search

rbit / pydtls

Datagram Transport Layer Security for Python
Apache License 2.0
72 stars 45 forks source link

Is NAT traversal handled properly for long running connections? #25

Closed ChristiaanWillemsen closed 4 years ago

ChristiaanWillemsen commented 4 years ago

I have a question regarding NAT traversal, and specifically with long running connections. In these cases the STUN will timeout, leading to a new packet from client to server to appear to be coming from a new source port.

We tried out some tests with a rigged client which made it possible to exchange the datagram socket for a new one. so what happens is this:

client makes a DTLS socket to the server, server accepts a fresh DTLS socket then we exchange the datagram socket in the client for a new one (so new source port), and we send a new packet to the server. In this case, it looks like the server seems to accept a new TLS socket, but does not do a new handshake.

I would expect that the packet would be steered towards the original TLS socket.

This is obviously only a crude test to reproduce the issue. With a real setup we've also seen that not only the source port changes, but also the source IP could change due to load balancing NAT gateway.

rbit commented 4 years ago

Clients are identified by their address/port tuple only. The demux will route a packet from a new tuple to a new SSL type instance with freshly initialized state. The same is true for DTLS in general, unless something like "Connection Identifiers" has been implemented and the connection_id extension is present.

ChristiaanWillemsen commented 4 years ago

Mkay, so why does the new connection appear to do the handshake without any client interaction then? And the new socket will still receive new information.