Subject: Long Headers and Version Negotiation

From: Martin Duke <[email-masked]>
Date: Fri, 5 Jan 2018 14:38:52 -0800

The invariants draft
<https://tools.ietf.org/html/draft-thomson-quic-invariants-00> only
reserves the 0x80 and 0x40 codepoints in the first byte of the packet.

The transport draft suggests that only initial packets should trigger
version negotiation. However, the Initial Packet byte (0xff) is not
invariant. So for version negotiation to work at all, servers must send VN
packets for *any* long header type where the version is unsupported --
otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 servers
would ignore it.

On the other hand, in 0RTT cases this might create a storm of VN packets if
the version is wrong. I suppose clients are probably not sending 0RTT if
they don't know the supported versions.

Am I thinking about this correctly? If so, I'm happy to file an issue, and
a PR if we agree that the correct solution is to reply with VN to all long
headers with unsupported versions.

- Martin Duke

---

From: Nick Banks <[email-masked]>
Date: Fri, 5 Jan 2018 22:46:33 +0000

If you are sending 0-RTT packets then you have connected to this server before and should be able to remember the version you used. The only issue then, is if the server stops supporting a particular version and then you try to reconnect. Either way, a server might want to have some throttling logic for VN packets sent out; but I don’t think it would be the end of the world if it didn’t.

- Nick Banks

From: QUIC [mailto:[email-masked]] On Behalf Of Martin Duke
Sent: Friday, January 5, 2018 2:39 PM
To: IETF QUIC WG <[email-masked]>
Subject: Long Headers and Version Negotiation

The invariants draft<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-thomson-quic-invariants-00&data=02%7C01%7Cnibanks%40microsoft.com%7Cd3a2449b9239497e80a608d5548d1eff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636507887456170898&sdata=l1gMfIkx9QmJiJtkHRALPevafNru5A63IwiMsnUaj84%3D&reserved=0> only reserves the 0x80 and 0x40 codepoints in the first byte of the packet.

The transport draft suggests that only initial packets should trigger version negotiation. However, the Initial Packet byte (0xff) is not invariant. So for version negotiation to work at all, servers must send VN packets for any long header type where the version is unsupported -- otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 servers would ignore it.

On the other hand, in 0RTT cases this might create a storm of VN packets if the version is wrong. I suppose clients are probably not sending 0RTT if they don't know the supported versions.

Am I thinking about this correctly? If so, I'm happy to file an issue, and a PR if we agree that the correct solution is to reply with VN to all long headers with unsupported versions.

- Martin Duke

---

From: Martin Duke <[email-masked]>
Date: Fri, 5 Jan 2018 14:51:45 -0800

I agree. The only other alternative I can see is to make 0xff an invariant
for initial packets. I don't have a strong opinion one way or the other.

On Fri, Jan 5, 2018 at 2:46 PM, Nick Banks <[email-masked]> wrote:

> If you are sending 0-RTT packets then you have connected to this server
> before and should be able to remember the version you used. The only issue
> then, is if the server stops supporting a particular version and then you
> try to reconnect. Either way, a server might want to have some throttling
> logic for VN packets sent out; but I don’t think it would be the end of the
> world if it didn’t.
>
>
>
> - Nick Banks
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Martin Duke
> *Sent:* Friday, January 5, 2018 2:39 PM
> *To:* IETF QUIC WG <[email-masked]>
> *Subject:* Long Headers and Version Negotiation
>
>
>
> The invariants draft
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-thomson-quic-invariants-00&data=02%7C01%7Cnibanks%40microsoft.com%7Cd3a2449b9239497e80a608d5548d1eff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636507887456170898&sdata=l1gMfIkx9QmJiJtkHRALPevafNru5A63IwiMsnUaj84%3D&reserved=0>
> only reserves the 0x80 and 0x40 codepoints in the first byte of the packet.
>
>
>
> On the other hand, in 0RTT cases this might create a storm of VN packets
> if the version is wrong. I suppose clients are probably not sending 0RTT if

---

From: Mike Bishop <[email-masked]>
Date: Fri, 5 Jan 2018 22:57:54 +0000

This is actually beneficial, albeit a corner case – if the Initial packet is lost, but the version is unknown, then the 0-RTT packets will still provoke the Version Negotiation packet and the loss doesn’t induce an RTO.

From: QUIC [mailto:[email-masked]] On Behalf Of Martin Duke
Sent: Friday, January 5, 2018 2:52 PM
To: Nick Banks <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Long Headers and Version Negotiation

I agree. The only other alternative I can see is to make 0xff an invariant for initial packets. I don't have a strong opinion one way or the other.

On Fri, Jan 5, 2018 at 2:46 PM, Nick Banks <[email-masked]<mailto:[email-masked]>> wrote:
If you are sending 0-RTT packets then you have connected to this server before and should be able to remember the version you used. The only issue then, is if the server stops supporting a particular version and then you try to reconnect. Either way, a server might want to have some throttling logic for VN packets sent out; but I don’t think it would be the end of the world if it didn’t.

- Nick Banks

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Martin Duke
Sent: Friday, January 5, 2018 2:39 PM
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Long Headers and Version Negotiation

- Martin Duke

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jan 2018 10:19:04 +1100

We had a similar concern with TLS, in that a server that advertises
0-RTT support could later decide to disable TLS 1.3.  That leads to a
similar sort of issue: 0-RTT data hitting a server that doesn't know
how to handle it.  We concluded that advertising 0-RTT was a
commitment to support that configuration until the 0-RTT ticket
expired (at least to the extent that the server wouldn't choke on
0-RTT).

Mike's right in saying that QUIC is somewhat better able to cope.  Not
using ordered delivery means that this turns into a flood of version
negotiation packets rather than anything immediately fatal.  That
said, we could recommend that servers treat 0-RTT-enabled tickets as a
commitment to support a given version.  That effectively means
disabling 0-RTT on versions that you plan to decommission.  Maybe
that's a manageability consideration more than a protocol one.

On Sat, Jan 6, 2018 at 9:46 AM, Nick Banks <[email-masked]> wrote:
> The invariants draft only reserves the 0x80 and 0x40 codepoints in the first
> byte of the packet.
>
>
>
> packets for any long header type where the version is unsupported --
> Am I thinking about this correctly? If so, I'm happy to file an issue, and a
> PR if we agree that the correct solution is to reply with VN to all long

---

From: Martin Duke <[email-masked]>
Date: Sun, 7 Jan 2018 18:58:40 -0800

I am not all that concerned about the VN storm. I'll file an issue, and
would like input on "treat all long headers as initials" vs. "Make 0xff
invariant".

On Jan 7, 2018 3:19 PM, "Martin Thomson" <[email-masked]> wrote:

> if

---

From: Christian Huitema <[email-masked]>
Date: Sun, 7 Jan 2018 17:12:02 -1000

About 0xFF invariant -- that was one of the issues we found during the December 18 interop. The first byte in the VN packet is unspecified so picoquic was setting it to 0xFF. Legit, but somewhat unexpected.

Another point about VN storms. Servers can of course implement some kind of pacing. They should also only send VN in response to packets that are at least 1200 bytes, since CI must be at least that.

-- Christian Huitema 

> On Jan 7, 2018, at 4:58 PM, Martin Duke <[email-masked]> wrote:
> 
> I am not all that concerned about the VN storm. I'll file an issue, and would like input on "treat all long headers as initials" vs. "Make 0xff invariant".
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jan 2018 14:32:59 +1100

On Mon, Jan 8, 2018 at 2:12 PM, Christian Huitema <[email-masked]> wrote:
> About 0xFF invariant -- that was one of the issues we found during the
> December 18 interop. The first byte in the VN packet is unspecified so
> picoquic was setting it to 0xFF. Legit, but somewhat unexpected.

That's why we have these interop things.  The question is whether it
is surprising enough to warrant a change.

> Another point about VN storms. Servers can of course implement some kind of
> pacing. They should also only send VN in response to packets that are at
> least 1200 bytes, since CI must be at least that.

>From Section 7.1:

For servers, packets that aren’t associated with a connection
potentially create a new connection. However, only packets that use
the long packet header and that are at least the minimum size defined
for the protocol version can be initial packets.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 7 Jan 2018 17:49:48 -1000

> On Jan 7, 2018, at 5:32 PM, Martin Thomson <[email-masked]> wrote:
> 

Eh eh...
> for the protocol version can be initial packets.

So if we just suggested that 0-RTT packets should be shorter than the minimum size, we would be covered.

---

From: Martin Duke <[email-masked]>
Date: Sun, 7 Jan 2018 19:57:12 -0800

I filed issue 1038
https://github.com/quicwg/base-drafts/issues/1038