]> Principles for the Involvement of Intermediaries in Internet Protocols Mozilla
mt@lowentropy.net
This document proposes a set of principles for designing protocols with rules for intermediaries. The goal of these principles is to limit the ways in which intermediaries can produce undesirable effects and to protect the useful functions that intermediaries legitimately provide. Discussion Venues Discussion of this document takes place on the IAB Model-T list (modelt@iab.org), which is archived at . Source for this draft and an issue tracker can be found at .
Introduction The Internet owes much of its success to its application of the end-to-end principle . The realization that efficiency is best served by moving higher-level functions to endpoints is a key insight in system design, but also a key element of the success of the Internet. This does not mean that the Internet avoids a relying on functions provided by entities in the network. While the principle establishes that some functions are best provided by endsystems, this does not exclude all intermediary functions. Some level of function in the network is necessary, or else there would be no network. The ways in which intermediaries can assist protocol endpoints are numerous and constantly evolving. This document explores some of the ways in which intermediaries make both essential and valuable contributions to the function of the system. Problems arise when the interests of intermediaries are poorly aligned with those of endpoints. This can result in systemic costs and tension. Addressing those issues can be difficult. This document proposes the following design principles for the protocols that might involve the participation of intermediaries:
  • Avoid intermediation ()
  • Limit the entities that can intermediate ()
  • Limit what intermediaries can do ()
These principles aim to provide clarity about the roles and responsibilities of protocol participants. These principles produce more robust protocols with better privacy and security properties. These also limit the secondary costs associated with intermediation.
What is Meant by Intermediary An intermediary is an element that participates in a protocol exchange. An intermediary receives protocol units, such as packets or messages, and forwards the protocol units to other protocol participants. An intermediary might make changes to protocol units or leave the content of the unit unchanged. An intermediary often does not directly benefit from the protocol exchange, but instead acts to facilitate the exchange. An intermediary often participates at the request of another participant in the protocol, which might be an endpoint or an intermediary. Intermediaries exist at all layers of the stack. A router is an intermediary that acts at the network layer to forward packets. A TURN relay provides similar forwarding capability for UDP in the presence of a network address translator (NAT) -- a different type of intermediary that provides the ability to share a limited supply of addresses. At higher layers of the stack, group messaging servers intermediate the exchange of messages within groups of people; a conference focus aids the sending of media group real-time communications; and a social network intermediates communication and information sharing through the exchange of messages and formation of groups. A person uses a networked computer as an intermediary for their communications with other people and computers. This intermediation is essential, for users are unable to directly interact with a network. Much of the guidance in this document does not apply to the relationship between users and user agents; see , Section in particular, for an examination of this topic. An intermediary at one layer of the stack is often an endpoint for communication at a lower layer. A Diameter peer acts as an intermediary when it forwards requests to other peers. However, a Diameter peer establishes connections to neighboring peers using TLS/TCP or DTLS/SCTP and acts as a endpoint for all of those protocols. It is possible to facilitate communication without being an intermediary. The DNS provides information that is critical to locating and communicating with other Internet hosts, but it does so without intermediating those communications. Thus, this definition of intermediary does not necessarily include a service like the DNS. Of course, the use of the DNS could involve engaging with intermediaries such as recursive resolvers.
Intermediation Is Essential Intermediaries are essential to scalable communications. The service an intermediary provides usually involves access to resources that would not otherwise be available. For instance, the Internet does not function without routers that enable packets to reach other networks. There is some level of intermediation that is essential for the proper functioning of the Internet. Scalable solutions to the introduction problem often depend on services that provide access to information and capabilities. As it is with the network layer of the Internet, the use of an intermediary can be absolutely essential. For example, a social networking application acts as an intermediary that provides a communications medium, content discovery and publication, and related services. Video conferencing applications often depend on an intermediary that mixes audio and selectively forwards video so that bandwidth requirements don't increase beyond what is available for participants as conferences grow in size.
Intermediation Is Useful Not all intermediaries have exclusive control access to the resources they provide access to. A router might facilitate access to other networks, but similar access might be obtained via a different route. The same web content might be provided by multiple CDNs. Multiple DNS resolvers can provide answers to the same queries. The ability to access the same capabilities from multiple entities contributes greatly to the robustness of a system. Intermediaries often provide capabilities that benefit from economies of scale by providing a service that serves multiple individuals. For instance, individuals are unlikely to be in a position to negotiate connections to multiple networks, but an ISP can. Similarly, an individual might find it difficult to acquire the capacity necessary to withstand a DDoS attack, but the scale at which a CDN operates means that this capacity is likely available to it. Or the value of a social network is in part due to the existing participation of other people. Aggregation also provides other potential benefits. For instance, caching of shared information can allow for performance advantages. From an efficiency perspective, the use of shared resources might allow load to be more evenly distributed over time. Or, for privacy, individual activity might be mixed with the activity of many others, thereby making it difficult to isolate that activity. The ability of an intermediary to operate at scale can therefore provide a number of different benefits to performance, scalability, privacy, and other areas.
Intermediation Enables Scaling Of Control An action by an intermediary can affect all who communicate using that intermediary. For an intermediary that operates at scale, this means it can be seen as an effective control point. In addition to facilitating communications, some intermediary deployments aim to effect a policy. This relies on the ability of a well-placed intermediary to affect multiple protocol interactions and participants. The ability of an intermediary to affect a large number of network users can be an advantage or vulnerability, depending on perspective. For instance, network intermediaries have been used to distribute warnings of impending natural disasters like fire, flood, or earthquake, which save lives and property. In contrast, control over large-scale communications can enable censorship , misinformation , or pervasive monitoring . Intermediaries that can affect many people can therefore be powerful agents for control. While the morality of actions taken can be subjective, network users have to consider the potential for the power they vest in intermediaries to be abused or subverted.
Incentive Misalignment at Scale A dependency on an intermediary represents a risk to those that take the dependency. The incentives and motives of intermediaries can be important to consider when choosing to use an intermediary. For instance, the information an intermediary needs to perform its function might be used (or abused) for other purposes. Even the simple function of forwarding necessarily involves information about who was communicating, when, and the size of messages. This can reveal more than is trivially apparent . As uses of networks become more diverse, the extent that incentives for intermediaries and network users align reduce. In particular, acceptance of the costs and risks associated with intermediation by a majority of network users does not mean that all users have the same expectations and requirements. This can be a significant problem if it becomes difficult to avoid or refuse participation by a particular intermediary. A dependency on an intermediary, particularly a technically or operationally challenging dependency, can reduce the number of viable choices of intermediary operators. Reduced choice can lead to dependence on specific intermediaries, which reduces resilience and exposes endpoints to greater potential for abuse.
Forced and Unwanted Intermediation The ability to act as intermediary can offer more options than a service that is called upon to provide information or services as needed. Sometimes those advantages are enough to justify the use of intermediation over alternative designs. However, the use of an intermediary also introduces costs. The use of transparent or interception proxies in HTTP is an example of a practice that has fallen out of common usage due to increased use of HTTPS. Use of transparent proxies was once widespread with a wide variety of reasons for their deployment. However, transparent proxies were involved in many abuses, such as unwanted transcoding of content and insertion of identifiers to the detriment of individual privacy . Introducing intermediaries is often done with the intent of avoiding disruption to protocols that operate a higher layer of the stack. However, network layering abstractions often leak, meaning that the effects of the intermediation can be observed. Where those effects cause problems, it can be difficult to detect and fix those problems. The insertion of an intermediary in a protocol imposes other costs on other protocol participants; see or . In particular, poor implementations of intermediaries can adversely affect protocol operation. As an intermediary is another participant in a protocol, they can make interactions less robust. Intermediaries can also be responsible for ossification, or the inability to deploy new protocol mechanisms; see . For example, measurement of TCP showed that the protocol has poor prospects for extensibility due to widespread use -- and poor implementation -- of intermediaries . Some forms of intermediation have been deployed without consulting the endpoints involved in the protocol. As protocols evolve or a more diverse set of deployments are encountered, assumptions that might have been valid at the time the intermediary was deployed might not hold. For example, some intermediaries identified a very early version of QUIC by checking that the first byte of the UDP payload was to to a value of 0x07. As this version used the different bits in this byte to signal different protocol options, when endpoints started to exercise the options represented by other values the classification failed.
Contention over Intermediation The IETF has a long history of dealing with different forms of intermediation. A debate about the intent and purpose of IPv6 extension headers occurred prior to the publication of RFC 8986 , in particular, it's PSP (Penultimate Segment Pop) mode. Here, the use of extension headers by entities other than the communication endpoints -- that is, intermediaries -- was contested. As the purpose of this feature is to communicate routing information between intermediaries, this could be seen as a form of tunneling between the communicating routers that uses the ability of IPv6 intermediaries (or routers) to add or remove extension headers. Like HTTP, SIP defines a role for a proxy, which is a form of intermediary with limited ability to interact with the session that it facilitates. In practice, many deployments instead choose to deploy some form of Back-to-Back UA (B2BUA; ) for reasons that effectively reduce to greater ability to implement control functions. There are several ongoing debates in the IETF that are rooted in disagreement about the rule of intermediaries. The interests of network-based devices -- which sometimes act as TLS intermediaries -- is fiercely debated in the context of TLS 1.3 , where the design renders certain practices obsolete. The functions provided by intermediaries in different protocols can be dramatically different. Even within the one protocol, the same protocol might be deployed to address many different needs. For an existing protocol with wide deployment, there might not be a single, easy method for managing the integration of the functions that intermediaries provide.
Proposed Principles Many problems caused by intermediation are the result of intermediaries that are introduced without the involvement of protocol endpoints. Limiting the extent to which protocol designs depend on intermediaries makes the resulting system more robust. These principles are progressive, with three stages:
  1. Prefer designs without intermediaries ();
  2. Failing that, control which entities can intermediate the protocol (); and
  3. Limit actions and information that are available to intermediaries ().
The use of technical mechanisms to ensure that these principles are enforced is encouraged. It is expected that protocols will need to use cryptography for this. New protocol designs therefore need to identify what intermediation is possible and what is desired. Technical mechanisms to guarantee conformance, where possible, are highly recommended. Modifying existing protocols to follow these principles could be difficult, but worthwhile.
Prefer Services to Intermediaries Where protocol functions can provided by a service or a means other than intermediation, the design should prefer that alternative. Designing protocols to use services rather than intermediaries ensures that responsibilities of protocol participants are clearly defined. If there is a need for information, defining a means for querying a service for that information is preferable to allowing an intermediary to add information during an exchange. Similarly, direct invocation of service to perform an action is better than involving that service as a participant in the protocol. Involving an intermediary in a protocol means depending on that intermediary for every aspect of protocol functioning. For example, it might be necessary to negotiate the use of new capabilities with all protocol participants, including the intermediary, even when the functions for which the intermediary was added are not affected. It is also more difficult to limit the extent to which a protocol participant can be involved than a service that is invoked for a specific task. Using discrete services is not always the most performant architecture as additional network interactions can add latency or other overheads. The cost of these overheads need to be weighed against the recurrent costs from the involvement of intermediaries. The contribution of an intermediary to performance and efficiency can involve trade-offs, such as those discussed in Section 2.3 of . One consideration is the potential need for critical functions to be replicated in both intermediaries and endpoints, reducing efficiency. Another is the possibility that an intermediary optimized for one application could degrade performance in other applications. Preferring services is analogous to the software design principle that recommends a preference for composition over inheritance .
Deliberately Select Protocol Participants Protocol participants should know what other participants they might be interacting with, including intermediaries. Protocols that permit the involvement of an intermediary need to do so intentionally and provide measures that prevent the addition of unwanted intermediaries. Ideally, all protocol participants are identified and known to other protocol participants. The addition of an unwanted protocol participant is an attack on the protocol. This is an extension of the conclusion of , which:
recommends that implicit signals should be avoided and that an implicit signal should be replaced with an explicit signal only when the signal's originator intends that it be used by the network elements on the path.
Applying this principle likely requires the use of authentication and encryption.
Limit Capabilities of Intermediaries Protocol participants should be able to limit the capabilities conferred to other protocol participants. Though this applies to all participants, intermediaries often have narrowly-defined roles. Where the potential for intermediation already exists, or intermediaries provide essential functions, protocol designs should limit the capabilities and information that protocol participants are required to grant others. Limiting the information that participants are required to provide to other participants has benefits for privacy or to limit the potential for misuse of information; see . Where confidentiality is impossible or impractical, integrity protection can be used to ensure that data origin authentication is preserved; see .
Limit Information Exposure Protocol participants should only have access to the information they need to perform their designated function. Protocol designs based on a principle of providing the minimum information necessary have several benefits. In addition to simplicity, requiring smaller messages, or fewer exchanges, reducing information provides greater control over exposure of information. This has privacy benefits. Where an intermediary needs to carry information that it has no need to access, protocols should use encryption to ensure that the intermediary cannot access that information. Providing information for intermediaries using signals that are separate from other protocol signaling is preferable . In addition, integrity protection should be applied to these signals to prevent modification.
Limit Permitted Interactions An action should only be taken based on signals from protocol participants that are authorized to request that action. Where an intermediary needs to communicate with other protocol participants, ensure that these signals are attributed to an intermediary. Authentication is the best means of ensuring signals generated by protocol participants are correctly attributed. Authentication informs decisions protocol participants make about actions they take. In some cases, particularly protocols that are primarily two-party protocols, it might be sufficient to allow the signal to be attributed to any intermediary. This is the case in QUIC where ECN and ICMP signals are assumed to be provided by elements on the network path. Limited mechanisms exist to authenticate these as signals that originate from path elements, informing actions taken by endpoints. Consequently, the actions that can be taken in response to these signals is limited.
Costs of Technical Constraints Moving from a protocol in which there are two participants (such as ) to more than two participants can be more complex and expensive to implement and deploy. More generally, the application of technical measures to control how intermediaries participate in a protocol incur costs that manifest in several ways. Protocols are more difficult to design; implementations are larger and more complex; and deployments might suffer from added operational costs, higher computation loads, and more bandwidth consumption. These costs are reflective of the true cost of involving additional entities in protocols. In protocols without technical measures to limit participation, these costs have historically been borne by other protocol participants. In general however, most protocols are able to reuse existing mechanisms for cryptographic protection, such as TLS . Adopting something like TLS provides security properties that are well understood and analyzed. Using a standardized solution enables use of well-tested implementations that include optimizations and other mitigations for these costs.
Applying Non-Technical Constraints Not all intermediary functions can be tightly constrained. For instance, as described in , some functions involve granting intermediaries access to information that can be used for more than its intended purpose. Applying strong technical constraints on how that information is used might be infeasible or impossible. Systems that audit the involvement in protocols can use authentication to improve accountability. Authentication can enable the use of legal, social, or other types of control that might cover any shortfall in technical measures.
The Effect on Existing Practices The application of these principles can have an effect on existing operational practices, particularly where they rely on protocols not limiting intermediary access. Several documents have explored aspects of this in detail:
  • describes effects of encryption on practices performed by intermediaries;
  • describes a broader set of practices;
  • explores the effect on transport-layer intermediaries in more detail; and
  • examines the effect of TLS on operational network security practices.
In all these documents, the defining characteristic is the move from a system that lacked controls on participation to one in which technical controls are employed. In each case, the protocols in question provided little or no technical controls that prevented the addition of intermediaries. This allowed for the insertion of intermediaries into sessions without permission or knowledge of other protocol participants. Adding controls like encryption and authentication disrupts these practices. Overall, the advantages derived from having greater control over or knowledge of other protocol participants outweighs these costs. In these settings, finding ways for intermediaries to contribute is an ongoing process. When looking at how intermediaries contributed to protocols operation prior to the introduction of technical controls there are three potential classes of outcome of these discussion:
  • Practices might be deemed valuable. Facilities might be added to protocols to allow or encourage those practices.
  • The use case supported by the practice might be deemed valuable, but the existence of a superior alternative approach could make further effort unnecessary.
  • Practices might be deemed harmful, such that no replacement mechanism is needed.
Many factors could influence the outcome of this analysis. For instance, deployment of alternative methods or limited roles for intermediaries could be relatively simple for new protocol deployments; whereas it might be challenging to retrofit controls on existing protocol deployments.
Security Considerations Understanding how intermediaries participate is highly relevant to the security of a protocol. The principles in are fundamentally an application of a security principle: namely the principle of least privilege . Lack of proper controls on intermediaries in protocols has been the source of significant security problems. A protocol is not secure if it fails to prevent an intermediary from consuming, modifying, or generating protocol units in ways that are contrary to the interests of other protocol participants.
IANA Considerations This document has no IANA actions.
Informative References Design Patterns: Elements of Reusable Object-Oriented Software Verizon Wireless’ use of a Unique Identifier Header (UIDH) End-to-end arguments in system design M.I.T. Laboratory for Computer Science, 545 Technology Square, Cambridge, MA Software Arts, Inc., 27 Mica Lane, Wellesley, MA M.I.T. Laboratory for Computer Science, 545 Technology Square, Cambridge, MA Traversal Using Relays around NAT (TURN) Server Auto Discovery Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery. This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases. The Internet is for End Users This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this. Diameter Base Protocol The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK] Technical Considerations for Internet Service Blocking and Filtering The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches. The Paradox of Participation Versus Misinformation: Social Media, Political Engagement, and the Spread of Misinformation School of Communications, Research Center for Integrated Disaster Risk Management (CIGIDEN), Pontificia Universidad Católica de Chile, Santiago, Chile;; Millennium Institute for Foundational Research on Data (IMFD), Pontificia Universidad Católica de Chile, Santiago, Chile; School of Communications, Research Center for Integrated Disaster Risk Management (CIGIDEN), Pontificia Universidad Católica de Chile, Santiago, Chile; Division of Emerging Media Studies, Boston University, Boston, MA, USA School of Communications, Research Center for Integrated Disaster Risk Management (CIGIDEN), Pontificia Universidad Católica de Chile, Santiago, Chile; Pervasive Monitoring Is an Attack Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Erosion of the moral authority of transparent middleboxes Many middleboxes on the Internet attempt to add value to the connections that traverse that point on the network. Problems in their implementations erode the moral authority that otherwise might accrue to the legitimate value that they add. Middleboxes: Taxonomy and Issues This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community. Long-Term Viability of Protocol Extension Mechanisms The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. Is it still possible to extend TCP? QUIC: A UDP-Based Multiplexed and Secure Transport This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Internet Protocol, Version 6 (IPv6) Specification This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Segment Routing over IPv6 (SRv6) Network Programming The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. SIP: Session Initiation Protocol This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC). There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference. The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Transport Protocol Path Signals This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used. The Addition of Explicit Congestion Notification (ECN) to IP This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] Internet Control Message Protocol Effects of Pervasive Encryption on Operators Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks. An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes". RFC 3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets. Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication are now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, mitigate attacks against the transport protocol, and protect metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted. This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features. Impact of TLS 1.3 to Operational Network Security Practices Cisco Systems Cisco Systems Software Engineering Institute Broadcom Network-based security solutions are used by enterprises, the public sector, internet-service providers, and cloud-service providers to both complement and enhance host-based security solutions. As TLS is a widely deployed protocol to secure communication, these network- based security solutions must necessarily interact with it. This document describes this interaction for current operational security practices and notes the impact of TLS 1.3 on them. Protection and the control of information sharing in multics Massachusetts Institute of Technology, Cambridge Guidelines for Writing RFC Text on Security Considerations All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture IAB The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. This memo provides information for the Internet community.
Acknowledgments This document is merely an attempt to codify existing practice. Practice that is inspired, at least in part, by prior work, including and which both advocate for clearer articulation of trust boundaries. , , and are acknowledged for their contributions of thought, review, and text.