CAPWAP Protocol Specification Editors' Report

1
CAPWAP Protocol Specification Editors' Report

• July 2006
• pcalhoun_at_cisco.com
• mmontemurro_at_rim.com
• dstanley_at_arubanetworks.com

2
Editors Report Agenda

• 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

3
Issues 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

4
Issues 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

5
Issues covered in CAPWAP-02

• Issue 77 Added Local MAC to the document's
  introduction section
• Issue 120New 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

6
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

7
Issues 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 TFLWM
  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.

8
Issue 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.

9
Issue 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

10
Issue 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
11
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)

12
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

13
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

14
IEEE 802.11 Binding Scope

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

15
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

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

17
Issue 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

18
Issue 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.

19
Issue 138 CAPWAP Protocol WTP/AC Encryption
Support

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

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

• 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

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

Split MAC DTLS on Data Channel 802.11i Crypto in WTP
Split MAC DTLS on Data Channel 802.11i Crypto in AC
Split MAC No DTLS on Data Channel 802.11i Crypto in WTP
Split MAC No DTLS on Data Channel 802.11i Crypto in AC
Local MAC DTLS on Data Channel No Tunnel
Local MAC DTLS on Data Channel 802.3 Tunnel
Local MAC No DTLS on Data Channel No Tunnel
Local MAC No DTLS on Data Channel 802.3 Tunnel
22
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

23
What 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 whats in the
  WTPs queue

24
What 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

25
Proposed Change
Split MAC DTLS on Data Channel 802.11 Payload
Split MAC No DTLS on Data Channel 802.11 Payload
Local MAC DTLS on Data Channel No Tunnel
Local MAC DTLS on Data Channel 802.3 Tunnel
Local MAC No DTLS on Data Channel No Tunnel
Local MAC No DTLS on Data Channel 802.3 Tunnel