tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5973

 
 
 

NAT/Firewall NSIS Signaling Layer Protocol (NSLP)

Part 3 of 5, p. 31 to 55
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 31 
3.5.  Message Sequencing

   NATFW NSLP messages need to carry an identifier so that all nodes
   along the path can distinguish messages sent at different points in
   time.  Messages can be lost along the path or duplicated.  So, all
   NATFW NSLP nodes should be able to identify messages that have been
   received before (duplicated) or lost before (loss).  For message
   replay protection, it is necessary to keep information about messages
   that have already been received and requires every NATFW NSLP message
   to carry a message sequence number (MSN), see also Section 4.2.7.

   The MSN MUST be set by the NI and MUST NOT be set or modified by any
   other node.  The initial value for the MSN MUST be generated randomly
   and MUST be unique only within the NATFW NSLP signaling session for
   which it is used.  The NI MUST increment the MSN by one for every
   message sent.  Once the MSN has reached the maximum value, the next
   value it takes is zero.  All NATFW NSLP nodes MUST use the algorithm
   defined in [RFC1982] to detect MSN wrap-arounds.

   NSLP forwarders and the responder store the MSN from the initial
   CREATE or EXTERNAL packet that creates the NATFW NSLP signaling
   session as the start value for the NATFW NSLP signaling session.  NFs
   and NRs MUST include the received MSN value in the corresponding
   RESPONSE message that they generate.

   When receiving a CREATE or EXTERNAL message, a NATFW NSLP node uses
   the MSN given in the message to determine whether the state being
   requested is different from the state already installed.  The message
   MUST be discarded if the received MSN value is equal to or lower than
   the stored MSN value.  Such a received MSN value can indicate a
   duplicated and delayed message or replayed message.  If the received
   MSN value is greater than the already stored MSN value, the NATFW
   NSLP MUST update its stored state accordingly, if permitted by all
   security checks (see Section 3.6), and store the updated MSN value
   accordingly.

Top      Up      ToC       Page 32 
3.6.  Authentication, Authorization, and Policy Decisions

   NATFW NSLP nodes receiving signaling messages MUST first check
   whether this message is authenticated and authorized to perform the
   requested action.  NATFW NSLP nodes requiring more information than
   provided MUST generate an error RESPONSE of class 'Permanent failure'
   (0x5) with response code 'Authentication failed' (0x01) or with
   response code 'Authorization failed' (0x02).

   The NATFW NSLP is expected to run in various environments, such as
   IP-based telephone systems, enterprise networks, home networks, etc.
   The requirements on authentication and authorization are quite
   different between these use cases.  While a home gateway, or an
   Internet cafe, using NSIS may well be happy with a "NATFW signaling
   coming from inside the network" policy for authorization of
   signaling, enterprise networks are likely to require more strongly
   authenticated/authorized signaling.  This enterprise scenario may
   require the use of an infrastructure and administratively assigned
   identities to operate the NATFW NSLP.

   Once the NI is authenticated and authorized, another step is
   performed.  The requested policy rule for the NATFW NSLP signaling
   session is checked against a set of policy rules, i.e., whether the
   requesting NI is allowed to request the policy rule to be loaded in
   the device.  If this fails, the NF or NR must send an error RESPONSE
   of class 'Permanent failure' (5) and with response code
   'Authorization failed' (0x02).

3.7.  Protocol Operations

   This section defines the protocol operations including how to create
   NATFW NSLP signaling sessions, maintain them, delete them, and how to
   reserve addresses.

   This section requires a good knowledge of the NTLP [RFC5971] and the
   message routing method mechanism and the associated message routing
   information (MRI).  The NATFW NSLP uses information from the MRI,
   e.g., the destination and source ports, and the NATFW NSLP to
   construct the policy rules used on the NATFW NSLP level.  See also
   Appendix D for further information about this.

3.7.1.  Creating Signaling Sessions

   Allowing two hosts to exchange data even in the presence of
   middleboxes is realized in the NATFW NSLP by the use of the CREATE
   message.  The NI (either the data sender or a proxy) generates a
   CREATE message as defined in Section 4.3.1 and hands it to the NTLP.
   The NTLP forwards the whole message on the basis of the message

Top      Up      ToC       Page 33 
   routing information (MRI) towards the NR.  Each NSLP forwarder along
   the path that implements NATFW NSLP processes the NSLP message.
   Forwarding is done hop-by-hop but may pass transparently through NSLP
   forwarders that do not contain NATFW NSLP functionality and non-NSIS-
   aware routers between NSLP hop way points.  When the message reaches
   the NR, the NR can accept the request or reject it.  The NR generates
   a response to CREATE and this response is transported hop-by-hop
   towards the NI.  NATFW NSLP forwarders may reject requests at any
   time.  Figure 14 sketches the message flow between the NI (DS in this
   example), an NF (e.g., NAT), and an NR (DR in this example).

       NI      Private Network        NF    Public Internet        NR
       |                              |                            |
       | CREATE                       |                            |
       |----------------------------->|                            |
       |                              |                            |
       |                              |                            |
       |                              | CREATE                     |
       |                              |--------------------------->|
       |                              |                            |
       |                              | RESPONSE                   |
       |    RESPONSE                  |<---------------------------|
       |<-----------------------------|                            |
       |                              |                            |
       |                              |                            |

           Figure 14: CREATE Message Flow with Success RESPONSE

   There are several processing rules for a NATFW peer when generating
   and receiving CREATE messages, since this message type is used for
   creating new NATFW NSLP signaling sessions, updating existing ones,
   and extending the lifetime and deleting NATFW NSLP signaling
   sessions.  The three latter functions operate in the same way for all
   kinds of CREATE messages, and are therefore described in separate
   sections:

   o  Extending the lifetime of NATFW NSLP signaling sessions is
      described in Section 3.7.3.

   o  Deleting NATFW NSLP signaling sessions is described in
      Section 3.7.4.

   o  Updating policy rules is described in Section 3.10.

   For an initial CREATE message creating a new NATFW NSLP signaling
   session, the processing of CREATE messages is different for every
   NATFW node type:

Top      Up      ToC       Page 34 
   o  NSLP initiator: An NI only generates CREATE messages and hands
      them over to the NTLP.  The NI should never receive CREATE
      messages and MUST discard them.

   o  NATFW NSLP forwarder: NFs that are unable to forward the CREATE
      message to the next hop MUST generate an error RESPONSE of class
      'Permanent failure' (5) with response code 'Did not reach the NR'
      (0x07).  This case may occur if the NTLP layer cannot find a NATFW
      NSLP peer, either another NF or the NR, and returns an error via
      the GIST API (a timeout error reported by GIST).  The NSLP message
      processing at the NFs depends on the middlebox type:

      *  NAT: When the initial CREATE message is received at the public
         side of the NAT, it looks for a reservation made in advance, by
         using an EXTERNAL message (see Section 3.7.2).  The matching
         process considers the received MRI information and the stored
         MRI information, as described in Section 3.8.  If no matching
         reservation can be found, i.e., no reservation has been made in
         advance, the NSLP MUST return an error RESPONSE of class
         'Signaling session failure' (7) with response code 'No
         reservation found matching the MRI of the CREATE request'
         (0x03).  If there is a matching reservation, the NSLP stores
         the data sender's address (and if applicable port number) as
         part of the source IP address of the policy rule ('the
         remembered policy rule') to be loaded, and forwards the message
         with the destination IP address set to the internal (private in
         most cases) address of the NR.  When the initial CREATE message
         is received at the private side, the NAT binding is allocated,
         but not activated (see also Appendix D.3).  An error RESPONSE
         message is generated, if the requested policy rule cannot be
         reserved right away, of class 'Signaling session failure' (7)
         with response code 'Requested policy rule denied due to policy
         conflict' (0x4).  The MRI information is updated to reflect the
         address, and if applicable port, translation.  The NSLP message
         is forwarded towards the NR with source IP address set to the
         NAT's external address from the newly remembered binding.

      *  Firewall: When the initial CREATE message is received, the NSLP
         just remembers the requested policy rule, but does not install
         any policy rule.  Afterwards, the message is forwarded towards
         the NR.  If the requested policy rule cannot be reserved right
         away, an error RESPONSE message is generated, of class
         'Signaling session failure' (7) with response code 'Requested
         policy rule denied due to policy conflict' (0x4).

      *  Combined NAT and firewall: Processing at combined firewall and
         NAT middleboxes is the same as in the NAT case.  No policy
         rules are installed.  Implementations MUST take into account

Top      Up      ToC       Page 35 
         the order of packet processing in the firewall and NAT
         functions within the device.  This will be referred to as
         "order of functions" and is generally different depending on
         whether the packet arrives at the external or internal side of
         the middlebox.

   o  NSLP receiver: NRs receiving initial CREATE messages MUST reply
      with a success RESPONSE of class 'Success' (2) with response code
      set to 'All successfully processed' (0x01), if they accept the
      CREATE message.  Otherwise, they MUST generate a RESPONSE message
      with a suitable response code.  RESPONSE messages are sent back
      NSLP hop-by-hop towards the NI, irrespective of the response
      codes, either success or error.

   Remembered policy rules at middleboxes MUST be only installed upon
   receiving a corresponding successful RESPONSE message with the same
   SID as the CREATE message that caused them to be remembered.  This is
   a countermeasure to several problems, for example, wastage of
   resources due to loading policy rules at intermediate NFs when the
   CREATE message does not reach the final NR for some reason.

   Processing of a RESPONSE message is different for every NSIS node
   type:

   o  NSLP initiator: After receiving a successful RESPONSE, the data
      path is configured and the DS can start sending its data to the
      DR.  After receiving an error RESPONSE message, the NI MAY try to
      generate the CREATE message again or give up and report the
      failure to the application, depending on the error condition.

   o  NSLP forwarder: NFs install the remembered policy rules, if a
      successful RESPONSE message with matching SID is received.  If an
      ERROR RESPONSE message with matching SID is received, the NATFW
      NSLP session is marked as 'Dead', no policy rule is installed and
      the remembered rule is discarded.

   o  NSIS responder: The NR should never receive RESPONSE messages and
      MUST silently drop any such messages received.

   NFs and the NR can also tear down the CREATE session at any time by
   generating a NOTIFY message with the appropriate response code set.

3.7.2.  Reserving External Addresses

   NSIS signaling is intended to travel end-to-end, even in the presence
   of NATs and firewalls on-path.  This works well in cases where the
   data sender is itself behind a NAT or a firewall as described in
   Section 3.7.1.  For scenarios where the data receiver is located

Top      Up      ToC       Page 36 
   behind a NAT or a firewall and it needs to receive data flows from
   outside its own network (usually referred to as inbound flows, see
   Figure 5), the problem is more troublesome.

   NSIS signaling, as well as subsequent data flows, are directed to a
   particular destination IP address that must be known in advance and
   reachable.  Data receivers must tell the local NSIS infrastructure
   (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP
   signaling and data flows before they can receive these flows.  It is
   necessary to differentiate between data receivers behind NATs and
   behind firewalls to understand the further NATFW procedures.  Data
   receivers that are only behind firewalls already have a public IP
   address and they need only to be reachable for NATFW signaling.
   Unlike data receivers that are only behind firewalls, data receivers
   behind NATs do not have public IP addresses; consequently, they are
   not reachable for NATFW signaling by entities outside their
   addressing realm.

   The preceding discussion addresses the situation where a DR node that
   wants to be reachable is unreachable because the NAT lacks a suitable
   rule with the 'allow' action that would forward inbound data.
   However, in certain scenarios, a node situated behind inbound
   firewalls that do not block inbound data traffic (firewalls with
   "default to allow") unless requested might wish to prevent traffic
   being sent to it from specified addresses.  In this case, NSIS NATFW
   signaling can be used to achieve this by installing a policy rule
   with its action set to 'deny' using the same mechanisms as for
   'allow' rules.

   The required result is obtained by sending an EXTERNAL message in the
   inbound direction of the intended data flow.  When using this
   functionality, the NSIS initiator for the 'Reserve External Address'
   signaling is typically the node that will become the DR for the
   eventual data flow.  To distinguish this initiator from the usual
   case where the NI is associated with the DS, the NI is denoted by NI+
   and the NSIS responder is similarly denoted by NR+.

Top      Up      ToC       Page 37 
       Public Internet                Private Address
                                           Space

                    Edge
    NI(DS)         NAT/FW                  NAT                   NR(DR)
    NR+                                                          NI+

    |               |                       |                       |
    |               |                       |                       |
    |               |                       |                       |
    |               |  EXTERNAL[(DTInfo)]   |  EXTERNAL[(DTInfo)]   |
    |               |<----------------------|<----------------------|
    |               |                       |                       |
    |               |RESPONSE[Success/Error]|RESPONSE[Success/Error]|
    |               |---------------------->|---------------------->|
    |               |                       |                       |
    |               |                       |                       |

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

     Figure 15: Reservation Message Flow for DR behind NAT or Firewall

   Figure 15 shows the EXTERNAL message flow for enabling inbound NATFW
   NSLP signaling messages.  In this case, the roles of the different
   NSIS entities are:

   o  The data receiver (DR) for the anticipated data traffic is the
      NSIS initiator (NI+) for the EXTERNAL message, but becomes the
      NSIS responder (NR) for following CREATE messages.

   o  The actual data sender (DS) will be the NSIS initiator (NI) for
      later CREATE messages and may be the NSIS target of the signaling
      (NR+).

   o  It may be necessary to use a signaling destination address (SDA)
      as the actual target of the EXTERNAL message (NR+) if the DR is
      located behind a NAT and the address of the DS is unknown.  The
      SDA is an arbitrary address in the outermost address realm on the
      other side of the NAT from the DR.  Typically, this will be a
      suitable public IP address when the 'outside' realm is the public
      Internet.  This choice of address causes the EXTERNAL message to
      be routed through the NATs towards the outermost realm and would
      force interception of the message by the outermost NAT in the
      network at the boundary between the private address and the public
      address realm (the edge-NAT).  It may also be intercepted by other
      NATs and firewalls on the path to the edge-NAT.

Top      Up      ToC       Page 38 
   Basically, there are two different signaling scenarios.  Either

   1.  the DR behind the NAT/firewall knows the IP address of the DS in
       advance, or

   2.  the address of the DS is not known in advance.

   Case 1 requires the NATFW NSLP to request the path-coupled message
   routing method (PC-MRM) from the NTLP.  The EXTERNAL message MUST be
   sent with PC-MRM (see Section 5.8.1 in [RFC5971]) with the direction
   set to 'upstream' (inbound).  The handling of case 2 depends on the
   situation of the DR: if the DR is solely located behind a firewall,
   the EXTERNAL message MUST be sent with the PC-MRM, direction
   'upstream' (inbound), and the data flow source IP address set to
   'wildcard'.  If the DR is located behind a NAT, the EXTERNAL message
   MUST be sent with the loose-end message routing method (LE-MRM, see
   Section 5.8.2 in [RFC5971]), the destination-address set to the
   signaling destination IP address (SDA, see also Appendix A).  For
   scenarios with the DR behind a firewall, special conditions apply
   (see applicability statement in Appendix C).  The data receiver is
   challenged to determine whether it is solely located behind firewalls
   or NATs in order to choose the right message routing method.  This
   decision can depend on a local configuration parameter, possibly
   given through DHCP, or it could be discovered through other non-NSLP
   related testing of the network configuration.  The use of the PC-MRM
   with the known data sender's IP address is RECOMMENDED.  This gives
   GIST the best possible handle to route the message 'upstream'
   (outbound).  The use of the LE-MRM, if and only if the data sender's
   IP address is not known and the data receiver is behind a NAT, is
   RECOMMENDED.

   For case 2 with NAT, the NI+ (which could be on the data receiver DR
   or on any other host within the private network) sends the EXTERNAL
   message targeted to the signaling destination IP address.  The
   message routing for the EXTERNAL message is in the reverse direction
   of the normal message routing used for path-coupled signaling where
   the signaling is sent outbound (as opposed to inbound in this case).
   When establishing NAT bindings (and a NATFW NSLP signaling session),
   the signaling direction does not matter since the data path is
   modified through route pinning due to the external IP address at the
   NAT.  Subsequent NSIS messages (and also data traffic) will travel
   through the same NAT boxes.  However, this is only valid for the NAT
   boxes, but not for any intermediate firewall.  That is the reason for
   having a separate CREATE message enabling the reservations made with
   EXTERNAL at the NATs and either enabling prior reservations or
   creating new pinholes at the firewalls that are encountered on the
   outbound path depending on whether the inbound and outbound routes
   coincide.

Top      Up      ToC       Page 39 
   The EXTERNAL signaling message creates an NSIS NATFW signaling
   session at any intermediate NSIS NATFW peer(s) encountered,
   independent of the message routing method used.  Furthermore, it has
   to be ensured that the edge-NAT or edge-firewall device is discovered
   as part of this process.  The end host cannot be assumed to know this
   device -- instead the NAT or firewall box itself is assumed to know
   that it is located at the outer perimeter of the network.  Forwarding
   of the EXTERNAL message beyond this entity is not necessary, and MUST
   be prohibited as it may provide information on the capabilities of
   internal hosts.  It should be noted, that it is the outermost NAT or
   firewall that is the edge-device that must be found during this
   discovery process.  For instance, when there are a NAT and
   (afterwards) a firewall on the outbound path at the network border,
   the firewall is the edge-firewall.  All messages must be forwarded to
   the topology-wise outermost edge-device to ensure that this device
   knows about the NATFW NSLP signaling sessions for incoming CREATE
   messages.  However, the NAT is still the edge-NAT because it has a
   public globally routable IP address on its public side: this is not
   affected by any firewall between the edge-NAT and the public network.

   Possible edge arrangements are:

          Public Net   -----------------  Private net  --------------

        | Public Net|--|Edge-FW|--|FW|...|FW|--|DR|

        | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR|

        | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR|

   The edge-NAT or edge-firewall device closest to the public realm
   responds to the EXTERNAL request message with a successful RESPONSE
   message.  An edge-NAT includes a NATFW_EXTERNAL_IP object (see
   Section 4.2.2), carrying the publicly reachable IP address, and if
   applicable, a port number.

   The NI+ can request each intermediate NAT (i.e., a NAT that is not
   the edge-NAT) to include the external binding address (and if
   applicable port number) in the external binding address object.  The
   external binding address object stores the external IP address (and
   port) at the particular NAT.  The NI+ has to include the external
   binding address (see Section 4.2.3) object in the request message, if
   it wishes to obtain the information.

   There are several processing rules for a NATFW peer when generating
   and receiving EXTERNAL messages, since this message type is used for
   creating new reserve NATFW NSLP signaling sessions, updating
   existing, extending the lifetime, and deleting NATFW NSLP signaling

Top      Up      ToC       Page 40 
   session.  The three latter functions operate in the same way for all
   kinds of CREATE and EXTERNAL messages, and are therefore described in
   separate sections:

   o  Extending the lifetime of NATFW NSLP signaling sessions is
      described in Section 3.7.3.

   o  Deleting NATFW NSLP signaling sessions is described in
      Section 3.7.4.

   o  Updating policy rules is described in Section 3.10.

   The NI+ MUST always include a NATFW_DTINFO object in the EXTERNAL
   message.  Especially, the LE-MRM does not include enough information
   for some types of NATs (basically, those NATs that also translate
   port numbers) to perform the address translation.  This information
   is provided in the NATFW_DTINFO (see Section 4.2.8).  This
   information MUST include at least the 'dst port number' and
   'protocol' fields, in the NATFW_DTINFO object as these may be
   required by NATs that are en route, depending on the type of the NAT.
   All other fields MAY be set by the NI+ to restrict the set of
   possible NIs.  An edge-NAT will use the information provided in the
   NATFW_DTINFO object to allow only a NATFW CREATE message with a
   matching MRI to be forwarded.  The MRI of the NATFW CREATE message
   has to use the parameters set in NATFW_DTINFO object ('src IPv4/v6
   address', 'src port number', 'protocol') as the source IP address/
   port of the flow from DS to DR.  A NAT requiring information carried
   in the NATFW_DTINFO can generate a number of error RESPONSE messages
   of class 'Signaling session failure' (7):

   o  'Requested policy rule denied due to policy conflict' (0x04)

   o  'Unknown policy rule action' (0x05)

   o  'Requested rule action not applicable' (0x06)

   o  'NATFW_DTINFO object is required' (0x07)

   o  'Requested value in sub_ports field in NATFW_EFI not permitted'
      (0x08)

   o  'Requested IP protocol not supported' (0x09)

   o  'Plain IP policy rules not permitted -- need transport layer
      information' (0x0A)

   o  'Source IP address range is too large' (0x0C)

Top      Up      ToC       Page 41 
   o  'Destination IP address range is too large' (0x0D)

   o  'Source L4-port range is too large' (0x0E)

   o  'Destination L4-port range is too large' (0x0F)

   Processing of EXTERNAL messages is specific to the NSIS node type:

   o  NSLP initiator: NI+ only generate EXTERNAL messages.  When the
      data sender's address information is known in advance, the NI+ can
      include a NATFW_DTINFO object in the EXTERNAL message, if not
      anyway required to do so (see above).  When the data sender's IP
      address is not known, the NI+ MUST NOT include an IP address in
      the NATFW_DTINFO object.  The NI should never receive EXTERNAL
      messages and MUST silently discard it.

   o  NSLP forwarder: The NSLP message processing at NFs depends on the
      middlebox type:

      *  NAT: NATs check whether the message is received at the external
         (public in most cases) address or at the internal (private)
         address.  If received at the external address, an NF MUST
         generate an error RESPONSE of class 'Protocol error' (3) with
         response code 'Received EXTERNAL request message on external
         side' (0x0B).  If received at the internal (private address)
         and the NATFW_EFI object contains the action 'deny', an error
         RESPONSE of class 'Protocol error' (3) with response code
         'Requested rule action not applicable' (0x06) MUST be
         generated.  If received at the internal address, an IP address,
         and if applicable, one or more ports, are reserved.  If the
         NATFW_EXTERNAL_BINDING object is present in the message, any
         NAT that is not an edge-NAT MUST include the allocated external
         IP address, and if applicable one or more ports, (the external
         binding address) in the NATFW_EXTERNAL_BINDING object.  If it
         is an edge-NAT and there is no edge-firewall beyond, the NSLP
         message is not forwarded any further and a successful RESPONSE
         message is generated containing a NATFW_EXTERNAL_IP object
         holding the translated address, and if applicable, port
         information from the binding reserved as a result of the
         EXTERNAL message.  The edge-NAT MUST copy the
         NATFW_EXTERNAL_BINDING object to response message, if the
         object is included in the EXTERNAL message.  The RESPONSE
         message is sent back towards the NI+.  If it is not an edge-
         NAT, the NSLP message is forwarded further using the translated
         IP address as signaling source IP address in the LE-MRM and
         translated port in the NATFW_DTINFO object in the field 'DR
         port number', i.e., the NATFW_DTINFO object is updated to
         reflect the translated port number.  The edge-NAT or any other

Top      Up      ToC       Page 42 
         NAT MUST reject EXTERNAL messages not carrying a NATFW_DTINFO
         object or if the address information within this object is
         invalid or is not compliant with local policies (e.g., the
         information provided relates to a range of addresses
         ('wildcarded') but the edge-NAT requires exact information
         about DS's IP address and port) with the above mentioned
         response codes.

      *  Firewall: Non edge-firewalls remember the requested policy
         rule, keep NATFW NSLP signaling session state, and forward the
         message.  Edge-firewalls stop forwarding the EXTERNAL message.
         The policy rule is immediately loaded if the action in the
         NATFW_EFI object is set to 'deny' and the node is an edge-
         firewall.  The policy rule is remembered, but not activated, if
         the action in the NATFW_EFI object is set to 'allow'.  In both
         cases, a successful RESPONSE message is generated.  If the
         action is 'allow', and the NATFW_DTINFO object is included, and
         the MRM is set to LE-MRM in the request, additionally a
         NATFW_EXTERNAL_IP object is included in the RESPONSE message,
         holding the translated address, and if applicable port,
         information.  This information is obtained from the
         NATFW_DTINFO object's 'DR port number' and the source-address
         of the LE-MRM.  The edge-firewall MUST copy the
         NATFW_EXTERNAL_BINDING object to response message, if the
         object is included in the EXTERNAL message.

      *  Combined NAT and firewall: Processing at combined firewall and
         NAT middleboxes is the same as in the NAT case.

   o  NSLP receiver: This type of message should never be received by
      any NR+, and it MUST generate an error RESPONSE message of class
      'Permanent failure' (5) with response code 'No edge-device here'
      (0x06).

   Processing of a RESPONSE message is different for every NSIS node
   type:

   o  NSLP initiator: Upon receiving a successful RESPONSE message, the
      NI+ can rely on the requested configuration for future inbound
      NATFW NSLP signaling sessions.  If the response contains a
      NATFW_EXTERNAL_IP object, the NI can use IP address and port pairs
      carried for further application signaling.  After receiving an
      error RESPONSE message, the NI+ MAY try to generate the EXTERNAL
      message again or give up and report the failure to the
      application, depending on the error condition.

Top      Up      ToC       Page 43 
   o  NSLP forwarder: NFs simply forward this message as long as they
      keep state for the requested reservation, if the RESPONSE message
      contains NATFW_INFO object with class set to 'Success' (2).  If
      the RESPONSE message contains NATFW_INFO object with class set not
      to 'Success' (2), the NATFW NSLP signaling session is marked as
      'Dead'.

   o  NSIS responder: This type of message should never be received by
      any NR+.  The NF should never receive response messages and MUST
      silently discard it.

   NFs and the NR can also tear down the EXTERNAL session at any time by
   generating a NOTIFY message with the appropriate response code set.

   Reservations with action 'allow' made with EXTERNAL MUST be enabled
   by a subsequent CREATE message.  A reservation made with EXTERNAL
   (independent of selected action) is kept alive as long as the NI+
   refreshes the particular NATFW NSLP signaling session and it can be
   reused for multiple, different CREATE messages.  An NI+ may decide to
   tear down a reservation immediately after receiving a CREATE message.
   This implies that a new NATFW NSLP signaling session must be created
   for each new CREATE message.  The CREATE message does not re-use the
   NATFW NSLP signaling session created by EXTERNAL.

   Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode
   (see Section 3.7.6) no data traffic will be forwarded to the DR
   beyond the edge-NAT or edge-firewall.  The only function of EXTERNAL
   is to ensure that subsequent CREATE messages traveling towards the NR
   will be forwarded across the public-private boundary towards the DR.
   Correlation of incoming CREATE messages to EXTERNAL reservation
   states is described in Section 3.8.

3.7.3.  NATFW NSLP Signaling Session Refresh

   NATFW NSLP signaling sessions are maintained on a soft-state basis.
   After a specified timeout, sessions and corresponding policy rules
   are removed automatically by the middlebox, if they are not
   refreshed.  Soft-state is created by CREATE and EXTERNAL and the
   maintenance of this state must be done by these messages.  State
   created by CREATE must be maintained by CREATE, state created by
   EXTERNAL must be maintained by EXTERNAL.  Refresh messages, are
   messages carrying the same session ID as the initial message and a
   NATFW_LT lifetime object with a lifetime greater than zero.  Messages
   with the same SID but which carry a different MRI are treated as
   updates of the policy rules and are processed as defined in
   Section 3.10.  Every refresh CREATE or EXTERNAL message MUST be
   acknowledged by an appropriate response message generated by the NR.
   Upon reception by each NSLP forwarder, the state for the given

Top      Up      ToC       Page 44 
   session ID is extended by the NATFW NSLP signaling session refresh
   period, a period of time calculated based on a proposed refresh
   message period.  The new (extended) lifetime of a NATFW NSLP
   signaling session is calculated as current local time plus proposed
   lifetime value (NATFW NSLP signaling session refresh period).
   Section 3.4 defines the process of calculating lifetimes in detail.

   NI      Public Internet        NAT    Private address       NR

      |                              |          space             |
      | CREATE[lifetime > 0]         |                            |

      |----------------------------->|                            |
      |                              |                            |
      |                              |                            |
      |                              |  CREATE[lifetime > 0]      |
      |                              |--------------------------->|
      |                              |                            |
      |                              |   RESPONSE[Success/Error]  |
      |   RESPONSE[Success/Error]    |<---------------------------|
      |<-----------------------------|                            |
      |                              |                            |
      |                              |                            |

       Figure 16: Successful Refresh Message Flow, CREATE as Example

   Processing of NATFW NSLP signaling session refresh CREATE and
   EXTERNAL messages is different for every NSIS node type:

   o  NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling
      session refresh CREATE/EXTERNAL messages before the NATFW NSLP
      signaling session times out.  The rate at which the refresh
      CREATE/EXTERNAL messages are sent and their relation to the NATFW
      NSLP signaling session state lifetime is discussed further in
      Section 3.4.

   o  NSLP forwarder: Processing of this message is independent of the
      middlebox type and is as described in Section 3.4.

   o  NSLP responder: NRs accepting a NATFW NSLP signaling session
      refresh CREATE/EXTERNAL message generate a successful RESPONSE
      message, including the granted lifetime value of Section 3.4 in a
      NATFW_LT object.

Top      Up      ToC       Page 45 
3.7.4.  Deleting Signaling Sessions

   NATFW NSLP signaling sessions can be deleted at any time.  NSLP
   initiators can trigger this deletion by using a CREATE or EXTERNAL
   messages with a lifetime value set to 0, as shown in Figure 17.
   Whether a CREATE or EXTERNAL message type is use depends on how the
   NATFW NSLP signaling session was created.

      NI      Public Internet        NAT    Private address       NR

      |                              |          space             |
      |    CREATE[lifetime=0]        |                            |
      |----------------------------->|                            |
      |                              |                            |
      |                              | CREATE[lifetime=0]         |
      |                              |--------------------------->|
      |                              |                            |

             Figure 17: Delete message flow, CREATE as Example

   NSLP nodes receiving this message delete the NATFW NSLP signaling
   session immediately.  Policy rules associated with this particular
   NATFW NSLP signaling session MUST be also deleted immediately.  This
   message is forwarded until it reaches the final NR.  The CREATE/
   EXTERNAL message with a lifetime value of 0, does not generate any
   response, either positive or negative, since there is no NSIS state
   left at the nodes along the path.

   NSIS initiators can use CREATE/EXTERNAL message with lifetime set to
   zero in an aggregated way, such that a single CREATE or EXTERNAL
   message is terminating multiple NATFW NSLP signaling sessions.  NIs
   can follow this procedure if they like to aggregate NATFW NSLP
   signaling session deletion requests: the NI uses the CREATE or
   EXTERNAL message with the session ID set to zero and the MRI's
   source-address set to its used IP address.  All other fields of the
   respective NATFW NSLP signaling sessions to be terminated are set as
   well; otherwise, these fields are completely wildcarded.  The NSLP
   message is transferred to the NTLP requesting 'explicit routing' as
   described in Sections 5.2.1 and 7.1.4. in [RFC5971].

   The outbound NF receiving such an aggregated CREATE or EXTERNAL
   message MUST reject it with an error RESPONSE of class 'Permanent
   failure' (5) with response code 'Authentication failed' (0x01) if the
   authentication fails and with an error RESPONSE of class 'Permanent
   failure' (5) with response code 'Authorization failed' (0x02) if the
   authorization fails.  Proof of ownership of NATFW NSLP signaling
   sessions, as it is defined in this memo (see Section 5.2.1), is not
   possible when using this aggregation for multiple session

Top      Up      ToC       Page 46 
   termination.  However, the outbound NF can use the relationship
   between the information of the received CREATE or EXTERNAL message
   and the GIST messaging association where the request has been
   received.  The outbound NF MUST only accept this aggregated CREATE or
   EXTERNAL message through already established GIST messaging
   associations with the NI.  The outbound NF MUST NOT propagate this
   aggregated CREATE or EXTERNAL message but it MAY generate and forward
   per NATFW NSLP signaling session CREATE or EXTERNAL messages.

3.7.5.  Reporting Asynchronous Events

   NATFW NSLP forwarders and NATFW NSLP responders must have the ability
   to report asynchronous events to other NATFW NSLP nodes, especially
   to allow reporting back to the NATFW NSLP initiator.  Such
   asynchronous events may be premature NATFW NSLP signaling session
   termination, changes in local policies, route change or any other
   reason that indicates change of the NATFW NSLP signaling session
   state.

   NFs and NRs may generate NOTIFY messages upon asynchronous events,
   with a NATFW_INFO object indicating the reason for event.  These
   reasons can be carried in the NATFW_INFO object (class MUST be set to
   'Informational' (1)) within the NOTIFY message.  This list shows the
   response codes and the associated actions to take at NFs and the NI:

   o  'Route change: Possible route change on the outbound path' (0x01):
      Follow instructions in Section 3.9.  This MUST be sent inbound and
      outbound, if the signaling session is any state except
      'Transitory'.  The NOTIFY message for signaling sessions in state
      Transitory MUST be discarded, as the signaling session is anyhow
      Transitory.  The outbound NOTIFY message MUST be sent with
      explicit routing by providing the SII-Handle to the NTLP.

   o  'Re-authentication required' (0x02): The NI should re-send the
      authentication.  This MUST be sent inbound.

   o  'NATFW node is going down soon' (0x03): The NI and other NFs
      should be prepared for a service interruption at any time.  This
      message MAY be sent inbound and outbound.

   o  'NATFW signaling session lifetime expired' (0x04): The NATFW
      signaling session has expired and the signaling session is invalid
      now.  NFs MUST mark the signaling session as 'Dead'.  This message
      MAY be sent inbound and outbound.

Top      Up      ToC       Page 47 
   o  'NATFW signaling session terminated' (0x05): The NATFW signaling
      session has been terminated for some reason and the signaling
      session is invalid now.  NFs MUST mark the signaling session as
      'Dead'.  This message MAY be sent inbound and outbound.

   NOTIFY messages are always sent hop-by-hop inbound towards NI until
   they reach NI or outbound towards the NR as indicated in the list
   above.

   The initial processing when receiving a NOTIFY message is the same
   for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages
   through already established NTLP messaging associations.  The further
   processing is different for each NATFW NSLP node type and depends on
   the events notified:

   o  NSLP initiator: NIs analyze the notified event and behave
      appropriately based on the event type.  NIs MUST NOT generate
      NOTIFY messages.

   o  NSLP forwarder: NFs analyze the notified event and behave based on
      the above description per response code.  NFs SHOULD generate
      NOTIFY messages upon asynchronous events and forward them inbound
      towards the NI or outbound towards the NR, depending on the
      received direction, i.e., inbound messages MUST be forwarded
      further inbound and outbound messages MUST be forwarded further
      outbound.  NFs MUST silently discard NOTIFY messages that have
      been received outbound but are only allowed to be sent inbound,
      e.g., 'Re-authentication required' (0x02).

   o  NSLP responder: NRs SHOULD generate NOTIFY messages upon
      asynchronous events including a response code based on the
      reported event.  The NR MUST silently discard NOTIFY messages that
      have been received outbound but are only allowed to be sent
      inbound, e.g., 'Re-authentication required' (0x02).

   NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions
   at the same time, can experience problems when shutting down service
   suddenly.  This sudden shutdown can be as a result of local node
   failure, for instance, due to a hardware failure.  This NF generates
   NOTIFY messages for each of the NATFW NSLP signaling sessions and
   tries to send them inbound.  Due to the number of NOTIFY messages to
   be sent, the shutdown of the node may be unnecessarily prolonged,
   since not all messages can be sent at the same time.  This case can
   be described as a NOTIFY storm, if a multitude of NATFW NSLP
   signaling sessions is involved.

Top      Up      ToC       Page 48 
   To avoid the need for generating per NATFW NSLP signaling session
   NOTIFY messages in such a scenario described or similar cases, NFs
   SHOULD follow this procedure: the NF uses the NOTIFY message with the
   session ID in the NTLP set to zero, with the MRI completely
   wildcarded, using the 'explicit routing' as described in Sections
   5.2.1 and 7.1.4 of [RFC5971].  The inbound NF receiving this type of
   NOTIFY immediately regards all NATFW NSLP signaling sessions from
   that peer matching the MRI as void.  This message will typically
   result in multiple NOTIFY messages at the inbound NF, i.e., the NF
   can generate per terminated NATFW NSLP signaling session a NOTIFY
   message.  However, an NF MAY also aggregate the NOTIFY messages as
   described here.

3.7.6.  Proxy Mode of Operation

   Some migration scenarios need specialized support to cope with cases
   where NSIS is only deployed in some areas of the Internet.  End-to-
   end signaling is going to fail without NSIS support at or near both
   data sender and data receiver terminals.  A proxy mode of operation
   is needed.  This proxy mode of operation must terminate the NATFW
   NSLP signaling topologically-wise as close as possible to the
   terminal for which it is proxying and proxy all messages.  This NATFW
   NSLP node doing the proxying of the signaling messages becomes either
   the NI or the NR for the particular NATFW NSLP signaling session,
   depending on whether it is the DS or DR that does not support NSIS.
   Typically, the edge-NAT or the edge-firewall would be used to proxy
   NATFW NSLP messages.

   This proxy mode operation does not require any new CREATE or EXTERNAL
   message type, but relies on extended CREATE and EXTERNAL message
   types.  They are called, respectively, CREATE-PROXY and EXTERNAL-
   PROXY and are distinguished by setting the P flag in the NSLP header
   to P=1.  This flag instructs edge-NATs and edge-firewalls receiving
   them to operate in proxy mode for the NATFW NSLP signaling session in
   question.  The semantics of the CREATE and EXTERNAL message types are
   not changed and the behavior of the various node types is as defined
   in Sections 3.7.1 and 3.7.2, except for the proxying node.  The
   following paragraphs describe the proxy mode operation for data
   receivers behind middleboxes and data senders behind middleboxes.

3.7.6.1.  Proxying for a Data Sender

   The NATFW NSLP gives the NR the ability to install state on the
   inbound path towards the data sender for outbound data packets, even
   when only the receiving side is running NSIS (as shown in Figure 18).
   The goal of the method described is to trigger the edge-NAT/
   edge-firewall to generate a CREATE message on behalf of the data
   receiver.  In this case, an NR can signal towards the network border

Top      Up      ToC       Page 49 
   as it is performed in the standard EXTERNAL message handling scenario
   as in Section 3.7.2.  The message is forwarded until the edge-NAT/
   edge-firewall is reached.  A public IP address and port number is
   reserved at an edge-NAT/edge-firewall.  As shown in Figure 18, unlike
   the standard EXTERNAL message handling case, the edge-NAT/
   edge-firewall is triggered to send a CREATE message on a new reverse
   path that traverse several firewalls or NATs.  The new reverse path
   for CREATE is necessary to handle routing asymmetries between the
   edge-NAT/edge-firewall and the DR.  It must be stressed that the
   semantics of the CREATE and EXTERNAL messages are not changed, i.e.,
   each is processed as described earlier.

      DS       Public Internet     NAT/FW    Private address      DR
     No NI                            NF         space            NR
      NR+                                                         NI+

      |                               |  EXTERNAL-PROXY[(DTInfo)] |
      |                               |<------------------------- |
      |                               |  RESPONSE[Error/Success]  |
      |                               | ---------------------- >  |
      |                               |   CREATE                  |
      |                               | ------------------------> |
      |                               |  RESPONSE[Error/Success]  |
      |                               | <----------------------   |
      |                               |                           |

         Figure 18: EXTERNAL Triggering Sending of CREATE Message

   A NATFW_NONCE object, carried in the EXTERNAL and CREATE message, is
   used to build the relationship between received CREATEs at the
   message initiator.  An NI+ uses the presence of the NATFW_NONCE
   object to correlate it to the particular EXTERNAL-PROXY.  The absence
   of a NONCE object indicates a CREATE initiated by the DS and not by
   the edge-NAT.  The two signaling sessions, i.e., the session for
   EXTERNAL-PROXY and the session for CREATE, are not independent.  The
   primary session is the EXTERNAL-PROXY session.  The CREATE session is
   secondary to the EXTERNAL-PROXY session, i.e., the CREATE session is
   valid as long as the EXTERNAL-PROXY session is the signaling states
   'Established' or 'Transitory'.  There is no CREATE session in any
   other signaling state of the EXTERNAL-PROXY, i.e., 'Pending' or
   'Dead'.  This ensures fate-sharing between the two signaling
   sessions.

   These processing rules of EXTERNAL-PROXY messages are added to the
   regular EXTERNAL processing:

Top      Up      ToC       Page 50 
   o  NSLP initiator (NI+): The NI+ MUST take the session ID (SID) value
      of the EXTERNAL-PROXY session as the nonce value of the
      NATFW_NONCE object.

   o  NSLP forwarder being either edge-NAT or edge-firewall: When the NF
      accepts an EXTERNAL-PROXY message, it generates a successful
      RESPONSE message as if it were the NR, and it generates a CREATE
      message as defined in Section 3.7.1 and includes a NATFW_NONCE
      object having the same value as of the received NATFW_NONCE
      object.  The NF MUST NOT generate a CREATE-PROXY message.  The NF
      MUST refresh the CREATE message signaling session only if an
      EXTERNAL-PROXY refresh message has been received first.  This also
      includes tearing down signaling sessions, i.e., the NF must tear
      down the CREATE signaling session only if an EXTERNAL-PROXY
      message with lifetime set to 0 has been received first.

   The scenario described in this section challenges the data receiver
   because it must make a correct assumption about the data sender's
   ability to use NSIS NATFW NSLP signaling.  It is possible for the DR
   to make the wrong assumption in two different ways:

      a) the DS is NSIS unaware but the DR assumes the DS to be NSIS
         aware, and

      b) the DS is NSIS aware but the DR assumes the DS to be NSIS
         unaware.

   Case a) will result in middleboxes blocking the data traffic, since
   the DS will never send the expected CREATE message.  Case b) will
   result in the DR successfully requesting proxy mode support by the
   edge-NAT or edge-firewall.  The edge-NAT/edge-firewall will send
   CREATE messages and DS will send CREATE messages as well.  Both
   CREATE messages are handled as separated NATFW NSLP signaling
   sessions and therefore the common rules per NATFW NSLP signaling
   session apply; the NATFW_NONCE object is used to differentiate CREATE
   messages generated by the edge-NAT/edge-firewall from the NI-
   initiated CREATE messages.  It is the NR's responsibility to decide
   whether to tear down the EXTERNAL-PROXY signaling sessions in the
   case where the data sender's side is NSIS aware, but was incorrectly
   assumed not to be so by the DR.  It is RECOMMENDED that a DR behind
   NATs use the proxy mode of operation by default, unless the DR knows
   that the DS is NSIS aware.  The DR MAY cache information about data
   senders that it has found to be NSIS aware in past NATFW NSLP
   signaling sessions.

Top      Up      ToC       Page 51 
   There is a possible race condition between the RESPONSE message to
   the EXTERNAL-PROXY and the CREATE message generated by the edge-NAT.
   The CREATE message can arrive earlier than the RESPONSE message.  An
   NI+ MUST accept CREATE messages generated by the edge-NAT even if the
   RESPONSE message to the EXTERNAL-PROXY was not received.

3.7.6.2.  Proxying for a Data Receiver

   As with data receivers behind middleboxes, data senders behind
   middleboxes can require proxy mode support.  The issue here is that
   there is no NSIS support at the data receiver's side and, by default,
   there will be no response to CREATE messages.  This scenario requires
   the last NSIS NATFW NSLP-aware node to terminate the forwarding and
   to proxy the response to the CREATE message, meaning that this node
   is generating RESPONSE messages.  This last node may be an edge-NAT/
   edge-firewall, or any other NATFW NSLP peer, that detects that there
   is no NR available (probably as a result of GIST timeouts but there
   may be other triggers).

      DS       Private Address      NAT/FW   Public Internet      NR
      NI           Space              NF                         no NR

      |                               |                           |
      |         CREATE-PROXY          |                           |
      |------------------------------>|                           |
      |                               |                           |
      |   RESPONSE[SUCCESS/ERROR]     |                           |
      |<------------------------------|                           |
      |                               |                           |

                 Figure 19: Proxy Mode CREATE Message Flow

   The processing of CREATE-PROXY messages and RESPONSE messages is
   similar to Section 3.7.1, except that forwarding is stopped at the
   edge-NAT/edge-firewall.  The edge-NAT/edge-firewall responds back to
   NI according to the situation (error/success) and will be the NR for
   future NATFW NSLP communication.

   The NI can choose the proxy mode of operation although the DR is NSIS
   aware.  The CREATE-PROXY mode would not configure all NATs and
   firewalls along the data path, since it is terminated at the edge-
   device.  Any device beyond this point will never receive any NATFW
   NSLP signaling for this flow.

Top      Up      ToC       Page 52 
3.7.6.3.  Incremental Deployment Using the Proxy Mode

   The above sections described the proxy mode for cases where the NATFW
   NSLP is solely deployed at the network edges.  However, the NATFW
   NSLP might be incrementally deployed first in some network edges, but
   later on also in other parts of the network.  Using the proxy mode
   only would prevent the NI from determining whether the other parts of
   the network have also been upgraded to use the NATFW NSLP.  One way
   of determining whether the path from the NI to the NR is NATFW-NSLP-
   capable is to use the regular CREATE message and to wait for a
   successful response or an error response.  This will lead to extra
   messages being sent, as a CREATE message, in addition to the CREATE-
   PROXY message (which is required anyhow), is sent from the NI.

   The NATFW NSLP allows the usage of the proxy-mode and a further
   probing of the path by the edge-NAT or edge-firewall.  The NI can
   request proxy-mode handling as described, and can set the E flag (see
   Figure 20) to request the edge-NAT or edge-firewall to probe the
   further path for NATFW NSLP enabled NFs or an NR.

   The edge-NAT or edge-firewall MUST continue to send the CREATE-PROXY
   or EXTERNAL-proxy towards the NR, if the received proxy-mode message
   has the E flag set, in addition to the regular proxy mode handling.
   The edge-NAT or edge-firewall relies on NTLP measures to determine
   whether or not there is another NATFW NSLP reachable towards the NR.
   A failed attempt to forward the request message to the NR will be
   silently discarded.  A successful attempt of forwarding the request
   message to the NR will be acknowledged by the NR with a successful
   response message, which is subject to the regular behavior described
   in the proxy-mode sections.

3.7.6.4.  Deployment Considerations for Edge-Devices

   The proxy mode assumes that the edge-NAT or edge-firewall are
   properly configured by network operator, i.e., the edge-device is
   really the final NAT or firewall of that particular network.  There
   is currently no known way of letting the NATFW NSLP automatically
   detect which of the NAT or firewalls are the actual edge of a
   network.  Therefore, it is important for the network operator to
   configure the edge-NAT or edge-firewall and also to re-configure
   these devices if they are not at the edge anymore.  For instance, an
   edge-NAT is located within an ISP and the ISP chooses to place
   another NAT in front of this edge-NAT.  In this case, the ISP needs
   to reconfigure the old edge-NAT to be a regular NATFW NLSP NAT and to
   configure the newly installed NAT to be the edge-NAT.

Top      Up      ToC       Page 53 
3.8.  Demultiplexing at NATs

   Section 3.7.2 describes how NSIS nodes behind NATs can obtain a
   publicly reachable IP address and port number at a NAT and how the
   resulting mapping rule can be activated by using CREATE messages (see
   Section 3.7.1).  The information about the public IP address/port
   number can be transmitted via an application-level signaling protocol
   and/or third party to the communication partner that would like to
   send data toward the host behind the NAT.  However, NSIS signaling
   flows are sent towards the address of the NAT at which this
   particular IP address and port number is allocated and not directly
   to the allocated IP address and port number.  The NATFW NSLP
   forwarder at this NAT needs to know how the incoming NSLP CREATE
   messages are related to reserved addresses, meaning how to
   demultiplex incoming NSIS CREATE messages.

   The demultiplexing method uses information stored at the local NATFW
   NSLP node and in the policy rule.  The policy rule uses the LE-MRM
   MRI source-address (see [RFC5971]) as the flow destination IP address
   and the network-layer-version (IP-ver) as IP version.  The external
   IP address at the NAT is stored as the external flow destination IP
   address.  All other parameters of the policy rule other than the flow
   destination IP address are wildcarded if no NATFW_DTINFO object is
   included in the EXTERNAL message.  The LE-MRM MRI destination-address
   MUST NOT be used in the policy rule, since it is solely a signaling
   destination address.

   If the NATFW_DTINFO object is included in the EXTERNAL message, the
   policy rule is filled with further information.  The 'dst port
   number' field of the NATFW_DTINFO is stored as the flow destination
   port number.  The 'protocol' field is stored as the flow protocol.
   The 'src port number' field is stored as the flow source port number.
   The 'data sender's IPv4 address' is stored as the flow source IP
   address.  Note that some of these fields can contain wildcards.

   When receiving a CREATE message at the NATFW NSLP, the NATFW NSLP
   uses the flow information stored in the MRI to do the matching
   process.  This table shows the parameters to be compared against each
   other.  Note that not all parameters need be present in an MRI at the
   same time.

Top      Up      ToC       Page 54 
    +-------------------------------+--------------------------------+
    |  Flow parameter (Policy Rule) | MRI parameter (CREATE message) |
    +-------------------------------+--------------------------------+
    |           IP version          |      network-layer-version     |
    |            Protocol           |           IP-protocol          |
    |     source IP address (w)     |       source-address (w)       |
    |      external IP address      |       destination-address      |
    |  destination IP address (n/u) |               N/A              |
    |     source port number (w)    |       L4-source-port (w)       |
    |    external port number (w)   |     L4-destination-port (w)    |
    | destination port number (n/u) |               N/A              |
    |           IPsec-SPI           |            ipsec-SPI           |
    +-------------------------------+--------------------------------+

            Table entries marked with (w) can be wildcarded and
         entries marked with (n/u) are not used for the matching.

                                  Table 1

   It should be noted that the Protocol/IP-protocol entries in Table 1
   refer to the 'Protocol' field in the IPv4 header or the 'next header'
   entry in the IPv6 header.

3.9.  Reacting to Route Changes

   The NATFW NSLP needs to react to route changes in the data path.
   This assumes the capability to detect route changes, to perform NAT
   and firewall configuration on the new path and possibly to tear down
   NATFW NSLP signaling session state on the old path.  The detection of
   route changes is described in Section 7 of [RFC5971], and the NATFW
   NSLP relies on notifications about route changes by the NTLP.  This
   notification will be conveyed by the API between NTLP and NSLP, which
   is out of the scope of this memo.

   A NATFW NSLP node other than the NI or NI+ detecting a route change,
   by means described in the NTLP specification or others, generates a
   NOTIFY message indicating this change and sends this inbound towards
   NI and outbound towards the NR (see also Section 3.7.5).
   Intermediate NFs on the way to the NI can use this information to
   decide later if their NATFW NSLP signaling session can be deleted
   locally, if they do not receive an update within a certain time
   period, as described in Section 3.2.8.  It is important to consider
   the transport limitations of NOTIFY messages as mandated in
   Section 3.7.5.

   The NI receiving this NOTIFY message MAY generate a new CREATE or
   EXTERNAL message and send it towards the NATFW NSLP signaling
   session's NI as for the initial message using the same session ID.

Top      Up      ToC       Page 55 
   All the remaining processing and message forwarding, such as NSLP
   next-hop discovery, is subject to regular NSLP processing as
   described in the particular sections.  Normal routing will guide the
   new CREATE or EXTERNAL message to the correct NFs along the changed
   route.  NFs that were on the original path receiving these new CREATE
   or EXTERNAL messages (see also Section 3.10), can use the session ID
   to update the existing NATFW NSLP signaling session; whereas NFs that
   were not on the original path will create new state for this NATFW
   NSLP signaling session.  The next section describes how policy rules
   are updated.

3.10.  Updating Policy Rules

   NSIS initiators can request an update of the installed/reserved
   policy rules at any time within a NATFW NSLP signaling session.
   Updates to policy rules can be required due to node mobility (NI is
   moving from one IP address to another), route changes (this can
   result in a different NAT mapping at a different NAT device), or the
   wish of the NI to simply change the rule.  NIs can update policy
   rules in existing NATFW NSLP signaling sessions by sending an
   appropriate CREATE or EXTERNAL message (similar to Section 3.4) with
   modified message routing information (MRI) as compared with that
   installed previously, but using the existing session ID to identify
   the intended target of the update.  With respect to authorization and
   authentication, this update CREATE or EXTERNAL message is treated in
   exactly the same way as any initial message.  Therefore, any node
   along in the NATFW NSLP signaling session can reject the update with
   an error RESPONSE message, as defined in the previous sections.

   The message processing and forwarding is executed as defined in the
   particular sections.  An NF or the NR receiving an update simply
   replaces the installed policy rules installed in the firewall/NAT.
   The local procedures on how to update the MRI in the firewall/NAT is
   out of the scope of this memo.



(page 55 continued on part 4)

Next RFC Part