Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-09.txt
Joseph Touch <touch@strayalpha.com> Thu, 26 November 2020 00:14 UTC
Return-Path: <touch@strayalpha.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558183A0794; Wed, 25 Nov 2020 16:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2ZSX7YehFzl; Wed, 25 Nov 2020 16:14:26 -0800 (PST)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=strayalpha.com; 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 cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50093 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) 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.20.0.2.21\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <160634937123.31668.16222629354118891810@ietfa.amsl.com>
Date: Wed, 25 Nov 2020 16:14:17 -0800
Cc: i-d-announce@ietf.org
Message-Id: <014545D8-D549-4FFF-AF44-64975BA5DB09@strayalpha.com>
References: <160634937123.31668.16222629354118891810@ietfa.amsl.com>
To: tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
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 - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/h3OK0IKX4Wz5boDnXmNJ979b6yM>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-09.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=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. Joe UDP option notes CHANGES 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, internet-drafts@ietf.org 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: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-09 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > >
- [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-… internet-drafts
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Carsten Bormann
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Gorry Fairhurst
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Carsten Bormann
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Carsten Bormann