Internet DRAFT - draft-aoun-nsis-nslp-natfw-migration

draft-aoun-nsis-nslp-natfw-migration




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]