CAPWAP Protocol Specification Editors' Report

1. CAPWAP Protocol Specification Editors' Report July 2006 pcalhoun@cisco.com mmontemurro@rim.com dstanley@arubanetworks.com

2. Highlights from -02 Issue Resolution Schedule for -03, -04, completion of CAPWAP protocol specification V1.0 Issues Discussion IEEE 802.11 Binding Scope in CAPWAP V1.0 Raising the bar on New Issues Issue 43: 802.11i Considerations Issue 90: Using 802.3 for tunneling in Split-MAC mode Issue 126: Wrong Place for “Image Data” State Issue 138: CAPWAP Protocol WTP/AC Encryption Support Editors’ Report Agenda

3. Issue 129. Cut and paste error fixed Issue 128. Typo in 8.6 and 8.7 fixed Issue 125. Move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information Issue 43. Add a Broadcast frame sequence number using 802.11 Update WLAN included in the IEEE 802.11 config response frame Issue 80: Reject: Recommend "change MAC address to IP address in section 10.3" Issue 100: Section 11.5 overlap with Section 4.3.3 – Made QOS Definitions consistent Issue 136: Typo in 4.3.1.1 Issue 133 updated 4.4.13 to remain consistent with 4.4.12 Issue 103 Merged Change-State-Event Message Element with Administrative-State Message Element Issue 104 Made the following changes Issue 64: TSPEC provisioning - Local MAC vs Split MAC Issue 37: Use the vendor specific message frame type Issue 141: Added WLAN ID and Radio ID to both messages Issues covered in CAPWAP-02

4. Issue 134 - Local MAC/ send disassociation if AC sends back negative association Issue 132 - Re-word goal #1 Issue 124 - Bob's (largely) editorials Issue 106 - Added short preamble to WTP Radio Config Issue 98 - Misc editorials, some incorporated, some rejected Issue 97 - Expanded Discovery type definitions, clarifying text Issue 78 - Add WTP Radio Information to Config Status message Issue 45 - Added text control message keep-alive rationale Issue 84 - Added Statistics Issue 81 - Some done in -01, Changed encapsulation to tunnel terminology Issue 74 - Result code in Response messages Issue 2 - Charles' certificate usage sections Issue 63 - All fields in 802.11 Mobile message element required Issue 85 - State machine changes - addressed in -01 or rejected Issue 86 - Comments on DTLS  - addressed in -01 Issue 105 - Reset statistics - reject with Dan R's reasoning Issues covered in CAPWAP-02

5. Issue 77: Added Local MAC to the document's introduction section Issue 120:New CAPWAP header format to fix various issues introduced in -01 Issue 119: Encapsulation data type in CAPWAP header Issue 118: New SW/HW version formats in WTP/AC Descriptor message elements Issue 83: Added clarification on the use of RADIUS in CAPWAP, which is handled in the AC Issue 66: Changed CAPWAP to deal better with clear configuration to WTP. Required state machine and changing what used to be a one way notification message to a request/response message. Issue 117: SSID suppression should be done on a per WLAN basis - not globally. However, the protocol supported both modes. Removed the global config flag. Issue 107: Rejected. No longer valid with the fix to issue 117 Issue 18: Included pointers to the IEEE 802.11 MIB variable names in the message elements, where possible/relevant Issue 123: Fixed a bug introduced in -01 where the capability field was removed from the Add/Update WLAN, with the assumption this was the same as the Power Capability Information Element. However, the capabilities field is not an IE, so it had to be re-added back to the Add/Update WLAN message elements. Issue 116: Moved fields from the Add/Update WLAN message elements to the IEEE 802.11 Mobile Session Key message element. Issue 130: New terminology section added Issues covered in CAPWAP-02

6. Resolved issue # 2 – Incorporate DTLS into CAPWAP protocol, replacing proprietary LWAPP mechanism. Largely complete. Open new issues for any further changes. Resolved issue # 124, structural message element changes. Believe that the document is easier to read, easier to find message element definitions. Resolved Issue # 84 – Added WTP Statistics and (non) piggybacking of statistics in Echo messages Highlights from -02 Issue Resolution

7. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN | WBID |T|F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where WBID is the CAPWAP Wireless Binding Identifier (IEEE 802.11 = 1) ‘T’ bit specifies whether payload is in wireless native format (e.g., 802.11 vs. 802.3) Remaining Issue: Wireless Specific Information includes a binding identifier, which is now repetitive. Issues 120 & 119 (Header Format)

8. Issue: Clear Config Indication was never acknowledged via an explicit response. Failure to clear config could not be known by the AC Changed –Indication to –Request, and introduced the Clear Config Response State machine is now explicit in that the response is sent. Issue 66: Unclear how Clear Config Indication is acknowledged

9. Issue: A deep understanding of the IEEE 802.11 protocol specification was required to create a link between MIB variables and CAPWAP message element fields Added explicit references, such as: 11.10.2. IEEE 802.11 Antenna [...] Diversity: An 8-bit value specifying whether the antenna is to provide receive diversity. The value of this field is the same as the IEEE 802.11 dot11DiversitySelectionRx MIB element (see [6]). The following values are supported: Issue 18: use MIB variable names instead

10. Issue: Many of the 802.11i fields were in the Add/Update WLAN message elements Remove these fields, and instead rely on the RSNA IE being sent alongside the above message elements Changes required to “IEEE 802.11 Add WLAN”, “IEEE 802.11 Mobile Session Key” and “IEEE 802.11 Update WLAN” Issue 116: Encryption Policy should use RSNA IE The CAPWAP protocol now relies more on 802.11 IEs instead of recreating new message elements

11. Defined binding-specific message type using IANA Enterprise number. Partition Message Elements for technology-specific binding (fixed in CAPWAP-02) Issue 76 – Wireless Technology Binding

12. Completed schedule dates Feb 25 – revision 00 March 20 – IETF meeting – review plans for revision-01, based on list discussion May 5th –publish revision 01 June 24th – publish revision 02 July 10th – IETF meeting – review plans for revision-03 Planned Schedule August 31 - publish revision 03 September/October – resolve remaining/new issues Mid/Late October (Nov meeting publication date) – publish -04, WGLC Now/Ongoing – Identify plans for –bis/requirements on next CAPWAP protocol version (Issue Discussion Item) End November submit to IESG Schedule

13. IEEE 802.11 Binding Scope in CAPWAP V1.0 Raising the bar on New Issues Issue 43: 802.11i Considerations Issue 90: Using 802.3 for tunneling in Split-MAC mode Issue 126: Wrong Place for “Image Data” State Issue 138: CAPWAP Protocol WTP/AC Encryption Support Issues to discuss

14. Shall unapproved 802.11 amendments (e.g. 802.11n, 802.11r, etc) be supported in the initial CAPWAP protocol IEEE 802.11 binding? Arguments in favor: 802.11n will be in the market and CAPWAP will need to support 802.11n to (and perhaps other draft amendments) to be relevant in the market Arguments against: Support of draft amendments requires selecting a specific draft, “standardizing” on that draft, and essentially has the IETF specifying a non-standard amendment. “Changes to 802.11” is a CAPWAP non-goal. Only completed amendments should be supported. Completion schedule for CAPWAP determines the amendments supported in a particular version. Inclusion of the 802.11 information elements in the CAPWAP binding, and definition of vendor specific message elements enable vendors to add the extensions if needed in advance of a CAPWAP binding. Goal should be to make the binding as independent of 802.11 changes as possible. Identify targeted amendments, e.g. those completed in 2007 for a subsequent CAPWAP specification. IEEE 802.11 Binding Scope

15. Goal is to finish CAPWAP V1.0 in -06 Have been trying to accommodate as many proposed changes, issues as possible Need to start deferring work into -bis/V2.0 Define requirements on next CAPWAP protocol version Need to start saying “No” to proposed additions, need criteria for this Raising the Bar on New Issues

16. Specified the Architecture for IEEE 802.11i EAPoL frames generated at the AC Currently: Encryption done at either AC or WTP Specified how Group Key exchange works Added Group Key signaling and keyRSC to UpdateWLAN Issue: Request that keyRSC be managed at either the AC or the WTP Would require additional negotiations between AC and WTP Would require the EAPoL frame to be sent as control frame. Issue 43 – IEEE 802.11i Considerations

17. Recommendation to remove 802.3 tunneling in Local MAC mode, and add 802.3 tunneling in Split MAC mode Since Split MAC implies AC supports 802.11, why require 802.3 frame formats? Can have broad implications to the protocol Issue 90: Using 802.3 for tunneling in Split-MAC mode

18. The current protocol assumes that the WTP and AC firmware are in lockstep The protocol requires that the WTP decide when it is to download new firmware David has raised an issue whereby be believes the AC should trigger the firmware download I believe the WTP is in better position to know about its firmware management strategy, and loosens the implied binding between AC and WTP vendors. Issue 126: Wrong place for "Image data" state

19. Shall the CAPWAP protocol support 802.11 encryption/decryption at either the WTP or the AC? (CAPWAP -00, -01, and -02 support 802.11 encryption/decryption at either the WTP or AC) Arguments in favor (no change to – 00, 01, 02): Provide architectural flexibility to meet application needs, e.g. Support of strong AES/CCMP encryption, even with WTPs that are only TKIP capable; in general, need only upgrade the client and AC crypto capabilities. Meet needs of WTPs deployed in “hostile environments”, e.g. meet DoD Directive 8100.2, “encryption for unclassified data in transit via WLAN-enabled devices, systems, and technologies must be implemented end-to-end over an assured channel and be validated by NIST as meeting requirements per FIPS 140-2 Overall Level 1 at a minimum. If WLAN infrastructure devices which store keying information are used in public unprotected environments, then those products must meet FIPS 140-2 Overall Level 2”.When encryption and security functions are performed at the AC; no encryption keys are distributed to the WTPs. Centralized encryption at the AC eliminates the need to FIPS-validate the access points and the control channel between the access points and the mobility controller. When 802.11 encryption is performed at the WTP, the WTP must go through the FIPS validation process, increasing both the costs and time to market for using Commercial Off-The-Shelf (COTS) technology within the Federal marketplace. Issue 138: CAPWAP Protocol WTP/AC Encryption Support

20. Shall the CAPWAP protocol support 802.11 encryption/decryption at either the WTP or the AC? (CAPWAP -00, -01, and -02 support 802.11 encryption/decryption at either the WTP or AC) Arguments in favor (no change to – 00, 01, 02): Meet CAPWAP Protocol Goal #1: “The AC may also provide centralized bridging, forwarding, and encryption of user traffic. Centralization of these functions will enable reduced cost and higher efficiency by applying the capabilities of network processing silicon to the wireless network, as in wired LANs.” 802.11i and DTLS crypto functions serve separate, distinct purposes; keep them separate Supports 802.11e EDCA, HCCA required functions Minimal additional complexity for significant architectural flexibility Arguments against: e.g. Support encryption only at the AC No one is proposing this, it would prevent the local MAC mode Arguments against: e.g. Support encryption only at the WTP – see next slides Issue 138: CAPWAP Protocol WTP/AC Encryption Support-2

21. 802.11i Encryption in AC • The CAPWAP protocol already has too many optional features • We currently have two optional crypto modes on the data plane; 802.11i and DTLS • I am worried about interoperability between WTPs and ACs

22. 802.11i Provides privacy and authentication of 802.11 payload Does not secure the CAPWAP header Breaks some 802.11 features (see next slide) DTLS Already present on AC and WTP (needed for control plane) Supports any CAPWAP binding Protects payload and CAPWAP header Two crypto modes

23. 802.11e Encryption needs to occur prior to fragmentation Fragmentation to support a service period required for HCCA AC does not have access to RF conditions and cannot perform this function WTP MUST trust STA marking, and cannot drop packets that invalidate the TSPEC (especially important in WAN cases). 802.11n A-MSDU Aggregation requires encryption after aggregation function A-MSDU Aggregation is required to achieve high data rates AC does not buffer packets to WTP AC is not in a position to know what’s in the WTP’s queue What breaks with 802.11i in AC

24. Identifying the threat is useful in understanding our requirements Malicious user gains access to wire and snoops traffic Protected via both 802.11i and DTLS Malicious user injects packets Protected via both 802.11i and DTLS Malicious user modifies CAPWAP header Protected via DTLS only What is the security threat?

25. Proposed Change