NSIS Working Group M. Stiemerling
Internet-Draft NEC
Expires: April 17, 2004 H. Tschofenig
Siemens
M. Martin
NEC
C. Aoun
Nortel Networks
October 18, 2003
A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
draft-ietf-nsis-nslp-natfw-00
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.
This Internet-Draft will expire on April 17, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This draft describes scenarios, problems and solutions for
path-coupled Network Address Translator and Firewall signaling.
This is one of the two NSIS Signaling Layer Protocols (NSLPs) the
working group will address during its work.
Stiemerling, et al. Expires April 17, 2004 [Page 1]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . 5
3. Framework and Scenarios . . . . . . . . . . . . . . . . . 7
3.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 What problem should be solved? . . . . . . . . . . . . . . 7
3.3 Basic NSIS Usage for NAT/FW traversal . . . . . . . . . . 8
3.4 Scenarios for Protocol Functionality . . . . . . . . . . . 9
3.4.1 Firewall traversal . . . . . . . . . . . . . . . . . . . . 9
3.4.2 NAT with two private networks . . . . . . . . . . . . . . 10
3.4.3 NAT with private network on sender side . . . . . . . . . 11
3.4.4 NAT with private network on receiver side . . . . . . . . 11
3.4.5 Both end hosts in same private network behind NATs . . . . 12
3.4.5.1 Both end hosts in same private network behind same NAT . . 13
3.4.6 IPv4/v6 NAT with two private networks . . . . . . . . . . 13
3.5 Trust Relationship and Authorization . . . . . . . . . . . 14
3.5.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . . . 14
3.5.2 Intra-Domain Trust Relationship . . . . . . . . . . . . . 15
3.5.3 End-to-Middle Trust Relationship . . . . . . . . . . . . . 16
4. Problems and Challenges . . . . . . . . . . . . . . . . . 18
4.1 Missing Network-to-Network Trust Relationship . . . . . . 18
4.2 End-to-end significance . . . . . . . . . . . . . . . . . 19
4.3 Relationship with routing . . . . . . . . . . . . . . . . 19
4.4 Dynamic state installation and maintenance . . . . . . . . 20
4.5 Affected Parts of the Network . . . . . . . . . . . . . . 20
4.6 NSIS backward compatibility with NSIS unaware NAT and
Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 20
4.7 Authentication and Authorization . . . . . . . . . . . . . 21
4.8 Directional Properties . . . . . . . . . . . . . . . . . . 21
4.9 Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 22
4.10 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 22
4.11 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 23
4.12 Route changes . . . . . . . . . . . . . . . . . . . . . . 23
4.13 Combining Middlebox and QoS signaling . . . . . . . . . . 23
4.14 Difference between sender- and receiver-initiated
signaling . . . . . . . . . . . . . . . . . . . . . . . . 24
4.15 Inability to know the scenario . . . . . . . . . . . . . . 24
5. NSIS NAT Handling Solution . . . . . . . . . . . . . . . . 25
5.1 Problem Description . . . . . . . . . . . . . . . . . . . 25
5.2 Solution Overview . . . . . . . . . . . . . . . . . . . . 28
5.2.1 Destination IP address Selection . . . . . . . . . . . . . 30
6. Protocol Description . . . . . . . . . . . . . . . . . . . 32
Stiemerling, et al. Expires April 17, 2004 [Page 2]
Internet-Draft A NAT/FW NSIS NSLP October 2003
6.1 Basic protocol overview . . . . . . . . . . . . . . . . . 32
6.2 Message format and types . . . . . . . . . . . . . . . . . 32
6.3 Message flow . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Middle box configuration . . . . . . . . . . . . . . . . . 36
6.5 Message handling . . . . . . . . . . . . . . . . . . . . . 37
6.5.1 Detailed behaviour . . . . . . . . . . . . . . . . . . . . 38
6.5.1.1 Reserve external address message . . . . . . . . . . . . . 38
6.5.1.2 Return external address message . . . . . . . . . . . . . 39
6.5.1.3 Create message . . . . . . . . . . . . . . . . . . . . . . 39
6.5.1.4 Delete session message . . . . . . . . . . . . . . . . . . 41
6.5.1.5 Prolong session message . . . . . . . . . . . . . . . . . 41
6.5.1.6 Path Succeded message . . . . . . . . . . . . . . . . . . 41
7. Solution examples . . . . . . . . . . . . . . . . . . . . 43
7.1 Firewall traversal . . . . . . . . . . . . . . . . . . . . 43
7.2 NAT with private network on sender side . . . . . . . . . 43
7.3 NAT with private network on receiver side . . . . . . . . 45
7.4 Both end hosts are in same private network behind NATs . . 49
7.5 IPv4/v6 NAT with two private networks . . . . . . . . . . 52
7.6 Full example for NAT/FW with two private networks . . . . 52
8. NSIS NAT and Firewall transitions issues . . . . . . . . . 59
9. Security Considerations . . . . . . . . . . . . . . . . . 60
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 62
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . 63
Normative References . . . . . . . . . . . . . . . . . . . 64
Informative References . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 66
A. Interworking of SIP with NSIS NATFW NSLP . . . . . . . . . 68
A.1 The Session Initiation Protocol . . . . . . . . . . . . . 68
A.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 73
B. Ad-Hoc networks . . . . . . . . . . . . . . . . . . . . . 74
C. Interworking of Security Mechanisms and NSIS NATFW NSLP . 75
D. Solution approaches in case of missing authorization . . . 76
D.1 Solution Approach: Local authorization from both end
points . . . . . . . . . . . . . . . . . . . . . . . . . . 76
D.2 Solution Approach: Access Network-Only Signaling . . . . . 77
D.3 Solution Approach: Authorization Tokens . . . . . . . . . 77
Stiemerling, et al. Expires April 17, 2004 [Page 3]
Internet-Draft A NAT/FW NSIS NSLP October 2003
E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 80
Intellectual Property and Copyright Statements . . . . . . 81
Stiemerling, et al. Expires April 17, 2004 [Page 4]
Internet-Draft A NAT/FW NSIS NSLP October 2003
1. Introduction
Even though the NSIS WG (Next Steps in Signaling) has QoS signaling
as a primary application, other types of applications should be
possible.
In this draft, we address the scenario, framework, problems, and
issues when signaling Network Address Translators (NAT) and/or
Firewalls to allow packet traversal.
One of the requirements in NSIS [1] is that the NTLP signaling
protocol must be independent of the service requested. In some
cases the NSIS protocol suite could be used to request end-to-end or
edge-to-edge QoS from IP networks; in other cases the service might
be allow packet traversal from one host to the other through all the
NATs and firewalls deployed on the data path.
See also [17] and [18] for proposals to use RSVP or CASP for NAT and
Firewall traversal.
Stiemerling, et al. Expires April 17, 2004 [Page 5]
Internet-Draft A NAT/FW NSIS NSLP October 2003
2. Terminology and Abbreviations
This document uses terms defined in [22]. In addition the following
terms are used:
o NSIS NAT Forwarding State: The term "NSIS NAT Forwarding State" in
this context refers to a state used to forward the NSIS signaling
message beyond the targeted destination address; that state is
typically used when the NSIS Responder address is not known
o Sender-/Receiver Initiated Signaling
Sender-initiated: NAT bindings and firewall rules are created
immediately when the "path" message hits the NSIS nodes. With
"path" message we refer to the signaling message traveling from
the data sender towards the data receiver.
Receiver-initiated: NAT bindings and firewall rules are created
when the "resv" message returns from the other end. With
"resv" message we refer to a signaling message on the reverse
path, this means from the receiver to the sender (i.e.
backwards routed).
Note that these definitions have nothing to do with number of
roundtrips, who performs authorization etc.
o Firewalls vs. Security Gateway: As discussed in Section 3.1
different types of firewalls exist. This document focuses on
firewalls, which perform packet filtering, and possibly
application level filtering and does not address IPsec based
security gateways.
o NSIS Initiator (NI): the signaling entity which makes the resource
request, usually as a result of user application request.
o NSIS Responder (NR): the signaling entity that acts as the
endpoint for the signaling and can optionally interact with
applications as well.
o NSIS Forwarder (NF): the signaling entity between an NI and NR
which propagates NSIS signaling further through the network.
o Receiver (DR or R): the node in the network which is receiving the
data packets in a flow.
o Sender (DS or S): the node in the network which is sending the
data packets in a flow.
Stiemerling, et al. Expires April 17, 2004 [Page 6]
Internet-Draft A NAT/FW NSIS NSLP October 2003
o NATFW NSLP session: an artifact that groups the installed states
for a given data flow.
o Middlebox: from [21]: "A middlebox is defined as any intermediate
device performing functions other than the normal, standard
functions of an IP router on the datagram path between a source
host and a destination host". The term middlebox in context of
this document and in NSIS refers to firewalls and NATs only.
Other types of middlebox are currently outside the scope.
Stiemerling, et al. Expires April 17, 2004 [Page 7]
Internet-Draft A NAT/FW NSIS NSLP October 2003
3. Framework and Scenarios
3.1 Scope
The term firewall and middlebox in general raises different
expectations about the functionality provided by such a device.
Different groups have worked on the problem of securing access to a
network by using different procedures and protocols. From an
abstract point of view two different mechanisms for restricting
access to a network can be differentiated:
o Packet Filters
o Cryptographically protected data traffic
Within this document we assume that packet filters are installed at
devices along the path. These packet filters may consist of a 5
tuple (src/dst ip address, transport protocol, src/dst port). Some
devices entitled as firewalls only accept traffic after cryptographic
verification (i.e. IPsec protected data traffic). Particularly for
network access scenarios either link layer or network layer data
protection is common. Hence we do not address these types of devices
(referred as security gateways) since per-flow signaling is rather
uncommon in this environment. For a discussion of network access
authentication and associated scenarios the reader is referred to the
PANA working group (see [16]).
In mobility scenarios an often experienced problem is the traversal
of a security gateway at the edge of the corporate network. Network
administrators often rely on the policy that only authenticated data
traffic is allowed to enter the network. A problem statement for the
traversal of these security gateways in the context of Mobile IP can
be found at [15]).
3.2 What problem should be solved?
The goal of NSIS FW/NAT signaling therefore focuses on packet filter
installation combined with associated actions to be enforced on
packets matching the filter expression. In the case of NATs and
Firewalls the associated actions are packet forwarding and address/
port translation in packet headers.
Discovering security gateways, which was also mentioned as an
application for NSIS signaling, for the purpose of executing an IKE
to create an IPsec SA, is already solved without requiring NSIS.
Installing packet filters provides some security but has some
weaknesses, which heavily depend on the type of packet filter
Stiemerling, et al. Expires April 17, 2004 [Page 8]
Internet-Draft A NAT/FW NSIS NSLP October 2003
installed. A packet filter cannot prevent an adversary to inject
traffic (due to the IP spoofing capabilities). This type of attack
might not be particular helpful if the packet filter is a standard 5
tuple which is very restrictive. If packet filter installation,
however, allows specifying a rule, which restricts only the source IP
address, then IP spoofing allows transmitting traffic to an arbitrary
address. NSIS aims to provide path-coupled signaling and therefore
an adversary is somewhat restricted in the location from which
attacks can be performed. Some trust is therefore assumed from nodes
and networks along the path.
3.3 Basic NSIS Usage for NAT/FW traversal
The basic high-level picture of NSIS usage is that of the endhosts
signaling to establish packet filters and NAT bindings on a data
path, which allows the said data to travel from the endhost to the
endpoint unobstructed.
Therefore it is necessary that each firewall and each NAT involved in
the signaling communication runs an NSIS daemon. There might be
several NATs and FWs in various possible combinations on a path
between two hosts. The reader is referred to Section 3.4 where
different scenarios are presented.
Stiemerling, et al. Expires April 17, 2004 [Page 9]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Application Application Server (0, 1, or more) Application
+----+ +----+ +----+
| +------------------------+ +------------------------+ |
+-+--+ +----+ +-+--+
| |
| NSIS Agents |
+-+--+ +----+ +-----+ +-+--+
| +--------+ +----------------------------+ +-----+ |
+-+--+ +-+--+ +--+--+ +-+--+
| | ------ | |
| | //// \\\\\ | |
+-+--+ +-+--+ |/ | +-+--+ +-+--+
| | | | | Internet | | | | |
| +--------+ +-----+ +----+ +-----+ |
+----+ +----+ |\ | +----+ +----+
\\\\ /////
sender NAT/FW (1+) ------ NATFW (1+) receiver
Figure 1: Generic View on NSIS in a NAT / Firewall case
3.4 Scenarios for Protocol Functionality
This section introduces several scenarios for middleboxes in the
Internet. These middleboxes are firewalls or different flavours of
NATs [5], like NAPT. Combinations of Firewalls and NATs in the same
device are possible as well.
Each section introduces a different scenario for a different set of
middleboxes and their ordering within the topology.
3.4.1 Firewall traversal
The following scenario shows two end hosts behind a firewall but
connected via the public Internet. The application can somehow
trigger firewall traversal (e.g. via an API call) at the NSIS agent
at the local host. The NSIS agent then signals this request to the
next NSIS aware node and therefore to the receiver. Each firewall in
the middle must provide traversal service in order to permit the NSIS
message to reach the other end host.
The difference between this scenario and the following is that
firewalls are on the path, but no NATs. This has specific
implication concerning the used destination address for path-coupled
signaling message sent by the NSIS Initiator to an NR hosted behind a
NAT.
Stiemerling, et al. Expires April 17, 2004 [Page 10]
Internet-Draft A NAT/FW NSIS NSLP October 2003
+----+ //----\\ +----+
S -----| FW |---| |------| FW |--- R
+----+ \\----// +----+
private public private
FW: Firewall
S: Data Sender
R: Data Receiver
Figure 2: Firewall Traversal Scenario
3.4.2 NAT with two private networks
This scenario deals with NATs on both ends of the network.
Therefore, each application instance is behind a NAT and is connected
to the public Internet (see Figure 3 ).
The case where more than one MB on each side ("only" two are shown in
the figure) is present must be taken into account. This aspect
introduces more topology problems.
+----+ +----+ //----\\ +----+ +----+
S --| MB |-----| MB |---| |---| MB |-----| MB |--- R
+----+ +----+ \\----// +----+ +----+
private public private
MB: Middlebox
S: Data Sender
R: Data Receiver
Figure 3: NAT with two private networks Scenario
Data traffic from the sender to the receiver has to traverse all four
middleboxes on the path and all four middleboxes must be configured
properly to allow subsequent data packets to flow. The sender has to
know the IP address of the receiver in advance, i.e. before any NSIS
message can be sent. Or more general the NSIS Initiator must know
the IP addresses of the NSIS Responder, otherwise he cannot send a
single NSIS signaling message towards the responder. Note that this
IP address is not the private IP address of the responder. Instead a
NAT binding (including a public IP address) has to be obtained from
Stiemerling, et al. Expires April 17, 2004 [Page 11]
Internet-Draft A NAT/FW NSIS NSLP October 2003
the NAT which subsequently allows packets hitting the NAT to be
forwarded to the receiver within the private address realm. This in
general requires further support from an application layer protocol
for the purpose of discovering and exchanging information. The
receiver might have a number of ways to learn its public IP address
and port number and might need to signal this information to the
sender using the application level signaling protocol.
3.4.3 NAT with private network on sender side
This scenario shows an application instance at the sending node which
is behind one ore more FW/NATs. The receiver is located in the
public internet.
+----+ +----+ //----\\
S --| MB |-----| MB |---| |--- R
+----+ +----+ \\----//
private public
MB: Middlebox
S: Data Sender
R: Data Receiver
Figure 4: NAT with private network on sender scenario
The traffic from the sender to the receiver has to traverse only
middleboxes on the sender's side. The receiver has a public IP
address and therefore the procedure is simple. The sender sends its
signaling message directly to the receiver whereby it is intercepted
by the middleboxes along the path.
Note that the data sender does not necessarily know whether the
receiver is behind a NAT or not, hence, it is the receiving side that
has to detect the whether it is behind a NAT or not. As described in
Section 5 NSIS can also provide help for this procedure.
3.4.4 NAT with private network on receiver side
The application instance receiving data is behind one or more NATs.
Stiemerling, et al. Expires April 17, 2004 [Page 12]
Internet-Draft A NAT/FW NSIS NSLP October 2003
//----\\ +----+ +----+
S ---| |---| MB |-----| MB |--- R
\\----// +----+ +----+
public private
MB: Middlebox
S: Data Sender
R: Data Receiver
Figure 5: NAT with private network on receiver Scenario
First, the sender must determine the public IP address of the
receiver.
One possibility is that an application level protocol is used. In
this case, the receiver must first find out its public IP addresses
at the middlebox on its side. This information about IP address and
port numbers could be signalled somehow to the actual sender directly
or indirectly via a third party. In the scenario, this means the
receiver has to determine its public IP address (NAT binding) and
register this address with the third party.
The sender can start NSIS signaling after he has received information
about the receiver's address and port number.
Note: The solution design will determine where to discontinue
forwarding the signaling messages.
3.4.5 Both end hosts in same private network behind NATs
This is a special case, where the main problem is to detect that both
nodes are within the same network behind a NAT. This scenario
primarily addresses performance aspects.
Sender and receiver are both within a private address realm and
potentially have overlapped addresses. Figure 6 shows the ordering
of NATs. This is a common configuration in several networks,
particularly after the merging of companies that have overlapped
addresses.
Stiemerling, et al. Expires April 17, 2004 [Page 13]
Internet-Draft A NAT/FW NSIS NSLP October 2003
public
+----+ +----+ //----\\
S --| MB |--+--| MB |---| |
+----+ | +----+ \\----//
|
| +----+
+--| MB |------------ R
+----+
private
MB: Middlebox
S: Data Sender
R: Data Receiver
Figure 6: NAT to public, receiver in same private network Scenario
The middleboxes are twice-NATs, i.e. they map the IP addresses and
port numbers on both sides, private and public interface.
From a protocol point of view, this means that the protocol must be
robust enough to at least not break with this scenario.
In the worst case, both sender and receiver obtain a public IP
address at the NAT and the communication path is not optimal anymore.
3.4.5.1 Both end hosts in same private network behind same NAT
A slight variation of the previous scenario consists in having both
the DS and the DR behind the same NAT. In case the data sender and
data receiver can not communicate which address is the most suitable
among the several available (local scoped or globally scoped)
addresses to be used for the NSIS messages, the protocol should be
robust enough to handle the worst case, where the messages are sent
through the NAT.
3.4.6 IPv4/v6 NAT with two private networks
This scenario combines the usage case mentioned in Section 3.4.2 with
the IPv4 to IPv6 transition scenario, i.e. using Network Address and
Protocol Translators (NAT-PT).
The difference to the other scenarios lies in the use of IPv6 - IPv4
address translation, which happens in both directions. Additionally,
the base NTLP must take care of this case for its own functionality
of forwarding messages between NSIS peers.
Stiemerling, et al. Expires April 17, 2004 [Page 14]
Internet-Draft A NAT/FW NSIS NSLP October 2003
+----+ +----+ //----\\ +----+ //----\\ +----+ +----+
S --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- R
+----+ +----+ \\----// +----+ \\----// +----+ +----+
private public public private
IPv4 IPv6
MB: Middlebox
S: Data Sender
R: Data Receiver
Figure 7: IPv4/v6 NAT with two private networks
3.5 Trust Relationship and Authorization
Trust relationships and authorization are very important for the
protocol machinery. Trust and authorization closely related to each
other in the sense that a certain degree of trust is required to
authorize a particular action. If the action is "create/delete
packet filters" then authorization is very important due to the
nature of a firewall.
It is not particularly surprising that differences exist between
authorization in a QoS signaling environment and firewall signaling.
As elaborated in [13] the establishment of a financial relationship
is very important for QoS, signaling whereas for firewall signaling
is not directly of interest.
In the subsequent sections different trust relationships will be
described which appear in firewall signaling environments.
Peer-to-peer trust relationships are those, which are used in QoS
signaling today and seem to be the simplest. However, there are
reasons to believe that this is not the only type of trust
relationship found in today's networks.
3.5.1 Peer-to-Peer Trust Relationship
Starting with the simplest scenario it is assumed that neighboring
nodes trust each other. The required security association to
authenticate and to protect a signaling message is either available
(manual configuration) or dynamically established with the help of an
authentication and key exchange protocol. If nodes are located
closely together it is assumed that security association
establishment is easier than establishing it between far distant
node. It is, however, difficult to describe this relationship
generally due to the different usage scenarios and environments.
Stiemerling, et al. Expires April 17, 2004 [Page 15]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Authorization heavily depends on the participating entities but for
this scenario it is assumed that neighboring entities trust each
other (at least for the purpose of packet filter creation and
deletion). Note that Figure 8 does not illustrate the trust
relationship between the end host and the access network, which is
dynamically established as part of the network access authentication
procedure as stated in Section 1.
+------------------------+ +-------------------------+
| | | |
| Network A | | Network B |
| | | |
| +---------+ +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | Trust | box 2 | | |
| | +---------+ Relationship +---------+ | |
| | | | | |
| | | | | |
| | | | | |
| | Trust | | Trust | |
| | Relationship | | Relationship | |
| | | | | |
| | | | | |
| | | | | |
| +--+---+ | | +--+---+ |
| | Host | | | | Host | |
| | A | | | | B | |
| +------+ | | +------+ |
+------------------------+ +-------------------------+
Figure 8: Peer-to-Peer Trust Relationship
3.5.2 Intra-Domain Trust Relationship
In larger corporations often more than one firewall is used to
protect different departments. In many cases the entire enterprise
is controlled by a security department, which gives instructions to
the department administrators. In such a scenario a peer-to-peer
trust-relationship might be prevalent. Sometimes however it might be
necessary to preserve authentication and authorization information
within the network. As a possible solution a centralized approach
could be used whereby an interaction between the individual
middleboxes and a central entity (for example a policy decision point
- PDP) takes place. As an alternative individual firewalls could
exchange the authorization decision to another firewalls within the
Stiemerling, et al. Expires April 17, 2004 [Page 16]
Internet-Draft A NAT/FW NSIS NSLP October 2003
same trust domain. Individual middleboxes within an administrative
domain should exploit their trust relationship instead of requesting
authentication and authorization of the signaling initiator again and
again. Thereby complex protocol interaction is avoided. This
provides both a performance improvement without a security
disadvantage since a single administrative domain can be seen as a
single entity. Figure 9 illustrates a network structure which uses a
centralized entity.
+-----------------------------------------------------------+
| |
| Network A |
| |
| |
| +---------+ +---------+
| +----///--------+ Middle- +------///------++ Middle- +---
| | | box 2 | | box 2 |
| | +----+----+ +----+----+
| | | | |
| +----+----+ | | |
| | Middle- +--------+ +---------+ | |
| | box 1 | | | | |
| +----+----+ | | | |
| | | | | |
| - | | | |
| - | +----+-----+ | |
| | | | Policy | | |
| +--+---+ +-----------+ Decision +----------+ |
| | Host | | Point | |
| | A | +----------+ |
| +------+ |
+-----------------------------------------------------------+
Figure 9: Intra-domain Trust Relationship
3.5.3 End-to-Middle Trust Relationship
In some scenarios a simple peer-to-peer trust relationship between
participating nodes is not sufficient. Network B might require
additional authorization of the signaling message initiator. If
authentication and authorization information is not attached to the
initial signaling message then the signaling message arriving at
Middlebox 2 would cause an error message to be created, which
indicates the additional authorization requirement. In many cases
the signaling message initiator is already aware of the additionally
Stiemerling, et al. Expires April 17, 2004 [Page 17]
Internet-Draft A NAT/FW NSIS NSLP October 2003
required authorization before the signaling message exchange is
executed. Replay protection is a requirement for authentication to
the non-neighboring firewall which might be difficult to accomplish
without adding additional roundtrips to the signaling protocol (e.g.
by adding a challenge/response type of message exchange).
Figure 10 shows the slightly more complex trust relationships in this
scenario.
+----------------------+ +--------------------------+
| | | |
| Network A | | Network B |
| | | |
| | Trust | |
| | Relationship | |
| +---------+ +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | +-------+ box 2 | | |
| | +---------+ | +---------+ | |
| | | | | | |
| |Trust | | | | |
| |Relationship | | | | |
| | | | | Trust | |
| | | | | Relationship| |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| +--+---+ | | | +--+---+ |
| | Host +----///----+------+ | | Host | |
| | A | |Trust | | B | |
| +------+ |Relationship | +------+ |
+----------------------+ +--------------------------+
Figure 10: End-to-Middle Trust Relationship
Stiemerling, et al. Expires April 17, 2004 [Page 18]
Internet-Draft A NAT/FW NSIS NSLP October 2003
4. Problems and Challenges
This section describes a number of problems which have to be
addressed for NSIS NAT/Firewall. These are also of relevance for
other NSLP protocols.
4.1 Missing Network-to-Network Trust Relationship
Peer-to-peer trust relationship, as shown in Figure 8, is a very
convenient assumption that allows simplified signaling message
processing. However, it might not always be applicable, especially
between two arbitrary access networks (over a core network where
signaling messages are not interpreted) does possibly not exist
because of the large number of networks and the unwillingness of
administrators to have other network operators to create holes in
their firewalls without proper authorization. Hence in the following
scenario we assume a somewhat different message processing and show
three possible approaches to tackle the problem. None of these three
approaches is without drawbacks or constraining assumptions.
Stiemerling, et al. Expires April 17, 2004 [Page 19]
Internet-Draft A NAT/FW NSIS NSLP October 2003
+----------------------+ +--------------------------+
| | | |
| Network A | | Network B |
| | | |
| +---------+ Missing +---------+ |
| +-///-+ Middle- | Trust | Middle- +-///-+ |
| | | box 1 | Relation- | box 2 | | |
| | +---------+ ship +---------+ | |
| | | or | | |
| | | Authorization| | |
| | | | | |
| | Trust | | Trust | |
| | Relationship | | Relationship | |
| | | | | |
| | | | | |
| | | | | |
| +--+---+ | | +--+---+ |
| | Host | | | | Host | |
| | A | | | | B | |
| +------+ | | +------+ |
+----------------------+ +--------------------------+
Figure 11: Missing Network-to-Network Trust Relationship
Figure 11 illustrates a problem whereby an external node is not
allowed to manipulate (create, delete, query, etc.) packet filters at
a firewall. Opening pinholes is only allowed for internal nodes or
with a certain authorization permission. Hence the solution
alternatives in Section 5 focus on establishing the necessary trust
with cooperation of internal nodes.
4.2 End-to-end significance
In the case of NAT/firewalls traversal, the NSIS signaling messages
need to be sent all they way from the DS and DR or viceversa. This
is so because a middle box does not know wether the remaining path to
the destination is clear of pottentially obstructing middleboxes or
not.
4.3 Relationship with routing
The data path is following the "normal" routes. The NAT/FW devices
along the data path are those providing the service. In this case
the service is something like "open a pinhole" or even more general
"allow for connectivity between two communication partners". The
benefit of using path-coupled signaling is that the NSIS NATFW NSLP
does not need to determine what middleboxes or in what order the data
Stiemerling, et al. Expires April 17, 2004 [Page 20]
Internet-Draft A NAT/FW NSIS NSLP October 2003
flow will go through.
Creating NAT bindings modifies routing of data packets between end
points. This is unlike other NSIS NSLPs, which do not interfere with
routing - instead they only follow the path of the data packets.
4.4 Dynamic state installation and maintenance
For NAT/Firewall traversal, the lifetime of a NAT binding or a packet
filter must be determined is often mantained through periodic
refresh.For short-lived flows, having unpredictable filtersi,
signaling for pinholes and NAT bindings is preferable as opposed to
statically configured NAT bindings and pinholes requested for long
duration in time. The capability to specify a lifetime for a NAT
binding provides some advantages to what exists today where unknown
NAT binding lifetimes can lead to unexpected protocol actions.
For static state other mechanisms than an NSIS signaling protocol
might be preferable; such mechanisms would include a management
protocols such as SNMP or CLI.
4.5 Affected Parts of the Network
NATs and Firewalls tend to be located at the edge of the network,
whereby other signaling applications affect all nodes along the path.
One typical example is QoS signaling where all networks along the
path must provide QoS in order to achieve true end-to-end QoS. In
the NAT/Firewall case, only some of the domains/nodes are affected
(typically access networks), whereas most parts of the networks and
nodes are unaffected (e.g. the core network).
This fact raises some questions. Should an NSIS NTLP node intercept
every signaling message independently of the upper layer signaling
application or should it be possible to make the discovery procedure
more intelligent to skip nodes. These questions are also related to
the question whether NSIS NAT/FW should be combined with other NSIS
signaling applications.
4.6 NSIS backward compatibility with NSIS unaware NAT and Firewalls
Backward compatibility is key for NSIS deployments, as such the NSIS
protocol suite should be sufficiently robust to allow traversal of
none NSIS aware routers (Qos gates, Firewalls, NATs, etc )
NSIS NATFW NSLP's backward compatibility issues is different than the
NSIS QoS NSLP backward compatibility issues, where an NSIS unaware
Qos gate will simply forward the Qos NSLP message. An NSIS unaware
firewall rejects NSIS messages, since firewalls typically implement
Stiemerling, et al. Expires April 17, 2004 [Page 21]
Internet-Draft A NAT/FW NSIS NSLP October 2003
the policy "default = deny".
The NSIS backward compatibility support on none NSIS aware firewall
would typically consist of configuring a static policy rule that
allows the forwarding of the NSIS protocol messages (either protocol
type if raw transport mode is used or transport port number in case a
transport protocol is used).
For NATs backward compatibility is more problematic since signaling
messages are forwarded (at least in one direction), but with a
changed IP address and changed port numbers. The content of the NSIS
signaling message is, however, unchanged. This can lead to
unexpected results, both due to embedded unchanged local scoped
addresses and none NSIS aware firewalls configured with specific
policy rules allowing forwarding of the NSIS protocol (case of
transport protocols are used for the NTLP). NSIS unaware NATs must
be detected to maintain a well known deterministic mode of operation
for all the involved NSIS entities. Such a "legacy" NAT detection
procedure can be done during the NSIS discover procedure itself.
Based on experience it was discovered that routers unaware of the
Router Alert IP option [RFC 2113] discarded packets,this is certainly
a problem for NSIS signaling.
4.7 Authentication and Authorization
Since a firewall has security functionality, strong authentication
and authorization means MUST be provided.
For NATs security is not a major concern, but might play a role in
the perceived security measure of some administrators. For NAT
sometimes address depletion is considered as a threat.
4.8 Directional Properties
There two directional properties that need to be addressed by the
NATFW NSLP:
o Directionality of the data
o Directionality of NSLP signaling
Both properties are relevant to NATFW NSLP aware NATs and Firewalls.
With regards to NSLP signaling directionality: As stated in the
previous sections, the authentication and authorization of NSLP
signaling messages received from hosts within the same trust domain
(typically from hosts located within the security perimeter delimited
Stiemerling, et al. Expires April 17, 2004 [Page 22]
Internet-Draft A NAT/FW NSIS NSLP October 2003
by firewalls) is normally simpler than received messages sent by
hosts located in different trust domains.
The way NSIS signaling messages enters the NSIS agent of a firewall
(see Figure 2) might be important, because different policies might
apply for authentication and admission control.
Hosts deployed within the secured network perimeter delimited by a
Firewall, are protected from hosts deployed outside the secured
network perimeter, hence by nature the firewall has more restrictions
on flows triggered from hosts deployed outside the security
perimeter.
As opposed to traditional NAT [6] where the NAT bind was implicitly
created when an outbound packet was sent; the NSIS NATFW NSLP aware
NATs will be explicitly requested to create NAT binds. Hence data
packet directionality is no longer significant for the bind creation,
in the case of signaled NAT bind creations on NSIS aware NATs.
However depending on the used NAT implementation, data directionality
may still apply to implicitly maintain the NAT bind (since NAT binds
consume memory and addressing resources); as such some NAT
implementation might still require that outbound packet ONLY maintain
(implicitly and not explicitly) binds.
4.9 Routing Asymmetry
Routing asymmetry [14] is a general problem for path-coupled
signaling, especially when installed states on NSIS forwarders are
related to bi-directional flows.
Path state, on an NSIS forwarder, including the next NSIS hop (for
packets sent from the NR to NI), is used to handle routing asymmetry
for NSIS messages but not for data flows (i.e. no route pinning for
data flows).
Similarly to path-coupled QoS signaling, firewall signaling also has
to be aware of the routing asymmetry when bi-directional flows
relevant states need to be installed on NSIS aware nodes, although
the routing asymmetry might not be significant within the local
networks where firewalls are typically located. For signaling NAT
bindings this issue comes with a different flavor since an
established NAT binding changes the path of the data packets. Hence
a data receiver might still be able to send NSIS signaling messages
to create a NAT binding, although they travel the previously "wrong"
path.
4.10 Addressing
Stiemerling, et al. Expires April 17, 2004 [Page 23]
Internet-Draft A NAT/FW NSIS NSLP October 2003
A more general problem of NATs is the addressing of the end-point.
NSIS signaling message have to be addressed to the other end host to
follow data packets subsequently sent. Therefore a public IP address
of the receiver has to be known prior to sending an nsis message.
When NSIS signaling messages contain IP addresses of the sender and
the receiver in the signaling message payloads, then an NSIS agent
must modify them. This is one of the cases, where a NSIS aware NATs
is also helpful for other types of signaling applications e.g. QoS
signaling.
4.11 NTLP/NSLP NAT Support
It must be possible for NSIS NATs along the path to change NTLP and/
or NSLP message payloads , which carry IP address and port
information. This functionality includes the support of providing
mid-session and mid-path modification of these payloads. As a
consequence these payloads must not be reordered, integrity protected
and/or encrypted in a non peer-to-peer fashion (e.g. end-to-middle,
end-to-end protection). Ideally these mutable payloads must be
marked (e.g. a protected flag) to assist NATs in their effort of
adjusting these payloads.
4.12 Route changes
The effect of route changes are more severe than in other signaling
applications since a firewall pinhole and NAT binding is needed
before further communication can takes place. This is true for both
NSIS signaling and for subsequent data traffic. If a route changes
and NSIS signaling messages do not configure NSIS NATs and firewalls
along the new path then the communication is temporarily interrupted.
This is naturally a big problem for networks where routes frequently
change e.g. ad-hoc networks or in case of fast mobility. In these
cases state refresh messages have to provide a mechanism for fast
reaction.
4.13 Combining Middlebox and QoS signaling
In many cases, middlebox and QoS signaling has to be combined at
least logically. Hence it was suggested to combine them into a
single signaling message or to tie them together with the help of
some sort of data connection identifier, later on refered as Session
ID. This, however, has some disadvantages such as:
- NAT/FW NSLP signaling affects a much small number of NSIS nodes
along the path (for example compared to the QoS signaling).
- NAT/FW signaling might show different signaling patterns (e.g.
required end-to-middle communication).
Stiemerling, et al. Expires April 17, 2004 [Page 24]
Internet-Draft A NAT/FW NSIS NSLP October 2003
- The refresh interval is likely to be different.
- The number of error cases increase as different signaling
applications are combined into a single message. The combination of
error cases has to be considered.
4.14 Difference between sender- and receiver-initiated signaling
For NAT/FW signaling there seems to be little difference between
sender- and receiver- initiated signaling messages. Some other
characteristics of QoS signaling protocols are not applicable (e.g.
the adspec object) to the NAT/FW context. It seems that a full
roundtrip is always required if the protocol aims to be generic
enough.
4.15 Inability to know the scenario
In Section 3.4 a number of different scenarios are presented. In
some scenario NSIS signaling is fairly easy whereas in others it is
quite complex. Additionally different trust relationships exist
between networks along the path, which might require interaction with
the end host or a different signaling behavior. However, the user
(or the NSIS agent initially) typically does not know which scenario
is currently applicable. To make things worse, the scenario might
actually change with moving networks, adhoc networks or with mobility
in general. Hence NSIS signaling must assume the worst case and
cannot put responsibility to the user to know which scenario is
currently applicable. As a result, it might be necessary to perform
a "discovery" periodically such that the NSIS agent at the end host
has enough information to decide which scenario is currently
applicable. This additional messaging, which might not be necessary
in all cases, eats performance, bandwidth and adds complexity.
Additional information by the user can provide information to assist
this "discovery" process but cannot replace it.
Some protocols already aim to provide a solution for an end host to
learn something about the topology such as STUN [11]. To some extend
these protocols can help NSIS NAT/FW signaling.
Stiemerling, et al. Expires April 17, 2004 [Page 25]
Internet-Draft A NAT/FW NSIS NSLP October 2003
5. NSIS NAT Handling Solution
This section describes a mechanism for allowing NSIS signaling
messages to travel end-to-end in the presence of NATs at the
receiving side. This requires to establish state information at the
NSIS-aware NAT device.
Note: The discussed mechanism only creates state relevant for NSIS
message handling. It does not create NAT bindings for data traffic.
5.1 Problem Description
NSIS signaling messages follow the data path from the data sender to
the data receiver. To provide this property of being path-coupled
the discovery process sends signaling messages along the same route
as taken by subsequent data packets. The NSIS messages are directed
to a particular destination IP address and hence the destination
address needs to be known in advance before NSIS signaling can
start.
Stiemerling, et al. Expires April 17, 2004 [Page 26]
Internet-Draft A NAT/FW NSIS NSLP October 2003
+-------------+ AS-Data Receiver Communication
+-------->| Application |<-----------------------------+
| | Server | |
| +-------------+ |
| IP(R-NAT_B) |
| NSIS Signaling Message +-------+--+
| +------------------------------------------>| NAT/NAPT |
| | | B |
| | +-------+--+
| | |
AS-Data| | |
Receiver| | +----------+ |
Comm.| | | NAT/NAPT | |
| | | A | |
| | +----------+ |
| | |
| | |
| | |
| | |
v | IP(R) v
+--------+ +---------+
| Data | | Data |
| Sender | | Receiver|
+--------+ +---------+
Figure 12: The Data Receiver behind NAT problem
Figure 12 describes a typical message communication in a peer-to-peer
networking environment whereby the two end points learn of each
others existence with the help of a third party (referred as
Application Server). The communication with the application server
and the two end points (data sender and data receivers) serves a
number of functions. As one of the most important functions it
enables the two end hosts to learn the IP address of each other.
Without the proposed mechanism it would not be possible to establish
a NAT binding end-to-end in all scenarios.
Some sort of communication between the end hosts and a third party is
typically necessary (independently of NSIS). NSIS signaling messages
cannot be used to communicate application level relevant end point
identifiers (in the generic case at least) as a replacement for the
communication with the application server.
If the data receiver is behind a NAT then an NSIS signaling message
will be addressed to the IP address allocated at the NAT (if there
Stiemerling, et al. Expires April 17, 2004 [Page 27]
Internet-Draft A NAT/FW NSIS NSLP October 2003
was one allocated). If no corresponding NSIS NAT Forwarding State at
NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the signaling
message will terminate at the NAT device (most likely without proper
response message). The signaling message transmitted by the data
sender cannot install the NAT binding or NSIS NAT Forwarding State
"on-the-fly" since this would assume that the data sender knows the
topology at the data receiver side (i.e. the number and the
arrangement of the NAT and the private IP address(es) of the data
receiver). The primary goal of path-coupled middlebox communication
was not to force end hosts to have this type of topology knowledge.
A number of solutions exist to allow nodes behind a NAT to establish
a NAT binding to allow the receiver to receive IP packets. These
solutions can at best be labeled as hacks (see [NATP2P]) and they
have their drawbacks:
o They assume a certain behavior of NAT boxes.
o They work in some environments whereas in others they do not
properly function.
o They only allow NAT bindings for UDP traffic to be established.
o They often fail.
Some other solutions assume that both nodes are registered in the DNS
directory (see [19]).
The requirements for an NSIS solution are two-fold:
1. NSIS signaling messages must be able to travel end-to-end
(between data sender and data receiver) - if desired. This is
important for a number of NSIS NSLPs
2. NSIS relies on a generic solution which works in all scenarios
(see section 5 of [22]).
Since the NSIS signaling messages are intercepted at each NSIS device
the NAT solution depends on the properties of the NTLP. In
particular, multiplexing capability is important. Two possible
options are feasible:
1. Multiplexing with the help of transport layer information (i.e.
port information)
2. Multiplexing at the NSIS application layer (e.g. based on
session identifier)
Stiemerling, et al. Expires April 17, 2004 [Page 28]
Internet-Draft A NAT/FW NSIS NSLP October 2003
We describe the second approach although we believe that alternatives
are possible.
Enough information has to be available to convert IP address
information of an incoming signaling message to different IP
addresses of an outgoing NSIS message. Finally the signaling message
must reach the data receiver.
It seems that the session identifier can be used to associate state
information of the two independent signaling exchanges. The two
exchanges (as described in Section 5.2) are:
1. Signaling exchange from the data receiver (NR) to the NAT(s)
2. End-to-end NSIS signaling message exchange from the NI to the NR.
If the session identifier is used for this purpose then it is
necessary to communicate the session id from the data receiver (NR)
to the NI. Communicating the IP address information instead (as an
alternative solution approach) is easier since this functionality is
already provided by SIP whereas securely exchanging (e.g.
confidentiality protected) the Session Identifier is not available.
5.2 Solution Overview
The data receiver starts to signal an NSIS Create-NAT-Binding message
into the "wrong direction". By "wrong" we refer to the usual
behavior of path-coupled signaling where the data sender starts
signaling in order to tackle with routing asymmetry. The data
receiver would typically return signaling messages to the data sender
in the reverse direction by utilizing state created at nodes along
the path (i.e. to reverse route signaling messages). The concept of
path-coupled or path-decoupled signaling is, however, no relevant for
this special type of signaling communication. In case of
establishing NAT bindings (and NSIS NAT Forwarding State) the
direction does not matter since routing is modified. Subsequent NSIS
messages (and also data traffic) will travel through the same NAT
boxes.
The proposed solution requires two NSIS signaling messages:
1. Create-NAT-Binding Request
2. Create-NAT-Binding Acknowledgement
The semantic of the two messages will be described in detail in this
section.
Stiemerling, et al. Expires April 17, 2004 [Page 29]
Internet-Draft A NAT/FW NSIS NSLP October 2003
The data receiver sends a Create-NAT-Binding NSIS signaling message
into the local network (before the data sender starts NSIS
signaling). In Section Section 5.2.1 we will discuss where to
address this signaling message (i.e. which destination IP address to
use).
The signaling message creates NSIS NAT Forwarding State at
intermediate NSIS NAT node(s). Furthermore it has to be ensured that
the edge NAT device is discovered as part of this process. By edge
NAT we refer to the NAT device which is reachable from outside and
has a globally routable IP address. The end host cannot be assumed
to know this device - instead the NAT box itself is assumed to know
that it has such a capability. Forwarding of the Create-NAT-Binding
NSIS message beyond this entity is not necessary, and should be
prohibited as it provides information on internal hosts capabilities.
Create-NAT-Binding Request
+-------+ +-------+ +-------+ +---------+
| NAT X |<---| NAT Y |<---| NAT Z |<---| Data |
| |--->| |--->| |--->| Receiver|
+-------+ +-------+ +-------+ +---------+
Create-NAT-Binding Response
========================================>
Data Traffic Direction
Figure 13: Create-NAT-Binding NSIS Signaling Message
The goal of this signaling message exchange is:
o to create one (or more) NAT binding(s)
o to allow the data receiver to learn its global routable IP address
(for communication with NSIS)
o not to require the data receiver to learn topology information.
Figure 13 shows a number of NAT devices at the data receivers network
side. NSIS NAT Forwarding State is established at these network
elements.
The Create-NAT-Binding Request message triggers the state creation
and the discovery. The message carries information where the sender
expects incoming NSIS signaling messages.
Stiemerling, et al. Expires April 17, 2004 [Page 30]
Internet-Draft A NAT/FW NSIS NSLP October 2003
The Create-NAT-Binding Response message confirms the state creation
and allows to return information about the NATs and the topology to
the end host (for informational purposes). As a result the end host
will learn the public IP address which can be used by the data sender
to address NSIS signaling messages.
5.2.1 Destination IP address Selection
The Create-NAT-Binding Request message has to be addressed to a
specific destination IP address. Since there is no natural candidate
a few alternatives might be considered. The discussed options refer
to entities of Figure 12
Possible options are:
1. Public IP address of the data sender
2. Public IP address of the data receiver (allocated at NAT B)
3. IP address at the Application Server
Actually, there is no "correct" answer to this question and from a
theoretical point of view it does not really matter as long as Host A
learns an IP address where he has to send the NSIS signaling message.
>From a performance point of view there is, however, a difference
since it would be desirable to create an "optimal" routing path.
1. Public IP address of the data sender:
* Assumption:
+ The data receiver already learned the IP address of the
data sender (e.g. via a third party).
* Problems:
+ The data sender might also be behind a NAT. In this case
the public IP address of the data receiver is the IP
address allocated at this NAT.
+ Due to routing asymmetry it might be possible that the
routes taken by a) the data sender and the application
server b) the data sender and NAT B might be different. As
a consequence it might be necessary to advertise a new (and
different) external IP address with SIP after using NSIS to
establish a NAT binding.
Stiemerling, et al. Expires April 17, 2004 [Page 31]
Internet-Draft A NAT/FW NSIS NSLP October 2003
2. Public IP address of the data receiver (allocated at NAT B):
* Assumption:
+ The data receiver already learned his externally visible IP
address (e.g. based on the third party communication).
* Problems:
+ Communication with a third party is required.
3. IP address at the Application Server:
* Assumption:
+ An application server (or a different third party) is
available.
* Problems:
+ If the NSIS signaling message is not terminated at the NAT
of the local network then an NSIS unaware application
server might discard the message.
+ Routing might not be optimal since the route between a) the
data receiver and the application server b) the data
receiver and the data sender might be different.
Stiemerling, et al. Expires April 17, 2004 [Page 32]
Internet-Draft A NAT/FW NSIS NSLP October 2003
6. Protocol Description
6.1 Basic protocol overview
In the NSIS protocol, hosts try to communicate with each other in
spite of firewalls or NAT's by opening pinholes or making NAT
bindings in them. For things to work, we need to signal the proper
boxes, and that means we will have to send the signals on the data
path, and in the proper direction. So, if the Data Sender (DS) wants
to send data to the Data Receiver (DR), it is DS that will have to
signal towards DR.
Problems arise when DR has a private IP address and is not publicly
reachable. In that case, DR will have to make due for it, and get a
public IP address it can use by using specific NSIS signaling. DS
will then signal towards the public address DR got.
Given this fact, we have two modes of operation:
o First, DR making itself available by signaling on the reverse path
(DR towards DS). This way, it reserves publicly reachable
addresses and ports, which it communicates to DR through means out
of the scope of this document, but probably involving a third
party and an application level protocol.
o And second, DS signaling directly to DR, and creating NAT bindings
and installing FW rules. Nothe that the first mode will usually
make reservations only, which will be "activated" by the signaling
from DS towards DR. The first mode is detailed in the Section 5
The protocol is meant to work on a soft-state basis. This means,
that whatever state is installed or reserved on a middle box, will
expire, and thus be uninstalled/forgotten after a certain timeout.
To prevent this the involved boxes will have to specifically request
a session prolongation. An explicit NATFW NSLP state deletion
message is also provided by the protocol.
Middle boxes should report back in case of error, so that appropriate
measures and debugging can be performed.
6.2 Message format and types
At the moment of writing this document, no decision has been reached
on the details of the NTLP, (NSIS Transport Layer Protocol), hence
the current NATFW NSLP protocol specification uses raw IP transport
with an arbitrary protocol number. The NSIS Protocol Data Unit is
constituted of a header, and a series of objects.
Stiemerling, et al. Expires April 17, 2004 [Page 33]
Internet-Draft A NAT/FW NSIS NSLP October 2003
The NSIS header contains:
o header_len: length of the nsisp header in bytes
o version: protocol version number.
o obj_count: number of objects that follow after the nsis header.
It is followed by a series of objects. Each object is composed of an
object header and the object data. The object header format is
common to all the object types, and has the following format:
o obj_len: total length of the object
o obj_h_len: length of the object header
o obj_type: type of NATFW NSLP object. Identifies the data that
follows.
The object data is attached next to the object header, and varies
depending on the required action to be taken. For the moment four
object types are defined as follows, if required others could be
defined later on.
Create session (a temporary pinhole or a nat-binding):
o sid: Session ID. Randomly generated by the endhosts.
o src_addr: where the data will come from. If it is DS sending data
to DR, the source address is either DS or the closest NAT in the
route from DS to the middlebox that gets the packet; That is, the
address where each middlebox will see the packet come from.
o dst_addr: whre the data is headed. If it is DS sending data to
DR, the destination address is either DR or the public address DR
reserved itself.
o src_port: the transport port the data will come from
o dst_port: the transport port the data will go to.
o proto: protocol number.
Note: you might want to leave the source address or port set to ANY,
to accept any source address port. This makes the pinhole not so pin
like, but might be necessary at the integration with certain NAT/FW
types. Whether this loose pinhole is authorized or not by the middle
box, is a policy decision based on the middle box configuration.
Stiemerling, et al. Expires April 17, 2004 [Page 34]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Prolong session:
o sid: the session we intend to prolong.
Delete session:
o sid: the session we want to delete.
Reserve external addr:
o sid: session for the reserve external address process.
o tgt_addr: address we want our external address to point to. If A
reserves an external address in a NAT, it will want that external
address to point to A.
o tgt_port: port the external addres:port pair should point to.
o src_addr: The address the data will come from. We might want to
set this to 0.0.0.0, to make a loose pinhole reservation, if we
don't the src_addr yet.
o src_port: The port the data will come from. Can also be set to
zero if unknown.
Note that no state, be it a firewall rule or a nat binding, is
installed as a result of this message. The state is only remembered,
and might be later installed by a create message.
Return external addr:
o sid: the session this packet is replyng about.
o ext_addr: the external address that the nat has just created for
the endhost.
o ext_port: the external port.
Path succeeded:
o sid: the session ID for which a path was succesfully installed
Error:
o sid: the session id of the object that generated the error
o error_code: what the error was.
Stiemerling, et al. Expires April 17, 2004 [Page 35]
Internet-Draft A NAT/FW NSIS NSLP October 2003
6.3 Message flow
Of the shown message types, 4 of them are sent by the end hosts to
achieve some service (create, reserve, prolong, and delete) and 3 are
sent back as a response (return external address, path succeded and
error).
The usual message flow for the reservation mode of operation, to
achieve an external address, is:
DS Public Internet NAT Private addres DR
| | space |
| | |
| | Reserve |
| |<---------------------------|
| | |
| | Return ext addr / Error |
| |--------------------------->|
| | |
| | |
In the case of the creation mode, when rules are actually installed,
the message flow is as follows:
Stiemerling, et al. Expires April 17, 2004 [Page 36]
Internet-Draft A NAT/FW NSIS NSLP October 2003
DS Public Internet NAT Private addres DR
| | space |
| Create | |
|----------------------------->| |
| | |
| Error (if necessary) | |
|<-----------------------------| Create |
| |--------------------------->|
| | |
| | Path Succeeded/Error |
| Path Succeeded/Error |<---------------------------|
|<-----------------------------| |
| | |
| | |
When it comes to prolonging or deleting sessions:
DS Public Internet NAT Private addres DR
| | space |
| Prolong/Delete | |
|----------------------------->| |
| | |
| Error (if necessary) | |
|<-----------------------------| Prolong/Delete |
| |--------------------------->|
| | |
| | Error (if necessary) |
| Error (if necessary) |<---------------------------|
|<-----------------------------| |
| | |
| | |
6.4 Middle box configuration
The way a message is handled in each box will depend on its
configuration.
Currently defined ocal NSIS NAT/FW configuration parameters are:
o nat_capabilities: am I a NAT?
o nat_external_addr: if I'm a nat, what is the address closest to
Stiemerling, et al. Expires April 17, 2004 [Page 37]
Internet-Draft A NAT/FW NSIS NSLP October 2003
the public internet?
o edge_nat: true, false or auto. Tells us how much of an edge_nat
we are. See explanation below.
The edge_nat parameter requires some more explanation, though. When
a host reserves an external address, as seen in Section 5, it makes
itself reachable by the other end. This does not always mean a
public internet address. In Section 7.4 we see that a private
address can also be reachable by another box in the same address
space. Still, things work well if we get a public ip address, only
the route is unnecesarily long (see an example in Section 7.4).
For this reason, we can set up the boxes to always or never behave as
an edge nat, or else set it to auto. The auto setting will compare
the destination ip address of the reserve address objects, and see if
they belong to the same address space as the nat external address.
If it is so, the nat behaves as an edge_nat for this connection,
otherwise, it doesn't.
Note that the address spaces are set in RFC3330 [2].
6.5 Message handling
When a box receives an NSIS message, it might take an action based on
the message type, the nature of the box, its configuration and its
security policies.
As a summary, here's the behaviour of the boxes, depending on message
type and config parameters:
NAT FW NAT+FW DS DR
reserve 5 - 5 + +
ret_ext_addr - - - + 8
create 1 2 3 + 4
prolong 6 6 6 + 4
delete 7 7 7 + 4
path_succeed - - - 8 +
1: install the rule, rewriting either the source or destination
address depending on whether the packet comes from the
external_address or not. Always forward.
2: Install the rule, always forward.
3: 1+2. The order depends on whether it comes from the outside
address (NAT, then FW) or the inside one (FW, then NAT)
Stiemerling, et al. Expires April 17, 2004 [Page 38]
Internet-Draft A NAT/FW NSIS NSLP October 2003
4: If it fits one of its requests, send a path_succeeded packet
back. Drop the packet.
5: Make a reservation. If edge_nat is set, send back the
external_addr and don't forward. Otherwise, forward and don't
send anything back.
6: Prolong the session. Always forward.
7: Terminate the session. Always forward.
8: hand it over to superior layers, and drop it.
-: ignore and forward.
+: ignore and drop.
Note that the order is important, when it comes to NAT+FW boxes,
because the filter rules have to be set up according to the packet
they will see. Source NAT is done at the end so it doesn't disturb
routing decisons, this means the filter sees the original packets.
Destination NAT, on the other hand, is done at the beginning, so it
can be routed properly, and so the filter sees the modified packets.
Note also that for each action, the host might demand a certain
degree of authorization, and thus refuse to take the action, sending
an error message back instead.
The details of the message handling in each of the boxes follows.
6.5.1 Detailed behaviour
6.5.1.1 Reserve external address message
o NAT Box:
When a NAT box gets a Reserve external addressm message, it checks
whether it arrived on the public address, or the private one. If
it arrived in the public one, an error message of the type:
"Requested an external address from the outside" is sent back.
If it arrived on the private side, an entry is made in the
internal reservation list with the packet information. If the box
is an edge nat (either by configuring it to true, or just for that
connection if it is set to auto), it drops the message, and
replies with a return external address message containing the
allocated address port pair. If it is not an edge NAT, it
forwards the packet on.
Stiemerling, et al. Expires April 17, 2004 [Page 39]
Internet-Draft A NAT/FW NSIS NSLP October 2003
o Firewall Box:
Reserve messages are silently ignored in Firewall boxes. They are
simply forwarded on.
o NAT+FW Box:
When a box that integrates both a NAT and a Firewall gets a
reserve message, it will hand it to its NAT part. Its firewall
part will simple ignore it.
o Data Sender:
The message should never get here. It should be ignored and
dropped.
o Data Receiver:
The message should never get here. It should be ignored and
dropped.
6.5.1.2 Return external address message
o NAT Box, Firewall Box and NAT+Firewall Box:
When one of these boxes gets a Return external address message, it
must simply ignore it and let it traverse.
o Data Sender:
The message should never get here. It should be ignored and
dropped.
o Data Receiver:
A return external address message in the Data receiver, has
reached its destination. It must be dropped, and it's information
handed to superior layers.
6.5.1.3 Create message
o NAT Box:
When a NAT box gets a create message, it first checks if it
arrived on the public address or not.
Stiemerling, et al. Expires April 17, 2004 [Page 40]
Internet-Draft A NAT/FW NSIS NSLP October 2003
If it came from the public side, it means an external box will try
to send data. It then looks for a reservation in its reservation
list, that matches the dst_addr and dst_port of the packet. If it
doesn't find it, it returns an error message of the type "No
reservation found". If it finds it, it fills in the reservation
with the data from the packet, and installs the given rule. It
then changes the dst_addr and dst_port fields of the create packet
and forwards it to the tgt_addr of the reservation.
If it came from the private side, it installs the nat rule with
the information in the packet. It then changes the src_addr and
src_port of the create message to its own external address and
port.
o Firwall Box:
When a firewall box gets a create message, it simply installs the
rule specified in the message and forwards the packet.
o NAT+FW Box:
When a box that integrates both a NAT and a Firewall gets a create
message, it first checks whether it arrived on the public address
or not.
If it arrived on the public side, the NAT part of the box takes
care of the packet first, as said in the NAT Box case.
Afterwards, the modified packet is handed to the firewall part,
where it is handled as in the Firewall Box case.
If it arrived on the private side, the message is handed to the
firewall part first, and then to the NAT one.
o Data Sender:
The message should never get here. It should be ignored and
dropped.
o Data Receiver:
If the data receiver gets a create message, it means all the boxes
on the way accepted it, and so the signaling succeded. All it
does is drop the packet, and send back a Path Succeded message to
the ip packet source address.
Stiemerling, et al. Expires April 17, 2004 [Page 41]
Internet-Draft A NAT/FW NSIS NSLP October 2003
6.5.1.4 Delete session message
o NAT Box, Firewall Box and NAT+Firewall Box:
When one of these boxes gets a Delete session message, it should
erase the session refered in the message.
o Data Sender:
As in the create session message, this packet should never get to
the DS, so it is to be ignored and dropped.
o Data Receiver:
As in the create session message, this is the final destination of
the message. If it got here, everything is fine. No further
action should be taken on the packet, which means it is dropped at
the endhost.
6.5.1.5 Prolong session message
o NAT Box, Firewall Box and NAT+Firewall Box:
When one of these boxes gets a Prolong session message, the
expiration time of the session should be changed to the time of
reception plus the configured session lifetime.
o Data Sender:
As in the create session message, this packet is sent from the DS
to the DR, and should never arrive at the DS. Again, it should be
ignored and dropped.
o Data Receiver:
The same behaviour as in the case of a Delete session message on
the DR should be applied.
6.5.1.6 Path Succeded message
o NAT Box, Firewall Box and NAT+Firewall Box:
When one of these boxes gets a Path succeded message, it should
simply ignore it and allow it to traverse.
o Data Sender:
Stiemerling, et al. Expires April 17, 2004 [Page 42]
The message ends here. It must be dropped, and its contents sent
to upper software layers.
o Data Receiver:
The message should never get here. It should be ignored and
dropped.
Stiemerling, et al. Expires April 17, 2004 [Page 43]
Internet-Draft A NAT/FW NSIS NSLP October 2003
7. Solution examples
7.1 Firewall traversal
DS wants to send ata traffic to DR through tight firewalls, as seen
in Figure 18. To do that, it will have to signal using NSIS, on the
data path.
+-----+ +-----+ //----\\ +-----+ +-----+
DS --| FW1 |-----| FW2 |---| |---| FW3 |-----| FW4 |--- DR
+-----+ +-----+ \\----// +-----+ +-----+
private public private
Data Flow
===============================>
Figure 18: Firewall Traversal Scenario
Therefore, DS initiates signaling to DR by sending a create object to
the ip address od DR. Note that DS already knows its source address
and port (say, 1111), and the destination address of DR. The
destination port (let's say 9999) has been send to DS by DR via
application layer messages, possibily, but not necessarily involving
a third party. The message looks like:
o dst_addr = DR
o dst_port = 9999
o src_addr = DS
o src_port = 1111
This message is received by FW1, which installs the state that reads:
"Any packet coming from DS:1111 headed for DR:9999 will be allowed
traversal"
FW2, FW3 and FW4 do exactly the same, and forward the packet to each
other, until it finally reaches DR. At this point, the data path is
open, and DR sends back a Path succeeded message to DS, which can now
start sending traffic.
7.2 NAT with private network on sender side
Stiemerling, et al. Expires April 17, 2004 [Page 44]
Internet-Draft A NAT/FW NSIS NSLP October 2003
In the example in Figure 19, DS is in a private network and wants to
send data to DR, out in the public internet. To do so, DS will have
to initiate NSIS signaling towards DR
+------+ +------+ //----\\
DS --| NAT1 |-----| NAT2 |---| |--- DR
+------+ +------+ \\----//
private public
Figure 19: NAT with private network on sender scenario
Now, this is a deceivingly easy example. Apparently, the normal NAT
functionality will take care of sending the data from DS out into the
public internet, and route back the replies from DR. This is indeed
true, but doesn't give NSIS control on what the source address or
port is, as it is usually asigned dinamycally by the NAT. Moreover,
the NSLP would have no information on this hops, and could not
install proper pinholes, as it would set DS as the source address,
and not that of the last NAT.
DS builds a create packet with the information he has, which is the
same as that in Section 7.1. It looks like this:
o dst_addr = DR
o dst_port = 9999
o src_addr = DS
o src_port = 1111
NAT1 is the first to get the packet; It is not coming from its
configured "nat external address", and so, it knows it will have to
rewrite the information on the source, and not that of the
destination. NAT1 then picks a free port (incidentally 1011) and
installs a nat rule that reads: "Whatever packet comes from DS:111,
heading for DR:9999 will be rewriten so that the source address looks
like NAT1:1011".
It then rewrites the packet it received as follows:
o dst_addr = DR
o dst_port = 9999
Stiemerling, et al. Expires April 17, 2004 [Page 45]
Internet-Draft A NAT/FW NSIS NSLP October 2003
o src_addr = NAT1
o src_port = 1011
And forwards the packet.
NAT2 gets it now, and does exactly the same. Port 2022 is chosen,
and the rule: "Whatever packet comes from NAT1:1011, heading for
DR:9999 will be rewriten so that the source address looks like
NAT2:2022" is installed. The packet gets modified as follows:
o dst_addr = DR
o dst_port = 9999
o src_addr = NAT2
o src_port = 2022
And is forwarded. It eventually reaches DR, who sends back a path
succeded message. Data flow from DS:1111 to DR:9999 is now possible.
7.3 NAT with private network on receiver side
In this example, DS wants to send data to DR over the network in
Figure 20:
//----\\ +------+ +------+
DS ---| |---| NAT1 |-----| NAT2 |--- DR
\\----// +------+ +------+
public private
Figure 20: NAT with private network on receiver Scenario
The problem, of course, is that DR is not publicly reachable.
Because of that, DR will have to signal on the data path, in the
opposite direction (DR->DS) to get itself a public address it can
use. This method is described in Section 5
To get an external address, DR sends a packet to DS. It could
actually send it to anything in the public internet, as it would
force it to traverse what NATs are on its way. In the case of
multihomed environments, though, more than one NAT to the outside is
possible, so the better we "aim" the more the chances we go out the
Stiemerling, et al. Expires April 17, 2004 [Page 46]
Internet-Draft A NAT/FW NSIS NSLP October 2003
right NATs and get more optimal routes.
The said packet is an NSIS reserve_addr object which looks like this:
o tgt_addr = DR
o tgt_port = 9999
o src_addr = 0.0.0.0
o src_port = 0
Notice that this is a really loose pinhole, since any src_addr and
port is allowed.
NAT2 gets the packet and looks for a free port (say, 2022, for
clarity's sake). It then adds an entry to its reservation list. The
entry looks like this:
o src_addr = 0.0.0.0
o src_port = 0
o dst_addr = NAT2
o dst_port = 2022
o tgt_addr = DR
o tgt_port = 9999
This means simply that packets coming from any source, destinated to
the public address we just reserved, shoud be targeted to the
internal box DR, on port 9999
It then rewrites the packet so that it looks like:
o tgt_addr = NAT2
o tgt_port = 2022
o src_addr = 0.0.0.0
o src_port = 0
Because it is not an edge nat, it forwards the modified packet and
does not sent a return_external_addr object to DR. Note that no nat
binding is installed so far in NAT2, although the state is now
Stiemerling, et al. Expires April 17, 2004 [Page 47]
Internet-Draft A NAT/FW NSIS NSLP October 2003
reserved.
NAT1 now gets the packet, picks free port 1011 and adds the following
entry to its reservation list:
o src_addr = 0.0.0.0
o src_port = 0
o dst_addr = NAT1
o dst_port = 1011
o tgt_addr = NAT2
o tgt_port = 2022
As it turns out, NAT1 IS an edge_nat, so it doesn't forward the
packet. Instead, it replies to DR sending back a return external
address packet on the same connection, so it finds its way back
through the NATs:
o ext_addr = NAT2
o ext_port = 2022
By using some application layer protocol, and possibly, although not
necesarily, using a third party box, DR sends it's freshly allocated
external address and port to DS.
DS now knows who to signal, so it sends a create message:
o dst_addr = NAT1
o dst_port = 1011
o src_addr = DS
o src_port = 1111
When it reaches NAT1, it does so through NAT1 external address. It
realizes it is being asked to forward the traffic from some outside
box towards the inside. It then looks up its reservation list,
looking for a session that has the external address and port
NAT1:1011 assigned. It finds this:
o src_addr = 0.0.0.0
Stiemerling, et al. Expires April 17, 2004 [Page 48]
Internet-Draft A NAT/FW NSIS NSLP October 2003
o src_port = 0
o dst_addr = NAT1
o dst_port = 1011
o tgt_addr = NAT2
o tgt_port = 2022
Using the information in the create object, it then fills in this
structure to:
o src_addr = DS
o src_port = 1111
o dst_addr = NAT1
o dst_port = 1011
o tgt_addr = NAT2
o tgt_port = 2022
This IS a tight pinhole. NAT1 installs the rules now, which say:
"Whatever packet comes from DS:1111 heading for NAT1:1011, should
have its destination address changed to NAT2:2022, and be forwarded".
The packet is also rewritten into this:
o src_addr = DS
o src_port = 1111
o dst_addr = NAT2
o dst_port = 2022
And is forwarded to NAT2. Upon arrival, a similar process issues.
NAT2 finds its reservation entry:
o src_addr = 0.0.0.0
o src_port = 0
o dst_addr = NAT2
o dst_port = 2022
Stiemerling, et al. Expires April 17, 2004 [Page 49]
Internet-Draft A NAT/FW NSIS NSLP October 2003
o tgt_addr = DR
o tgt_port = 9999
Fills it in accordingly:
o src_addr = DS
o src_port = 1111
o dst_addr = NAT2
o dst_port = 2022
o tgt_addr = DR
o tgt_port = 9999
Rewrites the packet:
o src_addr = DS
o src_port = 1111
o dst_addr = DR
o dst_port = 2222
And forwards it to DR. Once there, DR acknowledges it by sending
back a path succeded message in reply, back to DS.
The path is now open and data transmission from DS:1111->DR:9999 can
comence.
7.4 Both end hosts are in same private network behind NATs
In this example (see Figure 21), DS, in a private address space,
wants to send data to DR, in another private address space. The
point marked "%" is yet another private address space. Notice that
since NAT1 and NAT3 have addresses in the same address space, NAT3
might want to consider itself an edge nat. We will consider both
situations.
Stiemerling, et al. Expires April 17, 2004 [Page 50]
Internet-Draft A NAT/FW NSIS NSLP October 2003
public
+------+ % +------+ //----\\
DS --| NAT1 |--+--| NAT2 |---| |
+------+ | +------+ \\----//
|
| +------+
+--| NAT3 |------------ DR
+------+
private
Figure 21: NAT to public, receiver in same private network Scenario
We will first assume that NAT3 has the edge_nat option set to false.
In this case, the connection is a combination of Section 7.3 and
Section 7.2.
Firstly DR will signal against on the data path, against the data
flow, with a reserve external address object. NAT3 will reserve the
address and forward the packet on to NAT2, who IS an edge nat in all
cases. NAT2 will reply with the external address, and the connection
goes on just as in Section 7.2, except for the fact the topology
becomes:
Stiemerling, et al. Expires April 17, 2004 [Page 51]
Internet-Draft A NAT/FW NSIS NSLP October 2003
public
+------+ +------+
DS --| NAT1 |-----o------o---+
+------+ | | |
| NAT2 |---+
| | |
+--o------o---+
| +------+
|
| +------+
+--| NAT3 |------------ DR
+------+
private
Figure 22: New topology due to the non optimal edge nat parameter
decision
This is not optimal, but the connection does succeed, and data flow
can commence.
Let us now solve the case in which NAT3 has edge_nat set to auto.
Back in Figure 21, NAT3 will decide it IS an edge_nat if the
destination we pick up for the reserve address packet is in the
address space marked as "%", and will NOT consider itself an edge_nat
if we point it anywhere else. This is an optimality issue such as
the one pointed out in Section 7.3.
Well so, if it doesn't consider itself an edge nat, we already saw
what the topological equivalent is, and how it proceeds. If it IS an
edge nat, the topological equivalent would be:
Stiemerling, et al. Expires April 17, 2004 [Page 52]
Internet-Draft A NAT/FW NSIS NSLP October 2003
+------+
DS --| NAT1 |--+
+------+ |
|
| +------+
+--| NAT3 |------------ DR
+------+
private
Figure 23: A good edge nat decision brings an optimal route
And we would proceed in the same way, only on a more optimal route.
7.5 IPv4/v6 NAT with two private networks
TBD
7.6 Full example for NAT/FW with two private networks
The NAT's have the nat_capabilities variable set to true. NAT+FW3
and NAT+FW5 have the edge_nat variable set to true. The rest of
boxses have it set to false.
Let's now suppose that DR wants to get a data stream from DS in
Figure 24. For that, we need some way for B to get messages from A,
be it through some third party application server or some publicly
reachable proxy, perhaps made public through a nat binding.
Stiemerling, et al. Expires April 17, 2004 [Page 53]
Internet-Draft A NAT/FW NSIS NSLP October 2003
+-----+
+--------| FW4 |--------+
| +-----+ |
+---------+ +---------+
| NAT+FW3 | | NAT+FW5 |
+---------+ +---------+
| |
+---------+ +---------+
| NAT3 | | NAT6 |
+---------+ +---------+
| |
+---------+ +---------+
| FW1 | | FW7 |
+---------+ +---------+
| |
+---------+ +---------+
| DS | | DR |
+---------+ +---------+
Data Flow
==========================>
Figure 24: Example network topology
DR wants a data stream from DS, which means that the direction of the
data is DS->DR. A will have to make itself publicly reachable by
signaling its NATs and firewalls as necessary. This is a step by
step guide to the whole process.
In steps 1 to 4, DR makes itself publicly reachable. From 5 and on,
DS is signaling on the data path towards DR.
1. DR wants to get data from DS, so it sends a reserve_addr object
to a target in the public internet. The closest this target is, the
more the chances that the outcoming route is optimal, but any will
work. The reserve_addr obj looks like this:
o tgt_addr = DR
o tgt_port = 888
o src_addr = 0.0.0.0
o src_port = 0
Notice that this is a really loose pinhole, since any src_addr and
port is allowed.
Stiemerling, et al. Expires April 17, 2004 [Page 54]
Internet-Draft A NAT/FW NSIS NSLP October 2003
2. FW7 gets the packet, ignores its contents and forwards it.
Firewalls always ignore reserve_addr objects.
3. NAT6 gets the packet, and looks for a free port (say, 666, for
clarity's sake). It then adds an entry to its reservation list. The
entry looks like this:
o src_addr = 0.0.0.0
o src_port = 0
o dst_addr = NAT6
o dst_port = 666
o tgt_addr = DR
o tgt_port = 888
It then rewrites the packet so that it looks like:
o tgt_addr = NAT6
o tgt_port = 666
o src_addr = 0.0.0.0
o src_port = 0
Because it is not an edge nat (edge_nat=false), it does not sent a
return_external_addr object to DR, but rather forwards the modified
packet. Note that no nat binding is installed so far in NAT6,
although the state is now reserved.
4. NAT+FW5 receives the packet. The firewall part gets the object,
but, being as it is an address reservation only object, it ignores
it. The NAT part gets it next. Because it is a NAT, it binds a free
port, which is thus reserved. An entry to the reservation list is
added:
o src_addr = 0.0.0.0
o src_port = 0
o dst_addr = NAT+FW5
o dst_port = 555
Stiemerling, et al. Expires April 17, 2004 [Page 55]
Internet-Draft A NAT/FW NSIS NSLP October 2003
o tgt_addr = NAT6
o tgt_port = 666
Because it is an edge_nat, it sends a return_external_addr packet
with address NAT+FW5 and port 555 back to DR. It does so by simply
sending it back to the source IP addr in the IP header of the packet.
In this case, it is NAT6. The standard capabilities of NAT6 will
send it back to DR, since we are always working on the same
connection. Because it is an edge_nat and this is a
reserve_external_addr packet, it does not forward the packet.
At this stage, the end host DR has learned what its (reserved)
external address is, even if it can not be used. It is now publicly
reachable, and path-coupled nsis signaling in direction DS->DR can
start.
5. Firstly, DR tells DS about it's freshly reserved outside address
through some higher layer protocol, using the third-party box.
6. DS now initiates signaling to DR by sending a create object to
the brand new public address of DR. It looks like:
o dst_addr = NAT+FW5
o dst_port = 555
o src_addr = DS
o src_port = 111
7. The firewall FW1 gets it, and installs the requested pinhole.
(Note this IS a tight pinhole with well defined source and
destination). It then forwards the packet.
8. NAT2 gets the packet. Because it is NOT coming from it's
external address, it realizes it is being asked to forward DS's
future data packets, and so, it will have to rewrite it's source
address. To do so, NAT2 picks a random free port (which turns out to
be 222), and installs a nat rule that says: "Whatever packet comes
from DS:111, heading for NAT+FW5:555 will be rewriten so that the
source address looks like NAT2:222". That is usually known as Source
NAT. The nsis create request is then rewriten to look like:
o dst_addr = NAT+FW5
o dst_port = 555
Stiemerling, et al. Expires April 17, 2004 [Page 56]
Internet-Draft A NAT/FW NSIS NSLP October 2003
o src_addr = NAT2
o src_port = 222
Because it is not an edge nat, it simply forwards the modified
packet.
9. NAT+FW3 gets the packet next. Because it is NOT coming from the
extarnal_addr of the NAT+FW, The firewall part gets it first, and
installs the filter rule that says: "Allow traversal of packets going
from NAT2:222 towards NAT+FW5:555". It then hands it to the NAT
part.
The NAT part gets it then. It is not coming from its external addr,
and so, it does as NAT2, binding a port (333) and installing a rule
that says: "Whatever packet comes from NAT2:222, heading for
NAT+FW5:555, will be rewriten so that the source address looks like
NAT+FW3:333". It will then rewrite the create object to:
o dst_addr = NAT+FW5
o dst_port = 555
o src_addr = NAT+FW3
o src_port = 333
Note that the box won't send a packet back to DS informing it of its
external address, because DS will never need that.
10. FW4 gets the create object, and installs the rule "Allow
traversal of packets going from NAT+FW3:333 towards NAT+FW5:555" It
then forwards the object.
11. NAT+FW5 gets the create object. It arrived at its external
address, so it realizes it doesn't have to change the source address
of the future data packets of DS, but rather its destination. It
also means that the NAT part will have to handle it first. It then
tries to find out where it has to re-destinate it to, by looking up
its reservation tables. It finds the previous reservation, by
matching it with ther dst_addr and dst_port of the create object:
o src_addr = 0.0.0.0
o src_port = 0
o dst_addr = NAT+FW5
Stiemerling, et al. Expires April 17, 2004 [Page 57]
Internet-Draft A NAT/FW NSIS NSLP October 2003
o dst_port = 555
o tgt_addr = NAT6
o tgt_port = 666
And proceeds to fill it in with the information of the create object
(src_addr and src_port):
o src_addr = NAT+FW3
o src_port = 333
o dst_addr = NAT+FW5
o dst_port = 555
o tgt_addr = NAT6
o tgt_port = 666
It then installs a NAT rule with that information. It reads:
"Whatever packet comes from NAT+FW3:333, heading for NAT+FW5:555 will
be rewritten, so that its destination address looks like NAT6:666".
The reservation is erased and the rule starts working. The NAT
binding becomes thus usable.
The object is modified, so that it now looks like:
o dst_addr = NAT+FW3
o dst_port = 333
o src_addr = NAT6
o src_port = 666
The FW part now gets the object, and installs the rule: "Allow
traversal of whatever packet that comes from NAT+FW3:333 heading for
NAT6:666". The packet is then forwarded.
12. NAT6 gets the packet. As it comes from the external adddress,
it does as NAT+FW5, looking up the reservation list and filling it in
with:
o src_addr = NAT+FW3
o src_port = 333
Stiemerling, et al. Expires April 17, 2004 [Page 58]
Internet-Draft A NAT/FW NSIS NSLP October 2003
o dst_addr = NAT6
o dst_port = 666
o tgt_addr = DR
o tgt_port = 888
It then installs the rule: "Whatever packet comes from NAT+FW3:333,
heading for NAT6:666 will be rewritten, so that its destination
address looks like DR:888". The rule reservation is erased, and the
NAT binding becomes active. The object is rewritten as:
o src_addr = NAT+FW3
o src_port = 333
o dst_addr = DR
o dst_port = 888
The object is thus forwarded.
13. FW7 gets the packet now, and installs the rule: "Allow traversal
of whatever packet that comes from NAT+FW3:333 heading for DR:888".
It forwards the packet.
14: DR gets (finally) the packet. It realizes it is a create object
headed for him, to the port which he expected, and so it sees
everything went well. A reply to the packet is send, and the NAT's
on the way, knowing the already established connection, will route it
to DS. The packet is a path_succesful message, which simply means
"Everything's fine, send data whenever you want".
Stiemerling, et al. Expires April 17, 2004 [Page 59]
Internet-Draft A NAT/FW NSIS NSLP October 2003
8. NSIS NAT and Firewall transitions issues
NSIS NAT and Firewall transition issues are premature and will be
addressed in a separate draft (see [8]). An update of this section
will be based on consensus.
Stiemerling, et al. Expires April 17, 2004 [Page 60]
Internet-Draft A NAT/FW NSIS NSLP October 2003
9. Security Considerations
Security is of major concern particularly in case of firewall
traversal. Generic threats for NSIS signaling have been discussed in
[3] and are applicable here as well. It is necessary to provide
proper signaling message protection and proper authorization. Note
that the NAT is likely to be co-located with a firewall and might
therefore require packet filters to be changed in order to allow the
signaling message to process and to traverse. This section aims to
raise some items for further discussion and illustrates the problems
the authors faced when creating a security solution for the NAT/
Firewall NSLP. Without doubts there is a dependency on the security
provided by the NTLP. At the time of writing this version of the
document no NTLP draft is available (or accessible for the authors).
Section Section 4 and Section 3.5 motivates some trust relationship
and authorization scenarios. These scenarios deserve a discussion
since some of them (particularly one with a missing
network-to-network trust relationship) is different to what is know
from QoS signaling. To address some of these trust relationships and
authorization issues requires security mechanisms between
non-neighboring nodes at the NSLP layer. For the group of authors it
seems that peer-to-peer and end-to-middle security needs to be
provided. An NSLP security mechanism between neighboring NSLP peers
might be necessary if security mechanisms at the NTLP do not provide
adequate protection mechanisms. This issue is, however, still in
discussion. As a design goal it seems to be favorable to reuse
existing mechanisms to the best extend possible. In most cases it is
necessary to carry the objects for end-to-middle as NSLP payloads
since the precesence of NATs might prevent direct communication.
Three security mechanisms have to be considered in more detail in a
future version of this document: CMS [9] and Identity Representation
for RSVP [10]. The authors believe that CMS more suitable (since it
provides much more functionality). The details deserve further
discussion and implementation experience.
With regard to signal between two end hosts even though the receiver
is behind a NAT this proposal suggests creating state by the data
receiver first. This allows NSIS signaling messages to traverse a
NAT at the receiver side (due to the established state at this NAT
box) and simplifies security handling.To achieve this behavior it is
required to install NSIS NTLP and NSLP state. Furthermore, it is
envisioned to associate the two signaling parts (one part from the
data sender to the NAT and the other part from the NAT to the data
receiver) with the help of the Session Identifier. As such, the
discussion in [10] is relevant for this document.
Another interesting property of this protocol proposal is to prevent
Denial of Service attacks against NAT boxes whereby an adversary
Stiemerling, et al. Expires April 17, 2004 [Page 61]
Internet-Draft A NAT/FW NSIS NSLP October 2003
allocates NAT bindings with the help of data packets. Since these
data packets do not provide any type of authentication and are not
authorized any adversary is able to mount such an attack. This
attack has been mentioned at several places in the literature
already and is particularly harmful if no NAPT functionality is used
(i.e. if a new NAT binding consumes one IP address of a pool of IP
addresses). Using the protocol described in this document additional
security can be achieved and more fairness can be provided.
Stiemerling, et al. Expires April 17, 2004 [Page 62]
Internet-Draft A NAT/FW NSIS NSLP October 2003
10. Open Issues
At least the following issues require further discussion:
o Message format: The exact message format is still to be
determined, both in regards of bit level details and on
parameters, such as the need for an object header length, since,
until now, that is a constant.
o Error codes: error codes have to be defined still. Among others,
we will need: missing authorization, out of resources, unable to
understand the packet, or maximum resources for that individual
already allocated.
o Middle box default policies: allow for the configuration of the
default policies of the box. For a NAT+Firewall box, for
instance, the firewall default policy might be "accept", and so,
no packet filters would have to be installed on that regard (we
would still need the nat bindings, though).
Stiemerling, et al. Expires April 17, 2004 [Page 63]
Internet-Draft A NAT/FW NSIS NSLP October 2003
11. Contributors
A number of individuals have contributed to this draft. Since it was
not possible to list them all in the authors section, it was decided
to split it and move Marcus Brunner and Henning Schulzrinne into the
contributors section. Separating into two groups was done without
treating any one of them better (or worse) than others.
Stiemerling, et al. Expires April 17, 2004 [Page 64]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Normative References
[1] Brunner et al., M., "Requirements for Signaling Protocols",
DRAFT draft-ietf-nsis-req-07.txt, March 2003.
[2] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[3] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
DRAFT draft-ietf-nsis-threats-01.txt, January 2003.
[4] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002.
Stiemerling, et al. Expires April 17, 2004 [Page 65]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Informative References
[5] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations, RFC 2663", August 1999.
[6] Srisuresh, P. and E. Egevang, "Traditional IP Network Address
Translator (Traditional NAT), RFC 3022", January 2001.
[7] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and
X. Fu, "Security Implications of the Session Identifier", June
2003.
[8] Aoun and others...., C., "NAT/Firewall NSLP migration, routing,
NTLP requirements and off-path Considerations", October 2003.
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[10] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC
3182, October 2001.
[11] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[12] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K.
Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt,
November 2002.
[13] Tschofenig, H., Buechli, M., Van den Bosch, S. and H.
Schulzrinne, "NSIS Authentication, Authorization and Accounting
Issues", draft-tschofenig-nsis-aaa-issues-01 (work in
progress), March 2003.
[14] Amini, L. and H. Schulzrinne, "Observations from router-level
internet traces", DIMACS Workshop on Internet and WWW
Measurement, Mapping and Modelin Jersey) , Februar 2002.
[15] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4
Traversal of VPN Gateways",
draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in
progress), April 2003.
[16] Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin,
"Problem Space and Usage Scenarios for PANA",
draft-ietf-pana-usage-scenarios-06 (work in progress), April
2003.
Stiemerling, et al. Expires April 17, 2004 [Page 66]
Internet-Draft A NAT/FW NSIS NSLP October 2003
[17] Shore, M., "The TIST (Topology-Insensitive Service Traversal)
Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002.
[18] Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT
Traversal Client for CASP", DRAFT
draft-tschofenig-nsis-casp-midcom-01.txt, March 2003.
[19] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan,
"DNS extensions to Network Address Translators (DNS_ALG)", RFC
2694, September 1999.
[20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[21] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002.
[22] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H. and H.
Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and
Framework", DRAFT draft-brunner-nsis-midcom-ps-00.txt, June
2003.
Authors' Addresses
Martin Stiemerling
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 13
EMail: stiemerling@ccrle.nec.de
URI:
Hannes Tschoefenig
Siemens AG
Otto-Hahn-Ring 6
Munich 81739
Germany
Phone:
EMail: Hannes.Tschofenig@siemens.com
URI:
Stiemerling, et al. Expires April 17, 2004 [Page 67]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Miquel Martin
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 16
EMail: lopez@ccrle.nec.de
URI:
Cedric Aoun
Nortel Networks
France
EMail: cedric.aoun@nortelnetworks.com
Stiemerling, et al. Expires April 17, 2004 [Page 68]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Appendix A. Interworking of SIP with NSIS NATFW NSLP
This document aims at pinpointing the problems of using SIP in
nowadays networks, focusing on the problems derived of NAT's,
Firewalls and multi-path communications. It is intended to fit in a
scenario description that shows the necessity of NSIS, as well as
depicting it's requirements. However, note that there are a number
of other solutions available. For example the IETF Midcom working
group is working on [4].
A.1 The Session Initiation Protocol
[20] describes the Session Initiation Protocol, an application-layer
control protocol that can establish, modify, and terminate multimedia
sessions. This often involves several flows for video and voice,
which are transported over new connections. These use of dynamically
allocated ports which results in protocol complexity which can not be
handled by nowadays NAT's and Firewalls.
Session initiation when one or both of the users is behind a NAT is
also not possible, given the impossibility to address a private IP
over the internet. Moreover, network deployments often allow for
different paths per connection and direction, making the setup of the
middle boxes even more complicated.
The following figure depicts a typical SIP connection:
Stiemerling, et al. Expires April 17, 2004 [Page 69]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Ernie(192.0.2.1) Bert(192.0.2.2)
| |
| 1# SIP INVITE |
+--------------------------------------->|
|
| 2# SIP Ringing |
|<---------------------------------------+
| |
| 3# SIP OK | <-- Call accepted
|<---------------------------------------+
| |
| 4# SIP ACK |
+--------------------------------------->|
| |
| 5# DATA |
|=======================================>|
|<=======================================|
| |
1# SIP Invite (192.0.2.1:? -> 192.0.2.2:SIP): I Listen on
192.0.2.1:1000 Ernie invites Bert to the conference, and informs
it's awaiting media data on port 1000.
2# SIP Ringing (192.0.2.2:SIP -> 192.0.2.1:?): Ringing Bert's
phone The ringing simply inplies that there's something sip aware
on Berts side, and that it's ringing his phone
3# SIP OK (192.0.2.2:SIP -> 192.0.2.1:?): Call accepted, I listen
on 192.0.2.2:2000 This OK means that the Bert took the phone off
hook, and thus accepted the call. It also informs Ernie that Bert
is awaiting his media data at port 2000
4# SIP ACK (192.0.2.1:? -> 192.0.2.2:SIP): All is fine, start
transmitting. ACK means the ports are accepted and the call can
start in the slected data ports on both sides.
5# DATA (192.0.2.1:? -> 192.0.2.2:2000 and 192.0.2.2:? ->
192.0.2.1:1000): Voice,image, video.. This is the actual data
being transmited.
In the above example, SIP is used successfully to establish a
communication, which includes negotiating the data ports for the
actual transmission. Unfortunatelly, this scheme will not work for
more complex setups.
Let's now consider one firewall in the data path, be it on Ernie's or
Bert's network, or elsewhere in the middle. We assume that the
Stiemerling, et al. Expires April 17, 2004 [Page 70]
Internet-Draft A NAT/FW NSIS NSLP October 2003
firewall is allowing traffic directed to the SIP port. As to the
rest of the ports, a typical setup involves outgoing connections
being allowed, and incoming connections being dropped, except for
those already established. That is, we allow packets to go out and
their replies to come in, but disable all other traffic.
In this case, the connection is as follows, for the case of a
firewall on Ernie's network:
Ernie(192.0.2.1) FW Bert(192.0.2.2)
| | |
| 1# SIP INVITE | |
+--------------------------------------->|
| | |
| | 2# SIP Ringing |
|<---------------------------------------+
| | |
| | 3# SIP OK | <-- Call accepted
|<---------------------------------------+
| | |
| 4# SIP ACK | |
+--------------------------------------->|
| | |
| 5# DATA | |
|=======================================>|
| |<=======================|
| | |
Notice how the SIP messages #1 and #4 traverse the firewall, because
they are outbound, and how 2# and 3# traverse it too, because they
are replies to the connection established at 1#.
Notice now how 5# can go outwards, but Bert can not go through the
firewall to reach Ernie's port 1000. The reason is the connection is
a new one, and the firewall won't allow it through.
Bert will now get media from Ernie, but Ernie is never going to get
anything from Bert. The call is thus considered unsuccessful. The
reason is that the application level port negotiation is never
acknowledge by the network-transport layer firewall, which doesn't
know what to expect. We would still face the same problem if the
connection used a SIP Proxy, for it would only translate names into
IP addresses.
Let us now assume that we indeed have an application layer firewall,
Stiemerling, et al. Expires April 17, 2004 [Page 71]
Internet-Draft A NAT/FW NSIS NSLP October 2003
be it by design, or because we load some sort of SIP module to it.
The previous case would now work, since the firewall can now
understand the packets going through it and open the necessary ports.
Still, we cannot assume that SIP signalization packets and the actual
data follow the same path. The following figure shows a likely
setup. FW+ stands for one or more firewalls:
SIP Signalization Path +-----+
/---------------->-----------| FW+ |-------\
| +-----+ |
+------+ +------+ +-----+
|Ernie |----|Router| |Bert |
+------+ +------+ +-----+
| Data Path +-----+ |
\---------------->-----------| FW+ |-------/
+-----+
The SIP packets with the information about the listening ports now
travels on the SIP Signalization path, and so the firewalls on that
path can read them. The Data, though, is traveling through the Data
path, and the firewalls in that path never get to see the Invite and
Ok packets. They are thus unable to open the ports.
Two issues are arisen here: first, we need on-path signalization
unless we already know the path our packets will take; a highly
unlikely situation in today's internet. Second, if we patch the
firewalls to understand SIP, we will provide any caller with a
hole-puncher for the firewall, since SIP is not provisioned with
proper authentication mechanism.
It is now clear that tight firewalls prevent SIP from successfully
working. There is still another obstacle: NATs.
NATs provide for a link between two different address spaces,
typically connecting a private range network to a public range one.
As a consequence, connections going from the inside (usually the
private range) are translated using the NAT's public interface
address, and the replies are routed back. The public side of the
network can only see the NATs public interface, and know nothing of
the private network inside. This means computers outside the NAT
won't be able to address computers inside the NAT.
Let us analyze the SIP example when Ernie is behind a NAT. The
following figure depicts a typical session:
Stiemerling, et al. Expires April 17, 2004 [Page 72]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Ernie(10.0.0.2) (10.0.0.1) NAT (192.0.2.1) Bert(192.0.2.2)
| | |
| 1# SIP INVITE | |
+--------------------------\ |
| |----------------->|
| | |
| | 2# SIP Ringing |
| /------------------+
|<-------------------------| |
| | |
| | 3# SIP OK | <-- Call accepted
| /------------------+
|<-------------------------| |
| | |
| 4# SIP ACK | |
+--------------------------\ |
| |----------------->|
| | |
| 5# DATA | |
|==========================\ |
| |=================>|
| | ?<=============|
| | |
The communication is analogous to the one in the previous examples,
except for the fact the NAT is rewriting the source address of the
packets as they traverse it.
For instance, packet 1# is going from 10.0.0.2:? towards
192.0.2.2:SIP. The NAT box intercepts the message and puts
192.0.2.1:? as the source address and port, with ? being a
dynamically picked port, which might be different from the original
one 1# used.
On the way back, Bert is replyinc to the source of the IP packet,
that is, 192.0.2.1, and so, when 2# reaches 192.0.2.1, the NAT know
it is a reply from 1#, because it established a NAT binding, and this
replaces the destination address, 192.0.2.1:? with 10.0.0.2:? and
forwards the packet inside the NAT.
As a result, Ernie never knows there is a NAT in his communication
path, since he sends and receives packets from 192.0.2.2 normally.
This means that the INVITE packet will tell Bert to send data back to
10.0.0.2, a private IP. Once the signalization is finished, and the
actual DATA transmission starts, Bert tries to connect to 10.0.0.2, a
private IP address, from the internet; The routers don't know how to
route this, and the packet is eventually dropped.
Stiemerling, et al. Expires April 17, 2004 [Page 73]
Internet-Draft A NAT/FW NSIS NSLP October 2003
One possible solution would be for Ernie to know the NAT exists, and
already indicate that it listens on 192.0.2.1, and not 10.0.0.2.
That, still would not work, since the NAT binding is not performed at
the NAT box.
A.2 Conclusions
The above examples display the inability to use standard SIP through
tight firewalls or NATs, and points at the necessity of a secure
on-path protocol to negotiate firewall pinholes and NAT bindings.
Stiemerling, et al. Expires April 17, 2004 [Page 74]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Appendix B. Ad-Hoc networks
Some forms of ad-hoc networks exist where trust in the network is not
justified. Figure Figure 29 mainly illustrates the problems of
malicious NSIS entities graphically:
+------------------------------------------+ +--------//
| Adhoc | | ISP
| Network | |
| regular data | |
| traffic by +---------+ | |
| node A |Malicious| | +-+--------+
| +-------------->+ Node +-----+///-->+ Firewall +-//
| ^ | 3 |===========>| 1 |
| | +---------+ injected +-+--------+
| | data traffic |
| | | |
| | | |
| +---+-----+ +---------+ | |
| + Node | | Node | | |
| | 1 | | 2 | | |
| +---------+ +---------+ | |
| ^ | +--------//
| | |
+----------+-------------------------------+
|
+--+---+
| Node |
| A |
+------+
Figure 29: Limits of packet filter security
An ad-hoc network consists of a number of nodes between the end host
(Node A) and the ISP to which Node A wants to get access. Although
Node A uses an authentication and key exchange protocol to create a
policy rule at the firewall 1 it is still possible for an untrusted
node (in this case Node 3) to inject data traffic which will pass
Firewall 1 since the data traffic is not authenticated. To prevent
this type of threat two approaches are possible. First, a
restrictive packet filter limits the capabilities of an adversary.
Finally, there is always the option of using data traffic protection.
Stiemerling, et al. Expires April 17, 2004 [Page 75]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Appendix C. Interworking of Security Mechanisms and NSIS NATFW NSLP
TBD
Stiemerling, et al. Expires April 17, 2004 [Page 76]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Appendix D. Solution approaches in case of missing authorization
D.1 Solution Approach: Local authorization from both end points
The first approach makes use of local authorization from both end
points. If Host A sends a signaling message toward the destination
to Middlebox 1 the message will perform the desired action in Network
A. Middlebox 1 establishes some state information and forwards the
signaling message towards Host B. Signaling message protection
between the two access networks might be difficult. A missing trust
relationship does not necessarily mean that no security association
establishment is possible. The lacking trust disallows Middlebox 1
(or indirectly Host A where the signaling message was initiated) to
create packet filters at Middlebox 2. We assume that the NSIS
signaling message is allowed to pass the firewall then it finally
reaches Host B. Due to the missing authorization no packet filter
specific state is created. The filters will be installed later after
receiving an authorization from Host B. When Host B returns a
confirmation or acknowledgement then Middlebox 2 treats it as an
authorization and finally triggers filter creation. The message is
then forwarded to Middlebox 1, where filters are either already
installed or require an additional confirmation. Finally the
signaling message is forwarded to Host A, which can be assured that
subsequent data traffic can be transmitted end-to-end from Host A to
Host B. The same procedure has to be applied again to signal
information for the other direction (Host B to Host A).
The following behavior has to be assumed in order for this approach
to be applicable:
1. Signaling messages must be allowed to pass firewalls along the
path.
2. NSIS signaling must operate in the described manner which could
be described as: Install where you have authorization - delay and
forward where you have no authorization.
This approach suffers from the following drawbacks:
1. Firewalls which block NSIS signaling from external networks or
nodes prevent a successful operation.
2. A full roundtrip is required to signal packet filter information.
The NSIS signaling message must therefore provide the capability
to route signaling message in both direction which might either
require state installation at nodes along the path (route
pinning) or a stateless version via record-route. Some risk of
DoS protection might exist.
Stiemerling, et al. Expires April 17, 2004 [Page 77]
Internet-Draft A NAT/FW NSIS NSLP October 2003
D.2 Solution Approach: Access Network-Only Signaling
The next approach is based on signaling packet filter information by
both hosts into the local access network only. An NSIS allows
specifying such a behavior by indicating the signaling endpoint with
the help of scoping (for example with domain name or a "local network
only" flag). Scoping means that the signaling message although
addressed to a particular destination IP address terminates somewhere
along the path. If packet filters for both directions have to be
installed then the signaling messages have to make packet filter
installations up- and downstream along the data path. Similar to
proposals in the area of QoS signaling some problems are likely to
occur. One such problem is that downstream signaling in general
causes problems because of asymmetric routes. In particular it is
difficult to determine the firewall where the downstream data traffic
will enter a network. The problem of triggering downstream
reservations is for example described in [12] . Another problem for
example is the placement of a firewall or NAT along the path other
than in the access network. This would prevent a successful data
exchange.
The following behavior has to be assumed in order for this approach
to be applicable:
1. It must be possible to trigger a signaling message exchange for a
downstream signaling message exchange at the firewall where the
data traffic enters the network.
2. No other firewalls or NATs are present along the path other than
in the access network.
This approach suffers from the following drawbacks:
1. To signal policy rules only within the access network (by both
end-points) has a number of disadvantage and challenges (see for
example [12] ). The complex message processing caused by this
approach strongly argues against it although it might sound
simple (and even might be simple in restricted environments).
2. Complex topologies might lead to ineffective policy rules (i.e.
data traffic hits firewalls hits wrong firewalls).
D.3 Solution Approach: Authorization Tokens
The last approach is based on some exchanged authorization tokens
which are created by an authorized entity (such as the PDP) or by a
trusted third party. Both end hosts need to exchange these tokens
Stiemerling, et al. Expires April 17, 2004 [Page 78]
Internet-Draft A NAT/FW NSIS NSLP October 2003
with protocols such as SIP or HTTP since these protocols are likely
to be allowed to bypass the firewall. The basic idea of this
approach is to provide an end host, which requests access to the
network, with credentials (referred as authorization tokens). These
tokens have to possess some properties, namely:
1. They have to be restrictive by including lifetimes, source and
destination identifiers, usage indication and more.
2. They have to provide basic replay protection to prevent
unauthorized reuse.
3. The have be cryptographically protected to prevent manipulations.
4. There has to be a mechanism to dynamically create them for a
specific reason and to distribute them to the end points.
5. It has to be possible to exchange tokens via a trusted third part
in cases where no direct communication between the end hosts is
possible (due to NAT).
6. The token can be created locally at the network or by a trusted
third party.
An example of a possible signaling communication could have the
following structure: After exchanging the tokens between the two end
hosts. Host A would include the received authorization token to the
signaling message for Network B. When the signaling message arrives
at Middlebox 2 then the token is verified by the token-creating
entity. In order to prevent parties from reusing the token
timestamps (e.g. token creation, token lifetime, etc.) have to be
included. Adding IP address information about Host A would create
difficulties in relationship with NATs. Information about Host B
might be possible to include in order to limit attacks where a token
is lost and reused by a different host for a different purpose. The
goal is to restrict the usage of the token for a specific session.
The content of the token only needs to be verified by the originator
of the token since it only has to be verified locally. Since
authorization needs to be linked to the authorized actions, which
have to be performed on the packets matching the packet filter, the
token may include the associated action or a reference to it. The
following behavior has to be assumed in order for this approach to be
applicable:
1. The exchange of authorization tokens between end-systems must be
possible. These protocols must be allowed to pass the firewalls.
2. An end-system must be able to request such an authorization token
Stiemerling, et al. Expires April 17, 2004 [Page 79]
Internet-Draft A NAT/FW NSIS NSLP October 2003
at some entity in the local network or at a trusted third party.
This approach suffers from the following drawback:
1. Possibly an additional protocol is required for an end host to
request an authorization token from an entity in the local
network.
Stiemerling, et al. Expires April 17, 2004 [Page 80]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Appendix E. Acknowledgements
We would like to acknowledge Vishal Sankhla and Joao Girao for their
input to this draft.
Stiemerling, et al. Expires April 17, 2004 [Page 81]
Internet-Draft A NAT/FW NSIS NSLP October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Stiemerling, et al. Expires April 17, 2004 [Page 82]
Internet-Draft A NAT/FW NSIS NSLP October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stiemerling, et al. Expires April 17, 2004 [Page 83]
