Back to work

[Martin Thomson <[e-mail]>]

Nick opened https://github.com/quicwg/base-drafts/issues/4257 last week.

Amplification attacks based on spoofed path migrations seem like they might need some thought.

We have two options we're debating and it seems like a good candidate for broader discussion.

# Background

We currently recommend that you send kMinimumWindow each kInitialRtt to an unvalidated peer address after migration.  This is a different limit to that we use during the handshake and not absolutely bounded.  Thus, if an attacker can spoof migration the spoofed address might receive path validation probes at this rate until the path validation fails.

If our recommendations for validation are followed, this means that you could have a relatively small packet (21 bytes is our minimum, but then we have to add overheads and a connection ID to be realistic, so maybe 51 bytes) to get 1200 times the number of probes sent during path validation (which might between 3 and maybe 9 depending on how you interpret the text).

The same connection can be used to attack as many different hosts as the server is willing to probe from the same connection.  Whether this is in parallel or series doesn't matter so much, we're most interested in the number of bytes involved.

That seems bad, but you have to remember that the attacker has performed a full handshake: all the crypto and round trips necessary to get this going.  That's a non-trivial cost; even if the attacker doesn't bother with retransmissions and timers, it's still a fairly large commitment to mount the attack.

Rough calculations show that 3 probes toward a single target isn't that interesting for an attacker.  If you count a minimal handshake in their costs, they get less than 3x amplification if there are 3 probes and nearly 8x for 9 probes.

If an attacker has multiple targets and considers attacking all of them equally worthwhile, then then can amortize the setup cost across those targets.  Then it depends on how many targets they have and how many paths the server is willing to probe.  Attacker advantage then goes up asymptotically toward the maximum advantage, which is about 25 times the number of probes sent in response to the single packet.

Kazuho also points out that the attacker is mounting a denial of service on themselves as part of this.  Migration causes a probe on the existing, validated path.  Those can be answered readily to limit the number of probes, but congesting their downlink in this way might limit their ability to create additional connections.

# Option 1: 3x limit

We could make the 3x limit for unvalidated paths a blanket requirement.

This is principled, but complicates the process if validating a path.  If you haven't received much data on that path, then you will be unable to send a fully padded probe and so validation only establishes that the recipient is present; then you have to probe again to determine that the path supports the 1200 byte MTU.

This is also risky.  The last two changes we made in this area produced nasty regressions.  This issue is a direct result of changes; without the requirement to pad packets containing PATH_CHALLENGE, this would not be an issue.

# Option 2: Document the exposure and let implementations manage this

The existing rate limiting does have a limited ability to limit amplification.  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.  If the number of probes and the number of failed path validations are both limited, then this could be entirely manageable.  For instance, 3 probes, a connection ID of 8 bytes and 4 path validations provide just 11.6x advantage.

Recommending that implementations limit the number probes and the number of probed paths might then be sufficient.

Note: The rate limiting we currently have only helps if servers limit the number of active connections in some way.