CAPWAP Protocol Specification Editors' Report

CAPWAP Protocol Specification Editors' Report March 2007 pcalhoun@cisco.com mmontemurro@rim.com dstanley@arubanetworks.com

Highlights from -05/-02 issue resolution Discussion of new issues raised since publication of -05/-02 Discussion of issues in “wish” category Schedule for -06, -03, completion of CAPWAP protocol specification V1.0 Editors’ Report Agenda

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). 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 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 Issue Resolutions 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 Pat: Issues Resolved in -05/-02

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). Resolved Issue 227:Indicating crypto properties of a packet

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. Resolved Issue 236:retransmission of DTLSencrypted control packets

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. Resolved Issue 236:retransmission of DTLSencrypted control packets

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. Resolved Issue 236:retransmission of DTLSencrypted control packets

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 Resolved Issue 226:Transition to join state

/===================>=====================================\ " /=================<=================================\ " " " /==============<=============================\ " " " " " /===========<=========\ " " " " " " " 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 +------------+ Resolved Issue 226:State Machine in -04

/-------------------------\ 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 +---------+ Resolved Issue 226:New State Machine in -05

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 Goals for CAPWAP-06, binding-03

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? New Issue 217:What is frame format when WTP encrypts/decrypts

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? New Issue 246:Data IP Address message element is missing

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? New Issue 247:MAC Addresses can be larger than 6 octets

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 Question: Is there any disagreement that this change needs to be made to the -06 draft? New Issue 248:Both IPv4 and IPv6 addresses not required

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. New Issue 249: IPv6 UDP Lite

Issue: Issue 226 introduced some text that has issues Section 4.6.5. has references to DTLSRehandshake, when rehandshake was removed as a feature. State machine has references to DTLSPeerAuthorize, which is missing in Section 2.3.2.2. DTLSIncomingSession is defined in Section 2.3.2.2, but the state machine does not reference it. Question: Is there any disagreement that this change needs to be made to the -03 draft? New Issue 250:Clarification on DTLSRehandshake/DTLSPeerAuthorize/DTLSIncomingSession

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 “Wish” Issues

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 Publication History

CAPWAP Protocol Specification Editors' Report