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

Joe Touch <touch@strayalpha.com> Fri, 03 January 2020 19:04 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 8C36B120875 for <tsvwg@ietfa.amsl.com>; Fri, 3 Jan 2020 11:04:45 -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 XcthaRaQD7wg for <tsvwg@ietfa.amsl.com>; Fri, 3 Jan 2020 11:04:44 -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 33A8C12009E for <tsvwg@ietf.org>; Fri, 3 Jan 2020 11:04:44 -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-Transfer-Encoding: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=z2u4LtEZsgGM8SM63X1i7mLOvuWWLcp4GzOsX4BqtC4=; b=5xce6YrQXIim5S9diWWFwrNe9X 6ee6ZewSFbcYStS/pbamju9CjSa+5aygaFEo21Mm7B8N5nJaSZS+pK9HV4oGtfChama/+KwIkaPpM QJCvN6untHb8BfHP6wck9E7s6zs3HHT8GtaSbvBCF71HeDqbdsaDzvW1qQK9MLlIcjQHwqIgg5x1I esMOfWoroHtrKnZbjYvrpEv4e/SfZ+cvDcwdNxKXGNiGPsD63uHrBcnqqZCstVbWoTbWiVx8HQFpY 9Zl3WTBKxogigggfqTRyiIpQWnpFBLnycfr9GCk6ElVCfRMHBe/WYvzd9Citc9OvMqRxngn2bE9D3 pTXNp+jA==;
Received: from [38.64.80.138] (port=58720 helo=[172.21.15.58]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1inSFS-001ult-TZ; Fri, 03 Jan 2020 14:04:43 -0500
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <CALx6S34+zEqFyy60NRxdGT5OpOQmcuSKxySr=+vV+rdX3UJ1=A@mail.gmail.com>
Date: Fri, 03 Jan 2020 11:04:38 -0800
Cc: TSVWG <tsvwg@ietf.org>
Message-Id: <8B9A6A87-0FA1-4F6D-AA7D-C9177D35C301@strayalpha.com>
References: <CALx6S34+zEqFyy60NRxdGT5OpOQmcuSKxySr=+vV+rdX3UJ1=A@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: iPhone Mail (17C54)
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/ygb7Ggg54PSN_hDaJuwVV-7oUQQ>
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: Fri, 03 Jan 2020 19:04:46 -0000

Tom,

How about providing text of an example of any deployed transport option that modifies content (other than encryption, which is already handled). That was asked several IETFs ago and remains unanswered.

Joe

On Jan 3, 2020, at 8:07 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Thu, Jan 2, 2020 at 8:21 PM Joe Touch <touch@strayalpha.com> wrote:
>> 
>> 
>> 
>> On Jan 2, 2020, at 7:00 PM, C. M. Heard <heard@pobox.com> wrote:
>> 
>>> On Thu, Jan 2, 2020 at 6:23 PM Joe Touch wrote:
>>> 
>>> On Jan 2, 2020, at 6:03 PM, Tom Herbert wrote:
>>>> IPv6 options
>>>> solve this problem by the "drop if unrecognized" bit so no negotiation
>>>> is ever necessary.
>>> 
>>> That is ONE way to solve things, but its hardly “solved" when nearly nobody uses it.
>>> 
>>> But it’s also not relevant here because IPv6 baked that rule in from the start. We can’t - there’s NOTHING we can do to make a legacy receiver drop packets with unknown options, regardless of the flags per se. All we can do is design them so the options and data are invisible together, which LITE+FRAG already supports.
>> 
>> 
>> Joe, I think that you are missing an important point here, namely that the "drop if unrecognized" flag (or Option Kind encoding rule) is proposed for the benefit of ***option aware*** receivers, not for the benefit of legacy receivers.
>> 
>> 
>> FRAG+LITE already provides the behavior you want. The flag option fails to provide correct behavior for unidirectional or failed soft-state receivers - both of which are non-starters. A key requirement is that legacy receivers can silently ignore all options.
> 
> Here is the necessary requirements and text:
> 
> "
> Options that cannot be ignored by a receiver due to side effects or
> other requirements MAY be sent. An option that cannot be ignored is
> indicated by the high order of the option type being set to 1 (if the
> high order bit of the option type is 0 then the option can be safely
> ignored).
> 
> If an option that cannot be ignored is received by a node that does
> not recognize the option then the packet MUST be dropped. The
> following requirements ensure this:
> 
>  - Options that cannot be ignored MUST NOT be sent in packets that do
> not use FRAG+LITE format. This prevents a legacy receiver from
> incorrectly ignoring an unknown option.
>  - If an option is received with the high order bit of the bit of the
> option type set to 1 and the receiver does not recognize the option,
> then the packet MUST be dropped. This covers the case where a receiver
> that processes UDP options however doesn't support a particular
> received option that cannot be ignored.
> "
> 
> This requirements yield a correct protocol for ALL CASES including
> unidirectional, failed soft-state receivers, multicast, NAT
> transitions, anycast, and simple unicast.
> 
> Tom
> 
>> 
>> …
>> 
>> I do agree in principle that use of FRAG+LITE (in a form that includes OCS over the entire surplus area) plus post-reassembly options addresses (a) and (b) of my message (though I still reserve the right to comment when I see the details).
>> 
>> 
>> AOK. And point taken that the soft state section needs clarification.
>> 
>> Joe
>