Again the spec says PATH_CHALLENGE MUST be padded to 1200 On Tue, Oct 27, 2020 at 4:17 PM Kazuho Oku <[email protected]> wrote:
> > > 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 >
