NSIS Working Group M. Stiemerling Internet-Draft NEC Intended status: Standards Track H. Tschofenig Expires: August 18, 2008 Nokia Siemens Networks C. Aoun E. Davies Folly Consulting February 15, 2008 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) draft-ietf-nsis-nslp-natfw-18.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Stiemerling, et al. Expires August 18, 2008 [Page 1] Internet-Draft NAT/FW NSIS NSLP February 2008 Abstract This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 8 1.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 1.4. General Scenario for NATFW Traversal . . . . . . . . . . . 11 2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 13 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13 2.2. NAT with two private Networks . . . . . . . . . . . . . . 14 2.3. NAT with Private Network on Sender Side . . . . . . . . . 15 2.4. NAT with Private Network on Receiver Side Scenario . . . . 15 2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . . 16 2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 17 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 19 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 20 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21 3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 21 3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 22 3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 23 3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 25 3.2.5. State and Error Maintenance . . . . . . . . . . . . . 25 3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 26 3.2.7. Classification of RESPONSE Messages . . . . . . . . . 26 3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 27 3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 28 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 28 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 31 3.6. Authentication, Authorization, and Policy Decisions . . . 32 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 33 Stiemerling, et al. Expires August 18, 2008 [Page 2] Internet-Draft NAT/FW NSIS NSLP February 2008 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 33 3.7.2. Reserving External Addresses . . . . . . . . . . . . . 36 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 43 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 44 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 46 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 47 3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 51 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 53 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 53 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 55 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 55 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 56 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 57 4.2.2. External Address Object . . . . . . . . . . . . . . . 57 4.2.3. Extended Flow Information Object . . . . . . . . . . . 58 4.2.4. Information Code Object . . . . . . . . . . . . . . . 59 4.2.5. Nonce Object . . . . . . . . . . . . . . . . . . . . . 62 4.2.6. Message Sequence Number Object . . . . . . . . . . . . 62 4.2.7. Data Terminal Information Object . . . . . . . . . . . 63 4.2.8. ICMP Types Object . . . . . . . . . . . . . . . . . . 64 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 65 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 66 4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 66 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 67 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 69 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 69 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 69 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 70 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 71 5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 72 5.2.1. Security Protection between neighboring NATFW NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . . . 72 5.2.2. Security Protection between non-neighboring NATFW NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 73 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 79 Stiemerling, et al. Expires August 18, 2008 [Page 3] Internet-Draft NAT/FW NSIS NSLP February 2008 Appendix A. Selecting Signaling Destination Addresses for EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 81 Appendix B. Applicability Statement on Data Receivers behind Firewalls . . . . . . . . . . . . . . . . . . . . . . 82 Appendix C. Firewall and NAT Resources . . . . . . . . . . . . . 84 C.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 84 C.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 84 C.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 85 C.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 85 Appendix D. Protocols Numbers for Testing . . . . . . . . . . . . 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 Intellectual Property and Copyright Statements . . . . . . . . . . 89 Stiemerling, et al. Expires August 18, 2008 [Page 4] Internet-Draft NAT/FW NSIS NSLP February 2008 1. Introduction 1.1. Scope and Background Firewalls and Network Address Translators (NAT) have both been used throughout the Internet for many years, and they will remain present for the foreseeable future. Firewalls are used to protect networks against certain types of attacks from internal networks and the Internet, whereas NATs provide a virtual extension of the IP address space. Both types of devices may be obstacles to some applications, since they only allow traffic created by a limited set of applications to traverse them, typically those that use protocols with relatively predetermined and static properties (e.g., most HTTP traffic, and other client/server applications). Other applications, such as IP telephony and most other peer-to-peer applications, which have more dynamic properties, create traffic that is unable to traverse NATs and firewalls unassisted. In practice, the traffic of many applications cannot traverse autonomous firewalls or NATs, even when they have additional functionality which attempts to restore the transparency of the network. Several solutions to enable applications to traverse such entities have been proposed and are currently in use. Typically, application level gateways (ALG) have been integrated with the firewall or NAT to configure the firewall or NAT dynamically. Another approach is middlebox communication (MIDCOM). In this approach, ALGs external to the firewall or NAT configure the corresponding entity via the MIDCOM protocol [7]. Several other work-around solutions are available, such as STUN [14]. However, all of these approaches introduce other problems that are generally hard to solve, such as dependencies on the type of NAT implementation (full-cone, symmetric, etc), or dependencies on certain network topologies. NAT and firewall (NATFW) signaling shares a property with Quality of Service (QoS) signaling. The signaling of both must reach any device on the data path that is involved in, respectively, NATFW or QoS treatment of data packets. This means, that for both, NATFW and QoS, it is convenient if signaling travels path-coupled, meaning that the signaling messages follow exactly the same path that the data packets take. RSVP [11] is an example of a current QoS signaling protocol that is path-coupled. [19] proposes the use of RSVP as firewall signaling protocol but does not include NATs. This memo defines a path-coupled signaling protocol for NAT and firewall configuration within the framework of NSIS, called the NATFW NSIS Signaling Layer Protocol (NSLP). The general requirements for NSIS are defined in [5] and the general framework of NSIS is outlined in [4]. It introduces the split between an NSIS transport layer and Stiemerling, et al. Expires August 18, 2008 [Page 5] Internet-Draft NAT/FW NSIS NSLP February 2008 an NSIS signaling layer. The transport of NSLP messages is handled by an NSIS Network Transport Layer Protocol (NTLP, with General Internet Signaling Transport (GIST) [2] being the implementation of the abstract NTLP). The signaling logic for QoS and NATFW signaling is implemented in the different NSLPs. The QoS NSLP is defined in [6]. The NATFW NSLP is designed to request the dynamic configuration of NATs and/or firewalls along the data path. Dynamic configuration includes enabling data flows to traverse these devices without being obstructed, as well as blocking of particular data flows at inbound firewalls. Enabling data flows requires the loading of firewall rules with an action that allows the data flow packets to be forwarded and creating NAT bindings. Blocking of data flows requires the loading of firewalls rules with an action that will deny forwarding of the data flow packets. A simplified example for enabling data flows: A source host sends a NATFW NSLP signaling message towards its data destination. This message follows the data path. Every NATFW NSLP-enabled NAT/firewall along the data path intercepts this message, processes them, and configures itself accordingly. Thereafter, the actual data flow can traverse all these configured firewalls/NATs. It is necessary to distinguish between two different basic scenarios when operating the NATFW NSLP, independent of the type of the middleboxes to be configured. 1. Both, data sender and data receiver, are NSIS NATFW NSLP aware. This includes the cases where the data sender is logically decomposed from the initiator of the NSIS signaling (the so- called NSIS initiator) or the data receiver logically decomposed from the receiver of the NSIS signaling (the so-called NSIS receiver), but both sides support NSIS. This scenario assumes deployment of NSIS all over the Internet, or at least at all NATs and firewalls. This scenario is used as base assumption, if not otherwise noted. 2. Only one end host or region of the network is NSIS NATFW NSLP aware, either data receiver or data sender. This scenario is referred to as proxy mode. The NATFW NSLP has two basic signaling messages which are sufficient to cope with the various possible scenarios likely to be encountered before and after widespread deployment of NSIS: CREATE message: Send by the data sender for configuring a path outbound from a data sender to a data receiver. Stiemerling, et al. Expires August 18, 2008 [Page 6] Internet-Draft NAT/FW NSIS NSLP February 2008 EXTERNAL message: Used by data receiver to locate inbound NATs/ firewalls and prime them to expect outbound signaling and at NATs to pre-allocate a public address. This is used for data receivers behind these devices to enable their reachability. CREATE and EXTERNAL messages are sent by the NSIS initiator (NI) towards the NSIS responder (NR). Both type of messages are acknowledged by a subsequent RESPONSE message. This RESPONSE message is generated by the NR if the requested configuration can be established, otherwise the NR or any of the NSIS forwarders (NFs) can also generate such a message if an error occurs. NFs and the NR can also generate asynchronous messages to notify the NI, the so called NOTIFY messages. If the data receiver resides in a private addressing realm or behind a firewall, and needs to preconfigure the edge-NAT/edge-firewall to provide a (publicly) reachable address for use by the data sender, a combination of EXTERNAL and CREATE messages is used. During the introduction of NSIS, it is likely that one or the other of the data sender and receiver will not be NSIS aware. In these cases, the NATFW NSLP can utilize NSIS aware middleboxes on the path between the data sender and data receiver to provide proxy NATFW NSLP services (i.e., the proxy mode). Typically, these boxes will be at the boundaries of the realms in which the end hosts are located. The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in NSIS entities. NTLP state allows signaling messages to travel in the forward (outbound) and the reverse (inbound) direction along the path between a NAT/firewall NSLP sender and a corresponding receiver. This state is managed using a soft-state mechanism, i.e., it expires unless it is refreshed from time to time. The NAT bindings and firewall rules being installed during the state setup are bound to the particular signaling session. However, the exact local implementation of the NAT bindings and firewall rules are NAT/ firewall specific and it is out of scope of this memo. This memo is structured as follows. Section 2 describes the network environment for NATFW NSLP signaling. Section 3 defines the NATFW signaling protocol and Section 4 defines the message components and the overall messages used in the protocol. The remaining parts of the main body of the document cover security considerations Section 5, IAB considerations on UNilateral Self-Address Fixing (UNSAF) [12] in Section 6 and IANA considerations in Section 7. Please note that readers familiar with firewalls and NATs and their possible location within networks can safely skip Section 2. Stiemerling, et al. Expires August 18, 2008 [Page 7] Internet-Draft NAT/FW NSIS NSLP February 2008 1.2. Terminology and Abbreviations The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. This document uses a number of terms defined in [5] and [4]. The following additional terms are used: o Policy rule: A policy rule is "a basic building block of a policy- based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed" [15]. In the context of NSIS NATFW NSLP, the conditions are the specification of a set of packets to which the rule is applied. The set of actions always contains just a single element per rule, and is limited to either action "deny" or action "allow". o Reserved policy rule: A policy rule stored at NATs or firewalls for activation by a later, different signaling exchange. This type of policy rule is kept in the NATFW NSLP and is not loaded into the firewall or NAT engine, i.e., it does not affect the data flow handling. o Installed policy rule: A policy rule in operation at NATs or firewalls. This type of rule is kept in the NATFW NSLP and is loaded into the firewall or NAT engine, i.e., it is affecting the data flow. o Remembered policy rule: A policy rule stored at NATs and firewalls for immediate use, as soon as the signaling exchange is successfully completed. o Firewall: A packet filtering device that matches packets against a set of policy rules and applies the actions. o Network Address Translator: Network Address Translation is a method by which IP addresses are mapped from one IP address realm to another, in an attempt to provide transparent routing between hosts (see [9]). Network Address Translators are devices that perform this work by modifying packets passing through them. o Data Receiver (DR): The node in the network that is receiving the data packets of a flow. o Data Sender (DS): The node in the network that is sending the data packets of a flow. Stiemerling, et al. Expires August 18, 2008 [Page 8] Internet-Draft NAT/FW NSIS NSLP February 2008 o NATFW NSLP peer or peer: An NSIS NATFW NSLP node with which an NTLP adjacency has been created as defined in [2]. o NATFW NSLP signaling session or signaling session: A signaling session defines an association between the NI, NFs, and the NR related to a data flow. All the NATFW NSLP peers on the path, including the NI and the NR, use the same identifier to refer to the state stored for the association. The same NI and NR may have more than one signaling session active at any time. The state for NATFW NSLP consists of NSLP state and associated policy rules at a middlebox. o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP address which is reachable from the public Internet. o Edge-firewall: An edge-firewall is a firewall device that is located on the border line of an administrative domain. o Public Network: "A Global or Public Network is an address realm with unique network addresses assigned by Internet Assigned Numbers Authority (IANA) or an equivalent address registry. This network is also referred as external network during NAT discussions" [9]. o Private/Local Network: "A private network is an address realm independent of external network addresses. Private network may also be referred alternately as Local Network. Transparent routing between hosts in private realm and external realm is facilitated by a NAT router" [9]. o Public/Global IP address: An IP address located in the public network according to Section 2.7 of [9]. o Private/Local IP address: An IP address located in the private network according to Section 2.8 of [9]. o Signaling Destination Address (SDA): An IP address generally taken from the public/global IP address range, although, the SDA may in certain circumstances be part of the private/local IP address range. This address is used in EXTERNAL signaling message exchanges, if the data receiver's IP address is unknown. 1.3. Middleboxes The term middlebox covers a range of devices and is well-defined in [10]: "A middlebox is defined as any intermediate device performing functions other than the normal, standard functions of an IP router on the datagram path between source host and a destination host". As Stiemerling, et al. Expires August 18, 2008 [Page 9] Internet-Draft NAT/FW NSIS NSLP February 2008 such, middleboxes fall into a number of categories with a wide range of functionality, not all of which is pertinent to the NATFW NSLP. Middlebox categories in the scope of this memo are firewalls that filter data packets against a set of filter rules, and NATs that translate packet addresses from one address realm to another address realm. Other categories of middleboxes, such as QoS traffic shapers, are out of scope of this memo. The term NAT used in this document is a placeholder for a range of different NAT flavors. We consider the following types of NATs: o Traditional NAT (basic NAT and NAPT) o Bi-directional NAT o Twice-NAT o Multihomed NAT For definitions and a detailed discussion about the characteristics of each NAT type please see [9]. All types of middleboxes under consideration here, use policy rules to make a decision on data packet treatment. Policy rules consist of a flow identifier which selects the packets to which the policy applies and an associated action; data packets matching the flow identifier are subjected to the policy rule action. A typical flow identifier is the 5-tuple selector which matches the following fields of a packet to configured values: o Source and destination IP addresses o Transport protocol number o Transport source and destination port numbers Actions for firewalls are usually one or more of: o Allow: forward data packet o Deny: block data packet and discard it o Other actions such as logging, diverting, duplicating, etc Actions for NATs include (amongst many others): o Change source IP address and transport port number to a globally routable IP address and associated port number. Stiemerling, et al. Expires August 18, 2008 [Page 10] Internet-Draft NAT/FW NSIS NSLP February 2008 o Change destination IP address and transport port number to a private IP address and associated port number. It should be noted that a middlebox may contain two logical representations of the policy rule. The policy rule has a representation within the NATFW NSLP, comprising the message routing information (MRI) of the NTLP and NSLP information (such as the rule action). The other representation is the implementation of the NATFW NSLP policy rule within the NAT and firewall engine of the particular device. Refer to Appendix C for further details. 1.4. General Scenario for NATFW Traversal The purpose of NSIS NATFW signaling is to enable communication between endpoints across networks, even in the presence of NAT and firewall middleboxes that have not been specially engineered to facilitate communication with the application protocols used. This removes the need to create and maintain application layer gateways for specific protocols that have been commonly used to provide transparency in previous generations of NAT and firewall middleboxes. It is assumed that these middleboxes will be statically configured in such a way that NSIS NATFW signaling messages themselves are allowed to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP signaling is used to dynamically install additional policy rules in all NATFW middleboxes along the data path that will allow transmission of the application data flow(s). Firewalls are configured to forward data packets matching the policy rule provided by the NSLP signaling. NATs are configured to translate data packets matching the policy rule provided by the NSLP signaling. An additional capability, that is an exception to the primary goal of NSIS NATFW signaling, is that the NATFW nodes can request blocking of particular data flows instead of enabling these flows at inbound firewalls. The basic high-level picture of NSIS usage is that end hosts are located behind middleboxes, meaning that there is at least one middlebox on the data path from the end host in a private network to the external network (NATFW in Figure 1). Applications located at these end hosts try to establish communication with corresponding applications on other such end hosts. They trigger the NSIS entity at the local host to control provisioning for middlebox traversal along the prospective data path (e.g., via an API call). The NSIS entity in turn uses NSIS NATFW NSLP signaling to establish policy rules along the data path, allowing the data to travel from the sender to the receiver unobstructed. Stiemerling, et al. Expires August 18, 2008 [Page 11] Internet-Draft NAT/FW NSIS NSLP February 2008 Application Application Server (0, 1, or more) Application +----+ +----+ +----+ | +------------------------+ +------------------------+ | +-+--+ +----+ +-+--+ | | | NSIS Entities NSIS Entities | +-+--+ +----+ +-----+ +-+--+ | +--------+ +----------------------------+ +-----+ | +-+--+ +-+--+ +--+--+ +-+--+ | | ------ | | | | //// \\\\\ | | +-+--+ +-+--+ |/ | +-+--+ +-+--+ | | | | | Internet | | | | | | +--------+ +-----+ +----+ +-----+ | +----+ +----+ |\ | +----+ +----+ \\\\ ///// sender NATFW (1+) ------ NATFW (1+) receiver Note that 1+ refers to one or more NATFW nodes. Figure 1: Generic View of NSIS with NATs and/or firewalls For end-to-end NATFW signaling, it is necessary that each firewall and each NAT along the path between the data sender and the data receiver implements the NSIS NATFW NSLP. There might be several NATs and FWs in various possible combinations on a path between two hosts. Section 2 presents a number of likely scenarios with different combinations of NATs and firewalls. However, the scenarios given in the following sections are not limiting the scope of the NATFW NSLP to them only, but they are examples only. Stiemerling, et al. Expires August 18, 2008 [Page 12] Internet-Draft NAT/FW NSIS NSLP February 2008 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 they may be 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 Stiemerling, et al. Expires August 18, 2008 [Page 13] Internet-Draft NAT/FW NSIS NSLP February 2008 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 MB 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 NI to 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. Stiemerling, et al. Expires August 18, 2008 [Page 14] Internet-Draft NAT/FW NSIS NSLP February 2008 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 the 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 the a accordingly. The data sender does not necessarily know whether the receiver is behind a NAT or not, hence, it is the receiving side that has to detect whether itself is behind a NAT or not. 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). Stiemerling, et al. Expires August 18, 2008 [Page 15] Internet-Draft NAT/FW NSIS NSLP February 2008 //----\\ +----+ +----+ 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 [9] 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. Stiemerling, et al. Expires August 18, 2008 [Page 16] Internet-Draft NAT/FW NSIS NSLP February 2008 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 address 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 [7]. 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, [2]) within the NSLP and NTLP accordingly. For more information see Appendix C.4 2.6. Both End Hosts Behind Same NAT When 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 Stiemerling, et al. Expires August 18, 2008 [Page 17] Internet-Draft NAT/FW NSIS NSLP February 2008 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 Stiemerling, et al. Expires August 18, 2008 [Page 18] Internet-Draft NAT/FW NSIS NSLP February 2008 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 network 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 B). +----+ NR -------| FW |\ \ +----+ \ //---\\ \ -| |-- NI \ \\---// \ +----+ | --| FW |-------+ +----+ private private public FW: Firewall NI: NSIS Initiator NR: NSIS Responder Figure 9: Multihomed Network with two firewalls Stiemerling, et al. Expires August 18, 2008 [Page 19] Internet-Draft NAT/FW NSIS NSLP February 2008 3. 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 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 which 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. Stiemerling, et al. Expires August 18, 2008 [Page 20] Internet-Draft NAT/FW NSIS NSLP February 2008 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 [2]. NATFW NSLP messages are initiated by the NSIS initiator (NI), handled by NSIS forwarders (NF) 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. NSIS 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 data sender (DS) to launch NSLP signaling towards the address of data receiver (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 NSIS forwarder 1 MB2 : Middlebox 2 and NSIS 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 the NTLP level. o NSIS initiators generate NATFW NSLP CREATE/EXTERNAL messages and send these towards the NSIS responder. This CREATE/EXTERNAL message is the initial message which creates a new NATFW NSLP Stiemerling, et al. Expires August 18, 2008 [Page 21] Internet-Draft NAT/FW NSIS NSLP February 2008 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 CREATE/EXTERNAL messages are processed each time a NF with NATFW NSLP support is traversed. Each NF that is intercepting a CREATE/EXTERNAL 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 CREATE/ EXTERNAL 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 a 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 Stiemerling, et al. Expires August 18, 2008 [Page 22] Internet-Draft NAT/FW NSIS NSLP February 2008 layer signaling, which is out of 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 DS, the NI creates a new NATFW NSLP signaling session and signals directly to the public IP address of 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 Stiemerling, et al. Expires August 18, 2008 [Page 23] Internet-Draft NAT/FW NSIS NSLP February 2008 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 NSIS forwarder 1 MB2 : Middlebox 2 and NSIS 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 Figure 11 or receiving Figure 12 side is NSIS aware and not both at the same time. NATFW NSLP supports both scenarios (i.e., either the DS or DR do not support NSIS) by using a proxy mode, as described in Section 3.7.6 Stiemerling, et al. Expires August 18, 2008 [Page 24] Internet-Draft NAT/FW NSIS NSLP February 2008 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 NSIS forwarder 1 MB2 : Middlebox 2 and NSIS responder Figure 12: proxy mode signaling for data receiver 3.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 de- installed 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. Stiemerling, et al. Expires August 18, 2008 [Page 25] Internet-Draft NAT/FW NSIS NSLP February 2008 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 a 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 NSIS 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 which contains a severity class code and a response code (see Section 4.2.4). This section defines terms for groups of RESPONSE messages depending on the severity class. o Successful RESPONSE: Messages carrying NATFW_INFO with severity class 'Success' (0x2). Stiemerling, et al. Expires August 18, 2008 [Page 26] Internet-Draft NAT/FW NSIS NSLP February 2008 o Informational RESPONSE: Messages carrying NATFW_INFO with severity class 'Informational' (0x1) (only used with NOTIFY messages). o Error RESPONSE: Messages carrying NATFW_INFO with severity 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 generated in a random way, 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 can conceptually be in different states, implementations may use other or even more states. 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. Stiemerling, et al. Expires August 18, 2008 [Page 27] Internet-Draft NAT/FW NSIS NSLP February 2008 o Transit: 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 'transit'. This signaling session SHOULD NOT be deleted before a minimum hold time of 30 second, i.e., it can be removed after 30 seconds or more. 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' (0x3) code is generated if any problem is detected. If a message is delivered to the NATFW NSLP, this implies that the NTLP layer has been able to correlate it with the 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/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 which 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 which creates the NATFW NSLP signaling Stiemerling, et al. Expires August 18, 2008 [Page 28] Internet-Draft NAT/FW NSIS NSLP February 2008 session, to other NSLP nodes. The NATFW NSLP signaling session lifetime value is calculated based on: o the number of lost refresh messages that NFs should cope with; o the end-to-end delay between the NI and NR; o network vulnerability due to NATFW NSLP signaling session hijacking ([8]), 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 larger than 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 [11] provides an appropriate algorithm for calculating the NATFW NSLP signaling session lifetime as well as means to avoid refresh message synchronization between NATFW NSLP signaling sessions. [11] 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 Stiemerling, et al. Expires August 18, 2008 [Page 29] Internet-Draft NAT/FW NSIS NSLP February 2008 period; the algorithm provided is only given as an example. 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' (0x6) 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' (0x6) 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. Stiemerling, et al. Expires August 18, 2008 [Page 30] Internet-Draft NAT/FW NSIS NSLP February 2008 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, 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' (0x6) with response code 'Modified lifetime is too big' (0x11). 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' (0x6) with response code 'Modified lifetime is too small' (0x12). 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 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 either old messages that have been received before (duplicated), or the case that messages have been 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 Stiemerling, et al. Expires August 18, 2008 [Page 31] Internet-Draft NAT/FW NSIS NSLP February 2008 sequence number (MSN), see also Section 4.2.6. 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 [3] to detect MSN wrap-arounds. NSIS forwarders and the responder store the MSN from the initial CREATE or EXTERNAL packet which 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 to 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 Stiemerling, et al. Expires August 18, 2008 [Page 32] Internet-Draft NAT/FW NSIS NSLP February 2008 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' (0x5) 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. 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 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 NSIS forwarder along the path that implements NATFW NSLP, processes the NSLP message. Forwarding is done hop-by-hop but may pass transparently through NSIS forwarders which 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 NI (DS in this example), a NF (e.g., NAT), and NR (DR in this example). NI Private Network NF Public Internet NR | | | | CREATE | | |----------------------------->| | | | | | | | | | CREATE | | |--------------------------->| | | | | | RESPONSE | | RESPONSE |<---------------------------| |<-----------------------------| | | | | | | | Figure 14: CREATE message flow with success RESPONSE Stiemerling, et al. Expires August 18, 2008 [Page 33] Internet-Draft NAT/FW NSIS NSLP February 2008 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 session, 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 message, 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 it. 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' (0x6) with response code 'Did not reach the NR' (0x07). This case may occur if the NTLP layer cannot find an NATFW NSLP peer, either another NF or the NR, and returns an error via the GIST API. 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 a 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' (0x6) 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 address of the policy rule ('the remembered policy rule') to be loaded and forwards the message with the destination address set to the internal (private in most cases) address of NR. When the initial CREATE message is received at the private side, the NAT binding is allocated, but not activated (see also Appendix C.3). An error RESPONSE message Stiemerling, et al. Expires August 18, 2008 [Page 34] Internet-Draft NAT/FW NSIS NSLP February 2008 is generated, if the requested policy rule cannot be installed later on, with of class 'Signaling session failure' (0x6) 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 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. An error RESPONSE message is generated, if the requested policy rule cannot be installed later on, with of class 'Signaling session failure' (0x6) 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' (0x2) 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. Stiemerling, et al. Expires August 18, 2008 [Page 35] Internet-Draft NAT/FW NSIS NSLP February 2008 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 for understanding 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 behind just 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 which 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 a EXTERNAL message in the Stiemerling, et al. Expires August 18, 2008 [Page 36] Internet-Draft NAT/FW NSIS NSLP February 2008 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 Stiemerling, et al. Expires August 18, 2008 [Page 37] Internet-Draft NAT/FW NSIS NSLP February 2008 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, 2. or the address of 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 [2]) with the direction set to 'upstream' (inbound). The handling of case 2 depends on the situation of DR: If DR is solely located behind a firewall, the EXTERNAL message MUST be sent with the PC-MRM, direction 'upstream' (inbound), and data flow source IP address set to wildcard. If 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 [2]), the destination-address set to the signaling destination address (SDA, see also Appendix A). For scenarios with DR being behind a firewall, special conditions apply (see applicability statement in Appendix B). The data receiver is challenged to determine whether it is solely located behind firewalls or NATs, for choosing 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. It is RECOMMENDED to use the PC-MRM with the known data sender's IP address. This gives GIST the best possible handled to route the message 'upstream' (outbound). It is RECOMMENDED to use the LE-MRM, if and only if the data sender's IP address is not known and the data receiver is behind a NAT. 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 address. The message routing for the EXTERNAL message is in the reverse direction to 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 an 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 Stiemerling, et al. Expires August 18, 2008 [Page 38] Internet-Draft NAT/FW NSIS NSLP February 2008 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 which 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 devices 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 message with a successful RESPONSE message. An edge-NAT includes an NATFW_EXTERNAL-IP object (see Section 4.2.2), carrying the public reachable IP address, and if applicable port number. 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 Stiemerling, et al. Expires August 18, 2008 [Page 39] Internet-Draft NAT/FW NSIS NSLP February 2008 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 which also translate port numbers) to perform the address translation. This information is provided in the NATFW_DTINFO (see Section 4.2.7). This information MUST include at least the 'dst port number' and 'protocol' fields, in the NATFW_DTINFO object as these may be required by en-route NATs, 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 NATFW CREATE message with the MRI matching ('src IPv4/v6 address', 'src port number', 'protocol') to be forwarded. A NAT requiring information carried in the NATFW_DTINFO can generate a number of error RESPONSE messages of class 'Signaling session failure' (0x6): o 'Requested policy rule denied due to policy conflict' (0x04) 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) Stiemerling, et al. Expires August 18, 2008 [Page 40] Internet-Draft NAT/FW NSIS NSLP February 2008 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 an NF MUST generate an error RESPONSE of class 'Protocol error' (0x3) 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' (0x3) 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 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 an 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 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 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' 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. Stiemerling, et al. Expires August 18, 2008 [Page 41] Internet-Draft NAT/FW NSIS NSLP February 2008 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 an 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. * 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' (0x5) 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 an NATFW_EXTERNAL-IP object, the NI can use IP address and port pairs carried for further application signaling. After receiving a 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' (0x2). If the RESPONSE message contains NATFW_INFO object with class set not to 'Success' (0x2), 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 Stiemerling, et al. Expires August 18, 2008 [Page 42] Internet-Draft NAT/FW NSIS NSLP February 2008 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 teardown 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 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 carrying 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 NSIS 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. Stiemerling, et al. Expires August 18, 2008 [Page 43] Internet-Draft NAT/FW NSIS NSLP February 2008 NI Public Internet NAT Private address NR | | space | | CREATE[lifetime > 0] | | |----------------------------->| | | | | | | | | | CREATE[lifetime > 0] | | |--------------------------->| | | | | | RESPONSE[Success/Error] | | RESPONSE[Success/Error] |<---------------------------| |<-----------------------------| | | | | | | | Figure 17: 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 18. Whether a CREATE or EXTERNAL message type is used, depends on how the NATFW NSLP signaling session was created. Stiemerling, et al. Expires August 18, 2008 [Page 44] Internet-Draft NAT/FW NSIS NSLP February 2008 NI Public Internet NAT Private address NR | | space | | CREATE[lifetime=0] | | |----------------------------->| | | | | | | CREATE[lifetime=0] | | |--------------------------->| | | | Figure 18: 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, neither positive nor 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 [2]. The outbound NF receiving such an aggregated CREATE or EXTERNAL message MUST reject it with an error RESPONSE of class 'Permanent failure' (0x5) with response code 'Authentication failed' (0x01) if the authentication fails and with an error RESPONSE of class 'Permanent failure' (0x5) with response code 'Authorization failed' (0x02) if the authorization fails. Per NATFW NSLP signaling session proof of ownership, as it is defined in this memo, is not possible anymore when using this aggregated way. 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. Stiemerling, et al. Expires August 18, 2008 [Page 45] Internet-Draft NAT/FW NSIS NSLP February 2008 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' (0x1)) 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. 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 been 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 by any 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: Stiemerling, et al. Expires August 18, 2008 [Page 46] Internet-Draft NAT/FW NSIS NSLP February 2008 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 result of node local 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 of 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. in [2]. 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, a NF MAY aggregate again 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 same areas of the Internet. End-to- Stiemerling, et al. Expires August 18, 2008 [Page 47] Internet-Draft NAT/FW NSIS NSLP February 2008 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 Section 3.7.1 and Section 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 19). 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 19, unlike the standard EXTERNAL message handling case, the edge-NAT/ edge-firewall is triggered to send a CREATE message on a new reverse path which traverse several firewalls or NATs. The new reverse path for CREATE is necessary to handle routing asymmetries between the edge-NAT/edge-firewall and DR. It must be stressed that the semantics of the CREATE and EXTERNAL messages is not changed, i.e., each is processed as described earlier. Stiemerling, et al. Expires August 18, 2008 [Page 48] Internet-Draft NAT/FW NSIS NSLP February 2008 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 19: 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 'Transit'. There is no CREATE session in any other signaling state of the EXTERNAL-PROXY, i.e., 'pending' or 'dead'. This ensures a faith-sharing between both 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 a EXTERNAL-PROXY message, it generates a successful RESPONSE message as if it were the NR and additionally, 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 a EXTERNAL-PROXY refresh message has been received first. This also includes tearing down signaling sessions, i.e., the NF must teardown the CREATE signaling session only if a EXTERNAL-PROXY message with lifetime set to 0 has been received Stiemerling, et al. Expires August 18, 2008 [Page 49] Internet-Draft NAT/FW NSIS NSLP February 2008 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 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 NI initiated CREATE messages. It is the NR's responsibility to decide whether to teardown 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 uses 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 which 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). Stiemerling, et al. Expires August 18, 2008 [Page 50] Internet-Draft NAT/FW NSIS NSLP February 2008 DS Private Address NAT/FW Public Internet NR NI Space NF no NR | | | | CREATE-PROXY | | |------------------------------>| | | | | | RESPONSE[SUCCESS/ERROR] | | |<------------------------------| | | | | Figure 20: 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.8. De-Multiplexing at NATs Section 3.7.2 describes how NSIS nodes behind NATs can obtain a public reachable IP address and port number at a NAT and 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 de- multiplex incoming NSIS CREATE messages. The de-multiplexing 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 [2]) as the flow destination IP address and the network-layer-version 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 Stiemerling, et al. Expires August 18, 2008 [Page 51] Internet-Draft NAT/FW NSIS NSLP February 2008 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 field can contain wildcards. When receiving a CREATE message at the NATFW NSLP it uses the flow information stored in the MRI to do the matching process. This table shows the parameters to be compared against each others. Note that not all parameters can be present in a 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) | | | |