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

Tom Herbert <tom@herbertland.com> Sun, 05 January 2020 20:13 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 81C09120058 for <tsvwg@ietfa.amsl.com>; Sun, 5 Jan 2020 12:13:26 -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 7ymvFPveBQOB for <tsvwg@ietfa.amsl.com>; Sun, 5 Jan 2020 12:13:24 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4978D12004F for <tsvwg@ietf.org>; Sun, 5 Jan 2020 12:13:24 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id f8so2311932edv.2 for <tsvwg@ietf.org>; Sun, 05 Jan 2020 12:13:24 -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=pvM1rxOmJv30C0HPE5uwpgVCMXfeIZgvBOXdQkK2Y0c=; b=mbFDUiOLpFcYzsJGXLDuxgfRg1P6s7G6wAluz4LriMIjTTMFGEgFZj0Dt2/2bPIYee iMeG09w3F7Gz/6K8FCvE/j22Jd/102ooM3h1CO2fYxPRUseth5TlpqNwDuKyb1Vtr39f 7zX60873Tk3vI4F6AVm07D4VQYL8BKtQ+CEligWHggzwe6QpqQQIp4FHnWNUTDaY4sej 564pbikicQ2nYtDO9jflBobusVMA1vm9dEl7AEi7oveMBWWyxP9S2DyYs+pYR3HgVpMx 48jEAaFuoTmLHYL3nPNJdCy6uOFdtV4r51VJvF75HPHiLp3Ko3nnvYLRSNylCusr//5A RYEA==
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=pvM1rxOmJv30C0HPE5uwpgVCMXfeIZgvBOXdQkK2Y0c=; b=QqFcwc+st3tezX3hyicLtqZGTggQvxt9hZCVcr/cpctbRZKWSce7YxZga3P1XbM6i3 EX5YFcaoDFDzigG/L4sZhZbT8eBrqkwaSfCa+CbHVpmuYY+Nr9bzRzun+L0M0mEA2TXS 6dyEoHSNyBcQw+Z5Z7NR+lZ2+p2ZYsA0H+Ob3Jf3UURY6k9n6gtj80esl1MEl/B5p30Y ld6oWJl0+ET1uVeXFay9XArmScyKK6D9HhfBA5g2RX50B8Odtf90pYIUux4jESI8SQ93 1bl4c6HHRu4nd60xUoUGMiFrX51W37Z2OmOFFONBI3bfsUlLnZyDZfdTSCaxAqvCbgSg c1OQ==
X-Gm-Message-State: APjAAAXX+UTtkDoDPpYo+AVD/BGvH3I9JrN0/bCHct1otU/vLcy2h5+t CqVWfrlGUtYoH1mPAl1hS9GI/sFaTxCecnEUhEs5zw==
X-Google-Smtp-Source: APXvYqz5ecmkSXrkqX5KEZDllx7Ow60yU0bQ/DiYv/WmaUihgKzziKWvkUYAiBlDne8+6Wt3NSlEbcE5hLQV6nJfjuk=
X-Received: by 2002:a17:906:2e53:: with SMTP id r19mr104266927eji.306.1578255202630; Sun, 05 Jan 2020 12:13:22 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S37oZK8urwN-TCpZxs9F_+QXzobT8-rObPH112NkqSpUVQ@mail.gmail.com> <418EE20D-387B-48C1-BC08-614D28D7849E@strayalpha.com>
In-Reply-To: <418EE20D-387B-48C1-BC08-614D28D7849E@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 05 Jan 2020 12:13:11 -0800
Message-ID: <CALx6S372xi1rTiAw6ZmLAU-yN6RvF7PEcg6sNqS=WcNVvYMTZw@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: "C. M. Heard" <heard@pobox.com>, 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/Hpfk5AitpAaIGHXKRDMWP5Wtdx0>
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 20:13:27 -0000

On Sun, Jan 5, 2020 at 11:21 AM Joe Touch <touch@strayalpha.com> wrote:
>
> Malformed packets are dropped as with TCP and the base UDP spec.
>
And packet with unknown options that cannot be ignored need be dropped
(IPv6 HBH and destination options for instance). Such a packet is
equivalent to a malformed packet since these packet cannot be
correctly processed by the receiver.

In any case, send a malformed UDP options to an options aware receiver
then the packet is dropped, send the same packet to a legacy receiver
then a zero length packet is received. There is no consistency there,
and neither does that conform to the requirement in normative language
that you just proposed

Tom



> And original UDP design goal here refers to the original requirements for this update.
>
> Finally, consistency with legacy receivers as a default is critical until explicitly negotiated at the app later otherwise. Because until then a sender doesn’t know what receiver it’s dealing with.
>
> Joe
>
> > On Jan 5, 2020, at 11:15 AM, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Jan 5, 2020 at 8:25 AM Joe Touch <touch@strayalpha.com> wrote:
> >>
> >> Just to dive a little into the TCP example, additionally:
> >>
> >> On Jan 4, 2020, at 7:10 PM, C. M. Heard <heard@pobox.com> wrote:
> >>
> >> Since you brought it up, let's compare and contrast the operation of TCP-AO and TCP-MD5 with that of UDP-AE, in the case that an endpoint erroneously (due, e.g., to a misconfiguration) attempts to initiates an exchange containing the option with a peer that does not understand it.
> >>
> >> For TCP-AO or TCP-MD5, the listener will receive a SYN segment with the option. Since it does not understand the option, it will return a SYN-ACK that does not contain the option.
> >>
> >>
> >> The presence of unknown TCP options **NEVER** causes a SYN to be ignored, discarded, or to generate a RST. It is simply ignored.
> >>
> >> It is the result of *state exchange* that enables the endpoints to know when to use - or not use - those options. It is the responsibility of the sender to know what options to use; the receiver is ALWAYS ALLOWED TO INGORE OPTIONS that it hasn’t confirmed by state exchange - even after a connection is established.
> >>
> >> E.g., even if the side opening the connection, sending the SYN+AO were to ignore the reply (SYN-ACK without AO, never RST), let’s look at what happens to the connection afterwards. Let’s say the side opening the connection decides to include AO anyway. The receiver WOULD CONTINUE TO IGNORE OPTIONS IT DOESN’T UNDERSTAND.
> >>
> >> See RFC1122, Sec 4.2.2.5.
> >>
> >> Your subsequent claim is incorrect, as per the citations below:
> >>> Seeing a SYN-ACK without the option, the initiator will return a RST segment.
> >>
> >> RFC2385 for TCP-MD5, Sec 2.0:
> >>
> >>   Unlike other TCP extensions (e.g., the Window Scale option
> >>   [RFC1323]), the absence of the option in the SYN,ACK segment must not
> >>   cause the sender to disable its sending of signatures.  This
> >>   negotiation is typically done to prevent some TCP implementations
> >>   from misbehaving upon receiving options in non-SYN segments.  This is
> >>   not a problem for this option, since the SYN,ACK sent during
> >>   connection negotiation will not be signed and will thus be ignored.
> >>   The connection will never be made, and non-SYN segments with options
> >>   will never be sent.  More importantly, the sending of signatures must
> >>   be under the complete control of the application, not at the mercy of
> >>   the remote host not understanding the option.
> >>
> >>
> >> RFC5925 for TCP-AO, Sec 11:
> >>
> >>   TCP-AO does not include a fast decline capability, e.g., where a SYN-
> >>   ACK is received without an expected TCP-AO and the connection is
> >>   quickly reset or aborted.
> >>
> >>
> >> —
> >>
> >> For UDP, the original design goal was to follow this behavior, i.e., that the receiver always ignores options it doesn’t understand individually.
> >
> > Since when was options considered in the design of UDP? I'm looking at
> > RFC768 and see nothing about this.
> >
> >> That’s largely because options overall can be ignored - there’s no way to “unring the bell”. Even if we bury options or user data inside the FRAG+LITE, the *ONLY* correct behavior is to have the receiver see a zero-length UDP packet arrival.
> >>
> >> There is NO way to prevent that for legacy receivers - and thus there should be no way to do otherwise for option-aware receivers. The best we should ever try to do is to make option-aware receivers see what legacy receivers see in that case (unknown options) - a blank packet.
> >
> > Joe,
> >
> > As discussed before, the fact that a legacy receiver can receive a
> > blank packet is potentially problematic. We cannot eliminate the
> > possibility that zero length UDP packets don't have some detrimental
> > side effect by some receiving application. We're accepting that the
> > risk of this is small, but this behavior is far from optimal and if
> > there were a way to ensure that legacy receivers dropped packets with
> > UDP options we'd do that. Forcing option-aware receivers to have this
> > same sub-optimal behavior just to be consistent with legacy receivers
> > makes no sense.
> >>
> >> So regardless of any rules, we MUST NOT try to declare any rule where the receiver “sees NO packet”.
> >>
> > Your draft doesn't meet this requirement. e.g. "Option lengths MUST
> > NOT exceed the IP length of the packet. If this occurs, the packet
> > MUST be treated as malformed and dropped".
> >
> > Tom
> >
> >> Joe
> >>
>