/
draft-ietf-quic-invariants.html
611 lines (561 loc) · 29.3 KB
/
draft-ietf-quic-invariants.html
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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>Version-Independent Properties of QUIC</title>
<style type="text/css">/*<![CDATA[*/
body {
font: 16px "Helvetica Neue","Open Sans",Helvetica,Calibri,sans-serif;
color: #333;
font-size-adjust: 0.5;
line-height: 24px;
margin: 75px auto;
max-width: 624px;
padding: 0 5px;
}
.title, .filename, h1, h2, h3, h4, h5 {
font: 16px "Roboto Condensed","Helvetica Neue","Open Sans",Helvetica,Calibri,sans-serif;
font-size-adjust: 0.5;
font-weight: bold;
color: #333;
line-height: 100%;
margin: 1.2em 0 0.3em;
}
.title, #rfc\.title h1 { font-size: 32px; }
h1, section h1, h2, section h2, section h3, nav h2 { font-size: 20px; }
h3, section h4, h4, section h5 { font-size: 16px; }
h1 a[href], h2 a[href], h3 a[href], h4 a[href] {
color: #333;
}
table {
margin-left: 0em;
border-collapse: collapse;
}
th {
text-align: left;
border-bottom: 2px solid #ddd;
}
td {
border-top: 1px solid #ddd;
vertical-align: top;
}
tr:nth-child(2n+1) > td,
tr:nth-child(2n+1) > th {
background-color: #f9f9f9;
}
td.reference {
max-width: 200px;
border-top: none;
padding-right: 1em;
}
.right {
text-align: right;
}
table.header, table#rfc\.headerblock {
width: 100%;
}
table.header td, table#rfc\.headerblock td {
border: none;
background-color: transparent;
color: black;
padding: 0;
}
.filename {
display: block;
color: rgb(119, 119, 119);
font-size: 20px;
font-weight: normal;
line-height: 100%;
margin: 10px 0 32px;
}
#rfc\.abstract+p, #rfc\.abstract p {
font-size: 20px;
line-height: 28px;
}
samp, tt, code, pre {
font: 13.5px Consolas, monospace;
font-size-adjust: none;
}
pre {
background-color: #eee;
border: 1px solid #ddd;
overflow-x: auto;
padding: 5px;
margin: 5px;
}
.figure, caption {
font-style: italic;
margin: 0 1.5em;
text-align: left;
}
address {
margin: 16px 2px;
line-height: 20px;
}
.vcard {
font-style: normal;
}
.vcardline {
display: block;
}
.vcardline .fn, address b {
font-weight: normal;
}
.vcardline .hidden {
display: none;
}
dl {
margin-left: 1em;
}
dl.dl-horizontal: {
margin-left: 0;
}
dl > dt {
float: left;
margin-right: 1em;
}
dl.nohang > dt {
float: none;
}
dl > dd {
margin-bottom: .5em;
}
dl.compact > dd {
margin-bottom: 0em;
}
dl > dd > dl {
margin-top: 0.5em;
margin-bottom: 0em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
hr {
border: 0;
border-top: 1px solid #eee;
}
hr.noprint {
display: none;
}
a {
text-decoration: none;
}
a[href] {
color: #2a6496;
}
a[href]:hover {
background-color: #eee;
}
p, ol, ul, li {
padding: 0;
}
p {
margin: 0.5em 0;
}
ol, ul {
margin: 0.2em 0 0.2em 2em;
}
li {
margin: 0.2em 0;
}
address {
font-style: normal;
}
ul.toc ul {
margin: 0 0 0 2em;
}
ul.toc li {
list-style: none;
margin: 0;
}
@media screen and (min-width: 924px) {
body {
padding-right: 350px;
}
body>ul.toc, body>#rfc\.toc {
position: fixed;
bottom: 0;
right: 0;
right: calc(50vw - 500px);
width: 300px;
z-index: 1;
overflow: auto;
overscroll-behavior: contain;
}
body>#rfc\.toc {
top: 55px;
}
body>ul.toc {
top: 100px;
}
ul.toc {
margin: 0 0 0 4px;
font-size: 12px;
line-height: 20px;
}
ul.toc ul {
margin-left: 1.2em;
}
}
.github-fork-ribbon-wrapper {
display: none;
}
@media screen and (min-width: 800px) {
/* "Fork me on GitHub" CSS ribbon based on
* https://github.com/simonwhitaker/github-fork-ribbon-css
*/
.github-fork-ribbon {
position: absolute;
padding: 2px 0;
background-color: #a00;
background-image: linear-gradient(to bottom, rgba(0, 0, 0, 0), rgba(0, 0, 0, 0.15));
box-shadow: 0 2px 3px 0 rgba(0, 0, 0, 0.5);
font: 700 12px "Helvetica Neue", Helvetica, Arial, sans-serif;
pointer-events: auto;
top: 38px;
right: -45px;
transform: rotate(45deg);
}
.github-fork-ribbon a[href],
.github-fork-ribbon a[href]:hover {
color: #fff;
background-color: transparent;
text-decoration: none;
text-shadow: 0 -1px rgba(0, 0, 0, 0.5);
text-align: center;
width: 190px;
line-height: 18px;
display: inline-block;
padding: 2px 0;
border: 1.5px dotted #fff;
border-color: rgba(255, 255, 255, 0.6);
}
.github-fork-ribbon-wrapper {
display: block;
width: 130px;
height: 130px;
position: absolute;
overflow: hidden;
top: 0; right: 0;
z-index: 2;
pointer-events: none;
}
}
@media screen and (min-width: 1000px) {
.github-fork-ribbon-wrapper {
position: fixed;
}
/*]]>*/</style>
<meta name="viewport" content="initial-scale=1.0">
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.2" rel="Chapter" title="2 Conventions and Definitions">
<link href="#rfc.section.3" rel="Chapter" title="3 An Extremely Abstract Description of QUIC">
<link href="#rfc.section.4" rel="Chapter" title="4 QUIC Packet Headers">
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Long Header">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Short Header">
<link href="#rfc.section.4.3" rel="Chapter" title="4.3 Connection ID">
<link href="#rfc.section.4.4" rel="Chapter" title="4.4 Version">
<link href="#rfc.section.5" rel="Chapter" title="5 Version Negotiation">
<link href="#rfc.section.6" rel="Chapter" title="6 Security and Privacy Considerations">
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations">
<link href="#rfc.references" rel="Chapter" title="8 References">
<link href="#rfc.references.1" rel="Chapter" title="8.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="8.2 Informative References">
<link href="#rfc.appendix.A" rel="Chapter" title="A Incorrect Assumptions">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.12.3 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Thomson, M." />
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-quic-invariants-latest" />
<meta name="dct.issued" scheme="ISO8601" content="2018-12-07" />
<meta name="dct.abstract" content="This document defines the properties of the QUIC transport protocol that are expected to remain unchanged over time as new versions of the protocol are developed." />
<meta name="description" content="This document defines the properties of the QUIC transport protocol that are expected to remain unchanged over time as new versions of the protocol are developed." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">QUIC</td>
<td class="right">M. Thomson</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Mozilla</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">December 07, 2018</td>
</tr>
<tr>
<td class="left">Expires: June 10, 2019</td>
<td class="right"></td>
</tr>
</tbody>
</table>
<p class="title">Version-Independent Properties of QUIC<br />
<span class="filename">draft-ietf-quic-invariants-latest</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>This document defines the properties of the QUIC transport protocol that are expected to remain unchanged over time as new versions of the protocol are developed.</p>
<h1><a>Note to Readers</a></h1>
<p>Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at <a href="https://mailarchive.ietf.org/arch/search/?email_list=quic">https://mailarchive.ietf.org/arch/search/?email_list=quic</a>.</p>
<p>Working Group information can be found at <a href="https://github.com/quicwg">https://github.com/quicwg</a>; source code and issues list for this draft can be found at <a href="https://github.com/quicwg/base-drafts/labels/-invariants">https://github.com/quicwg/base-drafts/labels/-invariants</a>.</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>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/.</p>
<p>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."</p>
<p>This Internet-Draft will expire on June 10, 2019.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>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.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<li>2. <a href="#rfc.section.2">Conventions and Definitions</a>
</li>
<li>3. <a href="#rfc.section.3">An Extremely Abstract Description of QUIC</a>
</li>
<li>4. <a href="#rfc.section.4">QUIC Packet Headers</a>
</li>
<ul><li>4.1. <a href="#rfc.section.4.1">Long Header</a>
</li>
<li>4.2. <a href="#rfc.section.4.2">Short Header</a>
</li>
<li>4.3. <a href="#rfc.section.4.3">Connection ID</a>
</li>
<li>4.4. <a href="#rfc.section.4.4">Version</a>
</li>
</ul><li>5. <a href="#rfc.section.5">Version Negotiation</a>
</li>
<li>6. <a href="#rfc.section.6">Security and Privacy Considerations</a>
</li>
<li>7. <a href="#rfc.section.7">IANA Considerations</a>
</li>
<li>8. <a href="#rfc.references">References</a>
</li>
<ul><li>8.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>8.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Incorrect Assumptions</a>
</li>
<li><a href="#rfc.authors">Author's Address</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
</h1>
<p id="rfc.section.1.p.1">In addition to providing secure, multiplexed transport, QUIC <a href="#QUIC-TRANSPORT" class="xref">[QUIC-TRANSPORT]</a> includes the ability to negotiate a version. This allows the protocol to change over time in response to new requirements. Many characteristics of the protocol will change between versions.</p>
<p id="rfc.section.1.p.2">This document describes the subset of QUIC that is intended to remain stable as new versions are developed and deployed. All of these invariants are IP-version-independent.</p>
<p id="rfc.section.1.p.3">The primary goal of this document is to ensure that it is possible to deploy new versions of QUIC. By documenting the properties that can’t change, this document aims to preserve the ability to change any other aspect of the protocol. Thus, unless specifically described in this document, any aspect of the protocol can change between different versions.</p>
<p><a href="#bad-assumptions" class="xref">Appendix A</a> is a non-exhaustive list of some incorrect assumptions that might be made based on knowledge of QUIC version 1; these do not apply to every version of QUIC.</p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#conventions-and-definitions" id="conventions-and-definitions">Conventions and Definitions</a>
</h1>
<p id="rfc.section.2.p.1">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 <a href="#RFC2119" class="xref">[RFC2119]</a> <a href="#RFC8174" class="xref">[RFC8174]</a> when, and only when, they appear in all capitals, as shown here.</p>
<p id="rfc.section.2.p.2">This document uses terms and notational conventions from <a href="#QUIC-TRANSPORT" class="xref">[QUIC-TRANSPORT]</a>.</p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#an-extremely-abstract-description-of-quic" id="an-extremely-abstract-description-of-quic">An Extremely Abstract Description of QUIC</a>
</h1>
<p id="rfc.section.3.p.1">QUIC is a connection-oriented protocol between two endpoints. Those endpoints exchange UDP datagrams. These UDP datagrams contain QUIC packets. QUIC endpoints use QUIC packets to establish a QUIC connection, which is shared protocol state between those endpoints.</p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#quic-packet-headers" id="quic-packet-headers">QUIC Packet Headers</a>
</h1>
<p id="rfc.section.4.p.1">A QUIC packet is the content of the UDP datagrams exchanged by QUIC endpoints. This document describes the contents of those datagrams.</p>
<p id="rfc.section.4.p.2">QUIC defines two types of packet header: long and short. Packets with long headers are identified by the most significant bit of the first byte being set; packets with a short header have that bit cleared.</p>
<p id="rfc.section.4.p.3">Aside from the values described here, the payload of QUIC packets is version-specific and of arbitrary length.</p>
<h2 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#long-header" id="long-header">Long Header</a>
</h2>
<p id="rfc.section.4.1.p.1">Long headers take the form described in <a href="#fig-long" class="xref">Figure 1</a>. Bits that have version-specific semantics are marked with an X.</p>
<div id="rfc.figure.1"></div>
<div id="fig-long"></div>
<pre>
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
+-+-+-+-+-+-+-+-+
|1|X X X X X X X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p class="figure">Figure 1: QUIC Long Header</p>
<p id="rfc.section.4.1.p.2">A QUIC packet with a long header has the high bit of the first byte set to 1. All other bits in that byte are version specific.</p>
<p id="rfc.section.4.1.p.3">The next four bytes include a 32-bit Version field (see <a href="#version" class="xref">Section 4.4</a>).</p>
<p id="rfc.section.4.1.p.4">The next byte contains the length in bytes of the two Connection IDs (see <a href="#connection-id" class="xref">Section 4.3</a>) that follow. Each length is encoded as a 4-bit unsigned integer. The length of the Destination Connection ID (DCIL) occupies the high bits of the byte and the length of the Source Connection ID (SCIL) occupies the low bits of the byte. An encoded length of 0 indicates that the connection ID is also 0 bytes in length. Non-zero encoded lengths are increased by 3 to get the full length of the connection ID; the final value is therefore either 0 or between 4 and 18 bytes in length (inclusive). For example, an byte with the value 0xe0 describes a 17 byte Destination Connection ID and a zero byte Source Connection ID.</p>
<p id="rfc.section.4.1.p.5">The connection ID lengths are followed by two connection IDs. The connection ID associated with the recipient of the packet (the Destination Connection ID) is followed by the connection ID associated with the sender of the packet (the Source Connection ID).</p>
<p id="rfc.section.4.1.p.6">The remainder of the packet contains version-specific content.</p>
<h2 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#short-header" id="short-header">Short Header</a>
</h2>
<p id="rfc.section.4.2.p.1">Short headers take the form described in <a href="#fig-short" class="xref">Figure 2</a>. Bits that have version-specific semantics are marked with an X.</p>
<div id="rfc.figure.2"></div>
<div id="fig-short"></div>
<pre>
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|X X X X X X X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p class="figure">Figure 2: QUIC Short Header</p>
<p id="rfc.section.4.2.p.2">A QUIC packet with a short header has the high bit of the first byte set to 0.</p>
<p id="rfc.section.4.2.p.3">A QUIC packet with a short header includes a Destination Connection ID. The short header does not include the Connection ID Lengths, Source Connection ID, or Version fields.</p>
<p id="rfc.section.4.2.p.4">The remainder of the packet has version-specific semantics.</p>
<h2 id="rfc.section.4.3">
<a href="#rfc.section.4.3">4.3.</a> <a href="#connection-id" id="connection-id">Connection ID</a>
</h2>
<p id="rfc.section.4.3.p.1">A connection ID is an opaque field of arbitrary length.</p>
<p id="rfc.section.4.3.p.2">The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP, and below) don’t cause packets for a QUIC connection to be delivered to the wrong endpoint. The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint. At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for.</p>
<p id="rfc.section.4.3.p.3">The connection ID is chosen by each endpoint using version-specific methods. Packets for the same QUIC connection might use different connection ID values.</p>
<h2 id="rfc.section.4.4">
<a href="#rfc.section.4.4">4.4.</a> <a href="#version" id="version">Version</a>
</h2>
<p id="rfc.section.4.4.p.1">QUIC versions are identified with a 32-bit integer, encoded in network byte order. Version 0 is reserved for version negotiation (see <a href="#version-negotiation" class="xref">Section 5</a>). All other version numbers are potentially valid.</p>
<p id="rfc.section.4.4.p.2">The properties described in this document apply to all versions of QUIC. A protocol that does not conform to the properties described in this document is not QUIC. Future documents might describe additional properties which apply to a specific QUIC version, or to a range of QUIC versions.</p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#version-negotiation" id="version-negotiation">Version Negotiation</a>
</h1>
<p id="rfc.section.5.p.1">A QUIC endpoint that receives a packet with a long header and a version it either does not understand or does not support might send a Version Negotiation packet in response. Packets with a short header do not trigger version negotiation.</p>
<p id="rfc.section.5.p.2">A Version Negotiation packet sets the high bit of the first byte, and thus it conforms with the format of a packet with a long header as defined in <a href="#long-header" class="xref">Section 4.1</a>. A Version Negotiation packet is identifiable as such by the Version field, which is set to 0x00000000.</p>
<div id="rfc.figure.3"></div>
<div id="version-negotiation-format"></div>
<pre>
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
+-+-+-+-+-+-+-+-+
|1|X X X X X X X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version 1 (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version 2 (32)] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version N (32)] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p class="figure">Figure 3: Version Negotiation Packet</p>
<p id="rfc.section.5.p.3">The Version Negotiation packet contains a list of Supported Version fields, each identifying a version that the endpoint sending the packet supports. The Supported Version fields follow the Version field. A Version Negotiation packet contains no other fields. An endpoint MUST ignore a packet that contains no Supported Version fields, or a truncated Supported Version.</p>
<p id="rfc.section.5.p.4">Version Negotiation packets do not use integrity or confidentiality protection. A specific QUIC version might authenticate the packet as part of its connection establishment process.</p>
<p id="rfc.section.5.p.5">An endpoint MUST include the value from the Source 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 Destination Connection ID of the received packet, which is initially randomly selected by a client. Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an off-path attacker.</p>
<p id="rfc.section.5.p.6">An endpoint that receives a Version Negotiation packet might change the version that it decides to use for subsequent packets. The conditions under which an endpoint changes QUIC version will depend on the version of QUIC that it chooses.</p>
<p id="rfc.section.5.p.7">See <a href="#QUIC-TRANSPORT" class="xref">[QUIC-TRANSPORT]</a> for a more thorough description of how an endpoint that supports QUIC version 1 generates and consumes a Version Negotiation packet.</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#security-and-privacy-considerations" id="security-and-privacy-considerations">Security and Privacy Considerations</a>
</h1>
<p id="rfc.section.6.p.1">It is possible that middleboxes could use traits of a specific version of QUIC and assume that when other versions of QUIC exhibit similar traits the same underlying semantic is being expressed. There are potentially many such traits (see <a href="#bad-assumptions" class="xref">Appendix A</a>). Some effort has been made to either eliminate or obscure some observable traits in QUIC version 1, but many of these remain. Other QUIC versions might make different design decisions and so exhibit different traits.</p>
<p id="rfc.section.6.p.2">The QUIC version number does not appear in all QUIC packets, which means that reliably extracting information from a flow based on version-specific traits requires that middleboxes retain state for every connection ID they see.</p>
<p id="rfc.section.6.p.3">The Version Negotiation packet described in this document is not integrity-protected; it only has modest protection against insertion by off-path attackers. QUIC versions MUST define a mechanism that authenticates the values it contains.</p>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a>
</h1>
<p id="rfc.section.7.p.1">This document makes no request of IANA.</p>
<h1 id="rfc.references">
<a href="#rfc.references">8.</a> References</h1>
<h2 id="rfc.references.1">
<a href="#rfc.references.1">8.1.</a> Normative References</h2>
<table><tbody>
<tr>
<td class="reference"><b id="QUIC-TRANSPORT">[QUIC-TRANSPORT]</b></td>
<td class="top">
<a title="Google">Iyengar, J.</a> and <a title="Mozilla">M. Thomson</a>, "<a href="https://tools.ietf.org/html/draft-ietf-quic-transport">QUIC: A UDP-Based Multiplexed and Secure Transport</a>", Internet-Draft draft-ietf-quic-transport, December 2018.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8174">[RFC8174]</b></td>
<td class="top">
<a>Leiba, B.</a>, "<a href="https://tools.ietf.org/html/rfc8174">Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</a>", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.</td>
</tr>
</tbody></table>
<h2 id="rfc.references.2">
<a href="#rfc.references.2">8.2.</a> Informative References</h2>
<table><tbody>
<tr>
<td class="reference"><b id="QUIC-TLS">[QUIC-TLS]</b></td>
<td class="top">
<a title="Mozilla">Thomson, M.</a> and <a title="sn3rd">S. Turner</a>, "<a href="https://tools.ietf.org/html/draft-ietf-quic-tls">Using Transport Layer Security (TLS) to Secure QUIC</a>", Internet-Draft draft-ietf-quic-tls, December 2018.</td>
</tr>
<tr>
<td class="reference"><b id="RFC5116">[RFC5116]</b></td>
<td class="top">
<a>McGrew, D.</a>, "<a href="https://tools.ietf.org/html/rfc5116">An Interface and Algorithms for Authenticated Encryption</a>", RFC 5116, DOI 10.17487/RFC5116, January 2008.</td>
</tr>
</tbody></table>
<h1 id="rfc.appendix.A">
<a href="#rfc.appendix.A">Appendix A.</a> <a href="#bad-assumptions" id="bad-assumptions">Incorrect Assumptions</a>
</h1>
<p id="rfc.section.A.p.1">There are several traits of QUIC version 1 <a href="#QUIC-TRANSPORT" class="xref">[QUIC-TRANSPORT]</a> that are not protected from observation, but are nonetheless considered to be changeable when a new version is deployed.</p>
<p id="rfc.section.A.p.2">This section lists a sampling of incorrect assumptions that might be made based on knowledge of QUIC version 1. Some of these statements are not even true for QUIC version 1. This is not an exhaustive list, it is intended to be illustrative only.</p>
<p id="rfc.section.A.p.3">The following statements are NOT guaranteed to be true for every QUIC version:</p>
<p></p>
<ul>
<li>QUIC uses TLS <a href="#QUIC-TLS" class="xref">[QUIC-TLS]</a> and some TLS messages are visible on the wire</li>
<li>QUIC long headers are only exchanged during connection establishment</li>
<li>Every flow on a given 5-tuple will include a connection establishment phase</li>
<li>The first packets exchanged on a flow use the long header</li>
<li>QUIC forbids acknowledgments of packets that only contain ACK frames, therefore the last packet before a long period of quiescence might be assumed to contain an acknowledgment</li>
<li>QUIC uses an AEAD (AEAD_AES_128_GCM <a href="#RFC5116" class="xref">[RFC5116]</a>) to protect the packets it exchanges during connection establishment</li>
<li>QUIC packet numbers appear after the Version field</li>
<li>QUIC packet numbers increase by one for every packet sent</li>
<li>QUIC has a minimum size for the first handshake packet sent by a client</li>
<li>QUIC stipulates that a client speaks first</li>
<li>A QUIC Version Negotiation packet is only sent by a server</li>
<li>A QUIC connection ID changes infrequently</li>
<li>QUIC endpoints change the version they speak if they are sent a Version Negotiation packet</li>
<li>The version field in a QUIC long header is the same in both directions</li>
<li>Only one connection at a time is established between any pair of QUIC endpoints</li>
</ul>
<h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Martin Thomson</span>
<span class="n hidden">
<span class="family-name">Thomson</span>
</span>
</span>
<span class="org vcardline">Mozilla</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:martin.thomson@gmail.com">martin.thomson@gmail.com</a></span>
</address>
</div>
</body>
</html>