[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DTLS in gnutls
From: |
Jonathan Bastien-Filiatrault |
Subject: |
Re: DTLS in gnutls |
Date: |
Mon, 14 Mar 2011 17:44:06 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Icedove/3.0.11 |
On 2011-03-11 14:59, Nikos Mavrogiannopoulos wrote:
> Hello,
> It seems that gnutls in master repository includes a fully
> functional DTLS 1.0 (rfc4347) implementation. Kudos to Jonathan
> for creating the initial functional implementation the current
> implementation was built on.
Great ! Thanks for putting it together and getting that last 10-20% done !
> Due to DTLS' requirements for handshake, several parts of
> gnutls' handshake subsystem were rewritten to allow maximum
> re-use between the two protocols (TLS and DTLS). DTLS'
> handshake is asynchronous meaning that it might operate
> even after gnutls_handshake() is terminated (e.g. retransmit
> handshake packets lost by the peer) and this requires
> substantial changes to how gnutls' functions can be
> called in DTLS. Now I emulate the synchronous behavior
> of gnutls_handshake() by waiting for few seconds for
> possible retransmissions by peer, and this has the
> disadvantage of gnutls_handshake() taking a fixed amount
> of seconds irrespective of calculations, but requires
> no semantic changes in the rest of the functions
> (such as gnutls_record_recv()).
This is a good starting point. However, as you must be aware, this adds
latency for the blocking case and is a Really Bad Idea in the async case.
The absolute worst case is a blocking, send-only application (think
CHARGEN).
The asynchronous case can be solved simply: require applications to
monitor the receive side even if they don't read after
gnutls_handshake() and call gnutls_record_recv() when this happens. This
assumes that you keep the last flight buffered neatly somewhere, ready
to send, for a while after gnutls_handshake().
Example sequence of events:
- Bunch of writes
- Event dispatch
- Bunch of writes
- Event dispatch
- Retransmit receive
- Socket readable event
- Event dispatch
- gnutls_record_read(). Here we read the socket, process and retransmit
if required. If we have no application data, we can (ab)use GNUTLS_E_AGAIN.
- Bunch of writes
- Event dispatch
- ...
Since this only adds a requirement and does not change existing ones
much, I think this is desirable.
For the blocking case, someone needs to monitor the receive side of the
socket. gnutls_record_send could set the socket to non-blocking mode,
call gnutls_record_recv, set it back to blocking mode and do the write.
This induces dependencies on some syscalls/application function pointers.
Giving a look at YaSSL and OpenSSL might give us a clue. The
responsibilities between application and library are still fuzzy for me
in that case. Handling os-specific timers and timeouts was also a big
part of my indecision in the handshake layer.
> Another solution is to require a DTLS server/client to
> call gnutls_record_recv() on every received record, even
> if he wasn't expecting one for his application protocol
> and reserve a special error code to indicate no data for
> application...
Is this the case I elaborated above ?
>
>
> I don't like the latter change of semantics, but I cannot
> see any obvious way of avoiding it... If you have suggestions
> or ideas please let me know.
>
> best regards,
> Nikos
>
All the best,
Jonathan
signature.asc
Description: OpenPGP digital signature
- DTLS in gnutls, Nikos Mavrogiannopoulos, 2011/03/11
- Re: DTLS in gnutls,
Jonathan Bastien-Filiatrault <=