Change:
4.7. <del> Current practices in detection and mitigation of Distributed Denial of Service (DDoS) attacks generally involve classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic, and then differential treatment of this traffic to forward only good traffic.  This operation is often done in a separate specialized mitigation environment through which all traffic is filtered; a generalized architecture for separation of concerns in mitigation is given in DOTS-ARCH. Key to successful DDoS mitigation is efficient classification of this traffic in the mitigation environment.  Limited first-packet garbage detection as in sec-garbage and stateful tracking of QUIC traffic as in sec-stateful above may be useful during classification. </del> <ins> On-path observation of the transport headers of packets can be used for various security functions.  For example, Denial of Service (DOS) and Distributed DOS (DDOS) attacks against the infrastructure or against an endpoint can be detected and mitigated by characterising anomalous traffic.  Other uses include support for security audits (e.g., verifying the compliance with ciphersuites); client and application fingerprinting for inventory; and to provide alerts for network intrusion detection and other next generation firewall functions. Current practices in detection and mitigation of DDoS attacks generally involve classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic, and then differential treatment of this traffic to forward only good traffic.  This operation is often done in a separate specialized mitigation environment through which all traffic is filtered; a generalized architecture for separation of concerns in mitigation is given in DOTS-ARCH. Efficient classification of this DDoS traffic in the mitigation environment is key to the success of this approach.  Limited first- packet garbage detection as in sec-garbage and stateful tracking of QUIC traffic as in sec-stateful above may be useful during classification. </ins> Note that the use of a connection ID to support connection migration renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT <del> rebinding, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID. It is questionable whether 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. TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS attacks.  QUIC Retry packets are the functional analogue to syncookies, forcing clients to prove possession of their IP address before committing server state. However, there are safeguards in QUIC against unsolicited injection of these packets by intermediaries who do not have consent of the end server.  See QUIC_LB for standard ways for intermediaries to send Retry packets on behalf of consenting servers. </del> <ins> rebinding, where the client's address changes without the client's intent or knowledge, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  However, QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID.  In this case, the connection ID can not be used to distinguish valid, active traffic from new attack traffic. It is also possible for endpoints to directly support security functions such as DoS classification and mitigation.  Endpoints can cooperate with an in-network device directly by e.g.  sharing information about connection IDs. Another potential method could use an on-path network device that relies on pattern inferences in the traffic and heuristics or machine learning instead of processing observed header information. However, it is questionable whether connection migrations must be supported during a DDoS attack.  However, for unintentional mitigations, as is usually the case for NAT rebindings, the connection ID can be used to track connections (see sec-flow- association).  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. Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS attacks.  QUIC Retry packets are the functional analogue to syncookies, forcing clients to prove possession of their IP address before committing server state.  However, there are safeguards in QUIC against unsolicited injection of these packets by intermediaries who do not have consent of the end server.  See QUIC_LB for standard ways for intermediaries to send Retry packets on behalf of consenting servers. </ins> 4.8.

Discussion:
thanks NAME for the text.
talks at length about detecting and mitigating against (D)DoS attacks, but this is written with the assumption of an uncooperative endpoint (likely to be, but unstated, a server). All except the Retry text where the design specifically forces interventions to be cooperative. It is entirely reasonable for DoS classification to be done with full knowledge of valid connection IDs or at least valid connection ID lengths. If you allow for cooperation, the text might then explain how this might allow established flows to be separated from spoofed flows and new connection attempts.
+1 Perhaps either approach could be reasonable depending on the specific case? - Which DoS/DDoS mitigation fits best for an enterprise/user might vary depending on many things - including the role played by the endpoint and who controls the network and devices.
Can someone propose text?
In the last paragraph, it may be worth mentioning the 3x amplification limit during the handshake as well. Post-handshake DoS/DDoS is usually an application-level property which could affect TCP as much as QUIC, so the whole 5-tuple/CID aspect seems like it could be ignored commonly post-handshake. Is there a DoS expert we could ask to look at this text to see if it made sense, since I worry none of us are that person?
NAME with TCP, the handshake could be completed by the DDoS "classification" engine without passing a bit of an information to the endpoint. That's called "SYN proxying". That was, uh, a cool feature since otherwise the endpoint would've been flooded by handshake attempts. Even though TCP wasn't cooperating, this feature was powerful enough to allow to build an impenetrable DDoS mitigation infrastructure. Please see also .
I was thinking of something a little like this (and can make a PR if this is heading in a useful direction: "On-path observation of the transport headers of packets can be used for various security functions. For example, Denial of Service (DOS) and Distributed DOS (DDOS) attacks against the infrastructure or against an endpoint can be detected and mitigated by characterising anomalous traffic. Other uses include support for security audits (e.g., verifying the compliance with ciphersuites); client and application fingerprinting for inventory; and to provide alerts for network intrusion detection and other next generation firewall functions.

When using an encrypted transport, it is possible for endpoints to directly support these security functions; another method could use an on-path network device that relies on pattern inferences in the traffic and heuristics or machine learning instead of processing observed header information." Thoughts?
I think this text still doesn't address MT's original point fully - that an endpoint could even cooperate with an on-path device directly by e.g. sharing information about connection IDs.
Yes. Would happily add that the endpoint can "cooperate with an on-path device directly by e.g. sharing information about connection IDs". Is there more?
Re: NAME comment above: SYN proxying won't work in QUIC for the obvious crypto reasons, but a related approach that dynamically starts sending Retry over a certain rate limit might be almost as good. Retries are already partially covered in section 4.7. In this regime one could also drop 0RTT packets. Is this something it'd make sense to add to this document, or in QUIC-LB instead?
I don't like where this was taken. As NAME said, it is not responsive to my comments about cooperation. It still firmly assumes that DoS mitigation is being performed without cooperation from endpoints. That might be unavoidable for good reasons, but we should be clearer about the consequences of that AND we should recommend that DoS mitigation be performed with cooperation from endpoints.