Capwap editor s report
Sponsored Links
This presentation is the property of its rightful owner.
1 / 24

CAPWAP Editor’s Report PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

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:

Download Presentation

CAPWAP Editor’s Report

An Image/Link below is provided (as is) to download presentation

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

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 802.3 encapsulation requires that the bridging function be performed in the WTP


    • "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

  • Login