idnits 2.17.1 draft-per-app-networking-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (15 November 2020) is 1258 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-10 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-08 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Colitti 3 Internet-Draft Google 4 Intended status: Informational T. Pauly 5 Expires: 19 May 2021 Apple Inc. 6 15 November 2020 8 Per-Application Networking Considerations 9 draft-per-app-networking-considerations-00 11 Abstract 13 This document describes considerations for and implications of using 14 application identifiers as a method of differentiating traffic on 15 networks. Specifically, it discusses privacy considerations, 16 possible mitigations, and considerations for user experience and API 17 design. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Source for this draft and an issue tracker can be found at 24 https://github.com/tfpauly/per-app-networking-considerations. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 19 May 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 61 2. Requesting differential treatment . . . . . . . . . . . . . . 3 62 3. Open Internet implications . . . . . . . . . . . . . . . . . 4 63 4. Privacy implications . . . . . . . . . . . . . . . . . . . . 4 64 5. Mitigating implications via traffic categories . . . . . . . 5 65 6. User experience considerations . . . . . . . . . . . . . . . 6 66 7. API considerations . . . . . . . . . . . . . . . . . . . . . 6 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 There are a number of use cases where network operators, or 76 applications, might desire for application traffic to be treated 77 differently by the network. Some examples are: 79 * Network-specific services. Applications might want to access 80 local resources on a network that does not otherwise provide 81 Internet access (for example, an entertainment system on an 82 airplane). 84 * Per-application private networks. Certain applications, such as 85 enterprise applications, might want to connect directly to the 86 enterprise network in a secure fashion without using a device-wide 87 VPN. 89 * Mobile network services. In mobile networks, applications like 90 voice over LTE, IMS and RCS often use a different virtual network 91 than general Internet traffic. 93 * Applications with specific performance requirements. Certain 94 applications would benefit from particular scheduling or QoS 95 policies - for example applications requiring low latency such as 96 voice might be scheduled and queued differently from latency- 97 insensitive traffic. 99 * Local breakout. In a mobile networks, applications might want to 100 access resources through a different network interface (e.g., one 101 that uses IPv6 addresses that are local to a specific area, and do 102 not have a wide mobility). 104 * Zero-rating traffic. As allowed by regulators, certain classes of 105 traffic (e.g., messaging or streaming video) might be exempt from 106 metering on networks that are otherwise metered. 108 In existing networks, this is sometimes implemented by the network 109 using deep packet inspection (e.g., flow tracking coupled with 110 inspection of the SNI handshake). This is complex, implicates public 111 policy concerns, and generally conflicts with the recommendations in 112 [RFC7258]. The move towards encrypted protocols such as [RFC8484] 113 and [I-D.ietf-tls-esni] will make this more difficult for some 114 operators. Thus, if an application is to receive different 115 treatment, the host or the application itself should be involved in 116 requesting specific network treatment. This document explores the 117 implications. 119 In this document, the term "application" refers to an application as 120 understood by the user of the device. 122 1.1. Conventions and Definitions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. Requesting differential treatment 132 There are already mechanisms for applications to request and obtain 133 particular treatment by the network, or to communicate application 134 identity to the network in order to obtain particular treatment. 135 These include: 137 * Diffserv 139 * APN6 140 * Network tokens 142 * Slicing in 3GPP 5G networks 144 * Explicit application selection of a given Provisioning Domain 145 (PvD) [RFC8801] 147 3. Open Internet implications 149 In certain regulatory regions, networks that provide general Internet 150 access may not be permitted to discriminate between traffic sent to 151 or from different lawful applications or websites, or such 152 discrimination may be prohibited if commercially based. In a 153 situation where the network operator has influence on the 154 implementation of the user host (e.g., mobile networks where the 155 handset is sold by the carrier), the device may be able to implement 156 network policies directly, and thus may be impacted by neutrality 157 considerations. 159 Neutrality concerns can be addressed by providing user control over 160 assignment of particular applications to the particular network 161 resources available to that user. Further, network neutrality 162 implications may be reduced or avoided in some jurisdictions if the 163 differential treatment occurs between different classes of traffic 164 with different network requirements (e.g., bandwidth-intensive 165 traffic vs. low-latency traffic) as opposed to between different 166 applications with similar network requirements, and thus, by ensuring 167 that the mechanism used to communicate requests to the network only 168 specifies traffic classes and not individual applications. 170 4. Privacy implications 172 IETF guidance to avoid pervasive monitoring [RFC7258] is for network 173 protocols to expose as little information as possible. Some of the 174 proposed technologies for application signalling rely on the 175 application exposing its identity to the network so that the network 176 can then implement appropriate policies. This may provide the 177 network with much more information than is needed to implement the 178 desired behaviour. Information about which users are using specific 179 applications, or visiting certain destinations, and when, can be 180 highly privacy-sensitive. 182 Note that application identity can be exposed to the network even in 183 the absence of explicit signalling. For example, if the host were to 184 implement a network-set policy that requires that traffic from 185 application X be sent on a different network path than all other 186 traffic, the identity of application X would be exposed to the 187 network as soon as it sends traffic. 189 Privacy concerns may also be reduced or avoided if the mechanism to 190 request a different class of service only specifies the class of 191 service (e.g., "low latency" or "streaming video") instead of the 192 application originating the traffic. 194 In a situation where the network operator has influence over the 195 implementation of the user host, the operator can still impose 196 policies on what requests are possible - for example, the operator 197 might choose to limit access to specialized services such as carrier 198 messaging only to carrier applications. It is possible for such 199 policies to preserve privacy if the policies specify general 200 categories of traffic as opposed to specifying applications. 202 5. Mitigating implications via traffic categories 204 Many of these implications can be mitigated if the mechanism does not 205 request different treatment of a service for a particular 206 application, but instead specifies a general category of traffic, 207 especially one that is defined based on traffic properties rather 208 than commercial agreements. 210 Categories of traffic need to be sufficiently broad to not identify 211 individual applications, and should be general enough that details 212 about a user cannot be inferred merely by use of the category. 214 Consider the example a network that wants to provide differentiated 215 service for a role-playing game application that can take advantage 216 of a low-latency path. Several levels of categories could be 217 defined. The following list shows some examples, in order of 218 decreasing specificity: 220 1. Role-playing game 222 2. Game 224 3. Real-time/low-latency 226 The first category would not be an appropriate choice due to the 227 privacy implications of identifying what kind of game a user plays. 228 The second category is preferable, but the third is best since it 229 defines a way to manage the network traffic without identifying 230 anything about the content of the application. 232 Some use cases for traffic differentiation might need other kinds of 233 categories. For example, operators might wish to zero-rate 234 applications using categories based on payment tiers and rate- 235 limiting. 237 6. User experience considerations 239 Privacy and neutrality concerns can be mitigated if the host's user 240 is informed that particular applications are seeking or designated 241 for particular treatment and consents to it. In order for consent to 242 be meaningful, the user should be presented with a message that they 243 understand. It may be difficult to balance the goal of providing 244 complete and accurate information with the goal of ensuring that the 245 user understands the implications. 247 7. API considerations 249 It is desirable to provide an API layer that is not tied to specific 250 network technologies (e.g., URSP, VPN, etc.). Having applications 251 select a specific Provisioning Domain (PvD) could provide a useful 252 layer of abstraction, as described in [I-D.ietf-taps-interface]. 254 Any API should not involve revealing an application or user identity 255 to the network via metadata without network authentication. Instead, 256 the API should allow a given setting to be conditional on the 257 identity of the network. For example, an application should express 258 "use the zero-rated service for my app when on a particular carrier 259 network", instead of blindly saying "this is my application 260 identifier". 262 8. References 264 8.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, 268 DOI 10.17487/RFC2119, March 1997, 269 . 271 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 272 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 273 May 2017, . 275 8.2. Informative References 277 [I-D.ietf-taps-interface] 278 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 279 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 280 Pauly, "An Abstract Application Layer Interface to 281 Transport Services", Work in Progress, Internet-Draft, 282 draft-ietf-taps-interface-10, 2 November 2020, 283 . 286 [I-D.ietf-tls-esni] 287 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 288 Encrypted Client Hello", Work in Progress, Internet-Draft, 289 draft-ietf-tls-esni-08, 16 October 2020, 290 . 293 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 294 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 295 2014, . 297 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 298 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 299 . 301 [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. 302 Shao, "Discovering Provisioning Domain Names and Data", 303 RFC 8801, DOI 10.17487/RFC8801, July 2020, 304 . 306 Acknowledgments 308 Thanks to Adi Masputra and Elliot Briggs for their inputs to this 309 discussion. 311 Authors' Addresses 313 Lorenzo Colitti 314 Google 315 Shibuya 3-21-3, 316 Japan 318 Email: lorenzo@google.com 320 Tommy Pauly 321 Apple Inc. 322 One Apple Park Way 323 Cupertino, California 95014, 324 United States of America 326 Email: tpauly@apple.com