Re: [saag] [tsvwg] 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

Fernando Gont <fernando@gont.com.ar> Fri, 12 February 2021 01:56 UTC

Return-Path: <fernando@gont.com.ar>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A38C3A1060; Thu, 11 Feb 2021 17:56:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 MmnAovTJEo89; Thu, 11 Feb 2021 17:56:06 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21913A105F; Thu, 11 Feb 2021 17:56:05 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 476E6283B7D; Fri, 12 Feb 2021 01:55:56 +0000 (UTC)
To: Michael Richardson <mcr+ietf@sandelman.ca>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
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>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <0590c44a-847d-a171-39b1-cb5e685bb9db@gont.com.ar>
Date: Thu, 11 Feb 2021 22:55:48 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <16740.1613082711@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/FcURF-MTLGoixG-pFk9DvuVCu0Q>
Subject: Re: [saag] [tsvwg] 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: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2021 01:56:11 -0000

On 11/2/21 19:31, Michael Richardson wrote:
> 
> Tom Herbert <tom@herbertland.com> wrote:
>      > Perhaps, but in order to change the protocol to satisfy the
>      > requirements of folks running networks, we'd need to know *what* the
>      > requirements are. For instance, if someone were to say that networks
>      > require more information than what is in the IP header to successfully
>      > deliver packets, then I will immediately ask that they specify
>      > *exactly* what information they need. Until/unless that is answered we
>      > are left guessing as to what may or may not be acceptable in various
>      > networks and the tussle continues.
> 
> 15+ years, when "transport-friendly ESP" was litigated (and to my surprise
> got a protocol number), the 3G people went on and on about how much better
> they could do if we (the IPsec people) would show them TCP information.
> I asked, repeatedly, for details of this supposed improvement.
> I got nothing in justification.  My request was simple: if you want me to
> increase my risk, then show me what the benefit is.

Well, this is how operators' version of it: RFC7872. -- i.e.: "Your ESP 
packets probably don't go through. **Show me the money**".



> (_Show me the money_)
> I now know that really, they were dealing with ad-hoc solutions to
> bufferbloat, but they didn't know that then.
> 
> BTW: nobody uses TF-ESP. It's totally and completely dead. There was never
> any benefit worth the risk.
> 
> Fernando says they need src/dst port, but I disagree.

Ask operators. That's what I did.


> They want every bit they can get, including the encrypted insides of TLS, but
> they have no idea really, what legal things they actually want to do with it.

There's folks that probably want as much as they can get.. But the vast 
majory of them want IP `transport header, for load-balancing, variety of 
ACLs, et al.



[...]
> The pen-registry only needs to have the destination number to connect the call.

For networks where packets flow frelly between any arbitrary nodes, yes.

I doubt such networks exists, except in specific walled gardens.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1