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

[Martin Thomson <[e-mail]>]

OK, that helps.  I didn't factor in packet headers in my calculations, but I also allow for multiple probes in response to a single non-probing packet.

What I'm concerned about then is considering the cost of the handshake.  To complete the handshake, you need to send one 1200 byte packet and one packet of about 78 bytes.  For an attack on a single host, this changes the dynamic considerably: you send `1220 + (98 + CID) + (41 + CID)` to get `3*1220`, assuming that you send three probes on new paths.  That's lower than our 3x target even if the connection ID is zero length (2.66).

Even if you amortize that setup cost across multiple targets, the amplification factor isn't as bad as I first thought. If a server probes up to 10 paths (which seems high), then you get `3*1200 / ((1318 + CID) / n + 41 + CID)` which for a CID of 8 bytes and 10 paths is 19.8.  That's much worse, but not so bad as it is spread over multiple paths.

We might limit the number of concurrent path validations, but this is not really going to change anything if they are just strung out.  Only the total amount matters if the attacker is even slightly patient.

I think that there might be some clarifications we can add:

1. Point more clearly to the requirement to limit the sending rate on unvalidated paths after migration.

2. Note that this rate limit applies to each path and that it might be necessary to limit the number of paths that are concurrently validated in this way, either per connection or across all connections (perhaps per destination if you are able).

3. Note that multiple path validations in sequence can still be used to use a single connection to attack multiple targets and that it might be necessary to limit the number of total failed path validations.

On this last point, the total exposure is fixed in total to the number of probes in each failed validation attempt (e.g., 3) times the number of failed validations that the endpoint permits (e.g., 10).  Using 3 and 10 gives the ~20x figure above, which is pretty bad, but not so far out of proportion that it couldn't be managed.  Keep in mind that the attacker needs to do all the crypto of a handshake in order to access that, plus all the protocol logic and timers over two round trips.  All that to get that 20x factor.

-- 
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-717001767