Subject: Re: [quicwg/base-drafts] introduce a version alias mechanism (#2573)

From: Martin Thomson <[email-masked]>
Date: Mon, 01 Apr 2019 00:03:20 -0700

@marten-seemann can you open an issue to track 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/2573#issuecomment-478460326

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 01 Apr 2019 10:03:31 +0000 (UTC)

philsbln commented on this pull request.

> @@ -4115,6 +4130,25 @@ preferred_address (0x000d):
 ~~~
 {: #fig-preferred-address title="Preferred Address format"}
 
+version_aliases (0x000e):
+
+: A list of version numbers that the server accepts as an alias for the
+  currently used versions. This transport parameter is only sent by the server.
+  Every version alias contains a lifetime in seconds. The alias is only valid
+  for that lifetime, clients MUST NOT use it after expiry.
+
+~~~
+   struct {
+     uint32 VersionNumber;
+     varint Lifetime;

Making the Lifetime a fixed uint32 in milliseconds would limit the alias to roughly two month. Could be a practical solution as the variant encoding does not really save space for lifetimes in the range of days.

-- 
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/2573#discussion_r270796458

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 01 Apr 2019 10:20:28 +0000 (UTC)

> @@ -3246,7 +3246,21 @@ Implementors are encouraged to register version numbers of QUIC that they are
 using for private experimentation on the GitHub wiki at
 \<https://github.com/quicwg/base-drafts/wiki/QUIC-Versions\>.
 
-
+## Version Aliases
+
+In order to avoid ossification of the version number defined by this draft,
+servers announce a list of version numbers that they interpret as an alias for
+the version number used in this draft. Alias versions MUST NOT be a reserved
+version. Servers SHOULD send at least one version alias, and SHOULD frequently
+change the value that they announce. Each version alias contains a lifetime,
+which indicates how long the server will accept this version alias. It also
+contains an initial salt, which is used instead of the initial salt as defined

Even without the salt, the presence of multiple QUIC versions with different salts would force a middle-box to opportunistically decrypt initials using different salts. So if we decide QUIC being blocked because of too much obfuscation is a consideration, this proposal adds to this level even without a salt.

-- 
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/2573#discussion_r270802267

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 01 Apr 2019 14:02:24 -0700

dtikhonov commented on this pull request.

 ~~~

`varint` is not part of the TLS Presentation Language.

-- 
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/2573#pullrequestreview-221344550

---

From: martinduke <[email-masked]>
Date: Mon, 01 Apr 2019 21:38:13 -0700

@martinthomson I believe this targets #2496.

-- 
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/2573#issuecomment-478841370

---

From: Marten Seemann <[email-masked]>
Date: Mon, 01 Apr 2019 21:41:35 -0700

marten-seemann commented on this pull request.

 ~~~

Right. I was hoping for some help from people more familiar with the TLS presentation language on how to write it. We're using varints for all the other transport parameters, but we successfully managed to never actually use presentation language.

-- 
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/2573#discussion_r271131977

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 08 Apr 2019 18:45:06 -0700

janaiyengar commented on this pull request.

 ~~~

I like @philsbln 's suggestion of using uint32 here.

-- 
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/2573#discussion_r273298420

---

From: Martin Thomson <[email-masked]>
Date: Mon, 08 Apr 2019 19:31:01 -0700

martinthomson commented on this pull request.

As noted on the list, a few major items:

* This might be better as a NEW_TOKEN addition.
* This needs more thorough treatment of linkability.
* Some discussion of how to generate these values would be advisable.  That doesn't need to include the tricky bit, which is how you manage this in anticipation of the deployment of a new version, but it does need to have at least an example of how to do this without messing it up.

 ~~~
 
+     opaque InitialSecret<20>;

You want `opaque InitialSalt[20];` or `opaque InitialSalt<20..32>;`  with appropriate values for minimum and maximum.
```suggestion
     opaque initial_secret[20];
```

 ~~~

```suggestion
     uint32 lifetime_ms;
```

As others have suggested, include the units.

-- 
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/2573#pullrequestreview-224167569

---

From: Marten Seemann <[email-masked]>
Date: Mon, 08 Apr 2019 19:35:09 -0700

@marten-seemann pushed 1 commit.

9d1090e27f4f596ceedd0841a7929a914af7623d  make the lifetime a uint32

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2573/files/2e3a99eb39f54b4ccb35f1a5d0a8ebfe31e41314..9d1090e27f4f596ceedd0841a7929a914af7623d

---

From: MikkelFJ <[email-masked]>
Date: Mon, 08 Apr 2019 22:25:29 -0700

mikkelfj commented on this pull request.

 ~~~

```suggestion
  Every version alias contains a lifetime in milliseconds. The alias is only valid
```

-- 
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/2573#pullrequestreview-224197423

---

From: Marten Seemann <[email-masked]>
Date: Tue, 09 Apr 2019 02:54:16 -0700

9e77f1168e0b19e3fe0c40344acd430d6c1f705f  change the lifetime to milliseconds

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2573/files/9d1090e27f4f596ceedd0841a7929a914af7623d..9e77f1168e0b19e3fe0c40344acd430d6c1f705f

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 09 Apr 2019 04:10:04 -0700

I just realised that requiring the server to announce (some of the) version aliases over the whole lifetime may give us downgrade protection for free. That also allows us to keep version alias and version downgrade protection separate.

+## Version Aliases
+
+In order to avoid ossification of the version number defined by this draft,
+servers announce a list of version numbers that they interpret as an alias for
+the version number used in this draft. Alias versions MUST NOT be a reserved
+version. Servers SHOULD send at least one version alias, and SHOULD frequently
+change the value that they announce. Each version alias contains a lifetime,
+which indicates how long the server will accept this version alias. It also
+contains an initial salt, which is used instead of the initial salt as defined
+in section 5.2 of {{QUIC-TLS}}. The list of version aliases is sent in the
+server's Transport Parameters (see {{transport-parameter-definitions}}).
+
+Clients SHOULD remember the aliases and use it for subsequent connections to the
+same server in the future. This applies to both 0-RTT connection as well as
+connections that don't use 0-RTT.

We should add a note that Version Aliases must not be advertised during version negotiation

```suggestion
Version aliases MUST NOT be advertised in version negotiation Packets to avoid conflicts with future versions and experiments.
```

 ~~~
 
+  Every version alias contains a lifetime in milliseconds. The alias is only valid

Should we require the server to announce (some) of the version aliases during their whole lifetime to enable the client to detect downgrade attacks?

-- 
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/2573#pullrequestreview-224333650

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Apr 2019 17:46:57 -0700

~~~

If the idea that this lifetime is also a commitment to support a given version, then this isn't really a fully effective downgrade-prevention mechanism.  I expect that we'll see something good on that shortly.

I would instead prefer to say that the server is required to honour the alias for the entire advertised lifetime *unless* it also stops supporting that QUIC version.

-- 
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/2573#discussion_r273755194

---

From: MikkelFJ <[email-masked]>
Date: Tue, 09 Apr 2019 22:47:44 -0700

I'm a bit concerned with unbounded amounts of aliases being dumped on the client. If the alias is tied to a token, a client can just drop excess tokens and aliases, but if the design somehow evolves into a many headed alias thing, there could be some abuse/resource issues.

Wouldn't it be reasonable to limit this to a single alias?

A future version linked to downgrade protection and version negotiation could have a more complicated pattern, with more time for analysis and design.

-- 
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/2573#issuecomment-481542682

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Wed, 10 Apr 2019 00:51:40 -0700

~~~

I don't consider this a fully effective downgrade-prevention mechanism, but it provides a mechanism for the client to detect on-path version tapering: If the client gets a version negotiation packet in return to an alias version and receives the same version alias that failed again, it can be sure someone is doing a downgrade attack (or the server is horribly broken).

-- 
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/2573#discussion_r273829957

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Wed, 10 Apr 2019 07:57:40 +0000 (UTC)

I consider the whole version alias mechanism must be strictly optional for client and server. If it is used, it may provide an early signal for version negotiation tapering.
The server MUST NOT assume that the client uses any of the version aliases, but the server MUST accept all version aliases it presented the client with during their lifetime unless it also stops supporting the aliased QUIC version (thanks @martinthomson ).

-- 
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/2573#issuecomment-481580664

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 12 Apr 2019 02:41:02 +0000 (UTC)

Asking mostly out of curiosity: do we need to scramble (or protect) other fields of a long header packet as well?

The (original) argument for having a version alias is to protect against accidental ossification of the protocol. That could happen on the other fields of v1 packet as well; namely the non-invariant fields of the first octet and the CIDL fields. If we scramble CIDL fields, it would not matter if the rest of the fields (e.g., token length) were kept as-is, assuming that the CID lengths have enough randomness to randomize the position of such fields.

Though the downside would be that servers would no longer be able to use the token to decipher the actual value of version number field.

-- 
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/2573#issuecomment-482414853

---

From: MikkelFJ <[email-masked]>
Date: Thu, 11 Apr 2019 21:59:44 -0700

That could be problematic for load balancers. But if they don’t know the version it might be bad anyway?

-- 
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/2573#issuecomment-482437626

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 12 Apr 2019 00:11:19 -0700

@marten-seemann Maybe I should have been more specific. The remaining vectors that are prone to ossification are:
* non-invariant bits of the first octet
* the restrictions on how CIDL is used in v1
* the Token Length field (the position is dependent on the values of CIDL fields)
* the Length field (the position is dependent on the values of CIDL fields and the Token Length field)

For example, I would not be surprised to see a middlebox checking that the Token Length field contains a reasonable value regardless of the value of the version number field.

-- 
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/2573#issuecomment-482464439

---

From: Nick Banks <[email-masked]>
Date: Fri, 12 Apr 2019 13:33:41 +0000 (UTC)

I do fear that this feature will make a generic, independent DDoS solution practically impossible. The more I talk to folks on the DDoS side, the more push back I get from **any** type of coordination between backend servers and the DDoS device. If there is no coordination, then the device will not understand these aliased version numbers; and therefore will not be able to reply with a version specific response (Retry).

The **only** course of action the device will have is to send back a VN packet with a reserved field, and drop the incoming packets for new connections. This is definitely not ideal, as I have no idea how clients would use this for back off logic. I'd assume they'd immediately fallback to H2, but when would they try QUIC again?

-- 
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/2573#issuecomment-482576171

---

From: Marten Seemann <[email-masked]>
Date: Fri, 12 Apr 2019 06:48:20 -0700

> I do fear that this feature will make a generic, independent DDoS solution practically impossible. The more I talk to folks on the DDoS side, the more push back I get from any type of coordination between backend servers and the DDoS device. If there is no coordination, then the device will not understand these aliased version numbers; and therefore will not be able to reply with a version specific response (Retry).

We had this discussion on the NY interim, and we concluded that it's a design feature of QUIC that middleboxes can't send retries **unless** they coordinate with the server. That's why we introduced the `original_connection_id` transport parameter, in which the server has to prove knowledge of the connection ID that the client initially used for its connection attempt. If a middlebox wants to send a Retry, it therefore must either communicate this connection ID directly to the server, or (which is the more practical solution) share a key with the server and encode it into the token.

To decode the version number of greased versions, it's not hard to imagine a similar arrangement between the middlebox and the server. Defining an algorithm to do so safely would probably belong in the LB draft.

-- 
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/2573#issuecomment-482581145

---

From: Nick Banks <[email-masked]>
Date: Fri, 12 Apr 2019 07:02:44 -0700

@marten-seemann I agree that it's possible to coordinate these things, but the DDoS device is meant to be a light-wieght plug-in-play device into the path that can be extremely efficient in getting rid of unwanted traffic, all in hardware. The folks in Azure that own the functionality are extremely hesitant to add any additional complexity there that adds additional points of failure. Any kind of protocol between the backend servers and that box increases the complexity of such a device by an order of magnitude. It will take a lot of time to get such a complete solution in place.

In the mean time, we have to continue to have a solution, beyond the default UDP rate limitting algorithms that exist today. We were considering a simple connection close with server busy error code, but that's not possible with this design. So, the only invariant solution would be a practically empty VN response.

-- 
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/2573#issuecomment-482586164

---

From: Martin Thomson <[email-masked]>
Date: Sat, 13 Apr 2019 02:57:44 -0700

A server that uses a load balancer can either not use this mechanism (i.e., it's free) or provide whatever aliasing the load balancer supports.

The point is to have the feature so that some servers support it.  Not all of them have to.

-- 
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/2573#issuecomment-482795232

---

From: martinduke <[email-masked]>
Date: Thu, 18 Apr 2019 14:47:06 -0700

I am not sure why this affects load balancing at all. The CID is part of the invariants, so LBs should be able to read and parse the CID without regard for the other versions.

There is a legitimate coordination problem for DDoS boxes, I agree. However, I'm pretty comfortable for this kind of mechanism not working in cloud deployments -- we're just looking for some big players and the browsers to support this. There's basically no benefit for endpoints except preserving extensibility of the protocol.

-- 
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/2573#issuecomment-484700688

---

From: Mike Bishop <[email-masked]>
Date: Thu, 18 Apr 2019 15:39:23 -0700

MikeBishop commented on this pull request.

Needs some of the extra text others have noted, plus some agreement issues.

While we will eventually need to write a full VN specification, it might also be worth mentioning some implications here.  While we're not specifying the generation algorithm, let's be pedantic and say that the server MUST NOT advertise as an alias a version number for some other version it actually speaks.  As a corollary, if the server advertises as an alias some version number that the client actually supports, the client SHOULD assume the server doesn't support that version.

-
+## Version Aliases
+

Antecedent agreement.  Many possibilities:
- ...remember the aliases and use **them**
- ...remember the **list of** aliases and use it
- ...remember **one of** the aliases and use it

 ~~~

```suggestion
  currently used version. This transport parameter is only sent by the server.
```

 ~~~

```suggestion
: A list of version numbers that the server accepts as aliases for the
```

 ~~~

```suggestion
  for that lifetime. Clients MUST NOT use an expired alias.
```

Comma splice.

-
+## Version Aliases
+

```suggestion
servers announce a list of version numbers that they interpret as aliases for
```

-
+## Version Aliases
+

This feature is being proposed to grease middleboxes; reserved versions exist to grease the peer endpoint.

-- 
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/2573#pullrequestreview-228533168

---

From: Mike Bishop <[email-masked]>
Date: Thu, 18 Apr 2019 15:54:48 -0700

@MikeBishop pushed 1 commit.

4e3089df90e67867a6c65b6283515b052cdd723e  Rewrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2573/files/9e77f1168e0b19e3fe0c40344acd430d6c1f705f..4e3089df90e67867a6c65b6283515b052cdd723e

---

From: Marten Seemann <[email-masked]>
Date: Thu, 18 Apr 2019 16:46:26 -0700

1eeb14eb8c24ca18a78d8e5e892c85e2548b6362  Mike's suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2573/files/4e3089df90e67867a6c65b6283515b052cdd723e..1eeb14eb8c24ca18a78d8e5e892c85e2548b6362

---

From: Marten Seemann <[email-masked]>
Date: Thu, 18 Apr 2019 16:53:15 -0700

b085787323b8ba247f239ee0178fb2637e950ce7  be pedantic about supporting alias versions

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 18 Apr 2019 16:53:56 -0700

Thanks for the suggestions, @MikeBishop. I applied all of them.

-- 
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/2573#issuecomment-484726060

---

From: MikkelFJ <[email-masked]>
Date: Thu, 18 Apr 2019 23:54:47 -0700

Version aliases can be used to track connections that are frequent visitors.

-- 
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/2573#issuecomment-484785140

---

From: MikkelFJ <[email-masked]>
Date: Fri, 19 Apr 2019 00:01:25 -0700

> I am not sure why this affects load balancing at all. The CID is part of the invariants, so LBs should be able to read and parse the CID without regard for the other versions.

If the pool of servers handling one version is different from another pool, for example in a blue/green deployment. Since client decides ODCID, you have nothing but the version to route on. You could, however, use a retry get a new DCID so traffic will route correctly.

-- 
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/2573#issuecomment-484786362

---

From: Marten Seemann <[email-masked]>
Date: Fri, 19 Apr 2019 00:05:58 -0700

> If the pool of servers handling one version is different from another pool, for example in a blue/green deployment. Since client decides ODCID, you have nothing but the version to route on. You could, however, use a retry to get a new DCID so traffic will route correctly.

We already have text that you shouldn't use the ODCID for routing anyway. This applies especially in a setup like 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/2573#issuecomment-484787194

---

From: MikkelFJ <[email-masked]>
Date: Fri, 19 Apr 2019 00:09:44 -0700

If you can recognize the ODCID as being a Retry DCID you could.
For a truly original ODCID you shouldn't, I agree.
But it is not so much about blame, as it is about what LB can do and need to do.

-- 
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/2573#issuecomment-484788002

---

From: Marten Seemann <[email-masked]>
Date: Fri, 19 Apr 2019 00:15:54 -0700

> If you can recognize the ODCID as being a Retry DCID you could.

If it's a Retry DCID, it's by definition not an ODCID any more (the O means "original").

-- 
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/2573#issuecomment-484789271

---

From: MikkelFJ <[email-masked]>
Date: Fri, 19 Apr 2019 00:18:16 -0700

Yes, but it is the DCID in the initial packet. A load balancer would not trivially be able to tell the difference between the DCID of two initial packets since there is no RetryInitial packet type.

-- 
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/2573#issuecomment-484789704

---

From: MikkelFJ <[email-masked]>
Date: Fri, 19 Apr 2019 00:21:36 -0700

Or rather, there is, since the token length field would be non-zero.

But what are we arguing about here? I'm just saying a Retry could be used to route to different version, but only if Retry is able to  work across those versions.

-- 
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/2573#issuecomment-484790272

---

From: Mike Bishop <[email-masked]>
Date: Fri, 19 Apr 2019 12:47:45 -0700

> @@ -3251,12 +3251,17 @@ using for private experimentation on the GitHub wiki at
 In order to avoid ossification of the version number defined by this draft,
 servers announce a list of version numbers that they interpret as aliases for
 the version number used in this draft. Alias versions MUST NOT be a reserved
-version. Servers SHOULD send at least one version alias, and SHOULD frequently
-change the value that they announce. Each version alias contains a lifetime,
-which indicates how long the server will accept this version alias. It also
-contains an initial salt, which is used instead of the initial salt as defined
-in section 5.2 of {{QUIC-TLS}}. The list of version aliases is sent in the
-server's Transport Parameters (see {{transport-parameter-definitions}}).
+version. A server MUST NOT advertise an alias version number for a version that
+it actually supports. If the server advertises an alias version number that the
+client actually supports, the client MUST assume the server doesn't support
+that version and ignore the alias.

I don't know that the client has to ignore the alias, per se -- it just needs to be cognizant of what the interpretation of that version will be on that server.  On the other hand, if there's a possibility that the server might acquire support for that version between flights (server upgrade case), perhaps it's better that the client just avoids it entirely after all.

-- 
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/2573#pullrequestreview-228806243

---

From: Mike Bishop <[email-masked]>
Date: Fri, 19 Apr 2019 12:51:01 -0700

> We already have text that you shouldn't use the ODCID for routing anyway. This applies especially in a setup like this.

Per #2026, we don't have such text, actually.

-- 
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/2573#issuecomment-484998078