Re: [tsvwg] transport-encrypt-14 review, pt 1

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 10 April 2020 15:08 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 146C03A0C66; Fri, 10 Apr 2020 08:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 z6r77xZ1IXsd; Fri, 10 Apr 2020 08:08:37 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 11EEB3A0C77; Fri, 10 Apr 2020 08:08:22 -0700 (PDT)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 03D551B001AB; Fri, 10 Apr 2020 16:08:15 +0100 (BST)
To: Martin Duke <martin.h.duke@gmail.com>, Tom Herbert <tom@herbertland.com>
Cc: Joseph Touch <touch@strayalpha.com>, tsvwg <tsvwg@ietf.org>, draft-ietf-tsvwg-transport-encrypt.all@ietf.org
References: <CAM4esxTbVSX1voJjzyt3YdapPuv7+K4EpU35SWYC3Y0rmo7Tww@mail.gmail.com> <5922D0CB-81B7-467D-862F-28872476B3B8@strayalpha.com> <eb4d9121-142f-d6b5-72fc-ae4b7a8cf13f@erg.abdn.ac.uk> <CALx6S35txqVEBHrMb8-G0=eV37fbVLj4k-6VMYjAFC_PkZrLmQ@mail.gmail.com> <CAM4esxTBjGyA4OJWeWVgv8nkCJM0GshE7yczRX-B4HLFMGshOg@mail.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <715dd647-34b9-48c4-ec52-ed03bc489adb@erg.abdn.ac.uk>
Date: Fri, 10 Apr 2020 16:08:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAM4esxTBjGyA4OJWeWVgv8nkCJM0GshE7yczRX-B4HLFMGshOg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------47F2D4012B4691FF5B09B441"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/C94phvfa5I061QT_FXC0xhSrxNs>
Subject: Re: [tsvwg] transport-encrypt-14 review, pt 1
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, 10 Apr 2020 15:08:44 -0000

On 10/04/2020 16:03, Martin Duke wrote:
> Very well everyone,
>
> I'm conscious of coming in at a very late stage in the consensus -- if 
> we've already defined header modification as out of scope, then very 
> well (although it would be good to state that the Introduction, 
> assuming I didn't miss it there). That certainly negates my comments 
> PEPs and injection attacks as subjects, although that seems like an 
> important part of this landscape.
>
> To Gorry:
> > That seems rather a simple view! Traffic conditioning and monitoring is
> still something that can operate at the flow level and by address, even
> on IPsec flows for instance - just with less accuracy, and likely
> requiring more heuristics and with more and different "failure" modes
> e.g. that impact sequences of packets rather than deterministically drop
> packets with specific headers.
>
> By "almost impossible" I was exactly suggesting this kind of approach, 
> which I am fairly convinced will lead to tears. But people are going 
> to do what they're going to do, I guess.
>
> Martin
>
Yes, and my own judgment (personal of course) is also that going too far 
down this particular direction could well end in tears.

Gorry

> On Fri, Apr 10, 2020 at 7:51 AM Tom Herbert <tom@herbertland.com 
> <mailto:tom@herbertland.com>> wrote:
>
>     On Fri, Apr 10, 2020 at 12:45 AM Gorry Fairhurst
>     <gorry@erg.abdn.ac.uk <mailto:gorry@erg.abdn.ac.uk>> wrote:
>     >
>     >
>     > On 09/04/2020 21:20, Joseph Touch wrote:
>     >
>     >
>     >
>     > On Apr 9, 2020, at 12:44 PM, Martin Duke
>     <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>> wrote:
>     >
>     > - Conversely, middlebox interference with headers does enable
>     performance enhancing proxies for extraordinary link types like
>     satellite.
>     >
>     >
>     > Those are only “extraordinary” only in the “been around for 50
>     years in the Arpanet/Internet”. That understanding goes back as
>     far as RFC 346 and IEN 8.
>     >
>     > Additionally, ground nets often experience similar BW delay
>     products, which can be the dominant driver.
>     >
>     > There are known ways to help TCP over such links that don’t
>     involve these sort of steps, documented as far back as RFC 2488,
>     some of which are now being incorporated (faster window growth and
>     recovery, ala Hybla).
>     >
>     > I.e., just because a mechanism CAN rely on these headers doesn’t
>     mean that’s the only - or even safe - way to do so.
>     >
>     > Joe
>     >
>     > I'm with Joe there are MANY ways that devices sitting in the
>     network *do* presently change TCP headers. This is not at all
>     restricted to specific technologies such as Satellite. TCP ACK
>     filtering/decimation/etc is commonly used on a variety of paths to
>     reduce return link traffic in WiFi, Docsis, LTE, etc. PEPs have
>     split TCP in many ways where delay and/or loss is important,
>     devices that track or change rwnd are out there, as are other
>     devices that have modified other things for better or worese.
>     However we already have RFC3135, RFC3449, a variety of header
>     compression specs, and more recently RFC8404. All of which delve
>     into these topics.
>     >
>     > In an earlier thread, I motivated restoring the focus on methods
>     that observe headers and do not "manipulate" these. It's true that
>     when the WG decided to add the "ossification" examples at the
>     start iof the document, that these were nearly all related to
>     changing headers, but still I think the focus of the remainder
>     should be on methods that do not change headers - That also is the
>     set of methods that could be compatible with end-to-end
>     authentication.
>     >
>
>     Gorry,
>
>     I think the draft is trying to walk a fine line. The draft provides
>     several examples of presumably benevolent instances of passive
>     observation, however doesn't acknowledge there are deployed use cases
>     of modification. There are people that would probably agree that maybe
>     observation is okay but modification is detrimental. There are also
>     those that might say any use of transport information by intermediate
>     nodes is bad and leads to ossification, so both observation and
>     modification should be prevented. A third camp might say we've been
>     modifying TCP fields and our users are seeing great benefits so it's
>     okay. I don't think there is consensus on which of these viewpoints is
>     correct, however I believe that the goal of the draft is trying to
>     establish a balanced position without judgement, so not mentioning a
>     known use case that would definitely be affected by transport layer
>     encryption seems like an omission.
>
>     I'd also point out that if a transport protocol developer makes a
>     conscious decision to not encrypt some data in the transport layer for
>     the benefit of observation at intermediate nodes, it's just as easy
>     for them to also purposely not authenticate data so that intermediate
>     nodes could modify it (again this is independent of any judgement as
>     to whether intermediate nodes observing or modifying end-to-end data
>     is a good thing).
>
>     Tom
>
>     > Gorry
>