On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote:
> The following case (NAT box reboot) is problematic:
>
> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
> host B (B.1);
> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
> 3. The NAT box reboots (all previous 5-tuple mappings are lost);
> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
> meanwhile);
>
> How is B.1 supposed to correctly interpret the bytes starting at offset
> +11? (For what it knows, it could be CID from A.1 or the length field
> from A.2.)
I don't think that this is a problem.
connection = five_tuples.lookup(packet.five_tuple)
if (!connection) {
connection =
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
}
if (!connection) {
// is this a ClientHello? otherwise drop it
}
Of course this doesn't help you with A.2, but that's why this draft exists.
If the server can insist on connection IDs from all clients (in the
far future perhaps, or for an entirely new protocol), then the code is
more simply:
connection =
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
if (!connection) {
// is this a ClientHello? otherwise drop it
}
> I might be missing something fundamental here, but isn't the length
> encoded in the CID field on the wire?
Not by my understanding. There isn't any need (the intent is to have
the CID only consumable by the entity that created it, and any others
that it collaborates with, like a load balancer).
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
