Internet Draft Melinda Shore draft-shore-midcom-protos-00.txt Cisco Systems October 2003 Expires April 2004 Talking to Stuff In The Network: Middlebox Communication Models <draft-shore-midcom-protos-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 It is increasingly common for applications to want to influence the behavior of equipment in the network, in violation of various tenets underpinning the the design of IP. A number of different mechanisms and architectures have been proposed, and this very drafty draft is a hoped to be a start at discussing some of the issues related to protocols used for middlebox communication. 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 Shore [Page 1]
Internet Draft Midcom Models October 2003 a time when the dominant values in the network were sharing and maximizing communication reach. As IP networking found a foothold in the commercial world, however, there grew an increasing need to compartmentalize the network into administrative domains where local policy could be applied. These policies include things like access control, accounting, quality- of-service, and so on. There was also increasing interest in per- formance-enhancing intermediaries and proxies. These middleboxes typically have done their work either by making policy decisions based on packet contents (firewalls filtering on the traditional 5-tuple or QoS-capable routers making decisions based on DSCPs) or by transforming all traffic that traverses it (NAT, for example). Allowing the middlebox to make decisions in isolation from the end- points participating in the data flows that traverse it has turned out to have some serious problems. Among those is that the middle- box often has no way to inspect the traffic to make decisions if the traffic is encrypted (and unfortunately some network adminis- trators are choosing to not encrypt traffic in order to allow mid- dlebox/firewall inspection). Another is that the network should not be allowed to manipulate traffic without authorization from the participating endpoints (for example, it might be a problem if every instance of "Gore" was changed to "Bush" without permission). And another is that it's frequently difficult for middleboxes to recognize relationships among parallel data streams, which has proven to be a very serious problem in protocols and applications which use dynamically-allocated data streams, such as VoIP and streaming media. 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 is an attempt at categorizing those protocols and architectures. [Some obvious things are missing: mobile IP. Some things seem out- of-scope - configuration protocols like DHCP and ipv6 neighbor dis- covery, ??Teredo??, application intermediaries that function as application peers, like SIP proxy servers] Shore [Page 2]
Internet Draft Midcom Models October 2003 2. Terminology 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. 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. Shore [Page 3]
Internet Draft Midcom Models October 2003 3.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 1 shows the middlebox control model -- no data streams are shown). +-----------+ | | | | | Agent | | | | | +-----------+ / \ / \ +-----------+ \+------------+ +------------+ | | | | | | | | | | | | | Host 1 | | Middlebox | | Host 2 | | | | | | | | | | | | | +-----------+ +------------+ +------------+ Figure 1 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 Shore [Page 4]
Internet Draft Midcom Models October 2003 relevant 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] 3.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 2 shows the middlebox communi- Shore [Page 5]
Internet Draft Midcom Models October 2003 cation model (again, no data streams are shown). +------+ +-----------+ +-----------+ +------+ | |------->| |---->| |--->| | |Host 1| |Middlebox 1| |Middlebox 2| |Host 2| | |<-------| |<----| |<---| | +------+ +-----------+ +-----------+ +------+ Figure 2 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 gateway and returned to the originating gateway which then initi- ates an IKE session with the discovered gateway, bringing up an IPSec tunnel. but there are several associated disadvantages. One is that the signaling 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 Shore [Page 6]
Internet Draft Midcom Models October 2003 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. 4. 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. 4.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. 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. 4.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] 4.2.1. TRIGTRAN TRIGTRAN is path-oriented, in that it assumes the existence of two participating endpoints which are sending data to one another. Shore [Page 7]
Internet Draft Midcom Models October 2003 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 3 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 3 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 (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. 4.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 Shore [Page 8]
Internet Draft Midcom Models October 2003 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 4, which shows the control connections for the callout protocol. +-----------------+ |Callout Processor| +-----------------+ ^ / / / +------+ +--------------+ +------+ |Host A| |OPES Processor| |Host B| +------+ +--------------+ +------+ Figure 4 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. 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 Shore [Page 9]
Internet Draft Midcom Models October 2003 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. References [Barbir] Barbir, A. et al. "An Architecture for Open Pluggable Edge Services (OPES)," work in progress. December 2002. [Blumenthal] Blumenthal, U. et al. "Securely Enabling Intermediary-based Transport Services," work in progress. June 2003. [Dawkins] Dawkins, S., Williams, C. and A. Yegin, "Framework and Requirements for TRIGTRAN," work in progress. March 2003. [Fluhrer] Fluhrer, S. "Tunnel Endpoint Discovery," work in progress (expired internet draft). November 2001. [NSIS] "Next Steps in Signaling (nsis)," working group charter. http://www.ietf.org/html.charters/nsis-charter.html. [RFC1928] Leach, M. et al. "SOCK Protocol Version 5," March 1996. [RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP)," RFC 2205, 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. [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. [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan. "Middlebox communication architecture and framework, RFC 3303, August 2002. Shore [Page 10]
Internet Draft Midcom Models October 2003 [Rosenberg] Rosenberg, J., Mahy, R., and C. Huitema, "Traversal Using Relay NAT (TURN)," work in progress, October 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. 5. 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 October 1, 2003. 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. 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. Shore [Page 11]
Internet Draft Midcom Models October 2003 6. 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. Author's Address Melinda Shore Cisco Systems 809 Hayts Road Ithaca, NY 14850 USA mshore@cisco.com Shore [Page 12]