Subject: [quicwg/base-drafts] Allow servers to omit version negotiation in response to 0-RTT packets. (#1758)

From: Kyle Nekritz <[email-masked]>
Date: Mon, 17 Sep 2018 19:28:04 +0000 (UTC)

You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Allow servers to omit version negotiation in response to 0-RTT packets.

-- File Changes --

    M draft-ietf-quic-transport.md (5)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1758.patch
https://github.com/quicwg/base-drafts/pull/1758.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/1758

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 17 Sep 2018 12:31:35 -0700

This looks great to me, maybe you can elaborate on the problem this is solving in the description of the 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/pull/1758#issuecomment-422141096

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Sep 2018 14:17:03 -0700

Gotta say, I don't understand this change.  What does "explicit knowledge of another QUIC version" have to do 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/1758#issuecomment-422174724

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 15:28:28 -0700

It took me ages to understand this one, and I needed @janaiyengar's help.  Maybe the right thing to say is that servers don't have to send Version Negotiation in response to every packet and they can use their own heuristics for deciding 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/1758#issuecomment-424146440

---

From: Kyle Nekritz <[email-masked]>
Date: Mon, 24 Sep 2018 16:54:56 -0700

Sorry about my lack of description here. The issue is that if we are doing 0-RTT and the server wants to negotiate a different versions, it will send a version negotiation packet in response to each 0-RTT packet in addition to the client initial. This isn't a huge issue normally as clients will only try 0-RTT when they have recent prior knowledge of the server, but it's not ideal during new version rollouts.

To prevent these duplicate version negotiation packets, the server can omit version negotiation responses when it knows they are unnecessary (for example in response to 0-RTT packets which always will come after the client initial). However, applying this too broadly comes with some ossification risk, if a server never sends version negotiation in response to 0-RTT packets as defined in v1 (without also checking the exact version), that will cause some ossification of the long header types, which is why I added the "explicit knowledge of another QUIC version" blurb.

-- 
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/1758#issuecomment-424162821

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Sep 2018 14:09:40 -0700

This is a corner-case of a corner-case.  In the general case, if you don't recognize the client's proposed version, you have to send VN because you can't interpret anything about it and the spec says that you SHOULD NOT try.  But here, you know the version you've received well enough to know what packet types you don't want to send VN in response to, but you don't actually speak that version.  To me, that sounds like a version that's been deprecated for security reasons; outside of that, you either know a version or you don't.

I'd agree with Martin, the right framing here is that servers aren't required to send VN in response to every packet, but are allowed to use heuristics to limit the number they send.  That could be based on packet type if it knows but refuses to speak the version, or by having a short-lived cache of client IP/ports to which you've recently send VN packets, etc.

-- 
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/1758#issuecomment-424502413