idnits 2.17.00 (12 Aug 2021) /tmp/idnits48950/draft-ietf-nsis-nslp-natfw-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4258. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o NSLP forwarder being either edge-NAT or edge-firewall: When the NF accepts a EXT_PROXY message, it generates a successful RESPONSE message as if it were the NR and additionally, it generates a CREATE message as defined in Section 3.7.1 and includes a NATFW_NONCE object having the same value as of the received NATFW_NONCE object. The NF MUST not generate a CREATE-PROXY message. The NF MUST refresh the CREATE message signaling session only if a EXT-PROXY refresh message has been received first. This also includes tearing down signaling sessions, i.e., the NF must teardown the CREATE signaling session only if a EXT-PROXY message with lifetime set to 0 has been received first. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2007) is 5555 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-nsis-ntlp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '13') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. '14') (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '15') (Obsoleted by RFC 5389) == Outdated reference: A later version (-04) exists of draft-manner-nsis-nslp-auth-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group M. Stiemerling 3 Internet-Draft NEC 4 Intended status: Standards Track H. Tschofenig 5 Expires: September 6, 2007 Siemens 6 C. Aoun 8 E. Davies 9 Folly Consulting 10 March 5, 2007 12 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 13 draft-ietf-nsis-nslp-natfw-14.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 6, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This memo defines the NSIS Signaling Layer Protocol (NSLP) for 47 Network Address Translators (NATs) and firewalls. This NSLP allows 48 hosts to signal on the data path for NATs and firewalls to be 49 configured according to the needs of the application data flows. It 50 enables hosts behind NATs to obtain a public reachable address and 51 hosts behind firewalls to receive data traffic. The overall 52 architecture is given by the framework and requirements defined by 53 the Next Steps in Signaling (NSIS) working group. The network 54 scenarios, the protocol itself, and examples for path-coupled 55 signaling are given in this memo. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 7 61 1.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 62 1.3. General Scenario for NATFW Traversal . . . . . . . . . . 11 64 2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 13 65 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . 13 66 2.2. NAT with two private Networks . . . . . . . . . . . . . . 14 67 2.3. NAT with Private Network on Sender Side . . . . . . . . . 15 68 2.4. NAT with Private Network on Receiver Side Scenario . . . 15 69 2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . 16 70 2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . 17 71 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18 72 2.8. Multihomed Network with Firewall . . . . . . . . . . . . 19 74 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 20 75 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . 20 76 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21 77 3.2.1. Message Types . . . . . . . . . . . . . . . . . . . . 25 78 3.2.2. Classification of RESPONSE Messages . . . . . . . . . 25 79 3.2.3. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26 80 3.3. Basic Message Processing . . . . . . . . . . . . . . . . 27 81 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27 82 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . 30 83 3.6. Authentication, Authorization, and Policy Decisions . . . 31 84 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 32 85 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 32 86 3.7.2. Reserving External Addresses . . . . . . . . . . . . 35 87 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . 42 88 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 43 89 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 44 90 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 46 92 3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 49 93 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 51 94 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 51 96 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 53 97 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 53 98 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . 54 99 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 55 100 4.2.2. External Address Object . . . . . . . . . . . . . . . 55 101 4.2.3. Extended Flow Information Object . . . . . . . . . . 56 102 4.2.4. Information Code Object . . . . . . . . . . . . . . . 57 103 4.2.5. Nonce Object . . . . . . . . . . . . . . . . . . . . 60 104 4.2.6. Message Sequence Number Object . . . . . . . . . . . 60 105 4.2.7. Data Terminal Information Object . . . . . . . . . . 61 106 4.2.8. ICMP Types Object . . . . . . . . . . . . . . . . . . 62 107 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 63 108 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . 64 109 4.3.2. EXTERNAL (EXT) . . . . . . . . . . . . . . . . . . . 64 110 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . 65 111 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 65 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 67 114 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 67 115 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 67 116 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 68 117 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . 69 118 5.2. Security Threats and Requirements . . . . . . . . . . . . 70 119 5.2.1. Data Sender (DS) behind a firewall . . . . . . . . . 70 120 5.2.2. Data Sender (DS) behind a NAT . . . . . . . . . . . . 71 121 5.2.3. Data Receiver (DR) behind a firewall . . . . . . . . 71 122 5.2.4. Data Receiver (DR) behind a NAT . . . . . . . . . . . 73 123 5.2.5. NSLP Message Injection . . . . . . . . . . . . . . . 74 124 5.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 75 125 5.3.1. Flooding with CREATE messages from outside . . . . . 75 126 5.3.2. Flooding with EXT messages from inside . . . . . . . 76 127 5.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 76 128 5.5. Message Modification by non-NSIS on-path node . . . . . . 77 129 5.6. Message Modification by malicious NSIS node . . . . . . . 77 130 5.7. Signaling Session Ownership . . . . . . . . . . . . . . . 78 131 5.7.1. Misuse of Mobility in a NAT Handling Scenario . . . . 78 132 5.8. Misuse of unreleased signaling sessions . . . . . . . . . 79 133 5.9. Data Traffic Injection . . . . . . . . . . . . . . . . . 81 134 5.10. Eavesdropping and Traffic Analysis . . . . . . . . . . . 81 135 5.11. Security Framework for the NAT/Firewall NSLP . . . . . . 81 136 5.11.1. Security Protection between neighboring NATFW NSLP 137 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 82 138 5.11.2. Security Protection between non-neighboring NATFW 139 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . 82 141 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 85 143 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 145 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 88 147 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 89 149 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 150 10.1. Normative References . . . . . . . . . . . . . . . . . . 90 151 10.2. Informative References . . . . . . . . . . . . . . . . . 90 153 Appendix A. Selecting Signaling Destination Addresses for EXT . 92 155 Appendix B. Applicability Statement on Data Receivers behind 156 Firewalls . . . . . . . . . . . . . . . . . . . . . 93 158 Appendix C. Firewall and NAT Resources . . . . . . . . . . . . . 95 159 C.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 95 160 C.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 95 161 C.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 96 162 C.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . 96 164 Appendix D. Assigned Numbers for Testing . . . . . . . . . . . . 98 166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 99 167 Intellectual Property and Copyright Statements . . . . . . . . . 100 169 1. Introduction 171 Firewalls and Network Address Translators (NAT) have both been used 172 throughout the Internet for many years, and they will remain present 173 for the foreseeable future. Firewalls are used to protect networks 174 against certain types of attacks from internal networks and the 175 Internet, whereas NATs provide a virtual extension of the IP address 176 space. Both types of devices may be obstacles to some applications, 177 since they only allow traffic created by a limited set of 178 applications to traverse them, typically those that use protocols 179 with relatively predetermined and static properties (e.g., most HTTP 180 traffic, and other client/server applications). Other applications, 181 such as IP telephony and most other peer-to-peer applications, which 182 have more dynamic properties, create traffic that is unable to 183 traverse NATs and firewalls unassisted. In practice, the traffic of 184 many applications cannot traverse autonomous firewalls or NATs, even 185 when they have additional functionality which attempts to restore the 186 transparency of the network. 188 Several solutions to enable applications to traverse such entities 189 have been proposed and are currently in use. Typically, application 190 level gateways (ALG) have been integrated with the firewall or NAT to 191 configure the firewall or NAT dynamically. Another approach is 192 middlebox communication (MIDCOM). In this approach, ALGs external to 193 the firewall or NAT configure the corresponding entity via the MIDCOM 194 protocol [7]. Several other work-around solutions are available, 195 such as STUN [15]. However, all of these approaches introduce other 196 problems that are generally hard to solve, such as dependencies on 197 the type of NAT implementation (full-cone, symmetric, etc), or 198 dependencies on certain network topologies. 200 NAT and firewall (NATFW) signaling shares a property with Quality of 201 Service (QoS) signaling. The signaling of both must reach any device 202 on the data path that is involved in, respectively, NATFW or QoS 203 treatment of data packets. This means, that for both, NATFW and QoS, 204 it is convenient if signaling travels path-coupled, meaning that the 205 signaling messages follow exactly the same path that the data packets 206 take. RSVP [11] is an example of a current QoS signaling protocol 207 that is path-coupled. [22] proposes the use of RSVP as firewall 208 signaling protocol but does not include NATs. 210 This memo defines a path-coupled signaling protocol for NAT and 211 firewall configuration within the framework of NSIS, called the NATFW 212 NSIS Signaling Layer Protocol (NSLP). The general requirements for 213 NSIS are defined in [5] and the general framework of NSIS is outlined 214 in [4]. It introduces the split between an NSIS transport layer and 215 an NSIS signaling layer. The transport of NSLP messages is handled 216 by an NSIS Network Transport Layer Protocol (NTLP, with General 217 Internet Signaling Transport (GIST) [2] being the implementation of 218 the abstract NTLP). The signaling logic for QoS and NATFW signaling 219 is implemented in the different NSLPs. The QoS NSLP is defined in 220 [6]. 222 The NATFW NSLP is designed to request the dynamic configuration of 223 NATs and/or firewalls along the data path. Dynamic configuration 224 includes enabling data flows to traverse these devices without being 225 obstructed, as well as blocking of particular data flows at inbound 226 firewalls. Enabling data flows requires the loading of firewall 227 rules with an action that allows the data flow packets to be 228 forwarded and creating NAT bindings. Blocking of data flows requires 229 the loading of firewalls rules with an action that will deny 230 forwarding of the data flow packets. A simplified example for 231 enabling data flows: A source host sends a NATFW NSLP signaling 232 message towards its data destination. This message follows the data 233 path. Every NATFW NSLP-enabled NAT/firewall along the data path 234 intercepts these messages, processes them, and configures itself 235 accordingly. Thereafter, the actual data flow can traverse all these 236 configured firewalls/NATs. 238 It is necessary to distinguish between two different basic scenarios 239 when operating the NATFW NSLP, independent of the type of the 240 middleboxes to be configured. 242 1. Both, data sender and data receiver, are NSIS NATFW NSLP aware. 243 This includes the cases where the data sender is logically 244 decomposed from the NSIS initiator or the data receiver logically 245 decomposed from the NSIS receiver, but both sides support NSIS. 246 This scenario assumes deployment of NSIS all over the Internet, 247 or at least at all NATs and firewalls. This scenario is used as 248 base assumption, if not otherwise noted. 250 2. Only one end host or region of the network is NSIS NATFW NSLP 251 aware, either data receiver or data sender. This scenario is 252 referred to as proxy mode. 254 The NATFW NSLP has two basic signaling messages which are sufficient 255 to cope with the various possible scenarios likely to be encountered 256 before and after widespread deployment of NSIS: 258 CREATE message: The basic message for configuring a path outbound 259 from a data sender to a data receiver. 261 EXTERNAL (EXT) message: Used to locate inbound NATs/firewalls and 262 prime them to expect outbound signaling and at NATs to pre- 263 allocate a public address. This is used for data receivers behind 264 these devices to enable their reachability. 266 CREATE and EXT messages are sent by the NSIS initiator (NI) towards 267 the NSIS responder (NR). Both type of messages are acknowledged by a 268 subsequent RESPONSE message. This RESPONSE message is generated by 269 the NR if the requested configuration can be established, otherwise 270 the NR or any of the NSIS forwarders (NFs) can also generate such a 271 message if an error occurs. NFs and the NR can also generate 272 asynchronous messages to notify the NI, the so called NOTIFY 273 messages. 275 If the data receiver resides in a private addressing realm or 276 firewall, and needs to preconfigure the edge-NAT/edge-firewall to 277 provide a (publicly) reachable address for use by the data sender, a 278 combination of EXTERNAL and CREATE messages is used. 280 During the introduction of NSIS, it is likely that one or other of 281 the data sender and receiver will not be NSIS aware. In these cases, 282 the NATFW NSLP can utilize NSIS aware middleboxes on the path between 283 the data sender and data receiver to provide proxy NATFW NSLP 284 services (i.e., the proxy mode operation). Typically, these boxes 285 will be at the boundaries of the realms in which the end hosts are 286 located. 288 The CREATE and EXT messages create NATFW NSLP and NTLP state in NSIS 289 entities. NTLP state allows signaling messages to travel in the 290 forward (outbound) and the reverse (inbound) direction along the path 291 between a NAT/firewall NSLP sender and a corresponding receiver. 292 This state is managed using a soft-state mechanism, i.e., it expires 293 unless it is refreshed from time to time. The NAT bindings and 294 firewall rules being installed during the state setup are bound to 295 the particular signaling session. However, the exact local 296 implementation of the NAT bindings and firewall rules are NAT/ 297 firewall specific. 299 This memo is structured as follows. Section 2 describes the network 300 environment for NATFW NSLP signaling. Section 3 defines the NATFW 301 signaling protocol and Section 4 defines the message components and 302 the overall messages used in the protocol. The remaining parts of 303 the main body of the document, covers security considerations 304 Section 5, IAB considerations on UNilateral Self-Address Fixing 305 (UNSAF) [12] in Section 6 and IANA considerations in Section 7. 306 Please note that readers familiar with firewalls and NATs and their 307 possible location within networks can safely skip Section 2. 309 1.1. Terminology and Abbreviations 311 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 312 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 313 document are to be interpreted as described in [1]. 315 This document uses a number of terms defined in [5] and [4]. The 316 following additional terms are used: 318 o Policy rule: A policy rule is "a basic building block of a policy- 319 based system. It is the binding of a set of actions to a set of 320 conditions - where the conditions are evaluated to determine 321 whether the actions are performed" [16]. In the context of NSIS 322 NATFW NSLP, the conditions are the specification of a set of 323 packets to which the rule is applied. The set of actions always 324 contains just a single element per rule, and is limited to either 325 action "deny" or action "allow". 327 o Reserved policy rule: A policy rule stored at NATs or firewalls 328 for activation by a later, different signaling exchange. This 329 type of policy rule is kept in the NATFW NSLP and is not loaded 330 into the firewall or NAT engine, i.e., it does not affect the data 331 flow handling. 333 o Installed policy rule: A policy rule in operation at NATs or 334 firewalls. This type of rule is kept in the NATFW NSLP and is 335 loaded into the firewall or NAT engine, i.e., it is affecting the 336 data flow. 338 o Remembered policy rule: A policy rule stored at NATs and firewalls 339 for immediate use, as soon as the signaling exchange is 340 successfully completed. 342 o Firewall: A packet filtering device that matches packets against a 343 set of policy rules and applies the actions. In the context of 344 NSIS NATFW NSLP we refer to this device as a firewall. 346 o Network Address Translator: Network Address Translation is a 347 method by which IP addresses are mapped from one IP address realm 348 to another, in an attempt to provide transparent routing between 349 hosts (see [9]). Network Address Translators are devices that 350 perform this work by modifying packets passing through them. 352 o Middlebox: "A middlebox is defined as any intermediate device 353 performing functions other than the normal, standard functions of 354 an IP router on the datagram path between a source host and a 355 destination host" [10]. In the context of this document, the term 356 middlebox refers to firewalls and NATs only. Other types of 357 middlebox are outside of the scope of this document. 359 o Data Receiver (DR): The node in the network that is receiving the 360 data packets of a flow. 362 o Data Sender (DS): The node in the network that is sending the data 363 packets of a flow. 365 o NATFW NSLP peer or peer: An NSIS NATFW NSLP node with which an 366 NSIS adjacency has been created as defined in [2]. 368 o NATFW NSLP signaling session or signaling session: A signaling 369 session defines an association between the NI, NFs, and the NR 370 related to a data flow. All the NATFW NSLP peers on the path, 371 including the NI and the NR, use the same identifier to refer to 372 the state stored for the association. The same NI and NR may have 373 more than one signaling session active at any time. The state for 374 NATFW NSLP consists of NSLP state and associated policy rules at a 375 middlebox. 377 o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP 378 address which is reachable from the public Internet. 380 o Edge-firewall: An edge-firewall is a firewall device that is 381 located on the border line of an administrative domain. 383 o Public Network: "A Global or Public Network is an address realm 384 with unique network addresses assigned by Internet Assigned 385 Numbers Authority (IANA) or an equivalent address registry. This 386 network is also referred as external network during NAT 387 discussions" [9]. 389 o Private/Local Network: "A private network is an address realm 390 independent of external network addresses. Private network may 391 also be referred alternately as Local Network. Transparent 392 routing between hosts in private realm and external realm is 393 facilitated by a NAT router" [9]. 395 o Public/Global IP address: An IP address located in the public 396 network according to Section 2.7 of [9]. 398 o Private/Local IP address: An IP address located in the private 399 network according to Section 2.8 of [9]. 401 o Signaling Destination Address (SDA): An IP address generally taken 402 from the public/global IP address range, although, the SDA may in 403 certain circumstances be part of the private/local IP address 404 range. This address is used in EXT signaling message exchanges, 405 if the data receiver's IP address is unknown. 407 1.2. Middleboxes 409 The term middlebox covers a range of devices which intercept the flow 410 of packets between end hosts and perform actions other than standard 411 forwarding expected in an IP router. As such, middleboxes fall into 412 a number of categories with a wide range of functionality, not all of 413 which is pertinent to the NATFW NSLP. Middlebox categories in the 414 scope of this memo are firewalls that filter data packets against a 415 set of filter rules, and NATs that translate packet addresses from 416 one address realm to another address realm. Other categories of 417 middleboxes, such as QoS traffic shapers, are out of scope of this 418 memo. 420 The term NAT used in this document is a placeholder for a range of 421 different NAT flavors. We consider the following types of NATs: 423 o Traditional NAT (basic NAT and NAPT) 425 o Bi-directional NAT 427 o Twice-NAT 429 o Multihomed NAT 431 For definitions and a detailed discussion about the characteristics 432 of each NAT type please see [9]. 434 All types of middleboxes under consideration here, use policy rules 435 to make a decision on data packet treatment. Policy rules consist of 436 a flow identifier which selects the packets to which the policy 437 applies and an associated action; data packets matching the flow 438 identifier are subjected to the policy rule action. A typical flow 439 identifier is the 5-tuple selector which matches the following fields 440 of a packet to configured values: 442 o Source and destination IP addresses 444 o Transport protocol number 446 o Transport source and destination port numbers 448 Actions for firewalls are usually one or more of: 450 o Allow: forward data packet 452 o Deny: block data packet and discard it 453 o Other actions such as logging, diverting, duplicating, etc 455 Actions for NATs include (amongst many others): 457 o Change source IP address and transport port number to a globally 458 routeable IP address and associated port number. 460 o Change destination IP address and transport port number to a 461 private IP address and associated port number. 463 It should be noted that a middlebox may contain two logical 464 representations of the policy rule. The policy rule has a 465 representation within the NATFW NSLP, comprising the message routing 466 information (MRI) of the NTLP and NSLP information (such as the rule 467 action). The other representation is the implementation of the NATFW 468 NSLP policy rule within the NAT and firewall engine of the particular 469 device. Refer to Appendix C for further details. 471 1.3. General Scenario for NATFW Traversal 473 The purpose of NSIS NATFW signaling is to enable communication 474 between endpoints across networks, even in the presence of NAT and 475 firewall middleboxes that have not been specially engineered to 476 facilitate communication with the application protocols used. This 477 removes the need to create and maintain application layer gateways 478 for specific protocols that have been commonly used to provide 479 transparency in previous generations of NAT and firewall middleboxes. 480 It is assumed that these middleboxes will be statically configured in 481 such a way that NSIS NATFW signaling messages themselves are allowed 482 to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP 483 signaling is used to dynamically install additional policy rules in 484 all NATFW middleboxes along the data path that will allow 485 transmission of the application data flow(s). Firewalls are 486 configured to forward data packets matching the policy rule provided 487 by the NSLP signaling. NATs are configured to translate data packets 488 matching the policy rule provided by the NSLP signaling. An 489 additional capability, that is an exception to the primary goal of 490 NSIS NATFW signaling, is that the NATFW nodes can request blocking of 491 particular data flows instead of enabling these flows at inbound 492 firewalls. 494 The basic high-level picture of NSIS usage is that end hosts are 495 located behind middleboxes, meaning that there is a middlebox on the 496 data path from the end host in a private network and the external 497 network (NATFW in Figure 1). Applications located at these end hosts 498 try to establish communication with corresponding applications on 499 other such end hosts. They trigger the NSIS entity at the local host 500 to control provisioning for middlebox traversal along the prospective 501 data path (e.g., via an API call). The NSIS entity in turn uses NSIS 502 NATFW NSLP signaling to establish policy rules along the data path, 503 allowing the data to travel from the sender to the receiver 504 unobstructed. 506 Application Application Server (0, 1, or more) Application 508 +----+ +----+ +----+ 509 | +------------------------+ +------------------------+ | 510 +-+--+ +----+ +-+--+ 511 | | 512 | NSIS Entities NSIS Entities | 513 +-+--+ +----+ +-----+ +-+--+ 514 | +--------+ +----------------------------+ +-----+ | 515 +-+--+ +-+--+ +--+--+ +-+--+ 516 | | ------ | | 517 | | //// \\\\\ | | 518 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 519 | | | | | Internet | | | | | 520 | +--------+ +-----+ +----+ +-----+ | 521 +----+ +----+ |\ | +----+ +----+ 522 \\\\ ///// 523 sender NATFW (1+) ------ NATFW (1+) receiver 525 Note that 1+ refers to one or more NATFW nodes. 527 Figure 1: Generic View of NSIS with NATs and/or Firewalls 529 For end-to-end NATFW signaling, it is necessary that each firewall 530 and each NAT along the path between the data sender and the data 531 receiver implements the NSIS NATFW NSLP. There might be several NATs 532 and FWs in various possible combinations on a path between two hosts. 533 Section 2 presents a number of likely scenarios with different 534 combinations of NATs and firewalls. 536 2. Network Deployment Scenarios using the NATFW NSLP 538 This section introduces several scenarios for middlebox placement 539 within IP networks. Middleboxes are typically found at various 540 different locations, including at enterprise network borders, within 541 enterprise networks, as mobile phone network gateways, etc. Usually, 542 middleboxes are placed more towards the edge of networks than in 543 network cores. Firewalls and NATs may be found at these locations 544 either alone, or they may be combined; other categories of 545 middleboxes may also be found at such locations, possibly combined 546 with the NATs and/or firewalls. Using combined middleboxes typically 547 reduces the number of network elements needed. 549 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 550 regular data path to the NSIS responder (NR). On the data path, 551 NATFW NSLP signaling messages reach different NSIS nodes that 552 implement the NATFW NSLP. Each NATFW NSLP node processes the 553 signaling messages according to Section 3 and, if necessary, installs 554 policy rules for subsequent data packets. 556 Each of the following sub-sections introduces a different scenario 557 for a different set of middleboxes and their ordering within the 558 topology. It is assumed that each middlebox implements the NSIS 559 NATFW NSLP signaling protocol. 561 2.1. Firewall Traversal 563 This section describes a scenario with firewalls only; NATs are not 564 involved. Each end host is behind a firewall. The firewalls are 565 connected via the public Internet. Figure 2 shows the topology. The 566 part labeled "public" is the Internet connecting both firewalls. 568 +----+ //----\\ +----+ 569 NI -----| FW |---| |------| FW |--- NR 570 +----+ \\----// +----+ 572 private public private 574 FW: Firewall 575 NI: NSIS Initiator 576 NR: NSIS Responder 578 Figure 2: Firewall Traversal Scenario 580 Each firewall on the data path must provide traversal service for 581 NATFW NSLP in order to permit the NSIS message to reach the other end 582 host. All firewalls process NSIS signaling and establish appropriate 583 policy rules, so that the required data packet flow can traverse 584 them. 586 There are several very different ways to place firewalls in a network 587 topology. To distinguish firewalls located at network borders, such 588 as administrative domains, from others located internally, the term 589 edge-firewall is used. A similar distinction can be made for NATs, 590 with an edge-NAT fulfilling the equivalent role. 592 2.2. NAT with two private Networks 594 Figure 3 shows a scenario with NATs at both ends of the network. 595 Therefore, each application instance, the NSIS initiator and the NSIS 596 responder, are behind NATs. The outermost NAT, known as the edge-NAT 597 (MB2 and MB3), at each side is connected to the public Internet. The 598 NATs are generically labeled as MBX (for middlebox No. X), since 599 those devices certainly implement NAT functionality, but can 600 implement firewall functionality as well. 602 Only two middleboxes MB are shown in Figure 3 at each side, but in 603 general, any number of MBs on each side must be considered. 605 +----+ +----+ //----\\ +----+ +----+ 606 NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR 607 +----+ +----+ \\----// +----+ +----+ 609 private public private 611 MB: Middlebox 612 NI: NSIS Initiator 613 NR: NSIS Responder 615 Figure 3: NAT with two Private Networks Scenario 617 Signaling traffic from NI to NR has to traverse all the middleboxes 618 on the path (MB1 to MB4, in this order), and all the middleboxes must 619 be configured properly to allow NSIS signaling to traverse them. The 620 NATFW signaling must configure all middleboxes and consider any 621 address translation that will result from this configuration in 622 further signaling. The sender (NI) has to know the IP address of the 623 receiver (NR) in advance, otherwise it will not be possible to send 624 any NSIS signaling messages towards the responder. Note that this IP 625 address is not the private IP address of the responder but the NAT's 626 public IP address (here MB3's IP address). Instead a NAT binding 627 (including a public IP address) has to be previously installed on the 628 NAT MB3. This NAT binding subsequently allows packets reaching the 629 NAT to be forwarded to the receiver within the private address realm. 630 The receiver might have a number of ways to learn its public IP 631 address and port number (including the NATFW NSLP) and might need to 632 signal this information to the sender using the application level 633 signaling protocol. 635 2.3. NAT with Private Network on Sender Side 637 This scenario shows an application instance at the sending node that 638 is behind one or more NATs (shown as generic MB, see discussion in 639 Section 2.2). The receiver is located in the public Internet. 641 +----+ +----+ //----\\ 642 NI --| MB |-----| MB |---| |--- NR 643 +----+ +----+ \\----// 645 private public 647 MB: Middlebox 648 NI: NSIS Initiator 649 NR: NSIS Responder 651 Figure 4: NAT with Private Network on Sender Side Scenario 653 The traffic from NI to NR has to traverse middleboxes only on the 654 sender's side. The receiver has a public IP address. The NI sends 655 its signaling message directly to the address of the NSIS responder. 656 Middleboxes along the path intercept the signaling messages and 657 configure the policy rules accordingly. 659 The data sender does not necessarily know whether the receiver is 660 behind a NAT or not, hence, it is the receiving side that has to 661 detect whether itself is behind a NAT or not. 663 2.4. NAT with Private Network on Receiver Side Scenario 665 The application instance receiving data is behind one or more NATs 666 shown as MB (see discussion in Section 2.2). 668 //----\\ +----+ +----+ 669 NI ---| |---| MB |-----| MB |--- NR 670 \\----// +----+ +----+ 672 public private 674 MB: Middlebox 675 NI: NSIS Initiator 676 NR: NSIS Responder 678 Figure 5: NAT with Private Network on Receiver Scenario 680 Initially, the NSIS responder must determine its publicly reachable 681 IP address at the external middlebox and notify the NSIS initiator 682 about this address. One possibility is that an application level 683 protocol is used, meaning that the public IP address is signaled via 684 this protocol to the NI. Afterwards the NI can start its signaling 685 towards the NR and therefore establish the path via the middleboxes 686 in the receiver side private network. 688 This scenario describes the use case for the EXTERNAL message of the 689 NATFW NSLP. 691 2.5. Both End Hosts behind twice-NATs 693 This is a special case, where the main problem arises from the need 694 to detect that both end hosts are logically within the same address 695 space, but are also in two partitions of the address realm on either 696 side of a twice-NAT (see [9] for a discussion of twice-NAT 697 functionality). 699 Sender and receiver are both within a single private address realm 700 but the two partitions potentially have overlapping IP address 701 ranges. Figure 6 shows the arrangement of NATs. 703 public 705 +----+ +----+ //----\\ 706 NI --| MB |--+--| MB |---| | 707 +----+ | +----+ \\----// 708 | 709 | +----+ 710 +--| MB |------------ NR 711 +----+ 713 private 715 MB: Middlebox 716 NI: NSIS Initiator 717 NR: NSIS Responder 719 Figure 6: NAT to Public, Sender and Receiver on either side of a 720 twice-NAT Scenario 722 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 723 addresses and port numbers on both sides, meaning the mapping of 724 source and destination address at the private and public interfaces. 726 This scenario requires the assistance of application level entities, 727 such as a DNS server. The application level entities must handle 728 requests that are based on symbolic names, and configure the 729 middleboxes so that data packets are correctly forwarded from NI to 730 NR. The configuration of those middleboxes may require other 731 middlebox communication protocols, such as MIDCOM [7]. NSIS 732 signaling is not required in the twice-NAT only case, since 733 middleboxes of the twice-NAT type are normally configured by other 734 means. Nevertheless, NSIS signaling might be useful when there are 735 also firewalls on the path. In this case NSIS will not configure any 736 policy rule at twice-NATs, but will configure policy rules at the 737 firewalls on the path. The NSIS signaling protocol must be at least 738 robust enough to survive this scenario. This requires that twice- 739 NATs must implement the NATFW NSLP also and participate in NATFW 740 signaling sessions but they do not change the configuration of the 741 NAT, i.e., they only read the address mapping information out of the 742 NAT and translate the Message Routing Information (MRI, [2]) within 743 the NSLP and NTLP accordingly. For more information see Appendix C.4 745 2.6. Both End Hosts Behind Same NAT 747 When NSIS initiator and NSIS responder are behind the same NAT (thus 748 being in the same address realm, see Figure 7), they are most likely 749 not aware of this fact. As in Section 2.4 the NSIS responder must 750 determine its public IP address in advance and transfer it to the 751 NSIS initiator. Afterwards, the NSIS initiator can start sending the 752 signaling messages to the responder's public IP address. During this 753 process, a public IP address will be allocated for the NSIS initiator 754 at the same middlebox as for the responder. Now, the NSIS signaling 755 and the subsequent data packets will traverse the NAT twice: from 756 initiator to public IP address of responder (first time) and from 757 public IP address of responder to responder (second time). 759 NI public 760 \ +----+ //----\\ 761 +-| MB |----| | 762 / +----+ \\----// 763 NR 764 private 766 MB: Middlebox 767 NI: NSIS Initiator 768 NR: NSIS Responder 770 Figure 7: NAT to Public, Both Hosts Behind Same NAT 772 2.7. Multihomed Network with NAT 774 The previous sub-sections sketched network topologies where several 775 NATs and/or firewalls are ordered sequentially on the path. This 776 section describes a multihomed scenario with two NATs placed on 777 alternative paths to the public network. 779 +----+ //---\\ 780 NI -------| MB |---| | 781 \ +----+ \\-+-// 782 \ | 783 \ +----- NR 784 \ | 785 \ +----+ //-+-\\ 786 --| MB |---| | 787 +----+ \\---// 789 private public 791 MB: Middlebox 792 NI: NSIS Initiator 793 NR: NSIS Responder 794 Figure 8: Multihomed Network with Two NATs 796 Depending on the destination, either one or the other middlebox is 797 used for the data flow. Which middlebox is used, depends on local 798 policy or routing decisions. NATFW NSLP must be able to handle this 799 situation properly, see Section 3.7.2 for an extended discussion of 800 this topic with respect to NATs. 802 2.8. Multihomed Network with Firewall 804 This section describes a multihomed scenario with two firewalls 805 placed on alternative paths to the public network (Figure 9). The 806 routing in the private and public network decides which firewall is 807 being taken for data flows. Depending on the data flow's direction, 808 either outbound or inbound, a different firewall could be traversed. 809 This is a challenge for the EXT message of the NATFW NSLP where the 810 NSIS responder is located behind these firewalls within the private 811 network. The EXT message is used to block a particular data flow on 812 an inbound firewall. NSIS must route the EXT message inbound from NR 813 to NI probably without knowing which path the data traffic will take 814 from NI to NR (see also Appendix B). 816 +----+ 817 NR -------| MB |\ 818 \ +----+ \ //---\\ 819 \ -| |-- NI 820 \ \\---// 821 \ +----+ | 822 --| MB |-------+ 823 +----+ 824 private 826 private public 828 MB: Middlebox 829 NI: NSIS Initiator 830 NR: NSIS Responder 832 Figure 9: Multihomed Network with two Firewalls 834 3. Protocol Description 836 This section defines messages, objects, and protocol semantics for 837 the NATFW NSLP. 839 3.1. Policy Rules 841 Policy rules, bound to a NATFW NSLP signaling session, are the 842 building blocks of middlebox devices considered in the NATFW NSLP. 843 For firewalls the policy rule usually consists of a 5-tuple, source/ 844 destination addresses, transport protocol, and source/destination 845 port numbers, plus an action, such as allow or deny. For NATs the 846 policy rule consists of the action 'translate this address' and 847 further mapping information, that might be, in the simplest case, 848 internal IP address and external IP address. 850 The NATFW NSLP carries, in conjunction with the NTLP's Message 851 Routing Information (MRI), the policy rules to be installed at NATFW 852 peers. This policy rule is an abstraction with respect to the real 853 policy rule to be installed at the respective firewall or NAT. It 854 conveys the initiator's request and must be mapped to the possible 855 configuration on the particular used NAT and/or firewall in use. For 856 pure firewalls one or more filter rules must be created and for pure 857 NATs one or more NAT bindings must be created. In mixed firewall and 858 NAT boxes, the policy rule must be mapped to filter rules and 859 bindings observing the ordering of the firewall and NAT engine. 860 Depending on the ordering, NAT before firewall or vice versa, the 861 firewall rules must carry public or private IP addresses. However, 862 the exact mapping depends on the implementation of the firewall or 863 NAT which is different for each vendor. 865 The policy rule at the NATFW NSLP level comprises the message routing 866 information (MRI) part, carried in the NTLP, and the information 867 available in the NATFW NSLP. The information provided by the NSLP is 868 stored in the 'extend flow information' (NATFW_EFI) and 'data 869 terminal information' (NATFW_DTINFO) objects, and the message type. 870 Additional information, such as the external IP address and port 871 number, stored in the NAT or firewall, will be used as well. The MRI 872 carries the filter part of the NAT/firewall-level policy rule that is 873 to be installed. 875 The NATFW NSLP specifies two actions for the policy rules: deny and 876 allow. A policy rule with action set to deny will result in all 877 packets matching this rule to be dropped. A policy rule with action 878 set to allow will result in all packets matching this rule to be 879 forwarded. 881 3.2. Basic Protocol Overview 883 The NSIS NATFW NSLP is carried over the General Internet Signaling 884 Transport (GIST, the implementation of the NTLP) defined in [2]. 885 NATFW NSLP messages are initiated by the NSIS initiator (NI), handled 886 by NSIS forwarders (NF) and received by the NSIS responder (NR). It 887 is required that at least NI and NR implement this NSLP, intermediate 888 NFs only implement this NSLP when they provide relevant middlebox 889 functions. NSIS forwarders that do not have any NATFW NSLP functions 890 just forward these packets as they have no interest in them. 892 A Data Sender (DS), intending to send data to a Data Receiver (DR) 893 has to start NATFW NSLP signaling. This causes the NI associated 894 with the data sender (DS) to launch NSLP signaling towards the 895 address of data receiver (DR) (see Figure 10). Although it is 896 expected that the DS and the NATFW NSLP NI will usually reside on the 897 same host, this specification does not rule out scenarios where the 898 DS and NI reside on different hosts, the so-called proxy mode (see 899 Section 3.7.6.) 901 +-------+ +-------+ +-------+ +-------+ 902 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 903 | |--->| NF1 |--->| NF2 |--->| | 904 +-------+ +-------+ +-------+ +-------+ 906 ========================================> 907 Data Traffic Direction (outbound) 909 ---> : NATFW NSLP request signaling 910 ~~~> : NATFW NSLP response signaling 911 DS/NI : Data sender and NSIS initiator 912 DR/NR : Data receiver and NSIS responder 913 MB1 : Middlebox 1 and NSIS forwarder 1 914 MB2 : Middlebox 2 and NSIS forwarder 2 916 Figure 10: General NSIS signaling 918 The following list shows the normal sequence of NSLP events without 919 detailing the interaction with the NTLP and the interactions on the 920 the NTLP level. 922 o NSIS initiators generate NATFW NSLP CREATE/EXT messages and send 923 these towards the NSIS responder. This CREATE/EXT message is the 924 initial message which creates a new NATFW NSLP signaling session. 925 The NI and the NR will most likely already share an application 926 session before they start the NATFW NSLP signaling session. Note 927 the difference between both sessions. 929 o NSLP CREATE/EXT messages are processed each time a NF with NATFW 930 NSLP support is traversed. Each NF that is intercepting a CREATE/ 931 EXT message and is accepting it for further treatment is joining 932 the particular NATFW NSLP signaling session. These nodes process 933 the message, check local policies for authorization and 934 authentication, possibly create policy rules, and forward the 935 signaling message to the next NSIS node. The request message is 936 forwarded until it reaches the NSIS responder. 938 o NSIS responders will check received messages and process them if 939 applicable. NSIS responders generate RESPONSE messages and send 940 them hop-by-hop back to the NI via the same chain of NFs 941 (traversal of the same NF chain is guaranteed through the 942 established reverse message routing state in the NTLP). The NR is 943 also joining the NATFW NSLP signaling session if the CREATE/EXT 944 message is accepted. 946 o The RESPONSE message is processed at each NF that has been 947 included in the prior NATFW NSLP signaling session setup. 949 o If the NI has received a successful RESPONSE message and if the 950 signaling NATFW NSLP session started with a CREATE message, the 951 data sender can start sending its data flow to the data receiver. 952 If the Ni has received a successful RESPONSE message and if the 953 signaling NATFW NSLP session started with a EXT message, the data 954 receiver is ready to receive further CREATE messages. 956 Because NATFW NSLP signaling follows the data path from DS to DR, 957 this immediately enables communication between both hosts for 958 scenarios with only firewalls on the data path or NATs on the sender 959 side. For scenarios with NATs on the receiver side certain problems 960 arise, as described in Section 2.4. 962 When the NR and the NI are located in different address realms and 963 the NR is located behind a NAT, the NI cannot signal to the NR 964 address directly. The DR/NR are not reachable from the NIs using the 965 private address of the NR and thus NATFW signaling messages cannot be 966 sent to the NR/DR's address. Therefore, the NR must first obtain a 967 NAT binding that provides an address that is reachable for the NI. 968 Once the NR has acquired a public IP address, it forwards this 969 information to the DS via a separate protocol. This application 970 layer signaling, which is out of scope of the NATFW NSLP, may involve 971 third parties that assist in exchanging these messages. 973 The same holds partially true for NRs located behind firewalls that 974 block all traffic by default. In this case, NR must tell its inbound 975 firewalls of inbound NATFW NSLP signaling and corresponding data 976 traffic. Once the NR has informed the inbound firewalls, it can 977 start its application level signaling to initiate communication with 978 the NI. This application layer signaling, which is out of scope of 979 the NATFW NSLP, may involve third parties that assist in exchanging 980 these messages. This mechanism can be used by machines hosting 981 services behind firewalls as well. In this case, the NR informs the 982 inbound firewalls as described, but does not need to communicate this 983 to the NIs. 985 NATFW NSLP signaling supports this scenario by using the EXT message 987 1. The DR acquires a public address by signaling on the reverse path 988 (DR towards DS) and thus making itself available to other hosts. 989 This process of acquiring public addresses is called reservation. 990 During this process the DR reserves publicly reachable addresses 991 and ports suitable for further usage in application level 992 signaling and the publicly reachable address for further NATFW 993 NSLP signaling. However, the data traffic will not be allowed to 994 use this address/port initially (see next point). In the process 995 of reservation the DR becomes the NI for the messages necessary 996 to obtain the publicly reachable IP address, i.e., the NI for 997 this specific NATFW NSLP signaling session. 999 2. Now on the side of DS, the NI creates a new NATFW NSLP signaling 1000 session and signals directly to the public IP address of DR. 1001 This public IP address is used as NR's address, as the NI would 1002 do if there is no NAT in between, and creates policy rules at 1003 middleboxes. Note, that the reservation will only allow 1004 forwarding of signaling messages, but not data flow packets. 1005 Policy rules allowing forwarding of data flow packets set up by 1006 the prior EXT message signaling will be activated when the 1007 signaling from NI towards NR is confirmed with a positive 1008 RESPONSE message. The EXTERNAL (EXT) message is described 1009 inSection 3.7.2. 1011 +-------+ +-------+ +-------+ +-------+ 1012 | DS/NI |<~~~| MB1/ |<~~~| NR | | DR | 1013 | |--->| NF1 |--->| | | | 1014 +-------+ +-------+ +-------+ +-------+ 1016 ========================================> 1017 Data Traffic Direction (outbound) 1019 ---> : NATFW NSLP request signaling 1020 ~~~> : NATFW NSLP response signaling 1021 DS/NI : Data sender and NSIS initiator 1022 DR/NR : Data receiver and NSIS responder 1023 MB1 : Middlebox 1 and NSIS forwarder 1 1024 MB2 : Middlebox 2 and NSIS forwarder 2 1026 Figure 11: A NSIS proxy mode signaling 1028 The above usage assumes that both ends of a communication support 1029 NSIS, but fails when NSIS is only deployed at one end of the path. 1030 In this case only one of the receiving or sending side is NSIS aware 1031 and not both at the same time. NATFW NSLP supports this scenario 1032 (i.e., the DR does not support NSIS) by using a proxy mode, as 1033 described in Section 3.7.6; the proxy mode operation also supports 1034 scenarios with a data sender that does not support NSIS, i.e. the 1035 data receiver must act to enable data flows towards itself. 1037 The basic functionality of the NATFW NSLP provides for opening 1038 firewall pin holes and creating NAT bindings to enable data flows to 1039 traverse these devices. Firewalls are normally expected to work on a 1040 'deny-all' policy, meaning that traffic not explicitly matching any 1041 firewall filter rule will be blocked. Similarly, the normal behavior 1042 of NATs is to block all traffic that does not match any already 1043 configured/installed binding or NATFW NSLP session. However, some 1044 scenarios require support of firewalls having 'allow-all' policies, 1045 allowing data traffic to traverse the firewall unless it is blocked 1046 explicitly. Data receivers can utilize NATFW NSLP's EXT message with 1047 action set to 'deny' to install policy rules at inbound firewalls to 1048 block unwanted traffic. 1050 The protocol works on a soft-state basis, meaning that whatever state 1051 is installed or reserved on a middlebox will expire, and thus be de- 1052 installed or forgotten after a certain period of time. To prevent 1053 premature removal of state that is needed for ongoing communication, 1054 the NATFW NI involved will have to specifically request a NATFW NSLP 1055 signaling session extension. An explicit NATFW NSLP state deletion 1056 capability is also provided by the protocol. 1058 If the actions requested by a NATFW NSLP message cannot be carried 1059 out, NFs and the NR must return a failure, such that appropriate 1060 actions can be taken. They can do this either during a the request 1061 message handling (synchronously) by sending an error RESPONSE 1062 message, or at any time (asynchronously) by sending a notification 1063 message. 1065 The next sections define the NATFW NSLP message types and formats, 1066 protocol operations, and policy rule operations. 1068 3.2.1. Message Types 1070 The protocol uses four messages types: 1072 o CREATE: a request message used for creating, changing, refreshing, 1073 and deleting NATFW NSLP signaling sessions, i.e., open the data 1074 path from DS to DR. 1076 o EXTERNAL (EXT): a request message used for reserving, changing, 1077 refreshing, and deleting EXT NATFW NSLP signaling sessions. EXT 1078 messages are forwarded to the edge-NAT or edge-firewall and allow 1079 inbound CREATE messages to be forwarded to the NR. Additionally, 1080 EXT messages reserve an external address and, if applicable, port 1081 number at an edge-NAT. 1083 o NOTIFY: an asynchronous message used by NATFW peers to alert 1084 inbound NATFW peers about specific events (especially failures). 1086 o RESPONSE: used as a response to CREATE and EXT request messages. 1088 3.2.2. Classification of RESPONSE Messages 1090 RESPONSE messages will be generated synchronously to CREATE and EXT 1091 messages by NSIS Forwarders and Responders to report success or 1092 failure of operations or some information relating to the NATFW NSLP 1093 signaling session or a node. RESPONSE messages MUST NOT be generated 1094 for any other message, such as NOTIFY and RESPONSE. 1096 All RESPONSE messages MUST carry a NATFW_INFO object which contains a 1097 severity class code and a response code (see Section 4.2.4). This 1098 section defines terms for groups of RESPONSE messages depending on 1099 the severity class. 1101 o Successful RESPONSE: Messages carrying NATFW_INFO with severity 1102 class 'Success' (0x2). 1104 o Informational RESPONSE: Messages carrying NATFW_INFO with severity 1105 class 'Informational' (0x1) (only used with NOTIFY messages). 1107 o Error RESPONSE: Messages carrying NATFW_INFO with severity class 1108 other than 'Success' or 'Informational'. 1110 3.2.3. NATFW NSLP Signaling Sessions 1112 A NATFW NSLP signaling session defines an association between the NI, 1113 NFs, and the NR related to a data flow. This association is created 1114 when the initial CREATE or EXT message is successfully received at 1115 the NFs or the NR. There is signaling NATFW NSLP session state 1116 stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP 1117 signaling session state for the NATFW NSLP comprises NSLP state and 1118 the associated policy rules at a middlebox. 1120 The NATFW NSLP signaling session is identified by the session ID 1121 (plus other information at the NTLP level). The session ID is 1122 generated by the NI before the initial CREATE or EXT message is sent. 1123 The value of the session ID MUST generated in a random way, i.e., the 1124 output MUST NOT be easily guessable by third parties. The session ID 1125 is not stored in any NATFW NSLP message but passed on to the NTLP. 1127 A NATFW NSLP signaling session can conceptually be in different 1128 states, implementations may use other or even more states. The 1129 signaling session can have these states at a node: 1131 o Pending: The NATFW NSLP signaling session has been created and the 1132 node is waiting for a RESPONSE message to the CREATE or EXT 1133 message. A NATFW NSLP signaling session in state 'Pending' MUST 1134 be marked as 'Dead' if no corresponding RESPONSE message has been 1135 received within the time of the locally granted NATFW NSLP 1136 signaling session lifetime of the forwarded CREATE or EXT message 1137 (as described in Section 3.4). 1139 o Established: The NATFW NSLP signaling session is established, i.e, 1140 the signaling has been successfully performed and the lifetime of 1141 NATFW NSLP signaling session is counted from now on. A NATFW NSLP 1142 signaling session in state 'Established' MUST be marked as 'Dead' 1143 if no refresh message has been received within the time of the 1144 locally granted NATFW NSLP signaling session lifetime of the 1145 RESPONSE message (as described in Section 3.4). 1147 o Dead: Either the NATFW NSLP signaling session is timed out or the 1148 node has received an error RESPONSE message for the NATFW NSLP 1149 signaling session and the NATFW NSLP signaling session can be 1150 deleted. 1152 o Transit: The node has received an asynchronous message, i.e., a 1153 NOTIFY, and can delete the NATFW NSLP signaling session if needed. 1154 When a node has received a NOTIFY message (for instance, 1155 indicating a route change) it marks it as 'Transit' and deletes 1156 this NATFW NSLP signaling session if it is unused for some time 1157 specific to the local node. This idle time does not need to be 1158 fixed, since it can depend on the node local maintenance cycle, 1159 i.e., the NATFW NSLP signaling session could be deleted if the 1160 node runs it garbage collection cycle. 1162 3.3. Basic Message Processing 1164 All NATFW messages are subject to some basic message processing when 1165 received at a node, independent of message type. Initially, the 1166 syntax of the NSLP message is checked and a RESPONSE message with an 1167 appropriate error of class 'Protocol error' (0x1) code is generated 1168 if any problem is detected. If a message is delivered to the NATFW 1169 NSLP, this implies that the NTLP layer has been able to correlate it 1170 with the SID and MRI entries in its database. There is therefore 1171 enough information to identify the source of the message and routing 1172 information to route the message back to the NI through an 1173 established chain of NTLP messaging associations. The message is not 1174 further forwarded if any error in the syntax is detected. The 1175 specific response codes stemming from the processing of objects are 1176 described in the respective object definition section (see 1177 Section 4). After passing this check, the NATFW NSLP node performs 1178 authentication/authorization related checks described in Section 3.6. 1179 Further processing is executed only if these tests have been 1180 successfully passed, otherwise the processing stops and an error 1181 RESPONSE is returned. 1183 Further message processing stops whenever an error RESPONSE message 1184 is generated, and the EXT or CREATE message is discarded. 1186 3.4. Calculation of Signaling Session Lifetime 1188 NATFW NSLP signaling sessions, and the corresponding policy rules 1189 which may have been installed, are maintained via a soft-state 1190 mechanism. Each signaling session is assigned a signaling session 1191 lifetime and the signaling session is kept alive as long as the 1192 lifetime is valid. After the expiration of the signaling session 1193 lifetime, signaling sessions and policy rules MUST be removed 1194 automatically and resources bound to them MUST be freed as well. 1195 Signaling session lifetime is handled at every NATFW NSLP node. The 1196 NSLP forwarders and NSLP responder MUST NOT trigger signaling session 1197 lifetime extension refresh messages (see Section 3.7.3): this is the 1198 task of the NSIS initiator. 1200 The NSIS initiator MUST choose a NATFW NSLP signaling session 1201 lifetime value (expressed in seconds) before sending any message, 1202 including the initial message which creates the NATFW NSLP signaling 1203 session, to other NSLP nodes. The NATFW NSLP signaling session 1204 lifetime value is calculated based on: 1206 o the number of lost refresh messages that NFs should cope with; 1208 o the end-to-end delay between the NI and NR; 1210 o network vulnerability due to NATFW NSLP signaling session 1211 hijacking ([8]), NATFW NSLP signaling session hijacking is made 1212 easier when the NI does not explicitly remove the NATFW NSLP 1213 signaling session); 1215 o the user application's data exchange duration, in terms of time 1216 and networking needs. This duration is modeled as M x R, with R 1217 the message refresh period (in seconds) and M as a multiplier for 1218 R; 1220 o the load on the signalling plane. Short lifetimes imply more 1221 frequent signaling messages. 1223 o the acceptable time for a NATFW NSLP signaling session to be 1224 present after it is no longer actually needed. For example, if 1225 the existence of the NATFW NSLP signaling session implies a 1226 monetary cost and teardown cannot be guaranteed, shorter lifetimes 1227 would be preferable. 1229 o the lease time of the NI's IP address. The chosen NATFW NSLP 1230 signaling session lifetime must be larger than the lease time, 1231 otherwise the IP address can be re-assigned to a different node. 1232 This node may receive unwanted traffic, although it never has 1233 requested a NAT/firewall configuration, which might be an issue in 1234 mobile environments. 1236 The RSVP specification [11] provides an appropriate algorithm for 1237 calculating the NATFW NSLP signaling session lifetime as well as 1238 means to avoid refresh message synchronization between NATFW NSLP 1239 signaling sessions. [11] recommends: 1241 1. The refresh message timer to be randomly set to a value in the 1242 range [0.5R, 1.5R]. 1244 2. To avoid premature loss of state, lt (with lt being the NATFW 1245 NSLP signaling session lifetime) must satisfy lt >= (K + 1246 0.5)*1.5*R, where K is a small integer. Then in the worst case, 1247 K-1 successive messages may be lost without state being deleted. 1248 Currently K = 3 is suggested as the default. However, it may be 1249 necessary to set a larger K value for hops with high loss rate. 1250 Other algorithms could be used to define the relation between the 1251 NATFW NSLP signaling session lifetime and the refresh message 1252 period; the algorithm provided is only given as an example. 1254 This requested NATFW NSLP signaling session lifetime value lt is 1255 stored in the NATFW_LT object of the NSLP message. 1257 NSLP forwarders can execute the following behavior with respect to 1258 the lifetime handling: 1260 Requested signaling session lifetime acceptable: 1262 No changes to the NATFW NSLP signaling session lifetime values are 1263 needed. The CREATE or EXT message is forwarded. 1265 Signaling session lifetime can be lowered: 1267 The NSLP responder MAY also lower the requested NATFW NSLP 1268 signaling session lifetime to an acceptable value (based on its 1269 local policies). If an NF changes the NATFW NSLP signaling 1270 session lifetime value, it MUST store the new value in the 1271 NATFW_LT object. The CREATE or EXT message is forwarded. 1273 Requested signaling session lifetime is too big: 1275 The NSLP responder MAY reject the requested NATFW NSLP signaling 1276 session lifetime value as being too big and MUST generate an error 1277 RESPONSE message of class 'Signaling session failures' (0x6) with 1278 response code 'Requested lifetime is too big' (0x02) upon 1279 rejection. Lowering the lifetime is preferred instead of 1280 generating an error message. 1282 Requested signaling session lifetime is too small: 1284 The NSLP responder MAY reject the requested NATFW NSLP signaling 1285 session lifetime value as being to small and MUST generate an 1286 error RESPONSE message of class 'Signaling session failures' (0x6) 1287 with response code 'Requested lifetime is too small' (0x10) upon 1288 rejection. 1290 NFs MUST NOT increase the NATFW NSLP signaling session lifetime 1291 value. Messages can be rejected on the basis of the NATFW NSLP 1292 signaling session lifetime being too long when a NATFW NSLP signaling 1293 session is first created and also on refreshes. 1295 The NSLP responder generates a successful RESPONSE for the received 1296 CREATE or EXT message, sets the NATFW NSLP signaling session lifetime 1297 value in the NATFW_LT object to the above granted lifetime and sends 1298 the message back towards NSLP initiator. 1300 Each NSLP forwarder processes the RESPONSE message, reads and stores 1301 the granted NATFW NSLP signaling session lifetime value. The 1302 forwarders MUST accept the granted NATFW NSLP signaling session 1303 lifetime, as long as this value is less than or equal to the 1304 acceptable value. The acceptable value refers to the value accepted 1305 by the NSLP forwarder when processing the CREATE or EXT message. For 1306 received values greater than the acceptable value, NSLP forwarders 1307 MUST generate a RESPONSE message of class 'Signaling session 1308 failures' (0x6) with response code 'Requested lifetime is too big' 1309 (0x02). For received values lower than the values acceptable by the 1310 node local policy, NSLP forwarders MUST generate a RESPONSE message 1311 of class 'Signaling session failures' (0x6) with response code 1312 'Requested lifetime is too small' (0x10). Figure 12 shows the 1313 procedure with an example, where an initiator requests 60 seconds 1314 lifetime in the CREATE message and the lifetime is shortened along 1315 the path by the forwarder to 20 seconds and by the responder to 15 1316 seconds. When the NSLP forwarder receives the RESPONSE message with 1317 a NATFW NSLP signaling session lifetime value of 15 seconds it checks 1318 whether this value is lower or equal to the acceptable value. 1320 +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ 1321 | |---------------->| NSLP |---------------->| | 1322 | NI | | forwarder | | NR | 1323 | |<----------------| check 15<20 |<----------------| | 1324 +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ 1326 lt = lifetime 1328 Figure 12: Signaling Session Lifetime Setting Example 1330 3.5. Message Sequencing 1332 NATFW NSLP messages need to carry an identifier so that all nodes 1333 along the path can distinguish messages sent at different points in 1334 time. Messages can be lost along the path or duplicated. So all 1335 NATFW NSLP nodes should be able to identify either old messages that 1336 have been received before (duplicated), or the case that messages 1337 have been lost before (loss). For message replay protection it is 1338 necessary to keep information about messages that have already been 1339 received and requires every NATFW NSLP message to carry a message 1340 sequence number (MSN), see also Section 4.2.6. 1342 The MSN MUST be set by the NI and MUST NOT be set or modified by any 1343 other node. The initial value for the MSN MUST be generated randomly 1344 and MUST be unique only within the NATFW NSLP signaling session for 1345 which it is used. The NI MUST increment the MSN by one for every 1346 message sent. Once the MSN has reached the maximum value, the next 1347 value it takes is zero. All NATFW NSLP nodes MUST use the algorithm 1348 defined in [3] to detect MSN wrap-arounds. 1350 NSIS forwarders and the responder store the MSN from the initial 1351 CREATE or EXT packet which creates the NATFW NSLP signaling session 1352 as the start value for the NATFW NSLP signaling session. NFs and NRs 1353 MUST include the received MSN value in the corresponding RESPONSE 1354 message that they generate. 1356 When receiving a CREATE or EXT message, a NATFW NSLP node uses the 1357 MSN given in the message to determine whether the state being 1358 requested is different to the state already installed. The message 1359 MUST be discarded if the received MSN value is equal to or lower than 1360 the stored MSN value. Such a received MSN value can indicate a 1361 duplicated and delayed message or replayed message. If the received 1362 MSN value is greater than the already stored MSN value, the NATFW 1363 NSLP MUST update its stored state accordingly, if permitted by all 1364 security checks (see Section 3.6), and stores the updated MSN value 1365 accordingly. 1367 3.6. Authentication, Authorization, and Policy Decisions 1369 NATFW NSLP nodes receiving signaling messages MUST first check 1370 whether this message is authenticated and authorized to perform the 1371 requested action. NATFW NSLP nodes requiring more information than 1372 provided MUST generate an error RESPONSE of class 'Permanent failure' 1373 (0x5) with response code 'Authentication failed' (0x01) or with 1374 response code 'Authorization failed' (0x02). 1376 The NATFW NSLP is expected to run in various environments, such as 1377 IP-based telephone systems, enterprise networks, home networks, etc. 1378 The requirements on authentication and authorization are quite 1379 different between these use cases. While a home gateway, or an 1380 Internet cafe, using NSIS may well be happy with a "NATFW signaling 1381 coming from inside the network" policy for authorization of 1382 signaling, enterprise networks are likely to require more strongly 1383 authenticated/authorized signaling. This enterprise scenario may 1384 require the use of an infrastructure and administratively assigned 1385 identities to operate the NATFW NSLP. 1387 Once the NI is authenticated and authorized, another step is 1388 performed. The requested policy rule for the NATFW NSLP signaling 1389 session is checked against a set of policy rules, i.e., whether the 1390 requesting NI is allowed to request the policy rule to be loaded in 1391 the device. If this fails the NF or NR must send an error RESPONSE 1392 of class 'Permanent failure' (0x5) and with response code 1393 'Authorization failed' (0x02). 1395 3.7. Protocol Operations 1397 This section defines the protocol operations including, how to create 1398 NATFW NSLP signaling sessions, maintain them, and how to reserve 1399 addresses. 1401 3.7.1. Creating Signaling Sessions 1403 Allowing two hosts to exchange data even in the presence of 1404 middleboxes is realized in the NATFW NSLP by use of the CREATE 1405 message. The NI (either the data sender or a proxy) generates a 1406 CREATE message as defined in Section 4.3.1 and hands it to the NTLP. 1407 The NTLP forwards the whole message on the basis of the message 1408 routing information (MRI) towards the NR. Each NSIS forwarder along 1409 the path that implements NATFW NSLP, processes the NSLP message. 1410 Forwarding is thus managed NSLP hop-by-hop but may pass transparently 1411 through NSIS forwarders which do not contain NATFW NSLP functionality 1412 and non-NSIS aware routers between NSLP hop way points. When the 1413 message reaches the NR, the NR can accept the request or reject it. 1414 The NR generates a response to CREATE and this response is 1415 transported hop-by-hop towards the NI. NATFW NSLP forwarders may 1416 reject requests at any time. Figure 13 sketches the message flow 1417 between NI (DS in this example), a NF (e.g., NAT), and NR (DR in this 1418 example). 1420 NI Private Network NF Public Internet NR 1421 | | | 1422 | CREATE | | 1423 |----------------------------->| | 1424 | | | 1425 | | | 1426 | | CREATE | 1427 | |--------------------------->| 1428 | | | 1429 | | RESPONSE | 1430 | RESPONSE |<---------------------------| 1431 |<-----------------------------| | 1432 | | | 1433 | | | 1435 Figure 13: CREATE message flow with success RESPONSE 1437 There are several processing rules for a NATFW peer when generating 1438 and receiving CREATE messages, since this message type is used for 1439 creating new NATFW NSLP signaling session, updating existing, 1440 extending the lifetime and deleting NATFW NSLP signaling session. 1441 The three latter functions operate in the same way for all kinds of 1442 CREATE message, and are therefore described in separate sections: 1444 o Extending the lifetime of NATFW NSLP signaling sessions is 1445 described in Section 3.7.3. 1447 o Deleting NATFW NSLP signaling sessions is described in 1448 Section 3.7.4. 1450 o Updating policy rules is described in Section 3.10. 1452 For an initial CREATE message creating a new NATFW NSLP signaling 1453 session, the processing of CREATE messages is different for every 1454 NATFW node type: 1456 o NSLP initiator: An NI only generates CREATE messages and hands 1457 them over to the NTLP. The NI should never receive CREATE 1458 messages and MUST discard it. 1460 o NATFW NSLP forwarder: NFs that are unable to forward the CREATE 1461 message to the next hop MUST generate an error RESPONSE of class 1462 'Permanent failure' (0x6) with response code 'Did not reach the 1463 NR' (0x07). This case may occur if the NTLP layer cannot find an 1464 NATFW NSLP peer, either another NF or the NR, and returns an error 1465 via the GIST API. The NSLP message processing at the NFs depends 1466 on the middlebox type: 1468 * NAT: When the initial CREATE message is received at the public 1469 side of the NAT, it looks for a reservation made in advance, by 1470 using a EXT message (see Section 3.7.2). The matching process 1471 considers the received MRI information and the stored MRI 1472 information, as described in Section 3.8. If no matching 1473 reservation can be found, i.e. no reservation has been made in 1474 advance, the NSLP MUST return an error RESPONSE of class 1475 'Signaling session failure' (0x6) with response code 'No 1476 reservation found matching the MRI of the CREATE request' 1477 (0x03) MUST be generated. If there is a matching reservation, 1478 the NSLP stores the data sender's address (and if applicable 1479 port number) as part of the source address of the policy rule 1480 ('the remembered policy rule') to be loaded and forwards the 1481 message with the destination address set to the internal 1482 (private in most cases) address of NR. When the initial CREATE 1483 message is received at the private side, the NAT binding is 1484 allocated, but not activated (see also Appendix C.3). The MRI 1485 information is updated to reflect the address, and if 1486 applicable port, translation. The NSLP message is forwarded 1487 towards the NR with source address set to the NAT's external 1488 address from the newly remembered binding. 1490 * Firewall: When the initial CREATE message is received, the NSLP 1491 just remembers the requested policy rule, but does not install 1492 any policy rule. Afterwards, the message is forwarded towards 1493 the NR. 1495 * Combined NAT and firewall: Processing at combined firewall and 1496 NAT middleboxes is the same as in the NAT case. No policy 1497 rules are installed. Implementations MUST take into account 1498 the order of packet processing in the firewall and NAT 1499 functions within the device. This will be referred to as 1500 'order of functions' and is generally different depending on 1501 whether the packet arrives at the external or internal side of 1502 the middlebox. 1504 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1505 with a success RESPONSE of class 'Success' (0x2) with response 1506 code set to 'All successfully processed' (0x01), if they accept 1507 the CREATE message. Otherwise they MUST generate a RESPONSE 1508 message with a suitable response code. RESPONSE messages are sent 1509 back NSLP hop-by-hop towards the NI, irrespective of the response 1510 codes, either success or error. 1512 Remembered policy rules at middleboxes MUST be only installed upon 1513 receiving a corresponding successful RESPONSE message with the same 1514 SID and MSN as the CREATE message that caused them to be remembered. 1515 This is a countermeasure to several problems, for example, wastage of 1516 resources due to loading policy rules at intermediate NFs when the 1517 CREATE message does not reach the final NR for some reason. 1519 Processing of a RESPONSE message is different for every NSIS node 1520 type: 1522 o NSLP initiator: After receiving a successful RESPONSE, the data 1523 path is configured and the DS can start sending its data to the 1524 DR. After receiving an error RESPONSE message, the NI MAY try to 1525 generate the CREATE message again or give up and report the 1526 failure to the application, depending on the error condition. 1528 o NSLP forwarder: NFs install the remembered policy rules, if a 1529 successful RESPONSE message with matching SID and MSN is received. 1530 If an ERROR RESPONSE message with matching SID and MSN is 1531 received, the NATFW NSLP session is marked as dead, no policy rule 1532 is installed and the remembered rule is discarded. 1534 o NSIS responder: The NR should never receive RESPONSE messages and 1535 MUST silently drop any such messages received. 1537 3.7.2. Reserving External Addresses 1539 NSIS signaling is intended to travel end-to-end, even in the presence 1540 of NATs and firewalls on-path. This works well in cases where the 1541 data sender is itself behind a NAT or a firewall as described in 1542 Section 3.7.1. For scenarios where the data receiver is located 1543 behind a NAT or a firewall and it needs to receive data flows from 1544 outside its own network (usually referred to as inbound flows, see 1545 Figure 5) the problem is more troublesome. 1547 NSIS signaling, as well as subsequent data flows, are directed to a 1548 particular destination IP address that must be known in advance and 1549 reachable. Data receivers must tell the local NSIS infrastructure 1550 (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP 1551 signaling and data flows before they can receive these flows. It is 1552 necessary to differentiate between data receivers behind NATs and 1553 behind firewalls for understanding the further NATFW procedures. 1554 Data receivers that are only behind firewalls already have a public 1555 IP address and they need only to be reachable for NATFW signaling. 1556 Unlike data receivers behind just firewalls, data receivers behind 1557 NATs do not have public IP addresses; consequently they are not 1558 reachable for NATFW signaling by entities outside their addressing 1559 realm. 1561 The preceding discussion addresses the situation where a DR node that 1562 wants to be reachable is unreachable because the NAT lacks a suitable 1563 rule with the 'allow' action which would forward inbound data. 1564 However, in certain scenarios, a node situated behind inbound 1565 firewalls that do not block inbound data traffic (firewalls with 1566 "default to allow") unless requested might wish to prevent traffic 1567 being sent to it from specified addresses. In this case, NSIS NATFW 1568 signaling can be used to achieve this by installing a policy rule 1569 with its action set to 'deny' using the same mechanisms as for 1570 'allow' rules. 1572 The required result is obtained by sending a EXTERNAL (EXT) message 1573 in the inbound direction of the intended data flow. When using this 1574 functionality the NSIS initiator for the 'Reserve External Address' 1575 signaling is typically the node that will become the DR for the 1576 eventual data flow. To distinguish this initiator from the usual 1577 case where the NI is associated with the DS, the NI is denoted by NI+ 1578 and the NSIS responder is similarly denoted by NR+. 1580 Public Internet Private Address 1581 Space 1583 Edge 1584 NI(DS) NAT/FW NAT NR(DR) 1585 NR+ NI+ 1587 | | | | 1588 | | | | 1589 | | | | 1590 | | EXT[(DTInfo)] | EXT[(DTInfo)] | 1591 | |<----------------------|<----------------------| 1592 | | | | 1593 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1594 | |---------------------->|---------------------->| 1595 | | | | 1596 | | | | 1598 ============================================================> 1599 Data Traffic Direction 1601 Figure 14: Reservation message flow for DR behind NAT or firewall 1603 Figure 14 shows the EXT message flow for enabling inbound NATFW NSLP 1604 signaling messages. In this case the roles of the different NSIS 1605 entities are: 1607 o The data receiver (DR) for the anticipated data traffic is the 1608 NSIS initiator (NI+) for the EXTERNAL (EXT) message, but becomes 1609 the NSIS responder (NR) for following CREATE messages. 1611 o The actual data sender (DS) will be the NSIS initiator (NI) for 1612 later CREATE messages and may be the NSIS target of the signaling 1613 (NR+). 1615 o It may be necessary to use a signaling destination address (SDA) 1616 as the actual target of the EXT message (NR+) if the DR is located 1617 behind a NAT and the address of the DS is unknown. The SDA is an 1618 arbitrary address in the outermost address realm on the other side 1619 of the NAT from the DR. Typically this will be a suitable public 1620 IP address when the 'outside' realm is the public Internet. This 1621 choice of address causes the EXT message to be routed through the 1622 NATs towards the outermost realm and would force interception of 1623 the message by the outermost NAT in the network at the boundary 1624 between the private address and the public address realm (the 1625 edge-NAT). It may also be intercepted by other NATs and firewalls 1626 on the path to the edge-NAT. 1628 Basically, there are two different signaling scenarios. Either 1630 1. the DR behind the NAT/firewall knows the IP address of the DS in 1631 advance, 1633 2. or the address of DS is not known in advance. 1635 Case 1 requires the NATFW NSLP to request the path-coupled message 1636 routing method (PC-MRM) from the NTLP. The EXT message MUST be sent 1637 with PC-MRM (see Section 5.8.1 in [2]) with the direction set to 1638 'upstream' (inbound). The handling of case 2 depends on the 1639 situation of DR: If DR is solely located behind a firewall, the EXT 1640 message MUST be sent with the PC-MRM, direction 'upstream' (inbound), 1641 and data flow source IP address set to wildcard. If DR is located 1642 behind a NAT, the EXT message MUST be sent with the loose-end message 1643 routing method (LE-MRM, see Section 5.8.2 in [2]), the destination- 1644 address set to the signaling destination address (SDA, see also 1645 Appendix A). For scenarios with DR being behind a firewall, special 1646 conditions apply (applicability statement, Appendix B). The data 1647 receiver is challenged to determine whether it is solely located 1648 behind firewalls or NATs, for choosing the right message routing 1649 method. This decision can depend on a local configuration parameter, 1650 possibly given through DHCP, or it could be discovered through other 1651 non-NSLP related testing of the network configuration. 1653 For case 2 with NAT, the NI+ (which could be on the data receiver DR 1654 or on any other host within the private network) sends the EXT 1655 message targeted to the signaling destination address. The message 1656 routing for the EXT message is in the reverse direction to the normal 1657 message routing used for path-coupled signaling where the signaling 1658 is sent outbound (as opposed to inbound in this case). When 1659 establishing NAT bindings (and an NATFW NSLP signaling session) the 1660 signaling direction does not matter since the data path is modified 1661 through route pinning due to the external IP address at the NAT. 1662 Subsequent NSIS messages (and also data traffic) will travel through 1663 the same NAT boxes. However, this is only valid for the NAT boxes, 1664 but not for any intermediate firewall. That is the reason for having 1665 a separate CREATE message enabling the reservations made with EXT at 1666 the NATs and either enabling prior reservations or creating new 1667 pinholes at the firewalls which are encountered on the outbound path 1668 depending on whether the inbound and outbound routes coincide. 1670 The EXT signaling message creates an NSIS NATFW signaling session at 1671 any intermediate NSIS NATFW peer(s) encountered, independent of the 1672 message routing method used. Furthermore, it has to be ensured that 1673 the edge-NAT or edge-firewall device is discovered as part of this 1674 process. The end host cannot be assumed to know this device - 1675 instead the NAT or firewall box itself is assumed to know that it is 1676 located at the outer perimeter of the network. Forwarding of the EXT 1677 message beyond this entity is not necessary, and MUST be prohibited 1678 as it may provide information on the capabilities of internal hosts. 1679 It should be noted, that it is the outermost NAT or firewall that is 1680 the edge-device that must be found during this discovery process. 1681 For instance, when there are a NAT and afterwards a firewall on the 1682 outbound path at the network border, the firewall is the edge- 1683 firewall. All messages must be forwarded to the topology-wise 1684 outermost edge-device, to ensure that this devices knows about the 1685 NATFW NSLP signaling sessions for incoming CREATE messages. However, 1686 the NAT is still the edge-NAT because it has a public globally 1687 routable IP address on its public side: this is not affected by any 1688 firewall between the edge-NAT and the public network. 1690 Possible edge arrangements are: 1692 Public Net ----------------- Private net -------------- 1694 | Public Net|--|Edge-FW|--|FW|...|FW|--|DR| 1696 | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR| 1698 | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR| 1700 The edge-NAT or edge-firewall device closest to the public realm 1701 responds to the EXT message with a successful RESPONSE message. An 1702 edge-NAT includes an NATFW_EXT_IP object (see Section 4.2.2), 1703 carrying the public reachable IP address, and if applicable port 1704 number. 1706 There are several processing rules for a NATFW peer when generating 1707 and receiving EXT messages, since this message type is used for 1708 creating new reserve NATFW NSLP signaling sessions, updating 1709 existing, extending the lifetime and deleting NATFW NSLP signaling 1710 session. The three latter functions operate in the same way for all 1711 kinds of CREATE and EXT messages, and are therefore described in 1712 separate sections: 1714 o Extending the lifetime of NATFW NSLP signaling sessions is 1715 described in Section 3.7.3. 1717 o Deleting NATFW NSLP signaling sessions is described in 1718 Section 3.7.4. 1720 o Updating policy rules is described in Section 3.10. 1722 The NI+ MUST include a NATFW_DTINFO object in the EXT message when 1723 using the LE-MRM. The LE-MRM does not include enough information for 1724 some types of NATs (basically, those NATs which also translate port 1725 numbers) to perform the address translation. This information is 1726 provided in the NATFW_DTINFO (see Section 4.2.7). This information 1727 MUST include at least the 'dst port number' and 'protocol' fields, in 1728 the NATFW_DTINFO object as these may be required by en-route NATs, 1729 depending on the type of the NAT. All other fields MAY be set by the 1730 NI+ to restrict the set of possible NIs. An edge-NAT will use the 1731 information provided in the NATFW_DTINFO object to allow only NATFW 1732 CREATE message with the MRI matching ('src IPv4/v6 address', 'src 1733 port number', 'protocol') to be forwarded. A NAT requiring 1734 information carried in the NATFW_DTINFO can generate a number of 1735 error RESPONSE messages of class 'Signaling session failures' (0x6): 1737 o 'Requested policy rule denied due to policy conflict' (0x04) 1739 o 'NATFW_DTINFO object is required' (0x07) 1741 o 'Requested value in sub_ports field in NATFW_EFI not permitted' 1742 (0x08) 1744 o 'Requested IP protocol not supported' (0x09) 1746 o 'Plain IP policy rules not permitted -- need transport layer 1747 information' (0x0A) 1749 o 'source IP address range is too large' (0x0C) 1751 o 'destination IP address range is too large' (0x0D) 1753 o 'source L4-port range is too large' (0x0E) 1755 o 'destination L4-port range is too large' (0x0F) 1757 Processing of EXT messages is specific to the NSIS node type: 1759 o NSLP initiator: NI+ only generate EXT messages. When the data 1760 sender's address information is known in advance the NI+ can 1761 include a NATFW_DTINFO object in the EXT message, if not anyway 1762 required to do so (see above). When the data sender's IP address 1763 is not known, the NI+ MUST NOT include a NATFW_DTINFO object. The 1764 NI should never receive EXT messages and MUST silently discard it. 1766 o NSLP forwarder: The NSLP message processing at NFs depends on the 1767 middlebox type: 1769 * NAT: NATs check whether the message is received at the external 1770 (public in most cases) address or at the internal (private) 1771 address. If received at the external an NF MUST generate an 1772 error RESPONSE of class 'Protocol error' (0x3) with response 1773 code 'Received EXT request message on external side' (0x0B). 1774 If received at the internal (private address) and the NATFW_EFI 1775 object contains the action 'deny', an error RESPONSE of class 1776 'Protocol error' (0x3) with response code 'Requested rule 1777 action not applicable' (0x06) MUST be generated. If received 1778 at the internal address, an IP address, and if applicable one 1779 or more ports, are reserved. If it is an edge-NAT and there is 1780 no edge-firewall beyond, the NSLP message is not forwarded any 1781 further and a successful RESPONSE message is generated 1782 containing an NATFW_EXT_IP object holding the translated 1783 address, and if applicable port, information from the binding 1784 reserved as a result of the EXT message. The RESPONSE message 1785 is sent back towards the NI+. If it is not an edge-NAT, the 1786 NSLP message is forwarded further using the translated IP 1787 address as signaling source address in the LE-MRM and 1788 translated port in the NATFW_DTINFO object in the field 'DR 1789 port number', i.e., the NATFW_DTINFO object is updated to 1790 reflect the translated port number. The edge-NAT or any other 1791 NAT MUST reject EXT messages not carrying a NATFW_DTINFO object 1792 or if the address information within this object is invalid or 1793 is not compliant with local policies (e.g., the information 1794 provided relates to a range of addresses ('wildcarded') but the 1795 edge-NAT requires exact information about DS' IP address and 1796 port) with the above mentioned response codes. 1798 * Firewall: Non edge-firewalls remember the requested policy 1799 rule, keep NATFW NSLP signaling session state, and forward the 1800 message. Edge-firewalls stop forwarding the EXT message. The 1801 policy rule is immediately loaded if the action in the 1802 NATFW_EFI object is set to 'deny' and the node is an edge- 1803 firewall. The policy rule is remembered, but not activated, if 1804 the action in the NATFW_EFI object is set to 'allow'. In both 1805 cases, a successful RESPONSE message is generated. If the 1806 action is 'allow', and the NATFW_DTINFO object is included, and 1807 the MRM is set to LE-MRM in the request, additionally an 1808 NATFW_EXT_IP object is included in the RESPONSE message, 1809 holding the translated address, and if applicable port, 1810 information. This information is obtained from the 1811 NATFW_DTINFO object's 'DR port number' and the source-address 1812 of the LE-MRM. 1814 * Combined NAT and firewall: Processing at combined firewall and 1815 NAT middleboxes is the same as in the NAT case. 1817 o NSLP receiver: This type of message should never be received by 1818 any NR+ and it MUST generate an error RESPONSE message of class 1819 'Permanent failure' (0x5) with response code 'No edge-device here' 1820 (0x06). 1822 Processing of a RESPONSE message is different for every NSIS node 1823 type: 1825 o NSLP initiator: Upon receiving a successful RESPONSE message, the 1826 NI+ can rely on the requested configuration for future inbound 1827 NATFW NSLP signaling sessions. If the response contains an 1828 NATFW_EXT_IP object, the NI can use IP address and port pairs 1829 carried for further application signaling. After receiving a 1830 error RESPONSE message, the NI+ MAY try to generate the EXT 1831 message again or give up and report the failure to the 1832 application, depending on the error condition. 1834 o NSLP forwarder: NFs simply forward this message as long as they 1835 keep state for the requested reservation, if the RESPONSE message 1836 contains NATFW_INFO object with class set to 'Success' (0x2). If 1837 the RESPONSE message contains NATFW_INFO object with class set not 1838 to 'Success' (0x2), the NATFW NSLP signaling session is marked as 1839 dead. 1841 o NSIS responder: This type of message should never be received by 1842 any NR+. The NF should never receive response messages and MUST 1843 silently discard it. 1845 Reservations with action 'allow' made with EXT MUST be enabled by a 1846 subsequent CREATE message. A reservation made with EXT (independent 1847 of selected action) is kept alive as long as the NI+ refreshes the 1848 particular NATFW NSLP signaling session and it can be reused for 1849 multiple, different CREATE messages. An NI+ may decide to teardown a 1850 reservation immediately after receiving a CREATE message. This 1851 implies that a new NATFW NSLP signaling session must be created for 1852 each new CREATE message. The CREATE message does not re-use the 1853 NATFW NSLP signaling session created by REA. 1855 Without using CREATE Section 3.7.1 or EXT in proxy mode Section 3.7.6 1856 no data traffic will be forwarded to DR beyond the edge-NAT or edge- 1857 firewall. The only function of EXT is to ensure that subsequent 1858 CREATE messages traveling towards the NR will be forwarded across the 1859 public-private boundary towards the DR. Correlation of incoming 1860 CREATE messages to EXT reservation states is described in 1861 Section 3.8. 1863 3.7.3. NATFW NSLP Signaling Session Refresh 1865 NATFW NSLP signaling sessions are maintained on a soft-state basis. 1866 After a specified timeout, sessions and corresponding policy rules 1867 are removed automatically by the middlebox, if they are not 1868 refreshed. Soft-state is created by CREATE and EXT and the 1869 maintenance of this state must be done by these messages. State 1870 created by CREATE must be maintained by CREATE, state created by EXT 1871 must be maintained by EXT. Refresh messages, are messages carrying 1872 the same session ID as the initial message and a NATFW_LT lifetime 1873 object with a lifetime greater than zero. Messages with the same SID 1874 but carrying a different MRI are treated as updates of the policy 1875 rules and are processed as defined in Section 3.10. Every refresh 1876 CREATE or EXT message MUST be acknowledged by an appropriate response 1877 message generated by the NR. Upon reception by each NSIS forwarder, 1878 the state for the given session ID is extended by the NATFW NSLP 1879 signaling session refresh period, a period of time calculated based 1880 on a proposed refresh message period. The lifetime extension of a 1881 NATFW NSLP signaling session is calculated as current local time plus 1882 proposed lifetime value (NATFW NSLP signaling session refresh 1883 period). Section 3.4 defines the process of calculating lifetimes in 1884 detail. 1886 NI Public Internet NAT Private address NR 1888 | | space | 1889 | CREATE[lifetime > 0] | | 1891 |----------------------------->| | 1892 | | | 1893 | | | 1894 | | CREATE[lifetime > 0] | 1895 | |--------------------------->| 1896 | | | 1897 | | RESPONSE[Success/Error] | 1898 | RESPONSE[Success/Error] |<---------------------------| 1899 |<-----------------------------| | 1900 | | | 1901 | | | 1903 Figure 16: Successful Refresh Message Flow, CREATE as example 1905 Processing of NATFW NSLP signaling session refresh CREATE and EXT 1906 messages is different for every NSIS node type: 1908 o NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling 1909 session refresh CREATE/EXT messages before the NATFW NSLP 1910 signaling session times out. The rate at which the refresh 1911 CREATE/EXT messages are sent and their relation to the NATFW NSLP 1912 signaling session state lifetime is discussed further in 1913 Section 3.4. 1915 o NSLP forwarder: Processing of this message is independent of the 1916 middlebox type and is as described in Section 3.4. 1918 o NSLP responder: NRs accepting a NATFW NSLP signaling session 1919 refresh CREATE/EXT message generate a successful RESPONSE message, 1920 including the granted lifetime value of Section 3.4 in a NATFW_LT 1921 object. 1923 3.7.4. Deleting Signaling Sessions 1925 NATFW NSLP signaling sessions can be deleted at any time. NSLP 1926 initiators can trigger this deletion by using a CREATE or EXT 1927 messages with a lifetime value set to 0, as shown in Figure 17. 1928 Whether a CREATE or EXT message type is used, depends on how the 1929 NATFW NSLP signaling session was created. 1931 NI Public Internet NAT Private address NR 1933 | | space | 1934 | CREATE[lifetime=0] | | 1935 |----------------------------->| | 1936 | | | 1937 | | CREATE[lifetime=0] | 1938 | |--------------------------->| 1939 | | | 1941 Figure 17: Delete message flow, CREATE as example 1943 NSLP nodes receiving this message delete the NATFW NSLP signaling 1944 session immediately. Policy rules associated with this particular 1945 NATFW NSLP signaling session MUST be also deleted immediately. This 1946 message is forwarded until it reaches the final NR. The CREATE/EXT 1947 message with a lifetime value of 0, does not generate any response, 1948 neither positive nor negative, since there is no NSIS state left at 1949 the nodes along the path. 1951 NSIS initiators can use CREATE/EXT message with lifetime set to zero 1952 in an aggregated way, such that a single CREATE or EXT message is 1953 terminating multiple NATFW NSLP signaling sessions. NIs can follow 1954 this procedure if the like to aggregate NATFW NSLP signaling session 1955 deletion requests: The NI uses the CREATE or EXT message with the 1956 session ID set to zero and the MRI's source-address set to its used 1957 IP address. All other fields of the respective NATFW NSLP signaling 1958 sessions to be terminated are set as well, otherwise these fields are 1959 completely wildcarded. The NSLP message is transferred to the NTLP 1960 requesting 'explicit routing' as described in Sections 5.2.1 and 1961 7.1.4. in [2]. 1963 The outbound NF receiving such an aggregated CREATE or EXT message 1964 MUST reject it with an error RESPONSE of class 'Permanent failure' 1965 (0x5) with response code 'Authentication failed' (0x01) if the 1966 authentication fails and with an error RESPONSE of class 'Permanent 1967 failure' (0x5) with response code 'Authorization failed' (0x02) if 1968 the authorization fails. Per NATFW NSLP signaling session proof of 1969 ownership, as it is defined in this memo, is not possible anymore 1970 when using this aggregated way. However, the outbound NF can use the 1971 relationship between the information of the received CREATE or EXT 1972 message and the GIST messaging association where the request has been 1973 received. The outbound NF MUST only accept this aggregated CREATE or 1974 EXT message through already established GIST messaging associations 1975 with the NI. The outbound NF MUST NOT propagate this aggregated 1976 CREATE or EXT message but it MAY generate and forward per NATFW NSLP 1977 signaling session CREATE or EXT messages. 1979 3.7.5. Reporting Asynchronous Events 1981 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 1982 to report asynchronous events to other NATFW NSLP nodes, especially 1983 to allow reporting back to the NATFW NSLP initiator. Such 1984 asynchronous events may be premature NATFW NSLP signaling session 1985 termination, changes in local policies, route change or any other 1986 reason that indicates change of the NATFW NSLP signaling session 1987 state. 1989 NFs and NRs may generate NOTIFY messages upon asynchronous events, 1990 with a NATFW_INFO object indicating the reason for event. These 1991 reasons can be carried in the NATFW_INFO object (class MUST be set to 1992 'Informational' (0x1)) within the NOTIFY message. This list shows 1993 the response codes and the associated actions to take at NFs and the 1994 NI: 1996 o 'Route change: possible route change on the outbound path' (0x01): 1997 Follow instructions in Section 3.9. This MUST be sent inbound. 1999 o 'Re-authentication required' (0x02): The NI should re-send the 2000 authentication. This MUST be sent inbound. 2002 o 'NATFW node is going down soon' (0x03): The NI and other NFs 2003 should be prepared for a service interruption at any time. This 2004 message MAY be sent inbound and outbound. 2006 o 'NATFW signaling session lifetime expired' (0x04): The NATFW 2007 signaling session has been expired and the signaling session is 2008 invalid now. NFs MUST mark the signaling session as 'Dead'. This 2009 message MAY be sent inbound and outbound. 2011 NOTIFY messages are always sent hop-by-hop inbound towards NI until 2012 they reach NI or outbound towards the NR as indicated in the list 2013 above. 2015 The initial processing when receiving a NOTIFY message is the same 2016 for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages 2017 through already established NTLP messaging associations. The further 2018 processing is different for each NATFW NSLP node type and depends on 2019 the events notified: 2021 o NSLP initiator: NIs analyze the notified event and behave 2022 appropriately based on the event type. NIs MUST NOT generate 2023 NOTIFY messages. 2025 o NSLP forwarder: NFs analyze the notified event and behave based on 2026 the above description per response code. NFs SHOULD generate 2027 NOTIFY messages upon asynchronous events and forward them inbound 2028 towards the NI or outbound towards the NR, depending on the 2029 received direction, i.e., inbound messages MUST be forwarded 2030 further inbound and outbound messages MUST be forwarded further 2031 inbound. NFs MUST silently discard NOTIFY messages that have been 2032 received outbound but are only allowed to be sent inbound, e.g. 2033 'Re-authentication required' (0x02). 2035 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 2036 asynchronous events including a response code based on the 2037 reported event. The NR MUST silently discard NOTIFY messages that 2038 have been received outbound but are only allowed to be sent 2039 inbound, e.g. 'Re-authentication required' (0x02), 2041 NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions 2042 at the same time, can experience problems when shutting down service 2043 suddenly. This sudden shutdown can be result of node local failure, 2044 for instance, due to a hardware failure. This NF generates NOTIFY 2045 messages for each of the NATFW NSLP signaling sessions and tries to 2046 send them inbound. Due to the number of NOTIFY messages to be sent, 2047 the shutdown of the node may be unnecessarily prolonged, since not 2048 all messages can be sent at the same time. This case can be 2049 described as a NOTIFY storm, if a multitude of NATFW NSLP signaling 2050 sessions is involved. 2052 To avoid the need of generating per NATFW NSLP signaling session 2053 NOTIFY messages in such a scenario described or similar cases, NFs 2054 SHOULD follow this procedure: The NF uses the NOTIFY message with the 2055 session ID in the NTLP set to zero, with the MRI completely 2056 wildcarded, using the 'explicit routing' as described in Sections 2057 5.2.1 and 7.1.4. in [2]. The inbound NF receiving this type of 2058 NOTIFY immediately regards all NATFW NSLP signaling sessions from 2059 that peer matching the MRI as void. This message will typically 2060 result in multiple NOTIFY messages at the inbound NF, i.e., the NF 2061 can generate per terminated NATFW NSLP signaling session a NOTIFY 2062 message. However, a NF MAY aggregate again the NOTIFY messages as 2063 described here. 2065 3.7.6. Proxy Mode of Operation 2067 Some migration scenarios need specialized support to cope with cases 2068 where NSIS is only deployed in same areas of the Internet. End-to- 2069 end signaling is going to fail without NSIS support at or near both 2070 data sender and data receiver terminals. A proxy mode of operation 2071 is needed. This proxy mode of operation must terminate the NATFW 2072 NSLP signaling as topologically close to the terminal for which it is 2073 proxying and proxy all messages. This NATFW NSLP node doing the 2074 proxying of the signaling messages becomes either the NI or the NR 2075 for the particular NATFW NSLP signaling session, depending on whether 2076 it is the DS or DR that does not support NSIS. Typically, the edge- 2077 NAT or the edge-firewall would be used to proxy NATFW NSLP messages. 2079 This proxy mode operation does not require any new CREATE or EXT 2080 message type, but relies on extended CREATE and EXT message types. 2081 They are called respectively CREATE-PROXY and EXT-PROXY and are 2082 distinguished by setting the P flag in the NSLP header to P=1. This 2083 flag instructs edge-NATs and edge-firewalls receiving them to operate 2084 in proxy mode for the NATFW NSLP signaling session in question. The 2085 semantics of the CREATE and EXT message types are not changed and the 2086 behavior of the various node types is as defined in Section 3.7.1 and 2087 Section 3.7.2, except for the proxying node. The following 2088 paragraphs describe the proxy mode operation for data receivers 2089 behind middleboxes and data senders behind middleboxes. 2091 3.7.6.1. Proxying for a Data Sender 2093 The NATFW NSLP gives the NR the ability to install state on the 2094 inbound path towards the data sender for outbound data packets, even 2095 when only the receiving side is running NSIS (as shown in Figure 18). 2096 The goal of the method described is to trigger the edge-NAT/ 2097 edge-firewall to generate a CREATE message on behalf of the data 2098 receiver. In this case, an NR can signal towards the network border 2099 as it is performed in the standard EXT message handling scenario as 2100 in Section 3.7.2. The message is forwarded until the edge-NAT/ 2101 edge-firewall is reached. A public IP address and port number is 2102 reserved at an edge-NAT/edge-firewall. As shown in Figure 18, unlike 2103 the standard EXT message handling case, the edge-NAT/edge-firewall is 2104 triggered to send a CREATE message on a new reverse path which 2105 traverse several firewalls or NATs. The new reverse path for CREATE 2106 is necessary to handle routing asymmetries between the edge-NAT/ 2107 edge-firewall and DR. It must be stressed that the semantics of the 2108 CREATE and EXT messages is not changed, i.e., each is processed as 2109 described earlier. 2111 DS Public Internet NAT/FW Private address NR 2112 No NI NF space NI+ 2113 NR+ 2115 | | EXT-PROXY[(DTInfo)] | 2116 | |<------------------------- | 2117 | | RESPONSE[Error/Success] | 2118 | | ---------------------- > | 2119 | | CREATE | 2120 | | ------------------------> | 2121 | | RESPONSE[Error/Success] | 2122 | | <---------------------- | 2123 | | | 2125 Figure 18: EXT Triggering Sending of CREATE Message 2127 A NATFW_NONCE object, carried in the EXT and CREATE message, is used 2128 to build the relationship between received CREATEs at the message 2129 initiator. An NI+ uses the presence of the NATFW_NONCE object to 2130 correlate it to the particular EXT-PROXY. The absence of a NONCE 2131 object indicates a CREATE initiated by the DS and not by the edge- 2132 NAT. Therefore, these processing rules of EXT-PROXY messages are 2133 added to the regular EXT processing: 2135 o NSLP initiator (NI+): The NI+ MUST choose a random value and place 2136 it in the NATFW_NONCE object. 2138 o NSLP forwarder being either edge-NAT or edge-firewall: When the NF 2139 accepts a EXT_PROXY message, it generates a successful RESPONSE 2140 message as if it were the NR and additionally, it generates a 2141 CREATE message as defined in Section 3.7.1 and includes a 2142 NATFW_NONCE object having the same value as of the received 2143 NATFW_NONCE object. The NF MUST not generate a CREATE-PROXY 2144 message. The NF MUST refresh the CREATE message signaling session 2145 only if a EXT-PROXY refresh message has been received first. This 2146 also includes tearing down signaling sessions, i.e., the NF must 2147 teardown the CREATE signaling session only if a EXT-PROXY message 2148 with lifetime set to 0 has been received first. 2150 The scenario described in this section challenges the data receiver 2151 because it must make a correct assumption about the data sender's 2152 ability to use NSIS NATFW NSLP signaling. It is possible for the DR 2153 to make the wrong assumption in two different ways: 2155 a) the DS is NSIS unaware but the DR assumes the DS to be NSIS 2156 aware and 2158 b) the DS is NSIS aware but the DR assumes the DS to be NSIS 2159 unaware. 2161 Case a) will result in middleboxes blocking the data traffic, since 2162 DS will never send the expected CREATE message. Case b) will result 2163 in the DR successfully requesting proxy mode support by the edge-NAT 2164 or edge-firewall. The edge-NAT/edge-firewall will send CREATE 2165 messages and DS will send CREATE messages as well. Both CREATE 2166 messages are handled as separated NATFW NSLP signaling sessions and 2167 therefore the common rules per NATFW NSLP signaling session apply; 2168 the NATFW_NONCE object is used to differentiate CREATE messages 2169 generated by the edge-NAT/edge-firewall from NI initiated CREATE 2170 messages. It is the NR's responsibility to decide whether to 2171 teardown the EXT-PROXY signaling sessions in the case where the data 2172 sender's side is NSIS aware, but was incorrectly assumed not to be so 2173 by the DR. It is RECOMMENDED that a DR behind NATs uses the proxy 2174 mode of operation by default, unless the DR knows that the DS is NSIS 2175 aware. The DR MAY cache information about data senders which it has 2176 found to be NSIS aware in past NATFW NSLP signaling sessions. 2178 There is a possible race condition between the RESPONSE message to 2179 the EXT-PROXY and the CREATE message generated by the edge-NAT. The 2180 CREATE message can arrive earlier than the RESPONSE message. An NI+ 2181 MUST accept CREATE messages generated by the edge-NAT even if the 2182 RESPONSE message to the EXT-PROXY was not received. 2184 3.7.6.2. Proxying for a Data Receiver 2186 As with data receivers behind middleboxes, data senders behind 2187 middleboxes can require proxy mode support. The issue here is that 2188 there is no NSIS support at the data receiver's side and, by default, 2189 there will be no response to CREATE messages. This scenario requires 2190 the last NSIS NATFW NSLP aware node to terminate the forwarding and 2191 to proxy the response to the CREATE message, meaning that this node 2192 is generating RESPONSE messages. This last node may be an edge-NAT/ 2193 edge-firewall, or any other NATFW NSLP peer, that detects that there 2194 is no NR available (probably as a result of GIST timeouts but there 2195 may be other triggers). 2197 DS Private Address NAT/FW Public Internet NR 2198 NI Space NF no NR 2200 | | | 2201 | CREATE-PROXY | | 2202 |------------------------------>| | 2203 | | | 2204 | RESPONSE[SUCCESS/ERROR] | | 2205 |<------------------------------| | 2206 | | | 2208 Figure 19: Proxy Mode CREATE Message Flow 2210 The processing of CREATE-PROXY messages and RESPONSE messages is 2211 similar to Section 3.7.1, except that forwarding is stopped at the 2212 edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to 2213 NI according the situation (error/success) and will be the NR for 2214 future NATFW NSLP communication. 2216 The NI can choose the proxy mode of operation although the DR is NSIS 2217 aware. The CREATE-PROXY mode would not configure all NATs and 2218 firewalls along the data path, since it is terminated at the edge- 2219 device. Any device beyond this point will never receive any NATFW 2220 NSLP signaling for this flow. 2222 3.8. De-Multiplexing at NATs 2224 Section 3.7.2 describes how NSIS nodes behind NATs can obtain a 2225 public reachable IP address and port number at a NAT and and how the 2226 resulting mapping rule can be activated by using CREATE messages (see 2227 Section 3.7.1). The information about the public IP address/port 2228 number can be transmitted via an application level signaling protocol 2229 and/or third party to the communication partner that would like to 2230 send data toward the host behind the NAT. However, NSIS signaling 2231 flows are sent towards the address of the NAT at which this 2232 particular IP address and port number is allocated and not directly 2233 to the allocated IP address and port number. The NATFW NSLP 2234 forwarder at this NAT needs to know how the incoming NSLP CREATE 2235 messages are related to reserved addresses, meaning how to de- 2236 multiplex incoming NSIS CREATE messages. 2238 The de-multiplexing method uses information stored at the local NATFW 2239 NSLP node and the of the policy rule. The policy rule uses the LE- 2240 MRM MRI source-address (see [2]) as the flow destination IP address 2241 and the network-layer-version as IP version. The external IP address 2242 at the NAT is stored as the external flow destination IP address. 2243 All other parameters of the policy rule other than the flow 2244 destination IP address are wildcarded if no NATFW_DTINFO object is 2245 included in the EXT message. The LE-MRM MRI destination-address MUST 2246 NOT be used in the policy rule, since it is solely a signaling 2247 destination address. 2249 If the NATFW_DTINFO object is included in the EXT message, the policy 2250 rule is filled with further information. The 'dst port number' field 2251 of the NATFW_DTINFO is stored as the flow destination port number. 2252 The 'protocol' field is stored as the flow protocol. The 'src port 2253 number' field is stored as the flow source port number. The 'data 2254 sender's IPv4 address' is stored as the flow source IP address. Note 2255 that some of these field can contain wildcards. 2257 When receiving a CREATE message at the NATFW NSLP it uses the flow 2258 information stored in the MRI to do the matching process. This table 2259 shows the parameters to be compared against each others. Note that 2260 not all parameters can be present in a MRI at the same time. 2262 +-------------------------------+--------------------------------+ 2263 | Flow parameter (Policy Rule) | MRI parameter (CREATE message) | 2264 +-------------------------------+--------------------------------+ 2265 | IP version | network-layer-version | 2266 | | | 2267 | Protocol | IP-protocol | 2268 | | | 2269 | source IP address (w) | source-address (w) | 2270 | | | 2271 | external IP address | destination-address | 2272 | | | 2273 | destination IP address (n/u) | N/A | 2274 | | | 2275 | source port number (w) | L4-source-port (w) | 2276 | | | 2277 | external port number (w) | L4-destination-port (w) | 2278 | | | 2279 | destination port number (n/u) | N/A | 2280 | | | 2281 | IPsec SPI | ipsec-SPI | 2282 +-------------------------------+--------------------------------+ 2284 Table entries marked with (w) can be wildcarded and entries marked 2285 with (n/u) are not used for the matching. 2287 Table 1 2289 3.9. Reacting to Route Changes 2291 The NATFW NSLP needs to react to route changes in the data path. 2292 This assumes the capability to detect route changes, to perform NAT 2293 and firewall configuration on the new path and possibly to tear down 2294 NATFW NSLP signaling session state on the old path. The detection of 2295 route changes is described in Section 7 of [2] and the NATFW NSLP 2296 relies on notifications about route changes by the NTLP. This 2297 notification will be conveyed by the API between NTLP and NSLP, which 2298 is out of scope of this memo. 2300 A NATFW NSLP node other than the NI or NI+ detecting a route change, 2301 by means described in the NTLP specification or others, generates a 2302 NOTIFY message indicating this change and sends this inbound towards 2303 NI. Intermediate NFs on the way to the NI can use this information 2304 to decide later if their NATFW NSLP signaling session can be deleted 2305 locally, if they do not receive an update within a certain time 2306 period, as described in Section 3.2.3. It is important to consider 2307 the transport limitations of NOTIFY messages as mandated in 2308 Section 3.7.5. 2310 The NI receiving this NOTIFY message MAY generate a new CREATE or EXT 2311 message and sends it towards the NATFW NSLP signaling session's NI as 2312 for the initial message using the same session ID. All the remaining 2313 processing and message forwarding, such as NSLP next hop discovery, 2314 is subject to regular NSLP processing as described in the particular 2315 sections. Normal routing will guide the new CREATE or EXT message to 2316 the correct NFs along the changed route. NFs that were on the 2317 original path receiving these new CREATE or EXT messages (see also 2318 Section 3.10), can use the session ID to update the existing NATFW 2319 NSLP signaling session, whereas NFs that were not on the original 2320 path will create new state for this NATFW NSLP signaling session. 2321 The next section describes how policy rules are updated. 2323 3.10. Updating Policy Rules 2325 NSIS initiators can request an update of the installed/reserved 2326 policy rules at any time within a NATFW NSLP signaling session. 2327 Updates to policy rules can be required due to node mobility (NI is 2328 moving from one IP address to another), route changes (this can 2329 result in a different NAT mapping at a different NAT device), or the 2330 wish of the NI to simply change the rule. NIs can update policy 2331 rules in existing NATFW NSLP signaling sessions by sending an 2332 appropriate CREATE or EXT message (similar to Section 3.4) with 2333 modified message routing information (MRI) as compared with that 2334 installed previously, but using the existing session ID to identify 2335 the intended target of the update. With respect to authorization and 2336 authentication, this update CREATE or EXT message is treated in 2337 exactly the same way as any initial message. Therefore, any node 2338 along in the NATFW NSLP signaling session can reject the update with 2339 an error RESPONSE message, as defined in the previous sections. 2341 The message processing and forwarding is executed as defined in the 2342 particular sections. A NF or the NR receiving an update, simply 2343 replaces the installed policy rules installed in the firewall/NAT. 2344 The local procedures on how to update the MRI in the firewall/NAT is 2345 out of scope of this memo 2347 4. NATFW NSLP Message Components 2349 A NATFW NSLP message consists of a NSLP header and one or more 2350 objects following the header. The NSLP header is carried in all 2351 NATFW NSLP message and objects are Type-Length-Value (TLV) encoded 2352 using big endian (network ordered) binary data representations. 2353 Header and objects are aligned to 32 bit boundaries and object 2354 lengths that are not multiples of 32 bits must be padded to the next 2355 higher 32 bit multiple. 2357 The whole NSLP message is carried as payload of a NTLP message. 2359 Note that the notation 0x is used to indicate hexadecimal numbers. 2361 4.1. NSLP Header 2363 All GIST NSLP-Data objects for the NATFW NSLP MUST contain this 2364 common header as the first 32 bits of the object (this is not the 2365 same as the GIST Common Header). It contains two fields, the NSLP 2366 message type and a reserved field. The total length is 32 bits. The 2367 layout of the NSLP header is defined by Figure 20. 2369 0 1 2 3 2370 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 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | Message type |P| reserved | reserved | 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 Figure 20: Common NSLP header 2377 The reserved field MUST be set to zero in the NATFW NSLP header 2378 before sending and MUST be ignored during processing of the header. 2380 The defined messages types are: 2382 o IANA-TBD(1) : CREATE 2384 o IANA-TBD(2) : EXTERNAL(EXT) 2386 o IANA-TBD(3) : RESPONSE 2388 o IANA-TBD(4) : NOTIFY 2390 If a message with another type is received, an error RESPONSE of 2391 class 'Protocol error' (0x3) with response code 'Illegal message 2392 type' (0x01) MUST be generated. 2394 The P flag indicates the usage of proxy mode. If proxy mode is used 2395 it MUST be set to 1. Proxy mode usage is only allowed in combination 2396 with the message types CREATE and EXT, P=1 MUST NOT be set with 2397 message types other than CREATE and EXT. The P flag MUST be ignored 2398 when processing messages with type RESPONSE. An error RESPONSE 2399 message of class 'Protocol error' (0x3) and type 'Bad flags value' 2400 (0x03) MUST be generated, if the P flag is set in NOTIFY messages. 2402 4.2. NSLP Objects 2404 NATFW NSLP objects use a common header format defined by Figure 21. 2405 The object header contains two fields, the NSLP object type and the 2406 object length. Its total length is 32 bits. 2408 0 1 2 3 2409 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 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2414 Figure 21: Common NSLP object header 2416 The object length field contains the total length of the object 2417 without the object header. The unit is a word, consisting of 4 2418 octets. The particular values of type and length for each NSLP 2419 object are listed in the subsequent sections that define the NSLP 2420 objects. An error RESPONSE of class 'Protocol error' (0x3) with 2421 response code 'Wrong object length' (0x07) MUST be generated if the 2422 length given for the object in the object header did not match the 2423 length of the object data present. The two leading bits of the NSLP 2424 object header are used to signal the desired treatment for objects 2425 whose treatment has not been defined in this memo (see [2], Section 2426 A.2.1), i.e., the Object Type has not been defined. NATFW NSLP uses 2427 a subset of the categories defined in GIST: 2429 o AB=00 ("Mandatory"): If the object is not understood, the entire 2430 message containing it MUST be rejected with an error RESPONSE of 2431 class 'Protocol error' (0x3) with response code 'Unknown object 2432 present' (0x06). 2434 o AB=01 ("Optional"): If the object is not understood, it should be 2435 deleted and then the rest of the message processed as usual. 2437 o AB=10 ("Forward"): If the object is not understood, it should be 2438 retained unchanged in any message forwarded as a result of message 2439 processing, but not stored locally. 2441 The combination AB=11 MUST NOT be used and an error RESPONSE of class 2442 'Protocol error' (0x3) with response code 'Invalid Flag-Field 2443 combination' (0x09) MUST be generated. 2445 The following sections do not repeat the common NSLP object header, 2446 they just list the type and the length. 2448 4.2.1. Signaling Session Lifetime Object 2450 The signaling session lifetime object carries the requested or 2451 granted lifetime of a NATFW NSLP signaling session measured in 2452 seconds. 2454 Type: NATFW_LT (IANA-TBD) 2456 Length: 1 2458 0 1 2 3 2459 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 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 | NATFW NSLP signaling session lifetime | 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 Figure 22: Signaling Session Lifetime object 2466 4.2.2. External Address Object 2468 The external address object can be included in RESPONSE messages 2469 (Section 4.3.3) only. It carries the publicly reachable IP address, 2470 and if applicable port number, at an edge-NAT. 2472 Type: NATFW_EXT_IP (IANA-TBD) 2474 Length: 2 2476 0 1 2 3 2477 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 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 | port number | reserved | 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | IPv4 address | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 Figure 23: External Address Object for IPv4 addresses 2486 Please note that the field 'port number' MUST be set to 0 if only an 2487 IP address has been reserved, for instance, by a traditional NAT. A 2488 port number of 0 MUST be ignored in processing this object. 2490 4.2.3. Extended Flow Information Object 2492 In general, flow information is kept in the message routing 2493 information (MRI) of the NTLP. Nevertheless, some additional 2494 information may be required for NSLP operations. The 'extended flow 2495 information' object carries this additional information about the 2496 action of the policy rule for firewalls/NATs and contiguous port . 2498 Type: NATFW_EFI (IANA-TBD) 2500 Length: 1 2502 0 1 2 3 2503 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 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | rule action | sub_ports | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 Figure 24: Extended Flow Information 2510 This object has two fields, 'rule action' and 'sub_ports'. The 'rule 2511 action' field has these meanings: 2513 o 0x0001: Allow: A policy rule with this action allows data traffic 2514 to traverse the middlebox and the NATFW NSLP MUST allow NSLP 2515 signaling to be forwarded. 2517 o 0x0002: Deny: A policy rule with this action blocks data traffic 2518 from traversing the middlebox and the NATFW NSLP MUST NOT allow 2519 NSLP signaling to be forwarded. 2521 If the 'rule action' field contains neither 0x0001 nor 0x0002, an 2522 error RESPONSE of class 'Signaling session error' (0x6) with response 2523 code 'Unknown policy rule action' (0x05) MUST be generated. 2525 The 'sub_ports' field contains the number of contiguous transport 2526 layer ports to which this rule applies. The default value of this 2527 field is 0, i.e., only the port specified in the NTLP's MRM or 2528 NATFW_DTINFO object is used for the policy rule. A value of 1 2529 indicates that additionally to the port specified in the NTLP's MRM 2530 (port1), a second port (port2) is used. This value of port 2 is 2531 calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT 2532 be used in this field and an error RESPONSE of class 'Signaling 2533 session error' (0x6) with response code 'Requested value in sub_ports 2534 field in NATFW_EFI not permitted' (0x08) MUST be generated. Further 2535 version of this memo may allow other values for the 'sub_ports' 2536 field. This two contiguous port numbered ports, can be used by 2537 legacy voice over IP equipment. This legacy equipment assumes that 2538 two adjacent port numbers for its RTP/RTCP flows respectively. 2540 4.2.4. Information Code Object 2542 This object carries the response code, which may be indications for 2543 either a successful or failed CREATE or EXT message depending on the 2544 value of the 'response code' field. 2546 Type: NATFW_INFO (IANA-TBD) 2548 Length: 1 2550 0 1 2 3 2551 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 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Resv. | Class | Response Code |r|r|r|r| Object Type | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 Figure 25: Information Code Object 2558 The field 'resv.' is reserved for future extensions and MUST be set 2559 to zero when generating such an object and MUST be ignored when 2560 receiving. The 'Object Type' field contains the type of the object 2561 causing the error. The value of 'Object Type' is set to 0, if no 2562 object is concerned and the leading fours bits marked with 'r' are 2563 always set to zero and ignored. The 4 bit class field contains the 2564 severity class. The following classes are defined: 2566 o 0x1: Informational (NOTIFY only) 2568 o 0x2: Success 2570 o 0x3: Protocol error 2572 o 0x4: Transient failure 2574 o 0x5: Permanent failure 2576 o 0x6: Signaling session failures 2578 Within each severity class a number of responses values are defined 2579 o Informational: 2581 * 0x01: Route change: possible route change on the outbound path. 2583 * 0x02: Re-authentication required. 2585 * 0x03: NATFW node is going down soon. 2587 o Success: 2589 * 0x01: All successfully processed. 2591 o Protocol error: 2593 * 0x01: Illegal message type: the type given in the Message Type 2594 field of the NSLP header is unknown. 2596 * 0x02: Wrong message length: the length given for the message in 2597 the NSLP header does not match the length of the message data. 2599 * 0x03: Bad flags value: an undefined flag or combination of 2600 flags was set in the NSLP header. 2602 * 0x04: Mandatory object missing: an object required in a message 2603 of this type was missing. 2605 * 0x05: Illegal object present: an object was present which must 2606 not be used in a message of this type. 2608 * 0x06: Unknown object present: an object of an unknown type was 2609 present in the message. 2611 * 0x07: Wrong object length: the length given for the object in 2612 the object header did not match the length of the object data 2613 present. 2615 * 0x08: Unknown object field value: a field in an object had an 2616 unknown value. 2618 * 0x09: Invalid Flag-Field combination: An object contains an 2619 invalid combination of flags and/or fields. 2621 * 0x0A: Duplicate object present. 2623 * 0x0B: Received EXT request message on external side. 2625 o Transient failure: 2627 * 0x01: Requested resources temporarily not available. 2629 o Permanent failure: 2631 * 0x01: Authentication failed. 2633 * 0x02: Authorization failed. 2635 * 0x03: Unable to agree transport security with peer. 2637 * 0x04: Internal or system error. 2639 * 0x05: No NAT here. 2641 * 0x06: No edge-device here. 2643 * 0x07: Did not reach the NR. 2645 o Signaling session failures: 2647 * 0x01: Session terminated asynchronously. 2649 * 0x02: Requested lifetime is too big. 2651 * 0x03: No reservation found matching the MRI of the CREATE 2652 request. 2654 * 0x04: Requested policy rule denied due to policy conflict. 2656 * 0x05: Unknown policy rule action. 2658 * 0x06: Requested rule action not applicable. 2660 * 0x07: NATFW_DTINFO object is required. 2662 * 0x08: Requested value in sub_ports field in NATFW_EFI not 2663 permitted. 2665 * 0x09: Requested IP protocol not supported. 2667 * 0x0A: Plain IP policy rules not permitted -- need transport 2668 layer information. 2670 * 0x0B: ICMP type value not permitted. 2672 * 0x0C: source IP address range is too large. 2674 * 0x0D: destination IP address range is too large. 2676 * 0x0E: source L4-port range is too large. 2678 * 0x0F: destination L4-port range is too large. 2680 * 0x10: Requested lifetime is too small. 2682 4.2.5. Nonce Object 2684 This object carries the nonce value as described in Section 3.7.6. 2686 Type: NATFW_NONCE (IANA-TBD) 2688 Length: 1 2690 0 1 2 3 2691 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 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | nonce | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 Figure 26: Nonce Object 2698 4.2.6. Message Sequence Number Object 2700 This object carries the MSN value as described in Section 3.5. 2702 Type: NATFW_MSN (IANA-TBD) 2704 Length: 1 2706 0 1 2 3 2707 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 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | message sequence number | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 Figure 27: Message Sequence Number Object 2714 4.2.7. Data Terminal Information Object 2716 The 'data terminal information' object carries additional information 2717 possibly needed during EXT operations. EXT messages are transported 2718 by the NTLP using the Loose-End message routing method (LE-MRM). The 2719 LE-MRM contains only DR's IP address and a signaling destination 2720 address (destination address). This destination address is used for 2721 message routing only and is not necessarily reflecting the address of 2722 the data sender. This object contains information about (if 2723 applicable) DR's port number (the destination port number), DS' port 2724 number (the source port number), the used transport protocol, the 2725 prefix length of the IP address, and DS' IP address. 2727 Type: NATFW_DTINFO (IANA-TBD) 2729 Length: variable. Maximum 3. 2731 0 1 2 3 2732 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 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 |I|P|S| reserved | sender prefix | protocol | 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 : DR port number | DS port number : 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 : IPsec SPI : 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 | data sender's IPv4 address | 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 Figure 28: Data Terminal IPv4 Address Object 2745 The flags are: 2747 o I: I=1 means that 'protocol' should be interpreted. 2749 o P: P=1 means that 'dst port number' and 'src port number' are 2750 present and should be interpreted. 2752 o S: S=1 means that SPI is present and should be interpreted. 2754 The SPI field is only present if S is set. The port numbers are only 2755 present if P is set. The flags P and S MUST NOT be set at the same 2756 time. An error RESPONSE of class 'Protocol error' (0x3) with 2757 response code 'Invalid Flag-Field combination' (0x09) MUST be 2758 generated if they are both set. If either P or S is set, I MUST be 2759 set as well and the protocol field MUST carry the particular 2760 protocol. An error RESPONSE of class 'Protocol error' (0x3) with 2761 response code 'Invalid Flag-Field combination' (0x09) MUST be 2762 generated if S or P is set but I is not set. 2764 The fields MUST be interpreted according these rules: 2766 o (data) sender prefix: This parameter indicates the prefix length 2767 of the 'data sender's IP address' in bits. For instance, a full 2768 IPv4 address requires 'sender prefix' to be set to 32. A value of 2769 0 indicates an IP address wildcard. 2771 o protocol: The IPv4 protocol field. This field MUST be interpreted 2772 if I=1, otherwise it MUST be set to 0 and MUST be ignored. 2774 o DR port number: The port number at the data receiver (DR), i.e., 2775 the destination port. A value of 0 indicates a port wildcard, 2776 i.e., the destination port number is not known. Any other value 2777 indicates the destination port number. 2779 o DS port number: The port number at the data sender (DS), i.e., the 2780 source port. A value of 0 indicates a port wildcard, i.e., the 2781 source port number is not known. Any other value indicates the 2782 source port number. 2784 o data sender's IPv4 address: The source IP address of the data 2785 sender. This field MUST be set to zero if no IP address is 2786 provided, i.e., a complete wildcard is desired (see dest prefix 2787 field above). 2789 4.2.8. ICMP Types Object 2791 The 'ICMP types' object contains additional information needed to 2792 configure a NAT of firewall with rules to control ICMP traffic. The 2793 object contains a number of values of the ICMP Type field for which a 2794 filter action should be set up: 2796 Type: NATFW_ICMP_TYPES (IANA-TBD) 2798 Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 2800 Where DIV is an integer division. 2802 0 1 2 3 2803 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 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 | Count | Type | Type | ........ | 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 | ................ | 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 | ........ | Type | (Padding) | 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 Figure 29: ICMP Types Object 2814 The fields MUST be interpreted according these rules: 2816 count: 8 bit integer specifying the number of 'Type' entries in 2817 the object. 2819 type: 8 bit field specifying an ICMP Type value to which this rule 2820 applies. 2822 padding: Sufficient 0 bits to pad out the last word so that the 2823 total size of object is an even multiple of words. Ignored on 2824 reception. 2826 4.3. Message Formats 2828 This section defines the content of each NATFW NSLP message type. 2829 The message types are defined in Section 4.1. 2831 Basically, each message is constructed of NSLP header and one or more 2832 NSLP objects. The order of objects is not defined, meaning that 2833 objects may occur in any sequence. Objects are marked either with 2834 mandatory (M) or optional (O). Where (M) implies that this 2835 particular object MUST be included within the message and where (O) 2836 implies that this particular object is OPTIONAL within the message. 2837 Objects defined in this memo carry always the flag combination AB=00 2838 in the NSLP object header. An error RESPONSE message of class 2839 'Protocol error' (0x3) with response code 'Mandatory object missing' 2840 (0x02) MUST be generated if a mandatory declared object is missing. 2841 An error RESPONSE message of class 'Protocol error' (0x3) with 2842 response code 'Illegal object present' (0x05) MUST be generated if an 2843 object was present which must not be used in a message of this type. 2844 An error RESPONSE message of class 'Protocol error' (0x3) with 2845 response code 'Duplicate object present' (0x0A) MUST be generated if 2846 an object appears more than once in a message. 2848 Each section elaborates the required settings and parameters to be 2849 set by the NSLP for the NTLP, for instance, how the message routing 2850 information is set. 2852 4.3.1. CREATE 2854 The CREATE message is used to create NATFW NSLP signaling sessions 2855 and to create policy rules. Furthermore, CREATE messages are used to 2856 refresh NATFW NSLP signaling sessions and to delete them. 2858 The CREATE message carries these objects: 2860 o Signaling Session Lifetime object (M) 2862 o Extended flow information object (M) 2864 o Message sequence number object (M) 2866 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 2867 (O) 2869 o ICMP Types Object (O) 2871 The message routing information in the NTLP MUST be set to DS as 2872 source address and DR as destination address. All other parameters 2873 MUST be set according the required policy rule. CREATE messages MUST 2874 be transported by using the path-coupled MRM with direction set to 2875 'downstream' (outbound). 2877 4.3.2. EXTERNAL (EXT) 2879 The EXTERNAL (EXT) message is used to a) reserve an external IP 2880 address/port at NATs, b) to notify firewalls about NSIS capable DRs, 2881 or c) to block incoming data traffic at inbound firewalls. 2883 The EXT message carries these objects: 2885 o Signaling Session Lifetime object (M) 2887 o Message sequence number object (M) 2889 o Extended flow information object (M) 2891 o Data terminal information object (M) 2893 o Nonce object [M if P flag set to 1 in the NSLP header, otherwise 2894 (O) 2896 o ICMP Types Object (O) 2897 The selected message routing method of the EXT message depends on a 2898 number of considerations. Section 3.7.2 describes it exhaustively 2899 how to select the correct method. EXT messages can be transported 2900 via the path-coupled message routing method (PC-MRM) or via the 2901 loose-end message routing method (LE-MRM). In the case of PC-MRM, 2902 the source-address is set to DS' address and the destination address 2903 is set to DR's address, the direction is set to inbound. In the case 2904 of LE-MRM, the destination-address is set to DR's address or to the 2905 signaling destination address. The source-address is set to DS's 2906 address. 2908 4.3.3. RESPONSE 2910 RESPONSE messages are responses to CREATE and EXT messages. RESPONSE 2911 messages MUST NOT be generated for any other message, such as NOTIFY 2912 and RESPONSE. 2914 The RESPONSE message for the class 'Success' (0x2) carries these 2915 objects: 2917 o Signaling Session Lifetime object (M) 2919 o Message sequence number object (M) 2921 o Information code object (M) 2923 o External address object (O) 2925 The RESPONSE message for other classes than 'Success' (0x2) carries 2926 these objects: 2928 o Message sequence number object (M) 2930 o Information code object (M) 2932 This message is routed towards the NI hop-by-hop, using existing NTLP 2933 messaging associations. The MRM used for this message MUST be the 2934 same as MRM used by the corresponding CREATE or EXT message. 2936 4.3.4. NOTIFY 2938 The NOTIFY messages is used to report asynchronous events happening 2939 along the signaled path to other NATFW NSLP nodes. 2941 The NOTIFY message carries this object: 2943 o Information code object (M). 2945 The NOTIFY message is routed towards the NI hop-by-hop using the 2946 existing inbound node messaging association entry within the node's 2947 Message Routing State table. The MRM used for this message MUST be 2948 the same as MRM used by the corresponding CREATE or EXT message. 2950 5. Security Considerations 2952 Security is of major concern particularly in case of firewall 2953 traversal. This section provides security considerations for the 2954 NAT/firewall traversal and is organized as follows. 2956 In Section 5.1 we describe the participating entities relate to each 2957 other from a security point of view. This subsection also motivates 2958 a particular authorization model. 2960 Security threats that focus on NSIS in general are described in [8] 2961 and they are applicable to this document as well. In Section 5.2 we 2962 extend this threat investigation by considering NATFW NSLP specific 2963 threats in more detail. Based on the investigated security threats 2964 we derive security requirements. 2966 Finally, we illustrate how the security requirements that were 2967 created based on the security threats can be fulfilled by specific 2968 security mechanisms. These aspects will be elaborated in 2969 Section 5.11. 2971 5.1. Authorization Framework 2973 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 2974 and is, as such, not a two-party protocol. Figure 1 and Figure 2 of 2975 [8] already depict the possible set of communication patterns. In 2976 this section we will re-evaluate these communication patters with 2977 respect to the NATFW NSLP protocol interaction. 2979 The security solutions for providing authorization have a direct 2980 impact on the treatment of different NSLPs. As it can be seen from 2981 the QoS NSLP [6] and the corresponding Diameter QoS work [20] 2982 accounting and charging seems to play an important role for QoS 2983 reservations, whereas monetary aspects might only indirectly effect 2984 authorization decisions for NAT and firewall signaling. Hence, there 2985 are differences in the semantic of authorization handling between QoS 2986 and NATFW signaling. A NATFW aware node will most likely want to 2987 authorize the entity (e.g., user or machine) requesting the 2988 establishment of pinholes or NAT bindings. The outcome of the 2989 authorization decision is either allowed or disallowed whereas a QoS 2990 authorization decision might indicate that a different set of QoS 2991 parameters is authorization (see [20] as an example). 2993 5.1.1. Peer-to-Peer Relationship 2995 Starting with the simplest scenario, it is assumed that neighboring 2996 nodes are able to authenticate each other and to establish keying 2997 material to protect the signaling message communication. The nodes 2998 will have to authorize each other, additionally to the 2999 authentication. We use the term 'Security Context' as a placeholder 3000 for referring to the entire security procedure, the necessary 3001 infrastructure that needs to be in place in order for this to work 3002 (e.g., key management) and the established security related state. 3003 The required long-term key (symmetric or asymmetric keys) used for 3004 authentication are either made available using an out-of-band 3005 mechanism between the two NSIS NATFW nodes or they are dynamically 3006 established using mechanisms not further specified in this document. 3007 Note that the deployment environment will most likely have an impact 3008 on the choice of credentials being used. The choice of these 3009 credentials used is also outside the scope of this document. 3011 +------------------------+ +-------------------------+ 3012 |Network A | | Network B| 3013 | +---------+ +---------+ | 3014 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3015 | | | box 1 | Security | box 2 | | | 3016 | | +---------+ Context +---------+ | | 3017 | | Security | | Security | | 3018 | | Context | | Context | | 3019 | | | | | | 3020 | +--+---+ | | +--+---+ | 3021 | | Host | | | | Host | | 3022 | | A | | | | B | | 3023 | +------+ | | +------+ | 3024 +------------------------+ +-------------------------+ 3026 Figure 30: Peer-to-Peer Relationship 3028 Figure 30 shows a possible relationship between participating NSIS 3029 aware nodes. Host A might be, for example, a host in an enterprise 3030 network that has keying material established (e.g., a shared secret) 3031 with the company's firewall (Middlebox 1). The network administrator 3032 of Network A (company network) has created access control lists for 3033 Host A (or whatever identifiers a particular company wants to use). 3034 Exactly the same procedure might also be used between Host B and 3035 Middlebox 2 in Network B. For the communication between Middlebox 1 3036 and Middlebox 2 a security context is also assumed in order to allow 3037 authentication, authorization and signaling message protection to be 3038 successful. 3040 5.1.2. Intra-Domain Relationship 3042 In larger corporations, for example, a middlebox is used to protect 3043 individual departments. In many cases, the entire enterprise is 3044 controlled by a single (or a small number of) security department, 3045 which gives instructions to the department administrators. In such a 3046 scenario, the previously discussed peer-to-peer relationship might be 3047 prevalent. Sometimes it might be necessary to preserve 3048 authentication and authorization information within the network. As 3049 a possible solution, a centralized approach could be used, whereby an 3050 interaction between the individual middleboxes and a central entity 3051 (for example a policy decision point - PDP) takes place. As an 3052 alternative, individual middleboxes exchange the authorization 3053 decision with another middlebox within the same trust domain. 3054 Individual middleboxes within an administrative domain may exploit 3055 their relationship instead of requesting authentication and 3056 authorization of the signaling initiator again and again. Figure 31 3057 illustrates a network structure which uses a centralized entity. 3059 +-----------------------------------------------------------+ 3060 | Network A | 3061 | +---------+ +---------+ 3062 | +----///--------+ Middle- +------///------++ Middle- +--- 3063 | | Security | box 2 | Security | box 2 | 3064 | | Context +----+----+ Context +----+----+ 3065 | +----+----+ | | | 3066 | | Middle- +--------+ +---------+ | | 3067 | | box 1 | | | | | 3068 | +----+----+ | | | | 3069 | | Security | +----+-----+ | | 3070 | | Context | | Policy | | | 3071 | +--+---+ +-----------+ Decision +----------+ | 3072 | | Host | | Point | | 3073 | | A | +----------+ | 3074 | +------+ | 3075 +-----------------------------------------------------------+ 3077 Figure 31: Intra-domain Relationship 3079 The interaction between individual middleboxes and a policy decision 3080 point (or AAA server) is outside the scope of this document. 3082 5.1.3. End-to-Middle Relationship 3084 The peer-to-peer relationship between neighboring NSIS NATFW NSLP 3085 nodes might not always be sufficient. Network B might require 3086 additional authorization of the signaling message initiator (in 3087 addition to the authorization of the neighboring node). If 3088 authentication and authorization information is not attached to the 3089 initial signaling message then the signaling message arriving at 3090 Middlebox 2 would result in an error message being created, which 3091 indicates the additional authorization requirement. In many cases 3092 the signaling message initiator might already be aware of the 3093 additionally required authorization before the signaling message 3094 exchange is executed. 3096 Figure 32 shows this scenario. 3098 +--------------------+ +---------------------+ 3099 | Network A | |Network B | 3100 | | Security | | 3101 | +---------+ Context +---------+ | 3102 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3103 | | | box 1 | +-------+ box 2 | | | 3104 | | +---------+ | +---------+ | | 3105 | |Security | | | Security | | 3106 | |Context | | | Context | 3107 | | | | | | | 3108 | +--+---+ | | | +--+---+ | 3109 | | Host +----///----+------+ | | Host | | 3110 | | A | | Security | | B | | 3111 | +------+ | Context | +------+ | 3112 +--------------------+ +---------------------+ 3114 Figure 32: End-to-Middle Relationship 3116 5.2. Security Threats and Requirements 3118 This section describes NATFW specific security threats and 3119 requirements. 3121 5.2.1. Data Sender (DS) behind a firewall 3123 +------------------------------+ 3124 | | 3125 | +-----+ create +-----+ 3126 | | DS | --------------> | FW | 3127 | +-----+ +-----+ 3128 | | 3129 +------------------------------+ 3131 DS behind a firewall 3133 DS sends a CREATE message to request the traversal of a data flow. 3135 The following attacks are possible: 3137 o DS could open a firewall pinhole with a source address different 3138 from its own host. 3140 o DS could open firewall pinholes for incoming data flows that are 3141 not supposed to enter the network. 3143 o DS could request installation of any policy rules and allow all 3144 traffic go through. 3146 SECURITY REQUIREMENT: The middlebox MUST authenticate and authorize 3147 the neighboring NAT/FW NSLP node requesting an action. 3148 Authentication and authorization of the initiator SHOULD be 3149 provided to NATs and firewalls along the path. 3151 5.2.2. Data Sender (DS) behind a NAT 3153 The case 'DS behind a NAT' is analogous to the case 'DS behind a 3154 firewall'. 3156 Figure 34 illustrates such a scenario: 3158 +------------------------------+ 3159 | | 3160 | +------+ CREATE | 3161 | | NI_1 | ------\ +-----+ CREATE +-----+ 3162 | +------+ \------> | NAT |-------->| MB | 3163 | +-----+ +-----+ 3164 | +------+ | 3165 | | NI_2 | | 3166 | +------+ | 3167 +------------------------------+ 3169 Figure 34: Several NIs behind a NAT 3171 In this case the middlebox MB does not know who is the NSIS Initiator 3172 since both NI_1 and NI_2 are behind a NAT (which is also NSIS aware). 3173 Authentication needs to be provided by other means such as the NSLP 3174 or the application layer. 3176 SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure 3177 that the neighboring NAT/FW NSLP node is authorized to request an 3178 action. Authentication and authorization of the initiator (which 3179 is the DR in this scenario) to the non-neighboring middleboxes 3180 SHOULD be provided. 3182 5.2.3. Data Receiver (DR) behind a firewall 3184 In this case a CREATE message comes from an entity DS outside the 3185 network towards the DR inside the network. 3187 +------------------------------+ 3188 | | 3189 +-----+ CREATE +-----+ CREATE +-----+ | 3190 | DS | -------------> | FW | -------------> | DR | | 3191 +-----+ <------------- +-----+ <------------- +-----+ | 3192 successful RESPONSE | successful RESPONSE | 3193 | | 3194 +------------------------------+ 3196 DR behind a firewall 3198 Since policy rules at middleboxes must only be installed after 3199 receiving a successful response it is necessary that the middlebox 3200 waits until the Data Receiver DR confirms the request of the Data 3201 Sender DS with a successful RESPONSE message. 3203 This confirmation implies that the data receiver is expecting the 3204 data flow. 3206 At this point we differentiate two cases: 3208 1. DR knows the (publicly reachable) IP address and port number of 3209 the DS (for instance because of some previous application layer 3210 signaling) and is expecting the data flow. 3212 2. DR might be expecting the data flow (for instance because of some 3213 previous application layer signaling) but does not know the 3214 (publicly reachable) IP address of the Data Sender DS. 3216 For the second case, Figure 36 illustrates a possible attack: an 3217 adversary Mallory M could be sniffing the application layer signaling 3218 and thus knows the address and port number where DR is expecting the 3219 data flow. Thus it could pretend to be DS and send a CREATE message 3220 towards DR with the data flow description (M -> DR). Since DR does 3221 not know the IP address of DS, it is not able to recognize that the 3222 request is coming from the "wrong guy". It will send a success 3223 RESPONSE message back and the middlebox will install policy rules 3224 that will allow Mallory M to inject its data into the network. 3226 Application Layer signaling 3227 <------------------------------------> 3228 / \ 3229 / +-----------------\------------+ 3230 / | \ | 3231 +-----+ +-----+ +-----+ | 3232 | DS | -> | FW | | DR | | 3233 +-----+ / +-----+ +-----+ | 3234 CREATE / | | 3235 +-----+ / +-------------------------------+ 3236 | M |---------- 3237 +-----+ 3239 Figure 36: DR behind a firewall with an adversary 3241 Network administrators will probably not rely on a DR to check the IP 3242 address of the DS. Thus we have to assume the worst case with an 3243 attack such as in Figure 36. Many operators might not allow NSIS 3244 signaling message to traverse the firewall in Figure 36 without 3245 having the DR to interact with the FW first. 3247 SECURITY REQUIREMENT: No requirements are created by this scenario. 3249 5.2.4. Data Receiver (DR) behind a NAT 3251 When a data receiver DR behind a NAT sends a EXTERNAL (EXT) message 3252 to get a public reachable address, this address can be used as a 3253 contact address by an arbitrary data sender, if the DR was unable to 3254 restrict the future data sender. The NAT reserves an external 3255 address and port number and sends them back to DR. The NAT adds an 3256 address mapping entry in its reservation list which links the public 3257 and private addresses as follows: 3259 (DR_ext <=> DR_int) (accept data from any IP address, i.e., 3260 wildcard). 3262 The NAT sends a RESPONSE message with the external address' object 3263 back to the DR with the address DR_ext. DR informs DS about the 3264 public address that it has recently received, for instance, by means 3265 of application layer signaling. 3267 When a data sender sends a CREATE message towards DR_ext then the 3268 message will be forwarded to the DR. The data receiver might want to 3269 update the NAT binding stored at the edge-NAT to make it more 3270 restrictive. 3272 We assume that the adversary Mallory M obtains the contact address 3273 (i.e., external address and port) allocated at the NAT possibly by 3274 eavesdropping on the application layer signaling and sends a CREATE 3275 message. As a consequence Mallory would be able to communicate with 3276 DR (if M is authorized by the edge-NAT and if the DR accepts CREATE 3277 and returns a RESPONSE. 3279 Application Layer signaling 3280 <------------------------------------------> 3281 / \ 3282 / +----------------------\-------+ 3283 v | EXT v | 3284 +-----+ +-----+ <----------- +-----+ | 3285 | DS | -> | NAT | -----------> | DR | | 3286 +-----+ / +-----+ DR_external +-----+ | 3287 CREATE / | | 3288 +-----+ / +-------------------------------+ 3289 | M |---------- 3290 +-----+ 3292 DR behind a NAT with an adversary 3294 SECURITY REQUIREMENT: The DR MUST be able to specify which data 3295 sender is allowed to traverse the NAT in order to be forwarded to 3296 DR's address. 3298 5.2.5. NSLP Message Injection 3300 Malicious hosts, located either off-path or on-path, could inject 3301 arbitrary NATFW NSLP messages into the signaling path. These 3302 problems apply when no proper authorization and authentication scheme 3303 is available. 3305 By injecting a bogus CREATE message with NATFW NSLP signaling session 3306 lifetime set to zero, a malicious host could try to teardown NATFW 3307 NSLP signaling session state partially or completely on a data path, 3308 causing a service interruption. 3310 By injecting a bogus responses or NOTIFY message, for instance, NATFW 3311 NSLP signaling session timeout, a malicious host could try to 3312 teardown NATFW NSLP signaling session state as well. This could 3313 affect the data path partially or totally, causing a service 3314 interruption. 3316 SECURITY REQUIREMENT: Messages, such as NOTIFY, can be misused by 3317 malicious hosts, and therefore MUST be authorized by the 3318 respective NATFW NLSP entities. 3320 5.3. Denial-of-Service Attacks 3322 In this section we describe several ways how an adversary could 3323 launch a Denial of service (DoS) attack on networks running NSIS for 3324 middlebox configuration to exhaust their resources. 3326 5.3.1. Flooding with CREATE messages from outside 3328 5.3.1.1. Attacks due to NSLP state 3330 A CREATE message requests the NSLP to store state information such as 3331 a NAT binding or a policy rule. 3333 The policy rules requested in the CREATE message will be installed at 3334 the arrival of a confirmation from the Data Receiver with a success 3335 RESPONSE message. A successful RESPONSE message includes the session 3336 ID. So the NSLP looks up the NATFW NSLP signaling session and 3337 installs the requested policy rules. 3339 An adversary could launch a DoS attack with an arbitrary number of 3340 CREATE messages. For each of these messages the middlebox needs to 3341 store state information such as the policy rules to be loaded, i.e., 3342 the middlebox could run out of memory. This kind of attack is also 3343 mentioned in [8] Section 4.8. 3345 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 3346 establishment of state information. 3348 5.3.1.2. Attacks due to authentication complexity 3350 This kind of attack is possible if authentication is based on 3351 mechanisms that require computing power, for example, digital 3352 signatures. 3354 For a more detailed treatment of this kind of attack, the reader is 3355 encouraged to see [8]. 3357 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 3358 denial of service attacks based on authentication or key exchange 3359 mechanisms. 3361 5.3.1.3. Attacking Endpoints 3363 The NATFW NSLP requires firewalls to forward NSLP messages, a 3364 malicious node may keep sending NSLP messages to a target. This may 3365 consume the access network resources of the victim, drain the battery 3366 of the victim's terminal and may force the victim to pay for the 3367 received although undesired data. 3369 This threat may be more particularly be relevant in networks where 3370 access link is a limited resource, for instance in cellular networks, 3371 and where the terminal capacities are limited. 3373 SECURITY REQUIREMENT: A NATFW NSLP node MUST be configurable to 3374 block unauthorized signaling messages. 3376 5.3.2. Flooding with EXT messages from inside 3378 Although we are more concerned with possible attacks from outside the 3379 network, we need also to consider possible attacks from inside the 3380 network. 3382 An adversary inside the network could send arbitrary EXTERNAL 3383 messages. At a certain point the NAT will run out of port numbers 3384 and the access for other users to the outside will be disabled. 3386 SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state 3387 creation for the EXTERNAL message. Furthermore, the NAT/FW NSLP 3388 implementation MUST prevent denial of service attacks involving 3389 the allocation of an arbitrary number of NAT bindings or the 3390 installation of a large number of packet filters. 3392 5.4. Man-in-the-Middle Attacks 3394 Figure 38 illustrates a possible man-in-the-middle attack using the 3395 EXTERNAL (EXT) message. This message travels from DR towards the 3396 public Internet. The message might not be intercepted because there 3397 are no NSIS aware middleboxes. 3399 Imagine such an NSIS signaling message is then intercepted by an 3400 adversary Mallory (M). M returns a faked RESPONSE message whereby 3401 the adversary pretends that a NAT binding was created. This NAT 3402 binding is returned with the RESPONSE message. Mallory might insert 3403 it own IP address in the response, the IP address of a third party or 3404 the address of a black hole. In the first case, the DR thinks that 3405 the address of Mallory M is its public address and will inform the DS 3406 about it. As a consequence, the DS will send the data traffic to 3407 Mallory M. 3409 The data traffic from the DS to the DR will re-directed to Mallory M. 3410 M will be able to read, modify or block the data traffic (if the end- 3411 to-end communication itself does not experience protection). 3412 Eavesdropping and modification is only possible if the data traffic 3413 is itself unprotected. 3415 +-----+ +-----+ +-----+ 3416 | DS | | M | | DR | 3417 +-----+ +-----+ +-----+ 3418 | | | 3419 | | EXT | 3420 | | <------------------ | 3421 | | | 3422 | | RESPONSE | 3423 | | ------------------> | 3424 | | | 3425 | data traffic | | 3426 |===============>| data traffic | 3427 | |====================>| 3429 Figure 38: MITM attack using the EXTERNAL message 3431 SECURITY REQUIREMENT: Mutual authentication between neighboring 3432 NATFW NSLP MUST be provided. To ensure that only legitimate nodes 3433 along the path act as NSIS entities the initiator MUST authorize 3434 the responder. In the example in Figure 38 the firewall FW must 3435 perform an authorization with the neighboring entities. 3437 5.5. Message Modification by non-NSIS on-path node 3439 An unauthorized on-path node along the path towards the destination 3440 could easily modify, inject or just drop an NSIS message. It could 3441 also hijack or disrupt the communication. 3443 SECURITY REQUIREMENT: Message integrity, replay protection and data 3444 origin authentication between neighboring NAT/FW NSLPs MUST be 3445 provided. 3447 5.6. Message Modification by malicious NSIS node 3449 Message modification by an NSIS node that became malicious is more 3450 serious. An adversary could easily create arbitrary pinholes or NAT 3451 bindings. For example: 3453 o NATs need to modify the source/destination of the data flow in the 3454 'create session' message. 3456 o Each middlebox along the path may change the requested lifetime in 3457 the CREATE message to fit their needs and/or local policy. 3459 SECURITY REQUIREMENT: Malicious NSIS NATs and firewalls will not be 3460 addressed by this specification. 3462 5.7. Signaling Session Ownership 3464 Section 4.10 in [8] describes a threat where an adversary is able to 3465 modify or delete previously installed state information at NATFW NSLP 3466 nodes along the path. An adversary therefore needs to know NATFW 3467 NSLP signaling session specific information, such as the NATFW NSLP 3468 signaling session identifier and MRI information. 3470 SECURITY REQUIREMENT: Off-path adversaries MUST NOT be able to 3471 modify or delete sessions without proper authorization. 3473 5.7.1. Misuse of Mobility in a NAT Handling Scenario 3475 Another kind of NATFW NSLP signaling session modification is related 3476 to mobility scenarios. The NSIS protocol suite offers interworking 3477 with mobility protocol and a mobile node might need to update state 3478 along NATFW NSLP nodes. 3480 Whenever a host behind a NAT initiates a data transfer, it is 3481 assigned an external IP and port number. In typical mobility 3482 scenarios, the DR might also obtain a new address according to the 3483 topology and it should convey its new IP address to the NAT. The NAT 3484 is assumed to modify these NAT bindings based on the new IP address 3485 conveyed by the end host. 3487 Public Private Address 3488 Internet space 3490 +----------+ +----------+ 3491 +----------| NAT |------------------|End host | 3492 | | | | 3493 +----------+ +----------+ 3494 | 3495 | +----------+ 3496 \--------------------|Malicious | 3497 |End host | 3498 +----------+ 3499 data traffic 3500 <======================== 3502 Figure 39: Misuse of mobility in NAT binding 3504 A NAT binding can be changed with the help of NSIS signaling. When a 3505 DR moves to a new location and obtains a new IP address, it sends an 3506 NSIS signaling message to modify the NAT binding. It would use the 3507 Session-ID and the new flow-id to update the state. The NAT updates 3508 the binding and the DR continues to receive the data traffic. 3509 Consider the scenario in Figure 39 where an the end host(DR) and the 3510 adversary are behind a NAT. The adversary pretending that it is the 3511 end host could generate a spurious signaling message to update the 3512 state at the NAT. This could be done for these purposes: 3514 o Redirecting packets to the attacker as in Figure 40. 3516 o Third party flooding by redirecting packets to arbitrary hosts 3518 o Service disruption by redirecting to non-existing hosts 3520 +----------+ +----------+ +----------+ 3521 | NAT | |End host | |Malicious | 3522 | | | | |End host | 3523 +----------+ +----------+ +----------+ 3524 | | | 3525 | Data Traffic | | 3526 |--------->----------| | 3527 | | Spurious | 3528 | | NAT binding update | 3529 |---------<----------+--------<------------| 3530 | | | 3531 | Data Traffic | | 3532 |--------->----------+-------->------------| 3533 | | | 3535 Figure 40: Connection Hijacking 3537 SECURITY REQUIREMENT: A NAT/FW signaling message MUST be 3538 authenticated, integrity and replay protected between neighboring 3539 NAT/FW NSLP nodes. The NSIS NATFW NSLP aware NAT MUST authorize 3540 the end host to insure that the messages are indeed belonging to 3541 the previously established NATFW NSLP signaling session. 3543 5.8. Misuse of unreleased signaling sessions 3545 Assume that DS (N1) initiates NATFW NSLP signaling session with DR 3546 (N2) through a series of middleboxes as in Figure 41. When the DS is 3547 sending data to DR, it might happen that the DR disconnects from the 3548 network (crashes or moves out of the network in mobility scenarios). 3549 In such cases, it is possible that another node N3 (which recently 3550 entered the network protected by the same firewall) is assigned the 3551 same IP address that was previously allocated to N2. The DS could 3552 take advantage of the firewall policies installed already, if the 3553 refresh interval time is very high. The DS can flood the node (N3), 3554 which will consume the access network resources of the victim forcing 3555 it to pay for unwanted traffic as shown in Figure 42. Note that here 3556 we make the assumption that the data receiver has to pay for 3557 receiving data packets. 3559 Public Internet 3560 +--------------------------+ 3561 | | 3562 +-------+ CREATE +---+-----+ +-------+ | 3563 | |-------------->------| |---->---| | | 3564 | N1 |--------------<------| FW |----<---| N2 | | 3565 | | successful RESPONSE | | | | | 3566 | |==============>======| |====>===| | | 3567 +-------+ Data Traffic +---+-----+ +-------+ | 3568 | | 3569 +--------------------------+ 3571 Figure 41: Before mobility 3573 Public Internet 3574 +--------------------------+ 3575 | | 3576 +-------+ +---+-----+ +-------+ | 3577 | | | | | | | 3578 | N1 |==============>======| FW |====>===| N3 | | 3579 | | Data Traffic | | | | | 3580 +-------+ +---+-----+ +-------+ | 3581 | | 3582 +--------------------------+ 3584 Figure 42: After mobility 3586 Also, this threat is valid for the other direction as well. The DS 3587 which is communicating with the DR may disconnect from the network 3588 and this IP address may be assigned to a new node that had recently 3589 entered the network. This new node could pretend to be the DS and 3590 send data traffic to the DR in conformance with the firewall policies 3591 and cause service disruption. 3593 SECURITY REQUIREMENT: In order to allow firewalls to verify that a 3594 legitimate end host indeed transmitted data traffic it is 3595 necessary to provide data origin authentication. This is, 3596 however, outside the scope of this document. Hence, there are no 3597 security requirements imposed by this threat, which will be 3598 addressed by the NATFW NSLP. 3600 5.9. Data Traffic Injection 3602 In some environments, such as enterprise networks, it is still common 3603 to perform authorization for access to a service based on the source 3604 IP address of the service requester. There is no doubt that this 3605 practice by itself represents a security weakness. Using IP spoofing 3606 an adversary is able to reach the target machines if they match, 3607 using the existing firewall rules. 3609 The adversary is able to inject its own data traffic in conformance 3610 with the firewall policies simultaneously along with the genuine DS. 3612 SECURITY REQUIREMENT: Since IP spoofing is a general limitation of 3613 non-cryptographic packet filters no countermeasures need to be 3614 taken by the NAT/FW NSLP. Techniques such as ingress filtering 3615 (see [19]) and, if necessary, data origin authentication (such as 3616 provided with IPsec based VPNs) can help mitigate this threat. 3617 This aspect is, however, outside the scope of this document. 3619 5.10. Eavesdropping and Traffic Analysis 3621 By collecting NSLP messages, an adversary is able to learn policy 3622 rules for packet filters and knows which ports are open. It can use 3623 this information to inject its own data traffic due to the IP 3624 spoofing capability already mentioned in Section 5.9. An on-path 3625 adversary could also observe the data traffic and he could conclude 3626 that it is possible to traverse a firewall. 3628 An adversary could learn authorization tokens included in CREATE 3629 messages and use them to launch replay-attacks or to create a NATFW 3630 NSLP signaling session with its own address as source address. This 3631 threat is discussed in the respective document suggesting the usage 3632 of authorization token in the NSIS protocol suite. 3634 SECURITY REQUIREMENT: The threat of eavesdropping itself does not 3635 mandate the usage of confidentiality protection since an adversary 3636 can also eavesdrop on data traffic. In the context of a 3637 particular security solutions (e.g., authorization tokens) it MAY 3638 be necessary to offer confidentiality protection. The latter 3639 aspect is outside the scope of this document. 3641 5.11. Security Framework for the NAT/Firewall NSLP 3643 Based on the identified threats a list of security requirements has 3644 been created. 3646 5.11.1. Security Protection between neighboring NATFW NSLP Nodes 3648 Based on the analyzed threats it is necessary to provide, between 3649 neighboring NATFW NSLP nodes, the following mechanism: 3651 o data origin authentication 3653 o replay protection 3655 o integrity protection and 3657 o optionally confidentiality protection 3659 To consider the aspect of authentication and key exchange the 3660 security mechanisms provided in [2] between neighboring nodes MUST be 3661 enabled when sending NATFW signaling messages. The proposed security 3662 mechanisms at GIST provide support for authentication and key 3663 exchange in addition to denial of service protection. Depending on 3664 the chosen security protocol, support for multiple authentication 3665 protocols might be provided. If security between neighboring nodes 3666 is desired then the usage of C-MODE for the delivery of data packets 3667 and the usage of D-MODE only to discover the next NATFW NSLP aware 3668 node along the path is demanded. Almost all security threats at the 3669 NATFW NSLP layer can be prevented by using a mutually authenticated 3670 Transport Layer secured connection and by relying on authorization by 3671 the neighboring NATFW NSLP entities. 3673 The NATFW NSLP relies an established security association between 3674 neighboring peers to prevent unauthorized nodes to modify or delete 3675 installed state. Between non-neighboring nodes the session ID (SID) 3676 carried in the NTLP is used to show ownership of a NATFW NSLP 3677 signaling session. The session ID MUST be generated in a random way 3678 and thereby prevent an off-path adversary to mount targeted attacks. 3679 Hence, an adversary would have to learn the randomly generated 3680 Session ID to perform an attack. In a mobility environment a former 3681 on-path node that is now off-path can perform an attack. The cost- 3682 benefit tradeoff to counter this attack does not seem to be high 3683 enough to provide a solution. Messages for a particular NATFW NSLP 3684 signaling session are handled by the NTLP to the NATFW NSLP for 3685 further processing. Messages carrying a different session ID not 3686 associated with any NATFW NSLP are subject to the regular processing 3687 for new NATFW NSLP signaling sessions. 3689 5.11.2. Security Protection between non-neighboring NATFW NSLP Nodes 3691 Based on the security threats and the listed requirements it was 3692 noted that some threats also demand authentication and authorization 3693 of a NATFW signaling entity (including the initiator) towards a non- 3694 neighboring node. This mechanism mainly demands entity 3695 authentication. Additionally, security protection of certain 3696 payloads may be required between non-neighboring signaling entities 3697 and the Cryptographic Message Syntax (CMS) [14] migh be a potential 3698 solution. Payload protection using CMS is not described in this 3699 document. The most important information exchanged at the NATFW NSLP 3700 is information related to the establishment for firewall pinholes and 3701 NAT bindings. This information can, however, not be protected over 3702 multiple NSIS NATFW NSLP hops since this information might change 3703 depending on the capability of each individual NATFW NSLP node. 3705 Some scenarios might also benefit from the usage of authorization 3706 tokens. Their purpose is to associate two different signaling 3707 protocols (e.g., SIP and NSIS) and their authorization decision. 3708 These tokens are obtained by non-NSIS protocols, such as SIP or as 3709 part of network access authentication. When a NAT or firewall along 3710 the path receives the token it might be verified locally or passed to 3711 the AAA infrastructure. Examples of authorization tokens can be 3712 found in RFC 3520 [17] and RFC 3521 [18]. Figure 43 shows an example 3713 of this protocol interaction. 3715 An authorization token is provided by the SIP proxy, which acts as 3716 the assertion generating entity and gets delivered to the end host 3717 with proper authentication and authorization. When the NATFW 3718 signaling message is transmitted towards the network, the 3719 authorization token is attached to the signaling messages to refer to 3720 the previous authorization decision. The assertion verifying entity 3721 needs to process the token or it might be necessary to interact with 3722 the assertion granting entity using HTTP (or other protocols). As a 3723 result of a successfully authorization by a NATFW NSLP node, the 3724 requested action is executed and later a RESPONSE message is 3725 generated. 3727 +----------------+ Trust Relationship +----------------+ 3728 | +------------+ |<.......................>| +------------+ | 3729 | | Protocol | | | | Assertion | | 3730 | | requesting | | HTTP, SIP Request | | Granting | | 3731 | | authz | |------------------------>| | Entity | | 3732 | | assertions | |<------------------------| +------------+ | 3733 | +------------+ | Artifact/Assertion | Entity Cecil | 3734 | ^ | +----------------+ 3735 | | | ^ ^| 3736 | | | . || HTTP, 3737 | | | Trust . || other 3738 | API Access | Relationship. || protocols 3739 | | | . || 3740 | | | . || 3741 | | | v |v 3742 | v | +----------------+ 3743 | +------------+ | | +------------+ | 3744 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3745 | | using authz| | Assertion/Artifact | | Verifying | | 3746 | | assertion | | ----------------------- | | Entity | | 3747 | +------------+ | | +------------+ | 3748 | Entity Alice | <---------------------- | Entity Bob | 3749 +----------------+ RESPONSE +----------------+ 3751 Figure 43: Authorization Token Usage 3753 Threats against the usage of authorization tokens have been mentioned 3754 in [8] and also in Section 5.2. Hence, it is required to provide 3755 confidentiality protection to avoid allowing an eavesdropper to learn 3756 the token and to use it in another NATFW NSLP signaling session 3757 (replay attack). The token itself also needs to be protected against 3758 tempering. 3760 To harmonize the usage of authorization tokens in NSLPs a separate 3761 document is available, see [21]. 3763 6. IAB Considerations on UNSAF 3765 UNilateral Self-Address Fixing (UNSAF) is described in [12] as a 3766 process at originating endpoints that attempt to determine or fix the 3767 address (and port) by which they are known to another endpoint. 3768 UNSAF proposals, such as STUN [15] are considered as a general class 3769 of workarounds for NAT traversal and as solutions for scenarios with 3770 no middlebox communication. 3772 This memo specifies a path-coupled middlebox communication protocol, 3773 i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are 3774 not intended as a short-term workaround, but more as a long-term 3775 solution for middlebox communication. In NSIS, endpoints are 3776 involved in allocating, maintaining, and deleting addresses and ports 3777 at the middlebox. However, the full control of addresses and ports 3778 at the middlebox is at the NATFW NSLP daemon located to the 3779 respective NAT. 3781 Therefore, this document addresses the UNSAF considerations in [12] 3782 by proposing a long-term alternative solution. 3784 7. IANA Considerations 3786 This section provides guidance to the Internet Assigned Numbers 3787 Authority (IANA) regarding registration of values related to the 3788 NATFW NSLP, in accordance with BCP 26 RFC 2434 [13]. 3790 The NATFW NSLP requires IANA to create a number of new registries. 3791 These registries may require further coordination with the registries 3792 of the NTLP [2] and the QoS NSLP [6]. 3794 NATFW NSLP Message Type Registry 3796 The NATFW NSLP Message Type is a 8 bit value. The allocation of 3797 values for new message types requires standards action. Updates and 3798 deletion of values from the registry is not possible. This 3799 specification defines four NATFW NSLP message types, which form the 3800 initial contents of this registry. IANA is requested to add these 3801 four NATFW NSLP Message Types: CREATE, EXT, RESPONSE, and NOTIFY. 3803 NATFW NSLP Header Flag Registry 3805 NATFW NSLP messages have a messages-specific 8 bit flags/reserved 3806 field in their header. The registration of flags is subject to IANA 3807 registration. The allocation of values for flag types requires 3808 standards action. Updates and deletion of values from the registry 3809 is not possible. This specification defines only one flag, the P 3810 flag in Figure 20. 3812 NSLP Object Type Registry 3814 [Delete this part if already done by another NSLP: 3816 A new registry is to be created for NSLP Message Objects. This is a 3817 12-bit field (giving values from 0 to 4095). This registry is shared 3818 between a number of NSLPs. Allocation policies are as follows: 3820 0-1023: Standards Action 3822 1024-1999: Specification Required 3824 2000-2047: Private/Experimental Use 3826 2048-4095: Reserved 3828 When a new object is defined, the extensbility bits (A/B) must also 3829 be defined.] 3831 This document defines 8 objects for the NATFW NSLP: NATFW_LT, 3832 NATFW_EXT_IP, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, 3833 NATFW_DTINFO, NATFW_ICMP_TYPES. IANA is request to assigned values 3834 for them from NSLP Object Type registry and to replace the 3835 corresponding IANA-TBD tags with the numeric values. 3837 NSLP Response Code Registry 3839 In addition it defines a number of Response Codes for the NATFW NSLP. 3840 These can be found in Section 4.2.4 and are to be assigned values 3841 from NSLP Response Code registry. The allocation of values for 3842 Response Codes Codes requires standards action. IANA is request to 3843 assigned values for them from NSLP Response Code registry. 3845 Furthermore, IANA is requested to add a new value to the NSLP 3846 Identifiers (NSLPID) registry defined in [2] for the NATFW NSLP. 3848 8. Open Issues 3850 A more detailed list of open issue can be found at: 3851 https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/index 3853 9. Acknowledgments 3855 We would like to thank the following individuals for their 3856 contributions to this document at different stages: 3858 o Marcus Brunner and Henning Schulzrinne for work on work on IETF 3859 drafts which lead us to start with this document, 3861 o Miquel Martin for his help on the initial version of this 3862 document, 3864 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3865 NAT/firewall threats draft, 3867 o Henning Peters for his comments and suggestions, 3869 o and the NSIS working group. 3871 10. References 3873 10.1. Normative References 3875 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3876 Levels", BCP 14, RFC 2119, March 1997. 3878 [2] Schulzrinne, H. and R. Hancock, "GIST: General Internet 3879 Signaling Transport", draft-ietf-nsis-ntlp-11 (work in 3880 progress), August 2006. 3882 [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 3883 August 1996. 3885 10.2. Informative References 3887 [4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3888 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 3889 June 2005. 3891 [5] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 3892 April 2004. 3894 [6] Manner, J., "NSLP for Quality-of-Service Signaling", 3895 draft-ietf-nsis-qos-nslp-12 (work in progress), October 2006. 3897 [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 3898 Rayhan, "Middlebox communication architecture and framework", 3899 RFC 3303, August 2002. 3901 [8] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 3902 Steps in Signaling (NSIS)", RFC 4081, June 2005. 3904 [9] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 3905 (NAT) Terminology and Considerations", RFC 2663, August 1999. 3907 [10] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 3908 RFC 3234, February 2002. 3910 [11] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 3911 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3912 Specification", RFC 2205, September 1997. 3914 [12] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 3915 Address Fixing (UNSAF) Across Network Address Translation", 3916 RFC 3424, November 2002. 3918 [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3919 Considerations Section in RFCs", BCP 26, RFC 2434, 3920 October 1998. 3922 [14] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, 3923 July 2004. 3925 [15] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 3926 - Simple Traversal of User Datagram Protocol (UDP) Through 3927 Network Address Translators (NATs)", RFC 3489, March 2003. 3929 [16] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 3930 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and 3931 S. Waldbusser, "Terminology for Policy-Based Management", 3932 RFC 3198, November 2001. 3934 [17] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 3935 Authorization Policy Element", RFC 3520, April 2003. 3937 [18] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session 3938 Set-up with Media Authorization", RFC 3521, April 2003. 3940 [19] Ferguson, P. and D. Senie, "Network Ingress Filtering: 3941 Defeating Denial of Service Attacks which employ IP Source 3942 Address Spoofing", BCP 38, RFC 2827, May 2000. 3944 [20] Alfano, F., "Diameter Quality of Service Application", 3945 draft-alfano-aaa-qosprot-05 (work in progress), October 2005. 3947 [21] Manner, J., "Authorization for NSIS Signaling Layer Protocols", 3948 draft-manner-nsis-nslp-auth-02 (work in progress), 3949 October 2006. 3951 [22] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as 3952 firewall Signalling Protocol", Proceedings of the 6th IEEE 3953 Symposium on Computers and Communications, Hammamet, 3954 Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001. 3956 Appendix A. Selecting Signaling Destination Addresses for EXT 3958 As with all other message types, EXT messages need a reachable IP 3959 address of the data sender on the GIST level. For the path-coupled 3960 MRM the source-address of GIST is the reachable IP address (i.e., the 3961 real IP address of the data sender, or a wildcard). While this is 3962 straight forward, it is not necessarily so for the loose-end MRM. 3963 Many applications do not provide the IP address of the communication 3964 counterpart, i.e., either the data sender or both a data sender and 3965 receiver. For the EXT messages, the case of data sender is of 3966 interest only. The rest of this section is giving informational 3967 guidance about determining a good destination-address of the LE-MRM 3968 in GIST for EXT messages. 3970 This signaling destination address (SDA, the destination-address in 3971 GIST) can be the data sender, but for applications which do not 3972 provide an address upfront, the destination address has to be chosen 3973 independently, as it is unknown at the time when the NATFW NSLP 3974 signaling has to start. Choosing the 'correct' destination IP 3975 address may be difficult and it is possible that there is no 'right 3976 answer' for all applications relying on the NATFW NSLP. 3978 Whenever possible it is RECOMMENDED to chose the data sender's IP 3979 address as SDA. It necessary to differentiate between the received 3980 IP addresses on the data sender. Some application level signaling 3981 protocols (e.g., SIP) have the ability to transfer multiple contact 3982 IP addresses of the data sender. For instance, private IP address, 3983 public IP address at NAT, and public IP address at a relay. It is 3984 RECOMMENDED to use all non-private IP addresses as SDAs. 3986 A different SDA must be chosen, should the IP address of the data 3987 sender be unknown. This can have multiple reasons: The application 3988 level signaling protocol cannot determine any data sender IP address 3989 at this point of time or the data receiver is server behind a NAT, 3990 i.e., accepting inbound packets from any host. In this case, the 3991 NATFW NSLP can be instructed to use the public IP address of an 3992 application server or any other node. Choosing the SDA in this case 3993 is out of the scope of the NATFW NSLP and depends on the 3994 application's choice. The local network can provide a network-SDA, 3995 i.e., a SDA which is only meaningful to the local network. This will 3996 ensure that GIST packets with destination-address set to this 3997 network-SDA are going to be routed to a edge-NAT or edge-firewall. 3999 Appendix B. Applicability Statement on Data Receivers behind Firewalls 4001 Section 3.7.2 describes how data receivers behind middleboxes can 4002 instruct inbound firewalls/NATs to forward NATFW NSLP signaling 4003 towards them. Finding an inbound edge-NAT in address environment 4004 with NAT'ed addresses is quite easy. It is only required to find 4005 some edge-NAT, as the data traffic will be route-pinned to the NAT, 4006 which is done with the LE-MRM. Locating the appropriate edge- 4007 firewall with the PC-MRM, sent inbound is difficult. For cases with 4008 a single, symmetric route from the Internet to the data receiver, it 4009 is quite easy; simply follow the default route in the inbound 4010 direction. 4012 +------+ Data Flow 4013 +-------| EFW1 +----------+ <=========== 4014 | +------+ ,--+--. 4015 +--+--+ / \ 4016 NI+-----| FW1 | (Internet )----NR+/NI/DS 4017 NR +--+--+ \ / 4018 | +------+ `--+--' 4019 +-------| EFW2 +----------+ 4020 +------+ 4022 ~~~~~~~~~~~~~~~~~~~~~> 4023 Signaling Flow 4025 Figure 44: Data receiver behind multiple, parallel located firewalls 4027 When a data receiver, and thus NR, is located in a network site that 4028 is multihomed with several independently firewalled connections to 4029 the public Internet (as shown in Figure 44), the specific firewall 4030 through which the data traffic will be routed has to be ascertained. 4031 NATFW NSLP signaling messages sent from the NI+/NR during the EXT 4032 message exchange towards the NR+ must be routed by the NTLP to the 4033 edge-firewall that will be passed by the data traffic as well. The 4034 NTLP would need to be aware about the routing within the Internet to 4035 determine the path between DS and DR. Out of this, the NTLP could 4036 determine which of the edge-firewalls, either EFW1 or EFW2, must be 4037 selected to forward the NATFW NSLP signaling. Signaling to the wrong 4038 edge-firewall, as shown in Figure 44, would install the NATFW NSLP 4039 policy rules at the wrong device. This causes either a blocked data 4040 flow (when the policy rule is 'allow') or an ongoing attack (when the 4041 policy rule is 'deny'). Requiring the NTLP to know all about the 4042 routing within the Internet is definitely a tough challenge and 4043 usually not possible. In such described case, the NTLP must 4044 basically give up and return an error to the NSLP level, indicating 4045 that the next hop discovery is not possible. 4047 Appendix C. Firewall and NAT Resources 4049 This section gives some examples on how NATFW NSLP policy rules could 4050 be mapped to real firewall or NAT resources. The firewall rules and 4051 NAT bindings are described in a natural way, i.e., in a way one will 4052 find it in common implementation. 4054 C.1. Wildcarding of Policy Rules 4056 The policy rule/MRI to be installed can be wildcarded to some degree. 4057 Wildcarding applies to IP address, transport layer port numbers, and 4058 the IP payload (or next header in IPv6). Processing of wildcarding 4059 splits into the NTLP and the NATFW NSLP layer. The processing at the 4060 NTLP layer is independent of the NSLP layer processing and per layer 4061 constraints apply. For wildcarding in the NTLP see Section 5.8 of 4062 [2]. 4064 Wildcarding at the NATFW NSLP level is always a node local policy 4065 decision. A signaling message carrying a wildcarded MRI (and thus 4066 policy rule) arriving at an NSLP node can be rejected if the local 4067 policy does not allow the request. For instance, a MRI with IP 4068 addresses set (not wildcarded), transport protocol TCP, and TCP port 4069 numbers completely wildcarded. Now the local policy allows only 4070 requests for TCP with all ports set and not wildcarded. The request 4071 is going to be rejected. 4073 C.2. Mapping to Firewall Rules 4075 This section describes how a NSLP policy rule signaled with a CREATE 4076 message is mapped to a firewall rule. The MRI is set as follows: 4078 o network-layer-version=IPv4 4080 o source-address=192.0.2.100, prefix-length=32 4082 o destination-address=192.0.50.5, prefix-length=32 4084 o IP-protocol=UDP 4086 o L4-source-port=34543, L4-destination-port=23198 4088 The NATFW_EFI object is set to action=allow and sub_ports=0. 4090 The resulting policy rule (firewall rule) to be installed might look 4091 like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198 4093 C.3. Mapping to NAT Bindings 4095 This section describes how a NSLP policy rule signaled with a EXT 4096 message is mapped to a NAT binding. It is assumed that the EXT 4097 message is sent by a NI+ being located behind a NAT and does contain 4098 a NATFW_DTINFO object. The MRI is set following using the signaling 4099 destination address, since the IP address of the real data sender is 4100 not known: 4102 o network-layer-version=IPv4 4104 o source-address= 192.168.5.100 4106 o destination-address=SDA 4108 o IP-protocol=UDP 4110 The NATFW_EFI object is set to action=allow and sub_ports=0. The 4111 NATFW_DTINFO object contains these parameters: 4113 o P=1 4115 o dest prefix=0 4117 o protocol=UDP 4119 o dst port number = 20230, src port number=0 4121 o src IP=0.0.0.0 4123 The edge-NAT allocates the external IP 192.0.2.79 and port 45000. 4125 The resulting policy rule (NAT binding) to be installed could look 4126 like: translate from any to 192.0.2.79 port=45000 to 192.168.5.100 4127 port=20230 4129 C.4. NSLP Handling of Twice-NAT 4131 The dynamic configuration of twice-NATs requires application level 4132 support, as stated in Section 2.5. The NATFW NSLP cannot be used for 4133 configuring twice-NATs if application level support is needed. 4134 Assuming application level support performing the configuration of 4135 the twice-NAT and the NATFW NSLP being installed at this devices, the 4136 NATFW NSLP must be able to traverse it. The NSLP is probably able to 4137 traverse the twice-NAT, as any other data traffic, but the flow 4138 information stored in the NTLP's MRI will be invalidated through the 4139 translation of source and destination address. The NATFW NSLP 4140 implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP 4141 signaling messages as any other NATFW NSLP node does. For the given 4142 signaling flow, the NATFW NSLP node MUST look up the corresponding IP 4143 address translation and modify the NTLP/NSLP signaling accordingly. 4144 The modification results in an updated MRI with respect to the source 4145 and destination IP addresses. 4147 Appendix D. Assigned Numbers for Testing 4149 NOTE: This section MUST be removed before publication. 4151 This section defines temporarily used values of the NATFW NSLP for 4152 testing the different implementations. 4154 Values for the NATFW NSLP message types: 4156 o CREATE: 0x01 4158 o EXT: 0x02 4160 o RESPONSE: 0x03 4162 o NOTIFY: 0x04 4164 Values for the NSLP object types 4166 o NATFW_LT: 0x00F1 4168 o NATFW_EXT_IP: 0x00F2 4170 o NATFW_EFI: 0x00F3 4172 o NATFW_INFO: 0x00F4 4174 o NATFW_NONCE: 0x00F5 4176 o NATFW_MSN: 0x00F6 4178 o NATFW_DTINFO: 0x00F7 4180 o NATFW_ICMP_TYPES: 0x00F9 4182 1345 4184 Authors' Addresses 4186 Martin Stiemerling 4187 Network Laboratories, NEC Europe Ltd. 4188 Kurfuersten-Anlage 36 4189 Heidelberg 69115 4190 Germany 4192 Phone: +49 (0) 6221 4342 113 4193 Email: stiemerling@netlab.nec.de 4194 URI: http://www.stiemerling.org 4196 Hannes Tschofenig 4197 Siemens AG 4198 Otto-Hahn-Ring 6 4199 Munich 81739 4200 Germany 4202 Phone: 4203 Email: Hannes.Tschofenig@siemens.com 4204 URI: http://www.tschofenig.com 4206 Cedric Aoun 4207 Paris 4208 France 4210 Email: cedric@caoun.net 4212 Elwyn Davies 4213 Folly Consulting 4214 Soham 4215 UK 4217 Phone: +44 7889 488 335 4218 Email: elwynd@dial.pipex.com 4220 Full Copyright Statement 4222 Copyright (C) The IETF Trust (2007). 4224 This document is subject to the rights, licenses and restrictions 4225 contained in BCP 78, and except as set forth therein, the authors 4226 retain all their rights. 4228 This document and the information contained herein are provided on an 4229 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4230 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4231 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4232 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4233 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4234 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4236 Intellectual Property 4238 The IETF takes no position regarding the validity or scope of any 4239 Intellectual Property Rights or other rights that might be claimed to 4240 pertain to the implementation or use of the technology described in 4241 this document or the extent to which any license under such rights 4242 might or might not be available; nor does it represent that it has 4243 made any independent effort to identify any such rights. Information 4244 on the procedures with respect to rights in RFC documents can be 4245 found in BCP 78 and BCP 79. 4247 Copies of IPR disclosures made to the IETF Secretariat and any 4248 assurances of licenses to be made available, or the result of an 4249 attempt made to obtain a general license or permission for the use of 4250 such proprietary rights by implementers or users of this 4251 specification can be obtained from the IETF on-line IPR repository at 4252 http://www.ietf.org/ipr. 4254 The IETF invites any interested party to bring to its attention any 4255 copyrights, patents or patent applications, or other proprietary 4256 rights that may cover technology that may be required to implement 4257 this standard. Please address the information to the IETF at 4258 ietf-ipr@ietf.org. 4260 Acknowledgment 4262 Funding for the RFC Editor function is provided by the IETF 4263 Administrative Support Activity (IASA).