Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

Tom Herbert <tom@herbertland.com> Thu, 28 February 2019 17:34 UTC

Return-Path: <tom@herbertland.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 0AFFF130EBE for <tsvwg@ietfa.amsl.com>; Thu, 28 Feb 2019 09:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 d7TSwalzasEP for <tsvwg@ietfa.amsl.com>; Thu, 28 Feb 2019 09:34:16 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 06C37130F2B for <tsvwg@ietf.org>; Thu, 28 Feb 2019 09:34:16 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id w4so24509431qtc.1 for <tsvwg@ietf.org>; Thu, 28 Feb 2019 09:34:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=c4QW+OFYSax3vpU/8UhEbNKqM6+oAhYiAmCL7AteVB0=; b=NFdBj23L0yx/whCWFhwFwcQKryR3uF/W/9zhRllk8jJ64PNxW29kZJT/QZbXgTSsxm cOAHaLCHuzsvuklKCR1DTZajFM6I2zHoWTlZXCDr6vlIR5MAQWJBFTuxILMHcGAMsYPg rebo+UdVWvD3vOpXGSEKH+Fp92Ps+dWjdpvYpJZ/WCw+Ed7XcScTSPAqObLVfUuj/Aq+ gyAXT7Ovy+7bckZs+OoOhN83mFuGEZD2KpVXmREPMQmGNpQ94v6mkSOt+fdNkNjlFEFY LzDaGz6Bi5V/5jvNS3R7dT32/tC84Zv6U4A9Y1dIpZRxUq43Fle9kekQlVO7GGn2y+g3 Wbbg==
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:content-transfer-encoding; bh=c4QW+OFYSax3vpU/8UhEbNKqM6+oAhYiAmCL7AteVB0=; b=FWDfkB8ww9zdrZCn3LJowdU7T4obHG03ksoHXHCEf3bu5wAhdpTO3ioTeJan0t0ZNw yyslVC+zp74by/wJcdalDSEB8n04RmL4DgkyibfeinvhgoMDqOfR+URcs4GuEaK5+6UG 3mAmj4U8dnOMiIU2WAv9rEXW4pLDDSTgXSTKaS4F9IVDlTZ7iw/s+rlF8saZT2WtZSS/ Q+QzbJh9DKn3IhSjjc9hXN7rQjwaWXb35blE9TCRtd/RKqGM2kkD6yOIrLxK6Mxo/eM9 j6avrbdvtnixdU8SvJ4FT7x3aX9ThH0UMp6/9v0t+kDhMs8j9rZT/tYh8LOe0dcV4L1V f4Sw==
X-Gm-Message-State: APjAAAX9napoKQjmWzoe8J6ZTrQlIlmIM3WH1MAzP021K+39rz79Ei3U zlRPwQf+Ym6TNsCODy/3S9T7X/Xfykx5h4FUiur0hQ==
X-Google-Smtp-Source: APXvYqzIFQli74otG8qBTbeSZ+dju/7E2tzaqWRwi/yyA3VwVbYT4rGflEpAva2qXecYI9+84bD/EN4ykzEWzw+y848=
X-Received: by 2002:ac8:22d6:: with SMTP id g22mr308207qta.97.1551375254745; Thu, 28 Feb 2019 09:34:14 -0800 (PST)
MIME-Version: 1.0
References: <155052226474.25978.1700439564007128149@ietfa.amsl.com> <CALx6S34o08DY-v-1S59VAerwpnf3wD6puNGe-Jq90aswYdK8Xw@mail.gmail.com> <5C6C3F9C.1070601@erg.abdn.ac.uk> <CALx6S35WuRra0njfY=HOCaF8v9ampkTG612nbjKwid=CHQNumQ@mail.gmail.com> <072547E4-D84D-4313-BEEE-0CB66A3C6A1C@csperkins.org> <LEJPR01MB0460F9AB6E2113F4CBF246EA9C7D0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CALx6S37RjKafmj9V3CifCDVSTK7Xz+kWfJGmAbq6udWHJzTGxQ@mail.gmail.com> <LEJPR01MB0460EF67D703C8340A976DF39C7D0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CALx6S34BbkeMumZ5-D2N9GOJ=bx=n-m6TGR0CVqU9iWVc0rH0w@mail.gmail.com> <LEJPR01MB046097E5E99F79B9F9A2C97A9C7E0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CALx6S34ZFFO8uzFAt5aQ+ACTUXwH1t5jChewvxNuROpnPqdOjA@mail.gmail.com> <LEJPR01MB04609B9A82FC9FE960D445449C7F0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CALx6S37DBmWpW_PDzm8P_X70qCGiHcFz=8DY5ZUhUk1dWgXgNQ@mail.gmail.com> <LEJPR01MB046073E87F7278B21A26E7FB9C7A0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CALx6S341BDig0WGjjbbvjUCEY_3uA4vJ7=mKTGM=YP6J6+-Zmg@mail.gmail.com> <LEJPR01MB04601AD62AED2EC7F3C3E0239C750@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE>
In-Reply-To: <LEJPR01MB04601AD62AED2EC7F3C3E0239C750@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 28 Feb 2019 09:34:03 -0800
Message-ID: <CALx6S358A--qSbbOr0URG7ByY8sspcc6qHy9h97uHVpBDEwZDQ@mail.gmail.com>
To: Ruediger.Geib@telekom.de
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/lvhWpp4l1HBY37VnS7a_AV9miy0>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.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: Thu, 28 Feb 2019 17:34:19 -0000

On Thu, Feb 28, 2019 at 1:14 AM <Ruediger.Geib@telekom.de>; wrote:
>
> Hi Tom
>
> what I'd prefer is a standardized default exposure of the discussed information by $transport_protocol. Something that's reliably part of commodity code. Evaluation of RTT information is passive, the nodes don't have to read the information, it's to be forwarded unchanged.
>
> The window size optimization is a different story, as it requires active communication of nodes and terminals along a path. Got no expertise. My guts feeling is, that a simplistic generic mechanism may be feasible (not a perfect one).
>
> As I mentioned, my transport know how is limited and I rely on others to judge, whether your draft and other proposals may find consent. It would be great to solve the issues once and maintain some generic design guidance, so that we don't have to have the whole discussion with every new transport protocol.
>
Ruediger,

That's the goal. Allow optional exposure of generic transport layer
information in the network layer. This works with any transport
protocol or any encapsulation, network devices no longer need to do
expensive DPI, and encryption of the transport layer headers becomes a
non-issue. This is the simplest approach!

Tom

> Regards,
>
> Ruediger
>
>
> On Sun, Feb 24, 2019 at 11:52 PM <Ruediger.Geib@telekom.de>; wrote:
> >
> > Tom,
> >
> > if consensus and a standard on your proposals for IPv4 and IPv6 can be reached, I'm ok. I'm not a transport protocol expert however (my expertise is QoS and network/transport QoS related QoE - I use the information to be gathered). Others can judge transport protocol related aspects better.
>
> Hi Ruediger,
>
> My proposal is to put network signaling and transport layer information an node wishes to expose in the common network layer.
> Extension headers have been designed for this purpose, but they are only defined for IPv6 and some intermediate nodes don't like them anyway. I posted  draft-herbert-ipv4-udpencap-eh-00 as a proposed solution.
>
> Tom
>
> >
> > Regards,
> >
> > Ruediger
> >
> >
> > -----Ursprüngliche Nachricht-----
> > From: Tom Herbert <tom@herbertland.com>;
> >
> > [RG] I've re-ordered that, Tom's response above my last mail now...
> >
> > Ruediger,
> >
> > Yes, ECN is good example of an IP layer mechanism that carries information of interest to various transport layer protocols. A router can set ECN with no regard to the transport or payload so the mechanism works with TCP, QUIC, SCTP, etc. But, ECN bits are in the IP header and there really are no reserved bits in either IPv4 or IPv6 headers and no bits that can be easily repurposed for other uses (people have tried, there have been several proposals to repurpose bits in the IPv6 flow label for instance).
> >
> > The correct solution is put the exposed transport information, or more generally host to network signals, in an extensible lower protocol (i.e. in the network layer). In IPv6 that would be Hop-by-Hop options.
> > For IPv4, it's a little more difficult to find a good solution, some sort of shim header might work (SPUD was proposed for that). The third high order bit of Hop-by-Hop options indicates whether the option can be modified in-flight and non-modifiable data can be authenticated so it is robust. There are other considerations such as ensuring that signals can't be spoofed to gain an unfair advantage and that exposed data might need to be scoped somehow (for instance I might be willing to share information with my local provider, but not to the whole Internet).
> >
> > Tom
> >
> >
> > On Thu, Feb 21, 2019 at 11:33 PM <Ruediger.Geib@telekom.de>; wrote:
> > >
> > >
> > >
> > > [TH]  The RTT and other information can only be extracted from transport layer headers under very specific circumstances (header has the right fields, transport header is visible and in cleartext, intermediate devices can parse the transport layer protocol, etc.).
> > >
> > > [RG] Agree. By chance TCP allows to determine RTT within the network. RTT monitoring allows network providers optimize router buffers and supports QoE estimates. I'm out for simple solutions. My take is, IETF should provide hints to transport  protocol designers. If transport protocol features are impacted by network properties, then allow the network to detect these. Transport depending on determination of the bandwidth delay product is impacted network features. Classic TCP shows (by chance) that exposing RTT information is feasible and it is beneficial for endpoints as well as for network providers.
> > >
> > > [RG] As general guidance I suggest: if a new transport protocol depends on bandwidth delay product optimization then expose the relevant information by design to those partys in your chain operation, which may impact the bandwidth-delay-product.
> > >
> > > [TH] If you want a win-win than provide a solution that works with all protocols, promotes security, minimizes effort, and ends protocol ossification. I don't see that this draft proposes anything resembling such a solution. The idea seems to be that transport protocol designers should consider purposely sending some fields in the clear.
> > > Okay, but what exactly are the requirements? How is it simple if this needs to be done independently for every transport protocol? What are the realities of that to be feasible? Is the requirements and assumption that all transport protocols have to provide the same information as TCP? What about network mechanisms that want to modify fields like the receive window-- how does that work robustly in other transport protocols?
> > >
> > > [RG] Requirements: see above. I don't advocate to recommend RTT communication exactly like it is done for TCP - I'm open for discussion between involved experts. I prefer a single recommended approach. As you note yourself, "works with all protocols" and "independently for every transport" - the networks of today can't do per transport protocol or per flow optimization. Fast forwarding and some generic filter edge policies, that's it. Measurements for QoS based QoE estimation and RTT are done passive. I'm not aware of any approach distinguishing transport protocols down to every detail (UDP, TCP, the latter TLS or not and QUIC ... ). Router buffer dimensioning isn't done per transport protocol. A commercial provider network is optimized to service the majority of the users fairly well. "Corner cases" are all those transport protocols which have a share of, say, a low single digit percentage in a commercial network.
> > >
> > > [TH] What about network mechanisms that want to modify fields like the receive window-- how does that work robustly in other transport protocols?
> > >
> > > [RG] Above I talk about passive measurements. Here you talk about a kind of active communication between routers and of transport protocols (if I get you right - I got no expertise). To me, you mix things which need to be discussed separately. If routers are to support transport features actively, mechanisms need to be standardized to a high degree. Let's take ECN is an example. Two well defined IP layer bits. It took years to switch from the early standardized interpretation to experimental ones. I think, well defined fields and a simple general standard support are the only way to enable routers to communicate information to transport protocols (apart for communicating by "packet drop").
> > >
> > > Regards, Ruediger
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Tom Herbert <tom@herbertland.com>;
> > > Gesendet: Donnerstag, 21. Februar 2019 16:46
> > > An: Geib, Rüdiger <Ruediger.Geib@telekom.de>;
> > > Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>;; tsvwg <tsvwg@ietf.org>;
> > > Betreff: Re: [tsvwg] I-D Action:
> > > draft-ietf-tsvwg-transport-encrypt-04.txt
> > >
> > > On Wed, Feb 20, 2019 at 11:46 PM <Ruediger.Geib@telekom.de>; wrote:
> > > >
> > > > To find a definition for bulk usage transport and set apart corner
> > > > cases (like tunnels, SCTP and so on),
> > >
> > > I still don't understand what "corner case" means with respect to standard IETF protocols. Can you please define this? What are the requirments for a protocol being a corner case on the Internet or not?
> > > Who makes this determination?
> > >
> > > > please have a read into state-of-the-art QoE estimation research. There's ample literature on that. In the recent years, QoE research is mostly based on the evaluation of several thousand flows. In many cases captured by commodity terminals connected to consumer Internet products.
> > > >
> > > > TCP or QUIC measure RTT by design. As we all know, RTT can easily be measured by evaluating transport protocol information, if exposed. This information helps to optimize provider networks.  What you recommend is to add an extra header to have a surrogate RTT measurement (if standardisation works out well, IOAM isn't  commodity network feature). I prefer simple solutions. The RTT information can be extracted from the transport layer, as we all know.
> > >
> > > No, we don't all know that. The RTT and other information can only be extracted from transport layer headers under very specific circumstances (header has the right fields, transport header is visible and in cleartext, intermediate devices can parse the transport layer protocol, etc.).
> > > >
> > > > The solutions you advocate result in monitoring strategies
> > > > requiring monitoring applications on consumer terminals. To me,
> > > > that threatens security of those consumers willing to support such
> > > > an
> > >
> > > Applications are already heavily monitored as endpoints. The information that can be gathered about an application from some random point in the network is extremely limited. Application developers rely on the data collected at endpoints to make their decisions. The only time we need drill down to see what is happening in the network is when we see particular networks are messing things up (for instance, when we noticed that some  network devices we're drop SYNs with data when TFO was being developed).
> > >
> > > > approach more that exposing some network related information in transport headers. IOAM is an approach which might work some day. QoS and QoE monitoring based on applications in consumer terminals is deployed today. I expect the latter to spread, and to spread faster, the less network related information is exposed to network operators.
> > > >
> > > > I don't think that TCP/IP is the one and only and I don't think that things never change, as I'm changing them myself. I prefer to create win-win solution based on solutions which are as simple as possible. In my experience solutions with these properties work best.
> > >
> > > If you want a win-win than provide a solution that works with all protocols, promotes security, minimizes effort, and ends protocol ossification. I don't see that this draft proposes anything resembling such a solution. The idea seems to be that transport protocol designers should consider purposely sending some fields in the clear.
> > > Okay, but what exactly are the requirements? How is it simple if this needs to be done independently for every transport protocol? What are the realities of that to be feasible? Is the requirements and assumption that all transport protocols have to provide the same information as TCP? What about network mechanisms that want to modify fields like the receive window-- how does that work robustly in other transport protocols?
> > >
> > > Tom
> > >
> > > >
> > > > Regards,
> > > >
> > > > Ruediger
> > > >
> > > >
> > > >
> > [snip]