Topic #1 & #5 “All that has to do with header formats” Pat R. Calhoun

Issue 227 Problem Statement As discussed on the list, the issue is: During the initialization a session, the AC doesn’t have a simple way to differentiate CAPWAP Discovery Requests from DTLS packets Several alternatives were discussed, including: Reserving fixed fields within CAPWAP to ensure differentiation with DTLS Adding mandatory DTLS header padded with zeroes (which would signify an invalid DTLS header).

Proposed Resolution Agreed upon resolution on the list was to require a fixed header prior to DTLS header Not present in Discovery Packets DTLS Header UDP CAPWAP Pre-Header CAPWAP Header CAPWAP Payload Dictates header that follows

Proposed Resolution The group also agreed that consistency in packet formats was desirable Therefore, the pre-header was used with data packets as well Encryption (or not) would be available in the pre-header, although local policy needs to be enforced Also addresses issue 224 and 89

Proposal #1 Pre-Header format proposed by Scott Kelly: +------------+------------+------------+------------+-------- | Version | Tunnel ID | Type | Payload Version field is used to provide protocol extensibility The Tunnel ID field, which is equivalent to a DTLS Session Identifier, is used for QoS purposes (topic addressed by Mani) Type would indicate the contents of the payload field: 0x1 – Clear Text CAPWAP Control Packet 0x2 – Clear Text CAPWAP Data Packet 0x3 – DTLS Encrypted Control Packet 0x4 – DTLS Encrypted Data Packet

Proposal #1 (cont) This last proposal is a merge of both proposals one and two, which eliminates the need for a second version field: 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| Tunnel ID | Type | | (optional) DTLS Header | |Version| RID | HLEN | WBID |F|L|D|W|M|T| Flags | | RID | HLEN | WBID |F|L|D|W|M|T| Flags | | Fragment ID | Frag Offset |Rsvd | | Session ID | | (optional) Radio MAC Address | | Payload .... | Issue is created because two version fields exist, and whether they have a relationship.

Proposal #2 This alternative proposal exposes part of the CAPWAP header, but only has a single Version field: 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 |F|L|D|W|M|T| Flags | | Fragment ID | Frag Offset |Rsvd | | Session ID | | (optional) DTLS Specific Information | | (optional) Wireless Specific Information | | (optional) Radio MAC Address | | Payload .... | Where DTLS Specific Info has the following format: | Length | Tunnel ID | DTLS Header

Proposal #3 (Pat’s Preference) This last proposal is a merge of both proposals one and two, and similar to the proposal in issue 137, which eliminates the need for a second version field: 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| Tunnel ID | Type | | (optional) DTLS Header | | RID | HLEN | WBID |F|L|D|W|M|T| Flags | | Fragment ID | Frag Offset |Rsvd | | Session ID | | (optional) Radio MAC Address | | Payload .... | Type field has the same values as shown in proposal one (1) Note Issue 137 also inclusome additional document formatting requests, which are editorial in nature and not required

Issue 127: Use of SESSION ID The Session ID is necessary in order to bind the control and data plane The binding is necessary to support NAT gateways, where multiple WTPs may appear behind a single IP Address

Proposal 168 Requested the removal of the Session ID, which is needed for NAT support

Control Message Format Proposal The proposal simply removes the Time Stamp field, which has not found any usefulness (initially requested by David Perkins, yet removed in his proposals 137 and 146): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | | Seq Num | Msg Element Length | Flags | | Time Stamp | | Msg Element [0..N] ... +-+-+-+-+-+-+-+-+-+-+-+-+ TO:

Control Message Format Proposal (partially from Issue 137) Components not adopted Introduction of Sequence Number field (which he removed in his subsequent issue 146) Introduction of reserved field (was used for padding – not required) Introduction of ‘F’ bit (first packet). This is unnecessary because both ends need to know what packets they’ve received Introduction of Length field. Unnecessary since this is derived from outer headers

Proposal 146 Introduces a separate CAPWAP Fragmentation Header which is not adopted Complicates the packet format (nothing wrong with the current proposal) Some text could be useful (mostly editorial) Additional re-ordering of fields not adopted

Proposal 217 The specification is not clear on what 802.11 fields are to be present If 802.11i encryption is provided on the AC, the frame format contains the necessary fields If 802.11i encryption terminates in the WTP, should the AC add padded fields for the necessary security? Yes, since this is how most chipsets work today TKIP would include the necessary header format The Checksum is not present since it may be removed by the 802.11 chip

Proposal 221 The CAPWAP protocol supports the use of DTLS on the data plane, but has no way to signal from AC to WTP New AC Descriptor 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stations | Limit | | Active WTPs | Max WTPs | | Security | R-MAC Field |Wireless Field | DTLS Policy | The DTLS Policy field supports on the following values: 0x0: DTLS does not need to be applied on the data channel 0x1: DTLS needs to be applied on the data channel

Side Issue The CAPWAP protocol does not specify a DTLS version In order to guarantee interoperability, a version MUST be mandated