Skip to content

Commit

Permalink
Script updating archive at 2022-05-24T18:13:45Z. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed May 24, 2022
1 parent 5f800c4 commit 3102c0c
Showing 1 changed file with 116 additions and 14 deletions.
130 changes: 116 additions & 14 deletions archive.json
View file
@@ -1,6 +1,6 @@
{
"magic": "E!vIA5L86J2I",
"timestamp": "2022-04-26T16:53:42.700659+00:00",
"timestamp": "2022-05-24T18:13:42.736370+00:00",
"repo": "quicwg/load-balancers",
"labels": [
{
Expand Down Expand Up @@ -3000,7 +3000,7 @@
"labels": [],
"body": "There are cases where an offload might send Retry on the second initial but not the first:\r\n- it turns on between the two packets\r\n- it is in a stochastic mode where it doesn't always send Retry\r\n\r\nThere is one failure mode and one degraded performance issue:\r\n1) If the server sends HRR, if the client's response triggers Retry it is likely to blackhole the connection.\r\n2) Under certain conditions, dropping the client's second Initial packet will cause either a client or server PTO. (Specifically, there will be no penalty if the client's 2nd flight has a datagram that (a) does not contain an initial, and (b) contains a HS ACK.)\r\n\r\nWe ought to write this down in the draft. For #1, it might be good practice for servers to send CONNECTION_CLOSE instead of HRR under two conditions:\r\n1) There is no Retry token in the Initial, and\r\n2) Other recent initials contained Retry tokens.",
"createdAt": "2022-03-30T16:31:37Z",
"updatedAt": "2022-04-12T16:42:32Z",
"updatedAt": "2022-05-24T13:43:50Z",
"closedAt": null,
"comments": [
{
Expand All @@ -3009,6 +3009,27 @@
"body": "The amplification limit is a problem here. If the client's second flight is one packet, including an Initial, which keeps getting dropped, and the server is at its amplification limit, there is no way for the connection to progress.",
"createdAt": "2022-04-12T16:42:32Z",
"updatedAt": "2022-04-12T16:42:32Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "As I mentioned in OR #170, I think we need to handle this via an extension to the QUIC protocol itself. I recommend we define an extension that does the following:\r\n\r\nThe server includes a new transport parameter `initial_token` that contains the value of the initial token that clients should use for any subsequent initial packets they send. If the client understands this extension/TP, it acts accordingly. If it does not, then it may hit the issues you describe in this PR and eventually time out.",
"createdAt": "2022-05-11T12:46:12Z",
"updatedAt": "2022-05-11T12:46:12Z"
},
{
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"body": "So the problem with using a TP is that it isn't delivered until the Encrypted Extensions messages, which is far too late for most of the failure modes here.\r\n\r\nHowever, I've thought more carefully about this and have realized some things.\r\n\r\n1. Offload statefulness doesn't completely solve it, as you could have a shared-state retry where an anti-DDoS service turns on and suddenly has all packets route through it. \r\n\r\n2. If an offload is going to randomly send Retry while being stateless, it really ought to be pseudorandom based on the address/port or whatever. Therefore, the two Initial packets will get the same treatment in the usual case. That reduces to the problem to \"service turns on mid-handshake\".\r\n\r\n3. Case 1 is where Retry offload breaks the Initial + Handshake flight. This isn't actually a black hole. The client will retransmit handshake packets and, per RFC9001 4.9.1, MUST NOT send Initial packets once it's sent a handshake. So there might be a PTO, which is not ideal, but not catastrophic. In the normal case, there are multiple server handshake packets, and if the client is following spec and not doing ack delay in the handshake, it is unlikely the entire Handshake ACK will be coalesced with Initial. **So let's forget about this \"problem\", and we don't need to do any weird packet truncation as in PR #170.**\r\n\r\n4. Case 2 is HRR or Multi-packet SHLO: this is the harder case as Initial ACKs are critical to progress. HRR is an edge case but post-quantum we may need multi-packet SHLO, and it would be good for this design to be robust to that. I don't see a realistic fix here right now but I'll think about it some more.",
"createdAt": "2022-05-23T23:33:14Z",
"updatedAt": "2022-05-23T23:33:40Z"
},
{
"author": "nibanks",
"authorAssociation": "MEMBER",
"body": "> So the problem with using a TP is that it isn't delivered until the Encrypted Extensions messages, which is far too late for most of the failure modes here.\r\n\r\nCrap. You're obviously totally right. I don't know how I forgot. I still thing the right way to handle this is to somehow give the client the `initial_token` along with the server's initial payload. I might propose a slight modification of my original plan:\r\n\r\nThe client includes a new transport parameter `initial_token` (with no payload) that advertises support for this new extension. If the server supports this extension, it includes a `initial_token` **frame** in all its Initial packets, and then also includes the `initial_token` transport parameter that also contains the value of the initial token (so that it can be securely validated). Clients should use the `initial_token` frame value for any subsequent initial packets they send.",
"createdAt": "2022-05-24T13:43:50Z",
"updatedAt": "2022-05-24T13:43:50Z"
}
]
},
Expand All @@ -3017,15 +3038,15 @@
"id": "I_kwDODoD6yc5HJWqs",
"title": "Index depends on length",
"url": "https://github.com/quicwg/load-balancers/issues/166",
"state": "OPEN",
"state": "CLOSED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "In the second crypto review (#164) there was a note that plaintexts of different lengths might end up with similar results, if the extra bits were zeros. The suggestion to fix this was to update the path index to also include the length.",
"createdAt": "2022-04-05T19:37:11Z",
"updatedAt": "2022-04-05T19:37:11Z",
"closedAt": null,
"updatedAt": "2022-04-26T19:02:19Z",
"closedAt": "2022-04-26T19:02:19Z",
"comments": []
},
{
Expand Down Expand Up @@ -8815,24 +8836,26 @@
"id": "PR_kwDODoD6yc41r65S",
"title": "updated index calculation",
"url": "https://github.com/quicwg/load-balancers/pull/167",
"state": "OPEN",
"state": "MERGED",
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [],
"body": "Fix #166 in accordance with the 2nd crypto review",
"createdAt": "2022-04-05T20:50:14Z",
"updatedAt": "2022-04-26T16:53:16Z",
"updatedAt": "2022-04-26T19:02:20Z",
"baseRepository": "quicwg/load-balancers",
"baseRefName": "main",
"baseRefOid": "cf4c59ea1d54b6023a36458192ff0ce058cdbfc6",
"headRepository": "quicwg/load-balancers",
"headRefName": "fix-index",
"headRefOid": "6b9ea5196af77aa9f67db3950e85884b8c70c4a1",
"closedAt": null,
"mergedAt": null,
"mergedBy": null,
"mergeCommit": null,
"headRefOid": "9f889f12f5b72dcb752f22d82cf46acc4c59e39c",
"closedAt": "2022-04-26T19:02:19Z",
"mergedAt": "2022-04-26T19:02:19Z",
"mergedBy": "martinduke",
"mergeCommit": {
"oid": "5635d1aacebb3c3bc5441e80e8a3202a640baa95"
},
"comments": [],
"reviews": [
{
Expand Down Expand Up @@ -8894,6 +8917,32 @@
"updatedAt": "2022-04-26T06:39:45Z"
}
]
},
{
"id": "PRR_kwDODoD6yc442ZLH",
"commit": {
"abbreviatedOid": "6b9ea51"
},
"author": "huitema",
"authorAssociation": "CONTRIBUTOR",
"state": "APPROVED",
"body": "Looks good, except for the missing parenthesis.",
"createdAt": "2022-04-26T17:44:04Z",
"updatedAt": "2022-04-26T17:46:50Z",
"comments": [
{
"originalPosition": 25,
"body": "Missing parenthesis. Should be `expand_right(0xaaba3c, 0x0b, 0x02)`.",
"createdAt": "2022-04-26T17:44:05Z",
"updatedAt": "2022-04-26T17:46:50Z"
},
{
"originalPosition": 58,
"body": "This comment is addressed in the new text.",
"createdAt": "2022-04-26T17:44:43Z",
"updatedAt": "2022-04-26T17:46:50Z"
}
]
}
]
},
Expand All @@ -8911,7 +8960,7 @@
"labels": [],
"body": "Fix #165",
"createdAt": "2022-04-12T18:06:40Z",
"updatedAt": "2022-04-12T18:06:40Z",
"updatedAt": "2022-05-23T21:15:23Z",
"baseRepository": "quicwg/load-balancers",
"baseRefName": "main",
"baseRefOid": "cf4c59ea1d54b6023a36458192ff0ce058cdbfc6",
Expand All @@ -8923,7 +8972,60 @@
"mergedBy": null,
"mergeCommit": null,
"comments": [],
"reviews": []
"reviews": [
{
"id": "PRR_kwDODoD6yc45xcGD",
"commit": {
"abbreviatedOid": "f18171b"
},
"author": "nibanks",
"authorAssociation": "MEMBER",
"state": "COMMENTED",
"body": "I have strong reservations here. I think we should definitely callout the problems, but at least for now, not suggest any solutions. The more I think about this, I believe we should solve this in the QUIC protocol.\r\n\r\nI recommend we define an extension that does the following:\r\n\r\nThe server includes a new transport parameter `initial_token` that contains the value of the initial token that clients should use for any subsequent initial packets they send. If the client understands this extension/TP, it acts accordingly. If it does not, then it may hit the issues you describe in this PR and eventually time out.",
"createdAt": "2022-05-11T12:29:17Z",
"updatedAt": "2022-05-11T12:39:51Z",
"comments": [
{
"originalPosition": 87,
"body": "I do not think we should do this. This is encouraging exceeding the amplification limit.",
"createdAt": "2022-05-11T12:29:17Z",
"updatedAt": "2022-05-11T12:39:51Z"
},
{
"originalPosition": 66,
"body": "I don't care for this for two reasons:\r\n\r\n1. It requires Retry Offloads to parse the entire UDP datagram (or at least more of it). This could be leveraged to attack the Retry Offload itself.\r\n2. It requires the Retry Offloads to modify the contents of the datagram in these cases. This text stats the UDP payload length should be updated accordingly, but it doesn't go into any details about what you actually put at the end of the datagram (after the valid packets). And again, this requirement can be leveraged to attack the Retry Offload.",
"createdAt": "2022-05-11T12:35:15Z",
"updatedAt": "2022-05-11T12:39:51Z"
}
]
},
{
"id": "PRR_kwDODoD6yc46jViE",
"commit": {
"abbreviatedOid": "f18171b"
},
"author": "martinduke",
"authorAssociation": "CONTRIBUTOR",
"state": "COMMENTED",
"body": "Aside from the qualitative issues of requiring client participation in this mechanism, the transport parameter doesn't arrive early enough in the handshake to address any of these problems.",
"createdAt": "2022-05-23T21:01:41Z",
"updatedAt": "2022-05-23T21:15:23Z",
"comments": [
{
"originalPosition": 66,
"body": "1. The limited amount of parsing seems quite inexpensive to me.\r\n\r\n2. You're not putting anything at the end of the datagram, you're just deleting Initial and 0-RTT. Invalid hanshake packets can be immediately discarded at the server, so there are no costs to letting them through. Meanwhile, if this is the second flight the server will do fine if Initial doesn't get through.",
"createdAt": "2022-05-23T21:01:41Z",
"updatedAt": "2022-05-23T21:15:09Z"
},
{
"originalPosition": 87,
"body": "A CONNECTION_CLOSE is small and IMO doesn't violate the spirit of the 3x limit, but I can instead add some language that the server has to save some space under the limit to send this.",
"createdAt": "2022-05-23T21:07:54Z",
"updatedAt": "2022-05-23T21:15:09Z"
}
]
}
]
}
]
}

0 comments on commit 3102c0c

Please sign in to comment.