Internet-Draft Mike Fisk Expiration Date: May 2001 LANL/UCSD November 2000 An End-to-End Session Layer for Realm-Specific Networking draft-fisk-midcom-session-00.txt Status of This Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract: Application- and transport-layer gateways are considered harmful to the Internet since they hinder the operation of existing and new end-to-end protocols. A survey of such upper-level gateways shows that they exist because of realm-specific performance, security, and protocol needs of certain portions of the Internet. Expecting this realm-specific functionality to be added manually deployted to every end hosts or application is, conversely, harmful to the flexibility of using the Internet to link disparate networks. With the belief that these gateways will continue to exist, this document examines the requirements for a protocol architecture that allows gateways to explicitly interact with applications in extensible ways that do no prevent the growth of new protocols. End-to-end control over the connection is maintained, while permitting gateways to modulate protocol interactions. 1. Introduction The Internet was designed to remove the need for application-layer gateways between networks by allowing end applications to view a collection of networks as a single Fisk Expires May 17, 2001 [Page 1] Internet-Draft November 2000 abstract network that can be used to communicate directly with an application running on any other host on the network. The original Internet protocols were not specifically designed for the enomorous, popular, commercial network that we have today. While the protocols have scaled remarkably well, there are some fundamental concerns that are not addressed by the protocols. These realm-specific concerns, such as address allocation, security, and high performance over diverse link characteristics have resulted in a resurgence of application-layer gateways. These gateways are seen as both counter to the end-to-end argument and harmful to the transparency of the Internet. To fit the Internet model, the necessary functionality should instead be added to end-to-end applications and protocols. RFC 2775 [1] documents a wide-spread perception within the Internet community of a growing problem with `Internet transparency.' This commonly perceived problem is characterized as a loss of the basic technical characteristics of `a single universal logical addressing scheme, and the mechanisms by which packets may flow from source to destination essentially unaltered.' In short, Internet protocols are designed to run on an end-to-end datagram network, while current trends are creating perturbations in the Internet which routinely break end-to-end datagram connectivity and fate-sharing. These perturbations take the form of firewalls, network address translation, and other application-layer gateways. 2. Case Studies In each of the following case studies, we show that application-layer gateways are the result of functionality requirements that are beyond the control of the two end-points. As such, solutions to these problems will necessarily involve a third party. For example, a system using a private IP address needs to be able to use a global address to communicate with the Internet, but the pool of globally-unique addresses that a site owns is allocated by central system (implicitly with NAT [4,14], or explicity with Realm-Specific IP). In the case of mobile phones, the wireless network (or just its operator) may not support IP and may instead require the use of a specialized protocol such as WAP [5] that must be translated to IP by a gateway. Network providers may provide protocol boosters because the protocol implementations on most end systems do not work well with the link characteristics of that network. End-to-end protocols such as TCP could be made to deal with these networks, but if the link characteristic is relatively rare, it is unlikely that such a modification will become Fisk Expires May 17, 2001 [Page 2] Internet-Draft November 2000 widespread. It is difficult for a provider to sell a gigabit link if customers see poor performance, even the poor performance is purely due to inadequacies of their own end systems. Worse yet, one or both of the end users may not ever know that their traffic is being carried by a link that needs special protocol considerations for good performance. Most security professionals agree that security can be implemented best in end applications. However, those same people will agree that firewalls are necessary because end systems are notoriously buggy and ill-managed. Thus, many sites find it smart to impose authentication, authorization, and/or validation functions on all connections with the Internet. 3. End-to-end Tunnelling For some problems, there are straighforward, end-to-end protocol solutions. For example, TCP has been modified to include end-to-end support for the large window sizes necessary on networks with large delay-bandwidth products. To preserve end-to-end connectivity, many solutions, however, have resorted to tunneling traffic across realm boundaries When the sender of a packet is aware of the existence and requirements of a gateway, the sender can encapsulate the end-to-end packet with additional information for the gateway. The gateway can perform its functions on this additional information and then forward the original, end-to-end packet. Tunneling mode IPsec and Realm Specific IP use IP over IP encapsulation in this manner. IPsec tunneling [8] can be used to replace application-layer, authenticating proxies. Each packet is wrapped in an additional layer of authenticating IP headers. The gateway checks these headers, strips them off, and forwards the inner packet on to the destination. Realm Specific IP (RSIP) [2] allows a system to allocate a global address from a local gateway system. The internal system then uses that global address for outside communications, but tunnels the global traffic inside local packets to the gateway. The gateway strips the outer headers and sends the tunneled traffic onto the Internet. In the reverse direction, the gateway maintains a table of allocated addresses and tunnels incoming traffic to the appropriate internal system. 3.1 Generality Tunneling solutions only work if the sender can include all information that the gateway needs. For authentication and address translation, this has been demonstrated to be possible. For performance enhancing proxies, validating proxies, protocol translation, and congestion notification [13], however, it is still necessary to examine upper-layer Fisk Expires May 17, 2001 [Page 3] Internet-Draft November 2000 protocols. 4. Agility It can be argued that one of the reasons that the Internet has been so successful is that it created a flexible end-to-end network on which new applications such as the World Wide Web could be easily developed and used between any two cooperating systems. Explosive, unorganized growth is routine. When networks are designed so that application-specific gateways are necessary to provide connectivity to the Internet, this agility is lost. However, another key to the Internet's success is the ease of adding new types of networks and systems to the Internet. Because only basic, datagram functionality is required, it is relatively easy to add new networks to the Internet. If, however, that new network has realm-specific needs such as those described above, additional functionality may be necessary. Traditional, end-to-end protocol solutions involve placing knowledge in the end application about the requirements of the network. For completeness, the end applications must be prepared to handle the requirements of any realm that might exist in the Internet. In this case we have created the same kind of interdependency that the end-to-end paradigm seeks to avoid. Application-layer gateways are popular because they let functionality be implemented in centralized points rather than on each end system that may use that network. End customers and users drive the development and deployment of most end-system functionality and there is only marginal push to add support for specialized network needs. Almost eight years after the TCP window scaling option was created, a March 2000 sampling of 115143 web servers showed that less than 41% of them supported the option [15]. Worse yet, while features are commonly bundled in new software releases, users or administrators often have to enable them individually. So in practice, if gateways are not used and end-to-end protocols alone must fill the requirements, we also lose agility. 4.1 Solutions Gateways could be removed if we had ways to efficiently deploy equivalent functionality to all end-hosts. Current research in areas such as agent technology may someday solve this problem, but any such solution is over the horizon. Or we can assume that gateways will continue to exist for the foreseeable future and build end-to-end extensible protocols Fisk Expires May 17, 2001 [Page 4] Internet-Draft November 2000 that allow them to explicitly interact with applications in ways that do not prevent the growth of new protocols. 5. A Session Signalling Protocol For the remainder of this document, we explore models and requirements for such an extensible protocol that we, for lack of a better name, call a Session Signalling Protocol. In short, it is necessary to have a generic, extensible protocol that is applicable to all types of upper-layer gateways. The basic functionality should be provided at a higher level than the transport protocols (TCP, UDP, etc) and is consistent with a session-layer protocol. Tunneling solutions are not general enough since they allow extra information to be provided to gateways, but do not allow those gateways to participate actively in network connections. The SOCKS [9] protocol operates at approximately the right layer, but lacks extensibility. SOCKS tunnels TCP and UDP connection setup, and sometimes data, within the SOCKS application protocol. Since SOCKS encapsulates socket-level TCP, UDP, and IP information rather than a pre-formed IP packet, it does not provide the same level of end-to-end continuity that tunneling provides and that is required for protocols like IPsec. SOCKS only works for static, pre-configured paths through gateways and does not inherently support traversal of a series of gateways. So we envision a protocol that must support the composition a series of realm-specific transport and/or network layer connections into an end-to-end session. 5.1 Gateway Location and Negotiation SOCKS, IPsec tunneling, and Realm Specific IP (RSIP) are all existing mechanisms for interacting with network gateways. Of the three, however, only RSIP addresses how end applications discover these gateways. In the case of RSIP, the Service Location Protocol (SLP) [6] is used. SLP, however, does not scale to finding intermediate gateways on wide-area networks under multiple domains of control. To provide explicit communications between gateways and applications, it is necessary to have an automatic way to discover the gateways between two end hosts. All parties involved must then negotiate the necessary transport connections that will make-up the composition. To support alternate protocol suites such as WAP, the negotiation should focus on characteristics of the connection rather than specific protocols. As described below, there are multiple security aspects that must be included in this negotiation. 5.2 Gateway Changes During the lifetime of a session, routing changes or movement Fisk Expires May 17, 2001 [Page 5] Internet-Draft November 2000 of mobile systems may change the path through the network. The protocol must therefore determine when gateways are added or removed from the path. These changes to the gateway environment may also result in changes to the existing transport connections. The Mobile IP protocol [12] takes application traffic using a canonical address and tunnels that traffic to a gateway on the home network. Different tunneling paths may have drastically different congestion and flow control characteristics, but with Mobile IP, the transport connection remains established. For example, if a mobile system moves from a high-bandwidth LAN to a low-bandwidth wireless link, the transport protocol may immediately flood the network with traffic. Most TCP implementations will only discover the loss in available bandwidth after congestion occurs. In contrast, the addition or loss of a gateway cause the re-establishment of a transport protocol. 5.3 Encryption Gateways that perform auditing or validation of application-layer data will most likely not allow end-to-end encryption. Performance Enhancing Proxies may request unencrypted data as well, but should be willing to accept data that is encrypted from end-to-end. If the application is willing to operate without end-to-end encryption, it may still require that all traffic between validating gateways and/or end-hosts be encrypted. End-to-end encryption of application data can be handled by a higher layer, but may possibly be conveniently provided by the session layer implementation on the end systems. 5.4 Authentication The originator and authenticity of all data (in both directions) must be verifiable. Not all gateways may require this authentication, but the functionality must be present to support authenticating proxies. To support end-user authentication, the end-system implementation must be able to authenticate the user, either directly or through the calling application. Applications may also wish to know the identity of a gateway before agreeing to pass unencrypted data through it. The application would presumably have some out-of-band mechanism for assigning a level of trust to the identified gateway. 5.5 Multiple Connections There are certain applications that, like FTP, set-up secondary network connections. The session layer must allow these applications to refer to and identify these connections in an end-to-end manner. Further the session layer can signal to authenticating proxies that the secondary connection is part of the same session. Fisk Expires May 17, 2001 [Page 6] Internet-Draft November 2000 6. Conclusions The authors believe that the genericity of the concept of composing consecutive transport connections, together with an extensible session layer protocol for building those compositions, would bring the Internet closer to the goals expressed in the end-to-end arguments. It is true that networks absent of upper-layer gateways are more pure in end-to-end terms. However, it is not clear that it is practical to deploy the functionality of those gateways on end systems. The fact that there are realms in the Internet, and the networks connecting to it, that are owned, operated, and legislated by diverse groups with differing environments has created inter-realm boundaries. Those boundaries affect end-to-end protocols and must be addressed. The concepts outlined in this paper form an infrastructure for making that multi-party negotiation possible. The creation and deployment of a Session Signalling Protocol is not trivial. However, it could replace the implementation and deployment of several point solutions such as Realm Specific IP, SOCKS, Mobile IP, and other solutions not yet created. Many of the features of such a protocol are already provided by protocols such as SOCKS, IPsec, Transport Layer Security (TLS) [3], Group Secure Association Key Management Protocol [7] and authentication frameworks such as the Simple Authentication and Security Layer [11] and the Generic Security Service Application Program Interface [10]. References 1 Carpenter B. RFC 2775: Internet transparency, February 2000. 2 M. Borella and J. Lo. IETF draft-ietf-nat-rsip-framework-04.txt: Realm specific IP: Framework, March 2000. 3 0. T. Dierks and C. Allen. RFC 2246: The TLS protocol version 1, January 1999. Status: PROPOSED STANDARD. 4 K. Egevang and P. Francis. RFC 1631: The IP Network Address Translator (NAT), May 1994. 5 Wireless Application Protocol Forum. Wireless Application Protocol Architecture Specification, April 1998. http://www.wapforum.org/. 6 E. Guttman, C. Perkins, J. Veizades, and M. Day. Fisk Expires May 17, 2001 [Page 7] Internet-Draft November 2000 RFC 2608: Service Location Protocol, version 2, June 1999. 7 H. Harney, A. Colegrove, E. Harder, U. Meth, and R. Fleischer. IETF draft-harney-sparta-gsakmp-sec-01.txt: Group Secure Association Key Management Protocol, May 2000. 8 S. Kent and R. Atkinson. RFC 2401: Security architecture for the Internet Protocol, November 1998. 9 M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones. RFC 1928: SOCKS protocol version 5, April 1996. Status: PROPOSED STANDARD. 10 J. Linn. RFC 2078: Generic Security Service Application Program Interface, version 2, January 1997. 11 J. Myers. RFC 2222: Simple Authentication and Security Layer (SASL), October 1997. 12 C. Perkins. RFC 2002: IP mobility support, October 1996. 13 K. Ramakrishnan and S. Floyd. RFC 2481: A proposal to add Explicit Congestion Notification (ECN) to IP, January 1999. 14 P. Srisuresh and M. Holdrege. RFC 2663: IP Network Address Translator (NAT) terminology and considerations, August 1999. 15 Richard Wendland. A question about the deployment of SACK and NewReno TCP, March 2000. E-mail to IETF end2end-interest@isi.edu list. Author's Address: Mike Fisk Los Alamos National Laboratory MS B255 CCN-5 Los Alamos, NM 87545 USA EMail: mfisk@lanl.gov Fisk Expires May 17, 2001 [Page 7]