tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5973

Experimental
Pages: 90
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: NSIS

NAT/Firewall NSIS Signaling Layer Protocol (NSLP)

Part 1 of 5, p. 1 to 12
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                    M. Stiemerling
Request for Comments: 5973                                           NEC
Category: Experimental                                     H. Tschofenig
ISSN: 2070-1721                                   Nokia Siemens Networks
                                                                 C. Aoun
                                                              Consultant
                                                               E. Davies
                                                        Folly Consulting
                                                            October 2010


           NAT/Firewall NSIS Signaling Layer Protocol (NSLP)

Abstract

   This memo defines the NSIS Signaling Layer Protocol (NSLP) for
   Network Address Translators (NATs) and firewalls.  This NSLP allows
   hosts to signal on the data path for NATs and firewalls to be
   configured according to the needs of the application data flows.  For
   instance, it enables hosts behind NATs to obtain a publicly reachable
   address and hosts behind firewalls to receive data traffic.  The
   overall architecture is given by the framework and requirements
   defined by the Next Steps in Signaling (NSIS) working group.  The
   network scenarios, the protocol itself, and examples for path-coupled
   signaling are given in this memo.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  It represents the consensus of the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are a candidate for any level of
   Internet Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5973.

Page 2 
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Top       Page 3 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Scope and Background . . . . . . . . . . . . . . . . . . .  5
     1.2.  Terminology and Abbreviations  . . . . . . . . . . . . . .  8
     1.3.  Notes on the Experimental Status . . . . . . . . . . . . . 10
     1.4.  Middleboxes  . . . . . . . . . . . . . . . . . . . . . . . 10
     1.5.  General Scenario for NATFW Traversal . . . . . . . . . . . 11
   2.  Network Deployment Scenarios Using the NATFW NSLP  . . . . . . 13
     2.1.  Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13
     2.2.  NAT with Two Private Networks  . . . . . . . . . . . . . . 14
     2.3.  NAT with Private Network on Sender Side  . . . . . . . . . 15
     2.4.  NAT with Private Network on Receiver Side Scenario . . . . 15
     2.5.  Both End Hosts behind Twice-NATs . . . . . . . . . . . . . 16
     2.6.  Both End Hosts behind Same NAT . . . . . . . . . . . . . . 17
     2.7.  Multihomed Network with NAT  . . . . . . . . . . . . . . . 18
     2.8.  Multihomed Network with Firewall . . . . . . . . . . . . . 18
   3.  Protocol Description . . . . . . . . . . . . . . . . . . . . . 19
     3.1.  Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 19
     3.2.  Basic Protocol Overview  . . . . . . . . . . . . . . . . . 20
       3.2.1.  Signaling for Outbound Traffic . . . . . . . . . . . . 20
       3.2.2.  Signaling for Inbound Traffic  . . . . . . . . . . . . 22
       3.2.3.  Signaling for Proxy Mode . . . . . . . . . . . . . . . 23
       3.2.4.  Blocking Traffic . . . . . . . . . . . . . . . . . . . 24
       3.2.5.  State and Error Maintenance  . . . . . . . . . . . . . 24
       3.2.6.  Message Types  . . . . . . . . . . . . . . . . . . . . 25
       3.2.7.  Classification of RESPONSE Messages  . . . . . . . . . 25
       3.2.8.  NATFW NSLP Signaling Sessions  . . . . . . . . . . . . 26
     3.3.  Basic Message Processing . . . . . . . . . . . . . . . . . 27
     3.4.  Calculation of Signaling Session Lifetime  . . . . . . . . 27
     3.5.  Message Sequencing . . . . . . . . . . . . . . . . . . . . 31
     3.6.  Authentication, Authorization, and Policy Decisions  . . . 32
     3.7.  Protocol Operations  . . . . . . . . . . . . . . . . . . . 32
       3.7.1.  Creating Signaling Sessions  . . . . . . . . . . . . . 32
       3.7.2.  Reserving External Addresses . . . . . . . . . . . . . 35
       3.7.3.  NATFW NSLP Signaling Session Refresh . . . . . . . . . 43
       3.7.4.  Deleting Signaling Sessions  . . . . . . . . . . . . . 45
       3.7.5.  Reporting Asynchronous Events  . . . . . . . . . . . . 46
       3.7.6.  Proxy Mode of Operation  . . . . . . . . . . . . . . . 48
     3.8.  Demultiplexing at NATs . . . . . . . . . . . . . . . . . . 53
     3.9.  Reacting to Route Changes  . . . . . . . . . . . . . . . . 54
     3.10. Updating Policy Rules  . . . . . . . . . . . . . . . . . . 55
   4.  NATFW NSLP Message Components  . . . . . . . . . . . . . . . . 55
     4.1.  NSLP Header  . . . . . . . . . . . . . . . . . . . . . . . 56
     4.2.  NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 57
       4.2.1.  Signaling Session Lifetime Object  . . . . . . . . . . 58
       4.2.2.  External Address Object  . . . . . . . . . . . . . . . 58
       4.2.3.  External Binding Address Object  . . . . . . . . . . . 59

Top      ToC       Page 4 
       4.2.4.  Extended Flow Information Object . . . . . . . . . . . 59
       4.2.5.  Information Code Object  . . . . . . . . . . . . . . . 60
       4.2.6.  Nonce Object . . . . . . . . . . . . . . . . . . . . . 64
       4.2.7.  Message Sequence Number Object . . . . . . . . . . . . 64
       4.2.8.  Data Terminal Information Object . . . . . . . . . . . 64
       4.2.9.  ICMP Types Object  . . . . . . . . . . . . . . . . . . 66
     4.3.  Message Formats  . . . . . . . . . . . . . . . . . . . . . 67
       4.3.1.  CREATE . . . . . . . . . . . . . . . . . . . . . . . . 67
       4.3.2.  EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 68
       4.3.3.  RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 68
       4.3.4.  NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 69
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 69
     5.1.  Authorization Framework  . . . . . . . . . . . . . . . . . 70
       5.1.1.  Peer-to-Peer Relationship  . . . . . . . . . . . . . . 70
       5.1.2.  Intra-Domain Relationship  . . . . . . . . . . . . . . 71
       5.1.3.  End-to-Middle Relationship . . . . . . . . . . . . . . 72
     5.2.  Security Framework for the NAT/Firewall NSLP . . . . . . . 73
       5.2.1.  Security Protection between Neighboring NATFW NSLP
               Nodes  . . . . . . . . . . . . . . . . . . . . . . . . 73
       5.2.2.  Security Protection between Non-Neighboring NATFW
               NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 74
     5.3.  Implementation of NATFW NSLP Security  . . . . . . . . . . 75
   6.  IAB Considerations on UNSAF  . . . . . . . . . . . . . . . . . 76
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 77
     7.1.  NATFW NSLP Message Type Registry . . . . . . . . . . . . . 77
     7.2.  NATFW NSLP Header Flag Registry  . . . . . . . . . . . . . 77
     7.3.  NSLP Message Object Registry . . . . . . . . . . . . . . . 78
     7.4.  NSLP Response Code Registry  . . . . . . . . . . . . . . . 78
     7.5.  NSLP IDs and Router Alert Option Values  . . . . . . . . . 78
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 78
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 79
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 79
   Appendix A.  Selecting Signaling Destination Addresses for
                EXTERNAL  . . . . . . . . . . . . . . . . . . . . . . 81
   Appendix B.  Usage of External Binding Addresses . . . . . . . . . 82
   Appendix C.  Applicability Statement on Data Receivers behind
                Firewalls . . . . . . . . . . . . . . . . . . . . . . 83
   Appendix D.  Firewall and NAT Resources  . . . . . . . . . . . . . 84
     D.1.  Wildcarding of Policy Rules  . . . . . . . . . . . . . . . 84
     D.2.  Mapping to Firewall Rules  . . . . . . . . . . . . . . . . 84
     D.3.  Mapping to NAT Bindings  . . . . . . . . . . . . . . . . . 85
     D.4.  NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 85
   Appendix E.  Example for Receiver Proxy Case . . . . . . . . . . . 86

Top      ToC       Page 5 
1.  Introduction

1.1.  Scope and Background

   Firewalls and Network Address Translators (NATs) have both been used
   throughout the Internet for many years, and they will remain present
   for the foreseeable future.  Firewalls are used to protect networks
   against certain types of attacks from internal networks and the
   Internet, whereas NATs provide a virtual extension of the IP address
   space.  Both types of devices may be obstacles to some applications,
   since they only allow traffic created by a limited set of
   applications to traverse them, typically those that use protocols
   with relatively predetermined and static properties (e.g., most HTTP
   traffic, and other client/server applications).  Other applications,
   such as IP telephony and most other peer-to-peer applications, which
   have more dynamic properties, create traffic that is unable to
   traverse NATs and firewalls without assistance.  In practice, the
   traffic of many applications cannot traverse autonomous firewalls or
   NATs, even when they have additional functionality that attempts to
   restore the transparency of the network.

   Several solutions to enable applications to traverse such entities
   have been proposed and are currently in use.  Typically, application-
   level gateways (ALGs) have been integrated with the firewall or NAT
   to configure the firewall or NAT dynamically.  Another approach is
   middlebox communication (MIDCOM).  In this approach, ALGs external to
   the firewall or NAT configure the corresponding entity via the MIDCOM
   protocol [RFC3303].  Several other work-around solutions are
   available, such as Session Traversal Utilities for NAT (STUN)
   [RFC5389].  However, all of these approaches introduce other problems
   that are generally hard to solve, such as dependencies on the type of
   NAT implementation (full-cone, symmetric, etc.), or dependencies on
   certain network topologies.

   NAT and firewall (NATFW) signaling shares a property with Quality-of-
   Service (QoS) signaling -- each must reach any device that is on the
   data path and is involved in (respectively) NATFW or QoS treatment of
   data packets.  This means that for both NATFW and QoS it is
   convenient if signaling travels path-coupled, i.e., the signaling
   messages follow exactly the same path that the data packets take.
   The Resource Reservation Protocol (RSVP) [RFC2205] is an example of a
   current QoS signaling protocol that is path-coupled. [rsvp-firewall]
   proposes the use of RSVP as a firewall signaling protocol but does
   not include NATs.

   This memo defines a path-coupled signaling protocol for NAT and
   firewall configuration within the framework of NSIS, called the NATFW
   NSIS Signaling Layer Protocol (NSLP).  The general requirements for

Top      ToC       Page 6 
   NSIS are defined in [RFC3726] and the general framework of NSIS is
   outlined in [RFC4080].  It introduces the split between an NSIS
   transport layer and an NSIS signaling layer.  The transport of NSLP
   messages is handled by an NSIS Network Transport Layer Protocol
   (NTLP, with General Internet Signaling Transport (GIST) [RFC5971]
   being the implementation of the abstract NTLP).  The signaling logic
   for QoS and NATFW signaling is implemented in the different NSLPs.
   The QoS NSLP is defined in [RFC5974].

   The NATFW NSLP is designed to request the dynamic configuration of
   NATs and/or firewalls along the data path.  Dynamic configuration
   includes enabling data flows to traverse these devices without being
   obstructed, as well as blocking of particular data flows at inbound
   firewalls.  Enabling data flows requires the loading of firewall
   rules with an action that allows the data flow packets to be
   forwarded and NAT bindings to be created.  The blocking of data flows
   requires the loading of firewall rules with an action that will deny
   forwarding of the data flow packets.  A simplified example for
   enabling data flows: a source host sends a NATFW NSLP signaling
   message towards its data destination.  This message follows the data
   path.  Every NATFW NSLP-enabled NAT/firewall along the data path
   intercepts this message, processes it, and configures itself
   accordingly.  Thereafter, the actual data flow can traverse all these
   configured firewalls/NATs.

   It is necessary to distinguish between two different basic scenarios
   when operating the NATFW NSLP, independent of the type of the
   middleboxes to be configured.

   1.  Both the data sender and data receiver are NSIS NATFW NSLP aware.
       This includes the cases in which the data sender is logically
       decomposed from the initiator of the NSIS signaling (the so-
       called NSIS initiator) or the data receiver logically decomposed
       from the receiver of the NSIS signaling (the so-called NSIS
       receiver), but both sides support NSIS.  This scenario assumes
       deployment of NSIS all over the Internet, or at least at all NATs
       and firewalls.  This scenario is used as a base assumption, if
       not otherwise noted.

   2.  Only one end host or region of the network is NSIS NATFW NSLP
       aware, either the data receiver or data sender.  This scenario is
       referred to as proxy mode.

   The NATFW NSLP has two basic signaling messages that are sufficient
   to cope with the various possible scenarios likely to be encountered
   before and after widespread deployment of NSIS:

Top      ToC       Page 7 
      CREATE message: Sent by the data sender for configuring a path
      outbound from a data sender to a data receiver.

      EXTERNAL message: Used by a data receiver to locate inbound NATs/
      firewalls and prime them to expect inbound signaling and used at
      NATs to pre-allocate a public address.  This is used for data
      receivers behind these devices to enable their reachability.

   CREATE and EXTERNAL messages are sent by the NSIS initiator (NI)
   towards the NSIS responder (NR).  Both types of message are
   acknowledged by a subsequent RESPONSE message.  This RESPONSE message
   is generated by the NR if the requested configuration can be
   established; otherwise, the NR or any of the NSLP forwarders (NFs)
   can also generate such a message if an error occurs.  NFs and the NR
   can also generate asynchronous messages to notify the NI, the so-
   called NOTIFY messages.

   If the data receiver resides in a private addressing realm or behind
   a firewall, and it needs to preconfigure the edge-NAT/edge-firewall
   to provide a (publicly) reachable address for use by the data sender,
   a combination of EXTERNAL and CREATE messages is used.

   During the introduction of NSIS, it is likely that one or the other
   of the data sender and receiver will not be NSIS aware.  In these
   cases, the NATFW NSLP can utilize NSIS-aware middleboxes on the path
   between the data sender and data receiver to provide proxy NATFW NSLP
   services (i.e., the proxy mode).  Typically, these boxes will be at
   the boundaries of the realms in which the end hosts are located.

   The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in
   NSIS entities.  NTLP state allows signaling messages to travel in the
   forward (outbound) and the reverse (inbound) direction along the path
   between a NAT/firewall NSLP sender and a corresponding receiver.
   This state is managed using a soft-state mechanism, i.e., it expires
   unless it is refreshed from time to time.  The NAT bindings and
   firewall rules being installed during the state setup are bound to
   the particular signaling session.  However, the exact local
   implementation of the NAT bindings and firewall rules are NAT/
   firewall specific and it is out of the scope of this memo.

   This memo is structured as follows.  Section 2 describes the network
   environment for NATFW NSLP signaling.  Section 3 defines the NATFW
   signaling protocol and Section 4 defines the message components and
   the overall messages used in the protocol.  The remaining parts of
   the main body of the document cover security considerations
   Section 5, IAB considerations on UNilateral Self-Address Fixing

Top      ToC       Page 8 
   (UNSAF) [RFC3424] in Section 6, and IANA considerations in Section 7.
   Please note that readers familiar with firewalls and NATs and their
   possible location within networks can safely skip Section 2.

1.2.  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 [RFC2119].

   This document uses a number of terms defined in [RFC3726] and
   [RFC4080].  The following additional terms are used:

   o  Policy rule: 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 conditions are the specification of a set of
      packets to which the rule is applied.  The set of actions always
      contains just a single element per rule, and is limited to either
      action "deny" or action "allow".

   o  Reserved policy rule: A policy rule stored at NATs or firewalls
      for activation by a later, different signaling exchange.  This
      type of policy rule is kept in the NATFW NSLP and is not loaded
      into the firewall or NAT engine, i.e., it does not affect the data
      flow handling.

   o  Installed policy rule: A policy rule in operation at NATs or
      firewalls.  This type of rule is kept in the NATFW NSLP and is
      loaded into the firewall or NAT engine, i.e., it is affecting the
      data flow.

   o  Remembered policy rule: A policy rule stored at NATs and firewalls
      for immediate use, as soon as the signaling exchange is
      successfully completed.

   o  Firewall: A packet filtering device that matches packets against a
      set of policy rules and applies the actions.

   o  Network Address Translator: Network Address Translation is a
      method by which IP addresses are mapped from one IP address realm
      to another, in an attempt to provide transparent routing between
      hosts (see [RFC2663]).  Network Address Translators are devices
      that perform this work by modifying packets passing through them.

   o  Data Receiver (DR): The node in the network that is receiving the
      data packets of a flow.

Top      ToC       Page 9 
   o  Data Sender (DS): The node in the network that is sending the data
      packets of a flow.

   o  NATFW NSLP peer (or simply "peer"): An NSIS NATFW NSLP node with
      which an NTLP adjacency has been created as defined in [RFC5971].

   o  NATFW NSLP signaling session (or simply "signaling session"): A
      signaling session defines an association between the NI, NFs, and
      the NR related to a data flow.  All the NATFW NSLP peers on the
      path, including the NI and the NR, use the same identifier to
      refer to the state stored for the association.  The same NI and NR
      may have more than one signaling session active at any time.  The
      state for the NATFW NSLP consists of NSLP state and associated
      policy rules at a middlebox.

   o  Edge-NAT: An edge-NAT is a NAT device with a globally routable IP
      address that is reachable from the public Internet.

   o  Edge-firewall: An edge-firewall is a firewall device that is
      located on the borderline of an administrative domain.

   o  Public Network: "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" [RFC2663].

   o  Private/Local Network: "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" [RFC2663].

   o  Public/Global IP address: An IP address located in the public
      network according to Section 2.7 of [RFC2663].

   o  Private/Local IP address: An IP address located in the private
      network according to Section 2.8 of [RFC2663].

   o  Signaling Destination Address (SDA): An IP address generally taken
      from the public/global IP address range, although, the SDA may, in
      certain circumstances, be part of the private/local IP address
      range.  This address is used in EXTERNAL signaling message
      exchanges, if the data receiver's IP address is unknown.

Top      ToC       Page 10 
1.3.  Notes on the Experimental Status

   The same deployment issues and extensibility considerations described
   in [RFC5971] and [RFC5978] also apply to this document.

1.4.  Middleboxes

   The term "middlebox" covers a range of devices and is well-defined in
   [RFC3234]: "A middlebox is defined as any intermediary 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".  As such, middleboxes fall into a number of
   categories with a wide range of functionality, not all of which is
   pertinent to the NATFW NSLP.  Middlebox categories in the scope of
   this memo are firewalls that filter data packets against a set of
   filter rules, and NATs that translate packet addresses from one
   address realm to another address realm.  Other categories of
   middleboxes, such as QoS traffic shapers, are out of the scope of
   this memo.

   The term "NAT" used in this document is a placeholder for a range of
   different NAT flavors.  We consider the following types of NATs:

   o  Traditional NAT (basic NAT and NAPT)

   o  Bi-directional NAT

   o  Twice-NAT

   o  Multihomed NAT

   For definitions and a detailed discussion about the characteristics
   of each NAT type, please see [RFC2663].

   All types of middleboxes under consideration here use policy rules to
   make a decision on data packet treatment.  Policy rules consist of a
   flow identifier that selects the packets to which the policy applies
   and an associated action; data packets matching the flow identifier
   are subjected to the policy rule action.  A typical flow identifier
   is the 5-tuple selector that matches the following fields of a packet
   to configured values:

   o  Source and destination IP addresses

   o  Transport protocol number

   o  Transport source and destination port numbers

Top      ToC       Page 11 
   Actions for firewalls are usually one or more of:

   o  Allow: forward data packet

   o  Deny: block data packet and discard it

   o  Other actions such as logging, diverting, duplicating, etc.

   Actions for NATs include (amongst many others):

   o  Change source IP address and transport port number to a globally
      routable IP address and associated port number.

   o  Change destination IP address and transport port number to a
      private IP address and associated port number.

   It should be noted that a middlebox may contain two logical
   representations of the policy rule.  The policy rule has a
   representation within the NATFW NSLP, comprising the message routing
   information (MRI) of the NTLP and NSLP information (such as the rule
   action).  The other representation is the implementation of the NATFW
   NSLP policy rule within the NAT and firewall engine of the particular
   device.  Refer to Appendix D for further details.

1.5.  General Scenario for NATFW Traversal

   The purpose of NSIS NATFW signaling is to enable communication
   between endpoints across networks, even in the presence of NAT and
   firewall middleboxes that have not been specially engineered to
   facilitate communication with the application protocols used.  This
   removes the need to create and maintain application layer gateways
   for specific protocols that have been commonly used to provide
   transparency in previous generations of NAT and firewall middleboxes.
   It is assumed that these middleboxes will be statically configured in
   such a way that NSIS NATFW signaling messages themselves are allowed
   to reach the locally installed NATFW NSLP daemon.  NSIS NATFW NSLP
   signaling is used to dynamically install additional policy rules in
   all NATFW middleboxes along the data path that will allow
   transmission of the application data flow(s).  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.  An
   additional capability, that is an exception to the primary goal of
   NSIS NATFW signaling, is that the NATFW nodes can request blocking of
   particular data flows instead of enabling these flows at inbound
   firewalls.

Top      ToC       Page 12 
   The basic high-level picture of NSIS usage is that end hosts are
   located behind middleboxes, meaning that there is at least one
   middlebox on the data path from the end host in a private network to
   the external network (NATFW in Figure 1).  Applications located at
   these end hosts try to establish communication with corresponding
   applications on other such end hosts.  This communication
   establishment may require that the applications contact an
   application server that serves as a rendezvous point between both
   parties to exchange their IP address and port(s).  The local
   applications trigger the NSIS entity at the local host to control
   provisioning for middlebox traversal along the prospective data path
   (e.g., via an API call).  The NSIS entity, in turn, uses NSIS NATFW
   NSLP signaling to establish policy rules along the data path,
   allowing the data to travel from the sender to the receiver without
   obstruction.

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

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

   Note that 1+ refers to one or more NATFW nodes.

         Figure 1: Generic View of NSIS with NATs and/or Firewalls

   For end-to-end NATFW signaling, it is necessary that each firewall
   and each NAT along the path between the data sender and the data
   receiver implements the NSIS NATFW NSLP.  There might be several NATs
   and FWs in various possible combinations on a path between two hosts.
   Section 2 presents a number of likely scenarios with different
   combinations of NATs and firewalls.  However, the scenarios given in
   the following sections are only examples and should not be treated as
   limiting the scope of the NATFW NSLP.


Next RFC Part