Internet Engineering Task Force Internet Draft Bob Penfield draft-penfield-midcom-realms-00.txt Acme Packet, Inc Expires: February 2002 August 30, 2001 MIDCOM Topology Using Realms Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 documents 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 At the 51st IETF meeting in London, there was much disagreement in the MIDCOM working group about the need for topology information in the MIDCOM requirements. It was decided that there should be a "contest of champions" in which interested parties write drafts describing their solution to the problem. This document presents a proposal for the inclusion of minimal topological information in the MIDCOM protocol by the use of abstract realms. Table of Contents 1. Terminology....................................................2 2. Introduction...................................................2 3. Selecting a Middlebox..........................................2 4. Multiple Overlapping Networks..................................3 5. Using Realms...................................................4 5.1. Example Call Flow...........................................4 6. Proposed Requirements..........................................7 7. Security Considerations........................................7 8. References.....................................................7 9. Author's Address...............................................8 Penfield Page 1 INTERNET-DRAFT MIDCOM Realms August 2001 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. This document uses the following terms as they are defined in [MIDFRM]: middlebox, firewall, NAT, proxy, MIDCOM agent, and MIDCOM protocol. The term "flow" refers to streams of data packets that are flowing between application end-points through the middlebox and that are enabled with the MIDCOM protocol. A "flow specification" refers to the set of data that has been communicated to the middlebox via the MIDCOM protocol; it identifies the flows and the set of actions or services the middlebox performs for the packets in the flow. The term "flow descriptor" refers to the set of data used in the MIDCOM protocol to identify the flow. There is substantial agreement that the flow descriptor consists of at least the standard 5-tuple: source address and port, destination address and port, and transport protocol. The preceding terms have been chosen because they are the author's preferred terms, and because there is still a lack of consensus within the MIDCOM Working Group regarding a set of terminology for these items. The term "realm" is used to refer an administrative domain, a network, or a collection of networks. It is a logical representation of the network clouds between which a NAT/Firewall middlebox logically sits. Within the MIDCOM framework [MIDFRM], a middlebox provides NAT and/or firewall between two or more "realms". These may be address realms for NATs, trust realms for firewalls, or both for combination middleboxes. 2. Introduction This proposal puts forth the claim that, for certain deployment scenarios, the notion of a realm is essential for the MIDCOM agent in order to: a) determine the need for a middlebox; b) determine the particular middlebox to use; and c) communicate to the middlebox from which realm the packets will flow into the middlebox, and to which realm the middlebox should direct the packets. This document uses SIP-based Voice over IP application scenarios in its arguments. However, the concepts can be applied to other applications. 3. Selecting a Middlebox Before an application can send a flow specification to a middlebox in order to open a firewall pinhole or establish a NAT binding, it must determine which middlebox, if any, the flow needs to traverse. Penfield Expires February 2002 Page 2 INTERNET-DRAFT MIDCOM Realms August 2001 In a private network with a single middlebox at the border of the public network, the need for a middlebox can easily be determined by examining the IP addresses of the end-points of the flow, assuming that the MIDCOM agent is smart enough to differentiate private and public addresses. The problem with SIP [SIP] is that it is difficult for a SIP proxy to determine whether or not a middlebox is needed. SIP is a rendezvous protocol wherein typically end-points register their location with a proxy in their home domain and requests for that user are directed toward that proxy. The proxy then forwards the request to the registered location(s). The URL used to address a given user is not always a good indication of the end-point's IP address. The IP addresses of the end-points are contained in the session description (SDP) [SDP], which is included in both the INVITE request from the caller and the response from the callee. In order to determine whether or not the middlebox must be traversed by the RTP media flows, the SIP proxy must have both end-point addresses. If the caller is at a private address and the callee is at a public address, the SIP proxy needs to modify the private IP address in the SDP of the INVITE request to make it a public address before forwarding the request. The problem is that the proxy does not know the address of the callee as it is processing the INVITE. If the next-hop SIP server is at a public address, the most logical assumption for the proxy to make is that the callee is at a public address. The proxy then requests a NAT binding from the middlebox. For non-mobile SIP end-points like gateways to the PSTN, this assumption is usually a valid one. 4. Multiple Overlapping Networks +-------------+ | | +------+ | Customer A | | | +---------------+ | +-----------+ | | | | 10.0.0.x | | | | | | | | | | Service | +-------------+ |Middle| | Provider | | Box +------+ | +-------------+ | | | | | | | | | 192.168.20.x | | Customer B | | | | | | +-----------+ | +---------------+ | 10.0.0.x | | | | | +------+ +-------------+ Figure 1. Multiple Overlapping Private Networks In some VoIP carrier deployments, service providers want a single middlebox to provide NAT and firewall functions for multiple customers. The result is a middlebox being connected to multiple private networks with overlapping private address space. This can be Penfield Expires February 2002 Page 3 INTERNET-DRAFT MIDCOM Realms August 2001 accomplished by using multiple physical interfaces on the middlebox or VLAN tags at Layer 2. In this scenario, source and destination IP addresses alone are insufficient for determining how flows traverse the middlebox. Figure 1 illustrates a middlebox providing NAT and firewall functions for two overlapping private networks that access a service provider's public network. In this scenario, the middlebox needs more information to determine where flows come from and where they should be directed. Some sort of ingress and egress network or interface identification needs to be included in the flow specification sent by the MIDCOM agent. 5. Using Realms This draft proposes the notion of realms as an effective way of representing the various networks adjacent to the middlebox. In the example in Figure 1, each realm (called A, B, and SP in the example) is equivalent to a network interface on the middlebox. However, the concept of a realm is chosen over that of an interface because there may be multiple network interfaces into the same network or, in the case of VLANs, a single physical interface may connect to multiple networks. Local configuration in the middlebox could establish the mapping between the realm names/identifiers and the physical or logical interfaces. The realm information must also be available to the MIDCOM agents so that they can communicate the realm identifiers in a flow specification to the middlebox. The question of how the application determines the realms for a given flow then arises. One way of making this determination is to associate the realm name with the SIP proxies. Often service providers want limited secure access to their SIP proxies. Typically, there are a limited number of SIP proxies in the customer network communicating to a limited number of SIP proxies at the edge of the service provider's network over persistent TLS/TCP connections. These relationships between the proxies are pre- configured into the SIP proxies. If the realm association is part of that configuration, then the SIP proxy can determine the realm based on which TLS/TCP connection a request is sent out or arrives. 5.1. Example Call Flow For the example in Figure 1, it is assumed that there is one SIP proxy in each network. The service provider owns the middlebox and its SIP proxy is the MIDCOM agent for the middlebox. The following examples of messages show a call from a user in customer A to a user in customer B. Only the SIP messages to and from the service provider's proxy are shown, and only pertinent portions of the SIP messages are included. The flow specification sent to the middlebox is also shown. Penfield Expires February 2002 Page 4 INTERNET-DRAFT MIDCOM Realms August 2001 The request travels from the calling User Agent to customer A's SIP proxy, which then forwards the request to the service provider's SIP proxy. Proxy A -> Proxy SP INVITE sip:UserB@customerb.com SIP/2.0 Via: SIP/2.0/TCP sip.customera.com:5060 c=IN IP4 10.0.0.1 m=audio 49172 RTP/AVP 0 The service provider's SIP proxy determines that the request must be forwarded to customer B's SIP proxy, which forwards the request to the called User Agent. Since both customer A and customer B are in private networks, the service provider's proxy must set up NAT bindings in the middlebox to allow the RTP to flow between the two end-points. In the service provider's proxy, there is configuration information about customer A's proxy and customer B's proxies that includes the realm names. Therefore, since the request came from customer A and is being sent to customer B, the service provider's proxy knows that the flows travel between realms A and B. The MIDCOM agent in the proxy requests a NAT binding for the RTP packets flowing from the called user B to the calling user A: Proxy SP (MIDCOM Agent) -> Middlebox Ingress Realm = B Source Address = Source Port = Destination Address = Destination Port = Transport Protocol = UDP Forward to Destination Address = 10.0.0.1 Forward to Destination Port = 49172 Egress Realm = A The middlebox responds with the selected address and port. Middlebox -> Proxy SP (MIDCOM Agent) Ingress Realm = B Source Address = Source Port = Destination Address = 192.168.20.1 Destination Port = 42100 Transport Protocol = UDP Forward to Destination Address = 10.0.0.1 Forward to Destination Port = 49172 Egress Realm = A Penfield Expires February 2002 Page 5 INTERNET-DRAFT MIDCOM Realms August 2001 The proxy sends the request on to customer B's SIP proxy with the updated address and port. Proxy SP -> Proxy B INVITE sip:UserB@customerb.com SIP/2.0 Via: SIP/2.0/TCP sip.service-provider.com:5060 Via: SIP/2.0/TCP sip.customera.com:5060 c=IN IP4 192.168.20.1 m=audio 42100 RTP/AVP 0 When the request reaches the called User Agent, it responds to customer B's proxy, which forwards the response to the service provider's proxy. Proxy B -> Proxy SP SIP/2.0 200 OK Via: SIP/2.0/TCP sip.service-provider.com:5060 Via: SIP/2.0/TCP sip.customera.com:5060 c=IN IP4 10.0.0.5 m=audio 46240 RTP/AVP 0 The MIDCOM agent in the proxy requests a NAT binding for the RTP packets flowing from the calling user A to the called user B. Proxy SP (MIDCOM Agent) -> Middlebox Ingress Realm = A Source Address = Source Port = Destination Address = Destination Port = Transport Protocol = UDP Forward to Destination Address = 10.0.0.5 Forward to Destination Port = 46240 Egress Realm = B The middlebox responds with the selected address and port. Middlebox -> Proxy SP (MIDCOM Agent) Ingress Realm = A Source Address = Source Port = Destination Address = 192.168.20.1 Destination Port = 42102 Transport Protocol = UDP Forward to Destination Address = 10.0.0.5 Forward to Destination Port = 46240 Egress Realm = B Penfield Expires February 2002 Page 6 INTERNET-DRAFT MIDCOM Realms August 2001 The proxy sends the request to customer A's SIP proxy with the updated address and port. Proxy SP -> Proxy A SIP/2.0 200 OK Via: SIP/2.0/TCP sip.customera.com:5060 c=IN IP4 192.168.20.1 m=audio 42102 RTP/AVP 0 6. Proposed Requirements The previous example describes one scenario where a 5-tuple flow descriptor is not sufficient for enabling a flow to traverse a middlebox properly. Therefore, the following requirements are proposed for inclusion in [MIDREQ]: The MIDCOM protocol MUST support ingress realm identification as part of the flow descriptor in order to indicate to the middlebox on which interface(s) the packets will arrive. The MIDCOM protocol MUST support egress realm identification as part of the flow specification in order to indicate to the middlebox on which interfaces(s) the packets are to be sent out. Support of ingress and egress realm identification by MIDCOM protocol implementations SHOULD be OPTIONAL. 7. Security Considerations In scenarios where the middlebox is a firewall between public networks, using realms to identify which side of the middlebox to allow the packets through would defend against address spoofing on packets arriving at the wrong interface in a situation where the middlebox does not have access to routing tables, and the end-point addresses are not local to the networks adjacent to the middlebox. This situation may occur at a peering point between two transit network service providers. The [MIDREQ] draft addresses the security considerations for the MIDCOM protocol. 8. References [MIDFRM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, "Middlebox Communication Architecture and framework", draft-ietf-midcom-framework-03.txt, July 2001, Work In Progress. Penfield Expires February 2002 Page 7 INTERNET-DRAFT MIDCOM Realms August 2001 [MIDREQ] R. P. Swale, P. A. Mart, and P. Sijben, "Middlebox Control (MIDCOM) Protocol Architecture and Requirements", draft-ietf-midcom-requirements-02.txt, July 2001, Work In Progress. [SIP] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", Request For Comments 2543, IETF, March 1999. [SDP] M. Handley, and V. Jacobson, "SDP: Session Description Protocol", Request For Comments 2327, IETF, April 1998. 9. Author's Address Bob Penfield Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 U. S. A. Email: bpenfield@acmepacket.com Penfield Expires February 2002 Page 8