Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Bernard Aboba <bernard.aboba@gmail.com> Mon, 04 November 2019 19:10 UTC
Return-Path: <bernard.aboba@gmail.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 9F3C3120816; Mon, 4 Nov 2019 11:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jHToFy_Ld7RB; Mon, 4 Nov 2019 11:10:15 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 B40E6120114; Mon, 4 Nov 2019 11:10:13 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id f5so13120140lfp.1; Mon, 04 Nov 2019 11:10:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jMTJuPKj27tohTQCbiGlAKfO8CjPHeUoPwytq2veJMY=; b=YiQu5RxaPgJf0F6B4jW+b3r8/bZC3jANfGTm2uNL9fG9o8PRzSMiavKKicFG0g0Icy DTI3u88b6qk6mZ8rBtC5gMXyZHVO8FBFgOGPOziGCqeB9rvK6VLA/3+Zy1+h6+DS9dl1 B4I0PIsT6KOpCd1u4Q6wEUOqk5L209kQDYrL4bydJWiErJdVbhA5Y1wjn3quUQIQSUXz 87eZ9KqJy6c85kZKI6xHfcYhwODvxxbX6CAv6HOhS61Wx9OJlyNfFrqrF91GyNJODgkU LcFSDxP68HDgu+uwFaguM3ZRIdbwbtyCFiUbe1q0yZgc2vHb1zeNRNHpl8OV1VSEA9VK GtOA==
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=jMTJuPKj27tohTQCbiGlAKfO8CjPHeUoPwytq2veJMY=; b=nuRRG9w9AQHEQUXZxoPUvC9TOMGh1YF6c2Uf4g9+4AlZY3WTOd6uoWWWYjbRovfAwr wpVQnPiEn6xeqqVHqeb0ftNk90ogSZuUHn96c3uenJOESlQJJuaopNEwtTTS7G6xSOwB qW+18p2MjiB7VXSLQWiSSyk4CjyATtCw4CXCRjmyLQ37pto0hXiCLi0/ng2of0o9gRRx lyLib1QUabGboF5pZOL7jvkJrj+TKL2idD/P7wjpHwrlMoKgt3kIggxhUejzNpGZiBce KJMRROanTH9nB15kJ/o0CPeuajZVlQzSon7n3MJVEJKdFjqi5gbTH88AnaKpRDq6838k sCbA==
X-Gm-Message-State: APjAAAUgOUktaImFeLkp/HN+XEOFt7SGm0E3bExLiEYchldDHhQAG6To pYk2CIKuGYMt+sA6XLHZnw7qmoA0gPXqEBzSyIe99+Mk
X-Google-Smtp-Source: APXvYqya9WhivT2Duu8EakwXIY46124mInD7C7BZau7f47ET/FkEyIySec8IpGwxzq59WJ7dnAV9vpygk/w8NPR/7fE=
X-Received: by 2002:ac2:5210:: with SMTP id a16mr18133325lfl.156.1572894611632; Mon, 04 Nov 2019 11:10:11 -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>
In-Reply-To: <5DC063F2.8040502@erg.abdn.ac.uk>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 04 Nov 2019 11:10:00 -0800
Message-ID: <CAOW+2dvswQFbibg3R_Wh4uyb56sRAeOAEET_SCw1SXhMWQXXTg@mail.gmail.com>
To: gorry@erg.abdn.ac.uk
Cc: Christian Huitema <huitema@huitema.net>, "saag@ietf.org" <saag@ietf.org>, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, tsvwg IETF list <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000098774505968a10dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/UpYKC9OR9lun9UmRIeEPSYgPVfs>
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: Mon, 04 Nov 2019 19:10:25 -0000
Gorry said: "I'm also going to oppose documenting new ideas for how we can go forward" [BA] The problem is that the "current practices" described in the document are more representative of where we were 10+ years ago, than where we are today, with Infrastructure as a Service (IAAS), Platform As A Service, and Application as a Service (AAAS) providers all operating at enormous scale, all measuring performance using "new ideas" (developed largely outside the IETF). "The RTP people are still in IETF" [BA] The way realtime applications performance assessment has been conducted has changed markedly over the last decade, particularly as the world has moved toward the development and deployment of web-based applications (e.g. Electron, React, PWAs, etc.) where performance data is collected by the Application as a Service Provider rather than the network operator (though the two may collaborate). On Mon, Nov 4, 2019 at 9:46 AM 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. > > > 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. > > > I suspect the information you wish to see about QUIC's design is > actually available. I'm not sure documenting QUIC is helpful here, if > the QUIC WG wants to so that, can't it be added to the manageability draft? > > I dispute the claim that the entire transport area has the same > priorities as that voiced at the QUIC WG. I think this discussion needs > to look outside the QUIC working group and examine other transports and > WGs. As far as I know the RTP people are still doing specs in the IETF, > as are various other transport working groups. Also, this draft has been > presented at OPsec, and has contributors from other areas outside > transport... > > My assertion is that *current* practice is using transport header > information & header authentication/encryption is becoming common, let's > set out what the current facts are. I'm also going to oppose documenting > new ideas for how we can go forward - as Spencer insisted when this was > chartered: Proposing new methods belong in a different draft - paraphrased. > > Gorry > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >
- [tsvwg] Comments on draft-ietf-tsvwg-transport-en… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Eric Rescorla
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Kathleen Moriarty
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Frode Kileng
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Colin Perkins
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Stephen Farrell
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Colin Perkins
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Phillip Hallam-Baker
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Phillip Hallam-Baker
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Kathleen Moriarty
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann