From 14020735ae126961bc364334d28d5dc2f943941b Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Wed, 12 Sep 2018 13:43:15 -0700 Subject: [PATCH 01/13] New text around Connection IDs, add CONNECTION_ID_FINISHED --- draft-ietf-quic-transport.md | 209 ++++++++++++++++++++++++----------- 1 file changed, 142 insertions(+), 67 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 996049d4da..ef8ebbdcd0 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1143,28 +1143,29 @@ For all other frames, the Frame Type field simply identifies the frame. These frames are explained in more detail as they are referenced later in the document. -| Type Value | Frame Type Name | Definition | -|:------------|:------------------|:----------------------------| -| 0x00 | PADDING | {{frame-padding}} | -| 0x01 | RST_STREAM | {{frame-rst-stream}} | -| 0x02 | CONNECTION_CLOSE | {{frame-connection-close}} | -| 0x03 | APPLICATION_CLOSE | {{frame-application-close}} | -| 0x04 | MAX_DATA | {{frame-max-data}} | -| 0x05 | MAX_STREAM_DATA | {{frame-max-stream-data}} | -| 0x06 | MAX_STREAM_ID | {{frame-max-stream-id}} | -| 0x07 | PING | {{frame-ping}} | -| 0x08 | BLOCKED | {{frame-blocked}} | -| 0x09 | STREAM_BLOCKED | {{frame-stream-blocked}} | -| 0x0a | STREAM_ID_BLOCKED | {{frame-stream-id-blocked}} | -| 0x0b | NEW_CONNECTION_ID | {{frame-new-connection-id}} | -| 0x0c | STOP_SENDING | {{frame-stop-sending}} | -| 0x0d | ACK | {{frame-ack}} | -| 0x0e | PATH_CHALLENGE | {{frame-path-challenge}} | -| 0x0f | PATH_RESPONSE | {{frame-path-response}} | -| 0x10 - 0x17 | STREAM | {{frame-stream}} | -| 0x18 | CRYPTO | {{frame-crypto}} | -| 0x19 | NEW_TOKEN | {{frame-new-token}} | -| 0x1a | ACK_ECN | {{frame-ack-ecn}} | +| Type Value | Frame Type Name | Definition | +|:------------|:-----------------------|:---------------------------------| +| 0x00 | PADDING | {{frame-padding}} | +| 0x01 | RST_STREAM | {{frame-rst-stream}} | +| 0x02 | CONNECTION_CLOSE | {{frame-connection-close}} | +| 0x03 | APPLICATION_CLOSE | {{frame-application-close}} | +| 0x04 | MAX_DATA | {{frame-max-data}} | +| 0x05 | MAX_STREAM_DATA | {{frame-max-stream-data}} | +| 0x06 | MAX_STREAM_ID | {{frame-max-stream-id}} | +| 0x07 | PING | {{frame-ping}} | +| 0x08 | BLOCKED | {{frame-blocked}} | +| 0x09 | STREAM_BLOCKED | {{frame-stream-blocked}} | +| 0x0a | STREAM_ID_BLOCKED | {{frame-stream-id-blocked}} | +| 0x0b | NEW_CONNECTION_ID | {{frame-new-connection-id}} | +| 0x0c | STOP_SENDING | {{frame-stop-sending}} | +| 0x0d | ACK | {{frame-ack}} | +| 0x0e | PATH_CHALLENGE | {{frame-path-challenge}} | +| 0x0f | PATH_RESPONSE | {{frame-path-response}} | +| 0x10 - 0x17 | STREAM | {{frame-stream}} | +| 0x18 | CRYPTO | {{frame-crypto}} | +| 0x19 | NEW_TOKEN | {{frame-new-token}} | +| 0x1a | ACK_ECN | {{frame-ack-ecn}} | +| 0x1b | CONNECTION_ID_FINISHED | {{frame-connection-id-finished}} | {: #frame-types title="Frame Types"} All QUIC frames are idempotent. That is, a valid frame does not cause @@ -1224,41 +1225,77 @@ be routed back to the endpoint and identified by the endpoint upon receipt. A zero-length connection ID MAY be used when the connection ID is not needed for routing and the address/port tuple of packets is sufficient to associate them to -a connection. An endpoint whose peer has selected a zero-length connection ID +a connection. An endpoint whose peer has selected a zero-length connection ID MUST continue to use a zero-length connection ID for the lifetime of the connection and MUST NOT send packets from any other local address. -When an endpoint has requested a non-zero-length connection ID, it will issue a -series of connection IDs over the lifetime of a connection. The series of -connection IDs issued by an endpoint is ordered, with the final connection ID -selected during the handshake coming first. Additional connection IDs are -provided using the NEW_CONNECTION_ID frame ({{frame-new-connection-id}}), each -with a specified sequence number. The series of connection IDs issued SHOULD be -contiguous, but might not appear to be upon receipt due to reordering or loss. - -Each connection ID MUST be used on only one local address. When packets are sent -for the first time on a new local address, a new connection ID MUST be used with -a higher sequence number than any connection ID previously used on any local -address. At any time, an endpoint MAY change to a new connection ID on a local -address already in use. - -An endpoint MUST NOT send packets with a connection ID which has a lower -sequence number than the highest sequence number of any connection ID ever sent -or received on that local address. This ensures that when an endpoint migrates -to a new path or changes connection ID on an existing path, the packets will use -a new connection ID in both directions. - -Implementations SHOULD ensure that peers have a connection ID with a matching -sequence number available when changing to a new connection ID. An -implementation could do this by always supplying a corresponding connection ID -to a peer for each connection ID received from that peer. - -While endpoints select connection IDs as appropriate for their implementation, -the connection ID MUST NOT include the unprotected sequence number. Endpoints -need to be able to recover the sequence number associated with each connection -ID they generate without relying on information available to unaffiliated -parties. A connection ID that encodes an unencrypted sequence number could be -used to correlate connection IDs across network paths. +An endpoint whose peer has selected a non-zero-length connection ID will +potentially send packets using different connection IDs over the lifetime of a +connection. These connection IDs are supplied by the peer using the +NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). + + +### Issuing Connection IDs + +An endpoint issues connection IDs to its peer for the peer to use when sending +packets. This allows the endpoint control over the strategy used to interpret +connection IDs of packets that it receives. These connection IDs are +communicated to the peer using NEW_CONNECTION_ID frames +({{frame-new-connection-id}}). + +The initial connection ID issued to the peer is sent by the endpoint as the +Source Connection ID during the handshake, ensuring that the peer always begins +the connection with at least one connection ID to use when sending. An endpoint +SHOULD supply its peer with additional connection IDs via NEW_CONNECTION_ID +frames. While each endpoint can choose how many connection IDs to issue, a +recommended number of outstanding connection IDs is eight. + +When an endpoint issues a connection ID, it MUST accept packets using this +connection ID for the duration of the connection or until its peer invalidates +the connection ID via a CONNECTION_ID_FINISHED frame +({{frame-connection-id-finished}}). + +Implementations SHOULD ensure that peers have sufficient connection IDs +available to reduce the possibility of peers exhausting their supply of +available connection IDs. An implementation could do this by always supplying a +new connection ID for each connection ID retired with a CONNECTION_ID_FINISHED +frame. When a receiver of a packet notices that its peer is now using a +previously unused connection ID, it can choose to supply its peer with a new +connection ID using a NEW_CONNECTION_ID frame to reduce the possibility of its +peer running out of available connection IDs. + +An endpoint that receives a packet with a different remote address than +previously used SHOULD also switch to sending with a different connection ID. +This can help to ensure that different connection IDs will be used in both +directions when an endpoint migrates to a new path or changes connection ID on +an existing path. + + +### Consuming Connection IDs + +If an endpoint's peer has selected a non-zero-length connection ID, the endpoint +maintains a set of connection IDs received from the peer that it can use when +sending packets. All connection IDs issued by the peer are considered valid for +use by the endpoint when sending packets until the connection ID is retired by +the endpoint. Endpoints can choose to stop using a given connection ID to send +packets at any time and signal this to the issuing endpoint via a +CONNECTION_ID_FINISHED frame. This frame indicates the connection ID that is no +longer in use and serves as a request for the peer to issue additional +connection IDs via a NEW_CONNECTION_ID frame. + +An endpoint that retires a connection ID should retain knowledge of that +connection ID for a reasonable time after sending the CONNECTION_ID_FINISHED +frame, or until that frame is acknowledged. A recommended time is three times +the current Retransmission Timeout (RTO) interval as defined in +{{QUIC-RECOVERY}}. This prevents potential retransmissions of a +NEW_CONNECTION_ID frame from overlapping with the CONNECTION_ID_FINISHED frame +for the same connection ID. + +Additionally, each connection ID MUST be used on packets sent from only one +local address. At any time, an endpoint MAY change to a new connection ID on a +local address already in use. An endpoint that migrates to a new local address +SHOULD retire all connection IDs that were used on the previous address +using the CONNECTION_ID_FINISHED frame. ## Matching Packets to Connections {#packet-handling} @@ -2606,6 +2643,9 @@ the NEW_CONNECTION_ID frame sent by either peer, and servers can specify the stateless_reset_token transport parameter during the handshake (clients cannot because their transport parameters don't have confidentiality protection). This value is protected by encryption, so only client and server know this value. +Tokens sent via NEW_CONNECTION_ID frames are invalidated when their associated +connection ID is retired via a CONNECTION_ID_FINISHED frame +({{frame-connection-id-finished}}). An endpoint that receives packets that it cannot process sends a packet in the following layout: @@ -3192,14 +3232,12 @@ An endpoint sends a NEW_CONNECTION_ID frame (type=0x0b) to provide its peer with alternative connection IDs that can be used to break linkability when migrating connections (see {{migration-linkability}}). -The NEW_CONNECTION_ID is as follows: +The NEW_CONNECTION_ID frame is as follows: ~~~ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Sequence (i) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (8) | Connection ID (32..144) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | @@ -3214,14 +3252,6 @@ The NEW_CONNECTION_ID is as follows: The fields are: -Sequence: - -: A variable-length integer. This value starts at 0 and increases by 1 for each - connection ID that is provided by the server. The connection ID that is - assigned during the handshake is assumed to have a sequence of -1. That is, - the value selected during the handshake comes immediately before the first - value that a server can send. - Length: : An 8-bit unsigned integer containing the length of the connection ID. Values @@ -3234,7 +3264,7 @@ Connection ID: Stateless Reset Token: -: A 128-bit value that will be used to for a stateless reset when the associated +: A 128-bit value that will be used for a stateless reset when the associated connection ID is used (see {{stateless-reset}}). An endpoint MUST NOT send this frame if it currently requires that its peer send @@ -3257,6 +3287,49 @@ the Source Connection ID used by the peer during the initial handshake, it MUST treat that receipt as a connection error of type PROTOCOL_VIOLATION. +## CONNECTION_ID_FINISHED Frame {#frame-connection-id-finished} + +An endpoint sends a CONNECTION_ID_FINISHED frame (type=0x1b) to indicate that it +will no longer use a connection ID that was issued by its peer. This also +serves as a request to the peer to send additional connection IDs for future use +(see {{connection-id}}). New connection IDs can be delivered via the +NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). + +Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates any +stateless reset tokens associated with that connection ID. + +The CONNECTION_ID_FINISHED frame is as follows: + +~~~ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Length (8) | Connection ID (32..144) ... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~~~ + +The fields are: + +Length: + +: An 8-bit unsigned integer containing the length of the connection ID. + +Connection ID: + +: A connection ID of the specified length. + +Receipt of a CONNECTION_ID_FINISHED frame containing a connection ID that was +not previously sent to the peer MAY be treated as a connection error of type +PROTOCOL_VIOLATION. + +An endpoint MUST NOT send this frame if it is currently sending packets with a +zero-length Destination Connection ID. Changing the length of a connection ID +to or from zero-length makes it difficult to identify when the value of the +connection ID changed. An endpoint that is receiving packets with a zero-length +Destination Connection ID MUST treat receipt of a CONNECTION_ID_FINISHED frame +as a connection error of type PROTOCOL_VIOLATION. + + ## STOP_SENDING Frame {#frame-stop-sending} An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate that @@ -3869,7 +3942,9 @@ containing that information is acknowledged. needed. * New connection IDs are sent in NEW_CONNECTION_ID frames and retransmitted if - the packet containing them is lost. + the packet containing them is lost. Likewise, retired connection IDs are sent + in CONNECTION_ID_FINISHED frames and retransmitted if the packet containing + them is lost. * PADDING frames contain no information, so lost PADDING frames do not require repair. From 1fdbecd39492547b83807237e56cd39e547fbd3f Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Sat, 15 Sep 2018 21:33:19 -0700 Subject: [PATCH 02/13] Move caution text, review comments --- draft-ietf-quic-transport.md | 75 ++++++++++++++++-------------------- 1 file changed, 34 insertions(+), 41 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ef8ebbdcd0..a9a60e9241 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1264,11 +1264,21 @@ previously unused connection ID, it can choose to supply its peer with a new connection ID using a NEW_CONNECTION_ID frame to reduce the possibility of its peer running out of available connection IDs. -An endpoint that receives a packet with a different remote address than -previously used SHOULD also switch to sending with a different connection ID. -This can help to ensure that different connection IDs will be used in both -directions when an endpoint migrates to a new path or changes connection ID on -an existing path. +Endpoints that use connection IDs with length greater than zero could have their +activity correlated if their peers keep using the same destination connection ID +after migration. An endpoint that receives a packet with a different remote +address or destination connection ID than previously used SHOULD also switch to +sending with a connection ID that has not previously been used. The goal is to +ensure absence of correlation between the pairs of client and server connection +ID used on different paths. To fulfill this privacy requirement, endpoints that +initiate migration and use connection IDs with length greater than zero SHOULD +provide their peers with new connection IDs before migration. + +Caution: + +: If both endpoints change connection ID in response to seeing a change in + connection ID from their peer, then this can trigger an infinite sequence + of changes. ### Consuming Connection IDs @@ -1279,12 +1289,10 @@ sending packets. All connection IDs issued by the peer are considered valid for use by the endpoint when sending packets until the connection ID is retired by the endpoint. Endpoints can choose to stop using a given connection ID to send packets at any time and signal this to the issuing endpoint via a -CONNECTION_ID_FINISHED frame. This frame indicates the connection ID that is no -longer in use and serves as a request for the peer to issue additional -connection IDs via a NEW_CONNECTION_ID frame. +CONNECTION_ID_FINISHED frame. An endpoint that retires a connection ID should retain knowledge of that -connection ID for a reasonable time after sending the CONNECTION_ID_FINISHED +connection ID for a period of time after sending the CONNECTION_ID_FINISHED frame, or until that frame is acknowledged. A recommended time is three times the current Retransmission Timeout (RTO) interval as defined in {{QUIC-RECOVERY}}. This prevents potential retransmissions of a @@ -1293,9 +1301,9 @@ for the same connection ID. Additionally, each connection ID MUST be used on packets sent from only one local address. At any time, an endpoint MAY change to a new connection ID on a -local address already in use. An endpoint that migrates to a new local address -SHOULD retire all connection IDs that were used on the previous address -using the CONNECTION_ID_FINISHED frame. +local address already in use. An endpoint that migrates away from a local +address SHOULD retire all connection IDs used on that address once it no longer +plans to use that address. ## Matching Packets to Connections {#packet-handling} @@ -2406,22 +2414,6 @@ genuine migrations. Changing port number can cause a peer to reset its congestion state (see {{migration-cc}}), so the port SHOULD only be changed infrequently. -Endpoints that use connection IDs with length greater than zero could have -their activity correlated if their peers keep using the same destination -connection ID after migration. Endpoints that receive packets with a -previously unused Destination Connection ID SHOULD change to sending packets -with a connection ID that has not been used on any other network path. The -goal is to ensure absence of correlation between the pairs of client and server -connection ID used on different paths. To fulfill this privacy requirement, -endpoints that initiate migration and use connection IDs with length greater -than zero SHOULD provide their peers with new connection IDs before migration. - -Caution: - -: If both endpoints change connection ID in response to seeing a change in - connection ID from their peer, then this can trigger an infinite sequence - of changes. - ## Server's Preferred Address {#preferred-address} @@ -2698,7 +2690,7 @@ ignoring an unknown packet with a long header might be more effective. An endpoint cannot determine the Source Connection ID from a packet with a short header, therefore it cannot set the Destination Connection ID in the stateless -reset packet. The destination connection ID will therefore differ from the +reset packet. The Destination Connection ID will therefore differ from the value used in previous packets. A random Destination Connection ID makes the connection ID appear to be the result of moving to a new connection ID that was provided using a NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). @@ -3290,13 +3282,15 @@ PROTOCOL_VIOLATION. ## CONNECTION_ID_FINISHED Frame {#frame-connection-id-finished} An endpoint sends a CONNECTION_ID_FINISHED frame (type=0x1b) to indicate that it -will no longer use a connection ID that was issued by its peer. This also -serves as a request to the peer to send additional connection IDs for future use -(see {{connection-id}}). New connection IDs can be delivered via the -NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). +will no longer use a connection ID that was issued by its peer. Note that this +may include the connection ID provided during the handshake. Sending a +CONNECTION_ID_FINISHED frame also serves as a request to the peer to send +additional connection IDs for future use (see {{connection-id}}). New +connection IDs can be delivered via the NEW_CONNECTION_ID frame ({{frame-new- +connection-id}}). -Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates any -stateless reset tokens associated with that connection ID. +Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates the +stateless reset token associated with that connection ID. The CONNECTION_ID_FINISHED frame is as follows: @@ -3322,12 +3316,11 @@ Receipt of a CONNECTION_ID_FINISHED frame containing a connection ID that was not previously sent to the peer MAY be treated as a connection error of type PROTOCOL_VIOLATION. -An endpoint MUST NOT send this frame if it is currently sending packets with a -zero-length Destination Connection ID. Changing the length of a connection ID -to or from zero-length makes it difficult to identify when the value of the -connection ID changed. An endpoint that is receiving packets with a zero-length -Destination Connection ID MUST treat receipt of a CONNECTION_ID_FINISHED frame -as a connection error of type PROTOCOL_VIOLATION. +An endpoint cannot send this frame if it was provided with a zero-length +connection ID by its peer. An endpoint that is +receiving packets with a zero-length Destination Connection ID MUST treat +receipt of a CONNECTION_ID_FINISHED frame as a connection error of type +PROTOCOL_VIOLATION. ## STOP_SENDING Frame {#frame-stop-sending} From 325c21e34d452a0639369f5dacad623cd78f39a2 Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Sat, 15 Sep 2018 21:37:46 -0700 Subject: [PATCH 03/13] Minor textual nits --- draft-ietf-quic-transport.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a9a60e9241..232a3fd80d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1260,9 +1260,9 @@ available to reduce the possibility of peers exhausting their supply of available connection IDs. An implementation could do this by always supplying a new connection ID for each connection ID retired with a CONNECTION_ID_FINISHED frame. When a receiver of a packet notices that its peer is now using a -previously unused connection ID, it can choose to supply its peer with a new -connection ID using a NEW_CONNECTION_ID frame to reduce the possibility of its -peer running out of available connection IDs. +previously unused connection ID, it can supply its peer with a new connection ID +using a NEW_CONNECTION_ID frame to reduce the possibility of its peer running +out of available connection IDs. Endpoints that use connection IDs with length greater than zero could have their activity correlated if their peers keep using the same destination connection ID @@ -3317,10 +3317,9 @@ not previously sent to the peer MAY be treated as a connection error of type PROTOCOL_VIOLATION. An endpoint cannot send this frame if it was provided with a zero-length -connection ID by its peer. An endpoint that is -receiving packets with a zero-length Destination Connection ID MUST treat -receipt of a CONNECTION_ID_FINISHED frame as a connection error of type -PROTOCOL_VIOLATION. +connection ID by its peer. An endpoint that provides a zero-length connection +ID MUST treat receipt of a CONNECTION_ID_FINISHED frame as a connection error of +type PROTOCOL_VIOLATION. ## STOP_SENDING Frame {#frame-stop-sending} From a22f0aa6f52360b696745afcfc414a9a1cdf4fd0 Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Sun, 23 Sep 2018 23:06:11 -0700 Subject: [PATCH 04/13] Bring back TP, this time for max_connection_ids --- draft-ietf-quic-transport.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f6eec903e0..119e6f05c9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1238,8 +1238,9 @@ The initial connection ID issued to the peer is sent by the endpoint as the Source Connection ID during the handshake, ensuring that the peer always begins the connection with at least one connection ID to use when sending. An endpoint SHOULD supply its peer with additional connection IDs via NEW_CONNECTION_ID -frames. While each endpoint can choose how many connection IDs to issue, a -recommended number of outstanding connection IDs is eight. +frames, up to the number of connection IDs specified in the `max_connection_ids` +transport parameter. While each endpoint can choose how many connection IDs to +issue, a recommended number of outstanding connection IDs is eight. When an endpoint issues a connection ID, it MUST accept packets using this connection ID for the duration of the connection or until its peer invalidates @@ -1592,6 +1593,7 @@ language from Section 3 of {{!TLS13=RFC8446}}. disable_migration(9), initial_max_stream_data_bidi_remote(10), initial_max_stream_data_uni(11), + max_connection_ids(12), (65535) } TransportParameterId; @@ -1707,6 +1709,16 @@ disable_migration (0x0009): address other than that used to perform the handshake. This parameter is a zero-length value. +max_connection_ids (0x000c): + +: A 16-bit unsigned integer value indicating the maximum number of connection + IDs the endpoint would like its peer to issue, as described in + {{connection-id}}. The receiver MUST NOT provide more than this many + connection IDs using NEW_CONNECTION_ID frames ({{frame-new-connection-id}}), + noting that the initial connection ID established during the handshake is + included in this count. If a zero-length connection ID is used, this + parameter MUST be ignored. + Either peer MAY advertise an initial value for the flow control on each type of stream on which they might receive data. Each of the following transport parameters is encoded as an unsigned 32-bit integer in units of octets: @@ -5080,6 +5092,7 @@ The initial contents of this registry are shown in {{iana-tp-table}}. | 0x0009 | disable_migration | {{transport-parameter-definitions}} | | 0x000a | initial_max_stream_data_bidi_remote | {{transport-parameter-definitions}} | | 0x000b | initial_max_stream_data_uni | {{transport-parameter-definitions}} | +| 0x000c | max_connection_ids | {{transport-parameter-definitions}} | {: #iana-tp-table title="Initial QUIC Transport Parameters Entries"} From 6a67f0c5ef6ead104075bce5fa41fbf0f42879ac Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 24 Sep 2018 17:14:27 -0700 Subject: [PATCH 05/13] Revert "Bring back TP, this time for max_connection_ids" This reverts commit a22f0aa6f52360b696745afcfc414a9a1cdf4fd0. --- draft-ietf-quic-transport.md | 17 ++--------------- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 119e6f05c9..f6eec903e0 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1238,9 +1238,8 @@ The initial connection ID issued to the peer is sent by the endpoint as the Source Connection ID during the handshake, ensuring that the peer always begins the connection with at least one connection ID to use when sending. An endpoint SHOULD supply its peer with additional connection IDs via NEW_CONNECTION_ID -frames, up to the number of connection IDs specified in the `max_connection_ids` -transport parameter. While each endpoint can choose how many connection IDs to -issue, a recommended number of outstanding connection IDs is eight. +frames. While each endpoint can choose how many connection IDs to issue, a +recommended number of outstanding connection IDs is eight. When an endpoint issues a connection ID, it MUST accept packets using this connection ID for the duration of the connection or until its peer invalidates @@ -1593,7 +1592,6 @@ language from Section 3 of {{!TLS13=RFC8446}}. disable_migration(9), initial_max_stream_data_bidi_remote(10), initial_max_stream_data_uni(11), - max_connection_ids(12), (65535) } TransportParameterId; @@ -1709,16 +1707,6 @@ disable_migration (0x0009): address other than that used to perform the handshake. This parameter is a zero-length value. -max_connection_ids (0x000c): - -: A 16-bit unsigned integer value indicating the maximum number of connection - IDs the endpoint would like its peer to issue, as described in - {{connection-id}}. The receiver MUST NOT provide more than this many - connection IDs using NEW_CONNECTION_ID frames ({{frame-new-connection-id}}), - noting that the initial connection ID established during the handshake is - included in this count. If a zero-length connection ID is used, this - parameter MUST be ignored. - Either peer MAY advertise an initial value for the flow control on each type of stream on which they might receive data. Each of the following transport parameters is encoded as an unsigned 32-bit integer in units of octets: @@ -5092,7 +5080,6 @@ The initial contents of this registry are shown in {{iana-tp-table}}. | 0x0009 | disable_migration | {{transport-parameter-definitions}} | | 0x000a | initial_max_stream_data_bidi_remote | {{transport-parameter-definitions}} | | 0x000b | initial_max_stream_data_uni | {{transport-parameter-definitions}} | -| 0x000c | max_connection_ids | {{transport-parameter-definitions}} | {: #iana-tp-table title="Initial QUIC Transport Parameters Entries"} From 923b024085df0f58ea736772c054afb246362884 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 24 Sep 2018 17:20:32 -0700 Subject: [PATCH 06/13] replace CONNECTION_ID_FINISHED with RETIRE_CONNECTION_ID --- draft-ietf-quic-transport.md | 74 ++++++++++++++++++------------------ 1 file changed, 37 insertions(+), 37 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f6eec903e0..97cea4844c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1135,29 +1135,29 @@ For all other frames, the Frame Type field simply identifies the frame. These frames are explained in more detail as they are referenced later in the document. -| Type Value | Frame Type Name | Definition | -|:------------|:-----------------------|:---------------------------------| -| 0x00 | PADDING | {{frame-padding}} | -| 0x01 | RST_STREAM | {{frame-rst-stream}} | -| 0x02 | CONNECTION_CLOSE | {{frame-connection-close}} | -| 0x03 | APPLICATION_CLOSE | {{frame-application-close}} | -| 0x04 | MAX_DATA | {{frame-max-data}} | -| 0x05 | MAX_STREAM_DATA | {{frame-max-stream-data}} | -| 0x06 | MAX_STREAM_ID | {{frame-max-stream-id}} | -| 0x07 | PING | {{frame-ping}} | -| 0x08 | BLOCKED | {{frame-blocked}} | -| 0x09 | STREAM_BLOCKED | {{frame-stream-blocked}} | -| 0x0a | STREAM_ID_BLOCKED | {{frame-stream-id-blocked}} | -| 0x0b | NEW_CONNECTION_ID | {{frame-new-connection-id}} | -| 0x0c | STOP_SENDING | {{frame-stop-sending}} | -| 0x0d | ACK | {{frame-ack}} | -| 0x0e | PATH_CHALLENGE | {{frame-path-challenge}} | -| 0x0f | PATH_RESPONSE | {{frame-path-response}} | -| 0x10 - 0x17 | STREAM | {{frame-stream}} | -| 0x18 | CRYPTO | {{frame-crypto}} | -| 0x19 | NEW_TOKEN | {{frame-new-token}} | -| 0x1a | ACK_ECN | {{frame-ack-ecn}} | -| 0x1b | CONNECTION_ID_FINISHED | {{frame-connection-id-finished}} | +| Type Value | Frame Type Name | Definition | +|:------------|:---------------------|:-------------------------------| +| 0x00 | PADDING | {{frame-padding}} | +| 0x01 | RST_STREAM | {{frame-rst-stream}} | +| 0x02 | CONNECTION_CLOSE | {{frame-connection-close}} | +| 0x03 | APPLICATION_CLOSE | {{frame-application-close}} | +| 0x04 | MAX_DATA | {{frame-max-data}} | +| 0x05 | MAX_STREAM_DATA | {{frame-max-stream-data}} | +| 0x06 | MAX_STREAM_ID | {{frame-max-stream-id}} | +| 0x07 | PING | {{frame-ping}} | +| 0x08 | BLOCKED | {{frame-blocked}} | +| 0x09 | STREAM_BLOCKED | {{frame-stream-blocked}} | +| 0x0a | STREAM_ID_BLOCKED | {{frame-stream-id-blocked}} | +| 0x0b | NEW_CONNECTION_ID | {{frame-new-connection-id}} | +| 0x0c | STOP_SENDING | {{frame-stop-sending}} | +| 0x0d | ACK | {{frame-ack}} | +| 0x0e | PATH_CHALLENGE | {{frame-path-challenge}} | +| 0x0f | PATH_RESPONSE | {{frame-path-response}} | +| 0x10 - 0x17 | STREAM | {{frame-stream}} | +| 0x18 | CRYPTO | {{frame-crypto}} | +| 0x19 | NEW_TOKEN | {{frame-new-token}} | +| 0x1a | ACK_ECN | {{frame-ack-ecn}} | +| 0x1b | RETIRE_CONNECTION_ID | {{frame-retire-connection-id}} | {: #frame-types title="Frame Types"} All QUIC frames are idempotent. That is, a valid frame does not cause @@ -1243,13 +1243,13 @@ recommended number of outstanding connection IDs is eight. When an endpoint issues a connection ID, it MUST accept packets using this connection ID for the duration of the connection or until its peer invalidates -the connection ID via a CONNECTION_ID_FINISHED frame +the connection ID via a RETIRE_CONNECTION_ID frame ({{frame-connection-id-finished}}). Implementations SHOULD ensure that peers have sufficient connection IDs available to reduce the possibility of peers exhausting their supply of available connection IDs. An implementation could do this by always supplying a -new connection ID for each connection ID retired with a CONNECTION_ID_FINISHED +new connection ID for each connection ID retired with a RETIRE_CONNECTION_ID frame. When a receiver of a packet notices that its peer is now using a previously unused connection ID, it can supply its peer with a new connection ID using a NEW_CONNECTION_ID frame to reduce the possibility of its peer running @@ -1280,14 +1280,14 @@ sending packets. All connection IDs issued by the peer are considered valid for use by the endpoint when sending packets until the connection ID is retired by the endpoint. Endpoints can choose to stop using a given connection ID to send packets at any time and signal this to the issuing endpoint via a -CONNECTION_ID_FINISHED frame. +RETIRE_CONNECTION_ID frame. An endpoint that retires a connection ID should retain knowledge of that -connection ID for a period of time after sending the CONNECTION_ID_FINISHED +connection ID for a period of time after sending the RETIRE_CONNECTION_ID frame, or until that frame is acknowledged. A recommended time is three times the current Retransmission Timeout (RTO) interval as defined in {{QUIC-RECOVERY}}. This prevents potential retransmissions of a -NEW_CONNECTION_ID frame from overlapping with the CONNECTION_ID_FINISHED frame +NEW_CONNECTION_ID frame from overlapping with the RETIRE_CONNECTION_ID frame for the same connection ID. Additionally, each connection ID MUST be used on packets sent from only one @@ -2625,7 +2625,7 @@ stateless_reset_token transport parameter during the handshake (clients cannot because their transport parameters don't have confidentiality protection). This value is protected by encryption, so only client and server know this value. Tokens sent via NEW_CONNECTION_ID frames are invalidated when their associated -connection ID is retired via a CONNECTION_ID_FINISHED frame +connection ID is retired via a RETIRE_CONNECTION_ID frame ({{frame-connection-id-finished}}). An endpoint that receives packets that it cannot process sends a packet in the @@ -3268,20 +3268,20 @@ the Source Connection ID used by the peer during the initial handshake, it MUST treat that receipt as a connection error of type PROTOCOL_VIOLATION. -## CONNECTION_ID_FINISHED Frame {#frame-connection-id-finished} +## RETIRE_CONNECTION_ID Frame {#frame-connection-id-finished} -An endpoint sends a CONNECTION_ID_FINISHED frame (type=0x1b) to indicate that it +An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x1b) to indicate that it will no longer use a connection ID that was issued by its peer. Note that this may include the connection ID provided during the handshake. Sending a -CONNECTION_ID_FINISHED frame also serves as a request to the peer to send +RETIRE_CONNECTION_ID frame also serves as a request to the peer to send additional connection IDs for future use (see {{connection-id}}). New connection IDs can be delivered via the NEW_CONNECTION_ID frame ({{frame-new- connection-id}}). -Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates the +Retiring a connection ID using the RETIRE_CONNECTION_ID frame invalidates the stateless reset token associated with that connection ID. -The CONNECTION_ID_FINISHED frame is as follows: +The RETIRE_CONNECTION_ID frame is as follows: ~~~ 0 1 2 3 @@ -3301,13 +3301,13 @@ Connection ID: : A connection ID of the specified length. -Receipt of a CONNECTION_ID_FINISHED frame containing a connection ID that was +Receipt of a RETIRE_CONNECTION_ID frame containing a connection ID that was not previously sent to the peer MAY be treated as a connection error of type PROTOCOL_VIOLATION. An endpoint cannot send this frame if it was provided with a zero-length connection ID by its peer. An endpoint that provides a zero-length connection -ID MUST treat receipt of a CONNECTION_ID_FINISHED frame as a connection error of +ID MUST treat receipt of a RETIRE_CONNECTION_ID frame as a connection error of type PROTOCOL_VIOLATION. @@ -3924,7 +3924,7 @@ containing that information is acknowledged. * New connection IDs are sent in NEW_CONNECTION_ID frames and retransmitted if the packet containing them is lost. Likewise, retired connection IDs are sent - in CONNECTION_ID_FINISHED frames and retransmitted if the packet containing + in RETIRE_CONNECTION_ID frames and retransmitted if the packet containing them is lost. * PADDING frames contain no information, so lost PADDING frames do not require From ae3ba4f23552694653b44c7f4d14c1f2bd74f35b Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 24 Sep 2018 17:21:54 -0700 Subject: [PATCH 07/13] stragglers --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 97cea4844c..2992323e89 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1244,7 +1244,7 @@ recommended number of outstanding connection IDs is eight. When an endpoint issues a connection ID, it MUST accept packets using this connection ID for the duration of the connection or until its peer invalidates the connection ID via a RETIRE_CONNECTION_ID frame -({{frame-connection-id-finished}}). +({{frame-retire-connection-id}}). Implementations SHOULD ensure that peers have sufficient connection IDs available to reduce the possibility of peers exhausting their supply of @@ -2626,7 +2626,7 @@ because their transport parameters don't have confidentiality protection). This value is protected by encryption, so only client and server know this value. Tokens sent via NEW_CONNECTION_ID frames are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame -({{frame-connection-id-finished}}). +({{frame-retire-connection-id}}). An endpoint that receives packets that it cannot process sends a packet in the following layout: @@ -3268,7 +3268,7 @@ the Source Connection ID used by the peer during the initial handshake, it MUST treat that receipt as a connection error of type PROTOCOL_VIOLATION. -## RETIRE_CONNECTION_ID Frame {#frame-connection-id-finished} +## RETIRE_CONNECTION_ID Frame {#frame-retire-connection-id} An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x1b) to indicate that it will no longer use a connection ID that was issued by its peer. Note that this From 6dc077fbc4763687cb1c8400e4d9466ab7a906a9 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 24 Sep 2018 17:40:18 -0700 Subject: [PATCH 08/13] cleaned up section on issuing connection IDs --- draft-ietf-quic-transport.md | 59 ++++++++++++++---------------------- 1 file changed, 23 insertions(+), 36 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2992323e89..c040e1362d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1220,48 +1220,38 @@ connection. An endpoint whose peer has selected a zero-length connection ID MUST continue to use a zero-length connection ID for the lifetime of the connection and MUST NOT send packets from any other local address. -An endpoint whose peer has selected a non-zero-length connection ID will -potentially send packets using different connection IDs over the lifetime of a -connection. These connection IDs are supplied by the peer using the -NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). +When an endpoint has requested a non-zero-length connection ID, it needs to +ensure that the peer has a supply of connection IDs from which to choose for +packets sent to the endpoint. These connection IDs are supplied by the endpoint +using the NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). ### Issuing Connection IDs -An endpoint issues connection IDs to its peer for the peer to use when sending -packets. This allows the endpoint control over the strategy used to interpret -connection IDs of packets that it receives. These connection IDs are -communicated to the peer using NEW_CONNECTION_ID frames -({{frame-new-connection-id}}). +The initial connection ID issued by an endpoint is the Source Connection ID +during the handshake. Subsequent connection IDs are communicated to the peer +using NEW_CONNECTION_ID frames ({{frame-new-connection-id}}). While each +endpoint independently chooses how many connection IDs to issue, a recommended +number of outstanding connection IDs is eight. -The initial connection ID issued to the peer is sent by the endpoint as the -Source Connection ID during the handshake, ensuring that the peer always begins -the connection with at least one connection ID to use when sending. An endpoint -SHOULD supply its peer with additional connection IDs via NEW_CONNECTION_ID -frames. While each endpoint can choose how many connection IDs to issue, a -recommended number of outstanding connection IDs is eight. - -When an endpoint issues a connection ID, it MUST accept packets using this +When an endpoint issues a connection ID, it MUST accept packets that carry this connection ID for the duration of the connection or until its peer invalidates the connection ID via a RETIRE_CONNECTION_ID frame ({{frame-retire-connection-id}}). -Implementations SHOULD ensure that peers have sufficient connection IDs -available to reduce the possibility of peers exhausting their supply of -available connection IDs. An implementation could do this by always supplying a -new connection ID for each connection ID retired with a RETIRE_CONNECTION_ID -frame. When a receiver of a packet notices that its peer is now using a -previously unused connection ID, it can supply its peer with a new connection ID -using a NEW_CONNECTION_ID frame to reduce the possibility of its peer running -out of available connection IDs. - -Endpoints that use connection IDs with length greater than zero could have their -activity correlated if their peers keep using the same destination connection ID -after migration. An endpoint that receives a packet with a different remote -address or destination connection ID than previously used SHOULD also switch to -sending with a connection ID that has not previously been used. The goal is to -ensure absence of correlation between the pairs of client and server connection -ID used on different paths. To fulfill this privacy requirement, endpoints that +An endpoint SHOULD ensure that its peer has a sufficient number of available and +unused connection IDs. The endpoint can do this by always supplying a new +connection ID when a connection ID is retired by its peer or when the endpoint +receives a packet with a previously unused connection ID. + + +### Consuming Connection IDs + +An endpoint that receives a packet with a different remote address or +destination connection ID than previously used SHOULD also switch to sending +with a connection ID that has not previously been used. The goal is to ensure +absence of correlation between the pairs of client and server connection ID used +on different paths. To fulfill this privacy requirement, endpoints that initiate migration and use connection IDs with length greater than zero SHOULD provide their peers with new connection IDs before migration. @@ -1271,9 +1261,6 @@ Caution: connection ID from their peer, then this can trigger an infinite sequence of changes. - -### Consuming Connection IDs - If an endpoint's peer has selected a non-zero-length connection ID, the endpoint maintains a set of connection IDs received from the peer that it can use when sending packets. All connection IDs issued by the peer are considered valid for From b64b73cb29bdea47c266dee579f768785ec08c5b Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 24 Sep 2018 18:01:19 -0700 Subject: [PATCH 09/13] finished section on consuming and retiring connection IDs --- draft-ietf-quic-transport.md | 72 +++++++++++++++++++----------------- 1 file changed, 39 insertions(+), 33 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c040e1362d..879be3e421 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1242,46 +1242,37 @@ the connection ID via a RETIRE_CONNECTION_ID frame An endpoint SHOULD ensure that its peer has a sufficient number of available and unused connection IDs. The endpoint can do this by always supplying a new connection ID when a connection ID is retired by its peer or when the endpoint -receives a packet with a previously unused connection ID. - - -### Consuming Connection IDs +receives a packet with a previously unused connection ID. Endpoints that +initiate migration and require non-zero-length connection IDs SHOULD provide +their peers with new connection IDs before migration, or risk the peer closing +the connection. -An endpoint that receives a packet with a different remote address or -destination connection ID than previously used SHOULD also switch to sending -with a connection ID that has not previously been used. The goal is to ensure -absence of correlation between the pairs of client and server connection ID used -on different paths. To fulfill this privacy requirement, endpoints that -initiate migration and use connection IDs with length greater than zero SHOULD -provide their peers with new connection IDs before migration. -Caution: +### Consuming and Retiring Connection IDs -: If both endpoints change connection ID in response to seeing a change in - connection ID from their peer, then this can trigger an infinite sequence - of changes. +An endpoint can arbitrarily 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 response to a migrating peer, see {{#migration-linkability}} +for more. -If an endpoint's peer has selected a non-zero-length connection ID, the endpoint -maintains a set of connection IDs received from the peer that it can use when -sending packets. All connection IDs issued by the peer are considered valid for -use by the endpoint when sending packets until the connection ID is retired by -the endpoint. Endpoints can choose to stop using a given connection ID to send -packets at any time and signal this to the issuing endpoint via a -RETIRE_CONNECTION_ID frame. +An endpoint maintains a set of connection IDs received from its peer, any of +which it can use when sending packets. When the endpoint wishes to remove a +connection ID from use, it sends a RETIRE_CONNECTION_ID frame to its peer, +indicating that the peer might bring a new connection ID into circulation using +the NEW_CONNECTION_ID frame. An endpoint that retires a connection ID should retain knowledge of that -connection ID for a period of time after sending the RETIRE_CONNECTION_ID -frame, or until that frame is acknowledged. A recommended time is three times -the current Retransmission Timeout (RTO) interval as defined in -{{QUIC-RECOVERY}}. This prevents potential retransmissions of a -NEW_CONNECTION_ID frame from overlapping with the RETIRE_CONNECTION_ID frame -for the same connection ID. +connection ID for a period of time after sending the RETIRE_CONNECTION_ID frame, +or until that frame is acknowledged. A recommended time is three times the +current retransmission timeout (RTO) interval as defined in {{QUIC-RECOVERY}}. +This prevents confusion from receiving retransmissions of a NEW_CONNECTION_ID +frame soon after sending a RETIRE_CONNECTION_ID frame for the same connection +ID. -Additionally, each connection ID MUST be used on packets sent from only one -local address. At any time, an endpoint MAY change to a new connection ID on a -local address already in use. An endpoint that migrates away from a local -address SHOULD retire all connection IDs used on that address once it no longer -plans to use that address. +As discussed in {{migration-linkability}}, each connection ID MUST be used on +packets sent from only one local address. An endpoint that migrates away from a +local address SHOULD retire all connection IDs used on that address once it no +longer plans to use that address. ## Matching Packets to Connections {#packet-handling} @@ -2390,6 +2381,21 @@ genuine migrations. Changing port number can cause a peer to reset its congestion state (see {{migration-cc}}), so the port SHOULD only be changed infrequently. +Endpoints that use connection IDs with length greater than zero could have their +activity correlated if their peers keep using the same destination connection ID +after migration. Endpoints that receive packets with a previously unused +Destination Connection ID SHOULD change to sending packets with a connection ID +that has not been used on any other network path. The goal is to ensure absence +of correlation between the pairs of client and server connection ID used on +different paths. To fulfill this privacy requirement, endpoints that initiate +migration and use connection IDs with length greater than zero SHOULD provide +their peers with new connection IDs before migration. + +Caution: + +: If both endpoints change connection ID in response to seeing a change in + connection ID from their peer, then this can trigger an infinite sequence of + changes. ## Server's Preferred Address {#preferred-address} From 978abd8333d35663df22fdc897c5ee6aac39d152 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 24 Sep 2018 18:05:24 -0700 Subject: [PATCH 10/13] final bits --- draft-ietf-quic-transport.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 879be3e421..478b40aa2c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3264,15 +3264,14 @@ PROTOCOL_VIOLATION. ## RETIRE_CONNECTION_ID Frame {#frame-retire-connection-id} An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x1b) to indicate that it -will no longer use a connection ID that was issued by its peer. Note that this -may include the connection ID provided during the handshake. Sending a -RETIRE_CONNECTION_ID frame also serves as a request to the peer to send -additional connection IDs for future use (see {{connection-id}}). New -connection IDs can be delivered via the NEW_CONNECTION_ID frame ({{frame-new- -connection-id}}). +will no longer use a connection ID that was issued by its peer. This may include +the connection ID provided during the handshake. Sending a RETIRE_CONNECTION_ID +frame also serves as a request to the peer to send additional connection IDs for +future use (see {{connection-id}}). New connection IDs can be delivered to a +peer using the NEW_CONNECTION_ID frame ({{frame-new- connection-id}}). -Retiring a connection ID using the RETIRE_CONNECTION_ID frame invalidates the -stateless reset token associated with that connection ID. +Retiring a connection ID invalidates the stateless reset token associated with +that connection ID. The RETIRE_CONNECTION_ID frame is as follows: @@ -3294,8 +3293,8 @@ Connection ID: : A connection ID of the specified length. -Receipt of a RETIRE_CONNECTION_ID frame containing a connection ID that was -not previously sent to the peer MAY be treated as a connection error of type +Receipt of a RETIRE_CONNECTION_ID frame containing a connection ID that was not +previously sent to the peer MAY be treated as a connection error of type PROTOCOL_VIOLATION. An endpoint cannot send this frame if it was provided with a zero-length From 93052d0c45eed5c298c5480d05f49e66f5c7fd04 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 24 Sep 2018 18:07:11 -0700 Subject: [PATCH 11/13] nits --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 478b40aa2c..55ae7dd862 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1252,8 +1252,8 @@ the connection. An endpoint can arbitrarily 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 response to a migrating peer, see {{#migration-linkability}} -for more. +connection IDs in response to a migrating peer, see {{migration-linkability}} +for more. An endpoint maintains a set of connection IDs received from its peer, any of which it can use when sending packets. When the endpoint wishes to remove a @@ -2391,7 +2391,7 @@ different paths. To fulfill this privacy requirement, endpoints that initiate migration and use connection IDs with length greater than zero SHOULD provide their peers with new connection IDs before migration. -Caution: +Caution: : If both endpoints change connection ID in response to seeing a change in connection ID from their peer, then this can trigger an infinite sequence of From 94c6a0eb69baf56e09ae331d557da0af4ad29984 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 24 Sep 2018 18:16:21 -0700 Subject: [PATCH 12/13] mt review --- draft-ietf-quic-transport.md | 40 +++++++++++++++++------------------- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 55ae7dd862..794e2947b9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1230,9 +1230,7 @@ using the NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). The initial connection ID issued by an endpoint is the Source Connection ID during the handshake. Subsequent connection IDs are communicated to the peer -using NEW_CONNECTION_ID frames ({{frame-new-connection-id}}). While each -endpoint independently chooses how many connection IDs to issue, a recommended -number of outstanding connection IDs is eight. +using NEW_CONNECTION_ID frames ({{frame-new-connection-id}}). When an endpoint issues a connection ID, it MUST accept packets that carry this connection ID for the duration of the connection or until its peer invalidates @@ -1240,20 +1238,21 @@ the connection ID via a RETIRE_CONNECTION_ID frame ({{frame-retire-connection-id}}). An endpoint SHOULD ensure that its peer has a sufficient number of available and -unused connection IDs. The endpoint can do this by always supplying a new -connection ID when a connection ID is retired by its peer or when the endpoint -receives a packet with a previously unused connection ID. Endpoints that -initiate migration and require non-zero-length connection IDs SHOULD provide -their peers with new connection IDs before migration, or risk the peer closing -the connection. +unused connection IDs. While each endpoint independently chooses how many +connection IDs to issue, endpoints SHOULD provide and maintain at least eight +connection IDs. The endpoint can do this by always supplying a new connection +ID when a connection ID is retired by its peer or when the endpoint receives a +packet with a previously unused connection ID. Endpoints that initiate +migration and require non-zero-length connection IDs SHOULD provide their peers +with new connection IDs before migration, or risk the peer closing the +connection. ### Consuming and Retiring Connection IDs -An endpoint can arbitrarily 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 response to a migrating peer, see {{migration-linkability}} -for more. +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 +response to a migrating peer, see {{migration-linkability}} for more. An endpoint maintains a set of connection IDs received from its peer, any of which it can use when sending packets. When the endpoint wishes to remove a @@ -1265,9 +1264,8 @@ An endpoint that retires a connection ID should retain knowledge of that connection ID for a period of time after sending the RETIRE_CONNECTION_ID frame, or until that frame is acknowledged. A recommended time is three times the current retransmission timeout (RTO) interval as defined in {{QUIC-RECOVERY}}. -This prevents confusion from receiving retransmissions of a NEW_CONNECTION_ID -frame soon after sending a RETIRE_CONNECTION_ID frame for the same connection -ID. +This prevents a retransmission of a NEW_CONNECTION_ID frame from incorrectly +renewing a previously retired connection ID. As discussed in {{migration-linkability}}, each connection ID MUST be used on packets sent from only one local address. An endpoint that migrates away from a @@ -2385,11 +2383,11 @@ Endpoints that use connection IDs with length greater than zero could have their activity correlated if their peers keep using the same destination connection ID after migration. Endpoints that receive packets with a previously unused Destination Connection ID SHOULD change to sending packets with a connection ID -that has not been used on any other network path. The goal is to ensure absence -of correlation between the pairs of client and server connection ID used on -different paths. To fulfill this privacy requirement, endpoints that initiate -migration and use connection IDs with length greater than zero SHOULD provide -their peers with new connection IDs before migration. +that has not been used on any other network path. The goal here is to ensure +that packets sent on different paths cannot be correlated. To fulfill this +privacy requirement, endpoints that initiate migration and use connection IDs +with length greater than zero SHOULD provide their peers with new connection IDs +before migration. Caution: From 48ff3e7050c3298008929ce40d130bd1bc745e0e Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 24 Sep 2018 18:18:35 -0700 Subject: [PATCH 13/13] fix --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 794e2947b9..c2d4e93b9b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3266,7 +3266,7 @@ will no longer use a connection ID that was issued by its peer. This may include the connection ID provided during the handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a request to the peer to send additional connection IDs for future use (see {{connection-id}}). New connection IDs can be delivered to a -peer using the NEW_CONNECTION_ID frame ({{frame-new- connection-id}}). +peer using the NEW_CONNECTION_ID frame ({{frame-new-connection-id}}). Retiring a connection ID invalidates the stateless reset token associated with that connection ID.