SLAPP: Secure Light Access Point Protocol
draft-narasimhan-ietf-slapp-01

[Note]: 'This document is an independent submission via the RFC Editor.  In conformance with RFC 3932, Section 4, the IESG requests the
  publication of the following note:  "This RFC documents the SLAPP protocol as it was when submitted to
  the IETF as a basis for further work in the CAPWAP WG, and therefore
  it may resemble the CAPWAP protocol specification (RFC XXXX), as well
  as other current IETF work in progress or published IETF work.
  This RFC is being published solely for the historical record. The  protocol described in this RFC has not been thoroughly reviewed and may
  contain errors and omissions.  RFC XXXX documents the standards track solution for the CAPWAP
  Working Group and obsoletes any and all mechanisms defined in this RFC.
  This RFC itself is not a candidate for any level of Internet  Standard and should not be used as a basis for any sort of deployment  in the Internet.  The IETF disclaims any knowledge of the fitness of this
  RFC for any purpose, and in particular notes that it has not had
  complete IETF review for such things as security, congestion control,
  or inappropriate interaction with deployed protocols.  The RFC Editor
  has chosen to publish this document at its discretion."' added by Amy Vezza

[Note]: 'This document is an independent submission via the RFC Editor.  In conformance with RFC 3932, Section 4, the IESG requests the
  publication of the following note:   "This RFC documents the SLAPP protocol as it was when submitted to
  the IETF as a basis for further work in the CAPWAP WG, and therefore
  it may resemble the CAPWAP protocol specification (RFC XXXX), as well
  as other current IETF work in progress or published IETF work.
  This RFC is being published solely for the historical record. The   protocol described in this RFC has not been thoroughly reviewed and may
  contain errors and omissions.   RFC XXXX documents the standards track solution for the CAPWAP
  Working Group and obsoletes any and all mechanisms defined in this RFC.
  This RFC itself is not a candidate for any level of Internet   Standard and should not be used as a basis for any sort of deployment   in the Internet.   The IETF disclaims any knowledge of the fitness of this
  RFC for any purpose, and in particular notes that it has not had
  complete IETF review for such things as security, congestion control,
  or inappropriate interaction with deployed protocols.  The RFC Editor
  has chosen to publish this document at its discretion."' added by Amy Vezza

[Note]: 'This document is an independent submission via the RFC Editor.   In conformance with RFC 3932, Section 4, the IESG requests the
  publication of the following note:

  "This RFC documents the SLAPP protocol as it was when submitted to
  the IETF as a basis for further work in the CAPWAP WG, and therefore
  it may resemble the CAPWAP protocol specification (RFC XXXX), as well
  as other current IETF work in progress or published IETF work.
  This RFC is being published solely for the historical record. The
  protocol described in this RFC has not been thoroughly reviewed and may
  contain errors and omissions.

  RFC XXXX documents the standards track solution for the CAPWAP
  Working Group and obsoletes any and all mechanisms defined in this RFC.
  This RFC itself is not a candidate for any level of Internet
  Standard and should not be used as a basis for any sort of deployment
  in the Internet.

  The IETF disclaims any knowledge of the fitness of this
  RFC for any purpose, and in particular notes that it has not had
  complete IETF review for such things as security, congestion control,
  or inappropriate interaction with deployed protocols.  The RFC Editor
  has chosen to publish this document at its discretion."

' added by Dan Romascanu

[Ballot discuss]
First, I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option 3 from section 3 of RFC3932:

  3. The IESG thinks that publication is harmful to the IETF work done
      in WG capwap and recommends not publishing the document at this time.

I understand that there is precedent for publication of overlapping input into the standards process (IPFIX was identified) but remain unconvinced. There is plenty of other precedent showing that overlapping independent work is delayed until standards track work is finished, and is a significant part of the spirit of the IESG review procedures instilled in RFC 3932.

Beyond this, this particular document is hardly fit for publication in current form.

1. Section 6.2 invents its own file download mechanism without thought for congestion control or other transport issues

2. Section 4.6.1 tries to handwave that WTP discovery can occur in one of no less than 6 different ways, none of which (save perhaps #1, static config) is specified in such way to be implemented. For example:

-    2.  DHCP options: As part of the DHCP response, the DHCP server could
        be configured to use option 43 to deliver the IP address of an AC
        to which the WTP should address the SLAPP discover request
        packet.  If the IP address of an AC is handed to the WTP as part
        of the DHCP response, then the WTP should address the SLAPP
        discover request packet to this IP address.

For reference, option 43 is an option for carrying vendor-specific information, and "could" is hardly the normative language necessary for a protocol specification.

One sentence is devoted to "Multicast discovery" with "[TBD]" at the end. Are we really going to allocate a Multicast address for this protocol?

DNS is mentioned as a "discovery" method, with no mention of what record type to use (again, a casual "[TBD]" inserted here).

In fact....

% grep  IANA draft-narasimhan-ietf-slapp-01.txt
    registered with, IANA).
                3-255  - RESERVED (to IANA)
    from, and registered with, IANA).  This field appears once for each
% grep  TBD draft-narasimhan-ietf-slapp-01.txt
    packet is a UDP packet addressed to port [TBD] designated as the
    port [TBD] and the destination port is the same as the source port
        multicast address [TBD].
        an AC [TBD].  If this DNS query succeeds, then the WTP should
    AC for this exchange will be [TBD].
    is TBD; when GRE encapsulates 802.3 frames the ether type in the GRE
    header is TBD2.

...yet there is no IANA Considerations section in the document.

I can't read anymore. This document is not fit for publication at any level of protocol specification, even Historic as this implies that at one time it might have been valid for implementation. The -01 version is hardly changed from -00. At best, this looks like a "first cut" of a protocol that needs a whole lot of work given that it tries to cover auto-discovery, file transport, L2 encapsulation over IP, Security, etc.

Given this document's gaping holes in design, coupled with its vast scope and apparant lack of review, I believe there is no chance for interoperability and a significant possibility for harm if one attempted to use this as a basis for implementation. I reiterate my stance that this document could be harmful if published in this form. Additional RFC Editor cycles should not be spent on this document without significant improvement from the authors first.

[Ballot discuss]
First, I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option 3 from section 3 of RFC3932:

  3. The IESG thinks that publication is harmful to the IETF work done
      in WG capwap and recommends not publishing the document at this time.

I understand that there is precedent for publication of overlapping input into the standards process (IPFIX was identified) but remain unconvinced. There is plenty of other precedent showing that overlapping independent work is delayed until standards track work is finished, and is a significant part of the spirit of the IESG review procedures instilled in RFC 3932.

Beyond this, this particular document is hardly fit for publication in current form.

1. Section 6.2 invents its own file download mechanism without thought for congestion control or other transport issues

2. Section 4.6.1 tries to handwave that WTP discovery can occur in one of no less than 6 different ways, none of which (save perhaps #1, static config) is specified in such way to be implemented. For example:

-    2.  DHCP options: As part of the DHCP response, the DHCP server could
        be configured to use option 43 to deliver the IP address of an AC
        to which the WTP should address the SLAPP discover request
        packet.  If the IP address of an AC is handed to the WTP as part
        of the DHCP response, then the WTP should address the SLAPP
        discover request packet to this IP address.

For reference, option 43 is an option for carrying vendor-specific information, and "could" is hardly the normative language necessary for a protocol specification.

One sentence is devoted to "Multicast discovery" with "[TBD]" at the end. Are we really going to allocate a Multicast address for this protocol?

DNS is mentioned as a "discovery" method, with no mention of what record type to use (again, a casual "[TBD]" inserted here).

In fact....

% grep  IANA draft-narasimhan-ietf-slapp-01.txt
    registered with, IANA).
                3-255  - RESERVED (to IANA)
    from, and registered with, IANA).  This field appears once for each
% grep  TBD draft-narasimhan-ietf-slapp-01.txt
    packet is a UDP packet addressed to port [TBD] designated as the
    port [TBD] and the destination port is the same as the source port
        multicast address [TBD].
        an AC [TBD].  If this DNS query succeeds, then the WTP should
    AC for this exchange will be [TBD].
    is TBD; when GRE encapsulates 802.3 frames the ether type in the GRE
    header is TBD2.

...yet there is no IANA Considerations section in the document.

I can't read anymore. This document is not fit for publication at any level of protocol specification, even Historic as this implies that at one time it might have been valid for implementation. The -01 version is hardly changed from -00. At best, this looks like a "first cut" of a protocol that needs a whole lot of work given that it tries to cover auto-discovery, file transport, L2 encapsulation over IP, etc.

Given this document's gaping holes in design, coupled with its vast scope and apparant lack of review, I believe there is no chance for interoperability and a significant possibility for harm if one attempted to use this as a basis for implementation. I reiterate my stance that this document could be harmful if published in this form. Additional RFC Editor cycles should not be spent on this document without significant improvement from the authors first.

[Ballot discuss]
First, I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option 3 from section 3 of RFC3932:

  3. The IESG thinks that publication is harmful to the IETF work done
      in WG capwap and recommends not publishing the document at this time.

I understand that there is precedent for publication of overlapping input into the standards process (IPFIX was identified) but remain unconvinced. There is plenty of other precedent showing that overlapping independent work is delayed until standards track work is finished, and is a significant part of the spirit of the IESG review procedures instilled in RFC 3932.

Beyond this, this particular document is hardly fit for publication in current form.

1. Section 6.2 invents its own file download mechanism without thought for congestion control or other transport issues

2. Section 4.6.1 tries to handwave that WTP discovery can occur in one of 6 different ways, none of which (save perhaps #1, static config) is specified in such way to be implemented. For example:

-    2.  DHCP options: As part of the DHCP response, the DHCP server could
        be configured to use option 43 to deliver the IP address of an AC
        to which the WTP should address the SLAPP discover request
        packet.  If the IP address of an AC is handed to the WTP as part
        of the DHCP response, then the WTP should address the SLAPP
        discover request packet to this IP address.

For reference, option 43 is an option for carrying vendor-specific information, and "could" is hardly the normative language necessary for a protocol specification.

One sentence is devoted to "Multicast discovery" with "[TBD]" at the end. Are we really going to allocate a Multicast address for this protocol?

DNS is mentioned as a "discovery" method, with no mention of what record type to use (again, a casual "[TBD]" inserted here).

In fact....

% grep  IANA draft-narasimhan-ietf-slapp-01.txt
    registered with, IANA).
                3-255  - RESERVED (to IANA)
    from, and registered with, IANA).  This field appears once for each
% grep  TBD draft-narasimhan-ietf-slapp-01.txt
    packet is a UDP packet addressed to port [TBD] designated as the
    port [TBD] and the destination port is the same as the source port
        multicast address [TBD].
        an AC [TBD].  If this DNS query succeeds, then the WTP should
    AC for this exchange will be [TBD].
    is TBD; when GRE encapsulates 802.3 frames the ether type in the GRE
    header is TBD2.

...yet there is no IANA Considerations section in the document.

I can't read anymore. This document is not fit for publication at any level of protocol specification, even Historic as this implies that at one time it might have been valid. The -01 version is hardly changed from -00. At best, this looks like a "first cut" of a protocol that needs a whole lot of work given that it tries to cover auto-discovery, file transport, L2 encapsulation over IP, etc.

I see no good reason to publish this document at all in this form. Given the gaping holes in design, lack of review and iteration, and vast scope, there is a lot possibility for harm if anyone tries to implement this.

[Ballot discuss]
I strongly argue that we should recommend the RFC-editor to not publish this document as it describes a protocol that lacks basic congestion control mechanisms. The authors should start with reading:
http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-udp-guidelines-02.txt
And then consider if they really need to implement the protocol on top of UDP instead of TCP, with the possible special UDP function for broadcast discovery of ACs.

To go into more detail. The protocol is clearly intended to be used in a general IP network environemnt as described in section 3, Topology. It performs both simple request response actions and bulk data transfers (Image Download). It has no rate control function at all. It has no reaction to losses, other than retransmitting. This is a protocol that is dangerous to itself and other traffic from a congestion point of view.

IANA Evaluation Comments:


The IANA consideration section is not clear on what actions
are requested of IANA.

No IANA Considerations section but registrations observed
in the document.

[Ballot comment]
The Abstract should not contain references like [3].  These references
  need to be replaced with text that points to an RFC by number.  It is
  important to remember that the Abstract is copied into an RFC index.

[Ballot discuss]
This discuss has two parts.

The first part is a discuss discuss: As I read the IESG note, a standards track protocol is forthcoming for capwap.  Publication of the slapp specification as "Informational" may cause confusion, particularly since the standards track protocol is still under development.  (1) Wouldn't it be better to progress this specification as "Historic"? (2) Should we delay publication of this spec until the standards track protocol is published?

The second part is a normal discuss position:

The security considerations text begins with

    This document describes a protocol, SLAPP, which uses a different
    protocol, DTLS, to provide for authentication, key exchange, and bulk
    data encryption of a negotiated control protocol.  It's security
    considerations are therefore those of DTLS.

I believe that is an oversimplification.

    This document describes a technology independent protocol for controller discovery,
    security association establishment, and control protocol negotiation.  Authentication,
    key exchange, and bulk data encryption are required during the security assocation
    phase.  This protocol depends upon DTLS [7] to provide authentication, key exchange,
    and bulk data for security association establishment.  As a result, the security
    considerations described in [7] apply to the security association establishment phase
    of this protocol.

[Note]: 'This document is an independent submission via the RFC Editor. In conformace with RFC 3932, Section 4, the IESG requests the publication of the following note: "This RFC documents the SLAPP protocol as it was when submitted to the IETF as a basis for further work in the CAPWAP WG, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC itself is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that it has not had complete IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion."
' added by Dan Romascanu

[Note]: 'This document is an independent submission via the RFC Editor. In conformace with RFC 3932, Section 4, the IESG requests the publication of the following note:

   "This RFC documents the SLAPP protocol as it was when submitted to the
   IETF as a basis for further work in the CAPWAP WG, and therefore it
   may resemble a current IETF work in progress or a published IETF work.

   This RFC itself is not a candidate for any level of Internet
   Standard.  The IETF disclaims any knowledge of the fitness of this
   RFC for any purpose, and in particular notes that it has not had
   complete IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion."
' added by Dan Romascanu