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

"" <> Fri, 09 June 2023 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14E4DC151538 for <>; Fri, 9 Jun 2023 14:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.315
X-Spam-Status: No, score=-1.315 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, HTML_MESSAGE=0.001, 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 I8KzbUF6fcQP for <>; Fri, 9 Jun 2023 14:42:23 -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 245B0C151524 for <>; Fri, 9 Jun 2023 14:42:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding: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=62DQgbpxlbKn0ZnWY/9iAdcazi3eQI3ONLm0MwW7OIo=; b=DnneJFxmPxNo/vIiYMzPL2BHgh K6fO8WfljsG1LQZUq/J+J1rUP7zuZPyrKX/Oit4y51Hcn6HanAcszFhcSeWr/AxwM1RSogzcUNpbi L1Qo2m2zDdwNDI64KX5Mj3t3OJhKJGblhC9UHoVU2YpC3A1jRm5h2xIZrNtamcgt2yvszBma06eaR PS+WB1N9XnDzD58Q/Qeq+qZlQBmlC8Jc6V8WOK7bRLB83uwB5BekyVLqAgCf4DcHp2C/ufDzFLzl7 N6lWiYot812gsYF9/iwyPZY1AT1pCLkv2UXWn7HMzanljpQEEEm/yzNkt4m9LOdjtoObJVl75Is2I Hr7j8nVg==;
Received: from [] (port=58692 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <>) id 1q7js8-000ZaX-LV; Fri, 09 Jun 2023 17:42:21 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A27893D-C078-485F-8BE0-CD78F7F8FBB5"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: "" <>
In-Reply-To: <>
Date: Fri, 09 Jun 2023 14:42:04 -0700
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 21:42:27 -0000

See below...

> On Jun 9, 2023, at 12:59 PM, Tom Herbert <> wrote:
> On Fri, Jun 9, 2023 at 10:56 AM
> <> 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.

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

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