March 2007 CAPWAP Protocol Specification Editors' Report March 2007 [email protected]...

March 2007

CAPWAP Protocol Specification Editors' Report

March 2007

[email protected]

[email protected]

[email protected]

March 2007

Editors’ Report Agenda

1. Highlights from -05/-02 issue resolution

2. Discussion of new issues raised since publication of -05/-02

3. Discussion of issues in “wish” category

4. Schedule for -06, -03, completion of CAPWAP protocol specification V1.0

March 2007

Issue Resolutions in -05, -02• Issue 148 – “Scan Results” - Deferred to Wish list

– Defer to a future version of the CAPWAP IEEE 802.11 binding document. Reports of Scan results are being incorporated in the IEEE 802.11k Beacon report, which is in the process of being standardized.

• Issue 152 – “Which Message Elements can be repeated”– Message definitions indicate if multiple of a message element can be included (1 is

default)• Issue 153 – Can additional message elements be added to a message

– 4.4.1.5: When a WTP or AC receives a CAPWAP message without a message element that is specified as mandatory for the CAPWAP message, then the CAPWAP message is discarded. If the received message was a request message for which the corresponding response message carries message elements, then a corresponding response message with a Result Code of "Failure - Missing Mandatory Message Element“ is returned to the sender.

When a WTP or AC receives a CAPWAP message with a message element that the WTP or AC does not recognize, the CAPWAP message is discarded. If the received message was a request message for which the corresponding response message carries message elements, then a corresponding response message with a Result Code of "Failure - Unknown Message Element" and one or more Returned Message Element message elements is included, containing the unrecognized message element (s).

March 2007

Issue Resolutions in -05, -02• Issue 173 - What happens when a message does not fit within a CAPWAP

frame– Section 4: A CAPWAP implementation MUST be capable of receiving a reassembled

CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY indicate that it supports a higher maximum message length, by including the Maximum Message Length message element, see Section 4.5.29, in the Join Request message or the Join Response message.

– 4.5.29. Maximum Message Length

The Maximum Message Length message element value is used by the AC to inform the WTP and by the WTP to inform the AC of the maximum CAPWAP message length that ii can receive.

0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Max Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type: 29 for Maximum Message Length Length: 2 Maximum Mesage Length: An 16-bit unsigned integer indicating the maximum message

length

March 2007

Issue Resolutions in -05, -02

• Issue 207 – Addition of WLAN definition – WLAN: In this document, WLAN refers to a logical component

instantiated on a WTP device.A single physical WTP may operate a number of WLANs. Each Basic Service Set Identifier (BSSID) and its constituent wireless terminal radios is denoted as a distinct WLAN on a physical WTP.

• Significant editorial read-abililty, consistency and grammar clean-up

• Addition of Acknowledgements text to 02

March 2007

Pat: Issues Resolved in -05/-02• 90: Using 802.3 for tunnelling in Split-MAC mode• 122: Editorial Issues in CAPWAP-01 • 146: Updated proposal for packet formats • 149: IPv6 Multicast address for Discovery phase • 159: Operations should have listed in which states they are applicable • 190: Issues with configuration update response • 191: Clear Config Request. this operation has several problems • 194: Handling duplicate IPV4 addresses • 218: Static IP Address message element is a MUST• 219: Insufficient description of WTPs during discovery • 223: Description of RID field is unclear • 226: Transition to join state • 227: Need Shim Header to indicate crypto property of packet • 229: DTLSMtuUpdate undefined • 231: Need clarifications on Image Data Transfer • 239: Protocol Header and command Extensibility • 234: Join Request is missing message elements • 235: Join to Image Data State is broken • 236: retransmission of DTLS encrypted control packets • 237: Changes to firmware download process • 240: Discovery Attack on established DTLS session • 242: Some editorial feedback on draft 04 • 243: Radio Administrative and Operational state • 245: State machine timeouts

March 2007 Resolved Issue 227:Indicating crypto properties of a packet

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| Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version: A 4 bit field which contains the version of CAPWAP used in this packet. The value for this draft is zero (0). Payload Type: A 4 bit field which specifies the payload type that follows the preamble header. The following values are supported: 0 - Clear text. If the packet is received on the data UDP port, the CAPWAP stack MUST treat this as a clear text CAPWAP data packet. If received on the control UDP port, the CAPWAP stack MUST treat this as a clear text CAPWAP control packet. If the control packet is not a Discovery Request or Response packet, it is illegal and MUST be dropped. 1 - DTLS Payload. The packet is either a DTLS packet and MAY be a data or control packet, based on the UDP port it was received on (see section Section 3.1).

March 2007 Resolved Issue 236:retransmission of DTLSencrypted control packets

Issue: An issue was raised at the January Interim meeting that some guidance needs to be provided on how to handle the retransmission of CAPWAP Control packets encrypted using DTLS.

If the response was lost, the peer would drop the request as being a replay. In order to avoid this problem, requests need to be re-encrypted.

While fixing this issue, I found there was no guidance provided on retransmissions in general, and created a new section.


4.4.3. Retransmissions

The CAPWAP control protocol operates as a reliable transport. For each request message, a response exists, which is used to acknowledge receipt of the request. Further, the control header's sequence number is used to pair the request and response messages (see section Section 4.4.1).

Response messages are not explicitly acknowledged, therefore if it was not received, the original request would be retransmitted. Implementations MAY cache response messages in order to be able to respond to a retransmitted request with minimal local processing. Therefore, retransmitted requests MUST NOT be altered by the sender, as it MUST assume that the original request was processed, but the response was lost in the network. Any alterations to the original request MUST have a new sequence number, and is treated as a new request by the receiver.


After transmitting a request message, the RetransmitInterval (see section Section 4.6) timer and MaxRetransmit (see section Section 4.7) variable are used in order to determine whether the original request needs to be retransmitted. Response messages are not subjected to these timers.

When a request is retransmitted, it MUST be re-encrypted via the DTLS stack. The reason being that if the peer had received the request, but the corresponding response had been lost, it is necessary to ensure that retransmitted requests are not identified as replays by the DTLS stack. Similarly, any cached responses that are retransmitted as a result of receiving a previously received request MUST be re-encrypted via DTLS.

Duplicate response, identified by the Sequence Number field in the CAPWAP control message header, SHOULD be discarded upon receipt.

March 2007 Resolved Issue 226:Transition to join state

• This issue covers the interactions between the CAPWAP and DTLS protocols.

• Version -04 included text for which rough consensus hadn’t been reached, but was included for the interim meeting

March 2007 Resolved Issue 226:State Machine in -04

/===================>=====================================\ " /=================<=================================\ " " " /==============<=============================\ " " " " " /===========<=========\ " " " " " " " n4,n5,n6" n8" n3" v " " " " +-----------+ +--------------+ +----------+ " " " " | DTLS Idle | | DTLS Setup | | DTLS Run | " " " " +-----------+ +--------------+ +----------+ " " " " ^ "n1 ^c4 ^ ^ "n2 c3^ n7" ^ " " " " " " " " " " " " " DTLS "~"~~"~~"~~~"~~~"~~~~~"~~~~~~"~~"~~~~~~~~~"~~~~~~~"~~~~"~~"~~~~~~~~ " " " " " " \======"=="=======\ " /====/ " " CAPWAP ^ v v v " " " " " " " " " " " " " " " /=======/ " " " " " " " " " " " " " " " " " " " " " " " "c1 v "c2 d "c2 " v " " " " " " \=>+------------+ +------+ +------+ " " " " " | Idle |-->| Disc | | Auth | " " " " \====>+------------+ a +------+ +------+ " " " " b| ^ |d /==================/ " " " | | | " /-----------------"----\ " " v f| /----/ v r| "c5 | " " +---------+ | +----------+ s +------------+ | " " | Sulking |<=/ | Run |-->| Reset | | " " +---------+ +----------+ +------------+ | " " q ^ ^ ^ | " " | /-----/ | | " " p| k| j |m v " \========>+--------------+ +-----------+ +------------+ " c5| Join |---->| Configure |---->| Image Data | \===========+--------------+ g +-----------+ h +------------+

March 2007 Resolved Issue 226:New State Machine in -05

/-------------------------\ w| | 5+----------+ x +------------+ | | Run |-->| Reset |-\| +----------+ +------------+ || u ^ ^ ^ y|| +------------+--------/ | | || | Data Check | /-------/ | || +------------+<-------\ | | || t| s| 4 o| || +--------+ +-----------+ +--------------+|| | Join |---->| Configure |---->| Image Data ||| +--------+ q +-----------+ r +--------------+|| ^ p| V| x| || | | \-------------------\ | || | \--------------------------------------\| | || \------------------------\ || | || /--------------<----------------+--------------\ || | || | /------------<-------------\ | | || | || | | m| |n z| vv v vv | | +----------------+ +--------------+ +-----------+ | | | DTLS Setup | | DTLS Connect | | DTLS TD | | | +----------------+ +--------------+ +-----------+ | | g| ^ ^ |h ^ ^ v v | | | | | | | | | | | \-------\ | /-----------/ | | | | | | | | | | v |e f| 2 v |j |k | \->+------+ +------+ +-----------+ | | Idle |-->| Disc | | Authorize | \--->+------+ a +------+ +-----------+ b| ^ |c | | /----/ v d| | +---------+ | | Sulking |<-/ 3 +---------+

March 2007

Goals for CAPWAP-06, binding-03

• Incorporate additional text changes, including mailing list, editorial resolutions and resolutions for– 250 – Clarification on DTLS Rehandshake DTLSPeerAuthorize

DTLSIncomingSession – 249 – IPv6 UDP Lite– 248 - BothIPv4 and IPv6 addresses not required – 247 - MAC Addresses can be larger than 6 octets– 246 - Data IP Address message element is missing – 217 - What is frame format when WTP encrypts/decrypts – 138 - Support and negotiation of WTP data encryption in the

CAPWAP protocol

• Please see descriptions at www.capwap.org for details

March 2007 New Issue 217:What is frame format when WTP encrypts/decrypts

• Issue: The -01 IEEE 802.11 binding document did not properly describe which fields in the 802.11 header are handled by the WTP and/or the AC.

• There was an agreed upon fix on the list, but the change was not applied to -02.

• Question: Is there any disagreement that this change needs to be made to the -03 draft?

March 2007 New Issue 246:Data IP Address message element is missing

• Issue: NAT Considerations text refers to “Data IP Address message element “, which is not defined in the CAPWAP Spec. The offending text was removed from -05 for now.

• RFC 4564 (CAPWAP Objectives) states:5.1.2. Support for Traffic Separation Protocol Requirement: The CAPWAP protocol MUST define transport

control messages such that the transport of control messages is separate from the transport of data messages.

• The Data IP Address message element allows the control and data CAPWAP packets to be sent to a separate AC IP Address

• Question: Is this a desired CAPWAP feature? The change is very minor, should we make the change?

March 2007 New Issue 247:MAC Addresses can be larger than 6 octets

• Issue: CAPWAP is intended to be flexible to support other wireless technologies

• IEEE 802.16 now utilizes a 8 octet MAC Address• Question: Should the base protocol be modified to

support the extended address space?• Question: If yes, should the field be variable in

length, or static length covering worst case 8 which is either zero padded, if necessary, or has a valid address length byte?

March 2007 New Issue 248:Both IPv4 and IPv6 addresses not required

• Issue: The Primary Discovery Response and Join Response messages require the presence of both the CAPWAP Control IPv4 Address and CAPWAP Control IPv6 address message elements

• This error was fixed in the Discovery Response in the -05 draft, but the changes were not applied to the other messages


March 2007 New Issue 249: IPv6 UDP Lite

• Issue: When UDP is run over IPv4, the checksum field may be set to zero (0). When run over IPv6, the checksum field MUST NOT be set to zero.

• The cost of computing the checksum, at line rate, can significantly impact AC performance

• Proposal is to utilize UDP-Lite (RFC3828), which does not require a full checksum

• Question: Do we allow or mandate the use of UDP-Lite?

• Question: If yes, is it restricted to IPv6 (vs. IPv4)?– NAT systems do not recognize UDP-Lite, and there are no

IPv6 NATs deployed today.

March 2007 New Issue 250:Clarification on

DTLSRehandshake/DTLSPeerAuthorize/DTLSIncomingSession

• Issue: Issue 226 introduced some text that has issues

1. Section 4.6.5. has references to DTLSRehandshake, when rehandshake was removed as a feature.

2. State machine has references to DTLSPeerAuthorize, which is missing in Section 2.3.2.2.

3. DTLSIncomingSession is defined in Section 2.3.2.2, but the state machine does not reference it.


March 2007

“Wish” Issues• 75: recommend LWAPP add a new notification message "Gratuitous disconnect notification"

– Proposed Reject: No obvious real need for WTP sending an explicit “Im leaving” message• 79: Handover issue with CAPWAP

– Proposed Reject: Significant departure from current WG charter• 112: MTU Discovery

– Proposed Resolved: Handled via issue 173• 148: Binding element for scanning report

– Proposed Defer: Wait until IEEE 802.11k is ratified• 161: The term "Mobile" is not really accurate

– Propose Resolved: Editors have been using Station• 205: Rogue AP Detection

– Proposed Reject: Use existing mechanisms in IEEE 802.11k , when available• 206: Common MIB Statistics

– Proposed Reject: Applicable to MIB document – out of scope for CAPWAP base• 230: crypto algorithms for DTLS

– Proposed Defer: Wait for DTLS to support AES-GCM/GMAC• 244: preamble header optimization

– Proposed Reject: Reserved field provides flexibility. May want to use the field for QoS purposes in the future

March 2007

Publication History • Feb 25th, 2006 – revision 00 published• May 5th, 2006 –publish revision 01• June 24th, 2006 – publish revision 02• July 10th, 2006 – IETF meeting – review plans for revision-03• October 13th, 2006 – publish revision-03, 00 (binding)• November 6th, 2006 – IETF Meeting – review plans for next revision• January 23rd, 2007 – publish revision 04, 01 in advance of ad-hoc• March 4th, 2007 – publish revision 05, 02• March 19th, 2007– IETF Meeting – review plans for next revision

– Which version going to WG Last Call? IEEE Review?– Plans for -06/-03

March 2007 CAPWAP Protocol Specification Editors' Report March 2007 [email protected]...

Documents

Transcript of March 2007 CAPWAP Protocol Specification Editors' Report March 2007 [email protected]...