tech-invite   World Map     

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

RFC 5973

 
 
 

NAT/Firewall NSIS Signaling Layer Protocol (NSLP)

Part 2 of 5, p. 13 to 31
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 13 
2.  Network Deployment Scenarios Using the NATFW NSLP

   This section introduces several scenarios for middlebox placement
   within IP networks.  Middleboxes are typically found at various
   different locations, including at enterprise network borders, within
   enterprise networks, as mobile phone network gateways, etc.  Usually,
   middleboxes are placed more towards the edge of networks than in
   network cores.  Firewalls and NATs may be found at these locations
   either alone or combined; other categories of middleboxes may also be
   found at such locations, possibly combined with the NATs and/or
   firewalls.

   NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the
   regular data path to the NSIS responder (NR).  On the data path,
   NATFW NSLP signaling messages reach different NSIS nodes that
   implement the NATFW NSLP.  Each NATFW NSLP node processes the
   signaling messages according to Section 3 and, if necessary, installs
   policy rules for subsequent data packets.

   Each of the following sub-sections 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.  Firewall Traversal

   This section describes a scenario with firewalls only; NATs are not
   involved.  Each end host is behind a firewall.  The firewalls are
   connected via the public Internet.  Figure 2 shows the topology.  The
   part labeled "public" is the Internet connecting both firewalls.

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

                 private     public        private

             FW: Firewall
             NI: NSIS Initiator
             NR: NSIS Responder

                   Figure 2: Firewall Traversal Scenario

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

Top      Up      ToC       Page 14 
   There are several very different ways to place firewalls in a network
   topology.  To distinguish firewalls located at network borders, such
   as administrative domains, from others located internally, the term
   edge-firewall is used.  A similar distinction can be made for NATs,
   with an edge-NAT fulfilling the equivalent role.

2.2.  NAT with Two Private Networks

   Figure 3 shows a scenario with NATs at both ends of the network.
   Therefore, each application instance, the NSIS initiator and the NSIS
   responder, are behind NATs.  The outermost NAT, known as the edge-NAT
   (MB2 and MB3), at each side is connected to the public Internet.  The
   NATs are generically labeled as MBX (for middlebox No. X), since
   those devices certainly implement NAT functionality, but can
   implement firewall functionality as well.

   Only two middleboxes (MBs) are shown in Figure 3 at each side, but in
   general, any number of MBs on each side must be considered.

           +----+     +----+    //----\\    +----+     +----+
      NI --| MB1|-----| MB2|---|        |---| MB3|-----| MB4|--- NR
           +----+     +----+    \\----//    +----+     +----+

                private          public          private

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

             Figure 3: NAT with two Private Networks Scenario

   Signaling traffic from the NI to the NR has to traverse all the
   middleboxes on the path (MB1 to MB4, in this order), and all the
   middleboxes must be configured properly to allow NSIS signaling to
   traverse them.  The NATFW signaling must configure all middleboxes
   and consider any address translation that will result from this
   configuration in further signaling.  The sender (NI) has to know the
   IP address of the receiver (NR) in advance, otherwise it will not be
   possible to send any NSIS signaling messages towards the responder.
   Note that this IP address is not the private IP address of the
   responder but the NAT's public IP address (here MB3's IP address).
   Instead, a NAT binding (including a public IP address) has to be
   previously installed on the NAT MB3.  This NAT binding subsequently
   allows packets reaching the NAT to be forwarded to the receiver
   within the private address realm.  The receiver might have a number
   of ways to learn its public IP address and port number (including the
   NATFW NSLP) and might need to signal this information to the sender
   using an application-level signaling protocol.

Top      Up      ToC       Page 15 
2.3.  NAT with Private Network on Sender Side

   This scenario shows an application instance at the sending node that
   is behind one or more NATs (shown as generic MB, see discussion in
   Section 2.2).  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 Side

   The traffic from NI to NR has to traverse middleboxes only 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 accordingly.

   The data sender does not necessarily know whether or not the receiver
   is behind a NAT; hence, it is the receiving side that has to detect
   whether or not it is behind a NAT.

2.4.  NAT with Private Network on Receiver Side Scenario

   The application instance receiving data is behind one or more NATs
   shown as MB (see discussion in Section 2.2).

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

                public          private

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

          Figure 5: NAT with Private Network on Receiver Scenario

   Initially, the NSIS responder must determine its publicly reachable
   IP address at the external middlebox and notify the NSIS initiator
   about this address.  One possibility is that an application-level

Top      Up      ToC       Page 16 
   protocol is used, meaning that the public IP address is signaled via
   this protocol to the NI.  Afterwards, the NI can start its signaling
   towards the NR and therefore establish the path via the middleboxes
   in the receiver side private network.

   This scenario describes the use case for the EXTERNAL message of the
   NATFW NSLP.

2.5.  Both End Hosts behind Twice-NATs

   This is a special case, where the main problem arises from the need
   to detect that both end hosts are logically within the same address
   space, but are also in two partitions of the address realm on either
   side of a twice-NAT (see [RFC2663] for a discussion of twice-NAT
   functionality).

   Sender and receiver are both within a single private address realm,
   but the two partitions potentially have overlapping IP address
   ranges.  Figure 6 shows the arrangement of NATs.

                                   public

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

                   private

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

     Figure 6: NAT to Public, Sender and Receiver on Either Side of a
                            Twice-NAT Scenario

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

   This scenario requires the assistance of application-level entities,
   such as a DNS server.  The application-level entities must handle
   requests that are based on symbolic names and configure the
   middleboxes so that data packets are correctly forwarded from NI to

Top      Up      ToC       Page 17 
   NR.  The configuration of those middleboxes may require other
   middlebox communication protocols, such as MIDCOM [RFC3303].  NSIS
   signaling is not required in the twice-NAT only case, since
   middleboxes of the twice-NAT type are normally configured by other
   means.  Nevertheless, NSIS signaling might be useful when there are
   also firewalls on the path.  In this case, NSIS will not configure
   any policy rule at twice-NATs, but will configure policy rules at the
   firewalls on the path.  The NSIS signaling protocol must be at least
   robust enough to survive this scenario.  This requires that twice-
   NATs must implement the NATFW NSLP also and participate in NATFW
   signaling sessions, but they do not change the configuration of the
   NAT, i.e., they only read the address mapping information out of the
   NAT and translate the Message Routing Information (MRI, [RFC5971])
   within the NSLP and NTLP accordingly.  For more information, see
   Appendix D.4.

2.6.  Both End Hosts behind Same NAT

   When the NSIS initiator and NSIS responder are behind the same NAT
   (thus, being in the same address realm, see Figure 7), they are most
   likely not aware of this fact.  As in Section 2.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: from initiator to public IP address of responder (first time)
   and from public IP address of responder to responder (second time).

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


             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

            Figure 7: NAT to Public, Both Hosts behind Same NAT

Top      Up      ToC       Page 18 
2.7.  Multihomed Network with NAT

   The previous sub-sections sketched network topologies where several
   NATs and/or firewalls are ordered sequentially on the path.  This
   section describes a multihomed scenario with two NATs placed on
   alternative paths to the public network.

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

        private          public

             MB: Middlebox
             NI: NSIS Initiator
             NR: NSIS Responder

                Figure 8: Multihomed Network with Two NATs

   Depending on the destination, either one or the other middlebox is
   used for the data flow.  Which middlebox is used, depends on local
   policy or routing decisions.  NATFW NSLP must be able to handle this
   situation properly, see Section 3.7.2 for an extended discussion of
   this topic with respect to NATs.

2.8.  Multihomed Network with Firewall

   This section describes a multihomed scenario with two firewalls
   placed on alternative paths to the public network (Figure 9).  The
   routing in the private and public networks decides which firewall is
   being taken for data flows.  Depending on the data flow's direction,
   either outbound or inbound, a different firewall could be traversed.
   This is a challenge for the EXTERNAL message of the NATFW NSLP where
   the NSIS responder is located behind these firewalls within the
   private network.  The EXTERNAL message is used to block a particular
   data flow on an inbound firewall.  NSIS must route the EXTERNAL
   message inbound from NR to NI probably without knowing which path the
   data traffic will take from NI to NR (see also Appendix C).

Top      Up      ToC       Page 19 
             +----+
   NR -------| FW |\
       \     +----+ \  //---\\
        \            -|       |-- NI
         \             \\---//
          \  +----+       |
           --| FW |-------+
             +----+
             private

        private          public

             FW: Firewall
             NI: NSIS Initiator
             NR: NSIS Responder

              Figure 9: Multihomed Network with Two Firewalls

3.  Protocol Description

   This section defines messages, objects, and protocol semantics for
   the NATFW NSLP.

3.1.  Policy Rules

   Policy rules, bound to a NATFW NSLP signaling session, are the
   building blocks of middlebox devices considered in the NATFW NSLP.
   For firewalls, the policy rule usually consists of a 5-tuple and an
   action such as allow or deny.  The information contained in the tuple
   includes source/destination IP addresses, transport protocol, and
   source/destination port numbers.  For NATs, the policy rule consists
   of the action 'translate this address' and further mapping
   information, that might be, in the simplest case, internal IP address
   and external IP address.

   The NATFW NSLP carries, in conjunction with the NTLP's Message
   Routing Information (MRI), the policy rules to be installed at NATFW
   peers.  This policy rule is an abstraction with respect to the real
   policy rule to be installed at the respective firewall or NAT.  It
   conveys the initiator's request and must be mapped to the possible
   configuration on the particular used NAT and/or firewall in use.  For
   pure firewalls, one or more filter rules must be created, and for
   pure NATs, one or more NAT bindings must be created.  In mixed
   firewall and NAT boxes, the policy rule must be mapped to filter
   rules and bindings observing the ordering of the firewall and NAT
   engine.  Depending on the ordering, NAT before firewall or vice

Top      Up      ToC       Page 20 
   versa, the firewall rules must carry public or private IP addresses.
   However, the exact mapping depends on the implementation of the
   firewall or NAT that is possibly different for each implementation.

   The policy rule at the NATFW NSLP level comprises the message routing
   information (MRI) part, carried in the NTLP, and the information
   available in the NATFW NSLP.  The information provided by the NSLP is
   stored in the 'extend flow information' (NATFW_EFI) and 'data
   terminal information' (NATFW_DTINFO) objects, and the message type.
   Additional information, such as the external IP address and port
   number, stored in the NAT or firewall, will be used as well.  The MRI
   carries the filter part of the NAT/firewall-level policy rule that is
   to be installed.

   The NATFW NSLP specifies two actions for the policy rules: deny and
   allow.  A policy rule with action set to deny will result in all
   packets matching this rule to be dropped.  A policy rule with action
   set to allow will result in all packets matching this rule to be
   forwarded.

3.2.  Basic Protocol Overview

   The NSIS NATFW NSLP is carried over the General Internet Signaling
   Transport (GIST, the implementation of the NTLP) defined in
   [RFC5971].  NATFW NSLP messages are initiated by the NSIS initiator
   (NI), handled by NSLP forwarders (NFs) and received by the NSIS
   responder (NR).  It is required that at least NI and NR implement
   this NSLP, intermediate NFs only implement this NSLP when they
   provide relevant middlebox functions.  NSLP forwarders that do not
   have any NATFW NSLP functions just forward these packets as they have
   no interest in them.

3.2.1.  Signaling for Outbound Traffic

   A data sender (DS), intending to send data to a data receiver (DR),
   has to start NATFW NSLP signaling.  This causes the NI associated
   with the DS to launch NSLP signaling towards the address of the DR
   (see Figure 10).  Although it is expected that the DS and the NATFW
   NSLP NI will usually reside on the same host, this specification does
   not rule out scenarios where the DS and NI reside on different hosts,
   the so-called proxy mode (see Section 3.7.6).

Top      Up      ToC       Page 21 
             +-------+    +-------+    +-------+    +-------+
             | DS/NI |<~~~| MB1/  |<~~~| MB2/  |<~~~| DR/NR |
             |       |--->| NF1   |--->| NF2   |--->|       |
             +-------+    +-------+    +-------+    +-------+

                 ========================================>
                    Data Traffic Direction (outbound)


                  --->  : 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 NSLP forwarder 1
                  MB2   : Middlebox 2 and NSLP forwarder 2

                     Figure 10: General NSIS Signaling

   The following list shows the normal sequence of NSLP events without
   detailing the interaction with the NTLP and the interactions on the
   NTLP level.

   o  NSIS initiators generate request messages (which are either CREATE
      or EXTERNAL messages) and send these towards the NSIS responder.
      This request message is the initial message that creates a new
      NATFW NSLP signaling session.  The NI and the NR will most likely
      already share an application session before they start the NATFW
      NSLP signaling session.  Note well the difference between both
      sessions.

   o  NSLP request messages are processed each time an NF with NATFW
      NSLP support is traversed.  Each NF that is intercepting a request
      message and is accepting it for further treatment is joining the
      particular NATFW NSLP signaling session.  These 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.

   o  NSIS responders will check received messages and process them if
      applicable.  NSIS responders generate RESPONSE messages and send
      them hop-by-hop back to the NI via the same chain of NFs
      (traversal of the same NF chain is guaranteed through the
      established reverse message routing state in the NTLP).  The NR is
      also joining the NATFW NSLP signaling session if the request
      message is accepted.

Top      Up      ToC       Page 22 
   o  The RESPONSE message is processed at each NF that has been
      included in the prior NATFW NSLP signaling session setup.

   o  If the NI has received a successful RESPONSE message and if the
      signaling NATFW NSLP session started with a CREATE message, the
      data sender can start sending its data flow to the data receiver.
      If the NI has received a successful RESPONSE message and if the
      signaling NATFW NSLP session started with an EXTERNAL message, the
      data receiver is ready to receive further CREATE messages.

   Because NATFW NSLP signaling follows the data path from DS to DR,
   this immediately enables communication between both hosts for
   scenarios with only firewalls on the data path or NATs on the sender
   side.  For scenarios with NATs on the receiver side, certain problems
   arise, as described in Section 2.4.

3.2.2.  Signaling for Inbound Traffic

   When the NR and the NI are located in different address realms and
   the NR is located behind a NAT, the NI cannot signal to the NR
   address directly.  The DR/NR is not reachable from other NIs using
   the private address of the NR and thus NATFW signaling messages
   cannot be sent to the NR/DR's address.  Therefore, the NR must first
   obtain a NAT binding that provides an address that is reachable for
   the NI.  Once the NR has acquired a public IP address, it forwards
   this information to the DS via a separate protocol.  This
   application-layer signaling, which is out of the scope of the NATFW
   NSLP, may involve third parties that assist in exchanging these
   messages.

   The same holds partially true for NRs located behind firewalls that
   block all traffic by default.  In this case, NR must tell its inbound
   firewalls of inbound NATFW NSLP signaling and corresponding data
   traffic.  Once the NR has informed the inbound firewalls, it can
   start its application-level signaling to initiate communication with
   the NI.  This mechanism can be used by machines hosting services
   behind firewalls as well.  In this case, the NR informs the inbound
   firewalls as described, but does not need to communicate this to the
   NIs.

   NATFW NSLP signaling supports this scenario by using the EXTERNAL
   message.

   1.  The DR acquires a public address by signaling on the reverse path
       (DR towards DS) and thus making itself available to other hosts.
       This process of acquiring public addresses is called reservation.
       During this process the DR reserves publicly reachable addresses
       and ports suitable for further usage in application-level

Top      Up      ToC       Page 23 
       signaling and the publicly reachable address for further NATFW
       NSLP signaling.  However, the data traffic will not be allowed to
       use this address/port initially (see next point).  In the process
       of reservation, the DR becomes the NI for the messages necessary
       to obtain the publicly reachable IP address, i.e., the NI for
       this specific NATFW NSLP signaling session.

   2.  Now on the side of the DS, the NI creates a new NATFW NSLP
       signaling session and signals directly to the public IP address
       of the DR.  This public IP address is used as NR's address, as
       the NI would do if there is no NAT in between, and creates policy
       rules at middleboxes.  Note, that the reservation will only allow
       forwarding of signaling messages, but not data flow packets.
       Policy rules allowing forwarding of data flow packets set up by
       the prior EXTERNAL message signaling will be activated when the
       signaling from NI towards NR is confirmed with a positive
       RESPONSE message.  The EXTERNAL message is described in
       Section 3.7.2.

3.2.3.  Signaling for Proxy Mode

                    administrative domain
               ----------------------------------\
                                                 |
             +-------+    +-------+    +-------+ |  +-------+
             | DS/NI |<~~~| MB1/  |<~~~| MB2/  | |  |   DR  |
             |       |--->| NF1   |--->| NR    | |  |       |
             +-------+    +-------+    +-------+ |  +-------+
                                                 |
               ----------------------------------/

                 ========================================>
                    Data Traffic Direction (outbound)


                  --->  : 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 NSLP forwarder 1
                  MB2   : Middlebox 2 and NSLP responder

              Figure 11: Proxy Mode Signaling for Data Sender

   The above usage assumes that both ends of a communication support
   NSIS, but fails when NSIS is only deployed at one end of the path.
   In this case, only one of the sending side (see Figure 11) or
   receiving side (see Figure 12) is NSIS aware and not both at the same

Top      Up      ToC       Page 24 
   time.  NATFW NSLP supports both scenarios (i.e., either the DS or DR
   does not support NSIS) by using a proxy mode, as described in
   Section 3.7.6.

                               administrative domain
                        / ----------------------------------
                        |
             +-------+  | +-------+    +-------+    +-------+
             |   DS  |  | | MB2/  |~~~>|  MB1/ |~~~>|   DR  |
             |       |  | | NR    |<---|  NF1  |<---|       |
             +-------+  | +-------+    +-------+    +-------+
                        |
                        \----------------------------------

                 ========================================>
                    Data Traffic Direction (inbound)


                  --->  : 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 NSLP forwarder 1
                  MB2   : Middlebox 2 and NSLP responder

             Figure 12: Proxy Mode Signaling for Data Receiver

3.2.4.  Blocking Traffic

   The basic functionality of the NATFW NSLP provides for opening
   firewall pin holes and creating NAT bindings to enable data flows to
   traverse these devices.  Firewalls are normally expected to work on a
   "deny-all" policy, meaning that traffic not explicitly matching any
   firewall filter rule will be blocked.  Similarly, the normal behavior
   of NATs is to block all traffic that does not match any already
   configured/installed binding or NATFW NSLP session.  However, some
   scenarios require support of firewalls having "allow-all" policies,
   allowing data traffic to traverse the firewall unless it is blocked
   explicitly.  Data receivers can utilize NATFW NSLP's EXTERNAL message
   with action set to "deny" to install policy rules at inbound
   firewalls to block unwanted traffic.

3.2.5.  State and Error Maintenance

   The protocol works on a soft-state basis, meaning that whatever state
   is installed or reserved on a middlebox will expire, and thus be
   uninstalled or forgotten after a certain period of time.  To prevent
   premature removal of state that is needed for ongoing communication,

Top      Up      ToC       Page 25 
   the NATFW NI involved will have to specifically request a NATFW NSLP
   signaling session extension.  An explicit NATFW NSLP state deletion
   capability is also provided by the protocol.

   If the actions requested by a NATFW NSLP message cannot be carried
   out, NFs and the NR must return a failure, such that appropriate
   actions can be taken.  They can do this either during the request
   message handling (synchronously) by sending an error RESPONSE message
   or at any time (asynchronously) by sending a NOTIFY notification
   message.

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

3.2.6.  Message Types

   The protocol uses four messages types:

   o  CREATE: a request message used for creating, changing, refreshing,
      and deleting NATFW NSLP signaling sessions, i.e., open the data
      path from DS to DR.

   o  EXTERNAL: a request message used for reserving, changing,
      refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions.
      EXTERNAL messages are forwarded to the edge-NAT or edge-firewall
      and allow inbound CREATE messages to be forwarded to the NR.
      Additionally, EXTERNAL messages reserve an external address and,
      if applicable, port number at an edge-NAT.

   o  NOTIFY: an asynchronous message used by NATFW peers to alert other
      NATFW peers about specific events (especially failures).

   o  RESPONSE: used as a response to CREATE and EXTERNAL request
      messages.

3.2.7.  Classification of RESPONSE Messages

   RESPONSE messages will be generated synchronously to CREATE and
   EXTERNAL messages by NSLP forwarders and responders to report success
   or failure of operations or some information relating to the NATFW
   NSLP signaling session or a node.  RESPONSE messages MUST NOT be
   generated for any other message, such as NOTIFY and RESPONSE.

   All RESPONSE messages MUST carry a NATFW_INFO object that contains an
   error class code and a response code (see Section 4.2.5).  This
   section defines terms for groups of RESPONSE messages depending on
   the error class.

Top      Up      ToC       Page 26 
   o  Successful RESPONSE: Messages carrying NATFW_INFO with error class
      'Success' (2).

   o  Informational RESPONSE: Messages carrying NATFW_INFO with error
      class 'Informational' (1) (only used with NOTIFY messages).

   o  Error RESPONSE: Messages carrying NATFW_INFO with error class
      other than 'Success' or 'Informational'.

3.2.8.  NATFW NSLP Signaling Sessions

   A NATFW NSLP signaling session defines an association between the NI,
   NFs, and the NR related to a data flow.  This association is created
   when the initial CREATE or EXTERNAL message is successfully received
   at the NFs or the NR.  There is signaling NATFW NSLP session state
   stored at the NTLP layer and at the NATFW NSLP level.  The NATFW NSLP
   signaling session state for the NATFW NSLP comprises NSLP state and
   the associated policy rules at a middlebox.

   The NATFW NSLP signaling session is identified by the session ID
   (plus other information at the NTLP level).  The session ID is
   generated by the NI before the initial CREATE or EXTERNAL message is
   sent.  The value of the session ID MUST be generated as a
   cryptographically random number (see [RFC4086]) by the NI, i.e., the
   output MUST NOT be easily guessable by third parties.  The session ID
   is not stored in any NATFW NSLP message but passed on to the NTLP.

   A NATFW NSLP signaling session has several conceptual states that
   describe in what state a signaling session is at a given time.  The
   signaling session can have these states at a node:

   o  Pending: The NATFW NSLP signaling session has been created and the
      node is waiting for a RESPONSE message to the CREATE or EXTERNAL
      message.  A NATFW NSLP signaling session in state 'Pending' MUST
      be marked as 'Dead' if no corresponding RESPONSE message has been
      received within the time of the locally granted NATFW NSLP
      signaling session lifetime of the forwarded CREATE or EXTERNAL
      message (as described in Section 3.4).

   o  Established: The NATFW NSLP signaling session is established, i.e,
      the signaling has been successfully performed and the lifetime of
      NATFW NSLP signaling session is counted from now on.  A NATFW NSLP
      signaling session in state 'Established' MUST be marked as 'Dead'
      if no refresh message has been received within the time of the
      locally granted NATFW NSLP signaling session lifetime of the
      RESPONSE message (as described in Section 3.4).

Top      Up      ToC       Page 27 
   o  Dead: Either the NATFW NSLP signaling session is timed out or the
      node has received an error RESPONSE message for the NATFW NSLP
      signaling session and the NATFW NSLP signaling session can be
      deleted.

   o  Transitory: The node has received an asynchronous message, i.e., a
      NOTIFY, and can delete the NATFW NSLP signaling session if needed
      after some time.  When a node has received a NOTIFY message, it
      marks the signaling session as 'Transitory'.  This signaling
      session SHOULD NOT be deleted before a minimum hold time of 30
      seconds, i.e., it can be removed after 30 seconds or more.  This
      hold time ensures that the existing signaling session can be
      reused by the NI, e.g., a part of a signaling session that is not
      affected by the route change can be reused once the updating
      request message is received.

3.3.  Basic Message Processing

   All NATFW messages are subject to some basic message processing when
   received at a node, independent of the message type.  Initially, the
   syntax of the NSLP message is checked and a RESPONSE message with an
   appropriate error of class 'Protocol error' (3) code is generated if
   a non-recoverable syntax error is detected.  A recoverable error is,
   for instance, when a node receives a message with reserved flags set
   to values other than zero.  This also refers to unknown NSLP objects
   and their handling, according to Section 4.2.  If a message is
   delivered to the NATFW NSLP, this implies that the NTLP layer has
   been able to correlate it with the session ID (SID) and MRI entries
   in its database.  There is therefore enough information to identify
   the source of the message and routing information to route the
   message back to the NI through an established chain of NTLP messaging
   associations.  The message is not further forwarded if any error in
   the syntax is detected.  The specific response codes stemming from
   the processing of objects are described in the respective object
   definition section (see Section 4).  After passing this check, the
   NATFW NSLP node performs authentication- and authorization-related
   checks, described in Section 3.6.  Further processing is executed
   only if these tests have been successfully passed; otherwise, the
   processing stops and an error RESPONSE is returned.

   Further message processing stops whenever an error RESPONSE message
   is generated, and the EXTERNAL or CREATE message is discarded.

3.4.  Calculation of Signaling Session Lifetime

   NATFW NSLP signaling sessions, and the corresponding policy rules
   that may have been installed, are maintained via a soft-state
   mechanism.  Each signaling session is assigned a signaling session

Top      Up      ToC       Page 28 
   lifetime and the signaling session is kept alive as long as the
   lifetime is valid.  After the expiration of the signaling session
   lifetime, signaling sessions and policy rules MUST be removed
   automatically and resources bound to them MUST be freed as well.
   Signaling session lifetime is handled at every NATFW NSLP node.  The
   NSLP forwarders and NSLP responder MUST NOT trigger signaling session
   lifetime extension refresh messages (see Section 3.7.3): this is the
   task of the NSIS initiator.

   The NSIS initiator MUST choose a NATFW NSLP signaling session
   lifetime value (expressed in seconds) before sending any message,
   including the initial message that creates the NATFW NSLP signaling
   session, to other NSLP nodes.  It is RECOMMENDED that the NATFW NSLP
   signaling session lifetime value is calculated based on:

   o  the number of lost refresh messages with which NFs should cope;

   o  the end-to-end delay between the NI and NR;

   o  network vulnerability due to NATFW NSLP signaling session
      hijacking ([RFC4081]), NATFW NSLP signaling session hijacking is
      made easier when the NI does not explicitly remove the NATFW NSLP
      signaling session;

   o  the user application's data exchange duration, in terms of time
      and networking needs.  This duration is modeled as R, with R the
      message refresh period (in seconds);

   o  the load on the signaling plane.  Short lifetimes imply more
      frequent signaling messages;

   o  the acceptable time for a NATFW NSLP signaling session to be
      present after it is no longer actually needed.  For example, if
      the existence of the NATFW NSLP signaling session implies a
      monetary cost and teardown cannot be guaranteed, shorter lifetimes
      would be preferable;

   o  the lease time of the NI's IP address.  The lease time of the IP
      address must be longer than the chosen NATFW NSLP signaling
      session lifetime; otherwise, the IP address can be re-assigned to
      a different node.  This node may receive unwanted traffic,
      although it never has requested a NAT/firewall configuration,
      which might be an issue in environments with mobile hosts.

   The RSVP specification [RFC2205] provides an appropriate algorithm
   for calculating the NATFW NSLP signaling session lifetime as well as
   a means to avoid refresh message synchronization between NATFW NSLP
   signaling sessions.  [RFC2205] recommends:

Top      Up      ToC       Page 29 
   1.  The refresh message timer to be randomly set to a value in the
       range [0.5R, 1.5R].

   2.  To avoid premature loss of state, lt (with lt being the NATFW
       NSLP signaling session lifetime) must satisfy lt >= (K +
       0.5)*1.5*R, where K is a small integer.  Then, in the worst case,
       K-1 successive messages may be lost without state being deleted.
       Currently, K = 3 is suggested as the default.  However, it may be
       necessary to set a larger K value for hops with high loss rate.
       Other algorithms could be used to define the relation between the
       NATFW NSLP signaling session lifetime and the refresh message
       period; the algorithm provided is only given as an example.

   It is RECOMMENDED to use a refresh timer of 300 s (5 minutes), unless
   the NI or the requesting application at the NI has other requirements
   (e.g., flows lasting a very short time).

   This requested NATFW NSLP signaling session lifetime value lt is
   stored in the NATFW_LT object of the NSLP message.

   NSLP forwarders and the NSLP responder can execute the following
   behavior with respect to the requested lifetime handling:

   Requested signaling session lifetime acceptable:

      No changes to the NATFW NSLP signaling session lifetime values are
      needed.  The CREATE or EXTERNAL message is forwarded, if
      applicable.


   Signaling session lifetime can be lowered:

      An NSLP forwarded or the NSLP responder MAY also lower the
      requested NATFW NSLP signaling session lifetime to an acceptable
      value (based on its local policies).  If an NF changes the NATFW
      NSLP signaling session lifetime value, it MUST store the new value
      in the NATFW_LT object.  The CREATE or EXTERNAL message is
      forwarded.


   Requested signaling session lifetime is too big:

      An NSLP forwarded or the NSLP responder MAY reject the requested
      NATFW NSLP signaling session lifetime value as being too big and
      MUST generate an error RESPONSE message of class 'Signaling
      session failure' (7) with response code 'Requested lifetime is too
      big' (0x02) upon rejection.  Lowering the lifetime is preferred
      instead of generating an error message.

Top      Up      ToC       Page 30 
   Requested signaling session lifetime is too small:

      An NSLP forwarded or the NSLP responder MAY reject the requested
      NATFW NSLP signaling session lifetime value as being to small and
      MUST generate an error RESPONSE message of class 'Signaling
      session failure' (7) with response code 'Requested lifetime is too
      small' (0x10) upon rejection.

   NFs or the NR MUST NOT increase the NATFW NSLP signaling session
   lifetime value.  Messages can be rejected on the basis of the NATFW
   NSLP signaling session lifetime being too long when a NATFW NSLP
   signaling session is first created and also on refreshes.

   The NSLP responder generates a successful RESPONSE for the received
   CREATE or EXTERNAL message, sets the NATFW NSLP signaling session
   lifetime value in the NATFW_LT object to the above granted lifetime
   and sends the message back towards NSLP initiator.

   Each NSLP forwarder processes the RESPONSE message and reads and
   stores the granted NATFW NSLP signaling session lifetime value.  The
   forwarders MUST accept the granted NATFW NSLP signaling session
   lifetime, if the lifetime value is within the acceptable range.  The
   acceptable value refers to the value accepted by the NSLP forwarder
   when processing the CREATE or EXTERNAL message.  For received values
   greater than the acceptable value, NSLP forwarders MUST generate a
   RESPONSE message of class 'Signaling session failure' (7) with
   response code 'Modified lifetime is too big' (0x11), including a
   Signaling Session Lifetime object that carries the maximum acceptable
   signaling session lifetime for this node.  For received values lower
   than the values acceptable by the node local policy, NSLP forwarders
   MUST generate a RESPONSE message of class 'Signaling session failure'
   (7) with response code 'Modified lifetime is too small' (0x12),
   including a Signaling Session Lifetime object that carries the
   minimum acceptable signaling session lifetime for this node.  In both
   cases, either 'Modified lifetime is too big' (0x11) or 'Modified
   lifetime is too small' (0x12), the NF MUST generate a NOTIFY message
   and send it outbound with the error class set to 'Informational' (1)
   and with the response code set to 'NATFW signaling session
   terminated' (0x05).

   Figure 13 shows the procedure with an example, where an initiator
   requests 60 seconds lifetime in the CREATE message and the lifetime
   is shortened along the path by the forwarder to 20 seconds and by the
   responder to 15 seconds.  When the NSLP forwarder receives the
   RESPONSE message with a NATFW NSLP signaling session lifetime value
   of 15 seconds it checks whether this value is lower or equal to the
   acceptable value.

Top      Up      ToC       Page 31 
   +-------+ CREATE(lt=60s)  +-------------+ CREATE(lt=20s)  +--------+
   |       |---------------->|     NSLP    |---------------->|        |
   |  NI   |                 |  forwarder  |                 |  NR    |
   |       |<----------------| check 15<20 |<----------------|        |
   +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+

      lt  = lifetime

           Figure 13: Signaling Session Lifetime Setting Example



(page 31 continued on part 3)

Next RFC Part