This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on March 19, 2020.
+
This Internet-Draft will expire on April 19, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document defines the “quic” parameter for Alt-Svc, which MAY be used to provide version-negotiation hints to HTTP/3 clients. QUIC versions are four-byte sequences with no additional constraints on format. Leading zeros SHOULD be omitted for brevity.
Where multiple versions are listed, the order of the values reflects the server’s preference (with the first value being the most preferred version). Reserved versions MAY be listed, but unreserved versions which are not supported by the alternative SHOULD NOT be present in the list. Origins MAY omit supported versions for any reason.
Clients MUST ignore any included versions which they do not support. The “quic” parameter MUST NOT occur more than once; clients SHOULD process only the first occurrence.
@@ -808,7 +808,7 @@
HTTP message headers carry information as a series of key-value pairs, called header fields. For a listing of registered HTTP header fields, see the “Message Header Field” registry maintained at https://www.iana.org/assignments/message-headers.
Just as in previous versions of HTTP, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. Properties of HTTP header field names and values are discussed in more detail in Section 3.2 of [RFC7230], though the wire rendering in HTTP/3 differs. As in HTTP/2, header field names MUST be converted to lowercase prior to their encoding. A request or response containing uppercase header field names MUST be treated as malformed (Section 4.1.3).
-
As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with the ‘:’ character (ASCII 0x3a) to convey the target URI, the method of the request, and the status code for the response. These pseudo-header fields are defined in Section 8.1.2.3 and 8.1.2.4 of [HTTP2]. Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT generate pseudo-header fields other than those defined in [HTTP2]. The restrictions on the use of pseudo-header fields in Section 8.1.2.1 of [HTTP2] also apply to HTTP/3.
+
As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with the ‘:’ character (ASCII 0x3a) to convey the target URI, the method of the request, and the status code for the response. These pseudo-header fields are defined in Section 8.1.2.3 and 8.1.2.4 of [HTTP2]. Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT generate pseudo-header fields other than those defined in [HTTP2]. The restrictions on the use of pseudo-header fields in Section 8.1.2 of [HTTP2] also apply to HTTP/3. Messages which are considered malformed under these restrictions are handled as described in Section 4.1.3.
HTTP/3 uses QPACK header compression as described in [QPACK], a variation of HPACK which allows the flexibility to avoid header-compression-induced head-of-line blocking. See that document for additional details.
To allow for better compression efficiency, the cookie header field [RFC6265] MAY be split into separate header fields, each with one or more cookie-pairs, before compression. If a decompressed header list contains multiple cookie header fields, these MUST be concatenated before being passed into a non-HTTP/2, non-HTTP/3 context, as described in [HTTP2], Section 8.1.2.5.
An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message. A server that receives a larger header field list than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code [RFC6585]. A client can discard responses that it cannot process. The size of a header field list is calculated based on the uncompressed size of header fields, including the length of the name and value in bytes plus an overhead of 32 bytes for each header field.
Some stream types are reserved (Section 6.2.3). Two stream types are defined in this document: control streams (Section 6.2.1) and push streams (Section 6.2.2). Other stream types can be defined by extensions to HTTP/3; see Section 9 for more details.
+
Some stream types are reserved (Section 6.2.3). Two stream types are defined in this document: control streams (Section 6.2.1) and push streams (Section 6.2.2). [QPACK] defines two additional stream types. Other stream types can be defined by extensions to HTTP/3; see Section 9 for more details.
The performance of HTTP/3 connections in the early phase of their lifetime is sensitive to the creation and exchange of data on unidirectional streams. Endpoints that excessively restrict the number of streams or the flow control window of these streams will increase the chance that the remote peer reaches the limit early and becomes blocked. In particular, implementations should consider that remote peers may wish to exercise reserved stream behavior (Section 6.2.3) with some of the unidirectional streams they are permitted to use. To avoid blocking, the transport parameters sent by both clients and servers MUST allow the peer to create at least one unidirectional stream for the HTTP control stream plus the number of unidirectional streams required by mandatory extensions (three being the minimum number required for the base HTTP/3 protocol and QPACK), and SHOULD provide at least 1,024 bytes of flow control credit to each stream.
Note that an endpoint is not required to grant additional credits to create more unidirectional streams if its peer consumes all the initial credits before creating the critical unidirectional streams. Endpoints SHOULD create the HTTP control stream as well as the unidirectional streams required by mandatory extensions (such as the QPACK encoder and decoder streams) first, and then create additional streams as allowed by their peer.
If the stream header indicates a stream type which is not supported by the recipient, the remainder of the stream cannot be consumed as the semantics are unknown. Recipients of unknown stream types MAY abort reading of the stream with an error code of HTTP_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be a connection error of any kind.
The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a server push prior to the push stream being received. The CANCEL_PUSH frame identifies a server push by Push ID (see Section 7.2.5), encoded as a variable-length integer.
-
When a server receives this frame, it aborts sending the response for the identified server push. If the server has not yet started to send the server push, it can use the receipt of a CANCEL_PUSH frame to avoid opening a push stream. If the push stream has been opened by the server, the server SHOULD abruptly terminate that stream.
-
A server can send the CANCEL_PUSH frame to indicate that it will not be fulfilling a promise prior to creation of a push stream. Once the push stream has been created, sending CANCEL_PUSH has no effect on the state of the push stream. The server SHOULD abruptly terminate the push stream instead.
-
A CANCEL_PUSH frame is sent on the control stream. Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be treated as a connection error of type HTTP_FRAME_UNEXPECTED.
+
When a client sends CANCEL_PUSH, it is indicating that it does not wish to receive the promised resource. The server SHOULD abort sending the resource, but the mechanism to do so depends on the state of the corresponding push stream. If the server has not yet created a push stream, it does not create one. If the push stream is open, the server SHOULD abruptly terminate that stream. If the push stream has already ended, the server MAY still abruptly terminate the stream or MAY take no action.
+
When a server sends CANCEL_PUSH, it is indicating that it will not be fulfilling a promise and has not created a push stream. The client should not expect the corresponding promise to be fulfilled.
+
Sending CANCEL_PUSH has no direct effect on the state of existing push streams. A server SHOULD NOT send a CANCEL_PUSH when it has already created a corresponding push stream, and a client SHOULD NOT send a CANCEL_PUSH when it has already received a corresponding push stream.
+
A CANCEL_PUSH frame is sent on the control stream. Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be treated as a connection error of type HTTP_FRAME_UNEXPECTED.
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length integer. The Push ID identifies the server push that is being cancelled (see Section 7.2.5).
-
If the client receives a CANCEL_PUSH frame, that frame might identify a Push ID that has not yet been mentioned by a PUSH_PROMISE frame.
+
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length integer. The Push ID identifies the server push that is being cancelled (see Section 7.2.5). If a CANCEL_PUSH frame is received which references a Push ID greater than currently allowed on the connection, this MUST be treated as a connection error of type HTTP_ID_ERROR.
+
If the client receives a CANCEL_PUSH frame, that frame might identify a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due to reordering. If a server receives a CANCEL_PUSH frame for a Push ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST be treated as a connection error of type HTTP_ID_ERROR.
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the number of server pushes that the server can initiate. This sets the maximum value for a Push ID that the server can use in a PUSH_PROMISE frame. Consequently, this also limits the number of push streams that the server can initiate in addition to the limit maintained by the QUIC transport.
+
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the number of server pushes that the server can initiate. This sets the maximum value for a Push ID that the server can use in PUSH_PROMISE and CANCEL_PUSH frames. Consequently, this also limits the number of push streams that the server can initiate in addition to the limit maintained by the QUIC transport.
The MAX_PUSH_ID frame is always sent on the control stream. Receipt of a MAX_PUSH_ID frame on any other stream MUST be treated as a connection error of type HTTP_FRAME_UNEXPECTED.
A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the receipt of a MAX_PUSH_ID frame as a connection error of type HTTP_FRAME_UNEXPECTED.
The maximum Push ID is unset when a connection is created, meaning that a server cannot push until it receives a MAX_PUSH_ID frame. A client that wishes to manage the number of promised server pushes can increase the maximum Push ID by sending MAX_PUSH_ID frames as the server fulfills or cancels server pushes.
@@ -1248,7 +1249,7 @@
Frame types of the format 0x1f * N + 0x21 for integer values of N are reserved to exercise the requirement that unknown types be ignored (Section 9). These frames have no semantics, and can be sent on any open stream when application-layer padding is desired. They MAY also be sent on connections where no data is currently being transferred. Endpoints MUST NOT consider these frames to have any meaning upon receipt.
The payload and length of the frames are selected in any manner the implementation chooses.
-
Frame types which were used in HTTP/2 where there is no corresponding HTTP/3 frame have also been reserved (Section 11.3). These frame types MUST NOT be sent, and receipt MAY be treated as an error of type HTTP_UNEXPECTED_FRAME.
+
Frame types which were used in HTTP/2 where there is no corresponding HTTP/3 frame have also been reserved (Section 11.3). These frame types MUST NOT be sent, and receipt MAY be treated as an error of type HTTP_FRAME_UNEXPECTED.
diff --git a/close3029/draft-ietf-quic-http.txt b/ianswett-limit-bursts/draft-ietf-quic-http.txt
similarity index 90%
rename from close3029/draft-ietf-quic-http.txt
rename to ianswett-limit-bursts/draft-ietf-quic-http.txt
index 06209f84ce..13f6f357c8 100644
--- a/close3029/draft-ietf-quic-http.txt
+++ b/ianswett-limit-bursts/draft-ietf-quic-http.txt
@@ -4,8 +4,8 @@
QUIC M. Bishop, Ed.
Internet-Draft Akamai
-Intended status: Standards Track September 16, 2019
-Expires: March 19, 2020
+Intended status: Standards Track October 17, 2019
+Expires: April 19, 2020
Hypertext Transfer Protocol Version 3 (HTTP/3)
@@ -45,7 +45,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on March 19, 2020.
+ This Internet-Draft will expire on April 19, 2020.
@@ -53,9 +53,9 @@ Status of This Memo
-Bishop Expires March 19, 2020 [Page 1]
+Bishop Expires April 19, 2020 [Page 1]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
Copyright Notice
@@ -109,13 +109,13 @@ Table of Contents
-Bishop Expires March 19, 2020 [Page 2]
+Bishop Expires April 19, 2020 [Page 2]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 24
- 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 24
+ 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 25
7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 25
7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 26
@@ -123,72 +123,72 @@ Internet-Draft HTTP/3 September 2019
7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 27
7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 30
7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 31
- 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 31
- 7.2.8. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 32
- 7.2.9. Reserved Frame Types . . . . . . . . . . . . . . . . 33
- 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33
+ 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 32
+ 7.2.8. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 33
+ 7.2.9. Reserved Frame Types . . . . . . . . . . . . . . . . 34
+ 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 34
- 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 35
+ 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 36
- 10.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 36
- 10.2. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 36
- 10.3. Early Data . . . . . . . . . . . . . . . . . . . . . . . 36
+ 10.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 37
+ 10.2. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 37
+ 10.3. Early Data . . . . . . . . . . . . . . . . . . . . . . . 37
10.4. Migration . . . . . . . . . . . . . . . . . . . . . . . 37
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
11.1. Registration of HTTP/3 Identification String . . . . . . 37
- 11.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 37
- 11.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 37
+ 11.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 38
+ 11.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 38
11.4. Settings Parameters . . . . . . . . . . . . . . . . . . 39
11.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 40
11.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 42
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . 43
- 12.2. Informative References . . . . . . . . . . . . . . . . . 44
+ 12.2. Informative References . . . . . . . . . . . . . . . . . 45
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
- Appendix A. Considerations for Transitioning from HTTP/2 . . . . 45
- A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 45
- A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 45
- A.2.1. Prioritization Differences . . . . . . . . . . . . . 46
- A.2.2. Header Compression Differences . . . . . . . . . . . 46
+ Appendix A. Considerations for Transitioning from HTTP/2 . . . . 46
+ A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 46
+ A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 46
+ A.2.1. Prioritization Differences . . . . . . . . . . . . . 47
+ A.2.2. Header Compression Differences . . . . . . . . . . . 47
A.2.3. Guidance for New Frame Type Definitions . . . . . . . 47
- A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 47
- A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 48
- A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 49
- Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50
- B.1. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 50
- B.2. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 51
- B.3. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 51
- B.4. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 52
- B.5. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 52
+ A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 48
+ A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 49
+ A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 50
+ Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 51
+ B.1. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 51
+ B.2. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 52
+ B.3. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 52
+ B.4. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 53
+ B.5. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 53
B.6. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 53
B.7. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 53
-Bishop Expires March 19, 2020 [Page 3]
+Bishop Expires April 19, 2020 [Page 3]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
- B.8. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 53
- B.9. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 53
+ B.8. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 54
+ B.9. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 54
B.10. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 54
- B.11. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 54
- B.12. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 54
- B.13. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 54
- B.14. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 54
+ B.11. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 55
+ B.12. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 55
+ B.13. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 55
+ B.14. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 55
B.15. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 55
B.16. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 55
- B.17. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 55
- B.18. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 55
- B.19. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 55
+ B.17. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 56
+ B.18. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 56
+ B.19. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 56
B.20. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 56
B.21. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 56
B.22. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 56
- B.23. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 56
+ B.23. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 57
B.24. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction
@@ -221,9 +221,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 4]
+Bishop Expires April 19, 2020 [Page 4]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
1.2. Delegation to QUIC
@@ -277,9 +277,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 5]
+Bishop Expires April 19, 2020 [Page 5]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
As in HTTP/2, request and response headers are compressed for
@@ -333,9 +333,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 6]
+Bishop Expires April 19, 2020 [Page 6]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
14 [RFC2119] [RFC8174] when, and only when, they appear in all
@@ -389,9 +389,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 7]
+Bishop Expires April 19, 2020 [Page 7]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
stream error: An error on the individual HTTP/3 stream.
@@ -445,9 +445,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 8]
+Bishop Expires April 19, 2020 [Page 8]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
port and, if successful, send HTTP requests using the mapping
@@ -468,10 +468,10 @@ Internet-Draft HTTP/3 September 2019
versions are four-byte sequences with no additional constraints on
format. Leading zeros SHOULD be omitted for brevity.
- Syntax:
+ Syntax of the "quic" parameter value:
- quic = DQUOTE version-number [ "," version-number ] * DQUOTE
- version-number = 1*8HEXDIG; hex-encoded QUIC version
+ quic = DQUOTE quic-version *( "," quic-version ) DQUOTE
+ quic-version = 1*8HEXDIG ; hex-encoded QUIC version
Where multiple versions are listed, the order of the values reflects
the server's preference (with the first value being the most
@@ -501,9 +501,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 9]
+Bishop Expires April 19, 2020 [Page 9]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
3.3. Connection Establishment
@@ -557,9 +557,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 10]
+Bishop Expires April 19, 2020 [Page 10]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
The considerations discussed in Section 9.1 of [HTTP2] also apply to
@@ -613,9 +613,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 11]
+Bishop Expires April 19, 2020 [Page 11]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
If an endpoint receives an invalid sequence of frames on either a
@@ -669,9 +669,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 12]
+Bishop Expires April 19, 2020 [Page 12]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with
@@ -680,8 +680,10 @@ Internet-Draft HTTP/3 September 2019
header fields are defined in Section 8.1.2.3 and 8.1.2.4 of [HTTP2].
Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT
generate pseudo-header fields other than those defined in [HTTP2].
- The restrictions on the use of pseudo-header fields in
- Section 8.1.2.1 of [HTTP2] also apply to HTTP/3.
+ The restrictions on the use of pseudo-header fields in Section 8.1.2
+ of [HTTP2] also apply to HTTP/3. Messages which are considered
+ malformed under these restrictions are handled as described in
+ Section 4.1.3.
HTTP/3 uses QPACK header compression as described in [QPACK], a
variation of HPACK which allows the flexibility to avoid header-
@@ -719,17 +721,18 @@ Internet-Draft HTTP/3 September 2019
stream with an error code of HTTP_REQUEST_CANCELLED (Section 8.1).
When the client aborts reading a response, it indicates that this
response is no longer of interest. Implementations SHOULD cancel
- requests by abruptly terminating any directions of a stream that are
- still open.
-Bishop Expires March 19, 2020 [Page 13]
+Bishop Expires April 19, 2020 [Page 13]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
+ requests by abruptly terminating any directions of a stream that are
+ still open.
+
When the server rejects a request without performing any application
processing, it SHOULD abort its response stream with the error code
HTTP_REQUEST_REJECTED. In this context, "processed" means that some
@@ -774,18 +777,18 @@ Internet-Draft HTTP/3 September 2019
Intermediaries that process HTTP requests or responses (i.e., any
intermediary not acting as a tunnel) MUST NOT forward a malformed
request or response. Malformed requests or responses that are
- detected MUST be treated as a stream error (Section 8) of type
- HTTP_GENERAL_PROTOCOL_ERROR.
-
-Bishop Expires March 19, 2020 [Page 14]
+Bishop Expires April 19, 2020 [Page 14]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
+ detected MUST be treated as a stream error (Section 8) of type
+ HTTP_GENERAL_PROTOCOL_ERROR.
+
For malformed requests, a server MAY send an HTTP response prior to
closing or resetting the stream. Clients MUST NOT accept a malformed
response. Note that these requirements are intended to protect
@@ -831,17 +834,17 @@ Internet-Draft HTTP/3 September 2019
The TCP connection can be closed by either peer. When the client
ends the request stream (that is, the receive stream at the proxy
enters the "Data Recvd" state), the proxy will set the FIN bit on its
- connection to the TCP server. When the proxy receives a packet with
- the FIN bit set, it will terminate the send stream that it sends to
- the client. TCP connections which remain half-closed in a single
-Bishop Expires March 19, 2020 [Page 15]
+Bishop Expires April 19, 2020 [Page 15]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
+ connection to the TCP server. When the proxy receives a packet with
+ the FIN bit set, it will terminate the send stream that it sends to
+ the client. TCP connections which remain half-closed in a single
direction are not invalid, but are often handled poorly by servers,
so clients SHOULD NOT close a stream for sending while they still
expect to receive data from the target of the CONNECT.
@@ -887,16 +890,16 @@ Internet-Draft HTTP/3 September 2019
The header of the request message is carried by a PUSH_PROMISE frame
(see Section 7.2.5) on the request stream which generated the push.
This allows the server push to be associated with a client request.
- Promised requests MUST conform to the requirements in Section 8.2 of
- [HTTP2].
-
-Bishop Expires March 19, 2020 [Page 16]
+Bishop Expires April 19, 2020 [Page 16]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
+
+ Promised requests MUST conform to the requirements in Section 8.2 of
+ [HTTP2].
The same server push can be associated with additional client
requests using a DUPLICATE_PUSH frame (see Section 7.2.8).
@@ -946,12 +949,9 @@ Internet-Draft HTTP/3 September 2019
-
-
-
-Bishop Expires March 19, 2020 [Page 17]
+Bishop Expires April 19, 2020 [Page 17]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
5.1. Idle Connections
@@ -1005,9 +1005,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 18]
+Bishop Expires April 19, 2020 [Page 18]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
server explicitly reject such requests (see Section 4.1.2) in order
@@ -1061,9 +1061,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 19]
+Bishop Expires April 19, 2020 [Page 19]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
Before closing the connection, a GOAWAY MAY be sent to allow the
@@ -1117,9 +1117,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 20]
+Bishop Expires April 19, 2020 [Page 20]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
HTTP/3 does not use server-initiated bidirectional streams, though an
@@ -1146,8 +1146,9 @@ Internet-Draft HTTP/3 September 2019
Some stream types are reserved (Section 6.2.3). Two stream types are
defined in this document: control streams (Section 6.2.1) and push
- streams (Section 6.2.2). Other stream types can be defined by
- extensions to HTTP/3; see Section 9 for more details.
+ streams (Section 6.2.2). [QPACK] defines two additional stream
+ types. Other stream types can be defined by extensions to HTTP/3;
+ see Section 9 for more details.
The performance of HTTP/3 connections in the early phase of their
lifetime is sensitive to the creation and exchange of data on
@@ -1169,15 +1170,15 @@ Internet-Draft HTTP/3 September 2019
create more unidirectional streams if its peer consumes all the
initial credits before creating the critical unidirectional streams.
Endpoints SHOULD create the HTTP control stream as well as the
- unidirectional streams required by mandatory extensions (such as the
-Bishop Expires March 19, 2020 [Page 21]
+Bishop Expires April 19, 2020 [Page 21]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
+ unidirectional streams required by mandatory extensions (such as the
QPACK encoder and decoder streams) first, and then create additional
streams as allowed by their peer.
@@ -1228,10 +1229,9 @@ Internet-Draft HTTP/3 September 2019
-
-Bishop Expires March 19, 2020 [Page 22]
+Bishop Expires April 19, 2020 [Page 22]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
6.2.2. Push Streams
@@ -1285,9 +1285,9 @@ Internet-Draft HTTP/3 September 2019
-Bishop Expires March 19, 2020 [Page 23]
+Bishop Expires April 19, 2020 [Page 23]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
7. HTTP Framing Layer
@@ -1299,28 +1299,37 @@ Internet-Draft HTTP/3 September 2019
overview. A comparison between HTTP/2 and HTTP/3 frames is provided
in Appendix A.2.
- +----------------+---------+----------+---------+-------------------+
- | Frame | Control | Request | Push | Section |
- | | Stream | Stream | Stream | |
- +----------------+---------+----------+---------+-------------------+
- | DATA | No | Yes | Yes | Section 7.2.1 |
- | | | | | |
- | HEADERS | No | Yes | Yes | Section 7.2.2 |
- | | | | | |
- | CANCEL_PUSH | Yes | No | No | Section 7.2.3 |
- | | | | | |
- | SETTINGS | Yes (1) | No | No | Section 7.2.4 |
- | | | | | |
- | PUSH_PROMISE | No | Yes | No | Section 7.2.5 |
- | | | | | |
- | GOAWAY | Yes | No | No | Section 7.2.6 |
- | | | | | |
- | MAX_PUSH_ID | Yes | No | No | Section 7.2.7 |
- | | | | | |
- | DUPLICATE_PUSH | No | Yes | No | Section 7.2.8 |
- | | | | | |
- | Reserved | Yes | Yes | Yes | {{frame-reserved} |
- +----------------+---------+----------+---------+-------------------+
+ +----------------+------------+------------+-----------+------------+
+ | Frame | Control | Request | Push | Section |
+ | | Stream | Stream | Stream | |
+ +----------------+------------+------------+-----------+------------+
+ | DATA | No | Yes | Yes | Section 7. |
+ | | | | | 2.1 |
+ | | | | | |
+ | HEADERS | No | Yes | Yes | Section 7. |
+ | | | | | 2.2 |
+ | | | | | |
+ | CANCEL_PUSH | Yes | No | No | Section 7. |
+ | | | | | 2.3 |
+ | | | | | |
+ | SETTINGS | Yes (1) | No | No | Section 7. |
+ | | | | | 2.4 |
+ | | | | | |
+ | PUSH_PROMISE | No | Yes | No | Section 7. |
+ | | | | | 2.5 |
+ | | | | | |
+ | GOAWAY | Yes | No | No | Section 7. |
+ | | | | | 2.6 |
+ | | | | | |
+ | MAX_PUSH_ID | Yes | No | No | Section 7. |
+ | | | | | 2.7 |
+ | | | | | |
+ | DUPLICATE_PUSH | No | Yes | No | Section 7. |
+ | | | | | 2.8 |
+ | | | | | |
+ | Reserved | Yes | Yes | Yes | Section 7. |
+ | | | | | 2.9 |
+ +----------------+------------+------------+-----------+------------+
Table 1: HTTP/3 frames and stream type overview
@@ -1328,23 +1337,21 @@ Internet-Draft HTTP/3 September 2019
stream type; these are indicated in Table 1 with a (1). Specific
guidance is provided in the relevant section.
- Note that, unlike QUIC frames, HTTP/3 frames can span multiple
- packets.
-
-7.1. Frame Layout
-
- All frames have the following format:
+Bishop Expires April 19, 2020 [Page 24]
+
+Internet-Draft HTTP/3 October 2019
+ Note that, unlike QUIC frames, HTTP/3 frames can span multiple
+ packets.
-Bishop Expires March 19, 2020 [Page 24]
-
-Internet-Draft HTTP/3 September 2019
+7.1. Frame Layout
+ All frames have the following format:
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
@@ -1386,21 +1393,19 @@ Internet-Draft HTTP/3 September 2019
DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with an HTTP request or response payload.
- DATA frames MUST be associated with an HTTP request or response. If
- a DATA frame is received on a control stream, the recipient MUST
- respond with a connection error (Section 8) of type
- HTTP_FRAME_UNEXPECTED.
-
-
-
-Bishop Expires March 19, 2020 [Page 25]
+Bishop Expires April 19, 2020 [Page 25]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
+
+ DATA frames MUST be associated with an HTTP request or response. If
+ a DATA frame is received on a control stream, the recipient MUST
+ respond with a connection error (Section 8) of type
+ HTTP_FRAME_UNEXPECTED.
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
@@ -1435,28 +1440,37 @@ Internet-Draft HTTP/3 September 2019
frame identifies a server push by Push ID (see Section 7.2.5),
encoded as a variable-length integer.
- When a server receives this frame, it aborts sending the response for
- the identified server push. If the server has not yet started to
- send the server push, it can use the receipt of a CANCEL_PUSH frame
- to avoid opening a push stream. If the push stream has been opened
- by the server, the server SHOULD abruptly terminate that stream.
+ When a client sends CANCEL_PUSH, it is indicating that it does not
+ wish to receive the promised resource. The server SHOULD abort
+ sending the resource, but the mechanism to do so depends on the state
+ of the corresponding push stream. If the server has not yet created
+ a push stream, it does not create one. If the push stream is open,
+ the server SHOULD abruptly terminate that stream. If the push stream
+ has already ended, the server MAY still abruptly terminate the stream
+ or MAY take no action.
- A server can send the CANCEL_PUSH frame to indicate that it will not
- be fulfilling a promise prior to creation of a push stream. Once the
- push stream has been created, sending CANCEL_PUSH has no effect on
- the state of the push stream. The server SHOULD abruptly terminate
- the push stream instead.
- A CANCEL_PUSH frame is sent on the control stream. Receiving a
- CANCEL_PUSH frame on a stream other than the control stream MUST be
- treated as a connection error of type HTTP_FRAME_UNEXPECTED.
-Bishop Expires March 19, 2020 [Page 26]
+Bishop Expires April 19, 2020 [Page 26]
-Internet-Draft HTTP/3 September 2019
+Internet-Draft HTTP/3 October 2019
+
+ When a server sends CANCEL_PUSH, it is indicating that it will not be
+ fulfilling a promise and has not created a push stream. The client
+ should not expect the corresponding promise to be fulfilled.
+
+ Sending CANCEL_PUSH has no direct effect on the state of existing
+ push streams. A server SHOULD NOT send a CANCEL_PUSH when it has
+ already created a corresponding push stream, and a client SHOULD NOT
+ send a CANCEL_PUSH when it has already received a corresponding push
+ stream.
+
+ A CANCEL_PUSH frame is sent on the control stream. Receiving a
+ CANCEL_PUSH frame on a stream other than the control stream MUST be
+ treated as a connection error of type HTTP_FRAME_UNEXPECTED.
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
@@ -1468,10 +1482,16 @@ Internet-Draft HTTP/3 September 2019
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length
integer. The Push ID identifies the server push that is being
- cancelled (see Section 7.2.5).
+ cancelled (see Section 7.2.5). If a CANCEL_PUSH frame is received
+ which references a Push ID greater than currently allowed on the
+ connection, this MUST be treated as a connection error of type
+ HTTP_ID_ERROR.
If the client receives a CANCEL_PUSH frame, that frame might identify
- a Push ID that has not yet been mentioned by a PUSH_PROMISE frame.
+ a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due
+ to reordering. If a server receives a CANCEL_PUSH frame for a Push
+ ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST
+ be treated as a connection error of type HTTP_ID_ERROR.
7.2.4. SETTINGS
@@ -1486,6 +1506,14 @@ Internet-Draft HTTP/3 September 2019
A SETTINGS frame MUST be sent as the first frame of each control
stream (see Section 6.2.1) by each peer, and MUST NOT be sent
subsequently. If an endpoint receives a second SETTINGS frame on the
+
+
+
+Bishop Expires April 19, 2020 [Page 27]
+
+Internet-Draft HTTP/3 October 2019
+
+
control stream, the endpoint MUST respond with a connection error of
type HTTP_FRAME_UNEXPECTED.
@@ -1506,14 +1534,6 @@ Internet-Draft HTTP/3 September 2019
peer. For example, a client might be willing to consume a very large
response header, while servers are more cautious about request size.
-
-
-
-Bishop Expires March 19, 2020 [Page 27]
-
-Internet-Draft HTTP/3 September 2019
-
-
The same setting identifier MUST NOT occur more than once in the
SETTINGS frame. A receiver MAY treat the presence of duplicate
setting identifiers as a connection error of type
@@ -1543,6 +1563,13 @@ Internet-Draft HTTP/3 September 2019
SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited.
See Section 4.1.1 for usage.
+
+
+Bishop Expires April 19, 2020 [Page 28]
+
+Internet-Draft HTTP/3 October 2019
+
+
Setting identifiers of the format "0x1f * N + 0x21" for integer
values of N are reserved to exercise the requirement that unknown
identifiers be ignored. Such settings have no defined meaning.
@@ -1561,15 +1588,6 @@ Internet-Draft HTTP/3 September 2019
An HTTP implementation MUST NOT send frames or requests which would
be invalid based on its current understanding of the peer's settings.
-
-
-
-
-Bishop Expires March 19, 2020 [Page 28]
-
-Internet-Draft HTTP/3 September 2019
-
-
All settings begin at an initial value. Each endpoint SHOULD use
these initial values to send messages before the peer's SETTINGS
frame has arrived, as packets carrying the settings can be lost or
@@ -1599,6 +1617,15 @@ Internet-Draft HTTP/3 September 2019
settings in certain cases (e.g., if the session ticket is received
before the SETTINGS frame). A client MUST comply with stored
settings - or default values, if no values are stored - when
+
+
+
+
+Bishop Expires April 19, 2020 [Page 29]
+
+Internet-Draft HTTP/3 October 2019
+
+
attempting 0-RTT. Once a server has provided new settings, clients
MUST comply with those values.
@@ -1618,14 +1645,6 @@ Internet-Draft HTTP/3 September 2019
include all settings which differ from their default values. If a
server accepts 0-RTT, but then sends a SETTINGS frame which reduces a
setting the client understands or omits a value that was previously
-
-
-
-Bishop Expires March 19, 2020 [Page 29]
-
-Internet-Draft HTTP/3 September 2019
-
-
specified to have a non-default value, this MUST be treated as a
connection error of type HTTP_SETTINGS_ERROR.
@@ -1654,6 +1673,15 @@ Internet-Draft HTTP/3 September 2019
Header Block: QPACK-compressed request header fields for the
promised response. See [QPACK] for more details.
+
+
+
+
+Bishop Expires April 19, 2020 [Page 30]
+
+Internet-Draft HTTP/3 October 2019
+
+
A server MUST NOT use a Push ID that is larger than the client has
provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat
receipt of a PUSH_PROMISE frame that contains a larger Push ID than
@@ -1674,14 +1702,6 @@ Internet-Draft HTTP/3 September 2019
See Section 4.4 for a description of the overall server push
mechanism.
-
-
-
-Bishop Expires March 19, 2020 [Page 30]
-
-Internet-Draft HTTP/3 September 2019
-
-
7.2.6. GOAWAY
The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of
@@ -1709,6 +1729,15 @@ Internet-Draft HTTP/3 September 2019
a GOAWAY frame on any stream as a connection error (Section 8) of
type HTTP_FRAME_UNEXPECTED.
+
+
+
+
+Bishop Expires April 19, 2020 [Page 31]
+
+Internet-Draft HTTP/3 October 2019
+
+
The GOAWAY frame applies to the connection, not a specific stream. A
client MUST treat a GOAWAY frame on a stream other than the control
stream as a connection error (Section 8) of type
@@ -1720,24 +1749,15 @@ Internet-Draft HTTP/3 September 2019
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
number of server pushes that the server can initiate. This sets the
- maximum value for a Push ID that the server can use in a PUSH_PROMISE
- frame. Consequently, this also limits the number of push streams
- that the server can initiate in addition to the limit maintained by
- the QUIC transport.
+ maximum value for a Push ID that the server can use in PUSH_PROMISE
+ and CANCEL_PUSH frames. Consequently, this also limits the number of
+ push streams that the server can initiate in addition to the limit
+ maintained by the QUIC transport.
The MAX_PUSH_ID frame is always sent on the control stream. Receipt
of a MAX_PUSH_ID frame on any other stream MUST be treated as a
connection error of type HTTP_FRAME_UNEXPECTED.
-
-
-
-
-Bishop Expires March 19, 2020 [Page 31]
-
-Internet-Draft HTTP/3 September 2019
-
-
A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the
receipt of a MAX_PUSH_ID frame as a connection error of type
HTTP_FRAME_UNEXPECTED.
@@ -1763,6 +1783,17 @@ Internet-Draft HTTP/3 September 2019
previously received MUST be treated as a connection error of type
HTTP_ID_ERROR.
+
+
+
+
+
+
+Bishop Expires April 19, 2020 [Page 32]
+
+Internet-Draft HTTP/3 October 2019
+
+
7.2.8. DUPLICATE_PUSH
The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate
@@ -1785,15 +1816,6 @@ Internet-Draft HTTP/3 September 2019
Figure 11: DUPLICATE_PUSH frame payload
-
-
-
-
-Bishop Expires March 19, 2020 [Page 32]
-
-Internet-Draft HTTP/3 September 2019
-
-
The DUPLICATE_PUSH frame carries a single variable-length integer
that identifies the Push ID of a resource that the server has
previously promised (see Section 7.2.5), though that promise might
@@ -1817,6 +1839,17 @@ Internet-Draft HTTP/3 September 2019
they have since consumed and discarded are forced to ignore the
DUPLICATE_PUSH.
+
+
+
+
+
+
+Bishop Expires April 19, 2020 [Page 33]
+
+Internet-Draft HTTP/3 October 2019
+
+
7.2.9. Reserved Frame Types
Frame types of the format "0x1f * N + 0x21" for integer values of N
@@ -1833,7 +1866,7 @@ Internet-Draft HTTP/3 September 2019
Frame types which were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (Section 11.3). These frame
types MUST NOT be sent, and receipt MAY be treated as an error of
- type HTTP_UNEXPECTED_FRAME.
+ type HTTP_FRAME_UNEXPECTED.
8. Error Handling
@@ -1843,13 +1876,6 @@ Internet-Draft HTTP/3 September 2019
described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose
to treat a stream error as a connection error.
-
-
-Bishop Expires March 19, 2020 [Page 33]
-
-Internet-Draft HTTP/3 September 2019
-
-
Because new error codes can be defined without negotiation (see
Section 9), receipt of an unknown error code or use of an error code
in an unexpected context MUST NOT be treated as an error. However,
@@ -1872,6 +1898,14 @@ Internet-Draft HTTP/3 September 2019
requirements in a way which doesn't match a more specific error
code, or endpoint declines to use the more specific error code.
+
+
+
+Bishop Expires April 19, 2020 [Page 34]
+
+Internet-Draft HTTP/3 October 2019
+
+
HTTP_INTERNAL_ERROR (0x102): An internal error has occurred in the
HTTP stack.
@@ -1899,13 +1933,6 @@ Internet-Draft HTTP/3 September 2019
HTTP_MISSING_SETTINGS (0x10A): No SETTINGS frame was received at the
beginning of the control stream.
-
-
-Bishop Expires March 19, 2020 [Page 34]
-
-Internet-Draft HTTP/3 September 2019
-
-
HTTP_REQUEST_REJECTED (0x10B): A server rejected a request without
performing any application processing.
@@ -1925,6 +1952,16 @@ Internet-Draft HTTP/3 September 2019
HTTP_VERSION_FALLBACK (0x110): The requested operation cannot be
served over HTTP/3. The peer should retry over HTTP/1.1.
+
+
+
+
+
+Bishop Expires April 19, 2020 [Page 35]
+
+Internet-Draft HTTP/3 October 2019
+
+
9. Extensions to HTTP/3
HTTP/3 permits extension of the protocol. Within the limitations
@@ -1953,15 +1990,6 @@ Internet-Draft HTTP/3 September 2019
Section 6.2.1), an unknown frame type does not satisfy that
requirement and SHOULD be treated as an error.
-
-
-
-
-Bishop Expires March 19, 2020 [Page 35]
-
-Internet-Draft HTTP/3 September 2019
-
-
Extensions that could change the semantics of existing protocol
components MUST be negotiated before being used. For example, an
extension that changes the layout of the HEADERS frame cannot be used
@@ -1983,6 +2011,13 @@ Internet-Draft HTTP/3 September 2019
of HTTP/2 with TLS; the considerations from Section 10 of [HTTP2]
apply in addition to those listed here.
+
+
+Bishop Expires April 19, 2020 [Page 36]
+
+Internet-Draft HTTP/3 October 2019
+
+
When HTTP Alternative Services is used for discovery for HTTP/3
endpoints, the security considerations of [ALTSVC] also apply.
@@ -2010,14 +2045,6 @@ Internet-Draft HTTP/3 September 2019
The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when
using HTTP/3 with 0-RTT.
-
-
-
-Bishop Expires March 19, 2020 [Page 36]
-
-Internet-Draft HTTP/3 September 2019
-
-
10.4. Migration
Certain HTTP implementations use the client address for logging or
@@ -2040,6 +2067,13 @@ Internet-Draft HTTP/3 September 2019
Protocol: HTTP/3
+
+
+Bishop Expires April 19, 2020 [Page 37]
+
+Internet-Draft HTTP/3 October 2019
+
+
Identification Sequence: 0x68 0x33 ("h3")
Specification: This document
@@ -2066,14 +2100,6 @@ Internet-Draft HTTP/3 September 2019
While this registry is separate from the "HTTP/2 Frame Type" registry
defined in [HTTP2], it is preferable that the assignments parallel
-
-
-
-Bishop Expires March 19, 2020 [Page 37]
-
-Internet-Draft HTTP/3 September 2019
-
-
each other where the code spaces overlap. If an entry is present in
only one registry, every effort SHOULD be made to avoid assigning the
corresponding value to an unrelated operation.
@@ -2090,6 +2116,20 @@ Internet-Draft HTTP/3 September 2019
The entries in the following table are registered by this document.
+
+
+
+
+
+
+
+
+
+Bishop Expires April 19, 2020 [Page 38]
+
+Internet-Draft HTTP/3 October 2019
+
+
+----------------+------+---------------+
| Frame Type | Code | Specification |
+----------------+------+---------------+
@@ -2122,14 +2162,6 @@ Internet-Draft HTTP/3 September 2019
values of N (that is, "0x21", "0x40", ..., through
"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
-
-
-
-Bishop Expires March 19, 2020 [Page 38]
-
-Internet-Draft HTTP/3 September 2019
-
-
11.4. Settings Parameters
This document establishes a registry for HTTP/3 settings. The
@@ -2145,6 +2177,15 @@ Internet-Draft HTTP/3 September 2019
While this registry is separate from the "HTTP/2 Settings" registry
defined in [HTTP2], it is preferable that the assignments parallel
each other. If an entry is present in only one registry, every
+
+
+
+
+Bishop Expires April 19, 2020 [Page 39]
+
+Internet-Draft HTTP/3 October 2019
+
+
effort SHOULD be made to avoid assigning the corresponding value to
an unrelated operation.
@@ -2177,15 +2218,6 @@ Internet-Draft HTTP/3 September 2019
| MAX_HEADER_LIST_SIZE | 0x6 | Section 7.2.4.1 | Unlimited |
+----------------------+------+-----------------+-----------+
-
-
-
-
-Bishop Expires March 19, 2020 [Page 39]
-
-Internet-Draft HTTP/3 September 2019
-
-
Additionally, each code of the format "0x1f * N + 0x21" for integer
values of N (that is, "0x21", "0x40", ..., through
"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
@@ -2202,6 +2234,14 @@ Internet-Draft HTTP/3 September 2019
registrations for possible duplication with existing error codes.
Use of existing registrations is to be encouraged, but not mandated.
+
+
+
+Bishop Expires April 19, 2020 [Page 40]
+
+Internet-Draft HTTP/3 October 2019
+
+
New registrations are advised to provide the following information:
Name: A name for the error code. Specifying an error code name is
@@ -2234,14 +2274,6 @@ Internet-Draft HTTP/3 September 2019
| | | error | |
| | | | |
| HTTP_CLOSED_CRITICAL_STREA | 0x0104 | Critical | Section 8.1 |
-
-
-
-Bishop Expires March 19, 2020 [Page 40]
-
-Internet-Draft HTTP/3 September 2019
-
-
| M | | stream was | |
| | | closed | |
| | | | |
@@ -2258,6 +2290,14 @@ Internet-Draft HTTP/3 September 2019
| | | | |
| HTTP_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 |
| | | generating | |
+
+
+
+Bishop Expires April 19, 2020 [Page 41]
+
+Internet-Draft HTTP/3 October 2019
+
+
| | | excessive | |
| | | load | |
| | | | |
@@ -2290,14 +2330,6 @@ Internet-Draft HTTP/3 September 2019
| HTTP_EARLY_RESPONSE | 0x010E | Remainder | Section 8.1 |
| | | of request | |
| | | not needed | |
-
-
-
-Bishop Expires March 19, 2020 [Page 41]
-
-Internet-Draft HTTP/3 September 2019
-
-
| | | | |
| HTTP_CONNECT_ERROR | 0x010F | TCP reset | Section 8.1 |
| | | or error on | |
@@ -2314,6 +2346,14 @@ Internet-Draft HTTP/3 September 2019
types. The "HTTP/3 Stream Type" registry governs a 62-bit space.
This space is split into three spaces that are governed by different
policies. Values between "0x00" and 0x3f (in hexadecimal) are
+
+
+
+Bishop Expires April 19, 2020 [Page 42]
+
+Internet-Draft HTTP/3 October 2019
+
+
assigned via the Standards Action or IESG Review policies [RFC8126].
Values from "0x40" to "0x3fff" operate on the Specification Required
policy [RFC8126]. All other values are assigned to Private Use
@@ -2346,14 +2386,6 @@ Internet-Draft HTTP/3 September 2019
values of N (that is, "0x21", "0x40", ..., through
"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
-
-
-
-Bishop Expires March 19, 2020 [Page 42]
-
-Internet-Draft HTTP/3 September 2019
-
-
12. References
12.1. Normative References
@@ -2367,6 +2399,17 @@ Internet-Draft HTTP/3 September 2019
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, .
+
+
+
+
+
+
+Bishop Expires April 19, 2020 [Page 43]
+
+Internet-Draft HTTP/3 October 2019
+
+
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
@@ -2374,12 +2417,12 @@ Internet-Draft HTTP/3 September 2019
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Header Compression for HTTP over QUIC", draft-ietf-quic-
- qpack (work in progress), September 2019.
+ qpack (work in progress), October 2019.
[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic-
- transport (work in progress), September 2019.
+ transport (work in progress), October 2019.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
@@ -2400,16 +2443,6 @@ Internet-Draft HTTP/3 September 2019
DOI 10.17487/RFC6066, January 2011,
.
-
-
-
-
-
-Bishop Expires March 19, 2020 [Page 43]
-
-Internet-Draft HTTP/3 September 2019
-
-
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
.
@@ -2424,6 +2457,15 @@ Internet-Draft HTTP/3 September 2019
DOI 10.17487/RFC7231, June 2014,
.
+
+
+
+
+Bishop Expires April 19, 2020 [Page 44]
+
+Internet-Draft HTTP/3 October 2019
+
+
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, .
@@ -2456,16 +2498,6 @@ Internet-Draft HTTP/3 September 2019
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, .
-
-
-
-
-
-Bishop Expires March 19, 2020 [Page 44]
-
-Internet-Draft HTTP/3 September 2019
-
-
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
.
@@ -2480,6 +2512,16 @@ Internet-Draft HTTP/3 September 2019
[4] https://www.iana.org/assignments/message-headers
+
+
+
+
+
+Bishop Expires April 19, 2020 [Page 45]
+
+Internet-Draft HTTP/3 October 2019
+
+
Appendix A. Considerations for Transitioning from HTTP/2
HTTP/3 is strongly informed by HTTP/2, and bears many similarities.
@@ -2514,14 +2556,6 @@ A.2. HTTP Frame Types
multiplexing (QUIC's multiplexing occurs below this layer), the
support for variable-maximum-length packets can be removed. Because
stream termination is handled by QUIC, an END_STREAM flag is not
-
-
-
-Bishop Expires March 19, 2020 [Page 45]
-
-Internet-Draft HTTP/3 September 2019
-
-
required. This permits the removal of the Flags field from the
generic frame layout.
@@ -2536,6 +2570,14 @@ Internet-Draft HTTP/3 September 2019
Many of the differences arise from the fact that HTTP/2 provides an
absolute ordering between frames across all streams, while QUIC
+
+
+
+Bishop Expires April 19, 2020 [Page 46]
+
+Internet-Draft HTTP/3 October 2019
+
+
provides this guarantee on each stream only. As a result, if a frame
type makes assumptions that frames from different streams will still
be received in the order sent, HTTP/3 will break them.
@@ -2570,14 +2612,6 @@ A.2.2. Header Compression Differences
[QPACK] provides additional details.
-
-
-
-Bishop Expires March 19, 2020 [Page 46]
-
-Internet-Draft HTTP/3 September 2019
-
-
A.2.3. Guidance for New Frame Type Definitions
Frame type definitions in HTTP/3 often use the QUIC variable-length
@@ -2592,6 +2626,14 @@ A.2.3. Guidance for New Frame Type Definitions
those frames which depend on the presence of flags need to allocate
space for flags as part of their frame payload.
+
+
+
+Bishop Expires April 19, 2020 [Page 47]
+
+Internet-Draft HTTP/3 October 2019
+
+
Other than this issue, frame type HTTP/2 extensions are typically
portable to QUIC simply by replacing Stream 0 in HTTP/2 with a
control stream in HTTP/3. HTTP/3 extensions will not assume
@@ -2627,13 +2669,6 @@ A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types
GOAWAY (0x7): GOAWAY is sent only from server to client and does not
contain an error code. See Section 7.2.6.
-
-
-Bishop Expires March 19, 2020 [Page 47]
-
-Internet-Draft HTTP/3 September 2019
-
-
WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC
provides flow control.
@@ -2647,6 +2682,14 @@ Internet-Draft HTTP/3 September 2019
so many HTTP/3 frame types have no equivalent HTTP/2 code points.
See Section 11.3.
+
+
+
+Bishop Expires April 19, 2020 [Page 48]
+
+Internet-Draft HTTP/3 October 2019
+
+
A.3. HTTP/2 SETTINGS Parameters
An important difference from HTTP/2 is that settings are sent once,
@@ -2682,14 +2725,6 @@ A.3. HTTP/2 SETTINGS Parameters
In HTTP/3, setting values are variable-length integers (6, 14, 30, or
62 bits long) rather than fixed-length 32-bit fields as in HTTP/2.
-
-
-
-Bishop Expires March 19, 2020 [Page 48]
-
-Internet-Draft HTTP/3 September 2019
-
-
This will often produce a shorter encoding, but can produce a longer
encoding for settings which use the full 32-bit space. Settings
ported from HTTP/2 might choose to redefine the format of their
@@ -2701,6 +2736,16 @@ Internet-Draft HTTP/3 September 2019
larger (62 bits versus 16 bits), so many HTTP/3 settings have no
equivalent HTTP/2 code point. See Section 11.4.
+
+
+
+
+
+Bishop Expires April 19, 2020 [Page 49]
+
+Internet-Draft HTTP/3 October 2019
+
+
As QUIC streams might arrive out-of-order, endpoints are advised to
not wait for the peers' settings to arrive before responding to other
streams. See Section 7.2.4.2.
@@ -2736,16 +2781,6 @@ A.4. HTTP/2 Error Codes
FRAME_SIZE_ERROR (0x6): HTTP_FRAME_ERROR error code defined in
Section 8.1.
-
-
-
-
-
-Bishop Expires March 19, 2020 [Page 49]
-
-Internet-Draft HTTP/3 September 2019
-
-
REFUSED_STREAM (0x7): HTTP_REQUEST_REJECTED (in Section 8.1) is used
to indicate that a request was not processed. Otherwise, not
applicable because QUIC handles stream management.
@@ -2759,6 +2794,14 @@ Internet-Draft HTTP/3 September 2019
ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1.
+
+
+
+Bishop Expires April 19, 2020 [Page 50]
+
+Internet-Draft HTTP/3 October 2019
+
+
INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to
provide sufficient security on all connections.
@@ -2794,14 +2837,6 @@ B.1. Since draft-ietf-quic-http-22
o Settings identifiers cannot be duplicated (#2979)
-
-
-
-Bishop Expires March 19, 2020 [Page 50]
-
-Internet-Draft HTTP/3 September 2019
-
-
o Changes to SETTINGS frames in 0-RTT (#2972,#2790,#2945):
* Servers must send all settings with non-default values in their
@@ -2816,6 +2851,13 @@ Internet-Draft HTTP/3 September 2019
o Clarify that Upgrade and the 101 status code are prohibited
(#2898,#2889)
+
+
+Bishop Expires April 19, 2020 [Page 51]
+
+Internet-Draft HTTP/3 October 2019
+
+
o Clarify that frame types reserved for greasing can occur on any
stream, but frame types reserved due to HTTP/2 correspondence are
prohibited (#2997,#2692,#2693)
@@ -2849,15 +2891,6 @@ B.3. Since draft-ietf-quic-http-20
o Extensive changes to error codes and conditions of their sending
-
-
-
-
-Bishop Expires March 19, 2020 [Page 51]
-
-Internet-Draft HTTP/3 September 2019
-
-
* Require connection errors for more error conditions (#2511,
#2510)
@@ -2874,6 +2907,13 @@ Internet-Draft HTTP/3 September 2019
* Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813)
+
+
+Bishop Expires April 19, 2020 [Page 52]
+
+Internet-Draft HTTP/3 October 2019
+
+
* Refactor Push ID related errors (#2818, #2820)
* Rationalize HTTP/3 stream creation errors (#2821, #2822)
@@ -2906,14 +2946,6 @@ B.5. Since draft-ietf-quic-http-18
o Use connection error for invalid PRIORITY (#2507, #2508)
-
-
-
-Bishop Expires March 19, 2020 [Page 52]
-
-Internet-Draft HTTP/3 September 2019
-
-
B.6. Since draft-ietf-quic-http-17
o HTTP_REQUEST_REJECTED is used to indicate a request can be retried
@@ -2931,6 +2963,13 @@ B.7. Since draft-ietf-quic-http-16
* Remove exclusive reprioritization
+
+
+Bishop Expires April 19, 2020 [Page 53]
+
+Internet-Draft HTTP/3 October 2019
+
+
* Changes to Prioritized Element Type bits
o Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE
@@ -2963,13 +3002,6 @@ B.9. Since draft-ietf-quic-http-14
o Expanded discussion of connection closure (#1599,#1717,#1712)
-
-
-Bishop Expires March 19, 2020 [Page 53]
-
-Internet-Draft HTTP/3 September 2019
-
-
o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685)
B.10. Since draft-ietf-quic-http-13
@@ -2984,6 +3016,16 @@ B.10. Since draft-ietf-quic-http-13
o Specify behavior for truncated requests (#1596, #1643)
+
+
+
+
+
+Bishop Expires April 19, 2020 [Page 54]
+
+Internet-Draft HTTP/3 October 2019
+
+
B.11. Since draft-ietf-quic-http-12
o TLS SNI extension isn't mandatory if an alternative method is used
@@ -3018,14 +3060,6 @@ B.14. Since draft-ietf-quic-http-09
o The server_name TLS extension is now mandatory (#296, #495)
-
-
-
-Bishop Expires March 19, 2020 [Page 54]
-
-Internet-Draft HTTP/3 September 2019
-
-
o Specified handling of unsupported versions in Alt-Svc (#1093,
#1097)
@@ -3041,6 +3075,13 @@ B.16. Since draft-ietf-quic-http-07
o Improvement to the description of GOAWAY (#604, #898)
+
+
+Bishop Expires April 19, 2020 [Page 55]
+
+Internet-Draft HTTP/3 October 2019
+
+
o Improve description of server push usage (#947, #950, #957)
B.17. Since draft-ietf-quic-http-06
@@ -3073,15 +3114,6 @@ B.19. Since draft-ietf-quic-http-04
o DATA frames cannot be empty (#700)
-
-
-
-
-Bishop Expires March 19, 2020 [Page 55]
-
-Internet-Draft HTTP/3 September 2019
-
-
B.20. Since draft-ietf-quic-http-03
None.
@@ -3099,6 +3131,13 @@ B.22. Since draft-ietf-quic-http-01
* SETTINGS_ACK removed
+
+
+Bishop Expires April 19, 2020 [Page 56]
+
+Internet-Draft HTTP/3 October 2019
+
+
* Settings can only occur in the SETTINGS frame a single time
* Boolean format updated
@@ -3131,13 +3170,6 @@ B.23. Since draft-ietf-quic-http-00
o Described CONNECT pseudo-method (#95)
-
-
-Bishop Expires March 19, 2020 [Page 56]
-
-Internet-Draft HTTP/3 September 2019
-
-
o Updated ALPN token and Alt-Svc guidance (#13,#87)
o Application-layer-defined error codes (#19,#74)
@@ -3153,6 +3185,15 @@ Acknowledgements
The original authors of this specification were Robbie Shade and Mike
Warres.
+
+
+
+
+Bishop Expires April 19, 2020 [Page 57]
+
+Internet-Draft HTTP/3 October 2019
+
+
A substantial portion of Mike's contribution was supported by
Microsoft during his employment there.
@@ -3189,4 +3230,19 @@ Author's Address
-Bishop Expires March 19, 2020 [Page 57]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bishop Expires April 19, 2020 [Page 58]
diff --git a/close3029/draft-ietf-quic-invariants.html b/ianswett-limit-bursts/draft-ietf-quic-invariants.html
similarity index 98%
rename from close3029/draft-ietf-quic-invariants.html
rename to ianswett-limit-bursts/draft-ietf-quic-invariants.html
index 89413e3ea6..fc3d903497 100644
--- a/close3029/draft-ietf-quic-invariants.html
+++ b/ianswett-limit-bursts/draft-ietf-quic-invariants.html
@@ -300,12 +300,12 @@
-
+
-
+
@@ -326,10 +326,10 @@
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on March 19, 2020.
+
This Internet-Draft will expire on April 19, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
diff --git a/close3029/draft-ietf-quic-invariants.txt b/ianswett-limit-bursts/draft-ietf-quic-invariants.txt
similarity index 92%
rename from close3029/draft-ietf-quic-invariants.txt
rename to ianswett-limit-bursts/draft-ietf-quic-invariants.txt
index 6c52da6ba8..cdde52392f 100644
--- a/close3029/draft-ietf-quic-invariants.txt
+++ b/ianswett-limit-bursts/draft-ietf-quic-invariants.txt
@@ -4,8 +4,8 @@
QUIC M. Thomson
Internet-Draft Mozilla
-Intended status: Standards Track September 16, 2019
-Expires: March 19, 2020
+Intended status: Standards Track October 17, 2019
+Expires: April 19, 2020
Version-Independent Properties of QUIC
@@ -42,7 +42,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on March 19, 2020.
+ This Internet-Draft will expire on April 19, 2020.
Copyright Notice
@@ -53,9 +53,9 @@ Copyright Notice
-Thomson Expires March 19, 2020 [Page 1]
+Thomson Expires April 19, 2020 [Page 1]
-Internet-Draft QUIC Invariants September 2019
+Internet-Draft QUIC Invariants October 2019
This document is subject to BCP 78 and the IETF Trust's Legal
@@ -109,9 +109,9 @@ Table of Contents
-Thomson Expires March 19, 2020 [Page 2]
+Thomson Expires April 19, 2020 [Page 2]
-Internet-Draft QUIC Invariants September 2019
+Internet-Draft QUIC Invariants October 2019
Appendix A is a non-exhaustive list of some incorrect assumptions
@@ -165,9 +165,9 @@ Internet-Draft QUIC Invariants September 2019
-Thomson Expires March 19, 2020 [Page 3]
+Thomson Expires April 19, 2020 [Page 3]
-Internet-Draft QUIC Invariants September 2019
+Internet-Draft QUIC Invariants October 2019
0 1 2 3
@@ -221,9 +221,9 @@ Internet-Draft QUIC Invariants September 2019
-Thomson Expires March 19, 2020 [Page 4]
+Thomson Expires April 19, 2020 [Page 4]
-Internet-Draft QUIC Invariants September 2019
+Internet-Draft QUIC Invariants October 2019
0 1 2 3
@@ -277,9 +277,9 @@ Internet-Draft QUIC Invariants September 2019
-Thomson Expires March 19, 2020 [Page 5]
+Thomson Expires April 19, 2020 [Page 5]
-Internet-Draft QUIC Invariants September 2019
+Internet-Draft QUIC Invariants October 2019
in this document is not QUIC. Future documents might describe
@@ -333,9 +333,9 @@ Internet-Draft QUIC Invariants September 2019
-Thomson Expires March 19, 2020 [Page 6]
+Thomson Expires April 19, 2020 [Page 6]
-Internet-Draft QUIC Invariants September 2019
+Internet-Draft QUIC Invariants October 2019
Version Negotiation packets do not use integrity or confidentiality
@@ -389,9 +389,9 @@ Internet-Draft QUIC Invariants September 2019
-Thomson Expires March 19, 2020 [Page 7]
+Thomson Expires April 19, 2020 [Page 7]
-Internet-Draft QUIC Invariants September 2019
+Internet-Draft QUIC Invariants October 2019
8. References
@@ -401,7 +401,7 @@ Internet-Draft QUIC Invariants September 2019
[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic-
- transport (work in progress), September 2019.
+ transport (work in progress), October 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
@@ -417,7 +417,7 @@ Internet-Draft QUIC Invariants September 2019
[QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls
- (work in progress), September 2019.
+ (work in progress), October 2019.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
@@ -445,9 +445,9 @@ Appendix A. Incorrect Assumptions
-Thomson Expires March 19, 2020 [Page 8]
+Thomson Expires April 19, 2020 [Page 8]
-Internet-Draft QUIC Invariants September 2019
+Internet-Draft QUIC Invariants October 2019
The following statements are NOT guaranteed to be true for every QUIC
@@ -501,9 +501,9 @@ Author's Address
-Thomson Expires March 19, 2020 [Page 9]
+Thomson Expires April 19, 2020 [Page 9]
-Internet-Draft QUIC Invariants September 2019
+Internet-Draft QUIC Invariants October 2019
Martin Thomson
@@ -557,4 +557,4 @@ Internet-Draft QUIC Invariants September 2019
-Thomson Expires March 19, 2020 [Page 10]
+Thomson Expires April 19, 2020 [Page 10]
diff --git a/close3029/draft-ietf-quic-qpack.html b/ianswett-limit-bursts/draft-ietf-quic-qpack.html
similarity index 97%
rename from close3029/draft-ietf-quic-qpack.html
rename to ianswett-limit-bursts/draft-ietf-quic-qpack.html
index e2a96e9edc..a0497412d0 100644
--- a/close3029/draft-ietf-quic-qpack.html
+++ b/ianswett-limit-bursts/draft-ietf-quic-qpack.html
@@ -352,12 +352,12 @@
-
+
-
+
@@ -381,7 +381,7 @@
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on March 19, 2020.
+
This Internet-Draft will expire on April 19, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
@@ -658,7 +658,7 @@
Because QUIC does not guarantee order between data on different streams, a decoder might encounter a header block that references a dynamic table entry that it has not yet received.
Each header block contains a Required Insert Count (see Section 4.5.1), the lowest possible value for the Insert Count with which the header block can be decoded. For a header block with references to the dynamic table, the Required Insert Count is one larger than the largest absolute index of all referenced dynamic table entries. For a header block with no references to the dynamic table, the Required Insert Count is zero.
-
When the decoder receives a header block with a Required Insert Count greater than its own Insert Count, the stream cannot be processed immediately, and is considered “blocked” (see {blocked-decoding}).
+
When the decoder receives a header block with a Required Insert Count greater than its own Insert Count, the stream cannot be processed immediately, and is considered “blocked” (see Section 2.2.1).
The decoder specifies an upper bound on the number of streams which can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting (see Section 5). An encoder MUST limit the number of streams which could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all times. If an decoder encounters more blocked streams than it promised to support, it MUST treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED.
Note that the decoder might not become blocked on every stream which risks becoming blocked.
An encoder can decide whether to risk having a stream become blocked. If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS, compression efficiency can often be improved by referencing dynamic table entries that are still in transit, but if there is loss or reordering the stream can become blocked at the decoder. An encoder avoids the risk of blocking by only referencing dynamic table entries which have been acknowledged, but this could mean using literals. Since literals make the header block larger, this can result in the encoder becoming blocked on congestion or flow control limits.
The string literal defined by Section 5.2 of [RFC7541] is also used throughout. This string format includes optional Huffman encoding.
-
HPACK defines string literals to begin on a byte boundary. They begin with a single flag (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data. When Huffman encoding is enabled, the Huffman table from Appendix B of [RFC7541] is used without modification.
+
HPACK defines string literals to begin on a byte boundary. They begin with a single bit flag, denoted as ‘H’ in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data. When Huffman encoding is enabled, the Huffman table from Appendix B of [RFC7541] is used without modification.
This document expands the definition of string literals and permits them to begin other than on a byte boundary. An “N-bit prefix string literal” begins with the same Huffman flag, followed by the length encoded as an (N-1)-bit prefix integer. The remainder of the string literal is unmodified.
A string literal without a prefix length noted is an 8-bit prefix string literal and follows the definitions in [RFC7541] without modification.
An encoder adds an entry to the dynamic table where the header field name matches the header field name of an entry stored in the static or the dynamic table using an instruction that starts with the ‘1’ one-bit pattern. The second (S) bit indicates whether the reference is to the static or dynamic table. The 6-bit prefix integer (see Section 4.1.1) that follows is used to locate the table entry for the header name. When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table.
+
An encoder adds an entry to the dynamic table where the header field name matches the header field name of an entry stored in the static or the dynamic table using an instruction that starts with the ‘1’ one-bit pattern. The second (‘T’) bit indicates whether the reference is to the static or dynamic table. The 6-bit prefix integer (see Section 4.1.1) that follows is used to locate the table entry for the header name. When T=1, the number represents the static table index; when T=0, the number is the relative index of the entry in the dynamic table.
The header name reference is followed by the header field value represented as a string literal (see Section 4.1.2).
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
- | 1 | S | Name Index (6+) |
+ | 1 | T | Name Index (6+) |
+---+---+-----------------------+
| H | Value Length (7+) |
+---+---------------------------+
@@ -953,7 +953,7 @@
Each header block is prefixed with two integers. The Required Insert Count is encoded as an integer with an 8-bit prefix after the encoding described in Section 4.5.1.1). The Base is encoded as sign-and-modulus integer, using a single sign bit and a value with a 7-bit prefix (see Section 4.5.1.2).
+
Each header block is prefixed with two integers. The Required Insert Count is encoded as an integer with an 8-bit prefix after the encoding described in Section 4.5.1.1). The Base is encoded as sign-and-modulus integer, using a single sign bit (‘S’) and a value with a 7-bit prefix (see Section 4.5.1.2).
These two values are followed by representations for compressed headers.
The Base is used to resolve references in the dynamic table as described in Section 3.2.5.
-
To save space, the Base is encoded relative to the Insert Count using a one-bit sign and the Delta Base value. A sign bit of 0 indicates that the Base is greater than or equal to the value of the Insert Count; the value of Delta Base is added to the Insert Count to determine the value of the Base. A sign bit of 1 indicates that the Base is less than the Insert Count. That is:
+
To save space, the Base is encoded relative to the Insert Count using a one-bit sign (‘S’) and the Delta Base value. A sign bit of 0 indicates that the Base is greater than or equal to the value of the Insert Count; the value of Delta Base is added to the Insert Count to determine the value of the Base. A sign bit of 1 indicates that the Base is less than the Insert Count. That is:
if S == 0:
Base = ReqInsertCount + DeltaBase
@@ -1035,11 +1035,11 @@
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
-| 1 | S | Index (6+) |
+| 1 | T | Index (6+) |
+---+---+-----------------------+
Indexed Header Field
-
If the entry is in the static table, or in the dynamic table with an absolute index less than the Base, this representation starts with the ‘1’ 1-bit pattern, followed by the S bit indicating whether the reference is into the static or dynamic table. The 6-bit prefix integer (see Section 4.1.1) that follows is used to locate the table entry for the header field. When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table.
+
If the entry is in the static table, or in the dynamic table with an absolute index less than the Base, this representation starts with the ‘1’ 1-bit pattern, followed by the ‘T’ bit indicating whether the reference is into the static or dynamic table. The 6-bit prefix integer (see Section 4.1.1) that follows is used to locate the table entry for the header field. When T=1, the number represents the static table index; when T=0, the number is the relative index of the entry in the dynamic table.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
- | 0 | 1 | N | S |Name Index (4+)|
+ | 0 | 1 | N | T |Name Index (4+)|
+---+---+---+---+---------------+
| H | Value Length (7+) |
+---+---------------------------+
@@ -1068,7 +1068,7 @@
+-------------------------------+
Literal Header Field With Name Reference
-
The fourth (S) bit indicates whether the reference is to the static or dynamic table. The 4-bit prefix integer (see Section 4.1.1) that follows is used to locate the table entry for the header name. When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table.
+
The fourth (‘T’) bit indicates whether the reference is to the static or dynamic table. The 4-bit prefix integer (see Section 4.1.1) that follows is used to locate the table entry for the header name. When T=1, the number represents the static table index; when T=0, the number is the relative index of the entry in the dynamic table.
Only the header field name is taken from the dynamic table entry; the header field value is encoded as an 8-bit prefix string literal (see Section 4.1.2).
diff --git a/close3029/draft-ietf-quic-qpack.txt b/ianswett-limit-bursts/draft-ietf-quic-qpack.txt
similarity index 92%
rename from close3029/draft-ietf-quic-qpack.txt
rename to ianswett-limit-bursts/draft-ietf-quic-qpack.txt
index 3fb66642ef..49535da79d 100644
--- a/close3029/draft-ietf-quic-qpack.txt
+++ b/ianswett-limit-bursts/draft-ietf-quic-qpack.txt
@@ -5,10 +5,10 @@
QUIC C. Krasic
Internet-Draft Netflix
Intended status: Standards Track M. Bishop
-Expires: March 19, 2020 Akamai Technologies
+Expires: April 19, 2020 Akamai Technologies
A. Frindell, Ed.
Facebook
- September 16, 2019
+ October 17, 2019
QPACK: Header Compression for HTTP/3
@@ -46,16 +46,16 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on March 19, 2020.
+ This Internet-Draft will expire on April 19, 2020.
-Krasic, et al. Expires March 19, 2020 [Page 1]
+Krasic, et al. Expires April 19, 2020 [Page 1]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
Copyright Notice
@@ -109,9 +109,9 @@ Table of Contents
-Krasic, et al. Expires March 19, 2020 [Page 2]
+Krasic, et al. Expires April 19, 2020 [Page 2]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
4.3.4. Duplicate . . . . . . . . . . . . . . . . . . . . . . 17
@@ -165,9 +165,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 3]
+Krasic, et al. Expires April 19, 2020 [Page 3]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
QPACK reuses core concepts from HPACK, but is redesigned to allow
@@ -221,9 +221,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 4]
+Krasic, et al. Expires April 19, 2020 [Page 4]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
x (A) Indicates that x is A bits long
@@ -277,9 +277,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 5]
+Krasic, et al. Expires April 19, 2020 [Page 5]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
about each compressed header block that references the dynamic table
@@ -333,9 +333,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 6]
+Krasic, et al. Expires April 19, 2020 [Page 6]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
+----------+---------------------------------+--------+
@@ -365,7 +365,7 @@ Internet-Draft QPACK September 2019
When the decoder receives a header block with a Required Insert Count
greater than its own Insert Count, the stream cannot be processed
- immediately, and is considered "blocked" (see {blocked-decoding}).
+ immediately, and is considered "blocked" (see Section 2.2.1).
The decoder specifies an upper bound on the number of streams which
can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting (see
@@ -389,9 +389,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 7]
+Krasic, et al. Expires April 19, 2020 [Page 7]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
Since literals make the header block larger, this can result in the
@@ -445,9 +445,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 8]
+Krasic, et al. Expires April 19, 2020 [Page 8]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
When processing header blocks, the decoder expects the Required
@@ -501,9 +501,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 9]
+Krasic, et al. Expires April 19, 2020 [Page 9]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
encoder, but could be redundant with other decoder feedback. By
@@ -557,9 +557,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 10]
+Krasic, et al. Expires April 19, 2020 [Page 10]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
3.2. Dynamic Table
@@ -613,9 +613,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 11]
+Krasic, et al. Expires April 19, 2020 [Page 11]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
until the size of the dynamic table is less than or equal to the new
@@ -669,9 +669,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 12]
+Krasic, et al. Expires April 19, 2020 [Page 12]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
In encoder instructions, a relative index of "0" always refers to the
@@ -725,9 +725,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 13]
+Krasic, et al. Expires April 19, 2020 [Page 13]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
3.2.6. Post-Base Indexing
@@ -772,18 +772,18 @@ Internet-Draft QPACK September 2019
throughout. This string format includes optional Huffman encoding.
HPACK defines string literals to begin on a byte boundary. They
- begin with a single flag (indicating whether the string is Huffman-
- coded), followed by the Length encoded as a 7-bit prefix integer, and
- finally Length bytes of data. When Huffman encoding is enabled, the
- Huffman table from Appendix B of [RFC7541] is used without
- modification.
+ begin with a single bit flag, denoted as 'H' in this document
+ (indicating whether the string is Huffman-coded), followed by the
+ Length encoded as a 7-bit prefix integer, and finally Length bytes of
+ data. When Huffman encoding is enabled, the Huffman table from
+ Appendix B of [RFC7541] is used without modification.
-Krasic, et al. Expires March 19, 2020 [Page 14]
+Krasic, et al. Expires April 19, 2020 [Page 14]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
This document expands the definition of string literals and permits
@@ -837,9 +837,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 15]
+Krasic, et al. Expires April 19, 2020 [Page 15]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
as a string literal. For entries which already exist in the dynamic
@@ -880,11 +880,11 @@ Internet-Draft QPACK September 2019
An encoder adds an entry to the dynamic table where the header field
name matches the header field name of an entry stored in the static
or the dynamic table using an instruction that starts with the '1'
- one-bit pattern. The second ("S") bit indicates whether the
+ one-bit pattern. The second ('T') bit indicates whether the
reference is to the static or dynamic table. The 6-bit prefix
integer (see Section 4.1.1) that follows is used to locate the table
- entry for the header name. When S=1, the number represents the
- static table index; when S=0, the number is the relative index of the
+ entry for the header name. When T=1, the number represents the
+ static table index; when T=0, the number is the relative index of the
entry in the dynamic table.
The header name reference is followed by the header field value
@@ -893,14 +893,14 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 16]
+Krasic, et al. Expires April 19, 2020 [Page 16]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
- | 1 | S | Name Index (6+) |
+ | 1 | T | Name Index (6+) |
+---+---+-----------------------+
| H | Value Length (7+) |
+---+---------------------------+
@@ -949,9 +949,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 17]
+Krasic, et al. Expires April 19, 2020 [Page 17]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
The existing entry is re-inserted into the dynamic table without
@@ -1005,9 +1005,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 18]
+Krasic, et al. Expires April 19, 2020 [Page 18]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
0 1 2 3 4 5 6 7
@@ -1056,14 +1056,14 @@ Internet-Draft QPACK September 2019
Each header block is prefixed with two integers. The Required Insert
Count is encoded as an integer with an 8-bit prefix after the
encoding described in Section 4.5.1.1). The Base is encoded as sign-
- and-modulus integer, using a single sign bit and a value with a 7-bit
- prefix (see Section 4.5.1.2).
+ and-modulus integer, using a single sign bit ('S') and a value with a
+ 7-bit prefix (see Section 4.5.1.2).
-Krasic, et al. Expires March 19, 2020 [Page 19]
+Krasic, et al. Expires April 19, 2020 [Page 19]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
These two values are followed by representations for compressed
@@ -1117,9 +1117,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 20]
+Krasic, et al. Expires April 19, 2020 [Page 20]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
TotalNumberOfInserts is the total number of inserts into the
@@ -1160,9 +1160,9 @@ Internet-Draft QPACK September 2019
described in Section 3.2.5.
To save space, the Base is encoded relative to the Insert Count using
- a one-bit sign and the "Delta Base" value. A sign bit of 0 indicates
- that the Base is greater than or equal to the value of the Insert
- Count; the value of Delta Base is added to the Insert Count to
+ a one-bit sign ('S') and the "Delta Base" value. A sign bit of 0
+ indicates that the Base is greater than or equal to the value of the
+ Insert Count; the value of Delta Base is added to the Insert Count to
determine the value of the Base. A sign bit of 1 indicates that the
Base is less than the Insert Count. That is:
@@ -1173,9 +1173,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 21]
+Krasic, et al. Expires April 19, 2020 [Page 21]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
A single-pass encoder determines the Base before encoding a header
@@ -1210,18 +1210,18 @@ Internet-Draft QPACK September 2019
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
- | 1 | S | Index (6+) |
+ | 1 | T | Index (6+) |
+---+---+-----------------------+
Indexed Header Field
If the entry is in the static table, or in the dynamic table with an
absolute index less than the Base, this representation starts with
- the '1' 1-bit pattern, followed by the "S" bit indicating whether the
+ the '1' 1-bit pattern, followed by the 'T' bit indicating whether the
reference is into the static or dynamic table. The 6-bit prefix
integer (see Section 4.1.1) that follows is used to locate the table
- entry for the header field. When S=1, the number represents the
- static table index; when S=0, the number is the relative index of the
+ entry for the header field. When T=1, the number represents the
+ static table index; when T=0, the number is the relative index of the
entry in the dynamic table.
@@ -1229,9 +1229,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 22]
+Krasic, et al. Expires April 19, 2020 [Page 22]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
4.5.3. Indexed Header Field With Post-Base Index
@@ -1271,7 +1271,7 @@ Internet-Draft QPACK September 2019
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
- | 0 | 1 | N | S |Name Index (4+)|
+ | 0 | 1 | N | T |Name Index (4+)|
+---+---+---+---+---------------+
| H | Value Length (7+) |
+---+---------------------------+
@@ -1280,18 +1280,18 @@ Internet-Draft QPACK September 2019
Literal Header Field With Name Reference
- The fourth ("S") bit indicates whether the reference is to the static
+ The fourth ('T') bit indicates whether the reference is to the static
or dynamic table. The 4-bit prefix integer (see Section 4.1.1) that
-Krasic, et al. Expires March 19, 2020 [Page 23]
+Krasic, et al. Expires April 19, 2020 [Page 23]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
follows is used to locate the table entry for the header name. When
- S=1, the number represents the static table index; when S=0, the
+ T=1, the number represents the static table index; when T=0, the
number is the relative index of the entry in the dynamic table.
Only the header field name is taken from the dynamic table entry; the
@@ -1341,9 +1341,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 24]
+Krasic, et al. Expires April 19, 2020 [Page 24]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
0 1 2 3 4 5 6 7
@@ -1397,9 +1397,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 25]
+Krasic, et al. Expires April 19, 2020 [Page 25]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
unsent data, especially on the decoder stream where flexibility to
@@ -1453,9 +1453,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 26]
+Krasic, et al. Expires April 19, 2020 [Page 26]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
+-----------------------------+-------+--------------+--------------+
@@ -1482,12 +1482,12 @@ Internet-Draft QPACK September 2019
[HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
(HTTP/3)", draft-ietf-quic-http (work in progress),
- September 2019.
+ October 2019.
[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic-
- transport (work in progress), September 2019.
+ transport (work in progress), October 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
@@ -1509,9 +1509,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 27]
+Krasic, et al. Expires April 19, 2020 [Page 27]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
9.2. Informative References
@@ -1565,9 +1565,9 @@ Appendix A. Static Table
-Krasic, et al. Expires March 19, 2020 [Page 28]
+Krasic, et al. Expires April 19, 2020 [Page 28]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
| | | |
@@ -1621,9 +1621,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 29]
+Krasic, et al. Expires April 19, 2020 [Page 29]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
| | | |
@@ -1677,9 +1677,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 30]
+Krasic, et al. Expires April 19, 2020 [Page 30]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
| | | |
@@ -1733,9 +1733,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 31]
+Krasic, et al. Expires April 19, 2020 [Page 31]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
| | methods | |
@@ -1789,9 +1789,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 32]
+Krasic, et al. Expires April 19, 2020 [Page 32]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
Appendix B. Sample One Pass Encoding Algorithm
@@ -1845,9 +1845,9 @@ Appendix B. Sample One Pass Encoding Algorithm
-Krasic, et al. Expires March 19, 2020 [Page 33]
+Krasic, et al. Expires April 19, 2020 [Page 33]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
baseIndex = dynamicTable.baseIndex
@@ -1901,9 +1901,9 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 34]
+Krasic, et al. Expires April 19, 2020 [Page 34]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
Appendix C. Change Log
@@ -1957,9 +1957,9 @@ C.6. Since draft-ietf-quic-qpack-03
-Krasic, et al. Expires March 19, 2020 [Page 35]
+Krasic, et al. Expires April 19, 2020 [Page 35]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
C.7. Since draft-ietf-quic-qpack-02
@@ -2013,9 +2013,9 @@ C.10. Since draft-ietf-quic-qcram-00
-Krasic, et al. Expires March 19, 2020 [Page 36]
+Krasic, et al. Expires April 19, 2020 [Page 36]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
o Reworked indexing scheme (#1176, #1145, #1136, #1130, #1125,
@@ -2069,9 +2069,9 @@ Authors' Addresses
-Krasic, et al. Expires March 19, 2020 [Page 37]
+Krasic, et al. Expires April 19, 2020 [Page 37]
-Internet-Draft QPACK September 2019
+Internet-Draft QPACK October 2019
Alan Frindell (editor)
@@ -2125,4 +2125,4 @@ Internet-Draft QPACK September 2019
-Krasic, et al. Expires March 19, 2020 [Page 38]
+Krasic, et al. Expires April 19, 2020 [Page 38]
diff --git a/close3029/draft-ietf-quic-recovery.html b/ianswett-limit-bursts/draft-ietf-quic-recovery.html
similarity index 98%
rename from close3029/draft-ietf-quic-recovery.html
rename to ianswett-limit-bursts/draft-ietf-quic-recovery.html
index e7e3c93a24..d4e3acead6 100644
--- a/close3029/draft-ietf-quic-recovery.html
+++ b/ianswett-limit-bursts/draft-ietf-quic-recovery.html
@@ -375,12 +375,12 @@
-
+
-
+
@@ -404,12 +404,12 @@
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on March 19, 2020.
+
This Internet-Draft will expire on April 19, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
@@ -778,15 +778,15 @@
Once a later packet packet within the same packet number space has been acknowledged, an endpoint SHOULD declare an earlier packet lost if it was sent a threshold amount of time in the past. To avoid declaring packets as lost too early, this time threshold MUST be set to at least kGranularity. The time threshold is:
If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time.
-
Using max(SRTT, latest_RTT) protects from the two following cases:
+
Using max(smoothed_rtt, latest_rtt) protects from the two following cases:
-
the latest RTT sample is lower than the SRTT, perhaps due to reordering where the acknowledgement encountered a shorter path;
-
the latest RTT sample is higher than the SRTT, perhaps due to a sustained increase in the actual RTT, but the smoothed SRTT has not yet caught up.
+
the latest RTT sample is lower than the smoothed RTT, perhaps due to reordering where the acknowledgement encountered a shorter path;
+
the latest RTT sample is higher than the smoothed RTT, perhaps due to a sustained increase in the actual RTT, but the smoothed RTT has not yet caught up.
The RECOMMENDED time threshold (kTimeThreshold), expressed as a round-trip time multiplier, is 9/8.
Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT variance. Smaller thresholds reduce reordering resilience and increase spurious retransmissions, and larger thresholds increase loss detection delay.
This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the congestion controller. For example, a pacer might distribute the congestion window over the SRTT when used with a window-based controller, and a pacer might use the rate estimate of a rate-based controller.
+
This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the congestion controller. For example, a pacer might distribute the congestion window over the smoothed RTT when used with a window-based controller, and a pacer might use the rate estimate of a rate-based controller.
An implementation should take care to architect its congestion controller to work well with a pacer. For instance, a pacer might wrap the congestion controller and control the availability of the congestion window, or a pacer might pace out packets handed to it by the congestion controller. Timely delivery of ACK frames is important for efficient loss recovery. Packets containing only ACK frames should therefore not be paced, to avoid delaying their delivery to the peer.
-
As an example of a well-known and publicly available implementation of a flow pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards).
+
Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses. Implementations MUST either use pacing or limit such bursts to minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same as the recommended initial congestion window.
+
As an example of a well-known and publicly available implementation of a flow pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards).
A congestion window that is under-utilized SHOULD NOT be increased in either slow start or congestion avoidance. This can happen due to insufficient application data or flow control credit.
+
When bytes in flight is smaller than the congestion window and sending is not pacing limited, the congestion window is under-utilized. When this occurs, the congestion window SHOULD NOT be increased in either slow start or congestion avoidance. This can happen due to insufficient application data or flow control credit.
A sender MAY use the pipeACK method described in section 4.3 of [RFC7661] to determine if the congestion window is sufficiently utilized.
A sender that paces packets (see Section 6.8) might delay sending packets and not fully utilize the congestion window due to this delay. A sender should not consider itself application limited if it would have fully utilized the congestion window without pacing delay.
-
Bursting more than an initial window’s worth of data into the network might cause short-term congestion and losses. Implemementations SHOULD either use pacing or reduce their congestion window to limit such bursts.
-
A sender MAY implement alternate mechanisms to update its congestion window after periods of under-utilization, such as those proposed for TCP in [RFC7661].
+
A sender MAY implement alternate mechanisms to update its congestion window after periods of under-utilization, such as those proposed for TCP in [RFC7661].
diff --git a/close3029/draft-ietf-quic-recovery.txt b/ianswett-limit-bursts/draft-ietf-quic-recovery.txt
similarity index 91%
rename from close3029/draft-ietf-quic-recovery.txt
rename to ianswett-limit-bursts/draft-ietf-quic-recovery.txt
index a2518e5d00..521c2701eb 100644
--- a/close3029/draft-ietf-quic-recovery.txt
+++ b/ianswett-limit-bursts/draft-ietf-quic-recovery.txt
@@ -5,8 +5,8 @@
QUIC J. Iyengar, Ed.
Internet-Draft Fastly
Intended status: Standards Track I. Swett, Ed.
-Expires: March 19, 2020 Google
- September 16, 2019
+Expires: April 19, 2020 Google
+ October 17, 2019
QUIC Loss Detection and Congestion Control
@@ -42,7 +42,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on March 19, 2020.
+ This Internet-Draft will expire on April 19, 2020.
Copyright Notice
@@ -53,9 +53,9 @@ Copyright Notice
-Iyengar & Swett Expires March 19, 2020 [Page 1]
+Iyengar & Swett Expires April 19, 2020 [Page 1]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
This document is subject to BCP 78 and the IETF Trust's Legal
@@ -97,7 +97,7 @@ Table of Contents
5.5. Discarding Keys and Packet State . . . . . . . . . . . . 14
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15
- 6.1. Explicit Congestion Notification . . . . . . . . . . . . 15
+ 6.1. Explicit Congestion Notification . . . . . . . . . . . . 16
6.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 16
6.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 16
@@ -109,9 +109,9 @@ Table of Contents
-Iyengar & Swett Expires March 19, 2020 [Page 2]
+Iyengar & Swett Expires April 19, 2020 [Page 2]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
@@ -125,13 +125,13 @@ Internet-Draft QUIC Loss Detection September 2019
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 22
A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 22
- A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 22
+ A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 23
A.2. Constants of interest . . . . . . . . . . . . . . . . . . 23
- A.3. Variables of interest . . . . . . . . . . . . . . . . . . 23
+ A.3. Variables of interest . . . . . . . . . . . . . . . . . . 24
A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 24
A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 25
A.6. On Receiving an Acknowledgment . . . . . . . . . . . . . 25
- A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 26
+ A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 27
A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 27
A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 29
A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 29
@@ -165,9 +165,9 @@ Internet-Draft QUIC Loss Detection September 2019
-Iyengar & Swett Expires March 19, 2020 [Page 3]
+Iyengar & Swett Expires April 19, 2020 [Page 3]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
C.18. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 38
@@ -221,9 +221,9 @@ Internet-Draft QUIC Loss Detection September 2019
-Iyengar & Swett Expires March 19, 2020 [Page 4]
+Iyengar & Swett Expires April 19, 2020 [Page 4]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
Out-of-order Packets: Packets that do not increase the largest
@@ -277,9 +277,9 @@ Internet-Draft QUIC Loss Detection September 2019
-Iyengar & Swett Expires March 19, 2020 [Page 5]
+Iyengar & Swett Expires April 19, 2020 [Page 5]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
3.1.1. Separate Packet Number Spaces
@@ -333,9 +333,9 @@ Internet-Draft QUIC Loss Detection September 2019
-Iyengar & Swett Expires March 19, 2020 [Page 6]
+Iyengar & Swett Expires April 19, 2020 [Page 6]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
3.1.4. No Reneging
@@ -389,9 +389,9 @@ Internet-Draft QUIC Loss Detection September 2019
-Iyengar & Swett Expires March 19, 2020 [Page 7]
+Iyengar & Swett Expires April 19, 2020 [Page 7]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
An RTT sample is generated using only the largest acknowledged packet
@@ -445,9 +445,9 @@ Internet-Draft QUIC Loss Detection September 2019
-Iyengar & Swett Expires March 19, 2020 [Page 8]
+Iyengar & Swett Expires April 19, 2020 [Page 8]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
Consequently, when a peer reports an Ack Delay that is greater than
@@ -501,9 +501,9 @@ Internet-Draft QUIC Loss Detection September 2019
-Iyengar & Swett Expires March 19, 2020 [Page 9]
+Iyengar & Swett Expires April 19, 2020 [Page 9]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
5.1. Acknowledgement-based Detection
@@ -552,27 +552,29 @@ Internet-Draft QUIC Loss Detection September 2019
declaring packets as lost too early, this time threshold MUST be set
to at least kGranularity. The time threshold is:
- kTimeThreshold * max(SRTT, latest_RTT, kGranularity)
+ kTimeThreshold * max(smoothed_rtt, latest_rtt, kGranularity)
-Iyengar & Swett Expires March 19, 2020 [Page 10]
+Iyengar & Swett Expires April 19, 2020 [Page 10]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
If packets sent prior to the largest acknowledged packet cannot yet
be declared lost, then a timer SHOULD be set for the remaining time.
- Using max(SRTT, latest_RTT) protects from the two following cases:
+ Using max(smoothed_rtt, latest_rtt) protects from the two following
+ cases:
- o the latest RTT sample is lower than the SRTT, perhaps due to
- reordering where the acknowledgement encountered a shorter path;
+ o the latest RTT sample is lower than the smoothed RTT, perhaps due
+ to reordering where the acknowledgement encountered a shorter
+ path;
- o the latest RTT sample is higher than the SRTT, perhaps due to a
- sustained increase in the actual RTT, but the smoothed SRTT has
- not yet caught up.
+ o the latest RTT sample is higher than the smoothed RTT, perhaps due
+ to a sustained increase in the actual RTT, but the smoothed RTT
+ has not yet caught up.
The RECOMMENDED time threshold (kTimeThreshold), expressed as a
round-trip time multiplier, is 9/8.
@@ -607,16 +609,17 @@ Internet-Draft QUIC Loss Detection September 2019
The PTO period is the amount of time that a sender ought to wait for
an acknowledgement of a sent packet. This time period includes the
estimated network roundtrip-time (smoothed_rtt), the variance in the
- estimate (4*rttvar), and max_ack_delay, to account for the maximum
- time by which a receiver might delay sending an acknowledgement.
-Iyengar & Swett Expires March 19, 2020 [Page 11]
+Iyengar & Swett Expires April 19, 2020 [Page 11]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
+
+ estimate (4*rttvar), and max_ack_delay, to account for the maximum
+ time by which a receiver might delay sending an acknowledgement.
The PTO value MUST be set to at least kGranularity, to avoid the
timer expiring immediately.
@@ -663,16 +666,16 @@ Internet-Draft QUIC Loss Detection September 2019
from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished
its address validation (see Section 8 of [QUIC-TRANSPORT]). That is,
- the client MUST set the probe timer if the client has not received an
- acknowledgement for one of its Handshake or 1-RTT packets.
-
-Iyengar & Swett Expires March 19, 2020 [Page 12]
+Iyengar & Swett Expires April 19, 2020 [Page 12]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
+
+ the client MUST set the probe timer if the client has not received an
+ acknowledgement for one of its Handshake or 1-RTT packets.
Prior to handshake completion, when few to none RTT samples have been
generated, it is possible that the probe timer expiration is due to
@@ -719,17 +722,17 @@ Internet-Draft QUIC Loss Detection September 2019
Probe packets sent on a PTO MUST be ack-eliciting. A probe packet
SHOULD carry new data when possible. A probe packet MAY carry
- retransmitted unacknowledged data when new data is unavailable, when
- flow control does not permit new data to be sent, or to
- opportunistically reduce loss recovery delay. Implementations MAY
-Iyengar & Swett Expires March 19, 2020 [Page 13]
+Iyengar & Swett Expires April 19, 2020 [Page 13]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
+ retransmitted unacknowledged data when new data is unavailable, when
+ flow control does not permit new data to be sent, or to
+ opportunistically reduce loss recovery delay. Implementations MAY
use alternate strategies for determining the content of probe
packets, including sending new or retransmitted data based on the
application's priorities.
@@ -775,17 +778,16 @@ Internet-Draft QUIC Loss Detection September 2019
anymore. The sender MUST discard all recovery state associated with
those packets and MUST remove them from the count of bytes in flight.
- Endpoints stop sending and receiving Initial packets once they start
- exchanging Handshake packets (see Section 17.2.2.1 of
-
-Iyengar & Swett Expires March 19, 2020 [Page 14]
+Iyengar & Swett Expires April 19, 2020 [Page 14]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
+ Endpoints stop sending and receiving Initial packets once they start
+ exchanging Handshake packets (see Section 17.2.2.1 of
[QUIC-TRANSPORT]). At this point, recovery state for all in-flight
Initial packets is discarded.
@@ -829,19 +831,22 @@ Internet-Draft QUIC Loss Detection September 2019
another. The signals QUIC provides for congestion control are
generic and are designed to support different algorithms.
-6.1. Explicit Congestion Notification
- If a path has been verified to support ECN, QUIC treats a Congestion
- Experienced codepoint in the IP header as a signal of congestion.
- This document specifies an endpoint's response when its peer receives
-Iyengar & Swett Expires March 19, 2020 [Page 15]
+
+
+Iyengar & Swett Expires April 19, 2020 [Page 15]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
+6.1. Explicit Congestion Notification
+
+ If a path has been verified to support ECN, QUIC treats a Congestion
+ Experienced codepoint in the IP header as a signal of congestion.
+ This document specifies an endpoint's response when its peer receives
packets with the Congestion Experienced codepoint. As discussed in
[RFC8311], endpoints are permitted to experiment with other response
functions.
@@ -884,20 +889,18 @@ Internet-Draft QUIC Loss Detection September 2019
packets cannot be processed until the Initial packets arrive, and
1-RTT packets cannot be processed until the handshake completes.
Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets
- that might arrive before the peer has packet protection keys to
- process those packets.
-
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 16]
+Iyengar & Swett Expires April 19, 2020 [Page 16]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
+ that might arrive before the peer has packet protection keys to
+ process those packets.
+
6.6. Probe Timeout
Probe packets MUST NOT be blocked by the congestion controller. A
@@ -926,7 +929,7 @@ Internet-Draft QUIC Loss Detection September 2019
smoothed_rtt = 1 rttvar = 0 max_ack_delay = 0
kPersistentCongestionThreshold = 3
- If an eck-eliciting packet is sent at time = 0, the following
+ If an ack-eliciting packet is sent at time = 0, the following
scenario would illustrate persistent congestion:
+-----+------------------------+
@@ -943,17 +946,17 @@ Internet-Draft QUIC Loss Detection September 2019
The first three packets are determined to be lost when the ACK of
packet 4 is received at t=8. The congestion period is calculated as
- the time between the oldest and newest lost packets: (3 - 0) = 3.
- The duration for persistent congestion is equal to: (1 *
- kPersistentCongestionThreshold) = 3. Because the threshold was
-Iyengar & Swett Expires March 19, 2020 [Page 17]
+Iyengar & Swett Expires April 19, 2020 [Page 17]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
+ the time between the oldest and newest lost packets: (3 - 0) = 3.
+ The duration for persistent congestion is equal to: (1 *
+ kPersistentCongestionThreshold) = 3. Because the threshold was
reached and because none of the packets between the oldest and the
newest packets are acknowledged, the network is considered to have
experienced persistent congestion.
@@ -970,7 +973,7 @@ Internet-Draft QUIC Loss Detection September 2019
This document does not specify a pacer, but it is RECOMMENDED that a
sender pace sending of all in-flight packets based on input from the
congestion controller. For example, a pacer might distribute the
- congestion window over the SRTT when used with a window-based
+ congestion window over the smoothed RTT when used with a window-based
controller, and a pacer might use the rate estimate of a rate-based
controller.
@@ -983,15 +986,32 @@ Internet-Draft QUIC Loss Detection September 2019
frames should therefore not be paced, to avoid delaying their
delivery to the peer.
+ Sending multiple packets into the network without any delay between
+ them creates a packet burst that might cause short-term congestion
+ and losses. Implementations MUST either use pacing or limit such
+ bursts to minimum of 10 * kMaxDatagramSize and max(2*
+ kMaxDatagramSize, 14720)), the same as the recommended initial
+ congestion window.
+
As an example of a well-known and publicly available implementation
of a flow pacer, implementers are referred to the Fair Queue packet
scheduler (fq qdisc) in Linux (3.11 onwards).
6.9. Under-utilizing the Congestion Window
- A congestion window that is under-utilized SHOULD NOT be increased in
- either slow start or congestion avoidance. This can happen due to
- insufficient application data or flow control credit.
+ When bytes in flight is smaller than the congestion window and
+ sending is not pacing limited, the congestion window is under-
+ utilized. When this occurs, the congestion window SHOULD NOT be
+
+
+
+Iyengar & Swett Expires April 19, 2020 [Page 18]
+
+Internet-Draft QUIC Loss Detection October 2019
+
+
+ increased in either slow start or congestion avoidance. This can
+ happen due to insufficient application data or flow control credit.
A sender MAY use the pipeACK method described in section 4.3 of
[RFC7661] to determine if the congestion window is sufficiently
@@ -1002,19 +1022,6 @@ Internet-Draft QUIC Loss Detection September 2019
delay. A sender should not consider itself application limited if it
would have fully utilized the congestion window without pacing delay.
-
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 18]
-
-Internet-Draft QUIC Loss Detection September 2019
-
-
- Bursting more than an initial window's worth of data into the network
- might cause short-term congestion and losses. Implemementations
- SHOULD either use pacing or reduce their congestion window to limit
- such bursts.
-
A sender MAY implement alternate mechanisms to update its congestion
window after periods of under-utilization, such as those proposed for
TCP in [RFC7661].
@@ -1051,21 +1058,20 @@ Internet-Draft QUIC Loss Detection September 2019
Reporting additional ECN-CE markings will cause a sender to reduce
their sending rate, which is similar in effect to advertising reduced
- connection flow control limits and so no advantage is gained by doing
- so.
-
- Endpoints choose the congestion controller that they use. Though
- congestion controllers generally treat reports of ECN-CE markings as
- equivalent to loss [RFC8311], the exact response for each controller
-
-Iyengar & Swett Expires March 19, 2020 [Page 19]
+Iyengar & Swett Expires April 19, 2020 [Page 19]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
+
+ connection flow control limits and so no advantage is gained by doing
+ so.
+ Endpoints choose the congestion controller that they use. Though
+ congestion controllers generally treat reports of ECN-CE markings as
+ equivalent to loss [RFC8311], the exact response for each controller
could be different. Failure to correctly respond to information
about ECN markings is therefore difficult to detect.
@@ -1079,13 +1085,13 @@ Internet-Draft QUIC Loss Detection September 2019
[QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
- QUIC", draft-ietf-quic-tls (work in progress), September
+ QUIC", draft-ietf-quic-tls (work in progress), October
2019.
[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic-
- transport (work in progress), September 2019.
+ transport (work in progress), October 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
@@ -1107,6 +1113,15 @@ Internet-Draft QUIC Loss Detection September 2019
Refining TCP Congestion Control", ACM SIGCOMM , August
1996.
+
+
+
+
+Iyengar & Swett Expires April 19, 2020 [Page 20]
+
+Internet-Draft QUIC Loss Detection October 2019
+
+
[RACK] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK:
a time-based fast loss detection algorithm for TCP",
draft-ietf-tcpm-rack-05 (work in progress), April 2019.
@@ -1115,13 +1130,6 @@ Internet-Draft QUIC Loss Detection September 2019
Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February
2003, .
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 20]
-
-Internet-Draft QUIC Loss Detection September 2019
-
-
[RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton,
"Improving the Robustness of TCP to Non-Congestion
Events", RFC 4653, DOI 10.17487/RFC4653, August 2006,
@@ -1159,6 +1167,17 @@ Internet-Draft QUIC Loss Detection September 2019
RFC 6675, DOI 10.17487/RFC6675, August 2012,
.
+
+
+
+
+
+
+Iyengar & Swett Expires April 19, 2020 [Page 21]
+
+Internet-Draft QUIC Loss Detection October 2019
+
+
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013,
@@ -1169,15 +1188,6 @@ Internet-Draft QUIC Loss Detection September 2019
DOI 10.17487/RFC7661, October 2015,
.
-
-
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 21]
-
-Internet-Draft QUIC Loss Detection September 2019
-
-
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018,
@@ -1217,6 +1227,13 @@ A.1. Tracking Sent Packets
Sent packets are tracked for each packet number space, and ACK
processing only applies to a single space.
+
+
+Iyengar & Swett Expires April 19, 2020 [Page 22]
+
+Internet-Draft QUIC Loss Detection October 2019
+
+
A.1.1. Sent Packet Fields
packet_number: The packet number of the sent packet.
@@ -1226,14 +1243,6 @@ A.1.1. Sent Packet Fields
be received, though the peer could delay sending the ACK frame
containing it by up to the MaxAckDelay.
-
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 22]
-
-Internet-Draft QUIC Loss Detection September 2019
-
-
in_flight: A boolean that indicates whether the packet counts
towards bytes in flight.
@@ -1271,6 +1280,16 @@ A.2. Constants of interest
ApplicationData,
}
+
+
+
+
+
+Iyengar & Swett Expires April 19, 2020 [Page 23]
+
+Internet-Draft QUIC Loss Detection October 2019
+
+
A.3. Variables of interest
Variables required to implement the congestion control mechanisms are
@@ -1282,14 +1301,6 @@ A.3. Variables of interest
smoothed_rtt: The smoothed RTT of the connection, computed as
described in [RFC6298]
-
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 23]
-
-Internet-Draft QUIC Loss Detection September 2019
-
-
rttvar: The RTT variance, computed as described in [RFC6298]
min_rtt: The minimum RTT seen in the connection, ignoring ack delay.
@@ -1324,6 +1335,17 @@ A.4. Initialization
At the beginning of the connection, initialize the loss detection
variables as follows:
+
+
+
+
+
+
+Iyengar & Swett Expires April 19, 2020 [Page 24]
+
+Internet-Draft QUIC Loss Detection October 2019
+
+
loss_detection_timer.reset()
pto_count = 0
latest_rtt = 0
@@ -1336,16 +1358,6 @@ A.4. Initialization
largest_acked_packet[pn_space] = infinite
loss_time[pn_space] = 0
-
-
-
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 24]
-
-Internet-Draft QUIC Loss Detection September 2019
-
-
A.5. On Sending a Packet
After a packet is sent, information about the packet is stored. The
@@ -1383,6 +1395,13 @@ A.6. On Receiving an Acknowledgment
largest_acked_packet[pn_space] =
max(largest_acked_packet[pn_space], ack.largest_acked)
+
+
+Iyengar & Swett Expires April 19, 2020 [Page 25]
+
+Internet-Draft QUIC Loss Detection October 2019
+
+
// Nothing to do if there are no newly acked packets.
newly_acked_packets = DetermineNewlyAckedPackets(ack, pn_space)
if (newly_acked_packets.empty()):
@@ -1394,14 +1413,6 @@ A.6. On Receiving an Acknowledgment
IncludesAckEliciting(newly_acked_packets)):
latest_rtt =
now - sent_packets[pn_space][ack.largest_acked].time_sent
-
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 25]
-
-Internet-Draft QUIC Loss Detection September 2019
-
-
ack_delay = 0
if (pn_space == ApplicationData):
ack_delay = ack.ack_delay
@@ -1439,6 +1450,14 @@ Internet-Draft QUIC Loss Detection September 2019
adjusted_rtt = latest_rtt - ack_delay
rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt)
+
+
+
+Iyengar & Swett Expires April 19, 2020 [Page 26]
+
+Internet-Draft QUIC Loss Detection October 2019
+
+
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
A.7. On Packet Acknowledgment
@@ -1448,16 +1467,6 @@ A.7. On Packet Acknowledgment
newly acknowledge several packets. OnPacketAcked must be called once
for each of these newly acknowledged packets.
-
-
-
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 26]
-
-Internet-Draft QUIC Loss Detection September 2019
-
-
OnPacketAcked takes two parameters: acked_packet, which is the struct
detailed in Appendix A.1.1, and the packet number space that this ACK
frame was sent for.
@@ -1500,18 +1509,9 @@ A.8. Setting the Loss Detection Timer
-
-
-
-
-
-
-
-
-
-Iyengar & Swett Expires March 19, 2020 [Page 27]
+Iyengar & Swett Expires April 19, 2020 [Page 27]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
// Returns the earliest loss_time and the packet number
@@ -1565,9 +1565,9 @@ Internet-Draft QUIC Loss Detection September 2019
-Iyengar & Swett Expires March 19, 2020 [Page 28]
+Iyengar & Swett Expires April 19, 2020 [Page 28]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
A.9. On Timeout
@@ -1621,9 +1621,9 @@ A.10. Detecting Lost Packets
-Iyengar & Swett Expires March 19, 2020 [Page 29]
+Iyengar & Swett Expires April 19, 2020 [Page 29]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
DetectLostPackets(pn_space):
@@ -1677,9 +1677,9 @@ B.1. Constants of interest
-Iyengar & Swett Expires March 19, 2020 [Page 30]
+Iyengar & Swett Expires April 19, 2020 [Page 30]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
calculating initial and minimum congestion windows. The
@@ -1733,9 +1733,9 @@ B.2. Variables of interest
-Iyengar & Swett Expires March 19, 2020 [Page 31]
+Iyengar & Swett Expires April 19, 2020 [Page 31]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
recovery. When a packet sent after this time is acknowledged,
@@ -1789,9 +1789,9 @@ B.5. On Packet Acknowledgement
-Iyengar & Swett Expires March 19, 2020 [Page 32]
+Iyengar & Swett Expires April 19, 2020 [Page 32]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
InCongestionRecovery(sent_time):
@@ -1845,9 +1845,9 @@ B.7. Process ECN Information
-Iyengar & Swett Expires March 19, 2020 [Page 33]
+Iyengar & Swett Expires April 19, 2020 [Page 33]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
B.8. On Packets Lost
@@ -1901,9 +1901,9 @@ C.2. Since draft-ietf-quic-recovery-21
-Iyengar & Swett Expires March 19, 2020 [Page 34]
+Iyengar & Swett Expires April 19, 2020 [Page 34]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
C.3. Since draft-ietf-quic-recovery-20
@@ -1957,9 +1957,9 @@ C.5. Since draft-ietf-quic-recovery-18
-Iyengar & Swett Expires March 19, 2020 [Page 35]
+Iyengar & Swett Expires April 19, 2020 [Page 35]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
o What to send on multiple PTOs (#2380)
@@ -2013,9 +2013,9 @@ C.7. Since draft-ietf-quic-recovery-16
-Iyengar & Swett Expires March 19, 2020 [Page 36]
+Iyengar & Swett Expires April 19, 2020 [Page 36]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
o Limit ack_delay by max_ack_delay (#2060, #2099)
@@ -2069,9 +2069,9 @@ C.12. Since draft-ietf-quic-recovery-10
-Iyengar & Swett Expires March 19, 2020 [Page 37]
+Iyengar & Swett Expires April 19, 2020 [Page 37]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
o Define time_of_last_sent_handshake_packet (#1171)
@@ -2125,9 +2125,9 @@ C.20. Since draft-ietf-quic-recovery-02
-Iyengar & Swett Expires March 19, 2020 [Page 38]
+Iyengar & Swett Expires April 19, 2020 [Page 38]
-Internet-Draft QUIC Loss Detection September 2019
+Internet-Draft QUIC Loss Detection October 2019
o Require connection abort if a skipped packet was acknowledged
@@ -2181,4 +2181,4 @@ Authors' Addresses
-Iyengar & Swett Expires March 19, 2020 [Page 39]
+Iyengar & Swett Expires April 19, 2020 [Page 39]
diff --git a/close3029/draft-ietf-quic-tls.html b/ianswett-limit-bursts/draft-ietf-quic-tls.html
similarity index 89%
rename from close3029/draft-ietf-quic-tls.html
rename to ianswett-limit-bursts/draft-ietf-quic-tls.html
index 637b9fc267..9def84bbf0 100644
--- a/close3029/draft-ietf-quic-tls.html
+++ b/ianswett-limit-bursts/draft-ietf-quic-tls.html
@@ -298,12 +298,13 @@
-
-
-
-
-
-
+
+
+
+
+
+
+
@@ -361,12 +362,12 @@
-
+
-
+
@@ -390,12 +391,12 @@
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on March 19, 2020.
+
This Internet-Draft will expire on April 19, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
PADDING frames MAY appear in packets of any encryption level.
+
PADDING and PING frames MAY appear in packets of any encryption level.
CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any encryption level except 0-RTT.
ACK frames MAY appear in packets of any encryption level other than 0-RTT, but can only acknowledge packets which appeared in that packet number space.
All other frame types MUST only be sent in the 0-RTT and 1-RTT levels.
As shown in Figure 2, the interface from QUIC to TLS consists of three primary functions:
+
As shown in Figure 2, the interface from QUIC to TLS consists of four primary functions:
Sending and receiving handshake messages
+
Processing stored transport and application state from a resumed session and determining if it is valid to accept early data
Rekeying (both transmit and receive)
Handshake state updates
@@ -791,9 +796,10 @@
In order to drive the handshake, TLS depends on being able to send and receive handshake messages. There are two basic functions on this interface: one where QUIC requests handshake messages and one where QUIC provides handshake packets.
Before starting the handshake QUIC provides TLS with the transport parameters (see Section 8.2) that it wishes to carry.
A QUIC client starts TLS by requesting TLS handshake bytes from TLS. The client acquires handshake bytes before sending its first packet. A QUIC server starts the process by providing TLS with the client’s handshake bytes.
-
At any given time, the TLS stack at an endpoint will have a current sending encryption level and receiving encryption level. Each encryption level is associated with a different flow of bytes, which is reliably transmitted to the peer in CRYPTO frames. When TLS provides handshake bytes to be sent, they are appended to the current flow and any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level.
+
At any time, the TLS stack at an endpoint will have a current sending encryption level and receiving encryption level. Each encryption level is associated with a different flow of bytes, which is reliably transmitted to the peer in CRYPTO frames. When TLS provides handshake bytes to be sent, they are appended to the current flow and any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level.
QUIC takes the unprotected content of TLS handshake records as the content of CRYPTO frames. TLS record protection is not used by QUIC. QUIC assembles CRYPTO frames into QUIC packets, which are protected using QUIC packet protection.
-
When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows:
+
QUIC is only capable of conveying TLS handshake records in CRYPTO frames. TLS alerts are turned into QUIC CONNECTION_CLOSE error codes; see Section 4.9. TLS application data and other message types cannot be carried by QUIC at any encryption level and is an error if they are received from the TLS stack.
+
When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows:
@@ -801,10 +807,10 @@
If the packet is from a previously installed encryption level, it MUST not contain data which extends past the end of previously received data in that flow. Implementations MUST treat any violations of this requirement as a connection error of type PROTOCOL_VIOLATION.
If the packet is from a new encryption level, it is saved for later processing by TLS. Once TLS moves to receiving from this encryption level, saved data can be provided. When providing data from any new encryption level to TLS, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION.
-
Each time that TLS is provided with new data, new handshake bytes are requested from TLS. TLS might not provide any bytes if the handshake messages it has received are incomplete or it has no data to send.
-
Once the TLS handshake is complete, this is indicated to QUIC along with any final handshake bytes that TLS needs to send. TLS also provides QUIC with the transport parameters that the peer advertised during the handshake.
-
Once the handshake is complete, TLS becomes passive. TLS can still receive data from its peer and respond in kind, but it will not need to send more data unless specifically requested - either by an application or QUIC. One reason to send data is that the server might wish to provide additional or updated session tickets to a client.
-
When the handshake is complete, QUIC only needs to provide TLS with any data that arrives in CRYPTO streams. In the same way that is done during the handshake, new data is requested from TLS after providing received data.
+
Each time that TLS is provided with new data, new handshake bytes are requested from TLS. TLS might not provide any bytes if the handshake messages it has received are incomplete or it has no data to send.
+
Once the TLS handshake is complete, this is indicated to QUIC along with any final handshake bytes that TLS needs to send. TLS also provides QUIC with the transport parameters that the peer advertised during the handshake.
+
Once the handshake is complete, TLS becomes passive. TLS can still receive data from its peer and respond in kind, but it will not need to send more data unless specifically requested - either by an application or QUIC. One reason to send data is that the server might wish to provide additional or updated session tickets to a client.
+
When the handshake is complete, QUIC only needs to provide TLS with any data that arrives in CRYPTO streams. In the same way that is done during the handshake, new data is requested from TLS after providing received data.
The requirements for authentication depend on the application protocol that is in use. TLS provides server authentication and permits the server to request client authentication.
A client MUST authenticate the identity of the server. This typically involves verification that the identity of the server is included in a certificate and that the certificate is issued by a trusted entity (see for example [RFC2818]).
A server MAY request that the client authenticate during the handshake. A server MAY refuse a connection if the client is unable to authenticate when requested. The requirements for client authentication vary based on application protocol and deployment.
-
A server MUST NOT use post-handshake client authentication (see Section 4.6.2 of [TLS13]).
+
A server MUST NOT use post-handshake client authentication (as defined in Section 4.6.2 of [TLS13]), because the multiplexing offered by QUIC prevents clients from correlating the certificate request with the application-level event that triggered it (see [HTTP2-TLS13]). More specifically, servers MUST NOT send post-handshake TLS CertificateRequest messages and clients MUST treat receipt of such messages as a connection error of type PROTOCOL_VIOLATION.
In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket message that contains the “early_data” extension with a max_early_data_size of 0xffffffff; the amount of data which the client can send in 0-RTT is controlled by the “initial_max_data” transport parameter supplied by the server. A client MUST treat receipt of a NewSessionTicket that contains an “early_data” extension with any other value as a connection error of type PROTOCOL_VIOLATION.
+
To communicate their willingness to process 0-RTT data, servers send a NewSessionTicket message that contains the “early_data” extension with a max_early_data_size of 0xffffffff; the amount of data which the client can send in 0-RTT is controlled by the “initial_max_data” transport parameter supplied by the server. Servers MUST NOT send the “early_data” extension with a max_early_data_size set to any value other than 0xffffffff. A client MUST treat receipt of a NewSessionTicket that contains an “early_data” extension with any other value as a connection error of type PROTOCOL_VIOLATION.
A client that wishes to send 0-RTT packets uses the “early_data” extension in the ClientHello message of a subsequent handshake (see Section 4.2.10 of [TLS13]). It then sends the application data in 0-RTT packets.
-
Early data within the TLS connection MUST NOT be used. As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type PROTOCOL_VIOLATION.
When 0-RTT is rejected, all connection characteristics that the client assumed might be incorrect. This includes the choice of application protocol, transport parameters, and any application configuration. The client therefore MUST reset the state of all streams, including application state bound to those streams.
A client MAY attempt to send 0-RTT again if it receives a Retry or Version Negotiation packet. These packets do not signify rejection of 0-RTT.
In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of [TLS13]) can be used to correct a client’s incorrect KeyShare extension as well as for a stateless round-trip check. From the perspective of QUIC, this just looks like additional messages carried in the Initial encryption level. Although it is in principle possible to use this feature for address verification in QUIC, QUIC implementations SHOULD instead use the Retry feature (see Section 8.1 of [QUIC-TRANSPORT]). HelloRetryRequest is still used to request key shares.
+
When a server receives a ClientHello with the “early_data” extension, it has to decide whether to accept or reject early data from the client. Some of this decision is made by the TLS stack (e.g., checking that the cipher suite being resumed was included in the ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack has no reason to reject early data, the QUIC stack or the application protocol using QUIC might reject early data because the configuration of the transport or application associated with the resumed session is not compatible with the server’s current configuration.
+
QUIC requires additional transport state to be associated with a 0-RTT session ticket. One common way to implement this is using stateless session tickets and storing this state in the session ticket. Application protocols that use QUIC might have similar requirements regarding associating or storing state. This associated state is used for deciding whether early data must be rejected. For example, HTTP/3 ([QUIC-HTTP]) settings determine how early data from the client is interpreted. Other applications using QUIC could have different requirements for determining whether to accept or reject early data.
If TLS experiences an error, it generates an appropriate alert as defined in Section 6 of [TLS13].
-
A TLS alert is turned into a QUIC connection error by converting the one-byte alert description into a QUIC error code. The alert description is added to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR. The resulting value is sent in a QUIC CONNECTION_CLOSE frame.
-
The alert level of all TLS alerts is “fatal”; a TLS stack MUST NOT generate alerts at the “warning” level.
+
In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of [TLS13]) can be used to correct a client’s incorrect KeyShare extension as well as for a stateless round-trip check. From the perspective of QUIC, this just looks like additional messages carried in the Initial encryption level. Although it is in principle possible to use this feature for address verification in QUIC, QUIC implementations SHOULD instead use the Retry feature (see Section 8.1 of [QUIC-TRANSPORT]). HelloRetryRequest is still used to request key shares.
If TLS experiences an error, it generates an appropriate alert as defined in Section 6 of [TLS13].
+
A TLS alert is turned into a QUIC connection error by converting the one-byte alert description into a QUIC error code. The alert description is added to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR. The resulting value is sent in a QUIC CONNECTION_CLOSE frame.
+
The alert level of all TLS alerts is “fatal”; a TLS stack MUST NOT generate alerts at the “warning” level.
After QUIC moves to a new encryption level, packet protection keys for previous encryption levels can be discarded. This occurs several times during the handshake, as well as when keys are updated; see Section 6.
-
Packet protection keys are not discarded immediately when new keys are available. If packets from a lower encryption level contain CRYPTO frames, frames that retransmit that data MUST be sent at the same encryption level. Similarly, an endpoint generates acknowledgements for packets at the same encryption level as the packet being acknowledged. Thus, it is possible that keys for a lower encryption level are needed for a short time after keys for a newer encryption level are available.
-
An endpoint cannot discard keys for a given encryption level unless it has both received and acknowledged all CRYPTO frames for that encryption level and when all CRYPTO frames for that encryption level have been acknowledged by its peer. However, this does not guarantee that no further packets will need to be received or sent at that encryption level because a peer might not have received all the acknowledgements necessary to reach the same state.
-
Though an endpoint might retain older keys, new data MUST be sent at the highest currently-available encryption level. Only ACK frames and retransmissions of data in CRYPTO frames are sent at a previous encryption level. These packets MAY also include PADDING frames.
After QUIC moves to a new encryption level, packet protection keys for previous encryption levels can be discarded. This occurs several times during the handshake, as well as when keys are updated; see Section 6.
+
Packet protection keys are not discarded immediately when new keys are available. If packets from a lower encryption level contain CRYPTO frames, frames that retransmit that data MUST be sent at the same encryption level. Similarly, an endpoint generates acknowledgements for packets at the same encryption level as the packet being acknowledged. Thus, it is possible that keys for a lower encryption level are needed for a short time after keys for a newer encryption level are available.
+
An endpoint cannot discard keys for a given encryption level unless it has both received and acknowledged all CRYPTO frames for that encryption level and when all CRYPTO frames for that encryption level have been acknowledged by its peer. However, this does not guarantee that no further packets will need to be received or sent at that encryption level because a peer might not have received all the acknowledgements necessary to reach the same state.
+
Though an endpoint might retain older keys, new data MUST be sent at the highest currently-available encryption level. Only ACK frames and retransmissions of data in CRYPTO frames are sent at a previous encryption level. These packets MAY also include PADDING frames.
Packets protected with Initial secrets (Section 5.2) are not authenticated, meaning that an attacker could spoof packets with the intent to disrupt a connection. To limit these attacks, Initial packet protection keys can be discarded more aggressively than other keys.
-
The successful use of Handshake packets indicates that no more Initial packets need to be exchanged, as these keys can only be produced after receiving all CRYPTO frames from Initial packets. Thus, a client MUST discard Initial keys when it first sends a Handshake packet and a server MUST discard Initial keys when it first successfully processes a Handshake packet. Endpoints MUST NOT send Initial packets after this point.
-
This results in abandoning loss recovery state for the Initial encryption level and ignoring any outstanding Initial packets.
Packets protected with Initial secrets (Section 5.2) are not authenticated, meaning that an attacker could spoof packets with the intent to disrupt a connection. To limit these attacks, Initial packet protection keys can be discarded more aggressively than other keys.
+
The successful use of Handshake packets indicates that no more Initial packets need to be exchanged, as these keys can only be produced after receiving all CRYPTO frames from Initial packets. Thus, a client MUST discard Initial keys when it first sends a Handshake packet and a server MUST discard Initial keys when it first successfully processes a Handshake packet. Endpoints MUST NOT send Initial packets after this point.
+
This results in abandoning loss recovery state for the Initial encryption level and ignoring any outstanding Initial packets.
An endpoint MUST NOT discard its handshake keys until the TLS handshake is confirmed (Section 4.1.2). An endpoint SHOULD discard its handshake keys as soon as it has confirmed the handshake. Most application protocols will send data after the handshake, resulting in acknowledgements that allow both endpoints to discard their handshake keys promptly. Endpoints that do not have reason to send immediately after completing the handshake MAY send ack-eliciting frames, such as PING, which will cause the handshake to be confirmed when they are acknowledged.
An endpoint MUST NOT discard its handshake keys until the TLS handshake is confirmed (Section 4.1.2). An endpoint SHOULD discard its handshake keys as soon as it has confirmed the handshake. Most application protocols will send data after the handshake, resulting in acknowledgements that allow both endpoints to discard their handshake keys promptly. Endpoints that do not have reason to send immediately after completing the handshake MAY send ack-eliciting frames, such as PING, which will cause the handshake to be confirmed when they are acknowledged.
0-RTT and 1-RTT packets share the same packet number space, and clients do not send 0-RTT packets after sending a 1-RTT packet (Section 5.6).
-
Therefore, a client SHOULD discard 0-RTT keys as soon as it installs 1-RTT keys, since they have no use after that moment.
-
Additionally, a server MAY discard 0-RTT keys as soon as it receives a 1-RTT packet. However, due to packet reordering, a 0-RTT packet could arrive after a 1-RTT packet. Servers MAY temporarily retain 0-RTT keys to allow decrypting reordered packets without requiring their contents to be retransmitted with 1-RTT keys. After receiving a 1-RTT packet, servers MUST discard 0-RTT keys within a short time; the RECOMMENDED time period is three times the Probe Timeout (PTO, see [QUIC-RECOVERY]). A server MAY discard 0-RTT keys earlier if it determines that it has received all 0-RTT packets, which can be done by keeping track of missing packet numbers.
+
0-RTT and 1-RTT packets share the same packet number space, and clients do not send 0-RTT packets after sending a 1-RTT packet (Section 5.6).
+
Therefore, a client SHOULD discard 0-RTT keys as soon as it installs 1-RTT keys, since they have no use after that moment.
+
Additionally, a server MAY discard 0-RTT keys as soon as it receives a 1-RTT packet. However, due to packet reordering, a 0-RTT packet could arrive after a 1-RTT packet. Servers MAY temporarily retain 0-RTT keys to allow decrypting reordered packets without requiring their contents to be retransmitted with 1-RTT keys. After receiving a 1-RTT packet, servers MUST discard 0-RTT keys within a short time; the RECOMMENDED time period is three times the Probe Timeout (PTO, see [QUIC-RECOVERY]). A server MAY discard 0-RTT keys earlier if it determines that it has received all 0-RTT packets, which can be done by keeping track of missing packet numbers.
Once the handshake is confirmed, it is possible to update the keys. The KEY_PHASE bit in the short header is used to indicate whether key updates have occurred. The KEY_PHASE bit is initially set to 0 and then inverted with each key update.
The KEY_PHASE bit allows a recipient to detect a change in keying material without necessarily needing to receive the first packet that triggered the change. An endpoint that notices a changed KEY_PHASE bit can update keys and decrypt the packet that contains the changed bit.
-
This mechanism replaces the TLS KeyUpdate message. Endpoints MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt of a TLS KeyUpdate message as a connection error of type 0x10a, equivalent to a fatal TLS alert of unexpected_message (see Section 4.8).
+
This mechanism replaces the TLS KeyUpdate message. Endpoints MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt of a TLS KeyUpdate message as a connection error of type 0x10a, equivalent to a fatal TLS alert of unexpected_message (see Section 4.9).
An endpoint MUST NOT initiate the first key update until the handshake is confirmed (Section 4.1.2). An endpoint MUST NOT initiate a subsequent key update until it has received an acknowledgment for a packet sent at the current KEY_PHASE. This can be implemented by tracking the lowest packet number sent with each KEY_PHASE, and the highest acknowledged packet number in the 1-RTT space: once the latter is higher than or equal to the former, another key update can be initiated.
Endpoints MAY limit the number of keys they retain to two sets for removing packet protection and one set for protecting packets. Older keys can be discarded. Updating keys multiple times rapidly can cause packets to be effectively lost if packets are significantly reordered. Therefore, an endpoint SHOULD NOT initiate a key update for some time after it has last updated keys; the RECOMMENDED time period is three times the PTO. This avoids valid reordered packets being dropped by the peer as a result of the peer discarding older keys.
A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret (see Section 7.2 of [TLS13]) and the corresponding read key and IV using the KDF function provided by TLS. The header protection key is not updated.
QUIC requires that the cryptographic handshake provide authenticated protocol negotiation. TLS uses Application Layer Protocol Negotiation (ALPN) [RFC7301] to select an application protocol. Unless another mechanism is used for agreeing on an application protocol, endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in [QUIC-TRANSPORT]) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see Section 4.8). While [RFC7301] only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails.
+
QUIC requires that the cryptographic handshake provide authenticated protocol negotiation. TLS uses Application Layer Protocol Negotiation (ALPN) [RFC7301] to select an application protocol. Unless another mechanism is used for agreeing on an application protocol, endpoints MUST use ALPN for this purpose. When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in [QUIC-TRANSPORT]) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see Section 4.9). While [RFC7301] only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails.
An application-layer protocol MAY restrict the QUIC versions that it can operate over. Servers MUST select an application protocol compatible with the QUIC version that the client has selected. If the server cannot select a compatible combination of application protocol and QUIC version, it MUST abort the connection. A client MUST abort a connection if the server picks an application protocol incompatible with the protocol version being used.
The extension_data field of the quic_transport_parameters extension contains a value that is defined by the version of QUIC that is in use. The quic_transport_parameters extension carries a TransportParameters struct when the version of QUIC defined in [QUIC-TRANSPORT] is used.
-
The quic_transport_parameters extension is carried in the ClientHello and the EncryptedExtensions messages during the handshake. Endpoints MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST close the connection with an error of type 0x16d (equivalent to a fatal TLS missing_extension alert, see Section 4.8).
+
The quic_transport_parameters extension is carried in the ClientHello and the EncryptedExtensions messages during the handshake. Endpoints MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST close the connection with an error of type 0x16d (equivalent to a fatal TLS missing_extension alert, see Section 4.9).
While the transport parameters are technically available prior to the completion of the handshake, they cannot be fully trusted until the handshake completes, and reliance on them should be minimized. However, any tampering with the parameters will cause the handshake to fail.
Endpoints MUST NOT send this extension in a TLS connection that does not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A fatal unsupported_extension alert MUST be sent by an implementation that supports this extension if the extension is received when the transport is not QUIC.
Header protection relies on the packet protection AEAD being a pseudorandom function (PRF), which is not a property that AEAD algorithms guarantee. Therefore, no strong assurances about the general security of this mechanism can be shown in the general case. The AEAD algorithms described in this document are assumed to be PRFs.
-
The header protection algorithms defined in this document take the form:
+
[NAN] analyzes authenticated encryption algorithms which provide nonce privacy, referred to as “Hide Nonce” (HN) transforms. The general header protection construction in this document is one of those algorithms (HN1). Header protection uses the output of the packet protection AEAD to derive sample, and then encrypts the header field using a pseudorandom function (PRF) as follows:
protected_field = field XOR PRF(hp_key, sample)
-
This construction is secure against chosen plaintext attacks (IND-CPA) [IMC].
+
The header protection variants in this document use a pseudorandom permutation (PRP) in place of a generic PRF. However, since all PRPs are also PRFs [IMC], these variants do not deviate from the HN1 construction.
+
As hp_key is distinct from the packet protection key, it follows that header protection achieves AE2 security as defined in [NAN] and therefore guarantees privacy of field, the protected packet header. Future header protection variants based on this construction MUST use a PRF to ensure equivalent security guarantees.
Use of the same key and ciphertext sample more than once risks compromising header protection. Protecting two different headers with the same key and ciphertext sample reveals the exclusive OR of the protected fields. Assuming that the AEAD acts as a PRF, if L bits are sampled, the odds of two ciphertext samples being identical approach 2^(-L/2), that is, the birthday bound. For the algorithms described in this document, that probability is one in 2^64.
diff --git a/close3029/draft-ietf-quic-tls.txt b/ianswett-limit-bursts/draft-ietf-quic-tls.txt
similarity index 87%
rename from close3029/draft-ietf-quic-tls.txt
rename to ianswett-limit-bursts/draft-ietf-quic-tls.txt
index 297b96048f..61d6d25dcd 100644
--- a/close3029/draft-ietf-quic-tls.txt
+++ b/ianswett-limit-bursts/draft-ietf-quic-tls.txt
@@ -5,8 +5,8 @@
QUIC M. Thomson, Ed.
Internet-Draft Mozilla
Intended status: Standards Track S. Turner, Ed.
-Expires: March 19, 2020 sn3rd
- September 16, 2019
+Expires: April 19, 2020 sn3rd
+ October 17, 2019
Using TLS to Secure QUIC
@@ -42,7 +42,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on March 19, 2020.
+ This Internet-Draft will expire on April 19, 2020.
Copyright Notice
@@ -53,9 +53,9 @@ Copyright Notice
-Thomson & Turner Expires March 19, 2020 [Page 1]
+Thomson & Turner Expires April 19, 2020 [Page 1]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
This document is subject to BCP 78 and the IETF Trust's Legal
@@ -70,106 +70,111 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
2.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Carrying TLS Messages . . . . . . . . . . . . . . . . . . . . 8
- 4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9
+ 4.1. Interface to TLS . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Handshake Complete . . . . . . . . . . . . . . . . . 10
4.1.2. Handshake Confirmed . . . . . . . . . . . . . . . . . 10
4.1.3. Sending and Receiving Handshake Messages . . . . . . 10
4.1.4. Encryption Level Changes . . . . . . . . . . . . . . 12
4.1.5. TLS Interface Summary . . . . . . . . . . . . . . . . 13
4.2. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 14
- 4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 14
+ 4.3. ClientHello Size . . . . . . . . . . . . . . . . . . . . 15
4.4. Peer Authentication . . . . . . . . . . . . . . . . . . . 15
- 4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 15
+ 4.5. Enabling 0-RTT . . . . . . . . . . . . . . . . . . . . . 16
4.6. Accepting and Rejecting 0-RTT . . . . . . . . . . . . . . 16
- 4.7. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 16
- 4.8. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 16
- 4.9. Discarding Unused Keys . . . . . . . . . . . . . . . . . 17
- 4.9.1. Discarding Initial Keys . . . . . . . . . . . . . . . 17
- 4.9.2. Discarding Handshake Keys . . . . . . . . . . . . . . 18
- 4.9.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . . 18
- 5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 18
- 5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 18
- 5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 19
- 5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 20
- 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 21
- 5.4.1. Header Protection Application . . . . . . . . . . . . 22
- 5.4.2. Header Protection Sample . . . . . . . . . . . . . . 23
- 5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 24
- 5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 25
- 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 25
- 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 25
- 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 26
- 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 27
- 7. Security of Initial Messages . . . . . . . . . . . . . . . . 29
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 2]
+ 4.7. Validating 0-RTT Configuration . . . . . . . . . . . . . 17
+ 4.8. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 17
+ 4.9. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 18
+ 4.10. Discarding Unused Keys . . . . . . . . . . . . . . . . . 18
+ 4.10.1. Discarding Initial Keys . . . . . . . . . . . . . . 18
+ 4.10.2. Discarding Handshake Keys . . . . . . . . . . . . . 19
+ 4.10.3. Discarding 0-RTT Keys . . . . . . . . . . . . . . . 19
+ 5. Packet Protection . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.1. Packet Protection Keys . . . . . . . . . . . . . . . . . 20
+ 5.2. Initial Secrets . . . . . . . . . . . . . . . . . . . . . 20
+ 5.3. AEAD Usage . . . . . . . . . . . . . . . . . . . . . . . 21
+ 5.4. Header Protection . . . . . . . . . . . . . . . . . . . . 22
+ 5.4.1. Header Protection Application . . . . . . . . . . . . 23
+ 5.4.2. Header Protection Sample . . . . . . . . . . . . . . 25
+ 5.4.3. AES-Based Header Protection . . . . . . . . . . . . . 26
+ 5.4.4. ChaCha20-Based Header Protection . . . . . . . . . . 26
+ 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 27
+ 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 27
+ 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 28
+ 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 2]
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
- 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30
- 8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 30
- 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 30
- 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 31
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
- 9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 31
- 9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 32
- 9.3. Header Protection Analysis . . . . . . . . . . . . . . . 33
- 9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 34
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
- 11.1. Normative References . . . . . . . . . . . . . . . . . . 34
- 11.2. Informative References . . . . . . . . . . . . . . . . . 36
- 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
- Appendix A. Sample Initial Packet Protection . . . . . . . . . . 36
- A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 36
- A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 38
- A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 39
- Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 40
- B.1. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 40
- B.2. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 40
- B.3. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 40
- B.4. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 40
- B.5. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 41
- B.6. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 41
- B.7. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 41
- B.8. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 41
- B.9. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 42
- B.10. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 42
- B.11. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 42
- B.12. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 42
- B.13. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 42
- B.14. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 42
- B.15. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 42
- B.16. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 42
- B.17. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 42
- B.18. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 43
- B.19. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 43
- B.20. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 43
- Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
- Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 44
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
+ 7. Security of Initial Messages . . . . . . . . . . . . . . . . 30
+ 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 31
+ 8.1. Protocol Negotiation . . . . . . . . . . . . . . . . . . 31
+ 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 32
+ 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 32
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
+ 9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 33
+ 9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 34
+ 9.3. Header Protection Analysis . . . . . . . . . . . . . . . 34
+ 9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 35
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 37
+ 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 38
+ Appendix A. Sample Initial Packet Protection . . . . . . . . . . 38
+ A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 38
+ A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 39
+ A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 41
+ Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 42
+ B.1. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 42
+ B.2. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 42
+ B.3. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 42
+ B.4. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 42
+ B.5. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 43
+ B.6. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 43
+ B.7. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 43
+ B.8. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 43
+ B.9. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 44
+ B.10. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 44
+ B.11. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 44
+ B.12. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 44
+ B.13. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 44
+ B.14. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 44
+ B.15. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 44
+ B.16. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 44
+ B.17. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 44
+ B.18. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 45
+ B.19. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 45
+ B.20. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 45
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
+ Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 46
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
+
+
+
+
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 3]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
1. Introduction
This document describes how QUIC [QUIC-TRANSPORT] is secured using
TLS [TLS13].
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 3]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
TLS 1.3 provides critical latency improvements for connection
establishment over previous versions. Absent packet loss, most new
connections can be established and secured within a single round
@@ -212,19 +217,20 @@ Internet-Draft Using TLS to Secure QUIC September 2019
| |
+--------------------------------------------+
- Each upper layer (handshake, alerts, and application data) is carried
- as a series of typed TLS records. Records are individually
- cryptographically protected and then transmitted over a reliable
- transport (typically TCP) which provides sequencing and guaranteed
- delivery.
-Thomson & Turner Expires March 19, 2020 [Page 4]
+Thomson & Turner Expires April 19, 2020 [Page 4]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+ Each upper layer (handshake, alerts, and application data) is carried
+ as a series of typed TLS records. Records are individually
+ cryptographically protected and then transmitted over a reliable
+ transport (typically TCP) which provides sequencing and guaranteed
+ delivery.
Change Cipher Spec records cannot be sent in QUIC.
@@ -271,15 +277,9 @@ Internet-Draft Using TLS to Secure QUIC September 2019
-
-
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 5]
+Thomson & Turner Expires April 19, 2020 [Page 5]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
Client Server
@@ -333,9 +333,9 @@ Internet-Draft Using TLS to Secure QUIC September 2019
-Thomson & Turner Expires March 19, 2020 [Page 6]
+Thomson & Turner Expires April 19, 2020 [Page 6]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
+--------------+--------------+ +-------------+
@@ -389,18 +389,19 @@ Internet-Draft Using TLS to Secure QUIC September 2019
-Thomson & Turner Expires March 19, 2020 [Page 7]
+Thomson & Turner Expires April 19, 2020 [Page 7]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
- +------------+ +------------+
- | |<- Handshake Messages ->| |
- | |<---- 0-RTT Keys -------| |
- | |<--- Handshake Keys-----| |
- | QUIC |<---- 1-RTT Keys -------| TLS |
- | |<--- Handshake Done ----| |
- +------------+ +------------+
+ +------------+ +------------+
+ | |<---- Handshake Messages ----->| |
+ | |<- Validate 0-RTT parameters ->| |
+ | |<--------- 0-RTT Keys ---------| |
+ | QUIC |<------- Handshake Keys -------| TLS |
+ | |<--------- 1-RTT Keys ---------| |
+ | |<------- Handshake Done -------| |
+ +------------+ +------------+
| ^
| Protect | Protected
v | Packet
@@ -441,15 +442,17 @@ Internet-Draft Using TLS to Secure QUIC September 2019
at any encryption level, whereas those associated with transferring
data can only appear in the 0-RTT and 1-RTT encryption levels:
- o PADDING frames MAY appear in packets of any encryption level.
-Thomson & Turner Expires March 19, 2020 [Page 8]
+Thomson & Turner Expires April 19, 2020 [Page 8]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
+ o PADDING and PING frames MAY appear in packets of any encryption
+ level.
+
o CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any
encryption level except 0-RTT.
@@ -491,20 +494,27 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Section 17 of [QUIC-TRANSPORT] shows how packets at the various
encryption levels fit into the handshake process.
-4.1. Interface to TLS
- As shown in Figure 2, the interface from QUIC to TLS consists of
- three primary functions:
- o Sending and receiving handshake messages
-Thomson & Turner Expires March 19, 2020 [Page 9]
+
+Thomson & Turner Expires April 19, 2020 [Page 9]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+4.1. Interface to TLS
+
+ As shown in Figure 2, the interface from QUIC to TLS consists of four
+ primary functions:
+
+ o Sending and receiving handshake messages
+
+ o Processing stored transport and application state from a resumed
+ session and determining if it is valid to accept early data
o Rekeying (both transmit and receive)
@@ -545,32 +555,37 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Before starting the handshake QUIC provides TLS with the transport
parameters (see Section 8.2) that it wishes to carry.
- A QUIC client starts TLS by requesting TLS handshake bytes from TLS.
- The client acquires handshake bytes before sending its first packet.
- A QUIC server starts the process by providing TLS with the client's
- handshake bytes.
-
- At any given time, the TLS stack at an endpoint will have a current
- sending encryption level and receiving encryption level. Each
- encryption level is associated with a different flow of bytes, which
- is reliably transmitted to the peer in CRYPTO frames. When TLS
-
-Thomson & Turner Expires March 19, 2020 [Page 10]
+Thomson & Turner Expires April 19, 2020 [Page 10]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+ A QUIC client starts TLS by requesting TLS handshake bytes from TLS.
+ The client acquires handshake bytes before sending its first packet.
+ A QUIC server starts the process by providing TLS with the client's
+ handshake bytes.
- provides handshake bytes to be sent, they are appended to the current
- flow and any packet that includes the CRYPTO frame is protected using
- keys from the corresponding encryption level.
+ At any time, the TLS stack at an endpoint will have a current sending
+ encryption level and receiving encryption level. Each encryption
+ level is associated with a different flow of bytes, which is reliably
+ transmitted to the peer in CRYPTO frames. When TLS provides
+ handshake bytes to be sent, they are appended to the current flow and
+ any packet that includes the CRYPTO frame is protected using keys
+ from the corresponding encryption level.
QUIC takes the unprotected content of TLS handshake records as the
content of CRYPTO frames. TLS record protection is not used by QUIC.
QUIC assembles CRYPTO frames into QUIC packets, which are protected
using QUIC packet protection.
+ QUIC is only capable of conveying TLS handshake records in CRYPTO
+ frames. TLS alerts are turned into QUIC CONNECTION_CLOSE error
+ codes; see Section 4.9. TLS application data and other message types
+ cannot be carried by QUIC at any encryption level and is an error if
+ they are received from the TLS stack.
+
When an endpoint receives a QUIC packet containing a CRYPTO frame
from the network, it proceeds as follows:
@@ -593,6 +608,16 @@ Internet-Draft Using TLS to Secure QUIC September 2019
previous encryption level that TLS has not consumed, this MUST be
treated as a connection error of type PROTOCOL_VIOLATION.
+
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 11]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
Each time that TLS is provided with new data, new handshake bytes are
requested from TLS. TLS might not provide any bytes if the handshake
messages it has received are incomplete or it has no data to send.
@@ -609,15 +634,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
might wish to provide additional or updated session tickets to a
client.
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 11]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
When the handshake is complete, QUIC only needs to provide TLS with
any data that arrives in CRYPTO streams. In the same way that is
done during the handshake, new data is requested from TLS after
@@ -650,6 +666,14 @@ Internet-Draft Using TLS to Secure QUIC September 2019
ClientHello message or the server receives that message. After
providing a QUIC client with the first handshake bytes, the TLS stack
might signal the change to 0-RTT keys. On the server, after
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 12]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
receiving handshake bytes that contain a ClientHello message, a TLS
server might signal that 0-RTT keys are available.
@@ -666,14 +690,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
In particular, server implementations need to be able to read packets
at the Handshake encryption level at the same time as the 0-RTT
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 12]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
encryption level. A client could interleave ACK frames that are
protected with Handshake keys with 0-RTT data and the server needs to
process those acknowledgments in order to detect lost Handshake
@@ -691,6 +707,29 @@ Internet-Draft Using TLS to Secure QUIC September 2019
and server. Each arrow is tagged with the encryption level used for
that transmission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 13]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
Client Server
Get Handshake
@@ -723,13 +762,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Figure 3: Interaction Summary between QUIC and TLS
-
-
-Thomson & Turner Expires March 19, 2020 [Page 13]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
Figure 3 shows the multiple packets that form a single "flight" of
messages being processed individually, to show what incoming messages
trigger different actions. New handshake messages are requested
@@ -747,6 +779,13 @@ Internet-Draft Using TLS to Secure QUIC September 2019
acceptable provided that the features of TLS 1.3 that are used by
QUIC are supported by the newer version.
+
+
+Thomson & Turner Expires April 19, 2020 [Page 14]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
A badly configured TLS implementation could negotiate TLS 1.2 or
another older version of TLS. An endpoint MUST terminate the
connection if a version of TLS older than 1.3 is negotiated.
@@ -779,13 +818,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
connect. Minimizing the size of these values increases the
probability that they can be successfully used by a client.
-
-
-Thomson & Turner Expires March 19, 2020 [Page 14]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
A client is not required to fit the ClientHello that it sends in
response to a HelloRetryRequest message into a single UDP datagram.
@@ -801,6 +833,15 @@ Internet-Draft Using TLS to Secure QUIC September 2019
A client MUST authenticate the identity of the server. This
typically involves verification that the identity of the server is
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 15]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
included in a certificate and that the certificate is issued by a
trusted entity (see for example [RFC2818]).
@@ -809,39 +850,32 @@ Internet-Draft Using TLS to Secure QUIC September 2019
to authenticate when requested. The requirements for client
authentication vary based on application protocol and deployment.
- A server MUST NOT use post-handshake client authentication (see
- Section 4.6.2 of [TLS13]).
+ A server MUST NOT use post-handshake client authentication (as
+ defined in Section 4.6.2 of [TLS13]), because the multiplexing
+ offered by QUIC prevents clients from correlating the certificate
+ request with the application-level event that triggered it (see
+ [HTTP2-TLS13]). More specifically, servers MUST NOT send post-
+ handshake TLS CertificateRequest messages and clients MUST treat
+ receipt of such messages as a connection error of type
+ PROTOCOL_VIOLATION.
4.5. Enabling 0-RTT
- In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket
- message that contains the "early_data" extension with a
- max_early_data_size of 0xffffffff; the amount of data which the
- client can send in 0-RTT is controlled by the "initial_max_data"
- transport parameter supplied by the server. A client MUST treat
- receipt of a NewSessionTicket that contains an "early_data" extension
- with any other value as a connection error of type
- PROTOCOL_VIOLATION.
+ To communicate their willingness to process 0-RTT data, servers send
+ a NewSessionTicket message that contains the "early_data" extension
+ with a max_early_data_size of 0xffffffff; the amount of data which
+ the client can send in 0-RTT is controlled by the "initial_max_data"
+ transport parameter supplied by the server. Servers MUST NOT send
+ the "early_data" extension with a max_early_data_size set to any
+ value other than 0xffffffff. A client MUST treat receipt of a
+ NewSessionTicket that contains an "early_data" extension with any
+ other value as a connection error of type PROTOCOL_VIOLATION.
A client that wishes to send 0-RTT packets uses the "early_data"
extension in the ClientHello message of a subsequent handshake (see
Section 4.2.10 of [TLS13]). It then sends the application data in
0-RTT packets.
- Early data within the TLS connection MUST NOT be used. As it is for
- other TLS application data, a server MUST treat receiving early data
- on the TLS connection as a connection error of type
- PROTOCOL_VIOLATION.
-
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 15]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
4.6. Accepting and Rejecting 0-RTT
A server accepts 0-RTT by sending an early_data extension in the
@@ -856,6 +890,14 @@ Internet-Draft Using TLS to Secure QUIC September 2019
0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition.
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 16]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
When 0-RTT is rejected, all connection characteristics that the
client assumed might be incorrect. This includes the choice of
application protocol, transport parameters, and any application
@@ -866,7 +908,30 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Version Negotiation packet. These packets do not signify rejection
of 0-RTT.
-4.7. HelloRetryRequest
+4.7. Validating 0-RTT Configuration
+
+ When a server receives a ClientHello with the "early_data" extension,
+ it has to decide whether to accept or reject early data from the
+ client. Some of this decision is made by the TLS stack (e.g.,
+ checking that the cipher suite being resumed was included in the
+ ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack
+ has no reason to reject early data, the QUIC stack or the application
+ protocol using QUIC might reject early data because the configuration
+ of the transport or application associated with the resumed session
+ is not compatible with the server's current configuration.
+
+ QUIC requires additional transport state to be associated with a
+ 0-RTT session ticket. One common way to implement this is using
+ stateless session tickets and storing this state in the session
+ ticket. Application protocols that use QUIC might have similar
+ requirements regarding associating or storing state. This associated
+ state is used for deciding whether early data must be rejected. For
+ example, HTTP/3 ([QUIC-HTTP]) settings determine how early data from
+ the client is interpreted. Other applications using QUIC could have
+ different requirements for determining whether to accept or reject
+ early data.
+
+4.8. HelloRetryRequest
In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of
[TLS13]) can be used to correct a client's incorrect KeyShare
@@ -878,7 +943,18 @@ Internet-Draft Using TLS to Secure QUIC September 2019
of [QUIC-TRANSPORT]). HelloRetryRequest is still used to request key
shares.
-4.8. TLS Errors
+
+
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 17]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
+4.9. TLS Errors
If TLS experiences an error, it generates an appropriate alert as
defined in Section 6 of [TLS13].
@@ -889,19 +965,10 @@ Internet-Draft Using TLS to Secure QUIC September 2019
range reserved for CRYPTO_ERROR. The resulting value is sent in a
QUIC CONNECTION_CLOSE frame.
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 16]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
generate alerts at the "warning" level.
-4.9. Discarding Unused Keys
+4.10. Discarding Unused Keys
After QUIC moves to a new encryption level, packet protection keys
for previous encryption levels can be discarded. This occurs several
@@ -930,11 +997,19 @@ Internet-Draft Using TLS to Secure QUIC September 2019
and retransmissions of data in CRYPTO frames are sent at a previous
encryption level. These packets MAY also include PADDING frames.
-4.9.1. Discarding Initial Keys
+4.10.1. Discarding Initial Keys
Packets protected with Initial secrets (Section 5.2) are not
authenticated, meaning that an attacker could spoof packets with the
intent to disrupt a connection. To limit these attacks, Initial
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 18]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
packet protection keys can be discarded more aggressively than other
keys.
@@ -946,18 +1021,10 @@ Internet-Draft Using TLS to Secure QUIC September 2019
successfully processes a Handshake packet. Endpoints MUST NOT send
Initial packets after this point.
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 17]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
This results in abandoning loss recovery state for the Initial
encryption level and ignoring any outstanding Initial packets.
-4.9.2. Discarding Handshake Keys
+4.10.2. Discarding Handshake Keys
An endpoint MUST NOT discard its handshake keys until the TLS
handshake is confirmed (Section 4.1.2). An endpoint SHOULD discard
@@ -969,7 +1036,7 @@ Internet-Draft Using TLS to Secure QUIC September 2019
frames, such as PING, which will cause the handshake to be confirmed
when they are acknowledged.
-4.9.3. Discarding 0-RTT Keys
+4.10.3. Discarding 0-RTT Keys
0-RTT and 1-RTT packets share the same packet number space, and
clients do not send 0-RTT packets after sending a 1-RTT packet
@@ -989,6 +1056,16 @@ Internet-Draft Using TLS to Secure QUIC September 2019
determines that it has received all 0-RTT packets, which can be done
by keeping track of missing packet numbers.
+
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 19]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
5. Packet Protection
As with TLS over TCP, QUIC protects packets with keys derived from
@@ -1002,14 +1079,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Each encryption level has separate secret values for protection of
packets sent in each direction. These traffic secrets are derived by
TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 18]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
encryption levels except the Initial encryption level. The secrets
for the Initial encryption level are computed based on the client's
initial Destination Connection ID, as described in Section 5.2.
@@ -1046,6 +1115,13 @@ Internet-Draft Using TLS to Secure QUIC September 2019
"server in", "",
Hash.length)
+
+
+Thomson & Turner Expires April 19, 2020 [Page 20]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
The hash function for HKDF when deriving initial secrets and keys is
SHA-256 [SHA].
@@ -1058,14 +1134,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
The value of initial_salt is a 20 byte sequence shown in the figure
in hexadecimal notation. Future versions of QUIC SHOULD generate a
new salt value, thus ensuring that the keys are different for each
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 19]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
version of QUIC. This prevents a middlebox that only recognizes one
version of QUIC from seeing or modifying the contents of packets from
future versions.
@@ -1101,6 +1169,15 @@ Internet-Draft Using TLS to Secure QUIC September 2019
shared secret, packets are protected with AEAD_AES_128_GCM and a key
derived from the Destination Connection ID in the client's first
Initial packet (see Section 5.2). This provides protection against
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 21]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
off-path attackers and robustness against QUIC version unaware
middleboxes, but not against on-path attackers.
@@ -1113,15 +1190,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
authentication tag and produce an output 16 bytes larger than their
input.
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 20]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
Note: An endpoint MUST NOT reject a ClientHello that offers a
ciphersuite that it does not support, or it would be impossible to
deploy a new ciphersuite. This also applies to
@@ -1157,6 +1225,15 @@ Internet-Draft Using TLS to Secure QUIC September 2019
used to provide confidentiality protection for those fields that are
not exposed to on-path elements.
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 22]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
This protection applies to the least-significant bits of the first
byte, plus the Packet Number field. The four least-significant bits
of the first byte are protected for packets with long headers; the
@@ -1170,14 +1247,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Section 6). This allows header protection to be used to protect the
key phase.
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 21]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
This process does not apply to Retry or Version Negotiation packets,
which do not contain a protected payload or any of the fields that
are protected by this process.
@@ -1200,23 +1269,10 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Removing header protection only differs in the order in which the
packet number length (pn_length) is determined.
- mask = header_protection(hp_key, sample)
- pn_length = (packet[0] & 0x03) + 1
- if (packet[0] & 0x80) == 0x80:
- # Long header: 4 bits masked
- packet[0] ^= mask[0] & 0x0f
- else:
- # Short header: 5 bits masked
- packet[0] ^= mask[0] & 0x1f
- # pn_offset is the start of the Packet Number field.
- packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]
- Figure 4: Header Protection Pseudocode
- Figure 5 shows the protected fields of long and short headers marked
- with an E. Figure 5 also shows the sampled fields.
@@ -1229,10 +1285,28 @@ Internet-Draft Using TLS to Secure QUIC September 2019
-Thomson & Turner Expires March 19, 2020 [Page 22]
+Thomson & Turner Expires April 19, 2020 [Page 23]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
+ mask = header_protection(hp_key, sample)
+
+ pn_length = (packet[0] & 0x03) + 1
+ if (packet[0] & 0x80) == 0x80:
+ # Long header: 4 bits masked
+ packet[0] ^= mask[0] & 0x0f
+ else:
+ # Short header: 5 bits masked
+ packet[0] ^= mask[0] & 0x1f
+
+ # pn_offset is the start of the Packet Number field.
+ packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]
+
+ Figure 4: Header Protection Pseudocode
+ Figure 5 shows the protected fields of long and short headers marked
+ with an E. Figure 5 also shows the sampled fields.
Long Header:
+-+-+-+-+-+-+-+-+
@@ -1264,6 +1338,14 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Before a TLS ciphersuite can be used with QUIC, a header protection
algorithm MUST be specified for the AEAD used with that ciphersuite.
This document defines algorithms for AEAD_AES_128_GCM,
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 24]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in
[AEAD]), and AEAD_CHACHA20_POLY1305 [CHACHA]. Prior to TLS selecting
a ciphersuite, AES header protection is used (Section 5.4.3),
@@ -1283,13 +1365,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
An endpoint MUST discard packets that are not long enough to contain
a complete sample.
-
-
-Thomson & Turner Expires March 19, 2020 [Page 23]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
To ensure that sufficient data is available for sampling, packets are
padded so that the combined lengths of the encoded packet number and
protected payload is at least 4 bytes longer than the sample required
@@ -1316,6 +1391,17 @@ Internet-Draft Using TLS to Secure QUIC September 2019
multiple QUIC packets might be included in the same UDP datagram and
that each one is handled separately.
+
+
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 25]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
sample_offset = 7 + len(destination_connection_id) +
len(source_connection_id) +
len(payload_length) + 4
@@ -1338,14 +1424,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
mask = AES-ECB(hp_key, sample)
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 24]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
5.4.4. ChaCha20-Based Header Protection
When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw
@@ -1369,6 +1447,17 @@ Internet-Draft Using TLS to Secure QUIC September 2019
nonce = sample[4..15]
mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})
+
+
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 26]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
5.5. Receiving Protected Packets
Once an endpoint successfully receives a packet with a given packet
@@ -1393,15 +1482,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
A client MUST only use 0-RTT keys to protect data that is idempotent.
A client MAY wish to apply additional restrictions on what data it
sends prior to the completion of the TLS handshake. A client
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 25]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
otherwise treats 0-RTT keys as equivalent to 1-RTT keys, except that
it MUST NOT send ACKs with 0-RTT keys.
@@ -1425,6 +1505,15 @@ Internet-Draft Using TLS to Secure QUIC September 2019
protection cannot be derived until the client receives all server
handshake messages.
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 27]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
5.7. Receiving Out-of-Order Protected Frames
Due to reordering and loss, protected packets might be received by an
@@ -1450,14 +1539,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Therefore, the server's use of 1-RTT keys is limited before the
handshake is complete. A server MUST NOT process data from incoming
1-RTT protected packets before the TLS handshake is complete.
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 26]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
Because sending acknowledgments indicates that all frames in a packet
have been processed, a server cannot send acknowledgments for 1-RTT
packets until the TLS handshake is complete. Received packets
@@ -1480,6 +1561,15 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Once the handshake is confirmed, it is possible to update the keys.
The KEY_PHASE bit in the short header is used to indicate whether key
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 28]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
updates have occurred. The KEY_PHASE bit is initially set to 0 and
then inverted with each key update.
@@ -1493,7 +1583,7 @@ Internet-Draft Using TLS to Secure QUIC September 2019
NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt
of a TLS KeyUpdate message as a connection error of type 0x10a,
equivalent to a fatal TLS alert of unexpected_message (see
- Section 4.8).
+ Section 4.9).
An endpoint MUST NOT initiate the first key update until the
handshake is confirmed (Section 4.1.2). An endpoint MUST NOT
@@ -1506,14 +1596,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Endpoints MAY limit the number of keys they retain to two sets for
removing packet protection and one set for protecting packets. Older
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 27]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
keys can be discarded. Updating keys multiple times rapidly can
cause packets to be effectively lost if packets are significantly
reordered. Therefore, an endpoint SHOULD NOT initiate a key update
@@ -1535,6 +1617,15 @@ Internet-Draft Using TLS to Secure QUIC September 2019
key phase, it MUST NOT send a packet encrypted with an older key
phase.
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 29]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
An endpoint does not always need to send packets when it detects that
its peer has updated keys. The next packet that it sends will simply
use the new keys. If an endpoint detects a second update before it
@@ -1555,21 +1646,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
there are multiple key updates in a short time frame succession and
significant packet reordering.
-
-
-
-
-
-
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 28]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
Initiating Peer Responding Peer
@M QUIC Frames
@@ -1598,6 +1674,14 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Initial packets are not protected with a secret key, so they are
subject to potential tampering by an attacker. QUIC provides
protection against attackers that cannot read packets, but does not
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 30]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
attempt to provide additional protection against attacks where the
attacker can observe and inject packets. Some forms of tampering -
such as modifying the TLS messages themselves - are detectable, but
@@ -1616,16 +1700,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
modifying TLS handshake messages, that tampering will cause the TLS
handshake to fail.
-
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 29]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
8. QUIC-Specific Additions to the TLS Handshake
QUIC uses the TLS handshake for more than just negotiation of
@@ -1643,7 +1717,7 @@ Internet-Draft Using TLS to Secure QUIC September 2019
endpoints MUST immediately close a connection (see Section 10.3 in
[QUIC-TRANSPORT]) if an application protocol is not negotiated with a
no_application_protocol TLS alert (QUIC error code 0x178, see
- Section 4.8). While [RFC7301] only specifies that servers use this
+ Section 4.9). While [RFC7301] only specifies that servers use this
alert, QUIC clients MUST also use it to terminate a connection when
ALPN negotiation fails.
@@ -1655,6 +1729,15 @@ Internet-Draft Using TLS to Secure QUIC September 2019
MUST abort a connection if the server picks an application protocol
incompatible with the protocol version being used.
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 31]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
8.2. QUIC Transport Parameters Extension
QUIC transport parameters are carried in a TLS extension. Different
@@ -1673,22 +1756,13 @@ Internet-Draft Using TLS to Secure QUIC September 2019
TransportParameters struct when the version of QUIC defined in
[QUIC-TRANSPORT] is used.
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 30]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
The quic_transport_parameters extension is carried in the ClientHello
and the EncryptedExtensions messages during the handshake. Endpoints
MUST send the quic_transport_parameters extension; endpoints that
receive ClientHello or EncryptedExtensions messages without the
quic_transport_parameters extension MUST close the connection with an
error of type 0x16d (equivalent to a fatal TLS missing_extension
- alert, see Section 4.8).
+ alert, see Section 4.9).
While the transport parameters are technically available prior to the
completion of the handshake, they cannot be fully trusted until the
@@ -1712,6 +1786,14 @@ Internet-Draft Using TLS to Secure QUIC September 2019
treat receipt of a CRYPTO frame in a 0-RTT packet as a connection
error of type PROTOCOL_VIOLATION.
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 32]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
As a result, EndOfEarlyData does not appear in the TLS handshake
transcript.
@@ -1730,14 +1812,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
with an exposure to replay attack. The use of 0-RTT in QUIC is
similarly vulnerable to replay attack.
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 31]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
Endpoints MUST implement and use the replay protections described in
[TLS13], however it is recognized that these protections are
imperfect. Therefore, additional consideration of the risk of replay
@@ -1767,6 +1841,15 @@ Internet-Draft Using TLS to Secure QUIC September 2019
attacks with 0-RTT lies with an application protocol. An application
protocol that uses QUIC MUST describe how the protocol uses 0-RTT and
the measures that are employed to protect against replay attack. An
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 33]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
analysis of replay risk needs to consider all QUIC protocol features
that carry application semantics.
@@ -1786,14 +1869,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
QUIC includes three defenses against this attack. First, the packet
containing a ClientHello MUST be padded to a minimum size. Second,
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 32]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
if responding to an unverified source address, the server is
forbidden to send more than three UDP datagrams in its first flight
(see Section 8.1 of [QUIC-TRANSPORT]). Finally, because
@@ -1803,20 +1878,33 @@ Internet-Draft Using TLS to Secure QUIC September 2019
9.3. Header Protection Analysis
- Header protection relies on the packet protection AEAD being a
- pseudorandom function (PRF), which is not a property that AEAD
- algorithms guarantee. Therefore, no strong assurances about the
- general security of this mechanism can be shown in the general case.
- The AEAD algorithms described in this document are assumed to be
- PRFs.
-
- The header protection algorithms defined in this document take the
- form:
+ [NAN] analyzes authenticated encryption algorithms which provide
+ nonce privacy, referred to as "Hide Nonce" (HN) transforms. The
+ general header protection construction in this document is one of
+ those algorithms (HN1). Header protection uses the output of the
+ packet protection AEAD to derive "sample", and then encrypts the
+ header field using a pseudorandom function (PRF) as follows:
protected_field = field XOR PRF(hp_key, sample)
- This construction is secure against chosen plaintext attacks (IND-
- CPA) [IMC].
+ The header protection variants in this document use a pseudorandom
+ permutation (PRP) in place of a generic PRF. However, since all PRPs
+ are also PRFs [IMC], these variants do not deviate from the HN1
+ construction.
+
+ As "hp_key" is distinct from the packet protection key, it follows
+ that header protection achieves AE2 security as defined in [NAN] and
+ therefore guarantees privacy of "field", the protected packet header.
+ Future header protection variants based on this construction MUST use
+ a PRF to ensure equivalent security guarantees.
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 34]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
Use of the same key and ciphertext sample more than once risks
compromising header protection. Protecting two different headers
@@ -1842,14 +1930,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
numbers without attempting to remove packet protection they could
reveal through timing side-channels that the packet number matches a
received packet. For authentication to be free from side-channels,
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 33]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
the entire process of header protection removal, packet number
recovery, and packet protection removal MUST be applied together
without timing and other side-channels.
@@ -1874,6 +1954,14 @@ Internet-Draft Using TLS to Secure QUIC September 2019
To preserve this separation, a new version of QUIC SHOULD define new
labels for key derivation for packet protection key and IV, plus the
header protection keys. This version of QUIC uses the string "quic".
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 35]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
Other versions can use a version-specific label in place of that
string.
@@ -1899,13 +1987,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
.
-
-
-Thomson & Turner Expires March 19, 2020 [Page 34]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
[AES] "Advanced encryption standard (AES)", National Institute
of Standards and Technology report,
DOI 10.6028/nist.fips.197, November 2001.
@@ -1917,18 +1998,26 @@ Internet-Draft Using TLS to Secure QUIC September 2019
[QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery (work in
- progress), September 2019.
+ progress), October 2019.
[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic-
- transport (work in progress), September 2019.
+ transport (work in progress), October 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 36]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
@@ -1951,17 +2040,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
.
-
-
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 35]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
11.2. Informative References
[AEBounds]
@@ -1969,15 +2047,33 @@ Internet-Draft Using TLS to Secure QUIC September 2019
Encryption Use in TLS", March 2016,
.
+ [HTTP2-TLS13]
+ Benjamin, D., "Using TLS 1.3 with HTTP/2", draft-ietf-
+ httpbis-http2-tls13-02 (work in progress), September 2019.
+
[IMC] Katz, J. and Y. Lindell, "Introduction to Modern
Cryptography, Second Edition", ISBN 978-1466570269,
November 2014.
+ [NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
+ AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.
+ 235-265, DOI 10.1007/978-3-030-26948-7_9, 2019.
+
[QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
- QUIC", draft-ietf-quic-http (work in progress), September
+ QUIC", draft-ietf-quic-http (work in progress), October
2019.
+
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 37]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
.
@@ -2010,14 +2106,6 @@ A.1. Keys
client in: 00200f746c73313320636c69656e7420696e00
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 36]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
server in: 00200f746c7331332073657276657220696e00
quic key: 00100e746c7331332071756963206b657900
@@ -2034,6 +2122,14 @@ Internet-Draft Using TLS to Secure QUIC September 2019
The secrets for protecting client packets are:
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 38]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
client_initial_secret
= HKDF-Expand-Label(initial_secret, "client in", _, 32)
= fda3953aecc040e48b34e27ef87de3a6
@@ -2064,16 +2160,6 @@ Internet-Draft Using TLS to Secure QUIC September 2019
hp = HKDF-Expand-Label(server_initial_secret, "quic hp", _, 16)
= a8ed82e6664f865aedf6106943f95fb8
-
-
-
-
-
-Thomson & Turner Expires March 19, 2020 [Page 37]
-
-Internet-Draft Using TLS to Secure QUIC September 2019
-
-
A.2. Client Initial
The client sends an Initial packet. The unprotected payload of this
@@ -2093,6 +2179,13 @@ A.2. Client Initial
c3ff000017088394c8f03e5157080000449e00000002
+
+
+Thomson & Turner Expires April 19, 2020 [Page 39]
+
+Internet-Draft Using TLS to Secure QUIC October 2019
+
+
Protecting the payload produces output that is sampled for header
protection. Because the header uses a 4 byte packet number encoding,
the first 16 bytes of the protected payload is sampled, then applied
@@ -2125,9 +2218,28 @@ A.2. Client Initial
-Thomson & Turner Expires March 19, 2020 [Page 38]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson & Turner Expires April 19, 2020 [Page 40]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
c0ff000017088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c
@@ -2181,9 +2293,9 @@ A.3. Server Initial
-Thomson & Turner Expires March 19, 2020 [Page 39]
+Thomson & Turner Expires April 19, 2020 [Page 41]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
The header from the server includes a new connection ID and a 2-byte
@@ -2237,9 +2349,9 @@ B.4. Since draft-ietf-quic-tls-18
-Thomson & Turner Expires March 19, 2020 [Page 40]
+Thomson & Turner Expires April 19, 2020 [Page 42]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
B.5. Since draft-ietf-quic-tls-17
@@ -2293,9 +2405,9 @@ B.8. Since draft-ietf-quic-tls-12
-Thomson & Turner Expires March 19, 2020 [Page 41]
+Thomson & Turner Expires April 19, 2020 [Page 43]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
* Limit the use of HelloRetryRequest to address TLS needs (like
@@ -2349,9 +2461,9 @@ B.17. Since draft-ietf-quic-tls-02
-Thomson & Turner Expires March 19, 2020 [Page 42]
+Thomson & Turner Expires April 19, 2020 [Page 44]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
B.18. Since draft-ietf-quic-tls-01
@@ -2405,9 +2517,9 @@ B.20. Since draft-thomson-quic-tls-01
-Thomson & Turner Expires March 19, 2020 [Page 43]
+Thomson & Turner Expires April 19, 2020 [Page 45]
-Internet-Draft Using TLS to Secure QUIC September 2019
+Internet-Draft Using TLS to Secure QUIC October 2019
Acknowledgments
@@ -2461,4 +2573,4 @@ Authors' Addresses
-Thomson & Turner Expires March 19, 2020 [Page 44]
+Thomson & Turner Expires April 19, 2020 [Page 46]
diff --git a/close3029/draft-ietf-quic-transport.html b/ianswett-limit-bursts/draft-ietf-quic-transport.html
similarity index 98%
rename from close3029/draft-ietf-quic-transport.html
rename to ianswett-limit-bursts/draft-ietf-quic-transport.html
index dde48f0b93..30378576b4 100644
--- a/close3029/draft-ietf-quic-transport.html
+++ b/ianswett-limit-bursts/draft-ietf-quic-transport.html
@@ -472,12 +472,12 @@
-
+
-
+
@@ -501,12 +501,12 @@
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-
This Internet-Draft will expire on March 19, 2020.
+
This Internet-Draft will expire on April 19, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
@@ -1001,6 +1001,8 @@
The transport protocol described by this document. QUIC is a name, not an acronym.
QUIC packet:
A complete processable unit of QUIC that can be encapsulated in a UDP datagram. Multiple QUIC packets can be encapsulated in a single UDP datagram.
+
Ack-eliciting Packet:
+
A QUIC packet that contains frames other than ACK and PADDING. These cause a recipient to send an acknowledgment (see Section 13.2.1).
Endpoint:
An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets. There are only two types of endpoint in QUIC: client and server.
If the idle timeout is enabled, a connection is silently closed and the state is discarded when it remains idle for longer than both the advertised idle timeout (see Section 18.2) and three times the current Probe Timeout (PTO).
-
Each endpoint advertises its own idle timeout to its peer. An endpoint restarts any timer it maintains when a packet from its peer is received and processed successfully. The timer is also restarted when sending a packet containing frames other than ACK or PADDING (an ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK-eliciting packets have been sent since last receiving a packet. Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity.
+
Each endpoint advertises its own idle timeout to its peer. An endpoint restarts any timer it maintains when a packet from its peer is received and processed successfully. The timer is also restarted when sending a packet containing frames other than ACK or PADDING (an ack-eliciting packet; see [QUIC-RECOVERY]), but only if no other ack-eliciting packets have been sent since last receiving a packet. Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity.
The value for an idle timeout can be asymmetric. The value advertised by an endpoint is only used to determine whether the connection is live at that endpoint. An endpoint that sends packets near the end of the idle timeout period of a peer risks having those packets discarded if its peer enters the draining state before the packets arrive. If a peer could timeout within a Probe Timeout (PTO; see Section 6.3 of [QUIC-RECOVERY]), it is advisable to test for liveness before sending any data that cannot be retried safely. Note that it is likely that only applications or application protocols will know what information can be retried.
A stateless reset is provided as an option of last resort for an endpoint that does not have access to the state of a connection. A crash or outage might result in peers continuing to send data to an endpoint that is unable to properly continue the connection. An endpoint MAY send a stateless reset in response to receiving a packet that it cannot associate with an active connection.
A stateless reset is not appropriate for signaling error conditions. An endpoint that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE frame if it has sufficient state to do so.
-
To support this process, a token is sent by endpoints. The token is carried in 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 are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (Section 19.16).
+
To support this process, a token is sent by endpoints. The token is carried in the Stateless Reset Token field of a NEW_CONNECTION_ID frame. Servers can also specify a stateless_reset_token transport parameter during the handshake that applies to the connection ID that it selected during the handshake; clients cannot use this transport parameter because their transport parameters don’t have confidentiality protection. These tokens are protected by encryption, so only client and server know their value. Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (Section 19.16).
An endpoint that receives packets that it cannot process sends a packet in the following layout:
An endpoint detects a potential stateless reset when an incoming packet either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet. The endpoint MUST then compare the last 16 bytes of the packet with all Stateless Reset Tokens that are associated with connection IDs that the endpoint recently used to send packets from the IP address and port on which the datagram is received. This includes Stateless Reset Tokens from NEW_CONNECTION_ID frames and the server’s transport parameters. An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired.
+
An endpoint detects a potential stateless reset when an incoming packet either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet. The endpoint MUST then compare the last 16 bytes of the packet with all Stateless Reset Tokens corresponding to active connection IDs that the endpoint has used for sending packets to the IP address and port on which the datagram is received. This includes Stateless Reset Tokens from NEW_CONNECTION_ID frames and the server’s transport parameters. An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired.
If the last 16 bytes of the packet values are identical to a Stateless Reset Token, the endpoint MUST enter the draining period and not send any further packets on this connection. If the comparison fails, the packet can be discarded.
An endpoint that loses state can use the same method to generate a valid Stateless Reset Token. The connection ID comes from the packet that the endpoint receives.
This design relies on the peer always sending a connection ID in its packets so that the endpoint can use the connection ID from a packet to reset the connection. An endpoint that uses this design MUST either use the same connection ID length for all connections or encode the length of the connection ID such that it can be recovered without state. In addition, it cannot provide a zero-length connection ID.
Revealing the Stateless Reset Token allows any entity to terminate the connection, so a value can only be used once. This method for choosing the Stateless Reset Token means that the combination of connection ID and static key MUST NOT be used for another connection. A denial of service attack is possible if the same connection ID is used by instances that share a static key, or if an attacker can cause a packet to be routed to an instance that has no state but the same static key; see Section 21.9. A connection ID from a connection that is reset by revealing the Stateless Reset Token MUST NOT be reused for new connections at nodes that share a static key.
-
The same Stateless Reset Token MAY be used for multiple connection IDs on the same connection. However, reuse of a Stateless Reset Token might expose an endpoint to denial of service if associated connection IDs are forgotten while the associated token is still active at a peer. An endpoint MUST ensure that packets with Destination Connection ID field values that correspond to a reused Stateless Reset Token are attributed to the same connection as long as the Stateless Reset Token is still usable, even when the connection ID has been retired. Otherwise, an attacker might be able to send a packet with a retired connection ID and cause the endpoint to produce a Stateless Reset that it can use to disrupt the connection, just as with the attacks in Section 21.9.
+
The same Stateless Reset Token MUST NOT be used for multiple connection IDs. Endpoints are not required to compare new values against all previous values, but a duplicate value MAY be treated as a connection error of type PROTOCOL_VIOLATION.
Note that Stateless Reset packets do not have any cryptographic protection.
When sending a packet for any reason, an endpoint should attempt to bundle an ACK frame if one has not been sent recently. Doing so helps with timely loss detection at the peer.
In general, frequent feedback from a receiver improves loss and congestion response, but this has to be balanced against excessive load generated by a receiver that sends an ACK frame in response to every ack-eliciting packet. The guidance offered below seeks to strike this balance.
An ACK frame SHOULD be generated for at least every second ack-eliciting packet. This recommendation is in keeping with standard practice for TCP [RFC5681].
-
A receiver’s delayed acknowledgment timer SHOULD NOT exceed the current RTT estimate or the value it indicates in the max_ack_delay transport parameter. This ensures an acknowledgment is sent at least once per RTT when packets needing acknowledgement are received. The sender can use the receiver’s max_ack_delay value in determining timeouts for timer-based retransmission.
-
In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet that is out of order. The endpoint MAY continue sending ACK frames immediately on each subsequently received packet, but the endpoint SHOULD return to acknowledging every other packet after a period of 1/8 x RTT, unless more ACK-eliciting packets are received out of order. If every subsequent ACK-eliciting packet arrives out of order, then an ACK frame SHOULD be sent immediately for every received ACK-eliciting packet.
+
An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting packets. An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see Section 18.2. max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value. If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer. For Initial and Handshake packets, a max_ack_delay of 0 is used. The sender uses the receiver’s max_ack_delay value in determining timeouts for timer-based retransmission, as detailed in Section 5.2.1 of [QUIC-RECOVERY].
+
In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet that is out of order. The endpoint MAY continue sending ACK frames immediately on each subsequently received packet, but the endpoint SHOULD return to acknowledging every other packet after a period of 1/8 x RTT, unless more ack-eliciting packets are received out of order. If every subsequent ack-eliciting packet arrives out of order, then an ACK frame SHOULD be sent immediately for every received ack-eliciting packet.
Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer’s response time to congestion events.
As an optimization, a receiver MAY process multiple packets before sending any ACK frames in response. In this case the receiver can determine whether an immediate or delayed acknowledgement should be generated after processing incoming packets.
-
Acknowledgements of packets carrying CRYPTO frames SHOULD be minimally delayed, to complete the handshake with minimal latency. Delaying them by a small amount, such as the local timer granularity, allows the endpoint to bundle any data sent in response with the ACK frame. ACK frames SHOULD be sent immediately when the crypto stack indicates all data for that packet number space has been received.
-
Packets containing PADDING frames are considered to be in flight for congestion control purposes [QUIC-RECOVERY]. Sending only PADDING frames might cause the sender to become limited by the congestion controller (as described in [QUIC-RECOVERY]) with no acknowledgments forthcoming from the receiver. Therefore, a sender SHOULD ensure that other frames are sent in addition to PADDING frames to elicit acknowledgments from the receiver.
-
An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgements are included in packets with ACK-eliciting frames. An endpoint SHOULD bundle ACK frames with other frames when there are new ACK-eliciting packets to acknowledge. When only non-ACK-eliciting packets need to be acknowledged, an endpoint MAY wait until an ACK-eliciting packet has been received to bundle an ACK frame with outgoing frames.
-
The algorithms in [QUIC-RECOVERY] are resilient to receivers that do not follow guidance offered above. However, an implementor should only deviate from these requirements after careful consideration of the performance implications of doing so.
-
Packets containing only ACK frames are not congestion controlled, so there are limits on how frequently they can be sent. An endpoint MUST NOT send more than one ACK-frame-only packet in response to receiving an ACK-eliciting packet (one containing frames other than ACK and/or PADDING). An endpoint MUST NOT send a packet containing only an ACK frame in response to a non-ACK-eliciting packet (one containing only ACK and/or PADDING frames), even if there are packet gaps which precede the received packet. Limiting ACK frames avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle. However, the endpoint acknowledges non-ACK-eliciting packets when it sends an ACK frame.
-
An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition.
+
Packets containing PADDING frames are considered to be in flight for congestion control purposes [QUIC-RECOVERY]. Sending only PADDING frames might cause the sender to become limited by the congestion controller (as described in [QUIC-RECOVERY]) with no acknowledgments forthcoming from the receiver. Therefore, a sender SHOULD ensure that other frames are sent in addition to PADDING frames to elicit acknowledgments from the receiver.
+
An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgements are included in packets with ack-eliciting frames. An endpoint SHOULD bundle ACK frames with other frames when there are new ack-eliciting packets to acknowledge. When only non-ack-eliciting packets need to be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to bundle an ACK frame with outgoing frames.
+
The algorithms in [QUIC-RECOVERY] are resilient to receivers that do not follow guidance offered above. However, an implementor should only deviate from these requirements after careful consideration of the performance implications of doing so.
+
Packets containing only ACK frames are not congestion controlled, so there are limits on how frequently they can be sent. An endpoint MUST NOT send more than one ACK-frame-only packet in response to receiving an ack-eliciting packet (one containing frames other than ACK and/or PADDING). An endpoint MUST NOT send a packet containing only an ACK frame in response to a non-ack-eliciting packet (one containing only ACK and/or PADDING frames), even if there are packet gaps which precede the received packet. Limiting ACK frames avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle. However, the endpoint acknowledges non-ack-eliciting packets when it sends an ACK frame.
+
An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition.
To limit ACK Ranges (see Section 19.3.1) to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer. The receiver SHOULD exclude already acknowledged packets from future ACK frames whenever these packets would unnecessarily contribute to the ACK frame size. When the receiver is only sending non-ACK-eliciting packets, it can bundle a PING or other small ACK-eliciting frame with a fraction of them, such as once per round trip, to enable dropping unnecessary ACK ranges and any state for previously sent packets. The receiver MUST NOT bundle an ACK-eliciting frame, such as a PING, with all packets that would otherwise be non-ACK-eliciting, in order to avoid an infinite feedback loop of acknowledgements.
+
To limit ACK Ranges (see Section 19.3.1) to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer. The receiver SHOULD exclude already acknowledged packets from future ACK frames whenever these packets would unnecessarily contribute to the ACK frame size. When the receiver is only sending non-ack-eliciting packets, it can bundle a PING or other small ack-eliciting frame with a fraction of them, such as once per round trip, to enable dropping unnecessary ACK ranges and any state for previously sent packets. The receiver MUST NOT bundle an ack-eliciting frame, such as a PING, with all packets that would otherwise be non-ack-eliciting, in order to avoid an infinite feedback loop of acknowledgements.
To limit receiver state or the size of ACK frames, a receiver MAY limit the number of ACK Ranges it sends. A receiver can do this even without receiving acknowledgment of its ACK frames, with the knowledge this could cause the sender to unnecessarily retransmit some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare packets lost after sufficiently newer packets are acknowledged. Therefore, the receiver SHOULD repeatedly acknowledge newly received packets in preference to packets received in the past.
An endpoint measures the delays intentionally introduced between when an ACK-eliciting packet is received and the corresponding acknowledgment is sent. The endpoint encodes this delay for the largest acknowledged packet in the Ack Delay field of an ACK frame (see Section 19.3). This allows the receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed. A packet might be held in the OS kernel or elsewhere on the host before being processed. An endpoint MUST NOT include delays that is does not control when populating the Ack Delay field in an ACK frame.
-
An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting packets. An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see Section 18.2. max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value. If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer. For Initial and Handshake packets, a max_ack_delay of 0 is used.
+
An endpoint measures the delays intentionally introduced between when an ack-eliciting packet is received and the corresponding acknowledgment is sent. The endpoint encodes this delay for the largest acknowledged packet in the Ack Delay field of an ACK frame (see Section 19.3). This allows the receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed. A packet might be held in the OS kernel or elsewhere on the host before being processed. An endpoint MUST NOT include delays that is does not control when populating the Ack Delay field in an ACK frame.
Data sent in CRYPTO frames is retransmitted according to the rules in [QUIC-RECOVERY], until all data has been acknowledged. Data in CRYPTO frames for Initial and Handshake packets is discarded when keys for the corresponding encryption level are discarded.
Application data sent in STREAM frames is retransmitted in new STREAM frames unless the endpoint has sent a RESET_STREAM for that stream. Once an endpoint sends a RESET_STREAM frame, no further STREAM frames are needed.
-
The most recent set of acknowledgments are sent in ACK frames. An ACK frame SHOULD contain all unacknowledged acknowledgments, as described in Section 13.2.1.
+
The most recent set of acknowledgments are sent in ACK frames. An ACK frame SHOULD contain all unacknowledged acknowledgments, as described in Section 13.2.1.
Cancellation of stream transmission, as carried in a RESET_STREAM frame, is sent until acknowledged or until all stream data is acknowledged by the peer (that is, either the “Reset Recvd” or “Data Recvd” state is reached on the sending part of the stream). The content of a RESET_STREAM frame MUST NOT change when it is sent again.
Similarly, a request to cancel stream transmission, as encoded in a STOP_SENDING frame, is sent until the receiving part of the stream enters either a “Data Recvd” or “Reset Recvd” state; see Section 3.5.
Connection close signals, including packets that contain CONNECTION_CLOSE frames, are not sent again when packet loss is detected, but as described in Section 10.
A maximum ACK delay of 0 is used for handshake packet number spaces (#2646, #2638)
Improved rules for use of congestion control state on new paths (#2685, #2918)
Removed recommendation to coordinate spin for multiple connections that share a path (#2763, #2882)
-
Allow smaller stateless resets and recommend a smaller minimum on packets that might trigger a stateless reset (#2770, #2869, #2927)
+
Allow smaller stateless resets and recommend a smaller minimum on packets that might trigger a stateless reset (#2770, #2869, #2927, #3007).
Provide guidance around the interface to QUIC as used by application protocols (#2805, #2857)
Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825, #2826)
Tighter rules about processing of rejected 0-RTT packets (#2829, #2840, #2841)
diff --git a/close3029/draft-ietf-quic-transport.txt b/ianswett-limit-bursts/draft-ietf-quic-transport.txt
similarity index 93%
rename from close3029/draft-ietf-quic-transport.txt
rename to ianswett-limit-bursts/draft-ietf-quic-transport.txt
index 8e59dfd684..a7fd1ac204 100644
--- a/close3029/draft-ietf-quic-transport.txt
+++ b/ianswett-limit-bursts/draft-ietf-quic-transport.txt
@@ -5,8 +5,8 @@
QUIC J. Iyengar, Ed.
Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed.
-Expires: March 19, 2020 Mozilla
- September 16, 2019
+Expires: April 19, 2020 Mozilla
+ October 17, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport
@@ -43,7 +43,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on March 19, 2020.
+ This Internet-Draft will expire on April 19, 2020.
Copyright Notice
@@ -53,9 +53,9 @@ Copyright Notice
-Iyengar & Thomson Expires March 19, 2020 [Page 1]
+Iyengar & Thomson Expires April 19, 2020 [Page 1]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
This document is subject to BCP 78 and the IETF Trust's Legal
@@ -109,9 +109,9 @@ Table of Contents
-Iyengar & Thomson Expires March 19, 2020 [Page 2]
+Iyengar & Thomson Expires April 19, 2020 [Page 2]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 33
@@ -152,11 +152,11 @@ Internet-Draft QUIC Transport Protocol September 2019
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 60
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 61
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 62
- 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 63
+ 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 62
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 63
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 64
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 64
- 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 65
+ 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 64
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 65
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 66
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 67
@@ -165,9 +165,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 3]
+Iyengar & Thomson Expires April 19, 2020 [Page 3]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 71
@@ -183,8 +183,8 @@ Internet-Draft QUIC Transport Protocol September 2019
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 78
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 80
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 81
- 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 82
- 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 83
+ 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 81
+ 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 82
14.3.1. PMTU Probes Containing Source Connection ID . . . . 83
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 83
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 84
@@ -221,9 +221,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 4]
+Iyengar & Thomson Expires April 19, 2020 [Page 4]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 119
@@ -269,7 +269,7 @@ Internet-Draft QUIC Transport Protocol September 2019
B.12. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 147
B.13. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 147
B.14. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 148
- B.15. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 148
+ B.15. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 149
B.16. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 149
B.17. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 150
B.18. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 150
@@ -277,9 +277,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 5]
+Iyengar & Thomson Expires April 19, 2020 [Page 5]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
B.20. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 151
@@ -333,9 +333,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 6]
+Iyengar & Thomson Expires April 19, 2020 [Page 6]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
* Section 7 details the process for establishing connections,
@@ -389,9 +389,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 7]
+Iyengar & Thomson Expires April 19, 2020 [Page 7]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
1.2. Terms and Definitions
@@ -411,6 +411,10 @@ Internet-Draft QUIC Transport Protocol September 2019
encapsulated in a UDP datagram. Multiple QUIC packets can be
encapsulated in a single UDP datagram.
+ Ack-eliciting Packet: A QUIC packet that contains frames other than
+ ACK and PADDING. These cause a recipient to send an
+ acknowledgment (see Section 13.2.1).
+
Endpoint: An entity that can participate in a QUIC connection by
generating, receiving, and processing QUIC packets. There are
only two types of endpoint in QUIC: client and server.
@@ -439,16 +443,14 @@ Internet-Draft QUIC Transport Protocol September 2019
x (A): Indicates that x is A bits long
- x (A/B/C) ...: Indicates that x is one of A, B, or C bits long
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 8]
+Iyengar & Thomson Expires April 19, 2020 [Page 8]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+
+ x (A/B/C) ...: Indicates that x is one of A, B, or C bits long
x (i) ...: Indicates that x uses the variable-length encoding in
Section 16
@@ -499,11 +501,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 9]
+Iyengar & Thomson Expires April 19, 2020 [Page 9]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
The second least significant bit (0x2) of the stream ID distinguishes
@@ -557,9 +557,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 10]
+Iyengar & Thomson Expires April 19, 2020 [Page 10]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
the same offset within a stream as a connection error of type
@@ -613,9 +613,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 11]
+Iyengar & Thomson Expires April 19, 2020 [Page 11]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
On the receiving part of a stream, application protocols need to be
@@ -669,9 +669,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 12]
+Iyengar & Thomson Expires April 19, 2020 [Page 12]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
o
@@ -725,9 +725,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 13]
+Iyengar & Thomson Expires April 19, 2020 [Page 13]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
The sending part of a bidirectional stream initiated by a peer (type
@@ -781,9 +781,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 14]
+Iyengar & Thomson Expires April 19, 2020 [Page 14]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
part that cannot be observed, such as the "Ready" state. Instead,
@@ -837,9 +837,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 15]
+Iyengar & Thomson Expires April 19, 2020 [Page 15]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
The receiving part of a stream enters the "Recv" state when the
@@ -893,9 +893,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 16]
+Iyengar & Thomson Expires April 19, 2020 [Page 16]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
RESET_STREAM frame (the "Reset Recvd" state). An implementation is
@@ -949,9 +949,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 17]
+Iyengar & Thomson Expires April 19, 2020 [Page 17]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
parts are in a non-terminal state and "closed" when both sending and
@@ -1005,9 +1005,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 18]
+Iyengar & Thomson Expires April 19, 2020 [Page 18]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
3.5. Solicited State Transitions
@@ -1061,9 +1061,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 19]
+Iyengar & Thomson Expires April 19, 2020 [Page 19]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
4. Flow Control
@@ -1117,9 +1117,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 20]
+Iyengar & Thomson Expires April 19, 2020 [Page 20]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
that the sender receives an update before running out of flow control
@@ -1173,9 +1173,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 21]
+Iyengar & Thomson Expires April 19, 2020 [Page 21]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
data, similar to common TCP implementations. As an optimization,
@@ -1229,9 +1229,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 22]
+Iyengar & Thomson Expires April 19, 2020 [Page 22]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
4.4. Stream Final Size
@@ -1285,9 +1285,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 23]
+Iyengar & Thomson Expires April 19, 2020 [Page 23]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Endpoints MUST NOT exceed the limit set by their peer. An endpoint
@@ -1341,9 +1341,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 24]
+Iyengar & Thomson Expires April 19, 2020 [Page 24]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Connection IDs MUST NOT contain any information that can be used by
@@ -1397,9 +1397,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 25]
+Iyengar & Thomson Expires April 19, 2020 [Page 25]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Additional connection IDs are communicated to the peer using
@@ -1453,9 +1453,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 26]
+Iyengar & Thomson Expires April 19, 2020 [Page 26]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
As discussed in Section 9.5, each connection ID MUST be used on
@@ -1509,9 +1509,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 27]
+Iyengar & Thomson Expires April 19, 2020 [Page 27]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Invalid packets without packet protection, such as Initial, Retry, or
@@ -1565,9 +1565,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 28]
+Iyengar & Thomson Expires April 19, 2020 [Page 28]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
If a server isn't currently accepting any new connections, it SHOULD
@@ -1621,9 +1621,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 29]
+Iyengar & Thomson Expires April 19, 2020 [Page 29]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
o configure minimum values for the initial number of permitted
@@ -1677,9 +1677,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 30]
+Iyengar & Thomson Expires April 19, 2020 [Page 30]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
A server MAY limit the number of Version Negotiation packets it
@@ -1733,9 +1733,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 31]
+Iyengar & Thomson Expires April 19, 2020 [Page 31]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
negotiation (0x?a?a?a?a as defined in Section 15) when generating a
@@ -1789,9 +1789,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 32]
+Iyengar & Thomson Expires April 19, 2020 [Page 32]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
The first client packet of the cryptographic handshake protocol MUST
@@ -1845,9 +1845,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 33]
+Iyengar & Thomson Expires April 19, 2020 [Page 33]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Client Server
@@ -1901,9 +1901,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 34]
+Iyengar & Thomson Expires April 19, 2020 [Page 34]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Connection ID is used to set the Destination Connection ID used by
@@ -1957,9 +1957,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 35]
+Iyengar & Thomson Expires April 19, 2020 [Page 35]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
7.3. Transport Parameters
@@ -2013,9 +2013,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 36]
+Iyengar & Thomson Expires April 19, 2020 [Page 36]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
ack_delay_exponent and active_connection_id_limit. The client MUST
@@ -2069,9 +2069,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 37]
+Iyengar & Thomson Expires April 19, 2020 [Page 37]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
server MAY treat use of updated transport parameters in 0-RTT as a
@@ -2125,9 +2125,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 38]
+Iyengar & Thomson Expires April 19, 2020 [Page 38]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
victim. If a server generates more or larger packets in response to
@@ -2181,9 +2181,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 39]
+Iyengar & Thomson Expires April 19, 2020 [Page 39]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
In addition to sending limits imposed prior to address validation,
@@ -2237,9 +2237,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 40]
+Iyengar & Thomson Expires April 19, 2020 [Page 40]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
potentially sends a significant amount of data to a client in
@@ -2293,9 +2293,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 41]
+Iyengar & Thomson Expires April 19, 2020 [Page 41]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
path; see Section 9.5. A client MUST NOT reuse a token if it
@@ -2349,9 +2349,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 42]
+Iyengar & Thomson Expires April 19, 2020 [Page 42]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
a short period. Servers are encouraged to allow tokens to be used
@@ -2405,9 +2405,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 43]
+Iyengar & Thomson Expires April 19, 2020 [Page 43]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that
@@ -2461,9 +2461,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 44]
+Iyengar & Thomson Expires April 19, 2020 [Page 44]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Note that receipt on a different local address does not result in
@@ -2517,9 +2517,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 45]
+Iyengar & Thomson Expires April 19, 2020 [Page 45]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
"disable_active_migration" transport parameter during the handshake.
@@ -2573,9 +2573,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 46]
+Iyengar & Thomson Expires April 19, 2020 [Page 46]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames
@@ -2629,9 +2629,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 47]
+Iyengar & Thomson Expires April 19, 2020 [Page 47]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
that an endpoint does not send packets to an old peer address in the
@@ -2685,9 +2685,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 48]
+Iyengar & Thomson Expires April 19, 2020 [Page 48]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
To protect the connection from failing due to such a spurious
@@ -2741,9 +2741,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 49]
+Iyengar & Thomson Expires April 19, 2020 [Page 49]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
arrives before any copy made by an attacker, this results in the
@@ -2797,9 +2797,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 50]
+Iyengar & Thomson Expires April 19, 2020 [Page 50]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
A sender can make exceptions for probe packets so that their loss
@@ -2853,9 +2853,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 51]
+Iyengar & Thomson Expires April 19, 2020 [Page 51]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
or genuine migrations. Changing port number can cause a peer to
@@ -2909,9 +2909,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 52]
+Iyengar & Thomson Expires April 19, 2020 [Page 52]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
9.6.2. Responding to Connection Migration
@@ -2965,9 +2965,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 53]
+Iyengar & Thomson Expires April 19, 2020 [Page 53]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
A client that migrates to a new address SHOULD use a preferred
@@ -3021,9 +3021,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 54]
+Iyengar & Thomson Expires April 19, 2020 [Page 54]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
and to identify packets as belonging to the connection. The
@@ -3077,9 +3077,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 55]
+Iyengar & Thomson Expires April 19, 2020 [Page 55]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
10.2. Idle Timeout
@@ -3093,7 +3093,7 @@ Internet-Draft QUIC Transport Protocol September 2019
endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully. The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an
- ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK-
+ ack-eliciting packet; see [QUIC-RECOVERY]), but only if no other ack-
eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity.
@@ -3133,9 +3133,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 56]
+Iyengar & Thomson Expires April 19, 2020 [Page 56]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
of advantage to loss recovery and congestion control, which are
@@ -3189,9 +3189,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 57]
+Iyengar & Thomson Expires April 19, 2020 [Page 57]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
the client. These packets can be coalesced into a single UDP
@@ -3211,13 +3211,15 @@ Internet-Draft QUIC Transport Protocol September 2019
use a CONNECTION_CLOSE frame if it has sufficient state to do so.
To support this process, a token is sent by endpoints. The token is
- carried in 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 are invalidated when their associated connection ID is retired
- via a RETIRE_CONNECTION_ID frame (Section 19.16).
+ carried in the Stateless Reset Token field of a NEW_CONNECTION_ID
+ frame. Servers can also specify a stateless_reset_token transport
+ parameter during the handshake that applies to the connection ID that
+ it selected during the handshake; clients cannot use this transport
+ parameter because their transport parameters don't have
+ confidentiality protection. These tokens are protected by
+ encryption, so only client and server know their value. Tokens are
+ invalidated when their associated connection ID is retired via a
+ RETIRE_CONNECTION_ID frame (Section 19.16).
An endpoint that receives packets that it cannot process sends a
packet in the following layout:
@@ -3238,17 +3240,19 @@ Internet-Draft QUIC Transport Protocol September 2019
Figure 6: Stateless Reset Packet
- This design ensures that a stateless reset packet is - to the extent
- possible - indistinguishable from a regular packet with a short
- header.
-Iyengar & Thomson Expires March 19, 2020 [Page 58]
+
+Iyengar & Thomson Expires April 19, 2020 [Page 58]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+
+ This design ensures that a stateless reset packet is - to the extent
+ possible - indistinguishable from a regular packet with a short
+ header.
A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header. The remainder of the first byte
@@ -3294,18 +3298,18 @@ Internet-Draft QUIC Transport Protocol September 2019
An endpoint MAY send a stateless reset in response to a packet with a
long header. Sending a stateless reset is not effective prior to the
- stateless reset token being available to a peer. In this QUIC
- version, packets with a long header are only used during connection
- establishment. Because the stateless reset token is not available
- until connection establishment is complete or near completion,
-Iyengar & Thomson Expires March 19, 2020 [Page 59]
+Iyengar & Thomson Expires April 19, 2020 [Page 59]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+ stateless reset token being available to a peer. In this QUIC
+ version, packets with a long header are only used during connection
+ establishment. Because the stateless reset token is not available
+ until connection establishment is complete or near completion,
ignoring an unknown packet with a long header might be as effective
as sending a stateless reset.
@@ -3347,21 +3351,22 @@ Internet-Draft QUIC Transport Protocol September 2019
packet either cannot be associated with a connection, cannot be
decrypted, or is marked as a duplicate packet. The endpoint MUST
then compare the last 16 bytes of the packet with all Stateless Reset
- Tokens that are associated with connection IDs that the endpoint
- recently used to send packets from the IP address and port on which
- the datagram is received. This includes Stateless Reset Tokens from
- NEW_CONNECTION_ID frames and the server's transport parameters. An
- endpoint MUST NOT check for any Stateless Reset Tokens associated
- with connection IDs it has not used or for connection IDs that have
- been retired.
+ Tokens corresponding to active connection IDs that the endpoint has
+ used for sending packets to the IP address and port on which the
+ datagram is received. This includes Stateless Reset Tokens from
-Iyengar & Thomson Expires March 19, 2020 [Page 60]
+Iyengar & Thomson Expires April 19, 2020 [Page 60]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+ NEW_CONNECTION_ID frames and the server's transport parameters. An
+ endpoint MUST NOT check for any Stateless Reset Tokens associated
+ with connection IDs it has not used or for connection IDs that have
+ been retired.
+
If the last 16 bytes of the packet values are identical to a
Stateless Reset Token, the endpoint MUST enter the draining period
and not send any further packets on this connection. If the
@@ -3405,31 +3410,23 @@ Internet-Draft QUIC Transport Protocol September 2019
connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can
- cause a packet to be routed to an instance that has no state but the
- same static key; see Section 21.9. A connection ID from a connection
- that is reset by revealing the Stateless Reset Token MUST NOT be
- reused for new connections at nodes that share a static key.
-
-Iyengar & Thomson Expires March 19, 2020 [Page 61]
+Iyengar & Thomson Expires April 19, 2020 [Page 61]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
- The same Stateless Reset Token MAY be used for multiple connection
- IDs on the same connection. However, reuse of a Stateless Reset
- Token might expose an endpoint to denial of service if associated
- connection IDs are forgotten while the associated token is still
- active at a peer. An endpoint MUST ensure that packets with
- Destination Connection ID field values that correspond to a reused
- Stateless Reset Token are attributed to the same connection as long
- as the Stateless Reset Token is still usable, even when the
- connection ID has been retired. Otherwise, an attacker might be able
- to send a packet with a retired connection ID and cause the endpoint
- to produce a Stateless Reset that it can use to disrupt the
- connection, just as with the attacks in Section 21.9.
+ cause a packet to be routed to an instance that has no state but the
+ same static key; see Section 21.9. A connection ID from a connection
+ that is reset by revealing the Stateless Reset Token MUST NOT be
+ reused for new connections at nodes that share a static key.
+
+ The same Stateless Reset Token MUST NOT be used for multiple
+ connection IDs. Endpoints are not required to compare new values
+ against all previous values, but a duplicate value MAY be treated as
+ a connection error of type PROTOCOL_VIOLATION.
Note that Stateless Reset packets do not have any cryptographic
protection.
@@ -3462,18 +3459,6 @@ Internet-Draft QUIC Transport Protocol September 2019
of broken connections where only very small packets are sent; such
failures might only be detected by other means, such as timers.
-
-
-
-
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 62]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
11. Error Handling
An endpoint that detects an error SHOULD signal the existence of that
@@ -3482,6 +3467,13 @@ Internet-Draft QUIC Transport Protocol September 2019
application-level errors can be isolated to a single stream (see
Section 11.2).
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 62]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
The most appropriate error code (Section 20) SHOULD be included in
the frame that signals the error. Where this specification
identifies error conditions, it also identifies the error code that
@@ -3522,19 +3514,21 @@ Internet-Draft QUIC Transport Protocol September 2019
An endpoint that chooses not to retransmit packets containing a
CONNECTION_CLOSE frame risks a peer missing the first such packet.
The only mechanism available to an endpoint that continues to receive
+ data for a terminated connection is to use the stateless reset
+ process (Section 10.4).
+ An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT
+ signal the existence of the error to its peer.
-Iyengar & Thomson Expires March 19, 2020 [Page 63]
-
-Internet-Draft QUIC Transport Protocol September 2019
- data for a terminated connection is to use the stateless reset
- process (Section 10.4).
- An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT
- signal the existence of the error to its peer.
+
+Iyengar & Thomson Expires April 19, 2020 [Page 63]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
11.2. Stream Errors
@@ -3574,18 +3568,6 @@ Internet-Draft QUIC Transport Protocol September 2019
overhead and are used after a connection is established and 1-RTT
keys are available.
-
-
-
-
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 64]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
12.1. Protected Packets
All QUIC packets except Version Negotiation and Retry packets use
@@ -3596,6 +3578,14 @@ Internet-Draft QUIC Transport Protocol September 2019
Initial packets are protected using keys that are statically derived.
This packet protection is not effective confidentiality protection.
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 64]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
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
@@ -3633,15 +3623,6 @@ Internet-Draft QUIC Transport Protocol September 2019
Section 14.3.1). Receivers MUST be able to process coalesced
packets.
-
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 65]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be
able to process all the packets in a single pass. A packet with a
@@ -3654,6 +3635,13 @@ Internet-Draft QUIC Transport Protocol September 2019
packets with a different Destination Connection ID than the first
packet in the datagram.
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 65]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete. The receiver of coalesced QUIC packets MUST
individually process each QUIC packet and separately acknowledge
@@ -3691,13 +3679,6 @@ Internet-Draft QUIC Transport Protocol September 2019
o Initial space: All Initial packets (Section 17.2.2) are in this
space.
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 66]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
o Handshake space: All Handshake packets (Section 17.2.4) are in
this space.
@@ -3709,6 +3690,14 @@ Internet-Draft QUIC Transport Protocol September 2019
Conceptually, a packet number space is the context in which a packet
can be processed and acknowledged. Initial packets can only be sent
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 66]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
with Initial packet protection keys and acknowledged in packets which
are also Initial packets. Similarly, Handshake packets are sent at
the Handshake encryption level and can only be acknowledged in
@@ -3749,9 +3738,20 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 67]
+
+
+
+
+
+
+
+
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 67]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
0 1 2 3
@@ -3805,9 +3805,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 68]
+Iyengar & Thomson Expires April 19, 2020 [Page 68]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+-------------+----------------------+---------------+
@@ -3861,9 +3861,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 69]
+Iyengar & Thomson Expires April 19, 2020 [Page 69]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
All QUIC frames are idempotent in this version of QUIC. That is, a
@@ -3917,9 +3917,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 70]
+Iyengar & Thomson Expires April 19, 2020 [Page 70]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
13.1. Packet Processing
@@ -3957,30 +3957,36 @@ Internet-Draft QUIC Transport Protocol September 2019
eliciting packet. This recommendation is in keeping with standard
practice for TCP [RFC5681].
- A receiver's delayed acknowledgment timer SHOULD NOT exceed the
- current RTT estimate or the value it indicates in the "max_ack_delay"
- transport parameter. This ensures an acknowledgment is sent at least
- once per RTT when packets needing acknowledgement are received. The
- sender can use the receiver's "max_ack_delay" value in determining
- timeouts for timer-based retransmission.
+ An endpoint MUST NOT excessively delay acknowledgements of ack-
+ eliciting packets. An endpoint commits to a maximum delay using the
+ max_ack_delay transport parameter; see Section 18.2. max_ack_delay
+ declares an explicit contract: an endpoint promises to never delay
+ acknowledgments of an ack-eliciting packet by more than the indicated
+ value. If it does, any excess accrues to the RTT estimate and could
+ result in delayed retransmissions from the peer. For Initial and
+ Handshake packets, a max_ack_delay of 0 is used. The sender uses the
+ receiver's "max_ack_delay" value in determining timeouts for timer-
+ based retransmission, as detailed in Section 5.2.1 of
+ [QUIC-RECOVERY].
+
- In order to assist loss detection at the sender, an endpoint SHOULD
- send an ACK frame immediately on receiving an ack-eliciting packet
- that is out of order. The endpoint MAY continue sending ACK frames
- immediately on each subsequently received packet, but the endpoint
- SHOULD return to acknowledging every other packet after a period of
- 1/8 x RTT, unless more ACK-eliciting packets are received out of
-Iyengar & Thomson Expires March 19, 2020 [Page 71]
+Iyengar & Thomson Expires April 19, 2020 [Page 71]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
- order. If every subsequent ACK-eliciting packet arrives out of
+ In order to assist loss detection at the sender, an endpoint SHOULD
+ send an ACK frame immediately on receiving an ack-eliciting packet
+ that is out of order. The endpoint MAY continue sending ACK frames
+ immediately on each subsequently received packet, but the endpoint
+ SHOULD return to acknowledging every other packet after a period of
+ 1/8 x RTT, unless more ack-eliciting packets are received out of
+ order. If every subsequent ack-eliciting packet arrives out of
order, then an ACK frame SHOULD be sent immediately for every
- received ACK-eliciting packet.
+ received ack-eliciting packet.
Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to
@@ -3991,13 +3997,6 @@ Internet-Draft QUIC Transport Protocol September 2019
determine whether an immediate or delayed acknowledgement should be
generated after processing incoming packets.
- Acknowledgements of packets carrying CRYPTO frames SHOULD be
- minimally delayed, to complete the handshake with minimal latency.
- Delaying them by a small amount, such as the local timer granularity,
- allows the endpoint to bundle any data sent in response with the ACK
- frame. ACK frames SHOULD be sent immediately when the crypto stack
- indicates all data for that packet number space has been received.
-
Packets containing PADDING frames are considered to be in flight for
congestion control purposes [QUIC-RECOVERY]. Sending only PADDING
frames might cause the sender to become limited by the congestion
@@ -4008,10 +4007,10 @@ Internet-Draft QUIC Transport Protocol September 2019
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are
- included in packets with ACK-eliciting frames. An endpoint SHOULD
- bundle ACK frames with other frames when there are new ACK-eliciting
- packets to acknowledge. When only non-ACK-eliciting packets need to
- be acknowledged, an endpoint MAY wait until an ACK-eliciting packet
+ included in packets with ack-eliciting frames. An endpoint SHOULD
+ bundle ACK frames with other frames when there are new ack-eliciting
+ packets to acknowledge. When only non-ack-eliciting packets need to
+ be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to bundle an ACK frame with outgoing frames.
The algorithms in [QUIC-RECOVERY] are resilient to receivers that do
@@ -4022,22 +4021,22 @@ Internet-Draft QUIC Transport Protocol September 2019
Packets containing only ACK frames are not congestion controlled, so
there are limits on how frequently they can be sent. An endpoint
MUST NOT send more than one ACK-frame-only packet in response to
- receiving an ACK-eliciting packet (one containing frames other than
+ receiving an ack-eliciting packet (one containing frames other than
ACK and/or PADDING). An endpoint MUST NOT send a packet containing
- only an ACK frame in response to a non-ACK-eliciting packet (one
+ only an ACK frame in response to a non-ack-eliciting packet (one
containing only ACK and/or PADDING frames), even if there are packet
+ gaps which precede the received packet. Limiting ACK frames avoids
-Iyengar & Thomson Expires March 19, 2020 [Page 72]
+Iyengar & Thomson Expires April 19, 2020 [Page 72]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
- gaps which precede the received packet. Limiting ACK frames avoids
an infinite feedback loop of acknowledgements, which could prevent
the connection from ever becoming idle. However, the endpoint
- acknowledges non-ACK-eliciting packets when it sends an ACK frame.
+ acknowledges non-ack-eliciting packets when it sends an ACK frame.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it
did not send as a connection error of type PROTOCOL_VIOLATION, if it
@@ -4082,21 +4081,21 @@ Internet-Draft QUIC Transport Protocol September 2019
been received by the sender, the receiver SHOULD track which ACK
frames have been acknowledged by its peer. The receiver SHOULD
exclude already acknowledged packets from future ACK frames whenever
+ these packets would unnecessarily contribute to the ACK frame size.
-Iyengar & Thomson Expires March 19, 2020 [Page 73]
+Iyengar & Thomson Expires April 19, 2020 [Page 73]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
- these packets would unnecessarily contribute to the ACK frame size.
- When the receiver is only sending non-ACK-eliciting packets, it can
- bundle a PING or other small ACK-eliciting frame with a fraction of
+ When the receiver is only sending non-ack-eliciting packets, it can
+ bundle a PING or other small ack-eliciting frame with a fraction of
them, such as once per round trip, to enable dropping unnecessary ACK
ranges and any state for previously sent packets. The receiver MUST
- NOT bundle an ACK-eliciting frame, such as a PING, with all packets
- that would otherwise be non-ACK-eliciting, in order to avoid an
+ NOT bundle an ack-eliciting frame, such as a PING, with all packets
+ that would otherwise be non-ack-eliciting, in order to avoid an
infinite feedback loop of acknowledgements.
To limit receiver state or the size of ACK frames, a receiver MAY
@@ -4111,7 +4110,7 @@ Internet-Draft QUIC Transport Protocol September 2019
13.2.5. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between when
- an ACK-eliciting packet is received and the corresponding
+ an ack-eliciting packet is received and the corresponding
acknowledgment is sent. The endpoint encodes this delay for the
largest acknowledged packet in the Ack Delay field of an ACK frame
(see Section 19.3). This allows the receiver of the ACK to adjust
@@ -4121,15 +4120,6 @@ Internet-Draft QUIC Transport Protocol September 2019
processed. An endpoint MUST NOT include delays that is does not
control when populating the Ack Delay field in an ACK frame.
- An endpoint MUST NOT excessively delay acknowledgements of ack-
- eliciting packets. An endpoint commits to a maximum delay using the
- max_ack_delay transport parameter; see Section 18.2. max_ack_delay
- declares an explicit contract: an endpoint promises to never delay
- acknowledgments of an ack-eliciting packet by more than the indicated
- value. If it does, any excess accrues to the RTT estimate and could
- result in delayed retransmissions from the peer. For Initial and
- Handshake packets, a max_ack_delay of 0 is used.
-
13.2.6. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet
@@ -4137,15 +4127,6 @@ Internet-Draft QUIC Transport Protocol September 2019
instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys.
-
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 74]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
Packets that a client sends with 0-RTT packet protection MUST be
acknowledged by the server in packets protected by 1-RTT keys. This
can mean that the client is unable to use these acknowledgments if
@@ -4153,6 +4134,18 @@ Internet-Draft QUIC Transport Protocol September 2019
Note that the same limitation applies to other data sent by the
server protected by the 1-RTT keys.
+
+
+
+
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 74]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
13.3. Retransmission of Information
QUIC packets that are determined to be lost are not retransmitted
@@ -4192,16 +4185,6 @@ Internet-Draft QUIC Transport Protocol September 2019
stream enters either a "Data Recvd" or "Reset Recvd" state; see
Section 3.5.
-
-
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 75]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
o Connection close signals, including packets that contain
CONNECTION_CLOSE frames, are not sent again when packet loss is
detected, but as described in Section 10.
@@ -4211,6 +4194,14 @@ Internet-Draft QUIC Transport Protocol September 2019
containing the most recently sent MAX_DATA frame is declared lost,
or when the endpoint decides to update the limit. Care is
necessary to avoid sending this frame too often as the limit can
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 75]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
increase frequently and cause an unnecessarily large number of
MAX_DATA frames to be sent.
@@ -4250,14 +4241,6 @@ Internet-Draft QUIC Transport Protocol September 2019
o New connection IDs are sent in NEW_CONNECTION_ID frames and
retransmitted if the packet containing them is lost.
Retransmissions of this frame carry the same sequence number
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 76]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
value. Likewise, retired connection IDs are sent in
RETIRE_CONNECTION_ID frames and retransmitted if the packet
containing them is lost.
@@ -4267,6 +4250,14 @@ Internet-Draft QUIC Transport Protocol September 2019
duplicated NEW_TOKEN frames other than a direct comparison of the
frame contents.
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 76]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
o PING and PADDING frames contain no information, so lost PING or
PADDING frames do not require repair.
@@ -4306,14 +4297,6 @@ Internet-Draft QUIC Transport Protocol September 2019
enabled endpoint that can access the ECN codepoints from the
enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE
count, and includes these counts in subsequent ACK frames (see
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 77]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
Section 13.2 and Section 19.3). Note that this requires being able
to read the ECN codepoints from the enclosing IP packet, which is not
possible on all platforms.
@@ -4322,6 +4305,15 @@ Internet-Draft QUIC Transport Protocol September 2019
receiver's local ECN codepoint counts; see (Section 21.8) for
relevant security concerns.
+
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 77]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
If an endpoint receives a QUIC packet without an ECT or CE codepoint
in the IP packet header, it responds per Section 13.2 with an ACK
frame without increasing any ECN counts. If an endpoint does not
@@ -4362,14 +4354,6 @@ Internet-Draft QUIC Transport Protocol September 2019
To start ECN validation, an endpoint SHOULD do the following when
sending packets on a new path to a peer:
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 78]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
o Set the ECT(0) codepoint in the IP header of early outgoing
packets sent on a new path to the peer [RFC8311].
@@ -4377,6 +4361,15 @@ Internet-Draft QUIC Transport Protocol September 2019
eventually deemed lost [QUIC-RECOVERY], validation is deemed to
have failed.
+
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 78]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
To reduce the chances of misinterpreting congestive loss as packets
dropped by a faulty network element, an endpoint could set the ECT(0)
codepoint in the first ten outgoing packets on a path, or for a
@@ -4417,15 +4410,6 @@ Internet-Draft QUIC Transport Protocol September 2019
not advance the largest packet number acknowledged in this
connection.
-
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 79]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
An endpoint could miss acknowledgements for a packet when ACK frames
are lost. It is therefore possible for the total increase in ECT(0),
ECT(1), and CE counts to be greater than the number of packets
@@ -4433,6 +4417,15 @@ Internet-Draft QUIC Transport Protocol September 2019
succeeds, the local reference counts MUST be increased to match the
counts in the ACK frame.
+
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 79]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
13.4.2.3. Validation Outcomes
If validation fails, then the endpoint stops sending ECN markings in
@@ -4473,20 +4466,21 @@ Internet-Draft QUIC Transport Protocol September 2019
PROTOCOL_VIOLATION in response to the first Initial packet it
receives from a client if the UDP datagram is smaller than 1200
bytes. It MUST NOT send any other frame type in response, or
+ otherwise behave as if any part of the offending packet was processed
+ as valid.
+ The server MUST also limit the number of bytes it sends before
+ validating the address of the client; see Section 8.
-Iyengar & Thomson Expires March 19, 2020 [Page 80]
-
-Internet-Draft QUIC Transport Protocol September 2019
- otherwise behave as if any part of the offending packet was processed
- as valid.
- The server MUST also limit the number of bytes it sends before
- validating the address of the client; see Section 8.
+Iyengar & Thomson Expires April 19, 2020 [Page 80]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
14.1. Path Maximum Transmission Unit (PMTU)
@@ -4527,17 +4521,6 @@ Internet-Draft QUIC Transport Protocol September 2019
path. An endpoint MAY terminate the connection if an alternative
path cannot be found.
-
-
-
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 81]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
14.2. ICMP Packet Too Big Messages
PMTU discovery [RFC1191] [RFC8201] relies on reception of ICMP
@@ -4548,6 +4531,13 @@ Internet-Draft QUIC Transport Protocol September 2019
successfully guess the addresses used on the path and reduce the PMTU
to a bandwidth-inefficient value.
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 81]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
An endpoint MUST ignore an ICMP message that claims the PMTU has
decreased below 1280 bytes.
@@ -4586,14 +4576,6 @@ Internet-Draft QUIC Transport Protocol September 2019
QUIC's loss detection algorithm determines that the quoted packet has
actually been lost.
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 82]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
14.3. Datagram Packetization Layer PMTU Discovery
Section 6.4 of [DPLPMTUD] provides considerations for implementing
@@ -4603,6 +4585,15 @@ Internet-Draft QUIC Transport Protocol September 2019
initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC
packet size (1232 bytes for IPv6 and 1252 bytes for IPv4).
+
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 82]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
PING and PADDING frames can be used to generate PMTU probe packets.
These frames might not be retransmitted if a probe packet containing
them is lost. However, these frames do consume congestion window,
@@ -4643,13 +4634,6 @@ Internet-Draft QUIC Transport Protocol September 2019
across all versions of the protocol are described in
[QUIC-INVARIANTS].
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 83]
-
-Internet-Draft QUIC Transport Protocol September 2019
-
-
Version 0x00000001 of QUIC uses TLS as a cryptographic handshake
protocol, as described in [QUIC-TLS].
@@ -4658,6 +4642,14 @@ Internet-Draft QUIC Transport Protocol September 2019
Versions that follow the pattern 0x?a?a?a?a are reserved for use in
forcing version negotiation to be exercised. That is, any version
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 83]
+
+Internet-Draft QUIC Transport Protocol October 2019
+
+
number where the low four bits of all bytes is 1010 (in binary). A
client or server MAY advertise support for any of these reserved
versions.
@@ -4701,9 +4693,17 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 84]
+
+
+
+
+
+
+
+
+Iyengar & Thomson Expires April 19, 2020 [Page 84]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+------+--------+-------------+-----------------------+
@@ -4757,9 +4757,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 85]
+Iyengar & Thomson Expires April 19, 2020 [Page 85]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
recovered even if the packet arrives after packets that are sent
@@ -4813,9 +4813,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 86]
+Iyengar & Thomson Expires April 19, 2020 [Page 86]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Long headers are used for packets that are sent prior to the
@@ -4869,9 +4869,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 87]
+Iyengar & Thomson Expires April 19, 2020 [Page 87]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Source Connection ID: The Source Connection ID field follows the
@@ -4925,9 +4925,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 88]
+Iyengar & Thomson Expires April 19, 2020 [Page 88]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
bits are protected using header protection (see Section 5.4 of
@@ -4981,9 +4981,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 89]
+Iyengar & Thomson Expires April 19, 2020 [Page 89]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
0 1 2 3
@@ -5037,9 +5037,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 90]
+Iyengar & Thomson Expires April 19, 2020 [Page 90]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
The remainder of the Version Negotiation packet is a list of 32-bit
@@ -5093,9 +5093,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 91]
+Iyengar & Thomson Expires April 19, 2020 [Page 91]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
The Initial packet contains a long header as well as the Length and
@@ -5149,9 +5149,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 92]
+Iyengar & Thomson Expires April 19, 2020 [Page 92]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
cryptographic handshake and will contain a CRYPTO frame with an
@@ -5205,9 +5205,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 93]
+Iyengar & Thomson Expires April 19, 2020 [Page 93]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+-+-+-+-+-+-+-+-+
@@ -5261,9 +5261,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 94]
+Iyengar & Thomson Expires April 19, 2020 [Page 94]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
client cannot send an ACK frame in a 0-RTT packet, because that can
@@ -5317,9 +5317,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 95]
+Iyengar & Thomson Expires April 19, 2020 [Page 95]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Handshake packets are their own packet number space, and thus the
@@ -5373,9 +5373,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 96]
+Iyengar & Thomson Expires April 19, 2020 [Page 96]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
ODCID Len: The ODCID Len contains the length in bytes of the
@@ -5429,9 +5429,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 97]
+Iyengar & Thomson Expires April 19, 2020 [Page 97]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
to the keys used to protect the Initial packet. It also sets the
@@ -5485,9 +5485,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 98]
+Iyengar & Thomson Expires April 19, 2020 [Page 98]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
0 1 2 3
@@ -5541,9 +5541,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 99]
+Iyengar & Thomson Expires April 19, 2020 [Page 99]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
of the packet number field is the value of this field, plus one.
@@ -5597,9 +5597,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 100]
+Iyengar & Thomson Expires April 19, 2020 [Page 100]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
When the spin bit is disabled, endpoints MAY set the spin bit to any
@@ -5653,9 +5653,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 101]
+Iyengar & Thomson Expires April 19, 2020 [Page 101]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
enum {
@@ -5709,9 +5709,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 102]
+Iyengar & Thomson Expires April 19, 2020 [Page 102]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Many transport parameters listed here have integer values. Those
@@ -5765,9 +5765,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 103]
+Iyengar & Thomson Expires April 19, 2020 [Page 103]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
initial_max_stream_data_bidi_remote (0x0006): This parameter is an
@@ -5821,9 +5821,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 104]
+Iyengar & Thomson Expires April 19, 2020 [Page 104]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
disable_active_migration (0x000c): The disable active migration
@@ -5877,9 +5877,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 105]
+Iyengar & Thomson Expires April 19, 2020 [Page 105]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
19. Frame Types and Formats
@@ -5933,9 +5933,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 106]
+Iyengar & Thomson Expires April 19, 2020 [Page 106]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
packets with associated ECN marks received on the connection up until
@@ -5989,9 +5989,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 107]
+Iyengar & Thomson Expires April 19, 2020 [Page 107]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
ACK Delay: A variable-length integer representing the time delta in
@@ -6045,9 +6045,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 108]
+Iyengar & Thomson Expires April 19, 2020 [Page 108]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
0 1 2 3
@@ -6101,9 +6101,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 109]
+Iyengar & Thomson Expires April 19, 2020 [Page 109]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
The largest value for an ACK Range is determined by cumulatively
@@ -6157,9 +6157,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 110]
+Iyengar & Thomson Expires April 19, 2020 [Page 110]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
CE Count: A variable-length integer representing the total number of
@@ -6213,9 +6213,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 111]
+Iyengar & Thomson Expires April 19, 2020 [Page 111]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
A STOP_SENDING frame can be sent for streams in the Recv or Size
@@ -6269,9 +6269,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 112]
+Iyengar & Thomson Expires April 19, 2020 [Page 112]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
0 1 2 3
@@ -6325,9 +6325,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 113]
+Iyengar & Thomson Expires April 19, 2020 [Page 113]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
NEW_TOKEN frames contain the following fields:
@@ -6381,9 +6381,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 114]
+Iyengar & Thomson Expires April 19, 2020 [Page 114]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
0 1 2 3
@@ -6437,9 +6437,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 115]
+Iyengar & Thomson Expires April 19, 2020 [Page 115]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
0 1 2 3
@@ -6493,9 +6493,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 116]
+Iyengar & Thomson Expires April 19, 2020 [Page 116]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Maximum Stream Data: A variable-length integer indicating the
@@ -6549,9 +6549,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 117]
+Iyengar & Thomson Expires April 19, 2020 [Page 117]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
and 11, but not stream 15. An endpoint MUST terminate a connection
@@ -6605,9 +6605,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 118]
+Iyengar & Thomson Expires April 19, 2020 [Page 118]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
STREAM_DATA_BLOCKED frames contain the following fields:
@@ -6661,9 +6661,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 119]
+Iyengar & Thomson Expires April 19, 2020 [Page 119]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
0 1 2 3
@@ -6717,9 +6717,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 120]
+Iyengar & Thomson Expires April 19, 2020 [Page 120]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Transmission errors, timeouts and retransmissions might cause the
@@ -6773,9 +6773,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 121]
+Iyengar & Thomson Expires April 19, 2020 [Page 121]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
RETIRE_CONNECTION_ID frames contain the following fields:
@@ -6829,9 +6829,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 122]
+Iyengar & Thomson Expires April 19, 2020 [Page 122]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
19.18. PATH_RESPONSE Frame
@@ -6885,9 +6885,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 123]
+Iyengar & Thomson Expires April 19, 2020 [Page 123]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
application-specific variant of CONNECTION_CLOSE (type 0x1d) does
@@ -6941,9 +6941,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 124]
+Iyengar & Thomson Expires April 19, 2020 [Page 124]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
INTERNAL_ERROR (0x1): The endpoint encountered an internal error and
@@ -6997,9 +6997,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 125]
+Iyengar & Thomson Expires April 19, 2020 [Page 125]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
In defining these error codes, several principles are applied. Error
@@ -7053,9 +7053,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 126]
+Iyengar & Thomson Expires April 19, 2020 [Page 126]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
key that is derived from this connection ID and salt specific to the
@@ -7109,9 +7109,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 127]
+Iyengar & Thomson Expires April 19, 2020 [Page 127]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
21.4. Slowloris Attacks
@@ -7165,9 +7165,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 128]
+Iyengar & Thomson Expires April 19, 2020 [Page 128]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Normally, clients will open streams sequentially, as explained in
@@ -7221,9 +7221,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 129]
+Iyengar & Thomson Expires April 19, 2020 [Page 129]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
an IP packet unless at least one QUIC packet in that IP packet is
@@ -7277,9 +7277,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 130]
+Iyengar & Thomson Expires April 19, 2020 [Page 130]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
of client-selected values; a Source Connection ID can be selected to
@@ -7333,9 +7333,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 131]
+Iyengar & Thomson Expires April 19, 2020 [Page 131]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+--------+-------------------------------------+---------------+
@@ -7389,9 +7389,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 132]
+Iyengar & Thomson Expires April 19, 2020 [Page 132]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Standards Action or IESG Review policies [RFC8126]. Values from 0x40
@@ -7445,9 +7445,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 133]
+Iyengar & Thomson Expires April 19, 2020 [Page 133]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Description: A brief description of the error code semantics, which
@@ -7501,9 +7501,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 134]
+Iyengar & Thomson Expires April 19, 2020 [Page 134]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+------+---------------------------+----------------+---------------+
@@ -7557,9 +7557,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 135]
+Iyengar & Thomson Expires April 19, 2020 [Page 135]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
23.1. Normative References
@@ -7573,12 +7573,12 @@ Internet-Draft QUIC Transport Protocol September 2019
[QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery (work in
- progress), September 2019.
+ progress), October 2019.
[QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls
- (work in progress), September 2019.
+ (work in progress), October 2019.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
@@ -7613,9 +7613,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 136]
+Iyengar & Thomson Expires April 19, 2020 [Page 136]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
@@ -7663,15 +7663,15 @@ Internet-Draft QUIC Transport Protocol September 2019
[QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC",
- draft-ietf-quic-invariants (work in progress), September
+ draft-ietf-quic-invariants (work in progress), October
2019.
-Iyengar & Thomson Expires March 19, 2020 [Page 137]
+Iyengar & Thomson Expires April 19, 2020 [Page 137]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
[QUIC-MANAGEABILITY]
@@ -7725,9 +7725,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 138]
+Iyengar & Thomson Expires April 19, 2020 [Page 138]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
@@ -7781,9 +7781,9 @@ Appendix A. Sample Packet Number Decoding Algorithm
-Iyengar & Thomson Expires March 19, 2020 [Page 139]
+Iyengar & Thomson Expires April 19, 2020 [Page 139]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Appendix B. Change Log
@@ -7827,21 +7827,24 @@ B.1. Since draft-ietf-quic-transport-22
that share a path (#2763, #2882)
o Allow smaller stateless resets and recommend a smaller minimum on
- packets that might trigger a stateless reset (#2770, #2869, #2927)
+ packets that might trigger a stateless reset (#2770, #2869, #2927,
+ #3007).
o Provide guidance around the interface to QUIC as used by
application protocols (#2805, #2857)
- o Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825,
- #2826)
-Iyengar & Thomson Expires March 19, 2020 [Page 140]
+
+Iyengar & Thomson Expires April 19, 2020 [Page 140]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+ o Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825,
+ #2826)
+
o Tighter rules about processing of rejected 0-RTT packets (#2829,
#2840, #2841)
@@ -7887,17 +7890,17 @@ B.3. Since draft-ietf-quic-transport-20
o When sending 0-RTT, only remembered transport parameters apply
(#2458, #2360, #2466, #2461)
- o Define handshake completion and confirmation; define clearer rules
- when it encryption keys should be discarded (#2214, #2267, #2673)
-
-Iyengar & Thomson Expires March 19, 2020 [Page 141]
+Iyengar & Thomson Expires April 19, 2020 [Page 141]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+ o Define handshake completion and confirmation; define clearer rules
+ when it encryption keys should be discarded (#2214, #2267, #2673)
+
o Prohibit path migration prior to handshake confirmation (#2309,
#2370)
@@ -7943,16 +7946,15 @@ B.5. Since draft-ietf-quic-transport-18
authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313)
- o Added discussion of the use of IPv6 flow labels (#2348, #2399)
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 142]
+Iyengar & Thomson Expires April 19, 2020 [Page 142]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+
+ o Added discussion of the use of IPv6 flow labels (#2348, #2399)
o A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420)
@@ -7999,16 +8001,17 @@ B.6. Since draft-ietf-quic-transport-17
o Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296)
- o Corrected requirements for migration to a preferred address
- (#2146, #2349)
-Iyengar & Thomson Expires March 19, 2020 [Page 143]
+Iyengar & Thomson Expires April 19, 2020 [Page 143]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+
+ o Corrected requirements for migration to a preferred address
+ (#2146, #2349)
o ACK of non-existent packet is illegal (#2298, #2302)
@@ -8056,16 +8059,15 @@ B.7. Since draft-ietf-quic-transport-16
o Require peers to replace retired connection IDs (#2085)
- o Servers are required to ignore Version Negotiation packets (#2088)
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 144]
+Iyengar & Thomson Expires April 19, 2020 [Page 144]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+ o Servers are required to ignore Version Negotiation packets (#2088)
+
o Tokens are repeated in all Initial packets (#2089)
o Clarified how PING frames are sent after loss (#2094)
@@ -8112,15 +8114,16 @@ B.10. Since draft-ietf-quic-transport-13
o Permit stateless reset in response to any packet (#1348, #1553)
- o Recommended defense against stateless reset spoofing (#1386,
- #1554)
-Iyengar & Thomson Expires March 19, 2020 [Page 145]
+Iyengar & Thomson Expires April 19, 2020 [Page 145]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+
+ o Recommended defense against stateless reset spoofing (#1386,
+ #1554)
o Prevent infinite stateless reset exchanges (#1443, #1627)
@@ -8168,15 +8171,15 @@ B.11. Since draft-ietf-quic-transport-12
o Added ECN feedback mechanisms and handling; new ACK_ECN frame
(#804, #805, #1372)
- o Changed rules and recommendations for use of new connection IDs
- (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465)
-
-Iyengar & Thomson Expires March 19, 2020 [Page 146]
+Iyengar & Thomson Expires April 19, 2020 [Page 146]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+
+ o Changed rules and recommendations for use of new connection IDs
+ (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465)
o Added a transport parameter to disable intentional connection
migration (#1271, #1447)
@@ -8223,16 +8226,15 @@ B.13. Since draft-ietf-quic-transport-10
o A Stateless Reset Token isn't mandatory (#818, #1191)
- o Removed implicit stream opening (#896, #1193)
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 147]
+Iyengar & Thomson Expires April 19, 2020 [Page 147]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+
+ o Removed implicit stream opening (#896, #1193)
o An empty STREAM frame can be used to open a stream without sending
data (#901, #1194)
@@ -8277,19 +8279,21 @@ B.14. Since draft-ietf-quic-transport-09
omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
-B.15. Since draft-ietf-quic-transport-08
- o Clarified requirements for BLOCKED usage (#65, #924)
-Iyengar & Thomson Expires March 19, 2020 [Page 148]
+Iyengar & Thomson Expires April 19, 2020 [Page 148]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+B.15. Since draft-ietf-quic-transport-08
+
+ o Clarified requirements for BLOCKED usage (#65, #924)
+
o BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928)
@@ -8335,16 +8339,15 @@ B.16. Since draft-ietf-quic-transport-07
* Stream limit transport parameters are now optional and default
to 0 (#970, #971)
- o The stream state machine has been split into read and write (#634,
- #894)
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 149]
+Iyengar & Thomson Expires April 19, 2020 [Page 149]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+
+ o The stream state machine has been split into read and write (#634,
+ #894)
o Employ variable-length integer encodings throughout (#595)
@@ -8391,17 +8394,18 @@ B.18. Since draft-ietf-quic-transport-05
o Refactor section on connection termination (#733, #748, #328,
#177)
- o Limit size of Version Negotiation packet (#585)
-
- o Clarify when and what to ack (#736)
-Iyengar & Thomson Expires March 19, 2020 [Page 150]
+Iyengar & Thomson Expires April 19, 2020 [Page 150]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
+ o Limit size of Version Negotiation packet (#585)
+
+ o Clarify when and what to ack (#736)
+
o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
o Clarify Keep-alive requirements (#729)
@@ -8449,13 +8453,9 @@ B.20. Since draft-ietf-quic-transport-03
-
-
-
-
-Iyengar & Thomson Expires March 19, 2020 [Page 151]
+Iyengar & Thomson Expires April 19, 2020 [Page 151]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
B.21. Since draft-ietf-quic-transport-02
@@ -8509,9 +8509,9 @@ B.21. Since draft-ietf-quic-transport-02
-Iyengar & Thomson Expires March 19, 2020 [Page 152]
+Iyengar & Thomson Expires April 19, 2020 [Page 152]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
B.22. Since draft-ietf-quic-transport-01
@@ -8565,9 +8565,9 @@ B.22. Since draft-ietf-quic-transport-01
-Iyengar & Thomson Expires March 19, 2020 [Page 153]
+Iyengar & Thomson Expires April 19, 2020 [Page 153]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
o Clarified that frames are not retransmitted, but the information
@@ -8621,9 +8621,9 @@ Internet-Draft QUIC Transport Protocol September 2019
-Iyengar & Thomson Expires March 19, 2020 [Page 154]
+Iyengar & Thomson Expires April 19, 2020 [Page 154]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
B.23. Since draft-ietf-quic-transport-00
@@ -8677,9 +8677,9 @@ Contributors
-Iyengar & Thomson Expires March 19, 2020 [Page 155]
+Iyengar & Thomson Expires April 19, 2020 [Page 155]
-Internet-Draft QUIC Transport Protocol September 2019
+Internet-Draft QUIC Transport Protocol October 2019
Authors' Addresses
@@ -8733,4 +8733,4 @@ Authors' Addresses
-Iyengar & Thomson Expires March 19, 2020 [Page 156]
+Iyengar & Thomson Expires April 19, 2020 [Page 156]
diff --git a/close3029/index.html b/ianswett-limit-bursts/index.html
similarity index 75%
rename from close3029/index.html
rename to ianswett-limit-bursts/index.html
index 7d6329ae28..eda4c48dcf 100644
--- a/close3029/index.html
+++ b/ianswett-limit-bursts/index.html
@@ -1,7 +1,7 @@
- quicwg/base-drafts close3029 preview
+ quicwg/base-drafts ianswett-limit-bursts preview
-