Subject: [Capwap] lwapp-dtls: section 2 - dtls potential errors

From: Scott G Kelly <[email-masked]>
Date: Mon, 13 Feb 2006 05:52:32 -0800

This is the first in a series of email threads discussing issues Sue
raised with the current lwapp-dtls draft.

A minor point of clarification. DTLS/TLS refers to session establishment 
as the "handshake", and rekeying as a "rehandshake". We should use that 
terminology from now on to avoid confusion.

In section 2, "Inserting DTLS", you point out that dtls can encounter
errors or receive "Alert" messages due to errors encountered by a peer,
and ask how these errors will be handled. Here is the text you inlined
in the draft, with my comments inlined....

> DTLS can encounter errors or cause Alert messages.  This section describes
 > the interface between DTLS and LWAPP to process the errors and alerts.
> 
> 2.1) DTLS potential errors 
> 
>    DTLS uses all of the same handshake messages and flows as TLS,
>    with three principal changes:
> 
>       1. A stateless cookie exchange has been added to prevent
>       denial of service attacks.
> 
>       2. Modifications to the handshake header to handle message
>       loss, reordering and fragmentation.
> 
>       3. Retransmission timers to handle message loss.
> 
> Each of these new features can cause the DTLS connection to fail. 
> 
> 
> 2.1.1) DTLS Cookie Exchange Failure causes dropping of DTLS session  
>  Sequence (per DTLS): 
> 
>          Client (WTP)                         Server (AC)
>          ------                                   ------
>          ClientHello           ------>
> 
>                                <----- HelloVerifyRequest
>                                       (contains cookie)
> 
>          ClientHello           ------>
>          (with cookie)
> 						(Bad cookie determination) 
> 						[please fill in DTLS action] 
> 
> 
> Detection: 
> 
> Once the client has transmitted the ClientHello message with the cookie
> the server validates the cookie.  If the cookie is bad, the server
> a)disconnects the client [option a]
> b)allows the client another n tries by sending
> HelloVerifyRequest(cookie) 
> c)Awaits a retransmission of the ClientHello
> 
> (note: DTLS needs to specify the action here) 
 >
 > Signal to LWAPP:
 >
 > Error action 	             State in LWAPP              Action
 > a) Disconnect 		DTLS-init                 ???
 > 				DTLS-rekey
 >
 > b)Another retry               DTLS-init                 ???
 >   After send                  DTLS-rekey                ???
 >   the DTLS message
 >   HelloVerifyRequest
 >
 > c) Wait ClientHello           DTLS-init                 ???
 > 				DTLS-rekey
 >
 > New Action by LWAPP:
 >
 > Discovery state:
 > 1) Drop DTLS connection in discovery state
 > 2) Keep LWAPP in Discovery state while awaiting DTLS drop.
 >
 > DTLS Rekey state:
 > 	(please specify)
 >
 > (please follow through to check all interaction with other states).
 >

An important point here: in many (if not all) cases, dtls will not be a 
black box that is dropped into capwap implementations. In some cases, 
folks may choose to implement from scratch, and in others, they might 
choose to use openssl or some other library. Different libraries may 
implement APIs in their own idiosyncratic way, so we need to be careful 
about overspecification here (and not specify APIs).

That said, assuming a UDP transport and openssl, each end will open a 
socket from which they read and write, and errors will be returned by 
read and write operations. In openssl, the application calls 
SSL_get_error() to determine the particular error. Arguably, bad cookies 
should be ignored (due to the DoS implications), but the application is 
completely free to define its own behavior.

Since DTLS hello exchange is stateless, option (a) is not possible, and 
likewise, since (b) would require statefulness I don't think that's a 
good idea. I would suggest ignoring (or at most, logging) invalid 
cookies (option c).

  > 2.1.2) DTLS Fragmentation errors
> 
> a) Description in DTLS of fragmentation requirements: 
> 
>    “When transmitting the handshake message, the sender divides
>    the message into a series of N contiguous data ranges. These
>    range MUST NOT be larger than the maximum handshake fragment
>    size and MUST jointly contain the entire handshake message.
>    The ranges SHOULD NOT overlap.”
> 
> Action upon Failure: 
> If a fragmented messages should fail the above constrains,
> LWAPP will be signaled with: xxx (fill in blank) 

Again, this may be an API issue. Keep in mind that dtls implements 
reliable delivery during the handshake phase (and only then). So, 
there's a timer set on both sides. Also, record layer fragmentation may 
*only* occur during the handshake, and not afterwards.

DTLS fragmentation (in the Handshake only, described in 4.2.3) is 
subject to automatic fragmentation and reassembly. Only complete 
Handshake Messages are processed by the Handshake layer, so incomplete 
messages are treated as if the message was never received.

  > b) DTLS client reception of handshake problems with recombining 
fragments  of messages
> 
> DTLS Text:   
>   “When a DTLS implementation receives a handshake message
>    fragment, it MUST buffer it until it has the entire handshake
>    message. DTLS implementations MUST be able to handle
>    overlapping fragment ranges. This allows senders to retransmit
>    handshake messages with smaller fragment sizes during path MTU
>    discovery.” 
> 
>   Failures: 
> 1)Buffer overflow with all message 
> 2)DTLS timeout with messages still pending
> 3)LWAPP timeout with DTLS still waiting for messages.
> 
>   Action upon Failure: 
>       Please specify 
> 
> LWAPP action upon signal: 
> 	(please fill in) for the DTLS init and re-keying states
> 
> Signal to LWAPP for fragmentation 
> 
> Error action 	State in LWAPP		Action 
> a) Fragmentation 		DTLS-init			???
> 	error			DTLS-rekey
> 
> b)fragment   		DTLS-init			???
>   recombine error 	DTLS-rekey			???
> 1)buffer overflow
> 2)DTLS timeout 
> 3)LWAPP timeout 
> 
> (please specify errorsO 

This is pretty much the same discussion as above, and the dtls return 
value depends on the implementation. In openssl, the socket read will 
return an error, and lwapp could use SSL_get_error() to determine the 
particular error. I would assume that upon any of these errors, AC lwapp 
would either return to the discovery state, and WTP would choose the 
next suitable AC and try again. This is no different than errors 
encountered during session establishment by the current lwapp 
implementations.

> 
> 2.1.3a) DTLS Message Lost Fail causes delayed success 
> 
> Sequence per DTLS doc: 
> 
>       Client (WTP)                            Server (AC) 
>       ------                                   ------
>       ClientHello           ------>
> 
>                               X<-- HelloVerifyRequest
>                                                (lost)
> 
>       [Timer Expires] 
> 
>       ClientHello           ------>
>       (retransmit)
> 
> 						[LWAPP Wait Join timer expires] 
>                                -----HelloVerifyRequest
>                                                (OK)
> 
> Detection: 
> 
>    Once the client has transmitted the ClientHello message, it
>    expects to see a HelloVerifyRequest from the server. However,
>    if the server's message is lost the client knows that either
>    the ClientHello or the HelloVerifyRequest has been lost and
>    retransmits. When the server receives the retransmission, it
>    knows to retransmit. The server also maintains a
>    retransmission timer and retransmits when that timer expires.
> 
> 
> Signal to LWAPP:  Signal that Hello Verify has been received in 
> 			
> Action by LWAPP:  Drop DTLS connection in discovery state. 
> 			Keep LWAPP in Discovery state while awaiting DTLS drop.
> 

Again, there are API issues here. Openssl can call a client callback 
function once the session is established, and lwapp has the option to 
abort the session establishment at any point using a function call. Why 
should dtls signal each step in its protocol, rather than just session 
establishment?

> 2.2) Alert messages
> 
> 
> DTLS Alert Message Generation (from DTLS) 
> 
>    Note that Alert messages are not retransmitted at all, even
>    when they occur in the context of a handshake. However, a DTLS
>    implementation SHOULD generate a new alert message if the
>    offending record is received again (e.g., as a retransmitted
>    handshake message). Implementations SHOULD detect when a peer
>    is persistently sending bad messages and terminate the local
>    connection state after such misbehavior is detected.
> 
> Indication to LWAPP that Alert message has been sent: 
> (please fill in) 
> 
> Impact on LWAPP state machine: (please fill in) 

Again, API issues. Openssl will return a read/write error, which lwapp 
can obtain using SSL_get_error() - other implementations would do 
something similar.

Scott
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap