RFC 5973
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
Pages: 90
Experimental
Experimental
Part 1 of 5 – Pages 1 to 12
Internet Engineering Task Force (IETF) M. Stiemerling Request for Comments: 5973 NEC Category: Experimental H. Tschofenig ISSN: 2070-1721 Nokia Siemens Networks C. Aoun Consultant E. Davies Folly Consulting October 2010 NAT/Firewall NSIS Signaling Layer Protocol (NSLP)Abstract
This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5973.
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 8 1.3. Notes on the Experimental Status . . . . . . . . . . . . . 10 1.4. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 1.5. General Scenario for NATFW Traversal . . . . . . . . . . . 11 2. Network Deployment Scenarios Using the NATFW NSLP . . . . . . 13 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13 2.2. NAT with Two Private Networks . . . . . . . . . . . . . . 14 2.3. NAT with Private Network on Sender Side . . . . . . . . . 15 2.4. NAT with Private Network on Receiver Side Scenario . . . . 15 2.5. Both End Hosts behind Twice-NATs . . . . . . . . . . . . . 16 2.6. Both End Hosts behind Same NAT . . . . . . . . . . . . . . 17 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 18 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 19 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 20 3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 20 3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 22 3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 23 3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 24 3.2.5. State and Error Maintenance . . . . . . . . . . . . . 24 3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 25 3.2.7. Classification of RESPONSE Messages . . . . . . . . . 25 3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26 3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 27 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 31 3.6. Authentication, Authorization, and Policy Decisions . . . 32 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 32 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 32 3.7.2. Reserving External Addresses . . . . . . . . . . . . . 35 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 43 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 45 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 46 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 48 3.8. Demultiplexing at NATs . . . . . . . . . . . . . . . . . . 53 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 54 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 55 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 55 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 56 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 57 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 58 4.2.2. External Address Object . . . . . . . . . . . . . . . 58 4.2.3. External Binding Address Object . . . . . . . . . . . 59
4.2.4. Extended Flow Information Object . . . . . . . . . . . 59
4.2.5. Information Code Object . . . . . . . . . . . . . . . 60
4.2.6. Nonce Object . . . . . . . . . . . . . . . . . . . . . 64
4.2.7. Message Sequence Number Object . . . . . . . . . . . . 64
4.2.8. Data Terminal Information Object . . . . . . . . . . . 64
4.2.9. ICMP Types Object . . . . . . . . . . . . . . . . . . 66
4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 67
4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 69
5. Security Considerations . . . . . . . . . . . . . . . . . . . 69
5.1. Authorization Framework . . . . . . . . . . . . . . . . . 70
5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 70
5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 71
5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 72
5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 73
5.2.1. Security Protection between Neighboring NATFW NSLP
Nodes . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2.2. Security Protection between Non-Neighboring NATFW
NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 74
5.3. Implementation of NATFW NSLP Security . . . . . . . . . . 75
6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 76
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
7.1. NATFW NSLP Message Type Registry . . . . . . . . . . . . . 77
7.2. NATFW NSLP Header Flag Registry . . . . . . . . . . . . . 77
7.3. NSLP Message Object Registry . . . . . . . . . . . . . . . 78
7.4. NSLP Response Code Registry . . . . . . . . . . . . . . . 78
7.5. NSLP IDs and Router Alert Option Values . . . . . . . . . 78
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.1. Normative References . . . . . . . . . . . . . . . . . . . 79
9.2. Informative References . . . . . . . . . . . . . . . . . . 79
Appendix A. Selecting Signaling Destination Addresses for
EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 81
Appendix B. Usage of External Binding Addresses . . . . . . . . . 82
Appendix C. Applicability Statement on Data Receivers behind
Firewalls . . . . . . . . . . . . . . . . . . . . . . 83
Appendix D. Firewall and NAT Resources . . . . . . . . . . . . . 84
D.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 84
D.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 84
D.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 85
D.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 85
Appendix E. Example for Receiver Proxy Case . . . . . . . . . . . 86
1. Introduction
1.1. Scope and Background
Firewalls and Network Address Translators (NATs) have both been used throughout the Internet for many years, and they will remain present for the foreseeable future. Firewalls are used to protect networks against certain types of attacks from internal networks and the Internet, whereas NATs provide a virtual extension of the IP address space. Both types of devices may be obstacles to some applications, since they only allow traffic created by a limited set of applications to traverse them, typically those that use protocols with relatively predetermined and static properties (e.g., most HTTP traffic, and other client/server applications). Other applications, such as IP telephony and most other peer-to-peer applications, which have more dynamic properties, create traffic that is unable to traverse NATs and firewalls without assistance. In practice, the traffic of many applications cannot traverse autonomous firewalls or NATs, even when they have additional functionality that 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 (ALGs) have been integrated with the firewall or NAT to configure the firewall or NAT dynamically. Another approach is middlebox communication (MIDCOM). In this approach, ALGs external to the firewall or NAT configure the corresponding entity via the MIDCOM protocol [RFC3303]. Several other work-around solutions are available, such as Session Traversal Utilities for NAT (STUN) [RFC5389]. However, all of these approaches introduce other problems that are generally hard to solve, such as dependencies on the type of NAT implementation (full-cone, symmetric, etc.), or dependencies on certain network topologies. NAT and firewall (NATFW) signaling shares a property with Quality-of- Service (QoS) signaling -- each must reach any device that is on the data path and is involved in (respectively) NATFW or QoS treatment of data packets. This means that for both NATFW and QoS it is convenient if signaling travels path-coupled, i.e., the signaling messages follow exactly the same path that the data packets take. The Resource Reservation Protocol (RSVP) [RFC2205] is an example of a current QoS signaling protocol that is path-coupled. [rsvp-firewall] proposes the use of RSVP as a 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 [RFC3726] and the general framework of NSIS is outlined in [RFC4080]. It introduces the split between an NSIS transport layer and an NSIS signaling layer. The transport of NSLP messages is handled by an NSIS Network Transport Layer Protocol (NTLP, with General Internet Signaling Transport (GIST) [RFC5971] 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 [RFC5974]. The NATFW NSLP is designed to request the dynamic configuration of NATs and/or firewalls along the data path. Dynamic configuration includes enabling data flows to traverse these devices without being obstructed, as well as blocking of particular data flows at inbound firewalls. Enabling data flows requires the loading of firewall rules with an action that allows the data flow packets to be forwarded and NAT bindings to be created. The blocking of data flows requires the loading of firewall rules with an action that will deny forwarding of the data flow packets. A simplified example for enabling data flows: a source host sends a NATFW NSLP signaling message towards its data destination. This message follows the data path. Every NATFW NSLP-enabled NAT/firewall along the data path intercepts this message, processes it, and configures itself accordingly. Thereafter, the actual data flow can traverse all these configured firewalls/NATs. It is necessary to distinguish between two different basic scenarios when operating the NATFW NSLP, independent of the type of the middleboxes to be configured. 1. Both the data sender and data receiver are NSIS NATFW NSLP aware. This includes the cases in which the data sender is logically decomposed from the initiator of the NSIS signaling (the so- called NSIS initiator) or the data receiver logically decomposed from the receiver of the NSIS signaling (the so-called NSIS receiver), but both sides support NSIS. This scenario assumes deployment of NSIS all over the Internet, or at least at all NATs and firewalls. This scenario is used as a base assumption, if not otherwise noted. 2. Only one end host or region of the network is NSIS NATFW NSLP aware, either the data receiver or data sender. This scenario is referred to as proxy mode. The NATFW NSLP has two basic signaling messages that are sufficient to cope with the various possible scenarios likely to be encountered before and after widespread deployment of NSIS:
CREATE message: Sent by the data sender for configuring a path
outbound from a data sender to a data receiver.
EXTERNAL message: Used by a data receiver to locate inbound NATs/
firewalls and prime them to expect inbound signaling and used at
NATs to pre-allocate a public address. This is used for data
receivers behind these devices to enable their reachability.
CREATE and EXTERNAL messages are sent by the NSIS initiator (NI)
towards the NSIS responder (NR). Both types of message are
acknowledged by a subsequent RESPONSE message. This RESPONSE message
is generated by the NR if the requested configuration can be
established; otherwise, the NR or any of the NSLP forwarders (NFs)
can also generate such a message if an error occurs. NFs and the NR
can also generate asynchronous messages to notify the NI, the so-
called NOTIFY messages.
If the data receiver resides in a private addressing realm or behind
a firewall, and it needs to preconfigure the edge-NAT/edge-firewall
to provide a (publicly) reachable address for use by the data sender,
a combination of EXTERNAL and CREATE messages is used.
During the introduction of NSIS, it is likely that one or the other
of the data sender and receiver will not be NSIS aware. In these
cases, the NATFW NSLP can utilize NSIS-aware middleboxes on the path
between the data sender and data receiver to provide proxy NATFW NSLP
services (i.e., the proxy mode). Typically, these boxes will be at
the boundaries of the realms in which the end hosts are located.
The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in
NSIS entities. NTLP state allows signaling messages to travel in the
forward (outbound) and the reverse (inbound) direction along the path
between a NAT/firewall NSLP sender and a corresponding receiver.
This state is managed using a soft-state mechanism, i.e., it expires
unless it is refreshed from time to time. The NAT bindings and
firewall rules being installed during the state setup are bound to
the particular signaling session. However, the exact local
implementation of the NAT bindings and firewall rules are NAT/
firewall specific and it is out of the scope of this memo.
This memo is structured as follows. Section 2 describes the network
environment for NATFW NSLP signaling. Section 3 defines the NATFW
signaling protocol and Section 4 defines the message components and
the overall messages used in the protocol. The remaining parts of
the main body of the document cover security considerations
Section 5, IAB considerations on UNilateral Self-Address Fixing
(UNSAF) [RFC3424] in Section 6, and IANA considerations in Section 7. Please note that readers familiar with firewalls and NATs and their possible location within networks can safely skip Section 2.1.2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses a number of terms defined in [RFC3726] and [RFC4080]. 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" [RFC3198]. In the context of NSIS NATFW NSLP, the conditions are the specification of a set of packets to which the rule is applied. The set of actions always contains just a single element per rule, and is limited to either action "deny" or action "allow". o Reserved policy rule: A policy rule stored at NATs or firewalls for activation by a later, different signaling exchange. This type of policy rule is kept in the NATFW NSLP and is not loaded into the firewall or NAT engine, i.e., it does not affect the data flow handling. o Installed policy rule: A policy rule in operation at NATs or firewalls. This type of rule is kept in the NATFW NSLP and is loaded into the firewall or NAT engine, i.e., it is affecting the data flow. o Remembered policy rule: A policy rule stored at NATs and firewalls for immediate use, as soon as the signaling exchange is successfully completed. o Firewall: A packet filtering device that matches packets against a set of policy rules and applies the actions. o Network Address Translator: Network Address Translation is a method by which IP addresses are mapped from one IP address realm to another, in an attempt to provide transparent routing between hosts (see [RFC2663]). Network Address Translators are devices that perform this work by modifying packets passing through them. o Data Receiver (DR): The node in the network that is receiving the data packets of a flow.
o Data Sender (DS): The node in the network that is sending the data
packets of a flow.
o NATFW NSLP peer (or simply "peer"): An NSIS NATFW NSLP node with
which an NTLP adjacency has been created as defined in [RFC5971].
o NATFW NSLP signaling session (or simply "signaling session"): A
signaling session defines an association between the NI, NFs, and
the NR related to a data flow. All the NATFW NSLP peers on the
path, including the NI and the NR, use the same identifier to
refer to the state stored for the association. The same NI and NR
may have more than one signaling session active at any time. The
state for the NATFW NSLP consists of NSLP state and associated
policy rules at a middlebox.
o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP
address that is reachable from the public Internet.
o Edge-firewall: An edge-firewall is a firewall device that is
located on the borderline 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" [RFC2663].
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" [RFC2663].
o Public/Global IP address: An IP address located in the public
network according to Section 2.7 of [RFC2663].
o Private/Local IP address: An IP address located in the private
network according to Section 2.8 of [RFC2663].
o Signaling Destination Address (SDA): An IP address generally taken
from the public/global IP address range, although, the SDA may, in
certain circumstances, be part of the private/local IP address
range. This address is used in EXTERNAL signaling message
exchanges, if the data receiver's IP address is unknown.
1.3. Notes on the Experimental Status
The same deployment issues and extensibility considerations described in [RFC5971] and [RFC5978] also apply to this document.1.4. Middleboxes
The term "middlebox" covers a range of devices and is well-defined in [RFC3234]: "A middlebox is defined as any intermediary 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". 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, are out of the scope of this memo. The term "NAT" used in this document is a placeholder for a range of different NAT flavors. We consider the following types of NATs: o Traditional NAT (basic NAT and NAPT) o Bi-directional NAT o Twice-NAT o Multihomed NAT For definitions and a detailed discussion about the characteristics of each NAT type, please see [RFC2663]. 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 that 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 that matches the following fields of a packet to configured values: o Source and destination IP addresses o Transport protocol number o Transport source and destination port numbers
Actions for firewalls are usually one or more of:
o Allow: forward data packet
o Deny: block data packet and discard it
o Other actions such as logging, diverting, duplicating, etc.
Actions for NATs include (amongst many others):
o Change source IP address and transport port number to a globally
routable IP address and associated port number.
o Change destination IP address and transport port number to a
private IP address and associated port number.
It should be noted that a middlebox may contain two logical
representations of the policy rule. The policy rule has a
representation within the NATFW NSLP, comprising the message routing
information (MRI) of the NTLP and NSLP information (such as the rule
action). The other representation is the implementation of the NATFW
NSLP policy rule within the NAT and firewall engine of the particular
device. Refer to Appendix D for further details.
1.5. General Scenario for NATFW Traversal
The purpose of NSIS NATFW signaling is to enable communication
between endpoints across networks, even in the presence of NAT and
firewall middleboxes that have not been specially engineered to
facilitate communication with the application protocols used. This
removes the need to create and maintain application layer gateways
for specific protocols that have been commonly used to provide
transparency in previous generations of NAT and firewall middleboxes.
It is assumed that these middleboxes will be statically configured in
such a way that NSIS NATFW signaling messages themselves are allowed
to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP
signaling is used to dynamically install additional policy rules in
all NATFW middleboxes along the data path that will allow
transmission of the application data flow(s). Firewalls are
configured to forward data packets matching the policy rule provided
by the NSLP signaling. NATs are configured to translate data packets
matching the policy rule provided by the NSLP signaling. An
additional capability, that is an exception to the primary goal of
NSIS NATFW signaling, is that the NATFW nodes can request blocking of
particular data flows instead of enabling these flows at inbound
firewalls.
The basic high-level picture of NSIS usage is that end hosts are located behind middleboxes, meaning that there is at least one middlebox on the data path from the end host in a private network to the external network (NATFW in Figure 1). Applications located at these end hosts try to establish communication with corresponding applications on other such end hosts. This communication establishment may require that the applications contact an application server that serves as a rendezvous point between both parties to exchange their IP address and port(s). The local applications 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 without obstruction. Application Application Server (0, 1, or more) Application +----+ +----+ +----+ | +------------------------+ +------------------------+ | +-+--+ +----+ +-+--+ | | | NSIS Entities NSIS Entities | +-+--+ +----+ +-----+ +-+--+ | +--------+ +----------------------------+ +-----+ | +-+--+ +-+--+ +--+--+ +-+--+ | | ------ | | | | //// \\\\\ | | +-+--+ +-+--+ |/ | +-+--+ +-+--+ | | | | | Internet | | | | | | +--------+ +-----+ +----+ +-----+ | +----+ +----+ |\ | +----+ +----+ \\\\ ///// sender NATFW (1+) ------ NATFW (1+) receiver Note that 1+ refers to one or more NATFW nodes. Figure 1: Generic View of NSIS with NATs and/or Firewalls For end-to-end NATFW signaling, it is necessary that each firewall and each NAT along the path between the data sender and the data receiver implements the NSIS NATFW NSLP. There might be several NATs and FWs in various possible combinations on a path between two hosts. Section 2 presents a number of likely scenarios with different combinations of NATs and firewalls. However, the scenarios given in the following sections are only examples and should not be treated as limiting the scope of the NATFW NSLP.
(next page on part 2)