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 4 of 5, p. 55 to 76
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 55 
4.  NATFW NSLP Message Components

   A NATFW NSLP message consists of an NSLP header and one or more
   objects following the header.  The NSLP header is carried in all
   NATFW NSLP messages and objects are Type-Length-Value (TLV) encoded
   using big endian (network ordered) binary data representations.
   Header and objects are aligned to 32-bit boundaries and object
   lengths that are not multiples of 32 bits must be padded to the next
   higher 32-bit multiple.

   The whole NSLP message is carried as payload of a NTLP message.

   Note that the notation 0x is used to indicate hexadecimal numbers.

Top      Up      ToC       Page 56 
4.1.  NSLP Header

   All GIST NSLP-Data objects for the NATFW NSLP MUST contain this
   common header as the first 32 bits of the object (this is not the
   same as the GIST Common Header).  It contains two fields, the NSLP
   message type and the P Flag, plus two reserved fields.  The total
   length is 32 bits.  The layout of the NSLP header is defined by
   Figure 20.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message type  |P|E| reserved  |       reserved                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 20: Common NSLP Header

   The reserved field MUST be set to zero in the NATFW NSLP header
   before sending and MUST be ignored during processing of the header.

   The defined messages types are:

   o  0x1: CREATE

   o  0x2: EXTERNAL

   o  0x3: RESPONSE

   o  0x4: NOTIFY

   If a message with another type is received, an error RESPONSE of
   class 'Protocol error' (3) with response code 'Illegal message type'
   (0x01) MUST be generated.

   The P flag indicates the usage of proxy mode.  If the proxy mode is
   used, it MUST be set to 1.  Proxy mode MUST only be used in
   combination with the message types CREATE and EXTERNAL.  The P flag
   MUST be ignored when processing messages with type RESPONSE or
   NOTIFY.

   The E flag indicates, in proxy mode, whether the edge-NAT or edge-
   firewall MUST continue sending the message to the NR, i.e., end-to-
   end.  The E flag can only be set to 1 if the P flag is set;
   otherwise, it MUST be ignored.  The E flag MUST only be used in
   combination with the message types CREATE and EXTERNAL.  The E flag
   MUST be ignored when processing messages with type RESPONSE or
   NOTIFY.

Top      Up      ToC       Page 57 
4.2.  NSLP Objects

   NATFW NSLP objects use a common header format defined by Figure 21.
   The object header contains these fields: two flags, two reserved
   bits, the NSLP object type, a reserved field of 4 bits, and the
   object length.  Its total length is 32 bits.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|B|r|r|   Object Type         |r|r|r|r|   Object Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 21: Common NSLP Object Header

   The object length field contains the total length of the object
   without the object header.  The unit is a word, consisting of 4
   octets.  The particular values of type and length for each NSLP
   object are listed in the subsequent sections that define the NSLP
   objects.  An error RESPONSE of class 'Protocol error' (3) with
   response code 'Wrong object length' (0x07) MUST be generated if the
   length given in the object header is inconsistent with the type of
   object specified or the message is shorter than implied by the object
   length.  The two leading bits of the NSLP object header are used to
   signal the desired treatment for objects whose treatment has not been
   defined in this memo (see [RFC5971], Appendix A.2.1), i.e., the
   Object Type has not been defined.  NATFW NSLP uses a subset of the
   categories defined in GIST:

   o  AB=00 ("Mandatory"): If the object is not understood, the entire
      message containing it MUST be rejected with an error RESPONSE of
      class 'Protocol error' (3) with response code 'Unknown object
      present' (0x06).

   o  AB=01 ("Optional"): If the object is not understood, it should be
      deleted and then the rest of the message processed as usual.

   o  AB=10 ("Forward"): If the object is not understood, it should be
      retained unchanged in any message forwarded as a result of message
      processing, but not stored locally.

   The combination AB=11 MUST NOT be used and an error RESPONSE of class
   'Protocol error' (3) with response code 'Invalid Flag-Field
   combination' (0x09) MUST be generated.

   The following sections do not repeat the common NSLP object header,
   they just list the type and the length.

Top      Up      ToC       Page 58 
4.2.1.  Signaling Session Lifetime Object

   The signaling session lifetime object carries the requested or
   granted lifetime of a NATFW NSLP signaling session measured in
   seconds.

      Type: NATFW_LT (0x00C)

      Length: 1

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          NATFW NSLP signaling session lifetime                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 22: Signaling Session Lifetime Object

4.2.2.  External Address Object

   The external address object can be included in RESPONSE messages
   (Section 4.3.3) only.  It carries the publicly reachable IP address,
   and if applicable port number, at an edge-NAT.

      Type: NATFW_EXTERNAL_IP (0x00D)

      Length: 2

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         port number           |IP-Ver |   reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IPv4 address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 23: External Address Object for IPv4 Addresses

   Please note that the field 'port number' MUST be set to 0 if only an
   IP address has been reserved, for instance, by a traditional NAT.  A
   port number of 0 MUST be ignored in processing this object.

   IP-Ver (4 bits): The IP version number.  This field MUST be set to 4.

Top      Up      ToC       Page 59 
4.2.3.  External Binding Address Object

   The external binding address object can be included in RESPONSE
   messages (Section 4.3.3) and EXTERNAL (Section 3.7.2) messages.  It
   carries one or multiple external binding addresses, and if applicable
   port number, for multi-level NAT deployments (for an example, see
   Section 2.5).  The utilization of the information carried in this
   object is described in Appendix B.

      Type: NATFW_EXTERNAL_BINDING (0x00E)

      Length: 1 + number of IPv4 addresses

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         port number           |IP-Ver |   reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IPv4 address #1                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                           . . .                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IPv4 address  #n                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 24: External Binding Address Object

   Please note that the field 'port number' MUST be set to 0 if only an
   IP address has been reserved, for instance, by a traditional NAT.  A
   port number of 0 MUST be ignored in processing this object.

   IP-Ver (4 bits): The IP version number.  This field MUST be set to 4.

4.2.4.  Extended Flow Information Object

   In general, flow information is kept in the message routing
   information (MRI) of the NTLP.  Nevertheless, some additional
   information may be required for NSLP operations.  The 'extended flow
   information' object carries this additional information about the
   action of the policy rule for firewalls/NATs and a potential
   contiguous port.

      Type: NATFW_EFI (0x00F)

      Length: 1

Top      Up      ToC       Page 60 
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           rule action         |           sub_ports           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 25: Extended Flow Information

   This object has two fields, 'rule action' and 'sub_ports'.  The 'rule
   action' field has these meanings:

   o  0x0001: Allow: A policy rule with this action allows data traffic
      to traverse the middlebox and the NATFW NSLP MUST allow NSLP
      signaling to be forwarded.

   o  0x0002: Deny: A policy rule with this action blocks data traffic
      from traversing the middlebox and the NATFW NSLP MUST NOT allow
      NSLP signaling to be forwarded.

   If the 'rule action' field contains neither 0x0001 nor 0x0002, an
   error RESPONSE of class 'Signaling session failure' (7) with response
   code 'Unknown policy rule action' (0x05) MUST be generated.

   The 'sub_ports' field contains the number of contiguous transport
   layer ports to which this rule applies.  The default value of this
   field is 0, i.e., only the port specified in the NTLP's MRM or
   NATFW_DTINFO object is used for the policy rule.  A value of 1
   indicates that additionally to the port specified in the NTLP's MRM
   (port1), a second port (port2) is used.  This value of port 2 is
   calculated as: port2 = port1 + 1.  Other values than 0 or 1 MUST NOT
   be used in this field and an error RESPONSE of class 'Signaling
   session failure' (7) with response code 'Requested value in sub_ports
   field in NATFW_EFI not permitted' (0x08) MUST be generated.  These
   two contiguous numbered ports can be used by legacy voice over IP
   equipment.  This legacy equipment assumes two adjacent port numbers
   for its RTP/RTCP flows, respectively.

4.2.5.  Information Code Object

   This object carries the response code in RESPONSE messages, which
   indicates either a successful or failed CREATE or EXTERNAL message
   depending on the value of the 'response code' field.  This object is
   also carried in a NOTIFY message to specify the reason for the
   notification.

      Type: NATFW_INFO (0x010)

      Length: 1

Top      Up      ToC       Page 61 
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Resv. | Class | Response Code |r|r|r|r|     Object Type       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 26: Information Code Object

   The field 'resv.' is reserved for future extensions and MUST be set
   to zero when generating such an object and MUST be ignored when
   receiving.  The 'Object Type' field contains the type of the object
   causing the error.  The value of 'Object Type' is set to 0, if no
   object is concerned.  The leading fours bits marked with 'r' are
   always set to zero and ignored.  The 4-bit class field contains the
   error class.  The following classes are defined:

   o  0: Reserved

   o  1: Informational (NOTIFY only)

   o  2: Success

   o  3: Protocol error

   o  4: Transient failure

   o  5: Permanent failure

   o  7: Signaling session failure

   Within each error class a number of responses codes are defined as
   follows.

   o  Informational:

      *  0x01: Route change: possible route change on the outbound path.

      *  0x02: Re-authentication required.

      *  0x03: NATFW node is going down soon.

      *  0x04: NATFW signaling session lifetime expired.

      *  0x05: NATFW signaling session terminated.

   o  Success:

      *  0x01: All successfully processed.

Top      Up      ToC       Page 62 
   o  Protocol error:

      *  0x01: Illegal message type: the type given in the Message Type
         field of the NSLP header is unknown.

      *  0x02: Wrong message length: the length given for the message in
         the NSLP header does not match the length of the message data.

      *  0x03: Bad flags value: an undefined flag or combination of
         flags was set in the NSLP header.

      *  0x04: Mandatory object missing: an object required in a message
         of this type was missing.

      *  0x05: Illegal object present: an object was present that must
         not be used in a message of this type.

      *  0x06: Unknown object present: an object of an unknown type was
         present in the message.

      *  0x07: Wrong object length: the length given for the object in
         the object header did not match the length of the object data
         present.

      *  0x08: Unknown object field value: a field in an object had an
         unknown value.

      *  0x09: Invalid Flag-Field combination: An object contains an
         invalid combination of flags and/or fields.

      *  0x0A: Duplicate object present.

      *  0x0B: Received EXTERNAL request message on external side.

   o  Transient failure:

      *  0x01: Requested resources temporarily not available.

   o  Permanent failure:

      *  0x01: Authentication failed.

      *  0x02: Authorization failed.

      *  0x04: Internal or system error.

      *  0x06: No edge-device here.

Top      Up      ToC       Page 63 
      *  0x07: Did not reach the NR.

   o  Signaling session failure:

      *  0x01: Session terminated asynchronously.

      *  0x02: Requested lifetime is too big.

      *  0x03: No reservation found matching the MRI of the CREATE
         request.

      *  0x04: Requested policy rule denied due to policy conflict.

      *  0x05: Unknown policy rule action.

      *  0x06: Requested rule action not applicable.

      *  0x07: NATFW_DTINFO object is required.

      *  0x08: Requested value in sub_ports field in NATFW_EFI not
         permitted.

      *  0x09: Requested IP protocol not supported.

      *  0x0A: Plain IP policy rules not permitted -- need transport
         layer information.

      *  0x0B: ICMP type value not permitted.

      *  0x0C: Source IP address range is too large.

      *  0x0D: Destination IP address range is too large.

      *  0x0E: Source L4-port range is too large.

      *  0x0F: Destination L4-port range is too large.

      *  0x10: Requested lifetime is too small.

      *  0x11: Modified lifetime is too big.

      *  0x12: Modified lifetime is too small.

Top      Up      ToC       Page 64 
4.2.6.  Nonce Object

   This object carries the nonce value as described in Section 3.7.6.

      Type: NATFW_NONCE (0x011)

      Length: 1

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         nonce                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 27: Nonce Object

4.2.7.  Message Sequence Number Object

   This object carries the MSN value as described in Section 3.5.

      Type: NATFW_MSN (0x012)

      Length: 1

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    message sequence number                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 28: Message Sequence Number Object

4.2.8.  Data Terminal Information Object

   The 'data terminal information' object carries additional information
   that MUST be included the EXTERNAL message.  EXTERNAL messages are
   transported by the NTLP using the Loose-End message routing method
   (LE-MRM).  The LE-MRM contains only the DR's IP address and a
   signaling destination address (destination IP address).  This
   destination IP address is used for message routing only and is not
   necessarily reflecting the address of the data sender.  This object
   contains information about (if applicable) DR's port number (the
   destination port number), the DS's port number (the source port
   number), the used transport protocol, the prefix length of the IP
   address, and DS's IP address.

      Type: NATFW_DTINFO (0x013)

Top      Up      ToC       Page 65 
      Length: variable.  Maximum 3.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |I|P|S|    reserved             | sender prefix |    protocol   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :      DR port number           |       DS port number          :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                            IPsec-SPI                          :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  data sender's IPv4 address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 29: Data Terminal IPv4 Address Object

   The flags are:

   o  I: I=1 means that 'protocol' should be interpreted.

   o  P: P=1 means that 'dst port number' and 'src port number' are
      present and should be interpreted.

   o  S: S=1 means that SPI is present and should be interpreted.

   The SPI field is only present if S is set.  The port numbers are only
   present if P is set.  The flags P and S MUST NOT be set at the same
   time.  An error RESPONSE of class 'Protocol error' (3) with response
   code 'Invalid Flag-Field combination' (0x09) MUST be generated if
   they are both set.  If either P or S is set, I MUST be set as well
   and the protocol field MUST carry the particular protocol.  An error
   RESPONSE of class 'Protocol error' (3) with response code 'Invalid
   Flag-Field combination' (0x09) MUST be generated if S or P is set but
   I is not set.

   The fields MUST be interpreted according to these rules:

   o  (data) sender prefix: This parameter indicates the prefix length
      of the 'data sender's IP address' in bits.  For instance, a full
      IPv4 address requires 'sender prefix' to be set to 32.  A value of
      0 indicates an IP address wildcard.

   o  protocol: The IP protocol field.  This field MUST be interpreted
      if I=1; otherwise, it MUST be set to 0 and MUST be ignored.

Top      Up      ToC       Page 66 
   o  DR port number: The port number at the data receiver (DR), i.e.,
      the destination port.  A value of 0 indicates a port wildcard,
      i.e., the destination port number is not known.  Any other value
      indicates the destination port number.

   o  DS port number: The port number at the data sender (DS), i.e., the
      source port.  A value of 0 indicates a port wildcard, i.e., the
      source port number is not known.  Any other value indicates the
      source port number.

   o  data sender's IPv4 address: The source IP address of the data
      sender.  This field MUST be set to zero if no IP address is
      provided, i.e., a complete wildcard is desired (see the dest
      prefix field above).

4.2.9.  ICMP Types Object

   The 'ICMP types' object contains additional information needed to
   configure a NAT of firewall with rules to control ICMP traffic.  The
   object contains a number of values of the ICMP Type field for which a
   filter action should be set up:

      Type: NATFW_ICMP_TYPES (0x014)

      Length: Variable = ((Number of Types carried + 1) + 3) DIV 4

   Where DIV is an integer division.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Count      |     Type      |      Type     |    ........   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       ................                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    ........   |     Type      |           (Padding)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 30: ICMP Types Object

   The fields MUST be interpreted according to these rules:

      count: 8-bit integer specifying the number of 'Type' entries in
      the object.

      type: 8-bit field specifying an ICMP Type value to which this rule
      applies.

Top      Up      ToC       Page 67 
      padding: Sufficient 0 bits to pad out the last word so that the
      total size of the object is an even multiple of words.  Ignored on
      reception.

4.3.  Message Formats

   This section defines the content of each NATFW NSLP message type.
   The message types are defined in Section 4.1.

   Basically, each message is constructed of an NSLP header and one or
   more NSLP objects.  The order of objects is not defined, meaning that
   objects may occur in any sequence.  Objects are marked either with
   mandatory (M) or optional (O).  Where (M) implies that this
   particular object MUST be included within the message and where (O)
   implies that this particular object is OPTIONAL within the message.
   Objects defined in this memo always carry the flag combination AB=00
   in the NSLP object header.  An error RESPONSE message of class
   'Protocol error' (3) with response code 'Mandatory object missing'
   (0x04) MUST be generated if a mandatory declared object is missing.
   An error RESPONSE message of class 'Protocol error' (3) with response
   code 'Illegal object present' (0x05) MUST be generated if an object
   was present that must not be used in a message of this type.  An
   error RESPONSE message of class 'Protocol error' (3) with response
   code 'Duplicate object present' (0x0A) MUST be generated if an object
   appears more than once in a message.

   Each section elaborates the required settings and parameters to be
   set by the NSLP for the NTLP, for instance, how the message routing
   information is set.

4.3.1.  CREATE

   The CREATE message is used to create NATFW NSLP signaling sessions
   and to create policy rules.  Furthermore, CREATE messages are used to
   refresh NATFW NSLP signaling sessions and to delete them.

   The CREATE message carries these objects:

   o  Signaling Session Lifetime object (M)

   o  Extended flow information object (M)

   o  Message sequence number object (M)

   o  Nonce object (M) if P flag set to 1 in the NSLP header, otherwise
      (O)

   o  ICMP Types Object (O)

Top      Up      ToC       Page 68 
   The message routing information in the NTLP MUST be set to DS as
   source IP address and DR as destination IP address.  All other
   parameters MUST be set according to the required policy rule.  CREATE
   messages MUST be transported by using the path-coupled MRM with the
   direction set to 'downstream' (outbound).

4.3.2.  EXTERNAL

   The EXTERNAL message is used to a) reserve an external IP address/
   port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to
   block incoming data traffic at inbound firewalls.

   The EXTERNAL message carries these objects:

   o  Signaling Session Lifetime object (M)

   o  Message sequence number object (M)

   o  Extended flow information object (M)

   o  Data terminal information object (M)

   o  Nonce object (M) if P flag set to 1 in the NSLP header, otherwise
      (O)

   o  ICMP Types Object (O)

   o  External binding address object (O)

   The selected message routing method of the EXTERNAL message depends
   on a number of considerations.  Section 3.7.2 describes exhaustively
   how to select the correct method.  EXTERNAL messages can be
   transported via the path-coupled message routing method (PC-MRM) or
   via the loose-end message routing method (LE-MRM).  In the case of
   PC-MRM, the source-address is set to the DS's address and the
   destination-address is set to the DR's address, the direction is set
   to inbound.  In the case of LE-MRM, the destination-address is set to
   the DR's address or to the signaling destination IP address.  The
   source-address is set to the DS's address.

4.3.3.  RESPONSE

   RESPONSE messages are responses to CREATE and EXTERNAL messages.
   RESPONSE messages MUST NOT be generated for any other message, such
   as NOTIFY and RESPONSE.

   The RESPONSE message for the class 'Success' (2) carries these
   objects:

Top      Up      ToC       Page 69 
   o  Signaling Session Lifetime object (M)

   o  Message sequence number object (M)

   o  Information code object (M)

   o  External address object (O)

   o  External binding address object (O)

   The RESPONSE message for other classes than 'Success' (2) carries
   these objects:

   o  Message sequence number object (M)

   o  Information code object (M)

   o  Signaling Session Lifetime object (O)

   This message is routed towards the NI hop-by-hop, using existing NTLP
   messaging associations.  The MRM used for this message MUST be the
   same as MRM used by the corresponding CREATE or EXTERNAL message.

4.3.4.  NOTIFY

   The NOTIFY messages is used to report asynchronous events happening
   along the signaled path to other NATFW NSLP nodes.

   The NOTIFY message carries this object:

   o  Information code object (M)

   The NOTIFY message is routed towards the next NF, NI, or NR hop-by-
   hop using the existing inbound or outbound node messaging association
   entry within the node's Message Routing State table.  The MRM used
   for this message MUST be the same as MRM used by the corresponding
   CREATE or EXTERNAL message.

5.  Security Considerations

   Security is of major concern particularly in the case of firewall
   traversal.  This section provides security considerations for the
   NAT/firewall traversal and is organized as follows.

   In Section 5.1, we describe how the participating entities relate to
   each other from a security point of view.  That subsection also
   motivates a particular authorization model.

Top      Up      ToC       Page 70 
   Security threats that focus on NSIS in general are described in
   [RFC4081] and they are applicable to this document as well.

   Finally, we illustrate how the security requirements that were
   created based on the security threats can be fulfilled by specific
   security mechanisms.  These aspects will be elaborated in
   Section 5.2.

5.1.  Authorization Framework

   The NATFW NSLP is a protocol that may involve a number of NSIS nodes
   and is, as such, not a two-party protocol.  Figures 1 and 2 of
   [RFC4081] already depict the possible set of communication patterns.
   In this section, we will re-evaluate these communication patterns
   with respect to the NATFW NSLP protocol interaction.

   The security solutions for providing authorization have a direct
   impact on the treatment of different NSLPs.  As it can be seen from
   the QoS NSLP [RFC5974] and the corresponding Diameter QoS work
   [RFC5866], accounting and charging seems to play an important role
   for QoS reservations, whereas monetary aspects might only indirectly
   effect authorization decisions for NAT and firewall signaling.
   Hence, there are differences in the semantics of authorization
   handling between QoS and NATFW signaling.  A NATFW-aware node will
   most likely want to authorize the entity (e.g., user or machine)
   requesting the establishment of pinholes or NAT bindings.  The
   outcome of the authorization decision is either allowed or
   disallowed, whereas a QoS authorization decision might indicate that
   a different set of QoS parameters is authorized (see [RFC5866] as an
   example).

5.1.1.  Peer-to-Peer Relationship

   Starting with the simplest scenario, it is assumed that neighboring
   nodes are able to authenticate each other and to establish keying
   material to protect the signaling message communication.  The nodes
   will have to authorize each other, additionally to the
   authentication.  We use the term 'Security Context' as a placeholder
   for referring to the entire security procedure, the necessary
   infrastructure that needs to be in place in order for this to work
   (e.g., key management) and the established security-related state.
   The required long-term keys (symmetric or asymmetric keys) used for
   authentication either are made available using an out-of-band
   mechanism between the two NSIS NATFW nodes or are dynamically
   established using mechanisms not further specified in this document.
   Note that the deployment environment will most likely have an impact
   on the choice of credentials being used.  The choice of these
   credentials used is also outside the scope of this document.

Top      Up      ToC       Page 71 
   +------------------------+              +-------------------------+
   |Network A               |              |                Network B|
   |              +---------+              +---------+               |
   |        +-///-+ Middle- +---///////----+ Middle- +-///-+         |
   |        |     |  box 1  | Security     |  box 2  |     |         |
   |        |     +---------+ Context      +---------+     |         |
   |        | Security      |              |  Security     |         |
   |        | Context       |              |  Context      |         |
   |        |               |              |               |         |
   |     +--+---+           |              |            +--+---+     |
   |     | Host |           |              |            | Host |     |
   |     |  A   |           |              |            |  B   |     |
   |     +------+           |              |            +------+     |
   +------------------------+              +-------------------------+

                   Figure 31: Peer-to-Peer Relationship

   Figure 31 shows a possible relationship between participating NSIS-
   aware nodes.  Host A might be, for example, a host in an enterprise
   network that has keying material established (e.g., a shared secret)
   with the company's firewall (Middlebox 1).  The network administrator
   of Network A (company network) has created access control lists for
   Host A (or whatever identifiers a particular company wants to use).
   Exactly the same procedure might also be used between Host B and
   Middlebox 2 in Network B.  For the communication between Middlebox 1
   and Middlebox 2 a security context is also assumed in order to allow
   authentication, authorization, and signaling message protection to be
   successful.

5.1.2.  Intra-Domain Relationship

   In larger corporations, for example, a middlebox is used to protect
   individual departments.  In many cases, the entire enterprise is
   controlled by a single (or a small number of) security department(s),
   which give instructions to the department administrators.  In such a
   scenario, the previously discussed peer-to-peer relationship might be
   prevalent.  Sometimes it might be necessary to preserve
   authentication and authorization information within the network.  As
   a possible solution, a centralized approach could be used, whereby an
   interaction between the individual middleboxes and a central entity
   (for example, a policy decision point - PDP) takes place.  As an
   alternative, individual middleboxes exchange the authorization
   decision with another middlebox within the same trust domain.
   Individual middleboxes within an administrative domain may exploit
   their relationship instead of requesting authentication and
   authorization of the signaling initiator again and again.  Figure 32
   illustrates a network structure that uses a centralized entity.

Top      Up      ToC       Page 72 
       +-----------------------------------------------------------+
       |                                               Network A   |
       |                      +---------+                +---------+
       |      +----///--------+ Middle- +------///------++ Middle- +---
       |      | Security      |  box 2  | Security       |  box 2  |
       |      | Context       +----+----+ Context        +----+----+
       | +----+----+               |                          |    |
       | | Middle- +--------+      +---------+                |    |
       | |  box 1  |        |                |                |    |
       | +----+----+        |                |                |    |
       |      | Security    |           +----+-----+          |    |
       |      | Context     |           | Policy   |          |    |
       |   +--+---+         +-----------+ Decision +----------+    |
       |   | Host |                     | Point    |               |
       |   |  A   |                     +----------+               |
       |   +------+                                                |
       +-----------------------------------------------------------+

                   Figure 32: Intra-Domain Relationship

   The interaction between individual middleboxes and a policy decision
   point (or AAA server) is outside the scope of this document.

5.1.3.  End-to-Middle Relationship

   The peer-to-peer relationship between neighboring NSIS NATFW NSLP
   nodes might not always be sufficient.  Network B might require
   additional authorization of the signaling message initiator (in
   addition to the authorization of the neighboring node).  If
   authentication and authorization information is not attached to the
   initial signaling message then the signaling message arriving at
   Middlebox 2 would result in an error message being created, which
   indicates the additional authorization requirement.  In many cases,
   the signaling message initiator might already be aware of the
   additionally required authorization before the signaling message
   exchange is executed.

   Figure 33 shows this scenario.

Top      Up      ToC       Page 73 
       +--------------------+              +---------------------+
       |          Network A |              |Network B            |
       |                    |   Security   |                     |
       |          +---------+   Context    +---------+           |
       |    +-///-+ Middle- +---///////----+ Middle- +-///-+     |
       |    |     |  box 1  |      +-------+  box 2  |     |     |
       |    |     +---------+      |       +---------+     |     |
       |    |Security       |      |       | Security      |     |
       |    |Context        |      |       | Context       |
       |    |               |      |       |               |     |
       | +--+---+           |      |       |            +--+---+ |
       | | Host +----///----+------+       |            | Host | |
       | |  A   |           |   Security   |            |  B   | |
       | +------+           |   Context    |            +------+ |
       +--------------------+              +---------------------+

                   Figure 33: End-to-Middle Relationship

5.2.  Security Framework for the NAT/Firewall NSLP

   The following list of security requirements has been created to
   ensure proper secure operation of the NATFW NSLP.

5.2.1.  Security Protection between Neighboring NATFW NSLP Nodes

   Based on the analyzed threats, it is RECOMMENDED to provide, between
   neighboring NATFW NSLP nodes, the following mechanisms:

   o  data origin authentication,

   o  replay protection,

   o  integrity protection, and,

   o  optionally, confidentiality protection

   It is RECOMMENDED to use the authentication and key exchange security
   mechanisms provided in [RFC5971] between neighboring nodes when
   sending NATFW signaling messages.  The proposed security mechanisms
   of GIST provide support for authentication and key exchange in
   addition to denial-of-service protection.  Depending on the chosen
   security protocol, support for multiple authentication protocols
   might be provided.  If security between neighboring nodes is desired,
   then the usage of C-MODE with a secure transport protocol for the
   delivery of most NSIS messages with the usage of D-MODE only to
   discover the next NATFW NSLP-aware node along the path is highly
   RECOMMENDED.  See [RFC5971] for the definitions of C-MODE and D-MODE.
   Almost all security threats at the NATFW NSLP-layer can be prevented

Top      Up      ToC       Page 74 
   by using a mutually authenticated Transport Layer secured connection
   and by relying on authorization by the neighboring NATFW NSLP
   entities.

   The NATFW NSLP relies on an established security association between
   neighboring peers to prevent unauthorized nodes from modifying or
   deleting installed state.  Between non-neighboring nodes the session
   ID (SID) carried in the NTLP is used to show ownership of a NATFW
   NSLP signaling session.  The session ID MUST be generated in a random
   way and thereby prevents an off-path adversary from mounting targeted
   attacks.  Hence, an adversary would have to learn the randomly
   generated session ID to perform an attack.  In a mobility environment
   a former on-path node that is now off-path can perform an attack.
   Messages for a particular NATFW NSLP signaling session are handled by
   the NTLP to the NATFW NSLP for further processing.  Messages carrying
   a different session ID not associated with any NATFW NSLP are subject
   to the regular processing for new NATFW NSLP signaling sessions.

5.2.2.  Security Protection between Non-Neighboring NATFW NSLP Nodes

   Based on the security threats and the listed requirements, it was
   noted that some threats also demand authentication and authorization
   of a NATFW signaling entity (including the initiator) towards a non-
   neighboring node.  This mechanism mainly demands entity
   authentication.  The most important information exchanged at the
   NATFW NSLP is information related to the establishment for firewall
   pinholes and NAT bindings.  This information can, however, not be
   protected over multiple NSIS NATFW NSLP hops since this information
   might change depending on the capability of each individual NATFW
   NSLP node.

   Some scenarios might also benefit from the usage of authorization
   tokens.  Their purpose is to associate two different signaling
   protocols (e.g., SIP and NSIS) and their authorization decision.
   These tokens are obtained by non-NSIS protocols, such as SIP or as
   part of network access authentication.  When a NAT or firewall along
   the path receives the token it might be verified locally or passed to
   the AAA infrastructure.  Examples of authorization tokens can be
   found in RFC 3520 [RFC3520] and RFC 3521 [RFC3521].  Figure 34 shows
   an example of this protocol interaction.

   An authorization token is provided by the SIP proxy, which acts as
   the assertion generating entity and gets delivered to the end host
   with proper authentication and authorization.  When the NATFW
   signaling message is transmitted towards the network, the
   authorization token is attached to the signaling messages to refer to
   the previous authorization decision.  The assertion-verifying entity
   needs to process the token or it might be necessary to interact with

Top      Up      ToC       Page 75 
   the assertion-granting entity using HTTP (or other protocols).  As a
   result of a successfully authorization by a NATFW NSLP node, the
   requested action is executed and later a RESPONSE message is
   generated.

    +----------------+   Trust Relationship    +----------------+
    | +------------+ |<.......................>| +------------+ |
    | | Protocol   | |                         | | Assertion  | |
    | | requesting | |    HTTP, SIP Request    | | Granting   | |
    | | authz      | |------------------------>| | Entity     | |
    | | assertions | |<------------------------| +------------+ |
    | +------------+ |    Artifact/Assertion   |  Entity Cecil  |
    |       ^        |                         +----------------+
    |       |        |                          ^     ^|
    |       |        |                          .     || HTTP,
    |       |        |              Trust       .     || other
    |   API Access   |              Relationship.     || protocols
    |       |        |                          .     ||
    |       |        |                          .     ||
    |       |        |                          v     |v
    |       v        |                         +----------------+
    | +------------+ |                         | +------------+ |
    | | Protocol   | |  NSIS NATFW CREATE +    | | Assertion  | |
    | | using authz| |  Assertion/Artifact     | | Verifying  | |
    | | assertion  | | ----------------------- | | Entity     | |
    | +------------+ |                         | +------------+ |
    |  Entity Alice  | <---------------------- |  Entity Bob    |
    +----------------+   RESPONSE              +----------------+

                   Figure 34: Authorization Token Usage

   Threats against the usage of authorization tokens have been mentioned
   in [RFC4081].  Hence, it is required to provide confidentiality
   protection to avoid allowing an eavesdropper to learn the token and
   to use it in another NATFW NSLP signaling session (replay attack).
   The token itself also needs to be protected against tempering.

5.3.  Implementation of NATFW NSLP Security

   The prior sections describe how to secure the NATFW NSLP in the
   presence of established trust between the various players and the
   particular relationships (e.g., intra-domain, end-to-middle, or peer-
   to-peer).  However, in typical Internet deployments there is no
   established trust, other than granting access to a network, but not
   between various sites in the Internet.  Furthermore, the NATFW NSLP
   may be incrementally deployed with a widely varying ability to be
   able to use authentication and authorization services.

Top      Up      ToC       Page 76 
   The NATFW NSLP offers a way to keep the authentication and
   authorization at the "edge" of the network.  The local edge network
   can deploy and use any type of Authentication and Authorization (AA)
   scheme without the need to have AA technology match with other edges
   in the Internet (assuming that firewalls and NATs are deployed at the
   edges of the network and not somewhere in the cores).

   Each network edge that has the NATFW NSLP deployed can use the
   EXTERNAL request message to allow a secure access to the network.
   Using the EXTERNAL request message does allow the DR to open the
   firewall/NAT on the receiver's side.  However, the edge-devices
   should not allow the firewall/NAT to be opened up completely (i.e.,
   should not apply an allow-all policy), but should let DRs reserve
   very specific policies.  For instance, a DR can request reservation
   of an 'allow' policy rule for an incoming TCP connection for a Jabber
   file transfer.  This reserved policy (see Figure 15) rule must be
   activated by matching the CREATE request message (see Figure 15).
   This mechanism allows for the authentication and authorization issues
   to be managed locally at the particular edge-network.  In the reverse
   direction, the CREATE request message can be handled independently on
   the DS side with respect to authentication and authorization.

   The usage described in the above paragraph is further simplified for
   an incremental deployment: there is no requirement to activate a
   reserved policy rule with a CREATE request message.  This is
   completely handled by the EXTERNAL-PROXY request message and the
   associated CREATE request message.  Both of them are handled by the
   local authentication and authorization scheme.



(page 76 continued on part 5)

Next RFC Part