INTERNET DRAFT Melinda Shore Cisco Systems May 2001 Application Considerations for Midcom Middleboxes Status Of This Memo This document is an Internet-Draft and is in full con- formance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its work- ing 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 obso- leted by other documents at any time. It is inappro- priate 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract As an architecture is evolving around an interface between middleboxes in the transport plane [Srisuresh] and the applications which must traverse them, we need to document the implications for applications. This documentation is intended both to provide guidance for application designers and to help network architects come to a better understanding of sources of complexity in our networks. 1. Introduction The IP protocol suite was originally designed around the notion that intelligence would be placed in the endpoints and the applications running on those end- points, and that the actions of the network itself Page 1 Internet Draft Midcom Application Interactions April 2001 would be largely limited to routing and forwarding of packets. However, over time and for a variety of rea- sons (security, resource management, accounting, pol- icy, etc) a number of different types of network inter- mediaries have evolved, putting application involvement into the network either explicitly (proxies, stateful inspection firewalls) or implicitly through failure (middleboxes which prevent some applications from func- tioning correctly, such as NATs). [Carpenter] provides an excellent overview of this evolution. One response to the problem of middleboxes in the net- work quietly interfering with applications has been to make the middleboxes explicitly visible to them [mid- com]. Applications controlling middleboxes in the transport layer, such as firewalls and NATs, violates the end-to-end principle as well as the separation of network layers and therefore introduces yet more com- plexity into an already increasingly complex network. Understanding why this is the case and anticipating some of the issues emanating from layer violation can help network designers build their networks to minimize complexity and help application and application proto- col designers be more sensitive to the consequences of middlebox interactions. This document is not intended to present either protocol requirements or an architec- tural framework. 2. Terminology ASP Application Service Provider ISP Internet Service Provider 3. ASPs and ISPs Business arrangements built around network services are coming to be layered in much the same manner that net- work protocols themselves are layered. It is increas- ingly the case that value-added services are being sold and managed independently of network connectivity itself so that, for example, one might contract for voice or content distribution services with a company which then contracts for bandwidth with yet another company or companies. It is also not uncommon in orga- nizations which deliver both connectivity and services to have them delivered by distinct lines of business with separate administrative and financial structures, effectively operating as separate companies. These arrangements may or may not be independent of "last mile" connectivity. In situations in which packet services and connectivity are being managed by organizations other than those Page 2 Internet Draft Midcom Application Interactions April 2001 which manage application services, it is possible that middleboxes being operated in the network layer are administratively inaccessible to application service providers. This may be particularly problematic when there is an assumption that the application has access to the middlebox's authentication and authorization infrastructures (or vice versa). 4. Third-party Session Mediation The notion of applying external control to firewalls and NATs originally came up within the IETF in the con- text of IP telephony applications. In both enterprise and service provider deployments of these applications (PBX systems would be one example of the former, toll bypass of the latter) it is typically the case that some sort of call control server is used to mediate call signaling. This mediation can consist of call admission control, resource reservation, call routing, billing and settlement, etc. Examples of call control servers include SIP proxy servers and H.323 gatekeep- ers. Because this sort of administrative arrangement is independent of network topology, there are clearly sev- eral implications for interaction with network-layer middleboxes. One obvious consideration is the manage- ment of credentials for authentication and authoriza- tion. A call control server may be able to establish a trust relationship with a network-layer middlebox, but it may well be (indeed, may usually be) that it will be asking to open pinholes for direct communication between calling and called parties rather than for com- munication in which it is a party itself. Another consideration is determining the location of services. Service providers may not wish to expose the topology of their network to external individuals or businesses, and this would include preferring not to reveal the location of firewalls and security gateways (see below). 5. Receiving Incoming Sessions Traditionally firewalls are configured to be more per- missive of traffic exiting the protected network than of traffic entering the protected network. In fact, in many configurations a firewall will allow any connec- tion initiated by a protected host but will by default filter connections initiated from outside the network. NAT also presents difficulties for hosts wishing to receive incoming calls. It is overwhelmingly the case that NATted endpoints do not have routable-to Page 3 Internet Draft Midcom Application Interactions April 2001 addresses, and determining the address at which they make a public appearance is frequently difficult, if not impossible. While some NATs will forward all incoming traffic (or all incoming traffic for a given protocol) to a configured endpoint, this cannot allow multiple NATted endpoints behind the same NAT to receive incoming connections in the general case. There may be several approaches to solving this prob- lem. One would be for an application which expects to receive incoming calls to 1) request a pinhole in a firewall, and 2) request a NAT table mapping and a directory update in anticipation of being contacted. This approach can work, but it makes some assumptions about directory services which may not be true (see below) and is highly wasteful of resources on the mid- dlebox. An approach that scales better would be to have a proxy server or call control server (or even a directory server) available at a routable-to address, which would mean that there would have to be a mechanism for resolving from the address belonging to the called party or server to the address of the proxy server or call control server. This, in turn, implies the exis- tence of an appropriate directory service. Some direc- tory services, such as DNS, may assume a relatively static underlying database and may not be able to func- tion well in the presence of highly dynamic name/address mappings, such an externally controlled NAT may provide. Particular concerns would be speed of update to the database itself, the security of that database, and the speed of propagation of database changes. 6. Separation of Signaling and Data Paths In commercial packet multimedia architectures is is commonly the case that call signaling is mediated by call control servers (H.323 gatekeepers, SIP proxy servers) but that media flow directly between end- points. This results in a trapezoidal architecture: signaling CM ------------------------ CM / \ / \ / media \ EP ------------------------------- EP (where "CM" is a call manager and "EP" is a call end- Page 4 Internet Draft Midcom Application Interactions April 2001 point). There may be firewalls between call managers: CM ---------- FW ---------- CM / \ / \ / \ EP ------------------------------- EP or between endpoints: CM ------------------------ CM / \ / \ / \ EP -------------- FW ------------- EP or between both: CM ---------- FW ---------- CM / \ / \ / \ EP -------------- FW ------------- EP (note that there may also be firewalls between end- points and call managers). There are several concerns here. The first is that a call control server that is in communication with a firewall or NAT in order to permit transit of its own signaling messages may not be aware that there is a firewall or NAT in the media path. A particularly dif- ficult problem, however, is that of route determina- tion: that call control server may have to select from among multiple middleboxes, and for it to know which middlebox needs to be contacted it must have knowledge of transport and/or application network topology and routing policy. Alternatively it could contact all known middleboxes and request a pinhole or NAT mapping, but that is clearly wasteful of resources and can introduce unnecessary gaps in the network perimeter. 7. Location and Discovery Application failures caused by inability to traverse a middlebox are most often diagnosed by a deficiency of diagnostic information - they fail quietly, with error indications usually being limited to timeouts or trans- port protocol handshake failures. Firewalls are almost always configured to drop packets without returning ICMP unreachable messages, and ICMP unreachable code 13 (prohibited access) messages are rarely, if ever, used. There is currently no mechanism available for applica- tions to discover reliably that a packet filtering Page 5 Internet Draft Midcom Application Interactions April 2001 middlebox is dropping their packets. It must be noted that even if there were a general mechanism for discovering middleboxes, network adminis- trators tend to prefer not to expose network topology to outsiders (or sometimes even insiders). And it must be further noted that relying on knowledge of network topology introduces new failure modes into applica- tions. Application designers should be aware that discovery can expose them to attackers fraudulently representing themselves as middleboxes and diverting traffic and that a discovered middlebox should authenticate itself to the middle box controller or agent. Eliot Lear has published an internet draft [Lear] describing the requirements for middlebox discovery. 8. Performance Among the advantages of externalizing application logic from a transport-layer middlebox is that it removes a processing load as well as removing the packet/stream reassembly latency imposed by stateful inspection. There can be one area of performance impact, however, and that is connection establishment. In addition to introducing at least one additional round trip between the middlebox and the application controlling it, there may be other operations required, such as discovery (if it hasn't already occured), authentication and policy consultation for authorization, etc. The effect will likely be negligible for most applications but may be of concern for voice applications, etc. 9. Security Considerations One of the foremost considerations must be whether or not a given agent is authorized to execute given opera- tions on a particular middlebox. The components of that authorization decision include a policy infras- tructure, an authentication infrastructure, and mecha- nisms to provide identity authentication and source authentication. Source authentication is needed in order to prevent the spoofing of authorized control agents. Any middlebox control facility will need access to an authentication infrastructure, if one exists, or will need to pre-share keys, a solution with clear scaling limitations. Middlebox control is predicated on the notion that an application can find a middlebox to control. This implies exposing elements of network topology to an application, and many network administrators would Page 6 Internet Draft Midcom Application Interactions April 2001 prefer not to do that. A middlebox discovery process could potentially be subverted for the purposes of locating, say, a firewall in order to attack it. Of particular concern would be exposing network topology to applications outside the network perimeter. Application designers should also be aware that it could be possible for an attacker to 1) subvert a dis- covery process to represent him/herself as a middlebox, or 2) spoof registration and control responses as com- ing from an existing middlebox in order to divert traf- fic. The authentication infrastructure must provide for mutual authentication, which may mean the acquisi- tion and installation of certificates from a certifi- cate authority. Self-signed certificates are probably undesirable in this case. References [Carpenter] Carpenter, Brian and Scott Brim, "Middleboxes: taxonomy and issues," April 2001. Work in progress. [Lear] Lear, Eliot, "Requirements for Discovering Mid- dleboxes," April 2001. Work in progress. [midcom] "Middlebox Communication (midcom)" working group charter, http://www.ietf.org/html.charters/mid- com-charter.html. [Srisuresh] Srisuresh, P. et al., "Middlebox Communication Architecture and framework," May 2001. Work in progress. 10. Author's Address Melinda Shore Cisco Systems 809 Hayts Road Ithaca, NY 14850 USA Email: mshore@cisco.com Phone: +1 607 272 7512 11. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the 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 Page 7 Internet Draft Midcom Application Interactions April 2001 rights in standards-track and standards-related docu- mentation can be found in BCP-11. Copies of claims of rights made available for publication and any assur- ances of licenses to be made available, or the result of an attempt made to obtain a general license or per- mission for the use of such proprietary rights by implementors 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 applica- tions, or other proprietary rights which may cover technology that may be required to practice this stan- dard. Please address the information to the IETF Exec- utive Director. 12. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 implementa- tion may be prepared, copied, published and dis- tributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, 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 procedures 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 Soci- ety or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 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 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 13. Expiration Date This memo is filed as and expires November, 2001. Page 8