Capwap Mailing List: Issue 171: Pasi nits on binding spec

[Pat Calhoun (pacalhou) (pcalhoun]

> Section 3: CAPWAP base protocol requires that all Request messages are
odd 
> numbers, and Responses even; these aren't.
Yes, this was raised already and will be addressed in the next rev.

> Section 3.1, "sent after the CAPWAP Configuration Update Request
message 
> (..) has been received by the WTP" probably 
> means "sent after the CAPWAP Configuration Update Response message has
been 
> received by the AC"?
Oh - right.

> 
> Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station QoS

> Profile"
Right.

> 
> Section 6.1 and 6.21: are some of these 802.11 information elements 
> optional, or are all of them always included?
Always, since the text states:

<current text>
   The inclusion of this message
   element MUST also include the IEEE 802.11 Information Element message
   element, containing the following 802.11 IEs:
</current text>

> 
> Section 6.1 and 6.21: what do you put in "Key Status" if you're not
using 
> encryption at all?
Well... Good question. The way it works is that the absence of a key
means that the key status field is irrelevant, but perhaps it would be
good to define a new "unused" value. However, this *could* create a
backward compatibility problem. Alternatively, we could add text that
simply states that this field is ignored if the key field has a zero
length, and then it really doesn't matter what value was used.

OK?


> 
> Section 6.21: to avoid repetition of text, I'd suggest simply pointing
to 
> existing text in Section 6.1 for field 
> descriptions.
Tried that before - had a bug asking for specific text :(

> 
> Section 6.1 and 6.21: "32 byte Session Key" -- length depends on "Key 
> Length" field, right?
Ack!

> 
> Section 6.2/10.6: is the "Combiner" a bit field or enumerated field?
> (And in the former case, an explicit bit diagram would be very useful
to 
> avoid confusion about bit numbering)
Enumerated - fixed it. Thanks.

> 
> Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably be
shown 
> as 3 bits in the diagram, to make it 
> unambiguous about which bits are not used.
Well... That would truncate a packet on a non-byte boundary. Do you
really believe that would help clear things up?

> 
> Section 6.15: The sentence "Note that AKM-Only is MAY be set..." would

> benefit for some clarification -- does 802.11 
> really drop all unencrypted EAPOL-Key frames if you have an encryption
key? 
> (it seems that would cause difficulties 
> when e.g. client reboots -- but I'm not sure what 802.11 does here)

When the client reboots, it will re-associate and that will cause the
state to change anyhow. If 802.1X is enabled, then the station will need
to re-authenticate in order to get to the point where it can transmit
data frames. This is normal IEEE 802.11-2007/802.1X behavior - and is
very well defined in the existing standards.

> 
> Section 6.15: "MUST NOT be sent if the WTP had not specifically
advertised 
> support for the requested encryption 
> scheme": would be easier to understand if it said how the WTP
advertises 
> this (presumably, the Encryption Capabilities 
> field in the WTP Descriptor Message Element?)
Got it. Added text at the end of the paragraph:

<new text>
6.15.  IEEE 802.11 Station Session Key

   The IEEE 802.11 Station Session Key message element is sent when the
   AC determines that encryption of a station must be performed in the
   WTP.  This message element MUST NOT be present without the IEEE
   802.11 Station (see Section 6.13) message element, and MUST NOT be
   sent if the WTP had not specifically advertised support for the
   requested encryption scheme, through the WTP Descriptor Message
   Element's Encryption Capabilities Field (see Section 8.1).
</new text>

> 
> Sections 6.20 and 6.22: the DSCP Tag field should probably be shown as
6 
> bits in the diagram, to make it unambiguous 
> how it's sent in
> IPv4/IPv6 header (and which bits are unused).

See above. I think showing fragments of a byte is even harder to
understand. I have never seen RFCs to that.

> Section 6.16, "maximum value of 65535" -- the fields are 32 bits, so 
> probably should be 4294967295?

Oh - you want to use *that* decimal system ;-)

> 
> Section 6.20 and 6.22: "if packets are to be DSCP tagged" would
benefit of 
> clarifying what packets are meant (I guess 
> it means CAPWAP Data packets sent from the WTP to the AC?).

New text:
<new text>
6.20.  IEEE 802.11 Update Station QoS

   The IEEE 802.11 Update Station QoS message element is used to change
   the Quality of Service policy on the WTP for a given station.  The
   QoS tags included in this message element are to be applied to
   packets received by the station.
[...]
6.22.  IEEE 802.11 WTP Quality of Service

   The IEEE 802.11 WTP Quality of Service message element value is sent
   by the AC to the WTP to communicate quality of service configuration
   information.  The QoS tag included in this message element are to be
   applied to packets received by the WTP from station on a particular
   radio.
</new text>

> 
> Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated
field?
> (In the former case, an explicit bit diagram would be very useful to
avoid 
> confusion about bit numbering.)
Agreed - and I've fixed this to be:

<new text>
6.22.  IEEE 802.11 WTP Quality of Service
[...]

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |   Tag Packets |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]

   Tag Packet:   A bit field indicating whether CAPWAP packets should be
      tagged for QoS purposes.  The field has the following format:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Reserved |D|P|U|
        +-+-+-+-+-+-+-+-+

      Reserved:  A set of reserved bits for future use.  All
         implementations complying with this protocol MUST set to zero
         any bits that are reserved in the version of the protocol
         supported by that implementation.  Receivers MUST ignore all
         bits not defined for the version of the protocol they support.

      D:   When set, this indicates that the CAPWAP packets should be
         tagged for QoS purposes using DSCP.

      P:   When set, this indicates that the CAPWAP packets should be
         tagged for QoS purposes using 802.1p.

      U:   When set, this indicates that the CAPWAP packets should be
         untagged.  When set, both the D and P bits MUST NOT be set.
</new text>
> 
> Section 6.23: "Country Code" field probably should be called "Country 
> String" (since it contains other things than the 
> country code, and it's called "country string" in 802.11), and it
should be 
> 3 octets instead of 4.
OK, again one key goal through this process is to minimize any
interoperability issues with existing implementations, so instead of
changing the length of the field, I propose adding the following
sentence to the end of the Country String field description:

<new text>
      Note that the last byte of the Country String MUST be set to NULL.
</new text>
> 
> Section 6.23: The description of third octet of Country field doesn't
quite 
> match IEEE 802.11 (e.g. 'X' character is 
> missing, and the '255'
> entry is confusing).
Yup - you are absolutely correct. I have fixed it to be:

<new text>
      1.   an ASCII space character, if the regulations under which the
         station is operating encompass all environments in the country,

      2.   an ASCII 'O' character, if the regulations under which the
         station is operating are for an outdoor environment only, or

      3.   an ASCII 'I' character, if the regulations under which the
         station is operating are for an indoor environment only.

      4.   an ASCII 'X' character, if the station is operating under a
         non-country entity.  The first two octets of the non-country
         entity shall be two ASCII 'XX' characters.
</new text>
I do want to note that this breaks backward interoperability, however
I'm not sure I've ever seen an AP that advertises the last option.

> 
> Section 6.23: reference [ISO.3166.1984] should be to the latest
edition, not 
> 1984 version:
> 
>    [ISO.3166-1] International Organization for Standardization, "Codes
>                 for the representation of names of countries and their
>                 subdivisions - Part 1: Country codes", ISO Standard
>                 3166-1:1997

Got it - thanks!

> 
> Section 6.25: an explicit bit diagram would be useful for the "Radio
Type" 
> field, since it's not clear whether e.g. 
> "2" really means bit number 2, or perhaps bit number 6 (rest of the
text 
> suggests it's the latter).

I agree, and I have fixed it to be:

<new text>
6.25.  IEEE 802.11 WTP Radio Information

[...]

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |                  Radio Type                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Radio Type   |
     +-+-+-+-+-+-+-+-+
[...]

   Radio Type:   The type of radio present.  Note this is a bit field
      which is used to specify support for more than a single type of
      PHY/MAC.  The field has the following format:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Reservd|N|G|A|B|
        +-+-+-+-+-+-+-+-+

      Reservd:  A set of reserved bits for future use.  All
         implementations complying with this protocol MUST set to zero
         any bits that are reserved in the version of the protocol
         supported by that implementation.  Receivers MUST ignore all
         bits not defined for the version of the protocol they support.

      N:   An IEEE 802.11n radioP.

      G:   An IEEE 802.11g radio.

      A:   An IEEE 802.11a radio.

      B:   An IEEE 802.11b radio.
</new text>

Note this makes certain assumptions about the position of the first bit,
and I think most people in the past would have assumed what I've done
here. However, this was a potential cause of interoperability issue, and
therefore could require an implementation to change.

> 
> Section 8.1: an explicit bit diagram would be useful (since bit
numbering 
> has been somewhat inconsistent in various 
> parts of the spec).

Yes, you have a great point. Here is the new text:

<text>
8.1.  WTP Descriptor Message Element, Encryption Capabilities Field:

   This specification defines two new bits for the WTP Descriptor's
   Encryption Capabilities field, as defined in
   [I-D.ietf-capwap-protocol-specification].  Note that only the bits
   defined in this specification are described below.  The format of the
   Encryption Capabilities Field is:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |       |A|T|   |
        +-+-+-+-+-+-+-+-+

   A:   WTP supports AES-CCMP, as defined in [IEEE.802-11.2007].

   T:   WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007]
      and [WPA], respectively.
</new text>

Again, this MAY have create an interoperability issue since the old text
was so vague. It is difficult to determine how people interpreted the
old text.

> 
> Section 8.1: WEP is missing from the list?

Given that WEP was introduced so long ago, it was just assumed that WTPs
support it. However, with TKIP and AES possibly requiring changes to the
ASIC, we wanted to allow WTPs to advertise these capabilities.

> 
> Section 8.1: there probably should be IANA considerations text about
how the 
> remaining bits are allocated.
I'm have opened issue 172 to track this issue.
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue172
> 
> Section 10.2, "defines 27 new Message Types" -> "defines 25 new
Message 
> Element Types"?
This was fixed when I cleaned up IANA considerations, given the issue
you raised on the base spec.

<new IANA text>
10.  IANA Considerations

   This section details the actions to be taken by IANA during the
   publication of the specification.  There are numerous registries that
   need to be created, and the contents, document action (see [RFC5226],
   and registry format are all included below.  Note that in cases where
   bit fields are referred to, the bit numbering is left to right, where
   the leftmost bit is labelled as bit zero (0).

10.1.  CAPWAP Wireless Binding Identifier

   This specification requires a value assigned from the Wireless
   Binding Identifier namespace, defined in
   [I-D.ietf-capwap-protocol-specification].  The value assigned is to
   be added to Section 2.1.  The value of one (1)is highly recommended,
   as it is used in implementations.

10.2.  CAPWAP IEEE 802.11 Message Types

   This document creates a new sub-registry to the existing CAPWAP
   Message Type registry, which is defined in
   [I-D.ietf-capwap-protocol-specification].

   IANA will create and maintain the CAPWAP IEEE 802.11 Message Types
   sub-registry for all message types whose Enterprise Number is set to
   13277.  The namespace is 32 bits (0-4294967295), where the values
   3398911 and 3398912 are reserved and must not be assigned.  The
   values 3398913 and 3398914 are allocated in this specification, and
   can be found in Section 3.  Any new assignments of a CAPWAP IEEE
   802.11 Message Type, whose Enterprise Number is set to 13277)
   requires a Standards Action.  The format of the registry to be
   maintained by IANA has the following format:

           CAPWAP IEEE 802.11               Message Type     Reference
           Control Message                     Value

10.3.  CAPWAP Control Message Type

   This specification defines new values to be registered to the
   existing CAPWAP Control Message Type registry, defined in
   [I-D.ietf-capwap-protocol-specification].  The values used in this
   document, 1024 through 1048, as listed in Figure 8 are recommended as
   implementations already exist that make use of these values.

10.4.  IEEE 802.11 Key Status

   The Key Status field in the IEEE 802.11 Add WLAN message element (see
   Section 6.1) and IEEE 802.11 Update WLAN message element (see



Calhoun, Editor, et al.  Expires February 1, 2009              [Page 64]

Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11       July 2008


   Section 6.21) is used to provide information about the status of the
   keying exchange.  This document defines four values, and the
   remaining values are controlled and maintained by IANA and requires a
   Standards Action.

10.5.  IEEE 802.11 QoS

   The QoS field in the IEEE 802.11 Add WLAN message element (see
   Section 6.1) is used to configure a QoS policy for the WLAN.  The
   namespace is 8 bits (0-255), where the values zero (0) through four
   (4) are allocated in this specification, and can be found in
   Section 6.1.  This namespace is managed by IANA and assignments
   require a Standards Action.  IANA will create the IEEE 802.11 QoS
   registry, whose format is:

           IEEE 802.11 QoS                  Type Value       Reference

10.6.  IEEE 802.11 Auth Type

   The Auth Type field in the IEEE 802.11 Add WLAN message element (see
   Section 6.1) is 8 bits and is used to configure the IEEE 802.11
   authentication policy for the WLAN.  The namespace is 8 bits (0-255),
   where the values zero (0) and one (1) are allocated in this
   specification, and can be found in Section 6.1.  This namespace is
   managed by IANA and assignments require a Standards Action.  IANA
   will create the IEEE 802.11 Auth Type registry, whose format is:

           IEEE 802.11 Auth Type            Type Value       Reference

10.7.  IEEE 802.11 Antenna Combiner

   The Combiner field in the IEEE 802.11 Antenna message element (see
   Section 6.2) is used to provide information about the WTP's antennas.
   The namespace is 8 bits (0-255), where the values zero (0) and one
   (1) are allocated in this specification, and can be found in
   Section 6.2.  This namespace is managed by IANA and assignments
   require a Standards Action.  IANA will create the IEEE 802.11 Antenna
   Combiner registry, whose format is:

           IEEE 802.11 Antenna Combiner     Type Value       Reference

10.8.  IEEE 802.11 Antenna Selection

   The Antenna Selection field in the IEEE 802.11 Antenna message
   element (see Section 6.2) is used to provide information about the
   WTP's antennas.  The namespace is 8 bits (0-255), where the values
   zero (0) is reserved and used and the values one (1) through four (4)
   are allocated in this specification, and can be found in Section 6.2.



Calhoun, Editor, et al.  Expires February 1, 2009              [Page 65]

Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11       July 2008


   This namespace is managed by IANA and assignments require a Standards
   Action.  IANA will create the IEEE 802.11 Antenna Selection registry,
   whose format is:

           IEEE 802.11 Antenna Selection    Type Value       Reference

10.9.  IEEE 802.11 Session Key Flags

   The Flags field in the IEEE 802.11 Station Session Key message
   element (see Section 6.15) is 16 bits and is used to configure the
   session key association with the mobile device.  This specification
   defines bits zero (0) and one (1), while bits two (2) through sixteen
   are reserved.  The reserved bits are managed by IANA and whose
   assignment requires a Standard Action.  IANA will create the IEEE
   802.11 Session Key Flags registry, whose format is:

           IEEE 802.11 Station Session Key   Bit Position    Reference

10.10.  IEEE 802.11 Tag Packets

   The Tag Packets field in the IEEE 802.11 WTP Quality of Service
   message element (see Section 6.22) is 8 bits and is used to specify
   how the CAPWAP Data Channel packets are to be tagged.  This
   specification defines bits five (5) through seven (7).  The remaining
   bits are managed by IANA and whose assignment requires a Standard
   Action.  IANA will create the IEEE 802.11 Tag Packets registry, whose
   format is:

           IEEE 802.11 Tag Packets           Bit Position    Reference

10.11.  IEEE 802.11 WTP Radio Fail

   The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication
   message element (see Section 6.24) is used to provide information on
   why a WTP's radio has failed.  The namespace is 8 bits (0-255), where
   the values zero (0) is reserved and unused, while the values one (1)
   and two (2) are allocated in this specification, and can be found in
   Section 6.24.  This namespace is managed by IANA and assignments
   require a Standards Action.  IANA will create the IEEE 802.11 WTP
   Radio Fail registry, whose format is:

           IEEE 802.11 WTP Radio Fail       Type Value       Reference

10.12.  IEEE 802.11 WTP Radio Type

   The Radio Type field in the IEEE 802.11 WTP Radio Information message
   element (see Section 6.25) is 8 bits and is used to provide
   information about the WTP's radio type.  This specification defines



Calhoun, Editor, et al.  Expires February 1, 2009              [Page 66]

Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11       July 2008


   bits five (5) through seven (7).  The remaining bits are managed by
   IANA and whose assignment requires a Standard Action.  IANA will
   create the IEEE 802.11 WTP Radio Type registry, whose format is:

           IEEE 802.11 WTP Radio Type        Bit Position    Reference
</new IANA text>