Subject: Re: [TLS] Connection ID Draft

From: Matt Caswell <[email-masked]>
Date: Thu, 2 Nov 2017 16:32:18 +0000

On 17/10/17 22:35, Martin Thomson wrote:
> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK) <[email-masked]> 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])
> }

Just skimming this old thread...doesn't this fail in the case where the
five tuple has been reused? In that case five_tuples.lookup will return
an old stale connection which the server thinks is still valid so we
never get to lookup the connection id. With an explicit marking we would
not fail in this scenario.

Matt

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Nov 2017 10:34:04 +1100

> not fail in this scenario.

I'm assuming that once a connection is closed (or moved), the entry is
removed.  There's some fudging needed there for migrations (it might
be in two places at once for a while), but I don't see a significant
problem.  (Note that I didn't include the update parts of this code -
when a packet decrypts successfully, you need to update the
five_tuples list.)

---

From: Matt Caswell <[email-masked]>
Date: Fri, 3 Nov 2017 09:15:12 +0000

> when a packet decrypts successfully, you need to update the

Imagine the scenario where you have a large number of clients sitting
behind a NAT middlebox talking to a server. If the NAT crashes/reboots
then all of the associations are lost and the server will not know to
remove any of them from its table. It then seems highly likely that a
tuple will get reused with stale connections in the server's table.

It was my understanding that it is precisely this sort of problem that
this draft was attempting to address. Explicit marking would solve this.

Matt

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Nov 2017 20:28:45 +1100

> this draft was attempting to address. Explicit marking would solve this.

Yes, and the connection ID is that marking.  The contention - I think
- is what to do when there is a mix of marked connections and
unmarked.

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Fri, 3 Nov 2017 09:59:06 +0000

On 03/11/2017, 09:28, "TLS on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:
> > It was my understanding that it is precisely this sort of problem
> > that this draft was attempting to address. Explicit marking would
> > solve this.
> 

Specifically, the two lines of contention seem to be:
- On the receiver side, whether to favour survival of CID v non-CID
  bearing sessions;
- Packet analyser friendliness (i.e., being able to correctly parse
  the stream without requiring it to keep state.)

Cheers

---

From: Matt Caswell <[email-masked]>
Date: Fri, 3 Nov 2017 10:12:11 +0000

> - is what to do when there is a mix of marked connections and

Right - where you have a mix of packets with connection ID and no
connection ID you don't know whether to look for one or not. IMO this
draft won't really be addressing the issues unless it includes a
mechanism for determining that.

Matt

---

From: Simon Bernard <[email-masked]>
Date: Wed, 8 Nov 2017 14:37:52 +0100

Hi,

Here are the scenarios we would be interested to see covered by this CID 
extension.

1. Clients in unstable IP environment (like NAT)
2. stateless middlebox (like load balancer) with mixed CID and no CID 
connections.
3. stateless packet introspection (wireshark), with mixed CID and no CID 
connections.

Linkability is not an issue for us, we have almost the same kind of 
linkability than with fixed IP.

Point 1. seems already supported.
Points 2. and 3. seems not ok for now because its not so easy to know if 
a record contains a CID or not.

To know if a record contains a CID, the proposed solution in this thread 
are:
- using content type (not sure to see how?)
- using version (not available in DTLS 1.3? impact on current 
implementation?)
- add a MAC for CID (bandwidth cost?)

I don’t know which one could be the best, but I have one question: how 
to know the CID length for stateless middlebox or packet introspector ?

Simon

Le 03/11/2017 à 11:12, Matt Caswell a écrit :
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls