Subject: [quicwg/base-drafts] Allow longer CIDs (#2749)

From: martinduke <[email-masked]>
Date: Wed, 22 May 2019 07:32:38 -0700

Fixes #2736.

As a straw man, I selected a v1 limit of 48 bytes to reflect comments in London. Note that we cannot grease the unused bits of the CIL fields if we're going to make load balancers robust to version changes (which is the point in having CIDs in the invariants, IIRC).
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2749

-- Commit Summary --

  * longer CIDs
  * fix unintentional diffs
  * fix typos

-- File Changes --

    M draft-ietf-quic-invariants.md (38)
    M draft-ietf-quic-transport.md (101)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2749.patch
https://github.com/quicwg/base-drafts/pull/2749.diff

-- 
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/pull/2749

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 22 May 2019 07:45:11 -0700

It would be nice if an invalid length could not be expressed.  Is 48 a completely arbitrary number?

-- 
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/pull/2749#issuecomment-494834355

---

From: martinduke <[email-masked]>
Date: Wed, 22 May 2019 07:47:20 -0700

@dtikhonov somewhat arbitrary. @ianswett wanted it smaller than a 64B cacheline; the most extreme use case we came up with was "more than 32B".

However, I'd prefer that we not artificially limit it in the invariants, because my imagination is limited.

-- 
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/pull/2749#issuecomment-494835310

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 07:51:15 -0700

It's great to have CID's of length 1..3 bytes, but perhaps some guidelines are needed as there is an increased collision chance and some attack mitigations might make assumptions on the CID being at least 32 bits.

-- 
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/pull/2749#issuecomment-494836978

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 14:55:37 +0000 (UTC)

martinthomson commented on this pull request.

> @@ -143,11 +143,13 @@ version-specific semantics are marked with an X.
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Version (32)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|DCIL(4)|SCIL(4)|
+|    DCIL (8)   |

I think that we should have a varint length.

> @@ -2345,7 +2345,7 @@ following layout:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|0|1|               Unpredictable Bits (182..)                ...
+|0|1|               Unpredictable Bits (422..)                ...

This one remains particularly thorny.  Now there is no way to generate a stateless reset that is a reasonable size.  Yes, this is technically bounded, but now the naive stateless reset is considerably bigger than the packet that triggers it in many more cases.

-- 
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/pull/2749#pullrequestreview-240686914

---

From: martinduke <[email-masked]>
Date: Wed, 22 May 2019 07:56:29 -0700

martinduke commented on this pull request.

  0                   1                   2                   3

Isn't there a rule that you can't send a reset that's biger than the originating packet?

-- 
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/pull/2749#discussion_r286535424

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 07:58:41 -0700

mikkelfj commented on this pull request.

  0                   1                   2                   3

eternal ping pong rule

-- 
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/pull/2749#discussion_r286536723

---

From: martinduke <[email-masked]>
Date: Wed, 22 May 2019 07:59:41 -0700

@martinduke pushed 1 commit.

ae51a064536f4a40b5f13132e5a9531e3b95de84  remove trailing whitespace

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2749/files/d8d90dc29804a2a370044497f1885db30949ec18..ae51a064536f4a40b5f13132e5a9531e3b95de84

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 08:00:10 -0700

0                   1                   2                   3

you can get around sending a reset only once per every 4 received packets on average, but consensus dislike random.

-- 
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/pull/2749#discussion_r286537549

---

From: martinduke <[email-masked]>
Date: Wed, 22 May 2019 08:12:58 -0700

Discussed in the room; though varints would help with greasing; it is a pain and creates serious problems for current deployments.

-- 
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/pull/2749#discussion_r286544131

---

From: martinduke <[email-masked]>
Date: Wed, 22 May 2019 08:23:54 -0700

0                   1                   2                   3

discussed in London; I think we're OK with this

-- 
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/pull/2749#discussion_r286549929

---

From: martinduke <[email-masked]>
Date: Wed, 22 May 2019 08:25:03 -0700

@DavidSchinazi Raises a good point; for purposes of Version Negotiation, v1 servers need to accommodate longer CIDs (up to 255 bytes). I'll make the change.

-- 
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/pull/2749#issuecomment-494851529

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 22 May 2019 15:26:10 +0000 (UTC)

> for purposes of Version Negotiation, v1 servers need to accommodate longer CIDs (up to 255 bytes).

-- 
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/pull/2749#issuecomment-494851953

---

From: martinduke <[email-masked]>
Date: Wed, 22 May 2019 15:33:38 -0700

@dtikhonov in v2, we might allow 255B CIDs. So to send a proper VN packet in response to v2 we need to handle that entire CID.

-- 
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/pull/2749#issuecomment-494998912

---

From: David Schinazi <[email-masked]>
Date: Thu, 23 May 2019 08:02:10 -0700

This PR looks good to me. Thanks for making an encoding that we can deploy in parallel with older versions on the same server.

-- 
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/pull/2749#issuecomment-495256924

---

From: martinduke <[email-masked]>
Date: Fri, 31 May 2019 11:58:00 -0700

63e7dd65909b908c084d366a90c13804faa7e159  VN packets may have 255B CIDs

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2749/files/ae51a064536f4a40b5f13132e5a9531e3b95de84..63e7dd65909b908c084d366a90c13804faa7e159

---

From: martinduke <[email-masked]>
Date: Fri, 31 May 2019 12:03:17 -0700

OK, the transport drafts now acknowledges that it may have to send VN with CIL > 48 bytes.

I believe all known issues are resolved.

-- 
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/pull/2749#issuecomment-497825958

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 31 May 2019 15:32:33 -0700

janaiyengar commented on this pull request.

A few nits

 Destination Connection ID:
 
-: The Destination Connection ID field follows the connection ID lengths and is
-  either 0 bytes in length or between 4 and 18 bytes.
-  {{negotiating-connection-ids}} describes the use of this field in more detail.
+: The Destination Connection ID field follows the DCIL and is between 0 and 48
+  bytes in length. {{negotiating-connection-ids}} describes the use of this
+  field in more detail.
+
+SCIL:
+
+: The byte following the destination Connection ID contains the length in bytes

```suggestion
: The byte following the Destination Connection ID contains the length in bytes
```

 Destination Connection ID:
 
-: The Destination Connection ID field follows the connection ID lengths and is
-  either 0 bytes in length or between 4 and 18 bytes.
-  {{negotiating-connection-ids}} describes the use of this field in more detail.
+: The Destination Connection ID field follows the DCIL and is between 0 and 48
+  bytes in length. {{negotiating-connection-ids}} describes the use of this
+  field in more detail.
+
+SCIL:
+
+: The byte following the destination Connection ID contains the length in bytes
+  of the source connection ID field that follows it.  This length is encoded as

```suggestion
  of the Source Connection ID field that follows it.  This length is encoded as
```

> @@ -3577,6 +3588,10 @@ connection IDs gives clients some assurance that the server received the packet
 and that the Version Negotiation packet was not generated by an off-path
 attacker.
 
+As future versions of QUIC may support Connection IDs larger than the version 1
+limit, Version Negotiation Packets will sometimes exceed the Connection ID

```suggestion
limit, Version Negotiation Packets MAY carry Connection IDs that are longer than 48 bytes.
```

> @@ -3577,6 +3588,10 @@ connection IDs gives clients some assurance that the server received the packet
 and that the Version Negotiation packet was not generated by an off-path
 attacker.
 
+As future versions of QUIC may support Connection IDs larger than the version 1
+limit, Version Negotiation Packets will sometimes exceed the Connection ID
+length limit of 48 bytes in version 1.

```suggestion

```

-- 
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/pull/2749#pullrequestreview-244543236