1 / 16

Topic #1 & #5 “All that has to do with header formats”

This proposal suggests a fixed header format to differentiate CAPWAP Discovery Requests from DTLS packets, ensuring consistency in packet formats. Three alternative proposals are outlined to address the issue of multiple version fields and their relationship.

phinze
Download Presentation

Topic #1 & #5 “All that has to do with header formats”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Issue 227Problem 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).

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

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

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

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

  7. 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: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Tunnel ID | DTLS Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

  11. 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: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Element [0..N] ... +-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

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

More Related