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

Eric Rescorla <ekr@rtfm.com> Tue, 05 November 2019 19:59 UTC

Return-Path: <ekr@rtfm.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 2C8B5120A8D for <tsvwg@ietfa.amsl.com>; Tue, 5 Nov 2019 11:59:43 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 7NIq75TqKUVi for <tsvwg@ietfa.amsl.com>; Tue, 5 Nov 2019 11:59:41 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 625681209C0 for <tsvwg@ietf.org>; Tue, 5 Nov 2019 11:59:34 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id q2so16764739ljg.7 for <tsvwg@ietf.org>; Tue, 05 Nov 2019 11:59:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wfWof+oWvw61V1BM2zohLZy5WA3LAAsoi066yQ6HWEM=; b=ACeCHrYMxMcE1YNFIP3fLNgca3JMnRrbjqYojJL/pOYNSlZTlaV5/y8NEfzVSWZz5G 4PoNlS+8zDx4j1OIffgEAmuxQUj6TIa4K1qBfsZ+OxtWe3ZPYtfeUol+rk0jicuPXSjh OwZlldYeEjsPgmsMCaBkatxWHgXod71XLe+43VjmLdKiuKvYApThTKDYJ2jqqjmpmWor h1xSYlf8p48gigubOSbvPuhREZrBj3O/hiBcMqq32dXPg/Di/8xliO8zo6XHMYU0jkfu ssBwTE1iGu/GlMjfh4c10qtKcEGHsa+3tRxnHYjMdWCCBhFNOgq+EGdnMev2ZOvp/IdR qYfg==
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=wfWof+oWvw61V1BM2zohLZy5WA3LAAsoi066yQ6HWEM=; b=dcypvEIyiXSsHzGdvVXsTFlM4a1f2tyA+ViQwRqboiERCIyrZu+aEU/Zg+hxuFYYIR AIfBM+ZQkQFBcrJpSsMknjhBXwZMS7Sg4XIKMa4BTjC4bZJKiVEJrmI1vnhN67DVA6dj xpggSJpeuSyJVLRP1iDCm15LeESKRIUaH/RnqgMLhYF7WXQYLLhu0KtTsXUm2O5t7VJG vui1Hi97xl3cNnl9oRFLEwfq9HfG/WyBSdJiJQUArchBLX661Tf8DP14osvzUf/fMV/H UMDrKvU2nPfr0dTT2Td+3tLS4acbvDs395PJmIS49WE6g4s6LusrtsbPPJjH18vHhI9M 3p0g==
X-Gm-Message-State: APjAAAXhYAIesqNsIT7eEmQzF8Z/P4j5zm/lqAnv+MukOH1Ad6tcosoJ /KEu5VUWhL5WzO11bCzqpajwKoYjJJ9/O/iqgrO8DQ==
X-Google-Smtp-Source: APXvYqyfBNJoLK2T9EzvhdNYSfwMR6dauZmsMpsX0jEv3X0WpBXhXZCkYnSdQ+qvO38c36PYtaKR0DPqXhXzw5RZ6IM=
X-Received: by 2002:a2e:3e18:: with SMTP id l24mr24737579lja.48.1572983972383; Tue, 05 Nov 2019 11:59:32 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <B74B17C8-A8D7-47F9-9DA2-610A8EB9F3BA@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 5 Nov 2019 11:58:55 -0800
Message-ID: <CABcZeBMemLcmXdWnstOwa5GFatgp5HcwMo6r-a2A9Etp03xTfA@mail.gmail.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Christian Huitema <huitema@huitema.net>, tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e964a505969ede02"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/tOOnrPGydqRsbqH_EnVqtKM04ro>
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 19:59:43 -0000

On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind <
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> 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