Re: Back to work

[Martin Thomson <[e-mail]>]

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