2020年11月13日(金) 8:23 Christian Huitema <[email protected]>: > 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
