I agree, thanks Kazuho. On Tue, Oct 20, 2020 at 10:41 AM Martin Thomson <[email protected]> wrote:
> 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 > >
