This also leaves all of these MASQUE proxies open for abuse as well to receive amplified attack traffic from poorly behaving UDP based applications. I’m not sure how you will address these given the limitations here. Additionally there’s a lot of a activity in this space at present which impacts operators, but the protocols are not well suited to address. A number of UDP based applications will generate persistent long-term data back to the originating MASQUE server. Without disclosing more about what happens in public, there’s some interesting challenges here in mitigating that issue. - Jared > On Jun 13, 2022, at 10:45 AM, Meadows, Catherine CIV USN NRL (5543) Washington DC (USA) <catherine.meadows=40nrl.navy.mil@xxxxxxxxxxxxxx> wrote: > > Hi David: > > Here is a stab at rewriting that paragraph: > > One possible misuse of unauthenticated tunneling is the exploitation of the proxy for a denial of service attack via data flooding through the proxy. We find CONNECT and UPD proxies behave similarly in this case. In the case of CONNECT, the proxy will only send data as long as it gets TCP SYN-ACKs from the target. Once the target is flooded, it will stop responding, and so the proxy will stop sending. UPD does not acknowledge receipt, but in that case the protocol running over UDP would respond, and produce a similar scenario to that of CONNECT. > > However, after writing it I found I had another question. Since UDP is designed to support broadcasting, wouldn’t we expect in many cases that the protocol running on top of it would also be a broadcast protocol? > In that case it would be unlikely to send an acknowledgment. > > Cathy > > > From: David Schinazi <dschinazi.ietf@xxxxxxxxx> > Date: Thursday, June 9, 2022 at 9:38 PM > To: Catherine Meadows <catherine.meadows@xxxxxxxxxxxx> > Cc: "secdir@xxxxxxxx" <secdir@xxxxxxxx>, "draft-ietf-masque-connect-udp.all@xxxxxxxx" <draft-ietf-masque-connect-udp.all@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>, MASQUE <masque@xxxxxxxx> > Subject: Re: Secdir last call review of draft-ietf-masque-connect-udp-13 > > Hi Catherine, > Responses inline. > David > > On Thu, Jun 9, 2022 at 6:16 PM Meadows, Catherine CIV USN NRL (5543) Washington DC (USA) <catherine.meadows@xxxxxxxxxxxx> wrote: > Thanks David! > > I’m fine with the resolution of Issue 1. > > Great, thanks for confirming! > > For Issue 2, I’m still a little confused when I look at the paragraph about DoS. The new first sentence helps, but I’m afraid some of these things are things I didn’t mention in my review, but only noticed when I took a closer look now. > > However, in practice > denial of service attacks target open TCP ports so the TCP SYN-ACK does not > offer much protection in real scenarios. > > Why doesn’t it offer much protection? > > With a CONNECT proxy, you can't DoS a closed port because the proxy will send a few SYNs but never data because the target won't reply with a SYN-ACK. But no one attacks closed ports in practice, they attack open ports that do reply with a SYN-ACK, so it is possible to send those data. So the SYN-ACK doesn't prevent real attacks. > > Is it for the same reason as the reason the UDP proxy waiting for a response doesn’t work, because the protocol running over UDP would respond? > > That's right, if you target an open UDP port with a real packet (a valid DNS query or a valid QUIC initial or DTLS client hello etc) that part will reply with its protocol's corresponding response. > > And how could the protocol respond if it is running over UDP and the UDP port is flooded? > > Once the port is flooded to the point that it doesn't reply, it is already too late - the attack has succeeded. > > It sounds like we can improve this text to make it clearer, do you have thoughts on how best to do that? > > > Cathy > > > > > > > > > > > > > > From: David Schinazi <dschinazi.ietf@xxxxxxxxx> > Date: Tuesday, June 7, 2022 at 10:20 PM > To: Catherine Meadows <catherine.meadows@xxxxxxxxxxxx> > Cc: "secdir@xxxxxxxx" <secdir@xxxxxxxx>, "draft-ietf-masque-connect-udp.all@xxxxxxxx" <draft-ietf-masque-connect-udp.all@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>, MASQUE <masque@xxxxxxxx> > Subject: Re: Secdir last call review of draft-ietf-masque-connect-udp-13 > > Hi Catherine, > > Thank you for your review. I agree with both your points. In response, I've created the following PR: > https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/pull/177 > More responses inline. > > Thanks, > David > > On Tue, Jun 7, 2022 at 4:01 PM Catherine Meadows via Datatracker <noreply@xxxxxxxx> wrote: > 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. > > I went digging through the git history and mailing list archives and couldn't come > up with a good reason for why I added this paragraph. Also I can't tell what it's > supposed to accomplish when I read it with today's eyes. So I removed it. > > 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. > > I've added the following sentence at the start of the paragraph to explain why: > << > UDP proxies have similar properties to TCP proxies when it comes to facilitating > denial of service attacks, even though TCP offers better protection in theory. > >> > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
