CAPWAP Editor’s Report

Pat R. CalhounCisco 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 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

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