Re: Back to work

[Ian Swett <[e-mail]>]

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 <[e-mail]> wrote:

> Peace,
>
> On Tue, Oct 27, 2020 at 9:35 AM Martin Thomson <[e-mail]> 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
>
>