Document Action: 'Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)' to Informational RFC

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) '
   <draft-ietf-capwap-objectives-04.txt> as an Informational RFC

This document is the product of the Control And Provisioning of Wireless AccessPoints Working Group. 

The IESG contact persons are Bert Wijnen and David Kessens.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-capwap-objectives-04.txt

Technical Summary
 
  This document presents objectives for an interoperable protocol for
  the Control and Provisioning of Wireless Access Points (CAPWAP). 
  The document aims to establish a set of focused requirements for the
  development and evaluation of a CAPWAP protocol.  The objectives
  address Architecture, Operation, Security and Network Operator
  Requirements that are necessary to enable interoperability among
  wireless local area network (WLAN) architectural variants.
 
Working Group Summary
 
  Support for local-MAC and split-MAC (obj-5.1.1 related to logical
  groups) had generated quite some spirited discussions. It aims to
  seek support for both modes as identified in RFC4118.  Also worth
  noting is the NAT traversal requirement – which was not in initial
  revision; that brought a desired objective in (5.1.15).
  Another noteworthy (accepted objective; but still debated on its
  variants) is the firmware update requirement (whether trigger is
  enough or more needs specified in Protocol).
 
Protocol Quality
 
  This document has had the benefit of review from WG members and
  rigorous review from IEEE802.11 WLAN WG as well through IEEE
  liaison Dorothy Stanley.

  Bert Wijnen has reviewed the document for the IESG.

  Since this is an Informational document and since it has had 
  serious review as stated above, there was no IETF Last Call.

Note to RFC Editor

- Please clarify section 5 on page 8.
  OLD:
   The objectives described in this document have been prioritized based
   on their immediate significance in the development and evaluation of
   a control and provisioning protocol for large-scale WLAN deployments.
   Additionally, one category is provided for requirements gathered from
   network service operators.  These are specific need that arise from
   operators' experiencese in deploying and managing large-scale WLANs.
   The priorities are;

   i.  Mandatory and Accepted Objectives
   ii.  Desirable Objectives
   iii.  Non-Objectives
   iv.  Operator Requirements

   The priorities have been assigned to individual objectives in
   accordance with working group discussions.

  NEW:

   The objectives described in this document have been prioritized based
   on their immediate significance in the development and evaluation of
   a control and provisioning protocol for large-scale WLAN deployments.
   The priorities are;
 
   i.  Mandatory and Accepted Objectives
   ii.  Desirable Objectives
   iii.  Non-Objectives
 
   The priorities have been assigned to individual objectives in
   accordance with working group discussions.
 
   Furthermore, a distinct category of objectives is provided based on
   requirements gathered from network service operators.  These are
   specific needs that arise from operators' experiences in deploying
   and managing large-scale WLANs.
 
   a. Operator Requirements

- Pls add some text in Section 5.1.8, in the 4th para on page 15
  OLD:
  Once WTPs and WLAN controller have been mutually authenticated,
  information exchanges between them must be secured against various
  security threats.  This should cover illegitimate modifications to
  ...
  NEW:
  Once WTPs and WLAN controller have been mutually authenticated,
  information exchanges between them must be secured against various
  security threats.  So the CAPWAP protocol MUST provide
  integrity-protection and replay-protection. The protocol SHOULD
  provide confidentiality through encryption.  This should cover
  illegitimate modifications to
  ...
- Pls insert a para in Section: 5.1.8, after last para on page 15
  OLD:
   CAPWAP MUST NOT prevent the use of asymmetric authentication.  The
   security considerations of such asymmetric authentication are
   described in the Security Considerations section.
  NEW:
   CAPWAP MUST NOT prevent the use of asymmetric authentication.  The
   security considerations of such asymmetric authentication are
   described in the Security Considerations section.

   If the CAPWAP protocol meets the criteria to require automated key
   management per BCP 107, then mutual authentication MUST be
   accomplished via an authenticated key exchange.

- Pls fix in Section: 5.1.8, first para on page 16
  OLD:
   The CAPWAP protocol MUST support mutual authentication of WTPs and
   the centralized controller.  It must also ensure that information
   exchanges between them are secured.
  NEW:
   The CAPWAP protocol MUST support mutual authentication of WTPs and
   the centralized controller. It also MUST ensure that information
   exchanges are integrity protected, and SHOULD ensure confidentiality
   through encryption."

  
- Please list all refrences as Normative.
  OLD:
  9.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3990]  O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
              Provisioning for Wireless Access Points (CAPWAP) Problem
              Statement", RFC 3990, February 2005.

   [RFC4118]  Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
              for Control and Provisioning of Wireless Access Points
              (CAPWAP)", RFC 4118, June 2005.

  NEW:
  9. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3990]  O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
              Provisioning for Wireless Access Points (CAPWAP) Problem
              Statement", RFC 3990, February 2005.

   [RFC4118]  Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
              for Control and Provisioning of Wireless Access Points
              (CAPWAP)", RFC 4118, June 2005.

IANA Note

  There are no actions required from IANA.


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce