Original text:
could send more data to an unwilling target than a CONNECT proxy. However, in practice denial of service attacks target open TCP ports so the TCP SYN-ACK does not offer much protection in real scenarios.  The security considerations described in HTTP-DGRAM also apply here.

Reviewer comments:
Thx!
Should we maybe add a recommendation to the sec considerations that proxies may limited the amount of data they send as long as they don't see any reply. I guess initially you would limit to 10 packets and then following RFC8085 limit to one datagram per 3 seconds...? Not sure if that really is a good idea but I wanted to bring it up for discussion...
I thought about that when I first wrote the existing text, and I came to the conclusion that a limit here wouldn't protect against real attacks. If someone is attacking a closed UDP port, they're not accomplishing anything. If someone attacks an open UDP port (for example 443 because they want to attack someone's QUIC endpoint), then the target will reply with some sort of UDP packet (for example a QUIC RETRY) so this protection will disable itself. Does that make sense?
The challenge I see with any advice is that the proxy is not an application using UDP, it's just passing opaque data. So it will really struggle to rationalise at all about the various UDP use cases that clients have for the proxy. Perhaps rather than focus on advice, focus on how CONNECT UDP proxy considerations differ from CONNECT TCP proxies. That may well cover, at the same time, considerations like how long should a proxy hold open requests (tunnels) that don't exchange any packets in one or both directions i.e., a DoS attack on the proxy itself via a slow loris kind of mechanism
That's discussed in the Proxy Handling section, it references BEHAVE for how long sockets should be kept open
NAME would it be worth adding your reasoning (which makes sense to me) to the draft somewhere?
fair point, I'd read that and forgotten about it, maybe worth a back reference from the security considerations. For instance, HTTP/2 has some special callouts to CONNECT in its security considerations URL edit: I'm not claiming the same considerations apply here, just that server resource usage as a byproduct of proxying might be different than other request loads
That makes sense, I've written up to address these comments.
Thank you

Revised text:
could send more data to an unwilling target than a CONNECT proxy. However, in practice denial of service attacks target open TCP ports so the TCP SYN-ACK does not offer much protection in real scenarios. <ins> While a proxy could potentially limit the number of UDP packets it is willing to forward until it has observed a response from the target, that is unlikely to provide any protection against denial of service attacks because such attacks target open UDP ports where the protocol running over UDP would respond, and that would be interpreted as willingness to accept UDP by the proxy. UDP sockets for UDP proxying have a different lifetime than TCP sockets for CONNECT, therefore implementors would be well served to follow the advice in handling if they base their UDP proxying implementation on a preexisting implementation of CONNECT. </ins> The security considerations described in HTTP-DGRAM also apply here.