RFC 5973
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
Pages: 90
Experimental
Experimental
Part 2 of 5 – Pages 13 to 31
2. Network Deployment Scenarios Using the NATFW NSLP
This section introduces several scenarios for middlebox placement within IP networks. Middleboxes are typically found at various different locations, including at enterprise network borders, within enterprise networks, as mobile phone network gateways, etc. Usually, middleboxes are placed more towards the edge of networks than in network cores. Firewalls and NATs may be found at these locations either alone or combined; other categories of middleboxes may also be found at such locations, possibly combined with the NATs and/or firewalls. NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the regular data path to the NSIS responder (NR). On the data path, NATFW NSLP signaling messages reach different NSIS nodes that implement the NATFW NSLP. Each NATFW NSLP node processes the signaling messages according to Section 3 and, if necessary, installs policy rules for subsequent data packets. Each of the following sub-sections introduces a different scenario for a different set of middleboxes and their ordering within the topology. It is assumed that each middlebox implements the NSIS NATFW NSLP signaling protocol.2.1. Firewall Traversal
This section describes a scenario with firewalls only; NATs are not involved. Each end host is behind a firewall. The firewalls are connected via the public Internet. Figure 2 shows the topology. The part labeled "public" is the Internet connecting both firewalls. +----+ //----\\ +----+ NI -----| FW |---| |------| FW |--- NR +----+ \\----// +----+ private public private FW: Firewall NI: NSIS Initiator NR: NSIS Responder Figure 2: Firewall Traversal Scenario Each firewall on the data path must provide traversal service for NATFW NSLP in order to permit the NSIS message to reach the other end host. All firewalls process NSIS signaling and establish appropriate policy rules, so that the required data packet flow can traverse them.
There are several very different ways to place firewalls in a network topology. To distinguish firewalls located at network borders, such as administrative domains, from others located internally, the term edge-firewall is used. A similar distinction can be made for NATs, with an edge-NAT fulfilling the equivalent role.2.2. NAT with Two Private Networks
Figure 3 shows a scenario with NATs at both ends of the network. Therefore, each application instance, the NSIS initiator and the NSIS responder, are behind NATs. The outermost NAT, known as the edge-NAT (MB2 and MB3), at each side is connected to the public Internet. The NATs are generically labeled as MBX (for middlebox No. X), since those devices certainly implement NAT functionality, but can implement firewall functionality as well. Only two middleboxes (MBs) are shown in Figure 3 at each side, but in general, any number of MBs on each side must be considered. +----+ +----+ //----\\ +----+ +----+ NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR +----+ +----+ \\----// +----+ +----+ private public private MB: Middlebox NI: NSIS Initiator NR: NSIS Responder Figure 3: NAT with two Private Networks Scenario Signaling traffic from the NI to the NR has to traverse all the middleboxes on the path (MB1 to MB4, in this order), and all the middleboxes must be configured properly to allow NSIS signaling to traverse them. The NATFW signaling must configure all middleboxes and consider any address translation that will result from this configuration in further signaling. The sender (NI) has to know the IP address of the receiver (NR) in advance, otherwise it will not be possible to send any NSIS signaling messages towards the responder. Note that this IP address is not the private IP address of the responder but the NAT's public IP address (here MB3's IP address). Instead, a NAT binding (including a public IP address) has to be previously installed on the NAT MB3. This NAT binding subsequently allows packets reaching the NAT to be forwarded to the receiver within the private address realm. The receiver might have a number of ways to learn its public IP address and port number (including the NATFW NSLP) and might need to signal this information to the sender using an application-level signaling protocol.
2.3. NAT with Private Network on Sender Side
This scenario shows an application instance at the sending node that is behind one or more NATs (shown as generic MB, see discussion in Section 2.2). The receiver is located in the public Internet. +----+ +----+ //----\\ NI --| MB |-----| MB |---| |--- NR +----+ +----+ \\----// private public MB: Middlebox NI: NSIS Initiator NR: NSIS Responder Figure 4: NAT with Private Network on Sender Side The traffic from NI to NR has to traverse middleboxes only on the sender's side. The receiver has a public IP address. The NI sends its signaling message directly to the address of the NSIS responder. Middleboxes along the path intercept the signaling messages and configure accordingly. The data sender does not necessarily know whether or not the receiver is behind a NAT; hence, it is the receiving side that has to detect whether or not it is behind a NAT.2.4. NAT with Private Network on Receiver Side Scenario
The application instance receiving data is behind one or more NATs shown as MB (see discussion in Section 2.2). //----\\ +----+ +----+ NI ---| |---| MB |-----| MB |--- NR \\----// +----+ +----+ public private MB: Middlebox NI: NSIS Initiator NR: NSIS Responder Figure 5: NAT with Private Network on Receiver Scenario Initially, the NSIS responder must determine its publicly reachable IP address at the external middlebox and notify the NSIS initiator about this address. One possibility is that an application-level
protocol is used, meaning that the public IP address is signaled via this protocol to the NI. Afterwards, the NI can start its signaling towards the NR and therefore establish the path via the middleboxes in the receiver side private network. This scenario describes the use case for the EXTERNAL message of the NATFW NSLP.2.5. Both End Hosts behind Twice-NATs
This is a special case, where the main problem arises from the need to detect that both end hosts are logically within the same address space, but are also in two partitions of the address realm on either side of a twice-NAT (see [RFC2663] for a discussion of twice-NAT functionality). Sender and receiver are both within a single private address realm, but the two partitions potentially have overlapping IP address ranges. Figure 6 shows the arrangement of NATs. public +----+ +----+ //----\\ NI --| MB |--+--| MB |---| | +----+ | +----+ \\----// | | +----+ +--| MB |------------ NR +----+ private MB: Middlebox NI: NSIS Initiator NR: NSIS Responder Figure 6: NAT to Public, Sender and Receiver on Either Side of a Twice-NAT Scenario The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP addresses and port numbers on both sides, meaning the mapping of source and destination IP addresses at the private and public interfaces. This scenario requires the assistance of application-level entities, such as a DNS server. The application-level entities must handle requests that are based on symbolic names and configure the middleboxes so that data packets are correctly forwarded from NI to
NR. The configuration of those middleboxes may require other middlebox communication protocols, such as MIDCOM [RFC3303]. NSIS signaling is not required in the twice-NAT only case, since middleboxes of the twice-NAT type are normally configured by other means. Nevertheless, NSIS signaling might be useful when there are also firewalls on the path. In this case, NSIS will not configure any policy rule at twice-NATs, but will configure policy rules at the firewalls on the path. The NSIS signaling protocol must be at least robust enough to survive this scenario. This requires that twice- NATs must implement the NATFW NSLP also and participate in NATFW signaling sessions, but they do not change the configuration of the NAT, i.e., they only read the address mapping information out of the NAT and translate the Message Routing Information (MRI, [RFC5971]) within the NSLP and NTLP accordingly. For more information, see Appendix D.4.2.6. Both End Hosts behind Same NAT
When the NSIS initiator and NSIS responder are behind the same NAT (thus, being in the same address realm, see Figure 7), they are most likely not aware of this fact. As in Section 2.4, the NSIS responder must determine its public IP address in advance and transfer it to the NSIS initiator. Afterwards, the NSIS initiator can start sending the signaling messages to the responder's public IP address. During this process, a public IP address will be allocated for the NSIS initiator at the same middlebox as for the responder. Now, the NSIS signaling and the subsequent data packets will traverse the NAT twice: from initiator to public IP address of responder (first time) and from public IP address of responder to responder (second time). NI public \ +----+ //----\\ +-| MB |----| | / +----+ \\----// NR private MB: Middlebox NI: NSIS Initiator NR: NSIS Responder Figure 7: NAT to Public, Both Hosts behind Same NAT
2.7. Multihomed Network with NAT
The previous sub-sections sketched network topologies where several NATs and/or firewalls are ordered sequentially on the path. This section describes a multihomed scenario with two NATs placed on alternative paths to the public network. +----+ //---\\ NI -------| MB |---| | \ +----+ \\-+-// \ | \ +----- NR \ | \ +----+ //-+-\\ --| MB |---| | +----+ \\---// private public MB: Middlebox NI: NSIS Initiator NR: NSIS Responder Figure 8: Multihomed Network with Two NATs Depending on the destination, either one or the other middlebox is used for the data flow. Which middlebox is used, depends on local policy or routing decisions. NATFW NSLP must be able to handle this situation properly, see Section 3.7.2 for an extended discussion of this topic with respect to NATs.2.8. Multihomed Network with Firewall
This section describes a multihomed scenario with two firewalls placed on alternative paths to the public network (Figure 9). The routing in the private and public networks decides which firewall is being taken for data flows. Depending on the data flow's direction, either outbound or inbound, a different firewall could be traversed. This is a challenge for the EXTERNAL message of the NATFW NSLP where the NSIS responder is located behind these firewalls within the private network. The EXTERNAL message is used to block a particular data flow on an inbound firewall. NSIS must route the EXTERNAL message inbound from NR to NI probably without knowing which path the data traffic will take from NI to NR (see also Appendix C).
+----+ NR -------| FW |\ \ +----+ \ //---\\ \ -| |-- NI \ \\---// \ +----+ | --| FW |-------+ +----+ private private public FW: Firewall NI: NSIS Initiator NR: NSIS Responder Figure 9: Multihomed Network with Two Firewalls3. Protocol Description
This section defines messages, objects, and protocol semantics for the NATFW NSLP.3.1. Policy Rules
Policy rules, bound to a NATFW NSLP signaling session, are the building blocks of middlebox devices considered in the NATFW NSLP. For firewalls, the policy rule usually consists of a 5-tuple and an action such as allow or deny. The information contained in the tuple includes source/destination IP addresses, transport protocol, and source/destination port numbers. For NATs, the policy rule consists of the action 'translate this address' and further mapping information, that might be, in the simplest case, internal IP address and external IP address. The NATFW NSLP carries, in conjunction with the NTLP's Message Routing Information (MRI), the policy rules to be installed at NATFW peers. This policy rule is an abstraction with respect to the real policy rule to be installed at the respective firewall or NAT. It conveys the initiator's request and must be mapped to the possible configuration on the particular used NAT and/or firewall in use. For pure firewalls, one or more filter rules must be created, and for pure NATs, one or more NAT bindings must be created. In mixed firewall and NAT boxes, the policy rule must be mapped to filter rules and bindings observing the ordering of the firewall and NAT engine. Depending on the ordering, NAT before firewall or vice
versa, the firewall rules must carry public or private IP addresses. However, the exact mapping depends on the implementation of the firewall or NAT that is possibly different for each implementation. The policy rule at the NATFW NSLP level comprises the message routing information (MRI) part, carried in the NTLP, and the information available in the NATFW NSLP. The information provided by the NSLP is stored in the 'extend flow information' (NATFW_EFI) and 'data terminal information' (NATFW_DTINFO) objects, and the message type. Additional information, such as the external IP address and port number, stored in the NAT or firewall, will be used as well. The MRI carries the filter part of the NAT/firewall-level policy rule that is to be installed. The NATFW NSLP specifies two actions for the policy rules: deny and allow. A policy rule with action set to deny will result in all packets matching this rule to be dropped. A policy rule with action set to allow will result in all packets matching this rule to be forwarded.3.2. Basic Protocol Overview
The NSIS NATFW NSLP is carried over the General Internet Signaling Transport (GIST, the implementation of the NTLP) defined in [RFC5971]. NATFW NSLP messages are initiated by the NSIS initiator (NI), handled by NSLP forwarders (NFs) and received by the NSIS responder (NR). It is required that at least NI and NR implement this NSLP, intermediate NFs only implement this NSLP when they provide relevant middlebox functions. NSLP forwarders that do not have any NATFW NSLP functions just forward these packets as they have no interest in them.3.2.1. Signaling for Outbound Traffic
A data sender (DS), intending to send data to a data receiver (DR), has to start NATFW NSLP signaling. This causes the NI associated with the DS to launch NSLP signaling towards the address of the DR (see Figure 10). Although it is expected that the DS and the NATFW NSLP NI will usually reside on the same host, this specification does not rule out scenarios where the DS and NI reside on different hosts, the so-called proxy mode (see Section 3.7.6).
+-------+ +-------+ +-------+ +-------+ | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | | |--->| NF1 |--->| NF2 |--->| | +-------+ +-------+ +-------+ +-------+ ========================================> Data Traffic Direction (outbound) ---> : NATFW NSLP request signaling ~~~> : NATFW NSLP response signaling DS/NI : Data sender and NSIS initiator DR/NR : Data receiver and NSIS responder MB1 : Middlebox 1 and NSLP forwarder 1 MB2 : Middlebox 2 and NSLP forwarder 2 Figure 10: General NSIS Signaling The following list shows the normal sequence of NSLP events without detailing the interaction with the NTLP and the interactions on the NTLP level. o NSIS initiators generate request messages (which are either CREATE or EXTERNAL messages) and send these towards the NSIS responder. This request message is the initial message that creates a new NATFW NSLP signaling session. The NI and the NR will most likely already share an application session before they start the NATFW NSLP signaling session. Note well the difference between both sessions. o NSLP request messages are processed each time an NF with NATFW NSLP support is traversed. Each NF that is intercepting a request message and is accepting it for further treatment is joining the particular NATFW NSLP signaling session. These nodes process the message, check local policies for authorization and authentication, possibly create policy rules, and forward the signaling message to the next NSIS node. The request message is forwarded until it reaches the NSIS responder. o NSIS responders will check received messages and process them if applicable. NSIS responders generate RESPONSE messages and send them hop-by-hop back to the NI via the same chain of NFs (traversal of the same NF chain is guaranteed through the established reverse message routing state in the NTLP). The NR is also joining the NATFW NSLP signaling session if the request message is accepted.
o The RESPONSE message is processed at each NF that has been
included in the prior NATFW NSLP signaling session setup.
o If the NI has received a successful RESPONSE message and if the
signaling NATFW NSLP session started with a CREATE message, the
data sender can start sending its data flow to the data receiver.
If the NI has received a successful RESPONSE message and if the
signaling NATFW NSLP session started with an EXTERNAL message, the
data receiver is ready to receive further CREATE messages.
Because NATFW NSLP signaling follows the data path from DS to DR,
this immediately enables communication between both hosts for
scenarios with only firewalls on the data path or NATs on the sender
side. For scenarios with NATs on the receiver side, certain problems
arise, as described in Section 2.4.
3.2.2. Signaling for Inbound Traffic
When the NR and the NI are located in different address realms and
the NR is located behind a NAT, the NI cannot signal to the NR
address directly. The DR/NR is not reachable from other NIs using
the private address of the NR and thus NATFW signaling messages
cannot be sent to the NR/DR's address. Therefore, the NR must first
obtain a NAT binding that provides an address that is reachable for
the NI. Once the NR has acquired a public IP address, it forwards
this information to the DS via a separate protocol. This
application-layer signaling, which is out of the scope of the NATFW
NSLP, may involve third parties that assist in exchanging these
messages.
The same holds partially true for NRs located behind firewalls that
block all traffic by default. In this case, NR must tell its inbound
firewalls of inbound NATFW NSLP signaling and corresponding data
traffic. Once the NR has informed the inbound firewalls, it can
start its application-level signaling to initiate communication with
the NI. This mechanism can be used by machines hosting services
behind firewalls as well. In this case, the NR informs the inbound
firewalls as described, but does not need to communicate this to the
NIs.
NATFW NSLP signaling supports this scenario by using the EXTERNAL
message.
1. The DR acquires a public address by signaling on the reverse path
(DR towards DS) and thus making itself available to other hosts.
This process of acquiring public addresses is called reservation.
During this process the DR reserves publicly reachable addresses
and ports suitable for further usage in application-level
signaling and the publicly reachable address for further NATFW
NSLP signaling. However, the data traffic will not be allowed to
use this address/port initially (see next point). In the process
of reservation, the DR becomes the NI for the messages necessary
to obtain the publicly reachable IP address, i.e., the NI for
this specific NATFW NSLP signaling session.
2. Now on the side of the DS, the NI creates a new NATFW NSLP
signaling session and signals directly to the public IP address
of the DR. This public IP address is used as NR's address, as
the NI would do if there is no NAT in between, and creates policy
rules at middleboxes. Note, that the reservation will only allow
forwarding of signaling messages, but not data flow packets.
Policy rules allowing forwarding of data flow packets set up by
the prior EXTERNAL message signaling will be activated when the
signaling from NI towards NR is confirmed with a positive
RESPONSE message. The EXTERNAL message is described in
Section 3.7.2.
3.2.3. Signaling for Proxy Mode
administrative domain
----------------------------------\
|
+-------+ +-------+ +-------+ | +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR |
| |--->| NF1 |--->| NR | | | |
+-------+ +-------+ +-------+ | +-------+
|
----------------------------------/
========================================>
Data Traffic Direction (outbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP responder
Figure 11: Proxy Mode Signaling for Data Sender
The above usage assumes that both ends of a communication support
NSIS, but fails when NSIS is only deployed at one end of the path.
In this case, only one of the sending side (see Figure 11) or
receiving side (see Figure 12) is NSIS aware and not both at the same
time. NATFW NSLP supports both scenarios (i.e., either the DS or DR does not support NSIS) by using a proxy mode, as described in Section 3.7.6. administrative domain / ---------------------------------- | +-------+ | +-------+ +-------+ +-------+ | DS | | | MB2/ |~~~>| MB1/ |~~~>| DR | | | | | NR |<---| NF1 |<---| | +-------+ | +-------+ +-------+ +-------+ | \---------------------------------- ========================================> Data Traffic Direction (inbound) ---> : NATFW NSLP request signaling ~~~> : NATFW NSLP response signaling DS/NI : Data sender and NSIS initiator DR/NR : Data receiver and NSIS responder MB1 : Middlebox 1 and NSLP forwarder 1 MB2 : Middlebox 2 and NSLP responder Figure 12: Proxy Mode Signaling for Data Receiver3.2.4. Blocking Traffic
The basic functionality of the NATFW NSLP provides for opening firewall pin holes and creating NAT bindings to enable data flows to traverse these devices. Firewalls are normally expected to work on a "deny-all" policy, meaning that traffic not explicitly matching any firewall filter rule will be blocked. Similarly, the normal behavior of NATs is to block all traffic that does not match any already configured/installed binding or NATFW NSLP session. However, some scenarios require support of firewalls having "allow-all" policies, allowing data traffic to traverse the firewall unless it is blocked explicitly. Data receivers can utilize NATFW NSLP's EXTERNAL message with action set to "deny" to install policy rules at inbound firewalls to block unwanted traffic.3.2.5. State and Error Maintenance
The protocol works on a soft-state basis, meaning that whatever state is installed or reserved on a middlebox will expire, and thus be uninstalled or forgotten after a certain period of time. To prevent premature removal of state that is needed for ongoing communication,
the NATFW NI involved will have to specifically request a NATFW NSLP signaling session extension. An explicit NATFW NSLP state deletion capability is also provided by the protocol. If the actions requested by a NATFW NSLP message cannot be carried out, NFs and the NR must return a failure, such that appropriate actions can be taken. They can do this either during the request message handling (synchronously) by sending an error RESPONSE message or at any time (asynchronously) by sending a NOTIFY notification message. The next sections define the NATFW NSLP message types and formats, protocol operations, and policy rule operations.3.2.6. Message Types
The protocol uses four messages types: o CREATE: a request message used for creating, changing, refreshing, and deleting NATFW NSLP signaling sessions, i.e., open the data path from DS to DR. o EXTERNAL: a request message used for reserving, changing, refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions. EXTERNAL messages are forwarded to the edge-NAT or edge-firewall and allow inbound CREATE messages to be forwarded to the NR. Additionally, EXTERNAL messages reserve an external address and, if applicable, port number at an edge-NAT. o NOTIFY: an asynchronous message used by NATFW peers to alert other NATFW peers about specific events (especially failures). o RESPONSE: used as a response to CREATE and EXTERNAL request messages.3.2.7. Classification of RESPONSE Messages
RESPONSE messages will be generated synchronously to CREATE and EXTERNAL messages by NSLP forwarders and responders to report success or failure of operations or some information relating to the NATFW NSLP signaling session or a node. RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE. All RESPONSE messages MUST carry a NATFW_INFO object that contains an error class code and a response code (see Section 4.2.5). This section defines terms for groups of RESPONSE messages depending on the error class.
o Successful RESPONSE: Messages carrying NATFW_INFO with error class
'Success' (2).
o Informational RESPONSE: Messages carrying NATFW_INFO with error
class 'Informational' (1) (only used with NOTIFY messages).
o Error RESPONSE: Messages carrying NATFW_INFO with error class
other than 'Success' or 'Informational'.
3.2.8. NATFW NSLP Signaling Sessions
A NATFW NSLP signaling session defines an association between the NI,
NFs, and the NR related to a data flow. This association is created
when the initial CREATE or EXTERNAL message is successfully received
at the NFs or the NR. There is signaling NATFW NSLP session state
stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP
signaling session state for the NATFW NSLP comprises NSLP state and
the associated policy rules at a middlebox.
The NATFW NSLP signaling session is identified by the session ID
(plus other information at the NTLP level). The session ID is
generated by the NI before the initial CREATE or EXTERNAL message is
sent. The value of the session ID MUST be generated as a
cryptographically random number (see [RFC4086]) by the NI, i.e., the
output MUST NOT be easily guessable by third parties. The session ID
is not stored in any NATFW NSLP message but passed on to the NTLP.
A NATFW NSLP signaling session has several conceptual states that
describe in what state a signaling session is at a given time. The
signaling session can have these states at a node:
o Pending: The NATFW NSLP signaling session has been created and the
node is waiting for a RESPONSE message to the CREATE or EXTERNAL
message. A NATFW NSLP signaling session in state 'Pending' MUST
be marked as 'Dead' if no corresponding RESPONSE message has been
received within the time of the locally granted NATFW NSLP
signaling session lifetime of the forwarded CREATE or EXTERNAL
message (as described in Section 3.4).
o Established: The NATFW NSLP signaling session is established, i.e,
the signaling has been successfully performed and the lifetime of
NATFW NSLP signaling session is counted from now on. A NATFW NSLP
signaling session in state 'Established' MUST be marked as 'Dead'
if no refresh message has been received within the time of the
locally granted NATFW NSLP signaling session lifetime of the
RESPONSE message (as described in Section 3.4).
o Dead: Either the NATFW NSLP signaling session is timed out or the
node has received an error RESPONSE message for the NATFW NSLP
signaling session and the NATFW NSLP signaling session can be
deleted.
o Transitory: The node has received an asynchronous message, i.e., a
NOTIFY, and can delete the NATFW NSLP signaling session if needed
after some time. When a node has received a NOTIFY message, it
marks the signaling session as 'Transitory'. This signaling
session SHOULD NOT be deleted before a minimum hold time of 30
seconds, i.e., it can be removed after 30 seconds or more. This
hold time ensures that the existing signaling session can be
reused by the NI, e.g., a part of a signaling session that is not
affected by the route change can be reused once the updating
request message is received.
3.3. Basic Message Processing
All NATFW messages are subject to some basic message processing when
received at a node, independent of the message type. Initially, the
syntax of the NSLP message is checked and a RESPONSE message with an
appropriate error of class 'Protocol error' (3) code is generated if
a non-recoverable syntax error is detected. A recoverable error is,
for instance, when a node receives a message with reserved flags set
to values other than zero. This also refers to unknown NSLP objects
and their handling, according to Section 4.2. If a message is
delivered to the NATFW NSLP, this implies that the NTLP layer has
been able to correlate it with the session ID (SID) and MRI entries
in its database. There is therefore enough information to identify
the source of the message and routing information to route the
message back to the NI through an established chain of NTLP messaging
associations. The message is not further forwarded if any error in
the syntax is detected. The specific response codes stemming from
the processing of objects are described in the respective object
definition section (see Section 4). After passing this check, the
NATFW NSLP node performs authentication- and authorization-related
checks, described in Section 3.6. Further processing is executed
only if these tests have been successfully passed; otherwise, the
processing stops and an error RESPONSE is returned.
Further message processing stops whenever an error RESPONSE message
is generated, and the EXTERNAL or CREATE message is discarded.
3.4. Calculation of Signaling Session Lifetime
NATFW NSLP signaling sessions, and the corresponding policy rules
that may have been installed, are maintained via a soft-state
mechanism. Each signaling session is assigned a signaling session
lifetime and the signaling session is kept alive as long as the lifetime is valid. After the expiration of the signaling session lifetime, signaling sessions and policy rules MUST be removed automatically and resources bound to them MUST be freed as well. Signaling session lifetime is handled at every NATFW NSLP node. The NSLP forwarders and NSLP responder MUST NOT trigger signaling session lifetime extension refresh messages (see Section 3.7.3): this is the task of the NSIS initiator. The NSIS initiator MUST choose a NATFW NSLP signaling session lifetime value (expressed in seconds) before sending any message, including the initial message that creates the NATFW NSLP signaling session, to other NSLP nodes. It is RECOMMENDED that the NATFW NSLP signaling session lifetime value is calculated based on: o the number of lost refresh messages with which NFs should cope; o the end-to-end delay between the NI and NR; o network vulnerability due to NATFW NSLP signaling session hijacking ([RFC4081]), NATFW NSLP signaling session hijacking is made easier when the NI does not explicitly remove the NATFW NSLP signaling session; o the user application's data exchange duration, in terms of time and networking needs. This duration is modeled as R, with R the message refresh period (in seconds); o the load on the signaling plane. Short lifetimes imply more frequent signaling messages; o the acceptable time for a NATFW NSLP signaling session to be present after it is no longer actually needed. For example, if the existence of the NATFW NSLP signaling session implies a monetary cost and teardown cannot be guaranteed, shorter lifetimes would be preferable; o the lease time of the NI's IP address. The lease time of the IP address must be longer than the chosen NATFW NSLP signaling session lifetime; otherwise, the IP address can be re-assigned to a different node. This node may receive unwanted traffic, although it never has requested a NAT/firewall configuration, which might be an issue in environments with mobile hosts. The RSVP specification [RFC2205] provides an appropriate algorithm for calculating the NATFW NSLP signaling session lifetime as well as a means to avoid refresh message synchronization between NATFW NSLP signaling sessions. [RFC2205] recommends:
1. The refresh message timer to be randomly set to a value in the
range [0.5R, 1.5R].
2. To avoid premature loss of state, lt (with lt being the NATFW
NSLP signaling session lifetime) must satisfy lt >= (K +
0.5)*1.5*R, where K is a small integer. Then, in the worst case,
K-1 successive messages may be lost without state being deleted.
Currently, K = 3 is suggested as the default. However, it may be
necessary to set a larger K value for hops with high loss rate.
Other algorithms could be used to define the relation between the
NATFW NSLP signaling session lifetime and the refresh message
period; the algorithm provided is only given as an example.
It is RECOMMENDED to use a refresh timer of 300 s (5 minutes), unless
the NI or the requesting application at the NI has other requirements
(e.g., flows lasting a very short time).
This requested NATFW NSLP signaling session lifetime value lt is
stored in the NATFW_LT object of the NSLP message.
NSLP forwarders and the NSLP responder can execute the following
behavior with respect to the requested lifetime handling:
Requested signaling session lifetime acceptable:
No changes to the NATFW NSLP signaling session lifetime values are
needed. The CREATE or EXTERNAL message is forwarded, if
applicable.
Signaling session lifetime can be lowered:
An NSLP forwarded or the NSLP responder MAY also lower the
requested NATFW NSLP signaling session lifetime to an acceptable
value (based on its local policies). If an NF changes the NATFW
NSLP signaling session lifetime value, it MUST store the new value
in the NATFW_LT object. The CREATE or EXTERNAL message is
forwarded.
Requested signaling session lifetime is too big:
An NSLP forwarded or the NSLP responder MAY reject the requested
NATFW NSLP signaling session lifetime value as being too big and
MUST generate an error RESPONSE message of class 'Signaling
session failure' (7) with response code 'Requested lifetime is too
big' (0x02) upon rejection. Lowering the lifetime is preferred
instead of generating an error message.
Requested signaling session lifetime is too small:
An NSLP forwarded or the NSLP responder MAY reject the requested
NATFW NSLP signaling session lifetime value as being to small and
MUST generate an error RESPONSE message of class 'Signaling
session failure' (7) with response code 'Requested lifetime is too
small' (0x10) upon rejection.
NFs or the NR MUST NOT increase the NATFW NSLP signaling session
lifetime value. Messages can be rejected on the basis of the NATFW
NSLP signaling session lifetime being too long when a NATFW NSLP
signaling session is first created and also on refreshes.
The NSLP responder generates a successful RESPONSE for the received
CREATE or EXTERNAL message, sets the NATFW NSLP signaling session
lifetime value in the NATFW_LT object to the above granted lifetime
and sends the message back towards NSLP initiator.
Each NSLP forwarder processes the RESPONSE message and reads and
stores the granted NATFW NSLP signaling session lifetime value. The
forwarders MUST accept the granted NATFW NSLP signaling session
lifetime, if the lifetime value is within the acceptable range. The
acceptable value refers to the value accepted by the NSLP forwarder
when processing the CREATE or EXTERNAL message. For received values
greater than the acceptable value, NSLP forwarders MUST generate a
RESPONSE message of class 'Signaling session failure' (7) with
response code 'Modified lifetime is too big' (0x11), including a
Signaling Session Lifetime object that carries the maximum acceptable
signaling session lifetime for this node. For received values lower
than the values acceptable by the node local policy, NSLP forwarders
MUST generate a RESPONSE message of class 'Signaling session failure'
(7) with response code 'Modified lifetime is too small' (0x12),
including a Signaling Session Lifetime object that carries the
minimum acceptable signaling session lifetime for this node. In both
cases, either 'Modified lifetime is too big' (0x11) or 'Modified
lifetime is too small' (0x12), the NF MUST generate a NOTIFY message
and send it outbound with the error class set to 'Informational' (1)
and with the response code set to 'NATFW signaling session
terminated' (0x05).
Figure 13 shows the procedure with an example, where an initiator
requests 60 seconds lifetime in the CREATE message and the lifetime
is shortened along the path by the forwarder to 20 seconds and by the
responder to 15 seconds. When the NSLP forwarder receives the
RESPONSE message with a NATFW NSLP signaling session lifetime value
of 15 seconds it checks whether this value is lower or equal to the
acceptable value.
+-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ | |---------------->| NSLP |---------------->| | | NI | | forwarder | | NR | | |<----------------| check 15<20 |<----------------| | +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ lt = lifetime Figure 13: Signaling Session Lifetime Setting Example
(page 31 continued on part 3)