DTLS 1.2 connection ID bypassing NATs

The DTLS internet pain

For DTLS 1.2 it's essential, that records are encoded and decoded with connection keys negotiated during the handshake. Those keys are associated with the peer's IP endpoint, the source ip-address and port. That works well, if the network is fully controlled and static. In the NATed internet, it is an impossible task. Without exchanging records that association is usually only valid for a couple of seconds (e.g. 30-180s). When a new record arrives after quiet periods, that association is lost and so the negotiated keys could not be determined. As consequences a new handshake is required. Even a short resumption handshake uses often more bytes than the effective payload.

One important part to overcome that is RFC9146 Connection Identifier for DTLS 1.2. It introduces a new record type TLS12_CID (25/0x19), which contains a connection id. That connection id is then used to associate the negotiated keys instead of the ephemeral IP endpoint. With that, DTLS 1.2 works now great even in the NATed internet! Your peer may became easier traceable by the traffic with that cid, but many scenarios will benefit more from the achieved reliability than they benefit from the identity privacy without the cid.

DTLS 1.2 CID cloud demonstration

Californium's sandbox already supports the DTLS 1.2 Connection ID with the early assigned code-points. Scandium from 2.0.0-M16 uses TLS12_CID(25/0x19) for the new record type and CONNECTION_ID(53/0x35) for the new hello extension type.

The sandbox could be reached by coaps://californium.eclipse.org .