July 2006

CAPWAP Protocol Specification Editors' Report

July 2006

pcalhoun@cisco.com mmontemurro@rim.com

dstanley@arubanetworks.com

July 2006

Editors’ Report Agenda1. Highlights from -02 Issue Resolution2. Schedule for -03, -04, completion of CAPWAP

protocol specification V1.03. 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

July 2006Issues covered in CAPWAP-02

• 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

July 2006Issues covered in CAPWAP-02

• 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

July 2006Issues covered in CAPWAP-02

• 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

July 2006

Highlights from -02 Issue Resolution 1. Resolved issue # 2 – Incorporate DTLS into CAPWAP

protocol, replacing proprietary LWAPP mechanism. Largely complete. Open new issues for any further changes.

2. Resolved issue # 124, structural message element changes. Believe that the document is easier to read, easier to find message element definitions.

3. Resolved Issue # 84 – Added WTP Statistics and (non) piggybacking of statistics in Echo messages

July 2006Issues 120 & 119 (Header Format)

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.

July 2006Issue 66: Unclear how Clear Config Indication is acknowledged

• 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.

July 2006Issue 18: use MIB variable names instead

• 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:

July 2006Issue 116: Encryption Policy should use RSNA IE

• 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”The CAPWAP protocol now relies more on 802.11 IEs instead of

recreating new message elements

July 2006 Issue 76 – Wireless Technology Binding

• Defined binding-specific message type using IANA Enterprise number.

• Partition Message Elements for technology-specific binding (fixed in CAPWAP-02)

July 2006

Schedule • 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

July 2006

Issues to discuss• 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

July 2006

IEEE 802.11 Binding Scope

1. Shall unapproved 802.11 amendments (e.g. 802.11n, 802.11r, etc) be supported in the initial CAPWAP protocol IEEE 802.11 binding?

2. 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 market3. 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.

July 2006

Raising the Bar on New Issues

1. Goal is to finish CAPWAP V1.0 in -062. Have been trying to accommodate as many

proposed changes, issues as possible3. Need to start deferring work into -bis/V2.04. Define requirements on next CAPWAP

protocol version5. Need to start saying “No” to proposed

additions, need criteria for this

July 2006Issue 43 – IEEE 802.11i Considerations

• 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.

July 2006Issue 90: Using 802.3 for tunneling in Split-MAC mode

• 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

July 2006Issue 126: Wrong place for "Image data" state

• 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.

July 2006

Issue 138: CAPWAP Protocol WTP/AC Encryption Support

1. 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)

2. 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.

July 2006

Issue 138: CAPWAP Protocol WTP/AC Encryption Support-2

1. 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)

2. 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

3. Arguments against: e.g. Support encryption only at the AC• No one is proposing this, it would prevent the local MAC mode

4. Arguments against: e.g. Support encryption only at the WTP – see next slides

July 2006 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

Split MAC DTLS on Data Channel

802.11i Crypto in WTP

802.11i Crypto in AC

No DTLS on Data Channel

802.11i Crypto in WTP

802.11i Crypto in AC

Local MAC DTLS on Data Channel

No Tunnel

802.3 Tunnel

No DTLS on Data Channel

No Tunnel

802.3 Tunnel

July 2006 Two crypto modes

• 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

July 2006What breaks with 802.11i in AC

• 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

July 2006What is the security threat?

• 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

July 2006 Proposed Change

Split MAC DTLS on Data Channel 802.11 Payload

No DTLS on Data Channel 802.11 Payload

Local MAC DTLS on Data Channel No Tunnel

802.3 Tunnel

No DTLS on Data Channel No Tunnel

802.3 Tunnel