Re: [quicwg/base-drafts] Prevent linkability from responding to migration (#2969)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.

Thank you for the changes. I think it's much better, the discussion of "active" connection ID looks good.

> @@ -2057,11 +2058,17 @@ linked by any other entity.
 At any time, endpoints MAY change the Destination Connection ID they send to a
 value that has not been used on another path.
 
-An endpoint MUST use a new connection ID if it initiates connection migration.
-Using a new connection ID eliminates the use of the connection ID for linking
-activity from the same connection on different networks.  Header protection
-ensures that packet numbers cannot be used to correlate activity.  This does not
-prevent other properties of packets, such as timing and size, from being used to
+An endpoint MUST use a new connection ID if it initiates connection migration as
+described in {{initiating-migration}}.  An endpoint MUST use a new connection ID

Maybe add something like: "or when probing a new path ({{#probing}})"?

> @@ -2057,11 +2058,17 @@ linked by any other entity.
 At any time, endpoints MAY change the Destination Connection ID they send to a
 value that has not been used on another path.
 
-An endpoint MUST use a new connection ID if it initiates connection migration.
-Using a new connection ID eliminates the use of the connection ID for linking
-activity from the same connection on different networks.  Header protection
-ensures that packet numbers cannot be used to correlate activity.  This does not
-prevent other properties of packets, such as timing and size, from being used to
+An endpoint MUST use a new connection ID if it initiates connection migration as
+described in {{initiating-migration}}.  An endpoint MUST use a new connection ID
+in response to a change in the address of a peer if the packet with the new peer
+address uses an active connection ID that has not been previously used by the
+peer.

What should the responding endpoint do, when it does not have any unused Connection IDs?

I think we have at least four options, but neither of them seem to be very good: a) respond using a Connection ID already in use, b) error-close the connection (on the active path), c) respond with a stateless reset, d) drop the packet.

Option _a_ has the privacy concern. I do not think that option _b_ or _c_ is viable, as it creates an attack vector (a middlebox might race the packet that initiates the migration from a different source address. If the spoofed packet reaches the server before the legitimate one, the connection might get dropped as the server might have used all the spare connection IDs for responding to the spoofed packets). Option _d_ seems a bit odd.

Relatedly, Section 9.1 (Probing a New Path) states quote: _An endpoint that uses a new local address needs to ensure that at least one new connection ID is available at the peer. That can be achieved by including a NEW_CONNECTION_ID frame in the probe._ I think that this is a good advice and that we might want to promote the sentences to here, so that it would cover both path probing and immediate connection migration.

-- 
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/2969#pullrequestreview-276302869