Principles for the Involvement of Intermediaries in Internet Protocols
Internet-Draft draft-thomson-tmi-04
Martin Thomson
Mozilla
mt@lowentropy.net
08 September 2022
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 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.
Introduction
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:
- Avoid intermediation (Section 9.1)
- Limit the entities that can intermediate (Section 9.2)
- Limit what intermediaries can do (Section 9.3)
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 [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.
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 [RFC8890], Section 4.2 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 [DIAMETER] 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 [RFC7754], misinformation [PARADOX], or pervasive monitoring [RFC7258].
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 [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.
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 [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 [X-UIDH].
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].
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 [RFC9000] 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 [IPv6] occurred prior to the publication of RFC 8986 [SRv6], 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 [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 sometimes act as TLS intermediaries -- is fiercely debated in the context of TLS 1.3 [TLS], 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 (Section 9.1);
2. Failing that, control which entities can intermediate the protocol (Section 9.2); and
3. Limit actions and information that are available to intermediaries (Section 9.3).
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 [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].
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 [PATH-SIGNALS], 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 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.
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 [PATH-SIGNALS]. 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 [RFC9000] where ECN [ECN] and ICMP [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 [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.
Applying Non-Technical Constraints
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.
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:
- [RFC8404] describes effects of encryption on practices performed by intermediaries;
- [RFC8517] describes a broader set of practices;
- [RFC9065] explores the effect on transport-layer intermediaries in more detail; and
- [NS-IMPACT] 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 Section 9 are fundamentally an application of a security principle: namely the principle of least privilege [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
[PATTERNS]

Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma
Richard Helm
Ralph Johnson
John Vlissides
1994
[X-UIDH]

Verizon Wireless’ use of a Unique Identifier Header (UIDH)
19 October 2012
[E2E]

End-to-end arguments in system design
J. H. Saltzer
M.I.T. Laboratory for Computer Science, 545 Technology Square, Cambridge, MA
D. P. Reed
Software Arts, Inc., 27 Mica Lane, Wellesley, MA
D. D. Clark
M.I.T. Laboratory for Computer Science, 545 Technology Square, Cambridge, MA
November 1984
ACM Transactions on Computer Systems vol. 2, no. 4, pp. 277-288
DOI 10.1145/357401.357402
[RFC8155]

Traversal Using Relays around NAT (TURN) Server Auto Discovery
P. Patil
T. Reddy
D. Wing
April 2017
RFC 8155
DOI 10.17487/RFC8155
[RFC8890]

The Internet is for End Users
M. Nottingham
August 2020
RFC 8890
DOI 10.17487/RFC8890
[DIAMETER]

Diameter Base Protocol
V. Fajardo, Ed.
J. Arkko
J. Loughney
G. Zorn, Ed.
October 2012
RFC 6733
DOI 10.17487/RFC6733
[RFC7754]

Technical Considerations for Internet Service Blocking and Filtering
R. Barnes
A. Cooper
O. Kolkman
D. Thaler
E. Nordmark
March 2016
RFC 7754
DOI 10.17487/RFC7754
[PARADOX]

The Paradox of Participation Versus Misinformation: Social Media, Political Engagement, and the Spread of Misinformation
Sebastián Valenzuela
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;
Daniel Halpern
School of Communications, Research Center for Integrated Disaster Risk Management (CIGIDEN), Pontificia Universidad Católica de Chile, Santiago, Chile;
James E. Katz
Division of Emerging Media Studies, Boston University, Boston, MA, USA
Juan Pablo Miranda
School of Communications, Research Center for Integrated Disaster Risk Management (CIGIDEN), Pontificia Universidad Católica de Chile, Santiago, Chile;
June 2019
Digital Journalism vol. 7, no. 6, pp. 802-823
DOI 10.1080/21670811.2019.1623701
[RFC7258]

Pervasive Monitoring Is an Attack
S. Farrell
H. Tschofenig
May 2014
BCP 188
RFC 7258
DOI 10.17487/RFC7258
[CLINIC]

I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis
Brad Miller
Ling Huang
A. D. Joseph
J. D. Tygar
2014
Privacy Enhancing Technologies pp. 143-163
DOI 10.1007/978-3-319-08506-7_8
[HTTP]

HTTP Semantics
R. Fielding, Ed.
M. Nottingham, Ed.
J. Reschke, Ed.
June 2022
STD 97
RFC 9110
DOI 10.17487/RFC9110
[EROSION]

Erosion of the moral authority of transparent middleboxes
Joe Hildebrand
Patrick McManus
10 November 2014
Internet-Draft draft-hildebrand-middlebox-erosion-01
[MIDDLEBOX]

Middleboxes: Taxonomy and Issues
B. Carpenter
S. Brim
February 2002
RFC 3234
DOI 10.17487/RFC3234
[USE-IT]

Long-Term Viability of Protocol Extension Mechanisms
M. Thomson
T. Pauly
December 2021
RFC 9170
DOI 10.17487/RFC9170
[TCP-EXTEND]

Is it still possible to extend TCP?
Michio Honda
Yoshifumi Nishida
Costin Raiciu
Adam Greenhalgh
Mark Handley
Hideyuki Tokuda
2011
Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference - IMC '11
DOI 10.1145/2068816.2068834
[RFC9000]

QUIC: A UDP-Based Multiplexed and Secure Transport
J. Iyengar, Ed.
M. Thomson, Ed.
May 2021
RFC 9000
DOI 10.17487/RFC9000
[IPv6]

Internet Protocol, Version 6 (IPv6) Specification
S. Deering
R. Hinden
July 2017
STD 86
RFC 8200
DOI 10.17487/RFC8200
[SRv6]

Segment Routing over IPv6 (SRv6) Network Programming
C. Filsfils, Ed.
P. Camarillo, Ed.
J. Leddy
D. Voyer
S. Matsushima
Z. Li
February 2021
RFC 8986
DOI 10.17487/RFC8986
[RFC3261]

SIP: Session Initiation Protocol
J. Rosenberg
H. Schulzrinne
G. Camarillo
A. Johnston
J. Peterson
R. Sparks
M. Handley
E. Schooler
June 2002
RFC 3261
DOI 10.17487/RFC3261
[RFC7092]

A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
H. Kaplan
V. Pascual
December 2013
RFC 7092
DOI 10.17487/RFC7092
[TLS]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[PATH-SIGNALS]

Transport Protocol Path Signals
T. Hardie, Ed.
April 2019
RFC 8558
DOI 10.17487/RFC8558
[ECN]

The Addition of Explicit Congestion Notification (ECN) to IP
K. Ramakrishnan
S. Floyd
D. Black
September 2001
RFC 3168
DOI 10.17487/RFC3168
[ICMP]

Internet Control Message Protocol
J. Postel
September 1981
STD 5
RFC 792
DOI 10.17487/RFC0792
[RFC8404]

Effects of Pervasive Encryption on Operators
K. Moriarty, Ed.
A. Morton, Ed.
July 2018
RFC 8404
DOI 10.17487/RFC8404
[RFC8517]

An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective
D. Dolson, Ed.
J. Snellman
M. Boucadair, Ed.
C. Jacquenet
February 2019
RFC 8517
DOI 10.17487/RFC8517
[RFC9065]

Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols
G. Fairhurst
C. Perkins
July 2021
RFC 9065
DOI 10.17487/RFC9065
[NS-IMPACT]

Impact of TLS 1.3 to Operational Network Security Practices
Nancy Cam-Winget
Cisco Systems
Eric Wang
Cisco Systems
Roman Danyliw
Software Engineering Institute
Roelof DuToit
Broadcom
26 January 2021
Internet-Draft draft-ietf-opsec-ns-impact-04
[LEAST-PRIVILEGE]

Protection and the control of information sharing in multics
Jerome H. Saltzer
Massachusetts Institute of Technology, Cambridge
July 1974
Communications of the ACM vol. 17, no. 7, pp. 388-402
DOI 10.1145/361011.361067
[RFC3552]

Guidelines for Writing RFC Text on Security Considerations
E. Rescorla
B. Korver
July 2003
BCP 72
RFC 3552
DOI 10.17487/RFC3552
[RFC3724]

The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture
J. Kempf, Ed.
R. Austein, Ed.
IAB
March 2004
RFC 3724
DOI 10.17487/RFC3724
Acknowledgments
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.