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

Tom Herbert <> Sat, 10 June 2023 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C298EC1522BE for <>; Sat, 10 Jun 2023 12:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 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_BLOCKED=0.001, 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 Qml5c0-92Lem for <>; Sat, 10 Jun 2023 12:12:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42e]) (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 16A88C14CF05 for <>; Sat, 10 Jun 2023 12:12:31 -0700 (PDT)
Received: by with SMTP id d2e1a72fcca58-6537d2a8c20so2466808b3a.2 for <>; Sat, 10 Jun 2023 12:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1686424351; x=1689016351; 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=PFRMEgSJLTTh1ZZd7O9KQfLtelL3OYCIGJ0JhJsMDdo=; b=J+TnB00g1X7pgI40p7RQsrKLj+SkuK946hvSoi+Z6b7+eQkY3G16rZ3dLsIXP+GRw2 2uuc0H5HcYyej8TkUGZYIj+qCMCFmRv+W+LebGVrKyBdCjqOZqv2tGqK92s+H+P3CZhw cPrXuaXFx/FQU+IJ9DLnquU70HCEBimPdcnUh21LmDC1YAM61fBDj98bsKF4zE3Ju24y 5xlM0OrCtkllEvN+WkkZULeYRuwuFgBp7gqkeXLhcG8ucFXL9/muUTcUL1hbeC5x9YEA PXW7L3cVTnfBeDwfAvgCG087T/gXiC0B87+xcbBZPjWO2tElcPXWyOa0+T9nHxsWJ45t JNzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686424351; x=1689016351; 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=PFRMEgSJLTTh1ZZd7O9KQfLtelL3OYCIGJ0JhJsMDdo=; b=MJVf3xj4H+a4n/jMY7egfrFRO5Yx77NZbzK9cxw0yJgymhDyXFVDFXKrZBa4o0N4w6 5a+OA7Yj+b01NRGYKmDoGU4x+gxa2eKlNn1thN1FhvNs6Z7/fRgpKqH8H98ErJacJ754 Cd2rkBvMdfE+du3ec7XAQFe8fM4Orj/K8Gdf1wjL2ULu5Km+Cu+7w7+pmBFq7sNWXLth alXJZ0JyQOiqvtw1pOcsw9dIIsyUrwuZHVJssMfeIZKz2146bv88VkJhl2BKY1V5fNST 7tIoJngPA+QjKRFPt5pQIPdBG60hJws0q6kdQYPFQ3Gh29Gu1LkrgQ16s/Bqqd5N0lRO /p/g==
X-Gm-Message-State: AC+VfDxU3guJDrZNSOw74XL2P3koO3fZQ0WDE45Mu8kRtbvaWlKKzEaV 10/Rc0zvCOq1gGBZjAefq9PuPoilB4O06qtdh+gMgwXCrzBJwvP2U+mv9Q==
X-Google-Smtp-Source: ACHHUZ70A5GJZ8Iq8OCLyUnPhQWjV/Zrd9nzZKoTUHYrM+pI/AR3GUVy/m+aN2mbCMTVymd4AVq/l4fS+AuRRRFSZVs=
X-Received: by 2002:a05:6a20:9683:b0:114:f112:d8f0 with SMTP id hp3-20020a056a20968300b00114f112d8f0mr4482101pzc.35.1686424351190; Sat, 10 Jun 2023 12:12:31 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Sat, 10 Jun 2023 12:12:19 -0700
Message-ID: <>
To: "" <>
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: Sat, 10 Jun 2023 19:12:41 -0000

On Sat, Jun 10, 2023 at 11:29 AM
<> wrote:
> ….
> > On Jun 10, 2023, at 10:41 AM, Tom Herbert <> wrote:
> >
> > On Sat, Jun 10, 2023 at 10:10 AM
> > <> wrote:
> >>
> >>
> >> On Jun 10, 2023, at 8:40 AM, Tom Herbert <> wrote:
> >>
> >> On Fri, Jun 9, 2023 at 8:30 PM
> >> <> wrote:
> >> ...
> >> By expecting implementations that do more to allow more, the current wording both avoids that lock-in and allows more modest implementations - e.g., that don’t have resources to enable 100 options - to not need to support packets with 100 options.
> >
> > If different implementations are allowed to choose different protocol
> > parameters then that reduces interoperability;
> This isn’t a protocol parameter. Many protocols have different expectations for how widely each option is supported - see TCP, e.g.
> >> ...
> >> Adapted to the implementation. It does not talk about adaptive algorithms.
> >>
> >> As above, this just indicates that lesser implementations can allow less, but full-featured ones need to accommodate more.
> >>
> >> for a new protocol that hasn't yet seen any
> >> deployment. So much simpler to just set a limit. So we can assume the
> >> default limit will be locked in globally, and once systems are
> >> deployed changing those limits takes years as legacy systems are
> >> replaced.
> >>
> >>
> >> How’s that working out for IPv6? (It doesn’t - once you set the bar low, that’s it).
> >
> > You're asking the wrong question.The right question is "how did
> > defining unlimited options work out for out for IPv6?”.
> The right question is “how is treating every unexpected behavior as an attack working out”?
> And it isn’t.

Yes, but that's the network providers that do that. If you ignore
that, then the protocol faces a long road to be ever deployed. As I
already mentioned, if someone sees a problem with UDP Options and
calls up their provider, the network provider's response is most
likely to start dropping packets with UDP surplus. Creating a filter
on their edge devices to do that is trivial, debugging and trying to
fix the problem isn't. This is the biggest risk UDP Options faces for
real work deployment, so there really needs to be good answers to
potential problems in the protocol specification.

> Further, IPv6 options involve intermediate nodes that need to invest resources. UDP options do not.
> (Which is why limited HBH options is appropriate, but limiting destination options is not).

Because host processing is free? I assure you it's not. TLV processing
is a very expensive operation rather done in hardware or software,
both in complexity as well as power consumption. Sending options or
receiving options that are mostly ignored is a blatant waste of energy
even if it's not a DOS attack. If you don't believe me, take your UDP
Options implementation, send the receiving host packet with long lists
of options and measure CPU utilization to see what happens...

This discussion makes me wonder if it's time for IETF to require an
"Energy Considerations" section in RFCs! Power consumption for
processing a protocol is a first class issue now, even if it's not a
DOS attack.

> > Conversely,
> > one could ask "how did limited options work out for TCP?"
> Well, then not so well:
Good luck getting consensus on that!

> See draft-ietf-tcpm-tcp-edo and the numerous attempts to extend an option space that isn’t sufficient now, but at the time “40 bytes” was a specific limitation.

Yes, I've looked at draft-ietf-tcpm-tcp-edo. It's basically
undeployable since it breaks common TCP hardware offloads.

> See also MP-TCP and numerous methods to try to treat other portions of TCP segments as option space as well.
> Joe