draft-ietf-quic-transport-34.txt | draft-ietf-quic-transport-latest.txt | |||
---|---|---|---|---|
QUIC Working Group J. Iyengar, Ed. | Internet Engineering Task Force (IETF) J. Iyengar, Ed. | |||
Internet-Draft Fastly | Request for Comments: 9000 Fastly | |||
Intended status: Standards Track M. Thomson, Ed. | Category: Standards Track M. Thomson, Ed. | |||
Expires: July 19, 2021 Mozilla | ISSN: 2070-1721 Mozilla | |||
January 15, 2021 | May 2021 | |||
QUIC: A UDP-Based Multiplexed and Secure Transport | QUIC: A UDP-Based Multiplexed and Secure Transport | |||
draft-ietf-quic-transport-34 | ||||
Abstract | Abstract | |||
This document defines the core of the QUIC transport protocol. QUIC | This document defines the core of the QUIC transport protocol. QUIC | |||
provides applications with flow-controlled streams for structured | provides applications with flow-controlled streams for structured | |||
communication, low-latency connection establishment, and network path | communication, low-latency connection establishment, and network path | |||
migration. QUIC includes security measures that ensure | migration. QUIC includes security measures that ensure | |||
confidentiality, integrity, and availability in a range of deployment | confidentiality, integrity, and availability in a range of deployment | |||
circumstances. Accompanying documents describe the integration of | circumstances. Accompanying documents describe the integration of | |||
TLS for key negotiation, loss detection, and an exemplary congestion | TLS for key negotiation, loss detection, and an exemplary congestion | |||
control algorithm. | control algorithm. | |||
DO NOT DEPLOY THIS VERSION OF QUIC | ||||
DO NOT DEPLOY THIS VERSION OF QUIC UNTIL IT IS IN AN RFC. This | ||||
version is still a work in progress. For trial deployments, please | ||||
use earlier versions. | ||||
Note to Readers | ||||
Discussion of this draft takes place on the QUIC working group | ||||
mailing list (quic@ietf.org [1]), which is archived at | ||||
<https://mailarchive.ietf.org/arch/search/?email_list=quic> | ||||
Working Group information can be found at <https://github.com/ | ||||
quicwg>; source code and issues list for this draft can be found at | ||||
<https://github.com/quicwg/base-drafts/labels/-transport>. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
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 | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on July 19, 2021. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9000. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 8 | 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 7 | |||
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 10 | 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8 | |||
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 11 | 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9 | |||
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 12 | 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 11 | |||
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 13 | 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 12 | |||
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 14 | 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13 | |||
2.4. Operations on Streams . . . . . . . . . . . . . . . . . . 14 | 2.4. Operations on Streams . . . . . . . . . . . . . . . . . . 13 | |||
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 15 | 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 16 | 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 15 | |||
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 18 | 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 17 | |||
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 21 | 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 20 | |||
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 21 | 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 20 | |||
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 22 | 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 22 | |||
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23 | 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 24 | 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 23 | |||
4.2. Increasing Flow Control Limits . . . . . . . . . . . . . 25 | 4.2. Increasing Flow Control Limits . . . . . . . . . . . . . 24 | |||
4.3. Flow Control Performance . . . . . . . . . . . . . . . . 26 | 4.3. Flow Control Performance . . . . . . . . . . . . . . . . 25 | |||
4.4. Handling Stream Cancellation . . . . . . . . . . . . . . 26 | 4.4. Handling Stream Cancellation . . . . . . . . . . . . . . 25 | |||
4.5. Stream Final Size . . . . . . . . . . . . . . . . . . . . 27 | 4.5. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26 | |||
4.6. Controlling Concurrency . . . . . . . . . . . . . . . . . 27 | 4.6. Controlling Concurrency . . . . . . . . . . . . . . . . . 27 | |||
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 29 | 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 28 | |||
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 30 | 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 29 | |||
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 31 | 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 31 | |||
5.2. Matching Packets to Connections . . . . . . . . . . . . . 33 | 5.2. Matching Packets to Connections . . . . . . . . . . . . . 32 | |||
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 33 | 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 33 | |||
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 34 | 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 33 | |||
5.2.3. Considerations for Simple Load Balancers . . . . . . 35 | 5.2.3. Considerations for Simple Load Balancers . . . . . . 34 | |||
5.3. Operations on Connections . . . . . . . . . . . . . . . . 35 | 5.3. Operations on Connections . . . . . . . . . . . . . . . . 34 | |||
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 36 | 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 36 | |||
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 37 | 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 36 | |||
6.2. Handling Version Negotiation Packets . . . . . . . . . . 37 | 6.2. Handling Version Negotiation Packets . . . . . . . . . . 36 | |||
6.2.1. Version Negotiation Between Draft Versions . . . . . 37 | 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 37 | |||
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 38 | 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 37 | |||
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 38 | 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 39 | |||
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 40 | 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 40 | |||
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 41 | 7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 41 | |||
7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 42 | 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 43 | |||
7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 44 | 7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 44 | |||
7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 45 | 7.4.2. New Transport Parameters . . . . . . . . . . . . . . 46 | |||
7.4.2. New Transport Parameters . . . . . . . . . . . . . . 47 | 7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 47 | |||
7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 48 | 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 47 | |||
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 48 | 8.1. Address Validation during Connection Establishment . . . 48 | |||
8.1. Address Validation During Connection Establishment . . . 49 | 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 49 | |||
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 50 | 8.1.2. Address Validation Using Retry Packets . . . . . . . 49 | |||
8.1.2. Address Validation using Retry Packets . . . . . . . 50 | 8.1.3. Address Validation for Future Connections . . . . . . 50 | |||
8.1.3. Address Validation for Future Connections . . . . . . 51 | 8.1.4. Address Validation Token Integrity . . . . . . . . . 52 | |||
8.1.4. Address Validation Token Integrity . . . . . . . . . 53 | 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 53 | |||
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 54 | 8.2.1. Initiating Path Validation . . . . . . . . . . . . . 54 | |||
8.2.1. Initiating Path Validation . . . . . . . . . . . . . 55 | 8.2.2. Path Validation Responses . . . . . . . . . . . . . . 55 | |||
8.2.2. Path Validation Responses . . . . . . . . . . . . . . 56 | 8.2.3. Successful Path Validation . . . . . . . . . . . . . 56 | |||
8.2.3. Successful Path Validation . . . . . . . . . . . . . 57 | 8.2.4. Failed Path Validation . . . . . . . . . . . . . . . 56 | |||
8.2.4. Failed Path Validation . . . . . . . . . . . . . . . 57 | 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 57 | |||
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 58 | 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 58 | |||
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 59 | 9.2. Initiating Connection Migration . . . . . . . . . . . . . 58 | |||
9.2. Initiating Connection Migration . . . . . . . . . . . . . 59 | 9.3. Responding to Connection Migration . . . . . . . . . . . 59 | |||
9.3. Responding to Connection Migration . . . . . . . . . . . 60 | 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 59 | |||
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 60 | 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 60 | |||
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 61 | 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 60 | |||
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 61 | 9.4. Loss Detection and Congestion Control . . . . . . . . . . 61 | |||
9.4. Loss Detection and Congestion Control . . . . . . . . . . 62 | 9.5. Privacy Implications of Connection Migration . . . . . . 62 | |||
9.5. Privacy Implications of Connection Migration . . . . . . 63 | 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 64 | |||
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 65 | 9.6.1. Communicating a Preferred Address . . . . . . . . . . 64 | |||
9.6.1. Communicating a Preferred Address . . . . . . . . . . 65 | 9.6.2. Migration to a Preferred Address . . . . . . . . . . 64 | |||
9.6.2. Migration to a Preferred Address . . . . . . . . . . 65 | 9.6.3. Interaction of Client Migration and Preferred Address 65 | |||
9.6.3. Interaction of Client Migration and Preferred Address 66 | 9.7. Use of IPv6 Flow Label and Migration . . . . . . . . . . 66 | |||
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 67 | 10. Connection Termination . . . . . . . . . . . . . . . . . . . 66 | |||
10. Connection Termination . . . . . . . . . . . . . . . . . . . 67 | 10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 66 | |||
10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 67 | 10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 67 | |||
10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 68 | 10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 67 | |||
10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 68 | 10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 68 | |||
10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 69 | 10.2.1. Closing Connection State . . . . . . . . . . . . . . 69 | |||
10.2.1. Closing Connection State . . . . . . . . . . . . . . 70 | 10.2.2. Draining Connection State . . . . . . . . . . . . . 70 | |||
10.2.2. Draining Connection State . . . . . . . . . . . . . 71 | 10.2.3. Immediate Close during the Handshake . . . . . . . . 70 | |||
10.2.3. Immediate Close During the Handshake . . . . . . . . 71 | 10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 72 | |||
10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 73 | 10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 74 | |||
10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 75 | 10.3.2. Calculating a Stateless Reset Token . . . . . . . . 75 | |||
10.3.2. Calculating a Stateless Reset Token . . . . . . . . 76 | 10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 76 | |||
10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 77 | 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 77 | |||
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 78 | 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 77 | |||
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 78 | 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 78 | |||
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 79 | 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 79 | |||
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 80 | 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 79 | |||
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 80 | 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 80 | |||
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 81 | 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 81 | |||
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 82 | 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 82 | |||
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 83 | 12.5. Frames and Number Spaces . . . . . . . . . . . . . . . . 86 | |||
12.5. Frames and Number Spaces . . . . . . . . . . . . . . . . 87 | 13. Packetization and Reliability . . . . . . . . . . . . . . . . 87 | |||
13. Packetization and Reliability . . . . . . . . . . . . . . . . 88 | 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 87 | |||
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 88 | 13.2. Generating Acknowledgments . . . . . . . . . . . . . . . 88 | |||
13.2. Generating Acknowledgments . . . . . . . . . . . . . . . 89 | 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 88 | |||
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 89 | 13.2.2. Acknowledgment Frequency . . . . . . . . . . . . . . 89 | |||
13.2.2. Acknowledgment Frequency . . . . . . . . . . . . . . 90 | 13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 90 | |||
13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 91 | 13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 91 | |||
13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 92 | 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 92 | |||
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 93 | 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 92 | |||
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 93 | 13.2.7. PADDING Frames Consume Congestion Window . . . . . . 92 | |||
13.2.7. PADDING Frames Consume Congestion Window . . . . . . 93 | 13.3. Retransmission of Information . . . . . . . . . . . . . 93 | |||
13.3. Retransmission of Information . . . . . . . . . . . . . 94 | 13.4. Explicit Congestion Notification . . . . . . . . . . . . 95 | |||
13.4. Explicit Congestion Notification . . . . . . . . . . . . 96 | 13.4.1. Reporting ECN Counts . . . . . . . . . . . . . . . . 96 | |||
13.4.1. Reporting ECN Counts . . . . . . . . . . . . . . . . 97 | 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 96 | |||
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 97 | 14. Datagram Size . . . . . . . . . . . . . . . . . . . . . . . . 98 | |||
14. Datagram Size . . . . . . . . . . . . . . . . . . . . . . . . 99 | 14.1. Initial Datagram Size . . . . . . . . . . . . . . . . . 99 | |||
14.1. Initial Datagram Size . . . . . . . . . . . . . . . . . 100 | 14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 100 | |||
14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 101 | 14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 101 | |||
14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 102 | 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 102 | |||
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 103 | 14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 102 | |||
14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 103 | 14.3.2. Validating the Network Path with DPLPMTUD . . . . . 102 | |||
14.3.2. Validating the Network Path with DPLPMTUD . . . . . 103 | 14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 102 | |||
14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 103 | 14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 102 | |||
14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 103 | 14.4.1. PMTU Probes Containing Source Connection ID . . . . 103 | |||
14.4.1. PMTU Probes Containing Source Connection ID . . . . 104 | 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 103 | |||
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 104 | 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 104 | |||
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 105 | 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 105 | |||
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 106 | 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 105 | |||
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 106 | 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 106 | |||
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 107 | 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 109 | |||
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 110 | 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 110 | |||
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 111 | 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 112 | |||
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 113 | ||||
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 114 | 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 114 | |||
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 116 | 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 115 | |||
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 118 | 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 117 | |||
17.3.1. 1-RTT Packet . . . . . . . . . . . . . . . . . . . . 118 | 17.3.1. 1-RTT Packet . . . . . . . . . . . . . . . . . . . . 117 | |||
17.4. Latency Spin Bit . . . . . . . . . . . . . . . . . . . . 120 | 17.4. Latency Spin Bit . . . . . . . . . . . . . . . . . . . . 119 | |||
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 121 | 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 120 | |||
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 122 | 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 121 | |||
18.2. Transport Parameter Definitions . . . . . . . . . . . . 122 | 18.2. Transport Parameter Definitions . . . . . . . . . . . . 121 | |||
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 126 | 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 125 | |||
19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 126 | 19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 125 | |||
19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 127 | 19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 126 | |||
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 127 | 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 126 | |||
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 129 | 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 128 | |||
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 130 | 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 129 | |||
19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 131 | 19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 130 | |||
19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 132 | 19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 131 | |||
19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 132 | 19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 131 | |||
19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 133 | 19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 132 | |||
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 134 | 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 133 | |||
19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 136 | 19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 135 | |||
19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 136 | 19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 135 | |||
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 137 | 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 136 | |||
19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 138 | 19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 137 | |||
19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 139 | 19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 138 | |||
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 139 | 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 138 | |||
19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 140 | 19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 139 | |||
19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 141 | 19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 140 | |||
19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 142 | 19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 141 | |||
19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 143 | 19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 142 | |||
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 143 | 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 142 | |||
19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 144 | 19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 143 | |||
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 145 | 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 144 | |||
20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 145 | 20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 144 | |||
20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 146 | 20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 145 | |||
20.2. Application Protocol Error Codes . . . . . . . . . . . . 147 | 20.2. Application Protocol Error Codes . . . . . . . . . . . . 146 | |||
21. Security Considerations . . . . . . . . . . . . . . . . . . . 148 | 21. Security Considerations . . . . . . . . . . . . . . . . . . . 147 | |||
21.1. Overview of Security Properties . . . . . . . . . . . . 148 | 21.1. Overview of Security Properties . . . . . . . . . . . . 147 | |||
21.1.1. Handshake . . . . . . . . . . . . . . . . . . . . . 148 | 21.1.1. Handshake . . . . . . . . . . . . . . . . . . . . . 147 | |||
21.1.2. Protected Packets . . . . . . . . . . . . . . . . . 150 | 21.1.2. Protected Packets . . . . . . . . . . . . . . . . . 149 | |||
21.1.3. Connection Migration . . . . . . . . . . . . . . . . 151 | 21.1.3. Connection Migration . . . . . . . . . . . . . . . . 150 | |||
21.2. Handshake Denial of Service . . . . . . . . . . . . . . 155 | 21.2. Handshake Denial of Service . . . . . . . . . . . . . . 154 | |||
21.3. Amplification Attack . . . . . . . . . . . . . . . . . . 156 | 21.3. Amplification Attack . . . . . . . . . . . . . . . . . . 155 | |||
21.4. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 156 | 21.4. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 155 | |||
21.5. Request Forgery Attacks . . . . . . . . . . . . . . . . 157 | 21.5. Request Forgery Attacks . . . . . . . . . . . . . . . . 156 | |||
21.5.1. Control Options for Endpoints . . . . . . . . . . . 158 | 21.5.1. Control Options for Endpoints . . . . . . . . . . . 157 | |||
21.5.2. Request Forgery with Client Initial Packets . . . . 159 | 21.5.2. Request Forgery with Client Initial Packets . . . . 158 | |||
21.5.3. Request Forgery with Preferred Addresses . . . . . . 160 | 21.5.3. Request Forgery with Preferred Addresses . . . . . . 159 | |||
21.5.4. Request Forgery with Spoofed Migration . . . . . . . 160 | 21.5.4. Request Forgery with Spoofed Migration . . . . . . . 159 | |||
21.5.5. Request Forgery with Version Negotiation . . . . . . 161 | 21.5.5. Request Forgery with Version Negotiation . . . . . . 160 | |||
21.5.6. Generic Request Forgery Countermeasures . . . . . . 161 | 21.5.6. Generic Request Forgery Countermeasures . . . . . . 160 | |||
21.6. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 162 | 21.6. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 161 | |||
21.7. Stream Fragmentation and Reassembly Attacks . . . . . . 162 | 21.7. Stream Fragmentation and Reassembly Attacks . . . . . . 161 | |||
21.8. Stream Commitment Attack . . . . . . . . . . . . . . . . 163 | 21.8. Stream Commitment Attack . . . . . . . . . . . . . . . . 162 | |||
21.9. Peer Denial of Service . . . . . . . . . . . . . . . . . 163 | 21.9. Peer Denial of Service . . . . . . . . . . . . . . . . . 162 | |||
21.10. Explicit Congestion Notification Attacks . . . . . . . . 164 | 21.10. Explicit Congestion Notification Attacks . . . . . . . . 163 | |||
21.11. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 164 | 21.11. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 163 | |||
21.12. Version Downgrade . . . . . . . . . . . . . . . . . . . 165 | 21.12. Version Downgrade . . . . . . . . . . . . . . . . . . . 164 | |||
21.13. Targeted Attacks by Routing . . . . . . . . . . . . . . 165 | 21.13. Targeted Attacks by Routing . . . . . . . . . . . . . . 164 | |||
21.14. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 165 | 21.14. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 164 | |||
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 165 | 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164 | |||
22.1. Registration Policies for QUIC Registries . . . . . . . 166 | 22.1. Registration Policies for QUIC Registries . . . . . . . 165 | |||
22.1.1. Provisional Registrations . . . . . . . . . . . . . 166 | 22.1.1. Provisional Registrations . . . . . . . . . . . . . 165 | |||
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 167 | 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 166 | |||
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 167 | 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 166 | |||
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 168 | 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 167 | |||
22.2. QUIC Versions Registry . . . . . . . . . . . . . . . . . 168 | 22.2. QUIC Versions Registry . . . . . . . . . . . . . . . . . 167 | |||
22.3. QUIC Transport Parameter Registry . . . . . . . . . . . 169 | 22.3. QUIC Transport Parameters Registry . . . . . . . . . . . 168 | |||
22.4. QUIC Frame Types Registry . . . . . . . . . . . . . . . 171 | 22.4. QUIC Frame Types Registry . . . . . . . . . . . . . . . 170 | |||
22.5. QUIC Transport Error Codes Registry . . . . . . . . . . 171 | 22.5. QUIC Transport Error Codes Registry . . . . . . . . . . 170 | |||
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 173 | ||||
23.1. Normative References . . . . . . . . . . . . . . . . . . 173 | 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 172 | |||
23.2. Informative References . . . . . . . . . . . . . . . . . 175 | 23.1. Normative References . . . . . . . . . . . . . . . . . . 172 | |||
23.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 178 | 23.2. Informative References . . . . . . . . . . . . . . . . . 174 | |||
Appendix A. Pseudocode . . . . . . . . . . . . . . . . . . . . . 178 | Appendix A. Pseudocode . . . . . . . . . . . . . . . . . . . . . 177 | |||
A.1. Sample Variable-Length Integer Decoding . . . . . . . . . 178 | A.1. Sample Variable-Length Integer Decoding . . . . . . . . . 177 | |||
A.2. Sample Packet Number Encoding Algorithm . . . . . . . . . 179 | A.2. Sample Packet Number Encoding Algorithm . . . . . . . . . 178 | |||
A.3. Sample Packet Number Decoding Algorithm . . . . . . . . . 180 | A.3. Sample Packet Number Decoding Algorithm . . . . . . . . . 179 | |||
A.4. Sample ECN Validation Algorithm . . . . . . . . . . . . . 181 | A.4. Sample ECN Validation Algorithm . . . . . . . . . . . . . 180 | |||
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 181 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 181 | |||
B.1. Since draft-ietf-quic-transport-32 . . . . . . . . . . . 182 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 184 | |||
B.2. Since draft-ietf-quic-transport-31 . . . . . . . . . . . 182 | ||||
B.3. Since draft-ietf-quic-transport-30 . . . . . . . . . . . 183 | ||||
B.4. Since draft-ietf-quic-transport-29 . . . . . . . . . . . 183 | ||||
B.5. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 184 | ||||
B.6. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 184 | ||||
B.7. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 185 | ||||
B.8. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 185 | ||||
B.9. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 185 | ||||
B.10. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 186 | ||||
B.11. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 187 | ||||
B.12. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 188 | ||||
B.13. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 188 | ||||
B.14. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 189 | ||||
B.15. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 190 | ||||
B.16. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 190 | ||||
B.17. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 191 | ||||
B.18. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 192 | ||||
B.19. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 192 | ||||
B.20. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 193 | ||||
B.21. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 193 | ||||
B.22. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 194 | ||||
B.23. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 195 | ||||
B.24. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 195 | ||||
B.25. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 196 | ||||
B.26. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 196 | ||||
B.27. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 197 | ||||
B.28. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 198 | ||||
B.29. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 198 | ||||
B.30. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 199 | ||||
B.31. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 199 | ||||
B.32. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 200 | ||||
B.33. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 202 | ||||
B.34. Since draft-hamilton-quic-transport-protocol-01 . . . . . 202 | ||||
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 202 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 204 | ||||
1. Overview | 1. Overview | |||
QUIC is a secure general-purpose transport protocol. This document | QUIC is a secure general-purpose transport protocol. This document | |||
defines version 1 of QUIC, which conforms to the version-independent | defines version 1 of QUIC, which conforms to the version-independent | |||
properties of QUIC defined in [QUIC-INVARIANTS]. | properties of QUIC defined in [QUIC-INVARIANTS]. | |||
QUIC is a connection-oriented protocol that creates a stateful | QUIC is a connection-oriented protocol that creates a stateful | |||
interaction between a client and server. | interaction between a client and server. | |||
The QUIC handshake combines negotiation of cryptographic and | The QUIC handshake combines negotiation of cryptographic and | |||
transport parameters. QUIC integrates the TLS ([TLS13]) handshake, | transport parameters. QUIC integrates the TLS handshake [TLS13], | |||
although using a customized framing for protecting packets. The | although using a customized framing for protecting packets. The | |||
integration of TLS and QUIC is described in more detail in | integration of TLS and QUIC is described in more detail in | |||
[QUIC-TLS]. The handshake is structured to permit the exchange of | [QUIC-TLS]. The handshake is structured to permit the exchange of | |||
application data as soon as possible. This includes an option for | application data as soon as possible. This includes an option for | |||
clients to send data immediately (0-RTT), which requires some form of | clients to send data immediately (0-RTT), which requires some form of | |||
prior communication or configuration to enable. | prior communication or configuration to enable. | |||
Endpoints communicate in QUIC by exchanging QUIC packets. Most | Endpoints communicate in QUIC by exchanging QUIC packets. Most | |||
packets contain frames, which carry control information and | packets contain frames, which carry control information and | |||
application data between endpoints. QUIC authenticates the entirety | application data between endpoints. QUIC authenticates the entirety | |||
of each packet and encrypts as much of each packet as is practical. | of each packet and encrypts as much of each packet as is practical. | |||
QUIC packets are carried in UDP datagrams ([UDP]) to better | QUIC packets are carried in UDP datagrams [UDP] to better facilitate | |||
facilitate deployment in existing systems and networks. | deployment in existing systems and networks. | |||
Application protocols exchange information over a QUIC connection via | Application protocols exchange information over a QUIC connection via | |||
streams, which are ordered sequences of bytes. Two types of stream | streams, which are ordered sequences of bytes. Two types of streams | |||
can be created: bidirectional streams, which allow both endpoints to | can be created: bidirectional streams, which allow both endpoints to | |||
send data; and unidirectional streams, which allow a single endpoint | send data; and unidirectional streams, which allow a single endpoint | |||
to send data. A credit-based scheme is used to limit stream creation | to send data. A credit-based scheme is used to limit stream creation | |||
and to bound the amount of data that can be sent. | and to bound the amount of data that can be sent. | |||
QUIC provides the necessary feedback to implement reliable delivery | QUIC provides the necessary feedback to implement reliable delivery | |||
and congestion control. An algorithm for detecting and recovering | and congestion control. An algorithm for detecting and recovering | |||
from loss of data is described in [QUIC-RECOVERY]. QUIC depends on | from loss of data is described in Section 6 of [QUIC-RECOVERY]. QUIC | |||
congestion control to avoid network congestion. An exemplary | depends on congestion control to avoid network congestion. An | |||
congestion control algorithm is also described in [QUIC-RECOVERY]. | exemplary congestion control algorithm is described in Section 7 of | |||
[QUIC-RECOVERY]. | ||||
QUIC connections are not strictly bound to a single network path. | QUIC connections are not strictly bound to a single network path. | |||
Connection migration uses connection identifiers to allow connections | Connection migration uses connection identifiers to allow connections | |||
to transfer to a new network path. Only clients are able to migrate | to transfer to a new network path. Only clients are able to migrate | |||
in this version of QUIC. This design also allows connections to | in this version of QUIC. This design also allows connections to | |||
continue after changes in network topology or address mappings, such | continue after changes in network topology or address mappings, such | |||
as might be caused by NAT rebinding. | as might be caused by NAT rebinding. | |||
Once established, multiple options are provided for connection | Once established, multiple options are provided for connection | |||
termination. Applications can manage a graceful shutdown, endpoints | termination. Applications can manage a graceful shutdown, endpoints | |||
skipping to change at page 9, line 4 ¶ | skipping to change at page 7, line 40 ¶ | |||
* Section 4 outlines the operation of flow control. | * Section 4 outlines the operation of flow control. | |||
o Connections are the context in which QUIC endpoints communicate. | o Connections are the context in which QUIC endpoints communicate. | |||
* Section 5 describes core concepts related to connections, | * Section 5 describes core concepts related to connections, | |||
* Section 6 describes version negotiation, | * Section 6 describes version negotiation, | |||
* Section 7 details the process for establishing connections, | * Section 7 details the process for establishing connections, | |||
* Section 8 describes address validation and critical denial of | ||||
* Section 8 describes address validation and critical denial-of- | ||||
service mitigations, | service mitigations, | |||
* Section 9 describes how endpoints migrate a connection to a new | * Section 9 describes how endpoints migrate a connection to a new | |||
network path, | network path, | |||
* Section 10 lists the options for terminating an open | * Section 10 lists the options for terminating an open | |||
connection, and | connection, and | |||
* Section 11 provides guidance for stream and connection error | * Section 11 provides guidance for stream and connection error | |||
handling. | handling. | |||
skipping to change at page 9, line 29 ¶ | skipping to change at page 8, line 18 ¶ | |||
* Section 13 defines models for the transmission, retransmission, | * Section 13 defines models for the transmission, retransmission, | |||
and acknowledgment of data, and | and acknowledgment of data, and | |||
* Section 14 specifies rules for managing the size of datagrams | * Section 14 specifies rules for managing the size of datagrams | |||
carrying QUIC packets. | carrying QUIC packets. | |||
o Finally, encoding details of QUIC protocol elements are described | o Finally, encoding details of QUIC protocol elements are described | |||
in: | in: | |||
* Section 15 (Versions), | * Section 15 (versions), | |||
* Section 16 (Integer Encoding), | * Section 16 (integer encoding), | |||
* Section 17 (Packet Headers), | * Section 17 (packet headers), | |||
* Section 18 (Transport Parameters), | * Section 18 (transport parameters), | |||
* Section 19 (Frames), and | * Section 19 (frames), and | |||
* Section 20 (Errors). | * Section 20 (errors). | |||
Accompanying documents describe QUIC's loss detection and congestion | Accompanying documents describe QUIC's loss detection and congestion | |||
control [QUIC-RECOVERY], and the use of TLS and other cryptographic | control [QUIC-RECOVERY], and the use of TLS and other cryptographic | |||
mechanisms [QUIC-TLS]. | mechanisms [QUIC-TLS]. | |||
This document defines QUIC version 1, which conforms to the protocol | This document defines QUIC version 1, which conforms to the protocol | |||
invariants in [QUIC-INVARIANTS]. | invariants in [QUIC-INVARIANTS]. | |||
To refer to QUIC version 1, cite this document. References to the | To refer to QUIC version 1, cite this document. References to the | |||
limited set of version-independent properties of QUIC can cite | limited set of version-independent properties of QUIC can cite | |||
[QUIC-INVARIANTS]. | [QUIC-INVARIANTS]. | |||
1.2. Terms and Definitions | 1.2. Terms and Definitions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
Commonly used terms in the document are described below. | Commonly used terms in this document are described below. | |||
QUIC: The transport protocol described by this document. QUIC is a | QUIC: The transport protocol described by this document. QUIC is a | |||
name, not an acronym. | name, not an acronym. | |||
Endpoint: An entity that can participate in a QUIC connection by | Endpoint: An entity that can participate in a QUIC connection by | |||
generating, receiving, and processing QUIC packets. There are | generating, receiving, and processing QUIC packets. There are | |||
only two types of endpoint in QUIC: client and server. | only two types of endpoints in QUIC: client and server. | |||
Client: The endpoint that initiates a QUIC connection. | Client: The endpoint that initiates a QUIC connection. | |||
Server: The endpoint that accepts a QUIC connection. | Server: The endpoint that accepts a QUIC connection. | |||
QUIC packet: A complete processable unit of QUIC that can be | QUIC packet: A complete processable unit of QUIC that can be | |||
encapsulated in a UDP datagram. One or more QUIC packets can be | encapsulated in a UDP datagram. One or more QUIC packets can be | |||
encapsulated in a single UDP datagram. | encapsulated in a single UDP datagram. | |||
Ack-eliciting Packet: A QUIC packet that contains frames other than | Ack-eliciting packet: A QUIC packet that contains frames other than | |||
ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to | ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to | |||
send an acknowledgment; see Section 13.2.1. | send an acknowledgment; see Section 13.2.1. | |||
Frame: A unit of structured protocol information. There are | Frame: A unit of structured protocol information. There are | |||
multiple frame types, each of which carries different information. | multiple frame types, each of which carries different information. | |||
Frames are contained in QUIC packets. | Frames are contained in QUIC packets. | |||
Address: When used without qualification, the tuple of IP version, | Address: When used without qualification, the tuple of IP version, | |||
IP address, and UDP port number that represents one end of a | IP address, and UDP port number that represents one end of a | |||
network path. | network path. | |||
Connection ID: An identifier that is used to identify a QUIC | Connection ID: An identifier that is used to identify a QUIC | |||
connection at an endpoint. Each endpoint selects one or more | connection at an endpoint. Each endpoint selects one or more | |||
Connection IDs for its peer to include in packets sent towards the | connection IDs for its peer to include in packets sent towards the | |||
endpoint. This value is opaque to the peer. | endpoint. This value is opaque to the peer. | |||
Stream: A unidirectional or bidirectional channel of ordered bytes | Stream: A unidirectional or bidirectional channel of ordered bytes | |||
within a QUIC connection. A QUIC connection can carry multiple | within a QUIC connection. A QUIC connection can carry multiple | |||
simultaneous streams. | simultaneous streams. | |||
Application: An entity that uses QUIC to send and receive data. | Application: An entity that uses QUIC to send and receive data. | |||
This document uses the terms "QUIC packets", "UDP datagrams", and "IP | This document uses the terms "QUIC packets", "UDP datagrams", and "IP | |||
packets" to refer to the units of the respective protocols. That is, | packets" to refer to the units of the respective protocols. That is, | |||
skipping to change at page 11, line 28 ¶ | skipping to change at page 10, line 16 ¶ | |||
surrounded by a pair of matching braces. Each field in this list is | surrounded by a pair of matching braces. Each field in this list is | |||
separated by commas. | separated by commas. | |||
Individual fields include length information, plus indications about | Individual fields include length information, plus indications about | |||
fixed value, optionality, or repetitions. Individual fields use the | fixed value, optionality, or repetitions. Individual fields use the | |||
following notational conventions, with all lengths in bits: | following notational conventions, with all lengths in bits: | |||
x (A): Indicates that x is A bits long | x (A): Indicates that x is A bits long | |||
x (i): Indicates that x holds an integer value using the variable- | x (i): Indicates that x holds an integer value using the variable- | |||
length encoding in Section 16 | length encoding described in Section 16 | |||
x (A..B): Indicates that x can be any length from A to B; A can be | x (A..B): Indicates that x can be any length from A to B; A can be | |||
omitted to indicate a minimum of zero bits and B can be omitted to | omitted to indicate a minimum of zero bits, and B can be omitted | |||
indicate no set upper limit; values in this format always end on | to indicate no set upper limit; values in this format always end | |||
an byte boundary | on a byte boundary | |||
x (L) = C: Indicates that x has a fixed value of C with the length | x (L) = C: Indicates that x has a fixed value of C; the length of x | |||
described by L, which can use any of the three length forms above | is described by L, which can use any of the length forms above | |||
x (L) = C..D: Indicates that x has a value in the range from C to D, | x (L) = C..D: Indicates that x has a value in the range from C to D, | |||
inclusive, with the length described by L, as above | inclusive, with the length described by L, as above | |||
[x (L)]: Indicates that x is optional (and has length of L) | [x (L)]: Indicates that x is optional and has a length of L | |||
x (L) ...: Indicates that zero or more instances of x are present | x (L) ...: Indicates that x is repeated zero or more times and that | |||
(and that each instance is length L) | each instance has a length of L | |||
This document uses network byte order (that is, big endian) values. | This document uses network byte order (that is, big endian) values. | |||
Fields are placed starting from the high-order bits of each byte. | Fields are placed starting from the high-order bits of each byte. | |||
By convention, individual fields reference a complex field by using | By convention, individual fields reference a complex field by using | |||
the name of the complex field. | the name of the complex field. | |||
For example: | Figure 1 provides an example: | |||
Example Structure { | Example Structure { | |||
One-bit Field (1), | One-bit Field (1), | |||
7-bit Field with Fixed Value (7) = 61, | 7-bit Field with Fixed Value (7) = 61, | |||
Field with Variable-Length Integer (i), | Field with Variable-Length Integer (i), | |||
Arbitrary-Length Field (..), | Arbitrary-Length Field (..), | |||
Variable-Length Field (8..24), | Variable-Length Field (8..24), | |||
Field With Minimum Length (16..), | Field With Minimum Length (16..), | |||
Field With Maximum Length (..128), | Field With Maximum Length (..128), | |||
[Optional Field (64)], | [Optional Field (64)], | |||
skipping to change at page 12, line 32 ¶ | skipping to change at page 11, line 32 ¶ | |||
could be used to refer to the single-bit field in the most | could be used to refer to the single-bit field in the most | |||
significant bit of the byte, such as One-bit Field in Figure 1. | significant bit of the byte, such as One-bit Field in Figure 1. | |||
2. Streams | 2. Streams | |||
Streams in QUIC provide a lightweight, ordered byte-stream | Streams in QUIC provide a lightweight, ordered byte-stream | |||
abstraction to an application. Streams can be unidirectional or | abstraction to an application. Streams can be unidirectional or | |||
bidirectional. | bidirectional. | |||
Streams can be created by sending data. Other processes associated | Streams can be created by sending data. Other processes associated | |||
with stream management - ending, cancelling, and managing flow | with stream management -- ending, canceling, and managing flow | |||
control - are all designed to impose minimal overheads. For | control -- are all designed to impose minimal overheads. For | |||
instance, a single STREAM frame (Section 19.8) can open, carry data | instance, a single STREAM frame (Section 19.8) can open, carry data | |||
for, and close a stream. Streams can also be long-lived and can last | for, and close a stream. Streams can also be long-lived and can last | |||
the entire duration of a connection. | the entire duration of a connection. | |||
Streams can be created by either endpoint, can concurrently send data | Streams can be created by either endpoint, can concurrently send data | |||
interleaved with other streams, and can be cancelled. QUIC does not | interleaved with other streams, and can be canceled. QUIC does not | |||
provide any means of ensuring ordering between bytes on different | provide any means of ensuring ordering between bytes on different | |||
streams. | streams. | |||
QUIC allows for an arbitrary number of streams to operate | QUIC allows for an arbitrary number of streams to operate | |||
concurrently and for an arbitrary amount of data to be sent on any | concurrently and for an arbitrary amount of data to be sent on any | |||
stream, subject to flow control constraints and stream limits; see | stream, subject to flow control constraints and stream limits; see | |||
Section 4. | Section 4. | |||
2.1. Stream Types and Identifiers | 2.1. Stream Types and Identifiers | |||
skipping to change at page 13, line 13 ¶ | skipping to change at page 12, line 13 ¶ | |||
streams carry data in one direction: from the initiator of the stream | streams carry data in one direction: from the initiator of the stream | |||
to its peer. Bidirectional streams allow for data to be sent in both | to its peer. Bidirectional streams allow for data to be sent in both | |||
directions. | directions. | |||
Streams are identified within a connection by a numeric value, | Streams are identified within a connection by a numeric value, | |||
referred to as the stream ID. A stream ID is a 62-bit integer (0 to | referred to as the stream ID. A stream ID is a 62-bit integer (0 to | |||
2^62-1) that is unique for all streams on a connection. Stream IDs | 2^62-1) that is unique for all streams on a connection. Stream IDs | |||
are encoded as variable-length integers; see Section 16. A QUIC | are encoded as variable-length integers; see Section 16. A QUIC | |||
endpoint MUST NOT reuse a stream ID within a connection. | endpoint MUST NOT reuse a stream ID within a connection. | |||
The least significant bit (0x1) of the stream ID identifies the | The least significant bit (0x01) of the stream ID identifies the | |||
initiator of the stream. Client-initiated streams have even-numbered | initiator of the stream. Client-initiated streams have even-numbered | |||
stream IDs (with the bit set to 0), and server-initiated streams have | stream IDs (with the bit set to 0), and server-initiated streams have | |||
odd-numbered stream IDs (with the bit set to 1). | odd-numbered stream IDs (with the bit set to 1). | |||
The second least significant bit (0x2) of the stream ID distinguishes | The second least significant bit (0x02) of the stream ID | |||
between bidirectional streams (with the bit set to 0) and | distinguishes between bidirectional streams (with the bit set to 0) | |||
unidirectional streams (with the bit set to 1). | and unidirectional streams (with the bit set to 1). | |||
The two least significant bits from a stream ID therefore identify a | The two least significant bits from a stream ID therefore identify a | |||
stream as one of four types, as summarized in Table 1. | stream as one of four types, as summarized in Table 1. | |||
+------+----------------------------------+ | +------+----------------------------------+ | |||
| Bits | Stream Type | | | Bits | Stream Type | | |||
+------+----------------------------------+ | +------+----------------------------------+ | |||
| 0x0 | Client-Initiated, Bidirectional | | | 0x00 | Client-Initiated, Bidirectional | | |||
| | | | | | | | |||
| 0x1 | Server-Initiated, Bidirectional | | | 0x01 | Server-Initiated, Bidirectional | | |||
| | | | | | | | |||
| 0x2 | Client-Initiated, Unidirectional | | | 0x02 | Client-Initiated, Unidirectional | | |||
| | | | | | | | |||
| 0x3 | Server-Initiated, Unidirectional | | | 0x03 | Server-Initiated, Unidirectional | | |||
+------+----------------------------------+ | +------+----------------------------------+ | |||
Table 1: Stream ID Types | Table 1: Stream ID Types | |||
The stream space for each type begins at the minimum value (0x0 | The stream space for each type begins at the minimum value (0x00 | |||
through 0x3 respectively); successive streams of each type are | through 0x03, respectively); successive streams of each type are | |||
created with numerically increasing stream IDs. A stream ID that is | created with numerically increasing stream IDs. A stream ID that is | |||
used out of order results in all streams of that type with lower- | used out of order results in all streams of that type with lower- | |||
numbered stream IDs also being opened. | numbered stream IDs also being opened. | |||
2.2. Sending and Receiving Data | 2.2. Sending and Receiving Data | |||
STREAM frames (Section 19.8) encapsulate data sent by an application. | STREAM frames (Section 19.8) encapsulate data sent by an application. | |||
An endpoint uses the Stream ID and Offset fields in STREAM frames to | An endpoint uses the Stream ID and Offset fields in STREAM frames to | |||
place data in order. | place data in order. | |||
Endpoints MUST be able to deliver stream data to an application as an | Endpoints MUST be able to deliver stream data to an application as an | |||
ordered byte-stream. Delivering an ordered byte-stream requires that | ordered byte stream. Delivering an ordered byte stream requires that | |||
an endpoint buffer any data that is received out of order, up to the | an endpoint buffer any data that is received out of order, up to the | |||
advertised flow control limit. | advertised flow control limit. | |||
QUIC makes no specific allowances for delivery of stream data out of | QUIC makes no specific allowances for delivery of stream data out of | |||
order. However, implementations MAY choose to offer the ability to | order. However, implementations MAY choose to offer the ability to | |||
deliver data out of order to a receiving application. | deliver data out of order to a receiving application. | |||
An endpoint could receive data for a stream at the same stream offset | An endpoint could receive data for a stream at the same stream offset | |||
multiple times. Data that has already been received can be | multiple times. Data that has already been received can be | |||
discarded. The data at a given offset MUST NOT change if it is sent | discarded. The data at a given offset MUST NOT change if it is sent | |||
skipping to change at page 14, line 47 ¶ | skipping to change at page 13, line 47 ¶ | |||
information. Instead, it relies on receiving priority information | information. Instead, it relies on receiving priority information | |||
from the application. | from the application. | |||
A QUIC implementation SHOULD provide ways in which an application can | A QUIC implementation SHOULD provide ways in which an application can | |||
indicate the relative priority of streams. An implementation uses | indicate the relative priority of streams. An implementation uses | |||
information provided by the application to determine how to allocate | information provided by the application to determine how to allocate | |||
resources to active streams. | resources to active streams. | |||
2.4. Operations on Streams | 2.4. Operations on Streams | |||
This document does not define an API for QUIC, but instead defines a | This document does not define an API for QUIC; it instead defines a | |||
set of functions on streams that application protocols can rely upon. | set of functions on streams that application protocols can rely upon. | |||
An application protocol can assume that a QUIC implementation | An application protocol can assume that a QUIC implementation | |||
provides an interface that includes the operations described in this | provides an interface that includes the operations described in this | |||
section. An implementation designed for use with a specific | section. An implementation designed for use with a specific | |||
application protocol might provide only those operations that are | application protocol might provide only those operations that are | |||
used by that protocol. | used by that protocol. | |||
On the sending part of a stream, an application protocol can: | On the sending part of a stream, an application protocol can: | |||
o write data, understanding when stream flow control credit | o write data, understanding when stream flow control credit | |||
skipping to change at page 15, line 37 ¶ | skipping to change at page 14, line 37 ¶ | |||
An application protocol can also request to be informed of state | An application protocol can also request to be informed of state | |||
changes on streams, including when the peer has opened or reset a | changes on streams, including when the peer has opened or reset a | |||
stream, when a peer aborts reading on a stream, when new data is | stream, when a peer aborts reading on a stream, when new data is | |||
available, and when data can or cannot be written to the stream due | available, and when data can or cannot be written to the stream due | |||
to flow control. | to flow control. | |||
3. Stream States | 3. Stream States | |||
This section describes streams in terms of their send or receive | This section describes streams in terms of their send or receive | |||
components. Two state machines are described: one for the streams on | components. Two state machines are described: one for the streams on | |||
which an endpoint transmits data (Section 3.1), and another for | which an endpoint transmits data (Section 3.1) and another for | |||
streams on which an endpoint receives data (Section 3.2). | streams on which an endpoint receives data (Section 3.2). | |||
Unidirectional streams use either the sending or receiving state | Unidirectional streams use either the sending or receiving state | |||
machine depending on the stream type and endpoint role. | machine, depending on the stream type and endpoint role. | |||
Bidirectional streams use both state machines at both endpoints. For | Bidirectional streams use both state machines at both endpoints. For | |||
the most part, the use of these state machines is the same whether | the most part, the use of these state machines is the same whether | |||
the stream is unidirectional or bidirectional. The conditions for | the stream is unidirectional or bidirectional. The conditions for | |||
opening a stream are slightly more complex for a bidirectional stream | opening a stream are slightly more complex for a bidirectional stream | |||
because the opening of either the send or receive side causes the | because the opening of either the send or receive side causes the | |||
stream to open in both directions. | stream to open in both directions. | |||
The state machines shown in this section are largely informative. | The state machines shown in this section are largely informative. | |||
This document uses stream states to describe rules for when and how | This document uses stream states to describe rules for when and how | |||
different types of frames can be sent and the reactions that are | different types of frames can be sent and the reactions that are | |||
expected when different types of frames are received. Though these | expected when different types of frames are received. Though these | |||
state machines are intended to be useful in implementing QUIC, these | state machines are intended to be useful in implementing QUIC, these | |||
states are not intended to constrain implementations. An | states are not intended to constrain implementations. An | |||
implementation can define a different state machine as long as its | implementation can define a different state machine as long as its | |||
behavior is consistent with an implementation that implements these | behavior is consistent with an implementation that implements these | |||
states. | states. | |||
Note: In some cases, a single event or action can cause a transition | Note: In some cases, a single event or action can cause a | |||
through multiple states. For instance, sending STREAM with a FIN | transition through multiple states. For instance, sending STREAM | |||
bit set can cause two state transitions for a sending stream: from | with a FIN bit set can cause two state transitions for a sending | |||
the Ready state to the Send state, and from the Send state to the | stream: from the "Ready" state to the "Send" state, and from the | |||
Data Sent state. | "Send" state to the "Data Sent" state. | |||
3.1. Sending Stream States | 3.1. Sending Stream States | |||
Figure 2 shows the states for the part of a stream that sends data to | Figure 2 shows the states for the part of a stream that sends data to | |||
a peer. | a peer. | |||
o | o | |||
| Create Stream (Sending) | | Create Stream (Sending) | |||
| Peer Creates Bidirectional Stream | | Peer Creates Bidirectional Stream | |||
v | v | |||
skipping to change at page 18, line 5 ¶ | skipping to change at page 17, line 5 ¶ | |||
Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a | Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a | |||
sending part of a stream to enter the "Send" state. An | sending part of a stream to enter the "Send" state. An | |||
implementation might choose to defer allocating a stream ID to a | implementation might choose to defer allocating a stream ID to a | |||
stream until it sends the first STREAM frame and enters this state, | stream until it sends the first STREAM frame and enters this state, | |||
which can allow for better stream prioritization. | which can allow for better stream prioritization. | |||
The sending part of a bidirectional stream initiated by a peer (type | The sending part of a bidirectional stream initiated by a peer (type | |||
0 for a server, type 1 for a client) starts in the "Ready" state when | 0 for a server, type 1 for a client) starts in the "Ready" state when | |||
the receiving part is created. | the receiving part is created. | |||
In the "Send" state, an endpoint transmits - and retransmits as | In the "Send" state, an endpoint transmits -- and retransmits as | |||
necessary - stream data in STREAM frames. The endpoint respects the | necessary -- stream data in STREAM frames. The endpoint respects the | |||
flow control limits set by its peer, and continues to accept and | flow control limits set by its peer and continues to accept and | |||
process MAX_STREAM_DATA frames. An endpoint in the "Send" state | process MAX_STREAM_DATA frames. An endpoint in the "Send" state | |||
generates STREAM_DATA_BLOCKED frames if it is blocked from sending by | generates STREAM_DATA_BLOCKED frames if it is blocked from sending by | |||
stream flow control limits (Section 4.1). | stream flow control limits (Section 4.1). | |||
After the application indicates that all stream data has been sent | After the application indicates that all stream data has been sent | |||
and a STREAM frame containing the FIN bit is sent, the sending part | and a STREAM frame containing the FIN bit is sent, the sending part | |||
of the stream enters the "Data Sent" state. From this state, the | of the stream enters the "Data Sent" state. From this state, the | |||
endpoint only retransmits stream data as necessary. The endpoint | endpoint only retransmits stream data as necessary. The endpoint | |||
does not need to check flow control limits or send | does not need to check flow control limits or send | |||
STREAM_DATA_BLOCKED frames for a stream in this state. | STREAM_DATA_BLOCKED frames for a stream in this state. | |||
MAX_STREAM_DATA frames might be received until the peer receives the | MAX_STREAM_DATA frames might be received until the peer receives the | |||
final stream offset. The endpoint can safely ignore any | final stream offset. The endpoint can safely ignore any | |||
MAX_STREAM_DATA frames it receives from its peer for a stream in this | MAX_STREAM_DATA frames it receives from its peer for a stream in this | |||
state. | state. | |||
Once all stream data has been successfully acknowledged, the sending | Once all stream data has been successfully acknowledged, the sending | |||
part of the stream enters the "Data Recvd" state, which is a terminal | part of the stream enters the "Data Recvd" state, which is a terminal | |||
state. | state. | |||
From any of the "Ready", "Send", or "Data Sent" states, an | From any state that is one of "Ready", "Send", or "Data Sent", an | |||
application can signal that it wishes to abandon transmission of | application can signal that it wishes to abandon transmission of | |||
stream data. Alternatively, an endpoint might receive a STOP_SENDING | stream data. Alternatively, an endpoint might receive a STOP_SENDING | |||
frame from its peer. In either case, the endpoint sends a | frame from its peer. In either case, the endpoint sends a | |||
RESET_STREAM frame, which causes the stream to enter the "Reset Sent" | RESET_STREAM frame, which causes the stream to enter the "Reset Sent" | |||
state. | state. | |||
An endpoint MAY send a RESET_STREAM as the first frame that mentions | An endpoint MAY send a RESET_STREAM as the first frame that mentions | |||
a stream; this causes the sending part of that stream to open and | a stream; this causes the sending part of that stream to open and | |||
then immediately transition to the "Reset Sent" state. | then immediately transition to the "Reset Sent" state. | |||
skipping to change at page 20, line 26 ¶ | skipping to change at page 19, line 26 ¶ | |||
In the "Recv" state, the endpoint receives STREAM and | In the "Recv" state, the endpoint receives STREAM and | |||
STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be | STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be | |||
reassembled into the correct order for delivery to the application. | reassembled into the correct order for delivery to the application. | |||
As data is consumed by the application and buffer space becomes | As data is consumed by the application and buffer space becomes | |||
available, the endpoint sends MAX_STREAM_DATA frames to allow the | available, the endpoint sends MAX_STREAM_DATA frames to allow the | |||
peer to send more data. | peer to send more data. | |||
When a STREAM frame with a FIN bit is received, the final size of the | When a STREAM frame with a FIN bit is received, the final size of the | |||
stream is known; see Section 4.5. The receiving part of the stream | stream is known; see Section 4.5. The receiving part of the stream | |||
then enters the "Size Known" state. In this state, the endpoint no | then enters the "Size Known" state. In this state, the endpoint no | |||
longer needs to send MAX_STREAM_DATA frames, it only receives any | longer needs to send MAX_STREAM_DATA frames; it only receives any | |||
retransmissions of stream data. | retransmissions of stream data. | |||
Once all data for the stream has been received, the receiving part | Once all data for the stream has been received, the receiving part | |||
enters the "Data Recvd" state. This might happen as a result of | enters the "Data Recvd" state. This might happen as a result of | |||
receiving the same STREAM frame that causes the transition to "Size | receiving the same STREAM frame that causes the transition to "Size | |||
Known". After all data has been received, any STREAM or | Known". After all data has been received, any STREAM or | |||
STREAM_DATA_BLOCKED frames for the stream can be discarded. | STREAM_DATA_BLOCKED frames for the stream can be discarded. | |||
The "Data Recvd" state persists until stream data has been delivered | The "Data Recvd" state persists until stream data has been delivered | |||
to the application. Once stream data has been delivered, the stream | to the application. Once stream data has been delivered, the stream | |||
enters the "Data Read" state, which is a terminal state. | enters the "Data Read" state, which is a terminal state. | |||
Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states | Receiving a RESET_STREAM frame in the "Recv" or "Size Known" state | |||
causes the stream to enter the "Reset Recvd" state. This might cause | causes the stream to enter the "Reset Recvd" state. This might cause | |||
the delivery of stream data to the application to be interrupted. | the delivery of stream data to the application to be interrupted. | |||
It is possible that all stream data has already been received when a | It is possible that all stream data has already been received when a | |||
RESET_STREAM is received (that is, in the "Data Recvd" state). | RESET_STREAM is received (that is, in the "Data Recvd" state). | |||
Similarly, it is possible for remaining stream data to arrive after | Similarly, it is possible for remaining stream data to arrive after | |||
receiving a RESET_STREAM frame (the "Reset Recvd" state). An | receiving a RESET_STREAM frame (the "Reset Recvd" state). An | |||
implementation is free to manage this situation as it chooses. | implementation is free to manage this situation as it chooses. | |||
Sending RESET_STREAM means that an endpoint cannot guarantee delivery | Sending a RESET_STREAM means that an endpoint cannot guarantee | |||
of stream data; however there is no requirement that stream data not | delivery of stream data; however, there is no requirement that stream | |||
be delivered if a RESET_STREAM is received. An implementation MAY | data not be delivered if a RESET_STREAM is received. An | |||
interrupt delivery of stream data, discard any data that was not | implementation MAY interrupt delivery of stream data, discard any | |||
consumed, and signal the receipt of the RESET_STREAM. A RESET_STREAM | data that was not consumed, and signal the receipt of the | |||
signal might be suppressed or withheld if stream data is completely | RESET_STREAM. A RESET_STREAM signal might be suppressed or withheld | |||
received and is buffered to be read by the application. If the | if stream data is completely received and is buffered to be read by | |||
RESET_STREAM is suppressed, the receiving part of the stream remains | the application. If the RESET_STREAM is suppressed, the receiving | |||
in "Data Recvd". | part of the stream remains in "Data Recvd". | |||
Once the application receives the signal indicating that the stream | Once the application receives the signal indicating that the stream | |||
was reset, the receiving part of the stream transitions to the "Reset | was reset, the receiving part of the stream transitions to the "Reset | |||
Read" state, which is a terminal state. | Read" state, which is a terminal state. | |||
3.3. Permitted Frame Types | 3.3. Permitted Frame Types | |||
The sender of a stream sends just three frame types that affect the | The sender of a stream sends just three frame types that affect the | |||
state of a stream at either sender or receiver: STREAM | state of a stream at either the sender or the receiver: STREAM | |||
(Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM | (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM | |||
(Section 19.4). | (Section 19.4). | |||
A sender MUST NOT send any of these frames from a terminal state | A sender MUST NOT send any of these frames from a terminal state | |||
("Data Recvd" or "Reset Recvd"). A sender MUST NOT send a STREAM or | ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send a STREAM or | |||
STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or | STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or | |||
any terminal state, that is, after sending a RESET_STREAM frame. A | any terminal state -- that is, after sending a RESET_STREAM frame. A | |||
receiver could receive any of these three frames in any state, due to | receiver could receive any of these three frames in any state, due to | |||
the possibility of delayed delivery of packets carrying them. | the possibility of delayed delivery of packets carrying them. | |||
The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and | The receiver of a stream sends MAX_STREAM_DATA frames (Section 19.10) | |||
STOP_SENDING frames (Section 19.5). | and STOP_SENDING frames (Section 19.5). | |||
The receiver only sends MAX_STREAM_DATA in the "Recv" state. A | The receiver only sends MAX_STREAM_DATA frames in the "Recv" state. | |||
receiver MAY send STOP_SENDING in any state where it has not received | A receiver MAY send a STOP_SENDING frame in any state where it has | |||
a RESET_STREAM frame; that is states other than "Reset Recvd" or | not received a RESET_STREAM frame -- that is, states other than | |||
"Reset Read". However there is little value in sending a | "Reset Recvd" or "Reset Read". However, there is little value in | |||
STOP_SENDING frame in the "Data Recvd" state, since all stream data | sending a STOP_SENDING frame in the "Data Recvd" state, as all stream | |||
has been received. A sender could receive either of these two frames | data has been received. A sender could receive either of these two | |||
in any state as a result of delayed delivery of packets. | types of frames in any state as a result of delayed delivery of | |||
packets. | ||||
3.4. Bidirectional Stream States | 3.4. Bidirectional Stream States | |||
A bidirectional stream is composed of sending and receiving parts. | A bidirectional stream is composed of sending and receiving parts. | |||
Implementations can represent states of the bidirectional stream as | Implementations can represent states of the bidirectional stream as | |||
composites of sending and receiving stream states. The simplest | composites of sending and receiving stream states. The simplest | |||
model presents the stream as "open" when either sending or receiving | model presents the stream as "open" when either sending or receiving | |||
parts are in a non-terminal state and "closed" when both sending and | parts are in a non-terminal state and "closed" when both sending and | |||
receiving streams are in terminal states. | receiving streams are in terminal states. | |||
Table 2 shows a more complex mapping of bidirectional stream states | Table 2 shows a more complex mapping of bidirectional stream states | |||
that loosely correspond to the stream states in HTTP/2 [HTTP2]. This | that loosely correspond to the stream states defined in HTTP/2 | |||
shows that multiple states on sending or receiving parts of streams | [HTTP2]. This shows that multiple states on sending or receiving | |||
are mapped to the same composite state. Note that this is just one | parts of streams are mapped to the same composite state. Note that | |||
possibility for such a mapping; this mapping requires that data is | this is just one possibility for such a mapping; this mapping | |||
acknowledged before the transition to a "closed" or "half-closed" | requires that data be acknowledged before the transition to a | |||
state. | "closed" or "half-closed" state. | |||
+-----------------------+---------------------+---------------------+ | +----------------------+-----------------------+--------------------+ | |||
| Sending Part | Receiving Part | Composite State | | | Sending Part | Receiving Part | Composite State | | |||
+-----------------------+---------------------+---------------------+ | +----------------------+-----------------------+--------------------+ | |||
| No Stream/Ready | No Stream/Recv *1 | idle | | | No Stream / Ready | No Stream / Recv (*1) | idle | | |||
| | | | | | | | | | |||
| Ready/Send/Data Sent | Recv/Size Known | open | | | Ready / Send / Data | Recv / Size Known | open | | |||
| | | | | | Sent | | | | |||
| Ready/Send/Data Sent | Data Recvd/Data | half-closed | | | | | | | |||
| | Read | (remote) | | | Ready / Send / Data | Data Recvd / Data | half-closed | | |||
| | | | | | Sent | Read | (remote) | | |||
| Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | | | | | | | |||
| | Read | (remote) | | | Ready / Send / Data | Reset Recvd / Reset | half-closed | | |||
| | | | | | Sent | Read | (remote) | | |||
| Data Recvd | Recv/Size Known | half-closed (local) | | | | | | | |||
| | | | | | Data Recvd | Recv / Size Known | half-closed | | |||
| Reset Sent/Reset | Recv/Size Known | half-closed (local) | | | | | (local) | | |||
| Recvd | | | | | | | | | |||
| | | | | | Reset Sent / Reset | Recv / Size Known | half-closed | | |||
| Reset Sent/Reset | Data Recvd/Data | closed | | | Recvd | | (local) | | |||
| Recvd | Read | | | | | | | | |||
| | | | | | Reset Sent / Reset | Data Recvd / Data | closed | | |||
| Reset Sent/Reset | Reset Recvd/Reset | closed | | | Recvd | Read | | | |||
| Recvd | Read | | | | | | | | |||
| | | | | | Reset Sent / Reset | Reset Recvd / Reset | closed | | |||
| Data Recvd | Data Recvd/Data | closed | | | Recvd | Read | | | |||
| | Read | | | | | | | | |||
| | | | | | Data Recvd | Data Recvd / Data | closed | | |||
| Data Recvd | Reset Recvd/Reset | closed | | | | Read | | | |||
| | Read | | | | | | | | |||
+-----------------------+---------------------+---------------------+ | | Data Recvd | Reset Recvd / Reset | closed | | |||
| | Read | | | ||||
+----------------------+-----------------------+--------------------+ | ||||
Table 2: Possible Mapping of Stream States to HTTP/2 | Table 2: Possible Mapping of Stream States to HTTP/2 | |||
Note (*1): A stream is considered "idle" if it has not yet been | Note (*1): A stream is considered "idle" if it has not yet been | |||
created, or if the receiving part of the stream is in the "Recv" | created or if the receiving part of the stream is in the "Recv" | |||
state without yet having received any frames. | state without yet having received any frames. | |||
3.5. Solicited State Transitions | 3.5. Solicited State Transitions | |||
If an application is no longer interested in the data it is receiving | If an application is no longer interested in the data it is receiving | |||
on a stream, it can abort reading the stream and specify an | on a stream, it can abort reading the stream and specify an | |||
application error code. | application error code. | |||
If the stream is in the "Recv" or "Size Known" states, the transport | If the stream is in the "Recv" or "Size Known" state, the transport | |||
SHOULD signal this by sending a STOP_SENDING frame to prompt closure | SHOULD signal this by sending a STOP_SENDING frame to prompt closure | |||
of the stream in the opposite direction. This typically indicates | of the stream in the opposite direction. This typically indicates | |||
that the receiving application is no longer reading data it receives | that the receiving application is no longer reading data it receives | |||
from the stream, but it is not a guarantee that incoming data will be | from the stream, but it is not a guarantee that incoming data will be | |||
ignored. | ignored. | |||
STREAM frames received after sending a STOP_SENDING frame are still | STREAM frames received after sending a STOP_SENDING frame are still | |||
counted toward connection and stream flow control, even though these | counted toward connection and stream flow control, even though these | |||
frames can be discarded upon receipt. | frames can be discarded upon receipt. | |||
A STOP_SENDING frame requests that the receiving endpoint send a | A STOP_SENDING frame requests that the receiving endpoint send a | |||
RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame | RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame | |||
MUST send a RESET_STREAM frame if the stream is in the Ready or Send | MUST send a RESET_STREAM frame if the stream is in the "Ready" or | |||
state. If the stream is in the "Data Sent" state, the endpoint MAY | "Send" state. If the stream is in the "Data Sent" state, the | |||
defer sending the RESET_STREAM frame until the packets containing | endpoint MAY defer sending the RESET_STREAM frame until the packets | |||
outstanding data are acknowledged or declared lost. If any | containing outstanding data are acknowledged or declared lost. If | |||
outstanding data is declared lost, the endpoint SHOULD send a | any outstanding data is declared lost, the endpoint SHOULD send a | |||
RESET_STREAM frame instead of retransmitting the data. | RESET_STREAM frame instead of retransmitting the data. | |||
An endpoint SHOULD copy the error code from the STOP_SENDING frame to | An endpoint SHOULD copy the error code from the STOP_SENDING frame to | |||
the RESET_STREAM frame it sends, but can use any application error | the RESET_STREAM frame it sends, but it can use any application error | |||
code. An endpoint that sends a STOP_SENDING frame MAY ignore the | code. An endpoint that sends a STOP_SENDING frame MAY ignore the | |||
error code in any RESET_STREAM frames subsequently received for that | error code in any RESET_STREAM frames subsequently received for that | |||
stream. | stream. | |||
STOP_SENDING SHOULD only be sent for a stream that has not been reset | STOP_SENDING SHOULD only be sent for a stream that has not been reset | |||
by the peer. STOP_SENDING is most useful for streams in the "Recv" | by the peer. STOP_SENDING is most useful for streams in the "Recv" | |||
or "Size Known" states. | or "Size Known" state. | |||
An endpoint is expected to send another STOP_SENDING frame if a | An endpoint is expected to send another STOP_SENDING frame if a | |||
packet containing a previous STOP_SENDING is lost. However, once | packet containing a previous STOP_SENDING is lost. However, once | |||
either all stream data or a RESET_STREAM frame has been received for | either all stream data or a RESET_STREAM frame has been received for | |||
the stream - that is, the stream is in any state other than "Recv" or | the stream -- that is, the stream is in any state other than "Recv" | |||
"Size Known" - sending a STOP_SENDING frame is unnecessary. | or "Size Known" -- sending a STOP_SENDING frame is unnecessary. | |||
An endpoint that wishes to terminate both directions of a | An endpoint that wishes to terminate both directions of a | |||
bidirectional stream can terminate one direction by sending a | bidirectional stream can terminate one direction by sending a | |||
RESET_STREAM frame, and it can encourage prompt termination in the | RESET_STREAM frame, and it can encourage prompt termination in the | |||
opposite direction by sending a STOP_SENDING frame. | opposite direction by sending a STOP_SENDING frame. | |||
4. Flow Control | 4. Flow Control | |||
Receivers need to limit the amount of data that they are required to | Receivers need to limit the amount of data that they are required to | |||
buffer, in order to prevent a fast sender from overwhelming them or a | buffer, in order to prevent a fast sender from overwhelming them or a | |||
skipping to change at page 24, line 4 ¶ | skipping to change at page 23, line 12 ¶ | |||
RESET_STREAM frame, and it can encourage prompt termination in the | RESET_STREAM frame, and it can encourage prompt termination in the | |||
opposite direction by sending a STOP_SENDING frame. | opposite direction by sending a STOP_SENDING frame. | |||
4. Flow Control | 4. Flow Control | |||
Receivers need to limit the amount of data that they are required to | Receivers need to limit the amount of data that they are required to | |||
buffer, in order to prevent a fast sender from overwhelming them or a | buffer, in order to prevent a fast sender from overwhelming them or a | |||
malicious sender from consuming a large amount of memory. To enable | malicious sender from consuming a large amount of memory. To enable | |||
a receiver to limit memory commitments for a connection, streams are | a receiver to limit memory commitments for a connection, streams are | |||
flow controlled both individually and across a connection as a whole. | flow controlled both individually and across a connection as a whole. | |||
A QUIC receiver controls the maximum amount of data the sender can | A QUIC receiver controls the maximum amount of data the sender can | |||
send on a stream as well as across all streams at any time, as | send on a stream as well as across all streams at any time, as | |||
described in Section 4.1 and Section 4.2. | described in Sections 4.1 and 4.2. | |||
Similarly, to limit concurrency within a connection, a QUIC endpoint | Similarly, to limit concurrency within a connection, a QUIC endpoint | |||
controls the maximum cumulative number of streams that its peer can | controls the maximum cumulative number of streams that its peer can | |||
initiate, as described in Section 4.6. | initiate, as described in Section 4.6. | |||
Data sent in CRYPTO frames is not flow controlled in the same way as | Data sent in CRYPTO frames is not flow controlled in the same way as | |||
stream data. QUIC relies on the cryptographic protocol | stream data. QUIC relies on the cryptographic protocol | |||
implementation to avoid excessive buffering of data; see [QUIC-TLS]. | implementation to avoid excessive buffering of data; see [QUIC-TLS]. | |||
To avoid excessive buffering at multiple layers, QUIC implementations | To avoid excessive buffering at multiple layers, QUIC implementations | |||
SHOULD provide an interface for the cryptographic protocol | SHOULD provide an interface for the cryptographic protocol | |||
implementation to communicate its buffering limits. | implementation to communicate its buffering limits. | |||
4.1. Data Flow Control | 4.1. Data Flow Control | |||
QUIC employs a limit-based flow-control scheme where a receiver | QUIC employs a limit-based flow control scheme where a receiver | |||
advertises the limit of total bytes it is prepared to receive on a | advertises the limit of total bytes it is prepared to receive on a | |||
given stream or for the entire connection. This leads to two levels | given stream or for the entire connection. This leads to two levels | |||
of data flow control in QUIC: | of data flow control in QUIC: | |||
o Stream flow control, which prevents a single stream from consuming | o Stream flow control, which prevents a single stream from consuming | |||
the entire receive buffer for a connection by limiting the amount | the entire receive buffer for a connection by limiting the amount | |||
of data that can be sent on each stream. | of data that can be sent on each stream. | |||
o Connection flow control, which prevents senders from exceeding a | o Connection flow control, which prevents senders from exceeding a | |||
receiver's buffer capacity for the connection, by limiting the | receiver's buffer capacity for the connection by limiting the | |||
total bytes of stream data sent in STREAM frames on all streams. | total bytes of stream data sent in STREAM frames on all streams. | |||
Senders MUST NOT send data in excess of either limit. | Senders MUST NOT send data in excess of either limit. | |||
A receiver sets initial limits for all streams through transport | A receiver sets initial limits for all streams through transport | |||
parameters during the handshake (Section 7.4). Subsequently, a | parameters during the handshake (Section 7.4). Subsequently, a | |||
receiver sends MAX_STREAM_DATA (Section 19.10) or MAX_DATA | receiver sends MAX_STREAM_DATA frames (Section 19.10) or MAX_DATA | |||
(Section 19.9) frames to the sender to advertise larger limits. | frames (Section 19.9) to the sender to advertise larger limits. | |||
A receiver can advertise a larger limit for a stream by sending a | A receiver can advertise a larger limit for a stream by sending a | |||
MAX_STREAM_DATA frame with the corresponding stream ID. A | MAX_STREAM_DATA frame with the corresponding stream ID. A | |||
MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a | MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a | |||
stream. A receiver could determine the flow control offset to be | stream. A receiver could determine the flow control offset to be | |||
advertised based on the current offset of data consumed on that | advertised based on the current offset of data consumed on that | |||
stream. | stream. | |||
A receiver can advertise a larger limit for a connection by sending a | A receiver can advertise a larger limit for a connection by sending a | |||
MAX_DATA frame, which indicates the maximum of the sum of the | MAX_DATA frame, which indicates the maximum of the sum of the | |||
absolute byte offsets of all streams. A receiver maintains a | absolute byte offsets of all streams. A receiver maintains a | |||
cumulative sum of bytes received on all streams, which is used to | cumulative sum of bytes received on all streams, which is used to | |||
check for violations of the advertised connection or stream data | check for violations of the advertised connection or stream data | |||
limits. A receiver could determine the maximum data limit to be | limits. A receiver could determine the maximum data limit to be | |||
advertised based on the sum of bytes consumed on all streams. | advertised based on the sum of bytes consumed on all streams. | |||
Once a receiver advertises a limit for the connection or a stream, it | Once a receiver advertises a limit for the connection or a stream, it | |||
is not an error to advertise a smaller limit, but the smaller limit | is not an error to advertise a smaller limit, but the smaller limit | |||
has no effect. | has no effect. | |||
A receiver MUST close the connection with a FLOW_CONTROL_ERROR error | A receiver MUST close the connection with an error of type | |||
(Section 11) if the sender violates the advertised connection or | FLOW_CONTROL_ERROR if the sender violates the advertised connection | |||
stream data limits. | or stream data limits; see Section 11 for details on error handling. | |||
A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do | A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do | |||
not increase flow control limits. | not increase flow control limits. | |||
If a sender has sent data up to the limit, it will be unable to send | If a sender has sent data up to the limit, it will be unable to send | |||
new data and is considered blocked. A sender SHOULD send a | new data and is considered blocked. A sender SHOULD send a | |||
STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver | STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver | |||
that it has data to write but is blocked by flow control limits. If | that it has data to write but is blocked by flow control limits. If | |||
a sender is blocked for a period longer than the idle timeout | a sender is blocked for a period longer than the idle timeout | |||
(Section 10.1), the receiver might close the connection even when the | (Section 10.1), the receiver might close the connection even when the | |||
skipping to change at page 26, line 18 ¶ | skipping to change at page 25, line 26 ¶ | |||
A blocked sender is not required to send STREAM_DATA_BLOCKED or | A blocked sender is not required to send STREAM_DATA_BLOCKED or | |||
DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a | DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a | |||
STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a | STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a | |||
MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the | MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the | |||
sender being blocked for the rest of the connection. Even if the | sender being blocked for the rest of the connection. Even if the | |||
sender sends these frames, waiting for them will result in the sender | sender sends these frames, waiting for them will result in the sender | |||
being blocked for at least an entire round trip. | being blocked for at least an entire round trip. | |||
When a sender receives credit after being blocked, it might be able | When a sender receives credit after being blocked, it might be able | |||
to send a large amount of data in response, resulting in short-term | to send a large amount of data in response, resulting in short-term | |||
congestion; see Section 7.7 in [QUIC-RECOVERY] for a discussion of | congestion; see Section 7.7 of [QUIC-RECOVERY] for a discussion of | |||
how a sender can avoid this congestion. | how a sender can avoid this congestion. | |||
4.3. Flow Control Performance | 4.3. Flow Control Performance | |||
If an endpoint cannot ensure that its peer always has available flow | If an endpoint cannot ensure that its peer always has available flow | |||
control credit that is greater than the peer's bandwidth-delay | control credit that is greater than the peer's bandwidth-delay | |||
product on this connection, its receive throughput will be limited by | product on this connection, its receive throughput will be limited by | |||
flow control. | flow control. | |||
Packet loss can cause gaps in the receive buffer, preventing the | Packet loss can cause gaps in the receive buffer, preventing the | |||
skipping to change at page 27, line 24 ¶ | skipping to change at page 26, line 34 ¶ | |||
receiver reliably, no matter how the stream is terminated. The final | receiver reliably, no matter how the stream is terminated. The final | |||
size is the sum of the Offset and Length fields of a STREAM frame | size is the sum of the Offset and Length fields of a STREAM frame | |||
with a FIN flag, noting that these fields might be implicit. | with a FIN flag, noting that these fields might be implicit. | |||
Alternatively, the Final Size field of a RESET_STREAM frame carries | Alternatively, the Final Size field of a RESET_STREAM frame carries | |||
this value. This guarantees that both endpoints agree on how much | this value. This guarantees that both endpoints agree on how much | |||
flow control credit was consumed by the sender on that stream. | flow control credit was consumed by the sender on that stream. | |||
An endpoint will know the final size for a stream when the receiving | An endpoint will know the final size for a stream when the receiving | |||
part of the stream enters the "Size Known" or "Reset Recvd" state | part of the stream enters the "Size Known" or "Reset Recvd" state | |||
(Section 3). The receiver MUST use the final size of the stream to | (Section 3). The receiver MUST use the final size of the stream to | |||
account for all bytes sent on the stream in its connection level flow | account for all bytes sent on the stream in its connection-level flow | |||
controller. | controller. | |||
An endpoint MUST NOT send data on a stream at or beyond the final | An endpoint MUST NOT send data on a stream at or beyond the final | |||
size. | size. | |||
Once a final size for a stream is known, it cannot change. If a | Once a final size for a stream is known, it cannot change. If a | |||
RESET_STREAM or STREAM frame is received indicating a change in the | RESET_STREAM or STREAM frame is received indicating a change in the | |||
final size for the stream, an endpoint SHOULD respond with a | final size for the stream, an endpoint SHOULD respond with an error | |||
FINAL_SIZE_ERROR error; see Section 11. A receiver SHOULD treat | of type FINAL_SIZE_ERROR; see Section 11 for details on error | |||
receipt of data at or beyond the final size as a FINAL_SIZE_ERROR | handling. A receiver SHOULD treat receipt of data at or beyond the | |||
error, even after a stream is closed. Generating these errors is not | final size as an error of type FINAL_SIZE_ERROR, even after a stream | |||
mandatory, because requiring that an endpoint generate these errors | is closed. Generating these errors is not mandatory, because | |||
also means that the endpoint needs to maintain the final size state | requiring that an endpoint generate these errors also means that the | |||
for closed streams, which could mean a significant state commitment. | endpoint needs to maintain the final size state for closed streams, | |||
which could mean a significant state commitment. | ||||
4.6. Controlling Concurrency | 4.6. Controlling Concurrency | |||
An endpoint limits the cumulative number of incoming streams a peer | An endpoint limits the cumulative number of incoming streams a peer | |||
can open. Only streams with a stream ID less than (max_stream * 4 + | can open. Only streams with a stream ID less than "(max_streams * 4 | |||
initial_stream_id_for_type) can be opened; see Table 1. Initial | + first_stream_id_of_type)" can be opened; see Table 1. Initial | |||
limits are set in the transport parameters; see Section 18.2. | limits are set in the transport parameters; see Section 18.2. | |||
Subsequent limits are advertised using MAX_STREAMS frames; see | Subsequent limits are advertised using MAX_STREAMS frames; see | |||
Section 19.11. Separate limits apply to unidirectional and | Section 19.11. Separate limits apply to unidirectional and | |||
bidirectional streams. | bidirectional streams. | |||
If a max_streams transport parameter or a MAX_STREAMS frame is | If a max_streams transport parameter or a MAX_STREAMS frame is | |||
received with a value greater than 2^60, this would allow a maximum | received with a value greater than 2^60, this would allow a maximum | |||
stream ID that cannot be expressed as a variable-length integer; see | stream ID that cannot be expressed as a variable-length integer; see | |||
Section 16. If either is received, the connection MUST be closed | Section 16. If either is received, the connection MUST be closed | |||
immediately with a connection error of type TRANSPORT_PARAMETER_ERROR | immediately with a connection error of type TRANSPORT_PARAMETER_ERROR | |||
if the offending value was received in a transport parameter or of | if the offending value was received in a transport parameter or of | |||
type FRAME_ENCODING_ERROR if it was received in a frame; see | type FRAME_ENCODING_ERROR if it was received in a frame; see | |||
Section 10.2. | Section 10.2. | |||
Endpoints MUST NOT exceed the limit set by their peer. An endpoint | Endpoints MUST NOT exceed the limit set by their peer. An endpoint | |||
that receives a frame with a stream ID exceeding the limit it has | that receives a frame with a stream ID exceeding the limit it has | |||
sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR | sent MUST treat this as a connection error of type | |||
(Section 11). | STREAM_LIMIT_ERROR; see Section 11 for details on error handling. | |||
Once a receiver advertises a stream limit using the MAX_STREAMS | Once a receiver advertises a stream limit using the MAX_STREAMS | |||
frame, advertising a smaller limit has no effect. A receiver MUST | frame, advertising a smaller limit has no effect. MAX_STREAMS frames | |||
ignore any MAX_STREAMS frame that does not increase the stream limit. | that do not increase the stream limit MUST be ignored. | |||
As with stream and connection flow control, this document leaves | As with stream and connection flow control, this document leaves | |||
implementations to decide when and how many streams should be | implementations to decide when and how many streams should be | |||
advertised to a peer via MAX_STREAMS. Implementations might choose | advertised to a peer via MAX_STREAMS. Implementations might choose | |||
to increase limits as streams are closed, to keep the number of | to increase limits as streams are closed, to keep the number of | |||
streams available to peers roughly consistent. | streams available to peers roughly consistent. | |||
An endpoint that is unable to open a new stream due to the peer's | An endpoint that is unable to open a new stream due to the peer's | |||
limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This | limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This | |||
signal is considered useful for debugging. An endpoint MUST NOT wait | signal is considered useful for debugging. An endpoint MUST NOT wait | |||
skipping to change at page 29, line 51 ¶ | skipping to change at page 29, line 16 ¶ | |||
Packets with long headers include Source Connection ID and | Packets with long headers include Source Connection ID and | |||
Destination Connection ID fields. These fields are used to set the | Destination Connection ID fields. These fields are used to set the | |||
connection IDs for new connections; see Section 7.2 for details. | connection IDs for new connections; see Section 7.2 for details. | |||
Packets with short headers (Section 17.3) only include the | Packets with short headers (Section 17.3) only include the | |||
Destination Connection ID and omit the explicit length. The length | Destination Connection ID and omit the explicit length. The length | |||
of the Destination Connection ID field is expected to be known to | of the Destination Connection ID field is expected to be known to | |||
endpoints. Endpoints using a load balancer that routes based on | endpoints. Endpoints using a load balancer that routes based on | |||
connection ID could agree with the load balancer on a fixed length | connection ID could agree with the load balancer on a fixed length | |||
for connection IDs, or agree on an encoding scheme. A fixed portion | for connection IDs or agree on an encoding scheme. A fixed portion | |||
could encode an explicit length, which allows the entire connection | could encode an explicit length, which allows the entire connection | |||
ID to vary in length and still be used by the load balancer. | ID to vary in length and still be used by the load balancer. | |||
A Version Negotiation (Section 17.2.1) packet echoes the connection | A Version Negotiation (Section 17.2.1) packet echoes the connection | |||
IDs selected by the client, both to ensure correct routing toward the | IDs selected by the client, both to ensure correct routing toward the | |||
client and to demonstrate that the packet is in response to a packet | client and to demonstrate that the packet is in response to a packet | |||
sent by the client. | sent by the client. | |||
A zero-length connection ID can be used when a connection ID is not | A zero-length connection ID can be used when a connection ID is not | |||
needed to route to the correct endpoint. However, multiplexing | needed to route to the correct endpoint. However, multiplexing | |||
skipping to change at page 30, line 29 ¶ | skipping to change at page 29, line 42 ¶ | |||
certain that those protocol features are not in use. | certain that those protocol features are not in use. | |||
When an endpoint uses a non-zero-length connection ID, it needs to | When an endpoint uses a non-zero-length connection ID, it needs to | |||
ensure that the peer has a supply of connection IDs from which to | ensure that the peer has a supply of connection IDs from which to | |||
choose for packets sent to the endpoint. These connection IDs are | choose for packets sent to the endpoint. These connection IDs are | |||
supplied by the endpoint using the NEW_CONNECTION_ID frame | supplied by the endpoint using the NEW_CONNECTION_ID frame | |||
(Section 19.15). | (Section 19.15). | |||
5.1.1. Issuing Connection IDs | 5.1.1. Issuing Connection IDs | |||
Each Connection ID has an associated sequence number to assist in | Each connection ID has an associated sequence number to assist in | |||
detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer | detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer | |||
to the same value. The initial connection ID issued by an endpoint | to the same value. The initial connection ID issued by an endpoint | |||
is sent in the Source Connection ID field of the long packet header | is sent in the Source Connection ID field of the long packet header | |||
(Section 17.2) during the handshake. The sequence number of the | (Section 17.2) during the handshake. The sequence number of the | |||
initial connection ID is 0. If the preferred_address transport | initial connection ID is 0. If the preferred_address transport | |||
parameter is sent, the sequence number of the supplied connection ID | parameter is sent, the sequence number of the supplied connection ID | |||
is 1. | is 1. | |||
Additional connection IDs are communicated to the peer using | Additional connection IDs are communicated to the peer using | |||
NEW_CONNECTION_ID frames (Section 19.15). The sequence number on | NEW_CONNECTION_ID frames (Section 19.15). The sequence number on | |||
skipping to change at page 31, line 52 ¶ | skipping to change at page 31, line 17 ¶ | |||
An endpoint that selects a zero-length connection ID during the | An endpoint that selects a zero-length connection ID during the | |||
handshake cannot issue a new connection ID. A zero-length | handshake cannot issue a new connection ID. A zero-length | |||
Destination Connection ID field is used in all packets sent toward | Destination Connection ID field is used in all packets sent toward | |||
such an endpoint over any network path. | such an endpoint over any network path. | |||
5.1.2. Consuming and Retiring Connection IDs | 5.1.2. Consuming and Retiring Connection IDs | |||
An endpoint can change the connection ID it uses for a peer to | An endpoint can change the connection ID it uses for a peer to | |||
another available one at any time during the connection. An endpoint | another available one at any time during the connection. An endpoint | |||
consumes connection IDs in response to a migrating peer; see | consumes connection IDs in response to a migrating peer; see | |||
Section 9.5 for more. | Section 9.5 for more details. | |||
An endpoint maintains a set of connection IDs received from its peer, | An endpoint maintains a set of connection IDs received from its peer, | |||
any of which it can use when sending packets. When the endpoint | any of which it can use when sending packets. When the endpoint | |||
wishes to remove a connection ID from use, it sends a | wishes to remove a connection ID from use, it sends a | |||
RETIRE_CONNECTION_ID frame to its peer. Sending a | RETIRE_CONNECTION_ID frame to its peer. Sending a | |||
RETIRE_CONNECTION_ID frame indicates that the connection ID will not | RETIRE_CONNECTION_ID frame indicates that the connection ID will not | |||
be used again and requests that the peer replace it with a new | be used again and requests that the peer replace it with a new | |||
connection ID using a NEW_CONNECTION_ID frame. | connection ID using a NEW_CONNECTION_ID frame. | |||
As discussed in Section 9.5, endpoints limit the use of a connection | As discussed in Section 9.5, endpoints limit the use of a connection | |||
skipping to change at page 32, line 40 ¶ | skipping to change at page 32, line 6 ¶ | |||
connection ID to the set of active connection IDs. This ordering | connection ID to the set of active connection IDs. This ordering | |||
allows an endpoint to replace all active connection IDs without the | allows an endpoint to replace all active connection IDs without the | |||
possibility of a peer having no available connection IDs and without | possibility of a peer having no available connection IDs and without | |||
exceeding the limit the peer sets in the active_connection_id_limit | exceeding the limit the peer sets in the active_connection_id_limit | |||
transport parameter; see Section 18.2. Failure to cease using the | transport parameter; see Section 18.2. Failure to cease using the | |||
connection IDs when requested can result in connection failures, as | connection IDs when requested can result in connection failures, as | |||
the issuing endpoint might be unable to continue using the connection | the issuing endpoint might be unable to continue using the connection | |||
IDs with the active connection. | IDs with the active connection. | |||
An endpoint SHOULD limit the number of connection IDs it has retired | An endpoint SHOULD limit the number of connection IDs it has retired | |||
locally and have not yet been acknowledged. An endpoint SHOULD allow | locally for which RETIRE_CONNECTION_ID frames have not yet been | |||
for sending and tracking a number of RETIRE_CONNECTION_ID frames of | acknowledged. An endpoint SHOULD allow for sending and tracking a | |||
at least twice the active_connection_id limit. An endpoint MUST NOT | number of RETIRE_CONNECTION_ID frames of at least twice the value of | |||
forget a connection ID without retiring it, though it MAY choose to | the active_connection_id_limit transport parameter. An endpoint MUST | |||
treat having connection IDs in need of retirement that exceed this | NOT forget a connection ID without retiring it, though it MAY choose | |||
to treat having connection IDs in need of retirement that exceed this | ||||
limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. | limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. | |||
Endpoints SHOULD NOT issue updates of the Retire Prior To field | Endpoints SHOULD NOT issue updates of the Retire Prior To field | |||
before receiving RETIRE_CONNECTION_ID frames that retire all | before receiving RETIRE_CONNECTION_ID frames that retire all | |||
connection IDs indicated by the previous Retire Prior To value. | connection IDs indicated by the previous Retire Prior To value. | |||
5.2. Matching Packets to Connections | 5.2. Matching Packets to Connections | |||
Incoming packets are classified on receipt. Packets can either be | Incoming packets are classified on receipt. Packets can either be | |||
associated with an existing connection, or - for servers - | associated with an existing connection or -- for servers -- | |||
potentially create a new connection. | potentially create a new connection. | |||
Endpoints try to associate a packet with an existing connection. If | Endpoints try to associate a packet with an existing connection. If | |||
the packet has a non-zero-length Destination Connection ID | the packet has a non-zero-length Destination Connection ID | |||
corresponding to an existing connection, QUIC processes that packet | corresponding to an existing connection, QUIC processes that packet | |||
accordingly. Note that more than one connection ID can be associated | accordingly. Note that more than one connection ID can be associated | |||
with a connection; see Section 5.1. | with a connection; see Section 5.1. | |||
If the Destination Connection ID is zero length and the addressing | If the Destination Connection ID is zero length and the addressing | |||
information in the packet matches the addressing information the | information in the packet matches the addressing information the | |||
endpoint uses to identify a connection with a zero-length connection | endpoint uses to identify a connection with a zero-length connection | |||
ID, QUIC processes the packet as part of that connection. An | ID, QUIC processes the packet as part of that connection. An | |||
endpoint can use just destination IP and port or both source and | endpoint can use just destination IP and port or both source and | |||
destination addresses for identification, though this makes | destination addresses for identification, though this makes | |||
connections fragile as described in Section 5.1. | connections fragile as described in Section 5.1. | |||
Endpoints can send a Stateless Reset (Section 10.3) for any packets | Endpoints can send a Stateless Reset (Section 10.3) for any packets | |||
that cannot be attributed to an existing connection. A stateless | that cannot be attributed to an existing connection. A Stateless | |||
reset allows a peer to more quickly identify when a connection | Reset allows a peer to more quickly identify when a connection | |||
becomes unusable. | becomes unusable. | |||
Packets that are matched to an existing connection are discarded if | Packets that are matched to an existing connection are discarded if | |||
the packets are inconsistent with the state of that connection. For | the packets are inconsistent with the state of that connection. For | |||
example, packets are discarded if they indicate a different protocol | example, packets are discarded if they indicate a different protocol | |||
version than that of the connection, or if the removal of packet | version than that of the connection or if the removal of packet | |||
protection is unsuccessful once the expected keys are available. | protection is unsuccessful once the expected keys are available. | |||
Invalid packets that lack strong integrity protection, such as | Invalid packets that lack strong integrity protection, such as | |||
Initial, Retry, or Version Negotiation, MAY be discarded. An | Initial, Retry, or Version Negotiation, MAY be discarded. An | |||
endpoint MUST generate a connection error if processing the contents | endpoint MUST generate a connection error if processing the contents | |||
of these packets prior to discovering an error, or fully revert any | of these packets prior to discovering an error, or fully revert any | |||
changes made during that processing. | changes made during that processing. | |||
5.2.1. Client Packet Handling | 5.2.1. Client Packet Handling | |||
Valid packets sent to clients always include a Destination Connection | Valid packets sent to clients always include a Destination Connection | |||
ID that matches a value the client selects. Clients that choose to | ID that matches a value the client selects. Clients that choose to | |||
receive zero-length connection IDs can use the local address and port | receive zero-length connection IDs can use the local address and port | |||
to identify a connection. Packets that do not match an existing | to identify a connection. Packets that do not match an existing | |||
connection, based on Destination Connection ID or, if this value is | connection -- based on Destination Connection ID or, if this value is | |||
zero-length, local IP address and port, are discarded. | zero length, local IP address and port -- are discarded. | |||
Due to packet reordering or loss, a client might receive packets for | Due to packet reordering or loss, a client might receive packets for | |||
a connection that are encrypted with a key it has not yet computed. | a connection that are encrypted with a key it has not yet computed. | |||
The client MAY drop these packets, or it MAY buffer them in | ||||
The client MAY drop these packets, or MAY buffer them in anticipation | anticipation of later packets that allow it to compute the key. | |||
of later packets that allow it to compute the key. | ||||
If a client receives a packet that uses a different version than it | If a client receives a packet that uses a different version than it | |||
initially selected, it MUST discard that packet. | initially selected, it MUST discard that packet. | |||
5.2.2. Server Packet Handling | 5.2.2. Server Packet Handling | |||
If a server receives a packet that indicates an unsupported version | If a server receives a packet that indicates an unsupported version | |||
and if the packet is large enough to initiate a new connection for | and if the packet is large enough to initiate a new connection for | |||
any supported version, the server SHOULD send a Version Negotiation | any supported version, the server SHOULD send a Version Negotiation | |||
packet as described in Section 6.1. A server MAY limit the number of | packet as described in Section 6.1. A server MAY limit the number of | |||
skipping to change at page 34, line 28 ¶ | skipping to change at page 33, line 41 ¶ | |||
Servers MUST drop smaller packets that specify unsupported versions. | Servers MUST drop smaller packets that specify unsupported versions. | |||
The first packet for an unsupported version can use different | The first packet for an unsupported version can use different | |||
semantics and encodings for any version-specific field. In | semantics and encodings for any version-specific field. In | |||
particular, different packet protection keys might be used for | particular, different packet protection keys might be used for | |||
different versions. Servers that do not support a particular version | different versions. Servers that do not support a particular version | |||
are unlikely to be able to decrypt the payload of the packet or | are unlikely to be able to decrypt the payload of the packet or | |||
properly interpret the result. Servers SHOULD respond with a Version | properly interpret the result. Servers SHOULD respond with a Version | |||
Negotiation packet, provided that the datagram is sufficiently long. | Negotiation packet, provided that the datagram is sufficiently long. | |||
Packets with a supported version, or no version field, are matched to | Packets with a supported version, or no Version field, are matched to | |||
a connection using the connection ID or - for packets with zero- | a connection using the connection ID or -- for packets with zero- | |||
length connection IDs - the local address and port. These packets | length connection IDs -- the local address and port. These packets | |||
are processed using the selected connection; otherwise, the server | are processed using the selected connection; otherwise, the server | |||
continues below. | continues as described below. | |||
If the packet is an Initial packet fully conforming with the | If the packet is an Initial packet fully conforming with the | |||
specification, the server proceeds with the handshake (Section 7). | specification, the server proceeds with the handshake (Section 7). | |||
This commits the server to the version that the client selected. | This commits the server to the version that the client selected. | |||
If a server refuses to accept a new connection, it SHOULD send an | If a server refuses to accept a new connection, it SHOULD send an | |||
Initial packet containing a CONNECTION_CLOSE frame with error code | Initial packet containing a CONNECTION_CLOSE frame with error code | |||
CONNECTION_REFUSED. | CONNECTION_REFUSED. | |||
If the packet is a 0-RTT packet, the server MAY buffer a limited | If the packet is a 0-RTT packet, the server MAY buffer a limited | |||
number of these packets in anticipation of a late-arriving Initial | number of these packets in anticipation of a late-arriving Initial | |||
packet. Clients are not able to send Handshake packets prior to | packet. Clients are not able to send Handshake packets prior to | |||
receiving a server response, so servers SHOULD ignore any such | receiving a server response, so servers SHOULD ignore any such | |||
packets. | packets. | |||
Servers MUST drop incoming packets under all other circumstances. | Servers MUST drop incoming packets under all other circumstances. | |||
5.2.3. Considerations for Simple Load Balancers | 5.2.3. Considerations for Simple Load Balancers | |||
A server deployment could load balance among servers using only | A server deployment could load-balance among servers using only | |||
source and destination IP addresses and ports. Changes to the | source and destination IP addresses and ports. Changes to the | |||
client's IP address or port could result in packets being forwarded | client's IP address or port could result in packets being forwarded | |||
to the wrong server. Such a server deployment could use one of the | to the wrong server. Such a server deployment could use one of the | |||
following methods for connection continuity when a client's address | following methods for connection continuity when a client's address | |||
changes. | changes. | |||
o Servers could use an out-of-band mechanism to forward packets to | o Servers could use an out-of-band mechanism to forward packets to | |||
the correct server based on Connection ID. | the correct server based on connection ID. | |||
o If servers can use a dedicated server IP address or port, other | o If servers can use a dedicated server IP address or port, other | |||
than the one that the client initially connects to, they could use | than the one that the client initially connects to, they could use | |||
the preferred_address transport parameter to request that clients | the preferred_address transport parameter to request that clients | |||
move connections to that dedicated address. Note that clients | move connections to that dedicated address. Note that clients | |||
could choose not to use the preferred address. | could choose not to use the preferred address. | |||
A server in a deployment that does not implement a solution to | A server in a deployment that does not implement a solution to | |||
maintain connection continuity when the client address changes SHOULD | maintain connection continuity when the client address changes SHOULD | |||
indicate migration is not supported using the | indicate that migration is not supported by using the | |||
disable_active_migration transport parameter. The | disable_active_migration transport parameter. The | |||
disable_active_migration transport parameter does not prohibit | disable_active_migration transport parameter does not prohibit | |||
connection migration after a client has acted on a preferred_address | connection migration after a client has acted on a preferred_address | |||
transport parameter. | transport parameter. | |||
Server deployments that use this simple form of load balancing MUST | Server deployments that use this simple form of load balancing MUST | |||
avoid the creation of a stateless reset oracle; see Section 21.11. | avoid the creation of a stateless reset oracle; see Section 21.11. | |||
5.3. Operations on Connections | 5.3. Operations on Connections | |||
This document does not define an API for QUIC, but instead defines a | This document does not define an API for QUIC; it instead defines a | |||
set of functions for QUIC connections that application protocols can | set of functions for QUIC connections that application protocols can | |||
rely upon. An application protocol can assume that an implementation | rely upon. An application protocol can assume that an implementation | |||
of QUIC provides an interface that includes the operations described | of QUIC provides an interface that includes the operations described | |||
in this section. An implementation designed for use with a specific | in this section. An implementation designed for use with a specific | |||
application protocol might provide only those operations that are | application protocol might provide only those operations that are | |||
used by that protocol. | used by that protocol. | |||
When implementing the client role, an application protocol can: | When implementing the client role, an application protocol can: | |||
o open a connection, which begins the exchange described in | o open a connection, which begins the exchange described in | |||
skipping to change at page 36, line 24 ¶ | skipping to change at page 35, line 36 ¶ | |||
from the client's resumption ticket and accept or reject Early | from the client's resumption ticket and accept or reject Early | |||
Data based on that information. | Data based on that information. | |||
In either role, an application protocol can: | In either role, an application protocol can: | |||
o configure minimum values for the initial number of permitted | o configure minimum values for the initial number of permitted | |||
streams of each type, as communicated in the transport parameters | streams of each type, as communicated in the transport parameters | |||
(Section 7.4); | (Section 7.4); | |||
o control resource allocation for receive buffers by setting flow | o control resource allocation for receive buffers by setting flow | |||
control limits both for streams and for the connection | control limits both for streams and for the connection; | |||
o identify whether the handshake has completed successfully or is | o identify whether the handshake has completed successfully or is | |||
still ongoing; | still ongoing; | |||
o keep a connection from silently closing, either by generating PING | o keep a connection from silently closing, by either generating PING | |||
frames (Section 19.2) or by requesting that the transport send | frames (Section 19.2) or requesting that the transport send | |||
additional frames before the idle timeout expires (Section 10.1); | additional frames before the idle timeout expires (Section 10.1); | |||
and | and | |||
o immediately close (Section 10.2) the connection. | o immediately close (Section 10.2) the connection. | |||
6. Version Negotiation | 6. Version Negotiation | |||
Version negotiation allows a server to indicate that it does not | Version negotiation allows a server to indicate that it does not | |||
support the version the client used. A server sends a Version | support the version the client used. A server sends a Version | |||
Negotiation packet in response to each packet that might initiate a | Negotiation packet in response to each packet that might initiate a | |||
skipping to change at page 37, line 29 ¶ | skipping to change at page 36, line 46 ¶ | |||
A server MAY limit the number of Version Negotiation packets it | A server MAY limit the number of Version Negotiation packets it | |||
sends. For instance, a server that is able to recognize packets as | sends. For instance, a server that is able to recognize packets as | |||
0-RTT might choose not to send Version Negotiation packets in | 0-RTT might choose not to send Version Negotiation packets in | |||
response to 0-RTT packets with the expectation that it will | response to 0-RTT packets with the expectation that it will | |||
eventually receive an Initial packet. | eventually receive an Initial packet. | |||
6.2. Handling Version Negotiation Packets | 6.2. Handling Version Negotiation Packets | |||
Version Negotiation packets are designed to allow for functionality | Version Negotiation packets are designed to allow for functionality | |||
to be defined in the future that allows QUIC to negotiate the version | to be defined in the future that allows QUIC to negotiate the version | |||
of QUIC to use for a connection. Future standards-track | of QUIC to use for a connection. Future Standards Track | |||
specifications might change how implementations that support multiple | specifications might change how implementations that support multiple | |||
versions of QUIC react to Version Negotiation packets received in | versions of QUIC react to Version Negotiation packets received in | |||
response to an attempt to establish a connection using this version. | response to an attempt to establish a connection using this version. | |||
A client that supports only this version of QUIC MUST abandon the | A client that supports only this version of QUIC MUST abandon the | |||
current connection attempt if it receives a Version Negotiation | current connection attempt if it receives a Version Negotiation | |||
packet, with the following two exceptions. A client MUST discard any | packet, with the following two exceptions. A client MUST discard any | |||
Version Negotiation packet if it has received and successfully | Version Negotiation packet if it has received and successfully | |||
processed any other packet, including an earlier Version Negotiation | processed any other packet, including an earlier Version Negotiation | |||
packet. A client MUST discard a Version Negotiation packet that | packet. A client MUST discard a Version Negotiation packet that | |||
lists the QUIC version selected by the client. | lists the QUIC version selected by the client. | |||
How to perform version negotiation is left as future work defined by | How to perform version negotiation is left as future work defined by | |||
future standards-track specifications. In particular, that future | future Standards Track specifications. In particular, that future | |||
work will ensure robustness against version downgrade attacks; see | work will ensure robustness against version downgrade attacks; see | |||
Section 21.12. | Section 21.12. | |||
6.2.1. Version Negotiation Between Draft Versions | ||||
[[RFC editor: please remove this section before publication.]] | ||||
When a draft implementation receives a Version Negotiation packet, it | ||||
MAY use it to attempt a new connection with one of the versions | ||||
listed in the packet, instead of abandoning the current connection | ||||
attempt; see Section 6.2. | ||||
The client MUST check that the Destination and Source Connection ID | ||||
fields match the Source and Destination Connection ID fields in a | ||||
packet that the client sent. If this check fails, the packet MUST be | ||||
discarded. | ||||
Once the Version Negotiation packet is determined to be valid, the | ||||
client then selects an acceptable protocol version from the list | ||||
provided by the server. The client then attempts to create a new | ||||
connection using that version. The new connection MUST use a new | ||||
random Destination Connection ID different from the one it had | ||||
previously sent. | ||||
Note that this mechanism does not protect against downgrade attacks | ||||
and MUST NOT be used outside of draft implementations. | ||||
6.3. Using Reserved Versions | 6.3. Using Reserved Versions | |||
For a server to use a new version in the future, clients need to | For a server to use a new version in the future, clients need to | |||
correctly handle unsupported versions. Some version numbers | correctly handle unsupported versions. Some version numbers | |||
(0x?a?a?a?a as defined in Section 15) are reserved for inclusion in | (0x?a?a?a?a, as defined in Section 15) are reserved for inclusion in | |||
fields that contain version numbers. | fields that contain version numbers. | |||
Endpoints MAY add reserved versions to any field where unknown or | Endpoints MAY add reserved versions to any field where unknown or | |||
unsupported versions are ignored to test that a peer correctly | unsupported versions are ignored to test that a peer correctly | |||
ignores the value. For instance, an endpoint could include a | ignores the value. For instance, an endpoint could include a | |||
reserved version in a Version Negotiation packet; see Section 17.2.1. | reserved version in a Version Negotiation packet; see Section 17.2.1. | |||
Endpoints MAY send packets with a reserved version to test that a | Endpoints MAY send packets with a reserved version to test that a | |||
peer correctly discards the packet. | peer correctly discards the packet. | |||
7. Cryptographic and Transport Handshake | 7. Cryptographic and Transport Handshake | |||
skipping to change at page 39, line 4 ¶ | skipping to change at page 37, line 45 ¶ | |||
and uses TLS as described in [QUIC-TLS]; a different QUIC version | and uses TLS as described in [QUIC-TLS]; a different QUIC version | |||
could indicate that a different cryptographic handshake protocol is | could indicate that a different cryptographic handshake protocol is | |||
in use. | in use. | |||
QUIC provides reliable, ordered delivery of the cryptographic | QUIC provides reliable, ordered delivery of the cryptographic | |||
handshake data. QUIC packet protection is used to encrypt as much of | handshake data. QUIC packet protection is used to encrypt as much of | |||
the handshake protocol as possible. The cryptographic handshake MUST | the handshake protocol as possible. The cryptographic handshake MUST | |||
provide the following properties: | provide the following properties: | |||
o authenticated key exchange, where | o authenticated key exchange, where | |||
* a server is always authenticated, | * a server is always authenticated, | |||
* a client is optionally authenticated, | * a client is optionally authenticated, | |||
* every connection produces distinct and unrelated keys, and | * every connection produces distinct and unrelated keys, and | |||
* keying material is usable for packet protection for both 0-RTT | * keying material is usable for packet protection for both 0-RTT | |||
and 1-RTT packets | and 1-RTT packets. | |||
o authenticated exchange of values for transport parameters of both | o authenticated exchange of values for transport parameters of both | |||
endpoints, and confidentiality protection for server transport | endpoints, and confidentiality protection for server transport | |||
parameters (see Section 7.4) | parameters (see Section 7.4). | |||
o authenticated negotiation of an application protocol (TLS uses | o authenticated negotiation of an application protocol (TLS uses | |||
ALPN [ALPN] for this purpose) | Application-Layer Protocol Negotiation (ALPN) [ALPN] for this | |||
purpose). | ||||
The CRYPTO frame can be sent in different packet number spaces | The CRYPTO frame can be sent in different packet number spaces | |||
(Section 12.3). The offsets used by CRYPTO frames to ensure ordered | (Section 12.3). The offsets used by CRYPTO frames to ensure ordered | |||
delivery of cryptographic handshake data start from zero in each | delivery of cryptographic handshake data start from zero in each | |||
packet number space. | packet number space. | |||
Figure 4 shows a simplified handshake and the exchange of packets and | Figure 4 shows a simplified handshake and the exchange of packets and | |||
frames that are used to advance the handshake. Exchange of | frames that are used to advance the handshake. Exchange of | |||
application data during the handshake is enabled where possible, | application data during the handshake is enabled where possible, | |||
shown with a '*'. Once the handshake is complete, endpoints are able | shown with an asterisk ("*"). Once the handshake is complete, | |||
to exchange application data freely. | endpoints are able to exchange application data freely. | |||
Client Server | Client Server | |||
Initial (CRYPTO) | Initial (CRYPTO) | |||
0-RTT (*) ----------> | 0-RTT (*) ----------> | |||
Initial (CRYPTO) | Initial (CRYPTO) | |||
Handshake (CRYPTO) | Handshake (CRYPTO) | |||
<---------- 1-RTT (*) | <---------- 1-RTT (*) | |||
Handshake (CRYPTO) | Handshake (CRYPTO) | |||
1-RTT (*) ----------> | 1-RTT (*) ----------> | |||
skipping to change at page 40, line 24 ¶ | skipping to change at page 39, line 20 ¶ | |||
Section 8.1.2. | Section 8.1.2. | |||
Once any address validation exchanges are complete, the cryptographic | Once any address validation exchanges are complete, the cryptographic | |||
handshake is used to agree on cryptographic keys. The cryptographic | handshake is used to agree on cryptographic keys. The cryptographic | |||
handshake is carried in Initial (Section 17.2.2) and Handshake | handshake is carried in Initial (Section 17.2.2) and Handshake | |||
(Section 17.2.4) packets. | (Section 17.2.4) packets. | |||
Figure 5 provides an overview of the 1-RTT handshake. Each line | Figure 5 provides an overview of the 1-RTT handshake. Each line | |||
shows a QUIC packet with the packet type and packet number shown | shows a QUIC packet with the packet type and packet number shown | |||
first, followed by the frames that are typically contained in those | first, followed by the frames that are typically contained in those | |||
packets. So, for instance the first packet is of type Initial, with | packets. For instance, the first packet is of type Initial, with | |||
packet number 0, and contains a CRYPTO frame carrying the | packet number 0, and contains a CRYPTO frame carrying the | |||
ClientHello. | ClientHello. | |||
Multiple QUIC packets - even of different packet types - can be | Multiple QUIC packets -- even of different packet types -- can be | |||
coalesced into a single UDP datagram; see Section 12.2. As a result, | coalesced into a single UDP datagram; see Section 12.2. As a result, | |||
this handshake could consist of as few as 4 UDP datagrams, or any | this handshake could consist of as few as four UDP datagrams, or any | |||
number more (subject to limits inherent to the protocol, such as | number more (subject to limits inherent to the protocol, such as | |||
congestion control and anti-amplification). For instance, the | congestion control and anti-amplification). For instance, the | |||
server's first flight contains Initial packets, Handshake packets, | server's first flight contains Initial packets, Handshake packets, | |||
and "0.5-RTT data" in 1-RTT packets. | and "0.5-RTT data" in 1-RTT packets. | |||
Client Server | Client Server | |||
Initial[0]: CRYPTO[CH] -> | Initial[0]: CRYPTO[CH] -> | |||
Initial[0]: CRYPTO[SH] ACK[0] | Initial[0]: CRYPTO[SH] ACK[0] | |||
skipping to change at page 42, line 14 ¶ | skipping to change at page 41, line 9 ¶ | |||
The Destination Connection ID field from the first Initial packet | The Destination Connection ID field from the first Initial packet | |||
sent by a client is used to determine packet protection keys for | sent by a client is used to determine packet protection keys for | |||
Initial packets. These keys change after receiving a Retry packet; | Initial packets. These keys change after receiving a Retry packet; | |||
see Section 5.2 of [QUIC-TLS]. | see Section 5.2 of [QUIC-TLS]. | |||
The client populates the Source Connection ID field with a value of | The client populates the Source Connection ID field with a value of | |||
its choosing and sets the Source Connection ID Length field to | its choosing and sets the Source Connection ID Length field to | |||
indicate the length. | indicate the length. | |||
The first flight of 0-RTT packets use the same Destination Connection | 0-RTT packets in the first flight use the same Destination Connection | |||
ID and Source Connection ID values as the client's first Initial | ID and Source Connection ID values as the client's first Initial | |||
packet. | packet. | |||
Upon first receiving an Initial or Retry packet from the server, the | Upon first receiving an Initial or Retry packet from the server, the | |||
client uses the Source Connection ID supplied by the server as the | client uses the Source Connection ID supplied by the server as the | |||
Destination Connection ID for subsequent packets, including any 0-RTT | Destination Connection ID for subsequent packets, including any 0-RTT | |||
packets. This means that a client might have to change the | packets. This means that a client might have to change the | |||
connection ID it sets in the Destination Connection ID field twice | connection ID it sets in the Destination Connection ID field twice | |||
during connection establishment: once in response to a Retry, and | during connection establishment: once in response to a Retry packet | |||
once in response to an Initial packet from the server. Once a client | and once in response to an Initial packet from the server. Once a | |||
has received a valid Initial packet from the server, it MUST discard | client has received a valid Initial packet from the server, it MUST | |||
any subsequent packet it receives on that connection with a different | discard any subsequent packet it receives on that connection with a | |||
Source Connection ID. | different Source Connection ID. | |||
A client MUST change the Destination Connection ID it uses for | A client MUST change the Destination Connection ID it uses for | |||
sending packets in response to only the first received Initial or | sending packets in response to only the first received Initial or | |||
Retry packet. A server MUST set the Destination Connection ID it | Retry packet. A server MUST set the Destination Connection ID it | |||
uses for sending packets based on the first received Initial packet. | uses for sending packets based on the first received Initial packet. | |||
Any further changes to the Destination Connection ID are only | Any further changes to the Destination Connection ID are only | |||
permitted if the values are taken from NEW_CONNECTION_ID frames; if | permitted if the values are taken from NEW_CONNECTION_ID frames; if | |||
subsequent Initial packets include a different Source Connection ID, | subsequent Initial packets include a different Source Connection ID, | |||
they MUST be discarded. This avoids unpredictable outcomes that | they MUST be discarded. This avoids unpredictable outcomes that | |||
might otherwise result from stateless processing of multiple Initial | might otherwise result from stateless processing of multiple Initial | |||
skipping to change at page 43, line 20 ¶ | skipping to change at page 42, line 13 ¶ | |||
original_destination_connection_id transport parameter; if the server | original_destination_connection_id transport parameter; if the server | |||
sent a Retry packet, this refers to the first Initial packet received | sent a Retry packet, this refers to the first Initial packet received | |||
before sending the Retry packet. If it sends a Retry packet, a | before sending the Retry packet. If it sends a Retry packet, a | |||
server also includes the Source Connection ID field from the Retry | server also includes the Source Connection ID field from the Retry | |||
packet in the retry_source_connection_id transport parameter. | packet in the retry_source_connection_id transport parameter. | |||
The values provided by a peer for these transport parameters MUST | The values provided by a peer for these transport parameters MUST | |||
match the values that an endpoint used in the Destination and Source | match the values that an endpoint used in the Destination and Source | |||
Connection ID fields of Initial packets that it sent (and received, | Connection ID fields of Initial packets that it sent (and received, | |||
for servers). Endpoints MUST validate that received transport | for servers). Endpoints MUST validate that received transport | |||
parameters match received Connection ID values. Including connection | parameters match received connection ID values. Including connection | |||
ID values in transport parameters and verifying them ensures that | ID values in transport parameters and verifying them ensures that an | |||
that an attacker cannot influence the choice of connection ID for a | attacker cannot influence the choice of connection ID for a | |||
successful connection by injecting packets carrying attacker-chosen | successful connection by injecting packets carrying attacker-chosen | |||
connection IDs during the handshake. | connection IDs during the handshake. | |||
An endpoint MUST treat absence of the initial_source_connection_id | An endpoint MUST treat the absence of the | |||
transport parameter from either endpoint or absence of the | initial_source_connection_id transport parameter from either endpoint | |||
original_destination_connection_id transport parameter from the | or the absence of the original_destination_connection_id transport | |||
server as a connection error of type TRANSPORT_PARAMETER_ERROR. | parameter from the server as a connection error of type | |||
TRANSPORT_PARAMETER_ERROR. | ||||
An endpoint MUST treat the following as a connection error of type | An endpoint MUST treat the following as a connection error of type | |||
TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: | TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: | |||
o absence of the retry_source_connection_id transport parameter from | o absence of the retry_source_connection_id transport parameter from | |||
the server after receiving a Retry packet, | the server after receiving a Retry packet, | |||
o presence of the retry_source_connection_id transport parameter | o presence of the retry_source_connection_id transport parameter | |||
when no Retry packet was received, or | when no Retry packet was received, or | |||
skipping to change at page 44, line 29 ¶ | skipping to change at page 43, line 29 ¶ | |||
Initial: DCID=S1, SCID=C1 -> | Initial: DCID=S1, SCID=C1 -> | |||
<- Retry: DCID=C1, SCID=S2 | <- Retry: DCID=C1, SCID=S2 | |||
Initial: DCID=S2, SCID=C1 -> | Initial: DCID=S2, SCID=C1 -> | |||
<- Initial: DCID=C1, SCID=S3 | <- Initial: DCID=C1, SCID=S3 | |||
... | ... | |||
1-RTT: DCID=S3 -> | 1-RTT: DCID=S3 -> | |||
<- 1-RTT: DCID=C1 | <- 1-RTT: DCID=C1 | |||
Figure 8: Use of Connection IDs in a Handshake with Retry | Figure 8: Use of Connection IDs in a Handshake with Retry | |||
In both cases (Figure 7 and Figure 8), the client sets the value of | In both cases (Figures 7 and 8), the client sets the value of the | |||
the initial_source_connection_id transport parameter to "C1". | initial_source_connection_id transport parameter to "C1". | |||
When the handshake does not include a Retry (Figure 7), the server | When the handshake does not include a Retry (Figure 7), the server | |||
sets original_destination_connection_id to "S1" and | sets original_destination_connection_id to "S1" (note that this value | |||
initial_source_connection_id to "S3". In this case, the server does | is chosen by the client) and initial_source_connection_id to "S3". | |||
not include a retry_source_connection_id transport parameter. | In this case, the server does not include a | |||
retry_source_connection_id transport parameter. | ||||
When the handshake includes a Retry (Figure 8), the server sets | When the handshake includes a Retry (Figure 8), the server sets | |||
original_destination_connection_id to "S1", | original_destination_connection_id to "S1", | |||
retry_source_connection_id to "S2", and initial_source_connection_id | retry_source_connection_id to "S2", and initial_source_connection_id | |||
to "S3". | to "S3". | |||
7.4. Transport Parameters | 7.4. Transport Parameters | |||
During connection establishment, both endpoints make authenticated | During connection establishment, both endpoints make authenticated | |||
declarations of their transport parameters. Endpoints are required | declarations of their transport parameters. Endpoints are required | |||
skipping to change at page 45, line 27 ¶ | skipping to change at page 44, line 27 ¶ | |||
TRANSPORT_PARAMETER_ERROR. | TRANSPORT_PARAMETER_ERROR. | |||
An endpoint MUST NOT send a parameter more than once in a given | An endpoint MUST NOT send a parameter more than once in a given | |||
transport parameters extension. An endpoint SHOULD treat receipt of | transport parameters extension. An endpoint SHOULD treat receipt of | |||
duplicate transport parameters as a connection error of type | duplicate transport parameters as a connection error of type | |||
TRANSPORT_PARAMETER_ERROR. | TRANSPORT_PARAMETER_ERROR. | |||
Endpoints use transport parameters to authenticate the negotiation of | Endpoints use transport parameters to authenticate the negotiation of | |||
connection IDs during the handshake; see Section 7.3. | connection IDs during the handshake; see Section 7.3. | |||
Application Layer Protocol Negotiation (ALPN; see [ALPN]) allows | ALPN (see [ALPN]) allows clients to offer multiple application | |||
clients to offer multiple application protocols during connection | protocols during connection establishment. The transport parameters | |||
establishment. The transport parameters that a client includes | that a client includes during the handshake apply to all application | |||
during the handshake apply to all application protocols that the | protocols that the client offers. Application protocols can | |||
client offers. Application protocols can recommend values for | recommend values for transport parameters, such as the initial flow | |||
transport parameters, such as the initial flow control limits. | control limits. However, application protocols that set constraints | |||
However, application protocols that set constraints on values for | on values for transport parameters could make it impossible for a | |||
transport parameters could make it impossible for a client to offer | client to offer multiple application protocols if these constraints | |||
multiple application protocols if these constraints conflict. | conflict. | |||
7.4.1. Values of Transport Parameters for 0-RTT | 7.4.1. Values of Transport Parameters for 0-RTT | |||
Using 0-RTT depends on both client and server using protocol | Using 0-RTT depends on both client and server using protocol | |||
parameters that were negotiated from a previous connection. To | parameters that were negotiated from a previous connection. To | |||
enable 0-RTT, endpoints store the value of the server transport | enable 0-RTT, endpoints store the values of the server transport | |||
parameters from a connection and apply them to any 0-RTT packets that | parameters with any session tickets it receives on the connection. | |||
are sent in subsequent connections to that peer that use a session | Endpoints also store any information required by the application | |||
ticket issued on that connection. This information is stored with | protocol or cryptographic handshake; see Section 4.6 of [QUIC-TLS]. | |||
any information required by the application protocol or cryptographic | The values of stored transport parameters are used when attempting | |||
handshake; see Section 4.6 of [QUIC-TLS]. | 0-RTT using the session tickets. | |||
Remembered transport parameters apply to the new connection until the | Remembered transport parameters apply to the new connection until the | |||
handshake completes and the client starts sending 1-RTT packets. | handshake completes and the client starts sending 1-RTT packets. | |||
Once the handshake completes, the client uses the transport | Once the handshake completes, the client uses the transport | |||
parameters established in the handshake. Not all transport | parameters established in the handshake. Not all transport | |||
parameters are remembered, as some do not apply to future connections | parameters are remembered, as some do not apply to future connections | |||
or they have no effect on use of 0-RTT. | or they have no effect on the use of 0-RTT. | |||
The definition of a new transport parameter (Section 7.4.2) MUST | The definition of a new transport parameter (Section 7.4.2) MUST | |||
specify whether storing the transport parameter for 0-RTT is | specify whether storing the transport parameter for 0-RTT is | |||
mandatory, optional, or prohibited. A client need not store a | mandatory, optional, or prohibited. A client need not store a | |||
transport parameter it cannot process. | transport parameter it cannot process. | |||
A client MUST NOT use remembered values for the following parameters: | A client MUST NOT use remembered values for the following parameters: | |||
ack_delay_exponent, max_ack_delay, initial_source_connection_id, | ack_delay_exponent, max_ack_delay, initial_source_connection_id, | |||
original_destination_connection_id, preferred_address, | original_destination_connection_id, preferred_address, | |||
retry_source_connection_id, and stateless_reset_token. The client | retry_source_connection_id, and stateless_reset_token. The client | |||
MUST use the server's new values in the handshake instead; if the | MUST use the server's new values in the handshake instead; if the | |||
server does not provide new values, the default value is used. | server does not provide new values, the default values are used. | |||
A client that attempts to send 0-RTT data MUST remember all other | A client that attempts to send 0-RTT data MUST remember all other | |||
transport parameters used by the server that it is able to process. | transport parameters used by the server that it is able to process. | |||
The server can remember these transport parameters, or store an | The server can remember these transport parameters or can store an | |||
integrity-protected copy of the values in the ticket and recover the | integrity-protected copy of the values in the ticket and recover the | |||
information when accepting 0-RTT data. A server uses the transport | information when accepting 0-RTT data. A server uses the transport | |||
parameters in determining whether to accept 0-RTT data. | parameters in determining whether to accept 0-RTT data. | |||
If 0-RTT data is accepted by the server, the server MUST NOT reduce | If 0-RTT data is accepted by the server, the server MUST NOT reduce | |||
any limits or alter any values that might be violated by the client | any limits or alter any values that might be violated by the client | |||
with its 0-RTT data. In particular, a server that accepts 0-RTT data | with its 0-RTT data. In particular, a server that accepts 0-RTT data | |||
MUST NOT set values for the following parameters (Section 18.2) that | MUST NOT set values for the following parameters (Section 18.2) that | |||
are smaller than the remembered value of the parameters. | are smaller than the remembered values of the parameters. | |||
o active_connection_id_limit | o active_connection_id_limit | |||
o initial_max_data | o initial_max_data | |||
o initial_max_stream_data_bidi_local | o initial_max_stream_data_bidi_local | |||
o initial_max_stream_data_bidi_remote | o initial_max_stream_data_bidi_remote | |||
o initial_max_stream_data_uni | o initial_max_stream_data_uni | |||
o initial_max_streams_bidi | o initial_max_streams_bidi | |||
o initial_max_streams_uni | o initial_max_streams_uni | |||
Omitting or setting a zero value for certain transport parameters can | Omitting or setting a zero value for certain transport parameters can | |||
result in 0-RTT data being enabled, but not usable. The applicable | result in 0-RTT data being enabled but not usable. The applicable | |||
subset of transport parameters that permit sending of application | subset of transport parameters that permit the sending of application | |||
data SHOULD be set to non-zero values for 0-RTT. This includes | data SHOULD be set to non-zero values for 0-RTT. This includes | |||
initial_max_data and either initial_max_streams_bidi and | initial_max_data and either (1) initial_max_streams_bidi and | |||
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and | initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni | |||
initial_max_stream_data_uni. | and initial_max_stream_data_uni. | |||
A server might provide larger initial stream flow control limits for | ||||
streams than the remembered values that a client applies when sending | ||||
0-RTT. Once the handshake completes, the client updates the flow | ||||
control limits on all sending streams using the updated values of | ||||
initial_max_stream_data_bidi_remote and initial_max_stream_data_uni. | ||||
A server MAY store and recover the previously sent values of the | A server MAY store and recover the previously sent values of the | |||
max_idle_timeout, max_udp_payload_size, and disable_active_migration | max_idle_timeout, max_udp_payload_size, and disable_active_migration | |||
parameters and reject 0-RTT if it selects smaller values. Lowering | parameters and reject 0-RTT if it selects smaller values. Lowering | |||
the values of these parameters while also accepting 0-RTT data could | the values of these parameters while also accepting 0-RTT data could | |||
degrade the performance of the connection. Specifically, lowering | degrade the performance of the connection. Specifically, lowering | |||
the max_udp_payload_size could result in dropped packets leading to | the max_udp_payload_size could result in dropped packets, leading to | |||
worse performance compared to rejecting 0-RTT data outright. | worse performance compared to rejecting 0-RTT data outright. | |||
A server MUST reject 0-RTT data if the restored values for transport | A server MUST reject 0-RTT data if the restored values for transport | |||
parameters cannot be supported. | parameters cannot be supported. | |||
When sending frames in 0-RTT packets, a client MUST only use | When sending frames in 0-RTT packets, a client MUST only use | |||
remembered transport parameters; importantly, it MUST NOT use updated | remembered transport parameters; importantly, it MUST NOT use updated | |||
values that it learns from the server's updated transport parameters | values that it learns from the server's updated transport parameters | |||
or from frames received in 1-RTT packets. Updated values of | or from frames received in 1-RTT packets. Updated values of | |||
transport parameters from the handshake apply only to 1-RTT packets. | transport parameters from the handshake apply only to 1-RTT packets. | |||
For instance, flow control limits from remembered transport | For instance, flow control limits from remembered transport | |||
parameters apply to all 0-RTT packets even if those values are | parameters apply to all 0-RTT packets even if those values are | |||
increased by the handshake or by frames sent in 1-RTT packets. A | increased by the handshake or by frames sent in 1-RTT packets. A | |||
server MAY treat use of updated transport parameters in 0-RTT as a | server MAY treat the use of updated transport parameters in 0-RTT as | |||
connection error of type PROTOCOL_VIOLATION. | a connection error of type PROTOCOL_VIOLATION. | |||
7.4.2. New Transport Parameters | 7.4.2. New Transport Parameters | |||
New transport parameters can be used to negotiate new protocol | New transport parameters can be used to negotiate new protocol | |||
behavior. An endpoint MUST ignore transport parameters that it does | behavior. An endpoint MUST ignore transport parameters that it does | |||
not support. Absence of a transport parameter therefore disables any | not support. The absence of a transport parameter therefore disables | |||
optional protocol feature that is negotiated using the parameter. As | any optional protocol feature that is negotiated using the parameter. | |||
described in Section 18.1, some identifiers are reserved in order to | As described in Section 18.1, some identifiers are reserved in order | |||
exercise this requirement. | to exercise this requirement. | |||
A client that does not understand a transport parameter can discard | A client that does not understand a transport parameter can discard | |||
it and attempt 0-RTT on subsequent connections. However, if the | it and attempt 0-RTT on subsequent connections. However, if the | |||
client adds support for a discarded transport parameter, it risks | client adds support for a discarded transport parameter, it risks | |||
violating the constraints that the transport parameter establishes if | violating the constraints that the transport parameter establishes if | |||
it attempts 0-RTT. New transport parameters can avoid this problem | it attempts 0-RTT. New transport parameters can avoid this problem | |||
by setting a default of the most conservative value. Clients can | by setting a default of the most conservative value. Clients can | |||
avoid this problem by remembering all parameters, even ones not | avoid this problem by remembering all parameters, even those not | |||
currently supported. | currently supported. | |||
New transport parameters can be registered according to the rules in | New transport parameters can be registered according to the rules in | |||
Section 22.3. | Section 22.3. | |||
7.5. Cryptographic Message Buffering | 7.5. Cryptographic Message Buffering | |||
Implementations need to maintain a buffer of CRYPTO data received out | Implementations need to maintain a buffer of CRYPTO data received out | |||
of order. Because there is no flow control of CRYPTO frames, an | of order. Because there is no flow control of CRYPTO frames, an | |||
endpoint could potentially force its peer to buffer an unbounded | endpoint could potentially force its peer to buffer an unbounded | |||
skipping to change at page 49, line 5 ¶ | skipping to change at page 48, line 8 ¶ | |||
peer is able to receive packets at the transport address that it | peer is able to receive packets at the transport address that it | |||
claims. Therefore, after receiving packets from an address that is | claims. Therefore, after receiving packets from an address that is | |||
not yet validated, an endpoint MUST limit the amount of data it sends | not yet validated, an endpoint MUST limit the amount of data it sends | |||
to the unvalidated address to three times the amount of data received | to the unvalidated address to three times the amount of data received | |||
from that address. This limit on the size of responses is known as | from that address. This limit on the size of responses is known as | |||
the anti-amplification limit. | the anti-amplification limit. | |||
Address validation is performed both during connection establishment | Address validation is performed both during connection establishment | |||
(see Section 8.1) and during connection migration (see Section 8.2). | (see Section 8.1) and during connection migration (see Section 8.2). | |||
8.1. Address Validation During Connection Establishment | 8.1. Address Validation during Connection Establishment | |||
Connection establishment implicitly provides address validation for | Connection establishment implicitly provides address validation for | |||
both endpoints. In particular, receipt of a packet protected with | both endpoints. In particular, receipt of a packet protected with | |||
Handshake keys confirms that the peer successfully processed an | Handshake keys confirms that the peer successfully processed an | |||
Initial packet. Once an endpoint has successfully processed a | Initial packet. Once an endpoint has successfully processed a | |||
Handshake packet from the peer, it can consider the peer address to | Handshake packet from the peer, it can consider the peer address to | |||
have been validated. | have been validated. | |||
Additionally, an endpoint MAY consider the peer address validated if | Additionally, an endpoint MAY consider the peer address validated if | |||
the peer uses a connection ID chosen by the endpoint and the | the peer uses a connection ID chosen by the endpoint and the | |||
skipping to change at page 49, line 48 ¶ | skipping to change at page 48, line 51 ¶ | |||
necessary. A client that sends padded datagrams allows the server to | necessary. A client that sends padded datagrams allows the server to | |||
send more data prior to completing address validation. | send more data prior to completing address validation. | |||
Loss of an Initial or Handshake packet from the server can cause a | Loss of an Initial or Handshake packet from the server can cause a | |||
deadlock if the client does not send additional Initial or Handshake | deadlock if the client does not send additional Initial or Handshake | |||
packets. A deadlock could occur when the server reaches its anti- | packets. A deadlock could occur when the server reaches its anti- | |||
amplification limit and the client has received acknowledgments for | amplification limit and the client has received acknowledgments for | |||
all the data it has sent. In this case, when the client has no | all the data it has sent. In this case, when the client has no | |||
reason to send additional packets, the server will be unable to send | reason to send additional packets, the server will be unable to send | |||
more data because it has not validated the client's address. To | more data because it has not validated the client's address. To | |||
prevent this deadlock, clients MUST send a packet on a probe timeout | prevent this deadlock, clients MUST send a packet on a Probe Timeout | |||
(PTO, see Section 6.2 of [QUIC-RECOVERY]). Specifically, the client | (PTO); see Section 6.2 of [QUIC-RECOVERY]. Specifically, the client | |||
MUST send an Initial packet in a UDP datagram that contains at least | MUST send an Initial packet in a UDP datagram that contains at least | |||
1200 bytes if it does not have Handshake keys, and otherwise send a | 1200 bytes if it does not have Handshake keys, and otherwise send a | |||
Handshake packet. | Handshake packet. | |||
A server might wish to validate the client address before starting | A server might wish to validate the client address before starting | |||
the cryptographic handshake. QUIC uses a token in the Initial packet | the cryptographic handshake. QUIC uses a token in the Initial packet | |||
to provide address validation prior to completing the handshake. | to provide address validation prior to completing the handshake. | |||
This token is delivered to the client during connection establishment | This token is delivered to the client during connection establishment | |||
with a Retry packet (see Section 8.1.2) or in a previous connection | with a Retry packet (see Section 8.1.2) or in a previous connection | |||
using the NEW_TOKEN frame (see Section 8.1.3). | using the NEW_TOKEN frame (see Section 8.1.3). | |||
In addition to sending limits imposed prior to address validation, | In addition to sending limits imposed prior to address validation, | |||
servers are also constrained in what they can send by the limits set | servers are also constrained in what they can send by the limits set | |||
by the congestion controller. Clients are only constrained by the | by the congestion controller. Clients are only constrained by the | |||
congestion controller. | congestion controller. | |||
8.1.1. Token Construction | 8.1.1. Token Construction | |||
A token sent in a NEW_TOKEN frame or a Retry packet MUST be | A token sent in a NEW_TOKEN frame or a Retry packet MUST be | |||
constructed in a way that allows the server to identify how it was | constructed in a way that allows the server to identify how it was | |||
provided to a client. These tokens are carried in the same field, | provided to a client. These tokens are carried in the same field but | |||
but require different handling from servers. | require different handling from servers. | |||
8.1.2. Address Validation using Retry Packets | 8.1.2. Address Validation Using Retry Packets | |||
Upon receiving the client's Initial packet, the server can request | Upon receiving the client's Initial packet, the server can request | |||
address validation by sending a Retry packet (Section 17.2.5) | address validation by sending a Retry packet (Section 17.2.5) | |||
containing a token. This token MUST be repeated by the client in all | containing a token. This token MUST be repeated by the client in all | |||
Initial packets it sends for that connection after it receives the | Initial packets it sends for that connection after it receives the | |||
Retry packet. | Retry packet. | |||
In response to processing an Initial containing a token that was | In response to processing an Initial packet containing a token that | |||
provided in a Retry packet, a server cannot send another Retry | was provided in a Retry packet, a server cannot send another Retry | |||
packet; it can only refuse the connection or permit it to proceed. | packet; it can only refuse the connection or permit it to proceed. | |||
As long as it is not possible for an attacker to generate a valid | As long as it is not possible for an attacker to generate a valid | |||
token for its own address (see Section 8.1.4) and the client is able | token for its own address (see Section 8.1.4) and the client is able | |||
to return that token, it proves to the server that it received the | to return that token, it proves to the server that it received the | |||
token. | token. | |||
A server can also use a Retry packet to defer the state and | A server can also use a Retry packet to defer the state and | |||
processing costs of connection establishment. Requiring the server | processing costs of connection establishment. Requiring the server | |||
to provide a different connection ID, along with the | to provide a different connection ID, along with the | |||
skipping to change at page 52, line 40 ¶ | skipping to change at page 51, line 45 ¶ | |||
connection to that server. | connection to that server. | |||
A token allows a server to correlate activity between the connection | A token allows a server to correlate activity between the connection | |||
where the token was issued and any connection where it is used. | where the token was issued and any connection where it is used. | |||
Clients that want to break continuity of identity with a server can | Clients that want to break continuity of identity with a server can | |||
discard tokens provided using the NEW_TOKEN frame. In comparison, a | discard tokens provided using the NEW_TOKEN frame. In comparison, a | |||
token obtained in a Retry packet MUST be used immediately during the | token obtained in a Retry packet MUST be used immediately during the | |||
connection attempt and cannot be used in subsequent connection | connection attempt and cannot be used in subsequent connection | |||
attempts. | attempts. | |||
A client SHOULD NOT reuse a NEW_TOKEN token for different connection | A client SHOULD NOT reuse a token from a NEW_TOKEN frame for | |||
attempts. Reusing a token allows connections to be linked by | different connection attempts. Reusing a token allows connections to | |||
entities on the network path; see Section 9.5. | be linked by entities on the network path; see Section 9.5. | |||
Clients might receive multiple tokens on a single connection. Aside | Clients might receive multiple tokens on a single connection. Aside | |||
from preventing linkability, any token can be used in any connection | from preventing linkability, any token can be used in any connection | |||
attempt. Servers can send additional tokens to either enable address | attempt. Servers can send additional tokens to either enable address | |||
validation for multiple connection attempts or to replace older | validation for multiple connection attempts or replace older tokens | |||
tokens that might become invalid. For a client, this ambiguity means | that might become invalid. For a client, this ambiguity means that | |||
that sending the most recent unused token is most likely to be | sending the most recent unused token is most likely to be effective. | |||
effective. Though saving and using older tokens has no negative | Though saving and using older tokens have no negative consequences, | |||
consequences, clients can regard older tokens as being less likely be | clients can regard older tokens as being less likely to be useful to | |||
useful to the server for address validation. | the server for address validation. | |||
When a server receives an Initial packet with an address validation | When a server receives an Initial packet with an address validation | |||
token, it MUST attempt to validate the token, unless it has already | token, it MUST attempt to validate the token, unless it has already | |||
completed address validation. If the token is invalid then the | completed address validation. If the token is invalid, then the | |||
server SHOULD proceed as if the client did not have a validated | server SHOULD proceed as if the client did not have a validated | |||
address, including potentially sending a Retry. Tokens provided with | address, including potentially sending a Retry packet. Tokens | |||
NEW_TOKEN frames and Retry packets can be distinguished by servers | provided with NEW_TOKEN frames and Retry packets can be distinguished | |||
(see Section 8.1.1), and the latter validated more strictly. If the | by servers (see Section 8.1.1), and the latter can be validated more | |||
validation succeeds, the server SHOULD then allow the handshake to | strictly. If the validation succeeds, the server SHOULD then allow | |||
proceed. | the handshake to proceed. | |||
Note: The rationale for treating the client as unvalidated rather | Note: The rationale for treating the client as unvalidated rather | |||
than discarding the packet is that the client might have received | than discarding the packet is that the client might have received | |||
the token in a previous connection using the NEW_TOKEN frame, and | the token in a previous connection using the NEW_TOKEN frame, and | |||
if the server has lost state, it might be unable to validate the | if the server has lost state, it might be unable to validate the | |||
token at all, leading to connection failure if the packet is | token at all, leading to connection failure if the packet is | |||
discarded. | discarded. | |||
In a stateless design, a server can use encrypted and authenticated | In a stateless design, a server can use encrypted and authenticated | |||
tokens to pass information to clients that the server can later | tokens to pass information to clients that the server can later | |||
recover and use to validate a client address. Tokens are not | recover and use to validate a client address. Tokens are not | |||
integrated into the cryptographic handshake and so they are not | integrated into the cryptographic handshake, and so they are not | |||
authenticated. For instance, a client might be able to reuse a | authenticated. For instance, a client might be able to reuse a | |||
token. To avoid attacks that exploit this property, a server can | token. To avoid attacks that exploit this property, a server can | |||
limit its use of tokens to only the information needed to validate | limit its use of tokens to only the information needed to validate | |||
client addresses. | client addresses. | |||
Clients MAY use tokens obtained on one connection for any connection | Clients MAY use tokens obtained on one connection for any connection | |||
attempt using the same version. When selecting a token to use, | attempt using the same version. When selecting a token to use, | |||
clients do not need to consider other properties of the connection | clients do not need to consider other properties of the connection | |||
that is being attempted, including the choice of possible application | that is being attempted, including the choice of possible application | |||
protocols, session tickets, or other connection properties. | protocols, session tickets, or other connection properties. | |||
skipping to change at page 54, line 13 ¶ | skipping to change at page 53, line 18 ¶ | |||
requires access to the integrity protection key for tokens. | requires access to the integrity protection key for tokens. | |||
There is no need for a single well-defined format for the token | There is no need for a single well-defined format for the token | |||
because the server that generates the token also consumes it. Tokens | because the server that generates the token also consumes it. Tokens | |||
sent in Retry packets SHOULD include information that allows the | sent in Retry packets SHOULD include information that allows the | |||
server to verify that the source IP address and port in client | server to verify that the source IP address and port in client | |||
packets remain constant. | packets remain constant. | |||
Tokens sent in NEW_TOKEN frames MUST include information that allows | Tokens sent in NEW_TOKEN frames MUST include information that allows | |||
the server to verify that the client IP address has not changed from | the server to verify that the client IP address has not changed from | |||
when the token was issued. Servers can use tokens from NEW_TOKEN in | when the token was issued. Servers can use tokens from NEW_TOKEN | |||
deciding not to send a Retry packet, even if the client address has | frames in deciding not to send a Retry packet, even if the client | |||
changed. If the client IP address has changed, the server MUST | address has changed. If the client IP address has changed, the | |||
adhere to the anti-amplification limit; see Section 8. Note that in | server MUST adhere to the anti-amplification limit; see Section 8. | |||
the presence of NAT, this requirement might be insufficient to | Note that in the presence of NAT, this requirement might be | |||
protect other hosts that share the NAT from amplification attack. | insufficient to protect other hosts that share the NAT from | |||
amplification attacks. | ||||
Attackers could replay tokens to use servers as amplifiers in DDoS | Attackers could replay tokens to use servers as amplifiers in DDoS | |||
attacks. To protect against such attacks, servers MUST ensure that | attacks. To protect against such attacks, servers MUST ensure that | |||
replay of tokens is prevented or limited. Servers SHOULD ensure that | replay of tokens is prevented or limited. Servers SHOULD ensure that | |||
tokens sent in Retry packets are only accepted for a short time, as | tokens sent in Retry packets are only accepted for a short time, as | |||
they are returned immediately by clients. Tokens that are provided | they are returned immediately by clients. Tokens that are provided | |||
in NEW_TOKEN frames (Section 19.7) need to be valid for longer, but | in NEW_TOKEN frames (Section 19.7) need to be valid for longer but | |||
SHOULD NOT be accepted multiple times. Servers are encouraged to | SHOULD NOT be accepted multiple times. Servers are encouraged to | |||
allow tokens to be used only once, if possible; tokens MAY include | allow tokens to be used only once, if possible; tokens MAY include | |||
additional information about clients to further narrow applicability | additional information about clients to further narrow applicability | |||
or reuse. | or reuse. | |||
8.2. Path Validation | 8.2. Path Validation | |||
Path validation is used by both peers during connection migration | Path validation is used by both peers during connection migration | |||
(see Section 9) to verify reachability after a change of address. In | (see Section 9) to verify reachability after a change of address. In | |||
path validation, endpoints test reachability between a specific local | path validation, endpoints test reachability between a specific local | |||
address and a specific peer address, where an address is the two- | address and a specific peer address, where an address is the 2-tuple | |||
tuple of IP address and port. | of IP address and port. | |||
Path validation tests that packets sent on a path to a peer are | Path validation tests that packets sent on a path to a peer are | |||
received by that peer. Path validation is used to ensure that | received by that peer. Path validation is used to ensure that | |||
packets received from a migrating peer do not carry a spoofed source | packets received from a migrating peer do not carry a spoofed source | |||
address. | address. | |||
Path validation does not validate that a peer can send in the return | Path validation does not validate that a peer can send in the return | |||
direction. Acknowledgments cannot be used for return path validation | direction. Acknowledgments cannot be used for return path validation | |||
because they contain insufficient entropy and might be spoofed. | because they contain insufficient entropy and might be spoofed. | |||
Endpoints independently determine reachability on each direction of a | Endpoints independently determine reachability on each direction of a | |||
path, and therefore return reachability can only be established by | path, and therefore return reachability can only be established by | |||
the peer. | the peer. | |||
Path validation can be used at any time by either endpoint. For | Path validation can be used at any time by either endpoint. For | |||
instance, an endpoint might check that a peer is still in possession | instance, an endpoint might check that a peer is still in possession | |||
of its address after a period of quiescence. | of its address after a period of quiescence. | |||
Path validation is not designed as a NAT traversal mechanism. Though | Path validation is not designed as a NAT traversal mechanism. Though | |||
the mechanism described here might be effective for the creation of | the mechanism described here might be effective for the creation of | |||
NAT bindings that support NAT traversal, the expectation is that one | NAT bindings that support NAT traversal, the expectation is that one | |||
or other peer is able to receive packets without first having sent a | endpoint is able to receive packets without first having sent a | |||
packet on that path. Effective NAT traversal needs additional | packet on that path. Effective NAT traversal needs additional | |||
synchronization mechanisms that are not provided here. | synchronization mechanisms that are not provided here. | |||
An endpoint MAY include other frames with the PATH_CHALLENGE and | An endpoint MAY include other frames with the PATH_CHALLENGE and | |||
PATH_RESPONSE frames used for path validation. In particular, an | PATH_RESPONSE frames used for path validation. In particular, an | |||
endpoint can include PADDING frames with a PATH_CHALLENGE frame for | endpoint can include PADDING frames with a PATH_CHALLENGE frame for | |||
Path Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1); | Path Maximum Transmission Unit Discovery (PMTUD); see Section 14.2.1. | |||
it can also include its own PATH_CHALLENGE frame with a PATH_RESPONSE | An endpoint can also include its own PATH_CHALLENGE frame when | |||
frame. | sending a PATH_RESPONSE frame. | |||
An endpoint uses a new connection ID for probes sent from a new local | An endpoint uses a new connection ID for probes sent from a new local | |||
address; see Section 9.5. When probing a new path, an endpoint can | address; see Section 9.5. When probing a new path, an endpoint can | |||
ensure that its peer has an unused connection ID available for | ensure that its peer has an unused connection ID available for | |||
responses. Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in | responses. Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in | |||
the same packet, if the peer's active_connection_id_limit permits, | the same packet, if the peer's active_connection_id_limit permits, | |||
ensures that an unused connection ID will be available to the peer | ensures that an unused connection ID will be available to the peer | |||
when sending a response. | when sending a response. | |||
An endpoint can choose to simultaneously probe multiple paths. The | An endpoint can choose to simultaneously probe multiple paths. The | |||
skipping to change at page 56, line 39 ¶ | skipping to change at page 55, line 41 ¶ | |||
8.2.2. Path Validation Responses | 8.2.2. Path Validation Responses | |||
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by | On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by | |||
echoing the data contained in the PATH_CHALLENGE frame in a | echoing the data contained in the PATH_CHALLENGE frame in a | |||
PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a | PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a | |||
packet containing a PATH_RESPONSE frame unless constrained by | packet containing a PATH_RESPONSE frame unless constrained by | |||
congestion control. | congestion control. | |||
A PATH_RESPONSE frame MUST be sent on the network path where the | A PATH_RESPONSE frame MUST be sent on the network path where the | |||
PATH_CHALLENGE was received. This ensures that path validation by a | PATH_CHALLENGE frame was received. This ensures that path validation | |||
peer only succeeds if the path is functional in both directions. | by a peer only succeeds if the path is functional in both directions. | |||
This requirement MUST NOT be enforced by the endpoint that initiates | This requirement MUST NOT be enforced by the endpoint that initiates | |||
path validation as that would enable an attack on migration; see | path validation, as that would enable an attack on migration; see | |||
Section 9.3.3. | Section 9.3.3. | |||
An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame | An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame | |||
to at least the smallest allowed maximum datagram size of 1200 bytes. | to at least the smallest allowed maximum datagram size of 1200 bytes. | |||
This verifies that the path is able to carry datagrams of this size | This verifies that the path is able to carry datagrams of this size | |||
in both directions. However, an endpoint MUST NOT expand the | in both directions. However, an endpoint MUST NOT expand the | |||
datagram containing the PATH_RESPONSE if the resulting data exceeds | datagram containing the PATH_RESPONSE if the resulting data exceeds | |||
the anti-amplification limit. This is expected to only occur if the | the anti-amplification limit. This is expected to only occur if the | |||
received PATH_CHALLENGE was not sent in an expanded datagram. | received PATH_CHALLENGE was not sent in an expanded datagram. | |||
skipping to change at page 57, line 18 ¶ | skipping to change at page 56, line 20 ¶ | |||
additional PATH_RESPONSE frames. | additional PATH_RESPONSE frames. | |||
8.2.3. Successful Path Validation | 8.2.3. Successful Path Validation | |||
Path validation succeeds when a PATH_RESPONSE frame is received that | Path validation succeeds when a PATH_RESPONSE frame is received that | |||
contains the data that was sent in a previous PATH_CHALLENGE frame. | contains the data that was sent in a previous PATH_CHALLENGE frame. | |||
A PATH_RESPONSE frame received on any network path validates the path | A PATH_RESPONSE frame received on any network path validates the path | |||
on which the PATH_CHALLENGE was sent. | on which the PATH_CHALLENGE was sent. | |||
If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not | If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not | |||
expanded to at least 1200 bytes, and if the response to it validates | expanded to at least 1200 bytes and if the response to it validates | |||
the peer address, the path is validated but not the path MTU. As a | the peer address, the path is validated but not the path MTU. As a | |||
result, the endpoint can now send more than three times the amount of | result, the endpoint can now send more than three times the amount of | |||
data that has been received. However, the endpoint MUST initiate | data that has been received. However, the endpoint MUST initiate | |||
another path validation with an expanded datagram to verify that the | another path validation with an expanded datagram to verify that the | |||
path supports the required MTU. | path supports the required MTU. | |||
Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE | Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE | |||
frame is not adequate validation, since the acknowledgment can be | frame is not adequate validation, since the acknowledgment can be | |||
spoofed by a malicious peer. | spoofed by a malicious peer. | |||
8.2.4. Failed Path Validation | 8.2.4. Failed Path Validation | |||
Path validation only fails when the endpoint attempting to validate | Path validation only fails when the endpoint attempting to validate | |||
the path abandons its attempt to validate the path. | the path abandons its attempt to validate the path. | |||
Endpoints SHOULD abandon path validation based on a timer. When | Endpoints SHOULD abandon path validation based on a timer. When | |||
setting this timer, implementations are cautioned that the new path | setting this timer, implementations are cautioned that the new path | |||
could have a longer round-trip time than the original. A value of | could have a longer round-trip time than the original. A value of | |||
three times the larger of the current Probe Timeout (PTO) or the PTO | three times the larger of the current PTO or the PTO for the new path | |||
for the new path (that is, using kInitialRtt as defined in | (using kInitialRtt, as defined in [QUIC-RECOVERY]) is RECOMMENDED. | |||
[QUIC-RECOVERY]) is RECOMMENDED. | ||||
This timeout allows for multiple PTOs to expire prior to failing path | This timeout allows for multiple PTOs to expire prior to failing path | |||
validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE | validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE | |||
frame does not cause path validation failure. | frame does not cause path validation failure. | |||
Note that the endpoint might receive packets containing other frames | Note that the endpoint might receive packets containing other frames | |||
on the new path, but a PATH_RESPONSE frame with appropriate data is | on the new path, but a PATH_RESPONSE frame with appropriate data is | |||
required for path validation to succeed. | required for path validation to succeed. | |||
When an endpoint abandons path validation, it determines that the | When an endpoint abandons path validation, it determines that the | |||
path is unusable. This does not necessarily imply a failure of the | path is unusable. This does not necessarily imply a failure of the | |||
connection - endpoints can continue sending packets over other paths | connection -- endpoints can continue sending packets over other paths | |||
as appropriate. If no paths are available, an endpoint can wait for | as appropriate. If no paths are available, an endpoint can wait for | |||
a new path to become available or close the connection. An endpoint | a new path to become available or close the connection. An endpoint | |||
that has no valid network path to its peer MAY signal this using the | that has no valid network path to its peer MAY signal this using the | |||
NO_VIABLE_PATH connection error, noting that this is only possible if | NO_VIABLE_PATH connection error, noting that this is only possible if | |||
the network path exists but does not support the required MTU | the network path exists but does not support the required MTU | |||
(Section 14). | (Section 14). | |||
A path validation might be abandoned for other reasons besides | A path validation might be abandoned for other reasons besides | |||
failure. Primarily, this happens if a connection migration to a new | failure. Primarily, this happens if a connection migration to a new | |||
path is initiated while a path validation on the old path is in | path is initiated while a path validation on the old path is in | |||
skipping to change at page 58, line 25 ¶ | skipping to change at page 57, line 27 ¶ | |||
9. Connection Migration | 9. Connection Migration | |||
The use of a connection ID allows connections to survive changes to | The use of a connection ID allows connections to survive changes to | |||
endpoint addresses (IP address and port), such as those caused by an | endpoint addresses (IP address and port), such as those caused by an | |||
endpoint migrating to a new network. This section describes the | endpoint migrating to a new network. This section describes the | |||
process by which an endpoint migrates to a new address. | process by which an endpoint migrates to a new address. | |||
The design of QUIC relies on endpoints retaining a stable address for | The design of QUIC relies on endpoints retaining a stable address for | |||
the duration of the handshake. An endpoint MUST NOT initiate | the duration of the handshake. An endpoint MUST NOT initiate | |||
connection migration before the handshake is confirmed, as defined in | connection migration before the handshake is confirmed, as defined in | |||
section 4.1.2 of [QUIC-TLS]. | Section 4.1.2 of [QUIC-TLS]. | |||
If the peer sent the disable_active_migration transport parameter, an | If the peer sent the disable_active_migration transport parameter, an | |||
endpoint also MUST NOT send packets (including probing packets; see | endpoint also MUST NOT send packets (including probing packets; see | |||
Section 9.1) from a different local address to the address the peer | Section 9.1) from a different local address to the address the peer | |||
used during the handshake, unless the endpoint has acted on a | used during the handshake, unless the endpoint has acted on a | |||
preferred_address transport parameter from the peer. If the peer | preferred_address transport parameter from the peer. If the peer | |||
violates this requirement, the endpoint MUST either drop the incoming | violates this requirement, the endpoint MUST either drop the incoming | |||
packets on that path without generating a stateless reset or proceed | packets on that path without generating a Stateless Reset or proceed | |||
with path validation and allow the peer to migrate. Generating a | with path validation and allow the peer to migrate. Generating a | |||
stateless reset or closing the connection would allow third parties | Stateless Reset or closing the connection would allow third parties | |||
in the network to cause connections to close by spoofing or otherwise | in the network to cause connections to close by spoofing or otherwise | |||
manipulating observed traffic. | manipulating observed traffic. | |||
Not all changes of peer address are intentional, or active, | Not all changes of peer address are intentional, or active, | |||
migrations. The peer could experience NAT rebinding: a change of | migrations. The peer could experience NAT rebinding: a change of | |||
address due to a middlebox, usually a NAT, allocating a new outgoing | address due to a middlebox, usually a NAT, allocating a new outgoing | |||
port or even a new outgoing IP address for a flow. An endpoint MUST | port or even a new outgoing IP address for a flow. An endpoint MUST | |||
perform path validation (Section 8.2) if it detects any change to a | perform path validation (Section 8.2) if it detects any change to a | |||
peer's address, unless it has previously validated that address. | peer's address, unless it has previously validated that address. | |||
skipping to change at page 59, line 35 ¶ | skipping to change at page 58, line 35 ¶ | |||
packet containing any other frame is a "non-probing packet". | packet containing any other frame is a "non-probing packet". | |||
9.2. Initiating Connection Migration | 9.2. Initiating Connection Migration | |||
An endpoint can migrate a connection to a new local address by | An endpoint can migrate a connection to a new local address by | |||
sending packets containing non-probing frames from that address. | sending packets containing non-probing frames from that address. | |||
Each endpoint validates its peer's address during connection | Each endpoint validates its peer's address during connection | |||
establishment. Therefore, a migrating endpoint can send to its peer | establishment. Therefore, a migrating endpoint can send to its peer | |||
knowing that the peer is willing to receive at the peer's current | knowing that the peer is willing to receive at the peer's current | |||
address. Thus an endpoint can migrate to a new local address without | address. Thus, an endpoint can migrate to a new local address | |||
first validating the peer's address. | without first validating the peer's address. | |||
To establish reachability on the new path, an endpoint initiates path | To establish reachability on the new path, an endpoint initiates path | |||
validation (Section 8.2) on the new path. An endpoint MAY defer path | validation (Section 8.2) on the new path. An endpoint MAY defer path | |||
validation until after a peer sends the next non-probing frame to its | validation until after a peer sends the next non-probing frame to its | |||
new address. | new address. | |||
When migrating, the new path might not support the endpoint's current | When migrating, the new path might not support the endpoint's current | |||
sending rate. Therefore, the endpoint resets its congestion | sending rate. Therefore, the endpoint resets its congestion | |||
controller and RTT estimate, as described in Section 9.4. | controller and RTT estimate, as described in Section 9.4. | |||
skipping to change at page 60, line 13 ¶ | skipping to change at page 59, line 13 ¶ | |||
endpoint validates ECN capability as described in Section 13.4. | endpoint validates ECN capability as described in Section 13.4. | |||
9.3. Responding to Connection Migration | 9.3. Responding to Connection Migration | |||
Receiving a packet from a new peer address containing a non-probing | Receiving a packet from a new peer address containing a non-probing | |||
frame indicates that the peer has migrated to that address. | frame indicates that the peer has migrated to that address. | |||
If the recipient permits the migration, it MUST send subsequent | If the recipient permits the migration, it MUST send subsequent | |||
packets to the new peer address and MUST initiate path validation | packets to the new peer address and MUST initiate path validation | |||
(Section 8.2) to verify the peer's ownership of the address if | (Section 8.2) to verify the peer's ownership of the address if | |||
validation is not already underway. | validation is not already underway. If the recipient has no unused | |||
connection IDs from the peer, it will not be able to send anything on | ||||
the new path until the peer provides one; see Section 9.5. | ||||
An endpoint only changes the address to which it sends packets in | An endpoint only changes the address to which it sends packets in | |||
response to the highest-numbered non-probing packet. This ensures | response to the highest-numbered non-probing packet. This ensures | |||
that an endpoint does not send packets to an old peer address in the | that an endpoint does not send packets to an old peer address in the | |||
case that it receives reordered packets. | case that it receives reordered packets. | |||
An endpoint MAY send data to an unvalidated peer address, but it MUST | An endpoint MAY send data to an unvalidated peer address, but it MUST | |||
protect against potential attacks as described in Section 9.3.1 and | protect against potential attacks as described in Sections 9.3.1 and | |||
Section 9.3.2. An endpoint MAY skip validation of a peer address if | 9.3.2. An endpoint MAY skip validation of a peer address if that | |||
that address has been seen recently. In particular, if an endpoint | address has been seen recently. In particular, if an endpoint | |||
returns to a previously-validated path after detecting some form of | returns to a previously validated path after detecting some form of | |||
spurious migration, skipping address validation and restoring loss | spurious migration, skipping address validation and restoring loss | |||
detection and congestion state can reduce the performance impact of | detection and congestion state can reduce the performance impact of | |||
the attack. | the attack. | |||
After changing the address to which it sends non-probing packets, an | After changing the address to which it sends non-probing packets, an | |||
endpoint can abandon any path validation for other addresses. | endpoint can abandon any path validation for other addresses. | |||
Receiving a packet from a new peer address could be the result of a | Receiving a packet from a new peer address could be the result of a | |||
NAT rebinding at the peer. | NAT rebinding at the peer. | |||
skipping to change at page 60, line 50 ¶ | skipping to change at page 60, line 4 ¶ | |||
It is possible that a peer is spoofing its source address to cause an | It is possible that a peer is spoofing its source address to cause an | |||
endpoint to send excessive amounts of data to an unwilling host. If | endpoint to send excessive amounts of data to an unwilling host. If | |||
the endpoint sends significantly more data than the spoofing peer, | the endpoint sends significantly more data than the spoofing peer, | |||
connection migration might be used to amplify the volume of data that | connection migration might be used to amplify the volume of data that | |||
an attacker can generate toward a victim. | an attacker can generate toward a victim. | |||
As described in Section 9.3, an endpoint is required to validate a | As described in Section 9.3, an endpoint is required to validate a | |||
peer's new address to confirm the peer's possession of the new | peer's new address to confirm the peer's possession of the new | |||
address. Until a peer's address is deemed valid, an endpoint limits | address. Until a peer's address is deemed valid, an endpoint limits | |||
the amount of data it sends to that address; see Section 8. In the | the amount of data it sends to that address; see Section 8. In the | |||
absence of this limit, an endpoint risks being used for a denial of | absence of this limit, an endpoint risks being used for a denial-of- | |||
service attack against an unsuspecting victim. | service attack against an unsuspecting victim. | |||
If an endpoint skips validation of a peer address as described above, | If an endpoint skips validation of a peer address as described above, | |||
it does not need to limit its sending rate. | it does not need to limit its sending rate. | |||
9.3.2. On-Path Address Spoofing | 9.3.2. On-Path Address Spoofing | |||
An on-path attacker could cause a spurious connection migration by | An on-path attacker could cause a spurious connection migration by | |||
copying and forwarding a packet with a spoofed address such that it | copying and forwarding a packet with a spoofed address such that it | |||
arrives before the original packet. The packet with the spoofed | arrives before the original packet. The packet with the spoofed | |||
skipping to change at page 61, line 32 ¶ | skipping to change at page 60, line 34 ¶ | |||
address when validation of a new peer address fails. Additionally, | address when validation of a new peer address fails. Additionally, | |||
receipt of packets with higher packet numbers from the legitimate | receipt of packets with higher packet numbers from the legitimate | |||
peer address will trigger another connection migration. This will | peer address will trigger another connection migration. This will | |||
cause the validation of the address of the spurious migration to be | cause the validation of the address of the spurious migration to be | |||
abandoned, thus containing migrations initiated by the attacker | abandoned, thus containing migrations initiated by the attacker | |||
injecting a single packet. | injecting a single packet. | |||
If an endpoint has no state about the last validated peer address, it | If an endpoint has no state about the last validated peer address, it | |||
MUST close the connection silently by discarding all connection | MUST close the connection silently by discarding all connection | |||
state. This results in new packets on the connection being handled | state. This results in new packets on the connection being handled | |||
generically. For instance, an endpoint MAY send a stateless reset in | generically. For instance, an endpoint MAY send a Stateless Reset in | |||
response to any further incoming packets. | response to any further incoming packets. | |||
9.3.3. Off-Path Packet Forwarding | 9.3.3. Off-Path Packet Forwarding | |||
An off-path attacker that can observe packets might forward copies of | An off-path attacker that can observe packets might forward copies of | |||
genuine packets to endpoints. If the copied packet arrives before | genuine packets to endpoints. If the copied packet arrives before | |||
the genuine packet, this will appear as a NAT rebinding. Any genuine | the genuine packet, this will appear as a NAT rebinding. Any genuine | |||
packet will be discarded as a duplicate. If the attacker is able to | packet will be discarded as a duplicate. If the attacker is able to | |||
continue forwarding packets, it might be able to cause migration to a | continue forwarding packets, it might be able to cause migration to a | |||
path via the attacker. This places the attacker on path, giving it | path via the attacker. This places the attacker on-path, giving it | |||
the ability to observe or drop all subsequent packets. | the ability to observe or drop all subsequent packets. | |||
This style of attack relies on the attacker using a path that has | This style of attack relies on the attacker using a path that has | |||
approximately the same characteristics as the direct path between | approximately the same characteristics as the direct path between | |||
endpoints. The attack is more reliable if relatively few packets are | endpoints. The attack is more reliable if relatively few packets are | |||
sent or if packet loss coincides with the attempted attack. | sent or if packet loss coincides with the attempted attack. | |||
A non-probing packet received on the original path that increases the | A non-probing packet received on the original path that increases the | |||
maximum received packet number will cause the endpoint to move back | maximum received packet number will cause the endpoint to move back | |||
to that path. Eliciting packets on this path increases the | to that path. Eliciting packets on this path increases the | |||
likelihood that the attack is unsuccessful. Therefore, mitigation of | likelihood that the attack is unsuccessful. Therefore, mitigation of | |||
this attack relies on triggering the exchange of packets. | this attack relies on triggering the exchange of packets. | |||
In response to an apparent migration, endpoints MUST validate the | In response to an apparent migration, endpoints MUST validate the | |||
previously active path using a PATH_CHALLENGE frame. This induces | previously active path using a PATH_CHALLENGE frame. This induces | |||
the sending of new packets on that path. If the path is no longer | the sending of new packets on that path. If the path is no longer | |||
viable, the validation attempt will time out and fail; if the path is | viable, the validation attempt will time out and fail; if the path is | |||
viable, but no longer desired, the validation will succeed, but only | viable but no longer desired, the validation will succeed but only | |||
results in probing packets being sent on the path. | results in probing packets being sent on the path. | |||
An endpoint that receives a PATH_CHALLENGE on an active path SHOULD | An endpoint that receives a PATH_CHALLENGE on an active path SHOULD | |||
send a non-probing packet in response. If the non-probing packet | send a non-probing packet in response. If the non-probing packet | |||
arrives before any copy made by an attacker, this results in the | arrives before any copy made by an attacker, this results in the | |||
connection being migrated back to the original path. Any subsequent | connection being migrated back to the original path. Any subsequent | |||
migration to another path restarts this entire process. | migration to another path restarts this entire process. | |||
This defense is imperfect, but this is not considered a serious | This defense is imperfect, but this is not considered a serious | |||
problem. If the path via the attack is reliably faster than the | problem. If the path via the attack is reliably faster than the | |||
original path despite multiple attempts to use that original path, it | original path despite multiple attempts to use that original path, it | |||
is not possible to distinguish between attack and an improvement in | is not possible to distinguish between an attack and an improvement | |||
routing. | in routing. | |||
An endpoint could also use heuristics to improve detection of this | An endpoint could also use heuristics to improve detection of this | |||
style of attack. For instance, NAT rebinding is improbable if | style of attack. For instance, NAT rebinding is improbable if | |||
packets were recently received on the old path; similarly, rebinding | packets were recently received on the old path; similarly, rebinding | |||
is rare on IPv6 paths. Endpoints can also look for duplicated | is rare on IPv6 paths. Endpoints can also look for duplicated | |||
packets. Conversely, a change in connection ID is more likely to | packets. Conversely, a change in connection ID is more likely to | |||
indicate an intentional migration rather than an attack. | indicate an intentional migration rather than an attack. | |||
9.4. Loss Detection and Congestion Control | 9.4. Loss Detection and Congestion Control | |||
The capacity available on the new path might not be the same as the | The capacity available on the new path might not be the same as the | |||
old path. Packets sent on the old path MUST NOT contribute to | old path. Packets sent on the old path MUST NOT contribute to | |||
congestion control or RTT estimation for the new path. | congestion control or RTT estimation for the new path. | |||
On confirming a peer's ownership of its new address, an endpoint MUST | On confirming a peer's ownership of its new address, an endpoint MUST | |||
immediately reset the congestion controller and round-trip time | immediately reset the congestion controller and round-trip time | |||
estimator for the new path to initial values (see Appendices A.3 and | estimator for the new path to initial values (see Appendices A.3 and | |||
B.3 in [QUIC-RECOVERY]) unless the only change in the peer's address | B.3 of [QUIC-RECOVERY]) unless the only change in the peer's address | |||
is its port number. Because port-only changes are commonly the | is its port number. Because port-only changes are commonly the | |||
result of NAT rebinding or other middlebox activity, the endpoint MAY | result of NAT rebinding or other middlebox activity, the endpoint MAY | |||
instead retain its congestion control state and round-trip estimate | instead retain its congestion control state and round-trip estimate | |||
in those cases instead of reverting to initial values. In cases | in those cases instead of reverting to initial values. In cases | |||
where congestion control state retained from an old path is used on a | where congestion control state retained from an old path is used on a | |||
new path with substantially different characteristics, a sender could | new path with substantially different characteristics, a sender could | |||
transmit too aggressively until the congestion controller and the RTT | transmit too aggressively until the congestion controller and the RTT | |||
estimator have adapted. Generally, implementations are advised to be | estimator have adapted. Generally, implementations are advised to be | |||
cautious when using previous values on a new path. | cautious when using previous values on a new path. | |||
skipping to change at page 63, line 16 ¶ | skipping to change at page 62, line 19 ¶ | |||
sends data and probes from/to multiple addresses during the migration | sends data and probes from/to multiple addresses during the migration | |||
period, since the two resulting paths could have different round-trip | period, since the two resulting paths could have different round-trip | |||
times. A receiver of packets on multiple paths will still send ACK | times. A receiver of packets on multiple paths will still send ACK | |||
frames covering all received packets. | frames covering all received packets. | |||
While multiple paths might be used during connection migration, a | While multiple paths might be used during connection migration, a | |||
single congestion control context and a single loss recovery context | single congestion control context and a single loss recovery context | |||
(as described in [QUIC-RECOVERY]) could be adequate. For instance, | (as described in [QUIC-RECOVERY]) could be adequate. For instance, | |||
an endpoint might delay switching to a new congestion control context | an endpoint might delay switching to a new congestion control context | |||
until it is confirmed that an old path is no longer needed (such as | until it is confirmed that an old path is no longer needed (such as | |||
the case in Section 9.3.3). | the case described in Section 9.3.3). | |||
A sender can make exceptions for probe packets so that their loss | A sender can make exceptions for probe packets so that their loss | |||
detection is independent and does not unduly cause the congestion | detection is independent and does not unduly cause the congestion | |||
controller to reduce its sending rate. An endpoint might set a | controller to reduce its sending rate. An endpoint might set a | |||
separate timer when a PATH_CHALLENGE is sent, which is cancelled if | separate timer when a PATH_CHALLENGE is sent, which is canceled if | |||
the corresponding PATH_RESPONSE is received. If the timer fires | the corresponding PATH_RESPONSE is received. If the timer fires | |||
before the PATH_RESPONSE is received, the endpoint might send a new | before the PATH_RESPONSE is received, the endpoint might send a new | |||
PATH_CHALLENGE, and restart the timer for a longer period of time. | PATH_CHALLENGE and restart the timer for a longer period of time. | |||
This timer SHOULD be set as described in Section 6.2.1 of | This timer SHOULD be set as described in Section 6.2.1 of | |||
[QUIC-RECOVERY] and MUST NOT be more aggressive. | [QUIC-RECOVERY] and MUST NOT be more aggressive. | |||
9.5. Privacy Implications of Connection Migration | 9.5. Privacy Implications of Connection Migration | |||
Using a stable connection ID on multiple network paths would allow a | Using a stable connection ID on multiple network paths would allow a | |||
passive observer to correlate activity between those paths. An | passive observer to correlate activity between those paths. An | |||
endpoint that moves between networks might not wish to have their | endpoint that moves between networks might not wish to have their | |||
activity correlated by any entity other than their peer, so different | activity correlated by any entity other than their peer, so different | |||
connection IDs are used when sending from different local addresses, | connection IDs are used when sending from different local addresses, | |||
as discussed in Section 5.1. For this to be effective, endpoints | as discussed in Section 5.1. For this to be effective, endpoints | |||
need to ensure that connection IDs they provide cannot be linked by | need to ensure that connection IDs they provide cannot be linked by | |||
any other entity. | any other entity. | |||
At any time, endpoints MAY change the Destination Connection ID they | At any time, endpoints MAY change the Destination Connection ID they | |||
transmit with to a value that has not been used on another path. | transmit with to a value that has not been used on another path. | |||
An endpoint MUST NOT reuse a connection ID when sending from more | An endpoint MUST NOT reuse a connection ID when sending from more | |||
than one local address, for example when initiating connection | than one local address -- for example, when initiating connection | |||
migration as described in Section 9.2 or when probing a new network | migration as described in Section 9.2 or when probing a new network | |||
path as described in Section 9.1. | path as described in Section 9.1. | |||
Similarly, an endpoint MUST NOT reuse a connection ID when sending to | Similarly, an endpoint MUST NOT reuse a connection ID when sending to | |||
more than one destination address. Due to network changes outside | more than one destination address. Due to network changes outside | |||
the control of its peer, an endpoint might receive packets from a new | the control of its peer, an endpoint might receive packets from a new | |||
source address with the same destination connection ID, in which case | source address with the same Destination Connection ID field value, | |||
it MAY continue to use the current connection ID with the new remote | in which case it MAY continue to use the current connection ID with | |||
address while still sending from the same local address. | the new remote address while still sending from the same local | |||
address. | ||||
These requirements regarding connection ID reuse apply only to the | These requirements regarding connection ID reuse apply only to the | |||
sending of packets, as unintentional changes in path without a change | sending of packets, as unintentional changes in path without a change | |||
in connection ID are possible. For example, after a period of | in connection ID are possible. For example, after a period of | |||
network inactivity, NAT rebinding might cause packets to be sent on a | network inactivity, NAT rebinding might cause packets to be sent on a | |||
new path when the client resumes sending. An endpoint responds to | new path when the client resumes sending. An endpoint responds to | |||
such an event as described in Section 9.3. | such an event as described in Section 9.3. | |||
Using different connection IDs for packets sent in both directions on | Using different connection IDs for packets sent in both directions on | |||
each new network path eliminates the use of the connection ID for | each new network path eliminates the use of the connection ID for | |||
skipping to change at page 64, line 26 ¶ | skipping to change at page 63, line 31 ¶ | |||
to correlate activity. This does not prevent other properties of | to correlate activity. This does not prevent other properties of | |||
packets, such as timing and size, from being used to correlate | packets, such as timing and size, from being used to correlate | |||
activity. | activity. | |||
An endpoint SHOULD NOT initiate migration with a peer that has | An endpoint SHOULD NOT initiate migration with a peer that has | |||
requested a zero-length connection ID, because traffic over the new | requested a zero-length connection ID, because traffic over the new | |||
path might be trivially linkable to traffic over the old one. If the | path might be trivially linkable to traffic over the old one. If the | |||
server is able to associate packets with a zero-length connection ID | server is able to associate packets with a zero-length connection ID | |||
to the right connection, it means that the server is using other | to the right connection, it means that the server is using other | |||
information to demultiplex packets. For example, a server might | information to demultiplex packets. For example, a server might | |||
provide a unique address to every client, for instance using HTTP | provide a unique address to every client -- for instance, using HTTP | |||
alternative services [ALTSVC]. Information that might allow correct | alternative services [ALTSVC]. Information that might allow correct | |||
routing of packets across multiple network paths will also allow | routing of packets across multiple network paths will also allow | |||
activity on those paths to be linked by entities other than the peer. | activity on those paths to be linked by entities other than the peer. | |||
A client might wish to reduce linkability by switching to a new | A client might wish to reduce linkability by switching to a new | |||
connection ID, source UDP port, or IP address (see [RFC4941]) when | connection ID, source UDP port, or IP address (see [RFC8981]) when | |||
sending traffic after a period of inactivity. Changing the address | sending traffic after a period of inactivity. Changing the address | |||
from which it sends packets at the same time might cause the server | from which it sends packets at the same time might cause the server | |||
to detect a connection migration. This ensures that the mechanisms | to detect a connection migration. This ensures that the mechanisms | |||
that support migration are exercised even for clients that do not | that support migration are exercised even for clients that do not | |||
experience NAT rebindings or genuine migrations. Changing address | experience NAT rebindings or genuine migrations. Changing address | |||
can cause a peer to reset its congestion control state (see | can cause a peer to reset its congestion control state (see | |||
Section 9.4), so addresses SHOULD only be changed infrequently. | Section 9.4), so addresses SHOULD only be changed infrequently. | |||
An endpoint that exhausts available connection IDs cannot probe new | An endpoint that exhausts available connection IDs cannot probe new | |||
paths or initiate migration, nor can it respond to probes or attempts | paths or initiate migration, nor can it respond to probes or attempts | |||
skipping to change at page 66, line 41 ¶ | skipping to change at page 65, line 43 ¶ | |||
If path validation of the server's preferred address succeeds, the | If path validation of the server's preferred address succeeds, the | |||
client MUST abandon validation of the original address and migrate to | client MUST abandon validation of the original address and migrate to | |||
using the server's preferred address. If path validation of the | using the server's preferred address. If path validation of the | |||
server's preferred address fails but validation of the server's | server's preferred address fails but validation of the server's | |||
original address succeeds, the client MAY migrate to its new address | original address succeeds, the client MAY migrate to its new address | |||
and continue sending to the server's original address. | and continue sending to the server's original address. | |||
If packets received at the server's preferred address have a | If packets received at the server's preferred address have a | |||
different source address than observed from the client during the | different source address than observed from the client during the | |||
handshake, the server MUST protect against potential attacks as | handshake, the server MUST protect against potential attacks as | |||
described in Section 9.3.1 and Section 9.3.2. In addition to | described in Sections 9.3.1 and 9.3.2. In addition to intentional | |||
intentional simultaneous migration, this might also occur because the | simultaneous migration, this might also occur because the client's | |||
client's access network used a different NAT binding for the server's | access network used a different NAT binding for the server's | |||
preferred address. | preferred address. | |||
Servers SHOULD initiate path validation to the client's new address | Servers SHOULD initiate path validation to the client's new address | |||
upon receiving a probe packet from a different address; see | upon receiving a probe packet from a different address; see | |||
Section 8. | Section 8. | |||
A client that migrates to a new address SHOULD use a preferred | A client that migrates to a new address SHOULD use a preferred | |||
address from the same address family for the server. | address from the same address family for the server. | |||
The connection ID provided in the preferred_address transport | The connection ID provided in the preferred_address transport | |||
parameter is not specific to the addresses that are provided. This | parameter is not specific to the addresses that are provided. This | |||
connection ID is provided to ensure that the client has a connection | connection ID is provided to ensure that the client has a connection | |||
ID available for migration, but the client MAY use this connection ID | ID available for migration, but the client MAY use this connection ID | |||
on any path. | on any path. | |||
9.7. Use of IPv6 Flow-Label and Migration | 9.7. Use of IPv6 Flow Label and Migration | |||
Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label | Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label | |||
in compliance with [RFC6437], unless the local API does not allow | in compliance with [RFC6437], unless the local API does not allow | |||
setting IPv6 flow labels. | setting IPv6 flow labels. | |||
The flow label generation MUST be designed to minimize the chances of | The flow label generation MUST be designed to minimize the chances of | |||
linkability with a previously used flow label, as a stable flow label | linkability with a previously used flow label, as a stable flow label | |||
would enable correlating activity on multiple paths; see Section 9.5. | would enable correlating activity on multiple paths; see Section 9.5. | |||
[RFC6437] suggests deriving values using a pseudorandom function to | [RFC6437] suggests deriving values using a pseudorandom function to | |||
skipping to change at page 67, line 45 ¶ | skipping to change at page 66, line 48 ¶ | |||
o immediate close (Section 10.2) | o immediate close (Section 10.2) | |||
o stateless reset (Section 10.3) | o stateless reset (Section 10.3) | |||
An endpoint MAY discard connection state if it does not have a | An endpoint MAY discard connection state if it does not have a | |||
validated path on which it can send packets; see Section 8.2. | validated path on which it can send packets; see Section 8.2. | |||
10.1. Idle Timeout | 10.1. Idle Timeout | |||
If a max_idle_timeout is specified by either peer in its transport | If a max_idle_timeout is specified by either endpoint in its | |||
parameters (Section 18.2), the connection is silently closed and its | transport parameters (Section 18.2), the connection is silently | |||
state is discarded when it remains idle for longer than the minimum | closed and its state is discarded when it remains idle for longer | |||
of both peers max_idle_timeout values. | than the minimum of the max_idle_timeout value advertised by both | |||
endpoints. | ||||
Each endpoint advertises a max_idle_timeout, but the effective value | Each endpoint advertises a max_idle_timeout, but the effective value | |||
at an endpoint is computed as the minimum of the two advertised | at an endpoint is computed as the minimum of the two advertised | |||
values (or the sole advertised value, if only one endpoint advertises | values (or the sole advertised value, if only one endpoint advertises | |||
a nonzero value). By announcing a max_idle_timeout, an endpoint | a non-zero value). By announcing a max_idle_timeout, an endpoint | |||
commits to initiating an immediate close (Section 10.2) if it | commits to initiating an immediate close (Section 10.2) if it | |||
abandons the connection prior to the effective value. | abandons the connection prior to the effective value. | |||
An endpoint restarts its idle timer when a packet from its peer is | An endpoint restarts its idle timer when a packet from its peer is | |||
received and processed successfully. An endpoint also restarts its | received and processed successfully. An endpoint also restarts its | |||
idle timer when sending an ack-eliciting packet if no other ack- | idle timer when sending an ack-eliciting packet if no other ack- | |||
eliciting packets have been sent since last receiving and processing | eliciting packets have been sent since last receiving and processing | |||
a packet. Restarting this timer when sending a packet ensures that | a packet. Restarting this timer when sending a packet ensures that | |||
connections are not closed after new activity is initiated. | connections are not closed after new activity is initiated. | |||
skipping to change at page 68, line 36 ¶ | skipping to change at page 67, line 40 ¶ | |||
An endpoint can send a PING or another ack-eliciting frame to test | An endpoint can send a PING or another ack-eliciting frame to test | |||
the connection for liveness if the peer could time out soon, such as | the connection for liveness if the peer could time out soon, such as | |||
within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially | within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially | |||
useful if any available application data cannot be safely retried. | useful if any available application data cannot be safely retried. | |||
Note that the application determines what data is safe to retry. | Note that the application determines what data is safe to retry. | |||
10.1.2. Deferring Idle Timeout | 10.1.2. Deferring Idle Timeout | |||
An endpoint might need to send ack-eliciting packets to avoid an idle | An endpoint might need to send ack-eliciting packets to avoid an idle | |||
timeout if it is expecting response data, but does not have or is | timeout if it is expecting response data but does not have or is | |||
unable to send application data. | unable to send application data. | |||
An implementation of QUIC might provide applications with an option | An implementation of QUIC might provide applications with an option | |||
to defer an idle timeout. This facility could be used when the | to defer an idle timeout. This facility could be used when the | |||
application wishes to avoid losing state that has been associated | application wishes to avoid losing state that has been associated | |||
with an open connection, but does not expect to exchange application | with an open connection but does not expect to exchange application | |||
data for some time. With this option, an endpoint could send a PING | data for some time. With this option, an endpoint could send a PING | |||
frame (Section 19.2) periodically, which will cause the peer to | frame (Section 19.2) periodically, which will cause the peer to | |||
restart its idle timeout period. Sending a packet containing a PING | restart its idle timeout period. Sending a packet containing a PING | |||
frame restarts the idle timeout for this endpoint also if this is the | frame restarts the idle timeout for this endpoint also if this is the | |||
first ack-eliciting packet sent since receiving a packet. Sending a | first ack-eliciting packet sent since receiving a packet. Sending a | |||
PING frame causes the peer to respond with an acknowledgment, which | PING frame causes the peer to respond with an acknowledgment, which | |||
also restarts the idle timeout for the endpoint. | also restarts the idle timeout for the endpoint. | |||
Application protocols that use QUIC SHOULD provide guidance on when | Application protocols that use QUIC SHOULD provide guidance on when | |||
deferring an idle timeout is appropriate. Unnecessary sending of | deferring an idle timeout is appropriate. Unnecessary sending of | |||
PING frames could have a detrimental effect on performance. | PING frames could have a detrimental effect on performance. | |||
A connection will time out if no packets are sent or received for a | A connection will time out if no packets are sent or received for a | |||
period longer than the time negotiated using the max_idle_timeout | period longer than the time negotiated using the max_idle_timeout | |||
transport parameter; see Section 10. However, state in middleboxes | transport parameter; see Section 10. However, state in middleboxes | |||
might time out earlier than that. Though REQ-5 in [RFC4787] | might time out earlier than that. Though REQ-5 in [RFC4787] | |||
recommends a 2 minute timeout interval, experience shows that sending | recommends a 2-minute timeout interval, experience shows that sending | |||
packets every 30 seconds is necessary to prevent the majority of | packets every 30 seconds is necessary to prevent the majority of | |||
middleboxes from losing state for UDP flows [GATEWAY]. | middleboxes from losing state for UDP flows [GATEWAY]. | |||
10.2. Immediate Close | 10.2. Immediate Close | |||
An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to | An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to | |||
terminate the connection immediately. A CONNECTION_CLOSE frame | terminate the connection immediately. A CONNECTION_CLOSE frame | |||
causes all streams to immediately become closed; open streams can be | causes all streams to immediately become closed; open streams can be | |||
assumed to be implicitly reset. | assumed to be implicitly reset. | |||
skipping to change at page 69, line 44 ¶ | skipping to change at page 68, line 46 ¶ | |||
can exchange messages that are needed for both application endpoints | can exchange messages that are needed for both application endpoints | |||
to agree that the connection can be closed, after which the | to agree that the connection can be closed, after which the | |||
application requests that QUIC close the connection. When QUIC | application requests that QUIC close the connection. When QUIC | |||
consequently closes the connection, a CONNECTION_CLOSE frame with an | consequently closes the connection, a CONNECTION_CLOSE frame with an | |||
application-supplied error code will be used to signal closure to the | application-supplied error code will be used to signal closure to the | |||
peer. | peer. | |||
The closing and draining connection states exist to ensure that | The closing and draining connection states exist to ensure that | |||
connections close cleanly and that delayed or reordered packets are | connections close cleanly and that delayed or reordered packets are | |||
properly discarded. These states SHOULD persist for at least three | properly discarded. These states SHOULD persist for at least three | |||
times the current Probe Timeout (PTO) interval as defined in | times the current PTO interval as defined in [QUIC-RECOVERY]. | |||
[QUIC-RECOVERY]. | ||||
Disposing of connection state prior to exiting the closing or | Disposing of connection state prior to exiting the closing or | |||
draining state could result in an endpoint generating a stateless | draining state could result in an endpoint generating a Stateless | |||
reset unnecessarily when it receives a late-arriving packet. | Reset unnecessarily when it receives a late-arriving packet. | |||
Endpoints that have some alternative means to ensure that late- | Endpoints that have some alternative means to ensure that late- | |||
arriving packets do not induce a response, such as those that are | arriving packets do not induce a response, such as those that are | |||
able to close the UDP socket, MAY end these states earlier to allow | able to close the UDP socket, MAY end these states earlier to allow | |||
for faster resource recovery. Servers that retain an open socket for | for faster resource recovery. Servers that retain an open socket for | |||
accepting new connections SHOULD NOT end the closing or draining | accepting new connections SHOULD NOT end the closing or draining | |||
states early. | state early. | |||
Once its closing or draining state ends, an endpoint SHOULD discard | Once its closing or draining state ends, an endpoint SHOULD discard | |||
all connection state. The endpoint MAY send a stateless reset in | all connection state. The endpoint MAY send a Stateless Reset in | |||
response to any further incoming packets belonging to this | response to any further incoming packets belonging to this | |||
connection. | connection. | |||
10.2.1. Closing Connection State | 10.2.1. Closing Connection State | |||
An endpoint enters the closing state after initiating an immediate | An endpoint enters the closing state after initiating an immediate | |||
close. | close. | |||
In the closing state, an endpoint retains only enough information to | In the closing state, an endpoint retains only enough information to | |||
generate a packet containing a CONNECTION_CLOSE frame and to identify | generate a packet containing a CONNECTION_CLOSE frame and to identify | |||
skipping to change at page 70, line 47 ¶ | skipping to change at page 69, line 49 ¶ | |||
state and send a packet containing a CONNECTION_CLOSE frame in | state and send a packet containing a CONNECTION_CLOSE frame in | |||
response to any UDP datagram that is received. However, an endpoint | response to any UDP datagram that is received. However, an endpoint | |||
that discards packet protection keys cannot identify and discard | that discards packet protection keys cannot identify and discard | |||
invalid packets. To avoid being used for an amplification attack, | invalid packets. To avoid being used for an amplification attack, | |||
such endpoints MUST limit the cumulative size of packets it sends to | such endpoints MUST limit the cumulative size of packets it sends to | |||
three times the cumulative size of the packets that are received and | three times the cumulative size of the packets that are received and | |||
attributed to the connection. To minimize the state that an endpoint | attributed to the connection. To minimize the state that an endpoint | |||
maintains for a closing connection, endpoints MAY send the exact same | maintains for a closing connection, endpoints MAY send the exact same | |||
packet in response to any received packet. | packet in response to any received packet. | |||
Note: Allowing retransmission of a closing packet is an exception to | Note: Allowing retransmission of a closing packet is an exception | |||
the requirement that a new packet number be used for each packet | to the requirement that a new packet number be used for each | |||
in Section 12.3. Sending new packet numbers is primarily of | packet; see Section 12.3. Sending new packet numbers is primarily | |||
advantage to loss recovery and congestion control, which are not | of advantage to loss recovery and congestion control, which are | |||
expected to be relevant for a closed connection. Retransmitting | not expected to be relevant for a closed connection. | |||
the final packet requires less state. | Retransmitting the final packet requires less state. | |||
While in the closing state, an endpoint could receive packets from a | While in the closing state, an endpoint could receive packets from a | |||
new source address, possibly indicating a connection migration; see | new source address, possibly indicating a connection migration; see | |||
Section 9. An endpoint in the closing state MUST either discard | Section 9. An endpoint in the closing state MUST either discard | |||
packets received from an unvalidated address or limit the cumulative | packets received from an unvalidated address or limit the cumulative | |||
size of packets it sends to an unvalidated address to three times the | size of packets it sends to an unvalidated address to three times the | |||
size of packets it receives from that address. | size of packets it receives from that address. | |||
An endpoint is not expected to handle key updates when it is closing | An endpoint is not expected to handle key updates when it is closing | |||
(Section 6 of [QUIC-TLS]). A key update might prevent the endpoint | (Section 6 of [QUIC-TLS]). A key update might prevent the endpoint | |||
skipping to change at page 71, line 40 ¶ | skipping to change at page 70, line 41 ¶ | |||
packet containing a CONNECTION_CLOSE frame before entering the | packet containing a CONNECTION_CLOSE frame before entering the | |||
draining state, using a NO_ERROR code if appropriate. An endpoint | draining state, using a NO_ERROR code if appropriate. An endpoint | |||
MUST NOT send further packets. Doing so could result in a constant | MUST NOT send further packets. Doing so could result in a constant | |||
exchange of CONNECTION_CLOSE frames until one of the endpoints exits | exchange of CONNECTION_CLOSE frames until one of the endpoints exits | |||
the closing state. | the closing state. | |||
An endpoint MAY enter the draining state from the closing state if it | An endpoint MAY enter the draining state from the closing state if it | |||
receives a CONNECTION_CLOSE frame, which indicates that the peer is | receives a CONNECTION_CLOSE frame, which indicates that the peer is | |||
also closing or draining. In this case, the draining state ends when | also closing or draining. In this case, the draining state ends when | |||
the closing state would have ended. In other words, the endpoint | the closing state would have ended. In other words, the endpoint | |||
uses the same end time, but ceases transmission of any packets on | uses the same end time but ceases transmission of any packets on this | |||
this connection. | connection. | |||
10.2.3. Immediate Close During the Handshake | 10.2.3. Immediate Close during the Handshake | |||
When sending CONNECTION_CLOSE, the goal is to ensure that the peer | When sending a CONNECTION_CLOSE frame, the goal is to ensure that the | |||
will process the frame. Generally, this means sending the frame in a | peer will process the frame. Generally, this means sending the frame | |||
packet with the highest level of packet protection to avoid the | in a packet with the highest level of packet protection to avoid the | |||
packet being discarded. After the handshake is confirmed (see | packet being discarded. After the handshake is confirmed (see | |||
Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any | Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any | |||
CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to | CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to | |||
confirming the handshake, it is possible that more advanced packet | confirming the handshake, it is possible that more advanced packet | |||
protection keys are not available to the peer, so another | protection keys are not available to the peer, so another | |||
CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower | CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower | |||
packet protection level. More specifically: | packet protection level. More specifically: | |||
o A client will always know whether the server has Handshake keys | o A client will always know whether the server has Handshake keys | |||
(see Section 17.2.2.1), but it is possible that a server does not | (see Section 17.2.2.1), but it is possible that a server does not | |||
know whether the client has Handshake keys. Under these | know whether the client has Handshake keys. Under these | |||
circumstances, a server SHOULD send a CONNECTION_CLOSE frame in | circumstances, a server SHOULD send a CONNECTION_CLOSE frame in | |||
both Handshake and Initial packets to ensure that at least one of | both Handshake and Initial packets to ensure that at least one of | |||
them is processable by the client. | them is processable by the client. | |||
o A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be | o A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet | |||
assured that the server has accepted 0-RTT. Sending a | cannot be assured that the server has accepted 0-RTT. Sending a | |||
CONNECTION_CLOSE frame in an Initial packet makes it more likely | CONNECTION_CLOSE frame in an Initial packet makes it more likely | |||
that the server can receive the close signal, even if the | that the server can receive the close signal, even if the | |||
application error code might not be received. | application error code might not be received. | |||
o Prior to confirming the handshake, a peer might be unable to | o Prior to confirming the handshake, a peer might be unable to | |||
process 1-RTT packets, so an endpoint SHOULD send CONNECTION_CLOSE | process 1-RTT packets, so an endpoint SHOULD send a | |||
in both Handshake and 1-RTT packets. A server SHOULD also send | CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. A | |||
CONNECTION_CLOSE in an Initial packet. | server SHOULD also send a CONNECTION_CLOSE frame in an Initial | |||
packet. | ||||
Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake | Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake | |||
packet could expose application state or be used to alter application | packet could expose application state or be used to alter application | |||
state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a | state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a | |||
CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or | CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or | |||
Handshake packets. Otherwise, information about the application | Handshake packets. Otherwise, information about the application | |||
state might be revealed. Endpoints MUST clear the value of the | state might be revealed. Endpoints MUST clear the value of the | |||
Reason Phrase field and SHOULD use the APPLICATION_ERROR code when | Reason Phrase field and SHOULD use the APPLICATION_ERROR code when | |||
converting to a CONNECTION_CLOSE of type 0x1c. | converting to a CONNECTION_CLOSE of type 0x1c. | |||
skipping to change at page 73, line 14 ¶ | skipping to change at page 72, line 17 ¶ | |||
state. An endpoint that has no state for the connection does not | state. An endpoint that has no state for the connection does not | |||
enter a closing or draining period on sending a CONNECTION_CLOSE | enter a closing or draining period on sending a CONNECTION_CLOSE | |||
frame. | frame. | |||
10.3. Stateless Reset | 10.3. Stateless Reset | |||
A stateless reset is provided as an option of last resort for an | 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 | 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 | crash or outage might result in peers continuing to send data to an | |||
endpoint that is unable to properly continue the connection. An | endpoint that is unable to properly continue the connection. An | |||
endpoint MAY send a stateless reset in response to receiving a packet | endpoint MAY send a Stateless Reset in response to receiving a packet | |||
that it cannot associate with an active connection. | that it cannot associate with an active connection. | |||
A stateless reset is not appropriate for indicating errors in active | A stateless reset is not appropriate for indicating errors in active | |||
connections. An endpoint that wishes to communicate a fatal | connections. An endpoint that wishes to communicate a fatal | |||
connection error MUST use a CONNECTION_CLOSE frame if it is able. | connection error MUST use a CONNECTION_CLOSE frame if it is able. | |||
To support this process, an endpoint issues a stateless reset token, | To support this process, an endpoint issues a stateless reset token, | |||
which is a 16-byte value that is hard to guess. If the peer | which is a 16-byte value that is hard to guess. If the peer | |||
subsequently receives a stateless reset, which is a UDP datagram that | subsequently receives a Stateless Reset, which is a UDP datagram that | |||
ends in that stateless reset token, the peer will immediately end the | ends in that stateless reset token, the peer will immediately end the | |||
connection. | connection. | |||
A stateless reset token is specific to a connection ID. An endpoint | A stateless reset token is specific to a connection ID. An endpoint | |||
issues a stateless reset token by including the value in the | issues a stateless reset token by including the value in the | |||
Stateless Reset Token field of a NEW_CONNECTION_ID frame. Servers | Stateless Reset Token field of a NEW_CONNECTION_ID frame. Servers | |||
can also issue a stateless_reset_token transport parameter during the | can also issue a stateless_reset_token transport parameter during the | |||
handshake that applies to the connection ID that it selected during | handshake that applies to the connection ID that it selected during | |||
the handshake. These exchanges are protected by encryption, so only | the handshake. These exchanges are protected by encryption, so only | |||
client and server know their value. Note that clients cannot use the | client and server know their value. Note that clients cannot use the | |||
skipping to change at page 73, line 49 ¶ | skipping to change at page 72, line 52 ¶ | |||
An endpoint that receives packets that it cannot process sends a | An endpoint that receives packets that it cannot process sends a | |||
packet in the following layout (see Section 1.3): | packet in the following layout (see Section 1.3): | |||
Stateless Reset { | Stateless Reset { | |||
Fixed Bits (2) = 1, | Fixed Bits (2) = 1, | |||
Unpredictable Bits (38..), | Unpredictable Bits (38..), | |||
Stateless Reset Token (128), | Stateless Reset Token (128), | |||
} | } | |||
Figure 10: Stateless Reset Packet | Figure 10: Stateless Reset | |||
This design ensures that a stateless reset packet is - to the extent | This design ensures that a Stateless Reset is -- to the extent | |||
possible - indistinguishable from a regular packet with a short | possible -- indistinguishable from a regular packet with a short | |||
header. | header. | |||
A stateless reset uses an entire UDP datagram, starting with the | A Stateless Reset uses an entire UDP datagram, starting with the | |||
first two bits of the packet header. The remainder of the first byte | first two bits of the packet header. The remainder of the first byte | |||
and an arbitrary number of bytes following it are set to values that | and an arbitrary number of bytes following it are set to values that | |||
SHOULD be indistinguishable from random. The last 16 bytes of the | SHOULD be indistinguishable from random. The last 16 bytes of the | |||
datagram contain a Stateless Reset Token. | datagram contain a stateless reset token. | |||
To entities other than its intended recipient, a stateless reset will | To entities other than its intended recipient, a Stateless Reset will | |||
appear to be a packet with a short header. For the stateless reset | appear to be a packet with a short header. For the Stateless Reset | |||
to appear as a valid QUIC packet, the Unpredictable Bits field needs | to appear as a valid QUIC packet, the Unpredictable Bits field needs | |||
to include at least 38 bits of data (or 5 bytes, less the two fixed | to include at least 38 bits of data (or 5 bytes, less the two fixed | |||
bits). | bits). | |||
The resulting minimum size of 21 bytes does not guarantee that a | The resulting minimum size of 21 bytes does not guarantee that a | |||
stateless reset is difficult to distinguish from other packets if the | Stateless Reset is difficult to distinguish from other packets if the | |||
recipient requires the use of a connection ID. To achieve that end, | recipient requires the use of a connection ID. To achieve that end, | |||
the endpoint SHOULD ensure that all packets it sends are at least 22 | the endpoint SHOULD ensure that all packets it sends are at least 22 | |||
bytes longer than the minimum connection ID length that it requests | bytes longer than the minimum connection ID length that it requests | |||
the peer to include in its packets, adding PADDING frames as | the peer to include in its packets, adding PADDING frames as | |||
necessary. This ensures that any stateless reset sent by the peer is | necessary. This ensures that any Stateless Reset sent by the peer is | |||
indistinguishable from a valid packet sent to the endpoint. An | indistinguishable from a valid packet sent to the endpoint. An | |||
endpoint that sends a stateless reset in response to a packet that is | endpoint that sends a Stateless Reset in response to a packet that is | |||
43 bytes or shorter SHOULD send a stateless reset that is one byte | 43 bytes or shorter SHOULD send a Stateless Reset that is one byte | |||
shorter than the packet it responds to. | shorter than the packet it responds to. | |||
These values assume that the Stateless Reset Token is the same length | These values assume that the stateless reset token is the same length | |||
as the minimum expansion of the packet protection AEAD. Additional | as the minimum expansion of the packet protection AEAD. Additional | |||
unpredictable bytes are necessary if the endpoint could have | unpredictable bytes are necessary if the endpoint could have | |||
negotiated a packet protection scheme with a larger minimum | negotiated a packet protection scheme with a larger minimum | |||
expansion. | expansion. | |||
An endpoint MUST NOT send a stateless reset that is three times or | An endpoint MUST NOT send a Stateless Reset that is three times or | |||
more larger than the packet it receives to avoid being used for | more larger than the packet it receives to avoid being used for | |||
amplification. Section 10.3.3 describes additional limits on | amplification. Section 10.3.3 describes additional limits on | |||
stateless reset size. | Stateless Reset size. | |||
Endpoints MUST discard packets that are too small to be valid QUIC | Endpoints MUST discard packets that are too small to be valid QUIC | |||
packets. To give an example, with the set of AEAD functions defined | packets. To give an example, with the set of AEAD functions defined | |||
in [QUIC-TLS], short header packets that are smaller than 21 bytes | in [QUIC-TLS], short header packets that are smaller than 21 bytes | |||
are never valid. | are never valid. | |||
Endpoints MUST send stateless reset packets formatted as a packet | Endpoints MUST send Stateless Resets formatted as a packet with a | |||
with a short header. However, endpoints MUST treat any packet ending | short header. However, endpoints MUST treat any packet ending in a | |||
in a valid stateless reset token as a stateless reset, as other QUIC | valid stateless reset token as a Stateless Reset, as other QUIC | |||
versions might allow the use of a long header. | versions might allow the use of a long header. | |||
An endpoint MAY send a stateless reset in response to a packet with a | 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 | long header. Sending a Stateless Reset is not effective prior to the | |||
stateless reset token being available to a peer. In this QUIC | stateless reset token being available to a peer. In this QUIC | |||
version, packets with a long header are only used during connection | version, packets with a long header are only used during connection | |||
establishment. Because the stateless reset token is not available | establishment. Because the stateless reset token is not available | |||
until connection establishment is complete or near completion, | until connection establishment is complete or near completion, | |||
ignoring an unknown packet with a long header might be as effective | ignoring an unknown packet with a long header might be as effective | |||
as sending a stateless reset. | as sending a Stateless Reset. | |||
An endpoint cannot determine the Source Connection ID from a packet | An endpoint cannot determine the Source Connection ID from a packet | |||
with a short header, therefore it cannot set the Destination | with a short header; therefore, it cannot set the Destination | |||
Connection ID in the stateless reset packet. The Destination | Connection ID in the Stateless Reset. The Destination Connection ID | |||
Connection ID will therefore differ from the value used in previous | will therefore differ from the value used in previous packets. A | |||
packets. A random Destination Connection ID makes the connection ID | random Destination Connection ID makes the connection ID appear to be | |||
appear to be the result of moving to a new connection ID that was | the result of moving to a new connection ID that was provided using a | |||
provided using a NEW_CONNECTION_ID frame (Section 19.15). | NEW_CONNECTION_ID frame; see Section 19.15. | |||
Using a randomized connection ID results in two problems: | Using a randomized connection ID results in two problems: | |||
o The packet might not reach the peer. If the Destination | o The packet might not reach the peer. If the Destination | |||
Connection ID is critical for routing toward the peer, then this | Connection ID is critical for routing toward the peer, then this | |||
packet could be incorrectly routed. This might also trigger | packet could be incorrectly routed. This might also trigger | |||
another Stateless Reset in response; see Section 10.3.3. A | another Stateless Reset in response; see Section 10.3.3. A | |||
Stateless Reset that is not correctly routed is an ineffective | Stateless Reset that is not correctly routed is an ineffective | |||
error detection and recovery mechanism. In this case, endpoints | error detection and recovery mechanism. In this case, endpoints | |||
will need to rely on other methods - such as timers - to detect | will need to rely on other methods -- such as timers -- to detect | |||
that the connection has failed. | that the connection has failed. | |||
o The randomly generated connection ID can be used by entities other | o The randomly generated connection ID can be used by entities other | |||
than the peer to identify this as a potential stateless reset. An | than the peer to identify this as a potential Stateless Reset. An | |||
endpoint that occasionally uses different connection IDs might | endpoint that occasionally uses different connection IDs might | |||
introduce some uncertainty about this. | introduce some uncertainty about this. | |||
This stateless reset design is specific to QUIC version 1. An | This stateless reset design is specific to QUIC version 1. An | |||
endpoint that supports multiple versions of QUIC needs to generate a | endpoint that supports multiple versions of QUIC needs to generate a | |||
stateless reset that will be accepted by peers that support any | Stateless Reset that will be accepted by peers that support any | |||
version that the endpoint might support (or might have supported | version that the endpoint might support (or might have supported | |||
prior to losing state). Designers of new versions of QUIC need to be | prior to losing state). Designers of new versions of QUIC need to be | |||
aware of this and either reuse this design, or use a portion of the | aware of this and either (1) reuse this design or (2) use a portion | |||
packet other than the last 16 bytes for carrying data. | of the packet other than the last 16 bytes for carrying data. | |||
10.3.1. Detecting a Stateless Reset | 10.3.1. Detecting a Stateless Reset | |||
An endpoint detects a potential stateless reset using the trailing 16 | An endpoint detects a potential Stateless Reset using the trailing 16 | |||
bytes of the UDP datagram. An endpoint remembers all Stateless Reset | bytes of the UDP datagram. An endpoint remembers all stateless reset | |||
Tokens associated with the connection IDs and remote addresses for | tokens associated with the connection IDs and remote addresses for | |||
datagrams it has recently sent. This includes Stateless Reset Tokens | datagrams it has recently sent. This includes Stateless Reset Token | |||
from NEW_CONNECTION_ID frames and the server's transport parameters | field values from NEW_CONNECTION_ID frames and the server's transport | |||
but excludes Stateless Reset Tokens associated with connection IDs | parameters but excludes stateless reset tokens associated with | |||
that are either unused or retired. The endpoint identifies a | connection IDs that are either unused or retired. The endpoint | |||
received datagram as a stateless reset by comparing the last 16 bytes | identifies a received datagram as a Stateless Reset by comparing the | |||
of the datagram with all Stateless Reset Tokens associated with the | last 16 bytes of the datagram with all stateless reset tokens | |||
remote address on which the datagram was received. | associated with the remote address on which the datagram was | |||
received. | ||||
This comparison can be performed for every inbound datagram. | This comparison can be performed for every inbound datagram. | |||
Endpoints MAY skip this check if any packet from a datagram is | Endpoints MAY skip this check if any packet from a datagram is | |||
successfully processed. However, the comparison MUST be performed | successfully processed. However, the comparison MUST be performed | |||
when the first packet in an incoming datagram either cannot be | when the first packet in an incoming datagram either cannot be | |||
associated with a connection, or cannot be decrypted. | associated with a connection or cannot be decrypted. | |||
An endpoint MUST NOT check for any Stateless Reset Tokens associated | An endpoint MUST NOT check for any stateless reset tokens associated | |||
with connection IDs it has not used or for connection IDs that have | with connection IDs it has not used or for connection IDs that have | |||
been retired. | been retired. | |||
When comparing a datagram to Stateless Reset Token values, endpoints | When comparing a datagram to stateless reset token values, endpoints | |||
MUST perform the comparison without leaking information about the | MUST perform the comparison without leaking information about the | |||
value of the token. For example, performing this comparison in | value of the token. For example, performing this comparison in | |||
constant time protects the value of individual Stateless Reset Tokens | constant time protects the value of individual stateless reset tokens | |||
from information leakage through timing side channels. Another | from information leakage through timing side channels. Another | |||
approach would be to store and compare the transformed values of | approach would be to store and compare the transformed values of | |||
Stateless Reset Tokens instead of the raw token values, where the | stateless reset tokens instead of the raw token values, where the | |||
transformation is defined as a cryptographically-secure pseudo-random | transformation is defined as a cryptographically secure pseudorandom | |||
function using a secret key (e.g., block cipher, HMAC [RFC2104]). An | function using a secret key (e.g., block cipher, Hashed Message | |||
endpoint is not expected to protect information about whether a | Authentication Code (HMAC) [RFC2104]). An endpoint is not expected | |||
packet was successfully decrypted, or the number of valid Stateless | to protect information about whether a packet was successfully | |||
Reset Tokens. | decrypted or the number of valid stateless reset tokens. | |||
If the last 16 bytes of the datagram are identical in value to a | If the last 16 bytes of the datagram are identical in value to a | |||
Stateless Reset Token, the endpoint MUST enter the draining period | stateless reset token, the endpoint MUST enter the draining period | |||
and not send any further packets on this connection. | and not send any further packets on this connection. | |||
10.3.2. Calculating a Stateless Reset Token | 10.3.2. Calculating a Stateless Reset Token | |||
The stateless reset token MUST be difficult to guess. In order to | The stateless reset token MUST be difficult to guess. In order to | |||
create a Stateless Reset Token, an endpoint could randomly generate | create a stateless reset token, an endpoint could randomly generate | |||
([RANDOM]) a secret for every connection that it creates. However, | [RANDOM] a secret for every connection that it creates. However, | |||
this presents a coordination problem when there are multiple | this presents a coordination problem when there are multiple | |||
instances in a cluster or a storage problem for an endpoint that | instances in a cluster or a storage problem for an endpoint that | |||
might lose state. Stateless reset specifically exists to handle the | might lose state. Stateless reset specifically exists to handle the | |||
case where state is lost, so this approach is suboptimal. | case where state is lost, so this approach is suboptimal. | |||
A single static key can be used across all connections to the same | A single static key can be used across all connections to the same | |||
endpoint by generating the proof using a pseudorandom function that | endpoint by generating the proof using a pseudorandom function that | |||
takes a static key and the connection ID chosen by the endpoint (see | takes a static key and the connection ID chosen by the endpoint (see | |||
Section 5.1) as input. An endpoint could use HMAC [RFC2104] (for | Section 5.1) as input. An endpoint could use HMAC [RFC2104] (for | |||
example, HMAC(static_key, connection_id)) or HKDF [RFC5869] (for | example, HMAC(static_key, connection_id)) or the HMAC-based Key | |||
example, using the static key as input keying material, with the | Derivation Function (HKDF) [RFC5869] (for example, using the static | |||
connection ID as salt). The output of this function is truncated to | key as input keying material, with the connection ID as salt). The | |||
16 bytes to produce the Stateless Reset Token for that connection. | output of this function is truncated to 16 bytes to produce the | |||
stateless reset token for that connection. | ||||
An endpoint that loses state can use the same method to generate a | An endpoint that loses state can use the same method to generate a | |||
valid Stateless Reset Token. The connection ID comes from the packet | valid stateless reset token. The connection ID comes from the packet | |||
that the endpoint receives. | that the endpoint receives. | |||
This design relies on the peer always sending a connection ID in its | 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 | packets so that the endpoint can use the connection ID from a packet | |||
to reset the connection. An endpoint that uses this design MUST | to reset the connection. An endpoint that uses this design MUST | |||
either use the same connection ID length for all connections or | either use the same connection ID length for all connections or | |||
encode the length of the connection ID such that it can be recovered | encode the length of the connection ID such that it can be recovered | |||
without state. In addition, it cannot provide a zero-length | without state. In addition, it cannot provide a zero-length | |||
connection ID. | connection ID. | |||
Revealing the Stateless Reset Token allows any entity to terminate | Revealing the stateless reset token allows any entity to terminate | |||
the connection, so a value can only be used once. This method for | the connection, so a value can only be used once. This method for | |||
choosing the Stateless Reset Token means that the combination of | choosing the stateless reset token means that the combination of | |||
connection ID and static key MUST NOT be used for another connection. | 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 | 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 | used by instances that share a static key or if an attacker can cause | |||
cause a packet to be routed to an instance that has no state but the | a packet to be routed to an instance that has no state but the same | |||
same static key; see Section 21.11. A connection ID from a | static key; see Section 21.11. A connection ID from a connection | |||
connection that is reset by revealing the Stateless Reset Token MUST | that is reset by revealing the stateless reset token MUST NOT be | |||
NOT be reused for new connections at nodes that share a static key. | reused for new connections at nodes that share a static key. | |||
The same Stateless Reset Token MUST NOT be used for multiple | The same stateless reset token MUST NOT be used for multiple | |||
connection IDs. Endpoints are not required to compare new values | connection IDs. Endpoints are not required to compare new values | |||
against all previous values, but a duplicate value MAY be treated as | against all previous values, but a duplicate value MAY be treated as | |||
a connection error of type PROTOCOL_VIOLATION. | a connection error of type PROTOCOL_VIOLATION. | |||
Note that Stateless Reset packets do not have any cryptographic | Note that Stateless Resets do not have any cryptographic protection. | |||
protection. | ||||
10.3.3. Looping | 10.3.3. Looping | |||
The design of a Stateless Reset is such that without knowing the | The design of a Stateless Reset is such that without knowing the | |||
stateless reset token it is indistinguishable from a valid packet. | stateless reset token it is indistinguishable from a valid packet. | |||
For instance, if a server sends a Stateless Reset to another server | For instance, if a server sends a Stateless Reset to another server, | |||
it might receive another Stateless Reset in response, which could | it might receive another Stateless Reset in response, which could | |||
lead to an infinite exchange. | lead to an infinite exchange. | |||
An endpoint MUST ensure that every Stateless Reset that it sends is | An endpoint MUST ensure that every Stateless Reset that it sends is | |||
smaller than the packet that triggered it, unless it maintains state | smaller than the packet that triggered it, unless it maintains state | |||
sufficient to prevent looping. In the event of a loop, this results | sufficient to prevent looping. In the event of a loop, this results | |||
in packets eventually being too small to trigger a response. | in packets eventually being too small to trigger a response. | |||
An endpoint can remember the number of Stateless Reset packets that | An endpoint can remember the number of Stateless Resets that it has | |||
it has sent and stop generating new Stateless Reset packets once a | sent and stop generating new Stateless Resets once a limit is | |||
limit is reached. Using separate limits for different remote | reached. Using separate limits for different remote addresses will | |||
addresses will ensure that Stateless Reset packets can be used to | ensure that Stateless Resets can be used to close connections when | |||
close connections when other peers or connections have exhausted | other peers or connections have exhausted limits. | |||
limits. | ||||
Reducing the size of a Stateless Reset below 41 bytes means that the | A Stateless Reset that is smaller than 41 bytes might be identifiable | |||
packet could reveal to an observer that it is a Stateless Reset, | as a Stateless Reset by an observer, depending upon the length of the | |||
depending upon the length of the peer's connection IDs. Conversely, | peer's connection IDs. Conversely, not sending a Stateless Reset in | |||
refusing to send a Stateless Reset in response to a small packet | response to a small packet might result in Stateless Resets not being | |||
might result in Stateless Reset not being useful in detecting cases | useful in detecting cases of broken connections where only very small | |||
of broken connections where only very small packets are sent; such | packets are sent; such failures might only be detected by other | |||
failures might only be detected by other means, such as timers. | means, such as timers. | |||
11. Error Handling | 11. Error Handling | |||
An endpoint that detects an error SHOULD signal the existence of that | An endpoint that detects an error SHOULD signal the existence of that | |||
error to its peer. Both transport-level and application-level errors | error to its peer. Both transport-level and application-level errors | |||
can affect an entire connection; see Section 11.1. Only application- | can affect an entire connection; see Section 11.1. Only application- | |||
level errors can be isolated to a single stream; see Section 11.2. | level errors can be isolated to a single stream; see Section 11.2. | |||
The most appropriate error code (Section 20) SHOULD be included in | The most appropriate error code (Section 20) SHOULD be included in | |||
the frame that signals the error. Where this specification | the frame that signals the error. Where this specification | |||
skipping to change at page 79, line 20 ¶ | skipping to change at page 78, line 18 ¶ | |||
connection. Limiting the number of retransmissions and the time over | connection. Limiting the number of retransmissions and the time over | |||
which this final packet is sent limits the effort expended on | which this final packet is sent limits the effort expended on | |||
terminated connections. | terminated connections. | |||
An endpoint that chooses not to retransmit packets containing a | An endpoint that chooses not to retransmit packets containing a | |||
CONNECTION_CLOSE frame risks a peer missing the first such packet. | CONNECTION_CLOSE frame risks a peer missing the first such packet. | |||
The only mechanism available to an endpoint that continues to receive | The only mechanism available to an endpoint that continues to receive | |||
data for a terminated connection is to attempt the stateless reset | data for a terminated connection is to attempt the stateless reset | |||
process (Section 10.3). | process (Section 10.3). | |||
As the AEAD on Initial packets does not provide strong | As the AEAD for Initial packets does not provide strong | |||
authentication, an endpoint MAY discard an invalid Initial packet. | authentication, an endpoint MAY discard an invalid Initial packet. | |||
Discarding an Initial packet is permitted even where this | Discarding an Initial packet is permitted even where this | |||
specification otherwise mandates a connection error. An endpoint can | specification otherwise mandates a connection error. An endpoint can | |||
only discard a packet if it does not process the frames in the packet | only discard a packet if it does not process the frames in the packet | |||
or reverts the effects of any processing. Discarding invalid Initial | or reverts the effects of any processing. Discarding invalid Initial | |||
packets might be used to reduce exposure to denial of service; see | packets might be used to reduce exposure to denial of service; see | |||
Section 21.2. | Section 21.2. | |||
11.2. Stream Errors | 11.2. Stream Errors | |||
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. | |||
The semantics of the application error code carried in RESET_STREAM | The semantics of the application error code carried in RESET_STREAM | |||
are defined by the application protocol. Only the application | are defined by the application protocol. Only the application | |||
protocol is able to cause a stream to be terminated. A local | protocol is able to cause a stream to be terminated. A local | |||
instance of the application protocol uses a direct API call and a | instance of the application protocol uses a direct API call, and 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 canceled 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. Packets | confidentiality and integrity protection; see Section 12.1. Packets | |||
are carried in UDP datagrams; see Section 12.2. | are carried in UDP datagrams; see Section 12.2. | |||
This version of QUIC uses the long packet header during connection | This version of QUIC uses the long packet header during connection | |||
establishment; see Section 17.2. Packets with the long header are | establishment; see Section 17.2. Packets with the long header are | |||
Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake | Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake | |||
skipping to change at page 80, line 32 ¶ | skipping to change at page 79, line 32 ¶ | |||
12.1. Protected Packets | 12.1. Protected Packets | |||
QUIC packets have different levels of cryptographic protection based | QUIC packets have different levels of cryptographic protection based | |||
on the type of packet. Details of packet protection are found in | on the type of packet. Details of packet protection are found in | |||
[QUIC-TLS]; this section includes an overview of the protections that | [QUIC-TLS]; this section includes an overview of the protections that | |||
are provided. | are provided. | |||
Version Negotiation packets have no cryptographic protection; see | Version Negotiation packets have no cryptographic protection; see | |||
[QUIC-INVARIANTS]. | [QUIC-INVARIANTS]. | |||
Retry packets use an authenticated encryption with associated data | Retry packets use an AEAD function [AEAD] to protect against | |||
function (AEAD; [AEAD]) to protect against accidental modification. | ||||
Initial packets use an AEAD, the keys for which are derived using a | ||||
value that is visible on the wire. Initial packets therefore do not | ||||
have effective confidentiality protection. Initial protection exists | ||||
to ensure that the sender of the packet is on the network path. Any | ||||
entity that receives an Initial packet from a client can recover the | ||||
keys that will allow them to both read the contents of the packet and | ||||
generate Initial packets that will be successfully authenticated at | ||||
either endpoint. The AEAD also protects Initial packets against | ||||
accidental modification. | accidental modification. | |||
Initial packets use an AEAD function, the keys for which are derived | ||||
using a value that is visible on the wire. Initial packets therefore | ||||
do not have effective confidentiality protection. Initial protection | ||||
exists to ensure that the sender of the packet is on the network | ||||
path. Any entity that receives an Initial packet from a client can | ||||
recover the keys that will allow them to both read the contents of | ||||
the packet and generate Initial packets that will be successfully | ||||
authenticated at either endpoint. The AEAD also protects Initial | ||||
packets against accidental modification. | ||||
All other packets are protected with keys derived from the | All other packets are protected with keys derived from the | |||
cryptographic handshake. The cryptographic handshake ensures that | cryptographic handshake. The cryptographic handshake ensures that | |||
only the communicating endpoints receive the corresponding keys for | only the communicating endpoints receive the corresponding keys for | |||
Handshake, 0-RTT, and 1-RTT packets. Packets protected with 0-RTT | Handshake, 0-RTT, and 1-RTT packets. Packets protected with 0-RTT | |||
and 1-RTT keys have strong confidentiality and integrity protection. | and 1-RTT keys have strong confidentiality and integrity protection. | |||
The Packet Number field that appears in some packet types has | The Packet Number field that appears in some packet types has | |||
alternative confidentiality protection that is applied as part of | alternative confidentiality protection that is applied as part of | |||
header protection; see Section 5.4 of [QUIC-TLS] for details. The | header protection; see Section 5.4 of [QUIC-TLS] for details. The | |||
underlying packet number increases with each packet sent in a given | underlying packet number increases with each packet sent in a given | |||
skipping to change at page 81, line 20 ¶ | skipping to change at page 80, line 20 ¶ | |||
Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake | Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake | |||
(Section 17.2.4) packets contain a Length field that determines the | (Section 17.2.4) packets contain a Length field that determines the | |||
end of the packet. The length includes both the Packet Number and | end of the packet. The length includes both the Packet Number and | |||
Payload fields, both of which are confidentiality protected and | Payload fields, both of which are confidentiality protected and | |||
initially of unknown length. The length of the Payload field is | initially of unknown length. The length of the Payload field is | |||
learned once header protection is removed. | learned once header protection is removed. | |||
Using the Length field, a sender can coalesce multiple QUIC packets | Using the Length field, a sender can coalesce multiple QUIC packets | |||
into one UDP datagram. This can reduce the number of UDP datagrams | into one UDP datagram. This can reduce the number of UDP datagrams | |||
needed to complete the cryptographic handshake and start sending | needed to complete the cryptographic handshake and start sending | |||
data. This can also be used to construct PMTU probes; see | data. This can also be used to construct Path Maximum Transmission | |||
Section 14.4.1. Receivers MUST be able to process coalesced packets. | Unit (PMTU) probes; see Section 14.4.1. Receivers MUST be able to | |||
process coalesced packets. | ||||
Coalescing packets in order of increasing encryption levels (Initial, | Coalescing packets in order of increasing encryption levels (Initial, | |||
0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it | 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it | |||
more likely the receiver will be able to process all the packets in a | more likely that the receiver will be able to process all the packets | |||
single pass. A packet with a short header does not include a length, | in a single pass. A packet with a short header does not include a | |||
so it can only be the last packet included in a UDP datagram. An | length, so it can only be the last packet included in a UDP datagram. | |||
endpoint SHOULD include multiple frames in a single packet if they | An endpoint SHOULD include multiple frames in a single packet if they | |||
are to be sent at the same encryption level, instead of coalescing | are to be sent at the same encryption level, instead of coalescing | |||
multiple packets at the same encryption level. | multiple packets at the same encryption level. | |||
Receivers MAY route based on the information in the first packet | Receivers MAY route based on the information in the first packet | |||
contained in a UDP datagram. Senders MUST NOT coalesce QUIC packets | contained in a UDP datagram. Senders MUST NOT coalesce QUIC packets | |||
with different connection IDs into a single UDP datagram. Receivers | with different connection IDs into a single UDP datagram. Receivers | |||
SHOULD ignore any subsequent packets with a different Destination | SHOULD ignore any subsequent packets with a different Destination | |||
Connection ID than the first packet in the datagram. | Connection ID than the first packet in the datagram. | |||
Every QUIC packet that is coalesced into a single UDP datagram is | Every QUIC packet that is coalesced into a single UDP datagram is | |||
separate and complete. The receiver of coalesced QUIC packets MUST | separate and complete. The receiver of coalesced QUIC packets MUST | |||
individually process each QUIC packet and separately acknowledge | individually process each QUIC packet and separately acknowledge | |||
them, as if they were received as the payload of different UDP | them, as if they were received as the payload of different UDP | |||
datagrams. For example, if decryption fails (because the keys are | datagrams. For example, if decryption fails (because the keys are | |||
not available or any other reason), the receiver MAY either discard | not available or for any other reason), the receiver MAY either | |||
or buffer the packet for later processing and MUST attempt to process | discard or buffer the packet for later processing and MUST attempt to | |||
the remaining packets. | process the remaining packets. | |||
Retry packets (Section 17.2.5), Version Negotiation packets | Retry packets (Section 17.2.5), Version Negotiation packets | |||
(Section 17.2.1), and packets with a short header (Section 17.3) do | (Section 17.2.1), and packets with a short header (Section 17.3) do | |||
not contain a Length field and so cannot be followed by other packets | not contain a Length field and so cannot be followed by other packets | |||
in the same UDP datagram. Note also that there is no situation where | in the same UDP datagram. Note also that there is no situation where | |||
a Retry or Version Negotiation packet is coalesced with another | a Retry or Version Negotiation packet is coalesced with another | |||
packet. | packet. | |||
12.3. Packet Numbers | 12.3. Packet Numbers | |||
The packet number is an integer in the range 0 to 2^62-1. This | The packet number is an integer in the range 0 to 2^62-1. This | |||
number is used in determining the cryptographic nonce for packet | number is used in determining the cryptographic nonce for packet | |||
protection. Each endpoint maintains a separate packet number for | protection. Each endpoint maintains a separate packet number for | |||
sending and receiving. | sending and receiving. | |||
Packet numbers are limited to this range because they need to be | Packet numbers are limited to this range because they need to be | |||
representable in whole in the Largest Acknowledged field of an ACK | representable in whole in the Largest Acknowledged field of an ACK | |||
frame (Section 19.3). When present in a long or short header | frame (Section 19.3). When present in a long or short header, | |||
however, packet numbers are reduced and encoded in 1 to 4 bytes; see | however, packet numbers are reduced and encoded in 1 to 4 bytes; see | |||
Section 17.1. | Section 17.1. | |||
Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) | Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) | |||
packets do not include a packet number. | packets do not include a packet number. | |||
Packet numbers are divided into 3 spaces in QUIC: | Packet numbers are divided into three spaces in QUIC: | |||
o Initial space: All Initial packets (Section 17.2.2) are in this | Initial space: All Initial packets (Section 17.2.2) are in this | |||
space. | space. | |||
o Handshake space: All Handshake packets (Section 17.2.4) are in | Handshake space: All Handshake packets (Section 17.2.4) are in this | |||
this space. | space. | |||
o Application data space: All 0-RTT (Section 17.2.3) and 1-RTT | Application data space: All 0-RTT (Section 17.2.3) and 1-RTT | |||
(Section 17.3.1) packets are in this space. | (Section 17.3.1) packets are in this space. | |||
As described in [QUIC-TLS], each packet type uses different | As described in [QUIC-TLS], each packet type uses different | |||
protection keys. | protection keys. | |||
Conceptually, a packet number space is the context in which a packet | Conceptually, a packet number space is the context in which a packet | |||
can be processed and acknowledged. Initial packets can only be sent | can be processed and acknowledged. Initial packets can only be sent | |||
with Initial packet protection keys and acknowledged in packets that | with Initial packet protection keys and acknowledged in packets that | |||
are also Initial packets. Similarly, Handshake packets are sent at | are also Initial packets. Similarly, Handshake packets are sent at | |||
the Handshake encryption level and can only be acknowledged in | the Handshake encryption level and can only be acknowledged in | |||
skipping to change at page 83, line 7 ¶ | skipping to change at page 82, line 7 ¶ | |||
different packet number spaces. Packet numbers in each space start | different packet number spaces. Packet numbers in each space start | |||
at packet number 0. Subsequent packets sent in the same packet | at packet number 0. Subsequent packets sent in the same packet | |||
number space MUST increase the packet number by at least one. | number space MUST increase the packet number by at least one. | |||
0-RTT and 1-RTT data exist in the same packet number space to make | 0-RTT and 1-RTT data exist in the same packet number space to make | |||
loss recovery algorithms easier to implement between the two packet | loss recovery algorithms easier to implement between the two packet | |||
types. | types. | |||
A QUIC endpoint MUST NOT reuse a packet number within the same packet | A QUIC endpoint MUST NOT reuse a packet number within the same packet | |||
number space in one connection. If the packet number for sending | number space in one connection. If the packet number for sending | |||
reaches 2^62 - 1, the sender MUST close the connection without | reaches 2^62-1, the sender MUST close the connection without sending | |||
sending a CONNECTION_CLOSE frame or any further packets; an endpoint | a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send | |||
MAY send a Stateless Reset (Section 10.3) in response to further | a Stateless Reset (Section 10.3) in response to further packets that | |||
packets that it receives. | it receives. | |||
A receiver MUST discard a newly unprotected packet unless it is | A receiver MUST discard a newly unprotected packet unless it is | |||
certain that it has not processed another packet with the same packet | certain that it has not processed another packet with the same packet | |||
number from the same packet number space. Duplicate suppression MUST | number from the same packet number space. Duplicate suppression MUST | |||
happen after removing packet protection for the reasons described in | happen after removing packet protection for the reasons described in | |||
Section 9.5 of [QUIC-TLS]. | Section 9.5 of [QUIC-TLS]. | |||
Endpoints that track all individual packets for the purposes of | Endpoints that track all individual packets for the purposes of | |||
detecting duplicates are at risk of accumulating excessive state. | detecting duplicates are at risk of accumulating excessive state. | |||
The data required for detecting duplicates can be limited by | The data required for detecting duplicates can be limited by | |||
maintaining a minimum packet number below which all packets are | maintaining a minimum packet number below which all packets are | |||
immediately dropped. Any minimum needs to account for large | immediately dropped. Any minimum needs to account for large | |||
variations in round trip time, which includes the possibility that a | variations in round-trip time, which includes the possibility that a | |||
peer might probe network paths with much larger round trip times; see | peer might probe network paths with much larger round-trip times; see | |||
Section 9. | Section 9. | |||
Packet number encoding at a sender and decoding at a receiver are | Packet number encoding at a sender and decoding at a receiver are | |||
described in Section 17.1. | described in Section 17.1. | |||
12.4. Frames and Frame Types | 12.4. Frames and Frame Types | |||
The payload of QUIC packets, after removing packet protection, | The payload of QUIC packets, after removing packet protection, | |||
consists of a sequence of complete frames, as shown in Figure 11. | consists of a sequence of complete frames, as shown in Figure 11. | |||
Version Negotiation, Stateless Reset, and Retry packets do not | Version Negotiation, Stateless Reset, and Retry packets do not | |||
skipping to change at page 85, line 5 ¶ | skipping to change at page 84, line 5 ¶ | |||
Frame Type (i), | Frame Type (i), | |||
Type-Dependent Fields (..), | Type-Dependent Fields (..), | |||
} | } | |||
Figure 12: Generic Frame Layout | Figure 12: Generic Frame Layout | |||
Table 3 lists and summarizes information about each frame type that | Table 3 lists and summarizes information about each frame type that | |||
is defined in this specification. A description of this summary is | is defined in this specification. A description of this summary is | |||
included after the table. | included after the table. | |||
+-------------+----------------------+----------------+------+------+ | +------------+----------------------+----------------+------+------+ | |||
| Type Value | Frame Type Name | Definition | Pkts | Spec | | | Type Value | Frame Type Name | Definition | Pkts | Spec | | |||
+-------------+----------------------+----------------+------+------+ | +------------+----------------------+----------------+------+------+ | |||
| 0x00 | PADDING | Section 19.1 | IH01 | NP | | | 0x00 | PADDING | Section 19.1 | IH01 | NP | | |||
| | | | | | | | | | | | | | |||
| 0x01 | PING | Section 19.2 | IH01 | | | | 0x01 | PING | Section 19.2 | IH01 | | | |||
| | | | | | | | | | | | | | |||
| 0x02 - 0x03 | ACK | Section 19.3 | IH_1 | NC | | | 0x02-0x03 | ACK | Section 19.3 | IH_1 | NC | | |||
| | | | | | | | | | | | | | |||
| 0x04 | RESET_STREAM | Section 19.4 | __01 | | | | 0x04 | RESET_STREAM | Section 19.4 | __01 | | | |||
| | | | | | | | | | | | | | |||
| 0x05 | STOP_SENDING | Section 19.5 | __01 | | | | 0x05 | STOP_SENDING | Section 19.5 | __01 | | | |||
| | | | | | | | | | | | | | |||
| 0x06 | CRYPTO | Section 19.6 | IH_1 | | | | 0x06 | CRYPTO | Section 19.6 | IH_1 | | | |||
| | | | | | | | | | | | | | |||
| 0x07 | NEW_TOKEN | Section 19.7 | ___1 | | | | 0x07 | NEW_TOKEN | Section 19.7 | ___1 | | | |||
| | | | | | | | | | | | | | |||
| 0x08 - 0x0f | STREAM | Section 19.8 | __01 | F | | | 0x08-0x0f | STREAM | Section 19.8 | __01 | F | | |||
| | | | | | | | | | | | | | |||
| 0x10 | MAX_DATA | Section 19.9 | __01 | | | | 0x10 | MAX_DATA | Section 19.9 | __01 | | | |||
| | | | | | | | | | | | | | |||
| 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | | | | 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | | | |||
| | | | | | | | | | | | | | |||
| 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | __01 | | | | 0x12-0x13 | MAX_STREAMS | Section 19.11 | __01 | | | |||
| | | | | | | | | | | | | | |||
| 0x14 | DATA_BLOCKED | Section 19.12 | __01 | | | | 0x14 | DATA_BLOCKED | Section 19.12 | __01 | | | |||
| | | | | | | | | | | | | | |||
| 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | | | | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | | | |||
| | | | | | | | | | | | | | |||
| 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | | | 0x16-0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | | |||
| | | | | | | | | | | | | | |||
| 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P | | | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P | | |||
| | | | | | | | | | | | | | |||
| 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | | | | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | | | |||
| | | | | | | | | | | | | | |||
| 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P | | | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P | | |||
| | | | | | | | | | | | | | |||
| 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P | | | 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P | | |||
| | | | | | | | | | | | | | |||
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N | | | 0x1c-0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N | | |||
| | | | | | | | | | | | | | |||
| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | | | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | | |||
+-------------+----------------------+----------------+------+------+ | +------------+----------------------+----------------+------+------+ | |||
Table 3: Frame Types | Table 3: Frame Types | |||
The format and semantics of each frame type are explained in more | The format and semantics of each frame type are explained in more | |||
detail in Section 19. The remainder of this section provides a | detail in Section 19. The remainder of this section provides a | |||
summary of important and general information. | summary of important and general information. | |||
The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and | The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and | |||
CONNECTION_CLOSE frames is used to carry other frame-specific flags. | CONNECTION_CLOSE frames is used to carry other frame-specific flags. | |||
For all other frames, the Frame Type field simply identifies the | For all other frames, the Frame Type field simply identifies the | |||
frame. | frame. | |||
The "Pkts" column in Table 3 lists the types of packets that each | The "Pkts" column in Table 3 lists the types of packets that each | |||
frame type could appear in, indicated by the following characters: | frame type could appear in, indicated by the following 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: 1-RTT (Section 17.3.1) | |||
ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial | ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial | |||
or Handshake packets. | or Handshake packets. | |||
For more detail about these restrictions, see Section 12.5. Note | For more details about these restrictions, see Section 12.5. Note | |||
that all frames can appear in 1-RTT packets. An endpoint MUST treat | that all frames can appear in 1-RTT packets. An endpoint MUST treat | |||
receipt of a frame in a packet type that is not permitted as a | receipt of a frame in a packet type that is not permitted as a | |||
connection error of type PROTOCOL_VIOLATION. | connection error of type PROTOCOL_VIOLATION. | |||
The "Spec" column in Table 3 summarizes any special rules governing | The "Spec" column in Table 3 summarizes any special rules governing | |||
the processing or generation of the frame type, as indicated by the | the processing or generation of the frame type, as indicated by the | |||
following characters: | following characters: | |||
N: Packets containing only frames with this marking are not ack- | N: Packets containing only frames with this marking are not ack- | |||
eliciting; see Section 13.2. | eliciting; see Section 13.2. | |||
C: Packets containing only frames with this marking do not count | C: Packets containing only frames with this marking do not count | |||
toward bytes in flight for congestion control purposes; see | toward bytes in flight for congestion control purposes; see | |||
[QUIC-RECOVERY]. | [QUIC-RECOVERY]. | |||
P: Packets containing only frames with this marking can be used to | P: Packets containing only frames with this marking can be used to | |||
probe new network paths during connection migration; see | probe new network paths during connection migration; see | |||
Section 9.1. | Section 9.1. | |||
F: The content of frames with this marking are flow controlled; see | F: The contents of frames with this marking are flow controlled; | |||
Section 4. | see Section 4. | |||
The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA | The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA | |||
registry; see Section 22.4. | registry; see Section 22.4. | |||
An endpoint MUST treat the receipt of a frame of unknown type as a | An endpoint MUST treat the receipt of a frame of unknown type as a | |||
connection error of type FRAME_ENCODING_ERROR. | connection error of type FRAME_ENCODING_ERROR. | |||
All frames are idempotent in this version of QUIC. That is, a valid | All frames are idempotent in this version of QUIC. That is, a valid | |||
frame does not cause undesirable side effects or errors when received | frame does not cause undesirable side effects or errors when received | |||
more than once. | more than once. | |||
The Frame Type field uses a variable-length integer encoding (see | The Frame Type field uses a variable-length integer encoding (see | |||
Section 16) with one exception. To ensure simple and efficient | Section 16), with one exception. To ensure simple and efficient | |||
implementations of frame parsing, a frame type MUST use the shortest | implementations of frame parsing, a frame type MUST use the shortest | |||
possible encoding. For frame types defined in this document, this | possible encoding. For frame types defined in this document, this | |||
means a single-byte encoding, even though it is possible to encode | means a single-byte encoding, even though it is possible to encode | |||
these values as a two-, four- or eight-byte variable-length integer. | these values as a two-, four-, or eight-byte variable-length integer. | |||
For instance, though 0x4001 is a legitimate two-byte encoding for a | For instance, though 0x4001 is a legitimate two-byte encoding for a | |||
variable-length integer with a value of 1, PING frames are always | variable-length integer with a value of 1, PING frames are always | |||
encoded as a single byte with the value 0x01. This rule applies to | encoded as a single byte with the value 0x01. This rule applies to | |||
all current and future QUIC frame types. An endpoint MAY treat the | all current and future QUIC frame types. An endpoint MAY treat the | |||
receipt of a frame type that uses a longer encoding than necessary as | receipt of a frame type that uses a longer encoding than necessary as | |||
a connection error of type PROTOCOL_VIOLATION. | a connection error of type PROTOCOL_VIOLATION. | |||
12.5. Frames and Number Spaces | 12.5. Frames and Number Spaces | |||
Some frames are prohibited in different packet number spaces. The | Some frames are prohibited in different packet number spaces. The | |||
skipping to change at page 87, line 41 ¶ | skipping to change at page 86, line 41 ¶ | |||
can only appear in the application data packet number space: | can only appear in the application data packet number space: | |||
o PADDING, PING, and CRYPTO frames MAY appear in any packet number | o PADDING, PING, and CRYPTO frames MAY appear in any packet number | |||
space. | space. | |||
o CONNECTION_CLOSE frames signaling errors at the QUIC layer (type | o CONNECTION_CLOSE frames signaling errors at the QUIC layer (type | |||
0x1c) MAY appear in any packet number space. CONNECTION_CLOSE | 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE | |||
frames signaling application errors (type 0x1d) MUST only appear | frames signaling application errors (type 0x1d) MUST only appear | |||
in the application data packet number space. | in the application data packet number space. | |||
o ACK frames MAY appear in any packet number space, but can only | o ACK frames MAY appear in any packet number space but can only | |||
acknowledge packets that appeared in that packet number space. | acknowledge packets that appeared in that packet number space. | |||
However, as noted below, 0-RTT packets cannot contain ACK frames. | However, as noted below, 0-RTT packets cannot contain ACK frames. | |||
o All other frame types MUST only be sent in the application data | o All other frame types MUST only be sent in the application data | |||
packet number space. | packet number space. | |||
Note that it is not possible to send the following frames in 0-RTT | Note that it is not possible to send the following frames in 0-RTT | |||
packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, | packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, | |||
PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt | PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt | |||
of these frames in 0-RTT packets as a connection error of type | of these frames in 0-RTT packets as a connection error of type | |||
skipping to change at page 88, line 40 ¶ | skipping to change at page 87, line 40 ¶ | |||
progress. Implementations are advised to include as few streams as | progress. Implementations are advised to include as few streams as | |||
necessary in outgoing packets without losing transmission efficiency | necessary in outgoing packets without losing transmission efficiency | |||
to underfilled packets. | to underfilled packets. | |||
13.1. Packet Processing | 13.1. Packet Processing | |||
A packet MUST NOT be acknowledged until packet protection has been | A packet MUST NOT be acknowledged until packet protection has been | |||
successfully removed and all frames contained in the packet have been | successfully removed and all frames contained in the packet have been | |||
processed. For STREAM frames, this means the data has been enqueued | processed. For STREAM frames, this means the data has been enqueued | |||
in preparation to be received by the application protocol, but it | in preparation to be received by the application protocol, but it | |||
does not require that data is delivered and consumed. | does not require that data be delivered and consumed. | |||
Once the packet has been fully processed, a receiver acknowledges | Once the packet has been fully processed, a receiver acknowledges | |||
receipt by sending one or more ACK frames containing the packet | receipt by sending one or more ACK frames containing the packet | |||
number of the received packet. | number of the received packet. | |||
An endpoint SHOULD treat receipt of an acknowledgment for a packet it | 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 | did not send as a connection error of type PROTOCOL_VIOLATION, if it | |||
is able to detect the condition. Further discussion of how this | is able to detect the condition. For further discussion of how this | |||
might be achieved is in Section 21.4. | might be achieved, see Section 21.4. | |||
13.2. Generating Acknowledgments | 13.2. Generating Acknowledgments | |||
Endpoints acknowledge all packets they receive and process. However, | Endpoints acknowledge all packets they receive and process. However, | |||
only ack-eliciting packets cause an ACK frame to be sent within the | only ack-eliciting packets cause an ACK frame to be sent within the | |||
maximum ack delay. Packets that are not ack-eliciting are only | maximum ack delay. Packets that are not ack-eliciting are only | |||
acknowledged when an ACK frame is sent for other reasons. | acknowledged when an ACK frame is sent for other reasons. | |||
When sending a packet for any reason, an endpoint SHOULD attempt to | When sending a packet for any reason, an endpoint SHOULD attempt to | |||
include an ACK frame if one has not been sent recently. Doing so | include an ACK frame if one has not been sent recently. Doing so | |||
skipping to change at page 90, line 5 ¶ | skipping to change at page 89, line 5 ¶ | |||
controlled, an endpoint MUST NOT send more than one such packet in | controlled, an endpoint MUST NOT send more than one such packet in | |||
response to receiving an ack-eliciting packet. | response to receiving an ack-eliciting packet. | |||
An endpoint MUST NOT send a non-ack-eliciting packet in response to a | An endpoint MUST NOT send a non-ack-eliciting packet in response to a | |||
non-ack-eliciting packet, even if there are packet gaps that precede | non-ack-eliciting packet, even if there are packet gaps that precede | |||
the received packet. This avoids an infinite feedback loop of | the received packet. This avoids an infinite feedback loop of | |||
acknowledgments, which could prevent the connection from ever | acknowledgments, which could prevent the connection from ever | |||
becoming idle. Non-ack-eliciting packets are eventually acknowledged | becoming idle. Non-ack-eliciting packets are eventually acknowledged | |||
when the endpoint sends an ACK frame in response to other events. | when the endpoint sends an ACK frame in response to other events. | |||
An endpoint that is only sending ACK frames will not receive | ||||
acknowledgments from its peer unless those acknowledgments are | ||||
included in packets with ack-eliciting frames. An endpoint SHOULD | ||||
send an ACK frame 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 choose not to send an ACK frame with | ||||
outgoing frames until an ack-eliciting packet has been received. | ||||
An endpoint that is only sending non-ack-eliciting packets might | ||||
choose to occasionally add an ack-eliciting frame to those packets to | ||||
ensure that it receives an acknowledgment; see Section 13.2.4. In | ||||
that case, an endpoint MUST NOT send an ack-eliciting frame in all | ||||
packets that would otherwise be non-ack-eliciting, to avoid an | ||||
infinite feedback loop of acknowledgments. | ||||
In order to assist loss detection at the sender, an endpoint SHOULD | In order to assist loss detection at the sender, an endpoint SHOULD | |||
generate and send an ACK frame without delay when it receives an ack- | generate and send an ACK frame without delay when it receives an ack- | |||
eliciting packet either: | eliciting packet either: | |||
o when the received packet has a packet number less than another | o when the received packet has a packet number less than another | |||
ack-eliciting packet that has been received, or | ack-eliciting packet that has been received, or | |||
o when the packet has a packet number larger than the highest- | o when the packet has a packet number larger than the highest- | |||
numbered ack-eliciting packet that has been received and there are | numbered ack-eliciting packet that has been received and there are | |||
missing packets between that packet and this packet. | missing packets between that packet and this packet. | |||
skipping to change at page 90, line 27 ¶ | skipping to change at page 89, line 42 ¶ | |||
codepoint in the IP header SHOULD be acknowledged immediately, to | codepoint in the IP header SHOULD be acknowledged immediately, to | |||
reduce the peer's response time to congestion events. | reduce the peer's response time to congestion events. | |||
The algorithms in [QUIC-RECOVERY] are expected to be resilient to | The algorithms in [QUIC-RECOVERY] are expected to be resilient to | |||
receivers that do not follow the guidance offered above. However, an | receivers that do not follow the guidance offered above. However, an | |||
implementation should only deviate from these requirements after | implementation should only deviate from these requirements after | |||
careful consideration of the performance implications of a change, | careful consideration of the performance implications of a change, | |||
for connections made by the endpoint and for other users of the | for connections made by the endpoint and for other users of the | |||
network. | network. | |||
An endpoint that is only sending ACK frames will not receive | ||||
acknowledgments from its peer unless those acknowledgments are | ||||
included in packets with ack-eliciting frames. An endpoint SHOULD | ||||
send an ACK frame 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 include an ACK frame with outgoing frames. | ||||
A receiver MUST NOT send an ack-eliciting frame in all packets that | ||||
would otherwise be non-ack-eliciting, to avoid an infinite feedback | ||||
loop of acknowledgments. | ||||
13.2.2. Acknowledgment Frequency | 13.2.2. Acknowledgment Frequency | |||
A receiver determines how frequently to send acknowledgments in | A receiver determines how frequently to send acknowledgments in | |||
response to ack-eliciting packets. This determination involves a | response to ack-eliciting packets. This determination involves a | |||
trade-off. | trade-off. | |||
Endpoints rely on timely acknowledgment to detect loss; see Section 6 | Endpoints rely on timely acknowledgment to detect loss; see Section 6 | |||
of [QUIC-RECOVERY]. Window-based congestion controllers, such as the | of [QUIC-RECOVERY]. Window-based congestion controllers, such as the | |||
one in Section 7 of [QUIC-RECOVERY], rely on acknowledgments to | one described in Section 7 of [QUIC-RECOVERY], rely on | |||
manage their congestion window. In both cases, delaying | acknowledgments to manage their congestion window. In both cases, | |||
acknowledgments can adversely affect performance. | delaying acknowledgments can adversely affect performance. | |||
On the other hand, reducing the frequency of packets that carry only | On the other hand, reducing the frequency of packets that carry only | |||
acknowledgments reduces packet transmission and processing cost at | acknowledgments reduces packet transmission and processing cost at | |||
both endpoints. It can improve connection throughput on severely | both endpoints. It can improve connection throughput on severely | |||
asymmetric links and reduce the volume of acknowledgment traffic | asymmetric links and reduce the volume of acknowledgment traffic | |||
using return path capacity; see Section 3 of [RFC3449]. | using return path capacity; see Section 3 of [RFC3449]. | |||
A receiver SHOULD send an ACK frame after receiving at least two ack- | A receiver SHOULD send an ACK frame after receiving at least two ack- | |||
eliciting packets. This recommendation is general in nature and | eliciting packets. This recommendation is general in nature and | |||
consistent with recommendations for TCP endpoint behavior [RFC5681]. | consistent with recommendations for TCP endpoint behavior [RFC5681]. | |||
skipping to change at page 91, line 27 ¶ | skipping to change at page 90, line 30 ¶ | |||
whether to send an ACK frame in response. | whether to send an ACK frame in response. | |||
13.2.3. Managing ACK Ranges | 13.2.3. Managing ACK Ranges | |||
When an ACK frame is sent, one or more ranges of acknowledged packets | When an ACK frame is sent, one or more ranges of acknowledged packets | |||
are included. Including acknowledgments for older packets reduces | are included. Including acknowledgments for older packets reduces | |||
the chance of spurious retransmissions caused by losing previously | the chance of spurious retransmissions caused by losing previously | |||
sent ACK frames, at the cost of larger ACK frames. | sent ACK frames, at the cost of larger ACK frames. | |||
ACK frames SHOULD always acknowledge the most recently received | ACK frames SHOULD always acknowledge the most recently received | |||
packets, and the more out-of-order the packets are, the more | packets, and the more out of order the packets are, the more | |||
important it is to send an updated ACK frame quickly, to prevent the | important it is to send an updated ACK frame quickly, to prevent the | |||
peer from declaring a packet as lost and spuriously retransmitting | peer from declaring a packet as lost and spuriously retransmitting | |||
the frames it contains. An ACK frame is expected to fit within a | the frames it contains. An ACK frame is expected to fit within a | |||
single QUIC packet. If it does not, then older ranges (those with | single QUIC packet. If it does not, then older ranges (those with | |||
the smallest packet numbers) are omitted. | the smallest packet numbers) are omitted. | |||
A receiver limits the number of ACK Ranges (Section 19.3.1) it | A receiver limits the number of ACK Ranges (Section 19.3.1) it | |||
remembers and sends in ACK frames, both to limit the size of ACK | remembers and sends in ACK frames, both to limit the size of ACK | |||
frames and to avoid resource exhaustion. After receiving | frames and to avoid resource exhaustion. After receiving | |||
acknowledgments for an ACK frame, the receiver SHOULD stop tracking | acknowledgments for an ACK frame, the receiver SHOULD stop tracking | |||
skipping to change at page 92, line 4 ¶ | skipping to change at page 91, line 7 ¶ | |||
It is possible that retaining many ACK Ranges could cause an ACK | It is possible that retaining many ACK Ranges could cause an ACK | |||
frame to become too large. A receiver can discard unacknowledged ACK | frame to become too large. A receiver can discard unacknowledged ACK | |||
Ranges to limit ACK frame size, at the cost of increased | Ranges to limit ACK frame size, at the cost of increased | |||
retransmissions from the sender. This is necessary if an ACK frame | retransmissions from the sender. This is necessary if an ACK frame | |||
would be too large to fit in a packet. Receivers MAY also limit ACK | would be too large to fit in a packet. Receivers MAY also limit ACK | |||
frame size further to preserve space for other frames or to limit the | frame size further to preserve space for other frames or to limit the | |||
capacity that acknowledgments consume. | capacity that acknowledgments consume. | |||
A receiver MUST retain an ACK Range unless it can ensure that it will | A receiver MUST retain an ACK Range unless it can ensure that it will | |||
not subsequently accept packets with numbers in that range. | not subsequently accept packets with numbers in that range. | |||
Maintaining a minimum packet number that increases as ranges are | Maintaining a minimum packet number that increases as ranges are | |||
discarded is one way to achieve this with minimal state. | discarded is one way to achieve this with minimal state. | |||
Receivers can discard all ACK Ranges, but they MUST retain the | Receivers can discard all ACK Ranges, but they MUST retain the | |||
largest packet number that has been successfully processed as that is | largest packet number that has been successfully processed, as that | |||
used to recover packet numbers from subsequent packets; see | is used to recover packet numbers from subsequent packets; see | |||
Section 17.1. | Section 17.1. | |||
A receiver SHOULD include an ACK Range containing the largest | A receiver SHOULD include an ACK Range containing the largest | |||
received packet number in every ACK frame. The Largest Acknowledged | received packet number in every ACK frame. The Largest Acknowledged | |||
field is used in ECN validation at a sender and including a lower | field is used in ECN validation at a sender, and including a lower | |||
value than what was included in a previous ACK frame could cause ECN | value than what was included in a previous ACK frame could cause ECN | |||
to be unnecessarily disabled; see Section 13.4.2. | to be unnecessarily disabled; see Section 13.4.2. | |||
Section 13.2.4 describes an exemplary approach for determining what | Section 13.2.4 describes an exemplary approach for determining what | |||
packets to acknowledge in each ACK frame. Though the goal of this | packets to acknowledge in each ACK frame. Though the goal of this | |||
algorithm is to generate an acknowledgment for every packet that is | algorithm is to generate an acknowledgment for every packet that is | |||
processed, it is still possible for acknowledgments to be lost. | processed, it is still possible for acknowledgments to be lost. | |||
13.2.4. Limiting Ranges by Tracking ACK Frames | 13.2.4. Limiting Ranges by Tracking ACK Frames | |||
When a packet containing an ACK frame is sent, the largest | When a packet containing an ACK frame is sent, the Largest | |||
acknowledged in that frame can be saved. When a packet containing an | Acknowledged field in that frame can be saved. When a packet | |||
ACK frame is acknowledged, the receiver can stop acknowledging | containing an ACK frame is acknowledged, the receiver can stop | |||
packets less than or equal to the largest acknowledged in the sent | acknowledging packets less than or equal to the Largest Acknowledged | |||
ACK frame. | field in the sent ACK frame. | |||
A receiver that sends only non-ack-eliciting packets, such as ACK | A receiver that sends only non-ack-eliciting packets, such as ACK | |||
frames, might not receive an acknowledgment for a long period of | frames, might not receive an acknowledgment for a long period of | |||
time. This could cause the receiver to maintain state for a large | time. This could cause the receiver to maintain state for a large | |||
number of ACK frames for a long period of time, and ACK frames it | number of ACK frames for a long period of time, and ACK frames it | |||
sends could be unnecessarily large. In such a case, a receiver could | sends could be unnecessarily large. In such a case, a receiver could | |||
send a PING or other small ack-eliciting frame occasionally, such as | send a PING or other small ack-eliciting frame occasionally, such as | |||
once per round trip, to elicit an ACK from the peer. | once per round trip, to elicit an ACK from the peer. | |||
In cases without ACK frame loss, this algorithm allows for a minimum | In cases without ACK frame loss, this algorithm allows for a minimum | |||
of 1 RTT of reordering. In cases with ACK frame loss and reordering, | of 1 RTT of reordering. In cases with ACK frame loss and reordering, | |||
this approach does not guarantee that every acknowledgment is seen by | this approach does not guarantee that every acknowledgment is seen by | |||
the sender before it is no longer included in the ACK frame. Packets | the sender before it is no longer included in the ACK frame. Packets | |||
could be received out of order and all subsequent ACK frames | could be received out of order, and all subsequent ACK frames | |||
containing them could be lost. In this case, the loss recovery | containing them could be lost. In this case, the loss recovery | |||
algorithm could cause spurious retransmissions, but the sender will | algorithm could cause spurious retransmissions, but the sender will | |||
continue making forward progress. | continue making forward progress. | |||
13.2.5. Measuring and Reporting Host Delay | 13.2.5. Measuring and Reporting Host Delay | |||
An endpoint measures the delays intentionally introduced between the | An endpoint measures the delays intentionally introduced between the | |||
time the packet with the largest packet number is received and the | time the packet with the largest packet number is received and the | |||
time an acknowledgment is sent. The endpoint encodes this | time an acknowledgment is sent. The endpoint encodes this | |||
acknowledgment delay in the ACK Delay field of an ACK frame; see | acknowledgment delay in the ACK Delay field of an ACK frame; see | |||
skipping to change at page 94, line 14 ¶ | skipping to change at page 93, line 14 ¶ | |||
13.3. Retransmission of Information | 13.3. Retransmission of Information | |||
QUIC packets that are determined to be lost are not retransmitted | QUIC packets that are determined to be lost are not retransmitted | |||
whole. The same applies to the frames that are contained within lost | whole. The same applies to the frames that are contained within lost | |||
packets. Instead, the information that might be carried in frames is | packets. Instead, the information that might be carried in frames is | |||
sent again in new frames as needed. | sent again in new frames as needed. | |||
New frames and packets are used to carry information that is | New frames and packets are used to carry information that is | |||
determined to have been lost. In general, information is sent again | determined to have been lost. In general, information is sent again | |||
when a packet containing that information is determined to be lost | when a packet containing that information is determined to be lost, | |||
and sending ceases when a packet containing that information is | and sending ceases when a packet containing that information is | |||
acknowledged. | acknowledged. | |||
o Data sent in CRYPTO frames is retransmitted according to the rules | o Data sent in CRYPTO frames is retransmitted according to the rules | |||
in [QUIC-RECOVERY], until all data has been acknowledged. Data in | in [QUIC-RECOVERY], until all data has been acknowledged. Data in | |||
CRYPTO frames for Initial and Handshake packets is discarded when | CRYPTO frames for Initial and Handshake packets is discarded when | |||
keys for the corresponding packet number space are discarded. | keys for the corresponding packet number space are discarded. | |||
o Application data sent in STREAM frames is retransmitted in new | o Application data sent in STREAM frames is retransmitted in new | |||
STREAM frames unless the endpoint has sent a RESET_STREAM for that | STREAM frames unless the endpoint has sent a RESET_STREAM for that | |||
skipping to change at page 94, line 49 ¶ | skipping to change at page 93, line 49 ¶ | |||
The content of a RESET_STREAM frame MUST NOT change when it is | The content of a RESET_STREAM frame MUST NOT change when it is | |||
sent again. | sent again. | |||
o Similarly, a request to cancel stream transmission, as encoded in | o Similarly, a request to cancel stream transmission, as encoded in | |||
a STOP_SENDING frame, is sent until the receiving part of the | a STOP_SENDING frame, is sent until the receiving part of the | |||
stream enters either a "Data Recvd" or "Reset Recvd" state; see | stream enters either a "Data Recvd" or "Reset Recvd" state; see | |||
Section 3.5. | Section 3.5. | |||
o Connection close signals, including packets that contain | o Connection close signals, including packets that contain | |||
CONNECTION_CLOSE frames, are not sent again when packet loss is | CONNECTION_CLOSE frames, are not sent again when packet loss is | |||
detected, but as described in Section 10. | detected. Resending these signals is described in Section 10. | |||
o The current connection maximum data is sent in MAX_DATA frames. | o The current connection maximum data is sent in MAX_DATA frames. | |||
An updated value is sent in a MAX_DATA frame if the packet | An updated value is sent in a MAX_DATA frame if the packet | |||
containing the most recently sent MAX_DATA frame is declared lost, | containing the most recently sent MAX_DATA frame is declared lost | |||
or when the endpoint decides to update the limit. Care is | or when the endpoint decides to update the limit. Care is | |||
necessary to avoid sending this frame too often as the limit can | necessary to avoid sending this frame too often, as the limit can | |||
increase frequently and cause an unnecessarily large number of | increase frequently and cause an unnecessarily large number of | |||
MAX_DATA frames to be sent; see Section 4.2. | MAX_DATA frames to be sent; see Section 4.2. | |||
o The current maximum stream data offset is sent in MAX_STREAM_DATA | o The current maximum stream data offset is sent in MAX_STREAM_DATA | |||
frames. Like MAX_DATA, an updated value is sent when the packet | frames. Like MAX_DATA, an updated value is sent when the packet | |||
containing the most recent MAX_STREAM_DATA frame for a stream is | containing the most recent MAX_STREAM_DATA frame for a stream is | |||
lost or when the limit is updated, with care taken to prevent the | lost or when the limit is updated, with care taken to prevent the | |||
frame from being sent too often. An endpoint SHOULD stop sending | frame from being sent too often. An endpoint SHOULD stop sending | |||
MAX_STREAM_DATA frames when the receiving part of the stream | MAX_STREAM_DATA frames when the receiving part of the stream | |||
enters a "Size Known" or "Reset Recvd" state. | enters a "Size Known" or "Reset Recvd" state. | |||
o The limit on streams of a given type is sent in MAX_STREAMS | o The limit on streams of a given type is sent in MAX_STREAMS | |||
frames. Like MAX_DATA, an updated value is sent when a packet | frames. Like MAX_DATA, an updated value is sent when a packet | |||
containing the most recent MAX_STREAMS for a stream type frame is | containing the most recent MAX_STREAMS for a stream type frame is | |||
declared lost or when the limit is updated, with care taken to | declared lost or when the limit is updated, with care taken to | |||
prevent the frame from being sent too often. | prevent the frame from being sent too often. | |||
o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, | o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, | |||
and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection | and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection | |||
scope, STREAM_DATA_BLOCKED frames have stream scope, and | scope, STREAM_DATA_BLOCKED frames have stream scope, and | |||
STREAMS_BLOCKED frames are scoped to a specific stream type. New | STREAMS_BLOCKED frames are scoped to a specific stream type. A | |||
frames are sent if packets containing the most recent frame for a | new frame is sent if a packet containing the most recent frame for | |||
scope is lost, but only while the endpoint is blocked on the | a scope is lost, but only while the endpoint is blocked on the | |||
corresponding limit. These frames always include the limit that | corresponding limit. These frames always include the limit that | |||
is causing blocking at the time that they are transmitted. | is causing blocking at the time that they are transmitted. | |||
o A liveness or path validation check using PATH_CHALLENGE frames is | o A liveness or path validation check using PATH_CHALLENGE frames is | |||
sent periodically until a matching PATH_RESPONSE frame is received | sent periodically until a matching PATH_RESPONSE frame is received | |||
or until there is no remaining need for liveness or path | or until there is no remaining need for liveness or path | |||
validation checking. PATH_CHALLENGE frames include a different | validation checking. PATH_CHALLENGE frames include a different | |||
payload each time they are sent. | payload each time they are sent. | |||
o Responses to path validation using PATH_RESPONSE frames are sent | o Responses to path validation using PATH_RESPONSE frames are sent | |||
skipping to change at page 96, line 21 ¶ | skipping to change at page 95, line 21 ¶ | |||
acknowledged. | acknowledged. | |||
Endpoints SHOULD prioritize retransmission of data over sending new | Endpoints SHOULD prioritize retransmission of data over sending new | |||
data, unless priorities specified by the application indicate | data, unless priorities specified by the application indicate | |||
otherwise; see Section 2.3. | otherwise; see Section 2.3. | |||
Even though a sender is encouraged to assemble frames containing up- | Even though a sender is encouraged to assemble frames containing up- | |||
to-date information every time it sends a packet, it is not forbidden | to-date information every time it sends a packet, it is not forbidden | |||
to retransmit copies of frames from lost packets. A sender that | to retransmit copies of frames from lost packets. A sender that | |||
retransmits copies of frames needs to handle decreases in available | retransmits copies of frames needs to handle decreases in available | |||
payload size due to change in packet number length, connection ID | payload size due to changes in packet number length, connection ID | |||
length, and path MTU. A receiver MUST accept packets containing an | length, and path MTU. A receiver MUST accept packets containing an | |||
outdated frame, such as a MAX_DATA frame carrying a smaller maximum | outdated frame, such as a MAX_DATA frame carrying a smaller maximum | |||
data than one found in an older packet. | data value than one found in an older packet. | |||
A sender SHOULD avoid retransmitting information from packets once | A sender SHOULD avoid retransmitting information from packets once | |||
they are acknowledged. This includes packets that are acknowledged | they are acknowledged. This includes packets that are acknowledged | |||
after being declared lost, which can happen in the presence of | after being declared lost, which can happen in the presence of | |||
network reordering. Doing so requires senders to retain information | network reordering. Doing so requires senders to retain information | |||
about packets after they are declared lost. A sender can discard | about packets after they are declared lost. A sender can discard | |||
this information after a period of time elapses that adequately | this information after a period of time elapses that adequately | |||
allows for reordering, such as a PTO (Section 6.2 of | allows for reordering, such as a PTO (Section 6.2 of | |||
[QUIC-RECOVERY]), or on other events, such as reaching a memory | [QUIC-RECOVERY]), or based on other events, such as reaching a memory | |||
limit. | limit. | |||
Upon detecting losses, a sender MUST take appropriate congestion | Upon detecting losses, a sender MUST take appropriate congestion | |||
control action. The details of loss detection and congestion control | control action. The details of loss detection and congestion control | |||
are described in [QUIC-RECOVERY]. | are described in [QUIC-RECOVERY]. | |||
13.4. Explicit Congestion Notification | 13.4. Explicit Congestion Notification | |||
QUIC endpoints can use Explicit Congestion Notification (ECN) | QUIC endpoints can use ECN [RFC3168] to detect and respond to network | |||
[RFC3168] to detect and respond to network congestion. ECN allows an | congestion. ECN allows an endpoint to set an ECN-Capable Transport | |||
endpoint to set an ECT codepoint in the ECN field of an IP packet. A | (ECT) codepoint in the ECN field of an IP packet. A network node can | |||
network node can then indicate congestion by setting the CE codepoint | then indicate congestion by setting the ECN-CE codepoint in the ECN | |||
in the ECN field instead of dropping the packet [RFC8087]. Endpoints | field instead of dropping the packet [RFC8087]. Endpoints react to | |||
react to reported congestion by reducing their sending rate in | reported congestion by reducing their sending rate in response, as | |||
response, as described in [QUIC-RECOVERY]. | described in [QUIC-RECOVERY]. | |||
To enable ECN, a sending QUIC endpoint first determines whether a | To enable ECN, a sending QUIC endpoint first determines whether a | |||
path supports ECN marking and whether the peer reports the ECN values | path supports ECN marking and whether the peer reports the ECN values | |||
in received IP headers; see Section 13.4.2. | in received IP headers; see Section 13.4.2. | |||
13.4.1. Reporting ECN Counts | 13.4.1. Reporting ECN Counts | |||
Use of ECN requires the receiving endpoint to read the ECN field from | The use of ECN requires the receiving endpoint to read the ECN field | |||
an IP packet, which is not possible on all platforms. If an endpoint | from an IP packet, which is not possible on all platforms. If an | |||
does not implement ECN support or does not have access to received | endpoint does not implement ECN support or does not have access to | |||
ECN fields, it does not report ECN counts for packets it receives. | received ECN fields, it does not report ECN counts for packets it | |||
receives. | ||||
Even if an endpoint does not set an ECT field on packets it sends, | Even if an endpoint does not set an ECT field in packets it sends, | |||
the endpoint MUST provide feedback about ECN markings it receives, if | the endpoint MUST provide feedback about ECN markings it receives, if | |||
these are accessible. Failing to report the ECN counts will cause | these are accessible. Failing to report the ECN counts will cause | |||
the sender to disable use of ECN for this connection. | the sender to disable the use of ECN for this connection. | |||
On receiving an IP packet with an ECT(0), ECT(1) or CE codepoint, an | On receiving an IP packet with an ECT(0), ECT(1), or ECN-CE | |||
ECN-enabled endpoint accesses the ECN field and increases the | codepoint, an ECN-enabled endpoint accesses the ECN field and | |||
corresponding ECT(0), ECT(1), or CE count. These ECN counts are | increases the corresponding ECT(0), ECT(1), or ECN-CE count. These | |||
included in subsequent ACK frames; see Section 13.2 and Section 19.3. | ECN counts are included in subsequent ACK frames; see Sections 13.2 | |||
and 19.3. | ||||
Each packet number space maintains separate acknowledgment state and | Each packet number space maintains separate acknowledgment state and | |||
separate ECN counts. Coalesced QUIC packets (see Section 12.2) share | separate ECN counts. Coalesced QUIC packets (see Section 12.2) share | |||
the same IP header so the ECN counts are incremented once for each | the same IP header so the ECN counts are incremented once for each | |||
coalesced QUIC packet. | coalesced QUIC packet. | |||
For example, if one each of an Initial, Handshake, and 1-RTT QUIC | For example, if one each of an Initial, Handshake, and 1-RTT QUIC | |||
packet are coalesced into a single UDP datagram, the ECN counts for | packet are coalesced into a single UDP datagram, the ECN counts for | |||
all three packet number spaces will be incremented by one each, based | all three packet number spaces will be incremented by one each, based | |||
on the ECN field of the single IP header. | on the ECN field of the single IP header. | |||
skipping to change at page 97, line 46 ¶ | skipping to change at page 96, line 48 ¶ | |||
ECN counts are only incremented when QUIC packets from the received | ECN counts are only incremented when QUIC packets from the received | |||
IP packet are processed. As such, duplicate QUIC packets are not | IP packet are processed. As such, duplicate QUIC packets are not | |||
processed and do not increase ECN counts; see Section 21.10 for | processed and do not increase ECN counts; see Section 21.10 for | |||
relevant security concerns. | relevant security concerns. | |||
13.4.2. ECN Validation | 13.4.2. ECN Validation | |||
It is possible for faulty network devices to corrupt or erroneously | It is possible for faulty network devices to corrupt or erroneously | |||
drop packets that carry a non-zero ECN codepoint. To ensure | drop packets that carry a non-zero ECN codepoint. To ensure | |||
connectivity in the presence of such devices, an endpoint validates | connectivity in the presence of such devices, an endpoint validates | |||
the ECN counts for each network path and disables use of ECN on that | the ECN counts for each network path and disables the use of ECN on | |||
path if errors are detected. | that path if errors are detected. | |||
To perform ECN validation for a new path: | To perform ECN validation for a new path: | |||
o The endpoint sets an ECT(0) codepoint in the IP header of early | o The endpoint sets an ECT(0) codepoint in the IP header of early | |||
outgoing packets sent on a new path to the peer ([RFC8311]). | outgoing packets sent on a new path to the peer [RFC8311]. | |||
o The endpoint monitors whether all packets sent with an ECT | o The endpoint monitors whether all packets sent with an ECT | |||
codepoint are eventually deemed lost (Section 6 of | codepoint are eventually deemed lost (Section 6 of | |||
[QUIC-RECOVERY]), indicating that ECN validation has failed. | [QUIC-RECOVERY]), indicating that ECN validation has failed. | |||
If an endpoint has cause to expect that IP packets with an ECT | If an endpoint has cause to expect that IP packets with an ECT | |||
codepoint might be dropped by a faulty network element, the endpoint | codepoint might be dropped by a faulty network element, the endpoint | |||
could set an ECT codepoint for only the first ten outgoing packets on | could set an ECT codepoint for only the first ten outgoing packets on | |||
a path, or for a period of three PTOs (see Section 6.2 of | a path, or for a period of three PTOs (see Section 6.2 of | |||
[QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints | [QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints | |||
skipping to change at page 98, line 30 ¶ | skipping to change at page 97, line 33 ¶ | |||
one possible algorithm. | one possible algorithm. | |||
Other methods of probing paths for ECN support are possible, as are | Other methods of probing paths for ECN support are possible, as are | |||
different marking strategies. Implementations MAY use other methods | different marking strategies. Implementations MAY use other methods | |||
defined in RFCs; see [RFC8311]. Implementations that use the ECT(1) | defined in RFCs; see [RFC8311]. Implementations that use the ECT(1) | |||
codepoint need to perform ECN validation using the reported ECT(1) | codepoint need to perform ECN validation using the reported ECT(1) | |||
counts. | counts. | |||
13.4.2.1. Receiving ACK Frames with ECN Counts | 13.4.2.1. Receiving ACK Frames with ECN Counts | |||
Erroneous application of CE markings by the network can result in | Erroneous application of ECN-CE markings by the network can result in | |||
degraded connection performance. An endpoint that receives an ACK | degraded connection performance. An endpoint that receives an ACK | |||
frame with ECN counts therefore validates the counts before using | frame with ECN counts therefore validates the counts before using | |||
them. It performs this validation by comparing newly received counts | them. It performs this validation by comparing newly received counts | |||
against those from the last successfully processed ACK frame. Any | against those from the last successfully processed ACK frame. Any | |||
increase in the ECN counts is validated based on the ECN markings | increase in the ECN counts is validated based on the ECN markings | |||
that were applied to packets that are newly acknowledged in the ACK | that were applied to packets that are newly acknowledged in the ACK | |||
frame. | frame. | |||
If an ACK frame newly acknowledges a packet that the endpoint sent | If an ACK frame newly acknowledges a packet that the endpoint sent | |||
with either the ECT(0) or ECT(1) codepoint set, ECN validation fails | with either the ECT(0) or ECT(1) codepoint set, ECN validation fails | |||
skipping to change at page 99, line 36 ¶ | skipping to change at page 98, line 38 ¶ | |||
If validation fails, then the endpoint MUST disable ECN. It stops | If validation fails, then the endpoint MUST disable ECN. It stops | |||
setting the ECT codepoint in IP packets that it sends, assuming that | setting the ECT codepoint in IP packets that it sends, assuming that | |||
either the network path or the peer does not support ECN. | either the network path or the peer does not support ECN. | |||
Even if validation fails, an endpoint MAY revalidate ECN for the same | Even if validation fails, an endpoint MAY revalidate ECN for the same | |||
path at any later time in the connection. An endpoint could continue | path at any later time in the connection. An endpoint could continue | |||
to periodically attempt validation. | to periodically attempt validation. | |||
Upon successful validation, an endpoint MAY continue to set an ECT | Upon successful validation, an endpoint MAY continue to set an ECT | |||
codepoint in subsequent packets it sends, with the expectation that | codepoint in subsequent packets it sends, with the expectation that | |||
the path is ECN-capable. Network routing and path elements can | the path is ECN capable. Network routing and path elements can | |||
however change mid-connection; an endpoint MUST disable ECN if | change mid-connection; an endpoint MUST disable ECN if validation | |||
validation later fails. | later fails. | |||
14. Datagram Size | 14. Datagram Size | |||
A UDP datagram can include one or more QUIC packets. The datagram | A UDP datagram can include one or more QUIC packets. The datagram | |||
size refers to the total UDP payload size of a single UDP datagram | size refers to the total UDP payload size of a single UDP datagram | |||
carrying QUIC packets. The datagram size includes one or more QUIC | carrying QUIC packets. The datagram size includes one or more QUIC | |||
packet headers and protected payloads, but not the UDP or IP headers. | packet headers and protected payloads, but not the UDP or IP headers. | |||
The maximum datagram size is defined as the largest size of UDP | The maximum datagram size is defined as the largest size of UDP | |||
payload that can be sent across a network path using a single UDP | payload that can be sent across a network path using a single UDP | |||
datagram. QUIC MUST NOT be used if the network path cannot support a | datagram. QUIC MUST NOT be used if the network path cannot support a | |||
maximum datagram size of at least 1200 bytes. | maximum datagram size of at least 1200 bytes. | |||
QUIC assumes a minimum IP packet size of at least 1280 bytes. This | QUIC assumes a minimum IP packet size of at least 1280 bytes. This | |||
is the IPv6 minimum size ([IPv6]) and is also supported by most | is the IPv6 minimum size [IPv6] and is also supported by most modern | |||
modern IPv4 networks. Assuming the minimum IP header size of 40 | IPv4 networks. Assuming the minimum IP header size of 40 bytes for | |||
bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 | IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this | |||
bytes, this results in a maximum datagram size of 1232 bytes for IPv6 | results in a maximum datagram size of 1232 bytes for IPv6 and 1252 | |||
and 1252 bytes for IPv4. Thus, modern IPv4 and all IPv6 network | bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are | |||
paths are expected to be able to support QUIC. | expected to be able to support QUIC. | |||
Note: This requirement to support a UDP payload of 1200 bytes limits | Note: This requirement to support a UDP payload of 1200 bytes | |||
the space available for IPv6 extension headers to 32 bytes or IPv4 | limits the space available for IPv6 extension headers to 32 bytes | |||
options to 52 bytes if the path only supports the IPv6 minimum MTU | or IPv4 options to 52 bytes if the path only supports the IPv6 | |||
of 1280 bytes. This affects Initial packets and path validation. | minimum MTU of 1280 bytes. This affects Initial packets and path | |||
validation. | ||||
Any maximum datagram size larger than 1200 bytes can be discovered | Any maximum datagram size larger than 1200 bytes can be discovered | |||
using Path Maximum Transmission Unit Discovery (PMTUD; see | using Path Maximum Transmission Unit Discovery (PMTUD) (see | |||
Section 14.2.1) or Datagram Packetization Layer PMTU Discovery | Section 14.2.1) or Datagram Packetization Layer PMTU Discovery | |||
(DPLPMTUD; see Section 14.3). | (DPLPMTUD) (see Section 14.3). | |||
Enforcement of the max_udp_payload_size transport parameter | Enforcement of the max_udp_payload_size transport parameter | |||
(Section 18.2) might act as an additional limit on the maximum | (Section 18.2) might act as an additional limit on the maximum | |||
datagram size. A sender can avoid exceeding this limit, once the | datagram size. A sender can avoid exceeding this limit, once the | |||
value is known. However, prior to learning the value of the | value is known. However, prior to learning the value of the | |||
transport parameter, endpoints risk datagrams being lost if they send | transport parameter, endpoints risk datagrams being lost if they send | |||
datagrams larger than the smallest allowed maximum datagram size of | datagrams larger than the smallest allowed maximum datagram size of | |||
1200 bytes. | 1200 bytes. | |||
UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 | UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 | |||
([IPv4]), the DF bit MUST be set if possible, to prevent | [IPv4], the Don't Fragment (DF) bit MUST be set if possible, to | |||
fragmentation on the path. | prevent fragmentation on the path. | |||
QUIC sometimes requires datagrams to be no smaller than a certain | QUIC sometimes requires datagrams to be no smaller than a certain | |||
size; see Section 8.1 as an example. However, the size of a datagram | size; see Section 8.1 as an example. However, the size of a datagram | |||
is not authenticated. That is, if an endpoint receives a datagram of | is not authenticated. That is, if an endpoint receives a datagram of | |||
a certain size, it cannot know that the sender sent the datagram at | a certain size, it cannot know that the sender sent the datagram at | |||
the same size. Therefore, an endpoint MUST NOT close a connection | the same size. Therefore, an endpoint MUST NOT close a connection | |||
when it receives a datagram that does not meet size constraints; the | when it receives a datagram that does not meet size constraints; the | |||
endpoint MAY however discard such datagrams. | endpoint MAY discard such datagrams. | |||
14.1. Initial Datagram Size | 14.1. Initial Datagram Size | |||
A client MUST expand the payload of all UDP datagrams carrying | A client MUST expand the payload of all UDP datagrams carrying | |||
Initial packets to at least the smallest allowed maximum datagram | Initial packets to at least the smallest allowed maximum datagram | |||
size of 1200 bytes by adding PADDING frames to the Initial packet or | size of 1200 bytes by adding PADDING frames to the Initial packet or | |||
by coalescing the Initial packet; see Section 12.2. Initial packets | by coalescing the Initial packet; see Section 12.2. Initial packets | |||
can even be coalesced with invalid packets, which a receiver will | can even be coalesced with invalid packets, which a receiver will | |||
discard. Similarly, a server MUST expand the payload of all UDP | discard. Similarly, a server MUST expand the payload of all UDP | |||
datagrams carrying ack-eliciting Initial packets to at least the | datagrams carrying ack-eliciting Initial packets to at least the | |||
skipping to change at page 101, line 26 ¶ | skipping to change at page 100, line 30 ¶ | |||
datagram with a payload that is smaller than the smallest allowed | datagram with a payload that is smaller than the smallest allowed | |||
maximum datagram size of 1200 bytes. A server MAY also immediately | maximum datagram size of 1200 bytes. A server MAY also immediately | |||
close the connection by sending a CONNECTION_CLOSE frame with an | close the connection by sending a CONNECTION_CLOSE frame with an | |||
error code of PROTOCOL_VIOLATION; see Section 10.2.3. | error code of PROTOCOL_VIOLATION; see Section 10.2.3. | |||
The server MUST also limit the number of bytes it sends before | The server MUST also limit the number of bytes it sends before | |||
validating the address of the client; see Section 8. | validating the address of the client; see Section 8. | |||
14.2. Path Maximum Transmission Unit | 14.2. Path Maximum Transmission Unit | |||
The Path Maximum Transmission Unit (PMTU) is the maximum size of the | The PMTU is the maximum size of the entire IP packet, including the | |||
entire IP packet including the IP header, UDP header, and UDP | IP header, UDP header, and UDP payload. The UDP payload includes one | |||
payload. The UDP payload includes one or more QUIC packet headers | or more QUIC packet headers and protected payloads. The PMTU can | |||
and protected payloads. The PMTU can depend on path characteristics, | depend on path characteristics and can therefore change over time. | |||
and can therefore change over time. The largest UDP payload an | The largest UDP payload an endpoint sends at any given time is | |||
endpoint sends at any given time is referred to as the endpoint's | referred to as the endpoint's maximum datagram size. | |||
maximum datagram size. | ||||
An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD | An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD | |||
(Section 14.2.1) to determine whether the path to a destination will | (Section 14.2.1) to determine whether the path to a destination will | |||
support a desired maximum datagram size without fragmentation. In | support a desired maximum datagram size without fragmentation. In | |||
the absence of these mechanisms, QUIC endpoints SHOULD NOT send | the absence of these mechanisms, QUIC endpoints SHOULD NOT send | |||
datagrams larger than the smallest allowed maximum datagram size. | datagrams larger than the smallest allowed maximum datagram size. | |||
Both DPLPMTUD and PMTUD send datagrams that are larger than the | Both DPLPMTUD and PMTUD send datagrams that are larger than the | |||
current maximum datagram size, referred to as PMTU probes. All QUIC | current maximum datagram size, referred to as PMTU probes. All QUIC | |||
packets that are not sent in a PMTU probe SHOULD be sized to fit | packets that are not sent in a PMTU probe SHOULD be sized to fit | |||
within the maximum datagram size to avoid the datagram being | within the maximum datagram size to avoid the datagram being | |||
fragmented or dropped ([RFC8085]). | fragmented or dropped [RFC8085]. | |||
If a QUIC endpoint determines that the PMTU between any pair of local | If a QUIC endpoint determines that the PMTU between any pair of local | |||
and remote IP addresses cannot support the smallest allowed maximum | and remote IP addresses cannot support the smallest allowed maximum | |||
datagram size of 1200 bytes, it MUST immediately cease sending QUIC | datagram size of 1200 bytes, it MUST immediately cease sending QUIC | |||
packets, except for those in PMTU probes or those containing | packets, except for those in PMTU probes or those containing | |||
CONNECTION_CLOSE frames, on the affected path. An endpoint MAY | CONNECTION_CLOSE frames, on the affected path. An endpoint MAY | |||
terminate the connection if an alternative path cannot be found. | terminate the connection if an alternative path cannot be found. | |||
Each pair of local and remote addresses could have a different PMTU. | Each pair of local and remote addresses could have a different PMTU. | |||
QUIC implementations that implement any kind of PMTU discovery | QUIC implementations that implement any kind of PMTU discovery | |||
therefore SHOULD maintain a maximum datagram size for each | therefore SHOULD maintain a maximum datagram size for each | |||
combination of local and remote IP addresses. | combination of local and remote IP addresses. | |||
A QUIC implementation MAY be more conservative in computing the | A QUIC implementation MAY be more conservative in computing the | |||
maximum datagram size to allow for unknown tunnel overheads or IP | maximum datagram size to allow for unknown tunnel overheads or IP | |||
header options/extensions. | header options/extensions. | |||
14.2.1. Handling of ICMP Messages by PMTUD | 14.2.1. Handling of ICMP Messages by PMTUD | |||
Path Maximum Transmission Unit Discovery (PMTUD; [RFC1191], | PMTUD [RFC1191] [RFC8201] relies on reception of ICMP messages (that | |||
[RFC8201]) relies on reception of ICMP messages (e.g., IPv6 Packet | is, IPv6 Packet Too Big (PTB) messages) that indicate when an IP | |||
Too Big messages) that indicate when an IP packet is dropped because | packet is dropped because it is larger than the local router MTU. | |||
it is larger than the local router MTU. DPLPMTUD can also optionally | DPLPMTUD can also optionally use these messages. This use of ICMP | |||
use these messages. This use of ICMP messages is potentially | messages is potentially vulnerable to attacks by entities that cannot | |||
vulnerable to attacks by entities that cannot observe packets but | observe packets but might successfully guess the addresses used on | |||
might successfully guess the addresses used on the path. These | the path. These attacks could reduce the PMTU to a bandwidth- | |||
attacks could reduce the PMTU to a bandwidth-inefficient value. | inefficient value. | |||
An endpoint MUST ignore an ICMP message that claims the PMTU has | An endpoint MUST ignore an ICMP message that claims the PMTU has | |||
decreased below QUIC's smallest allowed maximum datagram size. | decreased below QUIC's smallest allowed maximum datagram size. | |||
The requirements for generating ICMP ([RFC1812], [RFC4443]) state | The requirements for generating ICMP [RFC1812] [RFC4443] state that | |||
that the quoted packet should contain as much of the original packet | the quoted packet should contain as much of the original packet as | |||
as possible without exceeding the minimum MTU for the IP version. | possible without exceeding the minimum MTU for the IP version. The | |||
The size of the quoted packet can actually be smaller, or the | size of the quoted packet can actually be smaller, or the information | |||
information unintelligible, as described in Section 1.1 of | unintelligible, as described in Section 1.1 of [DPLPMTUD]. | |||
[DPLPMTUD]. | ||||
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect | QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect | |||
from packet injection as specified in [RFC8201] and Section 5.2 of | from packet injection as specified in [RFC8201] and Section 5.2 of | |||
[RFC8085]. This validation SHOULD use the quoted packet supplied in | [RFC8085]. This validation SHOULD use the quoted packet supplied in | |||
the payload of an ICMP message to associate the message with a | the payload of an ICMP message to associate the message with a | |||
corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). | corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). | |||
ICMP message validation MUST include matching IP addresses and UDP | ICMP message validation MUST include matching IP addresses and UDP | |||
ports ([RFC8085]) and, when possible, connection IDs to an active | ports [RFC8085] and, when possible, connection IDs to an active QUIC | |||
QUIC session. The endpoint SHOULD ignore all ICMP messages that fail | session. The endpoint SHOULD ignore all ICMP messages that fail | |||
validation. | validation. | |||
An endpoint MUST NOT increase PMTU based on ICMP messages; see | An endpoint MUST NOT increase the PMTU based on ICMP messages; see | |||
Section 3, clause 6 of [DPLPMTUD]. Any reduction in QUIC's maximum | Item 6 in Section 3 of [DPLPMTUD]. Any reduction in QUIC's maximum | |||
datagram size in response to ICMP messages MAY be provisional until | datagram size in response to ICMP messages MAY be provisional until | |||
QUIC's loss detection algorithm determines that the quoted packet has | QUIC's loss detection algorithm determines that the quoted packet has | |||
actually been lost. | actually been lost. | |||
14.3. Datagram Packetization Layer PMTU Discovery | 14.3. Datagram Packetization Layer PMTU Discovery | |||
Datagram Packetization Layer PMTU Discovery (DPLPMTUD; [DPLPMTUD]) | DPLPMTUD [DPLPMTUD] relies on tracking loss or acknowledgment of QUIC | |||
relies on tracking loss or acknowledgment of QUIC packets that are | packets that are carried in PMTU probes. PMTU probes for DPLPMTUD | |||
carried in PMTU probes. PMTU probes for DPLPMTUD that use the | that use the PADDING frame implement "Probing using padding data", as | |||
PADDING frame implement "Probing using padding data", as defined in | defined in Section 4.1 of [DPLPMTUD]. | |||
Section 4.1 of [DPLPMTUD]. | ||||
Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of | Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of | |||
[DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum | [DPLPMTUD]) to be consistent with QUIC's smallest allowed maximum | |||
datagram size. The MIN_PLPMTU is the same as the BASE_PLPMTU. | datagram size. The MIN_PLPMTU is the same as the BASE_PLPMTU. | |||
QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum | QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum | |||
Packet Size (MPS, Section 4.4 of [DPLPMTUD]) for each combination of | Packet Size (MPS) (Section 4.4 of [DPLPMTUD]) for each combination of | |||
local and remote IP addresses. This corresponds to the maximum | local and remote IP addresses. This corresponds to the maximum | |||
datagram size. | datagram size. | |||
14.3.1. DPLPMTUD and Initial Connectivity | 14.3.1. DPLPMTUD and Initial Connectivity | |||
From the perspective of DPLPMTUD, QUIC is an acknowledged | From the perspective of DPLPMTUD, QUIC is an acknowledged | |||
Packetization Layer (PL). A QUIC sender can therefore enter the | Packetization Layer (PL). A QUIC sender can therefore enter the | |||
DPLPMTUD BASE state (Section 5.2 of [DPLPMTUD]) when the QUIC | DPLPMTUD BASE state (Section 5.2 of [DPLPMTUD]) when the QUIC | |||
connection handshake has been completed. | connection handshake has been completed. | |||
14.3.2. Validating the Network Path with DPLPMTUD | 14.3.2. Validating the Network Path with DPLPMTUD | |||
QUIC is an acknowledged PL, therefore a QUIC sender does not | QUIC is an acknowledged PL; therefore, a QUIC sender does not | |||
implement a DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE | implement a DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE | |||
state; see Section 5.2 of [DPLPMTUD]. | state; see Section 5.2 of [DPLPMTUD]. | |||
14.3.3. Handling of ICMP Messages by DPLPMTUD | 14.3.3. Handling of ICMP Messages by DPLPMTUD | |||
An endpoint using DPLPMTUD requires the validation of any received | An endpoint using DPLPMTUD requires the validation of any received | |||
ICMP Packet Too Big (PTB) message before using the PTB information, | ICMP PTB message before using the PTB information, as defined in | |||
as defined in Section 4.6 of [DPLPMTUD]. In addition to UDP port | Section 4.6 of [DPLPMTUD]. In addition to UDP port validation, QUIC | |||
validation, QUIC validates an ICMP message by using other PL | validates an ICMP message by using other PL information (e.g., | |||
information (e.g., validation of connection IDs in the quoted packet | validation of connection IDs in the quoted packet of any received | |||
of any received ICMP message). | ICMP message). | |||
The considerations for processing ICMP messages described in | The considerations for processing ICMP messages described in | |||
Section 14.2.1 also apply if these messages are used by DPLPMTUD. | Section 14.2.1 also apply if these messages are used by DPLPMTUD. | |||
14.4. Sending QUIC PMTU Probes | 14.4. Sending QUIC PMTU Probes | |||
PMTU probes are ack-eliciting packets. | PMTU probes are ack-eliciting packets. | |||
Endpoints could limit the content of PMTU probes to PING and PADDING | Endpoints could limit the content of PMTU probes to PING and PADDING | |||
frames, since packets that are larger than the current maximum | frames, since packets that are larger than the current maximum | |||
datagram size are more likely to be dropped by the network. Loss of | datagram size are more likely to be dropped by the network. Loss of | |||
a QUIC packet that is carried in a PMTU probe is therefore not a | a QUIC packet that is carried in a PMTU probe is therefore not a | |||
reliable indication of congestion and SHOULD NOT trigger a congestion | reliable indication of congestion and SHOULD NOT trigger a congestion | |||
control reaction; see Section 3, Bullet 7 of [DPLPMTUD]. However, | control reaction; see Item 7 in Section 3 of [DPLPMTUD]. However, | |||
PMTU probes consume congestion window, which could delay subsequent | PMTU probes consume congestion window, which could delay subsequent | |||
transmission by an application. | transmission by an application. | |||
14.4.1. PMTU Probes Containing Source Connection ID | 14.4.1. PMTU Probes Containing Source Connection ID | |||
Endpoints that rely on the destination connection ID for routing | Endpoints that rely on the Destination Connection ID field for | |||
incoming QUIC packets are likely to require that the connection ID be | routing incoming QUIC packets are likely to require that the | |||
included in PMTU probes to route any resulting ICMP messages | connection ID be included in PMTU probes to route any resulting ICMP | |||
(Section 14.2.1) back to the correct endpoint. However, only long | messages (Section 14.2.1) back to the correct endpoint. However, | |||
header packets (Section 17.2) contain the Source Connection ID field, | only long header packets (Section 17.2) contain the Source Connection | |||
and long header packets are not decrypted or acknowledged by the peer | ID field, and long header packets are not decrypted or acknowledged | |||
once the handshake is complete. | by the peer once the handshake is complete. | |||
One way to construct a PMTU probe is to coalesce (see Section 12.2) a | One way to construct a PMTU probe is to coalesce (see Section 12.2) a | |||
packet with a long header, such as a Handshake or 0-RTT packet | packet with a long header, such as a Handshake or 0-RTT packet | |||
(Section 17.2), with a short header packet in a single UDP datagram. | (Section 17.2), with a short header packet in a single UDP datagram. | |||
If the resulting PMTU probe reaches the endpoint, the packet with the | If the resulting PMTU probe reaches the endpoint, the packet with the | |||
long header will be ignored, but the short header packet will be | long header will be ignored, but the short header packet will be | |||
acknowledged. If the PMTU probe causes an ICMP message to be sent, | acknowledged. If the PMTU probe causes an ICMP message to be sent, | |||
the first part of the probe will be quoted in that message. If the | the first part of the probe will be quoted in that message. If the | |||
Source Connection ID field is within the quoted portion of the probe, | Source Connection ID field is within the quoted portion of the probe, | |||
that could be used for routing or validation of the ICMP message. | that could be used for routing or validation of the ICMP message. | |||
Note: The purpose of using a packet with a long header is only to | Note: The purpose of using a packet with a long header is only to | |||
ensure that the quoted packet contained in the ICMP message | ensure that the quoted packet contained in the ICMP message | |||
contains a Source Connection ID field. This packet does not need | contains a Source Connection ID field. This packet does not need | |||
to be a valid packet and it can be sent even if there is no | to be a valid packet, and it can be sent even if there is no | |||
current use for packets of that type. | current use for packets of that type. | |||
15. Versions | 15. Versions | |||
QUIC versions are identified using a 32-bit unsigned number. | QUIC versions are identified using a 32-bit unsigned number. | |||
The version 0x00000000 is reserved to represent version negotiation. | The version 0x00000000 is reserved to represent version negotiation. | |||
This version of the specification is identified by the number | This version of the specification is identified by the number | |||
0x00000001. | 0x00000001. | |||
skipping to change at page 105, line 9 ¶ | skipping to change at page 104, line 9 ¶ | |||
across all versions of the protocol are described in | across all versions of the protocol are described in | |||
[QUIC-INVARIANTS]. | [QUIC-INVARIANTS]. | |||
Version 0x00000001 of QUIC uses TLS as a cryptographic handshake | Version 0x00000001 of QUIC uses TLS as a cryptographic handshake | |||
protocol, as described in [QUIC-TLS]. | protocol, as described in [QUIC-TLS]. | |||
Versions with the most significant 16 bits of the version number | Versions with the most significant 16 bits of the version number | |||
cleared are reserved for use in future IETF consensus documents. | cleared are reserved for use in future IETF consensus documents. | |||
Versions that follow the pattern 0x?a?a?a?a are reserved for use in | 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 | forcing version negotiation to be exercised -- that is, any version | |||
number where the low four bits of all bytes is 1010 (in binary). A | 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 | client or server MAY advertise support for any of these reserved | |||
versions. | versions. | |||
Reserved version numbers will never represent a real protocol; a | Reserved version numbers will never represent a real protocol; a | |||
client MAY use one of these version numbers with the expectation that | client MAY use one of these version numbers with the expectation that | |||
the server will initiate version negotiation; a server MAY advertise | the server will initiate version negotiation; a server MAY advertise | |||
support for one of these versions and can expect that clients ignore | support for one of these versions and can expect that clients ignore | |||
the value. | the value. | |||
16. Variable-Length Integer Encoding | 16. Variable-Length Integer Encoding | |||
QUIC packets and frames commonly use a variable-length encoding for | QUIC packets and frames commonly use a variable-length encoding for | |||
non-negative integer values. This encoding ensures that smaller | non-negative integer values. This encoding ensures that smaller | |||
integer values need fewer bytes to encode. | integer values need fewer bytes to encode. | |||
The QUIC variable-length integer encoding reserves the two most | The QUIC variable-length integer encoding reserves the two most | |||
significant bits of the first byte to encode the base 2 logarithm of | significant bits of the first byte to encode the base-2 logarithm of | |||
the integer encoding length in bytes. The integer value is encoded | the integer encoding length in bytes. The integer value is encoded | |||
on the remaining bits, in network byte order. | on the remaining bits, in network byte order. | |||
This means that integers are encoded on 1, 2, 4, or 8 bytes and can | This means that integers are encoded on 1, 2, 4, or 8 bytes and can | |||
encode 6-, 14-, 30-, or 62-bit values respectively. Table 4 | encode 6-, 14-, 30-, or 62-bit values, respectively. Table 4 | |||
summarizes the encoding properties. | summarizes the encoding properties. | |||
+------+--------+-------------+-----------------------+ | +------+--------+-------------+-----------------------+ | |||
| 2Bit | Length | Usable Bits | Range | | | 2MSB | Length | Usable Bits | Range | | |||
+------+--------+-------------+-----------------------+ | +------+--------+-------------+-----------------------+ | |||
| 00 | 1 | 6 | 0-63 | | | 00 | 1 | 6 | 0-63 | | |||
| | | | | | | | | | | | |||
| 01 | 2 | 14 | 0-16383 | | | 01 | 2 | 14 | 0-16383 | | |||
| | | | | | | | | | | | |||
| 10 | 4 | 30 | 0-1073741823 | | | 10 | 4 | 30 | 0-1073741823 | | |||
| | | | | | | | | | | | |||
| 11 | 8 | 62 | 0-4611686018427387903 | | | 11 | 8 | 62 | 0-4611686018427387903 | | |||
+------+--------+-------------+-----------------------+ | +------+--------+-------------+-----------------------+ | |||
Table 4: Summary of Integer Encodings | Table 4: Summary of Integer Encodings | |||
Examples and a sample decoding algorithm are shown in Appendix A.1. | An example of a decoding algorithm and sample encodings are shown in | |||
Appendix A.1. | ||||
Values do not need to be encoded on the minimum number of bytes | Values do not need to be encoded on the minimum number of bytes | |||
necessary, with the sole exception of the Frame Type field; see | necessary, with the sole exception of the Frame Type field; see | |||
Section 12.4. | Section 12.4. | |||
Versions (Section 15), packet numbers sent in the header | Versions (Section 15), packet numbers sent in the header | |||
(Section 17.1), and the length of connection IDs in long header | (Section 17.1), and the length of connection IDs in long header | |||
packets (Section 17.2) are described using integers, but do not use | packets (Section 17.2) are described using integers but do not use | |||
this encoding. | this encoding. | |||
17. Packet Formats | 17. Packet Formats | |||
All numeric values are encoded in network byte order (that is, big- | All numeric values are encoded in network byte order (that is, big | |||
endian) and all field sizes are in bits. Hexadecimal notation is | endian), and all field sizes are in bits. Hexadecimal notation is | |||
used for describing the value of fields. | used for describing the value of fields. | |||
17.1. Packet Number Encoding and Decoding | 17.1. Packet Number Encoding and Decoding | |||
Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). | Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). | |||
When present in long or short packet headers, they are encoded in 1 | When present in long or short packet headers, they are encoded in 1 | |||
to 4 bytes. The number of bits required to represent the packet | to 4 bytes. The number of bits required to represent the packet | |||
number is reduced by including only the least significant bits of the | number is reduced by including only the least significant bits of the | |||
packet number. | packet number. | |||
The encoded packet number is protected as described in Section 5.4 of | The encoded packet number is protected as described in Section 5.4 of | |||
[QUIC-TLS]. | [QUIC-TLS]. | |||
Prior to receiving an acknowledgment for a packet number space, the | Prior to receiving an acknowledgment for a packet number space, the | |||
full packet number MUST be included; it is not to be truncated as | full packet number MUST be included; it is not to be truncated, as | |||
described below. | described below. | |||
After an acknowledgment is received for a packet number space, the | After an acknowledgment is received for a packet number space, the | |||
sender MUST use a packet number size able to represent more than | sender MUST use a packet number size able to represent more than | |||
twice as large a range than the difference between the largest | twice as large a range as the difference between the largest | |||
acknowledged packet and packet number being sent. A peer receiving | acknowledged packet number and the packet number being sent. A peer | |||
the packet will then correctly decode the packet number, unless the | receiving the packet will then correctly decode the packet number, | |||
packet is delayed in transit such that it arrives after many higher- | unless the packet is delayed in transit such that it arrives after | |||
numbered packets have been received. An endpoint SHOULD use a large | many higher-numbered packets have been received. An endpoint SHOULD | |||
enough packet number encoding to allow the packet number to be | use a large enough packet number encoding to allow the packet number | |||
recovered even if the packet arrives after packets that are sent | to be recovered even if the packet arrives after packets that are | |||
afterwards. | sent afterwards. | |||
As a result, the size of the packet number encoding is at least one | As a result, the size of the packet number encoding is at least one | |||
bit more than the base-2 logarithm of the number of contiguous | bit more than the base-2 logarithm of the number of contiguous | |||
unacknowledged packet numbers, including the new packet. Pseudocode | unacknowledged packet numbers, including the new packet. Pseudocode | |||
and examples for packet number encoding can be found in Appendix A.2. | and an example for packet number encoding can be found in | |||
Appendix A.2. | ||||
At a receiver, protection of the packet number is removed prior to | At a receiver, protection of the packet number is removed prior to | |||
recovering the full packet number. The full packet number is then | recovering the full packet number. The full packet number is then | |||
reconstructed based on the number of significant bits present, the | reconstructed based on the number of significant bits present, the | |||
value of those bits, and the largest packet number received in a | value of those bits, and the largest packet number received in a | |||
successfully authenticated packet. Recovering the full packet number | successfully authenticated packet. Recovering the full packet number | |||
is necessary to successfully remove packet protection. | is necessary to successfully complete the removal of packet | |||
protection. | ||||
Once header protection is removed, the packet number is decoded by | Once header protection is removed, the packet number is decoded by | |||
finding the packet number value that is closest to the next expected | finding the packet number value that is closest to the next expected | |||
packet. The next expected packet is the highest received packet | packet. The next expected packet is the highest received packet | |||
number plus one. Pseudocode and an example for packet number | number plus one. Pseudocode and an example for packet number | |||
decoding can be found in Appendix A.3. | decoding can be found in Appendix A.3. | |||
17.2. Long Header Packets | 17.2. Long Header Packets | |||
Long Header Packet { | Long Header Packet { | |||
skipping to change at page 107, line 35 ¶ | skipping to change at page 106, line 39 ¶ | |||
Source Connection ID Length (8), | Source Connection ID Length (8), | |||
Source Connection ID (0..160), | Source Connection ID (0..160), | |||
Type-Specific Payload (..), | Type-Specific Payload (..), | |||
} | } | |||
Figure 13: Long Header Packet Format | Figure 13: Long Header Packet Format | |||
Long headers are used for packets that are sent prior to the | Long headers are used for packets that are sent prior to the | |||
establishment of 1-RTT keys. Once 1-RTT keys are available, a sender | establishment of 1-RTT keys. Once 1-RTT keys are available, a sender | |||
switches to sending packets using the short header (Section 17.3). | switches to sending packets using the short header (Section 17.3). | |||
The long form allows for special packets - such as the Version | The long form allows for special packets -- such as the Version | |||
Negotiation packet - to be represented in this uniform fixed-length | Negotiation packet -- to be represented in this uniform fixed-length | |||
packet format. Packets that use the long header contain the | packet format. Packets that use the long header contain the | |||
following fields: | following fields: | |||
Header Form: The most significant bit (0x80) of byte 0 (the first | Header Form: The most significant bit (0x80) of byte 0 (the first | |||
byte) is set to 1 for long headers. | byte) is set to 1 for long headers. | |||
Fixed Bit: The next bit (0x40) of byte 0 is set to 1, unless the | Fixed Bit: The next bit (0x40) of byte 0 is set to 1, unless the | |||
packet is a Version Negotiation packet. Packets containing a zero | packet is a Version Negotiation packet. Packets containing a zero | |||
value for this bit are not valid packets in this version and MUST | value for this bit are not valid packets in this version and MUST | |||
be discarded. A value of 1 for this bit allows QUIC to coexist | be discarded. A value of 1 for this bit allows QUIC to coexist | |||
skipping to change at page 108, line 16 ¶ | skipping to change at page 107, line 19 ¶ | |||
a mask of 0x0f) of byte 0 are determined by the packet type. | a mask of 0x0f) of byte 0 are determined by the packet type. | |||
Version: The QUIC Version is a 32-bit field that follows the first | Version: The QUIC Version is a 32-bit field that follows the first | |||
byte. This field indicates the version of QUIC that is in use and | byte. This field indicates the version of QUIC that is in use and | |||
determines how the rest of the protocol fields are interpreted. | determines how the rest of the protocol fields are interpreted. | |||
Destination Connection ID Length: The byte following the version | Destination Connection ID Length: The byte following the version | |||
contains the length in bytes of the Destination Connection ID | contains the length in bytes of the Destination Connection ID | |||
field that follows it. This length is encoded as an 8-bit | field that follows it. This length is encoded as an 8-bit | |||
unsigned integer. In QUIC version 1, this value MUST NOT exceed | unsigned integer. In QUIC version 1, this value MUST NOT exceed | |||
20. Endpoints that receive a version 1 long header with a value | 20 bytes. Endpoints that receive a version 1 long header with a | |||
larger than 20 MUST drop the packet. In order to properly form a | value larger than 20 MUST drop the packet. In order to properly | |||
Version Negotiation packet, servers SHOULD be able to read longer | form a Version Negotiation packet, servers SHOULD be able to read | |||
connection IDs from other QUIC versions. | longer connection IDs from other QUIC versions. | |||
Destination Connection ID: The Destination Connection ID field | Destination Connection ID: The Destination Connection ID field | |||
follows the Destination Connection ID Length field, which | follows the Destination Connection ID Length field, which | |||
indicates the length of this field. Section 7.2 describes the use | indicates the length of this field. Section 7.2 describes the use | |||
of this field in more detail. | of this field in more detail. | |||
Source Connection ID Length: The byte following the Destination | Source Connection ID Length: The byte following the Destination | |||
Connection ID contains the length in bytes of the Source | Connection ID contains the length in bytes of the Source | |||
Connection ID field that follows it. This length is encoded as a | Connection ID field that follows it. This length is encoded as an | |||
8-bit unsigned integer. In QUIC version 1, this value MUST NOT | 8-bit unsigned integer. In QUIC version 1, this value MUST NOT | |||
exceed 20 bytes. Endpoints that receive a version 1 long header | exceed 20 bytes. Endpoints that receive a version 1 long header | |||
with a value larger than 20 MUST drop the packet. In order to | with a value larger than 20 MUST drop the packet. In order to | |||
properly form a Version Negotiation packet, servers SHOULD be able | properly form a Version Negotiation packet, servers SHOULD be able | |||
to read longer connection IDs from other QUIC versions. | to read longer connection IDs from other QUIC versions. | |||
Source Connection ID: The Source Connection ID field follows the | Source Connection ID: The Source Connection ID field follows the | |||
Source Connection ID Length field, which indicates the length of | Source Connection ID Length field, which indicates the length of | |||
this field. Section 7.2 describes the use of this field in more | this field. Section 7.2 describes the use of this field in more | |||
detail. | detail. | |||
Type-Specific Payload: The remainder of the packet, if any, is type- | Type-Specific Payload: The remainder of the packet, if any, is type | |||
specific. | specific. | |||
In this version of QUIC, the following packet types with the long | In this version of QUIC, the following packet types with the long | |||
header are defined: | header are defined: | |||
+------+-----------+-----------------+ | +------+-----------+-----------------+ | |||
| Type | Name | Section | | | Type | Name | Section | | |||
+------+-----------+-----------------+ | +------+-----------+-----------------+ | |||
| 0x0 | Initial | Section 17.2.2 | | | 0x00 | Initial | Section 17.2.2 | | |||
| | | | | | | | | | |||
| 0x1 | 0-RTT | Section 17.2.3 | | | 0x01 | 0-RTT | Section 17.2.3 | | |||
| | | | | | | | | | |||
| 0x2 | Handshake | Section 17.2.4 | | | 0x02 | Handshake | Section 17.2.4 | | |||
| | | | | | | | | | |||
| 0x3 | Retry | Section 17.2.5 | | | 0x03 | Retry | Section 17.2.5 | | |||
+------+-----------+-----------------+ | +------+-----------+-----------------+ | |||
Table 5: Long Header Packet Types | Table 5: Long Header Packet Types | |||
The header form bit, Destination and Source Connection ID lengths, | The header form bit, Destination and Source Connection ID lengths, | |||
Destination and Source Connection ID fields, and Version fields of a | Destination and Source Connection ID fields, and Version fields of a | |||
long header packet are version-independent. The other fields in the | long header packet are version independent. The other fields in the | |||
first byte are version-specific. See [QUIC-INVARIANTS] for details | first byte are version specific. See [QUIC-INVARIANTS] for details | |||
on how packets from different versions of QUIC are interpreted. | on how packets from different versions of QUIC are interpreted. | |||
The interpretation of the fields and the payload are specific to a | The interpretation of the fields and the payload are specific to a | |||
version and packet type. While type-specific semantics for this | version and packet type. While type-specific semantics for this | |||
version are described in the following sections, several long-header | version are described in the following sections, several long header | |||
packets in this version of QUIC contain these additional fields: | packets in this version of QUIC contain these additional fields: | |||
Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are | Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are | |||
reserved across multiple packet types. These bits are protected | reserved across multiple packet types. These bits are protected | |||
using header protection; see Section 5.4 of [QUIC-TLS]. The value | using header protection; see Section 5.4 of [QUIC-TLS]. The value | |||
included prior to protection MUST be set to 0. An endpoint MUST | included prior to protection MUST be set to 0. An endpoint MUST | |||
treat receipt of a packet that has a non-zero value for these bits | treat receipt of a packet that has a non-zero value for these bits | |||
after removing both packet and header protection as a connection | after removing both packet and header protection as a connection | |||
error of type PROTOCOL_VIOLATION. Discarding such a packet after | error of type PROTOCOL_VIOLATION. Discarding such a packet after | |||
only removing header protection can expose the endpoint to | only removing header protection can expose the endpoint to | |||
attacks; see Section 9.5 of [QUIC-TLS]. | attacks; see Section 9.5 of [QUIC-TLS]. | |||
Packet Number Length: In packet types that contain a Packet Number | Packet Number Length: In packet types that contain a Packet Number | |||
field, the least significant two bits (those with a mask of 0x03) | field, the least significant two bits (those with a mask of 0x03) | |||
of byte 0 contain the length of the packet number, encoded as an | of byte 0 contain the length of the Packet Number field, encoded | |||
unsigned, two-bit integer that is one less than the length of the | as an unsigned two-bit integer that is one less than the length of | |||
packet number field in bytes. That is, the length of the packet | the Packet Number field in bytes. That is, the length of the | |||
number field is the value of this field, plus one. These bits are | Packet Number field is the value of this field plus one. These | |||
protected using header protection; see Section 5.4 of [QUIC-TLS]. | bits are protected using header protection; see Section 5.4 of | |||
[QUIC-TLS]. | ||||
Length: The length of the remainder of the packet (that is, the | Length: This is the length of the remainder of the packet (that is, | |||
Packet Number and Payload fields) in bytes, encoded as a variable- | the Packet Number and Payload fields) in bytes, encoded as a | |||
length integer (Section 16). | variable-length integer (Section 16). | |||
Packet Number: The packet number field is 1 to 4 bytes long. The | Packet Number: This field is 1 to 4 bytes long. The packet number | |||
packet number is protected using header protection; see | is protected using header protection; see Section 5.4 of | |||
Section 5.4 of [QUIC-TLS]. The length of the packet number field | [QUIC-TLS]. The length of the Packet Number field is encoded in | |||
is encoded in the Packet Number Length bits of byte 0; see above. | the Packet Number Length bits of byte 0; see above. | |||
Packet Payload: This is the payload of the packet -- containing a | ||||
sequence of frames -- that is protected using packet protection. | ||||
17.2.1. Version Negotiation Packet | 17.2.1. Version Negotiation Packet | |||
A Version Negotiation packet is inherently not version-specific. | A Version Negotiation packet is inherently not version specific. | |||
Upon receipt by a client, it will be identified as a Version | Upon receipt by a client, it will be identified as a Version | |||
Negotiation packet based on the Version field having a value of 0. | Negotiation packet based on the Version field having a value of 0. | |||
The Version Negotiation packet is a response to a client packet that | The Version Negotiation packet is a response to a client packet that | |||
contains a version that is not supported by the server, and is only | contains a version that is not supported by the server. It is only | |||
sent by servers. | sent by servers. | |||
The layout of a Version Negotiation packet is: | The layout of a Version Negotiation packet is: | |||
Version Negotiation Packet { | Version Negotiation Packet { | |||
Header Form (1) = 1, | Header Form (1) = 1, | |||
Unused (7), | Unused (7), | |||
Version (32) = 0, | Version (32) = 0, | |||
Destination Connection ID Length (8), | Destination Connection ID Length (8), | |||
Destination Connection ID (0..2040), | Destination Connection ID (0..2040), | |||
skipping to change at page 111, line 9 ¶ | skipping to change at page 110, line 12 ¶ | |||
Destination Connection ID of the received packet, which is initially | Destination Connection ID of the received packet, which is initially | |||
randomly selected by a client. Echoing both connection IDs gives | randomly selected by a client. Echoing both connection IDs gives | |||
clients some assurance that the server received the packet and that | clients some assurance that the server received the packet and that | |||
the Version Negotiation packet was not generated by an entity that | the Version Negotiation packet was not generated by an entity that | |||
did not observe the Initial packet. | did not observe the Initial packet. | |||
Future versions of QUIC could have different requirements for the | Future versions of QUIC could have different requirements for the | |||
lengths of connection IDs. In particular, connection IDs might have | lengths of connection IDs. In particular, connection IDs might have | |||
a smaller minimum length or a greater maximum length. Version- | a smaller minimum length or a greater maximum length. Version- | |||
specific rules for the connection ID therefore MUST NOT influence a | specific rules for the connection ID therefore MUST NOT influence a | |||
server decision about whether to send a Version Negotiation packet. | decision about whether to send a Version Negotiation packet. | |||
The remainder of the Version Negotiation packet is a list of 32-bit | The remainder of the Version Negotiation packet is a list of 32-bit | |||
versions that the server supports. | versions that the server supports. | |||
A Version Negotiation packet is not acknowledged. It is only sent in | A Version Negotiation packet is not acknowledged. It is only sent in | |||
response to a packet that indicates an unsupported version; see | response to a packet that indicates an unsupported version; see | |||
Section 5.2.2. | Section 5.2.2. | |||
The Version Negotiation packet does not include the Packet Number and | The Version Negotiation packet does not include the Packet Number and | |||
Length fields present in other packets that use the long header form. | Length fields present in other packets that use the long header form. | |||
Consequently, a Version Negotiation packet consumes an entire UDP | Consequently, a Version Negotiation packet consumes an entire UDP | |||
datagram. | datagram. | |||
A server MUST NOT send more than one Version Negotiation packet in | A server MUST NOT send more than one Version Negotiation packet in | |||
response to a single UDP datagram. | response to a single UDP datagram. | |||
See Section 6 for a description of the version negotiation process. | See Section 6 for a description of the version negotiation process. | |||
17.2.2. Initial Packet | 17.2.2. Initial Packet | |||
An Initial packet uses long headers with a type value of 0x0. It | An Initial packet uses long headers with a type value of 0x00. It | |||
carries the first CRYPTO frames sent by the client and server to | carries the first CRYPTO frames sent by the client and server to | |||
perform key exchange, and carries ACKs in either direction. | perform key exchange, and it carries ACK frames in either direction. | |||
Initial Packet { | Initial Packet { | |||
Header Form (1) = 1, | Header Form (1) = 1, | |||
Fixed Bit (1) = 1, | Fixed Bit (1) = 1, | |||
Long Packet Type (2) = 0, | Long Packet Type (2) = 0, | |||
Reserved Bits (2), | Reserved Bits (2), | |||
Packet Number Length (2), | Packet Number Length (2), | |||
Version (32), | Version (32), | |||
Destination Connection ID Length (8), | Destination Connection ID Length (8), | |||
Destination Connection ID (0..160), | Destination Connection ID (0..160), | |||
skipping to change at page 112, line 12 ¶ | skipping to change at page 111, line 32 ¶ | |||
Figure 15: Initial Packet | Figure 15: Initial Packet | |||
The Initial packet contains a long header as well as the Length and | The Initial packet contains a long header as well as the Length and | |||
Packet Number fields; see Section 17.2. The first byte contains the | Packet Number fields; see Section 17.2. The first byte contains the | |||
Reserved and Packet Number Length bits; see also Section 17.2. | Reserved and Packet Number Length bits; see also Section 17.2. | |||
Between the Source Connection ID and Length fields, there are two | Between the Source Connection ID and Length fields, there are two | |||
additional fields specific to the Initial packet. | additional fields specific to the Initial packet. | |||
Token Length: A variable-length integer specifying the length of the | Token Length: A variable-length integer specifying the length of the | |||
Token field, in bytes. This value is zero if no token is present. | Token field, in bytes. This value is 0 if no token is present. | |||
Initial packets sent by the server MUST set the Token Length field | Initial packets sent by the server MUST set the Token Length field | |||
to zero; clients that receive an Initial packet with a non-zero | to 0; clients that receive an Initial packet with a non-zero Token | |||
Token Length field MUST either discard the packet or generate a | Length field MUST either discard the packet or generate a | |||
connection error of type PROTOCOL_VIOLATION. | connection error of type PROTOCOL_VIOLATION. | |||
Token: The value of the token that was previously provided in a | Token: The value of the token that was previously provided in a | |||
Retry packet or NEW_TOKEN frame; see Section 8.1. | Retry packet or NEW_TOKEN frame; see Section 8.1. | |||
Packet Payload: The payload of the packet. | ||||
In order to prevent tampering by version-unaware middleboxes, Initial | In order to prevent tampering by version-unaware middleboxes, Initial | |||
packets are protected with connection- and version-specific keys | packets are protected with connection- and version-specific keys | |||
(Initial keys) as described in [QUIC-TLS]. This protection does not | (Initial keys) as described in [QUIC-TLS]. This protection does not | |||
provide confidentiality or integrity against attackers that can | provide confidentiality or integrity against attackers that can | |||
observe packets, but provides some level of protection against | observe packets, but it does prevent attackers that cannot observe | |||
attackers that cannot observe packets. | packets from spoofing Initial packets. | |||
The client and server use the Initial packet type for any packet that | The client and server use the Initial packet type for any packet that | |||
contains an initial cryptographic handshake message. This includes | contains an initial cryptographic handshake message. This includes | |||
all cases where a new packet containing the initial cryptographic | all cases where a new packet containing the initial cryptographic | |||
message needs to be created, such as the packets sent after receiving | message needs to be created, such as the packets sent after receiving | |||
a Retry packet (Section 17.2.5). | a Retry packet; see Section 17.2.5. | |||
A server sends its first Initial packet in response to a client | A server sends its first Initial packet in response to a client | |||
Initial. A server MAY send multiple Initial packets. The | Initial. A server MAY send multiple Initial packets. The | |||
cryptographic key exchange could require multiple round trips or | cryptographic key exchange could require multiple round trips or | |||
retransmissions of this data. | retransmissions of this data. | |||
The payload of an Initial packet includes a CRYPTO frame (or frames) | The payload of an Initial packet includes a CRYPTO frame (or frames) | |||
containing a cryptographic handshake message, ACK frames, or both. | containing a cryptographic handshake message, ACK frames, or both. | |||
PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also | PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also | |||
permitted. An endpoint that receives an Initial packet containing | permitted. An endpoint that receives an Initial packet containing | |||
skipping to change at page 113, line 23 ¶ | skipping to change at page 112, line 40 ¶ | |||
A client stops both sending and processing Initial packets when it | A client stops both sending and processing Initial packets when it | |||
sends its first Handshake packet. A server stops sending and | sends its first Handshake packet. A server stops sending and | |||
processing Initial packets when it receives its first Handshake | processing Initial packets when it receives its first Handshake | |||
packet. Though packets might still be in flight or awaiting | packet. Though packets might still be in flight or awaiting | |||
acknowledgment, no further Initial packets need to be exchanged | acknowledgment, no further Initial packets need to be exchanged | |||
beyond this point. Initial packet protection keys are discarded (see | beyond this point. Initial packet protection keys are discarded (see | |||
Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and | Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and | |||
congestion control state; see Section 6.4 of [QUIC-RECOVERY]. | congestion control state; see Section 6.4 of [QUIC-RECOVERY]. | |||
Any data in CRYPTO frames is discarded - and no longer retransmitted | Any data in CRYPTO frames is discarded -- and no longer retransmitted | |||
- when Initial keys are discarded. | -- when Initial keys are discarded. | |||
17.2.3. 0-RTT | 17.2.3. 0-RTT | |||
A 0-RTT packet uses long headers with a type value of 0x1, followed | A 0-RTT packet uses long headers with a type value of 0x01, followed | |||
by the Length and Packet Number fields; see Section 17.2. The first | by the Length and Packet Number fields; see Section 17.2. The first | |||
byte contains the Reserved and Packet Number Length bits; see | byte contains the Reserved and Packet Number Length bits; see | |||
Section 17.2. A 0-RTT packet is used to carry "early" data from the | Section 17.2. A 0-RTT packet is used to carry "early" data from the | |||
client to the server as part of the first flight, prior to handshake | client to the server as part of the first flight, prior to handshake | |||
completion. As part of the TLS handshake, the server can accept or | completion. As part of the TLS handshake, the server can accept or | |||
reject this early data. | reject this early data. | |||
See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its | See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its | |||
limitations. | limitations. | |||
skipping to change at page 114, line 49 ¶ | skipping to change at page 114, line 7 ¶ | |||
client cannot send an ACK frame in a 0-RTT packet, because that can | client cannot send an ACK frame in a 0-RTT packet, because that can | |||
only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT | only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT | |||
packet MUST be carried in a 1-RTT packet. | packet MUST be carried in a 1-RTT packet. | |||
A server SHOULD treat a violation of remembered limits | A server SHOULD treat a violation of remembered limits | |||
(Section 7.4.1) as a connection error of an appropriate type (for | (Section 7.4.1) as a connection error of an appropriate type (for | |||
instance, a FLOW_CONTROL_ERROR for exceeding stream data limits). | instance, a FLOW_CONTROL_ERROR for exceeding stream data limits). | |||
17.2.4. Handshake Packet | 17.2.4. Handshake Packet | |||
A Handshake packet uses long headers with a type value of 0x2, | A Handshake packet uses long headers with a type value of 0x02, | |||
followed by the Length and Packet Number fields; see Section 17.2. | followed by the Length and Packet Number fields; see Section 17.2. | |||
The first byte contains the Reserved and Packet Number Length bits; | The first byte contains the Reserved and Packet Number Length bits; | |||
see Section 17.2. It is used to carry cryptographic handshake | see Section 17.2. It is used to carry cryptographic handshake | |||
messages and acknowledgments from the server and client. | messages and acknowledgments from the server and client. | |||
Handshake Packet { | Handshake Packet { | |||
Header Form (1) = 1, | Header Form (1) = 1, | |||
Fixed Bit (1) = 1, | Fixed Bit (1) = 1, | |||
Long Packet Type (2) = 2, | Long Packet Type (2) = 2, | |||
Reserved Bits (2), | Reserved Bits (2), | |||
skipping to change at page 115, line 45 ¶ | skipping to change at page 114, line 51 ¶ | |||
first Handshake packet sent by a server contains a packet number of | first Handshake packet sent by a server contains a packet number of | |||
0. | 0. | |||
The payload of this packet contains CRYPTO frames and could contain | The payload of this packet contains CRYPTO frames and could contain | |||
PING, PADDING, or ACK frames. Handshake packets MAY contain | PING, PADDING, or ACK frames. Handshake packets MAY contain | |||
CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt | CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt | |||
of Handshake packets with other frames as a connection error of type | of Handshake packets with other frames as a connection error of type | |||
PROTOCOL_VIOLATION. | PROTOCOL_VIOLATION. | |||
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames | Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames | |||
for Handshake packets is discarded - and no longer retransmitted - | for Handshake packets is discarded -- and no longer retransmitted -- | |||
when Handshake protection keys are discarded. | when Handshake protection keys are discarded. | |||
17.2.5. Retry Packet | 17.2.5. Retry Packet | |||
A Retry packet uses a long packet header with a type value of 0x3. | As shown in Figure 17, a Retry packet uses a long packet header with | |||
It carries an address validation token created by the server. It is | a type value of 0x03. It carries an address validation token created | |||
used by a server that wishes to perform a retry; see Section 8.1. | by the server. It is used by a server that wishes to perform a | |||
retry; see Section 8.1. | ||||
Retry Packet { | Retry Packet { | |||
Header Form (1) = 1, | Header Form (1) = 1, | |||
Fixed Bit (1) = 1, | Fixed Bit (1) = 1, | |||
Long Packet Type (2) = 3, | Long Packet Type (2) = 3, | |||
Unused (4), | Unused (4), | |||
Version (32), | Version (32), | |||
Destination Connection ID Length (8), | Destination Connection ID Length (8), | |||
Destination Connection ID (0..160), | Destination Connection ID (0..160), | |||
Source Connection ID Length (8), | Source Connection ID Length (8), | |||
Source Connection ID (0..160), | Source Connection ID (0..160), | |||
Retry Token (..), | Retry Token (..), | |||
Retry Integrity Tag (128), | Retry Integrity Tag (128), | |||
} | } | |||
Figure 17: Retry Packet | Figure 17: Retry Packet | |||
A Retry packet (shown in Figure 17) does not contain any protected | A Retry packet does not contain any protected fields. The value in | |||
fields. The value in the Unused field is set to an arbitrary value | the Unused field is set to an arbitrary value by the server; a client | |||
by the server; a client MUST ignore these bits. In addition to the | MUST ignore these bits. In addition to the fields from the long | |||
fields from the long header, it contains these additional fields: | header, it contains these additional fields: | |||
Retry Token: An opaque token that the server can use to validate the | Retry Token: An opaque token that the server can use to validate the | |||
client's address. | client's address. | |||
Retry Integrity Tag: See the Retry Packet Integrity section of | Retry Integrity Tag: Defined in Section "Retry Packet Integrity" | |||
[QUIC-TLS]. | [QUIC-TLS] of [QUIC-TLS]. | |||
17.2.5.1. Sending a Retry Packet | 17.2.5.1. Sending a Retry Packet | |||
The server populates the Destination Connection ID with the | The server populates the Destination Connection ID with the | |||
connection ID that the client included in the Source Connection ID of | connection ID that the client included in the Source Connection ID of | |||
the Initial packet. | the Initial packet. | |||
The server includes a connection ID of its choice in the Source | The server includes a connection ID of its choice in the Source | |||
Connection ID field. This value MUST NOT be equal to the Destination | Connection ID field. This value MUST NOT be equal to the Destination | |||
Connection ID field of the packet sent by the client. A client MUST | Connection ID field of the packet sent by the client. A client MUST | |||
skipping to change at page 117, line 19 ¶ | skipping to change at page 116, line 19 ¶ | |||
packet in response to a single UDP datagram. | packet in response to a single UDP datagram. | |||
17.2.5.2. Handling a Retry Packet | 17.2.5.2. Handling a Retry Packet | |||
A client MUST accept and process at most one Retry packet for each | A client MUST accept and process at most one Retry packet for each | |||
connection attempt. After the client has received and processed an | connection attempt. After the client has received and processed an | |||
Initial or Retry packet from the server, it MUST discard any | Initial or Retry packet from the server, it MUST discard any | |||
subsequent Retry packets that it receives. | subsequent Retry packets that it receives. | |||
Clients MUST discard Retry packets that have a Retry Integrity Tag | Clients MUST discard Retry packets that have a Retry Integrity Tag | |||
that cannot be validated; see the Retry Packet Integrity section of | that cannot be validated; see Section 5.8 of [QUIC-TLS]. This | |||
[QUIC-TLS]. This diminishes an attacker's ability to inject a Retry | diminishes an attacker's ability to inject a Retry packet and | |||
packet and protects against accidental corruption of Retry packets. | protects against accidental corruption of Retry packets. A client | |||
A client MUST discard a Retry packet with a zero-length Retry Token | MUST discard a Retry packet with a zero-length Retry Token field. | |||
field. | ||||
The client responds to a Retry packet with an Initial packet that | The client responds to a Retry packet with an Initial packet that | |||
includes the provided Retry Token to continue connection | includes the provided Retry token to continue connection | |||
establishment. | establishment. | |||
A client sets the Destination Connection ID field of this Initial | A client sets the Destination Connection ID field of this Initial | |||
packet to the value from the Source Connection ID in the Retry | packet to the value from the Source Connection ID field in the Retry | |||
packet. Changing Destination Connection ID also results in a change | packet. Changing the Destination Connection ID field also results in | |||
to the keys used to protect the Initial packet. It also sets the | a change to the keys used to protect the Initial packet. It also | |||
Token field to the token provided in the Retry. The client MUST NOT | sets the Token field to the token provided in the Retry packet. The | |||
change the Source Connection ID because the server could include the | client MUST NOT change the Source Connection ID because the server | |||
connection ID as part of its token validation logic; see | could include the connection ID as part of its token validation | |||
Section 8.1.4. | logic; see Section 8.1.4. | |||
A Retry packet does not include a packet number and cannot be | A Retry packet does not include a packet number and cannot be | |||
explicitly acknowledged by a client. | explicitly acknowledged by a client. | |||
17.2.5.3. Continuing a Handshake After Retry | 17.2.5.3. Continuing a Handshake after Retry | |||
Subsequent Initial packets from the client include the connection ID | Subsequent Initial packets from the client include the connection ID | |||
and token values from the Retry packet. The client copies the Source | and token values from the Retry packet. The client copies the Source | |||
Connection ID field from the Retry packet to the Destination | Connection ID field from the Retry packet to the Destination | |||
Connection ID field and uses this value until an Initial packet with | Connection ID field and uses this value until an Initial packet with | |||
an updated value is received; see Section 7.2. The value of the | an updated value is received; see Section 7.2. The value of the | |||
Token field is copied to all subsequent Initial packets; see | Token field is copied to all subsequent Initial packets; see | |||
Section 8.1.2. | Section 8.1.2. | |||
Other than updating the Destination Connection ID and Token fields, | Other than updating the Destination Connection ID and Token fields, | |||
skipping to change at page 118, line 27 ¶ | skipping to change at page 117, line 26 ¶ | |||
contain confidential information that will most likely be | contain confidential information that will most likely be | |||
retransmitted on receiving a Retry packet. The keys used to protect | retransmitted on receiving a Retry packet. The keys used to protect | |||
these new 0-RTT packets will not change as a result of responding to | these new 0-RTT packets will not change as a result of responding to | |||
a Retry packet. However, the data sent in these packets could be | a Retry packet. However, the data sent in these packets could be | |||
different than what was sent earlier. Sending these new packets with | different than what was sent earlier. Sending these new packets with | |||
the same packet number is likely to compromise the packet protection | the same packet number is likely to compromise the packet protection | |||
for those packets because the same key and nonce could be used to | for those packets because the same key and nonce could be used to | |||
protect different content. A server MAY abort the connection if it | protect different content. A server MAY abort the connection if it | |||
detects that the client reset the packet number. | detects that the client reset the packet number. | |||
The connection IDs used on Initial and Retry packets exchanged | The connection IDs used in Initial and Retry packets exchanged | |||
between client and server are copied to the transport parameters and | between client and server are copied to the transport parameters and | |||
validated as described in Section 7.3. | validated as described in Section 7.3. | |||
17.3. Short Header Packets | 17.3. Short Header Packets | |||
This version of QUIC defines a single packet type that uses the short | This version of QUIC defines a single packet type that uses the short | |||
packet header. | packet header. | |||
17.3.1. 1-RTT Packet | 17.3.1. 1-RTT Packet | |||
skipping to change at page 119, line 49 ¶ | skipping to change at page 118, line 49 ¶ | |||
header protection can expose the endpoint to attacks; see | header protection can expose the endpoint to attacks; see | |||
Section 9.5 of [QUIC-TLS]. | Section 9.5 of [QUIC-TLS]. | |||
Key Phase: The next bit (0x04) of byte 0 indicates the key phase, | Key Phase: The next bit (0x04) of byte 0 indicates the key phase, | |||
which allows a recipient of a packet to identify the packet | which allows a recipient of a packet to identify the packet | |||
protection keys that are used to protect the packet. See | protection keys that are used to protect the packet. See | |||
[QUIC-TLS] for details. This bit is protected using header | [QUIC-TLS] for details. This bit is protected using header | |||
protection; see Section 5.4 of [QUIC-TLS]. | protection; see Section 5.4 of [QUIC-TLS]. | |||
Packet Number Length: The least significant two bits (those with a | Packet Number Length: The least significant two bits (those with a | |||
mask of 0x03) of byte 0 contain the length of the packet number, | mask of 0x03) of byte 0 contain the length of the Packet Number | |||
encoded as an unsigned, two-bit integer that is one less than the | field, encoded as an unsigned two-bit integer that is one less | |||
length of the packet number field in bytes. That is, the length | than the length of the Packet Number field in bytes. That is, the | |||
of the packet number field is the value of this field, plus one. | length of the Packet Number field is the value of this field plus | |||
one. These bits are protected using header protection; see | ||||
These bits are protected using header protection; see Section 5.4 | Section 5.4 of [QUIC-TLS]. | |||
of [QUIC-TLS]. | ||||
Destination Connection ID: The Destination Connection ID is a | Destination Connection ID: The Destination Connection ID is a | |||
connection ID that is chosen by the intended recipient of the | connection ID that is chosen by the intended recipient of the | |||
packet. See Section 5.1 for more details. | packet. See Section 5.1 for more details. | |||
Packet Number: The packet number field is 1 to 4 bytes long. The | Packet Number: The Packet Number field is 1 to 4 bytes long. The | |||
packet number is protected using header protection; see | packet number is protected using header protection; see | |||
Section 5.4 of [QUIC-TLS]. The length of the packet number field | Section 5.4 of [QUIC-TLS]. The length of the Packet Number field | |||
is encoded in Packet Number Length field. See Section 17.1 for | is encoded in Packet Number Length field. See Section 17.1 for | |||
details. | details. | |||
Packet Payload: 1-RTT packets always include a 1-RTT protected | Packet Payload: 1-RTT packets always include a 1-RTT protected | |||
payload. | payload. | |||
The header form bit and the connection ID field of a short header | The header form bit and the Destination Connection ID field of a | |||
packet are version-independent. The remaining fields are specific to | short header packet are version independent. The remaining fields | |||
the selected QUIC version. See [QUIC-INVARIANTS] for details on how | are specific to the selected QUIC version. See [QUIC-INVARIANTS] for | |||
packets from different versions of QUIC are interpreted. | details on how packets from different versions of QUIC are | |||
interpreted. | ||||
17.4. Latency Spin Bit | 17.4. Latency Spin Bit | |||
The latency spin bit, which is defined for 1-RTT packets | The latency spin bit, which is defined for 1-RTT packets | |||
(Section 17.3.1), enables passive latency monitoring from observation | (Section 17.3.1), enables passive latency monitoring from observation | |||
points on the network path throughout the duration of a connection. | points on the network path throughout the duration of a connection. | |||
The server reflects the spin value received, while the client 'spins' | The server reflects the spin value received, while the client "spins" | |||
it after one RTT. On-path observers can measure the time between two | it after one RTT. On-path observers can measure the time between two | |||
spin bit toggle events to estimate the end-to-end RTT of a | spin bit toggle events to estimate the end-to-end RTT of a | |||
connection. | connection. | |||
The spin bit is only present in 1-RTT packets, since it is possible | The spin bit is only present in 1-RTT packets, since it is possible | |||
to measure the initial RTT of a connection by observing the | to measure the initial RTT of a connection by observing the | |||
handshake. Therefore, the spin bit is available after version | handshake. Therefore, the spin bit is available after version | |||
negotiation and connection establishment are completed. On-path | negotiation and connection establishment are completed. On-path | |||
measurement and use of the latency spin bit is further discussed in | measurement and use of the latency spin bit are further discussed in | |||
[QUIC-MANAGEABILITY]. | [QUIC-MANAGEABILITY]. | |||
The spin bit is an OPTIONAL feature of this version of QUIC. An | The spin bit is an OPTIONAL feature of this version of QUIC. An | |||
endpoint that does not support this feature MUST disable it, as | endpoint that does not support this feature MUST disable it, as | |||
defined below. | defined below. | |||
Each endpoint unilaterally decides if the spin bit is enabled or | Each endpoint unilaterally decides if the spin bit is enabled or | |||
disabled for a connection. Implementations MUST allow administrators | disabled for a connection. Implementations MUST allow administrators | |||
of clients and servers to disable the spin bit either globally or on | of clients and servers to disable the spin bit either globally or on | |||
a per-connection basis. Even when the spin bit is not disabled by | a per-connection basis. Even when the spin bit is not disabled by | |||
the administrator, endpoints MUST disable their use of the spin bit | the administrator, endpoints MUST disable their use of the spin bit | |||
for a random selection of at least one in every 16 network paths, or | for a random selection of at least one in every 16 network paths, or | |||
for one in every 16 connection IDs, in order to ensure that QUIC | for one in every 16 connection IDs, in order to ensure that QUIC | |||
connections that disable the spin bit are commonly observed on the | connections that disable the spin bit are commonly observed on the | |||
network. As each endpoint disables the spin bit independently, this | network. As each endpoint disables the spin bit independently, this | |||
ensures that the spin bit signal is disabled on approximately one in | ensures that the spin bit signal is disabled on approximately one in | |||
eight network paths. | eight network paths. | |||
When the spin bit is disabled, endpoints MAY set the spin bit to any | When the spin bit is disabled, endpoints MAY set the spin bit to any | |||
value, and MUST ignore any incoming value. It is RECOMMENDED that | value and MUST ignore any incoming value. It is RECOMMENDED that | |||
endpoints set the spin bit to a random value either chosen | endpoints set the spin bit to a random value either chosen | |||
independently for each packet or chosen independently for each | independently for each packet or chosen independently for each | |||
connection ID. | connection ID. | |||
If the spin bit is enabled for the connection, the endpoint maintains | If the spin bit is enabled for the connection, the endpoint maintains | |||
a spin value for each network path and sets the spin bit in the | a spin value for each network path and sets the spin bit in the | |||
packet header to the currently stored value when a 1-RTT packet is | packet header to the currently stored value when a 1-RTT packet is | |||
sent on that path. The spin value is initialized to 0 in the | sent on that path. The spin value is initialized to 0 in the | |||
endpoint for each network path. Each endpoint also remembers the | endpoint for each network path. Each endpoint also remembers the | |||
highest packet number seen from its peer on each path. | highest packet number seen from its peer on each path. | |||
skipping to change at page 121, line 33 ¶ | skipping to change at page 120, line 34 ¶ | |||
When a server receives a 1-RTT packet that increases the highest | When a server receives a 1-RTT packet that increases the highest | |||
packet number seen by the server from the client on a given network | packet number seen by the server from the client on a given network | |||
path, it sets the spin value for that path to be equal to the spin | path, it sets the spin value for that path to be equal to the spin | |||
bit in the received packet. | bit in the received packet. | |||
When a client receives a 1-RTT packet that increases the highest | When a client receives a 1-RTT packet that increases the highest | |||
packet number seen by the client from the server on a given network | packet number seen by the client from the server on a given network | |||
path, it sets the spin value for that path to the inverse of the spin | path, it sets the spin value for that path to the inverse of the spin | |||
bit in the received packet. | bit in the received packet. | |||
An endpoint resets the spin value for a network path to zero when | An endpoint resets the spin value for a network path to 0 when | |||
changing the connection ID being used on that network path. | changing the connection ID being used on that network path. | |||
18. Transport Parameter Encoding | 18. Transport Parameter Encoding | |||
The extension_data field of the quic_transport_parameters extension | The extension_data field of the quic_transport_parameters extension | |||
defined in [QUIC-TLS] contains the QUIC transport parameters. They | defined in [QUIC-TLS] contains the QUIC transport parameters. They | |||
are encoded as a sequence of transport parameters, as shown in | are encoded as a sequence of transport parameters, as shown in | |||
Figure 18: | Figure 18: | |||
Transport Parameters { | Transport Parameters { | |||
skipping to change at page 122, line 24 ¶ | skipping to change at page 121, line 24 ¶ | |||
Transport Parameter Value field in bytes. | Transport Parameter Value field in bytes. | |||
QUIC encodes transport parameters into a sequence of bytes, which is | QUIC encodes transport parameters into a sequence of bytes, which is | |||
then included in the cryptographic handshake. | then included in the cryptographic handshake. | |||
18.1. Reserved Transport Parameters | 18.1. Reserved Transport Parameters | |||
Transport parameters with an identifier of the form "31 * N + 27" for | Transport parameters with an identifier of the form "31 * N + 27" for | |||
integer values of N are reserved to exercise the requirement that | integer values of N are reserved to exercise the requirement that | |||
unknown transport parameters be ignored. These transport parameters | unknown transport parameters be ignored. These transport parameters | |||
have no semantics, and can carry arbitrary values. | have no semantics and can carry arbitrary values. | |||
18.2. Transport Parameter Definitions | 18.2. Transport Parameter Definitions | |||
This section details the transport parameters defined in this | This section details the transport parameters defined in this | |||
document. | document. | |||
Many transport parameters listed here have integer values. Those | Many transport parameters listed here have integer values. Those | |||
transport parameters that are identified as integers use a variable- | transport parameters that are identified as integers use a variable- | |||
length integer encoding; see Section 16. Transport parameters have a | length integer encoding; see Section 16. Transport parameters have a | |||
default value of 0 if the transport parameter is absent unless | default value of 0 if the transport parameter is absent, unless | |||
otherwise stated. | otherwise stated. | |||
The following transport parameters are defined: | The following transport parameters are defined: | |||