RFC 5973
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
Pages: 90
Experimental
Experimental
Part 4 of 5 – Pages 55 to 76
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.
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.
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.
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 Object4.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.
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
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
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.
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.
* 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.
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 Object4.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 Object4.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)
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.
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.
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)
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:
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.
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.
+------------------------+ +-------------------------+ |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.
+-----------------------------------------------------------+ | 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.
+--------------------+ +---------------------+ | 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 Relationship5.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
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
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.
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)