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.