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

Tom Herbert <> Fri, 09 June 2023 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFAEAC151B3F for <>; Fri, 9 Jun 2023 08:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H4sWaYicTsBh for <>; Fri, 9 Jun 2023 08:24:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::233]) (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 (Postfix) with ESMTPS id E1353C151B21 for <>; Fri, 9 Jun 2023 08:24:28 -0700 (PDT)
Received: by with SMTP id 5614622812f47-392116b8f31so675609b6e.2 for <>; Fri, 09 Jun 2023 08:24:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1686324267; x=1688916267; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Xlr3ncsmlBzbpg8kW3Im97w8RIY67z08ZOxQba+rvgI=; b=R3biigrcnOcynCX2jne6deXISZmKgWy6XUEgpJ2UFrQmooaeZQA4TW4qt4DndqO37I RJ4bMoydWB1nxv+PbsEgzR1nmjEa7zDSRsXkmMl1eoBGNN8xZwPkg38oKmsespHwL3CJ SrxdbDY236i6fDWGgSY/eGSUxAj0qbNMVrmXtvkdnxtXkoubNSsIZz9vOGafkYrOkX2f ix6h3BT2D6WhTIFddqjzarOgIDAqRiTP/OQiIQwhe6sVDqjEtQdomqduyRAcJxk0FOF1 paQokYg5Ad89Wr1l1FA2g5/99Zv0mg5weYJ7D3GSU+85NoGHyXi9QB6MS2quxYI7RuMv m4bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686324267; x=1688916267; h=content-transfer-encoding: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=Xlr3ncsmlBzbpg8kW3Im97w8RIY67z08ZOxQba+rvgI=; b=gI/ZenbJiwJ1LvZFTYm1W6FrOA+zZHoIHGhQcwyZ9fE35IswUoNy/UH/Ocf+mJTIhb zR2nQd2EAIEfpyMr065Dls/SjmSnIdZkiCcwi2S815HQv0Wn5LAGIWJW3xpCFSbWHFw8 9vaLf4FLZ6BlyI6HEGuEmb3il/uySgOdbEWOnJzEytq64Nlt7+VxAA/pW+DvZDclRvz5 0k+6Jh3+YUgeW9b54VqbrXIicTj6/0G0XkYTPMZ3Aa1Bu/bKupql9JQr0NyKzzJ9DSMO 1nbzn94HQQEvjo5og5AGsbuV5Ka5/iCTeVZ61J7AE3y74zpsKeh1N+VCO/NyxslLW3xZ IJlg==
X-Gm-Message-State: AC+VfDzN/nksJveDguIXBZJYCtV/Wv2k0QJ4xdpM/R+EUJmoIKZgOgJJ gjOI80/r+OdKQ5PZUmWaCk3S6hFn8EvhUeBfOUuOyCK7Oyg9C+j28nVgrQ==
X-Google-Smtp-Source: ACHHUZ7umPU628WcLlX2U/je0ToPcXTD0YPwFGWp3KV1crEguK3nzZWPnA7k9Pwmg+w/+tPynYA84O9lP5P4GSrs+O0=
X-Received: by 2002:a05:6808:1452:b0:39c:785a:9751 with SMTP id x18-20020a056808145200b0039c785a9751mr2327107oiv.32.1686324267343; Fri, 09 Jun 2023 08:24:27 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Fri, 09 Jun 2023 08:24:15 -0700
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-21.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Jun 2023 15:24:33 -0000

>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

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?


On Thu, Jun 8, 2023 at 9:04 PM <> 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:
> There is also an htmlized version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by rsync at