Network Working Group J. Kempf, Ed. Request for Comments: 3724 R. Austein, Ed. Category: Informational IAB March 2004 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.
AbstractThe 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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. A Brief History of the End-to-End Principle. . . . . . . . . . 2 3. Trends Opposed to the End-to-End Principle . . . . . . . . . . 5 4. Whither the End-to-End Principle?. . . . . . . . . . . . . . . 8 5. Internet Standards as an Arena for Conflict. . . . . . . . . . 10 6. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
1]. The end-to-end principle was originally articulated as a question of where best not to put functions in a communication system. Yet, in the ensuing years, it has evolved to address concerns of maintaining openness, increasing reliability and robustness, and preserving the properties of user choice and ease of new service development as discussed by Blumenthal and Clark in ; concerns that were not part of the original articulation of the end-to-end principle. In this document, we examine how the interpretation of the end-to-end principle has evolved over the years, and where it stands currently. We examine trends in the development of the Internet that have led to pressure to define services in the network, a topic that has already received some amount of attention from the IAB in RFC 3238 . We describe some considerations about how the end-to-end principle might evolve in light of these trends. 1]. A specific example of such a function is delivery guarantees . The original ARPANET returned a message "Request for Next Message" whenever it delivered a packet. Although this message was found to be useful within the network as a form of congestion control, since the ARPANET refused to accept another message to the same destination until the previous acknowledgment was returned, it was never particularly useful as an indication of guaranteed delivery. The problem was that the host stack on the sending host typically doesn't want to know just that the network delivered a packet, but rather the stack layer on the sending host wants to know that the stack layer on the receiving host properly processed the packet. In terms of modern IP stack structure, a reliable transport layer requires an indication that transport processing has successfully completed, such as given
by TCP's ACK message , and not simply an indication from the IP layer that the packet arrived. Similarly, an application layer protocol may require an application-specific acknowledgement that contains, among other things, a status code indicating the disposition of the request. The specific examples given in  and other references at the time  primarily involve transmission of data packets: data integrity, delivery guarantees, duplicate message suppression, per packet encryption, and transaction management. From the viewpoint of today's Internet architecture, we would view most of these as transport layer functions (data integrity, delivery guarantees, duplicate message suppression, and perhaps transaction management), others as network layer functions with support at other layers where necessary (for example, packet encryption), and not application layer functions. RFC 1958 : This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e., information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes. The original articulation of the end-to-end principle - that knowledge and assistance of the end point is essential and that omitting such knowledge and implementing a function in the network without such knowledge and assistance is not possible - took a while to percolate through the engineering community, and had evolved by this point to a broad architectural statement about what belongs in the network and what doesn't. RFC 1958 uses the term "application" to mean the entire network stack on the end node, including network, transport, and application layers, in contrast to the earlier articulation of the end-to-end principle as being about the communication system itself. "Fate-sharing" describes this quite clearly: the fate of a conversation between two applications is only
shared between the two applications; the fate does not depend on anything in the network, except for the network's ability to get packets from one application to the other. The end-to-end principle in this formulation is specifically about what kind of state is maintained where: To perform its services, the network maintains some state information: routes, QoS guarantees that it makes, session information where that is used in header compression, compression histories for data compression, and the like. This state must be self-healing; adaptive procedures or protocols must exist to derive and maintain that state, and change it when the topology or activity of the network changes. The volume of this state must be minimized, and the loss of the state must not result in more than a temporary denial of service given that connectivity exists. Manually configured state must be kept to an absolute minimum. In this formulation of the end-to-end principle, state involved in getting packets from one end of the network to the other is maintained in the network. The state is "soft state," in the sense that it can be quickly dropped and reconstructed (or even required to be periodically renewed) as the network topology changes due to routers and switches going on and off line. "Hard state", state upon which the proper functioning of the application depends, is only maintained in the end nodes. This formulation of the principle is a definite change from the original formulation of the principle, about end node participation being required for proper implementation of most functions. In summary, the general awareness both of the principle itself and of its implications for how unavoidable state should be handled grew over time to become a (if not the) foundation principle of the Internet architecture. 7], requires a routing proxy in the mobile node's home network (the Home Agent) for maintaining the mapping between the mobile node's routing locator, the care of address, and the mobile node's node identifier, the home address. But the local subnet routing proxy (the Foreign Agent), which was a feature of the older Mobile IPv4 design  that
compromised end-to-end routing, has been eliminated. The end node now handles its own care of address. In addition, Mobile IPv6 includes secure mechanisms for optimizing routing to allow end-to-end routing between the mobile end node and the correspondent node, removing the need to route through the global routing proxy at the home agent. These features are all based on end to end considerations. However, the need for the global routing proxy in the Home Agent in Mobile IPv6 is determined by the aliasing of the global node identifier with the routing identifier in the Internet routing architecture, a topic that was discussed in an IAB workshop and reported in RFC 2956 , and that hasn't changed in IPv6. Despite this constraint, the vision emerging out of the IETF working groups developing standards for mobile networking is of a largely autonomous mobile node with multiple wireless link options, among which the mobile node picks and chooses. The end node is therefore responsible for maintaining the integrity of the communication, as the end-to-end principle implies. This kind of innovative application of the end-to-end principle derives from the same basic considerations of reliability and robustness (wireless link integrity, changes in connectivity and service availability with movement, etc.) that motivated the original development of the end- to-end principle. While the basic reliability of wired links, routing, and switching equipment has improved considerably since the end-to-end principle was formalized 15 years ago, the reliability or unreliability of wireless links is governed more strongly by the basic physics of the medium and the instantaneous radio propagation conditions. RFC 1958 has increasingly come into question from various directions. The IAB has been concerned about trends opposing the end-to-end principle for some time, for example RFC 2956  and RFC 2775 . The primary focus of concern in these documents is the reduction in transparency due to the introduction of NATs and other address translation mechanisms in the Internet, and the consequences to the end-to-end principle of various scenarios involving full, partial, or no deployment of IPv6. More recently, the topic of concern has shifted to the consequences of service deployment in the network. The IAB opinion on Open Pluggable Edge Services (OPES) in RFC 3238  is intended to assess the architectural desirability of defining services in the network and to raise questions about how such services might result in compromises
of privacy, security, and end-to-end data integrity. Clark, et al. in  and Carpenter in RFC 3234  also take up the topic of service definition in the network. Perhaps the best review of the forces militating against the end-to- end principle is by Blumenthal and Clark in . The authors make the point that the Internet originally developed among a community of like-minded technical professionals who trusted each other, and was administered by academic and government institutions who enforced a policy of no commercial use. The major stakeholders in the Internet are quite different today. As a consequence, new requirements have evolved over the last decade. Examples of these requirements are discussed in the following subsections. Other discussions about pressures on the end-to-end principle in today's Internet can be found in the discussion by Reed  and Moors' paper in the 2002 IEEE International Communications Conference .
At the same time, these measures act as impediments for end-to-end communications. Third party trust intermediaries are not a requirement for security, as end-to-end security mechanisms, such as S/MIME , can be used instead, and where third party measures such as PKI infrastructure or keys in DNS are utilized to exchange keying material, they don't necessarily impinge on end-to-end traffic after authentication has been achieved. Even if third parties are involved, ultimately it is up to the endpoints and their users in particular, to determine which third parties they trust.
multimedia. Some ISPs that offer broadband access also deploy content distribution networks to increase the performance of streaming media. These services are typically deployed so that they are only accessible within the ISP's network, and as a result, they do not contribute to open, end-to-end service. From an ISP's standpoint, however, offering such service is an incentive for customers to buy the ISP's service. ISPs are not the only third party intermediary that has appeared within the last 10 years. Unlike the previous involvement of corporations and governments in running the Internet, corporate network administrators and governmental officials have become increasingly demanding of opportunities to interpose between two parties in an end-to-end conversation. A benign motivation for this involvement is to mitigate the lack of trust, so the third party acts as a trust anchor or enforcer of good behavior between the two ends. A less benign motivation is for the third parties to insert policy for their own reasons, perhaps taxation or even censorship. The requirements of third parties often have little or nothing to do with technical concerns, but rather derive from particular social and legal considerations.
Section 3.1. Thus, the issue of the trust breakdown can be considered another forcing function on the Internet architecture. The immediate reaction to this trust breakdown has been to try to back fit security into existing protocols. While this effort is necessary, it is not sufficient. The issue of trust must become as firm an architectural principle in protocol design for the future as the end-to-end principle is today. Trust isn't simply a matter of adding some cryptographic protection to a protocol after it is designed. Rather, prior to designing the protocol, the trust relationships between the network elements involved in the protocol must be defined, and boundaries must be drawn between those network elements that share a trust relationship. The trust boundaries should be used to determine what type of communication occurs between the network elements involved in the protocol and which network elements signal each other. When communication occurs across a trust boundary, cryptographic or other security protection of some sort may
be necessary. Additional measures may be necessary to secure the protocol when communicating network elements do not share a trust relationship. For example, a protocol might need to minimize state in the recipient prior to establishing the validity of the credentials from the sender in order to avoid a memory depletion DoS attack. RFC 3238 . This desire need not result in a violation of the end-to-end principle if the partitioning of functioning is done so that services provided in the network operate with the explicit knowledge and involvement of endpoints, when such knowledge and involvement is necessary for the proper functioning of the service. The result becomes a distributed application, in which the end-to-end principle applies to each connection involved in implementing the application. 10]. ISPs have certain concerns, businesses and government have others, and vendors of networking hardware and software still others. Often, these concerns conflict, and sometimes they conflict with the concerns of the end users. For example, ISPs are reluctant to deploy interdomain QoS services because, among other reasons, every known instance creates a significant and easily exploited DoS/DDoS vulnerability. However, some end users would like to have end-to- end, Diffserv or Intserv-style QoS available to improve support for voice and video multimedia applications between end nodes in different domains, as discussed by Huston in RFC 2990 . In this case, the security, robustness, and reliability concerns of the ISP conflict with the desire of users for a different type of service. These conflicts will inevitably be reflected in the Internet architecture going forward. Some of these conflicts are impossible to resolve on a technical level, and would not even be desirable, because they involve social and legal choices that the IETF is not empowered to make (for a counter argument in the area of privacy, see
Goldberg, et al. ). But for those conflicts that do involve technical choices, the important properties of user choice and empowerment, reliability and integrity of end-to-end service, supporting trust and "good network citizen behavior," and fostering innovation in services should be the basis upon which resolution is made. The conflict will then play out on the field of the resulting architecture.
 Saltzer, J.H., Reed, D.P., and Clark, D.D., "End-to-End Arguments in System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.  Clark, D., "The Design Philosophy of the DARPA Internet Protocols," Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, pp. 106-114.  Blumenthal, M., Clark, D.D., "Rethinking the design of the Internet: The end-to-end arguments vs. the brave new world", ACM Transactions on Internet Technology, Vol. 1, No. 1, August 2001, pp 70-109.  Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.  Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.  Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", Work in Progress.  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.  Kaat, M., "Overview of 1999 IAB Network Layer Workshop," RFC 2956, October 2000.  Clark, D.D., Wroclawski, J., Sollins, K., and Braden, B., "Tussle in Cyberspace: Defining Tomorrow's Internet", Proceedings of Sigcomm 2002.  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February, 2002.
 Carpenter, B., "Internet Transparency", RFC 2775, February 2000.  Reed, D., "The End of the End-to-End Argument?", http://www.reed.com/dprframeweb/ dprframe.asp?section=paper&fn=endofendtoend.html, April 2000.  Moors, T., "A Critical Review of End-to-end Arguments in System Design," Proc. 2000 IEEE International Conference on Communications, pp. 1214-1219, April, 2002.  Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.  Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.  Goldberg, I., Wagner, D., and Brewer, E., "Privacy-enhancing technologies for the Internet," Proceedings of IEEE COMPCON 97, pp. 103-109, 1997.
BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.