-
Notifications
You must be signed in to change notification settings - Fork 201
/
draft-ietf-quic-transport.txt
9968 lines (6703 loc) · 395 KB
/
draft-ietf-quic-transport.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
QUIC J. Iyengar, Ed.
Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed.
Expires: 13 November 2020 Mozilla
12 May 2020
QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-latest
Abstract
This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation.
Note to Readers
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
archived at https://mailarchive.ietf.org/arch/search/?email_list=quic
Working Group information can be found at https://github.com/quicwg;
source code and issues list for this draft can be found at
https://github.com/quicwg/base-drafts/labels/-transport.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 November 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Iyengar & Thomson Expires 13 November 2020 [Page 1]
Internet-Draft QUIC Transport Protocol May 2020
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 7
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 11
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 12
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 12
2.4. Required Operations on Streams . . . . . . . . . . . . . 13
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 14
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 17
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 19
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 20
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 21
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 23
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 24
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 25
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 26
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 27
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 29
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 30
5.2. Matching Packets to Connections . . . . . . . . . . . . . 31
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 31
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 32
5.2.3. Considerations for Simple Load Balancers . . . . . . 33
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 33
5.4. Required Operations on Connections . . . . . . . . . . . 34
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 35
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 35
6.2. Handling Version Negotiation Packets . . . . . . . . . . 36
6.2.1. Version Negotiation Between Draft Versions . . . . . 36
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 37
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 37
Iyengar & Thomson Expires 13 November 2020 [Page 2]
Internet-Draft QUIC Transport Protocol May 2020
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 38
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 39
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 41
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 41
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 43
7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 43
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 44
8.1. Address Validation During Connection Establishment . . . 44
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 45
8.1.2. Address Validation using Retry Packets . . . . . . . 45
8.1.3. Address Validation for Future Connections . . . . . . 46
8.1.4. Address Validation Token Integrity . . . . . . . . . 49
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 49
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 50
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 51
8.5. Successful Path Validation . . . . . . . . . . . . . . . 51
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 51
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 52
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 53
9.2. Initiating Connection Migration . . . . . . . . . . . . . 53
9.3. Responding to Connection Migration . . . . . . . . . . . 54
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 54
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 55
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 55
9.4. Loss Detection and Congestion Control . . . . . . . . . . 56
9.5. Privacy Implications of Connection Migration . . . . . . 57
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 58
9.6.1. Communicating a Preferred Address . . . . . . . . . . 59
9.6.2. Responding to Connection Migration . . . . . . . . . 59
9.6.3. Interaction of Client Migration and Preferred
Address . . . . . . . . . . . . . . . . . . . . . . . 60
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 60
10. Connection Termination . . . . . . . . . . . . . . . . . . . 61
10.1. Closing and Draining Connection States . . . . . . . . . 61
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 63
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 63
10.3.1. Immediate Close During the Handshake . . . . . . . . 65
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 66
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 69
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 70
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 71
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 71
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 72
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 72
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 73
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 73
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 74
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 75
Iyengar & Thomson Expires 13 November 2020 [Page 3]
Internet-Draft QUIC Transport Protocol May 2020
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 76
13. Packetization and Reliability . . . . . . . . . . . . . . . . 79
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 80
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 80
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 81
13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 82
13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 83
13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 83
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 84
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 84
13.3. Retransmission of Information . . . . . . . . . . . . . 85
13.4. Explicit Congestion Notification . . . . . . . . . . . . 87
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 88
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 88
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 90
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 91
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 92
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 93
14.3.1. PMTU Probes Containing Source Connection ID . . . . 93
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 93
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 94
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 95
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 95
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 96
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 99
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 100
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 102
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 104
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 105
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 107
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 109
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 110
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 111
18.2. Transport Parameter Definitions . . . . . . . . . . . . 111
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 115
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 115
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 115
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 116
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 117
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 118
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 119
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 120
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 121
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 122
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 122
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 124
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 124
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 125
Iyengar & Thomson Expires 13 November 2020 [Page 4]
Internet-Draft QUIC Transport Protocol May 2020
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 126
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 127
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 127
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 128
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 130
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 130
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 131
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 131
19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 132
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 133
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 133
20.1. Application Protocol Error Codes . . . . . . . . . . . . 135
21. Security Considerations . . . . . . . . . . . . . . . . . . . 135
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 135
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 136
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 137
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 137
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 137
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 138
21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 138
21.8. Explicit Congestion Notification Attacks . . . . . . . . 139
21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 139
21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 140
21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 140
21.12. Overview of Security Properties . . . . . . . . . . . . 140
21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 141
21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 142
21.12.3. Connection Migration . . . . . . . . . . . . . . . 143
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147
22.1. Registration Policies for QUIC Registries . . . . . . . 147
22.1.1. Provisional Registrations . . . . . . . . . . . . . 147
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 148
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 149
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 150
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 150
22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 151
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 152
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 154
23.1. Normative References . . . . . . . . . . . . . . . . . . 154
23.2. Informative References . . . . . . . . . . . . . . . . . 155
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 157
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 158
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 159
C.1. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 159
C.2. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 159
C.3. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 159
C.4. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 161
C.5. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 161
Iyengar & Thomson Expires 13 November 2020 [Page 5]
Internet-Draft QUIC Transport Protocol May 2020
C.6. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 162
C.7. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 163
C.8. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 164
C.9. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 164
C.10. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 164
C.11. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 165
C.12. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 166
C.13. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 167
C.14. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 167
C.15. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 168
C.16. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 169
C.17. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 169
C.18. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 170
C.19. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 170
C.20. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 171
C.21. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 172
C.22. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 172
C.23. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 172
C.24. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 173
C.25. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 173
C.26. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 174
C.27. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 176
C.28. Since draft-hamilton-quic-transport-protocol-01 . . . . . 176
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 178
1. Introduction
QUIC is a multiplexed and secure general-purpose transport protocol
that provides:
* Stream multiplexing
* Stream and connection-level flow control
* Low-latency connection establishment
* Connection migration and resilience to NAT rebinding
* Authenticated and encrypted header and payload
QUIC uses UDP as a substrate to avoid requiring changes to legacy
client operating systems and middleboxes. QUIC authenticates all of
its headers and encrypts most of the data it exchanges, including its
signaling, to avoid incurring a dependency on middleboxes.
Iyengar & Thomson Expires 13 November 2020 [Page 6]
Internet-Draft QUIC Transport Protocol May 2020
1.1. Document Structure
This document describes the core QUIC protocol and is structured as
follows:
* Streams are the basic service abstraction that QUIC provides.
- Section 2 describes core concepts related to streams,
- Section 3 provides a reference model for stream states, and
- Section 4 outlines the operation of flow control.
* Connections are the context in which QUIC endpoints communicate.
- Section 5 describes core concepts related to connections,
- Section 6 describes version negotiation,
- Section 7 details the process for establishing connections,
- Section 8 specifies critical denial of service mitigation
mechanisms,
- Section 9 describes how endpoints migrate a connection to a new
network path,
- Section 10 lists the options for terminating an open
connection, and
- Section 11 provides general guidance for error handling.
* Packets and frames are the basic unit used by QUIC to communicate.
- Section 12 describes concepts related to packets and frames,
- Section 13 defines models for the transmission, retransmission,
and acknowledgement of data, and
- Section 14 specifies rules for managing the size of packets.
* Finally, encoding details of QUIC protocol elements are described
in:
- Section 15 (Versions),
- Section 16 (Integer Encoding),
Iyengar & Thomson Expires 13 November 2020 [Page 7]
Internet-Draft QUIC Transport Protocol May 2020
- Section 17 (Packet Headers),
- Section 18 (Transport Parameters),
- Section 19 (Frames), and
- Section 20 (Errors).
Accompanying documents describe QUIC's loss detection and congestion
control [QUIC-RECOVERY], and the use of TLS for key negotiation
[QUIC-TLS].
This document defines QUIC version 1, which conforms to the protocol
invariants in [QUIC-INVARIANTS].
1.2. Terms and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Commonly used terms in the document are described below.
QUIC: The transport protocol described by this document. QUIC is a
name, not an acronym.
QUIC packet: A complete processable unit of QUIC that can be
encapsulated in a UDP datagram. Multiple QUIC packets can be
encapsulated in a single UDP datagram.
Ack-eliciting Packet: A QUIC packet that contains frames other than
ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to
send an acknowledgment; see Section 13.2.1.
Out-of-order packet: A packet that does not increase the largest
received packet number for its packet number space (Section 12.3)
by exactly one. A packet can arrive out of order if it is
delayed, if earlier packets are lost or delayed, or if the sender
intentionally skips a packet number.
Endpoint: An entity that can participate in a QUIC connection by
generating, receiving, and processing QUIC packets. There are
only two types of endpoint in QUIC: client and server.
Client: The endpoint initiating a QUIC connection.
Iyengar & Thomson Expires 13 November 2020 [Page 8]
Internet-Draft QUIC Transport Protocol May 2020
Server: The endpoint accepting incoming QUIC connections.
Address: When used without qualification, the tuple of IP version,
IP address, UDP protocol, and UDP port number that represents one
end of a network path.
Connection ID: An opaque identifier that is used to identify a QUIC
connection at an endpoint. Each endpoint sets a value for its
peer to include in packets sent towards the endpoint.
Stream: A unidirectional or bidirectional channel of ordered bytes
within a QUIC connection. A QUIC connection can carry multiple
simultaneous streams.
Application: An entity that uses QUIC to send and receive data.
1.3. Notational Conventions
Packet and frame diagrams in this document use a bespoke format. The
purpose of this format is to summarize, not define, protocol
elements. Prose defines the complete semantics and details of
structures.
Complex fields are named and then followed by a list of fields
surrounded by a pair of matching braces. Each field in this list is
separated by commas.
Individual fields include length information, plus indications about
fixed value, optionality, or repetitions. Individual fields use the
following notational conventions, with all lengths in bits:
x (A): Indicates that x is A bits long
x (i): Indicates that x uses the variable-length encoding in
Section 16
x (A..B): Indicates that x can be any length from A to B; A can be
omitted to indicate a mimumum of zero bits and B can be omitted to
indicate no set upper limit; values in this format always end on
an octet boundary
x (?) = C: Indicates that x has a fixed value of C
x (?) = C..D: Indicates that x has a value in the range from C to D,
inclusive
[x (E)]: Indicates that x is optional (and has length of E)
Iyengar & Thomson Expires 13 November 2020 [Page 9]
Internet-Draft QUIC Transport Protocol May 2020
x (E) ...: Indicates that x is repeated zero or more times (and that
each instance is length E)
By convention, individual fields reference a complex field by using
the name of the complex field.
For example:
Example Structure {
One-bit Field (1),
7-bit Field with Fixed Value (7) = 61,
Arbitrary-Length Field (..),
Variable-Length Field (8..24),
Field With Minimum Length (16..),
Field With Maximum Length (..128),
[Optional Field (64)],
Repeated Field (8) ...,
}
Figure 1: Example Format
2. Streams
Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application. Streams can be unidirectional or
bidirectional. An alternative view of QUIC unidirectional streams is
a "message" abstraction of practically unlimited length.
Streams can be created by sending data. Other processes associated
with stream management - ending, cancelling, and managing flow
control - are all designed to impose minimal overheads. For
instance, a single STREAM frame (Section 19.8) can open, carry data
for, and close a stream. Streams can also be long-lived and can last
the entire duration of a connection.
Streams can be created by either endpoint, can concurrently send data
interleaved with other streams, and can be cancelled. QUIC does not
provide any means of ensuring ordering between bytes on different
streams.
QUIC allows for an arbitrary number of streams to operate
concurrently and for an arbitrary amount of data to be sent on any
stream, subject to flow control constraints and stream limits; see
Section 4.
Iyengar & Thomson Expires 13 November 2020 [Page 10]
Internet-Draft QUIC Transport Protocol May 2020
2.1. Stream Types and Identifiers
Streams can be unidirectional or bidirectional. Unidirectional
streams carry data in one direction: from the initiator of the stream
to its peer. Bidirectional streams allow for data to be sent in both
directions.
Streams are identified within a connection by a numeric value,
referred to as the stream ID. A stream ID is a 62-bit integer (0 to
2^62-1) that is unique for all streams on a connection. Stream IDs
are encoded as variable-length integers; see Section 16. A QUIC
endpoint MUST NOT reuse a stream ID within a connection.
The least significant bit (0x1) of the stream ID identifies the
initiator of the stream. Client-initiated streams have even-numbered
stream IDs (with the bit set to 0), and server-initiated streams have
odd-numbered stream IDs (with the bit set to 1).
The second least significant bit (0x2) of the stream ID distinguishes
between bidirectional streams (with the bit set to 0) and
unidirectional streams (with the bit set to 1).
The least significant two bits from a stream ID therefore identify a
stream as one of four types, as summarized in Table 1.
+------+----------------------------------+
| Bits | Stream Type |
+======+==================================+
| 0x0 | Client-Initiated, Bidirectional |
+------+----------------------------------+
| 0x1 | Server-Initiated, Bidirectional |
+------+----------------------------------+
| 0x2 | Client-Initiated, Unidirectional |
+------+----------------------------------+
| 0x3 | Server-Initiated, Unidirectional |
+------+----------------------------------+
Table 1: Stream ID Types
Within each type, streams are created with numerically increasing
stream IDs. A stream ID that is used out of order results in all
streams of that type with lower-numbered stream IDs also being
opened.
The first bidirectional stream opened by the client has a stream ID
of 0.
Iyengar & Thomson Expires 13 November 2020 [Page 11]
Internet-Draft QUIC Transport Protocol May 2020
2.2. Sending and Receiving Data
STREAM frames (Section 19.8) encapsulate data sent by an application.
An endpoint uses the Stream ID and Offset fields in STREAM frames to
place data in order.
Endpoints MUST be able to deliver stream data to an application as an
ordered byte-stream. Delivering an ordered byte-stream requires that
an endpoint buffer any data that is received out of order, up to the
advertised flow control limit.
QUIC makes no specific allowances for delivery of stream data out of
order. However, implementations MAY choose to offer the ability to
deliver data out of order to a receiving application.
An endpoint could receive data for a stream at the same stream offset
multiple times. Data that has already been received can be
discarded. The data at a given offset MUST NOT change if it is sent
multiple times; an endpoint MAY treat receipt of different data at
the same offset within a stream as a connection error of type
PROTOCOL_VIOLATION.
Streams are an ordered byte-stream abstraction with no other
structure visible to QUIC. STREAM frame boundaries are not expected
to be preserved when data is transmitted, retransmitted after packet
loss, or delivered to the application at a receiver.
An endpoint MUST NOT send data on any stream without ensuring that it
is within the flow control limits set by its peer. Flow control is
described in detail in Section 4.
2.3. Stream Prioritization
Stream multiplexing can have a significant effect on application
performance if resources allocated to streams are correctly
prioritized.
QUIC does not provide a mechanism for exchanging prioritization
information. Instead, it relies on receiving priority information
from the application that uses QUIC.
A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams. When deciding which
streams to dedicate resources to, the implementation SHOULD use the
information provided by the application.
Iyengar & Thomson Expires 13 November 2020 [Page 12]
Internet-Draft QUIC Transport Protocol May 2020
2.4. Required Operations on Streams
There are certain operations which an application MUST be able to
perform when interacting with QUIC streams. This document does not
specify an API, but any implementation of this version of QUIC MUST
expose the ability to perform the operations described in this
section on a QUIC stream.
On the sending part of a stream, application protocols need to be
able to:
* write data, understanding when stream flow control credit
(Section 4.1) has successfully been reserved to send the written
data;
* end the stream (clean termination), resulting in a STREAM frame
(Section 19.8) with the FIN bit set; and
* reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (Section 19.4), if the stream was not already in a terminal
state.
On the receiving part of a stream, application protocols need to be
able to:
* read data; and
* abort reading of the stream and request closure, possibly
resulting in a STOP_SENDING frame (Section 19.5).
Applications also need to be informed of state changes on streams,
including when the peer has opened or reset a stream, when a peer
aborts reading on a stream, when new data is available, and when data
can or cannot be written to the stream due to flow control.
3. Stream States
This section describes streams in terms of their send or receive
components. Two state machines are described: one for the streams on
which an endpoint transmits data (Section 3.1), and another for
streams on which an endpoint receives data (Section 3.2).
Iyengar & Thomson Expires 13 November 2020 [Page 13]
Internet-Draft QUIC Transport Protocol May 2020
Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines. For the most part,
the use of these state machines is the same whether the stream is
unidirectional or bidirectional. The conditions for opening a stream
are slightly more complex for a bidirectional stream because the
opening of either send or receive sides causes the stream to open in
both directions.
An endpoint MUST open streams of the same type in increasing order of
stream ID.
Note: These states are largely informative. This document uses
stream states to describe rules for when and how different types
of frames can be sent and the reactions that are expected when
different types of frames are received. Though these state
machines are intended to be useful in implementing QUIC, these
states aren't intended to constrain implementations. An
implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements
these states.
3.1. Sending Stream States
Figure 2 shows the states for the part of a stream that sends data to
a peer.
Iyengar & Thomson Expires 13 November 2020 [Page 14]
Internet-Draft QUIC Transport Protocol May 2020
o
| Create Stream (Sending)
| Peer Creates Bidirectional Stream
v
+-------+
| Ready | Send RESET_STREAM
| |-----------------------.
+-------+ |
| |
| Send STREAM / |
| STREAM_DATA_BLOCKED |
| |
| Peer Creates |
| Bidirectional Stream |
v |
+-------+ |
| Send | Send RESET_STREAM |
| |---------------------->|
+-------+ |
| |
| Send STREAM + FIN |
v v
+-------+ +-------+
| Data | Send RESET_STREAM | Reset |
| Sent |------------------>| Sent |
+-------+ +-------+
| |
| Recv All ACKs | Recv ACK
v v
+-------+ +-------+
| Data | | Reset |
| Recvd | | Recvd |
+-------+ +-------+
Figure 2: States for Sending Parts of Streams
The sending part of stream that the endpoint initiates (types 0 and 2
for clients, 1 and 3 for servers) is opened by the application. The
"Ready" state represents a newly created stream that is able to
accept data from the application. Stream data might be buffered in
this state in preparation for sending.
Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a
sending part of a stream to enter the "Send" state. An
implementation might choose to defer allocating a stream ID to a
stream until it sends the first STREAM frame and enters this state,
which can allow for better stream prioritization.
Iyengar & Thomson Expires 13 November 2020 [Page 15]
Internet-Draft QUIC Transport Protocol May 2020
The sending part of a bidirectional stream initiated by a peer (type
0 for a server, type 1 for a client) starts in the "Ready" state when
the receiving part is created.
In the "Send" state, an endpoint transmits - and retransmits as
necessary - stream data in STREAM frames. The endpoint respects the
flow control limits set by its peer, and continues to accept and
process MAX_STREAM_DATA frames. An endpoint in the "Send" state
generates STREAM_DATA_BLOCKED frames if it is blocked from sending by
stream or connection flow control limits Section 4.1.
After the application indicates that all stream data has been sent
and a STREAM frame containing the FIN bit is sent, the sending part
of the stream enters the "Data Sent" state. From this state, the
endpoint only retransmits stream data as necessary. The endpoint
does not need to check flow control limits or send
STREAM_DATA_BLOCKED frames for a stream in this state.
MAX_STREAM_DATA frames might be received until the peer receives the
final stream offset. The endpoint can safely ignore any
MAX_STREAM_DATA frames it receives from its peer for a stream in this
state.
Once all stream data has been successfully acknowledged, the sending
part of the stream enters the "Data Recvd" state, which is a terminal
state.
From any of the "Ready", "Send", or "Data Sent" states, an
application can signal that it wishes to abandon transmission of
stream data. Alternatively, an endpoint might receive a STOP_SENDING
frame from its peer. In either case, the endpoint sends a
RESET_STREAM frame, which causes the stream to enter the "Reset Sent"
state.
An endpoint MAY send a RESET_STREAM as the first frame that mentions
a stream; this causes the sending part of that stream to open and
then immediately transition to the "Reset Sent" state.
Once a packet containing a RESET_STREAM has been acknowledged, the
sending part of the stream enters the "Reset Recvd" state, which is a
terminal state.
Iyengar & Thomson Expires 13 November 2020 [Page 16]
Internet-Draft QUIC Transport Protocol May 2020
3.2. Receiving Stream States
Figure 3 shows the states for the part of a stream that receives data
from a peer. The states for a receiving part of a stream mirror only
some of the states of the sending part of the stream at the peer.
The receiving part of a stream does not track states on the sending
part that cannot be observed, such as the "Ready" state. Instead,
the receiving part of a stream tracks the delivery of data to the
application, some of which cannot be observed by the sender.
o
| Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
| Create Bidirectional Stream (Sending)
| Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional)
| Create Higher-Numbered Stream
v
+-------+
| Recv | Recv RESET_STREAM
| |-----------------------.
+-------+ |
| |
| Recv STREAM + FIN |
v |
+-------+ |
| Size | Recv RESET_STREAM |
| Known |---------------------->|
+-------+ |
| |
| Recv All Data |
v v
+-------+ Recv RESET_STREAM +-------+
| Data |--- (optional) --->| Reset |
| Recvd | Recv All Data | Recvd |
+-------+<-- (optional) ----+-------+
| |
| App Read All Data | App Read RST
v v
+-------+ +-------+
| Data | | Reset |
| Read | | Read |
+-------+ +-------+
Figure 3: States for Receiving Parts of Streams
The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) is created when the first STREAM,
STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream.
For bidirectional streams initiated by a peer, receipt of a
Iyengar & Thomson Expires 13 November 2020 [Page 17]
Internet-Draft QUIC Transport Protocol May 2020
MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
stream also creates the receiving part. The initial state for the
receiving part of stream is "Recv".
The receiving part of a stream enters the "Recv" state when the
sending part of a bidirectional stream initiated by the endpoint
(type 0 for a client, type 1 for a server) enters the "Ready" state.
An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or
STOP_SENDING frame is received from the peer for that stream.
Receiving a MAX_STREAM_DATA frame for an unopened stream indicates
that the remote peer has opened the stream and is providing flow
control credit. Receiving a STOP_SENDING frame for an unopened
stream indicates that the remote peer no longer wishes to receive
data on this stream. Either frame might arrive before a STREAM or
STREAM_DATA_BLOCKED frame if packets are lost or reordered.
Before a stream is created, all streams of the same type with lower-
numbered stream IDs MUST be created. This ensures that the creation
order for streams is consistent on both endpoints.
In the "Recv" state, the endpoint receives STREAM and
STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be
reassembled into the correct order for delivery to the application.
As data is consumed by the application and buffer space becomes
available, the endpoint sends MAX_STREAM_DATA frames to allow the
peer to send more data.
When a STREAM frame with a FIN bit is received, the final size of the
stream is known; see Section 4.4. The receiving part of the stream
then enters the "Size Known" state. In this state, the endpoint no
longer needs to send MAX_STREAM_DATA frames, it only receives any
retransmissions of stream data.
Once all data for the stream has been received, the receiving part
enters the "Data Recvd" state. This might happen as a result of
receiving the same STREAM frame that causes the transition to "Size
Known". After all data has been received, any STREAM or
STREAM_DATA_BLOCKED frames for the stream can be discarded.
The "Data Recvd" state persists until stream data has been delivered
to the application. Once stream data has been delivered, the stream
enters the "Data Read" state, which is a terminal state.