Re: [quicwg/base-drafts] Clarify text around preferred address (#3589)

[Eric Kinnear <[e-mail]>]

@erickinnear commented on this pull request.



> @@ -2277,11 +2278,21 @@ 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 as
-described in {{initiating-migration}} or probes a new network path as described
-in {{probing}}.  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.
+An endpoint MUST NOT reuse a connection ID when sending from more than one local
+address, for example when initiating connection migration as described in
+{{initiating-migration}} or when probing a new network path as described in
+{{probing}}.
+
+Similarly, an endpoint MUST NOT reuse a connection ID when sending to more than
+one destination address.  However, if an endpoint receives packets from a new
+source address with the same destination connection ID, it MAY continue to use
+the current connection ID with the new address.

I like the framing of the last sentence you have there, although it's interesting to think through the question about if we really need an exception here. 

In theory, the problem with changing for this is that a NAT rebinding can cause us to "burn" a CID, making it so that instead of having 2 linked CIDs, we now have 3 linked CIDs. As long as we retire the old one (which is already in the text) once we change to the new one, we should be able to keep a steady supply of those around, although it would mean that someone in the middle of the network could fiddle with things to keep us generating and exchanging more and more CIDs. 

So, the idea is that if someone on the network changes without your knowledge, we've already linked those two 5-tuples by the fact that you've got the same CID in one direction, there's no harm in continuing to keep using that CID in the other direction. 

It does seem better to keep doing that, rather than opening ourselves up to letting someone on the network arbitrarily churn through CIDs.

This would mean the text becomes much like what you have in the TODO above, essentially we're saying that the _sender_ of the packet MUST follow these restrictions, but if you see that your peer did not, then \<the text you have above\>.

-- 
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/3589#discussion_r423278139