Re: [Int-area] Per-Application Networking Considerations
Toerless Eckert <tte@cs.fau.de> Thu, 18 February 2021 21:51 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256153A18E2 for <int-area@ietfa.amsl.com>; Thu, 18 Feb 2021 13:51:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2MVQzsZPABYv for <int-area@ietfa.amsl.com>; Thu, 18 Feb 2021 13:51:41 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01133A18E5 for <int-area@ietf.org>; Thu, 18 Feb 2021 13:51:40 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 14CB654802F; Thu, 18 Feb 2021 22:51:35 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0D91C440163; Thu, 18 Feb 2021 22:51:35 +0100 (CET)
Date: Thu, 18 Feb 2021 22:51:35 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: "int-area@ietf.org" <int-area@ietf.org>
Message-ID: <20210218215135.GA21407@faui48f.informatik.uni-erlangen.de>
References: <160549933225.16448.15210422391776585953@ietfa.amsl.com> <7CDDE2AD-62C9-4E0A-9D7E-4698CD8009E1@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7CDDE2AD-62C9-4E0A-9D7E-4698CD8009E1@apple.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/9-I8lo68ddHoiazDSWgYw3ldjPw>
Subject: Re: [Int-area] Per-Application Networking Considerations
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 21:51:44 -0000
Hi Tommy, Lorenzo Thanks for this work. Its always good trying to make _any_ progress on this subject matter. This is a huge can of really interesting worms many of us have been thinking about for a long time in various aspects, so i have to constrain myself. Not sure i succeed. The one most high-level concern is that of scope and actually considering the scope where these technologies are not something to fear, but where they actually are crucial to the use case. For example, the end-to-end security model to counter pervasive monitoring is exactly what i personally likely want for my internet browsing activity, but when i would have to build the network & compute infrastructure for a big complex system, like a manufacturing or power plant, it is maybe almost the opposite of what i need, but because of scope misinterpretation and creep of IETF principles such as those PM goals, i might not be able to get the software solutions anymore to build the ideal solution because all endpoints SDKs are only providing let's say TLS 1.3. For example: In an embedded network, most of the hosts are unrustworthy stupid machines sensors/actors with absolutely no privacy rights that regularily misbehave and endanger the reliabilty of the overall system, they also have absolutely no revenue model to permit the quite expensive crypto agility operational model, but need to be stockable for 30 years. On the other hand, almost every forwarder in the network serves an orchestration, control and/or surveillance function, and i would like all my data flowing through the network to be authenticated but not encrypted so i can most easily perform all these verification, orchestration and control functions. Oh, and i have shitloads of physical security. Of course, this is a simplistic exaggeration, but i think it would be prudent to the ongoing wider reach of IETF solutions to acknowledge that we have to support a continuum betwen maybe those two extremes: The network as the nervuous system of what ultimately is a big distributed application on one extreme over to the "Internet browsing" as maybe the other extreme. Of course expecting a one-dimensional problem space is also simplistic, but at last it is one dimension more than assuming that all our problems are around the zero-dimensional problem space of Internet browsing (OTT service consumption). To that extend, one suggestion for 110 is to ask bringing up the subject at iotops WG too in the hope to find feedback from more IETF participants working outside the "Internet Browsing" use case. One other point for now: Nobody loves DPI, but when i presented draft-eckert-intarea-flow-metadata-framework into the IEF during probably the height of the PM work (2014) to overcome DPI and to easier allow for end-to-end encryption without removing the ability to support the application objectives best, the reaction was pretty single minded rejecting anything that didnt serve the PM goal, with feedback like this: "An application should never be given an opportunity to even willfully disseminate any information to a network, because we can not trust application code to do anything" (of course the sentence didn't go on saying "beside passing all possible user information into a data-center without any user consent", but hey, it was 2014). In fact, that whole draft design was based on the recognition that applications indeed are often too stupid to understand what they need from the network to give them the best experience, and that is an important problem to solve, but it has never been a problem that Internet cloud application providers where interested in, because all their past network facing design was based on attracting the most users even in the face of the worst network (design against worst 20%) instead of spending any development cycles on supporting better experiences for the top 20% that would be able to get better differentiated network services. Especially given that the network service providers offering those better network services are commercial competitors of said internet cloud application providers. And i am not putting blame anywhere, i just think we need to openly talk about the commercial interests that we do want or not want to represent in the work. Its the elephant in the room: As long as we have such a huge disconnect in economic interest between key stakeholder in the IETF, we are just going to see technical solutions based on who has more influence to push their side of a divisive agenda. Btw (and i hope i remember this correctly): Even back in the days of early windows NT (around or before XP), the API was not to let poor applications figure out what they should request from the network (application: "WTF is a DSCP, and why do i need to care ?"), but instead it was a policy layer provisioned by the windows domain operator that did that. And accordingly mapped application traffic flows to appropriate DSCP and/or RSVP signalings. That type of layered approach would allow to create different policies and resulting different degrees of exposure of information for the same application if its either deployed in that nuclear power plant vs. a home for internet browsing. Add appropriate authentication and better than RSVP/DSCP signaling, add encryption for the Internet use-case, jada jada - and we would get towards good technical solutions... (IMHO). Cheers Toerless On Mon, Nov 16, 2020 at 08:22:22PM -0800, Tommy Pauly wrote: > Hello INTAREA, > > We published a draft this week that we???d like to briefly introduce for discussion within the intarea WG, draft-per-app-networking-considerations. This is an informational document that discusses the implications of a trend we???ve noticed towards putting more application identifiers or per-application logic in the network layers. Many different proposals touch on the idea of differentiating traffic based on application, but we believe it would be useful to have a general statement about the privacy trade-offs and design considerations in this space. Moreover, we think that a broad technical group like intarea may be the right place to discuss and review this work. > > https://www.ietf.org/archive/id/draft-per-app-networking-considerations-00.html > > Your reviews and thoughts are appreciated! > > Best, > Tommy & Lorenzo > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-per-app-networking-considerations-00.txt > > Date: November 15, 2020 at 8:02:12 PM PST > > To: Lorenzo Colitti <lorenzo@google.com>, Tommy Pauly <tpauly@apple.com> > > > > > > A new version of I-D, draft-per-app-networking-considerations-00.txt > > has been successfully submitted by Tommy Pauly and posted to the > > IETF repository. > > > > Name: draft-per-app-networking-considerations > > Revision: 00 > > Title: Per-Application Networking Considerations > > Document date: 2020-11-15 > > Group: Individual Submission > > Pages: 7 > > URL: https://www.ietf.org/archive/id/draft-per-app-networking-considerations-00.txt > > Status: https://datatracker.ietf.org/doc/draft-per-app-networking-considerations/ > > Html: https://www.ietf.org/archive/id/draft-per-app-networking-considerations-00.html > > Htmlized: https://tools.ietf.org/html/draft-per-app-networking-considerations-00 > > > > > > Abstract: > > This document describes considerations for and implications of using > > application identifiers as a method of differentiating traffic on > > networks. Specifically, it discusses privacy considerations, > > possible mitigations, and considerations for user experience and API > > design. > > > > Discussion Venues > > > > This note is to be removed before publishing as an RFC. > > > > Source for this draft and an issue tracker can be found at > > https://github.com/tfpauly/per-app-networking-considerations. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- --- tte@cs.fau.de
- [Int-area] Per-Application Networking Considerati… Tommy Pauly
- Re: [Int-area] Per-Application Networking Conside… Luis M. Contreras
- Re: [Int-area] Per-Application Networking Conside… Toerless Eckert
- Re: [Int-area] Per-Application Networking Conside… Jiayihao