Re: Handling consensus on design issues identified during AD Review

[Kazuho Oku <[e-mail]>]

Thanks to chairs / editors / ADs for pushing the draft forward.

My comments inline.

2020年10月20日(火) 21:32 Lars Eggert <[e-mail]>:

> 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