IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP)
draft-ietf-opsawg-capwap-hybridmac-08

[Ballot comment]
Does the abstract really need to be as long as it is?  Wouldn't it be sufficient to say something like this?

  The CAPWAP protocol binding for IEEE 802.11 defines two MAC
  modes for IEEE 802.11 WTP: Split and Local MAC.
  In the Split MAC mode, the partitioning of encryption/decryption
  functions are not clearly defined.  This leads to interoperability
  issues, especially when the Access Controller (AC) and Wireless
  Transmission Point (WTP) come from different vendors.
  To prevent interoperability issues, this specification defines an
  IEEE 802.11 MAC profile message element in which each profile
  specifies an unambiguous division of encryption functionality
  between the WTP and AC.

I think this is sufficient information for people to figure out what the purpose of the document is, and then people who are interested in the stated problem will read the document.  The other information in the abstract seems unnecessary, and increases the workload of the reader who is deciding whether or not the document is something they need to read based on the abstract.

[Ballot comment]
Does the abstract really need to be as long as it is?  Wouldn't it be sufficient to say something like this?

  The CAPWAP protocol binding for IEEE 802.11 defines two MAC
  modes for IEEE 802.11 WTP: Split and Local MAC.
  In the Split MAC mode, the partitioning of encryption/decryption
  functions are not clearly defined.  This leads to interoperability
  issues, especially when the Access Controller (AC) and Wireless
  Transmission Point (WTP) come from different vendors.
  To prevent interoperability issues, this specification defines an
  IEEE 802.11 MAC profile message element in which each profile
  specifies an unambiguous division of encryption functionality
  between the WTP and AC.

I think this is sufficient information for people to figure out what the purpose of the document is, and then people who are interested in the stated problem will read the document.  The other information in the abstract really isn't needed, and is better expressed in the body of the document.

[Ballot comment]
Does the abstract really need to be as long as it is?  Wouldn't it be sufficient to say something like this?

  The CAPWAP protocol binding for IEEE 802.11 defines two MAC
  modes for IEEE 802.11 WTP: Split and Local MAC.
  In the Split MAC mode, the partitioning of encryption/decryption
  functions are not clearly defined.  This leads to interoperability
  issues, especially when the Access Controller (AC) and Wireless
  Transmission Point (WTP) come from different vendors.
  To prevent interoperability issues, this specification defines an IEEE
  802.11 MAC profile message element in which each profile specifies
  an unambiguous division of encryption functionality between the WTP
  and AC.

I think this is sufficient information for people to figure out what the purpose of the document is, and then people who are interested in the stated problem will read the document.  The other information in the abstract really isn't needed, and is better expressed in the body of the document.

[Ballot comment]


- intro, last para: Figure 1's last row says "WTP" in the
Local MAC column, but the text here implies that it should
say AC - what am I getting wrong?

- sec cons. saying WAP and AC messages "is encrypted" is not
quite what you want - I think you need to say that those
messages have origin authentication and data integrity (which
they should have if "encrypted" properly, and if they're not
that not this doc's fault).

[Ballot discuss]
You may not have seen the SecDir review, some helpful security consideration suggestions were provided and I'd like to see if you can work them into the draft, if appropriate.

Here is a link to the full review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05260.html

Here are the specific suggestions:
The Security Considerations Section says that this document does not introduce any new security risks compared to RFC5416, and that the security considerations
described in RFC5416 apply here as well.  I believe that a document that addresses the placement of encryption functionality should say something more, in particular
*why* it introduces no new security risks.  In the case of negotiation, the main security risk is that an attacker could interfere with the negotiation so that a less secure
alternative is chosen even when a more secure one is available.  In the security considerations section of RFC5416 it is noted that there is a possibility of a
replay attack if encryption resides at the WTP.  The risk is slight, and the only way of closing the security gap is expensive, so the authors of RFC5416 decide to let
the risk stand.  However, this presents a conceivable attack in which an attacker could cause an AC to believe that a WTP only supports  encryption functionality at the WTP,
and the AC would choose the less secure mode.  Although the risk this introduces is also slight, I believe that this should be mentioned. Also, would I be correct in assuming
that a WTP that supports encryption at the WTP but not at the AC is unlikely? If that is so, it might be possible to close the security gap by having the ATP reject advertisements (request
a retransmit?) that only support encryption at the WTP, and if so you should mention that too.

Thank you.

IESG/Authors/WG Chairs:

IANA has reviewed [draft-enter-here].  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the CAPWAP Message Element Type subregistry of the Control And Provisioning of Wireless Access Points (CAPWAP) Parameters registry located at:

https://www.iana.org/assignments/capwap-parameters/

two new protocol message elements are to be registered as follows:

CAPWAP Message Element: IEEE 802.11 Supported MAC Profiles
Type Value: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

CAPWAP Message Element: IEEE 802.11 MAC Profile
Type Value: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

IANA understands that RFC5415 requires that these values be in the range 1024-2047.

As this document requests registrations in an Expert Review (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, IANA will create a new registry called the CAPWAP IEEE 802.11 Split MAC Profile registry. This new registry will consist of a Profile name, a type value and a reference. IANA understands that the new registry wil be managed via Expert Review as defined in RFC 5226.

IANA QUESTION -> Where should this new registry be located? Is it a néw standalone registry on the IANA Matrix or is it a subregistry of an existing registry?  If it is a subregistry of an existing registry, in which registry will it be contained?  For example, should this a new subregistry be added to
the registry "Control And Provisioning of Wireless Access Points (CAPWAP) Parameters"
located at:

https://www.iana.org/assignments/capwap-parameters/

?

There are initial registrations in the new registry as follows:

Registry name: CAPWAP IEEE 802.11 Split MAC Profile
Registration procedure: Expert Review

Type Profile Value Reference
----------------------------------------+---------------+--------------------
Split MAC with WTP encryption 0 [ RFC-to-be ]
Split MAC with AC encryption 1 [ RFC-to-be ]
Unassigned  2-255

IANA understands these two actions to be the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IEEE 802.11 MAC Profile for CAPWAP) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'IEEE 802.11 MAC Profile for CAPWAP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-11-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The CAPWAP protocol defines two entities: a Wireless Transmission
  Point (WTP) and an Access Controller (AC).  The CAPWAP protocol
  binding for IEEE 802.11 defines two MAC (Medium Access Control) modes
  for IEEE 802.11 WTP: Split and Local MAC, and describes the required
  functionality split between the WTP and AC for each mode.  However,
  in the split MAC mode, the partitioning of encryption/decryption
  functions are not been clearly clearly defined.  In the Split MAC
  mode description, IEEE 802.11 encryption is specified as located in
  either at the AC or the WTP, with no clear way for the AC to inform
  the WTP of where the encryption functionality should be located.
  This lack of specification leads to interoperability issues,
  especially when the AC and WTP come from different vendors.  To
  prevent interoperability issues, this specification defines an IEEE
  802.11 MAC profile message element in which each profile specifies an
  unambiguous division of encryption functionality between the WTP and
  AC.  The IEEE 802.11 MAC profile is used as follows: the WTP informs
  the AC of the supported profiles during the discovery or join process
  and the AC configures the WTP with one of the supported profiles when
  configuring the WLAN.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd Template: 24 February 2012.

(1) What type of RFC is being requested:
Intended status: Standards Track.


(2) Document Announcement Write-Up:

Technical Summary:

This document defines an IEEE 802.11 MAC profile which specifies the
division of encryption functionality between the Wireless Transmission
Point (WTP) and the Access Controller (AC). This is to alleviate
interoperability issues, especially when the AC and WTP come from
different vendors.

Working Group Summary:

There was no drama in the WG related to this document.

OpsAWG provides a home for the CAPWAP work within the IETF, but CAPWAP is
not the primary focus of the WG. This means that only a small number
of participants had an opinion on the work, but those who did were supportive.

We also received a comment from the IEEE 802.11 Working Group Chair,
stating
that: "The IEEE 802.11 Working Group has also reviewed this document
and has no comments on its content."

Document Quality:
This document is well written, clear and concise.

Personnel:
Warren Kumari is the Document Shepherd. Benoit Claise is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.
The document shepherd is not very familiar with CAPWAP, and so has relied
on the opinions of those within the WG who know are familiar with
CAPWAP for technical evaluation.
The shepherd did review the document, and it is easily understandable
by those not steeped in the CAPWAP arcana.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The OpsAWG group is somewhat of a catch-all for documents
that don't fit very well in other working groups. This means that we
do not have a set of dedicated participants who are passionate about
the topics / documents. The IETF works on the CAPWAP stuff together
with the IEEE. All this means that we do not have a huge set of folk
with experience in this area. That said, the participants who *do*
know this stuff, and care about it all seem to believe that the work
is needed, useful and clear.
The IEEE 802.11 Working Group also reviewed this document and has no
comments on its content ( https://datatracker.ietf.org/liaison/1325/ )


(5) Do portions of the document need review from a particular or from broader perspective?
No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?
None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Each author has confirmed.


(8) Has an IPR disclosure been filed that references this document?
Nope.

(9) 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?

The WG is not very active and only a minority of the WG participants
follow CAPWAP, so the huge majority of the WG was silent. Those who
do care were very supportive. The work was also presented in meetings,
and discussion was supportive.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
Nope!


(11) Identify any ID nits the Document Shepherd has found in this
document.
None (all nits found have been addressed in the latest version).


(12) Describe how the document meets any required formal review criteria.
None needed.

(13) Have all references within this document been identified as either normative or informative?
Yes. There are only 2 references, both normative.

(14) Are there normative references to documents that are not ready for advancement?
No. Both references are to published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
Nope.

(16) Will publication of this document change the status of any existing RFCs?
Nope.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.
The IANA considerations section was a little sparse, the shepherd
provided feedback to the authors and it has now been fleshed out.
It appears acceptable now.
The actions requested of the IANA align with the document contents.


(18) List any new IANA registries that require Expert Review for future allocations.
CAPWAP IEEE 802.11 Split MAC Profile.


(19) Describe checks to validate formal language.
No formal language exists.