Kazuho has identified the set of changes that I too think we should take. Thanks Kazuho.
On Wed, Oct 21, 2020, at 01:32, Kazuho Oku wrote: > Thanks to chairs / editors / ADs for pushing the draft forward. > > My comments inline. > > 2020年10月20日(火) 21:32 Lars Eggert <[email protected]>: > > Hi, > > > > we are getting very close to publishing a new set of drafts that address > > Magnus' AD Review comments and will then be taken to IETF Last Call. > > > > The vast majority of changes were editorial, but there were three "design" > > issues that changed the protocol in non-editorial ways, for which we need > > to confirm WG consensus. These issues are: > > > > * #4183 Handshake failure (infinite ping-pong) when path MTU is asymmetric > > https://github.com/quicwg/base-drafts/issues/4183 > > Just to make sure, the solution is #4188 (merged on GitHub). > https://github.com/quicwg/base-drafts/pull/4188 > > > * #4216 Connection Migration Failure when Path MTU is asymmetric > > https://github.com/quicwg/base-drafts/issues/4216 > > The solution is #4226 (open on GitHub). > https://github.com/quicwg/base-drafts/pull/4226 > > > * #3701 The QUIC-TLS draft should define anti-forgery limits for packet > > lengths up to 2^16 > > https://github.com/quicwg/base-drafts/issues/3701 > > The solution is #4175 (merged on GitHub). > https://github.com/quicwg/base-drafts/pull/4175 > > Regarding #4183 and #4216, I have a tiny preference, in short, I think > #4253 (PR #4254) should be merged as part of the pair. > https://github.com/quicwg/base-drafts/pull/4254 > > The two issues cover the same problem: how to fail when the MTU of the > path in one direction is below 1200 bytes. Both say "MUST pad to > datagrams to at least 1200 bytes," and that's fine. OTOH, #4183 says > that a receiver MAY close the connection if the sender fails to meet > the padding requirement. #4216 does not provide guidance to the > receiver side. > > For #4216, it is my understanding that we have to state that the > receiver MUST NOT try to enforce the behavior of the sender, as the > size of UDP datagrams is not authenticated. Ignoring unauthenticated > signal is the basis of a secure transport protocol. That in turn raises > the question on if the guidance that we adopted in #4183 (i.e. MAY > close) has been correct. To be precise, it is questionable if Initial > packets are "authenticated," as they are not protected by keys only > known to the endpoints. But still, it sticks out from the design > principle of a secure transport protocol. > > That's why I think we should merge #4254 alongside the other two, so > that we'd be principled, that we'd have less rules. > > > > > > > The resolutions for these issues are linked from the respective issue > > pages, and will be merged into the text of the upcoming draft revisions, > > together with the editorial changes. > > > > Instead of performing a separate WG Last Call and further delaying the > > start of the IETF Last Call, we've agreed with our AD to judge WG consensus > > on these design changes as part of the IETF Last Call. > > > > Thanks, > > Lars and Lucas > > > -- > Kazuho Oku
