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

[Tom Herbert <[e-mail]>]

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

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

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


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

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