diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 339cf32985..a9df762022 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1071,7 +1071,7 @@ peer to use a new connection ID on migration, as the peer will close the connection if the pool is exhausted. -### Consuming and Retiring Connection IDs {#retiring-cids} +### Consuming and Retiring Connection IDs {#retire-cid} An endpoint can change the connection ID it uses for a peer to another available one at any time during the connection. An endpoint consumes connection IDs in @@ -1085,8 +1085,9 @@ be used again and requests that the peer replace it with a new connection ID using a NEW_CONNECTION_ID frame. As discussed in {{migration-linkability}}, endpoints limit the use of a -connection ID to a single network path where possible. Endpoints SHOULD retire -connection IDs when no longer actively using the network path on which the +connection ID to packets sent from a single local address to a single +destination address. Endpoints SHOULD retire connection IDs when they are no +longer actively using either the local or destination address for which the connection ID was used. An endpoint might need to stop accepting previously issued connection IDs in @@ -2116,9 +2117,10 @@ verifies ECN capability as described in {{ecn}}. Receiving acknowledgments for data sent on the new path serves as proof of the peer's reachability from the new address. Note that since acknowledgments may -be received on any path, return reachability on the new path is not -established. To establish return reachability on the new path, an endpoint MAY -concurrently initiate path validation {{migrate-validate}} on the new path. +be received on any path, return reachability on the new path is not established. +To establish return reachability on the new path, an endpoint MAY concurrently +initiate path validation {{migrate-validate}} on the new path or it MAY choose +to wait for the peer to send the next non-probing frame to its new address. ## Responding to Connection Migration {#migration-response} @@ -2300,11 +2302,23 @@ 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. Due to network changes outside the control of its +peer, an endpoint might receive packets from a new source address with the same +destination connection ID, in which case it MAY continue to use the current +connection ID with the new remote address while still sending from the same +local address. + +These requirements regarding connection ID reuse apply only to the sending of +packets, as unintentional changes in path without a change in connection ID are +possible. For example, after a period of network inactivity, NAT rebinding +might cause packets to be sent on a new path when the client resumes sending. +An endpoint responds to such an event as described in {{migration-response}}. Using different connection IDs for packets sent in both directions on each new network path eliminates the use of the connection ID for linking packets from @@ -2315,18 +2329,14 @@ correlate activity. An endpoint SHOULD NOT initiate migration with a peer that has requested a zero-length connection ID, because traffic over the new path might be trivially -linkable to traffic over the old one. If the server is able to route packets +linkable to traffic over the old one. If the server is able to route packets with a zero-length connection ID to the right connection, it means that the -server is using other information to demultiplex packets. For example, a server +server is using other information to demultiplex packets. For example, a server might provide a unique address to every client, for instance using HTTP alternative services {{?ALTSVC=RFC7838}}. Information that might allow correct routing of packets across multiple network paths will also allow activity on those paths to be linked by entities other than the peer. -Unintentional changes in path without a change in connection ID are possible. -For example, after a period of network inactivity, NAT rebinding might cause -packets to be sent on a new path when the client resumes sending. - A client might wish to reduce linkability by employing a new connection ID and source UDP port when sending traffic after a period of inactivity. Changing the UDP port from which it sends packets at the same time might cause the packet to @@ -2367,10 +2377,11 @@ transport parameter in the TLS handshake. Servers MAY communicate a preferred address of each address family (IPv4 and IPv6) to allow clients to pick the one most suited to their network attachment. -Once the handshake is finished, the client SHOULD select one of the two +Once the handshake is confirmed, the client SHOULD select one of the two server's preferred addresses and initiate path validation (see -{{migrate-validate}}) of that address using the connection ID provided in the -preferred_address transport parameter. +{{migrate-validate}}) of that address using any previously unused active +connection ID, taken from either the preferred_address transport parameter or +a NEW_CONNECTION_ID frame. If path validation succeeds, the client SHOULD immediately begin sending all future packets to the new server address using the new connection ID and @@ -5530,8 +5541,8 @@ Sequence Number: Retire Prior To: -: A variable-length integer indicating which connection IDs should be retired. - See {{retiring-cids}}. +: A variable-length integer indicating which connection IDs should be retired; + see {{retire-cid}}. Length: @@ -5568,7 +5579,7 @@ IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION. The Retire Prior To field counts connection IDs established during connection -setup and the preferred_address transport parameter; see {{retiring-cids}}. The +setup and the preferred_address transport parameter; see {{retire-cid}}. The Retire Prior To field MUST be less than or equal to the Sequence Number field. Receiving a value greater than the Sequence Number MUST be treated as a connection error of type FRAME_ENCODING_ERROR. @@ -5611,8 +5622,7 @@ RETIRE_CONNECTION_ID frames contain the following fields: Sequence Number: -: The sequence number of the connection ID being retired. See - {{retiring-cids}}. +: The sequence number of the connection ID being retired; see {{retire-cid}}. Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number greater than any previously sent to the peer MUST be treated as a connection error of