DTLS reconnect

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

DTLS reconnect

Detlef Vollmann
Hello,

section 4.2.8 "Establishing New Associations with Existing Parameters"
of RFC 6347 (<https://tools.ietf.org/html/rfc6347#section-4.2.8>)
recommends ("SHOULD") that a new ClientHello from a client IP/port
pair for which a session already exists initiates a new handshake.

I tried to test such a scenario using s_server and s_client:

As server:
openssl s_server -accept 127.0.0.1:18001 -4 -cert demoCA/srv.crt -key
demoCA/testdev.key -CAfile demoCA/testca.crt -dtls1_2

As client:
openssl s_client -bind 127.0.0.1:19933 -connect 127.0.0.1:18001 -4
-noservername -cert demoCA/clnt.crt -key demoCA/testdev.key -CAfile
demoCA/testca.crt -dtls1_2

Then stop the client using CTRL-C and start it again.
tcpdump/wireshark shows the first (successful) handshake and then
ClientHellos from the same IP/port pair which are never replied to.


I tested the official Debian unstable package 1.1.1g-1 and
today's master (a3f15e237c).

So here are my questions:

  - Is this part of RFC 6347 implemented in OpenSSL?
  - If yes, how can it be used?

Note: this is not the same as what the "-reconnect' option of
s_client does.  This reconnect sends a ClientHello with a
previously established session ID for cached connections.
Section 4.2.8 of DTLS 1.2 is about a client that has no
existing session context but tries to connect from an IP address
and UDP port it has used previously.  This happens e.g. for many
embedded devices after a reset.

Thanks,
   Detlef