EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Question concerning DTLS

Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages
Posted: 02/15/2010 15:59:32
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

I have a questions regarding DTLS. Given a server, "listening" on a defined port for incoming UDP DTLS "connections". Could an existing DTLS session be confused by DTLS handshake packets, coming from another host using the same destination port locally? I think I have seen such a confusion right now, while getting the error 75782 followed by a connection close of the server. I admit, the new incoming packet did appear as it has been sent by the currently connected host.

Posted: 02/15/2010 23:44:07
by Ken Ivanov (Team)

Sure. It is a task of your code to distinguish the source of the incoming packets by their remote address and port. Packets originating from different <host:port> pairs belong to different "conversations" and cannot be passed to the same TElDTLS(Client|Server) object.

This distinction is not implemented in the sample (all incoming packets are assumed to come from the same source) for the sake of simplicity.
Posted: 02/16/2010 01:45:35
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Yes, we've already discussed this. Generally I have that distinction; this special case was "by fault". I just wanted to make sure.

Posted: 02/16/2010 06:29:27
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Just an additional question, please: May I rely on that OnReceive is only called, if triggered by DataAvailable? I think so, just a confirmation please. Background: For UDP I have to use a global input buffer (for all packets). For TCP I could use an input buffer associated to the TElxx object, but because I have to instantiate a new TElxx object, _after_ having received an UDP packet, this is no longer possible.

The answer has an impact to the design, I just want to be sure.

So I suppose, the things are going that way:

Enter DataAvailable()
Callback OnReceive()
Leave DataAvailable()


Posted: 02/16/2010 07:21:02
by Ken Ivanov (Team)

Yes, exactly.
Posted: 02/16/2010 09:19:13
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Right now I'm using just _one_ socket rx buffer for all UDP clients, which might come in (in contrast to TCP, where every living connection has it's own buffer). In your professional opinion: Could that work? I'm not that familiar with UDP, but I have a vague feeling, that there can be just one UDP reception a time...

Posted: 02/16/2010 09:37:04
by Eugene Mayevski (Team)

In UDP all of your data are received via one socket and as such they are not separated by sender. The only place where you get the sender's address and port is exactly where you receive the packet. So if you use one buffer, then you need to store sender's address and port together with the received data. And then dispatch the packets based on their sender info.

Sincerely yours
Eugene Mayevski
Posted: 02/16/2010 10:07:33
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Exactly this is what I'm doing. Thanks for confirmation.
Posted: 02/16/2010 13:34:49
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Because we are still dealing with DTLS: Once the connection is established between client and server and data may be exchanged between both, I can only see every TimeOutValue

Change Cipher Spec
Encrypted Handshake Message

flying from server to client, but not from client to server. Two questions:

a) What is that message good for?
b) Why doesn't the client poll the server too? How shall a client determine, that the server is "gone"?

Posted: 02/17/2010 01:38:44
by Ken Ivanov (Team)

According to DTLS specification, there is no way for the server to detect whether the client has received the final bunch of the TLS handshake messages ("change cipher spec" and "finished") sent by him. That's why the server continues to re-send those messages until some application-layer data proving that the connection has been successfully established is received from the client.

DTLS also does not provide means for peers to poll each other. If you need keep-alive support, you would have to implement it yourself on top of DTLS application layer protocol.
Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.



Topic viewed 3849 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!