Internet Engineering Task Force SIP WG Internet Draft J. Peterson draft-jfp-sipfw-policy-00.txt Level(3) Communications July 14, 2000 Expires: January, 2001 Application-layer Policy Enforcement at SIP Firewalls 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 boundaries of some networks, administrators may want to implement policies that govern the application-layer traversal of SIP signaling. This document serves as an introduction to application- layer policies for SIP, discusses the architectures of network boundaries at which policies might be deployed, and provides examples of policies tailored to particular network services. Introduction As the use of the Session Initiation Protocol (SIP, [1]) in the Internet at large becomes more common, network service providers have begun to confront the security implications of the protocol. Enterprise network administrators whose domains are currently protected by off-the-shelf firewalls are discovering that they must make special allowances for the ingress and egress of SIP traffic. Peterson [Page 1] Internet-Draft SIP FW Policies July 2000 Meanwhile, emerging SIP-centric carriers seek to deploy peering firewalls whose vocation is to ensure that no traffic other than SIP (and the media characterized within it) can pass. Fortunately, both of these roles can be performed by the same system; the technology that permits SIP to traverse firewalls (addressed, for example, in [2] and [3]) manages the disparate signaling and media streams, dynamically allocates media ports as required for sessions, and resolves network-edge complications such as Network Address Translators (NAT, [4]). This document assumes the enforcement of IP- layer policies at the edges of the network to be a solved problem, and focuses on the cases in which the administrators of a network have application-layer policies above and beyond those required for basic SIP traversal that they would like to enforce at network edges. In essence, the policies in question are rules to which passing signaling is subject, ones which may result in the modification, redirection, or rejection of passing signaling. The following sections explore architectures for the implementation of such policies at SIP network edges, and provides a few examples of the sorts of rules that network administrators might wish to use in various situations. I. SIP Network Edges In this document, a network edge refers simply to the border between one IP network and another - whether this designates a peering point between a pair of carriers, or the boundary that separates an enterprise network from the public Internet, or any other sort of divide between administrative domains. In this day and age, firewalls are inevitably deployed at such borders to protect valuable network resources; consequently, this document assumes that anyone interested in applying application-layer policies to SIP traffic will also have enforcers of IP-layer policy in place. The instruments that reside at the edge of a SIP-enabled network are assumed to be of the general form of those described in [2], compromising first a firewall (FW), which handles incoming traffic at the IP (layer 3 to 4) level, and second an application-layer gateway (ALG) which statefully analyzes SIP methods, headers, and so forth in messages which, for inbound calls, it receives from the firewall. A SIP ALG will usually be colocated or associated with a SIP proxy server that assists in routing messages which traverse the network edge. Peterson [Page 2] Internet-Draft SIP FW Policies July 2000 +-------++-------+ | || | -----+ Proxy || ALG | | || | Network +-------++-+---+-+ Boundary | | FCP | | SIP | | | | +-+---+-+ | | | | | FW +--------------| | | | +-------+ | | | | Figure 1: A SIP Firewall On the basis of its analysis of the signaling, an application-layer gateway must instruct the firewall to open ports (for media transmission) at the commencement of a session, and to close these ports once the session has concluded. The mechanism by which an ALG signals to the FW has little direct bearing on this document, but should be some sort of firewall control protocol (FCP) allowing for the dynamic provisioning of IP-layer policies (related to packet filtration, NAT bindings, and so forth) such as the one envisioned in [5]. Note that for reasons of scalability and redundancy, a given firewall implementation may deploy more than one instance of each of the components shown above. Some types of SIP network edges are: o Enterprise network facing the public Internet o SIP-only network facing peer carrier o SIP-only network facing external service The instruments depicted in Figure 1 will perform the roles described above regardless of the type of edge at which the firewall is situated. However, the application-layer policies will almost certainly vary with the sorts of resources that a particular network edge faces. Peterson [Page 3] Internet-Draft SIP FW Policies July 2000 II. Application-layer Policies An application-layer policy is an administrative rule that proscribes a particular behavior if certain characteristics are present in the application-layer component of signaling traversing the policy- enforcing instrument. The term 'application-layer' differentiates these policies from those that apply to lower-layers in signaling (such as the IP headers, where ports and addresses for low-level message routing are designated). Several SIP-speaking elements that might be present in a service provider's network, such as redirect servers or application servers, can enforce administrative rules on signaling. Application-layer policies, as they are considered in this document, are applied to traffic associated with a particular network edge (perhaps one among many in a large service provider's network), thus differentiating these policies from independent applications that might be operating in a given administrative domain. While some networks (enterprise networks, for example, which generally face only the public Internet) have only one logical edge, others, such as those of carriers who exchange sessions with several peer carriers, may wish to enforce different policies at different edges. The rules which application-layer policies enforce are instantiated in logic (most likely software) that analyzes and/or modifies SIP signaling. Generally, this logic will be predicated on the values of particular SIP headers, although it is also possible that some logic might be interested in the body of a SIP message (scanning for supported MIME types, or analyzing bodies like SDP when appropriate). Policies should have access to the complete content of a SIP message. Once this content has been analyzed, policies may: o Allow signaling to pass. Commonly, policies will verify that certain characteristics of the session are in accordance with some pre-provisioned guidelines before proxying signaling on towards its final destination. o Discard signaling. If the sorts of verifications mentioned in the previous case fail, it may be desirable for a policy to discard signaling and take no further action. o Reply to signaling without passing it along. This might, for example, be a more sophisticated form of rejecting signaling in which an appropriate application-layer status code is returned to the originating user agent, possibly soliciting a necessary modification to the session. o Modify signaling and pass it along. New SIP headers might be added, or existing ones modified, in order to bring signaling into conformity with administrative conventions of the network. This is especially useful for amendments to routing. Peterson [Page 4] Internet-Draft SIP FW Policies July 2000 And in many of the above cases, it may be appropriate for policies to also: o Take some other action as a side-effect of receiving the signaling. Logging (for billing, alarming, trending, and so forth) is the most common example of this behavior. Another example is the port-provisioning systems used by an application-layer gateway to instruct a firewall of addresses for media transport (which also serves as an example of the analysis of the SIP body, in this case certain portions of the SDP in some SIP messages). Note that not all policies necessarily target inbound (that is, traversing a network edge from outside to inside) sessions. Some enterprise domains, especially corporate networks, apply restrictions to outbound traffic in order to prevent, for example, abuse of business Internet connectivity. The ALG functionality associated with a conventional SIP firewall targets both inbound and outbound calls (dynamic allocation of media ports is necessary for either). III. Edge Architectures supporting Policy The composition of a network edge will, to some extent, dictate the possibilities for the deployment of instruments of policy. Almost any conceivable SIP edge architecture can support the presence of one or more application-layer policies, although some architectures may be more efficient than others. All of the cases examined in this section assume the existence of a firewall at network edges - in the absence of such a firewall, edge architectures would most likely be considerably simpler. From a strictly logical perspective, policies are positioned between the firewall (packet filterer/NAT) element of a network edge and a proxy server. The proxy server in question may be an ingress element (fronting for a location server, distributing inbound SIP requests to the proper user agents or interior proxies) or a local outbound proxy of some kind through which users inside the edge originate sessions. In turn, the firewall filters inbound and outbound traffic, directing SIP traffic to the ALG, permitting media associated with known sessions to reach the proper endpoints, and blocking all other packets. One or more policy-enforcing instruments will bridge together these elements, allowing (or disallowing) signaling to pass between them. Peterson [Page 5] Internet-Draft SIP FW Policies July 2000 +------+ +------+ +------+ +------+ | | | | | | | | Network ---+Proxy +-+Policy+-+Policy+-+ ALG | Boundary | | |One | |Two | | | | +------+ +------+ +------+ +-+--+-+ | | | | FCP | | SIP | +-+--+-+ | | | | | FW +--------+ | | | +------+ | | | | Figure 2: Chain of Policy It is perhaps simplest to visualize one instrument, a back-to-back UAS/UAC, per such policy. A set of these instruments are then chained together, each receiving a SIP message from the previous instrument in the chain, enforcing its own rule, and then, when appropriate, forwarding the message on to the next instrument in the chain. Inbound calls would originate with the firewall, which would forward signaling to the first instrument in the chain; after traversing each of the instruments in the proper sequence, the final policy instrument would deliver the message to the proxy. Outbound calls would originate with the proxy and traverse the chain to reach the firewall - however, the inbound and outbound chains need not be traversed in the same order, nor indeed constituted of the same instruments. While this architecture is easy to picture, it is however not a terribly efficient way to implement multiple policies. Rather than repeatedly transmitting the SIP message 'over the wire' between distinct elements, it makes far more sense to maintain a single platform that is responsible for managing all of the policies associated with an edge. This platform could serve as both a repository for the service logic associated with each policy, and as a router that ensures the proper traversal of the policy chain. An ALG as described in [2] could be considered such a platform, insofar as it enforces a set of differentiable (albeit tightly coupled) policies. Moreover, a simple chain of instruments neglects opportunities for Peterson [Page 6] Internet-Draft SIP FW Policies July 2000 parallelism and intelligent feature interaction that could be administered by a more versatile platform. Network management tools, even in the form of a service creation environment, could be used by network administrators to provision and sequence such policies. IV. Examples of policies The majority of networks supporting SIP will have one or more edges through which sessions can be exchanged with the public Internet or specific peer networks. The following policies are applicable to these sorts of edges. - Application-layer throttle: This policy prevents an unreasonable volume of inbound call requests from flooding the network behind it. Upon receiving a given rate of calls (perhaps one informed by dynamic conditions in the interior of the network), the policy instrument does not allow signaling to pass, but rather sends a 503 status code in the backwards direction with a Retry-After header specifying a suitable interval. - Enforcing Edge direction: Especially in the case of peering points between SIP carriers, it may be desirable for an edge to be one-way, allowing calls to be originated by only one of the side of the network edge. - Session screening: On a per-edge basis, it may make sense to block sessions originating from either side of the border that are associated with particular users, on account of fraud, abuse, and so forth. The policy logic analyzes the From field in SIP INVITEs, comparing the URI with a list of undesirables, and if it finds a match returning a 403 Forbidden message and refusing to pass the signaling along. - Entrypoint flagging: In some cases, analysis of the From header of a SIP message might not be sufficient to determine the peer network which offered a particular session to an administrative domain. If interior SIP resources need to know the edge at which a particular call entered the network (and possibly the domain which that edge faces) for the purposes of billing, routing, or whatnot, it may be appropriate for a policy to add some signifier of its own identity, and possibly that of the network to which it is adjacent, to SIP signaling before passing it along. Such an identifier might for example be appended to the existing message as a proprietary X- header without any further modification to the signaling. Some SIP networks may have edges that face specialty resources, such as application servers or third-party call control platforms that are hosted by semi-trusted entities. In such cases, network Peterson [Page 7] Internet-Draft SIP FW Policies July 2000 administrators may wish to enforce policies that enforce rules applicable to specific services managed by these external resources, for example: - Transaction tracking for an external routing service: Consider a case in which an administrative domain uses an external service to make some routing decisions. When the network sends a SIP INVITE to the external service, it expects to receive one INVITE back, potentially with a modified Request-URI field, or perhaps a 302 redirection or similar routing mechanism. One policy that might be desired at a network edge facing this sort of external service is a transaction tracking policy that verifies that each call sent out to the service results in precisely one returning call. Timers could guarantee that a request (tracked by Call-ID) is answered within a provisioned interval. Only requests bearing the Call-ID of a session known to be offered to the external service should be passed along (and presumably, once the transaction has been completed, no further requests associated with that Call-ID should be permitted to originate from the external service). - Checksum verification for read-only external services: Some sorts of external services do not require the ability to modify SIP signaling; they merely examine the messages and perform some sort of unrelated behavior based on the result. Network edges facing this sort of service might wish to guarantee the integrity of signaling returning to the originating administrative domain by installing a policy that records a simple checksum of signaling as it passes. Returning messages are corollated by Call-ID, CSeq and method, rehashed and compared with the original checksum to ensure that they were not modified. V. To do o Consideration of policies which trigger on media characteristics, i.e. SDP. VI. Security Insofar as policies are frequently instruments of security, this document illustrates the means by which policies can be added to network edges in order to augment the security of a particular network. VII. Authors' Addresses Jon Peterson Level(3) Communications 1025 Eldorado Blvd Peterson [Page 8] Internet-Draft SIP FW Policies July 2000 Broomfield, CO 80021 jon.peterson@level3.com VIII. References [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: sesion initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999 [2] J. Rosenberg, D. Drew, H. Schulzrinne, "Getting SIP through Firewalls and NATs", Internet Draft (work in progress), Internet Engineering Task Force, Feb. 2000 [3] B. Biggs, "A SIP Application Level Gateway for Network Address Translation", Internet Draft (work in progress), Internet Engineering Task Force, Mar. 2000 [4] P. Srisuresh and M. Holdrege, "IP network address translator (NAT) terminology and considerations", Request for Comments (Informational) 2663, Internet Engineering Task Force, Aug. 1999 [5] J. Kuthan, J. Rosenberg, "Firewall Control Protocol Framework and Requirements", Internet Draft (work in progress), Internet Engineering Task Force, Jun. 2000 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 implementation may be prepared, copied, published and distributed, 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 Society 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 Peterson [Page 9] Internet-Draft SIP FW Policies July 2000 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Peterson [Page 10]