draft-ietf-quic-transport-19.txt   draft-ietf-quic-transport-20.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: September 12, 2019 Mozilla Expires: October 25, 2019 Mozilla
March 11, 2019 April 23, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-19 draft-ietf-quic-transport-20
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 September 12, 2019. This Internet-Draft will expire on October 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25
5.2. Matching Packets to Connections . . . . . . . . . . . . . 26 5.2. Matching Packets to Connections . . . . . . . . . . . . . 26
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 26 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 27
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 27 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 27
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 27 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 28
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 28 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 28
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28
6.2. Handling Version Negotiation Packets . . . . . . . . . . 28 6.2. Handling Version Negotiation Packets . . . . . . . . . . 29
6.2.1. Version Negotiation Between Draft Versions . . . . . 29 6.2.1. Version Negotiation Between Draft Versions . . . . . 29
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 29 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 30
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 33 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 34
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 35 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 36
8.1. Address Validation During Connection Establishment . . . 35 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 36
8.1.1. Address Validation using Retry Packets . . . . . . . 36 8.1. Address Validation During Connection Establishment . . . 37
8.1.2. Address Validation for Future Connections . . . . . . 37 8.1.1. Address Validation using Retry Packets . . . . . . . 37
8.1.3. Address Validation Token Integrity . . . . . . . . . 39 8.1.2. Address Validation for Future Connections . . . . . . 38
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 39 8.1.3. Address Validation Token Integrity . . . . . . . . . 40
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 40 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 40
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 40 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 41
8.5. Successful Path Validation . . . . . . . . . . . . . . . 41 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 42
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 41 8.5. Successful Path Validation . . . . . . . . . . . . . . . 42
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 42 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 42
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 43 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 43
9.2. Initiating Connection Migration . . . . . . . . . . . . . 43 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 44
9.3. Responding to Connection Migration . . . . . . . . . . . 44 9.2. Initiating Connection Migration . . . . . . . . . . . . . 44
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 44 9.3. Responding to Connection Migration . . . . . . . . . . . 45
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 45 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 45
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 45 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 46
9.4. Loss Detection and Congestion Control . . . . . . . . . . 46 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 47
9.5. Privacy Implications of Connection Migration . . . . . . 47 9.4. Loss Detection and Congestion Control . . . . . . . . . . 48
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 48 9.5. Privacy Implications of Connection Migration . . . . . . 49
9.6.1. Communicating A Preferred Address . . . . . . . . . . 48 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 49
9.6.2. Responding to Connection Migration . . . . . . . . . 49 9.6.1. Communicating A Preferred Address . . . . . . . . . . 50
9.6.3. Interaction of Client Migration and Preferred Address 49 9.6.2. Responding to Connection Migration . . . . . . . . . 50
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 50 9.6.3. Interaction of Client Migration and Preferred Address 51
10. Connection Termination . . . . . . . . . . . . . . . . . . . 50 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 51
10.1. Closing and Draining Connection States . . . . . . . . . 50 10. Connection Termination . . . . . . . . . . . . . . . . . . . 52
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 52 10.1. Closing and Draining Connection States . . . . . . . . . 52
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 52 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 53
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 53 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 54
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 56 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 55
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 56 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 58
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 57 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 58
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 58 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 59
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 58 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 60
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 59 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 60
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 59 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 61
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 59 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 61
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 60 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 61
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 61 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 62
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 62 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 63
13. Packetization and Reliability . . . . . . . . . . . . . . . . 65 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 64
13.1. Packet Processing and Acknowledgment . . . . . . . . . . 65 13. Packetization and Reliability . . . . . . . . . . . . . . . . 67
13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 66 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 68
13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 67 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 68
13.2. Retransmission of Information . . . . . . . . . . . . . 67 13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 69
13.3. Explicit Congestion Notification . . . . . . . . . . . . 69
13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 70 13.2. Retransmission of Information . . . . . . . . . . . . . 69
13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 70 13.3. Explicit Congestion Notification . . . . . . . . . . . . 72
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 72 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 72
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 73 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 73
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 73 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 74
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 74 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 75
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 75 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 76
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 76 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 77
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 77 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 77
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 77 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 78
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 78 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 79
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 80 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 79
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 82 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 80
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 84 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 83
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 85 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 84
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 86 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 87
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 89 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 88
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 90 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 89
18.1. Transport Parameter Definitions . . . . . . . . . . . . 91 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 91
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 94 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 93
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 94 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 94
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 95 18.1. Transport Parameter Definitions . . . . . . . . . . . . 95
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 95 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 98
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 97 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 98
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 98 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 99
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 99 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 99
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 100 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 101
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 100 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 102
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 101 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 103
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 102 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 104
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 103 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 104
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 104 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 105
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 105 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 106
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 106 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 107
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 106 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 108
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 107 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 109
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 107 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 110
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 109 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 110
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 110 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 111
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 110 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 111
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 110 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 113
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 111 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 114
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 112 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 114
20.1. Application Protocol Error Codes . . . . . . . . . . . . 113 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 114
21. Security Considerations . . . . . . . . . . . . . . . . . . . 113 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 115
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 113 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 116
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 114 20.1. Application Protocol Error Codes . . . . . . . . . . . . 117
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 115 21. Security Considerations . . . . . . . . . . . . . . . . . . . 117
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 115 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 117
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 115 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 118
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 116 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 119
21.7. Explicit Congestion Notification Attacks . . . . . . . . 116 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 119
21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 116 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 119
21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 117 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 120
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 21.7. Explicit Congestion Notification Attacks . . . . . . . . 120
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 117 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 121
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 119 21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 121
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 119 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 121
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 121 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 121
23.1. Normative References . . . . . . . . . . . . . . . . . . 122 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 123
23.2. Informative References . . . . . . . . . . . . . . . . . 123 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 124
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 125 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 126
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 125 23.1. Normative References . . . . . . . . . . . . . . . . . . 126
B.1. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 126 23.2. Informative References . . . . . . . . . . . . . . . . . 127
B.2. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 126 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 129
B.3. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 127 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 129
B.4. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 128 B.1. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 130
B.5. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 128 B.2. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 130
B.6. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 128 B.3. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 131
B.7. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 129 B.4. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 131
B.8. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 130 B.5. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 133
B.9. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 130 B.6. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 133
B.10. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 131 B.7. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 133
B.11. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 132 B.8. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 134
B.12. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 132 B.9. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 135
B.13. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 133 B.10. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 135
B.14. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 134 B.11. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 136
B.15. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 134 B.12. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 136
B.16. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 135 B.13. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 137
B.17. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 135 B.14. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 138
B.18. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 136 B.15. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 138
B.19. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 138 B.16. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 138
B.20. Since draft-hamilton-quic-transport-protocol-01 . . . . . 138 B.17. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 139
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 138 B.18. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 139
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 138 B.19. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 140
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 139 B.20. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 142
B.21. Since draft-hamilton-quic-transport-protocol-01 . . . . . 142
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 143
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143
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:
o Stream multiplexing o Stream multiplexing
o Stream and connection-level flow control o Stream and connection-level flow control
o Low-latency connection establishment o Low-latency connection establishment
o Connection migration and resilience to NAT rebinding o Connection migration and resilience to NAT rebinding
o Authenticated and encrypted header and payload o Authenticated and encrypted header and payload
QUIC uses UDP as a substrate to avoid requiring changes to legacy QUIC uses UDP as a substrate to avoid requiring changes to legacy
client operating systems and middleboxes. QUIC authenticates all of client operating systems and middleboxes. QUIC authenticates all of
its headers and encrypts most of the data it exchanges, including its its headers and encrypts most of the data it exchanges, including its
signaling, to avoid incurring a dependency on middleboxes. signaling, to avoid incurring a dependency on middleboxes.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
enters the "Data Read" state, which is a terminal state. enters the "Data Read" state, which is a terminal state.
Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states
causes the stream to enter the "Reset Recvd" state. This might cause causes the stream to enter the "Reset Recvd" state. This might cause
the delivery of stream data to the application to be interrupted. the delivery of stream data to the application to be interrupted.
It is possible that all stream data is received when a RESET_STREAM It is possible that all stream data is received when a RESET_STREAM
is received (that is, from the "Data Recvd" state). Similarly, it is is received (that is, from the "Data Recvd" state). Similarly, it is
possible for remaining stream data to arrive after receiving a possible for remaining stream data to arrive after receiving a
RESET_STREAM frame (the "Reset Recvd" state). An implementation is RESET_STREAM frame (the "Reset Recvd" state). An implementation is
free to manage this situation as it chooses. Sending RESET_STREAM free to manage this situation as it chooses.
means that an endpoint cannot guarantee delivery of stream data;
however there is no requirement that stream data not be delivered if Sending RESET_STREAM means that an endpoint cannot guarantee delivery
a RESET_STREAM is received. An implementation MAY interrupt delivery of stream data; however there is no requirement that stream data not
of stream data, discard any data that was not consumed, and signal be delivered if a RESET_STREAM is received. An implementation MAY
the receipt of the RESET_STREAM immediately. Alternatively, the interrupt delivery of stream data, discard any data that was not
RESET_STREAM signal might be suppressed or withheld if stream data is consumed, and signal the receipt of the RESET_STREAM. A RESET_STREAM
completely received and is buffered to be read by the application. signal might be suppressed or withheld if stream data is completely
In the latter case, the receiving part of the stream transitions from received and is buffered to be read by the application. If the
"Reset Recvd" to "Data Recvd". RESET_STREAM is suppressed, the receiving part of the stream remains
in "Data Recvd".
Once the application has been delivered the signal indicating that Once the application has been delivered the signal indicating that
the stream was reset, the receiving part of the stream transitions to the stream was reset, the receiving part of the stream transitions to
the "Reset Read" state, which is a terminal state. the "Reset Read" state, which is a terminal state.
3.3. Permitted Frame Types 3.3. Permitted Frame Types
The sender of a stream sends just three frame types that affect the The sender of a stream sends just three frame types that affect the
state of a stream at either sender or receiver: STREAM state of a stream at either sender or receiver: STREAM
(Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM
skipping to change at page 22, line 10 skipping to change at page 22, line 10
opposite direction. Both endpoints MUST maintain flow control state opposite direction. Both endpoints MUST maintain flow control state
for the stream in the unterminated direction until that direction for the stream in the unterminated direction until that direction
enters a terminal state, or until one of the endpoints sends enters a terminal state, or until one of the endpoints sends
CONNECTION_CLOSE. CONNECTION_CLOSE.
4.4. Stream Final Size 4.4. Stream Final Size
The final size is the amount of flow control credit that is consumed The final size is the amount of flow control credit that is consumed
by a stream. Assuming that every contiguous byte on the stream was by a stream. Assuming that every contiguous byte on the stream was
sent once, the final size is the number of bytes sent. More sent once, the final size is the number of bytes sent. More
generally, this is one higher than the largest byte offset sent on generally, this is one higher than the offset of the byte with the
the stream. largest offset sent on the stream, or zero if no bytes were sent.
For a stream that is reset, the final size is carried explicitly in a For a stream that is reset, the final size is carried explicitly in a
RESET_STREAM frame. Otherwise, the final size is the offset plus the RESET_STREAM frame. Otherwise, the final size is the offset plus the
length of a STREAM frame marked with a FIN flag, or 0 in the case of length of a STREAM frame marked with a FIN flag, or 0 in the case of
incoming unidirectional streams. incoming unidirectional streams.
An endpoint will know the final size for a stream when the receiving An endpoint will know the final size for a stream when the receiving
part of the stream enters the "Size Known" or "Reset Recvd" state part of the stream enters the "Size Known" or "Reset Recvd" state
(Section 3). (Section 3).
skipping to change at page 22, line 46 skipping to change at page 22, line 46
4.5. Controlling Concurrency 4.5. Controlling Concurrency
An endpoint limits the cumulative number of incoming streams a peer An endpoint limits the cumulative number of incoming streams a peer
can open. Only streams with a stream ID less than (max_stream * 4 + can open. Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened (see Table 5). Initial initial_stream_id_for_type) can be opened (see Table 5). Initial
limits are set in the transport parameters (see Section 18.1) and limits are set in the transport parameters (see Section 18.1) and
subsequently limits are advertised using MAX_STREAMS frames subsequently limits are advertised using MAX_STREAMS frames
(Section 19.11). Separate limits apply to unidirectional and (Section 19.11). Separate limits apply to unidirectional and
bidirectional streams. bidirectional streams.
If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer (see
Section 16). If either is received, the connection MUST be closed
immediately with a connection error of type STREAM_LIMIT_ERROR (see
Section 10.3).
Endpoints MUST NOT exceed the limit set by their peer. An endpoint Endpoints MUST NOT exceed the limit set by their peer. An endpoint
that receives a STREAM frame with a stream ID exceeding the limit it that receives a STREAM frame with a stream ID exceeding the limit it
has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR
(Section 11). (Section 11).
A receiver cannot renege on an advertisement. That is, once a A receiver cannot renege on an advertisement. That is, once a
receiver advertises a stream limit using the MAX_STREAMS frame, receiver advertises a stream limit using the MAX_STREAMS frame,
advertising a smaller limit has no effect. A receiver MUST ignore advertising a smaller limit has no effect. A receiver MUST ignore
any MAX_STREAMS frame that does not increase the stream limit. any MAX_STREAMS frame that does not increase the stream limit.
skipping to change at page 29, line 31 skipping to change at page 29, line 44
provided by the server. The client then attempts to create a new provided by the server. The client then attempts to create a new
connection using that version. The new connection MUST use a new connection using that version. The new connection MUST use a new
random Destination Connection ID different from the one it had random Destination Connection ID different from the one it had
previously sent. previously sent.
Note that this mechanism does not protect against downgrade attacks Note that this mechanism does not protect against downgrade attacks
and MUST NOT be used outside of draft implementations. and MUST NOT be used outside of draft implementations.
6.3. Using Reserved Versions 6.3. Using Reserved Versions
For a server to use a new version in the future, clients must For a server to use a new version in the future, clients need to
correctly handle unsupported versions. To help ensure this, a server correctly handle unsupported versions. To help ensure this, a server
SHOULD include a reserved version (see Section 15) while generating a SHOULD include a version that is reserved for forcing version
negotiation (0x?a?a?a?a as defined in Section 15) when generating a
Version Negotiation packet. Version Negotiation packet.
The design of version negotiation permits a server to avoid The design of version negotiation permits a server to avoid
maintaining state for packets that it rejects in this fashion. maintaining state for packets that it rejects in this fashion.
A client MAY send a packet using a reserved version number. This can A client MAY send a packet using a version that is reserved for
be used to solicit a list of supported versions from a server. forcing version negotiation. This can be used to solicit a list of
supported versions from a server.
7. Cryptographic and Transport Handshake 7. Cryptographic and Transport Handshake
QUIC relies on a combined cryptographic and transport handshake to QUIC relies on a combined cryptographic and transport handshake to
minimize connection establishment latency. QUIC uses the CRYPTO minimize connection establishment latency. QUIC uses the CRYPTO
frame Section 19.6 to transmit the cryptographic handshake. Version frame Section 19.6 to transmit the cryptographic handshake. Version
0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different
QUIC version number could indicate that a different cryptographic QUIC version number could indicate that a different cryptographic
handshake protocol is in use. handshake protocol is in use.
skipping to change at page 34, line 19 skipping to change at page 34, line 40
once in a given transport parameters extension. An endpoint MUST once in a given transport parameters extension. An endpoint MUST
treat receipt of duplicate transport parameters as a connection error treat receipt of duplicate transport parameters as a connection error
of type TRANSPORT_PARAMETER_ERROR. of type TRANSPORT_PARAMETER_ERROR.
A server MUST include the original_connection_id transport parameter A server MUST include the original_connection_id transport parameter
(Section 18.1) if it sent a Retry packet to enable validation of the (Section 18.1) if it sent a Retry packet to enable validation of the
Retry, as described in Section 17.2.5. Retry, as described in Section 17.2.5.
7.3.1. Values of Transport Parameters for 0-RTT 7.3.1. Values of Transport Parameters for 0-RTT
A client that attempts to send 0-RTT data MUST remember the transport Both endpoints store the value of the server transport parameters
parameters used by the server. The transport parameters that the from a connection and apply them to any 0-RTT packets that are sent
server advertises during connection establishment apply to all in subsequent connections to that peer, except for transport
connections that are resumed using the keying material established parameters that are explicitly excluded. Remembered transport
during that handshake. Remembered transport parameters apply to the parameters apply to the new connection until the handshake completes
new connection until the handshake completes and new transport and the client starts sending 1-RTT packets. Once the handshake
parameters from the server can be provided. completes, the client uses the transport parameters established in
the handshake.
A server can remember the transport parameters that it advertised, or The definition of new transport parameters (Section 7.3.2) MUST
store an integrity-protected copy of the values in the ticket and specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A
recover the information when accepting 0-RTT data. A server uses the client need not store a transport parameter it cannot process.
transport parameters in determining whether to accept 0-RTT data.
A server MAY accept 0-RTT and subsequently provide different values A client MUST NOT use remembered values for the following parameters:
for transport parameters for use in the new connection. If 0-RTT original_connection_id, preferred_address, stateless_reset_token, and
data is accepted by the server, the server MUST NOT reduce any limits ack_delay_exponent. The client MUST use the server's new values in
or alter any values that might be violated by the client with its the handshake instead, and absent new values from the server, the
0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT default value.
set values for the following parameters (Section 18.1) that are
smaller than the remembered value of those parameters. A client that attempts to send 0-RTT data MUST remember all other
transport parameters used by the server. The server can remember
these transport parameters, or store an integrity-protected copy of
the values in the ticket and recover the information when accepting
0-RTT data. A server uses the transport parameters in determining
whether to accept 0-RTT data.
If 0-RTT data is accepted by the server, the server MUST NOT reduce
any limits or alter any values that might be violated by the client
with its 0-RTT data. In particular, a server that accepts 0-RTT data
MUST NOT set values for the following parameters (Section 18.1) that
are smaller than the remembered value of the parameters.
o initial_max_data o initial_max_data
o initial_max_stream_data_bidi_local o initial_max_stream_data_bidi_local
o initial_max_stream_data_bidi_remote o initial_max_stream_data_bidi_remote
o initial_max_stream_data_uni o initial_max_stream_data_uni
o initial_max_streams_bidi o initial_max_streams_bidi
skipping to change at page 35, line 4 skipping to change at page 35, line 35
o initial_max_stream_data_bidi_local o initial_max_stream_data_bidi_local
o initial_max_stream_data_bidi_remote o initial_max_stream_data_bidi_remote
o initial_max_stream_data_uni o initial_max_stream_data_uni
o initial_max_streams_bidi o initial_max_streams_bidi
o initial_max_streams_uni o initial_max_streams_uni
Omitting or setting a zero value for certain transport parameters can Omitting or setting a zero value for certain transport parameters can
result in 0-RTT data being enabled, but not usable. The applicable result in 0-RTT data being enabled, but not usable. The applicable
subset of transport parameters that permit sending of application subset of transport parameters that permit sending of application
data SHOULD be set to non-zero values for 0-RTT. This includes data SHOULD be set to non-zero values for 0-RTT. This includes
initial_max_data and either initial_max_streams_bidi and initial_max_data and either initial_max_streams_bidi and
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_bidi_remote, or initial_max_streams_uni and
initial_max_stream_data_uni. initial_max_stream_data_uni.
The value of the server's previous preferred_address MUST NOT be used
when establishing a new connection; rather, the client should wait to
observe the server's new preferred_address value in the handshake.
A server MUST either reject 0-RTT data or abort a handshake if the A server MUST either reject 0-RTT data or abort a handshake if the
implied values for transport parameters cannot be supported. implied values for transport parameters cannot be supported.
7.3.2. New Transport Parameters 7.3.2. New Transport Parameters
New transport parameters can be used to negotiate new protocol New transport parameters can be used to negotiate new protocol
behavior. An endpoint MUST ignore transport parameters that it does behavior. An endpoint MUST ignore transport parameters that it does
not support. Absence of a transport parameter therefore disables any not support. Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter. optional protocol feature that is negotiated using the parameter.
New transport parameters can be registered according to the rules in New transport parameters can be registered according to the rules in
Section 22.1. Section 22.1.
7.4. Cryptographic Message Buffering
Implementations need to maintain a buffer of CRYPTO data received out
of order. Because there is no flow control of CRYPTO frames, an
endpoint could potentially force its peer to buffer an unbounded
amount of data.
Implementations MUST support buffering at least 4096 bytes of data
received in CRYPTO frames out of order. Endpoints MAY choose to
allow more data to be buffered during the handshake. A larger limit
during the handshake could allow for larger keys or credentials to be
exchanged. An endpoint's buffer size does not need to remain
constant during the life of the connection.
Being unable to buffer CRYPTO frames during the handshake can lead to
a connection failure. If an endpoint's buffer is exceeded during the
handshake, it can expand its buffer temporarily to complete the
handshake. If an endpoint does not expand its buffer, it MUST close
the connection with a CRYPTO_BUFFER_EXCEEDED error code.
Once the handshake completes, if an endpoint is unable to buffer all
data in a CRYPTO frame, it MAY discard that CRYPTO frame and all
CRYPTO frames received in the future, or it MAY close the connection
with an CRYPTO_BUFFER_EXCEEDED error code. Packets containing
discarded CRYPTO frames MUST be acknowledged because the packet has
been received and processed by the transport even though the CRYPTO
frame was discarded.
8. Address Validation 8. Address Validation
Address validation is used by QUIC to avoid being used for a traffic Address validation is used by QUIC to avoid being used for a traffic
amplification attack. In such an attack, a packet is sent to a amplification attack. In such an attack, a packet is sent to a
server with spoofed source address information that identifies a server with spoofed source address information that identifies a
victim. If a server generates more or larger packets in response to victim. If a server generates more or larger packets in response to
that packet, the attacker can use the server to send more data toward that packet, the attacker can use the server to send more data toward
the victim than it would be able to send on its own. the victim than it would be able to send on its own.
The primary defense against amplification attack is verifying that an The primary defense against amplification attack is verifying that an
skipping to change at page 36, line 11 skipping to change at page 37, line 20
from the server. Once the server has successfully processed a from the server. Once the server has successfully processed a
Handshake packet from the client, it can consider the client address Handshake packet from the client, it can consider the client address
to have been validated. to have been validated.
Prior to validating the client address, servers MUST NOT send more Prior to validating the client address, servers MUST NOT send more
than three times as many bytes as the number of bytes they have than three times as many bytes as the number of bytes they have
received. This limits the magnitude of any amplification attack that received. This limits the magnitude of any amplification attack that
can be mounted using spoofed source addresses. In determining this can be mounted using spoofed source addresses. In determining this
limit, servers only count the size of successfully processed packets. limit, servers only count the size of successfully processed packets.
Clients MUST pad UDP datagrams that contain only Initial packets to Clients MUST ensure that UDP datagrams containing only Initial
at least 1200 bytes. Once a client has received an acknowledgment packets are sized to at least 1200 bytes, adding padding to packets
for a Handshake packet it MAY send smaller datagrams. Sending padded in the datagram as necessary. Sending padded datagrams ensures that
datagrams ensures that the server is not overly constrained by the the server is not overly constrained by the amplification
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 crypto retransmission timeout, as clients SHOULD send a packet upon a crypto retransmission timeout, as
described in [QUIC-RECOVERY]. If the client has no data to described in [QUIC-RECOVERY]. If the client has no data to
retransmit and does not have Handshake keys, it SHOULD send an retransmit and does not have Handshake keys, it SHOULD send an
Initial packet in a UDP datagram of at least 1200 bytes. If the Initial packet in a UDP datagram of at least 1200 bytes. If the
client has Handshake keys, it SHOULD send a Handshake packet. client has Handshake keys, it SHOULD send a Handshake packet.
skipping to change at page 54, line 47 skipping to change at page 56, line 31
This design ensures that a stateless reset packet is - to the extent This design ensures that a stateless reset packet is - to the extent
possible - indistinguishable from a regular packet with a short possible - indistinguishable from a regular packet with a short
header. header.
A stateless reset uses an entire UDP datagram, starting with the A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header. The remainder of the first byte first two bits of the packet header. The remainder of the first byte
and an arbitrary number of bytes following it that are set to and an arbitrary number of bytes following it that are set to
unpredictable values. The last 16 bytes of the datagram contain a unpredictable values. The last 16 bytes of the datagram contain a
Stateless Reset Token. Stateless Reset Token.
A stateless reset will be interpreted by a recipient as a packet with To entities other than its intended recipient, a stateless reset will
a short header. For the packet to appear as valid, the Unpredictable be appear to be a packet with a short header. For the packet to
Bits field needs to include at least 182 bits of data (or 23 bytes, appear as valid, the Unpredictable Bits field needs to include at
less the two fixed bits). This is intended to allow for a least 182 bits of data (or 23 bytes, less the two fixed bits). This
Destination Connection ID of the maximum length permitted, with a is intended to allow for a Destination Connection ID of the maximum
minimal packet number, and payload. The Stateless Reset Token length permitted, with a minimal packet number, and payload. The
corresponds to the minimum expansion of the packet protection AEAD. Stateless Reset Token corresponds to the minimum expansion of the
More unpredictable bytes might be necessary if the endpoint could packet protection AEAD. More unpredictable bytes might be necessary
have negotiated a packet protection scheme with a larger minimum AEAD if the endpoint could have negotiated a packet protection scheme with
expansion. a larger minimum AEAD expansion.
An endpoint SHOULD NOT send a stateless reset that is significantly An endpoint SHOULD NOT send a stateless reset that is significantly
larger than the packet it receives. Endpoints MUST discard packets larger than the packet it receives. Endpoints MUST discard packets
that are too small to be valid QUIC packets. With the set of AEAD that are too small to be valid QUIC packets. With the set of AEAD
functions defined in [QUIC-TLS], packets that are smaller than 21 functions defined in [QUIC-TLS], packets that are smaller than 21
bytes are never valid. bytes are never valid.
Endpoints MUST send stateless reset packets formatted as a packet
with a short header. However, endpoints MUST treat any packet ending
in a valid stateless reset token as a stateless reset, as other QUIC
versions might allow the use of a long header.
An endpoint MAY send a stateless reset in response to a packet with a An endpoint MAY send a stateless reset in response to a packet with a
long header. This would not be effective if the stateless reset long header. Sending a stateless reset is not effective prior to the
token was not yet available to a peer. In this QUIC version, packets stateless reset token being available to a peer. In this QUIC
with a long header are only used during connection establishment. version, packets with a long header are only used during connection
Because the stateless reset token is not available until connection establishment. Because the stateless reset token is not available
establishment is complete or near completion, ignoring an unknown until connection establishment is complete or near completion,
packet with a long header might be more effective. ignoring an unknown packet with a long header might be as effective
than sending a stateless reset.
An endpoint cannot determine the Source Connection ID from a packet An endpoint cannot determine the Source Connection ID from a packet
with a short header, therefore it cannot set the Destination with a short header, therefore it cannot set the Destination
Connection ID in the stateless reset packet. The Destination Connection ID in the stateless reset packet. The Destination
Connection ID will therefore differ from the value used in previous Connection ID will therefore differ from the value used in previous
packets. A random Destination Connection ID makes the connection ID packets. A random Destination Connection ID makes the connection ID
appear to be the result of moving to a new connection ID that was appear to be the result of moving to a new connection ID that was
provided using a NEW_CONNECTION_ID frame (Section 19.15). provided using a NEW_CONNECTION_ID frame (Section 19.15).
Using a randomized connection ID results in two problems: Using a randomized connection ID results in two problems:
skipping to change at page 56, line 15 skipping to change at page 58, line 7
This stateless reset design is specific to QUIC version 1. An This stateless reset design is specific to QUIC version 1. An
endpoint that supports multiple versions of QUIC needs to generate a endpoint that supports multiple versions of QUIC needs to generate a
stateless reset that will be accepted by peers that support any stateless reset that will be accepted by peers that support any
version that the endpoint might support (or might have supported version that the endpoint might support (or might have supported
prior to losing state). Designers of new versions of QUIC need to be prior to losing state). Designers of new versions of QUIC need to be
aware of this and either reuse this design, or use a portion of the aware of this and either reuse this design, or use a portion of the
packet other than the last 16 bytes for carrying data. packet other than the last 16 bytes for carrying data.
10.4.1. Detecting a Stateless Reset 10.4.1. Detecting a Stateless Reset
An endpoint detects a potential stateless reset when a incoming An endpoint detects a potential stateless reset when an incoming
packet with a short header either cannot be associated with a packet either cannot be associated with a connection, cannot be
connection, cannot be decrypted, or is marked as a duplicate packet. decrypted, or is marked as a duplicate packet. The endpoint MUST
The endpoint then compares the last 16 bytes of the packet with the then compare the last 16 bytes of the packet with all Stateless Reset
Stateless Reset Token provided by its peer, either in a Tokens that are associated with connection IDs that are currently in
NEW_CONNECTION_ID frame or the server's transport parameters. If use. This includes Stateless Reset Tokens from NEW_CONNECTION_ID
these values are identical, the endpoint MUST enter the draining frames and the server's transport parameters. An endpoint MUST NOT
period and not send any further packets on this connection. If the check for any Stateless Reset Tokens associated with connection IDs
it has not used or for connection IDs that have been retired.
If the last 16 bytes of the packet values are identical to a
Stateless Reset Token, the endpoint MUST enter the draining period
and not send any further packets on this connection. If the
comparison fails, the packet can be discarded. comparison fails, the packet can be discarded.
10.4.2. Calculating a Stateless Reset Token 10.4.2. Calculating a Stateless Reset Token
The stateless reset token MUST be difficult to guess. In order to The stateless reset token MUST be difficult to guess. In order to
create a Stateless Reset Token, an endpoint could randomly generate create a Stateless Reset Token, an endpoint could randomly generate
[RFC4086] a secret for every connection that it creates. However, [RFC4086] a secret for every connection that it creates. However,
this presents a coordination problem when there are multiple this presents a coordination problem when there are multiple
instances in a cluster or a storage problem for an endpoint that instances in a cluster or a storage problem for an endpoint that
might lose state. Stateless reset specifically exists to handle the might lose state. Stateless reset specifically exists to handle the
skipping to change at page 57, line 11 skipping to change at page 59, line 8
packets so that the endpoint can use the connection ID from a packet packets so that the endpoint can use the connection ID from a packet
to reset the connection. An endpoint that uses this design MUST to reset the connection. An endpoint that uses this design MUST
either use the same connection ID length for all connections or either use the same connection ID length for all connections or
encode the length of the connection ID such that it can be recovered encode the length of the connection ID such that it can be recovered
without state. In addition, it cannot provide a zero-length without state. In addition, it cannot provide a zero-length
connection ID. connection ID.
Revealing the Stateless Reset Token allows any entity to terminate Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once. This method for the connection, so a value can only be used once. This method for
choosing the Stateless Reset Token means that the combination of choosing the Stateless Reset Token means that the combination of
connection ID and static key cannot occur for another connection. A connection ID and static key MUST NOT be used for another connection.
denial of service attack is possible if the same connection ID is A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the cause a packet to be routed to an instance that has no state but the
same static key (see Section 21.8). A connection ID from a same static key (see Section 21.8). A connection ID from a
connection that is reset by revealing the Stateless Reset Token connection that is reset by revealing the Stateless Reset Token MUST
cannot be reused for new connections at nodes that share a static NOT be reused for new connections at nodes that share a static key.
key.
Note that Stateless Reset packets do not have any cryptographic Note that Stateless Reset packets do not have any cryptographic
protection. protection.
10.4.3. Looping 10.4.3. Looping
The design of a Stateless Reset is such that without knowing the The design of a Stateless Reset is such that without knowing the
stateless reset token it is indistinguishable from a valid packet. stateless reset token it is indistinguishable from a valid packet.
For instance, if a server sends a Stateless Reset to another server For instance, if a server sends a Stateless Reset to another server
it might receive another Stateless Reset in response, which could it might receive another Stateless Reset in response, which could
skipping to change at page 62, line 36 skipping to change at page 64, line 31
happen after removing packet protection for the reasons described in happen after removing packet protection for the reasons described in
Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate
suppression can be found in Section 3.4.3 of [RFC4303]. suppression can be found in Section 3.4.3 of [RFC4303].
Packet number encoding at a sender and decoding at a receiver are Packet number encoding at a sender and decoding at a receiver are
described in Section 17.1. described in Section 17.1.
12.4. Frames and Frame Types 12.4. Frames and Frame Types
The payload of QUIC packets, after removing packet protection, The payload of QUIC packets, after removing packet protection,
commonly consists of a sequence of frames, as shown in Figure 7. consists of a sequence of complete frames, as shown in Figure 7.
Version Negotiation, Stateless Reset, and Retry packets do not Version Negotiation, Stateless Reset, and Retry packets do not
contain frames. contain frames.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame 1 (*) ... | Frame 1 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame 2 (*) ... | Frame 2 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame N (*) ... | Frame N (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: QUIC Payload Figure 7: QUIC Payload
QUIC payloads MUST contain at least one frame, and MAY contain The payload of a packet that contains frames MUST contain at least
multiple frames and multiple frame types. one frame, and MAY contain multiple frames and multiple frame types.
Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC Frames always fit within a single QUIC packet and cannot span
packet boundary. Each frame begins with a Frame Type, indicating its multiple packets.
type, followed by additional type-dependent fields:
Each frame begins with a Frame Type, indicating its type, followed by
additional type-dependent fields:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Type (i) ... | Frame Type (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-Dependent Fields (*) ... | Type-Dependent Fields (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Generic Frame Layout Figure 8: Generic Frame Layout
The frame types defined in this specification are listed in Table 3. The frame types defined in this specification are listed in Table 3.
The Frame Type in STREAM frames is used to carry other frame-specific The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and
flags. For all other frames, the Frame Type field simply identifies CONNECTION_CLOSE frames is used to carry other frame-specific flags.
the frame. These frames are explained in more detail in Section 19. For all other frames, the Frame Type field simply identifies the
frame. These frames are explained in more detail in Section 19.
+-------------+----------------------+---------------+ +-------------+----------------------+---------------+
| Type Value | Frame Type Name | Definition | | Type Value | Frame Type Name | Definition |
+-------------+----------------------+---------------+ +-------------+----------------------+---------------+
| 0x00 | PADDING | Section 19.1 | | 0x00 | PADDING | Section 19.1 |
| | | | | | | |
| 0x01 | PING | Section 19.2 | | 0x01 | PING | Section 19.2 |
| | | | | | | |
| 0x02 - 0x03 | ACK | Section 19.3 | | 0x02 - 0x03 | ACK | Section 19.3 |
| | | | | | | |
skipping to change at page 64, line 49 skipping to change at page 66, line 49
| | | | | | | |
| 0x1a | PATH_CHALLENGE | Section 19.17 | | 0x1a | PATH_CHALLENGE | Section 19.17 |
| | | | | | | |
| 0x1b | PATH_RESPONSE | Section 19.18 | | 0x1b | PATH_RESPONSE | Section 19.18 |
| | | | | | | |
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 |
+-------------+----------------------+---------------+ +-------------+----------------------+---------------+
Table 3: Frame Types Table 3: Frame Types
An endpoint MUST treat the receipt of a frame of unknown type as a
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. Though a two-, four- or eight-byte encoding of
the frame types defined in this document is possible, the Frame Type the frame types defined in this document is possible, the Frame Type
field for these frames is encoded on a single byte. For instance, field for these frames is encoded on a single byte. For instance,
skipping to change at page 77, line 5 skipping to change at page 79, line 11
+------+--------+-------------+-----------------------+ +------+--------+-------------+-----------------------+
Table 4: Summary of Integer Encodings Table 4: Summary of Integer Encodings
For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in
hexadecimal) decodes to the decimal value 151288809941952652; the hexadecimal) decodes to the decimal value 151288809941952652; the
four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte
sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37
(as does the two byte sequence 40 25). (as does the two byte sequence 40 25).
Error codes (Section 20) and versions Section 15 are described using Error codes (Section 20) and versions (Section 15) are described
integers, but do not use this encoding. using integers, but do not use this encoding.
17. Packet Formats 17. Packet Formats
All numeric values are encoded in network byte order (that is, big- All numeric values are encoded in network byte order (that is, big-
endian) and all field sizes are in bits. Hexadecimal notation is endian) and all field sizes are in bits. Hexadecimal notation is
used for describing the value of fields. used for describing the value of fields.
17.1. Packet Number Encoding and Decoding 17.1. Packet Number Encoding and Decoding
Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3).
skipping to change at page 81, line 30 skipping to change at page 83, line 48
| [Supported Version 2 (32)] ... | [Supported Version 2 (32)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version N (32)] ... | [Supported Version N (32)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Version Negotiation Packet Figure 10: Version Negotiation Packet
The value in the Unused field is selected randomly by the server. The value in the Unused field is selected randomly by the server.
Clients MUST ignore the value of this field. Servers SHOULD set the
most significant bit of this field (0x40) to 1 so that Version
Negotiation packets appear to have the Fixed Bit field.
The Version field of a Version Negotiation packet MUST be set to The Version field of a Version Negotiation packet MUST be set to
0x00000000. 0x00000000.
The server MUST include the value from the Source Connection ID field The server MUST include the value from the Source Connection ID field
of the packet it receives in the Destination Connection ID field. of the packet it receives in the Destination Connection ID field.
The value for Source Connection ID MUST be copied from the The value for Source Connection ID MUST be copied from the
Destination Connection ID of the received packet, which is initially Destination Connection ID of the received packet, which is initially
randomly selected by a client. Echoing both connection IDs gives randomly selected by a client. Echoing both connection IDs gives
clients some assurance that the server received the packet and that clients some assurance that the server received the packet and that
skipping to change at page 89, line 44 skipping to change at page 92, line 30
negotiated. Packets that use the short header contain the following negotiated. Packets that use the short header contain the following
fields: fields:
Header Form: The most significant bit (0x80) of byte 0 is set to 0 Header Form: The most significant bit (0x80) of byte 0 is set to 0
for the short header. for the short header.
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
containing a zero value for this bit are not valid packets in this containing a zero value for this bit are not valid packets in this
version and MUST be discarded. version and MUST be discarded.
Spin Bit (S): The sixth bit (0x20) of byte 0 is the Latency Spin Spin Bit (S): The third most significant bit (0x20) of byte 0 is the
Bit, set as described in [SPIN]. latency spin bit, set as described in Section 17.3.1.
Reserved Bits (R): The next two bits (those with a mask of 0x18) of Reserved Bits (R): The next two bits (those with a mask of 0x18) of
byte 0 are reserved. These bits are protected using header byte 0 are reserved. These bits are protected using header
protection (see Section 5.4 of [QUIC-TLS]). The value included protection (see Section 5.4 of [QUIC-TLS]). The value included
prior to protection MUST be set to 0. An endpoint MUST treat prior to protection MUST be set to 0. An endpoint MUST treat
receipt of a packet that has a non-zero value for these bits, receipt of a packet that has a non-zero value for these bits,
after removing both packet and header protection, as a connection after removing both packet and header protection, as a connection
error of type PROTOCOL_VIOLATION. Discarding such a packet after error of type PROTOCOL_VIOLATION. Discarding such a packet after
only removing header protection can expose the endpoint to attacks only removing header protection can expose the endpoint to attacks
(see Section 9.3 of [QUIC-TLS]). (see Section 9.3 of [QUIC-TLS]).
skipping to change at page 90, line 40 skipping to change at page 93, line 26
field. See Section 17.1 for details. field. See Section 17.1 for details.
Protected Payload: Packets with a short header always include a Protected Payload: Packets with a short header always include a
1-RTT protected payload. 1-RTT protected payload.
The header form bit and the connection ID field of a short header The header form bit and the connection ID field of a short header
packet are version-independent. The remaining fields are specific to packet are version-independent. The remaining fields are specific to
the selected QUIC version. See [QUIC-INVARIANTS] for details on how the selected QUIC version. See [QUIC-INVARIANTS] for details on how
packets from different versions of QUIC are interpreted. packets from different versions of QUIC are interpreted.
17.3.1. Latency Spin Bit
The latency spin bit enables passive latency monitoring from
observation points on the network path throughout the duration of a
connection. The spin bit is only present in the short packet header,
since it is possible to measure the initial RTT of a connection by
observing the handshake. Therefore, the spin bit is available after
version negotiation and connection establishment are completed. On-
path measurement and use of the latency spin bit is further discussed
in [QUIC-MANAGEABILITY].
The spin bit is an OPTIONAL feature of QUIC. A QUIC stack that
chooses to support the spin bit MUST implement it as specified in
this section.
Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection. Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on
a per-connection basis. Even when the spin bit is not disabled by
the administrator, implementations MUST disable the spin bit for a
given connection with a certain likelihood. The random selection
process SHOULD be designed such that on average the spin bit is
disabled for at least one eighth of connections. The selection
process performed at the beginning of the connection SHOULD be
applied for all paths used by the connection.
In case multiple connections share the same five-tuple, that is, have
the same source and destination IP address and UDP ports, endpoints
should try to co-ordinate across all connections to ensure a clear
signal to any on-path measurement points.
When the spin bit is disabled, endpoints MAY set the spin bit to any
value, and MUST ignore any incoming value. It is RECOMMENDED that
endpoints set the spin bit to a random value either chosen
independently for each packet or chosen independently for each
connection ID.
If the spin bit is enabled for the connection, the endpoint maintains
a spin value and sets the spin bit in the short header to the
currently stored value when a packet with a short header is sent out.
The spin value is initialized to 0 in the endpoint at connection
start. Each endpoint also remembers the highest packet number seen
from its peer on the connection.
When a server receives a short header packet that increments the
highest packet number seen by the server from the client, it sets the
spin value to be equal to the spin bit in the received packet.
When a client receives a short header packet that increments the
highest packet number seen by the client from the server, it sets the
spin value to the inverse of the spin bit in the received packet.
An endpoint resets its spin value to zero when sending the first
packet of a given connection with a new connection ID. This reduces
the risk that transient spin bit state can be used to link flows
across connection migration or ID change.
With this mechanism, the server reflects the spin value received,
while the client 'spins' it after one RTT. On-path observers can
measure the time between two spin bit toggle events to estimate the
end-to-end RTT of a connection.
18. Transport Parameter Encoding 18. Transport Parameter Encoding
The format of the transport parameters is the TransportParameters The format of the transport parameters is the TransportParameters
struct from Figure 15. This is described using the presentation struct from Figure 15. This is described using the presentation
language from Section 3 of [TLS13]. language from Section 3 of [TLS13].
enum { enum {
original_connection_id(0), original_connection_id(0),
idle_timeout(1), idle_timeout(1),
stateless_reset_token(2), stateless_reset_token(2),
skipping to change at page 93, line 50 skipping to change at page 97, line 50
include the receiver's expected delays in alarms firing. For include the receiver's expected delays in alarms firing. For
example, if a receiver sets a timer for 5ms and alarms commonly example, if a receiver sets a timer for 5ms and alarms commonly
fire up to 1ms late, then it should send a max_ack_delay of 6ms. fire up to 1ms late, then it should send a max_ack_delay of 6ms.
If this value is absent, a default of 25 milliseconds is assumed. If this value is absent, a default of 25 milliseconds is assumed.
Values of 2^14 or greater are invalid. Values of 2^14 or greater are invalid.
disable_migration (0x000c): The disable migration transport disable_migration (0x000c): The disable migration transport
parameter is included if the endpoint does not support connection parameter is included if the endpoint does not support connection
migration (Section 9). Peers of an endpoint that sets this migration (Section 9). Peers of an endpoint that sets this
transport parameter MUST NOT send any packets, including probing transport parameter MUST NOT send any packets, including probing
packets (Section 9.1), from a local address other than that used packets (Section 9.1), from a local address or port other than
to perform the handshake. This parameter is a zero-length value. that used to perform the handshake. This parameter is a zero-
length value.
preferred_address (0x000d): The server's preferred address is used preferred_address (0x000d): The server's preferred address is used
to effect a change in server address at the end of the handshake, to effect a change in server address at the end of the handshake,
as described in Section 9.6. The format of this transport as described in Section 9.6. The format of this transport
parameter is the PreferredAddress struct shown in Figure 16. This parameter is the PreferredAddress struct shown in Figure 16. This
transport parameter is only sent by a server. Servers MAY choose transport parameter is only sent by a server. Servers MAY choose
to only send a preferred address of one address family by sending to only send a preferred address of one address family by sending
an all-zero address and port (0.0.0.0:0 or ::.0) for the other an all-zero address and port (0.0.0.0:0 or ::.0) for the other
family. family.
skipping to change at page 96, line 35 skipping to change at page 100, line 35
Figure 17: ACK Frame Format Figure 17: ACK Frame Format
ACK frames contain the following fields: ACK frames contain the following fields:
Largest Acknowledged: A variable-length integer representing the Largest Acknowledged: A variable-length integer representing the
largest packet number the peer is acknowledging; this is usually largest packet number the peer is acknowledging; this is usually
the largest packet number that the peer has received prior to the largest packet number that the peer has received prior to
generating the ACK frame. Unlike the packet number in the QUIC generating the ACK frame. Unlike the packet number in the QUIC
long or short header, the value in an ACK frame is not truncated. long or short header, the value in an ACK frame is not truncated.
ACK Delay: A variable-length integer including the time in ACK Delay: A variable-length integer representing the time delta in
microseconds that the largest acknowledged packet, as indicated in microseconds between when this ACK was sent and when the largest
the Largest Acknowledged field, was received by this peer to when acknowledged packet, as indicated in the Largest Acknowledged
this ACK was sent. The value of the ACK Delay field is scaled by field, was received by this peer. The value of the ACK Delay
multiplying the encoded value by 2 to the power of the value of field is scaled by multiplying the encoded value by 2 to the power
the "ack_delay_exponent" transport parameter set by the sender of of the value of the "ack_delay_exponent" transport parameter set
the ACK frame. The "ack_delay_exponent" defaults to 3, or a by the sender of the ACK frame. The "ack_delay_exponent" defaults
multiplier of 8 (see Section 18.1). Scaling in this fashion to 3, or a multiplier of 8 (see Section 18.1). Scaling in this
allows for a larger range of values with a shorter encoding at the fashion allows for a larger range of values with a shorter
cost of lower resolution. encoding at the cost of lower resolution.
ACK Range Count: A variable-length integer specifying the number of ACK Range Count: A variable-length integer specifying the number of
Gap and ACK Range fields in the frame. Gap and ACK Range fields in the frame.
First ACK Range: A variable-length integer indicating the number of First ACK Range: A variable-length integer indicating the number of
contiguous packets preceding the Largest Acknowledged that are contiguous packets preceding the Largest Acknowledged that are
being acknowledged. The First ACK Range is encoded as an ACK being acknowledged. The First ACK Range is encoded as an ACK
Range (see Section 19.3.1) starting from the Largest Acknowledged. Range (see Section 19.3.1) starting from the Largest Acknowledged.
That is, the smallest packet acknowledged in the range is That is, the smallest packet acknowledged in the range is
determined by subtracting the First ACK Range value from the determined by subtracting the First ACK Range value from the
skipping to change at page 99, line 18 skipping to change at page 103, line 18
| ECT(0) Count (i) ... | ECT(0) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT(1) Count (i) ... | ECT(1) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Count (i) ... | ECN-CE Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The three ECN Counts are: The three ECN Counts are:
ECT(0) Count: A variable-length integer representing the total ECT(0) Count: A variable-length integer representing the total
number packets received with the ECT(0) codepoint. number of packets received with the ECT(0) codepoint.
ECT(1) Count: A variable-length integer representing the total ECT(1) Count: A variable-length integer representing the total
number packets received with the ECT(1) codepoint. number of packets received with the ECT(1) codepoint.
CE Count: A variable-length integer representing the total number CE Count: A variable-length integer representing the total number of
packets received with the CE codepoint. packets received with the CE codepoint.
ECN counts are maintained separately for each packet number space. ECN counts are maintained separately for each packet number space.
19.4. RESET_STREAM Frame 19.4. RESET_STREAM Frame
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly
terminate a stream. terminate the sending part of a stream.
After sending a RESET_STREAM, an endpoint ceases transmission and After sending a RESET_STREAM, an endpoint ceases transmission and
retransmission of STREAM frames on the identified stream. A receiver retransmission of STREAM frames on the identified stream. A receiver
of RESET_STREAM can discard any data that it already received on that of RESET_STREAM can discard any data that it already received on that
stream. stream.
An endpoint that receives a RESET_STREAM frame for a send-only stream An endpoint that receives a RESET_STREAM frame for a send-only stream
MUST terminate the connection with error STREAM_STATE_ERROR. MUST terminate the connection with error STREAM_STATE_ERROR.
The RESET_STREAM frame is as follows: The RESET_STREAM frame is as follows:
skipping to change at page 103, line 40 skipping to change at page 107, line 40
Stream Data field in this STREAM frame. This field is present Stream Data field in this STREAM frame. This field is present
when the LEN bit is set to 1. When the LEN bit is set to 0, the when the LEN bit is set to 1. When the LEN bit is set to 0, the
Stream Data field consumes all the remaining bytes in the packet. Stream Data field consumes all the remaining bytes in the packet.
Stream Data: The bytes from the designated stream to be delivered. Stream Data: The bytes from the designated stream to be delivered.
When a Stream Data field has a length of 0, the offset in the STREAM When a Stream Data field has a length of 0, the offset in the STREAM
frame is the offset of the next byte that would be sent. frame is the offset of the next byte that would be sent.
The first byte in the stream has an offset of 0. The largest offset The first byte in the stream has an offset of 0. The largest offset
delivered on a stream - the sum of the offset and data length - MUST delivered on a stream - the sum of the offset and data length -
be less than 2^62. cannot exceed 2^62-1, as it is not possible to provide flow control
credit for that data. Receipt of a frame that exceeds this limit
will be treated as a connection error of type FLOW_CONTROL_ERROR.
19.9. MAX_DATA Frame 19.9. MAX_DATA Frame
The MAX_DATA frame (type=0x10) is used in flow control to inform the The MAX_DATA frame (type=0x10) is used in flow control to inform the
peer of the maximum amount of data that can be sent on the connection peer of the maximum amount of data that can be sent on the connection
as a whole. as a whole.
The MAX_DATA frame is as follows: The MAX_DATA frame is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 113, line 22 skipping to change at page 117, line 22
was absent even though it is mandatory, was present though it is was absent even though it is mandatory, was present though it is
forbidden, or is otherwise in error. forbidden, or is otherwise in error.
PROTOCOL_VIOLATION (0xA): An endpoint detected an error with PROTOCOL_VIOLATION (0xA): An endpoint detected an error with
protocol compliance that was not covered by more specific error protocol compliance that was not covered by more specific error
codes. codes.
INVALID_MIGRATION (0xC): A peer has migrated to a different network INVALID_MIGRATION (0xC): A peer has migrated to a different network
when the endpoint had disabled migration. when the endpoint had disabled migration.
CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in
CRYPTO frames than it can buffer.
CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range
of 256 values is reserved for carrying error codes specific to the of 256 values is reserved for carrying error codes specific to the
cryptographic handshake that is used. Codes for errors occurring cryptographic handshake that is used. Codes for errors occurring
when TLS is used for the crypto handshake are described in when TLS is used for the crypto handshake are described in
Section 4.8 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 22.3 for details of registering new error codes. See Section 22.3 for details of registering new error codes.
20.1. Application Protocol Error Codes 20.1. Application Protocol Error Codes
skipping to change at page 116, line 26 skipping to change at page 120, line 28
attacks in TCP. attacks in TCP.
Normally, clients will open streams sequentially, as explained in Normally, clients will open streams sequentially, as explained in
Section 2.1. However, when several streams are initiated at short Section 2.1. However, when several streams are initiated at short
intervals, transmission error may cause STREAM DATA frames opening intervals, transmission error may cause STREAM DATA frames opening
streams to be received out of sequence. A receiver is obligated to streams to be received out of sequence. A receiver is obligated to
open intervening streams if a higher-numbered stream ID is received. open intervening streams if a higher-numbered stream ID is received.
Thus, on a new connection, opening stream 2000001 opens 1 million Thus, on a new connection, opening stream 2000001 opens 1 million
streams, as required by the specification. streams, as required by the specification.
The number of active streams is limited by the concurrent stream The number of active streams is limited by the
limit transport parameter, as explained in Section 4.5. If chosen initial_max_streams_bidi and initial_max_streams_uni transport
judiciously, this limit mitigates the effect of the stream commitment parameters, as explained in Section 4.5. If chosen judiciously,
attack. However, setting the limit too low could affect performance these limits mitigate the effect of the stream commitment attack.
when applications expect to open large number of streams. However, setting the limit too low could affect performance when
applications expect to open large number of streams.
21.7. Explicit Congestion Notification Attacks 21.7. Explicit Congestion Notification Attacks
An on-path attacker could manipulate the value of ECN codepoints in An on-path attacker could manipulate the value of ECN codepoints in
the IP header to influence the sender's rate. [RFC3168] discusses the IP header to influence the sender's rate. [RFC3168] discusses
manipulations and their effects in more detail. manipulations and their effects in more detail.
An on-the-side attacker can duplicate and send packets with modified An on-the-side attacker can duplicate and send packets with modified
ECN codepoints to affect the sender's rate. If duplicate packets are ECN codepoints to affect the sender's rate. If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the discarded by a receiver, an off-path attacker will need to race the
skipping to change at page 122, line 4 skipping to change at page 126, line 6
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xC | INVALID_MIGRATION | Violated | Section 20 | | 0xC | INVALID_MIGRATION | Violated | Section 20 |
| | | disabled | | | | | disabled | |
| | | migration | | | | | migration | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
23. References 23. References
23.1. Normative References 23.1. Normative References
[DPLPMTUD] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07
(work in progress), February 2019. (work in progress), February 2019.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-19 (work and Congestion Control", draft-ietf-quic-recovery-20 (work
in progress), March 2019. in progress), April 2019.
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
tls-19 (work in progress), March 2019. tls-20 (work in progress), April 2019.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 123, line 33 skipping to change at page 127, line 33
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311, Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018, DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>. <https://www.rfc-editor.org/info/rfc8311>.
[SPIN] Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin
Bit", draft-ietf-quic-spin-exp-01 (work in progress),
October 2018.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
23.2. Informative References 23.2. Informative References
[EARLY-DESIGN] [EARLY-DESIGN]
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-03 (work in progress), March draft-ietf-quic-invariants-04 (work in progress), April
2019. 2019.
[QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-03
(work in progress), October 2018.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
skipping to change at page 126, line 5 skipping to change at page 130, line 5
return candidate_pn - pn_win return candidate_pn - pn_win
return candidate_pn return candidate_pn
Appendix B. Change Log Appendix B. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
B.1. Since draft-ietf-quic-transport-18 B.1. Since draft-ietf-quic-transport-19
o Refine discussion of 0-RTT transport parameters (#2467, #2464)
o Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467)
o Spin bit text incorporated (#2564)
o Close the connection when maximum stream ID in MAX_STREAMS exceeds
2^62 - 1 (#2499, #2487)
o New connection ID required for intentional migration (#2414,
#2413)
o Connection ID issuance can be rate-limited (#2436, #2428)
o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
o Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523)
o CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524)
o Stateless reset uses a short header packet (#2599, #2600)
B.2. Since draft-ietf-quic-transport-18
o Removed version negotation; version negotiation, including o Removed version negotation; version negotiation, including
authentication of the result, will be addressed in the next authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313) version of QUIC (#1773, #2313)
o Added discussion of the use of IPv6 flow labels (#2348, #2399) o Added discussion of the use of IPv6 flow labels (#2348, #2399)
o A connection ID can't be retired in a packet that uses that o A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420) connection ID (#2101, #2420)
o Idle timeout transport parameter is in milliseconds (from seconds) o Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454) (#2453, #2454)
o Endpoints are required to use new connnection IDs when they use o Endpoints are required to use new connnection IDs when they use
new network paths (#2413, #2414) new network paths (#2413, #2414)
o Increased the set of permissible frames in 0-RTT (#2344, #2355) o Increased the set of permissible frames in 0-RTT (#2344, #2355)
B.2. Since draft-ietf-quic-transport-17 B.3. Since draft-ietf-quic-transport-17
o Stream-related errors now use STREAM_STATE_ERROR (#2305) o Stream-related errors now use STREAM_STATE_ERROR (#2305)
o Endpoints discard initial keys as soon as handshake keys are o Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
o Expanded conditions for ignoring ICMP packet too big messages o Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161) (#2108, #2161)
o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
skipping to change at page 127, line 16 skipping to change at page 131, line 44
#2301) #2301)
o Allow server preferred address for both IPv4 and IPv6 (#2122, o Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
o Corrected requirements for migration to a preferred address o Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
o ACK of non-existent packet is illegal (#2298, #2302) o ACK of non-existent packet is illegal (#2298, #2302)
B.3. Since draft-ietf-quic-transport-16 B.4. Since draft-ietf-quic-transport-16
o Stream limits are defined as counts, not maximums (#1850, #1906) o Stream limits are defined as counts, not maximums (#1850, #1906)
o Require amplification attack defense after closing (#1905, #1911) o Require amplification attack defense after closing (#1905, #1911)
o Remove reservation of application error code 0 for STOPPING o Remove reservation of application error code 0 for STOPPING
(#1804, #1922) (#1804, #1922)
o Renumbered frames (#1945) o Renumbered frames (#1945)
skipping to change at page 128, line 23 skipping to change at page 133, line 5
o Tokens are repeated in all Initial packets (#2089) o Tokens are repeated in all Initial packets (#2089)
o Clarified how PING frames are sent after loss (#2094) o Clarified how PING frames are sent after loss (#2094)
o Initial keys are discarded once Handshake are available (#1951, o Initial keys are discarded once Handshake are available (#1951,
#2045) #2045)
o ICMP PTB validation clarifications (#2161, #2109, #2108) o ICMP PTB validation clarifications (#2161, #2109, #2108)
B.4. Since draft-ietf-quic-transport-15 B.5. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.5. Since draft-ietf-quic-transport-14 B.6. Since draft-ietf-quic-transport-14
o Merge ACK and ACK_ECN (#1778, #1801) o Merge ACK and ACK_ECN (#1778, #1801)
o Explicitly communicate max_ack_delay (#981, #1781) o Explicitly communicate max_ack_delay (#981, #1781)
o Validate original connection ID after Retry packets (#1710, #1486, o Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
o Idle timeout is optional and has no specified maximum (#1765) o Idle timeout is optional and has no specified maximum (#1765)
o Update connection ID handling; add RETIRE_CONNECTION_ID type o Update connection ID handling; add RETIRE_CONNECTION_ID type
(#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
#1821) #1821)
o Include a Token in all Initial packets (#1649, #1794) o Include a Token in all Initial packets (#1649, #1794)
o Prevent handshake deadlock (#1764, #1824) o Prevent handshake deadlock (#1764, #1824)
B.6. Since draft-ietf-quic-transport-13 B.7. Since draft-ietf-quic-transport-13
o Streams open when higher-numbered streams of the same type open o Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
o Split initial stream flow control limit into 3 transport o Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
o All flow control transport parameters are optional (#1610) o All flow control transport parameters are optional (#1610)
o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
skipping to change at page 129, line 21 skipping to change at page 134, line 4
o Recommended defense against stateless reset spoofing (#1386, o Recommended defense against stateless reset spoofing (#1386,
#1554) #1554)
o Prevent infinite stateless reset exchanges (#1443, #1627) o Prevent infinite stateless reset exchanges (#1443, #1627)
o Forbid processing of the same packet number twice (#1405, #1624) o Forbid processing of the same packet number twice (#1405, #1624)
o Added a packet number decoding example (#1493) o Added a packet number decoding example (#1493)
o More precisely define idle timeout (#1429, #1614, #1652) o More precisely define idle timeout (#1429, #1614, #1652)
o Corrected format of Retry packet and prevented looping (#1492, o Corrected format of Retry packet and prevented looping (#1492,
#1451, #1448, #1498) #1451, #1448, #1498)
o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, o Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
o Permit Retry in response to 0-RTT (#1547, #1552) o Permit Retry in response to 0-RTT (#1547, #1552)
o Looser verification of ECN counters to account for ACK loss o Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) o Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
B.7. Since draft-ietf-quic-transport-12 B.8. Since draft-ietf-quic-transport-12
o Changes to integration of the TLS handshake (#829, #1018, #1094, o Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450, #1458) #1165, #1190, #1233, #1242, #1252, #1450, #1458)
* The cryptographic handshake uses CRYPTO frames, not stream 0 * The cryptographic handshake uses CRYPTO frames, not stream 0
* QUIC packet protection is used in place of TLS record * QUIC packet protection is used in place of TLS record
protection protection
* Separate QUIC packet number spaces are used for the handshake * Separate QUIC packet number spaces are used for the handshake
skipping to change at page 130, line 29 skipping to change at page 135, line 14
o Fixed sampling method for packet number encryption; the length o Fixed sampling method for packet number encryption; the length
field in long headers includes the packet number field in addition field in long headers includes the packet number field in addition
to the packet payload (#1387, #1389) to the packet payload (#1387, #1389)
o Stateless Reset is now symmetric and subject to size constraints o Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
o Added frame type extension mechanism (#58, #1473) o Added frame type extension mechanism (#58, #1473)
B.8. Since draft-ietf-quic-transport-11 B.9. Since draft-ietf-quic-transport-11
o Enable server to transition connections to a preferred address o Enable server to transition connections to a preferred address
(#560, #1251) (#560, #1251)
o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079) #990, #734, #1317, #1267, #1079)
o Packet numbers use a variable-length encoding (#989, #1334) o Packet numbers use a variable-length encoding (#989, #1334)
o STREAM frames can now be empty (#1350) o STREAM frames can now be empty (#1350)
B.9. Since draft-ietf-quic-transport-10 B.10. Since draft-ietf-quic-transport-10
o Swap payload length and packed number fields in long header o Swap payload length and packed number fields in long header
(#1294) (#1294)
o Clarified that CONNECTION_CLOSE is allowed in Handshake packet o Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
o Spin bit reserved (#1283) o Spin bit reserved (#1283)
o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 131, line 19 skipping to change at page 136, line 4
o Removed implicit stream opening (#896, #1193) o Removed implicit stream opening (#896, #1193)
o An empty STREAM frame can be used to open a stream without sending o An empty STREAM frame can be used to open a stream without sending
data (#901, #1194) data (#901, #1194)
o Define stream counts in transport parameters rather than a maximum o Define stream counts in transport parameters rather than a maximum
stream ID (#1023, #1065) stream ID (#1023, #1065)
o STOP_SENDING is now prohibited before streams are used (#1050) o STOP_SENDING is now prohibited before streams are used (#1050)
o Recommend including ACK in Retry packets and allow PADDING (#1067, o Recommend including ACK in Retry packets and allow PADDING (#1067,
#882) #882)
o Endpoints now become closing after an idle timeout (#1178, #1179) o Endpoints now become closing after an idle timeout (#1178, #1179)
o Remove implication that Version Negotiation is sent when a packet o Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197) of the wrong version is received (#1197)
B.10. Since draft-ietf-quic-transport-09 B.11. Since draft-ietf-quic-transport-09
o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d.
(#1091, #725, #1086) (#1091, #725, #1086)
o A server can now only send 3 packets without validating the client o A server can now only send 3 packets without validating the client
address (#38, #1090) address (#38, #1090)
o Delivery order of stream data is no longer strongly specified o Delivery order of stream data is no longer strongly specified
(#252, #1070) (#252, #1070)
skipping to change at page 132, line 7 skipping to change at page 136, line 39
o Improved retransmission rules for all frame types: information is o Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053) retransmitted, not packets or frames (#463, #765, #1095, #1053)
o Added an error code for server busy signals (#1137) o Added an error code for server busy signals (#1137)
o Endpoints now set the connection ID that their peer uses. o Endpoints now set the connection ID that their peer uses.
Connection IDs are variable length. Removed the Connection IDs are variable length. Removed the
omit_connection_id transport parameter and the corresponding short omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
B.11. Since draft-ietf-quic-transport-08 B.12. Since draft-ietf-quic-transport-08
o Clarified requirements for BLOCKED usage (#65, #924) o Clarified requirements for BLOCKED usage (#65, #924)
o BLOCKED frame now includes reason for blocking (#452, #924, #927, o BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
o GAP limitation in ACK Frame (#613) o GAP limitation in ACK Frame (#613)
o Improved PMTUD description (#614, #1036) o Improved PMTUD description (#614, #1036)
skipping to change at page 132, line 19 skipping to change at page 137, line 4
o Clarified requirements for BLOCKED usage (#65, #924) o Clarified requirements for BLOCKED usage (#65, #924)
o BLOCKED frame now includes reason for blocking (#452, #924, #927, o BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
o GAP limitation in ACK Frame (#613) o GAP limitation in ACK Frame (#613)
o Improved PMTUD description (#614, #1036) o Improved PMTUD description (#614, #1036)
o Clarified stream state machine (#634, #662, #743, #894) o Clarified stream state machine (#634, #662, #743, #894)
o Reserved versions don't need to be generated deterministically o Reserved versions don't need to be generated deterministically
(#831, #931) (#831, #931)
o You don't always need the draining period (#871) o You don't always need the draining period (#871)
o Stateless reset clarified as version-specific (#930, #986) o Stateless reset clarified as version-specific (#930, #986)
o initial_max_stream_id_x transport parameters are optional (#970, o initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
o Ack Delay assumes a default value during the handshake (#1007, o Ack Delay assumes a default value during the handshake (#1007,
#1009) #1009)
o Removed transport parameters from NewSessionTicket (#1015) o Removed transport parameters from NewSessionTicket (#1015)
B.12. Since draft-ietf-quic-transport-07 B.13. Since draft-ietf-quic-transport-07
o The long header now has version before packet number (#926, #939) o The long header now has version before packet number (#926, #939)
o Rename and consolidate packet types (#846, #822, #847) o Rename and consolidate packet types (#846, #822, #847)
o Packet types are assigned new codepoints and the Connection ID o Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956) Flag is inverted (#426, #956)
o Removed type for Version Negotiation and use Version 0 (#963, o Removed type for Version Negotiation and use Version 0 (#963,
#968) #968)
skipping to change at page 133, line 31 skipping to change at page 138, line 15
o Address validation for connection migration (#161, #732, #878) o Address validation for connection migration (#161, #732, #878)
o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) o Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
o negotiated_version is sent in server transport parameters (#710, o negotiated_version is sent in server transport parameters (#710,
#959) #959)
o Increased the range over which packet numbers are randomized o Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
B.13. Since draft-ietf-quic-transport-06 B.14. Since draft-ietf-quic-transport-06
o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
o Split error code space between application and transport (#485) o Split error code space between application and transport (#485)
o Stateless reset token moved to end (#820) o Stateless reset token moved to end (#820)
o 1-RTT-protected long header types removed (#848) o 1-RTT-protected long header types removed (#848)
o No acknowledgments during draining period (#852) o No acknowledgments during draining period (#852)
o Remove "application close" as a separate close type (#854) o Remove "application close" as a separate close type (#854)
o Remove timestamps from the ACK frame (#841) o Remove timestamps from the ACK frame (#841)
o Require transport parameters to only appear once (#792) o Require transport parameters to only appear once (#792)
B.14. Since draft-ietf-quic-transport-05 B.15. Since draft-ietf-quic-transport-05
o Stateless token is server-only (#726) o Stateless token is server-only (#726)
o Refactor section on connection termination (#733, #748, #328, o Refactor section on connection termination (#733, #748, #328,
#177) #177)
o Limit size of Version Negotiation packet (#585) o Limit size of Version Negotiation packet (#585)
o Clarify when and what to ack (#736) o Clarify when and what to ack (#736)
o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
o Clarify Keep-alive requirements (#729) o Clarify Keep-alive requirements (#729)
B.15. Since draft-ietf-quic-transport-04 B.16. Since draft-ietf-quic-transport-04
o Introduce STOP_SENDING frame, RESET_STREAM only resets in one o Introduce STOP_SENDING frame, RESET_STREAM only resets in one
direction (#165) direction (#165)
o Removed GOAWAY; application protocols are responsible for graceful o Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
o Reduced the number of error codes (#96, #177, #184, #211) o Reduced the number of error codes (#96, #177, #184, #211)
o Version validation fields can't move or change (#121) o Version validation fields can't move or change (#121)
skipping to change at page 135, line 5 skipping to change at page 139, line 34
o Increased the maximum length of the Largest Acknowledged field in o Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
o truncate_connection_id is renamed to omit_connection_id (#659) o truncate_connection_id is renamed to omit_connection_id (#659)
o CONNECTION_CLOSE terminates the connection like TCP RST (#330, o CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
B.16. Since draft-ietf-quic-transport-03 B.17. Since draft-ietf-quic-transport-03
o Change STREAM and RESET_STREAM layout o Change STREAM and RESET_STREAM layout
o Add MAX_STREAM_ID settings o Add MAX_STREAM_ID settings
B.17. Since draft-ietf-quic-transport-02 B.18. Since draft-ietf-quic-transport-02
o The size of the initial packet payload has a fixed minimum (#267, o The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
o Define when Version Negotiation packets are ignored (#284, #294, o Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
o The 64-bit FNV-1a algorithm is used for integrity protection of o The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517) unprotected packets (#167, #480, #481, #517)
skipping to change at page 136, line 4 skipping to change at page 140, line 31
* BLOCKED split to match WINDOW_UPDATE split (#454) * BLOCKED split to match WINDOW_UPDATE split (#454)
* Define STREAM_ID_NEEDED frame (#455) * Define STREAM_ID_NEEDED frame (#455)
o A NEW_CONNECTION_ID frame supports connection migration without o A NEW_CONNECTION_ID frame supports connection migration without
linkability (#232, #491, #496) linkability (#232, #491, #496)
o Transport parameters for 0-RTT are retained from a previous o Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512) connection (#405, #513, #512)
* A client in 0-RTT no longer required to reset excess streams * A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
o Expanded security considerations (#440, #444, #445, #448) o Expanded security considerations (#440, #444, #445, #448)
B.18. Since draft-ietf-quic-transport-01 B.19. Since draft-ietf-quic-transport-01
o Defined short and long packet headers (#40, #148, #361) o Defined short and long packet headers (#40, #148, #361)
o Defined a versioning scheme and stable fields (#51, #361) o Defined a versioning scheme and stable fields (#51, #361)
o Define reserved version values for "greasing" negotiation (#112, o Define reserved version values for "greasing" negotiation (#112,
#278) #278)
o The initial packet number is randomized (#35, #283) o The initial packet number is randomized (#35, #283)
skipping to change at page 138, line 8 skipping to change at page 142, line 36
o Remove error code and reason phrase from GOAWAY (#352, #355) o Remove error code and reason phrase from GOAWAY (#352, #355)
o GOAWAY includes a final stream number for both directions (#347) o GOAWAY includes a final stream number for both directions (#347)
o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
o Defined priority as the responsibility of the application protocol o Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
B.19. Since draft-ietf-quic-transport-00 B.20. Since draft-ietf-quic-transport-00
o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
o Defined versioning o Defined versioning
o Reworked description of packet and frame layout o Reworked description of packet and frame layout
o Error code space is divided into regions for each component o Error code space is divided into regions for each component
o Use big endian for all numeric values o Use big endian for all numeric values
B.20. Since draft-hamilton-quic-transport-protocol-01 B.21. Since draft-hamilton-quic-transport-protocol-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added IANA Considerations section o Added IANA Considerations section
o Moved Contributors and Acknowledgments to appendices o Moved Contributors and Acknowledgments to appendices
Acknowledgments Acknowledgments
Special thanks are due to the following for helping shape pre-IETF Special thanks are due to the following for helping shape pre-IETF
QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon,
Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund.
 End of changes. 78 change blocks. 
281 lines changed or deleted 446 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/