Script updating archive at 2021-01-25T17:22:11Z. [ci skip]

archive.json

@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2021-01-15T19:11:43.116473+00:00",
+  "timestamp": "2021-01-25T17:22:09.800954+00:00",
   "repo": "quicwg/load-balancers",
   "labels": [
     {
@@ -1546,14 +1546,75 @@
       "id": "MDU6SXNzdWU3ODQ1ODE1NDA=",
       "title": "Allow-list and deny-list for QUIC versions",
       "url": "https://github.com/quicwg/load-balancers/issues/82",
-      "state": "OPEN",
+      "state": "CLOSED",
       "author": "martinduke",
       "authorAssociation": "CONTRIBUTOR",
       "assignees": [],
       "labels": [],
       "body": "It would help the anti-DDoS properties if the Retry Service could receive explicit instructions about which QUIC versions the server might support. This provides a way to deploy new versions without having to upgrade the retry service software or hardware.",
       "createdAt": "2021-01-12T20:45:39Z",
-      "updatedAt": "2021-01-12T20:45:39Z",
+      "updatedAt": "2021-01-25T17:21:42Z",
+      "closedAt": "2021-01-25T17:21:42Z",
+      "comments": []
+    },
+    {
+      "number": 84,
+      "id": "MDU6SXNzdWU3ODczMTA5MDA=",
+      "title": "Low-Config CID creating huge problems with coexistence of configurations",
+      "url": "https://github.com/quicwg/load-balancers/issues/84",
+      "state": "OPEN",
+      "author": "martinduke",
+      "authorAssociation": "CONTRIBUTOR",
+      "assignees": [],
+      "labels": [],
+      "body": "For low-config CID (LCID), which dynamically allocates server IDs, the current editor's draft has a heuristic to extract a server ID from a client-generated non-compliant CID. The fundamental issue is that the server *has* to get an SID from an incoming Initial, even if the SR bits of the Connection ID imply that it doesn't map to the LCID config.\r\n\r\n> \r\n> If the DCID references the 4-tuple routing bits or an undefined configuration, use the following procedure to establish a predictable template for server ID extraction:\r\n> * Identify the instance of Low-Config CID configuration with the largest config rotation codepoint. For example, if configurations 0b10, 0b01, and 0b00 all use the low-config CID algorithm and have server ID lengths of 3, 5, and 7 octets, respectively, and a packet comes in with codepoint 0b11, the load balancer would extract 3 octets for the server ID.\r\n> * Extract the appropriate number of octets.\r\n> * If the server ID matches one already in the table, forward the packet to that server.\r\n> * If not, the load balancer runs the algorithm of its choosing and adds the extracted server ID to the table corresponding to the highest-value Low-Config CID Configuration codepoint.\r\n\r\nThis doesn't work with config rotation. The main principle in CR is that the load balancer needs to get the configuration first -- otherwise the server might generate CIDs that the LB can't route, and we break ongoing connections. Given that, we have a problem. Consider:\r\n\r\n1. LB and server both have LCID configuration 0b00 with SIDL of 1.\r\n2. LB gets LCID configuration 0b01 with an SIDL of 2.\r\n3. LB gets a packet with CR bits 0b01 and octets 2-3 0xfa13, and randomly forwards it to the server\r\n4. The LB will add an SID entry for 0xfa13, but the server will add an SID entry for 0xfa.\r\n5. The server will generate CIDs with CR 0xb00 and SID 0xfa, and the LB will not route them correctly.\r\n\r\nStated more generally: in the current design, the LB can never be sure if the server has a given configuration and that makes it very hard for the LB to infer what the server is going to do with a given CID to get an SID for its table. We don't even know if it's non-compliant at the server or not!\r\n\r\nThere are some potential fixes here:\r\n1) Give up on dynamic server ID allocation\r\n2) Have the LB keep track of config rotation bits it's observed in short header packets to each server -- this is an indication the server has the CR bits. This is also seems vulnerable to attack with injection of random short-header packets.\r\n3) Reserve the SID corresponding to *all* configurations when routing a packet. In effect, this makes it impossible to adapt the crypto algorithms to use dynamically allocated server ID and have them coexist with plaintext ones: the crypto algorithms will essentially have randomly distributed plaintext fields, so the table will fill up fast.\r\n4) Remove config rotation from dynamic allocation; this makes changes to config a site maintenance event. This also effectively prevents using crypto with dynamic allocation, because you can't rotate keys.\r\n5) Change the behavior of a server when it gets CR bits it doesn't understand. Don't extract a server ID. If the server has no IDs because it just booted, simply echo the client-generated CID. When the server gets a config that lets it extract an SID from this, or gets a CID on another connection that it can decode, then it can update the CID on this connection. This implies that we could have valid short header packets with non-compliant DCIDs, so we'd have to have the LB admit these instead of dropping them like it does currently.\r\n6) Same as #5, but instead of echoing the client-generated CID, it uses the 4-tuple routing bits for a new CID. This will make the\r\nCID compliant, but abandon the whole purpose of QUIC-LB until an Initial with the right CR bits arrives (1 in 4 chance per connection).\r\n\r\n***\r\n\r\nUnfortunately, this breaks even more badly it coexists with a configuration with static SIDs. Another example:\r\n1. LB and server have LCID config 0b00 with an SIDL of 1. Server A has SID 0x01 and Server B has SID 0x02.\r\n2. LB gets stream CID config 0b01 (encrypted, static SIDs)\r\n3. An Initial packet has CR bits 0b01. The second octet is 0x02 but the proper SCID decoding maps to Server A. So, it routes to Server A.\r\n4. Server A doesn't have config 0b01 yet, so it extracts an SID from the CID and adds 0x02 to its list of SIDs. It generates an Low-config CID that the LB will route to Server B!\r\n\r\nFrom this, I conclude that dynamically and statically configured SIDs can't safely coexist in the same config space.\r\n\r\n***\r\n\r\nThis is all very hard to reason about. All the options are ugly but my instinct is to retreat to the first option and just abandon this dynamic design.\r\n\r\n\r\n",
+      "createdAt": "2021-01-16T01:05:23Z",
+      "updatedAt": "2021-01-16T07:00:41Z",
+      "closedAt": null,
+      "comments": [
+        {
+          "author": "huitema",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "For the stateless algorithm, can we assume that servers are configured with a \"current epoch\" in a way that's properly synchronized with the LB, and that the epoch is encoded in the first byte of the \"compliant\" CID? Then the LB can do the following:\r\n\r\n1) For Initial packets, assume non compliance. Treat CID as if they were part of the current epoch. Derive mapping from CID to server ID according to current epoch' key. \r\n\r\n2) For all other packets, assume compliance. If epoch is \"too old\", drop the packet (server should have sent new CID to client.) Otherwise, derive mapping from CID to server ID according to specified epoch' key. (Or if CID in cache, use cache.)\r\n",
+          "createdAt": "2021-01-16T03:18:45Z",
+          "updatedAt": "2021-01-16T03:18:45Z"
+        },
+        {
+          "author": "martinduke",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "Thanks Christian!\r\n\r\nI am not sure I fully understand your proposal, but I will make some points:\r\n\r\n1) quic-lb tries to distinguish only short-header and long-header packets to remain version invariant. There is no notion of Initials.\r\n\r\n2) the second Initial carries a server generated CID, and 0RTT does not. so it is not so simple as sniffing the Initial codepoint.\r\n\r\n3) IIUC the CR codepoint is much like your \"epoch.\" I think the problem is when you are switching epochs; the LB must understand both and can't be sure which epoch any given server is on. Indeed, this is the heart of the issue.\r\n\r\nOr perhaps I've wildly misunderstood your proposal.",
+          "createdAt": "2021-01-16T05:51:00Z",
+          "updatedAt": "2021-01-16T05:51:00Z"
+        },
+        {
+          "author": "huitema",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "So it boils down to a synchronization problem. The LB knows that a server is in epoch N+1 if it sees a CID from that server with the new epoch. So the transition will work like this:\r\n\r\n1) Before transition, server use epoch N. LB sees from that server CID with epoch N.\r\n2) At some point, LBtransitions to N+1.\r\n3) If the server notices the LB's transition, it also moves to epoch N+1\r\n4) Some time after that, the LB sees clients sending packets to that server with DCID marked for epoch N+1, at which points it knows server and LB are synchronized.\r\n\r\nThe main problem is that there is no synchronization signal from LB to server. The server cannot look at the ID and infer that the LB has moved to a new epoch.\r\n\r\nIt might be possible to use the retry frames to solve that. When it receives a new initial that would map to server X before confirmation that server X is on epoch N+1, the LB might send a retry to the client, suggesting a conforming DCID marked with epoch N+1. The server will receive the retried Initial, and learn that the new epoch has started. The idea probably needs some exploring, but that seems plausible.",
+          "createdAt": "2021-01-16T06:28:44Z",
+          "updatedAt": "2021-01-16T06:29:37Z"
+        },
+        {
+          "author": "martinduke",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "Assuming handshakes are going on, yes, LBs can see what configs are operating. This is my option 2 but using egress SCID instead of ingress DCID, definitely an improvement.\r\n\r\nSeveral drafts ago we moved away from explicit in-band signaling. Now we're headed back.",
+          "createdAt": "2021-01-16T07:00:41Z",
+          "updatedAt": "2021-01-16T07:00:41Z"
+        }
+      ]
+    },
+    {
+      "number": 85,
+      "id": "MDU6SXNzdWU3ODczMjA2MjY=",
+      "title": "Bytes for server use",
+      "url": "https://github.com/quicwg/load-balancers/issues/85",
+      "state": "OPEN",
+      "author": "martinduke",
+      "authorAssociation": "CONTRIBUTOR",
+      "assignees": [],
+      "labels": [],
+      "body": "Make sure each algorithm always provides 2-3 octets for server use. The current SID limits don't do that.",
+      "createdAt": "2021-01-16T01:48:21Z",
+      "updatedAt": "2021-01-16T01:48:21Z",
       "closedAt": null,
       "comments": []
     }
@@ -4634,24 +4695,26 @@
       "id": "MDExOlB1bGxSZXF1ZXN0NTUzNzY1NTgx",
       "title": "Added version allow-lists and deny-lists to Retry services",
       "url": "https://github.com/quicwg/load-balancers/pull/83",
-      "state": "OPEN",
+      "state": "MERGED",
       "author": "martinduke",
       "authorAssociation": "CONTRIBUTOR",
       "assignees": [],
       "labels": [],
       "body": "Fixes #82. Hopefully this will close the gap between what we want Retry Services to do and reality.",
       "createdAt": "2021-01-12T21:15:19Z",
-      "updatedAt": "2021-01-13T20:12:34Z",
+      "updatedAt": "2021-01-25T17:21:43Z",
       "baseRepository": "quicwg/load-balancers",
       "baseRefName": "master",
       "baseRefOid": "59321280e476bba2ffdb785256fc2f13995de069",
       "headRepository": "quicwg/load-balancers",
       "headRefName": "allow-deny-list",
       "headRefOid": "8fa98ee3f8d1378ef77cefe260c3b51c7d5931e1",
-      "closedAt": null,
-      "mergedAt": null,
-      "mergedBy": null,
-      "mergeCommit": null,
+      "closedAt": "2021-01-25T17:21:42Z",
+      "mergedAt": "2021-01-25T17:21:42Z",
+      "mergedBy": "martinduke",
+      "mergeCommit": {
+        "oid": "173222c345575842cc6b7061022d13c72d7410fb"
+      },
       "comments": [],
       "reviews": []
     }