draft-ietf-quic-transport-25.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: July 25, 2020 Mozilla Expires: July 26, 2020 Mozilla
January 22, 2020 January 23, 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-25 draft-ietf-quic-transport-latest
Abstract Abstract
This document defines the core of the QUIC transport protocol. This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation. control and the use of TLS for key negotiation.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 25, 2020. This Internet-Draft will expire on July 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 43, line 36 skipping to change at page 43, line 36
The server uses the NEW_TOKEN frame Section 19.7 to provide the The server uses the NEW_TOKEN frame Section 19.7 to provide the
client with an address validation token that can be used to validate client with an address validation token that can be used to validate
future connections. The client includes this token in Initial future connections. The client includes this token in Initial
packets to provide address validation in a future connection. The packets to provide address validation in a future connection. The
client MUST include the token in all Initial packets it sends, unless client MUST include the token in all Initial packets it sends, unless
a Retry replaces the token with a newer one. The client MUST NOT use a Retry replaces the token with a newer one. The client MUST NOT use
the token provided in a Retry for future connections. Servers MAY the token provided in a Retry for future connections. Servers MAY
discard any Initial packet that does not carry the expected token. discard any Initial packet that does not carry the expected token.
Unlike the token that is created for a Retry packet, there might be Unlike the token that is created for a Retry packet, which is used
some time between when the token is created and when the token is immediately, the token sent in the NEW_TOKEN frame might be used
subsequently used. Thus, a token SHOULD have an expiration time, after some period of time has passed. Thus, a token SHOULD have an
which could be either an explicit expiration time or an issued expiration time, which could be either an explicit expiration time or
timestamp that can be used to dynamically calculate the expiration an issued timestamp that can be used to dynamically calculate the
time. A server can store the expiration time or include it in an expiration time. A server can store the expiration time or include
encrypted form in the token. it in an encrypted form in the token.
A token issued with NEW_TOKEN MUST NOT include information that would A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an on-path observer to the connection on allow values to be linked by an on-path observer to the connection on
which it was issued, unless the values are encrypted. For example, which it was issued, unless the values are encrypted. For example,
it cannot include the previous connection ID or addressing it cannot include the previous connection ID or addressing
information. A server MUST ensure that every NEW_TOKEN frame it information. A server MUST ensure that every NEW_TOKEN frame it
sends is unique across all clients, with the exception of those sent sends is unique across all clients, with the exception of those sent
to repair losses of previously sent NEW_TOKEN frames. Information to repair losses of previously sent NEW_TOKEN frames. Information
that allows the server to distinguish between tokens from Retry and that allows the server to distinguish between tokens from Retry and
NEW_TOKEN MAY be accessible to entities other than the server. NEW_TOKEN MAY be accessible to entities other than the server.
skipping to change at page 67, line 50 skipping to change at page 67, line 50
If an application-level error affects a single stream, but otherwise If an application-level error affects a single stream, but otherwise
leaves the connection in a recoverable state, the endpoint can send a leaves the connection in a recoverable state, the endpoint can send a
RESET_STREAM frame (Section 19.4) with an appropriate error code to RESET_STREAM frame (Section 19.4) with an appropriate error code to
terminate just the affected stream. terminate just the affected stream.
Resetting a stream without the involvement of the application Resetting a stream without the involvement of the application
protocol could cause the application protocol to enter an protocol could cause the application protocol to enter an
unrecoverable state. RESET_STREAM MUST only be instigated by the unrecoverable state. RESET_STREAM MUST only be instigated by the
application protocol that uses QUIC. application protocol that uses QUIC.
RESET_STREAM carries an application error code, for which the The semantics of the application error code carried in RESET_STREAM
semantics are defined by the application protocol. Only the are defined by the application protocol. Only the application
application protocol is able to cause a stream to be terminated. A protocol is able to cause a stream to be terminated. A local
local instance of the application protocol uses a direct API call and instance of the application protocol uses a direct API call and a
a remote instance uses the STOP_SENDING frame, which triggers an remote instance uses the STOP_SENDING frame, which triggers an
automatic RESET_STREAM. automatic RESET_STREAM.
Application protocols SHOULD define rules for handling streams that Application protocols SHOULD define rules for handling streams that
are prematurely cancelled by either endpoint. are prematurely cancelled by either endpoint.
12. Packets and Frames 12. Packets and Frames
QUIC endpoints communicate by exchanging packets. Packets have QUIC endpoints communicate by exchanging packets. Packets have
confidentiality and integrity protection (see Section 12.1) and are confidentiality and integrity protection (see Section 12.1) and are
carried in UDP datagrams (see Section 12.2). carried in UDP datagrams (see Section 12.2).
skipping to change at page 68, line 32 skipping to change at page 68, line 32
Section 17.2.1). Section 17.2.1).
Packets with the short header (Section 17.3) are designed for minimal Packets with the short header (Section 17.3) are designed for minimal
overhead and are used after a connection is established and 1-RTT overhead and are used after a connection is established and 1-RTT
keys are available. keys are available.
12.1. Protected Packets 12.1. Protected Packets
All QUIC packets except Version Negotiation packets use authenticated All QUIC packets except Version Negotiation packets use authenticated
encryption with additional data (AEAD) [RFC5116] to provide encryption with additional data (AEAD) [RFC5116] to provide
confidentiality and integrity protection. Retry packets use an AEAD confidentiality and integrity protection. Retry packets use AEAD to
to provide integrity protection. Details of packet protection are provide integrity protection. Details of packet protection are found
found in [QUIC-TLS]; this section includes an overview of the in [QUIC-TLS]; this section includes an overview of the process.
process.
Initial packets are protected using keys that are statically derived. Initial packets are protected using keys that are statically derived.
This packet protection is not effective confidentiality protection. This packet protection is not effective confidentiality protection.
Initial protection only exists to ensure that the sender of the Initial protection only exists to ensure that the sender of the
packet is on the network path. Any entity that receives the Initial packet is on the network path. Any entity that receives the Initial
packet from a client can recover the keys necessary to remove packet packet from a client can recover the keys necessary to remove packet
protection or to generate packets that will be successfully protection or to generate packets that will be successfully
authenticated. authenticated.
All other packets are protected with keys derived from the All other packets are protected with keys derived from the
skipping to change at page 73, line 52 skipping to change at page 73, line 52
| 0x1b | PATH_RESPONSE | Section 19.18 | __01 | | 0x1b | PATH_RESPONSE | Section 19.18 | __01 |
| | | | | | | | | |
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | IH_1* | | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | IH_1* |
| | | | | | | | | |
| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 |
+-------------+----------------------+----------------+---------+ +-------------+----------------------+----------------+---------+
Table 3: Frame Types Table 3: Frame Types
The "Packets" column in Table 3 does not form part of the IANA The "Packets" column in Table 3 does not form part of the IANA
registry (see Section 22.3). This column summarizes the types of registry (see Section 22.3). This column lists the types of packets
packets that each frame type can appear in, indicated as up to four that each frame type can appear in, indicated by the following
characters indicating: characters:
I: Initial (Section 17.2.2) I: Initial (Section 17.2.2)
H: Handshake (Section 17.2.4) H: Handshake (Section 17.2.4)
0: 0-RTT (Section 17.2.3) 0: 0-RTT (Section 17.2.3)
1: 1-RTT (Section 17.3) 1: 1-RTT (Section 17.3)
*: A CONNECTION_CLOSE frame of type 0x1c can appear in Initial, *: A CONNECTION_CLOSE frame of type 0x1c can appear in Initial,
skipping to change at page 78, line 48 skipping to change at page 78, line 48
limit the number of ACK Ranges it sends. A receiver can do this even limit the number of ACK Ranges it sends. A receiver can do this even
without receiving acknowledgment of its ACK frames, with the without receiving acknowledgment of its ACK frames, with the
knowledge this could cause the sender to unnecessarily retransmit knowledge this could cause the sender to unnecessarily retransmit
some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare
packets lost after sufficiently newer packets are acknowledged. packets lost after sufficiently newer packets are acknowledged.
Therefore, the receiver SHOULD repeatedly acknowledge newly received Therefore, the receiver SHOULD repeatedly acknowledge newly received
packets in preference to packets received in the past. packets in preference to packets received in the past.
13.2.5. Measuring and Reporting Host Delay 13.2.5. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between when An endpoint measures the delays intentionally introduced between the
the packet with the largest packet number is received and an time the packet with the largest packet number is received and the
acknowledgment is sent. The endpoint encodes this delay in the Ack time an acknowledgment is sent. The endpoint encodes this delay in
Delay field of an ACK frame (see Section 19.3). This allows the the Ack Delay field of an ACK frame (see Section 19.3). This allows
receiver of the ACK to adjust for any intentional delays, which is the receiver of the ACK to adjust for any intentional delays, which
important for getting a better estimate of the path RTT when is important for getting a better estimate of the path RTT when
acknowledgments are delayed. A packet might be held in the OS kernel acknowledgments are delayed. A packet might be held in the OS kernel
or elsewhere on the host before being processed. An endpoint MUST or elsewhere on the host before being processed. An endpoint MUST
NOT include delays that it does not control when populating the Ack NOT include delays that it does not control when populating the Ack
Delay field in an ACK frame. Delay field in an ACK frame.
13.2.6. ACK Frames and Packet Protection 13.2.6. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed (see Section 12.1). For number space as the packet being ACKed (see Section 12.1). For
instance, packets that are protected with 1-RTT keys MUST be instance, packets that are protected with 1-RTT keys MUST be
skipping to change at page 151, line 21 skipping to change at page 151, line 21
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-13 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-13
(work in progress), January 2020. (work in progress), January 2020.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-25 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls-
tls-25 (work in progress). latest (work in progress).
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 153, line 7 skipping to change at page 153, line 7
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-07 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-06 Transport Protocol", draft-ietf-quic-manageability-06
(work in progress), January 2020. (work in progress), January 2020.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
 End of changes. 11 change blocks. 
34 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/