[erlang-questions] DTLS Status and examples?

Ingela Andin ingela.andin@REDACTED
Wed May 7 20:38:23 CEST 2014


Hi!

2014-05-07 18:38 GMT+02:00 Andreas Schultz <aschultz@REDACTED>:

> [...]
> >
> > DTLS is not yet runnable, as there is not yet a red thread through the
> code.
> > dtls_connection.erl is the most incomplete module. It is the module that
> > implements
> > the finite state machine of the DTLS handshake, it correspondes to
> > tls_connection.erl. In general tls_* implements TLS specific parts and
> > dtls_* DTLS specific parts and ssl_* common parts.
>
> Looking at dtls_connection.erl, it seems to me that it replicates to much
> functionality
> from tls_connection.erl.
>
>
Did not say anything of it being finished. You should see it more as
sketch. I have been refactoring in a lot in small steps, making sure that
TLS is not is broken. And I do expect that there will be more refactoring.


At the pure TLS FSM level, DTLS and TLS are almost identical. The only real
> difference
> here is the HELLO VERIFY request.
>

Well tls_connection and ssl_connection does not  implement a pure
handshake-FSMs, it also handles the user data, record- and alert protocols.


> To me it looks like the current dtls_* modules duplicate lots of the SSL
> record level
> FSM functions, when they IMHO should only abstract the differences in the
> transport
> level mapping.
>
>
I am sure there is still room for improvement,  for our design two things
are important. The connection process for TLS and DTLS shall be separate
behaviour implementations so that a bug in one will not affect the other.
We want to leave room for API functions that may be DTLS and/or TLS
specific, and also we want to reuse as much as possible of the original
SSL/TLS code. I have also tried to use a much as possible  of your
contributed code.  And yes there are some design decisions left to make and
some code that is there now that may be disregarded.


> You could always do a test suite for DTLS that corresponds to
> > ssl_to_openssl_SUITE.erl in the test directory. Once you have a test
> suite
> > it is easier to try to fill in the gaps in dtls_* .
>
> The pure connection oriented test can be converted with very little
> effort.


Yes sure they can, but it is still work that needs to be done and does not
take zero time. It is just a start, but you need to start somewhere and
once dtls_connection is  more close to connection process implementation
you can start a test driven approach of making it work.


The test
> that manually open a TCP connection are a bit harder. The real challenge
> will be to
> come up with exhaustive testes for packet loss, reordering and duplication.
>

Good testing is always a challenge ;)


Regards Ingela Erlang/OTP team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140507/793b3fa4/attachment.htm>


More information about the erlang-questions mailing list