idnits 2.17.00 (12 Aug 2021) /tmp/idnits56551/draft-thomson-tmi-02.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 (6 July 2021) is 318 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-16 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 == Outdated reference: draft-ietf-tsvwg-transport-encrypt has been published as RFC 9065 == Outdated reference: draft-iab-use-it-or-lose-it has been published as RFC 9170 Summary: 0 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 M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational 6 July 2021 5 Expires: 7 January 2022 7 Principles for the Involvement of Intermediaries in Internet Protocols 8 draft-thomson-tmi-02 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 7 January 2022. 46 Copyright Notice 48 Copyright (c) 2021 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 Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . 16 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 A protocol intermediary is an element that participates in 124 communications. An intermediary is not the primary initiator or 125 recipient of communications, but instead acts to facilitate 126 communications. 128 An intermediary need not be explicitly present at the request of a 129 participant. 131 Intermediaries exist at all layers of the stack. A router is an 132 intermediary that acts at the network layer to forward packets. A 133 TURN relay [RFC8155] provides similar forwarding capability for UDP 134 in the presence of a network address translator (NAT) - a different 135 type of intermediary that provides the ability to share a limited 136 supply of addresses. At higher layers of the stack, group messaging 137 servers intermediate the exchange of messages within groups of 138 people; a conference focus aids the sending of media group real-time 139 communications; and a social network intermediates communication and 140 information sharing through the exchange of messages and formation of 141 groups. 143 It is possible to facilitate communication without being an 144 intermediary. The DNS provides information that is critical to 145 locating and communicating with other Internet hosts, but it does so 146 without intermediating those communications. Thus, this definition 147 of intermediary does not include services like the DNS. That said, 148 though the DNS as a service does not result in intermediation of 149 other activities, there are roles for intermediaries within the DNS 150 that fit this definition, such as recursive resolvers. 152 3. Intermediation Is Essential 154 Intermediaries are essential to scalable communications. The service 155 an intermediary provides usually involves access to resources that 156 would not otherwise be available. For instance, the Internet does 157 not function without routers that enable packets to reach other 158 networks. 160 Thus, there is some level of intermediation that is essential for the 161 proper functioning of the Internet. 163 Scalable solutions to the introduction problem often depend on 164 services that provide access to information and capabilities. As it 165 is with the network layer of the Internet, the use of an intermediary 166 can be absolutely essential. For example, a social networking 167 application acts as an intermediary that provides a communications 168 medium, content discovery and publication, and related services. 169 Video conferencing applications often depend on an intermediary that 170 mixes audio and selectively forwards video so that bandwidth 171 requirements don't increase beyond what is available for participants 172 as conferences grow in size. 174 4. Intermediation Is Useful 176 That intermediaries provide access to valuable resources does not 177 imply that all intermediaries have exclusive control over access to 178 resources. A router might provide access to other networks, but 179 similar access might be obtained via a different route. The same web 180 content might be provided by multiple CDNs. Multiple DNS resolvers 181 can provide answers to the same queries. The ability to access the 182 same capabilities from multiple entities contributes greatly to the 183 robustness of a system. 185 Intermediaries often provide capabilities that benefit from economies 186 of scale by providing a service that aggregates demand from multiple 187 individuals. For instance, individuals are unlikely to be in a 188 position to negotiate connections to multiple networks, but an ISP 189 can. Similarly, an individual might find it difficult to acquire the 190 capacity necessary to withstand a DDoS attack, but the scale at which 191 a CDN operates means that this capacity is likely available to it. 192 Or the value of a social network is in part due to the existing 193 participation of other people. 195 Aggregation also provides other potential benefits. For instance, 196 caching of shared information can allow for performance advantages. 197 From an efficiency perspective, the use of shared resources might 198 allow load to be more evenly distributed over time. For privacy, 199 individual activity might be mixed with the activity of many others, 200 thereby making it difficult to isolate that activity. 202 The ability of an intermediary to operate at scale can therefore 203 provide a number of different benefits to performance, scalability, 204 privacy, and other areas. 206 5. Intermediation Enables Scaling Of Control 208 An action by an intermediary can affect all who communicate using 209 that intermediary. For an intermediary that operates at scale, this 210 means it can be seen as an effective control point. 212 The goal of some intermediary deployments is to effect a policy, 213 relying on the ability of a well-placed intermediary to affect 214 multiple protocol interactions and participants. 216 The ability of an intermediary to affect a large number of network 217 users can be an advantage or vulnerability, depending on perspective. 218 For instance, network intermediaries have been used to distribute 219 warnings of impending natural disasters like fire, flood, or 220 earthquake, which save lives and property. In contrast, control over 221 large-scale communications can enable censorship [RFC7754], 222 misinformation, or pervasive monitoring [RFC7258]. 224 Intermediaries that can affect many people can therefore be powerful 225 agents for control. While the morality of actions taken can be 226 subjective, network users have to consider the potential for the 227 power they vest in intermediaries to be abused or subverted. 229 6. Incentive Misalignment at Scale 231 A dependency on an intermediary represents a risk to those that take 232 the dependency. The incentives and motives of intermediaries can be 233 important to consider when choosing to use an intermediary. 235 For instance, the information necessary for an intermediary to 236 performs its function can often be used (or abused) for other 237 purposes. Even the simple function of forwarding necessarily 238 involves information about who was communicating, when, and the size 239 of messages. This can reveal more than is obvious [CLINIC]. 241 As uses of networks become more diverse, the extent that incentives 242 for intermediaries and network users align reduce. In particular, 243 acceptance of the costs and risks associated with intermediation by a 244 majority of network users does not mean that all users have the same 245 expectations and requirements. This can be a significant problem if 246 it becomes difficult to avoid or refuse participation by a particular 247 intermediary. 249 A dependency on an intermediary, particularly a technically or 250 operationally challenging dependency, can reduce the number of viable 251 choices of intermediary operators. Reduced choice can lead to 252 dependence on specific intermediaries, which reduces resilience and 253 exposes endpoints to greater potential for abuse. 255 7. Forced and Unwanted Intermediation 257 The ability to act as intermediary can offer more options than a 258 service that is called upon to provide information. Sometimes those 259 advantages are enough to justify the use of intermediation over 260 alternative designs. However, the use of an intermediary also 261 introduces costs. 263 The use of transparent or interception proxies in HTTP [HTTP] is an 264 example of a practice that has fallen out of common usage due to 265 increased use of HTTPS. Use of transparent proxies was once 266 widespread with a wide variety of reasons for their deployment. 267 However, transparent proxies were involved in many abuses, such as 268 unwanted transcoding of content and insertion of identifiers to the 269 detriment of individual privacy. 271 Introducing intermediaries is often done with the intent of avoiding 272 disruption to protocols that operate a higher layer of the stack. 273 However, network layering abstractions often leak, meaning that the 274 effects of the intermediation can be observed. Where those effects 275 cause problems, it can be difficult to detect and fix those problems. 277 The insertion of an intermediary in a protocol imposes other costs on 278 other protocol participants; see [EROSION] or [MIDDLEBOX]. In 279 particular, poor implementations of intermediaries can adversely 280 affect protocol operation. 282 As an intermediary is another participant in a protocol, they can 283 make interactions less robust. Intermediaries can also be 284 responsible for ossification, or the inability to deploy new protocol 285 mechanisms; see Section 2.3 of [USE-IT]. For example, measurement of 286 TCP showed that the protocol has poor prospects for extensibility due 287 to widespread use - and poor implementation - of intermediaries 288 [TCP-EXTEND]. 290 8. Contention over Intermediation 292 The IETF has a long history of dealing with different forms of 293 intermediation poorly. 295 A debate about the intent and purpose of IPv6 extension headers 296 [IPv6] occurred prior to the publication of RFC 8986 [SRv6] and it's 297 PSP (Penultimate Segment Pop) mode. Here, the use of extension 298 headers by entities other than the communication endpoints -- that 299 is, intermediaries -- was contested. As the purpose of this feature 300 is to communicate routing information between intermediaries, this 301 could be seen as a form of tunneling between the communicating 302 routers that uses the ability of IPv6 intermediaries (or routers) to 303 add or remove extension headers. 305 Like HTTP, SIP [RFC3261] defines a role for a proxy, which is a form 306 of intermediary with limited ability to interact with the session 307 that it facilitates. In practice, many deployments instead choose to 308 deploy some form of Back-to-Back UA (B2BUA; [RFC7092]) for reasons 309 that effectively reduce to greater ability to implement control 310 functions. 312 There are several ongoing debates in the IETF that are rooted in 313 disagreement about the rule of intermediaries. The interests of 314 network-based devices - which are sometimes intermediaries - is 315 fiercely debated in the context of TLS 1.3 [TLS], where the design 316 renders certain practices obsolete. 318 It could be that the circumstances in each of these debates is 319 different enough that there is no singular outcome. The 320 complications resulting from large-scale deployments of great 321 diversity might render a single clear outcome impossible for an 322 established protocol. 324 9. Proposed Principles 326 Many problems caused by intermediation are the result of 327 intermediaries that are introduced without the involvement of 328 protocol endpoints. Limiting the extent to which protocol designs 329 depend on intermediaries makes the resulting system more robust. 331 These principles are set out in three stages: 333 1. Prefer designs without intermediaries (Section 9.1); 335 2. Failing that, control which entities can intermediate the 336 protocol (Section 9.2); and 338 3. Limit actions and information that are available to 339 intermediaries (Section 9.3). 341 The use of technical mechanisms to ensure that these principles are 342 enforced is necessary. It is expected that protocols will need to 343 use cryptography for this. 345 New protocol designs therefore need to identify what intermediation 346 is possible and what is desired. Technical mechanisms to guarantee 347 conformance, where possible, are highly recommended. 349 Modifying existing protocols to follow these principles could be 350 difficult, but worthwhile. 352 9.1. Prefer Services to Intermediaries 354 Protocols should prefer designs that do not involve additional 355 participants, such as intermediaries. 357 Designing protocols to use services rather than intermediaries 358 ensures that responsibilities of protocol participants are clearly 359 defined. Where functions can provided by means other than 360 intermediation, the design should prefer that alternative. 362 If there is a need for information, defining a means for querying a 363 service for that information is preferable to adding an intermediary. 364 Similarly, direct invocation of service to perform an action is 365 better than involving that service as a participant in the protocol. 367 Involving an entity as an intermediary can greatly increase the 368 degree to which that entity becomes a dependency. For example, it 369 might be necessary to negotiate the use of new capabilities with all 370 protocol participants, including the intermediary, even when the 371 functions for which the intermediary was added are not affected. It 372 is also more difficult to limit the extent to which a protocol 373 participant can be involved than a service that is invoked for a 374 specific task. 376 Using discrete services is not always the most performant 377 architecture as additional network interactions can add to overheads. 378 The cost of these overheads need to be weighed against the recurrent 379 costs from involving intermediaries. 381 The contribution of an intermediary to performance and efficiency can 382 involve trade-offs, such as those discussed in Section 2.3 of [E2E]. 383 One consideration is the potential need for critical functions to be 384 replicated in both intermediaries and endpoints, reducing efficiency. 385 Another is the possibility that an intermediary optimized for one 386 application could degrade performance in other applications. 388 Preferring services is analogous to the software design principle 389 that recommends a preference for composition over inheritance 390 [PATTERNS]. 392 9.2. Deliberately Select Protocol Participants 394 Protocol participants should know what other participants they might 395 be interacting with, including intermediaries. 397 Protocols that permit the involvement of an intermediary need to do 398 so intentionally and provide measures that prevent the addition of 399 unwanted intermediaries. Ideally, all protocol participants are 400 identified and known to other protocol participants. 402 The addition of an unwanted protocol participant is an attack on the 403 protocol. 405 This is an extension of the conclusion of [PATH-SIGNALS], which: 407 recommends that implicit signals should be avoided and that an 408 implicit signal should be replaced with an explicit signal only 409 when the signal's originator intends that it be used by the 410 network elements on the path. 412 Applying this principle likely requires the use of authentication and 413 encryption. 415 9.3. Limit Capabilities of Intermediaries 417 Protocol participants should be able to limit the capabilities 418 conferred to other protocol participants. 420 Where the potential for intermediation already exists, or 421 intermediaries provide essential functions, protocol designs should 422 limit the capabilities and information that protocol participants are 423 required to grant others. 425 Limiting the information that participants are required to provide to 426 other participants has benefits for privacy or to limit the potential 427 for misuse of information; see Section 9.3.1. Where confidentiality 428 is impossible or impractical, integrity protection can be used to 429 ensure that data origin authentication is preserved; see 430 Section 9.3.2. 432 9.3.1. Limit Information Exposure 434 Protocol participants should only have access to the information they 435 need to perform their designated function. 437 Protocol designs based on a principle of providing the minimum 438 information necessary have several benefits. In addition to 439 requiring smaller messages, or fewer exchanges, reducing information 440 provides greater control over exposure of information. This has 441 privacy benefits. 443 Where an intermediary needs to carry information that it has no need 444 to access, protocols should use encryption to ensure that the 445 intermediary cannot access that information. 447 Providing information for intermediaries using signals that are 448 separate from other protocol signaling is preferable [PATH-SIGNALS]. 449 In addition, integrity protection should be applied to these signals 450 to prevent modification. 452 9.3.2. Limit Permitted Interactions 454 An action should only be taken based on signals from protocol 455 participants that are authorized to request that action. 457 Where an intermediary needs to communicate with other protocol 458 participants, ensure that these signals are attributed to an 459 intermediary. Authentication is the best means of ensuring signals 460 generated by protocol participants are correctly attributed. 461 Authentication informs decisions protocol participants make about 462 actions they take. 464 In some cases, particularly protocols that are primarily two-party 465 protocols, it might be sufficient to allow the signal to be 466 attributed to any intermediary. This is the case in QUIC [QUIC] for 467 ECN [ECN] and ICMP [ICMP], both of which are assumed to be provided 468 by elements on the network path. Limited mechanisms exist to 469 authenticate these as signals that originate from path elements, 470 informing actions taken by endpoints. Consequently, the actions 471 taken in response to these signals is limited. 473 9.3.3. Costs of Technical Constraints 475 Moving from a protocol in which there are two participants (such as 476 [TLS]) to more than two participants can be more complex and 477 expensive to implement and deploy. 479 More generally, the application of technical measures to control how 480 intermediaries participate in a protocol incur costs that manifest in 481 several ways. Protocols are more difficult to design; 482 implementations are larger and more complex; and deployments might 483 suffer from added operational costs, higher computation loads, and 484 more bandwidth consumption. These costs are reflective of the true 485 cost of involving additional entities in protocols. In protocols 486 without technical measures to limit participation, these costs have 487 historically been borne by other protocol participants. 489 In general however, most protocols are able to reuse existing 490 mechanisms for cryptographic protection, such as TLS [TLS]. Adopting 491 something like TLS provides security properties that are well 492 understood and analyzed. Using a standardized solution enables use 493 of well-tested implementations that include optimizations and other 494 mitigations for these costs. 496 10. Applying Non-Technical Constraints 498 Not all intermediary functions can be tightly constrained. For 499 instance, as described in Section 6, some functions involve granting 500 intermediaries access to information that can be used for more than 501 its intended purpose. Applying strong technical constraints on how 502 that information is used might be infeasible or impossible. 504 The use of authentication allows for other forms of control on 505 intermediaries. Auditing systems or other mechanisms for ensuring 506 accountability can use authentication information. Authentication 507 can also enable the use of legal, social, or other types of control 508 that might cover any shortfall in technical measures. 510 11. The Effect on Existing Practices 512 The application of these principles can have an effect on existing 513 operational practices, particularly where they rely on protocols not 514 limiting intermediary access. Several documents have explored 515 aspects of this in detail: 517 * [RFC8404] describes effects of encryption on practices performed 518 by intermediaries; 520 * [RFC8517] describes a broader set of practices; 522 * [TSV-ENC] explores the effect on transport-layer intermediaries in 523 more detail; and 525 * [NS-IMPACT] examines the effect of TLS on operational network 526 security practices. 528 In all these documents, the defining characteristic is the move from 529 a system that lacked controls on participation to one in which 530 technical controls are deployed. In each case the protocols in 531 question provided no technical controls or only limited technical 532 controls that prevent the addition of intermediaries. This allowed 533 the deployment of techniques that involved the insertion of 534 intermediaries into sessions without permission or knowledge of other 535 protocol participants. By adding controls like encryption, these 536 practices are disrupted. Overall, the advantages derived from having 537 greater control and knowledge of other protocol participants 538 outweighs these costs. 540 The process of identifying critical functions for intermediaries is 541 ongoing. There are three potential classes of outcome of these 542 discussion: 544 * Practices might be deemed valuable and methods that allow limited 545 participation by intermediaries will be added to protocols. 547 * The use case supported by the practice might be deemed valuable, 548 but alternative methods that address the use case without the use 549 of an intermediary will be sought. 551 * Practices might be deemed harmful and no replacement mechanism 552 will be sought. 554 Many factors could influence the outcome of this analysis. For 555 instance, deployment of alternative methods or limited roles for 556 intermediaries could be relatively simple for new protocol 557 deployments; whereas it might be challenging to retrofit controls on 558 existing protocol deployments. 560 12. Security Considerations 562 Controlling the level of participation and access intermediaries have 563 is a security question. The principles in Section 9 are 564 fundamentally an application of a security principle: namely the 565 principle of least privilege [LEAST-PRIVILEGE]. 567 Lack of proper controls on intermediaries protocols has been the 568 source of significant security problems. 570 13. IANA Considerations 572 This document has no IANA actions. 574 14. Informative References 576 [CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know 577 Why You Went to the Clinic: Risks and Realization of HTTPS 578 Traffic Analysis", Privacy Enhancing Technologies pp. 579 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014, 580 . 582 [E2E] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments 583 in system design", ACM Transactions on Computer 584 Systems Vol. 2, pp. 277-288, DOI 10.1145/357401.357402, 585 November 1984, . 587 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 588 of Explicit Congestion Notification (ECN) to IP", 589 RFC 3168, DOI 10.17487/RFC3168, September 2001, 590 . 592 [EROSION] Hildebrand, J. and P. McManus, "Erosion of the moral 593 authority of transparent middleboxes", Work in Progress, 594 Internet-Draft, draft-hildebrand-middlebox-erosion-01, 10 595 November 2014, . 598 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 599 Semantics", Work in Progress, Internet-Draft, draft-ietf- 600 httpbis-semantics-16, 27 May 2021, 601 . 604 [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, 605 RFC 792, DOI 10.17487/RFC0792, September 1981, 606 . 608 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 609 (IPv6) Specification", STD 86, RFC 8200, 610 DOI 10.17487/RFC8200, July 2017, 611 . 613 [LEAST-PRIVILEGE] 614 Saltzer, J., "Protection and the control of information 615 sharing in multics", Communications of the ACM Vol. 17, 616 pp. 388-402, DOI 10.1145/361011.361067, July 1974, 617 . 619 [MIDDLEBOX] 620 Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 621 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 622 . 624 [NS-IMPACT] 625 Cam-Winget, N., Wang, E., Danyliw, R., and R. DuToit, 626 "Impact of TLS 1.3 to Operational Network Security 627 Practices", Work in Progress, Internet-Draft, draft-ietf- 628 opsec-ns-impact-04, 26 January 2021, 629 . 632 [PATH-SIGNALS] 633 Hardie, T., Ed., "Transport Protocol Path Signals", 634 RFC 8558, DOI 10.17487/RFC8558, April 2019, 635 . 637 [PATTERNS] Gamma, E., Helm, R., Johnson, R., and J. Vlissides, 638 "Design Patterns: Elements of Reusable Object-Oriented 639 Software", 1994. 641 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 642 and Secure Transport", Work in Progress, Internet-Draft, 643 draft-ietf-quic-transport-34, 14 January 2021, 644 . 647 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 648 A., Peterson, J., Sparks, R., Handley, M., and E. 649 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 650 DOI 10.17487/RFC3261, June 2002, 651 . 653 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 654 Text on Security Considerations", BCP 72, RFC 3552, 655 DOI 10.17487/RFC3552, July 2003, 656 . 658 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 659 the Middle and the Future of End-to-End: Reflections on 660 the Evolution of the Internet Architecture", RFC 3724, 661 DOI 10.17487/RFC3724, March 2004, 662 . 664 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 665 Initiation Protocol (SIP) Back-to-Back User Agents", 666 RFC 7092, DOI 10.17487/RFC7092, December 2013, 667 . 669 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 670 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 671 2014, . 673 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 674 Nordmark, "Technical Considerations for Internet Service 675 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 676 March 2016, . 678 [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays 679 around NAT (TURN) Server Auto Discovery", RFC 8155, 680 DOI 10.17487/RFC8155, April 2017, 681 . 683 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 684 Pervasive Encryption on Operators", RFC 8404, 685 DOI 10.17487/RFC8404, July 2018, 686 . 688 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 689 Jacquenet, "An Inventory of Transport-Centric Functions 690 Provided by Middleboxes: An Operator Perspective", 691 RFC 8517, DOI 10.17487/RFC8517, February 2019, 692 . 694 [SRv6] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 695 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 696 (SRv6) Network Programming", RFC 8986, 697 DOI 10.17487/RFC8986, February 2021, 698 . 700 [TCP-EXTEND] 701 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 702 Handley, M., and H. Tokuda, "Is it still possible to 703 extend TCP?", Proceedings of the 2011 ACM SIGCOMM 704 conference on Internet measurement conference - IMC '11, 705 DOI 10.1145/2068816.2068834, 2011, 706 . 708 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 709 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 710 . 712 [TSV-ENC] Fairhurst, G. and C. Perkins, "Considerations around 713 Transport Header Confidentiality, Network Operations, and 714 the Evolution of Internet Transport Protocols", Work in 715 Progress, Internet-Draft, draft-ietf-tsvwg-transport- 716 encrypt-21, 20 April 2021, 717 . 720 [USE-IT] Thomson, M., "Long-term Viability of Protocol Extension 721 Mechanisms", Work in Progress, Internet-Draft, draft-iab- 722 use-it-or-lose-it-00, 7 August 2019, 723 . 726 Appendix A. Acknowledgments 728 This document is merely an attempt to codify existing practice. 729 Practice that is inspired, at least in part, by prior work, including 730 [RFC3552] and [RFC3724] which both advocate for clearer articulation 731 of trust boundaries. 733 Jari Arkko, Eric Rescorla, and David Schinazi are acknowledged for 734 their contributions of thought, review, and text. 736 Author's Address 738 Martin Thomson 739 Mozilla 741 Email: mt@lowentropy.net