Change:
addresses issue
See .
ISTM that this might also be an applicability thing as the "easy" solution involves the firewall to share state with the LB/frontend (with all the scalability impact that entails).
PR add a little more text here. Please provide another PR if you think more text is needed!
PR merged Hello WG, Consider, please, the following use case in your spare time: An access network (to simplify things) doesn't host any listening ports but rather just provides access to individual users. Some of the users, or the network itself, have DDoS attacks in their threat model. To address that, the network deploys a stateful firewall on or close to its border, far away from the last mile that could get congested. The said firewall doesn't allow incoming traffic towards the user machines, except for the packets belonging to connections initiated from the inside. For the sake of simplicity, let's treat the bandwidth on the border and computational resources of the firewall to be sufficient for processing any incoming traffic. With the Internet transport protocols of 1970s, one of the possible attack scenarios would then be to generate a large number of packers per second with a 5-tuple equal to a connection already existing on the firewall. In real life scenarios, an off-path attacker already knows 4 of 5-tuple parameters and just needs to guess the source port number a client has chosen to connect. The entropy is then generally limited to just 15 bits, which is believed to be not enough for proper protection of long-living sessions given the attack bandwidth levels observed today. In theory, the attacker also needs a side channel to figure out whether or not they have guessed the port already. In practice, the attacker usually does have such a side channel. E.g. during an online gaming tournament if one of the competing players experiences a connectivity problem it almost immediately becomes obvious for anyone. However, with TCP, we have SEQ and ACK numbers, which both add greatly to the entropy of a 5-tuple. (And, yes, in reality you cannot rely on proper SEQ randomness of a network client or server, but that's another story). The issue might be UDP, but in practice either the UDP "session" is expected to be very short-lived (DNS, NTP, etc.), or the protocol is not mission critical, or the protocol exposes a stable part in the layer 7 header which could also be used for reliable connection tracking. You'll have, however, to implement specific modules for each such a protocol. (In fact, the rest of the protocols you don't know what to do with could then just go through a fixed pipe with a bandwidth rate limit much below anything that you might have at the last mile.) What I was going to ask for is an advice on how could such a threat model be addressed if a client connects to a QUIC server. My first intention was to write down connection IDs, but it turns out those may change at will. The rest of the (long, let alone short) header is fixed. (I'm also present onsite in BKK, if that's easier for someone to ask for any clarifications or explanations this way) Thanks, | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: EMAIL | fb: ximaera | telegram: ximaera | skype: ximaera | tel. no: +7 916 515 49 58

Discussion:
either through timers or through least-recently-used eviction, depending on application requirements. <ins> The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the Connection ID is present and what length it has. </ins> 4.2. Limited RTT measurement is possible by passive observation of QUIC