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

Joseph Touch <> Thu, 26 November 2020 00:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 558183A0794; Wed, 25 Nov 2020 16:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 t2ZSX7YehFzl; Wed, 25 Nov 2020 16:14:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30BBB3A0779; Wed, 25 Nov 2020 16:14:25 -0800 (PST)
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=e3SmCBaPSaIntT0dRkoc7AJ6r+dIbKIRFi89on2Z8kw=; b=3pVYCkLL6VnETBQWvy95sw0h8 RV9NfWd0G0hgCY2FlgfPOhsLlOuvA1ZuZUJQ7ajbH4p+jabcs8g2SawLB5WM2/9Mrm16x6xSRZ+Mc 4VOscvZyu8Bbk56+rdLJSzOuMstv6g1xYW+sP2bJ3QvJy/WhZveGNob5TMGQcfIX3yNA9lSvtghYY unUeCMQCdAJhO7hIQJsMsQWGGfSVzVkjQmyzdK8la7aPDJYWHDfZaK8QbFpYIrXG89zOALHpOFEtF H4PD21H+3ta7qIQRK0D0SPljxkL/6OGrK20/+fI+PAJg7tlZCQrf0iM54e92WNF66aVeAd/xeLYer bwvKprKlA==;
Received: from ([]:50093 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1ki4vS-00223P-Fv; Wed, 25 Nov 2020 19:14:23 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_1E165586-E65F-4BE5-A6D3-427BFD5F917B"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Wed, 25 Nov 2020 16:14:17 -0800
Message-Id: <>
References: <>
To: tsvwg IETF list <>
X-Mailer: Apple Mail (2.3654.
X-OutGoing-Spam-Status: No, score=-1.0
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-09.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Nov 2020 00:14:28 -0000

Hi, all,

This update includes the following. 

It omits the reordering of the FRAG header intended to support zero-copy until we converge on the new format. I believe that capability may still be useful, but if we prefer, it can be omitted.

Many thanks to Gorry and Tom Jones for their detailed feedback, which has been incorporated or addressed by the changes as well.


UDP option notes

Fixed numerous typos, including the section numbering issue
New UNSAFE option for sender indication of options that it expects to be implemented:
If UNSAFE is encountered and not supported, it halts option processing and causes it to fail, so no further options are processed
The packet is passed to the app layer with all options processed up to that point indicated, including the UNSAFE one that triggered the condition
Core options are never UNSAFE because they’re always implemented
OCS can say “if I fail, stop option processing here and deliver the core”, but that’s not the same as UNSAFE
Actually, only OCS should stop in its tracks based on the value competed; everything else should just log what happens
Any option can say “if the option itself fails somehow, then drop/ignore” but that should default to ACCEPT (except for OCS, which defaults to drop)
I.e., UNSAFE is only relevant to whether an option is known, not what happens if it fails
Revised FRAG (integrates previous FRAG and LITE)
Unknown UNSAFE options before FRAG cause FRAG to be ignored  (but others don’t, so you CAN OCS or AUTH components before reassembly) **as a side effect of UNSAFE **
When FRAG fails, the packet processing continues, as with any other failed but supported options (i.e., options after FRAG still happen and the data - if any - would be delivered, or a zero-length packet)
If FRAG is first, it supports RDMA-like avoidance of user data copy (as before), but not if it is not first (which should only happen with UNSAFE options, which means data needs to be copied anyway)
In general, however, options are:
Ignored individually if not supported
Flagged as failing if supported but computes incorrect checksum, etc.
The RECEIVER decides what to drop
The default is NOT to drop (legacy behavior) but CAN be overridden
all options to be ignored if any one FAILS due to format / parsing or OCS failure
BUT NO options can prevent UDP data from going to the app by default
Apps that care can override that default
Options that should “share fate” with UDP data must be designed as UNSAFE options
There are NO currently defined UNSAFE options, FWIW
Fixed OCS description to include the surplus length pseudo header 
Also removed the claim that this would zero-out in ones complement (with surplus length, it does not)
Reiterated that the “coordination” of alignment is intended to emulate computation as if aligned to the UDP header
Clarify that failed ACS is NOT silently dropped by default
Recovers can override if desired
Default behavior works like legacy
Packet would still carry a flag allowing app to drop if desired too
Clarified that ACS and AE cover the UDP payload
Clarified that AE, like ACS, should silent drop unless configured otherwise
RFC6081 Teredo defines use when UDPlen >> IPlen-IPhdr
This is confusing; it implies Teredo processing ignores the IP length and uses UDP as an override
It won’t traverse non-Teredo routers (an errata might be appropriate?)
It is inconsistent with our approach (and so noted)
This doc now updates ROHC 3095 too
puts it in line with more recent header compression standards that we caught
UDP header compression should ever have assumed that UDP Length is implicit based on IP length

> On Nov 25, 2020, at 4:09 PM, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
>        Title           : Transport Options for UDP
>        Author          : Joe Touch
> 	Filename        : draft-ietf-tsvwg-udp-options-09.txt
> 	Pages           : 36
> 	Date            : 2020-11-25
> 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 draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at: