idnits 2.17.1 draft-thomson-tmi-01.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 (4 January 2021) is 1207 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-13 == Outdated reference: A later version (-04) exists of draft-ietf-opsec-ns-impact-03 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-33 == Outdated reference: A later version (-21) exists of draft-ietf-tsvwg-transport-encrypt-18 == Outdated reference: A later version (-04) exists of draft-iab-use-it-or-lose-it-00 Summary: 0 errors (**), 0 flaws (~~), 6 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 4 January 2021 5 Expires: 8 July 2021 7 Principles for the Involvement of Intermediaries in Internet Protocols 8 draft-thomson-tmi-01 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 July 2021. 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 . . . . . . . . . . . . 10 76 9.3.3. Costs of Technical Constraints . . . . . . . . . . . 11 77 10. Applying Non-Technical Constraints . . . . . . . . . . . . . 11 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 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. Though it is clear that the morality of actions 226 taken can be subjective, network users have to consider the potential 227 for the power they vest in intermediaries to be abused or subverted. 229 6. Incentive Misalignment at Scale 231 A dependency on an intermediary can represent a risk to those that 232 take the dependency. The incentives and motives of intermediaries 233 can be important to consider. 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; see (TODO CHOKEPOINTS=I-D.iab-chokepoints). 249 7. Forced and Unwanted Intermediation 251 The ability to act as intermediary can offer more options than a 252 service that is called upon to provide information. Sometimes those 253 advantages are enough to justify the use of intermediation over 254 alternative designs. However, the use of an intermediary also 255 introduces costs. 257 The use of transparent or interception proxies in HTTP [HTTP] is an 258 example of a practice that has fallen out of common usage due to 259 increased use of HTTPS. Use of transparent proxies was once 260 widespread with a wide variety of reasons for their deployment. 261 However, transparent proxies were involved in many abuses, such as 262 unwanted transcoding of content and insertion of identifiers to the 263 detriment of individual privacy. 265 Introducing intermediaries is often done with the intent of avoiding 266 disruption to protocols that operate a higher layer of the stack. 267 However, network layering abstractions often leak, meaning that the 268 effects of the intermediation can be observed. Where those effects 269 cause problems, it can be difficult to detect and fix those problems. 271 The insertion of an intermediary in a protocol imposes other costs on 272 other protocol participants; see [EROSION] or [MIDDLEBOX]. In 273 particular, poor implementations of intermediaries can adversely 274 affect protocol operation. 276 As an intermediary is another participant in a protocol, they can 277 make interactions less robust. Intermediaries can also be 278 responsible for ossification, or the inability to deploy new protocol 279 mechanisms; see Section 2.3 of [USE-IT]. For example, measurement of 280 TCP showed that the protocol has poor prospects for extensibility due 281 to widespread use - and poor implementation - of intermediaries 282 [TCP-EXTEND]. 284 8. Contention over Intermediation 286 The IETF has a long history of dealing with different forms of 287 intermediation poorly. 289 Early use of NAT was loudly decried by some in the IETF community. 290 Indeed, the use of NAT was regarded as an unwanted intrusion by 291 intermediaries. The eventual recognition - not endorsement - of the 292 existence of NAT ([MIDDLEBOX], [NAT-ARCH]) allowed the community to 293 engage in the design protocols that properly handled NAT devices 294 ([UNSAF], [STUN]) and to make recommendations for best practices 295 [BEHAVE]. 297 Like HTTP, SIP [RFC3261] defines a role for a proxy, which is a form 298 of intermediary with limited ability to interact with the session 299 that it facilitates. In practice, many deployments instead choose to 300 deploy some form of Back-to-Back UA (B2BUA; [RFC7092]) for reasons 301 that effectively reduce to greater ability to implement control 302 functions. 304 There are several ongoing debates in the IETF that are rooted in 305 disagreement about the rule of intermediaries. The interests of 306 network-based devices - which are sometimes intermediaries - is 307 fiercely debated in the context of TLS 1.3 [TLS], where the design 308 renders certain practices obsolete. Proposed uses of IPv6 header 309 extensions in [SRv6NP] called into question the extent to which 310 header extensions are the exclusive domain of endpoints as opposed to 311 being available to intermediaries. 313 It could be that the circumstances in each of these debates is 314 different enough that there is no singular outcome. The 315 complications resulting from large-scale deployments of great 316 diversity might render a single clear outcome impossible for an 317 established protocol. 319 9. Proposed Principles 321 Many problems caused by intermediation are the result of 322 intermediaries that are introduced without the involvement of 323 protocol endpoints. Limiting the extent to which protocol designs 324 depend on intermediaries makes the resulting system more robust. 326 These principles are set out in three stages: 328 1. Prefer designs without intermediaries (Section 9.1); 330 2. Failing that, control which entities can intermediate the 331 protocol (Section 9.2); and 333 3. Limit actions and information that are available to 334 intermediaries (Section 9.3). 336 The use of technical mechanisms to ensure that these principles are 337 enforced is necessary. It is expected that protocols will need to 338 use cryptography for this. 340 New protocol designs therefore need to identify what intermediation 341 is possible and what is desired. Technical mechanisms to guarantee 342 conformance, where possible, are highly recommended. 344 Modifying existing protocols to follow these principles could be 345 difficult, but worthwhile. 347 9.1. Prefer Services to Intermediaries 349 Protocols should prefer designs that do not involve additional 350 participants, such as intermediaries. 352 Designing protocols to use services rather than intermediaries 353 ensures that responsibilities of protocol participants are clearly 354 defined. Where functions can provided by means other than 355 intermediation, the design should prefer that alternative. 357 If there is a need for information, defining a means for querying a 358 service for that information is preferable to adding an intermediary. 359 Similarly, direct invocation of service to perform an action is 360 better than involving that service as a participant in the protocol. 362 Involving an entity as an intermediary can greatly increase the 363 degree to which that entity becomes a dependency. For example, it 364 might be necessary to negotiate the use of new capabilities with all 365 protocol participants, including the intermediary, even when the 366 functions for which the intermediary was added are not affected. It 367 is also more difficult to limit the extent to which a protocol 368 participant can be involved than a service that is invoked for a 369 specific task. 371 Using discrete services is not always the most performant 372 architecture as additional network interactions can add to overheads. 373 The cost of these overheads need to be weighed against the recurrent 374 costs from involving intermediaries. 376 The contribution of an intermediary to performance and efficiency can 377 involve trade-offs, such as those discussed in Section 2.3 of [E2E]. 378 One consideration is the potential need for critical functions to be 379 replicated in both intermediaries and endpoints, reducing efficiency. 380 Another is the possibility that an intermediary optimized for one 381 application could degrade performance in other applications. 383 Preferring services is analogous to the software design principle 384 that recommends a preference for composition over inheritance 385 [PATTERNS]. 387 9.2. Deliberately Select Protocol Participants 389 Protocol participants should know what other participants they might 390 be interacting with, including intermediaries. 392 Protocols that permit the involvement of an intermediary need to do 393 so intentionally and provide measures that prevent the addition of 394 unwanted intermediaries. Ideally, all protocol participants are 395 identified and known to other protocol participants. 397 The addition of an unwanted protocol participant is an attack on the 398 protocol. 400 This is an extension of the conclusion of [PATH-SIGNALS], which: 402 recommends that implicit signals should be avoided and that an 403 implicit signal should be replaced with an explicit signal only 404 when the signal's originator intends that it be used by the 405 network elements on the path. 407 Applying this principle likely requires the use of authentication and 408 encryption. 410 9.3. Limit Capabilities of Intermediaries 412 Protocol participants should be able to limit the capabilities 413 conferred to other protocol participants. 415 Where the potential for intermediation already exists, or 416 intermediaries provide essential functions, protocol designs should 417 limit the capabilities and information that protocol participants are 418 required to grant others. 420 Limiting the information that participants are required to provide to 421 other participants has benefits for privacy or to limit the potential 422 for misuse of information; see Section 9.3.1. Where confidentiality 423 is impossible or impractical, integrity protection can be used to 424 ensure that data origin authentication is preserved; see 425 Section 9.3.2. 427 9.3.1. Limit Information Exposure 429 Protocol participants should only have access to the information they 430 need to perform their designated function. 432 Protocol designs based on a principle of providing the minimum 433 information necessary have several benefits. In addition to 434 requiring smaller messages, or fewer exchanges, reducing information 435 provides greater control over exposure of information. This has 436 privacy benefits. 438 Where an intermediary needs to carry information that it has no need 439 to access, protocols should use encryption to ensure that the 440 intermediary cannot access that information. 442 Providing information for intermediaries using signals that are 443 separate from other protocol signaling is preferable [PATH-SIGNALS]. 444 In addition, integrity protection should be applied to these signals 445 to prevent modification. 447 9.3.2. Limit Permitted Interactions 449 An action should only be taken based on signals from protocol 450 participants that are authorized to request that action. 452 Where an intermediary needs to communicate with other protocol 453 participants, ensure that these signals are attributed to an 454 intermediary. Authentication is the best means of ensuring signals 455 generated by protocol participants are correctly attributed. 456 Authentication informs decisions protocol participants make about 457 actions they take. 459 In some cases, particularly protocols that are primarily two-party 460 protocols, it might be sufficient to allow the signal to be 461 attributed to any intermediary. This is the case in QUIC [QUIC] for 462 ECN [ECN] and ICMP [ICMP], both of which are assumed to be provided 463 by elements on the network path. Limited mechanisms exist to 464 authenticate these as signals that originate from path elements, 465 informing actions taken by endpoints. Consequently, the actions 466 taken in response to these signals is limited. 468 9.3.3. Costs of Technical Constraints 470 Moving from a protocol in which there are two participants (such as 471 [TLS]) to more than two participants can be more complex and 472 expensive to implement and deploy. 474 More generally, the application of technical measures to control how 475 intermediaries participate in a protocol incur costs that manifest in 476 several ways. Protocols are more difficult to design; 477 implementations are larger and more complex; and deployments might 478 suffer from added operational costs, higher computation loads, and 479 more bandwidth consumption. These costs are reflective of the true 480 cost of involving additional entities in protocols. In protocols 481 without technical measures to limit participation, these costs have 482 historically been borne by other protocol participants. 484 In general however, most protocols are able to reuse existing 485 mechanisms for cryptographic protection, such as TLS [TLS]. Adopting 486 something like TLS provides security properties that are well 487 understood and analyzed. Using a standardized solution enables use 488 of well-tested implementations that include optimizations and other 489 mitigations for these costs. 491 10. Applying Non-Technical Constraints 493 Not all intermediary functions can be tightly constrained. For 494 instance, as described in Section 6, some functions involve granting 495 intermediaries access to information that can be used for more than 496 its intended purpose. Applying strong technical constraints on how 497 that information is used might be infeasible or impossible. 499 The use of authentication allows for other forms of control on 500 intermediaries. Auditing systems or other mechanisms for ensuring 501 accountability can use authentication information. Authentication 502 can also enable the use of legal, social, or other types of control 503 that might cover any shortfall in technical measures. 505 11. The Effect on Existing Practices 507 The application of these principles can have an effect on existing 508 operational practices, particularly where they rely on protocols not 509 limiting intermediary access. Several documents have explored 510 aspects of this in detail: 512 * [RFC8404] describes effects of encryption on practices performed 513 by intermediaries; 515 * [RFC8517] describes a broader set of practices; 517 * [TSV-ENC] explores the effect on transport-layer intermediaries in 518 more detail; and 520 * [NS-IMPACT] examines the effect of TLS on operational network 521 security practices. 523 In all these documents, the defining characteristic is the move from 524 a system that lacked controls on participation to one in which 525 technical controls are deployed. In each case the protocols in 526 question provided no technical controls or only limited technical 527 controls that prevent the addition of intermediaries. This allowed 528 the deployment of techniques that involved the insertion of 529 intermediaries into sessions without permission or knowledge of other 530 protocol participants. By adding controls like encryption, these 531 practices are disrupted. Overall, the advantages derived from having 532 greater control and knowledge of other protocol participants 533 outweighs these costs. 535 The process of identifying critical functions for intermediaries is 536 ongoing. There are three potential classes of outcome of these 537 discussion: 539 * Practices might be deemed valuable and methods that allow limited 540 participation by intermediaries will be added to protocols. 542 * The use case supported by the practice might be deemed valuable, 543 but alternative methods that address the use case without the use 544 of an intermediary will be sought. 546 * Practices might be deemed harmful and no replacement mechanism 547 will be sought. 549 Many factors could influence the outcome of this analysis. For 550 instance, deployment of alternative methods or limited roles for 551 intermediaries could be relatively simple for new protocol 552 deployments; whereas it might be challenging to retrofit controls on 553 existing protocol deployments. 555 12. Security Considerations 557 Controlling the level of participation and access intermediaries have 558 is a security question. The principles in Section 9 are 559 fundamentally an application of a security principle: namely the 560 principle of least privilege [LEAST-PRIVILEGE]. 562 Lack of proper controls on intermediaries protocols has been the 563 source of significant security problems. 565 13. IANA Considerations 567 This document has no IANA actions. 569 14. Informative References 571 [BEHAVE] Audet, F., Ed. and C. Jennings, "Network Address 572 Translation (NAT) Behavioral Requirements for Unicast 573 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 574 2007, . 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., Nottingham, M., and J. Reschke, "HTTP 599 Semantics", Work in Progress, Internet-Draft, draft-ietf- 600 httpbis-semantics-13, 14 December 2020, 601 . 604 [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, 605 RFC 792, DOI 10.17487/RFC0792, September 1981, 606 . 608 [LEAST-PRIVILEGE] 609 Saltzer, J., "Protection and the control of information 610 sharing in multics", Communications of the ACM Vol. 17, 611 pp. 388-402, DOI 10.1145/361011.361067, July 1974, 612 . 614 [MIDDLEBOX] 615 Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 616 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 617 . 619 [NAT-ARCH] Hain, T., "Architectural Implications of NAT", RFC 2993, 620 DOI 10.17487/RFC2993, November 2000, 621 . 623 [NS-IMPACT] 624 Cam-Winget, N., Wang, E., Danyliw, R., and R. DuToit, 625 "Impact of TLS 1.3 to Operational Network Security 626 Practices", Work in Progress, Internet-Draft, draft-ietf- 627 opsec-ns-impact-03, 25 October 2020, . 630 [PATH-SIGNALS] 631 Hardie, T., Ed., "Transport Protocol Path Signals", 632 RFC 8558, DOI 10.17487/RFC8558, April 2019, 633 . 635 [PATTERNS] Gamma, E., Helm, R., Johnson, R., and J. Vlissides, 636 "Design Patterns: Elements of Reusable Object-Oriented 637 Software", 1994. 639 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 640 and Secure Transport", Work in Progress, Internet-Draft, 641 draft-ietf-quic-transport-33, 13 December 2020, 642 . 645 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 646 A., Peterson, J., Sparks, R., Handley, M., and E. 647 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 648 DOI 10.17487/RFC3261, June 2002, 649 . 651 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 652 Text on Security Considerations", BCP 72, RFC 3552, 653 DOI 10.17487/RFC3552, July 2003, 654 . 656 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 657 the Middle and the Future of End-to-End: Reflections on 658 the Evolution of the Internet Architecture", RFC 3724, 659 DOI 10.17487/RFC3724, March 2004, 660 . 662 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 663 Initiation Protocol (SIP) Back-to-Back User Agents", 664 RFC 7092, DOI 10.17487/RFC7092, December 2013, 665 . 667 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 668 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 669 2014, . 671 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 672 Nordmark, "Technical Considerations for Internet Service 673 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 674 March 2016, . 676 [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays 677 around NAT (TURN) Server Auto Discovery", RFC 8155, 678 DOI 10.17487/RFC8155, April 2017, 679 . 681 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 682 Pervasive Encryption on Operators", RFC 8404, 683 DOI 10.17487/RFC8404, July 2018, 684 . 686 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 687 Jacquenet, "An Inventory of Transport-Centric Functions 688 Provided by Middleboxes: An Operator Perspective", 689 RFC 8517, DOI 10.17487/RFC8517, February 2019, 690 . 692 [SRv6NP] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 693 Matsushima, S., and Z. Li, "SRv6 Network Programming", 694 Work in Progress, Internet-Draft, draft-ietf-spring-srv6- 695 network-programming-28, 29 December 2020, 696 . 699 [STUN] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 700 D., Mahy, R., and P. Matthews, "Session Traversal 701 Utilities for NAT (STUN)", Work in Progress, Internet- 702 Draft, draft-ietf-tram-stunbis-21, 22 March 2019, 703 . 706 [TCP-EXTEND] 707 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 708 Handley, M., and H. Tokuda, "Is it still possible to 709 extend TCP?", Proceedings of the 2011 ACM SIGCOMM 710 conference on Internet measurement conference - IMC '11, 711 DOI 10.1145/2068816.2068834, 2011, 712 . 714 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 715 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 716 . 718 [TSV-ENC] Fairhurst, G. and C. Perkins, "Considerations around 719 Transport Header Confidentiality, Network Operations, and 720 the Evolution of Internet Transport Protocols", Work in 721 Progress, Internet-Draft, draft-ietf-tsvwg-transport- 722 encrypt-18, 2 November 2020, . 726 [UNSAF] Daigle, L., Ed. and IAB, "IAB Considerations for 727 UNilateral Self-Address Fixing (UNSAF) Across Network 728 Address Translation", RFC 3424, DOI 10.17487/RFC3424, 729 November 2002, . 731 [USE-IT] Thomson, M., "Long-term Viability of Protocol Extension 732 Mechanisms", Work in Progress, Internet-Draft, draft-iab- 733 use-it-or-lose-it-00, 7 August 2019, . 736 Appendix A. Acknowledgments 738 This document is merely an attempt to codify existing practice. 739 Practice that is inspired, at least in part, by prior work, including 740 [RFC3552] and [RFC3724] which both advocate for clearer articulation 741 of trust boundaries. 743 Jari Arkko, Eric Rescorla, and David Schinazi are acknowledged for 744 their contributions of thought, review, and text. 746 Author's Address 748 Martin Thomson 749 Mozilla 751 Email: mt@lowentropy.net