March 2007 CAPWAP Protocol Specification Editors' Report March

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 binding document. Reports of Scan results are being incorporated in the IEEE k 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 – : 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 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 , in the Join Request message or the Join Response message. – 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 | 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 for tunnelling in Split-MAC modeUsing for tunnelling in Split-MAC mode 122: Editorial Issues in CAPWAP-01Editorial Issues in CAPWAP : Updated proposal for packet formatsUpdated proposal for packet formats 149: IPv6 Multicast address for Discovery phaseIPv6 Multicast address for Discovery phase 159: Operations should have listed in which states they are applicableOperations should have listed in which states they are applicable 190: Issues with configuration update responseIssues with configuration update response 191: Clear Config Request. this operation has several problemsClear Config Request. this operation has several problems 194: Handling duplicate IPV4 addressesHandling duplicate IPV4 addresses 218: Static IP Address message element is a MUSTStatic IP Address message element is a MUST 219: Insufficient description of WTPs during discoveryInsufficient description of WTPs during discovery 223: Description of RID field is unclearDescription of RID field is unclear 226: Transition to join stateTransition to join state 227: Need Shim Header to indicate crypto property of packetNeed Shim Header to indicate crypto property of packet 229: DTLSMtuUpdate undefinedDTLSMtuUpdate undefined 231: Need clarifications on Image Data TransferNeed clarifications on Image Data Transfer 239: Protocol Header and command ExtensibilityProtocol Header and command Extensibility 234: Join Request is missing message elementsJoin Request is missing message elements 235: Join to Image Data State is brokenJoin to Image Data State is broken 236: retransmission of DTLS encrypted control packetsretransmission of DTLS encrypted control packets 237: Changes to firmware download processChanges to firmware download process 240: Discovery Attack on established DTLS sessionDiscovery Attack on established DTLS session 242: Some editorial feedback on draft 04Some editorial feedback on draft : Radio Administrative and Operational stateRadio Administrative and Operational state 245: State machine timeoutsState machine timeouts

March 2007 Resolved Issue 227: Indicating crypto properties of a packet |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 227: CAPWAP Packet Formats CAPWAP Control Packet (Discovery Request/Response): | IP | UDP | CAPWAP |CAPWAP | Control | Message | | Hdr | Hdr | p-amble|Header | Header | Element(s) | DTLS Encrypted CAPWAP Control Packet: | IP | UDP | CAPWAP | DTLS | CAPWAP | Control | Message | DTLS | | Hdr | Hdr | p-amble| Hdr | Header | Header | Element(s) | Trlr | \ authenticated / \ encrypted / CAPWAP Plain Text Data Packet : | IP | UDP | CAPWAP | CAPWAP | Wireless | | Hdr | Hdr | p-amble| Header | Payload | DTLS Secured CAPWAP Data Packet: | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | | Hdr | Hdr | p-amble| Hdr | Hdr | Payload | Trlr | \----- authenticated -----/ \ encrypted /

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.

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

March 2007 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.

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 | | 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| | 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 |<-/

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 for detailswww.capwap.org

March 2007 New Issue 217: What is frame format when WTP encrypts/decrypts Issue: The -01 IEEE binding document did not properly describe which fields in the 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: 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 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 Question: Is there any disagreement that this change needs to be made to the -06 draft?

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 has references to DTLSRehandshake, when rehandshake was removed as a feature. 2.State machine has references to DTLSPeerAuthorize, which is missing in Section DTLSIncomingSession is defined in Section , but the state machine does not reference it. Question: Is there any disagreement that this change needs to be made to the -03 draft?

March 2007 “Wish” Issues 75: recommend LWAPP add a new notification message "Gratuitous disconnect notification"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 CAPWAPHandover issue with CAPWAP –Proposed Reject: Significant departure from current WG charter 112: MTU DiscoveryMTU Discovery –Proposed Resolved: Handled via issue : Binding element for scanning reportBinding element for scanning report –Proposed Defer: Wait until IEEE k is ratified 161: The term "Mobile" is not really accurateThe term "Mobile" is not really accurate –Propose Resolved: Editors have been using Station 205: Rogue AP DetectionRogue AP Detection –Proposed Reject: Use existing mechanisms in IEEE k, when available 206: Common MIB StatisticsCommon MIB Statistics –Proposed Reject: Applicable to MIB document – out of scope for CAPWAP base 230: crypto algorithms for DTLScrypto algorithms for DTLS –Proposed Defer: Wait for DTLS to support AES-GCM/GMAC 244: preamble header optimizationpreamble 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 25 th, 2006 – revision 00 published May 5 th, 2006 –publish revision 01 June 24 th, 2006 – publish revision 02 July 10 th, 2006 – IETF meeting – review plans for revision-03 October 13 th, 2006 – publish revision-03, 00 (binding) November 6 th, 2006 – IETF Meeting – review plans for next revision January 23 rd, 2007 – publish revision 04, 01 in advance of ad-hoc March 4 th, 2007 – publish revision 05, 02 March 19 th, 2007– IETF Meeting – review plans for next revision –Which version going to WG Last Call? IEEE Review? –Plans for -06/-03