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

["[e-mail]" <[e-mail]>]

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.

> 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.

>> 
>> 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.

Joe