Original text:
Today, 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 <del> controller) or to craft reflection and amplification attacks. Networks should therefore be prepared for UDP flood attacks on ports used for QUIC traffic.  One possible response to this threat is to police UDP traffic on the network, allocating a fixed portion of the network capacity to UDP and blocking UDP datagram over that cap. The recommended way to police QUIC packets is to either drop them all or to throttle 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.  When the handshake is blocked, QUIC-capable applications may failover to TCP (at least applications using well-known UDP ports).  However, blocking a random fraction of QUIC packets across 4-tuples will allow many QUIC handshakes to complete, preventing a TCP failover, but the connections will suffer from severe packet loss. </del>  4.7.

Reviewer comments:
and
Comment from NAME from PR on UDP Policing about this phrase: "The extra words don't really help here. If anything, you need to highlight the need to block only a subset of addresses rather than a subset of packets."
I'd like to question whether arbitrarily applying a limit to UDP flows is a sensible recommendation over the coming years. QUIC will dominate internet traffic (I will estimate 85% or more, by bandwidth, mainly due to HTTP/3). In that end state what is the protective value of setting a ceiling on the amount of UDP? Yes it permits continuation of service for some during an unmitigated UDP DDoS, if they can switch to TCP. But in the presence of active mitigation, perhaps a limit is unwise?
This document is not at all recommending to set such a limit. It's just saying that if you really think you need that limit, here is the way to do it right. However, maybe we should be more clear that this is not a recommendation for such a limit.
Proposed some wording updates in
Comment from PR from NAME on UDP policing: "This is recommending something that relies on the 4-tuple, but particularly if there's another NAT involved, the 4-tuple may not be stable. So this puts connections in a situation where the handshake completes, they use the connection for a bit, a NAT rebind occurs, and then the connection is blackholed. There are defenses against this problem, but this seems like a fairly dangerous recommendation."
NAME said in PR on the section title "UDP Policing": "Policing has a slightly different meaning(token bucket policer) that's widely used, so can we find a different term in this context?"
Looks like will resolve this.
Yes, is supposed to resolve this. Not sure why this is not correctly linked...
is merged
You should really cite the port avoidance prior art: avoid-v4-udp-ports. bind9 implemented this in which was implemented to avoid the problems that occurred after UDP/1434 was filtered by providers in response to the SQL Slammer attacks and the long term filtering that was left in place after this. Is there a described technique or measurement to determine what ports may be problematic? Many operators have had to mitigate the damage of UDP based protocols on their networks and in attempt to limit the impact to well behaving ports and protocols deployed things in a limited scope, eg: URL URL Large and small network operators are known to block or restrict ports and protocols due to the impact. Akamai also has this implemented at our network edge in some locations today. We have seen other protocols, eg: NTP start to move from 123 123 communication eg: draft-ietf-ntp-port-randomization which will face similar issues. Is there a way to provide feedback of what ports may be limited or should be avoided? How would an operator signal or configure this?
Currently most QUIC implementations are HTTP/3 and therefore use the https port 443. However QUIC is a general purpose transport protocol and therefore future application will likely use different ports. Also ports are not really meaningful to identify applications and as such I don't think there is any good advise we could give here. Or what are you missing? Can you maybe propose text? Please also note that PR proposes a (mostly) editorial update of this section.
NAME can we close this issue?
I think this is a very interesting question, but it's a bit outside the scope of this document (as a user's manual for the wire image)...
At your own peril I guess. The question here of how this protocol will work long distance on networks that have had to deal with abusive applications is still a going concern. I'll review the changes that went in via but ignoring how other UDP based applications have had to avoid ports but doing it at a protocol level will result in poor performance for some flows. network operators deployed these only after the pain from the protocol and application users reached a tipping point where it was no longer feasible to operate a network without these protections. It's unclear to me how this transport will work reliably as more ports are likely to be added to operator policers over time.
I agree with Brian and Mirja. This is an interesting question but since there is no single port number for the QUIC transport, I find that the question verges into an applicability / deployment concern. We (the QUIC WG) don't really have a document that covers that aspect of things today and I don't think we have enough experience with QUIC deployments to write an answer to the question yet. If the market figures out that, for example, any port other that UDP 443 is slow, then that seems an ok outcome while we figure things out. There is no transport-level mechanism defined by QUIC for service discovery. QUIC requires Application Protocol Layer Negotiation (ALPN) be used when opening a connection, so listening applications can share the same port number and dynamically dispatch QUIC flows based on the selected application. The reduces some of the concerns about QUIC-based applications competing for UDP numbers.
Generally speaking, this is OK. I have a few suggestions however.

Revised text:
Today, 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  <ins> controller) or to craft reflection and amplification attacks.  Some networks therefore block UDP traffic.  With increased deployment of QUIC, there is also an increased need to allow UDP traffic on ports used for QUIC.  However, if UDP is generally enabled on these ports, UDP flood attacks may also use the same ports.  One possible response to this threat is to throttle UDP traffic on the network, allocating a fixed portion of the network capacity to UDP and blocking UDP datagrams over that cap.  As the portion of QUIC traffic compared to TCP is also expected to increase over time, using such a limit is not recommended but if done, limits might need to be adapted dynamically. Further, if UDP traffic is desired to be throttled, it is recommended to block individual QUIC flows entirely rather than dropping packets randomly.  When the handshake is blocked, QUIC-capable applications may failover to TCP However, blocking a random fraction of QUIC packets across 4-tuples will allow many QUIC handshakes to complete, preventing a TCP failover, but the connections will suffer from severe packet loss (see also sec-filtering).  Therefore UDP throttling should be realized by per-flow policing as opposed to per- packet policing.  Note that this per-flow policing should be stateless to avoid problems with stateful treatment of QUIC flows (see sec-stateful), for example blocking a portion of the space of values of a hash function over the addresses and ports in the UDP datagram.  While QUIC endpoints are often able to survive address changes, e.g. by NAT rebindings, blocking a portion of the traffic based on 5-tuple hashing increases the risk of black-holing an active connection when the address changes. </ins> 4.7.