CAPWAP Editor

1
CAPWAP Editors Report

• Pat R. Calhoun
• Cisco Systems, Inc.

2
Closed Issues
3
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.

4
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

5
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

6
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

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

8
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

9
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

10
Issues Pending Approval
11
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

12
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

13
Issue 22 Data Check has no timeout on AC

• Data Check state had no exit if WTP didnt
  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

14
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

15
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

16
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).

17
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".

18
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

19
New Issues
20
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 ACs management
  interface.
• The request is to modify the data transfer to be
  bi-directional (supporting both "push" and "pull"
  model).

21
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)

22
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

23
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

24
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