From e94896b3ce3f572a6ee5e34a883c1ce7a25957c0 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 17:42:13 -0700 Subject: [PATCH 01/17] Clarify opaque --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 553cd9e8ce..687faf2e56 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -224,9 +224,9 @@ Address: Connection ID: -: An opaque identifier that is used to identify a QUIC connection at an +: An identifier that is used to identify a QUIC connection at an endpoint. Each endpoint sets a value for its peer to include in packets sent - towards the endpoint. + towards the endpoint; this value is opaque to the peer. Stream: From 1661f16071624490fdc39da7fe73ca0cf6f40ba0 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 17:42:31 -0700 Subject: [PATCH 02/17] Clarify gthe ? in the encoding language --- draft-ietf-quic-transport.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 687faf2e56..5d6bface63 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -263,10 +263,12 @@ x (A..B): values in this format always end on an octet boundary x (?) = C: -: Indicates that x has a fixed value of C +: Indicates that x has a fixed value of C with the length described by + ?, as above. x (?) = C..D: -: Indicates that x has a value in the range from C to D, inclusive +: Indicates that x has a value in the range from C to D, inclusive, + with the encoding described by ?, as above. \[x (E)\]: : Indicates that x is optional (and has length of E) From d29bd9f3b019c82785109ca8a5b729bb4acb178b Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 17:43:58 -0700 Subject: [PATCH 03/17] Don't say that unidirectional is a long message. That just confuses things --- draft-ietf-quic-transport.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5d6bface63..4086744b22 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -304,9 +304,7 @@ Example Structure { # Streams {#streams} Streams in QUIC provide a lightweight, ordered byte-stream abstraction to an -application. Streams can be unidirectional or bidirectional. An alternative -view of QUIC unidirectional streams is a "message" abstraction of practically -unlimited length. +application. Streams can be unidirectional or bidirectional. Streams can be created by sending data. Other processes associated with stream management - ending, cancelling, and managing flow control - are all designed to From 416932e8c4947cf5c568d08937b63bb81f348ca0 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 17:45:15 -0700 Subject: [PATCH 04/17] Clarify the example of stream IDs --- draft-ietf-quic-transport.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4086744b22..e47a76af18 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -357,7 +357,10 @@ Within each type, streams are created with numerically increasing stream IDs. A stream ID that is used out of order results in all streams of that type with lower-numbered stream IDs also being opened. -The first bidirectional stream opened by the client has a stream ID of 0. +For example, the first bidirectional stream opened by the client has a +stream ID of 0 and the first bidirectional stream opened by the server +has a stream ID of 1. + ## Sending and Receiving Data From f7bcfecf925ed0cdaf140e8a6e22faacd25ab4a6 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 17:55:35 -0700 Subject: [PATCH 05/17] Clarify the stream ID limits. Remove redundancy --- draft-ietf-quic-transport.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e47a76af18..4e02db7c44 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -803,6 +803,8 @@ entire connection. This leads to two levels of data flow control in QUIC: * Connection flow control, which prevents senders from exceeding a receiver's buffer capacity for the connection, by limiting the total bytes of stream data sent in STREAM frames on all streams. + +Senders MUST not send data in excess of either limit. A receiver sets initial limits for all streams by sending transport parameters during the handshake ({{transport-parameters}}). A receiver sends @@ -810,12 +812,10 @@ MAX_STREAM_DATA ({{frame-max-stream-data}}) or MAX_DATA ({{frame-max-data}}) frames to the sender to advertise larger limits. A receiver can advertise a larger limit for a stream by sending a -MAX_STREAM_DATA frame with the Stream ID field set appropriately. A -MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a stream. A -receiver could use the current offset of data consumed to determine the flow -control offset to be advertised. A receiver MAY send MAX_STREAM_DATA frames in -multiple packets in order to make sure that the sender receives an update before -running out of flow control, even if one of the packets is lost. +MAX_STREAM_DATA frame with corresponding Stream ID field. A +MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a +stream. A receiver could use the current offset of data consumed to +determine the flow control offset to be advertised. A receiver can advertise a larger limit for a connection by sending a MAX_DATA frame, which indicates the maximum of the sum of the absolute byte offsets of @@ -849,7 +849,7 @@ DATA_BLOCKED frame when it has no ack-eliciting packets in flight. Implementations decide when and how much credit to advertise in MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few considerations. -To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or MAX_DATA +To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or MAX_DATA frame multiple times within a round trip or send it early enough to allow for recovery from loss of the frame. From 44749f23bed53029e71d9365f3a80a7bcffabaa6 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 17:56:44 -0700 Subject: [PATCH 06/17] You actually don't know definitively how many bytes were sent --- draft-ietf-quic-transport.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4e02db7c44..949382b143 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -890,12 +890,12 @@ matching stream and ignore further data arriving on that stream. Without the offset included in RESET_STREAM, the two endpoints could disagree on the number of bytes that count towards connection flow control. -To remedy this issue, a RESET_STREAM frame ({{frame-reset-stream}}) includes the -final size of data sent on the stream. On receiving a RESET_STREAM frame, a -receiver definitively knows how many bytes were sent on that stream before the -RESET_STREAM frame, and the receiver MUST use the final size of the stream to -account for all bytes sent on the stream in its connection level flow -controller. +To remedy this issue, a RESET_STREAM frame ({{frame-reset-stream}}) +includes the final size of data sent on the stream. On receiving a +RESET_STREAM frame, a receiver knows how many bytes the sender claims +were sent on that stream before the RESET_STREAM frame, and the +receiver MUST use the final size of the stream to account for all +bytes sent on the stream in its connection level flow controller. RESET_STREAM terminates one direction of a stream abruptly. For a bidirectional stream, RESET_STREAM has no effect on data flow in the opposite direction. Both From 10d7d53b6d40c8c68ed170933a5516014a541163 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 18:19:02 -0700 Subject: [PATCH 07/17] early data -> 0-RTT data --- 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 949382b143..0b3fde6f85 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1300,10 +1300,10 @@ When implementing the server role, applications need to be able to: - listen for incoming connections, which prepares for the exchange described in {{handshake}}; -- if Early Data is supported, embed application-controlled data in the TLS +- if 0-RTT data is supported, embed application-controlled data in the TLS resumption ticket sent to the client; and -- if Early Data is supported, retrieve application-controlled data from the - client's resumption ticket and enable rejecting Early Data based on that +- if 0-RTT data is supported, retrieve application-controlled data from the + client's resumption ticket and enable rejecting 0-RTT data based on that information. In either role, applications need to be able to: From e2fa786b58fdbe90bf9edcd7cb7544fc3a241d2b Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 18:21:17 -0700 Subject: [PATCH 08/17] Fix description of the results of Version Negotiation. Remind me why this isn't called Version Error... --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0b3fde6f85..7fa87a5791 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1321,8 +1321,8 @@ In either role, applications need to be able to: # Version Negotiation {#version-negotiation} -Version negotiation ensures that client and server agree to a QUIC version -that is mutually supported. A server sends a Version Negotiation packet in +Version negotiation allows a server to indicate that it does not support +the version the client used. A server sends a Version Negotiation packet in response to each packet that might initiate a new connection; see {{packet-handling}} for details. From 5574143fbd57dfd313d61ce4f99e533fe986b631 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 18:26:02 -0700 Subject: [PATCH 09/17] You don't change SCID on later packets --- draft-ietf-quic-transport.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 7fa87a5791..39f223b9ba 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1530,12 +1530,13 @@ Connection ID is chosen by the recipient of the packet and is used to provide consistent routing; the Source Connection ID is used to set the Destination Connection ID used by the peer. -During the handshake, packets with the long header ({{long-header}}) are used to -establish the connection IDs in each direction. Each endpoint uses the Source -Connection ID field to specify the connection ID that is used in the Destination -Connection ID field of packets being sent to them. Upon receiving a packet, each -endpoint sets the Destination Connection ID it sends to match the value of the -Source Connection ID that it receives. +During the handshake, packets with the long header ({{long-header}}) +are used to establish the connection IDs in each direction. Each +endpoint uses the Source Connection ID field to specify the connection +ID that is used in the Destination Connection ID field of packets +being sent to them. Upon receiving the first packet from the peer, +each endpoint sets the Destination Connection ID it sends to match the +value of the Source Connection ID that it receives. When an Initial packet is sent by a client that has not previously received an Initial or Retry packet from the server, the client populates the Destination From 33f37e8af4a99f68e5f5d3a05cf00e04302cfc41 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 18:30:06 -0700 Subject: [PATCH 10/17] Clarify impact of on-path spoofing --- draft-ietf-quic-transport.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 39f223b9ba..96b25069d6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2323,18 +2323,20 @@ because the entity at the source address does not have the necessary cryptographic keys to read or respond to the PATH_CHALLENGE frame that is sent to it even if it wanted to. -To protect the connection from failing due to such a spurious migration, an -endpoint MUST revert to using the last validated peer address when validation of -a new peer address fails. +To protect the connection from failing due to such a spurious +migration, an endpoint MUST revert to using the last validated peer +address when validation of a new peer address fails. Additionally, +receipt of packets with higher packet numbers from the legitimate peer +address will trigger another connection migration. This will cause +the validation of the address of the spurious migration to be +abandoned, thus containing migrations initiated by the attacker +injecting a single packet. If an endpoint has no state about the last validated peer address, it MUST close the connection silently by discarding all connection state. This results in new packets on the connection being handled generically. For instance, an endpoint MAY send a stateless reset in response to any further incoming packets. -Note that receipt of packets with higher packet numbers from the legitimate peer -address will trigger another connection migration. This will cause the -validation of the address of the spurious migration to be abandoned. ### Off-Path Packet Forwarding {#off-path-forward} From 663f0e4e890077d1a90994ea70d199a454ae673c Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 18:34:46 -0700 Subject: [PATCH 11/17] Clarify awkward text around preferred connection --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 96b25069d6..3b042cbb2e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2514,11 +2514,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 confirmed, the client SHOULD select one of the two -server's preferred addresses and initiate path validation (see +Once the handshake is confirmed, the client SHOULD select one of the two values +preferred addresses provided by the server and initiate path validation (see {{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. +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 From c9dd3a6ec7d5e1bbc04f25b0348ba4642f1fce2d Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 18:46:45 -0700 Subject: [PATCH 12/17] Tiny wording change --- draft-ietf-quic-transport.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3b042cbb2e..623db9131e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2672,7 +2672,9 @@ source address. If a max_idle_timeout is specified by either peer in its transport parameters ({{transport-parameter-definitions}}), the connection is silently closed -and its state is discarded when it remains idle for longer than the minimum of +and its state is discarded when it remains idle for longer than either + +the minimum of both peers max_idle_timeout values and three times the current Probe Timeout (PTO). @@ -2801,7 +2803,7 @@ sent in a packet that uses a lower packet protection level. More specifically: send a CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at least one of them is processable by the client. -* A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be assured of +* A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be assured that the server has accepted 0-RTT and so sending a CONNECTION_CLOSE frame in an Initial packet makes it more likely that the server can receive the close signal, even if the application error code might not be received. From 135a0ffad9d2fb43c5196fd927fbb23a236a457a Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 19:01:04 -0700 Subject: [PATCH 13/17] Retry packets don't use keys derived from the handshake --- 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 623db9131e..01e94f8b82 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3161,7 +3161,7 @@ packet protection is not effective confidentiality protection. Initial protection only exists to ensure that the sender of the packet is on the network path. Any entity that receives the Initial packet from a client can recover the keys necessary to remove packet protection or to generate packets that will be -successfully authenticated. +successfully authenticated. Retry packets are protected using a fixed key. All other packets are protected with keys derived from the cryptographic handshake. The type of the packet from the long header or key phase from the From e8ab8bfd347ac60d3daf2668411b21d577a31d21 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 19:07:47 -0700 Subject: [PATCH 14/17] One follows the guidance --- 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 01e94f8b82..62954d68b8 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3503,7 +3503,7 @@ the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events. The algorithms in {{QUIC-RECOVERY}} are expected to be resilient to receivers -that do not follow guidance offered above. However, an implementation should +that do not follow the guidance offered above. However, an implementation should only deviate from these requirements after careful consideration of the performance implications of a change, for connections made by the endpoint and for other users of the network. From 60ea0f1703ee7df06e1c0821fa9517525398a9dd Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 19:13:21 -0700 Subject: [PATCH 15/17] Remove commas, this is a restrictive clause --- 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 62954d68b8..22e43ab670 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4341,7 +4341,7 @@ Reserved Bits: packet types. These bits are protected using header protection; see Section 5.4 of {{QUIC-TLS}}. The value included prior to protection MUST be set to 0. An endpoint MUST treat receipt of a packet that has a non-zero value for these - bits, after removing both packet and header protection, as a connection error + bits after removing both packet and header protection as a connection error of type PROTOCOL_VIOLATION. Discarding such a packet after only removing header protection can expose the endpoint to attacks; see Section 9.3 of {{QUIC-TLS}}. From 342b58ac7799bc4ead5110bed813a6955282e398 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 19:20:49 -0700 Subject: [PATCH 16/17] includes -> included --- 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 22e43ab670..654cf6647c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4721,7 +4721,7 @@ The next Initial packet from the client uses the connection ID and token values from the Retry packet; see {{negotiating-connection-ids}}. Aside from this, the Initial packet sent by the client is subject to the same restrictions as the first Initial packet. A client MUST use the same cryptographic handshake -message it includes in this packet. A server MAY treat a packet that +message it included in this packet. A server MAY treat a packet that contains a different cryptographic handshake message as a connection error or discard it. From afdc22d22bdaf78be5c9a65202192dbf20f264ea Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Jul 2020 19:23:01 -0700 Subject: [PATCH 17/17] Clarify which field --- 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 654cf6647c..d416af2d85 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -5531,9 +5531,9 @@ NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION. ## STREAM Frames {#frame-stream} STREAM frames implicitly create a stream and carry stream data. The STREAM -frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f). The -value of the three low-order bits of the frame type determines the fields that -are present in the frame. +frame type field takes the form 0b00001XXX (or the set of values from 0x08 to +0x0f). The value of the three low-order bits of the frame type determines the +fields that are present in the frame. * The OFF bit (0x04) in the frame type is set to indicate that there is an Offset field present. When set to 1, the Offset field is present. When set