SECURE FIREWALL TRAVERSAL AND
NETWORK ADDRESS TRANSLATION
FOR SIP INITIATED MEDIA
October 2001
A White Paper By
NetScreen Technologies Inc.
http://www.netscreen.com
INTRODUCTION .............................................................................................................3
SOLUTION APPROACHES............................................................................................3
AVOIDING THE FIREWALL AND NAT DEVICE....................................................................3
TUNNEL MEDIA THROUGH THE FIREWALL.........................................................................4
SIP APPLICATION LAYER GATEWAY................................................................................4
FIREWALL CONTROL PROTOCOL (MIDCOM) ..................................................................5
NETSCREEN AND DYNAMICSOFT S FCP................................................................5
FCP SECURITY.................................................................................................................5
A SIP CALL FLOW WITH THE NETSCREEN DYNAMICSOFT FCP........................................6
SUMMARY........................................................................................................................8
Copyright 2001 NetScreen Technologies, Inc. 2
Introduction
Session Initiation Protocol (SIP) aspires to become the dominant protocol on the Internet for
establishing calls of any type. Already, SIP is being deployed for Voice over IP (VoIP), video
conferencing, instant messaging, and is being planned for use in 3G wireless applications as well
as new converged data and voice applications.
In early adoptions of SIP technology, one of the issues confronting deployment is the problem of
firewall traversal of media sessions. In typical network security models, a firewall is deployed at
borders between Trusted and Untrusted network realms and security policies are configured on
the firewall that determine what network traffic may pass between these two realms.
Unfortunately, in nearly all SIP applications it is not possible to define static security policies that
would allow media connections to pass through. This is because the specific information that
would form the security policy rules varies from call to call.
The Session Description Protocol (SDP) is referenced by SIP as the method that should be used
to specify how media sessions such as voice, video, or data are established between two or more
parties in a call. Typically, SDP specifies that media sessions be encapsulated in Real-Time
Protocol (RTP). The issue with firewall traversal arises because RTP does not use fixed layer 4
1
port numbers but rather can use any port in the range 1024 through 65534.
The second significant problem to deployment of SIP in traditional IP networks is traversal of
Network Address Translation (NAT) devices. NAT devices are typically installed at the borders
between IP address realms and rewrite the IP addresses in packet headers as packets traverse
the NAT device. Because SIP signaling messages include IP addresses with the data segment
of IP packets, NAT devices will break SIP unless they are some how  S IP aware . Compounding
the problem is the fact that the source and destination of signaling messages may not have any
direct relationship to the source and destination of media streams.
NetScreen Technologies and dynamicsoft have partnered to develop a solution that addresses
these problems. This solution strives to maintain strong security, minimize initial and future
infrastructure upgrades, enable the quick set up of calls, and provide high performance.
Solution Approaches
There are four common approaches to solving the media firewall traversal problem:
" Avoid using a firewall for media connections
" Tunnel media connections through the firewall
" Use an embedded SIP application layer gateway in the firewall
" Use a Firewall Control Protocol between a trusted signaling server to dynamically
configure the firewall
Avoiding the firewall and NAT device
Some network administrators have attempted to solve the media traversal problem by routing
media and SIP signaling traffic around a firewall or by opening up the firewall rules so broadly that
all SIP and media traffic can pass through. In nearly all situations this is a poor solution for a
variety of reasons.
In order to eliminate the need for firewalls in SIP networks, some people have suggested that
duplicate network infrastructures be built exclusively for SIP. In practice this isn t a viable option.
Carriers must have the ability to support billing and authentication systems and services on the
same networks as the media sessions. Enterprises can t afford to build duplicate networks. SIP
also relies on DNS for routing calls. One of the advantages of SIP is its promise to offer
1
In RFC 2327, Session Description Protocol, RTP must use an even numbered port, therefore 65535
cannot be used for data.
Copyright 2001 NetScreen Technologies, Inc. 3
integrated voice and data applications as well. It is just not possible to build a network that only
handles media because other applications and systems must be on the same network and
secured.
Another option considered is to configure a firewall s rules such that all media can pass. A
firewall would have to allow all TCP and UDP traffic on ports 1024 and higher to be sure that any
call could be completed. With today s wide variety of network applications it is a relative certainty
that other applications that should be protected by the firewall will be using this port range.
Routing traffic around a NAT device that separates two address realms breaks the ability to route
traffic between these address realms.
Tunnel media through the firewall
Other possible solutions include using IPSec VPNs or proprietary protocols to transport SIP
signaling and media through a tunnel. While such a solution does allow specific rules to be
configured in a firewall (to allow only tunnel traffic through), there are several disadvantages of
such a solution.
A tunnel solution requires that both parties participating in the call be known in advance so the
tunnel service can be set up prior to any calls. Either an upstream service provider or the call
recipient must install compatible SIP tunneling hardware and/or software. As SIP becomes more
ubiquitous for voice communications, called parties may be located anywhere on the public
Internet. If the called party is not programmed into the tunnel solution in advance, communication
is not possible. Similarly if the called party moves, then tunnel equipment must be reconfigured.
Both parties participating in a call must have their network infrastructure configured to route traffic
back to the other caller through the tunnel. This means they cannot both be using the same
network address space such as private addresses.
Another issue with tunneling SIP media is the tunnel equipment may add unacceptable latency to
the media traffic. For example, IPSec relies heavily on encryption, a time intensive task, to
provide security. Tunnel equipment that performs encryption in software may add unacceptable
latency to the media streams resulting in poor voice or video quality. Note that NetScreen
security appliances and systems perform encryption on ASIC-based hardware and therefore
introduce less latency than software platforms.
In an enterprise with one address realm and two or more physical locations, hardware based
VPN tunnels may provide an acceptable solution. For carriers and Internet -based SIP
applications, address space conflicts, varying called parties, lack of guaranteed support by
service providers, and possible latency issues make tunnel solutions unviable.
SIP Application Layer Gateway
Some firewall and NAT vendors have embedded SIP intelligence into their products. These SIP
Application Layer Gateways (ALGs) work by examining the contents of SIP signaling messages
as they traverse the device. Firewall SIP ALGs will dynamically open pinholes for the SIP media
connections. NAT devices with a SIP ALG will automatically create the necessary NAT binding
and rewrite embedded IP addresses in SIP signaling messages.
An SIP ALG can be effective at dynamically adjusting firewall policies and NAT bindings to only
allow the necessary traffic to pass. However, there are several drawbacks to using an ALG
solution.
ALGs require that network equipment understand the application protocol. Any changes to the
application protocol will require an update to the network device. Additionally, most firewall and
NAT devices are designed to perform Layer 3 and Layer 4 IP header inspection and can only
Copyright 2001 NetScreen Technologies, Inc. 4
perform inspection deep inside the application layer and rewrite application protocol information
(such as embedded IP addresses) at a significant performance cost. This limits the ability of a
SIP ALG solution to scale.
An SIP ALG also limited by its inability to support encrypted signaling or authenticate a signaling
peer. By design, an ALG must be transparent to the signaling path. It is unable to actively
participate in signaling to provide additional services such as support for encrypted signaling and
authentication. This is not acceptable for carrier class networks where network operators need to
be sure they know who they are receiving calls from and they are billed correctly.
Firewall Control Protocol (MIDCOM)
The solution for firewall and NAT traversal of SIP media that NetScreen and dynamicsoft have
implemented is referred to as Firewall Control Protocol. A working group of the Internet
Engineering Task Force (IETF) known as MIDCOM (for Middlebox Communications) is working
on developing a standard approach to this solution.
The fundamental concept of FCP (and MIDCOM) is to keep all the application intelligence in the
application and allow the firewall or NAT device to continue to do what it does best  inspect and
rewrite Layer 3 and Layer 4 packet headers.
In the FCP solution, a trusted application server may act as an agent of the firewall and
dynamically configure the security policies and NAT bindings as needed to support a given
application. In the case of SIP, this is implemented within a special SIP Proxy server that will
create firewall pinholes and NAT bindings to allow media to traverse as calls are made and end.
The FCP solution has several advantages over other solutions:
" Firewalls and NATs do not need to understand the application protocol and therefore do
not need to be upgraded as the application protocol changes.
" SIP proxies can participate in encrypted signaling sessions and can authenticate
signaling peers. The proxy and firewall can use this information to make sure only the
calls that should be permitted are called to traverse the firewall.
" A SIP proxy can enforce additional policies such as the bandwidth a call may be allowed
to consume, the duration it may last, and the number of sessions in a multi-party or
multimedia call.
" There is significantly less processing overhead than ALG solutions because the
instructions that must be processed are only firewall and/or NAT instructions not SIP
signaling messages which must be analyzed and then translated into specific firewall
and/or NA T functions.
One of the limitations of the FCP solution is the cost. It does not scale down to small and
medium sized enterprises because the cost associated with both a firewall and the special
Firewall Control Proxy servers that are required.
NetScreen and dynamicsoft s FCP
NetScreen and dynamicsoft have worked together to design a Firewall Control Protocol. This
protocol has been implemented in both the NetScreen 500 and the dynamicsoft Firewall Control
Proxy. By using this protocol to send requests and configuration changes to the NetScreen
security system, a Firewall Control Proxy can ensure SIP-initiated media is able to securely
traverse a firewall and supports NAT for networks using private addresses or addresses which
should otherwise be hidden.
FCP Security
There are a number of possible security risks associated with an FCP type of solution.
NetScreen and dynamicsoft have anticipated these risks and implemented FCP in such a way to
minimize their exposure:
Copyright 2001 NetScreen Technologies, Inc. 5
" Eavesdropping on the FCP session
All communications between the Firewall Control Proxy and the NetScreen security
system are encrypted using SSL v3 that uses 3DES, DES, or RC4 encryption.
Encryption makes it significantly expensive for a would-be attacker to determine what
pinholes are open on the firewall at a given time by listening in on the Firewall Control
Protocol messages.
" Inserting a rogue FCP agent to control the firewall
A policy on the NetScreen security system limits the network addresses that may attempt
to use FCP to dynamically configure the NetScreen. Additionally, X.509 certificates must
be loaded on the NetScreen in advance for each FCP agent. These certificates are used
with SSL for mutual authentication of both the FCP agent and the NetScreen box itself.
" Compromised FCP agent (SIP proxy server)
Should a Firewall Control Proxy server itself be compromised it may be possible for an
attacker to use that system to configure the NetScreen system. It s important for
administrators to ensure the FCP server is adequately secured.
In the dynamicsoft reference network architecture, the Firewall Control Proxy server itself
is never exposed to the Untrusted network to help mitigate this risk. An Edge Proxy
server peers with the signaling server on the remote network which in turn exchanges
signaling with the Firewall Control Proxy server.
" Signaling messages with malicious SDP attributes
The dynamicsoft Firewall Control Proxy examines the SDP attributes that describe the
protocols, address, port numbers that are required for an individual call s media sessions.
Any session attributes that are invalid or against policy are rejected.
A SIP Call Flow with the NetScreen dynamicsoft FCP
Figure 1 shows the signaling call flow for a call placed by an enterprise softphone outside of the
firewall into a network such as that of an Internet Telephony Service Provider.
In addition to the firewall and Firewall Control Proxy, an Access Proxy (AP) is located outside the
firewall and an Edge Proxy (EP) is located inside the firewall. Inside the core network a Route
Proxy is used to route signaling messages through the backbone.
Copyright 2001 NetScreen Technologies, Inc. 6
Figure 1
1. An SIP softphone initiates a call by sending an SIP INVITE through the firewall on a
well defined port to the Edge Proxy.
2. The Edge Proxy forwards the INVITE to the Firewall Control Proxy.
3. The Firewall Control Proxy requests a NAT binding for the softphone IP address and
rewrites the SIP message so the INVITE appears to come from the NAT address.
4. The Firewall Control Proxy adds itself to the SIP signaling message RECORD
ROUTE field and forwards the INVITE to the Route Proxy.
Copyright 2001 NetScreen Technologies, Inc. 7
5. The Route Proxy sends the INVITE to a soft switch that in turn completes the call on
the PSTN and returns a 200 OK result.
6. The Route Proxy forwards the successful response to the Firewall Control Proxy.
7. The Firewall Control Proxy requests a NAT binding for the softswitch s IP address.
8. The Firewall Control Proxy requests pinholes in the firewall so the media may pass
through.
9. The Firewall Control Proxy sends the successful call set-up message back towards
the softphone via the Edge Proxy, resulting in a successfully set up call.
Summary
Though SIP is emerging as the dominant signaling protocol in use on the Internet for voice, video,
instant messaging, and presence applications, firewall and NAT traversal threatens to be a
significant inhibitor to wide-scale deployment of these applications. Carriers and Internet
Telephone Service Providers require a solution, which does not degrade voice quality, is cost-
effective, reliable, and minimizes the potential need for future upgrades.
While an SIP ALG solution will be useful for small to medium enterprises, the NetScreen-
dynamicsoft Firewall Control Protocol solution provides for secure firewall and NAT traversal,
highly scalable infrastructure, cooperative but separate application intelligence and network policy
enforcement, and low latency high capacity performance.
All Trademarks and registered trademarks are the property of their respective companies.
Copyright 2001 NetScreen Technologies, Inc. 8