Internet DRAFT - draft-fisk-midcom-session

draft-fisk-midcom-session



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]