PATH_CHALLENGE MUST be padded as well, so I don't see that as an amplification vector. It might be useful to add language to allow PATH_CHALLENGE to be ignored if not padded (SHOULD ignore?)
In migration, the path usually should have already been pre-validated so there is no attack vector once that happens. But Ian's proposal to use the 3x limit is not so great in the NAT rebinding case. If a small packet causes this, data transfer is going to plummet, and we can't simultaneously verify the path and the MTU. On Tue, Oct 27, 2020 at 10:04 AM Magnus Westerlund <magnus.westerlund= [email protected]> 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 > >
