Re: Long Headers and Version Negotiation

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] On Behalf Of Martin Duke
> Sent: Friday, January 5, 2018 2:39 PM
> To: IETF QUIC WG <[e-mail]>
> Subject: Long Headers and Version Negotiation
>
>
>
> The invariants draft 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