Re: [tsvwg] Rregarding soft-state and UDP options

Joe Touch <touch@strayalpha.com> Sat, 04 January 2020 04:35 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 D9843120058 for <tsvwg@ietfa.amsl.com>; Fri, 3 Jan 2020 20:35:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level:
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 lThEgrUL5v2t for <tsvwg@ietfa.amsl.com>; Fri, 3 Jan 2020 20:35:52 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 44F3E120020 for <tsvwg@ietf.org>; Fri, 3 Jan 2020 20:35:52 -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: 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=C0Zizi4i3Z8hVO/hIVC++3YFPlqetu3bHfxOkT8mouQ=; b=mIwb5K+Siw9QvgzPYcllGE01N lVCPtT2rT6vQanmpttAM1Yhw9m0ABBnHbxHxHRGGpUONM8edRf/gRzWn8/w7q1bJCUZloenJG+eTw 6vzNp77/VqiW/Aw+z81V+Io/+XQoiOMiX1H1L23VsBr+kZqy7ffodtMcJl1kqh334bx2YT6XFONNj LmijlBPXYGARZIl6FOUiB03pUTTT/J7LLX6XZJEe0e/69HYlqmjJHwPMcbELBk8+L/8WxYFvQpNFC 4+gT/d8nVmKEHp7cOv9c9BIGVO4QGeS1fzUJmMbjJVwJ0sdtrUFzLXbizp2/V2XKSL4ogxNeTIP/2 AxJwkKSew==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50394 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1inbA8-002vUc-H4; Fri, 03 Jan 2020 23:35:48 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <CALx6S34EfhcthoG4Qtr0JtfsdqQPr-2=havTvq_7nh9K8XDhJA@mail.gmail.com>
Date: Fri, 03 Jan 2020 20:35:43 -0800
Cc: TSVWG <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E21B9BD-3148-43C9-BCB8-E6F5DFCE69C3@strayalpha.com>
References: <CALx6S36227JnMkaZtPUvJoY5Pw-rQgy2R6tqt1PF_L=bgCjxCA@mail.gmail.com> <85C8C994-3FEA-4DF4-8C46-75CB205D09EA@strayalpha.com> <CALx6S34EfhcthoG4Qtr0JtfsdqQPr-2=havTvq_7nh9K8XDhJA@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
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/FPbU9fb8IUa4HjDcU2wropaCOho>
Subject: Re: [tsvwg] Rregarding soft-state and UDP options
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: Sat, 04 Jan 2020 04:35:54 -0000

Lost in this discussion has been an example to motivate the need for “drop if not supported”.

I’ve been asking for this for over a year and yet NO new existing transport examples have been cited. 

The only hypotheticals proposed are content encryption and content compression. Encryption is already supported by the AE option. TCP has a content compression option code point. It was assigned in 1999 with an experimental draft (Bellovin’s) that never made it past -00 individual.

The existing architecture already supports both these examples (i.e., that modify content) using FRAG+LITE as follows:

	- each frag (even if only one) is decrypted/decompressed as processed
	- the frags are OCS-verified after reassembly (frag completion)
	- if decompression or decryption is silently ignored (i.e., if not supported), then the reassembly OCS would fail

No example has been given of a transport protocol need for “drop if the option isn’t supported” that doesn’t modify the frag payload.

—

Right now, until there is consensus otherwise, there isn’t justification to waste half the code point space on  hypotheticals. However, there’s no reason not to assign ONE code point for such use, e.g., as follows:

	option 253 — defined as a prefix to “required options” code points, the next byte defines that code point 
	(these would be assigned as needed and have no relation to the UDP option code point values)

That way there’s support for the *remote* possibility that this feature can be useful without wasting space needlessly - and, as importantly, avoiding the impression that “flipping a bit” can change any option from “optional” to “required”.

Joe