idnits 2.17.1 draft-arkko-iab-path-signals-collaboration-00.txt: -(8): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 are 3 instances 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 date (12 July 2021) is 1019 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-quic-manageability-12 == Outdated reference: A later version (-02) exists of draft-thomson-http-oblivious-01 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational T. Hardie 5 Expires: 13 January 2022 Cisco 6 T. Pauly 7 Apple 8 M. Kühlewind 9 Ericsson 10 12 July 2021 12 Considerations on Application - Network Collaboration Using Path Signals 13 draft-arkko-iab-path-signals-collaboration-00 15 Abstract 17 Encryption and other security mechanisms are on the rise on all 18 layers of the stack, protecting user data and making network 19 operations more secured. Further, encryption is also a tool to 20 address ossification that has been observed on various layers of the 21 stack over time. Separation of functions into layers and enforcement 22 of layer boundaries based on encryption supports selected exposure to 23 those entities that are addressed by a function on a certain layer. 24 A clear separation supports innovation and also enables new 25 opportunities for collaborative functions. RFC 8558 describes path 26 signals as messages to or from on-path elements. This document 27 states principles for designing mechanisms that use or provide path 28 signals and calls for actions on specific valuable cases. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 13 January 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Past Guidance . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Intentional Distribution . . . . . . . . . . . . . . . . 6 67 3.2. Minimum Set of Entities . . . . . . . . . . . . . . . . . 7 68 3.3. Consent of Parties . . . . . . . . . . . . . . . . . . . 7 69 3.4. Minimum Information . . . . . . . . . . . . . . . . . . . 8 70 3.5. Protecting Information and Authentication . . . . . . . . 9 71 4. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 73 6. Informative References . . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 Encryption, besides its important role in security in general, 79 provides a tool to control information access and protects again 80 ossification by avoiding unintended dependencies and requiring active 81 maintenance. The increased deployment of encryption provides an 82 opportunity to reconsider parts of Internet architecture that have 83 rather used implicit derivation of input signals for on-path 84 functions than explicit signaling, as recommended by RFC 8558 85 [RFC8558]. 87 RFC 8558 defines the term path signals as signals to or from on-path 88 elements. Today path signals are often implicit, e.g. derived from 89 in-clear end-to-end information by e.g. examining transport 90 protocols. For instance, on-path elements use various fields of the 91 TCP header [RFC0793] to derive information about end-to-end latency 92 as well as congestion. These techniques have evolved because the 93 information was simply available and use of this information is 94 easier and therefore also cheaper than any explicit and potentially 95 complex cooperative approach. 97 As such, applications and networks have evolved their interaction 98 without comprehensive design for how this interaction should happen 99 or which information would be desired for a certain function. This 100 has lead to a situation where sometimes information is used that 101 maybe incomplete or incorrect or often indirectly only derives the 102 information that was actually desired. Further, dependencies on 103 information and mechanisms that were designed for a different 104 function limits the evolvability of the original intends. 106 This kind of interaction ends up having several negative effects: 108 * Ossifying protocols by introducing unintended parties that may not 109 be updating 111 * Creating systemic incentives against deploying more secure or 112 private versions of protocols 114 * Basing network behaviour on information that may be incomplete or 115 incorrect 117 * Creating a model where network entities expect to be able to use 118 rich information about sessions passing through 120 For instance, features such as DNS resolution or TLS setup have been 121 used beyond their original intent, such as name filtering, MAC 122 addresses used for access control, captive portal implementations 123 that employ taking over cleartext HTTP sessions, and so on. 125 Increased deployment of encryption can and will change this 126 situation. E.g. QUIC replaces TCP for various application and 127 protects all end-to-end signals to only be accessible by the 128 endpoint, ensuring evolvability [RFC9000]. QUIC does expose 129 information dedicated for on-path elements to consume by design 130 explicit signal for specific use cases, such as the Spin bit for 131 latency measurements or connection ID that can be used by load 132 balancers [I-D.ietf-quic-manageability] but information is limited to 133 only those use cases. Each new use cases requires additional action. 135 Such explicit signals that are specifically designed for the use of 136 on-path function, while all other information is appropriately 137 protected, enables an architecturally clean approach with the aims to 138 use and manage the existing network infrastructure most efficiently 139 as well as improve the quality of experience for those this 140 technology is build for - the user. 142 This draft discusses different approaches for explicit collaboration 143 and provides guidance on architectural principles to design new 144 mechanisms. Section 2 discusses past guidance, Section 3 principles 145 that good design can follow, along with some examples as well 146 explanation of situations that not following these principles can 147 lead to. Section 4 points to topics that need more to be looked at 148 more carefully before any guidance can be given. 150 2. Past Guidance 152 Incentives are a well understood problem in general but perhaps not 153 fully internalised for various designs attempting to establish 154 collaboration between applications and path elements. The principle 155 is that both receiver and sender of information must acquire tangible 156 and immediate benefits from the communication, such as improved 157 performance. 159 A related issue is understanding whether a business model or 160 ecosystem change is needed. Some designs may work well without any 161 monetary or payment or cross-administrative domains agreements. For 162 instance, I could ask my packets to be prioritised relative to each 163 other and that shouldn't affect anything else. Some other designs 164 may require a matching business ecosystem change to support what is 165 being proposed, and may be much harder to achieve. For instance, 166 requesting prioritisation over other people's traffic may imply that 167 you have to pay for that which may not be easy even for a single 168 provider let alone across many. 170 But on to more technical aspects. 172 The main guidance in [RFC8558] is to be aware that implicit signals 173 will be used whether intended or not. Protocol designers should 174 consider either hiding these signals when the information should not 175 be visible, or using explicit signals when it should be. 177 [I-D.irtf-panrg-what-not-to-do] discusses many past failure cases, a 178 catalogue of past issues to avoid. It also provides relevant 179 guidelines for new work, from discussion of incentives to more 180 specific observations, such as the need for outperforming end-to-end 181 mechanisms (Section 4.4), considering the need for per-connection 182 state (Section 4.6), taking into account the latency involved in 183 reacting to distant signals, and so on. 185 There are also more general guidance documents, e.g., [RFC5218] 186 discusses protocol successes and failures, and provides general 187 advice on incremental deployability etc. Internet Technology 188 Adoption and Transition (ITAT) workshop report [RFC7305] is also 189 recommended reading on this same general topic. And [RFC6709] 190 discusses protocol extensibility, and provides general advice on the 191 importance of global interoperability and so on. 193 3. Principles 195 This section attempts to provide some architecture-level principles 196 that would help future designers and recommend useful models to 197 apply. 199 A large number of our protocol mechanisms today fall into one of two 200 categories: authenticated and private communication that is only 201 visible by the end-to-end nodes; and unauthenticated public 202 communication that is visible to all nodes on a path. RFC 8558 203 explores the line between data that is protected and path signals. 205 There is a danger in taking a position that is too extreme towards 206 either exposing all information to the path, or hiding all 207 information from the path. Exposed information encourages pervasive 208 monitoring, which is described in RFC 7258 [RFC7258]. 210 But a lack of all path signaling, on the other hand, may be harmful 211 to network management, debugging, or the ability for networks to 212 provide the most efficient services. There are many cases where 213 elements on the network path can provide beneficial services, but 214 only if they can coordinate with the endpoints. This tradeoff 215 between privacy and network functions has in some cases led to an 216 adversarial stance between privacy and the ability for the network 217 path to provide intended functions. It also affects the ability of 218 service providers and others observe why problems occur 219 [I-D.iab-covid19-workshop]. 221 One way to resolve this conflict is to add more explicit trust and 222 coordination between endpoints and network devices. VPNs are a good 223 example of a case where there is an explicit authentication and 224 negotiation with a network path element that's used to optimize 225 behavior or gain access to specific resources. 227 The goal of improving privacy and trust on the Internet does not 228 necessarily need to remove the ability for network elements to 229 perform beneficial functions. We should instead improve the way that 230 these functions are achieved. Our goals should be: 232 * To ensure that information is distributed intentionally, not 233 accidentally; 235 * to understand the privacy and other implications of any 236 distributed information; and 238 * to gate the distribution of information on the consent of the 239 relevant parties 241 These goals for distribution apply equally to senders, receivers, and 242 path elements. 244 We can establish some basic questions that any new network path 245 functions should consider: 247 * What is the minimum set of entities that need to be involved? 249 * What is the minimum information each entity in this set needs? 251 * Which entities must consent to the information exchange? 253 If we look at many of the ways network path functions are achieved 254 today, we find that many if not most of them fall short the standard 255 set up by the questions above. Too often, they rely on information 256 being sent without limiting the scope of distribution or providing 257 any negotiation or consent. 259 Going forward, new standards work in the IETF needs to focus on 260 addressing this gap by providing better alternatives and mechanisms 261 for providing path functions. Note that not all of these functions 262 can be achieved in a way that preserves a high level of user privacy 263 from the network; in such cases, it is incumbent upon us to not 264 ignore the use case, but instead to define the high bar for consent 265 and trust, and thus define a limited applicability for those 266 functions. 268 3.1. Intentional Distribution 270 This guideline is best expressed in RFC 8558: 272 "Fundamentally, this document recommends that implicit signals should 273 be avoided and that an implicit signal should be replaced with an 274 explicit signal only when the signal's originator intends that it be 275 used by the network elements on the path. For many flows, this may 276 result in the signal being absent but allows it to be present when 277 needed." 279 Intentional distribution applies to other informal flow directions as 280 well. For instance, a network element should not unintentionally 281 leak information that is visible to endpoints. An explicit decision 282 is needed for a specific information to be provided, along with 283 analysis of the security and privacy implications of that 284 information. 286 3.2. Minimum Set of Entities 288 It is recommended that a design identify the minimum number of 289 entities needed to share a specific signal required for an identified 290 function. In some cases this will be a very limited set, e.g. when 291 the application needs to provide a signal to a specific gateway 292 function. In other cases, such as congestion control, a signal might 293 be shared with every router along the path, since each should be 294 aware of the congestion. 296 3.3. Consent of Parties 298 Consent and trust must determine the distribution of information. 299 The set of entities that need to consent is determined by the scope 300 and specificity of the information being shared. 302 Three distinct types of consent are recommended for collaboration or 303 information sharing: 305 * A corollary of the intentional distribution is that the sender 306 needs to agree to sending the information. Or that the requester 307 for an action needs to agree to make a request; it should not be 308 an implicit decision by the receiver that information was sent or 309 a request was made, just because a packet happened to be formed in 310 a particular way. 312 * At the same time, the recipient of information or the target of a 313 request should agree to wishing to receive the information. It 314 should not be burdened with extra processing if it does not have 315 willigness or a need to do so. This happens naturally in most 316 protocol designs, but has been a problem for some cases where 317 "slow path" packet processing is required or implied, and the 318 recipient or router did not have willingness for this. 320 * Internet communications are not made for the applications, they 321 are ultimately made on behalf of users. Information relating to 322 the users is something that both networks and applications should 323 be careful with, and not be shared without the user's consent. 324 This is not always easy, as the interests of the user and (for 325 instance) application developer may not always be inline; some 326 applications may wish to collect more information about the user 327 than the user would like. 329 3.4. Minimum Information 331 Parties should provide only the information that is needed for the 332 other party to perform the collaboration task that is desired by this 333 party, and not more. This applies to information sent by an 334 application about itself, information sent about users, or 335 information sent by the network. 337 An architecture can follow the guideline from RFC 8558 in using 338 explicit signals, but still fail to differentiate properly between 339 information that should be kept private and information that should 340 be shared. 342 In looking at what information can or cannot easily be passed, we can 343 look at both information from the network to the application, and 344 from the application to the network. 346 For the application to the network direction, user-identifying 347 information can be problematic for privacy and tracking reasons. 348 Similarly, application identity can be problematic, if it might form 349 the basis for prioritization or discrimination that the that 350 application provider may not wish to happen. It may also have 351 undesirable economic consequences, such as extra charges for the 352 consumer from a priority service where a regular service would have 353 worked. 355 On the other hand, as noted above, information about general classes 356 of applications may be desirable to be given by application 357 providers, if it enables prioritization that would improve service, 358 e.g., differentiation between interactive and non-interactive 359 services. 361 For the network to application direction there is similarly sensitive 362 information, such as the precise location of the user. On the other 363 hand, various generic network conditions, predictive bandwidth and 364 latency capabilities, and so on might be attractive information that 365 applications can use to determine, for instance, optimal strategies 366 for changing codecs. However, information given by the network about 367 load conditions and so on should not form a mechanism to provide a 368 side-channel into what other users are doing. 370 While information needs to be specific and provided on a per-need 371 basis, it is often beneficial to provide declarative information 372 that, for instance, expresses application needs than makes specific 373 requests for action. 375 3.5. Protecting Information and Authentication 377 Some simple forms of information often exist in cleartext form, e.g, 378 ECN bits from routers are generally not authenticated or integrity 379 protected. This is possible when the information exchanges are 380 advisory in their nature, and do not carry any significantly 381 sensitive information from the parties. 383 In other cases it may be necessary to establish a secure channel for 384 communication with a specific other party, e.g., between a network 385 element and an application. This channel may need to be 386 authenticated, integrity protected and encrypted. This is necessary, 387 for instance, if the particular information or request needs to be 388 share in confidency only with a particular, trusted node, or there's 389 a danger of an attack where someone else may forge messages that 390 could endanger the communication. 392 However, it is important to note that authentication does not equal 393 trust. Whether a communication is with an application server or 394 network element that can be shown to be associated with a particular 395 domain name, it does not follow that information about the user can 396 be safely sent to it. 398 In some cases, the ability of a party to show that it is on the path 399 can be beneficial. For instance, an ICMP error that refers to a 400 valid flow may be more trustworthy than any ICMP error claiming to 401 come from an address. 403 Other cases may require more substantial assurances. For instance, a 404 specific trust arrangement may be established between a particular 405 network and application. Or technologies such as confidential 406 computing can be applied to provide an assurance that information 407 processed by a party is handled in an appropriate manner. 409 4. Further Work 411 This is a developing field, and it is expected that our understanding 412 continues to grow. The recent changes with regards to much higher 413 use of encryption at different protocol layers, the consolidation or 414 more and more traffic to the same destinations, and so on have also 415 greatly impacted the field. 417 While there are some examples of modern, well-designed collaboration 418 mechanisms, clearly more work is needed. Many complex cases would 419 require significant developments in order to become feasible. 421 Some of the most difficult areas are listed below. Research on these 422 topics would be welcome. 424 * Business arrangements. Many designs - for instance those related 425 to quality-of-service - involve an expectation of paying for a 426 service. This is possible and has been successful within 427 individual domains, e.g., users can pay for higher data rates or 428 data caps in their ISP networks. However, it is a business-wise 429 much harder proposition for end-to-end connections across multiple 430 administrative domains [Claffy2015] 431 [I-D.irtf-panrg-what-not-to-do]. 433 * Secure communications with path elements. This has been a 434 difficult topic, both from the mechanics and scalability point 435 view, but also because there is no easy way to find out which 436 parties to trust or what trust roots would be appropriate. Some 437 application-network element interaction designs have focused on 438 information (such as ECN bits) that is distributed openly within a 439 path, but there are limited examples of designs with secure 440 information exchange with specific nodes. 442 * The use of path signals for reducing the effects of denial-of- 443 service attacks, e.g., in the form of modern "source quench" 444 designs. 446 * Ways of protecting information when held by network elements or 447 servers, beyond communications security. For instance, host 448 applications commonly share sensitive information about the user's 449 actions with other nodes, starting from basic data such as domain 450 names learned by DNS infrastructure or source and destination 451 addresses and protocol header information learned by all routers 452 on the path, to detailed end user identity and other information 453 learned by the servers. Some solutions are starting to exist for 454 this but are not widely deployed, at least not today [Oblivious] 455 [PDoT] [I-D.arkko-dns-confidential] [I-D.thomson-http-oblivious]. 456 These solutions address also very specific parts of the issue, and 457 more work remains. 459 * Sharing information from networks to applications. Some proposals 460 have been made in this space (see, e.g., 461 [I-D.flinck-mobile-throughput-guidance]) but there are no 462 successful or deployed mechanisms today. 464 5. Acknowledgments 466 The authors would like to thank everyone at the IETF, the IAB, and 467 our day jobs for interesting thoughts and proposals in this space. 468 Fragments of this document were also in 469 [I-D.per-app-networking-considerations] and 470 [I-D.arkko-path-signals-information] that were published earlier. We 471 would also like to acknowledge [I-D.trammell-stackevo-explicit-coop] 472 for presenting similar thoughts. 474 6. Informative References 476 [Claffy2015] 477 kc Claffy, . and D. Clark, "Adding Enhanced Services to 478 the Internet: Lessons from History", TPRC 43: The 43rd 479 Research Conference on Communication, Information and 480 Internet Policy Paper , April 2015. 482 [I-D.arkko-dns-confidential] 483 Arkko, J. and J. Novotny, "Privacy Improvements for DNS 484 Resolution with Confidential Computing", Work in Progress, 485 Internet-Draft, draft-arkko-dns-confidential-02, 2 July 486 2021, . 489 [I-D.arkko-path-signals-information] 490 Arkko, J., "Considerations on Information Passed between 491 Networks and Applications", Work in Progress, Internet- 492 Draft, draft-arkko-path-signals-information-00, 22 493 February 2021, . 496 [I-D.flinck-mobile-throughput-guidance] 497 Jain, A., Terzis, A., Flinck, H., Sprecher, N., 498 Arunachalam, S., Smith, K., Devarapalli, V., and R. B. 499 Yanai, "Mobile Throughput Guidance Inband Signaling 500 Protocol", Work in Progress, Internet-Draft, draft-flinck- 501 mobile-throughput-guidance-04, 13 March 2017, 502 . 505 [I-D.iab-covid19-workshop] 506 Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins, 507 "Report from the IAB COVID-19 Network Impacts Workshop 508 2020", Work in Progress, Internet-Draft, draft-iab- 509 covid19-workshop-03, 5 May 2021, 510 . 513 [I-D.ietf-quic-manageability] 514 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 515 Transport Protocol", Work in Progress, Internet-Draft, 516 draft-ietf-quic-manageability-12, 30 June 2021, 517 . 520 [I-D.irtf-panrg-what-not-to-do] 521 Dawkins, S., "Path Aware Networking: Obstacles to 522 Deployment (A Bestiary of Roads Not Taken)", Work in 523 Progress, Internet-Draft, draft-irtf-panrg-what-not-to-do- 524 19, 26 March 2021, . 527 [I-D.per-app-networking-considerations] 528 Colitti, L. and T. Pauly, "Per-Application Networking 529 Considerations", Work in Progress, Internet-Draft, draft- 530 per-app-networking-considerations-00, 15 November 2020, 531 . 534 [I-D.thomson-http-oblivious] 535 Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 536 Progress, Internet-Draft, draft-thomson-http-oblivious-01, 537 21 February 2021, . 540 [I-D.trammell-stackevo-explicit-coop] 541 Trammell, B., "Architectural Considerations for Transport 542 Evolution with Explicit Path Cooperation", Work in 543 Progress, Internet-Draft, draft-trammell-stackevo- 544 explicit-coop-00, 23 September 2015, 545 . 548 [Oblivious] 549 Schmitt, P., "Oblivious DNS: Practical privacy for DNS 550 queries", Proceedings on Privacy Enhancing Technologies 551 2019.2: 228-244 , 2019. 553 [PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private 554 DNS-over-TLS with TEE Support", Digit. Threat.: Res. 555 Pract., Vol. 2, No. 1, Article 3, 556 https://dl.acm.org/doi/fullHtml/10.1145/3431171 , February 557 2021. 559 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 560 RFC 793, DOI 10.17487/RFC0793, September 1981, 561 . 563 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 564 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 565 . 567 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 568 Considerations for Protocol Extensions", RFC 6709, 569 DOI 10.17487/RFC6709, September 2012, 570 . 572 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 573 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 574 2014, . 576 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 577 Technology Adoption and Transition (ITAT)", RFC 7305, 578 DOI 10.17487/RFC7305, July 2014, 579 . 581 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 582 RFC 8558, DOI 10.17487/RFC8558, April 2019, 583 . 585 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 586 Multiplexed and Secure Transport", RFC 9000, 587 DOI 10.17487/RFC9000, May 2021, 588 . 590 Authors' Addresses 592 Jari Arkko 593 Ericsson 595 Email: jari.arkko@ericsson.com 597 Ted Hardie 598 Cisco 600 Email: ted.ietf@gmail.com 602 Tommy Pauly 603 Apple 605 Email: tpauly@apple.com 606 Mirja Kühlewind 607 Ericsson 609 Email: mirja.kuehlewind@ericsson.com