Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-21.txt

[Tom Herbert <[e-mail]>]

On Fri, Jun 9, 2023 at 3:58 PM [e-mail]
<[e-mail]> wrote:
>
> Cutting to the chase…
>
> > On Jun 9, 2023, at 3:24 PM, Tom Herbert <[e-mail]> wrote:
> >> ...
> >>
>
> *
> >> There ARE good reasons a source might send more than N (for any N) SAFE options that a receiver might not support - and to do so repeatedly.
> >
> > Really? From the draft:
> >
> >>> Each option SHOULD NOT occur more than once in a single UDP
> >   datagram, the only exceptions being NOP, EXP, and UEXP. If an option
> >   other than these occurs more than once, a receiver MUST interpret
> >   only the first instance of that option and MUST ignore all others.
>
> The same option multiple times is NOT the same thing as many different options (the latter is what I refer to at the “*”)
>
> > So if an option is received more than once is ignored, how is that
> > possibly useful?
>
> It isn’t, but it isn’t necessarily an attack either.

Then what is it? An implementation bug on the sender? Either way,
these cause the receiver to consume power and burn resources without
beneficial effect. Receive one of these in a packet then it's in the
noise, receive a bunch of packets with 300 of these in each packet
then by any logic that's a Denial of Service Attack.

>
> > Also note that the MUST requirement here forces the
> > receiver to track the occurrence of each option and check if it has
> > been seen then that is more processing for the CPU that exacerbates
> > the DOS attack.
>
> We’re talking about different things:
>
> 1. Seeing many DIFFERENT unknown SAFE options is not an attack
>         there’s no good reason to treat it as such
>         if any socket consumes too much resources FOR ANY REASON, a host can always throttle resources to that socket
>         but that’s outside the scope of this doc
>
> 2. Seeing multiple copies of the same option
>         again, there are only a few cases where this should ever happen
>         but seeing one option twice or even three times is a mistake - not necessarily an attack
>
> Yes, the MUST here requires a check at the receiver - to ignore subsequent occurrences. NOT to treat it as an attack.
> NOP is the only one we include that way.  We can add “any time you see more than 7 NOPs or repeated other options is a problem, if the problem is persistent, then start doing something new like dropping packets”.
>
> But I think we’re engineering a protocol specification here, not an anti-DOS mechanism. I think we should the latter to implementers.

Every standard track protocol requires security considerations, and
DDOS is a security issue. Also note, that the protocol is CREATING the
DOS vector, so it's incumbent on the creators to provide solutions for
mitigating that.

>
> >>
> >> I do NOT endorse inferring DOS from behavior that is unexpected.
> >
> > Unlimited options are a known attack vector and this issue has been
> > addressed in other protocols. IMO, the mitigations described in this
> > draft are not sufficient and there's no reason to believe that UDP
> > Options is less susceptible to DOS attack than other protocols. I have
> > raised this issue several times.
> >
> > @working group chairs, please note my objection to UDP Options moving
> > forward because of insufficient considerations for Denial of Service
> > attacks
>
> It was raised largely in terms of NOPs before; now you’re raising it for all options.
>
> UDP has no strict limit on how many valid options can be used. That’s a feature, not a bug.
> Implementers can decide for themselves, for each connection, how much they want to support.
>
> But what we DO know is that finite limits WILL be exceeded for good reasons, then we’ll end up arguing how we can’t do anything because vendors locked in implementations with limits.
>
> This is a USER protocol. Let the USER decide.

Let the USER decide WHAT? The draft doesn't provide any useful
guidance that gives the user alternatives with tradeoffs. If the user
is experiencing a DOS attack because of UDP options, what does the
draft recommend they do? As I said, if you don't provide guidance, the
knee-jerk reaction is going to be to completely disable UDP Options
completely which ultimately threatens UDP Option from ever becoming
widely deployed. This is why RFC8504 style limits are useful; they are
not mandatory, the USER can decide which limits to set and what
values. The RFC recommends default values that MAY be used IF the USER
defines limits-- so the user gets to decide how to deal with DOS or
not. Note that RFC doesn't undermine RFC8200, to the contrary it is
attempting to SAVE it (at least HBH and Destination Options) by giving
an option to reasonably limit TLVs instead of dropping them
completely.

>
> Joe
>
>