NSIS Working Group M. Stiemerling Internet-Draft NEC Expires: August 5, 2006 H. Tschofenig Siemens C. Aoun ENST February 1, 2006 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) draft-ietf-nsis-nslp-natfw-09 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 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators and firewalls. This NSLP allows hosts to signal along a data path for Network Address Translators and firewalls to be configured according to the data flow needs. The network scenarios, problems and solutions for path-coupled Network Stiemerling, et al. Expires August 5, 2006 [Page 1] Internet-Draft NAT/FW NSIS NSLP February 2006 Address Translator and firewall signaling are described. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Terminology and Abbreviations . . . . . . . . . . . . . 7 1.2 Middleboxes . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . 10 1.4 General Scenario for NATFW Traversal . . . . . . . . . . 11 2. Network Deployment Scenarios using 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 IPv4/v6 NAT with two Private Networks . . . . . . . . . 18 2.8 Multihomed Network with NAT . . . . . . . . . . . . . . 19 2.9 Multihomed Network with Firewall . . . . . . . . . . . . 19 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 21 3.1 Policy Rules . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Basic Protocol Overview . . . . . . . . . . . . . . . . 21 3.3 Basic Message Processing . . . . . . . . . . . . . . . . 25 3.4 Protocol Operations . . . . . . . . . . . . . . . . . . 25 3.4.1 Creating Sessions . . . . . . . . . . . . . . . . . 26 3.4.2 Reserving External Addresses . . . . . . . . . . . . 28 3.4.3 NATFW Session Refresh . . . . . . . . . . . . . . . 35 3.4.4 Deleting Sessions . . . . . . . . . . . . . . . . . 37 3.4.5 Reporting Asynchronous Events . . . . . . . . . . . 37 3.4.6 Tracing Signaling Sessions . . . . . . . . . . . . . 38 3.4.7 Proxy Mode for Data Receiver behind NAT . . . . . . 40 3.4.8 Proxy Mode for Data Sender behind Middleboxes . . . 43 3.4.9 Proxy Mode for Data Receiver behind Firewall . . . . 44 3.5 Calculation of Session Lifetime . . . . . . . . . . . . 47 3.6 Message Sequencing . . . . . . . . . . . . . . . . . . . 49 3.7 De-Multiplexing at NATs . . . . . . . . . . . . . . . . 50 3.8 Selecting Opportunistic Addresses for REA . . . . . . . 50 3.9 Session Ownership . . . . . . . . . . . . . . . . . . . 52 3.10 Authentication and Authorization . . . . . . . . . . . . 52 3.11 Reacting to Route Changes . . . . . . . . . . . . . . . 53 3.12 Updating Policy Rules . . . . . . . . . . . . . . . . . 53 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . 55 4.1 NSLP Header . . . . . . . . . . . . . . . . . . . . . . 55 Stiemerling, et al. Expires August 5, 2006 [Page 2] Internet-Draft NAT/FW NSIS NSLP February 2006 4.2 NSLP Message Types . . . . . . . . . . . . . . . . . . . 55 4.3 NSLP Objects . . . . . . . . . . . . . . . . . . . . . . 56 4.3.1 Session Lifetime Object . . . . . . . . . . . . . . 57 4.3.2 External Address Object . . . . . . . . . . . . . . 57 4.3.3 Extended Flow Information Object . . . . . . . . . . 58 4.3.4 Response Code Object . . . . . . . . . . . . . . . . 59 4.3.5 Proxy Support Object . . . . . . . . . . . . . . . . 60 4.3.6 Nonce Object . . . . . . . . . . . . . . . . . . . . 60 4.3.7 Message Sequence Number Object . . . . . . . . . . . 61 4.3.8 Data Terminal Information Object . . . . . . . . . . 61 4.3.9 Trace Object . . . . . . . . . . . . . . . . . . . . 63 4.4 Message Formats . . . . . . . . . . . . . . . . . . . . 63 4.4.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . 64 4.4.2 RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . 64 4.4.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . 65 4.4.4 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 65 4.4.5 REA-F . . . . . . . . . . . . . . . . . . . . . . . 66 4.4.6 TRACE . . . . . . . . . . . . . . . . . . . . . . . 66 5. NATFW NSLP NTLP Requirements . . . . . . . . . . . . . . . . 67 6. NSIS NAT and Firewall Transition Issues . . . . . . . . . . 68 7. Security Considerations . . . . . . . . . . . . . . . . . . 69 7.1 Trust Relationship and Authorization . . . . . . . . . . 69 7.1.1 Peer-to-Peer Trust Relationship . . . . . . . . . . 70 7.1.2 Intra-Domain Trust Relationship . . . . . . . . . . 70 7.1.3 End-to-Middle Trust Relationship . . . . . . . . . . 71 7.2 Security Threats and Requirements . . . . . . . . . . . 72 7.2.1 Attacks related to authentication and authorization 72 7.2.2 Denial-of-Service Attacks . . . . . . . . . . . . . 79 7.2.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . 80 7.2.4 Message Modification by non-NSIS on-path node . . . 81 7.2.5 Message Modification by malicious NSIS node . . . . 81 7.2.6 Session Modification/Deletion . . . . . . . . . . . 82 7.2.7 Misuse of unreleased sessions . . . . . . . . . . . 85 7.2.8 Data Traffic Injection . . . . . . . . . . . . . . . 86 7.2.9 Eavesdropping and traffic analysis . . . . . . . . . 88 7.3 Security Framework for the NAT/Firewall NSLP . . . . . . 89 7.3.1 Security Protection between neighboring NATFW NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . . 89 7.3.2 Security Protection between non-neighboring NATFW NSLP Nodes . . . . . . . . . . . . . . . . . . . . . 89 7.3.3 End-to-End Security . . . . . . . . . . . . . . . . 91 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 92 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 93 Stiemerling, et al. Expires August 5, 2006 [Page 3] Internet-Draft NAT/FW NSIS NSLP February 2006 10. References . . . . . . . . . . . . . . . . . . . . . . . . 94 10.1 Normative References . . . . . . . . . . . . . . . . . . 94 10.2 Informative References . . . . . . . . . . . . . . . . . 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 97 A. Firewall and NAT Resources . . . . . . . . . . . . . . . . . 98 A.1 Wildcarding of Policy Rules . . . . . . . . . . . . . . 98 A.2 Mapping to Firewall Rules . . . . . . . . . . . . . . . 99 A.3 Mapping to NAT Bindings . . . . . . . . . . . . . . . . 99 A.4 Mapping for combined NAT and firewall . . . . . . . . . 99 A.5 NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . 99 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 100 Intellectual Property and Copyright Statements . . . . . . . 101 Stiemerling, et al. Expires August 5, 2006 [Page 4] Internet-Draft NAT/FW NSIS NSLP February 2006 1. Introduction 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 the outside, and in times of IPv4 address depletion, 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, currently under standardization at the IETF). 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, including STUN [26] and TURN [29]. 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, ...), 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 QoS or NATFW 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 [13] is an example of a current QoS signaling protocol that is path-coupled. [36] 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]. The general framework of NSIS is outlined in [4]. It introduces the split between an NSIS transport layer and an NSIS signaling layer. The transport of NSLP messages is handled Stiemerling, et al. Expires August 5, 2006 [Page 5] Internet-Draft NAT/FW NSIS NSLP February 2006 by an NSIS Network Transport Layer Protocol (NTLP, with General Internet Signaling Transport (GIST) [1] 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], while the NATFW NSLP is defined in this memo. 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 upstream firewalls. Enabling data flows requires the loading of firewall pin holes (loading of firewall rules with action allow) and creating NAT bindings. Blocking of data flows requires the loading of firewalls rules with action deny/drop. 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 NAT/firewall along the data path intercepts these messages, 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 middlebox 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 NSIS initiator or the data receiver logically decomposed from the 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. 2. Only one end host or region of the network is NSIS NATFW NSLP aware, either data receiver or data sender. NATFW NSLP provides two basic modes to cope with various possible scenarios likely to be encountered before and after widespread deployment of NSIS: CREATE mode: The basic mode for configuring a path downstream from a data sender RESERVE-EXTERNAL-ADDRESS (REA) mode: Used to prime upstream NATs/ firewalls to expect downstream signaling and at NATs to pre- allocate a public address. Once there is full deployment of NSIS (in the sense that both end hosts support NATFW NSLP signaling), the requisite NAT and firewall Stiemerling, et al. Expires August 5, 2006 [Page 6] Internet-Draft NAT/FW NSIS NSLP February 2006 state can be created using either just CREATE mode if the data receiver resides in a public addressing realm, or a combination of RESERVE-EXTERNAL-ADDRESS and CREATE modes if the data receiver resides in a private addressing realm and needs to preconfigure the edge-NAT/edge-firewall to provide a (publicly) reachable address for use by the data sender. During the introduction of NSIS, it is likely that one or 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 sender and receiver to provide proxy NATFW NSLP services ("proxy mode" services). Typically these boxes will be at the boundaries of the realms in which the end hosts are located. If the data receiver is NSIS unaware, the normal modes can be employed but the NSIS signaling terminates at the NSIS aware node topologically closest to the receiver which then acts as a proxy for the receiver. If the data sender is unaware a variant of the RESERVE-EXTERNAL-ADDRESS mode can be used by a data receiver behind a NAT or firewall. All modes of operation create NATFW NSLP and NTLP state in NSIS entities. NTLP state allows signaling messages to travel in the forward (downstream) and the reverse (upstream) direction along the path between a NAT/firewall NSLP sender and a corresponding receiver. NAT bindings and firewall rules are NAT/firewall specific state. This state is managed using a soft-state mechanism, i.e., it expires unless it is refreshed from time to time. Section 2 describes the network environment for NATFW NSLP signaling, highlighting the trust relationships and authorization required. Section 3 defines the NATFW signaling protocol. Section 4 defines the messages and and message components. In the remaining parts of the main body of the document, Section 6 covers transition issues and Section 7 addresses security considerations. Please note that readers familiar with firewalls and NATs and their possible location within networks can safely skip Section 2. 1.1 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 [2]. This document uses a number of terms defined in [5]. 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" [28]. In the context of NSIS Stiemerling, et al. Expires August 5, 2006 [Page 7] Internet-Draft NAT/FW NSIS NSLP February 2006 NATFW NSLP, the condition is a specification of a set of packets to which rules are applied. The set of actions always contains just a single element per rule, and is limited to either action "deny" or action "allow". o NSLP (rule) directive: Instruction to a NATFW NSLP node as to how it should treat the associated policy rule. Directive 'reserve' requests the middlebox to remember the rule and pre-allocate addresses where necessary but not install the rule. Directive 'install' requests the middle to install an active rule. o Firewall: A packet filtering device that matches packets against a set of policy rules and applies the actions. In the context of NSIS NATFW NSLP we refer to this device as a firewall. 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. o Middlebox: "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 a source host and a destination host" [11]. In the context of this document, the term middlebox refers to firewalls and NATs only. Other types of middlebox are currently outside of the scope of this document. o Security Gateway: IPsec-based gateways. o (Data) Receiver (DR or R): The node in the network that is receiving the data packets of a flow. o (Data) Sender (DS or S): The node in the network that is sending the data packets of a flow. o NATFW NSLP session or signaling session: An application layer flow of information for which some network control state information is to be manipulated or monitored (as defined in [4]). The control state for NATFW NSLP consists of NSLP state and associated policy rules at a middlebox. o NSIS peer or peer: An NSIS node with which an NSIS adjacency has been created as defined in [1]. o Edge-NAT: An edge-NAT is a NAT device that is reachable from the public Internet and that has a globally routable IP address. Stiemerling, et al. Expires August 5, 2006 [Page 8] Internet-Draft NAT/FW NSIS NSLP February 2006 o Edge-firewall: An edge-firewall is a firewall device that is located on the demarcation 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]. IP address space allocation for private networks is recommended in [27] 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 Opportunistic Address (OA) or Signaling Destination Address (SDA): An IP address out of the public/global IP address range. The OA/ SDA may in certain circumstances be part of the private/local IP address range. 1.2 Middleboxes The term middlebox covers a range of devices which intercept the flow of packets between end hosts and perform actions other than standard forwarding expected in an IP router. As 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 and security gateways, are out of scope. 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 Stiemerling, et al. Expires August 5, 2006 [Page 9] Internet-Draft NAT/FW NSIS NSLP February 2006 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 For further examples of flow identifiers see Section 5.2.2 of [1]. 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 routeable IP address and associated port number. o Change destination IP address and transport port number to a private IP address and associated port number. 1.3 Non-Goals Traversal of non-NSIS and non-NATFW NSLP aware NATs and firewalls is outside the scope of this document. Only firewalls and NATs are considered in this document, any other types of devices, for instance, QoS gateways, are out of scope. Stiemerling, et al. Expires August 5, 2006 [Page 10] Internet-Draft NAT/FW NSIS NSLP February 2006 The exact implementation of policy rules and their mapping to firewall rule sets and NAT bindings or sessions at the middlebox is an implementation issue and thus out of scope of this document. Some examples are given in Appendix A 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 upstream firewalls. The basic high-level picture of NSIS usage is that end hosts are located behind middleboxes, meaning that there is a middlebox on the data path from the end host in a private network and 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 5, 2006 [Page 11] Internet-Draft NAT/FW NSIS NSLP February 2006 Application Application Server (0, 1, or more) Application +----+ +----+ +----+ | +------------------------+ +------------------------+ | +-+--+ +----+ +-+--+ | | | NSIS Entities NSIS Entities | +-+--+ +----+ +-----+ +-+--+ | +--------+ +----------------------------+ +-----+ | +-+--+ +-+--+ +--+--+ +-+--+ | | ------ | | | | //// \\\\\ | | +-+--+ +-+--+ |/ | +-+--+ +-+--+ | | | | | Internet | | | | | | +--------+ +-----+ +----+ +-----+ | +----+ +----+ |\ | +----+ +----+ \\\\ ///// sender NATFW (1+) ------ NATFW (1+) receiver Figure 1: Generic View on NSIS in a NAT / Firewall case 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. Stiemerling, et al. Expires August 5, 2006 [Page 12] Internet-Draft NAT/FW NSIS NSLP February 2006 2. Network Deployment Scenarios using 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. Using combined middleboxes typically reduces the number of network elements needed. 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 Stiemerling, et al. Expires August 5, 2006 [Page 13] Internet-Draft NAT/FW NSIS NSLP February 2006 policy rules, so that the required data packet flow can traverse them. There are several very different ways to place firewalls in a network topology. To distinguish firewalls located at network borders, such as administrative domains, from others located internally, the term edge-firewall is used. A similar distinction can be made for NATs, with an edge-NAT fulfilling the equivalent role. 2.2 NAT with two private Networks Figure 3 shows a scenario with NATs at both ends of the network. Therefore, each application instance, the NSIS initiator and the NSIS responder, are behind NATs. The outermost NAT, known as the edge- NAT, at each side is connected to the processing public Internet. The NATs are generically labeled as MB (for middlebox), 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 --| MB |-----| MB |---| |---| MB |-----| MB |--- 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, 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. Instead a NAT binding (including a public IP address) has to be previously installed on the NAT that subsequently allows packets reaching the NAT to be forwarded to the receiver within the private address realm. This generally requires further support from an application layer protocol for the purpose of discovering and exchanging information. The receiver might have a Stiemerling, et al. Expires August 5, 2006 [Page 14] Internet-Draft NAT/FW NSIS NSLP February 2006 number of ways to learn its public IP address and port number 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 Scenario 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 policy rules accordingly. Note that 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. As described in Section 3.4.2.1 NSIS can also provide help for this procedure. 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 5, 2006 [Page 15] Internet-Draft NAT/FW NSIS NSLP February 2006 //----\\ +----+ +----+ 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 so establish the path via the middleboxes in the receiver side private network. This scenario describes the use case for the RESERVE-EXTERNAL-ADDRESS mode 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. This is a common configuration in networks, particularly after the merging of companies that have used the same private address space, resulting in overlapping address ranges. Stiemerling, et al. Expires August 5, 2006 [Page 16] Internet-Draft NAT/FW NSIS NSLP February 2006 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 gateway, such as a DNS server. The application level gateways 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 by useful when there are also firewalls on 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 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, [1])within the NSLP and NTLP accordingly. For more information see Appendix A.5 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 NSIS initiator. Afterwards, the NSIS initiator can start sending the Stiemerling, et al. Expires August 5, 2006 [Page 17] Internet-Draft NAT/FW NSIS NSLP February 2006 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). This is the worst case in which both sender and receiver obtain a public IP address at the NAT, and the communication path is certainly not optimal in this case. 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 IPv4/v6 NAT with two Private Networks This scenario combines the use case described in Section 2.2 with the IPv4 to IPv6 transition scenario involving address and protocol translation, i.e., using Network Address and Protocol Translators (NAT-PT, [10]). The difference from the other scenarios is the use of IPv6 to IPv4 (and vice versa) address and protocol translation. Additionally, the base NTLP must support transport of messages in mixed IPv4 and IPv6 networks where some NSIS peers provide translation. +----+ +----+ //---\\ +----+ //---\\ +----+ +----+ NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR +----+ +----+ \\---// +----+ \\---// +----+ +----+ private public public private IPv4 IPv6 MB: Middlebox NI: NSIS Initiator NR: NSIS Responder Figure 8: IPv4/v6 NAT with two Private Networks Stiemerling, et al. Expires August 5, 2006 [Page 18] Internet-Draft NAT/FW NSIS NSLP February 2006 This scenario needs the same type of application level support as described in Section 2.5, and so the issues relating to twice-NATs apply here as well. Note that the current form of IPv4/v6 NAT known as the Network Address Translator - Protocol Translator (NAT-PT) [10] is being removed from the set of recommended mechanisms for general usage in IPv4/IPv6 transitions. This scenario is therefore not expected to be commonly seen. 2.8 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 private public MB: Middlebox NI: NSIS Initiator NR: NSIS Responder Figure 9: Multihomed Network with Two NATs Depending on the destination or load balancing requirements, 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.4.2.1 for an expanded discussion of this topic with respect to NATs. 2.9 Multihomed Network with Firewall This section describes a multihomed scenario with two firewalls placed on alternative paths to the public network (Figure 10). The routing in the private and public network decided 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. Stiemerling, et al. Expires August 5, 2006 [Page 19] Internet-Draft NAT/FW NSIS NSLP February 2006 This is a challenge for the REA-F mode of the NATFW NSLP where the NSIS responder is located behind these firewalls within the private network. The REA-F mode is used to block a particular data flow on an upstream firewall. NSIS must route the REA-F mode message upstream from NR to NI probably without knowing which path the data traffic will take from NI to NR. +----+ NR -------| MB |\ \ +----+ \ //---\\ \ -| |-- NI \ \\---// \ +----+ | --| MB |-------+ +----+ private private public MB: Middlebox NI: NSIS Initiator NR: NSIS Responder Figure 10: Multihomed Network with two Firewalls Stiemerling, et al. Expires August 5, 2006 [Page 20] Internet-Draft NAT/FW NSIS NSLP February 2006 3. Protocol Description This section defines messages, objects, and protocol semantics for the NATFW NSLP. Section 3.1 introduces the base element of a NSLP session, the policy rule. Section 3.2 introduces the protocol and the protocol behavior is defined in Section 3.4. Section 4 defines the syntax of the messages and objects. 3.1 Policy Rules Policy rules, bound to a session, are the building block of middlebox devices considered in the NATFW NSLP. For firewalls the policy rule usually consists of a 5-tuple, source/destination addresses, transport protocol, and source/destination port numbers, plus an action, such as allow or deny. For NATs the policy rule consists of action 'translate this address' and further mapping information, that might be, in the simplest case, internal IP address and external IP address. Policy rules are usually carried in one piece in signaling applications. In NSIS the policy rule is divided into the flow identifier, an allow or deny action, and additional information. The filter specification is carried within NTLP's message routing information (MRI) and additional information, including the specification of the action, is carried in the NATFW NSLP's objects. Additional information is, for example, the lifetime of a policy rule or session. 3.2 Basic Protocol Overview The NSIS NATFW NSLP is carried over the NSIS Transport Layer Protocol (NTLP) defined in [1]. The interworking with the NTLP and other components is shown in Figure 54. NATFW NSLP messages are initiated by the NSIS initiator (NI), handled by NSIS forwarders (NF) and finally processed 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. A Data Sender (DS), intending to send data to a Data Receiver (DR) must first initiate 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 11). 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 1.) Stiemerling, et al. Expires August 5, 2006 [Page 21] Internet-Draft NAT/FW NSIS NSLP February 2006 +-------+ +-------+ +-------+ +-------+ | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | | |--->| NF1 |--->| NF2 |--->| | +-------+ +-------+ +-------+ +-------+ ========================================> Data Traffic Direction (downstream) ---> : 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 11: General NSIS signaling The sequence of NSLP events is as follows: o NSIS initiators generate NATFW NSLP request messages and send those towards the NSIS responder. Note, that the NSIS initiator may not necessarily be the data sender but may be the data receiver, for instance, when using the RESERVE-EXTERNAL-ADDRESS message. o NSLP request messages are processed each time a NF with NATFW NSLP support is traversed. 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). Note, that the NSIS responder may not necessarily be the data receiver but may be any intermediate NSIS node that terminates the forwarding, for example, in a proxy mode case where an edge-NAT is replying to requests. o The response message is processed at each NF implementing the NATFW NSLP. Stiemerling, et al. Expires August 5, 2006 [Page 22] Internet-Draft NAT/FW NSIS NSLP February 2006 o Once the NI has received a successful response, the data sender can start sending its data flow to the data receiver. Because NATFW NSLP signaling follows the data path from DS to DR (see Figure 11), 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. 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 and NR are not reachable from the 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 (such as SDP within SIP). This application layer signaling, which is out of scope of the NATFW NSLP, may involve third parties that assist in exchanging these messages. NATFW NSLP signaling supports this scenario by using the RESERVE- EXTERNAL-ADDRESS mode of operation 1. The NR acquires a public address by signaling on the reverse path (NR towards NI) and thus making itself available to other hosts. This process of acquiring a public addresses is called reservation. During this process the DR reserves publicly reachable addresses and ports suitable for NATFW NSLP signaling, but data traffic will not be allowed to use this address/port initially. 2. The NI signals directly to the NR as the NI would do if there is no NAT in between, and creates policy rules at middleboxes. Note, that the reservation mode will only allow the forwarding of signaling messages but not data flow packets. Data flow packets will be 'activated' by the signaling from NI towards NR. The RESERVE-EXTERNAL-ADDRESS mode of operation is detailed in Section 3.4.2.1 Stiemerling, et al. Expires August 5, 2006 [Page 23] Internet-Draft NAT/FW NSIS NSLP February 2006 +-------+ +-------+ +-------+ +-------+ | DS/NI |<~~~| MB1/ |<~~~| NR | | DR | | |--->| NF1 |--->| | | | +-------+ +-------+ +-------+ +-------+ ========================================> Data Traffic Direction (downstream) ---> : 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 12: A NSIS proxy mode signaling The above usage assumes that both ends of a communication support NSIS but fail when NSIS is only deployed at one end of the network. In this case only the receiving or sending side are NSIS aware and not both at the same time (see also Section 1). NATFW NSLP supports this scenario by using a proxy mode, as described in Section 3.4.7 and Section 3.4.8. Figure 12 sketches the proxy mode operation for a data sender behind a middlebox. 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 that does not explicitly match 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 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 REA-F message to install policy rules at upstream firewalls to block unwanted traffic. 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 nodes involved will have to specifically request a session extension. An explicit NATFW NSLP state deletion capability is also provided by the protocol. Middleboxes should return an error in case of a failure, such that Stiemerling, et al. Expires August 5, 2006 [Page 24] Internet-Draft NAT/FW NSIS NSLP February 2006 appropriate actions can be taken; this ability would allow debugging and error recovery. The next sections define the NATFW NSLP message types and formats, protocol operations, and policy rule operations. 3.3 Basic Message Processing All NATFW messages are subject to a basic message processing when received at a node, independent of request or response messages. Initially, the syntax of the NSLP message is checked and a RESPONSE message with error code is generated if any problem is detected (for instance, the message header could not be read). After passing this check, the NATFW NSLP node MUST first perform the checks defined in Section 3.9 and Section 3.10, if applicable, before any further processing is executed. This section should state this ugly sentence out of all protocol operations sections on authentication and authorization. So get it rid of it there. This section opens an interesting question: What happens if a NSLP nodes receives a malformed response message? 3.4 Protocol Operations This section defines the protocol operations including, how to create sessions, maintain them, and how to reserve addresses. All the NATFW NSLP protocol messages MUST be transported via C-mode handling by the NTLP and MUST NOT be piggybacked into D-mode NTLP messages used during the NTLP path discovery/refresh phase. The usage of the NTLP by protocol messages is described in detail in Section 4. The protocol uses six messages: o CREATE: a request message used for creating, changing, refreshing, and deleting CREATE NATFW NSLP sessions. o RESERVE-EXTERNAL-ADDRESS (REA): a request message used for reserving an external address and (if applicable) port number, depending on the type of NAT. REA messages are used to change, refresh, and delete REA NATFW NSLP sessions. o REA-F: a request message used by data receivers located behind firewalls to instruct upstream firewalls to allow or block incoming data traffic. REA-F is also used to inform upstream firewalls about incoming NATFW NSLP signaling messages. REA-F messages are used to change, refresh, and delete REA-F NATFW NSLP sessions. Stiemerling, et al. Expires August 5, 2006 [Page 25] Internet-Draft NAT/FW NSIS NSLP February 2006 o TRACE: a request message to trace all involved NATFW NSLP nodes in a particular signaling session. o NOTIFY: an asynchronous message used by NATFW peers to alert upstream and/or downstream NATFW peers about specific events (especially failures). o RESPONSE: used as a response to CREATE, REA, and REA-F messages with Success or Error information. 3.4.1 Creating Sessions Allowing two hosts to exchange data even in the presence of middleboxes is realized in the NATFW NSLP by the CREATE request message. The data sender generates a CREATE message as defined in Section 4.4.1 and hands it to the NTLP. The NTLP forwards the whole message on the basis of the message routing information towards the NR. Each NSIS forwarder along the path that implements NATFW NSLP, processes the NSLP message. Forwarding is thus managed NSLP 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 the request and this response is transported hop-by-hop towards the NI. NATFW NSLP forwarders may reject requests at any time. Figure 13 sketches the message flow between NI (DS), a NF (e.g., NAT), and NR (DR). NI Private Network NF Public Internet NR | | | | CREATE | | |----------------------------->| | | | | | RESPONSE[Error](if necessary)| | |<-----------------------------| CREATE | | |--------------------------->| | | | | | RESPONSE[Success/Error] | | RESPONSE[Success/Error] |<---------------------------| |<-----------------------------| | | | | | | | Figure 13: Creation message flow Stiemerling, et al. Expires August 5, 2006 [Page 26] Internet-Draft NAT/FW NSIS NSLP February 2006 Since the CREATE message is used for several purposes within the lifetime of a session, there are several processing rules for NATFW peers when generating and receiving CREATE messages. The different processing methods depend not only on the function which the CREATE is performing (to create, modify, refresh or delete a session) but also on the node at which the processing happens. For an initial CREATE message that creates a new NSIS session, the processing of CREATE messages is different for every NSIS node type: o NSLP initiator: NI only generates initial CREATE messages and hands them over to the NTLP. After receiving a successful response, the data path is configured and the DS can start sending its data to the DR. After receiving an 'error' response message the NI MAY try to generate the CREATE message again or give up and report the failure to the application, depending on the error condition. o NATFW NSLP forwarder: NFs receiving an initial CREATE message MUST first perform the checks defined in Section 3.9 and Section 3.10, if applicable, before any further processing is executed. The NF SHOULD check with its local policies if it can accept the desired policy rule given the combination of the NTLP's 'Message-Routing-Information' (MRI) (the flow description information) and the CREATE payload (behavior to be enforced on the packet stream). An initial CREATE is distinguished from subsequent CREATE messages by the absence of existing NSLP session related to the same session ID. The NSLP message processing 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 REA message (see Section 3.4.2.1), that matches the destination address/port of the MRI provided by the NTLP. If no reservation has been made in advance the NSLP SHOULD return an error response message of type 'no reservation found' and discard the request. If there is a reservation, NSLP stores the data sender's address (and if applicable port number) as part of the policy rule to be loaded and forwards the message with the address set to the internal (private in most cases) address of the next NSIS node. When the initial CREATE message is received at the private side, the NAT binding is allocated, but not activated (see also Appendix A.3). The NSLP message is forwarded to the next NSIS hop with source address set to the NAT's external address from the newly reserved 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 to the Stiemerling, et al. Expires August 5, 2006 [Page 27] Internet-Draft NAT/FW NSIS NSLP February 2006 next NSLP hop. There is a difference between requests from trusted (authorized NIs) and un-trusted (un-authorized NIs); requests from trusted NIs will be pre-authorized, whereas requests from un-trusted NIs will not be pre-authorized. This difference is required to speed-up the protocol operations as well as for proxy mode usage (please refer to Section 3.4.7). * 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 object has success information) RESPONSE message if they accept the CREATE request message and defined in Section 3.9 and Section 3.10, if applicable, have been successful executed. Otherwise they SHOULD generate a RESPONSE message with an error code. The calculation of session lifetime applies here as well (see Section 3.5). RESPONSE messages are sent back NSLP hop-by-hop towards the NI, independently of the response codes, either success or error. Policy rules at middleboxes MUST be only installed upon receiving a successful response. This is a countermeasure to several problems, for example wastage of resources due to loading policy rules at intermediate NF when the CREATE message does not reach the final NR for some reason. 3.4.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.4.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 (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 upstream firewalls/NATs) about incoming NATFW NSLP signaling and data flows before they can receive these flows. It is necessary to discriminate between data receivers behind NATs and behind firewalls for understanding the further NATFW procedures. Data receivers that are just behind firewalls already Stiemerling, et al. Expires August 5, 2006 [Page 28] Internet-Draft NAT/FW NSIS NSLP February 2006 have a public IP address and they need only to be reachable for NATFW signaling. Data receivers behind NATs do not a have a public IP address and are not reachable for NATFW signaling. We first discuss the DR behind a NAT case. 3.4.2.1 Reserving External Addresses at NATs Figure 14 describes a typical message sequence in a peer-to-peer networking environment whereby the two end points learn of each others existence with the help of a third party (referred to as an Application Server). Communication between the application server and each of the two end points (data sender and data receiver) enables the two end hosts to learn each other's IP addresses. The approach described in this memo supports this peer-to-peer approach, but is not limited to it. +-------------+ AS-Data Receiver Communication +-------->| Application |<-----------------------------+ | | Server (AS) | | | +-------------+ | | IP(R-NAT_B) | | NSIS Signaling Message +-------+--+ | +------------------------------------------>| NAT/NAPT | | | | B | | | +-------+--+ | | | AS-Data| | | Receiver| | +----------+ | Comm.| | | NAT/NAPT | | | | | A | | | | +----------+ | | | | | | | | | | | | | v | IP(R) v +--------+ +---------+ | Data | | Data | | Sender | | Receiver| +--------+ +---------+ IP(R): Private IP Address of Data Receiver IP(R-NAT_B): Public IP Address for Data Receiver provided by binding in NAT/NAPT B Stiemerling, et al. Expires August 5, 2006 [Page 29] Internet-Draft NAT/FW NSIS NSLP February 2006 Figure 14: The Data Receiver behind NAT Problem Some sort of communication between the data sender/data receiver and a third party is typically necessary (independently of whether NSIS is used). NSIS signaling messages cannot be used to communicate the relevant application level end point identifiers (in the generic case at least) as a replacement for communication with the application server. If the data receiver is behind a NAT then an NSIS signaling message will be addressed to the IP address allocated at the NAT (assuming one had already been allocated). If no corresponding NSIS NAT Forwarding State at NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the signaling message will terminate at the NAT device (most likely without generating a proper response message). The signaling message transmitted by the data sender cannot install the NAT binding or NSIS NAT Forwarding State "on-the-fly" since this would assume that the data sender knows the topology at the data receiver side (i.e., the number and the arrangement of the NAT and the private IP address(es) of the data receiver). A primary goal of path-coupled middlebox communication was to avoid end hosts having to discover and use this type of topology knowledge. Data receivers behind a NAT must first reserve an external IP address (and, in many cases, a port number as well). Public Internet Private Address Space Edge NI(DS) NAT NAT NR(DR) NR+ NI+ | | | | | | | | | | | | | | REA[DTInfo] | REA[DTInfo] | | |<----------------------|<----------------------| | | | | | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| | |---------------------->|---------------------->| | | | | | | | | ============================================================> Data Traffic Direction Figure 15: Reservation message flow for DR behind NAT Stiemerling, et al. Expires August 5, 2006 [Page 30] Internet-Draft NAT/FW NSIS NSLP February 2006 Figure 15 shows the message flow for reserving an external address/ port at a NAT. 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 RESERVE-EXTERNAL-ADDRESS (REA) 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 The actual target of the REA message, the Opportunistic Address (OA) is an arbitrary address, that would force the message to get intercepted by the far outermost NAT in the network at the boundary between the private address and the public address realm. The Opportunistic Address is shown as NR+. REA messages for NATs MUST be transported by using the loose-end message routing method (LE-MRM) of the NTLP. Note that REA messages for firewalls (the firewall-REA) must be transported by using the path-coupled message routing method (PC-MRM), see Section 3.4.2.2. The NI+ (could be on the data receiver DR or on any other host within the private network) sends the REA message targeted to the Opportunistic Address (OA defined earlier). The OA selection for this message is discussed in Section 3.8. The message routing for the REA message is in the reverse direction to the normal message routing used for path-coupled signaling where the signaling is sent downstream (as opposed to upstream in this case). When establishing NAT bindings (and a NSIS session) the signaling direction does not matter since the data path is modified through route pinning due to the external NAT address. Subsequent NSIS messages (and also data traffic) will travel through the same NAT boxes. The NI+ MUST include a 'data terminal information' object (DTInfo) in the REA message and fill it in appropriately (see Section 4.3.8). This information SHOULD include at least the 'dst port number' and 'protocol' fields, in the DTInfo object as these may be required by en-route NATs, depending on the type of the NAT. These two fields are most likely required by NAPTs to perform the address and port translation. All other fields MAY be set by the NI+ to restrict the set of possible NIs. An edge-NAT will use the information provided within the DTInfo object ('src IPv4/v6 address', 'src port number', 'protocol') to only allow hosts falling within the specified range to originate NATFW NSLP messages. The possible range is given by the 'src port number' field and the combination of 'dst prefix' and 'src IP address' (see also Section 4.3.8). Stiemerling, et al. Expires August 5, 2006 [Page 31] Internet-Draft NAT/FW NSIS NSLP February 2006 The REA signaling message creates a NSIS NATFW session at any intermediate NSIS NATFW peer(s) encountered. Furthermore it has to be ensured that the edge-NAT device is discovered as part of this process. The end host cannot be assumed to know this device - instead the NAT box itself is assumed to know that it is located at the outer perimeter of the private addressing realm. Forwarding of the REA message beyond this entity is not necessary, and MUST be prohibited as it provides information on the capabilities of internal hosts. The edge-NAT device responds to the REA message with a RESPONSE message containing a success object carrying the public reachable IP address/port number in an 'external address' object (see Section 4.3.2). Processing of REA messages is specific to the NSIS node type: o NSLP initiator: NI+ only generate REA messages and should never receive them. When the data sender's address information is known in advance the NI+ MAY include a DTInfo object in the REA message. When the data sender's IP address is not known, NI+s MUST NOT include a DTInfo object. o NSLP forwarder: NSLP forwarders receiving REA messages MUST first perform the checks defined in Section 3.9 and Section 3.10, if applicable, before any further processing is executed. The NF SHOULD check with its local policies if it can accept the desired policy rule given by NTLP's message routing information (MRI). Further processing depends on the middlebox type: * NAT: NATs check whether the message is received at the external (public in most cases) address or at the internal (private) address. If received at the external address a NF MAY generate a RESPONSE message with an error of type 'REA received from outside'. If received at the internal address, an IP address/port is reserved. If it is an edge-NAT, the NSLP message is not forwarded any further and a RESPONSE message is generated containing an 'external address' object (either IPv4 or IPv6 version, as appropriate) holding the translated address port information in the binding reserved as a result of the REA 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 and including the translated IP address/port in the MRI. The edge- NAT MAY reject REA messages not carrying a DTInfo object or if the address information within this object is invalid or is not comliant with local policies (e.g., the information provided is wildcarded but the edge-NAT requires full information about DS' Stiemerling, et al. Expires August 5, 2006 [Page 32] Internet-Draft NAT/FW NSIS NSLP February 2006 IP address and port). * Firewall: Firewalls MUST not change their configuration on receiving a REA message. They MUST simply forward the message and MUST keep NTLP state. Firewalls that are configured as edge-firewalls SHOULD return an error of type 'no NAT here'. * 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 SHOULD be discarded silently. Processing of a RESPONSE message with an 'external address' object is different for every NSIS node type: o NSLP initiator: Upon receiving a RESPONSE message with an external address object, the NI+ can use the IP address and port pairs carried for further application signaling. o NSLP forwarder: NFs simply forward this message as long as they keep state for the requested reservation. o NSIS responder: This type of message should never be received by any NR+, unless it also the edge-NAT. In any other case, it SHOULD be discarded silently (EDITOR's note: It can be appropriate the return an error message). o Edge-NATs: This type of message should never be received by any Edge-NAT and it SHOULD be discarded silently. (EDITOR's note: It can be appropriate the return an error message, btw what means drop silenty? What happens to the NTLP session?) Reservations made with REA MUST be enabled by a subsequent CREATE message. A reservation made with REA is kept alive as long as the NI+ refreshes the particular 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. Without using CREATE Section 3.4.1 or REA in proxy mode Section 3.4.7 no data traffic will be forwarded to DR beyond the edge-NAT. REA is just taking care about enabling the forwarding of subsequent CREATE messages traveling towards the NR. Correlation of incoming CREATE messages to REA reservation states is described in Section 3.7. 3.4.2.2 Signaling Reservation for Firewalls Data receivers behind firewalls can experience two basic policy settings of their upstream firewalls. Either the firewall is set to Stiemerling, et al. Expires August 5, 2006 [Page 33] Internet-Draft NAT/FW NSIS NSLP February 2006 a 'deny all by default' or 'allow all by default' policy. In the 'deny all' case, no traffic, neither plain data nor NATFW NSLP signaling,is allowed to traverse the firewall. Vice versa in the 'allow all' case, all traffic is allowed to traverse. For 'deny all' firewalls, data receivers must be able to notify upstream firewalls about their willingness to receive NATFW NSLP signaling (this is similar to REA for NATs). For 'allow all' firewalls, data receivers must be able to notify upstream firewalls about unwanted traffic that should be blocked. Data receivers use the RESERVE-EXTERNAL-ADDRESS (REA) request message to either allow incoming NATFW NSLP signaling messages or to block incoming data traffic, as shown in Figure 16. See also the proxy mode of operation for REA-F in Section 3.4.9. Public Internet Protected Address Space Edge NI(DS) FW FW NR(DR) NR+ NI+ | | | | | | | | | | | | | | REA-F[NATFW_EFI] | REA-F[NATFW_EFI] | | |<----------------------|<----------------------| | | | | | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| | |---------------------->|---------------------->| | | | | | | | | ============================================================> Data Traffic Direction Figure 16: Signaling reservation message flow The processing of REA for firewalls (REA-F) messages is different for every NSIS entity: o NSLP initiator (NI+): NI+ MUST always direct REA-F message to the address of DS. NI+ only generates REA-F messages and should never receive them. o NSLP forwarder: NSLP forwarders receiving REA-F messages MUST first perform the checks defined in Section 3.9 and Section 3.10, if applicable, before any further processing is executed. The NF SHOULD check with its local policies if it can accept the desired Stiemerling, et al. Expires August 5, 2006 [Page 34] Internet-Draft NAT/FW NSIS NSLP February 2006 policy rule given by NTLP's message routing information (MRI). Further processing 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 internal interface, NATs allocated a public IP address and port and forward the message further. Edge-NATs receiving REA-F SHOULD response with error RESPONSE indicating 'no edge-firewall'. * Firewall: Non edge-firewalls keep session state and forward the message. Edge-firewalls stop forwarding the check for performing the checks defined in Section 3.9 and Section 3.10, if applicable. If the message is accepted, load the specified policy rule and generate RESPONSE messages back towards the DR. * Combined NAT and firewall: Processing at combined firewall and NAT middleboxes is the same as in the firewall case. o NSLP receiver: This type of message should never be received by any NR+ and it SHOULD be discarded silently. Processing of a RESPONSE message with an external address object is different for every NSIS node type: o NSLP initiator (NI+): The NI+ is ready to received signaling or data traffic when receiving a RESPONSE message. o NSLP forwarder: NFs simply forward this message as long as they keep state for the requested reservation. o NSIS responder: This type of message should never be received by an NR and it SHOULD be discarded silently. o Edge-NATs/edge-firewall: This type of message should never be received by any edge-NAT/edge-firewall and it SHOULD be discarded silently. EDITOR's note: This section does not explain the operation of the NATFW_EFI object. 3.4.3 NATFW Session Refresh NATFW NSLP 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, REA, and REA-F and the maintenance of this state must be done by these messages. State created by Stiemerling, et al. Expires August 5, 2006 [Page 35] Internet-Draft NAT/FW NSIS NSLP February 2006 CREATE must be maintained by CREATE, state created by REA must be maintained by REA, and state created by REA-F must be maintained by REA-F. Refresh messages, either CREATE/REA/REA-F, are messages carrying the exact MRI and session ID as the initial message and a lifetime object with a lifetime greater than zero. Every refresh request message MUST be acknowledged by an appropriate response message generated by the NR. This response message is routed back towards the NI, to allow the intermediate NFs to propose a refresh period that would align with their local policies. The NI sends refresh messages destined for the NR. Upon reception by each NSIS forwarder, the state for the given session ID is extended by the session refresh period, a period of time calculated based on a proposed refresh message period. The lifetime extension of a session is calculated as current local time plus proposed lifetime value (session refresh period). Section 3.5 defines the process of calculating lifetimes in detail. NI Public Internet NAT Private address NR | | space | | CREATE[lifetime > 0] | | |----------------------------->| | | | | | RESPONSE[Error] (if needed) | | |<-----------------------------| CREATE[lifetime > 0] | | |--------------------------->| | | | | | RESPONSE[Success/Error] | | RESPONSE[Success/Error] |<---------------------------| |<-----------------------------| | | | | | | | Figure 17: State Refresh Message Flow, CREATE as example Processing of session refresh CREATE/REA/REA-F messages is different for every NSIS node type: o NSLP initiator: The NI can generate session refresh CREATE/REA/ REA-F messages before the session times out. The rate at which the refresh CREATE/REA/REA-F messages are sent and their relation to the session state lifetime are further discussed in Section 3.5. The message routing information and the extended flow information object MUST be set equal to the values of the initial request message. Stiemerling, et al. Expires August 5, 2006 [Page 36] Internet-Draft NAT/FW NSIS NSLP February 2006 o NSLP forwarder: NSLP forwarders receiving session refresh messages MUST first perform the checks defined in Section 3.9 and Section 3.10, if applicable, before any further processing is executed. The NF SHOULD check with its local policies if it can accept the desired lifetime extension for the session referred by the session ID. Processing of this message is independent of the middlebox type. o NSLP responder: NRs accepting a session refresh CREATE/REA/REA-F message generate a RESPONSE message with response object set to success. NRs MUST perform the checks defined in Section 3.9 and Section 3.10, if applicable. 3.4.4 Deleting Sessions NATFW NSLP sessions may be deleted at any time. NSLP initiators can trigger this deletion by using a CREATE, REA, or REA-F messages with a lifetime value set to 0, as shown in Figure 18. 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 MUST first perform the checks defined in Section 3.9 and Section 3.10, if applicable, and afterwards MUST delete the session immediately. Policy rules associated with this particular session MUST be deleted immediately. This message is forwarded until it reaches the final NR. The CREATE/ REA/REA-F request 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. 3.4.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 Stiemerling, et al. Expires August 5, 2006 [Page 37] Internet-Draft NAT/FW NSIS NSLP February 2006 to allow reporting back to the NATFW NSLP initiator. Such asynchronous events may be premature session termination, changes in local policies, route change or any other reason that indicates change of the NATFW NSLP session state. Currently, asynchronous session termination, re-authorization required and route change detected (see Section 3.11) are the only events that are defined, but other events may be defined in later revisions of this memo. NFs and NRs may generate NOTIFY messages upon asynchronous events, with a response object indicating the reason of the event. NOTIFY messages are sentEhop-by-hop upstream towards NI until they reach NI. The initial processing when receiving a NOTIFY message is the same for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages through already established NTLP messaging associations. The further processing is different for each NATFW NSLP node type and depends on the events notified: o NSLP initiator: NIs analyze the notified event and behave appropriately based on the event type. Section 4.3.4 discusses the required behavior for each notified event. NIs MUST NOT generate NOTIFY messages. o NSLP forwarder: NFs receiving NOTIFY messages MUST first perform the checks defined in Section 3.9 and Section 3.10, if applicable, and MUST only accept NOTIFY messages from downstream peers via an already existing NTLP messaging association. After successfully doing so, NFs analyze the notified event and behave based on the notified events defined in Section 4.3.4. NFs SHOULD generate NOTIFY messages upon asynchronous events and forward them upstream towards the NI. NOTIFY messages are sent further hop-by-hop upstream towards the NI. o NSLP responder: NRs SHOULD generate NOTIFY messages upon asynchronous events with 'response object(s)' code based on the reported event(s). NRs receiving NOTIFY messages MUST ignore this message and discard it. NOTIFY messages are sent hop-by-hop upstream towards NI EDITOR's note: The current semantics can result in NOTIFICATION storms. There is a better semantics needed, how to avoid those storms and how NOTIFY messages are handled along the path. Elwyn noted: What to do if more than one node detects a failure condition along the path. What happens than? 3.4.6 Tracing Signaling Sessions The NATFW NSLP provides a diagnosis capability to session owners (the Stiemerling, et al. Expires August 5, 2006 [Page 38] Internet-Draft NAT/FW NSIS NSLP February 2006 NI or NI+). Session owners are able to trace the NSIS nodes being involved in a particular signaling session. The TRACE request message is used to trace the involved NSIS nodes along the signaling session and to return their identifiers. NI Public Internet NAT Private address NR | | space | | TRACE | | |----------------------------->| | | | | | | TRACE | | |--------------------------->| | | | | | RESPONSE[IP(NR)] | | |<---------------------------| | RESPONSE[IP(NR),IP(NAT)] | | |<-----------------------------| | | | | | | | Figure 19: Example for tracing the signaling session path The processing when receiving a TRACE message is the different for each type of NATFW node: o NSLP initiator: NI generates TRACE request messages. o NSLP forwarder: NFs keep session state and forward the message. o NSLP responder: NRs receiving a TRACE request message terminate the forwarding and reply with a RESPONSE message including the NATFW_TRACE object. The NATFW_TRACE object MAY be filled by the NR with its IP address. Processing of a RESPONSE message to a TRACE request message is different for every NSIS node type: o NSLP initiator: The NI terminates the forwarding and checks the response message for further internal processing. o NSLP forwarder: NFs MAY include their identifier in the NATFW_TRACE object and increment the hop counter by one. This memo defines IPv4 and IPv6 IP addresses as possible node identifier. NFs MUST forward this type of RESPONSE. Stiemerling, et al. Expires August 5, 2006 [Page 39] Internet-Draft NAT/FW NSIS NSLP February 2006 o NSLP responder: A NR should never see such a RESPONSE message. It MUST discard the message and reply with an error message. 3.4.7 Proxy Mode for Data Receiver behind NAT Comment from Elwyn: The next three sections would benefit from a an introductory section . Some of the common text about NATFW_PROXY object and the naming of the xx-PROXY messages, etc., could be factored out, reducing the size of the text and making the whole thing clearer. Also the sections 3.3.7-3.3.9 should be reordered more logically. Some migration scenarios need specialized support to cope with cases whereonly the receiving side is running NSIS. End-to-end signaling is going to fail without NSIS support at both data sender and data receiver, unless the NATFW NSLP also gives the NR the ability to install state on the upstream path towards the data sender for downstream data packets. The goal of the method described is to trigger the network to generate a CREATE message at the edge-NAT on behalf of the data receiver. In this case, a NR can signal towards the Opportunistic Address as is performed in the standard REA message handling scenario for NATs as in Section 3.4.2.1. The message is forwarded until the edge-NAT is reached. A public IP address and port number is reserved at an edge-NAT. As shown in Figure 20, unlike the standard REA message handling case, the edge-NAT 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 and DR. This behavior requires an indication to the edge-NAT within the REA message if either the standard behavior (as defined in Section 3.4.2.1) is required or a CREATE message is required to be sent by the edge-NAT. This indication is that the REA message contains a NATFW_PROXY object. We distinguish a REA message containing a NATFW_PROXY object by calling it a REA-PROXY message. In addition when a CREATE message needs to be sent by the edge-NAT, the REA message may include the data sender's address (DTInfo), if available to the data receiver. Figure 20 shows this proxy mode REA as REA-PROXY. Stiemerling, et al. Expires August 5, 2006 [Page 40] Internet-Draft NAT/FW NSIS NSLP February 2006 DS Public Internet NAT Private address NR No NI NF space NI+ NR+ | | REA-PROXY[(DTInfo)] | | |<------------------------- | | | RESPONSE[Error/Success] | | | ---------------------- > | | | CREATE | | | ------------------------> | | | RESPONSE[Error/Success] | | | <---------------------- | | | | | | | Figure 20: REA Triggering Sending of CREATE Message on Separate Reverse Path The processing of REA-PROXY messages is different for every NSIS entity: o NSLP initiator (NI+): When the data sender's address information is known in advance the NI+ MAY include a DTInfo object in the REA-PROXY request message. When the data sender's address is not known, NI+'s MUST NOT include a DTInfo object. The NI+ MUST choose a random value and include it in the NONCE object. NI+ only generate REA-PROXY messages and should never receive them. o NSLP forwarder: NSLP forwarders receiving REA-PROXY messages MUST first perform the checks defined in Section 3.9 and Section 3.10, if applicable, before any further processing is executed. The NF SHOULD check with its local policies if it can accept the desired policy rule given by NTLP's message routing information (MRI). Further processing depends on the middlebox type: * NAT: NATs check whether the message is received at the external (public in most cases) address or at the internal (private) address. If received at the external address a NF SHOULD generate a RESPONSE message with an error of type 'REA received from outside' and stop forwarding. If received at the internal address, an IP address/port is reserved. If it is not an edge-NAT, the NSLP message is forwarded further with the translated IP address/port. If it is an edge-NAT, the NSLP message is not forwarded any further. The edge-NAT checks whether it is willing to send CREATE messages on behalf on NI+ and if so, it checks the DTInfo object. The edge-NAT MAY reject the REA-PROXY request if there is no DTInfo object or if Stiemerling, et al. Expires August 5, 2006 [Page 41] Internet-Draft NAT/FW NSIS NSLP February 2006 the address information within DTInfo is not valid or too much wildcarded. If accepted, a RESPONSE message is generated containing an External Address Object (either IPv4 or IPv6 version, as appropriate) holding the translated address port information in the binding reserved as a result of the REA message. The RESPONSE message is sent back towards the NI+. When the edge-NAT accepts, it generates a CREATE message as defined in Section 3.4.1 and includes a NONCE object having the same value as of the received NONCE object. The edge-NAT MUST not generate a CREATE-PROXY message (see below xref target="proxy_sender"/>). The edge-NAT MUST refresh the CREATE message session only if a REA-PROXY refresh message has been received first. * Firewall: firewalls MUST not change their configuration upon a REA message. They simply MUST forward the message and MUST keep NTLP state. Edge-firewalls SHOULD reply with an error RESPONSE indicating 'no egde-NAT here'. * 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 SHOULD be discarded silently. Processing of a RESPONSE message with an 'external address' object is different for every NSIS node type: o NSLP initiator: Upon receiving a RESPONSE message with an external address object, the NI+ can use the IP address and port pairs carried for further application signaling. o NSLP forwarder: NFs simply forward this message as long as they keep state for the requested reservation. o NSIS responder: This type of message should never be received by an NR and it SHOULD be discarded silently. o Edge-NATs/edge-firewall: This type of message should never be received by any Edge-NAT/edge-firewall and it SHOULD be discarded silently. 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: Stiemerling, et al. Expires August 5, 2006 [Page 42] Internet-Draft NAT/FW NSIS NSLP February 2006 a) DS is NSIS unaware but DR assumes DS to be NSIS aware and b) DS is NSIS aware but DR assumes 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. The edge-NAT will send CREATE messages and DS will send CREATE messages too. Both CREATE messages are handled as separated sessions and therefore the common rules per session apply. It is the NR's responsibility to decide whether to teardown the REA-PROXY 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 sessions. The NONCE object is used to build the relationship between received CREATEs and the message initiator. An NI+ uses the presence of the NATFW_NONCE object to correlate it to the particular REA-PROXY request. The absence of an NONCE object indicates a CREATE initiated by the DS and not by the edge-NAT. There is a possible race condition between the RESPONSE message to the REA-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 REA-PROXY request was not received. 3.4.8 Proxy Mode for Data Sender behind Middleboxes As with data receivers behind middleboxes in Section 3.4.7 data senders behind middleboxes 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 request 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). This proxy mode handles only data senders behind a middlebox; for receivers behind a NAT see Section 3.4.7 and for receivers behind a firewall see Section 3.4.9. NIs being aware about a NSIS unaware DR, send a CREATE message towards DR with a proxy support object (NATFW_PROXY). We distinguish Stiemerling, et al. Expires August 5, 2006 [Page 43] Internet-Draft NAT/FW NSIS NSLP February 2006 a CREATE message containing a NATFW_PROXY object by calling it a CREATE-PROXY message. Intermediate NFs can use this additional information to decide whether to terminate the message forwarding or not. This proxy support object is an implicit scoping of the CREATE message. Termination of CREATE-PROXY request messages with proxy support object included MUST only be done by the outermost egde-NATs/ edge-firewalls. DS Private Address FW Public Internet NR NI Space NF no NR | | | | CREATE-PROXY | | |------------------------------>| | | | | | RESPONSE[SUCCESS/ERROR] | | |<------------------------------| | | | | Figure 21: Proxy Mode Create Message Flow The processing of CREATE-PROXY messages and RESPONSE messages is similar to Section 3.4.1, except that forwarding is stopped at the edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to NI according the situation (error/success) and will be the NR for future NATFW NSLP communication. 3.4.9 Proxy Mode for Data Receiver behind Firewall Data receivers behind firewalls would like to use a similar sort of proxy mode operation compared to those behind NATs. While finding an upstream edge-NAT is quite easy (it is only required to find some edge-NAT as the data traffic will be route-pinned to the NAT), locating the appropriate edge-firewall is difficult. Where a data receiver is located in a site network that is multihomed with several independently firewalled connections to the public Internet, the specific firewall through which the data traffic will be routed has to be ascertained. With this knowledge, proxy mode support that is similar to Section 3.3.7 can be used to install appropriate "allow" rules in the firewall through which the data traffic will be routed. Being able to identify the firewall through which data from a given source address will be routed is also essential for implementing the capability to install a blocking rule for incoming traffic in a firewall which defaults to "allow all". In the first case the Stiemerling, et al. Expires August 5, 2006 [Page 44] Internet-Draft NAT/FW NSIS NSLP February 2006 downstream data path must be fully enabled by signaling from the edge-firewall towards the data receiver in case there are additional firewalls along the path. This additional signaling is not needed in the blocking case as the intention is prevent traffic entering the site. The REA-F (firewall-REA) is used to locate upstream firewalls and to request installation of the appropriate policy rules. The goal of the method described is to trigger the network to generate a CREATE message at the edge-firewall on behalf of the data receiver when this is needed for an 'allow' rule. Provided the data sender's IP address is known, a NR can signal towards the data sender's address as in the standard REA-F message handling scenario for firewalls Section 3.4.2.2. The message is forwarded until it reaches the edge- firewall. As shown in Figure 22, the edge-firewall is triggered to send a CREATE message on a new reverse path which traverses through internal firewalls or NATs. The new reverse path for CREATE is necessary to handle routing asymmetries between the edge-firewall and DR. REA-F does not install any policy rule but the subsequent CREATE message initiated by the edge-firewall does. EDITOR's note: The above paragraph describes just the allow case. The proxy thing is not needed if a 'deny' rule is requested. DS Public Internet FW Private address NR No NI NF space NI+ NR+ | | REA-F-PROXY | | |<------------------------- | | | RESPONSE[Error/Success] | | | ---------------------- > | | | CREATE | | | ------------------------> | | | RESPONSE[Error/Success] | | | <---------------------- | | | | | | | Figure 22: REA-F Triggering Sending of CREATE Message on Separate Reverse Path The processing of REA-F-PROXY messages is different for every NSIS Stiemerling, et al. Expires August 5, 2006 [Page 45] Internet-Draft NAT/FW NSIS NSLP February 2006 entity: o NSLP initiator (NI+): NI+ MUST always direct REA-F-PROXY message to the address of DS. NI+ only generates REA-F messages and should never receive them. o NSLP forwarder: NSLP forwarders receiving REA-F messages MUST first perform the checks defined in Section 3.9 and Section 3.10, if applicable, before any further processing is executed. The NF SHOULD check with its local policies if it can accept the desired policy rule given by NTLP's message routing information (MRI). Further processing 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 internal interface, NATs allocated a public IP address and port and forward the message further. Edge-NATs receiving REA-F-PROXY SHOULD response with error RESPONSE indicating 'no edge-firewall' * Firewall: Non edge-firewalls keep session state and forward the message. Edge-firewalls stop forwarding the check for performing the checks defined in Section 3.9 and Section 3.10, if applicable. If the message is accepted, load the specified policy rule and if the policy rule action is "allow", generate CREATE messages back towards the DR as defined in Section 3.4.1. In any case generate a RESPONSE message indicating success or failure and send it back towarsd the NI+. * Combined NAT and firewall: Processing at combined firewall and NAT middleboxes is the same as in the firewall case. o NSLP receiver: This type of message should never be received by any NR+ and it SHOULD be discarded silently. Processing of a RESPONSE message is different for every NSIS node type: o NSLP initiator (NI+): Upon receiving a RESPONSE message NI+ should await incoming corresponding CREATE messages if the UCREATE-PROXY message was sent with an "allow" rule o NSLP forwarder: NFs simply forward this message as long as they keep state for the requested reservation. o NSIS responder: This type of message should never be received by an NR and it SHOULD be discarded silently. Stiemerling, et al. Expires August 5, 2006 [Page 46] Internet-Draft NAT/FW NSIS NSLP February 2006 o Edge-NATs/edge-firewall: This type of message should never be received by any Edge-NAT/edge-firewall and it SHOULD be discarded silently. There is a possible race condition between the RESPONSE message to the REA-F-PROXY and the CREATE message generated by the edge- firewall. The CREATE message can arrive earlier than the RESPONSE message. An NI+ MUST accept CREATE messages generated by the edge- firewall even if the RESPONSE message to the REA-F-PROXY request was not received. 3.5 Calculation of Session Lifetime NATFW NSLP sessions, and the corresponding policy rules which may have been installed, are maintained via soft-state mechanisms. Each session is assigned a lifetime and the session is kept alive as long as the lifetime is valid. After the expiration of the lifetime, sessions and policy rules MUST be removed automatically and resources bound to them should be freed as well. Session lifetime is handled at every NATFW NSLP node. The NSLP forwarders and NSLP responder are not responsible for triggering lifetime extension refresh messages (see Section 3.4.3): this is the task of the NSIS initiator. The NSIS initiator MUST choose a session lifetime (expressed in seconds) value before sending any message including the initial message which creates the session (lifetime is set to zero for deleting sessions) to other NSLP nodes. The 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 session hijacking ([8]). Session hijacking is made easier when the NI does not explicitly remove the session. o The user application's data exchange duration, in terms of time and networking needs. This duration is modeled as M x R, with R the message refresh period (in seconds) and M a multiplier for R. The RSVP specification [13] provides an approriate algorithm for calculating the session lifetime as well as means to avoid refresh message synchronization between sessions. [13] recommends: 1. The refresh message timer to be randomly set to a value in the range [0.5R, 1.5R]. Stiemerling, et al. Expires August 5, 2006 [Page 47] Internet-Draft NAT/FW NSIS NSLP February 2006 2. To avoid premature loss of state, L (with L being the session lifetime) must satisfy L >= (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 session lifetime and the refresh message period, the algorithm provided is only given as an example. This requested lifetime value is placed in the 'lifetime' object of the NSLP message and messages are forwarded to the next NATFW NSLP node. NATFW NFs processing the request message along the path MAY change the requested lifetime to fit their needs and/or local policy. If an NF changes the lifetime value it must also indicate the corresponding refresh message period. NFs MUST NOT increase the lifetime value; they MAY reject the requested lifetime immediately and MUST generate an error response message of type 'lifetime too big' upon rejection. The NSLP request message is forwarded until it reaches the NSLP responder. NSLP responder MAY reject the requested lifetime value and MUST generate an error response message of type 'lifetime too big' upon rejection. The NSLP responder MAY also lower the requested lifetime to an acceptable value (based on its local policies). NSLP responders generate their appropriate response message for the received request message, sets the lifetime value to the above granted lifetime and sends the message back hop-by-hop towards NSLP initiator. Each NSLP forwarder processes the response message, reads and stores the granted lifetime value. The forwarders SHOULD accept the granted lifetime, as long as the value is within the tolerable lifetime range defined in their local policies. They MAY reject the lifetime and generate a 'lifetime not acceptable' error response message. Figure 23 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. Stiemerling, et al. Expires August 5, 2006 [Page 48] Internet-Draft NAT/FW NSIS NSLP February 2006 +-------+ CREATE(lt=60s) +-----------+ CREATE(lt=20s) +--------+ | |---------------->| NSLP |---------------->| | | NI | | | | NR | | |<----------------| forwarder |<----------------| | +-------+ RESPONSE(lt=15s +-----------+ RESPONSE(lt=15s +--------+ MRR=3s) MRR=3s) lt = lifetime MRR = Message Refresh Rate Figure 23: Lifetime Calculation Example 3.6 Message Sequencing NATFW NSLP messages need to carry an identifier so that all nodes along the path can distinguish messages sent at different points of 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 sequence number (MSN), see also Section 4.3.7. The MSN MUST be set by the NI and MUST NOT be set or modified by any other node. The initial value for the MSN MUST be generated randomly and MUST be unique only within the 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. EDITOR's note: Is it needed to apply this: 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/REA/UCREATE packet which creates the session as start value for the session. NFs and NRs MUST include the received MSN value in the corresponding RESPONSE message that they generate. When receiving a request 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 Stiemerling, et al. Expires August 5, 2006 [Page 49] Internet-Draft NAT/FW NSIS NSLP February 2006 NSLP MUST update its stored state accordingly, if permitted by all security checks (see Section 3.9 and Section 3.10), and stores the updated MSN value accordingly. For, example, applying these semantics to a CREATE message exchange mean that the first CREATE and carries the initial, randomly generated, MSN. All nodes along the path store this value and the NR includes the received value in its response (assuming that the CREATE message reaches the NR). Subsequent CREATE messages, updating the request policy rule or lifetime, carry an incremented MSN value, so that intermediate nodes can recognize the requested update. 3.7 De-Multiplexing at NATs Section 3.4.2.1 describes how NSIS nodes behind NATs can obtain a public reachable IP address and port number at a NAT and how it can be activated by using CREATE messages (see Section 3.4.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 requests are related to reserved addresses, meaning how to de-multiplex incoming NSIS requests. The de-multiplexing method uses information stored at NATs (such as mapping of public IP address to private, transport protocol, port numbers), information given by NTLP's message routing information and further authentication credentials. 3.8 Selecting Opportunistic Addresses for REA As with all other message types, REA messages need a reachable final destination IP address. But as many applications do not provide a destination IP address in the first place, there is a need to choose a destination address for REA messages. This destination address can be the final target, but for applications which do not provide an upfront address, the destination address has to be chosen independently. Choosing the 'correct' destination IP address may be difficult and it is possible there is no 'right answer'. [17] shows choices for SIP and this section provides some hints about choosing a good destination IP address. Stiemerling, et al. Expires August 5, 2006 [Page 50] Internet-Draft NAT/FW NSIS NSLP February 2006 1. Public IP address of the data sender: * Assumption: + The data receiver already learned the IP address of the data sender (e.g., via a third party). * Problems: + The data sender might also be behind a NAT. In this case the public IP address of the data receiver is the IP address allocated at this NAT. + Due to routing asymmetry it might be possible that the routes taken by a) the data sender and the application server b) the data sender and NAT B might be different, this could happen in a network deployment such as in Figure 14. As a consequence it might be necessary to advertise a new (and different) external IP address within the application (which may or may not allow that) after using NSIS to establish a NAT binding. 2. Public IP address of the data receiver: * Assumption: + The data receiver already learned his externally visible IP address (e.g., based on the third party communication). * Problems: + Communication with a third party is required. 3. IP address of the Application Server: * Assumption: + An application server (or a different third party) is available. * Problems: + If the NSIS signaling message is not terminated at the NAT of the local network then an NSIS unaware application server might discard the message. + Routing might not be optimal since the route between a) the data receiver and the application server b) the data Stiemerling, et al. Expires August 5, 2006 [Page 51] Internet-Draft NAT/FW NSIS NSLP February 2006 receiver and the data sender might be different. 3.9 Session Ownership Proof of session ownership is a fundamental part of the NATFW NSLP signaling protocol. It is used to validate the origin of a request, i.e., invariance of the message sender. Only request messages showing a valid session ownership are processed further. Within the NATFW NSLP, the NSIS initiator (the NI or the NI+) is the ultimate session owner for all request messages. A proof of ownership MUST be provided for any request message sent downstream or upstream. All intermediate NATFW NSLP nodes MUST use this proof of ownership to validate the message's origin. All NATFW nodes along the path must be able to verify that the sender of a request is the same entity that initially created the session. Generally, the path taken spans different administrative domains and cannot rely on using a common authentication scheme. This requirement demands a scheme independent of the local authentication scheme in use and administrative requirements being enforced. Relying on a public key infrastructure (PKI) for the purpose of prove of session ownership is not reasonable due to deployment problems of a global PKI. The NATFW NSLP relies on the session ID (SID) carried in the NTLP for prove of session ownership. The session ID MUST be generated in a random way. Messages for a particular session are handled by the NTLP to the NATFW NSLP for further processing. Messages carrying a different session ID not associated with any NATFW NSLP are subject to the regular processing for new NATFW NSLP sessions. 3.10 Authentication and Authorization NATFW NSLP nodes receiving signaling messages MUST first check whether this message is authenticated and authorized to perform the requested action. The NATFW NSLP is expected to run in various environments, such as IP 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 a stronger authenticated/authorized signaling. This enterprise scenario may require the use of an infrastructure and administratively assigned identities to operate the NATFW NSLP. Stiemerling, et al. Expires August 5, 2006 [Page 52] Internet-Draft NAT/FW NSIS NSLP February 2006 EDITOR's note: It is still not clear what are the requirements for authentication and authorization in the NATFW case. This is going to be discussed at the next IETF meeting. 3.11 Reacting to Route Changes The NATFW NSLP needs to react to route changes in the data path. This assumes the capability to detect route changes, to perform NAT and firewall configuration on the new path and possibly to tear down session state on the old path. The detection of route changes is described in Section 7 of [1] and the NATFW NSLP relies on notifications about route changes by the NTLP. This notification will be conveyed by the API between NTLP and NSLP, which is out of scope of this memo. A NATFW NSLP node other than the NI or NI+ detecting a route change, by means described in the NTLP specification or others, generates a NOTIFY message indicating this change and sends this upstream towards NI. Intermediate NFs on the way to the NI can use this information to decide later if their session can be deleted locally if they do not receive an update within a certain time period (EDITOR's note: what should be the default value for this time period?). It is important to consider the transport limitations of NOTIFY messages as mandate in Section 3.4.5. NOTIFY messages and therefore route change notifications and only accept from downstream peers via existing NTLP messaging associations. (EDITOR's note: double check this measure! It might be appropriate to allow NOTIFY messages to be sent up- and downstream and just to mandate the MA transport). The NI receiving this NOTIFY message SHOULD generate an update message and sends it downstream as for the initial exchange. All the remaining processing and message forwarding, such as NSLP next hop discovery, is subject to regular NSLP processing as described in the particular sections. Merge points, NFs receiving update request messages (see also Section 3.12), can easily use the session ID (session ownership information, see also Section 3.9) to update the session. 3.12 Updating Policy Rules NSIS initiators can request an update of the installed/reserved policy rules at any time within a signaling session. Updates to policy rules can be required due to node mobility (NI is moving from one IP address to another), route changes (this can result in a different NAT mapping at a different NAT device), or the wish of the NI to simply change the rule. NIs can update policy rules in existing signaling sessions by sending an appropriate request message (similar to Section 3.5) with a different message routing information Stiemerling, et al. Expires August 5, 2006 [Page 53] Internet-Draft NAT/FW NSIS NSLP February 2006 (MRI) than installed before. This update request message is treated with respect to authorization and authentication exactly as any initial request. Therefore, any node along in the signaling session can reject the update with an error response. A node rejecting the update MUST reply with an error message indicating the error reason . The request/response message processing and forwarding is executed as defined in the particular sections. The local procedures on how to update the MRI in the firewall/NAT is out of scope of this memo. Stiemerling, et al. Expires August 5, 2006 [Page 54] Internet-Draft NAT/FW NSIS NSLP February 2006 4. NATFW NSLP Message Components A NATFW NSLP message consists of a NSLP header and one or more objects following the header. The NSLP header is common for all NSLPs and objects are Type-Length-Value (TLV) encoded using big endian (network ordered) binary data representations. Header and objects are aligned to 32 bit boundaries and object lengths that are not multiples of 32 bits must be padded to the next higher 32 bit multiple. The whole NSLP message is carried as payload of a NTLP message. Note that the notation 0x is used to indicate hexadecimal numbers. 4.1 NSLP Header The NSLP header is common to all NSLPs and is the first part of all NSLP messages. It contains two fields, the NSLP message type and a reserved field. The total length is 32 bits. The layout of the NSLP header is defined by Figure 24. 0 16 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP message type | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 24: Common NSLP header The reserved field MUST be set to zero in the NATFW NSLP header before sending and MUST be ignored during processing of the header. Note that other NSLPs use this field as a flag field. 4.2 NSLP Message Types The message types identify requests and responses. Defined messages types are: o 0x0101 : CREATE o 0x0102 : RESERVE-EXTERNAL-ADDRESS(REA) o 0x0104 : REA-F Stiemerling, et al. Expires August 5, 2006 [Page 55] Internet-Draft NAT/FW NSIS NSLP February 2006 o 0x0201 : RESPONSE o 0x0301 : NOTIFY 4.3 NSLP Objects NATFW NSLP objects use a common header format defined by Figure 25. The object header contains two fields, the NSLP object type and the object length. Its total length is 32 bits. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B|r|r| Object Type |r|r|r|r| Object Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: Common NSLP object header The length is the total length of the object without the object header. The unit is a word, consisting of 4 octets. The particular values of type and length for each NSLP object are listed in the subsequent sections that define the NSLP objects. The two leading bits of the NSLP object header are used to signal the desired treatment for objects whose treatment has not been defined in this memo (see [1], Section A.2.1), i.e., the Object Type has not been defined. NATFW NSLP uses a subset of the categories defined in GIST: o AB=00 ("Mandatory"): If the object is not understood, the entire message containing it must be rejected with an error indication. o AB=01 ("Optional"): If the object is not understood, it should be deleted and then the rest of the message processed as usual. o AB=10 ("Forward"): If the object is not understood, it should be retained unchanged in any message forwarded as a result of message processing, but not stored locally. The combination AB=11 MUST NOT be used. The following sections do not repeat the common NSLP object header, they just state the type and the length. Stiemerling, et al. Expires August 5, 2006 [Page 56] Internet-Draft NAT/FW NSIS NSLP February 2006 4.3.1 Session Lifetime Object The session lifetime object carries the requested or granted lifetime of a NATFW NSLP session measured in seconds. The Message refresh rate value is set by default to 0xFFFF and only set to a specific value when an intermediate node changes the message lifetime and informs the upstream node about the recommended message refresh rate. Type: NATFW_LT Length: 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NATFW NSLP session lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NATFW NSLP message refresh rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26: Lifetime object 4.3.2 External Address Object The external address object can be included in RESPONSE messages (Section 4.4.3) only. Type: NATFW_EXT_IPv4 Length: 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | port number | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: External Address Object for IPv4 addresses Stiemerling, et al. Expires August 5, 2006 [Page 57] Internet-Draft NAT/FW NSIS NSLP February 2006 Type: NATFW_EXT_IPv6 Length: 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | port number | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 28: External Address Object for IPv6 addresses Please note that the field 'port number' MUST be set to 0 if only an IP address has been reserved, for instance, by a traditional NAT. A port number of 0 MUST be ignored in processing this object. 4.3.3 Extended Flow Information Object In general, flow information is kept in the message routing information (MRI) of the NTLP. Nevertheless, some additional information may be required for NSLP operations. The 'extended flow information' object carries this additional information about the policy rule's action for firewalls/NATs. Type: NATFW_EFI Length: 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule action | sub_ports | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: Extended Flow Information Stiemerling, et al. Expires August 5, 2006 [Page 58] Internet-Draft NAT/FW NSIS NSLP February 2006 This object has two fields, 'rule action' and 'sub_ports'. The 'rule action' field has these meanings: o Allow: A policy rule with this action allows data traffic to traverse the middlebox and the NATFW NSLP MUST allow NSLP signaling to be forwarded. o Deny: A policy rule with this action blocks data traffic from traversing the middlebox and the NATFW NSLP MUST NOT allow NSLP signaling to be forwarded. o Accept: A policy rule with this action blocks data traffic from traversing the middlebox and the NATFW NSLP MUST allow NSLP signaling to be forwarded. The 'sub_ports' field contains the number of subsequent transport layer ports. The default value of this field is 0, i.e., only the port specified in the NTLP's MRM is used for the policy rule. A value of 1 indicates that additionally to the port specified in the NTLP's MRM (port1), a second port (port2) is used. This port's value is calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT be used in this field, but further version of this memo may allow other values. This two subsequent port numbers feature can be used by legacy voice over IP equipment. This legacy equipment assumes two subsequent port numbers for its RTP/RTCP flows. 4.3.4 Response Code Object This object carries the response code, which may be indications for either a successful request or failed request depending on the value of the 'response code' field. Type: NATFW_RESPONSE Length: 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | response code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 30: Response Code Object TBD: Define response classes, success codes and error codes. Possible error classes are: Stiemerling, et al. Expires August 5, 2006 [Page 59] Internet-Draft NAT/FW NSIS NSLP February 2006 o Policy rule errors o Authentication and Authorization errors o NAT Currently errors defined in this memo are: o lifetime too big o lifetime not acceptable o no NAT here o no reservation found o requested external address from outside o re-authorization needed o routing change detected 4.3.5 Proxy Support Object This object indicates that proxy mode support is required. Either in a REA message or CREATE message. Type: NATFW_PROXY Length: 0 4.3.6 Nonce Object Type: NATFW_NONCE Length: 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 31: Nonce Object Stiemerling, et al. Expires August 5, 2006 [Page 60] Internet-Draft NAT/FW NSIS NSLP February 2006 4.3.7 Message Sequence Number Object This object carries the MSN value as described in Section 3.6. Type: NATFW_RESP_MSN Length: 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 32: Message Sequence Number Object 4.3.8 Data Terminal Information Object The 'data terminal information' object carries additional information possibly needed during REA operations. REA messages are transported by the NTLP using the Loose-End message routing method (LE-MRM). The LE-MRM contains only DR's IP address and a signaling destination address (destination address). This destination address is used for message routing only and is not necessarily reflecting the address of the data sender. This object contains information about (if applicable) DR's port number (the destination port number), DS' port number (the source port number), the used transport protocol, the prefix length of the IP address, and DS' IP address. Type: NATFW_DSINFO_IPv4 Length: 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| reserved | dest prefix | protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dst port number | src port number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | src IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stiemerling, et al. Expires August 5, 2006 [Page 61] Internet-Draft NAT/FW NSIS NSLP February 2006 Figure 33: Data Terminal IPv4 Address Object Type: NATFW_DSINFO_IPv6 Length: 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| reserved | dest prefix | protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dst port number | src port number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + src IPv6 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 34: Data Terminal IPv6 Address Object for IPv6 addresses The fields MUST be interpreted according these rules: o dest prefix: This parameter indicates the prefix length of the 'src IP address' in bits. For instance, a full IPv4 address requires 'dest prefix' to be set to 32. A value of 0 indicates an IP address wildcard. o protocol: The IPv4 protocol field or the last IPv6 header. This field MUST be interpreted if P=1, otherwise it MUST be set to 0 and MUST be ignored. o dst port number: A value of 0 indicates a port wildcard, i.e., the destination port number is not known. Any other value indicates the destination port number. o src port number: A value of 0 indicates a port wildcard, i.e., the source port number is not known. Any other value indicates the source port number. o src IPv4/IPv6 address: The source IP address of the data sender. This field MUST be set to zero if no IP address is provided, i.e., a complete wildcard is desired (see dest prefix field above). Stiemerling, et al. Expires August 5, 2006 [Page 62] Internet-Draft NAT/FW NSIS NSLP February 2006 4.3.9 Trace Object la Type: NATFW_TRACE Length: Variable +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | trace type | hop count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IP address : : ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 35: External Address Object for IPv4 addresses The NATFW_TRACE object may contain zero or more identifiers. The type of identifier is given by the value of 'trace type' field. This memo is defining the values for the 'trace type' field: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses. The 'hop count' field counts the total number of visited NATFW NSLP nodes that are willing to include their identifier in this object. Each node is appending its identifier at the end of the object. 4.4 Message Formats This section defines the content of each NATFW NSLP message type. The message types are defined in Section 4.2. First, the request messages are defined with their respective objects to be included in the message. Second, the response messages are defined with their respective objects to be included. Basically, each message is constructed of NSLP header and one or more NSLP objects. The order of objects is not defined, meaning that objects may occur in any sequence. Objects are marked either with mandatory [M] or optional [O]. Where [M] implies that this particular object MUST be included within the message and where [O] implies that this particular object is OPTIONAL within the message. Each section elaborates the required settings and parameters to be set by the NSLP for the NTLP, for instance, how the message routing information is set. Stiemerling, et al. Expires August 5, 2006 [Page 63] Internet-Draft NAT/FW NSIS NSLP February 2006 4.4.1 CREATE The CREATE request message is used to create NSLP sessions and to create policy rules. Furthermore, CREATE messages are used to refresh sessions and to delete them. The CREATE message carries these objects: o Lifetime object [M] o Extended flow information object [M] o Message sequence number object [M] o Proxy support object [O] o Nonce object [M if CREATE-PROXY message, otherwise O] The message routing information in the NTLP MUST be set to DS as source address and DR as destination address. All other parameters MUST be set according the required policy rule. CREATE messages MUST be transported by using the path-coupled MRM. 4.4.2 RESERVE-EXTERNAL-ADDRESS (REA) The RESERVE-EXTERNAL-ADDRESS (REA) request message is used to a) reserve an external IP address/port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to block incoming data traffic at upstream firewalls. All case can be used in proxy mode operations. The REA for NATs (case a)) request message carries these objects: o Lifetime object [M] o Message sequence number object [M] o Data terminal information object [M] o Proxy support object [O] o Nonce object [M if proxy support object is included, otherwise O] The REA for NATs message needs special NTLP treatment. First of all, REA for NATs messages travel the wrong way, from the DR towards DS. Second, the DS' address used during the signaling may be not the actual DS (see Section 3.8). REA for NATs messages MUST be transported by using the loose-end MRM defined in Section 5.8.2. of [1]. Stiemerling, et al. Expires August 5, 2006 [Page 64] Internet-Draft NAT/FW NSIS NSLP February 2006 The REA for firewalls (case b) and c)) request message carries these objects: o Lifetime object [M] o Message sequence number object [M] o Extended flow information object [M] o Proxy support object [O] o Nonce object [M if proxy support object is included, otherwise O] The REA for firewalls message needs path-coupled MRM NTLP treatment but with messages being sent upstream towards the DS. 4.4.3 RESPONSE RESPONSE messages are responses to CREATE, REA, and REA-F messages. The RESPONSE message carries these objects: o Lifetime object [M] o Message sequence number object [M] o Response code object [M] o External address object [O]([M] for success responses to REA) This message is routed upstream hop-by-hop. EDITOR's note: Text says that this section is defining the behavior depending on the response type. 4.4.4 NOTIFY The NOTIFY messages is used to report asynchronous events happening along the signaled path to other NATFW NSLP nodes. The NOTIFY message carries this object: o Response code object with NOTIFY code [M]. The NOTIFY message is forwarded upstream hop-by-hop using the existing upstream node messaging association entry within the node's Message Routing State table. Stiemerling, et al. Expires August 5, 2006 [Page 65] Internet-Draft NAT/FW NSIS NSLP February 2006 4.4.5 REA-F The REA-F request message is used to install policy rules at upstream firewalls The REA-F request message carries these objects: o Lifetime object [M] o Message sequence number object [M] o Extended flow information object [M] o Proxy support object [O] REA-F messages MUST be sent by using the path-coupled MRM upstream towards the data sender's address. 4.4.6 TRACE The TRACEF request message is used to trace the involved NATFW NSLP nodes along a signal session. The TRACE request message carries these objects: o Message sequence number object [M] TRACE request messages are sent path-coupled (PC-MRM). Stiemerling, et al. Expires August 5, 2006 [Page 66] Internet-Draft NAT/FW NSIS NSLP February 2006 5. NATFW NSLP NTLP Requirements The NATFW NSLP requires the following capabilities from the NTLP: o Ability to detect that the NSIS Responder does not support NATFW NSLP. This capability is key to launching the proxy mode behavior as described in Section 3.4.7 and [15]. o Detection of NATs and their support of the NSIS NATFW NSLP. If the NTLP discovers that the NSIS host is behind an NSIS aware NAT, the NR will send REA messages to the opportunistic address. If the NTLP discovers that the NSIS host is behind a NAT that does not support NSIS then the NSIS host will need to use a separate NAT traversal mechanism. o Message origin authentication and message integrity protection o Detection of routing changes o Protection against malicious announcement of fake path changes, this is needed to mitigate a threat discussed in Section 7 of [8] Stiemerling, et al. Expires August 5, 2006 [Page 67] Internet-Draft NAT/FW NSIS NSLP February 2006 6. NSIS NAT and Firewall Transition Issues NSIS NAT and firewall transition issues are premature and will be addressed in a separate draft (see [15]). An update of this section will be based on consensus. Stiemerling, et al. Expires August 5, 2006 [Page 68] Internet-Draft NAT/FW NSIS NSLP February 2006 7. Security Considerations Security is of major concern particularly in case of firewall traversal. This section provides security considerations for the NAT/firewall traversal and is organized as follows: Section 7.1 describes the framework assumptions with regard to the assumed trust relationships between the participating entities. This subsection also motivates a particular authorization model. Security threats that focus on NSIS in general are described in [8] and they are applicable to this document. Within Section 7.2 we extend this threat investigation by considering NATFW NSLP specific threats. Based on the security threats we list security requirements. Finally we illustrate how the security requirements that were created based on the security threats can be fullfilled by specific security mechanisms. These aspects will be elaborated in Section 7.3. 7.1 Trust Relationship and Authorization The NATFW NSLP is a protocol which may involve a number of NSIS nodes and is, as such, not a two-party protocol. This fact requires more thoughts about scenarios, trust relationships and authorization mechanisms. Trust relationships and authorization are very important for the protocol machinery and they are closely related to each other in the sense that a certain degree of trust is required to authorize a particular action. For any action (e.g. create/delete pinholes), authorization is very important due to the nature of middleboxes. Different types of trust relationships may affect different categories of middleboxes. As explained in [23], establishment of a financial relationship is typically very important for QoS signaling, whereas financial relationships are less directly of interest for NATFW middlebox signaling. It is therefore not particularly surprising that there are differences in the nature and level of authorization likely to be required in a QoS signaling environment and in NATFW middlebox signaling. Typically NATFW signaling requires authorization to configure firewalls or to modify NAT bindings. The outcome of the authorization is either allowed or disallowed whereas QoS signaling might just indicate that a lower QoS reservation is allowed. Different trust relationships that appear in middlebox signaling environments are described in the subsequent sub-sections. As a comparison with other NSIS signaling application it might be interesting to mention that QoS signaling relies on peer-to-peer Stiemerling, et al. Expires August 5, 2006 [Page 69] Internet-Draft NAT/FW NSIS NSLP February 2006 trust relationships and authorization between neighboring nodes or neighboring networks. These type of trust relationships turn out to be simpler for a protocol. However, there are reasons to believe that this is not the only type of trust relationship found in today's networks. 7.1.1 Peer-to-Peer Trust Relationship Starting with the simplest scenario, it is assumed that neighboring nodes trust each other. The required security association to authenticate and to protect a signaling message is either available (after manual configuration), or has been dynamically established with the help of an authentication and key exchange protocol. If nodes are located closely together, it is assumed that security association establishment is easier than establishing it between distant nodes. It is, however, difficult to describe this relationship generally due to the different usage scenarios and environments. Authorization heavily depends on the participating entities, but for this scenario, it is assumed that neighboring entities trust each other (at least for the purpose of policy rule creation, maintenance, and deletion). Note that Figure 36 does not illustrate the trust relationship between the end host and the access network. +------------------------+ +-------------------------+ |Network A | | Network B| | +---------+ +---------+ | | +-///-+ Middle- +---///////----+ Middle- +-///-+ | | | | box 1 | Trust | box 2 | | | | | +---------+ Relationship +---------+ | | | | Trust | | Trust | | | | Relationship | | Relationship | | | | | | | | | +--+---+ | | +--+---+ | | | Host | | | | Host | | | | A | | | | B | | | +------+ | | +------+ | +------------------------+ +-------------------------+ Figure 36: Peer-to-Peer Trust Relationship 7.1.2 Intra-Domain Trust Relationship In larger corporations, often more than one middlebox is used to protect or serve different departments. In many cases, the entire enterprise is controlled by a security department, which gives instructions to the department administrators. In such a scenario, a Stiemerling, et al. Expires August 5, 2006 [Page 70] Internet-Draft NAT/FW NSIS NSLP February 2006 peer-to-peer trust-relationship might be prevalent. Sometimes it might be necessary to preserve authentication and authorization information within the network. As a possible solution, a centralized approach could be used, whereby an interaction between the individual middleboxes and a central entity (for example a policy decision point - PDP) takes place. As an alternative, individual middleboxes could exchange the authorization decision with another middlebox within the same trust domain. Individual middleboxes within an administrative domain should exploit their trust relationship instead of requesting authentication and authorization of the signaling initiator again and again. Thereby complex protocol interactions are avoided. This provides both a performance improvement without a security disadvantage since a single administrative domain can be seen as a single entity. Figure 37 illustrates a network structure which uses a centralized entity. +-----------------------------------------------------------+ | Network A | | +---------+ +---------+ | +----///--------+ Middle- +------///------++ Middle- +--- | | | box 2 | | box 2 | | | +----+----+ +----+----+ | +----+----+ | | | | | Middle- +--------+ +---------+ | | | | box 1 | | | | | | +----+----+ | | | | | | | +----+-----+ | | | | | | Policy | | | | +--+---+ +-----------+ Decision +----------+ | | | Host | | Point | | | | A | +----------+ | | +------+ | +-----------------------------------------------------------+ Figure 37: Intra-domain Trust Relationship 7.1.3 End-to-Middle Trust Relationship In some scenarios, a simple peer-to-peer trust relationship between participating nodes is not sufficient. Network B might require additional authorization of the signaling message initiator. If authentication and authorization information is not attached to the initial signaling message then the signaling message arriving at Middlebox 2 would result in an error message being created, which indicates the additional authorization requirement. In many cases the signaling message initiator is already aware of the additionally required authorization before the signaling message exchange is Stiemerling, et al. Expires August 5, 2006 [Page 71] Internet-Draft NAT/FW NSIS NSLP February 2006 executed. Replay protection is a requirement for authentication to the non-neighboring middlebox, which might be difficult to accomplish without adding additional roundtrips to the signaling protocol (e.g., by adding a challenge/response type of message exchange). Figure 38 shows the slightly more complex trust relationships in this scenario. +--------------------+ +---------------------+ | Network A | Trust |Network B | | | Relationship | | | +---------+ +---------+ | | +-///-+ Middle- +---///////----+ Middle- +-///-+ | | | | box 1 | +-------+ box 2 | | | | | +---------+ | +---------+ | | | |Trust | | | Trust | | | |Relationship | | | Relationship| | | | | | | | | | +--+---+ | | | +--+---+ | | | Host +----///----+------+ | | Host | | | | A | |Trust | | B | | | +------+ |Relationship | +------+ | +--------------------+ +---------------------+ Figure 38: End-to-Middle Trust Relationship 7.2 Security Threats and Requirements This section describes NATFW specific security threats and requirements. 7.2.1 Attacks related to authentication and authorization The NSIS message which installs policy rules at a middlebox is the CREATE message. The CREATE message travels from the Data Sender (DS) toward the Data Receiver (DR). The packet filter or NAT binding is marked as pending by the middleboxes along the path. If it is confirmed with a success RESPONSE message from the DR, the requested policy rules on the middleboxes are installed to allow the traversal of a data flow. Stiemerling, et al. Expires August 5, 2006 [Page 72] Internet-Draft NAT/FW NSIS NSLP February 2006 +-----+ +-----+ +-----+ | DS | | MB | | DR | +-----+ +-----+ +-----+ | | | | CREATE | CREATE | |-------------------->+-------------------->| | | | | Succeeded/Error | Succeeded/Error | |<--------------------+<--------------------| | | | ==========================================> Direction of data traffic Figure 39: CREATE Mode In this section we will consider some simple scenarios for middlebox configuration: o Data Sender (DS) behind a firewall o Data Sender (DS) behind a NAT o Data Receiver (DR) behind a firewall o Data Receiver (DR) behind a NAT A real-world scenario could include a combination of these firewall/ NAT placements, such as, a DS and/or a DR behind a chain of NATs and firewalls. Figure 40 shows one possible scenario: Stiemerling, et al. Expires August 5, 2006 [Page 73] Internet-Draft NAT/FW NSIS NSLP February 2006 +-------------------+ +--------------------+ | Network A | | Network B | | | | | | +-----+ | //-----\\ | +-----+ | | | MB2 |--------+----| INET |----+--------| MB3 | | | +-----+ | \\-----// | +-----+ | | | | | | | | +-----+ | | +-----+ | | | MB1 | | | | MB4 | | | +-----+ | | +-----+ | | | | | | | | +-----+ | | +-----+ | | | DS | | | | DR | | | +-----+ | | +-----+ | +-------------------+ +--------------------+ MB: Middle box (NAT or firewall or a combination) DS: Data Sender DR: Data Receiver Figure 40: Several middleboxes per network 7.2.1.1 Data Sender (DS) behind a firewall +------------------------------+ | | | +-----+ create +-----+ | | DS | --------------> | FW | | +-----+ +-----+ | | +------------------------------+ DS sends a CREATE message to request the traversal of a data flow. It is up to network operators to decide how far they can trust users inside their networks. However, there are several reasons why they should not. The following attacks are possible: o DS could open a firewall pinhole with a source address different from its own host. o DS could open firewall pinholes for incoming data flows that are not supposed to enter the network. Stiemerling, et al. Expires August 5, 2006 [Page 74] Internet-Draft NAT/FW NSIS NSLP February 2006 o DS could request installation of any policy rules and allow all traffic go through. SECURITY REQUIREMENT: The middlebox MUST authenticate and authorize the neighboring NAT/FW NSLP node which requests an action. Authentication and authorization of the initiator SHOULD be provided to NATs and firewalls along the path. 7.2.1.2 Data Sender (DS) behind a NAT The case 'DS behind a NAT' is analogous to the case 'DS behind a firewall'. Figure 42 illustrates such a scenario: +------------------------------+ | | | +------+ CREATE | | | NI_1 | ------\ +-----+ CREATE +-----+ | +------+ \------> | NAT |-------->| MB | | +-----+ +-----+ | +------+ | | | NI_2 | | | +------+ | +------------------------------+ Figure 42: Several NIs behind a NAT In this case the middlebox MB does not know who is the NSIS Initiator since both NI_1 and NI_2 are behind a NAT (which is also NSIS aware). Authentication needs to be provided by other means such as the NSLP or the application layer. SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that the neighboring NAT/FW NSLP node is authorized to request an action. Authentication and authorization of the initiator (which is the DR in this scenario) to the middleboxes (via another NSIS aware middlebox) SHOULD be provided. 7.2.1.3 Data Receiver (DR) behind a firewall In this case a CREATE message comes from an entity DS outside the network towards the DR inside the network. Stiemerling, et al. Expires August 5, 2006 [Page 75] Internet-Draft NAT/FW NSIS NSLP February 2006 +------------------------------+ | | +-----+ CREATE +-----+ CREATE +-----+ | | DS | -------------> | FW | -------------> | DR | | +-----+ <------------- +-----+ <------------- +-----+ | success RESPONSE | success RESPONSE | | | +------------------------------+ Since policy rules at middleboxes must only be installed after receiving a successful response it is necessary that the middlebox waits until the Data Receiver DR confirms the request of the Data Sender DS with a success RESPONSE message. This is, however, only necessary o if the action requested with the CREATE message cannot be authorized and o if the middlebox is still forwarding the signaling message towards the end host (without state creation/deletion/modification). This confirmation implies that the data receiver is expecting the data flow. At this point we differentiate two cases: 1. DR knows the IP address of the DS (for instance because of some previous application layer signaling) and is expecting the data flow. 2. DR might be expecting the data flow (for instance because of some previous application layer signaling) but does not know the IP address of the Data Sender DS. For the second case, Figure 44 illustrates a possible attack: an adversary Mallory M could be sniffing the application layer signaling and thus knows the address and port number where DR is expecting the data flow. Thus it could pretend to be DS and send a CREATE message towards DR with the data flow description (M -> DR). Since DR does not know the IP address of DS, it is not able to recognize that the request is coming from the "wrong guy". It will send a success RESPONSE message back and the middlebox will install policy rules that will allow Mallory M to inject its data into the network. Stiemerling, et al. Expires August 5, 2006 [Page 76] Internet-Draft NAT/FW NSIS NSLP February 2006 Application Layer signaling <------------------------------------> / \ / +-----------------\------------+ / | \ | +-----+ +-----+ +-----+ | | DS | -> | FW | | DR | | +-----+ / +-----+ +-----+ | CREATE / | | +-----+ / +-------------------------------+ | M |---------- +-----+ Figure 44: DR behind a firewall with an adversary Network administrators will probably not rely on a DR to check the IP address of the DS. Thus we have to assume the worst case with an attack such as in Figure 44. Many operators might not allow NSIS signaling message to traverse the firewall in Figure 44 without proper authorization. In this case the threat is not applicable. SECURITY REQUIREMENT: A binding between the application layer and the NSIS signaling SHOULD be provided. 7.2.1.4 Data Receiver (DR) behind a NAT When a data receiver DR behind a NAT sends a RESERVE-EXTERNAL-ADDRESS (REA) message to get a public reachable address that can be used as a contact address by an arbitrary data sender if the DR was unable to restrict the future data sender. The NAT reserves an external address and port number and sends them back to DR. The NAT adds an address mapping entry in its reservation list which links the public and private addresses as follows: (DR_ext <=> DR_int) (*). The NAT sends a RESPONSE message with the external address' object back to the DR with the address DR_ext. DR informs DS about the public address that it has recently received, for instance, by means of application layer signaling. When a data sender sends a CREATE message towards DR_ext then the message will be forwarded to the DR. The data sender might want to update the NAT binding stored at the edge-NAT to make it more restrictive. We assume that the adversary Mallory M obtains the contact address Stiemerling, et al. Expires August 5, 2006 [Page 77] Internet-Draft NAT/FW NSIS NSLP February 2006 (i.e., external address and port) allocated at the NAT possibly by eavesdropping on the application layer signaling and sends a CREATE message. As a consequence Mallory would be able to communicate with DR (if M is authorized by the edge-NAT and if the DR accepts CREATE and returns a RESPONSE. Application Layer signaling <------------------------------------> / \ / +-----------------\------------+ / | REA \ | +-----+ +-----+ <----------- +-----+ | | DS | -> | NAT | -----------> | DR | | +-----+ / +-----+ rtn_ext_addr +-----+ | CREATE / | | +-----+ / +-------------------------------+ | M |---------- +-----+ SECURITY REQUIREMENT: The DR MUST be able to specify which data sender are allowed to traverse the NAT in order to be forwarded to DRs address. 7.2.1.5 NSLP Message Injection Malicious hosts, located either off-path or on-path, could inject arbitrary NATFW NSLP messages into the signaling path, causing several problems. These problems apply when no proper authorization and authentication scheme is available. By injecting a bogus CREATE message with lifetime set to zero, a malicious host could try to teardown NATFW NSLP session state partially or completely on a data path, causing a service interruption. By injecting a bogus responses or NOTIFY message, for instance, timeout, a malicious host could try to teardown NATFW NSLP session state as well. This could affect the data path partially or totally, causing a service interruption. SECURITY REQUIREMENT: Messages, such as TRIGGER, can be misused by malicious hosts, and therefore need to be authorized. Stiemerling, et al. Expires August 5, 2006 [Page 78] Internet-Draft NAT/FW NSIS NSLP February 2006 7.2.2 Denial-of-Service Attacks In this section we describe several ways how an adversary could launch a Denial of service (DoS) attack on networks running NSIS for middlebox configuration to exhaust their resources. 7.2.2.1 Flooding with CREATE messages from outside 7.2.2.1.1 Attacks due to NSLP state A CREATE message requests the NSLP to store state information such as a NAT binding or a policy rule. The policy rules requested in the CREATE message will be installed at the arrival of a confirmation from the Data Receiver with a success RESPONSE message. A successful RESPONSE message includes the session ID. So the NSLP looks up the NSIS session and installs the requested policy rules. An adversary from outside could launch a DoS attack with arbitrary CREATE messages. For each of these messages the middlebox needs to store state information such as the policy rules to be loaded, i.e., the middlebox could run out of memory. This kind of attack is also mentioned in [8] Section 4.8. SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 'create- session' message before storing state information. 7.2.2.1.2 Attacks due to authentication complexity This kind of attack is possible if authentication is based on mechanisms that require computing power, for example, digital signatures. For a more detailed treatment of this kind of attack, the reader is encouraged to see [8]. SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new denial of service attacks based on authentication or key management mechanisms. 7.2.2.1.3 Attacks to the endpoints The NATFW NSLP requires firewalls to forward NSLP messages, a malicious node may keep sending NSLP messages to a target. This may consume the access network resources of the victim, drain the battery Stiemerling, et al. Expires August 5, 2006 [Page 79] Internet-Draft NAT/FW NSIS NSLP February 2006 of the victim's terminal and may force the victim to pay for the received although undesired data. This threat may be more particularly be relevant in networks where access link is a limited resource, for instance in cellular networks, and where the terminal capacities are limited. SECURITY REQUIREMENT: A NATFW NSLP aware firewall or NAT MUST be able to block unauthorized signaling message, if this threat is a concern. 7.2.2.2 Flooding with REA messages from inside Although we are more concerned with possible attacks from outside the network, we need also to consider possible attacks from inside the network. An adversary inside the network could send arbitrary RESERVE- EXTERNAL-ADDRESS messages. At a certain point the NAT will run out of port numbers and the access for other users to the outside will be disabled. SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, the NAT/FW NSLP implementation MUST prevent denial of service attacks involving the allocation of an arbitrary number of NAT bindings or the installation of a large number of packet filters. 7.2.3 Man-in-the-Middle Attacks Figure 46 illustrates a possible man-in-the-middle attack using the RESERVE-EXTERNAL-ADDRESS (REA) message. This message travels from DR towards the public Internet. The message might not be intercepted because there are no NSIS aware middleboxes. Imagine such an NSIS signaling message is then intercepted by an adversary Mallory (M). M returns a faked RESPONSE message whereby the adversary pretends that a NAT binding was created. This NAT binding is returned with the RESPONSE message. Malory might insert it own IP address in the response, the IP address of a third party or the address of a black hole. In the first case, the DR thinks that the address of Mallory M is its public address and will inform the DS about it. As a consequence, the DS will send the data traffic to Mallory M. The data traffic from the DS to the DR will re-directed to Mallory M. Stiemerling, et al. Expires August 5, 2006 [Page 80] Internet-Draft NAT/FW NSIS NSLP February 2006 M will be able to read, modify or block the data traffic (if the end- to-end communication itself does not experience protection). Eavesdropping and modification is only possible if the data traffic is itself unprotected. +-----+ +-----+ +-----+ | DS | | M | | DR | +-----+ +-----+ +-----+ | | | | | REA | | | <------------------ | | | | | | RESPONSE | | | ------------------> | | | | | data traffic | | |===============>| data traffic | | |====================>| Figure 46: MITM attack using the RESERVE-EXTERNAL-ADDRESS message SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW NSLP MUST be provided. To ensure that only legitimate nodes along the path act as NSIS entities the initiator MUST authorize the responder. In the example in Figure 46 the firewall FW must perform an authorization with the neighboring entities. 7.2.4 Message Modification by non-NSIS on-path node An unauthorized on-path node along the path towards the destination could easily modify, inject or just drop an NSIS message. It could also hijack or disrupt the communication. SECURITY REQUIREMENT: Message integrity, replay protection and data origin authentication between neighboring NAT/FW NSLPs MUST be provided. 7.2.5 Message Modification by malicious NSIS node Message modification by a NSIS node that became malicious is more serious. An adversary could easily create arbitrary pinholes or NAT bindings. For example: Stiemerling, et al. Expires August 5, 2006 [Page 81] Internet-Draft NAT/FW NSIS NSLP February 2006 o NATs need to modify the source/destination of the data flow in the 'create session' message. o Each middlebox along the path may change the requested lifetime in the CREATE message to fit their needs and/or local policy. SECURITY REQUIREMENT: None. Malicious NSIS NATs and firewalls will not be addressed. 7.2.6 Session Modification/Deletion The Session ID is included in signaling messages as a reference to the established state. If an adversary is able to obtain the Session Identifier for example by eavesdropping on signaling messages, it would be able to add the same Session Identifier to a new signaling message and effect some modifications. Consider the scenario described in Figure 47. Here an adversary pretends to be 'DS in mobility'. The signaling messages start from the DS and go through a series of routers towards the DR. We assume that an off-path adversary is connected to one of the routers along the old path (here Router 3). We also assume that the adversary knows the Session ID of the NSIS session initiated by the DS. Knowing the Session ID, the adversary now sends signaling messages towards the DR. When the signaling message reaches Router3 then existing state information can be modified or even deleted. The adversary can modify or delete the established reservation causing unexpected behavior for the legitimate user. The source of the problem is that the Router 3 (cross-over router) is unable to decide whether the new signaling message was initiated from the owner of the session. In this scenario, the adversary need not even be located in the DS-DR path. This problem and the solution approaches are described in more detail in [25]. Stiemerling, et al. Expires August 5, 2006 [Page 82] Internet-Draft NAT/FW NSIS NSLP February 2006 Session ID(SID-x) +--------+ +--------+ +-------->--------+ Router +-------->+ DR | Session ID(SID-x)| | 4 | | | +---+----+ +--------+ +--------+ | Router | +------+ 3 +******* | +---+----+ * | * | Session ID(SID-x) * Session ID(SID-x) +---+----+ +---+----+ | Access | | Access | | Router | | Router | | 1 | | 2 | +---+----+ +---+----+ | * | Session ID(SID-x) * Session ID(SID-x) +----+------+ +----+------+ | DS | | Adversary | | | | | +-----------+ +-----------+ Figure 47: State Modification by off-path adversary As a summary, an off-path adversary's knowledge of Session-ID could cause session modification/deletion. SECURITY REQUIREMENT: The initiator MUST be able to demonstrate ownership of the session it wishes to modify. 7.2.6.1 Misuse of mobility in NAT handling Another kind of session modification is related to mobility scenarios. NSIS allows end hosts to be mobile, it is possible that an NSIS node behind a NAT needs to update its NAT binding in case of address change. Whenever a host behind a NAT initiates a data transfer, it is assigned an external IP and port number. In typical mobility scenarios, the DR might also obtain a new address according to the topology and it should convey its new IP address to the NAT. The NAT is assumed to modify these NAT bindings based on the new IP address conveyed by the endhost. Stiemerling, et al. Expires August 5, 2006 [Page 83] Internet-Draft NAT/FW NSIS NSLP February 2006 Public Private Address Internet space +----------+ +----------+ +----------| NAT |------------------|End host | | | | | +----------+ +----------+ | | +----------+ \--------------------|Malicious | |End host | +----------+ data traffic <======================== Figure 48: Misuse of mobility in NAT binding A NAT binding can be changed with the help of NSIS signaling. When a DR moves to a new location and obtains a new IP address, it sends an NSIS signaling message to modify the NAT binding. It would use the Session-ID and the new flow-id to update the state. The NAT updates the binding and the DR continues to receive the data traffic. Consider the scenario in Figure 48 where an the endhost(DR) and the adversary are behind a NAT. The adversary pretending that it is the end host could generate a spurious signaling message to update the state at the NAT. This could be done for these purposes: Connection hijacking by redirecting packets to the attacker as in Figure 49 Third party flooding by redirecting packets to arbitrary hosts Service disruption by redirecting to non-existing hosts Stiemerling, et al. Expires August 5, 2006 [Page 84] Internet-Draft NAT/FW NSIS NSLP February 2006 +----------+ +----------+ +----------+ | NAT | |End host | |Malicious | | | | | |End host | +----------+ +----------+ +----------+ | | | | Data Traffic | | |--------->----------| | | | Spurious | | | NAT binding update | |---------<----------+--------<------------| | | | | Data Traffic | | |--------->----------+-------->------------| | | | Figure 49: Connection Hijacking SECURITY REQUIREMENT: A NAT/FW signaling message MUST be authenticated, authorized, integrity protected and replay protected between neighboring NAT/FW NSLP nodes. 7.2.7 Misuse of unreleased sessions Assume that DS (N1) initiates NSIS session with DR (N2) through a series of middleboxes as in Figure 50. When the DS is sending data to DR, it might happen that the DR disconnects from the network (crashes or moves out of the network in mobility scenarios). In such cases, it is possible that another node N3 (which recently entered the network protected by the same firewall) is assigned the same IP address that was previously allocated to N2. The DS could take advantage of the firewall policies installed already, if the refresh interval time is very high. The DS can flood the node (N3), which will consume the access network resources of the victim forcing it to pay for unwanted traffic as shown in Figure 51. Note that here we make the assumption that the data receiver has to pay for receiving data packets. Stiemerling, et al. Expires August 5, 2006 [Page 85] Internet-Draft NAT/FW NSIS NSLP February 2006 Public Internet +--------------------------+ | | +-------+ CREATE +---+-----+ +-------+ | | |-------------->------| |---->---| | | | N1 |--------------<------| FW |----<---| N2 | | | | success RESPONSE | | | | | | |==============>======| |====>===| | | +-------+ Data Traffic +---+-----+ +-------+ | | | +--------------------------+ Figure 50: Before mobility Public Internet +--------------------------+ | | +-------+ +---+-----+ +-------+ | | | | | | | | | N1 |==============>======| FW |====>===| N3 | | | | Data Traffic | | | | | +-------+ +---+-----+ +-------+ | | | +--------------------------+ Figure 51: After mobility Also, this threat is valid for the other direction as well. The DS which is communicating with the DR may disconnect from the network and this IP address may be assigned to a new node that had recently entered the network. This new node could pretend to be the DS and send data traffic to the DR in conformance with the firewall policies and cause service disruption. SECURITY REQUIREMENT: Data origin authentication is needed to mitigate this threat. In order to allow firewalls to verify that a legitimate end host transmitted the data traffic data origin authentication is required. This is, however, outside the scope of this document. Hence, there are no security requirements imposed by this section which will be addressed by the NATFW NSLP. 7.2.8 Data Traffic Injection In some environments, such as enterprise networks, it is still common to perform authorization for access to a service based on the source IP address of the service requester. There is no doubt that this by Stiemerling, et al. Expires August 5, 2006 [Page 86] Internet-Draft NAT/FW NSIS NSLP February 2006 itself represents a security weakness. Hence by spoofing a connection, an attacker is able to reach the target machines, using the existing firewall rules. The adversary is able to inject its own data traffic in conformance with the firewall policies simultaneously along with the genuine DS. SECURITY REQUIREMENT: Since IP spoofing is a general limitation of non-cryptographic packet filters no security requirement needs to be created for the NAT/FW NSLP. Techniques such as ingress filtering (described below) and data origin authentication (such as provided with IPsec based VPNs) can help mitigate this threat. This issue is, however, outside the scope of this document. Ingress Filtering: Consider the scenario shown in Figure 52. In this scenario the DS is behind a router (R1) and a malicious node (M) is behind another router (R2). The DS communicates with the DR through a firewall (FW). The DS initiates NSIS signaling and installs firewall policies at FW. But the malicious node is also able to send data traffic using DS's source address. If R2 implements ingress filtering, these spoofed packets will be blocked. But this ingress filtering may not work in all scenarios. If both the DS and the malicious node are behind the same router, then the ingress filter will not be able to detect the spoofed packets as both the DS and the malicious node are in the same address range. Stiemerling, et al. Expires August 5, 2006 [Page 87] Internet-Draft NAT/FW NSIS NSLP February 2006 +-----------------------------------+ | +------------------+ | | | +-------+ +---+---+ | | | | DS +>--+ R1 +->+ | | | | | | | | | | | +-------+ +---+---+ | | | | | | | | +------------------+ | +---+---+ +-------+ | | | | | | | +---+ FW +-->--| DR | | +------------------+ ****| |*****| | | | | * +---+---+ +-------+ | | +-------+ +---+---+ * | | | | M | | R2 | * | | | | |***| |*** | | | +-------+ +---+---+ | | +------------------+ | +-----------------------------------+ ---->---- = genuine data traffic ********* = spoofed data traffic Figure 52: Ingress filtering 7.2.9 Eavesdropping and traffic analysis By collecting NSLP messages, an adversary is able to learn policy rules for packet filters and knows which ports are open. It can use this to inject its own data traffic due to the IP spoofing capability as already mentioned in Section 7.2.8. An adversary could learn authorization tokens included in CREATE messages and use them to launch replay-attacks or to create a session with its own address as source address. (cut-and-paste attack) As shown in Section 4.3 of [25] one possible solution for the session ownership problem is confidentiality protection of signaling messages SECURITY REQUIREMENT: The threat of eavesdropping itself does not mandate the usage of confidentiality protection since an adversary can also eavesdrop on data traffic. In the context of a particular security solutions (e.g., authorization tokens) it might be necessary to offer confidentiality protection. Confidentiality protection also needs to be offered to the refresh period. Stiemerling, et al. Expires August 5, 2006 [Page 88] Internet-Draft NAT/FW NSIS NSLP February 2006 7.3 Security Framework for the NAT/Firewall NSLP Based on the identified threats a list of security requirements has been created. 7.3.1 Security Protection between neighboring NATFW NSLP Nodes Based on the analyzed threats it is necessary to provide, between neighboring NATFW NSLP nodes, the following mechanism: provide o data origin authentication o replay protection o integrity protection and o optionally confidentiality protection To consider the aspect of authentication and key exchange the security mechanisms provided in [1] between neighboring nodes MUST be enabled when sending NATFW signaling messages. The proposed security mechanisms at GIST provide support for authentication and key exchange in addition to denial of service protection. Depending on the chosen protocol, support for flexible authentication protocols could be provided. The mandatory support for security, demands the usage of C-MODE for the delivery of data packets and the usage of D-MODE only to discover the next NATFW NSLP aware node along the path. 7.3.2 Security Protection between non-neighboring NATFW NSLP Nodes Based on the security threats and the listed requirements it was noted that some scenarios also demand authentication and authorization of a NATFW signaling entity (including the initiator) towards a non-neighboring node. This mechanism mainly demands entity authentication. Additionally, security protection of certain payloads MAY be required between non-neighboring signaling entities and the Cryptographic Message Syntax (CMS) [19] SHOULD be used. CMS can be used o This might be, for example, useful to authenticate and authorize a user towards a middlebox and vice versa. o If objects have to be protected between certain non-neighboring NATFW NSLP nodes. Details about the identifiers, replay protection and the usage of a dynamic key management with the help of CMS is for further study. In Stiemerling, et al. Expires August 5, 2006 [Page 89] Internet-Draft NAT/FW NSIS NSLP February 2006 some scenarios it is also required to use authorization token. Their purpose is to associate two different signaling protocols (e.g., SIP and NSIS) and their authorization decision. These tokens are obtained by non-NSIS protocols, such as SIP or as part of network access authentication. When a NAT or firewall along the path receives the token it might be verified locally or passed to the AAA infrastructure. Examples of authorization tokens or assertions can be found in RFC 3520 [31] and RFC 3521 [32]. More recent work on authorization token alike mechanisms is Security Assertion Markup Language (SAML). For details about SAML see [33], [34] and [35]. Figure 53 shows an example of this protocol interaction. An authorization token is provided by the SIP proxy, which acts as the assertion generating entity and gets delivered to the end host with proper authentication and authorization. When the NATFW signaling message is transmitted towards the network, the authorization token is attached to the signaling messages to refer to the previous authorization decision. The assertion verifying entity needs to process the token or it might be necessary to interact with the assertion granting entity using HTTP (or other protocols). As a result of a successful authorization by a NATFW NSLP node, the requested action is executed and later a RESPONSE message is generated. Stiemerling, et al. Expires August 5, 2006 [Page 90] Internet-Draft NAT/FW NSIS NSLP February 2006 +----------------+ Trust Relationship +----------------+ | +------------+ |<.......................>| +------------+ | | | Protocol | | | | Assertion | | | | requesting | | HTTP, SIP Request | | Granting | | | | authz | |------------------------>| | Entity | | | | assertions | |<------------------------| +------------+ | | +------------+ | Artifact/Assertion | Entity Cecil | | ^ | +----------------+ | | | ^ ^| | | | . || HTTP, | | | Trust . || other | API Access | Relationship. || protocols | | | . || | | | . || | | | v |v | v | +----------------+ | +------------+ | | +------------+ | | | Protocol | | NSIS NATFW CREATE + | | Assertion | | | | using authz| | Assertion/Artifact | | Verifying | | | | assertion | | ----------------------- | | Entity | | | +------------+ | | +------------+ | | Entity Alice | <---------------------- | Entity Bob | +----------------+ RESPONSE +----------------+ Figure 53: Authorization Token Usage Threats against the usage of authorization tokens have been mentioned in [8] and also in Section 7.2. Hence, it is required to provide confidentiality protection to avoid allowing an eavesdropper to learn the token and to use it in another session (replay attack). The token itself also needs to be protected against tempering. 7.3.3 End-to-End Security As part of the threat analysis we concluded that end-to-end security is not required and, if used, would be difficult to deploy. Furthermore, it might be difficult to use the suitable identifiers and to establish the necessary infrastructure for this propose. The only reasonable end-to-end security protection needed within NSIS seems to be a binding between an NSIS signaling session and application layer session. This aspect is, however, for further study. In order to solicit feedback from the IETF community on some hard security problems for path-coupled NATFW signaling a more detailed description in [22] is available. Stiemerling, et al. Expires August 5, 2006 [Page 91] Internet-Draft NAT/FW NSIS NSLP February 2006 8. Open Issues The NATFW NSLP has a series of related documents discussing several other aspects of path-coupled NATFW signaling, including security [22], migration (i.e., traversal of NSIS unaware NATs) [15], intra- realm signaling [16], and inter-working with SIP [17]. Summaries of the outcomes from these documents may be added, depending on WG feedback, to a later version of this draft. A more detailed list of open issue can be found at: https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/index It is intended to add an overview figure for all NATFW NSLP building blocks into the next version of this memo. Figure 54 sketches the overview +------------------+ |Security Policies | | Server | +--------^---------+ | +--------------------------------|----------------------+ | +---------+ +-----------V----+ +-------+| | |firewall |<-----> | |<------>| NAT || | |Engine | | Security policy| | Engine|| | +----^----+ | Table/Cache | +-^-----+| | | | ^ | | | | | +---- --------|--+ | | | +--|---------------------------|-------------|--+ | | | V NATFW NSLP V V | | | | | | | +-----------------------------------------------+ | | +--------------------------------------------------+| | | GIST || | | || | +--------------------------------------------------+| | +---------+ +-------+ +------+ +-------+ +------+| | | TCP | | UDP | | DCCP | | SCTP | | ICMP || | +---------+ +-------+ +------+ +-------+ +------+| | +-----------------------------+ +--------------------| | | IPv4 | | IPv6 | | +-----------------------------+ +--------------------| +-------------------------------------------------------+ Figure 54: NATFW NSLP Building Blocks Stiemerling, et al. Expires August 5, 2006 [Page 92] Internet-Draft NAT/FW NSIS NSLP February 2006 9. Contributors We would like to thank the following individuals for their contributions to this document: o Marcus Brunner and Henning Schulzrinne for work on work on IETF drafts which lead us to start with this document, o Miquel Martin for his help on the initial version of this document, o Srinath Thiruvengadam and Ali Fessi work for their work on the NAT/firewall threats draft, o Elywn Davies for his help to make this document more readable, o and the NSIS working group. Stiemerling, et al. Expires August 5, 2006 [Page 93] Internet-Draft NAT/FW NSIS NSLP February 2006 10. References 10.1 Normative References [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", draft-ietf-nsis-ntlp-08 (work in progress), September 2005. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. 10.2 Informative References [4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. [5] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [6] Bosch, S., "NSLP for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp-08 (work in progress), October 2005. [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [8] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", draft-ietf-nsis-threats-06 (work in progress), October 2004. [9] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [10] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [12] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. [13] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Stiemerling, et al. Expires August 5, 2006 [Page 94] Internet-Draft NAT/FW NSIS NSLP February 2006 Specification", RFC 2205, September 1997. [14] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001. [15] Aoun, C., Brunner, M., Stiemerling, M., Martin, M., and H. Tschofenig, "NAT/Firewall NSLP Migration Considerations", draft-aoun-nsis-nslp-natfw-migration-02 (work in progress), July 2004. [16] Aoun, C., "NATFirewall NSLP Intra-realm considerations", draft-aoun-nsis-nslp-natfw-intrarealm-01 (work in progress), July 2004. [17] Martin, M., "SIP NSIS Interactions for NAT/Firewall Traversal", draft-martin-nsis-nslp-natfw-sip-01 (work in progress), July 2004. [18] Tschofenig, H., "Extended QoS Authorization for the QoS NSLP", draft-tschofenig-nsis-qos-ext-authz-00 (work in progress), July 2004. [19] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002. [20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [21] Ohba, Y., "Problem Statement and Usage Scenarios for PANA", draft-ietf-pana-usage-scenarios-06 (work in progress), April 2003. [22] Tschofenig, H., "Path-coupled NAT/firewall Signaling Security Problems", DRAFT draft-tschofenig-nsis-natfw-security-problems-00.txt, July 2004. [23] Tschofenig, H., Buechli, M., Van den Bosch, S., and H. Schulzrinne, "NSIS Authentication, Authorization and Accounting Issues", March 2003. [24] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 Traversal of VPN Gateways", DRAFT draft-ietf-mobileip-vpn-problem-statement-req-02.txt, April 2003. Stiemerling, et al. Expires August 5, 2006 [Page 95] Internet-Draft NAT/FW NSIS NSLP February 2006 [25] Tschofenig, H., "Security Implications of the Session Identifier", draft-tschofenig-nsis-sid-00 (work in progress), June 2003. [26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [27] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [28] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001. [29] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-08 (work in progress), September 2005. [30] Tschofenig, H., "Using SAML for SIP", draft-tschofenig-sip-saml-04 (work in progress), July 2005. [31] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003. [32] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003. [33] Maler, E., Philpott, R., and P. Mishra, "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1", September 2003. [34] Maler, E., Philpott, R., and P. Mishra, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1", September 2003. [35] Maler, E. and J. Hughes, "Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1", March 2004. [36] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as firewall Signalling Protocol", Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001. Stiemerling, et al. Expires August 5, 2006 [Page 96] Internet-Draft NAT/FW NSIS NSLP February 2006 Authors' Addresses Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 13 Email: stiemerling@netlab.nec.de URI: http://www.stiemerling.org Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich 81739 Germany Phone: Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Cedric Aoun Ecole Nationale Superieure des Telecommunications Paris France Email: cedric@caoun.net Stiemerling, et al. Expires August 5, 2006 [Page 97] Internet-Draft NAT/FW NSIS NSLP February 2006 Appendix A. Firewall and NAT Resources 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. For pure firewalls a filter rule must be created and for pure NATs a NAT binding must be created. In mixed firewall and NAT boxes, the policy rule must be mapped in 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 private or public IP addresses. However, the exact mapping depends on the implementation of the firewall or NAT which is different for each vendor. The remainder of this section gives thus only an abstract mapping of NATFW NSLP policy rules to firewall rules and NAT bindings, without going into the specifics on single configuration parameter possibilities. A policy rule consists out of the message routing information (MRI), carried in the NTLP, and information available in the NATFW NSLP. The information of the NSLP is stored in the extend flow information object and the message type, in particular the flow direction. Additional information, such as the external IP address and port number, stored in the NAT or firewall will be used as well. A.1 Wildcarding of Policy Rules The policy rule/MRI to be installed can be wildcarded to some degree. Wildcarding applies to IP address, transport layer port numbers, and the IP payload (or next header in IPv6). Processing of wildcarding splits into the NTLP and the NATFW NSLP layer. The processing at the NTLP layer is independent of the NSLP layer processing and per layer constraints apply. For wildcarding in the NTLP see Section 7.2 of [1]. Wildcarding at the NATFW NSLP level is always a node local policy decision. A signaling message carrying a wildcarded MRI (and thus policy rule) arriving at an NSLP node can be rejected if the local policy does not allow the request. For instance, a MRI with IP addresses set (not wildcarded), transport protocol TCP, and TCP port numbers completely wildcarded. Now the local policy allows only requests for TCP with all ports set and not wildcarded. The request is going to be rejected. Stiemerling, et al. Expires August 5, 2006 [Page 98] Internet-Draft NAT/FW NSIS NSLP February 2006 A.2 Mapping to Firewall Rules EDITOR's NOTE: This section is to be done (CREATE, REA-F). A.3 Mapping to NAT Bindings EDITOR's NOTE: This section is to be done (CREATE, REA). A.4 Mapping for combined NAT and firewall EDITOR's NOTE: This section is to be done. A.5 NSLP Handling of Twice-NAT The dynamic configuration of twice-NATs requires application level support, as stated in Section 2.5. The NATFW NSLP cannot be used for configuring twice-NATs if application level support is needed. Assuming application level support performing the configuration of the twice-NAT and the NATFW NSLP being installed at this devices, the NATFW NSLP must be able to traverse it. The NSLP is probably able to traverse the twice-NAT, as any other data traffic, but the flow information stored in the NTLP's MRI will be invalidated through the translation of source and destination address. The NATFW NSLP implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP signaling messages as any other NATFW NSLP node does. For the given signaling flow, the NATFW NSLP node MUST look up the corresponding IP address translation and modify the NTLP/NSLP signaling accordingly. The modification results in an updated MRI with respect to the source and destination IP addresses. Stiemerling, et al. Expires August 5, 2006 [Page 99] Internet-Draft NAT/FW NSIS NSLP February 2006 Appendix B. Acknowledgments We would like to acknowledge: Vishal Sankhla and Joao Girao for their input to this draft; and Reinaldo Penno for his comments on the initial version of the document. Furthermore, we would like to especially thank Elwyn Davies for his valuable help and input. Stiemerling, et al. Expires August 5, 2006 [Page 100] Internet-Draft NAT/FW NSIS NSLP February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Stiemerling, et al. Expires August 5, 2006 [Page 101]