Draft: draft-ietf-masque-connect-udp

Commentary: 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 do n'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 would n'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 do n'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 
 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 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
Because the CONNECT method creates a TCP connection to the target,
the target has to indicate its willingness to accept TCP connections
by responding with a TCP SYN-ACK before the proxy can send it
application data.  UDP doesn't have this property, so a UDP proxy
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.
Because the CONNECT method creates a TCP connection to the target,
the target has to indicate its willingness to accept TCP connections
by responding with a TCP SYN-ACK before the proxy can send it
application data.  UDP doesn't have this property, so a UDP proxy
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.
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.