idnits 2.17.1 draft-thomson-tmi-03.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 778 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational 7 March 2022 5 Expires: 8 September 2022 7 Principles for the Involvement of Intermediaries in Internet Protocols 8 draft-thomson-tmi-03 10 Abstract 12 This document proposes a set of principles for designing protocols 13 with rules for intermediaries. The goal of these principles is to 14 limit the ways in which intermediaries can produce undesirable 15 effects and to protect the useful functions that intermediaries 16 legitimately provide. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Discussion of this document takes place on the IAB Model-T list 23 (modelt@iab.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/model-t/. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/martinthomson/tmi. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 8 September 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. What is Meant by Intermediary . . . . . . . . . . . . . . . . 3 64 3. Intermediation Is Essential . . . . . . . . . . . . . . . . . 4 65 4. Intermediation Is Useful . . . . . . . . . . . . . . . . . . 5 66 5. Intermediation Enables Scaling Of Control . . . . . . . . . . 5 67 6. Incentive Misalignment at Scale . . . . . . . . . . . . . . . 6 68 7. Forced and Unwanted Intermediation . . . . . . . . . . . . . 6 69 8. Contention over Intermediation . . . . . . . . . . . . . . . 7 70 9. Proposed Principles . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Prefer Services to Intermediaries . . . . . . . . . . . . 8 72 9.2. Deliberately Select Protocol Participants . . . . . . . . 9 73 9.3. Limit Capabilities of Intermediaries . . . . . . . . . . 10 74 9.3.1. Limit Information Exposure . . . . . . . . . . . . . 10 75 9.3.2. Limit Permitted Interactions . . . . . . . . . . . . 11 76 9.3.3. Costs of Technical Constraints . . . . . . . . . . . 11 77 10. Applying Non-Technical Constraints . . . . . . . . . . . . . 12 78 11. The Effect on Existing Practices . . . . . . . . . . . . . . 12 79 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 14. Informative References . . . . . . . . . . . . . . . . . . . 13 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 The Internet owes much of its success to its application of the end- 88 to-end principle [E2E]. The realization that efficiency is best 89 served by moving higher-level functions to endpoints is a key insight 90 in system design, but also a key element of the success of the 91 Internet. 93 This does not mean that the Internet avoids a relying on functions 94 provided by entities in the network. While the principle establishes 95 that some functions are best provided by endsystems, this does not 96 exclude all intermediary functions. Some level of function in the 97 network is necessary, or else there would be no network. The ways in 98 which intermediaries can assist protocol endpoints are numerous and 99 constantly evolving. 101 This document explores some of the ways in which intermediaries make 102 both essential and valuable contributions to the function of the 103 system. Problems arise when the interests of intermediaries are 104 poorly aligned with those of endpoints. This can result in systemic 105 costs and tension. Addressing those issues can be difficult. 107 This document proposes the following design principles for the 108 protocols that might involve the participation of intermediaries: 110 * Avoid intermediation (Section 9.1) 112 * Limit the entities that can intermediate (Section 9.2) 114 * Limit what intermediaries can do (Section 9.3) 116 These principles aim to provide clarity about the roles and 117 responsibilities of protocol participants. These principles produce 118 more robust protocols with better privacy and security properties. 119 These also limit the secondary costs associated with intermediation. 121 2. What is Meant by Intermediary 123 An intermediary is an element that participates in a protocol 124 exchange. An intermediary receives protocol units, such as packets 125 or messages, and forwards the protocol units to other protocol 126 participants. An intermediary might make changes to protocol units 127 or leave the content of the unit unchanged. 129 An intermediary often does not directly benefit from the protocol 130 exchange, but instead acts to facilitate the exchange. An 131 intermediary often participates at the request of another participant 132 in the protocol, which might be an endpoint or an intermediary. 134 Intermediaries exist at all layers of the stack. A router is an 135 intermediary that acts at the network layer to forward packets. A 136 TURN relay [RFC8155] provides similar forwarding capability for UDP 137 in the presence of a network address translator (NAT) - a different 138 type of intermediary that provides the ability to share a limited 139 supply of addresses. At higher layers of the stack, group messaging 140 servers intermediate the exchange of messages within groups of 141 people; a conference focus aids the sending of media group real-time 142 communications; and a social network intermediates communication and 143 information sharing through the exchange of messages and formation of 144 groups. 146 A person uses a networked computer as an intermediary for their 147 communications with other people and computers. This intermediation 148 is essential, for users are unable to directly interact with a 149 network. Much of the guidance in this document does not apply to the 150 relationship between users and user agents; see [RFC8890], 151 Section 4.2 in particular, for an examination of this topic. 153 An intermediary at one layer of the stack is often an endpoint for 154 communication at a lower layer. A Diameter peer [DIAMETER] acts as 155 an intermediary when it forwards requests to other peers. However, a 156 Diameter peer establishes connections to neighboring peers using TLS/ 157 TCP or DTLS/SCTP and acts as a endpoint for all of those protocols. 159 It is possible to facilitate communication without being an 160 intermediary. The DNS provides information that is critical to 161 locating and communicating with other Internet hosts, but it does so 162 without intermediating those communications. Thus, this definition 163 of intermediary does not necessarily include a service like the DNS. 164 Of course, the use of the DNS could involve engaging with 165 intermediaries such as recursive resolvers. 167 3. Intermediation Is Essential 169 Intermediaries are essential to scalable communications. The service 170 an intermediary provides usually involves access to resources that 171 would not otherwise be available. For instance, the Internet does 172 not function without routers that enable packets to reach other 173 networks. 175 There is some level of intermediation that is essential for the 176 proper functioning of the Internet. 178 Scalable solutions to the introduction problem often depend on 179 services that provide access to information and capabilities. As it 180 is with the network layer of the Internet, the use of an intermediary 181 can be absolutely essential. For example, a social networking 182 application acts as an intermediary that provides a communications 183 medium, content discovery and publication, and related services. 184 Video conferencing applications often depend on an intermediary that 185 mixes audio and selectively forwards video so that bandwidth 186 requirements don't increase beyond what is available for participants 187 as conferences grow in size. 189 4. Intermediation Is Useful 191 That intermediaries provide access to valuable resources does not 192 imply that all intermediaries have exclusive control over access to 193 resources. A router might provide access to other networks, but 194 similar access might be obtained via a different route. The same web 195 content might be provided by multiple CDNs. Multiple DNS resolvers 196 can provide answers to the same queries. The ability to access the 197 same capabilities from multiple entities contributes greatly to the 198 robustness of a system. 200 Intermediaries often provide capabilities that benefit from economies 201 of scale by providing a service that aggregates demand from multiple 202 individuals. For instance, individuals are unlikely to be in a 203 position to negotiate connections to multiple networks, but an ISP 204 can. Similarly, an individual might find it difficult to acquire the 205 capacity necessary to withstand a DDoS attack, but the scale at which 206 a CDN operates means that this capacity is likely available to it. 207 Or the value of a social network is in part due to the existing 208 participation of other people. 210 Aggregation also provides other potential benefits. For instance, 211 caching of shared information can allow for performance advantages. 212 From an efficiency perspective, the use of shared resources might 213 allow load to be more evenly distributed over time. For privacy, 214 individual activity might be mixed with the activity of many others, 215 thereby making it difficult to isolate that activity. 217 The ability of an intermediary to operate at scale can therefore 218 provide a number of different benefits to performance, scalability, 219 privacy, and other areas. 221 5. Intermediation Enables Scaling Of Control 223 An action by an intermediary can affect all who communicate using 224 that intermediary. For an intermediary that operates at scale, this 225 means it can be seen as an effective control point. 227 In addition to facilitating communications, some intermediary 228 deployments aim to effect a policy. This relies on the ability of a 229 well-placed intermediary to affect multiple protocol interactions and 230 participants. 232 The ability of an intermediary to affect a large number of network 233 users can be an advantage or vulnerability, depending on perspective. 234 For instance, network intermediaries have been used to distribute 235 warnings of impending natural disasters like fire, flood, or 236 earthquake, which save lives and property. In contrast, control over 237 large-scale communications can enable censorship [RFC7754], 238 misinformation [PARADOX], or pervasive monitoring [RFC7258]. 240 Intermediaries that can affect many people can therefore be powerful 241 agents for control. While the morality of actions taken can be 242 subjective, network users have to consider the potential for the 243 power they vest in intermediaries to be abused or subverted. 245 6. Incentive Misalignment at Scale 247 A dependency on an intermediary represents a risk to those that take 248 the dependency. The incentives and motives of intermediaries can be 249 important to consider when choosing to use an intermediary. 251 For instance, the information necessary for an intermediary to 252 performs its function can often be used (or abused) for other 253 purposes. Even the simple function of forwarding necessarily 254 involves information about who was communicating, when, and the size 255 of messages. This can reveal more than is obvious [CLINIC]. 257 As uses of networks become more diverse, the extent that incentives 258 for intermediaries and network users align reduce. In particular, 259 acceptance of the costs and risks associated with intermediation by a 260 majority of network users does not mean that all users have the same 261 expectations and requirements. This can be a significant problem if 262 it becomes difficult to avoid or refuse participation by a particular 263 intermediary. 265 A dependency on an intermediary, particularly a technically or 266 operationally challenging dependency, can reduce the number of viable 267 choices of intermediary operators. Reduced choice can lead to 268 dependence on specific intermediaries, which reduces resilience and 269 exposes endpoints to greater potential for abuse. 271 7. Forced and Unwanted Intermediation 273 The ability to act as intermediary can offer more options than a 274 service that is called upon to provide information. Sometimes those 275 advantages are enough to justify the use of intermediation over 276 alternative designs. However, the use of an intermediary also 277 introduces costs. 279 The use of transparent or interception proxies in HTTP [HTTP] is an 280 example of a practice that has fallen out of common usage due to 281 increased use of HTTPS. Use of transparent proxies was once 282 widespread with a wide variety of reasons for their deployment. 283 However, transparent proxies were involved in many abuses, such as 284 unwanted transcoding of content and insertion of identifiers to the 285 detriment of individual privacy. 287 Introducing intermediaries is often done with the intent of avoiding 288 disruption to protocols that operate a higher layer of the stack. 289 However, network layering abstractions often leak, meaning that the 290 effects of the intermediation can be observed. Where those effects 291 cause problems, it can be difficult to detect and fix those problems. 293 The insertion of an intermediary in a protocol imposes other costs on 294 other protocol participants; see [EROSION] or [MIDDLEBOX]. In 295 particular, poor implementations of intermediaries can adversely 296 affect protocol operation. 298 As an intermediary is another participant in a protocol, they can 299 make interactions less robust. Intermediaries can also be 300 responsible for ossification, or the inability to deploy new protocol 301 mechanisms; see Section 2.3 of [USE-IT]. For example, measurement of 302 TCP showed that the protocol has poor prospects for extensibility due 303 to widespread use - and poor implementation - of intermediaries 304 [TCP-EXTEND]. 306 8. Contention over Intermediation 308 The IETF has a long history of dealing with different forms of 309 intermediation poorly. 311 A debate about the intent and purpose of IPv6 extension headers 312 [IPv6] occurred prior to the publication of RFC 8986 [SRv6] and it's 313 PSP (Penultimate Segment Pop) mode. Here, the use of extension 314 headers by entities other than the communication endpoints -- that 315 is, intermediaries -- was contested. As the purpose of this feature 316 is to communicate routing information between intermediaries, this 317 could be seen as a form of tunneling between the communicating 318 routers that uses the ability of IPv6 intermediaries (or routers) to 319 add or remove extension headers. 321 Like HTTP, SIP [RFC3261] defines a role for a proxy, which is a form 322 of intermediary with limited ability to interact with the session 323 that it facilitates. In practice, many deployments instead choose to 324 deploy some form of Back-to-Back UA (B2BUA; [RFC7092]) for reasons 325 that effectively reduce to greater ability to implement control 326 functions. 328 There are several ongoing debates in the IETF that are rooted in 329 disagreement about the rule of intermediaries. The interests of 330 network-based devices -- which sometimes act as TLS intermediaries -- 331 is fiercely debated in the context of TLS 1.3 [TLS], where the design 332 renders certain practices obsolete. 334 It could be that the circumstances in each of these debates is 335 different enough that there is no singular outcome. The 336 complications resulting from large-scale deployments of great 337 diversity might render a single clear outcome impossible for an 338 established protocol. 340 9. Proposed Principles 342 Many problems caused by intermediation are the result of 343 intermediaries that are introduced without the involvement of 344 protocol endpoints. Limiting the extent to which protocol designs 345 depend on intermediaries makes the resulting system more robust. 347 These principles are set out in three stages: 349 1. Prefer designs without intermediaries (Section 9.1); 351 2. Failing that, control which entities can intermediate the 352 protocol (Section 9.2); and 354 3. Limit actions and information that are available to 355 intermediaries (Section 9.3). 357 The use of technical mechanisms to ensure that these principles are 358 enforced is necessary. It is expected that protocols will need to 359 use cryptography for this. 361 New protocol designs therefore need to identify what intermediation 362 is possible and what is desired. Technical mechanisms to guarantee 363 conformance, where possible, are highly recommended. 365 Modifying existing protocols to follow these principles could be 366 difficult, but worthwhile. 368 9.1. Prefer Services to Intermediaries 370 Protocols should prefer designs that do not involve additional 371 participants, such as intermediaries. 373 Designing protocols to use services rather than intermediaries 374 ensures that responsibilities of protocol participants are clearly 375 defined. Where functions can provided by means other than 376 intermediation, the design should prefer that alternative. 378 If there is a need for information, defining a means for querying a 379 service for that information is preferable to adding an intermediary. 380 Similarly, direct invocation of service to perform an action is 381 better than involving that service as a participant in the protocol. 383 Involving an entity as an intermediary can greatly increase the 384 degree to which that entity becomes a dependency. For example, it 385 might be necessary to negotiate the use of new capabilities with all 386 protocol participants, including the intermediary, even when the 387 functions for which the intermediary was added are not affected. It 388 is also more difficult to limit the extent to which a protocol 389 participant can be involved than a service that is invoked for a 390 specific task. 392 Using discrete services is not always the most performant 393 architecture as additional network interactions can add to overheads. 394 The cost of these overheads need to be weighed against the recurrent 395 costs from involving intermediaries. 397 The contribution of an intermediary to performance and efficiency can 398 involve trade-offs, such as those discussed in Section 2.3 of [E2E]. 399 One consideration is the potential need for critical functions to be 400 replicated in both intermediaries and endpoints, reducing efficiency. 401 Another is the possibility that an intermediary optimized for one 402 application could degrade performance in other applications. 404 Preferring services is analogous to the software design principle 405 that recommends a preference for composition over inheritance 406 [PATTERNS]. 408 9.2. Deliberately Select Protocol Participants 410 Protocol participants should know what other participants they might 411 be interacting with, including intermediaries. 413 Protocols that permit the involvement of an intermediary need to do 414 so intentionally and provide measures that prevent the addition of 415 unwanted intermediaries. Ideally, all protocol participants are 416 identified and known to other protocol participants. 418 The addition of an unwanted protocol participant is an attack on the 419 protocol. 421 This is an extension of the conclusion of [PATH-SIGNALS], which: 423 recommends that implicit signals should be avoided and that an 424 implicit signal should be replaced with an explicit signal only 425 when the signal's originator intends that it be used by the 426 network elements on the path. 428 Applying this principle likely requires the use of authentication and 429 encryption. 431 9.3. Limit Capabilities of Intermediaries 433 Protocol participants should be able to limit the capabilities 434 conferred to other protocol participants. 436 Where the potential for intermediation already exists, or 437 intermediaries provide essential functions, protocol designs should 438 limit the capabilities and information that protocol participants are 439 required to grant others. 441 Limiting the information that participants are required to provide to 442 other participants has benefits for privacy or to limit the potential 443 for misuse of information; see Section 9.3.1. Where confidentiality 444 is impossible or impractical, integrity protection can be used to 445 ensure that data origin authentication is preserved; see 446 Section 9.3.2. 448 9.3.1. Limit Information Exposure 450 Protocol participants should only have access to the information they 451 need to perform their designated function. 453 Protocol designs based on a principle of providing the minimum 454 information necessary have several benefits. In addition to 455 requiring smaller messages, or fewer exchanges, reducing information 456 provides greater control over exposure of information. This has 457 privacy benefits. 459 Where an intermediary needs to carry information that it has no need 460 to access, protocols should use encryption to ensure that the 461 intermediary cannot access that information. 463 Providing information for intermediaries using signals that are 464 separate from other protocol signaling is preferable [PATH-SIGNALS]. 465 In addition, integrity protection should be applied to these signals 466 to prevent modification. 468 9.3.2. Limit Permitted Interactions 470 An action should only be taken based on signals from protocol 471 participants that are authorized to request that action. 473 Where an intermediary needs to communicate with other protocol 474 participants, ensure that these signals are attributed to an 475 intermediary. Authentication is the best means of ensuring signals 476 generated by protocol participants are correctly attributed. 477 Authentication informs decisions protocol participants make about 478 actions they take. 480 In some cases, particularly protocols that are primarily two-party 481 protocols, it might be sufficient to allow the signal to be 482 attributed to any intermediary. This is the case in QUIC [QUIC] for 483 ECN [ECN] and ICMP [ICMP], both of which are assumed to be provided 484 by elements on the network path. Limited mechanisms exist to 485 authenticate these as signals that originate from path elements, 486 informing actions taken by endpoints. Consequently, the actions 487 taken in response to these signals is limited. 489 9.3.3. Costs of Technical Constraints 491 Moving from a protocol in which there are two participants (such as 492 [TLS]) to more than two participants can be more complex and 493 expensive to implement and deploy. 495 More generally, the application of technical measures to control how 496 intermediaries participate in a protocol incur costs that manifest in 497 several ways. Protocols are more difficult to design; 498 implementations are larger and more complex; and deployments might 499 suffer from added operational costs, higher computation loads, and 500 more bandwidth consumption. These costs are reflective of the true 501 cost of involving additional entities in protocols. In protocols 502 without technical measures to limit participation, these costs have 503 historically been borne by other protocol participants. 505 In general however, most protocols are able to reuse existing 506 mechanisms for cryptographic protection, such as TLS [TLS]. Adopting 507 something like TLS provides security properties that are well 508 understood and analyzed. Using a standardized solution enables use 509 of well-tested implementations that include optimizations and other 510 mitigations for these costs. 512 10. Applying Non-Technical Constraints 514 Not all intermediary functions can be tightly constrained. For 515 instance, as described in Section 6, some functions involve granting 516 intermediaries access to information that can be used for more than 517 its intended purpose. Applying strong technical constraints on how 518 that information is used might be infeasible or impossible. 520 The use of authentication allows for other forms of control on 521 intermediaries. Auditing systems or other mechanisms for ensuring 522 accountability can use authentication information. Authentication 523 can also enable the use of legal, social, or other types of control 524 that might cover any shortfall in technical measures. 526 11. The Effect on Existing Practices 528 The application of these principles can have an effect on existing 529 operational practices, particularly where they rely on protocols not 530 limiting intermediary access. Several documents have explored 531 aspects of this in detail: 533 * [RFC8404] describes effects of encryption on practices performed 534 by intermediaries; 536 * [RFC8517] describes a broader set of practices; 538 * [RFC9065] explores the effect on transport-layer intermediaries in 539 more detail; and 541 * [NS-IMPACT] examines the effect of TLS on operational network 542 security practices. 544 In all these documents, the defining characteristic is the move from 545 a system that lacked controls on participation to one in which 546 technical controls are deployed. In each case the protocols in 547 question provided no technical controls or only limited technical 548 controls that prevent the addition of intermediaries. This allowed 549 the deployment of techniques that involved the insertion of 550 intermediaries into sessions without permission or knowledge of other 551 protocol participants. By adding controls like encryption, these 552 practices are disrupted. Overall, the advantages derived from having 553 greater control and knowledge of other protocol participants 554 outweighs these costs. 556 The process of identifying critical functions for intermediaries is 557 ongoing. There are three potential classes of outcome of these 558 discussion: 560 * Practices might be deemed valuable and methods that allow limited 561 participation by intermediaries will be added to protocols. 563 * The use case supported by the practice might be deemed valuable, 564 but alternative methods that address the use case without the use 565 of an intermediary will be sought. 567 * Practices might be deemed harmful and no replacement mechanism 568 will be sought. 570 Many factors could influence the outcome of this analysis. For 571 instance, deployment of alternative methods or limited roles for 572 intermediaries could be relatively simple for new protocol 573 deployments; whereas it might be challenging to retrofit controls on 574 existing protocol deployments. 576 12. Security Considerations 578 Controlling the level of participation and access intermediaries have 579 is a security question. The principles in Section 9 are 580 fundamentally an application of a security principle: namely the 581 principle of least privilege [LEAST-PRIVILEGE]. 583 Lack of proper controls on intermediaries protocols has been the 584 source of significant security problems. One key example is where 585 protocols allow an intermediary to consume, modify, or generate 586 protocol units in ways that are contrary to the interests of other 587 protocol participants. 589 13. IANA Considerations 591 This document has no IANA actions. 593 14. Informative References 595 [CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know 596 Why You Went to the Clinic: Risks and Realization of HTTPS 597 Traffic Analysis", Privacy Enhancing Technologies pp. 598 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014, 599 . 601 [DIAMETER] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 602 Ed., "Diameter Base Protocol", RFC 6733, 603 DOI 10.17487/RFC6733, October 2012, 604 . 606 [E2E] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments 607 in system design", ACM Transactions on Computer 608 Systems Vol. 2, pp. 277-288, DOI 10.1145/357401.357402, 609 November 1984, . 611 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 612 of Explicit Congestion Notification (ECN) to IP", 613 RFC 3168, DOI 10.17487/RFC3168, September 2001, 614 . 616 [EROSION] Hildebrand, J. and P. McManus, "Erosion of the moral 617 authority of transparent middleboxes", Work in Progress, 618 Internet-Draft, draft-hildebrand-middlebox-erosion-01, 10 619 November 2014, . 622 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 623 Semantics", Work in Progress, Internet-Draft, draft-ietf- 624 httpbis-semantics-19, 12 September 2021, 625 . 628 [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, 629 RFC 792, DOI 10.17487/RFC0792, September 1981, 630 . 632 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 633 (IPv6) Specification", STD 86, RFC 8200, 634 DOI 10.17487/RFC8200, July 2017, 635 . 637 [LEAST-PRIVILEGE] 638 Saltzer, J., "Protection and the control of information 639 sharing in multics", Communications of the ACM Vol. 17, 640 pp. 388-402, DOI 10.1145/361011.361067, July 1974, 641 . 643 [MIDDLEBOX] 644 Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 645 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 646 . 648 [NS-IMPACT] 649 Cam-Winget, N., Wang, E., Danyliw, R., and R. DuToit, 650 "Impact of TLS 1.3 to Operational Network Security 651 Practices", Work in Progress, Internet-Draft, draft-ietf- 652 opsec-ns-impact-04, 26 January 2021, 653 . 656 [PARADOX] Valenzuela, S., Halpern, D., Katz, J., and J. Miranda, 657 "The Paradox of Participation Versus Misinformation: 658 Social Media, Political Engagement, and the Spread of 659 Misinformation", Digital Journalism Vol. 7, pp. 802-823, 660 DOI 10.1080/21670811.2019.1623701, June 2019, 661 . 663 [PATH-SIGNALS] 664 Hardie, T., Ed., "Transport Protocol Path Signals", 665 RFC 8558, DOI 10.17487/RFC8558, April 2019, 666 . 668 [PATTERNS] Gamma, E., Helm, R., Johnson, R., and J. Vlissides, 669 "Design Patterns: Elements of Reusable Object-Oriented 670 Software", 1994. 672 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 673 and Secure Transport", Work in Progress, Internet-Draft, 674 draft-ietf-quic-transport-34, 14 January 2021, 675 . 678 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 679 A., Peterson, J., Sparks, R., Handley, M., and E. 680 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 681 DOI 10.17487/RFC3261, June 2002, 682 . 684 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 685 Text on Security Considerations", BCP 72, RFC 3552, 686 DOI 10.17487/RFC3552, July 2003, 687 . 689 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 690 the Middle and the Future of End-to-End: Reflections on 691 the Evolution of the Internet Architecture", RFC 3724, 692 DOI 10.17487/RFC3724, March 2004, 693 . 695 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 696 Initiation Protocol (SIP) Back-to-Back User Agents", 697 RFC 7092, DOI 10.17487/RFC7092, December 2013, 698 . 700 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 701 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 702 2014, . 704 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 705 Nordmark, "Technical Considerations for Internet Service 706 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 707 March 2016, . 709 [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays 710 around NAT (TURN) Server Auto Discovery", RFC 8155, 711 DOI 10.17487/RFC8155, April 2017, 712 . 714 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 715 Pervasive Encryption on Operators", RFC 8404, 716 DOI 10.17487/RFC8404, July 2018, 717 . 719 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 720 Jacquenet, "An Inventory of Transport-Centric Functions 721 Provided by Middleboxes: An Operator Perspective", 722 RFC 8517, DOI 10.17487/RFC8517, February 2019, 723 . 725 [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, 726 DOI 10.17487/RFC8890, August 2020, 727 . 729 [RFC9065] Fairhurst, G. and C. Perkins, "Considerations around 730 Transport Header Confidentiality, Network Operations, and 731 the Evolution of Internet Transport Protocols", RFC 9065, 732 DOI 10.17487/RFC9065, July 2021, 733 . 735 [SRv6] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 736 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 737 (SRv6) Network Programming", RFC 8986, 738 DOI 10.17487/RFC8986, February 2021, 739 . 741 [TCP-EXTEND] 742 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 743 Handley, M., and H. Tokuda, "Is it still possible to 744 extend TCP?", Proceedings of the 2011 ACM SIGCOMM 745 conference on Internet measurement conference - IMC '11, 746 DOI 10.1145/2068816.2068834, 2011, 747 . 749 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 750 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 751 . 753 [USE-IT] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol 754 Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170, 755 December 2021, . 757 Appendix A. Acknowledgments 759 This document is merely an attempt to codify existing practice. 760 Practice that is inspired, at least in part, by prior work, including 761 [RFC3552] and [RFC3724] which both advocate for clearer articulation 762 of trust boundaries. 764 Jari Arkko, Eric Rescorla, and David Schinazi are acknowledged for 765 their contributions of thought, review, and text. 767 Author's Address 769 Martin Thomson 770 Mozilla 771 Email: mt@lowentropy.net