Internet Draft Melinda Shore draft-shore-friendly-midcom-01.txt Cisco Systems June 2002 Expires December 2002 Towards a Network-friendlier Midcom <draft-shore-friendly-midcom-01.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 While IP was designed around the notion that the network would be invisible to the applications that run on them, an increasingly complex service environment along with the compartmentalization of "policy" into administrative domains has led to a proliferation of types of middleboxes for policy enforcement, and those middleboxes are interfering with applications. Applications now need to influ- ence the behavior of middleboxes, but violating network layering principles by establishing explicit communication channels from applications to network-layer middleboxes introduces a new set of problems related to topology and discovery as well as consequent problems that ripple out from those. This paper is an introductory Page 1 Internet Draft Network-friendlier midcom June 2002 examination of whether or not there is a better way. 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 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. Met- calfe's Law, which says that the utility of a network equals the square of the number of users, may remain true in the broadest sense of the phrase "utility of a network," but may not be true locally. That is to say that the network may be more valuable to me if I have access to your stuff, but it may be less valuable to me if you have access to my stuff. As a consequence an industry has evolved around providing boxes that implement the separation of administrative domains. These boxes typically are firewalls or network address translators, but there may be others as well. A significant problem with firewalls and NATs is that the mechanisms that they use to implement this separation and to identify network traffic to which policy must be applied are extremely crude. Addresses and port numbers are very poor representations of policy, indeed. And because of the inade- quacy of these representations, complex applications which manipu- late or add their own data streams on dynamically allocated address/port/protocol tuples fail when traversing domain boundaries enforced by middleboxes. Middlebox vendors have attempted to mitigate the negative effects of their devices by adding "stateful inspection" capabilities and through the introduction of application- layer gateways. By forc- ing the middleboxes to understand application protocols the middle- boxes become participants in the application, violating the end-to- end principle. Predictably but unfortunately, stateful inspection brings with it a large number of drawbacks, including not being able to function if the application data are encrypted and failed payload integrity checks if stateful NAT rewrites are used, which actively interferes with securing applications. There are also problems with scalability and with software maintenance, as middle- boxes need to cope with an increasing number of application proto- cols. ALGs suffer similar limitations, as they force connections Page 2 Internet Draft Network-friendlier midcom June 2002 to terminate on intermediate devices, interfering with trust rela- tionships and increasing network complexity as ALGs are added for each application as needed. The IETF's midcom working group [Midcom] has been chartered to develop an architecture and requirements for moving application logic out of middleboxes and allowing applications direct influence over middlebox behavior by establishing a communications channel between an agent acting on behalf of the application and the mid- dlebox itself. The architecture that is being developed will work well in smaller networks, but may have difficulties scaling and with manageability. In this paper we discuss an alternative archi- tecture that may be more idiomatic to IP networking, and therefore more network-friendly. 2. The Midcom Model The essential components of the midcom architectural framework are a middlebox, a midcom agent (representing the application), and a policy function, as shown in Figure 1. +---------+ | agent | +---------+ | +---------+ +------+ |middlebox|------------|policy| +---------+ +------+ Figure 1 The agent establishes an explicit connection with a middlebox. That is to say, communication between the agent and the middlebox is terminated at one end on the agent and at the other end on the middlebox. In the case where there are multiple middleboxes that need to be influenced the agent will need to establish communica- tion with each one. Note that with respect to the agent the mid- Page 3 Internet Draft Network-friendlier midcom June 2002 dleboxes may be organized serially (Figure 2) +---------+ | agent |-+-+-+ +---------+ | | | | | | | +---------+ | | | |middlebox|-+ | | +---------+ | | | | | +---------+ | | |middlebox|---+ | +---------+ | | | +---------+ | |middlebox|-----+ +---------+ Figure 2 or as a "fan" (Figure 3) +---------+ +---------| agent |---------+ | +---------+ | | | | +---------+ +---------+ +---------+ |middlebox| |middlebox| |middlebox| +---------+ +---------+ +---------+ Figure 3 Either configuration presents challenges to the application and each configuration has problems of its own. These problems may not be tractable. In both cases the agent will need to discover the existence of the middleboxes and their location within the network. Right now the midcom assumption is that the middlebox will be manu- ally configured into the agent, but to date the question of rela- tive location remains unaddressed. By "relative location" we mean the location of each middlebox in relation to the agent and in relation to each other. For example, in the case where middleboxes are arranged serially, it may be nec- essary for the agent to know where they are and how they're ordered. If a NAT is inserted before a firewall, the agent will Page 4 Internet Draft Network-friendlier midcom June 2002 need to know to use the translated-to address when installing a ruleset on the firewall. If there are multiple NATs, the agent will need to know which NAT is last in order to know what address to present to the destination endpoint. The fan configuration introduces a different, difficult problem -- routing. The midcom agent must be able to identify which middlebox a particular stream of application data will traverse, which sug- gests knowledge of network topology and routing tables. It becomes even more complicated when a third party is used for call control and as a midcom agent, as with VoIP. In that case it may very well be that the middlebox(es) traversed to get from one call control server/midcom agent to another in order to complete a call are not the same as the middleboxes traversed by the end-to-end media streams (Figure 4). +--------------+ signaling +--------------+ | |<--------------->| | | call control | | call control | | | +---------+ | | | +------+ |---|middlebox|---| +------+ | | |midcom| | +---------+ | |midcom| | | | agent| | | | agent| | | +------+ | | +------+ | +--------------+ +--------------+ | | | | | | | | | audio | +----------+<------------------->+----------+ | VoIP | +---------+ | VoIP | | terminal |-----|middlebox|-----| terminal | +----------+ +---------+ +----------+ Figure 4 The agents may therefore need to know about the location of middle- boxes outside of the paths traversed by its own data, and it may need to understand the network topology well enough to determine when it needs to make a request of one. Other problems crop up, as well, such as NAT middleboxes with more than one interface and with overlapping address spaces, and that a Page 5 Internet Draft Network-friendlier midcom June 2002 midcom agent cannot know whether or not a given flow will need ser- vices from a particular middlebox without having access to network topology. Furthermore, because firewall rules are usually speci- fied in terms of "in" and "out" on particular interface, there's support for the notion of having midcom agents know about internal middlebox configuration. All of this is leading towards having midcom agents participate in network-layer routing, something which has clear negative implications for network performance, manage- ment, and stability. While problems stemming from relative topology have not yet been addressed, there have been proposals in midcom to make network- layer topology explicit to the midcom agent to varying degrees [Molitor, Aoun, Penfield]. [Brim] suggestion that leaving topol- ogy-related decisions in the hands of the middlebox with notifica- tion back to the agent is far more idiomatic to IP, but the prob- lems of relative topology and middlebox discovery remain. 3. An Alternative Architecturally it would seem to be preferable to allow the network to handle network-layer issues. The question then becomes whether or not that is feasible. There is a precedent for this sort of approach, and that precedent is RSVP [RFC2205]. Our intention at this time is not to propose RSVP as a midcom protocol but to exam- ine the approach that it takes for applicability to middlebox traversal problems. We also note that a working group has recently been chartered to investigate future work on signaling in the internet [nsis], and this may be a particularly apt time to examine whether or not this approach generalizes well to middlebox communi- cation. Please note that while we do not consider the policy interface in this draft, we do consider it a critical component of a complete middlebox communication environment. 3.1. RSVP [RFC2208] describes RSVP as "a unicast and multicast signalling protocol, designed to install and maintain reservation state infor- mation at each router along the path of a stream of data." "Reser- vation state" in this case refers to QoS parameters. Midcom con- cerns itself with manipulation of different resources (firewall pinholes and NAT table mappings), but these might broadly be con- sidered "reservation state information." Page 6 Internet Draft Network-friendlier midcom June 2002 Why RSVP is of particular interest is that it relies on existing routing mechanisms for finding a path through the network, and nei- ther endpoint involved in the reservation needs to know where RSVP- capable routers are located. The basic reservation model is build around a flowspec, which describes the treatment that the data are to receive, and a filter spec, which describes the data to which the flowspec applies. This model works as well for packet filter- ing middlebox functions as it does for QoS. A key characteristic of RSVP is that requests are sent downstream by the sender towards the receiver, collecting path/routing infor- mation, and the receiver then returns the request back upstream to the sender. This is where the actual reservation requests are made of the network. What this gives us is access to middleboxes along a path without having to address them directly, as well as access to ordering information. We no longer need to export network topology information to the application in order to have midcom be able to find middleboxes and make topology-appropriate requests. While there is legitimate concern about the state that this mecha- nism would install and manipulate in middleboxes, it should be noted that the middleboxes under direct consideration, NATs and firewalls, already retain the vast bulk of this state in normal operations. Indeed, one could argue that by removing stateful inspection from firewalls and NATs we are reducing the amount of state retention in these devices. Another scaling issue is maintenance traffic. RSVP's messaging model uses periodic idempotent messages to refresh reservation state and to accomodate routing changes, potentially creating a good deal of traffic of its own. Figuring on roughly 104 bytes per message (including IP headers but not including INTEGRITY or POLICY objects), we calculate the following table, where the number in each cell represents the bytes/sec. of RSVP traffic based on update interval (shown in the left-most column, in seconds) and the number of data flows (shown in the first row). 20 100 500 1000 5000 10000 30: 8320 41600 208000 416000 2080000 4160000 60: 4160 20800 104000 208000 1040000 2080000 120: 2080 10400 52000 104000 520000 1040000 300: 832 4160 20800 41600 208000 416000 600: 416 2080 10400 20800 104000 208000 900: 277 1386 6933 13866 69333 138666 Page 7 Internet Draft Network-friendlier midcom June 2002 So, we can see that if there were 10000 data flows whose middlebox state were being managed by Path/Resv message pairs every 30 sec- onds, it would generate more than 4 megabytes/sec in traffic. If the refresh interval is lengthened to 15 minutes, it would generate about 140,000 bytes/second of RSVP traffic. Note that this discus- sion assumes that the refresh reduction overhead mechanisms described in [RFC2961] are not used. Note as well that the longer the refresh interval is the longer it takes to respond to routing changes, etc. 3.2. Messages Downstream (from the sender towards the receiver) messages carry a description of the requested action, such as "open a pinhole," "install a NAT mapping," etc., a description of the data flows against which the action should be applied ({address, port, proto- col} tuples, for example), and sufficient information for the mid- dlebox to use as input into a policy-based decision whether or not to honor a request. This might include the identity of the requesting entity, the application for which the service is being requested, etc. Upstream (from the receiver towards the sender) messages create and maintain state in middleboxes, and accumulate confirmed informa- tion, such as NAT table mappings, that need to be returned to the sender. As with RSVP, when each middlebox receives a Path message it must record the previous hop middlebox in order to ensure that the Resv messages are returned along the same data path, avoiding problems created by asymmetric routing. The advantages of using the RSVP mechanism of collecting path information in a downstream direction before installing and con- firming reservation state in an upstream direction are clear. It provides with an ability to make topology- appropriate reservation requests and to be able to return topological summary information, such as outermost NAT with respect to the receiver, to the sender. 4. Example Scenarios For the sake of convenience, in the following examples we refer to forward messages from the originating host as "Path" and returning messages towards the originating host as "Resv". These were chosen because they're well-understood, and should not be construed as assuming or arguing for the use of RSVP as the underlying protocol. Page 8 Internet Draft Network-friendlier midcom June 2002 4.1. Open a firewall pinhole +----------+ (1) +--------------+ (2) +----------+ | |------>| |------>| | | Host A | | Middlebox | | Host B | | |<------| |<------| | +----------+ (4) +--------------+ (3) +----------+ Figure 5 In this case Host A is requesting the middlebox to permit all traf- fic originating at Host B and destined for Host A. Host A sends a Path message (1) towards host B, anticipating that midcom-aware middleboxes transited by the Path message will act on the message. The middlebox intializes path state and forwards the message (2) on towards Host B. Host B then uses the Path message to build a Resv message, which is returned towards Host A (3). The middlebox receives the Path message, makes a determination whether or not to open the pinhole, and forwards the results (success or failure) back to Host A (4). 4.2. Transit both firewall and NAT This scenario is where we begin to derive some benefit from relying on network routing and forwarding functions to handle topology for us. Firewalls and NATs may appear in any order in the data path. In Figure 6, packets from Host A to Host B transit a firewall Page 9 Internet Draft Network-friendlier midcom June 2002 before transiting a NAT. +--------+ | Host A | +--------+ | ^ (1) | | (6) v | +--------+ |Firewall| +--------+ | ^ (2) | | (5) v | +--------+ | NAT | +--------+ | ^ (3) | | (4) v | +--------+ | Host B | +--------+ Figure 6 Host A wishes to request a firewall pinhole and a NAT table map- ping, but it cannot know in which order which type of middlebox appears in the network. It therefore constructs a Path message consisting of a firewall pinhole request AND a NAT table mapping request and sends it into the network towards host B (1). The Path message arrives at the firewall, which install initial path state, and forwards it towards Host B (2). When the Path message arrives at the NAT, the NAT similarly initializes path state but it also rewrites the Path message with its own address so that Resv mes- sages are routed correctly. State associated with that mapping is retained at the NAT. The rewritten Path message is forwarded to Host B (3), which builds a Resv message and sends it back towards Host A using the translated address that was written into the packet by the NAT. Host A extracts the translated-to address from the message and uses it as needed for embedding in signaling pay- loads for session-oriented protocols, etc. Page 10 Internet Draft Network-friendlier midcom June 2002 4.3. Transit NAT then firewall In Figure 7, packets from Host A to Host B transit a NAT before transiting a firewall. +--------+ | Host A | +--------+ | ^ (1) | | (6) v | +--------+ | NAT | +--------+ | ^ (2) | | (5) v | +--------+ |Firewall| +--------+ | ^ (3) | | (4) v | +--------+ | Host B | +--------+ Figure 7 As with the previous scenario, Host A wishes to request both a firewall pinhole and a NAT table mapping but it doesn't know whether or not those devices lie in the data path or in what order they appear. It constructs a Path message consisting of both a pinhole request and a NAT table mapping request and sends it towards Host B (1). The Path message arrives at the NAT, which rewrites its own address into the Path message and forwards it on (2). When the firewall receives the Path message it now has the NATted address to use as a component of the pinhole rule. The Path message is forwarded on to Host B (3), which turns it around and sends the Resv message back towards Host A, with the NATted address in the Resv message and the pinhole for the translated address installed on the firewall. Page 11 Internet Draft Network-friendlier midcom June 2002 4.4. More than one NAT Figure 8 shows two NAT devices between Host A and Host B. +--------+ | Host A | +--------+ | ^ (1) | | (6) v | +--------+ | NAT A | +--------+ | ^ (2) | | (5) v | +--------+ | NAT B | +--------+ | ^ (3) | | (4) v | +--------+ | Host B | +--------+ Figure 8 Without midcom, or with the model currently being envisioned by midcom, the application has no way of knowing how many NATs are present or which address will appear in the source address field in the IP header when the packet is delivered to Host B. Furthermore, NAT A and NAT B have no way of knowing about eachother and cannot be relied upon to do the right thing. With our model, however, Host A will be able to learn the correct address without having any explicit awareness of network topology. Host A sends a Path message towards Host B (1). When it traverses NAT A, NAT A installs initial Path state, including a new NAT table mapping, writes the mapping into the Path message, and forwards it on (2). The message arrives at NAT B, which does the same thing (either adding a new mapping into the message along with a sequence number or overwriting the existing mapping). This is forwarded towards Host B (3), which turns it around as a Resv message. The Resv message includes the NAT mapping information. When the Path message returns to Host A, the correct NAT table entry will either Page 12 Internet Draft Network-friendlier midcom June 2002 be the one with the highest sequence number, if all mappings are retained, or the only one in the message, if mappings are overwrit- ten. 5. Security Considerations Many of the security issues relevant to midcom still apply, such as the need for "agent" authentication for firewalls and for mutual authentication for NATs. However, when the agent is authenticated to middleboxes, symmetric, private key authentication along with manual key provisioning is no longer a reasonable option. A rea- sonable authentication infrastructure should be in place in order to provide a foundation for secure operation. This may be a pub- lic- key infrastructure or it may be a trusted third-party private key mechanism, such as Kerberos. It cannot assumed that the infrastructure exists to authenticate and authorize network elements with which there is no pre-existing relationship. That infrastructure does not exist today and it is impossible to predict when it may become available. This is a serious concern for some deployments, and should not be regarded casually. Note, too, that since multiple middleboxes may be altering the mid- com messages in transit end-to-end integrity protection is no longer viable. MACs may have to be recalculated at each middlebox. This implies a transitivity of trust that may or may not be consis- tent with local security policy. Another consideration has less to do with the security of this pro- tocol than it does with its interaction with security elements in the network, namely firewalls. If a firewall allows this protocol through without processing it, it may be the case that a false pos- itive will result. That is to say, the sender may believe, based on the contents of the Resv message (or a Resv Confirm message) - that a pinhole has been opened when a firewall along the path was unable to process the message but just forwarded it along. This concern may be mitigated by the question of whether or not a fire- wall that just passes along unidentified midcom/RSVP traffic will be likely to just pass along other unidentified traffic. One very attractive advantage to the approach being proposed here is that network topology need no longer be exposed to applications. At most, the application will discover the public address of the outermost NAT in its path. Page 13 Internet Draft Network-friendlier midcom June 2002 6. References [Aoun] Aoun, C. and Sen, S. "Required Information in Midcom Agents," work in progress, August 2001. [Brim] Brim, S. and Simu, A. "Midcom Agents and Topology," work in progress, August 2001. [Midcom] "Middlebox Communication (midcom) Charter," http://www.ietf.org/html.charters/midcom-charter.html. [Molitor] Molitor, A. "Topology Considerations for IP Telephony MIDCOM Agents," work in progress, August 2001. [Nsis] "Next Steps in Signaling (nsis) Charter," http://www.ietf.org/html.charters/nsis-charter.html. [Penfield] Penfield, Bob. "MIDCOM Topology Using Realms," work in progress, August 2001. [RFC2026] Bradner, S. "The Internet Standards Process -- Revision 3," RFC 2026, October 1996. [RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP): Ver- sion 1 Functional Specification", RFC 2205 September 1997. [RFC2208] Mankin, A. et al. "Resource ReSerVation Protocol (RSVP) Ver- sion Applicability Statement," RFC 2208, September 1997. [RFC2961] Berger, L. et al. "RSVP Refresh Overhead Reduction Exten- sions," RFC 2961, April 2001. [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. [Srisuresh] Srisuresh, P. et al. "Middlebox Communication Architecture and framework," work in progress, July 2001. 7. Copyright The following copyright notice is copied from RFC 2026 [RFC2026] Section 10.4, and describes the applicable copyright for this docu- ment. Page 14 Internet Draft Network-friendlier midcom June 2002 Copyright (C) The Internet Society October 1, 2001. 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. 8. 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. Page 15 Internet Draft Network-friendlier midcom June 2002 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 Page 16