Subject: [quicwg/base-drafts] Connection ID lengths 1, 2 and 3 bytes can't be encoded (#1570)

From: Marten Seemann <[email-masked]>
Date: Sun, 15 Jul 2018 11:36:38 -0700

The connection IDs can be either 0 bytes or anything between 4 and 18 bytes (inclusive). Lengths of 1, 2 and 3 bytes are not possible.

There are several use cases that would benefit from using shorter connection IDs, especially in p2p applications. An endpoint could encode the length of the connection ID into the first few bits, and then starts using 1 byte connection IDs first, and successively moves to longer lengths only when handling more connections. For p2p hosts, in many cases 2 bytes would be sufficient for all use cases.

In the connection ID length field in the Long Header, we only have 4 bits to encode a range of 19 values (we want 0 byte connection IDs, and we want to support 18 byte connection IDs), so *some* values have to be left out. It seems there are few use cases for 13, 14 and 15 bytes.

We could achieve this by changing the definition of the length to:

>  An encoded length between 0 and 12 inclusive indicates that the connection ID is also 0 to 12 octets in length. Any larger value is increased by 3 to get the full length of the connection ID, producing a length between 16 and 18 octets inclusive. 

If people are supportive of this change, I'd be happy to write a PR.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1570

---

From: janaiyengar <[email-masked]>
Date: Sun, 15 Jul 2018 11:55:13 -0700

We should fix this, especially since the CIDs will become ossified quickly. Skipping 13-15 is odd, but that's going to be true of anything we skip. I'm supportive.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1570#issuecomment-405110534

---

From: MikkelFJ <[email-masked]>
Date: Sun, 15 Jul 2018 12:26:14 -0700

There are also use cases in radio based sensor networks and also wired lightweight protocols that use QUIC without IP/UDP framing. For example an I2C bus or similar microcontroller network might use QUIC for security and routing but really care about keeping individual message frames short. Such use cases might, BTW also opt to truncate the trailing authentication tag.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1570#issuecomment-405112346

---

From: ekr <[email-masked]>
Date: Sun, 15 Jul 2018 15:17:05 -0700

I don't have any objection to shorter lengths, but my memory of the
discussion in Melbourne was that some people opposed short IDs because the
natural way to allocation them was with some kind of counter (though I
suppose you could build a shuffle table) and that therefore this would
create privacy leaks

-Ekr

On Sun, Jul 15, 2018 at 11:36 AM, Marten Seemann <[email-masked]>
wrote:

> The connection IDs can be either 0 bytes or anything between 4 and 18
> bytes (inclusive). Lengths of 1, 2 and 3 bytes are not possible.
>
> There are several use cases that would benefit from using shorter
> connection IDs, especially in p2p applications. An endpoint could encode
> the length of the connection ID into the first few bits, and then starts
> using 1 byte connection IDs first, and successively moves to longer lengths
> only when handling more connections. For p2p hosts, in many cases 2 bytes
> would be sufficient for all use cases.
>
> In the connection ID length field in the Long Header, we only have 4 bits
> to encode a range of 19 values (we want 0 byte connection IDs, and we want
> to support 18 byte connection IDs), so *some* values have to be left out.
> It seems there are few use cases for 13, 14 and 15 bytes.
>
> An encoded length between 0 and 12 inclusive indicates that the connection
> ID is also 0 to 12 octets in length. Any larger value is increased by 3 to
> get the full length of the connection ID, producing a length between 16 and
> 18 octets inclusive.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1570>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oUzh1HvIDS_VexwowDaDshxQQGlMks5uG4u1gaJpZM4VQV65>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1570#issuecomment-405122659

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jul 2018 12:07:22 -0700

ekr's comment here is right.  You can't use new connection IDs in the same way when the space is too small (arguably 4 is too small, but several people wanted 4).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1570#issuecomment-405348255

---

From: MikkelFJ <[email-masked]>
Date: Mon, 16 Jul 2018 14:21:05 -0700

You can't use them the same way for sure, but they are useful in a different way. Unlinkability is not always a concern, or it may happen where linkability would happen anyway, such as a IP tuple but where the port number is not the best option to differentiate connections, e.g. due to avoid OS interference.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1570#issuecomment-405385899