| Internet-Draft | Too Much Intermediation | January 2021 |
| Thomson | Expires 8 July 2021 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the IAB Model-T list (modelt@iab.org), which is archived at https://mailarchive.ietf.org/arch/browse/model-t/.¶
Source for this draft and an issue tracker can be found at https://github.com/martinthomson/tmi.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 July 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
The Internet owes much of its success to its application of the end-to-end principle [E2E]. 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:¶
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.¶
A protocol intermediary is an element that participates in communications. An intermediary is not the primary initiator or recipient of communications, but instead acts to facilitate communications.¶
An intermediary need not be explicitly present at the request of a participant.¶
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 [RFC8155] 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.¶
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 include services like the DNS. That said, though the DNS as a service does not result in intermediation of other activities, there are roles for intermediaries within the DNS that fit this definition, such as recursive resolvers.¶
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.¶
Thus, 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.¶
That intermediaries provide access to valuable resources does not imply that all intermediaries have exclusive control over access to resources. A router might provide 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 aggregates demand from 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. 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.¶
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.¶
The goal of some intermediary deployments is to effect a policy, relying 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 [RFC7754], misinformation, or pervasive monitoring [RFC7258].¶
Intermediaries that can affect many people can therefore be powerful agents for control. Though it is clear that 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.¶
A dependency on an intermediary can represent a risk to those that take the dependency. The incentives and motives of intermediaries can be important to consider.¶
For instance, the information necessary for an intermediary to performs its function can often 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 obvious [CLINIC].¶
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; see (TODO CHOKEPOINTS=I-D.iab-chokepoints).¶
The ability to act as intermediary can offer more options than a service that is called upon to provide information. 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 [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 [EROSION] or [MIDDLEBOX]. 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 Section 2.3 of [USE-IT]. For example, measurement of TCP showed that the protocol has poor prospects for extensibility due to widespread use - and poor implementation - of intermediaries [TCP-EXTEND].¶
The IETF has a long history of dealing with different forms of intermediation poorly.¶
Early use of NAT was loudly decried by some in the IETF community. Indeed, the use of NAT was regarded as an unwanted intrusion by intermediaries. The eventual recognition - not endorsement - of the existence of NAT ([MIDDLEBOX], [NAT-ARCH]) allowed the community to engage in the design protocols that properly handled NAT devices ([UNSAF], [STUN]) and to make recommendations for best practices [BEHAVE].¶
Like HTTP, SIP [RFC3261] 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; [RFC7092]) 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 are sometimes intermediaries - is fiercely debated in the context of TLS 1.3 [TLS], where the design renders certain practices obsolete. Proposed uses of IPv6 header extensions in [SRv6NP] called into question the extent to which header extensions are the exclusive domain of endpoints as opposed to being available to intermediaries.¶
It could be that the circumstances in each of these debates is different enough that there is no singular outcome. The complications resulting from large-scale deployments of great diversity might render a single clear outcome impossible for an established protocol.¶
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 set out in three stages:¶
The use of technical mechanisms to ensure that these principles are enforced is necessary. 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.¶
Protocols should prefer designs that do not involve additional participants, such as intermediaries.¶
Designing protocols to use services rather than intermediaries ensures that responsibilities of protocol participants are clearly defined. Where functions can provided by means other than intermediation, the design should prefer that alternative.¶
If there is a need for information, defining a means for querying a service for that information is preferable to adding an intermediary. Similarly, direct invocation of service to perform an action is better than involving that service as a participant in the protocol.¶
Involving an entity as an intermediary can greatly increase the degree to which that entity becomes a dependency. 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 to overheads. The cost of these overheads need to be weighed against the recurrent costs from involving intermediaries.¶
The contribution of an intermediary to performance and efficiency can involve trade-offs, such as those discussed in Section 2.3 of [E2E]. 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 [PATTERNS].¶
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 [PATH-SIGNALS], which:¶
Applying this principle likely requires the use of authentication and encryption.¶
Protocol participants should be able to limit the capabilities conferred to other protocol participants.¶
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 Section 9.3.1. Where confidentiality is impossible or impractical, integrity protection can be used to ensure that data origin authentication is preserved; see Section 9.3.2.¶
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 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 [PATH-SIGNALS]. In addition, integrity protection should be applied to these signals to prevent modification.¶
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 [QUIC] for ECN [ECN] and ICMP [ICMP], both of which 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 taken in response to these signals is limited.¶
Moving from a protocol in which there are two participants (such as [TLS]) 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 [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.¶
Not all intermediary functions can be tightly constrained. For instance, as described in Section 6, 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.¶
The use of authentication allows for other forms of control on intermediaries. Auditing systems or other mechanisms for ensuring accountability can use authentication information. Authentication can also enable the use of legal, social, or other types of control that might cover any shortfall in technical measures.¶
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:¶
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 deployed. In each case the protocols in question provided no technical controls or only limited technical controls that prevent the addition of intermediaries. This allowed the deployment of techniques that involved the insertion of intermediaries into sessions without permission or knowledge of other protocol participants. By adding controls like encryption, these practices are disrupted. Overall, the advantages derived from having greater control and knowledge of other protocol participants outweighs these costs.¶
The process of identifying critical functions for intermediaries is ongoing. There are three potential classes of outcome of these discussion:¶
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.¶
Controlling the level of participation and access intermediaries have is a security question. The principles in Section 9 are fundamentally an application of a security principle: namely the principle of least privilege [LEAST-PRIVILEGE].¶
Lack of proper controls on intermediaries protocols has been the source of significant security problems.¶
This document has no IANA actions.¶
This document is merely an attempt to codify existing practice. Practice that is inspired, at least in part, by prior work, including [RFC3552] and [RFC3724] which both advocate for clearer articulation of trust boundaries.¶
Jari Arkko, Eric Rescorla, and David Schinazi are acknowledged for their contributions of thought, review, and text.¶