Internet Draft Melinda Shore, ed.
draft-shore-alias-fw-00.txt Cisco Systems
February 2004
Expires July 2004
Communicating With Transport Intermediaries: Discussion and Framework
<draft-shore-alias-fw-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 docu-
ments 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
In an increasingly complex internet it is becoming more common for
endpoints to want to influence the behavior of network devices, and
for those devices to want to communicate with endpoints for autho-
rization and policy discover. Frameworks and protocols are evolv-
ing for communication with application intermediaries and with net-
work edge policy enforcement devices. One area that has received
relatively little attention to date is communication between end-
points and transport intermediaries. This document presents a
problem statement and an overview of different communication mod-
els.
Shore [Page 1]
Internet Draft Alias Framework February 2004
1. Introduction
IP was originally designed around the end-to-end principle
[Saltzer] which says, among other things, that application function
should not be embedded in the network. This design was executed at
a time when the dominant values in the network were sharing and
maximizing communication reach.
As a rich set of network services and features has become avail-
able, however, there has been a growing reliance on network inter-
mediaries for policy enforcement, performance enhancement, defense
against attacks, and so on.
The IETF has taken on work on several subsets of the problem of
communicating with network intermediaries. The OPES working group
is tackling the problem of application intermediaries [Barbir],
while the MIDCOM working group is focusing on communicating with
firewalls and NATs [RFC3303]. The problem of communicating with
transport intermediaries, however, remains unaddressed.
Examples of services provided by transport intermediaries includes
TCP performance enhancements, multimedia packet filtering, header
compression, and prevention of denial-of-service attacks. These
services could be located in routers, switches, application gate-
ways, middleboxes, performance-enhancing proxies, or nodes of an
overlay network. To provide intermediary-based services they may
make use of the knowledge of aggregated and per-flow traffic behav-
ior at its location, as well as their processing, caching, and/or
filtering capabilities.
Various, uncoordinated pieces of work on explicit communication
with network devices have progressed in parallel in the IETF, and
different approaches and architectures have been developed. Each
introduces unique problems and benefits and it may be time to step
back and examine what we have (or have not!) learned so far.
[RFC3234] discusses different types of middleboxes and their asso-
ciated issues, but not the protocols used in sending policy and
other requests to them. This memo includes an attempt at catego-
rizing those protocols and architectures.
One of the critical problems introduced with explicit communication
between endpoints and network intermediaries is securing the commu-
nication. The solutions to that problem depend on a variety of
factors, including the nature of the communication, the direction
of the communication (endpoint to intermediary, or intermediary to
endpoints), the business relationships among the parties, and so
Shore [Page 2]
Internet Draft Alias Framework February 2004
on.
This document combines material from Blumenthal et al.'s earlier
internet draft on transport intermediaries [Blumenthal], Dawkins et
al.'s draft on transport triggers [Dawkins], and my internet draft
on different models for communicating with middleboxes.
2. Terminology
Endpoint: An end-user node including a PC, a laptop, a hand-held
device, etc. running user applications.
Intermediary: A network node including a router, a switch, an
application gateway, a middle box [RFC3303], a performance
enhancing proxy [RFC3135], or a node of an overlay network.
Middlebox: Any intermediary device performing functions other than
the normal, standard functions of an IP router on the datagram
path between a source host and destination host. See
[RFC3234] for a more complete discussion.
Off-path Signaling: "Off-path signaling" is a generic term refer-
ring to the establishment of an explicit policy request/commu-
nication connection between an application or an application
agent and a network device. It is called "off-path" because
the application agent may lie outside the application data
path. Also sometimes referred to as "path-decoupled signal-
ing."
On-path signaling: A generic term for referring to requests sent
along the same network path as the data messages they are
intended to affect. Also sometimes referred to as "path-cou-
pled signaling."
Relative topology: The relationship of network devices to one
another. Examples incude ordering of devices along a path, or
devices that are "next to eachother" topologically in a multi-
homed network.
3. Communication between endpoint and intermediary
3.1. Circumstances
Network end-points and network intermediaries may need to communi-
cate with each other to request and control intermediary-based
Shore [Page 3]
Internet Draft Alias Framework February 2004
services. In particular, the communication may serve functions
such as the ones described below.
+ Service discovery: The end-point may need to discover services
available from the intermediary. Service discovery might be
especially important in the case of mobile users, where mobile
users can roam into a foreign network and may need to discover
which intermediary-based services are available.
+ Service negotiation: The end-points should be able to negoti-
ate services and service options with the intermediary. Ser-
vice renegotiation might also be required due to any change in
requirements by the end-points or due to changing conditions
at the intermediary, or link changes that may be otherwise
invisible to the endpoint.
+ Service consent: The end-points must consent before the ser-
vices they are offered. There are two important reasons why
this consent must be provided by the end-points. First, the
end-points should have the ability to allow or deny access to
and possibly modification of end-to-end data. This is dis-
cussed in detail below. Second, there may be a charge associ-
ated with the services and an endpoint must be able to agree
or refuse to accept the charge.
+ Service configuration: The end-points and the intermediary may
need to exchange appropriate parameters for configuring the
intermediary-based services. Some of these parameters include
header formats, estimates of (or actual) resources required
for offering a service, identity of data flows etc.
+ Setting up trust relationships and security associations: The
end-points and the intermediary must be able to mutually
authenticate each other. This mutual authentication process
might involve other nodes such as a home agent or a home loca-
tion register in the case of mobile users. The end-points and
the intermediary will also need to exchange keys and set up
security associations to communicate securely. Separate secu-
rity associations will be required between each end-point and
the intermediary offering services and potentially between
intermediaries if multiple intermediaries are involved in
offering services. The end-points and the intermediary should
tear down security associations when intermediary services are
completed, revoked, or in the event of failures of the inter-
mediary or the end-points.
Shore [Page 4]
Internet Draft Alias Framework February 2004
+ Transfer of state: The intermediary might need to transfer
state information associated with the services it has negoti-
ated and is currently offering, or other security related
information (cryptographic counters, keys, etc.) to another
intermediary in the case of an impending failure, for load
balancing or due to user mobility.
Although intermediaries might voluntarily offer some services with-
out requiring any explicit communication with the end-points, this
will not be true when end-to-end security that protects entire
packets (e.g. IPsec) is used. When end-to-end security is used,
end-points must explicitly communicate with the intermediary for
setting up services and assist an intermediary with the information
required to offer services. In this document, we are interested in
only those services that require explicit communication between
end-points and the intermediary.
3.2. Transport "triggers"
It may be desirable in some circumstances to inform transport lay-
ers in end-points of network events or changes to link characteris-
tics. For example, if a link goes down or comes back up, a reach-
able endpoint should be informed.
3.2.1. Justification for transport triggers
The variety of devices accessing the Internet, and the variety of
access links they are using, continues to increase. At least some
of these links exhibit characteristics that cause some Internet
protocols, especially TCP, to perform poorly.
Among these characteristics are: 1. Intermittent connectivity, 2.
Access path changes ("hand-offs"), and 3. High uncorrected error
rate
For example, TCP congestion control [RFC2581] performs well over
paths that lose traffic primarily because of congestion and buffer
exhaustion, but performs poorly when TCP connections traverse links
with high uncorrected error rates. Sending TCPs spend an inordinate
amount of time waiting for acknowledgements that will not arrive,
and then, although these losses are not due to congestion-related
buffer exhaustion, the sending TCP transmits with a substantially
reduced congestion window as it probes the network to determine its
"safe" traffic level.
Shore [Page 5]
Internet Draft Alias Framework February 2004
The root cause here is that TCP sees only one (implicit) signal
about path conditions -- packet loss -- and can interpret this sig-
nal in only one way. The most conservative assumption is that
packet loss is due to congestion, and for most of TCP's history,
this conservative assumption was correct and sufficient. When
transports traverse paths that include intermittent connectivity or
other non-congestion "challenges", additional detection mechanisms
are required.
In a nutshell, the minimal TRIGTRAN architecture looks like:
+------+ +-----------------+ (Internet +------+
| Host | | TRIGTRAN Router | goes | Host |
+------+ +-----------------+ here) +------+
X X
Sub-network Event ------------------> Notifies Transport
Here Here
Figure 1
The critical feature here is that the host receiving a TRIGTRAN
trigger is across an arbitrary network topology from the TRIGTRAN
edge router sending the trigger. The host receiving the trigger
then takes some transport-level action (sending a packet, retrans-
mitting a packet, waiting for some period of time to transmit a
packet, etc).
The transports would figure out "most events" eventually, given
enough time (i.e., round trip times). For instance, TCP is good at
figuring at bandwidth changes, but not as good at detecting a
remote link transitioning to the "up" state after a retransmission
timeout. Eventually, a backed-off RTO timer will fire, and the now-
accessible receiver will acknowledge the next (successful) retrans-
mission, but the sender and receiver will be waiting when they
could be communicating.
TRIGTRAN can give the host receiving triggers hints that it might
reattempt transmission, without waiting a complete RTO interval.
TRIGTRAN is intended to provide network-based hints that clue the
transport in more quickly (where "quickly" is measured in RTTs, not
in milliseconds).
TRIGTRAN triggers are advisory in nature -- they do not replace
transport-level mechanisms (in the case of TCP, the receiver's ACK
stream). Indeed, the TRIGTRAN architecture is a continuum of an
existing body of work based on the principle that more and more
Shore [Page 6]
Internet Draft Alias Framework February 2004
often the network can clue a transport in on what is going on. Pre-
vious examples of "network-based clues" include ICMP Source Quench
and Explicit Congestion Notification (ECN). These methods are a
way for the transport to obtain more clues from the network but
without relying exclusively on that information to function prop-
erly.
3.2.2. Trigger events
This section presents some of the event types for which a trigger
might be desired. These triggers were identified by the PILC work-
ing group as things transports would want to know but that are dif-
ficult to discover using end-to-end signaling. For instance, "Con-
nectivity Interrupted" can't be signaled end-to-end, by definition.
Trigger: Connectivity Interrupted
Motivation: When a link goes down TCP RTO exponential backoff
occurs. The sender will eventually "give up", assuming that
the receiving TCP (and perhaps the receiving host) will not
recover.
Trigger: Connectivity Restored
Motivation: When a link returns to working state, an other-end
TCP may have experienced RTO, and may be waiting to attempt
retransmission. Since TCP backs off exponentially (up to 64
seconds between retransmission attempts, in common implementa-
tions), the receiver will be waiting unnecessarily.
Trigger: Packets Discarded by subnetwork, not lost due to conges-
tion
Motivation: In some wireless handoff scenarios, a subnetwork
may explicitly discard packets at the "old" base station. In
these cases, the application will either Fast Retransmit/Fast
Recover or RTO/Slow Start (depending on whether additional
ACKs are received for packets delivered by the new base sta-
tion). These losses will reduce the congestion window,
although they are not caused by congestion.
3.3. Exposing information
Another extremely important aspect of enabling intermediary-based
services is selective exposure of information to an intermediary by
Shore [Page 7]
Internet Draft Alias Framework February 2004
the end-points. This information might be required by the interme-
diary to provide the requested services to the end-points. Typi-
cally, in order to provide service, an intermediary may need to
access protocol headers in data packets. Exposing information to
an intermediary becomes complex when end-to-end security mechanisms
that protect the entire contents of data packets, such as IPsec,
are used.
When IPsec ESP [RFC2401] is used between two end-points, the entire
IP packet except for the outer IP header might be encrypted using
keys known only to the end-points, and none of the upper layer
headers (including the inner IP header in the case of IP encapsula-
tion) are accessible to the intermediary. How to expose informa-
tion to an intermediary while maintaining an acceptable level of
end-to-end security is a very challenging problem. Currently,
there is no standard way of exposing and accessing protocol headers
when an end-to-end security protocol such as IPsec ESP is used.
There are several critical dimensions of the problem of selectively
exposing information. These are described below.
+ Information that can be exposed: The information that could be
exposed to an intermediary will depend upon the nature of the
requested service. In some cases only the transport and net-
work layer information will need to be exposed to the interme-
diary. For example, an intermediary providing a TCP PEP ser-
vice [RFC3135] will need access to the TCP headers. In other
cases upper layer information might be required at the inter-
mediary to offer services. For example, when an intermediary
is providing a service to filter out low priority multimedia
packets during network congestion [Keller], it might require
access to the multimedia transport headers to find out the
packet priority.
+ Where the required information is located: It is not enough to
agree upon what information will be exposed to the intermedi-
ary. The intermediary may not know where to find it in the
packet. The end-points may have to help the intermediary find
the exposed information.
+ Who decides what information can be exposed: One of the impor-
tant questions in relation to exposing information is who
decides what information could be exposed. We believe that in
most of the cases the end-points should decide what informa-
tion should be exposed to an intermediary. This is because,
based on the services they require, the end-points know their
own security requirements and are in the best position to
Shore [Page 8]
Internet Draft Alias Framework February 2004
decide what should be exposed to the intermediary.
+ Method for exposing information: The end-points will need new
methods for selectively exposing information to an intermedi-
ary. The end-points must assist the intermediary in finding
the exposed information. Current security standards (such as
IPsec) allow either full exposure of all the data from the
end-points or no exposure of any end-point data other than the
outer IP headers.
All the above issues related to exposing information are dependent
upon the services offered by the intermediary and the service and
security requirements of the end user application. It is very
important to note that not all intermediary-based services require
exposing end-to-end information to the intermediary. Some services
could be built by using information that is usually visible even
when end-to-end security mechanisms are used. An example of such a
service is described in Section XXX.
Based on the discussion in this subsection, the problems of expos-
ing information could be classified as follows:
1. All communications between end-points are end-to-end
encrypted.
2. Communications between end-points are authenticated end-to-end
but not encrypted, allowing inspection but not modification of
information.
3. Some of the information exchanged between end-points is
exposed to the intermediary for inspection as well as modifi-
cation and the end-points assist the intermediary in finding
that information.
3.4. Preserving Security
Preserving acceptable security and allowing an intermediary to per-
form its services while selectively exposing information to an
intermediary is a challenging task. Once again, this aspect of the
larger problem is multi-dimensional. These dimensions are dis-
cussed below:
+ Trust between end-points and the intermediary: A trust rela-
tionship between the end-points and the intermediary is one of
the most fundamental issues in enabling intermediary-based
services. The end-points and the intermediary must trust each
Shore [Page 9]
Internet Draft Alias Framework February 2004
other with the information that is exposed and the services
that are offered and obtained. Mechanisms necessary to build
and maintain this trust must be investigated.
+ Detecting and responding to any inappropriate behavior of
intermediary: The trust model between the end-points and the
intermediary requires that the intermediary would not use the
information exposed to it to obtain services to attack the
end-points or play "end-to-end" games, such as reordering
packets. Trusting the intermediary does not imply that the
end-points should not detect and respond to inappropriate
actions of the intermediary. The questions of how end-points
detect any inappropriate behavior of the intermediary and how
they respond to the inappropriate behavior need to be
addressed.
+ Exposed information accessible only to intended recipients: An
important dimension of the problem of preserving acceptable
end-to-end security is how should the information exposed to
the intermediary be secured from the rest of the network.
Additional security layers might be required to achieve this.
One potentially serious problem with exposing information to
an intermediary is how to prevent it from sharing the exposed
information with other entities in the network. Unfortunately
it does not seem that this problem can be solved.
+ Security associations: The end-points and the intermediary
need to set up security associations among themselves for
secure communication. One approach to setting up security
associations is to set them one-to-one, i.e., only two nodes
(among the two-end points and the intermediary) are part of a
single security association. Alternately, as proposed in
[Zhang], it is possible to have, composite security associa-
tions or one-to-many security associations that involve more
than two nodes, e.g., both end-points and the intermediary.
As before, how security is preserved will depend upon the nature of
the end-user applications and the intermediary-based services being
offered.
4. Problem scenarios
The problem described in the previous section manifests itself in
several intermediary-based transport services. We now describe
representative intermediary-based services scenarios.
Shore [Page 10]
Internet Draft Alias Framework February 2004
4.1. TCP performance-enhancing proxies
Enhancements to transport protocols such as TCP over error prone
and bandwidth-limited links has been an area of study for almost a
decade. Particularly, when wireless links are involved, the vari-
ance in delay is found to be an important factor influencing TCP
performance [Chan]. Large delay variance decreases the effective
client throughput of all TCP-based applications. An accepted mech-
anism for enhancing TCP performance in such situations is the
implementation of a TCP performance-enhancing proxy (TCP-PEP) at
the intermediate node. The TCP-PEP can examine, modify or generate
TCP packets to match the characteristics of the wireline interface
to that of the wireless interface, improving end-to-end TCP perfor-
mance. More details on performance enhancing proxies that mitigate
link degradations are presented in [RFC3135].
Figure 2 shows an example of TCP throughput enhancement for a
mobile wireless user. In this figure, the mobile user is communi-
cating with a server using TCP. An intermediate TCP-PEP regulates
the acknowledgments [Chan] from the mobile host to account for the
large variations in wireless delay experienced by data flowing
towards the mobile node, thereby enhancing overall TCP throughput.
+---------------+
---- | |
/ // \\ | |
+------+ /--/ | TCP | | |
| | / | PEP | ------------ | Server |
*------* | | Wireline | |
/--------\ \\ // Network | |
---- | |
Mobile User +---------------+
Data
<--------
Acks
-----> Regulated Acks ->
<---------------- TCP connection ------------->
Figure 2
Shore [Page 11]
Internet Draft Alias Framework February 2004
4.2. Header compression and decompression
A problem with IP over cellular links when used for interactive
voice conversations is the large header overhead. Speech data for
IP telephony will most likely be carried by RTP. A packet will
then, in addition to link layer framing, have an IPv4 header (20
octets), a UDP header (8 octets), and an RTP header (12 octets) for
a total of 40 octets. With IPv6, the IP header is 40 octets for a
total of 60 octets. The size of the payload depends on the speech
coding and frame sizes being used and may be as small as 15-20
octets.
Compressing protocol headers over wireless access links will help
save expensive wireless bandwidth [RFC1144, RFC3095]. Even though
it is possible to achieve header compression between the two end-
points of an IP tunnel or two adjacent IP hops, most of the header
compression schemes are sensitive to delays and loss between the
end-points. [Degermark] shows that the average header size
increases significantly in the presence of high packet loss. In
[Dorward] the authors show the impact of delay on the efficiency of
their header compression scheme.
Achieving header compression and decompression close to a congested
link with the help of an intermediary can help in improving perfor-
mance of the header compression schemes. One might argue that if
the last hop wireless link is the only congested link that con-
tributes most of the loss and delay, then an intermediary based
header compression mechanism will not necessarily improve perfor-
mance over end-to-end header compression. This is not the case
when both the end-points are wireless users. Single wireless links
are also being increasingly replaced by a multi-hop paths where
multiple bandwidth-limited and lossy links might be present.
Implementing end-to-end header compression in such situations will
result in partial gains only. An intermediary-based header com-
pression scheme with an intermediary assisting every wireless or
bandwidth-limited link will help immensely in improving the perfor-
mance of header compression by providing lower loss and delay.
One can use multiple protocols to achieve intermediary-based header
compression in an efficient manner. For example, the Secure Real-
time Transport Protocol (SRTP) [Baugher] could be used to secure
the Real-time Transport Protocol (RTP) payload, while leaving the
IP/UDP/RTP headers accessible to the intermediary allowing header
compression using Robust header compression (ROHC), for example, at
the intermediary.
Shore [Page 12]
Internet Draft Alias Framework February 2004
Robust Header Compression (ROHC) [RFC3095] has been proposed as a
means to effectively compress headers at all layers up to and
including the IP Layer. ROHC is a stateful compression mechanism
relying on state maintained at the compressor/decompressor to maxi-
mize the compression efficiency of packets exchanged while tolerat-
ing lossy and high-latency links. ROHC is a hop-by-hop compression
mechanism where a hop could be a physical link or a virtual link
spanning multiple physical links (path). The use of end-to-end
IPSec would reduce the efficiency drastically due to encryption of
the IP payload via ESP. In such an environment, compression must be
performed before encryption for any benefit. In such cases, com-
pression can be applied only to the IP payload, not including the
ESP and AH headers that are added by IPSec. These headers con-
tribute an additional 20 bytes of overhead that is still signifi-
cant compared to the payload especially for VoIP applications. A
trusted intermediary instead could perform IPSec so as to avoid
this overhead on bandwidth-constrained links.
An additional problem with stateful compression schemes like ROHC
is that they do not tolerate reordering of packets. UDP is a con-
nectionless protocol in which packets can arrive out of order due
to the random routing of packets. ROHC is intended to be applied
hop-by-hop where there is less likelihood of packet reordering.
Thus, end-to-end header compression would not work well unless
there is an additional reordering mechanism that is enabled before
packets reach the decompressor. The routes need to be pre-config-
ured for compressed packets which is not a viable alternative in an
end-to-end approach. However, an intermediary router could assist
in such cases by negotiating, for example, an MPLS label-switched
path such that all compressed packets are assigned the same label.
An intermediary could also assist in ordering packets at the penul-
timate hop before the decompressor, so that they can be delivered
in-order to the decompressor.
Alternative compression mechanisms include IP payload compression
(IPComp) [RFC2393], which compresses the entire IP payload in a
manner involving less state than ROHC. This scheme does not suffer
from the reordering problems of ROHC but is not as efficient as
ROHC since each packet is compressed independently.
It should be noted that end-to-end header compression is not a
viable alternative if intermediate routers are not aware of the
compression. Compressing TCP headers at the end-host makes it dif-
ficult for firewalls or border routers to classify and route pack-
ets using 5-tuple filtering (IP source and destination addresses,
TCP protocol, source and destination ports) since none of the
Shore [Page 13]
Internet Draft Alias Framework February 2004
header fields can be inspected after compression unless the inter-
mediaries are participating in a security association with the end-
host. Since intermediaries need to be trusted anyway, it might be
beneficial to place some of the functionality in the intermediaries
to improve the performance. Essentially, there is a tradeoff
between performance and security, where leaving the headers open to
an intermediary allows header compression for performance but
requires a separate "trust" relationship between the end-point and
the intermediary.
4.3. Application-layer proxies
While application proxies frequently terminate and re-originate
application data streams, they also may inspect application headers
and payloads in order to improve performance as well as perfom
application specific functionality such as buffering and forwarding
application packets. This requires that the application headers be
left in the clear. A popular example is a proxy for the Session
Initiation Protocol (SIP). SIP is an application-layer control
(signaling) protocol for creating, modifying, and terminating ses-
sions with one or more participants. These sessions include Inter-
net telephone calls, multimedia distribution, and multimedia con-
ferences. SIP signaling requires that a user contact a SIP proxy
in order to initiate and maintain the SIP connection. Specifi-
cally, the "To" and "Via" header fields in SIP requests need to be
visible to SIP proxies to allow correct routing. Also, SIP pro-
vides a registration function that allows users to upload their
current locations to proxy servers, so that proxy servers can route
requests correctly.
SIP requires a tight integration with an IPSec implementation, with
a pre-configured SA between the user and the proxy server. While
SIP can be used with IPSec, creating a separate tunnel between the
end-host and the SIP proxy in order to allow the SIP proxy to pro-
cess signaling packets from the end-user introduces additional
expense. Creating tunnels at each hop leads to significant over-
head and is not how end-to-end IPSec was designed to be used.
A secure version of SIP (SIPS) relies on Transport Layer Security
(TLS) to encrypt signaling messages over TCP. TLS differes from
IPSec in that it is most suited to architectures in which hop-by-
hop security is required between hosts with no pre-existing trust
association. Thus, an intermediary assisting in SIP signaling
without the overhead of IPSec would use a more appropriate hop-by-
hop scheme like TLS for better peformance. However, TLS does leave
the TCP header in the open, which potentially compromises security.
Shore [Page 14]
Internet Draft Alias Framework February 2004
Additionally, QoS can also be specified in the SIP requests using
the session description protocol (SDP) payload of SIP messages
[RFC2327] and the UPDATE request [RFC3311]. The SIP proxy aids in
the negotiation of QoS and actually can be allowed to modify the
SDP payloads in SIP message bodies. However, if end-to-end authen-
tication/encryption is used, SIP proxies are not able to alter the
SIP message bodies according to [RFC3261], primarily due to the
end-to-end security mechanisms offered by the secure version of
SIP. In order to overcome the restrictions on the proxy there have
been several recent IETF drafts [Rosenberg2, Hilt] proposing new
SIP headers that can carry QoS information regarding the session.
SIP proxies can change SIP headers during the QoS negotiation phase
instead of modifying SDP, thus complying with RFC 3261. However,
if the headers are encrypted by IPSec this would thwart any useful
processing by the intermediate SIP proxy.
4.4. Stateful firewalls
Stateful firewalls such as those from Checkpoint [Checkpoint] are
tightly integrated with applications and can function as applica-
tion/transport proxies as well. They are capable of checking for
violations in upper layer protocols such as TCP connection state,
full packet header information (source address, destination
address, protocol, source port, destination port, packet length),
TCP/IP fragmentation data (fragment number, sequence number),
packet reassembly, and application type, among others. For exam-
ple, TCP packet reassembly is a popular function of most stateful
firewalls. Without this capability, an attack can conceal mali-
cious code or viruses in fragmented packets causing severe damage
to the network as well as the users.
Most of this information will be hidden to the firewall if IPSec
with ESP is in use, potentially compromising the security of the
application. It is unlikely that a "weak" entity such as a mobile
phone can ever perform the type of checks that a stateful firewall
is capable of. Furthermore, intrusion detection systems also bene-
fit by looking at such information in order to detect DoS attacks.
These security mechanisms would be rendered useless if an end-to-
end security mechanism like IPSec is used.
Note that IPSec provides a semantic of end-to-end security but does
not really guarantee it, nor does it provide a mechanism for pro-
tecting a network. It is up to the end-points to ensure that they
follow the guidelines. If end-points do not follow the IPSec
guidelines, the concept of end-to-end security becomes moot. Fur-
thermore, because it is an end-to-end mechanism it provides no
Shore [Page 15]
Internet Draft Alias Framework February 2004
border policing capabilities like those provided by network inter-
mediary devices such as firewalls and security gateways. For net-
work (as opposed to host or application) security, it is more reli-
able to rely on a trusted intermediary such as a corporate firewall
to protect a corporate network than it is to expect end-to-end
mechanisms to provide sufficient protection.
4.5. QoS provisioning, differentiated services, and packet classifica-
tion
An intermediate node may identify flows based on source and desti-
nation IP addresses, TCP/UDP source and destination port numbers,
IPsec security parameter index (SPI), and next protocol identity to
offer quality of service guarantees and differentiated treatment to
certain packets. It may also use the DSCP (Differentiated Services
Code Point) bits in the IP header or even application layer infor-
mation to treat packets differentially. The TOS byte can be used
to store the DSCP and enable packet classification. It should be
noted that IPSec in tunnel mode copies the ToS byte to the outer
header potentially allowing modifications by intermediaries.
For example, the intermediate node could assign lower priority to
non-conforming UDP traffic and a higher priority to TCP traffic
during link congestion. An intermediate node could use the secu-
rity parameter index in IPsec packets together with the IP destina-
tion address to identify flows for providing RSVP-based quality of
service. (This assumes that RSVP signaling [RFC2702] is used to
create the required state in the intermediate node.) These exam-
ples show that packets could be classified using multiple fields.
A specific classification method and policy implementation will
depend on the application.
Figure 3 shows an example of filtering packets based on multimedia
transport information. In this figure, multi-layer video is uni-
cast from the source to the receiver. On observing link conges-
tion, the intermediate node in the path from the source to receiver
selectively drops packets of lower priority layers. The identity
of the layers is found in the multimedia transport header. The
intermediate node performing the selective dropping must have the
knowledge of the multimedia transport header format. Keller
[Keller] has demonstrated dramatic improvements in video quality by
using one such scheme.
Shore [Page 16]
Internet Draft Alias Framework February 2004
+---------------+
---- | |
Congested // \\ | |
+------+ Link | Packet | | |
| |-------------- | Filter | ------------ | Video Source |
*------* | | | |
/--------\ \\ // | |
---- +---------------+
Video Receiver Drop lower
priority layers
<--------------------------------------------------
Multi-layer Video
Figure 3: Selective Video Filtering
4.6. Prevention of denial-of-service attacks
There is a variety of DoS attacks that can be launched against end-
hosts, and the impact is particularly severe on wireless endpoints
due to the limited wireless link bandwidth, processing power of
mobile handsets, and the battery lifetimes of these nodes. It is
significantly easier for an attacker to launch a wireless DoS
attack with much less traffic affecting more end-points than it is
against a wire-line network. Thus, the use of firewalls and other
security mechanisms such as VPNs is necessary.
Intermediate nodes may be configured to filter out packets from
unwanted sources to enterprise virtual private network (VPN)
clients. Enterprise VPN clients commonly establish secure sessions
with their enterprise gateways for accessing their company
resources (computers and servers). However, if one relies on
IPSec, this would prevent the correct operation of firewalls since
there is no mechanism to inspect the encrypted IP payload for IPSec
packets unless the firewall is co-located with the IPSec gateway.
Clients, especially bandwidth-limited wireless mobile enterprise
users, potentially can be flooded with unwanted packets from IP
addresses outside the enterprise or even spoofed enterprise IP
addresses via IPSec tunnels.
Once the packet reaches the mobile nodes the attacker has already
succeeded in launching a DoS attack by congesting the wireless
infrastructure, including the processing elements such as RNC,
PDSN, and base stations as well as attacking the end-points (by
draining the battery on mobiles).
Shore [Page 17]
Internet Draft Alias Framework February 2004
Instead, these unwanted packets could be ingress-filtered at an
intermediate node (e.g., a public data service node) in the path
from the enterprise client to the enterprise gateway by setting up
an additional authentication tunnel between the enterprise gateway
and the intermediate node. On receiving packets with source
addresses set to valid enterprise IP addresses, the intermediate
node allows only those packets that it can authenticate and drops
the rest.
+---------+
Attacker sends address-spoofed, | |
IPsec encrypted packets to the VPN Client | Attacker|
| |
+---------+
Wireless |
Access |
Network |
------ ------- | +-----+
// \ \ // |\ | |
/ | +------+ | | | | |
+---+ /--/ | |Packet|<---|---------- | | |
| | / | |Filter|---| |--| |
*---* | | | | | | |
/-----\ | +------+ | | | |
\\ // \\ // | |
------ ------- +-----+
VPN Client Internet Enterprise
VPN Gateway
-----------------------------------------------------
End-to-End IPsec Tunnel
-----------------------------------------------------
Figure 4: Prevention of Denial-of-Service
4.7. Network address translation
IPv4 has a limited range of addresses which are rapidly being
exhausted. As a result, Network Address Translation (NAT) [22] is
becoming increasingly popular, allowing a single IP address to be
multiplexed among different end-hosts. ISPs often use NAT to maxi-
mize their use of internet addresses. NAT also provides a modest
degree of security against some attacks since the attacker does not
know the real IP address of the end-host. Unfortunately, IPSec
mechanisms which are intended to protect the source and destination
addresses of an IP packet will not work with NAT. Address
Shore [Page 18]
Internet Draft Alias Framework February 2004
translation requires the NAT translator to modify the IP addresses
for all packets. In a typical IPSec with ESP implementation, this
would be impossible since the IP header is encrypted. Decrypting
this would require an SA to be pre-configured between the NAT proxy
and the end-user requiring "trust" relationships to be established.
4.8. Scenario summary
In the above scenarios, an intermediary must have access to the
protocol headers (TCP, RTP/UDP/IP) to offer the services. If end-
to-end, network-layer security solutions such as IPsec ESP are
used, the protocol headers are not accessible to the intermediary.
The problem here is to enable the end-points and the intermediary
to negotiate services and configure services, as well as allowing
the intermediary secure access to the protocol headers. In the DoS
scenario, the problem is to set up the additional authentication
tunnels with the help of a communication protocol between the
intermediary and the end-points to prevent denial-of-service
attacks. In stateful firewalls, all packets pass through the fire-
wall and must be examined.
Bandwidth-constrained wireless networks are particularly incapable
of handling the overhead introduced by IPSec due to the scarce
bandwidth and lossy links with long RTTs. Instead of an IPSec
implementation, users may instead choose to rely on link layer
encryption and/or transport layer security solutions such as TLS,
while allowing compression of headers. The use of an intermediary
would greatly increase the performance, without compromising secu-
rity, assuming that the intermediary can be trusted.
It should be noted that introducing intermediaries does potentially
open up new points of attack, namely the intermediaries themselves.
An attacker could simply flood the intermediary itself to bring it
down. This is an inherent drawback of any centralised, stateful
system and is orthogonal to the issues described in this document.
Scalability is another orthogonal issue that arise if the interme-
diary is centralised or co-located with a firewall, for example.
Finally, the trust relationship is hard to define. The trust can
be abused in indirect ways -- for example, the intermediary could
inspect addresses from the user packets and determine the location,
exposing the network topology and raising privacy issues.
5. Models for middlebox communication
There have been various efforts to develop mechanisms for communi-
cating with other kinds of network intermediaries, such as
Shore [Page 19]
Internet Draft Alias Framework February 2004
application intermediaries and security intermediaries. These
mechanisms have been based on different communication models, which
are presented and discussed below.
5.1. Endpoint/Proxy-initiated approaches to middlebox communication
In this section we look at architectures in which the signaling or
middlebox communication request is initiated by a network endpoint
or its proxy. When an application running across a network recog-
nizes that it requires special services from the network, such as
QoS for a particular data stream, a firewall pinhole, a security
policy modification, etc., it initiates a request. This function
may be proxied by another entity acting on behalf of the endpoint.
This is distinct from models in which a middlebox initiates commu-
nication with an endpoint or another device, which we discuss
later.
Also, note that we tend to use the phrases "signaling," "middlebox
requests," and "middlebox communication" interchangeably throughout
and probably should not.
5.1.1. Client-server approach
This is probably the most basic model for sending requests to a
network device. It is the one assumed by midcom, an IETF working
group defining a protocol specifically to make requests of middle-
boxes, in this case firewalls and NATs (although the intention was
to devise something general enough to support a variety of middle-
box uses). The client-server approach is one mechanism used for
off-path signaling but it is not the only one.
In this case an endpoint, or an agent acting on behalf of the end-
point (for example, a VoIP call control server), initiates a con-
trol connection to a middlebox and sends requests, which are
granted or denied by the middlebox based on local administrative
policy. An agent may be in communication with multiple middleboxes
or a middlebox may be in communication with multiple agents, but
the basic communication model remains the same (Figure 5 shows the
Shore [Page 20]
Internet Draft Alias Framework February 2004
middlebox control model -- no data streams are shown).
+-----------+
| |
| |
| Agent |
| |
| |
+-----------+
/ \
/ \
+-----------+ \+------------+ +------------+
| | | | | |
| | | | | |
| Host 1 | | Middlebox | | Host 2 |
| | | | | |
| | | | | |
+-----------+ +------------+ +------------+
Figure 5
This model raises a number of architectural issues, not the least
of which are location and routing. An agent has to know if there
are middleboxes along a given data path and if it has knowledge of
multiple middleboxes it has to be able to determine which are rele-
vant and which are not. An even more difficult problem is that it
may be the case that if there is more than one middlebox along a
path, requests could potentially be sensitive to topological order-
ing within the network. This is particularly true when one of
those middleboxes is a NAT and packets' transport addresses are
being altered in transit.
A clear advantage of using a client-server model for middlebox
requests is that the security model is relatively simple, with the
ability to authenticate and authorize being artifacts of a
straightforward relationship between the agent and middlebox as
well as whatever policy mechanisms are available.
Other examples of this kind of protocol include SOCKS [RFC1928],
TURN [Rosenberg]
Shore [Page 21]
Internet Draft Alias Framework February 2004
5.2. On-path signaling
On-path signaling sends middlebox requests along the same path (or
is hoped to be the same path) that will be traversed by the associ-
ated data stream. Probably the best-known protocol and architec-
ture used for on-path signaling is RSVP [RFC2205], and while RSVP
was originally used to carry IntServ requests it has been general-
ized somewhat to extend its use for establishing MPLS LSPs
[RFC3209]. There have been proposals to use RSVP for other middle-
box communication applications [Shore], and there are plans to sup-
port middlebox communications in the IETF's next on-path signaling
protocol [NSIS].
In on-path signaling, a request is sent between the two hosts orig-
inating and terminating a data stream. That is to say that the
source and destination addresses in the signaling request are the
same as those of the data stream (or proxies acting on behalf of
either or both endpoints). Requests are not addressed directly to
the middleboxes. Instead, something in the packet, for example a
router alert or a transport protocol port number, can be used to
indicate that the request is one that should be intercepted and
acted upon by the middlebox. Figure 6 shows the middlebox communi-
cation model (again, no data streams are shown).
+------+ +-----------+ +-----------+ +------+
| |------->| |---->| |--->| |
|Host 1| |Middlebox 1| |Middlebox 2| |Host 2|
| |<-------| |<----| |<---| |
+------+ +-----------+ +-----------+ +------+
Figure 6
In RSVP, path state (routing) is established as the request flows
from Host 1 towards Host 2, while reservation state is confirmed
and installed in the reverse direction, as the request flows from
Host 2 towards Host 1. This need not necessarily be the case.
This model has some clear advantages around topological issues
(discovery, routing, relative topology), and it can be used for
topology discovery and determination. One example of this is the
Tunnel Endpoint Discovery protocol, which is used to discover IPSec
gateway locations in order to establish IPSec tunnels. An entry
gateway injects a message into the network towards the destination
address of a data flow. The message is intercepted by an IPSec
Shore [Page 22]
Internet Draft Alias Framework February 2004
gateway and returned to the originating gateway which then initi-
ates an IKE session with the discovered gateway, bringing up an
IPSec tunnel.
There are several associated disadvantages. One is that the sig-
naling model is path-oriented, which suggests the existence of a
path, or at least a source and destination. A protocol like this
is not useful for provisioning or configuration. For example, a
path-coupled signaling protocol is unsuitable for sending a message
to a middlebox asking for specific QoS treatment for all traffic.
While individual requests can be sent out to request service for
each data stream, clearly this generates more traffic and cannot
solve certain middlebox problems such as asking for a more-or-less
static firewall pinhole for accepting incoming requests (on well-
known ports, for example).
Another difficulty is that the security model can be somewhat
murky. While endpoint (request initiator) credentialing can be
done, message authentication can be a problem in an environment
where nodes along the path may be modifying the contents of the
request and you might not have an existing relationship with other
nodes along the path. Authorization is difficult in the absence of
existing relationships, as well.
The most straightforward approach to securing middlebox requests in
this environment is to secure traffic between adjacent hops and
rely on transitivity. Security may not actually be transitive in
all situations, and it is sometimes unclear what a "hop" is, par-
ticularly when the protocol is being used to support a variety of
uses and any given node may not be relied upon to be participating
in a particular use.
5.3. Middlebox-initiated approaches to middlebox communication
In some instances, middleboxes may choose to consult with a sending
endpoint or with another device for further information on how to
process a packet. In these cases, the middlebox initiates a
request.
5.3.1. Callback protocols
In some cases, a middlebox may decide to contact a packet's sender
either to request additional information (say, credentials) or to
send it a notification. Obvious, early and crude examples of this
kind of use include ICMP messages like source quench and various
unreachables.
Shore [Page 23]
Internet Draft Alias Framework February 2004
This has been suggested as one possible communication model for
transport intermediaries [Blumenthal] but is not in wide use. It
demonstrates many of the same advantages and disadvantages as call-
out protocols, but may have fewer firewall traversal problems
(which is not to say that there will be no problems). The OPES
documents (see below) require that an endpoint be notified and
allowed to authorize (or not) treatment of its request or response
to its request, but it remains unspecified.
5.3.2. Callout protocols
In a callout protocol, a middlebox initiates contact with someone
other than a packet's sender. One example of this is the proposed
architecture for a "transport triggers" service for transport layer
protocols (notably TCP) [Dawkins]. Another is the callout function
of the OPES architecture [Barbir]
5.3.2.1. TRIGTRAN
TRIGTRAN is path-oriented, in that it assumes the existence of two
participating endpoints which are sending data to one another.
When a transport intermediary wishes to notify the endpoints of a
transport event or of connection path characteristics, it generates
a message which is sent to the receiver of the data triggering the
event, rather than the sender. Note that these requests are advi-
sory only, but nevertheless do constitute a form of middlebox com-
munication. There is a reasonable expectation that an endpoint
that has received a TRIGTRAN notification will modify its own
behavior, which in turn imposes some security requirements on the
protocol. Figure 7 shows the flow of the control traffic (here we
assume that Host A is the originator of the traffic and Host B is
the receiver).
+------+ +----------------------+ +------+
|Host A| |Transport Intermediary|--->|Host B|
+------+ +----------------------+ +------+
Figure 7
As with path-oriented signaling and callback protocols, callout
protocols have the advantage of not requiring device or topology
discovery. The endpoints are known. However, the most common
authorization model for firewalls (and indeed, the fundamental
premise behind NATs) is that connections initiated from inside a
firewall or NAT are allowed and that data sent from outside a fire-
wall or NAT is discarded either because it's a policy violation
Shore [Page 24]
Internet Draft Alias Framework February 2004
(firewalls) or because the device doesn't know where to send it
(NATs). Consequently, because TRIGTRAN messages are path-oriented
but not in-band, and because TRIGTRAN and other callout messages
are not embedded in the data stream of interest they will have a
problem reaching an endpoint if there is a NAT or firewall along
the path.
Note that in TRIGTRAN and other protocols where a network-embedded
device sends information that suggests to an endpoint that it mod-
ify its behavior (another example is when an endpoint discovers or
receives its external address from a NAT via midcom or another pro-
tocol), the middlebox must identify itself and be authorized to
provide the service in question. The reasons are obvious (DoS
attacks, connection hijacking, etc.), but this creates a somewhat
different expectation from the usual one that an endpoint is the
one who must authenticate itself to the server or network device.
5.3.2.2. Open Pluggable Edge Services (OPES)
The IETF's OPES working group has developed an architecture to
allow invocation of network-embedded application services that are
initiated by server-side devices. For example, requests from a
client may be redirected for load balancing, or a web page may be
automatically translated from one language to another. OPES sup-
ports the use of "callout servers." When a middlebox (in this case
an "OPES processor") receives traffic it would like to refer out
for processing, it encapsulates and forwards it (possibly after
performing some transformation itself). The transformed data are
returned to the OPES processor. There are essentially two middle-
boxes here, the OPES processor, which is a middlebox with respect
to the data originator, and the callout processor, which is a mid-
dlebox with respect to the OPES processor. See Figure 8, which
shows the control connections for the callout protocol.
+-----------------+
|Callout Processor|
+-----------------+
^
/
/
/
+------+ +--------------+ +------+
|Host A| |OPES Processor| |Host B|
+------+ +--------------+ +------+
Shore [Page 25]
Internet Draft Alias Framework February 2004
Figure 8
It could be argued that this is actually an instance of off-path
signaling, much like midcom. This probably doesn't survive
scrutiny in the overall network context, however, because of the
relationships among the participants. In midcom, the device
requesting treatment of the sender's data has a very close trust
relationship with the sender (and in fact may be the sender). In
OPES the sender has no relationship with the callout processor and
is not even aware that it exists.
COPS [2748] is arguably another example of a callout protocol.
5.4. Models conclusion
Based on the above discussion we can start to identify certain
properties that may be used to describe different aspects of mid-
dlebox communication. Among these are:
path-coupled/path-decoupled
endpoint-initiated/middlebox-initiated
on-path/in-stream
We believe that there are other distinctions that can be teased
out, as well, and that as we go forward with new middlebox communi-
cation protocols it is easily worth some effort to come to a
broader understanding of the issues and environments.
6. Security considerations
The question of disabling security mechanisms in order to enable
intermediary-based services is fraught with difficult decisions and
potentially expensive trade-offs. If protections are turned off in
order to allow an intermediary access to packet contents, they
remain turned off as the traffic transits the remainder of the data
path. An unauthorized intermediary may silently fiddle with the
packet. It may be possible for a network intermediary to secure
the traffic between itself and the packet's destination but that
introduces a number of questions around authorization, security
relationships, and credentialling.
7. Acknowledgments
The entire problem presentation and discussion was lifted wholesale
from "Securely Enabling Intermediary-based Transport Services," an
internet draft by U. Blumenthal, I. Faynberg, S.K. Kasera, S.
Shore [Page 26]
Internet Draft Alias Framework February 2004
Mizikovsky, S.Norden, G.S. Sundaram, and T. Woo, and from "Frame-
work and Requirements for TRIGTRAN," an internet draft by Spencer
Dawkins, Carl Williams, and Alper Yegin.
8. References
[Barbir] Barbir, A. et al. "An Architecture for Open Pluggable Edge
Services (OPES)," work in progress. December 2002.
[Baugher] Baugher, M. et al. "Secure Real-time Transport Protocol,"
work in progress. May 2003.
[Blumenthal] Blumenthal, U. et al. "Securely Enabling Intermediary-based
Transport Services," work in progress. June 2003.
[Chan] Chan, M.C. and R. Ramjee, "TCP/IP Performance Over 3G Wireless
Links With Rate and Delay Variations." In Proc. of ACM Mobicom,
Sep. 2002.
[Checkpoint] Checkpoint Inc. "Why All Stateful Firewalls Are Not Cre-
ated Equal." http://www.checkpoint.com, 2002.
[Dawkins] Dawkins, S., Williams, C. and A. Yegin, "Framework and
Requirements for TRIGTRAN," work in progress. March 2003.
[Degermark] Degermark, M., Hannu, H., Jonsson, L. and K. Svanbro.
"Evaluation of CRTP performance over cellular radio links. In IEEE
Personal Communications, Aug. 2000.
[Dorward] Dorward, S. and S. Quinlan. Robust data compression of net-
work packets, 2000. http://www.cs.bell-
labs.com/cm/cs/who/seanq/networkcomp.pdf.
[Fluhrer] Fluhrer, S. "Tunnel Endpoint Discovery," work in progress
(expired internet draft). November 2001.
[Hilt] Hilt, V. and J. Rosenberg "Supporting Intermediate Session Poli-
cies in SIP." Work in progress, October 2003.
[Keller] Keller, R., Choi S., Dasen, M., Decasper, D. and G.
Frankhauser. "An active router architecture for multicast video
distribution." In Proc. of IEEE Infocom, Mar. 2000.
[NSIS] "Next Steps in Signaling (nsis)," working group charter.
http://www.ietf.org/html.charters/nsis-charter.html.
Shore [Page 27]
Internet Draft Alias Framework February 2004
[RFC1144] Jacobson, V. "Compressing TCP/IP Headers for Low-Speed Serial
Links," RFC 1144, February 1990.
[RFC1928] Leach, M. et al. "SOCK Protocol Version 5," March 1996.
[RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP)," RFC
2205, September 1997.
[RFC2327] Handley, M. and V. Jacobson. "SDP: Session Description Proto-
col," RFC 2327, April 1998.
[RFC2393] Shacham, A. et al. "IP Payload Compression Protocol
(IPComp).: RFC 2393, December 1998.
[RFC2401] Kent, S. and R. Atkinson. "Security Architecture for the
Internet Protocol," RFC 2401, November 1998.
[RFC2663] Srisuresh, P and M. Holdrege. "IP Network Address Translator
(NAT) Terminology and Considerations," RFC 2663, August 1999.
[RFC2702] Berger, L. and T. O'Malley, "RSVP Extensions for IPsec Data
Flows," RFC 2702, September 1997.
[RFC2748] Durham, D. et al. "The COPS (Common Open Policy Service) Pro-
tocol." RFC 2748, January 2000.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin. "A Framework for
Policy-based Admission Control," RFC 2753, January 2000.
[RFC3095] Borman, C. et al. "Robust Header Compression (ROHC): Frame-
work and four profiles: RTP, UDP, ESP, and uncompressed. RFC 3095,
July 2001.
[RFC3135] Border, J. et al. "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations," RFC 3135, June 2001.
[RFC3209] Awduche, D. et al. "RSVP-TE: Extensions to RSVP for LSP Tun-
nels, RFC 3209, December 2001.
[RFC3234] Carpenter, G. and S. Brim. "Middleboxes: Taxonomy and
Issues," RFC 3234, February 2002.
[RFC3261] Rosenberg, J. et al. SIP: Session Initiation Protocol. RFC
3261, June 2003.
Shore [Page 28]
Internet Draft Alias Framework February 2004
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
Rayhan. "Middlebox communication architecture and framework, RFC
3303, August 2002.
[RFC3311] Rosenberg, J. "The Session Initiation Protocol (SIP) UPDATE
method. RFC 3261, June 2003.
[Rosenberg] Rosenberg, J., Mahy, R., and C. Huitema, "Traversal Using
Relay NAT (TURN)," work in progress, October 2003.
[Rosenberg2] Rosenberg, J. "Requirements for session policy for the ses-
sion initiation protocol (SIP)," work in progress, June 2003.
[Saltzer] Saltzer, J.H., Reed, D.P., Clark, D.D. "The End-to-End Argu-
ment in System Design," ACM Transactions in Computer Systems 2(4),
November 1984.
[Shore] Shore, M. "The TIST (Topology-Insensitive Service Traversal)
Protocol," work in progress (expired internet draft), May 2002.
[Zhang] Zhang, Y. and B. Singh. "A Multi-Layer IPSEC Protocol." In
Proc. 9th Usenix Security Symposium, Aug. 2000.
9. Copyright
The following copyright notice is copied from RFC 2026 [RFC2026]
Section 10.4, and describes the applicable copyright for this docu-
ment.
Copyright (C) The Internet Society January 25, 2004. All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, pub-
lished and distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and this para-
graph are included on all such copies and derivative works. How-
ever, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the proce-
dures for copyrights defined in the Internet Standards process must
be followed, or as required to translate it into languages other
than English.
Shore [Page 29]
Internet Draft Alias Framework February 2004
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI-
NEERING TASK FORCE DISCLAIMS 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 WAR-
RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10. Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996], Sec-
tion 10.4, and describes the position of the IETF concerning intel-
lectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 pro-
prietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Execu-
tive Director.
Editor's Address
Melinda Shore
Cisco Systems
809 Hayts Road
Ithaca, NY 14850
USA
Shore [Page 30]
Internet Draft Alias Framework February 2004
mshore@cisco.com
Shore [Page 31]