Re: Back to work

[Magnus Westerlund <[e-mail]>]

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