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 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]