idnits 2.17.1 draft-ietf-nsis-nslp-natfw-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 3, 2010) is 5190 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-13 Summary: 2 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: Standards Track H. Tschofenig 5 Expires: August 7, 2010 Nokia Siemens Networks 6 C. Aoun 8 E. Davies 9 Folly Consulting 10 February 3, 2010 12 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 13 draft-ietf-nsis-nslp-natfw-21.txt 15 Abstract 17 This memo defines the NSIS Signaling Layer Protocol (NSLP) for 18 Network Address Translators (NATs) and firewalls. This NSLP allows 19 hosts to signal on the data path for NATs and firewalls to be 20 configured according to the needs of the application data flows. For 21 instance, it enables hosts behind NATs to obtain a public reachable 22 address and hosts behind firewalls to receive data traffic. The 23 overall architecture is given by the framework and requirements 24 defined by the Next Steps in Signaling (NSIS) working group. The 25 network scenarios, the protocol itself, and examples for path-coupled 26 signaling are given in this memo. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on August 7, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 5 82 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 8 83 1.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 84 1.4. General Scenario for NATFW Traversal . . . . . . . . . . . 11 86 2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 13 87 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13 88 2.2. NAT with two Private Networks . . . . . . . . . . . . . . 14 89 2.3. NAT with Private Network on Sender Side . . . . . . . . . 15 90 2.4. NAT with Private Network on Receiver Side Scenario . . . . 15 91 2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . . 16 92 2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 17 93 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18 94 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 19 96 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 20 97 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 20 98 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21 99 3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 21 100 3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 22 101 3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 23 102 3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 25 103 3.2.5. State and Error Maintenance . . . . . . . . . . . . . 25 104 3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 26 105 3.2.7. Classification of RESPONSE Messages . . . . . . . . . 26 106 3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 27 107 3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 28 108 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 28 109 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 31 110 3.6. Authentication, Authorization, and Policy Decisions . . . 32 111 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 33 112 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 33 113 3.7.2. Reserving External Addresses . . . . . . . . . . . . . 36 114 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 44 115 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 45 116 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 46 117 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 48 118 3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 53 119 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 54 120 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 55 122 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 56 123 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 56 124 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 57 125 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 58 126 4.2.2. External Address Object . . . . . . . . . . . . . . . 58 127 4.2.3. External Binding Address Object . . . . . . . . . . . 59 128 4.2.4. Extended Flow Information Object . . . . . . . . . . . 60 129 4.2.5. Information Code Object . . . . . . . . . . . . . . . 61 130 4.2.6. Nonce Object . . . . . . . . . . . . . . . . . . . . . 64 131 4.2.7. Message Sequence Number Object . . . . . . . . . . . . 64 132 4.2.8. Data Terminal Information Object . . . . . . . . . . . 65 133 4.2.9. ICMP Types Object . . . . . . . . . . . . . . . . . . 66 134 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 67 135 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 68 136 4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 68 137 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 69 138 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 69 140 5. Security Considerations . . . . . . . . . . . . . . . . . . . 71 141 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 71 142 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 71 143 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 72 144 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 73 145 5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 74 146 5.2.1. Security Protection between neighboring NATFW NSLP 147 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 74 148 5.2.2. Security Protection between non-neighboring NATFW 149 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 75 150 5.3. Implementation of NATFW NSLP Security . . . . . . . . . . 76 152 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 78 154 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 155 7.1. NATFW NSLP Message Type Registry . . . . . . . . . . . . . 79 156 7.2. NATFW NSLP Header Flag Registry . . . . . . . . . . . . . 79 157 7.3. NSLP Object Type Registry . . . . . . . . . . . . . . . . 79 158 7.4. NSLP Response Code Registry . . . . . . . . . . . . . . . 80 159 7.5. NSLP IDs and Router Alert Option Values . . . . . . . . . 80 161 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 163 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 164 9.1. Normative References . . . . . . . . . . . . . . . . . . . 83 165 9.2. Informative References . . . . . . . . . . . . . . . . . . 83 167 Appendix A. Selecting Signaling Destination Addresses for 168 EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 85 170 Appendix B. Usage of External Binding Addresses . . . . . . . . . 86 172 Appendix C. Applicability Statement on Data Receivers behind 173 Firewalls . . . . . . . . . . . . . . . . . . . . . . 87 175 Appendix D. Firewall and NAT Resources . . . . . . . . . . . . . 89 176 D.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 89 177 D.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 89 178 D.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 90 179 D.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 90 181 Appendix E. Protocols Numbers for Testing . . . . . . . . . . . . 92 183 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 185 1. Introduction 187 1.1. Scope and Background 189 Firewalls and Network Address Translators (NAT) have both been used 190 throughout the Internet for many years, and they will remain present 191 for the foreseeable future. Firewalls are used to protect networks 192 against certain types of attacks from internal networks and the 193 Internet, whereas NATs provide a virtual extension of the IP address 194 space. Both types of devices may be obstacles to some applications, 195 since they only allow traffic created by a limited set of 196 applications to traverse them, typically those that use protocols 197 with relatively predetermined and static properties (e.g., most HTTP 198 traffic, and other client/server applications). Other applications, 199 such as IP telephony and most other peer-to-peer applications, which 200 have more dynamic properties, create traffic that is unable to 201 traverse NATs and firewalls unassisted. In practice, the traffic of 202 many applications cannot traverse autonomous firewalls or NATs, even 203 when they have additional functionality which attempts to restore the 204 transparency of the network. 206 Several solutions to enable applications to traverse such entities 207 have been proposed and are currently in use. Typically, application 208 level gateways (ALG) have been integrated with the firewall or NAT to 209 configure the firewall or NAT dynamically. Another approach is 210 middlebox communication (MIDCOM). In this approach, ALGs external to 211 the firewall or NAT configure the corresponding entity via the MIDCOM 212 protocol [RFC3303]. Several other work-around solutions are 213 available, such as STUN [RFC5389]. However, all of these approaches 214 introduce other problems that are generally hard to solve, such as 215 dependencies on the type of NAT implementation (full-cone, symmetric, 216 etc), or dependencies on certain network topologies. 218 NAT and firewall (NATFW) signaling shares a property with Quality of 219 Service (QoS) signaling. The signaling of both must reach any device 220 on the data path that is involved in, respectively, NATFW or QoS 221 treatment of data packets. This means, that for both, NATFW and QoS, 222 it is convenient if signaling travels path-coupled, meaning that the 223 signaling messages follow exactly the same path that the data packets 224 take. RSVP [RFC2205] is an example of a current QoS signaling 225 protocol that is path-coupled. [rsvp-firewall] proposes the use of 226 RSVP as firewall signaling protocol but does not include NATs. 228 This memo defines a path-coupled signaling protocol for NAT and 229 firewall configuration within the framework of NSIS, called the NATFW 230 NSIS Signaling Layer Protocol (NSLP). The general requirements for 231 NSIS are defined in [RFC3726] and the general framework of NSIS is 232 outlined in [RFC4080]. It introduces the split between an NSIS 233 transport layer and an NSIS signaling layer. The transport of NSLP 234 messages is handled by an NSIS Network Transport Layer Protocol 235 (NTLP, with General Internet Signaling Transport (GIST) 236 [I-D.ietf-nsis-ntlp] being the implementation of the abstract NTLP). 237 The signaling logic for QoS and NATFW signaling is implemented in the 238 different NSLPs. The QoS NSLP is defined in 239 [I-D.ietf-nsis-qos-nslp]. 241 The NATFW NSLP is designed to request the dynamic configuration of 242 NATs and/or firewalls along the data path. Dynamic configuration 243 includes enabling data flows to traverse these devices without being 244 obstructed, as well as blocking of particular data flows at inbound 245 firewalls. Enabling data flows requires the loading of firewall 246 rules with an action that allows the data flow packets to be 247 forwarded and creating NAT bindings. Blocking of data flows requires 248 the loading of firewalls rules with an action that will deny 249 forwarding of the data flow packets. A simplified example for 250 enabling data flows: A source host sends a NATFW NSLP signaling 251 message towards its data destination. This message follows the data 252 path. Every NATFW NSLP-enabled NAT/firewall along the data path 253 intercepts this message, processes them, and configures itself 254 accordingly. Thereafter, the actual data flow can traverse all these 255 configured firewalls/NATs. 257 It is necessary to distinguish between two different basic scenarios 258 when operating the NATFW NSLP, independent of the type of the 259 middleboxes to be configured. 261 1. Both, data sender and data receiver, are NSIS NATFW NSLP aware. 262 This includes the cases where the data sender is logically 263 decomposed from the initiator of the NSIS signaling (the so- 264 called NSIS initiator) or the data receiver logically decomposed 265 from the receiver of the NSIS signaling (the so-called NSIS 266 receiver), but both sides support NSIS. This scenario assumes 267 deployment of NSIS all over the Internet, or at least at all NATs 268 and firewalls. This scenario is used as base assumption, if not 269 otherwise noted. 271 2. Only one end host or region of the network is NSIS NATFW NSLP 272 aware, either data receiver or data sender. This scenario is 273 referred to as proxy mode. 275 The NATFW NSLP has two basic signaling messages which are sufficient 276 to cope with the various possible scenarios likely to be encountered 277 before and after widespread deployment of NSIS: 279 CREATE message: Sent by the data sender for configuring a path 280 outbound from a data sender to a data receiver. 282 EXTERNAL message: Used by data receiver to locate inbound NATs/ 283 firewalls and prime them to expect inbound signaling and at NATs 284 to pre-allocate a public address. This is used for data receivers 285 behind these devices to enable their reachability. 287 CREATE and EXTERNAL messages are sent by the NSIS initiator (NI) 288 towards the NSIS responder (NR). Both type of messages are 289 acknowledged by a subsequent RESPONSE message. This RESPONSE message 290 is generated by the NR if the requested configuration can be 291 established, otherwise the NR or any of the NSIS forwarders (NFs) can 292 also generate such a message if an error occurs. NFs and the NR can 293 also generate asynchronous messages to notify the NI, the so called 294 NOTIFY messages. 296 If the data receiver resides in a private addressing realm or behind 297 a firewall, and needs to preconfigure the edge-NAT/edge-firewall to 298 provide a (publicly) reachable address for use by the data sender, a 299 combination of EXTERNAL and CREATE messages is used. 301 During the introduction of NSIS, it is likely that one or the other 302 of the data sender and receiver will not be NSIS aware. In these 303 cases, the NATFW NSLP can utilize NSIS aware middleboxes on the path 304 between the data sender and data receiver to provide proxy NATFW NSLP 305 services (i.e., the proxy mode). Typically, these boxes will be at 306 the boundaries of the realms in which the end hosts are located. 308 The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in 309 NSIS entities. NTLP state allows signaling messages to travel in the 310 forward (outbound) and the reverse (inbound) direction along the path 311 between a NAT/firewall NSLP sender and a corresponding receiver. 312 This state is managed using a soft-state mechanism, i.e., it expires 313 unless it is refreshed from time to time. The NAT bindings and 314 firewall rules being installed during the state setup are bound to 315 the particular signaling session. However, the exact local 316 implementation of the NAT bindings and firewall rules are NAT/ 317 firewall specific and it is out of scope of this memo. 319 This memo is structured as follows. Section 2 describes the network 320 environment for NATFW NSLP signaling. Section 3 defines the NATFW 321 signaling protocol and Section 4 defines the message components and 322 the overall messages used in the protocol. The remaining parts of 323 the main body of the document cover security considerations 324 Section 5, IAB considerations on UNilateral Self-Address Fixing 325 (UNSAF) [RFC3424] in Section 6 and IANA considerations in Section 7. 326 Please note that readers familiar with firewalls and NATs and their 327 possible location within networks can safely skip Section 2. 329 1.2. Terminology and Abbreviations 331 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 332 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 333 document are to be interpreted as described in [RFC2119]. 335 This document uses a number of terms defined in [RFC3726] and 336 [RFC4080]. The following additional terms are used: 338 o Policy rule: A policy rule is "a basic building block of a policy- 339 based system. It is the binding of a set of actions to a set of 340 conditions - where the conditions are evaluated to determine 341 whether the actions are performed" [RFC3198]. In the context of 342 NSIS NATFW NSLP, the conditions are the specification of a set of 343 packets to which the rule is applied. The set of actions always 344 contains just a single element per rule, and is limited to either 345 action "deny" or action "allow". 347 o Reserved policy rule: A policy rule stored at NATs or firewalls 348 for activation by a later, different signaling exchange. This 349 type of policy rule is kept in the NATFW NSLP and is not loaded 350 into the firewall or NAT engine, i.e., it does not affect the data 351 flow handling. 353 o Installed policy rule: A policy rule in operation at NATs or 354 firewalls. This type of rule is kept in the NATFW NSLP and is 355 loaded into the firewall or NAT engine, i.e., it is affecting the 356 data flow. 358 o Remembered policy rule: A policy rule stored at NATs and firewalls 359 for immediate use, as soon as the signaling exchange is 360 successfully completed. 362 o Firewall: A packet filtering device that matches packets against a 363 set of policy rules and applies the actions. 365 o Network Address Translator: Network Address Translation is a 366 method by which IP addresses are mapped from one IP address realm 367 to another, in an attempt to provide transparent routing between 368 hosts (see [RFC2663]). Network Address Translators are devices 369 that perform this work by modifying packets passing through them. 371 o Data Receiver (DR): The node in the network that is receiving the 372 data packets of a flow. 374 o Data Sender (DS): The node in the network that is sending the data 375 packets of a flow. 377 o NATFW NSLP peer or peer: An NSIS NATFW NSLP node with which an 378 NTLP adjacency has been created as defined in 379 [I-D.ietf-nsis-ntlp]. 381 o NATFW NSLP signaling session or signaling session: A signaling 382 session defines an association between the NI, NFs, and the NR 383 related to a data flow. All the NATFW NSLP peers on the path, 384 including the NI and the NR, use the same identifier to refer to 385 the state stored for the association. The same NI and NR may have 386 more than one signaling session active at any time. The state for 387 NATFW NSLP consists of NSLP state and associated policy rules at a 388 middlebox. 390 o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP 391 address which is reachable from the public Internet. 393 o Edge-firewall: An edge-firewall is a firewall device that is 394 located on the border line of an administrative domain. 396 o Public Network: "A Global or Public Network is an address realm 397 with unique network addresses assigned by Internet Assigned 398 Numbers Authority (IANA) or an equivalent address registry. This 399 network is also referred as external network during NAT 400 discussions" [RFC2663]. 402 o Private/Local Network: "A private network is an address realm 403 independent of external network addresses. Private network may 404 also be referred alternately as Local Network. Transparent 405 routing between hosts in private realm and external realm is 406 facilitated by a NAT router" [RFC2663]. 408 o Public/Global IP address: An IP address located in the public 409 network according to Section 2.7 of [RFC2663]. 411 o Private/Local IP address: An IP address located in the private 412 network according to Section 2.8 of [RFC2663]. 414 o Signaling Destination Address (SDA): An IP address generally taken 415 from the public/global IP address range, although, the SDA may in 416 certain circumstances be part of the private/local IP address 417 range. This address is used in EXTERNAL signaling message 418 exchanges, if the data receiver's IP address is unknown. 420 1.3. Middleboxes 422 The term middlebox covers a range of devices and is well-defined in 423 [RFC3234]: "A middlebox is defined as any intermediate device 424 performing functions other than the normal, standard functions of an 425 IP router on the datagram path between source host and a destination 426 host". As such, middleboxes fall into a number of categories with a 427 wide range of functionality, not all of which is pertinent to the 428 NATFW NSLP. Middlebox categories in the scope of this memo are 429 firewalls that filter data packets against a set of filter rules, and 430 NATs that translate packet addresses from one address realm to 431 another address realm. Other categories of middleboxes, such as QoS 432 traffic shapers, are out of scope of this memo. 434 The term NAT used in this document is a placeholder for a range of 435 different NAT flavors. We consider the following types of NATs: 437 o Traditional NAT (basic NAT and NAPT) 439 o Bi-directional NAT 441 o Twice-NAT 443 o Multihomed NAT 445 For definitions and a detailed discussion about the characteristics 446 of each NAT type please see [RFC2663]. 448 All types of middleboxes under consideration here, use policy rules 449 to make a decision on data packet treatment. Policy rules consist of 450 a flow identifier which selects the packets to which the policy 451 applies and an associated action; data packets matching the flow 452 identifier are subjected to the policy rule action. A typical flow 453 identifier is the 5-tuple selector which matches the following fields 454 of a packet to configured values: 456 o Source and destination IP addresses 458 o Transport protocol number 460 o Transport source and destination port numbers 462 Actions for firewalls are usually one or more of: 464 o Allow: forward data packet 466 o Deny: block data packet and discard it 468 o Other actions such as logging, diverting, duplicating, etc 470 Actions for NATs include (amongst many others): 472 o Change source IP address and transport port number to a globally 473 routable IP address and associated port number. 475 o Change destination IP address and transport port number to a 476 private IP address and associated port number. 478 It should be noted that a middlebox may contain two logical 479 representations of the policy rule. The policy rule has a 480 representation within the NATFW NSLP, comprising the message routing 481 information (MRI) of the NTLP and NSLP information (such as the rule 482 action). The other representation is the implementation of the NATFW 483 NSLP policy rule within the NAT and firewall engine of the particular 484 device. Refer to Appendix D for further details. 486 1.4. General Scenario for NATFW Traversal 488 The purpose of NSIS NATFW signaling is to enable communication 489 between endpoints across networks, even in the presence of NAT and 490 firewall middleboxes that have not been specially engineered to 491 facilitate communication with the application protocols used. This 492 removes the need to create and maintain application layer gateways 493 for specific protocols that have been commonly used to provide 494 transparency in previous generations of NAT and firewall middleboxes. 495 It is assumed that these middleboxes will be statically configured in 496 such a way that NSIS NATFW signaling messages themselves are allowed 497 to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP 498 signaling is used to dynamically install additional policy rules in 499 all NATFW middleboxes along the data path that will allow 500 transmission of the application data flow(s). Firewalls are 501 configured to forward data packets matching the policy rule provided 502 by the NSLP signaling. NATs are configured to translate data packets 503 matching the policy rule provided by the NSLP signaling. An 504 additional capability, that is an exception to the primary goal of 505 NSIS NATFW signaling, is that the NATFW nodes can request blocking of 506 particular data flows instead of enabling these flows at inbound 507 firewalls. 509 The basic high-level picture of NSIS usage is that end hosts are 510 located behind middleboxes, meaning that there is at least one 511 middlebox on the data path from the end host in a private network to 512 the external network (NATFW in Figure 1). Applications located at 513 these end hosts try to establish communication with corresponding 514 applications on other such end hosts. They trigger the NSIS entity 515 at the local host to control provisioning for middlebox traversal 516 along the prospective data path (e.g., via an API call). The NSIS 517 entity in turn uses NSIS NATFW NSLP signaling to establish policy 518 rules along the data path, allowing the data to travel from the 519 sender to the receiver unobstructed. 521 Application Application Server (0, 1, or more) Application 523 +----+ +----+ +----+ 524 | +------------------------+ +------------------------+ | 525 +-+--+ +----+ +-+--+ 526 | | 527 | NSIS Entities NSIS Entities | 528 +-+--+ +----+ +-----+ +-+--+ 529 | +--------+ +----------------------------+ +-----+ | 530 +-+--+ +-+--+ +--+--+ +-+--+ 531 | | ------ | | 532 | | //// \\\\\ | | 533 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 534 | | | | | Internet | | | | | 535 | +--------+ +-----+ +----+ +-----+ | 536 +----+ +----+ |\ | +----+ +----+ 537 \\\\ ///// 538 sender NATFW (1+) ------ NATFW (1+) receiver 540 Note that 1+ refers to one or more NATFW nodes. 542 Figure 1: Generic View of NSIS with NATs and/or firewalls 544 For end-to-end NATFW signaling, it is necessary that each firewall 545 and each NAT along the path between the data sender and the data 546 receiver implements the NSIS NATFW NSLP. There might be several NATs 547 and FWs in various possible combinations on a path between two hosts. 548 Section 2 presents a number of likely scenarios with different 549 combinations of NATs and firewalls. However, the scenarios given in 550 the following sections are not limiting the scope of the NATFW NSLP 551 to them only, but they are examples only. 553 2. Network Deployment Scenarios using the NATFW NSLP 555 This section introduces several scenarios for middlebox placement 556 within IP networks. Middleboxes are typically found at various 557 different locations, including at enterprise network borders, within 558 enterprise networks, as mobile phone network gateways, etc. Usually, 559 middleboxes are placed more towards the edge of networks than in 560 network cores. Firewalls and NATs may be found at these locations 561 either alone, or they may be combined; other categories of 562 middleboxes may also be found at such locations, possibly combined 563 with the NATs and/or firewalls. 565 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 566 regular data path to the NSIS responder (NR). On the data path, 567 NATFW NSLP signaling messages reach different NSIS nodes that 568 implement the NATFW NSLP. Each NATFW NSLP node processes the 569 signaling messages according to Section 3 and, if necessary, installs 570 policy rules for subsequent data packets. 572 Each of the following sub-sections introduces a different scenario 573 for a different set of middleboxes and their ordering within the 574 topology. It is assumed that each middlebox implements the NSIS 575 NATFW NSLP signaling protocol. 577 2.1. Firewall Traversal 579 This section describes a scenario with firewalls only; NATs are not 580 involved. Each end host is behind a firewall. The firewalls are 581 connected via the public Internet. Figure 2 shows the topology. The 582 part labeled "public" is the Internet connecting both firewalls. 584 +----+ //----\\ +----+ 585 NI -----| FW |---| |------| FW |--- NR 586 +----+ \\----// +----+ 588 private public private 590 FW: Firewall 591 NI: NSIS Initiator 592 NR: NSIS Responder 594 Figure 2: Firewall Traversal Scenario 596 Each firewall on the data path must provide traversal service for 597 NATFW NSLP in order to permit the NSIS message to reach the other end 598 host. All firewalls process NSIS signaling and establish appropriate 599 policy rules, so that the required data packet flow can traverse 600 them. 602 There are several very different ways to place firewalls in a network 603 topology. To distinguish firewalls located at network borders, such 604 as administrative domains, from others located internally, the term 605 edge-firewall is used. A similar distinction can be made for NATs, 606 with an edge-NAT fulfilling the equivalent role. 608 2.2. NAT with two Private Networks 610 Figure 3 shows a scenario with NATs at both ends of the network. 611 Therefore, each application instance, the NSIS initiator and the NSIS 612 responder, are behind NATs. The outermost NAT, known as the edge-NAT 613 (MB2 and MB3), at each side is connected to the public Internet. The 614 NATs are generically labeled as MBX (for middlebox No. X), since 615 those devices certainly implement NAT functionality, but can 616 implement firewall functionality as well. 618 Only two middleboxes MB are shown in Figure 3 at each side, but in 619 general, any number of MBs on each side must be considered. 621 +----+ +----+ //----\\ +----+ +----+ 622 NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR 623 +----+ +----+ \\----// +----+ +----+ 625 private public private 627 MB: Middlebox 628 NI: NSIS Initiator 629 NR: NSIS Responder 631 Figure 3: NAT with two Private Networks Scenario 633 Signaling traffic from NI to NR has to traverse all the middleboxes 634 on the path (MB1 to MB4, in this order), and all the middleboxes must 635 be configured properly to allow NSIS signaling to traverse them. The 636 NATFW signaling must configure all middleboxes and consider any 637 address translation that will result from this configuration in 638 further signaling. The sender (NI) has to know the IP address of the 639 receiver (NR) in advance, otherwise it will not be possible to send 640 any NSIS signaling messages towards the responder. Note that this IP 641 address is not the private IP address of the responder but the NAT's 642 public IP address (here MB3's IP address). Instead a NAT binding 643 (including a public IP address) has to be previously installed on the 644 NAT MB3. This NAT binding subsequently allows packets reaching the 645 NAT to be forwarded to the receiver within the private address realm. 647 The receiver might have a number of ways to learn its public IP 648 address and port number (including the NATFW NSLP) and might need to 649 signal this information to the sender using an application level 650 signaling protocol. 652 2.3. NAT with Private Network on Sender Side 654 This scenario shows an application instance at the sending node that 655 is behind one or more NATs (shown as generic MB, see discussion in 656 Section 2.2). The receiver is located in the public Internet. 658 +----+ +----+ //----\\ 659 NI --| MB |-----| MB |---| |--- NR 660 +----+ +----+ \\----// 662 private public 664 MB: Middlebox 665 NI: NSIS Initiator 666 NR: NSIS Responder 668 Figure 4: NAT with Private Network on Sender Side 670 The traffic from NI to NR has to traverse middleboxes only on the 671 sender's side. The receiver has a public IP address. The NI sends 672 its signaling message directly to the address of the NSIS responder. 673 Middleboxes along the path intercept the signaling messages and 674 configure accordingly. 676 The data sender does not necessarily know whether the receiver is 677 behind a NAT or not, hence, it is the receiving side that has to 678 detect whether itself is behind a NAT or not. 680 2.4. NAT with Private Network on Receiver Side Scenario 682 The application instance receiving data is behind one or more NATs 683 shown as MB (see discussion in Section 2.2). 685 //----\\ +----+ +----+ 686 NI ---| |---| MB |-----| MB |--- NR 687 \\----// +----+ +----+ 689 public private 691 MB: Middlebox 692 NI: NSIS Initiator 693 NR: NSIS Responder 695 Figure 5: NAT with Private Network on Receiver Scenario 697 Initially, the NSIS responder must determine its publicly reachable 698 IP address at the external middlebox and notify the NSIS initiator 699 about this address. One possibility is that an application level 700 protocol is used, meaning that the public IP address is signaled via 701 this protocol to the NI. Afterwards the NI can start its signaling 702 towards the NR and therefore establish the path via the middleboxes 703 in the receiver side private network. 705 This scenario describes the use case for the EXTERNAL message of the 706 NATFW NSLP. 708 2.5. Both End Hosts behind twice-NATs 710 This is a special case, where the main problem arises from the need 711 to detect that both end hosts are logically within the same address 712 space, but are also in two partitions of the address realm on either 713 side of a twice-NAT (see [RFC2663] for a discussion of twice-NAT 714 functionality). 716 Sender and receiver are both within a single private address realm 717 but the two partitions potentially have overlapping IP address 718 ranges. Figure 6 shows the arrangement of NATs. 720 public 722 +----+ +----+ //----\\ 723 NI --| MB |--+--| MB |---| | 724 +----+ | +----+ \\----// 725 | 726 | +----+ 727 +--| MB |------------ NR 728 +----+ 730 private 732 MB: Middlebox 733 NI: NSIS Initiator 734 NR: NSIS Responder 736 Figure 6: NAT to Public, Sender and Receiver on either side of a 737 twice-NAT Scenario 739 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 740 addresses and port numbers on both sides, meaning the mapping of 741 source and destination address at the private and public interfaces. 743 This scenario requires the assistance of application level entities, 744 such as a DNS server. The application level entities must handle 745 requests that are based on symbolic names, and configure the 746 middleboxes so that data packets are correctly forwarded from NI to 747 NR. The configuration of those middleboxes may require other 748 middlebox communication protocols, such as MIDCOM [RFC3303]. NSIS 749 signaling is not required in the twice-NAT only case, since 750 middleboxes of the twice-NAT type are normally configured by other 751 means. Nevertheless, NSIS signaling might be useful when there are 752 also firewalls on the path. In this case NSIS will not configure any 753 policy rule at twice-NATs, but will configure policy rules at the 754 firewalls on the path. The NSIS signaling protocol must be at least 755 robust enough to survive this scenario. This requires that twice- 756 NATs must implement the NATFW NSLP also and participate in NATFW 757 signaling sessions but they do not change the configuration of the 758 NAT, i.e., they only read the address mapping information out of the 759 NAT and translate the Message Routing Information (MRI, 760 [I-D.ietf-nsis-ntlp]) within the NSLP and NTLP accordingly. For more 761 information see Appendix D.4 763 2.6. Both End Hosts Behind Same NAT 765 When NSIS initiator and NSIS responder are behind the same NAT (thus 766 being in the same address realm, see Figure 7), they are most likely 767 not aware of this fact. As in Section 2.4 the NSIS responder must 768 determine its public IP address in advance and transfer it to the 769 NSIS initiator. Afterwards, the NSIS initiator can start sending the 770 signaling messages to the responder's public IP address. During this 771 process, a public IP address will be allocated for the NSIS initiator 772 at the same middlebox as for the responder. Now, the NSIS signaling 773 and the subsequent data packets will traverse the NAT twice: from 774 initiator to public IP address of responder (first time) and from 775 public IP address of responder to responder (second time). 777 NI public 778 \ +----+ //----\\ 779 +-| MB |----| | 780 / +----+ \\----// 781 NR 782 private 784 MB: Middlebox 785 NI: NSIS Initiator 786 NR: NSIS Responder 788 Figure 7: NAT to Public, Both Hosts Behind Same NAT 790 2.7. Multihomed Network with NAT 792 The previous sub-sections sketched network topologies where several 793 NATs and/or firewalls are ordered sequentially on the path. This 794 section describes a multihomed scenario with two NATs placed on 795 alternative paths to the public network. 797 +----+ //---\\ 798 NI -------| MB |---| | 799 \ +----+ \\-+-// 800 \ | 801 \ +----- NR 802 \ | 803 \ +----+ //-+-\\ 804 --| MB |---| | 805 +----+ \\---// 807 private public 809 MB: Middlebox 810 NI: NSIS Initiator 811 NR: NSIS Responder 813 Figure 8: Multihomed Network with Two NATs 815 Depending on the destination, either one or the other middlebox is 816 used for the data flow. Which middlebox is used, depends on local 817 policy or routing decisions. NATFW NSLP must be able to handle this 818 situation properly, see Section 3.7.2 for an extended discussion of 819 this topic with respect to NATs. 821 2.8. Multihomed Network with Firewall 823 This section describes a multihomed scenario with two firewalls 824 placed on alternative paths to the public network (Figure 9). The 825 routing in the private and public network decides which firewall is 826 being taken for data flows. Depending on the data flow's direction, 827 either outbound or inbound, a different firewall could be traversed. 828 This is a challenge for the EXTERNAL message of the NATFW NSLP where 829 the NSIS responder is located behind these firewalls within the 830 private network. The EXTERNAL message is used to block a particular 831 data flow on an inbound firewall. NSIS must route the EXTERNAL 832 message inbound from NR to NI probably without knowing which path the 833 data traffic will take from NI to NR (see also Appendix C). 835 +----+ 836 NR -------| FW |\ 837 \ +----+ \ //---\\ 838 \ -| |-- NI 839 \ \\---// 840 \ +----+ | 841 --| FW |-------+ 842 +----+ 843 private 845 private public 847 FW: Firewall 848 NI: NSIS Initiator 849 NR: NSIS Responder 851 Figure 9: Multihomed Network with two firewalls 853 3. Protocol Description 855 This section defines messages, objects, and protocol semantics for 856 the NATFW NSLP. 858 3.1. Policy Rules 860 Policy rules, bound to a NATFW NSLP signaling session, are the 861 building blocks of middlebox devices considered in the NATFW NSLP. 862 For firewalls the policy rule usually consists of a 5-tuple and an 863 action such as allow or deny. The information contained in the tuple 864 includes source/destination addresses, transport protocol and source/ 865 destination port numbers. For NATs the policy rule consists of the 866 action 'translate this address' and further mapping information, that 867 might be, in the simplest case, internal IP address and external IP 868 address. 870 The NATFW NSLP carries, in conjunction with the NTLP's Message 871 Routing Information (MRI), the policy rules to be installed at NATFW 872 peers. This policy rule is an abstraction with respect to the real 873 policy rule to be installed at the respective firewall or NAT. It 874 conveys the initiator's request and must be mapped to the possible 875 configuration on the particular used NAT and/or firewall in use. For 876 pure firewalls one or more filter rules must be created and for pure 877 NATs one or more NAT bindings must be created. In mixed firewall and 878 NAT boxes, the policy rule must be mapped to filter rules and 879 bindings observing the ordering of the firewall and NAT engine. 880 Depending on the ordering, NAT before firewall or vice versa, the 881 firewall rules must carry public or private IP addresses. However, 882 the exact mapping depends on the implementation of the firewall or 883 NAT which is possibly different for each implementation. 885 The policy rule at the NATFW NSLP level comprises the message routing 886 information (MRI) part, carried in the NTLP, and the information 887 available in the NATFW NSLP. The information provided by the NSLP is 888 stored in the 'extend flow information' (NATFW_EFI) and 'data 889 terminal information' (NATFW_DTINFO) objects, and the message type. 890 Additional information, such as the external IP address and port 891 number, stored in the NAT or firewall, will be used as well. The MRI 892 carries the filter part of the NAT/firewall-level policy rule that is 893 to be installed. 895 The NATFW NSLP specifies two actions for the policy rules: deny and 896 allow. A policy rule with action set to deny will result in all 897 packets matching this rule to be dropped. A policy rule with action 898 set to allow will result in all packets matching this rule to be 899 forwarded. 901 3.2. Basic Protocol Overview 903 The NSIS NATFW NSLP is carried over the General Internet Signaling 904 Transport (GIST, the implementation of the NTLP) defined in 905 [I-D.ietf-nsis-ntlp]. NATFW NSLP messages are initiated by the NSIS 906 initiator (NI), handled by NSIS forwarders (NF) and received by the 907 NSIS responder (NR). It is required that at least NI and NR 908 implement this NSLP, intermediate NFs only implement this NSLP when 909 they provide relevant middlebox functions. NSIS forwarders that do 910 not have any NATFW NSLP functions just forward these packets as they 911 have no interest in them. 913 3.2.1. Signaling for Outbound Traffic 915 A Data Sender (DS), intending to send data to a Data Receiver (DR) 916 has to start NATFW NSLP signaling. This causes the NI associated 917 with the data sender (DS) to launch NSLP signaling towards the 918 address of data receiver (DR) (see Figure 10). Although it is 919 expected that the DS and the NATFW NSLP NI will usually reside on the 920 same host, this specification does not rule out scenarios where the 921 DS and NI reside on different hosts, the so-called proxy mode (see 922 Section 3.7.6.) 924 +-------+ +-------+ +-------+ +-------+ 925 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 926 | |--->| NF1 |--->| NF2 |--->| | 927 +-------+ +-------+ +-------+ +-------+ 929 ========================================> 930 Data Traffic Direction (outbound) 932 ---> : NATFW NSLP request signaling 933 ~~~> : NATFW NSLP response signaling 934 DS/NI : Data sender and NSIS initiator 935 DR/NR : Data receiver and NSIS responder 936 MB1 : Middlebox 1 and NSIS forwarder 1 937 MB2 : Middlebox 2 and NSIS forwarder 2 939 Figure 10: General NSIS signaling 941 The following list shows the normal sequence of NSLP events without 942 detailing the interaction with the NTLP and the interactions on the 943 the NTLP level. 945 o NSIS initiators generate request messages (which are either CREATE 946 or EXTERNAL messages) and send these towards the NSIS responder. 948 This request message is the initial message which creates a new 949 NATFW NSLP signaling session. The NI and the NR will most likely 950 already share an application session before they start the NATFW 951 NSLP signaling session. Note well the difference between both 952 sessions. 954 o NSLP request messages are processed each time a NF with NATFW NSLP 955 support is traversed. Each NF that is intercepting a request 956 message and is accepting it for further treatment is joining the 957 particular NATFW NSLP signaling session. These nodes process the 958 message, check local policies for authorization and 959 authentication, possibly create policy rules, and forward the 960 signaling message to the next NSIS node. The request message is 961 forwarded until it reaches the NSIS responder. 963 o NSIS responders will check received messages and process them if 964 applicable. NSIS responders generate RESPONSE messages and send 965 them hop-by-hop back to the NI via the same chain of NFs 966 (traversal of the same NF chain is guaranteed through the 967 established reverse message routing state in the NTLP). The NR is 968 also joining the NATFW NSLP signaling session if the request 969 message is accepted. 971 o The RESPONSE message is processed at each NF that has been 972 included in the prior NATFW NSLP signaling session setup. 974 o If the NI has received a successful RESPONSE message and if the 975 signaling NATFW NSLP session started with a CREATE message, the 976 data sender can start sending its data flow to the data receiver. 977 If the NI has received a successful RESPONSE message and if the 978 signaling NATFW NSLP session started with a EXTERNAL message, the 979 data receiver is ready to receive further CREATE messages. 981 Because NATFW NSLP signaling follows the data path from DS to DR, 982 this immediately enables communication between both hosts for 983 scenarios with only firewalls on the data path or NATs on the sender 984 side. For scenarios with NATs on the receiver side certain problems 985 arise, as described in Section 2.4. 987 3.2.2. Signaling for Inbound Traffic 989 When the NR and the NI are located in different address realms and 990 the NR is located behind a NAT, the NI cannot signal to the NR 991 address directly. The DR/NR is not reachable from other NIs using 992 the private address of the NR and thus NATFW signaling messages 993 cannot be sent to the NR/DR's address. Therefore, the NR must first 994 obtain a NAT binding that provides an address that is reachable for 995 the NI. Once the NR has acquired a public IP address, it forwards 996 this information to the DS via a separate protocol. This application 997 layer signaling, which is out of scope of the NATFW NSLP, may involve 998 third parties that assist in exchanging these messages. 1000 The same holds partially true for NRs located behind firewalls that 1001 block all traffic by default. In this case, NR must tell its inbound 1002 firewalls of inbound NATFW NSLP signaling and corresponding data 1003 traffic. Once the NR has informed the inbound firewalls, it can 1004 start its application level signaling to initiate communication with 1005 the NI. This mechanism can be used by machines hosting services 1006 behind firewalls as well. In this case, the NR informs the inbound 1007 firewalls as described, but does not need to communicate this to the 1008 NIs. 1010 NATFW NSLP signaling supports this scenario by using the EXTERNAL 1011 message 1013 1. The DR acquires a public address by signaling on the reverse path 1014 (DR towards DS) and thus making itself available to other hosts. 1015 This process of acquiring public addresses is called reservation. 1016 During this process the DR reserves publicly reachable addresses 1017 and ports suitable for further usage in application level 1018 signaling and the publicly reachable address for further NATFW 1019 NSLP signaling. However, the data traffic will not be allowed to 1020 use this address/port initially (see next point). In the process 1021 of reservation the DR becomes the NI for the messages necessary 1022 to obtain the publicly reachable IP address, i.e., the NI for 1023 this specific NATFW NSLP signaling session. 1025 2. Now on the side of DS, the NI creates a new NATFW NSLP signaling 1026 session and signals directly to the public IP address of DR. 1027 This public IP address is used as NR's address, as the NI would 1028 do if there is no NAT in between, and creates policy rules at 1029 middleboxes. Note, that the reservation will only allow 1030 forwarding of signaling messages, but not data flow packets. 1031 Policy rules allowing forwarding of data flow packets set up by 1032 the prior EXTERNAL message signaling will be activated when the 1033 signaling from NI towards NR is confirmed with a positive 1034 RESPONSE message. The EXTERNAL message is described in 1035 Section 3.7.2. 1037 3.2.3. Signaling for Proxy Mode 1038 administrative domain 1039 ----------------------------------\ 1040 | 1041 +-------+ +-------+ +-------+ | +-------+ 1042 | DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR | 1043 | |--->| NF1 |--->| NR | | | | 1044 +-------+ +-------+ +-------+ | +-------+ 1045 | 1046 ----------------------------------/ 1048 ========================================> 1049 Data Traffic Direction (outbound) 1051 ---> : NATFW NSLP request signaling 1052 ~~~> : NATFW NSLP response signaling 1053 DS/NI : Data sender and NSIS initiator 1054 DR/NR : Data receiver and NSIS responder 1055 MB1 : Middlebox 1 and NSIS forwarder 1 1056 MB2 : Middlebox 2 and NSIS responder 1058 Figure 11: proxy mode signaling for data sender 1060 The above usage assumes that both ends of a communication support 1061 NSIS, but fails when NSIS is only deployed at one end of the path. 1062 In this case only one of the sending Figure 11 or receiving Figure 12 1063 side is NSIS aware and not both at the same time. NATFW NSLP 1064 supports both scenarios (i.e., either the DS or DR do not support 1065 NSIS) by using a proxy mode, as described in Section 3.7.6 1066 administrative domain 1067 / ---------------------------------- 1068 | 1069 +-------+ | +-------+ +-------+ +-------+ 1070 | DS | | | MB2/ |~~~>| MB1/ |~~~>| DR | 1071 | | | | NR |<---| NF1 |<---| | 1072 +-------+ | +-------+ +-------+ +-------+ 1073 | 1074 \---------------------------------- 1076 ========================================> 1077 Data Traffic Direction (inbound) 1079 ---> : NATFW NSLP request signaling 1080 ~~~> : NATFW NSLP response signaling 1081 DS/NI : Data sender and NSIS initiator 1082 DR/NR : Data receiver and NSIS responder 1083 MB1 : Middlebox 1 and NSIS forwarder 1 1084 MB2 : Middlebox 2 and NSIS responder 1086 Figure 12: proxy mode signaling for data receiver 1088 3.2.4. Blocking Traffic 1090 The basic functionality of the NATFW NSLP provides for opening 1091 firewall pin holes and creating NAT bindings to enable data flows to 1092 traverse these devices. Firewalls are normally expected to work on a 1093 'deny-all' policy, meaning that traffic not explicitly matching any 1094 firewall filter rule will be blocked. Similarly, the normal behavior 1095 of NATs is to block all traffic that does not match any already 1096 configured/installed binding or NATFW NSLP session. However, some 1097 scenarios require support of firewalls having 'allow-all' policies, 1098 allowing data traffic to traverse the firewall unless it is blocked 1099 explicitly. Data receivers can utilize NATFW NSLP's EXTERNAL message 1100 with action set to 'deny' to install policy rules at inbound 1101 firewalls to block unwanted traffic. 1103 3.2.5. State and Error Maintenance 1105 The protocol works on a soft-state basis, meaning that whatever state 1106 is installed or reserved on a middlebox will expire, and thus be de- 1107 installed or forgotten after a certain period of time. To prevent 1108 premature removal of state that is needed for ongoing communication, 1109 the NATFW NI involved will have to specifically request a NATFW NSLP 1110 signaling session extension. An explicit NATFW NSLP state deletion 1111 capability is also provided by the protocol. 1113 If the actions requested by a NATFW NSLP message cannot be carried 1114 out, NFs and the NR must return a failure, such that appropriate 1115 actions can be taken. They can do this either during the request 1116 message handling (synchronously) by sending an error RESPONSE 1117 message, or at any time (asynchronously) by sending a NOTIFY 1118 notification message. 1120 The next sections define the NATFW NSLP message types and formats, 1121 protocol operations, and policy rule operations. 1123 3.2.6. Message Types 1125 The protocol uses four messages types: 1127 o CREATE: a request message used for creating, changing, refreshing, 1128 and deleting NATFW NSLP signaling sessions, i.e., open the data 1129 path from DS to DR. 1131 o EXTERNAL: a request message used for reserving, changing, 1132 refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions. 1133 EXTERNAL messages are forwarded to the edge-NAT or edge-firewall 1134 and allow inbound CREATE messages to be forwarded to the NR. 1135 Additionally, EXTERNAL messages reserve an external address and, 1136 if applicable, port number at an edge-NAT. 1138 o NOTIFY: an asynchronous message used by NATFW peers to alert other 1139 NATFW peers about specific events (especially failures). 1141 o RESPONSE: used as a response to CREATE and EXTERNAL request 1142 messages. 1144 3.2.7. Classification of RESPONSE Messages 1146 RESPONSE messages will be generated synchronously to CREATE and 1147 EXTERNAL messages by NSIS Forwarders and Responders to report success 1148 or failure of operations or some information relating to the NATFW 1149 NSLP signaling session or a node. RESPONSE messages MUST NOT be 1150 generated for any other message, such as NOTIFY and RESPONSE. 1152 All RESPONSE messages MUST carry a NATFW_INFO object which contains a 1153 severity class code and a response code (see Section 4.2.5). This 1154 section defines terms for groups of RESPONSE messages depending on 1155 the severity class. 1157 o Successful RESPONSE: Messages carrying NATFW_INFO with severity 1158 class 'Success' (0x2). 1160 o Informational RESPONSE: Messages carrying NATFW_INFO with severity 1161 class 'Informational' (0x1) (only used with NOTIFY messages). 1163 o Error RESPONSE: Messages carrying NATFW_INFO with severity class 1164 other than 'Success' or 'Informational'. 1166 3.2.8. NATFW NSLP Signaling Sessions 1168 A NATFW NSLP signaling session defines an association between the NI, 1169 NFs, and the NR related to a data flow. This association is created 1170 when the initial CREATE or EXTERNAL message is successfully received 1171 at the NFs or the NR. There is signaling NATFW NSLP session state 1172 stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP 1173 signaling session state for the NATFW NSLP comprises NSLP state and 1174 the associated policy rules at a middlebox. 1176 The NATFW NSLP signaling session is identified by the session ID 1177 (plus other information at the NTLP level). The session ID is 1178 generated by the NI before the initial CREATE or EXTERNAL message is 1179 sent. The value of the session ID MUST be generated as a 1180 cryptographically random number (see [RFC4086] by the NI, i.e., the 1181 output MUST NOT be easily guessable by third parties. The session ID 1182 is not stored in any NATFW NSLP message but passed on to the NTLP. 1184 A NATFW NSLP signaling session has several conceptional states that 1185 describes in what state a signaling session is at a given time. The 1186 signaling session can have these states at a node: 1188 o Pending: The NATFW NSLP signaling session has been created and the 1189 node is waiting for a RESPONSE message to the CREATE or EXTERNAL 1190 message. A NATFW NSLP signaling session in state 'Pending' MUST 1191 be marked as 'Dead' if no corresponding RESPONSE message has been 1192 received within the time of the locally granted NATFW NSLP 1193 signaling session lifetime of the forwarded CREATE or EXTERNAL 1194 message (as described in Section 3.4). 1196 o Established: The NATFW NSLP signaling session is established, i.e, 1197 the signaling has been successfully performed and the lifetime of 1198 NATFW NSLP signaling session is counted from now on. A NATFW NSLP 1199 signaling session in state 'Established' MUST be marked as 'Dead' 1200 if no refresh message has been received within the time of the 1201 locally granted NATFW NSLP signaling session lifetime of the 1202 RESPONSE message (as described in Section 3.4). 1204 o Dead: Either the NATFW NSLP signaling session is timed out or the 1205 node has received an error RESPONSE message for the NATFW NSLP 1206 signaling session and the NATFW NSLP signaling session can be 1207 deleted. 1209 o Transitory: The node has received an asynchronous message, i.e., a 1210 NOTIFY, and can delete the NATFW NSLP signaling session if needed 1211 after some time. When a node has received a NOTIFY message, it 1212 marks the signaling session as 'transitory'. This signaling 1213 session SHOULD NOT be deleted before a minimum hold time of 30 1214 second, i.e., it can be removed after 30 seconds or more. This 1215 hold time ensures that the existing signaling session can be 1216 reused by the NI, e.g., a part of a signalling session that is not 1217 affected by the route change can be reused once the updating 1218 request message is received. 1220 3.3. Basic Message Processing 1222 All NATFW messages are subject to some basic message processing when 1223 received at a node, independent of the message type. Initially, the 1224 syntax of the NSLP message is checked and a RESPONSE message with an 1225 appropriate error of class 'Protocol error' (0x3) code is generated 1226 if any problem is detected. If a message is delivered to the NATFW 1227 NSLP, this implies that the NTLP layer has been able to correlate it 1228 with the SID and MRI entries in its database. There is therefore 1229 enough information to identify the source of the message and routing 1230 information to route the message back to the NI through an 1231 established chain of NTLP messaging associations. The message is not 1232 further forwarded if any error in the syntax is detected. The 1233 specific response codes stemming from the processing of objects are 1234 described in the respective object definition section (see 1235 Section 4). After passing this check, the NATFW NSLP node performs 1236 authentication/authorization related checks described in Section 3.6. 1237 Further processing is executed only if these tests have been 1238 successfully passed, otherwise the processing stops and an error 1239 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. The NATFW NSLP signaling session 1262 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 This requested NATFW NSLP signaling session lifetime value lt is 1312 stored in the NATFW_LT object of the NSLP message. 1314 NSLP forwarders and the NSLP responder can execute the following 1315 behavior with respect to the requested lifetime handling: 1317 Requested signaling session lifetime acceptable: 1319 No changes to the NATFW NSLP signaling session lifetime values are 1320 needed. The CREATE or EXTERNAL message is forwarded, if 1321 applicable. 1323 Signaling session lifetime can be lowered: 1325 An NSLP forwarded or the NSLP responder MAY also lower the 1326 requested NATFW NSLP signaling session lifetime to an acceptable 1327 value (based on its local policies). If an NF changes the NATFW 1328 NSLP signaling session lifetime value, it MUST store the new value 1329 in the NATFW_LT object. The CREATE or EXTERNAL message is 1330 forwarded. 1332 Requested signaling session lifetime is too big: 1334 An NSLP forwarded or the NSLP responder MAY reject the requested 1335 NATFW NSLP signaling session lifetime value as being too big and 1336 MUST generate an error RESPONSE message of class 'Signaling 1337 session failure' (0x6) with response code 'Requested lifetime is 1338 too big' (0x02) upon rejection. Lowering the lifetime is 1339 preferred instead of generating an error message. 1341 Requested signaling session lifetime is too small: 1343 An NSLP forwarded or the NSLP responder MAY reject the requested 1344 NATFW NSLP signaling session lifetime value as being to small and 1345 MUST generate an error RESPONSE message of class 'Signaling 1346 session failure' (0x6) with response code 'Requested lifetime is 1347 too small' (0x10) upon rejection. 1349 NFs or the NR MUST NOT increase the NATFW NSLP signaling session 1350 lifetime value. Messages can be rejected on the basis of the NATFW 1351 NSLP signaling session lifetime being too long when a NATFW NSLP 1352 signaling session is first created and also on refreshes. 1354 The NSLP responder generates a successful RESPONSE for the received 1355 CREATE or EXTERNAL message, sets the NATFW NSLP signaling session 1356 lifetime value in the NATFW_LT object to the above granted lifetime 1357 and sends the message back towards NSLP initiator. 1359 Each NSLP forwarder processes the RESPONSE message, reads and stores 1360 the granted NATFW NSLP signaling session lifetime value. The 1361 forwarders MUST accept the granted NATFW NSLP signaling session 1362 lifetime, if the lifetime value is within the acceptable range. The 1363 acceptable value refers to the value accepted by the NSLP forwarder 1364 when processing the CREATE or EXTERNAL message. For received values 1365 greater than the acceptable value, NSLP forwarders MUST generate a 1366 RESPONSE message of class 'Signaling session failure' (0x6) with 1367 response code 'Modified lifetime is too big' (0x11). For received 1368 values lower than the values acceptable by the node local policy, 1369 NSLP forwarders MUST generate a RESPONSE message of class 'Signaling 1370 session failure' (0x6) with response code 'Modified lifetime is too 1371 small' (0x12). 1373 Figure 13 shows the procedure with an example, where an initiator 1374 requests 60 seconds lifetime in the CREATE message and the lifetime 1375 is shortened along the path by the forwarder to 20 seconds and by the 1376 responder to 15 seconds. When the NSLP forwarder receives the 1377 RESPONSE message with a NATFW NSLP signaling session lifetime value 1378 of 15 seconds it checks whether this value is lower or equal to the 1379 acceptable value. 1381 +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ 1382 | |---------------->| NSLP |---------------->| | 1383 | NI | | forwarder | | NR | 1384 | |<----------------| check 15<20 |<----------------| | 1385 +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ 1387 lt = lifetime 1389 Figure 13: Signaling Session Lifetime Setting Example 1391 3.5. Message Sequencing 1393 NATFW NSLP messages need to carry an identifier so that all nodes 1394 along the path can distinguish messages sent at different points in 1395 time. Messages can be lost along the path or duplicated. So all 1396 NATFW NSLP nodes should be able to identify either old messages that 1397 have been received before (duplicated), or the case that messages 1398 have been lost before (loss). For message replay protection it is 1399 necessary to keep information about messages that have already been 1400 received and requires every NATFW NSLP message to carry a message 1401 sequence number (MSN), see also Section 4.2.7. 1403 The MSN MUST be set by the NI and MUST NOT be set or modified by any 1404 other node. The initial value for the MSN MUST be generated randomly 1405 and MUST be unique only within the NATFW NSLP signaling session for 1406 which it is used. The NI MUST increment the MSN by one for every 1407 message sent. Once the MSN has reached the maximum value, the next 1408 value it takes is zero. All NATFW NSLP nodes MUST use the algorithm 1409 defined in [RFC1982] to detect MSN wrap-arounds. 1411 NSIS forwarders and the responder store the MSN from the initial 1412 CREATE or EXTERNAL packet which creates the NATFW NSLP signaling 1413 session as the start value for the NATFW NSLP signaling session. NFs 1414 and NRs MUST include the received MSN value in the corresponding 1415 RESPONSE message that they generate. 1417 When receiving a CREATE or EXTERNAL message, a NATFW NSLP node uses 1418 the MSN given in the message to determine whether the state being 1419 requested is different to the state already installed. The message 1420 MUST be discarded if the received MSN value is equal to or lower than 1421 the stored MSN value. Such a received MSN value can indicate a 1422 duplicated and delayed message or replayed message. If the received 1423 MSN value is greater than the already stored MSN value, the NATFW 1424 NSLP MUST update its stored state accordingly, if permitted by all 1425 security checks (see Section 3.6), and store the updated MSN value 1426 accordingly. 1428 3.6. Authentication, Authorization, and Policy Decisions 1430 NATFW NSLP nodes receiving signaling messages MUST first check 1431 whether this message is authenticated and authorized to perform the 1432 requested action. NATFW NSLP nodes requiring more information than 1433 provided MUST generate an error RESPONSE of class 'Permanent failure' 1434 (0x5) with response code 'Authentication failed' (0x01) or with 1435 response code 'Authorization failed' (0x02). 1437 The NATFW NSLP is expected to run in various environments, such as 1438 IP-based telephone systems, enterprise networks, home networks, etc. 1439 The requirements on authentication and authorization are quite 1440 different between these use cases. While a home gateway, or an 1441 Internet cafe, using NSIS may well be happy with a "NATFW signaling 1442 coming from inside the network" policy for authorization of 1443 signaling, enterprise networks are likely to require more strongly 1444 authenticated/authorized signaling. This enterprise scenario may 1445 require the use of an infrastructure and administratively assigned 1446 identities to operate the NATFW NSLP. 1448 Once the NI is authenticated and authorized, another step is 1449 performed. The requested policy rule for the NATFW NSLP signaling 1450 session is checked against a set of policy rules, i.e., whether the 1451 requesting NI is allowed to request the policy rule to be loaded in 1452 the device. If this fails the NF or NR must send an error RESPONSE 1453 of class 'Permanent failure' (0x5) and with response code 1454 'Authorization failed' (0x02). 1456 3.7. Protocol Operations 1458 This section defines the protocol operations including, how to create 1459 NATFW NSLP signaling sessions, maintain them, delete them, and how to 1460 reserve addresses. 1462 This section requires a good knowledge of the NTLP 1463 ([I-D.ietf-nsis-ntlp]) and the message routing method mechanism and 1464 the associated message routing information (MRI). The NATFW NSLP 1465 uses information from the MRI, e.g., the destination and source 1466 ports, and the NATFW NSLP to construct the policy rules used on the 1467 NATFW NSLP level. See also Appendix D for further information about 1468 this. 1470 3.7.1. Creating Signaling Sessions 1472 Allowing two hosts to exchange data even in the presence of 1473 middleboxes is realized in the NATFW NSLP by use of the CREATE 1474 message. The NI (either the data sender or a proxy) generates a 1475 CREATE message as defined in Section 4.3.1 and hands it to the NTLP. 1476 The NTLP forwards the whole message on the basis of the message 1477 routing information (MRI) towards the NR. Each NSIS forwarder along 1478 the path that implements NATFW NSLP, processes the NSLP message. 1479 Forwarding is done hop-by-hop but may pass transparently through NSIS 1480 forwarders which do not contain NATFW NSLP functionality and non-NSIS 1481 aware routers between NSLP hop way points. When the message reaches 1482 the NR, the NR can accept the request or reject it. The NR generates 1483 a response to CREATE and this response is transported hop-by-hop 1484 towards the NI. NATFW NSLP forwarders may reject requests at any 1485 time. Figure 14 sketches the message flow between NI (DS in this 1486 example), a NF (e.g., NAT), and NR (DR in this example). 1488 NI Private Network NF Public Internet NR 1489 | | | 1490 | CREATE | | 1491 |----------------------------->| | 1492 | | | 1493 | | | 1494 | | CREATE | 1495 | |--------------------------->| 1496 | | | 1497 | | RESPONSE | 1498 | RESPONSE |<---------------------------| 1499 |<-----------------------------| | 1500 | | | 1501 | | | 1503 Figure 14: CREATE message flow with success RESPONSE 1505 There are several processing rules for a NATFW peer when generating 1506 and receiving CREATE messages, since this message type is used for 1507 creating new NATFW NSLP signaling session, updating existing, 1508 extending the lifetime and deleting NATFW NSLP signaling session. 1509 The three latter functions operate in the same way for all kinds of 1510 CREATE message, and are therefore described in separate sections: 1512 o Extending the lifetime of NATFW NSLP signaling sessions is 1513 described in Section 3.7.3. 1515 o Deleting NATFW NSLP signaling sessions is described in 1516 Section 3.7.4. 1518 o Updating policy rules is described in Section 3.10. 1520 For an initial CREATE message creating a new NATFW NSLP signaling 1521 session, the processing of CREATE messages is different for every 1522 NATFW node type: 1524 o NSLP initiator: An NI only generates CREATE messages and hands 1525 them over to the NTLP. The NI should never receive CREATE 1526 messages and MUST discard it. 1528 o NATFW NSLP forwarder: NFs that are unable to forward the CREATE 1529 message to the next hop MUST generate an error RESPONSE of class 1530 'Permanent failure' (0x6) with response code 'Did not reach the 1531 NR' (0x07). This case may occur if the NTLP layer cannot find an 1532 NATFW NSLP peer, either another NF or the NR, and returns an error 1533 via the GIST API (a timeout error reported by GIST). The NSLP 1534 message processing at the NFs depends on the middlebox type: 1536 * NAT: When the initial CREATE message is received at the public 1537 side of the NAT, it looks for a reservation made in advance, by 1538 using a EXTERNAL message (see Section 3.7.2). The matching 1539 process considers the received MRI information and the stored 1540 MRI information, as described in Section 3.8. If no matching 1541 reservation can be found, i.e., no reservation has been made in 1542 advance, the NSLP MUST return an error RESPONSE of class 1543 'Signaling session failure' (0x6) with response code 'No 1544 reservation found matching the MRI of the CREATE request' 1545 (0x03). If there is a matching reservation, the NSLP stores 1546 the data sender's address (and if applicable port number) as 1547 part of the source address of the policy rule ('the remembered 1548 policy rule') to be loaded and forwards the message with the 1549 destination address set to the internal (private in most cases) 1550 address of NR. When the initial CREATE message is received at 1551 the private side, the NAT binding is allocated, but not 1552 activated (see also Appendix D.3). An error RESPONSE message 1553 is generated, if the requested policy rule cannot be installed 1554 later on, of class 'Signaling session failure' (0x6) with 1555 response code 'Requested policy rule denied due to policy 1556 conflict' (0x4). The MRI information is updated to reflect the 1557 address, and if applicable port, translation. The NSLP message 1558 is forwarded towards the NR with source address set to the 1559 NAT's external address from the newly remembered binding. 1561 * Firewall: When the initial CREATE message is received, the NSLP 1562 just remembers the requested policy rule, but does not install 1563 any policy rule. Afterwards, the message is forwarded towards 1564 the NR. An error RESPONSE message is generated, if the 1565 requested policy rule cannot be installed later on, with of 1566 class 'Signaling session failure' (0x6) with response code 1567 'Requested policy rule denied due to policy conflict' (0x4). 1569 * Combined NAT and firewall: Processing at combined firewall and 1570 NAT middleboxes is the same as in the NAT case. No policy 1571 rules are installed. Implementations MUST take into account 1572 the order of packet processing in the firewall and NAT 1573 functions within the device. This will be referred to as 1574 'order of functions' and is generally different depending on 1575 whether the packet arrives at the external or internal side of 1576 the middlebox. 1578 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1579 with a success RESPONSE of class 'Success' (0x2) with response 1580 code set to 'All successfully processed' (0x01), if they accept 1581 the CREATE message. Otherwise they MUST generate a RESPONSE 1582 message with a suitable response code. RESPONSE messages are sent 1583 back NSLP hop-by-hop towards the NI, irrespective of the response 1584 codes, either success or error. 1586 Remembered policy rules at middleboxes MUST be only installed upon 1587 receiving a corresponding successful RESPONSE message with the same 1588 SID as the CREATE message that caused them to be remembered. This is 1589 a countermeasure to several problems, for example, wastage of 1590 resources due to loading policy rules at intermediate NFs when the 1591 CREATE message does not reach the final NR for some reason. 1593 Processing of a RESPONSE message is different for every NSIS node 1594 type: 1596 o NSLP initiator: After receiving a successful RESPONSE, the data 1597 path is configured and the DS can start sending its data to the 1598 DR. After receiving an error RESPONSE message, the NI MAY try to 1599 generate the CREATE message again or give up and report the 1600 failure to the application, depending on the error condition. 1602 o NSLP forwarder: NFs install the remembered policy rules, if a 1603 successful RESPONSE message with matching SID is received. If an 1604 ERROR RESPONSE message with matching SID is received, the NATFW 1605 NSLP session is marked as dead, no policy rule is installed and 1606 the remembered rule is discarded. 1608 o NSIS responder: The NR should never receive RESPONSE messages and 1609 MUST silently drop any such messages received. 1611 NFs and the NR can also tear down the CREATE session at any time by 1612 generating a NOTIFY message with the appropriate response code set. 1614 3.7.2. Reserving External Addresses 1616 NSIS signaling is intended to travel end-to-end, even in the presence 1617 of NATs and firewalls on-path. This works well in cases where the 1618 data sender is itself behind a NAT or a firewall as described in 1619 Section 3.7.1. For scenarios where the data receiver is located 1620 behind a NAT or a firewall and it needs to receive data flows from 1621 outside its own network (usually referred to as inbound flows, see 1622 Figure 5) the problem is more troublesome. 1624 NSIS signaling, as well as subsequent data flows, are directed to a 1625 particular destination IP address that must be known in advance and 1626 reachable. Data receivers must tell the local NSIS infrastructure 1627 (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP 1628 signaling and data flows before they can receive these flows. It is 1629 necessary to differentiate between data receivers behind NATs and 1630 behind firewalls for understanding the further NATFW procedures. 1631 Data receivers that are only behind firewalls already have a public 1632 IP address and they need only to be reachable for NATFW signaling. 1633 Unlike data receivers behind just firewalls, data receivers behind 1634 NATs do not have public IP addresses; consequently they are not 1635 reachable for NATFW signaling by entities outside their addressing 1636 realm. 1638 The preceding discussion addresses the situation where a DR node that 1639 wants to be reachable is unreachable because the NAT lacks a suitable 1640 rule with the 'allow' action which would forward inbound data. 1641 However, in certain scenarios, a node situated behind inbound 1642 firewalls that do not block inbound data traffic (firewalls with 1643 "default to allow") unless requested might wish to prevent traffic 1644 being sent to it from specified addresses. In this case, NSIS NATFW 1645 signaling can be used to achieve this by installing a policy rule 1646 with its action set to 'deny' using the same mechanisms as for 1647 'allow' rules. 1649 The required result is obtained by sending a EXTERNAL message in the 1650 inbound direction of the intended data flow. When using this 1651 functionality the NSIS initiator for the 'Reserve External Address' 1652 signaling is typically the node that will become the DR for the 1653 eventual data flow. To distinguish this initiator from the usual 1654 case where the NI is associated with the DS, the NI is denoted by NI+ 1655 and the NSIS responder is similarly denoted by NR+. 1657 Public Internet Private Address 1658 Space 1660 Edge 1661 NI(DS) NAT/FW NAT NR(DR) 1662 NR+ NI+ 1664 | | | | 1665 | | | | 1666 | | | | 1667 | | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] | 1668 | |<----------------------|<----------------------| 1669 | | | | 1670 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1671 | |---------------------->|---------------------->| 1672 | | | | 1673 | | | | 1675 ============================================================> 1676 Data Traffic Direction 1678 Figure 15: Reservation message flow for DR behind NAT or firewall 1680 Figure 15 shows the EXTERNAL message flow for enabling inbound NATFW 1681 NSLP signaling messages. In this case the roles of the different 1682 NSIS entities are: 1684 o The data receiver (DR) for the anticipated data traffic is the 1685 NSIS initiator (NI+) for the EXTERNAL message, but becomes the 1686 NSIS responder (NR) for following CREATE messages. 1688 o The actual data sender (DS) will be the NSIS initiator (NI) for 1689 later CREATE messages and may be the NSIS target of the signaling 1690 (NR+). 1692 o It may be necessary to use a signaling destination address (SDA) 1693 as the actual target of the EXTERNAL message (NR+) if the DR is 1694 located behind a NAT and the address of the DS is unknown. The 1695 SDA is an arbitrary address in the outermost address realm on the 1696 other side of the NAT from the DR. Typically this will be a 1697 suitable public IP address when the 'outside' realm is the public 1698 Internet. This choice of address causes the EXTERNAL message to 1699 be routed through the NATs towards the outermost realm and would 1700 force interception of the message by the outermost NAT in the 1701 network at the boundary between the private address and the public 1702 address realm (the edge-NAT). It may also be intercepted by other 1703 NATs and firewalls on the path to the edge-NAT. 1705 Basically, there are two different signaling scenarios. Either 1707 1. the DR behind the NAT/firewall knows the IP address of the DS in 1708 advance, 1710 2. or the address of DS is not known in advance. 1712 Case 1 requires the NATFW NSLP to request the path-coupled message 1713 routing method (PC-MRM) from the NTLP. The EXTERNAL message MUST be 1714 sent with PC-MRM (see Section 5.8.1 in [I-D.ietf-nsis-ntlp]) with the 1715 direction set to 'upstream' (inbound). The handling of case 2 1716 depends on the situation of DR: If DR is solely located behind a 1717 firewall, the EXTERNAL message MUST be sent with the PC-MRM, 1718 direction 'upstream' (inbound), and data flow source IP address set 1719 to wildcard. If DR is located behind a NAT, the EXTERNAL message 1720 MUST be sent with the loose-end message routing method (LE-MRM, see 1721 Section 5.8.2 in [I-D.ietf-nsis-ntlp]), the destination-address set 1722 to the signaling destination address (SDA, see also Appendix A). For 1723 scenarios with DR being behind a firewall, special conditions apply 1724 (see applicability statement in Appendix C). The data receiver is 1725 challenged to determine whether it is solely located behind firewalls 1726 or NATs, for choosing the right message routing method. This 1727 decision can depend on a local configuration parameter, possibly 1728 given through DHCP, or it could be discovered through other non-NSLP 1729 related testing of the network configuration. It is RECOMMENDED to 1730 use the PC-MRM with the known data sender's IP address. This gives 1731 GIST the best possible handled to route the message 'upstream' 1732 (outbound). It is RECOMMENDED to use the LE-MRM, if and only if the 1733 data sender's IP address is not known and the data receiver is behind 1734 a NAT. 1736 For case 2 with NAT, the NI+ (which could be on the data receiver DR 1737 or on any other host within the private network) sends the EXTERNAL 1738 message targeted to the signaling destination address. The message 1739 routing for the EXTERNAL message is in the reverse direction to the 1740 normal message routing used for path-coupled signaling where the 1741 signaling is sent outbound (as opposed to inbound in this case). 1742 When establishing NAT bindings (and an NATFW NSLP signaling session) 1743 the signaling direction does not matter since the data path is 1744 modified through route pinning due to the external IP address at the 1745 NAT. Subsequent NSIS messages (and also data traffic) will travel 1746 through the same NAT boxes. However, this is only valid for the NAT 1747 boxes, but not for any intermediate firewall. That is the reason for 1748 having a separate CREATE message enabling the reservations made with 1749 EXTERNAL at the NATs and either enabling prior reservations or 1750 creating new pinholes at the firewalls which are encountered on the 1751 outbound path depending on whether the inbound and outbound routes 1752 coincide. 1754 The EXTERNAL signaling message creates an NSIS NATFW signaling 1755 session at any intermediate NSIS NATFW peer(s) encountered, 1756 independent of the message routing method used. Furthermore, it has 1757 to be ensured that the edge-NAT or edge-firewall device is discovered 1758 as part of this process. The end host cannot be assumed to know this 1759 device - instead the NAT or firewall box itself is assumed to know 1760 that it is located at the outer perimeter of the network. Forwarding 1761 of the EXTERNAL message beyond this entity is not necessary, and MUST 1762 be prohibited as it may provide information on the capabilities of 1763 internal hosts. It should be noted, that it is the outermost NAT or 1764 firewall that is the edge-device that must be found during this 1765 discovery process. For instance, when there are a NAT and afterwards 1766 a firewall on the outbound path at the network border, the firewall 1767 is the edge-firewall. All messages must be forwarded to the 1768 topology-wise outermost edge-device, to ensure that this device knows 1769 about the NATFW NSLP signaling sessions for incoming CREATE messages. 1770 However, the NAT is still the edge-NAT because it has a public 1771 globally routable IP address on its public side: this is not affected 1772 by any firewall between the edge-NAT and the public network. 1774 Possible edge arrangements are: 1776 Public Net ----------------- Private net -------------- 1778 | Public Net|--|Edge-FW|--|FW|...|FW|--|DR| 1780 | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR| 1782 | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR| 1784 The edge-NAT or edge-firewall device closest to the public realm 1785 responds to the EXTERNAL request message with a successful RESPONSE 1786 message. An edge-NAT includes an NATFW_EXTERNAL-IP object (see 1787 Section 4.2.2), carrying the public reachable IP address, and if 1788 applicable port number. 1790 The NI+ can request each intermediate NAT (i.e., a NAT that is not 1791 the edge-NAT) to include the external binding address (and if 1792 applicable port number) in the external binding address object. The 1793 external binding address object stores the external IP address (and 1794 port) at the particular NAT. The NI+ has to include the external 1795 binding address (see Section 4.2.3) object in the request message, if 1796 it wishes to obtain the information. 1798 There are several processing rules for a NATFW peer when generating 1799 and receiving EXTERNAL messages, since this message type is used for 1800 creating new reserve NATFW NSLP signaling sessions, updating 1801 existing, extending the lifetime and deleting NATFW NSLP signaling 1802 session. The three latter functions operate in the same way for all 1803 kinds of CREATE and EXTERNAL messages, and are therefore described in 1804 separate sections: 1806 o Extending the lifetime of NATFW NSLP signaling sessions is 1807 described in Section 3.7.3. 1809 o Deleting NATFW NSLP signaling sessions is described in 1810 Section 3.7.4. 1812 o Updating policy rules is described in Section 3.10. 1814 The NI+ MUST always include a NATFW_DTINFO object in the EXTERNAL 1815 message. Especially, the LE-MRM does not include enough information 1816 for some types of NATs (basically, those NATs which also translate 1817 port numbers) to perform the address translation. This information 1818 is provided in the NATFW_DTINFO (see Section 4.2.8). This 1819 information MUST include at least the 'dst port number' and 1820 'protocol' fields, in the NATFW_DTINFO object as these may be 1821 required by en-route NATs, depending on the type of the NAT. All 1822 other fields MAY be set by the NI+ to restrict the set of possible 1823 NIs. An edge-NAT will use the information provided in the 1824 NATFW_DTINFO object to allow only a NATFW CREATE message with a 1825 matching MRI to be forwarded. The MRI of the NATFW CREATE message 1826 has to use the parameters set in NATFW_DTINFO object ('src IPv4/v6 1827 address', 'src port number', 'protocol') as the source address/port 1828 of the flow from DS to DR. A NAT requiring information carried in 1829 the NATFW_DTINFO can generate a number of error RESPONSE messages of 1830 class 'Signaling session failure' (0x6): 1832 o 'Requested policy rule denied due to policy conflict' (0x04) 1834 o 'NATFW_DTINFO object is required' (0x07) 1836 o 'Requested value in sub_ports field in NATFW_EFI not permitted' 1837 (0x08) 1839 o 'Requested IP protocol not supported' (0x09) 1841 o 'Plain IP policy rules not permitted -- need transport layer 1842 information' (0x0A) 1844 o 'source IP address range is too large' (0x0C) 1846 o 'destination IP address range is too large' (0x0D) 1848 o 'source L4-port range is too large' (0x0E) 1850 o 'destination L4-port range is too large' (0x0F) 1852 Processing of EXTERNAL messages is specific to the NSIS node type: 1854 o NSLP initiator: NI+ only generate EXTERNAL messages. When the 1855 data sender's address information is known in advance the NI+ can 1856 include a NATFW_DTINFO object in the EXTERNAL message, if not 1857 anyway required to do so (see above). When the data sender's IP 1858 address is not known, the NI+ MUST NOT include an IP address in 1859 the NATFW_DTINFO object. The NI should never receive EXTERNAL 1860 messages and MUST silently discard it. 1862 o NSLP forwarder: The NSLP message processing at NFs depends on the 1863 middlebox type: 1865 * NAT: NATs check whether the message is received at the external 1866 (public in most cases) address or at the internal (private) 1867 address. If received at the external an NF MUST generate an 1868 error RESPONSE of class 'Protocol error' (0x3) with response 1869 code 'Received EXTERNAL request message on external side' 1870 (0x0B). If received at the internal (private address) and the 1871 NATFW_EFI object contains the action 'deny', an error RESPONSE 1872 of class 'Protocol error' (0x3) with response code 'Requested 1873 rule action not applicable' (0x06) MUST be generated. If 1874 received at the internal address, an IP address, and if 1875 applicable one or more ports, are reserved. If the 1876 NATFW_EXTERNAL_BINDING object is present in the message, any 1877 NAT that is not an edge-NAT MUST include the allocated external 1878 IP address, and if applicable one or more ports, (the external 1879 binding address) in the NATFW_EXTERNAL_BINDING object. If it 1880 is an edge-NAT and there is no edge-firewall beyond, the NSLP 1881 message is not forwarded any further and a successful RESPONSE 1882 message is generated containing an NATFW_EXTERNAL-IP object 1883 holding the translated address, and if applicable, port 1884 information from the binding reserved as a result of the 1885 EXTERNAL message. The edge-NAT MUST copy the 1886 NATFW_EXTERNAL_BINDING object to response message, if the 1887 object is included in the EXTERNAL message. The RESPONSE 1888 message is sent back towards the NI+. If it is not an edge- 1889 NAT, the NSLP message is forwarded further using the translated 1890 IP address as signaling source address in the LE-MRM and 1891 translated port in the NATFW_DTINFO object in the field 'DR 1892 port number', i.e., the NATFW_DTINFO object is updated to 1893 reflect the translated port number. The edge-NAT or any other 1894 NAT MUST reject EXTERNAL messages not carrying a NATFW_DTINFO 1895 object or if the address information within this object is 1896 invalid or is not compliant with local policies (e.g., the 1897 information provided relates to a range of addresses 1898 ('wildcarded') but the edge-NAT requires exact information 1899 about DS' IP address and port) with the above mentioned 1900 response codes. 1902 * Firewall: Non edge-firewalls remember the requested policy 1903 rule, keep NATFW NSLP signaling session state, and forward the 1904 message. Edge-firewalls stop forwarding the EXTERNAL message. 1905 The policy rule is immediately loaded if the action in the 1906 NATFW_EFI object is set to 'deny' and the node is an edge- 1907 firewall. The policy rule is remembered, but not activated, if 1908 the action in the NATFW_EFI object is set to 'allow'. In both 1909 cases, a successful RESPONSE message is generated. If the 1910 action is 'allow', and the NATFW_DTINFO object is included, and 1911 the MRM is set to LE-MRM in the request, additionally an 1912 NATFW_EXTERNAL-IP object is included in the RESPONSE message, 1913 holding the translated address, and if applicable port, 1914 information. This information is obtained from the 1915 NATFW_DTINFO object's 'DR port number' and the source-address 1916 of the LE-MRM. The edge-firewall MUST copy the 1917 NATFW_EXTERNAL_BINDING object to response message, if the 1918 object is included in the EXTERNAL message. 1920 * Combined NAT and firewall: Processing at combined firewall and 1921 NAT middleboxes is the same as in the NAT case. 1923 o NSLP receiver: This type of message should never be received by 1924 any NR+ and it MUST generate an error RESPONSE message of class 1925 'Permanent failure' (0x5) with response code 'No edge-device here' 1926 (0x06). 1928 Processing of a RESPONSE message is different for every NSIS node 1929 type: 1931 o NSLP initiator: Upon receiving a successful RESPONSE message, the 1932 NI+ can rely on the requested configuration for future inbound 1933 NATFW NSLP signaling sessions. If the response contains an 1934 NATFW_EXTERNAL-IP object, the NI can use IP address and port pairs 1935 carried for further application signaling. After receiving a 1936 error RESPONSE message, the NI+ MAY try to generate the EXTERNAL 1937 message again or give up and report the failure to the 1938 application, depending on the error condition. 1940 o NSLP forwarder: NFs simply forward this message as long as they 1941 keep state for the requested reservation, if the RESPONSE message 1942 contains NATFW_INFO object with class set to 'Success' (0x2). If 1943 the RESPONSE message contains NATFW_INFO object with class set not 1944 to 'Success' (0x2), the NATFW NSLP signaling session is marked as 1945 dead. 1947 o NSIS responder: This type of message should never be received by 1948 any NR+. The NF should never receive response messages and MUST 1949 silently discard it. 1951 NFs and the NR can also tear down the EXTERNAL session at any time by 1952 generating a NOTIFY message with the appropriate response code set. 1954 Reservations with action 'allow' made with EXTERNAL MUST be enabled 1955 by a subsequent CREATE message. A reservation made with EXTERNAL 1956 (independent of selected action) is kept alive as long as the NI+ 1957 refreshes the particular NATFW NSLP signaling session and it can be 1958 reused for multiple, different CREATE messages. An NI+ may decide to 1959 teardown a reservation immediately after receiving a CREATE message. 1960 This implies that a new NATFW NSLP signaling session must be created 1961 for each new CREATE message. The CREATE message does not re-use the 1962 NATFW NSLP signaling session created by EXTERNAL. 1964 Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode 1965 (see Section 3.7.6) no data traffic will be forwarded to DR beyond 1966 the edge-NAT or edge-firewall. The only function of EXTERNAL is to 1967 ensure that subsequent CREATE messages traveling towards the NR will 1968 be forwarded across the public-private boundary towards the DR. 1969 Correlation of incoming CREATE messages to EXTERNAL reservation 1970 states is described in Section 3.8. 1972 3.7.3. NATFW NSLP Signaling Session Refresh 1974 NATFW NSLP signaling sessions are maintained on a soft-state basis. 1975 After a specified timeout, sessions and corresponding policy rules 1976 are removed automatically by the middlebox, if they are not 1977 refreshed. Soft-state is created by CREATE and EXTERNAL and the 1978 maintenance of this state must be done by these messages. State 1979 created by CREATE must be maintained by CREATE, state created by 1980 EXTERNAL must be maintained by EXTERNAL. Refresh messages, are 1981 messages carrying the same session ID as the initial message and a 1982 NATFW_LT lifetime object with a lifetime greater than zero. Messages 1983 with the same SID but carrying a different MRI are treated as updates 1984 of the policy rules and are processed as defined in Section 3.10. 1985 Every refresh CREATE or EXTERNAL message MUST be acknowledged by an 1986 appropriate response message generated by the NR. Upon reception by 1987 each NSIS forwarder, the state for the given session ID is extended 1988 by the NATFW NSLP signaling session refresh period, a period of time 1989 calculated based on a proposed refresh message period. The new 1990 (extended) lifetime of a NATFW NSLP signaling session is calculated 1991 as current local time plus proposed lifetime value (NATFW NSLP 1992 signaling session refresh period). Section 3.4 defines the process 1993 of calculating lifetimes in detail. 1995 NI Public Internet NAT Private address NR 1997 | | space | 1998 | CREATE[lifetime > 0] | | 2000 |----------------------------->| | 2001 | | | 2002 | | | 2003 | | CREATE[lifetime > 0] | 2004 | |--------------------------->| 2005 | | | 2006 | | RESPONSE[Success/Error] | 2007 | RESPONSE[Success/Error] |<---------------------------| 2008 |<-----------------------------| | 2009 | | | 2010 | | | 2012 Figure 16: Successful Refresh Message Flow, CREATE as example 2014 Processing of NATFW NSLP signaling session refresh CREATE and 2015 EXTERNAL messages is different for every NSIS node type: 2017 o NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling 2018 session refresh CREATE/EXTERNAL messages before the NATFW NSLP 2019 signaling session times out. The rate at which the refresh 2020 CREATE/EXTERNAL messages are sent and their relation to the NATFW 2021 NSLP signaling session state lifetime is discussed further in 2022 Section 3.4. 2024 o NSLP forwarder: Processing of this message is independent of the 2025 middlebox type and is as described in Section 3.4. 2027 o NSLP responder: NRs accepting a NATFW NSLP signaling session 2028 refresh CREATE/EXTERNAL message generate a successful RESPONSE 2029 message, including the granted lifetime value of Section 3.4 in a 2030 NATFW_LT object. 2032 3.7.4. Deleting Signaling Sessions 2034 NATFW NSLP signaling sessions can be deleted at any time. NSLP 2035 initiators can trigger this deletion by using a CREATE or EXTERNAL 2036 messages with a lifetime value set to 0, as shown in Figure 17. 2037 Whether a CREATE or EXTERNAL message type is used, depends on how the 2038 NATFW NSLP signaling session was created. 2040 NI Public Internet NAT Private address NR 2042 | | space | 2043 | CREATE[lifetime=0] | | 2044 |----------------------------->| | 2045 | | | 2046 | | CREATE[lifetime=0] | 2047 | |--------------------------->| 2048 | | | 2050 Figure 17: Delete message flow, CREATE as example 2052 NSLP nodes receiving this message delete the NATFW NSLP signaling 2053 session immediately. Policy rules associated with this particular 2054 NATFW NSLP signaling session MUST be also deleted immediately. This 2055 message is forwarded until it reaches the final NR. The CREATE/ 2056 EXTERNAL message with a lifetime value of 0, does not generate any 2057 response, neither positive nor negative, since there is no NSIS state 2058 left at the nodes along the path. 2060 NSIS initiators can use CREATE/EXTERNAL message with lifetime set to 2061 zero in an aggregated way, such that a single CREATE or EXTERNAL 2062 message is terminating multiple NATFW NSLP signaling sessions. NIs 2063 can follow this procedure if they like to aggregate NATFW NSLP 2064 signaling session deletion requests: The NI uses the CREATE or 2065 EXTERNAL message with the session ID set to zero and the MRI's 2066 source-address set to its used IP address. All other fields of the 2067 respective NATFW NSLP signaling sessions to be terminated are set as 2068 well, otherwise these fields are completely wildcarded. The NSLP 2069 message is transferred to the NTLP requesting 'explicit routing' as 2070 described in Sections 5.2.1 and 7.1.4. in [I-D.ietf-nsis-ntlp]. 2072 The outbound NF receiving such an aggregated CREATE or EXTERNAL 2073 message MUST reject it with an error RESPONSE of class 'Permanent 2074 failure' (0x5) with response code 'Authentication failed' (0x01) if 2075 the authentication fails and with an error RESPONSE of class 2076 'Permanent failure' (0x5) with response code 'Authorization failed' 2077 (0x02) if the authorization fails. Per NATFW NSLP signaling session 2078 proof of ownership, as it is defined in this memo, is not possible 2079 anymore when using this aggregated way. However, the outbound NF can 2080 use the relationship between the information of the received CREATE 2081 or EXTERNAL message and the GIST messaging association where the 2082 request has been received. The outbound NF MUST only accept this 2083 aggregated CREATE or EXTERNAL message through already established 2084 GIST messaging associations with the NI. The outbound NF MUST NOT 2085 propagate this aggregated CREATE or EXTERNAL message but it MAY 2086 generate and forward per NATFW NSLP signaling session CREATE or 2087 EXTERNAL messages. 2089 3.7.5. Reporting Asynchronous Events 2091 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 2092 to report asynchronous events to other NATFW NSLP nodes, especially 2093 to allow reporting back to the NATFW NSLP initiator. Such 2094 asynchronous events may be premature NATFW NSLP signaling session 2095 termination, changes in local policies, route change or any other 2096 reason that indicates change of the NATFW NSLP signaling session 2097 state. 2099 NFs and NRs may generate NOTIFY messages upon asynchronous events, 2100 with a NATFW_INFO object indicating the reason for event. These 2101 reasons can be carried in the NATFW_INFO object (class MUST be set to 2102 'Informational' (0x1)) within the NOTIFY message. This list shows 2103 the response codes and the associated actions to take at NFs and the 2104 NI: 2106 o 'Route change: possible route change on the outbound path' (0x01): 2107 Follow instructions in Section 3.9. This MUST be sent inbound and 2108 outbound, if the signalling session is any state except 2109 'Transitory'. The NOTIFY message for signalling sessions in state 2110 transitory MUST be discarded, as the signalling session is anyhow 2111 transitory. The outbound NOTIFY message MUST be sent with 2112 explicit routing by providing the SII-Handle to the NTLP. 2114 o 'Re-authentication required' (0x02): The NI should re-send the 2115 authentication. This MUST be sent inbound. 2117 o 'NATFW node is going down soon' (0x03): The NI and other NFs 2118 should be prepared for a service interruption at any time. This 2119 message MAY be sent inbound and outbound. 2121 o 'NATFW signaling session lifetime expired' (0x04): The NATFW 2122 signaling session has been expired and the signaling session is 2123 invalid now. NFs MUST mark the signaling session as 'Dead'. This 2124 message MAY be sent inbound and outbound. 2126 o 'NATFW signaling session terminated' (0x05): The NATFW signaling 2127 session has been terminated by any reason and the signaling 2128 session is invalid now. NFs MUST mark the signaling session as 2129 'Dead'. This message MAY be sent inbound and outbound. 2131 NOTIFY messages are always sent hop-by-hop inbound towards NI until 2132 they reach NI or outbound towards the NR as indicated in the list 2133 above. 2135 The initial processing when receiving a NOTIFY message is the same 2136 for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages 2137 through already established NTLP messaging associations. The further 2138 processing is different for each NATFW NSLP node type and depends on 2139 the events notified: 2141 o NSLP initiator: NIs analyze the notified event and behave 2142 appropriately based on the event type. NIs MUST NOT generate 2143 NOTIFY messages. 2145 o NSLP forwarder: NFs analyze the notified event and behave based on 2146 the above description per response code. NFs SHOULD generate 2147 NOTIFY messages upon asynchronous events and forward them inbound 2148 towards the NI or outbound towards the NR, depending on the 2149 received direction, i.e., inbound messages MUST be forwarded 2150 further inbound and outbound messages MUST be forwarded further 2151 outbound. NFs MUST silently discard NOTIFY messages that have 2152 been received outbound but are only allowed to be sent inbound, 2153 e.g. 'Re-authentication required' (0x02). 2155 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 2156 asynchronous events including a response code based on the 2157 reported event. The NR MUST silently discard NOTIFY messages that 2158 have been received outbound but are only allowed to be sent 2159 inbound, e.g. 'Re-authentication required' (0x02), 2161 NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions 2162 at the same time, can experience problems when shutting down service 2163 suddenly. This sudden shutdown can be result of node local failure, 2164 for instance, due to a hardware failure. This NF generates NOTIFY 2165 messages for each of the NATFW NSLP signaling sessions and tries to 2166 send them inbound. Due to the number of NOTIFY messages to be sent, 2167 the shutdown of the node may be unnecessarily prolonged, since not 2168 all messages can be sent at the same time. This case can be 2169 described as a NOTIFY storm, if a multitude of NATFW NSLP signaling 2170 sessions is involved. 2172 To avoid the need of generating per NATFW NSLP signaling session 2173 NOTIFY messages in such a scenario described or similar cases, NFs 2174 SHOULD follow this procedure: The NF uses the NOTIFY message with the 2175 session ID in the NTLP set to zero, with the MRI completely 2176 wildcarded, using the 'explicit routing' as described in Sections 2177 5.2.1 and 7.1.4. in [I-D.ietf-nsis-ntlp]. The inbound NF receiving 2178 this type of NOTIFY immediately regards all NATFW NSLP signaling 2179 sessions from that peer matching the MRI as void. This message will 2180 typically result in multiple NOTIFY messages at the inbound NF, i.e., 2181 the NF can generate per terminated NATFW NSLP signaling session a 2182 NOTIFY message. However, a NF MAY aggregate again the NOTIFY 2183 messages as described here. 2185 3.7.6. Proxy Mode of Operation 2187 Some migration scenarios need specialized support to cope with cases 2188 where NSIS is only deployed in same areas of the Internet. End-to- 2189 end signaling is going to fail without NSIS support at or near both 2190 data sender and data receiver terminals. A proxy mode of operation 2191 is needed. This proxy mode of operation must terminate the NATFW 2192 NSLP signaling topologically-wise as close as possible to the 2193 terminal for which it is proxying and proxy all messages. This NATFW 2194 NSLP node doing the proxying of the signaling messages becomes either 2195 the NI or the NR for the particular NATFW NSLP signaling session, 2196 depending on whether it is the DS or DR that does not support NSIS. 2197 Typically, the edge-NAT or the edge-firewall would be used to proxy 2198 NATFW NSLP messages. 2200 This proxy mode operation does not require any new CREATE or EXTERNAL 2201 message type, but relies on extended CREATE and EXTERNAL message 2202 types. They are called respectively CREATE-PROXY and EXTERNAL-PROXY 2203 and are distinguished by setting the P flag in the NSLP header to 2204 P=1. This flag instructs edge-NATs and edge-firewalls receiving them 2205 to operate in proxy mode for the NATFW NSLP signaling session in 2206 question. The semantics of the CREATE and EXTERNAL message types are 2207 not changed and the behavior of the various node types is as defined 2208 in Section 3.7.1 and Section 3.7.2, except for the proxying node. 2209 The following paragraphs describe the proxy mode operation for data 2210 receivers behind middleboxes and data senders behind middleboxes. 2212 3.7.6.1. Proxying for a Data Sender 2214 The NATFW NSLP gives the NR the ability to install state on the 2215 inbound path towards the data sender for outbound data packets, even 2216 when only the receiving side is running NSIS (as shown in Figure 18). 2217 The goal of the method described is to trigger the edge-NAT/ 2218 edge-firewall to generate a CREATE message on behalf of the data 2219 receiver. In this case, an NR can signal towards the network border 2220 as it is performed in the standard EXTERNAL message handling scenario 2221 as in Section 3.7.2. The message is forwarded until the edge-NAT/ 2222 edge-firewall is reached. A public IP address and port number is 2223 reserved at an edge-NAT/edge-firewall. As shown in Figure 18, unlike 2224 the standard EXTERNAL message handling case, the edge-NAT/ 2225 edge-firewall is triggered to send a CREATE message on a new reverse 2226 path which traverse several firewalls or NATs. The new reverse path 2227 for CREATE is necessary to handle routing asymmetries between the 2228 edge-NAT/edge-firewall and DR. It must be stressed that the 2229 semantics of the CREATE and EXTERNAL messages is not changed, i.e., 2230 each is processed as described earlier. 2232 DS Public Internet NAT/FW Private address DR 2233 No NI NF space NR 2234 NR+ NI+ 2236 | | EXTERNAL-PROXY[(DTInfo)] | 2237 | |<------------------------- | 2238 | | RESPONSE[Error/Success] | 2239 | | ---------------------- > | 2240 | | CREATE | 2241 | | ------------------------> | 2242 | | RESPONSE[Error/Success] | 2243 | | <---------------------- | 2244 | | | 2246 Figure 18: EXTERNAL Triggering Sending of CREATE Message 2248 A NATFW_NONCE object, carried in the EXTERNAL and CREATE message, is 2249 used to build the relationship between received CREATEs at the 2250 message initiator. An NI+ uses the presence of the NATFW_NONCE 2251 object to correlate it to the particular EXTERNAL-PROXY. The absence 2252 of a NONCE object indicates a CREATE initiated by the DS and not by 2253 the edge-NAT. The two signaling sessions, i.e., the session for 2254 EXTERNAL-PROXY and the session for CREATE, are not independent. The 2255 primary session is the EXTERNAL-PROXY session. The CREATE session is 2256 secondary to the EXTERNAL-PROXY session, i.e., the CREATE session is 2257 valid as long as the EXTERNAL-PROXY session is the signaling states 2258 'Established' or 'Transitory'. There is no CREATE session in any 2259 other signaling state of the EXTERNAL-PROXY, i.e., 'pending' or 2260 'dead'. This ensures a fate-sharing between both signaling sessions. 2262 These processing rules of EXTERNAL-PROXY messages are added to the 2263 regular EXTERNAL processing: 2265 o NSLP initiator (NI+): The NI+ MUST take the session ID (SID) value 2266 of the EXTERNAL-PROXY session as the nonce value of the 2267 NATFW_NONCE object. 2269 o NSLP forwarder being either edge-NAT or edge-firewall: When the NF 2270 accepts a EXTERNAL-PROXY message, it generates a successful 2271 RESPONSE message as if it were the NR and additionally, it 2272 generates a CREATE message as defined in Section 3.7.1 and 2273 includes a NATFW_NONCE object having the same value as of the 2274 received NATFW_NONCE object. The NF MUST NOT generate a CREATE- 2275 PROXY message. The NF MUST refresh the CREATE message signaling 2276 session only if a EXTERNAL-PROXY refresh message has been received 2277 first. This also includes tearing down signaling sessions, i.e., 2278 the NF must teardown the CREATE signaling session only if a 2279 EXTERNAL-PROXY message with lifetime set to 0 has been received 2280 first. 2282 The scenario described in this section challenges the data receiver 2283 because it must make a correct assumption about the data sender's 2284 ability to use NSIS NATFW NSLP signaling. It is possible for the DR 2285 to make the wrong assumption in two different ways: 2287 a) the DS is NSIS unaware but the DR assumes the DS to be NSIS 2288 aware and 2290 b) the DS is NSIS aware but the DR assumes the DS to be NSIS 2291 unaware. 2293 Case a) will result in middleboxes blocking the data traffic, since 2294 DS will never send the expected CREATE message. Case b) will result 2295 in the DR successfully requesting proxy mode support by the edge-NAT 2296 or edge-firewall. The edge-NAT/edge-firewall will send CREATE 2297 messages and DS will send CREATE messages as well. Both CREATE 2298 messages are handled as separated NATFW NSLP signaling sessions and 2299 therefore the common rules per NATFW NSLP signaling session apply; 2300 the NATFW_NONCE object is used to differentiate CREATE messages 2301 generated by the edge-NAT/edge-firewall from NI initiated CREATE 2302 messages. It is the NR's responsibility to decide whether to 2303 teardown the EXTERNAL-PROXY signaling sessions in the case where the 2304 data sender's side is NSIS aware, but was incorrectly assumed not to 2305 be so by the DR. It is RECOMMENDED that a DR behind NATs uses the 2306 proxy mode of operation by default, unless the DR knows that the DS 2307 is NSIS aware. The DR MAY cache information about data senders which 2308 it has found to be NSIS aware in past NATFW NSLP signaling sessions. 2310 There is a possible race condition between the RESPONSE message to 2311 the EXTERNAL-PROXY and the CREATE message generated by the edge-NAT. 2312 The CREATE message can arrive earlier than the RESPONSE message. An 2313 NI+ MUST accept CREATE messages generated by the edge-NAT even if the 2314 RESPONSE message to the EXTERNAL-PROXY was not received. 2316 3.7.6.2. Proxying for a Data Receiver 2318 As with data receivers behind middleboxes, data senders behind 2319 middleboxes can require proxy mode support. The issue here is that 2320 there is no NSIS support at the data receiver's side and, by default, 2321 there will be no response to CREATE messages. This scenario requires 2322 the last NSIS NATFW NSLP aware node to terminate the forwarding and 2323 to proxy the response to the CREATE message, meaning that this node 2324 is generating RESPONSE messages. This last node may be an edge-NAT/ 2325 edge-firewall, or any other NATFW NSLP peer, that detects that there 2326 is no NR available (probably as a result of GIST timeouts but there 2327 may be other triggers). 2329 DS Private Address NAT/FW Public Internet NR 2330 NI Space NF no NR 2332 | | | 2333 | CREATE-PROXY | | 2334 |------------------------------>| | 2335 | | | 2336 | RESPONSE[SUCCESS/ERROR] | | 2337 |<------------------------------| | 2338 | | | 2340 Figure 19: Proxy Mode CREATE Message Flow 2342 The processing of CREATE-PROXY messages and RESPONSE messages is 2343 similar to Section 3.7.1, except that forwarding is stopped at the 2344 edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to 2345 NI according to the situation (error/success) and will be the NR for 2346 future NATFW NSLP communication. 2348 The NI can choose the proxy mode of operation although the DR is NSIS 2349 aware. The CREATE-PROXY mode would not configure all NATs and 2350 firewalls along the data path, since it is terminated at the edge- 2351 device. Any device beyond this point will never receive any NATFW 2352 NSLP signaling for this flow. 2354 3.7.6.3. Incremental Deployment using the Proxy Mode 2356 The above sections described the the proxy mode for cases where the 2357 NATFW NSLP is solely deployed at the network edges. However, the 2358 NATFW NSLP might be incrementally deployed first in some network 2359 edges, but later on also in other parts of the network. Using the 2360 proxy mode only, would prevent the NI to determine whether the other 2361 parts of the network have also been upgraded to use the NATFW NSLP. 2362 One way of determining whether the path from the NI to the NR is 2363 NATFW NSLP capable is to use the regular CREATE message and to wait 2364 for a successful response or an error response. This will lead to 2365 extra messages being sent, as a CREATE message in addition to the 2366 anyhow required CREATE-PROXY message is sent from the NI. 2368 The NATFW NSLP allows the usage of the proxy-mode and a further 2369 probing of the path by the edge-NAT or edge-firewall. The NI can 2370 request proxy-mode handling as described, and can set the E flag (see 2371 Section Figure 20) to request the edge-NAT or edge-firewall to probe 2372 the further path for NATFW NSLP enabled NFs or NR. 2374 The edge-NAT or edge-firewall MUST continue to send the CREATE-PROXY 2375 or EXTERNAL-proxy towards the NR, if the received proxy-mode message 2376 has the E flag set, in addition to the regular proxy mode handling. 2377 The edge-NAT or edge-firewall relies on the NTLP measures to 2378 determine whether there is no other NATFW NSLP reachable towards NR. 2379 A failed attempt to forward the request message to the NR will be 2380 silently discarded. A successful attempt of forwarding the request 2381 message to the NR will be acknowledged by the NR with a successful 2382 response message, which is subject to the regular behavior described 2383 in the proxy-mode sections. 2385 3.7.6.4. Deployment Considerations for Edge-Devices 2387 The proxy mode assumes that the edge-NAT or edge-firewall are 2388 properly configured by network operator, i.e., the edge-device is 2389 really the final NAT or firewall of that particular network. There 2390 is currently no known way of letting the NATFW NSLP automatically 2391 detect which of the NAT or firewalls are the actual edge of a 2392 network. Therefore, it is important for the network operator to 2393 configure the edge-NAT or edge-firewall and also to re-configure 2394 these devices if they are not at the edge anymore. For instance, an 2395 edge-NAT is located within an ISP and the ISP chooses to place 2396 another NAT in front of this edge-NAT. In this case, the ISP needs 2397 to reconfigure the old edge-NAT to be a regular NATFW NLSP NAT and to 2398 configure the newly installed NAT to be the edge-NAT. 2400 3.8. De-Multiplexing at NATs 2402 Section 3.7.2 describes how NSIS nodes behind NATs can obtain a 2403 public reachable IP address and port number at a NAT and and how the 2404 resulting mapping rule can be activated by using CREATE messages (see 2405 Section 3.7.1). The information about the public IP address/port 2406 number can be transmitted via an application level signaling protocol 2407 and/or third party to the communication partner that would like to 2408 send data toward the host behind the NAT. However, NSIS signaling 2409 flows are sent towards the address of the NAT at which this 2410 particular IP address and port number is allocated and not directly 2411 to the allocated IP address and port number. The NATFW NSLP 2412 forwarder at this NAT needs to know how the incoming NSLP CREATE 2413 messages are related to reserved addresses, meaning how to de- 2414 multiplex incoming NSIS CREATE messages. 2416 The de-multiplexing method uses information stored at the local NATFW 2417 NSLP node and in the policy rule. The policy rule uses the LE-MRM 2418 MRI source-address (see [I-D.ietf-nsis-ntlp]) as the flow destination 2419 IP address and the network-layer-version (IP-ver) as IP version. The 2420 external IP address at the NAT is stored as the external flow 2421 destination IP address. All other parameters of the policy rule 2422 other than the flow destination IP address are wildcarded if no 2423 NATFW_DTINFO object is included in the EXTERNAL message. The LE-MRM 2424 MRI destination-address MUST NOT be used in the policy rule, since it 2425 is solely a signaling destination address. 2427 If the NATFW_DTINFO object is included in the EXTERNAL message, the 2428 policy rule is filled with further information. The 'dst port 2429 number' field of the NATFW_DTINFO is stored as the flow destination 2430 port number. The 'protocol' field is stored as the flow protocol. 2431 The 'src port number' field is stored as the flow source port number. 2432 The 'data sender's IPv4 address' is stored as the flow source IP 2433 address. Note that some of these field can contain wildcards. 2435 When receiving a CREATE message at the NATFW NSLP it uses the flow 2436 information stored in the MRI to do the matching process. This table 2437 shows the parameters to be compared against each others. Note that 2438 not all parameters can be present in a MRI at the same time. 2440 +-------------------------------+--------------------------------+ 2441 | Flow parameter (Policy Rule) | MRI parameter (CREATE message) | 2442 +-------------------------------+--------------------------------+ 2443 | IP version | network-layer-version | 2444 | | | 2445 | Protocol | IP-protocol | 2446 | | | 2447 | source IP address (w) | source-address (w) | 2448 | | | 2449 | external IP address | destination-address | 2450 | | | 2451 | destination IP address (n/u) | N/A | 2452 | | | 2453 | source port number (w) | L4-source-port (w) | 2454 | | | 2455 | external port number (w) | L4-destination-port (w) | 2456 | | | 2457 | destination port number (n/u) | N/A | 2458 | | | 2459 | IPsec-SPI | ipsec-SPI | 2460 +-------------------------------+--------------------------------+ 2462 Table entries marked with (w) can be wildcarded and entries marked 2463 with (n/u) are not used for the matching. 2465 Table 1 2467 3.9. Reacting to Route Changes 2469 The NATFW NSLP needs to react to route changes in the data path. 2470 This assumes the capability to detect route changes, to perform NAT 2471 and firewall configuration on the new path and possibly to tear down 2472 NATFW NSLP signaling session state on the old path. The detection of 2473 route changes is described in Section 7 of [I-D.ietf-nsis-ntlp] and 2474 the NATFW NSLP relies on notifications about route changes by the 2475 NTLP. This notification will be conveyed by the API between NTLP and 2476 NSLP, which is out of scope of this memo. 2478 A NATFW NSLP node other than the NI or NI+ detecting a route change, 2479 by means described in the NTLP specification or others, generates a 2480 NOTIFY message indicating this change and sends this inbound towards 2481 NI and outbound towards the NR (see also Section 3.7.5.). 2482 Intermediate NFs on the way to the NI can use this information to 2483 decide later if their NATFW NSLP signaling session can be deleted 2484 locally, if they do not receive an update within a certain time 2485 period, as described in Section 3.2.8. It is important to consider 2486 the transport limitations of NOTIFY messages as mandated in 2487 Section 3.7.5. 2489 The NI receiving this NOTIFY message MAY generate a new CREATE or 2490 EXTERNAL message and send it towards the NATFW NSLP signaling 2491 session's NI as for the initial message using the same session ID. 2492 All the remaining processing and message forwarding, such as NSLP 2493 next hop discovery, is subject to regular NSLP processing as 2494 described in the particular sections. Normal routing will guide the 2495 new CREATE or EXTERNAL message to the correct NFs along the changed 2496 route. NFs that were on the original path receiving these new CREATE 2497 or EXTERNAL messages (see also Section 3.10), can use the session ID 2498 to update the existing NATFW NSLP signaling session, whereas NFs that 2499 were not on the original path will create new state for this NATFW 2500 NSLP signaling session. The next section describes how policy rules 2501 are updated. 2503 3.10. Updating Policy Rules 2505 NSIS initiators can request an update of the installed/reserved 2506 policy rules at any time within a NATFW NSLP signaling session. 2507 Updates to policy rules can be required due to node mobility (NI is 2508 moving from one IP address to another), route changes (this can 2509 result in a different NAT mapping at a different NAT device), or the 2510 wish of the NI to simply change the rule. NIs can update policy 2511 rules in existing NATFW NSLP signaling sessions by sending an 2512 appropriate CREATE or EXTERNAL message (similar to Section 3.4) with 2513 modified message routing information (MRI) as compared with that 2514 installed previously, but using the existing session ID to identify 2515 the intended target of the update. With respect to authorization and 2516 authentication, this update CREATE or EXTERNAL message is treated in 2517 exactly the same way as any initial message. Therefore, any node 2518 along in the NATFW NSLP signaling session can reject the update with 2519 an error RESPONSE message, as defined in the previous sections. 2521 The message processing and forwarding is executed as defined in the 2522 particular sections. A NF or the NR receiving an update, simply 2523 replaces the installed policy rules installed in the firewall/NAT. 2524 The local procedures on how to update the MRI in the firewall/NAT is 2525 out of scope of this memo. 2527 4. NATFW NSLP Message Components 2529 A NATFW NSLP message consists of a NSLP header and one or more 2530 objects following the header. The NSLP header is carried in all 2531 NATFW NSLP messages and objects are Type-Length-Value (TLV) encoded 2532 using big endian (network ordered) binary data representations. 2533 Header and objects are aligned to 32 bit boundaries and object 2534 lengths that are not multiples of 32 bits must be padded to the next 2535 higher 32 bit multiple. 2537 The whole NSLP message is carried as payload of a NTLP message. 2539 Note that the notation 0x is used to indicate hexadecimal numbers. 2541 4.1. NSLP Header 2543 All GIST NSLP-Data objects for the NATFW NSLP MUST contain this 2544 common header as the first 32 bits of the object (this is not the 2545 same as the GIST Common Header). It contains two fields, the NSLP 2546 message type and the P Flag, plus two reserved fields. The total 2547 length is 32 bits. The layout of the NSLP header is defined by 2548 Figure 20. 2550 0 1 2 3 2551 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Message type |P|E| reserved | reserved | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 Figure 20: Common NSLP header 2558 The reserved field MUST be set to zero in the NATFW NSLP header 2559 before sending and MUST be ignored during processing of the header. 2561 The defined messages types are: 2563 o 0x1 : CREATE 2565 o 0x2 : EXTERNAL 2567 o 0x3: RESPONSE 2569 o 0x4: NOTIFY 2571 If a message with another type is received, an error RESPONSE of 2572 class 'Protocol error' (0x3) with response code 'Illegal message 2573 type' (0x01) MUST be generated. 2575 The P flag indicates the usage of proxy mode. If proxy mode is used 2576 it MUST be set to 1. Proxy mode usage MUST only be used in 2577 combination with the message types CREATE and EXTERNAL. The P flag 2578 MUST be ignored when processing messages with type RESPONSE or 2579 NOTIFY. 2581 The E flag indicates in proxy mode whether the edge-NAT or edge- 2582 firewall MUST continue sending the message to the NR, i.e. end-to- 2583 end. The E flag MUST only be set to 1 if the P flag is set, 2584 otherwise it MUST be ignored. The E flag MUST only be used in 2585 combination with the message types CREATE and EXTERNAL. The E flag 2586 MUST be ignored when processing messages with type RESPONSE or 2587 NOTIFY. 2589 4.2. NSLP Objects 2591 NATFW NSLP objects use a common header format defined by Figure 21. 2592 The object header contains these fields: two flags, two reserved 2593 bits, the NSLP object type, a reserved field of 4 bits, and the 2594 object length. Its total length is 32 bits. 2596 0 1 2 3 2597 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 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 Figure 21: Common NSLP object header 2604 The object length field contains the total length of the object 2605 without the object header. The unit is a word, consisting of 4 2606 octets. The particular values of type and length for each NSLP 2607 object are listed in the subsequent sections that define the NSLP 2608 objects. An error RESPONSE of class 'Protocol error' (0x3) with 2609 response code 'Wrong object length' (0x07) MUST be generated if the 2610 length given for the object in the object header did not match the 2611 length of the object data present. The two leading bits of the NSLP 2612 object header are used to signal the desired treatment for objects 2613 whose treatment has not been defined in this memo (see 2614 [I-D.ietf-nsis-ntlp], Section A.2.1), i.e., the Object Type has not 2615 been defined. NATFW NSLP uses a subset of the categories defined in 2616 GIST: 2618 o AB=00 ("Mandatory"): If the object is not understood, the entire 2619 message containing it MUST be rejected with an error RESPONSE of 2620 class 'Protocol error' (0x3) with response code 'Unknown object 2621 present' (0x06). 2623 o AB=01 ("Optional"): If the object is not understood, it should be 2624 deleted and then the rest of the message processed as usual. 2626 o AB=10 ("Forward"): If the object is not understood, it should be 2627 retained unchanged in any message forwarded as a result of message 2628 processing, but not stored locally. 2630 The combination AB=11 MUST NOT be used and an error RESPONSE of class 2631 'Protocol error' (0x3) with response code 'Invalid Flag-Field 2632 combination' (0x09) MUST be generated. 2634 The following sections do not repeat the common NSLP object header, 2635 they just list the type and the length. 2637 4.2.1. Signaling Session Lifetime Object 2639 The signaling session lifetime object carries the requested or 2640 granted lifetime of a NATFW NSLP signaling session measured in 2641 seconds. 2643 Type: NATFW_LT (IANA-TBD) 2645 Length: 1 2647 0 1 2 3 2648 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 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 | NATFW NSLP signaling session lifetime | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 Figure 22: Signaling Session Lifetime object 2655 4.2.2. External Address Object 2657 The external address object can be included in RESPONSE messages 2658 (Section 4.3.3) only. It carries the publicly reachable IP address, 2659 and if applicable port number, at an edge-NAT. 2661 Type: NATFW_EXTERNAL-IP (IANA-TBD) 2663 Length: 2 2664 0 1 2 3 2665 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 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 | port number | reserved | 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2669 | IPv4 address | 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 Figure 23: External Address Object for IPv4 addresses 2674 Please note that the field 'port number' MUST be set to 0 if only an 2675 IP address has been reserved, for instance, by a traditional NAT. A 2676 port number of 0 MUST be ignored in processing this object. 2678 4.2.3. External Binding Address Object 2680 The external binding address object can be included in RESPONSE 2681 messages (Section 4.3.3) and EXTERNAL (Section 3.7.2) messages. It 2682 carries one or multiple external binding addresses, and if applicable 2683 port number, for multi-level NATs deployments (for an example see 2684 Section 2.5). The utilization of the information carried in this 2685 object is described in Appendix B. 2687 Type: NATFW_EXTERNAL_BINDING (IANA-TBD) 2689 Length: 1 + number of IPv4 addresses 2691 0 1 2 3 2692 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 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 | port number | reserved | 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 | IPv4 address #1 | 2697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2698 // . . . // 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 | IPv4 address #n | 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 Figure 24: External Binding Address Object 2705 Please note that the field 'port number' MUST be set to 0 if only an 2706 IP address has been reserved, for instance, by a traditional NAT. A 2707 port number of 0 MUST be ignored in processing this object. 2709 4.2.4. Extended Flow Information Object 2711 In general, flow information is kept in the message routing 2712 information (MRI) of the NTLP. Nevertheless, some additional 2713 information may be required for NSLP operations. The 'extended flow 2714 information' object carries this additional information about the 2715 action of the policy rule for firewalls/NATs and contiguous port . 2717 Type: NATFW_EFI (IANA-TBD) 2719 Length: 1 2721 0 1 2 3 2722 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 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | rule action | sub_ports | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 Figure 25: Extended Flow Information 2729 This object has two fields, 'rule action' and 'sub_ports'. The 'rule 2730 action' field has these meanings: 2732 o 0x0001: Allow: A policy rule with this action allows data traffic 2733 to traverse the middlebox and the NATFW NSLP MUST allow NSLP 2734 signaling to be forwarded. 2736 o 0x0002: Deny: A policy rule with this action blocks data traffic 2737 from traversing the middlebox and the NATFW NSLP MUST NOT allow 2738 NSLP signaling to be forwarded. 2740 If the 'rule action' field contains neither 0x0001 nor 0x0002, an 2741 error RESPONSE of class 'Signaling session failure' (0x6) with 2742 response code 'Unknown policy rule action' (0x05) MUST be generated. 2744 The 'sub_ports' field contains the number of contiguous transport 2745 layer ports to which this rule applies. The default value of this 2746 field is 0, i.e., only the port specified in the NTLP's MRM or 2747 NATFW_DTINFO object is used for the policy rule. A value of 1 2748 indicates that additionally to the port specified in the NTLP's MRM 2749 (port1), a second port (port2) is used. This value of port 2 is 2750 calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT 2751 be used in this field and an error RESPONSE of class 'Signaling 2752 session failure' (0x6) with response code 'Requested value in 2753 sub_ports field in NATFW_EFI not permitted' (0x08) MUST be generated. 2754 This two contiguous port numbered ports, can be used by legacy voice 2755 over IP equipment. This legacy equipment assumes two adjacent port 2756 numbers for its RTP/RTCP flows respectively. 2758 4.2.5. Information Code Object 2760 This object carries the response code, which may be indications for 2761 either a successful or failed CREATE or EXTERNAL message depending on 2762 the value of the 'response code' field. 2764 Type: NATFW_INFO (IANA-TBD) 2766 Length: 1 2768 0 1 2 3 2769 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 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | Resv. | Class | Response Code |r|r|r|r| Object Type | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 Figure 26: Information Code Object 2776 The field 'resv.' is reserved for future extensions and MUST be set 2777 to zero when generating such an object and MUST be ignored when 2778 receiving. The 'Object Type' field contains the type of the object 2779 causing the error. The value of 'Object Type' is set to 0, if no 2780 object is concerned. The leading fours bits marked with 'r' are 2781 always set to zero and ignored. The 4 bit class field contains the 2782 severity class. The following classes are defined: 2784 o 0x0: Reserved 2786 o 0x1: Informational (NOTIFY only) 2788 o 0x2: Success 2790 o 0x3: Protocol error 2792 o 0x4: Transient failure 2794 o 0x5: Permanent failure 2796 o 0x6: Signaling session failure 2798 Within each severity class a number of responses values are defined 2800 o Informational: 2802 * 0x01: Route change: possible route change on the outbound path. 2804 * 0x02: Re-authentication required. 2806 * 0x03: NATFW node is going down soon. 2808 * 0x04: NATFW signaling session lifetime expired. 2810 * 0x05: NATFW signaling session terminated. 2812 o Success: 2814 * 0x01: All successfully processed. 2816 o Protocol error: 2818 * 0x01: Illegal message type: the type given in the Message Type 2819 field of the NSLP header is unknown. 2821 * 0x02: Wrong message length: the length given for the message in 2822 the NSLP header does not match the length of the message data. 2824 * 0x03: Bad flags value: an undefined flag or combination of 2825 flags was set in the NSLP header. 2827 * 0x04: Mandatory object missing: an object required in a message 2828 of this type was missing. 2830 * 0x05: Illegal object present: an object was present which must 2831 not be used in a message of this type. 2833 * 0x06: Unknown object present: an object of an unknown type was 2834 present in the message. 2836 * 0x07: Wrong object length: the length given for the object in 2837 the object header did not match the length of the object data 2838 present. 2840 * 0x08: Unknown object field value: a field in an object had an 2841 unknown value. 2843 * 0x09: Invalid Flag-Field combination: An object contains an 2844 invalid combination of flags and/or fields. 2846 * 0x0A: Duplicate object present. 2848 * 0x0B: Received EXTERNAL request message on external side. 2850 o Transient failure: 2852 * 0x01: Requested resources temporarily not available. 2854 o Permanent failure: 2856 * 0x01: Authentication failed. 2858 * 0x02: Authorization failed. 2860 * 0x04: Internal or system error. 2862 * 0x06: No edge-device here. 2864 * 0x07: Did not reach the NR. 2866 o Signaling session failure: 2868 * 0x01: Session terminated asynchronously. 2870 * 0x02: Requested lifetime is too big. 2872 * 0x03: No reservation found matching the MRI of the CREATE 2873 request. 2875 * 0x04: Requested policy rule denied due to policy conflict. 2877 * 0x05: Unknown policy rule action. 2879 * 0x06: Requested rule action not applicable. 2881 * 0x07: NATFW_DTINFO object is required. 2883 * 0x08: Requested value in sub_ports field in NATFW_EFI not 2884 permitted. 2886 * 0x09: Requested IP protocol not supported. 2888 * 0x0A: Plain IP policy rules not permitted -- need transport 2889 layer information. 2891 * 0x0B: ICMP type value not permitted. 2893 * 0x0C: source IP address range is too large. 2895 * 0x0D: destination IP address range is too large. 2897 * 0x0E: source L4-port range is too large. 2899 * 0x0F: destination L4-port range is too large. 2901 * 0x10: Requested lifetime is too small. 2903 * 0x11: Modified lifetime is too big. 2905 * 0x12: Modified lifetime is too small. 2907 4.2.6. Nonce Object 2909 This object carries the nonce value as described in Section 3.7.6. 2911 Type: NATFW_NONCE (IANA-TBD) 2913 Length: 1 2915 0 1 2 3 2916 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 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2918 | nonce | 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 Figure 27: Nonce Object 2923 4.2.7. Message Sequence Number Object 2925 This object carries the MSN value as described in Section 3.5. 2927 Type: NATFW_MSN (IANA-TBD) 2929 Length: 1 2931 0 1 2 3 2932 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 2933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2934 | message sequence number | 2935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 Figure 28: Message Sequence Number Object 2939 4.2.8. Data Terminal Information Object 2941 The 'data terminal information' object carries additional information 2942 MUST be included the EXTERNAL message. EXTERNAL messages are 2943 transported by the NTLP using the Loose-End message routing method 2944 (LE-MRM). The LE-MRM contains only DR's IP address and a signaling 2945 destination address (destination address). This destination address 2946 is used for message routing only and is not necessarily reflecting 2947 the address of the data sender. This object contains information 2948 about (if applicable) DR's port number (the destination port number), 2949 DS' port number (the source port number), the used transport 2950 protocol, the prefix length of the IP address, and DS' IP address. 2952 Type: NATFW_DTINFO (IANA-TBD) 2954 Length: variable. Maximum 3. 2956 0 1 2 3 2957 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 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2959 |I|P|S| reserved | sender prefix | protocol | 2960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2961 : DR port number | DS port number : 2962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2963 : IPsec-SPI : 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | data sender's IPv4 address | 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2968 Figure 29: Data Terminal IPv4 Address Object 2970 The flags are: 2972 o I: I=1 means that 'protocol' should be interpreted. 2974 o P: P=1 means that 'dst port number' and 'src port number' are 2975 present and should be interpreted. 2977 o S: S=1 means that SPI is present and should be interpreted. 2979 The SPI field is only present if S is set. The port numbers are only 2980 present if P is set. The flags P and S MUST NOT be set at the same 2981 time. An error RESPONSE of class 'Protocol error' (0x3) with 2982 response code 'Invalid Flag-Field combination' (0x09) MUST be 2983 generated if they are both set. If either P or S is set, I MUST be 2984 set as well and the protocol field MUST carry the particular 2985 protocol. An error RESPONSE of class 'Protocol error' (0x3) with 2986 response code 'Invalid Flag-Field combination' (0x09) MUST be 2987 generated if S or P is set but I is not set. 2989 The fields MUST be interpreted according to these rules: 2991 o (data) sender prefix: This parameter indicates the prefix length 2992 of the 'data sender's IP address' in bits. For instance, a full 2993 IPv4 address requires 'sender prefix' to be set to 32. A value of 2994 0 indicates an IP address wildcard. 2996 o protocol: The IP protocol field. This field MUST be interpreted 2997 if I=1, otherwise it MUST be set to 0 and MUST be ignored. 2999 o DR port number: The port number at the data receiver (DR), i.e., 3000 the destination port. A value of 0 indicates a port wildcard, 3001 i.e., the destination port number is not known. Any other value 3002 indicates the destination port number. 3004 o DS port number: The port number at the data sender (DS), i.e., the 3005 source port. A value of 0 indicates a port wildcard, i.e., the 3006 source port number is not known. Any other value indicates the 3007 source port number. 3009 o data sender's IPv4 address: The source IP address of the data 3010 sender. This field MUST be set to zero if no IP address is 3011 provided, i.e., a complete wildcard is desired (see dest prefix 3012 field above). 3014 4.2.9. ICMP Types Object 3016 The 'ICMP types' object contains additional information needed to 3017 configure a NAT of firewall with rules to control ICMP traffic. The 3018 object contains a number of values of the ICMP Type field for which a 3019 filter action should be set up: 3021 Type: NATFW_ICMP_TYPES (IANA-TBD) 3023 Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 3025 Where DIV is an integer division. 3027 0 1 2 3 3028 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 3029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3030 | Count | Type | Type | ........ | 3031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3032 | ................ | 3033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3034 | ........ | Type | (Padding) | 3035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3037 Figure 30: ICMP Types Object 3039 The fields MUST be interpreted according to these rules: 3041 count: 8 bit integer specifying the number of 'Type' entries in 3042 the object. 3044 type: 8 bit field specifying an ICMP Type value to which this rule 3045 applies. 3047 padding: Sufficient 0 bits to pad out the last word so that the 3048 total size of object is an even multiple of words. Ignored on 3049 reception. 3051 4.3. Message Formats 3053 This section defines the content of each NATFW NSLP message type. 3054 The message types are defined in Section 4.1. 3056 Basically, each message is constructed of NSLP header and one or more 3057 NSLP objects. The order of objects is not defined, meaning that 3058 objects may occur in any sequence. Objects are marked either with 3059 mandatory (M) or optional (O). Where (M) implies that this 3060 particular object MUST be included within the message and where (O) 3061 implies that this particular object is OPTIONAL within the message. 3062 Objects defined in this memo always carry the flag combination AB=00 3063 in the NSLP object header. An error RESPONSE message of class 3064 'Protocol error' (0x3) with response code 'Mandatory object missing' 3065 (0x04) MUST be generated if a mandatory declared object is missing. 3066 An error RESPONSE message of class 'Protocol error' (0x3) with 3067 response code 'Illegal object present' (0x05) MUST be generated if an 3068 object was present which must not be used in a message of this type. 3069 An error RESPONSE message of class 'Protocol error' (0x3) with 3070 response code 'Duplicate object present' (0x0A) MUST be generated if 3071 an object appears more than once in a message. 3073 Each section elaborates the required settings and parameters to be 3074 set by the NSLP for the NTLP, for instance, how the message routing 3075 information is set. 3077 4.3.1. CREATE 3079 The CREATE message is used to create NATFW NSLP signaling sessions 3080 and to create policy rules. Furthermore, CREATE messages are used to 3081 refresh NATFW NSLP signaling sessions and to delete them. 3083 The CREATE message carries these objects: 3085 o Signaling Session Lifetime object (M) 3087 o Extended flow information object (M) 3089 o Message sequence number object (M) 3091 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 3092 (O) 3094 o ICMP Types Object (O) 3096 The message routing information in the NTLP MUST be set to DS as 3097 source address and DR as destination address. All other parameters 3098 MUST be set according the required policy rule. CREATE messages MUST 3099 be transported by using the path-coupled MRM with direction set to 3100 'downstream' (outbound). 3102 4.3.2. EXTERNAL 3104 The EXTERNAL message is used to a) reserve an external IP address/ 3105 port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to 3106 block incoming data traffic at inbound firewalls. 3108 The EXTERNAL message carries these objects: 3110 o Signaling Session Lifetime object (M) 3112 o Message sequence number object (M) 3114 o Extended flow information object (M) 3116 o Data terminal information object (M) 3118 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 3119 (O) 3121 o ICMP Types Object (O) 3122 o External binding address object (O) 3124 The selected message routing method of the EXTERNAL message depends 3125 on a number of considerations. Section 3.7.2 describes it 3126 exhaustively how to select the correct method. EXTERNAL messages can 3127 be transported via the path-coupled message routing method (PC-MRM) 3128 or via the loose-end message routing method (LE-MRM). In the case of 3129 PC-MRM, the source-address is set to DS' address and the destination 3130 address is set to DR's address, the direction is set to inbound. In 3131 the case of LE-MRM, the destination-address is set to DR's address or 3132 to the signaling destination address. The source-address is set to 3133 DS's address. 3135 4.3.3. RESPONSE 3137 RESPONSE messages are responses to CREATE and EXTERNAL messages. 3138 RESPONSE messages MUST NOT be generated for any other message, such 3139 as NOTIFY and RESPONSE. 3141 The RESPONSE message for the class 'Success' (0x2) carries these 3142 objects: 3144 o Signaling Session Lifetime object (M) 3146 o Message sequence number object (M) 3148 o Information code object (M) 3150 o External address object (O) 3152 o External binding address object (O) 3154 The RESPONSE message for other classes than 'Success' (0x2) carries 3155 these objects: 3157 o Message sequence number object (M) 3159 o Information code object (M) 3161 This message is routed towards the NI hop-by-hop, using existing NTLP 3162 messaging associations. The MRM used for this message MUST be the 3163 same as MRM used by the corresponding CREATE or EXTERNAL message. 3165 4.3.4. NOTIFY 3167 The NOTIFY messages is used to report asynchronous events happening 3168 along the signaled path to other NATFW NSLP nodes. 3170 The NOTIFY message carries this object: 3172 o Information code object (M). 3174 The NOTIFY message is routed towards the NI hop-by-hop using the 3175 existing inbound node messaging association entry within the node's 3176 Message Routing State table. The MRM used for this message MUST be 3177 the same as MRM used by the corresponding CREATE or EXTERNAL message. 3179 5. Security Considerations 3181 Security is of major concern particularly in case of firewall 3182 traversal. This section provides security considerations for the 3183 NAT/firewall traversal and is organized as follows. 3185 In Section 5.1 we describe how the participating entities relate to 3186 each other from a security point of view. This subsection also 3187 motivates a particular authorization model. 3189 Security threats that focus on NSIS in general are described in 3190 [RFC4081] and they are applicable to this document as well. 3192 Finally, we illustrate how the security requirements that were 3193 created based on the security threats can be fulfilled by specific 3194 security mechanisms. These aspects will be elaborated in 3195 Section 5.2. 3197 5.1. Authorization Framework 3199 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 3200 and is, as such, not a two-party protocol. Figure 1 and Figure 2 of 3201 [RFC4081] already depict the possible set of communication patterns. 3202 In this section we will re-evaluate these communication patters with 3203 respect to the NATFW NSLP protocol interaction. 3205 The security solutions for providing authorization have a direct 3206 impact on the treatment of different NSLPs. As it can be seen from 3207 the QoS NSLP [I-D.ietf-nsis-qos-nslp] and the corresponding Diameter 3208 QoS work [I-D.ietf-dime-diameter-qos] accounting and charging seems 3209 to play an important role for QoS reservations, whereas monetary 3210 aspects might only indirectly effect authorization decisions for NAT 3211 and firewall signaling. Hence, there are differences in the semantic 3212 of authorization handling between QoS and NATFW signaling. A NATFW 3213 aware node will most likely want to authorize the entity (e.g., user 3214 or machine) requesting the establishment of pinholes or NAT bindings. 3215 The outcome of the authorization decision is either allowed or 3216 disallowed whereas a QoS authorization decision might indicate that a 3217 different set of QoS parameters is authorization (see 3218 [I-D.ietf-dime-diameter-qos] as an example). 3220 5.1.1. Peer-to-Peer Relationship 3222 Starting with the simplest scenario, it is assumed that neighboring 3223 nodes are able to authenticate each other and to establish keying 3224 material to protect the signaling message communication. The nodes 3225 will have to authorize each other, additionally to the 3226 authentication. We use the term 'Security Context' as a placeholder 3227 for referring to the entire security procedure, the necessary 3228 infrastructure that needs to be in place in order for this to work 3229 (e.g., key management) and the established security related state. 3230 The required long-term key (symmetric or asymmetric keys) used for 3231 authentication are either made available using an out-of-band 3232 mechanism between the two NSIS NATFW nodes or they are dynamically 3233 established using mechanisms not further specified in this document. 3234 Note that the deployment environment will most likely have an impact 3235 on the choice of credentials being used. The choice of these 3236 credentials used is also outside the scope of this document. 3238 +------------------------+ +-------------------------+ 3239 |Network A | | Network B| 3240 | +---------+ +---------+ | 3241 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3242 | | | box 1 | Security | box 2 | | | 3243 | | +---------+ Context +---------+ | | 3244 | | Security | | Security | | 3245 | | Context | | Context | | 3246 | | | | | | 3247 | +--+---+ | | +--+---+ | 3248 | | Host | | | | Host | | 3249 | | A | | | | B | | 3250 | +------+ | | +------+ | 3251 +------------------------+ +-------------------------+ 3253 Figure 31: Peer-to-Peer Relationship 3255 Figure 31 shows a possible relationship between participating NSIS 3256 aware nodes. Host A might be, for example, a host in an enterprise 3257 network that has keying material established (e.g., a shared secret) 3258 with the company's firewall (Middlebox 1). The network administrator 3259 of Network A (company network) has created access control lists for 3260 Host A (or whatever identifiers a particular company wants to use). 3261 Exactly the same procedure might also be used between Host B and 3262 Middlebox 2 in Network B. For the communication between Middlebox 1 3263 and Middlebox 2 a security context is also assumed in order to allow 3264 authentication, authorization and signaling message protection to be 3265 successful. 3267 5.1.2. Intra-Domain Relationship 3269 In larger corporations, for example, a middlebox is used to protect 3270 individual departments. In many cases, the entire enterprise is 3271 controlled by a single (or a small number of) security department, 3272 which gives instructions to the department administrators. In such a 3273 scenario, the previously discussed peer-to-peer relationship might be 3274 prevalent. Sometimes it might be necessary to preserve 3275 authentication and authorization information within the network. As 3276 a possible solution, a centralized approach could be used, whereby an 3277 interaction between the individual middleboxes and a central entity 3278 (for example a policy decision point - PDP) takes place. As an 3279 alternative, individual middleboxes exchange the authorization 3280 decision with another middlebox within the same trust domain. 3281 Individual middleboxes within an administrative domain may exploit 3282 their relationship instead of requesting authentication and 3283 authorization of the signaling initiator again and again. Figure 32 3284 illustrates a network structure which uses a centralized entity. 3286 +-----------------------------------------------------------+ 3287 | Network A | 3288 | +---------+ +---------+ 3289 | +----///--------+ Middle- +------///------++ Middle- +--- 3290 | | Security | box 2 | Security | box 2 | 3291 | | Context +----+----+ Context +----+----+ 3292 | +----+----+ | | | 3293 | | Middle- +--------+ +---------+ | | 3294 | | box 1 | | | | | 3295 | +----+----+ | | | | 3296 | | Security | +----+-----+ | | 3297 | | Context | | Policy | | | 3298 | +--+---+ +-----------+ Decision +----------+ | 3299 | | Host | | Point | | 3300 | | A | +----------+ | 3301 | +------+ | 3302 +-----------------------------------------------------------+ 3304 Figure 32: Intra-domain Relationship 3306 The interaction between individual middleboxes and a policy decision 3307 point (or AAA server) is outside the scope of this document. 3309 5.1.3. End-to-Middle Relationship 3311 The peer-to-peer relationship between neighboring NSIS NATFW NSLP 3312 nodes might not always be sufficient. Network B might require 3313 additional authorization of the signaling message initiator (in 3314 addition to the authorization of the neighboring node). If 3315 authentication and authorization information is not attached to the 3316 initial signaling message then the signaling message arriving at 3317 Middlebox 2 would result in an error message being created, which 3318 indicates the additional authorization requirement. In many cases 3319 the signaling message initiator might already be aware of the 3320 additionally required authorization before the signaling message 3321 exchange is executed. 3323 Figure 33 shows this scenario. 3325 +--------------------+ +---------------------+ 3326 | Network A | |Network B | 3327 | | Security | | 3328 | +---------+ Context +---------+ | 3329 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3330 | | | box 1 | +-------+ box 2 | | | 3331 | | +---------+ | +---------+ | | 3332 | |Security | | | Security | | 3333 | |Context | | | Context | 3334 | | | | | | | 3335 | +--+---+ | | | +--+---+ | 3336 | | Host +----///----+------+ | | Host | | 3337 | | A | | Security | | B | | 3338 | +------+ | Context | +------+ | 3339 +--------------------+ +---------------------+ 3341 Figure 33: End-to-Middle Relationship 3343 5.2. Security Framework for the NAT/Firewall NSLP 3345 The following list of security requirements has been created to 3346 ensure proper secure operation of the NATFW NSLP. 3348 5.2.1. Security Protection between neighboring NATFW NSLP Nodes 3350 Based on the analyzed threats it is RECOMMENDED to provide, between 3351 neighboring NATFW NSLP nodes, the following mechanism: 3353 o data origin authentication 3355 o replay protection 3357 o integrity protection and 3359 o optionally confidentiality protection 3361 It is RECOMMENDED to use the authentication and key exchange security 3362 mechanisms provided in [I-D.ietf-nsis-ntlp] between neighboring nodes 3363 when sending NATFW signaling messages. The proposed security 3364 mechanisms of GIST provide support for authentication and key 3365 exchange in addition to denial of service protection. Depending on 3366 the chosen security protocol, support for multiple authentication 3367 protocols might be provided. If security between neighboring nodes 3368 is desired than the usage of C-MODE for the delivery of data packets 3369 and the usage of D-MODE only to discover the next NATFW NSLP aware 3370 node along the path is highly RECOMMENDED. Almost all security 3371 threats at the NATFW NSLP layer can be prevented by using a mutually 3372 authenticated Transport Layer secured connection and by relying on 3373 authorization by the neighboring NATFW NSLP entities. 3375 The NATFW NSLP relies on an established security association between 3376 neighboring peers to prevent unauthorized nodes to modify or delete 3377 installed state. Between non-neighboring nodes the session ID (SID) 3378 carried in the NTLP is used to show ownership of a NATFW NSLP 3379 signaling session. The session ID MUST be generated in a random way 3380 and thereby prevent an off-path adversary to mount targeted attacks. 3381 Hence, an adversary would have to learn the randomly generated 3382 session ID to perform an attack. In a mobility environment a former 3383 on-path node that is now off-path can perform an attack. Messages 3384 for a particular NATFW NSLP signaling session are handled by the NTLP 3385 to the NATFW NSLP for further processing. Messages carrying a 3386 different session ID not associated with any NATFW NSLP are subject 3387 to the regular processing for new NATFW NSLP signaling sessions. 3389 5.2.2. Security Protection between non-neighboring NATFW NSLP Nodes 3391 Based on the security threats and the listed requirements it was 3392 noted that some threats also demand authentication and authorization 3393 of a NATFW signaling entity (including the initiator) towards a non- 3394 neighboring node. This mechanism mainly demands entity 3395 authentication. The most important information exchanged at the 3396 NATFW NSLP is information related to the establishment for firewall 3397 pinholes and NAT bindings. This information can, however, not be 3398 protected over multiple NSIS NATFW NSLP hops since this information 3399 might change depending on the capability of each individual NATFW 3400 NSLP node. 3402 Some scenarios might also benefit from the usage of authorization 3403 tokens. Their purpose is to associate two different signaling 3404 protocols (e.g., SIP and NSIS) and their authorization decision. 3405 These tokens are obtained by non-NSIS protocols, such as SIP or as 3406 part of network access authentication. When a NAT or firewall along 3407 the path receives the token it might be verified locally or passed to 3408 the AAA infrastructure. Examples of authorization tokens can be 3409 found in RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. Figure 34 shows 3410 an example of this protocol interaction. 3412 An authorization token is provided by the SIP proxy, which acts as 3413 the assertion generating entity and gets delivered to the end host 3414 with proper authentication and authorization. When the NATFW 3415 signaling message is transmitted towards the network, the 3416 authorization token is attached to the signaling messages to refer to 3417 the previous authorization decision. The assertion verifying entity 3418 needs to process the token or it might be necessary to interact with 3419 the assertion granting entity using HTTP (or other protocols). As a 3420 result of a successfully authorization by a NATFW NSLP node, the 3421 requested action is executed and later a RESPONSE message is 3422 generated. 3424 +----------------+ Trust Relationship +----------------+ 3425 | +------------+ |<.......................>| +------------+ | 3426 | | Protocol | | | | Assertion | | 3427 | | requesting | | HTTP, SIP Request | | Granting | | 3428 | | authz | |------------------------>| | Entity | | 3429 | | assertions | |<------------------------| +------------+ | 3430 | +------------+ | Artifact/Assertion | Entity Cecil | 3431 | ^ | +----------------+ 3432 | | | ^ ^| 3433 | | | . || HTTP, 3434 | | | Trust . || other 3435 | API Access | Relationship. || protocols 3436 | | | . || 3437 | | | . || 3438 | | | v |v 3439 | v | +----------------+ 3440 | +------------+ | | +------------+ | 3441 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3442 | | using authz| | Assertion/Artifact | | Verifying | | 3443 | | assertion | | ----------------------- | | Entity | | 3444 | +------------+ | | +------------+ | 3445 | Entity Alice | <---------------------- | Entity Bob | 3446 +----------------+ RESPONSE +----------------+ 3448 Figure 34: Authorization Token Usage 3450 Threats against the usage of authorization tokens have been mentioned 3451 in [RFC4081]. Hence, it is required to provide confidentiality 3452 protection to avoid allowing an eavesdropper to learn the token and 3453 to use it in another NATFW NSLP signaling session (replay attack). 3454 The token itself also needs to be protected against tempering. 3456 5.3. Implementation of NATFW NSLP Security 3458 The prior sections describe how to secure the NATFW NSLP in the 3459 presence of established trust between the various players and the 3460 particular relationships (e.g., intra-domain, end-to-middle, or peer- 3461 to-peer. However, in typcial Internet deployments there is no 3462 established trust, other than granting access to a network, but not 3463 between various sites in the Internet. Furthermore, the NATFW NSLP 3464 may be incrementally deployed with a heavily varying ability of using 3465 authentication and authorization services. 3467 The NATFW NSLP offers a way to keep the authentication and 3468 authorization at the "edge" of the network. The local edge network 3469 can deploy and use any type of AA scheme without the need to have AA 3470 technology match with other edges in the Internet (assuming that 3471 firewalls and NATs are deployed at the edges of the network and not 3472 somewhere in the cores). 3474 Each network edge that has the NATFW NSLP deployed can use EXTERNAL 3475 request message to allow a secure access to the network. This will 3476 allow to open the firewall/NAT on the receiver's side. However, the 3477 edge-devices should not allow to be opened up completely, but to let 3478 DR's to reserve very specific policies. For instance, a DR can 3479 request to reserve an 'allow' policy rule for an incoming TCP 3480 connection for a Jabber file transfer. This reserved policy (see 3481 Figure 15) rule must be activated by matching CREATE request message 3482 (see Figure 15). This mechanism allows that the authentication and 3483 authorization issues are kept locally at the particular edge-network. 3484 On the reverse, the CREATE request message can be handled indepdently 3485 on the the DS side with respect to authentication and authorization. 3487 The usage described in the above paragraph is even simplified for an 3488 incremental deploy: There is no requirement to activate a reserved 3489 policy rule with a CREATE request message. This is completetly 3490 handled by the EXTERNAL-PROXY request message and the associated 3491 CREATE request message. Both of them are handled by the local 3492 authentication and authorization scheme. 3494 6. IAB Considerations on UNSAF 3496 UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a 3497 process at originating endpoints that attempt to determine or fix the 3498 address (and port) by which they are known to another endpoint. 3499 UNSAF proposals, such as STUN [RFC5389] are considered as a general 3500 class of workarounds for NAT traversal and as solutions for scenarios 3501 with no middlebox communication. 3503 This memo specifies a path-coupled middlebox communication protocol, 3504 i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are 3505 not intended as a short-term workaround, but more as a long-term 3506 solution for middlebox communication. In NSIS, endpoints are 3507 involved in allocating, maintaining, and deleting addresses and ports 3508 at the middlebox. However, the full control of addresses and ports 3509 at the middlebox is at the NATFW NSLP daemon located at the 3510 respective NAT. 3512 Therefore, this document addresses the UNSAF considerations in 3513 [RFC3424] by proposing a long-term alternative solution. 3515 7. IANA Considerations 3517 This section provides guidance to the Internet Assigned Numbers 3518 Authority (IANA) regarding registration of values related to the 3519 NATFW NSLP, in accordance with BCP 26 RFC 5226 [RFC5226]. 3521 The NATFW NSLP requires IANA to create a number of new registries: 3523 o NATFW NSLP Message Type Registry 3525 o NATFW NSLP Header Flag Registry 3527 o NSLP Response Code Registry 3529 It also requires registration of new values in a number of 3530 registries: 3532 o NSLP Object Types 3534 o GIST NSLP-ID 3536 o Router Alert Option Values (IPv4 and IPv6) 3538 7.1. NATFW NSLP Message Type Registry 3540 The NATFW NSLP Message Type is a 8 bit value. The allocation of 3541 values for new message types requires IETF Review. Updates and 3542 deletion of values from the registry is not possible. This 3543 specification defines four NATFW NSLP message types, which form the 3544 initial contents of this registry. IANA is requested to add these 3545 four NATFW NSLP Message Types: CREATE (0x1), EXTERNAL (0x2), RESPONSE 3546 (0x3), and NOTIFY (0x4). The registry entries consist of Name of 3547 Message Type, value, and reference to the relevant section. 3549 7.2. NATFW NSLP Header Flag Registry 3551 NATFW NSLP messages have a messages-specific 8 bit flags/reserved 3552 field in their header. The registration of flags is subject to IANA 3553 registration. The allocation of values for flag types requires IETF 3554 Review. Updates and deletion of values from the registry is not 3555 possible. This specification defines only two flags in Section 4.1, 3556 the E flag and the P flag. The registry entries consist of Name of 3557 the Flag and reference to the relevant section. 3559 7.3. NSLP Object Type Registry 3561 [ Delete the part in square brackets if registry is already created 3562 by another NSLP: 3564 A new registry is to be created for NSLP Message Objects. This is a 3565 12-bit field (giving values from 0 to 4095). This registry is shared 3566 between a number of NSLPs. Allocation policies are as follows: 3568 0-1023: IETF Review 3570 1024-1999: Specification Required 3572 2000-2047: Private/Experimental Use 3574 2048-4095: Reserved 3576 When a new object is defined, the extensibility bits (A/B) must also 3577 be defined. ] 3579 This document defines 9 objects for the NATFW NSLP: NATFW_LT, 3580 NATFW_EXTERNAL-IP, NATFW_EXTERNAL_BINDING, NATFW_EFI, NATFW_INFO, 3581 NATFW_NONCE, NATFW_MSN, NATFW_DTINFO, NATFW_ICMP_TYPES. IANA is 3582 request to assigned values for them from NSLP Object Type registry 3583 and to replace the corresponding IANA-TBD tags in this memo with the 3584 numeric values. 3586 7.4. NSLP Response Code Registry 3588 In addition it defines a number of Response Codes for the NATFW NSLP. 3589 These can be found in Section 4.2.5 and are to be assigned values 3590 from NSLP Response Code registry. The allocation of new values for 3591 Response Codes Codes requires IETF Review. IANA is request to 3592 assigned values for them from NSLP Response Code registry as given in 3593 Section 4.2.5for the severity class and also for the number of 3594 responses values per each severity class. The registry entries 3595 consist out of Name of class or response code, value, and reference 3596 to the relevant section. 3598 7.5. NSLP IDs and Router Alert Option Values 3600 GIST NSLPID 3602 This specification defines an NSLP for use with GIST and thus 3603 requires an assigned NSLP identifier. IANA is requested to add one 3604 new value to the NSLP Identifiers (NSLPID) registry defined in 3605 [I-D.ietf-nsis-ntlp] for the NATFW NSLP. 3607 IPv4 and IPv6 Router Alert Option (RAO) value 3609 The GIST specification also requires that each NSLP-ID be associated 3610 with specific Router Alert Option (RAO) value. For the purposes of 3611 the NATFW NSLP, just a single IPv4 RAO value and a single IPv6 RAO 3612 must be allocated. 3614 8. Acknowledgments 3616 We would like to thank the following individuals for their 3617 contributions to this document at different stages: 3619 o Marcus Brunner and Henning Schulzrinne for their work on IETF 3620 drafts which lead us to start with this document; 3622 o Miquel Martin for his large contribution on the initial version of 3623 this document and one of the first prototype implemenations; 3625 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3626 NAT/firewall threats draft; 3628 o Henning Peters for his comments and suggestions; 3630 o and the NSIS working group. 3632 9. References 3634 9.1. Normative References 3636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3637 Requirement Levels", BCP 14, RFC 2119, March 1997. 3639 [I-D.ietf-nsis-ntlp] 3640 Schulzrinne, H. and M. Stiemerling, "GIST: General 3641 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 3642 (work in progress), June 2009. 3644 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 3645 August 1996. 3647 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3648 Requirements for Security", BCP 106, RFC 4086, June 2005. 3650 9.2. Informative References 3652 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3653 Bosch, "Next Steps in Signaling (NSIS): Framework", 3654 RFC 4080, June 2005. 3656 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 3657 RFC 3726, April 2004. 3659 [I-D.ietf-nsis-qos-nslp] 3660 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 3661 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 3662 (work in progress), January 2010. 3664 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 3665 A. Rayhan, "Middlebox communication architecture and 3666 framework", RFC 3303, August 2002. 3668 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 3669 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 3671 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3672 Translator (NAT) Terminology and Considerations", 3673 RFC 2663, August 1999. 3675 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 3676 Issues", RFC 3234, February 2002. 3678 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 3679 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 3680 Functional Specification", RFC 2205, September 1997. 3682 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 3683 Self-Address Fixing (UNSAF) Across Network Address 3684 Translation", RFC 3424, November 2002. 3686 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3687 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3688 May 2008. 3690 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3691 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3692 October 2008. 3694 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 3695 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 3696 J., and S. Waldbusser, "Terminology for Policy-Based 3697 Management", RFC 3198, November 2001. 3699 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 3700 "Session Authorization Policy Element", RFC 3520, 3701 April 2003. 3703 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 3704 Session Set-up with Media Authorization", RFC 3521, 3705 April 2003. 3707 [I-D.ietf-dime-diameter-qos] 3708 Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., 3709 and G. Zorn, "Diameter Quality of Service Application", 3710 draft-ietf-dime-diameter-qos-13 (work in progress), 3711 October 2009. 3713 [rsvp-firewall] 3714 Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, 3715 "RSVP as firewall Signalling Protocol", Proceedings of the 3716 6th IEEE Symposium on Computers and Communications, 3717 Hammamet, Tunisia pp. 57 to 62, IEEE Computer Society 3718 Press, July 2001. 3720 Appendix A. Selecting Signaling Destination Addresses for EXTERNAL 3722 As with all other message types, EXTERNAL messages need a reachable 3723 IP address of the data sender on the GIST level. For the path- 3724 coupled MRM the source-address of GIST is the reachable IP address 3725 (i.e., the real IP address of the data sender, or a wildcard). While 3726 this is straight forward, it is not necessarily so for the loose-end 3727 MRM. Many applications do not provide the IP address of the 3728 communication counterpart, i.e., either the data sender or both a 3729 data sender and receiver. For the EXTERNAL messages, the case of 3730 data sender is of interest only. The rest of this section gives 3731 informational guidance about determining a good destination-address 3732 of the LE-MRM in GIST for EXTERNAL messages. 3734 This signaling destination address (SDA, the destination-address in 3735 GIST) can be the data sender, but for applications which do not 3736 provide an address upfront, the destination address has to be chosen 3737 independently, as it is unknown at the time when the NATFW NSLP 3738 signaling has to start. Choosing the 'correct' destination IP 3739 address may be difficult and it is possible that there is no 'right 3740 answer' for all applications relying on the NATFW NSLP. 3742 Whenever possible it is RECOMMENDED to chose the data sender's IP 3743 address as SDA. It is necessary to differentiate between the 3744 received IP addresses on the data sender. Some application level 3745 signaling protocols (e.g., SIP) have the ability to transfer multiple 3746 contact IP addresses of the data sender. For instance, private IP 3747 address, public IP address at NAT, and public IP address at a relay. 3748 It is RECOMMENDED to use all non-private IP addresses as SDAs. 3750 A different SDA must be chosen, if the IP address of the data sender 3751 is unknown. This can have multiple reasons: The application level 3752 signaling protocol cannot determine any data sender IP address at 3753 this point of time or the data receiver is server behind a NAT, i.e., 3754 accepting inbound packets from any host. In this case, the NATFW 3755 NSLP can be instructed to use the public IP address of an application 3756 server or any other node. Choosing the SDA in this case is out of 3757 the scope of the NATFW NSLP and depends on the application's choice. 3758 The local network can provide a network-SDA, i.e., a SDA which is 3759 only meaningful to the local network. This will ensure that GIST 3760 packets with destination-address set to this network-SDA are going to 3761 be routed to a edge-NAT or edge-firewall. 3763 Appendix B. Usage of External Binding Addresses 3765 The NATFW_EXTERNAL_BINDING object carries information, that has a 3766 different utility the information carried within the 3767 NATFW_EXTERNAL-IP object. The NATFW_EXTERNAL-IP object has the 3768 public IP address and potentially port numbers that can be used by 3769 the application at the NI to be reachable via the public Internet. 3770 However, there are cases were various NIs are located behind the same 3771 public NAT, but are subject to a multi-level NAT deployment, as shown 3772 in Figure 35. They can use their public IP address port assigned to 3773 them to communicate between each other (e.g., NI with NR1 and NR2) 3774 but they are forced to send their traffic through the edge-NAT, even 3775 though there is a short way possible. 3777 NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP) 3778 | 3779 NR1--192.168.0/24-- NAT3-- 3780 | 3781 NR2 10.1.2.3 3783 Figure 35: Multi-Level NAT Scenarion 3785 Figure 35 shows an example that is explored here: 3787 1. NI -> NR1: Both NI and NR1 does EXTERNAL towards NAT2 and get an 3788 external address+port binding. Then they exchange that external 3789 binding and all traffic gets pinned to NAT2 instead of taking 3790 shortes path by NAT1 to NAT3 directly. However to do that NR1 3791 and NI both needs to be aware that they also have the address on 3792 the external side of NAT1 and NAT3 respectively. If there is ICE 3793 deployed and there is actually a STUN server in the 10/8 network 3794 configured, it is possible to get the shorter path to work. The 3795 NATFW NSLP provides all external addresses in the 3796 NATFW_EXTERNAL_BINDING towards the public network it could allow 3797 for optimizations. 3799 2. For the case NI -> NR2 is even more obvious. Pinning this to 3800 NAT2 is an important fall back, but allowing for trying for a 3801 direct path between NAT1 and NAT3 might be worth it. 3803 Please note that if there are overlapping address domains between NR 3804 and the public Internet the regular routing will not necessary allow 3805 sending the packet to the right domain. 3807 Appendix C. Applicability Statement on Data Receivers behind Firewalls 3809 Section 3.7.2 describes how data receivers behind middleboxes can 3810 instruct inbound firewalls/NATs to forward NATFW NSLP signaling 3811 towards them. Finding an inbound edge-NAT in address environment 3812 with NAT'ed addresses is quite easy. It is only required to find 3813 some edge-NAT, as the data traffic will be route-pinned to the NAT. 3814 Locating the appropriate edge-firewall with the PC-MRM, sent inbound 3815 is difficult. For cases with a single, symmetric route from the 3816 Internet to the data receiver, it is quite easy; simply follow the 3817 default route in the inbound direction. 3819 +------+ Data Flow 3820 +-------| EFW1 +----------+ <=========== 3821 | +------+ ,--+--. 3822 +--+--+ / \ 3823 NI+-----| FW1 | (Internet )----NR+/NI/DS 3824 NR +--+--+ \ / 3825 | +------+ `--+--' 3826 +-------| EFW2 +----------+ 3827 +------+ 3829 ~~~~~~~~~~~~~~~~~~~~~> 3830 Signaling Flow 3832 Figure 36: Data receiver behind multiple, parallel located firewalls 3834 When a data receiver, and thus NR, is located in a network site that 3835 is multihomed with several independently firewalled connections to 3836 the public Internet (as shown in Figure 36), the specific firewall 3837 through which the data traffic will be routed has to be ascertained. 3838 NATFW NSLP signaling messages sent from the NI+/NR during the 3839 EXTERNAL message exchange towards the NR+ must be routed by the NTLP 3840 to the edge-firewall that will be passed by the data traffic as well. 3841 The NTLP would need to be aware about the routing within the Internet 3842 to determine the path between DS and DR. Out of this, the NTLP could 3843 determine which of the edge-firewalls, either EFW1 or EFW2, must be 3844 selected to forward the NATFW NSLP signaling. Signaling to the wrong 3845 edge-firewall, as shown in Figure 36, would install the NATFW NSLP 3846 policy rules at the wrong device. This causes either a blocked data 3847 flow (when the policy rule is 'allow') or an ongoing attack (when the 3848 policy rule is 'deny'). Requiring the NTLP to know all about the 3849 routing within the Internet is definitely a tough challenge and 3850 usually not possible. In such described case, the NTLP must 3851 basically give up and return an error to the NSLP level, indicating 3852 that the next hop discovery is not possible. 3854 Appendix D. Firewall and NAT Resources 3856 This section gives some examples on how NATFW NSLP policy rules could 3857 be mapped to real firewall or NAT resources. The firewall rules and 3858 NAT bindings are described in a natural way, i.e., in a way one will 3859 find it in common implementations. 3861 D.1. Wildcarding of Policy Rules 3863 The policy rule/MRI to be installed can be wildcarded to some degree. 3864 Wildcarding applies to IP address, transport layer port numbers, and 3865 the IP payload (or next header in IPv6). Processing of wildcarding 3866 splits into the NTLP and the NATFW NSLP layer. The processing at the 3867 NTLP layer is independent of the NSLP layer processing and per layer 3868 constraints apply. For wildcarding in the NTLP see Section 5.8 of 3869 [I-D.ietf-nsis-ntlp]. 3871 Wildcarding at the NATFW NSLP level is always a node local policy 3872 decision. A signaling message carrying a wildcarded MRI (and thus 3873 policy rule) arriving at an NSLP node can be rejected if the local 3874 policy does not allow the request. For instance, a MRI with IP 3875 addresses set (not wildcarded), transport protocol TCP, and TCP port 3876 numbers completely wildcarded. Now the local policy allows only 3877 requests for TCP with all ports set and not wildcarded. The request 3878 is going to be rejected. 3880 D.2. Mapping to Firewall Rules 3882 This section describes how a NSLP policy rule signaled with a CREATE 3883 message is mapped to a firewall rule. The MRI is set as follows: 3885 o network-layer-version=IPv4 3887 o source-address=192.0.2.100, prefix-length=32 3889 o destination-address=192.0.50.5, prefix-length=32 3891 o IP-protocol=UDP 3893 o L4-source-port=34543, L4-destination-port=23198 3895 The NATFW_EFI object is set to action=allow and sub_ports=0. 3897 The resulting policy rule (firewall rule) to be installed might look 3898 like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198 3900 D.3. Mapping to NAT Bindings 3902 This section describes how a NSLP policy rule signaled with a 3903 EXTERNAL message is mapped to a NAT binding. It is assumed that the 3904 EXTERNAL message is sent by a NI+ being located behind a NAT and does 3905 contain a NATFW_DTINFO object. The MRI is set following using the 3906 signaling destination address, since the IP address of the real data 3907 sender is not known: 3909 o network-layer-version=IPv4 3911 o source-address= 192.168.5.100 3913 o destination-address=SDA 3915 o IP-protocol=UDP 3917 The NATFW_EFI object is set to action=allow and sub_ports=0. The 3918 NATFW_DTINFO object contains these parameters: 3920 o P=1 3922 o dest prefix=0 3924 o protocol=UDP 3926 o dst port number = 20230, src port number=0 3928 o src IP=0.0.0.0 3930 The edge-NAT allocates the external IP 192.0.2.79 and port 45000. 3932 The resulting policy rule (NAT binding) to be installed could look 3933 like: translate udp from any to 192.0.2.79 port=45000 to 3934 192.168.5.100 port=20230 3936 D.4. NSLP Handling of Twice-NAT 3938 The dynamic configuration of twice-NATs requires application level 3939 support, as stated in Section 2.5. The NATFW NSLP cannot be used for 3940 configuring twice-NATs if application level support is needed. 3941 Assuming application level support performing the configuration of 3942 the twice-NAT and the NATFW NSLP being installed at this devices, the 3943 NATFW NSLP must be able to traverse it. The NSLP is probably able to 3944 traverse the twice-NAT, as any other data traffic, but the flow 3945 information stored in the NTLP's MRI will be invalidated through the 3946 translation of source and destination address. The NATFW NSLP 3947 implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP 3948 signaling messages as any other NATFW NSLP node does. For the given 3949 signaling flow, the NATFW NSLP node MUST look up the corresponding IP 3950 address translation and modify the NTLP/NSLP signaling accordingly. 3951 The modification results in an updated MRI with respect to the source 3952 and destination IP addresses. 3954 Appendix E. Protocols Numbers for Testing 3956 NOTE for the RFC editor: This section MUST be removed before 3957 publication. 3959 This section defines temporarily used values of the NATFW NSLP for 3960 testing the different implementations. 3962 Values for the NATFW NSLP message types: 3964 o CREATE: 0x01 3966 o EXTERNAL: 0x02 3968 o RESPONSE: 0x03 3970 o NOTIFY: 0x04 3972 Values for the NSLP object types 3974 o NATFW_LT: 0x00F1 3976 o NATFW_EXTERNAL-IP: 0x00F2 3978 o NATFW_EFI: 0x00F3 3980 o NATFW_INFO: 0x00F4 3982 o NATFW_NONCE: 0x00F5 3984 o NATFW_MSN: 0x00F6 3986 o NATFW_DTINFO: 0x00F7 3988 o NATFW_ICMP_TYPES: 0x00F9 3990 1345 3992 Authors' Addresses 3994 Martin Stiemerling 3995 NEC Europe Ltd. and University of Goettingen 3996 Kurfuersten-Anlage 36 3997 Heidelberg 69115 3998 Germany 4000 Phone: +49 (0) 6221 4342 113 4001 Email: stiemerling@nw.neclab.eu 4003 Hannes Tschofenig 4004 Nokia Siemens Networks 4005 Linnoitustie 6 4006 Espoo 02600 4007 Finland 4009 Phone: +358 (50) 4871445 4010 Email: Hannes.Tschofenig@nsn.com 4011 URI: http://www.tschofenig.com 4013 Cedric Aoun 4014 Paris 4015 France 4017 Email: cedric@caoun.net 4019 Elwyn Davies 4020 Folly Consulting 4021 Soham 4022 UK 4024 Phone: +44 7889 488 335 4025 Email: elwynd@dial.pipex.com