Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11
RFC 5416

Received changes through RFC Editor sync (changed abstract to 'Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller.

This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. [STANDARDS-TRACK]')

[Ballot comment]
(Updated comment for version -11)

Section 1 says 802.11n is not supported by this specification, but
Section 6.25 defines a field for 802.11n?

Section 8.1: there probably should be IANA considerations text about
how the remaining bits are allocated (or explicitly say that the
remaining bits will not be allocated, and new capabilities require
defining a new WBID).

Section 8.1 should say that there's no bit for WEP because all WTPs
are required to support it (if that's the reason).

Section 10.2 (Message Types): the range to be managed by IANA is not
32 bits, but only 8 (i.e. the unassigned values are 3398915-3399167,
not 0-4294967295).

Section 10.2: message type 3398911 has Enterprise Number 13276, not
13277, so it's not part of the range to be managed by IANA.

Section 10.5 (QoS) says values 0-4 are allocated in this
specification, but Section 6.1 defines only values 0-3.

Section 10.7 (Antenna Combiner) says values 0 and 1 are allocated in
this specification, but Section 6.2 defines values 1-4.

Section 10.8 (Antenna Selection) says values 1-4 are allocated in this
specification, but Section 6.2 defines only values 1-2.

Section 10.9 (Session Key Flags) , "bits two (2) through sixteen"
should be "..through fifteen".

Section 10.10 (Tagging Policy) says bits 5-7 are defined in this spec;
but Section 6.22 defines bits 3-7.

Section 10.12 (WTP Radio Type) says bits 5-7 are defined in this spec,
but Section 6.25 defines bits 4-7.

[Ballot discuss]
This is a question that I really would like to get answered before being certain about progressing this document.

Section 2.6.1.2

  "The IP header also includes the Explicit Congestion Notification
  (ECN) bits [RFC3168].  When packets received from stations are
  encapsulated by the WTP, the ECN bits are set to zero (0) in the
  outer header.  The WTP does not modify the ECN bits in the original
  station's packet header.  This mode of operation is detailed as the
  "limited functionality option" in [RFC3168]."

Can you provide some reasoning why this section basically mandates the limited functionality option for ECN? I don't understand why full functionality would be a problem.

[Ballot comment]
Section 6.14: The 802.1p Tag field should be shown as 3 bits in
the bit diagram, too.

Section 6.23, ""the third octet MUST have the value 1, 2 or 3 as
defined below" should be "the third octet MUST value the value ' ',
'O', 'I', or 'X' as defined below" (there are four different values,
none of which are 1, 2, or 3).

Section 1 says 802.11n is not supported by this specification, but
Section 6.25 defines a field for 802.11n?

Section 8.1: the "Encryption Capabilities" field is now 16 bits, not 8.

Section 8.1: there probably should be IANA considerations text about
how the remaining bits are allocated (or explicitly say that the
remaining bits will not be allocated, and new capabilities require
defining a new WBID).

Section 8.1 should say that there's no bit for WEP because all WTPs
are required to support it (if that's the reason).

Section 10.2 (Message Types): the range to be managed by IANA is not
32 bits, but only 8 (i.e. the unassigned values are 3398915-3399167,
not 0-4294967295).

Section 10.2: message type 3398911 has Enterprise Number 13276, not
13277, so it's not part of the range to be managed by IANA.

Section 10.5 (QoS) says values 0-4 are allocated in this
specification, but Section 6.1 defines only values 0-3.

Section 10.7 (Antenna Combiner) says values 0 and 1 are allocated in
this specification, but Section 6.2 defines values 1-4.

Section 10.8 (Antenna Selection) says values 1-4 are allocated in this
specification, but Section 6.2 defines only values 1-2.

Section 10.9 (Session Key Flags) , "bits two (2) through sixteen"
should be "..through fifteen".

Section 10.10 (Tagging Policy) says bits 5-7 are defined in this spec;
but Section 6.22 defines bits 3-7.

Section 10.12 (WTP Radio Type) says bits 5-7 are defined in this spec,
but Section 6.25 defines bits 4-7.

[Ballot discuss]
I've commented the spec already during IETF last call, but there's one
remaining issue that I'd like to discuss further:

When TKIP or CCMP encryption is used, and WTP does the encryption, it
obviously needs the key (TK) for TKIP or CCMP.  However, currently the
AC also sends two other keys, the EAPOL Key Confirmation Key (KCK) and
Key Encryption Key (KEK), to the WTP, even though the WTP does not
seem to need these keys for anything.  The principle of least
privilege would suggest that the AC shouldn't send these keys. Why
not send just the needed keys? Or does the WTP need the KCK/KEK
for something?

(I also found a bunch of editorial nits and inconsistencies, but
I've listed these in the "Comment" text since they don't really
need discussion.)

IANA has questions about this document.

Upon approval of this document, IANA understands that additions
will be made in the newly created CAPWAP registry. This registry,
created upon approval of draft-ietf-capwap-protocol-specification,
will consist of the subregistries created by approval of the base
CAPWAP protocol specification. IANA understands that this
document (draft-ietf-capwap-protocol-binding-ieee80211), if
approved, will make a series of additions to that document. Those
additions will include both additions to existing subregisties
(created upon approval of draft-ietf-capwap-protocol-
specification), and entirely new subregistries in the CAPWAP
registry.

Upon approval of this document, IANA understands that there are
eleven actions that need to be carried out:

1] CAPWAP Message Types
IANA will add two new Message Types to the CAPWAP Message
Types subregistry in the newly created CAPWAP registry.

IANA HAS A QUESTION ABOUT THIS ACTION:

How should the CAPWAP Control Message Type be formatted in the
newly created CAPWAP Message Type registry? IANA understands
that these are the first two Message Types specified for CAPWAP. Is
this correct?

2] CAPWAP Control Message Type
The current version of the document says that "This specification
defines 27 new Message Types used in the CAPWAP header. These
values are defined in Figure 8."

IANA HAS A QUESTION ABOUT THIS ACTION:

Figure 8 appears to not have control message types. Instead, Figure
8 is labelled "IEEE 802.11 Binding Message Elements." Where should
IANA look for the Control Message Types in this document?

3] IEEE 802.11 Key Status

IANA HAS A QUESTION ABOUT THIS ACTION:

The Key Status field in the IEEE 802.11 Add WLAN message element
and IEEE 802.11 Update WLAN message element is used to provide
information about the status of the keying exchange. This is an
eight bit field. IANA understands that this will be a new subregistry
in the registry created by approval of draft-ietf-capwap-protocol-
specification. For this subregistry a set of 4 initial values is supplied
for the Add WLAN message element.

The document references Section 6.21 for the IEEE 802.11 Update
WLAN message element, but IANA is unable to find that section in
the current version of the document. Does specification of Key
Status in some other part of the document add new registrations for
the IEEE 802.11 Key Status registry?

4] IEEE 802.11 QoS
The QoS field in the IEEE 802.11 Add WLAN message element is
used to configure a QoS policy for the WLAN. This is an eight bit
field. IANA understands that this will be a new subregistry in the
registry created by approval of draft-ietf-capwap-protocol-
specification. For this subregistry a set of 4 initial values is
supplied. Future registrations in this subregistry require standards
action.

IEEE 802.11
QoS Description

0 Best Effort
1 Video
2 Voice
3 Background

5] IEEE 802.11 Auth Type
The Auth Type field in the IEEE 802.11 Add WLAN message element
is used to configure the IEEE 802.11 authentication policy for the

WLAN. This is an eight bit field. IANA understands that this will be a
new subregistry in the registry created by approval of draft-ietf-
capwap-protocol-specification. For this subregistry a set of 2 initial
values is supplied. Future registrations in this subregistry require
standards action.

IEEE 802.11
Auth Type Description

0 Open System
1 WEP Shared Key

6] IEEE 802.11 Antenna Combiner
The Combiner field in the IEEE 802.11 Antenna message element
(seeSection 6.2) is used to provide information about the WTP's
antennas. This is an eight bit field. IANA understands that this will
be a new subregistry in the registry created by approval of draft-
ietf-capwap-protocol-specification. For this subregistry a set of 4
initial values are supplied. Future registrations in this subregistry
require standards action.

IEEE 802.11
Antenna Combiner Description

1 Sectorized (Left)
2 Sectorized (Right)
3 Omni
4 Multiple Input/Multiple Output (MIMO)

7] 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. This is an eight bit field. IANA understands that
this will be a new subregistry in the registry created by approval of
draft-ietf-capwap-protocol-specification. For this subregistry a set
of 2 initial values is supplied. Future registrations in this subregistry
require standards action.

IEEE 802.11
Antenna Selection Description

1 Internal Antenna
2 External Antenna

8] IEEE 802.11 Session Key Flags
The Flags field in the IEEE 802.11 Station Session Key message
element is used to configure the session key association with the
mobile device. This is a sixteen bit field. The document provides a
definition of the first two bits.

IANA HAS A QUESTION ABOUT THIS ACTION:

Is this really an item for an IANA registry? The document provides a
definition and requires that any definition of the other 14 bits
should be done through standards action. What should the registry
look like for the Session Key Flags?

9] IEEE 802.11 Tag Packets
The Tag Packets field in the IEEE 802.11 WTP Quality of Service
message element is used to specify how the CAPWAP Data Channel
packets are to be tagged. This is an eight bit field. IANA
understands that this will be a new subregistry in the registry
created by approval of draft-ietf-capwap-protocol-specification.
For this subregistry a set of 2 initial values is supplied. Future
registrations in this subregistry require standards action.

IEEE 802.11
Tag Packets Description

0 Untagged
1 802.1p
2 DSCP

10] IEEE 802.11 WTP Radio Fail
The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication
message element is used to provide information on why a WTP's
radio has failed. This is an eight bit field. IANA understands that
this will be a new subregistry in the registry created by approval of
draft-ietf-capwap-protocol-specification. For this subregistry a set
of 2 initial values is supplied. Future registrations in this subregistry
require standards action.

IEEE 802.11
Radio Fail Alarm
Indicator Description

1 Reciever
2 Transmitter

11] 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 used to provide information
about the WTP's radio type. This is a thirty-two bit field. IANA
understands that this will be a new subregistry in the registry
created by approval of draft-ietf-capwap-protocol-specification.
For this subregistry a set of 4 initial values are supplied. Future
registrations in this subregistry require standards action.

IEEE 802.11
Radio Type Description

1 802.11b
2 802.11a
4 802.11g
8 802.11n

IANA understands that these eleven actions are the only actions
required upon approval of this document.

AD Review by Dan Romascanu

Here is the AD review of
draft-ietf-capwap-protocol-binding-ieee80211-06. Although the document looks stable and in pretty good shape, there are a number of issues that need to be fixed or seem unclear, so a new I-D revision seems to be necessary before sending the document to IETF Last Call.

I have divided my comments into Technical and Editorial.

Regards,

Dan

-------------------------------

T1. Section 2.1.1 and 2.1.2 - What version of IEEE 802.1X is this document supporting? I believe that this needs to be clarified, as IEEE 802.1X is currently under revision, and the document needs to be included as a Normative reference.

T2. Section 4, definition of WLAN ID bitmap

        This field is to be set to zero for unicast packets and is
        unused if the WTP is not providing IEEE 802.11 encryption.

This being a bitmap, is the intention to say 'set to all zero'?

T3. What is the encoding of the Capabilities or Capability field (see also E6)?

T4. Section 6.1 - what is the format and length of the SSID field?

T5. Section 6.3 - why length = 3?

T6. Section 6.6 - should not length be >=3? (RadioID + WLANID + Flags at
minimum)

T7. Section 6.10 - the definition of how the field Band supported is codified is confusing. First a three bit integer value is mentioned, but then the explanation seems to indicate it's a bit mask

T8. Section 6.12 - the length should be 40

T9. Section 6.16 - for all statistics counters in this message - explain 1. do they start counting from 0 at initialization? What is the behavior when the device loses power? What is the behavior when they reach maximal value? Minimal interval between two rollover events

T10. Section 6.23 - Country Code

      Special
      attention is required with use of this field, as implementations
      which take action based on this field could violate regulatory
      requirements.  Some regulatory bodies do permit configuration of
      the country code under certain restrictions, such as the FCC, when
      WTPs are certified as Software Defined Radios.

I do not know what can be done with this text from a technical (implementation or processing) point of view. What 'special attention'
means? What can an implementation know about regulatory restrictions?
And what 'certain restrictions' mean? I suggest to reconsider if this text is needed and if it is clarify if there are any technical impacts or move it to a separate note or subsection.



E1. It is recommended to avoid mentioning references in Abstract sections. The current Abstract section mentions [3], I suggest to remove this.

E2. Terminology - The definition of a Station (STA) differs from the one in [3]. Is it there that it should extended to describe the presence of a MAC and a PHY, or is it here it is unnecessarily verbose?

E3. There are a lot of acronyms and terms mostly from the IEEE 802.11 realm that are neither expanded, not explained - RSN, WMM, EDCA, OFDM are only part of them. I suggest to expand the terminology section to add them 

E4. Section 4, page 19, Data rate - s/The data rate field is a 16 bit unsigned value. The contents of the field is set to 10 times the data rate in Mbps of the packet received by the WTP. /The data rate field is a 16 bit unsigned value expressing the data rate of the packets received by the WTP in units of 0.1 Mbps./

E5. Section 6 - for consistency it looks like the IEEE 802.11 Message Element / Type Value table should be a numbered figure.

E6. Section 6.1 - is the field named 'Capabilities' as in the diagram or 'Capability' as in the description?

E7. Section 6.2 - Antenna Selection should be represented in the diagram as N x 8 bit fields. Maybe the diagram is meant to say that padding is applied to 32-bit multiple in this case, but this should be clearly described, if this is the case.

E8. Section 6.6 - the 6 Flags bits should rather be named Reserved Bits.


E9. Section 6.13 - more information should be included about the supported rates syntax and length (even if the reference to the MIB document in [2] is provided

E10. Section 6.14 - IEEE 802.1P tag is three bits - why is the 802.1P Precedence Tag two octets? And why is it called Precedence Tag and not Priority Tag (same comment for 6.20, 6.22)?

E11. Section 6.23 - Document ISO/IEC 3166- 1 should be made a Normative Reference

E12 - Section 6.25 - is radio type a bitmask? Say clearly so. No need to say anything about the value for all four radio types

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for forwarding
to the IESG for publication?
Dorothy Gellert is the shepard for this document. Yes, I have fully
reviewed the document and believe that it is ready for publication.
(1.b) Has the document had adequate review both from key WG members and
from key non-WG members? Does the Document Shepherd have any concerns
about the depth or breadth of the reviews that have been performed?
It is my opinion that this document have been very well reviewed, as it
has gone through several WG last calls.
(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization
or XML?
No further review is necessary. Besides the CAPWAP WGLCs, this
document has been reviewed twice by IEEE 802.11.
(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document been
filed? If so, please include a reference to the disclosure and summarize
the WG discussion and conclusion on this issue.
This document is a necessary component of the CAPWAP architeture, and
the intention of the WG was for the CAPWAP protocol to be used in 802.11
networks.
(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?
This document has gone throught several review and internal WG
discussion and socialization and review in IEEE. It is my opinion that
this document has solid consensus and agreement by the WG.
(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)
There has been no appeal or extreme discontent regarding this document