NSIS H. Tschofenig
Internet-Draft Siemens
Expires: January 10, 2005 July 12, 2004
Path-coupled NAT/Firewall Signaling Security Problems
draft-tschofenig-nsis-natfw-security-problems-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This draft raises some of the open issues in dealing with
path-coupled NAT/Firewall signaling and tries to raise awareness of
the security issues beyond the NSIS working group. These issues need
to be addressed in order to proceed with the security architecture
for NAT/Firewall signaling.
Tschofenig Expires January 10, 2005 [Page 1]
Internet-Draft NATFW Signaling Security Problems July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. High-level Protocol Overview . . . . . . . . . . . . . . . . . 6
2.1 GIMPS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 9
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Security for NAT vs. Firewall Traversal . . . . . . . . . 12
3.2 Which Security Protection at Which Layer? . . . . . . . . 13
3.3 Different Requirements for Different Parts of the
Network . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Mobility, Sender Invariance, and Authorization Problems . 14
3.5 Dependencies among QoS, NAT, and Firewall Signaling . . . 15
3.6 End-to-end security . . . . . . . . . . . . . . . . . . . 16
3.7 Asymmetry of Security Protocols . . . . . . . . . . . . . 18
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 24
8.2 Informative References . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 27
Tschofenig Expires January 10, 2005 [Page 2]
Internet-Draft NATFW Signaling Security Problems July 2004
1. Introduction
The NSIS working group is currently working on three protocols: a
lower-layer transport mechanism (NTLP) and two signaling applications
(NSLPs). The first signaling application deals with QoS signaling
and the other one with NAT/Firewall signaling. The lower-layer
transport only carries application-specific payloads between a number
of NSIS aware nodes along the path in the forward and the backward
direction.
The work on path-coupled QoS signaling is the result of efforts on
RSVP. The work on path-coupled NAT/Firewall signaling has its origin
in the Midcom working group where NAT and Firewall signaling has to
cope with network topology problems. The TIST [refs.tist] proposal
led to a BOF and the work was moved to the NSIS working group. The
approach taken by the Midcom working group assumes that the NAT/
Firewall is known when the signaling protocol starts and that it can
be addressed by the entity controlling the midddlebox. A strong
trust relationship between the middlebox and the entity controlling
the middlebox is assumed. In more complex topologies with multiple
NATs and Firewalls the order of these devices need to be considered
with respect to the data flow traversing them. Additionally, the
entity controlling these devices need to know which device will be
hit by which data flow. This often requires some knowledge of the
topology.
The NSIS approach is different in the sense that this knowledge about
the topology is moved to a discovery mechanism, and it becomes the
responsibility of the end host to start signaling.
This document is organized as follows: Section 1 describes what
problem the NAT/Firewall NSLP is going to solve. Section 2 presents
a basic protocol model and a high-level description of the messages
transmitted, as suggested in [I-D.iab-model]. Section 3 lists
challenges and open issues.
The approach of path-coupled signaling has some implications:
o First, some application logic needs to be added to the end host to
control the creation of the NAT binding or Firewall pinholing on a
per-flow basis. NSIS allows a proxy in the network to be used to
perform this operation on behalf of the end host, but some
additional security considerations need to be taken into account.
o Due to the soft-state principle it is necessary to refresh the
state continual. Otherwise, the established state would be
deleted.
o Path-coupled signaling for each direction is required to deal with
routing asymmetry.
Tschofenig Expires January 10, 2005 [Page 3]
Internet-Draft NATFW Signaling Security Problems July 2004
o Changes to the routing path (e.g., due to mobility) require
periodic re-discovery. The refresh partially addresses this
issue, but the effect on the communication in the NAT/Firewall
signaling case is more devastating, since data cannot flow to one
of the end hosts if packet filters are not established at
Firewalls along the path.
o The impression exists that Firewalls and NATs are commonly used
today and in a way that requires path-coupled signaling. With
NATs, a number of protocols deal with creating NAT bindings. but
mostly without incorporating security mechanisms between the
signaling end points and the NAT(s). With Firewalls the situation
is quite different, since deployment heavily depends on the
scenario and on the environment. Furthermore, with increasing
end-to-end encryption and with protocols heavily overloading HTTP
and SIP, it is difficult to estimate the future of traditional,
packet-filter-based firewalls (and also for stateful packet
filtering firewalls).
Security considerations for NAT and Firewall traversal need to be
treated separately.
In the past, mainly two approaches have been used for establishing
NAT bindings:
These NAT bindings are typically used to allow data traffic from
the outside to be forwarded to a specific host on the inside.
Dynamic NAT creation can be categorized into one of the following
three categories:
* Implicit creation by outbound-initiated communications whereby
the translated address and port is selected from a configured
address and port pool.
* Explicit creation by the Application Layer Gateway(ALG) either
via an API call if the NAT and the ALG are co-located or
otherwise via a separate protocol.
* Separate signaling protocols that requests the creation of a
NAT binding
An alternative classification is by the trigger for the creation of a
NAT binding. In many cases an outbound data packet itself is used to
cause the allocation of a NAT binding. Alternatively, a signaling
protocol can be used to accomplish the same goal by directly
addressing the NAT itself. The Midcom and the NSIS working groups
are trying to develop protocols of the latter category.
There is little doubt that a user needs to have sufficient rights (or
be authorized) to create packet filters at a Firewall. The Midcom
working group addressed this aspect in a convenient way, since trust
between the middlebox and the entity controlling the middlebox is
Tschofenig Expires January 10, 2005 [Page 4]
Internet-Draft NATFW Signaling Security Problems July 2004
assumed. In most scenarios these two entities belong to the same
administrative domain. Another common 'firewall' uses cryptographic
data protection with IPsec. Protocols for establishing IPsec
security associations already exists with IKE [RFC2409], KINK
[I-D.ietf-kink-kink] and IKEv2 [I-D.ietf-ipsec-ikev2], and hence
there is little motivation to focus on these cases.
Tschofenig Expires January 10, 2005 [Page 5]
Internet-Draft NATFW Signaling Security Problems July 2004
2. High-level Protocol Overview
NSIS decided to use a two-layer architecture with one lower-layer
transport (NTLP) and multiple upper-layer application signaling
protocols (NSLPs). The NTLP itself is meaningless if it is not used
in conjunction with an upper-layer NSLP. An upper layer protocol,
such as the NAT/Firewall NSLP, cannot work without the lower layer.
The layering provides a functional split and has to ensure that
future applications can be easily integrated without modifying other
parts of the protocol.
This two-layer architecture is explained and the relationship between
the GIMPS and the NTLP is described in [I-D.ietf-nsis-fw]. For this
document the difference between the GIMPS and the NTLP is not too
important.
This section addresses the protocol functionality of the NAT/Firewall
NSLP and also the NTLP, since the former depends on the latter.
2.1 GIMPS
GIMPS (see [I-D.draft-ietf-nsis-ntlp]) establishes installed NTLP
"routing" state, which allows signaling messages to be routed
backwards along the same path. This is not possible without
installed state (or similar mechanisms such as record route) due to
routing asymmetry. This state is different from application-specific
state (such as QoS reservations).
GIMPS provides two ways to send signaling messages:
o The first is an RSVP-like signaling style with end-to-end
addressed messages. The end-to-end addressed message contains the
source and the destination IP addresses of the data flow. The
messages are intercepted along the path by NSIS nodes interested
in these messages (by using Router Alert Options). The GIMPS
specification refers to this as the Datagram mode (D-mode).
o The second mode (called Connection mode or C-mode) is used when
NSIS nodes are directly addressed. This mode assumes that the
discovery procedure has already finished (or the address of the
receiving node is known via other means) and information about the
node is already available.
From the previous description it might be apparent that an important
part of the NTLP is its discovery mechanism. Without knowing the
next NSIS aware node discovery (either implicit or explicit) is
necessary. Providing security for a discovery message is difficult,
particularly if standard security protocols should be used.
Combining discovery with signaling message delivery is, from a
Tschofenig Expires January 10, 2005 [Page 6]
Internet-Draft NATFW Signaling Security Problems July 2004
signaling point of view, faster, but security protection is a lot
harder. Currently, the GIMPS specification says that D-Mode does not
provide security protection. TLS and IPsec are suggested for C-Mode
message protection.
Figure 1 shows the explicit discovery mechanism. Because it is
assumed that an NSIS node is unaware of the topology, it is difficult
to protect the discovery procedure against all threats. For example,
the querying node might not be able to tell whether a responding node
is truly the next NSIS node along the path. Furthermore, the
querying node might not know the identity of the responding node and
hence authentication cannot provide a sufficient guarantee that this
node is an authorized NSIS node. Hence, some authorization mechanism
has to exist in the routing infrastructure and in the entire system
to ensure that nodes along the path act according to their prescribed
roles. Such mechanisms might not exist in ad hoc networks.
Unauthorized entities located along the path are able to harm NSIS
signaling and some NSIS applications, such as NAT/Firewall NSLP and
QoS NSLP.
As an example, an adversary along the path not authorized to
participate in NSIS signaling observes the NSIS signaling messages
and the subsequent data traffic. The adversary is able to learn
which IP traffic is allowed to pass the firewall and might learn
which QoS treatment a given flow will receive.
Tschofenig Expires January 10, 2005 [Page 7]
Internet-Draft NATFW Signaling Security Problems July 2004
+----------+ +----------+
| Querying | |Responding|
| Node | | Node |
+----------+ +----------+
GIMPS-query
---------------------->
(Query Cookie)
GIMPS-response
<----------------------
(Query Cookie,
Responder Cookie)
Final handshake
---------------------->
(Responder Cookie)
Figure 1: GIMPS discovery mechanism
The discovery mechanism shown in Figure 1 only presents the
high-level details. It allows the querying node to learn the IP
address of the responding node. Additional functionality, such as
discovering NSIS-unaware NATs between these two nodes is under
discussion.
The usage of two cookies is somewhat unusual and requires
explanation. The responder cookie is used to prevent denial of
service attacks in the classical sense as used by other protocols,
such as SCTP or IKE. The query cookie has to ensure that an
adversary does not redirect the discovery message to another NSIS
node. This is guaranteed by providing a cookie by the querying node
and by returning the same cookie in the response. This mechanism
prevents off-path adversaries from flooding the querying node with
GIMPS-responses. The querying node uses this cookie to match a
request with a pending response. Furthermore, transmitting the query
cookie from the responding node to the querying node after a security
association is established between the two ensures that the responder
has actually participated in the discovery exchange (i.e., the
discovery procedure is bound to the subsequent exchange).
Once the next NSIS node is known, a messaging association can be
established between these two nodes using C-mode. The same procedure
is repeated again and again for the C-Mode until the last GIMPS node
is reached. Note that the NSIS signaling does not necessarily need
to terminate at the data flow receiver. The data flow receiver might
not be NSIS capable, and some other node along the path (e.g., the
access router) might act on his behalf.
Tschofenig Expires January 10, 2005 [Page 8]
Internet-Draft NATFW Signaling Security Problems July 2004
The GIMPS protocol itself is only executed between NSIS peers, and
they also implement the signaling application. There are no GIMPS
nodes along the path that do not contain an upper layer signaling
application. This is, both an architectural principle and a
technical protocol design simplification. As with other protocols,
such as Diameter, security mechanisms at the "lower-layer" prevent
certain attacks at both layers between two NSIS nodes and allow
standard channel security mechanisms to be used.
2.2 NAT/Firewall NSLP
Currently, the NAT/Firewall NSLP description (see
[I-D.ietf-nsis-nslp-natfw]) mostly analyses the different problems
and challenges, describes trust relationships and motivates the
different scenarios where the protocol is used.
Unlike other protocols, little information is actually carried in the
NSLP beyond the information carried at the NTLP: information about a
created NAT binding, as well as lifetime and signaling information
(such as protocol headers and error messages). Information about the
flow identifier and the session identifier is carried in the NTLP.
Currently no additional security payloads at the NSLP layer are
specified.
The most valuable part of these information elements is the flow
identifier (in most cases a 5-tuple but in some cases not completely
known to the sender and/or the receiver at the time of transmitting a
message). As an example, a data sender might indicate which source
port, protocol type and source IP address has to be used, but it
cannot know the public IP address, of the NAT binding yet since it is
up to the protocol execution to establish and learn this NAT binding.
It is useful to distinguish between two signaling modes:
The first mode (CREATE) is the traditional way of creating a NAT
binding by sending a message from the data sender along the path
to the data receiver. Figure 2 shows a message exchange for this
signaling mode.
The second mode (RESERVE) is used when a data receiver is behind a
NAT and wants to establish a NAT binding to allow incoming data
traffic. Figure 3 shows this mode. It was necessary to introduce
this mode, because path-coupled signaling in the traditional sense
is not immediately applicable.
Tschofenig Expires January 10, 2005 [Page 9]
Internet-Draft NATFW Signaling Security Problems July 2004
Private Address Public Address
+----------+ Space +----------+ Space +----------+
| Data | | NAT | | Data |
| Sender | | | | Receiver |
+----------+ +----------+ +----------+
| | |
| Create | Create |
|----------------------------->+--------------------------->|
| | |
| Succeeded/Error | Succeeded/Error |
|<-----------------------------+<---------------------------|
| | |
============================================================>
Direction of data traffic
Figure 2: CREATE Mode
With the CREATE mode shown in Figure 2 the data sender (which happens
to be the NSIS initiator in this case) sends a message to request a
NAT binding to be created. The message is targeted to the data
receiver (or even to any node in the Internet), which returns a
success or failure message. The data sender learns about the new NAT
binding, as a consequence.
Public Internet Private Address
+----------+ +----------+ Space +----------+
| Data | | NAT | | Data |
| Sender | | | | Receiver |
+----------+ +----------+ +----------+
| | |
| | Reserve Reserve |
| |<---------------------------|
| | |
| | Return ext addr/Error |
| |--------------------------->|
| | |
============================================================>
Direction of data traffic
Figure 3: RESERVE Mode
With the RESERVE mode shown in Figure 3 the data receiver behind a
NAT creates a NAT binding. This allows data traffic from a node on
the Internet to be received. Please note that the RESERVE message is
sent in the opposite direction of the data traffic. The RESERVE mode
is, in some sense, not path-coupled, since the data receiver starts
Tschofenig Expires January 10, 2005 [Page 10]
Internet-Draft NATFW Signaling Security Problems July 2004
signaling but, on the other hand, the data sender will send the data
traffic to the IP address (and port) allocated at the NAT.
It should be noted that in [I-D.ietf-nsis-fw] the RESERVE mode
currently requires an additional CREATE message from the data sender
to the NAT to activate the binding. This issue is still in
discussion.
Tschofenig Expires January 10, 2005 [Page 11]
Internet-Draft NATFW Signaling Security Problems July 2004
3. Challenges
This section highlights some of the challenges discovered. Further
details can be found in NAT/Firewall NSlP [I-D.ietf-nsis-nslp-natfw].
3.1 Security for NAT vs. Firewall Traversal
As we tried to motivate in Section 1, the creation of NAT bindings is
security sensitive but not to the same degree as firewall traversal.
Existing proposals for NAT traversal typically do not use a signaling
protocol. Instead regular data traffic from the internal to the
external network is used. This is also true for IPv4/IPv6 transition
mechanisms in case of automatic tunneling. A typical threat against
a NAT device is flooding by an adversary that allocates a large
number of NAT bindings. If the dynamically allocated NAT bindings
are selected from a limited pool of available bindings (in particular
if a NAT instead of a NAPT is used) then this might be a real threat.
For a NAPT this threat does not seem to be dangerous enough to
require special purpose signaling protocols. As a minor note, STUN
[RFC3489] and TURN [I-D.rosenberg-midcom-turn] are signaling
protocols, but they do not provide additional security for the NAT
device when allocating NAT bindings.
If security should be provided for creating NAT bindings, then
authentication might be useful in cases of misuse (e.g., allocation
of too many NAT bindings). More interesting is, however,
authorization. In most networks today every node is automatically
authorized to create NAT bindings. To support mobility it is
possible either to allocate a new NAT binding (approach used today)
or to update the state. Updating a NAT binding is security
sensitive, since an adversary can modify an existing NAT binding in
order to redirect traffic to a third-party victim, to the adversary
itself, or even to a black hole. Flooding a third-party entity might
be particularly dangerous if the data sender is streaming a large
amount of data (possibly over a wireless interface).
Since a NAT binding has a life-time, it is necessary to refresh it
continually. This mechanism provides a self-healing property, since
a new data packet (or a new signaling message) causes either the
creation of a new binding or the refresh of the old one.
In contrast, firewall pinholing is more security sensitive. Creating
or deleting packet filters might easily violate the security policy
of a network and might allow an adversary to mount a number of
attacks. Only authorized entities are typically allowed to modify
packet filters. This requires proper authorization. Authentication
will also most like be required, since typically the authenticated
identity is used for computing the authorization decision. As
Tschofenig Expires January 10, 2005 [Page 12]
Internet-Draft NATFW Signaling Security Problems July 2004
described in Figure 5, this might lead to problems with path-coupled
signaling.
3.2 Which Security Protection at Which Layer?
An obvious question is which security mechanisms should be provided
at which layers. The choice impacts the performance and deployment.
The working group is currently in the stage of investigating the
threats, trust relationships, and security properties of the two
NSLPs to evaluate the impact on the NTLP.
Figure 4 shows the different layers. Providing security protection
at both layers between the neighboring entities is not valuable if no
additional functionality is provided. Note that if the protection is
provided between different entities (non-neighboring NSIS nodes) then
such protection is justified. Recent developments in Diameter with
regard to CMS [I-D.ietf-aaa-diameter-cms-sec] have shown that there
is a tendency not to use additional upper-layer security mechanisms
if lower-layer security mechanisms are provided, even if the security
properties are different. The same can also be observed in other
protocols, such as SIP or even in RSVP where the preferred choice is
the Integrity Object and not the mechanisms provided with the
Identity Objects. Public-key-based authentication, for example,
offered with the Identity Object is not used.
+------+ +------+
| NE | | NE |
|+----+| |+----+|
||NSLP|| NSLP Security ||NSLP||
|| 1 || - - - - - - - - - - - - - || 1 ||
|+----+| |+----+|
| || | | || |
|+----+| NTLP Security |+----+|
====||NTLP||============================||NTLP||====
|+----+| |+----+|
+------+ +------+
Figure 4: Security at Different Layers
3.3 Different Requirements for Different Parts of the Network
Since NSIS protocols are executed in an end-to-end fashion with some
(and possibly many) NSIS nodes along the path, it is important to
consider a large number of usage environments. These environments
might impose different requirements on the security protection. At a
high level, we can distinguish between intra-domain communication
Tschofenig Expires January 10, 2005 [Page 13]
Internet-Draft NATFW Signaling Security Problems July 2004
(communication within an administrative domain), inter-domain
communication (communication between administrative domains) and
finally the communication with the end hosts and the attached
network. NSIS, unlike RSVP, does not necessarily need to be executed
between the true data sender and data receiver. It is possible to
use NSIS within a single administrative domain only. The impact on
security of using NSIS in such diverse environments is that different
security protocols, not just one, need to be supported. Some
architectures use Kerberos, others rely on special authentication and
key exchange protocols, and again others rely on public-key-based
mechanisms.
It is highly desirable to provide some flexibility for the
authentication and key exchange protocol.
For some NSLPs, such as a quality of service signaling protocol, it
is desireable to execute the authorization procedure at an entity
where the user is known (typically its home network). This typically
implies that the authentication and key exchange protocol is also
terminated at the same entity.
3.4 Mobility, Sender Invariance, and Authorization Problems
The NAT/Firewall NSLP establishes state at possibly several entities
between the NSIS initiator and the NSIS responder. Providing
authentication of the signaling initiator to each individual node
along the path might be possible but not particularly useful, since
the initiator is most likely unknown to some middlebox along the
path. Hence, authentication per se does not solve the security
problem.
If authentication is only provided to some entities along the path
(most likely to the neighboring NSIS nodes), then information about
the initiator of the session is known to some NSIS nodes (except for
the session identifier, which does not change along the path and over
the lifetime of a session). Now, with the introduction of mobility
it might be possible that intermediate NSIS nodes need some assurance
that a particular sender is the owner of a session. No other entity
should be allowed to modify state since this would allow certain
attacks. In some respect this issue is similar to the authorization
property in Mobile IP where the mobility binding needs to be
protected against unauthorized modifications.
It seems that the property of "sender Invariance" is required in this
case: "A party is assured that the source of the communication has
remained the same as the one that started the communication, although
the actual identity of the source is not important to the recipient."
Tschofenig Expires January 10, 2005 [Page 14]
Internet-Draft NATFW Signaling Security Problems July 2004
The interactions among security, mobility, session ownership, and
authorization are subject to ongoing discussions in
[I-D.manyfolks-signaling-protocol-mobility].
3.5 Dependencies among QoS, NAT, and Firewall Signaling
Routing asymmetry has to be considered for firewalls but is not
applicable to NAT-only signaling. In the presence of NATs, we are
always sure that the forward path and the backward path are same with
regard to the NAT boxes, since the NAT forces the IP packets to flow
through these devices. But, in the presence of firewalls, the
forward and the backward routes may be different. A solution needs
to focus on the more difficult case where the routes are different.
In the forward direction some rules are established in the traversed
firewalls. In the reverse direction, if a different route is taken,
the packets might be blocked by some other firewall.
It is important to study the relationship between NSIS signaling and
other application protocols (such as SIP) and also between different
NSIS signaling applications themselves. Different NATs and firewalls
can be found along the path, and the worst case needs to be assumed.
As we argue in NAT-FW [I-D.ietf-nsis-nslp-natfw], it is always
possible with mobility that an end host finds itself located behind a
NAT. Before NSIS can start, the NSIS initiator needs to know the
destination IP address, since this is an integral part of
path-coupled signaling. This might, however, already assume some
application layer signaling exchange. The IP address information
exchanged during this exchange might, however, be wrong due to the
presence of a NAT. In some scenarios (e.g., receiver behind a NAT)
NSIS signaling might need to start beforehand. With NSIS QoS
signaling it is also necessary to avoid breaking this type of
signaling application. The NSIS NAT/Firewall NSLP does not aim to
learn topology information but rather to create NAT bindings and
firewall pinholes and to make information about the NAT binding
available to the end host. In a short memo on NAT handling in NSIS
(see [nat-memo]) we argue that it is necessary to incorporate a
mechanisms for learning the presence of NSIS unaware nodes into the
GIMPS discovery procedure. Additionally, it is necessary to modify
the flow identifier of the QoS signaling message at the corresponding
NAT device along the path to reflect the address change. An NSIS
initiator should not need to know where this address translation
takes place; this would require topology information. Providing the
necessary flow identifier modification in addition to the
installation of a QoS reservation would be useful.
One question is therefore how much NAT handling needs to be
incorporated into the NTLP and into every NSLP to support proper
signaling behavior. If NAT handling is added to the QoS signaling,
Tschofenig Expires January 10, 2005 [Page 15]
Internet-Draft NATFW Signaling Security Problems July 2004
then it automatically inherits the authorization applied to QoS
signaling. Should this procedure be extended to Firewall signaling?
Does the right to make a QoS reservation imply the right to traverse
the firewall?
3.6 End-to-end security
Securing the communication between neighboring NAT/FW NSLPs with a
chain of trust is a convenient assumption that allows simplified
signaling message processing. However, it might not always be
applicable, especially between two arbitrary networks. We assume
that NATs and firewalls are typically located in the access networks
and are typically not found in the core network. Hence, two
observations follow:
o The two access networks (and the firewalls/NATs in these networks)
do not trust each other or they might not even know of each other.
o The end host might have a trust relationship with the local access
network that allows it to create firewall pinholes. However, it
cannot be assumed that the end host of one network is able to
create packet filters at another network. In the example of
Figure 5 Host A is not authorized to create pinholes at Middlebox
2. A trust relationship exists only between Host B and Middlebox
2. This scenario represents a scenario in which two employees of
two companies want to communicate through their corporate network
firewalls. Company B trusts it own employees but not employees of
company A.
In [I-D.ietf-nsis-nslp-natfw] we describe three possible approaches
to tackle this problem. None of these three approaches is without
drawbacks. We have chosen the one approach that assumes the
signaling message is sent end-to-end and each end host contributes
its part to the authorization decision. Furthermore, we have to
assume that the NSIS signaling message is allowed to bypass the
firewall (without installing a packet filter at this stage of the
protocol) to reach the other end host.
Based on Figure 5 the authorization steps can be described as
follows: Host A starts with the NSIS signaling message exchange and
has to authenticate itself to Middlebox 1. Middlebox 1 authorizes
Host A to create a pinhole based on the existing trust relationship.
Then the signaling message is forwarded along the path and
intercepted by Middlebox 2. No trust relationship between
Middleboxes 1 and 2 or between Host A and Middlebox 2 exists. Hence,
Middlebox 2 does not authorize the pinhole creation. For more
restrictive firewalls an error message is returned to Host A, but in
our scenario the NSIS signaling message is forwarded to Host B ( the
final destination of the signaling message exchange). Host B
Tschofenig Expires January 10, 2005 [Page 16]
Internet-Draft NATFW Signaling Security Problems July 2004
verifies that the signaling message is provided from a trusted
device, might already expect an incoming message based on some
application layer signaling exchange with Host A, and returns a
response message. Middlebox 2 authorizes Host B's request for
pinhole creation due to the existing trust relationship. The message
travels back to Host A, which receives a positive confirmation that
the signaling message exchange is successful. Host A can start
transmitting data packets.
Please note that if Middlebox 2 is actually a NAT (instead of a
firewall) then the scenario for a receiver behind a NAT is
applicable, which allows Host B to perform signaling locally without
the above-described complications. This is one of the other
solutions described in [I-D.ietf-nsis-nslp-natfw].
+---------------------+ +-----------------------+
| Network A | Internet | Network B |
| +---------+ +---------+ |
| +---->+ Middle- +<------------>+ Middle- +<----+ |
| | ...>| box 1 | | box 2 |<....| |
| | . +---------+ +---------+ .| |
| | . | | .| |
| | . | | .| |
| | . | | .| |
| v v | | vv |
| +--+-+-+ | | +--+---+ |
| | Host | | | | Host | |
| | A | | | | B | |
| +------+ | | +------+ |
+---------------------+ +-----------------------+
-----: NSIS Communication
.....: Trust Relationship
Figure 5: Authorization Problems
Without a proper binding of the NSIS to application signaling , Host
B might suddenly receive an NSIS signaling message that indicates a
firewall pinhole has to be created. Host B does not know which end
host requested this NAT binding nor for which reason. Hence it might
be reasonable to think about providing end-to-end security (via a
binding between NSIS signaling and the application signaling) as an
option to provide the receiving node stronger guarantees about the
entity requesting certain actions. It has to be noted that other
NSIS signaling scenarios in which intermediate nodes start (or
terminate) NSIS signaling on behalf of the end hosts might be much
more difficult to deploy along with end-to-end security.
Tschofenig Expires January 10, 2005 [Page 17]
Internet-Draft NATFW Signaling Security Problems July 2004
The main questions raised by this section are whether the described
observations are correct and whether it seems possible to make the
assumption that an NSIS signaling message be allowed to traverse the
packet filter firewall. Furthermore, it needs to be studied whether
end-to-end security provides better properties.
It is worth noting that the observation such a need of this
application layer signaling to NSIS signaling binding is raised in
[I-D.aoun-nsis-nslp-natfw-migration].
3.7 Asymmetry of Security Protocols
Some security protocols operate asymmetrically, which leads to
unpleasant consequences for the NSIS protocol suite. The Transport
Layer Security protocol (TLS) [RFC2246], IKEv2
[I-D.ietf-ipsec-ikev2], and also custom security protocols (such as
those provided with RSVP Identity Representation and, for example,
Kerberos [RFC3182]). NAT/Firewall NSLP signaling messages travel
along a path between the NSIS initiator and the NSIS responder
containing a number of entities that act in different roles. Due to
the routing asymmetry it is necessary to start signaling from both
end hosts (one signaling exchange for each data flow direction). In
IKEv2 the security properties of the initiator and the responder are
different with respect to denial of service protection and support
for the Extensible Authentication Protocol (EAP)
[I-D.ietf-eap-rfc2284bis]. This is also the case if an end host
wants run TLS with unilateral authentication (NSIS entity in the
network to the end host) with upper layer client-side authentication.
This type of exchange might be typical for QoS signaling, since
authorization has to be executed at entities other than those
executing the security protocol. From a deployment point of view it
is simpler to have public key based authentication of the network to
the user than to support a client-side PKI. Such a client-side PKI
is, however, necessary when the roles are reversed. Figure 6 shows
this problem graphically. Unfortunately, TLS cannot reverse its
roles and cannot reuse the session cache for the reverse direction.
This problem was also observed in the context of SIP, where
[I-D.ietf-sip-connect-reuse] provides a solution to reuse an
established TCP or TLS connection that was established based on a SIP
REGISTER before a SIP INVITE (or similar message) is used. NSIS,
however, has no provision to support separate 'registration' and a
'end-to-end' signaling message exchanges due to the path-coupled
property.
Tschofenig Expires January 10, 2005 [Page 18]
Internet-Draft NATFW Signaling Security Problems July 2004
+---------------------+ +-----------------------+
| Network A | Internet | Network B |
| +---------+ +---------+ |
| +---->+ NSIS +------------->+ NSIS +-----+ |
| | | Entity | | Entity | | |
| | | B | | C | | |
| | +---------+ +---------+ | |
| | | | | |
| | | | | |
| | | | v |
| +--+---+ | | +--+---+ |
| | NSIS | | | | NSIS | |
+--+Entity+-----------+ +------------+Entity+---+
| A | TLS server TLS client| D |
+--+---+ +--+---+
^ |
| v
+-----+-------+ +-----+-------+
| NSIS | TLS TLS | NSIS |
| Initiator X | client server | Responder Y |
+-------------+ +-------------+
Figure 6: Problems with Asymmetric Protocols
Tschofenig Expires January 10, 2005 [Page 19]
Internet-Draft NATFW Signaling Security Problems July 2004
4. Conclusion
This section summarizes and reiterates a few questions addressed in
this document:
o Is it useful to separate the security aspects for NAT and firewall
signaling?
o To what extend is end-to-end security important?
o How can specific authorization problems be addressed?
o What can be done with regard to the properties of asymmetric
security protocols?
o Are the proposals in [I-D.tschofenig-nsis-sid] adequate to address
the sender-invariance property for mobility scenarios? This
document, for example describes how to reuse concepts like
hash-chains and the Purpose-Built Key mechanism
[I-D.bradner-pbk-frame] to provide a mobility solution without a
global PKI.
Tschofenig Expires January 10, 2005 [Page 20]
Internet-Draft NATFW Signaling Security Problems July 2004
5. Security Considerations
This entire document addresses security issues of path-coupled NAT/
Firewall signaling. The main intention is to solicit feedback and
comments from the community at an early stage of the protocol
development.
Tschofenig Expires January 10, 2005 [Page 21]
Internet-Draft NATFW Signaling Security Problems July 2004
6. Contributors
The author would like to thank Richard Graveman for his detailed
review.
Tschofenig Expires January 10, 2005 [Page 22]
Internet-Draft NATFW Signaling Security Problems July 2004
7. Acknowledgements
The author would like to thank Cedric Aoun, Marcus Brunner, Srinath
Thiruvengadam, Martin Stiemerling and Miquel Martin for their time to
discuss many NAT/Firewall related issues.
Tschofenig Expires January 10, 2005 [Page 23]
Internet-Draft NATFW Signaling Security Problems July 2004
8. References
8.1 Normative References
[I-D.draft-ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling",
draft-draft-ietf-nsis-ntlp-00 (work in progress), October
2003, <reference.I-D.draft-ietf-nsis-ntlp.xml>.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-02 (work in progress), May
2004, <reference.I-D.ietf-nsis-nslp-natfw.xml>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[draft-tschofenig-nsis-sid]
Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A.
and X. Fu, "Security Implications of the Session
Identifier", June 2003.
8.2 Informative References
[I-D.aoun-nsis-nslp-natfw-migration]
Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H.
Tschofenig, "NAT/Firewall NSLP Migration Considerations",
draft-aoun-nsis-nslp-natfw-migration-01 (work in
progress), February 2004,
<reference.I-D.aoun-nsis-nslp-natfw-migration.xml>.
[I-D.bradner-pbk-frame]
Bradner, S., Mankin, A. and J. Schiller, "A Framework for
Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06
(work in progress), June 2003,
<reference.I-D.bradner-pbk-frame.xml>.
[I-D.iab-model]
Rescorla, E., "Writing Protocol Models",
draft-iab-model-01 (work in progress), May 2004,
<reference.I-D.iab-model.xml>.
[I-D.ietf-aaa-diameter-cms-sec]
Calhoun, P., Farrell, S. and W. Bulley, "Diameter CMS
Security Application", draft-ietf-aaa-diameter-cms-sec-04
(work in progress), March 2002,
Tschofenig Expires January 10, 2005 [Page 24]
Internet-Draft NATFW Signaling Security Problems July 2004
<reference.I-D.ietf-aaa-diameter-cms-sec.xml>.
[I-D.ietf-eap-rfc2284bis]
Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-07 (work in progress), December
2003.
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-12 (work in progress), January
2004, <reference.I-D.ietf-ipsec-ikev2.xml>.
[I-D.ietf-kink-kink]
Thomas, M. and J. Vilhuber, "Kerberized Internet
Negotiation of Keys (KINK)", draft-ietf-kink-kink-05 (work
in progress), January 2003,
<reference.I-D.ietf-kink-kink.xml>.
[I-D.ietf-nsis-fw]
Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-05 (work in progress), October 2003,
<reference.I-D.ietf-nsis-fw.xml>.
[I-D.ietf-nsis-qos-nslp]
Bosch, S., "NSLP for Quality-of-Service signaling",
draft-ietf-nsis-qos-nslp-01 (work in progress), October
2003, <reference.I-D.ietf-nsis-qos-nslp.xml>.
[I-D.ietf-sip-connect-reuse]
Mahy, R., "Connection Reuse in the Session Initiation
Protocol (SIP)", draft-ietf-sip-connect-reuse-01 (work in
progress), February 2004,
<reference.I-D.ietf-sip-connect-reuse.xml>.
[I-D.manyfolks-signaling-protocol-mobility]
Bless, R., "Mobility and Internet Signaling Protocols",
draft-manyfolks-signaling-protocol-mobility-00 (work in
progress), January 2004,
<reference.I-D.manyfolks-signaling-protocol-mobility.xml>.
[I-D.rosenberg-midcom-turn]
Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-04 (work in progress),
February 2004, <reference.I-D.rosenberg-midcom-turn.xml>.
[I-D.tschofenig-nsis-sid]
Tschofenig, H., "Security Implications of the Session
Tschofenig Expires January 10, 2005 [Page 25]
Internet-Draft NATFW Signaling Security Problems July 2004
Identifier", draft-tschofenig-nsis-sid-00 (work in
progress), June 2003,
<reference.I-D.tschofenig-nsis-sid.xml>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999, <reference.RFC.2246.xml>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998, <reference.RFC.2409.xml>.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001, <reference.RFC.3182.xml>.
[RFC3489] 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, <reference.RFC.3489.xml>.
[nat-memo]
Tschofenig, H., "Memo about NSIS NAT Handling, available
at: http://www.tschofenig.com/drafts/NSIS-NAT-Handling.txt
(Feb. 2004)", February 2004, <reference.nat-memo>.
[refs.tist]
Shore, M., "The TIST (Topology-Insensitive Service
Traversal) Protocol", DRAFT draft-shore-tist-prot-00.txt,
May 2002.
Author's Address
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Tschofenig Expires January 10, 2005 [Page 26]
Internet-Draft NATFW Signaling Security Problems July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig Expires January 10, 2005 [Page 27]