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

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

See below...
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jun 9, 2023, at 8:24 AM, Tom Herbert <tom=[e-mail]> wrote:
> 
>> From the draft:
> 
>>> Receivers persistently experiencing packets with more than seven
> consecutive NOPs SHOULD log such events, at least occasionally, as a
> potential DOS indicator.
> 
> Logging that a DOS attack might be happening is fine, but if the user
> is experiencing a DOS attack what is the recommended mitigation? I
> suggest text similar to RFC8504 would be applicable:
> 
> "A host MAY limit the number of consecutive PAD1 options in
> destination options or hop-by-hop options to 7.  In this case, if
> there are more than 7 consecutive PAD1 options present, the packet MAY
> be silently discarded."
> 
> where for UDP options the correct behavior is probably to stop options
> processing and ignore whatever is past the offset where the limit is
> exceeded.

Agreed, but this needs to be in the context of responding to an attack. We need to make it clear that sending 8 NOPs once doesn’t make the packet silently drop - because sending more than 7 is a SHOULD NOT, not a MUST NOT.

I’ll add text to that shortly.

> There are some other potential DOS issues.
> 
>>> Receivers supporting UDP options MUST silently ignore unknown
>   SAFE options (i.e., in the same way a legacy receiver would). That
>   includes options whose length does not indicate the specified
>   value(s), as long as the length is not inherently invalid (i.e.,
>   smaller than 2 for the default and 4 for the extended formats).
> 
> I'm not sure what this means. A legacy receiver ignores all options,
> but in this case it seems like the intent is probably to skip over
> unknown SAFE options.

SAFE are safe to skip over, UNSAFE are not. I will clarify that in the text.

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

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

“Hardened” systems might want to do such a scan, but again this is NOT an indication of an attack without additional information.

Joe

> 
> Tom
> 
> On Thu, Jun 8, 2023 at 9:04 PM <[e-mail]> wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This Internet-Draft is a work item of the Transport Area Working
>> Group (TSVWG) WG of the IETF.
>> 
>>   Title           : Transport Options for UDP
>>   Author          : Joe Touch
>>   Filename        : draft-ietf-tsvwg-udp-options-21.txt
>>   Pages           : 44
>>   Date            : 2023-06-08
>> 
>> Abstract:
>>   Transport protocols are extended through the use of transport header
>>   options. This document extends UDP by indicating the location,
>>   syntax, and semantics for UDP transport layer options.
>> 
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
>> 
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-21
>> 
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-udp-options-21
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>> 
>> 
>