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

Tom Herbert <tom@herbertland.com> Fri, 09 June 2023 22:24 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E972EC151B37 for <tsvwg@ietfa.amsl.com>; Fri, 9 Jun 2023 15:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZl0CM7bYz1A for <tsvwg@ietfa.amsl.com>; Fri, 9 Jun 2023 15:24:40 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D301C151B04 for <tsvwg@ietf.org>; Fri, 9 Jun 2023 15:24:39 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-544c0d768b9so1180878a12.0 for <tsvwg@ietf.org>; Fri, 09 Jun 2023 15:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1686349479; x=1688941479; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vuOiqpq13ro0on1W84p8MkEif9NK7CY3xgvL+20ecY8=; b=Vcy4ZXp4i7p2CjXYctjunR9lyhxbf8K1roHZmjTQLLBCZBXXPWbtR6Z+mEIeiNX81x aG9jo1GQ4C28HXOajciC2yS5h7iemYpHJGBP7Kf4Hxr/TU7I7O5sK7MrHGTvYCCiT1vi alqXFuxfFqgcQvtXC1a4i6aesztTZJ9sYBEIQFT8KlsTBriuDKLWDgb0Ap+IMFPjoak5 GHdg64OENTt5CM5DdMUbqn1ekprJCo0mLcmryEEx7biix1g5MnYJnJLZd1z7yMjaI6pW nN9RxXDrE9eywk2NF++TR1k7G6iVthUzGoe+1rs2HYb5mElvf2/9kwdIuee2D2gIZtVd yXXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686349479; x=1688941479; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vuOiqpq13ro0on1W84p8MkEif9NK7CY3xgvL+20ecY8=; b=g+ZLLs1K/rU76BCs76bjCEbMsbb8D5PiHeVMChTYsFUR9Apc/QpcjARNQBBrg0HTWs BVqy5lznVa/0s7/iVIZW9NyIFHzJBVKr/RXn/y3mv6xOjafvIPF/BwSby9764Eh4A3Oy vA3x8d3XcX5diiO61uy1IUQId4TCY9nKT4TkA/ZjKGeDTbDCBJivkIj/ROD9taFllZe3 lin5xOMSK1xUxKvf3sfVTYayRnmKH3dhMVSvsJb7MUTZ4YsaSbLHKfRy5WKNAJFUHOuc G7J4oRCPXKRRzzoC+Plxg1Yzfbsme4D7FUSwrTW+4x+oVUJvwylx5QOJ/7zHAN8k1SLt adIA==
X-Gm-Message-State: AC+VfDzrOAnip61hF5TNRg2LetX9Rs1y4K4AkIpiy+aMA/52Sb53noWL DwmiWUKiswgwI7oSFxyv+vadiK+o9coMXuCytb3/hg==
X-Google-Smtp-Source: ACHHUZ6lYtQ4xKomycISTdeP2him/OygztN9ekIhyz+ASvacr3qNLr6YVPlK+UZrlwY5Gcv5JYTMbVvbePpvO6lpwPU=
X-Received: by 2002:a17:90a:b301:b0:259:aa15:80e6 with SMTP id d1-20020a17090ab30100b00259aa1580e6mr2556830pjr.23.1686349478869; Fri, 09 Jun 2023 15:24:38 -0700 (PDT)
MIME-Version: 1.0
References: <168628341428.60924.1127559055874638238@ietfa.amsl.com> <CALx6S34DGvkdvbmNqD2-1YK=5mXDxvy8NROCUZZgSWxiFLurfQ@mail.gmail.com> <B64DA8BB-F2BE-4847-BE19-1182172F27F6@strayalpha.com> <CALx6S35AkGmRo1u4oxn55w-7dv==AUXT3EKsbMB6a2Zxerps6g@mail.gmail.com> <2D59EEAE-E56A-4C8C-A2D5-4EDF7C534A59@strayalpha.com>
In-Reply-To: <2D59EEAE-E56A-4C8C-A2D5-4EDF7C534A59@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 09 Jun 2023 15:24:26 -0700
Message-ID: <CALx6S37Cyk_SwOHm6dT_jxbtqxuA-1Kk9aN6Fs=rR5SEJMhXYg@mail.gmail.com>
To: "touch@strayalpha.com" <touch@strayalpha.com>
Cc: tsvwg@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vWjr0dOFrfBm1zT5zy3eewig8sM>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-21.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jun 2023 22:24:45 -0000

On Fri, Jun 9, 2023 at 2:42 PM touch@strayalpha.com
<touch@strayalpha.com> wrote:
>
> See below...
>
> On Jun 9, 2023, at 12:59 PM, Tom Herbert <tom=40herbertland.com@dmarc.ietf.org> wrote:
>
> On Fri, Jun 9, 2023 at 10:56 AM touch@strayalpha.com
> <touch@strayalpha.com> 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.

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.

So if an option is received more than once is ignored, how is that
possibly useful? Also note that the MUST requirement here forces the
receiver to track the occurrence of each option and check if it has
been seen then that is more processing for the CPU that exacerbates
the DOS attack.

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

Unlimited options are a known attack vector and this issue has been
addressed in other protocols. IMO, the mitigations described in this
draft are not sufficient and there's no reason to believe that UDP
Options is less susceptible to DOS attack than other protocols. I have
raised this issue several times.

@working group chairs, please note my objection to UDP Options moving
forward because of insufficient considerations for Denial of Service
attacks

Thanks

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