Re: [secdir] Secdir last call review of draft-ietf-masque-connect-udp-13

[David Schinazi <[e-mail]>]

Hi Catherine,
Responses inline.
David

On Thu, Jun 9, 2022 at 6:16 PM Meadows, Catherine CIV USN NRL (5543)
Washington DC (USA) <[e-mail]> 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 <[e-mail]>
> *Date: *Tuesday, June 7, 2022 at 10:20 PM
> *To: *Catherine Meadows <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, MASQUE <[e-mail]>
> *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 <
> [e-mail]> 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.
>
> >>
>