Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5973

NAT/Firewall NSIS Signaling Layer Protocol (NSLP)

Pages: 90
Experimental
Part 1 of 5 – Pages 1 to 12
None   None   Next

Top   ToC   RFC5973 - 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.
Top   ToC   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   ToC   RFC5973 - 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   RFC5973 - 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   RFC5973 - 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   RFC5973 - 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   RFC5973 - 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   RFC5973 - 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   RFC5973 - 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   RFC5973 - 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   RFC5973 - 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   RFC5973 - 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 page on part 2)

Next Section