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

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

See below...

> On Jun 9, 2023, at 12:59 PM, Tom Herbert <tom=[e-mail]> wrote:
> 
> On Fri, Jun 9, 2023 at 10:56 AM [e-mail]
> <[e-mail]> wrote:
>> 
>> ….

(Regarding number of unknown SAFE options)

>> 
>> If that's the case, then this creates a
>> potential DOS attack similar to the one for NOPs where an attacker
>> could fill a packet with a bunch of SAFE options that it knows are
>> going to be unknown to the user. Again, RFC8504 provide guidance that
>> might be applicable for this:
>> 
>> 
>> I disagree; we can ignore unknown SAFE options forever, and should.
>> 
>> 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 limits
>>  for destination options and hop-by-hop options may be separately
>>  configurable.  If a packet is received and the number of destination
>>  or hop-by-hop options exceeds the limit, then the packet SHOULD be
>>  silently discarded."
>> 
>> 
>> Again, I disagree. We might say that “a large number of unknown SAFE options MAY be treated similarly to a large number of NOPs, i.e., to be logged and MAY be silently discarded if a DOS attack is inferred from additional information, e.g., the frequency or number of such options, but they MUST NOT be discarded as a matter of course without such additional context.
> 
> Okay, if you don't like the established precedent,

RFC8502 is a BCP that attempts to undermine RFC8200, which is a standard, but does not “update” RFC8200. Until that update happens, RFC8200 requires that unknown destination options be ignored. IPv6 has bits in the option type that indicate what to do when the option isn’t supported - we do not, except that (in the IPv6 option type sense) SAFE options are equivalent to having option type of “00” (skip the option and continue processing) and UNSAFE are equivalent to having option type of “01” (discard the packet silently).

RFC8200 does NOT indicate that packets can be discarded simply because of a large number of unknown options. I AGREE with that precedent here.

> then by all means
> please articulate exactly how an alternative mechanism works. If your
> mechanism entails counting the frequency of every option,

Only for NOP, because there is no reason for a source to deliberately send more than 7 NOPs in a row repeatedly.

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.

I do NOT endorse inferring DOS from behavior that is unexpected.

Endpoints are always allowed to limit resources allocated to capabilities that consume them excessively. That can be mentioned in the security considerations if necessary, but at what point? THere’s no technical reason for using more than 7 NOPs, but no such limit exists for unknown SAFE options.

>> Receivers supporting UDP options MUST silently drop all UDP
>>  options in a datagram containing an UNSAFE option when any UNSAFE
>>  option it contains is unknown. See Section 10 for further discussion
>>  of UNSAFE options.
>> 
>> If there are multiple UNSAFE options in a packet, how does this work?
>> Does this require that the receiver scans the packet searching for any
>> unknown UNSAFE option before starting to process options?
>> 
>> 
>> It doesn’t have to scan in advance, it just has to drop the packet when it encounters an unknown UNSAFE option.
>> 
> 
> Please clarify that in the text, the effect in this case is equivalent
> to dropping a packet.

See section 10:
   >> Receivers supporting UDP options MUST silently drop the UDP user
   data of the reassembled datagram if any fragment or the entire
   datagram includes an UNSAFE option whose UKind is not supported.
   Note that this still results in the receipt of a zero-length UDP
   datagram.
> What is the required behavior for a receiver that receives an UNSAFE
> option not in the context of fragmentation?

I’ll update the statement above as follows:
   >> Receivers supporting UDP options MUST silently drop the UDP user
   data of the reassembled datagram if any fragment or the entire
   datagram includes an UNSAFE option whose UKind is not supported or if an UNSAFE option appears outside the context of a fragment or reassembled fragments.
   Note that this still results in the receipt of a zero-length UDP
   datagram.

--