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

Tom Herbert <tom@herbertland.com> Sun, 05 January 2020 23:28 UTC

Return-Path: <tom@herbertland.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 4A5821200C5 for <tsvwg@ietfa.amsl.com>; Sun, 5 Jan 2020 15:28:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 E0Qk-Ws0EGiw for <tsvwg@ietfa.amsl.com>; Sun, 5 Jan 2020 15:28:36 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CB4120026 for <tsvwg@ietf.org>; Sun, 5 Jan 2020 15:28:35 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id e10so46078467edv.9 for <tsvwg@ietf.org>; Sun, 05 Jan 2020 15:28:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4BI/i/HRJbOSjYlLpXpuAJ1tksuj3EEjKmifzDMm8bM=; b=VOxyQJBF3ix+qBGCffM9AiX3r8acsG/RmXJugiwx9gfQKLUKhKGvJjtz65/1cDW42w QF7sSGiovphB4tgjw1e5ftHZVI1eif3BiU4c+Gwpb+wV6m78Qc3AH1qzLqh5lfKRCqlO rVNf9MJfU5ZUwMqF8i3Y6bT+Qz1ebX3D1Y0Lc+ABy3BhttU3u8jIavEplxs1sOBiHq9u tje4GKb7Mu6NmggeQwrItXRATBn3c8JIbgfdQSCrsk22xH4VYwyunsDFf24RbDGUyCUr QFn+evN9OLMJockcRY5E9g6kdcZRrAqbz/KAEiasH0iuvuc37GzeaYME8hjHAPYcTs7/ HsmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4BI/i/HRJbOSjYlLpXpuAJ1tksuj3EEjKmifzDMm8bM=; b=qwfH6L/lVU+KdB+/JItPB/ujjmFsdL308BtQBl2ZoTo5XkfFHq4n6RXLpwRE+EQ15/ ktIl6Ct5zD2i05Afax8tnDrShy2KMIHNcXAdxYdBWbg+zscoktqxuIpgsrhVd7jnzqoE pi6iZwwrjazNDycSQQ8xfQF6Ub1T7y0HX+HIGhallA1+Miw9fNTHnPG04JcQyDFNus5K G9P3DyO8s55NlktbOLZzRMhpbL6YjlhJtvqU9JVvu75+QJUvMQsW2g9bFIqlBu34CVYj 5LJzoqn8V6sn+JTS9UaW6Fw5FdGgnvzUJA5gDMIVjrwBpEELBG6G0jIlTViNzUUy9A9T Ikbg==
X-Gm-Message-State: APjAAAUDaRYEZMt5Q6yyNBEQBjQJgq4bdB9JekUUxTXEjmC/x68O4YnO SUmdgIwZWt4hdqXVbFWfbBgXLJ66FlW8KZ99aJEGkGLyrLE=
X-Google-Smtp-Source: APXvYqzOIIuYINaPbDKV6mfMqi3Cl+PSy1aLTUI0OSdJ7X2Hq8g0ljRubzdVscoOd6Cf3TwsQpZE/WJiyWZa3+POjpI=
X-Received: by 2002:aa7:da18:: with SMTP id r24mr51281206eds.111.1578266914084; Sun, 05 Jan 2020 15:28:34 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S37oZK8urwN-TCpZxs9F_+QXzobT8-rObPH112NkqSpUVQ@mail.gmail.com> <418EE20D-387B-48C1-BC08-614D28D7849E@strayalpha.com> <CALx6S372xi1rTiAw6ZmLAU-yN6RvF7PEcg6sNqS=WcNVvYMTZw@mail.gmail.com> <FEFC49BC-0D34-419D-818E-D80A85B1C74E@strayalpha.com> <CALx6S35jhAoKHttijzqQNxQL8WJfbu=fun3EivCCOmxfXcw0QA@mail.gmail.com> <49C20EDE-9AD1-4577-B097-2ED2BB7CFC19@strayalpha.com>
In-Reply-To: <49C20EDE-9AD1-4577-B097-2ED2BB7CFC19@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 05 Jan 2020 15:28:22 -0800
Message-ID: <CALx6S36Og0c73eQUW57M4ZH0BL=82CciJAmKujP=gJ3XbhcWwA@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: TSVWG <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bxx0ubIHM3K6vAWuwsHoZFmCO8w>
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: Sun, 05 Jan 2020 23:28:37 -0000

On Sun, Jan 5, 2020 at 1:57 PM Joe Touch <touch@strayalpha.com> wrote:
>
>
>
> > On Jan 5, 2020, at 1:17 PM, Tom Herbert <tom@herbertland.com> wrote:
> >
> >>
> >> You keep citing network protocols, not transport.
> >>
> > Because, just like UDP, IPv6 is a stateless, connectionless, datagram
> > protocol that works over unicast, multicast, anycast, and broadcast.
>
> IPv6 is two things UDP is or should not be:
>
> 1. a network protocol, not a transport
>         network protocols rely on ways to inform the intermediate hops
>         transports can and should rely on the endpoints
>
> 2. overbuilt
>         if we learned anything with IPv6, it’s that adding the kitchen sink helps delay adoption
>
> The lesson to follow here is TCP and TCP SYNs in particular. There is no TCP option that causes a received packet to be IGNORED (there could easily have been).
>
> > They have all the same pertinent properties. If you know of a
> > transport protocol with options having these same properties then we
> > can look at that (note, that protocol is not TCP!).
>
> It is TCP SYNs. They have to be interpreted without context.

TCP SYNs is the best you could come up with? One small part of a
protocol that typically doesn't carry user data, doesn't work with
multicast and is part of a stateful protocol 3WHS. Nope, IPv6 is the
better model.

>
> >
> >> Transport protocols don’t have this behavior - and it’s IMPOSSIBLE to implement for legacy UDP receivers.
> >>
> > It's not impossible, I've already suggested the necessary text and
> > requirements to prevent a receiver from incorrectly processing an
> > unknown options that cannot be ignored.
>
> That code never affects legacy receivers.
>
> > I claim that this protocol
> > works for all use cases of UDP in order to satisfy the requirement the
> > requirement. If you dispute this claim, then please provide the exact
> > scenario where you think it fails.
>
> First, it fails to be motivated by an example.
>
Encryption option.

> > Here again are the requirements to
> > ensure:
> >
> > "
> > 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 rest of this is not a requirement, it’s an implementation...
>
> > ...
> > If an option that cannot be ignored is received by a node that does
> > not recognize the option then the packet MUST be dropped.
>
> Fail. That causes the same packet to be silently dropped by option-aware receivers and received as zero-length by legacy receivers.

There is no such requirement. And as I pointed out if there were the
draft would need to be changed to eliminate all cases where packets
are dropped on error since that too  "causes the same packet to be
silently dropped by option-aware receivers and received as zero-length
by legacy receivers."
>
> That’s a non-starter. There is no justification for needing that behavior.
>
> > 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.
>
> This does NOT ensure that legacy receivers and option-aware function the same way. Legacy would receive zero-length packets. Option-aware should do the same.

Again, there is no requirement.

>
> >  - If an option is received with [he needed signal]
>
> (again, the rest of this sentence is implementation, not requirement)
>
> >  and the receiver does not recognize the option,
> > then the packet MUST be dropped.
>
> Same problem. Different behavior for legacy and option-aware.

Same response. Show me the requirement established by consensus of the
WG that this violates.

>
> Declaring that an option CANNOT BE IGNORED affects ONLY THAT OPTION. We can decide to make it trash all other options, but we can’t make it drop a packet as a whole.
>
The whole point of an option that cannot be ignored is that it is
incorrect to process the packet if ignored. That means that packet may
be delivered with corrupted data or other insidious side effects;
hence the packet needs to be dropped.

Tom

> Joe