Internet Engineering Task Force MidCom WG
Internet Draft S. Davies
draft-davies-fw-nat-traversal-01.txt S. Read
October 12, 2001 B. A. Scott
Expires: April 2002 P. Cordell
Ridgeway Systems & Software
Traversal of non-Protocol Aware Firewalls & NATS
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
We present a method that enables real-time session-oriented
protocols, such as SIP, H.323, Megaco/H.248 and MGCP, to traverse
through enterprise and residential firewalls and NATs. The method
requires no protocol awareness in the firewall or NAT device and it
is transparent to the endpoint. The method benefits from being
protocol agnostic - one method may be used for all protocols.
Profiles for SIP are presented here as examples.
This is a revision to an earlier draft. The main change in this
draft is to move the intelligent part of the solution into the
private network so that it is protected by the firewall. The details
of the various signalling flows have been modified to accommodate
this change.
Davies, Read, Scott, Cordell [Page 1]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
0. Changes since Last Version
For those that are familiar with the contents of the previous draft,
the main change in this version is to swap the locations of the Proxy
Server and Proxy Interface Agent. Thus the intelligent Proxy Server
function that was located in the public network is now located in the
private network, and the dumb Proxy Interface Agent has been moved
out of the private network into the public network.
The main benefit of this change is that it obviates the need for a
trust relationship with the 'provider'. In the former version, the
security of the solution relied on the efforts of the provider of the
'service'. In this version, the security of the solution remains with
the users of the service, i.e. the enterprise, SOHO, or home user.
The disadvantage of this version compared with the former is that the
enterprise has a separate client solution for each protocol it wants
to use and any protocol changes result in upgrades to many client
systems. In the former version, the client component was protocol
agnostic allowing a single system to support multiple applications
and any changes to the protocol required only the server to be
updated.
In all other respects, this version supports similar deployment
scenarios.
The second change is a change in philosophy rather than a specific
change in how the solution operates. It has been observed that the
solution is not specific to VoIP and multimedia over IP, but rather a
firewall / NAT traversal solution for a particular class of
applications - proxiable applications that contain multiple,
associated flows. To do this the solution involves the introduction
of some additional devices. Because the solution accommodates a
generic class of applications, we no longer look upon these
additional components as augmenting the application installation, but
augmenting the firewall / NAT installation so that it may accommodate
this class of application. This is discussed further below.
In accordance with these changes, what was previously known as the
Proxy Server is now called the Application Proxy, and the Proxy
Interface Agent is now called the Proxy Extension Agent (PEA). The
result is that in this version the client component is referred to as
the Application Proxy (AP), and the server component is referred to
as the Proxy Extension Agent.
1. Abbreviations
MoIP Multimedia over IP
VoIP Voice over IP
2. Introduction
Davies, Read, Scott, Cordell [Page 2]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
Much is now understood, and been written [1], [2], [3], [4] about the
problems caused by firewalls and NATs for real-time session-oriented
protocols. Three classes of solution seem to be emerging.
The first solution is to embed the firewall and NAT devices with ALGs
(application level gateway).
The second solution, as is being explored within the MidCom
architecture, is to define a new control protocol to enable another
device (typically a signalling entity) to control intermediary
firewalls or NATs.
These two solutions, ALGs and MidCom, require upgrades to firewall
and NAT devices and is therefore only appropriate to deployments
where this is possible.
The third solution is to 'traverse' firewalls and NATs. This type of
solution seeks to augment existing firewall and NAT behaviour by the
addition of extra components to the overall firewall and NAT
installation in order to allow the protocols securely through
existing firewall and NAT functions. This solution is necessary for
deployments where it is undesirable or impossible to upgrade deployed
firewall and NAT devices with ALGs or a new control protocol. The
challenges for this type of solution is not to compromise security
while at the same time meeting the real-time characteristics of the
application - the delivery of voice and video over IP.
This draft presents an architecture and method for the traversal of
firewalls and NATs for real-time session-oriented protocols such as
SIP and H.323.
3. Problems Introduced by Firewalls and NATs
The problems caused by firewalls and NAT devices are summarised as
follows:
With regard to firewalls, in addition to the TCP connection needed
for the call-signalling channel, an H.323 call typically requires an
additional TCP connection for H.245 signalling. There is no
well-known port associated with the H.245 channel and consequently it
is not possible to configure a sufficiently stringent static rule
that allows such a channel to pass through a firewall while at the
same time blocking other undesired TCP connections. Similarly, all
current VoIP/MoIP protocols use RTP for media transport, which is UDP
based. Again there are no fixed ports associated with this protocol
and it is thus impossible to define static rules that can allow RTP
media through a firewall without also allowing through data from
other undesired protocols.
NAT and NAPT also introduce problems when deploying MoIP systems.
The behaviour of a NAT/NAPT is to open up a bi-directional path when
a packet is sent from the private network to the shared network. But
Davies, Read, Scott, Cordell [Page 3]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
they will not allow packets from the shared network sent to the
private network to open such a path. The path is usually closed
after a period of inactivity. When the NAPT creates a new path it
will allocate an IP address and port from a pool of resources
available to the NAPT. These characteristics are problematic when
calls need to be made from the shared network into the private
network. Additionally, the NAPT function effectively scrambles the
source and destination addresses used for packets and without special
processing by the NAPT (or some associated function) these values
will not correspond with the values used in the control connections.
The result is that the various MoIP entities are unable to associate
the RTP sessions with the correct call.
4. Options for Firewalls and NATs in an MoIP Environment
Both NATs and firewalls can be made MoIP protocol aware. However,
there may be a number of problems with adopting this strategy. For
example, your existing firewall vendor may not support the protocols
that you wish to deploy. Alternatively the functionality that your
firewall vendor supports for a particular protocol might be limited,
and restrict what you can do with the protocol. Indeed, in a typical
firewall installation connections need to pass through two dissimilar
firewalls. This further restricts the options that the combined
firewall configuration is likely to support. As security is a
sensitive issue, enterprises are unlikely to replace their firewall
with one that supports MoIP, especially if MoIP is only being
deployed on an experimental basis. Also, one of the firewalls
involved in the configuration may be owned and operated by the ISP,
and as such the enterprise has even less control. Even if suitable
firewalls can be deployed, MoIP awareness incurs additional
processing burden for the firewalls and NATs to keep track of the
state of the protocol. Such processing may mean that the firewall
becomes vulnerable to overload attacks, or it has to have such
powerful processing capabilities that it is not economic to deploy.
Alternatively, both the firewall and NAT may have to refer to a
remote ALG function, incurring additional complexity and delay in the
system.
Another option is to deploy proxy systems that by-pass the NAT and
firewall installation. That is, one interface is connected directly
to the private network, and another interface is connected directly
to the shared network. This arrangement provides the attacker with
another route of attack. It also means that the configuration to
protect the private network is spread across a number of devices
increasing the likelihood of mis-configuration. It may also require
additional IP addresses to be allocated in order to support the
device. And it may require a separate network connection between the
enterprise and carrier. This latter restriction removes one of the
benefits that switching to VoIP technology enables.
Even if such solutions were acceptable, the pin-holes that a firewall
has to open up for media need to accept UDP data from all remote IP
Davies, Read, Scott, Cordell [Page 4]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
addresses and ports. This is due to the fact that current MoIP
signalling does not include the source from which the UDP packets
will arrive. The resultant rules that 'protect' internal MoIP
terminals are thus no more stringent than would be used to protect a
public web server, a device that would normally be a bastion host
and/or sacrificial.
The solution described in this document uses a combination of
techniques including tunnels and probe packets to enable operation
through firewall and NAT functions to facilitate the deployment of
MoIP. The system does not require firewalls and NATs to be upgraded,
and allows them to continue to be the primary security point. The
firewalls and NATs are not burdened with additional application
specific processing and can therefore continue to provide protection
to the private network in the light of things like flood attacks.
Additionally, it allows MoIP to be deployed with minimal change to
the existing set of security rules, with the result that
administrators can have confidence in the resultant solution.
The implementation scales down as well as up. In the simplest of
cases, the Application Proxy may be software executing on an endpoint
such as a PC. In large deployments, the Application Proxy and Proxy
Extension Agent may be dedicated equipment or logic executing in high
performance routers, for example.
The solution can, therefore, be scaled over time according to demand
without requiring key equipment (such as firewalls and NATs) to be
repeatedly swapped out as MoIP demand grows. As such, in addition to
being a preferable solution in its own right, it can be a key enabler
to enterprises that wish to have an experimental phase before moving
to a full-scale deployment of MoIP.
5. Philosophy
Figure 1 shows a typical enterprise firewall and NAT installation for
connecting an enterprise to a public network. There are many
variants of this in use, but most can be mapped to this configuration
to a greater or lesser extent.
Davies, Read, Scott, Cordell [Page 5]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
( )
( Shared )
( Network )
( )
( )
|
.................................|.....................................
: Boundary of Firewall / ___|__ :
: NAT Installation | | :
: | NAPT | :
: |______| :
: | | :
: | FW1 | :
: |______| :
: | DMZ :
: |-------------------------- :
: | ____|____ :
: | | | :
: | | Bastion | :
: ____|____ | Host | :
: | | |_________| :
: | FW2 | :
: | [+NAPT] | :
: |_________| :
: | :
.................................|.....................................
|
Private Network |
---------------------------------------------------------------------
____|____ ____|____ ____|____ ____|____
| | | | | | | |
| Private | | Private | | Private | | Private |
| Host | | Host | | Host | | Host |
|_________| |_________| |_________| |_________|
Figure 1 - Typical Enterprise Firewall / NAT Installation
In the installation shown in Figure 1, it should be observed that a
distinction has been made between a firewall and a firewall
installation. For the purposes of this document the firewall
installation is made up of a number of components, including
stand-alone devices that implement firewall (typically packet
filtering) and NAT functions. The distinction between a firewall and
a firewall installation is important for the rest of this document.
The set of filtering rules implemented by firewall FW1 are typically
minimally restrictive, and its main function is to prevent packets
from the public network spoofing that they are from the private
network and vice versa. Firewall FW2 is the main firewall where
application specific filtering rules are applied. It may also
perform a NAPT function, either as a substitute to the NAPT near FW1,
Davies, Read, Scott, Cordell [Page 6]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
or in addition to it.
The bastion host in the diagram is shown mainly for illustrative
purposes. Such a host may be an SMTP proxy, or be a web server.
Davies, Read, Scott, Cordell [Page 7]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
( )
( Shared )
( Network )
( )
( )
|
....................|........................
:Service | _________ :
:Provider | | | :
:Boundary |----------| PEA | :
: | |_________| :
: | :
:...................|.......................:
____|____
| In |
| Network |
| NATs |
|_________|
.................................|.....................................
: Boundary of Firewall / ___|__ :
: NAT Installation | | :
: | NAPT | :
: |______| :
: | | :
: | FW1 | :
: |______| :
: | DMZ :
: |-------------------------------- :
: | ____|____ :
: ____|____ | | :
: | | | Bastion | :
: | FW2 | | Host | :
: | [+NAPT] | |_________| :
: |_________| _____________ :
: | | | :
: |---------| Application | :
: | | Proxy | :
: | |_____________| :
.................................|.....................................
|
Private Network |
---------------------------------------------------------------------
____|____ ____|____ ____|____ ____|____
| | | | | | | |
| Private | | Private | | Private | | Private |
| Host | | Host | | Host | | Host |
|_________| |_________| |_________| |_________|
Figure 2 - Firewall / NAT Installation Augmented with
Application Proxy
The need to upgrade the firewall and NAT components with ALGs can be
Davies, Read, Scott, Cordell [Page 8]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
removed by providing an Application Proxy that sandwiches the
firewall and NAT components between itself and a Proxy Extension
Agent (PEA) as shown in Figure 2. These two devices work together so
that the various packet flows within the sandwich are both firewall
and NAT friendly. Outside of the sandwich the packet flows have the
characteristics of the relevant standardised application.
The result is that the ALG function containing the application
specific knowledge has been effectively removed from the individual
firewall and NAT components and placed in the Application Proxy.
Being stand-alone, these devices can more readily be upgraded without
affecting the individual firewall and NAT components.
Davies, Read, Scott, Cordell [Page 9]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
( )
( Shared )
( Network )
( )
( )
|
|
.................................|.....................................
: Boundary of Firewall / ___|__ :
: NAT Installation | | :
: | NAT | :
: |______| :
: | | :
: | FW1 | :
: |______| :
: | DMZ :
: |------------------------------- :
: | ____|____ ____|____ :
: | | | | | :
: | | PEA | | Bastion | :
: ____|____ | | | Host | :
: | | |_________| |_________| :
: | FW2 | :
: | NAPT | :
: |_________| :
: | _____________ :
: | | | :
: |---------| Application | :
: | | Proxy | :
: | |_____________| :
.................................|.....................................
|
Private Network |
---------------------------------------------------------------------
____|____ ____|____ ____|____ ____|____
| | | | | | | |
| Private | | Private | | Private | | Private |
| Host | | Host | | Host | | Host |
|_________| |_________| |_________| |_________|
Figure 3 - Proxy Extension Agent (PEA) located in DMZ
In the configuration shown in Figure 2 the Proxy Extension Agent is
provided by a service provider. Such an arrangement removes the need
for an additional IP address to be assigned to the enterprise.
For enterprises that have sufficient IP addresses and do not want to
engage a service provider, the configuration shown in Figure 3 can be
deployed. However, this does require the NAT function to implement
at least one instance of 1 to 1 NAT, and the firewall labelled FW1 to
allow all traffic needed by the MoIP protocol to access the Proxy
Extension Agent from other devices. The NAPT function can be
Davies, Read, Scott, Cordell [Page 10]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
colocated with FW2.
( )
( Shared )
( Network )
( )
( )
|
....................|........................
:Service | _________ :
:Provider | | | :
:Boundary |----------| PEA | :
: | |_________| :
: | :
:...................|.......................:
____|____
| In |
| Network |
| NATs |
|_________|
.................................|.....................................
: Boundary of Firewall / ____|____ :
: NAT Installation | | :
: | NAPT | :
: |_________| :
: | | :
: | FW1 | :
: |_________| :
: | :
: ____|____ :
: | | :
: | FW2 | :
: | [+NAPT] | :
: |_________| :
.................................|.....................................
|
Residential Network |
---------------------------------------------------------------------
______|______
| |
| Application |
| Proxy |
|_____________|
| |
| Private |
| Host |
|_____________|
Figure 4 - Application Proxy in a Residential Configuration
Figure 4 shows a variation of the firewall installation for a
residential environment in which only minimal devices are available,
Davies, Read, Scott, Cordell [Page 11]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
and certainly no DMZ is present. In this case the NAPT and the
firewall labelled FW1 are owned and administered by the network
provider. The firewall labelled FW2 most likely forms part of the
device that is used to access the network. Even if it is not owned
and administered by the network provider, the provider most likely
specifies it.
In such a situation, the Application Proxy can be deployed in the
host running the voice / video over IP protocol. Due to the lack of
a DMZ, this configuration does require the Proxy Extension Agent to
be provided by a service provider, although this service provider
need not be the same as the network provider or the ISP.
6. Principles of Operation
As mentioned earlier the Application Proxy and the Proxy Extension
Agent make the various packet flows associated with a session
firewall and NAT friendly for the devices that they sandwich. There
are two main parts to this; using well-known ports and always
initiating new packet flows from the private network out to the
shared network. The use of well-known ports (or as a minimum, fixed
ports) means that the firewall is able to apply secure filtering
rules. Initiating connections always from the private to the public
network makes the protocol NAT (and in particular NAPT) friendly. As
part of the connection initiation procedure, a mechanism is used to
discover the public addresses that the NAT has assigned to the new
packet flow.
To achieve this some control information is needed in addition to
what is available in the protocol that is being traversed across the
firewall installation. This introduces the need for a control
channel to be set up between the two devices. This is called the
Multiplexed Connection in the rest of this document.
The relationship of the Multiplexed Connection to the other devices
in the system is shown in Figure 5. (Note that in Figure 5 both
firewalls have been merged into a single block as drawing them as
separate units does not add to the clarity of the diagram.)
Davies, Read, Scott, Cordell [Page 12]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
___ _____ ____ ____ ____
| T | | A | ......| F |...| N |............... | P |
| e | | p | . | i | | A | Multiplexed . | r |
| r | | p | . | r | | P | Connection . | o |
| m | | l | .--c--| e |---| T |--------------.PZ| x |
| i |---a---| i | .--b--| W |---| |--------------. | y |
| n |---a---| c | .--b--| a |---| R |--------------. | |
| a | | a | ......| l |...| o |............... | Ext|
| l | | t | | l | | u | | |
| | | i P | PB____| |___| t |_______________PX| A |
| | | o r | PB____| 1 ___| e |_______________PY| g |
| | | n o | | & | | r | | e |
| | | x | | 2 | | | | n |
| |---d---| y |---d---| |---| |--------------PXR| t |
|___|---d---|_____|---d---|____|---|____|--------------PYR|____|
a = TCP and UDP Control Channels
b = Multiplexed Sub-channels
c = Multiplex Control Sub-Channel
d = RTP/ RTCP Media
PB = Probe Packets
PX = Port X
PY = Port Y
PZ = Port Z (TCP)
PXR = Port X (RTP)
PYR = Port Y (RTCP)
(Note that it is anticipated that PX == PZ)
Figure 5 - Communication Paths between Application
Proxy and Proxy Extension Agent
The Multiplexed Connection runs over TCP and is initiated by the
Application Proxy when the proxy is started. As part of the start up
procedure, the Application Proxy and Proxy Extension Agent may
authenticate each other. For extra security the Multiplexed
Connection may be encrypted using TLS [5] or an equivalent.
The Multiplexed Connection can carry multiple signalling flows over a
number of Sub-Channels. The information for the traversal protocol
is carried over what is called the Control Channel. Other
sub-channels may be reserved for specific purposes (such as
authentication and key exchange) and others can be dynamically
assigned. The dynamically assigned sub-channels carry UDP or TCP
based signalling protocols such as SIP, H.225 RAS, H.225 call
signalling, H.245 and MEGACO/H.248.
The data on the dynamically assigned sub-channels will typically be
relayed to and from the terminal by the Application Proxy and to and
from the remote party by the Proxy Extension Agent.
The Application Proxy has the ability to open sub channels within the
Multiplexed Connection. It is also able to instruct the Proxy
Davies, Read, Scott, Cordell [Page 13]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
Extension Agent to listen for new TCP connections on specific ports,
or any available port. The Application Proxy can also instruct the
Proxy Extension Agent to create UDP ports for signalling, either on a
specific port or any available port.
It is also necessary to be able to establish outbound and inbound RTP
media flows. RTP is transported by UDP, and a unidirectional RTP
connection requires both forward and reverse UDP paths to be
established. It is, therefore, necessary to establish UDP paths from
the terminal to the Proxy Extension Agent via the Application Proxy,
and from the Proxy Extension Agent to the terminal, again via the
Application Proxy. Additionally, the RTP and RTCP connections
require a fixed relationship between the ports they use. Consequently
it is necessary for the Application Proxy to be able to instruct the
Proxy Extension Agent to open a Media Flow consisting of a pair of
UDP ports which have the necessary RTP/RTCP port number relationship.
To minimise the size of the holes opened up in the firewall, all
outbound RTP and RTCP packets sent to the Proxy Extension Agent from
the Application Proxy are directed towards the same well-known port
pair. The source-address of the packets as viewed by the Proxy
Extension Agent will have been modified in a non-deterministic way by
the NAPT. Without further information, the Proxy Extension Agent
will not be able to associate the RTP/RTCP packets with the correct
Media Flow.
This is solved using Probe Packets containing tokens. When the
Application Proxy instructs the Proxy Extension Agent to establish a
Media Flow, the Proxy Extension Agent will specify tokens that are to
be included in Probe Packets. These Probe Packets, one for RTP and
one for RTCP, are sent over UDP from the Application Proxy to the
Proxy Extension Agent along the same path that the media will
subsequently take. The token in each Probe Packet allows the Proxy
Extension Agent to associate any further UDP packets received from
the observed NAPT-modified source address with the correct part of
the correct Media Flow.
The NAPT function is expected to allow two-way communications between
the Application Proxy and the Proxy Extension Agent triggered by the
Probe Packets. Typically the NAPT will use a timer to detect when the
path is no longer in use.
The Media Flows created by this method are capable of bi-directional
or uni-directional use.
It has been mentioned that the Multiplexed Connection and all the UDP
packets are handled by the same set of well-known ports on the Proxy
Extension Agent in order to make the set of filtering rules in the
firewall manageable and secure. To enable the scheme, any firewall
between the Application Proxy and the Proxy Extension Agent must
allow any TCP packet from any port with a source address of the
Davies, Read, Scott, Cordell [Page 14]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
Application Proxy to the well-known TCP port on the Proxy Extension
Agent and vice versa. In addition, they must allow packets from any
UDP port on the Application Proxy to be sent to the well-known UDP
ports on the Proxy Extension Agent and vice versa. The resultant set
of firewall rules is summarised in Table 1, below.
-----------------------------------------------------------------------
|Rule | To/From IP| To/From| From/To IP| From/To| IP | Purpose |
| | Address | Port | Address | Port | Protocol| |
-----------------------------------------------------------------------
| 1 |Application| Any | Proxy | Z | TCP | Multiplex |
| | Proxy | | Extension | | | Connection|
| | | | Agent | | | |
-----------------------------------------------------------------------
| 2 |Application| Any | Proxy | X | UDP | RTP |
| | Proxy | | Extension | | | Media |
| | | | Agent | | | |
-----------------------------------------------------------------------
| 3 |Application| Any | Proxy | Y | UDP | RTCP |
| | Proxy | | Extension | | | Media |
| | | | Agent | | | |
-----------------------------------------------------------------------
Table 1 - Example firewall filtering rules
to enable communication between
Application Proxy and Proxy Extension Agent
(Note that it is anticipated that X == Z)
(Note: These rules are bi-directional)
7. Operational Procedures
This section describes the operation of the various procedures that
make up the traversal scheme.
Note that a number of devices in the private network may communicate
with the Application Proxy, such as User Agents, Proxies and
Gateways. Similarly, a number of devices may communicate with the
Proxy Extension Agent on the shared network side, including other
Proxy Extension Agents. Therefore, rather than draw and annotate a
line to represent these devices, the diagrams show the Application
Proxy receiving and sending messages to the private network, and the
Proxy Extension Agent receiving and sending messages to the shared
network. The actual devices that send or terminate these messages
are not important to the discussion here.
Davies, Read, Scott, Cordell [Page 15]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
7.1. Initialisation and Registration
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| (1) Create TCP | | |
| Connection | | |
|-+-+-+-+-+-+-+-+-+->>>| |+-+->>>|
| | | |
| (2) Registration | | |
|------------------->>>| |---->>>|
| | | |
| | | |
| (3) Registration Ack | | |
|<<<-------------------| |<<<----|
| | | |
| ---- |
----->>> = Control Channel Messages =====>>> = UDP Packets
- - ->>> = Sub-channel Messages = = =>>> = Messages over TCP
Figure 6 - Creating the Multiplex Connection and
Registration
Figure 6 shows the procedure when the Application Proxy is initially
enabled. It will attempt to create a TCP connection to the Proxy
Extension Agent (1) and then register (2) and (3). Part of the
registration process may include authentication. As different
authentication schemes may require different numbers of messaging
round-trips, the actual sequence of messages will likely be different
to that shown in the figure. Additionally, the TCP connection may be
encrypted, possibly using TLS.
Davies, Read, Scott, Cordell [Page 16]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
7.2. Opening a TCP Channel
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| (1) Open TCP channel | | |
| forward to A | | |
|------------------->>>| |---->>>|
| | | | (2) TCP Open
| | | |<-+-+-+-+-+->>>
| (3) TCP Open Ack | | |
|<<<-------------------| |<<<----|
| | | |
| : | | |
| <other signalling> | | |
| : | | |
| | | |
| (4) Close TCP | | |
|------------------->>>| |---->>>| (5) TCP Close
| | | |<-x-x-x-x-x->>>
| (6) Close TCP | | |
|<<<-------------------| |<<<----|
| | | |
| ---- |
----->>> = Control Channel Messages =====>>> = UDP Packets
- - ->>> = Sub-channel Messages = = =>>> = Messages over TCP
Figure 7 - Opening an Outbound TCP Connection
Figure 7 shows the Application Proxy opening a TCP connection to a
remote party via the Proxy Extension Agent. The data for the
connection is conveyed on a sub-channel in the Multiplexed Connection
for the section of the path between the Application Proxy and the
Proxy Extension Agent.
The Application Proxy will begin by opening a sub-channel within the
Multiplexed Connection. This involves informing the Proxy Extension
Agent of the new sub-channel and telling it where it the destination
address that it will try to connect to (1).
When the TCP connection to the specified remote party has been
established (2), the Proxy Extension Agent will inform the
Application Proxy (3). After (3) the connection can be used to carry
data in both directions.
Note that if it is not possible to establish the connection, either
because the Proxy Extension Agent does not have sufficient resources,
or is unable to establish the connection to the remote party, the
response message to the Application Proxy will indicate that the Open
TCP Connection has failed.
Davies, Read, Scott, Cordell [Page 17]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
Either the Application Proxy or the Proxy Extension Agent can close
the connection, usually when they receive a close notification from
the corresponding TCP connections.
The figure shows the case where the Application Proxy closes the TCP
connection. In this case the Application Proxy sends a close message
to the Proxy Extension Agent (4). Note that even though the
Application Proxy has sent close, it should still continue to forward
any data received from the Proxy Extension Agent on to the private
network. Finally, when the Proxy Extension Agent has forwarded all
the data it needs to send, it will close the TCP connection (5) and
send a close message of its own (6), thus completing the close down
of the connection.
Davies, Read, Scott, Cordell [Page 18]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
7.3. Creating a TCP Listener
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| (1) Create TCP | | |
| Listener on port K | | |
|------------------->>>| |---->>>|
| | | |
| | | |
| (2) TCP Listen Ack | | |
|<<<-------------------| |<<<----|
| | | |
| : | | |
| <other signalling> | | |
| : | | | (3) TCP
| | | | Establish
| (4) TCP channel Ready| | |<<<-+-+-+-+-+-
| from Port K | | |
|<<<-------------------| |<<<----|
| | | |
| (5) TCP Ready Ack | | |
|------------------->>>| |---->>>|
| | | |
| : | | |
| <other signalling> | | |
| : | | | (6) TCP
| | | | Establish
| (7) TCP channel Ready| | |<<<-+-+-+-+-+-
| from Port K | | |
|<<<-------------------| |<<<----|
| | | |
| (8) TCP Ready Ack | | |
|------------------->>>| |---->>>|
| | | |
| : | | |
| <other signalling> | | |
| : | | |
| | | |
| (9) Close TCP | | |
| Listener on port K | | |
|------------------->>>| |---->>>|
| | | |
| (10) Close TCP Ack | | |
|<<<-------------------| |<<<----|
| ---- |
Figure 8 - Opening a TCP Listener
Figure 8 illustrates the operation of a TCP listener. Such a
listener might be used to listen for new incoming SIP calls over TCP,
Davies, Read, Scott, Cordell [Page 19]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
or H.323 calls.
The Application Proxy begins by instructing the Proxy Extension Agent
to listen on a specified port or a port chosen by the Proxy Extension
Agent (1). If the Proxy Extension Agent is able to do this it will
acknowledge the listen request (2). If the Proxy Extension Agent is
not able to post the listen, then it will reject the request.
Subsequently, when a new connection is made to the listening TCP port
(3), the Proxy Extension Agent will inform the Application Proxy
using a TCP channel Ready message (4). Part of the information in
the TCP channel Ready message will indicate the identity of the
listening port that caused the TCP channel Ready message to be sent.
If the Application Proxy is willing to accept the connection it will
send a TCP channel Ready Ack message (5), which will also create a
new sub-channel in the Multiplexed Connection. The Proxy Extension
Agent should only accept the new connection once it has received the
acknowledgement from the Application Proxy.
The same listener may be the source of the many TCP connections as
shown by (6), (7) and (8).
When the Application Proxy no longer requires the listener it can
instruct the Proxy Extension Agent to close it (9).
The TCP connections that are opened as a result of the listener will
be closed in the same way as TCP connections that are created by the
Application Proxy. See Figure 7.
Davies, Read, Scott, Cordell [Page 20]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
7.4. Opening a UDP Signalling Connection
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| (1) Open UDP channel | | |
| bind to port A | | |
|------------------->>>| |---->>>|
| | | |
| (2) UDP Open Ack | | |
|<<<-------------------| |<<<----|
| | | |
| : | | |
| <other signalling> | | |
| : | | |
| | | |
| (3) Close UDP Chan | | |
|------------------->>>| |---->>>|
| | | |
| (4) Close UDP Chan | | |
|<<<-------------------| |<<<----|
| | | |
| ---- |
----->>> = Control Channel Messages =====>>> = UDP Packets
- - ->>> = Sub-channel Messages = = =>>> = Messages over TCP
Figure 9 - Opening a UDP Signalling Connection
UDP signalling connections (as opposed to UDP based Media Flows) are
also made through the Multiplexed Connection. Note that such a
connection is NOT suitable for data that is delay sensitive such as
audio and video. Such data must use Media Flows.
To create a UDP signalling path (see Figure 9), the Application Proxy
sends a message to the Proxy Extension Agent. This message will
create a sub-channel within the Multiplexed Connection and specify
the port to which the UDP socket should bind, or specify that the
Proxy Extension Agent should bind to a port of its choice (1).
If the Proxy Extension Agent is able to create the sub-channel and
socket, it will acknowledge the request (2), otherwise it will reject
the request.
Once the UDP signalling connection has been created, the connection
emulates BSD sockets sendto and recvfrom semantics. This is achieved
by pre-fixing each packet of data sent or received with the transport
address of where it is to be sent to, or it has been received from.
Only the Application Proxy is able to close the UDP connection when
it is finished with. When the Application Proxy has no more data to
Davies, Read, Scott, Cordell [Page 21]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
send, it will send the Close UDP message (3). On reception of the
Close UDP message, the Proxy Extension Agent MUST close the
associated UDP port. It MAY continue to forward any queued UDP data
to the Application Proxy. Once the queued data has been sent, the
Proxy Extension Agent MUST send the Close UDP message, thus
completing the closure of the connection (4).
7.5. Opening a Media Flow
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| (1) Create Media Flow| | |
|------------------->>>| |---->>>|
| | | |
| (2) Create Media | | |
| Flow Ack | | |
| Ports = A:a,A:a+1 | | |
| Tokens = 1234, 2345 | | |
|<<<-------------------| |<<<----|
| | | |
| (3) UDP Probe Packet | | |
| token = 1234 | | |
|===================>>>| |====>>>|
| | | |
| (4) UDP Probe Packet | | |
| token = 2345 | | |
|===================>>>| |====>>>|
| | | |
| (5) Probe Ack (RTP) | | |
|<<<-------------------| |<<<----|
| | | |
| (6) Probe Ack (RTCP) | | |
|<<<-------------------| |<<<----|
| | | |
| | | |
| ---- |
Figure 10 - Opening a Media Flow
To enable RTP media to flow between the shared network and the
private network (Figure 10), the Application Proxy must first
instruct the Proxy Extension Agent to open a Media Flow (1).
If the Proxy Extension Agent is able to create the Media Flow it will
notify the Application Proxy of the port numbers (a and a+1) it has
allocated on address (A), and specify the tokens that are to be used
in subsequent Probe Packets (2). Note: The RTP specification
recommends that the RTP port number a is an even number and that the
RTCP port number is one bigger, a+1.
The Application Proxy will send the Probe Packets, with the supplied
Davies, Read, Scott, Cordell [Page 22]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
token values, from ports that it has assigned to this Media Flow, to
the Proxy Extension Agent (3) and (4).
When the Proxy Extension Agent receives the Probe Packets, it will
acknowledge each one with a Probe Ack (5) and (6).
The Application Proxy will send Probe Packets periodically until the
Probe Ack has been received or a time out limit is exceeded. The
values of these timers are for further study.
7.6. Configuring a Media Flow
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| (1) Set Remote(RTP) | | |
|------------------->>>| |---->>>|
| | | |
| (2) Set Remote(RTCP) | | |
|------------------->>>| |---->>>|
| | | |
| (3)<Signal RTP, RTCP | | |
| addresses A:a,A:a+1> | | |
|------------------->>>| |---->>>|------->>>
| | | |
| (4) RTP packet | | |
===============>>>|===================>>>| |====>>>|=======>>>
| | | |
| (5) RTP packet | | |
<<<===============|<<<===================| |<<<====|<<<=======
| | | |
| (6) RTCP Recv Report | | |
===============>>>|===================>>>| |====>>>|=======>>>
| | | |
| (7) RTCP Send Report | | |
<<<===============|<<<===================| |<<<====|<<<=======
| | | |
| (8) RTCP Send Report | | |
===============>>>|===================>>>| |====>>>|=======>>>
| | | |
| (9) RTCP Recv Report | | |
<<<===============|<<<===================| |<<<====|<<<=======
| ---- |
Figure 11 - Configuring a Bi-directional Media Flow
Figure 11 shows the sequence of messages required to set up a
bi-directional Media Flow.
The Application Proxy must set the remote addresses that the Proxy
Extension Agent will send RTP and RTCP packets to, (1) and (2).
Having set the addresses the Application Proxy will use the
Davies, Read, Scott, Cordell [Page 23]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
signalling protocol (H.323, SIP etc.) to send the RTP and RTCP
addresses and ports to the device in the Shared Network (3).
RTP and RTCP messages can now flow in both directions, (4), (5), (6),
(7), (8) and (9).
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| (2) Set Remote(RTCP) | | |
|------------------->>>| |---->>>|
| | | |
| (3)<Signal RTP, RTCP | | |
| addresses A:a,A:a+1> | | |
|------------------->>>| |---->>>|------->>>
| | | |
| (5) RTP packet | | |
<<<===============|<<<===================| |<<<====|<<<=======
| | | |
| (6) RTCP Recv Report | | |
===============>>>|===================>>>| |====>>>|=======>>>
| | | |
| (7) RTCP Send Report | | |
<<<===============|<<<===================| |<<<====|<<<=======
| ---- |
Figure 12 - Configuring an Incoming Media Flow
Figure 12 shows the sequence of messages required to set up an
incoming uni-directional Media Flow. Note: The numbering of messages
in Figure 11 is carried over to Figure 12 to show the commonality
between the procedures.
The Application Proxy must set the remote address that the Proxy
Extension Agent will send RTCP packets to (2). Having set the address
the Application Proxy will use the signalling protocol (H.323, SIP
etc.) to send the RTP and RTCP addresses and ports to the device in
the Shared Network (3).
RTP messages can be received from the Shared Network (5), and RTCP
messages can be sent and received, (6) and (7).
Davies, Read, Scott, Cordell [Page 24]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| (1) Set Remote(RTP) | | |
|------------------->>>| |---->>>|
| | | |
| (2) Set Remote(RTCP) | | |
|------------------->>>| |---->>>|
| | | |
| (3)<Signal RTCP | | |
| address A:a+1> | | |
|------------------->>>| |---->>>|------->>>
| | | |
| (4) RTP packet | | |
===============>>>|===================>>>| |====>>>|=======>>>
| | | |
| (8) RTCP Send Report | | |
===============>>>|===================>>>| |====>>>|=======>>>
| | | |
| (9) RTCP Recv Report | | |
<<<===============|<<<===================| |<<<====|<<<=======
| ---- |
Figure 13 - Configuring an Outgoing Media Flow
Figure 13 shows the sequence of messages required to set up an
outgoing uni-directional Media Flow. Note: The numbering of messages
in Figure 11 is carried over to Figure 13 to show the commonality
between the procedures.
The Application Proxy must set the remote addresses that the Proxy
Extension Agent will send RTP and RTCP packets to, (1) and (2).
Having set the addresses the Application Proxy will use the
signalling protocol (H.323, SIP etc.) to send the RTCP address and
port to the device in the Shared Network (3).
RTP can be sent into the shared network (4), and RTCP messages can be
sent and received, (8) and (9).
Davies, Read, Scott, Cordell [Page 25]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
7.7. Closing a Media Flow
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| | | |
| (1) Close Media Flow | | |
|------------------->>>| |---->>>|
| | | |
| (1) Close Media Flow | | |
| Ack | | |
|<<<-------------------| |<<<----|
| | | |
| ---- |
Figure 14 - Closing a Media Flow
Figure 14 shows the message sequence used to close a Media Flow.
8. Examples of Operation
This section contains examples that demonstrate the traversal
mechanism applied to the SIP VoIP signalling protocol.
Davies, Read, Scott, Cordell [Page 26]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
8.1. Handling Inbound SIP Call Signalling
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
| (1) INVITE + | | |
| ports a,a+1 | | |
|<<<- - - - - - - - - -| |- - - -|<<<===========
| | | |
| (2) Create Media Flow| | |
|------------------->>>| |---->>>|
| | | |
| (3) Create Media | | |
| Flow Ack | | |
| Ports = A:b,A:b+1 | | |
| Tokens = 1234, 2345 | | |
|<<<-------------------| |<<<----|
| | | |
| (5,6) RTP/RTCP Probes| | |
| Token = 1234, 2345 | | |
|===================>>>| |====>>>|
| | | |
| (7,8) Probe Acks | | |
|<<<-------------------| |<<<----|
| | | |
| (9,10) Set RTP/RTCP | | |
| Remote Addr | | |
(11) INVITE + | ports a,a+1 | | |
ports c,c+1 |------------------->>>| |---->>>|
<<<===============| | | |
| | | |
(12,13) RTP/RTCP | (14,15) RTP/RTCP | | |
Packets | Packets | | |
===============>>>|===================>>>| |====>>>|===========>>>
| | | |
(16) 200 OK + | (17) 200 OK + | | |
ports c,c+1 | ports b,b+1 | | |
===============>>>|- - - - - - - - - - ->| |- - >>>|===========>>>
| | | |
(20,21) RTP/RTCP | (18,19) RTP/RTCP | | |
<<<===============|<<<===================| |<<<====|<<<===========
| | | |
(23) SIP ACK | (22) SIP ACK | | |
<<<===============|<<<- - - - - - - - - -| |<<< - -|<<<===========
| | | |
| ---- |
----->>> = Control Channel Messages =====>>> = UDP Packets
- - ->>> = Sub-channel Messages = = =>>> = Messages over TCP
Figure 15 - Signalling During an Incoming SIP Call
Davies, Read, Scott, Cordell [Page 27]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
Figure 15 shows how some of the elements of the mechanism combine to
handle an incoming SIP call.
It is assumed that the Proxy Extension Agent has already been
instructed to create a UDP socket bound to port 5060 that can receive
incoming SIP messages. When such a message is received, it will be
forwarded to the Application Proxy along with the transport
information from where the message was received (1).
The Application Proxy will analyse the SIP messages and determine
what it requires in terms of media forwarding ports on the Proxy
Extension Agent. Once it has done this it will instruct the Proxy
Extension Agent to create media connections (2).
If the Proxy Extension Agent is able to allocate the required ports,
it will acknowledge the Create Media message, specifying the public
addresses it has created, and a set of tokens to be used in the probe
packets (3).
The Application Proxy is now able to create the required NAT bindings
using probes (5) (6) which the Proxy Extension Agent should
acknowledge (7) (8). Having received acknowledgement that the
probing has been successful, the Application Proxy informs the Proxy
Extension Agent where the RTP and RTCP media should be forwarded to
(9) (10).
At this point the Application Proxy has enough information to modify
the INVITE message before forwarding it into the private network
(11). Once this is done, any RTP and RTCP received from the private
network can be forwarded onto the shared network (12) (13) (14) (15).
At some point the Application Proxy should receive a final response
from the private network (in this case a 200 OK) (16), which the
Application Proxy forwards after modifying the SDP media addresses to
point to the Proxy Extension Agent (17).
It is now possible for bi-directional RTP/RTCP to flow (18) (19) (20)
(21).
The process is completed when the Proxy Extension Agent receives a
SIP ACK from the shared network (22) (23).
Davies, Read, Scott, Cordell [Page 28]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
8.2. Handling Outbound SIP Call Signalling
Proxy
Private Application Firewall Extension Shared
Network Proxy & NAPT Agent Network
| ---- |
(1) INVITE + | | | |
Ports = l,l+1 | | | |
===============>>>| (2) Create Media Flow| | |
|------------------->>>| |---->>>|
| | | |
| (3) Create Media | | |
| Flow Ack | | |
| Ports = A:m,A:m+1 | | |
| Tokens = 3456, 4567 | | |
|<<<-------------------| |<<<----|
| | | |
| (4,5) RTP/RTCP Probes| | |
| Token = 3456, 4567 | | |
|===================>>>| |====>>>|
| | | |
| (6,7) Probe Acks | | |
|<<<-------------------| |<<<----|
| | | |
| (8) INVITE + | | |
| Ports = m,m+1 | | |
|- - - - - - - - - - ->| |- - >>>|===========>>>
| | | |
| (9,10) RTP/RTCP | | |
(11,12) RTP/RTCP | Packets | | |
Packets |<<<===================| |<<<====|<<<===========
<<<===============| | | |
| (13) 200 OK + | | |
| Ports = n,n+1 | | |
|<<<- - - - - - - - - -| |<<< - -|<<<===========
| | | |
| (14,15) Set RTP/RTC | | |
| Remote Addr | | |
(16) 200 OK + | ports n,n+1 | | |
Ports = o,o+1 |------------------->>>| |---->>>|
<<<===============| | | |
| | | |
(17,18) RTP/RTCP | (19,20) RTP/RTCP | | |
Packets | Packets | | |
===============>>>|===================>>>| |====>>>|===========>>>
| | | |
(21) SIP ACK | (22) SIP ACK | | |
===============>>>|- - - - - - - - - - ->| |- - >>>|===========>>>
| | | |
| ---- |
Figure 16 - Signalling During an Outgoing SIP Call
Davies, Read, Scott, Cordell [Page 29]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
Figure 16 shows the handling of an outbound SIP call. The sequence
of events is initiated when the Application Proxy receives a SIP
INVITE on a port that it has already allocated for receiving SIP
messages (1).
The allocation of media ports and the probing is identical to that
shown in Figure 15 for an inbound call (2) (3) (4) (5) (6) (7).
From these steps the Application Proxy will have learnt the addresses
and ports allocated by the Proxy Extension Agent for this media flow,
and is able to modify and forward the INVITE message accordingly (8).
The Proxy Extension Agent is now able to forward any received RTP and
RTCP packets on to the Application Proxy, which will in turn forward
them on to the private network (9) (10) (11) (12).
If the call is to complete, the Proxy Extension Agent will receive a
200 OK, which it will forward to the Application Proxy (13). From
this the Application Proxy can tell where the Proxy Extension Agent
should forward RTP and RTCP packets, and informs the Proxy Extension
Agent accordingly (14) (15).
Prior to forwarding the 200 OK to the private network, the
Application Proxy modifies the message so that RTP and RTCP packets
will be sent to it, rather than the original addresses (16).
RTP and RTCP packets may now flow from the private to the shared
network (17) (18) (19) (20).
The sequence is completed by the exchange of a SIP ACK message (21)
(22).
9. Intra-Enterprise Calls
When a call is made between two agents within the same enterprise, it
is desirable to avoid sending media out onto the shared network and
then looping it back into the private network. Not only does this
needlessly occupy precious bandwidth on the connection path to the
network provider, but it also exposes the media to eavesdropping and
is thus a security risk.
To prevent this the Application Proxy can analyse the media addresses
received in the signalling. If the returned addresses are those of
its Proxy Extension Agent, then it can deduce that the call is being
looped back. It is then able to modify the signalling so that the
calling devices send media directly, without traversing the firewall
installation.
Davies, Read, Scott, Cordell [Page 30]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
_____
| Ext |
|Agent|
|__ __|
|
|
---------------------
__|__
| |
| PEA |
|__ __|
|
__|__
| FW |
| NAT |
|__ __|
|
__|__
| |
| AP |
|__ __|
|
-----------------------------------------------
| |
__|__ __|__
| | | |
| UA1 | | UA2 |
|_____| |_____|
Figure 17 - Intra-Enterprise Call
In Figure 17 UA1 wishes to call UA2 using the services of the
External Agent, ExtAgent. But the media must flow directly between
UA1 and UA2.
Call signalling will be routed from UA1 via the Application Proxy and
the Proxy Extension Agent to ExtAgent and then from ExtAgent via the
Proxy Extension Agent and the Application Proxy to UA2.
Two Media Flows will be created as a consequence of the signalling,
one between UA1 via the Application Proxy and the the Proxy Extension
Agent to the Shared Network, the other between UA2 via the
Application Proxy and the Proxy Extension Agent to the Shared
Network.
UA1 advertises its media address to the Application Proxy.
The Application Proxy sets up a Media Flow for UA1 and advertises the
media address information at the Proxy Extension Agent to the
ExtAgent.
The ExtAgent forwards the media address information received from the
Davies, Read, Scott, Cordell [Page 31]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
Proxy Extension Agent back via the Proxy Extension Agent to the
Application Proxy.
At this point UA1 has not been told any media address information, it
is waiting for the signalling to complete. The Application Proxy has
not yet started the signalling to create the media flow for UA2.
The Application Proxy looks up the media address information and
finds that there is a matching Media Flow for UA1.
The Application Proxy advertises UA1's media address information to
UA2 and remembers that when it completes media set up signalling to
UA1 it must supply UA2's media address information.
The Application Proxy sets up a second Media Flow for UA2 whose media
address information is advertised to ExtAgent, even though the Media
Flow will not be used. The media address information is required to
complete the signalling with ExtAgent.
ExtAgent completes the media signalling via the Proxy Extension Agent
to the Application Proxy for UA1.
The Application Proxy advertises UA2's media address information to
UA1 as it has remembered to do.
10. Security Considerations
The major change in this new version is to swap around the locations
of the two main functional components. This places the controlling
component behind the firewall, thus offering it some protection
against attack. Threat analysis has still to be fully completed, but
it is anticipated that locating the controlling component within the
protection offered by the firewall should ensure that the method
offers no more of a threat than any other host located behind a
firewall.
While, with the new swapped configuration, there is less of a need
for the Application Proxy and the Proxy Extension Agent to
authenticate each other, we still recommend that this procedure take
place. This will ensure that the Proxy Extension Agent knows that it
is acting on genuine commands, and means that a malicious agent
acting within the firewall protected zone is unable to use the method
to effectively open more holes in the firewall than would otherwise
be available to them.
As the Application Proxy is interpreting the signalling involved it
can make sure that all the signalling is valid, and thus provides
full stateful inspection capabilities rather than relying on simple
packet filtering. Similarly, the Application Proxy can check that
the media packets have the correct structure for RTP and RTCP.
At present it is anticipated that the authentication scheme will have
Davies, Read, Scott, Cordell [Page 32]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
a modular nature so that the mechanism is not locked into one
particular authentication scheme. There is still some work to do in
this area, and input on the various options for authentication (and
encryption) are solicited.
One area that does need further attention is that of end-to-end
authentication and encryption. As the Application Proxy and Proxy
Extension Agent have to handle media, the Application Proxy will have
to modify the protocol messages involved in the signalling so that
media is sent to them rather than directly to the destination host.
This will affect any message integrity-checking scheme that is
employed between the two end systems. Note that it should still be
possible to employ end-to-end encryption of the media, but the
Application Proxy will no longer be able to analyse whether the
packets have the correct format to be RTP or RTCP (although it will
be able to analyse whether they appear at the correct rate and have
roughly the correct size).
11. Conclusions
In summary, the technique provides a method for allowing multimedia
systems (such as those using SIP, H.323 and MEGACO/H.248) located in
private IP networks to connect to a shared network via firewall and
NAPT functions. The method does not compromise the existing security
procedures and measures, and avoids the need to upgrade existing
firewalls, routers and proxies. It also allows full NAPT to be
applied to IP connections without the NAPT function interpreting or
understanding the communication protocols being used. Multiple NAT
functions can be traversed, either by suitable positioning of a
single Application Proxy / Proxy Extension Agent pair, or by
deploying multiple Application Proxy / Proxy Extension Agent pairs.
12. Acknowledgements
We would like to thank Greg Adams in the team at Ridgeway Systems &
Software for helping to architect, implement and verify this method.
13. Authors' Addresses
Steven Davies
Ridgeway Systems & Software
66 Suttons Business Park
Reading, RG6 1AZ
England
sdavies@ridgeway-sys.com
Davies, Read, Scott, Cordell [Page 33]
Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001
Steve Read
Ridgeway Systems & Software
66 Suttons Business Park
Reading, RG6 1AZ
England
sread@ridgeway-sys.com
Barry Scott
Ridgeway Systems & Software
66 Suttons Business Park
Reading, RG6 1AZ
England
bscott@ridgeway-sys.com
Pete Cordell
Ridgeway Systems & Software
66 Suttons Business Park
Reading, RG6 1AZ
England
pete@tech-know-ware.com
14. Bibliography
[1] M. Holdrege and P. Srisuresh, "Protocol complications with the IP
network address translator (NAT)," Request For Comment 3027, Internet
Engineering Task Force, Jan. 2001.
[2] ETSI TIPHON Requirements Definitions Study DTR 01012 "Firewall
Aspects of Inter-domain Routing". Sept. 2000. Work in progress.
[3] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through
firewalls and NATs," Internet Draft, Internet Engineering Task Force,
Feb. 2000. Work in progress.
[4] P. Srisuresh, J. Kuthan, and J. Rosenberg, "Middlebox
communication architecture and framework," Internet Draft, Internet
Engineering Task Force, Feb. 2001. Work in progress.
[5] T. Dierks, C. Allen, "The TLS Protocol Version 1.0." Request
For Comment 2246, Internet Engineering Task Force, January 1999.
Davies, Read, Scott, Cordell [Page 34]