On 17/10/2017, 22:35, "Martin Thomson" <martin.thom...@gmail.com> wrote:
> 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
> }
This is quite similar to the trial and error / heuristic that I was
mentioning in [1].
Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails to
recognise A.1 as CID-enabled and sends it forward to the crypto handler
when it shouldn't.
It looks simple, but it introduces subtle complexity in that parsing is
not self-contained anymore: it depends on a couple of things (the
connection_ids and five_tuples stores) that in principle should have
nothing to do with making sense of an incoming record.
And the already discussed limitations:
- Fragility on corner cases (e.g., the 5-tuple swap above);
- Forcing middleware to keep state;
- Breaking wireshark & co unless they can see the whole session;
- (Depending on the use case, the cost of the two lookups per record
on the parsing might have a performance impact.)
> > 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).
You are right. For some reasons, I was implying cid was encoded as a
variable-length array. That said, I don't think saving 1 byte here is
worth the self-inflicted pain of making tshark unusable :-)
Cheers
[1] https://www.ietf.org/mail-archive/web/tls/current/msg24575.html
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
