July 2006
July 2006 pcalhoun@cisco.com
mmontemurro@rim.com
dstanley@arubanetworks.com

July 2006
1.
Highlights from -02 Issue Resolution
2.
Schedule for -03, -04, completion of CAPWAP protocol specification V1.0
3.
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 2006
•
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 2006
•
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 2006
•
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 2006
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 2006
• 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 2006
• 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 2006
• 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
• Defined binding-specific message type using
IANA Enterprise number.
• Partition Message Elements for technologyspecific 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
•
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 market
3.
Arguments against:
•
Support of draft amendments requires selecting a specific draft,
“standardizing” on that draft, and essentially has the IETF specifying a nonstandard 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 -06
2. Have been trying to accommodate as many proposed changes, issues as possible
3. Need to start deferring work into -bis/V2.0
4. Define requirements on next CAPWAP protocol version
5. Need to start saying “No” to proposed additions, need criteria for this

July 2006
Issue 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 2006
• 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 2006
• 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
• The CAPWAP protocol already has too many optional features
Split MAC
• We currently have two optional crypto modes on the data plane;
802.11i and DTLS
Local MAC
• I am worried about interoperability between WTPs and ACs
DTLS on Data
Channel
No DTLS on
Data Channel
DTLS on Data
Channel
No DTLS on
Data Channel
802.11i Crypto in WTP
802.11i Crypto in AC
802.11i Crypto in WTP
802.11i Crypto in AC
No Tunnel
802.3 Tunnel
No Tunnel
802.3 Tunnel

July 2006
• 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 2006
• 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 2006
• 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
Split MAC
Local MAC
DTLS on Data Channel
No DTLS on Data Channel
DTLS on Data Channel
No DTLS on Data Channel
802.11 Payload
802.11 Payload
No Tunnel
802.3 Tunnel
No Tunnel
802.3 Tunnel