NSIS Working Group                                        M. Stiemerling
Internet-Draft                                                       NEC
Expires: August 16, November 19, 2004                                 H. Tschofenig
                                                                 Siemens
                                                               M. Martin
                                                                     NEC
                                                                 C. Aoun
                                                         Nortel Networks
                                                       February 16,
                                                            May 21, 2004

           NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
                     draft-ietf-nsis-nslp-natfw-01
                     draft-ietf-nsis-nslp-natfw-02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.
   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 August 16, November 19, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This memo defines the NSIS Signaling Layer Protocol (NSLP) for
   Network Address Translators and Firewalls.  This NSLP allows hosts to
   signal along a data path for Network Address Translators and
   Firewalls to be configured according to the data flow needs.  The
   network scenarios, problems and solutions for path-coupled Network
   Address Translator and Firewall signaling are described.  The overall
   architecture is given by the framework and requirements defined by
   Next Steps in Signaling (NSIS) working group.  This is one of two
   NSIS Signaling Layer Protocols (NSLPs) the working group will address
   during its work.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  5 . .  4
     1.1   Terminology and Abbreviations  . . . . . . . . . . . . . .  6  5
     1.2   Middleboxes  . . . . . . . . . . . . . . . . . . . . . . .  7
     1.3   General Scenario for NATFW Traversal . . . . . . . . . . .  9  8

   2.  Network Environment  . . . . . . . . . . . . . . . . . . . 11 . . 10
     2.1   Network Scenarios for Protocol Functionality . . . . . . . 11 10
       2.1.1   Firewall traversal . . . . . . . . . . . . . . . . . . . . 11 10
       2.1.2   NAT with two private Networks  . . . . . . . . . . . . . . 12 11
       2.1.3   NAT with private network on sender side  . . . . . . . . . 13 12
       2.1.4   NAT with private network on receiver side  . . . . . . . . 13 12
       2.1.5   Both End Hosts behind twice-NATs . . . . . . . . . . . . . 14 13
       2.1.6   Both End Hosts behind same NAT . . . . . . . . . . . . . . 15 14
       2.1.7   IPv4/v6 NAT with two private networks  . . . . . . . . 15
       2.1.8   Multihomed Network with NAT  . . . . . . . . . . . . . 16
     2.2   Trust Relationship and Authorization . . . . . . . . . . . 17
       2.2.1   Peer-to-Peer Trust Relationship  . . . . . . . . . . . . . 17
       2.2.2   Intra-Domain Trust Relationship  . . . . . . . . . . . . . 18
       2.2.3   End-to-Middle Trust Relationship . . . . . . . . . . . . . 19

   3.      Problems and Challenges  . .  Protocol Description . . . . . . . . . . . . . . . 21
   3.1     Missing Network-to-Network Trust Relationship . . . . . . 21
   3.2     End-to-end significance  . . . . . . . . . . . . . . . . . 22
   3.3     Relationship with routing  . . . . . . . . . . . . . . . . 22
   3.4     Dynamic state installation and maintenance . . . . . . . . 22
   3.5     Affected Parts of the Network  . .
     3.1   Basic protocol overview  . . . . . . . . . . . . 22
   3.6     NSIS backward compatibility with NSIS unaware NAT and
           Firewalls . . . . . 21
     3.2   Protocol Operations  . . . . . . . . . . . . . . . . . . . 23
   3.7     Authentication and Authorization . . . . . . . . . . .
       3.2.1   Creating Sessions  . . 24
   3.8     Directional Properties . . . . . . . . . . . . . . . . 23
       3.2.2   Reserving External Addresses . . 24
   3.9     Routing Asymmetry . . . . . . . . . . . 25
       3.2.3   Reserving External Addresses and Create Session  . . . 28
       3.2.4   Prolonging Sessions  . . . . . . 24
   3.10    Addressing . . . . . . . . . . . 28
       3.2.5   Deleting Sessions  . . . . . . . . . . . . . 25
   3.11    NTLP/NSLP NAT Support . . . . . 29
       3.2.6   Authorization  . . . . . . . . . . . . . 25
   3.12    Route changes . . . . . . . 30
       3.2.7   Calculation of Lifetimes . . . . . . . . . . . . . . . 25
   3.13    Combining 30
       3.2.8   Middlebox and QoS signaling  . . . . . Resource . . . . . 26
   3.14    Difference between sender- and receiver-initiated
           signaling  . . . . . . . . . . . . . . 31
       3.2.9   De-Multiplexing at NATs  . . . . . . . . . . 26
   3.15    Inability to know the scenario . . . . . 31
       3.2.10  Selecting Destination IP addresses for REA . . . . . . 32
     3.3   NATFW NSLP Messages Components . . . 26

   4.      NSIS NAT Handling Solution . . . . . . . . . . . 33
       3.3.1   NSLP Header  . . . . . 28
   4.1     Problem Description . . . . . . . . . . . . . . . . 33
       3.3.2   NSLP message types . . . 28
   4.2     Solution Overview . . . . . . . . . . . . . . . 34
       3.3.3   NSLP Objects . . . . . 31
   4.2.1   Destination IP address Selection . . . . . . . . . . . . . 33

   5.      Protocol Description . . . 34
         3.3.3.1   Session ID Object  . . . . . . . . . . . . . . . . 35
   5.1     Basic protocol overview  . .
         3.3.3.2   Session Lifetime Object  . . . . . . . . . . . . . 35
         3.3.3.3   External Address Object  . . 35
   5.2     NATFW NSLP Header . . . . . . . . . . . 36
         3.3.3.4   Extended Flow Information Object . . . . . . . . . 37
   5.3     NATFW NSLP Objects .
         3.3.3.5   Error Object . . . . . . . . . . . . . . . . . . . 37
   5.3.1   NATFW NSLP Object Header . . . . . . . . . . . . .
     3.4   Message Formats  . . . . 37
   5.3.2   NATFW Session ID Object . . . . . . . . . . . . . . . . . 38
   5.3.3   Lifetime Object
       3.4.1   Policy Rules . . . . . . . . . . . . . . . . . . . . . 38
   5.3.4   Policy Rule Object . . .
       3.4.2   Create Session (CRS) . . . . . . . . . . . . . . . . . 38
   5.3.5 39
       3.4.3   Reserve External Address Object  . . . . . (REA) . . . . . . . . . . . . 39
   5.4     Request Message Formats
       3.4.4   Reserve-Create (REC) . . . . . . . . . . . . . . . . . 39
   5.4.1   Create Session . . . . . . . . . . . . . . . . . . . . . . 40
   5.4.2
       3.4.5   Prolong Session (PLS)  . . . . . . . . . . . . . . . . . . . . . 40
   5.4.3 39
       3.4.6   Delete Session . . . . . (DLS) . . . . . . . . . . . . . . . . . 40
   5.4.4   Reserve External Address
       3.4.7   Path Succeeded (PS)  . . . . . . . . . . . . . . . . . 40
   5.5     Response Messages  . .
       3.4.8   Path Deleted (PD)  . . . . . . . . . . . . . . . . . . 41
   5.5.1 40
       3.4.9   Return External Address Response . . . . . . . . . . . . . 41
   5.5.2   Path Succeeded Response  . . . . (RA) . . . . . . . . . . . . . 42
   5.5.3 40
       3.4.10  Error Response Messages  . . . . . (ER)  . . . . . . . . . . . . 42
   5.6     Protocol Operations  . . . . . . . . 41

   4.  NSIS NAT and Firewall transitions issues . . . . . . . . . . . 42
   5.6.1   Message Handling Overview  . . . . . . . . . . . .

   5.  Security Considerations  . . . . 42
   5.6.1.1 Reserving Addresses . . . . . . . . . . . . . . . 43

   6.  Open Issues  . . . . 44
   5.6.1.2 Creating Sessions . . . . . . . . . . . . . . . . . . . . 46
   5.6.1.3 Prolonging Session . 45

   7.  Contributors . . . . . . . . . . . . . . . . . . . 47
   5.6.1.4 Deleting Sessions . . . . . . 46

   8.  References . . . . . . . . . . . . . . 48

   6.      Solution examples . . . . . . . . . . . . 47
   8.1   Normative References . . . . . . . . 50
   6.1     Firewall traversal . . . . . . . . . . . . 47
   8.2   Informative References . . . . . . . . 50
   6.2     NAT with private network on sender side . . . . . . . . . 51
   6.3     NAT with private network on receiver side . . 47

       Authors' Addresses . . . . . . 52
   6.4     Both end hosts are in same private network behind NATs . . 56
   6.5     IPv4/v6 NAT with two private networks . . . . . . . . . . 58
   6.6     Full example for NAT/FW with two private networks . . . . 58

   7.      NSIS NAT 49

   A.  Problems and Firewall transitions issues . . . . . . . . . 65

   8.      Security Considerations  . . . . . . . . . . . . . . . . . 66

   9.      Open Issues  . . . . . . . . . . . . . . . . Challenges  . . . . . . . 68

   10.     Contributors . . . . . . . . . . . . 51
     A.1   Missing Network-to-Network Trust Relationship  . . . . . . 51
     A.2   Relationship with routing  . . . . . 69

           Normative References . . . . . . . . . . . 52
     A.3   Affected Parts of the Network  . . . . . . . . 70

           Informative References . . . . . . 53
     A.4   NSIS backward compatibility with NSIS unaware NAT and
           Firewalls  . . . . . . . . . . . . 71

           Authors' Addresses . . . . . . . . . . . . 53
     A.5   Authentication and Authorization . . . . . . . . 72

   A.      Inter-working of SIP with NSIS NATFW NSLP . . . . . 54
     A.6   Directional Properties . . . 74
   A.1     The Session Initiation Protocol . . . . . . . . . . . . . 74
   A.2     Conclusions . . 54
     A.7   Addressing . . . . . . . . . . . . . . . . . . . . . 79

   B.      Ad-Hoc networks . . . 54
     A.8   NTLP/NSLP NAT Support  . . . . . . . . . . . . . . . . . . 80

   C.      Interworking of Security Mechanisms 55
     A.9   Combining Middlebox and NSIS NATFW NSLP  . 81

   D.      Solution approaches in case of missing authorization . . . 82
   D.1     Solution Approach: Local authorization from both end
           points . . . . . . . . . . . . . . QoS signaling  . . . . . . . . . . 55
     A.10  Inability to know the scenario . . 82
   D.2     Solution Approach: Access Network-Only Signaling . . . . . 83
   D.3     Solution Approach: Authorization Tokens . . . . . . . 55

   B.  Acknowledgments  . . 83

   E.      Acknowledgments . . . . . . . . . . . . . . . . . . . . . 86 57

       Intellectual Property and Copyright Statements . . . . . . 87 . . 58

1.  Introduction

   Firewalls and Network Address Translators (NAT) have been both used
   throughout the Internet for many years and they will be present in
   future.  Using firewalls Firewalls brings security to networks and in times of
   IPv4 address depletion NATs virtually extend IP address space.  In
   general, both types are may be obstacles to many applications, since they
   only allow specific applications to traverse them (i.e. (i.e., HTTP
   traffic). traffic
   or in general client/server applications).  Other applications, as for instance
   instance, IP telephony, telephony or any other peer-to-peer application, with
   more dynamic properties suffer from firewalls Firewalls and NATs so that they
   don't
   do not work at all.  Therefore, many applications cannot traverse any
   kind of firewall
   Firewall or NAT. NATs.

   Several solutions to enable any application to traverse those boxes
   have been proposed and are currently used.  Typically, application
   level gateways (ALG) have been integrated and so configuring
   firewalls
   Firewalls and NATs dynamically.  Another approach is middlebox
   communication (MIDCOM, currently under standardization at the IETF).
   In this approach firewall Firewall and NAT external ALGs configure them via
   the MIDCOM protocol [6]. [7].  Several other work around solutions are
   available as well. Anyway, well, see STUN [32] and [31].  However, all of these
   approaches introduce other problems that are hard to solve; one of them is like
   dependencies on certain NAT implementations or dependency on
   topology issues.
   topology.

   NAT and firewall Firewall (NATFW) signaling share a property with Quality of
   Service (QoS) signaling, i.e. i.e., in both cases it is needed required to reach
   any device on the data path that is involved in QoS or NATFW
   treatment of data packets.  Currently,  For both, NATFW and QoS, signaling
   travels path-coupled, meaning that the signaling messages follow
   exactly the same path as the data packets do.  RSVP [13] [14] is used an
   example for a QoS signaling, but
   the conception of signaling protocol.

   This memo defines a new IP path-coupled signaling protocol is under work in the
   Next Step framework
   of NSIS for NAT and Firewall configuration, called the NATFW NSIS
   Signaling (NSIS) working group.  This new signaling
   protocol Layer Protocol (NSLP).  The general framework of NSIS is path-coupled, like RSVP is,
   outlined in [1] and its primary use is QoS
   signaling, but NATFW introduces the split between NSIS transport layer
   and NSIS signaling is considered as well.

   This memo defines this NATFW path-coupled protocol. layer.  The NATFW
   signaling protocol transport of NSLP messages is carried over the handled
   by NSIS Network Transport Layer Protocol (NTLP, see [3]) as and takes
   care about NSLP message transport.  The signaling logic for QoS and
   NATFW signaling is implemented in the different NSLPs.  The QoS NSLP
   is defined in [4], furthermore the general requirements for NSIS Signaling Layer Protocol (NSLP).
   This are
   defined in [2].

   There is a series of related documents to NATFW NSLP is used discussing
   several other aspects of path-coupled NATFW signaling, including
   security [20], migration [17], intrarealm signaling [18], and
   inter-working with SIP [19].

   The NATFW NSLP allows requesting the configuration of NATs and/or
   Firewalls along the data path to open pin-holes in firewalls enable data flows to traverse these
   devices without being obstructed.  A simplified example: A source
   host sends a NATFW NSLP signaling message towards its data
   destination.  This message follows the data path and create NAT
   address mappings every NATFW NSLP
   NAT/Firewall along the data path, so that subsequent path intercepts these messages, processes
   it and configures itself accordingly.  Afterwards, the actual data packets
   flow can traverse those devices. every configured Firewall/NAT.

   NATFW NSLP runs in two different modes, one is the path directed mode
   where Firewalls and NATs are configured along the data path as
   pointed out in the above example.  The second one is the reserve
   mode, where NATs are detected by the NSLP/NTLP within the network and
   a public reachable IP address and port number are reserved.  This
   reserve mode enables hosts located behind NATs to receive data
   originated in the public Internet on the reverse data path.  Both
   modes create NATFW NSLP and NTLP state in the network.  The NSLP
   state is maintained via a soft-state mechanism.  State includes not
   only signaling state, but as well as NAT bindings and Firewall rules.
   This state is maintained via a lifetime and must be kept alive via a
   lifetime extension mechanism if needed.  Two signaling messages are
   used for deleting state explicitly and extending state's lifetime.
   In general, all NATFW NSLP signaling messages are exchanged
   end-to-end.

   Traversal of non NATFW NSLPs or the NTLP is out of scope of this
   document.  Furthermore, only firewalls Firewalls and NATs are considered in
   this document, any other device, for instance IPSec security gateway,
   is out of scope.

   Section 2 describes the network environment for NATFW NSLP signaling
   and highlights the required trust relationship/ authorization.  Problems
   Section 3 defines the NATFW signaling protocol with its message
   components, message formats, and protocol operations.  The remaining
   document refers in Section 4 to transition issues and security
   considerations are handled in [20].  Currently unsolved problems and
   challenges are listed and discussed in section 3, whereas a NSIS Appendix A.  Please note that
   readers familiar with possible locations of Firewalls and NAT handling
   solution is described in section 4.
   networks can safely skip Section 5 describes the protocol
   itself and section 6 gives some usage examples.

   Readers are recommended to read the NSIS framework [1] and
   requirements documents beforehand [2]). 2.

1.1  Terminology and Abbreviations

   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 RFC 2119.

   This document uses terms defined in [2].  Furthermore, these
   following terms are used:
   o  NSIS NAT Forwarding State: The term "NSIS NAT Forwarding State" in
      this context refers to a state used to forward the NSIS signaling
      message beyond the targeted destination address; that state is
      typically used when the NSIS Responder address is not known
   o  Sender-/Receiver Initiated Signaling
         Sender-initiated: NAT bindings and firewall Firewall rules are created
         immediately when the "path" message hits the NSIS nodes.  With
         "path" message we refer to the signaling message traveling from
         the data sender towards the data receiver.
         Receiver-initiated: NAT bindings and firewall Firewall rules are created
         when the "reserve" message returns from the other end.  With
         "reserve" message we refer to a signaling message on the
         reverse path, this means from the receiver to the sender (i.e.
         backwards routed).
         Note that these definitions have nothing to do with number of
         roundtrips, who performs authorization etc.
   o  Policy rule: In general, a policy rule is "a basic building block
      of a policy-based system.  It is the binding of a set of actions
      to a set of conditions - where the conditions are evaluated to
      determine whether the actions are performed."  [RFC3198].  In the
      context of NSIS NATFW NSLP the condition is a specification of a
      set of packets to which rules are applied.  The set of actions
      always contains just a single element per rule, and is limited to
      either action "reserved" or action "enable".
   o  Firewall:  A packet filtering device that matches packet against a
      set of policy rules and applies the actions.  In the context of
      NSIS NATFW NSLP we refer to this device as firewall. Firewall.
   o  Network Address Translator:  Network Address Translation is a
      method by which IP addresses are mapped from one realm to another,
      in an attempt to provide transparent routing to hosts (see [8]). [9]).
      Network Address Translator Translators are devices that perform this method.
   o  Middlebox: from [11]: [12]: "A middlebox is defined as any intermediate
      device performing functions other than the normal, standard
      functions of an IP router on the datagram path between a source
      host and a destination host".  The term middlebox in context of
      this document and in NSIS refers to firewalls Firewalls and NATs only.
      Other types of middlebox are currently outside the scope.
   o  Security Gateway: IPsec based gateways.
   o  NSIS Initiator (NI): the signaling entity entity, which makes the
      resource request, usually as a result of user application request.
   o  NSIS Responder (NR): the signaling entity that , which acts as the
      final destination for the signaling and can optionally interact
      with applications as well.
   o  NSIS Forwarder (NF): the signaling entity between an NI and NR
      which propagates NSIS signaling further through the network.

   o  Receiver (DR or R): the node in the network network, which is receiving
      the data packets of a flow.
   o  Sender (DS or S): the node in the network network, which is sending the
      data packets of a flow.
   o  NATFW NSLP session:  Application layer flow of information for
      which some  network control state information is to be manipulated
      or monitored (as defined in [1]).  The control state for NATFW
      NSLP is NSLP state and associated policy rules at the middlebox.
   o  NSIS peer or peer:  NSIS node with which a NSIS adjacency has been
      created as defined in [3].
   o  Edge NAT:   By edge NAT we refer to the NAT device device, which is
      reachable from outside and has a globally routable IP address.
   o  Public Network: Definition according to [8] is "A Global or Public
      Network is an address realm with unique network addresses assigned
      by Internet Assigned Numbers Authority (IANA) or an equivalent
      address registry.  This network is also referred as External
      network during NAT discussions."
   o  Private/Local Network: Definition according to [8] is " A private
      network is an address realm independent of external network
      addresses.  Private network may also be referred alternately as
      Local Network.  Transparent routing between hosts in private realm
      and external realm is facilitated by a NAT router."  IP address
      space allocation for private networks is recommended in [33]
   o  Public/Global IP address: An IP address located in the public
      network.
   o  Private/Local IP address: An IP address located in the private
      network.

1.2  Middleboxes

   The term middlebox raises different expectations about functionality
   provided by such a device.  Middleboxes in the scope of this memo are
   firewalls
   Firewalls that filter data packets against their set of filter rules
   and NATs that translate addresses from one address realm to another
   address realm.  Other types of middleboxes, for instance QoS traffic
   shapers and security gateways, are out of scope.

   The term NAT used in this document is placeholder for a range of
   different NAT flavors.  We consider those types of NATs:
   o  traditional NAT (basic NAT and NAPT)
   o  Bi-directional NAT
   o  Twice-NAT
   o  Multihomed NAT
   For a detailed discussion about each NAT type please see [7]. [8].

   Both types of middleboxes use policy rules for decision on data
   packet treatment.  Policy rules consist of a 5-tuple and an
   associated action; action.  Data packets matching this 5-tuple experience the
   policy rule action.  A 5-tuple consists of:
   o  Source IP address and port number
   o  Destination IP address and port number
   o  Transport protocol
   Actions for firewalls Firewalls are usually:
   o  Allow: forward data packet
   o  Deny: block data packet and discard it
   o  Other actions like logging, diverting, etc
   Actions for NATs are (amongst many others):
   o  Change source IP address and port number to an a global routeable IP
      address and port number.
   o  Change destination IP address and port number to a private IP
      address and port number.

   The exact implementation of policy rules and mapping to firewall Firewall rule
   sets and NAT bindings or sessions at the middlebox is an
   implementation issue and thus out of scope of this document.

   Some devices entitled as firewalls Firewalls only accept traffic after
   cryptographic verification (i.e.  IPsec protected data traffic).
   Particularly for network access scenarios either link layer or
   network layer data protection is common.  Hence we do not address
   these types of devices (referred as security gateways) since per-flow
   signaling is rather uncommon in this environment.  For a discussion
   of network access authentication and associated scenarios the reader
   is referred to the PANA working group (see [22]). [26]).

   Discovering security gateways, which was also mentioned as an
   application for NSIS signaling, for the purpose of executing an IKE
   to create an IPsec SA, is already solved without requiring NSIS.

   In mobility scenarios an often experienced problem is the traversal
   of a security gateway at the edge of the corporate network.  Network
   administrators often rely on the policy that only authenticated data
   traffic is allowed to enter the network.  A problem statement for the
   traversal of these security gateways in the context of Mobile IP can
   be found at [21]). [25]).

   Other proposals for path-coupled NAT and firewall Firewall traversal like RSVP
   and CASP are described in [23] [27] and [24]. [28].

1.3  General Scenario for NATFW Traversal

   The purpose of NSIS NATFW signaling is to enable any communication
   between endpoints across networks even in presence of middleboxes.
   It is expected that those middleboxes are be configured in such a way
   that NSIS NATFW signaling messages itself are allowed to traverse
   them.  NSIS NATFW NSLP signaling is used to install such policy rules
   in all middleboxes along the data path.  Firewalls are configured to
   forward data packets matching the policy rule provided by the NSLP
   signaling.  NATs are configured to translate data packets matching
   the policy rule provided by the NSLP signaling.

   The basic high-level picture of NSIS usage is that endhosts are
   located behind middleboxes (NAT/FW in Figure 1).  Applications
   located at these endhosts try to establish communication between them
   and use NSIS NATFW NSLP signaling to establish policy rules on a data
   path, which allows the said data to travel from the endhost sender to the endpoint
   receiver unobstructed.  The applications can somehow trigger
   middlebox traversal (e.g.  via an API call) at the NSIS agent entity at the
   local host.

   Application          Application Server (0, 1, or more)   Application

   +----+                        +----+                        +----+
   |    +------------------------+    +------------------------+    |
   +-+--+                        +----+                        +-+--+
     |                                                           |
     |         NSIS Agents Entities                      NSIS Entities  |
   +-+--+        +----+                            +-----+     +-+--+
   |    +--------+    +----------------------------+     +-----+    |
   +-+--+        +-+--+                            +--+--+     +-+--+
     |             |               ------             |          |
     |             |           ////      \\\\\        |          |
   +-+--+        +-+--+      |/               |     +-+--+     +-+--+
   |    |        |    |     |   Internet       |    |    |     |    |
   |    +--------+    +-----+                  +----+    +-----+    |
   +----+        +----+      |\               |     +----+     +----+
                               \\\\      /////
   sender    NAT/FW (1+)           ------          NATFW (1+) receiver

        Figure 1: Generic View on NSIS in a NAT / Firewall case

   For running NATFW signaling it is necessary that each firewall Firewall and
   each NAT involved in the signaling communication runs an NSIS NATFW
   agent.
   entity.  There might be several NATs and FWs in various possible
   combinations on a path between two hosts.  The reader is referred to
   Section 2.1 where different scenarios are presented.

2.  Network Environment

2.1  Network Scenarios for Protocol Functionality

   This section introduces several scenarios for middleboxes in the
   Internet.  Middleboxes are located in at different locations, i.e.  at
   Enterprise network borders, within enterprise networks, mobile phone
   network gateways, etc.  In general, middleboxes are place placed more
   towards the edge of networks and less in network cores.  Those
   middleboxes are not only either firewall Firewall or NAT, but NAT and any other type of
   combination is possible.  Thus, combined firewall Firewall and NATs are
   available.

   NSIS initiators (NI) are sending NSIS NATFW NSLP signaling messages are sent by the NSIS initiator
   (NI)
   via the regular data path to the NSIS responder (NR).  On the data
   path NATFW NSLP signaling messages reach different NSIS peers that
   have the NATFW NSLP implemented.  Each NATFW NSLP node processes the
   signaling messages according to Section 5 3 and installs, if necessary,
   policy rules for subsequent data packets.

   Each following section introduces a different scenario for a
   different set of middleboxes and their ordering within the topology.
   It is assumed that each middlebox implements the NSIS NATFW NSLP
   signaling protocol.

2.1.1  Firewall traversal

   This section describes a scenario with firewalls only, no Firewalls only and NATs are
   not involved.  Both end hosts are behind a firewall Firewall that are is connected
   via the public Internet.  Figure 2 shows the topology.  The part
   labeled "public" is the Internet connection both firewalls. Firewalls.

                  +----+    //----\\       +----+
          NI -----| FW |---|        |------| FW |--- NR
                  +----+    \\----//       +----+

                 private     public        private

             FW: Firewall
             NI: NSIS Initiator
             NR: NSIS Responder

                 Figure 2: Firewall Traversal Scenario

   Each firewall Firewall on-path must provide traversal service for NATFW NSLP
   in order to permit the NSIS message to reach the other end host.  All
   firewalls
   Firewalls process NSIS signaling and establish appropriate policy
   rules, so that the required data packet flow can traverse them.

   The difference between this scenario and the following is that only
   firewalls are on the path, but no NATs.  This has specific
   implication concerning the used destination address for path-coupled
   signaling message sent by the NSIS initiator to an NSIS responder
   hosted behind a NAT.

2.1.2  NAT with two private Networks

   Figure 3 shows a scenario with NATs at both ends of the network.
   Therefore, each application instance, NSIS initiator and NSIS
   responder
   responder, are behind NATs.  The outermost NAT at each side is
   connected to the public Internet.  The NATs are labeled as MB (for
   middlebox), since those devices implement at least NAT-only, but can
   implement firewalling Firewalling as well.

   Only two middleboxes MB are shown in Figure 3 at each side, but in
   general more than one MB on each side must be considered.

           +----+     +----+    //----\\    +----+     +----+
      NI --| MB |-----| MB |---|        |---| MB |-----| MB |--- NR
           +----+     +----+    \\----//    +----+     +----+

                private          public          private

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

            Figure 3: NAT with two private networks Scenario

   Signaling traffic from NI to NR has to traverse all four middleboxes
   on the path and all four middleboxes must be configured properly to
   allow NSIS signaling to traverse.  The NATFW signaling must configure
   all middleboxes and consider any address translation in further
   signaling.  The sender (NI) has to know the IP address of the
   receiver (NR) in advance, otherwise he cannot send a single NSIS
   signaling message towards the responder.  Note that this IP address
   is not the private IP address of the responder.  Instead a NAT
   binding (including a public IP address) has to be obtained from the
   NAT which that subsequently allows packets hitting the NAT to be forwarded
   to the receiver within the private address realm.  This generally
   requires further support from an application layer protocol for the
   purpose of discovering and exchanging information.  The receiver
   might have a number of ways to learn its public IP address and port
   number and might need to signal this information to the sender using
   the application level signaling protocol.

2.1.3  NAT with private network on sender side

   This scenario shows an application instance at the sending node which that
   is behind one or more NATs (shown as MB).  The receiver is located in
   the public Internet.

             +----+     +----+    //----\\
        NI --| MB |-----| MB |---|        |--- NR
             +----+     +----+    \\----//

                  private          public

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

         Figure 4: NAT with private network on sender scenario

   The traffic from NI to NR has to traverse only middleboxes on the
   sender's side.  The receiver has a public IP address.  The NI sends
   its signaling message directly to the address of the NSIS responder.
   Middleboxes along the path intercept the signaling messages and
   configure the policy rules accordingly.

   Note that the data sender does not necessarily know whether the
   receiver is behind a NAT or not, hence, it is the receiving side that
   has to detect the whether it itself is behind a NAT or not.  As described in
   Section 4 3.2.2 NSIS can also provide help for this procedure.

2.1.4  NAT with private network on receiver side

   The application instance receiving data is behind one or more NATs.

               //----\\    +----+     +----+
        NI ---|        |---| MB |-----| MB |--- NR
               \\----//    +----+     +----+

                public          private

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

        Figure 5: NAT with private network on receiver Scenario

   First,

   Initially, the sender NSIS responder must determine the its public reachable IP
   address of at the
   receiver. external middlebox and notify the NSIS initiator about
   this address.  One possibility is that an application level protocol
   is
   used. In this case, used, meaning that the receiver must first fix its public IP
   addresses at the middlebox on its side.  This information about IP address and port number could be is signaled via an application level this
   protocol to the actual sender directly or indirectly via a third
   party (e.g. proxy). In the scenario, this means NI.  Afterwards the receiver has
   first to determine its public IP address (NAT binding) and register
   this address with a third party.

   The NSIS initiator NI can start NSIS its signaling after he has received
   information about
   towards the receiver's public IP address NR and port number. so establishing the path via the both middleboxes
   MB.

   This scenario describes the use case for the reserve mode of the
   NATFW NSLP.

2.1.5  Both End Hosts behind twice-NATs

   This is a special case, where the main problem is to detect that both
   nodes are logically within the same address space, also behind a
   twice-NAT (see [7] [8] for discussion about twice-NAT functionality).
   This scenario primarily addresses performance aspects.

   Sender and receiver are both within a private address realm and
   potentially have overlapping IP addresses.  Figure 6 shows the
   ordering of NATs.  This is a common configuration in several
   networks, particularly after the merging of companies that have use used
   the same address space, thus having overlapping addresses in many
   cases.

                                   public
             +----+     +----+    //----\\
        NI --| MB |--+--| MB |---|        |
             +----+  |  +----+    \\----//
                     |
                     |  +----+
                     +--| MB |------------ NR
                        +----+

                   private

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

     Figure 6: NAT to public, sender and receiver behind twice-NAT
                                Scenario

   The middleboxes shown in Figure 6 are twice-NATs, i.e.  they map IP
   addresses and port numbers on both sides, at private and public
   interfaces.

   This scenario requires assistance of application level entities, like
   DNS server.  Those application level gateways must handle request
   that are based on symbolic names and configure the middleboxes so
   that data packets are correctly forwarded from NI to NR.  The
   configuration of those middleboxes may require other middlebox
   communication protocols, like MIDCOM [6]. [7].  NSIS signaling is not
   required in the twice-NAT only case, since the middleboxes of type
   twice-NAT are configured by other means.  Nevertheless, NSIS
   signaling might by useful when there are firewalls in between. Firewalls on path.  In this
   case NSIS will not configure any policy rule at twice-NATs, but will
   configure policy rules at the intermediate firewalls. Firewalls.  The NSIS
   signaling protocol must be at least robust enough to survive this
   scenario.

2.1.6  Both End Hosts behind same NAT

   When NSIS initiator and NSIS responder are behind the same NAT (thus
   being in the same address realm, see Figure 7) , 7), they are most likely
   not aware of this fact.  As in Section 2.1.4 the NSIS responder must
   determine its public IP address in advance and transfer it to the
   NSIS initiator.  Afterwards, the NSIS initiator can start sending the
   signaling messages to the responder's public IP address.  During this
   process, a public IP address will be allocated for the NSIS initiator
   at the same middlebox as for the responder.  Now, the NSIS signaling
   and the subsequent data packets will traverse the NAT twice: two times: from
   initiator to public IP address of responder (first time) and from
   public IP address of responder to responder (second time).  This is
   the worst case, both sender and receiver obtain a public IP address
   at the NAT and the communication path is not optimal anymore.

               NI              public
                \  +----+     //----\\
                 +-| MB |----|        |
                /  +----+     \\----//
               NR
                   private

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

           Figure 7: NAT to public, both host behind same NAT

   NSIS NATFW signaling protocol should support mechanisms to detect
   such a scenario.  The signaling should directly by exchanged between
   NI and NR without involving the middlebox.

2.1.7  IPv4/v6 NAT with two private networks

   This scenario combines the usage case mentioned in Section 2.1.2
   with the IPv4 to IPv6 transition scenario, i.e.  using Network
   Address and Protocol Translators (NAT-PT, [10]). [11]).

   The difference to the other scenarios is the use of IPv6 to IPv4 (and
   vice versa) address and protocol translation.  Additionally, the base
   NTLP must take care of this case for its own functionality of
   forwarding messages between NSIS peers.

        +----+  +----+   //---\\   +----+  //---\\   +----+  +----+
   NI --| MB |--| MB |--|       |--| MB |-|       |--| MB |--| MB |-- NR
        +----+  +----+   \\---//   +----+  \\---//   +----+  +----+

             private      public            public       private
                           IPv4              IPv6

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

            Figure 8: IPv4/v6 NAT with two private networks

   This scenario needs the same type of application level support as
   described in Section 2.1.5 and so those issues of twice-NATs apply
   here as well.

2.1.8  Multihomed Network with NAT

   The previous chapters sketched network topologies where NAT and
   Firewalls are ordered sequentially on the path.  This chapter
   describes a multihomed scenario with two NATs to the Internet.

             +----+
   NI -------| MB |\
       \     +----+ \  //---\\
        \            -|       |-- NR
         \             \\---//
          \  +----+       |
           --| MB |-------+
             +----+
             private
        private          public

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

               Figure 9: Multihomed Network with two NATs

   Depending on the destination the one or the other middlebox is used
   for the data flow.  Which middlebox is used depends on local routing
   decisions.  NATFW NSLP must be able to handle this situation proper,
   see Section 3.2.2 for a more elaborated discussion of this topic with
   respect to NATs.

2.2  Trust Relationship and Authorization

   Trust relationships and authorization are very important for the
   protocol machinery.  Trust and authorization are closely related to
   each other in the sense that a certain degree of trust is required to
   authorize a particular action.  For any action (e.g.  "create/delete /
   prolong
   /prolong policy rules" then authorization is very important due to
   the nature of middleboxes.

   It is particularly not surprising that different degrees of required
   authorization in a QoS signaling environment and middlebox signaling
   exist.  As elaborated in [19], [23], establishment of a financial
   relationship is very important for QoS signaling, whereas for
   middlebox signaling is not directly of interest.  For middlebox
   signaling a stronger or weaker degree of authorization might be
   needed.

   Different trust relationships that appear in middlebox signaling
   environments are described in the subsequent sections.  Peer-to-peer
   trust relationships are those, which are used in QoS signaling today
   and seem to be the simplest.  However, there are reasons to believe
   that this is not the only type of trust relationship found in today's
   networks.

2.2.1  Peer-to-Peer Trust Relationship

   Starting with the simplest scenario it is assumed that neighboring
   nodes trust each other.  The required security association to
   authenticate and to protect a signaling message is either available
   (manual configuration) or dynamically established with the help of an
   authentication and key exchange protocol.  If nodes are located
   closely together it is assumed that security association
   establishment is easier than establishing it between far distant
   node.  It is, however, difficult to describe this relationship
   generally due to the different usage scenarios and environments.
   Authorization heavily depends on the participating entities but for
   this scenario it is assumed that neighboring entities trust each
   other (at least for the purpose of policy rule creation, maintenance
   and deletion).  Note that Figure 9 10 does not illustrate the trust
   relationship between the end host and the access network.

   +------------------------+              +-------------------------+
   |                        |              |                         |
   |            Network A   |              |              Network B  |
   |                        |              |                         |
   |              +---------+              +---------+               |
   |        +-///-+ Middle- +---///////----+ Middle- +-///-+         |
   |        |     |  box 1  |   Trust      |  box 2  |     |         |
   |        |     +---------+ Relationship +---------+     |         |
   |        |               |              |               |         |
   |        |               |              |               |         |
   |        |               |              |               |         |
   |        |   Trust       |              |      Trust    |         |
   |        | Relationship  |              |  Relationship |         |
   |        |               |              |               |         |
   |        |               |              |               |         |
   |        |               |              |               |         |
   |     +--+---+           |              |            +--+---+     |
   |     | Host |           |              |            | Host |     |
   |     |  A   |           |              |            |  B   |     |
   |     +------+           |              |            +------+     |
   +------------------------+              +-------------------------+

               Figure 9: 10: Peer-to-Peer Trust Relationship

2.2.2  Intra-Domain Trust Relationship

   In larger corporations often more than one middlebox is used to
   protect different departments.  In many cases the entire enterprise
   is controlled by a security department, which gives instructions to
   the department administrators.  In such a scenario a peer-to-peer
   trust-relationship might be prevalent.  Sometimes it might be
   necessary to preserve authentication and authorization information
   within the network.  As a possible solution a centralized approach
   could be used whereby an interaction between the individual
   middleboxes and a central entity (for example a policy decision point
   - PDP) takes place.  As an alternative individual middleboxes could
   exchange the authorization decision to another middlebox within the
   same trust domain.  Individual middleboxes within an administrative
   domain should exploit their trust relationship instead of requesting
   authentication and authorization of the signaling initiator again and
   again.  Thereby complex protocol interaction is avoided.  This
   provides both a performance improvement without a security
   disadvantage since a single administrative domain can be seen as a
   single entity.  Figure 10 11 illustrates a network structure structure, which uses
   a centralized entity.

    +-----------------------------------------------------------+
    |                                                           |
    |                                               Network A   |
    |                                                           |
    |                                                           |
    |                      +---------+                +---------+
    |      +----///--------+ Middle- +------///------++ Middle- +---
    |      |               |  box 2  |                |  box 2  |
    |      |               +----+----+                +----+----+
    |      |                    |                          |    |
    | +----+----+               |                          |    |
    | | Middle- +--------+      +---------+                |    |
    | |  box 1  |        |                |                |    |
    | +----+----+        |                |                |    |
    |      |             |                |                |    |
    |      -             |                |                |    |
    |      -             |           +----+-----+          |    |
    |      |             |           | Policy   |          |    |
    |   +--+---+         +-----------+ Decision +----------+    |
    |   | Host |                     | Point    |               |
    |   |  A   |                     +----------+               |
    |   +------+                                                |
    +-----------------------------------------------------------+

               Figure 10: 11: Intra-domain Trust Relationship

2.2.3  End-to-Middle Trust Relationship

   In some scenarios a simple peer-to-peer trust relationship between
   participating nodes is not sufficient.  Network B might require
   additional authorization of the signaling message initiator.  If
   authentication and authorization information is not attached to the
   initial signaling message then the signaling message arriving at
   Middlebox 2 would cause an error message to be created, which
   indicates the additional authorization requirement.  In many cases
   the signaling message initiator is already aware of the additionally
   required authorization before the signaling message exchange is
   executed.  Replay protection is a requirement for authentication to
   the non-neighboring middlebox middlebox, which might be difficult to accomplish
   without adding additional roundtrips to the signaling protocol (e.g.
   by adding a challenge/response type of message exchange).

   Figure 11 12 shows the slightly more complex trust relationships in this
   scenario.

    +----------------------+              +--------------------------+
    |                      |              |                          |
    |          Network A   |              |              Network B   |
    |                      |              |                          |
    |                      | Trust        |                          |
    |                      | Relationship |                          |
    |            +---------+              +---------+                |
    |      +-///-+ Middle- +---///////----+ Middle- +-///-+          |
    |      |     |  box 1  |      +-------+  box 2  |     |          |
    |      |     +---------+      |       +---------+     |          |
    |      |               |      |       |               |          |
    |      |Trust          |      |       |               |          |
    |      |Relationship   |      |       |               |          |
    |      |               |      |       |   Trust       |          |
    |      |               |      |       |   Relationship|          |
    |      |               |      |       |               |          |
    |      |               |      |       |               |          |
    |      |               |      |       |               |          |
    |      |               |      |       |               |          |
    |   +--+---+           |      |       |            +--+---+      |
    |   | Host +----///----+------+       |            | Host |      |
    |   |  A   |           |Trust         |            |  B   |      |
    |   +------+           |Relationship  |            +------+      |
    +----------------------+              +--------------------------+

              Figure 11: 12: End-to-Middle Trust Relationship

3. Problems and Challenges

   This  Protocol Description

   The protocol description section describes defines the NSIS NATFW NSLP with its
   messages, objects, and the protocol semantics.  Section 3.1
   introduces the protocol and Section 3.3 defines the syntax of the
   messages and objects.  The protocol behavior is defined in Section
   3.2.

3.1  Basic protocol overview

   The NSIS Signaling Layer Protocol (NSLP) for NAT and FW traversal is
   carried over the NSIS Transport Layer Protocol (NTLP) defined in [3].
   NATFW NSLP messages are initiated by the NSIS initiator (NI), handled
   by NSIS forwarders (NF) and finally processed by the NSIS responder
   (NR).  It is required that at least NI and NR implement this NSLP,
   intermediate NF only implement this NSLP when they provide middlebox
   functions.  Forwarders that do not have any NATFW NSLP functions just
   forward these messages; those forwarders implement NTLP and one or
   more other NSLPs.

   A Data Sender (DS) that is intending to send data to a number Data Receiver
   (DR) must start its NATFW NSLP signaling.  So the NI at the data
   sender (DS) starts NSLP signaling towards the address of data
   receiver DR (see Figure 13).

             +-------+    +-------+    +-------+    +-------+
             | DS/NI |<~~~| MB1/  |<~~~| MB2/  |<~~~| DR/NR |
             |       |--->| NF1   |--->| NF2   |--->|       |
             +-------+    +-------+    +-------+    +-------+

                 ========================================>
                         Data Traffic Direction

                  --->  : NATFW NSLP request signaling
                  ~~~>  : NATFW NSLP response signaling
                  DS/NI : Data sender and NSIS initiator
                  DR/NR : Data receiver and NSIS responder
                  MB1   : Middlebox 1 and NSIS forwarder 1
                  MB2   : Middlebox 2 and NSIS forwarder 2

                   Figure 13: General NSIS signaling

   The NSLP request messages are processed each time a NF with NATFW
   NSLP support is passed.  Those nodes process the message, check local
   policies for authorization and authentication, possibly create policy
   rules, and forward the signaling message to the next NSIS node.  The
   request message is forwarded until it reaches the NSIS responder.
   NSIS responders will check received messages and process those if
   applicable.  NSIS responders generate response messages and sent them
   back to the NI via the same chain of NFs.  The response message is
   processed at each NI forwarder implementing NATFW NSLP.  The Data
   Sender can start sending its data flow to the Data Receiver, when the
   signaling was successful, meaning that NI has received a successful
   response.

   In general, NATFW NSLP signaling follows the data path from DS to DR.
   This enables communication between both hosts for scenarios with only
   Firewalls on the data path or NATs on sender side.  For scenarios
   with NATs on the receiver side certain problems which have arise, see also
   Section 2.

   When Data receiver (DR) and Data Sender (DS) are located in different
   address realms and DR is behind a NAT, DS cannot signal to DR
   directly.  DR is not reachable from DS and thus no NATFW signaling
   can be
   addressed sent to DR's address.  Therefore, DR must first determine an
   address at a NAT that is reachable for NSIS NAT/Firewall. These might DS, for instance DR must
   determine its public IP address.  Once DR has determined a public
   address it forwards this to DS via a separate mechanism, which may be also
   application level signaling like SIP.  This application level
   signaling may involve third parties that assist in exchanging this
   information.  This separate mechanism is out of relevance scope of NATFW NSLP.

   NATFW NSLP signaling supports this public address fixing with this
   mechanism:
   o  First, DR determines a public address by signaling on the reverse
      path (DR towards DS) and thus making itself available to other NSLP protocols.

3.1 Missing Network-to-Network Trust Relationship

   Peer-to-peer trust relationship,
      hosts.  This process of determining a public addresses is called
      reservation.  This way DR reserves publicly reachable addresses
      and ports, but this address/port cannot be used by data traffic at
      this point of time.
   o  Second, DS is signaling directly to DR as shown DS would do if there is
      no NAT in Figure 9, between, and so creating policy rules at middleboxes.
      Note, that the reservation  mode will make reservations only,
      which will be "activated" by the signaling from DS towards DR.
      The first mode is detailed in the Section 3.2.2

   The protocol works on a very
   convenient assumption soft-state basis, meaning that allows simplified signaling message
   processing. However, that whatever
   state is installed or reserved on a middlebox, it might not always will expire, and
   thus be applicable, especially
   between two arbitrary access networks (over de-installed/ forgotten after a core network where
   signaling messages are not interpreted).   Possibly peer-to-peer
   trust relationship does not exist because certain period of time.  To
   prevent this, the large number involved boxes will have to specifically request a
   session extension.  An explicit NATFW NSLP state deletion message is
   also provided by the protocol.

   Middleboxes should report back in case of
   networks error, so that appropriate
   measures and debugging can be performed.

   The next sections define the unwillingness of administrators to have other
   network operators NATFW NSLP message types and formats,
   protocol operations, and policy rule operations.

3.2  Protocol Operations

   This section defines the protocol operations, how to create holes sessions,
   maintain them, and how to reserve addresses.

3.2.1  Creating Sessions

   Allowing two hosts to exchange data even in their firewalls without proper
   authorization. Hence the presence of
   middleboxes is realized in the following scenario we assume NATFW NSLP by the 'create session'
   request message.  The data sender generates a somewhat
   different 'create session'
   message processing as defined in Section 3.4.2 and show three possible approaches handles it to
   tackle the problem. None NTLP.  The
   NTLP forwards the whole message on the basis of these three approaches the flow routing
   information towards DR.  Each NSIS forwarders along the path that is without
   drawbacks
   implementing NATFW NSLP process the NSLP message, this is done NSLP
   hop-by-hop.  Finally, the message is approaching DR, DR can accept
   the request or constraining assumptions.

   +----------------------+              +--------------------------+
   |                      |              |                          |
   |          Network A   |              | reject it.  DR generates a response to the request,
   this response is transported hop by hop towards (XXX terminology) DS.
   NATFW NSLP forwarders may reject requests at any time.  Figure 14
   sketches the message flow between NI (DS), a NF (NAT), and NR (DR).

       NI      Private Network B   |
   |                      |              |                          |
   |            +---------+   Missing    +---------+                |
   |      +-///-+ Middle- |    Trust        NF    Public Internet        NR
       | Middle- +-///-+                              |                            |
       | Create                       |  box 1                            |   Relation-
       |----------------------------->|                            |  box 2
       |                              |                            |
       | Error (if necessary)         |     +---------+     ship     +---------+                            |
       |<-----------------------------| Create                     |
       |                              |--------------------------->|
       |                              |     or                            |
       |                              |       Path Succeeded/Error |
       |         Path Succeeded/Error |<---------------------------|
       |<-----------------------------|                            | Authorization|
       |                              |                            |
       |                              |                            |

                    Figure 14: Creation message flow

   Processing of 'create session' messages is differently per NSIS node:
   o  NSLP initiator:  NI only generate 'create session' messages and
      handle them over to the NTLP.  After receiving a 'path succeeded'
      the data path is configured and the NI can start sending its data
      to NR.  After receiving an 'error' message the NI MAY try to
      generate the 'create session' message again or give up, depending
      on the error condition.
   o  NSLP forwarder:  NSLP forwarders receiving 'create session'
      messages MUST first check authentication and authorization before
      any further processing is executed.  The NF SHOULD check with its
      local policies if he can accept the desired policy rule given by
      NTLP's flow routing information.  Further processing depends on
      the middlebox type:
      *  NAT:  When the 'create session' message is received at the
         public side a network external node is trying to open a NAT
         binding.  First, it looks for a reservation made in advance by
         means of 'reserve external address' that matches the
         destination address/port of the flow routing information
         provided by the NTLP.  If there is no reservation made in
         advance the NSLP SHOULD return an error message of type 'no
         reservation found' and discard the request.  If there is a
         reservation, NSLP stores the data sender's address as part of
         the policy rule to be loaded and forwards the message with the
         address set to the internal address of the next NSIS node.
         When the 'create session' message is received at the private
         side the NAT binding is reserved, but not activated.  The NSLP
         message is forwarded to next hop with source address set to the
         NAT's external address.
      *  Firewall: When the 'create session' message is received the
         NSLP just remembers the requested policy rule, but does not
         install any policy rule.  Afterwards, the message is forwarded
         to the next NSLP hop.
      *  Combined NAT and Firewall:  Processing at combined Firewall and
         NAT middleboxes is the same as in the NAT case.  No policy
         rules are installed.  Implementations MUST take care about the
         order of Firewall and NAT functions within the device.  Order
         of functions is to be interpreted as how packets experience the
         treatment of those functions.
   o  NSLP receiver: NRs receiving 'create session' messages MUST reply
      with a 'path succeeded' message if they accept the request
      message.  Otherwise they SHOULD generate an error message.  Both
      messages are sent back NSLP hop-by-hop towards NI.

   Policy rules at middleboxes MUST be only installed upon receiving a
   successful response of type 'path succeeded'.  This is a
   countermeasure to several problems, for instance, loaded policy rules
   at intermediate NF without reaching the actual NR.

3.2.2  Reserving External Addresses

   NSIS signaling is intended to travel end-to-end, even in the presence
   of NATs and Firewalls on-path.  This works well in cases where the
   data sender is itself behind a NAT and (covered by Section 3.2.1).
   For scenarios where the data receiver is located behind a NAT and it
   needs to receive data flows from outside its own network (see Figure
   5) it is more troublesome.  NSIS signaling, as well as subsequent
   data flows, are directed to a particular destination IP address that
   must be known in advance and reachable.

                      +-------------+   AS-Data Receiver Communication
            +-------->| Application |<-----------------------------+
            |         | Server      |                              |   Trust
            |         +-------------+                              |      Trust
            |                                          IP(R-NAT_B) |
            |         NSIS Signaling Message               +-------+--+
            | Relationship  +------------------------------------------>| NAT/NAPT |
            |  Relationship  |                                           | B        |
            |  |                                           +-------+--+
            |  |                                                   |
     AS-Data|  |                                                   |
    Receiver|  |                       +----------+                |
       Comm.|  |                       | NAT/NAPT |                |
            |  |                       | A        |                |   +--+---+
            |  |            +--+---+                       +----------+                |
            |  | Host                                                   |
            |  |                                                   | Host
            |  |                                                   |
            |  A  |                                                   |
            v  |                                             IP(R) v
        +--------+                                          +---------+
        |  B Data   |                                          | Data    |   +------+
        | Sender |            +------+                                          |
   +----------------------+              +--------------------------+ Receiver|
        +--------+                                          +---------+

            Figure 12: Missing Network-to-Network Trust Relationship 15: The Data Receiver behind NAT problem

   Figure 12 illustrates 15 describes a problem whereby an external node is not
   allowed to manipulate (create, delete, query, etc.) packet filters at typical message communication in a firewall.  Opening pinholes is only allowed for internal nodes or peer-to-peer
   networking environment whereby the two end points learn of each
   others existence with the help of a certain authorization permission. Hence third party (referred as
   Application Server).  The communication with the solution
   alternatives in Section 4 focus on establishing application server
   and the necessary trust
   with cooperation two end points  (data sender and data receivers) serves a
   number of internal nodes.

3.2 End-to-end significance

   In the case functions.  As one of NAT/firewalls traversal, the NSIS signaling messages
   need most important functions it
   enables the two end hosts to be sent all they way from learn the DS and DR or vice versa.  This IP address of each other.  The
   approach described in this memo supports this peer-to-peer approach,
   but is so because a middlebox does not know whether the remaining path limited to it.

   Some sort of communication between the destination data sender/data receiver and
   a third party is clear typically necessary (independently of potentially obstructing middleboxes or
   not.

3.3 Relationship NSIS).  NSIS
   signaling messages cannot be used to communicate application level
   relevant end point identifiers (in the generic case at least) as a
   replacement for the communication with routing

   The the application server.

   If the data path receiver is following behind a NAT then an NSIS signaling message
   will be addressed to the "normal" routes. The NAT/FW devices
   along IP address allocated at the data path are those providing NAT (if there
   was one allocated).  If no corresponding NSIS NAT Forwarding State at
   NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the service.  In this case signaling
   message will terminate at the service is something like "open a pinhole" or even more general
   "allow for connectivity between two communication partners". NAT device (most likely without proper
   response message).  The
   benefit of using path-coupled signaling is that message transmitted by the NSIS NATFW NSLP
   does not need to determine what middleboxes data
   sender cannot install the NAT binding or in what order NSIS NAT Forwarding State
   "on-the-fly" since this would assume that the data
   flow will go through.

   Creating sender knows the
   topology at the data receiver side (i.e.  the number and the
   arrangement of the NAT bindings modifies and the path private IP address(es) of the data packets between two
   receiver).  The primary goal of path-coupled middlebox communication
   was not to force end points.  Without NATs involved, packets flow from endhost hosts to
   endhost following the path given by the routing.  With NATs involved, have this end-to-end flow is not directly possible, because type of separated
   address realms.  Thus, data packets topology knowledge.

            Public Internet              Private Address
                                              Space
                                  Edge
    NI(DS)                        NAT        NAT                NR(DR)
    NR+                                                         NI+
    |                              |          |                 |
    |                              |          |                 |
    |                              |          |                 |
    |                              | Reserve  |         Reserve |
    |                              |<---------|<----------------|
    |                              |          |                 |
    |                              | Return   | ext addr/Error  |
    |                              |--------->|---------------->|
    |                              |          |                 |
    |                              |          |                 |

       ====================================================>
                        Data Traffic Direction

                  Figure 16: Reservation message flow towards

   Figure 16 shows the message flow for reserving an external IP
   address address/
   port at a NAT (external IP address may be a public IP address).
   Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with
   routing - instead they only follow NAT.  In this case the path roles of the different NSIS entities
   are:
   o  The actual data  packets.

3.4 Dynamic state installation and maintenance

   For NAT/Firewall traversal, the lifetime of a NAT binding or a packet
   filter is maintained through periodic refresh.  For short-lived
   flows, having unpredictable filters, signaling for dynamically policy
   rules receiver (DR) is preferable as opposed to statically configured policy rules
   requested the NSIS initiator (NI+) for long duration in time.

   For static state other mechanisms than an the
      'reserved external address' message, but the NSIS signaling protocol
   might responder (NR)
      for 'create session' messages following later.
   o  The actual data sender (DS) will be preferable; such mechanisms would include a management
   protocols such as SNMP or command line interfaces.

3.5 Affected Parts of the Network

   NATs NSIS initiator (NI) for
      later 'create session' messages and Firewalls are usually located at may be the edge NSIS target of the network,
   whereby other
      signaling applications affect all nodes along (NR+).
   o  The actual target of the path.
   One typical example is QoS 'reserved external address' message may
      be an arbitrary address NR+.

   The data receiver DR starts to signal an 'reserve external address'
   message into the "wrong direction".  By "wrong" we refer to the usual
   behavior of path-coupled signaling where all networks along the
   path must provide QoS data sender starts
   signaling in order to achieve true end-to-end QoS.  In
   the NAT/Firewall case, only some of tackle with routing asymmetry.  The data
   receiver would typically return signaling messages to the domains/nodes are affected
   (typically access networks), whereas most parts of data sender
   in the networks and reverse direction by utilizing state created at nodes are unaffected (e.g. along
   the core network).

   This fact raises some questions.  Should an NSIS NTLP node intercept
   every path (i.e.  to reverse route signaling message independently messages).  In case of
   establishing NAT bindings (and NSIS NAT Forwarding State) the upper layer signaling
   application or should it be possible to make
   direction does not matter since the discovery procedure
   more intelligent to skip nodes. These questions are also related data path is modified through
   route pinning due to the question whether NSIS NAT/FW should be combined with other external NAT address.  Subsequent NSIS
   messages (and also data traffic) will travel through the same NAT
   boxes.  The signaling applications.

3.6 target address selection for this message is
   discussed in Section 3.2.10.

   The signaling message creates NSIS backward compatibility with NAT Forwarding State at
   intermediate NSIS unaware NAT and Firewalls

   Backward compatibility is a key for NSIS deployments, as such the
   NSIS protocol suite should be sufficiently robust to allow traversal
   of none NSIS aware routers (QoS gates, Firewalls, NATs, etc ).

   NSIS NATFW NSLP's backward compatibility issues is different than the
   NSIS QoS NSLP backward compatibility issues, where an NSIS unaware
   QoS gate will simply forward the QoS NSLP message. An NSIS unaware
   firewall rejects NSIS messages, since firewalls typically implement
   the policy "default node(s).  Furthermore it has to deny".

   The NSIS backward compatibility support on none NSIS aware firewall
   would typically consist of configuring a static policy rule be ensured that
   allows the forwarding of
   the NSIS protocol messages (either protocol
   type if raw transport mode is used or transport port number in case a
   transport protocol is used).

   For NATs backward compatibility edge NAT device is more problematic since signaling
   messages are forwarded (at least in one direction), but with a
   changed IP address and changed port numbers.  The content of the NSIS
   signaling message is, however, unchanged.  This can lead to
   unexpected results, both due to embedded unchanged local scoped
   addresses and none NSIS aware firewalls configured with specific
   policy rules allowing forwarding of the NSIS protocol (case discovered as part of
   transport protocols are used for the NTLP).  NSIS unaware NATs must this process.  The end
   host cannot be detected assumed to maintain a well known deterministic mode of operation
   for all know this device - instead the involved NSIS entities.  Such a "legacy" NAT detection
   procedure can be done during the NSIS discover procedure itself.

   Based on experience it was discovered box
   itself is assumed to know that routers unaware it has such a capability.  Forwarding
   of the
   Router Alert IP option [RFC 2113] discarded packets, 'reserve external address' message beyond this entity is
   certainly a problem for NSIS signaling.

3.7 Authentication and Authorization

   For both types of middleboxes, firewall and NAT security is a strong
   requirement.  Authentication not
   necessary, and authorization means must should be
   provided.

   For NATFW signaling applications prohibited as it is partially not possible to do
   authentication and authorization based provides information on IP addresses.  Since NATs
   change IP addresses, such
   internal hosts capabilities.

   The edge NAT device is responding with a address based authentication and
   authorization scheme would fail.

3.8 Directional Properties

   There two directional properties that need to be addressed by 'return external address'
   message containing the
   NATFW NSLP:

   o  Directionality public reachable IP address/port number.

   Processing of the data 'reserve external address' messages is differently per
   NSIS node:
   o  Directionality of NSLP signaling

   Both properties are relevant to NATFW  NSLP aware NATs initiator: NI+ only generate 'reserve external address'
      messages and Firewalls.

   With regards to should never receive them.
   o  NSLP signaling directionality: As stated in the
   previous sections, the forwarder: NSLP forwarders receiving 'reserve external
      address' messages MUST first check authentication and
      authorization of NSLP
   signaling messages received from hosts within the same trust domain
   (typically from hosts located within the security perimeter delimited
   by firewalls) before any further processing is normally simpler than received messages sent by
   hosts located in different trust domains. executed.  The way NSIS signaling messages enters the NSIS agent of a firewall
   (see Figure 2) might be important, because different NF
      SHOULD check with its local policies might
   apply for authentication and admission control.

   Hosts deployed within the secured network perimeter delimited by a
   firewall, are protected from hosts deployed outside if he can accept the secured
   network perimeter, hence desired
      policy rule given by nature the firewall has more restrictions
   on flows triggered from hosts deployed outside the security
   perimeter.

3.9 Routing Asymmetry

   Routing asymmetry [20] is a general problem for path-coupled
   signaling, especially when installed states on NSIS forwarders are
   related to bi-directional flows.

   Path state, on an NSIS forwarder, including the next NSIS hop (for
   packets sent from the NR to NI), is used to handle routing asymmetry
   for NSIS messages, but not for data flows (i.e. no route pinning for
   data flows).

   Similarly to path-coupled QoS signaling, middlebox signaling also has
   to be aware of the NTLP's flow routing asymmetry when bi-directional flows
   relevant states need to be installed information.  Further
      processing depends on NSIS aware nodes, although
   the routing asymmetry might not be significant within the local
   networks where firewalls are typically located. For signaling NAT
   bindings this issue comes with a different flavor since an
   established NAT binding changes the path of the data packets. Hence a
   data receiver might still be able to send NSIS signaling messages to
   create a NAT binding, although they travel the previously "wrong"
   path.

3.10 Addressing

   A more general problem of middlebox type:

      *  NAT:  NATs check whether the message is received at the addressing of public
         address or at the end-point.
   NSIS signaling message have to be addressed to private address.  If received at the other end host to
   follow data packets subsequently sent. Therefore, a public IP
         address a NF MAY generate an error message of type 'requested
         external address from outside'.  If received at the receiver has to be known prior to sending private
         address, an NSIS message.
   When NSIS signaling messages contain IP addresses of the sender and address/port is reserved.  In the receiver in case it is an
         edge-NAT, the signaling NSLP message payloads, then an NSIS agent
   must modify them. This is one of the cases, where not forwarded anymore and a NSIS aware NATs
   is also helpful for other types
         response of signaling applications e.g. QoS
   signaling.

3.11 NTLP/NSLP NAT Support

   It must be possible for NSIS NATs along type 'return external address' is generated.  If it
         is not an edge-NAT, the path to change NTLP and/
   or NSLP message payloads , which carry IP address and port
   information.  This functionality includes the support of providing
   mid-session and mid-path modification of these payloads. As a
   consequence these payloads must is forwarded further.
      *  Firewall:  Firewalls MUST not be reordered, integrity protected
   and/or encrypted in a non peer-to-peer fashion (e.g. end-to-middle,
   end-to-end protection). Ideally these mutable payloads must be marked
   (e.g. a protected flag) to assist NATs in change their effort of adjusting
   these payloads.

3.12 Route changes

   The effect of route changes are more severe than in other signaling
   applications since configuration upon a firewall pinhole
         'reserve external address' message.  They simply MUST forward
         the message and MUST keep NTLP state.  Firewalls that are
         configured as edge-Firewalls (XXX, do definition!) MAY return
         an error of type 'no NAT here'.
      *  Combined NAT binding is needed
   before further communication can take place.  This is true for both
   NSIS signaling and for subsequent data traffic.  If a route changes and NSIS signaling messages do not configure NSIS NATs Firewall:  Processing at combined Firewall and firewalls
   along
         NAT middleboxes is the new path then same as in the communication is temporarily interrupted. NAT case.
   o  NSLP receiver:  This is naturally a big problem for networks where routes frequently
   change e.g. ad-hoc networks or in case type of fast mobility.  In these
   cases state refresh messages have to provide a mechanism for fast
   reaction.

3.13 Combining Middlebox and QoS signaling

   In many cases, middlebox and QoS signaling has to message should never be combined at
   least logically.  Hence, received by
      any NR and it was suggested to combine them into a
   single signaling message or to tie them together with the help of
   some sort SHOULD be discarded silently.

   Processing of data connection identifier, later on referred as Session
   ID.  This, however, has some disadvantages such as:

   - NAT/FW 'return external address' messages is differently per
   NSIS node:
   o  NSLP signaling affects initiator:  Upon receiving a much small number of NSIS nodes
   along 'return external address'
      message the path (for example compared to NI+ can use the QoS signaling).

   - NAT/FW signaling might show different signaling patterns (e.g.
   required end-to-middle communication).

   - The refresh interval is likely to be different.

   - The obtained IP address and port number of error cases increase
      for further application signaling.
   o  NSLP forwarder: NFs simply forward this message as different signaling
   applications are combined into a single message. The combination long as they
      keep state for the requested reservation.
   o  NSIS responder:  This type of
   error cases has to message should never be considered.

3.14 Difference between sender- received by
      any NR and receiver-initiated signaling

   For NAT/FW signaling there seems to it SHOULD be little difference between
   sender- discarded silently.

3.2.3  Reserving External Addresses and receiver-initiated signaling messages. Create Session

   Some other
   characteristics of QoS signaling protocols are not applicable (e.g.
   the adspec object) migration scenarios need specialized support to cope with the NAT/FW context.  It seems that a full
   roundtrip is always required if
   situation where the protocol aims to be generic
   enough.

3.15 Inability receiving side is running NSIS only.  End-to-end
   signaling is going to know fail without NSIS support at both sides.  For
   this the scenario 'create-reverse' signaling mode is supported.  In Section 2.1 this case,
   a number of different scenarios are presented.  Data
   receiver and sender may be located behind zero, one, or more
   firewalls and NATs. Depending on the scenario, different signaling
   approaches have to be taken.  For instance,  data receiver with no
   NAT and firewall DR can receive any sort of data signal towards the DS like in the 'reserve external address'
   message scenario.  The message is forwarded until it reaches the
   edge-NAT and signaling without
   any further action.  Data receivers behind a NAT must first obtain retrieves a public IP address before any signaling can happen. The scenario might
   even change over time with moving networks, ad-hoc networks or with
   mobility.

   NSIS signaling must assume the worst case and cannot put
   responsibility to port number.  Unlike
   in the user to know which scenario 'reserve external address' no 'return external address'
   response message is currently
   applicable.  As a result, it  might be necessary to perform a
   "discovery" periodically such that created, the NSIS agent at forwarding of the end host has
   enough information to decide which scenario is currently applicable.

   This additional messaging, which might not be necessary in all cases,
   requires additional performance, bandwidth request message
   stops and adds complexity.
   Additional, information a 'create session' message is generated by the user can provide information to assist
   this "discovery" process but cannot replace it.

4. NSIS NAT Handling Solution edge-NAT.
   This section describes a mechanism for allowing NSIS signaling
   messages to travel end-to-end in request message is sent towards DR with DS as source address and
   follows the presence regular processing orders as 'create session' messages
   do.  The exact definition of NATs at the
   receiving side.  This requires this mode is to establish state information at be done.

3.2.4  Prolonging Sessions

   NATFW NSLP sessions are maintained on a soft-state base.  After a
   certain timeout sessions and corresponding policy rules are removed
   automatically by the
   NSIS-aware NAT device.

   Note: The discussed mechanism only creates state relevant for NSIS
   message handling.  It does middlebox, if they are not create NAT bindings for data traffic.

4.1 Problem Description refreshed by a
   prolong session message.  NI is sending prolong message towards NR
   and each NSIS signaling messages follow forwarder maintaining state for the data path from given session ID
   extends the data sender to lifetime of the data receiver.  To provide this property session.  Extending lifetime of being path-coupled a
   discovery process sends signaling messages along the same route session
   is calculated as
   taken by subsequent data packets.  The NSIS messages are directed to
   a particular destination IP address and hence current local time plus lifetime.  Section 3.2.7 is
   defining the destination address
   needs to be known process of calculating lifetimes in advance before NSIS signaling can start.

                      +-------------+   AS-Data Receiver Communication
            +-------->| Application |<-----------------------------+
            |         | Server      |                              |
            |         +-------------+                              |
            |                                          IP(R-NAT_B) |
            |         NSIS Signaling Message               +-------+--+
            |  +------------------------------------------>| NAT/NAPT detail.

      NI      Public Internet        NAT    Private address       NR
      |                              |          space             |
      | B Prolong                      |                            |
      |----------------------------->|                            |                                           +-------+--+
      |                              |                            |
     AS-Data|
      | Error (if necessary)         |
    Receiver|                            |                       +----------+
      |<-----------------------------| Prolong                    |
       Comm.|
      |                              |--------------------------->|
      | NAT/NAPT                              |                            |
      |                              |       Error (if necessary) | A
      |         Error (if necessary) |<---------------------------|
      |<-----------------------------|                            |
      |                              |                       +----------+                            |
      |                              |                            |

                  Figure 17: Prolongation message flow

   Processing of 'prolong session' messages is differently per NSIS
   node:
   o  NSLP initiator: NI can generate 'prolong session' messages before
      the session times out.
   o  NSLP forwarder: NSLP forwarders receiving 'prolong session'
      messages MUST first check authentication and authorization before
      any further processing is executed.  The NF SHOULD check with its
      local policies if he can accept the desired lifetime extension for
      the session referred by the session ID.  Processing of this
      message is independent of the middlebox type.
   o  NSLP responder: NIs accepting this prolong message generate a
      'path succeeded' message.

3.2.5  Deleting Sessions

   NATFW NSLP sessions may be deleted at any time.  NSLP initiators can
   trigger this deletion via the 'delete session' message, as shown in
   Figure 17.

      NI      Public Internet        NAT    Private address       NR
      |                              |          space             |
      | Delete                       |                            |
      |----------------------------->|                            |
      |                              |
            v                            |                                             IP(R) v
        +--------+                                          +---------+
      | Data                              | Delete                     | Data
      |                              |--------------------------->|
      | Sender                              |                            | Receiver|
        +--------+                                          +---------+

            Figure 13: The Data Receiver behind NAT problem

                     Figure 13 describes a typical 18: Delete message communication in a peer-to-peer
   networking environment whereby flow

   NSLP nodes receiving this message MUST delete the two end points learn of each
   others existence with session
   immediately.  Corresponding policy rules to this particular session
   MUST be deleted immediately, too.  This message is forwarded until it
   reaches the help of a third party (referred as
   Application Server). final NR.  The communication with 'delete' message does not generate any
   response, neither positive nor negative, since there is no NSIS state
   left at the application server
   and nodes along the two end points  (data sender path.

3.2.6  Authorization

   Authorization and data receivers) serves security issues are currently discussed in a
   number of functions.  As one
   different document and will be included after reaching consensus (
   [20]).

3.2.7  Calculation of Lifetimes

   NATFW NSLP sessions, and the most important functions it
   enables the two end hosts to learn corresponding policy rules possibly
   installed, are maintained via soft-state.  Each session is assigned a
   lifetime and they are kept alive as long as the IP address of each other.

   Without lifetime is valid.
   After the proposed mechanism it would not be possible to establish
   a NAT binding end-to-end in all scenarios.

   Some sort expiration of communication between the end hosts lifetime sessions and a third party is
   typically necessary (independently of NSIS).  NSIS signaling messages
   cannot policy rules MUST
   be used removed automatically and resources bound to communicate application level relevant end point
   identifiers (in the generic case at least) them should be freed
   as a replacement for the
   communication with the application server.

   If the data receiver well.  Session lifetime is behind a NAT then an NSIS signaling message
   will be addressed to the IP address allocated at the NAT (if there
   was one allocated).  If no corresponding NSIS NAT Forwarding State at
   NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the signaling
   message will terminate kept at the NAT device (most likely without proper
   response message). every NATFW NSLP node.  The signaling message transmitted by the data
   sender cannot install the NAT binding or NSIS NAT Forwarding State
   "on-the-fly" since this would assume that the data sender knows the
   topology at the data receiver side (i.e. the number and the
   arrangement of the NAT
   NSLP forwarders and the private IP address(es) of the data
   receiver).  The primary goal of path-coupled middlebox communication
   was NSLP responder are not to force end hosts to have responsible for triggering
   lifetime prolongination messages (see Section 3.2.4), this type of topology knowledge.

   A number is the
   task of solutions exist to allow nodes behind a NAT to establish
   a NAT binding to allow the receiver to receive IP packets. These
   solutions can at best be labeled as hacks (see [NATP2P]) and they
   have their drawbacks:

   o  They assume NSIS initiator.

   NSIS initiator MUST choose a certain behavior of NAT boxes.

   o  They work in some environments whereas in others lifetime value before they do not
      properly function.

   o  They only allow NAT bindings for UDP traffic can sent any
   message (except 'delete session' messages) to be established.

   o  They often fail.

   Some other solutions assume that both nodes are registered NSLP nodes.  This
   lifetime value should consider application's needs, i.e., duration in
   terms of minutes or hours, and networking needs, i.e., values in the DNS
   directory (see [12]).

   The requirements for an NSIS solution are two-fold:

   1.  NSIS signaling messages must
   range less than 30 seconds may not be able to travel end-to-end
       (between data sender and data receiver) - if desired. useful.  This requested
   lifetime value is
       important for a number of NSIS NSLPs

   2.  NSIS relies on a generic solution which works placed in all scenarios
       (see section 5 the 'lifetime object' of [26]).

   Since the NSIS signaling NSLP message
   and messages are intercepted at each NSIS
   device, forwarded to the NAT solution depends on next NATFW NSLP node.

   NATFW NSLP forwarders processing the properties of request message along the NTLP. In
   particular, multiplexing capability is important. Two possible
   options are feasible:

   1.  Multiplexing with path
   MAY lower the help of transport layer information (i.e.
       port information)

   2.  Multiplexing at request lifetime given to fit their needs and/or local
   policy.  NATFW forwarders MUST NOT increase the NSIS application layer (e.g. based on session
       identifier)

   We describe lifetime value; they
   MAY reject the second approach although we believe that alternatives
   are possible.

   Enough information has to be available to convert IP address
   information of requested lifetime immediately and MUST generate an incoming signaling
   error response message to different IP
   addresses of an outgoing NSIS message. Finally the signaling type 'lifetime too big' upon rejection.
   The NSLP request message
   must reach is forwarded until it reaches the data receiver.

   It seems that NSLP
   responder.  NSLP responder MAY reject the session identifier can be used to associate state
   information requested lifetime value
   and MUST generate an error response message of type 'lifetime too
   big' upon rejection.  NSLP responder MAY lower the two independent signaling exchanges. The two
   exchanges (as described in Section 4.2) are:

   1.  Signaling exchange from the data receiver (NR) requested lifetime
   as well to the NAT(s)

   2.  End-to-end NSIS signaling a granted lifetime.  NSLP responders generate their
   appropriate response message exchange from the NI to for the NR.

   If received request message, sets
   the session identifier is used for this purpose then it is
   necessary lifetime value to communicate the session ID from above granted lifetime and sends the data receiver (NR)
   to
   message back hop-by-hop towards NSLP initiator.

   Each NSLP forwarder processes the NI. Communicating response message, reads and stores
   the IP address information instead (as an
   alternative solution approach) is easier since this functionality is
   already provided by SIP whereas securely exchanging (e.g.
   confidentiality protected) granted lifetime value.  The forwarders SHOULD accept the Session Identifier granted
   lifetime, as long as the value is not available.

4.2 Solution Overview

   The data receiver starts to signal an NSIS Create-NAT-Binding message
   into equal or lower than the "wrong direction".  By "wrong" we refer to requested
   lifetime.  They MAY reject the usual
   behavior of path-coupled signaling where lifetime and generate a 'lifetime not
   acceptable' error response message.  Figure 19 shows the data sender starts
   signaling in order to tackle procedure
   with routing asymmetry.  The data
   receiver would typically return signaling messages to the data sender an example, where an initiator requests 60 minutes lifetime in
   'create session' message and the reverse direction by utilizing state created at nodes lifetime is shortened along the path (i.e.
   by the forwarder to reverse route signaling messages). The concept of
   path-coupled or path-decoupled signaling is, however, no relevant for
   this special type of signaling communication.  In case of
   establishing NAT bindings (and NSIS NAT Forwarding State) 20 minutes and by the
   direction does not matter since responder to 5 minutes.

   +-------+ CREATE(lt=60m)  +-----------+ CREATE(lt=20m)  +--------+
   |       |---------------->|    NSLP   |---------------->|        |
   |  NI   |                 |           |                 |  NR    |
   |       |<----------------| forwarder |<----------------|        |
   +-------+    OK(lt=5m)    +-----------+    OK(lt=5m)    +--------+

      lt = lifetime
      CREATE = 'create session' message
      OK = 'path succeeded' message

                Figure 19: Lifetime Calculation Example

3.2.8  Middlebox Resource

   This section needs to be done and should describe how to map flow
   routing is modified. Subsequent NSIS
   messages (and also data traffic) will travel through the same NAT
   boxes.

   The proposed solution requires two information to middlebox policy rules.  Further, this section
   should clarify wildcarding.  XXX

3.2.9  De-Multiplexing at NATs

   Section 3.2.2 describes how NSIS signaling messages:

   1.  Reserve External Address Request

   2.  Reserve External Address Acknowledgment nodes behind NATs can obtain a
   public reachable IP address and port number at a NAT.  The semantics of the two messages will
   information IP address/port number can be described in detail in this
   section.

   The data receiver sends transmitted via a Reserve External Address NSIS signaling
   message into the local network (before
   protocol and/or third party to the communication partner that would
   like to send data sender starts towards.  However, NSIS
   signaling). In Section Section 4.2.1 we will discuss where to address
   this signaling message (i.e. which destination IP address to use).

   The signaling message creates NSIS NAT Forwarding State at
   intermediate NSIS NAT node(s). Furthermore it has to be ensured that flows are sent
   towards the edge NAT device is discovered as part address of this process. The end
   host cannot be assumed to know this device - instead the NAT box
   itself is assumed to know that it has such a capability.  Forwarding
   of the Reserve External Address NSIS message beyond at which this entity is
   not necessary, particular IP address
   and should be prohibited as it provides information on
   internal hosts capabilities.

   						 Reserve External Address Request
             +-------+    +-------+    +-------+    +---------+
             | NAT X |<---| NAT Y |<---| NAT Z |<---| Data    |
             |       |--->|       |--->|       |--->| Receiver|
             +-------+    +-------+    +-------+    +---------+
                            Reserve External Address Response

                 ========================================>
                         Data Traffic Direction

       Figure 14: Reserve External Address NSIS Signaling Message port number is allocated.  The goal of NATFW NSLP forwarder at this signaling message exchange is:

   o  to create one (or more) NAT binding(s)

   o
   needs to allow know how the data receiver to learn its global routable IP address
      (for communication with NSIS)

   o  not incoming NSLP requests are related to require the data receiver reserved
   addresses, meaning how to learn topology information.

   Figure 14 shows a de-multiplex incoming requests.

   Two options for de-multiplexing incoming NSLP requests are:
   1.  Based on flow routing information, like protocol number of NAT devices at the data receivers network
   side. and TCP
       port numbers.
   2.  Based on NSIS NAT Forwarding State is established at these network
   elements.

   The Reserve External Address Request message triggers the state
   creation session IDs.

   Approach 2) would require that both NSIS ends, initiator and
   responder, use the discovery. The message carries information where the
   sender expects incoming same session ID in NSIS signaling.  Since session
   IDs are usually generated randomly, application level signaling messages.

   The Reserve External Address Response message confirms the state
   creation and allows would
   have to return information about the NATs and the
   topology be adapted to carry NSIS session IDs used during reservation
   to the other end host (for informational purposes). As a result
   the end host will learn (the NSIS initiator sending the 'create session'
   message).  This approach SHOULD NOT be used.

   Approach 1) uses information stored at NATs (like mapping of public
   IP address which can be used to private, transport protocol, port numbers) and
   information given by
   the data sender NTLP's flow routing information to address de-multiplex
   NSIS signaling messages.

4.2.1  This approach is RECOMMENDED.

3.2.10  Selecting Destination IP address Selection

   The Reserve External Address addresses for REA

   Request messages of type 'reserve external address' do need, as any
   other message has to be addressed type as well, a final destination IP address to reach.
   But as many applications do not provide a
   specific destination IP address.  Since address at
   the first place, there is no natural candidate a few alternatives might be considered.  The discussed options refer need to entities of Figure 13

   Possible options are:

   1.  Public IP choose a destination address for
   the 'reserve external address' messages.  This destination can be the
   final target, but for the mentioned type of application, the data sender

   2.  Public IP
   destination address of can be arbitrary.  Taking the data receiver (allocated at NAT B)

   3. "correct"
   destination IP address at the Application Server

   Actually, might be difficult and there is no "correct" answer to this question right
   answer.  [19] shows choices for SIP and from this section provides some
   hints about choosing a
   theoretical point of view it does not really matter as long as Host A
   learns an good destination IP address where he has to send the NSIS signaling message.
   From a performance point of view there is, however, a difference
   since it would be desirable to create an "optimal" routing path. in general.

   1.  Public IP address of the data sender:
       *  Assumption:
          +  The data receiver already learned the IP address of the
             data sender (e.g.  via a third party).
       *  Problems:
          +  The data sender might also be behind a NAT.  In this case
             the public IP address of the data receiver is the IP
             address allocated at this NAT.

          +  Due to routing asymmetry it might be possible that the
             routes taken by a) the data sender and the application
             server b) the data sender and NAT B might be different.  As
             a consequence it might be necessary to advertise a new (and
             different) external IP address with SIP after using NSIS to
             establish a NAT binding.
   2.  Public IP address of the data receiver (allocated at NAT B):
       *  Assumption:
          +  The data receiver already learned his externally visible IP
             address (e.g.  based on the third party communication).
       *  Problems:
          +  Communication with a third party is required.
   3.  IP address at the Application Server:
       *  Assumption:
          +  An application server (or a different third party) is
             available.
       *  Problems:
          +  If the NSIS signaling message is not terminated at the NAT
             of the local network then an NSIS unaware application
             server might discard the message.
          +  Routing might not be optimal since the route between a) the
             data receiver and the application server b) the data
             receiver and the data sender might be different.

5. Protocol Description

5.1 Basic protocol overview

   The NSIS Signaling Layer Protocol (NSLP) for NAT and FW traversal is
   carried over the NSIS Transport Layer Protocol (NTLP) defined in [3].

3.3  NATFW NSLP messages are initiated by the NSIS initiator, (NI) handled
   by NSIS forwarders (NF) Messages Components

   A NATFW NSLP message consists of a NSLP header and finally processed by one or more
   objects following the NSIS responder
   (NR).  It header.  The NSLP header is required that at least NI common for all
   NSLPs and NR implement this NSLP,
   intermediate NF only implement this NSLP when they provide middlebox
   functions. Forwarders objects are Type-Length-Value (TLV) encoded using big
   endian (network ordered) binary data representations.  Header and
   objects are bound to 32 bits and objects that do not have any NATFW fall into 32
   bits boundaries must be padded to 32 bits.

   The whole NSLP functions just
   forward these messages; those forwarders implement message is carried in a NTLP and one or
   more other NSLPs.

   A Data Sender (DS) message.

   Note that intents to send data the notation 0x is used to a Data Receiver (DR)
   must start its NATFW indicate hexadecimal numbers.

3.3.1  NSLP signaling.  So the NI at Header

   The NSLP header is common to all NSLPs and is the data sender
   (DR) starts first part of all
   NSLP signaling towards messages.  It contains two fields, the address NSLP message type and a
   reserved field.  The total length is 32 bits.  The layout of data receiver DR
   (see the NSLP
   header is defined by Figure 15).

             +-------+    +-------+    +-------+    +-------+
             | DS/NI |<~~~| MB1/  |<~~~| MB2/  |<~~~| DR/NR 20.

      0                               16                            31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   NSLP message type           |       |--->| NF1   |--->| NF2   |--->|       reserved                |
             +-------+    +-------+    +-------+    +-------+

                 ========================================>
                         Data Traffic Direction

                  --->  : NATFW
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 20: Common NSLP request signaling
                  ~~~>  : header

   The reserved field MUST be set to zero in the NATFW NSLP response signaling
                  DS/NI : Data sender header
   before sending and NSIS initiator
                  DR/NR : Data receiver MUST be ignored during processing the header.
   Note that other NSLPs use this field as flag field.

3.3.2  NSLP message types

   The message types identify requests and NSIS responder
                  MB1 responses.  Defined messages
   types for requests are:
   o  0x0101 : Middlebox 1 and NSIS forwarder 1
                  MB2 create
   o  0x0102 : Middlebox 2 and NSIS forwarder 2 reserve
   o  0x0103 : reserve-create
   o  0x0104 : prolong
   o  0x0105 : delete
   Defined message types for responses are:
   o  0x0201 : path_succeed
   o  0x0202 : path_deleted
   o  0x0203 : ret_ext_addr
   o  0x0204 : error

3.3.3  NSLP Objects

   NATFW NSLP objects use a common header format defined by Figure 15: General NSIS signaling 21.
   Objects are Type-Length-Value (TLV) encoded using big endian (network
   ordered) binary data representations.  The object header contains two
   fields, the NSLP request messages are processed each time a NF with NATFW object type and the object length.  Its total length
   is 32 bits.

      0                               16                            31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   NSLP support object type            |       NSLP object length      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 21: Common NSLP object header

   The length is passed.  Those nodes process the message, check local
   policies for authorization and authentication, possibly create policy
   rules, and forward total length of the signaling message to object without the next NSIS node. object
   header.  The
   request message unit is forwarded until it reaches the NSIS responder.
   NSIS responders will check received messages and process those if
   applicable.  NSIS responders generate response messages bytes.  The particular values of type and sent them
   back to length
   for each NSLP object are listed in the NI via subsequent chapters that
   define the same chain NSLP objects.

3.3.3.1  Session ID Object

   The session ID object carries an identifier for the session of NFs. the
   signaled flow.  The response message only field is
   processed at each NI forwarder implementing NATFW NSLP. the session ID of 16 bytes length.

      0                               16                            31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              0x0001           |          16 bytes             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
    //                      16 bytes session id                      //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 22: Session ID object

   The Data
   Sender can start sending its data flow to session ID is generated in random way by the Data Receiver, when NSIS initiator.

3.3.3.2  Session Lifetime Object

   The session lifetime object carries the
   signaling was successful, meaning that NI has received requested or granted lifetime
   of a successful
   response.

   In general, NATFW NSLP signaling follows the data path from DS to DR.
   This enables communication between both hosts for scenarios with session measured in seconds.  The object consists
   only
   firewalls on the data path or NATs on sender side.  For scenarios
   with NATs on of the receiver side certain problems arise.

   When Data receiver (DR) and Data Sender (DS) are located 4 bytes lifetime field.

      0                               16                            31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              0x0002           |           4 bytes             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  NATFW NSLP session lifetime                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 23: Lifetime object

3.3.3.3  External Address Object

   The external address objects can be included in different ret_ext_addr
   responses (Section 3.4.9) only.  It contains the external IP address realms
   and DR is behind a NAT, DS cannot signal to DR. DR is
   not reachable from DS and thus no NATFW signaling can be sent to DR's
   address. Therefore, DR must first fix a address port number allocated at a NAT the edge-NAT.  Note that is
   reachable for DS, for instance DR must determine its public IP
   address.  Once DR has fixed a public address it forwards this to DS
   via a separate mechanism, which address/
   port may be application level signaling
   like SIP.  This application level signaling may involve third parties
   that assist in exchanging this information.  This separate mechanism
   is out of scope of NATFW NSLP.

   NATFW NSLP signaling supports this public address fixing with this
   mechanism:

   o  First, DR fixes a public address by signaling on the reverse path
      (DR towards DS) and thus making itself available to other hosts.
      This process of fixing public addresses is called reservation.
      This way DR reserves publicly reachable addresses and ports.

   o  Second, DS is signaling directly to DR, creating policy rules at
      middleboxes.  Note, that the reservation  mode will usually make
      reservations only, which will be "activated" by the signaling from
      DS towards DR. The first mode is detailed in the Section 4

   The protocol is intended to work on a soft-state basis. This means,
   that whatever state is installed or either reserved on a middlebox, will
   expire, and thus be de-installed/ forgotten after a certain period of
   time.  To prevent this the involved boxes will have to specifically
   request a session prolongation.  An explicit NATFW NSLP state
   deletion message is also provided by or reserve-create.  Two fields are
   defined, the protocol.

   Middleboxes should report back in case of error, so that appropriate
   measures external IP address, and debugging can be performed.

   The next sections define the NATFW NSLP message types and formats,
   protocol operations, and policy rule operations.

5.2 NATFW NSLP Header

   The NATFW NSLP header is common to all messages and follows directly external port number.  For
   IPv4 the NTLP header.  A NSLP node can distinguish based on this header
   whether a request or response message object with value 0x0010 is passed in the packet. defined.  It is
   followed by has a series of objects.

   The NSIS NATFW NSLP header contains:

   o  version: NSIS NATFW NSLP protocol version number.

   o  header_len: length of the NSLP payload 8
   bytes and is shown in bytes, including NSLP
      header

   o  obj_count: Figure 24.

      0                               16                            31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              0x0010           |           8 bytes             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         port number of objects that follow after the NSIS header.

   o  message type: The type of the NSLP message, request or response.
      Sub-types are encoded in this field as well.

   Message type indicates whether the NSLP packet is a request or a
   response. For request messages, four sub-types are defined:

   o  Create Session

   o  Prolong Session

   o  Delete Session

   o  Reserve Session

   For response messages, three sub-types are defined:

   o  Return           |           reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IPv4 address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 24: External Address

   o  Path Succeeded

   o  Error

   The next sections define which objects are included in which message
   type.  For each message type the allowed combination of objects is
   described.

5.3 NATFW NSLP Objects

5.3.1 NATFW NSLP Object Header

   NATFW NSLP objects carry the actual information about policy rules,
   lifetimes and error conditions.  All objects share the same object
   header.  An object header is followed by the object data, whereas the
   format of the object data depends on the object type. A NATFW NSLP
   payload may contain several objects.

   The object header has the following format:

   o  obj_len: total length of the object, including object header

   o  obj_type: type of NATFW NSLP object. Identifies the data that
      follows. for IPv4 addresses

   For IPv6 the moment four object types are defined in the next sections.
   Other objects can be defined later on. These four objects each
   describe a message request type.

5.3.2 NATFW Session ID Object

   The NATFW Session ID with value 0x0011 is the handle to the NATFW session at a
   particular NSIS node. defined.  It is randomly generated by the NSIS
   initiator.

5.3.3 Lifetime Object

   The lifetime object indicates the lifetime of a NATFW NSLP session.
   The real lifetime at has a NSIS peer is the current time plus the
   lifetime value length of this object.

5.3.4 Policy Rule Object

   The policy rule objects contains the flow information for the data
   traffic from DS to DR.  The information contained in this object will
   change as soon as NATs are involved.

   The policy rule object has these fields:

   o  Source address:  The IP address where the data will come from. If
      it is DS sending data to DR, the source address is either DS or
      the closest NAT in the route from DS to the middlebox that gets
      the packet; That is, the address where each middlebox will see the
      packet come from.

   o  Destination address:  The IP address where the data is headed. If
      it is DS sending data to DR, the destination address is either DR
      or the public address DR reserved itself.

   o  Protocol:  The protocol carried in the IP data packet. Currently
      TCP, UDP
   20 bytes and IP is defined.

   o  Source Port:  The transport layer port the data will come from

   o  Destination Port:  The transport layer shown in Figure 25.

      0                               16                            31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              0x0011           |          20 bytes             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         port the data will go to.

   o  IPv flow label:  The number           |          reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                          IPv6 flow label (Editor's note: needs further
      in-depth discussion).

   Note: you might want to leave the source address or port set to ANY,
   to accept any source address port. This makes the pinhole not so pin
   like, but might be necessary at the integration with certain NAT/FW
   types. Whether this loose pinhole is authorized or not by the
   middlebox, is a policy decision based on the middlebox configuration.

5.3.5                         +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 25: External Address Object

   This object contains the reserved external address and if applicable
   port number.

   The object has these fields:

   o  External IP address:  The reserved external IP address at the NAT.

   o  External port number:  The reserved external port number at the
      NAT.

5.4 Request Message Formats

   This section defines the message types and their format for the NATFW
   NSLP.  Note, that IPv6 addresses

3.3.3.4  Extended Flow Information Object

   In general, flow information is kept at the moment of writing this document, no final
   decision has been reached on the details of the NTLP.  Thus, message
   types and formats may change in future revisions of this document.

   Currently, the NATFW NSLP header and 4 request messages are defined.
   Furthermore, three response message types are defined.  All those
   messages are explained in this chapter.

   The NATFW payload of a NSIS NTLP packet consists of a NATFW NSLP
   header that is common to all request, response and error messages.
   Several NATFW NSLP objects follow the NSLP header, depending on the
   message type.

   NOTE: Any bit-level definition of messages and headers are to level during
   signaling.  Nevertheless, some additional information may be done
   in future revision of this memo. Furthermore, any order of object
   fields below is not mandating their order in the actual bit-level
   definition.

5.4.1 Create Session

   The create session request message is used to create policy rules on
   middleboxes.  Middleboxes receiving this message type will, if
   authenticated and authorized, enable the requested policy rules, so
   that data packets of the specified data flow can traverse.

   The create session messages carries these objects:

   o  Session ID object:  A newly generated session ID

   o  Policy Rule object:  The description of the data flow

   o  Lifetime Object:  A request lifetime required
   for this NSIS NATFW NSLP
      session

5.4.2 Prolong Session

   The prolong session request message is used to extend the lifetime of
   a NATFW NSLP session.  The NSIS initiator requests a certain lifetime
   extension.

   The prolong session message carries these objects:

   o  Session ID object:  Session to be prolonged

   o  Lifetime Object:  Requested new lifetime

5.4.3 Delete Session

   The delete session request message is used to delete NATFW NSLP
   session. operations.  The delete session 'extended flow information' object carries
   this object:

   o  Session ID: The session to be deleted.

5.4.4 Reserve External Address

   The reserve external address request message is used in the case that
   a Data Receiver (DR) is located behind a NAT.  The DR needs to
   received data and so uses this request message to reserve an external
   IP address at a NAT.

   The reserve external address message carries these objects:

   o  Session ID:  The session ID for the reservation.  Note that this
      session ID is only valid for the reservation.  Create messages
      using the reservation will use their own generate session ID.

   o  Lifetime:  The lifetime of the reservation

   o  Policy Rule:  In the reserve external address message the policy
      rule object must be set accordingly:

         Source address:  The source address of the data flow. This is
         the destination of the NATFW reserve address packet.  The way
         of NSLP signaling is in the reverse way of the data flow.

         Source port:  The source port of the data flow.

         Destination address:  The internal IP address to where data
         flow will be destined.  This is the source address additional information about number of the NATFW
         reserve address packet.

         Destination port:  The destination subsequent port of the data flow

         Protocol:  Expected protocol

   The direction of NSIS NATFW NSLP signaling is reverse to the reserved
   data flow.  The source address of the expected data flow is the
   destination of the signaling.  Vice versa, the destination address of
   the expected data flow is the source of the signaling (see section
   Section 4).

   Note numbers
   that no state, be it a firewall rule or a NAT binding, is
   installed as a result of this message. The state is only remembered,
   and might should be later installed by a create message.

5.5 Response Messages

   The following messages are responses messages that are generate
   either by any NF or NR.  Currently, three different types of request
   messages allocated at middleboxes.

   These fields are defined.

5.5.1 Return External Address Response

   The return external address response message is sent as a successful
   reply to a reserve external address request.

   Return external address message contains these objects:

   o  Session ID: The session this packet is replying to.

   o  External address object:  Contains reserved external IP address
      and port number

   o  Lifetime:  The minimum granted lifetime for this reservation.

5.5.2 Path Succeeded Response

   The path succeeded response message is sent as a successful reply to
   a create session request.

   The Path succeeded response message contains these objects:

   o  Session ID: The session ID defined for which a path was successfully
      installed

   o  Lifetime:  The minimum granted lifetime of this session

5.5.3 Error Response Messages

   Any NATFW NSLP error occurring at NF or NR is reported via the error
   response message towards the NI.

   The error message contains these objects:

   o  Session ID: The session id of the object that generated the error

   o  Error code:  The error to report.

   Possible error code classes are:

   o  Policy policy rule errors

   o  Authentication and Authorization errors object:
   o  NATFW NSLP protocol errors

5.6 Protocol Operations

   This section defines the message flow and protocol operation for all
   message types

5.6.1 Message Handling Overview

   When a NSIS NATFW peer receives an NSIS message, it might take an
   action based on the message type, the nature  Number of ports: This field gives the middlebox
   function, its configuration and local security policies.

   As a summary, here's the behavior of the boxes, depending on message
   type and configuration parameters:

                     NAT     FW     NAT+FW    DS    DR
      reserve        5       -      5         +     +
      ret_ext_addr   -       -      -         +     8
      create         1       2      3         +     4
      prolong        6       6      6         +     4
      delete         7       7      7         +     4
      path_succeed   9       9      9         8     +

      ret_ext_addr:  Return External Address response message

      1: Remember the policy rule, but do not install. Rewriting either
      the source or destination address depending on whether the packet
      comes from the external_address or not. Always forward.

      2: Remember policy rule, but do not install.  Always forward.

      3: 1+2. The order depends on whether it comes from the outside
      address (NAT, then FW) or the inside one (FW, then NAT)

      4: If it fits one number of its requests, send a path_succeeded packet
      back. Otherwise, drop the packet.

      5: Make a reservation. If middlebox is an edge NAT is set, send
      back the reserved external address and do not forward the message
      further. Otherwise, forward and do not send anything back.

      6: Prolong the session. Always forward.

      7: Terminate the session. Always forward.

      8: hand it over to upper layers, and stop processing.

      9: If it fits a prior request, enable policy rule that has been
      remembered only before.

      -: ignore and forward.

      +: ignore and drop.

   Note ports that policy rule ordering at middlebox is important, when it
   comes to combined NAT and firewall middleboxes, because the filter
   rules have to should
      be set up according to the packet they will see.
   Source NAT is done at the end so it does not disturb routing
   decisions, meaning that filter sees the original packets.
   Destination NAT, on the other hand, is done allocated beginnig at the beginning, so it
   can be routed properly, and so the filter sees the modified packets.

   Note also that for each action, the host might demand a certain
   degree of authorization, and thus refuse to take the action, sending
   an error message back instead.

   The details of protocol operations for each request type is defined
   in the next sections.  Each section describes the exact handling for
   each type of middlebox.

5.6.1.1 Reserving Addresses

   As explained in section Section 4, data receivers located	behind a
   NAT must first reserve an external address and port number (if
   applicable) before any NSIS message can be send towards them.

   With the reserved external address message exchange NSIS peers can
   obtain this required external address and port number at a NAT.
   Therefore, NI sets the policy rule object and sends the signaling
   message to an address chosen on its own (see Section 4.2.1.  The
   reserve message is sent given in this way:

            Public Internet              Private Address
                                              Space
                                  Edge
    DS                            NAT        NAT                 NI(DR)
    |                              |          |                 |
    |                              |          |                 |
    |                              |          |                 |
    |                              | Reserve  |         Reserve |
    |                              |<---------|<----------------|
    |                              |          |                 |
    |                              | Return   | ext addr/Error  |
    |                              |--------->|---------------->|
    |                              | NTLP's flow routing
      information.

      0                               16                            31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              0x0011           |           4 bytes             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         number of ports       |          reserved             |

   Handling of reserve external address messages depends on the
   middlebox type and NSIS peer:

   o  NAT Box:

      When a NAT box gets a Reserve external address message, it checks
      whether it arrived on the public address, or the private one. If
      it arrived in the public one, an
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 26: Extended Flow Information

3.3.3.5  Error Object

   The error message of the type:
      "Requested an external address from the outside" is sent back.

      If it arrived on the private side, an entry is made in the
      internal reservation list with the packet information. If object carries the box
      is an edge NAT (either by configuring it to true, or just reason for that
      connection if it is set to auto), it drops the message, and
      replies with a return external address message containing the
      allocated address port pair. If it is not an edge NAT, it forwards
      the packet on.

   o  Firewall Box:

      Reserve messages are silently ignored in Firewall boxes. They are
      simply forwarded on.

   o  NAT+FW Box:

      When a box that integrates both a NAT and a Firewall gets a
      reserve message, it will hand it to its NAT part. Its firewall
      part will simple ignore it.

   o  Data Sender:

      The message should never get here. It should be ignored and
      dropped.

   o  Data Receiver:

      The message should never get here. It should be ignored and
      dropped.

   Response messages are handled differently depending on NSIS peer
   type:

   o  NAT Box, Firewall Box and NAT+Firewall Box:

      When one of these boxes gets a Return external address message, it
      must simply ignore it and let it traverse.

   o  Data Sender:

      The message should never get here. error.  It should be ignored and
      dropped.

   o  Data Receiver:

      A return external address message in the Data receiver, has
      reached its destination. It must be dropped, and it's information
      handed to superior layers.

5.6.1.2 Creating Sessions

   Creating sessions enables communication between DS and DR.  Both are
   enabled to exchange data packets even with middleboxes on path.  DS
   generates a create session message with a chosen session ID, the
   policy rule object set to only one
   field, the requested flow, error code, and a requested
   lifetime.  DS sends the create session message towards DR.  The
   message flow is sketched in the next figure.

    DS      Public Internet        NAT    Private address        DR
    |                              |          space             |
    | Create                       | 2 bytes long.

      0                               16                            31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
    |----------------------------->|              0x0002           |           4 bytes             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           error code          |           reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 27: Error (if necessary)         |                            |
    |<-----------------------------| Create                     |
    |                              |--------------------------->|
    |                              |                            |
    |                              |       Path Succeeded/Error |
    |         Path Succeeded/Error |<---------------------------|
    |<-----------------------------|                            |
    |                              |                            |
    |                              |                            |

   Create session messages are processed differently at each NSIS peer:

   o  NAT Box:

      When a NAT box gets a create message, it first checks if it
      arrived on the public address or not.

      If it came from the public side, it means an external box will try
      to send data. It then looks for a reservation in its reservation
      list, that matches the dst_addr and dst_port of policy rule
      included in the create message.  If it does not find it, it
      returns an

   TBD: Define error message of the type "No reservation found". If it
      finds it, it fills in the reservation with the data from the
      packet, and remembers the given rule. It then changes the dst_addr
      and dst_port fields of the create packet and forwards it to the
      tgt_addr of the reservation.

      If it came from the private side, it installs the NAT rule with
      the information in the packet. It then changes the src_addr clases and
      src_port of define the create message to its own external address and
      port. error coded.  Possible
   classes are:

   o  Firewall Box:

      When a firewall box gets a create message, it simply remembers the  Policy rule specified in the message and forwards the packet. errors
   o  NAT+FW Box:

      When a box that integrates both a NAT  Authentication and a Firewall gets a create
      message, it first checks whether it arrived on the public address
      or not.

      If it arrived on the public side, the NAT part of the box takes
      care of the packet first, as said in the Authorization errors
   o  NAT Box case. Afterwards,
      the modified packet is handed to the firewall part, where it is
      handled as
   Currently in the Firewall Box case.

      If it arrived on the private side, the message is handed to the
      firewall part first, and then to the NAT one.

   o  Data Sender:

      The message should never get here. It should be ignored and
      dropped. this memo defined errors:
   o  Data Receiver:

      If the data receiver gets a create message, it means all the boxes
      on the way accepted it, and so the signaling succeeded. All it
      does is drop the packet, and send back a Path Succeeded message to
      the IP packet source address.

   As described above, DRs return a path succeeded when the create
   message arrived at DR.  The path succeeded message is returned along
   all NSIS forwarders.  Each NSIS forwarder enables the prior
   remembered policy rules and forwards the message to next NSIS hop.

   Forwarding of the path succeeded messages is terminated at the DS.

5.6.1.3 Prolonging Session

   NATFW NSLP sessions are maintained on a soft-state base. After a
   certain timeout they are removed automatically by the middlebox, if
   they are not refreshed by a prolong session message.  DS is sending
   prolong message towards DR and each NSIS forwarder maintaining state
   for the given session ID extends the  lifetime of the session.

   Extending too big
   o  lifetime of a session is calculated as current local time
   plus lifetime.

    DS      Public Internet        NAT    Private address       DR
    |                              |          space             |
    | Prolong/Delete               |                            |
    |----------------------------->|                            |
    |                              |                            |
    | Error (if necessary)         |                            |
    |<-----------------------------| Prolong/Delete             |
    |                              |--------------------------->|
    |                              |                            |
    |                              |       Error (if necessary) |
    |         Error (if necessary) |<---------------------------|
    |<-----------------------------|                            |
    |                              |                            |
    |                              |                            |

                  Figure 19: Prolongation message flow not acceptable
   o  no NAT Box, Firewall Box and NAT+Firewall Box:

      When one of these boxes gets a Prolong session message, the
      expiration time of the session should be changed to the time of
      reception plus the configured session lifetime. here
   o  Data Sender:

      As in the create session message, this packet is sent from the DS
      to the DR, and should never arrive at the DS.  Again, it should be
      ignored and dropped.  no reservation found
   o  Data Receiver:

      The same behavior as in  requested external address from outside

3.4  Message Formats

   This section defines the case content of a Delete session each NATFW NSLP message on
      the DR should be applied.

5.6.1.4 Deleting Sessions

   Deleting sessions is done via type.
   The message types are defined in Section 3.3.2.  First, the delete session message. DS can request the deletion of a session at any time by sending this
   message.  Processing of these
   messages at:

   o  NAT Box, Firewall Box and NAT+Firewall Box:

      When one of these boxes gets a Delete session message, it erases
      the session referred in the message.

   o  Data Sender:

      This packet should never get to the DS, so it is are defined with their respective objects to be ignored and
      dropped.

   o  Data Receiver:

      As included in
   the create session message, this is the final destination of
      the message.  DR erases its session.  Message forwarding stops
      here.

6. Solution examples

6.1 Firewall traversal

   DS wants to send data traffic to DR through tight firewalls, as seen
   in Figure 20. To do that, it will have to signal using NSIS, on the
   data path.

         +-----+     +-----+    //----\\    +-----+     +-----+
    DS --| FW1 |-----| FW2 |---|        |---| FW3 |-----| FW4 |--- DR
         +-----+     +-----+    \\----//    +-----+     +-----+

            private          public          private

                           Data Flow
   			 ===============================>

                 Figure 20: Firewall Traversal Scenario

   Therefore, DS initiates signaling to DR by sending a create object to
   the IP address of DR. Note that DS already knows its source address
   and port (say, 1111), and  Second, the destination address of DR. The
   destination port (let's say 9999) has been send response messages are defined with their
   respective objects to DS by DR via
   application layer messages, possibly, but not necessarily involving a
   third party. The message looks like:

   o  dst_addr = DR

   o  dst_port = 9999

   o  src_addr = DS

   o  src_port = 1111

   This message is received by FW1, which installs the state that reads:
   "Any packet coming from DS:1111 headed for DR:9999 will be allowed
   traversal"

   FW2, FW3 and FW4 do exactly the same, and forward the packet to included.

   Basically, each
   other, until it finally reaches DR. At this point, the data path is
   open, and DR sends back a Path succeeded message to DS, which can now
   start sending traffic.

6.2 NAT with private network on sender side

   In the example in Figure 21, DS is in a private network  and wants to
   send data to DR, out in the public internet. To do so, DS will have
   to initiate NSIS signaling towards DR

        +------+     +------+    //----\\
   DS --| NAT1 |-----| NAT2 |---|        |--- DR
        +------+     +------+    \\----//

            private          public

         Figure 21: NAT with private network on sender scenario

   Apparently, the normal NAT functionality will take care constructed of sending
   the data from DS out into the public internet, NSLP header and route back the
   replies from DR. This is indeed true, but doesn't give NSIS control
   on what the source address one or port is, as it is usually assigned
   dynamically by the NAT. Moreover, the more
   NSLP would have no information
   on this hops, and could not install proper pinholes, as it would set
   DS as the source address, and not that objects.  The order of the last NAT.

   DS builds a create packet with the information he has, which objects is the
   same as not defined, meaning that
   objects may occur in Section 6.1. It looks like this:

   o  dst_addr = DR

   o  dst_port = 9999

   o  src_addr = DS

   o  src_port = 1111

   NAT1 is the first to get any sequence.

   Each section elaborates the packet; It is not coming from its
   configured "nat external address", required settings and so, it knows it will have parameters to
   rewrite the information on the source, and not that of the
   destination. NAT1 then picks a free port (incidentally 1011) and
   installs a nat rule that reads:  "Whatever packet comes from DS:111,
   heading for DR:9999 will be rewritten so that the source address
   looks like NAT1:1011".

   It then rewrites the packet it received as follows:

   o  dst_addr = DR
   o  dst_port = 9999

   o  src_addr = NAT1

   o  src_port = 1011

   And forwards the packet.

   NAT2 gets it now, and does exactly
   set by the same. Port 2022 is chosen, and NSLP at the rule:  "Whatever packet comes from NAT1:1011, heading NTLP, for DR:9999
   will be rewritten so that instance, how the source address looks like NAT2:2022" is
   installed. The packet gets modified as follows:

   o  dst_addr = DR

   o  dst_port = 9999

   o  src_addr = NAT2

   o  src_port = 2022

   And is forwarded. It eventually reaches DR, who sends back a path
   succeeded message. Data flow from DS:1111 to DR:9999 routing
   information is now possible.

6.3 NAT with private network on receiver side

   In this example, DS wants to send data to DR over set.

3.4.1  Policy Rules

   Policy rules are the network in
   Figure 22:

          //----\\    +------+     +------+
   DS ---|        |---| NAT1 |-----| NAT2 |--- DR
          \\----//    +------+     +------+

          public          private

        Figure 22: NAT with private network on receiver Scenario

   The problem, of course, is that DR is not publicly reachable. Because building block of that, DR will have to signal on the data path, in the opposite
   direction (DR->DS) to get itself a public address it can use. This
   method is described in Section 4

   To get an external address, DR sends a packet to DS. It could
   actually send it to anything middlebox devices considered
   in the public internet, as it would
   force it to traverse what NATs are on its way. In NATFW NSLP.  For Firewalls the case policy rule consists usually of
   multihomed environments, though, more than one NAT to the outside is
   possible, so the better we "aim" the more the chances we go out the
   right NATs and get more optimal routes.

   The said packet is an NSIS reserve_addr object which looks like this:

   o  tgt_addr = DR

   o  tgt_port = 9999

   o  src_addr = 0.0.0.0

   o  src_port = 0

   Notice that this is
   a really loose pinhole, since any src_addr and
   port is allowed.

   NAT2 gets the packet 5-tuple, source/destination address, transport protocol, and looks for a free
   source/destination port (say, 2022, for
   clarity's sake). It then adds number, plus an entry to its reservation list. The
   entry looks action like this:

   o  src_addr = 0.0.0.0

   o  src_port = 0

   o  dst_addr = NAT2

   o  dst_port = 2022

   o  tgt_addr = DR

   o  tgt_port = 9999

   This means simply that packets coming from any source, destined to
   the public address we just reserved, should be targeted to the
   internal box DR, allow or deny.
   Other actions are available depending on port 9999

   It then rewrites the packet so that it looks like:

   o  tgt_addr = NAT2

   o  tgt_port = 2022

   o  src_addr = 0.0.0.0

   o  src_port = 0

   Because it is not an edge NAT, it forwards implementation of the modified packet and
   does not sent
   Firewall, but NATFW NSLP uses only allow action, since a return_external_addr object to DR. Note that no NAT
   binding is installed so far in NAT2, although the state is now
   reserved.

   NAT1 now gets the packet, picks free port 1011 and adds the following
   entry to its reservation list:

   o  src_addr = 0.0.0.0

   o  src_port = 0

   o  dst_addr = NAT1

   o  dst_port = 1011

   o  tgt_addr = NAT2

   o  tgt_port = 2022

   As it turns out, NAT1 IS an edge_nat, so it doesn't forward the
   packet. Instead, it replies default to DR sending back a return external
   address packet on the same connection, so it finds its way back
   through
   deny policy at the NATs:

   o  ext_addr = NAT2

   o  ext_port = 2022

   By using some application layer protocol, and possibly, although not
   necessarily, using a third party box, DR sends it's freshly allocated
   external address and port to DS.

   DS now knows who to signal, so it sends a create message:

   o  dst_addr = NAT1

   o  dst_port = 1011

   o  src_addr = DS

   o  src_port = 1111

   When it reaches NAT1, it does so through NAT1 external address. It
   realizes it middlebox is being asked to forward the traffic from some outside
   box towards the inside. It then looks up its reservation list,
   looking for a session that has the external address and port
   NAT1:1011 assigned. It finds this:

   o  src_addr = 0.0.0.0

   o  src_port = 0

   o  dst_addr = NAT1

   o  dst_port = 1011

   o  tgt_addr = NAT2

   o  tgt_port = 2022

   Using the information in assumed.  For NATs the create object, it then fills in policy rule
   consists of action 'map this
   structure to:

   o  src_addr = DS

   o  src_port = 1111

   o  dst_addr = NAT1

   o  dst_port = 1011

   o  tgt_addr = NAT2

   o  tgt_port = 2022

   This IS a tight pinhole. NAT1 installs the rules now, which say:
   "Whatever packet comes from DS:1111 heading for NAT1:1011, should
   have its destination another address changed to NAT2:2022, realm' and further
   mapping information, that might be forwarded".
   The packet is also rewritten into this:

   o  src_addr = DS

   o  src_port = 1111

   o  dst_addr = NAT2

   o  dst_port = 2022

   And is forwarded to NAT2. Upon arrival, a similar process issues.
   NAT2 finds its reservation entry:

   o  src_addr = 0.0.0.0

   o  src_port = 0

   o  dst_addr = NAT2
   o  dst_port = 2022

   o  tgt_addr = DR

   o  tgt_port = 9999

   Fills it in accordingly:

   o  src_addr = DS

   o  src_port = 1111

   o  dst_addr = NAT2

   o  dst_port = 2022

   o  tgt_addr = DR

   o  tgt_port = 9999

   Rewrites the packet:

   o  src_addr = DS

   o  src_port = 1111

   o  dst_addr = DR

   o  dst_port = 2222

   And forwards it to DR. Once there, DR acknowledges it by sending back
   a path succeeded message in reply, back to DS.

   The path is now open and data transmission from DS:1111->DR:9999 can
   commence.

6.4 Both end hosts are in same private network behind NATs

   In this example (see Figure 23), DS, in a private address space,
   wants to send data to DR, in another private address space. The point
   marked "%" is yet another private most simply case internal
   IP address space. Notice that since
   NAT1 and NAT3 have addresses external IP address.

   Policy rules are usually carried in the same address space, NAT3 might
   want to consider itself an edge NAT. We will consider both
   situations.

                             public
        +------+  %  +------+    //----\\
   DS --| NAT1 |--+--| NAT2 |---|        |
        +------+  |  +------+    \\----//
                  |
                  |  +------+
                  +--| NAT3 |------------ DR
                     +------+

            private

  Figure 23: NAT to public, receiver one piece in same private network Scenario

   We will first assume that NAT3 has the edge_nat option set to false. signaling
   applications.  In this case, NSIS the connection policy rule is a combination of Section 6.3 and
   Section 6.2.

   Firstly DR will signal against on the data path, against the data
   flow, with a reserve external address object. NAT3 will reserve the
   address and forward divided into the packet on to NAT2, who IS filter
   specification, an edge NAT in all
   cases. NAT2 will reply with the external address, implicit allow action, and the connection
   goes on just as in  Section 6.2, except for the fact the topology
   becomes:

                             public
        +------+     +------+
   DS --| NAT1 |-----o------o---+
        +------+     |      |   |
                     | NAT2 |---+
                     |      |   |
                  +--o------o---+
                  |  +------+
                  |
                  |  +------+
                  +--| NAT3 |------------ DR
                     +------+

            private

   Figure 24: New topology due to the non optimal edge nat parameter
                                decision

   This additional information.
   The filter specification is not optimal, but the connection does succeed, and data carried within NTLP's flow
   can commence.

   Let us now solve the case in which NAT3 has edge_nat set to auto.
   Back in Figure 23, NAT3 will decide it IS an edge_nat if the
   destination we pick up for the reserve address packet is in the
   address space marked as "%", routing
   information and will NOT consider itself an edge_nat
   if we point it anywhere else. This additional information is an optimization issue such as
   the one pointed out in Section 6.3.

   Well so, if it doesn't consider itself an edge NAT, we already saw
   what the topological equivalent is, and how it proceeds. If it IS an
   edge NAT, the topological equivalent	would be:

        +------+
   DS --| NAT1 |--+
        +------+  |
                  |
                  |  +------+
                  +--| NAT3 |------------ DR
                     +------+

            private

      Figure 25: A good edge nat decision brings an optimal route

   And we would proceed carried in the same way, only on a more optimal route.

6.5 IPv4/v6 NAT with two private networks

   TBD

6.6 Full example NSLP's objects.
   Additional information is for NAT/FW with two private networks

   The NAT's have the nat_capabilities variable set to true. NAT+FW3 and
   NAT+FW5 have instance the edge_nat variable set to true. The rest lifetime of boxes
   have it set to false.

   Let's now suppose that DR wants to get a data stream from DS in
   Figure 26. For that, we need some way for B to get messages from A,
   be it through some third party application server policy rule
   or some publicly
   reachable proxy, perhaps made public through a NAT binding.

                         +-----+
                +--------| FW4 |--------+
                |        +-----+        |
           +---------+             +---------+
           | NAT+FW3 |             | NAT+FW5 |
           +---------+             +---------+
                |                       |
           +---------+             +---------+
           |  NAT3   |             |  NAT6   |
           +---------+             +---------+
                |                       |
           +---------+             +---------+
           |   FW1   |             |   FW7   |
           +---------+             +---------+
   	         |                       |
           +---------+             +---------+
           |   DS    |             |   DR    |
           +---------+             +---------+

                        Data Flow
               ==========================>

                  Figure 26: Example network topology

   DR wants a data stream from DS, which means that the direction of the
   data is DS->DR. A will have to make itself publicly reachable by
   signaling its NATs and firewalls as necessary. This is a step by step
   guide to the whole process.

   In steps 1 to 4, DR makes itself publicly reachable. From 5 and on,
   DS is signaling on the data path towards DR.

   1. DR wants to get data from DS, so it sends a reserve_addr object to
   a target in the public internet. The closest this target is, the more
   the chances that the resulting route is optimal, but any will work. session.

3.4.2  Create Session (CRS)

   The reserve_addr obj looks like this:

   o  tgt_addr = DR

   o  tgt_port = 888

   o  src_addr = 0.0.0.0

   o  src_port = 0

   Notice that this is a really loose pinhole, since any src_addr and
   port create session request message is allowed.

   2. FW7 gets the packet, ignores its contents and forwards it.
   Firewalls always ignore reserve_addr objects.

   3. NAT6 gets the packet, used to create NSLP sessions
   and looks for a free port (say, 666, for
   clarity's sake). It then adds an entry at middleboxes to its reservation list. create policy rules.

   The
   entry looks like this:

   o  src_addr = 0.0.0.0

   o  src_port = 0

   o  dst_addr = NAT6

   o  dst_port = 666

   o  tgt_addr = DR

   o  tgt_port = 888

   It then rewrites the packet so that it looks like:

   o  tgt_addr = NAT6

   o  tgt_port = 666 create session messages carries these objects:
   o  src_addr = 0.0.0.0  Session ID object
   o  src_port = 0

   Because it is not an edge NAT (edge_nat=false), it does not sent a
   return_external_addr  Lifetime object to DR, but rather forwards the modified
   packet. Note that no NAT binding is installed so far in NAT6,
   although the state is now reserved.

   4. NAT+FW5 receives the packet. The firewall part gets the object,
   but, being as it is an address reservation only object, it ignores
   it.

   The NAT part gets it next. Because it is a NAT, it binds a free
   port, which is thus reserved. An entry to the reservation list is
   added:

   o  src_addr = 0.0.0.0

   o  src_port = 0

   o  dst_addr = NAT+FW5

   o  dst_port = 555
   o  tgt_addr = NAT6

   o  tgt_port = 666

   Because it is an edge_nat, it sends a return_external_addr packet
   with address NAT+FW5 and port 555 back to DR. It does so by simply
   sending it back to the source IP address flow routing information in the IP header of the
   packet. In this case, it is NAT6. The standard capabilities of NAT6
   will send it back to DR, since we are always working on the same
   connection. Because it is an edge_nat and this is a
   reserve_external_addr packet, it does not forward the packet.

   At this stage, the end host DR has learned what its (reserved)
   external address is, even if it can not NTLP MUST be used. It is now publicly
   reachable, and path-coupled NSIS signaling in direction DS->DR can
   start.

   5. Firstly, DR tells DS about it's freshly reserved outside address
   through some higher layer protocol, using the third-party box.

   6. DS now initiates signaling to DR by sending a create object set to the
   brand new public address of DR. It looks like:

   o  dst_addr = NAT+FW5

   o  dst_port = 555

   o  src_addr = DS

   o  src_port = 111

   7. The firewall FW1 gets it, and installs the requested pinhole.
   (Note this IS a tight pinhole with well defined as source
   address and
   destination). It then forwards the packet.

   8. NAT2 gets the packet. Because it is NOT coming from it's external
   address, it realizes it is being asked to forward DS's future data
   packets, and so, it will have to rewrite it's source DR as destination address. To do
   so, NAT2 picks a random free port (which turns out to be 222), and
   installs a NAT rule that says: "Whatever packet comes from DS:111,
   heading for NAT+FW5:555 will  All other parameters MUST be rewritten so that
   set according the source address
   looks like NAT2:222". That is usually known as Source NAT. required policy rule.

3.4.3  Reserve External Address (REA)

   The NSIS
   create reserve external address (REA) request message is then rewritten to look like:

   o  dst_addr = NAT+FW5

   o  dst_port = 555
   o  src_addr = NAT2

   o  src_port = 222

   Because it is not an edge NAT, it simply forwards the modified
   packet.

   9. NAT+FW3 gets the packet next. Because it is NOT coming from the
   extarnal_addr of the NAT+FW, The firewall part gets it first, and
   installs the filter rule that says: "Allow traversal of packets going
   from NAT2:222 towards NAT+FW5:555". It then hands it used to the NAT part.

   The lookup
   a NAT part gets it then. It is not coming from its external
   address, and so, it does as NAT2, binding a port (333) to allocated an external IP address and installing
   a rule that says: "Whatever packet comes from NAT2:222, heading for
   NAT+FW5:555, will be rewritten possibly port
   number, so that the source address looks like
   NAT+FW3:333". It will then rewrite initiator of the create object to:

   o  dst_addr = NAT+FW5

   o  dst_port = 555 REA request has a public
   reachable IP address/port number.

   The REA request message carries these objects:
   o  src_addr = NAT+FW3  Session ID object
   o  src_port = 333

   Note that the box won't send a packet back to DS informing it  Lifetime object

   The REA message needs special NTLP treatment.  First of its
   external address, because DS will never need that.

   10. FW4 gets the create object, and installs all, REA
   messages travel the rule "Allow
   traversal of packets going wrong way, from NAT+FW3:333 towards NAT+FW5:555" It
   then forwards the object.

   11. NAT+FW5 gets the create object. It arrived at its external
   address, so it realizes it doesn't have to change DR towards DS.  Second, the source
   DS' address
   of  used during the future data packets of DS, but rather its destination. It also
   means that signaling may be not the NAT part will have to handle it first. It then tries actual DS (see
   Section 3.2.10).  Therefore, the NTLP flow routing information is set
   to find out where it has DR as initiator and DS as responders, a special field is given in
   the NTLP: The signaling destination.

3.4.4  Reserve-Create (REC)

   XXX This is a proposal for a new message to re-destined it to, by looking up its
   reservation tables. It finds support the previous reservation, by matching it
   with their dst_addr reservation
   and dst_port of the simultaneous/implicit create object:

   o  src_addr = 0.0.0.0

   o  src_port = 0

   o  dst_addr = NAT+FW5

   o  dst_port = 555 message generation.

   The reserve-create message carries these objects:
   o  tgt_addr = NAT6  Session ID object
   o  tgt_port = 666

   And proceeds  Lifetime object

   NTLP issues: TBD.

3.4.5  Prolong Session (PLS)

   The prolong request message is used to fill it in with prolong (extend) the information lifetime
   of the create object
   (src_addr a NATFW NSLP and src_port):

   o  src_addr = NAT+FW3

   o  src_port = 333

   o  dst_addr = NAT+FW5

   o  dst_port = 555 policy rules at middleboxes.

   The prolong session message carries these objects:

   o  tgt_addr = NAT6  Session ID object
   o  tgt_port = 666

   It then installs a NAT rule with that information. It reads:
   "Whatever packet comes from NAT+FW3:333, heading for NAT+FW5:555 will  Lifetime object

   The flow routing information in the NTLP MUST be rewritten, so that its destination set to DS as source
   address looks like NAT6:666".
   The reservation is erased and DR as destination address.  All other parameters MUST be
   set according the rule starts working. The NAT
   binding becomes thus usable. required policy rule.

3.4.6  Delete Session (DLS)

   The object delete request message is modified, so that it now looks like:

   o  dst_addr = NAT+FW3

   o  dst_port = 333

   o  src_addr = NAT6 used to delete NATFW NSLP sessions.

   The delete session message carries these objects:
   o  src_port = 666  Session ID object

   The FW part now gets flow routing information in the object, NTLP MUST be set to DS as source
   address and installs DR as destination address.  All other parameters MUST be
   set according the rule: "Allow
   traversal of whatever packet that comes from NAT+FW3:333 heading for
   NAT6:666". required policy rule.

3.4.7  Path Succeeded (PS)

   The packet path succeeded response message is then forwarded.

   12. NAT6 gets the packet. As it comes from the external address, it
   does as NAT+FW5, looking up the reservation list used to acknowledge a
   successful create and filling it in
   with:

   o  src_addr = NAT+FW3

   o  src_port = 333

   o  dst_addr = NAT6
   o  dst_port = 666 prolong.

   The path succeeded message carries these objects:
   o  tgt_addr = DR  Session ID object
   o  tgt_port = 888

   It then installs the rule: "Whatever packet comes from NAT+FW3:333,
   heading for NAT6:666 will be rewritten, so that its destination
   address looks like DR:888". The rule reservation  lifetime object

   This message is erased, and routed on the
   NAT binding becomes active. reverse path.

3.4.8  Path Deleted (PD)

   The object path deleted response message is rewritten as:

   o  src_addr = NAT+FW3

   o  src_port = 333

   o  dst_addr = DR

   o  dst_port = 888 used to acknowledge a successful
   delete request message.

   The path deleted message carries this object:
   o  Session ID object

   This message is thus forwarded.

   13. FW7 gets the packet now, and installs the rule: "Allow traversal
   of whatever packet that comes from NAT+FW3:333 heading for DR:888".
   It forwards the packet.

   14: DR gets (finally) routed on the packet. It realizes it reverse path.

3.4.9  Return External Address (RA)

   The return external address response message is sent back as a create object
   headed for him, to
   positive result of reserve external address request.  It contains the port which he expected,
   reserved external IP address and so it sees
   everything went well. A reply to the packet port number.

   The path succeeded message carries these objects:
   o  Session ID object
   o  Lifetime object
   o  External address object (either IPv4 or IPv6 type)

   This message is send, and the NAT's routed on the way, knowing the already established connection, will route it to
   DS. reverse path.

3.4.10  Error Response (ER)

   The packet error response message is a path_succesful message, which simply means
   "Everything sent back by any NSIS node involved in
   the session that occurs an error condition.

   The error message carries these objects:
   o  Session ID object
   o  Error object

   This message is fine, send data whenever you want".

7. routed on the reverse path.

4.  NSIS NAT and Firewall transitions issues

   NSIS NAT and Firewall transition issues are premature and will be
   addressed in a separate draft (see [16]). [17]).  An update of this section
   will be based on consensus.

8.

5.  Security Considerations

   Security is of major concern particularly in case of firewall Firewall
   traversal.  Generic threats for NSIS signaling have been discussed in
   [5]
   [6] and are applicable here as well.  It is necessary to provide
   proper signaling message protection and proper authorization.  Note
   that the NAT is likely to be co-located with a firewall Firewall and might
   therefore require packet filters to be changed in order to allow the
   signaling message to process and to traverse.  This section aims to
   raise some items for further discussion and illustrates the problems
   the authors faced when creating a security solution for the NAT/
   Firewall NSLP.

   Installing packet filters provides some security, but has some
   weaknesses, which heavily depend on the type of packet filter
   installed.  A packet filter cannot prevent an adversary to inject
   traffic (due to the IP spoofing capabilities).  This type of attack
   might not be particular helpful if the packet filter is a standard 5
   tuple which is very restrictive.  If packet filter installation,
   however, allows specifying a rule, which restricts only the source IP
   address, then IP spoofing allows transmitting traffic to an arbitrary
   address.  NSIS aims to provide path-coupled signaling and therefore
   an adversary is somewhat restricted in the location from which
   attacks can be performed.  Some trust is therefore assumed from nodes
   and networks along the path.

   Without doubts there is a dependency on the security provided by the
   NTLP.  Section Section 3 Appendix A and Section 2.2 motivates some trust
   relationship and authorization scenarios.  These scenarios deserve a
   discussion since some of them (particularly one with a missing
   network-to-network trust relationship) is different to what is know
   from QoS signaling.  To address some of these trust relationships and
   authorization issues requires security mechanisms between
   non-neighboring nodes at the NSLP layer.  For the group of authors it
   seems that peer-to-peer and end-to-middle security needs to be
   provided.  An NSLP security mechanism between neighboring NSLP peers
   might be necessary if security mechanisms at the NTLP do not provide
   adequate protection mechanisms.  This issue is, however, still in
   discussion.

   As a design goal it seems to be favorable to reuse existing
   mechanisms to the best extend possible.  In most cases it is
   necessary to carry the objects for end-to-middle as NSLP payloads
   since the presence of NATs might prevent direct communication.  Three
   security mechanisms have to be considered in more detail in a future
   version of this document: CMS [17] [21] and Identity Representation for
   RSVP  [14].  [15].  The authors believe that CMS more suitable (since it
   provides much more functionality).  The details deserve further
   discussion and implementation experience.

   With regard to signal between two end hosts even though the receiver
   is behind a NAT this proposal suggests creating state by the data
   receiver first.  This allows NSIS signaling messages to traverse a
   NAT at the receiver side (due to the established state at this NAT
   box) and simplifies security handling.  To achieve this behavior it
   is required to install NSIS NTLP and NSLP state.  Furthermore, it is
   envisioned to associate the two signaling parts (one part from the
   data sender to the NAT and the other part from the NAT to the data
   receiver) with the help of the Session Identifier.  As such, the
   discussion in [14] [15] is relevant for this document.

   Another interesting property of this protocol proposal is to prevent
   Denial of Service attacks against NAT boxes whereby an adversary
   allocates NAT bindings with the help of data packets.  Since these
   data packets do not provide any type of authentication and are not
   authorized any adversary is able to mount such an attack.  This
   attack has  been mentioned at several places in the literature
   already and is particularly harmful if no NAPT functionality is used
   (i.e.  if a new NAT binding consumes one IP address of a pool of IP
   addresses).  Using the protocol described in this document additional
   security can be achieved and more fairness can be provided.

9.

6.  Open Issues

   At least the following issues require further discussion:
   o  Message format: The exact message format is still to be
      determined, both  Option processing rules in regards presence of bit level details and on
      parameters, such as unknown options.
   o  Terminology w.r.t.  the need for an term wrong way.
   o  NTLP: New object header length, since,
      until now, that is a constant. and semantics for REA.
   o  Message type numbering  NTLP and NATFW NSLP interaction
   o  Error codes: error codes have to be defined still. Among others,
      we will need:  missing authorization, out  List of resources, unable to
      understand the packet, or maximum resources for that individual
      already allocated. NTLP transport modes per NSLP message
   o  middlebox default policies: allow for the configuration of the
      default policies  Routing Change detection
   o  Query message, definition of the box. For semantics needed
   o  Is there a NAT+Firewall box, need for instance,
      the firewall default policy might be "accept", a QoS NSLP RSN like object/mechanism in NATFW
      NSLP?
   o  Add IANA considerations section.
   o  re-work security considerations.
   o  Query message: Syntax and so, no packet
      filters would have to be installed on that regard (we would still
      need the NAT bindings, though). semantics.
   o  IPv6 flow label usage  Add text about asynchronous messages.
   o  Stacking  Anycast address for REA.
   o  Edit Section 6 "Solution Examples"  Check common formats with QoS NSLP
   o  Edit Security Consideration section  Change length field of objects to long words as unit?
   o  Edit Appendix A.

10.  Variable length for session id?
   o  Meaning of 0 as session ID.
   o  Extended flow object: Needs refinement

7.  Contributors

   A number of individuals have contributed to this draft.  Since it was
   not possible to list them all in the authors section, it was decided
   to split it and move Marcus Brunner and Henning Schulzrinne into the
   contributors section.  Separating into two groups was done without
   treating any one of them better (or worse) than others.

8.  References

8.1  Normative References

   [1]  Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT
        draft-ietf-nsis-fw-05.txt, October 2003.

   [2]  Brunner et al., M., "Requirements for Signaling Protocols",
        DRAFT draft-ietf-nsis-req-09.txt, October 2003.

   [3]  Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
        Messaging Protocol for Signaling", DRAFT
        draft-ietf-nsis-ntlp-00.txt, October 2003.

   [4]  Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
        Quality-of-Service signaling", DRAFT
        draft-ietf-nsis-qos-nslp-03.txt, May 2004.

   [5]  IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.

   [5]

   [6]  Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
        DRAFT draft-ietf-nsis-threats-01.txt, January 2003.

   [6]

   [7]  Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
        Rayhan, "Middlebox communication architecture and framework",
        RFC 3303, August 2002.

8.2  Informative References

   [7]

   [8]   Srisuresh, P. and M. Holdrege, "IP Network Address Translator
         (NAT) Terminology and Considerations, RFC 2663", August 1999.

   [8]

   [9]   Srisuresh, P. and M. Holdrege, "Network Address Translator
         (NAT)Terminology and Considerations, RFC 2663".

   [9]

   [10]  Srisuresh, P. and E. Egevang, "Traditional IP Network Address
         Translator (Traditional NAT), RFC 3022", January 2001.

   [10]

   [11]  Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
         Protocol Translation (NAT-PT), RFC 2766", February 2000.

   [11]

   [12]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
         RFC 3234, February 2002.

   [12]

   [13]  Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan,
         "DNS extensions to Network Address Translators (DNS_ALG)", RFC
         2694, September 1999.

   [13]

   [14]  Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
         Specification", September 1997.

   [14]

   [15]  Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
         Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC
         3182, October 2001.

   [15]

   [16]  Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and
         X. Fu, "Security Implications of the Session Identifier", June
         2003.

   [16]  Aoun and others....,

   [17]  Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H.
         Tschofenig, "NAT/Firewall NSLP migration, routing,
         NTLP requirements and off-path Migration Considerations", October 2003.

   [17] DRAFT
         draft-aoun-nsis-nslp-natfw-migration-01.txt, Februar 2004.

   [18]  Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H.
         Tschofenig, "NATFirewall NSLP Intra-realm considerations",
         DRAFT draft-aoun-nsis-nslp-natfw-intrarealm-00.txt, Februar
         2004.

   [19]  Martin, M., Brunner, M. and M. Stiemerling, "SIP NSIS
         Interactions for NAT/Firewall Traversal", DRAFT
         draft-martin-nsis-nslp-natfw-sip-00.txt, Februar 2004.

   [20]  Martin, M., Brunner, M., Stiemerling, M., Girao, J. and C.
         Aoun, "A NSIS NAT/Firewall NSLP Security Infrastructure", DRAFT
         draft-martin-nsis-nslp-natfw-security-01.txt, Februar 2004.

   [21]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
         August 2002.

   [18]

   [22]  Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K.
         Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt,
         November 2002.

   [19]

   [23]  Tschofenig, H., Buechli, M., Van den Bosch, S. and H.
         Schulzrinne, "NSIS Authentication, Authorization and Accounting
         Issues", March 2003.

   [20]

   [24]  Amini, L. and H. Schulzrinne, "Observations from router-level
         internet traces", DIMACS Workshop on Internet and WWW
         Measurement, Mapping and Modelin Jersey) , Februar 2002.

   [21]

   [25]  Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4
         Traversal of VPN Gateways",
         draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in
         progress), April 2003.

   [22]

   [26]  Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin,
         "Problem Space and Usage Scenarios for PANA",
         draft-ietf-pana-usage-scenarios-06 (work in progress), April
         2003.

   [23]

   [27]  Shore, M., "The TIST (Topology-Insensitive Service Traversal)
         Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002.

   [24]

   [28]  Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT
         Traversal Client for CASP", DRAFT
         draft-tschofenig-nsis-casp-midcom-01.txt, March 2003.

   [25]

   [29]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [26]

   [30]  Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H. and H.
         Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and
         Framework", DRAFT draft-brunner-nsis-midcom-ps-00.txt, June
         2003.

   [31]  Ford, B., Srisuresh, P. and D. Kegel, "Peer-to-Peer(P2P)
         communication  Network Address Translators(NAT)", DRAFT
         draft-ford-midcom-p2p-02.txt, March 2004.

   [32]  Rosenberg et al, J., "STUN - Simple Traversal of User Datagram
         Protocol (UDP) Through Network Address Translators (NATs)", RFC
         3489, March 2003.

   [33]  Rekhter et al, Y., "Address Allocation for Private Internets",
         RFC 1918, February 1996.

Authors' Addresses

   Martin Stiemerling
   Network Laboratories, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 (0) 6221 905 11 13
   EMail: stiemerling@netlab.nec.de
   URI:

   Hannes Tschoefenig
   Siemens AG
   Otto-Hahn-Ring 6
   Munich  81739
   Germany

   Phone:
   EMail: Hannes.Tschofenig@siemens.com
   URI:

   Miquel Martin
   Network Laboratories, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 (0) 6221 905 11 16
   EMail: miquel.martin@netlab.nec.de
   URI:

   Cedric Aoun
   Nortel Networks

   France

   EMail: cedric.aoun@nortelnetworks.com

Appendix A. Inter-working of SIP with NSIS NATFW NSLP

   This document aims at pinpointing the problems of using SIP in
   nowadays networks, focusing on the problems derived of NAT's,
   Firewalls  Problems and multi-path communications. It is intended to fit in a
   scenario description that shows the necessity of NSIS, as well as
   depicting it's requirements. However, note that there are Challenges

   This section describes a number of
   other solutions available. For example the IETF Midcom working group
   is working on [6].

A.1 The Session Initiation Protocol

   [25] describes the Session Initiation Protocol, an application-layer
   control protocol problems that can establish, modify, and terminate multimedia
   sessions. This often involves several flows have to be addressed
   for video and voice,
   which NSIS NAT/Firewall.  Issues presented here are transported over new connections. subject to further
   discussions.  These use of dynamically
   allocated ports which results in protocol complexity which can not issues might be
   handled by nowadays NAT's and Firewalls.

   Session initiation when one or both also of the users relevance to other NSLP
   protocols.

A.1  Missing Network-to-Network Trust Relationship

   Peer-to-peer trust relationship, as shown in Figure 10, is behind a NAT is
   also very
   convenient assumption that allows simplified signaling message
   processing.  However, it might not possible, given the impossibility to address always be applicable, especially
   between two arbitrary access networks (over a private IP
   over the internet. Moreover, core network deployments often allow for
   different paths per connection where
   signaling messages are not interpreted).  Possibly peer-to-peer trust
   relationship does not exist because of the large number of networks
   and direction, making the setup unwillingness of administrators to have other network
   operators to create holes in their Firewalls without proper
   authorization.  Hence in the
   middleboxes even more complicated.

   The following figure depicts scenario we assume a typical SIP connection:

   Ernie(192.0.2.1)                          Bert(192.0.2.2)
      |                                        |
      |     1# SIP INVITE                      |
      +--------------------------------------->| somewhat
   different message processing and show three possible approaches to
   tackle the problem.  None of these three approaches is without
   drawbacks or constraining assumptions.

   +----------------------+              +--------------------------+
   |                      |                       2# SIP Ringing              |
      |<---------------------------------------+                          |
   |          Network A   |                       3# SIP OK              | <-- Call accepted
      |<---------------------------------------+              Network B   |
   |                      |     4# SIP ACK              |
      +--------------------------------------->|                          |
   |            +---------+   Missing    +---------+                |     5# DATA
   |
      |=======================================>|
      |<=======================================|      +-///-+ Middle- |    Trust     |

      1# SIP Invite (192.0.2.1:? -> 192.0.2.2:SIP): I Listen on
      192.0.2.1:1000 Ernie invites Bert to the conference, and informs
      it's awaiting media data on port 1000.

      2# SIP Ringing (192.0.2.2:SIP -> 192.0.2.1:?): Ringing Bert's
      phone The ringing simply implies that there's something sip aware
      on Bert's side, and that it's ringing his phone

      3# SIP OK (192.0.2.2:SIP -> 192.0.2.1:?): Call accepted, I listen
      on 192.0.2.2:2000 This OK means that the Bert took the phone off
      hook, and thus accepted the call. It also informs Ernie that Bert
      is awaiting his media data at port 2000

      4# SIP ACK (192.0.2.1:? -> 192.0.2.2:SIP): All is fine, start
      transmitting. ACK means the ports are accepted and the call can
      start in the selected data ports on both sides.

      5# DATA (192.0.2.1:? -> 192.0.2.2:2000 and 192.0.2.2:? ->
      192.0.2.1:1000): Voice,image, video.. This is the actual data
      being transmitted.

   In the above example, SIP is used successfully to establish a
   communication, which includes negotiating the data ports for the
   actual transmission. Unfortunately, this scheme will not work for
   more complex setups.

   Let's now consider one firewall in the data path, be it on Ernie's or
   Bert's network, or elsewhere in the middle. We assume that the
   firewall is allowing traffic directed to the SIP port. As to the rest
   of the ports, a typical setup involves outgoing connections being
   allowed, and incoming connections being dropped, except for those
   already established. That is, we allow packets to go out and their
   replies to come in, but disable all other traffic.

   In this case, the connection is as follows, for the case of a
   firewall on Ernie's network:

     Ernie(192.0.2.1)    FW                    Bert(192.0.2.2) Middle- +-///-+          |
   |      |     | 1# SIP INVITE  box 1  |   Relation-  |
      +--------------------------------------->|  box 2  |     |          |
   |      |         2# SIP Ringing     +---------+     ship     +---------+     |
      |<---------------------------------------+          |
   |      |               |     or       |              3# SIP OK               | <-- Call accepted
      |<---------------------------------------+          |
   |      |               | 4# SIP ACK Authorization|               |          |
      +--------------------------------------->|
   |      |               |              |     5# DATA               |          |
      |=======================================>|
   |               |<=======================|      |   Trust       |              |

   Notice how the SIP messages #1 and #4 traverse the firewall, because
   they are outbound, and how 2# and 3# traverse it too, because they
   are replies to the connection established at 1#.

   Notice now how 5# can go outwards, but Bert can not go through the
   firewall to reach Ernie's port 1000. The reason is the connection is
   a new one, and the firewall won't allow it through.

   Bert will now get media from Ernie, but Ernie is never going to get
   anything from Bert. The call is thus considered unsuccessful. The
   reason is that the application level port negotiation is never
   acknowledge by the network-transport layer firewall, which doesn't
   know what to expect. We would still face the same problem if the
   connection used a SIP Proxy, for it would only translate names into
   IP addresses.

   Let us now assume that we indeed have an application layer firewall,
   be it by design, or because we load some sort of SIP module to it.
   The previous case would now work, since the firewall can now
   understand the packets going through it and open the necessary ports.
   Still, we cannot assume that SIP signalization packets and the actual
   data follow the same path. The following figure shows a likely setup.
   FW+ stands for one or more firewalls:

                        SIP Signalization Path   +-----+
                    /---------------->-----------| FW+ |-------\      Trust    |                            +-----+          |
    +------+    +------+                                    +-----+
    |Ernie |----|Router|                                    |Bert
   |
    +------+    +------+                                    +-----+      |   Data Path                +-----+ Relationship  |
                    \---------------->-----------| FW+ |-------/
                                                 +-----+

   The SIP packets with the information about the listening ports now
   travels on the SIP Signalization path, and so the firewalls on that
   path can read them. The Data, though, is traveling through the Data
   path, and the firewalls in that path never get to see the Invite and
   Ok packets. They are thus unable to open the ports.

   Two issues are arisen here: first, we need on-path signalization
   unless we already know the path our packets will take; a highly
   unlikely situation in today's internet. Second, if we patch the
   firewalls to understand SIP, we will provide any caller with a
   hole-puncher for the firewall, since SIP is not provisioned with
   proper authentication mechanism.

   It is now clear that tight firewalls prevent SIP from successfully
   working. There is still another obstacle: NATs.

   NATs provide for a link between two different address spaces,
   typically connecting a private range network to a public range one.
   As a consequence, connections going from the inside (usually the
   private range) are translated using the NAT's public interface
   address, and the replies are routed back. The public side of the
   network can only see the NATs public interface, and know nothing of
   the private network inside. This means computers outside the NAT
   won't be able to address computers inside the NAT.

   Let us analyse the SIP example when Ernie is behind a NAT. The
   following figure depicts a typical session:

    Ernie(10.0.0.2)   (10.0.0.1) NAT (192.0.2.1)    Bert(192.0.2.2)              |  Relationship |          |
   | 1# SIP INVITE      |               |
       +--------------------------\              |               |                          |----------------->|          |
   |      |               |              |   2# SIP Ringing               |          |                          /------------------+
       |<-------------------------|
   |      |               |              |               |          |        3# SIP OK
   | <-- Call accepted   +--+---+           |                          /------------------+
       |<-------------------------|              |            +--+---+      |
   |   | Host | 4# SIP ACK           |              |
       +--------------------------\            | Host |                          |----------------->|      |
   |   |  A   | 5# DATA           |              |
       |==========================\            |  B   |                          |=================>|      |
   |   ?<=============|   +------+           |              |            +------+      |

   The communication
   +----------------------+              +--------------------------+

        Figure 28: Missing Network-to-Network Trust Relationship

   Figure 28 illustrates a problem whereby an external node is analogous not
   allowed to the one in the previous examples,
   except for the fact the NAT is rewriting the source address of the
   packets as they traverse it.

   For instance, manipulate (create, delete, query, etc.) packet 1# filters at
   a Firewall.  Opening pinholes is going from 10.0.0.2:? towards
   192.0.2.2:SIP. The NAT box intercepts the message and puts
   192.0.2.1:? as the source address and port, only allowed for internal nodes or
   with ? being a
   dynamically picked port, which might be different from certain authorization permission.  Hence the original
   one 1# used.

   On solution
   alternatives in Section 3.2.2 focus on establishing the way back, Bert necessary
   trust with cooperation of internal nodes.

A.2  Relationship with routing

   The data path is replying to following the source of "normal" routes.  The NAT/FW devices
   along the IP packet,
   that is, 192.0.2.1, and so, when 2# reaches 192.0.2.1, data path are those providing the NAT know
   it is a reply from 1#, because it established a NAT binding, and service.  In this
   replaces the destination address, 192.0.2.1:? with 10.0.0.2:? and
   forwards the packet inside case
   the NAT.

   As a result, Ernie never knows there service is something like "open a NAT in his pinhole" or even more general
   "allow for connectivity between two communication
   path, since he sends and receives packets from 192.0.2.2 normally.
   This means partners".  The
   benefit of using path-coupled signaling is that the INVITE packet will tell Bert NSIS NATFW NSLP
   does not need to send determine what middleboxes or in what order the data back
   flow will go through.

   Creating NAT bindings modifies the path of data packets between two
   end points.  Without NATs involved, packets flow from endhost to
   10.0.0.2, a private IP. Once
   endhost following the path given by the signalization routing.  With NATs involved,
   this end-to-end flow is finished, and not directly possible, because of separated
   address realms.  Thus, data packets flow towards the
   actual DATA transmission starts, Bert tries to connect to 10.0.0.2, external IP
   address at a
   private NAT (external IP address, from the internet; The routers don't know how to
   route this, and the packet is eventually dropped.

   One possible solution would address may be a public IP address).

   Other NSIS NSLPs, for Ernie to know the NAT exists, and
   already indicate that it listens on 192.0.2.1, and not 10.0.0.2.
   That, still would instance QoS NSLP, which do not work, since interfere with
   routing - instead they only follow the NAT binding is not performed at path of the NAT box.

A.2 Conclusions

   The above examples display data  packets.

A.3  Affected Parts of the inability to use standard SIP through
   tight firewalls or NATs, Network

   NATs and points Firewalls are usually located at the necessity of a secure
   on-path protocol to negotiate firewall pinholes and NAT bindings.

Appendix B. Ad-Hoc networks

   Some forms edge of ad-hoc networks exist the network,
   whereby other signaling applications affect all nodes along the path.
   One typical example is QoS signaling where trust all networks along the
   path must provide QoS in order to achieve true end-to-end QoS.  In
   the network is not
   justified. Figure Figure 31 mainly illustrates NAT/Firewall case, only some of the problems domains/nodes are affected
   (typically access networks), whereas most parts of
   malicious the networks and
   nodes are unaffected (e.g.  the core network).

   This fact raises some questions.  Should an NSIS entities graphically:

   +------------------------------------------+        +--------//
   |                             Ad-Hoc       |        | ISP
   |                             Network      |        |
   |      regular data                        |        |
   |      traffic by          +---------+     |        |
   | NTLP node A              |Malicious|     |      +-+--------+
   |          +-------------->+  Node   +-----+///-->+ Firewall +-//
   |          ^               |   3     |===========>|    1     |
   |          |               +---------+ injected   +-+--------+
   |          |                           data traffic |
   |          |                               |        |
   |          |                               |        |
   |      +---+-----+        +---------+      |        |
   |      +  Node   |        |  Node   |      |        |
   |      |    1    |        |    2    |      |        |
   |      +---------+        +---------+      |        |
   |          ^                               |        +--------//
   |          |                               |
   +----------+-------------------------------+
              |
           +--+---+
           | Node |
           |  A   |
           +------+

              Figure 31: Limits of packet filter security

   An ad-hoc network consists of a number intercept
   every signaling message independently of nodes between the end host
   (Node A) and upper layer signaling
   application or should it be possible to make the ISP discovery procedure
   more intelligent to which Node A wants skip nodes.  These questions are also related to get access. Although
   Node A uses an authentication
   the question whether NSIS NAT/FW should be combined with other NSIS
   signaling applications.

A.4  NSIS backward compatibility with NSIS unaware NAT and Firewalls

   Backward compatibility is a key exchange for NSIS deployments, as such the
   NSIS protocol suite should be sufficiently robust to create a
   policy rule at allow traversal
   of none NSIS aware routers (QoS gates, Firewalls, NATs, etc ).

   NSIS NATFW NSLP's backward compatibility issues are different than
   the firewall 1 it is still possible for NSIS QoS NSLP backward compatibility issues, where an untrusted
   node (in this case Node 3) to inject data traffic which NSIS
   unaware QoS gate will pass simply forward the QoS NSLP message.  An NSIS
   unaware Firewall 1 rejects NSIS messages, since Firewalls typically
   implement the data traffic is not authenticated. To prevent
   this type policy "default to deny".

   The NSIS backward compatibility support on none NSIS aware Firewall
   would typically consist of threat two approaches are possible. First, configuring a restrictive
   packet filter limits static policy rule that
   allows the capabilities forwarding of an adversary. Finally, there
   is always the option of using data traffic protection.

Appendix C. Interworking of Security Mechanisms and NSIS NATFW NSLP

   TBD

Appendix D. Solution approaches protocol messages (either protocol
   type if raw transport mode is used or transport port number in case of missing authorization

D.1 Solution Approach: Local authorization from both end points

   The first approach makes use of local authorization from both end
   points. If Host A sends a
   transport protocol is used).

   For NATs backward compatibility is more problematic since signaling message toward the destination to
   Middlebox 1 the message will perform the desired action
   messages are forwarded (at least in Network A.
   Middlebox 1 establishes some state information one direction), but with a
   changed IP address and forwards the
   signaling message towards Host B. Signaling message protection
   between the two access networks might be difficult. A missing trust
   relationship does not necessarily mean that no security association
   establishment is possible. changed port numbers.  The lacking trust disallows Middlebox 1
   (or indirectly Host A where content of the NSIS
   signaling message was initiated) is, however, unchanged.  This can lead to
   create packet filters at Middlebox 2. We assume that
   unexpected results, both due to embedded unchanged local scoped
   addresses and none NSIS aware Firewalls configured with specific
   policy rules allowing forwarding of the NSIS
   signaling message is allowed protocol (case of
   transport protocols are used for the NTLP).  NSIS unaware NATs must
   be detected to pass maintain a well-known deterministic mode of operation
   for all the firewall then involved NSIS entities.  Such a "legacy" NAT detection
   procedure can be done during the NSIS discover procedure itself.

   Based on experience it finally
   reaches Host B. Due to was discovered that routers unaware of the missing authorization no packet filter
   specific state
   Router Alert IP option [RFC 2113] discarded packets, this is created. The filters will be installed later after
   receiving an authorization from Host B. When Host B returns
   certainly a
   confirmation or acknowledgement then Middlebox 2 treats it as an
   authorization problem for NSIS signaling.

A.5  Authentication and finally triggers filter creation. The message Authorization

   For both types of middleboxes, Firewall and NAT security is
   then forwarded to Middlebox 1, where filters are either already
   installed or require an additional confirmation. Finally the a strong
   requirement.  Authentication and authorization means must be
   provided.

   For NATFW signaling message applications it is forwarded partially not possible to Host A, which can be assured do
   authentication and authorization based on IP addresses.  Since NATs
   change IP addresses, such an address based authentication and
   authorization scheme would fail.

A.6  Directional Properties

   There two directional properties that
   subsequent data traffic can be transmitted end-to-end from Host A to
   Host B. The same procedure has need to be applied again to signal
   information for addressed by the other direction (Host B to Host A).

   The following behavior has to be assumed in order for this approach
   NATFW NSLP:
   o  Directionality of the data
   o  Directionality of NSLP signaling

   Both properties are relevant to be applicable:

   1.  Signaling messages must be allowed NATFW NSLP aware NATs and Firewalls.

   With regards to pass firewalls along the
       path.

   2.  NSIS NSLP signaling must operate directionality: As stated in the described manner which could
       be described as: Install where you have authorization - delay
   previous sections, the authentication and
       forward where you have no authorization.

   This approach suffers authorization of NSLP
   signaling messages received from hosts within the following drawbacks:

   1.  Firewalls which block NSIS signaling same trust domain
   (typically from external networks or
       nodes prevent a successful operation.

   2.  A full roundtrip hosts located within the security perimeter delimited
   by Firewalls) is required to signal packet filter information. normally simpler than received messages sent by
   hosts located in different trust domains.

   The way NSIS signaling message must therefore provide the capability
       to route signaling message in both direction which might either
       require state installation at nodes along messages enters the path (route
       pinning) or a stateless version via record-route. Some risk NSIS entity of
       DoS protection a Firewall
   (see Figure 2) might exist.

D.2 Solution Approach: Access Network-Only Signaling

   The next approach is based on signaling packet filter information be important, because different policies might
   apply for authentication and admission control.

   Hosts deployed within the secured network perimeter delimited by
   both a
   Firewall, are protected from hosts into deployed outside the local access secured
   network only. An NSIS allows
   specifying such a behavior perimeter, hence by indicating nature the signaling endpoint with Firewall has more restrictions
   on flows triggered from hosts deployed outside the help security
   perimeter.

A.7  Addressing

   A more general problem of scoping (for example with domain name or a "local network
   only" flag). Scoping means that NATs is the addressing of the end-point.
   NSIS signaling message although have to be addressed to the other end host to
   follow data packets subsequently sent.  Therefore, a particular destination public IP
   address terminates somewhere
   along of the path. If packet filters for both directions have receiver has to be
   installed then the known prior to sending an NSIS
   message.  When NSIS signaling messages have to make packet filter
   installations up- contain IP addresses of the
   sender and downstream along the data path. Similar to
   proposals receiver in the area of QoS signaling some problems are likely to
   occur. One such problem message payloads, then an
   NSIS entity must modify them.  This is that downstream signaling in general
   causes problems because one of asymmetric routes. In particular it is
   difficult to determine the firewall cases, where the downstream data traffic
   will enter a network. The problem of triggering downstream
   reservations NSIS
   aware NATs is also helpful for example described in [18] . Another problem for
   example is the placement other types of a firewall or signaling applications
   e.g.  QoS signaling.

A.8  NTLP/NSLP NAT along the path other
   than in the access network. This would prevent a successful data
   exchange.

   The following behavior has to be assumed in order for this approach
   to be applicable:

   1. Support

   It must be possible to trigger a signaling message exchange for a
       downstream signaling message exchange at the firewall where the
       data traffic enters the network.

   2.  No other firewalls or NSIS NATs are present along the path other than
       in the access network. to change NTLP and/
   or NSLP message payloads, which carry IP address and port
   information.  This approach suffers from the following drawbacks:

   1.  To signal policy rules only within functionality includes the access network (by both
       end-points) has a number support of disadvantage providing
   mid-session and challenges (see for
       example [18] ). The complex message processing caused by this
       approach strongly argues against it although it might sound
       simple (and even might mid-path modification of these payloads.  As a
   consequence these payloads must not be simple reordered, integrity protected
   and/or encrypted in restricted environments).

   2.  Complex topologies might lead to ineffective policy rules (i.e.
       data traffic hits firewalls hits wrong firewalls).

D.3 Solution Approach: Authorization Tokens

   The last approach is based on some exchanged authorization tokens
   which are created by an authorized entity (such as the PDP) or by a
   trusted third party. Both end hosts need to exchange these tokens
   with protocols such as SIP or HTTP since non peer-to-peer fashion (e.g.  end-to-middle,
   end-to-end protection).  Ideally these protocols are likely
   to mutable payloads must be allowed
   marked (e.g.  a protected flag) to bypass the firewall. The basic idea assist NATs in their effort of this approach
   is to provide an end host, which requests access to the network, with
   credentials (referred as authorization tokens). These tokens have to
   possess some properties, namely:

   1.  They have to be restrictive by including lifetimes, source
   adjusting these payloads.

A.9  Combining Middlebox and
       destination identifiers, usage indication QoS signaling

   In many cases, middlebox and more.

   2.  They have to provide basic replay protection to prevent
       unauthorized reuse.

   3.  The have be cryptographically protected to prevent manipulations.

   4.  There QoS signaling has to be a mechanism combined at
   least logically.  Hence, it was suggested to dynamically create combine them for into a
       specific reason and
   single signaling message or to distribute tie them to together with the end points.

   5.  It help of
   some sort of data connection identifier, later on referred as Session
   ID.  This, however, has to be possible to exchange tokens via a trusted third part
       in cases where no direct communication between the end hosts is
       possible (due to NAT).

   6.  The token can be created locally at the network or by some disadvantages such as:

   - NAT/FW NSLP signaling affects a trusted
       third party.

   An example much small number of a possible signaling communication could have the
   following structure: After exchanging the tokens between the two end
   hosts. Host A would include NSIS nodes
   along the received authorization token path (for example compared to the QoS signaling).

   - NAT/FW signaling message for Network B. When the signaling message arrives
   at Middlebox 2 then the token is verified by the token-creating
   entity. In order to prevent parties from reusing the token timestamps
   (e.g. token creation, token lifetime, etc.) have to be included.
   Adding IP address information about Host A would create difficulties
   in relationship with NATs. Information about Host B might be possible
   to include in order to limit attacks where a token is lost and reused
   by a different host for a show different purpose. signaling patterns (e.g.
   required end-to-middle communication).

   - The goal refresh interval is likely to restrict
   the usage be different.

   - The number of the token for error cases increase as different signaling
   applications are combined into a specific session. single message.  The content of the
   token only needs to be verified by the originator combination of the token since
   it only
   error cases has to be verified locally. Since authorization needs to be
   linked considered.

A.10  Inability to know the authorized actions, which have to scenario

   In Section 2.1 a number of different scenarios are presented.  Data
   receiver and sender may be performed located behind zero, one, or more
   Firewalls and NATs.  Depending on the
   packets matching the packet filter, the token may include the
   associated action or a reference to it. The following behavior has to
   be assumed in order for this approach scenario, different signaling
   approaches have to be applicable:

   1.  The exchange taken.  For instance,  data receiver with no
   NAT and Firewall can receive any sort of authorization tokens between end-systems data and signaling without
   any further action.  Data receivers behind a NAT must be
       possible. These protocols first obtain a
   public IP address before any signaling can happen.  The scenario
   might even change over time with moving networks, ad-hoc networks or
   with mobility.

   NSIS signaling must be allowed assume the worst case and cannot put
   responsibility to pass the firewalls.

   2.  An end-system must user to know which scenario is currently
   applicable.  As a result, it  might be able necessary to request perform a
   "discovery" periodically such an authorization token
       at some entity in that the local network or NSIS entity at a trusted third party.

   This approach suffers from the following drawback:

   1.  Possibly an additional protocol is required for an end host
   has enough information to
       request an authorization token from an entity decide which scenario is currently
   applicable.  This additional messaging, which might not be necessary
   in all cases, requires additional performance, bandwidth and adds
   complexity.  Additional, information by the local
       network. user can provide
   information to assist this "discovery" process, but cannot replace
   it.

Appendix E. B.  Acknowledgments

   We would like to acknowledge Vishal Sankhla and Joao Girao for their
   input to this draft.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.