Re: [New Issue] CID based attacks

[Kazuho Oku <[e-mail]>]

2020年11月13日(金) 8:23 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.
>

Quicly adopts the same approach. Applications of quicly are expected to
supply their own CID generation scheme, and therefore quicly does not know
if there's enough entropy in the CID to avoid collision between
server-supplied CIDs and the original DCID being generated by the client.

Therefore, during the handshake, quicly uses `4-tuple && (client-generated
DCID || server-generated CID)` as the packet routing scheme.

That's how we avoid the problem raised by Kashyap.

QUIC stacks that are guaranteed to have server-generated connection IDs
sufficiently long can rely on CID-based routing, I think. Maybe the
implementations marked "vulnerable" fall into this category.

-- Christian Huitema
>
>

-- 
Kazuho Oku