Re: [quicwg/base-drafts] Path Challenge Padding and Amplification Protection (#4257)

[Martin Thomson <[e-mail]>]

Hmm, @kazuho is right, I can't find any restriction on use of paths after migration.  Our limits for anti-amplification are specifically: handshake, closing, and stateless reset.  No other mention exists.

That doesn't mean that Nick is wrong to have this code though. Without limits, an attacker could connect to a server then spoof a bunch of small packets to cause an amplification attack toward a chosen target.  

We can turn that into a low-grade amplification attack if we allow probes to be exempt from that limit.  It's low-grade then for several reasons.  It is stateful at the server and the connection establishment is expensive.  A single connection can be used to attack multiple targets, but a server won't send many packets to each.  In my half-written migration code, this results in just three packets, which isn't that useful.

After digging in more here, I think that we can make two changes, one the direct response to this issue, but the first is in response to the unstated issue that we don't have anti-amplification protection for migration.

1. Add the 3x rule for any unvalidated path.

2. Allow path probes to ignore the 3x rule.

The alternative is to leave this alone and focus on clarification.  We have a requirement that the server reduce its congestion window, so the concrete amount of amplification that can be gained without the 3x rule being in place is not that much relative to the cost of setting up the attack.

I'm ambivalent on this.  I can see the appeal of the principled fix, but getting it right could be tricky.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4257#issuecomment-714772404