[quicwg/base-drafts] Amplification attack using retry tokens and spoofed addresses (#2064)

[Christian Huitema <[e-mail]>]

We designed the Address Validation procedures to prevent QUIC servers from being used for UDP based DOS amplification attacks. By default, sending an Initial packet to a QUIC server results in up to 3 full size UDP packets sent back to the originating address, and perhaps several more if the server repeats packets on timeout. With address validation turned on, the server will only answer to Initial packets carrying a proof of origin, in the form of a "token". Once address is validated, servers are free to send many more than 3 packets in response to the Initial packets. I am concerned that the validation procedure can be bypassed with a replay attack.

Let's imagine that an attacker manages to locate itself close enough to its target to be able to observe an Initial/Retry exchange between the source address and a remote server, and obtain a copy of the Retry packet. The attacker now has enough information to manufacture an Initial packet that will pass address validation at the server, if sent from the spoofed address of the target. The attacker could then pass that information to a botnet. A large number of bots can send spoofed packets to the server, resulting in a massive attack against the target.

Whether the attack is plausible or not depends on how the server performs address validation. The current draft presents little guidance about that. If a server implementation simply verifies that the token was associated with the source address of the client, the botnet can run unimpeded. If the token also has some time to live, the attack will run unimpeded until that time. The attack will only be blocked if the server enforces that tokens are used only once, but the current draft does not require that.

I looked at how to modify the Picoquic implementation and protect against this attack. The simplest defense that I found was to embed in the ticket the Connection ID of the server. The connection ID is provided to the client as part of the retry packet, so that change is easy. Tokens could also be provided in New Token frames and sent by clients in Initial packet; the server could extract the CID from the token, and chose that for the new connection. The "server CID defense" is not perfect, but it ensures that the botnet will only be able to create one connection at a time. If tokens have a limited time to live, the attack is effectively thwarted.

I am not saying that all implementations should adopt the server CID defense. The goal is to prevent token reuse at the server, and there are certainly other ways to achieve that. I am just asking that we ask servers to prevent multiple reuses of the same token.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2064

-- Commit Summary --

  * Merge pull request #8 from quicwg/master
  * Ask servers to limit use of tokens to only once

-- File Changes --

    M draft-ietf-quic-transport.md (3)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2064.patch
https://github.com/quicwg/base-drafts/pull/2064.diff

-- 
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/pull/2064