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

"" <> Fri, 09 June 2023 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73DD9C15DD5E for <>; Fri, 9 Jun 2023 15:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Status: No, score=-1.316 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TLRdD86oTP25 for <>; Fri, 9 Jun 2023 15:58:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9168CC15DD44 for <>; Fri, 9 Jun 2023 15:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=s4eV9tto47sHceuplijb+7cbsYi/jE0Gra13E7J5opA=; b=TtCn93atqJTPuLuZHbldcJk7Y+ ojRTwhYvUQ6Ggc40/cdwcKHLax5Im/mtji9htMNgaDAXl1KcLSvMOXLwndK1o1BfaspfxG3IRXnVs 8efykrkQmEyZKUxOokVPHrIUL2DKGJfSR+zkxoB+Lnk73PPpPvqLYdCmP0Uf9AmRiBhvzAozG59Rv EmqHtsdpCtCxoBryw858kDo7v7Y5F1BB6KUdkmrMhF7KY2cYjhGrZn3Pl622Z3vqXIWPAid5EFQX0 0rP48/ogOWU3/N+T7WO5qDaMFqvgvnUGH6g870yfyRZMrlAvxOwtU937ydyLdF1MKJe+V0Jl7t6of 2DSXDcVA==;
Received: from [] (port=11809 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <>) id 1q7l4C-001jE3-8P; Fri, 09 Jun 2023 18:58:52 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: "" <>
In-Reply-To: <>
Date: Fri, 09 Jun 2023 15:58:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Tom Herbert <>
X-Mailer: Apple Mail (2.3731.600.7)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
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 22:58:57 -0000

Cutting to the chase…

> On Jun 9, 2023, at 3:24 PM, Tom Herbert <> wrote:
>> ...

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

The same option multiple times is NOT the same thing as many different options (the latter is what I refer to at the “*”)

> So if an option is received more than once is ignored, how is that
> possibly useful?

It isn’t, but it isn’t necessarily an attack either.

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

We’re talking about different things:

1. Seeing many DIFFERENT unknown SAFE options is not an attack
	there’s no good reason to treat it as such
	if any socket consumes too much resources FOR ANY REASON, a host can always throttle resources to that socket
	but that’s outside the scope of this doc

2. Seeing multiple copies of the same option
	again, there are only a few cases where this should ever happen
	but seeing one option twice or even three times is a mistake - not necessarily an attack

Yes, the MUST here requires a check at the receiver - to ignore subsequent occurrences. NOT to treat it as an attack.
NOP is the only one we include that way.  We can add “any time you see more than 7 NOPs or repeated other options is a problem, if the problem is persistent, then start doing something new like dropping packets”.

But I think we’re engineering a protocol specification here, not an anti-DOS mechanism. I think we should the latter to implementers.

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

It was raised largely in terms of NOPs before; now you’re raising it for all options.

UDP has no strict limit on how many valid options can be used. That’s a feature, not a bug.
Implementers can decide for themselves, for each connection, how much they want to support.

But what we DO know is that finite limits WILL be exceeded for good reasons, then we’ll end up arguing how we can’t do anything because vendors locked in implementations with limits.

This is a USER protocol. Let the USER decide.