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
