Re: [New Issue] CID based attacks

[Christian Huitema <[e-mail]>]

On 11/12/2020 2:15 PM, Martin Thomson wrote:

> On Fri, Nov 13, 2020, at 05:15, Dmitri Tikhonov wrote:
>> My question would be:  Why aren't connections in the other 11 implementations
>> enter the Draining State?
> Neqo should.  (I'm not sure that I have a test against our command-line server though, that is almost certainly doing bad things.)

The description of the experiment says "*To conduct the experiment, I
had the client open and hold a QUIC connection with source CID 1 and
destination CID 2 for a maximum of 10s with the server, and then close
it. We then idle for 10s and repeat the steps a second time." Should the
draining period be longer than 10 seconds? Section 10.2 of the transport
spec says: "*The closing and draining connection states exist to ensure
that connections close cleanly and that delayed or reordered packets are
properly discarded. These states SHOULD persist for at least three times
the current Probe Timeout (PTO) interval as defined in [QUIC-RECOVERY
<https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#QUIC-RECOVERY>]."
That's what picoquic implements, and that's typically way less than 10
seconds.

The description of the experiment does not say whether the successive
connection attempts used the same IP address. For Picoquic at least
that's important, because Picoquic retrieves the handshake context using
the combination of Initial DCID and client IP + port. Multiple
connection attempts using the same Initial DCID and different IP
addresses will be treated as independent connections. This was one of
the suggestion in
https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-01.

-- Christian Huitema