Re: [tsvwg] [saag] Fwd: Last Call: <draft-ietf-tsvwg-transport-encrypt-19.txt> (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC

Tom Herbert <tom@herbertland.com> Sat, 13 February 2021 01:53 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 B42303A11D7 for <tsvwg@ietfa.amsl.com>; Fri, 12 Feb 2021 17:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 DVpMv2gb3txl for <tsvwg@ietfa.amsl.com>; Fri, 12 Feb 2021 17:53:15 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 1BBA13A1220 for <tsvwg@ietf.org>; Fri, 12 Feb 2021 17:53:14 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id q2so1915201eds.11 for <tsvwg@ietf.org>; Fri, 12 Feb 2021 17:53:14 -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; bh=SzNwPlfE+pd0+XJE5zuFp267bS8cuvdiY5V1PmK52xE=; b=iBPW7Srf1EvkzUklcpD1b/OW2vPnjUpJkEWXyM0+8Dwjc/i1MCurWeOXFjQJUsWOWZ 06QL8hMhBMxXdxCmNb4ihpG/y7qqOEb5gt8fWMs1hve8anGn8CxG6eE7flk6d1sf3a5d ulVHxuVrdfsbwgo2gw2Hf7lrE1D20Zg6zh454Z9KpY0mdzBBVLM/mi9n0Guyu7XUiuBf YhKyS5rujHi4eyiqoPQNeAtgHSogH9Hd52+Eo2ikhvNI6YOSC0IUtklvValDiWNnRl7B K8y05n5iixgunuIaLFGrsRAx+mWrlbdfiWv8MrW1arEOYXsnZRszwM8Sd6UMS3EMTxrC JwCA==
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; bh=SzNwPlfE+pd0+XJE5zuFp267bS8cuvdiY5V1PmK52xE=; b=ILnlu7ZVmfXxEX0PjOI0fOCxjSj52EAXmCbCH7W85lqcShO/1mO8gWW7eWkLkDePeJ HNEufT47a9XB6nvJON1kGPvzjgM92BPg7e1e7wAOXVE/hiqyxd1LGrkWMNTasKQklhaq eKXQZmu1ffdHiEn28bkK+7XncdmIXzESay8bILCVsB7ZNvikvwAwfwyTOmrPc/nv9XCy EWfNIHNZlYr1cWlP/SnGbIAAWC6fq6qCUmZc7Inbg/LVufgTTRaY6C0nbTUf31YvOTZC IytNleciU4VhFwWcnqs9rUHY1GAmU8TUTsZMf2hrxopviOuf+39tDpZUD4Mepgw3vbu8 Y3TA==
X-Gm-Message-State: AOAM531jJ6+IytAndSdSv0wJ3xRdzMcDrHsqEkGpa637wbl2MsbyGPNG uqgYMDLcpZubwz1JPqAGSfPKUrKv1kCoeQ7WBhJuxHwG4VM=
X-Google-Smtp-Source: ABdhPJzm2Vz/d4ooEwYMI/saC4x6UbcbNLaiNjSRK9gz8JadaB9kQP5U3PgjqgF7ZBIU0R4Cgwvo4aDlk9TvCkWX3mQ=
X-Received: by 2002:aa7:cb0d:: with SMTP id s13mr6027615edt.221.1613181193480; Fri, 12 Feb 2021 17:53:13 -0800 (PST)
MIME-Version: 1.0
References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <f1a1aaef-5400-89ca-fe26-786686800036@gont.com.ar> <MN2PR19MB4045B25A78B3C0841CC8EAFE838D9@MN2PR19MB4045.namprd19.prod.outlook.com> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <CALx6S35_Rb_vUyDddaiJtt2iT2Gvev=bLs7Rip8TQ8yZppMLDQ@mail.gmail.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <CALx6S35U_Re0T5f9m4AbNyvv7Gk6s9UoN1wdo7_j_phSMm+2gg@mail.gmail.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> <CALx6S351GUy=FJAZ1h6YYfmvJv2yGVVDma26r=Fu56bgzwhFpQ@mail.gmail.com> <16740.1613082711@localhost> <CALx6S376UeJrikyyAbdTFAYzzEMackbaxiXri897xugJJf5mMA@mail.gmail.com> <b6780de8-fc73-cb35-5f44-87907681448a@gont.com.ar> <CALx6S376vcrugJqgk1oGBsfzoGmpTnFqgzzSoiV5hzekswA5rw@mail.gmail.com> <0856c5b2-57a7-cb6f-e74b-c2d1af568c28@si6networks.com>
In-Reply-To: <0856c5b2-57a7-cb6f-e74b-c2d1af568c28@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 12 Feb 2021 18:53:02 -0700
Message-ID: <CALx6S35d4J4i1tRwYbv=uj2gVRudxVnsQXZTEjZdP0ADaj_YsA@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Fernando Gont <fernando@gont.com.ar>, Michael Richardson <mcr+ietf@sandelman.ca>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qzOy2hfvouPDX1Qdl_BB8Rndsfs>
Subject: Re: [tsvwg] [saag] Fwd: Last Call: <draft-ietf-tsvwg-transport-encrypt-19.txt> (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC
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, 13 Feb 2021 01:53:23 -0000

On Fri, Feb 12, 2021 at 3:34 PM Fernando Gont <fgont@si6networks.com> wrote:
>
> Hi, Tom,
>
> On 12/2/21 11:47, Tom Herbert wrote:
> > On Thu, Feb 11, 2021 at 7:08 PM Fernando Gont <fernando@gont.com.ar> wrote:
> >>
> [....]
> >>
> >> FWIW, I'm certainly *not* arguing that the transport layer should not be
> >> encrypted. I'm simply pointing out that operators do more things with
> >> packets that blindly forward packets on a per-packet and per-dst-address
> >> basis. And that that, there are consequences of them not being able to
> >> access IP+transport metadata.
> >>
> > Fernando,
> >
> > Yes, this draft describes those consequences. But what has not been
> > adequately discussed IMO has been the negative consequences of network
> > devices acting on transport layer information. In particular, this
> > leads to protocol ossification and creates a myriad of impediments for
> > application developers trying to build applications to work across the
> > whole Internet. For instance, if you say that QUIC is the only UDP
>
> The fact that QUIC employs UDP should probably already say a lot. :-)
>
> (yes, they were right, and very pragmatic about it)
>
>
>
> > protocol allowed on the Internet., i.e. identified by UDP port 443,
> > then how could we ever deploy a new UDP protocol?
>
> Please see above.
>
>
>
> > This also leads to
> > arms escalation between application developers and network operators,
> > for instance if I do know that UDP port number 443 is the only port
> > number allowed the network then I'll simply wrap my new UDP protocol
> > in a UDP datagram to 443. You might complain that such things might be
> > purposely bypassing your network security, yes they do, however host
> > developers have no obligation to abide by some arcane set of network
> > security policies that are unwritten and inconsistent across the
> > Internet.
>
> And operators might as well argue that they won't leave their production
> networks open to attack for the sake of not constraining future protocol
> development....
>
>
>
> > I do believe that network operators and their users could benefit from
> > getting more information in a packet than just Ip addresses. But I
> > also believe that exposure of information should be volutary as
> > opposed to mandatory, and it should be be very clear what the value is
> > the to the user in exposing information.
>
> If it's voluntary, in many (most?) cases it cannot be relied upon, and
> hence is not of much use.
>
>
>
> > IMO, HBH is the best vehicle
> > to express this information and there is some good work in Network
> > tokens, FAST, and APN around this.
>
> RFC7872 seems to suggest otherwise.
>
I disagree. RFC7872 was one snapshot in time and is now coming up on
five years since it was published; since then RFC8200 was published
with relaxed requirements for intermediate nodes and there is a lot
more active work on extension headers. Besides that, we don't need or
expect 100% of the Internet to support EH, we can use it
opportunistically when we know the path works (e.g. the destination is
a server within the user's provider network that supports the
features).

Tom

> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>