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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
CAPWAP Editor’s Report Pat R. Calhoun Cisco Systems, Inc.
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
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 802.3 encapsulation requires that the bridging function be performed in the WTP to: • "IEEE 802.3 encapsulation requires that for 802.11 frames, the 802.11 *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 30-49 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
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