NSIS Working Group C. Aoun
Internet-Draft Nortel Networks
Expires: January 17, 2005 H. Tschofenig
Siemens
M. Stiemerling
NEC
July 19, 2004
NATFW NSLP Migration Considerations
draft-aoun-nsis-nslp-natfw-migration-02
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 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document discusses migration issues towards NSIS NAT/FW NSLP
enabled NATs and Firewalls. In particular traversal of NSIS unaware
NATs and NSIS proxy scenarios are addressed. This document will
serve as input to the NSIS NATFW NSLP document.
Aoun, et al. Expires January 17, 2005 [Page 1]
Internet-Draft NATFW NSLP Migration July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Traversal of NSIS unaware NATs . . . . . . . . . . . . . . . . 5
3.1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Class 1 NAT Handling . . . . . . . . . . . . . . . . . . . 6
3.4 Class 2 NAT Handling . . . . . . . . . . . . . . . . . . . 6
3.5 Class 3 NAT Handling . . . . . . . . . . . . . . . . . . . 7
3.6 Class 4 NAT Handling . . . . . . . . . . . . . . . . . . . 9
3.7 Dealing with NSIS unaware NATs (Class 4 NAT Handling) . . 10
4. NSIS Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . 14
5. NSIS unaware Firewall Traversal . . . . . . . . . . . . . . . 17
6. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . . . 18
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
11.2 Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25
Aoun, et al. Expires January 17, 2005 [Page 2]
Internet-Draft NATFW NSLP Migration July 2004
1. Introduction
This document discusses migration issues which are caused by the
incremental deployment of NSIS NAT/Firewall NSLP nodes. As such, it
is not only relevant for the NAT/FW NSLP but also for other NSLPs,
such as the QoS NSLP.
o The overall NSIS protocol suite (including the NAT/FW NSLP) is
impacted by NSIS unaware NATs and Firewalls. This document covers
the impacts as well as some suggestions to ease the deployments of
the NSIS protocol suite until the installed base of NATs and
Firewalls migrates to NSIS. Section 3 addresses this issue.
o The NAT/FW NSLP should allow an end host supporting NSIS to
operate properly without the need for supporting true end-to-end
NSIS signaling to its application correspondent. This is very
practical during the initial phases of the NSIS migration and is
applicable in simple network topologies. In the early phases of
the NSIS NAT/FW NSLP migration, this situation will occur quite
frequently, and hence this scenario must be supported. Section 4
is addresses this scenario.
Aoun, et al. Expires January 17, 2005 [Page 3]
Internet-Draft NATFW NSLP Migration July 2004
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terminology used in this document is defined in [NSISNATFW].
Aoun, et al. Expires January 17, 2005 [Page 4]
Internet-Draft NATFW NSLP Migration July 2004
3. Traversal of NSIS unaware NATs
3.1 Abstract
This section aims to describe different NAT handling classes in NSIS,
and the relationship between different solutions provided in various
NSIS documents. After a short introduction in Section 3.2, different
NAT classes are discussed in Section 3.2. Various NAT scenarios are
described in Section 3.3, in Section 3.4, in Section 3.5, and in
Section 3.6. Section 3.7 covers the details of addressing NSIS
unaware NATs.
3.2 Introduction
In the past, mainly two approaches have been used for establishing
NAT bindings:
Static configuration This type of NAT bindings is typically used to
allow inbound initiated communications. Ephemeral binds are often
not established or required.
Dynamic configuration: Dynamic NAT binding creation can be
categorized into one of the following three categories:
* Implicit creation by outbound initiated communications. In
this case, the translated address and port are selected from a
configured address and port pool.
* Explicit creation by an 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 which request the creation of a
NAT binding.
An alternative classification can be done by considering 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 establish the same
goal by directly addressing the NAT itself. The Midcom and the NSIS
working group are trying to develop protocols of the latter category.
To address the broad scope of NAT handling, this document tries to
describe the design considerations for the work in the NSIS WG. An
important impact for the design is caused by the introduction of the
two layer architecture, by intermediaries, and by NSIS unaware NATS.
Four classes of NAT functionality can be distinguished in NSIS.
Aoun, et al. Expires January 17, 2005 [Page 5]
Internet-Draft NATFW NSLP Migration July 2004
These are described in the following sub-sections.
3.3 Class 1 NAT Handling
We refer to Class 1 NAT handling if NATs or Firewalls implement the
NAT/Firewall NSLP.
Router 2+
Host A NAT Firewall
+--------+ +--------+ +--------+
| NE | | NE | | NE |
|+------+| |+------+| |+------+|
||QoS+ || ||QoS+ || ||QoS+ ||
||NAT-FW|| ||NAT-FW|| ||NAT-FW||
||NSLP || ||NSLP || ||NSLP ||
|+------+| |+------+| |+------+|
| || | | || | | || |
|+------+| |+------+| |+------+|
==||NTLP ||=========||NTLP ||=======||NTLP ||====>
|+------+| |+------+| |+------+|
+--------+ +--------+ +--------+
Figure 1: Class 1 NAT Handling
The NSIS working group decided to work on two NSLP client layer
applications: QoS and NAT/Firewall NSLP. The NAT/Firewall NSLP
assumes that a NAT or a Firewall implements the signaling application
(i.e., NTLP and NAT/Firewall NSLP implementation). [NSISNATFW]
describes the signaling mechanisms in more detail.
3.4 Class 2 NAT Handling
In Figure 2, a number of QoS NSLP nodes are shown, with one of the
NSIS nodes being a NAT device. In this scenario, we assume that the
NAT device does not contain a NAT/Firewall NSLP implementation.
Incremental deployment can lead to such a configuration. A question
raised by this scenario is whether the NSIS implementation (the NTLP
for example) should offer a minimal NAT implementation which would
allow it to request a NAT binding to update the flow identifier.
Aoun, et al. Expires January 17, 2005 [Page 6]
Internet-Draft NATFW NSLP Migration July 2004
Host A NAT Router 2
+--------+ +--------+ +--------+
| NE | | NE | | NE |
|+------+| |+------+| |+------+|
||QoS || ||QoS || ||QoS ||
||NSLP || ||NSLP || ||NSLP ||
|| || || || || ||
|+------+| |+------+| |+------+|
| || | | || | | || |
|+------+| |+------+| |+------+|
==||NTLP ||=========||NTLP ||=======||NTLP ||====>
|+------+| |+------+| |+------+|
+--------+ +--------+ +--------+
Figure 2: Class 2 NAT Handling
There is some desire to allow an NSLP signaling message exchange
(e.g., QoS signaling) to work properly even in the presence of NAT.
In this scenario, no NAT/Firewall NSLP implementation is available at
the NAT, and the end host might not trigger an NAT/Firewall NSLP
exchange. For some cases, the signaling message contains sufficient
information to create a NAT binding based on the flow identifier in
the NTLP layer. If additional security mechanisms have to be
provided by the NAT/Firewall NSLP, then that approach will fail
since, for example, a QoS NSLP will not be able to provide those
mechanisms.
Another question of interest is whether it is possible to combine a
NAT/Firewall signaling message with a QoS signaling message into a
single protocol message (or to at least combine them using a shared
session identifier). Error handling might be more complex because in
addition to dealing with errors of the individual signaling
applications, it will be necessary to deal with errors resulting from
the combined applications.
3.5 Class 3 NAT Handling
We refer to Class 3 NAT handling if there is a NAT along the path
which intercepts all NSIS signaling messages, but which does not
contain the desired NSLP implementation. In Figure 3a, Host A
signals for a QoS NSLP, but NAT 2 only offers an NTLP implementation.
This NTLP could modify a flow identifier, if it is not integrity
protected or encrypted. NAT 1 was already considered in Section 3.4.
Aoun, et al. Expires January 17, 2005 [Page 7]
Internet-Draft NATFW NSLP Migration July 2004
Host A NAT 1 Router 2
+--------+ +--------+ +--------+
| NE | | NE | | NE |
|+------+| |+------+| |+------+|
||QoS || ||QoS || ||QoS ||
||NSLP || ||NSLP || NAT 2 ||NSLP ||
|| || || || +--------+ || ||
|+------+| |+------+| | NE | |+------+|
| || | | || | | | | || |
|+------+| |+------+| |+------+| |+------+|
==||NTLP ||===||NTLP ||===||NTLP ||===||NTLP ||==>
|+------+| |+------+| |+------+| |+------+|
+--------+ +--------+ +--------+ +--------+
Figure 3: Class 3a NAT Handling
Intermediaries make NSIS signaling message handling more complex. To
avoid these problems it is possible to build functionality into the
NTLP to make intermediate nodes to be invisible for NSIS signaling.
As a solution, it is suggested to make the discovery message (C-Mode)
or the D-Mode in general cleverer to "discover" only those nodes
which implement the desired NSLP functionality. (This was already
discussed in the past.)
This requires indicating which NSLP functionality the signaling
message is looking for along the path. A discovery message might,
for example, want to know the next NSIS node along the path which
supports a QoS NSLP implementation. It is for further study, whether
a more fine-granular discovery is required (e.g., a QoS NSLP node
which supports a certain QoS model). IANA registration would be
required for the NSLPs as well as for QoS models.
Efficiency is an important issue here. An NSIS node which does not
implement a certain NSLP application must be able to quickly
distinguish whether it is interested in a message or not. Whether to
encode the necessary information into a router alert option, into UDP
port numbers, the Time-to-Live field, or into an IP protocol number
was discussed in the past.
As a minor variation of the scenario described in Figure 3, it is
possible that the end host does not contain a NAT/Firewall
implementation, but the network itself provides a NAT/Firewall
solution as shown in Figure 4.
Aoun, et al. Expires January 17, 2005 [Page 8]
Internet-Draft NATFW NSLP Migration July 2004
+----------------------------------------+
| Edge |
Host A | Router 1 Router 2 NAT/FW |
+--------+ +--------+ +--------+ +--------+
| NE | | NE | | NE | | NE |
|+------+| |+------+| |+------+| |+------+|
||QoS || ||QoS+ || ||QoS+ || ||[QoS+]||
||NSLP || ||NAT-FW|| ||NSLP || ||NAT-FW||
|| || ||NSLP || || || ||NSLP ||
|+------+| |+------+| |+------+| |+------+|
| || | | || | | || | | || |
|+------+| |+------+| |+------+| |+------+|
=||NTLP ||==||NTLP ||======||NTLP ||======||NTLP ||=>
|+------+| |+------+| |+------+| |+------+|
+--------+ +--------+ +--------+ +--------+
| Administrative Domain |
+----------------------------------------+
Figure 4: Class 3b NAT Handling
The main advantage of the approach described in Figure 4 is the
incremental deployment meaning that an administrative domain equips
its NATs/Firewalls with NAT/Firewall NSLP implementations even though
the end host might not support it. Note that the NAT/FW device might
not offer the QoS NSLP implementation. The NAT/Firewall NSLP enabled
Edge Router 1 might create a NAT binding or open a firewall pinhole
based on an incoming QoS signaling message (even though the end host
is not NAT/Firewall NSLP aware). It is also able to create NAT/
Bindings at the NAT/FW device independently of a signaling exchange.
Such a signaling exchange might be necessary if the NAT/Firewall is
not equipped with the NSLP application signaled by the end host - in
our example this would mean that the NAT/FW would not run a QoS NSLP
implementation.
3.6 Class 4 NAT Handling
We refer to a scenario as Class 4 NAT handling scenario if a NAT is
within the path which does not understand NSIS at all.
Aoun, et al. Expires January 17, 2005 [Page 9]
Internet-Draft NATFW NSLP Migration July 2004
Host A Router 2
+--------+ +--------+
| NE | | NE |
|+------+| |+------+|
||QoS || ||QoS ||
||NSLP || ||NSLP ||
|| || NAT || ||
|+------+| +--------+ |+------+|
| || | |+------+| | || |
|+------+| ||Plain || |+------+|
==||NTLP ||=========||NAT ||=======||NTLP ||====
|+------+| |+------+| |+------+|
+--------+ +--------+ +--------+
Figure 5: Class 4 NAT Handling
To allow NSIS signaling messages to traverse an NSIS unaware NAT, it
is required that they are sent in non-raw IP mode. This is necessary
to allow NAPT to perform modification of the transport protocol port
numbers. For an IPsec protected signaling message, UDP encapsulation
MUST be used. If IKE or IKEv2 [I-D.ietf-ipsec-ikev2] is used, then
NAT traversal functionality is necessary to dynamically detect the
presence of a NAT. The relevant work in this area can be found in
[I-D.ietf-ipsec-nat-t-ike], in [I-D.ietf-ipsec-ikev2] and in
[IPSECNAT].
3.7 Dealing with NSIS unaware NATs (Class 4 NAT Handling)
This section describes NSIS signaling in a Class 4 NAT handling
scenario. It is in general not possible to reuse the NAT binding
created with the NSIS signaling also for the data traffic. An
exception is a NAT which maps the source IP address of all outgoing
IP packets to the same external public IP address (without modifying
the port number). In order to update the flow identifier, the NSIS
NSLP daemon has to interact with a NAT in a non-NSIS fashion (such as
STUN [STUN] or a MIDCOM protocol), or to reuse an "NSIS-STUN-alike"
mechanism. We will describe the "NSIS-STUN-alike" mechanism in this
section.
In many cases it might be sufficient to detect the presence of an
NSIS unaware NAT. This might be useful for those cases where the
NSLP would break in such cases. The NSIS unaware NAT discovery
functionality could be a built-in feature of the NTLP [NTLP],
allowing its usage on any NE regardless of the supported NSLPs. In
order to discover a NAT the following procedure can be applied to
D-mode messages (which includes also discovery messages).
The initiator of the discovery message includes the source IP address
Aoun, et al. Expires January 17, 2005 [Page 10]
Internet-Draft NATFW NSLP Migration July 2004
and the source port of the transmitted message into the signaling
message payload.
An NSIS unaware NAT then modifies the source IP address (and possibly
the source port) of the NSIS signaling message. This procedure
represents typical NAT handling. The responder of the discovery
message will notice the modification by comparing information in the
IP header with the content of the discovery message. If both are
equal then no NAT was present. If the responder sees a deviation,
then an NSIS unaware NAT was located along the path. The responder
returns the source IP address and port number as a payload in the
discovery reply message. Unfortunately, the information found does
not help to update the flow identifier for the data traffic.
Traversing an NSIS unaware NAT (from inside to outside) dynamically
creates a NAT binding. Please note that only a NAT binding for the
signaling traffic is created. More complexity is introduced by
creating NAT bindings for data traffic. It seems to be reasonable
that neighboring NSIS nodes control the NAT and also the Firewall (of
the same administrative domain) via MIDCOM protocols, such as SNMPv3.
The usage of SNMPv3 for this purpose is simple but requires the NSIS
unaware NAT to implement this protocol.
Another option is to include an "NSIS-STUN-alike" mechanism into NSIS
which has the property of an in-band signaling mechanism. Ideally
NSIS signaling messages should look like regular data traffic to
experience the same treatment as data traffic. The discovery
mechanisms is thereby an important part which we will investigate in
more detail. Discovery messages are addressed to the same IP address
as the data traffic. The source IP address can, however, be the
source IP address of the data traffic, or the source IP address of
the signaling message, in which case it would be equal to the IP
address of the NSIS node transmitting it. The source port can be
either equal to the source port number of the transmitted data
traffic, or to the source port of the transmitting NSIS daemon.
Setting the source port to the port number of the application traffic
makes it very difficult for the NSIS daemon to intercept the response
to a discovery message. Further investigations are required to
verify its practicability. But this step would be very important
since responses need to be addressed to the port number which was
modified by the NAT (see symmetric NATs). It is suggested to set the
destination port number to the port number of the data traffic
destination. The Router Alert Option will allow an NSIS node to
intercept the message and to distinguish it from a regular data
packet. But note that this is only true for D-mode messages. For
C-Mode messages, an additional problem is created if the transport
layer protocol of the data traffic does not match the transport
protocol of the signaling traffic. Furthermore, it seems to be very
Aoun, et al. Expires January 17, 2005 [Page 11]
Internet-Draft NATFW NSLP Migration July 2004
difficult for an end host to distinguish the data traffic from the
signaling traffic. If we can assume that the discovery message
exchange is (for most parts) indistinguishable from data traffic,
then this exchange can be used by NSIS signaling messages and data
traffic to traverse an NSIS unaware NAT. This, however, additionally
assumes that only flows are signaled, rather than aggregates.
If no means of controling the NAT are available, then the STUN
protocol [STUN] can be used. The usage of STUN and other protocols
(such as TURN [I-D.rosenberg-midcom-turn]) should be investigated in
future versions of this document.
In Figure 6, we consider a scenario where an NSIS aware initiator
also hosts a STUN implementation. Note that more complex topologies
are possible but not investigated in detail in this section.
+---------------------------------------+
| | +--------+
| +----------+ | | STUN |
| |Apps | | | Server |
| +----------+ +---+| +--------+
| | STUN | |NAT||
| | CLIENT | | ||
| |__________| +---+|
| |ANY_NSLP | |
| | NI/NR | |
| +----------+ |
| Host A |
+---------------------------------------+
Figure 6: STUN usage for NSIS unaware NATs
Within Host A, shown in Figure 6, the NSIS API could invoke the
services of the STUN client upon determination that an NSIS unaware
NAT is on the path. NSLPs, such as a QoS NSLP, would use the STUN
returned global scoped address for the flow identifier of the NSIS
signaling message. If some NSLPs are between Host A and the NSIS
unaware NAT, then a wrong flow identifier would be communicated to
these devices. This might be problematic for a QoS NSLP and would
not really provide a solution. Without learning a globally routable
IP address via STUN, the correct flow identifier (i.e. the private
IP address) would be installed between Host A and the NSIS unaware
NAT, but a wrong flow identifier between the NAT and the destination
host, since the private IP address used as flow identifier is not
converted to a public IP address.
The consequences might be different if STUN is used by an entity
Aoun, et al. Expires January 17, 2005 [Page 12]
Internet-Draft NATFW NSLP Migration July 2004
along the path and not the end host. Figure 4 shows such an example.
This impact needs to be studied in more detail in a future version of
this document.
Aoun, et al. Expires January 17, 2005 [Page 13]
Internet-Draft NATFW NSLP Migration July 2004
4. NSIS Proxy Mode
When NSIS NAT/FW signaling will start to be deployed, it is quite
possible that an NI sends an NSIS message without having an NR to
respond to it. The NATFW NSLP should be able to handle this type of
deployments. NSIS NATFW NSLP signaling for a data receiver behind a
NAT already has just a local scope (the REA message is not forwarded
beyond the edge NAT, see [NSISNATFW]). This mechanism only works for
data receivers behind a NAT, but not for data receivers behind a
firewall.
Since the purpose of this section is to discuss how end to end
signaled messages are handled when no NRs are available on the
end-host, only Firewalls (the NFs) are discussed within the example
networks.
The local trust domain (from an NI perspective) has at least one NSIS
aware Firewall, there is no NR on the far end, nor an NSIS aware NAT
or Firewall. Goal of this exchange is to keep NSIS signaling local
within network A. The solution of this approach is similar to
[lrsvp], but the NSIS messages do not include any scoping
information.
Figure 7 shows this scenario graphically.
+-----------------------+ +--------------------+
|+----------+ | | +----------+
||App client| | | |App client|
||NI/NR | FW++ | ,---------. | +----------+
|+----------+ ''''''' The net ---. Host B |
| Host A | `---------' | |
| | | |
| Network A | | Network B |
+-----------------------+ +--------------------+
Figure 7: Implicit localized signaling
To terminate the NSIS signaling exchange within Network A, two
approaches are feasible: explicit and implicit scoping. With
explicit scoping, Host A has to indicate that the NSIS signaling
message should terminate locally. With implicit scoping, the NI
simply sends its firewall policy rule creation message. The message
traverses the first NF (its own firewall), but there is no NR to
respond back. As a consequence a timer will expire since no response
message is received. The last NF will respond back to the NI with a
notification that NSIS signaling had to terminate somewhere along the
path without reaching the NR. Using the network deployment shown in
Figure 7, the message exchange in Figure 8 takes place.
Aoun, et al. Expires January 17, 2005 [Page 14]
Internet-Draft NATFW NSLP Migration July 2004
Host A Host B
NI FW++ Expected NR
| | |
|1-NSIS Init msg | |
|----------------> | |
| |2-NSIS Init msg |
| | +---------------> |
| | |NATFW NSLP ON |
| | | |
| | | |
| | | |
| | | Timeout |
3-NSIS Init msg Ack| V |
|No NR | |
|<.................| |
Figure 8: Detecting the last NSIS peer
Figure 9 provides the message sequences when more than one NSIS aware
NAT or Firewall is deployed within the same trust domain. Upon
determination of a previous NSIS hop, an NSIS aware node will notify
the previous NSIS hop of its existence to avoid launching the timer
that triggers sending of an NSIS message back to the NI. The current
NTLP message association establishment procedures supports this
behavior. The last NF on the path will launch the timer since no
valid downstream NSIS neighbor responded back.
Aoun, et al. Expires January 17, 2005 [Page 15]
Internet-Draft NATFW NSLP Migration July 2004
Trust domain A Trust domain B
<..........................................> <-------->
Host A Host B
NI FW++ FW++ Expected NR
| | | |
| NSIS Init msg | | |
| ----------------> | NSIS Init msg | |
| | ---------------> | NSIS Init msg |
| | NATFW NSLP ON |---------------->|
| | | | with Token |
| | Valid . | NATFW NSLP ON |
| | NSIS Neighbor | | |
| |<-----------------| | |
| |----------------->| | Timeout |
| | Ack | | |
| | | | |
| | | | |
| | | | |
| | | V |
| | <................+ |
| | NSIS Init msg Ack| |
| NSIS Init msg Ack | No NR | |
| No NR | | |
| <.................| | |
Figure 9: Detecting the last NSIS peer (multiple FWs)
Aoun, et al. Expires January 17, 2005 [Page 16]
Internet-Draft NATFW NSLP Migration July 2004
5. NSIS unaware Firewall Traversal
In case an NSIS unaware firewall is traversed by NSIS messages, NSIS
messages should be allowed to go through it, as well as the exchanged
data flows between the user applications. This is not necessarily an
obvious task to perform in case the NSIS messages cannot be
identified by the NSIS unaware firewall. The same applies to the
user application data flows.
NSIS message identification should be supported by existing
firewalls.
Currently firewalls support flow identification by using the 5 tuple
or a sub-set of it. The authors are still expecting feedback from
firewall vendors to see if we can assume that existing firewalls will
not drop packets including the Router Alert Option (RAO) [RFC2113].
In case existing firewalls drop packets with the router alert option
set, then the RAO should not be the only element used to identify
packets to be dropped.
User application data flow identification should be deterministic at
a specific address and port range level. This means that the
application uses a combination of an address and specific transport
port range.This combination should be configured on the firewall.
In case a NAT is deployed on the path and it is NSIS-NATFW, the
assigned bind should be consistent with policy rules configured in
the NSIS unaware firewall.
Even though the deployed Firewall is not NSIS aware, the application
data would still be forwarded if existing interim solutions were
used, such as a mix of stateless policy rules and flow based states
with initial packets sent in the outbound direction (from inside a
trust domain to outside the trust domain).
Aoun, et al. Expires January 17, 2005 [Page 17]
Internet-Draft NATFW NSLP Migration July 2004
6. NATFW NSLP NTLP requirements
In this section we list two requirements for the NTLP raised by this
document.
o When NSIS signaling is used in the presence of NSIS unware NATs,
then raw IP MUST NOT be used. Network address and port
translation requires transport layer identifiers as means to
direct inbound traffic to the right recipient.
o For the traveral of NSIS unaware NATs, UDP is more likely to be
supported than DCCP or SCTP.
o If IPsec is used to secure NSIS signaling messages, then UDP
encapsulation for IPsec protected packets (see [IPSECNAT]) MUST be
used to ensure that IPsec does not break. IKE with extensions or
IKEv2 is able to detect the presence of a NAT along the path.
Aoun, et al. Expires January 17, 2005 [Page 18]
Internet-Draft NATFW NSLP Migration July 2004
7. Conclusion
To handle NAT devices properly it is necessary to address the
different NAT handling scenarios individually:
The impact of intermediaries causes complexity for signaling message
handling. It is therefore recommended to avoid Class 2 and Class 3
NAT handling scenarios by incorporating additional knowledge into the
discovery message.
Class 4 NAT handling requires some interaction with other protocols
such as MIDCOM or STUN. The ability to reuse the NTLP discovery
mechanisms to create NAT bindings for the signaling and the data
traffic is briefly outlined but requires more investigations.
To deal with firewalls it is also necessary to
o allow the NSIS signaling message to pass, and
o also to create pinholes for subsequent data traffic.
This is mainly an authorization problem and requires depends on the
environment where NSIS is used.
It is important to keep in mind to differentiate NAT bindings for the
signaling traffic and those for the data traffic. This separation is
necessary since the NSIS signaling message and the subsequent data
traffic are different in terms of the flow identifier observed by the
NAT. The same is true for firewall pinholes.
Aoun, et al. Expires January 17, 2005 [Page 19]
Internet-Draft NATFW NSLP Migration July 2004
8. Security Considerations
This document discusses various security issues for NAT/Firewall
signaling in migration scenarios.
Two important security threats are worth being highlighted:
o The proxy mode of operation, described in Section 4, demands the
property that NSIS signaling messages terminate somewhere along
the path. This functionality should allow NSIS to capture
additional scenarios not envisioned by RSVP. As a consequence it
makes it very hard to allow end-to-end security mechanisms to be
applied. These end-to-end security mechanisms have been proposed
to enable delayed authorization by both end hosts, and to tie the
NSIS end-to-end signaling together with application layer
signaling. The same is true if NSIS signaling is triggered by a
node other than the end host.
o Providing mechanisms to traverse NSIS unaware NATs also has
security implications. The impact can be related to an NSIS
signaling message, or even to the data traffic (based on signaling
of the flow identifier). Section 3 provides the details of
traversal of NSIS unaware NATs. An adversary along the path (a
non-NSIS node) is able to redirect NSIS signaling to another NSIS
node to cause denial of service attacks. If an adversary is
additionally able to modify the flow identifier, then it is
possible to cause NSIS to create an arbitrary policy rule which
would allow the adversary to inject traffic from an arbitrary
location. Note that an adversary along the path is always able to
cause denial of service attacks by dropping or delaying signaling
messages. Furthermore, it is also able to inject data packets,
but only with a flow identifier chosen by the signaling initiator,
and possibly modified by an NSIS aware NAT along the path.
Further security considerations can be found in [NSISNATFW] and
[I-D.fessi-nsis-natfw-threats].
Aoun, et al. Expires January 17, 2005 [Page 20]
Internet-Draft NATFW NSLP Migration July 2004
9. Contributors
We would like to thank Marcus Brunner and Miquel Martin for their
contribution to this draft.
Aoun, et al. Expires January 17, 2005 [Page 21]
Internet-Draft NATFW NSLP Migration July 2004
10. Acknowledgements
We would like to thank Joachim Kross for this comments to this draft.
Aoun, et al. Expires January 17, 2005 [Page 22]
Internet-Draft NATFW NSLP Migration July 2004
11. References
11.1 Normative References
[NSISNATFW]
Stiemerling, M., Martin, M., Tschofenig, H. and C. Aoun,
"A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
DRAFT draft-ietf-nsis-nslp-natfw-03.txt, July 2004.
[NTLP] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling",
draft-draft-ietf-nsis-ntlp-00 (work in progress), May
2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
11.2 Informative References
[I-D.fessi-nsis-natfw-threats]
Martin, A., Stiemerling, M., Thiruvengadam, S.,
Tschofenig, H. and C. Aoun, "Security Threats for the
NATFW NSLP", DRAFT draft-fessi-nsis-natfw-threats-01.txt,
July 2004.
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-14 (work in progress), May 2004,
<reference.I-D.ietf-ipsec-ikev2.xml>.
[I-D.ietf-ipsec-nat-t-ike]
Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-08 (work in progress), February
2004, <reference.I-D.ietf-ipsec-nat-t-ike.xml>.
[I-D.rosenberg-midcom-turn]
Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-01 (work in progress), March
2003.
[IPSECNAT]
A. Huttunen et all, A., "UDP Encapsulation of IPsec
Packets", DRAFT draft-ietf-ipsec-udp-encaps-07.txt, Jan
2003.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
Aoun, et al. Expires January 17, 2005 [Page 23]
Internet-Draft NATFW NSLP Migration July 2004
[RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements",
RFC 3304, August 2002.
[STUN] 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.
[lrsvp] Manner, J., "Localized RSVP", draft-manner-lrsvp-03 (work
in progress), January 2004.
Authors' Addresses
Cedric Aoun
Nortel Networks
France
EMail: cedric.aoun@nortelnetworks.com
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
Munich 81739
Germany
Phone:
EMail: Hannes.Tschofenig@siemens.com
URI:
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:
Aoun, et al. Expires January 17, 2005 [Page 24]
Internet-Draft NATFW NSLP Migration 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.
Aoun, et al. Expires January 17, 2005 [Page 25]