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

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

...

> On Jun 9, 2023, at 4:33 PM, Tom Herbert <[e-mail]> wrote:
> 
> 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.

300 in each packet, maybe. 10? 20? What’s the threshold? There isn’t one - nor should there be.

And same for “a bunch of packets”. 

So yes, like any protocol, there are ways to abuse it. We can mention that in the security section, but should NOT proscribe specific ways or thresholds that aren’t inherently part of the protocol (e.g., 40 bytes for TCP options - which even that is being extended).

> ...
> Every standard track protocol requires security considerations, and
> DDOS is a security issue.

Yes, it can and should be discussed.

> Also note, that the protocol is CREATING the
> DOS vector,

The default is already that UDP options are off unless a user turns them on.

> so it's incumbent on the creators to provide solutions for
> mitigating that.

There are known solutions - but we should NOT be indicating specific thresholds because they WILL become baked into implementations.

>> ...
>> This is a USER protocol. Let the USER decide.
> 
> Let the USER decide WHAT?

How many unknown options inside a single packet or how many such packets are an attack.

Yes, we can talk about that, but NO, we should not say 22 is bad but 21 is OK unless we have a specific reason to pick those numbers.

> This is why RFC8504 style limits are useful;

They’ve basically killed IPv6 options - without actually having the hurdle of being an actual update to the standard.

It’s not OK to tell everyone they “MAY ignore a single header option:
   A host MAY disallow unknown options in destination options or hop-by-hop options.

Doing that gives permission for everyone to stop supporting it:

It’s not OK to say:
   A host MAY impose a limit on the maximum number of non-padding
   options allowed in the destination options and hop-by-hop extension
   headers.  If this feature is supported, the maximum number SHOULD be
   configurable, and the default value SHOULD be set to 8.

The problem with that statement is it ought to have updated RFC8200 to say “IPv6 packets MUST NOT use more than 8 options”, because that’s the net effect. 

In our case, we can add:
	- A host MAY impose a limit on the max number of options in a UDP packet.

	- A host MAY also impose a separate limit on the max number of unknown options in a UDP packet

BUT:
	- A host MUST NOT impose these limits by default. Any such limits MUST be activated only after a threshold that combines the number of offending options AND significant repeated attempts to use those options in multiple packets. This document does not indicate a specific such limit.

Joe