idnits 2.17.1 draft-ietf-nsis-nslp-natfw-12.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 on line 4301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4291. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 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 REA_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 session only if a REA-PROXY refresh message 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 (June 27, 2006) is 6511 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) -- Looks like a reference, but probably isn't: 'M' on line 3026 -- Looks like a reference, but probably isn't: 'O' on line 2992 -- Looks like a reference, but probably isn't: 'RFC3489' on line 3839 -- Looks like a reference, but probably isn't: 'RFC3424' on line 3853 == Unused Reference: '12' is defined on line 3966, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 3974, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 3989, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '2') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-10 -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '10') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '16') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '17') (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '19') (Obsoleted by RFC 5389) == Outdated reference: A later version (-04) exists of draft-manner-nsis-nslp-auth-01 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 16 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 Expires: December 29, 2006 H. Tschofenig 5 Siemens 6 C. Aoun 7 ENST 8 E. Davies 9 Folly Consulting 10 June 27, 2006 12 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 13 draft-ietf-nsis-nslp-natfw-12.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 December 29, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . 9 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. IPv4/v6 NAT with two Private Networks . . . . . . . . . . 18 72 2.8. Multihomed Network with NAT . . . . . . . . . . . . . . . 19 73 2.9. Multihomed Network with Firewall . . . . . . . . . . . . 19 75 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 21 76 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . 21 77 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21 78 3.2.1. Message Types . . . . . . . . . . . . . . . . . . . . 25 79 3.2.2. Classification of RESPONSE Messages . . . . . . . . . 26 80 3.2.3. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26 81 3.3. Basic Message Processing . . . . . . . . . . . . . . . . 27 82 3.4. Calculation of Session Lifetime . . . . . . . . . . . . . 27 83 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . 30 84 3.6. Authentication, Authorization, and Policy Decisions . . . 31 85 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 31 86 3.7.1. Creating Sessions . . . . . . . . . . . . . . . . . . 31 87 3.7.2. Reserving External Addresses . . . . . . . . . . . . 34 88 3.7.3. NATFW Session Refresh . . . . . . . . . . . . . . . . 41 89 3.7.4. Deleting Sessions . . . . . . . . . . . . . . . . . . 42 90 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 43 91 3.7.6. Tracing Signaling Sessions . . . . . . . . . . . . . 45 92 3.7.7. Proxy Mode of Operation . . . . . . . . . . . . . . . 46 93 3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 49 94 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 51 95 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 52 97 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 53 98 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 53 99 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . 54 100 4.2.1. Session Lifetime Object . . . . . . . . . . . . . . . 55 101 4.2.2. External Address Object . . . . . . . . . . . . . . . 55 102 4.2.3. Extended Flow Information Object . . . . . . . . . . 56 103 4.2.4. Information Code Object . . . . . . . . . . . . . . . 57 104 4.2.5. Nonce Object . . . . . . . . . . . . . . . . . . . . 60 105 4.2.6. Message Sequence Number Object . . . . . . . . . . . 60 106 4.2.7. Data Terminal Information Object . . . . . . . . . . 61 107 4.2.8. Trace Object . . . . . . . . . . . . . . . . . . . . 62 108 4.2.9. NI Credential Object . . . . . . . . . . . . . . . . 63 109 4.2.10. ICMP Types Object . . . . . . . . . . . . . . . . . . 63 110 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 64 111 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . 65 112 4.3.2. RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . 65 113 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . 66 114 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 67 115 4.3.5. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 67 117 5. Security Considerations . . . . . . . . . . . . . . . . . . . 68 118 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 68 119 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 68 120 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 69 121 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . 70 122 5.2. Security Threats and Requirements . . . . . . . . . . . . 71 123 5.2.1. Data Sender (DS) behind a firewall . . . . . . . . . 71 124 5.2.2. Data Sender (DS) behind a NAT . . . . . . . . . . . . 72 125 5.2.3. Data Receiver (DR) behind a firewall . . . . . . . . 72 126 5.2.4. Data Receiver (DR) behind a NAT . . . . . . . . . . . 74 127 5.2.5. NSLP Message Injection . . . . . . . . . . . . . . . 75 128 5.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 75 129 5.3.1. Flooding with CREATE messages from outside . . . . . 76 130 5.3.2. Flooding with REA messages from inside . . . . . . . 77 131 5.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 77 132 5.5. Message Modification by non-NSIS on-path node . . . . . . 78 133 5.6. Message Modification by malicious NSIS node . . . . . . . 78 134 5.7. Session Ownership . . . . . . . . . . . . . . . . . . . . 79 135 5.7.1. Misuse of Mobility in a NAT Handling Scenario . . . . 79 136 5.8. Misuse of unreleased sessions . . . . . . . . . . . . . . 80 137 5.9. Data Traffic Injection . . . . . . . . . . . . . . . . . 82 138 5.10. Eavesdropping and Traffic Analysis . . . . . . . . . . . 82 139 5.11. Security Framework for the NAT/Firewall NSLP . . . . . . 82 140 5.11.1. Security Protection between neighboring NATFW NSLP 141 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 83 142 5.11.2. Security Protection between non-neighboring NATFW 143 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . 83 145 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 86 147 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87 149 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 88 151 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 89 153 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 154 10.1. Normative References . . . . . . . . . . . . . . . . . . 90 155 10.2. Informative References . . . . . . . . . . . . . . . . . 90 157 Appendix A. Selecting Signaling Destination Addresses for REA . 93 159 Appendix B. Applicability Statement on Data Receivers behind 160 Firewalls . . . . . . . . . . . . . . . . . . . . . 95 162 Appendix C. Firewall and NAT Resources . . . . . . . . . . . . . 97 163 C.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 97 164 C.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 97 165 C.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 98 166 C.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . 98 168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100 169 Intellectual Property and Copyright Statements . . . . . . . . . 101 171 1. Introduction 173 Firewalls and Network Address Translators (NAT) have both been used 174 throughout the Internet for many years, and they will remain present 175 for the foreseeable future. Firewalls are used to protect networks 176 against certain types of attacks from internal networks and the 177 Internet, whereas NATs provide a virtual extension of the IP address 178 space. Both types of devices may be obstacles to some applications, 179 since they only allow traffic created by a limited set of 180 applications to traverse them, typically those that use protocols 181 with relatively predetermined and static properties (e.g., most HTTP 182 traffic, and other client/server applications). Other applications, 183 such as IP telephony and most other peer-to-peer applications, which 184 have more dynamic properties, create traffic that is unable to 185 traverse NATs and firewalls unassisted. In practice, the traffic of 186 many applications cannot traverse autonomous firewalls or NATs, even 187 when they have additional functionality which attempts to restore the 188 transparency of the network. 190 Several solutions to enable applications to traverse such entities 191 have been proposed and are currently in use. Typically, application 192 level gateways (ALG) have been integrated with the firewall or NAT to 193 configure the firewall or NAT dynamically. Another approach is 194 middlebox communication (MIDCOM). In this approach, ALGs external to 195 the firewall or NAT configure the corresponding entity via the MIDCOM 196 protocol [7]. Several other work-around solutions are available, 197 such as STUN [19]. However, all of these approaches introduce other 198 problems that are generally hard to solve, such as dependencies on 199 the type of NAT implementation (full-cone, symmetric, etc), or 200 dependencies on certain network topologies. 202 NAT and firewall (NATFW) signaling shares a property with Quality of 203 Service (QoS) signaling. The signaling of both must reach any device 204 on the data path that is involved in, respectively, NATFW or QoS 205 treatment of data packets. This means, that for both, NATFW and QoS, 206 it is convenient if signaling travels path-coupled, meaning that the 207 signaling messages follow exactly the same path that the data packets 208 take. RSVP [13] is an example of a current QoS signaling protocol 209 that is path-coupled. [26] proposes the use of RSVP as firewall 210 signaling protocol but does not include NATs. 212 This memo defines a path-coupled signaling protocol for NAT and 213 firewall configuration within the framework of NSIS, called the NATFW 214 NSIS Signaling Layer Protocol (NSLP). The general requirements for 215 NSIS are defined in [5] and the general framework of NSIS is outlined 216 in [4]. It introduces the split between an NSIS transport layer and 217 an NSIS signaling layer. The transport of NSLP messages is handled 218 by an NSIS Network Transport Layer Protocol (NTLP, with General 219 Internet Signaling Transport (GIST) [2] being the implementation of 220 the abstract NTLP). The signaling logic for QoS and NATFW signaling 221 is implemented in the different NSLPs. The QoS NSLP is defined in 222 [6]. 224 The NATFW NSLP is designed to request the dynamic configuration of 225 NATs and/or firewalls along the data path. Dynamic configuration 226 includes enabling data flows to traverse these devices without being 227 obstructed, as well as blocking of particular data flows at upstream 228 firewalls. Enabling data flows requires the loading of firewall 229 rules with an action that allows the data flow packets to be 230 forwarded and creating NAT bindings. Blocking of data flows requires 231 the loading of firewalls rules with an action that will deny 232 forwarding of the data flow packets. A simplified example for 233 enabling data flows: A source host sends a NATFW NSLP signaling 234 message towards its data destination. This message follows the data 235 path. Every NATFW NSLP-enabled NAT/firewall along the data path 236 intercepts these messages, processes them, and configures itself 237 accordingly. Thereafter, the actual data flow can traverse all these 238 configured firewalls/NATs. 240 It is necessary to distinguish between two different basic scenarios 241 when operating the NATFW NSLP, independent of the type of middlebox 242 to be configured. 244 1. Both, data sender and data receiver, are NSIS NATFW NSLP aware. 245 This includes the cases where the data sender is logically 246 decomposed from the NSIS initiator or the data receiver logically 247 decomposed from the NSIS receiver, but both sides support NSIS. 248 This scenario assumes deployment of NSIS all over the Internet, 249 or at least at all NATs and firewalls. This scenario is referred 250 as to end-to-end mode operation and is used as base assumption if 251 not otherwise noted. 253 2. Only one end host or region of the network is NSIS NATFW NSLP 254 aware, either data receiver or data sender. This scenario is 255 referred to as proxy mode operation. 257 NATFW NSLP provides two basic signaling modes which are sufficient to 258 cope with the various possible scenarios likely to be encountered 259 before and after widespread deployment of NSIS: 261 CREATE mode: The basic mode for configuring a path downstream from 262 a data sender to a data receiver. 264 RESERVE-EXTERNAL-ADDRESS (REA) mode: Used to locate upstream NATs/ 265 firewalls and prime them to expect downstream signaling and at 266 NATs to pre-allocate a public address. This is used for data 267 receivers behind these devices to enable their reachability. 269 Once there is full deployment of NSIS (i.e., end-to-end mode 270 operations are possible), the requisite NAT and firewall state can be 271 created using only CREATE mode. If the data receiver resides in a 272 private addressing realm, and needs to preconfigure the edge-NAT/ 273 edge-firewall to provide a (publicly) reachable address for use by 274 the data sender, a combination of RESERVE-EXTERNAL-ADDRESS and CREATE 275 modes is used. 277 During the introduction of NSIS, it is likely that one or other of 278 the data sender and receiver will not be NSIS aware. In these cases, 279 the NATFW NSLP can utilize NSIS aware middleboxes on the path between 280 the data sender and data receiver to provide proxy NATFW NSLP 281 services (i.e., proxy mode operation). Typically, these boxes will 282 be at the boundaries of the realms in which the end hosts are 283 located. 285 All modes of operation create NATFW NSLP and NTLP state in NSIS 286 entities. NTLP state allows signaling messages to travel in the 287 forward (downstream) and the reverse (upstream) direction along the 288 path between a NAT/firewall NSLP sender and a corresponding receiver. 289 This state is managed using a soft-state mechanism, i.e., it expires 290 unless it is refreshed from time to time. The NAT bindings and 291 firewall rules being installed during the state setup are bound to 292 the particular signaling session. However, the exact local 293 implementation of the NAT bindings and firewall rules are NAT/ 294 firewall specific. 296 This memo is structured as follows. Section 2 describes the network 297 environment for NATFW NSLP signaling. Section 3 defines the NATFW 298 signaling protocol and Section 4 defines the message components and 299 the overall messages used in the protocol. The remaining parts of 300 the main body of the document, covers security considerations 301 Section 5, IAB considerations on UNilateral Self-Address Fixing 302 (UNSAF) [15] in Section 6 and IANA considerations in Section 7. 303 Please note that readers familiar with firewalls and NATs and their 304 possible location within networks can safely skip Section 2. 306 1.1. Terminology and Abbreviations 308 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 309 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 310 document are to be interpreted as described in [1]. 312 This document uses a number of terms defined in [5] and [4]. The 313 following additional terms are used: 315 o Policy rule: A policy rule is "a basic building block of a policy- 316 based system. It is the binding of a set of actions to a set of 317 conditions - where the conditions are evaluated to determine 318 whether the actions are performed" [20]. In the context of NSIS 319 NATFW NSLP, the conditions are the specification of a set of 320 packets to which the rule is applied. The set of actions always 321 contains just a single element per rule, and is limited to either 322 action "deny" or action "allow". 324 o Reserved policy rule: A policy rule stored at NATs or firewalls 325 for activation by a later, different signaling exchange. This 326 type of policy rule is kept in the NATFW NSLP and is not loaded 327 into the firewall or NAT engine, i.e., it does not affect the data 328 flow handling. 330 o Installed policy rule: A policy rule in operation at NATs or 331 firewalls. This type of rule is kept in the NATFW NSLP and is 332 loaded into the firewall or NAT engine, i.e., it is affecting the 333 data flow. 335 o Remembered policy rule: A policy rule stored at NATs and firewalls 336 for immediate use, as soon as the signaling exchange is 337 successfully completed. 339 o Firewall: A packet filtering device that matches packets against a 340 set of policy rules and applies the actions. In the context of 341 NSIS NATFW NSLP we refer to this device as a firewall. 343 o Network Address Translator: Network Address Translation is a 344 method by which IP addresses are mapped from one IP address realm 345 to another, in an attempt to provide transparent routing between 346 hosts (see [9]). Network Address Translators are devices that 347 perform this work by modifying packets passing through them. 349 o Middlebox: "A middlebox is defined as any intermediate device 350 performing functions other than the normal, standard functions of 351 an IP router on the datagram path between a source host and a 352 destination host" [11]. In the context of this document, the term 353 middlebox refers to firewalls and NATs only. Other types of 354 middlebox are outside of the scope of this document. 356 o Data Receiver (DR): The node in the network that is receiving the 357 data packets of a flow. 359 o Data Sender (DS): The node in the network that is sending the data 360 packets of a flow. 362 o NATFW NSLP session or signaling session: An application layer flow 363 of information for which some network control state information is 364 to be manipulated or monitored (as defined in [4]). The control 365 state for NATFW NSLP consists of NSLP state and associated policy 366 rules at a middlebox. 368 o NSIS peer or peer: An NSIS node with which an NSIS adjacency has 369 been created as defined in [2]. 371 o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP 372 address which is reachable from the public Internet. 374 o Edge-firewall: An edge-firewall is a firewall device that is 375 located on the border line of an administrative domain. 377 o Public Network: "A Global or Public Network is an address realm 378 with unique network addresses assigned by Internet Assigned 379 Numbers Authority (IANA) or an equivalent address registry. This 380 network is also referred as external network during NAT 381 discussions" [9]. 383 o Private/Local Network: "A private network is an address realm 384 independent of external network addresses. Private network may 385 also be referred alternately as Local Network. Transparent 386 routing between hosts in private realm and external realm is 387 facilitated by a NAT router" [9]. 389 o Public/Global IP address: An IP address located in the public 390 network according to Section 2.7 of [9]. 392 o Private/Local IP address: An IP address located in the private 393 network according to Section 2.8 of [9]. 395 o Signaling Destination Address (SDA): An IP address generally taken 396 from the public/global IP address range, although, the SDA may in 397 certain circumstances be part of the private/local IP address 398 range. This address is used in REA signaling message exchanges, 399 if the data receiver's IP address is unknown. 401 1.2. Middleboxes 403 The term middlebox covers a range of devices which intercept the flow 404 of packets between end hosts and perform actions other than standard 405 forwarding expected in an IP router. As such, middleboxes fall into 406 a number of categories with a wide range of functionality, not all of 407 which is pertinent to the NATFW NSLP. Middlebox categories in the 408 scope of this memo are firewalls that filter data packets against a 409 set of filter rules, and NATs that translate packet addresses from 410 one address realm to another address realm. Other categories of 411 middleboxes, such as QoS traffic shapers, are out of scope of this 412 memo. 414 The term NAT used in this document is a placeholder for a range of 415 different NAT flavors. We consider the following types of NATs: 417 o Traditional NAT (basic NAT and NAPT) 419 o Bi-directional NAT 421 o Twice-NAT 423 o Multihomed NAT 425 For definitions and a detailed discussion about the characteristics 426 of each NAT type please see [9]. 428 All types of middleboxes under consideration here, use policy rules 429 to make a decision on data packet treatment. Policy rules consist of 430 a flow identifier which selects the packets to which the policy 431 applies and an associated action; data packets matching the flow 432 identifier are subjected to the policy rule action. A typical flow 433 identifier is the 5-tuple selector which matches the following fields 434 of a packet to configured values: 436 o Source and destination IP addresses 438 o Transport protocol number 440 o Transport source and destination port numbers 442 Actions for firewalls are usually one or more of: 444 o Allow: forward data packet 446 o Deny: block data packet and discard it 448 o Other actions such as logging, diverting, duplicating, etc 450 Actions for NATs include (amongst many others): 452 o Change source IP address and transport port number to a globally 453 routeable IP address and associated port number. 455 o Change destination IP address and transport port number to a 456 private IP address and associated port number. 458 It should be noted that a middlebox may contain two logical 459 representations of the policy rule. The policy rule has a 460 representation within the NATFW NSLP, comprising the message routing 461 information (MRI) of the NTLP and NSLP information (such as the rule 462 action). The other representation is the implementation of the NATFW 463 NSLP policy rule within the NAT and firewall engine of the particular 464 device. Refer to Appendix C for further details. 466 1.3. General Scenario for NATFW Traversal 468 The purpose of NSIS NATFW signaling is to enable communication 469 between endpoints across networks, even in the presence of NAT and 470 firewall middleboxes that have not been specially engineered to 471 facilitate communication with the application protocols used. This 472 removes the need to create and maintain application layer gateways 473 for specific protocols that have been commonly used to provide 474 transparency in previous generations of NAT and firewall middleboxes. 475 It is assumed that these middleboxes will be statically configured in 476 such a way that NSIS NATFW signaling messages themselves are allowed 477 to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP 478 signaling is used to dynamically install additional policy rules in 479 all NATFW middleboxes along the data path that will allow 480 transmission of the application data flow(s). Firewalls are 481 configured to forward data packets matching the policy rule provided 482 by the NSLP signaling. NATs are configured to translate data packets 483 matching the policy rule provided by the NSLP signaling. An 484 additional capability, that is an exception to the primary goal of 485 NSIS NATFW signaling, is that the NATFW nodes can request blocking of 486 particular data flows instead of enabling these flows at upstream 487 firewalls. 489 The basic high-level picture of NSIS usage is that end hosts are 490 located behind middleboxes, meaning that there is a middlebox on the 491 data path from the end host in a private network and the external 492 network (NATFW in Figure 1). Applications located at these end hosts 493 try to establish communication with corresponding applications on 494 other such end hosts. They trigger the NSIS entity at the local host 495 to control provisioning for middlebox traversal along the prospective 496 data path (e.g., via an API call). The NSIS entity in turn uses NSIS 497 NATFW NSLP signaling to establish policy rules along the data path, 498 allowing the data to travel from the sender to the receiver 499 unobstructed. 501 Application Application Server (0, 1, or more) Application 503 +----+ +----+ +----+ 504 | +------------------------+ +------------------------+ | 505 +-+--+ +----+ +-+--+ 506 | | 507 | NSIS Entities NSIS Entities | 508 +-+--+ +----+ +-----+ +-+--+ 509 | +--------+ +----------------------------+ +-----+ | 510 +-+--+ +-+--+ +--+--+ +-+--+ 511 | | ------ | | 512 | | //// \\\\\ | | 513 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 514 | | | | | Internet | | | | | 515 | +--------+ +-----+ +----+ +-----+ | 516 +----+ +----+ |\ | +----+ +----+ 517 \\\\ ///// 518 sender NATFW (1+) ------ NATFW (1+) receiver 520 Note that 1+ refers to one or more NATFW nodes. 522 Figure 1: Generic View of NSIS with NATs and/or Firewalls 524 For end-to-end NATFW signaling, it is necessary that each firewall 525 and each NAT along the path between the data sender and the data 526 receiver implements the NSIS NATFW NSLP. There might be several NATs 527 and FWs in various possible combinations on a path between two hosts. 528 Section 2 presents a number of likely scenarios with different 529 combinations of NATs and firewalls. 531 2. Network Deployment Scenarios using the NATFW NSLP 533 This section introduces several scenarios for middlebox placement 534 within IP networks. Middleboxes are typically found at various 535 different locations, including at enterprise network borders, within 536 enterprise networks, as mobile phone network gateways, etc. Usually, 537 middleboxes are placed more towards the edge of networks than in 538 network cores. Firewalls and NATs may be found at these locations 539 either alone, or they may be combined; other categories of 540 middleboxes may also be found at such locations, possibly combined 541 with the NATs and/or firewalls. Using combined middleboxes typically 542 reduces the number of network elements needed. 544 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 545 regular data path to the NSIS responder (NR). On the data path, 546 NATFW NSLP signaling messages reach different NSIS nodes that 547 implement the NATFW NSLP. Each NATFW NSLP node processes the 548 signaling messages according to Section 3 and, if necessary, installs 549 policy rules for subsequent data packets. 551 Each of the following sub-sections introduces a different scenario 552 for a different set of middleboxes and their ordering within the 553 topology. It is assumed that each middlebox implements the NSIS 554 NATFW NSLP signaling protocol. 556 2.1. Firewall Traversal 558 This section describes a scenario with firewalls only; NATs are not 559 involved. Each end host is behind a firewall. The firewalls are 560 connected via the public Internet. Figure 2 shows the topology. The 561 part labeled "public" is the Internet connecting both firewalls. 563 +----+ //----\\ +----+ 564 NI -----| FW |---| |------| FW |--- NR 565 +----+ \\----// +----+ 567 private public private 569 FW: Firewall 570 NI: NSIS Initiator 571 NR: NSIS Responder 573 Figure 2: Firewall Traversal Scenario 575 Each firewall on the data path must provide traversal service for 576 NATFW NSLP in order to permit the NSIS message to reach the other end 577 host. All firewalls process NSIS signaling and establish appropriate 578 policy rules, so that the required data packet flow can traverse 579 them. 581 There are several very different ways to place firewalls in a network 582 topology. To distinguish firewalls located at network borders, such 583 as administrative domains, from others located internally, the term 584 edge-firewall is used. A similar distinction can be made for NATs, 585 with an edge-NAT fulfilling the equivalent role. 587 2.2. NAT with two private Networks 589 Figure 3 shows a scenario with NATs at both ends of the network. 590 Therefore, each application instance, the NSIS initiator and the NSIS 591 responder, are behind NATs. The outermost NAT, known as the edge- 592 NAT, at each side is connected to the public Internet. The NATs are 593 generically labeled as MB (for middlebox), since those devices 594 certainly implement NAT functionality, but can implement firewall 595 functionality as well. 597 Only two middleboxes MB are shown in Figure 3 at each side, but in 598 general, any number of MBs on each side must be considered. 600 +----+ +----+ //----\\ +----+ +----+ 601 NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR 602 +----+ +----+ \\----// +----+ +----+ 604 private public private 606 MB: Middlebox 607 NI: NSIS Initiator 608 NR: NSIS Responder 610 Figure 3: NAT with two Private Networks Scenario 612 Signaling traffic from NI to NR has to traverse all the middleboxes 613 on the path, and all the middleboxes must be configured properly to 614 allow NSIS signaling to traverse them. The NATFW signaling must 615 configure all middleboxes and consider any address translation that 616 will result from this configuration in further signaling. The sender 617 (NI) has to know the IP address of the receiver (NR) in advance, 618 otherwise it will not be possible to send any NSIS signaling messages 619 towards the responder. Note that this IP address is not the private 620 IP address of the responder. Instead a NAT binding (including a 621 public IP address) has to be previously installed on the NAT that 622 subsequently allows packets reaching the NAT to be forwarded to the 623 receiver within the private address realm. This generally requires 624 further support from an application layer protocol for the purpose of 625 discovering and exchanging information. The receiver might have a 626 number of ways to learn its public IP address and port number 627 (including the NATFW NSLP) and might need to signal this information 628 to the sender using the application level signaling protocol. 630 2.3. NAT with Private Network on Sender Side 632 This scenario shows an application instance at the sending node that 633 is behind one or more NATs (shown as generic MB, see discussion in 634 Section 2.2). The receiver is located in the public Internet. 636 +----+ +----+ //----\\ 637 NI --| MB |-----| MB |---| |--- NR 638 +----+ +----+ \\----// 640 private public 642 MB: Middlebox 643 NI: NSIS Initiator 644 NR: NSIS Responder 646 Figure 4: NAT with Private Network on Sender Side Scenario 648 The traffic from NI to NR has to traverse middleboxes only on the 649 sender's side. The receiver has a public IP address. The NI sends 650 its signaling message directly to the address of the NSIS responder. 651 Middleboxes along the path intercept the signaling messages and 652 configure the policy rules accordingly. 654 The data sender does not necessarily know whether the receiver is 655 behind a NAT or not, hence, it is the receiving side that has to 656 detect whether itself is behind a NAT or not. 658 2.4. NAT with Private Network on Receiver Side Scenario 660 The application instance receiving data is behind one or more NATs 661 shown as MB (see discussion in Section 2.2). 663 //----\\ +----+ +----+ 664 NI ---| |---| MB |-----| MB |--- NR 665 \\----// +----+ +----+ 667 public private 669 MB: Middlebox 670 NI: NSIS Initiator 671 NR: NSIS Responder 673 Figure 5: NAT with Private Network on Receiver Scenario 675 Initially, the NSIS responder must determine its publicly reachable 676 IP address at the external middlebox and notify the NSIS initiator 677 about this address. One possibility is that an application level 678 protocol is used, meaning that the public IP address is signaled via 679 this protocol to the NI. Afterwards the NI can start its signaling 680 towards the NR and therefore establish the path via the middleboxes 681 in the receiver side private network. 683 This scenario describes the use case for the RESERVE-EXTERNAL-ADDRESS 684 mode of the NATFW NSLP. 686 2.5. Both End Hosts behind twice-NATs 688 This is a special case, where the main problem arises from the need 689 to detect that both end hosts are logically within the same address 690 space, but are also in two partitions of the address realm on either 691 side of a twice-NAT (see [9] for a discussion of twice-NAT 692 functionality). 694 Sender and receiver are both within a single private address realm 695 but the two partitions potentially have overlapping IP address 696 ranges. Figure 6 shows the arrangement of NATs. 698 public 700 +----+ +----+ //----\\ 701 NI --| MB |--+--| MB |---| | 702 +----+ | +----+ \\----// 703 | 704 | +----+ 705 +--| MB |------------ NR 706 +----+ 708 private 710 MB: Middlebox 711 NI: NSIS Initiator 712 NR: NSIS Responder 714 Figure 6: NAT to Public, Sender and Receiver on either side of a 715 twice-NAT Scenario 717 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 718 addresses and port numbers on both sides, meaning the mapping of 719 source and destination address at the private and public interfaces. 721 This scenario requires the assistance of application level entities, 722 such as a DNS server. The application level entities must handle 723 requests that are based on symbolic names, and configure the 724 middleboxes so that data packets are correctly forwarded from NI to 725 NR. The configuration of those middleboxes may require other 726 middlebox communication protocols, such as MIDCOM [7]. NSIS 727 signaling is not required in the twice-NAT only case, since 728 middleboxes of the twice-NAT type are normally configured by other 729 means. Nevertheless, NSIS signaling might be useful when there are 730 also firewalls on the path. In this case NSIS will not configure any 731 policy rule at twice-NATs, but will configure policy rules at the 732 firewalls on the path. The NSIS signaling protocol must be at least 733 robust enough to survive this scenario. This requires that twice- 734 NATs must implement the NATFW NSLP also and participate in NATFW 735 sessions but they do not change the configuration of the NAT, i.e., 736 they only read the address mapping information out of the NAT and 737 translate the Message Routing Information (MRI, [2]) within the NSLP 738 and NTLP accordingly. For more information see Appendix C.4 740 2.6. Both End Hosts Behind Same NAT 742 When NSIS initiator and NSIS responder are behind the same NAT (thus 743 being in the same address realm, see Figure 7), they are most likely 744 not aware of this fact. As in Section 2.4 the NSIS responder must 745 determine its public IP address in advance and transfer it to the 746 NSIS initiator. Afterwards, the NSIS initiator can start sending the 747 signaling messages to the responder's public IP address. During this 748 process, a public IP address will be allocated for the NSIS initiator 749 at the same middlebox as for the responder. Now, the NSIS signaling 750 and the subsequent data packets will traverse the NAT twice: from 751 initiator to public IP address of responder (first time) and from 752 public IP address of responder to responder (second time). 754 NI public 755 \ +----+ //----\\ 756 +-| MB |----| | 757 / +----+ \\----// 758 NR 759 private 761 MB: Middlebox 762 NI: NSIS Initiator 763 NR: NSIS Responder 765 Figure 7: NAT to Public, Both Hosts Behind Same NAT 767 2.7. IPv4/v6 NAT with two Private Networks 769 This scenario combines the use case described in Section 2.2 with the 770 IPv4 to IPv6 transition scenario involving address and protocol 771 translation, i.e., using Network Address and Protocol Translators 772 (NAT-PT, [10]). 774 The difference from the other scenarios is the use of IPv6 to IPv4 775 (and vice versa) address and protocol translation. Additionally, the 776 base NTLP must support transport of messages in mixed IPv4 and IPv6 777 networks where some NSIS peers provide translation. 779 +----+ +----+ //---\\ +----+ //---\\ +----+ +----+ 780 NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR 781 +----+ +----+ \\---// +----+ \\---// +----+ +----+ 783 private public public private 784 IPv4 IPv6 786 MB: Middlebox 787 NI: NSIS Initiator 788 NR: NSIS Responder 790 Figure 8: IPv4/v6 NAT with two Private Networks 791 This scenario needs the same type of application level support as 792 described in Section 2.5, and so the issues relating to twice-NATs 793 apply here as well. 795 Note that the current form of IPv4/v6 NAT known as the Network 796 Address Translator - Protocol Translator (NAT-PT) [10] is being 797 removed from the set of recommended mechanisms for general usage in 798 IPv4/IPv6 transitions. This scenario is therefore not expected to be 799 commonly seen. 801 2.8. Multihomed Network with NAT 803 The previous sub-sections sketched network topologies where several 804 NATs and/or firewalls are ordered sequentially on the path. This 805 section describes a multihomed scenario with two NATs placed on 806 alternative paths to the public network. 808 +----+ 809 NI -------| MB |\ 810 \ +----+ \ //---\\ 811 \ -| |-- NR 812 \ \\---// 813 \ +----+ | 814 --| MB |-------+ 815 +----+ 817 private public 819 MB: Middlebox 820 NI: NSIS Initiator 821 NR: NSIS Responder 823 Figure 9: Multihomed Network with Two NATs 825 Depending on the destination, either one or the other middlebox is 826 used for the data flow. Which middlebox is used, depends on local 827 policy or routing decisions. NATFW NSLP must be able to handle this 828 situation properly, see Section 3.7.2 for an extended discussion of 829 this topic with respect to NATs. 831 2.9. Multihomed Network with Firewall 833 This section describes a multihomed scenario with two firewalls 834 placed on alternative paths to the public network (Figure 10). The 835 routing in the private and public network decides which firewall is 836 being taken for data flows. Depending on the data flow's direction, 837 either outbound or inbound, a different firewall could be traversed. 839 This is a challenge for the REA mode of the NATFW NSLP where the NSIS 840 responder is located behind these firewalls within the private 841 network. The REA mode is used to block a particular data flow on an 842 upstream firewall. NSIS must route the REA mode message upstream 843 from NR to NI probably without knowing which path the data traffic 844 will take from NI to NR (see also Appendix B. 846 +----+ 847 NR -------| MB |\ 848 \ +----+ \ //---\\ 849 \ -| |-- NI 850 \ \\---// 851 \ +----+ | 852 --| MB |-------+ 853 +----+ 854 private 856 private public 858 MB: Middlebox 859 NI: NSIS Initiator 860 NR: NSIS Responder 862 Figure 10: Multihomed Network with two Firewalls 864 3. Protocol Description 866 This section defines messages, objects, and protocol semantics for 867 the NATFW NSLP. 869 3.1. Policy Rules 871 Policy rules, bound to a session, are the building blocks of 872 middlebox devices considered in the NATFW NSLP. For firewalls the 873 policy rule usually consists of a 5-tuple, source/destination 874 addresses, transport protocol, and source/destination port numbers, 875 plus an action, such as allow or deny. For NATs the policy rule 876 consists of the action 'translate this address' and further mapping 877 information, that might be, in the simplest case, internal IP address 878 and external IP address. 880 The NATFW NSLP carries, in conjunction with the NTLP's Message 881 Routing Information (MRI), the policy rules to be installed at NATFW 882 peers. This policy rule is an abstraction with respect to the real 883 policy rule to be installed at the respective firewall or NAT. It 884 conveys the initiator's request and must be mapped to the possible 885 configuration on the particular used NAT and/or firewall in use. For 886 pure firewalls one or more filter rules must be created and for pure 887 NATs one or more NAT bindings must be created. In mixed firewall and 888 NAT boxes, the policy rule must be mapped to filter rules and 889 bindings observing the ordering of the firewall and NAT engine. 890 Depending on the ordering, NAT before firewall or vice versa, the 891 firewall rules must carry public or private IP addresses. However, 892 the exact mapping depends on the implementation of the firewall or 893 NAT which is different for each vendor. 895 The policy rule at the NATFW NSLP level comprises the message routing 896 information (MRI) part, carried in the NTLP, and the information 897 available in the NATFW NSLP. The information provided by the NSLP is 898 stored in the 'extend flow information' (NATFW_EFI) and 'data 899 terminal information' (NATFW_DTINFO) objects, and the message type, 900 in particular the flow direction. Additional information, such as 901 the external IP address and port number, stored in the NAT or 902 firewall, will be used as well. The MRI carries the filter part of 903 the NAT/firewall-level policy rule that is to be installed. 905 3.2. Basic Protocol Overview 907 The NSIS NATFW NSLP is carried over the General Internet Signaling 908 Transport (GIST, the implementation of the NTLP) defined in [2]. 909 NATFW NSLP messages are initiated by the NSIS initiator (NI), handled 910 by NSIS forwarders (NF) and received by the NSIS responder (NR). It 911 is required that at least NI and NR implement this NSLP, intermediate 912 NFs only implement this NSLP when they provide relevant middlebox 913 functions. NSIS forwarders that do not have any NATFW NSLP functions 914 just forward these packets as they have no interest in them. 916 A Data Sender (DS), intending to send data to a Data Receiver (DR) 917 has to start NATFW NSLP signaling. This causes the NI associated 918 with the data sender (DS) to launch NSLP signaling towards the 919 address of data receiver (DR) (see Figure 11). Although it is 920 expected that the DS and the NATFW NSLP NI will usually reside on the 921 same host, this specification does not rule out scenarios where the 922 DS and NI reside on different hosts, the so-called proxy mode (see 923 Section 1.) 925 +-------+ +-------+ +-------+ +-------+ 926 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 927 | |--->| NF1 |--->| NF2 |--->| | 928 +-------+ +-------+ +-------+ +-------+ 930 ========================================> 931 Data Traffic Direction (downstream) 933 ---> : NATFW NSLP request signaling 934 ~~~> : NATFW NSLP response signaling 935 DS/NI : Data sender and NSIS initiator 936 DR/NR : Data receiver and NSIS responder 937 MB1 : Middlebox 1 and NSIS forwarder 1 938 MB2 : Middlebox 2 and NSIS forwarder 2 940 Figure 11: General NSIS signaling 942 The normal sequence of NSLP events is as follows: 944 o NSIS initiators generate NATFW NSLP request messages and send 945 these towards the NSIS responder. Note that the NSIS initiator 946 does not necessarily need to be co-located with the data sender. 948 o NSLP request messages are processed each time a NF with NATFW NSLP 949 support is traversed. These nodes process the message, check 950 local policies for authorization and authentication, possibly 951 create policy rules, and forward the signaling message to the next 952 NSIS node. The request message is forwarded until it reaches the 953 NSIS responder. 955 o NSIS responders will check received messages and process them if 956 applicable. NSIS responders generate response messages and send 957 them hop-by-hop back to the NI via the same chain of NFs 958 (traversal of the same NF chain is guaranteed through the 959 established reverse message routing state in the NTLP). 961 o The response message is processed at each NF that has been 962 included in the prior signaling session setup. 964 o Once the NI has received a successful response, the data sender 965 can start sending its data flow to the data receiver. 967 Because NATFW NSLP signaling follows the data path from DS to DR, 968 this immediately enables communication between both hosts for 969 scenarios with only firewalls on the data path or NATs on the sender 970 side. For scenarios with NATs on the receiver side certain problems 971 arise, as described in Section 2. 973 When the NR and the NI are located in different address realms and 974 the NR is located behind a NAT, the NI cannot signal to the NR 975 address directly. The DR and NR are not reachable from the NIs using 976 the private address of the NR and thus NATFW signaling messages 977 cannot be sent to the NR/DR's address. Therefore, the NR must first 978 obtain a NAT binding that provides an address that is reachable for 979 the NI. Once the NR has acquired a public IP address, it forwards 980 this information to the DS via a separate protocol. This application 981 layer signaling, which is out of scope of the NATFW NSLP, may involve 982 third parties that assist in exchanging these messages. 984 The same holds partially true for NRs located behind firewalls that 985 block all traffic by default. In this case, NR must tell its 986 upstream firewalls of inbound NATFW NSLP signaling and corresponding 987 data traffic. Once the NR has informed the upstream firewalls, it 988 can start its application level signaling to initiate communication 989 with the NI. This application layer signaling, which is out of scope 990 of the NATFW NSLP, may involve third parties that assist in 991 exchanging these messages. This mechanism can be used by machines 992 hosting services behind firewalls as well. In this case, the NR 993 informs the upstream firewalls as described, but does not need to 994 communicate this to the NIs. 996 NATFW NSLP signaling supports this scenario by using the REA mode of 997 operation 999 1. The NR acquires a public address by signaling on the reverse path 1000 (NR towards NI) and thus making itself available to other hosts. 1001 This process of acquiring public addresses is called reservation. 1002 During this process the NR reserves publicly reachable addresses 1003 and ports suitable for further usage in application level 1004 signaling and the publicly reachable address for further NATFW 1005 NSLP signaling. However, the data traffic will not be allowed to 1006 use this address/port initially (see next point). 1008 2. The NI signals directly to the NR, as the NI would do if there is 1009 no NAT in between, and creates policy rules at middleboxes. 1010 Note, that the reservation mode will only allow forwarding of 1011 signaling messages, but not data flow packets. Policy rules 1012 allowing forwarding of data flow packets set up by the prior REA 1013 mode signaling will be 'activated' by the signaling from NI 1014 towards NR. The RESERVE-EXTERNAL-ADDRESS (REA) mode of operation 1015 is detailed inSection 3.7.2 1017 +-------+ +-------+ +-------+ +-------+ 1018 | DS/NI |<~~~| MB1/ |<~~~| NR | | DR | 1019 | |--->| NF1 |--->| | | | 1020 +-------+ +-------+ +-------+ +-------+ 1022 ========================================> 1023 Data Traffic Direction (downstream) 1025 ---> : NATFW NSLP request signaling 1026 ~~~> : NATFW NSLP response signaling 1027 DS/NI : Data sender and NSIS initiator 1028 DR/NR : Data receiver and NSIS responder 1029 MB1 : Middlebox 1 and NSIS forwarder 1 1030 MB2 : Middlebox 2 and NSIS forwarder 2 1032 Figure 12: A NSIS proxy mode signaling 1034 The above usage assumes that both ends of a communication support 1035 NSIS, but fails when NSIS is only deployed at one end of the path. 1036 In this case only one of the receiving or sending side is NSIS aware 1037 and not both at the same time. NATFW NSLP supports this scenario 1038 (i.e., the DR does not support NSIS) by using a proxy mode, as 1039 described in Section 3.7.7; the proxy mode operation also supports 1040 scenarios with a data sender that does not support NSIS, i.e. the 1041 data receiver must act to enable data flows towards itself. 1043 The basic functionality of the NATFW NSLP provides for opening 1044 firewall pin holes and creating NAT bindings to enable data flows to 1045 traverse these devices. Firewalls are normally expected to work on a 1046 'deny-all' policy, meaning that traffic not explicitly matching any 1047 firewall filter rule will be blocked. Similarly, the normal behavior 1048 of NATs is to block all traffic that does not match any already 1049 configured/installed binding or session. However, some scenarios 1050 require support of firewalls having 'allow-all' policies, allowing 1051 data traffic to traverse the firewall unless it is blocked 1052 explicitly. Data receivers can utilize NATFW NSLP's REA message with 1053 action set to 'deny' to install policy rules at upstream firewalls to 1054 block unwanted traffic. 1056 The protocol works on a soft-state basis, meaning that whatever state 1057 is installed or reserved on a middlebox will expire, and thus be de- 1058 installed or forgotten after a certain period of time. To prevent 1059 premature removal of state that is needed for ongoing communication, 1060 the NATFW NI involved will have to specifically request a session 1061 extension. An explicit NATFW NSLP state deletion capability is also 1062 provided by the protocol. 1064 If the actions requested by a NATFW NSLP message cannot be carried 1065 out, NFs and the NR should return a failure, such that appropriate 1066 actions can be taken. They can do this either during a the request 1067 message handling (synchronously) by sending an error RESPONSE 1068 message, or at any time (asynchronously) by sending a notification 1069 message. 1071 The next sections define the NATFW NSLP message types and formats, 1072 protocol operations, and policy rule operations. 1074 3.2.1. Message Types 1076 The protocol uses five messages types: 1078 o CREATE: a request message used for creating, changing, refreshing, 1079 and deleting CREATE NATFW NSLP sessions, i.e., open the data path 1080 from DS to DR. 1082 o RESERVE-EXTERNAL-ADDRESS (REA): a request message used for 1083 reserving, changing, refreshing, and deleting REA NATFW NSLP 1084 sessions. REA messages are forwarded to the edge-NAT or edge- 1085 firewall and allow inbound CREATE messages to be forwarded to the 1086 NR. Additionally, REA messages reserve an external address and, 1087 if applicable, port number at an edge-NAT. 1089 o TRACE: a request message to trace all involved NATFW NSLP nodes in 1090 a particular signaling session. 1092 o NOTIFY: an asynchronous message used by NATFW peers to alert 1093 upstream NATFW peers about specific events (especially failures). 1095 o RESPONSE: used as a response to CREATE, REA, and TRACE request 1096 messages. 1098 3.2.2. Classification of RESPONSE Messages 1100 RESPONSE messages will be generated synchronously by NSIS Forwarders 1101 and Responders to report success or failure of operations or some 1102 information relating to the session or a node. 1104 All RESPONSE messages MUST carry a NATFW_INFO object which contains a 1105 severity class code and a response code (see Section 4.2.4). This 1106 section defines terms for groups of RESPONSE messages depending on 1107 the severity class. 1109 o Successful RESPONSE: Messages carrying NATFW_INFO with severity 1110 class 'Success' (0x2). 1112 o Informational RESPONSE: Messages carrying NATFW_INFO with severity 1113 class 'Informational' (0x1) (normally only used with NOTIFY 1114 messages). 1116 o Error RESPONSE: Messages carrying NATFW_INFO with severity class 1117 other than 'Success' or 'Informational'. 1119 3.2.3. NATFW NSLP Signaling Sessions 1121 The general idea of signaling sessions is described in [4]. There is 1122 signaling session state stored at the NTLP layer and at the NATFW 1123 NSLP level. The signaling session state for the NATFW NSLP consists 1124 comprises NSLP state and the associated policy rules at a middlebox. 1126 A NATFW NSLP signaling session can conceptually be in different 1127 states, implementations may use other or even more states. The 1128 signaling session can have these states at a node: 1130 o Pending: The signaling session has been created and the node is 1131 waiting for a RESPONSE message to the request message. A 1132 signaling session in state 'Pending' MUST be marked as 'Dead' if 1133 no corresponding RESPONSE message has been received within the 1134 time of the locally granted session lifetime of the forwarded 1135 request message (as described in Section 3.4). 1137 o Established: The signaling session is established, i.e, the 1138 signaling has been successfully performed. A signaling session in 1139 state 'Established' MUST be marked as 'Dead' if no refresh message 1140 has been received within the time of the locally granted session 1141 lifetime of the RESPONSE message (as described in Section 3.4). 1143 o Dead: The node has received an error RESPONSE message for the 1144 signaling session and the signaling session can be deleted. 1146 o Transit: The node has received an asynchronous message, i.e., a 1147 NOTIFY, and can delete the signaling session if needed. When a 1148 node has received a NOTIFY message (for instance, indicating a 1149 route change) it marks it as 'Transit' and deletes this session if 1150 it is unused for some time specific to the local node. This idle 1151 time does not need to be fixed, since it can depend on the node 1152 local maintenance cycle, i.e., the session could be deleted if the 1153 node runs it garbage collection cycle. 1155 3.3. Basic Message Processing 1157 All NATFW messages are subject to some basic message processing when 1158 received at a node, independent of request or response messages. 1159 Initially, the syntax of the NSLP message is checked and a RESPONSE 1160 message with an appropriate error of class 'Protocol error' (0x1) 1161 code is generated if any problem is detected. If a message is 1162 delivered to the NATFW NSLP, this implies that the NTLP layer has 1163 been able to correlate it with the SID and MRI entries in its 1164 database. There is therefore enough information to identify the 1165 source of the message and routing information to route the message 1166 back to the NI through an established chain of MAs since the NATFW 1167 NSLP always requests reliable delivery resulting in the NTLP using 1168 C-mode. The message is not further forwarded if any error in the 1169 syntax is detected. The specific response codes stemming from the 1170 processing of objects are described in the respective object 1171 definition section (see Section 4). After passing this check, the 1172 NATFW NSLP node performs authentication/authorization related checks 1173 described in Section 3.6. Further processing is executed only if 1174 these tests have been successfully passed, otherwise the processing 1175 stops and an error RESPONSE is returned, as described in these 1176 sections. 1178 Further message processing stops whenever an error RESPONSE message 1179 is generated, and the request message is discarded. 1181 3.4. Calculation of Session Lifetime 1183 NATFW NSLP sessions, and the corresponding policy rules which may 1184 have been installed, are maintained via a soft-state mechanism. Each 1185 session is assigned a lifetime and the session is kept alive as long 1186 as the lifetime is valid. After the expiration of the lifetime, 1187 sessions and policy rules MUST be removed automatically and resources 1188 bound to them MUST be freed as well. Session lifetime is handled at 1189 every NATFW NSLP node. The NSLP forwarders and NSLP responder MUST 1190 NOT trigger lifetime extension refresh messages (see Section 3.7.3): 1191 this is the task of the NSIS initiator. This section describes how 1192 the session lifetime is set within a signaling session. 1194 The NSIS initiator MUST choose a session lifetime value (expressed in 1195 seconds) before sending any message, including the initial message 1196 which creates the session, to other NSLP nodes. The session lifetime 1197 value is calculated based on: 1199 o The number of lost refresh messages that NFs should cope with; 1201 o the end-to-end delay between the NI and NR; 1203 o network vulnerability due to session hijacking ([8], session 1204 hijacking is made easier when the NI does not explicitly remove 1205 the session); 1207 o the user application's data exchange duration, in terms of time 1208 and networking needs. This duration is modeled as M x R, with R 1209 the message refresh period (in seconds) and M as a multiplier for 1210 R; 1212 o the load on the signalling plane. Short lifetimes imply more 1213 frequent signalling messages. 1215 o the acceptable time for a signalling session to be present after 1216 it is no longer actually needed. For example, if the existence of 1217 the session implies a monetary cost and teardown cannot be 1218 guaranteed, shorter lifetimes would be preferable. 1220 The RSVP specification [13] provides an appropriate algorithm for 1221 calculating the session lifetime as well as means to avoid refresh 1222 message synchronization between sessions. [13] recommends: 1224 1. The refresh message timer to be randomly set to a value in the 1225 range [0.5R, 1.5R]. 1227 2. To avoid premature loss of state, lt (with lt being the session 1228 lifetime) must satisfy lt >= (K + 0.5)*1.5*R, where K is a small 1229 integer. Then in the worst case, K-1 successive messages may be 1230 lost without state being deleted. Currently K = 3 is suggested 1231 as the default. However, it may be necessary to set a larger K 1232 value for hops with high loss rate. Other algorithms could be 1233 used to define the relation between the session lifetime and the 1234 refresh message period; the algorithm provided is only given as 1235 an example. 1237 This requested lifetime value lt is stored in the NATFW_LT object of 1238 the NSLP message. 1240 NSLP forwarders may execute the following behavior with respect to 1241 the lifetime handling: 1243 Requested lifetime acceptable: 1245 No changes to the lifetime values are needed. The NSLP request 1246 message is forwarded. 1248 Lifetime can be lowered: 1250 The NSLP responder MAY also lower the requested lifetime to an 1251 acceptable value (based on its local policies). If an NF changes 1252 the lifetime value, it MUST store the new value in the 'lifetime' 1253 object. The NSLP request message is forwarded. 1255 Requested lifetime is too big: 1257 The NSLP responder MAY reject the requested lifetime value as 1258 being too big and MUST generate an error RESPONSE message of class 1259 'Signaling session failures' (0x6) with response code 'Requested 1260 lifetime is too big' (0x02) upon rejection. Lowering the lifetime 1261 is preferred instead of generating an error message. 1263 Requested lifetime is too small: 1265 The NSLP responder MAY reject the requested lifetime value as 1266 being to small and MUST generate an error RESPONSE message of 1267 class 'Signaling session failures' (0x6) with response code 1268 'Requested lifetime is too small' (0x10) upon rejection. 1270 NFs MUST NOT increase the lifetime value. Messages can be rejected 1271 on the basis of the lifetime being too long when a session is first 1272 created amd also on refreshes. 1274 The NSLP responder generates a successful RESPONSE for the received 1275 request message, sets the lifetime value to the above granted 1276 lifetime and sends the message back hop-by-hop towards NSLP 1277 initiator. 1279 Each NSLP forwarder processes the RESPONSE message, reads and stores 1280 the granted lifetime value. The forwarders MUST accept the granted 1281 lifetime, as long as this value is less than or equal to the 1282 acceptable value. The acceptable value refers to the value accepted 1283 by the NSLP forwarder when processing the CREATE message. For 1284 received values greater than the acceptable value, NSLP forwarders 1285 MUST generate a RESPONSE message of class 'Signaling session 1286 failures' (0x6) with response code 'Requested lifetime is too big' 1287 (0x02). For received values lower than the values acceptable by the 1288 node local policy, NSLP forwarders MUST generate a RESPONSE message 1289 of class 'Signaling session failures' (0x6) with response code 1290 'Requested lifetime is too small' (0x10). Figure 13 shows the 1291 procedure with an example, where an initiator requests 60 seconds 1292 lifetime in the CREATE message and the lifetime is shortened along 1293 the path by the forwarder to 20 seconds and by the responder to 15 1294 seconds. When the NSLP forwarder receives the RESPONSE message with 1295 a lifetime value of 15 seconds it checks whether this value is lower 1296 or equal to the acceptable value. 1298 +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ 1299 | |---------------->| NSLP |---------------->| | 1300 | NI | | forwarder | | NR | 1301 | |<----------------| check 15<20 |<----------------| | 1302 +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ 1304 lt = lifetime 1306 Figure 13: Lifetime Setting Example 1308 3.5. Message Sequencing 1310 NATFW NSLP messages need to carry an identifier so that all nodes 1311 along the path can distinguish messages sent at different points in 1312 time. Messages can be lost along the path or duplicated. So all 1313 NATFW NSLP nodes should be able to identify either old messages that 1314 have been received before (duplicated), or the case that messages 1315 have been lost before (loss). For message replay protection it is 1316 necessary to keep information about messages that have already been 1317 received and requires every NATFW NSLP message to carry a message 1318 sequence number (MSN), see also Section 4.2.6. 1320 The MSN MUST be set by the NI and MUST NOT be set or modified by any 1321 other node. The initial value for the MSN MUST be generated randomly 1322 and MUST be unique only within the session for which it is used. The 1323 NI MUST increment the MSN by one for every message sent. Once the 1324 MSN has reached the maximum value, the next value it takes is zero. 1325 All NATFW NSLP nodes MUST use the algorithm defined in [3] to detect 1326 MSN wrap-arounds. 1328 NSIS forwarders and the responder store the MSN from the initial 1329 CREATE or REA packet which creates the session as the start value for 1330 the session. NFs and NRs MUST include the received MSN value in the 1331 corresponding RESPONSE message that they generate. 1333 When receiving a request message, a NATFW NSLP node uses the MSN 1334 given in the message to determine whether the state being requested 1335 is different to the state already installed. The message MUST be 1336 discarded if the received MSN value is equal to or lower than the 1337 stored MSN value. Such a received MSN value can indicate a 1338 duplicated and delayed message or replayed message. If the received 1339 MSN value is greater than the already stored MSN value, the NATFW 1340 NSLP MUST update its stored state accordingly, if permitted by all 1341 security checks (see Section 3.6), and stores the updated MSN value 1342 accordingly. 1344 3.6. Authentication, Authorization, and Policy Decisions 1346 NATFW NSLP nodes receiving signaling messages MUST first check 1347 whether this message is authenticated and authorized to perform the 1348 requested action. The necessary information for these checks can be 1349 carried in the NATFW_CREDENTIAL object. NATFW NSLP nodes requiring 1350 more information than provided MUST generate an error RESPONSE of 1351 class 'Permanent failure' (0x5) with response code 'Authentication 1352 failed' (0x01) or with response code 'Authorization failed' (0x02). 1354 The NATFW NSLP is expected to run in various environments, such as 1355 IP-based telephone systems, enterprise networks, home networks, etc. 1356 The requirements on authentication and authorization are quite 1357 different between these use cases. While a home gateway, or an 1358 Internet cafe, using NSIS may well be happy with a "NATFW signaling 1359 coming from inside the network" policy for authorization of 1360 signaling, enterprise networks are likely to require more strongly 1361 authenticated/authorized signaling. This enterprise scenario may 1362 require the use of an infrastructure and administratively assigned 1363 identities to operate the NATFW NSLP. 1365 Once the NI is authenticated and authorized, another step is 1366 performed. The requested policy rule for the session is checked 1367 against a set of policy rules, i.e., whether the requesting NI is 1368 allowed to request the policy rule to be loaded in the device. If 1369 this fails the NF or NR must send an error RESPONSE of class 1370 'Permanent failure' (0x5) and with response code 'Authorization 1371 failed' (0x02). 1373 3.7. Protocol Operations 1375 This section defines the protocol operations including, how to create 1376 sessions, maintain them, and how to reserve addresses. 1378 3.7.1. Creating Sessions 1380 Allowing two hosts to exchange data even in the presence of 1381 middleboxes is realized in the NATFW NSLP by use of the CREATE 1382 request message. The NI (either the data sender or a proxy) 1383 generates a CREATE message as defined in Section 4.3.1 and hands it 1384 to the NTLP. The NTLP forwards the whole message on the basis of the 1385 message routing information towards the NR. Each NSIS forwarder 1386 along the path that implements NATFW NSLP, processes the NSLP 1387 message. Forwarding is thus managed NSLP hop-by-hop but may pass 1388 transparently through NSIS forwarders which do not contain NATFW NSLP 1389 functionality and non-NSIS aware routers between NSLP hop way points. 1390 When the message reaches the NR, the NR can accept the request or 1391 reject it. The NR generates a response to the request and this 1392 response is transported hop-by-hop towards the NI. NATFW NSLP 1393 forwarders may reject requests at any time. Figure 14 sketches the 1394 message flow between NI (DS in this example), a NF (e.g., NAT), and 1395 NR (DR in this example). 1397 NI Private Network NF Public Internet NR 1398 | | | 1399 | CREATE | | 1400 |----------------------------->| | 1401 | | | 1402 | | | 1403 | | CREATE | 1404 | |--------------------------->| 1405 | | | 1406 | | RESPONSE | 1407 | RESPONSE |<---------------------------| 1408 |<-----------------------------| | 1409 | | | 1410 | | | 1412 Figure 14: CREATE message flow with success RESPONSE 1414 There are several processing rules for a NATFW peer when generating 1415 and receiving CREATE messages, since this message type is used for 1416 creating new signaling sessions, updating existing, extending the 1417 lifetime and deleting signaling session. The three latter functions 1418 operate in the same way for all kinds of request message, and are 1419 therefore described in separate sections: 1421 o Extending the lifetime of signaling sessions is described in 1422 Section 3.7.3. 1424 o Deleting signaling sessions is described in Section 3.7.4. 1426 o Updating policy rules is described in Section 3.10. 1428 For an initial CREATE message creating a new NATFW NSLP session, the 1429 processing of CREATE messages is different for every NATFW node type: 1431 o NSLP initiator: An NI only generates CREATE messages and hands 1432 them over to the NTLP. The NI should never receive request 1433 messages and MUST discard it. 1435 o NATFW NSLP forwarder: NFs that are unable to forward the request 1436 message to the next hop MUST generate an error RESPONSE of class 1437 'Permanent failure' (0x6) with response code 'Did not reach the 1438 NR' (0x07). This case may occur if the NTLP layer cannot find an 1439 NATFW NSLP peer, either another NF or the NR, and returns an error 1440 via the GIST API. The NSLP message processing at the NFs depends 1441 on the middlebox type: 1443 * NAT: When the initial CREATE message is received at the public 1444 side of the NAT, it looks for a reservation made in advance, by 1445 using a REA message (see Section 3.7.2). The matching process 1446 considers the received MRI information and the stored MRI 1447 information, as described in Section 3.8. If no matching 1448 reservation can be found, i.e. no reservation has been made in 1449 advance, the NSLP MUST return an error RESPONSE of class 1450 'Signaling session failure' (0x6) with response code 'No 1451 reservation found matching the MRI of the CREATE request' 1452 (0x03) MUST be generated. If there is a matching reservation, 1453 the NSLP stores the data sender's address (and if applicable 1454 port number) as part of the source address of the policy rule 1455 ('the remembered policy rule') to be loaded and forwards the 1456 message with the destination address set to the internal 1457 (private in most cases) address of NR. When the initial CREATE 1458 message is received at the private side, the NAT binding is 1459 allocated, but not activated (see also Appendix C.3). The MRI 1460 information is updated to reflect the address, and if 1461 applicable port, translation. The NSLP message is forwarded 1462 towards the NR with source address set to the NAT's external 1463 address from the newly remembered binding. 1465 * Firewall: When the initial CREATE message is received, the NSLP 1466 just remembers the requested policy rule, but does not install 1467 any policy rule. Afterwards, the message is forwarded towards 1468 the NR. 1470 * Combined NAT and firewall: Processing at combined firewall and 1471 NAT middleboxes is the same as in the NAT case. No policy 1472 rules are installed. Implementations MUST take into account 1473 the order of packet processing in the firewall and NAT 1474 functions within the device. This will be referred to as 1475 'order of functions' and is generally different depending on 1476 whether the packet arrives at the external or internal side of 1477 the middlebox. 1479 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1480 with a success RESPONSE of class 'Success' (0x2) with response 1481 code set to 'All successfully processed' (0x01), if they accept 1482 the CREATE request message. Otherwise they MUST generate a 1483 RESPONSE message with a suitable response code. RESPONSE messages 1484 are sent back NSLP hop-by-hop towards the NI, irrespective of the 1485 response codes, either success or error. 1487 Remembered policy rules at middleboxes MUST be only installed upon 1488 receiving a corresponding successful RESPONSE message with the same 1489 SID and MSN as the CREATE message that caused them to be remembered. 1490 This is a countermeasure to several problems, for example, wastage of 1491 resources due to loading policy rules at intermediate NFs when the 1492 CREATE message does not reach the final NR for some reason. 1494 Processing of a RESPONSE message is different for every NSIS node 1495 type: 1497 o NSLP initiator: After receiving a successful RESPONSE, the data 1498 path is configured and the DS can start sending its data to the 1499 DR. After receiving an error RESPONSE message, the NI MAY try to 1500 generate the CREATE message again or give up and report the 1501 failure to the application, depending on the error condition. 1503 o NSLP forwarder: NFs install the remembered policy rules, if a 1504 successful RESPONSE message with matching SID and MSN is received. 1505 If an ERROR RESPONSE message with matching SID and MSN is 1506 received, the session is marked as dead, no policy rule is 1507 installed and the remembered rule is discarded. 1509 o NSIS responder: The NR should never receive RESPONSE messages and 1510 MUST silently drop any such messages received. 1512 3.7.2. Reserving External Addresses 1514 NSIS signaling is intended to travel end-to-end, even in the presence 1515 of NATs and firewalls on-path. This works well in cases where the 1516 data sender is itself behind a NAT or a firewall as described in 1517 Section 3.7.1. For scenarios where the data receiver is located 1518 behind a NAT or a firewall and it needs to receive data flows from 1519 outside its own network (usually referred to as inbound flows, see 1520 Figure 5) the problem is more troublesome. 1522 NSIS signaling, as well as subsequent data flows, are directed to a 1523 particular destination IP address that must be known in advance and 1524 reachable. Data receivers must tell the local NSIS infrastructure 1525 (i.e., the upstream firewalls/NATs) about incoming NATFW NSLP 1526 signaling and data flows before they can receive these flows. It is 1527 necessary to differentiate between data receivers behind NATs and 1528 behind firewalls for understanding the further NATFW procedures. 1529 Data receivers that are only behind firewalls already have a public 1530 IP address and they need only to be reachable for NATFW signaling. 1531 Unlike data receivers behind just firewalls, data receivers behind 1532 NATs do not have public IP addresses; consequently they are not 1533 reachable for NATFW signaling by entities outside their addressing 1534 realm. 1536 The preceding discussion addresses the situation where a DR node that 1537 wants to be reachable is unreachable because the NAT lacks a suitable 1538 rule with the 'allow' action which would forward inbound data. 1539 However, in certain scenarios, a node situated behind upstream 1540 firewalls that do not block inbound data traffic (firewalls with 1541 "default to allow") unless requested might wish to prevent traffic 1542 being sent to it from specified addresses. In this case, NSIS NATFW 1543 signaling can be used to achieve this by installing a policy rule 1544 with its action set to 'deny' using the same mechanisms as for 1545 'allow' rules. 1547 The required result is obtained by sending a RESERVE-EXTERNAL-ADDRESS 1548 (REA) message in the upstream direction of the intended data flow. 1549 When using this functionality the NSIS initiator for the 'Reserve 1550 External Address' signaling is typically the node that will become 1551 the DR for the eventual data flow. To distinguish this initiator 1552 from the usual case where the NI is associated with the DS, the NI is 1553 denoted by NI+ and the NSIS responder is similarly denoted by NR+. 1555 Public Internet Private Address 1556 Space 1558 Edge 1559 NI(DS) NAT/FW NAT NR(DR) 1560 NR+ NI+ 1562 | | | | 1563 | | | | 1564 | | | | 1565 | | REA[(DTInfo)] | REA[(DTInfo)] | 1566 | |<----------------------|<----------------------| 1567 | | | | 1568 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1569 | |---------------------->|---------------------->| 1570 | | | | 1571 | | | | 1573 ============================================================> 1574 Data Traffic Direction 1576 Figure 15: Reservation message flow for DR behind NAT or firewall 1578 Figure 15 shows the REA message flow for enabling inbound NATFW NSLP 1579 signaling messages. In this case the roles of the different NSIS 1580 entities are: 1582 o The data receiver (DR) for the anticipated data traffic is the 1583 NSIS initiator (NI+) for the RESERVE-EXTERNAL-ADDRESS (REA) 1584 message, but becomes the NSIS responder (NR) for following CREATE 1585 messages. 1587 o The actual data sender (DS) will be the NSIS initiator (NI) for 1588 later CREATE messages and may be the NSIS target of the signaling 1589 (NR+). 1591 o It may be necessary to use a signaling destination address (SDA) 1592 as the actual target of the REA message (NR+) if the DR is located 1593 behind a NAT and the address of the DS is unknown. The SDA is an 1594 arbitrary address in the outermost address realm on the other side 1595 of the NAT from the DR. Typically this will be a suitable public 1596 IP address when the 'outside' realm is the public Internet. This 1597 choice of address causes the REA message to be routed through the 1598 NATs towards the outermost realm and would force interception of 1599 the message by the outermost NAT in the network at the boundary 1600 between the private address and the public address realm (the 1601 edge-NAT). It may also be intercepted by other NATs and firewalls 1602 on the path to the edge-NAT. 1604 Basically, there are two different signaling scenarios. Either 1606 1. the DR behind the NAT/firewall knows the IP address of the DS in 1607 advance, 1609 2. or the address of DS is not known in advance. 1611 Case 1 requires the NATFW NSLP to request the path-coupled message 1612 routing method (PC-MRM) from the NTLP. The REA message MUST be sent 1613 with PC-MRM (see Section 5.8.1 in [2]) with the direction set to 1614 'upstream'. The handling of case 2 depends on the situation of DR: 1615 If DR is solely located behind a firewall, the REA message MUST be 1616 sent with the PC-MRM, direction 'upstream', and data flow source IP 1617 address set to wildcard. If DR is located behind a NAT, the REA 1618 message MUST be sent with the loose-end message routing method (LE- 1619 MRM, see Section 5.8.2 in [2]), the destination-address set to the 1620 signaling destination address (SDA, see also Appendix A). For 1621 scenarios with DR being behind a firewall, special conditions apply 1622 (applicability statement, Appendix B). The data receiver is 1623 challenged to determine whether it is solely located behind firewalls 1624 or NATs, for choosing the right message routing method. This 1625 decision can depend on a local configuration parameter, possibly 1626 given through DHCP, or it could be discovered through other non-NSLP 1627 related testing of the network configuration. 1629 For case 2 with NAT, the NI+ (which could be on the data receiver DR 1630 or on any other host within the private network) sends the REA 1631 message targeted to the signaling destination address. The message 1632 routing for the REA message is in the reverse direction to the normal 1633 message routing used for path-coupled signaling where the signaling 1634 is sent downstream (as opposed to upstream in this case). When 1635 establishing NAT bindings (and an NSIS session) the signaling 1636 direction does not matter since the data path is modified through 1637 route pinning due to the external IP address at the NAT. Subsequent 1638 NSIS messages (and also data traffic) will travel through the same 1639 NAT boxes. However, this is only valid for the NAT boxes, but not 1640 for any intermediate firewall. That is the reason for having a 1641 separate CREATE message enabling the reservations made with REA at 1642 the NATs and either enabling prior reservations or creating new 1643 pinholes at the firewalls which are encountered on the downstream 1644 path depending on whether the upstream and downstream routes 1645 coincide. 1647 The REA signaling message creates an NSIS NATFW session at any 1648 intermediate NSIS NATFW peer(s) encountered, independent of the 1649 message routing method used. Furthermore, it has to be ensured that 1650 the edge-NAT or edge-firewall device is discovered as part of this 1651 process. The end host cannot be assumed to know this device - 1652 instead the NAT or firewall box itself is assumed to know that it is 1653 located at the outer perimeter of the network. Forwarding of the REA 1654 message beyond this entity is not necessary, and MUST be prohibited 1655 as it may provide information on the capabilities of internal hosts. 1656 It should be noted, that it is the outermost NAT or firewall that is 1657 the edge-device that must be found during this discovery process. 1658 For instance, when there are a NAT and afterwards a firewall on the 1659 outbound path at the network border, the firewall is the edge- 1660 firewall. All messages must be forwarded to the topology-wise 1661 outermost edge-device, to ensure that this devices knows about the 1662 signaling sessions for incoming CREATE messages. However, the NAT is 1663 still the edge-NAT because it has a public globally routable IP 1664 address on its public side: this is not affected by any firewall 1665 between the edge-NAT and the public network. 1667 Possible edge arrangements are: 1669 Public Net ----------------- Private net -------------- 1671 | Public Net|--|Edge-FW|--|FW|...|FW|--|DR| 1673 | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR| 1675 | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR| 1677 The edge-NAT or edge-firewall device closest to the public realm 1678 responds to the REA message with a successful RESPONSE message. An 1679 edge-NAT includes an NATFW_EXT_IP object (see Section 4.2.2), 1680 carrying the public reachable IP address, and if applicable port 1681 number. 1683 There are several processing rules for a NATFW peer when generating 1684 and receiving REA messages, since this message type is used for 1685 creating new reserve signaling sessions, updating existing, extending 1686 the lifetime and deleting signaling session. The three latter 1687 functions operate in the same way for all kinds of request message, 1688 and are therefore described in separate sections: 1690 o Extending the lifetime of signaling sessions is described in 1691 Section 3.7.3. 1693 o Deleting signaling sessions is described in Section 3.7.4. 1695 o Updating policy rules is described in Section 3.10. 1697 The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message 1698 when using the LE-MRM. The LE-MRM does not include enough 1699 information for some types of NATs (basically, those NATs which also 1700 translate port numbers) to perform the address translation. This 1701 information is provided in the NATFW_DTINFO_IPv4 (see Section 4.2.7). 1702 This information SHOULD include at least the 'dst port number' and 1703 'protocol' fields, in the DTInfo object as these may be required by 1704 en-route NATs, depending on the type of the NAT. All other fields 1705 MAY be set by the NI+ to restrict the set of possible NIs. An edge- 1706 NAT will use the information provided in the NATFW_DTINFO_IPv4 object 1707 to allow only NATFW CREATE message with the MRI matching ('src 1708 IPv4/v6 address', 'src port number', 'protocol') to be forwarded. A 1709 NAT requiring information carried in the NATFW_DTINFO_IPv4 can 1710 generate a number of error RESPONSE messages of class 'Signaling 1711 session failures' (0x6): 1713 o 'Requested policy rule denied due to policy conflict' (0x04) 1715 o 'DTINFO object is required' (0x07) 1717 o 'Requested value in sub_ports field in NATFW_EFI not permitted' 1718 (0x08) 1720 o 'Requested IP protocol not supported' (0x09) 1722 o 'Plain IP policy rules not permitted -- need transport layer 1723 information' (0x0A) 1725 o 'source IP address range is too large' (0x0C) 1727 o 'destination IP address range is too large' (0x0D) 1729 o 'source L4-port range is too large' (0x0E) 1731 o 'destination L4-port range is too large' (0x0F) 1733 Processing of REA messages is specific to the NSIS node type: 1735 o NSLP initiator: NI+ only generate REA messages. When the data 1736 sender's address information is known in advance the NI+ MAY 1737 include a NATFW_DTINFO_IPv4 object in the REA message (as 1738 described above). When the data sender's IP address is not known, 1739 the NI+ MUST NOT include a NATFW_DTINFO_IPv4 object. The NI 1740 should never receive request messages and MUST silently discard 1741 it. 1743 o NSLP forwarder: The NSLP message processing at NFs depends on the 1744 middlebox type: 1746 * NAT: NATs check whether the message is received at the external 1747 (public in most cases) address or at the internal (private) 1748 address. If received at the external address a NF MUST 1749 generate an error RESPONSE of class 'Protocol error' (0x3) with 1750 response code 'Received REA request message on external side' 1751 (0x0B) MUST be generated. If received at the internal (private 1752 address) and the NATFW_EFI object contains the action 'deny', 1753 an error RESPONSE of class 'Protocol error' (0x3) with response 1754 code 'Requested rule action not applicable' (0x06) MUST be 1755 generated. If received at the internal address, an IP address, 1756 and if applicable a port, is reserved. If it is an edge-NAT 1757 and there is no edge-firewall beyond, the NSLP message is not 1758 forwarded any further and a successful RESPONSE message is 1759 generated containing an NATFW_EXT_IP object holding the 1760 translated address, and if applicable port, information in the 1761 binding reserved as a result of the REA message. The RESPONSE 1762 message is sent back towards the NI+. If it is not an edge- 1763 NAT, the NSLP message is forwarded further using the translated 1764 IP address as signaling source address and including the 1765 translated IP address/port in the MRI. The edge-NAT or any 1766 other NAT MAY reject REA messages not carrying a 1767 NATFW_DTINFO_IPv4 object or if the address information within 1768 this object is invalid or is not compliant with local policies 1769 (e.g., the information provided relates to a range of addresses 1770 ('wildcarded') but the edge-NAT requires exact information 1771 about DS' IP address and port) with the above mentioned 1772 response codes. 1774 * Firewall: Non edge-firewalls remember the requested policy 1775 rule, keep session state, and forward the message. Edge- 1776 firewalls stop forwarding the request message. The policy rule 1777 is immediately loaded if the action in the NATFW_EFI object is 1778 set to 'deny' and the node is an edge-firewall. The policy 1779 rule is remembered, but not activated, if the action in the 1780 NATFW_EFI object is set to 'allow'. In both cases, a 1781 successful RESPONSE message is generated. 1783 * Combined NAT and firewall: Processing at combined firewall and 1784 NAT middleboxes is the same as in the NAT case. 1786 o NSLP receiver: This type of message should never be received by 1787 any NR+ and it MUST generate an error RESPONSE message of class 1788 'Permanent failure' (0x5) with response code 'No edge-device here' 1789 (0x06). 1791 Processing of a RESPONSE message is different for every NSIS node 1792 type: 1794 o NSLP initiator: Upon receiving a successful RESPONSE message, the 1795 NI+ can rely on the requested configuration for future inbound 1796 sessions. If the response contains an NATFW_EXT_IP object, the NI 1797 can use IP address and port pairs carried for further application 1798 signaling. After receiving a error RESPONSE message, the NI+ MAY 1799 try to generate the REA message again or give up and report the 1800 failure to the application, depending on the error condition. 1802 o NSLP forwarder: NFs simply forward this message as long as they 1803 keep state for the requested reservation, if the RESPONSE message 1804 contains NATFW_INFO object with class set to 'Success' (0x2). If 1805 the RESPONSE message contains NATFW_INFO object with class set not 1806 to 'Success' (0x2), the session is marked as dead. 1808 o NSIS responder: This type of message should never be received by 1809 any NR+. The NF should never receive response messages and MUST 1810 silently discard it. 1812 Reservations with action 'allow' made with REA MUST be enabled by a 1813 subsequent CREATE message. A reservation made with REA (independent 1814 of selected action) is kept alive as long as the NI+ refreshes the 1815 particular signaling session and it can be reused for multiple, 1816 different CREATE messages. An NI+ may decide to teardown a 1817 reservation immediately after receiving a CREATE message. Without 1818 using CREATE Section 3.7.1 or REA in proxy mode Section 3.7.7 no data 1819 traffic will be forwarded to DR beyond the edge-NAT or edge-firewall. 1820 The only function of REA is to ensure that subsequent CREATE messages 1821 traveling towards the NR will be forwarded across the public-private 1822 boundary towards the DR. Correlation of incoming CREATE messages to 1823 REA reservation states is described in Section 3.8. 1825 3.7.3. NATFW Session Refresh 1827 NATFW NSLP sessions are maintained on a soft-state basis. After a 1828 specified timeout, sessions and corresponding policy rules are 1829 removed automatically by the middlebox, if they are not refreshed. 1830 Soft-state is created by CREATE and REA and the maintenance of this 1831 state must be done by these messages. State created by CREATE must 1832 be maintained by CREATE, state created by REA must be maintained by 1833 REA. Refresh messages, are messages carrying the same session ID as 1834 the initial message and a NATFW_LT lifetime object with a lifetime 1835 greater than zero. Messages with the same SID but carrying a 1836 different MRI are treated as updates of the policy rules and are 1837 processed as defined in Section 3.10. Every refresh request message 1838 MUST be acknowledged by an appropriate response message generated by 1839 the NR. Upon reception by each NSIS forwarder, the state for the 1840 given session ID is extended by the session refresh period, a period 1841 of time calculated based on a proposed refresh message period. The 1842 lifetime extension of a session is calculated as current local time 1843 plus proposed lifetime value (session refresh period). Section 3.4 1844 defines the process of calculating lifetimes in detail. 1846 NI Public Internet NAT Private address NR 1848 | | space | 1849 | CREATE[lifetime > 0] | | 1851 |----------------------------->| | 1852 | | | 1853 | | | 1854 | | CREATE[lifetime > 0] | 1855 | |--------------------------->| 1856 | | | 1857 | | RESPONSE[Success/Error] | 1858 | RESPONSE[Success/Error] |<---------------------------| 1859 |<-----------------------------| | 1860 | | | 1861 | | | 1863 Figure 17: Successful Refresh Message Flow, CREATE as example 1865 Processing of session refresh CREATE and REA messages is different 1866 for every NSIS node type: 1868 o NSLP initiator: The NI/NI+ can generate session refresh CREATE/REA 1869 messages before the session times out. The rate at which the 1870 refresh CREATE/REA messages are sent and their relation to the 1871 session state lifetime is discussed further in Section 3.4. 1873 o NSLP forwarder: Processing of this message is independent of the 1874 middlebox type and is as described in Section 3.4. 1876 o NSLP responder: NRs accepting a session refresh CREATE/REA message 1877 generate a successful RESPONSE message, including the granted 1878 lifetime value of Section 3.4 in a NATFW_LT object. 1880 3.7.4. Deleting Sessions 1882 NATFW NSLP sessions can be deleted at any time. NSLP initiators can 1883 trigger this deletion by using a CREATE or REA messages with a 1884 lifetime value set to 0, as shown in Figure 18. Whether a CREATE or 1885 REA message type is used, depends on how the session was created. 1887 NI Public Internet NAT Private address NR 1889 | | space | 1890 | CREATE[lifetime=0] | | 1891 |----------------------------->| | 1892 | | | 1893 | | CREATE[lifetime=0] | 1894 | |--------------------------->| 1895 | | | 1897 Figure 18: Delete message flow, CREATE as example 1899 NSLP nodes receiving this message delete the session immediately. 1900 Policy rules associated with this particular session MUST be also 1901 deleted immediately. This message is forwarded until it reaches the 1902 final NR. The CREATE/REA request message with a lifetime value of 0, 1903 does not generate any response, neither positive nor negative, since 1904 there is no NSIS state left at the nodes along the path. 1906 NSIS initiators can use CREATE/REA message with lifetime set to zero 1907 in an aggregated way, such that a single request message is 1908 terminating multiple signaling sessions. NIs can follow this 1909 procedure if the like to aggregate session deletion requests: The NI 1910 uses the CREATE or REA request message with the session ID set to 1911 zero and the MRI's source-address set to its used IP address. All 1912 other fields of the respective sessions to be terminated are set as 1913 well, otherwise these fields are completely wildcarded. The NSLP 1914 message is transferred to the NTLP requesting 'explicit routing' as 1915 described in Sections 5.2.1 and 7.1.4. in [2]. 1917 The downstream NF receiving such an aggregated request message MUST 1918 reject the request with an error RESPONSE of class 'Permanent 1919 failure' (0x5) with response code 'Authentication failed' (0x01) if 1920 the authentication fails and with an error RESPONSE of class 1921 'Permanent failure' (0x5) with response code 'Authorization failed' 1922 (0x02) if the authorization fails. Per session proof of ownership, 1923 as it is defined in this memo, is not possible anymore when using 1924 this aggregated mode. However, the downstream NF can use the 1925 relationship between the information of the received request message 1926 and the GIST messaging association where the request has been 1927 received. The downstream NF MUST only accept this aggregated request 1928 message through already established GIST messaging associations with 1929 the NI. The downstream NF MUST NOT propagate this aggregated request 1930 message but it MAY generate and forward per session request messages. 1932 3.7.5. Reporting Asynchronous Events 1934 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 1935 to report asynchronous events to other NATFW NSLP nodes, especially 1936 to allow reporting back to the NATFW NSLP initiator. Such 1937 asynchronous events may be premature session termination, changes in 1938 local policies, route change or any other reason that indicates 1939 change of the NATFW NSLP session state. Currently, asynchronous 1940 session termination, re-authorization required and route change 1941 detected (see Section 3.9) are the only events that are defined, but 1942 other events may be defined in later revisions of this memo. 1944 NFs and NRs may generate NOTIFY messages upon asynchronous events, 1945 with a NATFW_INFO object indicating the reason for event. These 1946 reasons can be carried in the NATFW_INFO object (class MUST be set to 1947 'Informational' (0x1)) within the NOTIFY message. This list shows 1948 the response codes and the associated actions to take at NFs and the 1949 NI: 1951 o 'Route change: possible route change on the downstream path' 1952 (0x01): Follow instructions in Section 3.9. 1954 o 'Re-authentication required' (0x02): The NI should re-send the 1955 authentication. 1957 o 'NATFW node is going down soon' (0x03): The NI and other NFs 1958 should be prepared for a service interruption at any time. 1960 NOTIFY messages are sent hop-by-hop upstream towards NI until they 1961 reach NI. 1963 The initial processing when receiving a NOTIFY message is the same 1964 for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages 1965 through already established NTLP messaging associations. The further 1966 processing is different for each NATFW NSLP node type and depends on 1967 the events notified: 1969 o NSLP initiator: NIs analyze the notified event and behave 1970 appropriately based on the event type. NIs MUST NOT generate 1971 NOTIFY messages. 1973 o NSLP forwarder: NFs analyze the notified event and behave based on 1974 the above description per response code. NFs SHOULD generate 1975 NOTIFY messages upon asynchronous events and forward them upstream 1976 towards the NI. 1978 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 1979 asynchronous events including a response code based on the 1980 reported event. The NF should never receive NOTIFY messages and 1981 MUST silently discard it. 1983 NATFW NSLP forwarders, keeping multiple signaling sessions at the 1984 same time, can experience problems when shutting down service 1985 suddenly. This sudden shutdown can be result of node local failure, 1986 for instance, due to a hardware failure. This NF generates NOTIFY 1987 messages for each of the signaling sessions and tries to send them 1988 upstream. Due to the number of NOTIFY messages to be sent, the 1989 shutdown of the node may be unnecessarily prolonged, since not all 1990 messages can be sent at the same time. This case can be described as 1991 a NOTIFY storm, if a multitude of signaling sessions is involved. 1993 To avoid the need of generating per signaling session NOTIFY messages 1994 in such a scenario described or similar cases, NFs SHOULD follow this 1995 procedure: The NF uses the NOTIFY message with the session ID in the 1996 NTLP set to zero, with the MRI completely wildcarded, using the 1997 'explicit routing' as described in Sections 5.2.1 and 7.1.4. in [2]. 1998 The upstream NF receiving this type of NOTIFY immediately regards all 1999 signaling sessions from that peer matching the MRI as void. This 2000 message will typically result in multiple NOTIFY messages at the 2001 upstream NF, i.e., the NF can generate per terminated session a 2002 NOTIFY message. However, a NF MAY aggregate again the NOTIFY 2003 messages as described here. 2005 3.7.6. Tracing Signaling Sessions 2007 The NATFW NSLP provides a diagnosis capability to session owners (the 2008 NI or NI+). Session owners are able to trace the NSIS nodes being 2009 involved in a particular signaling session. The TRACE request 2010 message is used to trace the involved NSIS nodes along the signaling 2011 session and to return their identifiers. 2013 NI Public Internet NAT Private address NR 2015 | | space | 2016 | TRACE | | 2017 |----------------------------->| | 2018 | | | 2019 | | TRACE | 2020 | |--------------------------->| 2021 | | | 2022 | | RESPONSE[IP(NR)] | 2023 | |<---------------------------| 2024 | RESPONSE[IP(NR),IP(NAT)] | | 2025 |<-----------------------------| | 2026 | | | 2027 | | | 2029 Figure 19: Example for tracing the signaling session path 2030 The processing when receiving a TRACE message is the different for 2031 each type of NATFW node: 2033 o NSLP initiator: NI generates TRACE request messages. The NI 2034 should never receive request messages and MUST silently discard 2035 it. 2037 o NSLP forwarder: NFs solely forward the message if their local 2038 policies permits tracing. A NF MUST generate an error RESPONSE of 2039 class 'Permanent failure' (0x6) with response code 'Tracing is not 2040 allowed' (0x08) if the local policies do not allow tracing. 2042 o NSLP responder: NRs receiving a TRACE request message terminate 2043 the forwarding and reply with a successful RESPONSE message. The 2044 NATFW_TRACE object MAY be filled by the NR with its IP address. 2046 Processing of a RESPONSE message to a TRACE request message is 2047 different for every NSIS node type: 2049 o NSLP initiator: The NI terminates the forwarding and checks the 2050 response message for further local processing. 2052 o NSLP forwarder: NFs MAY include their identifier in the 2053 NATFW_TRACE object and increment the 'hop count' field by one. 2054 This memo defines IPv4 and IPv6 IP addresses as possible de 2055 identifier. NFs MUST forward this type of RESPONSE. 2057 o NSLP responder: A NR should never see such a RESPONSE message and 2058 it MUST silently discard it. 2060 3.7.7. Proxy Mode of Operation 2062 Some migration scenarios need specialized support to cope with cases 2063 where NSIS is only deployed in same areas of the Internet. End-to- 2064 end signaling is going to fail without NSIS support at or near both 2065 data sender and data receiver terminals. A proxy mode of operation 2066 is needed. This proxy mode of operation must terminate the NATFW 2067 NSLP signaling as topologically close to the terminal for which it is 2068 proxying and proxy all request and response messages. This NATFW 2069 NSLP node doing the proxying of the signaling messages becomes either 2070 the NI or the NR for the particular signaling session, depending on 2071 whether it is the DS or DR that does not support NSIS. Typically, 2072 the edge-NAT or the edge-firewall would be used to proxy NATFW NSLP 2073 messages. 2075 This proxy mode operation does not require any new request message 2076 type, but relies on extended CREATE and REA message types. They are 2077 called respectively CREATE-PROXY and REA-PROXY and are distinguished 2078 by setting the P flag in the NSLP header is set to P=1. This flag 2079 instructs edge-NATs and edge-firewalls receiving them to operate in 2080 proxy mode for the session in question. The semantics of the CREATE 2081 and REA message types are not changed and the behavior of the various 2082 node types is as defined in Section 3.7.1 and Section 3.7.2, except 2083 for the proxying node. The following paragraphs describe the proxy 2084 mode operation for data receivers behind middleboxes and data senders 2085 behind middleboxes. 2087 3.7.7.1. Proxying for a Data Sender 2089 The NATFW NSLP gives the NR the ability to install state on the 2090 upstream path towards the data sender for downstream data packets, 2091 even when only the receiving side is running NSIS (as shown in 2092 Figure 20). The goal of the method described is to trigger the edge- 2093 NAT/edge-firewall to generate a CREATE message on behalf of the data 2094 receiver. In this case, a NR can signal towards the network border 2095 as it is performed in the standard REA message handling scenario as 2096 in Section 3.7.2. The message is forwarded until the edge-NAT/ 2097 edge-firewall is reached. A public IP address and port number is 2098 reserved at an edge-NAT/edge-firewall. As shown in Figure 20, unlike 2099 the standard REA message handling case, the edge-NAT/edge-firewall is 2100 triggered to send a CREATE message on a new reverse path which 2101 traverse several firewalls or NATs. The new reverse path for CREATE 2102 is necessary to handle routing asymmetries between the edge-NAT/ 2103 edge-firewall and DR. It must be stressed that the semantics of the 2104 CREATE and REA request messages is not changed, i.e., each is 2105 processed as described earlier. 2107 DS Public Internet NAT/FW Private address NR 2108 No NI NF space NI+ 2109 NR+ 2111 | | REA-PROXY[(DTInfo)] | 2112 | |<------------------------- | 2113 | | RESPONSE[Error/Success] | 2114 | | ---------------------- > | 2115 | | CREATE | 2116 | | ------------------------> | 2117 | | RESPONSE[Error/Success] | 2118 | | <---------------------- | 2119 | | | 2121 Figure 20: REA Triggering Sending of CREATE Message 2123 A NATFW_NONCE object, carried in the REA and CREATE message, is used 2124 to build the relationship between received CREATEs at the message 2125 initiator. An NI+ uses the presence of the NATFW_NONCE object to 2126 correlate it to the particular REA-PROXY request. The absence of an 2127 NONCE object indicates a CREATE initiated by the DS and not by the 2128 edge-NAT. Therefore, these processing rules of REA-PROXY messages 2129 are added to the regular REA processing: 2131 o NSLP initiator (NI+): The NI+ MUST choose a random value and place 2132 it in the NATFW_NONCE object. 2134 o NSLP forwarder being either edge-NAT or edge-firewall: When the NF 2135 accepts a REA_PROXY message, it generates a successful RESPONSE 2136 message as if it were the NR and additionally, it generates a 2137 CREATE message as defined in Section 3.7.1 and includes a 2138 NATFW_NONCE object having the same value as of the received 2139 NATFW_NONCE object. The NF MUST not generate a CREATE-PROXY 2140 message. The NF MUST refresh the CREATE message session only if a 2141 REA-PROXY refresh message has been received first. 2143 The scenario described in this section challenges the data receiver 2144 because it must make a correct assumption about the data sender's 2145 ability to use NSIS NATFW NSLP signaling. It is possible for the DR 2146 to make the wrong assumption in two different ways: 2148 a) the DS is NSIS unaware but the DR assumes the DS to be NSIS 2149 aware and 2151 b) the DS is NSIS aware but the DR assumes the DS to be NSIS 2152 unaware. 2154 Case a) will result in middleboxes blocking the data traffic, since 2155 DS will never send the expected CREATE message. Case b) will result 2156 in the DR successfully requesting proxy mode support by the edge-NAT 2157 or edge-firewall. The edge-NAT/edge-firewall will send CREATE 2158 messages and DS will send CREATE messages as well. Both CREATE 2159 messages are handled as separated sessions and therefore the common 2160 rules per session apply; the NATFW_NONCE object is used to 2161 differentiate CREATE messages generated by the edge-NAT/edge-firewall 2162 from NI initiated CREATE messages. It is the NR's responsibility to 2163 decide whether to teardown the REA-PROXY sessions in the case where 2164 the data sender's side is NSIS aware, but was incorrectly assumed not 2165 to be so by the DR. It is RECOMMENDED that a DR behind NATs uses the 2166 proxy mode of operation by default, unless the DR knows that the DS 2167 is NSIS aware. The DR MAY cache information about data senders which 2168 it has found to be NSIS aware in past sessions. 2170 There is a possible race condition between the RESPONSE message to 2171 the REA-PROXY and the CREATE message generated by the edge-NAT. The 2172 CREATE message can arrive earlier than the RESPONSE message. An NI+ 2173 MUST accept CREATE messages generated by the edge-NAT even if the 2174 RESPONSE message to the REA-PROXY request was not received. 2176 3.7.7.2. Proxying for a Data Receiver 2178 As with data receivers behind middleboxes, data senders behind 2179 middleboxes can require proxy mode support. The issue here is that 2180 there is no NSIS support at the data receiver's side and, by default, 2181 there will be no response to CREATE request messages. This scenario 2182 requires the last NSIS NATFW NSLP aware node to terminate the 2183 forwarding and to proxy the response to the CREATE message, meaning 2184 that this node is generating RESPONSE messages. This last node may 2185 be an edge-NAT/edge-firewall, or any other NATFW NSLP peer, that 2186 detects that there is no NR available (probably as a result of GIST 2187 timeouts but there may be other triggers). 2189 DS Private Address NAT/FW Public Internet NR 2190 NI Space NF no NR 2192 | | | 2193 | CREATE-PROXY | | 2194 |------------------------------>| | 2195 | | | 2196 | RESPONSE[SUCCESS/ERROR] | | 2197 |<------------------------------| | 2198 | | | 2200 Figure 21: Proxy Mode CREATE Message Flow 2202 The processing of CREATE-PROXY messages and RESPONSE messages is 2203 similar to Section 3.7.1, except that forwarding is stopped at the 2204 edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to 2205 NI according the situation (error/success) and will be the NR for 2206 future NATFW NSLP communication. 2208 The NI can choose the proxy mode of operation although the DR is NSIS 2209 aware. The CREATE-PROXY mode would not configure all NATs and 2210 firewalls along the data path, since it is terminated at the edge- 2211 device. Any device beyond this point will never received any NATFW 2212 NSLP signaling for this flow. 2214 3.8. De-Multiplexing at NATs 2216 Section 3.7.2 describes how NSIS nodes behind NATs can obtain a 2217 public reachable IP address and port number at a NAT and and how the 2218 resulting mapping rule can be activated by using CREATE messages (see 2219 Section 3.7.1). The information about the public IP address/port 2220 number can be transmitted via an application level signaling protocol 2221 and/or third party to the communication partner that would like to 2222 send data toward the host behind the NAT. However, NSIS signaling 2223 flows are sent towards the address of the NAT at which this 2224 particular IP address and port number is allocated and not directly 2225 to the allocated IP address and port number. The NATFW NSLP 2226 forwarder at this NAT needs to know how the incoming NSLP requests 2227 are related to reserved addresses, meaning how to de-multiplex 2228 incoming NSIS requests. 2230 The de-multiplexing method uses information stored at the local NATFW 2231 NSLP node and the of the policy rule. The policy rule uses the LE- 2232 MRM MRI source-address (see [2]) as the flow destination IP address 2233 and the network-layer-version as IP version. The external IP address 2234 at the NAT is stored as the external flow destination IP address. 2235 All other parameters of the policy rule other than the flow 2236 destination IP address are wildcarded if no NATFW_DTINFO_IPv4 object 2237 is included in the REA request message. The LE-MRM MRI destination- 2238 address MUST NOT be used in the policy rule, since it is solely a 2239 signaling destination address. 2241 If the NATFW_DTINFO_IPv4 object is included in the REA request 2242 message, the policy rule is filled with further information. The 2243 'dst port number' field of the NATFW_DTINFO_IPv4 is stored as the 2244 flow destination port number. The 'protocol' field is stored as the 2245 flow protocol. The 'src port number' field is stored as the flow 2246 source port number. The 'data sender's IPv4 address' is stored as 2247 the flow source IP address. Note that some of these field can 2248 contain wildcards. 2250 When receiving a CREATE message at the NATFW NSLP it uses the flow 2251 information stored in the MRI to do the matching process. This table 2252 shows the parameters to be compared against each others. Note that 2253 not all parameters can be present in a MRI at the same time. 2255 +-------------------------------+--------------------------------+ 2256 | Flow parameter (Policy Rule) | MRI parameter (CREATE message) | 2257 +-------------------------------+--------------------------------+ 2258 | IP version | network-layer-version | 2259 | | | 2260 | Protocol | IP-protocol | 2261 | | | 2262 | source IP address (w) | source-address (w) | 2263 | | | 2264 | external IP address | destination-address | 2265 | | | 2266 | destination IP address (n/u) | N/A | 2267 | | | 2268 | source port number (w) | L4-source-port (w) | 2269 | | | 2270 | external port number (w) | L4-destination-port (w) | 2271 | | | 2272 | destination port number (n/u) | N/A | 2273 | | | 2274 | IPsec SPI | ipsec-SPI | 2275 +-------------------------------+--------------------------------+ 2277 Table entries marked with (w) can be wildcarded and entries marked 2278 with (n/u) are not used for the matching. 2280 Table 1 2282 3.9. Reacting to Route Changes 2284 The NATFW NSLP needs to react to route changes in the data path. 2285 This assumes the capability to detect route changes, to perform NAT 2286 and firewall configuration on the new path and possibly to tear down 2287 session state on the old path. The detection of route changes is 2288 described in Section 7 of [2] and the NATFW NSLP relies on 2289 notifications about route changes by the NTLP. This notification 2290 will be conveyed by the API between NTLP and NSLP, which is out of 2291 scope of this memo. 2293 A NATFW NSLP node other than the NI or NI+ detecting a route change, 2294 by means described in the NTLP specification or others, generates a 2295 NOTIFY message indicating this change and sends this upstream towards 2296 NI. Intermediate NFs on the way to the NI can use this information 2297 to decide later if their session can be deleted locally, if they do 2298 not receive an update within a certain time period, as described in 2299 Section 3.2.3. It is important to consider the transport limitations 2300 of NOTIFY messages as mandated in Section 3.7.5. 2302 The NI receiving this NOTIFY message MAY generate a new request 2303 CREATE or REA message and sends it respectively downstream or 2304 upstream as for the initial exchange using the same session ID. All 2305 the remaining processing and message forwarding, such as NSLP next 2306 hop discovery, is subject to regular NSLP processing as described in 2307 the particular sections. Normal routing will guide the new request 2308 to the correct NFs along the changed route. NFs that were on the 2309 original path receiving these new request messages (see also 2310 Section 3.10), can use the session ID to update the existing session, 2311 whereas NFs that were not on the original path will create new state 2312 for this session. The next section describes how policy rules are 2313 updated. 2315 3.10. Updating Policy Rules 2317 NSIS initiators can request an update of the installed/reserved 2318 policy rules at any time within a signaling session. Updates to 2319 policy rules can be required due to node mobility (NI is moving from 2320 one IP address to another), route changes (this can result in a 2321 different NAT mapping at a different NAT device), or the wish of the 2322 NI to simply change the rule. NIs can update policy rules in 2323 existing signaling sessions by sending an appropriate request message 2324 (similar to Section 3.4) with modified message routing information 2325 (MRI) as compared with that installed previously, but using the 2326 existing session ID to identify the intended target of the update. 2327 With respect to authorization and authentication, this update request 2328 message is treated in exactly the same way as any initial request. 2329 Therefore, any node along in the signaling session can reject the 2330 update with an error RESPONSE message, as defined in the previous 2331 sections. 2333 The request/response message processing and forwarding is executed as 2334 defined in the those sections. A NF or the NR receiving an update, 2335 simply replaces the installed policy rules installed in the firewall/ 2336 NAT. The local procedures on how to update the MRI in the firewall/ 2337 NAT is out of scope of this memo. 2339 4. NATFW NSLP Message Components 2341 A NATFW NSLP message consists of a NSLP header and one or more 2342 objects following the header. The NSLP header is common for all 2343 NSLPs and objects are Type-Length-Value (TLV) encoded using big 2344 endian (network ordered) binary data representations. Header and 2345 objects are aligned to 32 bit boundaries and object lengths that are 2346 not multiples of 32 bits must be padded to the next higher 32 bit 2347 multiple. 2349 The whole NSLP message is carried as payload of a NTLP message. 2351 Note that the notation 0x is used to indicate hexadecimal numbers. 2353 4.1. NSLP Header 2355 All GIST NSLP-Data objects for the NATFW NSLP MUST contain this 2356 Common Header as the first 32 bits of the object (this is not the 2357 same as the GIST Common Header). It contains two fields, the NSLP 2358 message type and a reserved field. The total length is 32 bits. The 2359 layout of the NSLP header is defined by Figure 22. 2361 0 1 2 3 2362 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 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | Message type |P| reserved | reserved | 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 Figure 22: Common NSLP header 2369 The reserved field MUST be set to zero in the NATFW NSLP header 2370 before sending and MUST be ignored during processing of the header. 2372 The message types identify requests and responses. Defined messages 2373 types are: 2375 o IANA-TBD(1) : CREATE 2377 o IANA-TBD(2) : RESERVE-EXTERNAL-ADDRESS(REA) 2379 o IANA-TBD(3) : TRACE 2381 o IANA-TBD(4) : RESPONSE 2383 o IANA-TBD(5) : NOTIFY 2385 If a message with another type is received, an error RESPONSE of 2386 class 'Protocol error' (0x3) with response code 'Illegal message 2387 type' (0x01) MUST be generated. 2389 The P flag indicates the usage of proxy mode. If proxy mode is used 2390 it MUST be set to 1. Proxy mode usage is only allowed in combination 2391 with the message types CREATE and REA, P=1 MUST NOT be set with 2392 message types other than CREATE and REA. The P flag MUST be ignored 2393 when processing messages with type RESPONSE. An error RESPONSE 2394 message of class 'Protocol error' (0x3) and type 'Bad flags value' 2395 (0x03) MUST be generated, if the P flag is set in TRACE or NOTIFY 2396 messages. 2398 4.2. NSLP Objects 2400 NATFW NSLP objects use a common header format defined by Figure 23. 2401 The object header contains two fields, the NSLP object type and the 2402 object length. Its total length is 32 bits. 2404 0 1 2 3 2405 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 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2410 Figure 23: Common NSLP object header 2412 The object length field contains the total length of the object 2413 without the object header. The unit is a word, consisting of 4 2414 octets. The particular values of type and length for each NSLP 2415 object are listed in the subsequent sections that define the NSLP 2416 objects. An error RESPONSE of class 'Protocol error' (0x3) with 2417 response code 'Wrong object length' (0x07) MUST be generated if the 2418 length given for the object in the object header did not match the 2419 length of the object data present. The two leading bits of the NSLP 2420 object header are used to signal the desired treatment for objects 2421 whose treatment has not been defined in this memo (see [2], Section 2422 A.2.1), i.e., the Object Type has not been defined. NATFW NSLP uses 2423 a subset of the categories defined in GIST: 2425 o AB=00 ("Mandatory"): If the object is not understood, the entire 2426 message containing it MUST be rejected with an error RESPONSE of 2427 class 'Protocol error' (0x3) with response code 'Unknown object 2428 present' (0x06). 2430 o AB=01 ("Optional"): If the object is not understood, it should be 2431 deleted and then the rest of the message processed as usual. 2433 o AB=10 ("Forward"): If the object is not understood, it should be 2434 retained unchanged in any message forwarded as a result of message 2435 processing, but not stored locally. 2437 The combination AB=11 MUST NOT be used and an error RESPONSE of class 2438 'Protocol error' (0x3) with response code 'Invalid Flag-Field 2439 combination' (0x09) MUST be generated. 2441 The following sections do not repeat the common NSLP object header, 2442 they just name the type and the length. 2444 4.2.1. Session Lifetime Object 2446 The session lifetime object carries the requested or granted lifetime 2447 of a NATFW NSLP session measured in seconds. 2449 Type: NATFW_LT (IANA-TBD) 2451 Length: 1 2453 0 1 2 3 2454 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 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | NATFW NSLP session lifetime | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2459 Figure 24: Lifetime object 2461 4.2.2. External Address Object 2463 The external address object can be included in RESPONSE messages 2464 (Section 4.3.3) only. It carries the publicly reachable IP address, 2465 and if applicable port number, at an edge-NAT. 2467 Type: NATFW_EXT_IP (IANA-TBD) 2469 Length: 2 2471 0 1 2 3 2472 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 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | port number | reserved | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | IPv4 address | 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 Figure 25: External Address Object for IPv4 addresses 2481 Please note that the field 'port number' MUST be set to 0 if only an 2482 IP address has been reserved, for instance, by a traditional NAT. A 2483 port number of 0 MUST be ignored in processing this object. 2485 4.2.3. Extended Flow Information Object 2487 In general, flow information is kept in the message routing 2488 information (MRI) of the NTLP. Nevertheless, some additional 2489 information may be required for NSLP operations. The 'extended flow 2490 information' object carries this additional information about the 2491 action of the policy rule for firewalls/NATs and contiguous port . 2493 Type: NATFW_EFI (IANA-TBD) 2495 Length: 1 2497 0 1 2 3 2498 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 2499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2500 | rule action | sub_ports | 2501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 Figure 26: Extended Flow Information 2505 This object has two fields, 'rule action' and 'sub_ports'. The 'rule 2506 action' field has these meanings: 2508 o 0x0001: Allow: A policy rule with this action allows data traffic 2509 to traverse the middlebox and the NATFW NSLP MUST allow NSLP 2510 signaling to be forwarded. 2512 o 0x0002: Deny: A policy rule with this action blocks data traffic 2513 from traversing the middlebox and the NATFW NSLP MUST NOT allow 2514 NSLP signaling to be forwarded. 2516 If the 'rule action' field contains neither 0x0001 nor 0x0002, an 2517 error RESPONSE of class 'Signaling session error' (0x6) with response 2518 code 'Unknown policy rule action' (0x05) MUST be generated. 2520 The 'sub_ports' field contains the number of contiguous transport 2521 layer ports to which this rule applies. The default value of this 2522 field is 0, i.e., only the port specified in the NTLP's MRM is used 2523 for the policy rule. A value of 1 indicates that additionally to the 2524 port specified in the NTLP's MRM (port1), a second port (port2) is 2525 used. This value of port 2 is calculated as: port2 = port1 + 1. 2527 Other values than 0 or 1 MUST NOT be used in this field and an error 2528 RESPONSE of class 'Signaling session error' (0x6) with response code 2529 'Requested value in sub_ports field in NATFW_EFI not permitted' 2530 (0x08) MUST be generated. Further version of this memo may allow 2531 other values for the 'sub_ports' field. This two contiguous port 2532 numbered ports, can be used by legacy voice over IP equipment. This 2533 legacy equipment assumes that two adjacent port numbers for its RTP/ 2534 RTCP flows respectively. 2536 4.2.4. Information Code Object 2538 This object carries the response code, which may be indications for 2539 either a successful request or failed request depending on the value 2540 of the 'response code' field. 2542 Type: NATFW_INFO (IANA-TBD) 2544 Length: 1 2546 0 1 2 3 2547 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 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | Resv. | Class | Response Code | Object Type | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 Figure 27: Information Code Object 2554 The field 'resv.' is reserved for future extensions and MUST be set 2555 to zero when generating such an object and MUST be ignored when 2556 receiving. The 'Object Type' field contains the type of the object 2557 causing the error. The value of 'Object Type' is set to 0, if no 2558 object is concerned. The 4 bit class field contains the severity 2559 class. The following classes are defined: 2561 o 0x1: Informational (NOTIFY only) 2563 o 0x2: Success 2565 o 0x3: Protocol error 2567 o 0x4: Transient failure 2569 o 0x5: Permanent failure 2571 o 0x6: Signaling session failures 2573 Within each severity class a number of responses values are defined 2574 o Informational: 2576 * 0x01: Route change: possible route change on the downstream 2577 path. 2579 * 0x02: Re-authentication required. 2581 * 0x03: NATFW node is going down soon. 2583 o Success: 2585 * 0x01: All successfully processed. 2587 o Protocol error: 2589 * 0x01: Illegal message type: the type given in the Message Type 2590 field of the NSLP header is unknown. 2592 * 0x02: Wrong message length: the length given for the message in 2593 the NSLP header does not match the length of the message data. 2595 * 0x03: Bad flags value: an undefined flag or combination of 2596 flags was set in the NSLP header. 2598 * 0x04: Mandatory object missing: an object required in a message 2599 of this type was missing. 2601 * 0x05: Illegal object present: an object was present which must 2602 not be used in a message of this type. 2604 * 0x06: Unknown object present: an object of an unknown type was 2605 present in the message. 2607 * 0x07: Wrong object length: the length given for the object in 2608 the object header did not match the length of the object data 2609 present. 2611 * 0x08: Unknown object field value: a field in an object had an 2612 unknown value. 2614 * 0x09: Invalid Flag-Field combination: An object contains an 2615 invalid combination of flags and/or fields. 2617 * 0x0A: Duplicate object present. 2619 * 0x0B: Received REA request message on external side. 2621 o Transient failure: 2623 * 0x01: Requested resources temporarily not available. 2625 o Permanent failure: 2627 * 0x01: Authentication failed. 2629 * 0x02: Authorization failed. 2631 * 0x03: Unable to agree transport security with peer. 2633 * 0x04: Internal or system error. 2635 * 0x05: No NAT here. 2637 * 0x06: No edge-device here. 2639 * 0x07: Did not reach the NR. 2641 * 0x08: Tracing is not allowed. 2643 o Signaling session failures: 2645 * 0x01: Session terminated asynchronously. 2647 * 0x02: Requested lifetime is too big. 2649 * 0x03: No reservation found matching the MRI of the CREATE 2650 request. 2652 * 0x04: Requested policy rule denied due to policy conflict. 2654 * 0x05: Unknown policy rule action. 2656 * 0x06: Requested rule action not applicable. 2658 * 0x07: DTINFO object is required. 2660 * 0x08: Requested value in sub_ports field in NATFW_EFI not 2661 permitted. 2663 * 0x09: Requested IP protocol not supported. 2665 * 0x0A: Plain IP policy rules not permitted -- need transport 2666 layer information. 2668 * 0x0B: ICMP type value not permitted. 2670 * 0x0C: source IP address range is too large. 2672 * 0x0D: destination IP address range is too large. 2674 * 0x0E: source L4-port range is too large. 2676 * 0x0F: destination L4-port range is too large. 2678 * 0x10: Requested lifetime is too small. 2680 4.2.5. Nonce Object 2682 This object carries the nonce value as described in Section 3.7.7. 2684 Type: NATFW_NONCE (IANA-TBD) 2686 Length: 1 2688 0 1 2 3 2689 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 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | nonce | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 Figure 28: Nonce Object 2696 4.2.6. Message Sequence Number Object 2698 This object carries the MSN value as described in Section 3.5. 2700 Type: NATFW_MSN (IANA-TBD) 2702 Length: 1 2704 0 1 2 3 2705 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 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 | message sequence number | 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 Figure 29: Message Sequence Number Object 2712 4.2.7. Data Terminal Information Object 2714 The 'data terminal information' object carries additional information 2715 possibly needed during REA operations. REA messages are transported 2716 by the NTLP using the Loose-End message routing method (LE-MRM). The 2717 LE-MRM contains only DR's IP address and a signaling destination 2718 address (destination address). This destination address is used for 2719 message routing only and is not necessarily reflecting the address of 2720 the data sender. This object contains information about (if 2721 applicable) DR's port number (the destination port number), DS' port 2722 number (the source port number), the used transport protocol, the 2723 prefix length of the IP address, and DS' IP address. 2725 Type: NATFW_DTINFO_IPv4 (IANA-TBD) 2727 Length: 3 2729 0 1 2 3 2730 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 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 |I|P|S| reserved | sender prefix | protocol | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 : dst port number | src port number : 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 : IPsec SPI : 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | data sender's IPv4 address | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 Figure 30: Data Terminal IPv4 Address Object 2743 The flags are: 2745 o I: I=1 means that 'protocol' should be interpreted. 2747 o P: P=1 means that 'dst port number' and 'src port number' are 2748 present and should be interpreted. 2750 o S: S=1 means that SPI is present and should be interpreted. 2752 The SPI field is only present if S is set. The port numbers are only 2753 present if P is set. The flags P and S MUST NOT be set at the same 2754 time. An error RESPONSE of class 'Protocol error' (0x3) with 2755 response code 'Invalid Flag-Field combination' (0x09) MUST be 2756 generated if they are both set. If either P or S is set, I MUST be 2757 set as well and the protocol field MUST carry the particular 2758 protocol. An error RESPONSE of class 'Protocol error' (0x3) with 2759 response code 'Invalid Flag-Field combination' (0x09) MUST be 2760 generated if S or P is set but I is not set. 2762 The fields MUST be interpreted according these rules: 2764 o (data) sender prefix: This parameter indicates the prefix length 2765 of the 'data sender's IP address' in bits. For instance, a full 2766 IPv4 address requires 'sender prefix' to be set to 32. A value of 2767 0 indicates an IP address wildcard. 2769 o protocol: The IPv4 protocol field. This field MUST be interpreted 2770 if I=1, otherwise it MUST be set to 0 and MUST be ignored. 2772 o dst port number: A value of 0 indicates a port wildcard, i.e., the 2773 destination port number is not known. Any other value indicates 2774 the destination port number. 2776 o src port number: A value of 0 indicates a port wildcard, i.e., the 2777 source port number is not known. Any other value indicates the 2778 source port number. 2780 o data sender's IPv4 address: The source IP address of the data 2781 sender. This field MUST be set to zero if no IP address is 2782 provided, i.e., a complete wildcard is desired (see dest prefix 2783 field above). 2785 4.2.8. Trace Object 2787 The NATFW_TRACE object may contain zero or more identifiers of 2788 visited NATFW NSLP peers. However, it is only possible to store a 2789 single type of identifier, either IPv4 or IPv6 addresses. 2791 Type: NATFW_TRACE (IANA-TBD) 2793 Length: Variable 2795 0 1 2 3 2796 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 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | trace type | hop count | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 : IP address : 2801 : ... 2802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 Figure 31: Trace object 2805 The NATFW_TRACE object may contain zero or more identifiers. The 2806 type of identifier is given by the value of 'trace type' field. This 2807 memo is defining the values for the 'trace type' field: 0x01 for IPv4 2808 addresses and 0x02 for IPv6 addresses. Other trace types MUST 2809 generate an error RESPONSE of class 'Protocol error' (0x3) with 2810 response code 'Unknown object field value' (0x08). The 'hop count' 2811 field counts the total number of visited NATFW NSLP nodes that are 2812 willing to include their identifier in this object. Each such node 2813 appends its identifier at the end of the object. 2815 4.2.9. NI Credential Object 2817 This object is a container intended to carry credentials provided by 2818 the NI. 2820 Type: NATFW_CREDENTIAL (IANA-TBD) 2822 Length: Variable 2824 0 1 2 3 2825 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 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | credential type | credential length | 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 : credential data : 2830 : ... 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 Figure 32: Credential Object 2835 The field 'credential type' field contains one of these values: 2837 o 0x0002: Token 2839 Other trace types MUST generate an error RESPONSE of class 'Protocol 2840 error' (0x3) with response code 'Unknown object field value' (0x08). 2842 The field 'credential length' counts the total number of bytes of the 2843 included 'credential data'. Note that the total number of bytes 2844 contained in the NATFW_CREDENTIAL object may not end on a 32 bit word 2845 boundary. In this case a padding must be included at the end of the 2846 object right after the 'credential data' field. The padding must 2847 fill the NATFW_CREDENTIAL object to next 32 bit word boundary. 2849 4.2.10. ICMP Types Object 2851 The 'ICMP types' object contains additional information needed to 2852 configure a NAT of firewall with rules to control ICMP traffic. The 2853 object contains a number of values of the ICMP Type field for which a 2854 filter action should be set up: 2856 Type: NATFW_ICMP_TYPES (IANA-TBD) 2858 Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 2860 Where DIV is an integer division. 2862 0 1 2 3 2863 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 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 | Count | Type | Type | ........ | 2866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 | ................ | 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 | ........ | Type | (Padding) | 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2872 Figure 33: ICMP Types Object 2874 The fields MUST be interpreted according these rules: 2876 count: 8 bit integer specifying the number of 'Type' entries in 2877 the object. 2879 type: 8 bit field specifying an ICMP Type value to which this rule 2880 applies. 2882 padding: Sufficient 0 bits to pad out the last word so that the 2883 total size of object is an even multiple of words. Ignored on 2884 reception. 2886 4.3. Message Formats 2888 This section defines the content of each NATFW NSLP message type. 2889 The message types are defined in Section 4.1. First, the request 2890 messages are defined with their respective objects to be included in 2891 the message. Second, the response messages are defined with their 2892 respective objects to be included. 2894 Basically, each message is constructed of NSLP header and one or more 2895 NSLP objects. The order of objects is not defined, meaning that 2896 objects may occur in any sequence. Objects are marked either with 2897 mandatory [M] or optional [O]. Where [M] implies that this 2898 particular object MUST be included within the message and where [O] 2899 implies that this particular object is OPTIONAL within the message. 2900 Objects defined in this memo carry always the flag combination AB=00 2901 in the NSLP object header. An error RESPONSE message of class 2902 'Protocol error' (0x3) with response code 'Mandatory object missing' 2903 (0x02) MUST be generated if a mandatory declared object is missing. 2904 An error RESPONSE message of class 'Protocol error' (0x3) with 2905 response code 'Illegal object present' (0x05) MUST be generated if an 2906 object was present which must not be used in a message of this type. 2907 An error RESPONSE message of class 'Protocol error' (0x3) with 2908 response code 'Duplicate object present' (0x0A) MUST be generated if 2909 an object appears more than once in a message. 2911 Each section elaborates the required settings and parameters to be 2912 set by the NSLP for the NTLP, for instance, how the message routing 2913 information is set. 2915 4.3.1. CREATE 2917 The CREATE request message is used to create NSLP sessions and to 2918 create policy rules. Furthermore, CREATE messages are used to 2919 refresh sessions and to delete them. 2921 The CREATE request message carries these objects: 2923 o Lifetime object [M] 2925 o Extended flow information object [M] 2927 o Message sequence number object [M] 2929 o Credential object [O] 2931 o Nonce object [M] if P flag set to 1 in the NSLP header, otherwise 2932 [O] 2934 o ICMP Types Object [O] 2936 The message routing information in the NTLP MUST be set to DS as 2937 source address and DR as destination address. All other parameters 2938 MUST be set according the required policy rule. CREATE messages MUST 2939 be transported by using the path-coupled MRM with direction set to 2940 downstream. 2942 4.3.2. RESERVE-EXTERNAL-ADDRESS (REA) 2944 The RESERVE-EXTERNAL-ADDRESS (REA) request message is used to a) 2945 reserve an external IP address/port at NATs, b) to notify firewalls 2946 about NSIS capable DRs, or c) to block incoming data traffic at 2947 upstream firewalls. 2949 The REA request message carries these objects: 2951 o Lifetime object [M] 2953 o Message sequence number object [M] 2955 o Extended flow information object [M] 2957 o Credential object [O] 2959 o Data terminal information object [O] 2961 o Nonce object [M if P flag set to 1 in the NSLP header, otherwise 2962 [O] 2964 o ICMP Types Object [O] 2966 The selected message routing method of the REA request message 2967 depends on a number of considerations. Section 3.7.2 describes it 2968 exhaustively how to select the correct method. REA request messages 2969 can be transported via the path-coupled message routing method (PC- 2970 MRM) or via the loose-end message routing method (LE-MRM). In the 2971 case of PC-MRM, the source-address is set to DS' address and the 2972 destination address is set to DR's address, the direction is set to 2973 upstream. In the case of LE-MRM, the destination-address is set to 2974 DR's address or to the signaling destination address. The source- 2975 address is set to DS's address. 2977 4.3.3. RESPONSE 2979 RESPONSE messages are responses to CREATE and REA messages. 2981 The RESPONSE message for the class 'Success' (0x2) carries these 2982 objects: 2984 o Lifetime object [M] 2986 o Message sequence number object [M] 2988 o Information code object [M] 2990 o External address object [O] 2992 o Trace object [O] 2994 The RESPONSE message for other classes than 'Success' (0x2) carries 2995 these objects: 2997 o Message sequence number object [M] 2999 o Information code object [M] 3001 This message is routed upstream hop-by-hop, using existing NTLP 3002 messaging associations. 3004 4.3.4. NOTIFY 3006 The NOTIFY messages is used to report asynchronous events happening 3007 along the signaled path to other NATFW NSLP nodes. 3009 The NOTIFY message carries this object: 3011 o Information code object [M]. 3013 The NOTIFY message is forwarded upstream hop-by-hop using the 3014 existing upstream node messaging association entry within the node's 3015 Message Routing State table. 3017 4.3.5. TRACE 3019 The TRACE request message is used to trace the involved NATFW NSLP 3020 nodes along a signal session. 3022 The TRACE request message carries these objects: 3024 o Message sequence number object [M] 3026 o Trace object [M] 3028 TRACE request messages are sent path-coupled (PC-MRM). 3030 5. Security Considerations 3032 Security is of major concern particularly in case of firewall 3033 traversal. This section provides security considerations for the 3034 NAT/firewall traversal and is organized as follows. 3036 In Section 5.1 we describe the participating entities relate to each 3037 other from a security point of view. This subsection also motivates 3038 a particular authorization model. 3040 Security threats that focus on NSIS in general are described in [8] 3041 and they are applicable to this document as well. In Section 5.2 we 3042 extend this threat investigation by considering NATFW NSLP specific 3043 threats in more detail. Based on the investigated security threats 3044 we derive security requirements. 3046 Finally, we illustrate how the security requirements that were 3047 created based on the security threats can be fulfilled by specific 3048 security mechanisms. These aspects will be elaborated in 3049 Section 5.11. 3051 5.1. Authorization Framework 3053 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 3054 and is, as such, not a two-party protocol. Figure 1 and Figure 2 of 3055 [8] already depict the possible set of communication patterns. In 3056 this section we will re-evaluate these communication patters with 3057 respect to the NATFW NSLP protocol interaction. 3059 The security solutions for providing authorization have a direct 3060 impact on the treatment of different NSLPs. As it can be seen from 3061 the QoS NSLP [6] and the corresponding Diameter QoS work [24] 3062 accounting and charging seems to play an important role for QoS 3063 reservations, whereas monetary aspects might only indirectly effect 3064 authorization decisions for NAT and firewall signaling. Hence, there 3065 are differences in the semantic of authorization handling between QoS 3066 and NATFW signaling. A NATFW aware node will most likely want to 3067 authorize the entity (e.g., user or machine) requesting the 3068 establishment of pinholes or NAT bindings. The outcome of the 3069 authorization decision is either allowed or disallowed whereas a QoS 3070 authorization decision might indicate that a different set of QoS 3071 parameters is authorization (see [24] as an example). 3073 5.1.1. Peer-to-Peer Relationship 3075 Starting with the simplest scenario, it is assumed that neighboring 3076 nodes are able to authenticate each other and to establish keying 3077 material to protect the signaling message communication. An addition 3078 to authentication the nodes will have to authorize each other. We 3079 use the term 'Security Context' as a placeholder for referring to the 3080 entire security procedure, the necessary infrastructure that needs to 3081 be in place in order for this to work (e.g., key management) and the 3082 established security related state. The required long-term key 3083 (symmetric or asymmetric keys) used for authentication are either 3084 made available using an out-of-band mechanism between the two NSIS 3085 NATFW nodes or they are dynamically established using mechanisms not 3086 further specified in this document. Note that the deployment 3087 environment will most likely have an impact on the choice of 3088 credentials being used. The choice of these credentials used is also 3089 outside the scope of this document. 3091 +------------------------+ +-------------------------+ 3092 |Network A | | Network B| 3093 | +---------+ +---------+ | 3094 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3095 | | | box 1 | Security | box 2 | | | 3096 | | +---------+ Context +---------+ | | 3097 | | Security | | Security | | 3098 | | Context | | Context | | 3099 | | | | | | 3100 | +--+---+ | | +--+---+ | 3101 | | Host | | | | Host | | 3102 | | A | | | | B | | 3103 | +------+ | | +------+ | 3104 +------------------------+ +-------------------------+ 3106 Figure 34: Peer-to-Peer Relationship 3108 Figure 34 shows a possible relationship between participating NSIS 3109 aware nodes. Host A might be, for example, a host in an enterprise 3110 network that has keying material established (e.g., a shared secret) 3111 with the company's firewall (Middlebox 1). The network administrator 3112 of Network A (company network) has created access control lists for 3113 Host A (or whatever identifiers a particular company wants to use). 3114 Exactly the same procedure might also be used between Host B and 3115 Middlebox 2 in Network B. For the communication between Middlebox 1 3116 and Middlebox 2 a security context is also assumed in order to allow 3117 authentication, authorization and signaling message protection to be 3118 successful. 3120 5.1.2. Intra-Domain Relationship 3122 In larger corporations, for example, a middlebox is used to protect 3123 individual departments. In many cases, the entire enterprise is 3124 controlled by a single (or a small number of) security department, 3125 which gives instructions to the department administrators. In such a 3126 scenario, a the previously discussed peer-to-peer relationship might 3127 be prevalent. Sometimes it might be necessary to preserve 3128 authentication and authorization information within the network. As 3129 a possible solution, a centralized approach could be used, whereby an 3130 interaction between the individual middleboxes and a central entity 3131 (for example a policy decision point - PDP) takes place. As an 3132 alternative, individual middleboxes exchange the authorization 3133 decision with another middlebox within the same trust domain. 3134 Individual middleboxes within an administrative domain may exploit 3135 their relationship instead of requesting authentication and 3136 authorization of the signaling initiator again and again. Figure 35 3137 illustrates a network structure which uses a centralized entity. 3139 +-----------------------------------------------------------+ 3140 | Network A | 3141 | +---------+ +---------+ 3142 | +----///--------+ Middle- +------///------++ Middle- +--- 3143 | | Security | box 2 | Security | box 2 | 3144 | | Context +----+----+ Context +----+----+ 3145 | +----+----+ | | | 3146 | | Middle- +--------+ +---------+ | | 3147 | | box 1 | | | | | 3148 | +----+----+ | | | | 3149 | | Security | +----+-----+ | | 3150 | | Context | | Policy | | | 3151 | +--+---+ +-----------+ Decision +----------+ | 3152 | | Host | | Point | | 3153 | | A | +----------+ | 3154 | +------+ | 3155 +-----------------------------------------------------------+ 3157 Figure 35: Intra-domain Relationship 3159 The interaction between individual middleboxes and a policy decision 3160 point (or AAA server) is outside the scope of this document. 3162 5.1.3. End-to-Middle Relationship 3164 The peer-to-peer relationship between neighboring NSIS NATFW NSLP 3165 nodes might not always be sufficient. Network B might require 3166 additional authorization of the signaling message initiator (in 3167 addition to the authorization of the neighboring node). If 3168 authentication and authorization information is not attached to the 3169 initial signaling message then the signaling message arriving at 3170 Middlebox 2 would result in an error message being created, which 3171 indicates the additional authorization requirement. In many cases 3172 the signaling message initiator might already aware of the 3173 additionally required authorization before the signaling message 3174 exchange is executed. 3176 Figure 36 shows this scenario. 3178 +--------------------+ +---------------------+ 3179 | Network A | |Network B | 3180 | | Security | | 3181 | +---------+ Context +---------+ | 3182 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3183 | | | box 1 | +-------+ box 2 | | | 3184 | | +---------+ | +---------+ | | 3185 | |Security | | | Security | | 3186 | |Context | | | Context | 3187 | | | | | | | 3188 | +--+---+ | | | +--+---+ | 3189 | | Host +----///----+------+ | | Host | | 3190 | | A | | Security | | B | | 3191 | +------+ | Context | +------+ | 3192 +--------------------+ +---------------------+ 3194 Figure 36: End-to-Middle Relationship 3196 5.2. Security Threats and Requirements 3198 This section describes NATFW specific security threats and 3199 requirements. 3201 5.2.1. Data Sender (DS) behind a firewall 3203 +------------------------------+ 3204 | | 3205 | +-----+ create +-----+ 3206 | | DS | --------------> | FW | 3207 | +-----+ +-----+ 3208 | | 3209 +------------------------------+ 3211 DS sends a CREATE message to request the traversal of a data flow. 3213 The following attacks are possible: 3215 o DS could open a firewall pinhole with a source address different 3216 from its own host. 3218 o DS could open firewall pinholes for incoming data flows that are 3219 not supposed to enter the network. 3221 o DS could request installation of any policy rules and allow all 3222 traffic go through. 3224 SECURITY REQUIREMENT: The middlebox MUST authenticate and authorize 3225 the neighboring NAT/FW NSLP node requesting an action. 3226 Authentication and authorization of the initiator SHOULD be 3227 provided to NATs and firewalls along the path. 3229 5.2.2. Data Sender (DS) behind a NAT 3231 The case 'DS behind a NAT' is analogous to the case 'DS behind a 3232 firewall'. 3234 Figure 38 illustrates such a scenario: 3236 +------------------------------+ 3237 | | 3238 | +------+ CREATE | 3239 | | NI_1 | ------\ +-----+ CREATE +-----+ 3240 | +------+ \------> | NAT |-------->| MB | 3241 | +-----+ +-----+ 3242 | +------+ | 3243 | | NI_2 | | 3244 | +------+ | 3245 +------------------------------+ 3247 Figure 38: Several NIs behind a NAT 3249 In this case the middlebox MB does not know who is the NSIS Initiator 3250 since both NI_1 and NI_2 are behind a NAT (which is also NSIS aware). 3251 Authentication needs to be provided by other means such as the NSLP 3252 or the application layer. 3254 SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that 3255 the neighboring NAT/FW NSLP node is authorized to request an 3256 action. Authentication and authorization of the initiator (which 3257 is the DR in this scenario) to the non-neighboring middleboxes 3258 SHOULD be provided. 3260 5.2.3. Data Receiver (DR) behind a firewall 3262 In this case a CREATE message comes from an entity DS outside the 3263 network towards the DR inside the network. 3265 +------------------------------+ 3266 | | 3267 +-----+ CREATE +-----+ CREATE +-----+ | 3268 | DS | -------------> | FW | -------------> | DR | | 3269 +-----+ <------------- +-----+ <------------- +-----+ | 3270 successful RESPONSE | successful RESPONSE | 3271 | | 3272 +------------------------------+ 3274 Since policy rules at middleboxes must only be installed after 3275 receiving a successful response it is necessary that the middlebox 3276 waits until the Data Receiver DR confirms the request of the Data 3277 Sender DS with a successful RESPONSE message. 3279 This confirmation implies that the data receiver is expecting the 3280 data flow. 3282 At this point we differentiate two cases: 3284 1. DR knows the (publicly reachable) IP address and port number of 3285 the DS (for instance because of some previous application layer 3286 signaling) and is expecting the data flow. 3288 2. DR might be expecting the data flow (for instance because of some 3289 previous application layer signaling) but does not know the 3290 (publicly reachable) IP address of the Data Sender DS. 3292 For the second case, Figure 40 illustrates a possible attack: an 3293 adversary Mallory M could be sniffing the application layer signaling 3294 and thus knows the address and port number where DR is expecting the 3295 data flow. Thus it could pretend to be DS and send a CREATE message 3296 towards DR with the data flow description (M -> DR). Since DR does 3297 not know the IP address of DS, it is not able to recognize that the 3298 request is coming from the "wrong guy". It will send a success 3299 RESPONSE message back and the middlebox will install policy rules 3300 that will allow Mallory M to inject its data into the network. 3302 Application Layer signaling 3303 <------------------------------------> 3304 / \ 3305 / +-----------------\------------+ 3306 / | \ | 3307 +-----+ +-----+ +-----+ | 3308 | DS | -> | FW | | DR | | 3309 +-----+ / +-----+ +-----+ | 3310 CREATE / | | 3311 +-----+ / +-------------------------------+ 3312 | M |---------- 3313 +-----+ 3315 Figure 40: DR behind a firewall with an adversary 3317 Network administrators will probably not rely on a DR to check the IP 3318 address of the DS. Thus we have to assume the worst case with an 3319 attack such as in Figure 40. Many operators might not allow NSIS 3320 signaling message to traverse the firewall in Figure 40 without 3321 having the DR to interact with the FW first. 3323 SECURITY REQUIREMENT: No requirements are created by this scenario. 3325 5.2.4. Data Receiver (DR) behind a NAT 3327 When a data receiver DR behind a NAT sends a RESERVE-EXTERNAL-ADDRESS 3328 (REA) message to get a public reachable address that can be used as a 3329 contact address by an arbitrary data sender if the DR was unable to 3330 restrict the future data sender. The NAT reserves an external 3331 address and port number and sends them back to DR. The NAT adds an 3332 address mapping entry in its reservation list which links the public 3333 and private addresses as follows: 3335 (DR_ext <=> DR_int) (*). 3337 The NAT sends a RESPONSE message with the external address' object 3338 back to the DR with the address DR_ext. DR informs DS about the 3339 public address that it has recently received, for instance, by means 3340 of application layer signaling. 3342 When a data sender sends a CREATE message towards DR_ext then the 3343 message will be forwarded to the DR. The data sender might want to 3344 update the NAT binding stored at the edge-NAT to make it more 3345 restrictive. 3347 We assume that the adversary Mallory M obtains the contact address 3348 (i.e., external address and port) allocated at the NAT possibly by 3349 eavesdropping on the application layer signaling and sends a CREATE 3350 message. As a consequence Mallory would be able to communicate with 3351 DR (if M is authorized by the edge-NAT and if the DR accepts CREATE 3352 and returns a RESPONSE. 3354 Application Layer signaling 3355 <------------------------------------------> 3356 / \ 3357 / +----------------------\-------+ 3358 v | REA v | 3359 +-----+ +-----+ <----------- +-----+ | 3360 | DS | -> | NAT | -----------> | DR | | 3361 +-----+ / +-----+ DR_external +-----+ | 3362 CREATE / | | 3363 +-----+ / +-------------------------------+ 3364 | M |---------- 3365 +-----+ 3367 SECURITY REQUIREMENT: The DR MUST be able to specify which data 3368 sender are allowed to traverse the NAT in order to be forwarded to 3369 DRs address. 3371 5.2.5. NSLP Message Injection 3373 Malicious hosts, located either off-path or on-path, could inject 3374 arbitrary NATFW NSLP messages into the signaling path. These 3375 problems apply when no proper authorization and authentication scheme 3376 is available. 3378 By injecting a bogus CREATE message with lifetime set to zero, a 3379 malicious host could try to teardown NATFW NSLP session state 3380 partially or completely on a data path, causing a service 3381 interruption. 3383 By injecting a bogus responses or NOTIFY message, for instance, 3384 timeout, a malicious host could try to teardown NATFW NSLP session 3385 state as well. This could affect the data path partially or totally, 3386 causing a service interruption. 3388 SECURITY REQUIREMENT: Messages, such as NOTIFY, can be misused by 3389 malicious hosts, and therefore MUST be authorized by the 3390 respective NATFW NLSP entities. 3392 5.3. Denial-of-Service Attacks 3394 In this section we describe several ways how an adversary could 3395 launch a Denial of service (DoS) attack on networks running NSIS for 3396 middlebox configuration to exhaust their resources. 3398 5.3.1. Flooding with CREATE messages from outside 3400 5.3.1.1. Attacks due to NSLP state 3402 A CREATE message requests the NSLP to store state information such as 3403 a NAT binding or a policy rule. 3405 The policy rules requested in the CREATE message will be installed at 3406 the arrival of a confirmation from the Data Receiver with a success 3407 RESPONSE message. A successful RESPONSE message includes the session 3408 ID. So the NSLP looks up the NSIS session and installs the requested 3409 policy rules. 3411 An adversary could launch a DoS attack with an arbitrary number of 3412 CREATE messages. For each of these messages the middlebox needs to 3413 store state information such as the policy rules to be loaded, i.e., 3414 the middlebox could run out of memory. This kind of attack is also 3415 mentioned in [8] Section 4.8. 3417 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 3418 establishment of state information. 3420 5.3.1.2. Attacks due to authentication complexity 3422 This kind of attack is possible if authentication is based on 3423 mechanisms that require computing power, for example, digital 3424 signatures. 3426 For a more detailed treatment of this kind of attack, the reader is 3427 encouraged to see [8]. 3429 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 3430 denial of service attacks based on authentication or key exchange 3431 mechanisms. 3433 5.3.1.3. Attacking Endpoints 3435 The NATFW NSLP requires firewalls to forward NSLP messages, a 3436 malicious node may keep sending NSLP messages to a target. This may 3437 consume the access network resources of the victim, drain the battery 3438 of the victim's terminal and may force the victim to pay for the 3439 received although undesired data. 3441 This threat may be more particularly be relevant in networks where 3442 access link is a limited resource, for instance in cellular networks, 3443 and where the terminal capacities are limited. 3445 SECURITY REQUIREMENT: A NATFW NSLP node MUST be configurable to block 3446 unauthorized signaling message. 3448 5.3.2. Flooding with REA messages from inside 3450 Although we are more concerned with possible attacks from outside the 3451 network, we need also to consider possible attacks from inside the 3452 network. 3454 An adversary inside the network could send arbitrary RESERVE- 3455 EXTERNAL-ADDRESS messages. At a certain point the NAT will run out 3456 of port numbers and the access for other users to the outside will be 3457 disabled. 3459 SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state 3460 creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, 3461 the NAT/FW NSLP implementation MUST prevent denial of service 3462 attacks involving the allocation of an arbitrary number of NAT 3463 bindings or the installation of a large number of packet filters. 3465 5.4. Man-in-the-Middle Attacks 3467 Figure 42 illustrates a possible man-in-the-middle attack using the 3468 RESERVE-EXTERNAL-ADDRESS (REA) message. This message travels from DR 3469 towards the public Internet. The message might not be intercepted 3470 because there are no NSIS aware middleboxes. 3472 Imagine such an NSIS signaling message is then intercepted by an 3473 adversary Mallory (M). M returns a faked RESPONSE message whereby 3474 the adversary pretends that a NAT binding was created. This NAT 3475 binding is returned with the RESPONSE message. Mallory might insert 3476 it own IP address in the response, the IP address of a third party or 3477 the address of a black hole. In the first case, the DR thinks that 3478 the address of Mallory M is its public address and will inform the DS 3479 about it. As a consequence, the DS will send the data traffic to 3480 Mallory M. 3482 The data traffic from the DS to the DR will re-directed to Mallory M. 3483 M will be able to read, modify or block the data traffic (if the end- 3484 to-end communication itself does not experience protection). 3485 Eavesdropping and modification is only possible if the data traffic 3486 is itself unprotected. 3488 +-----+ +-----+ +-----+ 3489 | DS | | M | | DR | 3490 +-----+ +-----+ +-----+ 3491 | | | 3492 | | REA | 3493 | | <------------------ | 3494 | | | 3495 | | RESPONSE | 3496 | | ------------------> | 3497 | | | 3498 | data traffic | | 3499 |===============>| data traffic | 3500 | |====================>| 3502 Figure 42: MITM attack using the RESERVE-EXTERNAL-ADDRESS message 3504 SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW 3505 NSLP MUST be provided. To ensure that only legitimate nodes along 3506 the path act as NSIS entities the initiator MUST authorize the 3507 responder. In the example in Figure 42 the firewall FW must 3508 perform an authorization with the neighboring entities. 3510 5.5. Message Modification by non-NSIS on-path node 3512 An unauthorized on-path node along the path towards the destination 3513 could easily modify, inject or just drop an NSIS message. It could 3514 also hijack or disrupt the communication. 3516 SECURITY REQUIREMENT: Message integrity, replay protection and data 3517 origin authentication between neighboring NAT/FW NSLPs MUST be 3518 provided. 3520 5.6. Message Modification by malicious NSIS node 3522 Message modification by an NSIS node that became malicious is more 3523 serious. An adversary could easily create arbitrary pinholes or NAT 3524 bindings. For example: 3526 o NATs need to modify the source/destination of the data flow in the 3527 'create session' message. 3529 o Each middlebox along the path may change the requested lifetime in 3530 the CREATE message to fit their needs and/or local policy. 3532 SECURITY REQUIREMENT: Malicious NSIS NATs and firewalls will not be 3533 addressed by this specification. 3535 5.7. Session Ownership 3537 Section 4.10 in [8] describes a threat where an adversary is able to 3538 modify or delete previously installed state information at NATFW NSLP 3539 nodes along the path. An adversary therefore needs to know session 3540 specific information, such as the session identifier and MRI 3541 information. 3543 SECURITY REQUIREMENT: Off-path adversaries MUST NOT be able to modify 3544 or delete sessions without proper authorization. 3546 5.7.1. Misuse of Mobility in a NAT Handling Scenario 3548 Another kind of session modification is related to mobility 3549 scenarios. The NSIS protocol suite offers interworking with mobility 3550 protocol and a mobile node might need to update state along NATFW 3551 NSLP nodes. 3553 Whenever a host behind a NAT initiates a data transfer, it is 3554 assigned an external IP and port number. In typical mobility 3555 scenarios, the DR might also obtain a new address according to the 3556 topology and it should convey its new IP address to the NAT. The NAT 3557 is assumed to modify these NAT bindings based on the new IP address 3558 conveyed by the end host. 3560 Public Private Address 3561 Internet space 3563 +----------+ +----------+ 3564 +----------| NAT |------------------|End host | 3565 | | | | 3566 +----------+ +----------+ 3567 | 3568 | +----------+ 3569 \--------------------|Malicious | 3570 |End host | 3571 +----------+ 3572 data traffic 3573 <======================== 3575 Figure 43: Misuse of mobility in NAT binding 3577 A NAT binding can be changed with the help of NSIS signaling. When a 3578 DR moves to a new location and obtains a new IP address, it sends an 3579 NSIS signaling message to modify the NAT binding. It would use the 3580 Session-ID and the new flow-id to update the state. The NAT updates 3581 the binding and the DR continues to receive the data traffic. 3582 Consider the scenario in Figure 43 where an the end host(DR) and the 3583 adversary are behind a NAT. The adversary pretending that it is the 3584 end host could generate a spurious signaling message to update the 3585 state at the NAT. This could be done for these purposes: 3587 o Redirecting packets to the attacker as in Figure 44. 3589 o Third party flooding by redirecting packets to arbitrary hosts 3591 o Service disruption by redirecting to non-existing hosts 3593 +----------+ +----------+ +----------+ 3594 | NAT | |End host | |Malicious | 3595 | | | | |End host | 3596 +----------+ +----------+ +----------+ 3597 | | | 3598 | Data Traffic | | 3599 |--------->----------| | 3600 | | Spurious | 3601 | | NAT binding update | 3602 |---------<----------+--------<------------| 3603 | | | 3604 | Data Traffic | | 3605 |--------->----------+-------->------------| 3606 | | | 3608 Figure 44: Connection Hijacking 3610 SECURITY REQUIREMENT: A NAT/FW signaling message MUST be 3611 authenticated, integrity and replay protected between neighboring 3612 NAT/FW NSLP nodes. The NSIS NATFW NSLP aware NAT MUST authorize 3613 the end host to insure that the messages are indeed belonging to 3614 the previously established session. 3616 5.8. Misuse of unreleased sessions 3618 Assume that DS (N1) initiates NSIS session with DR (N2) through a 3619 series of middleboxes as in Figure 45. When the DS is sending data 3620 to DR, it might happen that the DR disconnects from the network 3621 (crashes or moves out of the network in mobility scenarios). In such 3622 cases, it is possible that another node N3 (which recently entered 3623 the network protected by the same firewall) is assigned the same IP 3624 address that was previously allocated to N2. The DS could take 3625 advantage of the firewall policies installed already, if the refresh 3626 interval time is very high. The DS can flood the node (N3), which 3627 will consume the access network resources of the victim forcing it to 3628 pay for unwanted traffic as shown in Figure 46. Note that here we 3629 make the assumption that the data receiver has to pay for receiving 3630 data packets. 3632 Public Internet 3633 +--------------------------+ 3634 | | 3635 +-------+ CREATE +---+-----+ +-------+ | 3636 | |-------------->------| |---->---| | | 3637 | N1 |--------------<------| FW |----<---| N2 | | 3638 | | successful RESPONSE | | | | | 3639 | |==============>======| |====>===| | | 3640 +-------+ Data Traffic +---+-----+ +-------+ | 3641 | | 3642 +--------------------------+ 3644 Figure 45: Before mobility 3646 Public Internet 3647 +--------------------------+ 3648 | | 3649 +-------+ +---+-----+ +-------+ | 3650 | | | | | | | 3651 | N1 |==============>======| FW |====>===| N3 | | 3652 | | Data Traffic | | | | | 3653 +-------+ +---+-----+ +-------+ | 3654 | | 3655 +--------------------------+ 3657 Figure 46: After mobility 3659 Also, this threat is valid for the other direction as well. The DS 3660 which is communicating with the DR may disconnect from the network 3661 and this IP address may be assigned to a new node that had recently 3662 entered the network. This new node could pretend to be the DS and 3663 send data traffic to the DR in conformance with the firewall policies 3664 and cause service disruption. 3666 SECURITY REQUIREMENT: In order to allow firewalls to verify that a 3667 legitimate end host indeed transmitted data traffic it is 3668 necessary to provide data origin authentication. This is, 3669 however, outside the scope of this document. Hence, there are no 3670 security requirements imposed by this threat, which will be 3671 addressed by the NATFW NSLP. 3673 5.9. Data Traffic Injection 3675 In some environments, such as enterprise networks, it is still common 3676 to perform authorization for access to a service based on the source 3677 IP address of the service requester. There is no doubt that this 3678 practice by itself represents a security weakness. Using IP spoofing 3679 an adversary is able to reach the target machines if they match, 3680 using the existing firewall rules. 3682 The adversary is able to inject its own data traffic in conformance 3683 with the firewall policies simultaneously along with the genuine DS. 3685 SECURITY REQUIREMENT: Since IP spoofing is a general limitation of 3686 non-cryptographic packet filters no countermeasures need to be 3687 taken by the NAT/FW NSLP. Techniques such as ingress filtering 3688 (see [23]) and, if necessary, data origin authentication (such as 3689 provided with IPsec based VPNs) can help mitigate this threat. 3690 This aspect is, however, outside the scope of this document. 3692 5.10. Eavesdropping and Traffic Analysis 3694 By collecting NSLP messages, an adversary is able to learn policy 3695 rules for packet filters and knows which ports are open. It can use 3696 this information to inject its own data traffic due to the IP 3697 spoofing capability already mentioned in Section 5.9. An on-path 3698 adversary could also observe the data traffic and he could conclude 3699 that it is possible to traverse a firewall. 3701 An adversary could learn authorization tokens included in CREATE 3702 messages and use them to launch replay-attacks or to create a session 3703 with its own address as source address. This threat is discussed in 3704 the respective document suggesting the usage of authorization token 3705 in the NSIS protocol suite. 3707 SECURITY REQUIREMENT: The threat of eavesdropping itself does not 3708 mandate the usage of confidentiality protection since an adversary 3709 can also eavesdrop on data traffic. In the context of a 3710 particular security solutions (e.g., authorization tokens) it MAY 3711 be necessary to offer confidentiality protection. The latter 3712 aspect is outside the scope of this document. 3714 5.11. Security Framework for the NAT/Firewall NSLP 3716 Based on the identified threats a list of security requirements has 3717 been created. 3719 5.11.1. Security Protection between neighboring NATFW NSLP Nodes 3721 Based on the analyzed threats it is necessary to provide, between 3722 neighboring NATFW NSLP nodes, the following mechanism: provide 3724 o data origin authentication 3726 o replay protection 3728 o integrity protection and 3730 o optionally confidentiality protection 3732 To consider the aspect of authentication and key exchange the 3733 security mechanisms provided in [2] between neighboring nodes MUST be 3734 enabled when sending NATFW signaling messages. The proposed security 3735 mechanisms at GIST provide support for authentication and key 3736 exchange in addition to denial of service protection. Depending on 3737 the chosen security protocol, support for multiple authentication 3738 protocols might be provided. If security between neighboring nodes 3739 is desired then the usage of C-MODE for the delivery of data packets 3740 and the usage of D-MODE only to discover the next NATFW NSLP aware 3741 node along the path is demanded. Almost all security threats at the 3742 NATFW NSLP layer can be prevented by using a mutually authenticated 3743 Transport Layer secured connection and by relying on authorization by 3744 the neighboring NATFW NSLP entities. 3746 The NATFW NSLP relies an established security association between 3747 neighboring peers to prevent unauthorized nodes to modify or delete 3748 installed state. Between non-neighboring nodes the session ID (SID) 3749 carried in the NTLP is used to show ownership of a session. The 3750 session ID MUST be generated in a random way and thereby prevent an 3751 off-path adversary to mount targeted attacks. Hencem, an adversary 3752 would have to learn the randomly generated Session ID to perform an 3753 attack. In a mobility environment a former on-path node that is now 3754 off-path can perform an attack. The cost-benefit tradeoff to counter 3755 this attack does not seem to be high enough to provide a solution. 3756 Messages for a particular session are handled by the NTLP to the 3757 NATFW NSLP for further processing. Messages carrying a different 3758 session ID not associated with any NATFW NSLP are subject to the 3759 regular processing for new NATFW NSLP sessions. 3761 5.11.2. Security Protection between non-neighboring NATFW NSLP Nodes 3763 Based on the security threats and the listed requirements it was 3764 noted that some threats also demand authentication and authorization 3765 of a NATFW signaling entity (including the initiator) towards a non- 3766 neighboring node. This mechanism mainly demands entity 3767 authentication. Additionally, security protection of certain 3768 payloads may be required between non-neighboring signaling entities 3769 and the Cryptographic Message Syntax (CMS) [17] migh be a potential 3770 solution. Payload protection using CMS is not described in this 3771 document. The most important information exchanged at the NATFW NSLP 3772 is information related to the establishment for firewall pinholes and 3773 NAT bindings. This information can, however, not be protected over 3774 multiple NSIS NATFW NSLP hops since this information might change 3775 depending on the capability of each individual NATFW NSLP node. 3777 Some scenarios might also benefit from the usage of authorization 3778 tokens. Their purpose is to associate two different signaling 3779 protocols (e.g., SIP and NSIS) and their authorization decision. 3780 These tokens are obtained by non-NSIS protocols, such as SIP or as 3781 part of network access authentication. When a NAT or firewall along 3782 the path receives the token it might be verified locally or passed to 3783 the AAA infrastructure. Examples of authorization tokens can be 3784 found in RFC 3520 [21] and RFC 3521 [22]. Figure 47 shows an example 3785 of this protocol interaction. 3787 An authorization token is provided by the SIP proxy, which acts as 3788 the assertion generating entity and gets delivered to the end host 3789 with proper authentication and authorization. When the NATFW 3790 signaling message is transmitted towards the network, the 3791 authorization token is attached to the signaling messages to refer to 3792 the previous authorization decision. The assertion verifying entity 3793 needs to process the token or it might be necessary to interact with 3794 the assertion granting entity using HTTP (or other protocols). As a 3795 result of a successfully authorization by a NATFW NSLP node, the 3796 requested action is executed and later a RESPONSE message is 3797 generated. 3799 +----------------+ Trust Relationship +----------------+ 3800 | +------------+ |<.......................>| +------------+ | 3801 | | Protocol | | | | Assertion | | 3802 | | requesting | | HTTP, SIP Request | | Granting | | 3803 | | authz | |------------------------>| | Entity | | 3804 | | assertions | |<------------------------| +------------+ | 3805 | +------------+ | Artifact/Assertion | Entity Cecil | 3806 | ^ | +----------------+ 3807 | | | ^ ^| 3808 | | | . || HTTP, 3809 | | | Trust . || other 3810 | API Access | Relationship. || protocols 3811 | | | . || 3812 | | | . || 3813 | | | v |v 3814 | v | +----------------+ 3815 | +------------+ | | +------------+ | 3816 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3817 | | using authz| | Assertion/Artifact | | Verifying | | 3818 | | assertion | | ----------------------- | | Entity | | 3819 | +------------+ | | +------------+ | 3820 | Entity Alice | <---------------------- | Entity Bob | 3821 +----------------+ RESPONSE +----------------+ 3823 Figure 47: Authorization Token Usage 3825 Threats against the usage of authorization tokens have been mentioned 3826 in [8] and also in Section 5.2. Hence, it is required to provide 3827 confidentiality protection to avoid allowing an eavesdropper to learn 3828 the token and to use it in another session (replay attack). The 3829 token itself also needs to be protected against tempering. 3831 To harmonize the usage of authorization tokens in NSLPs a separate 3832 document is available, see [25]. 3834 6. IAB Considerations on UNSAF 3836 UNilateral Self-Address Fixing (UNSAF) is described in [15] as a 3837 process at originating endpoints that attempt to determine or fix the 3838 address (and port) by which they are known to another endpoint. 3839 UNSAF proposals, such as STUN [RFC3489] are considered as a general 3840 class of workarounds for NAT traversal and as solutions for scenarios 3841 with no middlebox communication. 3843 This memo specifies a path-coupled middlebox communication protocol, 3844 i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are 3845 not intended as a short-term workaround, but more as a long-term 3846 solution for middlebox communication. In NSIS, endpoints are 3847 involved in allocating, maintaining, and deleting addresses and ports 3848 at the middlebox. However, the full control of addresses and ports 3849 at the middlebox is at the NATFW NSLP daemon located to the 3850 respective NAT. 3852 Therefore, this document addresses the UNSAF considerations in 3853 [RFC3424] by proposing a long-term alternative solution. 3855 7. IANA Considerations 3857 This section provides guidance to the Internet Assigned Numbers 3858 Authority (IANA) regarding registration of values related to the 3859 NATFW NSLP, in accordance with BCP 26 RFC 2434 [16]. 3861 The NATFW NSLP requires IANA to create a number of new registries. 3862 These registries may require further coordination with the registries 3863 of the NTLP [2] and the QoS NSLP [6]. 3865 NATFW NSLP Message Type Registry 3866 The NATFW NSLP Message Type is a 8 bit value. The allocation of 3867 values for new message types requires standards action. Updates and 3868 deletion of values from the registry is not possible. This 3869 specification defines five NATFW NSLP message types, which form the 3870 initial contents of this registry. IANA is requested to add these 3871 five NATFW NSLP Message Types: CREATE, REA, TRACE, RESPONSE, and 3872 NOTIFY. 3874 NATFW NSLP Header Flag Registry 3875 NATFW NSLP messages have a messages-specific 8 bit flags/reserved 3876 field in their header. The registration of flags is subject to IANA 3877 registration. The allocation of values for flag types requires 3878 standards action. Updates and deletion of values from the registry 3879 is not possible. This specification defines only one flag, the P 3880 flag in Figure 22. 3882 NSLP Object Type Registry 3883 This document defines 10 objects for the NATFW NSLP: NATFW_LT, 3884 NATFW_EXT_IP, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, 3885 NATFW_DTINFO_IPv4, NATFW_TRACE, NATFW_CREDENTIAL, NATFW_ICMP_TYPES. 3886 The allocation of values for new message types requires standards 3887 action. IANA is request to assigned values for them from NSLP Object 3888 Type registry and to replace the corresponding IANA-TBD tags with the 3889 numeric values. 3891 NSLP Response Code Registry 3892 In addition it defines a number of Response Codes for the NATFW NSLP. 3893 These can be found in Section 4.2.4 and are to be assigned values 3894 from NSLP Response Code registry. The allocation of values for 3895 Response Codes Codes requires standards action. IANA is request to 3896 assigned values for them from NSLP Response Code registry. 3898 Furthermore, IANA is requested to add a new value to the NSLP 3899 Identifiers (NSLPID) registry defined in [2] for the the NATFW NSLP. 3901 8. Open Issues 3903 A more detailed list of open issue can be found at: 3904 https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/index 3906 9. Acknowledgments 3908 We would like to thank the following individuals for their 3909 contributions to this document at different stages: 3911 o Marcus Brunner and Henning Schulzrinne for work on work on IETF 3912 drafts which lead us to start with this document, 3914 o Miquel Martin for his help on the initial version of this 3915 document, 3917 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3918 NAT/firewall threats draft, 3920 o Henning Peters for his comments and suggestions, 3922 o and the NSIS working group. 3924 10. References 3926 10.1. Normative References 3928 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3929 Levels", BCP 14, RFC 2119, March 1997. 3931 [2] Schulzrinne, H. and R. Hancock, "GIST: General Internet 3932 Signaling Transport", draft-ietf-nsis-ntlp-09 (work in 3933 progress), February 2006. 3935 [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 3936 August 1996. 3938 10.2. Informative References 3940 [4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3941 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 3942 June 2005. 3944 [5] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 3945 April 2004. 3947 [6] Manner, J., "NSLP for Quality-of-Service Signaling", 3948 draft-ietf-nsis-qos-nslp-10 (work in progress), March 2006. 3950 [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 3951 Rayhan, "Middlebox communication architecture and framework", 3952 RFC 3303, August 2002. 3954 [8] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 3955 Steps in Signaling (NSIS)", RFC 4081, June 2005. 3957 [9] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 3958 (NAT) Terminology and Considerations", RFC 2663, August 1999. 3960 [10] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 3961 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 3963 [11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 3964 RFC 3234, February 2002. 3966 [12] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, 3967 "DNS extensions to Network Address Translators (DNS_ALG)", 3968 RFC 2694, September 1999. 3970 [13] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 3971 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3972 Specification", RFC 2205, September 1997. 3974 [14] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 3975 Herzog, S., and R. Hess, "Identity Representation for RSVP", 3976 RFC 3182, October 2001. 3978 [15] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 3979 Address Fixing (UNSAF) Across Network Address Translation", 3980 RFC 3424, November 2002. 3982 [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3983 Considerations Section in RFCs", BCP 26, RFC 2434, 3984 October 1998. 3986 [17] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 3987 August 2002. 3989 [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3990 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3991 Session Initiation Protocol", RFC 3261, June 2002. 3993 [19] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 3994 - Simple Traversal of User Datagram Protocol (UDP) Through 3995 Network Address Translators (NATs)", RFC 3489, March 2003. 3997 [20] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 3998 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and 3999 S. Waldbusser, "Terminology for Policy-Based Management", 4000 RFC 3198, November 2001. 4002 [21] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 4003 Authorization Policy Element", RFC 3520, April 2003. 4005 [22] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session 4006 Set-up with Media Authorization", RFC 3521, April 2003. 4008 [23] Ferguson, P. and D. Senie, "Network Ingress Filtering: 4009 Defeating Denial of Service Attacks which employ IP Source 4010 Address Spoofing", BCP 38, RFC 2827, May 2000. 4012 [24] Alfano, F., "Diameter Quality of Service Application", 4013 draft-alfano-aaa-qosprot-05 (work in progress), October 2005. 4015 [25] Manner, J., "Authorization for NSIS Signaling Layer Protocols", 4016 draft-manner-nsis-nslp-auth-01 (work in progress), June 2006. 4018 [26] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as 4019 firewall Signalling Protocol", Proceedings of the 6th IEEE 4020 Symposium on Computers and Communications, Hammamet, 4021 Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001. 4023 Appendix A. Selecting Signaling Destination Addresses for REA 4025 As with all other message types, REA messages need a reachable final 4026 destination IP address. But as many applications do not provide a 4027 destination IP address in the first place, there is a need to choose 4028 a destination address for REA messages. This destination address can 4029 be the final target, but for applications which do not provide an 4030 upfront address, the destination address has to be chosen 4031 independently. Choosing the 'correct' destination IP address may be 4032 difficult and it is possible there is no 'right answer'. 4034 1. Public IP address of the data sender: 4036 * Assumption: 4038 + The data receiver already learned the IP address of the 4039 data sender (e.g., via a third party). 4041 * Problems: 4043 + The data sender might also be behind a NAT. In this case 4044 the public IP address of the data receiver is the IP 4045 address allocated at this NAT. 4047 + Due to routing asymmetry it might be possible that the 4048 routes taken by a) the data sender and the application 4049 server b) the data sender and NAT B might be different. As 4050 a consequence it might be necessary to advertise a new (and 4051 different) external IP address within the application 4052 (which may or may not allow that) after using NSIS to 4053 establish a NAT binding. 4055 2. Public IP address of the data receiver: 4057 * Assumption: 4059 + The data receiver already learned his externally visible IP 4060 address (e.g., based on the third party communication). 4062 * Problems: 4064 + Communication with a third party is required. 4066 3. IP address of the Application Server: 4068 * Assumption: 4070 + An application server (or a different third party) is 4071 available. 4073 * Problems: 4075 + If the NSIS signaling message is not terminated at the NAT 4076 of the local network then an NSIS unaware application 4077 server might discard the message. 4079 + Routing might not be optimal since the route between a) the 4080 data receiver and the application server b) the data 4081 receiver and the data sender might be different. 4083 Appendix B. Applicability Statement on Data Receivers behind Firewalls 4085 Section 3.7.2 describes how data receivers behind middleboxes can 4086 instruct upstream firewalls/NATs to forward NATFW NSLP signaling 4087 towards them. Finding an upstream edge-NAT in address environment 4088 with NAT'ed addresses is quite easy. It is only required to find 4089 some edge-NAT, as the data traffic will be route-pinned to the NAT, 4090 which is done with the LE-MRM. Locating the appropriate edge- 4091 firewall with the PC-MRM, sent upstream is difficult. For cases with 4092 a single, symmetric route from the Internet to the data receiver, it 4093 is quite easy; simply follow the default route in the upstream 4094 direction. 4096 +------+ Data Flow 4097 +-------| EFW1 +----------+ <=========== 4098 | +------+ ,--+--. 4099 +--+--+ / \ 4100 NI+-----| FW1 | (Internet )----NR+/NI/DS 4101 NR +--+--+ \ / 4102 | +------+ `--+--' 4103 +-------| EFW2 +----------+ 4104 +------+ 4106 ~~~~~~~~~~~~~~~~~~~~~> 4107 Signaling Flow 4109 Figure 48: Data receiver behind multiple, parallel located firewalls 4111 When a data receiver, and thus NR, is located in a network site that 4112 is multihomed with several independently firewalled connections to 4113 the public Internet (as shown in Figure 48), the specific firewall 4114 through which the data traffic will be routed has to be ascertained. 4115 NATFW NSLP signaling messages sent from the NI+/NR during the REA 4116 request message exchange towards the NR+ must be routed by the NTLP 4117 to the edge-firewall that will be passed by the data traffic as well. 4118 The NTLP would need to be aware about the routing within the Internet 4119 to determine the path between DS and DR. Out of this, the NTLP could 4120 determine which of the edge-firewalls, either EFW1 or EFW2, must be 4121 selected to forward the NATFW NSLP signaling. Signaling to the wrong 4122 edge-firewall, as shown in Figure 48, would install the NATFW NSLP 4123 policy rules at the wrong device. This causes either a blocked data 4124 flow (when the policy rule is 'allow') or an ongoing attack (when the 4125 policy rule is 'deny'). Requiring the NTLP to know all about the 4126 routing within the Internet is definitely a tough challenge and 4127 usually not possible. In such described case, the NTLP must 4128 basically give up and return an error to the NSLP level, indicating 4129 that the next hop discovery is not possible. 4131 Appendix C. Firewall and NAT Resources 4133 This section gives some examples on how NATFW NSLP policy rules could 4134 be mapped to real firewall or NAT resources. The firewall rules and 4135 NAT bindings are described in a natural way, i.e., in a way one will 4136 find it in common implementation. 4138 C.1. Wildcarding of Policy Rules 4140 The policy rule/MRI to be installed can be wildcarded to some degree. 4141 Wildcarding applies to IP address, transport layer port numbers, and 4142 the IP payload (or next header in IPv6). Processing of wildcarding 4143 splits into the NTLP and the NATFW NSLP layer. The processing at the 4144 NTLP layer is independent of the NSLP layer processing and per layer 4145 constraints apply. For wildcarding in the NTLP see Section 5.8 of 4146 [2]. 4148 Wildcarding at the NATFW NSLP level is always a node local policy 4149 decision. A signaling message carrying a wildcarded MRI (and thus 4150 policy rule) arriving at an NSLP node can be rejected if the local 4151 policy does not allow the request. For instance, a MRI with IP 4152 addresses set (not wildcarded), transport protocol TCP, and TCP port 4153 numbers completely wildcarded. Now the local policy allows only 4154 requests for TCP with all ports set and not wildcarded. The request 4155 is going to be rejected. 4157 C.2. Mapping to Firewall Rules 4159 This section describes how a NSLP policy rule signaled with a CREATE 4160 request message is mapped to a firewall rule. The MRI is set as 4161 follows: 4163 o network-layer-version=IPv4 4165 o source-address=192.0.2.100, prefix-length=32 4167 o destination-address=192.0.50.5, prefix-length=32 4169 o IP-protocol=UDP 4171 o L4-source-port=34543, L4-destination-port=23198 4173 The NATFW_EFI object is set to action=allow and sub_ports=0. 4175 The resulting policy rule (firewall rule) to be installed might look 4176 like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198 4178 C.3. Mapping to NAT Bindings 4180 This section describes how a NSLP policy rule signaled with a REA 4181 request message is mapped to a NAT binding. It is assumed that the 4182 REA message is sent by a NI+ being located behind a NAT and does 4183 contain a NATFW_DTINFO object. The MRI is set following using the 4184 signaling destination address, since the IP address of the real data 4185 sender is not known: 4187 o network-layer-version=IPv4 4189 o source-address= 192.168.5.100 4191 o destination-address=SDA 4193 o IP-protocol=UDP 4195 The NATFW_EFI object is set to action=allow and sub_ports=0. The 4196 NATFW_DTINFO object contains these parameters: 4198 o P=1 4200 o dest prefix=0 4202 o protocol=UDP 4204 o dst port number = 20230, src port number=0 4206 o src IP=0.0.0.0 4208 The edge-NAT allocates the external IP 192.0.2.79 and port 45000. 4210 The resulting policy rule (NAT binding) to be installed could look 4211 like: translate from any to 192.0.2.79 port=45000 to 192.168.5.100 4212 port=20230 4214 C.4. NSLP Handling of Twice-NAT 4216 The dynamic configuration of twice-NATs requires application level 4217 support, as stated in Section 2.5. The NATFW NSLP cannot be used for 4218 configuring twice-NATs if application level support is needed. 4219 Assuming application level support performing the configuration of 4220 the twice-NAT and the NATFW NSLP being installed at this devices, the 4221 NATFW NSLP must be able to traverse it. The NSLP is probably able to 4222 traverse the twice-NAT, as any other data traffic, but the flow 4223 information stored in the NTLP's MRI will be invalidated through the 4224 translation of source and destination address. The NATFW NSLP 4225 implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP 4226 signaling messages as any other NATFW NSLP node does. For the given 4227 signaling flow, the NATFW NSLP node MUST look up the corresponding IP 4228 address translation and modify the NTLP/NSLP signaling accordingly. 4229 The modification results in an updated MRI with respect to the source 4230 and destination IP addresses. 4232 Authors' Addresses 4234 Martin Stiemerling 4235 Network Laboratories, NEC Europe Ltd. 4236 Kurfuersten-Anlage 36 4237 Heidelberg 69115 4238 Germany 4240 Phone: +49 (0) 6221 905 11 13 4241 Email: stiemerling@netlab.nec.de 4242 URI: http://www.stiemerling.org 4244 Hannes Tschofenig 4245 Siemens AG 4246 Otto-Hahn-Ring 6 4247 Munich 81739 4248 Germany 4250 Phone: 4251 Email: Hannes.Tschofenig@siemens.com 4252 URI: http://www.tschofenig.com 4254 Cedric Aoun 4255 Ecole Nationale Superieure des Telecommunications 4256 Paris 4257 France 4259 Email: cedric@caoun.net 4261 Elwyn Davies 4262 Folly Consulting 4263 Soham 4264 UK 4266 Phone: +44 7889 488 335 4267 Email: elwynd@dial.pipex.com 4269 Intellectual Property Statement 4271 The IETF takes no position regarding the validity or scope of any 4272 Intellectual Property Rights or other rights that might be claimed to 4273 pertain to the implementation or use of the technology described in 4274 this document or the extent to which any license under such rights 4275 might or might not be available; nor does it represent that it has 4276 made any independent effort to identify any such rights. Information 4277 on the procedures with respect to rights in RFC documents can be 4278 found in BCP 78 and BCP 79. 4280 Copies of IPR disclosures made to the IETF Secretariat and any 4281 assurances of licenses to be made available, or the result of an 4282 attempt made to obtain a general license or permission for the use of 4283 such proprietary rights by implementers or users of this 4284 specification can be obtained from the IETF on-line IPR repository at 4285 http://www.ietf.org/ipr. 4287 The IETF invites any interested party to bring to its attention any 4288 copyrights, patents or patent applications, or other proprietary 4289 rights that may cover technology that may be required to implement 4290 this standard. Please address the information to the IETF at 4291 ietf-ipr@ietf.org. 4293 Disclaimer of Validity 4295 This document and the information contained herein are provided on an 4296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4298 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4299 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4300 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4303 Copyright Statement 4305 Copyright (C) The Internet Society (2006). This document is subject 4306 to the rights, licenses and restrictions contained in BCP 78, and 4307 except as set forth therein, the authors retain all their rights. 4309 Acknowledgment 4311 Funding for the RFC Editor function is currently provided by the 4312 Internet Society.