idnits 2.17.1 draft-ietf-nsis-nslp-natfw-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 3 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 9, 2010) is 5130 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Success' is mentioned on line 4017, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: Experimental H. Tschofenig 5 Expires: October 11, 2010 Nokia Siemens Networks 6 C. Aoun 7 E. Davies 8 Folly Consulting 9 April 9, 2010 11 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 12 draft-ietf-nsis-nslp-natfw-24.txt 14 Abstract 16 This memo defines the NSIS Signaling Layer Protocol (NSLP) for 17 Network Address Translators (NATs) and firewalls. This NSLP allows 18 hosts to signal on the data path for NATs and firewalls to be 19 configured according to the needs of the application data flows. For 20 instance, it enables hosts behind NATs to obtain a public reachable 21 address and hosts behind firewalls to receive data traffic. The 22 overall architecture is given by the framework and requirements 23 defined by the Next Steps in Signaling (NSIS) working group. The 24 network scenarios, the protocol itself, and examples for path-coupled 25 signaling are given in this memo. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 11, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 6 75 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 9 76 1.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 77 1.4. General Scenario for NATFW Traversal . . . . . . . . . . . 12 79 2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 14 80 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 14 81 2.2. NAT with two Private Networks . . . . . . . . . . . . . . 15 82 2.3. NAT with Private Network on Sender Side . . . . . . . . . 16 83 2.4. NAT with Private Network on Receiver Side Scenario . . . . 16 84 2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . . 17 85 2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 18 86 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 19 87 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 20 89 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 21 90 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 21 91 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 22 92 3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 22 93 3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 23 94 3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 24 95 3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 26 96 3.2.5. State and Error Maintenance . . . . . . . . . . . . . 26 97 3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 27 98 3.2.7. Classification of RESPONSE Messages . . . . . . . . . 27 99 3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 28 100 3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 29 101 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 29 102 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 33 103 3.6. Authentication, Authorization, and Policy Decisions . . . 34 104 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 34 105 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 34 106 3.7.2. Reserving External Addresses . . . . . . . . . . . . . 37 107 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 45 108 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 46 109 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 48 110 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 50 111 3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 54 112 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 56 113 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 56 115 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 58 116 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 58 117 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 59 118 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 60 119 4.2.2. External Address Object . . . . . . . . . . . . . . . 60 120 4.2.3. External Binding Address Object . . . . . . . . . . . 61 121 4.2.4. Extended Flow Information Object . . . . . . . . . . . 62 122 4.2.5. Information Code Object . . . . . . . . . . . . . . . 63 123 4.2.6. Nonce Object . . . . . . . . . . . . . . . . . . . . . 66 124 4.2.7. Message Sequence Number Object . . . . . . . . . . . . 66 125 4.2.8. Data Terminal Information Object . . . . . . . . . . . 67 126 4.2.9. ICMP Types Object . . . . . . . . . . . . . . . . . . 68 127 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 69 128 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 70 129 4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 70 130 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 71 131 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 71 133 5. Security Considerations . . . . . . . . . . . . . . . . . . . 73 134 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 73 135 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 73 136 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 74 137 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 75 138 5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 76 139 5.2.1. Security Protection between neighboring NATFW NSLP 140 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 76 141 5.2.2. Security Protection between non-neighboring NATFW 142 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 77 143 5.3. Implementation of NATFW NSLP Security . . . . . . . . . . 78 145 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 80 147 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 148 7.1. NATFW NSLP Message Type Registry . . . . . . . . . . . . . 81 149 7.2. NATFW NSLP Header Flag Registry . . . . . . . . . . . . . 81 150 7.3. NSLP Object Type Registry . . . . . . . . . . . . . . . . 81 151 7.4. NSLP Response Code Registry . . . . . . . . . . . . . . . 82 152 7.5. NSLP IDs and Router Alert Option Values . . . . . . . . . 82 154 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 156 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 157 9.1. Normative References . . . . . . . . . . . . . . . . . . . 85 158 9.2. Informative References . . . . . . . . . . . . . . . . . . 85 160 Appendix A. Selecting Signaling Destination Addresses for 161 EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 87 163 Appendix B. Usage of External Binding Addresses . . . . . . . . . 88 165 Appendix C. Applicability Statement on Data Receivers behind 166 Firewalls . . . . . . . . . . . . . . . . . . . . . . 89 168 Appendix D. Firewall and NAT Resources . . . . . . . . . . . . . 91 169 D.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 91 170 D.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 91 171 D.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 92 172 D.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 92 174 Appendix E. Example for Receiver Proxy Case . . . . . . . . . . . 94 176 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 98 178 1. Introduction 180 1.1. Scope and Background 182 Firewalls and Network Address Translators (NAT) have both been used 183 throughout the Internet for many years, and they will remain present 184 for the foreseeable future. Firewalls are used to protect networks 185 against certain types of attacks from internal networks and the 186 Internet, whereas NATs provide a virtual extension of the IP address 187 space. Both types of devices may be obstacles to some applications, 188 since they only allow traffic created by a limited set of 189 applications to traverse them, typically those that use protocols 190 with relatively predetermined and static properties (e.g., most HTTP 191 traffic, and other client/server applications). Other applications, 192 such as IP telephony and most other peer-to-peer applications, which 193 have more dynamic properties, create traffic that is unable to 194 traverse NATs and firewalls unassisted. In practice, the traffic of 195 many applications cannot traverse autonomous firewalls or NATs, even 196 when they have additional functionality which attempts to restore the 197 transparency of the network. 199 Several solutions to enable applications to traverse such entities 200 have been proposed and are currently in use. Typically, application 201 level gateways (ALG) have been integrated with the firewall or NAT to 202 configure the firewall or NAT dynamically. Another approach is 203 middlebox communication (MIDCOM). In this approach, ALGs external to 204 the firewall or NAT configure the corresponding entity via the MIDCOM 205 protocol [RFC3303]. Several other work-around solutions are 206 available, such as STUN [RFC5389]. However, all of these approaches 207 introduce other problems that are generally hard to solve, such as 208 dependencies on the type of NAT implementation (full-cone, symmetric, 209 etc), or dependencies on certain network topologies. 211 NAT and firewall (NATFW) signaling shares a property with Quality of 212 Service (QoS) signaling. The signaling of both must reach any device 213 on the data path that is involved in, respectively, NATFW or QoS 214 treatment of data packets. This means, that for both, NATFW and QoS, 215 it is convenient if signaling travels path-coupled, meaning that the 216 signaling messages follow exactly the same path that the data packets 217 take. RSVP [RFC2205] is an example of a current QoS signaling 218 protocol that is path-coupled. [rsvp-firewall] proposes the use of 219 RSVP as firewall signaling protocol but does not include NATs. 221 This memo defines a path-coupled signaling protocol for NAT and 222 firewall configuration within the framework of NSIS, called the NATFW 223 NSIS Signaling Layer Protocol (NSLP). The general requirements for 224 NSIS are defined in [RFC3726] and the general framework of NSIS is 225 outlined in [RFC4080]. It introduces the split between an NSIS 226 transport layer and an NSIS signaling layer. The transport of NSLP 227 messages is handled by an NSIS Network Transport Layer Protocol 228 (NTLP, with General Internet Signaling Transport (GIST) 229 [I-D.ietf-nsis-ntlp] being the implementation of the abstract NTLP). 230 The signaling logic for QoS and NATFW signaling is implemented in the 231 different NSLPs. The QoS NSLP is defined in 232 [I-D.ietf-nsis-qos-nslp]. 234 The NATFW NSLP is designed to request the dynamic configuration of 235 NATs and/or firewalls along the data path. Dynamic configuration 236 includes enabling data flows to traverse these devices without being 237 obstructed, as well as blocking of particular data flows at inbound 238 firewalls. Enabling data flows requires the loading of firewall 239 rules with an action that allows the data flow packets to be 240 forwarded and creating NAT bindings. Blocking of data flows requires 241 the loading of firewalls rules with an action that will deny 242 forwarding of the data flow packets. A simplified example for 243 enabling data flows: A source host sends a NATFW NSLP signaling 244 message towards its data destination. This message follows the data 245 path. Every NATFW NSLP-enabled NAT/firewall along the data path 246 intercepts this message, processes them, and configures itself 247 accordingly. Thereafter, the actual data flow can traverse all these 248 configured firewalls/NATs. 250 It is necessary to distinguish between two different basic scenarios 251 when operating the NATFW NSLP, independent of the type of the 252 middleboxes to be configured. 254 1. Both, data sender and data receiver, are NSIS NATFW NSLP aware. 255 This includes the cases where the data sender is logically 256 decomposed from the initiator of the NSIS signaling (the so- 257 called NSIS initiator) or the data receiver logically decomposed 258 from the receiver of the NSIS signaling (the so-called NSIS 259 receiver), but both sides support NSIS. This scenario assumes 260 deployment of NSIS all over the Internet, or at least at all NATs 261 and firewalls. This scenario is used as base assumption, if not 262 otherwise noted. 264 2. Only one end host or region of the network is NSIS NATFW NSLP 265 aware, either data receiver or data sender. This scenario is 266 referred to as proxy mode. 268 The NATFW NSLP has two basic signaling messages which are sufficient 269 to cope with the various possible scenarios likely to be encountered 270 before and after widespread deployment of NSIS: 272 CREATE message: Sent by the data sender for configuring a path 273 outbound from a data sender to a data receiver. 275 EXTERNAL message: Used by data receiver to locate inbound NATs/ 276 firewalls and prime them to expect inbound signaling and at NATs 277 to pre-allocate a public address. This is used for data receivers 278 behind these devices to enable their reachability. 280 CREATE and EXTERNAL messages are sent by the NSIS initiator (NI) 281 towards the NSIS responder (NR). Both type of messages are 282 acknowledged by a subsequent RESPONSE message. This RESPONSE message 283 is generated by the NR if the requested configuration can be 284 established, otherwise the NR or any of the NSIS forwarders (NFs) can 285 also generate such a message if an error occurs. NFs and the NR can 286 also generate asynchronous messages to notify the NI, the so called 287 NOTIFY messages. 289 If the data receiver resides in a private addressing realm or behind 290 a firewall, and needs to preconfigure the edge-NAT/edge-firewall to 291 provide a (publicly) reachable address for use by the data sender, a 292 combination of EXTERNAL and CREATE messages is used. 294 During the introduction of NSIS, it is likely that one or the other 295 of the data sender and receiver will not be NSIS aware. In these 296 cases, the NATFW NSLP can utilize NSIS aware middleboxes on the path 297 between the data sender and data receiver to provide proxy NATFW NSLP 298 services (i.e., the proxy mode). Typically, these boxes will be at 299 the boundaries of the realms in which the end hosts are located. 301 The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in 302 NSIS entities. NTLP state allows signaling messages to travel in the 303 forward (outbound) and the reverse (inbound) direction along the path 304 between a NAT/firewall NSLP sender and a corresponding receiver. 305 This state is managed using a soft-state mechanism, i.e., it expires 306 unless it is refreshed from time to time. The NAT bindings and 307 firewall rules being installed during the state setup are bound to 308 the particular signaling session. However, the exact local 309 implementation of the NAT bindings and firewall rules are NAT/ 310 firewall specific and it is out of scope of this memo. 312 This memo is structured as follows. Section 2 describes the network 313 environment for NATFW NSLP signaling. Section 3 defines the NATFW 314 signaling protocol and Section 4 defines the message components and 315 the overall messages used in the protocol. The remaining parts of 316 the main body of the document cover security considerations 317 Section 5, IAB considerations on UNilateral Self-Address Fixing 318 (UNSAF) [RFC3424] in Section 6 and IANA considerations in Section 7. 319 Please note that readers familiar with firewalls and NATs and their 320 possible location within networks can safely skip Section 2. 322 1.2. Terminology and Abbreviations 324 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 325 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 326 document are to be interpreted as described in [RFC2119]. 328 This document uses a number of terms defined in [RFC3726] and 329 [RFC4080]. The following additional terms are used: 331 o Policy rule: A policy rule is "a basic building block of a policy- 332 based system. It is the binding of a set of actions to a set of 333 conditions - where the conditions are evaluated to determine 334 whether the actions are performed" [RFC3198]. In the context of 335 NSIS NATFW NSLP, the conditions are the specification of a set of 336 packets to which the rule is applied. The set of actions always 337 contains just a single element per rule, and is limited to either 338 action "deny" or action "allow". 340 o Reserved policy rule: A policy rule stored at NATs or firewalls 341 for activation by a later, different signaling exchange. This 342 type of policy rule is kept in the NATFW NSLP and is not loaded 343 into the firewall or NAT engine, i.e., it does not affect the data 344 flow handling. 346 o Installed policy rule: A policy rule in operation at NATs or 347 firewalls. This type of rule is kept in the NATFW NSLP and is 348 loaded into the firewall or NAT engine, i.e., it is affecting the 349 data flow. 351 o Remembered policy rule: A policy rule stored at NATs and firewalls 352 for immediate use, as soon as the signaling exchange is 353 successfully completed. 355 o Firewall: A packet filtering device that matches packets against a 356 set of policy rules and applies the actions. 358 o Network Address Translator: Network Address Translation is a 359 method by which IP addresses are mapped from one IP address realm 360 to another, in an attempt to provide transparent routing between 361 hosts (see [RFC2663]). Network Address Translators are devices 362 that perform this work by modifying packets passing through them. 364 o Data Receiver (DR): The node in the network that is receiving the 365 data packets of a flow. 367 o Data Sender (DS): The node in the network that is sending the data 368 packets of a flow. 370 o NATFW NSLP peer or peer: An NSIS NATFW NSLP node with which an 371 NTLP adjacency has been created as defined in 372 [I-D.ietf-nsis-ntlp]. 374 o NATFW NSLP signaling session or signaling session: A signaling 375 session defines an association between the NI, NFs, and the NR 376 related to a data flow. All the NATFW NSLP peers on the path, 377 including the NI and the NR, use the same identifier to refer to 378 the state stored for the association. The same NI and NR may have 379 more than one signaling session active at any time. The state for 380 NATFW NSLP consists of NSLP state and associated policy rules at a 381 middlebox. 383 o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP 384 address which is reachable from the public Internet. 386 o Edge-firewall: An edge-firewall is a firewall device that is 387 located on the border line of an administrative domain. 389 o Public Network: "A Global or Public Network is an address realm 390 with unique network addresses assigned by Internet Assigned 391 Numbers Authority (IANA) or an equivalent address registry. This 392 network is also referred as external network during NAT 393 discussions" [RFC2663]. 395 o Private/Local Network: "A private network is an address realm 396 independent of external network addresses. Private network may 397 also be referred alternately as Local Network. Transparent 398 routing between hosts in private realm and external realm is 399 facilitated by a NAT router" [RFC2663]. 401 o Public/Global IP address: An IP address located in the public 402 network according to Section 2.7 of [RFC2663]. 404 o Private/Local IP address: An IP address located in the private 405 network according to Section 2.8 of [RFC2663]. 407 o Signaling Destination Address (SDA): An IP address generally taken 408 from the public/global IP address range, although, the SDA may in 409 certain circumstances be part of the private/local IP address 410 range. This address is used in EXTERNAL signaling message 411 exchanges, if the data receiver's IP address is unknown. 413 1.3. Middleboxes 415 The term middlebox covers a range of devices and is well-defined in 416 [RFC3234]: "A middlebox is defined as any intermediate device 417 performing functions other than the normal, standard functions of an 418 IP router on the datagram path between source host and a destination 419 host". As such, middleboxes fall into a number of categories with a 420 wide range of functionality, not all of which is pertinent to the 421 NATFW NSLP. Middlebox categories in the scope of this memo are 422 firewalls that filter data packets against a set of filter rules, and 423 NATs that translate packet addresses from one address realm to 424 another address realm. Other categories of middleboxes, such as QoS 425 traffic shapers, are out of scope of this memo. 427 The term NAT used in this document is a placeholder for a range of 428 different NAT flavors. We consider the following types of NATs: 430 o Traditional NAT (basic NAT and NAPT) 432 o Bi-directional NAT 434 o Twice-NAT 436 o Multihomed NAT 438 For definitions and a detailed discussion about the characteristics 439 of each NAT type please see [RFC2663]. 441 All types of middleboxes under consideration here, use policy rules 442 to make a decision on data packet treatment. Policy rules consist of 443 a flow identifier which selects the packets to which the policy 444 applies and an associated action; data packets matching the flow 445 identifier are subjected to the policy rule action. A typical flow 446 identifier is the 5-tuple selector which matches the following fields 447 of a packet to configured values: 449 o Source and destination IP addresses 451 o Transport protocol number 453 o Transport source and destination port numbers 455 Actions for firewalls are usually one or more of: 457 o Allow: forward data packet 459 o Deny: block data packet and discard it 461 o Other actions such as logging, diverting, duplicating, etc 463 Actions for NATs include (amongst many others): 465 o Change source IP address and transport port number to a globally 466 routable IP address and associated port number. 468 o Change destination IP address and transport port number to a 469 private IP address and associated port number. 471 It should be noted that a middlebox may contain two logical 472 representations of the policy rule. The policy rule has a 473 representation within the NATFW NSLP, comprising the message routing 474 information (MRI) of the NTLP and NSLP information (such as the rule 475 action). The other representation is the implementation of the NATFW 476 NSLP policy rule within the NAT and firewall engine of the particular 477 device. Refer to Appendix D for further details. 479 1.4. General Scenario for NATFW Traversal 481 The purpose of NSIS NATFW signaling is to enable communication 482 between endpoints across networks, even in the presence of NAT and 483 firewall middleboxes that have not been specially engineered to 484 facilitate communication with the application protocols used. This 485 removes the need to create and maintain application layer gateways 486 for specific protocols that have been commonly used to provide 487 transparency in previous generations of NAT and firewall middleboxes. 488 It is assumed that these middleboxes will be statically configured in 489 such a way that NSIS NATFW signaling messages themselves are allowed 490 to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP 491 signaling is used to dynamically install additional policy rules in 492 all NATFW middleboxes along the data path that will allow 493 transmission of the application data flow(s). Firewalls are 494 configured to forward data packets matching the policy rule provided 495 by the NSLP signaling. NATs are configured to translate data packets 496 matching the policy rule provided by the NSLP signaling. An 497 additional capability, that is an exception to the primary goal of 498 NSIS NATFW signaling, is that the NATFW nodes can request blocking of 499 particular data flows instead of enabling these flows at inbound 500 firewalls. 502 The basic high-level picture of NSIS usage is that end hosts are 503 located behind middleboxes, meaning that there is at least one 504 middlebox on the data path from the end host in a private network to 505 the external network (NATFW in Figure 1). Applications located at 506 these end hosts try to establish communication with corresponding 507 applications on other such end hosts. This communication 508 establishment may require that the applications contact an 509 application server which serves as a rendezvous point between both 510 parties to exchange their IP address and port(s). The local 511 applications trigger the NSIS entity at the local host to control 512 provisioning for middlebox traversal along the prospective data path 513 (e.g., via an API call). The NSIS entity in turn uses NSIS NATFW 514 NSLP signaling to establish policy rules along the data path, 515 allowing the data to travel from the sender to the receiver 516 unobstructed. 518 Application Application Server (0, 1, or more) Application 520 +----+ +----+ +----+ 521 | +------------------------+ +------------------------+ | 522 +-+--+ +----+ +-+--+ 523 | | 524 | NSIS Entities NSIS Entities | 525 +-+--+ +----+ +-----+ +-+--+ 526 | +--------+ +----------------------------+ +-----+ | 527 +-+--+ +-+--+ +--+--+ +-+--+ 528 | | ------ | | 529 | | //// \\\\\ | | 530 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 531 | | | | | Internet | | | | | 532 | +--------+ +-----+ +----+ +-----+ | 533 +----+ +----+ |\ | +----+ +----+ 534 \\\\ ///// 535 sender NATFW (1+) ------ NATFW (1+) receiver 537 Note that 1+ refers to one or more NATFW nodes. 539 Figure 1: Generic View of NSIS with NATs and/or firewalls 541 For end-to-end NATFW signaling, it is necessary that each firewall 542 and each NAT along the path between the data sender and the data 543 receiver implements the NSIS NATFW NSLP. There might be several NATs 544 and FWs in various possible combinations on a path between two hosts. 545 Section 2 presents a number of likely scenarios with different 546 combinations of NATs and firewalls. However, the scenarios given in 547 the following sections are not limiting the scope of the NATFW NSLP 548 to them only, but they are examples only. 550 2. Network Deployment Scenarios using the NATFW NSLP 552 This section introduces several scenarios for middlebox placement 553 within IP networks. Middleboxes are typically found at various 554 different locations, including at enterprise network borders, within 555 enterprise networks, as mobile phone network gateways, etc. Usually, 556 middleboxes are placed more towards the edge of networks than in 557 network cores. Firewalls and NATs may be found at these locations 558 either alone, or they may be combined; other categories of 559 middleboxes may also be found at such locations, possibly combined 560 with the NATs and/or firewalls. 562 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 563 regular data path to the NSIS responder (NR). On the data path, 564 NATFW NSLP signaling messages reach different NSIS nodes that 565 implement the NATFW NSLP. Each NATFW NSLP node processes the 566 signaling messages according to Section 3 and, if necessary, installs 567 policy rules for subsequent data packets. 569 Each of the following sub-sections introduces a different scenario 570 for a different set of middleboxes and their ordering within the 571 topology. It is assumed that each middlebox implements the NSIS 572 NATFW NSLP signaling protocol. 574 2.1. Firewall Traversal 576 This section describes a scenario with firewalls only; NATs are not 577 involved. Each end host is behind a firewall. The firewalls are 578 connected via the public Internet. Figure 2 shows the topology. The 579 part labeled "public" is the Internet connecting both firewalls. 581 +----+ //----\\ +----+ 582 NI -----| FW |---| |------| FW |--- NR 583 +----+ \\----// +----+ 585 private public private 587 FW: Firewall 588 NI: NSIS Initiator 589 NR: NSIS Responder 591 Figure 2: Firewall Traversal Scenario 593 Each firewall on the data path must provide traversal service for 594 NATFW NSLP in order to permit the NSIS message to reach the other end 595 host. All firewalls process NSIS signaling and establish appropriate 596 policy rules, so that the required data packet flow can traverse 597 them. 599 There are several very different ways to place firewalls in a network 600 topology. To distinguish firewalls located at network borders, such 601 as administrative domains, from others located internally, the term 602 edge-firewall is used. A similar distinction can be made for NATs, 603 with an edge-NAT fulfilling the equivalent role. 605 2.2. NAT with two Private Networks 607 Figure 3 shows a scenario with NATs at both ends of the network. 608 Therefore, each application instance, the NSIS initiator and the NSIS 609 responder, are behind NATs. The outermost NAT, known as the edge-NAT 610 (MB2 and MB3), at each side is connected to the public Internet. The 611 NATs are generically labeled as MBX (for middlebox No. X), since 612 those devices certainly implement NAT functionality, but can 613 implement firewall functionality as well. 615 Only two middleboxes MB are shown in Figure 3 at each side, but in 616 general, any number of MBs on each side must be considered. 618 +----+ +----+ //----\\ +----+ +----+ 619 NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR 620 +----+ +----+ \\----// +----+ +----+ 622 private public private 624 MB: Middlebox 625 NI: NSIS Initiator 626 NR: NSIS Responder 628 Figure 3: NAT with two Private Networks Scenario 630 Signaling traffic from NI to NR has to traverse all the middleboxes 631 on the path (MB1 to MB4, in this order), and all the middleboxes must 632 be configured properly to allow NSIS signaling to traverse them. The 633 NATFW signaling must configure all middleboxes and consider any 634 address translation that will result from this configuration in 635 further signaling. The sender (NI) has to know the IP address of the 636 receiver (NR) in advance, otherwise it will not be possible to send 637 any NSIS signaling messages towards the responder. Note that this IP 638 address is not the private IP address of the responder but the NAT's 639 public IP address (here MB3's IP address). Instead a NAT binding 640 (including a public IP address) has to be previously installed on the 641 NAT MB3. This NAT binding subsequently allows packets reaching the 642 NAT to be forwarded to the receiver within the private address realm. 644 The receiver might have a number of ways to learn its public IP 645 address and port number (including the NATFW NSLP) and might need to 646 signal this information to the sender using an application level 647 signaling protocol. 649 2.3. NAT with Private Network on Sender Side 651 This scenario shows an application instance at the sending node that 652 is behind one or more NATs (shown as generic MB, see discussion in 653 Section 2.2). The receiver is located in the public Internet. 655 +----+ +----+ //----\\ 656 NI --| MB |-----| MB |---| |--- NR 657 +----+ +----+ \\----// 659 private public 661 MB: Middlebox 662 NI: NSIS Initiator 663 NR: NSIS Responder 665 Figure 4: NAT with Private Network on Sender Side 667 The traffic from NI to NR has to traverse middleboxes only on the 668 sender's side. The receiver has a public IP address. The NI sends 669 its signaling message directly to the address of the NSIS responder. 670 Middleboxes along the path intercept the signaling messages and 671 configure accordingly. 673 The data sender does not necessarily know whether the receiver is 674 behind a NAT or not, hence, it is the receiving side that has to 675 detect whether itself is behind a NAT or not. 677 2.4. NAT with Private Network on Receiver Side Scenario 679 The application instance receiving data is behind one or more NATs 680 shown as MB (see discussion in Section 2.2). 682 //----\\ +----+ +----+ 683 NI ---| |---| MB |-----| MB |--- NR 684 \\----// +----+ +----+ 686 public private 688 MB: Middlebox 689 NI: NSIS Initiator 690 NR: NSIS Responder 692 Figure 5: NAT with Private Network on Receiver Scenario 694 Initially, the NSIS responder must determine its publicly reachable 695 IP address at the external middlebox and notify the NSIS initiator 696 about this address. One possibility is that an application level 697 protocol is used, meaning that the public IP address is signaled via 698 this protocol to the NI. Afterwards the NI can start its signaling 699 towards the NR and therefore establish the path via the middleboxes 700 in the receiver side private network. 702 This scenario describes the use case for the EXTERNAL message of the 703 NATFW NSLP. 705 2.5. Both End Hosts behind twice-NATs 707 This is a special case, where the main problem arises from the need 708 to detect that both end hosts are logically within the same address 709 space, but are also in two partitions of the address realm on either 710 side of a twice-NAT (see [RFC2663] for a discussion of twice-NAT 711 functionality). 713 Sender and receiver are both within a single private address realm 714 but the two partitions potentially have overlapping IP address 715 ranges. Figure 6 shows the arrangement of NATs. 717 public 719 +----+ +----+ //----\\ 720 NI --| MB |--+--| MB |---| | 721 +----+ | +----+ \\----// 722 | 723 | +----+ 724 +--| MB |------------ NR 725 +----+ 727 private 729 MB: Middlebox 730 NI: NSIS Initiator 731 NR: NSIS Responder 733 Figure 6: NAT to Public, Sender and Receiver on either side of a 734 twice-NAT Scenario 736 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 737 addresses and port numbers on both sides, meaning the mapping of 738 source and destination address at the private and public interfaces. 740 This scenario requires the assistance of application level entities, 741 such as a DNS server. The application level entities must handle 742 requests that are based on symbolic names, and configure the 743 middleboxes so that data packets are correctly forwarded from NI to 744 NR. The configuration of those middleboxes may require other 745 middlebox communication protocols, such as MIDCOM [RFC3303]. NSIS 746 signaling is not required in the twice-NAT only case, since 747 middleboxes of the twice-NAT type are normally configured by other 748 means. Nevertheless, NSIS signaling might be useful when there are 749 also firewalls on the path. In this case NSIS will not configure any 750 policy rule at twice-NATs, but will configure policy rules at the 751 firewalls on the path. The NSIS signaling protocol must be at least 752 robust enough to survive this scenario. This requires that twice- 753 NATs must implement the NATFW NSLP also and participate in NATFW 754 signaling sessions but they do not change the configuration of the 755 NAT, i.e., they only read the address mapping information out of the 756 NAT and translate the Message Routing Information (MRI, 757 [I-D.ietf-nsis-ntlp]) within the NSLP and NTLP accordingly. For more 758 information see Appendix D.4 760 2.6. Both End Hosts Behind Same NAT 762 When NSIS initiator and NSIS responder are behind the same NAT (thus 763 being in the same address realm, see Figure 7), they are most likely 764 not aware of this fact. As in Section 2.4 the NSIS responder must 765 determine its public IP address in advance and transfer it to the 766 NSIS initiator. Afterwards, the NSIS initiator can start sending the 767 signaling messages to the responder's public IP address. During this 768 process, a public IP address will be allocated for the NSIS initiator 769 at the same middlebox as for the responder. Now, the NSIS signaling 770 and the subsequent data packets will traverse the NAT twice: from 771 initiator to public IP address of responder (first time) and from 772 public IP address of responder to responder (second time). 774 NI public 775 \ +----+ //----\\ 776 +-| MB |----| | 777 / +----+ \\----// 778 NR 779 private 781 MB: Middlebox 782 NI: NSIS Initiator 783 NR: NSIS Responder 785 Figure 7: NAT to Public, Both Hosts Behind Same NAT 787 2.7. Multihomed Network with NAT 789 The previous sub-sections sketched network topologies where several 790 NATs and/or firewalls are ordered sequentially on the path. This 791 section describes a multihomed scenario with two NATs placed on 792 alternative paths to the public network. 794 +----+ //---\\ 795 NI -------| MB |---| | 796 \ +----+ \\-+-// 797 \ | 798 \ +----- NR 799 \ | 800 \ +----+ //-+-\\ 801 --| MB |---| | 802 +----+ \\---// 804 private public 806 MB: Middlebox 807 NI: NSIS Initiator 808 NR: NSIS Responder 810 Figure 8: Multihomed Network with Two NATs 812 Depending on the destination, either one or the other middlebox is 813 used for the data flow. Which middlebox is used, depends on local 814 policy or routing decisions. NATFW NSLP must be able to handle this 815 situation properly, see Section 3.7.2 for an extended discussion of 816 this topic with respect to NATs. 818 2.8. Multihomed Network with Firewall 820 This section describes a multihomed scenario with two firewalls 821 placed on alternative paths to the public network (Figure 9). The 822 routing in the private and public network decides which firewall is 823 being taken for data flows. Depending on the data flow's direction, 824 either outbound or inbound, a different firewall could be traversed. 825 This is a challenge for the EXTERNAL message of the NATFW NSLP where 826 the NSIS responder is located behind these firewalls within the 827 private network. The EXTERNAL message is used to block a particular 828 data flow on an inbound firewall. NSIS must route the EXTERNAL 829 message inbound from NR to NI probably without knowing which path the 830 data traffic will take from NI to NR (see also Appendix C). 832 +----+ 833 NR -------| FW |\ 834 \ +----+ \ //---\\ 835 \ -| |-- NI 836 \ \\---// 837 \ +----+ | 838 --| FW |-------+ 839 +----+ 840 private 842 private public 844 FW: Firewall 845 NI: NSIS Initiator 846 NR: NSIS Responder 848 Figure 9: Multihomed Network with two firewalls 850 3. Protocol Description 852 This section defines messages, objects, and protocol semantics for 853 the NATFW NSLP. 855 3.1. Policy Rules 857 Policy rules, bound to a NATFW NSLP signaling session, are the 858 building blocks of middlebox devices considered in the NATFW NSLP. 859 For firewalls the policy rule usually consists of a 5-tuple and an 860 action such as allow or deny. The information contained in the tuple 861 includes source/destination addresses, transport protocol and source/ 862 destination port numbers. For NATs the policy rule consists of the 863 action 'translate this address' and further mapping information, that 864 might be, in the simplest case, internal IP address and external IP 865 address. 867 The NATFW NSLP carries, in conjunction with the NTLP's Message 868 Routing Information (MRI), the policy rules to be installed at NATFW 869 peers. This policy rule is an abstraction with respect to the real 870 policy rule to be installed at the respective firewall or NAT. It 871 conveys the initiator's request and must be mapped to the possible 872 configuration on the particular used NAT and/or firewall in use. For 873 pure firewalls one or more filter rules must be created and for pure 874 NATs one or more NAT bindings must be created. In mixed firewall and 875 NAT boxes, the policy rule must be mapped to filter rules and 876 bindings observing the ordering of the firewall and NAT engine. 877 Depending on the ordering, NAT before firewall or vice versa, the 878 firewall rules must carry public or private IP addresses. However, 879 the exact mapping depends on the implementation of the firewall or 880 NAT which is possibly different for each implementation. 882 The policy rule at the NATFW NSLP level comprises the message routing 883 information (MRI) part, carried in the NTLP, and the information 884 available in the NATFW NSLP. The information provided by the NSLP is 885 stored in the 'extend flow information' (NATFW_EFI) and 'data 886 terminal information' (NATFW_DTINFO) objects, and the message type. 887 Additional information, such as the external IP address and port 888 number, stored in the NAT or firewall, will be used as well. The MRI 889 carries the filter part of the NAT/firewall-level policy rule that is 890 to be installed. 892 The NATFW NSLP specifies two actions for the policy rules: deny and 893 allow. A policy rule with action set to deny will result in all 894 packets matching this rule to be dropped. A policy rule with action 895 set to allow will result in all packets matching this rule to be 896 forwarded. 898 3.2. Basic Protocol Overview 900 The NSIS NATFW NSLP is carried over the General Internet Signaling 901 Transport (GIST, the implementation of the NTLP) defined in 902 [I-D.ietf-nsis-ntlp]. NATFW NSLP messages are initiated by the NSIS 903 initiator (NI), handled by NSIS forwarders (NF) and received by the 904 NSIS responder (NR). It is required that at least NI and NR 905 implement this NSLP, intermediate NFs only implement this NSLP when 906 they provide relevant middlebox functions. NSIS forwarders that do 907 not have any NATFW NSLP functions just forward these packets as they 908 have no interest in them. 910 3.2.1. Signaling for Outbound Traffic 912 A Data Sender (DS), intending to send data to a Data Receiver (DR) 913 has to start NATFW NSLP signaling. This causes the NI associated 914 with the data sender (DS) to launch NSLP signaling towards the 915 address of data receiver (DR) (see Figure 10). Although it is 916 expected that the DS and the NATFW NSLP NI will usually reside on the 917 same host, this specification does not rule out scenarios where the 918 DS and NI reside on different hosts, the so-called proxy mode (see 919 Section 3.7.6.) 921 +-------+ +-------+ +-------+ +-------+ 922 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 923 | |--->| NF1 |--->| NF2 |--->| | 924 +-------+ +-------+ +-------+ +-------+ 926 ========================================> 927 Data Traffic Direction (outbound) 929 ---> : NATFW NSLP request signaling 930 ~~~> : NATFW NSLP response signaling 931 DS/NI : Data sender and NSIS initiator 932 DR/NR : Data receiver and NSIS responder 933 MB1 : Middlebox 1 and NSIS forwarder 1 934 MB2 : Middlebox 2 and NSIS forwarder 2 936 Figure 10: General NSIS signaling 938 The following list shows the normal sequence of NSLP events without 939 detailing the interaction with the NTLP and the interactions on the 940 the NTLP level. 942 o NSIS initiators generate request messages (which are either CREATE 943 or EXTERNAL messages) and send these towards the NSIS responder. 945 This request message is the initial message which creates a new 946 NATFW NSLP signaling session. The NI and the NR will most likely 947 already share an application session before they start the NATFW 948 NSLP signaling session. Note well the difference between both 949 sessions. 951 o NSLP request messages are processed each time a NF with NATFW NSLP 952 support is traversed. Each NF that is intercepting a request 953 message and is accepting it for further treatment is joining the 954 particular NATFW NSLP signaling session. These nodes process the 955 message, check local policies for authorization and 956 authentication, possibly create policy rules, and forward the 957 signaling message to the next NSIS node. The request message is 958 forwarded until it reaches the NSIS responder. 960 o NSIS responders will check received messages and process them if 961 applicable. NSIS responders generate RESPONSE messages and send 962 them hop-by-hop back to the NI via the same chain of NFs 963 (traversal of the same NF chain is guaranteed through the 964 established reverse message routing state in the NTLP). The NR is 965 also joining the NATFW NSLP signaling session if the request 966 message is accepted. 968 o The RESPONSE message is processed at each NF that has been 969 included in the prior NATFW NSLP signaling session setup. 971 o If the NI has received a successful RESPONSE message and if the 972 signaling NATFW NSLP session started with a CREATE message, the 973 data sender can start sending its data flow to the data receiver. 974 If the NI has received a successful RESPONSE message and if the 975 signaling NATFW NSLP session started with a EXTERNAL message, the 976 data receiver is ready to receive further CREATE messages. 978 Because NATFW NSLP signaling follows the data path from DS to DR, 979 this immediately enables communication between both hosts for 980 scenarios with only firewalls on the data path or NATs on the sender 981 side. For scenarios with NATs on the receiver side certain problems 982 arise, as described in Section 2.4. 984 3.2.2. Signaling for Inbound Traffic 986 When the NR and the NI are located in different address realms and 987 the NR is located behind a NAT, the NI cannot signal to the NR 988 address directly. The DR/NR is not reachable from other NIs using 989 the private address of the NR and thus NATFW signaling messages 990 cannot be sent to the NR/DR's address. Therefore, the NR must first 991 obtain a NAT binding that provides an address that is reachable for 992 the NI. Once the NR has acquired a public IP address, it forwards 993 this information to the DS via a separate protocol. This application 994 layer signaling, which is out of scope of the NATFW NSLP, may involve 995 third parties that assist in exchanging these messages. 997 The same holds partially true for NRs located behind firewalls that 998 block all traffic by default. In this case, NR must tell its inbound 999 firewalls of inbound NATFW NSLP signaling and corresponding data 1000 traffic. Once the NR has informed the inbound firewalls, it can 1001 start its application level signaling to initiate communication with 1002 the NI. This mechanism can be used by machines hosting services 1003 behind firewalls as well. In this case, the NR informs the inbound 1004 firewalls as described, but does not need to communicate this to the 1005 NIs. 1007 NATFW NSLP signaling supports this scenario by using the EXTERNAL 1008 message 1010 1. The DR acquires a public address by signaling on the reverse path 1011 (DR towards DS) and thus making itself available to other hosts. 1012 This process of acquiring public addresses is called reservation. 1013 During this process the DR reserves publicly reachable addresses 1014 and ports suitable for further usage in application level 1015 signaling and the publicly reachable address for further NATFW 1016 NSLP signaling. However, the data traffic will not be allowed to 1017 use this address/port initially (see next point). In the process 1018 of reservation the DR becomes the NI for the messages necessary 1019 to obtain the publicly reachable IP address, i.e., the NI for 1020 this specific NATFW NSLP signaling session. 1022 2. Now on the side of DS, the NI creates a new NATFW NSLP signaling 1023 session and signals directly to the public IP address of DR. 1024 This public IP address is used as NR's address, as the NI would 1025 do if there is no NAT in between, and creates policy rules at 1026 middleboxes. Note, that the reservation will only allow 1027 forwarding of signaling messages, but not data flow packets. 1028 Policy rules allowing forwarding of data flow packets set up by 1029 the prior EXTERNAL message signaling will be activated when the 1030 signaling from NI towards NR is confirmed with a positive 1031 RESPONSE message. The EXTERNAL message is described in 1032 Section 3.7.2. 1034 3.2.3. Signaling for Proxy Mode 1035 administrative domain 1036 ----------------------------------\ 1037 | 1038 +-------+ +-------+ +-------+ | +-------+ 1039 | DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR | 1040 | |--->| NF1 |--->| NR | | | | 1041 +-------+ +-------+ +-------+ | +-------+ 1042 | 1043 ----------------------------------/ 1045 ========================================> 1046 Data Traffic Direction (outbound) 1048 ---> : NATFW NSLP request signaling 1049 ~~~> : NATFW NSLP response signaling 1050 DS/NI : Data sender and NSIS initiator 1051 DR/NR : Data receiver and NSIS responder 1052 MB1 : Middlebox 1 and NSIS forwarder 1 1053 MB2 : Middlebox 2 and NSIS responder 1055 Figure 11: proxy mode signaling for data sender 1057 The above usage assumes that both ends of a communication support 1058 NSIS, but fails when NSIS is only deployed at one end of the path. 1059 In this case only one of the sending Figure 11 or receiving Figure 12 1060 side is NSIS aware and not both at the same time. NATFW NSLP 1061 supports both scenarios (i.e., either the DS or DR do not support 1062 NSIS) by using a proxy mode, as described in Section 3.7.6 1063 administrative domain 1064 / ---------------------------------- 1065 | 1066 +-------+ | +-------+ +-------+ +-------+ 1067 | DS | | | MB2/ |~~~>| MB1/ |~~~>| DR | 1068 | | | | NR |<---| NF1 |<---| | 1069 +-------+ | +-------+ +-------+ +-------+ 1070 | 1071 \---------------------------------- 1073 ========================================> 1074 Data Traffic Direction (inbound) 1076 ---> : NATFW NSLP request signaling 1077 ~~~> : NATFW NSLP response signaling 1078 DS/NI : Data sender and NSIS initiator 1079 DR/NR : Data receiver and NSIS responder 1080 MB1 : Middlebox 1 and NSIS forwarder 1 1081 MB2 : Middlebox 2 and NSIS responder 1083 Figure 12: proxy mode signaling for data receiver 1085 3.2.4. Blocking Traffic 1087 The basic functionality of the NATFW NSLP provides for opening 1088 firewall pin holes and creating NAT bindings to enable data flows to 1089 traverse these devices. Firewalls are normally expected to work on a 1090 'deny-all' policy, meaning that traffic not explicitly matching any 1091 firewall filter rule will be blocked. Similarly, the normal behavior 1092 of NATs is to block all traffic that does not match any already 1093 configured/installed binding or NATFW NSLP session. However, some 1094 scenarios require support of firewalls having 'allow-all' policies, 1095 allowing data traffic to traverse the firewall unless it is blocked 1096 explicitly. Data receivers can utilize NATFW NSLP's EXTERNAL message 1097 with action set to 'deny' to install policy rules at inbound 1098 firewalls to block unwanted traffic. 1100 3.2.5. State and Error Maintenance 1102 The protocol works on a soft-state basis, meaning that whatever state 1103 is installed or reserved on a middlebox will expire, and thus be de- 1104 installed or forgotten after a certain period of time. To prevent 1105 premature removal of state that is needed for ongoing communication, 1106 the NATFW NI involved will have to specifically request a NATFW NSLP 1107 signaling session extension. An explicit NATFW NSLP state deletion 1108 capability is also provided by the protocol. 1110 If the actions requested by a NATFW NSLP message cannot be carried 1111 out, NFs and the NR must return a failure, such that appropriate 1112 actions can be taken. They can do this either during the request 1113 message handling (synchronously) by sending an error RESPONSE 1114 message, or at any time (asynchronously) by sending a NOTIFY 1115 notification message. 1117 The next sections define the NATFW NSLP message types and formats, 1118 protocol operations, and policy rule operations. 1120 3.2.6. Message Types 1122 The protocol uses four messages types: 1124 o CREATE: a request message used for creating, changing, refreshing, 1125 and deleting NATFW NSLP signaling sessions, i.e., open the data 1126 path from DS to DR. 1128 o EXTERNAL: a request message used for reserving, changing, 1129 refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions. 1130 EXTERNAL messages are forwarded to the edge-NAT or edge-firewall 1131 and allow inbound CREATE messages to be forwarded to the NR. 1132 Additionally, EXTERNAL messages reserve an external address and, 1133 if applicable, port number at an edge-NAT. 1135 o NOTIFY: an asynchronous message used by NATFW peers to alert other 1136 NATFW peers about specific events (especially failures). 1138 o RESPONSE: used as a response to CREATE and EXTERNAL request 1139 messages. 1141 3.2.7. Classification of RESPONSE Messages 1143 RESPONSE messages will be generated synchronously to CREATE and 1144 EXTERNAL messages by NSIS Forwarders and Responders to report success 1145 or failure of operations or some information relating to the NATFW 1146 NSLP signaling session or a node. RESPONSE messages MUST NOT be 1147 generated for any other message, such as NOTIFY and RESPONSE. 1149 All RESPONSE messages MUST carry a NATFW_INFO object which contains a 1150 severity class code and a response code (see Section 4.2.5). This 1151 section defines terms for groups of RESPONSE messages depending on 1152 the severity class. 1154 o Successful RESPONSE: Messages carrying NATFW_INFO with severity 1155 class 'Success' (0x2). 1157 o Informational RESPONSE: Messages carrying NATFW_INFO with severity 1158 class 'Informational' (0x1) (only used with NOTIFY messages). 1160 o Error RESPONSE: Messages carrying NATFW_INFO with severity class 1161 other than 'Success' or 'Informational'. 1163 3.2.8. NATFW NSLP Signaling Sessions 1165 A NATFW NSLP signaling session defines an association between the NI, 1166 NFs, and the NR related to a data flow. This association is created 1167 when the initial CREATE or EXTERNAL message is successfully received 1168 at the NFs or the NR. There is signaling NATFW NSLP session state 1169 stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP 1170 signaling session state for the NATFW NSLP comprises NSLP state and 1171 the associated policy rules at a middlebox. 1173 The NATFW NSLP signaling session is identified by the session ID 1174 (plus other information at the NTLP level). The session ID is 1175 generated by the NI before the initial CREATE or EXTERNAL message is 1176 sent. The value of the session ID MUST be generated as a 1177 cryptographically random number (see [RFC4086] by the NI, i.e., the 1178 output MUST NOT be easily guessable by third parties. The session ID 1179 is not stored in any NATFW NSLP message but passed on to the NTLP. 1181 A NATFW NSLP signaling session has several conceptional states that 1182 describes in what state a signaling session is at a given time. The 1183 signaling session can have these states at a node: 1185 o Pending: The NATFW NSLP signaling session has been created and the 1186 node is waiting for a RESPONSE message to the CREATE or EXTERNAL 1187 message. A NATFW NSLP signaling session in state 'Pending' MUST 1188 be marked as 'Dead' if no corresponding RESPONSE message has been 1189 received within the time of the locally granted NATFW NSLP 1190 signaling session lifetime of the forwarded CREATE or EXTERNAL 1191 message (as described in Section 3.4). 1193 o Established: The NATFW NSLP signaling session is established, i.e, 1194 the signaling has been successfully performed and the lifetime of 1195 NATFW NSLP signaling session is counted from now on. A NATFW NSLP 1196 signaling session in state 'Established' MUST be marked as 'Dead' 1197 if no refresh message has been received within the time of the 1198 locally granted NATFW NSLP signaling session lifetime of the 1199 RESPONSE message (as described in Section 3.4). 1201 o Dead: Either the NATFW NSLP signaling session is timed out or the 1202 node has received an error RESPONSE message for the NATFW NSLP 1203 signaling session and the NATFW NSLP signaling session can be 1204 deleted. 1206 o Transitory: The node has received an asynchronous message, i.e., a 1207 NOTIFY, and can delete the NATFW NSLP signaling session if needed 1208 after some time. When a node has received a NOTIFY message, it 1209 marks the signaling session as 'transitory'. This signaling 1210 session SHOULD NOT be deleted before a minimum hold time of 30 1211 second, i.e., it can be removed after 30 seconds or more. This 1212 hold time ensures that the existing signaling session can be 1213 reused by the NI, e.g., a part of a signalling session that is not 1214 affected by the route change can be reused once the updating 1215 request message is received. 1217 3.3. Basic Message Processing 1219 All NATFW messages are subject to some basic message processing when 1220 received at a node, independent of the message type. Initially, the 1221 syntax of the NSLP message is checked and a RESPONSE message with an 1222 appropriate error of class 'Protocol error' (0x3) code is generated 1223 if a non recoverable syntax error is detected. A recoverable error 1224 is, for instance, when a node receives a message with reserved flags 1225 set to values other than zero. This also refers to unknown NSLP 1226 objects and their handling, according to Section 4.2. If a message 1227 is delivered to the NATFW NSLP, this implies that the NTLP layer has 1228 been able to correlate it with the SID and MRI entries in its 1229 database. There is therefore enough information to identify the 1230 source of the message and routing information to route the message 1231 back to the NI through an established chain of NTLP messaging 1232 associations. The message is not further forwarded if any error in 1233 the syntax is detected. The specific response codes stemming from 1234 the processing of objects are described in the respective object 1235 definition section (see Section 4). After passing this check, the 1236 NATFW NSLP node performs authentication/authorization related checks 1237 described in Section 3.6. Further processing is executed only if 1238 these tests have been successfully passed, otherwise the processing 1239 stops and an error RESPONSE is returned. 1241 Further message processing stops whenever an error RESPONSE message 1242 is generated, and the EXTERNAL or CREATE message is discarded. 1244 3.4. Calculation of Signaling Session Lifetime 1246 NATFW NSLP signaling sessions, and the corresponding policy rules 1247 which may have been installed, are maintained via a soft-state 1248 mechanism. Each signaling session is assigned a signaling session 1249 lifetime and the signaling session is kept alive as long as the 1250 lifetime is valid. After the expiration of the signaling session 1251 lifetime, signaling sessions and policy rules MUST be removed 1252 automatically and resources bound to them MUST be freed as well. 1253 Signaling session lifetime is handled at every NATFW NSLP node. The 1254 NSLP forwarders and NSLP responder MUST NOT trigger signaling session 1255 lifetime extension refresh messages (see Section 3.7.3): this is the 1256 task of the NSIS initiator. 1258 The NSIS initiator MUST choose a NATFW NSLP signaling session 1259 lifetime value (expressed in seconds) before sending any message, 1260 including the initial message which creates the NATFW NSLP signaling 1261 session, to other NSLP nodes. It is RECOMMENDED that the NATFW NSLP 1262 signaling session lifetime value is calculated based on: 1264 o the number of lost refresh messages that NFs should cope with; 1266 o the end-to-end delay between the NI and NR; 1268 o network vulnerability due to NATFW NSLP signaling session 1269 hijacking ([RFC4081]), NATFW NSLP signaling session hijacking is 1270 made easier when the NI does not explicitly remove the NATFW NSLP 1271 signaling session; 1273 o the user application's data exchange duration, in terms of time 1274 and networking needs. This duration is modeled as R, with R the 1275 message refresh period (in seconds); 1277 o the load on the signaling plane. Short lifetimes imply more 1278 frequent signaling messages. 1280 o the acceptable time for a NATFW NSLP signaling session to be 1281 present after it is no longer actually needed. For example, if 1282 the existence of the NATFW NSLP signaling session implies a 1283 monetary cost and teardown cannot be guaranteed, shorter lifetimes 1284 would be preferable; 1286 o the lease time of the NI's IP address. The lease time of the IP 1287 address must be larger than chosen NATFW NSLP signaling session 1288 lifetime, otherwise the IP address can be re-assigned to a 1289 different node. This node may receive unwanted traffic, although 1290 it never has requested a NAT/firewall configuration, which might 1291 be an issue in environments with mobile hosts. 1293 The RSVP specification [RFC2205] provides an appropriate algorithm 1294 for calculating the NATFW NSLP signaling session lifetime as well as 1295 means to avoid refresh message synchronization between NATFW NSLP 1296 signaling sessions. [RFC2205] recommends: 1298 1. The refresh message timer to be randomly set to a value in the 1299 range [0.5R, 1.5R]. 1301 2. To avoid premature loss of state, lt (with lt being the NATFW 1302 NSLP signaling session lifetime) must satisfy lt >= (K + 1303 0.5)*1.5*R, where K is a small integer. Then in the worst case, 1304 K-1 successive messages may be lost without state being deleted. 1305 Currently K = 3 is suggested as the default. However, it may be 1306 necessary to set a larger K value for hops with high loss rate. 1307 Other algorithms could be used to define the relation between the 1308 NATFW NSLP signaling session lifetime and the refresh message 1309 period; the algorithm provided is only given as an example. 1311 It is RECOMMENDED to use a refresh timer of 300 s (5 minutes), unless 1312 the NI or the requesting application at the NI has other requirements 1313 (e.g., flows lasting a very short time). 1315 This requested NATFW NSLP signaling session lifetime value lt is 1316 stored in the NATFW_LT object of the NSLP message. 1318 NSLP forwarders and the NSLP responder can execute the following 1319 behavior with respect to the requested lifetime handling: 1321 Requested signaling session lifetime acceptable: 1323 No changes to the NATFW NSLP signaling session lifetime values are 1324 needed. The CREATE or EXTERNAL message is forwarded, if 1325 applicable. 1327 Signaling session lifetime can be lowered: 1329 An NSLP forwarded or the NSLP responder MAY also lower the 1330 requested NATFW NSLP signaling session lifetime to an acceptable 1331 value (based on its local policies). If an NF changes the NATFW 1332 NSLP signaling session lifetime value, it MUST store the new value 1333 in the NATFW_LT object. The CREATE or EXTERNAL message is 1334 forwarded. 1336 Requested signaling session lifetime is too big: 1338 An NSLP forwarded or the NSLP responder MAY reject the requested 1339 NATFW NSLP signaling session lifetime value as being too big and 1340 MUST generate an error RESPONSE message of class 'Signaling 1341 session failure' (0x6) with response code 'Requested lifetime is 1342 too big' (0x02) upon rejection. Lowering the lifetime is 1343 preferred instead of generating an error message. 1345 Requested signaling session lifetime is too small: 1347 An NSLP forwarded or the NSLP responder MAY reject the requested 1348 NATFW NSLP signaling session lifetime value as being to small and 1349 MUST generate an error RESPONSE message of class 'Signaling 1350 session failure' (0x6) with response code 'Requested lifetime is 1351 too small' (0x10) upon rejection. 1353 NFs or the NR MUST NOT increase the NATFW NSLP signaling session 1354 lifetime value. Messages can be rejected on the basis of the NATFW 1355 NSLP signaling session lifetime being too long when a NATFW NSLP 1356 signaling session is first created and also on refreshes. 1358 The NSLP responder generates a successful RESPONSE for the received 1359 CREATE or EXTERNAL message, sets the NATFW NSLP signaling session 1360 lifetime value in the NATFW_LT object to the above granted lifetime 1361 and sends the message back towards NSLP initiator. 1363 Each NSLP forwarder processes the RESPONSE message, reads and stores 1364 the granted NATFW NSLP signaling session lifetime value. The 1365 forwarders MUST accept the granted NATFW NSLP signaling session 1366 lifetime, if the lifetime value is within the acceptable range. The 1367 acceptable value refers to the value accepted by the NSLP forwarder 1368 when processing the CREATE or EXTERNAL message. For received values 1369 greater than the acceptable value, NSLP forwarders MUST generate a 1370 RESPONSE message of class 'Signaling session failure' (0x6) with 1371 response code 'Modified lifetime is too big' (0x11). For received 1372 values lower than the values acceptable by the node local policy, 1373 NSLP forwarders MUST generate a RESPONSE message of class 'Signaling 1374 session failure' (0x6) with response code 'Modified lifetime is too 1375 small' (0x12). In both cases, either 'Modified lifetime is too big' 1376 (0x11) or 'Modified lifetime is too small' (0x12), the NF MUST 1377 generate a NOTIFY message and send it outbound with the error class 1378 set to 'Informational' (0x1) and with the severity class to 'NATFW 1379 signaling session terminated.' (0x05). 1381 Figure 13 shows the procedure with an example, where an initiator 1382 requests 60 seconds lifetime in the CREATE message and the lifetime 1383 is shortened along the path by the forwarder to 20 seconds and by the 1384 responder to 15 seconds. When the NSLP forwarder receives the 1385 RESPONSE message with a NATFW NSLP signaling session lifetime value 1386 of 15 seconds it checks whether this value is lower or equal to the 1387 acceptable value. 1389 +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ 1390 | |---------------->| NSLP |---------------->| | 1391 | NI | | forwarder | | NR | 1392 | |<----------------| check 15<20 |<----------------| | 1393 +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ 1395 lt = lifetime 1397 Figure 13: Signaling Session Lifetime Setting Example 1399 3.5. Message Sequencing 1401 NATFW NSLP messages need to carry an identifier so that all nodes 1402 along the path can distinguish messages sent at different points in 1403 time. Messages can be lost along the path or duplicated. So all 1404 NATFW NSLP nodes should be able to identify either old messages that 1405 have been received before (duplicated), or the case that messages 1406 have been lost before (loss). For message replay protection it is 1407 necessary to keep information about messages that have already been 1408 received and requires every NATFW NSLP message to carry a message 1409 sequence number (MSN), see also Section 4.2.7. 1411 The MSN MUST be set by the NI and MUST NOT be set or modified by any 1412 other node. The initial value for the MSN MUST be generated randomly 1413 and MUST be unique only within the NATFW NSLP signaling session for 1414 which it is used. The NI MUST increment the MSN by one for every 1415 message sent. Once the MSN has reached the maximum value, the next 1416 value it takes is zero. All NATFW NSLP nodes MUST use the algorithm 1417 defined in [RFC1982] to detect MSN wrap-arounds. 1419 NSIS forwarders and the responder store the MSN from the initial 1420 CREATE or EXTERNAL packet which creates the NATFW NSLP signaling 1421 session as the start value for the NATFW NSLP signaling session. NFs 1422 and NRs MUST include the received MSN value in the corresponding 1423 RESPONSE message that they generate. 1425 When receiving a CREATE or EXTERNAL message, a NATFW NSLP node uses 1426 the MSN given in the message to determine whether the state being 1427 requested is different to the state already installed. The message 1428 MUST be discarded if the received MSN value is equal to or lower than 1429 the stored MSN value. Such a received MSN value can indicate a 1430 duplicated and delayed message or replayed message. If the received 1431 MSN value is greater than the already stored MSN value, the NATFW 1432 NSLP MUST update its stored state accordingly, if permitted by all 1433 security checks (see Section 3.6), and store the updated MSN value 1434 accordingly. 1436 3.6. Authentication, Authorization, and Policy Decisions 1438 NATFW NSLP nodes receiving signaling messages MUST first check 1439 whether this message is authenticated and authorized to perform the 1440 requested action. NATFW NSLP nodes requiring more information than 1441 provided MUST generate an error RESPONSE of class 'Permanent failure' 1442 (0x5) with response code 'Authentication failed' (0x01) or with 1443 response code 'Authorization failed' (0x02). 1445 The NATFW NSLP is expected to run in various environments, such as 1446 IP-based telephone systems, enterprise networks, home networks, etc. 1447 The requirements on authentication and authorization are quite 1448 different between these use cases. While a home gateway, or an 1449 Internet cafe, using NSIS may well be happy with a "NATFW signaling 1450 coming from inside the network" policy for authorization of 1451 signaling, enterprise networks are likely to require more strongly 1452 authenticated/authorized signaling. This enterprise scenario may 1453 require the use of an infrastructure and administratively assigned 1454 identities to operate the NATFW NSLP. 1456 Once the NI is authenticated and authorized, another step is 1457 performed. The requested policy rule for the NATFW NSLP signaling 1458 session is checked against a set of policy rules, i.e., whether the 1459 requesting NI is allowed to request the policy rule to be loaded in 1460 the device. If this fails the NF or NR must send an error RESPONSE 1461 of class 'Permanent failure' (0x5) and with response code 1462 'Authorization failed' (0x02). 1464 3.7. Protocol Operations 1466 This section defines the protocol operations including, how to create 1467 NATFW NSLP signaling sessions, maintain them, delete them, and how to 1468 reserve addresses. 1470 This section requires a good knowledge of the NTLP 1471 ([I-D.ietf-nsis-ntlp]) and the message routing method mechanism and 1472 the associated message routing information (MRI). The NATFW NSLP 1473 uses information from the MRI, e.g., the destination and source 1474 ports, and the NATFW NSLP to construct the policy rules used on the 1475 NATFW NSLP level. See also Appendix D for further information about 1476 this. 1478 3.7.1. Creating Signaling Sessions 1480 Allowing two hosts to exchange data even in the presence of 1481 middleboxes is realized in the NATFW NSLP by use of the CREATE 1482 message. The NI (either the data sender or a proxy) generates a 1483 CREATE message as defined in Section 4.3.1 and hands it to the NTLP. 1485 The NTLP forwards the whole message on the basis of the message 1486 routing information (MRI) towards the NR. Each NSIS forwarder along 1487 the path that implements NATFW NSLP, processes the NSLP message. 1488 Forwarding is done hop-by-hop but may pass transparently through NSIS 1489 forwarders which do not contain NATFW NSLP functionality and non-NSIS 1490 aware routers between NSLP hop way points. When the message reaches 1491 the NR, the NR can accept the request or reject it. The NR generates 1492 a response to CREATE and this response is transported hop-by-hop 1493 towards the NI. NATFW NSLP forwarders may reject requests at any 1494 time. Figure 14 sketches the message flow between NI (DS in this 1495 example), a NF (e.g., NAT), and NR (DR in this example). 1497 NI Private Network NF Public Internet NR 1498 | | | 1499 | CREATE | | 1500 |----------------------------->| | 1501 | | | 1502 | | | 1503 | | CREATE | 1504 | |--------------------------->| 1505 | | | 1506 | | RESPONSE | 1507 | RESPONSE |<---------------------------| 1508 |<-----------------------------| | 1509 | | | 1510 | | | 1512 Figure 14: CREATE message flow with success RESPONSE 1514 There are several processing rules for a NATFW peer when generating 1515 and receiving CREATE messages, since this message type is used for 1516 creating new NATFW NSLP signaling session, updating existing, 1517 extending the lifetime and deleting NATFW NSLP signaling session. 1518 The three latter functions operate in the same way for all kinds of 1519 CREATE message, and are therefore described in separate sections: 1521 o Extending the lifetime of NATFW NSLP signaling sessions is 1522 described in Section 3.7.3. 1524 o Deleting NATFW NSLP signaling sessions is described in 1525 Section 3.7.4. 1527 o Updating policy rules is described in Section 3.10. 1529 For an initial CREATE message creating a new NATFW NSLP signaling 1530 session, the processing of CREATE messages is different for every 1531 NATFW node type: 1533 o NSLP initiator: An NI only generates CREATE messages and hands 1534 them over to the NTLP. The NI should never receive CREATE 1535 messages and MUST discard it. 1537 o NATFW NSLP forwarder: NFs that are unable to forward the CREATE 1538 message to the next hop MUST generate an error RESPONSE of class 1539 'Permanent failure' (0x6) with response code 'Did not reach the 1540 NR' (0x07). This case may occur if the NTLP layer cannot find an 1541 NATFW NSLP peer, either another NF or the NR, and returns an error 1542 via the GIST API (a timeout error reported by GIST). The NSLP 1543 message processing at the NFs depends on the middlebox type: 1545 * NAT: When the initial CREATE message is received at the public 1546 side of the NAT, it looks for a reservation made in advance, by 1547 using a EXTERNAL message (see Section 3.7.2). The matching 1548 process considers the received MRI information and the stored 1549 MRI information, as described in Section 3.8. If no matching 1550 reservation can be found, i.e., no reservation has been made in 1551 advance, the NSLP MUST return an error RESPONSE of class 1552 'Signaling session failure' (0x6) with response code 'No 1553 reservation found matching the MRI of the CREATE request' 1554 (0x03). If there is a matching reservation, the NSLP stores 1555 the data sender's address (and if applicable port number) as 1556 part of the source address of the policy rule ('the remembered 1557 policy rule') to be loaded and forwards the message with the 1558 destination address set to the internal (private in most cases) 1559 address of NR. When the initial CREATE message is received at 1560 the private side, the NAT binding is allocated, but not 1561 activated (see also Appendix D.3). An error RESPONSE message 1562 is generated, if the requested policy rule cannot be reserved 1563 right away, of class 'Signaling session failure' (0x6) with 1564 response code 'Requested policy rule denied due to policy 1565 conflict' (0x4). The MRI information is updated to reflect the 1566 address, and if applicable port, translation. The NSLP message 1567 is forwarded towards the NR with source address set to the 1568 NAT's external address from the newly remembered binding. 1570 * Firewall: When the initial CREATE message is received, the NSLP 1571 just remembers the requested policy rule, but does not install 1572 any policy rule. Afterwards, the message is forwarded towards 1573 the NR. An error RESPONSE message is generated, if the 1574 requested policy rule cannot be installed later on, with of 1575 class 'Signaling session failure' (0x6) with response code 1576 'Requested policy rule denied due to policy conflict' (0x4). 1578 * Combined NAT and firewall: Processing at combined firewall and 1579 NAT middleboxes is the same as in the NAT case. No policy 1580 rules are installed. Implementations MUST take into account 1581 the order of packet processing in the firewall and NAT 1582 functions within the device. This will be referred to as 1583 'order of functions' and is generally different depending on 1584 whether the packet arrives at the external or internal side of 1585 the middlebox. 1587 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1588 with a success RESPONSE of class 'Success' (0x2) with response 1589 code set to 'All successfully processed' (0x01), if they accept 1590 the CREATE message. Otherwise they MUST generate a RESPONSE 1591 message with a suitable response code. RESPONSE messages are sent 1592 back NSLP hop-by-hop towards the NI, irrespective of the response 1593 codes, either success or error. 1595 Remembered policy rules at middleboxes MUST be only installed upon 1596 receiving a corresponding successful RESPONSE message with the same 1597 SID as the CREATE message that caused them to be remembered. This is 1598 a countermeasure to several problems, for example, wastage of 1599 resources due to loading policy rules at intermediate NFs when the 1600 CREATE message does not reach the final NR for some reason. 1602 Processing of a RESPONSE message is different for every NSIS node 1603 type: 1605 o NSLP initiator: After receiving a successful RESPONSE, the data 1606 path is configured and the DS can start sending its data to the 1607 DR. After receiving an error RESPONSE message, the NI MAY try to 1608 generate the CREATE message again or give up and report the 1609 failure to the application, depending on the error condition. 1611 o NSLP forwarder: NFs install the remembered policy rules, if a 1612 successful RESPONSE message with matching SID is received. If an 1613 ERROR RESPONSE message with matching SID is received, the NATFW 1614 NSLP session is marked as dead, no policy rule is installed and 1615 the remembered rule is discarded. 1617 o NSIS responder: The NR should never receive RESPONSE messages and 1618 MUST silently drop any such messages received. 1620 NFs and the NR can also tear down the CREATE session at any time by 1621 generating a NOTIFY message with the appropriate response code set. 1623 3.7.2. Reserving External Addresses 1625 NSIS signaling is intended to travel end-to-end, even in the presence 1626 of NATs and firewalls on-path. This works well in cases where the 1627 data sender is itself behind a NAT or a firewall as described in 1628 Section 3.7.1. For scenarios where the data receiver is located 1629 behind a NAT or a firewall and it needs to receive data flows from 1630 outside its own network (usually referred to as inbound flows, see 1631 Figure 5) the problem is more troublesome. 1633 NSIS signaling, as well as subsequent data flows, are directed to a 1634 particular destination IP address that must be known in advance and 1635 reachable. Data receivers must tell the local NSIS infrastructure 1636 (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP 1637 signaling and data flows before they can receive these flows. It is 1638 necessary to differentiate between data receivers behind NATs and 1639 behind firewalls for understanding the further NATFW procedures. 1640 Data receivers that are only behind firewalls already have a public 1641 IP address and they need only to be reachable for NATFW signaling. 1642 Unlike data receivers behind just firewalls, data receivers behind 1643 NATs do not have public IP addresses; consequently they are not 1644 reachable for NATFW signaling by entities outside their addressing 1645 realm. 1647 The preceding discussion addresses the situation where a DR node that 1648 wants to be reachable is unreachable because the NAT lacks a suitable 1649 rule with the 'allow' action which would forward inbound data. 1650 However, in certain scenarios, a node situated behind inbound 1651 firewalls that do not block inbound data traffic (firewalls with 1652 "default to allow") unless requested might wish to prevent traffic 1653 being sent to it from specified addresses. In this case, NSIS NATFW 1654 signaling can be used to achieve this by installing a policy rule 1655 with its action set to 'deny' using the same mechanisms as for 1656 'allow' rules. 1658 The required result is obtained by sending a EXTERNAL message in the 1659 inbound direction of the intended data flow. When using this 1660 functionality the NSIS initiator for the 'Reserve External Address' 1661 signaling is typically the node that will become the DR for the 1662 eventual data flow. To distinguish this initiator from the usual 1663 case where the NI is associated with the DS, the NI is denoted by NI+ 1664 and the NSIS responder is similarly denoted by NR+. 1666 Public Internet Private Address 1667 Space 1669 Edge 1670 NI(DS) NAT/FW NAT NR(DR) 1671 NR+ NI+ 1673 | | | | 1674 | | | | 1675 | | | | 1676 | | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] | 1677 | |<----------------------|<----------------------| 1678 | | | | 1679 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1680 | |---------------------->|---------------------->| 1681 | | | | 1682 | | | | 1684 ============================================================> 1685 Data Traffic Direction 1687 Figure 15: Reservation message flow for DR behind NAT or firewall 1689 Figure 15 shows the EXTERNAL message flow for enabling inbound NATFW 1690 NSLP signaling messages. In this case the roles of the different 1691 NSIS entities are: 1693 o The data receiver (DR) for the anticipated data traffic is the 1694 NSIS initiator (NI+) for the EXTERNAL message, but becomes the 1695 NSIS responder (NR) for following CREATE messages. 1697 o The actual data sender (DS) will be the NSIS initiator (NI) for 1698 later CREATE messages and may be the NSIS target of the signaling 1699 (NR+). 1701 o It may be necessary to use a signaling destination address (SDA) 1702 as the actual target of the EXTERNAL message (NR+) if the DR is 1703 located behind a NAT and the address of the DS is unknown. The 1704 SDA is an arbitrary address in the outermost address realm on the 1705 other side of the NAT from the DR. Typically this will be a 1706 suitable public IP address when the 'outside' realm is the public 1707 Internet. This choice of address causes the EXTERNAL message to 1708 be routed through the NATs towards the outermost realm and would 1709 force interception of the message by the outermost NAT in the 1710 network at the boundary between the private address and the public 1711 address realm (the edge-NAT). It may also be intercepted by other 1712 NATs and firewalls on the path to the edge-NAT. 1714 Basically, there are two different signaling scenarios. Either 1716 1. the DR behind the NAT/firewall knows the IP address of the DS in 1717 advance, 1719 2. or the address of DS is not known in advance. 1721 Case 1 requires the NATFW NSLP to request the path-coupled message 1722 routing method (PC-MRM) from the NTLP. The EXTERNAL message MUST be 1723 sent with PC-MRM (see Section 5.8.1 in [I-D.ietf-nsis-ntlp]) with the 1724 direction set to 'upstream' (inbound). The handling of case 2 1725 depends on the situation of DR: If DR is solely located behind a 1726 firewall, the EXTERNAL message MUST be sent with the PC-MRM, 1727 direction 'upstream' (inbound), and data flow source IP address set 1728 to wildcard. If DR is located behind a NAT, the EXTERNAL message 1729 MUST be sent with the loose-end message routing method (LE-MRM, see 1730 Section 5.8.2 in [I-D.ietf-nsis-ntlp]), the destination-address set 1731 to the signaling destination address (SDA, see also Appendix A). For 1732 scenarios with DR being behind a firewall, special conditions apply 1733 (see applicability statement in Appendix C). The data receiver is 1734 challenged to determine whether it is solely located behind firewalls 1735 or NATs, for choosing the right message routing method. This 1736 decision can depend on a local configuration parameter, possibly 1737 given through DHCP, or it could be discovered through other non-NSLP 1738 related testing of the network configuration. It is RECOMMENDED to 1739 use the PC-MRM with the known data sender's IP address. This gives 1740 GIST the best possible handled to route the message 'upstream' 1741 (outbound). It is RECOMMENDED to use the LE-MRM, if and only if the 1742 data sender's IP address is not known and the data receiver is behind 1743 a NAT. 1745 For case 2 with NAT, the NI+ (which could be on the data receiver DR 1746 or on any other host within the private network) sends the EXTERNAL 1747 message targeted to the signaling destination address. The message 1748 routing for the EXTERNAL message is in the reverse direction to the 1749 normal message routing used for path-coupled signaling where the 1750 signaling is sent outbound (as opposed to inbound in this case). 1751 When establishing NAT bindings (and an NATFW NSLP signaling session) 1752 the signaling direction does not matter since the data path is 1753 modified through route pinning due to the external IP address at the 1754 NAT. Subsequent NSIS messages (and also data traffic) will travel 1755 through the same NAT boxes. However, this is only valid for the NAT 1756 boxes, but not for any intermediate firewall. That is the reason for 1757 having a separate CREATE message enabling the reservations made with 1758 EXTERNAL at the NATs and either enabling prior reservations or 1759 creating new pinholes at the firewalls which are encountered on the 1760 outbound path depending on whether the inbound and outbound routes 1761 coincide. 1763 The EXTERNAL signaling message creates an NSIS NATFW signaling 1764 session at any intermediate NSIS NATFW peer(s) encountered, 1765 independent of the message routing method used. Furthermore, it has 1766 to be ensured that the edge-NAT or edge-firewall device is discovered 1767 as part of this process. The end host cannot be assumed to know this 1768 device - instead the NAT or firewall box itself is assumed to know 1769 that it is located at the outer perimeter of the network. Forwarding 1770 of the EXTERNAL message beyond this entity is not necessary, and MUST 1771 be prohibited as it may provide information on the capabilities of 1772 internal hosts. It should be noted, that it is the outermost NAT or 1773 firewall that is the edge-device that must be found during this 1774 discovery process. For instance, when there are a NAT and afterwards 1775 a firewall on the outbound path at the network border, the firewall 1776 is the edge-firewall. All messages must be forwarded to the 1777 topology-wise outermost edge-device, to ensure that this device knows 1778 about the NATFW NSLP signaling sessions for incoming CREATE messages. 1779 However, the NAT is still the edge-NAT because it has a public 1780 globally routable IP address on its public side: this is not affected 1781 by any firewall between the edge-NAT and the public network. 1783 Possible edge arrangements are: 1785 Public Net ----------------- Private net -------------- 1787 | Public Net|--|Edge-FW|--|FW|...|FW|--|DR| 1789 | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR| 1791 | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR| 1793 The edge-NAT or edge-firewall device closest to the public realm 1794 responds to the EXTERNAL request message with a successful RESPONSE 1795 message. An edge-NAT includes an NATFW_EXTERNAL-IP object (see 1796 Section 4.2.2), carrying the public reachable IP address, and if 1797 applicable port number. 1799 The NI+ can request each intermediate NAT (i.e., a NAT that is not 1800 the edge-NAT) to include the external binding address (and if 1801 applicable port number) in the external binding address object. The 1802 external binding address object stores the external IP address (and 1803 port) at the particular NAT. The NI+ has to include the external 1804 binding address (see Section 4.2.3) object in the request message, if 1805 it wishes to obtain the information. 1807 There are several processing rules for a NATFW peer when generating 1808 and receiving EXTERNAL messages, since this message type is used for 1809 creating new reserve NATFW NSLP signaling sessions, updating 1810 existing, extending the lifetime and deleting NATFW NSLP signaling 1811 session. The three latter functions operate in the same way for all 1812 kinds of CREATE and EXTERNAL messages, and are therefore described in 1813 separate sections: 1815 o Extending the lifetime of NATFW NSLP signaling sessions is 1816 described in Section 3.7.3. 1818 o Deleting NATFW NSLP signaling sessions is described in 1819 Section 3.7.4. 1821 o Updating policy rules is described in Section 3.10. 1823 The NI+ MUST always include a NATFW_DTINFO object in the EXTERNAL 1824 message. Especially, the LE-MRM does not include enough information 1825 for some types of NATs (basically, those NATs which also translate 1826 port numbers) to perform the address translation. This information 1827 is provided in the NATFW_DTINFO (see Section 4.2.8). This 1828 information MUST include at least the 'dst port number' and 1829 'protocol' fields, in the NATFW_DTINFO object as these may be 1830 required by en-route NATs, depending on the type of the NAT. All 1831 other fields MAY be set by the NI+ to restrict the set of possible 1832 NIs. An edge-NAT will use the information provided in the 1833 NATFW_DTINFO object to allow only a NATFW CREATE message with a 1834 matching MRI to be forwarded. The MRI of the NATFW CREATE message 1835 has to use the parameters set in NATFW_DTINFO object ('src IPv4/v6 1836 address', 'src port number', 'protocol') as the source address/port 1837 of the flow from DS to DR. A NAT requiring information carried in 1838 the NATFW_DTINFO can generate a number of error RESPONSE messages of 1839 class 'Signaling session failure' (0x6): 1841 o 'Requested policy rule denied due to policy conflict' (0x04) 1843 o 'NATFW_DTINFO object is required' (0x07) 1845 o 'Requested value in sub_ports field in NATFW_EFI not permitted' 1846 (0x08) 1848 o 'Requested IP protocol not supported' (0x09) 1850 o 'Plain IP policy rules not permitted -- need transport layer 1851 information' (0x0A) 1853 o 'source IP address range is too large' (0x0C) 1855 o 'destination IP address range is too large' (0x0D) 1856 o 'source L4-port range is too large' (0x0E) 1858 o 'destination L4-port range is too large' (0x0F) 1860 Processing of EXTERNAL messages is specific to the NSIS node type: 1862 o NSLP initiator: NI+ only generate EXTERNAL messages. When the 1863 data sender's address information is known in advance the NI+ can 1864 include a NATFW_DTINFO object in the EXTERNAL message, if not 1865 anyway required to do so (see above). When the data sender's IP 1866 address is not known, the NI+ MUST NOT include an IP address in 1867 the NATFW_DTINFO object. The NI should never receive EXTERNAL 1868 messages and MUST silently discard it. 1870 o NSLP forwarder: The NSLP message processing at NFs depends on the 1871 middlebox type: 1873 * NAT: NATs check whether the message is received at the external 1874 (public in most cases) address or at the internal (private) 1875 address. If received at the external an NF MUST generate an 1876 error RESPONSE of class 'Protocol error' (0x3) with response 1877 code 'Received EXTERNAL request message on external side' 1878 (0x0B). If received at the internal (private address) and the 1879 NATFW_EFI object contains the action 'deny', an error RESPONSE 1880 of class 'Protocol error' (0x3) with response code 'Requested 1881 rule action not applicable' (0x06) MUST be generated. If 1882 received at the internal address, an IP address, and if 1883 applicable one or more ports, are reserved. If the 1884 NATFW_EXTERNAL_BINDING object is present in the message, any 1885 NAT that is not an edge-NAT MUST include the allocated external 1886 IP address, and if applicable one or more ports, (the external 1887 binding address) in the NATFW_EXTERNAL_BINDING object. If it 1888 is an edge-NAT and there is no edge-firewall beyond, the NSLP 1889 message is not forwarded any further and a successful RESPONSE 1890 message is generated containing an NATFW_EXTERNAL-IP object 1891 holding the translated address, and if applicable, port 1892 information from the binding reserved as a result of the 1893 EXTERNAL message. The edge-NAT MUST copy the 1894 NATFW_EXTERNAL_BINDING object to response message, if the 1895 object is included in the EXTERNAL message. The RESPONSE 1896 message is sent back towards the NI+. If it is not an edge- 1897 NAT, the NSLP message is forwarded further using the translated 1898 IP address as signaling source address in the LE-MRM and 1899 translated port in the NATFW_DTINFO object in the field 'DR 1900 port number', i.e., the NATFW_DTINFO object is updated to 1901 reflect the translated port number. The edge-NAT or any other 1902 NAT MUST reject EXTERNAL messages not carrying a NATFW_DTINFO 1903 object or if the address information within this object is 1904 invalid or is not compliant with local policies (e.g., the 1905 information provided relates to a range of addresses 1906 ('wildcarded') but the edge-NAT requires exact information 1907 about DS' IP address and port) with the above mentioned 1908 response codes. 1910 * Firewall: Non edge-firewalls remember the requested policy 1911 rule, keep NATFW NSLP signaling session state, and forward the 1912 message. Edge-firewalls stop forwarding the EXTERNAL message. 1913 The policy rule is immediately loaded if the action in the 1914 NATFW_EFI object is set to 'deny' and the node is an edge- 1915 firewall. The policy rule is remembered, but not activated, if 1916 the action in the NATFW_EFI object is set to 'allow'. In both 1917 cases, a successful RESPONSE message is generated. If the 1918 action is 'allow', and the NATFW_DTINFO object is included, and 1919 the MRM is set to LE-MRM in the request, additionally an 1920 NATFW_EXTERNAL-IP object is included in the RESPONSE message, 1921 holding the translated address, and if applicable port, 1922 information. This information is obtained from the 1923 NATFW_DTINFO object's 'DR port number' and the source-address 1924 of the LE-MRM. The edge-firewall MUST copy the 1925 NATFW_EXTERNAL_BINDING object to response message, if the 1926 object is included in the EXTERNAL message. 1928 * Combined NAT and firewall: Processing at combined firewall and 1929 NAT middleboxes is the same as in the NAT case. 1931 o NSLP receiver: This type of message should never be received by 1932 any NR+ and it MUST generate an error RESPONSE message of class 1933 'Permanent failure' (0x5) with response code 'No edge-device here' 1934 (0x06). 1936 Processing of a RESPONSE message is different for every NSIS node 1937 type: 1939 o NSLP initiator: Upon receiving a successful RESPONSE message, the 1940 NI+ can rely on the requested configuration for future inbound 1941 NATFW NSLP signaling sessions. If the response contains an 1942 NATFW_EXTERNAL-IP object, the NI can use IP address and port pairs 1943 carried for further application signaling. After receiving a 1944 error RESPONSE message, the NI+ MAY try to generate the EXTERNAL 1945 message again or give up and report the failure to the 1946 application, depending on the error condition. 1948 o NSLP forwarder: NFs simply forward this message as long as they 1949 keep state for the requested reservation, if the RESPONSE message 1950 contains NATFW_INFO object with class set to 'Success' (0x2). If 1951 the RESPONSE message contains NATFW_INFO object with class set not 1952 to 'Success' (0x2), the NATFW NSLP signaling session is marked as 1953 dead. 1955 o NSIS responder: This type of message should never be received by 1956 any NR+. The NF should never receive response messages and MUST 1957 silently discard it. 1959 NFs and the NR can also tear down the EXTERNAL session at any time by 1960 generating a NOTIFY message with the appropriate response code set. 1962 Reservations with action 'allow' made with EXTERNAL MUST be enabled 1963 by a subsequent CREATE message. A reservation made with EXTERNAL 1964 (independent of selected action) is kept alive as long as the NI+ 1965 refreshes the particular NATFW NSLP signaling session and it can be 1966 reused for multiple, different CREATE messages. An NI+ may decide to 1967 teardown a reservation immediately after receiving a CREATE message. 1968 This implies that a new NATFW NSLP signaling session must be created 1969 for each new CREATE message. The CREATE message does not re-use the 1970 NATFW NSLP signaling session created by EXTERNAL. 1972 Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode 1973 (see Section 3.7.6) no data traffic will be forwarded to DR beyond 1974 the edge-NAT or edge-firewall. The only function of EXTERNAL is to 1975 ensure that subsequent CREATE messages traveling towards the NR will 1976 be forwarded across the public-private boundary towards the DR. 1977 Correlation of incoming CREATE messages to EXTERNAL reservation 1978 states is described in Section 3.8. 1980 3.7.3. NATFW NSLP Signaling Session Refresh 1982 NATFW NSLP signaling sessions are maintained on a soft-state basis. 1983 After a specified timeout, sessions and corresponding policy rules 1984 are removed automatically by the middlebox, if they are not 1985 refreshed. Soft-state is created by CREATE and EXTERNAL and the 1986 maintenance of this state must be done by these messages. State 1987 created by CREATE must be maintained by CREATE, state created by 1988 EXTERNAL must be maintained by EXTERNAL. Refresh messages, are 1989 messages carrying the same session ID as the initial message and a 1990 NATFW_LT lifetime object with a lifetime greater than zero. Messages 1991 with the same SID but carrying a different MRI are treated as updates 1992 of the policy rules and are processed as defined in Section 3.10. 1993 Every refresh CREATE or EXTERNAL message MUST be acknowledged by an 1994 appropriate response message generated by the NR. Upon reception by 1995 each NSIS forwarder, the state for the given session ID is extended 1996 by the NATFW NSLP signaling session refresh period, a period of time 1997 calculated based on a proposed refresh message period. The new 1998 (extended) lifetime of a NATFW NSLP signaling session is calculated 1999 as current local time plus proposed lifetime value (NATFW NSLP 2000 signaling session refresh period). Section 3.4 defines the process 2001 of calculating lifetimes in detail. 2003 NI Public Internet NAT Private address NR 2005 | | space | 2006 | CREATE[lifetime > 0] | | 2008 |----------------------------->| | 2009 | | | 2010 | | | 2011 | | CREATE[lifetime > 0] | 2012 | |--------------------------->| 2013 | | | 2014 | | RESPONSE[Success/Error] | 2015 | RESPONSE[Success/Error] |<---------------------------| 2016 |<-----------------------------| | 2017 | | | 2018 | | | 2020 Figure 16: Successful Refresh Message Flow, CREATE as example 2022 Processing of NATFW NSLP signaling session refresh CREATE and 2023 EXTERNAL messages is different for every NSIS node type: 2025 o NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling 2026 session refresh CREATE/EXTERNAL messages before the NATFW NSLP 2027 signaling session times out. The rate at which the refresh 2028 CREATE/EXTERNAL messages are sent and their relation to the NATFW 2029 NSLP signaling session state lifetime is discussed further in 2030 Section 3.4. 2032 o NSLP forwarder: Processing of this message is independent of the 2033 middlebox type and is as described in Section 3.4. 2035 o NSLP responder: NRs accepting a NATFW NSLP signaling session 2036 refresh CREATE/EXTERNAL message generate a successful RESPONSE 2037 message, including the granted lifetime value of Section 3.4 in a 2038 NATFW_LT object. 2040 3.7.4. Deleting Signaling Sessions 2042 NATFW NSLP signaling sessions can be deleted at any time. NSLP 2043 initiators can trigger this deletion by using a CREATE or EXTERNAL 2044 messages with a lifetime value set to 0, as shown in Figure 17. 2045 Whether a CREATE or EXTERNAL message type is used, depends on how the 2046 NATFW NSLP signaling session was created. 2048 NI Public Internet NAT Private address NR 2050 | | space | 2051 | CREATE[lifetime=0] | | 2052 |----------------------------->| | 2053 | | | 2054 | | CREATE[lifetime=0] | 2055 | |--------------------------->| 2056 | | | 2058 Figure 17: Delete message flow, CREATE as example 2060 NSLP nodes receiving this message delete the NATFW NSLP signaling 2061 session immediately. Policy rules associated with this particular 2062 NATFW NSLP signaling session MUST be also deleted immediately. This 2063 message is forwarded until it reaches the final NR. The CREATE/ 2064 EXTERNAL message with a lifetime value of 0, does not generate any 2065 response, neither positive nor negative, since there is no NSIS state 2066 left at the nodes along the path. 2068 NSIS initiators can use CREATE/EXTERNAL message with lifetime set to 2069 zero in an aggregated way, such that a single CREATE or EXTERNAL 2070 message is terminating multiple NATFW NSLP signaling sessions. NIs 2071 can follow this procedure if they like to aggregate NATFW NSLP 2072 signaling session deletion requests: The NI uses the CREATE or 2073 EXTERNAL message with the session ID set to zero and the MRI's 2074 source-address set to its used IP address. All other fields of the 2075 respective NATFW NSLP signaling sessions to be terminated are set as 2076 well, otherwise these fields are completely wildcarded. The NSLP 2077 message is transferred to the NTLP requesting 'explicit routing' as 2078 described in Sections 5.2.1 and 7.1.4. in [I-D.ietf-nsis-ntlp]. 2080 The outbound NF receiving such an aggregated CREATE or EXTERNAL 2081 message MUST reject it with an error RESPONSE of class 'Permanent 2082 failure' (0x5) with response code 'Authentication failed' (0x01) if 2083 the authentication fails and with an error RESPONSE of class 2084 'Permanent failure' (0x5) with response code 'Authorization failed' 2085 (0x02) if the authorization fails. Per NATFW NSLP signaling session 2086 proof of ownership, as it is defined in this memo, is not possible 2087 anymore when using this aggregated way. However, the outbound NF can 2088 use the relationship between the information of the received CREATE 2089 or EXTERNAL message and the GIST messaging association where the 2090 request has been received. The outbound NF MUST only accept this 2091 aggregated CREATE or EXTERNAL message through already established 2092 GIST messaging associations with the NI. The outbound NF MUST NOT 2093 propagate this aggregated CREATE or EXTERNAL message but it MAY 2094 generate and forward per NATFW NSLP signaling session CREATE or 2095 EXTERNAL messages. 2097 3.7.5. Reporting Asynchronous Events 2099 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 2100 to report asynchronous events to other NATFW NSLP nodes, especially 2101 to allow reporting back to the NATFW NSLP initiator. Such 2102 asynchronous events may be premature NATFW NSLP signaling session 2103 termination, changes in local policies, route change or any other 2104 reason that indicates change of the NATFW NSLP signaling session 2105 state. 2107 NFs and NRs may generate NOTIFY messages upon asynchronous events, 2108 with a NATFW_INFO object indicating the reason for event. These 2109 reasons can be carried in the NATFW_INFO object (class MUST be set to 2110 'Informational' (0x1)) within the NOTIFY message. This list shows 2111 the response codes and the associated actions to take at NFs and the 2112 NI: 2114 o 'Route change: possible route change on the outbound path' (0x01): 2115 Follow instructions in Section 3.9. This MUST be sent inbound and 2116 outbound, if the signalling session is any state except 2117 'Transitory'. The NOTIFY message for signalling sessions in state 2118 transitory MUST be discarded, as the signalling session is anyhow 2119 transitory. The outbound NOTIFY message MUST be sent with 2120 explicit routing by providing the SII-Handle to the NTLP. 2122 o 'Re-authentication required' (0x02): The NI should re-send the 2123 authentication. This MUST be sent inbound. 2125 o 'NATFW node is going down soon' (0x03): The NI and other NFs 2126 should be prepared for a service interruption at any time. This 2127 message MAY be sent inbound and outbound. 2129 o 'NATFW signaling session lifetime expired' (0x04): The NATFW 2130 signaling session has been expired and the signaling session is 2131 invalid now. NFs MUST mark the signaling session as 'Dead'. This 2132 message MAY be sent inbound and outbound. 2134 o 'NATFW signaling session terminated' (0x05): The NATFW signaling 2135 session has been terminated by any reason and the signaling 2136 session is invalid now. NFs MUST mark the signaling session as 2137 'Dead'. This message MAY be sent inbound and outbound. 2139 NOTIFY messages are always sent hop-by-hop inbound towards NI until 2140 they reach NI or outbound towards the NR as indicated in the list 2141 above. 2143 The initial processing when receiving a NOTIFY message is the same 2144 for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages 2145 through already established NTLP messaging associations. The further 2146 processing is different for each NATFW NSLP node type and depends on 2147 the events notified: 2149 o NSLP initiator: NIs analyze the notified event and behave 2150 appropriately based on the event type. NIs MUST NOT generate 2151 NOTIFY messages. 2153 o NSLP forwarder: NFs analyze the notified event and behave based on 2154 the above description per response code. NFs SHOULD generate 2155 NOTIFY messages upon asynchronous events and forward them inbound 2156 towards the NI or outbound towards the NR, depending on the 2157 received direction, i.e., inbound messages MUST be forwarded 2158 further inbound and outbound messages MUST be forwarded further 2159 outbound. NFs MUST silently discard NOTIFY messages that have 2160 been received outbound but are only allowed to be sent inbound, 2161 e.g. 'Re-authentication required' (0x02). 2163 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 2164 asynchronous events including a response code based on the 2165 reported event. The NR MUST silently discard NOTIFY messages that 2166 have been received outbound but are only allowed to be sent 2167 inbound, e.g. 'Re-authentication required' (0x02), 2169 NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions 2170 at the same time, can experience problems when shutting down service 2171 suddenly. This sudden shutdown can be result of node local failure, 2172 for instance, due to a hardware failure. This NF generates NOTIFY 2173 messages for each of the NATFW NSLP signaling sessions and tries to 2174 send them inbound. Due to the number of NOTIFY messages to be sent, 2175 the shutdown of the node may be unnecessarily prolonged, since not 2176 all messages can be sent at the same time. This case can be 2177 described as a NOTIFY storm, if a multitude of NATFW NSLP signaling 2178 sessions is involved. 2180 To avoid the need of generating per NATFW NSLP signaling session 2181 NOTIFY messages in such a scenario described or similar cases, NFs 2182 SHOULD follow this procedure: The NF uses the NOTIFY message with the 2183 session ID in the NTLP set to zero, with the MRI completely 2184 wildcarded, using the 'explicit routing' as described in Sections 2185 5.2.1 and 7.1.4. in [I-D.ietf-nsis-ntlp]. The inbound NF receiving 2186 this type of NOTIFY immediately regards all NATFW NSLP signaling 2187 sessions from that peer matching the MRI as void. This message will 2188 typically result in multiple NOTIFY messages at the inbound NF, i.e., 2189 the NF can generate per terminated NATFW NSLP signaling session a 2190 NOTIFY message. However, a NF MAY aggregate again the NOTIFY 2191 messages as described here. 2193 3.7.6. Proxy Mode of Operation 2195 Some migration scenarios need specialized support to cope with cases 2196 where NSIS is only deployed in same areas of the Internet. End-to- 2197 end signaling is going to fail without NSIS support at or near both 2198 data sender and data receiver terminals. A proxy mode of operation 2199 is needed. This proxy mode of operation must terminate the NATFW 2200 NSLP signaling topologically-wise as close as possible to the 2201 terminal for which it is proxying and proxy all messages. This NATFW 2202 NSLP node doing the proxying of the signaling messages becomes either 2203 the NI or the NR for the particular NATFW NSLP signaling session, 2204 depending on whether it is the DS or DR that does not support NSIS. 2205 Typically, the edge-NAT or the edge-firewall would be used to proxy 2206 NATFW NSLP messages. 2208 This proxy mode operation does not require any new CREATE or EXTERNAL 2209 message type, but relies on extended CREATE and EXTERNAL message 2210 types. They are called respectively CREATE-PROXY and EXTERNAL-PROXY 2211 and are distinguished by setting the P flag in the NSLP header to 2212 P=1. This flag instructs edge-NATs and edge-firewalls receiving them 2213 to operate in proxy mode for the NATFW NSLP signaling session in 2214 question. The semantics of the CREATE and EXTERNAL message types are 2215 not changed and the behavior of the various node types is as defined 2216 in Section 3.7.1 and Section 3.7.2, except for the proxying node. 2217 The following paragraphs describe the proxy mode operation for data 2218 receivers behind middleboxes and data senders behind middleboxes. 2220 3.7.6.1. Proxying for a Data Sender 2222 The NATFW NSLP gives the NR the ability to install state on the 2223 inbound path towards the data sender for outbound data packets, even 2224 when only the receiving side is running NSIS (as shown in Figure 18). 2225 The goal of the method described is to trigger the edge-NAT/ 2226 edge-firewall to generate a CREATE message on behalf of the data 2227 receiver. In this case, an NR can signal towards the network border 2228 as it is performed in the standard EXTERNAL message handling scenario 2229 as in Section 3.7.2. The message is forwarded until the edge-NAT/ 2230 edge-firewall is reached. A public IP address and port number is 2231 reserved at an edge-NAT/edge-firewall. As shown in Figure 18, unlike 2232 the standard EXTERNAL message handling case, the edge-NAT/ 2233 edge-firewall is triggered to send a CREATE message on a new reverse 2234 path which traverse several firewalls or NATs. The new reverse path 2235 for CREATE is necessary to handle routing asymmetries between the 2236 edge-NAT/edge-firewall and DR. It must be stressed that the 2237 semantics of the CREATE and EXTERNAL messages is not changed, i.e., 2238 each is processed as described earlier. 2240 DS Public Internet NAT/FW Private address DR 2241 No NI NF space NR 2242 NR+ NI+ 2244 | | EXTERNAL-PROXY[(DTInfo)] | 2245 | |<------------------------- | 2246 | | RESPONSE[Error/Success] | 2247 | | ---------------------- > | 2248 | | CREATE | 2249 | | ------------------------> | 2250 | | RESPONSE[Error/Success] | 2251 | | <---------------------- | 2252 | | | 2254 Figure 18: EXTERNAL Triggering Sending of CREATE Message 2256 A NATFW_NONCE object, carried in the EXTERNAL and CREATE message, is 2257 used to build the relationship between received CREATEs at the 2258 message initiator. An NI+ uses the presence of the NATFW_NONCE 2259 object to correlate it to the particular EXTERNAL-PROXY. The absence 2260 of a NONCE object indicates a CREATE initiated by the DS and not by 2261 the edge-NAT. The two signaling sessions, i.e., the session for 2262 EXTERNAL-PROXY and the session for CREATE, are not independent. The 2263 primary session is the EXTERNAL-PROXY session. The CREATE session is 2264 secondary to the EXTERNAL-PROXY session, i.e., the CREATE session is 2265 valid as long as the EXTERNAL-PROXY session is the signaling states 2266 'Established' or 'Transitory'. There is no CREATE session in any 2267 other signaling state of the EXTERNAL-PROXY, i.e., 'pending' or 2268 'dead'. This ensures a fate-sharing between both signaling sessions. 2270 These processing rules of EXTERNAL-PROXY messages are added to the 2271 regular EXTERNAL processing: 2273 o NSLP initiator (NI+): The NI+ MUST take the session ID (SID) value 2274 of the EXTERNAL-PROXY session as the nonce value of the 2275 NATFW_NONCE object. 2277 o NSLP forwarder being either edge-NAT or edge-firewall: When the NF 2278 accepts a EXTERNAL-PROXY message, it generates a successful 2279 RESPONSE message as if it were the NR and additionally, it 2280 generates a CREATE message as defined in Section 3.7.1 and 2281 includes a NATFW_NONCE object having the same value as of the 2282 received NATFW_NONCE object. The NF MUST NOT generate a CREATE- 2283 PROXY message. The NF MUST refresh the CREATE message signaling 2284 session only if a EXTERNAL-PROXY refresh message has been received 2285 first. This also includes tearing down signaling sessions, i.e., 2286 the NF must teardown the CREATE signaling session only if a 2287 EXTERNAL-PROXY message with lifetime set to 0 has been received 2288 first. 2290 The scenario described in this section challenges the data receiver 2291 because it must make a correct assumption about the data sender's 2292 ability to use NSIS NATFW NSLP signaling. It is possible for the DR 2293 to make the wrong assumption in two different ways: 2295 a) the DS is NSIS unaware but the DR assumes the DS to be NSIS 2296 aware and 2298 b) the DS is NSIS aware but the DR assumes the DS to be NSIS 2299 unaware. 2301 Case a) will result in middleboxes blocking the data traffic, since 2302 DS will never send the expected CREATE message. Case b) will result 2303 in the DR successfully requesting proxy mode support by the edge-NAT 2304 or edge-firewall. The edge-NAT/edge-firewall will send CREATE 2305 messages and DS will send CREATE messages as well. Both CREATE 2306 messages are handled as separated NATFW NSLP signaling sessions and 2307 therefore the common rules per NATFW NSLP signaling session apply; 2308 the NATFW_NONCE object is used to differentiate CREATE messages 2309 generated by the edge-NAT/edge-firewall from NI initiated CREATE 2310 messages. It is the NR's responsibility to decide whether to 2311 teardown the EXTERNAL-PROXY signaling sessions in the case where the 2312 data sender's side is NSIS aware, but was incorrectly assumed not to 2313 be so by the DR. It is RECOMMENDED that a DR behind NATs uses the 2314 proxy mode of operation by default, unless the DR knows that the DS 2315 is NSIS aware. The DR MAY cache information about data senders which 2316 it has found to be NSIS aware in past NATFW NSLP signaling sessions. 2318 There is a possible race condition between the RESPONSE message to 2319 the EXTERNAL-PROXY and the CREATE message generated by the edge-NAT. 2320 The CREATE message can arrive earlier than the RESPONSE message. An 2321 NI+ MUST accept CREATE messages generated by the edge-NAT even if the 2322 RESPONSE message to the EXTERNAL-PROXY was not received. 2324 3.7.6.2. Proxying for a Data Receiver 2326 As with data receivers behind middleboxes, data senders behind 2327 middleboxes can require proxy mode support. The issue here is that 2328 there is no NSIS support at the data receiver's side and, by default, 2329 there will be no response to CREATE messages. This scenario requires 2330 the last NSIS NATFW NSLP aware node to terminate the forwarding and 2331 to proxy the response to the CREATE message, meaning that this node 2332 is generating RESPONSE messages. This last node may be an edge-NAT/ 2333 edge-firewall, or any other NATFW NSLP peer, that detects that there 2334 is no NR available (probably as a result of GIST timeouts but there 2335 may be other triggers). 2337 DS Private Address NAT/FW Public Internet NR 2338 NI Space NF no NR 2340 | | | 2341 | CREATE-PROXY | | 2342 |------------------------------>| | 2343 | | | 2344 | RESPONSE[SUCCESS/ERROR] | | 2345 |<------------------------------| | 2346 | | | 2348 Figure 19: Proxy Mode CREATE Message Flow 2350 The processing of CREATE-PROXY messages and RESPONSE messages is 2351 similar to Section 3.7.1, except that forwarding is stopped at the 2352 edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to 2353 NI according to the situation (error/success) and will be the NR for 2354 future NATFW NSLP communication. 2356 The NI can choose the proxy mode of operation although the DR is NSIS 2357 aware. The CREATE-PROXY mode would not configure all NATs and 2358 firewalls along the data path, since it is terminated at the edge- 2359 device. Any device beyond this point will never receive any NATFW 2360 NSLP signaling for this flow. 2362 3.7.6.3. Incremental Deployment using the Proxy Mode 2364 The above sections described the the proxy mode for cases where the 2365 NATFW NSLP is solely deployed at the network edges. However, the 2366 NATFW NSLP might be incrementally deployed first in some network 2367 edges, but later on also in other parts of the network. Using the 2368 proxy mode only, would prevent the NI to determine whether the other 2369 parts of the network have also been upgraded to use the NATFW NSLP. 2370 One way of determining whether the path from the NI to the NR is 2371 NATFW NSLP capable is to use the regular CREATE message and to wait 2372 for a successful response or an error response. This will lead to 2373 extra messages being sent, as a CREATE message in addition to the 2374 anyhow required CREATE-PROXY message is sent from the NI. 2376 The NATFW NSLP allows the usage of the proxy-mode and a further 2377 probing of the path by the edge-NAT or edge-firewall. The NI can 2378 request proxy-mode handling as described, and can set the E flag (see 2379 Section Figure 20) to request the edge-NAT or edge-firewall to probe 2380 the further path for NATFW NSLP enabled NFs or NR. 2382 The edge-NAT or edge-firewall MUST continue to send the CREATE-PROXY 2383 or EXTERNAL-proxy towards the NR, if the received proxy-mode message 2384 has the E flag set, in addition to the regular proxy mode handling. 2386 The edge-NAT or edge-firewall relies on the NTLP measures to 2387 determine whether there is no other NATFW NSLP reachable towards NR. 2388 A failed attempt to forward the request message to the NR will be 2389 silently discarded. A successful attempt of forwarding the request 2390 message to the NR will be acknowledged by the NR with a successful 2391 response message, which is subject to the regular behavior described 2392 in the proxy-mode sections. 2394 3.7.6.4. Deployment Considerations for Edge-Devices 2396 The proxy mode assumes that the edge-NAT or edge-firewall are 2397 properly configured by network operator, i.e., the edge-device is 2398 really the final NAT or firewall of that particular network. There 2399 is currently no known way of letting the NATFW NSLP automatically 2400 detect which of the NAT or firewalls are the actual edge of a 2401 network. Therefore, it is important for the network operator to 2402 configure the edge-NAT or edge-firewall and also to re-configure 2403 these devices if they are not at the edge anymore. For instance, an 2404 edge-NAT is located within an ISP and the ISP chooses to place 2405 another NAT in front of this edge-NAT. In this case, the ISP needs 2406 to reconfigure the old edge-NAT to be a regular NATFW NLSP NAT and to 2407 configure the newly installed NAT to be the edge-NAT. 2409 3.8. De-Multiplexing at NATs 2411 Section 3.7.2 describes how NSIS nodes behind NATs can obtain a 2412 public reachable IP address and port number at a NAT and and how the 2413 resulting mapping rule can be activated by using CREATE messages (see 2414 Section 3.7.1). The information about the public IP address/port 2415 number can be transmitted via an application level signaling protocol 2416 and/or third party to the communication partner that would like to 2417 send data toward the host behind the NAT. However, NSIS signaling 2418 flows are sent towards the address of the NAT at which this 2419 particular IP address and port number is allocated and not directly 2420 to the allocated IP address and port number. The NATFW NSLP 2421 forwarder at this NAT needs to know how the incoming NSLP CREATE 2422 messages are related to reserved addresses, meaning how to de- 2423 multiplex incoming NSIS CREATE messages. 2425 The de-multiplexing method uses information stored at the local NATFW 2426 NSLP node and in the policy rule. The policy rule uses the LE-MRM 2427 MRI source-address (see [I-D.ietf-nsis-ntlp]) as the flow destination 2428 IP address and the network-layer-version (IP-ver) as IP version. The 2429 external IP address at the NAT is stored as the external flow 2430 destination IP address. All other parameters of the policy rule 2431 other than the flow destination IP address are wildcarded if no 2432 NATFW_DTINFO object is included in the EXTERNAL message. The LE-MRM 2433 MRI destination-address MUST NOT be used in the policy rule, since it 2434 is solely a signaling destination address. 2436 If the NATFW_DTINFO object is included in the EXTERNAL message, the 2437 policy rule is filled with further information. The 'dst port 2438 number' field of the NATFW_DTINFO is stored as the flow destination 2439 port number. The 'protocol' field is stored as the flow protocol. 2440 The 'src port number' field is stored as the flow source port number. 2441 The 'data sender's IPv4 address' is stored as the flow source IP 2442 address. Note that some of these field can contain wildcards. 2444 When receiving a CREATE message at the NATFW NSLP it uses the flow 2445 information stored in the MRI to do the matching process. This table 2446 shows the parameters to be compared against each others. Note that 2447 not all parameters can be present in a MRI at the same time. 2449 +-------------------------------+--------------------------------+ 2450 | Flow parameter (Policy Rule) | MRI parameter (CREATE message) | 2451 +-------------------------------+--------------------------------+ 2452 | IP version | network-layer-version | 2453 | | | 2454 | Protocol | IP-protocol | 2455 | | | 2456 | source IP address (w) | source-address (w) | 2457 | | | 2458 | external IP address | destination-address | 2459 | | | 2460 | destination IP address (n/u) | N/A | 2461 | | | 2462 | source port number (w) | L4-source-port (w) | 2463 | | | 2464 | external port number (w) | L4-destination-port (w) | 2465 | | | 2466 | destination port number (n/u) | N/A | 2467 | | | 2468 | IPsec-SPI | ipsec-SPI | 2469 +-------------------------------+--------------------------------+ 2471 Table entries marked with (w) can be wildcarded and entries marked 2472 with (n/u) are not used for the matching. 2474 Table 1 2476 It should be noted that the Protocol/IP-protocol entries in Table 1 2477 refers to 'Protocol' field in the IPv4 header or the 'next header' 2478 entry in the IPv6 header. 2480 3.9. Reacting to Route Changes 2482 The NATFW NSLP needs to react to route changes in the data path. 2483 This assumes the capability to detect route changes, to perform NAT 2484 and firewall configuration on the new path and possibly to tear down 2485 NATFW NSLP signaling session state on the old path. The detection of 2486 route changes is described in Section 7 of [I-D.ietf-nsis-ntlp] and 2487 the NATFW NSLP relies on notifications about route changes by the 2488 NTLP. This notification will be conveyed by the API between NTLP and 2489 NSLP, which is out of scope of this memo. 2491 A NATFW NSLP node other than the NI or NI+ detecting a route change, 2492 by means described in the NTLP specification or others, generates a 2493 NOTIFY message indicating this change and sends this inbound towards 2494 NI and outbound towards the NR (see also Section 3.7.5.). 2495 Intermediate NFs on the way to the NI can use this information to 2496 decide later if their NATFW NSLP signaling session can be deleted 2497 locally, if they do not receive an update within a certain time 2498 period, as described in Section 3.2.8. It is important to consider 2499 the transport limitations of NOTIFY messages as mandated in 2500 Section 3.7.5. 2502 The NI receiving this NOTIFY message MAY generate a new CREATE or 2503 EXTERNAL message and send it towards the NATFW NSLP signaling 2504 session's NI as for the initial message using the same session ID. 2505 All the remaining processing and message forwarding, such as NSLP 2506 next hop discovery, is subject to regular NSLP processing as 2507 described in the particular sections. Normal routing will guide the 2508 new CREATE or EXTERNAL message to the correct NFs along the changed 2509 route. NFs that were on the original path receiving these new CREATE 2510 or EXTERNAL messages (see also Section 3.10), can use the session ID 2511 to update the existing NATFW NSLP signaling session, whereas NFs that 2512 were not on the original path will create new state for this NATFW 2513 NSLP signaling session. The next section describes how policy rules 2514 are updated. 2516 3.10. Updating Policy Rules 2518 NSIS initiators can request an update of the installed/reserved 2519 policy rules at any time within a NATFW NSLP signaling session. 2520 Updates to policy rules can be required due to node mobility (NI is 2521 moving from one IP address to another), route changes (this can 2522 result in a different NAT mapping at a different NAT device), or the 2523 wish of the NI to simply change the rule. NIs can update policy 2524 rules in existing NATFW NSLP signaling sessions by sending an 2525 appropriate CREATE or EXTERNAL message (similar to Section 3.4) with 2526 modified message routing information (MRI) as compared with that 2527 installed previously, but using the existing session ID to identify 2528 the intended target of the update. With respect to authorization and 2529 authentication, this update CREATE or EXTERNAL message is treated in 2530 exactly the same way as any initial message. Therefore, any node 2531 along in the NATFW NSLP signaling session can reject the update with 2532 an error RESPONSE message, as defined in the previous sections. 2534 The message processing and forwarding is executed as defined in the 2535 particular sections. A NF or the NR receiving an update, simply 2536 replaces the installed policy rules installed in the firewall/NAT. 2537 The local procedures on how to update the MRI in the firewall/NAT is 2538 out of scope of this memo. 2540 4. NATFW NSLP Message Components 2542 A NATFW NSLP message consists of a NSLP header and one or more 2543 objects following the header. The NSLP header is carried in all 2544 NATFW NSLP messages and objects are Type-Length-Value (TLV) encoded 2545 using big endian (network ordered) binary data representations. 2546 Header and objects are aligned to 32 bit boundaries and object 2547 lengths that are not multiples of 32 bits must be padded to the next 2548 higher 32 bit multiple. 2550 The whole NSLP message is carried as payload of a NTLP message. 2552 Note that the notation 0x is used to indicate hexadecimal numbers. 2554 4.1. NSLP Header 2556 All GIST NSLP-Data objects for the NATFW NSLP MUST contain this 2557 common header as the first 32 bits of the object (this is not the 2558 same as the GIST Common Header). It contains two fields, the NSLP 2559 message type and the P Flag, plus two reserved fields. The total 2560 length is 32 bits. The layout of the NSLP header is defined by 2561 Figure 20. 2563 0 1 2 3 2564 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 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | Message type |P|E| reserved | reserved | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 Figure 20: Common NSLP header 2571 The reserved field MUST be set to zero in the NATFW NSLP header 2572 before sending and MUST be ignored during processing of the header. 2574 The defined messages types are: 2576 o 0x1 : CREATE 2578 o 0x2 : EXTERNAL 2580 o 0x3: RESPONSE 2582 o 0x4: NOTIFY 2584 If a message with another type is received, an error RESPONSE of 2585 class 'Protocol error' (0x3) with response code 'Illegal message 2586 type' (0x01) MUST be generated. 2588 The P flag indicates the usage of proxy mode. If proxy mode is used 2589 it MUST be set to 1. Proxy mode usage MUST only be used in 2590 combination with the message types CREATE and EXTERNAL. The P flag 2591 MUST be ignored when processing messages with type RESPONSE or 2592 NOTIFY. 2594 The E flag indicates in proxy mode whether the edge-NAT or edge- 2595 firewall MUST continue sending the message to the NR, i.e. end-to- 2596 end. The E flag MUST only be set to 1 if the P flag is set, 2597 otherwise it MUST be ignored. The E flag MUST only be used in 2598 combination with the message types CREATE and EXTERNAL. The E flag 2599 MUST be ignored when processing messages with type RESPONSE or 2600 NOTIFY. 2602 4.2. NSLP Objects 2604 NATFW NSLP objects use a common header format defined by Figure 21. 2605 The object header contains these fields: two flags, two reserved 2606 bits, the NSLP object type, a reserved field of 4 bits, and the 2607 object length. Its total length is 32 bits. 2609 0 1 2 3 2610 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 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 Figure 21: Common NSLP object header 2617 The object length field contains the total length of the object 2618 without the object header. The unit is a word, consisting of 4 2619 octets. The particular values of type and length for each NSLP 2620 object are listed in the subsequent sections that define the NSLP 2621 objects. An error RESPONSE of class 'Protocol error' (0x3) with 2622 response code 'Wrong object length' (0x07) MUST be generated if the 2623 length given for the object in the object header did not match the 2624 length of the object data present. The two leading bits of the NSLP 2625 object header are used to signal the desired treatment for objects 2626 whose treatment has not been defined in this memo (see 2627 [I-D.ietf-nsis-ntlp], Section A.2.1), i.e., the Object Type has not 2628 been defined. NATFW NSLP uses a subset of the categories defined in 2629 GIST: 2631 o AB=00 ("Mandatory"): If the object is not understood, the entire 2632 message containing it MUST be rejected with an error RESPONSE of 2633 class 'Protocol error' (0x3) with response code 'Unknown object 2634 present' (0x06). 2636 o AB=01 ("Optional"): If the object is not understood, it should be 2637 deleted and then the rest of the message processed as usual. 2639 o AB=10 ("Forward"): If the object is not understood, it should be 2640 retained unchanged in any message forwarded as a result of message 2641 processing, but not stored locally. 2643 The combination AB=11 MUST NOT be used and an error RESPONSE of class 2644 'Protocol error' (0x3) with response code 'Invalid Flag-Field 2645 combination' (0x09) MUST be generated. 2647 The following sections do not repeat the common NSLP object header, 2648 they just list the type and the length. 2650 4.2.1. Signaling Session Lifetime Object 2652 The signaling session lifetime object carries the requested or 2653 granted lifetime of a NATFW NSLP signaling session measured in 2654 seconds. 2656 Type: NATFW_LT (IANA-TBD) 2658 Length: 1 2660 0 1 2 3 2661 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 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2663 | NATFW NSLP signaling session lifetime | 2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 Figure 22: Signaling Session Lifetime object 2668 4.2.2. External Address Object 2670 The external address object can be included in RESPONSE messages 2671 (Section 4.3.3) only. It carries the publicly reachable IP address, 2672 and if applicable port number, at an edge-NAT. 2674 Type: NATFW_EXTERNAL-IP (IANA-TBD) 2676 Length: 2 2677 0 1 2 3 2678 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 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | port number |IP-Ver | reserved | 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 | IPv4 address | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 Figure 23: External Address Object for IPv4 addresses 2687 Please note that the field 'port number' MUST be set to 0 if only an 2688 IP address has been reserved, for instance, by a traditional NAT. A 2689 port number of 0 MUST be ignored in processing this object. 2691 IP-Ver (4 bits): The IP version number. This field MUST be set to 4. 2693 4.2.3. External Binding Address Object 2695 The external binding address object can be included in RESPONSE 2696 messages (Section 4.3.3) and EXTERNAL (Section 3.7.2) messages. It 2697 carries one or multiple external binding addresses, and if applicable 2698 port number, for multi-level NATs deployments (for an example see 2699 Section 2.5). The utilization of the information carried in this 2700 object is described in Appendix B. 2702 Type: NATFW_EXTERNAL_BINDING (IANA-TBD) 2704 Length: 1 + number of IPv4 addresses 2706 0 1 2 3 2707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | port number |IP-Ver | reserved | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 | IPv4 address #1 | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 // . . . // 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 | IPv4 address #n | 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 Figure 24: External Binding Address Object 2720 Please note that the field 'port number' MUST be set to 0 if only an 2721 IP address has been reserved, for instance, by a traditional NAT. A 2722 port number of 0 MUST be ignored in processing this object. 2724 IP-Ver (4 bits): The IP version number. This field MUST be set to 4. 2726 4.2.4. Extended Flow Information Object 2728 In general, flow information is kept in the message routing 2729 information (MRI) of the NTLP. Nevertheless, some additional 2730 information may be required for NSLP operations. The 'extended flow 2731 information' object carries this additional information about the 2732 action of the policy rule for firewalls/NATs and contiguous port . 2734 Type: NATFW_EFI (IANA-TBD) 2736 Length: 1 2738 0 1 2 3 2739 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 2740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 | rule action | sub_ports | 2742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 Figure 25: Extended Flow Information 2746 This object has two fields, 'rule action' and 'sub_ports'. The 'rule 2747 action' field has these meanings: 2749 o 0x0001: Allow: A policy rule with this action allows data traffic 2750 to traverse the middlebox and the NATFW NSLP MUST allow NSLP 2751 signaling to be forwarded. 2753 o 0x0002: Deny: A policy rule with this action blocks data traffic 2754 from traversing the middlebox and the NATFW NSLP MUST NOT allow 2755 NSLP signaling to be forwarded. 2757 If the 'rule action' field contains neither 0x0001 nor 0x0002, an 2758 error RESPONSE of class 'Signaling session failure' (0x6) with 2759 response code 'Unknown policy rule action' (0x05) MUST be generated. 2761 The 'sub_ports' field contains the number of contiguous transport 2762 layer ports to which this rule applies. The default value of this 2763 field is 0, i.e., only the port specified in the NTLP's MRM or 2764 NATFW_DTINFO object is used for the policy rule. A value of 1 2765 indicates that additionally to the port specified in the NTLP's MRM 2766 (port1), a second port (port2) is used. This value of port 2 is 2767 calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT 2768 be used in this field and an error RESPONSE of class 'Signaling 2769 session failure' (0x6) with response code 'Requested value in 2770 sub_ports field in NATFW_EFI not permitted' (0x08) MUST be generated. 2772 This two contiguous port numbered ports, can be used by legacy voice 2773 over IP equipment. This legacy equipment assumes two adjacent port 2774 numbers for its RTP/RTCP flows respectively. 2776 4.2.5. Information Code Object 2778 This object carries the response code, which may be indications for 2779 either a successful or failed CREATE or EXTERNAL message depending on 2780 the value of the 'response code' field. 2782 Type: NATFW_INFO (IANA-TBD) 2784 Length: 1 2786 0 1 2 3 2787 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 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 | Resv. | Class | Response Code |r|r|r|r| Object Type | 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 Figure 26: Information Code Object 2794 The field 'resv.' is reserved for future extensions and MUST be set 2795 to zero when generating such an object and MUST be ignored when 2796 receiving. The 'Object Type' field contains the type of the object 2797 causing the error. The value of 'Object Type' is set to 0, if no 2798 object is concerned. The leading fours bits marked with 'r' are 2799 always set to zero and ignored. The 4 bit class field contains the 2800 severity class. The following classes are defined: 2802 o 0x0: Reserved 2804 o 0x1: Informational (NOTIFY only) 2806 o 0x2: Success 2808 o 0x3: Protocol error 2810 o 0x4: Transient failure 2812 o 0x5: Permanent failure 2814 o 0x6: Signaling session failure 2816 Within each severity class a number of responses values are defined 2817 o Informational: 2819 * 0x01: Route change: possible route change on the outbound path. 2821 * 0x02: Re-authentication required. 2823 * 0x03: NATFW node is going down soon. 2825 * 0x04: NATFW signaling session lifetime expired. 2827 * 0x05: NATFW signaling session terminated. 2829 o Success: 2831 * 0x01: All successfully processed. 2833 o Protocol error: 2835 * 0x01: Illegal message type: the type given in the Message Type 2836 field of the NSLP header is unknown. 2838 * 0x02: Wrong message length: the length given for the message in 2839 the NSLP header does not match the length of the message data. 2841 * 0x03: Bad flags value: an undefined flag or combination of 2842 flags was set in the NSLP header. 2844 * 0x04: Mandatory object missing: an object required in a message 2845 of this type was missing. 2847 * 0x05: Illegal object present: an object was present which must 2848 not be used in a message of this type. 2850 * 0x06: Unknown object present: an object of an unknown type was 2851 present in the message. 2853 * 0x07: Wrong object length: the length given for the object in 2854 the object header did not match the length of the object data 2855 present. 2857 * 0x08: Unknown object field value: a field in an object had an 2858 unknown value. 2860 * 0x09: Invalid Flag-Field combination: An object contains an 2861 invalid combination of flags and/or fields. 2863 * 0x0A: Duplicate object present. 2865 * 0x0B: Received EXTERNAL request message on external side. 2867 o Transient failure: 2869 * 0x01: Requested resources temporarily not available. 2871 o Permanent failure: 2873 * 0x01: Authentication failed. 2875 * 0x02: Authorization failed. 2877 * 0x04: Internal or system error. 2879 * 0x06: No edge-device here. 2881 * 0x07: Did not reach the NR. 2883 o Signaling session failure: 2885 * 0x01: Session terminated asynchronously. 2887 * 0x02: Requested lifetime is too big. 2889 * 0x03: No reservation found matching the MRI of the CREATE 2890 request. 2892 * 0x04: Requested policy rule denied due to policy conflict. 2894 * 0x05: Unknown policy rule action. 2896 * 0x06: Requested rule action not applicable. 2898 * 0x07: NATFW_DTINFO object is required. 2900 * 0x08: Requested value in sub_ports field in NATFW_EFI not 2901 permitted. 2903 * 0x09: Requested IP protocol not supported. 2905 * 0x0A: Plain IP policy rules not permitted -- need transport 2906 layer information. 2908 * 0x0B: ICMP type value not permitted. 2910 * 0x0C: source IP address range is too large. 2912 * 0x0D: destination IP address range is too large. 2914 * 0x0E: source L4-port range is too large. 2916 * 0x0F: destination L4-port range is too large. 2918 * 0x10: Requested lifetime is too small. 2920 * 0x11: Modified lifetime is too big. 2922 * 0x12: Modified lifetime is too small. 2924 4.2.6. Nonce Object 2926 This object carries the nonce value as described in Section 3.7.6. 2928 Type: NATFW_NONCE (IANA-TBD) 2930 Length: 1 2932 0 1 2 3 2933 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 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 | nonce | 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2938 Figure 27: Nonce Object 2940 4.2.7. Message Sequence Number Object 2942 This object carries the MSN value as described in Section 3.5. 2944 Type: NATFW_MSN (IANA-TBD) 2946 Length: 1 2948 0 1 2 3 2949 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 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 | message sequence number | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2954 Figure 28: Message Sequence Number Object 2956 4.2.8. Data Terminal Information Object 2958 The 'data terminal information' object carries additional information 2959 MUST be included the EXTERNAL message. EXTERNAL messages are 2960 transported by the NTLP using the Loose-End message routing method 2961 (LE-MRM). The LE-MRM contains only DR's IP address and a signaling 2962 destination address (destination address). This destination address 2963 is used for message routing only and is not necessarily reflecting 2964 the address of the data sender. This object contains information 2965 about (if applicable) DR's port number (the destination port number), 2966 DS' port number (the source port number), the used transport 2967 protocol, the prefix length of the IP address, and DS' IP address. 2969 Type: NATFW_DTINFO (IANA-TBD) 2971 Length: variable. Maximum 3. 2973 0 1 2 3 2974 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 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 |I|P|S| reserved | sender prefix | protocol | 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2978 : DR port number | DS port number : 2979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 : IPsec-SPI : 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 | data sender's IPv4 address | 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2985 Figure 29: Data Terminal IPv4 Address Object 2987 The flags are: 2989 o I: I=1 means that 'protocol' should be interpreted. 2991 o P: P=1 means that 'dst port number' and 'src port number' are 2992 present and should be interpreted. 2994 o S: S=1 means that SPI is present and should be interpreted. 2996 The SPI field is only present if S is set. The port numbers are only 2997 present if P is set. The flags P and S MUST NOT be set at the same 2998 time. An error RESPONSE of class 'Protocol error' (0x3) with 2999 response code 'Invalid Flag-Field combination' (0x09) MUST be 3000 generated if they are both set. If either P or S is set, I MUST be 3001 set as well and the protocol field MUST carry the particular 3002 protocol. An error RESPONSE of class 'Protocol error' (0x3) with 3003 response code 'Invalid Flag-Field combination' (0x09) MUST be 3004 generated if S or P is set but I is not set. 3006 The fields MUST be interpreted according to these rules: 3008 o (data) sender prefix: This parameter indicates the prefix length 3009 of the 'data sender's IP address' in bits. For instance, a full 3010 IPv4 address requires 'sender prefix' to be set to 32. A value of 3011 0 indicates an IP address wildcard. 3013 o protocol: The IP protocol field. This field MUST be interpreted 3014 if I=1, otherwise it MUST be set to 0 and MUST be ignored. 3016 o DR port number: The port number at the data receiver (DR), i.e., 3017 the destination port. A value of 0 indicates a port wildcard, 3018 i.e., the destination port number is not known. Any other value 3019 indicates the destination port number. 3021 o DS port number: The port number at the data sender (DS), i.e., the 3022 source port. A value of 0 indicates a port wildcard, i.e., the 3023 source port number is not known. Any other value indicates the 3024 source port number. 3026 o data sender's IPv4 address: The source IP address of the data 3027 sender. This field MUST be set to zero if no IP address is 3028 provided, i.e., a complete wildcard is desired (see dest prefix 3029 field above). 3031 4.2.9. ICMP Types Object 3033 The 'ICMP types' object contains additional information needed to 3034 configure a NAT of firewall with rules to control ICMP traffic. The 3035 object contains a number of values of the ICMP Type field for which a 3036 filter action should be set up: 3038 Type: NATFW_ICMP_TYPES (IANA-TBD) 3040 Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 3042 Where DIV is an integer division. 3044 0 1 2 3 3045 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 3046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3047 | Count | Type | Type | ........ | 3048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3049 | ................ | 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 | ........ | Type | (Padding) | 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3054 Figure 30: ICMP Types Object 3056 The fields MUST be interpreted according to these rules: 3058 count: 8 bit integer specifying the number of 'Type' entries in 3059 the object. 3061 type: 8 bit field specifying an ICMP Type value to which this rule 3062 applies. 3064 padding: Sufficient 0 bits to pad out the last word so that the 3065 total size of object is an even multiple of words. Ignored on 3066 reception. 3068 4.3. Message Formats 3070 This section defines the content of each NATFW NSLP message type. 3071 The message types are defined in Section 4.1. 3073 Basically, each message is constructed of NSLP header and one or more 3074 NSLP objects. The order of objects is not defined, meaning that 3075 objects may occur in any sequence. Objects are marked either with 3076 mandatory (M) or optional (O). Where (M) implies that this 3077 particular object MUST be included within the message and where (O) 3078 implies that this particular object is OPTIONAL within the message. 3079 Objects defined in this memo always carry the flag combination AB=00 3080 in the NSLP object header. An error RESPONSE message of class 3081 'Protocol error' (0x3) with response code 'Mandatory object missing' 3082 (0x04) MUST be generated if a mandatory declared object is missing. 3083 An error RESPONSE message of class 'Protocol error' (0x3) with 3084 response code 'Illegal object present' (0x05) MUST be generated if an 3085 object was present which must not be used in a message of this type. 3086 An error RESPONSE message of class 'Protocol error' (0x3) with 3087 response code 'Duplicate object present' (0x0A) MUST be generated if 3088 an object appears more than once in a message. 3090 Each section elaborates the required settings and parameters to be 3091 set by the NSLP for the NTLP, for instance, how the message routing 3092 information is set. 3094 4.3.1. CREATE 3096 The CREATE message is used to create NATFW NSLP signaling sessions 3097 and to create policy rules. Furthermore, CREATE messages are used to 3098 refresh NATFW NSLP signaling sessions and to delete them. 3100 The CREATE message carries these objects: 3102 o Signaling Session Lifetime object (M) 3104 o Extended flow information object (M) 3106 o Message sequence number object (M) 3108 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 3109 (O) 3111 o ICMP Types Object (O) 3113 The message routing information in the NTLP MUST be set to DS as 3114 source address and DR as destination address. All other parameters 3115 MUST be set according the required policy rule. CREATE messages MUST 3116 be transported by using the path-coupled MRM with direction set to 3117 'downstream' (outbound). 3119 4.3.2. EXTERNAL 3121 The EXTERNAL message is used to a) reserve an external IP address/ 3122 port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to 3123 block incoming data traffic at inbound firewalls. 3125 The EXTERNAL message carries these objects: 3127 o Signaling Session Lifetime object (M) 3129 o Message sequence number object (M) 3131 o Extended flow information object (M) 3133 o Data terminal information object (M) 3135 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 3136 (O) 3138 o ICMP Types Object (O) 3139 o External binding address object (O) 3141 The selected message routing method of the EXTERNAL message depends 3142 on a number of considerations. Section 3.7.2 describes it 3143 exhaustively how to select the correct method. EXTERNAL messages can 3144 be transported via the path-coupled message routing method (PC-MRM) 3145 or via the loose-end message routing method (LE-MRM). In the case of 3146 PC-MRM, the source-address is set to DS' address and the destination 3147 address is set to DR's address, the direction is set to inbound. In 3148 the case of LE-MRM, the destination-address is set to DR's address or 3149 to the signaling destination address. The source-address is set to 3150 DS's address. 3152 4.3.3. RESPONSE 3154 RESPONSE messages are responses to CREATE and EXTERNAL messages. 3155 RESPONSE messages MUST NOT be generated for any other message, such 3156 as NOTIFY and RESPONSE. 3158 The RESPONSE message for the class 'Success' (0x2) carries these 3159 objects: 3161 o Signaling Session Lifetime object (M) 3163 o Message sequence number object (M) 3165 o Information code object (M) 3167 o External address object (O) 3169 o External binding address object (O) 3171 The RESPONSE message for other classes than 'Success' (0x2) carries 3172 these objects: 3174 o Message sequence number object (M) 3176 o Information code object (M) 3178 This message is routed towards the NI hop-by-hop, using existing NTLP 3179 messaging associations. The MRM used for this message MUST be the 3180 same as MRM used by the corresponding CREATE or EXTERNAL message. 3182 4.3.4. NOTIFY 3184 The NOTIFY messages is used to report asynchronous events happening 3185 along the signaled path to other NATFW NSLP nodes. 3187 The NOTIFY message carries this object: 3189 o Information code object (M). 3191 The NOTIFY message is routed towards the next NF, NI, or NR hop-by- 3192 hop using the existing inbound or outbound node messaging association 3193 entry within the node's Message Routing State table. The MRM used 3194 for this message MUST be the same as MRM used by the corresponding 3195 CREATE or EXTERNAL message. 3197 5. Security Considerations 3199 Security is of major concern particularly in case of firewall 3200 traversal. This section provides security considerations for the 3201 NAT/firewall traversal and is organized as follows. 3203 In Section 5.1 we describe how the participating entities relate to 3204 each other from a security point of view. This subsection also 3205 motivates a particular authorization model. 3207 Security threats that focus on NSIS in general are described in 3208 [RFC4081] and they are applicable to this document as well. 3210 Finally, we illustrate how the security requirements that were 3211 created based on the security threats can be fulfilled by specific 3212 security mechanisms. These aspects will be elaborated in 3213 Section 5.2. 3215 5.1. Authorization Framework 3217 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 3218 and is, as such, not a two-party protocol. Figure 1 and Figure 2 of 3219 [RFC4081] already depict the possible set of communication patterns. 3220 In this section we will re-evaluate these communication patters with 3221 respect to the NATFW NSLP protocol interaction. 3223 The security solutions for providing authorization have a direct 3224 impact on the treatment of different NSLPs. As it can be seen from 3225 the QoS NSLP [I-D.ietf-nsis-qos-nslp] and the corresponding Diameter 3226 QoS work [I-D.ietf-dime-diameter-qos] accounting and charging seems 3227 to play an important role for QoS reservations, whereas monetary 3228 aspects might only indirectly effect authorization decisions for NAT 3229 and firewall signaling. Hence, there are differences in the semantic 3230 of authorization handling between QoS and NATFW signaling. A NATFW 3231 aware node will most likely want to authorize the entity (e.g., user 3232 or machine) requesting the establishment of pinholes or NAT bindings. 3233 The outcome of the authorization decision is either allowed or 3234 disallowed whereas a QoS authorization decision might indicate that a 3235 different set of QoS parameters is authorization (see 3236 [I-D.ietf-dime-diameter-qos] as an example). 3238 5.1.1. Peer-to-Peer Relationship 3240 Starting with the simplest scenario, it is assumed that neighboring 3241 nodes are able to authenticate each other and to establish keying 3242 material to protect the signaling message communication. The nodes 3243 will have to authorize each other, additionally to the 3244 authentication. We use the term 'Security Context' as a placeholder 3245 for referring to the entire security procedure, the necessary 3246 infrastructure that needs to be in place in order for this to work 3247 (e.g., key management) and the established security related state. 3248 The required long-term key (symmetric or asymmetric keys) used for 3249 authentication are either made available using an out-of-band 3250 mechanism between the two NSIS NATFW nodes or they are dynamically 3251 established using mechanisms not further specified in this document. 3252 Note that the deployment environment will most likely have an impact 3253 on the choice of credentials being used. The choice of these 3254 credentials used is also outside the scope of this document. 3256 +------------------------+ +-------------------------+ 3257 |Network A | | Network B| 3258 | +---------+ +---------+ | 3259 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3260 | | | box 1 | Security | box 2 | | | 3261 | | +---------+ Context +---------+ | | 3262 | | Security | | Security | | 3263 | | Context | | Context | | 3264 | | | | | | 3265 | +--+---+ | | +--+---+ | 3266 | | Host | | | | Host | | 3267 | | A | | | | B | | 3268 | +------+ | | +------+ | 3269 +------------------------+ +-------------------------+ 3271 Figure 31: Peer-to-Peer Relationship 3273 Figure 31 shows a possible relationship between participating NSIS 3274 aware nodes. Host A might be, for example, a host in an enterprise 3275 network that has keying material established (e.g., a shared secret) 3276 with the company's firewall (Middlebox 1). The network administrator 3277 of Network A (company network) has created access control lists for 3278 Host A (or whatever identifiers a particular company wants to use). 3279 Exactly the same procedure might also be used between Host B and 3280 Middlebox 2 in Network B. For the communication between Middlebox 1 3281 and Middlebox 2 a security context is also assumed in order to allow 3282 authentication, authorization and signaling message protection to be 3283 successful. 3285 5.1.2. Intra-Domain Relationship 3287 In larger corporations, for example, a middlebox is used to protect 3288 individual departments. In many cases, the entire enterprise is 3289 controlled by a single (or a small number of) security department, 3290 which gives instructions to the department administrators. In such a 3291 scenario, the previously discussed peer-to-peer relationship might be 3292 prevalent. Sometimes it might be necessary to preserve 3293 authentication and authorization information within the network. As 3294 a possible solution, a centralized approach could be used, whereby an 3295 interaction between the individual middleboxes and a central entity 3296 (for example a policy decision point - PDP) takes place. As an 3297 alternative, individual middleboxes exchange the authorization 3298 decision with another middlebox within the same trust domain. 3299 Individual middleboxes within an administrative domain may exploit 3300 their relationship instead of requesting authentication and 3301 authorization of the signaling initiator again and again. Figure 32 3302 illustrates a network structure which uses a centralized entity. 3304 +-----------------------------------------------------------+ 3305 | Network A | 3306 | +---------+ +---------+ 3307 | +----///--------+ Middle- +------///------++ Middle- +--- 3308 | | Security | box 2 | Security | box 2 | 3309 | | Context +----+----+ Context +----+----+ 3310 | +----+----+ | | | 3311 | | Middle- +--------+ +---------+ | | 3312 | | box 1 | | | | | 3313 | +----+----+ | | | | 3314 | | Security | +----+-----+ | | 3315 | | Context | | Policy | | | 3316 | +--+---+ +-----------+ Decision +----------+ | 3317 | | Host | | Point | | 3318 | | A | +----------+ | 3319 | +------+ | 3320 +-----------------------------------------------------------+ 3322 Figure 32: Intra-domain Relationship 3324 The interaction between individual middleboxes and a policy decision 3325 point (or AAA server) is outside the scope of this document. 3327 5.1.3. End-to-Middle Relationship 3329 The peer-to-peer relationship between neighboring NSIS NATFW NSLP 3330 nodes might not always be sufficient. Network B might require 3331 additional authorization of the signaling message initiator (in 3332 addition to the authorization of the neighboring node). If 3333 authentication and authorization information is not attached to the 3334 initial signaling message then the signaling message arriving at 3335 Middlebox 2 would result in an error message being created, which 3336 indicates the additional authorization requirement. In many cases 3337 the signaling message initiator might already be aware of the 3338 additionally required authorization before the signaling message 3339 exchange is executed. 3341 Figure 33 shows this scenario. 3343 +--------------------+ +---------------------+ 3344 | Network A | |Network B | 3345 | | Security | | 3346 | +---------+ Context +---------+ | 3347 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3348 | | | box 1 | +-------+ box 2 | | | 3349 | | +---------+ | +---------+ | | 3350 | |Security | | | Security | | 3351 | |Context | | | Context | 3352 | | | | | | | 3353 | +--+---+ | | | +--+---+ | 3354 | | Host +----///----+------+ | | Host | | 3355 | | A | | Security | | B | | 3356 | +------+ | Context | +------+ | 3357 +--------------------+ +---------------------+ 3359 Figure 33: End-to-Middle Relationship 3361 5.2. Security Framework for the NAT/Firewall NSLP 3363 The following list of security requirements has been created to 3364 ensure proper secure operation of the NATFW NSLP. 3366 5.2.1. Security Protection between neighboring NATFW NSLP Nodes 3368 Based on the analyzed threats it is RECOMMENDED to provide, between 3369 neighboring NATFW NSLP nodes, the following mechanism: 3371 o data origin authentication 3373 o replay protection 3375 o integrity protection and 3377 o optionally confidentiality protection 3379 It is RECOMMENDED to use the authentication and key exchange security 3380 mechanisms provided in [I-D.ietf-nsis-ntlp] between neighboring nodes 3381 when sending NATFW signaling messages. The proposed security 3382 mechanisms of GIST provide support for authentication and key 3383 exchange in addition to denial of service protection. Depending on 3384 the chosen security protocol, support for multiple authentication 3385 protocols might be provided. If security between neighboring nodes 3386 is desired than the usage of C-MODE for the delivery of data packets 3387 and the usage of D-MODE only to discover the next NATFW NSLP aware 3388 node along the path is highly RECOMMENDED. Almost all security 3389 threats at the NATFW NSLP layer can be prevented by using a mutually 3390 authenticated Transport Layer secured connection and by relying on 3391 authorization by the neighboring NATFW NSLP entities. 3393 The NATFW NSLP relies on an established security association between 3394 neighboring peers to prevent unauthorized nodes to modify or delete 3395 installed state. Between non-neighboring nodes the session ID (SID) 3396 carried in the NTLP is used to show ownership of a NATFW NSLP 3397 signaling session. The session ID MUST be generated in a random way 3398 and thereby prevent an off-path adversary to mount targeted attacks. 3399 Hence, an adversary would have to learn the randomly generated 3400 session ID to perform an attack. In a mobility environment a former 3401 on-path node that is now off-path can perform an attack. Messages 3402 for a particular NATFW NSLP signaling session are handled by the NTLP 3403 to the NATFW NSLP for further processing. Messages carrying a 3404 different session ID not associated with any NATFW NSLP are subject 3405 to the regular processing for new NATFW NSLP signaling sessions. 3407 5.2.2. Security Protection between non-neighboring NATFW NSLP Nodes 3409 Based on the security threats and the listed requirements it was 3410 noted that some threats also demand authentication and authorization 3411 of a NATFW signaling entity (including the initiator) towards a non- 3412 neighboring node. This mechanism mainly demands entity 3413 authentication. The most important information exchanged at the 3414 NATFW NSLP is information related to the establishment for firewall 3415 pinholes and NAT bindings. This information can, however, not be 3416 protected over multiple NSIS NATFW NSLP hops since this information 3417 might change depending on the capability of each individual NATFW 3418 NSLP node. 3420 Some scenarios might also benefit from the usage of authorization 3421 tokens. Their purpose is to associate two different signaling 3422 protocols (e.g., SIP and NSIS) and their authorization decision. 3423 These tokens are obtained by non-NSIS protocols, such as SIP or as 3424 part of network access authentication. When a NAT or firewall along 3425 the path receives the token it might be verified locally or passed to 3426 the AAA infrastructure. Examples of authorization tokens can be 3427 found in RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. Figure 34 shows 3428 an example of this protocol interaction. 3430 An authorization token is provided by the SIP proxy, which acts as 3431 the assertion generating entity and gets delivered to the end host 3432 with proper authentication and authorization. When the NATFW 3433 signaling message is transmitted towards the network, the 3434 authorization token is attached to the signaling messages to refer to 3435 the previous authorization decision. The assertion verifying entity 3436 needs to process the token or it might be necessary to interact with 3437 the assertion granting entity using HTTP (or other protocols). As a 3438 result of a successfully authorization by a NATFW NSLP node, the 3439 requested action is executed and later a RESPONSE message is 3440 generated. 3442 +----------------+ Trust Relationship +----------------+ 3443 | +------------+ |<.......................>| +------------+ | 3444 | | Protocol | | | | Assertion | | 3445 | | requesting | | HTTP, SIP Request | | Granting | | 3446 | | authz | |------------------------>| | Entity | | 3447 | | assertions | |<------------------------| +------------+ | 3448 | +------------+ | Artifact/Assertion | Entity Cecil | 3449 | ^ | +----------------+ 3450 | | | ^ ^| 3451 | | | . || HTTP, 3452 | | | Trust . || other 3453 | API Access | Relationship. || protocols 3454 | | | . || 3455 | | | . || 3456 | | | v |v 3457 | v | +----------------+ 3458 | +------------+ | | +------------+ | 3459 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3460 | | using authz| | Assertion/Artifact | | Verifying | | 3461 | | assertion | | ----------------------- | | Entity | | 3462 | +------------+ | | +------------+ | 3463 | Entity Alice | <---------------------- | Entity Bob | 3464 +----------------+ RESPONSE +----------------+ 3466 Figure 34: Authorization Token Usage 3468 Threats against the usage of authorization tokens have been mentioned 3469 in [RFC4081]. Hence, it is required to provide confidentiality 3470 protection to avoid allowing an eavesdropper to learn the token and 3471 to use it in another NATFW NSLP signaling session (replay attack). 3472 The token itself also needs to be protected against tempering. 3474 5.3. Implementation of NATFW NSLP Security 3476 The prior sections describe how to secure the NATFW NSLP in the 3477 presence of established trust between the various players and the 3478 particular relationships (e.g., intra-domain, end-to-middle, or peer- 3479 to-peer. However, in typical Internet deployments there is no 3480 established trust, other than granting access to a network, but not 3481 between various sites in the Internet. Furthermore, the NATFW NSLP 3482 may be incrementally deployed with a heavily varying ability of using 3483 authentication and authorization services. 3485 The NATFW NSLP offers a way to keep the authentication and 3486 authorization at the "edge" of the network. The local edge network 3487 can deploy and use any type of Authentication and Authorization (AA) 3488 scheme without the need to have AA technology match with other edges 3489 in the Internet (assuming that firewalls and NATs are deployed at the 3490 edges of the network and not somewhere in the cores). 3492 Each network edge that has the NATFW NSLP deployed can use the 3493 EXTERNAL request message to allow a secure access to the network. 3494 Using the EXTERNAL request message does allow the DR to open the 3495 firewall/NAT on the receiver's side. However, the edge-devices 3496 should not allow to be opened up completely (i.e., applying an allow- 3497 all policy), but to let DR's to reserve very specific policies. For 3498 instance, a DR can request to reserve an 'allow' policy rule for an 3499 incoming TCP connection for a Jabber file transfer. This reserved 3500 policy (see Figure 15) rule must be activated by matching the CREATE 3501 request message (see Figure 15). This mechanism allows that the 3502 authentication and authorization issues are kept locally at the 3503 particular edge-network. On the reverse, the CREATE request message 3504 can be handled independently on the the DS side with respect to 3505 authentication and authorization. 3507 The usage described in the above paragraph is even simplified for an 3508 incremental deployment: There is no requirement to activate a 3509 reserved policy rule with a CREATE request message. This is 3510 completely handled by the EXTERNAL-PROXY request message and the 3511 associated CREATE request message. Both of them are handled by the 3512 local authentication and authorization scheme. 3514 6. IAB Considerations on UNSAF 3516 UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a 3517 process at originating endpoints that attempt to determine or fix the 3518 address (and port) by which they are known to another endpoint. 3519 UNSAF proposals, such as STUN [RFC5389] are considered as a general 3520 class of workarounds for NAT traversal and as solutions for scenarios 3521 with no middlebox communication. 3523 This memo specifies a path-coupled middlebox communication protocol, 3524 i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are 3525 not intended as a short-term workaround, but more as a long-term 3526 solution for middlebox communication. In NSIS, endpoints are 3527 involved in allocating, maintaining, and deleting addresses and ports 3528 at the middlebox. However, the full control of addresses and ports 3529 at the middlebox is at the NATFW NSLP daemon located at the 3530 respective NAT. 3532 Therefore, this document addresses the UNSAF considerations in 3533 [RFC3424] by proposing a long-term alternative solution. 3535 7. IANA Considerations 3537 This section provides guidance to the Internet Assigned Numbers 3538 Authority (IANA) regarding registration of values related to the 3539 NATFW NSLP, in accordance with BCP 26 RFC 5226 [RFC5226]. 3541 The NATFW NSLP requires IANA to create a number of new registries: 3543 o NATFW NSLP Message Type Registry 3545 o NATFW NSLP Header Flag Registry 3547 o NSLP Response Code Registry 3549 It also requires registration of new values in a number of 3550 registries: 3552 o NSLP Object Types 3554 o GIST NSLP-ID 3556 o Router Alert Option Values (IPv4 and IPv6) 3558 7.1. NATFW NSLP Message Type Registry 3560 The NATFW NSLP Message Type is a 8 bit value. The allocation of 3561 values for new message types requires IETF Review. Updates and 3562 deletion of values from the registry is not possible. This 3563 specification defines four NATFW NSLP message types, which form the 3564 initial contents of this registry. IANA is requested to add these 3565 four NATFW NSLP Message Types: CREATE (0x1), EXTERNAL (0x2), RESPONSE 3566 (0x3), and NOTIFY (0x4). The registry entries consist of Name of 3567 Message Type, value, and reference to the relevant section. 3569 7.2. NATFW NSLP Header Flag Registry 3571 NATFW NSLP messages have a messages-specific 8 bit flags/reserved 3572 field in their header. The registration of flags is subject to IANA 3573 registration. The allocation of values for flag types requires IETF 3574 Review. Updates and deletion of values from the registry is not 3575 possible. This specification defines only two flags in Section 4.1, 3576 the E flag and the P flag. The registry entries consist of Name of 3577 the Flag and reference to the relevant section. 3579 7.3. NSLP Object Type Registry 3581 [ Delete the part in square brackets if registry is already created 3582 by another NSLP: 3584 A new registry is to be created for NSLP Message Objects. This is a 3585 12-bit field (giving values from 0 to 4095). This registry is shared 3586 between a number of NSLPs. Allocation policies are as follows: 3588 0-1023: IETF Review 3590 1024-1999: Specification Required 3592 2000-2047: Private/Experimental Use 3594 2048-4095: Reserved 3596 When a new object is defined, the extensibility bits (A/B) must also 3597 be defined. ] 3599 This document defines 9 objects for the NATFW NSLP: NATFW_LT, 3600 NATFW_EXTERNAL-IP, NATFW_EXTERNAL_BINDING, NATFW_EFI, NATFW_INFO, 3601 NATFW_NONCE, NATFW_MSN, NATFW_DTINFO, NATFW_ICMP_TYPES. IANA is 3602 request to assigned values for them from NSLP Object Type registry 3603 and to replace the corresponding IANA-TBD tags in this memo with the 3604 numeric values. 3606 7.4. NSLP Response Code Registry 3608 In addition it defines a number of Response Codes for the NATFW NSLP. 3609 These can be found in Section 4.2.5 and are to be assigned values 3610 from NSLP Response Code registry. The allocation of new values for 3611 Response Codes Codes requires IETF Review. IANA is request to 3612 assigned values for them from NSLP Response Code registry as given in 3613 Section 4.2.5for the severity class and also for the number of 3614 responses values per each severity class. The registry entries 3615 consist out of Name of class or response code, value, and reference 3616 to the relevant section. 3618 7.5. NSLP IDs and Router Alert Option Values 3620 GIST NSLPID 3622 This specification defines an NSLP for use with GIST and thus 3623 requires an assigned NSLP identifier. IANA is requested to add one 3624 new value to the NSLP Identifiers (NSLPID) registry defined in 3625 [I-D.ietf-nsis-ntlp] for the NATFW NSLP. 3627 IPv4 and IPv6 Router Alert Option (RAO) value 3629 The GIST specification also requires that each NSLP-ID be associated 3630 with specific Router Alert Option (RAO) value. For the purposes of 3631 the NATFW NSLP, just a single IPv4 RAO value and a single IPv6 RAO 3632 must be allocated. 3634 8. Acknowledgments 3636 We would like to thank the following individuals for their 3637 contributions to this document at different stages: 3639 o Marcus Brunner and Henning Schulzrinne for their work on IETF 3640 drafts which lead us to start with this document; 3642 o Miquel Martin for his large contribution on the initial version of 3643 this document and one of the first prototype implementations; 3645 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3646 NAT/firewall threats draft; 3648 o Henning Peters for his comments and suggestions; 3650 o Ben Campbell as Gen-ART reviewer; 3652 o and the NSIS working group. 3654 9. References 3656 9.1. Normative References 3658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3659 Requirement Levels", BCP 14, RFC 2119, March 1997. 3661 [I-D.ietf-nsis-ntlp] 3662 Schulzrinne, H. and M. Stiemerling, "GIST: General 3663 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 3664 (work in progress), June 2009. 3666 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 3667 August 1996. 3669 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3670 Requirements for Security", BCP 106, RFC 4086, June 2005. 3672 9.2. Informative References 3674 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3675 Bosch, "Next Steps in Signaling (NSIS): Framework", 3676 RFC 4080, June 2005. 3678 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 3679 RFC 3726, April 2004. 3681 [I-D.ietf-nsis-qos-nslp] 3682 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 3683 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 3684 (work in progress), January 2010. 3686 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 3687 A. Rayhan, "Middlebox communication architecture and 3688 framework", RFC 3303, August 2002. 3690 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 3691 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 3693 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3694 Translator (NAT) Terminology and Considerations", 3695 RFC 2663, August 1999. 3697 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 3698 Issues", RFC 3234, February 2002. 3700 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 3701 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 3702 Functional Specification", RFC 2205, September 1997. 3704 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 3705 Self-Address Fixing (UNSAF) Across Network Address 3706 Translation", RFC 3424, November 2002. 3708 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3709 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3710 May 2008. 3712 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3713 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3714 October 2008. 3716 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 3717 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 3718 J., and S. Waldbusser, "Terminology for Policy-Based 3719 Management", RFC 3198, November 2001. 3721 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 3722 "Session Authorization Policy Element", RFC 3520, 3723 April 2003. 3725 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 3726 Session Set-up with Media Authorization", RFC 3521, 3727 April 2003. 3729 [I-D.ietf-dime-diameter-qos] 3730 Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., 3731 and G. Zorn, "Diameter Quality of Service Application", 3732 draft-ietf-dime-diameter-qos-15 (work in progress), 3733 March 2010. 3735 [rsvp-firewall] 3736 Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, 3737 "RSVP as firewall Signalling Protocol", Proceedings of the 3738 6th IEEE Symposium on Computers and Communications, 3739 Hammamet, Tunisia pp. 57 to 62, IEEE Computer Society 3740 Press, July 2001. 3742 Appendix A. Selecting Signaling Destination Addresses for EXTERNAL 3744 As with all other message types, EXTERNAL messages need a reachable 3745 IP address of the data sender on the GIST level. For the path- 3746 coupled MRM the source-address of GIST is the reachable IP address 3747 (i.e., the real IP address of the data sender, or a wildcard). While 3748 this is straight forward, it is not necessarily so for the loose-end 3749 MRM. Many applications do not provide the IP address of the 3750 communication counterpart, i.e., either the data sender or both a 3751 data sender and receiver. For the EXTERNAL messages, the case of 3752 data sender is of interest only. The rest of this section gives 3753 informational guidance about determining a good destination-address 3754 of the LE-MRM in GIST for EXTERNAL messages. 3756 This signaling destination address (SDA, the destination-address in 3757 GIST) can be the data sender, but for applications which do not 3758 provide an address upfront, the destination address has to be chosen 3759 independently, as it is unknown at the time when the NATFW NSLP 3760 signaling has to start. Choosing the 'correct' destination IP 3761 address may be difficult and it is possible that there is no 'right 3762 answer' for all applications relying on the NATFW NSLP. 3764 Whenever possible it is RECOMMENDED to chose the data sender's IP 3765 address as SDA. It is necessary to differentiate between the 3766 received IP addresses on the data sender. Some application level 3767 signaling protocols (e.g., SIP) have the ability to transfer multiple 3768 contact IP addresses of the data sender. For instance, private IP 3769 address, public IP address at NAT, and public IP address at a relay. 3770 It is RECOMMENDED to use all non-private IP addresses as SDAs. 3772 A different SDA must be chosen, if the IP address of the data sender 3773 is unknown. This can have multiple reasons: The application level 3774 signaling protocol cannot determine any data sender IP address at 3775 this point of time or the data receiver is server behind a NAT, i.e., 3776 accepting inbound packets from any host. In this case, the NATFW 3777 NSLP can be instructed to use the public IP address of an application 3778 server or any other node. Choosing the SDA in this case is out of 3779 the scope of the NATFW NSLP and depends on the application's choice. 3780 The local network can provide a network-SDA, i.e., a SDA which is 3781 only meaningful to the local network. This will ensure that GIST 3782 packets with destination-address set to this network-SDA are going to 3783 be routed to a edge-NAT or edge-firewall. 3785 Appendix B. Usage of External Binding Addresses 3787 The NATFW_EXTERNAL_BINDING object carries information, that has a 3788 different utility the information carried within the 3789 NATFW_EXTERNAL-IP object. The NATFW_EXTERNAL-IP object has the 3790 public IP address and potentially port numbers that can be used by 3791 the application at the NI to be reachable via the public Internet. 3792 However, there are cases were various NIs are located behind the same 3793 public NAT, but are subject to a multi-level NAT deployment, as shown 3794 in Figure 35. They can use their public IP address port assigned to 3795 them to communicate between each other (e.g., NI with NR1 and NR2) 3796 but they are forced to send their traffic through the edge-NAT, even 3797 though there is a short way possible. 3799 NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP) 3800 | 3801 NR1--192.168.0/24-- NAT3-- 3802 | 3803 NR2 10.1.2.3 3805 Figure 35: Multi-Level NAT Scenario 3807 Figure 35 shows an example that is explored here: 3809 1. NI -> NR1: Both NI and NR1 does EXTERNAL towards NAT2 and get an 3810 external address+port binding. Then they exchange that external 3811 binding and all traffic gets pinned to NAT2 instead of taking 3812 shortes path by NAT1 to NAT3 directly. However to do that NR1 3813 and NI both needs to be aware that they also have the address on 3814 the external side of NAT1 and NAT3 respectively. If there is ICE 3815 deployed and there is actually a STUN server in the 10/8 network 3816 configured, it is possible to get the shorter path to work. The 3817 NATFW NSLP provides all external addresses in the 3818 NATFW_EXTERNAL_BINDING towards the public network it could allow 3819 for optimizations. 3821 2. For the case NI -> NR2 is even more obvious. Pinning this to 3822 NAT2 is an important fall back, but allowing for trying for a 3823 direct path between NAT1 and NAT3 might be worth it. 3825 Please note that if there are overlapping address domains between NR 3826 and the public Internet the regular routing will not necessary allow 3827 sending the packet to the right domain. 3829 Appendix C. Applicability Statement on Data Receivers behind Firewalls 3831 Section 3.7.2 describes how data receivers behind middleboxes can 3832 instruct inbound firewalls/NATs to forward NATFW NSLP signaling 3833 towards them. Finding an inbound edge-NAT in address environment 3834 with NAT'ed addresses is quite easy. It is only required to find 3835 some edge-NAT, as the data traffic will be route-pinned to the NAT. 3836 Locating the appropriate edge-firewall with the PC-MRM, sent inbound 3837 is difficult. For cases with a single, symmetric route from the 3838 Internet to the data receiver, it is quite easy; simply follow the 3839 default route in the inbound direction. 3841 +------+ Data Flow 3842 +-------| EFW1 +----------+ <=========== 3843 | +------+ ,--+--. 3844 +--+--+ / \ 3845 NI+-----| FW1 | (Internet )----NR+/NI/DS 3846 NR +--+--+ \ / 3847 | +------+ `--+--' 3848 +-------| EFW2 +----------+ 3849 +------+ 3851 ~~~~~~~~~~~~~~~~~~~~~> 3852 Signaling Flow 3854 Figure 36: Data receiver behind multiple, parallel located firewalls 3856 When a data receiver, and thus NR, is located in a network site that 3857 is multihomed with several independently firewalled connections to 3858 the public Internet (as shown in Figure 36), the specific firewall 3859 through which the data traffic will be routed has to be ascertained. 3860 NATFW NSLP signaling messages sent from the NI+/NR during the 3861 EXTERNAL message exchange towards the NR+ must be routed by the NTLP 3862 to the edge-firewall that will be passed by the data traffic as well. 3863 The NTLP would need to be aware about the routing within the Internet 3864 to determine the path between DS and DR. Out of this, the NTLP could 3865 determine which of the edge-firewalls, either EFW1 or EFW2, must be 3866 selected to forward the NATFW NSLP signaling. Signaling to the wrong 3867 edge-firewall, as shown in Figure 36, would install the NATFW NSLP 3868 policy rules at the wrong device. This causes either a blocked data 3869 flow (when the policy rule is 'allow') or an ongoing attack (when the 3870 policy rule is 'deny'). Requiring the NTLP to know all about the 3871 routing within the Internet is definitely a tough challenge and 3872 usually not possible. In such described case, the NTLP must 3873 basically give up and return an error to the NSLP level, indicating 3874 that the next hop discovery is not possible. 3876 Appendix D. Firewall and NAT Resources 3878 This section gives some examples on how NATFW NSLP policy rules could 3879 be mapped to real firewall or NAT resources. The firewall rules and 3880 NAT bindings are described in a natural way, i.e., in a way one will 3881 find it in common implementations. 3883 D.1. Wildcarding of Policy Rules 3885 The policy rule/MRI to be installed can be wildcarded to some degree. 3886 Wildcarding applies to IP address, transport layer port numbers, and 3887 the IP payload (or next header in IPv6). Processing of wildcarding 3888 splits into the NTLP and the NATFW NSLP layer. The processing at the 3889 NTLP layer is independent of the NSLP layer processing and per layer 3890 constraints apply. For wildcarding in the NTLP see Section 5.8 of 3891 [I-D.ietf-nsis-ntlp]. 3893 Wildcarding at the NATFW NSLP level is always a node local policy 3894 decision. A signaling message carrying a wildcarded MRI (and thus 3895 policy rule) arriving at an NSLP node can be rejected if the local 3896 policy does not allow the request. For instance, a MRI with IP 3897 addresses set (not wildcarded), transport protocol TCP, and TCP port 3898 numbers completely wildcarded. Now the local policy allows only 3899 requests for TCP with all ports set and not wildcarded. The request 3900 is going to be rejected. 3902 D.2. Mapping to Firewall Rules 3904 This section describes how a NSLP policy rule signaled with a CREATE 3905 message is mapped to a firewall rule. The MRI is set as follows: 3907 o network-layer-version=IPv4 3909 o source-address=192.0.2.100, prefix-length=32 3911 o destination-address=192.0.50.5, prefix-length=32 3913 o IP-protocol=UDP 3915 o L4-source-port=34543, L4-destination-port=23198 3917 The NATFW_EFI object is set to action=allow and sub_ports=0. 3919 The resulting policy rule (firewall rule) to be installed might look 3920 like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198 3922 D.3. Mapping to NAT Bindings 3924 This section describes how a NSLP policy rule signaled with a 3925 EXTERNAL message is mapped to a NAT binding. It is assumed that the 3926 EXTERNAL message is sent by a NI+ being located behind a NAT and does 3927 contain a NATFW_DTINFO object. The MRI is set following using the 3928 signaling destination address, since the IP address of the real data 3929 sender is not known: 3931 o network-layer-version=IPv4 3933 o source-address= 192.168.5.100 3935 o destination-address=SDA 3937 o IP-protocol=UDP 3939 The NATFW_EFI object is set to action=allow and sub_ports=0. The 3940 NATFW_DTINFO object contains these parameters: 3942 o P=1 3944 o dest prefix=0 3946 o protocol=UDP 3948 o dst port number = 20230, src port number=0 3950 o src IP=0.0.0.0 3952 The edge-NAT allocates the external IP 192.0.2.79 and port 45000. 3954 The resulting policy rule (NAT binding) to be installed could look 3955 like: translate udp from any to 192.0.2.79 port=45000 to 3956 192.168.5.100 port=20230 3958 D.4. NSLP Handling of Twice-NAT 3960 The dynamic configuration of twice-NATs requires application level 3961 support, as stated in Section 2.5. The NATFW NSLP cannot be used for 3962 configuring twice-NATs if application level support is needed. 3963 Assuming application level support performing the configuration of 3964 the twice-NAT and the NATFW NSLP being installed at this devices, the 3965 NATFW NSLP must be able to traverse it. The NSLP is probably able to 3966 traverse the twice-NAT, as any other data traffic, but the flow 3967 information stored in the NTLP's MRI will be invalidated through the 3968 translation of source and destination address. The NATFW NSLP 3969 implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP 3970 signaling messages as any other NATFW NSLP node does. For the given 3971 signaling flow, the NATFW NSLP node MUST look up the corresponding IP 3972 address translation and modify the NTLP/NSLP signaling accordingly. 3973 The modification results in an updated MRI with respect to the source 3974 and destination IP addresses. 3976 Appendix E. Example for Receiver Proxy Case 3978 This section gives an example on how to use the NATFW NLSP for 3979 receiver behind a NAT, where only the receiving side is NATFW NSLP 3980 enabled. We assume FTP as application to show a working example. A 3981 FTP server is located behind a NAT, as shown in Figure 5, and uses 3982 the NATFW NSLP to allocated NAT bindings for the control and data 3983 channel of the FTP protocol. The information where to reach the 3984 server is communicated by a separated protocol, e.g., email, chat, to 3985 the DS side. 3987 Public Internet Private Address 3988 Space 3989 FTP Client FTP Server 3991 DS NAT NI+ 3992 | | | 3993 | | EXTERNAL | 3994 | |<---------------------------|(1) 3995 | | | 3996 | |RESPONSE[Success] | 3997 | |--------------------------->|(2) 3998 | |CREATE | 3999 | |--------------------------->|(3) 4000 | |RESPONSE[Success] | 4001 | |<---------------------------|(4) 4002 | | | 4003 | | | 4004 |<=======================================================|(5) 4005 |FTP control port=XYZ | FTP control port=21 | 4006 |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(6) 4007 | | | 4008 | FTP control/get X | FTP control/get X | 4009 |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(7) 4010 | | EXTERNAL | 4011 | |<---------------------------|(8) 4012 | | | 4013 | |RESPONSE[Success] | 4014 | |--------------------------->|(9) 4015 | |CREATE | 4016 | |--------------------------->|(10) 4017 | |RESPONSE[Success] | 4018 | |<---------------------------|(11) 4019 | | | 4020 | Use port=FOO, IP=a.b.c.d | Use port=FOO, IP=a.b.c.d | 4021 |<~~~~~~~~~~~~~~~~~~~~~~~~~~|<~~~~~~~~~~~~~~~~~~~~~~~~~~~|(12) 4022 | | | 4023 |FTP data to port=FOO | FTP data to port=20 | 4024 |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(13) 4026 Figure 37: Flow Chart 4028 1. EXTERNAL request message sent to NAT, with these objects: 4029 signaling session lifetime, extended flow information object 4030 (rule action=allow, sub_ports=0), message sequence number 4031 object, nonce object (carrying nonce for CREATE), and the data 4032 terminal information object (I/P-flags set, sender prefix=0, 4033 protocol=TCP, DR port number = 21, DS' IP address=0); using the 4034 LE-MRM. This is used to allocated the external binding for the 4035 FTP control channel (TCP, port 21) 4037 2. successful RESPONSE sent to NI+, with these objects: signaling 4038 session lifetime, message sequence number object, information 4039 code object (success:0x1), external address object (port=XYZ, 4040 IPv4 addr=a.b.c.d) 4042 3. The NAT sends a CREATE towards NI+, with these objects:signaling 4043 session lifetime, extended flow information object (rule 4044 action=allow, sub_ports=0), message sequence number object, 4045 nonce object (with copied value from (1)); using the PC-MRM 4046 (src-IP=a.b.c.d, src-port=XYZ, dst-IP=NI+, dst-port=21, 4047 downstream) 4049 4. successful RESPONSE sent to NAT, with these objects: signaling 4050 session lifetime, message sequence number object, information 4051 code object (success:0x1) 4053 5. application at NI+ sends external NAT binding information to 4054 other end, i.e., the FTP client at the DS 4056 6. the FTP client connects the FTP control channel to port=XYZ, 4057 IP=a.b.c.d 4059 7. the FTP client sends a get command for file X 4061 8. EXTERNAL request message sent to NAT, with these objects: 4062 signaling session lifetime, extended flow information object 4063 (rule action=allow, sub_ports=0), message sequence number 4064 object, nonce object (carrying nonce for CREATE), and the data 4065 terminal information object (I/P-flags set, sender prefix=32, 4066 protocol=TCP, DR port number = 20, DS' IP address=DS-IP); using 4067 the LE-MRM. This is used to allocated the external binding for 4068 the FTP data channel (TCP, port 22) 4070 9. successful RESPONSE sent to NI+, with these objects: signaling 4071 session lifetime, message sequence number object, information 4072 code object (success:0x1), external address object (port=FOO, 4073 IPv4 addr=a.b.c.d) 4075 10. The NAT sends a CREATE towards NI+, with these objects:signaling 4076 session lifetime, extended flow information object (rule 4077 action=allow, sub_ports=0), message sequence number object, 4078 nonce object (with copied value from (1)); using the PC-MRM 4079 (src-IP=a.b.c.d, src-port=FOO, dst-IP=NI+, dst-port=20, 4080 downstream) 4082 11. successful RESPONSE sent to NAT, with these objects: signaling 4083 session lifetime, message sequence number object, information 4084 code object (success:0x1) 4086 12. the FTP server responses with port=FOO and IP=a.b.c.d 4088 13. the FTP clients connects the data channel to port=FOO and 4089 IP=a.b.c.d 4091 Authors' Addresses 4093 Martin Stiemerling 4094 NEC Europe Ltd. and University of Goettingen 4095 Kurfuersten-Anlage 36 4096 Heidelberg 69115 4097 Germany 4099 Phone: +49 (0) 6221 4342 113 4100 Email: Martin.Stiemerling@neclab.eu 4101 URI: http://www.stiemerling.org 4103 Hannes Tschofenig 4104 Nokia Siemens Networks 4105 Linnoitustie 6 4106 Espoo 02600 4107 Finland 4109 Phone: +358 (50) 4871445 4110 Email: Hannes.Tschofenig@nsn.com 4111 URI: http://www.tschofenig.com 4113 Cedric Aoun 4114 Paris 4115 France 4117 Email: cedric@caoun.net 4119 Elwyn Davies 4120 Folly Consulting 4121 Soham 4122 UK 4124 Phone: +44 7889 488 335 4125 Email: elwynd@dial.pipex.com