EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Question concerning DTLS

Posted: 02/17/2010 02:53:55
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Many thanks for this extraordinarly informative answer as well as I have to say such an engaged staff is really hard to find in the Internet. I'm here in this forum since about three years and I have always got any question answered quickly, understandable, polite and competent. Many, many thanks for it and keep on doing that.
Concerning the topic: So keep alive is not part of SBB, neither from client nor from server, neither for TLS nor for DTLS. Did I catch this right?
Posted: 02/17/2010 03:23:22
by Ken Ivanov (Team)

TLS and DTLS do not provide built-in support for keep-alives. TLS was originally designed as a transparent security layer over TCP protocol. As TCP itself does not support keep-alives (you can only detect if TCP connection is alive by trying to read or write something to it), the TLS also doesn't.

For TCP-based (and, thus TLS-over-TCP-based) protocols the keep-alives are usually implemented as a part of application-layer protocols (HTTP, FTP etc.).

As DTLS was designed to be as much close to TLS as possible, it also does not support keep-alives.
Posted: 02/17/2010 05:58:18
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

From your experiences: Once a DTLS server/client connection has reached UP state and the client party breaks and retries again (same remote endpoint): What would the server say to a new "Client Hello"?

Posted: 02/17/2010 06:22:25
by Ken Ivanov (Team)

The server will ignore client hello messages arriving from the same client after the DTLS connection has been negotiated (treating them as "lost and then found initial client hellos").

However, "breaking and retrying again" is usually not a problem. First, TLS provides means for graceful session closure (with SBB this can be done by passing Silent=false parameter to the Close method). Second, it is a good idea to always allocate a new connection socket on client side. In most of the cases it would be bound to a different port, and thus the server will be able to distinguish packets coming from it from the packets of "older" client.
Posted: 02/17/2010 06:47:48
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Hmm. I'm looking for a means to manage several parallel connections. This is what I have for TCP:

1) If a client establishes a TLS connection to the server, it is entered into a list and monitored. If there was no outgoing user data traffic for a given time, the SBB object as well as the socket is closed. The purpose for that is to have a means to "reuse" an existing connection w/o being forced to go through the TLS negotiation for every single data portion again. This seems to work. The server watches this connection too, but with a higher timeout in order to be able to manage lost connections. The explicit socket open/close is very helpful to have a trigger here and to control the instantiation/destruction of SBB objects.

2) I'm not quit clear, how to adapt this for DTLS. OK, I can enter a (virtual) connection, once I have a DTLS connection UP and watch it from the client side. I can tear down the SBB object, if no data is available anymore for a given time (and doing the same on the server with a higher timeout). However - the view for client and server might differ, because there is no explicit open/close of a session... So it might be, that the server is dead, while the client is still alive, just because several data packets have been lost. I don't know, what impact this will have on future conversations between both, because: if the server re-creates a new SBB server object on reception of the next client packet - what will he do with it? It is out of sequence, because the client sends encrypted data, not the client hello, which would needed...

Posted: 02/17/2010 07:22:25
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

That said, I could exactly produce the (2) scenario:

1) Client connects to server and sends data - OK
2) Server simulates loss of connectivity by switching WiFi off (or unplug the cable)
3) After 30 secs the server gives up and tears down the SBB object
4) The cable is plugged again
5) The client is still sending data, the (new) server object is receiving it... and ignoring it obviously. No error, no response, just ignore...

UPDATE: Much easier:

1) Server/client connected via DTLS. Client sends data
2) Server is going down (stops) and comes back
3) The same situation as with 5) above.

How can this be solved?
Posted: 02/17/2010 08:18:12
by Ken Ivanov (Team)

There is no universal solution for this conceptual problem, whose root is (a) absense of guaranteed delivery, (b) connectionless. DTLS attempts to build a "connection" over a connectionless protocol, but you should keep in mind that it is not a "real" connection. It is actually just a negotiated set of cryptographic parameters.

To resolve this issue, you need to extend your application-layer protocol (also connectionless, as it runs over UDP) with some keep-alive features. For instance, you can introduce a kind of "keep-alive" packet and force peers to send such packet every N seconds. In case if there were no keep-alive packets from the peer for some period of time, the "connection" is considered broken and is removed from the list.

That was the simplest possible solution (and obviously not the best). The design and implementation of the solution suitable for your needs depend on your particular application-layer task.
Posted: 02/17/2010 09:12:25
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Thanks. This is what I was expecting.



Topic viewed 4003 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!