Change:
This PR is in response to . It improves the clarity of the Security Considerations section: the paragraph about willingness to receive needed an introductory sentence the paragraph about lifetimes no longer made sense and is removed
Look fine to me, posted some suggested editoiral tweaks you can take or leave Reviewer: Catherine Meadows Review result: Has Issues This draft describes a protocol for proxying UDP in HTTP, similar to the way in which HTTP CONNECT allows proxying TCP in HTTP. The Security Considerations Section, besides noting that the considerations identified in HTTP-DGRAM also apply, notes the necessity for authentication. It also notes the security issues (particularly, vulnerability to denial of service attacks)that arise from the fact that in UDP the target of a connection doesn’t have to indicate its willingness to accept a connection before a proxy sends data. It also discusses some issues that may arise from basing a UDP proxying implementation on a pre-existing implementation of the TCP CONNECT Protocol. I found a couple of minor issues, mainly having to do with clarity: Issue 1: I am confused by the last paragraph of the section, which runs as follows: 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 Section 3.1 if they base their UDP proxying implementation on a preexisting implementation of CONNECT. First of all, it’s not clear what the security implications of this are. This needs to be explained (or put elsewhere if there are no security implications). Secondly, it’s not clear what advice in Section 3.1 is relevant to this paragraph. Section 3.1 is mostly MUSTs and SHOULDs; I don’t see anything I would call advice. The paragraph needs to say more clearly what advice it is referring to. Issue 2: It is hard to draw a conclusion from the paragraph on DoS The first two sentences are clear. They state that the fact in the CONNECT method for TCP the target must indicate its willingness to receive data, while this is not the case for UDP, potentially makes it easier for UDP proxies implement denial of service attacks. However, I had trouble understanding the rest of the paragraph: 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 UDP 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 UDP proxy. I think that what this is intended to say is that because DoS attacks target open ports there is not much difference between TCP and UDP proxies as far as vulnerability to DoS is concerned. I would recommend saying this upfront. Then it would be easier to see how the two sentences above support that statement.

Discussion:
servers that support UDP proxying ought to restrict its use to authenticated users. <ins> UDP proxies have similar properties to TCP proxies when it comes to facilitating denial of service attacks.  In theory the stateful nature of TCP provides better protection than stateless UDP but in practice this provides negligible benefits when considering proxying. </ins> 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 CONNECT proxy can send it

protocol running over UDP would respond, and that would be interpreted as willingness to accept UDP by the UDP proxy. <del> 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. </del> The security considerations described in HTTP-DGRAM also apply here. 8.