Draft: draft-ietf-quic-manageability

Commentary: and 
 Comment from from PR on UDP Policing about this phrase : " The extra words do n'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 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 . " 
 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 : 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 do n'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 . 
 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 to operator policers over time . 
 I agree with  and  . 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 ) do n't really have a document that covers that aspect of things today and I do n'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 .
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.