RFC 5973
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
RFC 5973: NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 🦋
Okay bestie, the paperwork first! 📋✨ This is RFC 5973, which the IETF (Internet Engineering Task Force) published in October 2010. It's titled NAT/Firewall NSIS Signaling Layer Protocol (NSLP) and its ISSN is 2070-1721.
The authors are M. Stiemerling (NEC), H. Tschofenig (Nokia Siemens Networks), C. Aoun (Consultant), and E. Davies (Folly Consulting). 💅
It's Experimental, not a standards-track thing. The title block doesn't list any RFCs that it obsoletes or updates. 🌸
Abstract 📜
So this memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. 🧚 The NSLP lets hosts signal on the data path, so the NATs and firewalls get configured to match what the application data flows actually need. 💖
For example, it lets hosts behind NATs get a publicly reachable address, and it lets hosts behind firewalls receive data traffic. Iconic! 👑 The overall architecture comes from the framework and requirements that the Next Steps in Signaling (NSIS) working group defined. The memo then covers the network scenarios, the protocol itself, and examples for path-coupled signaling. ✨
Status of This Memo 🗒️
This document is not an Internet Standards Track specification. It's out there for examination, experimental implementation, and evaluation. 🔍
It defines an Experimental Protocol for the Internet community, and it's a product of the IETF. It reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). 🫶 Not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details. 📖
Info about the current status of this document, any errata, and how to leave feedback is 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) as in effect on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document. ⚠️
Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 🎀
This document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Unless you get an adequate license from whoever controls the copyright in those 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. The exceptions are formatting it for publication as an RFC or translating 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 . . . . . . . . . . . 861. Introduction ✨
1.1. Scope and Background ✨
okay bestie, firewalls and NATs (Network Address Translators) have been all over the Internet for years 💅, and they're not leaving anytime soon 🙈. Firewalls protect networks from certain attacks coming from internal networks and from the Internet, while NATs give you a virtual extension of the IP address space 🌸. But here's the tea: both can be obstacles for some apps, because they only let through traffic from a limited set of applications, usually the ones using protocols with pretty predetermined, static properties (e.g., most HTTP traffic and other client/server apps) 💀. Other apps, like IP telephony and most peer-to-peer apps with more dynamic properties, make traffic that can't get through NATs and firewalls without help 😭. Honestly, in practice the traffic of lots of apps can't get past autonomous firewalls or NATs, even when those have extra features trying to keep the network transparent 🦋.
Several solutions exist and are in use. Typically, application-level gateways (ALGs) get built into the firewall or NAT so they can configure it dynamically ✨. Another approach is middlebox communication (MIDCOM), where ALGs outside the firewall or NAT configure the matching entity through the MIDCOM protocol [RFC3303]. There are also other work-around solutions, like Session Traversal Utilities for NAT (STUN) [RFC5389]. But ngl, all of these bring their own problems that are hard to solve, like depending on the type of NAT implementation (full-cone, symmetric, etc.) or depending on certain network topologies 💅.
NAT and firewall (NATFW) signaling shares a property with Quality-of-Service (QoS) signaling -- each has to reach any device on the data path that's involved in (respectively) NATFW or QoS treatment of data packets 🎀. So for both, it's convenient if signaling travels path-coupled, meaning the signaling messages follow exactly the same path the data packets take 🧚. The Resource Reservation Protocol (RSVP) [RFC2205] is an example of a current QoS signaling protocol that's path-coupled. [rsvp-firewall] proposes using RSVP as a firewall signaling protocol, but it doesn't include NATs 👑.
This memo defines a path-coupled signaling protocol for NAT and firewall configuration within the NSIS framework, called the NATFW NSIS Signaling Layer Protocol (NSLP) 💖. The general requirements for NSIS are defined in [RFC3726], and the general NSIS framework is outlined in [RFC4080]. It introduces the split between an NSIS transport layer and an NSIS signaling layer. NSLP messages are 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, and the QoS NSLP is defined in [RFC5974] ✨.
The NATFW NSLP is designed to request dynamic configuration of NATs and/or firewalls along the data path. That dynamic configuration includes letting data flows traverse these devices without being obstructed, as well as blocking particular data flows at inbound firewalls 🔥. Enabling data flows means loading firewall rules with an action that allows the flow's packets to be forwarded, and creating NAT bindings. Blocking data flows means loading firewall rules with an action that denies forwarding of the flow's packets 🚫.
Here's a simplified example for enabling data flows 🍓: a source host sends a NATFW NSLP signaling message toward its data destination. That message follows the data path. Every NATFW NSLP-enabled NAT/firewall along the data path intercepts the message, processes it, and configures itself accordingly. After that, the actual data flow can traverse all of those configured firewalls/NATs 🫶.
It's necessary to distinguish between two different basic scenarios when operating the NATFW NSLP, no matter what type of middleboxes are being configured 🧐.
- 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 is 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.
- 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 💜:
CREATEmessage: Sent by the data sender for configuring a path outbound from a data sender to a data receiver.EXTERNALmessage: 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, then a combination of EXTERNAL and CREATE messages is used 🌷.
During the introduction of NSIS, it's likely that one or the other of the data sender and receiver won't be NSIS aware. In these cases, the NATFW NSLP can use 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 sit 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 installed during state setup are bound to the particular signaling session. However, the exact local implementation of the NAT bindings and firewall rules is 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 in 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 ✨
okay so bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way [RFC2119] describes 💅 that's the rulebook for how to hear every one of those words.
This document also uses a bunch of terms from [RFC3726] and [RFC4080] 📚 and then adds a few more of its own, so let's go through them 🫶
- 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 NSIS NATFW NSLP context, the conditions are the specification of a set of packets the rule gets applied to. Each rule always has just a single action, and that action is limited to either "deny" or "allow" 🎀
- Reserved policy rule: a policy rule stored at NATs or firewalls for activation by a later, different signaling exchange 🌸 This kind lives in the NATFW NSLP and does NOT get loaded into the firewall or NAT engine, so it doesn't affect the data flow handling at all 🙈
- Installed policy rule: a policy rule that's in operation at NATs or firewalls 🔥 This kind lives in the NATFW NSLP too, but it IS loaded into the firewall or NAT engine, which means it's actively affecting the data flow 💜
- Remembered policy rule: a policy rule stored at NATs and firewalls for immediate use, as soon as the signaling exchange is successfully completed 🦋
- Firewall: a packet filtering device that matches packets against a set of policy rules and applies the actions 🧱
- Network Address Translator: Network Address Translation is a method where IP addresses get mapped from one IP address realm to another, aiming to give transparent routing between hosts (see [RFC2663]). Network Address Translators are the devices that do this work, by modifying the packets passing through them ✨
- Data Receiver (DR): the node in the network that's receiving the data packets of a flow 🍓
- Data Sender (DS): the node in the network that's sending the data packets of a flow 🚀
- NATFW NSLP peer (or simply "peer"): an NSIS NATFW NSLP node that an NTLP adjacency has been created with, as defined in [RFC5971] 🫂
- 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 that association. The same NI and NR can have more than one signaling session active at any time. The state for the NATFW NSLP is made of NSLP state and the associated policy rules at a middlebox 💖
- Edge-NAT: an edge-NAT is a NAT device with a globally routable IP address that's reachable from the public Internet 🌈
- Edge-firewall: an edge-firewall is a firewall device that sits on the borderline of an administrative domain 🏰
- 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] 🌍
- 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] 🏠
- Public/Global IP address: an IP address located in the public network according to Section 2.7 of [RFC2663] 🌐
- Private/Local IP address: an IP address located in the private network according to Section 2.8 of [RFC2663] 🔒
- 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 gets used in EXTERNAL signaling message exchanges when 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 🫶 so if you already read those, you're basically caught up on this bit.
1.4. Middleboxes 📦
The term "middlebox" covers a whole range of devices and it's 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" 🧐 Middleboxes come in lots of categories with a wide range of functionality, and not all of it is relevant to the NATFW NSLP. The categories in scope for 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 🎯 Other middlebox categories, like QoS traffic shapers, are OUT of scope here 🙅♀️
The term "NAT" used in this document is a placeholder for a range of different NAT flavors 🍭 We consider the following types of NATs:
- Traditional NAT (basic NAT and NAPT)
- Bi-directional NAT
- Twice-NAT
- 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 decide how data packets get treated 🧠 A policy rule is made of a flow identifier that selects the packets the policy applies to, plus an associated action. Data packets that match the flow identifier get 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:
- Source and destination IP addresses
- Transport protocol number
- Transport source and destination port numbers
Actions for firewalls are usually one or more of:
- Allow: forward data packet
- Deny: block data packet and discard it
- Other actions such as logging, diverting, duplicating, etc.
Actions for NATs include (amongst many others):
- Change source IP address and transport port number to a globally routable IP address and associated port number.
- 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 👀 One representation lives within the NATFW NSLP, made of the message routing information (MRI) of the NTLP plus 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 that particular device. Refer to Appendix D for further details 🌟
1.5. General Scenario for NATFW Traversal 🗺️
The whole point of NSIS NATFW signaling is to let endpoints communicate across networks, even when there are NAT and firewall middleboxes in the way that weren't specially engineered to help with the application protocols being used 🥰 That removes the need to create and maintain application layer gateways for specific protocols, which were the go-to way to get transparency in earlier generations of NAT and firewall middleboxes 🙌 It's assumed these middleboxes will be statically configured so that NSIS NATFW signaling messages themselves are allowed to reach the locally installed NATFW NSLP daemon 🔐 Then NSIS NATFW NSLP signaling gets used to dynamically install additional policy rules in all NATFW middleboxes along the data path, so the application data flow(s) can be transmitted 🚀 Firewalls are configured to forward data packets matching the policy rule provided by the NSLP signaling, and NATs are configured to translate data packets matching that same policy rule 💖 There's also an extra capability, which is kind of an exception to the main goal: NATFW nodes can request blocking of particular data flows instead of enabling them at inbound firewalls 🚫
Here's the big picture of NSIS usage. End hosts sit behind middleboxes, which means there's at least one middlebox on the data path from the end host in a private network out to the external network (NATFW in Figure 1) 🏡 Applications on these end hosts try to talk to corresponding applications on other end hosts like them 🤝 Setting that up might mean the applications contact an application server that acts as a rendezvous point, where both parties swap 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 (for example, via an API call) ☎️ The NSIS entity then uses NSIS NATFW NSLP signaling to establish policy rules along the data path, so the data can travel from sender to receiver without obstruction 🎉
Application Application Server (0, 1, or more) Application
+----+ +----+ +----+
| +------------------------+ +------------------------+ |
+-+--+ +----+ +-+--+
| |
| NSIS Entities NSIS Entities |
+-+--+ +----+ +-----+ +-+--+
| +--------+ +----------------------------+ +-----+ |
+-+--+ +-+--+ +--+--+ +-+--+
| | ------ | |
| | //// \\\\\ | |
+-+--+ +-+--+ |/ | +-+--+ +-+--+
| | | | | Internet | | | | |
| +--------+ +-----+ +----+ +-----+ |
+----+ +----+ |\ | +----+ +----+
\\\\ /////
sender NATFW (1+) ------ NATFW (1+) receiverNote 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's 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 🙅♀️ (main character energy tho, it's an example, not the whole story 👑)
2. Network Deployment Scenarios Using the NATFW NSLP ✨
okay so middleboxes are literally everywhere 🌸 they hang out at enterprise network borders, inside enterprise networks, as mobile phone network gateways, etc. 💅 usually they live closer to the edges of a network than in the core. firewalls and NATs show up at these spots either solo or stacked together, and other kinds of middleboxes can chill there too, maybe combined with the NATs and/or firewalls 🦋
NSIS initiators (NI) send NATFW NSLP signaling messages through the regular data path to the NSIS responder (NR) 🧚 along the way, those messages hit different NSIS nodes that implement the NATFW NSLP. each node processes the signaling messages according to Section 3 and, if needed, installs policy rules for the data packets that come later 🎀
each of the sub-sections below is its own scenario, with a different set of middleboxes and a different ordering in the topology. it is assumed that each middlebox implements the NSIS NATFW NSLP signaling protocol 💖
2.1. Firewall Traversal
this one is firewalls only, so NATs are not involved at all 🔥 each end host sits behind a firewall, and the firewalls are connected via the public Internet. Figure 2 shows the topology, and 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 Scenarioevery firewall on the data path must provide traversal service for NATFW NSLP so the NSIS message can reach the other end host 👑 all the firewalls process the NSIS signaling and set up appropriate policy rules, so the required data packet flow can get through them ✨
there are a bunch of very different ways to place firewalls in a topology 🙈 to tell apart the firewalls sitting at network borders (like administrative domains) from the ones located internally, the term edge-firewall is used. a similar split works for NATs, where an edge-NAT plays the equivalent role 💜
2.2. NAT with Two Private Networks
this is the one with NATs at both ends of the network 😭 so both the NSIS initiator and the NSIS responder are behind NATs. the outermost NAT on each side, the edge-NAT (MB2 and MB3), is connected to the public Internet. these NATs get generically labeled as MBX (for middlebox No. X), because those devices definitely implement NAT functionality but can also implement firewall functionality as well 🌈
only two middleboxes (MBs) are shown per side in Figure 3, but in general, any number of MBs on each side must be considered 🍓
+----+ +----+ //----\\ +----+ +----+
NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR
+----+ +----+ \\----// +----+ +----+
private public private
MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder
Figure 3: NAT with two Private Networks Scenariosignaling traffic from the NI to the NR has to traverse all the middleboxes on the path (MB1 to MB4, in this order) 🛣️ and every middlebox must be configured properly so NSIS signaling can get through it. the NATFW signaling has to configure all the middleboxes and take into account any address translation that comes out of that configuration in further signaling ⭐
here's the tricky part 🥺 the sender (NI) has to know the IP address of the receiver (NR) in advance, or it won't be possible to send any NSIS signaling messages toward the responder. and this isn't the responder's private IP address, it's the NAT's public IP address (here, MB3's IP address). a NAT binding (including a public IP address) has to be installed on NAT MB3 beforehand. that binding is what lets packets reaching the NAT get forwarded to the receiver inside the private address realm 💖
the receiver might have a few ways to learn its public IP address and port number (including the NATFW NSLP), and it might need to tell the sender that info using an application-level signaling protocol 🫶
2.3. NAT with Private Network on Sender Side
this scenario is an application instance on the sending node that sits behind one or more NATs (shown as a generic MB, see the discussion in Section 2.2) 🦋 the receiver lives out 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 Sidethe 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, and the middleboxes along the path intercept those signaling messages and configure themselves accordingly 🎀
the data sender doesn't necessarily know whether or not the receiver is behind a NAT 🙈 so it's the receiving side that has to detect whether or not it's behind a NAT. no cap, that's a plot twist 💀
2.4. NAT with Private Network on Receiver Side Scenario
here the application instance that's receiving the data is behind one or more NATs, shown as MB (see the discussion in Section 2.2) 🌸
//----\\ +----+ +----+
NI ---| |---| MB |-----| MB |--- NR
\\----// +----+ +----+
public private
MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder
Figure 5: NAT with Private Network on Receiver Scenariofirst things first, the NSIS responder has to figure out its publicly reachable IP address at the external middlebox and then notify the NSIS initiator about it 🥹 one option is that an application-level protocol is used, meaning the public IP address gets signaled to the NI through that protocol. once that's done, the NI can start its signaling toward the NR, which sets up the path through the middleboxes in the receiver-side private network 💅
this scenario is the use case for the EXTERNAL message of the NATFW NSLP ✨
2.5. Both End Hosts behind Twice-NATs
this is a special case, and the main problem is detecting that both end hosts are logically in the same address space, even though they're in two partitions of the address realm on either side of a twice-NAT (see [RFC2663] for a discussion of twice-NAT functionality) 🌀
the sender and receiver are both inside a single private address realm, but the two partitions could have overlapping IP address ranges 🫠 Figure 6 shows how the NATs are arranged.
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 Scenariothe middleboxes in Figure 6 are twice-NATs, which means they map IP addresses and port numbers on both sides. so the mapping covers source and destination IP addresses at the private and public interfaces 🤯
this scenario needs help from application-level entities, like a DNS server 🧚 those entities have to handle requests based on symbolic names and configure the middleboxes so data packets get forwarded correctly from NI to NR. configuring those middleboxes may require other middlebox communication protocols, such as MIDCOM [RFC3303] 💜 NSIS signaling is not required in the twice-NAT-only case, since middleboxes of the twice-NAT type are normally configured by other means. still, NSIS signaling might be useful when there are also firewalls on the path. in that case, NSIS won't configure any policy rule at the twice-NATs, but it will configure policy rules at the firewalls on the path 🔥
the NSIS signaling protocol must be at least robust enough to survive this scenario 💪 that means twice-NATs must implement the NATFW NSLP too and take part in NATFW signaling sessions. they don't change the configuration of the NAT, though. they just read the address mapping information out of the NAT and translate the Message Routing Information (MRI, [RFC5971]) within the NSLP and NTLP accordingly 🦋 for more info, check out Appendix D.4 📖
2.6. Both End Hosts behind Same NAT
when the NSIS initiator and NSIS responder are behind the same NAT (so they're in the same address realm, see Figure 7), they most likely have no idea that's the case 🙈 just like in Section 2.4, the NSIS responder has to determine its public IP address in advance and transfer it to the NSIS initiator. after that, the NSIS initiator can start sending signaling messages to the responder's public IP address 🌸 during this process, a public IP address gets allocated for the NSIS initiator at the same middlebox as the one for the responder. now the NSIS signaling and the data packets that follow will traverse the NAT twice: once from the initiator to the responder's public IP address, and a second time from the responder's public IP address to the responder itself 🔁
NI public
\ +----+ //----\\
+-| MB |----| |
/ +----+ \\----//
NR
private
MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder
Figure 7: NAT to Public, Both Hosts behind Same NAT2.7. Multihomed Network with NAT
the earlier sub-sections sketched topologies where several NATs and/or firewalls are ordered one after another on the path 🛤️ this one is different: it's a multihomed scenario with two NATs placed on alternative paths to the public network 🌟
+----+ //---\\
| MB |---| |
+----+ \\-+-//
Wait, I need to correct the above and provide the full, exact diagram. Here it is:
NI -------+----+ //---\\
\ | MB |---| |
\ +----+ \\-+-//
\ |
\ +----- NR
\ |
\ +----+ //-+-\\
--| MB |---| |
+----+ \\---//
private public
MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder
Figure 8: Multihomed Network with Two NATsokay that's the real diagram, bestie 🫶 ignore my messed-up one above 😭 depending on the destination, either one or the other middlebox is used for the data flow. which one gets used depends on local policy or routing decisions 🌈 NATFW NSLP must be able to handle this situation properly, and Section 3.7.2 has an extended discussion of this topic with respect to NATs 👑
2.8. Multihomed Network with Firewall 🦋
okay so this one is a multihomed setup with TWO firewalls sitting on alternative paths out to the public network (Figure 9) 🌸 Which firewall your data flow goes through depends on the routing in the private and public networks, and it can even be a different firewall depending on whether the flow is outbound or inbound 😭 That's a real challenge for the EXTERNAL message of the NATFW NSLP, because the NSIS responder is hanging out behind these firewalls in the private network. The EXTERNAL message is what blocks a particular data flow on an inbound firewall, and NSIS has to route the EXTERNAL message inbound from NR to NI, probably without knowing which path the data traffic will take from NI to NR (see also Appendix C) 💅
+----+
NR -------| FW |\
\ +----+ \ //---\\
\ -| |-- NI
\ \\---//
\ +----+ |
--| FW |-------+
+----+
private
private public
FW: Firewall
NI: NSIS Initiator
NR: NSIS ResponderFigure 9: Multihomed Network with Two Firewalls
3. Protocol Description ✨
this section defines the messages, objects, and protocol semantics for the NATFW NSLP 🧚
3.1. Policy Rules 📜
policy rules, bound to a NATFW NSLP signaling session, are the building blocks of the middlebox devices considered in the NATFW NSLP 🎀 For firewalls, the policy rule usually consists of a 5-tuple and an action such as allow or deny. The information in the tuple includes source/destination IP addresses, transport protocol, and source/destination port numbers. For NATs, the policy rule consists of the action translate this address plus further mapping information, which might be, in the simplest case, an internal IP address and an external IP address.
the NATFW NSLP carries, together with the NTLP's Message Routing Information (MRI), the policy rules to be installed at NATFW peers. This policy rule is an abstraction of the real policy rule that gets installed at the respective firewall or NAT. It conveys the initiator's request and must be mapped to the possible configuration on the particular NAT and/or firewall in use. For pure firewalls, one or more filter rules must be created, and for pure NATs, one or more NAT bindings must be created. In mixed firewall and NAT boxes, the policy rule must be mapped to filter rules and bindings while observing the ordering of the firewall and NAT engine. Depending on the ordering, NAT before firewall or vice versa, the firewall rules must carry public or private IP addresses. However, the exact mapping depends on the implementation of the firewall or NAT, which might be different for each implementation 🙈
the policy rule at the NATFW NSLP level comprises the message routing information (MRI) part, carried in the NTLP, and the information available in the NATFW NSLP. The information provided by the NSLP is stored in the 'extend flow information' (NATFW_EFI) and 'data terminal information' (NATFW_DTINFO) objects, plus the message type. Additional information, such as the external IP address and port number stored in the NAT or firewall, will be used as well. The MRI carries the filter part of the NAT/firewall-level policy rule that is to be installed.
the NATFW NSLP specifies two actions for the policy rules: deny and allow. A policy rule with action set to deny will result in all packets matching this rule being dropped. A policy rule with action set to allow will result in all packets matching this rule being forwarded 💖
3.2. Basic Protocol Overview 🌈
the NSIS NATFW NSLP is carried over the General Internet Signaling Transport (GIST, the implementation of the NTLP) defined in [RFC5971]. NATFW NSLP messages are initiated by the NSIS initiator (NI), handled by NSLP forwarders (NFs), and received by the NSIS responder (NR). It is required that at least NI and NR implement this NSLP. Intermediate NFs only implement this NSLP when they provide relevant middlebox functions. NSLP forwarders that do not have any NATFW NSLP functions just forward these packets, since they have no interest in them 🫶
3.2.1. Signaling for Outbound Traffic 🚀
a data sender (DS), intending to send data to a data receiver (DR), has to start NATFW NSLP signaling. This causes the NI associated with the DS to launch NSLP signaling towards the address of the DR (see Figure 10). Although it is expected that the DS and the NATFW NSLP NI will usually reside on the same host, this specification does not rule out scenarios where the DS and NI reside on different hosts, the so-called proxy mode (see Section 3.7.6).
+-------+ +-------+ +-------+ +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR |
| |--->| NF1 |--->| NF2 |--->| |
+-------+ +-------+ +-------+ +-------+
========================================>
Data Traffic Direction (outbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP forwarder 2Figure 10: General NSIS Signaling
the normal sequence of NSLP events goes like this, without detailing the interaction with the NTLP or the interactions on the NTLP level 🧠
- NSIS initiators generate request messages (which are either CREATE or EXTERNAL messages) and send these towards the NSIS responder. This request message is the initial message that creates a new NATFW NSLP signaling session. The NI and the NR will most likely already share an application session before they start the NATFW NSLP signaling session. Note well the difference between both sessions.
- NSLP request messages are processed each time an NF with NATFW NSLP support is traversed. Each NF that intercepts a request message and accepts it for further treatment is joining the particular NATFW NSLP signaling session. These nodes process the message, check local policies for authorization and authentication, possibly create policy rules, and forward the signaling message to the next NSIS node. The request message is forwarded until it reaches the NSIS responder.
- NSIS responders check received messages and process them if applicable. NSIS responders generate RESPONSE messages and send them hop-by-hop back to the NI via the same chain of NFs (traversal of the same NF chain is guaranteed through the established reverse message routing state in the NTLP). The NR also joins the NATFW NSLP signaling session if the request message is accepted.
- The RESPONSE message is processed at each NF that was included in the prior NATFW NSLP signaling session setup.
- If the NI has received a successful RESPONSE message and the signaling NATFW NSLP session started with a CREATE message, the data sender can start sending its data flow to the data receiver. If the NI has received a successful RESPONSE message and the signaling NATFW NSLP session started with an EXTERNAL message, the data receiver is ready to receive further CREATE messages.
Because NATFW NSLP signaling follows the data path from DS to DR, this immediately enables communication between both hosts for scenarios with only firewalls on the data path or NATs on the sender side. For scenarios with NATs on the receiver side, certain problems arise, as described in Section 2.4 😬
3.2.2. Signaling for Inbound Traffic 📥
when the NR and the NI are located in different address realms and the NR is located behind a NAT, the NI cannot signal to the NR address directly. The DR/NR is not reachable from other NIs using the private address of the NR, so NATFW signaling messages cannot be sent to the NR/DR's address. Therefore, the NR must first obtain a NAT binding that provides an address that is reachable for the NI. Once the NR has acquired a public IP address, it forwards this information to the DS via a separate protocol. This application-layer signaling, which is out of the scope of the NATFW NSLP, may involve third parties that assist in exchanging these messages.
the same holds partially true for NRs located behind firewalls that block all traffic by default. In this case, the NR must tell its inbound firewalls about inbound NATFW NSLP signaling and corresponding data traffic. Once the NR has informed the inbound firewalls, it can start its application-level signaling to initiate communication with the NI. This mechanism can be used by machines hosting services behind firewalls as well. In this case, the NR informs the inbound firewalls as described, but does not need to communicate this to the NIs 🔥
NATFW NSLP signaling supports this scenario by using the EXTERNAL message. 🎀
- The DR acquires a public address by signaling on the reverse path (DR towards DS), thus making itself available to other hosts. This process of acquiring public addresses is called reservation. During this process, the DR reserves publicly reachable addresses and ports suitable for further usage in application-level signaling, and the publicly reachable address for further NATFW NSLP signaling. However, the data traffic will not be allowed to use this address/port initially (see next point). In the process of reservation, the DR becomes the NI for the messages necessary to obtain the publicly reachable IP address, i.e., the NI for this specific NATFW NSLP signaling session.
- Now on the side of the DS, the NI creates a new NATFW NSLP signaling session and signals directly to the public IP address of the DR. This public IP address is used as NR's address, as the NI would do if there were no NAT in between, and it creates policy rules at middleboxes. Note that the reservation will only allow forwarding of signaling messages, not data flow packets. Policy rules allowing forwarding of data flow packets set up by the prior EXTERNAL message signaling will be activated when the signaling from NI towards NR is confirmed with a positive RESPONSE message. The EXTERNAL message is described in Section 3.7.2 ✨
3.2.3. Signaling for Proxy Mode ✨
Okay bestie, this one is about what happens when only one end of the call is NSIS-aware 🦋 Figure 11 shows the sending side, and the data flows outbound, left to right 💌
administrative domain
----------------------------------\
|
+-------+ +-------+ +-------+ | +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR |
| |--->| NF1 |--->| NR | | | |
+-------+ +-------+ +-------+ | +-------+
|
----------------------------------/
========================================>
Data Traffic Direction (outbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP responder
Figure 11: Proxy Mode Signaling for Data SenderSo the setup above totally assumes that both ends of the communication support NSIS 🙈 The vibe gets ruined when NSIS is only deployed at one end of the path. In that case, only one side is NSIS aware, either the sending side (see Figure 11) or the receiving side (see Figure 12), and never both at the same time 💀 NATFW NSLP handles both scenarios (aka either the DS or the DR doesn't support NSIS) by using a proxy mode, as described in Section 3.7.6 🫶
administrative domain
/ ----------------------------------
|
+-------+ | +-------+ +-------+ +-------+
| DS | | | MB2/ |~~~>| MB1/ |~~~>| DR |
| | | | NR |<---| NF1 |<---| |
+-------+ | +-------+ +-------+ +-------+
|
\----------------------------------
========================================>
Data Traffic Direction (inbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP responder
Figure 12: Proxy Mode Signaling for Data Receiver3.2.4. Blocking Traffic 🚫
Here's the core deal: NATFW NSLP exists to open firewall pin holes and create NAT bindings, so data flows can actually get through these devices 🌸 Firewalls usually run a "deny-all" policy, which means any traffic that doesn't explicitly match a firewall filter rule gets blocked 🧱 NATs are similar. Their normal behavior is to block all traffic that doesn't match an already configured or installed binding, or a NATFW NSLP session 🔒 But some scenarios need firewalls with an "allow-all" policy instead, where data traffic gets through unless it's explicitly blocked 💖 For those, data receivers can use the NATFW NSLP's EXTERNAL message with the action set to "deny" to install policy rules at inbound firewalls and block the unwanted traffic 🙅♀️
3.2.5. State and Error Maintenance 🧠
The protocol is soft-state, which is giving "everything expires unless you keep it alive" energy ⏳ Whatever state gets installed or reserved on a middlebox will expire after a certain amount of time, and then it's uninstalled or forgotten 👋 To stop state that's still needed for an ongoing conversation from getting removed too early, the NATFW NI involved has to specifically request a NATFW NSLP signaling session extension 🔄 The protocol also gives you an explicit NATFW NSLP state deletion option, so you can clean up on purpose 🧹
If the actions a NATFW NSLP message asks for can't be carried out, the NFs and the NR must return a failure, so the right actions can be taken 🚨 They can do this either during request message handling (synchronously) by sending an error RESPONSE message, or at any time (asynchronously) by sending a NOTIFY notification message 📨
The next sections define the NATFW NSLP message types and formats, protocol operations, and policy rule operations 📚
3.2.6. Message Types 💌
The protocol uses four message types ✨
- CREATE: a request message used for creating, changing, refreshing, and deleting NATFW NSLP signaling sessions, i.e., open the data path from DS to DR. 🛣️
- EXTERNAL: a request message used for reserving, changing, refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions. EXTERNAL messages are forwarded to the edge-NAT or edge-firewall and allow inbound CREATE messages to be forwarded to the NR. Additionally, EXTERNAL messages reserve an external address and, if applicable, port number at an edge-NAT. 🌐
- NOTIFY: an asynchronous message used by NATFW peers to alert other NATFW peers about specific events (especially failures). 🚨
- RESPONSE: used as a response to CREATE and EXTERNAL request messages. 💬
3.2.7. Classification of RESPONSE Messages 🏷️
RESPONSE messages get generated synchronously to CREATE and EXTERNAL messages by NSLP forwarders and responders. They report whether an operation succeeded or failed, or share some info about the NATFW NSLP signaling session or a node 🎀 RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE. Hard rule, no exceptions 🙅♀️
All RESPONSE messages MUST carry a NATFW_INFO object that contains an error class code and a response code (see Section 4.2.5). This section also defines terms for groups of RESPONSE messages, based on the error class 💅
- Successful RESPONSE: Messages carrying NATFW_INFO with error class 'Success' (2). 🥳
- Informational RESPONSE: Messages carrying NATFW_INFO with error class 'Informational' (1) (only used with NOTIFY messages). ℹ️
- Error RESPONSE: Messages carrying NATFW_INFO with error class other than 'Success' or 'Informational'. 😬
3.2.8. NATFW NSLP Signaling Sessions 🦋
A NATFW NSLP signaling session is basically an association between the NI, the NFs, and the NR for a data flow 🤝 That association gets created once the initial CREATE or EXTERNAL message is successfully received at the NFs or the NR. There's signaling session state stored at both the NTLP layer and the NATFW NSLP level. For NATFW NSLP, that state is made of NSLP state plus the associated policy rules at a middlebox 🧩
The session is identified by the session ID (plus other info at the NTLP level) 🪪 The NI generates the session ID before it sends the initial CREATE or EXTERNAL message. The session ID MUST be generated as a cryptographically random number (see [RFC4086]) by the NI, so the output MUST NOT be easily guessable by third parties 🔐 The session ID doesn't get stored in any NATFW NSLP message. It's just passed on to the NTLP 📤
A signaling session has several conceptual states that describe where it is at any given time. A node can see these states for a session 👀
- Pending: The NATFW NSLP signaling session has been created and the node is waiting for a RESPONSE message to the CREATE or EXTERNAL message. A session in state 'Pending' MUST be marked as 'Dead' if no corresponding RESPONSE message has arrived within the locally granted NATFW NSLP signaling session lifetime of the forwarded CREATE or EXTERNAL message (as described in Section 3.4). ⏰
- Established: The NATFW NSLP signaling session is established, i.e., the signaling was successfully performed, and the lifetime of the NATFW NSLP signaling session counts from now on. A session in state 'Established' MUST be marked as 'Dead' if no refresh message has been received within the locally granted NATFW NSLP signaling session lifetime of the RESPONSE message (as described in Section 3.4). 🌟
- Dead: Either the NATFW NSLP signaling session timed out, or the node received an error RESPONSE message for it, and the session can be deleted. 💀
- Transitory: The node has received an asynchronous message, i.e., a NOTIFY, and can delete the session if needed after some time. When a node receives a NOTIFY message, it marks the session as 'Transitory'. This session SHOULD NOT be deleted before a minimum hold time of 30 seconds, i.e., it can be removed after 30 seconds or more. That hold time is there so the existing session can be reused by the NI. For example, the part of a session that the route change didn't affect can be reused once the updating request message arrives 🔁
3.3. Basic Message Processing 🧼
Every NATFW message gets some basic processing when it arrives at a node, no matter the message type 📬 First, the NSLP message syntax gets checked. If a non-recoverable syntax error shows up, a RESPONSE message with an appropriate error of class 'Protocol error' (3) code is generated 🚫 A recoverable error is something like a node getting a message with reserved flags set to anything other than zero. This also covers unknown NSLP objects and how they're handled, according to Section 4.2 🤷♀️ If a message gets delivered to the NATFW NSLP, that means the NTLP layer was able to match it to the session ID (SID) and MRI entries in its database. So there's enough info to identify where the message came from, and enough routing info to send it back to the NI through an established chain of NTLP messaging associations 🗺️ The message isn't forwarded any further if any syntax error is detected. The specific response codes that come from processing objects are described in each object's definition section (see Section 4) 📋 After it passes this check, the NATFW NSLP node runs the authentication and authorization checks described in Section 3.6 🔑 Further processing only happens if those tests pass. Otherwise, processing stops and an error RESPONSE gets returned 🙅♀️
Further message processing stops whenever an error RESPONSE message is generated, and the EXTERNAL or CREATE message gets discarded 🗑️ Plot twist: the whole pipeline is basically a bouncer checking IDs at every door 💅
3.4. Calculation of Signaling Session Lifetime ⏳🎀
okay so NATFW NSLP signaling sessions (and any policy rules that got installed with them) are kept alive with a soft-state mechanism 🫶. every session gets a lifetime, and it stays alive only while that lifetime is still valid. once the lifetime runs out, the sessions and policy rules MUST be removed automatically, and the resources bound to them MUST be freed too 💀. lifetime handling happens at every NATFW NSLP node. the NSLP forwarders and the NSLP responder MUST NOT trigger lifetime extension refresh messages (see Section 3.7.3) 🙅♀️. that job belongs to the NSIS initiator, bestie 💅.
the NSIS initiator MUST choose a NATFW NSLP signaling session lifetime value (in seconds) before it sends any message to the other NSLP nodes, including the very first message that creates the session ✨. it is RECOMMENDED that this lifetime value gets calculated based on:
- the number of lost refresh messages that NFs should be able to cope with 🌸
- the end-to-end delay between the NI and NR 🦋
- network vulnerability to NATFW NSLP signaling session hijacking ([RFC4081]). hijacking gets way easier when the NI doesn't explicitly remove the NATFW NSLP signaling session 😭
- the user application's data exchange duration, in terms of time and networking needs. this duration is modeled as R, where R is the message refresh period (in seconds) 🧚
- the load on the signaling plane. short lifetimes mean more frequent signaling messages, so the plane gets busier 🔥
- the acceptable time for a NATFW NSLP signaling session to stick around after it's no longer actually needed. for example, if keeping the session around costs money and teardown can't be guaranteed, shorter lifetimes are preferable 💜
- the lease time of the NI's IP address. the lease time must be longer than the chosen NATFW NSLP signaling session lifetime, otherwise the IP address can get re-assigned to a different node 👀. that node might get unwanted traffic even though it never asked for a NAT/firewall configuration, which could be a whole issue in environments with mobile hosts 🙈
the RSVP specification [RFC2205] gives an appropriate algorithm for calculating the NATFW NSLP signaling session lifetime, plus a way to stop refresh messages from syncing up across NATFW NSLP signaling sessions 🌈. [RFC2205] recommends:
- the refresh message timer gets randomly set to a value in the range [0.5R, 1.5R] 🎲
- to avoid premature loss of state, lt (where lt is the NATFW NSLP signaling session lifetime) must satisfy
lt >= (K + 0.5)*1.5*R, where K is a small integer. then, in the worst case, K-1 successive messages may be lost without the state being deleted. right now K = 3 is suggested as the default, but a larger K value may be needed for hops with a high loss rate 📡. other algorithms could define the relation between the NATFW NSLP signaling session lifetime and the refresh message period too. the algorithm above is only given as an example, so don't treat it as the only option 🍓
It is RECOMMENDED to use a refresh timer of 300 s (5 minutes), unless the NI or the requesting application at the NI has other requirements (for example, flows that only last a very short time) ⭐.
the requested NATFW NSLP signaling session lifetime value lt gets stored in the NATFW_LT object of the NSLP message 📦.
NSLP forwarders and the NSLP responder can handle the requested lifetime in the following ways 💅:
Requested signaling session lifetime acceptable:
No changes to the NATFW NSLP signaling session lifetime values are needed. the CREATE or EXTERNAL message gets forwarded, if applicable 🫶.
Signaling session lifetime can be lowered:
An NSLP forwarder or the NSLP responder MAY also lower the requested NATFW NSLP signaling session lifetime to an acceptable value (based on its local policies) 📉. if an NF changes the NATFW NSLP signaling session lifetime value, it MUST store the new value in the NATFW_LT object 📝. the CREATE or EXTERNAL message then gets forwarded.
Requested signaling session lifetime is too big:
An NSLP forwarder or the NSLP responder MAY reject the requested NATFW NSLP signaling session lifetime value as being too big, and it MUST generate an error RESPONSE message of class 'Signaling session failure' (7) with response code 'Requested lifetime is too big' (0x02) upon rejection 🙅♀️. lowering the lifetime is preferred over generating an error message, so that's the move 💖.
Requested signaling session lifetime is too small:
An NSLP forwarder or the NSLP responder MAY reject the requested NATFW NSLP signaling session lifetime value as being to small, and it MUST generate an error RESPONSE message of class 'Signaling session failure' (7) with response code 'Requested lifetime is too small' (0x10) upon rejection 🥺.
NFs or the NR MUST NOT increase the NATFW NSLP signaling session lifetime value 🚫. messages can get rejected for having a lifetime that's too long, both when a NATFW NSLP signaling session is first created and also on refreshes 🙈.
the NSLP responder generates a successful RESPONSE for the received CREATE or EXTERNAL message, sets the NATFW NSLP signaling session lifetime value in the NATFW_LT object to the granted lifetime above, and sends the message back towards the NSLP initiator 🏃♀️💨.
each NSLP forwarder processes the RESPONSE message, then reads and stores the granted NATFW NSLP signaling session lifetime value 👀. the forwarders MUST accept the granted NATFW NSLP signaling session lifetime if the value is within the acceptable range. the acceptable value means the value that the NSLP forwarder accepted when it processed the CREATE or EXTERNAL message 🧠. for received values greater than the acceptable value, NSLP forwarders MUST generate a RESPONSE message of class 'Signaling session failure' (7) with response code 'Modified lifetime is too big' (0x11), including a Signaling Session Lifetime object that carries the maximum acceptable signaling session lifetime for this node 📈. for received values lower than the values acceptable by the node's local policy, NSLP forwarders MUST generate a RESPONSE message of class 'Signaling session failure' (7) with response code 'Modified lifetime is too small' (0x12), including a Signaling Session Lifetime object that carries the minimum acceptable signaling session lifetime for this node 📉. in both cases, whether it's 'Modified lifetime is too big' (0x11) or 'Modified lifetime is too small' (0x12), the NF MUST generate a NOTIFY message and send it outbound with the error class set to 'Informational' (1) and the response code set to 'NATFW signaling session terminated' (0x05) 🚨.
Figure 13 shows the procedure with an example 🎀. the initiator requests a 60 second lifetime in the CREATE message, and the forwarder shortens it along the path to 20 seconds, then the responder shortens it to 15 seconds. when the NSLP forwarder receives the RESPONSE message with a NATFW NSLP signaling session lifetime value of 15 seconds, it checks whether that value is lower or equal to the acceptable value 🔍.
+-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+
| |---------------->| NSLP |---------------->| |
| NI | | forwarder | | NR |
| |<----------------| check 15<20 |<----------------| |
+-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+
lt = lifetime
Figure 13: Signaling Session Lifetime Setting Example3.5. Message Sequencing 🔢
NATFW NSLP messages need to carry an identifier so every node along the path can tell apart messages sent at different points in time 🕰️. messages can get lost along the path or duplicated, so all NATFW NSLP nodes should be able to spot messages they've already received (duplicates) or ones that got lost before (loss) 👯. for message replay protection, the nodes need to keep info about messages they've already received, which means every NATFW NSLP message has to carry a message sequence number (MSN). see also Section 4.2.7 🔐.
the MSN MUST be set by the NI and MUST NOT be set or modified by any other node 🙅♀️. the initial value for the MSN MUST be generated randomly and MUST be unique only within the NATFW NSLP signaling session it's used for 🎲. the NI MUST increment the MSN by one for every message it sends ➕. once the MSN hits its maximum value, the next value it takes is zero 🔄. all NATFW NSLP nodes MUST use the algorithm defined in [RFC1982] to detect MSN wrap-arounds 🌀.
NSLP forwarders and the responder store the MSN from the initial CREATE or EXTERNAL packet that creates the NATFW NSLP signaling session, and use it as the start value for that session 🚀. NFs and NRs MUST include the received MSN value in the corresponding RESPONSE message they generate 💌.
when a NATFW NSLP node receives a CREATE or EXTERNAL message, it uses the MSN in the message to figure out whether the state being requested is different from the state already installed 🧐. the message MUST be discarded if the received MSN value is equal to or lower than the stored MSN value 🗑️. a received MSN like that can mean a duplicated and delayed message, or a replayed one 😬. if the received MSN value is greater than the already stored MSN value, the NATFW NSLP MUST update its stored state accordingly (if all the security checks in Section 3.6 permit it) and store the updated MSN value too ✅.
3.6. Authentication, Authorization, and Policy Decisions 🔐👑
NATFW NSLP nodes that receive signaling messages MUST first check whether the message is authenticated and authorized to perform the requested action 🛂. NATFW NSLP nodes that need more info than was provided MUST generate an error RESPONSE of class 'Permanent failure' (0x5) with response code 'Authentication failed' (0x01) or with response code 'Authorization failed' (0x02) 🙋♀️.
the NATFW NSLP is expected to run in all kinds of environments, like IP-based telephone systems, enterprise networks, home networks, and so on 🏠📞. the requirements on authentication and authorization are super different between these use cases 🌈. a home gateway, or an Internet cafe, using NSIS may be perfectly happy with a "NATFW signaling coming from inside the network" policy for authorizing signaling 🧋. enterprise networks, though, are likely to require much more strongly authenticated and authorized signaling 🏢. that enterprise scenario may require an infrastructure and administratively assigned identities to operate the NATFW NSLP 🪪.
once the NI is authenticated and authorized, another step happens 👀. the requested policy rule for the NATFW NSLP signaling session gets checked against a set of policy rules, which means checking whether the requesting NI is allowed to have that policy rule loaded into the device 📋. if this check fails, the NF or NR must send an error RESPONSE of class 'Permanent failure' (5) with response code 'Authorization failed' (0x02) 💀.
3.7. Protocol Operations ✨
okay bestie, this is the section where the NATFW NSLP actually does stuff 💅 It covers how to create NATFW NSLP signaling sessions, maintain them, delete them, and reserve addresses. 🦋
This section needs you to know the NTLP [RFC5971] really well, plus the message routing method and the message routing information (MRI) that comes with it 🧚 The NATFW NSLP reads stuff from the MRI, like the destination and source ports, and uses that plus the NATFW NSLP info to build the policy rules at the NATFW NSLP level. Check out Appendix D for more on this, it's giving deep dive 🌸
3.7.1. Creating Signaling Sessions
okay so the whole point is letting two hosts swap data even when middleboxes are in the way 🫶 In the NATFW NSLP, that's done with the CREATE message. The NI (either the data sender or a proxy) makes a CREATE message like the one in Section 4.3.1 and hands it to the NTLP 💖 The NTLP forwards the whole thing based on the MRI, heading toward the NR. Every NSLP forwarder along the path that runs NATFW NSLP processes the message 👑
Forwarding is hop-by-hop, but it can pass right through NSLP forwarders that don't have NATFW NSLP stuff, and through non-NSIS-aware routers between NSLP hop way points. Not everyone has to be in on it, which is lowkey iconic ✨ When the message reaches the NR, the NR can either accept the request or reject it 🙈 The NR makes a RESPONSE to CREATE, and that response travels hop-by-hop back toward the NI. NATFW NSLP forwarders may reject requests at any time 💀
Figure 14 shows the message flow between the NI (DS in this example), an NF (like a NAT), and an NR (DR in this example) 🍓
NI Private Network NF Public Internet NR
| | |
| CREATE | |
|----------------------------->| |
| | |
| | |
| | CREATE |
| |--------------------------->|
| | |
| | RESPONSE |
| RESPONSE |<---------------------------|
|<-----------------------------| |
| | |
| | |
Figure 14: CREATE Message Flow with Success RESPONSEThere are a bunch of processing rules for NATFW peers when they make and get CREATE messages 🎀 That's because this message type handles creating new NATFW NSLP signaling sessions, updating existing ones, extending the lifetime, and deleting sessions. The last three work the same way for every kind of CREATE message, so they each get their own section:
- Extending the lifetime of NATFW NSLP signaling sessions is described in Section 3.7.3.
- Deleting NATFW NSLP signaling sessions is described in Section 3.7.4.
- Updating policy rules is described in Section 3.10.
For an initial CREATE message that makes a brand new NATFW NSLP signaling session, how it gets processed depends on the NATFW node type 🦋
- NSLP initiator: An NI only makes CREATE messages and hands them over to the NTLP. The NI should never receive CREATE messages and MUST discard them 🙅♀️
- NATFW NSLP forwarder: NFs that can't forward the CREATE message to the next hop MUST generate an error RESPONSE of class 'Permanent failure' (5) with response code 'Did not reach the NR' (0x07) 😭 This can happen if the NTLP layer can't find a NATFW NSLP peer (either another NF or the NR) and returns an error through the GIST API (a timeout error reported by GIST). The NSLP message processing at the NFs depends on the middlebox type:
- NAT: When the initial CREATE message hits the public side of the NAT, it looks for a reservation made in advance, using an EXTERNAL message (see Section 3.7.2). The matching process considers the received MRI info and the stored MRI info, as described in Section 3.8. If no matching reservation can be found, i.e., no reservation has been made in advance, the NSLP MUST return an error RESPONSE of class 'Signaling session failure' (7) with response code 'No reservation found matching the MRI of the CREATE request' (0x03) 💅 If there is a matching reservation, the NSLP stores the data sender's address (and the port number, if applicable) as part of the source IP address of the policy rule ('the remembered policy rule') to be loaded, and forwards the message with the destination IP address set to the internal (private in most cases) address of the NR. When the initial CREATE message is received at the private side, the NAT binding is allocated but not activated (see also Appendix D.3). An error RESPONSE message is generated if the requested policy rule can't be reserved right away, of class 'Signaling session failure' (7) with response code 'Requested policy rule denied due to policy conflict' (0x4). The MRI info gets updated to reflect the address, and the port if applicable, translation. The NSLP message is forwarded toward the NR with the source IP address set to the NAT's external address from the newly remembered binding 🌈
- Firewall: When the initial CREATE message arrives, the NSLP just remembers the requested policy rule but doesn't install any policy rule. After that, the message is forwarded toward the NR. If the requested policy rule can't be reserved right away, an error RESPONSE message is generated, of class 'Signaling session failure' (7) with response code 'Requested policy rule denied due to policy conflict' (0x4) 🔥
- Combined NAT and firewall: Processing at a combined firewall and NAT middlebox is the same as 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 is called "order of functions," and it's generally different depending on whether the packet arrives at the external or internal side of the middlebox 🧠
- NSLP receiver: NRs that get initial CREATE messages MUST reply with a success RESPONSE of class 'Success' (2) with response code set to 'All successfully processed' (0x01) if they accept the CREATE message ✨ Otherwise, they MUST generate a RESPONSE message with a suitable response code. RESPONSE messages go back NSLP hop-by-hop toward the NI, no matter if the response code is success or error 🫶
Remembered policy rules at middleboxes MUST be only installed upon receiving a corresponding successful RESPONSE message with the same SID as the CREATE message that caused them to be remembered. This is a countermeasure to several problems, for example, wasting resources by loading policy rules at intermediate NFs when the CREATE message doesn't reach the final NR for some reason. 🛡️
Processing a RESPONSE message is different for every NSIS node type too 👑
- NSLP initiator: After getting a successful RESPONSE, the data path is set up and the DS can start sending its data to the DR 🎉 After getting 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 🥺
- NSLP forwarder: NFs install the remembered policy rules if a successful RESPONSE message with a matching SID comes in. If an ERROR RESPONSE message with a matching SID comes in, the NATFW NSLP session is marked as 'Dead', no policy rule is installed, and the remembered rule is discarded 💔
- NSIS responder: The NR should never receive RESPONSE messages and MUST silently drop any such messages it gets 🙈
NFs and the NR can also tear down the CREATE session at any time by generating a NOTIFY message with the appropriate response code set 💜
3.7.2. Reserving External Addresses
NSIS signaling is meant to travel end-to-end, even with NATs and firewalls on the path 🦋 That works well when the data sender is behind a NAT or firewall, as described in Section 3.7.1. The problem gets trickier when the data receiver is behind a NAT or firewall and needs to receive data flows from outside its own network (these are usually called inbound flows, see Figure 5) 😬
NSIS signaling, along with the data flows after it, is sent to a specific destination IP address that has to be known in advance and be reachable. Data receivers must tell the local NSIS infrastructure (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP signaling and data flows before they can receive those flows 🌸 It's important to tell apart data receivers behind NATs from ones behind firewalls so you understand the rest of the NATFW procedures. Data receivers that are only behind firewalls already have a public IP address, so they only need to be reachable for NATFW signaling 💖 Unlike those, data receivers behind NATs don't have public IP addresses, so entities outside their addressing realm can't reach them for NATFW signaling 🌈
The discussion above covers a DR that wants to be reachable but can't be, because the NAT doesn't have a suitable rule with the 'allow' action that would forward inbound data. But in some cases, a node sitting behind inbound firewalls that don't block inbound data traffic (firewalls with "default to allow") unless asked might want to stop traffic from certain addresses from reaching it 🙅♀️ In that case, NSIS NATFW signaling can do this by installing a policy rule with its action set to 'deny', using the same mechanisms as for 'allow' rules ✨
The required result is achieved by sending an EXTERNAL message in the inbound direction of the intended data flow 🧚 When using this functionality, the NSIS initiator for the 'Reserve External Address' signaling is usually the node that will become the DR for the eventual data flow. To tell this initiator apart from the usual case where the NI is tied to the DS, the NI is written as NI+ and the NSIS responder is similarly written as NR+ 🎀
Public Internet Private Address Space
Edge NI(DS) NAT/FW NAT NR(DR) NR+ NI+
| | | |
| | | |
| | | |
| | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] |
| |<----------------------|<----------------------|
| | | |
| |RESPONSE[Success/Error]|RESPONSE[Success/Error]|
| |---------------------->|---------------------->|
| | | |
| | | |
============================================================>
Data Traffic DirectionFigure 15: Reservation Message Flow for DR behind NAT or Firewall 🦋
Okay so Figure 15 shows the EXTERNAL message flow for enabling inbound NATFW NSLP signaling messages ✨. The roles of the different NSIS entities here are:
- The data receiver (DR) for the anticipated data traffic is the NSIS initiator (NI+) for the EXTERNAL message, but then becomes the NSIS responder (NR) for following CREATE messages 💖.
- 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+) 🫶.
- It may be necessary to use a signaling destination address (SDA) as the actual target of the EXTERNAL message (NR+) if the DR is located behind a NAT and the address of the DS is unknown 🙈. The SDA is an arbitrary address in the outermost address realm on the other side of the NAT from the DR. Typically, this will be a suitable public IP address when the 'outside' realm is the public Internet. This choice of address causes the EXTERNAL message to be routed through the NATs towards the outermost realm, and would force interception of the message by the outermost NAT in the network at the boundary between the private address and the public address realm (the edge-NAT). It may also be intercepted by other NATs and firewalls on the path to the edge-NAT 🧚.
Basically, there are two different signaling scenarios, and either
- the DR behind the NAT/firewall knows the IP address of the DS in advance, or
- the address of the DS is not known in advance.
Case 1 requires the NATFW NSLP to request the path-coupled message routing method (PC-MRM) from the NTLP 🎀. The EXTERNAL message MUST be sent with PC-MRM (see Section 5.8.1 in [RFC5971]) with the direction set to 'upstream' (inbound).
The handling of case 2 depends on the situation of the DR 👑. If the DR is solely located behind a firewall, the EXTERNAL message MUST be sent with the PC-MRM, direction 'upstream' (inbound), and the data flow source IP address set to 'wildcard'. If the DR is located behind a NAT, the EXTERNAL message MUST be sent with the loose-end message routing method (LE-MRM, see Section 5.8.2 in [RFC5971]), with the destination-address set to the signaling destination IP address (SDA, see also Appendix A). For scenarios with the DR behind a firewall, special conditions apply (see applicability statement in Appendix C).
The data receiver is challenged to determine whether it is solely located behind firewalls or NATs, in order to choose the right message routing method 🌸. This decision can depend on a local configuration parameter, possibly given through DHCP, or it could be discovered through other non-NSLP related testing of the network configuration. The use of the PC-MRM with the known data sender's IP address is RECOMMENDED, because it gives GIST the best possible handle to route the message 'upstream' (outbound) 💅. The use of the LE-MRM, if and only if the data sender's IP address is not known and the data receiver is behind a NAT, is RECOMMENDED too 🌈.
For case 2 with NAT, the NI+ (which could be on the data receiver DR or on any other host within the private network) sends the EXTERNAL message targeted to the signaling destination IP address 🦋. The message routing for the EXTERNAL message is in the reverse direction of the normal message routing used for path-coupled signaling, where the signaling is sent outbound (as opposed to inbound in this case). When establishing NAT bindings (and a NATFW NSLP signaling session), the signaling direction does not matter, since the data path is modified through route pinning due to the external IP address at the NAT. Subsequent NSIS messages (and also data traffic) will travel through the same NAT boxes. However, this is only valid for the NAT boxes, but not for any intermediate firewall 😭. That is the reason for having a separate CREATE message, enabling the reservations made with EXTERNAL at the NATs and either enabling prior reservations or creating new pinholes at the firewalls that are encountered on the outbound path, depending on whether the inbound and outbound routes coincide.
The EXTERNAL signaling message creates an NSIS NATFW signaling session at any intermediate NSIS NATFW peer(s) encountered, independent of the message routing method used. Furthermore, it has to be ensured that the edge-NAT or edge-firewall device is discovered as part of this process. 🔥
The end host cannot be assumed to know this device. Instead, the NAT or firewall box itself is assumed to know that it is located at the outer perimeter of the network 🍓. Forwarding of the EXTERNAL message beyond this entity is not necessary, and MUST be prohibited, as it may provide information on the capabilities of internal hosts 🙈. It should be noted that it is the outermost NAT or firewall that is the edge-device that must be found during this discovery process. For instance, when there are a NAT and (afterwards) a firewall on the outbound path at the network border, the firewall is the edge-firewall. All messages must be forwarded to the topology-wise outermost edge-device, to ensure that this device knows about the NATFW NSLP signaling sessions for incoming CREATE messages. However, the NAT is still the edge-NAT, because it has a public globally routable IP address on its public side. This is not affected by any firewall between the edge-NAT and the public network 💜.
Possible edge arrangements are:
Public Net ----------------- Private net --------------
| Public Net|--|Edge-FW|--|FW|...|FW|--|DR|
| Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR|
| Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR|The edge-NAT or edge-firewall device closest to the public realm responds to the EXTERNAL request message with a successful RESPONSE message ⭐. An edge-NAT includes a NATFW_EXTERNAL_IP object (see Section 4.2.2), carrying the publicly reachable IP address and, if applicable, a port number.
The NI+ can request each intermediate NAT (i.e., a NAT that is not the edge-NAT) to include the external binding address (and, if applicable, port number) in the external binding address object 🧁. The external binding address object stores the external IP address (and port) at the particular NAT. The NI+ has to include the external binding address object (see Section 4.2.3) in the request message, if it wishes to obtain the information 🌷.
There are several processing rules for a NATFW peer when generating and receiving EXTERNAL messages, since this message type is used for creating new (reserve) NATFW NSLP signaling sessions, updating existing ones, extending the lifetime, and deleting NATFW NSLP signaling sessions 🎀. The three latter functions operate in the same way for all kinds of CREATE and EXTERNAL messages, and are therefore described in separate sections:
- Extending the lifetime of NATFW NSLP signaling sessions is described in Section 3.7.3.
- Deleting NATFW NSLP signaling sessions is described in Section 3.7.4.
- Updating policy rules is described in Section 3.10.
The NI+ MUST always include a NATFW_DTINFO object in the EXTERNAL message 🫶. Especially, the LE-MRM does not include enough information for some types of NATs (basically, those NATs that also translate port numbers) to perform the address translation. This information is provided in the NATFW_DTINFO (see Section 4.2.8). This information MUST include at least the 'dst port number' and 'protocol' fields in the NATFW_DTINFO object, as these may be required by NATs that are en route, depending on the type of the NAT. All other fields MAY be set by the NI+ to restrict the set of possible NIs ✨. An edge-NAT will use the information provided in the NATFW_DTINFO object to allow only a NATFW CREATE message with a matching MRI to be forwarded. The MRI of the NATFW CREATE message has to use the parameters set in the NATFW_DTINFO object ('src IPv4/v6 address', 'src port number', 'protocol') as the source IP address/port of the flow from DS to DR 💅.
A NAT requiring information carried in the NATFW_DTINFO can generate a number of error RESPONSE messages of class 'Signaling session failure' (7) 😭:
- 'Requested policy rule denied due to policy conflict' (0x04)
- 'Unknown policy rule action' (0x05)
- 'Requested rule action not applicable' (0x06)
- 'NATFW_DTINFO object is required' (0x07)
- 'Requested value in sub_ports field in NATFW_EFI not permitted' (0x08)
- 'Requested IP protocol not supported' (0x09)
- 'Plain IP policy rules not permitted -- need transport layer information' (0x0A)
- 'Source IP address range is too large' (0x0C)
- 'Destination IP address range is too large' (0x0D)
- 'Source L4-port range is too large' (0x0E)
- 'Destination L4-port range is too large' (0x0F)
Processing of EXTERNAL messages is specific to the NSIS node type 🌈:
- NSLP initiator: NI+ only generate EXTERNAL messages. When the data sender's address information is known in advance, the NI+ can include a
NATFW_DTINFOobject in the EXTERNAL message, if not anyway required to do so (see above). When the data sender's IP address is not known, the NI+ MUST NOT include an IP address in theNATFW_DTINFOobject. The NI should never receive EXTERNAL messages and MUST silently discard it 💀. - NSLP forwarder: The NSLP message processing at NFs depends on the middlebox type:
Alright bestie, the NAT bit is where it gets spicy 🌶️ so let's go 💅
- NAT: NATs check whether the message arrives at the external (public in most cases) address or the internal (private) address 👀. If it comes in on the external address, an NF MUST generate an error RESPONSE of class
'Protocol error'(3) with response code'Received EXTERNAL request message on external side'(0x0B). If it arrives at the internal (private) address and theNATFW_EFIobject contains the action'deny', an error RESPONSE of class'Protocol error'(3) with response code'Requested rule action not applicable'(0x06) MUST be generated. If it arrives at the internal address, an IP address and, if applicable, one or more ports get reserved 🎀. If theNATFW_EXTERNAL_BINDINGobject is in the message, any NAT that is not an edge-NAT MUST include the allocated external IP address, and if applicable one or more ports (the external binding address), in theNATFW_EXTERNAL_BINDINGobject 🦋. If it IS an edge-NAT and there's no edge-firewall beyond it, the NSLP message is not forwarded any further. Instead, a successful RESPONSE message gets generated with aNATFW_EXTERNAL_IPobject holding the translated address and, if applicable, the port info from the binding reserved by the EXTERNAL message ✨. The edge-NAT MUST copy theNATFW_EXTERNAL_BINDINGobject into the response message if it was included in the EXTERNAL message. The RESPONSE then goes back towards the NI+. If it's not an edge-NAT, the NSLP message keeps going, using the translated IP address as the signaling source IP address in the LE-MRM, and the translated port goes into theNATFW_DTINFOobject's field'DR port number'. So theNATFW_DTINFOobject gets updated to reflect the translated port number 🧚. The edge-NAT or any other NAT MUST reject EXTERNAL messages that don't carry aNATFW_DTINFOobject, or whose address info is invalid or not compliant with local policies (for example, the info covers a range of addresses ('wildcarded') but the edge-NAT needs exact info about DS's IP address and port). Those get rejected with the response codes mentioned above 🙅♀️. - Firewall: Non edge-firewalls remember the requested policy rule, keep NATFW NSLP signaling session state, and forward the message 📦. Edge-firewalls stop forwarding the EXTERNAL message 🛑. The policy rule gets loaded immediately if the action in the
NATFW_EFIobject is'deny'and the node is an edge-firewall. The policy rule is remembered but NOT activated if the action in theNATFW_EFIobject is'allow'. In both cases a successful RESPONSE message is generated 💖. If the action is'allow', theNATFW_DTINFOobject is included, and the MRM is set to LE-MRM in the request, then aNATFW_EXTERNAL_IPobject also goes into the RESPONSE message, holding the translated address and, if applicable, port info. That info comes from theNATFW_DTINFOobject's'DR port number'and the source address of the LE-MRM 🌸. The edge-firewall MUST copy theNATFW_EXTERNAL_BINDINGobject into the response message if it was included in the EXTERNAL message. - Combined NAT and firewall: Processing at combined firewall and NAT middleboxes is the same as in the NAT case 🫶.
- NSLP receiver: This type of message should never be received by any NR+, and it MUST generate an error RESPONSE message of class
'Permanent failure'(5) with response code'No edge-device here'(0x06) 💀.
Processing of a RESPONSE message is different for every NSIS node type 🌈:
- NSLP initiator: When a successful RESPONSE message arrives, the NI+ can rely on the requested configuration for future inbound NATFW NSLP signaling sessions 👑. If the response contains a
NATFW_EXTERNAL_IPobject, the NI can use the IP address and port pairs it carries for further application signaling 🦋. After receiving an error RESPONSE message, the NI+ MAY try to generate the EXTERNAL message again, or give up and report the failure to the application. It depends on the error condition 🤷♀️. - NSLP forwarder: NFs simply forward this message as long as they keep state for the requested reservation, IF the RESPONSE message contains a
NATFW_INFOobject with class set to'Success'(2) ✨. If the RESPONSE message contains aNATFW_INFOobject with class set to anything other than'Success'(2), the NATFW NSLP signaling session gets marked as'Dead'☠️. - NSIS responder: This type of message should never be received by any NR+. The NF should never receive response messages and MUST silently discard them 🙈.
NFs and the NR can also tear down the EXTERNAL session at any time by generating a NOTIFY message with the appropriate response code set 🧹.
Reservations with action 'allow' made with EXTERNAL MUST be enabled by a subsequent CREATE message 🔓. A reservation made with EXTERNAL (no matter which action was selected) is kept alive as long as the NI+ refreshes that particular NATFW NSLP signaling session, and it can be reused for multiple, different CREATE messages 🔁. An NI+ may decide to tear down a reservation immediately after receiving a CREATE message. This implies that a new NATFW NSLP signaling session must be created for each new CREATE message. The CREATE message does NOT re-use the NATFW NSLP signaling session created by EXTERNAL. Literally separate sessions, no sharing 🙅♀️.
Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode (see Section 3.7.6), no data traffic gets forwarded to the DR beyond the edge-NAT or edge-firewall 🚧. The only job of EXTERNAL is to make sure that subsequent CREATE messages traveling towards the NR get forwarded across the public-private boundary towards the DR 🌉. How incoming CREATE messages get correlated to EXTERNAL reservation states is described in Section 3.8 🧩.
3.7.3. NATFW NSLP Signaling Session Refresh 🔄✨
NATFW NSLP signaling sessions are maintained on a soft-state basis 🧁. After a specified timeout, sessions and their corresponding policy rules are removed automatically by the middlebox, if they are not refreshed 🗑️. Soft-state gets created by CREATE and EXTERNAL, and the maintenance of that state has to be done by those same messages. State created by CREATE must be maintained by CREATE, and state created by EXTERNAL must be maintained by EXTERNAL 🤝. Refresh messages are messages carrying the same session ID as the initial message and a NATFW_LT lifetime object with a lifetime greater than zero 💜. Messages with the same SID but a different MRI are treated as updates of the policy rules and get processed as defined in Section 3.10 🔧. Every refresh CREATE or EXTERNAL message MUST be acknowledged by an appropriate response message generated by the NR 📬. When each NSLP forwarder receives it, the state for the given session ID is extended by the NATFW NSLP signaling session refresh period, which is calculated based on a proposed refresh message period ⏰. The new (extended) lifetime of a NATFW NSLP signaling session is calculated as current local time plus the proposed lifetime value (the NATFW NSLP signaling session refresh period). Section 3.4 defines the process of calculating lifetimes in detail 🧮.
NI Public Internet NAT Private address NR
| | space |
| CREATE[lifetime > 0] | |
|----------------------------->| |
| | |
| | |
| | CREATE[lifetime > 0] |
| |--------------------------->|
| | |
| | RESPONSE[Success/Error] |
| RESPONSE[Success/Error] |<---------------------------|
|<-----------------------------| |
| | |
| | |
Figure 16: Successful Refresh Message Flow, CREATE as ExampleProcessing of NATFW NSLP signaling session refresh CREATE and EXTERNAL messages is different for every NSIS node type 🎀:
- NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling session refresh CREATE/EXTERNAL messages before the NATFW NSLP signaling session times out ⏳. How often the refresh CREATE/EXTERNAL messages get sent, and how that relates to the NATFW NSLP signaling session state lifetime, is discussed further in Section 3.4 📖.
- NSLP forwarder: Processing of this message is independent of the middlebox type and is as described in Section 3.4 🫧.
- NSLP responder: NRs that accept a NATFW NSLP signaling session refresh CREATE/EXTERNAL message generate a successful RESPONSE message, including the granted lifetime value from Section 3.4 in a
NATFW_LTobject 🎉.
3.7.4. Deleting Signaling Sessions ✨
okay so NATFW NSLP signaling sessions can be deleted at any time 🗑️ no cap. NSLP initiators can kick off the deletion by sending a CREATE or EXTERNAL message with a lifetime value set to 0, like in Figure 17 💅. Which one you send depends on how the session was created in the first place (iykyk 🙈).
NI Public Internet NAT Private address NR
| | space |
| CREATE[lifetime=0] | |
|----------------------------->| |
| | |
| | CREATE[lifetime=0] |
| |--------------------------->|
| | |
Figure 17: Delete message flow, CREATE as ExampleNSLP nodes that get this message delete the NATFW NSLP signaling session immediately 💀. The policy rules tied to that specific session MUST also be deleted immediately 🔥. The message keeps getting forwarded until it reaches the final NR 🦋. The CREATE/EXTERNAL message with a lifetime value of 0 doesn't generate any response, positive or negative, because there's no NSIS state left at the nodes along the path. so quiet and so iconic 🤫✨
NSIS initiators can also be aggregated bestie 🧚 A single CREATE or EXTERNAL message with lifetime set to zero can terminate multiple NATFW NSLP signaling sessions at once. NIs can follow this procedure if they like to aggregate deletion requests. The NI uses the CREATE or EXTERNAL message with the session ID set to zero and the MRI's source-address set to its used IP address. All the other fields of the NATFW NSLP signaling sessions being terminated get set as well, otherwise those fields are completely wildcarded. The NSLP message gets transferred to the NTLP requesting 'explicit routing' as described in Sections 5.2.1 and 7.1.4. in [RFC5971].
Now the outbound NF receiving one of these aggregated CREATE or EXTERNAL messages MUST reject it with an error RESPONSE of class 'Permanent failure' (5) and response code 'Authentication failed' (0x01) if the authentication fails 🙅♀️. If the authorization fails instead, it sends an error RESPONSE of class 'Permanent failure' (5) with response code 'Authorization failed' (0x02). Proof of ownership of NATFW NSLP signaling sessions, as defined in this memo (see Section 5.2.1), is not possible when you're aggregating for multiple session termination 😭. BUT the outbound NF can still use the relationship between the info in the received CREATE or EXTERNAL message and the GIST messaging association where the request came in ✨. The outbound NF MUST only accept this aggregated CREATE or EXTERNAL message through already established GIST messaging associations with the NI. The outbound NF MUST NOT propagate this aggregated CREATE or EXTERNAL message, but it MAY generate and forward per NATFW NSLP signaling session CREATE or EXTERNAL messages 🎀.
3.7.5. Reporting Asynchronous Events 🌸
NATFW NSLP forwarders and NATFW NSLP responders must have the ability to report asynchronous events to other NATFW NSLP nodes, especially so they can report back to the NATFW NSLP initiator 📣. These events may be a premature NATFW NSLP signaling session termination, changes in local policies, a route change, or any other reason that shows the NATFW NSLP signaling session state has changed 🦋.
NFs and NRs may generate NOTIFY messages upon asynchronous events, with a NATFW_INFO object that explains the reason for the event 💜. These reasons can be carried in the NATFW_INFO object (class MUST be set to 'Informational' (1)) within the NOTIFY message 💅. Here's the list of response codes and what NFs and the NI should do about each one:
- 'Route change: Possible route change on the outbound path' (0x01): Follow the instructions in Section 3.9. This MUST be sent inbound and outbound, if the signaling session is in any state except 'Transitory'. The NOTIFY message for signaling sessions in state Transitory MUST be discarded, since the signaling session is Transitory anyway 🙈. The outbound NOTIFY message MUST be sent with explicit routing by providing the SII-Handle to the NTLP.
- 'Re-authentication required' (0x02): The NI should re-send the authentication. This MUST be sent inbound 🔁.
- 'NATFW node is going down soon' (0x03): The NI and other NFs should be prepared for a service interruption at any time 🌧️. This message MAY be sent inbound and outbound.
- 'NATFW signaling session lifetime expired' (0x04): The NATFW signaling session has expired and the signaling session is invalid now 💀. NFs MUST mark the signaling session as 'Dead'. This message MAY be sent inbound and outbound.
- 'NATFW signaling session terminated' (0x05): The NATFW signaling session has been terminated for some reason and the signaling session is invalid now 🪦. NFs MUST mark the signaling session as 'Dead'. This message MAY be sent inbound and outbound.
NOTIFY messages are always sent hop-by-hop inbound towards the NI until they reach the NI, or outbound towards the NR as indicated in the list above 🧭.
The initial processing when a NOTIFY message comes in is the same for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages through already established NTLP messaging associations 🔐. The rest of the processing is different for each NATFW NSLP node type and depends on which event got notified:
- NSLP initiator: NIs analyze the notified event and behave appropriately based on the event type. NIs MUST NOT generate NOTIFY messages 🙅♀️.
- NSLP forwarder: NFs analyze the notified event and behave based on the description above for each response code. NFs SHOULD generate NOTIFY messages upon asynchronous events and forward them inbound towards the NI or outbound towards the NR, depending on the direction they were received in. In other words, inbound messages MUST be forwarded further inbound and outbound messages MUST be forwarded further outbound 🔄. NFs MUST silently discard NOTIFY messages that were received outbound but are only allowed to be sent inbound, e.g., 'Re-authentication required' (0x02) 🤫.
- NSLP responder: NRs SHOULD generate NOTIFY messages upon asynchronous events, including a response code based on the reported event 📬. The NR MUST silently discard NOTIFY messages that were received outbound but are only allowed to be sent inbound, e.g., 'Re-authentication required' (0x02) 🌷.
Now the NOTIFY storm situation 🌪️ NATFW NSLP forwarders keeping multiple NATFW NSLP signaling sessions at the same time can have real problems when they shut down service suddenly. This can happen because of a local node failure, like a hardware failure 🔧. The NF then generates a NOTIFY message for each NATFW NSLP signaling session and tries to send them all inbound. Because there are so many NOTIFY messages to send, the node's shutdown may get unnecessarily prolonged, since not every message can go out at the same time 😩. When a whole pile of NATFW NSLP signaling sessions is involved, that's called a NOTIFY storm.
To avoid generating per-session NOTIFY messages in that scenario (or similar cases), NFs SHOULD follow this procedure ✨: the NF uses a NOTIFY message with the session ID in the NTLP set to zero, with the MRI completely wildcarded, and uses 'explicit routing' as described in Sections 5.2.1 and 7.1.4 of [RFC5971]. The inbound NF that receives this type of NOTIFY immediately regards all NATFW NSLP signaling sessions from that peer that match the MRI as void 🫥. This usually leads to multiple NOTIFY messages at the inbound NF, since the NF can generate a NOTIFY message per terminated NATFW NSLP signaling session. However, an NF MAY also aggregate the NOTIFY messages as described here 💖.
3.7.6. Proxy Mode of Operation 🧚♀️
Some migration scenarios need specialized support, for cases where NSIS is only deployed in some areas of the Internet 🗺️. End-to-end signaling is going to fail without NSIS support at or near both the data sender and the data receiver terminals 😭. That's why a proxy mode of operation is needed. This proxy mode of operation must terminate the NATFW NSLP signaling topologically as close as possible to the terminal it's proxying for, and it must proxy all messages 🫶. The NATFW NSLP node doing the proxying becomes either the NI or the NR for that particular NATFW NSLP signaling session, depending on whether it's the DS or the DR that doesn't support NSIS 🎀. Typically, the edge-NAT or the edge-firewall would be used to proxy NATFW NSLP messages 🏰.
This proxy mode operation doesn't require any new CREATE or EXTERNAL message type. Instead, it relies on extended CREATE and EXTERNAL message types, called CREATE-PROXY and EXTERNAL-PROXY 🪄. They're distinguished by setting the P flag in the NSLP header to P=1. That flag tells the edge-NATs and edge-firewalls that receive them to operate in proxy mode for the NATFW NSLP signaling session in question 🌈. The semantics of the CREATE and EXTERNAL message types don't change, and the behavior of the various node types stays as defined in Sections 3.7.1 and 3.7.2, except for the proxying node 👑. The following paragraphs describe the proxy mode operation for data receivers behind middleboxes and data senders behind middleboxes 🦋.
3.7.6.1. Proxying for a Data Sender
okay bestie, this is the moment the NR gets to install state on the inbound path toward the data sender for outbound data packets, even when only the receiving side is running NSIS 💅✨ (see Figure 18). The whole goal is to trigger the edge-NAT/edge-firewall into generating a CREATE message on behalf of the data receiver 🦋. So the NR signals toward the network border the same way as the standard EXTERNAL message handling in Section 3.7.2. The message keeps getting forwarded until it reaches the edge-NAT/edge-firewall, and a public IP address and port number get reserved there 🌸. The difference from the standard EXTERNAL case is that the edge-NAT/edge-firewall is triggered to send a CREATE message on a new reverse path that traverses several firewalls or NATs. That new reverse path for CREATE is needed to handle routing asymmetries between the edge-NAT/edge-firewall and the DR 🧚. And I need you to really hear this part: the semantics of the CREATE and EXTERNAL messages do NOT change. Each one is still processed the way we already covered it 💖
DS Public Internet NAT/FW Private address DR
No NI NF space NR
NR+ NI+
| | EXTERNAL-PROXY[(DTInfo)] |
| |<------------------------- |
| | RESPONSE[Error/Success] |
| | ---------------------- > |
| | CREATE |
| | ------------------------> |
| | RESPONSE[Error/Success] |
| | <---------------------- |
| | |Figure 18: EXTERNAL Triggering Sending of CREATE Message
okay so a NATFW_NONCE object rides along in both the EXTERNAL and CREATE messages, and it's what links the CREATEs that show up at the message initiator back to their EXTERNAL-PROXY 🔗✨ An NI+ uses the presence of the NATFW_NONCE object to correlate the CREATE with the right EXTERNAL-PROXY. No NONCE object means the CREATE was started by the DS, not by the edge-NAT 🙈
Now the two signaling sessions (the one for EXTERNAL-PROXY and the one for CREATE) are NOT independent, they're totally codependent 💀 The EXTERNAL-PROXY session is the primary one, and the CREATE session is secondary to it. The CREATE session is valid only as long as the EXTERNAL-PROXY session is in the signaling state 'Established' or 'Transitory'. In any other EXTERNAL-PROXY signaling state, meaning 'Pending' or 'Dead', there is no CREATE session at all. That's the fate-sharing, and it's giving ride-or-die 👑
These processing rules get added on top of the regular EXTERNAL processing:
- NSLP initiator (NI+): The NI+ MUST take the session ID (SID) value of the EXTERNAL-PROXY session as the nonce value of the NATFW_NONCE object.
- NSLP forwarder being either edge-NAT or edge-firewall: When the NF accepts an EXTERNAL-PROXY message, it generates a successful RESPONSE message as if it were the NR, and it generates a CREATE message as defined in Section 3.7.1 and includes a NATFW_NONCE object having the same value as of the received NATFW_NONCE object. The NF MUST NOT generate a CREATE-PROXY message. The NF MUST refresh the CREATE message signaling session only if an EXTERNAL-PROXY refresh message has been received first. This also includes tearing down signaling sessions, i.e., the NF must tear down the CREATE signaling session only if an EXTERNAL-PROXY message with lifetime set to 0 has been received first. 🫶
This scenario is a real challenge for the data receiver, because it has to correctly guess whether the data sender can use NSIS NATFW NSLP signaling 😭 It can guess wrong in two different ways:
- a) the DS is NSIS unaware but the DR assumes the DS to be NSIS aware, and
- b) the DS is NSIS aware but the DR assumes the DS to be NSIS unaware.
Case a) is the bad one, because middleboxes end up blocking the data traffic. The DS will never send the expected CREATE message, so nothing opens up 💀 Case b) actually works out, since the DR successfully requests proxy mode support from the edge-NAT or edge-firewall. Then both the edge-NAT/edge-firewall and the DS send CREATE messages. Both CREATE messages get handled as separate NATFW NSLP signaling sessions, so the common rules per NATFW NSLP signaling session apply. The NATFW_NONCE object is what tells apart CREATE messages generated by the edge-NAT/edge-firewall from the NI-initiated CREATE messages 🧠 If the data sender's side is NSIS aware but the DR wrongly assumed it wasn't, it's the NR's call whether to tear down the EXTERNAL-PROXY signaling sessions.
It is RECOMMENDED that a DR behind NATs use the proxy mode of operation by default, unless the DR knows that the DS is NSIS aware. The DR MAY cache information about data senders that it has found to be NSIS aware in past NATFW NSLP signaling sessions 🍓
one more thing, there's a possible race condition 🏃♀️ The CREATE message generated by the edge-NAT can arrive earlier than the RESPONSE message to the EXTERNAL-PROXY. So an NI+ MUST accept CREATE messages generated by the edge-NAT even if the RESPONSE message to the EXTERNAL-PROXY was not received yet ✨
3.7.6.2. Proxying for a Data Receiver
same energy as data receivers behind middleboxes: data senders behind middleboxes can ALSO need proxy mode support 🙌 The catch is that there's no NSIS support on the data receiver's side, so by default, nothing responds to CREATE messages 😬 That means the last NSIS NATFW NSLP-aware node has to terminate the forwarding and proxy the response to the CREATE message, so this node is the one generating RESPONSE messages. That last node could be an edge-NAT/edge-firewall or any other NATFW NSLP peer that notices there's no NR available. It's probably because GIST timeouts happened, but there could be other triggers too 🔍
DS Private Address NAT/FW Public Internet NR
NI Space NF no NR
| | |
| CREATE-PROXY | |
|------------------------------>| |
| | |
| RESPONSE[SUCCESS/ERROR] | |
|<------------------------------| |
| | |Figure 19: Proxy Mode CREATE Message Flow
the processing of CREATE-PROXY and RESPONSE messages is basically the same as Section 3.7.1, except forwarding stops at the edge-NAT/edge-firewall 🎀 That device responds back to NI based on the situation (error or success), and it becomes the NR for any future NATFW NSLP communication.
The NI can pick proxy mode even when the DR is NSIS aware 🤷♀️ The CREATE-PROXY mode won't configure all the NATs and firewalls along the data path, since it gets terminated at the edge-device. Any device past that point will never receive any NATFW NSLP signaling for this flow 💅
3.7.6.3. Incremental Deployment Using the Proxy Mode
so far we've talked about proxy mode for when NATFW NSLP is only deployed at the network edges. But real life is messier 🙃 NATFW NSLP might roll out first at some network edges and only later in other parts of the network. If you only use proxy mode, the NI can't tell whether the other parts of the network have been upgraded to NATFW NSLP too 😭 One way to check whether the path from the NI to the NR is NATFW-NSLP-capable is to use the regular CREATE message and wait for a successful response or an error response. The downside is extra messages, since a CREATE message gets sent from the NI on top of the CREATE-PROXY message (which is required anyhow) 📬
The NATFW NSLP allows using proxy mode AND a further probing of the path by the edge-NAT or edge-firewall, and that's the iconic combo 🧚✨ The NI can request proxy-mode handling as described, and it can set the E flag (see Figure 20) to ask the edge-NAT or edge-firewall to probe the further path for NATFW NSLP enabled NFs or an NR.
The edge-NAT or edge-firewall MUST continue to send the CREATE-PROXY or EXTERNAL-proxy towards the NR if the received proxy-mode message has the E flag set, in addition to the regular proxy mode handling 🌈 The edge-NAT or edge-firewall relies on NTLP measures to determine whether or not there is another NATFW NSLP reachable toward the NR. A failed attempt to forward the request message to the NR gets silently discarded. A successful forward gets acknowledged by the NR with a successful response message, which follows the regular behavior described in the proxy-mode sections 💖
3.7.6.4. Deployment Considerations for Edge-Devices
the proxy mode assumes the edge-NAT or edge-firewall are properly configured by the network operator, meaning the edge-device really IS the final NAT or firewall of that network 🏡 Right now there's no known way for NATFW NSLP to automatically detect which NATs or firewalls are the actual edge of a network 😬 So it's super important that the network operator configures the edge-NAT or edge-firewall, and also reconfigures these devices if they stop being at the edge. For example, say an edge-NAT sits inside an ISP and the ISP decides to put another NAT in front of it. Then the ISP needs to reconfigure the old edge-NAT to be a regular NATFW NLSP NAT, and configure the newly installed NAT as the edge-NAT 🛠️✨
3.8. Demultiplexing at NATs 🎀
Okay bestie, so Section 3.7.2 explains how NSIS nodes stuck behind NATs can snag a publicly reachable IP address and port number at a NAT 💅 and how the resulting mapping rule gets switched on using CREATE messages (see Section 3.7.1). ✨ The info about that public IP address and port number can get passed along through an application-level signaling protocol and/or a third party to the communication partner who wants to send data to the host behind the NAT. 🦋 But here's the tea: NSIS signaling flows are sent towards the address of the NAT where that IP address and port number is allocated, and not directly to the allocated IP address and port number. 🙈 So the NATFW NSLP forwarder at this NAT needs to know how the incoming NSLP CREATE messages connect to reserved addresses, which means how to demultiplex incoming NSIS CREATE messages. Main character problem, but solvable! 💖
The demultiplexing method uses info stored at the local NATFW NSLP node and in the policy rule. 🧚 The policy rule uses the LE-MRM MRI source-address (see [RFC5971]) as the flow destination IP address and the network-layer-version (IP-ver) as the IP version. The external IP address at the NAT gets stored as the external flow destination IP address. All other parameters of the policy rule, other than the flow destination IP address, are wildcarded if no NATFW_DTINFO object is included in the EXTERNAL message. The LE-MRM MRI destination-address MUST NOT be used in the policy rule, since it is solely a signaling destination address. 🚫
If the NATFW_DTINFO object is included in the EXTERNAL message, the policy rule gets filled with extra info. 🌸 The 'dst port number' field of the NATFW_DTINFO gets stored as the flow destination port number. The 'protocol' field gets stored as the flow protocol. The 'src port number' field gets stored as the flow source port number. The 'data sender's IPv4 address' gets stored as the flow source IP address. Just a heads up that some of these fields can contain wildcards. 👀
When a CREATE message shows up at the NATFW NSLP, the NATFW NSLP uses the flow info stored in the MRI to do the matching. 💅 This table shows which parameters get compared against each other. Not all parameters need to be present in an MRI at the same time, so don't panic if some are missing. 🫶
+-------------------------------+--------------------------------+
| Flow parameter (Policy Rule) | MRI parameter (CREATE message) |
+-------------------------------+--------------------------------+
| IP version | network-layer-version |
| Protocol | IP-protocol |
| source IP address (w) | source-address (w) |
| external IP address | destination-address |
| destination IP address (n/u) | N/A |
| source port number (w) | L4-source-port (w) |
| external port number (w) | L4-destination-port (w) |
| destination port number (n/u) | N/A |
| IPsec-SPI | ipsec-SPI |
+-------------------------------+--------------------------------+
Table entries marked with (w) can be wildcarded and
entries marked with (n/u) are not used for the matching.
Table 1It's worth noting that the Protocol/IP-protocol entries in Table 1 refer to the 'Protocol' field in the IPv4 header or the 'next header' entry in the IPv6 header. 🌈
3.9. Reacting to Route Changes 🦋
The NATFW NSLP needs to react when routes change in the data path. 🛣️ This assumes it can detect route changes, configure NAT and firewall on the new path, and possibly tear down NATFW NSLP signaling session state on the old path. Route change detection is described in Section 7 of [RFC5971], and the NATFW NSLP relies on notifications about route changes from the NTLP. ✨ That notification gets conveyed through the API between NTLP and NSLP, which is out of the scope of this memo, so that's a whole other story! 📖
A NATFW NSLP node other than the NI or NI+ that detects a route change, by means described in the NTLP specification or others, generates a NOTIFY message indicating this change and sends it inbound towards the NI and outbound towards the NR (see also Section 3.7.5). 💌 Intermediate NFs on the way to the NI can use this info to decide later whether their NATFW NSLP signaling session can be deleted locally, in case they don't receive an update within a certain time period, as described in Section 3.2.8. 🕰️ It's important to consider the transport limitations of NOTIFY messages as mandated in Section 3.7.5. 🙏
The NI that receives this NOTIFY message MAY generate a new CREATE or EXTERNAL message and send it towards the NATFW NSLP signaling session's NI, just like for the initial message, using the same session ID. 🔁
All the remaining processing and message forwarding, like NSLP next-hop discovery, is subject to regular NSLP processing as described in the particular sections. 🧭 Normal routing will guide the new CREATE or EXTERNAL message to the correct NFs along the changed route. NFs that were on the original path and receive these new CREATE or EXTERNAL messages (see also Section 3.10) can use the session ID to update the existing NATFW NSLP signaling session. NFs that were not on the original path will create new state for this NATFW NSLP signaling session. 🌟 The next section describes how policy rules get updated. 💅
3.10. Updating Policy Rules 💅
NSIS initiators can request an update of the installed or reserved policy rules at any time within a NATFW NSLP signaling session. 💖 Updates can be needed because of node mobility (the NI is moving from one IP address to another), route changes (which can result in a different NAT mapping at a different NAT device), or the NI simply wanting to change the rule. 🔄 NIs can update policy rules in existing NATFW NSLP signaling sessions by sending an appropriate CREATE or EXTERNAL message (similar to Section 3.4) with modified message routing information (MRI) compared to what was installed previously. They use the existing session ID to identify the intended target of the update. 🎯
When it comes to authorization and authentication, this update CREATE or EXTERNAL message is treated in exactly the same way as any initial message. 🔐 So any node along the NATFW NSLP signaling session can reject the update with an error RESPONSE message, as defined in the previous sections. Rude, but fair! 🙅♀️
The message processing and forwarding is executed as defined in the particular sections. An NF or the NR that receives an update simply replaces the installed policy rules in the firewall or NAT. 🧱 The local procedures for how to update the MRI in the firewall or NAT are out of the scope of this memo. 🫠
4. NATFW NSLP Message Components ✨
A NATFW NSLP message consists of an NSLP header and one or more objects following the header. 🎀 The NSLP header is carried in all NATFW NSLP messages, 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 the payload of an NTLP message. 📦
Note that the notation 0x is used to indicate hexadecimal numbers. 🔢
4.1. NSLP Header 🎀
All GIST NSLP-Data objects for the NATFW NSLP MUST contain this common header as the first 32 bits of the object (this is not the same as the GIST Common Header). 💜 It has two fields, the NSLP message type and the P Flag, plus two reserved fields. The total length is 32 bits. The layout of the NSLP header is defined by Figure 20. 🧠
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message type |P|E| reserved | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Common NSLP HeaderThe reserved field MUST be set to zero in the NATFW NSLP header before sending, and it MUST be ignored during processing of the header. 0️⃣
The defined message types are:
0x1: CREATE0x2: EXTERNAL0x3: RESPONSE0x4: NOTIFY
If a message with another type is received, an error RESPONSE of class 'Protocol error' (3) with response code 'Illegal message type' (0x01) MUST be generated. 🚨
The P flag indicates the usage of proxy mode. If proxy mode is used, it MUST be set to 1. Proxy mode MUST only be used in combination with the message types CREATE and EXTERNAL. The P flag MUST be ignored when processing messages with type RESPONSE or NOTIFY. 🔀
The E flag indicates, in proxy mode, whether the edge-NAT or edge-firewall MUST continue sending the message to the NR, i.e., end-to-end. 🌍 The E flag can only be set to 1 if the P flag is set; otherwise, it MUST be ignored. The E flag MUST only be used in combination with the message types CREATE and EXTERNAL. The E flag MUST be ignored when processing messages with type RESPONSE or NOTIFY. 🫶
4.2. NSLP Objects 🧚
NATFW NSLP objects use a common header format defined by Figure 21. 🎀 The object header contains these fields: two flags, two reserved bits, the NSLP object type, a reserved field of 4 bits, 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 21: Common NSLP Object HeaderThe object length field contains 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. ⭐ An error RESPONSE of class 'Protocol error' (3) with response code 'Wrong object length' (0x07) MUST be generated if the length given in the object header is inconsistent with the type of object specified, or if the message is shorter than implied by the object length. 📏
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 [RFC5971], Appendix A.2.1), i.e., objects whose Object Type has not been defined. NATFW NSLP uses a subset of the categories defined in GIST: 🧩
AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected with an error RESPONSE of class 'Protocol error' (3) with response code 'Unknown object present' (0x06). 🛑AB=01 ("Optional"): If the object is not understood, it should be deleted and then the rest of the message processed as usual. 🗑️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, and an error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated. 🙅♀️
The following sections do not repeat the common NSLP object header; they just list the type and the length. 📝
4.2.1. Signaling Session Lifetime Object 🕰️
okay so this object is basically the "how long is this signaling session gonna last" card ✨. It carries the requested or granted lifetime of a NATFW NSLP signaling session, measured in seconds, obvs 💅.
Type: NATFW_LT (0x00C)
Length: 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NATFW NSLP signaling session lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 22: Signaling Session Lifetime Object
4.2.2. External Address Object 🦋
this one can only chill in RESPONSE messages (Section 4.3.3), and nowhere else 🙅♀️. It carries the publicly reachable IP address at an edge-NAT, plus the port number if that applies.
Type: NATFW_EXTERNAL_IP (0x00D)
Length: 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number |IP-Ver | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 23: External Address Object for IPv4 Addresses
heads up bestie 🚨: the port number field MUST be set to 0 if only an IP address has been reserved, like by a traditional NAT. A port number of 0 MUST be ignored when processing this object.
IP-Ver (4 bits) is the IP version number 🌈. This field MUST be set to 4.
4.2.3. External Binding Address Object 🧚
this object can show up in RESPONSE messages (Section 4.3.3) and EXTERNAL messages (Section 3.7.2) 💜. It carries one or multiple external binding addresses, plus the port number if that applies, for multi-level NAT deployments (for an example, see Section 2.5). How the info in this object gets used is described in Appendix B.
Type: NATFW_EXTERNAL_BINDING (0x00E)
Length: 1 + number of IPv4 addresses
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number |IP-Ver | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 24: External Binding Address Object
same deal as before, bestie 🚨: the port number field MUST be set to 0 if only an IP address has been reserved, like by a traditional NAT. A port number of 0 MUST be ignored when processing this object.
IP-Ver (4 bits) is the IP version number 🌈. This field MUST be set to 4.
4.2.4. Extended Flow Information Object 🔥
okay so normally flow info lives in the message routing information (MRI) of the NTLP 📦. Sometimes though, NSLP operations need a little extra info. The 'extended flow information' object carries that extra info about what the policy rule does for firewalls/NATs, plus a potential contiguous port 🎀.
Type: NATFW_EFI (0x00F)
Length: 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule action | sub_ports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 25: Extended Flow Information
this object has two fields, 'rule action' and 'sub_ports' ✨. The 'rule action' field has these meanings:
0x0001: 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.0x0002: 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.
if the 'rule action' field contains neither 0x0001 nor 0x0002, an error RESPONSE of class 'Signaling session failure' (7) with response code 'Unknown policy rule action' (0x05) MUST be generated. 🙅♀️
The 'sub_ports' field contains the number of contiguous transport layer ports the rule applies to 🦋. The default value is 0, which means only the port in the NTLP's MRM or NATFW_DTINFO object gets used for the policy rule. A value of 1 means that, in addition to the port in the NTLP's MRM (port1), a second port (port2) is used too. That port2 is calculated as port2 = port1 + 1. Other values than 0 or 1 MUST NOT be used in this field, and an error RESPONSE of class 'Signaling session failure' (7) with response code 'Requested value in sub_ports field in NATFW_EFI not permitted' (0x08) MUST be generated. These two contiguous numbered ports can be used by legacy voice over IP equipment, which assumes two adjacent port numbers for its RTP/RTCP flows, respectively 🎧.
4.2.5. Information Code Object 💅
this object carries the response code in RESPONSE messages, telling you if a CREATE or EXTERNAL message went through or not, depending on the 'response code' field 📬. It's also carried in a NOTIFY message to explain why the notification is happening.
Type: NATFW_INFO (0x010)
Length: 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv. | Class | Response Code |r|r|r|r| Object Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 26: Information Code Object
the field 'resv.' is reserved for future extensions 🔮. It MUST be set to zero when generating such an object and MUST be ignored when receiving. The 'Object Type' field tells you the type of the object causing the error, and it's set to 0 if no object is concerned. The leading four bits marked with 'r' are always set to zero and ignored. The 4-bit class field holds the error class, and these classes are defined:
0: Reserved1: Informational (NOTIFY only)2: Success3: Protocol error4: Transient failure5: Permanent failure7: Signaling session failure
within each error class, a bunch of response codes are defined as follows 🌈.
- Informational:
0x01: Route change: possible route change on the outbound path.0x02: Re-authentication required.0x03: NATFW node is going down soon.0x04: NATFW signaling session lifetime expired.0x05: NATFW signaling session terminated.
- Success:
0x01: All successfully processed.
- Protocol error:
0x01: Illegal message type: the type given in the Message Type field of the NSLP header is unknown.0x02: Wrong message length: the length given for the message in the NSLP header does not match the length of the message data.0x03: Bad flags value: an undefined flag or combination of flags was set in the NSLP header.0x04: Mandatory object missing: an object required in a message of this type was missing.0x05: Illegal object present: an object was present that must not be used in a message of this type.0x06: Unknown object present: an object of an unknown type was present in the message.0x07: Wrong object length: the length given for the object in the object header did not match the length of the object data present.0x08: Unknown object field value: a field in an object had an unknown value.0x09: Invalid Flag-Field combination: An object contains an invalid combination of flags and/or fields.0x0A: Duplicate object present.0x0B: Received EXTERNAL request message on external side.
- Transient failure:
0x01: Requested resources temporarily not available.
- Permanent failure:
0x01: Authentication failed.0x02: Authorization failed.0x04: Internal or system error.0x06: No edge-device here.0x07: Did not reach the NR.
- Signaling session failure:
0x01: Session terminated asynchronously.0x02: Requested lifetime is too big.0x03: No reservation found matching the MRI of the CREATE request.0x04: Requested policy rule denied due to policy conflict.0x05: Unknown policy rule action.0x06: Requested rule action not applicable.0x07: NATFW_DTINFO object is required.0x08: Requested value in sub_ports field in NATFW_EFI not permitted.0x09: Requested IP protocol not supported.0x0A: Plain IP policy rules not permitted -- need transport layer information.0x0B: ICMP type value not permitted.0x0C: Source IP address range is too large.0x0D: Destination IP address range is too large.0x0E: Source L4-port range is too large.0x0F: Destination L4-port range is too large.0x10: Requested lifetime is too small.0x11: Modified lifetime is too big.0x12: Modified lifetime is too small.
4.2.6. Nonce Object 🌸
this object carries the nonce value, as described in Section 3.7.6 🫶.
Type: NATFW_NONCE (0x011)
Length: 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 27: Nonce Object
4.2.7. Message Sequence Number Object 🍓
last one in this section, and it's giving simple ✨. This object carries the MSN value, as described in Section 3.5.
Type: NATFW_MSN (0x012)
Length: 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 28: Message Sequence Number Object
4.2.8. Data Terminal Information Object
okay bestie, this one is the data terminal information object 💅🎀 it carries extra info that MUST be included in the EXTERNAL message. EXTERNAL messages get transported by the NTLP using the Loose-End message routing method (LE-MRM) 🦋. The LE-MRM only has the DR's IP address and a signaling destination address (destination IP address). That destination IP is only used for routing and isn't necessarily the address of the data sender, so it's not giving "real source" 🙈. This object holds info about (if applicable) the DR's port number (destination port), the DS's port number (source port), the transport protocol, the prefix length of the IP address, and the DS's IP address ✨.
Type: NATFW_DTINFO (0x013)
Length: variable. Maximum 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|P|S| reserved | sender prefix | protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DR port number | DS port number :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPsec-SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data sender's IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: Data Terminal IPv4 Address Objectthe flags are:
- I: I=1 means that 'protocol' should be interpreted.
- P: P=1 means that 'dst port number' and 'src port number' are present and should be interpreted.
- S: S=1 means that SPI is present and should be interpreted.
the SPI field is only present if S is set, and the port numbers are only present if P is set. the flags P and S MUST NOT be set at the same time 🚫. An error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated if they are both set. If either P or S is set, I MUST be set as well, and the protocol field MUST carry the particular protocol. An error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated if S or P is set but I is not set. 💀
the fields MUST be interpreted according to these rules:
- (data) sender prefix: This parameter indicates the prefix length of the 'data sender's IP address' in bits. For instance, a full IPv4 address requires 'sender prefix' to be set to 32. A value of 0 indicates an IP address wildcard. 🌸
- protocol: The IP protocol field. This field MUST be interpreted if I=1; otherwise, it MUST be set to 0 and MUST be ignored.
- DR port number: The port number at the data receiver (DR), i.e., the destination port. 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.
- DS port number: The port number at the data sender (DS), i.e., the source port. 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.
- data sender's IPv4 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 the dest prefix field above). 🧚
4.2.9. ICMP Types Object
the 'ICMP types' object contains the extra info needed to configure a NAT or firewall with rules to control ICMP traffic 🔥. It holds a bunch of values of the ICMP Type field that should get a filter action set up:
Type: NATFW_ICMP_TYPES (0x014)
Length: Variable = ((Number of Types carried + 1) + 3) DIV 4where DIV is an integer division ✨.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Type | Type | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | Type | (Padding) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: ICMP Types Objectthe fields MUST be interpreted according to these rules:
- count: 8-bit integer specifying the number of 'Type' entries in the object.
- type: 8-bit field specifying an ICMP Type value to which this rule applies.
- padding: Sufficient 0 bits to pad out the last word so that the total size of the object is an even multiple of words. Ignored on reception.
4.3. Message Formats
this section defines the content of each NATFW NSLP message type. The message types are defined in Section 4.1.
basically, each message is built from an NSLP header and one or more NSLP objects. The order of objects is not defined, so objects may show up in any sequence 🌀. Objects are marked either mandatory (M) or optional (O). (M) means this object MUST be included in the message, and (O) means this object is OPTIONAL in the message. Objects defined in this memo always carry the flag combination AB=00 in the NSLP object header. An error RESPONSE message of class 'Protocol error' (3) with response code 'Mandatory object missing' (0x04) MUST be generated if a mandatory declared object is missing. An error RESPONSE message of class 'Protocol error' (3) with response code 'Illegal object present' (0x05) MUST be generated if an object was present that must not be used in a message of this type. An error RESPONSE message of class 'Protocol error' (3) with response code 'Duplicate object present' (0x0A) MUST be generated if an object appears more than once in a message.
each section spells out the required settings and parameters the NSLP has to set for the NTLP, like how the message routing info is set 🗺️.
4.3.1. CREATE
the CREATE message is used to create NATFW NSLP signaling sessions and to create policy rules. CREATE messages are also used to refresh NATFW NSLP signaling sessions and to delete them 🔄.
the CREATE message carries these objects:
- Signaling Session Lifetime object (M)
- Extended flow information object (M)
- Message sequence number object (M)
- Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)
- ICMP Types Object (O)
The message routing information in the NTLP MUST be set to DS as source IP address and DR as destination IP address. All other parameters MUST be set according to the required policy rule. CREATE messages MUST be transported by using the path-coupled MRM with the direction set to 'downstream' (outbound) 🌊.
4.3.2. EXTERNAL
the EXTERNAL message is used to a) reserve an external IP address/port at NATs, b) notify firewalls about NSIS capable DRs, or c) block incoming data traffic at inbound firewalls 🛡️.
the EXTERNAL message carries these objects:
- Signaling Session Lifetime object (M)
- Message sequence number object (M)
- Extended flow information object (M)
- Data terminal information object (M)
- Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)
- ICMP Types Object (O)
- External binding address object (O)
the selected message routing method of the EXTERNAL message depends on a number of considerations. Section 3.7.2 describes exhaustively how to select the correct method 📚. EXTERNAL messages can be transported via the path-coupled message routing method (PC-MRM) or via the loose-end message routing method (LE-MRM). In the case of PC-MRM, the source-address is set to the DS's address and the destination-address is set to the DR's address, and the direction is set to inbound. In the case of LE-MRM, the destination-address is set to the DR's address or to the signaling destination IP address. The source-address is set to the DS's address.
4.3.3. RESPONSE
RESPONSE messages are responses to CREATE and EXTERNAL messages. RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE 🙅♀️.
the RESPONSE message for the class 'Success' (2) carries these objects:
- Signaling Session Lifetime object (M)
- Message sequence number object (M)
- Information code object (M)
- External address object (O)
- External binding address object (O)
the RESPONSE message for other classes than 'Success' (2) carries these objects:
- Message sequence number object (M)
- Information code object (M)
- Signaling Session Lifetime object (O)
this message is routed towards the NI hop-by-hop, using existing NTLP messaging associations. The MRM used for this message MUST be the same as the MRM used by the corresponding CREATE or EXTERNAL message 🔁.
4.3.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:
- Information code object (M)
the NOTIFY message is routed towards the next NF, NI, or NR hop-by-hop using the existing inbound or outbound node messaging association entry within the node's Message Routing State table. The MRM used for this message MUST be the same as the MRM used by the corresponding CREATE or EXTERNAL message 💌.
5. Security Considerations
security is a major concern, especially in the case of firewall traversal 🚨. This section provides security considerations for NAT/firewall traversal and is organized as follows.
in Section 5.1, we describe how the participating entities relate to each other from a security point of view. That subsection also motivates a particular authorization model 🔐.
security threats that focus on NSIS in general are described in [RFC4081], and they are applicable to this document as well.
finally, we illustrate how the security requirements that were created based on the security threats can be fulfilled by specific security mechanisms. These aspects will be elaborated in Section 5.2 🫶.
5.1. Authorization Framework ✨
okay so the NATFW NSLP isn't a two-party thing bestie, it can involve a whole bunch of NSIS nodes 🫶 Figures 1 and 2 of [RFC4081] already show the possible communication patterns, and in this section we get to re-check those patterns against how NATFW signaling actually works 🦋
the security stuff for authorization has a direct impact on how each NSLP gets treated 💅 the QoS NSLP [RFC5974] and the Diameter QoS work [RFC5866] show that accounting and charging are a big deal for QoS reservations, whereas money stuff might only indirectly affect authorization decisions for NAT and firewall signaling 💸 so yes, the authorization semantics are different between QoS and NATFW signaling, and it's giving "not the same vibe at all" 🙈 a NATFW-aware node will most likely want to authorize whoever is asking for pinholes or NAT bindings (a user or a machine, whatever) 🔐 the answer is either allowed or disallowed. QoS can be messier, because a QoS decision might say a different set of QoS parameters is authorized (see [RFC5866] as an example) ✨
5.1.1. Peer-to-Peer Relationship
let's start with the simplest scenario 🧚 neighboring nodes are assumed to be able to authenticate each other and set up keying material to protect the signaling messages. on top of authentication, the nodes also have to authorize each other 💜 we use the term 'Security Context' as a placeholder for the whole security procedure: the infrastructure that has to be in place for it to work (e.g., key management) and the security-related state that gets established 🌸 the long-term keys (symmetric or asymmetric) used for authentication are either made available out-of-band between the two NSIS NATFW nodes, or they're dynamically established using mechanisms this document doesn't specify further 🗝️ the deployment environment will most likely affect which credentials get used, and picking those credentials is also outside the scope of this document 🙃
+------------------------+ +-------------------------+
|Network A | | Network B|
| +---------+ +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | Security | box 2 | | |
| | +---------+ Context +---------+ | |
| | Security | | Security | |
| | Context | | Context | |
| | | | | |
| +--+---+ | | +--+---+ |
| | Host | | | | Host | |
| | A | | | | B | |
| +------+ | | +------+ |
+------------------------+ +-------------------------+
Figure 31: Peer-to-Peer RelationshipFigure 31 shows one possible relationship between the NSIS-aware nodes 🦋 Host A could be, say, a host in an enterprise network that has keying material set up (e.g., a shared secret) with the company's firewall (Middlebox 1) 🔥 the network administrator of Network A (the company network) has made access control lists for Host A (or whatever identifiers that company wants to use) 📋 the exact same procedure might also be used between Host B and Middlebox 2 in Network B 💅 and for the communication between Middlebox 1 and Middlebox 2, a security context is also assumed, so that authentication, authorization, and signaling message protection can all actually work 🫶
5.1.2. Intra-Domain Relationship
in bigger corporations, a middlebox is often used to protect individual departments 🏢 usually the whole enterprise is controlled by one (or a small number of) security department(s), and they give instructions to the department admins 👑 in that setup, the peer-to-peer relationship from before might be the main vibe 🌈 sometimes it's necessary to keep authentication and authorization info inside the network, and one option is a centralized approach, where the individual middleboxes talk to a central entity (for example, a policy decision point, or PDP) 🧠 the alternative is that individual middleboxes swap the authorization decision with another middlebox in the same trust domain 🤝 middleboxes inside one administrative domain can use their relationship instead of asking for authentication and authorization of the signaling initiator over and over again 🙌 Figure 32 shows a network structure that uses a centralized entity 🎀
+-----------------------------------------------------------+
| Network A |
| +---------+ +---------+
| +----///--------+ Middle- +------///------++ Middle- +---
| | Security | box 2 | Security | box 2 |
| | Context +----+----+ Context +----+----+
| +----+----+ | | |
| | Middle- +--------+ +---------+ | |
| | box 1 | | | | |
| +----+----+ | | | |
| | Security | +----+-----+ | |
| | Context | | Policy | | |
| +--+---+ +-----------+ Decision +----------+ |
| | Host | | Point | |
| | A | +----------+ |
| +------+ |
+-----------------------------------------------------------+
Figure 32: Intra-Domain Relationshipthe interaction between the individual middleboxes and a policy decision point (or AAA server) is outside the scope of this document 🚫
5.1.3. End-to-Middle Relationship
the peer-to-peer relationship between neighboring NSIS NATFW NSLP nodes might not always be enough 🥺 Network B might need extra authorization of the signaling message initiator (on top of authorizing the neighboring node) 🔍 if the authentication and authorization info isn't attached to the initial signaling message, then the signaling message that shows up at Middlebox 2 creates an error message, and that error says there's an additional authorization requirement 🚨 in lots of cases, the initiator already knows about that extra authorization requirement before the signaling exchange even starts 🧚
Figure 33 shows this scenario 🦋
+--------------------+ +---------------------+
| Network A | |Network B |
| | Security | |
| +---------+ Context +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | +-------+ box 2 | | |
| | +---------+ | +---------+ | |
| |Security | | | Security | |
| |Context | | | Context |
| | | | | | |
| +--+---+ | | | +--+---+ |
| | Host +----///----+------+ | | Host | |
| | A | | Security | | B | |
| +------+ | Context | +------+ |
+--------------------+ +---------------------+
Figure 33: End-to-Middle Relationship5.2. Security Framework for the NAT/Firewall NSLP
this is the list of security requirements that was put together to make sure the NATFW NSLP runs securely 🔒
5.2.1. Security Protection between Neighboring NATFW NSLP Nodes
based on the threats we analyzed, it is RECOMMENDED to provide these mechanisms between neighboring NATFW NSLP nodes 🛡️
- data origin authentication,
- replay protection,
- integrity protection, and,
- optionally, confidentiality protection
it is RECOMMENDED to use the authentication and key exchange security mechanisms from [RFC5971] between neighboring nodes whenever they send NATFW signaling messages 🗝️ GIST's proposed security mechanisms support authentication and key exchange, plus denial-of-service protection 💪 depending on which security protocol gets picked, support for multiple authentication protocols might be there too 🌈 if you want security between neighboring nodes, using C-MODE with a secure transport protocol to deliver most NSIS messages, and using D-MODE only to discover the next NATFW NSLP-aware node along the path, is highly RECOMMENDED 🫶 see [RFC5971] for the definitions of C-MODE and D-MODE 📖 almost all security threats at the NATFW NSLP layer can be prevented by using a mutually authenticated Transport Layer secured connection and by relying on authorization from the neighboring NATFW NSLP entities 😤
the NATFW NSLP depends on a security association that's already established between neighboring peers, so that unauthorized nodes can't modify or delete installed state 🚫 between non-neighboring nodes, the session ID (SID) carried in the NTLP is what shows ownership of a NATFW NSLP signaling session 🪪 the session ID MUST be generated randomly, which keeps an off-path adversary from launching targeted attacks 🎲 so an adversary would have to learn that randomly generated session ID before they could attack anything 🕵️ in a mobility environment, a former on-path node that's now off-path can still perform an attack 🫣 messages for a particular NATFW NSLP signaling session get handed from the NTLP up to the NATFW NSLP for further processing 📬 messages carrying a session ID that isn't associated with any NATFW NSLP session go through the regular processing for new NATFW NSLP signaling sessions 🌸
5.2.2. Security Protection between Non-Neighboring NATFW NSLP Nodes ✨
okay so the security threats and the requirements list showed something important 👀 some threats need a NATFW signaling entity (including the initiator) to be authenticated and authorized towards a node that isn't its neighbor 🔐 this mechanism mostly needs entity authentication. The big deal in NATFW NSLP is the info for setting up firewall pinholes and NAT bindings 🕳️, but that info can't be protected across multiple NSIS NATFW NSLP hops, because it can change depending on what each individual NATFW NSLP node is capable of 🙃
some scenarios could also get major glow-ups from authorization tokens 💫 their whole purpose is linking two different signaling protocols (like SIP and NSIS) together with their authorization decision 🔗 the tokens come from non-NSIS protocols, like SIP or as part of network access authentication. When a NAT or firewall along the path gets the token, it can check it locally or pass it along to the AAA infrastructure 🛡️ examples of these tokens are in RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. Figure 34 shows how this goes down 👇
the SIP proxy makes the authorization token. It's the assertion generating entity, and the token gets delivered to the end host with proper authentication and authorization 🎀 when the NATFW signaling message heads out toward the network, the token gets attached to it so it can point back to the earlier authorization decision 📎 the assertion-verifying entity has to process the token, or it might need to talk to the assertion-granting entity over HTTP (or other protocols) 💬 once a NATFW NSLP node successfully authorizes it, the requested action gets executed, and a RESPONSE message is generated later 💌
+----------------+ Trust Relationship +----------------+
| +------------+ |<.......................>| +------------+ |
| | Protocol | | | | Assertion | |
| | requesting | | HTTP, SIP Request | | Granting | |
| | authz | |------------------------>| | Entity | |
| | assertions | |<------------------------| +------------+ |
| +------------+ | Artifact/Assertion | Entity Cecil |
| ^ | +----------------+
| | | ^ ^|
| | | Trust . || HTTP,
| 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 34: Authorization Token Usagenow the security part, and this is serious 🚨 threats against authorization tokens are covered in [RFC4081]. So it's required to give them confidentiality protection, otherwise an eavesdropper could snag the token and reuse it in another NATFW NSLP signaling session (a replay attack) 😱 the token also needs protection against tampering 🧱
5.3. Implementation of NATFW NSLP Security 🏰
the earlier sections explain how to lock down NATFW NSLP when there's already trust between the players and the specific relationships (like intra-domain, end-to-middle, or peer-to-peer) 🤝 but in typical Internet deployments there's no established trust, apart from granting access to a network, and definitely not between different sites on the Internet 🌐 on top of that, NATFW NSLP may get rolled out gradually, with wildly different abilities to use authentication and authorization services 🧩
NATFW NSLP lets the authentication and authorization stay at the "edge" of the network 🌱 the local edge network can use any kind of Authentication and Authorization (AA) scheme it wants, without its AA tech needing to match the other edges out there (assuming firewalls and NATs sit at the edges and not somewhere in the cores) 💅
every network edge with NATFW NSLP deployed can use the EXTERNAL request message to get secure access to the network 🔑 using the EXTERNAL request message does let the DR open the firewall/NAT on the receiver's side ✨ but the edge devices should not let the firewall/NAT get opened up completely (meaning they should not apply an allow-all policy) 🙅♀️ instead, they should let DRs reserve very specific policies 🎯 for example, a DR can request a reservation of an 'allow' policy rule for an incoming TCP connection for a Jabber file transfer 📁 this reserved policy (see Figure 15) rule must be activated by matching the CREATE request message (see Figure 15) 💥 this way, authentication and authorization issues get handled locally at that particular edge network 🏠 going the other way, the CREATE request message can be handled independently on the DS side when it comes to authentication and authorization 🙌
the setup above gets even simpler for incremental deployment 🐣 there's no requirement to activate a reserved policy rule with a CREATE request message. Everything is handled by the EXTERNAL-PROXY request message and its associated CREATE request message, and both of them are handled by the local authentication and authorization scheme 🫶
6. IAB Considerations on UNSAF 🦋
UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a process at originating endpoints that tries to figure out or fix the address (and port) they're known by to another endpoint 🧭 UNSAF proposals like STUN [RFC5389] are seen as a general class of workarounds for NAT traversal, and as solutions for scenarios with no middlebox communication 🪄
this memo specifies a path-coupled middlebox communication protocol, which is the NSIS NATFW NSLP 🛤️ NSIS in general and NATFW NSLP aren't meant to be a short-term workaround. They're more of a long-term solution for middlebox communication 🌷 in NSIS, endpoints are involved in allocating, maintaining, and deleting addresses and ports at the middlebox 📦 but full control of addresses and ports at the middlebox belongs to the NATFW NSLP daemon at the respective NAT 👑
so this document deals with the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution 💜
7. IANA Considerations 📋
this section gives guidance to the Internet Assigned Numbers Authority (IANA) on registering values related to NATFW NSLP, following BCP 26, RFC 5226 [RFC5226] 🙌
NATFW NSLP needs IANA to create a few new registries:
- NATFW NSLP Message Types
- NATFW NSLP Header Flags
- NSLP Response Codes
it also needs new values registered in a few existing registries:
- NSLP Message Objects
- NSLP Identifiers (under GIST Parameters)
- Router Alert Option Values (IPv4 and IPv6)
7.1. NATFW NSLP Message Type Registry 💌
the NATFW NSLP Message Type is an 8-bit value. Allocating values for new message types requires IETF Review. Updating or deleting values from the registry isn't possible 🙅♀️ this spec defines four NATFW NSLP message types, which form the initial contents of this registry. IANA added these four NATFW NSLP Message Types: CREATE (0x1), EXTERNAL (0x2), RESPONSE (0x3), and NOTIFY (0x4). 0x0 is Reserved 🫧 each registry entry has a value, description, and reference.
7.2. NATFW NSLP Header Flag Registry 🚩
NATFW NSLP messages have a message-specific 8-bit flags/reserved field in their header. Registering flags goes through IANA registration. Allocating values for flag types requires IETF Review, and updating or deleting values from the registry isn't possible either 🙈 this spec defines only two flags in Section 4.1: the P flag (bit 8) and the E flag (bit 9) ✨ each registry entry has a value, bit position, description (containing the section number), and reference.
7.3. NSLP Message Object Registry 🧃
in Section 4.2, this document defines 9 objects for NATFW NSLP: NATFW_LT, NATFW_EXTERNAL_IP, NATFW_EXTERNAL_BINDING, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, NATFW_DTINFO, and NATFW_ICMP_TYPES. IANA assigned values for them from the NSLP Message Objects registry 🎀
7.4. NSLP Response Code Registry 🔢
this document also defines a bunch of Response Codes for NATFW NSLP. You can find them in Section 4.2.5, and they've been assigned values from the NSLP Response Code registry 💖 allocating new values for Response Codes requires IETF Review. IANA assigned values as given in Section 4.2.5 for the error class, and also for the number of responses values per error class 🌈 each registry entry has a response code, value, description, and reference.
7.5. NSLP IDs and Router Alert Option Values 🛎️
GIST NSLPID
this spec defines an NSLP for use with GIST, so it needs an assigned NSLP identifier 🪪 IANA added one new value (33) to the NSLP Identifiers (NSLPID) registry defined in [RFC5971] for NATFW NSLP 🎉
IPv4 and IPv6 Router Alert Option (RAO) value
GIST also requires each NSLP-ID to be associated with a specific Router Alert Option (RAO) value 🚨 for NATFW NSLP, a single IPv4 RAO value (65) and a single IPv6 RAO value (68) have been allocated 💫
8. Acknowledgments 🫶
we'd like to thank these lovely people for their contributions to this document at different stages 💗
- Marcus Brunner and Henning Schulzrinne, for their work on IETF documents that led us to start with this document;
- Miquel Martin, for his huge contribution on the initial version of this document and one of the first prototype implementations;
- Srinath Thiruvengadam and Ali Fessi, for their work on the NAT/firewall threats document;
- Henning Peters, for his comments and suggestions;
- Ben Campbell, as Gen-ART reviewer;
- and the NSIS working group 🧚
9. References 📚
9.1. Normative References 🔖
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", RFC 5971, October 2010.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.9.2. Informative References 📚✨
These are the extra reads for when you wanna go deeper 🤓💖
- [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
- [RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
- [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
- [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010.
- [RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
- [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
- [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
- [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
- [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
- [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
- [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
- [RFC3198] 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.
- [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
- [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003.
- [rsvp-firewall] 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.
Appendix A. Selecting Signaling Destination Addresses for EXTERNAL 🎯
Okay so EXTERNAL messages need a reachable IP address of the data sender on the GIST level, same as every other message type 💌. For the path-coupled MRM, the GIST source-address is the reachable IP address (aka the real IP address of the data sender, or a wildcard) ✨. That's straightforward, but for the loose-end MRM it's not always so 🙈. Lots of applications don't hand over the IP address of the communication counterpart, meaning the data sender or both a data sender and receiver. For EXTERNAL messages only the data sender case matters. The rest of this section is informational guidance on picking a good destination address for the LE-MRM in GIST for EXTERNAL messages 🧚.
This signaling destination address (SDA, the destination-address in GIST) can be the data sender. But if an app doesn't give you an address upfront, the destination IP address has to be picked independently, since it's unknown when NATFW NSLP signaling has to start 😭. Choosing the 'correct' destination IP address can be tricky, and honestly there might be no 'right answer' for every app that relies on NATFW NSLP 💀.
Whenever possible, it is RECOMMENDED to choose the data sender's IP address as the SDA 💅. You need to be able to tell apart the different IP addresses the data sender has. Some application-level signaling protocols (e.g., SIP) can transfer multiple contact IP addresses of the data sender, like private IP addresses, public IP addresses at a NAT, and public IP addresses at a relay 🌸. It is RECOMMENDED to use all non-private IP addresses as SDAs 🫶.
A different SDA must be chosen if the IP address of the data sender is unknown 🥺. That can happen for a couple of reasons: the application-level signaling protocol can't determine any data sender IP address at that point in time, or the data receiver is a server behind a NAT, meaning it accepts inbound packets from any host 🏠. In that case, the NATFW NSLP can be instructed to use the public IP address of an application server or any other node 🌐. Choosing the SDA here is out of scope for the NATFW NSLP and depends on the application's choice 👑. The local network can provide a network-SDA, which is an SDA that's only meaningful to the local network. This makes sure GIST packets with destination-address set to this network-SDA get routed to an edge-NAT or edge-firewall 🦋.
Appendix B. Usage of External Binding Addresses 🌈
The NATFW_EXTERNAL_BINDING object carries information with a different use from the information in the NATFW_EXTERNAL_IP object 💜. The NATFW_EXTERNAL_IP object has the public IP address and potentially port numbers that the application at the NI can use to be reachable via the public Internet ✨. But there are cases where various NIs sit behind the same public NAT and are subject to a multi-level NAT deployment, as shown in Figure 35 🤯. They can use the public IP address and port assigned to them to communicate with each other (e.g., NI with NR1 and NR2), but they're forced to send their traffic through the edge-NAT even though there's a shorter way 😤.
NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP)
|
NR1--192.168.0/24-- NAT3--
|
NR2 10.1.2.3
Figure 35: Multi-Level NAT ScenarioFigure 35 shows an example that we're gonna explore here:
- NI -> NR1: Both NI and NR1 send EXTERNAL messages towards NAT2 and get an external address+port binding. Then they exchange that external binding, and all traffic gets pinned to NAT2 instead of taking the shortest path by NAT1 to NAT3 directly. However, to do that, NR1 and NI both need to be aware that they also have the address on the external side of NAT1 and NAT3, respectively. If ICE is deployed and there is actually a STUN server in the 10/8 network configured, it is possible to get the shorter path to work. The NATFW NSLP provides all external addresses in the NATFW_EXTERNAL_BINDING towards the public network, which it could allow for optimizations.
- For the case NI -> NR2 it's even more obvious. Pinning this to NAT2 is an important fallback, but allowing for trying a direct path between NAT1 and NAT3 might be worth it.
Heads up: if there are overlapping address domains between NR and the public Internet, the regular routing will not necessarily allow sending the packet to the right domain ⚠️
Appendix C. Applicability Statement on Data Receivers behind Firewalls 🔥
Section 3.7.2 describes how data receivers behind middleboxes can instruct inbound firewalls/NATs to forward NATFW NSLP signaling towards them 📬. Finding an inbound edge-NAT in an address environment with NAT'ed addresses is pretty easy. You only need to find some edge-NAT, since the data traffic will be route-pinned to the NAT 📍. Locating the appropriate edge-firewall with the PC-MRM sent inbound is harder. For cases with a single, symmetric route from the Internet to the data receiver, it's quite easy: just follow the default route in the inbound direction 🛣️.
+------+ Data Flow
+-------| EFW1 +----------+ <===========
| +------+ ,--+--.
+--+--+ / \
NI+-----| FW1 | (Internet )----NR+/NI/DS
NR +--+--+ \ /
| +------+ `--+--'
+-------| EFW2 +----------+
+------+
~~~~~~~~~~~~~~~~~~~~~>
Signaling Flow
Figure 36: Data Receiver behind Multiple Firewalls
Located in ParallelWhen a data receiver, and thus NR, is located in a network site that is multihomed with several independently firewalled connections to the public Internet (as shown in Figure 36), the specific firewall through which the data traffic will be routed has to be figured out 🧐. NATFW NSLP signaling messages sent from the NI+/NR during the EXTERNAL message exchange towards the NR+ must be routed by the NTLP to the edge-firewall that the data traffic will also pass through ✈️. The NTLP would need to be aware of the routing within the Internet to determine the path between the DS and DR. From that, the NTLP could determine which of the edge-firewalls, either EFW1 or EFW2, must be selected to forward the NATFW NSLP signaling. Signaling to the wrong edge-firewall, as shown in Figure 36, would install the NATFW NSLP policy rules at the wrong device. That causes either a blocked data flow (when the policy rule is 'allow') or an ongoing attack (when the policy rule is 'deny') 😱. Requiring the NTLP to know all about the routing within the Internet is definitely a tough challenge and usually not possible. In a case like this, the NTLP must basically give up and return an error to the NSLP level, indicating that next hop discovery is not possible 🙅.
Appendix D. Firewall and NAT Resources 🧱
This section gives some examples of how NATFW NSLP policy rules could be mapped to real firewall or NAT resources 💻. The firewall rules and NAT bindings are described in a natural way, i.e., in a way you'd find in common implementations.
D.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 5.8 of [RFC5971].
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, take an MRI with IP addresses set (not wildcarded), transport protocol TCP, and TCP port numbers completely wildcarded. If the local policy allows only requests for TCP with all ports set and not wildcarded, the request is going to be rejected 🚫.
D.2. Mapping to Firewall Rules 🧱
okay so this bit shows how a NATFW NSLP policy rule that gets signaled with a CREATE message turns into a firewall rule 💅 the MRI gets set like this:
network-layer-version=IPv4source-address=192.0.2.100, prefix-length=32destination-address=192.0.50.5, prefix-length=32IP-protocol=UDPL4-source-port=34543, L4-destination-port=23198
The NATFW_EFI object is set to action=allow and sub_ports=0 ✨
the resulting policy rule (firewall rule) to be installed might look like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198 🔥
D.3. Mapping to NAT Bindings 🦋
this one is about how a NATFW NSLP policy rule signaled with an EXTERNAL message becomes a NAT binding 🌸 we're assuming the EXTERNAL message comes from a NI+ that's sitting behind a NAT, and it does include a NATFW_DTINFO object. since the real data sender's IP address isn't known, the MRI gets set using the signaling destination address (SDA), like so:
network-layer-version=IPv4source-address= 192.168.5.100destination-address=SDAIP-protocol=UDP
the NATFW_EFI object is set to action=allow and sub_ports=0. the NATFW_DTINFO object carries these parameters:
P=1dest prefix=0protocol=UDPdst port number = 20230, src port number=0src IP=0.0.0.0
the edge-NAT allocates the external IP 192.0.2.79 and port 45000 🧚
the resulting policy rule (NAT binding) to be installed could look like: translate udp from any to 192.0.2.79 port=45000 to 192.168.5.100 port=20230. 💖
D.4. NSLP Handling of Twice-NAT 👑
okay so, twice-NATs need application-level support to get configured dynamically, like we said back in Section 2.5 🙈 the NATFW NSLP cannot be used to configure twice-NATs if application-level support is needed, periodt. but if you've got application-level support doing the twice-NAT configuration AND the NATFW NSLP installed on these devices, the NATFW NSLP must be able to traverse it ✨ the NSLP probably can get through the twice-NAT, just like any other data traffic, BUT the flow information stored in the NTLP's MRI gets invalidated because the source and destination IP addresses get translated 😭
the NATFW NSLP implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP signaling messages, the same way any other NATFW NSLP node does 💅 for the given signaling flow, the NATFW NSLP node MUST look up the matching IP address translation and modify the NTLP/NSLP signaling accordingly. that modification leaves you with an updated MRI for the source and destination IP addresses. main character energy 🎀
Appendix E. Example for Receiver Proxy Case 🎀
okay this is the example for a receiver that's behind a NAT, where only the receiving side runs the NATFW NSLP 🫶 we're using FTP as the app so it's a real working example. an FTP server sits behind a NAT (see Figure 5) and uses the NATFW NSLP to grab NAT bindings for both the control channel and the data channel of FTP 🦋 the info about where to find the server gets passed to the DS side through some separate protocol (think email or chat, iykyk) 💬
Public Internet Private Address
Space
FTP Client FTP Server
DS NAT NI+
| | |
| | EXTERNAL |
| |<---------------------------|(1)
| | |
| |RESPONSE[Success] |
| |--------------------------->|(2)
| |CREATE |
| |--------------------------->|(3)
| |RESPONSE[Success] |
| |<---------------------------|(4)
| | |
| | <Use port=XYZ, IP=a.b.c.d> |
|<=======================================================|(5)
|FTP control port=XYZ | FTP control port=21 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(6)
| | |
| FTP control/get X | FTP control/get X |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(7)
| | EXTERNAL |
| |<---------------------------|(8)
| | |
| |RESPONSE[Success] |
| |--------------------------->|(9)
| |CREATE |
| |--------------------------->|(10)
| |RESPONSE[Success] |
| |<---------------------------|(11)
| | |
| Use port=FOO, IP=a.b.c.d | Use port=FOO, IP=a.b.c.d |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~|<~~~~~~~~~~~~~~~~~~~~~~~~~~~|(12)
| | |
|FTP data to port=FOO | FTP data to port=20 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(13)
Figure 37: Flow Chart- 📨 EXTERNAL request goes to the NAT, carrying these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (carrying nonce for CREATE), and the data terminal information object (I/P-flags set, sender prefix=0, protocol=TCP, DR port number = 21, DS's IP address=0). it uses the LE-MRM. this one allocates the external binding for the FTP control channel (TCP, port 21).
- ✅ a successful RESPONSE goes back to NI+, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2), and external address object (port=XYZ, IPv4 addr=a.b.c.d).
- 🔁 the NAT sends a CREATE to NI+, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, and nonce object (with copied value from (1)). it uses the PC-MRM (src-IP=a.b.c.d, src-port=XYZ, dst-IP=NI+, dst-port=21, downstream).
- ✅ a successful RESPONSE goes to the NAT, with these objects: signaling session lifetime, message sequence number object, and information code object ('Success':2).
- 🗣️ the application at NI+ passes the external NAT binding info along to the other end, which is the FTP client at the DS.
- 🔌 the FTP client connects its control channel to port=XYZ, IP=a.b.c.d.
- 📂 the FTP client sends a get command for file X.
- 📨 another EXTERNAL request goes to the NAT, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (carrying nonce for CREATE), and the data terminal information object (I/P-flags set, sender prefix=32, protocol=TCP, DR port number = 20, DS's IP address=DS-IP). it uses the LE-MRM. this one allocates the external binding for the FTP data channel (TCP, port 22).
- ✅ a successful RESPONSE goes to NI+, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2), and external address object (port=FOO, IPv4 addr=a.b.c.d).
- 🔁 the NAT sends a CREATE to NI+, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, and nonce object (with copied value from (1)). it uses the PC-MRM (src-IP=a.b.c.d, src-port=FOO, dst-IP=NI+, dst-port=20, downstream).
- ✅ a successful RESPONSE goes to the NAT, with these objects: signaling session lifetime, message sequence number object, and information code object ('Success':2).
- 💌 the FTP server responds with port=FOO and IP=a.b.c.d.
- 🚀 the FTP client connects its data channel to port=FOO and IP=a.b.c.d. 🦋
Authors' Addresses 💜
Martin Stiemerling
NEC Europe Ltd. and University of Goettingen
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 4342 113
EMail: Martin.Stiemerling@neclab.eu
URI: http://www.stiemerling.org
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Cedric Aoun
Consultant
Paris, France
EMail: cedaoun@yahoo.fr
Elwyn Davies
Folly Consulting
Soham
UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com📦 where this page comes from
- ietf: rfc5973 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms