Internet DRAFT - draft-stott-behave-safenet
draft-stott-behave-safenet
BEHAVE Working Group D. Stott
Internet Draft R. Townsend
Expires: December 31, 2005 Lucent Technologies/Bell Labs
June 29, 2005
SAFENeT: Server-based Architecture For
Enterprise NAT and Firewall Transversal
draft-stott-behave-safenet-00.txt
IPR Statement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Abstract
One of the main challenges hindering the acceptance of VoIP is a
standards-based solution for traversing middleboxes such as Network
Address Translation (NAT) and FireWall (FW) boxes. This Internet-
Draft presents SAFENeT, a protocol that is intended to operate in an
enterprise environment and that allows the accommodation of real-time
services by the call server, internal to the enterprise network, to
communicate with the NAT/FW to enable the transversal of real-time
services including VoIP. This document describes the SAFENeT
architecture and protocol and shows how it overcomes the problems
caused by NATs/FWs. The SAFENeT architecture also enables security
features such as data confidentiality and digital integrity to be
used for the VoIP traffic traversing the NAT/FW.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 The NAT Routable Address Problem . . . . . . . . . . . . . 3
1.3 The VoIP Binding Problem . . . . . . . . . . . . . . . . . 3
1.4 Security Problems Caused by NATs and FWs . . . . . . . . . 4
1.5 SAFENeT as a Solution for Real-time Services . . . . . . . 4
1.6 Organization of This Internet-Draft . . . . . . . . . . . . 5
2. Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Application Layer Gateways (ALGs) . . . . . . . . . . . . . 5
2.2 Media Relays (MRs) . . . . . . . . . . . . . . . . . . . . 6
2.3 Session Border Controllers (SBCs) . . . . . . . . . . . . . 6
2.4 The MIDCOM and NSIS Solutions . . . . . . . . . . . . . . . 7
Stott & Townsend Expires – December 31, 2005 [Page 1]
Internet Draft SAFENeT June 29, 2005
2.5 RTP-based Solutions . . . . . . . . . . . . . . . . . . . 7
2.6 Controllable Firewalls . . . . . . . . . . . . . . . . . . 8
3. The SAFENeT Solution - Server-based Architecture For
Enterprise NAT/FW Transversal . . . . . . . . . . . . . 8
3.1 An Overview of SAFENeT . . . . . . . . . . . . . . . . . . 8
3.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Improvement Rationales . . . . . . . . . . . . . . . . . . 11
4. Examples and Details of SAFENeT . . . . . . . . . . . . . . . 13
4.1 Overview of Examples Illustrating SAFENeT . . . . . . . . . 13
4.2 Diagrams of Examples Illustrating SAFENeT . . . . . . . . . 14
4.3 Details of SAFENeT Communication Protocol (SCP) . . . . . . 21
4.4 Details of SAFENeT UA Communication Protocol (SUCP) . . . . 23
4.5 Illustrative Example of SCP and SUCP . . . . . . . . . . . 24
4.6 SAFENeT Block Caching Optimization . . . . . . . . . . . . 26
5. Discussion of Concerns . . . . . . . . . . . . . . . . . . . . 27
5.1 Don’t Mess with the Firewall . . . . . . . . . . . . . . . 27
5.2 Multiple NATs . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Complex Enterprise Topologies . . . . . . . . . . . . . . . 29
6. UNSAF Architectural Considerations . . . . . . . . . . . . . . 29
6.1 Addressing UNSAF Architectural Considerations in General . 29
6.2 Addressing Specific UNSAF Architectural
Considerations Per IAB . . . . . . . . . . . . . . . . . 30
6.3 IAB Consideration Summary . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1 Normative References . . . . . . . . . . . . . . . . . . . 33
9.2 Informative References . . . . . . . . . . . . . . . . . . 33
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 35
Status of This Document . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction
1.1 Overview
Firewalls (FW) are essential in today’s environment for protecting
corporate and academic university networks from outside attacks and
for partitioning large internal networks for security reasons such as
between different organizations within these internal networks.
While Network Address Translation (NAT) boxes are common for
overcoming the limitations due to the scarcity of available IP
addresses, they also provide privacy through isolation of internal
networks (and the identity of individual users) from visibility from
Stott & Townsend Expires – December 31, 2005 [Page 2]
Internet Draft SAFENeT June 29, 2005
the outside. One of the challenges hindering the acceptance of VoIP
is a standards-based method for traversing boxes such as NATs and
FWs.
"Middleboxes" are defined as in [MIDBOX] –
any intermediary box performing functions apart from normal,
standard functions of an IP router on the datagram path between a
source host and destination host. In this Internet-Draft,
middlebox refers only to NATs and FWs.
1.2 The NAT Routable Address Problem
The way VoIP establishes an RTP session creates problems when a NAT
is involved. The VoIP protocols assume that the initiating endpoint
advertises an IP address/port number that is routable from the remote
receiving host and is unmodified by any network equipment. Neither
of these conditions are true when a NAT is present. The Initiating
Phone’s IP address is generally a private address that is not
routable (i.e., known) from outside the NAT and the transmitted port
number is not the same as the one determined by the Initiating Phone
because the NAT changes it. Therefore, the recipient has no way to
determine a connection back to the Initiating Phone.
1.3 The VoIP Binding Problem
Typical Internet applications use a simple client/server model in
which the client connects to a well-known port number on the server.
VoIP is different from these typical Internet applications because it
uses separate signaling and bearer sessions (and may even have
additional sessions (e.g., RTCP) to monitor the quality of the bearer
channel). The bearer and signaling channels must be bound so that
the bearer traffic goes to the correct endpoint. The signaling
session uses the familiar client/server model for setting up and
taking down the bearer connection but is also responsible for
establishing parameters for that bearer connection. The bearer
session is peer-to-peer.
FWs are usually configured to (a) allow traffic to specific ports on
specific servers (usually in a demilitarized zone (DMZ)), (b) permit
local/private hosts behind the FW to open connections to outside
servers, and (c) permit the reply via an authorized, previously made
connection. When the FW opens a connection based on a request from
an internal client and permits packets to flow through, it records
the ports and addresses of the internal Initiating Phone to identify
where to send the reply. With VoIP, the endpoints (i.e., both
Initiating Phone and Receiving Phone) independently open sockets to
receive bearer traffic. Because the FW does not initiate the
traffic, it is unable to anticipate the traffic from a remote host
(to say nothing about guaranteeing the binding of both the bearer and
Stott & Townsend Expires – December 31, 2005 [Page 3]
Internet Draft SAFENeT June 29, 2005
signaling channels for the VoIP session) and blocks the connection.
Further, since the RFC 3550 on RTP [RTP] does not specify
definitively what the endpoint must choose as port numbers (on a
session–by-session basis), the FW administrator cannot know which
ports to open to incoming replies (as would be done for normal
Internet replies from servers) and is faced with opening nearly all
UDP ports – not a good thing for security reasons.
1.4 Security Problems Caused by NATs and FWs
For environments needing a secure connection (bearer channel,
signaling channel or both), Application Layer Gateways (ALG),
traditionally used to add intelligence to middleboxes to handle
applications such as VoIP, create difficulties for encrypted traffic.
Security measures such as encryption that are designed to protect
signaling data from malicious network entities have the effect of
hiding the data from the ALG. Since ALGs cannot look at the data
being transported, they block VoIP bearer traffic. So VoIP cannot be
supported in secure environments. UAs wishing to set up a secure
connection to achieve data confidentiality and data integrity for
signaling likewise find that the current systems do not support this
functionality. Additionally, since the NAT changes the source
address, the hash produced by the initiating host in a digital
signature will not be confirmed by the receiving host and an error
message will be generated.
1.5 SAFENeT as a Solution for Real-time Services
SAFENeT is proposed as a solution for any real-time services and,
specifically, for VoIP for enterprise or academic environments. This
Internet-Draft distinguishes an enterprise network from the
residential case in which each customer may have his or her own NAT
and the ISP on the public side of the NAT owns the call server. The
residential case is more likely to accept ICE because they have to
trust the ISP's call server (and might as well trust the path to the
STUN server the call server that the ISP also owns) and they have
fewer concerns about potential "bad" behaviors from ICE, such as
routing internal calls though the STUN/TURN server).
In this Internet-Draft, the term VoIP is used to reflect the
characteristics of real-time services including VoIP as well as other
applications such as video and IM.
This Internet-Draft proposes a solution optimized for VoIP. SAFENeT
solves the problems of return routable addresses, binding the
signaling and bearer streams, and the security issues of encryption
for confidentiality (supporting hop-by-hop encryption and end-to-end
encryption by the UA of S/MIME bodies) and digital signatures for
Stott & Townsend Expires – December 31, 2005 [Page 4]
Internet Draft SAFENeT June 29, 2005
integrity. SAFENeT does not address privacy in the Rec. X.805 [X805]
sense.
Note: In this Internet-Draft, the term ‘encryption and digital
signatures’ and its variants is meant to convey the concepts
of both encryption, i.e., data confidentiality, and digital
signatures including using message digests with a hash
calculation on the message contents, i.e., data integrity, as
in [X805].
The intent of this version of the Internet-Draft is to see if there
is any interest in pursuing the proposal and to elicit comments and
discussions on problem areas that need more work.
1.6 Organization of This Internet-Draft
While some solutions exist for handling NAT/FW transversal, all have
drawbacks; Section 2 describes these existing solutions. Section 3
proposes the SAFENeT solution with assumptions and rationales.
Section 4 gives examples and details of the SAFENeT solution.
Section 5 adds further discussion of concerns of NAT/FW traversal.
Section 6 covers considerations to be made when selecting a technique
for traversing a NAT per the IAB draft [NAT-TRAV]. Section 7 is the
section on security. Section 8 is the IANA considerations and
Section 9 contains references.
2. Existing Solutions
This section describes a number of technologies that have been
proposed to solve the NAT/FW transversal problem. As we show,
clearly none of them is suitable for enterprise VoIP systems in which
a high level of security is a principal requirement. An IAB draft
[NAT-TRAV] details considerations to be made when selecting a
technique for traversing a NAT.
From Rosenberg, [ICE], “Unfortunately, these techniques all have
pros and cons which make each one optimal in some network topologies,
but a poor choice in others.”
2.1 Application Layer Gateways (ALGs)
ALGs are often integrated with NAT boxes. They process every packet
sent through the box and inspect the packet contents for pre-
programmed application-specific fields with address or port
information. For example, an ALG with VoIP support might inspect the
packets looking for INVITE messages. The ALG would read the INVITE
message to get the UA’s address and port number (from the SDP), bind
Stott & Townsend Expires – December 31, 2005 [Page 5]
Internet Draft SAFENeT June 29, 2005
a new address and port number for that media stream, and rewrite the
SDP with the new (public) address and port number.
The key difficulties in using an ALG in this situation are (a) the
need to reprogram the ALG to support each new protocol, (b) the need
to address the resource intensiveness of a box in the main stream of
communication, and (c) the obvious inability to support protocols
using cryptography (e.g., S/MIME) if the application requires
confidentiality.
2.2 Media Relays (MRs)
Another class of transversal techniques is illustrated by a type of
box called an MR. MRs terminate the signaling protocol on each side
of the relay (similar to a media gateway but using the same protocol
on both the input and output sides). The advantages of an MR are
that (a) the signaling and bearer paths are forces through the same
point, (b) the session is broken into 2 independent sessions such
that any end-to-end requirements of the protocol do not need to apply
across the box, and (c) the box serves as an endpoint for encryption,
i.e., the clear text is available for reading and rewriting in the
box. One example of this technique in SIP is called a back-to-back
UA (B2BUA). The B2BUA box implements a complete SIP stack on each
side of the B2BUA function.
MRs are generally the network engineers last choice. They are
clearly performance and reliability bottlenecks and they break
security assumptions including end-to-end authentication. MRs limit
the effectiveness of the signaling protocol because messages are no
longer truly end-to-end. For example, they are likely to drop
headers they do not understand, i.e., new features may require
reprogramming of the MR.
2.3 Session Border Controllers (SBCs)
A special case of an MR is the SBC. SBCs are gateway boxes meant to
sit at the edge of a network and provide peering to various telephony
networks, including video, IM, and gateways to other IP or TDM
networks. They often add features such as firewalling, QoS and SLA
management, and limited intrusion detection/prevention. SBCs
advertise the capability of providing NAT transversal and FW
pinholing. A careful study of these claims reveals that they are
implementations of an ALG and, as such, have the same limitations
described in the ALG section above; additionally, most SBCs are MRs
and have the attributes of Section 2.2.
Stott & Townsend Expires – December 31, 2005 [Page 6]
Internet Draft SAFENeT June 29, 2005
2.4 The MIDCOM and NSIS Solutions
The MIDCOM WG has been addressing solutions in which one trusted
third party entity controls the transport layer behavior of another
entity in the network to support the transport of an application.
The WG has discussed protocols where a call server controls a FW to
support VoIP is one such example. The WG has also developed a series
of NAT transversal protocols for VoIP: Interactive Connectivity
Establishment [ICE], Simple Transversal of UDP Through Network
Address Translators [STUN], Traversal Using Relay NAT [TURN].
The basic architecture of these protocols is to (a) place a protocol
server outside the NAT and (b) modify the client application to work
with the protocol. The basic distinction between STUN and TURN is
that STUN only supports UDP and TURN requires all traffic to go
through the server.
SAFENeT has an advantage over ICE in that it requires a smaller
number of messages to determine which protocol it should use and that
packet loss may cause ICE to choose non-ideal paths (e.g., hosts on
the same network may end up communicating through the STUN server if
the wrong packet is lost). Both STUN and TURN have security problems
as stated in their respective specifications. TURN requires all
packets to go through the TURN server, becoming a performance
bottleneck and coming at high cost to the provider of the TURN
service. [TURN] also states a reliability issue, “TURN will **almost
always** provide connectivity to a client.”
The NSIS WG has also been working on middlebox transversal. These
protocols generally allow, but not require, a third party such as a
proxy to control the middlebox to support traversal features.
Future efforts in NSIS are expected to provide significant help in
supporting communication between the proxy and the middlebox.
Unfortunately, the recent NSIS effort is currently incomplete and
does not meet the needs for enterprise quality VoIP.
2.5 RTP-based Solutions
VoIP’s separation of control and bearer streams (and, in particular,
negotiating the bearer port numbers from inside the control protocol)
causes problems for administering FWs. FW administrators need to (a)
use bulky ALGs to handle VoIP traffic or (b) essentially allow
transversal for all UDP traffic. When the control messages (e.g.,
the SDP bodies) are encrypted or even just authenticated with an
integrity check, the network administrator is placed in the bad
situation of allowing insecure traffic or barring certain traffic.
One Internet-Draft [expired], now expired, modified the RTP
specification to allow all RTP streams to a single host to be
Stott & Townsend Expires – December 31, 2005 [Page 7]
Internet Draft SAFENeT June 29, 2005
multiplexed to the same port. Multiplexing RTP streams to a single
well-known port substantially reduces the FW administration problem
and VoIP will behave similarly to most typical Internet applications.
In theory, the FW could communicate with the call server to
determine which initiating and receiving hosts have valid connections
open.
[expired] advocates having RTP and RTPC on separate well-known ports.
While they could share the same port, there are arguments against
doing that, namely, that (a) the 2 streams may have different QoS
parameters since those parameters are assigned on a per-connection
basis and not on a per-packet basis and (b) sending both RTP and RTPC
packets to the same port may cause existing RTP stack to fail. These
authors do not know if this work will be continued in the future.
2.6 Controllable NAT/FWs
One study [BLTJ] demonstrated a VoIP system that communicated with a
specialized NAT/FW to support address and port mapping and pinholing
under the control of a SIP proxy connecting two SIP phones. In this
architecture, the SIP proxy used ITU-T Rec. H.248/MEGACO [H248] to
communicate with the NAT/FW to request address and port mappings to
open pinholes based on the MEGACO messages. The architecture solved
the problem for NAT/FW transversal but not end-to-end integrity.
3. The SAFENeT Solution - Server-based Architecture For Enterprise
NAT/FW Transversal
3.1 An Overview of SAFENeT
SAFENeT uses a different approach in solving the NAT/FW traversal
problem from those described above and is inherently simpler in
operation. SAFENeT solves the NAT problem by having a SIP proxy
function as a call server internal to the enterprise network. The
call server communicates with the NAT/FW, negotiates an addressing
mapping for the session, then communicates the result to the
local/private endpoint. Optionally, it moves the transversal logic
from the endpoints to a call server, one under the control of the
enterprise, and opens up the possibility of allowing a secure
environment.
This architecture solves the NAT routable address problem, provides
for appropriate binding of the two sessions needed by VoIP, and
optionally allows for security measures (data confidentiality and
integrity) if desired.
SAFENeT requires two area of specification. The first area of
specification is a standard secure interface to the NAT/FW to allow a
Stott & Townsend Expires – December 31, 2005 [Page 8]
Internet Draft SAFENeT June 29, 2005
trusted server (e.g., the call server) to cooperate with the NATs/FWs
to establish safe bindings that allows the authorized traffic (i.e.,
bearer stream) to traverse the NAT/FW.
The first part is nothing more than an application protocol for SIP
proxies to communicate with the NAT/FW as in and drafts in NSIS
similar to [NSIS-FW] and [NSLP]. The call server would obtain a NAT
binding for the session and open a pinhole in the FW. In a system
not needing end-to-end cryptography or digital signatures for
confidentiality or integrity respectively, this SAFENeT Communication
Protocol (SCP) alone is sufficient for a viable, working system; see
Section 4.3 for details.
SCP differs from the other work in NSIS in that it is meant to be
used for VoIP and similar applications while using the
procedures/protocols for controlling middleboxes (NATs and FWs)
[NSLP] in allowing the transversal of application streams. It is
intended to be used between a trusted server and the relevant
middleboxes and covers the case in which the bearer and signaling
paths are separate. It is not meant to be a replacement for the NSIS
work but does allow a migration from SCP to the NSIS solution. NSIS-
aware middleboxes could be configured to use SCP and the SAFENeT
architecture.
A second area of specification is an extension to the SIP
specification to allow the User Agents (UAs) to learn about the NAT
bindings thereby enabling end-to-end cryptography or digital
signatures between UAs (e.g., S/MIME encoded Session Description
Protocol (SDP) bodies as described in RFC 3261 [SIP]). This optional
protocol is known as SUCP for SAFENeT UA Communication Protocol, the
details being described in Section 4.4. Since the rationale of end-
to-end cryptography is to ensure the SDPs are not read by a malicious
interloper, eliminating the need to traverse network boxes that can
read or modify the bit stream provides an extra bonus for security.
Offering a protocol allowing digital signatures adds data integrity
as a security attribute. The UA needs to generate the SDP body with
the public address and port number as established by the SIP proxy.
The UA must obtain this information from the call server before
sending the INVITE or OK messages and before computing the hash that
is sent to the remote receiver (the description in Section 4.2 below
will illuminate these details better).
3.2 Assumptions
This section describes some simple assumptions about the target
system under which SAFENeT correctly operates. They were selected to
reflect a typical enterprise or academic VoIP system with high
security needs. Most medium and large business firms, including
Stott & Townsend Expires – December 31, 2005 [Page 9]
Internet Draft SAFENeT June 29, 2005
those in the fields of finance, medical and military are expected to
be in this category.
1) The basic example of an enterprise network has NAT(s) and/or
FW(s) at the boundary to the public network. See Figure 1.
The FW allows incoming SIP messages between remote hosts and an
internal SIP proxy.
+----------+
| Call |
| Server |
+----------+
\
\
\
__\________ ___ ____
/ \ / \\/ \
| \ // )) \\
+----------+ +----------+ // \\ +----------+
| IP | | NAT/ |____( Internet )_____| Remote |
| Phone | | FW | \\ // | Phone |
+----------+ +----------+ \\ ) // +----------+
\___/ \___/
Figure 1: Architecture of SAFENeT
2) The enterprise IT management controls the servers in the
enterprise network and knows and controls the topology of the
private network (e.g., between local/private clients and their
SIP proxy(ies)). The enterprise administrator can configure
the NAT/FW to permit only certain addresses and ports to be
used for VoIP connections involving particular servers. While
the NAT/FW may be owned by an entity other than the
enterprise, the enterprise must be able to control the NAT/FW.
3) The signaling path is constrained to always pass through the
call server.
4) Traditional security mechanisms by the enterprise protect the
call server and middlebox from unauthorized physical or
administrative access.
5) The internal call server is a trusted entity.
6) Communication between UAs in the local/private realm and their
call server(s) does not traverse the boundary with the public
network.
Stott & Townsend Expires – December 31, 2005 [Page 10]
Internet Draft SAFENeT June 29, 2005
7) The protocol proposed in this Internet-Draft is assumed to run
over a secure protocol such as TLS using mutually
authenticated certificates to provide authentication,
confidentiality, and integrity.
8) Without loss of generality, UAs have local/private addresses
that, in general, have no valid route from the remote UA.
9) The system supports hop-by-hop encryption techniques such as
SIPS over TLS [SIP]. Encrypted messages can only be processed
by SIP entities, i.e., SIP proxies and UAs.
10) The system supports S/MIME. UAs can choose to add (a) end-to-
end message integrity on S/MIME bodies with digital signatures,
(b) end-to-end encryption of S/MIME bodies, or (c) both. UAs
generally use S/MIME to protect the SDP but can also protect a
copy of the SIP headers. Only UAs can process cryptographic
S/MIME bodies. The solution cannot require UAs to copy
encrypted headers (such as media addresses) into clear text
headers as this defeats the purpose of encryption and
introduces potential coherency (i.e., improperly modified
headers) issues.
11) NAT vendors may implement their devices however they see fit.
Without loss of generality, NATs will display behavior as
symmetric NAT [STUN] where the NAT selects new external
address and port numbers for each new connection.
12) It is not acceptable to route traffic between local/private
UAs via the public network. It is also not acceptable for a
UA to send local/private addresses outside the NAT for the
reasons described in the Introduction.
13) The solution may support the case where the call server
applies cryptographic functions on behalf of the UA. Under
this method, the call server could be signing or encrypting
messages on behalf of the UA because the UA do not have the
capability to do so themselves (e.g., lack of a public key
certificate or lack of a software application).
3.3 Improvement Rationales
There are five basic reasons for SAFENeT being a viable (and better)
alternative as a solution to the NAT/FW transversal problem.
1) The call server (a trusted entity inside the enterprise FW)
controls the packet routing for signaling messages.
Stott & Townsend Expires – December 31, 2005 [Page 11]
Internet Draft SAFENeT June 29, 2005
2) The trusted call server handles all signaling message
processing.
3) No additional proxies or servers are required; a call server is
presumed to exist.
4) The UA communicates only signaling/control information with a
trusted SIP proxy, i.e., does not rely on an unknown trust
relationship with a server in the public network.
5) There are no restrictions on types of NATs/FWs SAFENeT can
support.
The first advantage is a clear improvement over ICE and UNSAF-like
systems. The SIP proxy is configured with the simple routing
instructions (such as the subnets with voice endpoints that connect
to the public network, those solely within the local/private
network, default routes toward the NAT/FW, or even where IPv4/IPv6
mappings should be applied) to determine how to route the bearer
streams. Recall that ICE requires complex procedures and message
exchanges to (a) determine the type of NAT as input to selecting the
proper procedure in the STUN server and (b) determine if alternate
paths to the remote host exist.
The second advantage is in contrast to ALG-based solution that
require code to process the VoIP signaling messages. Besides having
a maintenance advantage, the SAFENeT approach makes it easier to
enforce policies because they are processed within a single entity.
The same reasoning can also be applied to note that security is
improved using the SAFENeT architecture.
Unlike several of the alternative solutions, SAFENeT requires no
additional boxes (presuming a server, such as one for session
control, already exists), thereby improving performance,
reliability, and security, and lowering cost.
With SAFENeT, the only entities the UA communicates with are its SIP
proxy (for signaling) and the remote UAs (for bearer traffic). The
SIP proxy provides the binding requests on behalf of the UA, thereby
minimizing the configuration setup/data needed by the UA, this
latter function being applicable only for the option of end-to-end
encryption. The only changes in the UA behavior are (a) code to
handle the slight modification to the SIP headers and (b) the
addition of the functionality for processing a response to the call
server with the NAT mappings between the local/private and public
addresses (described below). In contrast, with the ICE approach,
the UAs in the local/private network all need to be configured with
the addresses of any available STUN or TURN servers with weights to
probabilistically determine how to select each.
Regarding the last advantage, SAFENeT needs to make no distinctions
about NAT behavior as do the alternatives as stated in [ICE].
Stott & Townsend Expires – December 31, 2005 [Page 12]
Internet Draft SAFENeT June 29, 2005
The problems discussed in [NSLP] are either resolved by the SAFENeT
proposal or are not relevant – save one. The issue of QoS signaling
is still relevant and needs to be addressed.
4. Examples and Details of SAFENeT
4.1 Overview of Examples Illustrating SAFENeT
Figure 2 illustrates a VoIP transaction with no NAT in the system;
the system works fine. While the Receiving Phone is shown without a
NAT/FW, there is no loss of generality; the connection protocol is
simply carried out on the receiving side too.
Figure 3 illustrates the well-known NAT problem of an external
address that is not routable from the remote host.
Figure 4 shows a basic version of the SAFENeT solution, i.e., one in
which the message does not involve encryption. As noted earlier, a
similar situation holds true for ALGs with encryption.
Notes for the succeeding diagrams:
Recall that in this Internet-Draft, the term ‘encryption and
digital signatures’ and its variants are meant to convey the
concepts of both encryption, i.e., data confidentiality, and
digital signatures including any hash-oriented message contents,
i.e., data integrity.
The OpenRequest and OpenReply messages signify that the NAT has
generated a binding between the local/private phone and the
public address.
This document distinguishes "end-to-end" encryption (e.g.,
S/MIME) from hop-by-hop encryption (e.g., TLS or IPSec);
end-to-end encryption is hidden from the call server and
middlebox whereas hop-by-hop encryption is processed by the call
server, but not the middlebox
The bindings in the RTP part of the diagram are shown as the
attached destination address/port numbers.
The public IP addresses used in all the examples of this document
are shown as assigned in the TEST-NET and Benchmark Testing
blocks [RFC 3330] and are just that – examples. The two
different blocks were chosen to reflect that, in a real world
implementation, the Initiating Phone and Receiving Phone will be
on different nets.
Figure 5 shows how the basic version fails if the message is
digitally signed. A similar case holds for encrypted messages.
Stott & Townsend Expires – December 31, 2005 [Page 13]
Internet Draft SAFENeT June 29, 2005
Figure 6 shows the SAFENeT version that correctly handles both
encryption and digital signatures.
Figure 7 shows an incoming call and confirms the assertion made above
about no loss of generality.
4.2 Diagrams of Examples Illustrating SAFENeT
Figure 2 depicts a system with null NAT functionality; no problems
arise.
+----------+ +---------+ +---------+ +---------+
|Initiating| | Call | | NAT/FW | |Receiving|
| Phone | | Server | | | | Phone |
+----------+ +---------+ +---------+ +---------+
10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4
| | | |
| F1: INVITE | | |
|------------------>| | |
| | F2: INVITE | |
| |-------------------+------------------>|
| | | F3: OK |
| |<------------------+-------------------|
| F4: OK | | |
|<------------------| | |
| F5: ACK | | |
|------------------>| | |
| | F6: ACK | |
| |-------------------+------------------>|
| | RTP | |
| | 10.0.1.2.:12000 | |
|<------------------+-------------------+-------------------|
| | RTP | |
| | 198.18.2.4:5600 | |
|-------------------+-------------------+------------------>|
| | | |
Figure 2: Example without NAT’s Address Translation
Function Active
Stott & Townsend Expires – December 31, 2005 [Page 14]
Internet Draft SAFENeT June 29, 2005
Figure 3 shows the well-known NAT problem in which case the
Initiating Phone is unaware of the NAT. The Receiver is unable to
route back using the local/private address since the public Internet
has no knowledge of it. ALGs can also offer a specialized solution
to the problem by rewriting the SDP. Subsequently, if the message is
encrypted, the ALG cannot process the message and the transaction
fails. For digital signatures, the message digest is incorrect and
the message is rejected by the Receiver.
+----------+ +---------+ +---------+ +---------+
|Initiating| | Call | | NAT/FW | |Receiving|
| Phone | | Server | | | | Phone |
+----------+ +---------+ +---------+ +---------+
10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4
| | | |
| F1: INVITE | | |
|------------------->| | |
| | F2: INVITE | |
| |-------------------+------------------>|
| | | F3: OK |
| |<------------------+-------------------|
| F4: OK | | |
|<-------------------| | |
| F5: ACK | | |
|------------------->| | |
| | F6: ACK | |
| |-------------------+------------------>|
| | | RTP |
| | | 10.0.1.2.:12000 |
| | | ?? <-----------|
| | | |
Figure 3: Example showing the well-known problem with NATs
for the case of encryption without any attempt
to mitigate and the transaction fails
Stott & Townsend Expires – December 31, 2005 [Page 15]
Internet Draft SAFENeT June 29, 2005
Figure 4 show how a basic SAFENeT offers a solution in the case in
which the message is neither encrypted or digitally signed. The
Proxy generates an exchange with the Initiating Phone to generate,
then later activate, a binding between the local/private address and
the public address being transmitted. No end-to-end encryption nor
digital signature is involved.
+----------+ +---------+ +---------+ +---------+
|Initiating| | Call | | NAT/FW | |Receiving|
| Phone | | Server | | | | Phone |
+----------+ +---------+ +---------+ +---------+
10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4
| | | |
| F1: INVITE | | |
|------------------>| | |
| | F2: OpenRequest | |
| |------------------>| |
| | F3: OpenReply | |
| |<------------------| |
| | F4: INVITE | |
| |-------------------+------------------>|
| | | F5: OK |
| |<------------------+-------------------|
| F6: OK | | |
|<------------------| | |
| |F7: UpdateRequest | |
| |------------------>| |
| | F8: UpdateReply | |
| |<------------------| |
| F9: ACK | | |
|------------------>| | |
| | F10: ACK | |
| |-------------------+------------------>|
| | | RTP |
| | | 192.0.2.11:2346 |
| | |<------------------|
| | RTP | |
| | 10.0.1.2.:12000 | |
|<------------------+-------------------| |
| | RTP | |
| | 198.18.2.4:5600 | |
|-------------------+-------------------+------------------>|
| | | |
| | | |
Figure 4: Example with NAT using a basic SAFENeT without
end-to-end encryption and digital signature support
(and no encryption or digital signing) giving a
successful transaction
Stott & Townsend Expires – December 31, 2005 [Page 16]
Internet Draft SAFENeT June 29, 2005
In Figure 5, we show that encryption and digital signing add another
level of complication. For case with encryption, the INVITE message
cannot be processed by the FW and, for the case with digital
signing, the digest in the F4: INVITE message has not been
recalculated to reflect the proper public address and is therefore
rejected by the Receiver. The transaction does not proceed.
+----------+ +---------+ +---------+ +---------+
|Initiating| | Call | | NAT/FW | |Receiving|
| Phone | | Server | | | | Phone |
+----------+ +---------+ +---------+ +---------+
10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4
| | | |
| F1: INVITE | | |
|------------------->| | |
| | F2: OpenRequest | |
| |------------------>| |
| | F3: OpenRepy | |
| |<------------------| |
| | F4: INVITE | |
| |-------------------+------------------>|
| | | F5: 403 Forbidden |
| |<------------------+-------------------|
| F6: 403 Forbidden | | |
|<-------------------| | |
| | | |
Figure 5: Example with NAT using the basic SAFENeT
without digital signature support
(but with digital signature)
Stott & Townsend Expires – December 31, 2005 [Page 17]
Internet Draft SAFENeT June 29, 2005
In Figure 6, we show SAFENeT with security support to allow
encryption or digital signatures. The public address must be sent
back to the Initiating Phone to encrypt the message including the
public address for the encryption case or to generate a new hash
using the public address before sending out the INVITE* message to
the Receiving Phone for the digital signature case. Now the
transaction can proceed successfully.
When the outgoing message relies on a security certificate, the hash
in the certificate must be recalculated with the proper public
address replacing the local/private address. The term ‘with
mappings’ is used to signify elements in that action.
+----------+ +---------+ +---------+ +---------+
|Initiating| | Call | | NAT/FW | |Receiving|
| Phone | | Server | | | | Phone |
+----------+ +---------+ +---------+ +---------+
10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4
| | | |
| F1: INVITE | | |
|------------------->| | |
| | F2: OpenRequest | |
| |------------------>| |
| | F3: OpenReply | |
| |<------------------| |
| F4: 444 Response* | | |
|<-------------------| | |
| F5: ACK | | |
|------------------->| | |
| F6: INVITE** | | |
|------------------->| | |
| | F7: INVITE** | |
| |-------------------+------------------>|
| | | F8: OK |
| |<------------------+-------------------|
| | F9: UpdateRequest | |
| |------------------>| |
| | F10: UpdateReply | |
| |<------------------| |
| F11: OK | | |
|<-------------------| | |
| F12: ACK | | |
|------------------->| | |
| | F13: ACK | |
| |-------------------+------------------>|
-- Continued on next page --
Stott & Townsend Expires – December 31, 2005 [Page 18]
Internet Draft SAFENeT June 29, 2005
-- From previous page --
| | | RTP/RTCP |
| | | 192.0.2.11:2346/ |
| | | 2347 |
| | |<------------------|
| | RTP/RTCP | |
| | 10.0.1.2.:12000/ | |
| | 12001 | |
|<-------------------+-------------------| |
| | RTP/RTCP | |
| | 198.18.2.4:5600/ | |
| | 5601 | |
|--------------------+-------------------+------------------>|
| | | |
* with mapping information
** with proper credentials
Figure 6: Example with NAT using SAFENeT with end-to-end
encryption and digital signature support
(and with an encrypted or digitally
signed message)
Stott & Townsend Expires – December 31, 2005 [Page 19]
Internet Draft SAFENeT June 29, 2005
Figure 7 shows an incoming call. With similar interactions between
the call server and the local/private phone as described above, the
transaction can proceed successfully.
+----------+ +---------+ +---------+ +----------+
|Receiving | | Call | | NAT/FW | |Initiating|
| Phone | | Server | | | | Phone |
+----------+ +---------+ +---------+ +----------+
10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4
| | | |
| | | F1: INVITE |
| |<------------------+-------------------|
| F2: INVITE | | |
|<-------------------| | |
| F3: OK | | |
|------------------->| | |
| | F4: OpenRequest | |
| |------------------>| |
| | F5: OpenReply | |
| |<------------------| |
| F6: 444 Response* | | |
|<-------------------| | |
| F7: OK** | | |
|------------------->| | |
| | | |
| | F8: OK** | |
| |-------------------+------------------>|
| | | F9: ACK |
| |<------------------+-------------------|
| F10: ACK | | |
|<-------------------| | |
| RTP | | |
| 198.18.2.4:5600 | | |
|--------------------+-------------------+------------------>|
| | | RTP |
| | | 192.0.2.11:2346 |
| | |<------------------|
| | RTP | |
| | 10.0.1.2.:12000 | |
|<-------------------+-------------------| |
| | | |
* with mapping information
** with proper credentials
Figure 7: Example of an incoming call using SAFENeT
with encryption and digital signature support
Stott & Townsend Expires – December 31, 2005 [Page 20]
Internet Draft SAFENeT June 29, 2005
4.3 Details of SAFENeT Communication Protocol (SCP)
SAFENeT defines a protocol (SCP) for communicating between the SIP
proxy (call server) and the NAT/FW similar in functionality to that
of RFC 3303 [RFC3303]. Illustrated in Figure 4, the process includes
(a) the call server acting as a manager requesting a NAT mapping
for the RTP stream described in the SIP SDP,
(b) the NAT/FW reserving the binding and replying to the manager
with the requested mapping,
(c) the manager requesting the binding be enabled,
(d) the RTP communication taking place, and
(e) the manager closing the binding after the call completes.
The protocol is assumed to run over a secure transport protocol such
as TLS [TLS]. TLS is an excellent choice because proxies are already
required to support it. Mutual authentication through public key
certificate validation is required for the system to be secure.
TLS, using mutually authenticated certificates, provides
authentication, confidentiality, and integrity. These properties
provided by TLS, protection against many common security threats,
such as eavesdropping and masquerading. Additionally, mutual
certificate authentication (with Diffie-Hellman-based session key
exchanges, used in most common public-key systems) is used to
prevent man-in-the-middle attacks. Access control to the SCP
manager and agent is well defined and manageable because the set of
managers and agents that can communicate with the SCP boxes is
small.
It is recommended that both the call server and the NAT/FW be
configured with its peer’s public key and that it only accept
connections from devices if it has that device’s public key
configured. The call server is located in a DMZ.
In this process the NAT/FW is an SCP agent and the call server is the
SCP manager. SCP contains the basic messages for opening a session,
updating session parameters, and closing the session. TLS provides
the secure connection. The manager connects to the NAT/FW acting as
an SCP agent once (e.g., at boot time) and reuses the same TLS
connection for all sessions.
Because no communication protocol currently exists to exchange these
types of messages, SAFENeT defines a simple, text-based message
format. The format is conceived to be easy to implement and enhance.
As new protocol are developed (e.g., future NSIS protocols), this
protocol can migrate to the newer one.
The first SCP message from the manager to the agent is the stream
header, used to inform the agent the SCP version number the manager
Stott & Townsend Expires – December 31, 2005 [Page 21]
Internet Draft SAFENeT June 29, 2005
is using. All subsequent messages are a single request or reply
separated by a pair of CRLF as do many applications like SMTP. The
manager can send any of three message types: OpenRequest,
UpdateRequest, and CloseRequest. The agent can reply using
OpenReply, UpdateReply, CloseReply, or ErrorMessage. The agent
replies to a request with a reply message or an error message.
Replies must correspond to the appropriate last request.
If at any point the agent detects an error in request (such as a bad
value or unsupported feature), it replies with an ErrorMessage
instead of the normal reply message. The error message indicates
which field caused the error, the type of error, and an optional text
description of the error.
The agent can also send Info messages to provide asynchronous
notifications to the manager, e.g., a time-out due to inactivity.
Each message follows a common format. The first line is the header
indicating the message type and unique session ID. Because the agent
established the ID, the OpenRequest does not specify one; the agent
chooses one and includes it in the OpenReply message. A message body
consisting of a sequence of request fields, follows the header.
Table 1 shows the possible request fields. Most parameters can be
set to 0 (zero) to indicate the value is unassigned or to –1 to
indicate a wildcard. When the session is activated, the agent must
verify that all the appropriate fields have been set – e.g., a NAT’s
policy may require that the local/private address and port number be
set as well as the remote address. The interface parameter can be
used to specify a particular interface on the NAT/FW. In general,
the manager needs to know *a priori* the meaning of the interface
value (e.g., the NAT/FW may expect the SNMP ifIndex or some other
interpretation). The manager should set the interface value to 0
(zero) as unassigned unless it knows the specific interface value.
Stott & Townsend Expires – December 31, 2005 [Page 22]
Internet Draft SAFENeT June 29, 2005
Table 1 – Request Field Types
+-------------------------------------------------------------------+
| Request | Parameters | Description |
| Type | | |
|----------+---------------+----------------------------------------|
| From: |address port# | The local/private address and port |
| | interface | number and NAT/FW interface |
| | | |
| To: |address, port# | The mapped (public) address and port# |
| | | |
| For: |address, port# | The remote destination |
| | interface | |
| | | |
| Proto: |IP protocol | Specific IP protocol 9E.g., UDP, TCP) |
| | | |
| Active: |Boolean | True to indicate activation of mapping;|
| | | False – not activated |
| | | |
| Action: |type | FW action can be block, reject, allow,|
| | | or log |
+-------------------------------------------------------------------+
4.4 Details of SAFENeT UA Communication Protocol (SUCP)
Just as we need to add a protocol for the manager (call server) to
the agent (NAT/FW), we also need to devise an optional communication
protocol for use between the manager and the UA (agent). This
section defines such a protocol. If another mechanism comes into
use, these messages could be included to enhance that protocol. This
part of the protocol might not be needed if the end-to-end security
aspects of the protocol are not used.
Using Figure 6 as an illustration, SUCP is an extension to the SIP
headers as well as requiring additional SCP interactions. On an
INVITE message, SUCP adds a single header specifying the
local/private address and port number and the remote addresses of the
media sessions (or a list of such tuples if it opens multiple
sessions). Next the manager checks if the message is to traverse (a)
a NAT, (b) a FW and no NAT, (c) both a FW and a NAT, or (d) neither.
For (a) the call server obtains the mappings as describe in Section
4.3, communicates them to the UA, and proceeds using a modified SCP
as in Figure 6. For (b), the call server requests a pinhole be
opened and passes the INVITE as normal. For (c), use the combined
actions for (a) and (b). For(d), the call server passes the INVITE
directly to the remote UA and removes the OpenRequest.
Stott & Townsend Expires – December 31, 2005 [Page 23]
Internet Draft SAFENeT June 29, 2005
An example of the initial SIP header would include information with
the UA address and port number:
MediaMapRequest: saddr=10.0.1.2,sport=12000.
The call server can determine if the session will be using a NAT.
If a NAT is not involved, the call server ignores (or removes) the
request and processes the message as normal.
If a NAT is involved, the call server uses SCP with additional
messages to communicate the binding information to the UA and
proceeds similarly as in Section 4.3. The UpdateRequest/Reply
messages (that are SIP messages) secure the binding from the NAT and
transmits it to the UA. The UA uses this information to encrypt the
SDP or recalculate the message digest. The UA will reconstruct the
SDP with the public address and port numbers (the only address the
remote UA sees), acknowledge the SIP message, and send the new
INVITE with public address, the same Call-ID as the original INVITE,
and the appropriate CSeq number:
MediaMapRequest: saddr=192.0.2.11,sport=2346.
The remote host will then have a routable address and any encrypted
or digitally signed message can be deciphered correctly by the
remote host.
On teardown, the call server uses SCP to delete the binding and/or
close the pinhole.
There is the possibility of using policy use-cases to provide the
communication between the call server and the UA as is currently
being introduced in the SIPPING WG [usecase] since the knowledge and
mechanism may already exist.
4.5 Illustrative Example of SCP and SUCP
In a scenario for an outbound call, using encryption or digital
signature, through a NAT/FW as in Figure 6, the UA sends an INVITE
message (F1) to the call server (see Figures 8a-f).
F1: INVITE +---------------------------------+
| MediaMapRequest: \ |
| saddr=10.0.1.2,sport=12000; \ |
| saddr=10.0.1.2,sport=12001 |
+---------------------------------+
Figure 8a – INVITE Message
Recognizing the sender is inside the NAT/FW, the call server/manager
uses SCP to obtain a mapping for the UA. The manager sends an
OpenRequest message (F2) to the agent (NAT) to open a session based
on the Initiating Phone’s (the local UA’s) private address and port
Stott & Townsend Expires – December 31, 2005 [Page 24]
Internet Draft SAFENeT June 29, 2005
number and the Receiver’s (the remote UA) address. The remote UA is
free to choose any ephemeral port.
F2: OpenRequest +-------------------------------+
| OpenRequest |
| From: 10.0.1.2 12000-12001 0 |
| For: 0 0 |
| Proto: UDP |
| Active: False |
+-------------------------------+
Figure 8b – Request to Open Message
The agent then chooses a session ID and builds a mapping for the
given addresses and port number and replies with an OpenReply message
(F3) that establishes a session ID, 31824 in this example.
F3: OpenReply +-------------------------------+
| OpenReply 31824 |
| From: 10.0.1.2 12000-12001 1 |
| To: 192.0.2.11 2346-2347 |
| Proto: UDP |
| Active: False |
+-------------------------------+
Figure 8c – Reply Message
The manager sends the mapped (public) address and port number to the
UA (F4).
F4: 444 Response +----------------------------------+
| 444 UseMediaMapping: \ |
| saddr=10.0.1.2,sport=12000; \ |
| maddr=192.0.2.11,mport=2346; \ |
| saddr=10.0.1.2,sport=12001; \ |
| maddr=192.0.2.11,mport=2347 |
+----------------------------------+
Figure 8d – Mapping Information to UA Message
At this point, the UA has the NAT mapping it needs to advertise the
public address and port number to the remote UA as F5 F6in Figure 6
F5and the call server forwards the new INVITE to the remote UA as F6
F7using the public address and port numbers.
Stott & Townsend Expires – December 31, 2005 [Page 25]
Internet Draft SAFENeT June 29, 2005
Once the network accepts the call, the manager sends an UpdateRequest
message (F9) to activate the binding for this session (and/or open a
FW pinhole).
F9: UpdateRequest +-------------------------------+
| UpdateRequest 31824 |
| For: 198.18.2.4 –1 0 |
| Active: True |
+-------------------------------+
Figure 8e – Activate the Binding Message
The agent replies with an UpdateReply as F10.
F10: UpdateReply +-------------------------------+
| UpdateReply 31824 |
| For: 198.18.2.4 –1 2 |
| Active: True |
+-------------------------------+
Figure 8f – Reply to the Activation Message
After the proper OKs and ACKs, the NAT/FW is ready to accept/traverse
RTP traffic between the remote UA at 192.0.2.11:2346 and mapping it
to the local/private UA address/port number at 10.0.1.2:12000.
Similarly, the RTCP stream uses port 2347 on the public side and
12001 on the private side.
When the call is complete, the manager sees an acknowledged BYE SIP
message and sends a CloseRequest with the session ID to the agent to
delete the binding.
4.6 SAFENeT Block Caching Optimization
The performance of SAFENeT for applications like VoIP can optionally
be improved by pre-allocating NAT mappings. This allows the manager
to choose the public address and port number without contacting the
NAT. Thus, the SIP INVITE can complete with a single message between
the manager and the agent instead of the two described in Section 4.3
and illustrated in Section 4.2. To enable this optimization, the
manager needs to reserve a block of public port numbers (and
addresses if appropriate) from the NAT for future mappings.
The manager obtains a block of port numbers and session IDs from the
agent using a new message type, ReserveBlock. The manager can
specify the size of the block in the message body. The agent finds a
suitable block of addresses and returns a list with the public
address, port number, and session ID for each. The manager can then
Stott & Townsend Expires – December 31, 2005 [Page 26]
Internet Draft SAFENeT June 29, 2005
choose its own mappings from the list. It still needs to use the
UpdateRequest message to activate the mappings at the NAT. The
manager is contacted when the call completes. For example, if the
remote UA dos not answer or redirects the call to another endpoint
(i.e., call forwarding), the manager would disregard the original
binding and choose a new one when the UA sends the INVITE to the next
remote UA.
5. Discussion of Concerns
This section discusses some issues of concern for middlebox traversal
solutions. Because enterprises rely on the security of their FW, it
is reasonable to be concerned that changes to the FW may have adverse
effects on security. The issue of enterprises having multiple FWs is
covered as well as the issue of complex enterprise topology.
5.1 Don’t Mess with the Firewall
A valid question for any middlebox solution is why an administrator
who is responsible for the enterprise’s network security should trust
the SAFENeT solution enough to install it in his/her network.
Administrators should be concerned that the solution allows
applications to open *bad* holes through the FW. An example is a
solution that allows middlebox-aware viruses to open backdoors
through the FW to propagate or release sensitive data back through
the FW; obviously unacceptable. Similarly, a solution that allows a
remote host to control the access through the FW would likely result
in severe problems.
SAFENeT offers an architecture and protocol that allows restrictions
to be placed on how the system is provisioned that address the above
concerns. The SAFENeT architecture is proposed to allow only a small
set of authorized hosts (e.g., the local call servers hat are often
physically co-located with the agents) can access the middlebox.
This restriction can be enforced by the enterprise with various key
management policies, access control mechanisms, and social
engineering mechanisms. For example, some administrators may
statically configure the managers and agents by entering the other
element’s public key manually. Others may find a public key
infrastructure (PKI) system or symmetric key-based authentication
system to be more effective. Vendors and administrators are also
free to use host-based access control mechanisms to restrict the set
of managers that can connect using SCP.
The fundamental purpose of the solution is to allow VoIP traffic to
traverse the middlebox but not allow any additional connections. As
a point of reference, consider ALGs. These devices are generally
accepted as allowable at the enterprise edge for non-encrypted VoIP.
Stott & Townsend Expires – December 31, 2005 [Page 27]
Internet Draft SAFENeT June 29, 2005
A key differentiator for SAFENeT over ALG is where the VoIP logic for
parsing the VoIP message is processed. With ALGs, the logic must be
programmed into the middlebox and must be changed to correctly deal
with each newest VoIP message format and feature set. With SAFENeT,
it is handled by the call server which needs only a secure
communication channel to the middlebox.
It can be a debatable issue whether it is better to trust a middlebox
vendor’s VoIP processing code or a service provider’s VoIP code. FW
vendors might not be current with the latest VoIP protocol
developments but service providers might not have the most secure
software engineering practices. If one must be flawed in such a way
that the system is vulnerable to DoS attacks or exploitable code,
better that the failure be confined to the call server instead of
affecting the FW. If properly built, the agent failure mode when it
detects an improperly formed SCP message should failsafe by dropping
the connection to the agent. We are unaware of any ALG product that
would prevent such an attacking (or zombie) host from spoofing a call
session message to open a connection through the FW. This situation
cannot happen with SAFENeT because the SCP messages are
authenticated.
Compared to other proposed solutions, SAFENeT clearly provides a more
secure solution. SAFENeT does not open FW pinholes until both
endpoints have acknowledged the call. Most host-based solutions
(e.g., ICE and those based on NSIS solutions) open a pinhole before
signaling the remote endpoint, and will do so even in the case when
the endpoint refuses the call or diverts to voice mail. With other
host-based solutions, any internal host is capable of opening
pinholes through the FW whereas in SAFENeT only a call server can
establish a connection.
5.2 Multiple NATs
While SAFENeT is not optimized for multiple NATs (e.g., where traffic
passes through back-to-back NATs), it is supported. The SAFENeT
architecture can accommodate the case for multiple NATs such as
between department boundaries with multiple NAT instantiations, each
with its own manager. The manager needs to be aware of the
connecting NATs and the routing between them. The trick to making
this work is to issue multiple SCP commands to each involved NAT.
The first set of SCP messages are to reserve a port and address from
each NAT. The second set is to update each mapping with the ports
from the other NAT(s). Once all the bindings have been specified,
the manager can send to the endpoint the mapping from the NAT nearest
to the endpoint and then specify ports to neighboring NATs along the
path.
Stott & Townsend Expires – December 31, 2005 [Page 28]
Internet Draft SAFENeT June 29, 2005
If the manager uses the option of reserving multiple NAT port
bindings ahead of time, the process is much simpler. The manager
simply needs to choose ports for each involved NAT and send updates
to each NAT along the path as before.
5.3 Complex Enterprise Topologies
SAFENeT assumes that the manager can be configured with routing data
for the enterprise. In particular, the manager must know what
middleboxes are along the path from the local endpoint to the NAT/FW
at the enterprise edge. As the enterprise topology becomes more
complex, distributing managers throughout the network helps in
scaling the problem.
One difficult problem for any middlebox solution, that does not
restrict the data path, is the handling of multiple potential routes.
An underlying assumption is that the solution is able to predict the
data path. If the network permits per-packet load sharing over two
different paths with different (logically separate) NATs, it may not
be possible for NATs in the two different paths to assign the same
bindings because of previous assignments. Judicious choices in
network architecture design may be needed to alleviate problems like
these.
6. UNSAF Architectural Considerations
While the authors believe SAFENeT is not an UNSAF architecture as
described in RFC 3424 [UNSAF] and does not suffer the same
limitations, some discussion is warranted for completeness both on
how SAFENeT differs from the UNSAF architecture and on how SAFENeT
addresses the architectural considerations proscribed in Section 4 of
[UNSAF]. This discussion can also serve both to highlight the value
of SAFENeT in solving the NAT/FW traversal of VoIP traffic while
enabling a higher level of security in transactions requiring it and
to note the longer term use of NATs/FWs for corporate/enterprise
environments.
6.1 Addressing UNSAF Architectural Considerations in General
The discussion of UNSAF considerations should start with a listing
of what problems we are solving by the use of NATs/FWs at the edge
of enterprise networks. The rationale behind the solutions to those
problems are generally considered to be (a) relief from the
limitations of the IPv4 address space, (b) keeping the topology of
the enterprise network private from the outside world, (c) providing
an isolation of unwanted traffic from the outside, and (d) using
NAT/FW as the endpoint for secure tunnels in providing secure VPN
transport across the external domain.
Stott & Townsend Expires – December 31, 2005 [Page 29]
Internet Draft SAFENeT June 29, 2005
The UNSAF considerations are based on two premises. One is that
UNSAF solutions are short term workarounds and “MUST be considered
transitional in IETF proposals, and a better architectural solution
is being sought” [UNSAF]. For enterprises with the need for strict
security, the authors note that while IPv6 solves reason (a), it
does not hold a solution to either (b), (c), or (d). Therefore, the
SAFENeT proposal may be a longer term solution to the VoIP NAT/FW
traversal problem. Nonetheless, as noted in the proposal
description above, this solution is simple enough that it can likely
be migrated into a more general, long term solution if/when one
becomes available.
Secondly, the [UNSAF] document prescribes certain considerations
that are addressed below.
6.2 Addressing Specific UNSAF Architectural Considerations Per IAB
The IAB has mandated [UNSAF] that any protocols developed by which a
client attempts to determine its address in another realm on the
other side of a NAT through a collaborative protocol reflection
mechanism document a specific set of considerations.
From Section 4 of [UNSAF]:
“By distinguishing these approaches as short term fixes, the IAB
believes the following considerations must be explicitly addressed in
any proposal:
1. Precise definition of a specific, limited-scope problem that is
to be solved with the UNSAF proposal. A short term fix should
not be generalized to solve other problems. Such generalizations
lead to the the (sic) prolonged dependence on and usage of the
supposed short term fix -- meaning that it is no longer accurate
to call it "short term".
2. Description of an exit strategy/transition plan. The better
short term fixes are the ones that will naturally see less and
less use as the appropriate technology is deployed.
3. Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition.
4. Identify requirements for longer term, sound technical solutions;
contribute to the process of finding the right longer term
solution.
5. Discussion of the impact of the noted practical issues with
Stott & Townsend Expires – December 31, 2005 [Page 30]
Internet Draft SAFENeT June 29, 2005
existing deployed NATs and experience reports.”
For consideration (1), SAFENeT covers the case of VoIP (and similar
applications) traversing NATs/FWs in an enterprise environment.
Additionally, it covers the further cases in which encryption is used
for data confidentiality and digital signatures used for data
integrity.
For (2), as in other cases, the problem for some may be self-healing
(by use of IPv6) for some of its attributes but others may be long
term issues (isolation of data from the public network, isolation of
the enterprise topology from the public network) leaving SAFENeT as a
long term solution. Even the long term SAFENeT solution can likely
be merged into more comprehensive solutions as will be determined in
the marketplace, e.g, as might be developed in NSIS.
For (3), neither discovery nor security is an issue as it is with
STUN because the call server is a defined part of the enterprise
network, i.e., inside the NAT/FW. Every solution that works with
applications and addresses/ports uses data at multiple network
layers and thereby creates debugging issues – seems unavoidable for
this type of protocol.
On the long term issue (4) and referencing the considerations in the
Internet-Draft on STUN:
- the bindings for SAFENeT are explicit,
- although the control is not “in-band”, the enterprise topology is
known and the call server is provisioned only with appropriate
addresses as described in section 4.3, thereby relieving the
problem,
- limiting control is not an issue since the call server resides
within the private enterprise network, and
- SAFENeT is simple.
For (5), no assumptions have been made about NATs/FWs. Assigning the
ports does not seem to be a problem. Likewise for timeouts; SCP is
assumed to run over a protocol like TCP (e.g., TLS over TCP) that
provides reliable delivery; the endpoint will eventually disconnect
if the signaling cannot complete.
6.3 IAB Consideration Summary
SAFENeT has less of an issue with the IAB considerations than other
schemes. Having the call server inside the NAT/FW allows the
enterprise to manage its own topology and, in fact, opens the door
to allowing to better security operation. This architecture, as
contrasted with others requiring a box outside the FW and as
contrasted with the residential case assumed to have the call server
Stott & Townsend Expires – December 31, 2005 [Page 31]
Internet Draft SAFENeT June 29, 2005
outside the FW, alleviates the majority of the IAB considerations
for NAT traversal.
7. Security Considerations
As in STUN, attack possibility discussions can be limited to denial
of service (DoS), masquerading, and eavesdropping attacks. These
descriptions do not include attacks from within the enterprise from
trusted sources; untrusted ones are summarily fired.
Like all Internet applications, it is possible to flood the agent
with spoofed packet (e.g., SYN packets for TCP). The underlying
transmission protocol provides authentication.
For a distributed DoS (DDoS) attack in which a remote UA with a
legitimate return address distributes that address to other evil UAs
all of whom call try to call in, the NAT/FW should reject all of
those extra calls because it will not have a mapping with the
outgoing call. If there was no original outgoing call, the attack is
no different from any DDoS attack.
Attempts to trick the local/private UAs by providing them with fake
mapped addresses won’t work because only the call server can supply
addresses via its interaction with the NAT/FW in setting up call
bindings. Other varieties of attacks using fake addresses are
thwarted similarly.
Eavesdropping attacks are carried out using a faked address to the
attacker who then passes the traffic on to the original recipient.
As above SAFENeT precludes a faked address because of the isolation
of the call server and its local/private connection with the NAT/FW
in setting up the bindings.
Other attacks rely on one primitive, namely injecting a response with
a faked address. Not being able to do this in an SAFENeT environment
precludes virus and Trojan horse attacks. Not running SAFENeT on
general-purpose computers and using best-practices to harden the
platforms is the best approach to attacks of these sorts.
Public-key authentication provides a mechanism to verify each host's
identity (including the DNS mapping between the host and it address).
Public-key authentication also prevent Man-in-the-Middle attacks
because each host authenticates the other using its respective
private key, which the potential MitM cannot know. After exchanging
session keys between the authenticated hosts, the session keys are
used to encrypt each message and to include a data integrity check.
These two mechanisms provide confidentiality, integrity and
authentication.
Stott & Townsend Expires – December 31, 2005 [Page 32]
Internet Draft SAFENeT June 29, 2005
8. IANA Considerations
A standard port over which to run SCP is TBD.
9. References
9.1 Normative References
None
9.2 Informative References
[MIDBOX] RFC 3234, B. Carpenter and S. Brim, “Middleboxes: Taxonomy
and Issues”.
[RTP] RFC 3550, H. Schulzrinne, S. Casner, R. Frederick, V.
Jacobson, “RTP: A Transport Protocol for Real-Time Applications”.
[X805] ITU-T Rec. X.805, “Security architecture for systems
providing end-to-end communications”.
[NAT-TRAV] J. Rosenberg, draft-iab-nat-traversal-considerations-00,
“Considerations for Selection of Techniques for NAT Traversal”.
[ICE] J. Rosenberg, draft-ietf-mmusic-ice-04, “Interactive
Connectivity Establishment (ICE): A Methodology for Network Address
Translator (NAT) Traversal for Multimedia Session Establishment
Protocols”.
[STUN] RFC 3489, J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy.
“Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)”.
[TURN] J. Rosenberg, R. Mahy, and C. Huitema, draft-rosenberg-
midcom-turn-07, “Traversal Using Relay NAT (TURN)”.
[expired] J. Peterson and J.Rosenberg, draft-peterson-rosenberg-avt-
rtp-ssrc-demux-00, “A Multiplexing Mechanism for Real-Time Protocol
(RTP)”, July 2004.
[BLTJ] P. Sijben, W. van Willigenburg, M. de Boer, and S. van der
Gaast, “Middleboxes: Controllable Media Firewalls,” Bell Labs
Technical Journal, vol. 7, pp.141-157, August 2002.
[H248} ITU-T Rec. H.248, “Gateway control protocol”.
Stott & Townsend Expires – December 31, 2005 [Page 33]
Internet Draft SAFENeT June 29, 2005
[NSIS-FW] R. Hancock, G. Karagiannis, J. Loughney, and S. van den
Bosch, draft-ietf-nsis-fw-07, “Next Steps in Signaling: Framework”.
[NSLP] M. Stiemerling, H. Tschofenig, C. Aoun, draft-ietf-nsis-nslp-
natfw-05, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP)”,
(Status is ‘AD is watching’).
[SIP] RFC 3261, J. Rosenberg, H. Schulzrinne, G. Camarillo, A.
Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, “SIP:
Session Initiation Protocol”.
[RFC3303] RFC 3303, P. Srisuresh et al, “Middlebox Communication
Architecture and Framework”.
[TLS] RFC 2246, T. Dierks, C. Allen, “The TLS Protocol Version
1.0”.
[usecase] V. Hilt, draft-hilt-sipping-policy-usecases-00, “Use Cases
for Session-Specific Session Initiation Protocol (SIP) Session
Policies”.
[UNSAF] RFC 3424, L. Daigle, Ed., “IAB Considerations for Unilateral
Self-Address Fixing (UNSAF), November 2002.
Author's Addresses
David Stott Phone: +1 973 386 3898
Room 15A-149 Email: stott@lucent.com
Lucent Technologies, Bell Labs URI:
67 Whippany Road
Whippany, NJ 07981
USA
Rick Townsend Phone: +1 732 949 8667
Room 4C-605A Email: rltownsend@lucent.com
Lucent Technologies, Bell Labs URI:
101 Crawfords Corner Road
Holmdel, NJ 07733
USA
Comments are solicited and should be addressed to the working group's
mailing list at ietf-behave@list.sipfoundry.org and/or to the
authors.
Stott & Townsend Expires – December 31, 2005 [Page 34]
Internet Draft SAFENeT June 29, 2005
Full Copyright Statement
"Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Status of This Document
"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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html"
This Internet-Draft will expire on December 31, 2005.
Stott & Townsend Expires – December 31, 2005 [Page 35]
