Connection ID extension

[ShadowJonathan]

As per Draft 13 of the Connection ID extension, DTLS wants to ensure that connections can persist over different server-client address+port tuples, however it does not yet specify a method via which to securely update these peer addresses, this could be seen as something analogous to QUICs persistency over multiple peer addresses, and/or TLS resumes.

Regardless, this is a problem for the design proposed in #1, as v1.3 requires and efficiently integrates these connection IDs, and so this is required to support v1.3.

The problem for #1, however, is that right now the application multiplexes the underlying transport to the DTLS is objects, and right now there is an implicit expectation of immutability of peer addresses after they've been established.

The connection ID proposal effectively says "no, everything is multiplexed as per the connection ID", with an asterisk that, to prevent attacks, the previous peer address should be considered canonical until a renegotiation has taken place.

This effectively requires a more complex back and forth between the application and DTLS layer, for which a good design would be necessary.

[ShadowJonathan]

It is possible that for the server listener, this can be fairly transient, in that it could signal that a CID Peer Address change has been negotiated, and that a particular Connection object needs to now listen on a different peer address.

I'd like to wait for the IANA to properly ratify such a protocol, though the 3rd draft of the RRC mechanism seems to me just that.

The latter probably requires implicit borrows or "knowledge" of connection objects from server listeners.

On the client side, I'm not entirely sure how this would look like, though there could probably be a lightweight "CID extractor" function analogous to a server listener, trying to parse unknown datagram packets, seeing if they're possibly a CID, and then passing that. The application could then ask a corresponding connection object if this packet is related to its connection, and potentially start a RRC renegotiation process.

This process could allow for more noise or attacks to have more execution in the application, so probably some "no, this is not a valid packet that rebinds CID" error should exist to then allow the application to start dropping packets from that address for a timeout.

(Possibly the same mechanism as described above could happen for the server part, without complicating much of the existing infrastructure, it'd add one new behaviour path of Listener -> "pass this to this connection object" -> Connection -> "hey, application, please change the peer address I'm listening to", or something along these lines, I'm not sure about the latter, as it'd require the listener object to have access to the connection object's security context, which may be undesired.)

[ShadowJonathan]

I just realised that it’s possible that, while the client might be switching to another network, a read from a socket might begin responding with “host not reachable”, we should make sure (either document this, and/or use it in the batteries-included router) that the router shouldn’t close connections immediately if it receives this, but instead maybe begin a countdown of 30 seconds until which a connection like that is closed, which is cancelled if a peer switch happens within that time.