2020年10月28日(水) 5:13 Martin Duke <[email protected]>: > 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?) >
The problem here is that an attacker might establish a connection, then send small-sized datagrams containing PATH_CHALLENGE frames. Therefore, if we are to have a stringent amplification limit for path migration (BTW, I like Ian's proposal), we should better block this attack vector too. So maybe something like "MUST NOT send PATH_RESPONSE frames in response to PATH_CHALLENGE frame carried by a datagram that is less than 1200 bytes." > 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 >> >> -- Kazuho Oku
