Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 05 November 2019 20:19 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 A64DD120B7F; Tue, 5 Nov 2019 12:19:32 -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, 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 bsUljQT3XZ07; Tue, 5 Nov 2019 12:19:30 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 64645120B73; Tue, 5 Nov 2019 12:19:30 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 933721B0023F; Tue, 5 Nov 2019 20:19:22 +0000 (GMT)
Message-ID: <5DC1D94A.9040602@erg.abdn.ac.uk>
Date: Tue, 05 Nov 2019 20:19:22 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
CC: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Christian Huitema <huitema@huitema.net>, tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
References: <CABcZeBPajzuEdw8=M1g1i-TAniJ9O+H5dEMxv8c6N3tD=7mSvw@mail.gmail.com> <CALx6S35bSAa_zq=HsF-3e9qC-vRNFRu6dn+O4ak4Hi+c=Tmz5A@mail.gmail.com> <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> <CABcZeBPfT=B+fOXAkPuoEQQHAtJrefXSgnjOpPC7-4zC_myRsA@mail.gmail.com> <D36061F0-F872-4054-ACF0-C9A88FCEC572@ericsson.com> <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk> <B74B17C8-A8D7-47F9-9DA2-610A8EB9F3BA@ericsson.com> <CABcZeBMemLcmXdWnstOwa5GFatgp5HcwMo6r-a2A9Etp03xTfA@mail.gmail.com>
In-Reply-To: <CABcZeBMemLcmXdWnstOwa5GFatgp5HcwMo6r-a2A9Etp03xTfA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Q3sooxTaIyYqTlkoeijvpyJ8gRo>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
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: Tue, 05 Nov 2019 20:19:33 -0000

On 05/11/2019, 19:58, Eric Rescorla wrote:
>
>
> On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind 
> <mirja.kuehlewind@ericsson.com <mailto:mirja.kuehlewind@ericsson.com>> 
> wrote:
>
>     Hi Christian,
>
>     please see two comments below (marked with [MK]).
>
>     Mirja
>
>     On 04.11.19, 18:46, "Gorry Fairhurst" <gorry@erg.abdn.ac.uk
>     <mailto:gorry@erg.abdn.ac.uk>> wrote:
>
>         Just focussing on the end...
>
>         On 04/11/2019, 16:29, Christian Huitema wrote:
>     >>
>     >> [MK] That’s not the intention here. But we also need to
>     consider ways
>     >> to interact with the network where this brings benefit to both the
>     >> network and the performance of the end-to-end traffic. There are
>     >> situation where this is the case. And I don’t think one makes
>     sense
>     >> without the other.
>     >>
>     > You seem to be arguing for something like "performance enhancing
>     > proxies". End-to-end encryption is indeed a way to opt out of such
>     > proxying. Measurements so far indicate that opting out has very
>     little
>     > impact on actual performance, and that whatever impact there is
>     could
>     > be reduced by improvements in end-to-end algorithms. In fact, in
>     many
>     > cases, end to end performance is better without such proxies.
>     But the
>     > real reason for the opposition to the concept is ossification.
>     > Enabling such proxies would quickly ossify the new transports,
>     and a
>     > such there is a strong consensus in the end-to-end transport
>     designers
>     > to use encryption and prevent interference by such devices.
>     >
>         On PEPs: The current case for many of the network segments I
>     see is that
>         QUIC is quite good, but it is considerably worse (currently)
>     than a PEP
>         using Split-TCP. That's not to say it can't improve - but
>     that's not
>         true yet. However: It's curious that people keep going back to
>     PEPs,
>         because network devices that change the transport header were
>         specifically out-of-scope for this ID!
>     >
>     > This does not mean that network level deployment have no role in
>     the
>     > future. I could see for example tunnels deployed that use FEC or
>     local
>     > retransmission to mask the poor performance of a particular
>     subnet. Or
>     > I could see end-to-end devices opting into some kinds of
>     application
>     > level caching services in order to improve performance. But the
>     draft
>     > should be clear: transport protocols do not have to enable
>     > interference with the transport bits.
>
>     [MK] This is not what the draft is asking for.
>
>     >
>         There are also many operators - e.g., enterprise who rely on
>     the methods
>         currently mentioned in this draft. In this case, they also
>     actually *do*
>         care about the performance of the networks they operate. They
>     also do
>         care about the topics, which matters most depends on which
>     organisation.
>     >
>     > My take is that this draft should not be published as is. It
>     should be
>     > rewritten to actually reflect the consensus of the transport area,
>     > which has to reflect in particular the work in the QUIC working
>     group.
>
>     [MK] The purpose of this draft is exactly to find and document
>     consensus in the transport area and in the IETF. I don't think any
>     individual at this points knows what the consensus actually is. 
>
>
> Well, in that case this document shouldn't be being advanced.
>
>
>     This document has support in tsvwg (otherwise it would not have
>     been adopted as wg document) and I also don't think there is
>     anything in the draft that contradicts any work in the QUIC group.
>
>
> Well, I think what you're hearing is that people think that it is 
> badly aligned with the consensus of other parts of the IETF.
>
> -Ekr

Than ks Ekr, but of course, I don't agree on your thoughts. Which is why 
this needs to be carefully considered.

Gorry