Thanks to everyone for the feedback.
I've written up a draft pull request here:
https://github.com/quicwg/base-drafts/pull/4264
This does something like what Magnus suggests below. It's not pretty, because
in some very common cases path validation could take twice as long, and it's
more complicated, but I think that it is at least principled.
On Wed, Oct 28, 2020, at 04:04, Magnus Westerlund wrote:
> On Tue, 2020-10-27 at 09:12 -0400, Ian Swett wrote:
> > Thanks for summarizing this issue. I think the above discussion is about
> > immediate migration and repeated immediate migrations, but I also wonder if
> > we've introduced a single packet amplification attack by requiring
> > PATH_RESPONSEs be padded on new paths without a requirement on the size of
> > PATH_CHALLENGE(see first item)?
> >
> > Validating a new path
> > If one receives only a PATH_CHALLENGE on a new path, then the server
> > responds with a full-sized PATH_RESPONSE. This seems safe. If a non-padded
> > PATH_CHALLENGE is received on a new path, then the peer is supposed to send
> > a
> > fully padded PATH_RESPONSE on the path, which could be >20x larger. I'm not
> > sure if we care about this, but I wanted to point it out.
> >
> > Immediately migrating to a new path
> > I think we should remove the text about allowing kMinimumWindow each
> > kInitialRtt after migration and change it to the 3x limit. I'm actually
> > surprised the text about 2*kInitialWindow still exists, since recovery says
> > "Until the server has validated the client's address on the path, the amount
> > of data it can send is limited to three times the amount of data received,
> > as
> > specified in Section 8.1 of {{QUIC-TRANSPORT}}.".
> >
> > In order to not get deadlocked by the 3x factor, I think we should change
> > the
> > newly added MUSTs to only apply to path validation prior to migration, not
> > the
> > peer responding to migration.
> >
> > My reasoning is that if a peer migrates prior to validating the path, it
> > means
> > it's either unintentional or they have no other choice, so the migrating
> > peer
> > has implicitly decided that validating PathMTU is not a prerequisite to
> > migrating.
>
> So some quesitons and ideas as I think it is relevant to resolve this as best
> as
> possible.
>
> So isn't this recreating the issue that if the client initiates a migration
> to a
> new path that is not QUIC compatible, by responding with a minimal size packet
> and completing the migration and then if the server performs the path
> verification with 1200 bytes UDP payload it fails. Thus maintaining a broken
> path.
>
> So is there need for the non pre-validated path migration case that one need
> need to do a two step process where one will ACK with minimal packet while
> initiating path validation. If path validatation fails then maybe one need to
> close down the connection as the migration ended up on a path that was unable
> to
> support QUIC. The question here is how to avoid the DoS attack this may open
> up
> if an attack rewrites source address of packets.
>
> So Maybe the path validation needs to be a two step process. First a return
> routability over the new path to verify that it is bi-directional. When that
> has
> been verified one does a test with minimal MTU to prove it to be QUIC
> compatible. This might even be done with application data if there is some
> that
> are available to send.
>
> But, I think that one needs to work through the criterias for when the QUIC
> connection is shut down under the conditions that the path available is not
> supporting 1200 bytes. Also do we end up in a situation where the client needs
> to do the second step itself towards the server to verify the path so that it
> can determine if it needs to try another path if this one doesn't work?
>
> Cheers
>
> Magnus
>
>
> Attachments:
> * smime.p7s
