I think Ian’s recommendation is a good one. It seems well balanced and in line with the existing principles.
Also, on the topic of factoring the cost of the handshake in here, I don’t see that as a significant hurdle. Once you have a connection, you can do minimal work to keep the normal path alive and continue to use it as the amplification vector. Then there’s no absolute limit to the number of times it can be used for a path validation attempt, AFAIK. Thanks, - Nick From: QUIC <[email protected]> On Behalf Of Ian Swett Sent: Tuesday, October 27, 2020 6:12 AM To: Töma Gavrichenkov <[email protected]> Cc: IETF QUIC WG <[email protected]>; Martin Thomson <[email protected]> Subject: Re: Back to work 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. Thanks, Ian On Tue, Oct 27, 2020 at 3:52 AM Töma Gavrichenkov <[email protected]<mailto:[email protected]>> wrote: Peace, On Tue, Oct 27, 2020 at 9:35 AM Martin Thomson <[email protected]<mailto:[email protected]>> wrote: > 25x amplification isn't anything to celebrate, but you might > say that the setup cost and other inherent limitations mean > that it is rarely that bad. This is a price an attacker only needs to pay once. If this code leaks to one of the myriad Mirai forks available on Github, the cost would be effectively zero then. > Recommending that implementations limit the number > probes and the number of probed paths might then be > sufficient. _Recommendations_ never worked well for DDoS prevention in the past. I think Section 11.3 of RFC 7252 and what happened next is the most recent example of that. -- Töma
