1 / 45

Topic #1 DTLS Related Issues

Topic #1 DTLS Related Issues. Pat R. Calhoun. Issue 226: Transition to Join State . Current CAPWAP state machine requires knowledge of DTLS state machine and inspection of DTLS packets. Issue 226: Original CAPWAP State Machine. /-------------<----------------+--------------------

stian
Télécharger la présentation

Topic #1 DTLS Related Issues

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Topic #1DTLS Related Issues Pat R. Calhoun

  2. Issue 226: Transition to Join State • Current CAPWAP state machine requires knowledge of DTLS state machine and inspection of DTLS packets

  3. Issue 226: Original CAPWAP State Machine /-------------<----------------+--------------------\ v |d | +------+ b+-----------+ +----------+ | | Idle |-->| Discovery |--->| Sulking | | +------+ a +-----------+ c +----------+ | ^ |aa ^ |e /----------------------\ | | V f| v k| | | h +--------------+ +------------+ i +------------+j | | /--| Join |->| Configure |-->| Image Data | | | | +--------------+ g+------------+ +------------+ | | | "c1, ^ ^ ^ m| ^ |l | | | "c4 " " " | /-------/ | /----/ | | " " " " V |s v V | | “ " " " +------------+ o+------------+ | | “ " " " | Run |->| Reset |--------/ | “ " " " n+------------+ +------------+ p | “ " " " "c2 ^ ^ c3" ^ \---"-----"--"---"--------"----"-------/ " “ CAPWAP ~~~~"~~~~~"~~"~~~"~~~~~~~~“~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~ “ " “ " " " " " DTLS v " "n2 \"""""\ " “ v "n6,n7 /-->+------+ " W+------+ " " " +------------+ | /-| Idle | " C| Auth |--"~-"----"----->| Shutdown |-------\P | | +------+ " +------+V “ “ " /--->| |<----\ | | |X Z| " ^ U| " " n4 " | +------------+ | | | | | " | | " " n5," | ^ | | | | v "n1 |Y | n3“ v n8" |R |Q | | | | +--------+ | +------------+ S+------------+ | | | | | Init | \->| Run |<--| Rekey | | | | | +--------+ | |-->| | | | | | +------------+T +------------+ | | | \---------------------------------------------------------/ | \-------------------------------------------------------------/

  4. Issue 226: Current State Machine Text • Idle to Join (aa): This transition occurs when the WTP presents a DTLSClientHello message containing a valid cookie to the AC. WTP: This transition is a no-op for the WTP. AC: The AC does not maintain state information until the WTP presents a DTLS ClientHello message containing a valid cookie. Upon receipt of a DTLS ClientHello message containing a valid cookie, the AC creates session state and transitions to the Join state.

  5. Issue 226: Pat’s issues • The original intent was to use DTLS as a “black box” • I believe that the CAPWAP specification should be sufficient to implement (and get interoperability), yet not dictate DTLS state machine

  6. Issue 226: Originally Proposed Solution /=================>=====================================\ " /===============<=================================\ “ " " /=============<=============================\ " “ " " " /===========<=========\ " " “ " " " " n4,n5,n6" n8" n3" v " " " " +-----------+ +--------------+ +----------+ " " " " | DTLS Idle | | DTLS Setup | | DTLS Run | " " " " +-----------+ +--------------+ +----------+ " " " " ^ "n1 ^c4 ^ ^ "n2 c3^ n7" ^ " " " " " " " " " " " " " DTLS "~"~"~"~~~"~~~"~~~~~"~~~~~~"~~"~~~~~~~~~"~~~~~~~"~~~~"~~"~~~~~~~~ " " " " " " \======"=="=======\ " /====/ " " CAPWAP ^ v v v " " " " " " " " “ " " " " " " /=======/ " " " " " “ " " " " " " " " " " " " “ " " " " "c1 v "c2 d "c2 " v " " “ " " " \=>+------------+ +------+ +------+ " “ " " " | Idle |-->| Disc | | Auth | " “ " " \===>+------------+ a +------+ +------+ " “ " " b| ^ |d /==================/ “ " " | | /----/ " /-----------------"----\ " " v f| | v s| "c5 | " " +---------+ | r+----------+ t +------------+ | " " | Sulking |<-/ | Run |-->| Reset | | " " +---------+ +----------+ +------------+ | " " ^ ^ ^ | " " +------------+ q | | | | " " | Data Check |--------/ /-----/ | | " " +------------+<-------\ | | | " " p| k| j | v " \======>+--------------+ +-----------+ +------------+ " c5| Join |---->| Configure |---->| Image Data | \=========+--------------+ g +-----------+ h +------------+

  7. Issue 226: Issues with Proposal • Commands and notifications are not state transitions, they are events. The state machine is difficult to follow • for instance, the auth state has no input/output transitions

  8. Issue 226: Revised Proposed Solution w+----------+ x +------------+ | Run |-->| Reset |-\ +----------+ +------------+ |y u ^ ^ ^ | +------------+--------/ | | | | Data Check | /-------/ | | +------------+<-------\ | | | t| s| j| | +--------+ +-----------+ +------------+ | | Join |---->| Configure |---->| Image Data | | +--------+ q +-----------+ r +------------+ | ^ p| | | \------------------------------------\ | \---------------------\ | | /--------------<----------------+---------------\ | | | /------------<-------------\ | | | | | | n| |o z| v v | | +----------------+ +--------------+ +---------+ | | | DTLS Setup | | DTLS Connect | | DTLS TD | | | +----------------+ +--------------+ +---------+ | | g| ^ ^ |h ^ ^ v v | | | | | | | | | | | \-------\ | /-----------/ | | | | | | | | | | v |e f| v |j |k | \->+------+ +------+ +-----------+ | | Idle |-->| Disc | | Authorize | \--->+------+ a +------+ +-----------+ b| ^ |c | | /----/ v d| | +---------+ | | Sulking |<-/ +---------+

  9. Issue 226: New State Machine Events • Idle -> DTLS Setup • WTP: The WTP initiates this transition by invoking the DTLSStart command, which starts the DTLS session establishment with the chosen AC. This decision is performed via local configuration of the AC. • AC: The AC initiates this transition by invoking the DTLSListen command, which informs the DTLS stack that it is willing to listen for an incoming session. The AC MAY provide optional qualifiers in the DTLSListen to only accept session requests from specific WTP. • Discovery -> DTLS Setup • WTP: The WTP initiates this transition by invoking the DTLSStart command (see Section 2.3.2.1), which starts the DTLS session establishment with the chosen AC. The decision of which AC to connect to is the result of the discovery phase, which is described in Section 3.2. • AC: The AC initiates this transition by invoking the DTLSListen command (see Section 2.3.2.1), which informs the DTLS stack that it is willing to listen for an incoming session. The AC MAY have maintained state information when it received the Discovery Request in order to provide optional qualifiers in the DTLSListen command to only accept session requests from specific WTP. Note that maintaining state information based on an unsecured discovery request MAY lead to a Denial of Service attack. Therefore the AC SHOULD ensure that the state information is freed after a period, which is implementation specific.

  10. Issue 226: New State Machine Events • DTLS Setup -> Idle • WTP: The WTP initiates this state transition when it receives a DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). This error notification aborts the secure DTLS session establishment. When this transition occurs, the FailedDTLSSessionCount counter is incremented. • AC: The WTP initiates this state transition when it receives a DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). This error notification means a DTLS session was attempted with a WTP, but failed. The notification should include information such as the offending WTP, and the reason for the failure. When this transition occurs, the FailedDTLSSessionCount counter is incremented.

  11. Issue 226: New State Machine Events • DTLS Setup -> Authorize • WTP: This state transition occurs when the WTP receives the DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon entering this state, the WTP MAY perform an authorization check against the AC's credentials. The method by which this authorization is performed is outside the scope of the CAPWAP specification. • AC: This state transition occurs when the AC receives the DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon entering this state, the AC MAY perform an authorization check against the WTP's credentials. The method by which this authorization is performed is outside the scope of the CAPWAP specification. • Authorize - > DTLS Connect • WTP: This state transition occurs when the WTP has either opted to forgo the authorization check of the AC's credentials, or the credentials were successfully authorized. This is done by invoking the DTLSAccept DTLS command (see Section 2.3.2.1). . • AC: This state transition occurs when the AC has either opted to forgo the authorization check of the WTP's credentials, or the credentials were successfully authorized. This is done by invoking the DTLSAccept DTLS command (see Section 2.3.2.1).

  12. Issue 226: New State Machine Events • Authorize - > DTLS Teardown • WTP: This state transition occurs when the WTP was unable to authorize the AC, via its credentials. The WTP then aborts the DTLS session, which is done by invoking DTLSAbortSession (see Section 2.3.2.1). • AC: This state transition occurs when the AC was unable to authorize the WTP, via its credentials. The AC then aborts the DTLS session, which is done by invoking DTLSAbortSession (see Section 2.3.2.1).

  13. Issue 226: New State Machine Events • DTLS Connect -> Idle • WTP: This state transition occurs when the WTP receives the DTLSAborted notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established. When this notification is received, the FailedDTLSSessionCount counter is incremented. • AC: This state transition occurs when the AC receives the DTLSAborted notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established. When this notification is received, the FailedDTLSSessionCount counter is incremented. • DTLS Connect -> Join • WTP: This state transition occurs when the WTP receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. • AC: This state transition occurs when the AC receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. • Join - > DTLS Teardown • WTP: This state transition occurs when the WTP receives a Join Response with a Result Code message element containing an error. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). • AC: This state transition occurs when the AC transmits a Join Response with a Result Code message element containing an error. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1).

  14. Issue 226: New State Machine Events • Run -> DTLS Teardown • WTP: The WTP enters this state when it receives a one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY decide to tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. • AC: The AC enters this state when it receives a one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, DTLSDecapFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY decide to tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. • Reset -> DTLS Teardown • WTP: This state transition occurs when the WTP receives a Reset Request. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). • AC: This state transition occurs when the AC receives a Reset Response. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). • DTLS Teardown -> Idle • WTP: This state transition occurs when the WTP receives a DTLSPeerDisconnect notification (see Section 2.3.2.2). • AC: This state transition occurs when the AC receives a DTLSPeerDisconnect notification (see Section 2.3.2.2).

  15. Issue 229: DTLSMtuUpdate Undefined • Issue: The current spec makes references to the DTLSMtuUpdate command that is not present in the CAPWAP to DTLS commands. • Proposed Resolution: Add the following text to section 2.3.2.1: o DTLSMtuUpdate is called by the CAPWAP protocol to modify the MTU size used by the DTLS module. The default value size is 1468.

  16. Topic #7Join and Discovery Related Issues Pat R. Calhoun

  17. Issue 13: define how MTU of 1596 was chosen • The original issue was raised as: • e) Page 41 -- Section 6.1 Join Request -- 3rd paragraph -- Why the 1596 MTU limit -- how was this number chosen ? == (RIF routes if vlan ?) if I use 802.3 then I have seen h/w do 1522 (4 byte vlan tag) -- some number a little bigger than 1522 and h/w do 16K bytes -- (intel ixp 4xx series) --- The 16K number is bigger than the 4k SDU for wireless medium... Would it be better to base the discovery on the MTU of the wireless media and work down ? • Proposed Resolution: Reject. The offending text was removed long ago. There are no references to MTU sizes in the Join Request section.

  18. Issue 149: IPv6 Multicast address for Discovery phase • The issue states: As IPv6 protocol does not have broadcast address so can the CAPWAP protocol be more specific for the multicast address to be used in the discovery phase: • Have one address assigned for AC “All ACs multicast address “, this has advantage of limiting the traffic and also it is extendable for new solution like some communication between AC etc • 2 Use all node multicast address.

  19. Issue 149: IPv6 Multicast address for Discovery phase • Proposed resolution: • Add to the end of the following sentence: “The WTP must send the Discovery Request message to either the limited broadcast IP address (255.255.255.255), a well known multicast address or to the unicast IP address of the AC. “ • “For IPv6 networks, since broadcast does not exist, the use of “All ACs multicast address” is used instead.” • Add to IANA considerations: “to assign an organization local multicast address called the “All ACs multicast address” from the IPv6 multicast address registry”

  20. Issue: 175 WTP Board Data belongs in the Join, not configure • Issue: WTP Board Data belongs in the Join, not configure. • <PRC> Agreed, but wonder even more why we are duplicating this information across both the WTP Descriptor and the WTP Board Data message elements. • Dorothy has fixed this already, and is included in -04/-01

  21. Issue: 175 WTP Board Data belongs in the Join, not configure • Removed WTP Serial Number, WTP Model Number, Board ID and Board Revision (already in WTP Board Data) • New text: 4.5.37. WTP Descriptor […] Type: The following values are supported. The Hardware Version, Software Version, and Boot Version values MUST be included. 0 - Hardware Version: The WTP's hardware version number. 1 - Software Version: The WTP's Firmware version number. 2 - Boot Version: The WTP's boot loader's version number.

  22. Issue: 175 WTP Board Data belongs in the Join, not configure • The following changes have also been made: • WTP Descriptor present in Discovery (not WTP Board Data) • WTP Descriptor present in Join Request (not WTP Board Data) • WTP Board Data present in Configuration Status (not WTP Descriptor)

  23. Issue 219: Insufficient description of WTPs during discovery • This issue states that a WTP has no way of advertising what bindings it plans to use – or what bindings are supported on the AC. • The issue argues that the discovery process needs to take this into account in the AC candidate selection process.

  24. Issue 219: Insufficient description of WTPs during discovery 4.5.37. WTP Descriptor The WTP descriptor message element is used by a WTP to communicate it's current hardware/firmware configuration. The value contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Radios | Radios in use | Encryption Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num of Binding | Reserved | Wireless Binding Supported... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  25. Issue 219: Insufficient description of WTPs during discovery Num of Binding: An 8-bit value representing the number of 16-bit Wireless Binding Supported fields present in the WTP Descriptor. Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Wireless Binding Supported: One or more 16-bit value representing the CAPWAP binding supported by the WTP. The following values are supported: 1 - IEEE 802.11: The IEEE 802.11 CAPWAP binding (see [12]). 2 - IEEE 802.16: The IEEE 802.16 CAPWAP binding. 3 - EPCGlobal: The EPCGlobal CAPWAP binding.

  26. Issue 219: Insufficient description of WTPs during discovery 4.5.1. AC Descriptor The AC payload message element is used by the AC to communicate it's current state. The value contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stations | Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Active WTPs | Max WTPs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security | R-MAC Field | Reserved1 | DTLS Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num of Binding | Reserved | Wireless Binding Supported... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  27. Issue 219: Insufficient description of WTPs during discovery Num of Binding: An 8-bit value representing the number of 16-bit Wireless Binding Supported fields present in the AC Descriptor. Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Wireless Binding Supported: One or more 16-bit value representing the CAPWAP binding supported by the AC. The following values are supported: 1 - IEEE 802.11: The IEEE 802.11 CAPWAP binding (see [12]). 2 - IEEE 802.16: The IEEE 802.16 CAPWAP binding. 3 - EPCGlobal: The EPCGlobal CAPWAP binding.

  28. Issue 219: Insufficient description of WTPs during discovery 3.2. AC Discovery The AC Discovery phase allows the WTP to determine which ACs are available, and chose the best AC to establish a CAPWAP session with. The discovery phase occurs when the WTP enters the Discovery state, which is optional. A WTP does not need to perform the AC discovery if it has a pre-configured AC which it wishes to utilize. This section details the mechanism used by the WTP to dynamically discovery candidate ACs. A WTP and an AC will frequently not reside in the same IP subnet (broadcast domain). When this occurs, the WTP must be capable of discovering the AC, without requiring that multicast services are enabled in the network. [...] Once the WTP has received Discovery Responses from the candidate ACs, it MAY use other factors in determining which is the preferred AC. For instance, the AC Descriptor, present in the Discovery Response, provides the list of CAPWAP bindings supported by the AC. A WTP MAY decide to connect to an AC based on the supported bindings advertised.

  29. Issue 219: Insufficient description of WTPs during discovery 4.5.31. Result Code [...] Result Code: The following values are defined: [...] 9 Join Failure (Binding Not Supported) 5.1. Discovery Request Message [...] The WTP Descriptor included in the Discovery Request includes the CAPWAP bindings supported by the WTP. 5.2. Discovery Response Message [...] The AC Descriptor included in the Discovery Request includes the CAPWAP bindings supported by the AC. The AC MAY include only the bindings it shares in common with the WTP, known through the WTP Descriptor received in the Discovery Request, or it MAY include all of the bindings supported. The WTP MAY use the supported bindings in its AC decision process. Note that if it uses an AC that does not support a specific CAPWAP binding, service for that binding MUST NOT be provided to stations.

  30. Issue 219: Insufficient description of WTPs during discovery 6.1. Join Request [...] The WTP Descriptor included in the Join Request includes only the CAPWAP bindings supported by the AC that the WTP expects to utilize. Including a binding that is unsupported by the AC will result in a failed Join Response. 6.2. Join Response [...] If the WTP Descriptor in the Join Request included a binding that is not supported by the AC, the AC sets the Result Code message element to "Binding Not Supported".

  31. Topic #2Configuration Related Issues Pat R. Calhoun

  32. Issue 72: get WLAN Config message • The original request, which lead to the issue being created, was a request for a new set of messages that allow an AC to request the WTP to provide its current configuration. At the time of the discussion, I disagreed this feature was needed in the CAPWAP protocol, because at the time of a reboot the WTP provides its stored configuration, if any. The AC then proceeds by providing its own configuration. The claim was that it was necessary for the AC to be able to "pull" the configuration from the WTP, ensuring it has an accurate picture of the WTP's config. There was also a mention that WTP bugs could exist that would cause the WTP to not process the configuration properly. • I believe that the current proposal for issue 73 now allows the WTP to return an error code should it be unable to apply a specific configuration message element. The AC can then decide whether it wishes the WTP to provide service anyhow. This ensures the AC will know the WTP's config. I also do not believe that a standard should be encumbered to help identify bugs on WTPs. • I do not believe that we have addressed the original request, however the question is whether we have addressed it in spirit. I believe we have with the proposed text in issue 73.

  33. Issue 73: Problems with setting initial config I have introduced a new message element, which is described below: <text> 4.5. CAPWAP Protocol Message Elements [...] Returned Message Element 46 </text> Here I have defined new result codes that allow the WTP to communicate why it was unable to apply the configuration, and two different reasons: <text> 4.5.31. Result Code [...] Result Code: The following values are defined: [...] 10 Failure (Unable to Apply Requested Configuration - Service Provided Anyhow) 11 Failure (Unable to Apply Requested Configuration - Service Not Provided) </text>

  34. Issue 73: Problems with setting initial config In the event that the WTP is unable to partially apply the requested configuration, the Change State Event includes one or more "Returned Message Element" which includes the offending information element. <text> 4.5.32. Returned Message Element The Returned Message Element is sent by the WTP within the Change State Event Request in order to communicate to the AC which message elements in the Configuration Status Response it was unable to apply locally. The Returned Message Element contains a result code that is used to indicate the reason why the configuration could not be applied, and encapsulates the offending message element. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | Message Element... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reason: The reason why the configuration in the offending message element could not be applied by the WTP 1 - Unknown Message Element 2 - Unsupported Message Element 3 - Unknown Message Element Value 4 - Unsupported Message Element Value Message Element: The Message Element field encapsulates the message element sent by the AC in the Configuration Status Response message that caused the error. </text>

  35. Issue 73: Problems with setting initial config Finally, the Change State Event text has been modified to indicate its expanded purpose, and the new message elements it may carry <text> 8.7. Change State Event Request The Change State Event Request message is used by the WTP for two main purposes: o When sent by the WTP following the reception Configuration Status Response from the AC, the WTP uses the Change State Event to provide an update on the WTP radio's operational state as well as to confirm that the configuration provided by the AC was successfully applied. o When sent during the Run state, the WTP uses the Change State Event to notify the AC of an unexpected change in the WTP's radio operational state. When an AC receives a Change State Event Request message it will respond with a Change State Event Response message and make any necessary modifications to internal WTP data structures. The AC MAY decide not to provide service to the WTP if it receives an error, based on local policy, which is done by transitioning to the CAPWAP Reset state. …

  36. Issue 73: Problems with setting initial config … The Change State Event Request is sent by a WTP to acknowledge or report an error condition to the AC for a requested configuration through the Configuration Status Response. The Change State Event Request includes the Result Code message element, which indicates whether the configuration was successfully applied. If the WTP is unable to apply a specfic configuration request, it indicates the failure by including one or more Returned Message Element message elements (see Section 4.5.32). The following message elements MUST be present in the Change State Event Request message. o Radio Operational State, see Section 4.5.30 o Result Code, see Section 4.5.31 One or more of the following message elements MAY be present in the Change State Event Request message. o Returned Message Element, see Section 4.5.32 </text> Therefore, I believe the request defined in issue 73 has been satisfied.

  37. Issue 108: Configuration Failure Processing (sub-issue 1) Config changes can fail (even when they are "not suppose to"). This may be due to a) resource deletion b) semantic constraints c) hardware failures d) software failures e) lack of authorization In the "configure request/response" (sections 7.2/7.3) , the "response" message specifies configuration settings. As described, there is no mechanism for the WTP to communicate to the AC that some (or part) of the config sent by the AC to WTP failed. Thus, I suggest that the response contain no configuration. <PRC> This is a duplicate of issue 73, which I believe we have satisfied.

  38. Issue 108: Configuration Failure Processing (sub-issue 2) 2) I'm not sure that all of the configuration info can fit into one CAPWAP control message. However, a WTP needs to be able to indicate to a AC the "classes" of config info that it supports. SNMP uses the GETNEXT operation to iterate through both all classes and instances of management info (which includes config info). I suggest for CAPWAP that a WTP specify in the "configure request" the classes of configuration info and then allow an AC to use one or more "Update config request" messages to change the WTP config. <PRC> I believe Michael and I responded to this via another email thread that neither one of us understood why the existing fragmentation mechanism supported by CAPWAP does not resolve this issue. Duplicate of issue 173

  39. Issue 108: Configuration Failure Processing (sub-issue 3) 3) When an AC changes the WTP config with an "Update config request", the request can fail. The response message needs to indicate which config message element(s) had an error and what was the error. Currently, this is not the case. (The error code in the result, as currently defined makes no sense to me!) Also, I didn't see if a config request was "all or nothing". That is, do the OK config values get applied and the error one not, or none get applied on any failure. <PRC> This is a duplicate of issue 73, which I believe we have satisfied.

  40. Issue 108: Configuration Failure Processing (sub-issue 4) 4) There are a lot of strange (too me) and not well defined config elements. I believe that all need to be reviewed, but this is really a separate issue. <PRC> As mentioned, this is a separate issue, and is therefore not germane to issue 108.

  41. Issue 108: Configuration Failure Processing (sub-issue 5) 5) A get config operation is needed that specifies at least a class of configuration info, and possibly additionally the instance of config info. (Again, this is because not all config info will be able to fit in a single CAPWAP message.) <PRC> I do not understand the request here. Is this a duplicate of issue 72, which is a request to have the AC pull the WTPs configuration? Duplicate of 72 *and* 173.

  42. Issue 108: Configuration Failure Processing (sub-issue 6) 6) I've ignored what should be done when an WTP has config info that is not supported by an AC, or when an AC tries to modify config info (class or specific values) that is not supported by the WTP. (CAPWAP is suppose to support WTPs and ACs from different vendors, and, thus, there can be no "tight version synchonization" as found in current products. <PRC> I believe this is already addressed via the proposed text for issue 73, which is done by including the Result Code set to 10 Failure (Unable to Apply Requested Configuration - Service Provided Anyhow), and including the Returned Message Element

  43. Issue 108: Configuration Failure Processing (Conclusion) So it appears that there are two sub-issues that have not been addressed already, sub-issues 2 and 5. Michael and I questioned whether 2 is a real problem or not, and I believe sub-issue 5 is not specified sufficiently for me to understand. I therefore do not believe that we are have sufficiently addressed this issue, but should reject this issue.

  44. Issue 181: Configuration Status is broken • I believe that this is a duplicate of issue 73, for which text has already been proposed.

  45. Issue 190: Issues with configuration update response • The issue seems to have two sub-issues. the first, identified as 42, is addressed with your suggestion below, for which proposed text was provided via issue 73. The second sub-issue, identified as 41, states that the CAPWAP protocol does not support APs that have no (or limited) nonvolatile memory. • I do not believe we have provided text to support the latter. The problem statement which was published by the CAPWAP WG does not mention that memory was an issue for traditional APs, and do I believe it is in the working group's scope to solve this problem. • We will add text stating that the WTP MAY save the configuration to flash, but that is implementation specific. The CAPWAP protocol does not dictate how the WTP is to utilize any optionally present non-volatile storage

More Related