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

Tom Herbert <> Tue, 13 June 2023 23:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E654DC15108D for <>; Tue, 13 Jun 2023 16:00:16 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0XStAPLqpn0e for <>; Tue, 13 Jun 2023 16:00:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (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 D7563C15153F for <>; Tue, 13 Jun 2023 16:00:12 -0700 (PDT)
Received: by with SMTP id 41be03b00d2f7-54fba092ef5so770041a12.2 for <>; Tue, 13 Jun 2023 16:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1686697211; x=1689289211; 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=xEyoOb/G/Suo5IfINsboUi61f2aLqY9UhgfsO3TGZQI=; b=dFH8Pt94Zz5CofkaCGqOKKmLsQLETAwU3F1nZQfBf8TC3qqadvV83xxznRn0aF0KBD pVGzRtoZ5ynF2SjswZJU/PrrKwaz65YUvggw+t3yaZsLgIp81XfySb7mS/KXbes3KLyd CoPV5XuUUwxLpIa7EgUbFKxtRTLnPVMpmGHyKgMzNskgd65nhe8PrEbkOWIyHyHHbzkN jjN+8djDQz0ofoROgM39jIMSUh/hgyiuSIWPvpibelcg/H5Jcn+lFuueROI+uIWhmq9Y mm2ay4tRKs2b1LazUKubjcmNRuwvC4CznQw9xdjs6+8IkEIObA74a+IjDQtB+HeYgSWF TWqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686697211; x=1689289211; 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=xEyoOb/G/Suo5IfINsboUi61f2aLqY9UhgfsO3TGZQI=; b=NIcmD50T0c3eUSkf+Aktx0hh+4IQcJsZK6UoOZV1FtoUOZpWbKz9tLP85qWu+YSF+Z dXoAgMjTTWbu04/wPsSERXW4zjgbDE5g1snFmGOfqHlD8acgMnd2lDvbMW2NTxxReyym Hc7GDGNXy1/+snyCh6XhjDdClOA55QpGtBJA2thVGkWMEV9LysK3Mwd/W2JBf5gK5lRo HtwKbSDRS4Dc0eDfBwCtuTZXdEMkeIsDNgkSHgJBBDX2yhpWZipr8NlT9EjXYEHlMe60 ckwlTGMigIId3tbrfMQ5PCJcOUxbYGzN6wL4Btuk4PdhsTekOBaFgZFl1TaBYTnYnzQq buMA==
X-Gm-Message-State: AC+VfDwtPfMDtUyDhlyaurzrDgVhpPp3oC+ezx9dlGejm5Z7hnjX33jg aoWdVkCxJ2D/F6rpWJPzfWtWmLhc1f6lU1rGPM4YtWB2OD3JcvhbQ8a7ng==
X-Google-Smtp-Source: ACHHUZ71KEIxqbEC6BNE45lafygpcrFyci7CKNmzzudz2JYvaj3IYJw/+Xu0ggByWhiTqqpubrh+lgHwz3gnEFjGSog=
X-Received: by 2002:a17:90a:3d0d:b0:256:4217:b955 with SMTP id h13-20020a17090a3d0d00b002564217b955mr120391pjc.35.1686697211135; Tue, 13 Jun 2023 16:00:11 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 13 Jun 2023 15:59:59 -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-22.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: Tue, 13 Jun 2023 23:00:17 -0000

Form the draft:

"If an option other than these occurs more than once, a receiver MUST
interpret other than these occurs more than once, a receiver MUST
only the first instance of that option and MUST ignore all others."

I don't think this is a preferred behavior. Since all options after
the first are ignored, I don't see how any useful work can be done by
sending the same option to more than once. Furthermore, a sender would
KNOW that multiple instances of the same option would always be
ignored, and I don't see any other purpose for doing that than DOS
attack. Note that ignoring repeated options is not processing cost, in
this case it's actually fairly involved since we need to have a
conditional check and probably set a bitmap for every option.

I think the behavior should either be to process all the copies of the
option (repeated occurrences of the same option might be deemed useful
someday), or treat a repeated options as malformed UDP options


On Fri, Jun 9, 2023 at 8:28 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-22.txt
>    Pages           : 44
>    Date            : 2023-06-09
> 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