Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

Tom Herbert <tom@herbertland.com> Fri, 12 July 2019 19:11 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 553D9120960 for <tsvwg@ietfa.amsl.com>; Fri, 12 Jul 2019 12:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Level:
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 isRCYgpIQxZU for <tsvwg@ietfa.amsl.com>; Fri, 12 Jul 2019 12:11:04 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 52A0B120935 for <tsvwg@ietf.org>; Fri, 12 Jul 2019 12:11:04 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id r12so10086661edo.5 for <tsvwg@ietf.org>; Fri, 12 Jul 2019 12:11:04 -0700 (PDT)
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=eClb6mmBrEty+4tEFoxotA6Proj7SaeqnRUmT0OH+38=; b=JVLkejmXgGmWHJ2xWyyDNxrfycU04vSk++gtJ42Vcp39WpLBxcPEwh2jcH9waBdixQ RKOHDf98oPHP488sVg2ylLUKpo46LqahXivIOLLkbrxWOsbvDQGmpE9a3wuJmbJNgL/v X9zBr0ievpm2Kd0r8KYfcVz6T/YABpmRIqyUN8F+B0ZSgF1CbG5DjMhUxqsf62LwWORC e10rf/E9ISwmjva5nriJ/D11JdRB8v1JyhwHISQ6uQ0QkWRNQ0bZhleHPezl1TrW5grd /d9uD+Ueynj+/P42F/mvWVJeiKYg7GhdnYmLz4TR6RzhJKYZv0jQGsghEyuGDK+lDQyO ScoQ==
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=eClb6mmBrEty+4tEFoxotA6Proj7SaeqnRUmT0OH+38=; b=cRPvPWfWRaGuUPaoXw1FgZiYvV8MwMVyleEKsgH5+ykc7YSB4PgHgjdlpvvu+Ps2rq q131JGK4NxheNGn/Q1t8KWxxssmrljCQVq6sEt42FDNcFwFwy1wX9o8BsROdtIY35XCr TrN9pIy6lxakMBNIrHe6htThotRfX2igA0jr/VV0x5PlX7hhrAE39KW7ZoOn0aXgYN+Y 0zk6nw4Jv62PV+w9c7cL5JY9rKmQLt2H7l+ou5BGQ9EINYJVL6i0Ztn9b23XQkBgTm7f edEm71uuUdkkV/VLw6wHJDL5xlzgDQURqG63n1r2sk8XK49rQ1IuJzvg1GLxFdtuzUF6 2D9Q==
X-Gm-Message-State: APjAAAV6LSoKb/uXcpcHmlZBLWILbSeVMNyb58hS/cZfCChVNrvrbRUi qTqUngTjgnKUVlDNMPbDmAgx8FpR0Dsjn00P0FU=
X-Google-Smtp-Source: APXvYqwC780nAfQ7eBR2Ta/uTsmK6uVJxe9GSA2/uFi2TMPOKyTZvvPr86ExA5rg3agGKoi9mUbXLQewHL2MaGmvmbE=
X-Received: by 2002:a50:b87c:: with SMTP id k57mr10797075ede.226.1562958662426; Fri, 12 Jul 2019 12:11:02 -0700 (PDT)
MIME-Version: 1.0
References: <156262970360.865.13042807682366763561.idtracker@ietfa.amsl.com> <CAPDqMeoMqsB8=tH5TBaq5Tw-sLW3HNc8tpfUU3htV=sWo7pJcA@mail.gmail.com> <D7E52D2B-3912-4897-80C6-0150CDE10218@strayalpha.com> <CAPDqMep9MYqjFvvJSVbqYwo-xJ1pUocYszNukveaZODhf9+75A@mail.gmail.com> <e73919f08202937bf45418cbf8bcc38c@strayalpha.com> <CAPDqMeoh3n5fL1k6Fw9D8rCpy4a9eWyUZvgStyzYfFuJbuWudw@mail.gmail.com> <3f6f54e0b828e2628af964d6ee7f33e1@strayalpha.com> <CALx6S37rt7OJtH5a2ZH23R21ATETuwTeFS-mZQECtgxPQ3nSZA@mail.gmail.com> <ccc386aa429bfe301998f39eb7fccfbf@strayalpha.com> <140f11c854e0ad96c51639f830cbb688@strayalpha.com> <CALx6S35MC_fj+fL6Ax9a-9=-QX0-mHLmMQ7cUs2Rir+AvYE=zA@mail.gmail.com> <5b35e91dd510119672a0836f868ade24@strayalpha.com> <CALx6S36AVbKfvb-6dj07rcGjsVsCz0daFM9qZOBSSstZOM-Ukg@mail.gmail.com> <8A584FFF-6C86-4154-8D9D-CF407CA77145@strayalpha.com> <CAPDqMeq9GjEQKukH1pZOTdE50e_rc3U6gpdxT-5qrS5phD0RGw@mail.gmail.com> <646D45AD-D79B-4BD2-A084-7DA97CE2C415@strayalpha.com> <7EC37B50-45D5-4CF1-B113-205E55BF244E@strayalpha.com> <CALx6S34s7L7xo+26bt5Cdaqi4Es5Aci42GHk1WNKzugr5st-Gw@mail.gmail.com> <B525BF50-EFCC-44A5-A604-6CDDA914A1CB@strayalpha.com> <CAPDqMep3R6z9PRKkHyOvrh6sV9n5Sc0B++-zVz0FYJCwE6swrQ@mail.gmail.com> <E42A2AE2-F499-465E-BDE6-5EFC0AB20042@strayalpha.com> <CE03DB3D7B45C245BCA0D24327794936306138E9@MX307CL04.corp.emc.com> <f9f1701c2196c5db520d025294202353@strayalpha.com> <CE03DB3D7B45C245BCA0D24327794936306153C4@MX307CL04.corp.emc.com> <CALx6S37U5Q9qkxDFfR6w9MpN4qvRagThb+p0GqnAS118cKDuZw@mail.gmail.com> <CE03DB3D7B45C245BCA0D2432779493630615838@MX307CL04.corp.emc.com> <CALx6S36SL2X5StJ59zyKKwNafS1WXh0HMDqbYs+OaDdMLoNTmg@mail.gmail.com> <33045f76897978c01208266c831318c2@strayalpha.com> <CALx6S34BmOefkEMKHLasmUoiWx6P+5yUG_v=Cdzdtw_H1cD7KQ@mail.gmail.com> <88dbe43611a5d7bc487ef76cfab3b26b@strayalpha.com> <CALx6S364Hmf5YUf2cF0xXkkyU3iqddEf6M4PTjyfewPbct5AYQ@mail.gmail.com> <25493093-480C-46C0-A91D-45DCCFB9D77F@strayalpha.com>
In-Reply-To: <25493093-480C-46C0-A91D-45DCCFB9D77F@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 12 Jul 2019 12:10:48 -0700
Message-ID: <CALx6S34tiBMNpM-yBXGzTznP_J=OpYNas+HtpAX4+BKJc5=CVQ@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: "Black, David" <David.Black@dell.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/1fWRZrY4cRgbJHdXRWpye9-cr7M>
Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
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, 12 Jul 2019 19:11:06 -0000

On Fri, Jul 12, 2019 at 11:12 AM Joe Touch <touch@strayalpha.com> wrote:
>
>
>
> > On Jul 12, 2019, at 11:07 AM, Tom Herbert <tom@herbertland.com> wrote:
> >
> >> On Fri, Jul 12, 2019 at 11:00 AM Joe Touch <touch@strayalpha.com> wrote:
> >>
> >>
> >>
> >>
> >>
> >> On 2019-07-12 10:44, Tom Herbert wrote:
> >>
> >> On Fri, Jul 12, 2019 at 10:19 AM Joe Touch <touch@strayalpha.com> wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 2019-07-12 09:40, Tom Herbert wrote:et the requirements (which
> >>
> >> ... UDP options proposal
> >> doesn't generally meet the requirements of RFC6936 for using UDPv6
> >> zero checksum.
> >>
> >>
> >> FRAG+LITE does, though - because it provides its own post-reassembly checksum.
> >>
> >> Unless the checksum covers the IP addresses, it doesn't meet the
> >> requirements
> >>
> >>
> >> Given NATs rewriting those addresses, what's the point?
> >>
> >>
> >> (not to mention as hard as I squint, I cannot fathom that
> >> UDP options is tunneling protocol). In any case, the requirments that
> >> UDPv6 checksum must be non-zero are baked in-- it's a done deal in the
> >> Internet. For instance, there's deployed middleboxes that will drop
> >> packets with UDP v6 zero checksum
> >>
> >>
> >>
> >>
> >> "baked in" or not, it a bug according to the requirements as of RFC6936 - and it needs to be addressed.
> >>
> >
> > What is the bug?
>
> Intermediate devices Dropping UDP packets with zero checksums.
>
They have been doing this for years and it is consistent with the
Internet standard, i.e. RFC2460 and now RFC8200 are very clear that
checksums are required for UDPv6. RFC6935 is also clear that it's the
responsibility of the tunnel protocols to deal with any
incompatibility that the use of UDPv6 zero checksums creates:

"Tunnel protocols intending to use a zero UDP checksum need to ensure
that they have defined a method for handling cases when a middlebox
prevents the path between the tunnel ingress and egress from
supporting transmission of datagrams with a zero UDP checksum.  This
is especially important as middleboxes that conform to RFC 2460 are
likely to discard datagrams with a zero UDP checksum."



>
> Ps - UDP is used for tunnels because it traverses NATs (or should) and doesn’t delay, unnecessarily reorder, or layer congestion control the way a TCP tunnel would.
>
> Joe