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