I have been working since mid-November in my "copious spare time" to bring
DTLS support into ruby-openssl in order to bring DTLS into the Rails "David"
CoAP server.

DTLS_listen() seems entirely focused on single-use situations like in RTP,
where only a single connection (single DTLS session) is expected. If used
in CoAP situation, there are a number of race conditions that make it
hard to use correctly.   I wrote another email about that, which I think did
not get to the list, which I can resend.

I have preserved DLTSv1_listen() functionality, refactoring most of it
into DTLSv1_anwerHello(), and then adding DTLSv1_accept() on top of it.

Unfortunately I was also forced to delve into dgram_bss.c in order to bring
some additional information out; stuff which is rather OS dependant for IPv4,
and which perhaps would be better done in the application somehow.

I'm looking for advice.

Also, I found it difficult to find the right incantation to get a static
build; I noticed finally that my test/* programs were linking against the
libssl that was in my /lib, rather than the code I was testing.  I suggest
that this be captured into a ./Configure option.  I used:

     ./Configure no-shared --debug linux-x86_64

"no-dso" seemed like it ought to help, but it made things worse...

I hope that I added the new exposed symbols correctly.
I have yet to validate the complete david/coap/ruby-openssl/dtls
functionality, but I wanted to post this sooner for review.


https://github.com/openssl/openssl/pull/5024 says:

This patch refactors the DTLSv1_listen() to create an alternative API that is
called DTLSv1_accept().

DTLSv1_accept() is useable by programs that need to treat DTLS interfaces in
a way similar to TCP: new connections must be accepted, and new sockets
created.

There are a number of changes included here:

1. dgram_write() and dgram_read() now use sendmsg(2) and recvmsg(2) in order to 
set and collect the local address used in the datagram.  This allows a socket 
to bound to ::, while still sending traffic correctly from the address that the 
other peer used. The IPv6 version of this code is according to rfc3542 API, but 
the IPv4 of the code is Linux specific and needs to be either abstracted and 
translated for *BSD and Windows, or IPv6 mapped IPv4 sockets could be used.
2. a new BIO control SET_ADDR and GET_ADDR are added, and if the address is not 
set then it pulls it out of the socket using getsockname(2).
3. DTLSv1_accept() accepts a second SSL* on which new connections are setup. A 
new socket is set up using the addresses from the received message and it is 
inserted into the BIO. There is a race condition during setup which turned out 
to be unavoidable: between the bind(2) and the connect(2), the new socket could 
have the same address as the "listen" socket, and additional hello packets 
could arrive on the wrong socket.  Such packets will hopefully be dropped as 
garbage. It was thought that connect(2) could be called before bind(2), but 
that seems to cause the kernel to allocate a local address for the new socket 
(a random port), which the subsequent bind(2) can not seem to change.
4. the use of POSIX socket APIs inside this code is likely inappropriate and 
this routine should be split up in some better way so that socket activities 
can be done by the application, using the correct abstractions for the OS.
5. a new test case dtlsaccepttest was created.  It uses fork() and also calls 
system() on "openssl s_client". Probably it should just call code internally, 
but apps/* is not in a library form that can be used. Perhaps this use is 
acceptable.  Other test functions just use canned packets in/out, but since 
this is testing the creation/adaption of socket code, real sockets would seem 
to be necessary.  Probably this test case should be disabled on non-Unix 
platforms.
6. routines BIO_ADDR_sockaddr and BIO_ADDR_sockaddr_size exposed from libcrypto 
to libssl.  There might be a better way to do this, perhaps a BIO_CTRL would be 
better?



--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     m...@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Attachment: signature.asc
Description: PGP signature

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to