CAPWAP Editor’s Report Pat R. Calhoun Cisco Systems, Inc.

Closed Issues

Issue 2: Potential Firmware Download Performance Issue Raised by Transport AD, claiming that current protocol could cause firmware download to take some time. Added the following text to Transport Considerations: “The lock step nature of the CAPWAP protocol's control channel can cause the firmware download process to take some time, depending upon the RTT. This is not expected to be a problem since the CAPWAP protocol allows firmware to be downloaded while the WTP provides service to wireless clients/devices.”

Issue 4: Potential Middlebox Issues Raised by Transport AD, claiming that CAPWAP must be capable of working through middleboxes The Data Channel KeepAlive ensures the data plane is kept fresh on the middlebox. This is sent every 30 seconds, via the DataChannelKeepAlive timer. The Control Channel Echo Request ensures the control plan is maintained. This is sent every 30 seconds, via the EchoInterval timer, if no activity has occurred on the control plane. Finally, Issue 5 (UDP-Lite) addresses any remaining middlebox issues

Issue 5: Proposed text for Benefits of Using UDP-Lite? Raised by Transport AD, asking why zero checksums were important –CAPWAP controllers handle data plane in hardware, and checksum is expensive –During the discussion, an agreement was made to make UDP-Lite optional Various changes to support issue: –CAPWAP Transport: IPv4 always uses UDP. IPv6 control plane uses UDP, while data plane default is UDP, but can use UDP-Lite –UDP-Lite checksum must have a coverage of 8

Issue 5: Proposed text for Benefits of Using UDP-Lite? More changes to support issue: –New message elements CAPWAP Transport Protocol: Used to negotiate UDP or UDP-Lite CAPWAP Local IPv4 Address: Used to determine whether IPv4 middlebox exists CAPWAP Local IPv6 Address: used to determine whether IPv6 middlebox exists –NAT Considerations text detailing: types of middleboxes, and how CAPWAP deals with each Protocol behavior when a middlebox was detected David Borman stated this was a good compromise on the list

Issue 18: CAPWAP and congestion control Raised by Transport AD, claiming lack of congestion control in data channel could cause collapse Agreed to include text in Transport Considerations on avoiding use of non- congestion controlled traffic: "Because there is no congestion control mechanism specified for the CAPWAP data channel, it is recommended that non-congestion-controlled traffic not be tunneled over CAPWAP. When a significant amount of non-congestion-controlled traffic is expected to be present on a WLAN, the CAPWAP connection between the AC and the WTP for that LAN should be configured to remain in Local MAC mode"

Issue 20: Use of NeighborDead timer with Echo The Echo Request message would use the NeighborDead timer to detect if the peer was no longer responding This makes no sense, since Echo Request messages are retransmitted as normal control packets Removed NeighborDead, and rely on existing reliable control channel transport

Miscellaneous changes Issue 6: Handling of multiple priority streams over DTLSin datapath was moved to deferred state Issue 15: DataChannelKeepAlive timer was undefined –Added timer, which causes Data Channel KeepAlive packet to be transmitted Issue 16: MAC Address fields were 9 bits –Changed to 8 bits Issue 17: File Size field was 16 bits, and did not specify the type of value. –Changed to 32 bits, and text now states the value is in bytes. Issue 21: CAPWAP Session Establishment Overview is incomplete –Added new message exchanges to figure to help provide more clarity

Issues Pending Approval

Issue 3: MTU Discovery Requirement Raised by Transport AD, claiming the CAPWAP protocol must define MTU discovery mechanism Various changes to support this issue was sent on 11/16: –Text in protocol overview to specify when MTU discovery is to be done –Specified DTLS DTLSMtuUpdate command uses path MTU –Instructions on how to configure DTLS MTU in DTLS Error Handling section –New section called “MTU Discovery”, which leverages RFCs 1191 (IPv4) and 1981 (IPv6) –Discovery Request message includes text on when to perform MTU discovery, and removes MTU Padding message element –Transport Considerations text outlining MTU discovery

Issue 19: Issue with Image Data to Reset AC State machine claims that AC resets session with WTP when last image packet is sent This breaks if WTP does not receive last packet from AC Two possible fixes were investigated: –Option 1: Create a uni-directional packet from the WTP, but this is not reliable, or –Option 2: Let the WTP reboot when it has completed the download, and let the AC clean its state when expiry occurs Option 2 was chosen on 11/16

Issue 22: Data Check has no timeout on AC Data Check state had no exit if WTP didn’t respond Caused the AC state to stay in Data Check until WTP rebooted and attempted to reconnect A few changes required to support this issue sent on 11/16: –Timer is set by AC when Configure to Data Check occurs –New state transition (Data Check to DTLS Teardown) added –Stop timer when Data Check to Run state transition occurs –Added new DataCheckTimer timer

Issue 23: Entering Image Data has no timeout The issue is that the AC needs a way to timeout if the WTP never initiates the firmware download A few changes required to support this issue sent on 11/16: –A new timer (ImageDataStartTimer) was defined –The AC enables the timer when it transitions between Join to Image Data –The AC stops the new timer if it was set when it –The AC transitions between Image Data to Reset if the timer expires

Issue 24: CAPWAP Header alignment Issue The CAPWAP header had alignment issues The WBID field had 4.5 bits in length, and the following fields were offset incorrectly Changed the WBID to 5 bits

Issue 25: ChangeStatePendingTimer clarification This issue was lost in the mailing list This issue points out that the AC will never time out after the join process if the WTP does not send a Configuration Status message This issue was a typo in the draft, where the following sentence: “The WTP also starts the ChangeStatePendingTimer timer (see Section 4.7).” Needs to be changed to: “The AC also starts the ChangeStatePendingTimer timer (see Section 4.7).”

Issue 27: capwap -07 spec comment This issue was lost in the mailing list The request is to change the following sentence: –" IEEE encapsulation requires that the bridging function be performed in the WTP to: –"IEEE encapsulation requires that for frames, the *Integration* function be performed in the WTP".

Issue 28: omissions in draft 08 The issue points to two ommisions in the draft: –1. The list of CAPWAP message elements on Page 52 of draft 08 is incomplete; elements are missing. Need to fix –2. The description of message element MTU Discovery Padding is missing. This was removed when the new MTU Discovery text was added

New Issues

Issue 26: Bidirectional data transfer Current spec defines Data Transfer Request messages to be sent by the WTP to the AC, essentially a “push” mechanism. This works well for remote troubleshooting. It is desirable to have a “pull” mechanism, allowing the AC to request information from the WTP. Typically used from the AC’s management interface. The request is to modify the data transfer to be bi-directional (supporting both "push" and "pull" model).

Issue 29: Vendor Specific Payloads A new issue was raised: –The CAPWAP spec defines the Vendor Specific Payload (VSP) –None of the CAPWAP messages state that the VSP is a permitted message element –The request to is add text to specify that the VSP can be present in any CAPWAP message. The draft already covers the expected behavior if a message is received with an unknown message element (discard CAPWAP message)

Issue 30: Inconsistent state tracking on AC prior to DTLSEstablishment The CAPWAP protocol makes the Discovery Request optional (state transitions ‘e’ and ‘f’) The text allows for an AC to maintain some state following the discovery process –This information is used to qualify the DTLSListen() –This could lead to a memory/table DoS attack Eliminating this issue does not eliminate DoS vulnerabilities –Restricting connection requests from certain peers can protect against CPU DoS attacks

Issue 30: Inconsistent state tracking on AC prior to DTLSEstablishment The AC state machine needs some clarification –Define the common “listener thread”, which handles state transitions up to (and optionally including) DTLS Connect –Define the “service thread”, which handles state transitions afterwards, and is specific to a given WTP Agreement –Charles is to add text to security considerations Discuss the threats to make implementers aware of the issues –Pat to modify state machine text

Issue 31: Peer Authorization is optional The current text states that the WTP and AC performs an optional peer authorization check Agreement is to make peer authorization mandatory –But include text in security considerations on the authorization process, which may include a ‘*’ ACL