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]
