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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
