-
Notifications
You must be signed in to change notification settings - Fork 10
/
draft-ietf-quic-load-balancers.txt
1848 lines (1231 loc) · 71.9 KB
/
draft-ietf-quic-load-balancers.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 M. Duke
Internet-Draft F5 Networks, Inc.
Intended status: Standards Track N. Banks
Expires: 18 January 2021 Microsoft
17 July 2020
QUIC-LB: Generating Routable QUIC Connection IDs
draft-ietf-quic-load-balancers-04
Abstract
QUIC connection IDs allow continuation of connections across address/
port 4-tuple changes, and can store routing information for stateless
or low-state load balancers. They also can prevent linkability of
connections across deliberate address migration through the use of
protected communications between client and server. This creates
issues for load-balancing intermediaries. This specification
standardizes methods for encoding routing information given a small
set of configuration parameters. This framework also enables offload
of other QUIC functions to trusted intermediaries, given the explicit
cooperation of the QUIC server.
Note to Readers
Discussion of this document takes place on the QUIC Working Group
mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/quic/
(https://mailarchive.ietf.org/arch/browse/quic/).
Source for this draft and an issue tracker can be found at
https://github.com/quicwg/load-balancers (https://github.com/quicwg/
load-balancers).
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."
Duke & Banks Expires 18 January 2021 [Page 1]
Internet-Draft QUIC-LB July 2020
This Internet-Draft will expire on 18 January 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Objectives . . . . . . . . . . . . . . . . . . . . . 5
2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 6
3. First CID octet . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Config Rotation . . . . . . . . . . . . . . . . . . . . . 6
3.2. Configuration Failover . . . . . . . . . . . . . . . . . 7
3.3. Length Self-Description . . . . . . . . . . . . . . . . . 7
3.4. Format . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 8
4.1. Plaintext CID Algorithm . . . . . . . . . . . . . . . . . 9
4.1.1. Configuration Agent Actions . . . . . . . . . . . . . 10
4.1.2. Load Balancer Actions . . . . . . . . . . . . . . . . 10
4.1.3. Server Actions . . . . . . . . . . . . . . . . . . . 10
4.2. Obfuscated CID Algorithm . . . . . . . . . . . . . . . . 10
4.2.1. Configuration Agent Actions . . . . . . . . . . . . . 10
4.2.2. Load Balancer Actions . . . . . . . . . . . . . . . . 11
4.2.3. Server Actions . . . . . . . . . . . . . . . . . . . 11
4.3. Stream Cipher CID Algorithm . . . . . . . . . . . . . . . 12
4.3.1. Configuration Agent Actions . . . . . . . . . . . . . 12
4.3.2. Load Balancer Actions . . . . . . . . . . . . . . . . 12
4.3.3. Server Actions . . . . . . . . . . . . . . . . . . . 14
4.4. Block Cipher CID Algorithm . . . . . . . . . . . . . . . 14
4.4.1. Configuration Agent Actions . . . . . . . . . . . . . 14
4.4.2. Load Balancer Actions . . . . . . . . . . . . . . . . 15
4.4.3. Server Actions . . . . . . . . . . . . . . . . . . . 15
5. ICMP Processing . . . . . . . . . . . . . . . . . . . . . . . 15
6. Retry Service . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Common Requirements . . . . . . . . . . . . . . . . . . . 16
Duke & Banks Expires 18 January 2021 [Page 2]
Internet-Draft QUIC-LB July 2020
6.2. No-Shared-State Retry Service . . . . . . . . . . . . . . 17
6.2.1. Configuration Agent Actions . . . . . . . . . . . . . 17
6.2.2. Service Requirements . . . . . . . . . . . . . . . . 17
6.2.3. Server Requirements . . . . . . . . . . . . . . . . . 19
6.3. Shared-State Retry Service . . . . . . . . . . . . . . . 19
6.3.1. Configuration Agent Actions . . . . . . . . . . . . . 21
6.3.2. Service Requirements . . . . . . . . . . . . . . . . 21
6.3.3. Server Requirements . . . . . . . . . . . . . . . . . 22
7. Configuration Requirements . . . . . . . . . . . . . . . . . 22
8. Additional Use Cases . . . . . . . . . . . . . . . . . . . . 23
8.1. Load balancer chains . . . . . . . . . . . . . . . . . . 24
8.2. Moving connections between servers . . . . . . . . . . . 24
9. Version Invariance of QUIC-LB . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.1. Attackers not between the load balancer and server . . . 25
10.2. Attackers between the load balancer and server . . . . . 26
10.3. Multiple Configuration IDs . . . . . . . . . . . . . . . 26
10.4. Limited configuration scope . . . . . . . . . . . . . . 26
10.5. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Load Balancer Test Vectors . . . . . . . . . . . . . 28
A.1. Obfuscated Connection ID Algorithm . . . . . . . . . . . 28
A.2. Stream Cipher Connection ID Algorithm . . . . . . . . . . 29
A.3. Block Cipher Connection ID Algorithm . . . . . . . . . . 30
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 31
C.1. since-draft-ietf-quic-load-balancers-03 . . . . . . . . . 31
C.2. since-draft-ietf-quic-load-balancers-02 . . . . . . . . . 31
C.3. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 32
C.4. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 32
C.5. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 32
C.6. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 32
C.7. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 32
C.8. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 32
C.9. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 32
C.10. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 33
C.11. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Duke & Banks Expires 18 January 2021 [Page 3]
Internet-Draft QUIC-LB July 2020
1. Introduction
QUIC packets [QUIC-TRANSPORT] usually contain a connection ID to
allow endpoints to associate packets with different address/port
4-tuples to the same connection context. This feature makes
connections robust in the event of NAT rebinding. QUIC endpoints
usually designate the connection ID which peers use to address
packets. Server-generated connection IDs create a potential need for
out-of-band communication to support QUIC.
QUIC allows servers (or load balancers) to designate an initial
connection ID to encode useful routing information for load
balancers. It also encourages servers, in packets protected by
cryptography, to provide additional connection IDs to the client.
This allows clients that know they are going to change IP address or
port to use a separate connection ID on the new path, thus reducing
linkability as clients move through the world.
There is a tension between the requirements to provide routing
information and mitigate linkability. Ultimately, because new
connection IDs are in protected packets, they must be generated at
the server if the load balancer does not have access to the
connection keys. However, it is the load balancer that has the
context necessary to generate a connection ID that encodes useful
routing information. In the absence of any shared state between load
balancer and server, the load balancer must maintain a relatively
expensive table of server-generated connection IDs, and will not
route packets correctly if they use a connection ID that was
originally communicated in a protected NEW_CONNECTION_ID frame.
This specification provides common algorithms for encoding the server
mapping in a connection ID given some shared parameters. The mapping
is generally only discoverable by observers that have the parameters,
preserving unlinkability as much as possible.
Aside from load balancing, a QUIC server may also desire to offload
other protocol functions to trusted intermediaries. These
intermediaries might include hardware assist on the server host
itself, without access to fully decrypted QUIC packets. For example,
this document specifies a means of offloading stateless retry to
counter Denial of Service attacks. It also proposes a system for
self-encoding connection ID length in all packets, so that crypto
offload can consistently look up key information.
Duke & Banks Expires 18 January 2021 [Page 4]
Internet-Draft QUIC-LB July 2020
While this document describes a small set of configuration parameters
to make the server mapping intelligible, the means of distributing
these parameters between load balancers, servers, and other trusted
intermediaries is out of its scope. There are numerous well-known
infrastructures for distribution of configuration.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
In this document, "client" and "server" refer to the endpoints of a
QUIC connection unless otherwise indicated. A "load balancer" is an
intermediary for that connection that does not possess QUIC
connection keys, but it may rewrite IP addresses or conduct other IP
or UDP processing. A "configuration agent" is the entity that
determines the QUIC-LB configuration parameters for the network and
leverages some system to distribute that configuration.
Note that stateful load balancers that act as proxies, by terminating
a QUIC connection with the client and then retrieving data from the
server using QUIC or another protocol, are treated as a server with
respect to this specification.
For brevity, "Connection ID" will often be abbreviated as "CID".
2. Protocol Objectives
2.1. Simplicity
QUIC is intended to provide unlinkability across connection
migration, but servers are not required to provide additional
connection IDs that effectively prevent linkability. If the
coordination scheme is too difficult to implement, servers behind
load balancers using connection IDs for routing will use trivially
linkable connection IDs. Clients will therefore be forced to choose
between terminating the connection during migration or remaining
linkable, subverting a design objective of QUIC.
The solution should be both simple to implement and require little
additional infrastructure for cryptographic keys, etc.
Duke & Banks Expires 18 January 2021 [Page 5]
Internet-Draft QUIC-LB July 2020
2.2. Security
In the limit where there are very few connections to a pool of
servers, no scheme can prevent the linking of two connection IDs with
high probability. In the opposite limit, where all servers have many
connections that start and end frequently, it will be difficult to
associate two connection IDs even if they are known to map to the
same server.
QUIC-LB is relevant in the region between these extremes: when the
information that two connection IDs map to the same server is helpful
to linking two connection IDs. Obviously, any scheme that
transparently communicates this mapping to outside observers
compromises QUIC's defenses against linkability.
Though not an explicit goal of the QUIC-LB design, concealing the
server mapping also complicates attempts to focus attacks on a
specific server in the pool.
3. First CID octet
The first octet of a Connection ID is reserved for two special
purposes, one mandatory (config rotation) and one optional (length
self-description).
Subsequent sections of this document refer to the contents of this
octet as the "first octet."
3.1. Config Rotation
The first two bits of any connection ID MUST encode an identifier for
the configuration that the connection ID uses. This enables
incremental deployment of new QUIC-LB settings (e.g., keys).
When new configuration is distributed to servers, there will be a
transition period when connection IDs reflecting old and new
configuration coexist in the network. The rotation bits allow load
balancers to apply the correct routing algorithm and parameters to
incoming packets.
Configuration Agents SHOULD deliver new configurations to load
balancers before doing so to servers, so that load balancers are
ready to process CIDs using the new parameters when they arrive.
A Configuration Agent SHOULD NOT use a codepoint to represent a new
configuration until it takes precautions to make sure that all
connections using CIDs with an old configuration at that codepoint
have closed or transitioned.
Duke & Banks Expires 18 January 2021 [Page 6]
Internet-Draft QUIC-LB July 2020
Servers MUST NOT generate new connection IDs using an old
configuration after receiving a new one from the configuration agent.
Servers MUST send NEW_CONNECTION_ID frames that provide CIDs using
the new configuration, and retire CIDs using the old configuration
using the "Retire Prior To" field of that frame.
It also possible to use these bits for more long-lived distinction of
different configurations, but this has privacy implications (see
Section 10.3).
3.2. Configuration Failover
If a server has not received a valid QUIC-LB configuration, and
believes that low-state, Connection-ID aware load balancers are in
the path, it SHOULD generate connection IDs with the config rotation
bits set to '11' and SHOULD use the "disable_active_migration"
transport parameter in all new QUIC connections. It SHOULD NOT send
NEW_CONNECTION_ID frames with new values.
A load balancer that sees a connection ID with config rotation bits
set to '11' MUST revert to 5-tuple routing.
3.3. Length Self-Description
Local hardware cryptographic offload devices may accelerate QUIC
servers by receiving keys from the QUIC implementation indexed to the
connection ID. However, on physical devices operating multiple QUIC
servers, it is impractical to efficiently lookup these keys if the
connection ID does not self-encode its own length.
Note that this is a function of particular server devices and is
irrelevant to load balancers. As such, load balancers MAY omit this
from their configuration. However, the remaining 6 bits in the first
octet of the Connection ID are reserved to express the length of the
following connection ID, not including the first octet.
A server not using this functionality SHOULD make the six bits appear
to be random.
3.4. Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C R| CID Len |
+-+-+-+-+-+-+-+-+
Figure 1: First Octet Format
Duke & Banks Expires 18 January 2021 [Page 7]
Internet-Draft QUIC-LB July 2020
The first octet has the following fields:
CR: Config Rotation bits.
CID Len: Length Self-Description (if applicable). Encodes the length
of the Connection ID following the First Octet.
4. Routing Algorithms
In QUIC-LB, load balancers do not generate individual connection IDs
to servers. Instead, they communicate the parameters of an algorithm
to generate routable connection IDs.
The algorithms differ in the complexity of configuration at both load
balancer and server. Increasing complexity improves obfuscation of
the server mapping.
As clients sometimes generate the DCIDs in long headers, these might
not conform to the expectations of the routing algorithm. These are
called "non-compliant DCIDs":
* The DCID might not be long enough for the routing algorithm to
process.
* The extracted server mapping might not correspond to an active
server.
* A field that should be all zeroes after decryption may not be so.
Load balancers MUST forward packets with long headers with non-
compliant DCIDs to an active server using an algorithm of its own
choosing. It need not coordinate this algorithm with the servers.
The algorithm SHOULD be deterministic over short time scales so that
related packets go to the same server. The design of this algorithm
SHOULD consider the version-invariant properties of QUIC described in
[QUIC-INVARIANTS] to maximize its robustness to future versions of
QUIC. For example, a non-compliant DCID might be converted to an
integer and divided by the number of servers, with the modulus used
to forward the packet. The number of servers is usually consistent
on the time scale of a QUIC connection handshake. See also
Section 9.
Duke & Banks Expires 18 January 2021 [Page 8]
Internet-Draft QUIC-LB July 2020
As a partial exception to the above, load balancers MAY drop packets
with long headers and non-compliant DCIDs if and only if it knows
that the encoded QUIC version does not allow a non-compliant DCID in
a packet with that signature. For example, a load balancer can
safely drop a QUIC version 1 Handshake packet with a non-compliant
DCIDs. The prohibition against dropping packets with long headers
remains for unknown QUIC versions.
Load balancers SHOULD drop packets with non-compliant DCIDs in a
short header.
A QUIC-LB configuration MAY significantly over-provision the server
ID space (i.e., provide far more codepoints than there are servers)
to increase the probability that a randomly generated Destination
Connection ID is non- compliant.
Load balancers MUST forward packets with compliant DCIDs to a server
in accordance with the chosen routing algorithm.
The load balancer MUST NOT make the routing behavior dependent on any
bits in the first octet of the QUIC packet header, except the first
bit, which indicates a long header. All other bits are QUIC version-
dependent and intermediaries would cannot build their design on
version-specific templates.
There are situations where a server pool might be operating two or
more routing algorithms or parameter sets simultaneously. The load
balancer uses the first two bits of the connection ID to multiplex
incoming DCIDs over these schemes.
This section describes three participants: the configuration agent,
the load balancer, and the server.
4.1. Plaintext CID Algorithm
The Plaintext CID Algorithm makes no attempt to obscure the mapping
of connections to servers, significantly increasing linkability. The
format is depicted in the figure below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First octet | Server ID (X=8..152) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Any (0..152-X) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Plaintext CID Format
Duke & Banks Expires 18 January 2021 [Page 9]
Internet-Draft QUIC-LB July 2020
4.1.1. Configuration Agent Actions
The configuration agent selects a number of bytes of the server
connection ID to encode individual server IDs, called the "routing
bytes". The number of bytes MUST have enough entropy to have a
different code point for each server.
It also assigns a server ID to each server.
4.1.2. Load Balancer Actions
On each incoming packet, the load balancer extracts consecutive
octets, beginning with the second octet. These bytes represent the
server ID.
4.1.3. Server Actions
The server chooses a connection ID length. This MUST be at least one
byte longer than the routing bytes.
When a server needs a new connection ID, it encodes its assigned
server ID in consecutive octets beginning with the second. All other
bits in the connection ID, except for the first octet, MAY be set to
any other value. These other bits SHOULD appear random to observers.
4.2. Obfuscated CID Algorithm
The Obfuscated CID Algorithm makes an attempt to obscure the mapping
of connections to servers to reduce linkability, while not requiring
true encryption and decryption. The format is depicted in the figure
below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First octet | Mixed routing and non-routing bits (64..152) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Obfuscated CID Format
4.2.1. Configuration Agent Actions
The configuration agent selects an arbitrary set of bits of the
server connection ID that it will use to route to a given server,
called the "routing bits". The number of bits MUST have enough
entropy to have a different code point for each server, and SHOULD
have enough entropy so that there are many codepoints for each
server.
Duke & Banks Expires 18 January 2021 [Page 10]
Internet-Draft QUIC-LB July 2020
The configuration agent MUST NOT select a routing mask with more than
136 routing bits set to 1, which allows for the first octet and up to
2 octets for server purposes in a maximum-length connection ID.
The configuration agent selects a divisor that MUST be larger than
the number of servers. It SHOULD be large enough to accommodate
reasonable increases in the number of servers. The divisor MUST be
an odd integer so certain addition operations do not always produce
an even number.
The configuration agent also assigns each server a "modulus", an
integer between 0 and the divisor minus 1. These MUST be unique for
each server, and SHOULD be distributed across the entire number space
between zero and the divisor.
4.2.2. Load Balancer Actions
Upon receipt of a QUIC packet, the load balancer extracts the
selected bits of the Server CID and expresses them as an unsigned
integer of that length. The load balancer then divides the result by
the chosen divisor. The modulus of this operation maps to the
modulus for the destination server.
Note that any Server CID that contains a server's modulus, plus an
arbitrary integer multiple of the divisor, in the routing bits is
routable to that server regardless of the contents of the non-routing
bits. Outside observers that do not know the divisor or the routing
bits will therefore have difficulty identifying that two Server CIDs
route to the same server.
Note also that not all Connection IDs are necessarily routable, as
the computed modulus may not match one assigned to any server. These
DCIDs are non-compliant as described above.
4.2.3. Server Actions
The server chooses a connection ID length. This MUST contain all of
the routing bits and MUST be at least 9 octets to provide adequate
entropy.
When a server needs a new connection ID, it adds an arbitrary
nonnegative integer multiple of the divisor to its modulus, without
exceeding the maximum integer value implied by the number of routing
bits. The choice of multiple should appear random within these
constraints.
Duke & Banks Expires 18 January 2021 [Page 11]
Internet-Draft QUIC-LB July 2020
The server encodes the result in the routing bits. It MAY put any
other value into bits that used neither for routing nor config
rotation. These bits SHOULD appear random to observers.
4.3. Stream Cipher CID Algorithm
The Stream Cipher CID algorithm provides true cryptographic
protection, rather than mere obfuscation, at the cost of additional
per-packet processing at the load balancer to decrypt every incoming
connection ID. The CID format is depicted below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Octet | Nonce (X=64..128) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Server ID (Y=8..152-X) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| For server use (0..152-X-Y) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Stream Cipher CID Format
4.3.1. Configuration Agent Actions
The configuration agent assigns a server ID to every server in its
pool, and determines a server ID length (in octets) sufficiently
large to encode all server IDs, including potential future servers.
The configuration agent also selects a nonce length and an 16-octet
AES-ECB key to use for connection ID decryption. The nonce length
MUST be at least 8 octets and no more than 16 octets. The nonce
length and server ID length MUST sum to 19 or fewer octets.
4.3.2. Load Balancer Actions
Upon receipt of a QUIC packet, the load balancer extracts as many of
the earliest octets from the destination connection ID as necessary
to match the nonce length. The server ID immediately follows.
The load balancer decrypts the nonce and the server ID using the
following three pass algorithm:
Duke & Banks Expires 18 January 2021 [Page 12]
Internet-Draft QUIC-LB July 2020
* Pass 1: The load balancer decrypts the server ID using 128-bit AES
Electronic Codebook (ECB) mode, much like QUIC header protection.
The encrypted nonce octets are zero-padded to 16 octets. AES-ECB
encrypts this encrypted nonce using its key to generate a mask
which it applies to the encrypted server id. This provides an
intermediate value of the server ID, referred to as server-id
intermediate.
server_id_intermediate = encrypted_server_id ^ AES-ECB(key, padded-
encrypted-nonce)
* Pass 2: The load balancer decrypts the nonce octets using 128-bit
AES ECB mode, using the server-id intermediate as "nonce" for this
pass. The server-id intermediate octets are zero-padded to 16
octets. AES-ECB encrypts this padded server-id intermediate using
its key to generate a mask which it applies to the encrypted
nonce. This provides the decrypted nonce value.
nonce = encrypted_nonce ^ AES-ECB(key, padded-server_id_intermediate)
* Pass 3: The load balancer decrypts the server ID using 128-bit AES
ECB mode. The nonce octets are zero-padded to 16 octets. AES-ECB
encrypts this nonce using its key to generate a mask which it
applies to the intermediate server id. This provides the
decrypted server ID.
server_id = server_id_intermediate ^ AES-ECB(key, padded-nonce)
For example, if the nonce length is 10 octets and the server ID
length is 2 octets, the connection ID can be as small as 13 octets.
The load balancer uses the the second through eleventh octets of the
connection ID for the nonce, zero-pads it to 16 octets, uses xors the
result with the twelfth and thirteenth octet. The result is padded
with 14 octets of zeros and encrypted to obtain a mask that is xored
with the nonce octets. Finally, the nonce octets are padded with six
octets of zeros, encrypted, and the first two octets xored with the
server ID octets to obtain the actual server ID.
This three-pass algorithm is a simplified version of the FFX
algorithm, with the property that each encrypted nonce value depends
on all server ID bits, and each encrypted server ID bit depends on
all nonce bits and all server ID bits. This mitigates attacks
against stream ciphers in which attackers simply flip encrypted
server-ID bits.
The output of the decryption is the server ID that the load balancer
uses for routing.
Duke & Banks Expires 18 January 2021 [Page 13]
Internet-Draft QUIC-LB July 2020
4.3.3. Server Actions
When generating a routable connection ID, the server writes arbitrary
bits into its nonce octets, and its provided server ID into the
server ID octets. Servers MAY opt to have a longer connection ID
beyond the nonce and server ID. The additional bits MAY encode
additional information, but SHOULD appear essentially random to
observers.
If the decrypted nonce bits increase monotonically, that guarantees
that nonces are not reused between connection IDs from the same
server.
The server encrypts the server ID using exactly the algorithm as
described in Section 4.3.2, performing the three passes in reverse
order.
4.4. Block Cipher CID Algorithm
The Block Cipher CID Algorithm, by using a full 16 octets of
plaintext and a 128-bit cipher, provides higher cryptographic
protection and detection of non-compliant connection IDs. However,
it also requires connection IDs of at least 17 octets, increasing
overhead of client-to-server packets.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First octet | Encrypted server ID (X=8..128) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Zero Padding (Y=0..128-X) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted bits for server use (128-X-Y) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unencrypted bits for server use (0..24) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Block Cipher CID Format
4.4.1. Configuration Agent Actions
The configuration agent assigns a server ID to every server in its
pool, and determines a server ID length (in octets) sufficiently
large to encode all server IDs, including potential future servers.
The server ID will start in the second octet of the decrypted
connection ID and occupy continuous octets beyond that.
Duke & Banks Expires 18 January 2021 [Page 14]
Internet-Draft QUIC-LB July 2020
The configuration agent selects a zero-padding length. This SHOULD
be at least four octets to allow detection of non-compliant DCIDs.
The server ID and zero- padding length MUST sum to no more than 16
octets. They SHOULD sum to no more than 12 octets, to provide
servers adequate space to encode their own opaque data.
The configuration agent also selects an 16-octet AES-ECB key to use
for connection ID decryption.
4.4.2. Load Balancer Actions
Upon receipt of a QUIC packet, the load balancer reads the first
octet to obtain the config rotation bits. It then decrypts the
subsequent 16 octets using AES-ECB decryption and the chosen key.
The decrypted plaintext contains the server id, zero padding, and
opaque server data in that order. The load balancer uses the server
ID octets for routing.
4.4.3. Server Actions
When generating a routable connection ID, the server MUST choose a
connection ID length between 17 and 20 octets. The server writes its
provided server ID into the server ID octets, zeroes into the zero-
padding octets, and arbitrary bits into the remaining bits. These
arbitrary bits MAY encode additional information. Bits in the first,
eighteenth, nineteenth, and twentieth octets SHOULD appear
essentially random to observers. The first octet is reserved as
described in Section 3.
The server then encrypts the second through seventeenth octets using
the 128-bit AES-ECB cipher.
5. ICMP Processing
For protocols where 4-tuple load balancing is sufficient, it is
straightforward to deliver ICMP packets from the network to the
correct server, by reading the IP and transport-layer headers to
obtain the 4-tuple. When routing is based on connection ID, further
measures are required, as most QUIC packets that trigger ICMP
responses will only contain a client-generated connection ID that
contains no routing information.
To solve this problem, load balancers MAY maintain a mapping of
Client IP and port to server ID based on recently observed packets.
Duke & Banks Expires 18 January 2021 [Page 15]
Internet-Draft QUIC-LB July 2020
Alternatively, servers MAY implement the technique described in
Section 14.4.1 of [QUIC-TRANSPORT] to increase the likelihood a
Source Connection ID is included in ICMP responses to Path Maximum
Transmission Unit (PMTU) probes. Load balancers MAY parse the echoed
packet to extract the Source Connection ID, if it contains a QUIC
long header, and extract the Server ID as if it were in a Destination
CID.
6. Retry Service
When a server is under load, QUICv1 allows it to defer storage of
connection state until the client proves it can receive packets at
its advertised IP address. Through the use of a Retry packet, a
token in subsequent client Initial packets, and the
original_destination_connection_id transport parameter, servers
verify address ownership and clients verify that there is no "man in
the middle" generating Retry packets.
As a trusted Retry Service is literally a "man in the middle," the
service must communicate the original_destination_connection_id back
to the server so that it can pass client verification. It also must
either verify the address itself (with the server trusting this
verification) or make sure there is common context for the server to
verify the address using a service-generated token.
The service must also communicate the source connection ID of the
Retry packet to the server so that it can include it in a transport
parameter for client verification.
There are two different mechanisms to allow offload of DoS mitigation
to a trusted network service. One requires no shared state; the
server need only be configured to trust a retry service, though this
imposes other operational constraints. The other requires shared
key, but has no such constraints.
Retry services MUST forward all QUIC packets that are not of type
Initial or 0-RTT. Other packets types might involve changed IP
addresses or connection IDs, so it is not practical for Retry
Services to identify such packets as valid or invalid.
6.1. Common Requirements
Regardless of mechanism, a retry service has an active mode, where it
is generating Retry packets, and an inactive mode, where it is not,
based on its assessment of server load and the likelihood an attack
is underway. The choice of mode MAY be made on a per-packet or per-
connection basis, through a stochastic process or based on client
address.
Duke & Banks Expires 18 January 2021 [Page 16]
Internet-Draft QUIC-LB July 2020
A retry service MUST forward all packets for a QUIC version it does
not understand. Note that if servers support versions the retry
service does not, this may increase load on the servers. However,
dropping these packets would introduce chokepoints to block
deployment of new QUIC versions. Note that future versions of QUIC
might not have Retry packets, require different information in Retry,
or use different packet type indicators.
6.2. No-Shared-State Retry Service
The no-shared-state retry service requires no coordination, except
that the server must be configured to accept this service and know
which QUIC versions the retry service supports. The scheme uses the
first bit of the token to distinguish between tokens from Retry
packets (codepoint '0') and tokens from NEW_TOKEN frames (codepoint
'1').
6.2.1. Configuration Agent Actions
The configuration agent distributes a list of QUIC versions to be
served by the Retry Service.
6.2.2. Service Requirements
A no-shared-state retry service MUST be present on all paths from
potential clients to the server. These paths MUST fail to pass QUIC
traffic should the service fail for any reason. That is, if the
service is not operational, the server MUST NOT be exposed to client
traffic. Otherwise, servers that have already disabled their Retry
capability would be vulnerable to attack.
The path between service and server MUST be free of any potential
attackers. Note that this and other requirements above severely
restrict the operational conditions in which a no-shared-state retry
service can safely operate.
Retry tokens generated by the service MUST have the format below.
Duke & Banks Expires 18 January 2021 [Page 17]
Internet-Draft QUIC-LB July 2020
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| ODCIL (7) | RSCIL (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Connection ID (0..160) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Source Connection ID (0..160) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Data (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of non-shared-state retry service tokens
The first bit of retry tokens generated by the service MUST be zero.
The token has the following additional fields:
ODCIL: The length of the original destination connection ID from the
triggering Initial packet. This is in cleartext to be readable for
the server, but authenticated later in the token.
RSCIL: The retry source connection ID length.
Original Destination Connection ID: This also in cleartext and
authenticated later.
Retry Source Connection ID: This also in cleartext and authenticated
later.
Opaque Data: This data MUST contain encrypted information that allows
the retry service to validate the client's IP address, in accordance
with the QUIC specification. It MUST also provide a
cryptographically secure means to validate the integrity of the
entire token.
Upon receipt of an Initial packet with a token that begins with '0',
the retry service MUST validate the token in accordance with the QUIC
specification.
In active mode, the service MUST issue Retry packets for all Client