IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 11 February 2021 22:31 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 4FE563A0D5C; Thu, 11 Feb 2021 14:31:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 InqeBygHaN8C; Thu, 11 Feb 2021 14:31:53 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00883A0D55; Thu, 11 Feb 2021 14:31:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E6C4738A3E; Thu, 11 Feb 2021 17:35:14 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DxzCNfxnaMxJ; Thu, 11 Feb 2021 17:35:14 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 722B838A3C; Thu, 11 Feb 2021 17:35:14 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 30450320; Thu, 11 Feb 2021 17:31:51 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
In-Reply-To: <CALx6S351GUy=FJAZ1h6YYfmvJv2yGVVDma26r=Fu56bgzwhFpQ@mail.gmail.com>
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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 11 Feb 2021 17:31:51 -0500
Message-ID: <16740.1613082711@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/U8Nl_doBgotZs7vYuRr-m8_Sqk8>
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: Thu, 11 Feb 2021 22:31:56 -0000

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.
(_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.
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.

Showing your layer-4 header is unlawful search in my opinion.
The pen-registry only needs to have the destination number to connect the call.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email