/
archive.json
4722 lines (4722 loc) · 256 KB
/
archive.json
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
{
"magic": "E!vIA5L86J2I",
"timestamp": "2021-01-25T17:22:09.800954+00:00",
"repo": "quicwg/load-balancers",
"labels": [
{
"name": "bug",
"description": "Something isn't working",
"color": "d73a4a"
},
{
"name": "documentation",
"description": "Improvements or additions to documentation",
"color": "0075ca"
},
{
"name": "duplicate",
"description": "This issue or pull request already exists",
"color": "cfd3d7"
},
{
"name": "enhancement",
"description": "New feature or request",
"color": "a2eeef"
},
{
"name": "good first issue",
"description": "Good for newcomers",
"color": "7057ff"
},
{
"name": "help wanted",
"description": "Extra attention is needed",
"color": "008672"
},
{
"name": "invalid",
"description": "This doesn't seem right",
"color": "e4e669"
},
{
"name": "question",
"description": "Further information is requested",
"color": "d876e3"
},
{
"name": "wontfix",
"description": "This will not be worked on",
"color": "ffffff"
},
{
"name": "editorial",
"description": "",
"color": "fc94f8"
},
{
"name": "needs-discussion",
"description": "",
"color": "32d5db"
}
],
"issues": [
{
"number": 6,
"id": "MDU6SXNzdWU1NzM2MjA2NDE=",
"title": "Setup CI",
"url": "https://github.com/quicwg/load-balancers/issues/6",
"state": "CLOSED",
"author": "martinthomson",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [],
"body": "The editor's draft and the `gh-pages` branch are currently empty.",
"createdAt": "2020-03-01T21:40:15Z",
"updatedAt": "2020-03-06T18:58:20Z",
"closedAt": "2020-03-06T18:58:20Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "I believe this is resolved.",
"createdAt": "2020-03-06T18:58:16Z",
"updatedAt": "2020-03-06T18:58:16Z"
}
]
},
{
"number": 7,
"id": "MDU6SXNzdWU1NzM2MjEwNzk=",
"title": "SCID acronym",
"url": "https://github.com/quicwg/load-balancers/issues/7",
"state": "CLOSED",
"author": "martinthomson",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [],
"body": "This is often used to mean Source Connection ID in other contexts. A collision here is likely to cause confusion.",
"createdAt": "2020-03-01T21:43:26Z",
"updatedAt": "2020-06-16T22:00:22Z",
"closedAt": "2020-06-16T22:00:22Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Recommended name? SCCID?",
"createdAt": "2020-03-06T20:57:02Z",
"updatedAt": "2020-03-06T20:57:02Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "I think it might just be best to call it the \"Server CID\" any other abbreviated term will get confused IMO.",
"createdAt": "2020-03-06T23:12:10Z",
"updatedAt": "2020-03-06T23:12:10Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "\"Server CID\" doesn't seem to fit well with \"Stream Cipher Connection ID\"",
"createdAt": "2020-03-09T15:21:30Z",
"updatedAt": "2020-03-09T15:21:40Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "So SCID didn't mean \"Server Connection ID\"? There is definitely confusion here. I'd just recommend not abbreviating anything more than CID.",
"createdAt": "2020-03-09T15:33:47Z",
"updatedAt": "2020-03-09T15:33:47Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "I guess this proves MT's point. \"STream Cipher Connection ID\" (just like PCID, OCID, BCID)",
"createdAt": "2020-03-09T15:54:35Z",
"updatedAt": "2020-03-09T15:54:35Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Looking again, the document never uses any acronym for 'stream cipher connection ID', so there's no issue there. This is just about 'S' meaning \"source\" or \"server\".",
"createdAt": "2020-05-26T18:04:23Z",
"updatedAt": "2020-05-26T18:04:23Z"
}
]
},
{
"number": 8,
"id": "MDU6SXNzdWU1NzM2MjQzMDg=",
"title": "Unguessable connection IDs",
"url": "https://github.com/quicwg/load-balancers/issues/8",
"state": "CLOSED",
"author": "martinthomson",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [
"needs-discussion"
],
"body": "There is a requirement that it be difficult for a party other than the server and load balancer to guess a CID that will be accepted as valid for a target connection.\r\n\r\nThis requirement needs to be validated for the schemes described in the draft. This might impose some constraints on the designs chosen.\r\n\r\nFor instance, I don't believe that the plaintext algorithm meets this goal. The server ID can take all the available space, which is probably wrong. Clearly it is impossible to create sufficient connection IDs for even a single connection if there is only one valid identifier per server. However, it might be argued that even an 18 byte server ID makes it too easy to guess a valid connection ID for a connection (just 16 guesses would be enough to get a 50% chance at that). So it seems to me that a shorter connection ID is necessary.\r\n\r\nThe same applies to any attempt at obfuscation.\r\n\r\nThe encrypted versions might be similarly challenging to get right. The For Server Use field in the stream cipher variant needs to be sufficiently long as to avoid engineered collisions. The value used for the stream cipher is malleable, which means that an attacker isn't prevented from guessing. In many ways, this is more challenging than the plaintext variant because the nonce consumes space.\r\n\r\nThe zero-padding in the block cipher mode might be the best way of preventing guessing, if it were sufficiently long. Similarly, if \"Encrypted bits for server use\" were sufficiently sparsely populated, then guessing can be hard enough.",
"createdAt": "2020-03-01T22:06:18Z",
"updatedAt": "2020-12-11T23:35:02Z",
"closedAt": "2020-12-11T23:35:02Z",
"comments": [
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "> There is a requirement that it be difficult for a party other than the server and load balancer to guess a CID that will be accepted as valid for a target connection.\r\n\r\n- What exactly does \"a CID that will be accepted as valid for a target connection\" mean?\r\n- What is exactly making this requirement?",
"createdAt": "2020-03-02T04:37:05Z",
"updatedAt": "2020-03-02T04:37:05Z"
},
{
"author": "martinthomson",
"authorAssociation": "MEMBER",
"body": "A connection ID that is accepted as valid for a target connection is any value that will cause packets to be routed to the node that serves that connection.\r\n\r\nThe transport draft [says](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-5.1-3):\r\n\r\n> Connection IDs MUST NOT contain any information that can be used by an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same connection. ",
"createdAt": "2020-03-02T23:30:13Z",
"updatedAt": "2020-03-02T23:30:13Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "I think this issue is conflating two different things:\r\n1) Is it easy to generate a CID that has a high probability of being considered valid by the LB? For all but BCID with zero-padding, the answer is clearly \"yes\" unless the SID space is sparsely populated. But that doesn't make them valid at the server. Moreover, if I am just trying to get random packets past the LB, it's far more productive to just generate a bunch of Initials.\r\n\r\nIn the absence of an LB, all CIDs get through to the server, so I don't understand why this is a problem.\r\n\r\n2) The transport draft language (it seems to me) exists mostly to prevent linkability in migration events. Although I've mentioned several times that linkability is a continuum, it is pretty clear that PCID fails at this and OCID makes it harder but no one would bet the house on it being truly secure -- hence the name.\r\n\r\nI think we're due for an actual WG discussion on OCID, but for PCID would it be sufficient for you, MT, if we said that servers using PCID MUST use disable_migration? To be honest, I thought I had already done this but it's not there.",
"createdAt": "2020-03-06T21:24:55Z",
"updatedAt": "2020-03-06T21:24:55Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "I really want to push back hard on any restrictions around migration for the Plaintext CID algorithm. It is by far the simplest and cheapest algorithm to support in the LB, and IMO must remain a valid option for QUIC load balancing.\r\n\r\nAs far as giving any information to an external observer, it's possible an external observer can work out the Server ID for each CID. Whether this is practically useful information depends on the number of connections being managed by the individual servers.\r\n\r\nIMO, we cannot restrict the full set of QUIC features to only work on the most complex and costly algorithms. Some solutions may never implement them.",
"createdAt": "2020-03-06T23:46:08Z",
"updatedAt": "2020-03-06T23:46:08Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Ah wait, I found the text in security considerations:\r\n\r\n> Servers that are running the Plaintext CID algorithm SHOULD only use it to generate new CIDs for the Server Initial Packet and SHOULD NOT send CIDs in QUIC NEW_CONNECTION_ID frames. Doing so might falsely suggest to the client that said CIDs were generated in a secure fashion.\r\n\r\nSo it's a SHOULD right now.",
"createdAt": "2020-03-09T16:52:00Z",
"updatedAt": "2020-03-09T16:52:00Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "To summarize the issue with Plaintext CID. This is the easiest to implement, so is mostly likely to be adopted.\r\n\r\nHowever:\r\n1) This makes DoS attacks on a single server quite straightforward. There is no consensus as to whether single-server DoS is a threat to mitigate or not.\r\n2) Makes connection IDs more linkable.\r\n3) Unless we add a server transport parameter for it, the client has no idea they're more linkable.\r\n4) We could prohibit migration to fix the linkability problem.\r\n5) If we prohibit migration, than the only reason to do plaintext CIDs, instead of just 5-tuple routing, is to support NAT rebinding.\r\n\r\nTo some extent, Obfuscated CID might have similar issues.",
"createdAt": "2020-07-03T18:15:43Z",
"updatedAt": "2020-07-03T18:15:43Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "The discussion at IETF 109 suggested that the level of linkability associated with the PCID algorithm did not violate the spirit of quic-transport (see @martinthomson and @ianswett in the QUIC-LB segment here: https://datatracker.ietf.org/meeting/109/materials/minutes-109-quic-00)",
"createdAt": "2020-12-11T23:35:02Z",
"updatedAt": "2020-12-11T23:35:02Z"
}
]
},
{
"number": 9,
"id": "MDU6SXNzdWU1NzM2Mjc1OTE=",
"title": "Effect on stateless resets",
"url": "https://github.com/quicwg/load-balancers/issues/9",
"state": "CLOSED",
"author": "martinthomson",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [],
"body": "The draft doesn't address the impact of each method of connection ID generation on how servers can use stateless resets.\r\n\r\nMost of this is likely bound up in decisions stemming from #8. If you can guess a valid but unused connection ID, then you might be able to induce a stateless reset that could be used to kill an open connection.\r\n\r\nAs the draft only includes methods that include an explicit server identifier, it is possible that as long as valid values cannot be guessed, the effect is minimal and each server instance can have its own configured stateless reset key (or a shared key from which a per-server key is derived using a KDF).",
"createdAt": "2020-03-01T22:30:24Z",
"updatedAt": "2020-07-06T19:17:21Z",
"closedAt": "2020-07-06T19:17:21Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "I don't understand the attack here. A given CID will deterministically map to a specific server instance. So there is no way for another server to receive a packet with that CID and generate a stateless reset. What am I missing?\r\n\r\n<strike>There might be something here with the differing treatment of long-header vs. short-header packets, (and the option for servers to send resets on long headers), but I'll have to think about it more.</strike>",
"createdAt": "2020-03-06T21:02:55Z",
"updatedAt": "2020-03-06T21:07:24Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "As to the last point, nope: even a long header with a DCID that conforms to the server's expectations (i.e. maps to a real server) will get delivered to that server, so I don't think that's an attack.",
"createdAt": "2020-03-06T21:06:56Z",
"updatedAt": "2020-03-06T21:06:56Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "@martinthomson Should we talk about this issue more, or are you satisfied enough that I can close it?",
"createdAt": "2020-05-26T18:12:10Z",
"updatedAt": "2020-05-26T18:12:10Z"
},
{
"author": "martinthomson",
"authorAssociation": "MEMBER",
"body": "I don't see any mention of stateless reset in the draft at all. That's probably something worth addressing, even if it is to say what you have already.",
"createdAt": "2020-05-27T01:39:55Z",
"updatedAt": "2020-05-27T01:39:55Z"
}
]
},
{
"number": 10,
"id": "MDU6SXNzdWU1NzM2Mjc5NTI=",
"title": "Moving connections between server instances",
"url": "https://github.com/quicwg/load-balancers/issues/10",
"state": "CLOSED",
"author": "martinthomson",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [
"editorial"
],
"body": "Some text on how a server cluster might support moving of connections from one server instance to another would be useful. The current design might permit portability under certain conditions, but there are things that might need to be considered, such as the way in stateless resets are generated.",
"createdAt": "2020-03-01T22:33:06Z",
"updatedAt": "2020-03-09T15:18:44Z",
"closedAt": "2020-03-09T15:18:44Z",
"comments": [
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "Are you referring to load balancing already existing connections to a new server? Are you envisioning the first server issuing new CIDs (that point to the new server) and setting Retire Prior To to retire the old CIDs so that future traffic redirect to the new server? How do you imagine the rest of the connection state would get moved?",
"createdAt": "2020-03-02T04:32:17Z",
"updatedAt": "2020-03-02T04:32:17Z"
},
{
"author": "martinthomson",
"authorAssociation": "MEMBER",
"body": "This applies to cases where clusters are rebalanced, where instances go down and others are expected to pick up the slack, and all similar cases. In some cases this requires an unspecified mechanism for transferring state between instances. In others, the instance might remain constant but the identifiers used might need to rotate.\r\n\r\nThis is likely addressed by using Retire Prior To as you say. Text on that would help.",
"createdAt": "2020-03-02T23:24:25Z",
"updatedAt": "2020-03-02T23:24:25Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Good idea, it wouldn't hurt to have a short non-normative section on this.",
"createdAt": "2020-03-06T20:56:34Z",
"updatedAt": "2020-03-06T20:56:34Z"
}
]
},
{
"number": 12,
"id": "MDU6SXNzdWU1NzQzMTUyMzE=",
"title": "Configuration ID might be too small",
"url": "https://github.com/quicwg/load-balancers/issues/12",
"state": "CLOSED",
"author": "martinthomson",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [
"needs-discussion"
],
"body": "As server clusters increase in size, the need to reallocate server identifiers becomes more acute. \r\n\r\nIn one model, the configuration ID is used to indicate a stable routing configuration. Server identifiers for a given configuration ID are routed to the same server, no matter how many other instances are added or removed. In order to allow for changes in the cluster, the configuration ID is used so that old servers can be removed from consideration and new ones added.\r\n\r\nIf these changes happen frequently enough, the number of bits allocated to identifying a configuration might be insufficient. Why not make the length of the identifier flexible? That might mean that you need to make the length of the length similarly configurable.",
"createdAt": "2020-03-02T23:28:35Z",
"updatedAt": "2020-12-11T23:36:47Z",
"closedAt": "2020-12-11T23:36:47Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "It was not the intent of these bits to support long-lived configurations, instead supporting key rotation, upgrades, and the like. I would much rather people overprovisioned the server ID space than using this tool, TBH.\r\n\r\nHowever, the only cost is limiting the theoretical size of CIDs. At the moment, we can support up to 64B, future-proofing the encodings against future versions of QUIC. I'm open to another bit for this, but how would a configurable number of CR bits work with multiple configurations? How does a config that needs 5 bits and one that needs 2 coexist, especially if the latter needs length self-encoding?",
"createdAt": "2020-03-06T20:39:11Z",
"updatedAt": "2020-03-06T20:39:11Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "As we talk through the implications of mutually mistrustful servers in #29, I think the case for adding another bit is compelling. I'm going to remove the needs-discussion label and come up with a PR that takes another bit.",
"createdAt": "2020-07-02T22:29:59Z",
"updatedAt": "2020-07-02T22:29:59Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "I'm returning this to needs-discussion, as @huitema points out there is a privacy tradeoff here.\r\n\r\nIf the config codespace is large, it's straightforward to have each mistrustful server have its own totally unique config. On the other hand, keeping this long-lived config difference leaks the type of flow. Assuming it's routed based on SNI, it leaks the SNI of each CID, and in that sense also increases linkability.",
"createdAt": "2020-07-06T19:10:03Z",
"updatedAt": "2020-07-06T19:10:03Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Alright, I've reflected on this a bit more.\r\n\r\nIn general, different server entities will have different external IP addresses and/or ports, so the load balancer can distinguish the correct QUIC-LB config without resorting to the CR bits. As IP and port are visible to everyone, there is no privacy leakage.\r\n\r\nThe problem occurs when mutually mistrustful servers share the same IP/port and are switched on something else. That \"something\" may be something present only in the client hello, with the classical load balancer simply using the 4tuple after that. The only thing I am aware of in practice is the SNI. If there are others, please say so in this thread.\r\n\r\nIf the SNI is encrypted, the unprivileged LB envisioned in QUIC-LB does not have access to it. So we can assume this use case only applies to unencrypted SNI.\r\n\r\nOption 1: mistrustful servers share the same config. a third party will be able to extract your server mapping, but in practice it will be hard for an attacker to obtain this position on purpose. If this is the best outcome, we can stick with 2 config rotation bits.\r\n\r\nOption 2: Issue them different config rotation codepoints. So an observer can see the SNI and associate it with certain CR bits; if the client later migrates, it will still be able to associate that connection with that SNI. If this is better than Option 1, we should probably add a third config rotation bit.\r\n\r\nOther (minor) costs of having 3 config rotation bits:\r\n- length self-encoding can only support 31 byte connection IDs, instead of 63 (obviously this is only relevant for hypothetical future versions of QUIC)\r\n- each config can have its own set of server IDs. So there is considerably more config state at the LB. As SIDs can be up to 18B, it's 18B x (# of servers) x (# of config rotation codepoints). This memory footprint will roughly double by going from 3 to 7 codepoints.\r\n\r\nI've talked myself into Option 1 as being a mildly better situation, thus sticking with 2 CR bits.\r\n\r\n\r\n\r\n",
"createdAt": "2020-10-28T21:36:02Z",
"updatedAt": "2020-10-28T21:36:02Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Update: the ECHO design might allow the LB privileged access to the SNI, so it might be encrypted. However, an attacker could connect to the domains at that IP and obtain the config rotation bits. So option 2 actually circumvents ESNI entirely!",
"createdAt": "2020-11-18T00:34:07Z",
"updatedAt": "2020-11-18T00:34:07Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Closing -- I have received no pushback on doing nothing (leaving it at 2 bits), so I'm going to do nothing.",
"createdAt": "2020-12-11T23:36:47Z",
"updatedAt": "2020-12-11T23:36:47Z"
}
]
},
{
"number": 16,
"id": "MDU6SXNzdWU1ODc5NDQ5Njc=",
"title": "Giving the client more information",
"url": "https://github.com/quicwg/load-balancers/issues/16",
"state": "CLOSED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [
"needs-discussion"
],
"body": "QUIC-LB has a bit of an incentive mismatch. The server infrastructure decides how linkable the CID algorithm is, but the client bears most of the cost of the CIDs being linkable. Worse yet, the client has no idea, without a lot of effort, what the servers are doing. Even worse, the servers have some incentives to pick something that's easily linkable.\r\n\r\nIn Section 8, it says:\r\n\r\n> Servers that are running the Plaintext CID algorithm SHOULD only use it to generate new CIDs for the Server Initial Packet and SHOULD NOT send CIDs in QUIC NEW_CONNECTION_ID frames\r\n\r\nThis is a concise way of not giving the client tools to link itself by trying an unsafe migration.\r\n\r\nWe could just stick with that. A richer way to go would be to create a new transport parameter (e.g. cid_is_linkable, cid_not_encrypted) that would explicitly communicate the risks to the client. We could have a different value for OCID or batch PCID and OCID together.\r\n",
"createdAt": "2020-03-25T19:41:47Z",
"updatedAt": "2020-12-11T23:32:07Z",
"closedAt": "2020-12-11T23:32:07Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Due to lack of enthusiasm at IETF 109, closing this issue.",
"createdAt": "2020-12-11T23:32:07Z",
"updatedAt": "2020-12-11T23:32:07Z"
}
]
},
{
"number": 20,
"id": "MDU6SXNzdWU2MTQyMDc4NTA=",
"title": "Load Balancing Invariant Longer Header Packets",
"url": "https://github.com/quicwg/load-balancers/issues/20",
"state": "CLOSED",
"author": "nibanks",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [],
"body": "We've had some discussion in this area in the past, and we decided that the best way to statelessly (and consistently) load balance long header packets would be to use a hash of the UDP 4-tuple and the client's source CID; since these are the only constants for all incoming (to the server) long header packets. I have come up with a couple of problems with this approach:\r\n\r\n1. As far as I know, there is no statement in the Invariants that says these must all stay constant for all future versions of QUIC.\r\n\r\n2. Using the hash approach can only function statelessly if there is not change in the DIP configuration. If the set of servers being load balanced changes (which we must assume to be common), then whatever stateless logic you have that maps hash to DIP would also change, resulting in long header packets getting routed incorrectly most likely.\r\n\r\n3. A follow up to (2), if you assume that the long header packets cannot therefore be routed statelessly based on the hash, and state must be tracked to continue to consistently route all long header packets until they are no longer used, at what point can the LB discard this state. By design, there is no on-path signal to indicate \"long header packets are no longer used\". Any heuristic that might be added here would be affected by (1) too.\r\n\r\nBecause of these issues, I'm left scratching my head on the best way to recommend to LBs on how to load balance invariant long header packets. The best thing I can think of is:\r\n\r\n- Use the hash mentioned above, but maintain state for each flow (tuple+client_cid).\r\n- Reset a timer (5 sec? 10 sec? 30 sec?) after each new packet is received for the flow. Discard the state when the timer fires.\r\n\r\nBecause the client's CID is included in the flow calculation, it allows an attacker to create nearly unlimited number of flow states on the LB. You might argue that Retry could be first used by a (cooperating) DoS appliance to first validate source address, but after that is done, this attack can still be executed. It would then require some heuristics on the LB to protect against.\r\n\r\n@martinduke @martinthomson any ideas here? ",
"createdAt": "2020-05-07T17:00:47Z",
"updatedAt": "2020-05-22T15:47:43Z",
"closedAt": "2020-05-22T15:47:43Z",
"comments": [
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "Another, simpler option is just to say live with the disruption of doing things statelessly. Only connections in the second round trip of the handshake would be affected (depending on loss). It's a fairly small window of time, compared to the lifetime of connections. But the clients that do get dropped have a really bad experience, because there will be no stateless reset to immediately kill their connection. They'd have to wait for a timeout.",
"createdAt": "2020-05-07T17:05:05Z",
"updatedAt": "2020-05-07T17:05:05Z"
},
{
"author": "udippant",
"authorAssociation": "NONE",
"body": "Re (2) - that problem exists for TCP as well. I.e. if you route an incoming TCP connection from a stateless L4LB to backend servers based on 4-tuple hash, any change in number of backend servers can result in the routing of subsequent packets for the same flow to a different backend server.\r\n\r\nUsing LRU cache for such connection table in L4LB has been a convenient way to address this issue for us ( for >99% of the flows). You may need to tune parameters such as size and TTL for items in the table to your needs. \r\nAlso, a pre-configured upper bound to limit the size of the connection table should address the concern you mentioned regarding exposure to attack vector of unlimited states in L4LB. \r\n\r\nFinally, even for LongHeader packets, packets of type 'Handshake' echo back the \"destination connection id' chosen by the server. So you can use similar logic to route these LongHeader sub-types as you use to route ShortHeader packets if the servers and L4Lb cooperatively choose the 'destination connection Id' [for e.g. as @martinduke proposed].",
"createdAt": "2020-05-07T18:39:41Z",
"updatedAt": "2020-05-07T18:39:41Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "Yeah, a LRU cache is a good solution. The difference between TCP and QUIC here is that TCP provides on path signals the LB can use to clean up state, but QUIC doesn't provide any. So, it' is purely a LRU + some timer.\r\n\r\nAlso, I'm looking for an invariant solution to routing packets. The fact that Handshake packets are similar to Short header packets assumes too much about the per-version semantics.",
"createdAt": "2020-05-07T18:55:28Z",
"updatedAt": "2020-05-07T18:55:28Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "The draft already addresses this issue in Section 4.\r\n\r\nExcept for some Initial and 0RTT packets, all DCIDs are server generated and so there is no routing problem.\r\n\r\nFor Initial/0RTT, the DCID might turn out to be routable (e.g. it came from a Retry). If not, it is a \"non-compliant DCID\" which is dropped if it's in a short header. If it's a long header:\r\n\r\n> 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.\r\n\r\nThis approach is designed to be version-invariant. I suppose a later version could drastically lengthen the time that non-server-generated CIDs were used, but I don't see why they would. The time scale till we get a server-generated CID is quite small, and if somehow the hash still messes up, the only affect is that 0RTT packets get sprayed where they aren't useful. I'm not too worried about that. Ultimately, if neither CID nor UDP tuple is stable, I don't know how you even map the packet to a connection independently of the load balancer problem.",
"createdAt": "2020-05-07T19:42:02Z",
"updatedAt": "2020-05-07T19:42:02Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "If we want a version-invariant solution (which is my immediate goal), we can't special case any of the long header packets based on type (Initial, Handshake, 0-RTT).\r\n\r\nBut, either way, @martinduke it sounds like you're in the boat of \"do it stateless and live with the (hopefully small) consequences\"?",
"createdAt": "2020-05-07T19:50:52Z",
"updatedAt": "2020-05-07T19:50:52Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Yes, I am on team stateless.\r\n\r\nWe don't need to process the packet subtype (Initial, Handshake, 0RTT). The QUIC-LB language just talks about long headers. There are some embedded assumptions: specifically, that client-generated DCIDs aren't around for a long time, and are only in long headers.\r\n\r\nI do think you're raised a point that we should explicity express our assumptions about version invariance. There are a few pathological things future versions could to to make the CID encoding fail: extremely small max CID lengths, client-generated CIDs in short headers, very long intervals before switching to server-generated CIDs, etc.\r\n\r\nMoreover, the LB requirement to use some algorithm that is invariant over small time scales raises some questions. How is the implementer to know if QUICv2 will allow the client first flight to have a consistent DCID but wildly varying SCIDs or UDP src ports? Or consistent SCID but randomized DCID?\r\n\r\nI'll write up a section to discuss these concerns, but I think we should just write them down and shrug.",
"createdAt": "2020-05-07T20:04:56Z",
"updatedAt": "2020-05-07T20:04:56Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "Does the invariants ever state that the tuple can't change during the handshake? If that's allowed in the future, the first packet could be from one tuple with the client chosen CID, then the next could be from a new tuple, with the server chosen CID...",
"createdAt": "2020-05-07T20:13:00Z",
"updatedAt": "2020-05-07T20:13:00Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "It does not. If we feel strongly that something is likely to not remain constant in some future version of QUIC, we can recommend it that LBs not use it in their algorithm. If not, we should just note the assumption and move on.",
"createdAt": "2020-05-07T20:17:45Z",
"updatedAt": "2020-05-07T20:17:45Z"
},
{
"author": "martinthomson",
"authorAssociation": "MEMBER",
"body": "There is a question here as to whether this is invariant, but here we go...\r\n\r\nThe goal is to route on the basis of connection ID as much as possible. But you don't always have an existing mapping. That might be because you don't know if the connection ID was generated locally, or because you know for certain that it wasn't. In those cases, the only thing you have to fall back on is the addressing information. So as Udip says, keeping a cache of flows for those packets you can't recognize is sensible.\r\n\r\nIn reading this, I was thinking \"what can the invariants draft say about this?\" And it seems like there is something we could say here.\r\n\r\nRight now, when you get a packet, there is some uncertainty about whether the destination connection ID is one of yours. That is pretty much unavoidable for the long header, unless we create a new invariant way of signaling this (which I don't think we will do). However, for the short header, I think we could say, definitively, that the connection ID is one that the destination server has selected. That might help load balancers in this situation. From my reading of this thread, it seems like this property was assumed throughout, but I realize that we never wrote that down.\r\n\r\n(You can avoid relying on this property by making your connection IDs self-authenticating, but you always have to suffer some false-positive chance, as the amount of data is pretty low.)\r\n\r\n",
"createdAt": "2020-05-07T23:23:54Z",
"updatedAt": "2020-05-07T23:24:58Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "Ideally, we'd want the following promises from the Invariants:\r\n\r\n- Short header packets always use your chosen CID\r\n- Long header packets never change UDP 4-tuple\r\n- Long header packets from the client have a constant source CID",
"createdAt": "2020-05-07T23:44:44Z",
"updatedAt": "2020-05-07T23:44:44Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Only 1 client-chosen server CID per connection would be sufficient as well,\nI think.\n\nFor packets that contain a client-chosen server CID, we need the LBs to\nhave something consistent to grab on to: this could be any combination of\nUDP address/port\nsource CID\ndestination CID.\n\nif any of these become invariant, we can tell LBs to use it exclusively\nwhen handling non-compliant DCIDs.\n\nOn Thu, May 7, 2020 at 4:44 PM Nick Banks <notifications@github.com> wrote:\n\n> Ideally, we'd want the following promises from the Invariants:\n>\n> - Short header packets always use your chosen CID\n> - Long header packets never change UDP 4-tuple\n> - Long header packets from the client have a constant source CID\n>\n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https://github.com/quicwg/load-balancers/issues/20#issuecomment-625551885>,\n> or unsubscribe\n> <https://github.com/notifications/unsubscribe-auth/AF2EYELEB2R2HHAFAP7RP23RQNBXRANCNFSM4M3P2FKA>\n> .\n>\n",
"createdAt": "2020-05-07T23:49:22Z",
"updatedAt": "2020-05-07T23:49:22Z"
},
{
"author": "martinthomson",
"authorAssociation": "MEMBER",
"body": "> Only 1 client-chosen server CID per connection would be sufficient as well, I think.\r\n\r\nThis is on the basis that the load balancer can route based on the destination connection ID always. I think that is right. And it might be my preferred option. The list of asks increases if you don't have that, as Nick points out.",
"createdAt": "2020-05-07T23:55:11Z",
"updatedAt": "2020-05-07T23:55:11Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Martin, the PR has a pretty good list of relevant things that are not quite\nguaranteed by the invariants draft. We don\u2019t have to have them all but if\nany are oversights please put them in.\n\nOn Thu, May 7, 2020 at 4:55 PM Martin Thomson <notifications@github.com>\nwrote:\n\n> Only 1 client-chosen server CID per connection would be sufficient as\n> well, I think.\n>\n> This is on the basis that the load balancer can route based on the\n> destination connection ID always. I think that is right. And it might be my\n> preferred option. The list of asks increases if you don't have that, as\n> Nick points out.\n>\n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https://github.com/quicwg/load-balancers/issues/20#issuecomment-625554775>,\n> or unsubscribe\n> <https://github.com/notifications/unsubscribe-auth/AF2EYENL4IYYE5PUFJ7LAWDRQNC6XANCNFSM4M3P2FKA>\n> .\n>\n",
"createdAt": "2020-05-08T01:20:13Z",
"updatedAt": "2020-05-08T01:20:13Z"
},
{
"author": "huitema",
"authorAssociation": "NONE",
"body": "In V1, we do assume that the addresses and ports will remain constant during the handshake. That means we can hash or route long header messages with the \"non-compliant DCID\" based on the combination of addresses, ports, SCID and DCID. This has an interesting robustness property: Initial packets sent by different parties will be routed to different contexts, even if the SCID and DCIDs collide -- either by mistake or intentionally. We may think of relaxing the rule in a future version and allow addresses to change during handshake, but I would not like losing the current robustness.",
"createdAt": "2020-05-08T01:38:58Z",
"updatedAt": "2020-05-08T01:39:43Z"
}
]
},
{
"number": 22,
"id": "MDU6SXNzdWU2MjMzMDQxNDM=",
"title": "Tweak non-compliant DCID recommendation",
"url": "https://github.com/quicwg/load-balancers/issues/22",
"state": "CLOSED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "@martinthomson sayeth on the list:\r\n\r\n> That routing will rely on the stability of a subset of fields. I would select from (source IP, source port, destination IP, destination port, DCID) and no others.\r\n\r\nIt would be useful to include something like this in Section 4 as a non-normative hint on what fields to use, since our hint currently consists of an example that just uses the DCID.\r\n\r\nSimilarly, make that assumption clearer in Section 8.\r\n",
"createdAt": "2020-05-22T15:50:03Z",
"updatedAt": "2020-07-01T00:47:53Z",
"closedAt": "2020-07-01T00:47:53Z",
"comments": [
{
"author": "DavidSchinazi",
"authorAssociation": "NONE",
"body": "For what it's worth, Google's load balancer only uses destination CIDs for routing. We always pick 64bit CIDs during the handshake so we can assume that short headers always carry 64bit CIDs.",
"createdAt": "2020-05-22T17:48:35Z",
"updatedAt": "2020-05-22T17:48:35Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Do all CIDs resolve to a valid server ID?",
"createdAt": "2020-05-22T18:15:45Z",
"updatedAt": "2020-05-22T18:15:45Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "@DavidSchinazi do you not care about an attacker specifically crafting destination CIDs to attack a particular server?",
"createdAt": "2020-05-22T18:39:21Z",
"updatedAt": "2020-05-22T18:39:21Z"
},
{
"author": "DavidSchinazi",
"authorAssociation": "NONE",
"body": "@martinduke \r\n> Do all CIDs resolve to a valid server ID?\r\n\r\nWe do not have a concept of server ID, but yes every CID routes to a server.\r\n\r\n@nibanks\r\n> @DavidSchinazi do you not care about an attacker specifically crafting destination CIDs to attack a particular server?\r\n\r\nWe do not care about that attack. I haven't seen any indication that it can actually cause harm in real life.",
"createdAt": "2020-05-22T19:41:49Z",
"updatedAt": "2020-05-22T19:41:49Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "@DavidSchinazi very well, then you have no non-compliant DCIDs. You would only need to upgrade your LBs for new versions if they allowed client-chosen DCIDs < 8 bytes.",
"createdAt": "2020-05-22T22:08:33Z",
"updatedAt": "2020-05-22T22:08:33Z"
}
]
},
{
"number": 23,
"id": "MDU6SXNzdWU2MjMzMzQxOTI=",
"title": "Fix Figures 3 and 4",
"url": "https://github.com/quicwg/load-balancers/issues/23",
"state": "CLOSED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "The bit variable length bit fields are wrong, and don't match the text. Fix them.",
"createdAt": "2020-05-22T16:32:44Z",
"updatedAt": "2020-05-26T18:14:13Z",
"closedAt": "2020-05-26T18:14:13Z",
"comments": []
},
{
"number": 27,
"id": "MDU6SXNzdWU2Mzc4NTQxNTY=",
"title": "Discuss uniqueness of config across load balancers",
"url": "https://github.com/quicwg/load-balancers/issues/27",
"state": "CLOSED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "Add a security consideration to avoid the following scenario:\r\n\r\nMyCloudProvider has a single QUIC-LB config for all its load balancers. It rotates keys periodically, etc, but everyone gets the same config. Obviously, all the attacker has to do is open an account with MyCloudProvider and it is able to recover all the server IDs.\r\n\r\nConfigs ought to be restricted to load balancers serving a finite set of servers. It is possible another MyCloudProvider customer is in the pool behind that load balancer, but that's already a privileged position as already described in the draft.\r\n\r\nObviously, this will require some wordsmithing, as the statement above isn't very precise.",
"createdAt": "2020-06-12T16:00:00Z",
"updatedAt": "2020-07-06T19:17:38Z",
"closedAt": "2020-07-06T19:17:38Z",
"comments": []
},
{
"number": 28,
"id": "MDU6SXNzdWU2NDAwMDg4NDM=",
"title": "Routing of ICMP Packet too big messages",
"url": "https://github.com/quicwg/load-balancers/issues/28",
"state": "CLOSED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "QUIC-LB LBs will not have the ability to properly route ICMP PTB messages without some additional work.\r\n\r\n1) Servers SHOULD prepend a garbage Handshake packet to their MSS Probes, so that the SCID is there.\r\n2) LBs SHOULD learn to parse these to extract the SCID and route them as they would a packet with that DCID.\r\n\r\nAlternatively, it could keep track of client IPs/ports and their mapping to servers.",
"createdAt": "2020-06-16T22:20:28Z",
"updatedAt": "2020-06-19T19:07:01Z",
"closedAt": "2020-06-19T19:07:01Z",
"comments": []
},
{
"number": 31,
"id": "MDU6SXNzdWU2NDIxNTk3NDk=",
"title": "Add retry_source_connection_id to Retry Service Token Format",
"url": "https://github.com/quicwg/load-balancers/issues/31",
"state": "CLOSED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "The server now needs to include this field.\r\n\r\nFor the no-shared state service, we just need language that the Retry service needs to encode enough information validate the packet DCID as well and drop if it fails validation. If it does, the server MUST use the packet DCID in the retry_source_connection_id TP.\r\n\r\nFor the shared state service, the retry source connection ID is going to have to be in the token. We might be able to compress this by xoring some fields; I'll think about it.",
"createdAt": "2020-06-19T18:45:31Z",
"updatedAt": "2020-06-29T19:11:43Z",
"closedAt": "2020-06-29T19:11:43Z",
"comments": []
},
{
"number": 34,
"id": "MDU6SXNzdWU2NDkzNTQzMjk=",
"title": "Support of server generated HCID with retry tokens",
"url": "https://github.com/quicwg/load-balancers/issues/34",
"state": "CLOSED",
"author": "huitema",
"authorAssociation": "NONE",
"assignees": [],
"labels": [],
"body": "Since draft 28, the retry mechanism includes a requirement that the client DCID in the retried connection matches the server SCID in the retry packet. I do not see a discussion of mechanisms to verify the retried DCID in section 5 of the draft.",
"createdAt": "2020-07-01T22:08:32Z",
"updatedAt": "2020-07-03T01:09:27Z",
"closedAt": "2020-07-03T01:09:27Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "I suggest you have a look at Sec 6 of the editor's draft:\r\nhttps://quicwg.org/load-balancers/draft-ietf-quic-load-balancers.html#name-retry-service",
"createdAt": "2020-07-02T22:27:49Z",
"updatedAt": "2020-07-02T22:27:49Z"
},
{
"author": "huitema",
"authorAssociation": "NONE",
"body": "Yes of course, this is addressed in the editor's draft. Let's close this issue.",
"createdAt": "2020-07-03T01:09:27Z",
"updatedAt": "2020-07-03T01:09:27Z"
}
]
},
{
"number": 35,
"id": "MDU6SXNzdWU2NDkzODQyODg=",
"title": "Using ECB for retry tokens seems sub optimal",
"url": "https://github.com/quicwg/load-balancers/issues/35",
"state": "CLOSED",
"author": "huitema",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "Section 5.3 specifies a Shared-State Retry Service describes a token format in which the token include the ODCID, a client IP encoded on 128 bits, and a 20 octets data-time, plus additional data. The token is encrypted using AES ECB. This seems sub-optimal:\r\n\r\n1) Using AES GCM or another AEAD format seems more natural. AEAD checks will immediately detect an invalid token, while using ECB forces reliance on invalidity heuristics.\r\n\r\n2) If using AEAD, there is no need to encode the IP address in the token. It can be derived from the IP header and placed in a pseudo header. The pseudo header can then be authenticated as part of AEAD decryption.\r\n\r\n3) The pseudo header approach can be used to authenticate other fields, e.g. verify that the DCID matches the SCID sent in the Retry packet.\r\n\r\n4) Encoding the time as 64 bits time64_t seems more natural than ASCII encoding, and also shorter.\r\n",
"createdAt": "2020-07-01T23:03:07Z",
"updatedAt": "2020-12-18T16:38:02Z",
"closedAt": "2020-12-18T16:38:02Z",
"comments": [
{
"author": "huitema",
"authorAssociation": "CONTRIBUTOR",
"body": "The editor draft also encodes the server's SCID in the token. That too could be moved to a pseudo-header, since the field is assume present in the DCID of the post retry Initial.",
"createdAt": "2020-07-03T01:11:09Z",
"updatedAt": "2020-07-03T01:11:09Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Closed by #33 ",
"createdAt": "2020-07-09T01:16:44Z",
"updatedAt": "2020-07-09T01:16:44Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "This was closed in error, as #33 deals with the Stream Cipher.",
"createdAt": "2020-11-03T18:51:20Z",
"updatedAt": "2020-11-03T18:51:20Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "I filed a very similar issue and then closed it when I realized the duplication. The text of that issue:\r\n\r\nI'm not an encryption expert, but if IIUC it's insufficiently hard to forge a shared-state retry token.\r\n\r\nBy inducing a Retry, an attacker can obtain the Retry SCID Length, and then focus entirely on an ODCIDs that allow the CID + CID Length part of the token to be a multiple of 16 B. For example, if RSCIDL= 10 B, then make ODCIDL = 20 B -> 32 Bytes for the block.\r\n\r\nThis then breaks Retry forgery into three separate problems:\r\n(1) Obtaining the mapping of IP Address to the first 16 Bytes of the token. A well-positioned observer could build a database of these in the time scale between token key rotations.\r\n(2) Generate lots of Retry tokens with an ODCID of the correct length, so there is a range of valid CID blocks.\r\n(3) Obtain a valid Retry every few seconds, using the right ODCID length, so that we have a valid timestamp.\r\n\r\nThus, the attacker has a database of\r\n\r\nvalid encrypted IP addresses\r\nvalid encrypted CIDs (really, it's the CID length that would cause validation to fail)\r\nvalid timestamps\r\nAs the spec uses AES-ECB, these blocks can be mixed and matched to create valid Retry tokens.\r\n\r\nThis is not exactly trivially open to attack [1], but it does feel like we're conceding a lot of entropy here. I would like someone to propose an alternate design that restores some of that entropy.\r\n\r\n[1] Step (1) seems to require a fairly privileged position in the network.",
"createdAt": "2020-11-03T19:06:18Z",
"updatedAt": "2020-11-03T19:06:18Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "@huitema Could I trouble you for a PR on this?",
"createdAt": "2020-11-03T19:43:57Z",
"updatedAt": "2020-11-03T19:43:57Z"
},
{
"author": "huitema",
"authorAssociation": "CONTRIBUTOR",
"body": "Sure. I can basically propose what I am doing in picoquic.\r\nAnd yes, the repetitive nature of ECB enables attacks.",
"createdAt": "2020-11-04T00:43:36Z",
"updatedAt": "2020-11-04T00:43:36Z"
},
{
"author": "huitema",
"authorAssociation": "CONTRIBUTOR",
"body": "@martinduke please review PR #59",
"createdAt": "2020-11-04T02:31:20Z",
"updatedAt": "2020-11-04T02:31:20Z"
}
]
},
{
"number": 38,
"id": "MDU6SXNzdWU2NTA3MTI2ODA=",
"title": "Make it clear the server might do length encoding on its own",
"url": "https://github.com/quicwg/load-balancers/issues/38",
"state": "CLOSED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [
"editorial"
],
"body": "The length encoding is mainly there for crypto offload, and the server MAY use this option even if the load balancer and config agent don't need it.",
"createdAt": "2020-07-03T17:49:04Z",
"updatedAt": "2020-07-06T19:18:09Z",
"closedAt": "2020-07-06T19:18:09Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Closing; this text already exists in Sec 3.3.",
"createdAt": "2020-07-06T19:18:09Z",
"updatedAt": "2020-07-06T19:18:09Z"
}
]
},
{
"number": 41,
"id": "MDU6SXNzdWU2NTUwMjU5NjQ=",
"title": "Simplify the configuration by merging server-id and zero-pad",
"url": "https://github.com/quicwg/load-balancers/issues/41",
"state": "CLOSED",
"author": "huitema",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "The encrypted CID format includes a zero-pad field that is used to detect whether the decryption succeeded or not. I suggest merging this field with the server ID field, and test whether the decryption succeed by checking whether the server ID is valid or not. This assumes that the server ID field is sparsely populated. For example, if there are just 256 servers, in theory a 1-octed field would be sufficient; instead, we could use a 4 or 5 octet server ID field that would be sparsely populated, allowing for error detection.\r\n\r\nThis would allow for unified validity detection across all supported methods:\r\n* clear text: verify that the server ID is valid;\r\n* obfuscated: the divider need to have the same size as the full length server ID; the modulo is the server ID; validity can be verified there.\r\n* stream: decrypt and verify that the server-id is valid\r\n* encrypt: decrypt and verify that the server-id is valid\r\n\r\nIt would also allows for simplification of the configuration for the encrypted method, by specifying just one field instead of two.",
"createdAt": "2020-07-10T20:43:31Z",
"updatedAt": "2020-07-20T18:39:51Z",
"closedAt": "2020-07-20T18:39:51Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Yes, I agree this is simpler with no cost at all. Care to do a PR?",
"createdAt": "2020-07-17T17:56:06Z",
"updatedAt": "2020-07-17T17:56:06Z"
}
]
},
{
"number": 42,
"id": "MDU6SXNzdWU2NTk0ODEwNzk=",
"title": "Fix terminology of Config Rotation",
"url": "https://github.com/quicwg/load-balancers/issues/42",
"state": "CLOSED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [
"editorial"
],
"body": "Erik Fuller points out via email:\r\n\r\n> This term \u201cconfiguration phase\u201d had me confused. These two sentences are the only place we reference it. It\u2019s basically a configuration ID so we can distinguish between settings across connections during a deployment, right? Once a new config is deployed, what happens to all the connections in the old format?\r\n> \r\n> After reading through I\u2019m still not certain what \u201cphase of the algorithm\u201d means\r\n\r\nHe's right. We should just call it a configuration ID and be clearer on what's what.",
"createdAt": "2020-07-17T17:57:49Z",
"updatedAt": "2020-07-17T22:15:08Z",
"closedAt": "2020-07-17T22:15:08Z",
"comments": []
},
{
"number": 46,
"id": "MDU6SXNzdWU2NjI1NTc4Njg=",
"title": "A little confused about configuration agent",
"url": "https://github.com/quicwg/load-balancers/issues/46",
"state": "CLOSED",
"author": "william-zk",
"authorAssociation": "NONE",
"assignees": [],
"labels": [
"editorial"
],
"body": "Hi Author:\r\n I have a little confused about 'configuration agent', from the description of draft, I think it should be a centralized control plane of 'load balancer' and 'server', but from the name 'agent', it seems like it should be a agent component which was used to receive message from control plane. So, what is the most correct definition of 'configuration agent'?",
"createdAt": "2020-07-21T04:11:13Z",
"updatedAt": "2020-08-14T02:10:45Z",
"closedAt": "2020-08-14T02:10:45Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "In the definitions section, it says: \"A \"configuration agent\" is\r\nthe entity that determines the QUIC-LB configuration parameters for the network\r\nand leverages some system to distribute that configuration.\"\r\n\r\nThe draft isn't really trying to define the architecture of the control plane. I'm not sure what the distinction is, for this spec, between being \"the control plane\" or something that \"receives messages from the control plane\". It is whatever is assigning server IDs.\r\n\r\nIs there other language that would make this clearer?\r\n",
"createdAt": "2020-07-29T20:14:56Z",
"updatedAt": "2020-07-29T20:14:56Z"
},
{
"author": "william-zk",
"authorAssociation": "NONE",
"body": "Um...I got it. My question comes from that we want to do an implementation about quic-lb, and contribute it to the nginx community, but for nginx, there are not any uniform centralized component to generate and distribute server ID, so we are confused with that if we should do a 'configuration agent' implementation. From your answer, we think that we can just open source quic-lb route ability, and provide a uniform server id usage api. ",
"createdAt": "2020-07-30T02:54:04Z",
"updatedAt": "2020-07-30T02:54:04Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Ah. So the draft originally had an in-band config channel but the group pulled it out for several reasons. I am personally not sure how people will deploy configurations for QUIC-LB in the real world, but for now you probably can't go wrong with adding the parameters to a configuration interface and just having a human being start the process.\r\n\r\nI would suspect that open source QUIC servers would have a check box that says \"accept QUIC-LB configuration\" or something and then it would open a REST interface or whatever to accept it. I would love to hear from cloud providers to understand what config frameworks there are, but I suspect we're going to write something down in a draft somewhere.",
"createdAt": "2020-07-30T03:14:53Z",
"updatedAt": "2020-07-30T03:14:53Z"
},
{
"author": "william-zk",
"authorAssociation": "NONE",
"body": "> I would suspect that open source QUIC servers would have a check box that says \"accept QUIC-LB configuration\" or something and then it would open a REST interface or whatever to accept it. I would love to hear from cloud providers to understand what config frameworks there are, but I suspect we're going to write something down in a draft somewhere.\r\n\r\nAh, maybe a brief introduction can be write into `1.1. Terminology`\r\n\r\n\r\n",
"createdAt": "2020-07-30T03:29:05Z",
"updatedAt": "2020-07-30T03:29:05Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "so this is already there:\r\nSec 1: \r\nWhile this document describes a small set of configuration parameters to make\r\nthe server mapping intelligible, the means of distributing these parameters\r\nbetween load balancers, servers, and other trusted intermediaries is out of its\r\nscope. There are numerous well-known infrastructures for distribution of\r\nconfiguration.\r\n\r\nSec 1.1\r\nA \"configuration agent\" is\r\nthe entity that determines the QUIC-LB configuration parameters for the network\r\nand leverages some system to distribute that configuration.\r\n\r\nIs this what you're looking for?",
"createdAt": "2020-08-13T19:48:52Z",
"updatedAt": "2020-08-13T19:48:52Z"
},
{
"author": "william-zk",
"authorAssociation": "NONE",
"body": "> so this is already there:\r\n> Sec 1:\r\n> While this document describes a small set of configuration parameters to make\r\n> the server mapping intelligible, the means of distributing these parameters\r\n> between load balancers, servers, and other trusted intermediaries is out of its\r\n> scope. There are numerous well-known infrastructures for distribution of\r\n> configuration.\r\n> \r\n> Sec 1.1\r\n> A \"configuration agent\" is\r\n> the entity that determines the QUIC-LB configuration parameters for the network\r\n> and leverages some system to distribute that configuration.\r\n> \r\n> Is this what you're looking for?\r\n\r\nOK, thanks for answering, I'd close this issue soon",
"createdAt": "2020-08-14T02:10:00Z",
"updatedAt": "2020-08-14T02:10:00Z"
}
]
},
{
"number": 47,
"id": "MDU6SXNzdWU2Njc3OTMyOTk=",
"title": "Cut obfuscated server ID algorithm",
"url": "https://github.com/quicwg/load-balancers/issues/47",
"state": "CLOSED",
"author": "martinthomson",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [],
"body": "As discussed at IETF 108. Split from #8.",
"createdAt": "2020-07-29T12:07:37Z",
"updatedAt": "2020-08-13T19:34:58Z",
"closedAt": "2020-08-13T19:34:58Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.",
"createdAt": "2020-07-29T18:57:32Z",
"updatedAt": "2020-07-29T18:57:32Z"
},
{
"author": "ianswett",
"authorAssociation": "NONE",
"body": "Removing this seems fine to me.",
"createdAt": "2020-07-29T19:16:23Z",
"updatedAt": "2020-07-29T19:16:23Z"
},
{
"author": "huitema",
"authorAssociation": "CONTRIBUTOR",
"body": "Yes, do it.",
"createdAt": "2020-07-29T19:24:46Z",
"updatedAt": "2020-07-29T19:24:46Z"
},
{
"author": "pravb",
"authorAssociation": "NONE",
"body": "Seems fine.",
"createdAt": "2020-07-29T19:24:52Z",
"updatedAt": "2020-07-29T19:24:52Z"
},
{
"author": "janaiyengar",
"authorAssociation": "NONE",
"body": "Do it.",
"createdAt": "2020-07-29T19:28:51Z",
"updatedAt": "2020-07-29T19:28:51Z"
},
{
"author": "DavidSchinazi",
"authorAssociation": "NONE",
"body": "Do it.",
"createdAt": "2020-07-29T19:34:21Z",
"updatedAt": "2020-07-29T19:34:21Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "Nick Harper concurred on the list",
"createdAt": "2020-07-29T19:59:45Z",
"updatedAt": "2020-07-29T19:59:45Z"
}
]
},
{
"number": 50,
"id": "MDU6SXNzdWU2ODcyMzU0MzE=",
"title": " A bit maybe used in cid to mark whether the server info encoded in the long header or not?",
"url": "https://github.com/quicwg/load-balancers/issues/50",
"state": "CLOSED",
"author": "Lingtaonju",
"authorAssociation": "NONE",
"assignees": [],
"labels": [],
"body": "Dear sir,\r\nAs you know, there is no bit in the cid to mark whether the cid encoded the server info or not. In this case, no matter the server info encoded or not, the load balancer needs to decrypt or decode the cid. Do you think this is a useless try when the packet is the first initial packet? Do you think this is a useful idea to expand the cid format to use the first bit to mark the cid encoded or not? However, in this case, the client need to obey the rule.",
"createdAt": "2020-08-27T13:17:16Z",
"updatedAt": "2020-10-10T02:21:56Z",
"closedAt": "2020-10-10T02:21:56Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "In fact, there is a bit. If the first two bits are '11' that means that the server didn't encode its ID and the load balancer should use 4-tuple routing:\r\n\r\nhttps://quicwg.org/load-balancers/draft-ietf-quic-load-balancers.html#name-configuration-failover\r\n\r\nThe very first packet usually has a CID chosen by the client, which knows nothing about QUIC-LB. The beginning of Section 4 is mostly about how load balancers should handle these.",
"createdAt": "2020-08-28T17:53:01Z",
"updatedAt": "2020-08-28T17:53:01Z"
},
{
"author": "Lingtaonju",
"authorAssociation": "NONE",
"body": "OK, I almost have forgot the first two Config Rotation bits can be used to mark the cid server info's validity.\r\n\r\nHowever, in this case, I want to know , for the very first packet, will the draft suggest the clients to generate the dcid with the first two bits \"11\" , if they know the QUIC-LB used.\r\n \r\nAs, if so, the QUIC-LB know all packets' cid information to prevent useless decode/decrypt try for the very first packet.",
"createdAt": "2020-08-31T06:23:21Z",
"updatedAt": "2020-08-31T06:26:28Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "No, this draft does not assume client cooperation at all. The very beginning of Section 4 explains how to handle client-generated CIDs.",
"createdAt": "2020-08-31T15:59:29Z",
"updatedAt": "2020-08-31T15:59:29Z"
},
{
"author": "Lingtaonju",
"authorAssociation": "NONE",
"body": "> No, this draft does not assume client cooperation at all. The very beginning of Section 4 explains how to handle client-generated CIDs.\r\n\r\nThanks for your reply. Actually, I understand your works and Section 4.\r\nHowever, my point is that , even this draft does not assume client cooperation at all, this draft can suggest the client to generate a cid with 11 for the very first initial packet.\r\n\r\nThis is useful for QUIC-LB if client obeys the rule, if not , the Section 4 also works well. \r\n",
"createdAt": "2020-09-01T12:27:05Z",
"updatedAt": "2020-09-01T12:27:46Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "In #52 I'm adding CR bits as a reason for noncompliance.\r\n\r\nIt's fine if the client wants to set '11' , but I don't think it's important to do that. At most all we're saving the LB is a very small decrypt operation.",
"createdAt": "2020-09-01T15:51:43Z",
"updatedAt": "2020-09-01T15:51:43Z"
},
{
"author": "Lingtaonju",
"authorAssociation": "NONE",
"body": "Even thought the decryption has a low consumption, I insist that the cost can be avoided.\r\n\r\nI admit that the lb can't assume client cooperation at all, however, the draft can suggest the client to obey the rule: \r\n_\" As, it is impossible for the client to know the server information at the beginning of the QUIC conn, so the DCID in the initial can't encode the server info, in this case, the Client should make the first two bits with \"11\". \"_\r\n",
"createdAt": "2020-09-14T02:18:57Z",
"updatedAt": "2020-09-14T02:18:57Z"
}
]
},
{
"number": 51,
"id": "MDU6SXNzdWU2ODcyNDY5MDk=",
"title": "Any suggestion about transmit client ip from quic-lb to quic-server?",
"url": "https://github.com/quicwg/load-balancers/issues/51",
"state": "CLOSED",
"author": "william-zk",
"authorAssociation": "NONE",
"assignees": [],
"labels": [],
"body": "Dear author:\r\n As you know, in many production scenarios, quic-server need to know the real ip/port of client. But when there is a quic-lb in the middle(a fullnat quic-lb), there are not any standard way to implement this function. Actually this function is not difficult to implement, will quic-lb-draft suggest or define a standard way for this function later?",
"createdAt": "2020-08-27T13:33:15Z",
"updatedAt": "2020-10-30T15:07:53Z",
"closedAt": "2020-10-30T15:07:53Z",
"comments": [
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "That is not currently an objective for this document. I would probably start with taking the PROXY protocol and adapting it for UDP. Perhaps that would be a good draft!",
"createdAt": "2020-08-28T17:59:35Z",
"updatedAt": "2020-08-28T17:59:35Z"
},
{
"author": "william-zk",
"authorAssociation": "NONE",
"body": "Ah, I got it",
"createdAt": "2020-08-31T11:38:02Z",
"updatedAt": "2020-08-31T11:38:02Z"
},
{
"author": "william-zk",
"authorAssociation": "NONE",
"body": "Um...I reconsider the situation, can UDP-PROXY-protocol cover all UDP-based transport protocol? Consider this, for QUIC, we may send client ip to quic-server when receive initial packet. For RTP, we may send client ip to real-server when receive first packet...\r\nThere are so much UDP-based protocol, can all situation be covered in one draft?",