draft-ietf-quic-transport-25.txt   draft-ietf-quic-transport-26.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: 25 July 2020 Mozilla Expires: 24 August 2020 Mozilla
22 January 2020 21 February 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-25 draft-ietf-quic-transport-26
Abstract Abstract
This document defines the core of the QUIC transport protocol. This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation. control and the use of TLS for key negotiation.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 July 2020. This Internet-Draft will expire on 24 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 10 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 10
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 11 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 11
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11
2.4. Required Operations on Streams . . . . . . . . . . . . . 12 2.4. Required Operations on Streams . . . . . . . . . . . . . 12
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 13 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 13
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 16 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 15
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 18 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 18
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 19 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 18
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 20 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 19
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 22 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 21
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 23 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 22
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 24 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 23
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 25 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 24
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 25 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 24
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 26 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 27 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 26
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 28 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 27
5.2. Matching Packets to Connections . . . . . . . . . . . . . 29 5.2. Matching Packets to Connections . . . . . . . . . . . . . 28
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 30 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 29
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 30 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 29
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 31 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 30
5.4. Required Operations on Connections . . . . . . . . . . . 32 5.4. Required Operations on Connections . . . . . . . . . . . 31
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 33 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 32
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 33 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 32
6.2. Handling Version Negotiation Packets . . . . . . . . . . 34 6.2. Handling Version Negotiation Packets . . . . . . . . . . 33
6.2.1. Version Negotiation Between Draft Versions . . . . . 34 6.2.1. Version Negotiation Between Draft Versions . . . . . 33
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 34 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 33
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 35 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 34
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 36 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 35
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 37 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 36
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 38 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 37
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 39 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 38
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 40 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 39
7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 41 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 40
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 41 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 40
8.1. Address Validation During Connection Establishment . . . 42 8.1. Address Validation During Connection Establishment . . . 41
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 43 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 42
8.1.2. Address Validation using Retry Packets . . . . . . . 43 8.1.2. Address Validation using Retry Packets . . . . . . . 42
8.1.3. Address Validation for Future Connections . . . . . . 44 8.1.3. Address Validation for Future Connections . . . . . . 43
8.1.4. Address Validation Token Integrity . . . . . . . . . 46 8.1.4. Address Validation Token Integrity . . . . . . . . . 45
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 47 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 46
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 47 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 46
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 48 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 47
8.5. Successful Path Validation . . . . . . . . . . . . . . . 48 8.5. Successful Path Validation . . . . . . . . . . . . . . . 47
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 48 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 47
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 49 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 48
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 50 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 49
9.2. Initiating Connection Migration . . . . . . . . . . . . . 50 9.2. Initiating Connection Migration . . . . . . . . . . . . . 49
9.3. Responding to Connection Migration . . . . . . . . . . . 51 9.3. Responding to Connection Migration . . . . . . . . . . . 50
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 52 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 50
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 52 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 51
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 53 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 52
9.4. Loss Detection and Congestion Control . . . . . . . . . . 54 9.4. Loss Detection and Congestion Control . . . . . . . . . . 53
9.5. Privacy Implications of Connection Migration . . . . . . 55 9.5. Privacy Implications of Connection Migration . . . . . . 54
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 56 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 55
9.6.1. Communicating a Preferred Address . . . . . . . . . . 56 9.6.1. Communicating a Preferred Address . . . . . . . . . . 55
9.6.2. Responding to Connection Migration . . . . . . . . . 57 9.6.2. Responding to Connection Migration . . . . . . . . . 56
9.6.3. Interaction of Client Migration and Preferred 9.6.3. Interaction of Client Migration and Preferred
Address . . . . . . . . . . . . . . . . . . . . . . . 57 Address . . . . . . . . . . . . . . . . . . . . . . . 56
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 58 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 57
10. Connection Termination . . . . . . . . . . . . . . . . . . . 58 10. Connection Termination . . . . . . . . . . . . . . . . . . . 57
10.1. Closing and Draining Connection States . . . . . . . . . 58 10.1. Closing and Draining Connection States . . . . . . . . . 57
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 60 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 59
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 60 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 59
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 62 10.3.1. Immediate Close During the Handshake . . . . . . . . 60
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 65 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 61
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 66 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 64
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 67 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 65
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 66
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 67 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 67
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 68 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 67
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 68 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 68
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 69 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 68
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 69 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 69
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 70 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 69
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 71 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 70
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 72 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 71
13. Packetization and Reliability . . . . . . . . . . . . . . . . 75
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 76 13. Packetization and Reliability . . . . . . . . . . . . . . . . 74
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 76 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 75
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 77 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 75
13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 78 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 76
13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 79 13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 77
13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 79 13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 78
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 79 13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 78
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 80 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 78
13.3. Retransmission of Information . . . . . . . . . . . . . 80 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 79
13.4. Explicit Congestion Notification . . . . . . . . . . . . 83 13.3. Retransmission of Information . . . . . . . . . . . . . 79
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 83 13.4. Explicit Congestion Notification . . . . . . . . . . . . 82
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 84 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 82
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 85 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 83
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 86 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 84
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 87 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 85
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 88 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 86
14.3.1. PMTU Probes Containing Source Connection ID . . . . 88 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 87
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 89 14.3.1. PMTU Probes Containing Source Connection ID . . . . 87
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 90 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 88
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 90 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 89
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 91 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 89
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 92 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 90
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 94 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 91
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 96 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 93
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 98 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 95
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 100 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 97
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 101 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 99
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 103 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 100
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 105 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 102
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 106 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 104
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 107 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 105
18.2. Transport Parameter Definitions . . . . . . . . . . . . 107 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 106
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 112 18.2. Transport Parameter Definitions . . . . . . . . . . . . 106
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 112 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 111
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 112 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 111
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 113 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 111
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 114 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 112
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 116 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 113
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 117 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 115
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 118 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 116
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 118 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 117
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 119 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 117
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 120 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 118
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 122 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 119
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 122 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 121
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 123 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 121
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 124 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 122
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 125 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 123
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 125 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 124
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 126 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 124
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 128 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 125
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 129 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 127
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 129 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 128
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 129 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 128
19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 131 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 128
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 131 19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 130
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 131 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 130
20.1. Application Protocol Error Codes . . . . . . . . . . . . 133 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 130
21. Security Considerations . . . . . . . . . . . . . . . . . . . 133 20.1. Application Protocol Error Codes . . . . . . . . . . . . 132
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 133 21. Security Considerations . . . . . . . . . . . . . . . . . . . 132
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 132
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 134 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 134
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 135 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 134
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 135 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 134
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 135 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 134
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 136 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 135
21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 136 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 135
21.8. Explicit Congestion Notification Attacks . . . . . . . . 137 21.8. Explicit Congestion Notification Attacks . . . . . . . . 136
21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 137 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 136
21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 137 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 137
21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 138 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 137
21.12. Overview of Security Properties . . . . . . . . . . . . 138 21.12. Overview of Security Properties . . . . . . . . . . . . 137
21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 138 21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 138
21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 140 21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 139
21.12.3. Connection Migration . . . . . . . . . . . . . . . 141 21.12.3. Connection Migration . . . . . . . . . . . . . . . 140
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144
22.1. Registration Policies for QUIC Registries . . . . . . . 145 22.1. Registration Policies for QUIC Registries . . . . . . . 144
22.1.1. Provisional Registrations . . . . . . . . . . . . . 145 22.1.1. Provisional Registrations . . . . . . . . . . . . . 144
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 146 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 145
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 146 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 146
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 147 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 146
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 148 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 147
22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 149 22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 148
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 150 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 149
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 152 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 151
23.1. Normative References . . . . . . . . . . . . . . . . . . 152 23.1. Normative References . . . . . . . . . . . . . . . . . . 151
23.2. Informative References . . . . . . . . . . . . . . . . . 153 23.2. Informative References . . . . . . . . . . . . . . . . . 152
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 155 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 154
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 156 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 155
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 157 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 156
C.1. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 157 C.1. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 156
C.2. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 158 C.2. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 157
C.3. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 159 C.3. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 158
C.4. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 160 C.4. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 159
C.5. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 160 C.5. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 159
C.6. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 161 C.6. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 160
C.7. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 162 C.7. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 161
C.8. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 162 C.8. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 161
C.9. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 163 C.9. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 162
C.10. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 164 C.10. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 163
C.11. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 164 C.11. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 163
C.12. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 164 C.12. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 164
C.13. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 165 C.13. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 164
C.14. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 166 C.14. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 165
C.15. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 166 C.15. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 165
C.16. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 167 C.16. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 166
C.17. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 168 C.17. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 167
C.18. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 168 C.18. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 167
C.19. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 169 C.19. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 168
C.20. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 170 C.20. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 169
C.21. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 170 C.21. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 169
C.22. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 171 C.22. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 170
C.23. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 171 C.23. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 170
C.24. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 172 C.24. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 171
C.25. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 174 C.25. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 173
C.26. Since draft-hamilton-quic-transport-protocol-01 . . . . . 174 C.26. Since draft-hamilton-quic-transport-protocol-01 . . . . . 173
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174
1. Introduction 1. Introduction
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
* Stream multiplexing * Stream multiplexing
* Stream and connection-level flow control * Stream and connection-level flow control
skipping to change at page 8, line 34 skipping to change at page 8, line 35
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. Multiple QUIC packets can be encapsulated in a UDP datagram. Multiple 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).
Out-of-order packet: A packet that does not increase the largest Out-of-order packet: A packet that does not increase the largest
received packet number for its packet number space by exactly one. received packet number for its packet number space (Section 12.3)
A packet can arrive out of order if it is delayed or if earlier by exactly one. A packet can arrive out of order if it is delayed
packets are lost or delayed. or if earlier packets are lost or delayed.
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 endpoint in QUIC: client and server.
Client: The endpoint initiating a QUIC connection. Client: The endpoint initiating a QUIC connection.
Server: The endpoint accepting incoming QUIC connections. Server: The endpoint accepting incoming QUIC connections.
Address: When used without qualification, the tuple of IP version, Address: When used without qualification, the tuple of IP version,
skipping to change at page 15, line 6 skipping to change at page 15, line 6
accept data from the application. Stream data might be buffered in accept data from the application. Stream data might be buffered in
this state in preparation for sending. this state in preparation for sending.
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) enters the "Ready" state then 0 for a server, type 1 for a client) starts in the "Ready" state when
immediately transitions to the "Send" state if the receiving part the receiving part is created.
enters the "Recv" state (Section 3.2).
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 or connection flow control limits Section 4.1. stream or connection 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
skipping to change at page 23, line 37 skipping to change at page 22, line 37
STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to
write but is blocked by flow control limits. If a sender is blocked write but is blocked by flow control limits. If a sender is blocked
for a period longer than the idle timeout (Section 10.2), the for a period longer than the idle timeout (Section 10.2), the
connection might be closed even when data is available for connection might be closed even when data is available for
transmission. To keep the connection from closing, a sender that is transmission. To keep the connection from closing, a sender that is
flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED
or DATA_BLOCKED frame when it has no ack-eliciting packets in flight. or DATA_BLOCKED frame when it has no ack-eliciting packets in flight.
4.2. Flow Credit Increments 4.2. Flow Credit Increments
This document leaves when and how many bytes to advertise in a Implementations decide when and how much credit to advertise in
MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few
few considerations. These frames contribute to connection overhead. considerations.
Therefore frequently sending frames with small changes is
undesirable. At the same time, larger increments to limits are To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or
necessary to avoid blocking if updates are less frequent, requiring MAX_DATA frame multiple times within a round trip or send it early
larger resource commitments at the receiver. Thus there is a trade- enough to allow for recovery from loss of the frame.
off between resource commitment and overhead when determining how
large a limit is advertised. Control frames contribute to connection overhead. Therefore,
frequently sending MAX_STREAM_DATA and MAX_DATA frames with small
changes is undesirable. On the other hand, if updates are less
frequent, larger increments to limits are necessary to avoid blocking
a sender, requiring larger resource commitments at the receiver.
There is a trade-off between resource commitment and overhead when
determining how large a limit is advertised.
A receiver can use an autotuning mechanism to tune the frequency and A receiver can use an autotuning mechanism to tune the frequency and
amount of advertised additional credit based on a round-trip time amount of advertised additional credit based on a round-trip time
estimate and the rate at which the receiving application consumes estimate and the rate at which the receiving application consumes
data, similar to common TCP implementations. As an optimization, data, similar to common TCP implementations. As an optimization, an
sending frames related to flow control only when there are other endpoint could send frames related to flow control only when there
frames to send or when a peer is blocked ensures that flow control are other frames to send or when a peer is blocked, ensuring that
doesn't cause extra packets to be sent. flow control does not cause extra packets to be sent.
If a sender runs out of flow control credit, it will be unable to A blocked sender is not required to send STREAM_DATA_BLOCKED or
send new data and is considered blocked. It is generally considered DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a
best to not let the sender become blocked. To avoid blocking a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a
sender, and to reasonably account for the possibility of loss, a MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the
receiver should send a MAX_DATA or MAX_STREAM_DATA frame at least two sender being blocked for the rest of the connection. Even if the
round trips before it expects the sender to get blocked. sender sends these frames, waiting for them will result in the sender
being blocked for at least an entire round trip.
A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED When a sender receives credit after being blocked, it might be able
frame before sending MAX_STREAM_DATA or MAX_DATA, since doing so will to send a large amount of data in response, resulting in short-term
mean that a sender will be blocked for at least an entire round trip, congestion; see Section 6.9 in [QUIC-RECOVERY] for a discussion of
and potentially for longer if the peer chooses to not send how a sender can avoid this congestion.
STREAM_DATA_BLOCKED or DATA_BLOCKED frames.
4.3. Handling Stream Cancellation 4.3. Handling Stream Cancellation
Endpoints need to eventually agree on the amount of flow control Endpoints need to eventually agree on the amount of flow control
credit that has been consumed, to avoid either exceeding flow control credit that has been consumed, to avoid either exceeding flow control
limits or deadlocking. limits or deadlocking.
On receipt of a RESET_STREAM frame, an endpoint will tear down state On receipt of a RESET_STREAM frame, an endpoint will tear down state
for the matching stream and ignore further data arriving on that for the matching stream and ignore further data arriving on that
stream. Without the offset included in RESET_STREAM, the two stream. Without the offset included in RESET_STREAM, the two
skipping to change at page 28, line 17 skipping to change at page 27, line 17
each newly-issued connection ID MUST increase by 1. The connection each newly-issued connection ID MUST increase by 1. The connection
ID randomly selected by the client in the Initial packet and any ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection numbers unless a server opts to retain them as its initial connection
ID. ID.
When an endpoint issues a connection ID, it MUST accept packets that When an endpoint issues a connection ID, it MUST accept packets that
carry this connection ID for the duration of the connection or until carry this connection ID for the duration of the connection or until
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
frame (Section 19.16). Connection IDs that are issued and not frame (Section 19.16). Connection IDs that are issued and not
retired are considered active; any active connection ID can be used. retired are considered active; any active connection ID is valid for
use at any time, in any packet type. This includes the connection ID
issued by the server via the preferred_address transport parameter.
An endpoint SHOULD ensure that its peer has a sufficient number of An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. Endpoints store received available and unused connection IDs. Endpoints store received
connection IDs for future use and advertise the number of connection connection IDs for future use and advertise the number of connection
IDs they are willing to store with the active_connection_id_limit IDs they are willing to store with the active_connection_id_limit
transport parameter. An endpoint MUST NOT provide more connection transport parameter. An endpoint MUST NOT provide more connection
IDs than the peer's limit. An endpoint that receives more connection IDs than the peer's limit. An endpoint that receives more connection
IDs than its advertised active_connection_id_limit MUST close the IDs than its advertised active_connection_id_limit MUST close the
connection with an error of type CONNECTION_ID_LIMIT_ERROR. connection with an error of type CONNECTION_ID_LIMIT_ERROR.
skipping to change at page 35, line 46 skipping to change at page 34, line 46
* authenticated values for transport parameters of both endpoints, * authenticated values for transport parameters of both endpoints,
and confidentiality protection for server transport parameters and confidentiality protection for server transport parameters
(see Section 7.3) (see Section 7.3)
* authenticated negotiation of an application protocol (TLS uses * authenticated negotiation of an application protocol (TLS uses
ALPN [RFC7301] for this purpose) ALPN [RFC7301] for this purpose)
An endpoint can verify support for Explicit Congestion Notification An endpoint can verify support for Explicit Congestion Notification
(ECN) in the first packets it sends, as described in Section 13.4.2. (ECN) in the first packets it sends, as described in Section 13.4.2.
The CRYPTO frame can be sent in different packet number spaces. The The CRYPTO frame can be sent in different packet number spaces
sequence numbers used by CRYPTO frames to ensure ordered delivery of (Section 12.3). The sequence numbers used by CRYPTO frames to ensure
cryptographic handshake data start from zero in each packet number ordered delivery of cryptographic handshake data start from zero in
space. each packet number space.
Endpoints MUST explicitly negotiate an application protocol. This Endpoints MUST explicitly negotiate an application protocol. This
avoids situations where there is a disagreement about the protocol avoids situations where there is a disagreement about the protocol
that is in use. that is in use.
7.1. Example Handshake Flows 7.1. Example Handshake Flows
Details of how TLS is integrated with QUIC are provided in Details of how TLS is integrated with QUIC are provided in
[QUIC-TLS], but some examples are provided here. An extension of [QUIC-TLS], but some examples are provided here. An extension of
this exchange to support client address validation is shown in this exchange to support client address validation is shown in
skipping to change at page 42, line 30 skipping to change at page 41, line 30
Clients MUST ensure that UDP datagrams containing Initial packets Clients MUST ensure that UDP datagrams containing Initial packets
have UDP payloads of at least 1200 bytes, adding padding to packets have UDP payloads of at least 1200 bytes, adding padding to packets
in the datagram as necessary. Sending padded datagrams ensures that in the datagram as necessary. Sending padded datagrams ensures that
the server is not overly constrained by the amplification the server is not overly constrained by the amplification
restriction. restriction.
Packet loss, in particular loss of a Handshake packet from the Packet loss, in particular loss of a Handshake packet from the
server, can cause a situation in which the server cannot send when server, can cause a situation in which the server cannot send when
the client has no data to send and the anti-amplification limit is the client has no data to send and the anti-amplification limit is
reached. In order to avoid this causing a handshake deadlock, reached. In order to avoid this causing a handshake deadlock,
clients SHOULD send a packet upon a probe timeout, as described in clients MUST send a packet upon a probe timeout, as described in
[QUIC-RECOVERY]. If the client has no data to retransmit and does [QUIC-RECOVERY]. If the client has no data to retransmit and does
not have Handshake keys, it SHOULD send an Initial packet in a UDP not have Handshake keys, it MUST send an Initial packet in a UDP
datagram of at least 1200 bytes. If the client has Handshake keys, datagram of at least 1200 bytes. If the client has Handshake keys,
it SHOULD send a Handshake packet. it SHOULD send a 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).
skipping to change at page 44, line 36 skipping to change at page 43, line 36
The server uses the NEW_TOKEN frame Section 19.7 to provide the The server uses the NEW_TOKEN frame Section 19.7 to provide the
client with an address validation token that can be used to validate client with an address validation token that can be used to validate
future connections. The client includes this token in Initial future connections. The client includes this token in Initial
packets to provide address validation in a future connection. The packets to provide address validation in a future connection. The
client MUST include the token in all Initial packets it sends, unless client MUST include the token in all Initial packets it sends, unless
a Retry replaces the token with a newer one. The client MUST NOT use a Retry replaces the token with a newer one. The client MUST NOT use
the token provided in a Retry for future connections. Servers MAY the token provided in a Retry for future connections. Servers MAY
discard any Initial packet that does not carry the expected token. discard any Initial packet that does not carry the expected token.
Unlike the token that is created for a Retry packet, there might be Unlike the token that is created for a Retry packet, which is used
some time between when the token is created and when the token is immediately, the token sent in the NEW_TOKEN frame might be used
subsequently used. Thus, a token SHOULD have an expiration time, after some period of time has passed. Thus, a token SHOULD have an
which could be either an explicit expiration time or an issued expiration time, which could be either an explicit expiration time or
timestamp that can be used to dynamically calculate the expiration an issued timestamp that can be used to dynamically calculate the
time. A server can store the expiration time or include it in an expiration time. A server can store the expiration time or include
encrypted form in the token. it in an encrypted form in the token.
A token issued with NEW_TOKEN MUST NOT include information that would A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an on-path observer to the connection on allow values to be linked by an on-path observer to the connection on
which it was issued, unless the values are encrypted. For example, which it was issued, unless the values are encrypted. For example,
it cannot include the previous connection ID or addressing it cannot include the previous connection ID or addressing
information. A server MUST ensure that every NEW_TOKEN frame it information. A server MUST ensure that every NEW_TOKEN frame it
sends is unique across all clients, with the exception of those sent sends is unique across all clients, with the exception of those sent
to repair losses of previously sent NEW_TOKEN frames. Information to repair losses of previously sent NEW_TOKEN frames. Information
that allows the server to distinguish between tokens from Retry and that allows the server to distinguish between tokens from Retry and
NEW_TOKEN MAY be accessible to entities other than the server. NEW_TOKEN MAY be accessible to entities other than the server.
skipping to change at page 45, line 32 skipping to change at page 44, line 32
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 MAY Clients that want to break continuity of identity with a server MAY
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 NEW_TOKEN token for different connection
attempts. Reusing a token allows connections to be linked by attempts. Reusing a token allows connections to be linked by
entities on the network path; see Section 9.5. A client MUST NOT entities on the network path; see Section 9.5.
reuse a token if it believes that its point of network attachment has
changed since the token was last used; that is, if there is a change
in its local IP address or network interface. A client needs to
start the connection process over if there is any change in its local
address prior to completing the handshake.
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 to replace older
tokens that might become invalid. For a client, this ambiguity means tokens that might become invalid. For a client, this ambiguity means
that sending the most recent unused token is most likely to be that sending the most recent unused token is most likely to be
effective. Though saving and using older tokens has no negative effective. Though saving and using older tokens has no negative
consequences, clients can regard older tokens as being less likely be consequences, clients can regard older tokens as being less likely be
useful to the server for address validation. useful to the server for address validation.
skipping to change at page 54, line 44 skipping to change at page 53, line 42
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]) may be adequate. For instance, an (as described in [QUIC-RECOVERY]) may be adequate. For instance, an
endpoint might delay switching to a new congestion control context 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 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 when separate timer when a PATH_CHALLENGE is sent, which is cancelled 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 5.3 of
[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 allows a Using a stable connection ID on multiple network paths allows 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 need as discussed in Section 5.1. For this to be effective endpoints need
to ensure that connection IDs they provide cannot be linked by any to ensure that connection IDs they provide cannot be linked by any
skipping to change at page 60, line 31 skipping to change at page 59, line 31
but only if no other ack-eliciting packets have been sent since last but only if no other ack-eliciting packets have been sent since last
receiving a packet. Restarting when sending packets ensures that receiving a packet. Restarting when sending packets ensures that
connections do not prematurely time out when initiating new activity. connections do not prematurely time out when initiating new activity.
An endpoint might need to send packets to avoid an idle timeout if it An endpoint might need to send packets to avoid an idle timeout if it
is unable to send application data due to being blocked on flow is unable to send application data due to being blocked on flow
control limits; see Section 4. control limits; see Section 4.
An endpoint that sends packets near the end of the idle timeout An endpoint that sends packets near the end of the idle timeout
period risks having those packets discarded if its peer enters the period risks having those packets discarded if its peer enters the
draining state before the packets arrive. If a peer could time out draining state before the packets arrive. If a peer could time out
within a Probe Timeout (PTO; see Section 6.2.2 of [QUIC-RECOVERY]), within a Probe Timeout (PTO; see Section 6.6 of [QUIC-RECOVERY]), it
it is advisable to test for liveness before sending any data that is advisable to test for liveness before sending any data that cannot
cannot be retried safely. Note that it is likely that only be retried safely. Note that it is likely that only applications or
applications or application protocols will know what information can application protocols will know what information can be retried.
be retried.
10.3. Immediate Close 10.3. 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.
After sending a CONNECTION_CLOSE frame, an endpoint immediately After sending a CONNECTION_CLOSE frame, an endpoint immediately
enters the closing state. enters the closing state.
skipping to change at page 61, line 48 skipping to change at page 60, line 46
An immediate close can be used after an application protocol has An immediate close can be used after an application protocol has
arranged to close a connection. This might be after the application arranged to close a connection. This might be after the application
protocols negotiates a graceful shutdown. The application protocol protocols negotiates a graceful shutdown. The application protocol
exchanges whatever messages that are needed to cause both endpoints exchanges whatever messages that are needed to cause both endpoints
to agree to close the connection, after which the application to agree to close the connection, after which the application
requests that the connection be closed. The application protocol can requests that the connection be closed. The application protocol can
use a CONNECTION_CLOSE frame with an appropriate error code to signal use a CONNECTION_CLOSE frame with an appropriate error code to signal
closure. closure.
10.3.1. Immediate Close During the Handshake
When sending CONNECTION_CLOSE, the goal is to ensure that the peer When sending CONNECTION_CLOSE, the goal is to ensure that the peer
will process the frame. Generally, this means sending the frame in a will process the frame. Generally, this means sending the frame in a
packet with the highest level of packet protection to avoid the 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 the frame MAY be protection keys are not available to the peer, so the frame MAY be
replicated in a packet that uses a lower packet protection level. replicated in a packet that uses a lower packet protection level.
A client will always know whether the server has Handshake keys (see 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 know Section 17.2.2.1), but it is possible that a server does not know
whether the client has Handshake keys. Under these circumstances, a whether the client has Handshake keys. Under these circumstances, a
server SHOULD send a CONNECTION_CLOSE frame in both Handshake and server SHOULD send a CONNECTION_CLOSE frame in both Handshake and
Initial packets to ensure that at least one of them is processable by Initial packets to ensure that at least one of them is processable by
the client. Similarly, a peer might be unable to read 1-RTT packets, the client. Similarly, a peer might be unable to read 1-RTT packets,
so an endpoint SHOULD send CONNECTION_CLOSE in Handshake and 1-RTT so an endpoint SHOULD send CONNECTION_CLOSE in Handshake and 1-RTT
packets prior to confirming the handshake. These packets can be packets prior to confirming the handshake. These packets can be
coalesced into a single UDP datagram; see Section 12.2. coalesced into a single UDP datagram; see Section 12.2.
An endpoint might send a CONNECTION_CLOSE frame in an Initial packet
or in response to unauthenticated information received in Initial or
Handshake packets. Such an immediate close might expose legitimate
connections to a denial of service. QUIC does not include defensive
measures for on-path attacks during the handshake; see Section 21.1.
However, at the cost of reducing feedback about errors for legitimate
peers, some forms of denial of service can be made more difficult for
an attacker if endpoints discard illegal packets rather than
terminating a connection with CONNECTION_CLOSE. For this reason,
endpoints MAY discard packets rather than immediately close if errors
are detected in packets that lack authentication.
An endpoint that has not established state, such as a server that
detects an error in an Initial packet, does not enter the closing
state. An endpoint that has no state for the connection does not
enter a closing or draining period on sending a CONNECTION_CLOSE
frame.
10.4. Stateless Reset 10.4. 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 signaling error conditions. A stateless reset is not appropriate for signaling error conditions.
skipping to change at page 68, line 50 skipping to change at page 68, line 19
If an application-level error affects a single stream, but otherwise If an application-level error affects a single stream, but otherwise
leaves the connection in a recoverable state, the endpoint can send a leaves the connection in a recoverable state, the endpoint can send a
RESET_STREAM frame (Section 19.4) with an appropriate error code to RESET_STREAM frame (Section 19.4) with an appropriate error code to
terminate just the affected stream. terminate just the affected stream.
Resetting a stream without the involvement of the application Resetting a stream without the involvement of the application
protocol could cause the application protocol to enter an protocol could cause the application protocol to enter an
unrecoverable state. RESET_STREAM MUST only be instigated by the unrecoverable state. RESET_STREAM MUST only be instigated by the
application protocol that uses QUIC. application protocol that uses QUIC.
RESET_STREAM carries an application error code, for which the The semantics of the application error code carried in RESET_STREAM
semantics are defined by the application protocol. Only the are defined by the application protocol. Only the application
application protocol is able to cause a stream to be terminated. A protocol is able to cause a stream to be terminated. A local
local instance of the application protocol uses a direct API call and instance of the application protocol uses a direct API call and a
a remote instance uses the STOP_SENDING frame, which triggers an remote instance uses the STOP_SENDING frame, which triggers an
automatic RESET_STREAM. automatic RESET_STREAM.
Application protocols SHOULD define rules for handling streams that Application protocols SHOULD define rules for handling streams that
are prematurely cancelled by either endpoint. are prematurely cancelled by either endpoint.
12. Packets and Frames 12. Packets and Frames
QUIC endpoints communicate by exchanging packets. Packets have QUIC endpoints communicate by exchanging packets. Packets have
confidentiality and integrity protection (see Section 12.1) and are confidentiality and integrity protection (see Section 12.1) and are
carried in UDP datagrams (see Section 12.2). carried in UDP datagrams (see Section 12.2).
skipping to change at page 69, line 32 skipping to change at page 69, line 9
Section 17.2.1). Section 17.2.1).
Packets with the short header (Section 17.3) are designed for minimal Packets with the short header (Section 17.3) are designed for minimal
overhead and are used after a connection is established and 1-RTT overhead and are used after a connection is established and 1-RTT
keys are available. keys are available.
12.1. Protected Packets 12.1. Protected Packets
All QUIC packets except Version Negotiation packets use authenticated All QUIC packets except Version Negotiation packets use authenticated
encryption with additional data (AEAD) [RFC5116] to provide encryption with additional data (AEAD) [RFC5116] to provide
confidentiality and integrity protection. Retry packets use an AEAD confidentiality and integrity protection. Retry packets use AEAD to
to provide integrity protection. Details of packet protection are provide integrity protection. Details of packet protection are found
found in [QUIC-TLS]; this section includes an overview of the in [QUIC-TLS]; this section includes an overview of the process.
process.
Initial packets are protected using keys that are statically derived. Initial packets are protected using keys that are statically derived.
This packet protection is not effective confidentiality protection. This packet protection is not effective confidentiality protection.
Initial protection only exists to ensure that the sender of the Initial protection only exists to ensure that the sender of the
packet is on the network path. Any entity that receives the Initial packet is on the network path. Any entity that receives the Initial
packet from a client can recover the keys necessary to remove packet packet from a client can recover the keys necessary to remove packet
protection or to generate packets that will be successfully protection or to generate packets that will be successfully
authenticated. authenticated.
All other packets are protected with keys derived from the All other packets are protected with keys derived from the
skipping to change at page 74, line 52 skipping to change at page 73, line 52
| 0x1b | PATH_RESPONSE | Section 19.18 | __01 | | 0x1b | PATH_RESPONSE | Section 19.18 | __01 |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | IH_1* | | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | IH_1* |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
Table 3: Frame Types Table 3: Frame Types
The "Packets" column in Table 3 does not form part of the IANA The "Packets" column in Table 3 does not form part of the IANA
registry (see Section 22.3). This column summarizes the types of registry (see Section 22.3). This column lists the types of packets
packets that each frame type can appear in, indicated as up to four that each frame type can appear in, indicated by the following
characters indicating: characters:
I: Initial (Section 17.2.2) I: Initial (Section 17.2.2)
H: Handshake (Section 17.2.4) H: Handshake (Section 17.2.4)
0: 0-RTT (Section 17.2.3) 0: 0-RTT (Section 17.2.3)
1: 1-RTT (Section 17.3) 1: 1-RTT (Section 17.3)
*: A CONNECTION_CLOSE frame of type 0x1c can appear in Initial, *: A CONNECTION_CLOSE frame of type 0x1c can appear in Initial,
skipping to change at page 75, line 32 skipping to change at page 74, line 32
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 QUIC frames are idempotent in this version of QUIC. That is, a All QUIC frames are idempotent in this version of QUIC. That is, a
valid frame does not cause undesirable side effects or errors when valid frame does not cause undesirable side effects or errors when
received more than once. received 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. Though a two-, four- or eight-byte encoding of possible encoding. For frame types defined in this document, this
the frame types defined in this document is possible, the Frame Type means a single-byte encoding, even though it is possible to encode
field for these frames is encoded on a single byte. For instance, these values as a two-, four- or eight-byte variable length integer.
though 0x4001 is a legitimate two-byte encoding for a variable-length For instance, though 0x4001 is a legitimate two-byte encoding for a
integer with a value of 1, PING frames are always encoded as a single variable-length integer with a value of 1, PING frames are always
byte with the value 0x01. An endpoint MAY treat the receipt of a encoded as a single byte with the value 0x01. This rule applies to
frame type that uses a longer encoding than necessary as a connection all current and future QUIC frame types. An endpoint MAY treat the
error of type PROTOCOL_VIOLATION. receipt of a frame type that uses a longer encoding than necessary as
a connection error of type PROTOCOL_VIOLATION.
13. Packetization and Reliability 13. Packetization and Reliability
A sender bundles one or more frames in a QUIC packet (see A sender bundles one or more frames in a QUIC packet (see
Section 12.4). Section 12.4).
A sender can minimize per-packet bandwidth and computational costs by A sender can minimize per-packet bandwidth and computational costs by
bundling as many frames as possible within a QUIC packet. A sender bundling as many frames as possible within a QUIC packet. A sender
MAY wait for a short period of time to bundle multiple frames before MAY wait for a short period of time to bundle multiple frames before
sending a packet that is not maximally packed, to avoid sending out sending a packet that is not maximally packed, to avoid sending out
skipping to change at page 79, line 48 skipping to change at page 78, line 48
limit the number of ACK Ranges it sends. A receiver can do this even limit the number of ACK Ranges it sends. A receiver can do this even
without receiving acknowledgment of its ACK frames, with the without receiving acknowledgment of its ACK frames, with the
knowledge this could cause the sender to unnecessarily retransmit knowledge this could cause the sender to unnecessarily retransmit
some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare
packets lost after sufficiently newer packets are acknowledged. packets lost after sufficiently newer packets are acknowledged.
Therefore, the receiver SHOULD repeatedly acknowledge newly received Therefore, the receiver SHOULD repeatedly acknowledge newly received
packets in preference to packets received in the past. packets in preference to packets received in the past.
13.2.5. Measuring and Reporting Host Delay 13.2.5. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between when An endpoint measures the delays intentionally introduced between the
the packet with the largest packet number is received and an time the packet with the largest packet number is received and the
acknowledgment is sent. The endpoint encodes this delay in the Ack time an acknowledgment is sent. The endpoint encodes this delay in
Delay field of an ACK frame (see Section 19.3). This allows the the Ack Delay field of an ACK frame (see Section 19.3). This allows
receiver of the ACK to adjust for any intentional delays, which is the receiver of the ACK to adjust for any intentional delays, which
important for getting a better estimate of the path RTT when is important for getting a better estimate of the path RTT when
acknowledgments are delayed. A packet might be held in the OS kernel acknowledgments are delayed. A packet might be held in the OS kernel
or elsewhere on the host before being processed. An endpoint MUST or elsewhere on the host before being processed. An endpoint MUST
NOT include delays that it does not control when populating the Ack NOT include delays that it does not control when populating the Ack
Delay field in an ACK frame. Delay field in an ACK frame.
13.2.6. ACK Frames and Packet Protection 13.2.6. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed (see Section 12.1). For number space as the packet being ACKed (see Section 12.1). For
instance, packets that are protected with 1-RTT keys MUST be instance, packets that are protected with 1-RTT keys MUST be
skipping to change at page 82, line 39 skipping to change at page 81, line 39
* The HANDSHAKE_DONE frame MUST be retransmitted until it is * The HANDSHAKE_DONE frame MUST be retransmitted until it is
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 receiver MUST to retransmit copies of frames from lost packets. A sender that
accept packets containing an outdated frame, such as a MAX_DATA frame retransmits copies of frames needs to handle decreases in available
carrying a smaller maximum data than one found in an older packet. payload size due to change in packet number length, connection ID
length, and path MTU. A receiver MUST accept packets containing an
outdated frame, such as a MAX_DATA frame carrying a smaller maximum
data than one found in an older packet.
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 Explicit Congestion Notification (ECN)
[RFC3168] to detect and respond to network congestion. ECN allows a [RFC3168] to detect and respond to network congestion. ECN allows a
network node to indicate congestion in the network by setting a network node to indicate congestion in the network by setting a
skipping to change at page 86, line 21 skipping to change at page 85, line 21
the amplitude of amplification attacks caused by server responses the amplitude of amplification attacks caused by server responses
toward an unverified client address; see Section 8. toward an unverified client address; see Section 8.
Datagrams containing Initial packets MAY exceed 1200 bytes if the Datagrams containing Initial packets MAY exceed 1200 bytes if the
client believes that the Path Maximum Transmission Unit (PMTU) client believes that the Path Maximum Transmission Unit (PMTU)
supports the size that it chooses. supports the size that it chooses.
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 to prevent fragmentation on the path. [IPv4], the DF bit MUST be set to prevent fragmentation on the path.
A server MAY send a CONNECTION_CLOSE frame with error code A server MUST discard an Initial packet that is carried in a UDP
PROTOCOL_VIOLATION in response to an Initial packet it receives from datagram that is smaller than 1200 bytes. A server MAY also
a client if the UDP datagram is smaller than 1200 bytes. It MUST NOT immediately close the connection by sending a CONNECTION_CLOSE frame
send any other frame type in response, or otherwise behave as if any with an error code of PROTOCOL_VIOLATION; see Section 10.3.1.
part of the offending packet was processed as valid.
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.1. Path Maximum Transmission Unit (PMTU) 14.1. Path Maximum Transmission Unit (PMTU)
The PMTU is the maximum size of the entire IP packet including the IP The PMTU is the maximum size of the entire IP packet including the IP
header, UDP header, and UDP payload. The UDP payload includes the header, UDP header, and UDP payload. The UDP payload includes the
QUIC packet header, protected payload, and any authentication fields. QUIC packet header, protected payload, and any authentication fields.
The PMTU can depend upon the current path characteristics. The PMTU can depend upon the current path characteristics.
skipping to change at page 92, line 26 skipping to change at page 91, line 26
| Destination Connection ID (0..160) ... | Destination Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCID Len (8) | | SCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0..160) ... | Source Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Long Header Packet Format Figure 9: 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 both conditions are met, 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. Packets Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
skipping to change at page 108, line 23 skipping to change at page 107, line 23
Connection ID field from the first Initial packet sent by the Connection ID field from the first Initial packet sent by the
client. This transport parameter is only sent by a server. This client. This transport parameter is only sent by a server. This
is the same value sent in the "Original Destination Connection ID" is the same value sent in the "Original Destination Connection ID"
field of a Retry packet (see Section 17.2.5). A server MUST field of a Retry packet (see Section 17.2.5). A server MUST
include the original_connection_id transport parameter if it sent include the original_connection_id transport parameter if it sent
a Retry packet. a Retry packet.
max_idle_timeout (0x0001): The max idle timeout is a value in max_idle_timeout (0x0001): The max idle timeout is a value in
milliseconds that is encoded as an integer; see (Section 10.2). milliseconds that is encoded as an integer; see (Section 10.2).
Idle timeout is disabled when both endpoints omit this transport Idle timeout is disabled when both endpoints omit this transport
parameteter or specify a value of 0. parameter or specify a value of 0.
stateless_reset_token (0x0002): A stateless reset token is used in stateless_reset_token (0x0002): A stateless reset token is used in
verifying a stateless reset; see Section 10.4. This parameter is verifying a stateless reset; see Section 10.4. This parameter is
a sequence of 16 bytes. This transport parameter MUST NOT be sent a sequence of 16 bytes. This transport parameter MUST NOT be sent
by a client, but MAY be sent by a server. A server that does not by a client, but MAY be sent by a server. A server that does not
send this transport parameter cannot use stateless reset send this transport parameter cannot use stateless reset
(Section 10.4) for the connection ID negotiated during the (Section 10.4) for the connection ID negotiated during the
handshake. handshake.
max_packet_size (0x0003): The maximum packet size parameter is an max_packet_size (0x0003): The maximum packet size parameter is an
skipping to change at page 111, line 37 skipping to change at page 110, line 37
+ + + +
| | | |
+ Stateless Reset Token (128) + + Stateless Reset Token (128) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Preferred Address format Figure 18: Preferred Address format
active_connection_id_limit (0x000e): The maximum number of active_connection_id_limit (0x000e): The active connection ID limit
connection IDs from the peer that an endpoint is willing to store. is an integer value specifying the maximum number of connection
This value includes the connection ID received during the IDs from the peer that an endpoint is willing to store. This
handshake, that received in the preferred_address transport value includes the connection ID received during the handshake,
parameter, and those received in NEW_CONNECTION_ID frames. Unless that received in the preferred_address transport parameter, and
a zero-length connection ID is being used, the value of the those received in NEW_CONNECTION_ID frames. Unless a zero-length
connection ID is being used, the value of the
active_connection_id_limit parameter MUST be no less than 2. If active_connection_id_limit parameter MUST be no less than 2. If
this transport parameter is absent, a default of 2 is assumed. this transport parameter is absent, a default of 2 is assumed.
When a zero-length connection ID is being used, the When a zero-length connection ID is being used, the
active_connection_id_limit parameter MUST NOT be sent. active_connection_id_limit parameter MUST NOT be sent.
If present, transport parameters that set initial flow control limits If present, transport parameters that set initial flow control limits
(initial_max_stream_data_bidi_local, (initial_max_stream_data_bidi_local,
initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni)
are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on
every stream of the corresponding type immediately after opening. If every stream of the corresponding type immediately after opening. If
skipping to change at page 131, line 32 skipping to change at page 130, line 32
successfully process a packet. This allows for efficient encoding of successfully process a packet. This allows for efficient encoding of
frames, but it means that an endpoint cannot send a frame of a type frames, but it means that an endpoint cannot send a frame of a type
that is unknown to its peer. that is unknown to its peer.
An extension to QUIC that wishes to use a new type of frame MUST An extension to QUIC that wishes to use a new type of frame MUST
first ensure that a peer is able to understand the frame. An first ensure that a peer is able to understand the frame. An
endpoint can use a transport parameter to signal its willingness to endpoint can use a transport parameter to signal its willingness to
receive one or more extension frame types with the one transport receive one or more extension frame types with the one transport
parameter. parameter.
Extensions that modify or replace core protocol functionality
(including frame types) will be difficult to combine with other
extensions which modify or replace the same functionality unless the
behavior of the combination is explicitly defined. Such extensions
SHOULD define their interaction with previously-defined extensions
modifying the same protocol components.
Extension frames MUST be congestion controlled and MUST cause an ACK Extension frames MUST be congestion controlled and MUST cause an ACK
frame to be sent. The exception is extension frames that replace or frame to be sent. The exception is extension frames that replace or
supplement the ACK frame. Extension frames are not included in flow supplement the ACK frame. Extension frames are not included in flow
control unless specified in the extension. control unless specified in the extension.
An IANA registry is used to manage the assignment of frame types; see An IANA registry is used to manage the assignment of frame types; see
Section 22.3. Section 22.3.
20. Transport Error Codes 20. Transport Error Codes
skipping to change at page 133, line 51 skipping to change at page 133, line 11
Once a connection is established QUIC endpoints might accept some Once a connection is established QUIC endpoints might accept some
unauthenticated ICMP packets (see Section 14.2), but the use of these unauthenticated ICMP packets (see Section 14.2), but the use of these
packets is extremely limited. The only other type of packet that an packets is extremely limited. The only other type of packet that an
endpoint might accept is a stateless reset (Section 10.4) which endpoint might accept is a stateless reset (Section 10.4) which
relies on the token being kept secret until it is used. relies on the token being kept secret until it is used.
During the creation of a connection, QUIC only provides protection During the creation of a connection, QUIC only provides protection
against attack from off the network path. All QUIC packets contain against attack from off the network path. All QUIC packets contain
proof that the recipient saw a preceding packet from its peer. proof that the recipient saw a preceding packet from its peer.
The first mechanism used is the source and destination connection Addresses cannot change during the handshake, so endpoints can
IDs, which are required to match those set by a peer. Except for an discard packets that are received on a different network path.
Initial and stateless reset packets, an endpoint only accepts packets
that include a destination connection that matches a connection ID
the endpoint previously chose. This is the only protection offered
for Version Negotiation packets.
The destination connection ID in an Initial packet is selected by a The Source and Destination Connection ID fields are the primary means
client to be unpredictable, which serves an additional purpose. The of protection against off-path attack during the handshake. These
packets that carry the cryptographic handshake are protected with a are required to match those set by a peer. Except for an Initial and
key that is derived from this connection ID and salt specific to the stateless reset packets, an endpoint only accepts packets that
QUIC version. This allows endpoints to use the same process for include a Destination Connection ID field that matches a value the
endpoint previously chose. This is the only protection offered for
Version Negotiation packets.
The Destination Connection ID field in an Initial packet is selected
by a client to be unpredictable, which serves an additional purpose.
The packets that carry the cryptographic handshake are protected with
a key that is derived from this connection ID and salt specific to
the QUIC version. This allows endpoints to use the same process for
authenticating packets that they receive as they use after the authenticating packets that they receive as they use after the
cryptographic handshake completes. Packets that cannot be cryptographic handshake completes. Packets that cannot be
authenticated are discarded. Protecting packets in this fashion authenticated are discarded. Protecting packets in this fashion
provides a strong assurance that the sender of the packet saw the provides a strong assurance that the sender of the packet saw the
Initial packet and understood it. Initial packet and understood it.
These protections are not intended to be effective against an These protections are not intended to be effective against an
attacker that is able to receive QUIC packets prior to the connection attacker that is able to receive QUIC packets prior to the connection
being established. Such an attacker can potentially send packets being established. Such an attacker can potentially send packets
that will be accepted by QUIC endpoints. This version of QUIC that will be accepted by QUIC endpoints. This version of QUIC
skipping to change at page 152, line 23 skipping to change at page 151, line 23
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg- <http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-
datagram-plpmtud-08.txt>. datagram-plpmtud-08.txt>.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", Work in Progress, Internet-Draft, and Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-25, 22 January 2020, draft-ietf-quic-recovery-26, 21 February 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-25>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-26>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", Work in Progress, Layer Security (TLS) to Secure QUIC", Work in Progress,
Internet-Draft, draft-ietf-quic-tls-25, 22 January 2020, Internet-Draft, draft-ietf-quic-tls-26, 21 February 2020,
<https://tools.ietf.org/html/draft-ietf-quic-tls-25>. <https://tools.ietf.org/html/draft-ietf-quic-tls-26>.
[RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery",
RFC 1191, DOI 10.17487/RFC1191, November 1990, RFC 1191, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 154, line 8 skipping to change at page 153, line 8
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic- Work in Progress, Internet-Draft, draft-ietf-quic-
invariants-07, 22 January 2020, invariants-07, 21 February 2020,
<https://tools.ietf.org/html/draft-ietf-quic-invariants- <https://tools.ietf.org/html/draft-ietf-quic-invariants-
07>. 07>.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-05, 5 July 2019, draft-ietf-quic-manageability-05, 5 July 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
manageability-05.txt>. manageability-05.txt>.
skipping to change at page 158, line 35 skipping to change at page 157, line 35
* Define error codes for invalid frames (#3027, #3042) * Define error codes for invalid frames (#3027, #3042)
* Idle timeout is symmetric (#2602, #3099) * Idle timeout is symmetric (#2602, #3099)
* Prohibit IP fragmentation (#3243, #3280) * Prohibit IP fragmentation (#3243, #3280)
* Define the use of provisional registration for all registries * Define the use of provisional registration for all registries
(#3109, #3020, #3102, #3170) (#3109, #3020, #3102, #3170)
* Packets on one path must not adjust values for a different path
(#2909, #3139)
C.2. Since draft-ietf-quic-transport-23 C.2. Since draft-ietf-quic-transport-23
* Allow ClientHello to span multiple packets (#2928, #3045) * Allow ClientHello to span multiple packets (#2928, #3045)
* Client Initial size constraints apply to UDP datagram payload * Client Initial size constraints apply to UDP datagram payload
(#3053, #3051) (#3053, #3051)
* Stateless reset changes (#2152, #2993) * Stateless reset changes (#2152, #2993)
- tokens need to be compared in constant time - tokens need to be compared in constant time
 End of changes. 48 change blocks. 
298 lines changed or deleted 340 lines changed or added

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