idnits 2.17.1 draft-ietf-nsis-nslp-natfw-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3770. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (January 30, 2008) is 5930 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) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-14 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '2') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-15 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '13') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '14') (Obsoleted by RFC 5389) == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-04 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group M. Stiemerling 3 Internet-Draft NEC 4 Intended status: Standards Track H. Tschofenig 5 Expires: August 2, 2008 Nokia Siemens Networks 6 C. Aoun 8 E. Davies 9 Folly Consulting 10 January 30, 2008 12 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 13 draft-ietf-nsis-nslp-natfw-17.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 2, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 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. For 50 instance, it enables hosts behind NATs to obtain a public reachable 51 address and hosts behind firewalls to receive data traffic. The 52 overall architecture is given by the framework and requirements 53 defined by the Next Steps in Signaling (NSIS) working group. The 54 network 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. Scope and Background . . . . . . . . . . . . . . . . . . . 5 61 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 8 62 1.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 63 1.4. General Scenario for NATFW Traversal . . . . . . . . . . . 11 65 2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 13 66 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13 67 2.2. NAT with two private Networks . . . . . . . . . . . . . . 14 68 2.3. NAT with Private Network on Sender Side . . . . . . . . . 15 69 2.4. NAT with Private Network on Receiver Side Scenario . . . . 15 70 2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . . 16 71 2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 17 72 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18 73 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 19 75 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 20 76 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 20 77 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21 78 3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 21 79 3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 22 80 3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 23 81 3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 25 82 3.2.5. State and Error Maintenance . . . . . . . . . . . . . 25 83 3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 26 84 3.2.7. Classification of RESPONSE Messages . . . . . . . . . 26 85 3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 27 86 3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 28 87 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 28 88 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 31 89 3.6. Authentication, Authorization, and Policy Decisions . . . 32 90 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 33 91 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 33 92 3.7.2. Reserving External Addresses . . . . . . . . . . . . . 36 93 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 43 94 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 44 95 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 46 96 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 47 97 3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 51 98 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 53 99 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 53 101 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 55 102 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 55 103 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 56 104 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 57 105 4.2.2. External Address Object . . . . . . . . . . . . . . . 57 106 4.2.3. Extended Flow Information Object . . . . . . . . . . . 58 107 4.2.4. Information Code Object . . . . . . . . . . . . . . . 59 108 4.2.5. Nonce Object . . . . . . . . . . . . . . . . . . . . . 62 109 4.2.6. Message Sequence Number Object . . . . . . . . . . . . 62 110 4.2.7. Data Terminal Information Object . . . . . . . . . . . 63 111 4.2.8. ICMP Types Object . . . . . . . . . . . . . . . . . . 64 112 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 65 113 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 66 114 4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 66 115 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 67 116 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 67 118 5. Security Considerations . . . . . . . . . . . . . . . . . . . 69 119 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 69 120 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 69 121 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 70 122 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 71 123 5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 72 124 5.2.1. Security Protection between neighboring NATFW NSLP 125 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 72 126 5.2.2. Security Protection between non-neighboring NATFW 127 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 73 129 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 75 131 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 133 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 135 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 136 9.1. Normative References . . . . . . . . . . . . . . . . . . . 79 137 9.2. Informative References . . . . . . . . . . . . . . . . . . 79 139 Appendix A. Selecting Signaling Destination Addresses for 140 EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 81 142 Appendix B. Applicability Statement on Data Receivers behind 143 Firewalls . . . . . . . . . . . . . . . . . . . . . . 82 145 Appendix C. Firewall and NAT Resources . . . . . . . . . . . . . 84 146 C.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 84 147 C.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 84 148 C.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 85 149 C.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 85 151 Appendix D. Protocols Numbers for Testing . . . . . . . . . . . . 87 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 154 Intellectual Property and Copyright Statements . . . . . . . . . . 89 156 1. Introduction 158 1.1. Scope and Background 160 Firewalls and Network Address Translators (NAT) have both been used 161 throughout the Internet for many years, and they will remain present 162 for the foreseeable future. Firewalls are used to protect networks 163 against certain types of attacks from internal networks and the 164 Internet, whereas NATs provide a virtual extension of the IP address 165 space. Both types of devices may be obstacles to some applications, 166 since they only allow traffic created by a limited set of 167 applications to traverse them, typically those that use protocols 168 with relatively predetermined and static properties (e.g., most HTTP 169 traffic, and other client/server applications). Other applications, 170 such as IP telephony and most other peer-to-peer applications, which 171 have more dynamic properties, create traffic that is unable to 172 traverse NATs and firewalls unassisted. In practice, the traffic of 173 many applications cannot traverse autonomous firewalls or NATs, even 174 when they have additional functionality which attempts to restore the 175 transparency of the network. 177 Several solutions to enable applications to traverse such entities 178 have been proposed and are currently in use. Typically, application 179 level gateways (ALG) have been integrated with the firewall or NAT to 180 configure the firewall or NAT dynamically. Another approach is 181 middlebox communication (MIDCOM). In this approach, ALGs external to 182 the firewall or NAT configure the corresponding entity via the MIDCOM 183 protocol [7]. Several other work-around solutions are available, 184 such as STUN [14]. However, all of these approaches introduce other 185 problems that are generally hard to solve, such as dependencies on 186 the type of NAT implementation (full-cone, symmetric, etc), or 187 dependencies on certain network topologies. 189 NAT and firewall (NATFW) signaling shares a property with Quality of 190 Service (QoS) signaling. The signaling of both must reach any device 191 on the data path that is involved in, respectively, NATFW or QoS 192 treatment of data packets. This means, that for both, NATFW and QoS, 193 it is convenient if signaling travels path-coupled, meaning that the 194 signaling messages follow exactly the same path that the data packets 195 take. RSVP [11] is an example of a current QoS signaling protocol 196 that is path-coupled. [19] proposes the use of RSVP as firewall 197 signaling protocol but does not include NATs. 199 This memo defines a path-coupled signaling protocol for NAT and 200 firewall configuration within the framework of NSIS, called the NATFW 201 NSIS Signaling Layer Protocol (NSLP). The general requirements for 202 NSIS are defined in [5] and the general framework of NSIS is outlined 203 in [4]. It introduces the split between an NSIS transport layer and 204 an NSIS signaling layer. The transport of NSLP messages is handled 205 by an NSIS Network Transport Layer Protocol (NTLP, with General 206 Internet Signaling Transport (GIST) [2] being the implementation of 207 the abstract NTLP). The signaling logic for QoS and NATFW signaling 208 is implemented in the different NSLPs. The QoS NSLP is defined in 209 [6]. 211 The NATFW NSLP is designed to request the dynamic configuration of 212 NATs and/or firewalls along the data path. Dynamic configuration 213 includes enabling data flows to traverse these devices without being 214 obstructed, as well as blocking of particular data flows at inbound 215 firewalls. Enabling data flows requires the loading of firewall 216 rules with an action that allows the data flow packets to be 217 forwarded and creating NAT bindings. Blocking of data flows requires 218 the loading of firewalls rules with an action that will deny 219 forwarding of the data flow packets. A simplified example for 220 enabling data flows: A source host sends a NATFW NSLP signaling 221 message towards its data destination. This message follows the data 222 path. Every NATFW NSLP-enabled NAT/firewall along the data path 223 intercepts this message, processes them, and configures itself 224 accordingly. Thereafter, the actual data flow can traverse all these 225 configured firewalls/NATs. 227 It is necessary to distinguish between two different basic scenarios 228 when operating the NATFW NSLP, independent of the type of the 229 middleboxes to be configured. 231 1. Both, data sender and data receiver, are NSIS NATFW NSLP aware. 232 This includes the cases where the data sender is logically 233 decomposed from the initiator of the NSIS signaling (the so- 234 called NSIS initiator) or the data receiver logically decomposed 235 from the receiver of the NSIS signaling (the so-called NSIS 236 receiver), but both sides support NSIS. This scenario assumes 237 deployment of NSIS all over the Internet, or at least at all NATs 238 and firewalls. This scenario is used as base assumption, if not 239 otherwise noted. 241 2. Only one end host or region of the network is NSIS NATFW NSLP 242 aware, either data receiver or data sender. This scenario is 243 referred to as proxy mode. 245 The NATFW NSLP has two basic signaling messages which are sufficient 246 to cope with the various possible scenarios likely to be encountered 247 before and after widespread deployment of NSIS: 249 CREATE message: Send by the data sender for configuring a path 250 outbound from a data sender to a data receiver. 252 EXTERNAL message: Used by data receiver to locate inbound NATs/ 253 firewalls and prime them to expect outbound signaling and at NATs 254 to pre-allocate a public address. This is used for data receivers 255 behind these devices to enable their reachability. 257 CREATE and EXTERNAL messages are sent by the NSIS initiator (NI) 258 towards the NSIS responder (NR). Both type of messages are 259 acknowledged by a subsequent RESPONSE message. This RESPONSE message 260 is generated by the NR if the requested configuration can be 261 established, otherwise the NR or any of the NSIS forwarders (NFs) can 262 also generate such a message if an error occurs. NFs and the NR can 263 also generate asynchronous messages to notify the NI, the so called 264 NOTIFY messages. 266 If the data receiver resides in a private addressing realm or behind 267 a firewall, and needs to preconfigure the edge-NAT/edge-firewall to 268 provide a (publicly) reachable address for use by the data sender, a 269 combination of EXTERNAL and CREATE messages is used. 271 During the introduction of NSIS, it is likely that one or the other 272 of the data sender and receiver will not be NSIS aware. In these 273 cases, the NATFW NSLP can utilize NSIS aware middleboxes on the path 274 between the data sender and data receiver to provide proxy NATFW NSLP 275 services (i.e., the proxy mode). Typically, these boxes will be at 276 the boundaries of the realms in which the end hosts are located. 278 The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in 279 NSIS entities. NTLP state allows signaling messages to travel in the 280 forward (outbound) and the reverse (inbound) direction along the path 281 between a NAT/firewall NSLP sender and a corresponding receiver. 282 This state is managed using a soft-state mechanism, i.e., it expires 283 unless it is refreshed from time to time. The NAT bindings and 284 firewall rules being installed during the state setup are bound to 285 the particular signaling session. However, the exact local 286 implementation of the NAT bindings and firewall rules are NAT/ 287 firewall specific and it is out of scope of this memo. 289 This memo is structured as follows. Section 2 describes the network 290 environment for NATFW NSLP signaling. Section 3 defines the NATFW 291 signaling protocol and Section 4 defines the message components and 292 the overall messages used in the protocol. The remaining parts of 293 the main body of the document cover security considerations 294 Section 5, IAB considerations on UNilateral Self-Address Fixing 295 (UNSAF) [12] in Section 6 and IANA considerations in Section 7. 296 Please note that readers familiar with firewalls and NATs and their 297 possible location within networks can safely skip Section 2. 299 1.2. Terminology and Abbreviations 301 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 302 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 303 document are to be interpreted as described in [1]. 305 This document uses a number of terms defined in [5] and [4]. The 306 following additional terms are used: 308 o Policy rule: A policy rule is "a basic building block of a policy- 309 based system. It is the binding of a set of actions to a set of 310 conditions - where the conditions are evaluated to determine 311 whether the actions are performed" [15]. In the context of NSIS 312 NATFW NSLP, the conditions are the specification of a set of 313 packets to which the rule is applied. The set of actions always 314 contains just a single element per rule, and is limited to either 315 action "deny" or action "allow". 317 o Reserved policy rule: A policy rule stored at NATs or firewalls 318 for activation by a later, different signaling exchange. This 319 type of policy rule is kept in the NATFW NSLP and is not loaded 320 into the firewall or NAT engine, i.e., it does not affect the data 321 flow handling. 323 o Installed policy rule: A policy rule in operation at NATs or 324 firewalls. This type of rule is kept in the NATFW NSLP and is 325 loaded into the firewall or NAT engine, i.e., it is affecting the 326 data flow. 328 o Remembered policy rule: A policy rule stored at NATs and firewalls 329 for immediate use, as soon as the signaling exchange is 330 successfully completed. 332 o Firewall: A packet filtering device that matches packets against a 333 set of policy rules and applies the actions. 335 o Network Address Translator: Network Address Translation is a 336 method by which IP addresses are mapped from one IP address realm 337 to another, in an attempt to provide transparent routing between 338 hosts (see [9]). Network Address Translators are devices that 339 perform this work by modifying packets passing through them. 341 o Data Receiver (DR): The node in the network that is receiving the 342 data packets of a flow. 344 o Data Sender (DS): The node in the network that is sending the data 345 packets of a flow. 347 o NATFW NSLP peer or peer: An NSIS NATFW NSLP node with which an 348 NTLP adjacency has been created as defined in [2]. 350 o NATFW NSLP signaling session or signaling session: A signaling 351 session defines an association between the NI, NFs, and the NR 352 related to a data flow. All the NATFW NSLP peers on the path, 353 including the NI and the NR, use the same identifier to refer to 354 the state stored for the association. The same NI and NR may have 355 more than one signaling session active at any time. The state for 356 NATFW NSLP consists of NSLP state and associated policy rules at a 357 middlebox. 359 o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP 360 address which is reachable from the public Internet. 362 o Edge-firewall: An edge-firewall is a firewall device that is 363 located on the border line of an administrative domain. 365 o Public Network: "A Global or Public Network is an address realm 366 with unique network addresses assigned by Internet Assigned 367 Numbers Authority (IANA) or an equivalent address registry. This 368 network is also referred as external network during NAT 369 discussions" [9]. 371 o Private/Local Network: "A private network is an address realm 372 independent of external network addresses. Private network may 373 also be referred alternately as Local Network. Transparent 374 routing between hosts in private realm and external realm is 375 facilitated by a NAT router" [9]. 377 o Public/Global IP address: An IP address located in the public 378 network according to Section 2.7 of [9]. 380 o Private/Local IP address: An IP address located in the private 381 network according to Section 2.8 of [9]. 383 o Signaling Destination Address (SDA): An IP address generally taken 384 from the public/global IP address range, although, the SDA may in 385 certain circumstances be part of the private/local IP address 386 range. This address is used in EXTERNAL signaling message 387 exchanges, if the data receiver's IP address is unknown. 389 1.3. Middleboxes 391 The term middlebox covers a range of devices and is well-defined in 392 [10]: "A middlebox is defined as any intermediate device performing 393 functions other than the normal, standard functions of an IP router 394 on the datagram path between source host and a destination host". As 395 such, middleboxes fall into a number of categories with a wide range 396 of functionality, not all of which is pertinent to the NATFW NSLP. 397 Middlebox categories in the scope of this memo are firewalls that 398 filter data packets against a set of filter rules, and NATs that 399 translate packet addresses from one address realm to another address 400 realm. Other categories of middleboxes, such as QoS traffic shapers, 401 are out of scope of this memo. 403 The term NAT used in this document is a placeholder for a range of 404 different NAT flavors. We consider the following types of NATs: 406 o Traditional NAT (basic NAT and NAPT) 408 o Bi-directional NAT 410 o Twice-NAT 412 o Multihomed NAT 414 For definitions and a detailed discussion about the characteristics 415 of each NAT type please see [9]. 417 All types of middleboxes under consideration here, use policy rules 418 to make a decision on data packet treatment. Policy rules consist of 419 a flow identifier which selects the packets to which the policy 420 applies and an associated action; data packets matching the flow 421 identifier are subjected to the policy rule action. A typical flow 422 identifier is the 5-tuple selector which matches the following fields 423 of a packet to configured values: 425 o Source and destination IP addresses 427 o Transport protocol number 429 o Transport source and destination port numbers 431 Actions for firewalls are usually one or more of: 433 o Allow: forward data packet 435 o Deny: block data packet and discard it 437 o Other actions such as logging, diverting, duplicating, etc 439 Actions for NATs include (amongst many others): 441 o Change source IP address and transport port number to a globally 442 routable IP address and associated port number. 444 o Change destination IP address and transport port number to a 445 private IP address and associated port number. 447 It should be noted that a middlebox may contain two logical 448 representations of the policy rule. The policy rule has a 449 representation within the NATFW NSLP, comprising the message routing 450 information (MRI) of the NTLP and NSLP information (such as the rule 451 action). The other representation is the implementation of the NATFW 452 NSLP policy rule within the NAT and firewall engine of the particular 453 device. Refer to Appendix C for further details. 455 1.4. General Scenario for NATFW Traversal 457 The purpose of NSIS NATFW signaling is to enable communication 458 between endpoints across networks, even in the presence of NAT and 459 firewall middleboxes that have not been specially engineered to 460 facilitate communication with the application protocols used. This 461 removes the need to create and maintain application layer gateways 462 for specific protocols that have been commonly used to provide 463 transparency in previous generations of NAT and firewall middleboxes. 464 It is assumed that these middleboxes will be statically configured in 465 such a way that NSIS NATFW signaling messages themselves are allowed 466 to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP 467 signaling is used to dynamically install additional policy rules in 468 all NATFW middleboxes along the data path that will allow 469 transmission of the application data flow(s). Firewalls are 470 configured to forward data packets matching the policy rule provided 471 by the NSLP signaling. NATs are configured to translate data packets 472 matching the policy rule provided by the NSLP signaling. An 473 additional capability, that is an exception to the primary goal of 474 NSIS NATFW signaling, is that the NATFW nodes can request blocking of 475 particular data flows instead of enabling these flows at inbound 476 firewalls. 478 The basic high-level picture of NSIS usage is that end hosts are 479 located behind middleboxes, meaning that there is at least one 480 middlebox on the data path from the end host in a private network to 481 the external network (NATFW in Figure 1). Applications located at 482 these end hosts try to establish communication with corresponding 483 applications on other such end hosts. They trigger the NSIS entity 484 at the local host to control provisioning for middlebox traversal 485 along the prospective data path (e.g., via an API call). The NSIS 486 entity in turn uses NSIS NATFW NSLP signaling to establish policy 487 rules along the data path, allowing the data to travel from the 488 sender to the receiver unobstructed. 490 Application Application Server (0, 1, or more) Application 492 +----+ +----+ +----+ 493 | +------------------------+ +------------------------+ | 494 +-+--+ +----+ +-+--+ 495 | | 496 | NSIS Entities NSIS Entities | 497 +-+--+ +----+ +-----+ +-+--+ 498 | +--------+ +----------------------------+ +-----+ | 499 +-+--+ +-+--+ +--+--+ +-+--+ 500 | | ------ | | 501 | | //// \\\\\ | | 502 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 503 | | | | | Internet | | | | | 504 | +--------+ +-----+ +----+ +-----+ | 505 +----+ +----+ |\ | +----+ +----+ 506 \\\\ ///// 507 sender NATFW (1+) ------ NATFW (1+) receiver 509 Note that 1+ refers to one or more NATFW nodes. 511 Figure 1: Generic View of NSIS with NATs and/or firewalls 513 For end-to-end NATFW signaling, it is necessary that each firewall 514 and each NAT along the path between the data sender and the data 515 receiver implements the NSIS NATFW NSLP. There might be several NATs 516 and FWs in various possible combinations on a path between two hosts. 517 Section 2 presents a number of likely scenarios with different 518 combinations of NATs and firewalls. However, the scenarios given in 519 the following sections are not limiting the scope of the NATFW NSLP 520 to them only, but they are examples only. 522 2. Network Deployment Scenarios using the NATFW NSLP 524 This section introduces several scenarios for middlebox placement 525 within IP networks. Middleboxes are typically found at various 526 different locations, including at enterprise network borders, within 527 enterprise networks, as mobile phone network gateways, etc. Usually, 528 middleboxes are placed more towards the edge of networks than in 529 network cores. Firewalls and NATs may be found at these locations 530 either alone, or they may be combined; other categories of 531 middleboxes may also be found at such locations, possibly combined 532 with the NATs and/or firewalls. 534 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 535 regular data path to the NSIS responder (NR). On the data path, 536 NATFW NSLP signaling messages reach different NSIS nodes that 537 implement the NATFW NSLP. Each NATFW NSLP node processes the 538 signaling messages according to Section 3 and, if necessary, installs 539 policy rules for subsequent data packets. 541 Each of the following sub-sections introduces a different scenario 542 for a different set of middleboxes and their ordering within the 543 topology. It is assumed that each middlebox implements the NSIS 544 NATFW NSLP signaling protocol. 546 2.1. Firewall Traversal 548 This section describes a scenario with firewalls only; NATs are not 549 involved. Each end host is behind a firewall. The firewalls are 550 connected via the public Internet. Figure 2 shows the topology. The 551 part labeled "public" is the Internet connecting both firewalls. 553 +----+ //----\\ +----+ 554 NI -----| FW |---| |------| FW |--- NR 555 +----+ \\----// +----+ 557 private public private 559 FW: Firewall 560 NI: NSIS Initiator 561 NR: NSIS Responder 563 Figure 2: Firewall Traversal Scenario 565 Each firewall on the data path must provide traversal service for 566 NATFW NSLP in order to permit the NSIS message to reach the other end 567 host. All firewalls process NSIS signaling and establish appropriate 568 policy rules, so that the required data packet flow can traverse 569 them. 571 There are several very different ways to place firewalls in a network 572 topology. To distinguish firewalls located at network borders, such 573 as administrative domains, from others located internally, the term 574 edge-firewall is used. A similar distinction can be made for NATs, 575 with an edge-NAT fulfilling the equivalent role. 577 2.2. NAT with two private Networks 579 Figure 3 shows a scenario with NATs at both ends of the network. 580 Therefore, each application instance, the NSIS initiator and the NSIS 581 responder, are behind NATs. The outermost NAT, known as the edge-NAT 582 (MB2 and MB3), at each side is connected to the public Internet. The 583 NATs are generically labeled as MBX (for middlebox No. X), since 584 those devices certainly implement NAT functionality, but can 585 implement firewall functionality as well. 587 Only two middleboxes MB are shown in Figure 3 at each side, but in 588 general, any number of MBs on each side must be considered. 590 +----+ +----+ //----\\ +----+ +----+ 591 NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR 592 +----+ +----+ \\----// +----+ +----+ 594 private public private 596 MB: Middlebox 597 NI: NSIS Initiator 598 NR: NSIS Responder 600 Figure 3: NAT with two Private Networks Scenario 602 Signaling traffic from NI to NR has to traverse all the middleboxes 603 on the path (MB1 to MB4, in this order), and all the middleboxes must 604 be configured properly to allow NSIS signaling to traverse them. The 605 NATFW signaling must configure all middleboxes and consider any 606 address translation that will result from this configuration in 607 further signaling. The sender (NI) has to know the IP address of the 608 receiver (NR) in advance, otherwise it will not be possible to send 609 any NSIS signaling messages towards the responder. Note that this IP 610 address is not the private IP address of the responder but the NAT's 611 public IP address (here MB3's IP address). Instead a NAT binding 612 (including a public IP address) has to be previously installed on the 613 NAT MB3. This NAT binding subsequently allows packets reaching the 614 NAT to be forwarded to the receiver within the private address realm. 616 The receiver might have a number of ways to learn its public IP 617 address and port number (including the NATFW NSLP) and might need to 618 signal this information to the sender using the application level 619 signaling protocol. 621 2.3. NAT with Private Network on Sender Side 623 This scenario shows an application instance at the sending node that 624 is behind one or more NATs (shown as generic MB, see discussion in 625 Section 2.2). The receiver is located in the public Internet. 627 +----+ +----+ //----\\ 628 NI --| MB |-----| MB |---| |--- NR 629 +----+ +----+ \\----// 631 private public 633 MB: Middlebox 634 NI: NSIS Initiator 635 NR: NSIS Responder 637 Figure 4: NAT with Private Network on Sender Side 639 The traffic from NI to NR has to traverse middleboxes only on the 640 sender's side. The receiver has a public IP address. The NI sends 641 its signaling message directly to the address of the NSIS responder. 642 Middleboxes along the path intercept the signaling messages and 643 configure the a accordingly. 645 The data sender does not necessarily know whether the receiver is 646 behind a NAT or not, hence, it is the receiving side that has to 647 detect whether itself is behind a NAT or not. 649 2.4. NAT with Private Network on Receiver Side Scenario 651 The application instance receiving data is behind one or more NATs 652 shown as MB (see discussion in Section 2.2). 654 //----\\ +----+ +----+ 655 NI ---| |---| MB |-----| MB |--- NR 656 \\----// +----+ +----+ 658 public private 660 MB: Middlebox 661 NI: NSIS Initiator 662 NR: NSIS Responder 664 Figure 5: NAT with Private Network on Receiver Scenario 666 Initially, the NSIS responder must determine its publicly reachable 667 IP address at the external middlebox and notify the NSIS initiator 668 about this address. One possibility is that an application level 669 protocol is used, meaning that the public IP address is signaled via 670 this protocol to the NI. Afterwards the NI can start its signaling 671 towards the NR and therefore establish the path via the middleboxes 672 in the receiver side private network. 674 This scenario describes the use case for the EXTERNAL message of the 675 NATFW NSLP. 677 2.5. Both End Hosts behind twice-NATs 679 This is a special case, where the main problem arises from the need 680 to detect that both end hosts are logically within the same address 681 space, but are also in two partitions of the address realm on either 682 side of a twice-NAT (see [9] for a discussion of twice-NAT 683 functionality). 685 Sender and receiver are both within a single private address realm 686 but the two partitions potentially have overlapping IP address 687 ranges. Figure 6 shows the arrangement of NATs. 689 public 691 +----+ +----+ //----\\ 692 NI --| MB |--+--| MB |---| | 693 +----+ | +----+ \\----// 694 | 695 | +----+ 696 +--| MB |------------ NR 697 +----+ 699 private 701 MB: Middlebox 702 NI: NSIS Initiator 703 NR: NSIS Responder 705 Figure 6: NAT to Public, Sender and Receiver on either side of a 706 twice-NAT Scenario 708 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 709 addresses and port numbers on both sides, meaning the mapping of 710 source and destination address at the private and public interfaces. 712 This scenario requires the assistance of application level entities, 713 such as a DNS server. The application level entities must handle 714 requests that are based on symbolic names, and configure the 715 middleboxes so that data packets are correctly forwarded from NI to 716 NR. The configuration of those middleboxes may require other 717 middlebox communication protocols, such as MIDCOM [7]. NSIS 718 signaling is not required in the twice-NAT only case, since 719 middleboxes of the twice-NAT type are normally configured by other 720 means. Nevertheless, NSIS signaling might be useful when there are 721 also firewalls on the path. In this case NSIS will not configure any 722 policy rule at twice-NATs, but will configure policy rules at the 723 firewalls on the path. The NSIS signaling protocol must be at least 724 robust enough to survive this scenario. This requires that twice- 725 NATs must implement the NATFW NSLP also and participate in NATFW 726 signaling sessions but they do not change the configuration of the 727 NAT, i.e., they only read the address mapping information out of the 728 NAT and translate the Message Routing Information (MRI, [2]) within 729 the NSLP and NTLP accordingly. For more information see Appendix C.4 731 2.6. Both End Hosts Behind Same NAT 733 When NSIS initiator and NSIS responder are behind the same NAT (thus 734 being in the same address realm, see Figure 7), they are most likely 735 not aware of this fact. As in Section 2.4 the NSIS responder must 736 determine its public IP address in advance and transfer it to the 737 NSIS initiator. Afterwards, the NSIS initiator can start sending the 738 signaling messages to the responder's public IP address. During this 739 process, a public IP address will be allocated for the NSIS initiator 740 at the same middlebox as for the responder. Now, the NSIS signaling 741 and the subsequent data packets will traverse the NAT twice: from 742 initiator to public IP address of responder (first time) and from 743 public IP address of responder to responder (second time). 745 NI public 746 \ +----+ //----\\ 747 +-| MB |----| | 748 / +----+ \\----// 749 NR 750 private 752 MB: Middlebox 753 NI: NSIS Initiator 754 NR: NSIS Responder 756 Figure 7: NAT to Public, Both Hosts Behind Same NAT 758 2.7. Multihomed Network with NAT 760 The previous sub-sections sketched network topologies where several 761 NATs and/or firewalls are ordered sequentially on the path. This 762 section describes a multihomed scenario with two NATs placed on 763 alternative paths to the public network. 765 +----+ //---\\ 766 NI -------| MB |---| | 767 \ +----+ \\-+-// 768 \ | 769 \ +----- NR 770 \ | 771 \ +----+ //-+-\\ 772 --| MB |---| | 773 +----+ \\---// 775 private public 777 MB: Middlebox 778 NI: NSIS Initiator 779 NR: NSIS Responder 780 Figure 8: Multihomed Network with Two NATs 782 Depending on the destination, either one or the other middlebox is 783 used for the data flow. Which middlebox is used, depends on local 784 policy or routing decisions. NATFW NSLP must be able to handle this 785 situation properly, see Section 3.7.2 for an extended discussion of 786 this topic with respect to NATs. 788 2.8. Multihomed Network with Firewall 790 This section describes a multihomed scenario with two firewalls 791 placed on alternative paths to the public network (Figure 9). The 792 routing in the private and public network decides which firewall is 793 being taken for data flows. Depending on the data flow's direction, 794 either outbound or inbound, a different firewall could be traversed. 795 This is a challenge for the EXTERNAL message of the NATFW NSLP where 796 the NSIS responder is located behind these firewalls within the 797 private network. The EXTERNAL message is used to block a particular 798 data flow on an inbound firewall. NSIS must route the EXTERNAL 799 message inbound from NR to NI probably without knowing which path the 800 data traffic will take from NI to NR (see also Appendix B). 802 +----+ 803 NR -------| FW |\ 804 \ +----+ \ //---\\ 805 \ -| |-- NI 806 \ \\---// 807 \ +----+ | 808 --| FW |-------+ 809 +----+ 810 private 812 private public 814 FW: Firewall 815 NI: NSIS Initiator 816 NR: NSIS Responder 818 Figure 9: Multihomed Network with two firewalls 820 3. Protocol Description 822 This section defines messages, objects, and protocol semantics for 823 the NATFW NSLP. 825 3.1. Policy Rules 827 Policy rules, bound to a NATFW NSLP signaling session, are the 828 building blocks of middlebox devices considered in the NATFW NSLP. 829 For firewalls the policy rule usually consists of a 5-tuple and an 830 action such as allow or deny. The information contained in the tuple 831 includes source/destination addresses, transport protocol and source/ 832 destination port numbers. For NATs the policy rule consists of the 833 action 'translate this address' and further mapping information, that 834 might be, in the simplest case, internal IP address and external IP 835 address. 837 The NATFW NSLP carries, in conjunction with the NTLP's Message 838 Routing Information (MRI), the policy rules to be installed at NATFW 839 peers. This policy rule is an abstraction with respect to the real 840 policy rule to be installed at the respective firewall or NAT. It 841 conveys the initiator's request and must be mapped to the possible 842 configuration on the particular used NAT and/or firewall in use. For 843 pure firewalls one or more filter rules must be created and for pure 844 NATs one or more NAT bindings must be created. In mixed firewall and 845 NAT boxes, the policy rule must be mapped to filter rules and 846 bindings observing the ordering of the firewall and NAT engine. 847 Depending on the ordering, NAT before firewall or vice versa, the 848 firewall rules must carry public or private IP addresses. However, 849 the exact mapping depends on the implementation of the firewall or 850 NAT which is possibly different for each implementation. 852 The policy rule at the NATFW NSLP level comprises the message routing 853 information (MRI) part, carried in the NTLP, and the information 854 available in the NATFW NSLP. The information provided by the NSLP is 855 stored in the 'extend flow information' (NATFW_EFI) and 'data 856 terminal information' (NATFW_DTINFO) objects, and the message type. 857 Additional information, such as the external IP address and port 858 number, stored in the NAT or firewall, will be used as well. The MRI 859 carries the filter part of the NAT/firewall-level policy rule that is 860 to be installed. 862 The NATFW NSLP specifies two actions for the policy rules: deny and 863 allow. A policy rule with action set to deny will result in all 864 packets matching this rule to be dropped. A policy rule with action 865 set to allow will result in all packets matching this rule to be 866 forwarded. 868 3.2. Basic Protocol Overview 870 The NSIS NATFW NSLP is carried over the General Internet Signaling 871 Transport (GIST, the implementation of the NTLP) defined in [2]. 872 NATFW NSLP messages are initiated by the NSIS initiator (NI), handled 873 by NSIS forwarders (NF) and received by the NSIS responder (NR). It 874 is required that at least NI and NR implement this NSLP, intermediate 875 NFs only implement this NSLP when they provide relevant middlebox 876 functions. NSIS forwarders that do not have any NATFW NSLP functions 877 just forward these packets as they have no interest in them. 879 3.2.1. Signaling for Outbound Traffic 881 A Data Sender (DS), intending to send data to a Data Receiver (DR) 882 has to start NATFW NSLP signaling. This causes the NI associated 883 with the data sender (DS) to launch NSLP signaling towards the 884 address of data receiver (DR) (see Figure 10). Although it is 885 expected that the DS and the NATFW NSLP NI will usually reside on the 886 same host, this specification does not rule out scenarios where the 887 DS and NI reside on different hosts, the so-called proxy mode (see 888 Section 3.7.6.) 890 +-------+ +-------+ +-------+ +-------+ 891 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 892 | |--->| NF1 |--->| NF2 |--->| | 893 +-------+ +-------+ +-------+ +-------+ 895 ========================================> 896 Data Traffic Direction (outbound) 898 ---> : NATFW NSLP request signaling 899 ~~~> : NATFW NSLP response signaling 900 DS/NI : Data sender and NSIS initiator 901 DR/NR : Data receiver and NSIS responder 902 MB1 : Middlebox 1 and NSIS forwarder 1 903 MB2 : Middlebox 2 and NSIS forwarder 2 905 Figure 10: General NSIS signaling 907 The following list shows the normal sequence of NSLP events without 908 detailing the interaction with the NTLP and the interactions on the 909 the NTLP level. 911 o NSIS initiators generate NATFW NSLP CREATE/EXTERNAL messages and 912 send these towards the NSIS responder. This CREATE/EXTERNAL 913 message is the initial message which creates a new NATFW NSLP 914 signaling session. The NI and the NR will most likely already 915 share an application session before they start the NATFW NSLP 916 signaling session. Note well the difference between both 917 sessions. 919 o NSLP CREATE/EXTERNAL messages are processed each time a NF with 920 NATFW NSLP support is traversed. Each NF that is intercepting a 921 CREATE/EXTERNAL message and is accepting it for further treatment 922 is joining the particular NATFW NSLP signaling session. These 923 nodes process the message, check local policies for authorization 924 and authentication, possibly create policy rules, and forward the 925 signaling message to the next NSIS node. The request message is 926 forwarded until it reaches the NSIS responder. 928 o NSIS responders will check received messages and process them if 929 applicable. NSIS responders generate RESPONSE messages and send 930 them hop-by-hop back to the NI via the same chain of NFs 931 (traversal of the same NF chain is guaranteed through the 932 established reverse message routing state in the NTLP). The NR is 933 also joining the NATFW NSLP signaling session if the CREATE/ 934 EXTERNAL message is accepted. 936 o The RESPONSE message is processed at each NF that has been 937 included in the prior NATFW NSLP signaling session setup. 939 o If the NI has received a successful RESPONSE message and if the 940 signaling NATFW NSLP session started with a CREATE message, the 941 data sender can start sending its data flow to the data receiver. 942 If the NI has received a successful RESPONSE message and if the 943 signaling NATFW NSLP session started with a EXTERNAL message, the 944 data receiver is ready to receive further CREATE messages. 946 Because NATFW NSLP signaling follows the data path from DS to DR, 947 this immediately enables communication between both hosts for 948 scenarios with only firewalls on the data path or NATs on the sender 949 side. For scenarios with NATs on the receiver side certain problems 950 arise, as described in Section 2.4. 952 3.2.2. Signaling for Inbound Traffic 954 When the NR and the NI are located in different address realms and 955 the NR is located behind a NAT, the NI cannot signal to the NR 956 address directly. The DR/NR is not reachable from other NIs using 957 the private address of the NR and thus NATFW signaling messages 958 cannot be sent to the NR/DR's address. Therefore, the NR must first 959 obtain a NAT binding that provides an address that is reachable for 960 the NI. Once the NR has acquired a public IP address, it forwards 961 this information to the DS via a separate protocol. This application 962 layer signaling, which is out of scope of the NATFW NSLP, may involve 963 third parties that assist in exchanging these messages. 965 The same holds partially true for NRs located behind firewalls that 966 block all traffic by default. In this case, NR must tell its inbound 967 firewalls of inbound NATFW NSLP signaling and corresponding data 968 traffic. Once the NR has informed the inbound firewalls, it can 969 start its application level signaling to initiate communication with 970 the NI. This mechanism can be used by machines hosting services 971 behind firewalls as well. In this case, the NR informs the inbound 972 firewalls as described, but does not need to communicate this to the 973 NIs. 975 NATFW NSLP signaling supports this scenario by using the EXTERNAL 976 message 978 1. The DR acquires a public address by signaling on the reverse path 979 (DR towards DS) and thus making itself available to other hosts. 980 This process of acquiring public addresses is called reservation. 981 During this process the DR reserves publicly reachable addresses 982 and ports suitable for further usage in application level 983 signaling and the publicly reachable address for further NATFW 984 NSLP signaling. However, the data traffic will not be allowed to 985 use this address/port initially (see next point). In the process 986 of reservation the DR becomes the NI for the messages necessary 987 to obtain the publicly reachable IP address, i.e., the NI for 988 this specific NATFW NSLP signaling session. 990 2. Now on the side of DS, the NI creates a new NATFW NSLP signaling 991 session and signals directly to the public IP address of DR. 992 This public IP address is used as NR's address, as the NI would 993 do if there is no NAT in between, and creates policy rules at 994 middleboxes. Note, that the reservation will only allow 995 forwarding of signaling messages, but not data flow packets. 996 Policy rules allowing forwarding of data flow packets set up by 997 the prior EXTERNAL message signaling will be activated when the 998 signaling from NI towards NR is confirmed with a positive 999 RESPONSE message. The EXTERNAL message is described in 1000 Section 3.7.2. 1002 3.2.3. Signaling for Proxy Mode 1003 administrative domain 1004 ----------------------------------\ 1005 | 1006 +-------+ +-------+ +-------+ | +-------+ 1007 | DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR | 1008 | |--->| NF1 |--->| NR | | | | 1009 +-------+ +-------+ +-------+ | +-------+ 1010 | 1011 ----------------------------------/ 1013 ========================================> 1014 Data Traffic Direction (outbound) 1016 ---> : NATFW NSLP request signaling 1017 ~~~> : NATFW NSLP response signaling 1018 DS/NI : Data sender and NSIS initiator 1019 DR/NR : Data receiver and NSIS responder 1020 MB1 : Middlebox 1 and NSIS forwarder 1 1021 MB2 : Middlebox 2 and NSIS responder 1023 Figure 11: proxy mode signaling for data sender 1025 The above usage assumes that both ends of a communication support 1026 NSIS, but fails when NSIS is only deployed at one end of the path. 1027 In this case only one of the sending Figure 11 or receiving Figure 12 1028 side is NSIS aware and not both at the same time. NATFW NSLP 1029 supports both scenarios (i.e., either the DS or DR do not support 1030 NSIS) by using a proxy mode, as described in Section 3.7.6 1031 administrative domain 1032 / ---------------------------------- 1033 | 1034 +-------+ | +-------+ +-------+ +-------+ 1035 | DS | | | MB2/ |~~~>| MB1/ |~~~>| DR | 1036 | | | | NR |<---| NF1 |<---| | 1037 +-------+ | +-------+ +-------+ +-------+ 1038 | 1039 \---------------------------------- 1041 ========================================> 1042 Data Traffic Direction (inbound) 1044 ---> : NATFW NSLP request signaling 1045 ~~~> : NATFW NSLP response signaling 1046 DS/NI : Data sender and NSIS initiator 1047 DR/NR : Data receiver and NSIS responder 1048 MB1 : Middlebox 1 and NSIS forwarder 1 1049 MB2 : Middlebox 2 and NSIS responder 1051 Figure 12: proxy mode signaling for data receiver 1053 3.2.4. Blocking Traffic 1055 The basic functionality of the NATFW NSLP provides for opening 1056 firewall pin holes and creating NAT bindings to enable data flows to 1057 traverse these devices. Firewalls are normally expected to work on a 1058 'deny-all' policy, meaning that traffic not explicitly matching any 1059 firewall filter rule will be blocked. Similarly, the normal behavior 1060 of NATs is to block all traffic that does not match any already 1061 configured/installed binding or NATFW NSLP session. However, some 1062 scenarios require support of firewalls having 'allow-all' policies, 1063 allowing data traffic to traverse the firewall unless it is blocked 1064 explicitly. Data receivers can utilize NATFW NSLP's EXTERNAL message 1065 with action set to 'deny' to install policy rules at inbound 1066 firewalls to block unwanted traffic. 1068 3.2.5. State and Error Maintenance 1070 The protocol works on a soft-state basis, meaning that whatever state 1071 is installed or reserved on a middlebox will expire, and thus be de- 1072 installed or forgotten after a certain period of time. To prevent 1073 premature removal of state that is needed for ongoing communication, 1074 the NATFW NI involved will have to specifically request a NATFW NSLP 1075 signaling session extension. An explicit NATFW NSLP state deletion 1076 capability is also provided by the protocol. 1078 If the actions requested by a NATFW NSLP message cannot be carried 1079 out, NFs and the NR must return a failure, such that appropriate 1080 actions can be taken. They can do this either during a the request 1081 message handling (synchronously) by sending an error RESPONSE 1082 message, or at any time (asynchronously) by sending a NOTIFY 1083 notification message. 1085 The next sections define the NATFW NSLP message types and formats, 1086 protocol operations, and policy rule operations. 1088 3.2.6. Message Types 1090 The protocol uses four messages types: 1092 o CREATE: a request message used for creating, changing, refreshing, 1093 and deleting NATFW NSLP signaling sessions, i.e., open the data 1094 path from DS to DR. 1096 o EXTERNAL: a request message used for reserving, changing, 1097 refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions. 1098 EXTERNAL messages are forwarded to the edge-NAT or edge-firewall 1099 and allow inbound CREATE messages to be forwarded to the NR. 1100 Additionally, EXTERNAL messages reserve an external address and, 1101 if applicable, port number at an edge-NAT. 1103 o NOTIFY: an asynchronous message used by NATFW peers to alert other 1104 NATFW peers about specific events (especially failures). 1106 o RESPONSE: used as a response to CREATE and EXTERNAL request 1107 messages. 1109 3.2.7. Classification of RESPONSE Messages 1111 RESPONSE messages will be generated synchronously to CREATE and 1112 EXTERNAL messages by NSIS Forwarders and Responders to report success 1113 or failure of operations or some information relating to the NATFW 1114 NSLP signaling session or a node. RESPONSE messages MUST NOT be 1115 generated for any other message, such as NOTIFY and RESPONSE. 1117 All RESPONSE messages MUST carry a NATFW_INFO object which contains a 1118 severity class code and a response code (see Section 4.2.4). This 1119 section defines terms for groups of RESPONSE messages depending on 1120 the severity class. 1122 o Successful RESPONSE: Messages carrying NATFW_INFO with severity 1123 class 'Success' (0x2). 1125 o Informational RESPONSE: Messages carrying NATFW_INFO with severity 1126 class 'Informational' (0x1) (only used with NOTIFY messages). 1128 o Error RESPONSE: Messages carrying NATFW_INFO with severity class 1129 other than 'Success' or 'Informational'. 1131 3.2.8. NATFW NSLP Signaling Sessions 1133 A NATFW NSLP signaling session defines an association between the NI, 1134 NFs, and the NR related to a data flow. This association is created 1135 when the initial CREATE or EXTERNAL message is successfully received 1136 at the NFs or the NR. There is signaling NATFW NSLP session state 1137 stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP 1138 signaling session state for the NATFW NSLP comprises NSLP state and 1139 the associated policy rules at a middlebox. 1141 The NATFW NSLP signaling session is identified by the session ID 1142 (plus other information at the NTLP level). The session ID is 1143 generated by the NI before the initial CREATE or EXTERNAL message is 1144 sent. The value of the session ID MUST generated in a random way, 1145 i.e., the output MUST NOT be easily guessable by third parties. The 1146 session ID is not stored in any NATFW NSLP message but passed on to 1147 the NTLP. 1149 A NATFW NSLP signaling session can conceptually be in different 1150 states, implementations may use other or even more states. The 1151 signaling session can have these states at a node: 1153 o Pending: The NATFW NSLP signaling session has been created and the 1154 node is waiting for a RESPONSE message to the CREATE or EXTERNAL 1155 message. A NATFW NSLP signaling session in state 'Pending' MUST 1156 be marked as 'Dead' if no corresponding RESPONSE message has been 1157 received within the time of the locally granted NATFW NSLP 1158 signaling session lifetime of the forwarded CREATE or EXTERNAL 1159 message (as described in Section 3.4). 1161 o Established: The NATFW NSLP signaling session is established, i.e, 1162 the signaling has been successfully performed and the lifetime of 1163 NATFW NSLP signaling session is counted from now on. A NATFW NSLP 1164 signaling session in state 'Established' MUST be marked as 'Dead' 1165 if no refresh message has been received within the time of the 1166 locally granted NATFW NSLP signaling session lifetime of the 1167 RESPONSE message (as described in Section 3.4). 1169 o Dead: Either the NATFW NSLP signaling session is timed out or the 1170 node has received an error RESPONSE message for the NATFW NSLP 1171 signaling session and the NATFW NSLP signaling session can be 1172 deleted. 1174 o Transit: The node has received an asynchronous message, i.e., a 1175 NOTIFY, and can delete the NATFW NSLP signaling session if needed 1176 after some time. When a node has received a NOTIFY message, it 1177 marks the signaling session as 'transit'. This signaling session 1178 SHOULD NOT be deleted before a minimum hold time of 30 second, 1179 i.e., it can be removed after 30 seconds or more. 1181 3.3. Basic Message Processing 1183 All NATFW messages are subject to some basic message processing when 1184 received at a node, independent of the message type. Initially, the 1185 syntax of the NSLP message is checked and a RESPONSE message with an 1186 appropriate error of class 'Protocol error' (0x3) code is generated 1187 if any problem is detected. If a message is delivered to the NATFW 1188 NSLP, this implies that the NTLP layer has been able to correlate it 1189 with the SID and MRI entries in its database. There is therefore 1190 enough information to identify the source of the message and routing 1191 information to route the message back to the NI through an 1192 established chain of NTLP messaging associations. The message is not 1193 further forwarded if any error in the syntax is detected. The 1194 specific response codes stemming from the processing of objects are 1195 described in the respective object definition section (see 1196 Section 4). After passing this check, the NATFW NSLP node performs 1197 authentication/authorization related checks described in Section 3.6. 1198 Further processing is executed only if these tests have been 1199 successfully passed, otherwise the processing stops and an error 1200 RESPONSE is returned. 1202 Further message processing stops whenever an error RESPONSE message 1203 is generated, and the EXTERNAL or CREATE message is discarded. 1205 3.4. Calculation of Signaling Session Lifetime 1207 NATFW NSLP signaling sessions, and the corresponding policy rules 1208 which may have been installed, are maintained via a soft-state 1209 mechanism. Each signaling session is assigned a signaling session 1210 lifetime and the signaling session is kept alive as long as the 1211 lifetime is valid. After the expiration of the signaling session 1212 lifetime, signaling sessions and policy rules MUST be removed 1213 automatically and resources bound to them MUST be freed as well. 1214 Signaling session lifetime is handled at every NATFW NSLP node. The 1215 NSLP forwarders and NSLP responder MUST NOT trigger signaling session 1216 lifetime extension refresh messages (see Section 3.7.3): this is the 1217 task of the NSIS initiator. 1219 The NSIS initiator MUST choose a NATFW NSLP signaling session 1220 lifetime value (expressed in seconds) before sending any message, 1221 including the initial message which creates the NATFW NSLP signaling 1222 session, to other NSLP nodes. The NATFW NSLP signaling session 1223 lifetime value is calculated based on: 1225 o the number of lost refresh messages that NFs should cope with; 1227 o the end-to-end delay between the NI and NR; 1229 o network vulnerability due to NATFW NSLP signaling session 1230 hijacking ([8]), NATFW NSLP signaling session hijacking is made 1231 easier when the NI does not explicitly remove the NATFW NSLP 1232 signaling session); 1234 o the user application's data exchange duration, in terms of time 1235 and networking needs. This duration is modeled as R, with R the 1236 message refresh period (in seconds); 1238 o the load on the signaling plane. Short lifetimes imply more 1239 frequent signaling messages. 1241 o the acceptable time for a NATFW NSLP signaling session to be 1242 present after it is no longer actually needed. For example, if 1243 the existence of the NATFW NSLP signaling session implies a 1244 monetary cost and teardown cannot be guaranteed, shorter lifetimes 1245 would be preferable; 1247 o the lease time of the NI's IP address. The lease time of the IP 1248 address must be larger than chosen NATFW NSLP signaling session 1249 lifetime, otherwise the IP address can be re-assigned to a 1250 different node. This node may receive unwanted traffic, although 1251 it never has requested a NAT/firewall configuration, which might 1252 be an issue in environments with mobile hosts. 1254 The RSVP specification [11] provides an appropriate algorithm for 1255 calculating the NATFW NSLP signaling session lifetime as well as 1256 means to avoid refresh message synchronization between NATFW NSLP 1257 signaling sessions. [11] recommends: 1259 1. The refresh message timer to be randomly set to a value in the 1260 range [0.5R, 1.5R]. 1262 2. To avoid premature loss of state, lt (with lt being the NATFW 1263 NSLP signaling session lifetime) must satisfy lt >= (K + 1264 0.5)*1.5*R, where K is a small integer. Then in the worst case, 1265 K-1 successive messages may be lost without state being deleted. 1266 Currently K = 3 is suggested as the default. However, it may be 1267 necessary to set a larger K value for hops with high loss rate. 1268 Other algorithms could be used to define the relation between the 1269 NATFW NSLP signaling session lifetime and the refresh message 1270 period; the algorithm provided is only given as an example. 1272 This requested NATFW NSLP signaling session lifetime value lt is 1273 stored in the NATFW_LT object of the NSLP message. 1275 NSLP forwarders and the NSLP responder can execute the following 1276 behavior with respect to the requested lifetime handling: 1278 Requested signaling session lifetime acceptable: 1280 No changes to the NATFW NSLP signaling session lifetime values are 1281 needed. The CREATE or EXTERNAL message is forwarded, if 1282 applicable. 1284 Signaling session lifetime can be lowered: 1286 An NSLP forwarded or the NSLP responder MAY also lower the 1287 requested NATFW NSLP signaling session lifetime to an acceptable 1288 value (based on its local policies). If an NF changes the NATFW 1289 NSLP signaling session lifetime value, it MUST store the new value 1290 in the NATFW_LT object. The CREATE or EXTERNAL message is 1291 forwarded. 1293 Requested signaling session lifetime is too big: 1295 An NSLP forwarded or the NSLP responder MAY reject the requested 1296 NATFW NSLP signaling session lifetime value as being too big and 1297 MUST generate an error RESPONSE message of class 'Signaling 1298 session failure' (0x6) with response code 'Requested lifetime is 1299 too big' (0x02) upon rejection. Lowering the lifetime is 1300 preferred instead of generating an error message. 1302 Requested signaling session lifetime is too small: 1304 An NSLP forwarded or the NSLP responder MAY reject the requested 1305 NATFW NSLP signaling session lifetime value as being to small and 1306 MUST generate an error RESPONSE message of class 'Signaling 1307 session failure' (0x6) with response code 'Requested lifetime is 1308 too small' (0x10) upon rejection. 1310 NFs or the NR MUST NOT increase the NATFW NSLP signaling session 1311 lifetime value. Messages can be rejected on the basis of the NATFW 1312 NSLP signaling session lifetime being too long when a NATFW NSLP 1313 signaling session is first created and also on refreshes. 1315 The NSLP responder generates a successful RESPONSE for the received 1316 CREATE or EXTERNAL message, sets the NATFW NSLP signaling session 1317 lifetime value in the NATFW_LT object to the above granted lifetime 1318 and sends the message back towards NSLP initiator. 1320 Each NSLP forwarder processes the RESPONSE message, reads and stores 1321 the granted NATFW NSLP signaling session lifetime value. The 1322 forwarders MUST accept the granted NATFW NSLP signaling session 1323 lifetime, if the lifetime value is within the acceptable range. The 1324 acceptable value refers to the value accepted by the NSLP forwarder 1325 when processing the CREATE or EXTERNAL message. For received values 1326 greater than the acceptable value, NSLP forwarders MUST generate a 1327 RESPONSE message of class 'Signaling session failure' (0x6) with 1328 response code 'Modified lifetime is too big' (0x11). For received 1329 values lower than the values acceptable by the node local policy, 1330 NSLP forwarders MUST generate a RESPONSE message of class 'Signaling 1331 session failure' (0x6) with response code 'Modified lifetime is too 1332 small' (0x12). 1334 Figure 13 shows the procedure with an example, where an initiator 1335 requests 60 seconds lifetime in the CREATE message and the lifetime 1336 is shortened along the path by the forwarder to 20 seconds and by the 1337 responder to 15 seconds. When the NSLP forwarder receives the 1338 RESPONSE message with a NATFW NSLP signaling session lifetime value 1339 of 15 seconds it checks whether this value is lower or equal to the 1340 acceptable value. 1342 +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ 1343 | |---------------->| NSLP |---------------->| | 1344 | NI | | forwarder | | NR | 1345 | |<----------------| check 15<20 |<----------------| | 1346 +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ 1348 lt = lifetime 1350 Figure 13: Signaling Session Lifetime Setting Example 1352 3.5. Message Sequencing 1354 NATFW NSLP messages need to carry an identifier so that all nodes 1355 along the path can distinguish messages sent at different points in 1356 time. Messages can be lost along the path or duplicated. So all 1357 NATFW NSLP nodes should be able to identify either old messages that 1358 have been received before (duplicated), or the case that messages 1359 have been lost before (loss). For message replay protection it is 1360 necessary to keep information about messages that have already been 1361 received and requires every NATFW NSLP message to carry a message 1362 sequence number (MSN), see also Section 4.2.6. 1364 The MSN MUST be set by the NI and MUST NOT be set or modified by any 1365 other node. The initial value for the MSN MUST be generated randomly 1366 and MUST be unique only within the NATFW NSLP signaling session for 1367 which it is used. The NI MUST increment the MSN by one for every 1368 message sent. Once the MSN has reached the maximum value, the next 1369 value it takes is zero. All NATFW NSLP nodes MUST use the algorithm 1370 defined in [3] to detect MSN wrap-arounds. 1372 NSIS forwarders and the responder store the MSN from the initial 1373 CREATE or EXTERNAL packet which creates the NATFW NSLP signaling 1374 session as the start value for the NATFW NSLP signaling session. NFs 1375 and NRs MUST include the received MSN value in the corresponding 1376 RESPONSE message that they generate. 1378 When receiving a CREATE or EXTERNAL message, a NATFW NSLP node uses 1379 the MSN given in the message to determine whether the state being 1380 requested is different to the state already installed. The message 1381 MUST be discarded if the received MSN value is equal to or lower than 1382 the stored MSN value. Such a received MSN value can indicate a 1383 duplicated and delayed message or replayed message. If the received 1384 MSN value is greater than the already stored MSN value, the NATFW 1385 NSLP MUST update its stored state accordingly, if permitted by all 1386 security checks (see Section 3.6), and store the updated MSN value 1387 accordingly. 1389 3.6. Authentication, Authorization, and Policy Decisions 1391 NATFW NSLP nodes receiving signaling messages MUST first check 1392 whether this message is authenticated and authorized to perform the 1393 requested action. NATFW NSLP nodes requiring more information than 1394 provided MUST generate an error RESPONSE of class 'Permanent failure' 1395 (0x5) with response code 'Authentication failed' (0x01) or with 1396 response code 'Authorization failed' (0x02). 1398 The NATFW NSLP is expected to run in various environments, such as 1399 IP-based telephone systems, enterprise networks, home networks, etc. 1400 The requirements on authentication and authorization are quite 1401 different between these use cases. While a home gateway, or an 1402 Internet cafe, using NSIS may well be happy with a "NATFW signaling 1403 coming from inside the network" policy for authorization of 1404 signaling, enterprise networks are likely to require more strongly 1405 authenticated/authorized signaling. This enterprise scenario may 1406 require the use of an infrastructure and administratively assigned 1407 identities to operate the NATFW NSLP. 1409 Once the NI is authenticated and authorized, another step is 1410 performed. The requested policy rule for the NATFW NSLP signaling 1411 session is checked against a set of policy rules, i.e., whether the 1412 requesting NI is allowed to request the policy rule to be loaded in 1413 the device. If this fails the NF or NR must send an error RESPONSE 1414 of class 'Permanent failure' (0x5) and with response code 1415 'Authorization failed' (0x02). 1417 3.7. Protocol Operations 1419 This section defines the protocol operations including, how to create 1420 NATFW NSLP signaling sessions, maintain them, delete them, and how to 1421 reserve addresses. 1423 3.7.1. Creating Signaling Sessions 1425 Allowing two hosts to exchange data even in the presence of 1426 middleboxes is realized in the NATFW NSLP by use of the CREATE 1427 message. The NI (either the data sender or a proxy) generates a 1428 CREATE message as defined in Section 4.3.1 and hands it to the NTLP. 1429 The NTLP forwards the whole message on the basis of the message 1430 routing information (MRI) towards the NR. Each NSIS forwarder along 1431 the path that implements NATFW NSLP, processes the NSLP message. 1432 Forwarding is done hop-by-hop but may pass transparently through NSIS 1433 forwarders which do not contain NATFW NSLP functionality and non-NSIS 1434 aware routers between NSLP hop way points. When the message reaches 1435 the NR, the NR can accept the request or reject it. The NR generates 1436 a response to CREATE and this response is transported hop-by-hop 1437 towards the NI. NATFW NSLP forwarders may reject requests at any 1438 time. Figure 14 sketches the message flow between NI (DS in this 1439 example), a NF (e.g., NAT), and NR (DR in this example). 1441 NI Private Network NF Public Internet NR 1442 | | | 1443 | CREATE | | 1444 |----------------------------->| | 1445 | | | 1446 | | | 1447 | | CREATE | 1448 | |--------------------------->| 1449 | | | 1450 | | RESPONSE | 1451 | RESPONSE |<---------------------------| 1452 |<-----------------------------| | 1453 | | | 1454 | | | 1456 Figure 14: CREATE message flow with success RESPONSE 1458 There are several processing rules for a NATFW peer when generating 1459 and receiving CREATE messages, since this message type is used for 1460 creating new NATFW NSLP signaling session, updating existing, 1461 extending the lifetime and deleting NATFW NSLP signaling session. 1462 The three latter functions operate in the same way for all kinds of 1463 CREATE message, and are therefore described in separate sections: 1465 o Extending the lifetime of NATFW NSLP signaling sessions is 1466 described in Section 3.7.3. 1468 o Deleting NATFW NSLP signaling sessions is described in 1469 Section 3.7.4. 1471 o Updating policy rules is described in Section 3.10. 1473 For an initial CREATE message creating a new NATFW NSLP signaling 1474 session, the processing of CREATE messages is different for every 1475 NATFW node type: 1477 o NSLP initiator: An NI only generates CREATE messages and hands 1478 them over to the NTLP. The NI should never receive CREATE 1479 messages and MUST discard it. 1481 o NATFW NSLP forwarder: NFs that are unable to forward the CREATE 1482 message to the next hop MUST generate an error RESPONSE of class 1483 'Permanent failure' (0x6) with response code 'Did not reach the 1484 NR' (0x07). This case may occur if the NTLP layer cannot find an 1485 NATFW NSLP peer, either another NF or the NR, and returns an error 1486 via the GIST API. The NSLP message processing at the NFs depends 1487 on the middlebox type: 1489 * NAT: When the initial CREATE message is received at the public 1490 side of the NAT, it looks for a reservation made in advance, by 1491 using a EXTERNAL message (see Section 3.7.2). The matching 1492 process considers the received MRI information and the stored 1493 MRI information, as described in Section 3.8. If no matching 1494 reservation can be found, i.e., no reservation has been made in 1495 advance, the NSLP MUST return an error RESPONSE of class 1496 'Signaling session failure' (0x6) with response code 'No 1497 reservation found matching the MRI of the CREATE request' 1498 (0x03). If there is a matching reservation, the NSLP stores 1499 the data sender's address (and if applicable port number) as 1500 part of the source address of the policy rule ('the remembered 1501 policy rule') to be loaded and forwards the message with the 1502 destination address set to the internal (private in most cases) 1503 address of NR. When the initial CREATE message is received at 1504 the private side, the NAT binding is allocated, but not 1505 activated (see also Appendix C.3). An error RESPONSE message 1506 is generated, if the requested policy rule cannot be installed 1507 later on, with of class 'Signaling session failure' (0x6) with 1508 response code 'Requested policy rule denied due to policy 1509 conflict' (0x4). The MRI information is updated to reflect the 1510 address, and if applicable port, translation. The NSLP message 1511 is forwarded towards the NR with source address set to the 1512 NAT's external address from the newly remembered binding. 1514 * Firewall: When the initial CREATE message is received, the NSLP 1515 just remembers the requested policy rule, but does not install 1516 any policy rule. Afterwards, the message is forwarded towards 1517 the NR. An error RESPONSE message is generated, if the 1518 requested policy rule cannot be installed later on, with of 1519 class 'Signaling session failure' (0x6) with response code 1520 'Requested policy rule denied due to policy conflict' (0x4). 1522 * Combined NAT and firewall: Processing at combined firewall and 1523 NAT middleboxes is the same as in the NAT case. No policy 1524 rules are installed. Implementations MUST take into account 1525 the order of packet processing in the firewall and NAT 1526 functions within the device. This will be referred to as 1527 'order of functions' and is generally different depending on 1528 whether the packet arrives at the external or internal side of 1529 the middlebox. 1531 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1532 with a success RESPONSE of class 'Success' (0x2) with response 1533 code set to 'All successfully processed' (0x01), if they accept 1534 the CREATE message. Otherwise they MUST generate a RESPONSE 1535 message with a suitable response code. RESPONSE messages are sent 1536 back NSLP hop-by-hop towards the NI, irrespective of the response 1537 codes, either success or error. 1539 Remembered policy rules at middleboxes MUST be only installed upon 1540 receiving a corresponding successful RESPONSE message with the same 1541 SID as the CREATE message that caused them to be remembered. This is 1542 a countermeasure to several problems, for example, wastage of 1543 resources due to loading policy rules at intermediate NFs when the 1544 CREATE message does not reach the final NR for some reason. 1546 Processing of a RESPONSE message is different for every NSIS node 1547 type: 1549 o NSLP initiator: After receiving a successful RESPONSE, the data 1550 path is configured and the DS can start sending its data to the 1551 DR. After receiving an error RESPONSE message, the NI MAY try to 1552 generate the CREATE message again or give up and report the 1553 failure to the application, depending on the error condition. 1555 o NSLP forwarder: NFs install the remembered policy rules, if a 1556 successful RESPONSE message with matching SID is received. If an 1557 ERROR RESPONSE message with matching SID is received, the NATFW 1558 NSLP session is marked as dead, no policy rule is installed and 1559 the remembered rule is discarded. 1561 o NSIS responder: The NR should never receive RESPONSE messages and 1562 MUST silently drop any such messages received. 1564 NFs and the NR can also tear down the CREATE session at any time by 1565 generating a NOTIFY message with the appropriate response code set. 1567 3.7.2. Reserving External Addresses 1569 NSIS signaling is intended to travel end-to-end, even in the presence 1570 of NATs and firewalls on-path. This works well in cases where the 1571 data sender is itself behind a NAT or a firewall as described in 1572 Section 3.7.1. For scenarios where the data receiver is located 1573 behind a NAT or a firewall and it needs to receive data flows from 1574 outside its own network (usually referred to as inbound flows, see 1575 Figure 5) the problem is more troublesome. 1577 NSIS signaling, as well as subsequent data flows, are directed to a 1578 particular destination IP address that must be known in advance and 1579 reachable. Data receivers must tell the local NSIS infrastructure 1580 (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP 1581 signaling and data flows before they can receive these flows. It is 1582 necessary to differentiate between data receivers behind NATs and 1583 behind firewalls for understanding the further NATFW procedures. 1584 Data receivers that are only behind firewalls already have a public 1585 IP address and they need only to be reachable for NATFW signaling. 1586 Unlike data receivers behind just firewalls, data receivers behind 1587 NATs do not have public IP addresses; consequently they are not 1588 reachable for NATFW signaling by entities outside their addressing 1589 realm. 1591 The preceding discussion addresses the situation where a DR node that 1592 wants to be reachable is unreachable because the NAT lacks a suitable 1593 rule with the 'allow' action which would forward inbound data. 1594 However, in certain scenarios, a node situated behind inbound 1595 firewalls that do not block inbound data traffic (firewalls with 1596 "default to allow") unless requested might wish to prevent traffic 1597 being sent to it from specified addresses. In this case, NSIS NATFW 1598 signaling can be used to achieve this by installing a policy rule 1599 with its action set to 'deny' using the same mechanisms as for 1600 'allow' rules. 1602 The required result is obtained by sending a EXTERNAL message in the 1603 inbound direction of the intended data flow. When using this 1604 functionality the NSIS initiator for the 'Reserve External Address' 1605 signaling is typically the node that will become the DR for the 1606 eventual data flow. To distinguish this initiator from the usual 1607 case where the NI is associated with the DS, the NI is denoted by NI+ 1608 and the NSIS responder is similarly denoted by NR+. 1610 Public Internet Private Address 1611 Space 1613 Edge 1614 NI(DS) NAT/FW NAT NR(DR) 1615 NR+ NI+ 1617 | | | | 1618 | | | | 1619 | | | | 1620 | | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] | 1621 | |<----------------------|<----------------------| 1622 | | | | 1623 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1624 | |---------------------->|---------------------->| 1625 | | | | 1626 | | | | 1628 ============================================================> 1629 Data Traffic Direction 1631 Figure 15: Reservation message flow for DR behind NAT or firewall 1633 Figure 15 shows the EXTERNAL message flow for enabling inbound NATFW 1634 NSLP signaling messages. In this case the roles of the different 1635 NSIS entities are: 1637 o The data receiver (DR) for the anticipated data traffic is the 1638 NSIS initiator (NI+) for the EXTERNAL message, but becomes the 1639 NSIS responder (NR) for following CREATE messages. 1641 o The actual data sender (DS) will be the NSIS initiator (NI) for 1642 later CREATE messages and may be the NSIS target of the signaling 1643 (NR+). 1645 o It may be necessary to use a signaling destination address (SDA) 1646 as the actual target of the EXTERNAL message (NR+) if the DR is 1647 located behind a NAT and the address of the DS is unknown. The 1648 SDA is an arbitrary address in the outermost address realm on the 1649 other side of the NAT from the DR. Typically this will be a 1650 suitable public IP address when the 'outside' realm is the public 1651 Internet. This choice of address causes the EXTERNAL message to 1652 be routed through the NATs towards the outermost realm and would 1653 force interception of the message by the outermost NAT in the 1654 network at the boundary between the private address and the public 1655 address realm (the edge-NAT). It may also be intercepted by other 1656 NATs and firewalls on the path to the edge-NAT. 1658 Basically, there are two different signaling scenarios. Either 1660 1. the DR behind the NAT/firewall knows the IP address of the DS in 1661 advance, 1663 2. or the address of DS is not known in advance. 1665 Case 1 requires the NATFW NSLP to request the path-coupled message 1666 routing method (PC-MRM) from the NTLP. The EXTERNAL message MUST be 1667 sent with PC-MRM (see Section 5.8.1 in [2]) with the direction set to 1668 'upstream' (inbound). The handling of case 2 depends on the 1669 situation of DR: If DR is solely located behind a firewall, the 1670 EXTERNAL message MUST be sent with the PC-MRM, direction 'upstream' 1671 (inbound), and data flow source IP address set to wildcard. If DR is 1672 located behind a NAT, the EXTERNAL message MUST be sent with the 1673 loose-end message routing method (LE-MRM, see Section 5.8.2 in [2]), 1674 the destination-address set to the signaling destination address 1675 (SDA, see also Appendix A). For scenarios with DR being behind a 1676 firewall, special conditions apply (see applicability statement in 1677 Appendix B). The data receiver is challenged to determine whether it 1678 is solely located behind firewalls or NATs, for choosing the right 1679 message routing method. This decision can depend on a local 1680 configuration parameter, possibly given through DHCP, or it could be 1681 discovered through other non-NSLP related testing of the network 1682 configuration. It is RECOMMENDED to use the PC-MRM with the known 1683 data sender's IP address. This gives GIST the best possible handled 1684 to route the message 'upstream' (outbound). It is RECOMMENDED to use 1685 the LE-MRM, if and only if the data sender's IP address is not known 1686 and the data receiver is behind a NAT. 1688 For case 2 with NAT, the NI+ (which could be on the data receiver DR 1689 or on any other host within the private network) sends the EXTERNAL 1690 message targeted to the signaling destination address. The message 1691 routing for the EXTERNAL message is in the reverse direction to the 1692 normal message routing used for path-coupled signaling where the 1693 signaling is sent outbound (as opposed to inbound in this case). 1694 When establishing NAT bindings (and an NATFW NSLP signaling session) 1695 the signaling direction does not matter since the data path is 1696 modified through route pinning due to the external IP address at the 1697 NAT. Subsequent NSIS messages (and also data traffic) will travel 1698 through the same NAT boxes. However, this is only valid for the NAT 1699 boxes, but not for any intermediate firewall. That is the reason for 1700 having a separate CREATE message enabling the reservations made with 1701 EXTERNAL at the NATs and either enabling prior reservations or 1702 creating new pinholes at the firewalls which are encountered on the 1703 outbound path depending on whether the inbound and outbound routes 1704 coincide. 1706 The EXTERNAL signaling message creates an NSIS NATFW signaling 1707 session at any intermediate NSIS NATFW peer(s) encountered, 1708 independent of the message routing method used. Furthermore, it has 1709 to be ensured that the edge-NAT or edge-firewall device is discovered 1710 as part of this process. The end host cannot be assumed to know this 1711 device - instead the NAT or firewall box itself is assumed to know 1712 that it is located at the outer perimeter of the network. Forwarding 1713 of the EXTERNAL message beyond this entity is not necessary, and MUST 1714 be prohibited as it may provide information on the capabilities of 1715 internal hosts. It should be noted, that it is the outermost NAT or 1716 firewall that is the edge-device that must be found during this 1717 discovery process. For instance, when there are a NAT and afterwards 1718 a firewall on the outbound path at the network border, the firewall 1719 is the edge-firewall. All messages must be forwarded to the 1720 topology-wise outermost edge-device, to ensure that this devices 1721 knows about the NATFW NSLP signaling sessions for incoming CREATE 1722 messages. However, the NAT is still the edge-NAT because it has a 1723 public globally routable IP address on its public side: this is not 1724 affected by any firewall between the edge-NAT and the public network. 1726 Possible edge arrangements are: 1728 Public Net ----------------- Private net -------------- 1730 | Public Net|--|Edge-FW|--|FW|...|FW|--|DR| 1732 | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR| 1734 | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR| 1736 The edge-NAT or edge-firewall device closest to the public realm 1737 responds to the EXTERNAL message with a successful RESPONSE message. 1738 An edge-NAT includes an NATFW_EXTERNAL-IP object (see Section 4.2.2), 1739 carrying the public reachable IP address, and if applicable port 1740 number. 1742 There are several processing rules for a NATFW peer when generating 1743 and receiving EXTERNAL messages, since this message type is used for 1744 creating new reserve NATFW NSLP signaling sessions, updating 1745 existing, extending the lifetime and deleting NATFW NSLP signaling 1746 session. The three latter functions operate in the same way for all 1747 kinds of CREATE and EXTERNAL messages, and are therefore described in 1748 separate sections: 1750 o Extending the lifetime of NATFW NSLP signaling sessions is 1751 described in Section 3.7.3. 1753 o Deleting NATFW NSLP signaling sessions is described in 1754 Section 3.7.4. 1756 o Updating policy rules is described in Section 3.10. 1758 The NI+ MUST always include a NATFW_DTINFO object in the EXTERNAL 1759 message. Especially, the LE-MRM does not include enough information 1760 for some types of NATs (basically, those NATs which also translate 1761 port numbers) to perform the address translation. This information 1762 is provided in the NATFW_DTINFO (see Section 4.2.7). This 1763 information MUST include at least the 'dst port number' and 1764 'protocol' fields, in the NATFW_DTINFO object as these may be 1765 required by en-route NATs, depending on the type of the NAT. All 1766 other fields MAY be set by the NI+ to restrict the set of possible 1767 NIs. An edge-NAT will use the information provided in the 1768 NATFW_DTINFO object to allow only NATFW CREATE message with the MRI 1769 matching ('src IPv4/v6 address', 'src port number', 'protocol') to be 1770 forwarded. A NAT requiring information carried in the NATFW_DTINFO 1771 can generate a number of error RESPONSE messages of class 'Signaling 1772 session failure' (0x6): 1774 o 'Requested policy rule denied due to policy conflict' (0x04) 1776 o 'NATFW_DTINFO object is required' (0x07) 1778 o 'Requested value in sub_ports field in NATFW_EFI not permitted' 1779 (0x08) 1781 o 'Requested IP protocol not supported' (0x09) 1783 o 'Plain IP policy rules not permitted -- need transport layer 1784 information' (0x0A) 1786 o 'source IP address range is too large' (0x0C) 1788 o 'destination IP address range is too large' (0x0D) 1790 o 'source L4-port range is too large' (0x0E) 1791 o 'destination L4-port range is too large' (0x0F) 1793 Processing of EXTERNAL messages is specific to the NSIS node type: 1795 o NSLP initiator: NI+ only generate EXTERNAL messages. When the 1796 data sender's address information is known in advance the NI+ can 1797 include a NATFW_DTINFO object in the EXTERNAL message, if not 1798 anyway required to do so (see above). When the data sender's IP 1799 address is not known, the NI+ MUST NOT include an IP address in 1800 the NATFW_DTINFO object. The NI should never receive EXTERNAL 1801 messages and MUST silently discard it. 1803 o NSLP forwarder: The NSLP message processing at NFs depends on the 1804 middlebox type: 1806 * NAT: NATs check whether the message is received at the external 1807 (public in most cases) address or at the internal (private) 1808 address. If received at the external an NF MUST generate an 1809 error RESPONSE of class 'Protocol error' (0x3) with response 1810 code 'Received EXTERNAL request message on external side' 1811 (0x0B). If received at the internal (private address) and the 1812 NATFW_EFI object contains the action 'deny', an error RESPONSE 1813 of class 'Protocol error' (0x3) with response code 'Requested 1814 rule action not applicable' (0x06) MUST be generated. If 1815 received at the internal address, an IP address, and if 1816 applicable one or more ports, are reserved. If it is an edge- 1817 NAT and there is no edge-firewall beyond, the NSLP message is 1818 not forwarded any further and a successful RESPONSE message is 1819 generated containing an NATFW_EXTERNAL-IP object holding the 1820 translated address, and if applicable port, information from 1821 the binding reserved as a result of the EXTERNAL message. The 1822 RESPONSE message is sent back towards the NI+. If it is not an 1823 edge-NAT, the NSLP message is forwarded further using the 1824 translated IP address as signaling source address in the LE-MRM 1825 and translated port in the NATFW_DTINFO object in the field 'DR 1826 port number', i.e., the NATFW_DTINFO object is updated to 1827 reflect the translated port number. The edge-NAT or any other 1828 NAT MUST reject EXTERNAL messages not carrying a NATFW_DTINFO 1829 object or if the address information within this object is 1830 invalid or is not compliant with local policies (e.g., the 1831 information provided relates to a range of addresses 1832 ('wildcarded') but the edge-NAT requires exact information 1833 about DS' IP address and port) with the above mentioned 1834 response codes. 1836 * Firewall: Non edge-firewalls remember the requested policy 1837 rule, keep NATFW NSLP signaling session state, and forward the 1838 message. Edge-firewalls stop forwarding the EXTERNAL message. 1840 The policy rule is immediately loaded if the action in the 1841 NATFW_EFI object is set to 'deny' and the node is an edge- 1842 firewall. The policy rule is remembered, but not activated, if 1843 the action in the NATFW_EFI object is set to 'allow'. In both 1844 cases, a successful RESPONSE message is generated. If the 1845 action is 'allow', and the NATFW_DTINFO object is included, and 1846 the MRM is set to LE-MRM in the request, additionally an 1847 NATFW_EXTERNAL-IP object is included in the RESPONSE message, 1848 holding the translated address, and if applicable port, 1849 information. This information is obtained from the 1850 NATFW_DTINFO object's 'DR port number' and the source-address 1851 of the LE-MRM. 1853 * Combined NAT and firewall: Processing at combined firewall and 1854 NAT middleboxes is the same as in the NAT case. 1856 o NSLP receiver: This type of message should never be received by 1857 any NR+ and it MUST generate an error RESPONSE message of class 1858 'Permanent failure' (0x5) with response code 'No edge-device here' 1859 (0x06). 1861 Processing of a RESPONSE message is different for every NSIS node 1862 type: 1864 o NSLP initiator: Upon receiving a successful RESPONSE message, the 1865 NI+ can rely on the requested configuration for future inbound 1866 NATFW NSLP signaling sessions. If the response contains an 1867 NATFW_EXTERNAL-IP object, the NI can use IP address and port pairs 1868 carried for further application signaling. After receiving a 1869 error RESPONSE message, the NI+ MAY try to generate the EXTERNAL 1870 message again or give up and report the failure to the 1871 application, depending on the error condition. 1873 o NSLP forwarder: NFs simply forward this message as long as they 1874 keep state for the requested reservation, if the RESPONSE message 1875 contains NATFW_INFO object with class set to 'Success' (0x2). If 1876 the RESPONSE message contains NATFW_INFO object with class set not 1877 to 'Success' (0x2), the NATFW NSLP signaling session is marked as 1878 dead. 1880 o NSIS responder: This type of message should never be received by 1881 any NR+. The NF should never receive response messages and MUST 1882 silently discard it. 1884 NFs and the NR can also tear down the EXTERNAL session at any time by 1885 generating a NOTIFY message with the appropriate response code set. 1887 Reservations with action 'allow' made with EXTERNAL MUST be enabled 1888 by a subsequent CREATE message. A reservation made with EXTERNAL 1889 (independent of selected action) is kept alive as long as the NI+ 1890 refreshes the particular NATFW NSLP signaling session and it can be 1891 reused for multiple, different CREATE messages. An NI+ may decide to 1892 teardown a reservation immediately after receiving a CREATE message. 1893 This implies that a new NATFW NSLP signaling session must be created 1894 for each new CREATE message. The CREATE message does not re-use the 1895 NATFW NSLP signaling session created by EXTERNAL. 1897 Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode 1898 (see Section 3.7.6) no data traffic will be forwarded to DR beyond 1899 the edge-NAT or edge-firewall. The only function of EXTERNAL is to 1900 ensure that subsequent CREATE messages traveling towards the NR will 1901 be forwarded across the public-private boundary towards the DR. 1902 Correlation of incoming CREATE messages to EXTERNAL reservation 1903 states is described in Section 3.8. 1905 3.7.3. NATFW NSLP Signaling Session Refresh 1907 NATFW NSLP signaling sessions are maintained on a soft-state basis. 1908 After a specified timeout, sessions and corresponding policy rules 1909 are removed automatically by the middlebox, if they are not 1910 refreshed. Soft-state is created by CREATE and EXTERNAL and the 1911 maintenance of this state must be done by these messages. State 1912 created by CREATE must be maintained by CREATE, state created by 1913 EXTERNAL must be maintained by EXTERNAL. Refresh messages, are 1914 messages carrying the same session ID as the initial message and a 1915 NATFW_LT lifetime object with a lifetime greater than zero. Messages 1916 with the same SID but carrying a different MRI are treated as updates 1917 of the policy rules and are processed as defined in Section 3.10. 1918 Every refresh CREATE or EXTERNAL message MUST be acknowledged by an 1919 appropriate response message generated by the NR. Upon reception by 1920 each NSIS forwarder, the state for the given session ID is extended 1921 by the NATFW NSLP signaling session refresh period, a period of time 1922 calculated based on a proposed refresh message period. The new 1923 (extended) lifetime of a NATFW NSLP signaling session is calculated 1924 as current local time plus proposed lifetime value (NATFW NSLP 1925 signaling session refresh period). Section 3.4 defines the process 1926 of calculating lifetimes in detail. 1928 NI Public Internet NAT Private address NR 1930 | | space | 1931 | CREATE[lifetime > 0] | | 1933 |----------------------------->| | 1934 | | | 1935 | | | 1936 | | CREATE[lifetime > 0] | 1937 | |--------------------------->| 1938 | | | 1939 | | RESPONSE[Success/Error] | 1940 | RESPONSE[Success/Error] |<---------------------------| 1941 |<-----------------------------| | 1942 | | | 1943 | | | 1945 Figure 17: Successful Refresh Message Flow, CREATE as example 1947 Processing of NATFW NSLP signaling session refresh CREATE and 1948 EXTERNAL messages is different for every NSIS node type: 1950 o NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling 1951 session refresh CREATE/EXTERNAL messages before the NATFW NSLP 1952 signaling session times out. The rate at which the refresh 1953 CREATE/EXTERNAL messages are sent and their relation to the NATFW 1954 NSLP signaling session state lifetime is discussed further in 1955 Section 3.4. 1957 o NSLP forwarder: Processing of this message is independent of the 1958 middlebox type and is as described in Section 3.4. 1960 o NSLP responder: NRs accepting a NATFW NSLP signaling session 1961 refresh CREATE/EXTERNAL message generate a successful RESPONSE 1962 message, including the granted lifetime value of Section 3.4 in a 1963 NATFW_LT object. 1965 3.7.4. Deleting Signaling Sessions 1967 NATFW NSLP signaling sessions can be deleted at any time. NSLP 1968 initiators can trigger this deletion by using a CREATE or EXTERNAL 1969 messages with a lifetime value set to 0, as shown in Figure 18. 1970 Whether a CREATE or EXTERNAL message type is used, depends on how the 1971 NATFW NSLP signaling session was created. 1973 NI Public Internet NAT Private address NR 1975 | | space | 1976 | CREATE[lifetime=0] | | 1977 |----------------------------->| | 1978 | | | 1979 | | CREATE[lifetime=0] | 1980 | |--------------------------->| 1981 | | | 1983 Figure 18: Delete message flow, CREATE as example 1985 NSLP nodes receiving this message delete the NATFW NSLP signaling 1986 session immediately. Policy rules associated with this particular 1987 NATFW NSLP signaling session MUST be also deleted immediately. This 1988 message is forwarded until it reaches the final NR. The CREATE/ 1989 EXTERNAL message with a lifetime value of 0, does not generate any 1990 response, neither positive nor negative, since there is no NSIS state 1991 left at the nodes along the path. 1993 NSIS initiators can use CREATE/EXTERNAL message with lifetime set to 1994 zero in an aggregated way, such that a single CREATE or EXTERNAL 1995 message is terminating multiple NATFW NSLP signaling sessions. NIs 1996 can follow this procedure if they like to aggregate NATFW NSLP 1997 signaling session deletion requests: The NI uses the CREATE or 1998 EXTERNAL message with the session ID set to zero and the MRI's 1999 source-address set to its used IP address. All other fields of the 2000 respective NATFW NSLP signaling sessions to be terminated are set as 2001 well, otherwise these fields are completely wildcarded. The NSLP 2002 message is transferred to the NTLP requesting 'explicit routing' as 2003 described in Sections 5.2.1 and 7.1.4. in [2]. 2005 The outbound NF receiving such an aggregated CREATE or EXTERNAL 2006 message MUST reject it with an error RESPONSE of class 'Permanent 2007 failure' (0x5) with response code 'Authentication failed' (0x01) if 2008 the authentication fails and with an error RESPONSE of class 2009 'Permanent failure' (0x5) with response code 'Authorization failed' 2010 (0x02) if the authorization fails. Per NATFW NSLP signaling session 2011 proof of ownership, as it is defined in this memo, is not possible 2012 anymore when using this aggregated way. However, the outbound NF can 2013 use the relationship between the information of the received CREATE 2014 or EXTERNAL message and the GIST messaging association where the 2015 request has been received. The outbound NF MUST only accept this 2016 aggregated CREATE or EXTERNAL message through already established 2017 GIST messaging associations with the NI. The outbound NF MUST NOT 2018 propagate this aggregated CREATE or EXTERNAL message but it MAY 2019 generate and forward per NATFW NSLP signaling session CREATE or 2020 EXTERNAL messages. 2022 3.7.5. Reporting Asynchronous Events 2024 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 2025 to report asynchronous events to other NATFW NSLP nodes, especially 2026 to allow reporting back to the NATFW NSLP initiator. Such 2027 asynchronous events may be premature NATFW NSLP signaling session 2028 termination, changes in local policies, route change or any other 2029 reason that indicates change of the NATFW NSLP signaling session 2030 state. 2032 NFs and NRs may generate NOTIFY messages upon asynchronous events, 2033 with a NATFW_INFO object indicating the reason for event. These 2034 reasons can be carried in the NATFW_INFO object (class MUST be set to 2035 'Informational' (0x1)) within the NOTIFY message. This list shows 2036 the response codes and the associated actions to take at NFs and the 2037 NI: 2039 o 'Route change: possible route change on the outbound path' (0x01): 2040 Follow instructions in Section 3.9. This MUST be sent inbound. 2042 o 'Re-authentication required' (0x02): The NI should re-send the 2043 authentication. This MUST be sent inbound. 2045 o 'NATFW node is going down soon' (0x03): The NI and other NFs 2046 should be prepared for a service interruption at any time. This 2047 message MAY be sent inbound and outbound. 2049 o 'NATFW signaling session lifetime expired' (0x04): The NATFW 2050 signaling session has been expired and the signaling session is 2051 invalid now. NFs MUST mark the signaling session as 'Dead'. This 2052 message MAY be sent inbound and outbound. 2054 o 'NATFW signaling session terminated' (0x05): The NATFW signaling 2055 session has been terminated by any reason and the signaling 2056 session is invalid now. NFs MUST mark the signaling session as 2057 'Dead'. This message MAY be sent inbound and outbound. 2059 NOTIFY messages are always sent hop-by-hop inbound towards NI until 2060 they reach NI or outbound towards the NR as indicated in the list 2061 above. 2063 The initial processing when receiving a NOTIFY message is the same 2064 for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages 2065 through already established NTLP messaging associations. The further 2066 processing is different for each NATFW NSLP node type and depends on 2067 the events notified: 2069 o NSLP initiator: NIs analyze the notified event and behave 2070 appropriately based on the event type. NIs MUST NOT generate 2071 NOTIFY messages. 2073 o NSLP forwarder: NFs analyze the notified event and behave based on 2074 the above description per response code. NFs SHOULD generate 2075 NOTIFY messages upon asynchronous events and forward them inbound 2076 towards the NI or outbound towards the NR, depending on the 2077 received direction, i.e., inbound messages MUST be forwarded 2078 further inbound and outbound messages MUST be forwarded further 2079 outbound. NFs MUST silently discard NOTIFY messages that have 2080 been received outbound but are only allowed to be sent inbound, 2081 e.g. 'Re-authentication required' (0x02). 2083 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 2084 asynchronous events including a response code based on the 2085 reported event. The NR MUST silently discard NOTIFY messages that 2086 have been received outbound but are only allowed to be sent 2087 inbound, e.g. 'Re-authentication required' (0x02), 2089 NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions 2090 at the same time, can experience problems when shutting down service 2091 suddenly. This sudden shutdown can be result of node local failure, 2092 for instance, due to a hardware failure. This NF generates NOTIFY 2093 messages for each of the NATFW NSLP signaling sessions and tries to 2094 send them inbound. Due to the number of NOTIFY messages to be sent, 2095 the shutdown of the node may be unnecessarily prolonged, since not 2096 all messages can be sent at the same time. This case can be 2097 described as a NOTIFY storm, if a multitude of NATFW NSLP signaling 2098 sessions is involved. 2100 To avoid the need of generating per NATFW NSLP signaling session 2101 NOTIFY messages in such a scenario described or similar cases, NFs 2102 SHOULD follow this procedure: The NF uses the NOTIFY message with the 2103 session ID in the NTLP set to zero, with the MRI completely 2104 wildcarded, using the 'explicit routing' as described in Sections 2105 5.2.1 and 7.1.4. in [2]. The inbound NF receiving this type of 2106 NOTIFY immediately regards all NATFW NSLP signaling sessions from 2107 that peer matching the MRI as void. This message will typically 2108 result in multiple NOTIFY messages at the inbound NF, i.e., the NF 2109 can generate per terminated NATFW NSLP signaling session a NOTIFY 2110 message. However, a NF MAY aggregate again the NOTIFY messages as 2111 described here. 2113 3.7.6. Proxy Mode of Operation 2115 Some migration scenarios need specialized support to cope with cases 2116 where NSIS is only deployed in same areas of the Internet. End-to- 2117 end signaling is going to fail without NSIS support at or near both 2118 data sender and data receiver terminals. A proxy mode of operation 2119 is needed. This proxy mode of operation must terminate the NATFW 2120 NSLP signaling topologically-wise as close as possible to the 2121 terminal for which it is proxying and proxy all messages. This NATFW 2122 NSLP node doing the proxying of the signaling messages becomes either 2123 the NI or the NR for the particular NATFW NSLP signaling session, 2124 depending on whether it is the DS or DR that does not support NSIS. 2125 Typically, the edge-NAT or the edge-firewall would be used to proxy 2126 NATFW NSLP messages. 2128 This proxy mode operation does not require any new CREATE or EXTERNAL 2129 message type, but relies on extended CREATE and EXTERNAL message 2130 types. They are called respectively CREATE-PROXY and EXTERNAL-PROXY 2131 and are distinguished by setting the P flag in the NSLP header to 2132 P=1. This flag instructs edge-NATs and edge-firewalls receiving them 2133 to operate in proxy mode for the NATFW NSLP signaling session in 2134 question. The semantics of the CREATE and EXTERNAL message types are 2135 not changed and the behavior of the various node types is as defined 2136 in Section 3.7.1 and Section 3.7.2, except for the proxying node. 2137 The following paragraphs describe the proxy mode operation for data 2138 receivers behind middleboxes and data senders behind middleboxes. 2140 3.7.6.1. Proxying for a Data Sender 2142 The NATFW NSLP gives the NR the ability to install state on the 2143 inbound path towards the data sender for outbound data packets, even 2144 when only the receiving side is running NSIS (as shown in Figure 19). 2145 The goal of the method described is to trigger the edge-NAT/ 2146 edge-firewall to generate a CREATE message on behalf of the data 2147 receiver. In this case, an NR can signal towards the network border 2148 as it is performed in the standard EXTERNAL message handling scenario 2149 as in Section 3.7.2. The message is forwarded until the edge-NAT/ 2150 edge-firewall is reached. A public IP address and port number is 2151 reserved at an edge-NAT/edge-firewall. As shown in Figure 19, unlike 2152 the standard EXTERNAL message handling case, the edge-NAT/ 2153 edge-firewall is triggered to send a CREATE message on a new reverse 2154 path which traverse several firewalls or NATs. The new reverse path 2155 for CREATE is necessary to handle routing asymmetries between the 2156 edge-NAT/edge-firewall and DR. It must be stressed that the 2157 semantics of the CREATE and EXTERNAL messages is not changed, i.e., 2158 each is processed as described earlier. 2160 DS Public Internet NAT/FW Private address DR 2161 No NI NF space NR 2162 NR+ NI+ 2164 | | EXTERNAL-PROXY[(DTInfo)] | 2165 | |<------------------------- | 2166 | | RESPONSE[Error/Success] | 2167 | | ---------------------- > | 2168 | | CREATE | 2169 | | ------------------------> | 2170 | | RESPONSE[Error/Success] | 2171 | | <---------------------- | 2172 | | | 2174 Figure 19: EXTERNAL Triggering Sending of CREATE Message 2176 A NATFW_NONCE object, carried in the EXTERNAL and CREATE message, is 2177 used to build the relationship between received CREATEs at the 2178 message initiator. An NI+ uses the presence of the NATFW_NONCE 2179 object to correlate it to the particular EXTERNAL-PROXY. The absence 2180 of a NONCE object indicates a CREATE initiated by the DS and not by 2181 the edge-NAT. The two signaling sessions, i.e., the session for 2182 EXTERNAL-PROXY and the session for CREATE, are not independent. The 2183 primary session is the EXTERNAL-PROXY session. The CREATE session is 2184 secondary to the EXTERNAL-PROXY session, i.e., the CREATE session is 2185 valid as long as the EXTERNAL-PROXY session is the signaling states 2186 'Established' or 'Transit'. There is no CREATE session in any other 2187 signaling state of the EXTERNAL-PROXY, i.e., 'pending' or 'dead'. 2188 This ensures a faith-sharing between both signaling sessions. 2190 These processing rules of EXTERNAL-PROXY messages are added to the 2191 regular EXTERNAL processing: 2193 o NSLP initiator (NI+): The NI+ MUST take the session ID (SID) value 2194 of the EXTERNAL-PROXY session as the nonce value of the 2195 NATFW_NONCE object. 2197 o NSLP forwarder being either edge-NAT or edge-firewall: When the NF 2198 accepts a EXTERNAL-PROXY message, it generates a successful 2199 RESPONSE message as if it were the NR and additionally, it 2200 generates a CREATE message as defined in Section 3.7.1 and 2201 includes a NATFW_NONCE object having the same value as of the 2202 received NATFW_NONCE object. The NF MUST NOT generate a CREATE- 2203 PROXY message. The NF MUST refresh the CREATE message signaling 2204 session only if a EXTERNAL-PROXY refresh message has been received 2205 first. This also includes tearing down signaling sessions, i.e., 2206 the NF must teardown the CREATE signaling session only if a 2207 EXTERNAL-PROXY message with lifetime set to 0 has been received 2208 first. 2210 The scenario described in this section challenges the data receiver 2211 because it must make a correct assumption about the data sender's 2212 ability to use NSIS NATFW NSLP signaling. It is possible for the DR 2213 to make the wrong assumption in two different ways: 2215 a) the DS is NSIS unaware but the DR assumes the DS to be NSIS 2216 aware and 2218 b) the DS is NSIS aware but the DR assumes the DS to be NSIS 2219 unaware. 2221 Case a) will result in middleboxes blocking the data traffic, since 2222 DS will never send the expected CREATE message. Case b) will result 2223 in the DR successfully requesting proxy mode support by the edge-NAT 2224 or edge-firewall. The edge-NAT/edge-firewall will send CREATE 2225 messages and DS will send CREATE messages as well. Both CREATE 2226 messages are handled as separated NATFW NSLP signaling sessions and 2227 therefore the common rules per NATFW NSLP signaling session apply; 2228 the NATFW_NONCE object is used to differentiate CREATE messages 2229 generated by the edge-NAT/edge-firewall from NI initiated CREATE 2230 messages. It is the NR's responsibility to decide whether to 2231 teardown the EXTERNAL-PROXY signaling sessions in the case where the 2232 data sender's side is NSIS aware, but was incorrectly assumed not to 2233 be so by the DR. It is RECOMMENDED that a DR behind NATs uses the 2234 proxy mode of operation by default, unless the DR knows that the DS 2235 is NSIS aware. The DR MAY cache information about data senders which 2236 it has found to be NSIS aware in past NATFW NSLP signaling sessions. 2238 There is a possible race condition between the RESPONSE message to 2239 the EXTERNAL-PROXY and the CREATE message generated by the edge-NAT. 2240 The CREATE message can arrive earlier than the RESPONSE message. An 2241 NI+ MUST accept CREATE messages generated by the edge-NAT even if the 2242 RESPONSE message to the EXTERNAL-PROXY was not received. 2244 3.7.6.2. Proxying for a Data Receiver 2246 As with data receivers behind middleboxes, data senders behind 2247 middleboxes can require proxy mode support. The issue here is that 2248 there is no NSIS support at the data receiver's side and, by default, 2249 there will be no response to CREATE messages. This scenario requires 2250 the last NSIS NATFW NSLP aware node to terminate the forwarding and 2251 to proxy the response to the CREATE message, meaning that this node 2252 is generating RESPONSE messages. This last node may be an edge-NAT/ 2253 edge-firewall, or any other NATFW NSLP peer, that detects that there 2254 is no NR available (probably as a result of GIST timeouts but there 2255 may be other triggers). 2257 DS Private Address NAT/FW Public Internet NR 2258 NI Space NF no NR 2260 | | | 2261 | CREATE-PROXY | | 2262 |------------------------------>| | 2263 | | | 2264 | RESPONSE[SUCCESS/ERROR] | | 2265 |<------------------------------| | 2266 | | | 2268 Figure 20: Proxy Mode CREATE Message Flow 2270 The processing of CREATE-PROXY messages and RESPONSE messages is 2271 similar to Section 3.7.1, except that forwarding is stopped at the 2272 edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to 2273 NI according to the situation (error/success) and will be the NR for 2274 future NATFW NSLP communication. 2276 The NI can choose the proxy mode of operation although the DR is NSIS 2277 aware. The CREATE-PROXY mode would not configure all NATs and 2278 firewalls along the data path, since it is terminated at the edge- 2279 device. Any device beyond this point will never receive any NATFW 2280 NSLP signaling for this flow. 2282 3.8. De-Multiplexing at NATs 2284 Section 3.7.2 describes how NSIS nodes behind NATs can obtain a 2285 public reachable IP address and port number at a NAT and and how the 2286 resulting mapping rule can be activated by using CREATE messages (see 2287 Section 3.7.1). The information about the public IP address/port 2288 number can be transmitted via an application level signaling protocol 2289 and/or third party to the communication partner that would like to 2290 send data toward the host behind the NAT. However, NSIS signaling 2291 flows are sent towards the address of the NAT at which this 2292 particular IP address and port number is allocated and not directly 2293 to the allocated IP address and port number. The NATFW NSLP 2294 forwarder at this NAT needs to know how the incoming NSLP CREATE 2295 messages are related to reserved addresses, meaning how to de- 2296 multiplex incoming NSIS CREATE messages. 2298 The de-multiplexing method uses information stored at the local NATFW 2299 NSLP node and in the policy rule. The policy rule uses the LE-MRM 2300 MRI source-address (see [2]) as the flow destination IP address and 2301 the network-layer-version as IP version. The external IP address at 2302 the NAT is stored as the external flow destination IP address. All 2303 other parameters of the policy rule other than the flow destination 2304 IP address are wildcarded if no NATFW_DTINFO object is included in 2305 the EXTERNAL message. The LE-MRM MRI destination-address MUST NOT be 2306 used in the policy rule, since it is solely a signaling destination 2307 address. 2309 If the NATFW_DTINFO object is included in the EXTERNAL message, the 2310 policy rule is filled with further information. The 'dst port 2311 number' field of the NATFW_DTINFO is stored as the flow destination 2312 port number. The 'protocol' field is stored as the flow protocol. 2313 The 'src port number' field is stored as the flow source port number. 2314 The 'data sender's IPv4 address' is stored as the flow source IP 2315 address. Note that some of these field can contain wildcards. 2317 When receiving a CREATE message at the NATFW NSLP it uses the flow 2318 information stored in the MRI to do the matching process. This table 2319 shows the parameters to be compared against each others. Note that 2320 not all parameters can be present in a MRI at the same time. 2322 +-------------------------------+--------------------------------+ 2323 | Flow parameter (Policy Rule) | MRI parameter (CREATE message) | 2324 +-------------------------------+--------------------------------+ 2325 | IP version | network-layer-version | 2326 | | | 2327 | Protocol | IP-protocol | 2328 | | | 2329 | source IP address (w) | source-address (w) | 2330 | | | 2331 | external IP address | destination-address | 2332 | | | 2333 | destination IP address (n/u) | N/A | 2334 | | | 2335 | source port number (w) | L4-source-port (w) | 2336 | | | 2337 | external port number (w) | L4-destination-port (w) | 2338 | | | 2339 | destination port number (n/u) | N/A | 2340 | | | 2341 | IPsec-SPI | ipsec-SPI | 2342 +-------------------------------+--------------------------------+ 2344 Table entries marked with (w) can be wildcarded and entries marked 2345 with (n/u) are not used for the matching. 2347 Table 1 2349 3.9. Reacting to Route Changes 2351 The NATFW NSLP needs to react to route changes in the data path. 2352 This assumes the capability to detect route changes, to perform NAT 2353 and firewall configuration on the new path and possibly to tear down 2354 NATFW NSLP signaling session state on the old path. The detection of 2355 route changes is described in Section 7 of [2] and the NATFW NSLP 2356 relies on notifications about route changes by the NTLP. This 2357 notification will be conveyed by the API between NTLP and NSLP, which 2358 is out of scope of this memo. 2360 A NATFW NSLP node other than the NI or NI+ detecting a route change, 2361 by means described in the NTLP specification or others, generates a 2362 NOTIFY message indicating this change and sends this inbound towards 2363 NI. Intermediate NFs on the way to the NI can use this information 2364 to decide later if their NATFW NSLP signaling session can be deleted 2365 locally, if they do not receive an update within a certain time 2366 period, as described in Section 3.2.8. It is important to consider 2367 the transport limitations of NOTIFY messages as mandated in 2368 Section 3.7.5. 2370 The NI receiving this NOTIFY message MAY generate a new CREATE or 2371 EXTERNAL message and send it towards the NATFW NSLP signaling 2372 session's NI as for the initial message using the same session ID. 2373 All the remaining processing and message forwarding, such as NSLP 2374 next hop discovery, is subject to regular NSLP processing as 2375 described in the particular sections. Normal routing will guide the 2376 new CREATE or EXTERNAL message to the correct NFs along the changed 2377 route. NFs that were on the original path receiving these new CREATE 2378 or EXTERNAL messages (see also Section 3.10), can use the session ID 2379 to update the existing NATFW NSLP signaling session, whereas NFs that 2380 were not on the original path will create new state for this NATFW 2381 NSLP signaling session. The next section describes how policy rules 2382 are updated. 2384 3.10. Updating Policy Rules 2386 NSIS initiators can request an update of the installed/reserved 2387 policy rules at any time within a NATFW NSLP signaling session. 2388 Updates to policy rules can be required due to node mobility (NI is 2389 moving from one IP address to another), route changes (this can 2390 result in a different NAT mapping at a different NAT device), or the 2391 wish of the NI to simply change the rule. NIs can update policy 2392 rules in existing NATFW NSLP signaling sessions by sending an 2393 appropriate CREATE or EXTERNAL message (similar to Section 3.4) with 2394 modified message routing information (MRI) as compared with that 2395 installed previously, but using the existing session ID to identify 2396 the intended target of the update. With respect to authorization and 2397 authentication, this update CREATE or EXTERNAL message is treated in 2398 exactly the same way as any initial message. Therefore, any node 2399 along in the NATFW NSLP signaling session can reject the update with 2400 an error RESPONSE message, as defined in the previous sections. 2402 The message processing and forwarding is executed as defined in the 2403 particular sections. A NF or the NR receiving an update, simply 2404 replaces the installed policy rules installed in the firewall/NAT. 2405 The local procedures on how to update the MRI in the firewall/NAT is 2406 out of scope of this memo. 2408 4. NATFW NSLP Message Components 2410 A NATFW NSLP message consists of a NSLP header and one or more 2411 objects following the header. The NSLP header is carried in all 2412 NATFW NSLP messages and objects are Type-Length-Value (TLV) encoded 2413 using big endian (network ordered) binary data representations. 2414 Header and objects are aligned to 32 bit boundaries and object 2415 lengths that are not multiples of 32 bits must be padded to the next 2416 higher 32 bit multiple. 2418 The whole NSLP message is carried as payload of a NTLP message. 2420 Note that the notation 0x is used to indicate hexadecimal numbers. 2422 4.1. NSLP Header 2424 All GIST NSLP-Data objects for the NATFW NSLP MUST contain this 2425 common header as the first 32 bits of the object (this is not the 2426 same as the GIST Common Header). It contains two fields, the NSLP 2427 message type and a reserved field. The total length is 32 bits. The 2428 layout of the NSLP header is defined by Figure 21. 2430 0 1 2 3 2431 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 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 | Message type |P| reserved | reserved | 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 Figure 21: Common NSLP header 2438 The reserved field MUST be set to zero in the NATFW NSLP header 2439 before sending and MUST be ignored during processing of the header. 2441 The defined messages types are: 2443 o IANA-TBD(1) : CREATE 2445 o IANA-TBD(2) : EXTERNAL 2447 o IANA-TBD(3) : RESPONSE 2449 o IANA-TBD(4) : NOTIFY 2451 If a message with another type is received, an error RESPONSE of 2452 class 'Protocol error' (0x3) with response code 'Illegal message 2453 type' (0x01) MUST be generated. 2455 The P flag indicates the usage of proxy mode. If proxy mode is used 2456 it MUST be set to 1. Proxy mode usage MUST only be used in 2457 combination with the message types CREATE and EXTERNAL. The P flag 2458 MUST be ignored when processing messages with type RESPONSE or 2459 NOTIFY. 2461 4.2. NSLP Objects 2463 NATFW NSLP objects use a common header format defined by Figure 22. 2464 The object header contains two fields, the NSLP object type and the 2465 object length. Its total length is 32 bits. 2467 0 1 2 3 2468 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 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 Figure 22: Common NSLP object header 2475 The object length field contains the total length of the object 2476 without the object header. The unit is a word, consisting of 4 2477 octets. The particular values of type and length for each NSLP 2478 object are listed in the subsequent sections that define the NSLP 2479 objects. An error RESPONSE of class 'Protocol error' (0x3) with 2480 response code 'Wrong object length' (0x07) MUST be generated if the 2481 length given for the object in the object header did not match the 2482 length of the object data present. The two leading bits of the NSLP 2483 object header are used to signal the desired treatment for objects 2484 whose treatment has not been defined in this memo (see [2], Section 2485 A.2.1), i.e., the Object Type has not been defined. NATFW NSLP uses 2486 a subset of the categories defined in GIST: 2488 o AB=00 ("Mandatory"): If the object is not understood, the entire 2489 message containing it MUST be rejected with an error RESPONSE of 2490 class 'Protocol error' (0x3) with response code 'Unknown object 2491 present' (0x06). 2493 o AB=01 ("Optional"): If the object is not understood, it should be 2494 deleted and then the rest of the message processed as usual. 2496 o AB=10 ("Forward"): If the object is not understood, it should be 2497 retained unchanged in any message forwarded as a result of message 2498 processing, but not stored locally. 2500 The combination AB=11 MUST NOT be used and an error RESPONSE of class 2501 'Protocol error' (0x3) with response code 'Invalid Flag-Field 2502 combination' (0x09) MUST be generated. 2504 The following sections do not repeat the common NSLP object header, 2505 they just list the type and the length. 2507 4.2.1. Signaling Session Lifetime Object 2509 The signaling session lifetime object carries the requested or 2510 granted lifetime of a NATFW NSLP signaling session measured in 2511 seconds. 2513 Type: NATFW_LT (IANA-TBD) 2515 Length: 1 2517 0 1 2 3 2518 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 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | NATFW NSLP signaling session lifetime | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 Figure 23: Signaling Session Lifetime object 2525 4.2.2. External Address Object 2527 The external address object can be included in RESPONSE messages 2528 (Section 4.3.3) only. It carries the publicly reachable IP address, 2529 and if applicable port number, at an edge-NAT. 2531 Type: NATFW_EXTERNAL-IP (IANA-TBD) 2533 Length: 2 2535 0 1 2 3 2536 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 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 | port number | reserved | 2539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2540 | IPv4 address | 2541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 Figure 24: External Address Object for IPv4 addresses 2545 Please note that the field 'port number' MUST be set to 0 if only an 2546 IP address has been reserved, for instance, by a traditional NAT. A 2547 port number of 0 MUST be ignored in processing this object. 2549 4.2.3. Extended Flow Information Object 2551 In general, flow information is kept in the message routing 2552 information (MRI) of the NTLP. Nevertheless, some additional 2553 information may be required for NSLP operations. The 'extended flow 2554 information' object carries this additional information about the 2555 action of the policy rule for firewalls/NATs and contiguous port . 2557 Type: NATFW_EFI (IANA-TBD) 2559 Length: 1 2561 0 1 2 3 2562 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 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | rule action | sub_ports | 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 Figure 25: Extended Flow Information 2569 This object has two fields, 'rule action' and 'sub_ports'. The 'rule 2570 action' field has these meanings: 2572 o 0x0001: Allow: A policy rule with this action allows data traffic 2573 to traverse the middlebox and the NATFW NSLP MUST allow NSLP 2574 signaling to be forwarded. 2576 o 0x0002: Deny: A policy rule with this action blocks data traffic 2577 from traversing the middlebox and the NATFW NSLP MUST NOT allow 2578 NSLP signaling to be forwarded. 2580 If the 'rule action' field contains neither 0x0001 nor 0x0002, an 2581 error RESPONSE of class 'Signaling session failure' (0x6) with 2582 response code 'Unknown policy rule action' (0x05) MUST be generated. 2584 The 'sub_ports' field contains the number of contiguous transport 2585 layer ports to which this rule applies. The default value of this 2586 field is 0, i.e., only the port specified in the NTLP's MRM or 2587 NATFW_DTINFO object is used for the policy rule. A value of 1 2588 indicates that additionally to the port specified in the NTLP's MRM 2589 (port1), a second port (port2) is used. This value of port 2 is 2590 calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT 2591 be used in this field and an error RESPONSE of class 'Signaling 2592 session failure' (0x6) with response code 'Requested value in 2593 sub_ports field in NATFW_EFI not permitted' (0x08) MUST be generated. 2594 This two contiguous port numbered ports, can be used by legacy voice 2595 over IP equipment. This legacy equipment assumes that two adjacent 2596 port numbers for its RTP/RTCP flows respectively. 2598 4.2.4. Information Code Object 2600 This object carries the response code, which may be indications for 2601 either a successful or failed CREATE or EXTERNAL message depending on 2602 the value of the 'response code' field. 2604 Type: NATFW_INFO (IANA-TBD) 2606 Length: 1 2608 0 1 2 3 2609 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 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | Resv. | Class | Response Code |r|r|r|r| Object Type | 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 Figure 26: Information Code Object 2616 The field 'resv.' is reserved for future extensions and MUST be set 2617 to zero when generating such an object and MUST be ignored when 2618 receiving. The 'Object Type' field contains the type of the object 2619 causing the error. The value of 'Object Type' is set to 0, if no 2620 object is concerned. The leading fours bits marked with 'r' are 2621 always set to zero and ignored. The 4 bit class field contains the 2622 severity class. The following classes are defined: 2624 o 0x1: Informational (NOTIFY only) 2626 o 0x2: Success 2628 o 0x3: Protocol error 2630 o 0x4: Transient failure 2632 o 0x5: Permanent failure 2634 o 0x6: Signaling session failure 2636 Within each severity class a number of responses values are defined 2638 o Informational: 2640 * 0x01: Route change: possible route change on the outbound path. 2642 * 0x02: Re-authentication required. 2644 * 0x03: NATFW node is going down soon. 2646 * 0x04: NATFW signaling session lifetime expired. 2648 * 0x05: NATFW signaling session terminated. 2650 o Success: 2652 * 0x01: All successfully processed. 2654 o Protocol error: 2656 * 0x01: Illegal message type: the type given in the Message Type 2657 field of the NSLP header is unknown. 2659 * 0x02: Wrong message length: the length given for the message in 2660 the NSLP header does not match the length of the message data. 2662 * 0x03: Bad flags value: an undefined flag or combination of 2663 flags was set in the NSLP header. 2665 * 0x04: Mandatory object missing: an object required in a message 2666 of this type was missing. 2668 * 0x05: Illegal object present: an object was present which must 2669 not be used in a message of this type. 2671 * 0x06: Unknown object present: an object of an unknown type was 2672 present in the message. 2674 * 0x07: Wrong object length: the length given for the object in 2675 the object header did not match the length of the object data 2676 present. 2678 * 0x08: Unknown object field value: a field in an object had an 2679 unknown value. 2681 * 0x09: Invalid Flag-Field combination: An object contains an 2682 invalid combination of flags and/or fields. 2684 * 0x0A: Duplicate object present. 2686 * 0x0B: Received EXTERNAL request message on external side. 2688 o Transient failure: 2690 * 0x01: Requested resources temporarily not available. 2692 o Permanent failure: 2694 * 0x01: Authentication failed. 2696 * 0x02: Authorization failed. 2698 * 0x04: Internal or system error. 2700 * 0x06: No edge-device here. 2702 * 0x07: Did not reach the NR. 2704 o Signaling session failure: 2706 * 0x01: Session terminated asynchronously. 2708 * 0x02: Requested lifetime is too big. 2710 * 0x03: No reservation found matching the MRI of the CREATE 2711 request. 2713 * 0x04: Requested policy rule denied due to policy conflict. 2715 * 0x05: Unknown policy rule action. 2717 * 0x06: Requested rule action not applicable. 2719 * 0x07: NATFW_DTINFO object is required. 2721 * 0x08: Requested value in sub_ports field in NATFW_EFI not 2722 permitted. 2724 * 0x09: Requested IP protocol not supported. 2726 * 0x0A: Plain IP policy rules not permitted -- need transport 2727 layer information. 2729 * 0x0B: ICMP type value not permitted. 2731 * 0x0C: source IP address range is too large. 2733 * 0x0D: destination IP address range is too large. 2735 * 0x0E: source L4-port range is too large. 2737 * 0x0F: destination L4-port range is too large. 2739 * 0x10: Requested lifetime is too small. 2741 * 0x11: Modified lifetime is too big. 2743 * 0x12: Modified lifetime is too small. 2745 4.2.5. Nonce Object 2747 This object carries the nonce value as described in Section 3.7.6. 2749 Type: NATFW_NONCE (IANA-TBD) 2751 Length: 1 2753 0 1 2 3 2754 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 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 | nonce | 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 Figure 27: Nonce Object 2761 4.2.6. Message Sequence Number Object 2763 This object carries the MSN value as described in Section 3.5. 2765 Type: NATFW_MSN (IANA-TBD) 2767 Length: 1 2769 0 1 2 3 2770 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 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 | message sequence number | 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 Figure 28: Message Sequence Number Object 2777 4.2.7. Data Terminal Information Object 2779 The 'data terminal information' object carries additional information 2780 possibly needed during EXTERNAL operations. EXTERNAL messages are 2781 transported by the NTLP using the Loose-End message routing method 2782 (LE-MRM). The LE-MRM contains only DR's IP address and a signaling 2783 destination address (destination address). This destination address 2784 is used for message routing only and is not necessarily reflecting 2785 the address of the data sender. This object contains information 2786 about (if applicable) DR's port number (the destination port number), 2787 DS' port number (the source port number), the used transport 2788 protocol, the prefix length of the IP address, and DS' IP address. 2790 Type: NATFW_DTINFO (IANA-TBD) 2792 Length: variable. Maximum 3. 2794 0 1 2 3 2795 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 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2797 |I|P|S| reserved | sender prefix | protocol | 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 : DR port number | DS port number : 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 : IPsec-SPI : 2802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2803 | data sender's IPv4 address | 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 Figure 29: Data Terminal IPv4 Address Object 2808 The flags are: 2810 o I: I=1 means that 'protocol' should be interpreted. 2812 o P: P=1 means that 'dst port number' and 'src port number' are 2813 present and should be interpreted. 2815 o S: S=1 means that SPI is present and should be interpreted. 2817 The SPI field is only present if S is set. The port numbers are only 2818 present if P is set. The flags P and S MUST NOT be set at the same 2819 time. An error RESPONSE of class 'Protocol error' (0x3) with 2820 response code 'Invalid Flag-Field combination' (0x09) MUST be 2821 generated if they are both set. If either P or S is set, I MUST be 2822 set as well and the protocol field MUST carry the particular 2823 protocol. An error RESPONSE of class 'Protocol error' (0x3) with 2824 response code 'Invalid Flag-Field combination' (0x09) MUST be 2825 generated if S or P is set but I is not set. 2827 The fields MUST be interpreted according to these rules: 2829 o (data) sender prefix: This parameter indicates the prefix length 2830 of the 'data sender's IP address' in bits. For instance, a full 2831 IPv4 address requires 'sender prefix' to be set to 32. A value of 2832 0 indicates an IP address wildcard. 2834 o protocol: The IP protocol field. This field MUST be interpreted 2835 if I=1, otherwise it MUST be set to 0 and MUST be ignored. 2837 o DR port number: The port number at the data receiver (DR), i.e., 2838 the destination port. A value of 0 indicates a port wildcard, 2839 i.e., the destination port number is not known. Any other value 2840 indicates the destination port number. 2842 o DS port number: The port number at the data sender (DS), i.e., the 2843 source port. A value of 0 indicates a port wildcard, i.e., the 2844 source port number is not known. Any other value indicates the 2845 source port number. 2847 o data sender's IPv4 address: The source IP address of the data 2848 sender. This field MUST be set to zero if no IP address is 2849 provided, i.e., a complete wildcard is desired (see dest prefix 2850 field above). 2852 4.2.8. ICMP Types Object 2854 The 'ICMP types' object contains additional information needed to 2855 configure a NAT of firewall with rules to control ICMP traffic. The 2856 object contains a number of values of the ICMP Type field for which a 2857 filter action should be set up: 2859 Type: NATFW_ICMP_TYPES (IANA-TBD) 2861 Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 2863 Where DIV is an integer division. 2865 0 1 2 3 2866 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 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 | Count | Type | Type | ........ | 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2870 | ................ | 2871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2872 | ........ | Type | (Padding) | 2873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 Figure 30: ICMP Types Object 2877 The fields MUST be interpreted according to these rules: 2879 count: 8 bit integer specifying the number of 'Type' entries in 2880 the object. 2882 type: 8 bit field specifying an ICMP Type value to which this rule 2883 applies. 2885 padding: Sufficient 0 bits to pad out the last word so that the 2886 total size of object is an even multiple of words. Ignored on 2887 reception. 2889 4.3. Message Formats 2891 This section defines the content of each NATFW NSLP message type. 2892 The message types are defined in Section 4.1. 2894 Basically, each message is constructed of NSLP header and one or more 2895 NSLP objects. The order of objects is not defined, meaning that 2896 objects may occur in any sequence. Objects are marked either with 2897 mandatory (M) or optional (O). Where (M) implies that this 2898 particular object MUST be included within the message and where (O) 2899 implies that this particular object is OPTIONAL within the message. 2900 Objects defined in this memo always carry the flag combination AB=00 2901 in the NSLP object header. An error RESPONSE message of class 2902 'Protocol error' (0x3) with response code 'Mandatory object missing' 2903 (0x04) MUST be generated if a mandatory declared object is missing. 2904 An error RESPONSE message of class 'Protocol error' (0x3) with 2905 response code 'Illegal object present' (0x05) MUST be generated if an 2906 object was present which must not be used in a message of this type. 2907 An error RESPONSE message of class 'Protocol error' (0x3) with 2908 response code 'Duplicate object present' (0x0A) MUST be generated if 2909 an object appears more than once in a message. 2911 Each section elaborates the required settings and parameters to be 2912 set by the NSLP for the NTLP, for instance, how the message routing 2913 information is set. 2915 4.3.1. CREATE 2917 The CREATE message is used to create NATFW NSLP signaling sessions 2918 and to create policy rules. Furthermore, CREATE messages are used to 2919 refresh NATFW NSLP signaling sessions and to delete them. 2921 The CREATE message carries these objects: 2923 o Signaling Session Lifetime object (M) 2925 o Extended flow information object (M) 2927 o Message sequence number object (M) 2929 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 2930 (O) 2932 o ICMP Types Object (O) 2934 The message routing information in the NTLP MUST be set to DS as 2935 source address and DR as destination address. All other parameters 2936 MUST be set according the required policy rule. CREATE messages MUST 2937 be transported by using the path-coupled MRM with direction set to 2938 'downstream' (outbound). 2940 4.3.2. EXTERNAL 2942 The EXTERNAL message is used to a) reserve an external IP address/ 2943 port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to 2944 block incoming data traffic at inbound firewalls. 2946 The EXTERNAL message carries these objects: 2948 o Signaling Session Lifetime object (M) 2950 o Message sequence number object (M) 2952 o Extended flow information object (M) 2954 o Data terminal information object (M) 2956 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 2957 (O) 2959 o ICMP Types Object (O) 2960 The selected message routing method of the EXTERNAL message depends 2961 on a number of considerations. Section 3.7.2 describes it 2962 exhaustively how to select the correct method. EXTERNAL messages can 2963 be transported via the path-coupled message routing method (PC-MRM) 2964 or via the loose-end message routing method (LE-MRM). In the case of 2965 PC-MRM, the source-address is set to DS' address and the destination 2966 address is set to DR's address, the direction is set to inbound. In 2967 the case of LE-MRM, the destination-address is set to DR's address or 2968 to the signaling destination address. The source-address is set to 2969 DS's address. 2971 4.3.3. RESPONSE 2973 RESPONSE messages are responses to CREATE and EXTERNAL messages. 2974 RESPONSE messages MUST NOT be generated for any other message, such 2975 as NOTIFY and RESPONSE. 2977 The RESPONSE message for the class 'Success' (0x2) carries these 2978 objects: 2980 o Signaling Session Lifetime object (M) 2982 o Message sequence number object (M) 2984 o Information code object (M) 2986 o External address object (O) 2988 The RESPONSE message for other classes than 'Success' (0x2) carries 2989 these objects: 2991 o Message sequence number object (M) 2993 o Information code object (M) 2995 This message is routed towards the NI hop-by-hop, using existing NTLP 2996 messaging associations. The MRM used for this message MUST be the 2997 same as MRM used by the corresponding CREATE or EXTERNAL message. 2999 4.3.4. NOTIFY 3001 The NOTIFY messages is used to report asynchronous events happening 3002 along the signaled path to other NATFW NSLP nodes. 3004 The NOTIFY message carries this object: 3006 o Information code object (M). 3008 The NOTIFY message is routed towards the NI hop-by-hop using the 3009 existing inbound node messaging association entry within the node's 3010 Message Routing State table. The MRM used for this message MUST be 3011 the same as MRM used by the corresponding CREATE or EXTERNAL message. 3013 5. Security Considerations 3015 Security is of major concern particularly in case of firewall 3016 traversal. This section provides security considerations for the 3017 NAT/firewall traversal and is organized as follows. 3019 In Section 5.1 we describe how the participating entities relate to 3020 each other from a security point of view. This subsection also 3021 motivates a particular authorization model. 3023 Security threats that focus on NSIS in general are described in [8] 3024 and they are applicable to this document as well. 3026 Finally, we illustrate how the security requirements that were 3027 created based on the security threats can be fulfilled by specific 3028 security mechanisms. These aspects will be elaborated in 3029 Section 5.2. 3031 5.1. Authorization Framework 3033 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 3034 and is, as such, not a two-party protocol. Figure 1 and Figure 2 of 3035 [8] already depict the possible set of communication patterns. In 3036 this section we will re-evaluate these communication patters with 3037 respect to the NATFW NSLP protocol interaction. 3039 The security solutions for providing authorization have a direct 3040 impact on the treatment of different NSLPs. As it can be seen from 3041 the QoS NSLP [6] and the corresponding Diameter QoS work [18] 3042 accounting and charging seems to play an important role for QoS 3043 reservations, whereas monetary aspects might only indirectly effect 3044 authorization decisions for NAT and firewall signaling. Hence, there 3045 are differences in the semantic of authorization handling between QoS 3046 and NATFW signaling. A NATFW aware node will most likely want to 3047 authorize the entity (e.g., user or machine) requesting the 3048 establishment of pinholes or NAT bindings. The outcome of the 3049 authorization decision is either allowed or disallowed whereas a QoS 3050 authorization decision might indicate that a different set of QoS 3051 parameters is authorization (see [18] as an example). 3053 5.1.1. Peer-to-Peer Relationship 3055 Starting with the simplest scenario, it is assumed that neighboring 3056 nodes are able to authenticate each other and to establish keying 3057 material to protect the signaling message communication. The nodes 3058 will have to authorize each other, additionally to the 3059 authentication. We use the term 'Security Context' as a placeholder 3060 for referring to the entire security procedure, the necessary 3061 infrastructure that needs to be in place in order for this to work 3062 (e.g., key management) and the established security related state. 3063 The required long-term key (symmetric or asymmetric keys) used for 3064 authentication are either made available using an out-of-band 3065 mechanism between the two NSIS NATFW nodes or they are dynamically 3066 established using mechanisms not further specified in this document. 3067 Note that the deployment environment will most likely have an impact 3068 on the choice of credentials being used. The choice of these 3069 credentials used is also outside the scope of this document. 3071 +------------------------+ +-------------------------+ 3072 |Network A | | Network B| 3073 | +---------+ +---------+ | 3074 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3075 | | | box 1 | Security | box 2 | | | 3076 | | +---------+ Context +---------+ | | 3077 | | Security | | Security | | 3078 | | Context | | Context | | 3079 | | | | | | 3080 | +--+---+ | | +--+---+ | 3081 | | Host | | | | Host | | 3082 | | A | | | | B | | 3083 | +------+ | | +------+ | 3084 +------------------------+ +-------------------------+ 3086 Figure 31: Peer-to-Peer Relationship 3088 Figure 31 shows a possible relationship between participating NSIS 3089 aware nodes. Host A might be, for example, a host in an enterprise 3090 network that has keying material established (e.g., a shared secret) 3091 with the company's firewall (Middlebox 1). The network administrator 3092 of Network A (company network) has created access control lists for 3093 Host A (or whatever identifiers a particular company wants to use). 3094 Exactly the same procedure might also be used between Host B and 3095 Middlebox 2 in Network B. For the communication between Middlebox 1 3096 and Middlebox 2 a security context is also assumed in order to allow 3097 authentication, authorization and signaling message protection to be 3098 successful. 3100 5.1.2. Intra-Domain Relationship 3102 In larger corporations, for example, a middlebox is used to protect 3103 individual departments. In many cases, the entire enterprise is 3104 controlled by a single (or a small number of) security department, 3105 which gives instructions to the department administrators. In such a 3106 scenario, the previously discussed peer-to-peer relationship might be 3107 prevalent. Sometimes it might be necessary to preserve 3108 authentication and authorization information within the network. As 3109 a possible solution, a centralized approach could be used, whereby an 3110 interaction between the individual middleboxes and a central entity 3111 (for example a policy decision point - PDP) takes place. As an 3112 alternative, individual middleboxes exchange the authorization 3113 decision with another middlebox within the same trust domain. 3114 Individual middleboxes within an administrative domain may exploit 3115 their relationship instead of requesting authentication and 3116 authorization of the signaling initiator again and again. Figure 32 3117 illustrates a network structure which uses a centralized entity. 3119 +-----------------------------------------------------------+ 3120 | Network A | 3121 | +---------+ +---------+ 3122 | +----///--------+ Middle- +------///------++ Middle- +--- 3123 | | Security | box 2 | Security | box 2 | 3124 | | Context +----+----+ Context +----+----+ 3125 | +----+----+ | | | 3126 | | Middle- +--------+ +---------+ | | 3127 | | box 1 | | | | | 3128 | +----+----+ | | | | 3129 | | Security | +----+-----+ | | 3130 | | Context | | Policy | | | 3131 | +--+---+ +-----------+ Decision +----------+ | 3132 | | Host | | Point | | 3133 | | A | +----------+ | 3134 | +------+ | 3135 +-----------------------------------------------------------+ 3137 Figure 32: Intra-domain Relationship 3139 The interaction between individual middleboxes and a policy decision 3140 point (or AAA server) is outside the scope of this document. 3142 5.1.3. End-to-Middle Relationship 3144 The peer-to-peer relationship between neighboring NSIS NATFW NSLP 3145 nodes might not always be sufficient. Network B might require 3146 additional authorization of the signaling message initiator (in 3147 addition to the authorization of the neighboring node). If 3148 authentication and authorization information is not attached to the 3149 initial signaling message then the signaling message arriving at 3150 Middlebox 2 would result in an error message being created, which 3151 indicates the additional authorization requirement. In many cases 3152 the signaling message initiator might already be aware of the 3153 additionally required authorization before the signaling message 3154 exchange is executed. 3156 Figure 33 shows this scenario. 3158 +--------------------+ +---------------------+ 3159 | Network A | |Network B | 3160 | | Security | | 3161 | +---------+ Context +---------+ | 3162 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3163 | | | box 1 | +-------+ box 2 | | | 3164 | | +---------+ | +---------+ | | 3165 | |Security | | | Security | | 3166 | |Context | | | Context | 3167 | | | | | | | 3168 | +--+---+ | | | +--+---+ | 3169 | | Host +----///----+------+ | | Host | | 3170 | | A | | Security | | B | | 3171 | +------+ | Context | +------+ | 3172 +--------------------+ +---------------------+ 3174 Figure 33: End-to-Middle Relationship 3176 5.2. Security Framework for the NAT/Firewall NSLP 3178 The following list of security requirements has been created to 3179 ensure proper secure operation of the NATFW NSLP. 3181 5.2.1. Security Protection between neighboring NATFW NSLP Nodes 3183 Based on the analyzed threats it is RECOMMENDED to provide, between 3184 neighboring NATFW NSLP nodes, the following mechanism: 3186 o data origin authentication 3188 o replay protection 3190 o integrity protection and 3192 o optionally confidentiality protection 3194 It is RECOMMENDED to use the authentication and key exchange security 3195 mechanisms provided in [2] between neighboring nodes when sending 3196 NATFW signaling messages. The proposed security mechanisms of GIST 3197 provide support for authentication and key exchange in addition to 3198 denial of service protection. Depending on the chosen security 3199 protocol, support for multiple authentication protocols might be 3200 provided. If security between neighboring nodes is desired than the 3201 usage of C-MODE for the delivery of data packets and the usage of 3202 D-MODE only to discover the next NATFW NSLP aware node along the path 3203 is highly RECOMMENDED. Almost all security threats at the NATFW NSLP 3204 layer can be prevented by using a mutually authenticated Transport 3205 Layer secured connection and by relying on authorization by the 3206 neighboring NATFW NSLP entities. 3208 The NATFW NSLP relies on an established security association between 3209 neighboring peers to prevent unauthorized nodes to modify or delete 3210 installed state. Between non-neighboring nodes the session ID (SID) 3211 carried in the NTLP is used to show ownership of a NATFW NSLP 3212 signaling session. The session ID MUST be generated in a random way 3213 and thereby prevent an off-path adversary to mount targeted attacks. 3214 Hence, an adversary would have to learn the randomly generated 3215 session ID to perform an attack. In a mobility environment a former 3216 on-path node that is now off-path can perform an attack. Messages 3217 for a particular NATFW NSLP signaling session are handled by the NTLP 3218 to the NATFW NSLP for further processing. Messages carrying a 3219 different session ID not associated with any NATFW NSLP are subject 3220 to the regular processing for new NATFW NSLP signaling sessions. 3222 5.2.2. Security Protection between non-neighboring NATFW NSLP Nodes 3224 Based on the security threats and the listed requirements it was 3225 noted that some threats also demand authentication and authorization 3226 of a NATFW signaling entity (including the initiator) towards a non- 3227 neighboring node. This mechanism mainly demands entity 3228 authentication. The most important information exchanged at the 3229 NATFW NSLP is information related to the establishment for firewall 3230 pinholes and NAT bindings. This information can, however, not be 3231 protected over multiple NSIS NATFW NSLP hops since this information 3232 might change depending on the capability of each individual NATFW 3233 NSLP node. 3235 Some scenarios might also benefit from the usage of authorization 3236 tokens. Their purpose is to associate two different signaling 3237 protocols (e.g., SIP and NSIS) and their authorization decision. 3238 These tokens are obtained by non-NSIS protocols, such as SIP or as 3239 part of network access authentication. When a NAT or firewall along 3240 the path receives the token it might be verified locally or passed to 3241 the AAA infrastructure. Examples of authorization tokens can be 3242 found in RFC 3520 [16] and RFC 3521 [17]. Figure 34 shows an example 3243 of this protocol interaction. 3245 An authorization token is provided by the SIP proxy, which acts as 3246 the assertion generating entity and gets delivered to the end host 3247 with proper authentication and authorization. When the NATFW 3248 signaling message is transmitted towards the network, the 3249 authorization token is attached to the signaling messages to refer to 3250 the previous authorization decision. The assertion verifying entity 3251 needs to process the token or it might be necessary to interact with 3252 the assertion granting entity using HTTP (or other protocols). As a 3253 result of a successfully authorization by a NATFW NSLP node, the 3254 requested action is executed and later a RESPONSE message is 3255 generated. 3257 +----------------+ Trust Relationship +----------------+ 3258 | +------------+ |<.......................>| +------------+ | 3259 | | Protocol | | | | Assertion | | 3260 | | requesting | | HTTP, SIP Request | | Granting | | 3261 | | authz | |------------------------>| | Entity | | 3262 | | assertions | |<------------------------| +------------+ | 3263 | +------------+ | Artifact/Assertion | Entity Cecil | 3264 | ^ | +----------------+ 3265 | | | ^ ^| 3266 | | | . || HTTP, 3267 | | | Trust . || other 3268 | API Access | Relationship. || protocols 3269 | | | . || 3270 | | | . || 3271 | | | v |v 3272 | v | +----------------+ 3273 | +------------+ | | +------------+ | 3274 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3275 | | using authz| | Assertion/Artifact | | Verifying | | 3276 | | assertion | | ----------------------- | | Entity | | 3277 | +------------+ | | +------------+ | 3278 | Entity Alice | <---------------------- | Entity Bob | 3279 +----------------+ RESPONSE +----------------+ 3281 Figure 34: Authorization Token Usage 3283 Threats against the usage of authorization tokens have been mentioned 3284 in [8]. Hence, it is required to provide confidentiality protection 3285 to avoid allowing an eavesdropper to learn the token and to use it in 3286 another NATFW NSLP signaling session (replay attack). The token 3287 itself also needs to be protected against tempering. 3289 6. IAB Considerations on UNSAF 3291 UNilateral Self-Address Fixing (UNSAF) is described in [12] as a 3292 process at originating endpoints that attempt to determine or fix the 3293 address (and port) by which they are known to another endpoint. 3294 UNSAF proposals, such as STUN [14] are considered as a general class 3295 of workarounds for NAT traversal and as solutions for scenarios with 3296 no middlebox communication. 3298 This memo specifies a path-coupled middlebox communication protocol, 3299 i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are 3300 not intended as a short-term workaround, but more as a long-term 3301 solution for middlebox communication. In NSIS, endpoints are 3302 involved in allocating, maintaining, and deleting addresses and ports 3303 at the middlebox. However, the full control of addresses and ports 3304 at the middlebox is at the NATFW NSLP daemon located at the 3305 respective NAT. 3307 Therefore, this document addresses the UNSAF considerations in [12] 3308 by proposing a long-term alternative solution. 3310 7. IANA Considerations 3312 This section provides guidance to the Internet Assigned Numbers 3313 Authority (IANA) regarding registration of values related to the 3314 NATFW NSLP, in accordance with BCP 26 RFC 2434 [13]. 3316 The NATFW NSLP requires IANA to create a number of new registries. 3317 These registries may require further coordination with the registries 3318 of the NTLP [2] and the QoS NSLP [6]. 3320 NATFW NSLP Message Type Registry 3322 The NATFW NSLP Message Type is a 8 bit value. The allocation of 3323 values for new message types requires standards action. Updates and 3324 deletion of values from the registry is not possible. This 3325 specification defines four NATFW NSLP message types, which form the 3326 initial contents of this registry. IANA is requested to add these 3327 four NATFW NSLP Message Types: CREATE, EXT, RESPONSE, and NOTIFY. 3329 NATFW NSLP Header Flag Registry 3331 NATFW NSLP messages have a messages-specific 8 bit flags/reserved 3332 field in their header. The registration of flags is subject to IANA 3333 registration. The allocation of values for flag types requires 3334 standards action. Updates and deletion of values from the registry 3335 is not possible. This specification defines only one flag, the P 3336 flag in Figure 21. 3338 NSLP Object Type Registry 3340 [Delete this part if already done by another NSLP: 3342 A new registry is to be created for NSLP Message Objects. This is a 3343 12-bit field (giving values from 0 to 4095). This registry is shared 3344 between a number of NSLPs. Allocation policies are as follows: 3346 0-1023: Standards Action 3348 1024-1999: Specification Required 3350 2000-2047: Private/Experimental Use 3352 2048-4095: Reserved 3354 When a new object is defined, the extensibility bits (A/B) must also 3355 be defined.] 3357 This document defines 8 objects for the NATFW NSLP: NATFW_LT, 3358 NATFW_EXTERNAL-IP, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, 3359 NATFW_DTINFO, NATFW_ICMP_TYPES. IANA is request to assigned values 3360 for them from NSLP Object Type registry and to replace the 3361 corresponding IANA-TBD tags with the numeric values. 3363 NSLP Response Code Registry 3365 In addition it defines a number of Response Codes for the NATFW NSLP. 3366 These can be found in Section 4.2.4 and are to be assigned values 3367 from NSLP Response Code registry. The allocation of values for 3368 Response Codes Codes requires standards action. IANA is request to 3369 assigned values for them from NSLP Response Code registry. 3371 Furthermore, IANA is requested to add a new value to the NSLP 3372 Identifiers (NSLPID) registry defined in [2] for the NATFW NSLP. 3374 8. Acknowledgments 3376 We would like to thank the following individuals for their 3377 contributions to this document at different stages: 3379 o Marcus Brunner and Henning Schulzrinne for their work on IETF 3380 drafts which lead us to start with this document; 3382 o Miquel Martin for his large contribution on the initial version of 3383 this document and one of the first prototype implemenations; 3385 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3386 NAT/firewall threats draft; 3388 o Henning Peters for his comments and suggestions; 3390 o and the NSIS working group. 3392 9. References 3394 9.1. Normative References 3396 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3397 Levels", BCP 14, RFC 2119, March 1997. 3399 [2] Schulzrinne, H. and R. Hancock, "GIST: General Internet 3400 Signalling Transport", draft-ietf-nsis-ntlp-14 (work in 3401 progress), July 2007. 3403 [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 3404 August 1996. 3406 9.2. Informative References 3408 [4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3409 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 3410 June 2005. 3412 [5] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 3413 April 2004. 3415 [6] Manner, J., "NSLP for Quality-of-Service Signaling", 3416 draft-ietf-nsis-qos-nslp-15 (work in progress), July 2007. 3418 [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 3419 Rayhan, "Middlebox communication architecture and framework", 3420 RFC 3303, August 2002. 3422 [8] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 3423 Steps in Signaling (NSIS)", RFC 4081, June 2005. 3425 [9] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 3426 (NAT) Terminology and Considerations", RFC 2663, August 1999. 3428 [10] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 3429 RFC 3234, February 2002. 3431 [11] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 3432 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3433 Specification", RFC 2205, September 1997. 3435 [12] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 3436 Address Fixing (UNSAF) Across Network Address Translation", 3437 RFC 3424, November 2002. 3439 [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3440 Considerations Section in RFCs", BCP 26, RFC 2434, 3441 October 1998. 3443 [14] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 3444 - Simple Traversal of User Datagram Protocol (UDP) Through 3445 Network Address Translators (NATs)", RFC 3489, March 2003. 3447 [15] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 3448 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and 3449 S. Waldbusser, "Terminology for Policy-Based Management", 3450 RFC 3198, November 2001. 3452 [16] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 3453 Authorization Policy Element", RFC 3520, April 2003. 3455 [17] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session 3456 Set-up with Media Authorization", RFC 3521, April 2003. 3458 [18] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and 3459 G. Zorn, "Diameter Quality of Service Application", 3460 draft-ietf-dime-diameter-qos-04 (work in progress), 3461 January 2008. 3463 [19] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as 3464 firewall Signalling Protocol", Proceedings of the 6th IEEE 3465 Symposium on Computers and Communications, Hammamet, 3466 Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001. 3468 Appendix A. Selecting Signaling Destination Addresses for EXTERNAL 3470 As with all other message types, EXTERNAL messages need a reachable 3471 IP address of the data sender on the GIST level. For the path- 3472 coupled MRM the source-address of GIST is the reachable IP address 3473 (i.e., the real IP address of the data sender, or a wildcard). While 3474 this is straight forward, it is not necessarily so for the loose-end 3475 MRM. Many applications do not provide the IP address of the 3476 communication counterpart, i.e., either the data sender or both a 3477 data sender and receiver. For the EXTERNAL messages, the case of 3478 data sender is of interest only. The rest of this section gives 3479 informational guidance about determining a good destination-address 3480 of the LE-MRM in GIST for EXTERNAL messages. 3482 This signaling destination address (SDA, the destination-address in 3483 GIST) can be the data sender, but for applications which do not 3484 provide an address upfront, the destination address has to be chosen 3485 independently, as it is unknown at the time when the NATFW NSLP 3486 signaling has to start. Choosing the 'correct' destination IP 3487 address may be difficult and it is possible that there is no 'right 3488 answer' for all applications relying on the NATFW NSLP. 3490 Whenever possible it is RECOMMENDED to chose the data sender's IP 3491 address as SDA. It is necessary to differentiate between the 3492 received IP addresses on the data sender. Some application level 3493 signaling protocols (e.g., SIP) have the ability to transfer multiple 3494 contact IP addresses of the data sender. For instance, private IP 3495 address, public IP address at NAT, and public IP address at a relay. 3496 It is RECOMMENDED to use all non-private IP addresses as SDAs. 3498 A different SDA must be chosen, if the IP address of the data sender 3499 is unknown. This can have multiple reasons: The application level 3500 signaling protocol cannot determine any data sender IP address at 3501 this point of time or the data receiver is server behind a NAT, i.e., 3502 accepting inbound packets from any host. In this case, the NATFW 3503 NSLP can be instructed to use the public IP address of an application 3504 server or any other node. Choosing the SDA in this case is out of 3505 the scope of the NATFW NSLP and depends on the application's choice. 3506 The local network can provide a network-SDA, i.e., a SDA which is 3507 only meaningful to the local network. This will ensure that GIST 3508 packets with destination-address set to this network-SDA are going to 3509 be routed to a edge-NAT or edge-firewall. 3511 Appendix B. Applicability Statement on Data Receivers behind Firewalls 3513 Section 3.7.2 describes how data receivers behind middleboxes can 3514 instruct inbound firewalls/NATs to forward NATFW NSLP signaling 3515 towards them. Finding an inbound edge-NAT in address environment 3516 with NAT'ed addresses is quite easy. It is only required to find 3517 some edge-NAT, as the data traffic will be route-pinned to the NAT. 3518 Locating the appropriate edge-firewall with the PC-MRM, sent inbound 3519 is difficult. For cases with a single, symmetric route from the 3520 Internet to the data receiver, it is quite easy; simply follow the 3521 default route in the inbound direction. 3523 +------+ Data Flow 3524 +-------| EFW1 +----------+ <=========== 3525 | +------+ ,--+--. 3526 +--+--+ / \ 3527 NI+-----| FW1 | (Internet )----NR+/NI/DS 3528 NR +--+--+ \ / 3529 | +------+ `--+--' 3530 +-------| EFW2 +----------+ 3531 +------+ 3533 ~~~~~~~~~~~~~~~~~~~~~> 3534 Signaling Flow 3536 Figure 35: Data receiver behind multiple, parallel located firewalls 3538 When a data receiver, and thus NR, is located in a network site that 3539 is multihomed with several independently firewalled connections to 3540 the public Internet (as shown in Figure 35), the specific firewall 3541 through which the data traffic will be routed has to be ascertained. 3542 NATFW NSLP signaling messages sent from the NI+/NR during the 3543 EXTERNAL message exchange towards the NR+ must be routed by the NTLP 3544 to the edge-firewall that will be passed by the data traffic as well. 3545 The NTLP would need to be aware about the routing within the Internet 3546 to determine the path between DS and DR. Out of this, the NTLP could 3547 determine which of the edge-firewalls, either EFW1 or EFW2, must be 3548 selected to forward the NATFW NSLP signaling. Signaling to the wrong 3549 edge-firewall, as shown in Figure 35, would install the NATFW NSLP 3550 policy rules at the wrong device. This causes either a blocked data 3551 flow (when the policy rule is 'allow') or an ongoing attack (when the 3552 policy rule is 'deny'). Requiring the NTLP to know all about the 3553 routing within the Internet is definitely a tough challenge and 3554 usually not possible. In such described case, the NTLP must 3555 basically give up and return an error to the NSLP level, indicating 3556 that the next hop discovery is not possible. 3558 Appendix C. Firewall and NAT Resources 3560 This section gives some examples on how NATFW NSLP policy rules could 3561 be mapped to real firewall or NAT resources. The firewall rules and 3562 NAT bindings are described in a natural way, i.e., in a way one will 3563 find it in common implementations. 3565 C.1. Wildcarding of Policy Rules 3567 The policy rule/MRI to be installed can be wildcarded to some degree. 3568 Wildcarding applies to IP address, transport layer port numbers, and 3569 the IP payload (or next header in IPv6). Processing of wildcarding 3570 splits into the NTLP and the NATFW NSLP layer. The processing at the 3571 NTLP layer is independent of the NSLP layer processing and per layer 3572 constraints apply. For wildcarding in the NTLP see Section 5.8 of 3573 [2]. 3575 Wildcarding at the NATFW NSLP level is always a node local policy 3576 decision. A signaling message carrying a wildcarded MRI (and thus 3577 policy rule) arriving at an NSLP node can be rejected if the local 3578 policy does not allow the request. For instance, a MRI with IP 3579 addresses set (not wildcarded), transport protocol TCP, and TCP port 3580 numbers completely wildcarded. Now the local policy allows only 3581 requests for TCP with all ports set and not wildcarded. The request 3582 is going to be rejected. 3584 C.2. Mapping to Firewall Rules 3586 This section describes how a NSLP policy rule signaled with a CREATE 3587 message is mapped to a firewall rule. The MRI is set as follows: 3589 o network-layer-version=IPv4 3591 o source-address=192.0.2.100, prefix-length=32 3593 o destination-address=192.0.50.5, prefix-length=32 3595 o IP-protocol=UDP 3597 o L4-source-port=34543, L4-destination-port=23198 3599 The NATFW_EFI object is set to action=allow and sub_ports=0. 3601 The resulting policy rule (firewall rule) to be installed might look 3602 like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198 3604 C.3. Mapping to NAT Bindings 3606 This section describes how a NSLP policy rule signaled with a 3607 EXTERNAL message is mapped to a NAT binding. It is assumed that the 3608 EXTERNAL message is sent by a NI+ being located behind a NAT and does 3609 contain a NATFW_DTINFO object. The MRI is set following using the 3610 signaling destination address, since the IP address of the real data 3611 sender is not known: 3613 o network-layer-version=IPv4 3615 o source-address= 192.168.5.100 3617 o destination-address=SDA 3619 o IP-protocol=UDP 3621 The NATFW_EFI object is set to action=allow and sub_ports=0. The 3622 NATFW_DTINFO object contains these parameters: 3624 o P=1 3626 o dest prefix=0 3628 o protocol=UDP 3630 o dst port number = 20230, src port number=0 3632 o src IP=0.0.0.0 3634 The edge-NAT allocates the external IP 192.0.2.79 and port 45000. 3636 The resulting policy rule (NAT binding) to be installed could look 3637 like: translate udp from any to 192.0.2.79 port=45000 to 3638 192.168.5.100 port=20230 3640 C.4. NSLP Handling of Twice-NAT 3642 The dynamic configuration of twice-NATs requires application level 3643 support, as stated in Section 2.5. The NATFW NSLP cannot be used for 3644 configuring twice-NATs if application level support is needed. 3645 Assuming application level support performing the configuration of 3646 the twice-NAT and the NATFW NSLP being installed at this devices, the 3647 NATFW NSLP must be able to traverse it. The NSLP is probably able to 3648 traverse the twice-NAT, as any other data traffic, but the flow 3649 information stored in the NTLP's MRI will be invalidated through the 3650 translation of source and destination address. The NATFW NSLP 3651 implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP 3652 signaling messages as any other NATFW NSLP node does. For the given 3653 signaling flow, the NATFW NSLP node MUST look up the corresponding IP 3654 address translation and modify the NTLP/NSLP signaling accordingly. 3655 The modification results in an updated MRI with respect to the source 3656 and destination IP addresses. 3658 Appendix D. Protocols Numbers for Testing 3660 NOTE for the RFC editor: This section MUST be removed before 3661 publication. 3663 This section defines temporarily used values of the NATFW NSLP for 3664 testing the different implementations. 3666 Values for the NATFW NSLP message types: 3668 o CREATE: 0x01 3670 o EXTERNAL: 0x02 3672 o RESPONSE: 0x03 3674 o NOTIFY: 0x04 3676 Values for the NSLP object types 3678 o NATFW_LT: 0x00F1 3680 o NATFW_EXTERNAL-IP: 0x00F2 3682 o NATFW_EFI: 0x00F3 3684 o NATFW_INFO: 0x00F4 3686 o NATFW_NONCE: 0x00F5 3688 o NATFW_MSN: 0x00F6 3690 o NATFW_DTINFO: 0x00F7 3692 o NATFW_ICMP_TYPES: 0x00F9 3694 1345 3696 Authors' Addresses 3698 Martin Stiemerling 3699 NEC Europe Ltd. and University of Goettingen 3700 Kurfuersten-Anlage 36 3701 Heidelberg 69115 3702 Germany 3704 Phone: +49 (0) 6221 4342 113 3705 Email: stiemerling@netlab.nec.de 3706 URI: http://www.stiemerling.org 3708 Hannes Tschofenig 3709 Nokia Siemens Networks 3710 Linnoitustie 6 3711 Espoo 02600 3712 Finland 3714 Phone: +358 (50) 4871445 3715 Email: Hannes.Tschofenig@nsn.com 3716 URI: http://www.tschofenig.com 3718 Cedric Aoun 3719 Paris 3720 France 3722 Email: cedric@caoun.net 3724 Elwyn Davies 3725 Folly Consulting 3726 Soham 3727 UK 3729 Phone: +44 7889 488 335 3730 Email: elwynd@dial.pipex.com 3732 Full Copyright Statement 3734 Copyright (C) The IETF Trust (2008). 3736 This document is subject to the rights, licenses and restrictions 3737 contained in BCP 78, and except as set forth therein, the authors 3738 retain all their rights. 3740 This document and the information contained herein are provided on an 3741 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3742 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3743 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3744 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3745 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3746 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3748 Intellectual Property 3750 The IETF takes no position regarding the validity or scope of any 3751 Intellectual Property Rights or other rights that might be claimed to 3752 pertain to the implementation or use of the technology described in 3753 this document or the extent to which any license under such rights 3754 might or might not be available; nor does it represent that it has 3755 made any independent effort to identify any such rights. Information 3756 on the procedures with respect to rights in RFC documents can be 3757 found in BCP 78 and BCP 79. 3759 Copies of IPR disclosures made to the IETF Secretariat and any 3760 assurances of licenses to be made available, or the result of an 3761 attempt made to obtain a general license or permission for the use of 3762 such proprietary rights by implementers or users of this 3763 specification can be obtained from the IETF on-line IPR repository at 3764 http://www.ietf.org/ipr. 3766 The IETF invites any interested party to bring to its attention any 3767 copyrights, patents or patent applications, or other proprietary 3768 rights that may cover technology that may be required to implement 3769 this standard. Please address the information to the IETF at 3770 ietf-ipr@ietf.org. 3772 Acknowledgment 3774 Funding for the RFC Editor function is provided by the IETF 3775 Administrative Support Activity (IASA).