Original text:
classification step. Note that the use of a connection ID to support connection migration <del> renders 5-tuple based filtering insufficient, and requires more state to be maintained by DDoS defense systems, and linkability resistance in connection ID update mechanisms means that a connection ID aware DDoS defense system must have the same information about flows as the load balancer. However, it is questionable if connection migrations needs to be supported in a DDOS attack.  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  However, a defense system might simply rely on the fast resumption mechanism provided by QUIC. </del>  4.5.

Reviewer comments:
This PR describes how a stateful DDoS system may link flows after a NAT rebinding event. Also, the PR adds a section on how to police QUIC packets to minimize disruption to application that are able to failover to TCP. Namely, avoid blocking a random fraction of UDP packets and, instead, focus on either blocking all packets from a subset of users or none at all. This is related to areas discussed in .
There's no mention of the QUIC Retry mechanism here. At the very least, for long header packets, a cooperating DDoS protection device can maintain a white-list of peer IP addresses, and only let through those addresses that successfully go through the Retry scenario. The question then is what to do with short header packets. The backend server will not have any connection state for any junk short header packets, so the server should either quickly discard the packet silently or send a stateless reset if it happens to look like a valid QUIC packet. Assuming the short header packet traffic is enough to overwhelm the server, then this PR's text would come into play. Though it'd be interesting to see some perf numbers on what kind of CPU cost there is to just reject these packets. From my previous tests with the QUIC server running in the Windows kernel, the network was the limiting factor in these type of attacks, not the CPU. So if the network is the bottleneck, does it really matter if you drop it at the server or just in front of it?
NAME I think this section could be expanded a lot more, and Retry mechanism with a cooperating DDoS protection device definitely has a place. I am happy to give it a try in a different PR, or I can leave it to you, since you've likely thought more about this topic. The cooperation should include an agreement on the format of the Token to: For a Retry tokens generated by DDoS protection device, decode originaldestinationconnectionid. DDoS protection device to understand and validate server's token provided by a NEWTOKEN frame DDoS protection device to understand and validate server's Retry tokens As for the CPU cost, this consideration only comes into play, if the attack was allowed to reach backend servers. Volumetric DDoS can saturate network links and/or be targeting networking infrastructure and not just backend servers. As NAME is saying in , volumetric attacks are often mitigated further away from the edge of the network. This kind of mitigation is the focus of UDP Policing section.
Looks like URL is an excellent discussion of Retry mechanics. It definitely deserves a reference from this doc. The Retry mechanisms described in LB draft are all cooperating boxes, and servers are aware of them. Unfortunately, Retry system protects only server's memory state and some CPU cycles spent on crypto. (Servers still need to decrypt CID to decide it is invalid, and if the attacker is clever enough to establish one valid connection and use that CID in a flood, the server will also be decrypting packets.) Retry does nothing to protect network resources. This PR is about transparent boxes that try to mitigate volumetric attacks.
As noted in discussion on .
Quoting:
PR
This is not how it works. A few examples: URL URL
I'm not sure I see support for "this is not how it works" in your examples: SYN cookies on their own are a 1990s technique for end-system DoS prevention, which, while useful at transport-terminating front ends as part of a larger DoS prevention strategy, aren't really usable on their own at scale. The paper you link to here (from ICWET, and itself a decade old) primarily deals with the separation of good from bad flows at layer 7, not necessarily how the front-end handles these flows once classified. But you're definitely right that this is not only how it works: the DoS mitigation landscape is wide and varied (even if at the end of the day the only strategy we have found to work at scale is "eat the DoS". That said, this text could be improved: it discounts detection and classification mechanisms other than based on flow designators derived from passive measurement, does not mention protocols other than IPFIX and the flow model that comes along with it when classifying traffic, etc. The text should also be more applicable to UDP reflection DoS, which is a primary concern in wire image differentiation in QUIC (and which also isn't otherwise addressed in the document or in this issue). Adding a path-observable SYN cookie equivalent to QUIC, while useful, seems difficult to achieve given the working group's history of consensus about path-observable wire image features, so other classification mechanisms are what we'll be left with.
Exactly my point. The passive measurements are generally only useful to prevent the collateral damage to the network infrastructure of an ISP or a datacenter network under an attack. While the infrastructure impact of QUIC is itself an intriguing research topic, DDoS affects not only transit networks but also the endpoints in ways that could not be prevented with any passive flow classification.
The intent of this section is to cover DoS mitigation on the "downstream" segment, all the way from transit to endpoint, with access and front-end networks in between; the further you get from the endpoint the harder classification is, but the larger the impact of filtering operations. AIUI transit networks generally only get involved at the BGP level (i.e., when an affected destination prefix is temporarily announced via a mitigation/filtering network to route traffic for scrubbing), but we shouldn't look at just the endpoint/frontend, either, This document probably shouldn't go all the way down the DoS prevention architecture rabbithole (note to self: check to see whether DOTS has something we can refer to here). But I'll put some effort into making this more general.
This is more of an "e.g." than "i.e.", but fine. I must say this is also a place where the infrastructure could be affected by the HTTP protocol upgrade. E.g. if the risk model assumes large transport layer floods, then the optical links towards the scrubbing center should be upgraded to carry ~22x more traffic.
actually, no; improve section 4.4 as well.
Err. "Current practices in detection and mitigation of Distributed Denial of Service (DDoS) attacks generally involves classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic" No. It generally does not. There are active and passive countermeasures, there are SYN cookies, truncated DNS responses, captchas, etc. The draft is still missing all of those.
I think what is still missing is to note that this document is generally scoped to in-network manageability and therefore does not discuss measures that can be applied directly at the end hosts. Maybe we can clarify this by add one simple word like this: s/Current practices in detection and mitigation/Current in-network practices in detection and mitigation/ ?
No, this is still not fair. Active countermeasures like SYN proxying still belong to the network. Probably the only way to do this properly would be to say that "Current practices in passive detection and mitigation" do whatever they do, and to add later in the section that there are also practices in active mitigation which are not supported by the protocol (the last paragraph basically sums it up) when the endpoint is not cooperating. It'd be also a good idea to highlight the impact of the lack of active mitigation features, and to hint to how the endpoint could cooperate.

Revised text:
classification step. Note that the use of a connection ID to support connection migration  <ins> renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT rebinding, DDoS defense systems can detect a change in client's endpoint address by linking flows based on the first 8 bytes of the server's connection IDs, provided the server is using at least 8- bytes-long connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID and necessitate that connection ID aware DDoS defense system must have the same information about connection IDs as the load balancer. It is questionable if connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. 4.4.1. UDP is the most prevalent DDoS vector, since it is easy for compromised non-admin applications to send a flood of large UDP packets (while with TCP the attacker gets throttled by the congestion controller).  Networks should be prepared for UDP flood attacks that masquerade as QUIC traffic. If attack classification fails, a possible response is to police UDP traffic on the network, allocating a fixed portion of the network capacity to UDP.  Blindly blocking a significant fraction of QUIC packets will allow many QUIC handshakes to complete, preventing a TCP failover, but the connections will suffer a severe packet loss.  As long as all QUIC-capable applications can failover to TCP (at least applications using well-known UDP ports), the recommended way to drop QUIC packets is to either drop them all or to police them based on the hash of the UDP datagram's source and destination addresses, blocking a portion of the hash space that corresponds to the fraction of UDP traffic one wishes to drop. </ins> 4.5.