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]