Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-20

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79A12C151717 for <>; Thu, 8 Jun 2023 20:58:27 -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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 L88bkUenMjWS for <>; Thu, 8 Jun 2023 20:58: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 7A24CC151711 for <>; Thu, 8 Jun 2023 20:58: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=/tD62MKzDFedCH28C5OhuPXT0q1dvTsk1tOIH+Fn/JI=; b=lTzHglJ+yCRMHvcrlN5TqgtxzI VdozITQmVpiS8BftqKmHYZnCWzRLU6G1t6TOeON6ItqYG6MKCu9MDWYkwMYxK4N+X3f9H7DNcfkFm 2VmHNszyLpj2/xEDEuntQStLhJfQpR9ZO43qUOaRxZgoauVJgzvOf5zhu2MTXzcCyisVEplshaQyn G+gFiDtN2RYMQD2X1mY45afEZTDlDaNJALVcn5zKdF+4lROE+q4C3mXRB64tKCTeSWUzlBFc7ntec 8z5DkpxhqoffNmwExUS70EzfXn27tIE5OlrsfhbUmqAccyfjqocy9ItwODlw7JiukiAp2HQcB3eAi FbEJM2Cw==;
Received: from [] (port=55803 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <>) id 1q7TGS-00GJWj-1n; Thu, 08 Jun 2023 23:58:21 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_116915D5-28DD-483C-9D7E-44D778B23A82"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: "" <>
In-Reply-To: <>
Date: Thu, 08 Jun 2023 20:58:02 -0700
Cc: "" <>
Message-Id: <>
References: <>
To: Gorry Fairhurst <>
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] Comments on draft-ietf-tsvwg-udp-options-20
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 03:58:27 -0000

Hi, Gorry,

Thanks for the detailed comments. All are included, with notes/discussion as below.

An update should appear shortly.


Dr. Joe Touch, temporal epistemologist

> On May 22, 2023, at 6:21 AM, Gorry Fairhurst <> wrote:
> I have just read version 20, and I have some questions as a working group member. I hope this helps,
> Gorry
> P.S. I plan to also re-read and send comments specifically on the security mechanisms in a week or so.
> ----
> 1. The text in Figure 1, uses "ToS", this ought to be updated in line with the terminology in RFC2474, and refer to this as the DS field.
> 2. In Figure 4 legend:
> "here using one zero for alignment"
> I think it would be clear to say this is a byte, rather than just the value:
> "here using one zero byte for alignment"
> 3. "UNSAFE options are used only in with",
> - I think this should be more like:
> "UNSAFE options are used only with"
> 3. "ignored but passing the UDP payload to the user when not supported"
> - Would it be easier for reading, if there was a comma before the "but'?
> 4. "Except for NOP, EXP, and UEXP, each option SHOULD NOT occur more
>    than once in a single UDP datagram."
> - what happens if, in the future, other options or replacements are actually defined? It seems hard to know whether there will ever be an updates.
> Could this instead be written as more like:
> "Extensions SHOULD NOT occur more than once in a single UDP datagram,
> the only specified extensions are NOP, EXP, and UEXP."

The next sentence is key, though - options can occur more than once, but for all except these three, additionally copies are ignored. This is important because it prevents ambiguity; any option that really needs more than one ‘instance' should do so within a single option codepoint.

> 5. "Impossible lengths
>    should indicate a malformed surplus area and all options silently
>    discarded."
> - Why ought this not be "SHOULD", and can we also modify the word order?
> Could this be written as:
> "An impossible length SHOULD be treated as an indication of a malformed surplus area and all options ought to be silently discarded.

I changed the last part to SHOULD silently be discarded.

> 6. " >> When the UDP options do not consume the entire surplus area, the
>    last non-NOP option MUST be EOL."
> - What is the required receiver behaviour when this is observed?

It’s stated a few sentences later - the idea is that we prefer this:

	opt1 opt2 … optN EOL zero zero zero

To this:

	opt1 opt2 … optN NOP NOP NOP NOP

Or this:
	opt1 opt2 … optN NOP NOP NOP EOL

I.e., don’t use pads to end-fill; simply use an EOL as quickly as possible and zero fill after.

> 7. ">> NOPs SHOULD NOT be used as padding before the EOL option. As a
>    one byte option, it need not be otherwise aligned."
> - Does this really matter for interoperation at the receiver?

No; it’s a SHOULD so option processing can stop as quickly as possible

> - I can see the argument that NOPs ought not to be used, but does this really need a keyword for receiver interoperability, or is this just good advice?

Yes - “Ought” is why it’s a SHOULD, not a MUST.

> 8. "on receipt but MUST be"
> - Please add a comma before "but".
> 9. " >> UDP packets SHOULD NOT use more than seven consecutive NOPs,
>    i.e., to support alignment up to 8-byte boundaries. UDP packets
>    SHOULD NOT use NOPs at the end of the options area as a substitute
>    for EOL followed by zero-fill. "
> - What is the required receiver behaviour if consecutive NOPs are observed?

This was added because of a perceived potential for DOS via lots of NOPs.

I added text that persistent use SHOULD be logged as a potential DOS indicator.

> 10. " MUST be receive the"
> - Please omit "be".
> 11. "Start pointer can indicate the start of the
>       original surplus area anywhere in the reassembled data."
> - Insert "The" ?
> 12. "Values should "increase" (allowing for rollover) according to a
>       typical 'tick' time"
> - explain rollover in terms of the modulo the field size?
> 13. " or intend optionally for
>    modification of any UDP options, including their new areas, in
>    transit."
> - I was unaware of what was intended here, perhaps this could be clearer?

Yes, reworded.

> 14. " UDP options are transport options. Generally, transport headers,
>    options, and data re not intended"
> - Please add "a" to make this "are not intended.."
> 15. "Although option nicknames are not used in-band, new UNSAFE safe
>    option values SHOULD commence with the letter "U" and avoid that
>    letter as commencing safe options."
> - Query: Please clarify: Is this intended as a capital "U", a small "u", or both cases?

Reworded; start with U, avoid both U and u in other names.

> 16. " Future options MUST NOT be defined as having a value
>    dependent on the contents of the surplus area."
> - This troubles me, because it seeks to limit evolution in the future,
> albeit for good reason. I'm not saying we should expect this type of change, but then I don't
> also know that somebody might propose something that is useful in future.
> - I wondered if it is wiser to say that we don't expect options
> to define this, and any case that does, then has to explain how it will
> co-exist with existing deployments, etc.

This becomes a problem because it would allow an option that isn’t an option. IMO, anyone wanting to use that space needs to have a codepoint assigned and use it to indicate the meaning of that field.

I don’t think that’s constraining; IMO, that’s just ensuring everyone plays by the same rules in that area of the packet.

I’ve added explanation to that effect.

> 17. "reassembly of that UDP packet must be abandoned
>    and all the fragments that have been received for that UDP packet
>    must be discarded, and no ICMP error messages should be sent."
> I this doesn't explain why this is required or recommended for the receiver,
> what happens when the assembly doesn't complete and the data is truncated.

That’s a timeout - as stated later. Partial reassembly MUST NOT be forwarded to the user - as stated even later.

> - why not require this with MUST?

Good point. This is just about when fragments overlap.

> - I also don't yet see why this ought not to be "ICMP error messages SHOULD NOT be sent", since I think that can have implications on end-to-end operation.

It’s only for fragment overlap. That should only happen due to DOS or incorrect implementation. We don’t want a DOS in one direction to cause an ICMP storm In the other. I’ll note that.

>> So should we define a new ICMP code for non-overlapping cases? It could be new code 2 for type 11 defined as UDP reassembly time exceeded, ir we could define a new type for this and other UDP errors.

> 18. ">> UDP options that rely on soft-state exchange MUST allow for
>    message reordering and loss."
> - This is a normative requirement currently, but I do not understand why this is a requirement, it is surely a reality that designs need to accommodate. For instance, RFC 8085 said "Therefore,
>    UDP-based applications need to be robust to reordering and delay.”

It’s better restated non-normatively.