idnits 2.17.1 draft-ietf-nsis-nslp-natfw-10.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 4298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4288. ** 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.8.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 (March 6, 2006) is 6623 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 2988 -- Looks like a reference, but probably isn't: 'O' on line 2954 -- Looks like a reference, but probably isn't: 'RFC3489' on line 3832 -- Looks like a reference, but probably isn't: 'RFC3424' on line 3846 == Unused Reference: '12' is defined on line 3959, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 3967, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 3982, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-08 -- 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) Summary: 4 errors (**), 0 flaws (~~), 9 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: September 7, 2006 H. Tschofenig 5 Siemens 6 C. Aoun 7 ENST 8 E. Davies 9 Folly Consulting 10 March 6, 2006 12 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 13 draft-ietf-nsis-nslp-natfw-10 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 7, 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 . . . . . . . . . . . . . 28 83 3.5 Message Sequencing . . . . . . . . . . . . . . . . . . . . 30 84 3.6 Session Ownership . . . . . . . . . . . . . . . . . . . . 30 85 3.7 Authentication, Authorization, and Policy Decisions . . . 31 86 3.8 Protocol Operations . . . . . . . . . . . . . . . . . . . 32 87 3.8.1 Creating Sessions . . . . . . . . . . . . . . . . . . 32 88 3.8.2 Reserving External Addresses . . . . . . . . . . . . . 35 89 3.8.3 NATFW Session Refresh . . . . . . . . . . . . . . . . 41 90 3.8.4 Deleting Sessions . . . . . . . . . . . . . . . . . . 42 91 3.8.5 Reporting Asynchronous Events . . . . . . . . . . . . 43 92 3.8.6 Tracing Signaling Sessions . . . . . . . . . . . . . . 45 93 3.8.7 Proxy Mode of Operation . . . . . . . . . . . . . . . 46 94 3.9 De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 49 95 3.10 Reacting to Route Changes . . . . . . . . . . . . . . . 51 96 3.11 Updating Policy Rules . . . . . . . . . . . . . . . . . 52 98 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . 53 99 4.1 NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 53 100 4.2 NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 54 101 4.2.1 Session Lifetime Object . . . . . . . . . . . . . . . 55 102 4.2.2 External Address Object . . . . . . . . . . . . . . . 55 103 4.2.3 Extended Flow Information Object . . . . . . . . . . . 56 104 4.2.4 Information Code Object . . . . . . . . . . . . . . . 57 105 4.2.5 Nonce Object . . . . . . . . . . . . . . . . . . . . . 60 106 4.2.6 Message Sequence Number Object . . . . . . . . . . . . 60 107 4.2.7 Data Terminal Information Object . . . . . . . . . . . 61 108 4.2.8 Trace Object . . . . . . . . . . . . . . . . . . . . . 62 109 4.2.9 NI Credential Object . . . . . . . . . . . . . . . . . 63 110 4.2.10 ICMP Types Object . . . . . . . . . . . . . . . . . 64 111 4.3 Message Formats . . . . . . . . . . . . . . . . . . . . . 64 112 4.3.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . . 65 113 4.3.2 RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . . 66 114 4.3.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 66 115 4.3.4 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 67 116 4.3.5 TRACE . . . . . . . . . . . . . . . . . . . . . . . . 67 118 5. Security Considerations . . . . . . . . . . . . . . . . . . 68 119 5.1 Authorization Framework . . . . . . . . . . . . . . . . . 68 120 5.2 Peer-to-Peer Relationship . . . . . . . . . . . . . . . . 68 121 5.3 Intra-Domain Relationship . . . . . . . . . . . . . . . . 69 122 5.4 End-to-Middle Relationship . . . . . . . . . . . . . . . . 70 123 5.5 Security Threats and Requirements . . . . . . . . . . . . 71 124 5.5.1 Data Sender (DS) behind a firewall . . . . . . . . . . 71 125 5.5.2 Data Sender (DS) behind a NAT . . . . . . . . . . . . 72 126 5.5.3 Data Receiver (DR) behind a firewall . . . . . . . . . 72 127 5.5.4 Data Receiver (DR) behind a NAT . . . . . . . . . . . 74 128 5.5.5 NSLP Message Injection . . . . . . . . . . . . . . . . 75 129 5.6 Denial-of-Service Attacks . . . . . . . . . . . . . . . . 76 130 5.6.1 Flooding with CREATE messages from outside . . . . . . 76 131 5.6.2 Flooding with REA messages from inside . . . . . . . . 77 132 5.7 Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 77 133 5.8 Message Modification by non-NSIS on-path node . . . . . . 78 134 5.9 Message Modification by malicious NSIS node . . . . . . . 78 135 5.10 Session Modification/Deletion . . . . . . . . . . . . . 79 136 5.10.1 Misuse of mobility in NAT handling . . . . . . . . . 79 137 5.11 Misuse of unreleased sessions . . . . . . . . . . . . . 81 138 5.12 Data Traffic Injection . . . . . . . . . . . . . . . . . 82 139 5.13 Eavesdropping and Traffic Analysis . . . . . . . . . . . 84 140 5.14 Security Framework for the NAT/Firewall NSLP . . . . . . 85 141 5.14.1 Security Protection between neighboring NATFW 142 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . 85 143 5.14.2 Security Protection between non-neighboring NATFW 144 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . 85 146 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . 88 148 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 89 150 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 90 152 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 91 154 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 155 10.1 Normative References . . . . . . . . . . . . . . . . . . 92 156 10.2 Informative References . . . . . . . . . . . . . . . . . 92 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 94 160 A. Selecting Signaling Destination Addresses for REA . . . . . 95 162 B. Applicability Statement on Data Receivers behind Firewalls . 97 164 C. Firewall and NAT Resources . . . . . . . . . . . . . . . . . 98 165 C.1 Wildcarding of Policy Rules . . . . . . . . . . . . . . . 98 166 C.2 Mapping to Firewall Rules . . . . . . . . . . . . . . . . 98 167 C.3 Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 99 168 C.4 NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 99 170 Intellectual Property and Copyright Statements . . . . . . . 101 172 1. Introduction 174 Firewalls and Network Address Translators (NAT) have both been used 175 throughout the Internet for many years, and they will remain present 176 for the foreseeable future. Firewalls are used to protect networks 177 against certain types of attacks from internal networks and the 178 Internet, whereas NATs provide a virtual extension of the IP address 179 space. Both types of devices may be obstacles to some applications, 180 since they only allow traffic created by a limited set of 181 applications to traverse them, typically those that use protocols 182 with relatively predetermined and static properties (e.g., most HTTP 183 traffic, and other client/server applications). Other applications, 184 such as IP telephony and most other peer-to-peer applications, which 185 have more dynamic properties, create traffic that is unable to 186 traverse NATs and firewalls unassisted. In practice, the traffic of 187 many applications cannot traverse autonomous firewalls or NATs, even 188 when they have additional functionality which attempts to restore the 189 transparency of the network. 191 Several solutions to enable applications to traverse such entities 192 have been proposed and are currently in use. Typically, application 193 level gateways (ALG) have been integrated with the firewall or NAT to 194 configure the firewall or NAT dynamically. Another approach is 195 middlebox communication (MIDCOM). In this approach, ALGs external to 196 the firewall or NAT configure the corresponding entity via the MIDCOM 197 protocol [7]. Several other work-around solutions are available, 198 such as STUN [19]. However, all of these approaches introduce other 199 problems that are generally hard to solve, such as dependencies on 200 the type of NAT implementation (full-cone, symmetric, etc), or 201 dependencies on certain network topologies. 203 NAT and firewall (NATFW) signaling shares a property with Quality of 204 Service (QoS) signaling. The signaling of both must reach any device 205 on the data path that is involved in, respectively, NATFW or QoS 206 treatment of data packets. This means, that for both, NATFW and QoS, 207 it is convenient if signaling travels path-coupled, meaning that the 208 signaling messages follow exactly the same path that the data packets 209 take. RSVP [13] is an example of a current QoS signaling protocol 210 that is path-coupled. [27] proposes the use of RSVP as firewall 211 signaling protocol but does not include NATs. 213 This memo defines a path-coupled signaling protocol for NAT and 214 firewall configuration within the framework of NSIS, called the NATFW 215 NSIS Signaling Layer Protocol (NSLP). The general requirements for 216 NSIS are defined in [5] and the general framework of NSIS is outlined 217 in [4]. It introduces the split between an NSIS transport layer and 218 an NSIS signaling layer. The transport of NSLP messages is handled 219 by an NSIS Network Transport Layer Protocol (NTLP, with General 220 Internet Signaling Transport (GIST) [1] being the implementation of 221 the abstract NTLP). The signaling logic for QoS and NATFW signaling 222 is implemented in the different NSLPs. The QoS NSLP is defined in 223 [6]. 225 The NATFW NSLP is designed to request the dynamic configuration of 226 NATs and/or firewalls along the data path. Dynamic configuration 227 includes enabling data flows to traverse these devices without being 228 obstructed, as well as blocking of particular data flows at upstream 229 firewalls. Enabling data flows requires the loading of firewall 230 rules with an action that allows the data flow packets to be 231 forwarded and creating NAT bindings. Blocking of data flows requires 232 the loading of firewalls rules with an action that will deny 233 forwarding of the data flow packets. A simplified example for 234 enabling data flows: A source host sends a NATFW NSLP signaling 235 message towards its data destination. This message follows the data 236 path. Every NATFW NSLP-enabled NAT/firewall along the data path 237 intercepts these messages, processes them, and configures itself 238 accordingly. Thereafter, the actual data flow can traverse all these 239 configured firewalls/NATs. 241 It is necessary to distinguish between two different basic scenarios 242 when operating the NATFW NSLP, independent of the type of middlebox 243 to be configured. 245 1. Both, data sender and data receiver, are NSIS NATFW NSLP aware. 246 This includes the cases where the data sender is logically 247 decomposed from the NSIS initiator or the data receiver logically 248 decomposed from the NSIS receiver, but both sides support NSIS. 249 This scenario assumes deployment of NSIS all over the Internet, 250 or at least at all NATs and firewalls. This scenario is referred 251 as to end-to-end mode operation and is used as base assumption if 252 not otherwise noted. 254 2. Only one end host or region of the network is NSIS NATFW NSLP 255 aware, either data receiver or data sender. This scenario is 256 referred to as proxy mode operation. 258 NATFW NSLP provides two basic signaling modes which are sufficient to 259 cope with the various possible scenarios likely to be encountered 260 before and after widespread deployment of NSIS: 262 CREATE mode: The basic mode for configuring a path downstream from 263 a data sender to a data receiver. 265 RESERVE-EXTERNAL-ADDRESS (REA) mode: Used to locate upstream NATs/ 266 firewalls and prime them to expect downstream signaling and at 267 NATs to pre-allocate a public address. This is used for data 268 receivers behind these devices to enable their reachability. 270 Once there is full deployment of NSIS (i.e., end-to-end mode 271 operations are possible), the requisite NAT and firewall state can be 272 created using only CREATE mode. However, if the data receiver 273 resides in a public addressing realm. If the data receiver resides 274 in a private addressing realm, and needs to preconfigure the edge- 275 NAT/edge-firewall to provide a (publicly) reachable address for use 276 by the data sender, a combination of RESERVE-EXTERNAL-ADDRESS and 277 CREATE modes is used. 279 During the introduction of NSIS, it is likely that one or other of 280 the data sender and receiver will not be NSIS aware. In these cases, 281 the NATFW NSLP can utilize NSIS aware middleboxes on the path between 282 the data sender and data receiver to provide proxy NATFW NSLP 283 services (i.e., proxy mode operation). Typically, these boxes will 284 be at the boundaries of the realms in which the end hosts are 285 located. 287 All modes of operation create NATFW NSLP and NTLP state in NSIS 288 entities. NTLP state allows signaling messages to travel in the 289 forward (downstream) and the reverse (upstream) direction along the 290 path between a NAT/firewall NSLP sender and a corresponding receiver. 291 This state is managed using a soft-state mechanism, i.e., it expires 292 unless it is refreshed from time to time. The NAT bindings and 293 firewall rules being installed during the state setup are bound to 294 the particular signaling session. However, the exact local 295 implementation of the NAT bindings and firewall rules are NAT/ 296 firewall specific. 298 This memo is structured as follows. Section 2 describes the network 299 environment for NATFW NSLP signaling. Section 3 defines the NATFW 300 signaling protocol and Section 4 defines the message components and 301 the overall messages used in the protocol. The remaining parts of 302 the main body of the document, covers security considerations 303 Section 5, IAB considerations on UNilateral Self-Address Fixing 304 (UNSAF) [15] in Section 6 and IANA considerations in Section 7. 305 Please note that readers familiar with firewalls and NATs and their 306 possible location within networks can safely skip Section 2. 308 1.1 Terminology and Abbreviations 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 311 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 312 document are to be interpreted as described in [2]. 314 This document uses a number of terms defined in [5] and [4]. The 315 following additional terms are used: 317 o Policy rule: A policy rule is "a basic building block of a policy- 318 based system. It is the binding of a set of actions to a set of 319 conditions - where the conditions are evaluated to determine 320 whether the actions are performed" [20]. In the context of NSIS 321 NATFW NSLP, the conditions are the specification of a set of 322 packets to which the rule is applied. The set of actions always 323 contains just a single element per rule, and is limited to either 324 action "deny" or action "allow". 326 o Reserved policy rule: A policy rule stored at NATs or firewalls 327 for activation by a later, different signaling exchange. This 328 type of policy rule is kept in the NATFW NSLP and is not loaded 329 into the firewall or NAT engine, i.e., it does not affect the data 330 flow handling. 332 o Installed policy rule: A policy rule in operation at NATs or 333 firewalls. This type of rule is kept in the NATFW NSLP and is 334 loaded into the firewall or NAT engine, i.e., it is affecting the 335 data flow. 337 o Remembered policy rule: A policy rule stored at NATs and firewalls 338 for immediate use, as soon as the signaling exchange is 339 successfully completed. 341 o Firewall: A packet filtering device that matches packets against a 342 set of policy rules and applies the actions. In the context of 343 NSIS NATFW NSLP we refer to this device as a firewall. 345 o Network Address Translator: Network Address Translation is a 346 method by which IP addresses are mapped from one IP address realm 347 to another, in an attempt to provide transparent routing between 348 hosts (see [9]). Network Address Translators are devices that 349 perform this work by modifying packets passing through them. 351 o Middlebox: "A middlebox is defined as any intermediate device 352 performing functions other than the normal, standard functions of 353 an IP router on the datagram path between a source host and a 354 destination host" [11]. In the context of this document, the term 355 middlebox refers to firewalls and NATs only. Other types of 356 middlebox are outside of the scope of this document. 358 o Data Receiver (DR): The node in the network that is receiving the 359 data packets of a flow. 361 o Data Sender (DS): The node in the network that is sending the data 362 packets of a flow. 364 o NATFW NSLP session or signaling session: An application layer flow 365 of information for which some network control state information is 366 to be manipulated or monitored (as defined in [4]). The control 367 state for NATFW NSLP consists of NSLP state and associated policy 368 rules at a middlebox. 370 o NSIS peer or peer: An NSIS node with which an NSIS adjacency has 371 been created as defined in [1]. 373 o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP 374 address which is reachable from the public Internet. 376 o Edge-firewall: An edge-firewall is a firewall device that is 377 located on the border line of an administrative domain. 379 o Public Network: "A Global or Public Network is an address realm 380 with unique network addresses assigned by Internet Assigned 381 Numbers Authority (IANA) or an equivalent address registry. This 382 network is also referred as external network during NAT 383 discussions" [9]. 385 o Private/Local Network: "A private network is an address realm 386 independent of external network addresses. Private network may 387 also be referred alternately as Local Network. Transparent 388 routing between hosts in private realm and external realm is 389 facilitated by a NAT router" [9]. 391 o Public/Global IP address: An IP address located in the public 392 network according to Section 2.7 of [9]. 394 o Private/Local IP address: An IP address located in the private 395 network according to Section 2.8 of [9]. 397 o Signaling Destination Address (SDA): An IP address generally taken 398 from the public/global IP address range, although, the SDA may in 399 certain circumstances be part of the private/local IP address 400 range. This address is used in REA signaling message exchanges, 401 if the data receiver's IP address is unknown. 403 1.2 Middleboxes 405 The term middlebox covers a range of devices which intercept the flow 406 of packets between end hosts and perform actions other than standard 407 forwarding expected in an IP router. As such, middleboxes fall into 408 a number of categories with a wide range of functionality, not all of 409 which is pertinent to the NATFW NSLP. Middlebox categories in the 410 scope of this memo are firewalls that filter data packets against a 411 set of filter rules, and NATs that translate packet addresses from 412 one address realm to another address realm. Other categories of 413 middleboxes, such as QoS traffic shapers, are out of scope of this 414 memo. 416 The term NAT used in this document is a placeholder for a range of 417 different NAT flavors. We consider the following types of NATs: 419 o Traditional NAT (basic NAT and NAPT) 421 o Bi-directional NAT 423 o Twice-NAT 425 o Multihomed NAT 427 For definitions and a detailed discussion about the characteristics 428 of each NAT type please see [9]. 430 All types of middleboxes under consideration here, use policy rules 431 to make a decision on data packet treatment. Policy rules consist of 432 a flow identifier which selects the packets to which the policy 433 applies and an associated action; data packets matching the flow 434 identifier are subjected to the policy rule action. A typical flow 435 identifier is the 5-tuple selector which matches the following fields 436 of a packet to configured values: 438 o Source and destination IP addresses 440 o Transport protocol number 442 o Transport source and destination port numbers 444 Actions for firewalls are usually one or more of: 446 o Allow: forward data packet 448 o Deny: block data packet and discard it 450 o Other actions such as logging, diverting, duplicating, etc 452 Actions for NATs include (amongst many others): 454 o Change source IP address and transport port number to a globally 455 routeable IP address and associated port number. 457 o Change destination IP address and transport port number to a 458 private IP address and associated port number. 460 It should be noted that a middlebox may contain two logical 461 representations of the policy rule. The policy rule has a 462 representation within the NATFW NSLP, comprising the message routing 463 information (MRI) of the NTLP and NSLP information (such as the rule 464 action). The other representation is the implementation of the NATFW 465 NSLP policy rule within the NAT and firewall engine of the particular 466 device. Refer to Appendix C for further details. 468 1.3 General Scenario for NATFW Traversal 470 The purpose of NSIS NATFW signaling is to enable communication 471 between endpoints across networks, even in the presence of NAT and 472 firewall middleboxes that have not been specially engineered to 473 facilitate communication with the application protocols used. This 474 removes the need to create and maintain application layer gateways 475 for specific protocols that have been commonly used to provide 476 transparency in previous generations of NAT and firewall middleboxes. 477 It is assumed that these middleboxes will be statically configured in 478 such a way that NSIS NATFW signaling messages themselves are allowed 479 to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP 480 signaling is used to dynamically install additional policy rules in 481 all NATFW middleboxes along the data path that will allow 482 transmission of the application data flow(s). Firewalls are 483 configured to forward data packets matching the policy rule provided 484 by the NSLP signaling. NATs are configured to translate data packets 485 matching the policy rule provided by the NSLP signaling. An 486 additional capability, that is an exception to the primary goal of 487 NSIS NATFW signaling, is that the NATFW nodes can request blocking of 488 particular data flows instead of enabling these flows at upstream 489 firewalls. 491 The basic high-level picture of NSIS usage is that end hosts are 492 located behind middleboxes, meaning that there is a middlebox on the 493 data path from the end host in a private network and the external 494 network (NATFW in Figure 1). Applications located at these end hosts 495 try to establish communication with corresponding applications on 496 other such end hosts. They trigger the NSIS entity at the local host 497 to control provisioning for middlebox traversal along the prospective 498 data path (e.g., via an API call). The NSIS entity in turn uses NSIS 499 NATFW NSLP signaling to establish policy rules along the data path, 500 allowing the data to travel from the sender to the receiver 501 unobstructed. 503 Application Application Server (0, 1, or more) Application 505 +----+ +----+ +----+ 506 | +------------------------+ +------------------------+ | 507 +-+--+ +----+ +-+--+ 508 | | 509 | NSIS Entities NSIS Entities | 510 +-+--+ +----+ +-----+ +-+--+ 511 | +--------+ +----------------------------+ +-----+ | 512 +-+--+ +-+--+ +--+--+ +-+--+ 513 | | ------ | | 514 | | //// \\\\\ | | 515 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 516 | | | | | Internet | | | | | 517 | +--------+ +-----+ +----+ +-----+ | 518 +----+ +----+ |\ | +----+ +----+ 519 \\\\ ///// 520 sender NATFW (1+) ------ NATFW (1+) receiver 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. As described in 657 Section 3.8.2 NSIS can also provide help for this procedure. 659 2.4 NAT with Private Network on Receiver Side Scenario 661 The application instance receiving data is behind one or more NATs 662 shown as MB (see discussion in Section 2.2). 664 //----\\ +----+ +----+ 665 NI ---| |---| MB |-----| MB |--- NR 666 \\----// +----+ +----+ 668 public private 670 MB: Middlebox 671 NI: NSIS Initiator 672 NR: NSIS Responder 674 Figure 5: NAT with Private Network on Receiver Scenario 676 Initially, the NSIS responder must determine its publicly reachable 677 IP address at the external middlebox and notify the NSIS initiator 678 about this address. One possibility is that an application level 679 protocol is used, meaning that the public IP address is signaled via 680 this protocol to the NI. Afterwards the NI can start its signaling 681 towards the NR and therefore establish the path via the middleboxes 682 in the receiver side private network. 684 This scenario describes the use case for the RESERVE-EXTERNAL-ADDRESS 685 mode of the NATFW NSLP. 687 2.5 Both End Hosts behind twice-NATs 689 This is a special case, where the main problem arises from the need 690 to detect that both end hosts are logically within the same address 691 space, but are also in two partitions of the address realm on either 692 side of a twice-NAT (see [9] for a discussion of twice-NAT 693 functionality). 695 Sender and receiver are both within a single private address realm 696 but the two partitions potentially have overlapping IP address 697 ranges. Figure 6 shows the arrangement of NATs. This is a common 698 configuration in networks, particularly after the merging of 699 companies that have used the same private address space, resulting in 700 overlapping address ranges. 702 public 703 +----+ +----+ //----\\ 704 NI --| MB |--+--| MB |---| | 705 +----+ | +----+ \\----// 706 | 707 | +----+ 708 +--| MB |------------ NR 709 +----+ 711 private 713 MB: Middlebox 714 NI: NSIS Initiator 715 NR: NSIS Responder 717 Figure 6: NAT to Public, Sender and Receiver on either side of a 718 twice-NAT Scenario 720 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 721 addresses and port numbers on both sides, meaning the mapping of 722 source and destination address at the private and public interfaces. 724 This scenario requires the assistance of application level entities, 725 such as a DNS server. The application level entities must handle 726 requests that are based on symbolic names, and configure the 727 middleboxes so that data packets are correctly forwarded from NI to 728 NR. The configuration of those middleboxes may require other 729 middlebox communication protocols, such as MIDCOM [7]. NSIS 730 signaling is not required in the twice-NAT only case, since 731 middleboxes of the twice-NAT type are normally configured by other 732 means. Nevertheless, NSIS signaling might be useful when there are 733 also firewalls on the path. In this case NSIS will not configure any 734 policy rule at twice-NATs, but will configure policy rules at the 735 firewalls on the path. The NSIS signaling protocol must be at least 736 robust enough to survive this scenario. This requires that twice- 737 NATs must implement the NATFW NSLP also and participate in NATFW 738 sessions but they do not change the configuration of the NAT, i.e., 739 they only read the address mapping information out of the NAT and 740 translate the Message Routing Information (MRI, [1]) within the NSLP 741 and NTLP accordingly. For more information see Appendix C.4 743 2.6 Both End Hosts Behind Same NAT 745 When NSIS initiator and NSIS responder are behind the same NAT (thus 746 being in the same address realm, see Figure 7), they are most likely 747 not aware of this fact. As in Section 2.4 the NSIS responder must 748 determine its public IP address in advance and transfer it to the 749 NSIS initiator. Afterwards, the NSIS initiator can start sending the 750 signaling messages to the responder's public IP address. During this 751 process, a public IP address will be allocated for the NSIS initiator 752 at the same middlebox as for the responder. Now, the NSIS signaling 753 and the subsequent data packets will traverse the NAT twice: from 754 initiator to public IP address of responder (first time) and from 755 public IP address of responder to responder (second time). This is 756 the worst case in which both sender and receiver obtain a public IP 757 address at the NAT, and the communication path is certainly not 758 optimal in this case. 760 NI public 761 \ +----+ //----\\ 762 +-| MB |----| | 763 / +----+ \\----// 764 NR 765 private 767 MB: Middlebox 768 NI: NSIS Initiator 769 NR: NSIS Responder 771 Figure 7: NAT to Public, Both Hosts Behind Same NAT 773 2.7 IPv4/v6 NAT with two Private Networks 775 This scenario combines the use case described in Section 2.2 with the 776 IPv4 to IPv6 transition scenario involving address and protocol 777 translation, i.e., using Network Address and Protocol Translators 778 (NAT-PT, [10]). 780 The difference from the other scenarios is the use of IPv6 to IPv4 781 (and vice versa) address and protocol translation. Additionally, the 782 base NTLP must support transport of messages in mixed IPv4 and IPv6 783 networks where some NSIS peers provide translation. 785 +----+ +----+ //---\\ +----+ //---\\ +----+ +----+ 786 NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR 787 +----+ +----+ \\---// +----+ \\---// +----+ +----+ 789 private public public private 790 IPv4 IPv6 792 MB: Middlebox 793 NI: NSIS Initiator 794 NR: NSIS Responder 796 Figure 8: IPv4/v6 NAT with two Private Networks 798 This scenario needs the same type of application level support as 799 described in Section 2.5, and so the issues relating to twice-NATs 800 apply here as well. 802 Note that the current form of IPv4/v6 NAT known as the Network 803 Address Translator - Protocol Translator (NAT-PT) [10] is being 804 removed from the set of recommended mechanisms for general usage in 805 IPv4/IPv6 transitions. This scenario is therefore not expected to be 806 commonly seen. 808 2.8 Multihomed Network with NAT 810 The previous sub-sections sketched network topologies where several 811 NATs and/or firewalls are ordered sequentially on the path. This 812 section describes a multihomed scenario with two NATs placed on 813 alternative paths to the public network. 815 +----+ 816 NI -------| MB |\ 817 \ +----+ \ //---\\ 818 \ -| |-- NR 819 \ \\---// 820 \ +----+ | 821 --| MB |-------+ 822 +----+ 824 private public 826 MB: Middlebox 827 NI: NSIS Initiator 828 NR: NSIS Responder 830 Figure 9: Multihomed Network with Two NATs 832 Depending on the destination, either one or the other middlebox is 833 used for the data flow. Which middlebox is used, depends on local 834 policy or routing decisions. NATFW NSLP must be able to handle this 835 situation properly, see Section 3.8.2 for an extended discussion of 836 this topic with respect to NATs. 838 2.9 Multihomed Network with Firewall 840 This section describes a multihomed scenario with two firewalls 841 placed on alternative paths to the public network (Figure 10). The 842 routing in the private and public network decides which firewall is 843 being taken for data flows. Depending on the data flow's direction, 844 either outbound or inbound, a different firewall could be traversed. 845 This is a challenge for the REA mode of the NATFW NSLP where the NSIS 846 responder is located behind these firewalls within the private 847 network. The REA mode is used to block a particular data flow on an 848 upstream firewall. NSIS must route the REA mode message upstream 849 from NR to NI probably without knowing which path the data traffic 850 will take from NI to NR (see also Appendix B. 852 +----+ 853 NR -------| MB |\ 854 \ +----+ \ //---\\ 855 \ -| |-- NI 856 \ \\---// 857 \ +----+ | 858 --| MB |-------+ 859 +----+ 860 private 861 private public 863 MB: Middlebox 864 NI: NSIS Initiator 865 NR: NSIS Responder 867 Figure 10: Multihomed Network with two Firewalls 869 3. Protocol Description 871 This section defines messages, objects, and protocol semantics for 872 the NATFW NSLP. 874 3.1 Policy Rules 876 Policy rules, bound to a session, are the building blocks of 877 middlebox devices considered in the NATFW NSLP. For firewalls the 878 policy rule usually consists of a 5-tuple, source/destination 879 addresses, transport protocol, and source/destination port numbers, 880 plus an action, such as allow or deny. For NATs the policy rule 881 consists of the action 'translate this address' and further mapping 882 information, that might be, in the simplest case, internal IP address 883 and external IP address. 885 The NATFW NSLP carries, in conjunction with the NTLP's Message 886 Routing Information (MRI), the policy rules to be installed at NATFW 887 peers. This policy rule is an abstraction with respect to the real 888 policy rule to be installed at the respective firewall or NAT. It 889 conveys the initiator's request and must be mapped to the possible 890 configuration on the particular used NAT and/or firewall in use. For 891 pure firewalls one or more filter rules must be created and for pure 892 NATs one or more NAT bindings must be created. In mixed firewall and 893 NAT boxes, the policy rule must be mapped to filter rules and 894 bindings observing the ordering of the firewall and NAT engine. 895 Depending on the ordering, NAT before firewall or vice versa, the 896 firewall rules must carry public or private IP addresses. However, 897 the exact mapping depends on the implementation of the firewall or 898 NAT which is different for each vendor. 900 The policy rule at the NATFW NSLP level comprises the message routing 901 information (MRI) part, carried in the NTLP, and the information 902 available in the NATFW NSLP. The information provided by the NSLP is 903 stored in the 'extend flow information' (NATFW_EFI) and 'data 904 terminal information' (NATFW_DTINFO) objects, and the message type, 905 in particular the flow direction. Additional information, such as 906 the external IP address and port number, stored in the NAT or 907 firewall, will be used as well. The MRI carries the filter part of 908 the NAT/firewall-level policy rule that is to be installed. 910 3.2 Basic Protocol Overview 912 The NSIS NATFW NSLP is carried over the General Internet Signaling 913 Transport (GIST, the implementation of the NTLP) defined in [1]. 914 NATFW NSLP messages are initiated by the NSIS initiator (NI), handled 915 by NSIS forwarders (NF) and received by the NSIS responder (NR). It 916 is required that at least NI and NR implement this NSLP, intermediate 917 NFs only implement this NSLP when they provide relevant middlebox 918 functions. NSIS forwarders that do not have any NATFW NSLP functions 919 just forward these packets as they have no interest in them. 921 A Data Sender (DS), intending to send data to a Data Receiver (DR) 922 must first initiate NATFW NSLP signaling. This causes the NI 923 associated with the data sender (DS) to launch NSLP signaling towards 924 the address of data receiver (DR) (see Figure 11). Although it is 925 expected that the DS and the NATFW NSLP NI will usually reside on the 926 same host, this specification does not rule out scenarios where the 927 DS and NI reside on different hosts, the so-called proxy mode (see 928 Section 1.) 930 +-------+ +-------+ +-------+ +-------+ 931 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 932 | |--->| NF1 |--->| NF2 |--->| | 933 +-------+ +-------+ +-------+ +-------+ 935 ========================================> 936 Data Traffic Direction (downstream) 938 ---> : NATFW NSLP request signaling 939 ~~~> : NATFW NSLP response signaling 940 DS/NI : Data sender and NSIS initiator 941 DR/NR : Data receiver and NSIS responder 942 MB1 : Middlebox 1 and NSIS forwarder 1 943 MB2 : Middlebox 2 and NSIS forwarder 2 945 Figure 11: General NSIS signaling 947 The normal sequence of NSLP events is as follows: 949 o NSIS initiators generate NATFW NSLP request messages and send 950 these towards the NSIS responder. Note, that the NSIS initiator 951 may not necessarily be the data sender but may be the data 952 receiver, for instance, when using the RESERVE-EXTERNAL-ADDRESS 953 (REA) message. 955 o NSLP request messages are processed each time a NF with NATFW NSLP 956 support is traversed. These nodes process the message, check 957 local policies for authorization and authentication, possibly 958 create policy rules, and forward the signaling message to the next 959 NSIS node. The request message is forwarded until it reaches the 960 NSIS responder. 962 o NSIS responders will check received messages and process them if 963 applicable. NSIS responders generate response messages and send 964 them hop-by-hop back to the NI via the same chain of NFs 965 (traversal of the same NF chain is guaranteed through the 966 established reverse message routing state in the NTLP). Note, 967 that the NSIS responder may not necessarily be the data receiver 968 but may be any intermediate NSIS node that terminates the 969 forwarding, for example, in a proxy mode case where an edge-NAT is 970 replying to requests. 972 o The response message is processed at each NF that has been 973 included in the prior signaling session setup. 975 o Once the NI has received a successful response, the data sender 976 can start sending its data flow to the data receiver. 978 Because NATFW NSLP signaling follows the data path from DS to DR, 979 this immediately enables communication between both hosts for 980 scenarios with only firewalls on the data path or NATs on the sender 981 side. For scenarios with NATs on the receiver side certain problems 982 arise, as described in Section 2. 984 When the NR and the NI are located in different address realms and 985 the NR is located behind a NAT, the NI cannot signal to the NR 986 address directly. The DR and NR are not reachable from the NIs using 987 the private address of the NR and thus NATFW signaling messages 988 cannot be sent to the NR/DR's address. Therefore, the NR must first 989 obtain a NAT binding that provides an address that is reachable for 990 the NI. Once the NR has acquired a public IP address, it forwards 991 this information to the DS via a separate protocol. This application 992 layer signaling, which is out of scope of the NATFW NSLP, may involve 993 third parties that assist in exchanging these messages. 995 The same holds partially true for NRs located behind firewalls that 996 block all traffic by default. In this case, NR must tell its 997 upstream firewalls of inbound NATFW NSLP signaling and corresponding 998 data traffic. Once the NR has informed the upstream firewalls, it 999 can start its application level signaling to initiate communication 1000 with the NI. This application layer signaling, which is out of scope 1001 of the NATFW NSLP, may involve third parties that assist in 1002 exchanging these messages. This mechanism can be used by machines 1003 hosting services behind firewalls as well. In this case, the NR 1004 informs the upstream firewalls as described, but does not need to 1005 communicate this to the NIs. 1007 NATFW NSLP signaling supports this scenario by using the REA mode of 1008 operation 1010 1. The NR acquires a public address by signaling on the reverse path 1011 (NR towards NI) and thus making itself available to other hosts. 1012 This process of acquiring public addresses is called reservation. 1013 During this process the NR reserves publicly reachable addresses 1014 and ports suitable for further usage in application level 1015 signaling and the publicly reachable address for further NATFW 1016 NSLP signaling. However, the data traffic will not be allowed to 1017 use this address/port initially (see next point). 1019 2. The NI signals directly to the NR, as the NI would do if there is 1020 no NAT in between, and creates policy rules at middleboxes. 1021 Note, that the reservation mode will only allow forwarding of 1022 signaling messages, but not data flow packets. Policy rules 1023 allowing forwarding of data flow packets set up by the prior REA 1024 mode signaling will be 'activated' by the signaling from NI 1025 towards NR. The RESERVE-EXTERNAL-ADDRESS (REA) mode of operation 1026 is detailed in Section 3.8.2 1028 +-------+ +-------+ +-------+ +-------+ 1029 | DS/NI |<~~~| MB1/ |<~~~| NR | | DR | 1030 | |--->| NF1 |--->| | | | 1031 +-------+ +-------+ +-------+ +-------+ 1033 ========================================> 1034 Data Traffic Direction (downstream) 1036 ---> : NATFW NSLP request signaling 1037 ~~~> : NATFW NSLP response signaling 1038 DS/NI : Data sender and NSIS initiator 1039 DR/NR : Data receiver and NSIS responder 1040 MB1 : Middlebox 1 and NSIS forwarder 1 1041 MB2 : Middlebox 2 and NSIS forwarder 2 1043 Figure 12: A NSIS proxy mode signaling 1045 The above usage assumes that both ends of a communication support 1046 NSIS, but fails when NSIS is only deployed at one end of the path. 1047 In this case only one of the receiving or sending side is NSIS aware 1048 and not both at the same time. NATFW NSLP supports this scenario 1049 (i.e., the DR does not support NSIS) by using a proxy mode, as 1050 described in Section 3.8.7; the proxy mode operation also supports 1051 scenarios with a data sender that does not support NSIS, i.e. the 1052 data receiver must act to enable data flows towards itself. 1054 The basic functionality of the NATFW NSLP provides for opening 1055 firewall pin holes and creating NAT bindings to enable data flows to 1056 traverse these devices. Firewalls are normally expected to work on a 1057 'deny-all' policy, meaning that traffic not explicitly matching any 1058 firewall filter rule will be blocked. Similarly, the normal behavior 1059 of NATs is to block all traffic that does not match any already 1060 configured/installed binding or session. However, some scenarios 1061 require support of firewalls having 'allow-all' policies, allowing 1062 data traffic to traverse the firewall unless it is blocked 1063 explicitly. Data receivers can utilize NATFW NSLP's REA message with 1064 action set to 'deny' to install policy rules at upstream firewalls to 1065 block unwanted traffic. 1067 The protocol works on a soft-state basis, meaning that whatever state 1068 is installed or reserved on a middlebox will expire, and thus be de- 1069 installed or forgotten after a certain period of time. To prevent 1070 premature removal of state that is needed for ongoing communication, 1071 the NATFW NI involved will have to specifically request a session 1072 extension. An explicit NATFW NSLP state deletion capability is also 1073 provided by the protocol. 1075 If the actions requested by a NATFW NSLP message cannot be carried 1076 out, NFs and the NR should return a failure, such that appropriate 1077 actions can be taken. They can do this either during a the request 1078 message handling (synchronously) by sending an error RESPONSE 1079 message, or at any time (asynchronously) by sending a notification 1080 message. 1082 The next sections define the NATFW NSLP message types and formats, 1083 protocol operations, and policy rule operations. 1085 3.2.1 Message Types 1087 The protocol uses five messages types: 1089 o CREATE: a request message used for creating, changing, refreshing, 1090 and deleting CREATE NATFW NSLP sessions, i.e., open the data path 1091 from DS to DR. 1093 o RESERVE-EXTERNAL-ADDRESS (REA): a request message used for 1094 reserving, changing, refreshing, and deleting REA NATFW NSLP 1095 sessions. REA messages are forwarded to the edge-NAT or edge- 1096 firewall and allow inbound CREATE messages to be forwarded to the 1097 NR. Additionally, REA messages reserve an external address and, 1098 if applicable, port number at an edge-NAT. 1100 o TRACE: a request message to trace all involved NATFW NSLP nodes in 1101 a particular signaling session. 1103 o NOTIFY: an asynchronous message used by NATFW peers to alert 1104 upstream NATFW peers about specific events (especially failures). 1106 o RESPONSE: used as a response to CREATE, REA, and TRACE request 1107 messages. 1109 3.2.2 Classification of RESPONSE Messages 1111 RESPONSE messages will be generated synchronously by NSIS Forwarders 1112 and Responders to report success or failure of operations or some 1113 information relating to the session or a node. 1115 All RESPONSE messages MUST carry a NATFW_INFO object which contains a 1116 severity class code and a response code (see Section 4.2.4). This 1117 section defines terms for groups of RESPONSE messages depending on 1118 the severity class. 1120 o Successful RESPONSE: Messages carrying NATFW_INFO with severity 1121 class 'Success' (0x2). 1123 o Informational RESPONSE: Messages carrying NATFW_INFO with severity 1124 class 'Informational' (0x1) (normally only used with NOTIFY 1125 messages). 1127 o Error RESPONSE: Messages carrying NATFW_INFO with severity class 1128 other than 'Success' or 'Informational'. 1130 3.2.3 NATFW NSLP Signaling Sessions 1132 The general idea of signaling sessions is described in [4]. There is 1133 signaling session state stored at the NTLP layer and at the NATFW 1134 NSLP level. The signaling session state for the NATFW NSLP consists 1135 comprises NSLP state and the associated policy rules at a middlebox. 1137 A NATFW NSLP signaling session can conceptually be in different 1138 states, implementations may use other or even more states. The 1139 signaling session can have these states at a node: 1141 o Pending: The signaling session has been created and the node is 1142 waiting for a RESPONSE message to the request message. A 1143 signaling session in state 'Pending' MUST be marked as 'Dead' if 1144 no corresponding RESPONSE message has been received within the 1145 time of the locally granted session lifetime of the forwarded 1146 request message (as described in Section 3.4). 1148 o Established: The signaling session is established, i.e, the 1149 signaling has been successfully performed. A signaling session in 1150 state 'Established' MUST be marked as 'Dead' if no refresh message 1151 has been received within the time of the locally granted session 1152 lifetime of the RESPONSE message (as described in Section 3.4). 1154 o Dead: The node has received an error RESPONSE message for the 1155 signaling session and the signaling session can be deleted. 1157 o Transit: The node has received an asynchronous message, i.e., a 1158 NOTIFY, and can delete the signaling session if needed. When a 1159 node has received a NOTIFY message (for instance, indicating a 1160 route change) it marks it as 'Transit' and deletes this session if 1161 it is unused for some time specific to the local node. This idle 1162 time does not need to be fixed, since it can depend on the node 1163 local maintenance cycle, i.e., the session could be deleted if the 1164 node runs it garbage collection cycle. 1166 3.3 Basic Message Processing 1168 All NATFW messages are subject to some basic message processing when 1169 received at a node, independent of request or response messages. 1170 Initially, the syntax of the NSLP message is checked and a RESPONSE 1171 message with an appropriate error of class 'Protocol error' (0x1) 1172 code is generated if any problem is detected. If a message is 1173 delivered to the NATFW NSLP, this implies that the NTLP layer has 1174 been able to correlate it with the SID and MRI entries in its 1175 database. There is therefore enough information to identify the 1176 source of the message and routing information to route the message 1177 back to the NI through an established chain of MAs since the NATFW 1178 NSLP always requests reliable delivery resulting in the NTLP using 1179 C-mode. The message is not further forwarded if any error in the 1180 syntax is detected. The specific response codes stemming from the 1181 processing of objects are described in the respective object 1182 definition section (see Section 4). After passing this check, the 1183 NATFW NSLP node MUST first perform the checks defined on session 1184 ownership in Section 3.6 and authentication/authorization in 1185 Section 3.7. Further processing is executed only if these tests have 1186 been successfully passed, otherwise the processing stops and an error 1187 RESPONSE is returned, as described in these sections. 1189 Further message processing stops whenever an error RESPONSE message 1190 is generated, and the request message is discarded. 1192 3.4 Calculation of Session Lifetime 1194 NATFW NSLP sessions, and the corresponding policy rules which may 1195 have been installed, are maintained via a soft-state mechanism. Each 1196 session is assigned a lifetime and the session is kept alive as long 1197 as the lifetime is valid. After the expiration of the lifetime, 1198 sessions and policy rules MUST be removed automatically and resources 1199 bound to them MUST be freed as well. Session lifetime is handled at 1200 every NATFW NSLP node. The NSLP forwarders and NSLP responder MUST 1201 NOT trigger lifetime extension refresh messages (see Section 3.8.3): 1202 this is the task of the NSIS initiator. This section describes how 1203 the session lifetime is set within a signaling session. 1205 The NSIS initiator MUST choose a session lifetime value (expressed in 1206 seconds) before sending any message, including the initial message 1207 which creates the session, to other NSLP nodes. The session 1208 lifetime value is calculated based on: 1210 o The number of lost refresh messages that NFs should cope with; 1212 o the end-to-end delay between the NI and NR; 1214 o network vulnerability due to session hijacking ([8], session 1215 hijacking is made easier when the NI does not explicitly remove 1216 the session); 1218 o the user application's data exchange duration, in terms of time 1219 and networking needs. This duration is modeled as M x R, with R 1220 the message refresh period (in seconds) and M as a multiplier for 1221 R; 1223 The RSVP specification [13] provides an appropriate algorithm for 1224 calculating the session lifetime as well as means to avoid refresh 1225 message synchronization between sessions. [13] recommends: 1227 1. The refresh message timer to be randomly set to a value in the 1228 range [0.5R, 1.5R]. 1230 2. To avoid premature loss of state, lt (with lt being the session 1231 lifetime) must satisfy lt >= (K + 0.5)*1.5*R, where K is a small 1232 integer. Then in the worst case, K-1 successive messages may be 1233 lost without state being deleted. Currently K = 3 is suggested 1234 as the default. However, it may be necessary to set a larger K 1235 value for hops with high loss rate. Other algorithms could be 1236 used to define the relation between the session lifetime and the 1237 refresh message period; the algorithm provided is only given as 1238 an example. 1240 This requested lifetime value lt is stored in the NATFW_LT object of 1241 the NSLP message. 1243 NATFW NFs processing the request message along the path may change 1244 the requested lifetime to fit their needs and/or local policy. If an 1245 NF changes the lifetime value, it MUST store the new value in the 1246 'lifetime' object. NFs MUST NOT increase the lifetime value; they 1247 MAY reject the requested lifetime immediately and MUST generate an 1248 error RESPONSE message of class 'Signaling session failures' (0x6) 1249 with error response code 'Requested lifetime is too big' (0x02) upon 1250 rejection. The NSLP request message is forwarded until it reaches 1251 the NSLP responder. The NSLP responder may reject the requested 1252 lifetime value and MUST generate an error RESPONSE message of class 1253 'Signaling session failures' (0x6) with response code 'Requested 1254 lifetime is too big' (0x02) upon rejection. The NSLP responder MAY 1255 also lower the requested lifetime to an acceptable value (based on 1256 its local policies). The NSLP responder generates a successful 1257 RESPONSE for the received request message, sets the lifetime value to 1258 the above granted lifetime and sends the message back hop-by-hop 1259 towards NSLP initiator. 1261 Each NSLP forwarder processes the RESPONSE message, reads and stores 1262 the granted lifetime value. The forwarders MUST accept the granted 1263 lifetime, as long as this value is less than or equal to their 1264 proposed value. For received values greater than the proposed value, 1265 NSLP forwarders MUST generate an RESPONSE message of class 'Signaling 1266 session failures' (0x6) with response code 'Requested lifetime is too 1267 big' (0x02). Figure 13 shows the procedure with an example, where an 1268 initiator requests 60 seconds lifetime in the CREATE message and the 1269 lifetime is shortened along the path by the forwarder to 20 seconds 1270 and by the responder to 15 seconds. 1272 +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ 1273 | |---------------->| NSLP |---------------->| | 1274 | NI | | forwarder | | NR | 1275 | |<----------------| check 15<20 |<----------------| | 1276 +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ 1278 lt = lifetime 1280 Figure 13: Lifetime Setting Example 1282 3.5 Message Sequencing 1284 NATFW NSLP messages need to carry an identifier so that all nodes 1285 along the path can distinguish messages sent at different points in 1286 time. Messages can be lost along the path or duplicated. So all 1287 NATFW NSLP nodes should be able to identify either old messages that 1288 have been received before (duplicated), or the case that messages 1289 have been lost before (loss). For message replay protection it is 1290 necessary to keep information about messages that have already been 1291 received and requires every NATFW NSLP message to carry a message 1292 sequence number (MSN), see also Section 4.2.6. 1294 The MSN MUST be set by the NI and MUST NOT be set or modified by any 1295 other node. The initial value for the MSN MUST be generated randomly 1296 and MUST be unique only within the session for which it is used. The 1297 NI MUST increment the MSN by one for every message sent. Once the 1298 MSN has reached the maximum value, the next value it takes is zero. 1299 All NATFW NSLP nodes MUST use the algorithm defined in [3] to detect 1300 MSN wrap-arounds. 1302 NSIS forwarders and the responder store the MSN from the initial 1303 CREATE or REA packet which creates the session as the start value for 1304 the session. NFs and NRs MUST include the received MSN value in the 1305 corresponding RESPONSE message that they generate. 1307 When receiving a request message, a NATFW NSLP node uses the MSN 1308 given in the message to determine whether the state being requested 1309 is different to the state already installed. The message MUST be 1310 discarded if the received MSN value is equal to or lower than the 1311 stored MSN value. Such a received MSN value can indicate a 1312 duplicated and delayed message or replayed message. If the received 1313 MSN value is greater than the already stored MSN value, the NATFW 1314 NSLP MUST update its stored state accordingly, if permitted by all 1315 security checks (see Section 3.6 and Section 3.7), and stores the 1316 updated MSN value accordingly. 1318 3.6 Session Ownership 1320 Proof of session ownership is a fundamental part of the NATFW NSLP 1321 signaling protocol. It is used to validate the origin of a request, 1322 i.e., invariance of the message sender. Only request messages 1323 demonstrating a valid session ownership are processed further. 1324 Within the NATFW NSLP, the NSIS initiator is the ultimate session 1325 owner for all request messages. A proof of ownership MUST be 1326 provided for any request message sent downstream or upstream. All 1327 intermediate NATFW NSLP nodes MUST use this proof of ownership to 1328 validate the message's origin. 1330 All NATFW nodes along the path must be able to verify that the sender 1331 of a request is the same entity that initially created the session. 1332 Generally, the path taken spans different administrative domains and 1333 cannot rely on using a common authentication scheme. This 1334 requirement demands a scheme independent of the local authentication 1335 scheme in use and administrative requirements being enforced. 1336 Relying on a public key infrastructure (PKI) for the purpose of prove 1337 of session ownership is not reasonable due to deployment problems of 1338 a global PKI. 1340 The NATFW NSLP relies on the session ID (SID) carried in the NTLP for 1341 proof of session ownership. The session ID MUST be generated in a 1342 random way. Messages for a particular session are handled by the 1343 NTLP to the NATFW NSLP for further processing. Messages carrying a 1344 different session ID not associated with any NATFW NSLP are subject 1345 to the regular processing for new NATFW NSLP sessions. 1347 3.7 Authentication, Authorization, and Policy Decisions 1349 NATFW NSLP nodes receiving signaling messages MUST first check 1350 whether this message is authenticated and authorized to perform the 1351 requested action. The necessary information for these checks can be 1352 carried in the NATFW_CREDENTIAL object. NATFW NSLP nodes requiring 1353 more information than provided MUST generate an error RESPONSE of 1354 class 'Permanent failure' (0x5) with response code 'Authentication 1355 failed' (0x01) or with response code 'Authorization failed' (0x02). 1357 The NATFW NSLP is expected to run in various environments, such as 1358 IP-based telephone systems, enterprise networks, home networks, etc. 1359 The requirements on authentication and authorization are quite 1360 different between these use cases. While a home gateway, or an 1361 Internet cafe, using NSIS may well be happy with a "NATFW signaling 1362 coming from inside the network" policy for authorization of 1363 signaling, enterprise networks are likely to require more strongly 1364 authenticated/authorized signaling. This enterprise scenario may 1365 require the use of an infrastructure and administratively assigned 1366 identities to operate the NATFW NSLP. 1368 Once the NI is authenticated and authorized, another step is 1369 performed. The requested policy rule for the session is checked 1370 against a set of policy rules, i.e., whether the requesting NI is 1371 allowed to request the policy rule to be loaded in the device. If 1372 this fails the NF or NR must send an error RESPONSE of class 1373 'Permanent failure' (0x5) and with response code 'Authorization 1374 failed' (0x02). 1376 3.8 Protocol Operations 1378 This section defines the protocol operations including, how to create 1379 sessions, maintain them, and how to reserve addresses. All the NATFW 1380 NSLP protocol messages MUST be transported via C-mode handling by the 1381 NTLP and MUST NOT be piggybacked into D-mode NTLP messages used 1382 during the NTLP path discovery/refresh phase. The usage of the NTLP 1383 by protocol messages is described in detail in Section 4. 1385 3.8.1 Creating Sessions 1387 Allowing two hosts to exchange data even in the presence of 1388 middleboxes is realized in the NATFW NSLP by use of the CREATE 1389 request message. The NI (either the data sender or a proxy) 1390 generates a CREATE message as defined in Section 4.3.1 and hands it 1391 to the NTLP. The NTLP forwards the whole message on the basis of the 1392 message routing information towards the NR. Each NSIS forwarder 1393 along the path that implements NATFW NSLP, processes the NSLP 1394 message. Forwarding is thus managed NSLP hop-by-hop but may pass 1395 transparently through NSIS forwarders which do not contain NATFW NSLP 1396 functionality and non-NSIS aware routers between NSLP hop way points. 1397 When the message reaches the NR, the NR can accept the request or 1398 reject it. The NR generates a response to the request and this 1399 response is transported hop-by-hop towards the NI. NATFW NSLP 1400 forwarders may reject requests at any time. Figure 14 sketches the 1401 message flow between NI (DS in this example), a NF (e.g., NAT), and 1402 NR (DR in this example). 1404 NI Private Network NF Public Internet NR 1405 | | | 1406 | CREATE | | 1407 |----------------------------->| | 1408 | | | 1409 | | | 1410 | | CREATE | 1411 | |--------------------------->| 1412 | | | 1413 | | RESPONSE | 1414 | RESPONSE |<---------------------------| 1415 |<-----------------------------| | 1416 | | | 1417 | | | 1419 Figure 14: CREATE message flow with success RESPONSE 1421 There are several processing rules for a NATFW peer when generating 1422 and receiving CREATE messages, since this message type is used for 1423 creating new signaling sessions, updating existing, extending the 1424 lifetime and deleting signaling session. The three latter functions 1425 operate in the same way for all kinds of request message, and are 1426 therefore described in separate sections: 1428 o Extending the lifetime of signaling sessions is described in 1429 Section 3.8.3. 1431 o Deleting signaling sessions is described in Section 3.8.4. 1433 o Updating policy rules is described in Section 3.11. 1435 For an initial CREATE message creating a new NATFW NSLP session, the 1436 processing of CREATE messages is different for every NATFW node type: 1438 o NSLP initiator: An NI only generates CREATE messages and hands 1439 them over to the NTLP. The NI should never receive request 1440 messages and MUST discard it. 1442 o NATFW NSLP forwarder: NFs that are unable to forward the request 1443 message to the next hop MUST generate an error RESPONSE of class 1444 'Permanent failure' (0x6) with response code 'Did not reach the 1445 NR' (0x06). This case may occur if the NTLP layer cannot find an 1446 NATFW NSLP peer, either another NF or the NR, and returns an error 1447 via the GIST API. The NSLP message processing at the NFs depends 1448 on the middlebox type: 1450 * NAT: When the initial CREATE message is received at the public 1451 side of the NAT, it looks for a reservation made in advance, by 1452 using a REA message (see Section 3.8.2). The matching process 1453 considers the received MRI information and the stored MRI 1454 information, as described in Section 3.9. If no matching 1455 reservation can be found, i.e. no reservation has been made in 1456 advance, the NSLP MUST return an error RESPONSE of class 1457 'Signaling session failure' (0x6) with response code 'No 1458 reservation found matching the MRI of the CREATE request' 1459 (0x03) MUST be generated. If there is a matching reservation, 1460 the NSLP stores the data sender's address (and if applicable 1461 port number) as part of the source address of the policy rule 1462 ('the remembered policy rule') to be loaded and forwards the 1463 message with the destination address set to the internal 1464 (private in most cases) address of NR. When the initial CREATE 1465 message is received at the private side, the NAT binding is 1466 allocated, but not activated (see also Appendix C.3). The MRI 1467 information is updated to reflect the address, and if 1468 applicable port, translation. The NSLP message is forwarded 1469 towards the NR with source address set to the NAT's external 1470 address from the newly remembered binding. 1472 * Firewall: When the initial CREATE message is received, the NSLP 1473 just remembers the requested policy rule, but does not install 1474 any policy rule. Afterwards, the message is forwarded towards 1475 the NR. 1477 * Combined NAT and firewall: Processing at combined firewall and 1478 NAT middleboxes is the same as in the NAT case. No policy 1479 rules are installed. Implementations MUST take into account 1480 the order of packet processing in the firewall and NAT 1481 functions within the device. This will be referred to as 1482 'order of functions' and is generally different depending on 1483 whether the packet arrives at the external or internal side of 1484 the middlebox. 1486 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1487 with a success RESPONSE of class 'Success' (0x2) with response 1488 code set to 'All successfully processed' (0x01), if they accept 1489 the CREATE request message. Otherwise they MUST generate a 1490 RESPONSE message with a suitable response code. RESPONSE messages 1491 are sent back NSLP hop-by-hop towards the NI, irrespective of the 1492 response codes, either success or error. 1494 Remembered policy rules at middleboxes MUST be only installed upon 1495 receiving a corresponding successful RESPONSE message with the same 1496 SID and MSN as the CREATE message that caused them to be remembered. 1497 This is a countermeasure to several problems, for example, wastage of 1498 resources due to loading policy rules at intermediate NFs when the 1499 CREATE message does not reach the final NR for some reason. 1501 Processing of a RESPONSE message is different for every NSIS node 1502 type: 1504 o NSLP initiator: After receiving a successful RESPONSE, the data 1505 path is configured and the DS can start sending its data to the 1506 DR. After receiving an error RESPONSE message, the NI MAY try to 1507 generate the CREATE message again or give up and report the 1508 failure to the application, depending on the error condition. 1510 o NSLP forwarder: NFs install the remembered policy rules, if a 1511 successful RESPONSE message with matching SID and MSN is received. 1512 If an ERROR RESPONSE message with matching SID and MSN is 1513 received, the session is marked as dead, no policy rule is 1514 installed and the remembered rule is discarded. 1516 o NSIS responder: The NR should never receive RESPONSE messages and 1517 MUST silently drop any such messages received. 1519 3.8.2 Reserving External Addresses 1521 NSIS signaling is intended to travel end-to-end, even in the presence 1522 of NATs and firewalls on-path. This works well in cases where the 1523 data sender is itself behind a NAT or a firewall as described in 1524 Section 3.8.1. For scenarios where the data receiver is located 1525 behind a NAT or a firewall and it needs to receive data flows from 1526 outside its own network (usually referred to as inbound flows, see 1527 Figure 5) the problem is more troublesome. 1529 NSIS signaling, as well as subsequent data flows, are directed to a 1530 particular destination IP address that must be known in advance and 1531 reachable. Data receivers must tell the local NSIS infrastructure 1532 (i.e., the upstream firewalls/NATs) about incoming NATFW NSLP 1533 signaling and data flows before they can receive these flows. It is 1534 necessary to differentiate between data receivers behind NATs and 1535 behind firewalls for understanding the further NATFW procedures. 1536 Data receivers that are only behind firewalls already have a public 1537 IP address and they need only to be reachable for NATFW signaling. 1538 Unlike data receivers behind just firewalls, data receivers behind 1539 NATs do not have public IP addresses; consequently they are not 1540 reachable for NATFW signaling by entities outside their addressing 1541 realm. 1543 The preceding discussion addresses the situation where a DR node that 1544 wants to be reachable is unreachable because the NAT lacks a suitable 1545 rule with the 'allow' action which would forward inbound data. 1546 However, in certain scenarios, a node situated behind upstream 1547 firewalls that do not block inbound data traffic (firewalls with 1548 "default to allow") unless requested might wish to prevent traffic 1549 being sent to it from specified addresses. In this case, NSIS NATFW 1550 signaling can be used to achieve this by installing a policy rule 1551 with its action set to 'deny' using the same mechanisms as for 1552 'allow' rules. 1554 The required result is obtained by sending a RESERVE-EXTERNAL-ADDRESS 1555 (REA) message in the upstream direction of the intended data flow. 1556 When using this functionality the NSIS initiator for the 'Reserve 1557 External Address' signaling is typically the node that will become 1558 the DR for the eventual data flow. To distinguish this initiator 1559 from the usual case where the NI is associated with the DS, the NI is 1560 denoted by NI+ and the NSIS responder is similarly denoted by NR+. 1562 Public Internet Private Address 1563 Space 1564 Edge 1565 NI(DS) NAT/FW NAT NR(DR) 1566 NR+ NI+ 1567 | | | | 1568 | | | | 1569 | | | | 1570 | | REA[(DTInfo)] | REA[(DTInfo)] | 1571 | |<----------------------|<----------------------| 1572 | | | | 1573 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1574 | |---------------------->|---------------------->| 1575 | | | | 1576 | | | | 1578 ============================================================> 1579 Data Traffic Direction 1581 Figure 15: Reservation message flow for DR behind NAT or firewall 1583 Figure 15 shows the REA message flow for enabling inbound NATFW NSLP 1584 signaling messages. In this case the roles of the different NSIS 1585 entities are: 1587 o The data receiver (DR) for the anticipated data traffic is the 1588 NSIS initiator (NI+) for the RESERVE-EXTERNAL-ADDRESS (REA) 1589 message, but becomes the NSIS responder (NR) for following CREATE 1590 messages. 1592 o The actual data sender (DS) will be the NSIS initiator (NI) for 1593 later CREATE messages and may be the NSIS target of the signaling 1594 (NR+). 1596 o It may be necessary to use a signaling destination address (SDA) 1597 as the actual target of the REA message (NR+) if the DR is located 1598 behind a NAT and the address of the DS is unknown. The SDA is an 1599 arbitrary address in the outermost address realm on the other side 1600 of the NAT from the DR. Typically this will be a suitable public 1601 IP address when the 'outside' realm is the public Internet. This 1602 choice of address causes the REA message to be routed through the 1603 NATs towards the outermost realm and would force interception of 1604 the message by the outermost NAT in the network at the boundary 1605 between the private address and the public address realm (the 1606 edge-NAT). It may also be intercepted by other NATs and firewalls 1607 on the path to the edge-NAT. 1609 Basically, there are two different signaling scenarios. Either 1611 1. the DR behind the NAT/firewall knows the IP address of the DS in 1612 advance, 1614 2. or the address of DS is not known in advance. 1616 Case 1 requires the NATFW NSLP to request the path-coupled message 1617 routing method (PC-MRM) from the NTLP. The REA message MUST be sent 1618 with PC-MRM (see Section 5.8.1 in [1]) with the direction set to 1619 'upstream'. The handling of case 2 depends on the situation of DR: 1620 If DR is solely located behind a firewall, the REA message MUST be 1621 sent with the PC-MRM, direction 'upstream', and data flow source IP 1622 address set to wildcard. If DR is located behind a NAT, the REA 1623 message MUST be sent with the loose-end message routing method (LE- 1624 MRM, see Section 5.8.2 in [1]), the destination-address set to the 1625 signaling destination address (SDA, see also Appendix A). For 1626 scenarios with DR being behind a firewall, special conditions apply 1627 (applicability statement, Appendix B). The data receiver is 1628 challenged to determine whether it is solely located behind firewalls 1629 or NATs, for choosing the right message routing method. This 1630 decision can depend on a local configuration parameter, possibly 1631 given through DHCP, or it could be discovered through other non-NSLP 1632 related testing of the network configuration. 1634 For case 2 with NAT, the NI+ (which could be on the data receiver DR 1635 or on any other host within the private network) sends the REA 1636 message targeted to the signaling destination address. The message 1637 routing for the REA message is in the reverse direction to the normal 1638 message routing used for path-coupled signaling where the signaling 1639 is sent downstream (as opposed to upstream in this case). When 1640 establishing NAT bindings (and an NSIS session) the signaling 1641 direction does not matter since the data path is modified through 1642 route pinning due to the external IP address at the NAT. Subsequent 1643 NSIS messages (and also data traffic) will travel through the same 1644 NAT boxes. However, this is only valid for the NAT boxes, but not 1645 for any intermediate firewall. That is the reason for having a 1646 separate CREATE message enabling the reservations made with REA at 1647 the NATs and either enabling prior reservations or creating new 1648 pinholes at the firewalls which are encountered on the downstream 1649 path depending on whether the upstream and downstream routes 1650 coincide. 1652 The REA signaling message creates an NSIS NATFW session at any 1653 intermediate NSIS NATFW peer(s) encountered, independent of the 1654 message routing method used. Furthermore, it has to be ensured that 1655 the edge-NAT or edge-firewall device is discovered as part of this 1656 process. The end host cannot be assumed to know this device - 1657 instead the NAT or firewall box itself is assumed to know that it is 1658 located at the outer perimeter of the network. Forwarding of the REA 1659 message beyond this entity is not necessary, and MUST be prohibited 1660 as it may provide information on the capabilities of internal hosts. 1661 It should be noted, that it is the outermost NAT or firewall that is 1662 the edge-device that must be found during this discovery process. 1663 For instance, when there are a NAT and afterwards a firewall on the 1664 outbound path at the network border, the firewall is the edge- 1665 firewall. All messages must be forwarded to the topology-wise 1666 outermost edge-device, to ensure that this devices knows about the 1667 signaling sessions for incoming CREATE messages. However, the NAT is 1668 still the edge-NAT because it has a public globally routable IP 1669 address on its public side: this is not affected by any firewall 1670 between the edge-NAT and the public network. 1672 Possible edge arrangements are: 1674 Public Net ----------------- Private net ------------------- 1676 | Public Net|--|Edge-FW|--|FW|...|FW|--|DR| 1678 | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR| 1680 | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR| 1682 The edge-NAT or edge-firewall device closest to the public realm 1683 responds to the REA message with a successful RESPONSE message. An 1684 edge-NAT includes an NATFW_EXT_IP object (see Section 4.2.2), 1685 carrying the public reachable IP address, and if applicable port 1686 number. 1688 There are several processing rules for a NATFW peer when generating 1689 and receiving REA messages, since this message type is used for 1690 creating new reserve signaling sessions, updating existing, extending 1691 the lifetime and deleting signaling session. The three latter 1692 functions operate in the same way for all kinds of request message, 1693 and are therefore described in separate sections: 1695 o Extending the lifetime of signaling sessions is described in 1696 Section 3.8.3. 1698 o Deleting signaling sessions is described in Section 3.8.4. 1700 o Updating policy rules is described in Section 3.11. 1702 The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message 1703 when using the LE-MRM. The LE-MRM does not include enough 1704 information for some types of NATs (basically, those NATs which also 1705 translate port numbers) to perform the address translation. This 1706 information is provided in the NATFW_DTINFO_IPv4 (see Section 4.2.7). 1707 This information SHOULD include at least the 'dst port number' and 1708 'protocol' fields, in the DTInfo object as these may be required by 1709 en-route NATs, depending on the type of the NAT. All other fields 1710 MAY be set by the NI+ to restrict the set of possible NIs. An edge- 1711 NAT will use the information provided in the NATFW_DTINFO_IPv4 object 1712 to allow only NATFW CREATE message with the MRI matching ('src 1713 IPv4/v6 address', 'src port number', 'protocol') to be forwarded. A 1714 NAT requiring information carried in the NATFW_DTINFO_IPv4 can 1715 generate a number of error RESPONSE messages of class 'Signaling 1716 session failures' (0x6): 1718 o 'Requested policy rule denied due to policy conflict' (0x04) 1720 o 'DTINFO object is required' (0x07) 1722 o 'Requested value in sub_ports field in NATFW_EFI not permitted' 1723 (0x08) 1725 o 'Requested IP protocol not supported' (0x09) 1727 o 'Plain IP policy rules not permitted -- need transport layer 1728 information' (0x0A) 1730 o 'source IP address range is too large' (0x0C) 1732 o 'destination IP address range is too large' (0x0D) 1734 o 'source L4-port range is too large' (0x0E) 1736 o 'destination L4-port range is too large' (0x0F) 1738 Processing of REA messages is specific to the NSIS node type: 1740 o NSLP initiator: NI+ only generate REA messages. When the data 1741 sender's address information is known in advance the NI+ MAY 1742 include a NATFW_DTINFO_IPv4 object in the REA message (as 1743 described above). When the data sender's IP address is not known, 1744 the NI+ MUST NOT include a NATFW_DTINFO_IPv4 object. The NI 1745 should never receive request messages and MUST silently discard 1746 it. 1748 o NSLP forwarder: The NSLP message processing at NFs depends on the 1749 middlebox type: 1751 * NAT: NATs check whether the message is received at the 1752 external (public in most cases) address or at the internal 1753 (private) address. If received at the external address a NF 1754 MUST generate an error RESPONSE of class 'Protocol error' (0x3) 1755 with response code 'Received REA request message on external 1756 side' (0x0B) MUST be generated. If received at the internal 1757 (private address) and the NATFW_EFI object contains the action 1758 'deny', an error RESPONSE of class 'Protocol error' (0x3) with 1759 response code 'Requested rule action not applicable' (0x06) 1760 MUST be generated. If received at the internal address, an IP 1761 address, and if applicable a port, is reserved. If it is an 1762 edge-NAT and there is no edge-firewall beyond, the NSLP message 1763 is not forwarded any further and a successful RESPONSE message 1764 is generated containing an NATFW_EXT_IP object holding the 1765 translated address, and if applicable port, information in the 1766 binding reserved as a result of the REA message. The RESPONSE 1767 message is sent back towards the NI+. If it is not an edge- 1768 NAT, the NSLP message is forwarded further using the translated 1769 IP address as signaling source address and including the 1770 translated IP address/port in the MRI. The edge-NAT or any 1771 other NAT MAY reject REA messages not carrying a 1772 NATFW_DTINFO_IPv4 object or if the address information within 1773 this object is invalid or is not compliant with local policies 1774 (e.g., the information provided relates to a range of addresses 1775 ('wildcarded') but the edge-NAT requires exact information 1776 about DS' IP address and port) with the above mentioned 1777 response codes. 1779 * Firewall: Non edge-firewalls remember the requested policy 1780 rule, keep session state, and forward the message. Edge- 1781 firewalls stop forwarding the request message. The policy rule 1782 is immediately loaded if the action in the NATFW_EFI object is 1783 set to 'deny' and the node is an edge-firewall. The policy 1784 rule is remembered, but not activated, if the action in the 1785 NATFW_EFI object is set to 'allow'. In both cases, a 1786 successful RESPONSE message is generated. 1788 * Combined NAT and firewall: Processing at combined firewall and 1789 NAT middleboxes is the same as in the NAT case. 1791 o NSLP receiver: This type of message should never be received by 1792 any NR+ and it MUST generate an error RESPONSE message of class 1793 'Permanent failure' (0x5) with response code 'No edge-device here' 1794 (0x05). 1796 Processing of a RESPONSE message is different for every NSIS node 1797 type: 1799 o NSLP initiator: Upon receiving a successful RESPONSE message, the 1800 NI+ can rely on the requested configuration for future inbound 1801 sessions. If the response contains an NATFW_EXT_IP object, the NI 1802 can use IP address and port pairs carried for further application 1803 signaling. After receiving a error RESPONSE message, the NI+ MAY 1804 try to generate the REA message again or give up and report the 1805 failure to the application, depending on the error condition. 1807 o NSLP forwarder: NFs simply forward this message as long as they 1808 keep state for the requested reservation, if the RESPONSE message 1809 contains NATFW_INFO object with class set to 'Success' (0x2). If 1810 the RESPONSE message contains NATFW_INFO object with class set not 1811 to 'Success' (0x2), the session is marked as dead. 1813 o NSIS responder: This type of message should never be received by 1814 any NR+. The NF should never receive response messages and MUST 1815 silently discard it. 1817 Reservations with action 'allow' made with REA MUST be enabled by a 1818 subsequent CREATE message. A reservation made with REA (independent 1819 of selected action) is kept alive as long as the NI+ refreshes the 1820 particular signaling session and it can be reused for multiple, 1821 different CREATE messages. An NI+ may decide to teardown a 1822 reservation immediately after receiving a CREATE message. Without 1823 using CREATE Section 3.8.1 or REA in proxy mode Section 3.8.7 no data 1824 traffic will be forwarded to DR beyond the edge-NAT or edge-firewall. 1825 The only function of REA is to ensure that subsequent CREATE messages 1826 traveling towards the NR will be forwarded across the public-private 1827 boundary towards the DR. Correlation of incoming CREATE messages to 1828 REA reservation states is described in Section 3.9. 1830 3.8.3 NATFW Session Refresh 1832 NATFW NSLP sessions are maintained on a soft-state basis. After a 1833 specified timeout, sessions and corresponding policy rules are 1834 removed automatically by the middlebox, if they are not refreshed. 1835 Soft-state is created by CREATE and REA and the maintenance of this 1836 state must be done by these messages. State created by CREATE must 1837 be maintained by CREATE, state created by REA must be maintained by 1838 REA. Refresh messages, are messages carrying the same session ID as 1839 the initial message and a NATFW_LT lifetime object with a lifetime 1840 greater than zero. Messages with the same SID but carrying a 1841 different MRI are treated as updates of the policy rules and are 1842 processed as defined in Section 3.11. Every refresh request message 1843 MUST be acknowledged by an appropriate response message generated by 1844 the NR. Upon reception by each NSIS forwarder, the state for the 1845 given session ID is extended by the session refresh period, a period 1846 of time calculated based on a proposed refresh message period. The 1847 lifetime extension of a session is calculated as current local time 1848 plus proposed lifetime value (session refresh period). Section 3.4 1849 defines the process of calculating lifetimes in detail. 1851 NI Public Internet NAT Private address NR 1852 | | space | 1853 | CREATE[lifetime > 0] | | 1854 |----------------------------->| | 1855 | | | 1856 | | | 1857 | | CREATE[lifetime > 0] | 1858 | |--------------------------->| 1859 | | | 1860 | | RESPONSE[Success/Error] | 1861 | RESPONSE[Success/Error] |<---------------------------| 1862 |<-----------------------------| | 1863 | | | 1864 | | | 1866 Figure 16: Successful Refresh Message Flow, CREATE as example 1868 Processing of session refresh CREATE and REA messages is different 1869 for every NSIS node type: 1871 o NSLP initiator: The NI/NI+ can generate session refresh CREATE/REA 1872 messages before the session times out. The rate at which the 1873 refresh CREATE/REA messages are sent and their relation to the 1874 session state lifetime is discussed further in Section 3.4. 1876 o NSLP forwarder: Processing of this message is independent of the 1877 middlebox type and is as described in Section 3.4. 1879 o NSLP responder: NRs accepting a session refresh CREATE/REA message 1880 generate a successful RESPONSE message, including the granted 1881 lifetime value of Section 3.4 in a NATFW_LT object. 1883 3.8.4 Deleting Sessions 1885 NATFW NSLP sessions can be deleted at any time. NSLP initiators can 1886 trigger this deletion by using a CREATE or REA messages with a 1887 lifetime value set to 0, as shown in Figure 17. Whether a CREATE or 1888 REA message type is used, depends on how the session was created. 1890 NI Public Internet NAT Private address NR 1891 | | space | 1892 | CREATE[lifetime=0] | | 1893 |----------------------------->| | 1894 | | | 1895 | | CREATE[lifetime=0] | 1896 | |--------------------------->| 1897 | | | 1899 Figure 17: Delete message flow, CREATE as example 1901 NSLP nodes receiving this message delete the session immediately. 1902 Policy rules associated with this particular session MUST be also 1903 deleted immediately. This message is forwarded until it reaches the 1904 final NR. The CREATE/REA request message with a lifetime value of 0, 1905 does not generate any response, neither positive nor negative, since 1906 there is no NSIS state left at the nodes along the path. 1908 NSIS initiators can use CREATE/REA message with lifetime set to zero 1909 in an aggregated way, such that a single request message is 1910 terminating multiple signaling sessions. NIs can follow this 1911 procedure if the like to aggregate session deletion requests: The NI 1912 uses the CREATE or REA request message with the session ID set to 1913 zero and the MRI's source-address set to its used IP address. All 1914 other fields of the respective sessions to be terminated are set as 1915 well, otherwise these fields are completely wildcarded. The NSLP 1916 message is transfered to the NTLP requesting 'explicit routing' as 1917 described in Sections 5.2.1 and 7.1.4. in [1]. 1919 The downstream NF receiving such an aggregated request message MUST 1920 reject the request with an error RESPONSE of class 'Permanent 1921 failure' (0x5) with response code 'Authentication failed' (0x01) if 1922 the authentication fails and with an error RESPONSE of class 1923 'Permanent failure' (0x5) with response code 'Authorization failed' 1924 (0x02) if the authorization fails. Per session proof of ownership, 1925 as it is defined in this memo, is not possible anymore when using 1926 this aggregated mode. However, the downstream NF can use the 1927 relationship between the information of the received request message 1928 and the GIST messaging association where the request has been 1929 received. The downstream NF MUST only accept this aggregated request 1930 message through already established GIST messaging associations with 1931 the NI. The downstream NF MUST NOT propagate this aggregated request 1932 message but it MAY generate and forward per session request messages. 1934 3.8.5 Reporting Asynchronous Events 1936 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 1937 to report asynchronous events to other NATFW NSLP nodes, especially 1938 to allow reporting back to the NATFW NSLP initiator. Such 1939 asynchronous events may be premature session termination, changes in 1940 local policies, route change or any other reason that indicates 1941 change of the NATFW NSLP session state. Currently, asynchronous 1942 session termination, re-authorization required and route change 1943 detected (see Section 3.10) are the only events that are defined, but 1944 other events may be defined in later revisions of this memo. 1946 NFs and NRs may generate NOTIFY messages upon asynchronous events, 1947 with a NATFW_INFO object indicating the reason for event. These 1948 reasons can be carried in the NATFW_INFO object (class MUST be set to 1949 'Informational' (0x1)) within the NOTIFY message. This list shows 1950 the response codes and the associated actions to take at NFs and the 1951 NI: 1953 o 'Route change: possible route change on the downstream path' 1954 (0x01): Follow instructions in Section 3.10. 1956 o 'Re-authentication required' (0x02): The NI should re-send the 1957 authentication. 1959 o 'NATFW node is going down soon' (0x03): The NI and other NFs 1960 should be prepared for a service interruption at any time. 1962 NOTIFY messages are sent hop-by-hop upstream towards NI until they 1963 reach NI. 1965 The initial processing when receiving a NOTIFY message is the same 1966 for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages 1967 through already established NTLP messaging associations. The further 1968 processing is different for each NATFW NSLP node type and depends on 1969 the events notified: 1971 o NSLP initiator: NIs analyze the notified event and behave 1972 appropriately based on the event type. NIs MUST NOT generate 1973 NOTIFY messages. 1975 o NSLP forwarder: NFs analyze the notified event and behave based 1976 on the above description per response code. NFs SHOULD generate 1977 NOTIFY messages upon asynchronous events and forward them upstream 1978 towards the NI. 1980 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 1981 asynchronous events including a response code based on the 1982 reported event. The NF should never receive NOTIFY messages and 1983 MUST silently discard it. 1985 NATFW NSLP forwarders, keeping multiple signaling sessions at the 1986 same time, can experience problems when shutting down service 1987 suddenly. This sudden shutdown can be result of node local failure, 1988 for instance, due to a hardware failure. This NF generates NOTIFY 1989 messages for each of the signaling sessions and tries to send them 1990 upstream. Due to the number of NOTIFY messages to be sent, the 1991 shutdown of the node may be unnecessarily prolonged, since not all 1992 messages can be sent at the same time. This case can be described as 1993 a NOTIFY storm, if a multitude of signaling sessions is involved. 1995 To avoid the need of generating per signaling session NOTIFY messages 1996 in such a scenario described or similar cases, NFs SHOULD follow this 1997 procedure: The NF uses the NOTIFY message with the session ID in the 1998 NTLP set to zero, with the MRI completely wildcarded, using the 1999 'explicit routing' as described in Sections 5.2.1 and 7.1.4. in [1]. 2000 The upstream NF receiving this type of NOTIFY immediately regards all 2001 signaling sessions from that peer matching the MRI as void. This 2002 message will typically result in multiple NOTIFY messages at the 2003 upstream NF, i.e., the NF can generate per terminated session a 2004 NOTIFY message. However, a NF MAY aggregate again the NOTIFY 2005 messages as described here. 2007 3.8.6 Tracing Signaling Sessions 2009 The NATFW NSLP provides a diagnosis capability to session owners (the 2010 NI or NI+). Session owners are able to trace the NSIS nodes being 2011 involved in a particular signaling session. The TRACE request 2012 message is used to trace the involved NSIS nodes along the signaling 2013 session and to return their identifiers. 2015 NI Public Internet NAT Private address NR 2016 | | space | 2017 | TRACE | | 2018 |----------------------------->| | 2019 | | | 2020 | | TRACE | 2021 | |--------------------------->| 2022 | | | 2023 | | RESPONSE[IP(NR)] | 2024 | |<---------------------------| 2025 | RESPONSE[IP(NR),IP(NAT)] | | 2026 |<-----------------------------| | 2027 | | | 2028 | | | 2029 Figure 18: Example for tracing the signaling session path 2031 The processing when receiving a TRACE message is the different for 2032 each type of NATFW node: 2034 o NSLP initiator: NI generates TRACE request messages. The NI 2035 should never receive request messages and MUST silently discard 2036 it. 2038 o NSLP forwarder: NFs solely forward the message if their local 2039 policies permits tracing. A NF MUST generate an error RESPONSE of 2040 class 'Permanent failure' (0x6) with response code 'Tracing is not 2041 allowed' (0x07) if the local policies do not allow tracing. 2043 o NSLP responder: NRs receiving a TRACE request message terminate 2044 the forwarding and reply with a successful RESPONSE message. The 2045 NATFW_TRACE object MAY be filled by the NR with its IP address. 2047 Processing of a RESPONSE message to a TRACE request message is 2048 different for every NSIS node type: 2050 o NSLP initiator: The NI terminates the forwarding and checks the 2051 response message for further local processing. 2053 o NSLP forwarder: NFs MAY include their identifier in the 2054 NATFW_TRACE object and increment the 'hop count' field by one. 2055 This memo defines IPv4 and IPv6 IP addresses as possible de 2056 identifier. NFs MUST forward this type of RESPONSE. 2058 o NSLP responder: A NR should never see such a RESPONSE message and 2059 it MUST silently discard it. 2061 3.8.7 Proxy Mode of Operation 2063 Some migration scenarios need specialized support to cope with cases 2064 where NSIS is only deployed in same areas of the Internet. End-to- 2065 end signaling is going to fail without NSIS support at or near both 2066 data sender and data receiver terminals. A proxy mode of operation 2067 is needed. This proxy mode of operation must terminate the NATFW 2068 NSLP signaling as topologically close to the terminal for which it is 2069 proxying and proxy all request and response messages. This NATFW 2070 NSLP node doing the proxying of the signaling messages becomes either 2071 the NI or the NR for the particular signaling session, depending on 2072 whether it is the DS or DR that does not support NSIS. Typically, 2073 the edge-NAT or the edge-firewall would be used to proxy NATFW NSLP 2074 messages. 2076 This proxy mode operation does not require any new request message 2077 type, but relies on extended CREATE and REA message types. They are 2078 called respectively CREATE-PROXY and REA-PROXY and are distinguished 2079 by setting the P flag in the NSLP header is set to P=1. This flag 2080 instructs edge-NATs and edge-firewalls receiving them to operate in 2081 proxy mode for the session in question. The semantics of the CREATE 2082 and REA message types are not changed and the behavior of the various 2083 node types is as defined in Section 3.8.1 and Section 3.8.2, except 2084 for the proxying node. The following paragraphs describe the proxy 2085 mode operation for data receivers behind middleboxes and data senders 2086 behind middleboxes. 2088 3.8.7.1 Proxying for a Data Sender 2090 The NATFW NSLP gives the NR the ability to install state on the 2091 upstream path towards the data sender for downstream data packets, 2092 even when only the receiving side is running NSIS (as shown in 2093 Figure 19). The goal of the method described is to trigger the edge- 2094 NAT/edge-firewall to generate a CREATE message on behalf of the data 2095 receiver. In this case, a NR can signal towards the network border 2096 as it is performed in the standard REA message handling scenario as 2097 in Section 3.8.2. The message is forwarded until the edge-NAT/ 2098 edge-firewall is reached. A public IP address and port number is 2099 reserved at an edge-NAT/edge-firewall. As shown in Figure 19, unlike 2100 the standard REA message handling case, the edge-NAT/edge-firewall is 2101 triggered to send a CREATE message on a new reverse path which 2102 traverse several firewalls or NATs. The new reverse path for CREATE 2103 is necessary to handle routing asymmetries between the edge-NAT/ 2104 edge-firewall and DR. It must be stressed that the semantics of the 2105 CREATE and REA request messages is not changed, i.e., each is 2106 processed as described earlier. 2108 DS Public Internet NAT/FW Private address NR 2109 No NI NF space NI+ 2110 NR+ 2111 | | REA-PROXY[(DTInfo)] | 2112 | |<------------------------- | 2113 | | RESPONSE[Error/Success] | 2114 | | ---------------------- > | 2115 | | CREATE | 2116 | | ------------------------> | 2117 | | RESPONSE[Error/Success] | 2118 | | <---------------------- | 2119 | | | 2121 Figure 19: 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 2135 NF 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.8.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.8.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 2191 | | | 2192 | CREATE-PROXY | | 2193 |------------------------------>| | 2194 | | | 2195 | RESPONSE[SUCCESS/ERROR] | | 2196 |<------------------------------| | 2197 | | | 2199 Figure 20: Proxy Mode CREATE Message Flow 2201 The processing of CREATE-PROXY messages and RESPONSE messages is 2202 similar to Section 3.8.1, except that forwarding is stopped at the 2203 edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to 2204 NI according the situation (error/success) and will be the NR for 2205 future NATFW NSLP communication. 2207 The NI can choose the proxy mode of operation although the DR is NSIS 2208 aware. The CREATE-PROXY mode would not configure all NATs and 2209 firewalls along the data path, since it is terminated at the edge- 2210 device. Any device beyond this point will never received any NATFW 2211 NSLP signaling for this flow. 2213 3.9 De-Multiplexing at NATs 2215 Section 3.8.2 describes how NSIS nodes behind NATs can obtain a 2216 public reachable IP address and port number at a NAT and and how the 2217 resulting mapping rule can be activated by using CREATE messages (see 2218 Section 3.8.1). The information about the public IP address/port 2219 number can be transmitted via an application level signaling protocol 2220 and/or third party to the communication partner that would like to 2221 send data toward the host behind the NAT. However, NSIS signaling 2222 flows are sent towards the address of the NAT at which this 2223 particular IP address and port number is allocated and not directly 2224 to the allocated IP address and port number. The NATFW NSLP 2225 forwarder at this NAT needs to know how the incoming NSLP requests 2226 are related to reserved addresses, meaning how to de-multiplex 2227 incoming NSIS requests. 2229 The de-multiplexing method uses information stored at the local NATFW 2230 NSLP node and the of the policy rule. The policy rule uses the LE- 2231 MRM MRI source-address (see [1]) as the flow destination IP address 2232 and the network-layer-version as IP version. The external IP address 2233 at the NAT is stored as the external flow destination IP address. 2234 All other parameters of the policy rule other than the flow 2235 destination IP address are wildcarded if no NATFW_DTINFO_IPv4 object 2236 is included in the REA request message. The LE-MRM MRI destination- 2237 address MUST NOT be used in the policy rule, since it is solely a 2238 signaling destination address. 2240 If the NATFW_DTINFO_IPv4 object is included in the REA request 2241 message, the policy rule is filled with further information. The 2242 'dst port number' field of the NATFW_DTINFO_IPv4 is stored as the 2243 flow destination port number. The 'protocol' field is stored as the 2244 flow protocol. The 'src port number' field is stored as the flow 2245 source port number. The 'data sender's IPv4 address' is stored as 2246 the flow source IP address. Note that some of these field can 2247 contain wildcards. 2249 When receiving a CREATE message at the NATFW NSLP it uses the flow 2250 information stored in the MRI to do the matching process. This table 2251 shows the parameters to be compared against each others. Note that 2252 not all parameters can be present in a MRI at the same time. 2254 +-------------------------------+--------------------------------+ 2255 | Flow parameter (Policy Rule) | MRI parameter (CREATE message) | 2256 +-------------------------------+--------------------------------+ 2257 | IP version | network-layer-version | 2258 | | | 2259 | Protocol | IP-protocol | 2260 | | | 2261 | source IP address (w) | source-address (w) | 2262 | | | 2263 | external IP address | destination-address | 2264 | | | 2265 | destination IP address (n/u) | N/A | 2266 | | | 2267 | source port number (w) | L4-source-port (w) | 2268 | | | 2269 | external port number (w) | L4-destination-port (w) | 2270 | | | 2271 | destination port number (n/u) | N/A | 2272 | | | 2273 | IPsec SPI | ipsec-SPI | 2274 +-------------------------------+--------------------------------+ 2276 Table entries marked with (w) can be wildcarded and entries marked 2277 with (n/u) are not used for the matching. 2279 Table 1 2281 3.10 Reacting to Route Changes 2283 The NATFW NSLP needs to react to route changes in the data path. 2284 This assumes the capability to detect route changes, to perform NAT 2285 and firewall configuration on the new path and possibly to tear down 2286 session state on the old path. The detection of route changes is 2287 described in Section 7 of [1] and the NATFW NSLP relies on 2288 notifications about route changes by the NTLP. This notification 2289 will be conveyed by the API between NTLP and NSLP, which is out of 2290 scope of this memo. 2292 A NATFW NSLP node other than the NI or NI+ detecting a route change, 2293 by means described in the NTLP specification or others, generates a 2294 NOTIFY message indicating this change and sends this upstream towards 2295 NI. Intermediate NFs on the way to the NI can use this information 2296 to decide later if their session can be deleted locally, if they do 2297 not receive an update within a certain time period, as described in 2298 Section 3.2.3. It is important to consider the transport limitations 2299 of NOTIFY messages as mandated in Section 3.8.5. 2301 The NI receiving this NOTIFY message MAY generate a new request 2302 CREATE or REA message and sends it respectively downstream or 2303 upstream as for the initial exchange using the same session ID. All 2304 the remaining processing and message forwarding, such as NSLP next 2305 hop discovery, is subject to regular NSLP processing as described in 2306 the particular sections. Normal routing will guide the new request 2307 to the correct NFs along the changed route. NFs that were on the 2308 original path receiving these new request messages (see also 2309 Section 3.11), can use the session ID (session ownership information, 2310 see also Section 3.6) to update the existing session, whereas NFs 2311 that were not on the original path will create new state for this 2312 session. The next section describes how policy rules are updated. 2314 3.11 Updating Policy Rules 2316 NSIS initiators can request an update of the installed/reserved 2317 policy rules at any time within a signaling session. Updates to 2318 policy rules can be required due to node mobility (NI is moving from 2319 one IP address to another), route changes (this can result in a 2320 different NAT mapping at a different NAT device), or the wish of the 2321 NI to simply change the rule. NIs can update policy rules in 2322 existing signaling sessions by sending an appropriate request message 2323 (similar to Section 3.4) with modified message routing information 2324 (MRI) as compared with that installed previously, but using the 2325 existing session ID to identify the intended target of the update. 2326 With respect to authorization and authentication, this update request 2327 message is treated in exactly the same way as any initial request. 2328 Therefore, any node along in the signaling session can reject the 2329 update with an error RESPONSE message, as defined in the previous 2330 sections. 2332 The request/response message processing and forwarding is executed as 2333 defined in the those sections. A NF or the NR receiving an update, 2334 simply replaces the installed policy rules installed in the firewall/ 2335 NAT. The local procedures on how to update the MRI in the firewall/ 2336 NAT is out of scope of this memo. 2338 4. NATFW NSLP Message Components 2340 A NATFW NSLP message consists of a NSLP header and one or more 2341 objects following the header. The NSLP header is common for all 2342 NSLPs and objects are Type-Length-Value (TLV) encoded using big 2343 endian (network ordered) binary data representations. Header and 2344 objects are aligned to 32 bit boundaries and object lengths that are 2345 not multiples of 32 bits must be padded to the next higher 32 bit 2346 multiple. 2348 The whole NSLP message is carried as payload of a NTLP message. 2350 Note that the notation 0x is used to indicate hexadecimal numbers. 2352 4.1 NSLP Header 2354 The NSLP header is common to all NSLPs and is the first part of all 2355 NSLP messages. It contains two fields, the NSLP message type and a 2356 reserved field. The total length is 32 bits. The layout of the NSLP 2357 header is defined by Figure 21. 2359 0 16 31 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 | Message type |P| reserved | reserved | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 Figure 21: Common NSLP header 2366 The reserved field MUST be set to zero in the NATFW NSLP header 2367 before sending and MUST be ignored during processing of the header. 2369 The message types identify requests and responses. Defined messages 2370 types are: 2372 o IANA-TBD(1) : CREATE 2374 o IANA-TBD(2) : RESERVE-EXTERNAL-ADDRESS(REA) 2376 o IANA-TBD(3) : TRACE 2378 o IANA-TBD(4) : RESPONSE 2380 o IANA-TBD(5) : NOTIFY 2381 If a message with another type is received, an error RESPONSE of 2382 class 'Protocol error' (0x3) with response code 'Illegal message 2383 type' (0x01) MUST be generated. 2385 The P flag indicates the usage of proxy mode. If proxy mode is used 2386 it MUST be set to 1. Proxy mode usage is only allowed in combination 2387 with the message types CREATE and REA, P=1 MUST NOT be set with 2388 message types other than CREATE and REA. The P flag MUST be ignored 2389 when processing messages with type RESPONSE. An error RESPONSE 2390 message of class 'Protocol error' (0x3) and type 'Bad flags value' 2391 (0x03) MUST be generated, if the P flag is set in TRACE or NOTIFY 2392 messages. 2394 4.2 NSLP Objects 2396 NATFW NSLP objects use a common header format defined by Figure 22. 2397 The object header contains two fields, the NSLP object type and the 2398 object length. Its total length is 32 bits. 2400 0 1 2 3 2401 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 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 Figure 22: Common NSLP object header 2408 The object length field contains the total length of the object 2409 without the object header. The unit is a word, consisting of 4 2410 octets. The particular values of type and length for each NSLP 2411 object are listed in the subsequent sections that define the NSLP 2412 objects. An error RESPONSE of class 'Protocol error' (0x3) with 2413 response code 'Wrong object length' (0x07) MUST be generated if the 2414 length given for the object in the object header did not match the 2415 length of the object data present. The two leading bits of the NSLP 2416 object header are used to signal the desired treatment for objects 2417 whose treatment has not been defined in this memo (see [1], Section 2418 A.2.1), i.e., the Object Type has not been defined. NATFW NSLP uses 2419 a subset of the categories defined in GIST: 2421 o AB=00 ("Mandatory"): If the object is not understood, the entire 2422 message containing it MUST be rejected with an error RESPONSE of 2423 class 'Protocol error' (0x3) with response code 'Unknown object 2424 present' (0x06). 2426 o AB=01 ("Optional"): If the object is not understood, it should be 2427 deleted and then the rest of the message processed as usual. 2429 o AB=10 ("Forward"): If the object is not understood, it should be 2430 retained unchanged in any message forwarded as a result of message 2431 processing, but not stored locally. 2433 The combination AB=11 MUST NOT be used and an error RESPONSE of class 2434 'Protocol error' (0x3) with response code 'Invalid Flag-Field 2435 combination' (0x09) MUST be generated. 2437 The following sections do not repeat the common NSLP object header, 2438 they just name the type and the length. 2440 4.2.1 Session Lifetime Object 2442 The session lifetime object carries the requested or granted lifetime 2443 of a NATFW NSLP session measured in seconds. 2445 Type: NATFW_LT (IANA-TBD) 2447 Length: 1 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 | NATFW NSLP session lifetime | 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 Figure 23: Lifetime object 2455 4.2.2 External Address Object 2457 The external address object can be included in RESPONSE messages 2458 (Section 4.3.3) only. It carries the publicly reachable IP address, 2459 and if applicable port number, at an edge-NAT. 2461 Type: NATFW_EXT_IP (IANA-TBD) 2463 Length: 2 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 | port number | reserved | 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 | IPv4 address | 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 Figure 24: External Address Object for IPv4 addresses 2473 Please note that the field 'port number' MUST be set to 0 if only an 2474 IP address has been reserved, for instance, by a traditional NAT. A 2475 port number of 0 MUST be ignored in processing this object. 2477 4.2.3 Extended Flow Information Object 2479 In general, flow information is kept in the message routing 2480 information (MRI) of the NTLP. Nevertheless, some additional 2481 information may be required for NSLP operations. The 'extended flow 2482 information' object carries this additional information about the 2483 action of the policy rule for firewalls/NATs and contiguous port . 2485 Type: NATFW_EFI (IANA-TBD) 2487 Length: 1 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 | rule action | sub_ports | 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 Figure 25: Extended Flow Information 2495 This object has two fields, 'rule action' and 'sub_ports'. The 'rule 2496 action' field has these meanings: 2498 o 0x0001: Allow: A policy rule with this action allows data traffic 2499 to traverse the middlebox and the NATFW NSLP MUST allow NSLP 2500 signaling to be forwarded. 2502 o 0x0002: Deny: A policy rule with this action blocks data traffic 2503 from traversing the middlebox and the NATFW NSLP MUST NOT allow 2504 NSLP signaling to be forwarded. 2506 If the 'rule action' field contains neither 0x0001 nor 0x0002, an 2507 error RESPONSE of class 'Signaling session error' (0x6) with response 2508 code 'Unknown policy rule action' (0x05) MUST be generated. 2510 The 'sub_ports' field contains the number of contiguous transport 2511 layer ports to which this rule applies. The default value of this 2512 field is 0, i.e., only the port specified in the NTLP's MRM is used 2513 for the policy rule. A value of 1 indicates that additionally to the 2514 port specified in the NTLP's MRM (port1), a second port (port2) is 2515 used. This value of port 2 is calculated as: port2 = port1 + 1. 2516 Other values than 0 or 1 MUST NOT be used in this field and an error 2517 RESPONSE of class 'Signaling session error' (0x6) with response code 2518 'Requested value in sub_ports field in NATFW_EFI not permitted' 2519 (0x08) MUST be generated. Further version of this memo may allow 2520 other values for the 'sub_ports' field. This two contiguous port 2521 numbered ports, can be used by legacy voice over IP equipment. This 2522 legacy equipment assumes that two adjacent port numbers for its RTP/ 2523 RTCP flows respectively. 2525 4.2.4 Information Code Object 2527 This object carries the response code, which may be indications for 2528 either a successful request or failed request depending on the value 2529 of the 'response code' field. 2531 Type: NATFW_INFO (IANA-TBD) 2533 Length: 1 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | Resv. | Class | Response Code | Object Type | 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 Figure 26: Information Code Object 2541 The field 'resv.' is reserved for future extensions and MUST be set 2542 to zero when generating such an object and MUST be ignored when 2543 receiving. The 'Object Type' field contains the type of the object 2544 causing the error. The value of 'Object Type' is set to 0, if no 2545 object is concerned. The 4 bit class field contains the severity 2546 class. The following classes are defined: 2548 o 0x1: Informational (NOTIFY only) 2549 o 0x2: Success 2551 o 0x3: Protocol error 2553 o 0x4: Transient failure 2555 o 0x5: Permanent failure 2557 o 0x6: Signaling session failures 2559 Within each severity class a number of responses values are defined 2561 o Informational: 2563 * 0x01: Route change: possible route change on the downstream 2564 path. 2566 * 0x02: Re-authentication required. 2568 * 0x03: NATFW node is going down soon. 2570 o Success: 2572 * 0x01: All successfully processed. 2574 o Protocol error: 2576 * 0x01: Illegal message type: the type given in the Message Type 2577 field of the NSLP header is unknown. 2579 * 0x02: Wrong message length: the length given for the message in 2580 the NSLP header does not match the length of the message data. 2582 * 0x03: Bad flags value: an undefined flag or combination of 2583 flags was set in the NSLP header. 2585 * 0x04: Mandatory object missing: an object required in a message 2586 of this type was missing. 2588 * 0x05: Illegal object present: an object was present which must 2589 not be used in a message of this type. 2591 * 0x06: Unknown object present: an object of an unknown type was 2592 present in the message. 2594 * 0x07: Wrong object length: the length given for the object in 2595 the object header did not match the length of the object data 2596 present. 2598 * 0x08: Unknown object field value: a field in an object had an 2599 unknown value. 2601 * 0x09: Invalid Flag-Field combination: An object contains an 2602 invalid combination of flags and/or fields. 2604 * 0x0A: Duplicate object present. 2606 * 0x0B: Received REA request message on external side. 2608 o Transient failure: 2610 * 0x01: Requested resources temporarily not available. 2612 o Permanent failure: 2614 * 0x01: Authentication failed. 2616 * 0x02: Authorization failed. 2618 * 0x02: Unable to agree transport security with peer. 2620 * 0x03: Internal or system error. 2622 * 0x04: No NAT here. 2624 * 0x05: No edge-device here. 2626 * 0x06: Did not reach the NR. 2628 * 0x07: Tracing is not allowed. 2630 o Signaling session failures: 2632 * 0x01: Session terminated asynchronously. 2634 * 0x02: Requested lifetime is too big. 2636 * 0x03: No reservation found matching the MRI of the CREATE 2637 request. 2639 * 0x04: Requested policy rule denied due to policy conflict. 2641 * 0x05: Unknown policy rule action. 2643 * 0x06: Requested rule action not applicable. 2645 * 0x07: DTINFO object is required. 2647 * 0x08: Requested value in sub_ports field in NATFW_EFI not 2648 permitted. 2650 * 0x09: Requested IP protocol not supported. 2652 * 0x0A: Plain IP policy rules not permitted -- need transport 2653 layer information. 2655 * 0x0B: ICMP type value not permitted. 2657 * 0x0C: source IP address range is too large. 2659 * 0x0D: destination IP address range is too large. 2661 * 0x0E: source L4-port range is too large. 2663 * 0x0F: destination L4-port range is too large. 2665 4.2.5 Nonce Object 2667 This object carries the nonce value as described in Section 3.8.7. 2669 Type: NATFW_NONCE (IANA-TBD) 2671 Length: 1 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | nonce | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 Figure 27: Nonce Object 2679 4.2.6 Message Sequence Number Object 2681 This object carries the MSN value as described in Section 3.5. 2683 Type: NATFW_MSN (IANA-TBD) 2685 Length: 1 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 | message sequence number | 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 Figure 28: Message Sequence Number Object 2693 4.2.7 Data Terminal Information Object 2695 The 'data terminal information' object carries additional information 2696 possibly needed during REA operations. REA messages are transported 2697 by the NTLP using the Loose-End message routing method (LE-MRM). The 2698 LE-MRM contains only DR's IP address and a signaling destination 2699 address (destination address). This destination address is used for 2700 message routing only and is not necessarily reflecting the address of 2701 the data sender. This object contains information about (if 2702 applicable) DR's port number (the destination port number), DS' port 2703 number (the source port number), the used transport protocol, the 2704 prefix length of the IP address, and DS' IP address. 2706 Type: NATFW_DTINFO_IPv4 (IANA-TBD) 2708 Length: 3 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 |I|P|S| reserved | dest prefix | protocol | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 : dst port number | src port number : 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 : IPsec SPI : 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 | data sender's IPv4 address | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 Figure 29: Data Terminal IPv4 Address Object 2722 The flags are: 2724 o I: I=1 means that Protocol should be interpreted. 2726 o I: P=1 means that 'dst port number' and 'src port number' are 2727 present and should be interpreted. 2729 o S: S=1 means that SPI is present and should be interpreted. 2731 The SPI field is only present if F is set. The port numbers are only 2732 present if P is set. The flags P and F MUST NOT be set at the same 2733 time. An error RESPONSE of class 'Protocol error' (0x3) with 2734 response code 'Invalid Flag-Field combination' (0x09) MUST be 2735 generated if they are both set. 2737 The fields MUST be interpreted according these rules: 2739 o dest prefix: This parameter indicates the prefix length of the 2740 'data sender's IP address' in bits. For instance, a full IPv4 2741 address requires 'dest prefix' to be set to 32. A value of 0 2742 indicates an IP address wildcard. 2744 o protocol: The IPv4 protocol field. This field MUST be interpreted 2745 if I=1, otherwise it MUST be set to 0 and MUST be ignored. 2747 o dst port number: A value of 0 indicates a port wildcard, i.e., the 2748 destination port number is not known. Any other value indicates 2749 the destination port number. 2751 o src port number: A value of 0 indicates a port wildcard, i.e., the 2752 source port number is not known. Any other value indicates the 2753 source port number. 2755 o data sender's IPv4 address: The source IP address of the data 2756 sender. This field MUST be set to zero if no IP address is 2757 provided, i.e., a complete wildcard is desired (see dest prefix 2758 field above). 2760 4.2.8 Trace Object 2762 The NATFW_TRACE object may contain zero or more identifiers of 2763 visited NATFW NSLP peers. However, it is only possible to store a 2764 single type of identifier, either IPv4 or IPv6 addresses. 2766 Type: NATFW_TRACE (IANA-TBD) 2768 Length: Variable 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | trace type | hop count | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 : IP address : 2774 : ... 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 Figure 30: Trace object 2779 The NATFW_TRACE object may contain zero or more identifiers. The 2780 type of identifier is given by the value of 'trace type' field. This 2781 memo is defining the values for the 'trace type' field: 0x01 for IPv4 2782 addresses and 0x02 for IPv6 addresses. Other trace types MUST 2783 generate an error RESPONSE of class 'Protocol error' (0x3) with 2784 response code 'Unknown object field value' (0x08). The 'hop count' 2785 field counts the total number of visited NATFW NSLP nodes that are 2786 willing to include their identifier in this object. Each such node 2787 appends its identifier at the end of the object. 2789 4.2.9 NI Credential Object 2791 This object is a container intended to carry credentials provided by 2792 the NI. 2794 Type: NATFW_CREDENTIAL (IANA-TBD) 2796 Length: Variable 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | credential type | credential length | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 : credential data : 2802 : ... 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 Figure 31: Credential Object 2807 The field 'credential type' field contains one of these values: 2809 o 0x0002: Token 2811 Other trace types MUST generate an error RESPONSE of class 'Protocol 2812 error' (0x3) with response code 'Unknown object field value' (0x08). 2814 4.2.10 ICMP Types Object 2816 The 'ICMP types' object contains additional information needed to 2817 configure a NAT of firewall with rules to control ICMP traffic. The 2818 object contains a number of values of the ICMP Type field for which a 2819 filter action should be set up: 2821 Type: NATFW_ICMP_TYPES (IANA-TBD) 2823 Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 2825 Where DIV is an integer division. 2827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2828 | Count | Type | Type | ........ | 2829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 | ................ | 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 | ........ | Type | (Padding) | 2833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 Figure 32: ICMP Types Object 2837 The fields MUST be interpreted according these rules: 2839 count: 8 bit integer specifying the number of 'Type' entries in 2840 the object. 2842 type: 8 bit field specifying an ICMP Type value to which this rule 2843 applies. 2845 padding: Sufficient 0 bits to pad out the last word so that the 2846 total size of object is an even multiple of words. Ignored on 2847 reception. 2849 4.3 Message Formats 2851 This section defines the content of each NATFW NSLP message type. 2852 The message types are defined in Section 4.1. First, the request 2853 messages are defined with their respective objects to be included in 2854 the message. Second, the response messages are defined with their 2855 respective objects to be included. 2857 Basically, each message is constructed of NSLP header and one or more 2858 NSLP objects. The order of objects is not defined, meaning that 2859 objects may occur in any sequence. Objects are marked either with 2860 mandatory [M] or optional [O]. Where [M] implies that this 2861 particular object MUST be included within the message and where [O] 2862 implies that this particular object is OPTIONAL within the message. 2863 Objects defined in this memo carry always the flag combination AB=00 2864 in the NSLP object header. An error RESPONSE message of class 2865 'Protocol error' (0x3) with response code 'Mandatory object missing' 2866 (0x02) MUST be generated if a mandatory declared object is missing. 2867 An error RESPONSE message of class 'Protocol error' (0x3) with 2868 response code 'Illegal object present' (0x05) MUST be generated if an 2869 object was present which must not be used in a message of this type. 2870 An error RESPONSE message of class 'Protocol error' (0x3) with 2871 response code 'Duplicate object present' (0x0A) MUST be generated if 2872 an object appears more than once in a message. 2874 Each section elaborates the required settings and parameters to be 2875 set by the NSLP for the NTLP, for instance, how the message routing 2876 information is set. 2878 4.3.1 CREATE 2880 The CREATE request message is used to create NSLP sessions and to 2881 create policy rules. Furthermore, CREATE messages are used to 2882 refresh sessions and to delete them. 2884 The CREATE request message carries these objects: 2886 o Lifetime object [M] 2888 o Extended flow information object [M] 2890 o Message sequence number object [M] 2892 o Credential object [O] 2894 o Nonce object [M] if P flag set to 1 in the NSLP header, otherwise 2895 [O] 2897 o ICMP Types Object [O] 2899 The message routing information in the NTLP MUST be set to DS as 2900 source address and DR as destination address. All other parameters 2901 MUST be set according the required policy rule. CREATE messages MUST 2902 be transported by using the path-coupled MRM with direction set to 2903 downstream. 2905 4.3.2 RESERVE-EXTERNAL-ADDRESS (REA) 2907 The RESERVE-EXTERNAL-ADDRESS (REA) request message is used to a) 2908 reserve an external IP address/port at NATs, b) to notify firewalls 2909 about NSIS capable DRs, or c) to block incoming data traffic at 2910 upstream firewalls. 2912 The REA request message carries these objects: 2914 o Lifetime object [M] 2916 o Message sequence number object [M] 2918 o Extended flow information object [M] 2920 o Credential object [O] 2922 o Data terminal information object [O] 2924 o Nonce object [M if P flag set to 1 in the NSLP header, otherwise 2925 [O] 2927 o ICMP Types Object [O] 2929 The selected message routing method of the REA request message 2930 depends on a number of considerations. Section 3.8.2 describes it 2931 exhaustively how to select the correct method. REA request messages 2932 can be transported via the path-coupled message routing method (PC- 2933 MRM) or via the loose-end message routing method (LE-MRM). In the 2934 case of PC-MRM, the source-address is set to DS' address and the 2935 destination address is set to DR's address, the direction is set to 2936 upstream. In the case of LE-MRM, the destination-address is set to 2937 DR's address or to the signaling destination address. The source- 2938 address is set to DS's address. 2940 4.3.3 RESPONSE 2942 RESPONSE messages are responses to CREATE and REA messages. 2944 The RESPONSE message for the class 'Success' (0x2) carries these 2945 objects: 2947 o Lifetime object [M] 2949 o Message sequence number object [M] 2951 o Information code object [M] 2952 o External address object [O] 2954 o Trace object [O] 2956 The RESPONSE message for other classes than 'Success' (0x2) carries 2957 these objects: 2959 o Message sequence number object [M] 2961 o Information code object [M] 2963 This message is routed upstream hop-by-hop, using existing NTLP 2964 messaging associations. 2966 4.3.4 NOTIFY 2968 The NOTIFY messages is used to report asynchronous events happening 2969 along the signaled path to other NATFW NSLP nodes. 2971 The NOTIFY message carries this object: 2973 o Information code object [M]. 2975 The NOTIFY message is forwarded upstream hop-by-hop using the 2976 existing upstream node messaging association entry within the node's 2977 Message Routing State table. 2979 4.3.5 TRACE 2981 The TRACE request message is used to trace the involved NATFW NSLP 2982 nodes along a signal session. 2984 The TRACE request message carries these objects: 2986 o Message sequence number object [M] 2988 o Trace object [M] 2990 TRACE request messages are sent path-coupled (PC-MRM). 2992 5. Security Considerations 2994 Security is of major concern particularly in case of firewall 2995 traversal. This section provides security considerations for the 2996 NAT/firewall traversal and is organized as follows. 2998 In Section 5.1 we describe the participating entities relate to each 2999 other from a security point of view. This subsection also motivates 3000 a particular authorization model. 3002 Security threats that focus on NSIS in general are described in [8] 3003 and they are applicable to this document as well. Within Section 5.5 3004 we extend this threat investigation by considering NATFW NSLP 3005 specific threats in detail. Based on the investigated security 3006 threats we derive security requirements. 3008 Finally, we illustrate how the security requirements that were 3009 created based on the security threats can be fulfilled by specific 3010 security mechanisms. These aspects will be elaborated in 3011 Section 5.14. 3013 5.1 Authorization Framework 3015 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 3016 and is, as such, not a two-party protocol. Figure 1 and Figure 2 of 3017 [8] already depict the possible set of communication patterns. In 3018 this section we will re-evaluate these communication patters with 3019 respect to the NATFW NSLP protocol interaction. 3021 The security solutions for providing authorization have a direct 3022 impact on the treatment of different NSLPs. As it can be seen from 3023 the QoS NSLP [6] and the corresponding Diameter QoS work [23] 3024 accounting and charging seems to play an important role for QoS 3025 reservations, whereas monetary aspects might only indirectly effect 3026 authorization decisions for NAT and firewall signaling. Hence, there 3027 are differences in the semantic of authorization handling between QoS 3028 and NATFW signaling. A NATFW aware node will most likely want to 3029 authorize the entity (e.g., user or machine) requesting the 3030 establishment of pinholes or NAT bindings. The outcome of the 3031 authorization decision is either allowed or disallowed whereas a QoS 3032 authorization decision might indicate that a different set of QoS 3033 parameters is authorization (see [23] as an example). 3035 5.2 Peer-to-Peer Relationship 3037 Starting with the simplest scenario, it is assumed that neighboring 3038 nodes are able to authenticate each other and to establish keying 3039 material to protect the signaling message communication. An addition 3040 to authentication the nodes will have to authorize each other. We 3041 use the term 'Security Context' as a placeholder for referring to the 3042 entire security procedure, the necessary infrastructure that needs to 3043 be in place in order for this to work (e.g., key management) and the 3044 established security related state. The required long-term key 3045 (symmetric or asymmetric keys) used for authentication are either 3046 made available using an out-of-band mechanism between the two NSIS 3047 NATFW nodes or they are dynamically established using mechanisms not 3048 further specified in this document. Note that the deployment 3049 environment will most likely have an impact on the choice of 3050 credentials being used. The choice of these credentials used is also 3051 outside the scope of this document. 3053 +------------------------+ +-------------------------+ 3054 |Network A | | Network B| 3055 | +---------+ +---------+ | 3056 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3057 | | | box 1 | Security | box 2 | | | 3058 | | +---------+ Context +---------+ | | 3059 | | Security | | Security | | 3060 | | Context | | Context | | 3061 | | | | | | 3062 | +--+---+ | | +--+---+ | 3063 | | Host | | | | Host | | 3064 | | A | | | | B | | 3065 | +------+ | | +------+ | 3066 +------------------------+ +-------------------------+ 3068 Figure 33: Peer-to-Peer Relationship 3070 Figure 33 shows a possible relationship between participating NSIS 3071 aware nodes. Host A might be, for example, a host in an enterprise 3072 network that has keying material established (e.g., a shared secret) 3073 with the company's firewall (Middlebox 1). The network administrator 3074 of Network A (company network) has created access control lists for 3075 Host A (or whatever identifiers a particular company wants to use). 3076 Exactly the same procedure might also be used between Host B and 3077 Middlebox 2 in Network B. For the communication between Middlebox 1 3078 and Middlebox 2 a security context is also assumed in order to allow 3079 authentication, authorization and signaling message protection to be 3080 successful. 3082 5.3 Intra-Domain Relationship 3084 In larger corporations, for example, a middlebox is used to protect 3085 individual departments. In many cases, the entire enterprise is 3086 controlled by a single (or a small number of) security department, 3087 which gives instructions to the department administrators. In such a 3088 scenario, a the previously discussed peer-to-peer relationship might 3089 be prevalent. Sometimes it might be necessary to preserve 3090 authentication and authorization information within the network. As 3091 a possible solution, a centralized approach could be used, whereby an 3092 interaction between the individual middleboxes and a central entity 3093 (for example a policy decision point - PDP) takes place. As an 3094 alternative, individual middleboxes exchange the authorization 3095 decision with another middlebox within the same trust domain. 3096 Individual middleboxes within an administrative domain may exploit 3097 their relationship instead of requesting authentication and 3098 authorization of the signaling initiator again and again. Figure 34 3099 illustrates a network structure which uses a centralized entity. 3101 +-----------------------------------------------------------+ 3102 | Network A | 3103 | +---------+ +---------+ 3104 | +----///--------+ Middle- +------///------++ Middle- +--- 3105 | | Security | box 2 | Security | box 2 | 3106 | | Context +----+----+ Context +----+----+ 3107 | +----+----+ | | | 3108 | | Middle- +--------+ +---------+ | | 3109 | | box 1 | | | | | 3110 | +----+----+ | | | | 3111 | | Security | +----+-----+ | | 3112 | | Context | | Policy | | | 3113 | +--+---+ +-----------+ Decision +----------+ | 3114 | | Host | | Point | | 3115 | | A | +----------+ | 3116 | +------+ | 3117 +-----------------------------------------------------------+ 3119 Figure 34: Intra-domain Relationship 3121 The interaction between individual middleboxes and a policy decision 3122 point (or AAA server) is outside the scope of this document. 3124 5.4 End-to-Middle Relationship 3126 The peer-to-peer relationship between neighboring NSIS NATFW NSLP 3127 nodes might not always be sufficient. Network B might require 3128 additional authorization of the signaling message initiator (in 3129 addition to the authorization of the neighboring node). If 3130 authentication and authorization information is not attached to the 3131 initial signaling message then the signaling message arriving at 3132 Middlebox 2 would result in an error message being created, which 3133 indicates the additional authorization requirement. In many cases 3134 the signaling message initiator might already aware of the 3135 additionally required authorization before the signaling message 3136 exchange is executed. 3138 Figure 35 shows this scenario. 3140 +--------------------+ +---------------------+ 3141 | Network A | |Network B | 3142 | | Security | | 3143 | +---------+ Context +---------+ | 3144 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3145 | | | box 1 | +-------+ box 2 | | | 3146 | | +---------+ | +---------+ | | 3147 | |Security | | | Security | | 3148 | |Context | | | Context | 3149 | | | | | | | 3150 | +--+---+ | | | +--+---+ | 3151 | | Host +----///----+------+ | | Host | | 3152 | | A | | Security | | B | | 3153 | +------+ | Context | +------+ | 3154 +--------------------+ +---------------------+ 3156 Figure 35: End-to-Middle Relationship 3158 5.5 Security Threats and Requirements 3160 This section describes NATFW specific security threats and 3161 requirements. 3163 5.5.1 Data Sender (DS) behind a firewall 3165 +------------------------------+ 3166 | | 3167 | +-----+ create +-----+ 3168 | | DS | --------------> | FW | 3169 | +-----+ +-----+ 3170 | | 3171 +------------------------------+ 3173 DS sends a CREATE message to request the traversal of a data flow. 3175 The following attacks are possible: 3177 o DS could open a firewall pinhole with a source address different 3178 from its own host. 3180 o DS could open firewall pinholes for incoming data flows that are 3181 not supposed to enter the network. 3183 o DS could request installation of any policy rules and allow all 3184 traffic go through. 3186 SECURITY REQUIREMENT: The middlebox MUST authenticate and authorize 3187 the neighboring NAT/FW NSLP node requesting an action. 3188 Authentication and authorization of the initiator SHOULD be 3189 provided to NATs and firewalls along the path. 3191 5.5.2 Data Sender (DS) behind a NAT 3193 The case 'DS behind a NAT' is analogous to the case 'DS behind a 3194 firewall'. 3196 Figure 37 illustrates such a scenario: 3198 +------------------------------+ 3199 | | 3200 | +------+ CREATE | 3201 | | NI_1 | ------\ +-----+ CREATE +-----+ 3202 | +------+ \------> | NAT |-------->| MB | 3203 | +-----+ +-----+ 3204 | +------+ | 3205 | | NI_2 | | 3206 | +------+ | 3207 +------------------------------+ 3209 Figure 37: Several NIs behind a NAT 3211 In this case the middlebox MB does not know who is the NSIS Initiator 3212 since both NI_1 and NI_2 are behind a NAT (which is also NSIS aware). 3213 Authentication needs to be provided by other means such as the NSLP 3214 or the application layer. 3216 SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that 3217 the neighboring NAT/FW NSLP node is authorized to request an 3218 action. Authentication and authorization of the initiator (which 3219 is the DR in this scenario) to the non-neighboring middleboxes 3220 SHOULD be provided. 3222 5.5.3 Data Receiver (DR) behind a firewall 3224 In this case a CREATE message comes from an entity DS outside the 3225 network towards the DR inside the network. 3227 +------------------------------+ 3228 | | 3229 +-----+ CREATE +-----+ CREATE +-----+ | 3230 | DS | -------------> | FW | -------------> | DR | | 3231 +-----+ <------------- +-----+ <------------- +-----+ | 3232 successful RESPONSE | successful RESPONSE | 3233 | | 3234 +------------------------------+ 3236 Since policy rules at middleboxes must only be installed after 3237 receiving a successful response it is necessary that the middlebox 3238 waits until the Data Receiver DR confirms the request of the Data 3239 Sender DS with a successful RESPONSE message. This is, however, only 3240 necessary 3242 o if the action requested with the CREATE message cannot be 3243 authorized and 3245 o if the middlebox is still forwarding the signaling message towards 3246 the end host (without state creation/deletion/modification). 3248 This confirmation implies that the data receiver is expecting the 3249 data flow. 3251 At this point we differentiate two cases: 3253 1. DR knows the IP address of the DS (for instance because of some 3254 previous application layer signaling) and is expecting the data 3255 flow. 3257 2. DR might be expecting the data flow (for instance because of some 3258 previous application layer signaling) but does not know the IP 3259 address of the Data Sender DS. 3261 For the second case, Figure 39 illustrates a possible attack: an 3262 adversary Mallory M could be sniffing the application layer signaling 3263 and thus knows the address and port number where DR is expecting the 3264 data flow. Thus it could pretend to be DS and send a CREATE message 3265 towards DR with the data flow description (M -> DR). Since DR does 3266 not know the IP address of DS, it is not able to recognize that the 3267 request is coming from the "wrong guy". It will send a success 3268 RESPONSE message back and the middlebox will install policy rules 3269 that will allow Mallory M to inject its data into the network. 3271 Application Layer signaling 3272 <------------------------------------> 3273 / \ 3274 / +-----------------\------------+ 3275 / | \ | 3276 +-----+ +-----+ +-----+ | 3277 | DS | -> | FW | | DR | | 3278 +-----+ / +-----+ +-----+ | 3279 CREATE / | | 3280 +-----+ / +-------------------------------+ 3281 | M |---------- 3282 +-----+ 3284 Figure 39: DR behind a firewall with an adversary 3286 Network administrators will probably not rely on a DR to check the IP 3287 address of the DS. Thus we have to assume the worst case with an 3288 attack such as in Figure 39. Many operators might not allow NSIS 3289 signaling message to traverse the firewall in Figure 39 without 3290 having the DR to interact with the FW first. 3292 SECURITY REQUIREMENT: No requirements are created by this scenario. 3294 5.5.4 Data Receiver (DR) behind a NAT 3296 When a data receiver DR behind a NAT sends a RESERVE-EXTERNAL-ADDRESS 3297 (REA) message to get a public reachable address that can be used as a 3298 contact address by an arbitrary data sender if the DR was unable to 3299 restrict the future data sender. The NAT reserves an external 3300 address and port number and sends them back to DR. The NAT adds an 3301 address mapping entry in its reservation list which links the public 3302 and private addresses as follows: 3304 (DR_ext <=> DR_int) (*). 3306 The NAT sends a RESPONSE message with the external address' object 3307 back to the DR with the address DR_ext. DR informs DS about the 3308 public address that it has recently received, for instance, by means 3309 of application layer signaling. 3311 When a data sender sends a CREATE message towards DR_ext then the 3312 message will be forwarded to the DR. The data sender might want to 3313 update the NAT binding stored at the edge-NAT to make it more 3314 restrictive. 3316 We assume that the adversary Mallory M obtains the contact address 3317 (i.e., external address and port) allocated at the NAT possibly by 3318 eavesdropping on the application layer signaling and sends a CREATE 3319 message. As a consequence Mallory would be able to communicate with 3320 DR (if M is authorized by the edge-NAT and if the DR accepts CREATE 3321 and returns a RESPONSE. 3323 Application Layer signaling 3324 <------------------------------------------> 3325 / \ 3326 / +----------------------\-------+ 3327 v | REA v | 3328 +-----+ +-----+ <----------- +-----+ | 3329 | DS | -> | NAT | -----------> | DR | | 3330 +-----+ / +-----+ DR_external +-----+ | 3331 CREATE / | | 3332 +-----+ / +-------------------------------+ 3333 | M |---------- 3334 +-----+ 3336 SECURITY REQUIREMENT: The DR MUST be able to specify which data 3337 sender are allowed to traverse the NAT in order to be forwarded to 3338 DRs address. 3340 5.5.5 NSLP Message Injection 3342 Malicious hosts, located either off-path or on-path, could inject 3343 arbitrary NATFW NSLP messages into the signaling path. These 3344 problems apply when no proper authorization and authentication scheme 3345 is available. 3347 By injecting a bogus CREATE message with lifetime set to zero, a 3348 malicious host could try to teardown NATFW NSLP session state 3349 partially or completely on a data path, causing a service 3350 interruption. 3352 By injecting a bogus responses or NOTIFY message, for instance, 3353 timeout, a malicious host could try to teardown NATFW NSLP session 3354 state as well. This could affect the data path partially or totally, 3355 causing a service interruption. 3357 SECURITY REQUIREMENT: Messages, such as NOTIFY, can be misused by 3358 malicious hosts, and therefore MUST be authorized by the 3359 respective NATFW NLSP entities. 3361 5.6 Denial-of-Service Attacks 3363 In this section we describe several ways how an adversary could 3364 launch a Denial of service (DoS) attack on networks running NSIS for 3365 middlebox configuration to exhaust their resources. 3367 5.6.1 Flooding with CREATE messages from outside 3369 5.6.1.1 Attacks due to NSLP state 3371 A CREATE message requests the NSLP to store state information such as 3372 a NAT binding or a policy rule. 3374 The policy rules requested in the CREATE message will be installed at 3375 the arrival of a confirmation from the Data Receiver with a success 3376 RESPONSE message. A successful RESPONSE message includes the session 3377 ID. So the NSLP looks up the NSIS session and installs the requested 3378 policy rules. 3380 An adversary could launch a DoS attack with an arbitrary number of 3381 CREATE messages. For each of these messages the middlebox needs to 3382 store state information such as the policy rules to be loaded, i.e., 3383 the middlebox could run out of memory. This kind of attack is also 3384 mentioned in [8] Section 4.8. 3386 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 3387 establishment of state information. 3389 5.6.1.2 Attacks due to authentication complexity 3391 This kind of attack is possible if authentication is based on 3392 mechanisms that require computing power, for example, digital 3393 signatures. 3395 For a more detailed treatment of this kind of attack, the reader is 3396 encouraged to see [8]. 3398 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 3399 denial of service attacks based on authentication or key exchange 3400 mechanisms. 3402 5.6.1.3 Attacking Endpoints 3404 The NATFW NSLP requires firewalls to forward NSLP messages, a 3405 malicious node may keep sending NSLP messages to a target. This may 3406 consume the access network resources of the victim, drain the battery 3407 of the victim's terminal and may force the victim to pay for the 3408 received although undesired data. 3410 This threat may be more particularly be relevant in networks where 3411 access link is a limited resource, for instance in cellular networks, 3412 and where the terminal capacities are limited. 3414 SECURITY REQUIREMENT: A NATFW NSLP node MUST be configurable to block 3415 unauthorized signaling message. 3417 5.6.2 Flooding with REA messages from inside 3419 Although we are more concerned with possible attacks from outside the 3420 network, we need also to consider possible attacks from inside the 3421 network. 3423 An adversary inside the network could send arbitrary RESERVE- 3424 EXTERNAL-ADDRESS messages. At a certain point the NAT will run out 3425 of port numbers and the access for other users to the outside will be 3426 disabled. 3428 SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state 3429 creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, 3430 the NAT/FW NSLP implementation MUST prevent denial of service 3431 attacks involving the allocation of an arbitrary number of NAT 3432 bindings or the installation of a large number of packet filters. 3434 5.7 Man-in-the-Middle Attacks 3436 Figure 41 illustrates a possible man-in-the-middle attack using the 3437 RESERVE-EXTERNAL-ADDRESS (REA) message. This message travels from DR 3438 towards the public Internet. The message might not be intercepted 3439 because there are no NSIS aware middleboxes. 3441 Imagine such an NSIS signaling message is then intercepted by an 3442 adversary Mallory (M). M returns a faked RESPONSE message whereby 3443 the adversary pretends that a NAT binding was created. This NAT 3444 binding is returned with the RESPONSE message. Mallory might insert 3445 it own IP address in the response, the IP address of a third party or 3446 the address of a black hole. In the first case, the DR thinks that 3447 the address of Mallory M is its public address and will inform the DS 3448 about it. As a consequence, the DS will send the data traffic to 3449 Mallory M. 3451 The data traffic from the DS to the DR will re-directed to Mallory M. 3452 M will be able to read, modify or block the data traffic (if the end- 3453 to-end communication itself does not experience protection). 3454 Eavesdropping and modification is only possible if the data traffic 3455 is itself unprotected. 3457 +-----+ +-----+ +-----+ 3458 | DS | | M | | DR | 3459 +-----+ +-----+ +-----+ 3460 | | | 3461 | | REA | 3462 | | <------------------ | 3463 | | | 3464 | | RESPONSE | 3465 | | ------------------> | 3466 | | | 3467 | data traffic | | 3468 |===============>| data traffic | 3469 | |====================>| 3471 Figure 41: MITM attack using the RESERVE-EXTERNAL-ADDRESS message 3473 SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW 3474 NSLP MUST be provided. To ensure that only legitimate nodes along 3475 the path act as NSIS entities the initiator MUST authorize the 3476 responder. In the example in Figure 41 the firewall FW must 3477 perform an authorization with the neighboring entities. 3479 5.8 Message Modification by non-NSIS on-path node 3481 An unauthorized on-path node along the path towards the destination 3482 could easily modify, inject or just drop an NSIS message. It could 3483 also hijack or disrupt the communication. 3485 SECURITY REQUIREMENT: Message integrity, replay protection and data 3486 origin authentication between neighboring NAT/FW NSLPs MUST be 3487 provided. 3489 5.9 Message Modification by malicious NSIS node 3491 Message modification by an NSIS node that became malicious is more 3492 serious. An adversary could easily create arbitrary pinholes or NAT 3493 bindings. For example: 3495 o NATs need to modify the source/destination of the data flow in the 3496 'create session' message. 3498 o Each middlebox along the path may change the requested lifetime in 3499 the CREATE message to fit their needs and/or local policy. 3501 SECURITY REQUIREMENT: Malicious NSIS NATs and firewalls will not be 3502 addressed by this specification. 3504 5.10 Session Modification/Deletion 3506 Section 4.10 in [8] describes a threat where an adversary is able to 3507 modify previously installed state information at NATFW NSLP nodes 3508 along the path. An adversary therefore needs to know session 3509 specific information, such as the session identifier and MRI 3510 information. 3512 SECURITY REQUIREMENT: No countermeasure will be provided as part of 3513 this document. The fact that the adversary needs to learn the 3514 randomly generated Session-ID already provides some degree of 3515 protection (although not perfect protection). 3517 5.10.1 Misuse of mobility in NAT handling 3519 Another kind of session modification is related to mobility 3520 scenarios. NSIS allows end hosts to be mobile, it is possible that 3521 an NSIS node behind a NAT needs to update its NAT binding in case of 3522 address change. Whenever a host behind a NAT initiates a data 3523 transfer, it is assigned an external IP and port number. In typical 3524 mobility scenarios, the DR might also obtain a new address according 3525 to the topology and it should convey its new IP address to the NAT. 3526 The NAT is assumed to modify these NAT bindings based on the new IP 3527 address conveyed by the end host. 3529 Public Private Address 3530 Internet space 3532 +----------+ +----------+ 3533 +----------| NAT |------------------|End host | 3534 | | | | 3535 +----------+ +----------+ 3536 | 3537 | +----------+ 3538 \--------------------|Malicious | 3539 |End host | 3540 +----------+ 3541 data traffic 3542 <======================== 3544 Figure 42: Misuse of mobility in NAT binding 3546 A NAT binding can be changed with the help of NSIS signaling. When a 3547 DR moves to a new location and obtains a new IP address, it sends an 3548 NSIS signaling message to modify the NAT binding. It would use the 3549 Session-ID and the new flow-id to update the state. The NAT updates 3550 the binding and the DR continues to receive the data traffic. 3551 Consider the scenario in Figure 42 where an the end host(DR) and the 3552 adversary are behind a NAT. The adversary pretending that it is the 3553 end host could generate a spurious signaling message to update the 3554 state at the NAT. This could be done for these purposes: 3556 o Redirecting packets to the attacker as in Figure 43. 3558 o Third party flooding by redirecting packets to arbitrary hosts 3560 o Service disruption by redirecting to non-existing hosts 3561 +----------+ +----------+ +----------+ 3562 | NAT | |End host | |Malicious | 3563 | | | | |End host | 3564 +----------+ +----------+ +----------+ 3565 | | | 3566 | Data Traffic | | 3567 |--------->----------| | 3568 | | Spurious | 3569 | | NAT binding update | 3570 |---------<----------+--------<------------| 3571 | | | 3572 | Data Traffic | | 3573 |--------->----------+-------->------------| 3574 | | | 3576 Figure 43: Connection Hijacking 3578 SECURITY REQUIREMENT: A NAT/FW signaling message MUST be 3579 authenticated, integrity and replay protected between neighboring 3580 NAT/FW NSLP nodes. The NSIS NATFW NSLP aware NAT MUST authorize 3581 the end host to insure that the messages are indeed belonging to 3582 the previously established session. 3584 5.11 Misuse of unreleased sessions 3586 Assume that DS (N1) initiates NSIS session with DR (N2) through a 3587 series of middleboxes as in Figure 44. When the DS is sending data 3588 to DR, it might happen that the DR disconnects from the network 3589 (crashes or moves out of the network in mobility scenarios). In such 3590 cases, it is possible that another node N3 (which recently entered 3591 the network protected by the same firewall) is assigned the same IP 3592 address that was previously allocated to N2. The DS could take 3593 advantage of the firewall policies installed already, if the refresh 3594 interval time is very high. The DS can flood the node (N3), which 3595 will consume the access network resources of the victim forcing it to 3596 pay for unwanted traffic as shown in Figure 45. Note that here we 3597 make the assumption that the data receiver has to pay for receiving 3598 data packets. 3600 Public Internet 3601 +--------------------------+ 3602 | | 3603 +-------+ CREATE +---+-----+ +-------+ | 3604 | |-------------->------| |---->---| | | 3605 | N1 |--------------<------| FW |----<---| N2 | | 3606 | | successful RESPONSE | | | | | 3607 | |==============>======| |====>===| | | 3608 +-------+ Data Traffic +---+-----+ +-------+ | 3609 | | 3610 +--------------------------+ 3612 Figure 44: Before mobility 3614 Public Internet 3615 +--------------------------+ 3616 | | 3617 +-------+ +---+-----+ +-------+ | 3618 | | | | | | | 3619 | N1 |==============>======| FW |====>===| N3 | | 3620 | | Data Traffic | | | | | 3621 +-------+ +---+-----+ +-------+ | 3622 | | 3623 +--------------------------+ 3625 Figure 45: After mobility 3627 Also, this threat is valid for the other direction as well. The DS 3628 which is communicating with the DR may disconnect from the network 3629 and this IP address may be assigned to a new node that had recently 3630 entered the network. This new node could pretend to be the DS and 3631 send data traffic to the DR in conformance with the firewall policies 3632 and cause service disruption. 3634 SECURITY REQUIREMENT: In order to allow firewalls to verify that a 3635 legitimate end host indeed transmitted data traffic it is 3636 necessary to provide data origin authentication. This is, 3637 however, outside the scope of this document. Hence, there are no 3638 security requirements imposed by this threat, which will be 3639 addressed by the NATFW NSLP. 3641 5.12 Data Traffic Injection 3643 In some environments, such as enterprise networks, it is still common 3644 to perform authorization for access to a service based on the source 3645 IP address of the service requester. There is no doubt that this 3646 practice by itself represents a security weakness. Using IPy 3647 spoofing a connection, an attacker an adversary is able to reach the 3648 target machines if they match , using the existing firewall rules. 3650 The adversary is able to inject its own data traffic in conformance 3651 with the firewall policies simultaneously along with the genuine DS. 3653 SECURITY REQUIREMENT: Since IP spoofing is a general limitation of 3654 non-cryptographic packet filters no countermeasures need to be 3655 taken by the NAT/FW NSLP. Techniques such as ingress filtering 3656 (described below) and data origin authentication (such as provided 3657 with IPsec based VPNs) can help mitigate this threat. This issue 3658 is, however, outside the scope of this document. 3660 Ingress Filtering: Consider the scenario shown in Figure 46. In this 3661 scenario the DS is behind a router (R1) and a malicious node (M) is 3662 behind another router (R2). The DS communicates with the DR through 3663 a firewall (FW). The DS initiates NSIS signaling and installs 3664 firewall policies at FW. But the malicious node is also able to send 3665 data traffic using DS's source address. If R2 implements ingress 3666 filtering, these spoofed packets will be blocked. But this ingress 3667 filtering may not work in all scenarios. If both the DS and the 3668 malicious node are behind the same router, then the ingress filter 3669 will not be able to detect the spoofed packets as both the DS and the 3670 malicious node are in the same address range. 3672 +-----------------------------------+ 3673 | +------------------+ | 3674 | | +-------+ +---+---+ | 3675 | | | DS +>--+ R1 +->+ | 3676 | | | | | | | | 3677 | | +-------+ +---+---+ | | 3678 | | | | | 3679 | +------------------+ | +---+---+ +-------+ 3680 | | | | | | 3681 | +---+ FW +-->--| DR | 3682 | +------------------+ ****| |*****| | 3683 | | | * +---+---+ +-------+ 3684 | | +-------+ +---+---+ * | 3685 | | | M | | R2 | * | 3686 | | | |***| |*** | 3687 | | +-------+ +---+---+ | 3688 | +------------------+ | 3689 +-----------------------------------+ 3691 ---->---- = genuine data traffic 3692 ********* = spoofed data traffic 3694 Figure 46: Ingress filtering 3696 5.13 Eavesdropping and Traffic Analysis 3698 By collecting NSLP messages, an adversary is able to learn policy 3699 rules for packet filters and knows which ports are open. It can use 3700 this information to inject its own data traffic due to the IP 3701 spoofing capability already mentioned in Section 5.12. An on-path 3702 adversary could also observe the data traffic and he could conclude 3703 that it is possible to traverse a firewall. 3705 An adversary could learn authorization tokens included in CREATE 3706 messages and use them to launch replay-attacks or to create a session 3707 with its own address as source address. This threat is discussed in 3708 the respective document suggesting the usage of authorization token 3709 in the NSIS protocol suite. 3711 SECURITY REQUIREMENT: The threat of eavesdropping itself does not 3712 mandate the usage of confidentiality protection since an adversary 3713 can also eavesdrop on data traffic. In the context of a 3714 particular security solutions (e.g., authorization tokens) it MAY 3715 be necessary to offer confidentiality protection. The latter 3716 aspect is outside the scope of this document. 3718 5.14 Security Framework for the NAT/Firewall NSLP 3720 Based on the identified threats a list of security requirements has 3721 been created. 3723 5.14.1 Security Protection between neighboring NATFW NSLP Nodes 3725 Based on the analyzed threats it is necessary to provide, between 3726 neighboring NATFW NSLP nodes, the following mechanism: provide 3728 o data origin authentication 3730 o replay protection 3732 o integrity protection and 3734 o optionally confidentiality protection 3736 To consider the aspect of authentication and key exchange the 3737 security mechanisms provided in [1] between neighboring nodes MUST 3738 be enabled when sending NATFW signaling messages. The proposed 3739 security mechanisms at GIST provide support for authentication and 3740 key exchange in addition to denial of service protection. Depending 3741 on the chosen security protocol, support for multiple authentication 3742 protocols might be provided. The mandatory support for security, 3743 demands the usage of C-MODE for the delivery of data packets and the 3744 usage of D-MODE only to discover the next NATFW NSLP aware node along 3745 the path. Almost all security threats at the NATFW NSLP layer can be 3746 prevented by using a mutually authenticated Transport Layer secured 3747 connection and by relying on authorization by the neighboring NATFW 3748 NSLP entities. 3750 5.14.2 Security Protection between non-neighboring NATFW NSLP Nodes 3752 Based on the security threats and the listed requirements it was 3753 noted that some scenarios threats also demand authentication and 3754 authorization of a NATFW signaling entity (including the initiator) 3755 towards a non-neighboring node. This mechanism mainly demands entity 3756 authentication. Additionally, security protection of certain 3757 payloads MAY is be required between non-neighboring signaling 3758 entities and the Cryptographic Message Syntax (CMS) [17] SHOULD be 3759 used. The most important information exchanged at the NATFW NSLP is 3760 information related to the establishment for firewall pinholes and 3761 NAT bindings. This information can, however, not be protected over 3762 multiple NSIS NATFW NSLP hops since this information might change 3763 depending on the capability of each individual NATFW NSLP node. 3764 Protection using CMS is not described in this document. 3766 Some scenarios might also benefit from the usage of authorization 3767 tokens. Their purpose is to associate two different signaling 3768 protocols (e.g., SIP and NSIS) and their authorization decision. 3769 These tokens are obtained by non-NSIS protocols, such as SIP or as 3770 part of network access authentication. When a NAT or firewall along 3771 the path receives the token it might be verified locally or passed to 3772 the AAA infrastructure. 3774 Examples of authorization tokens or assertions can be found in RFC 3775 3520 [21] and RFC 3521 [22]. Security Assertion Markup Language 3776 (SAML) is an example for a more recent mechanisms carrying 3777 authorization specific assertions. For details about SAML see [24], 3778 [25] and [26]. Figure 47 shows an example of this protocol 3779 interaction. An authorization token is provided by the SIP proxy, 3780 which acts as the assertion generating entity and gets delivered to 3781 the end host with proper authentication and authorization. When the 3782 NATFW signaling message is transmitted towards the network, the 3783 authorization token is attached to the signaling messages to refer to 3784 the previous authorization decision. The assertion verifying entity 3785 needs to process the token or it might be necessary to interact with 3786 the assertion granting entity using HTTP (or other protocols). As a 3787 result of a successfully authorization by a NATFW NSLP node, the 3788 requested action is executed and later a RESPONSE message is 3789 generated. 3791 +----------------+ Trust Relationship +----------------+ 3792 | +------------+ |<.......................>| +------------+ | 3793 | | Protocol | | | | Assertion | | 3794 | | requesting | | HTTP, SIP Request | | Granting | | 3795 | | authz | |------------------------>| | Entity | | 3796 | | assertions | |<------------------------| +------------+ | 3797 | +------------+ | Artifact/Assertion | Entity Cecil | 3798 | ^ | +----------------+ 3799 | | | ^ ^| 3800 | | | . || HTTP, 3801 | | | Trust . || other 3802 | API Access | Relationship. || protocols 3803 | | | . || 3804 | | | . || 3805 | | | v |v 3806 | v | +----------------+ 3807 | +------------+ | | +------------+ | 3808 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3809 | | using authz| | Assertion/Artifact | | Verifying | | 3810 | | assertion | | ----------------------- | | Entity | | 3811 | +------------+ | | +------------+ | 3812 | Entity Alice | <---------------------- | Entity Bob | 3813 +----------------+ RESPONSE +----------------+ 3815 Figure 47: Authorization Token Usage 3817 Threats against the usage of authorization tokens have been mentioned 3818 in [8] and also in Section 5.5. Hence, it is required to provide 3819 confidentiality protection to avoid allowing an eavesdropper to learn 3820 the token and to use it in another session (replay attack). The 3821 token itself also needs to be protected against tempering. 3823 This document does provide an initial specification of an NATFW NSLP 3824 object for usage of authorization tokens. The NATFW_CREDENTIAL 3825 object can carry authorization token or any other type. 3827 6. IAB Considerations on UNSAF 3829 UNilateral Self-Address Fixing (UNSAF) is described in [15] as a 3830 process at originating endpoints that attempt to determine or fix the 3831 address (and port) by which they are known to another endpoint. 3832 UNSAF proposals, such as STUN [RFC3489] are considered as a general 3833 class of workarounds for NAT traversal and as solutions for scenarios 3834 with no middlebox communication. 3836 This memo specifies a path-coupled middlebox communication protocol, 3837 i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are 3838 not intended as a short-term workaround, but more as a long-term 3839 solution for middlebox communication. In NSIS, endpoints are 3840 involved in allocating, maintaining, and deleting addresses and ports 3841 at the middlebox. However, the full control of addresses and ports 3842 at the middlebox is at the NATFW NSLP daemon located to the 3843 respective NAT. 3845 Therefore, this document addresses the UNSAF considerations in 3846 [RFC3424] by proposing a long-term alternative solution. 3848 7. IANA Considerations 3850 This section provides guidance to the Internet Assigned Numbers 3851 Authority (IANA) regarding registration of values related to the 3852 NATFW NSLP, in accordance with BCP 26 RFC 2434 [16]. 3854 The NATFW NSLP requires IANA to create a number of new registries. 3855 These registries may require further coordination with the registries 3856 of the NTLP [1] and the QoS NSLP [6]. 3858 NATFW NSLP Message Type Registry 3859 The NATFW NSLP Message Type is a 8 bit value. The allocation of 3860 values for new message types requires standards action. Updates and 3861 deletion of values from the registry is not possible. This 3862 specification defines five NATFW NSLP message types, which form the 3863 initial contents of this registry. IANA is requested to add these 3864 five NATFW NSLP Message Types: CREATE, REA, TRACE, RESPONSE, and 3865 NOTIFY. 3867 NATFW NSLP Header Flag Registry 3868 NATFW NSLP messages have a messages-specific 8 bit flags/reserved 3869 field in their header. The registration of flags is subject to IANA 3870 registration. The allocation of values for flag types requires 3871 standards action. Updates and deletion of values from the registry 3872 is not possible. This specification defines only one flag, the P 3873 flag in Figure 21. 3875 NSLP Object Type Registry 3876 This document defines 10 objects for the NATFW NSLP: NATFW_LT, 3877 NATFW_EXT_IP, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, 3878 NATFW_DTINFO_IPv4, NATFW_TRACE, NATFW_CREDENTIAL, NATFW_ICMP_TYPES. 3879 The allocation of values for new message types requires standards 3880 action. IANA is request to assigned values for them from NSLP Object 3881 Type registry and to replace the corresponding IANA-TBD tags with the 3882 numeric values. 3884 NSLP Response Code Registry 3885 In addition it defines a number of Response Codes for the NATFW NSLP. 3886 These can be found in Section 4.2.4 and are to be assigned values 3887 from NSLP Response Code registry. The allocation of values for 3888 Response Codes Codes requires standards action. IANA is request to 3889 assigned values for them from NSLP Response Code registry. 3891 Furthermore, IANA is requested to add a new value to the NSLP 3892 Identifiers (NSLPID) registry defined in [1] for the the NATFW NSLP. 3894 8. Open Issues 3896 A more detailed list of open issue can be found at: 3897 https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/index 3899 9. Acknowledgments 3901 We would like to thank the following individuals for their 3902 contributions to this document at different stages: 3904 o Marcus Brunner and Henning Schulzrinne for work on work on IETF 3905 drafts which lead us to start with this document, 3907 o Miquel Martin for his help on the initial version of this 3908 document, 3910 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3911 NAT/firewall threats draft, 3913 o Henning Peters for his comments and suggestions, 3915 o and the NSIS working group. 3917 10. References 3919 10.1 Normative References 3921 [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet 3922 Signaling Transport", draft-ietf-nsis-ntlp-08 (work in 3923 progress), September 2005. 3925 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3926 Levels", BCP 14, RFC 2119, March 1997. 3928 [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 3929 August 1996. 3931 10.2 Informative References 3933 [4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3934 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 3935 June 2005. 3937 [5] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 3938 April 2004. 3940 [6] Bosch, S., "NSLP for Quality-of-Service signalling", 3941 draft-ietf-nsis-qos-nslp-08 (work in progress), October 2005. 3943 [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 3944 Rayhan, "Middlebox communication architecture and framework", 3945 RFC 3303, August 2002. 3947 [8] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 3948 Steps in Signaling (NSIS)", RFC 4081, June 2005. 3950 [9] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 3951 (NAT) Terminology and Considerations", RFC 2663, August 1999. 3953 [10] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 3954 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 3956 [11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 3957 RFC 3234, February 2002. 3959 [12] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, 3960 "DNS extensions to Network Address Translators (DNS_ALG)", 3961 RFC 2694, September 1999. 3963 [13] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 3964 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3965 Specification", RFC 2205, September 1997. 3967 [14] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 3968 Herzog, S., and R. Hess, "Identity Representation for RSVP", 3969 RFC 3182, October 2001. 3971 [15] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 3972 Address Fixing (UNSAF) Across Network Address Translation", 3973 RFC 3424, November 2002. 3975 [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3976 Considerations Section in RFCs", BCP 26, RFC 2434, 3977 October 1998. 3979 [17] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 3980 August 2002. 3982 [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3983 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3984 Session Initiation Protocol", RFC 3261, June 2002. 3986 [19] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 3987 - Simple Traversal of User Datagram Protocol (UDP) Through 3988 Network Address Translators (NATs)", RFC 3489, March 2003. 3990 [20] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 3991 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and 3992 S. Waldbusser, "Terminology for Policy-Based Management", 3993 RFC 3198, November 2001. 3995 [21] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 3996 Authorization Policy Element", RFC 3520, April 2003. 3998 [22] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session 3999 Set-up with Media Authorization", RFC 3521, April 2003. 4001 [23] Alfano, F., "Diameter Quality of Service Application", 4002 draft-alfano-aaa-qosprot-05 (work in progress), October 2005. 4004 [24] Maler, E., Philpott, R., and P. Mishra, "Bindings and Profiles 4005 for the OASIS Security Assertion Markup Language (SAML) V1.1", 4006 September 2003. 4008 [25] Maler, E., Philpott, R., and P. Mishra, "Assertions and 4009 Protocol for the OASIS Security Assertion Markup Language 4010 (SAML) V1.1", September 2003. 4012 [26] Maler, E. and J. Hughes, "Technical Overview of the OASIS 4013 Security Assertion Markup Language (SAML) V1.1", March 2004. 4015 [27] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as 4016 firewall Signalling Protocol", Proceedings of the 6th IEEE 4017 Symposium on Computers and Communications, Hammamet, 4018 Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001. 4020 Authors' Addresses 4022 Martin Stiemerling 4023 Network Laboratories, NEC Europe Ltd. 4024 Kurfuersten-Anlage 36 4025 Heidelberg 69115 4026 Germany 4028 Phone: +49 (0) 6221 905 11 13 4029 Email: stiemerling@netlab.nec.de 4030 URI: http://www.stiemerling.org 4032 Hannes Tschofenig 4033 Siemens AG 4034 Otto-Hahn-Ring 6 4035 Munich 81739 4036 Germany 4038 Phone: 4039 Email: Hannes.Tschofenig@siemens.com 4040 URI: http://www.tschofenig.com 4042 Cedric Aoun 4043 Ecole Nationale Superieure des Telecommunications 4044 Paris 4045 France 4047 Email: cedric@caoun.net 4049 Elwyn Davies 4050 Folly Consulting 4051 Soham 4052 UK 4054 Phone: +44 7889 488 335 4055 Email: elwynd@dial.pipex.com 4057 Appendix A. Selecting Signaling Destination Addresses for REA 4059 As with all other message types, REA messages need a reachable final 4060 destination IP address. But as many applications do not provide a 4061 destination IP address in the first place, there is a need to choose 4062 a destination address for REA messages. This destination address can 4063 be the final target, but for applications which do not provide an 4064 upfront address, the destination address has to be chosen 4065 independently. Choosing the 'correct' destination IP address may be 4066 difficult and it is possible there is no 'right answer'. 4068 1. Public IP address of the data sender: 4070 * Assumption: 4072 + The data receiver already learned the IP address of the 4073 data sender (e.g., via a third party). 4075 * Problems: 4077 + The data sender might also be behind a NAT. In this case 4078 the public IP address of the data receiver is the IP 4079 address allocated at this NAT. 4081 + Due to routing asymmetry it might be possible that the 4082 routes taken by a) the data sender and the application 4083 server b) the data sender and NAT B might be different. As 4084 a consequence it might be necessary to advertise a new (and 4085 different) external IP address within the application 4086 (which may or may not allow that) after using NSIS to 4087 establish a NAT binding. 4089 2. Public IP address of the data receiver: 4091 * Assumption: 4093 + The data receiver already learned his externally visible IP 4094 address (e.g., based on the third party communication). 4096 * Problems: 4098 + Communication with a third party is required. 4100 3. IP address of the Application Server: 4102 * Assumption: 4104 + An application server (or a different third party) is 4105 available. 4107 * Problems: 4109 + If the NSIS signaling message is not terminated at the NAT 4110 of the local network then an NSIS unaware application 4111 server might discard the message. 4113 + Routing might not be optimal since the route between a) the 4114 data receiver and the application server b) the data 4115 receiver and the data sender might be different. 4117 Appendix B. Applicability Statement on Data Receivers behind Firewalls 4119 Section 3.8.2 describes how data receivers behind middleboxes can 4120 instruct upstream firewalls/NATs to forward NATFW NSLP signaling 4121 towards them. Finding an upstream edge-NAT in address environment 4122 with NAT'ed addresses is quite easy. It is only required to find 4123 some edge-NAT, as the data traffic will be route-pinned to the NAT, 4124 which is done with the LE-MRM. Locating the appropriate edge- 4125 firewall with the PC-MRM, sent upstream is difficult. For cases with 4126 a single, symmetric route from the Internet to the data receiver, it 4127 is quite easy; simply follow the default route in the upstream 4128 direction. 4130 +------+ Data Flow 4131 +-------| EFW1 +----------+ <=========== 4132 | +------+ ,--+--. 4133 +--+--+ / \ 4134 NI+-----| FW1 | (Internet )----NR+/NI/DS 4135 NR +--+--+ \ / 4136 | +------+ `--+--' 4137 +-------| EFW2 +----------+ 4138 +------+ 4140 ~~~~~~~~~~~~~~~~~~~~~> 4141 Signaling Flow 4143 Figure 48: Data receiver behind multiple, parallel located firewalls 4145 When a data receiver, and thus NR, is located in a network site that 4146 is multihomed with several independently firewalled connections to 4147 the public Internet (as shown in Figure 48), the specific firewall 4148 through which the data traffic will be routed has to be ascertained. 4149 NATFW NSLP signaling messages sent from the NI+/NR during the REA 4150 request message exchange towards the NR+ must be routed by the NTLP 4151 to the edge-firewall that will be passed by the data traffic as well. 4152 The NTLP would need to be aware about the routing within the Internet 4153 to determine the path between DS and DR. Out of this, the NTLP could 4154 determine which of the edge-firewalls, either EFW1 or EFW2, must be 4155 selected to forward the NATFW NSLP signaling. Signaling to the wrong 4156 edge-firewall, as shown in Figure 48, would install the NATFW NSLP 4157 policy rules at the wrong device. This causes either a blocked data 4158 flow (when the policy rule is 'allow') or an ongoing attack (when the 4159 policy rule is 'deny'). Requiring the NTLP to know all about the 4160 routing within the Internet is definitely a tough challenge and 4161 usually not possible. In such described case, the NTLP must 4162 basically give up and return an error to the NSLP level, indicating 4163 that the next hop discovery is not possible. 4165 Appendix C. Firewall and NAT Resources 4167 This section gives some examples on how NATFW NSLP policy rules could 4168 be mapped to real firewall or NAT resources. The firewall rules and 4169 NAT bindings are described in a natural way, i.e., in a way one will 4170 find it in common implementation. 4172 C.1 Wildcarding of Policy Rules 4174 The policy rule/MRI to be installed can be wildcarded to some degree. 4175 Wildcarding applies to IP address, transport layer port numbers, and 4176 the IP payload (or next header in IPv6). Processing of wildcarding 4177 splits into the NTLP and the NATFW NSLP layer. The processing at the 4178 NTLP layer is independent of the NSLP layer processing and per layer 4179 constraints apply. For wildcarding in the NTLP see Section 5.8 of 4180 [1]. 4182 Wildcarding at the NATFW NSLP level is always a node local policy 4183 decision. A signaling message carrying a wildcarded MRI (and thus 4184 policy rule) arriving at an NSLP node can be rejected if the local 4185 policy does not allow the request. For instance, a MRI with IP 4186 addresses set (not wildcarded), transport protocol TCP, and TCP port 4187 numbers completely wildcarded. Now the local policy allows only 4188 requests for TCP with all ports set and not wildcarded. The request 4189 is going to be rejected. 4191 C.2 Mapping to Firewall Rules 4193 This section describes how a NSLP policy rule signaled with a CREATE 4194 request message is mapped to a firewall rule. The MRI is set as 4195 follows: 4197 o network-layer-version=IPv4 4199 o source-address=192.0.2.100, prefix-length=32 4201 o destination-address=192.0.50.5, prefix-length=32 4203 o IP-protocol=UDP 4205 o L4-source-port=34543, L4-destination-port=23198 4207 The NATFW_EFI object is set to action=allow and sub_ports=0. 4209 The resulting policy rule (firewall rule) to be installed might look 4210 like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198 4212 C.3 Mapping to NAT Bindings 4214 This section describes how a NSLP policy rule signaled with a REA 4215 request message is mapped to a NAT binding. It is assumed that the 4216 REA message is sent by a NI+ being located behind a NAT and does 4217 contain a NATFW_DTINFO object. The MRI is set following using the 4218 signaling destination address, since the IP address of the real data 4219 sender is not known: 4221 o network-layer-version=IPv4 4223 o source-address= 192.168.5.100 4225 o destination-address=SDA 4227 o IP-protocol=UDP 4229 The NATFW_EFI object is set to action=allow and sub_ports=0. The 4230 NATFW_DTINFO object contains these parameters: 4232 o P=1 4234 o dest prefix=0 4236 o protocol=UDP 4238 o dst port number = 20230, src port number=0 4240 o src IP=0.0.0.0 4242 The edge-NAT allocates the external IP 192.0.2.79 and port 45000. 4244 The resulting policy rule (NAT binding) to be installed could look 4245 like: translate from any to 192.0.2.79 port=45000 to 192.168.5.100 4246 port=20230 4248 C.4 NSLP Handling of Twice-NAT 4250 The dynamic configuration of twice-NATs requires application level 4251 support, as stated in Section 2.5. The NATFW NSLP cannot be used for 4252 configuring twice-NATs if application level support is needed. 4253 Assuming application level support performing the configuration of 4254 the twice-NAT and the NATFW NSLP being installed at this devices, the 4255 NATFW NSLP must be able to traverse it. The NSLP is probably able to 4256 traverse the twice-NAT, as any other data traffic, but the flow 4257 information stored in the NTLP's MRI will be invalidated through the 4258 translation of source and destination address. The NATFW NSLP 4259 implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP 4260 signaling messages as any other NATFW NSLP node does. For the given 4261 signaling flow, the NATFW NSLP node MUST look up the corresponding IP 4262 address translation and modify the NTLP/NSLP signaling accordingly. 4263 The modification results in an updated MRI with respect to the source 4264 and destination IP addresses. 4266 Intellectual Property Statement 4268 The IETF takes no position regarding the validity or scope of any 4269 Intellectual Property Rights or other rights that might be claimed to 4270 pertain to the implementation or use of the technology described in 4271 this document or the extent to which any license under such rights 4272 might or might not be available; nor does it represent that it has 4273 made any independent effort to identify any such rights. Information 4274 on the procedures with respect to rights in RFC documents can be 4275 found in BCP 78 and BCP 79. 4277 Copies of IPR disclosures made to the IETF Secretariat and any 4278 assurances of licenses to be made available, or the result of an 4279 attempt made to obtain a general license or permission for the use of 4280 such proprietary rights by implementers or users of this 4281 specification can be obtained from the IETF on-line IPR repository at 4282 http://www.ietf.org/ipr. 4284 The IETF invites any interested party to bring to its attention any 4285 copyrights, patents or patent applications, or other proprietary 4286 rights that may cover technology that may be required to implement 4287 this standard. Please address the information to the IETF at 4288 ietf-ipr@ietf.org. 4290 Disclaimer of Validity 4292 This document and the information contained herein are provided on an 4293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4295 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4296 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4297 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4300 Copyright Statement 4302 Copyright (C) The Internet Society (2006). This document is subject 4303 to the rights, licenses and restrictions contained in BCP 78, and 4304 except as set forth therein, the authors retain all their rights. 4306 Acknowledgment 4308 Funding for the RFC Editor function is currently provided by the 4309 Internet Society.