1. Issues Discussions CAPWAP Interim Jan 24-25, 2007 Mahalingam Mani

2. 121: Provide more clarity on receiving unexpected message This is related to receiving messages beyond the scope of current state or inconsistent with current state. –Should the treatment be different for secure-state messages vs. non-secure mode (e.g., discovery) messages Non-secure messages received in secured (e.g., run)-state –(what) is 4.5.31 – result code - lacking? –(why) is 4.5.32 - returned message element - (not) sufficient? –What about other error codes? “A discovery recvd in the run state should ideally indicate the peer has gone down, Probably a reboot” –How to conclude so in favor of DoS? –Discussion was offshoot to issue45 Status: open Summary resolution: –The discussion concluded that (2) the unauthenticated discovery message is insufficient reason to reset state and resume rediscovery. However, discovery message would be entertained in this context and other states independent of existing run-state. –Other messages received in the protected states/modes which are inconsistent with the state of the AC or WTP will be returned with appropriate error (unexpected message in **** state) message. Sections 4.5.31 and 4.5.32 of -04 and elsewhere will be updated to clarify this. Pat will provide the updates.

3. 152:CAPWAP-01 doesn't do a good job of indicating which message elements can be repeated Can we summarize what has been done to address this? Proposal –When listing message elements, should note whether the frequentcy is 0-1 (absent or once), 1 (only once) or 0+ (any number of them could be present) Status: Open Resolution: –Dorothy Stanley will expand on the existing ‘table’ (along the lines of what exists in section 5 of.11bindings draft) to specify the number of times allowed message elements can figure in the messages. –This is posted here for WG discussion, acceptance/consensus.

4. 153: Can "additional" message elements be added to a message? (I believe so for reporting capabilities, statistics, and events. For configuration, there is nothing in the protocol that says what happens when one end gets an configuration element it doesn't know about. Should it be ignored, and the other elements processed, or should the entire operation be failed?) Proposed: The "Mandatory to implement" bit could address this issue. If an unrecognized message element is found to have the bit set, then the whole message needs to be rejected. If the bit is not set, the message element may be safely ignored. Status: Open Resolution: –If a message element is encountered in any message the processing will abort and If it is a request message, an (unknown message element) error response will be returned. –The entire message will not be processed – regardless of relevance of other message elements before and after. If it is a response message that contains an element unknown; it will be silently discarded. –Pat to provide text to clarify result codes.

5. 173: What if all of the message elements do not fit within a single CAPWAP control frame. Pre-interim Response: CAPWAP fragmentation should address this. If “control message” rather than control frame – this needs to be addressed (Dave Perkins) –WTP receiving a response message > max-message-size(WTP) –What if Sender (AC) knows max-message-size(WTP) limit If the WTP cannot support reassembly of messages > somesize –Implementation issue. Status: Open (Need more clarification on the perceived problem)

6. QoS-DTLS factor in data-path When data traffic is DTLS-protected between WTP & AC – the different QoS-flows (11e-marked to-DS and Diffserv-marked from- DS) will need to carry appropriate markings. This can lead to spurious replay as the markings may cause reordering along the way – being carried over the same DTLS session. –This is a concern for WTP-terminated 802.11i (as above). –Is there a need to differentiate control messages? Are there any control messages requiring expedited delivery? Proposed approach –Entertain per-DSCP DTLS sessions –Use DTLS-session resumption to create DTLS-session per-flow Multiple DTLS sessions between the the same WTP-AC pair (5-tuple) Identify and map sessions by hosting DSCP values in the preamble. –Nominal DoS concern (generic to all fields in the preamble) WTP-initiated; need a control message to bind sessionID to DSCP. –Issue Does DTLS module implementation support multiple sessions for same 5-tuple? How do we let the DTLS module know which SA to pick? Alternatives –Use different source addresses to distinguish DTLS sessions –Don’t mark the encapsulation PVer (4) QI (3) Preamble