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

[Tom Herbert <[e-mail]>]

On Fri, Jun 9, 2023 at 10:56 AM [e-mail]
<[e-mail]> wrote:
>
> 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.

Okay, if you don't like the established precedent, then by all means
please articulate exactly how an alternative mechanism works. If your
mechanism entails counting the frequency of every option, periodically
running the counters through an ML algorithm, and then setting up
filters to identify bad packets based on their specific options; then
I guarantee your mechanism will never be deployed. And if the DOS
mitigations for UDP Options are insufficient and there is an issue in
the field, the user, or worse their network operator, isn't going to
call IETF up to work on a solution, they're much more likely to simply
disable UDP Options completely by just dropping all packets where UDP
length doesn't equal IP length-- if that happens the side effect will
be to relegate UDP Options protocol to an academic footnote. This
scenario isn't hypothetical, we know about this from experience
dealing with deployed protocols that allow unlimited options; that's
why we need RFC8504 and others like 6man-eh-limits which address the
issues, are feasible to implement even in hardware, and limits are
always optional to set.

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

What is the required behavior for a receiver that receives an UNSAFE
option not in the context of fragmentation?



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