idnits 2.17.1 draft-ietf-nsis-nslp-natfw-25.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2010) is 5106 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Success' is mentioned on line 4035, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group M. Stiemerling 3 Internet-Draft NEC 4 Intended status: Experimental H. Tschofenig 5 Expires: October 29, 2010 Nokia Siemens Networks 6 C. Aoun 8 E. Davies 9 Folly Consulting 10 April 27, 2010 12 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 13 draft-ietf-nsis-nslp-natfw-25.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 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). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on October 29, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 6 76 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 9 77 1.3. Notes on the Experimental Status . . . . . . . . . . . . . 10 78 1.4. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 11 79 1.5. General Scenario for NATFW Traversal . . . . . . . . . . . 12 81 2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 14 82 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 14 83 2.2. NAT with two Private Networks . . . . . . . . . . . . . . 15 84 2.3. NAT with Private Network on Sender Side . . . . . . . . . 16 85 2.4. NAT with Private Network on Receiver Side Scenario . . . . 16 86 2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . . 17 87 2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 18 88 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 19 89 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 20 91 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 21 92 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 21 93 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 22 94 3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 22 95 3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 23 96 3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 24 97 3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 26 98 3.2.5. State and Error Maintenance . . . . . . . . . . . . . 26 99 3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 27 100 3.2.7. Classification of RESPONSE Messages . . . . . . . . . 27 101 3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 28 102 3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 29 103 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 29 104 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 33 105 3.6. Authentication, Authorization, and Policy Decisions . . . 34 106 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 34 107 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 34 108 3.7.2. Reserving External Addresses . . . . . . . . . . . . . 37 109 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 45 110 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 46 111 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 48 112 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 50 113 3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 54 114 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 56 115 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 56 117 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 58 118 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 58 119 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 59 120 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 60 121 4.2.2. External Address Object . . . . . . . . . . . . . . . 60 122 4.2.3. External Binding Address Object . . . . . . . . . . . 61 123 4.2.4. Extended Flow Information Object . . . . . . . . . . . 62 124 4.2.5. Information Code Object . . . . . . . . . . . . . . . 63 125 4.2.6. Nonce Object . . . . . . . . . . . . . . . . . . . . . 66 126 4.2.7. Message Sequence Number Object . . . . . . . . . . . . 66 127 4.2.8. Data Terminal Information Object . . . . . . . . . . . 67 128 4.2.9. ICMP Types Object . . . . . . . . . . . . . . . . . . 68 129 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 69 130 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 70 131 4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 70 132 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 71 133 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 72 135 5. Security Considerations . . . . . . . . . . . . . . . . . . . 73 136 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 73 137 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 73 138 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 74 139 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 75 140 5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 76 141 5.2.1. Security Protection between neighboring NATFW NSLP 142 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 76 143 5.2.2. Security Protection between non-neighboring NATFW 144 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 77 145 5.3. Implementation of NATFW NSLP Security . . . . . . . . . . 78 147 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 80 149 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 150 7.1. NATFW NSLP Message Type Registry . . . . . . . . . . . . . 81 151 7.2. NATFW NSLP Header Flag Registry . . . . . . . . . . . . . 81 152 7.3. NSLP Object Type Registry . . . . . . . . . . . . . . . . 81 153 7.4. NSLP Response Code Registry . . . . . . . . . . . . . . . 82 154 7.5. NSLP IDs and Router Alert Option Values . . . . . . . . . 82 156 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 158 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 159 9.1. Normative References . . . . . . . . . . . . . . . . . . . 85 160 9.2. Informative References . . . . . . . . . . . . . . . . . . 85 162 Appendix A. Selecting Signaling Destination Addresses for 163 EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 87 165 Appendix B. Usage of External Binding Addresses . . . . . . . . . 88 167 Appendix C. Applicability Statement on Data Receivers behind 168 Firewalls . . . . . . . . . . . . . . . . . . . . . . 89 170 Appendix D. Firewall and NAT Resources . . . . . . . . . . . . . 91 171 D.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 91 172 D.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 91 173 D.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 92 174 D.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 92 176 Appendix E. Example for Receiver Proxy Case . . . . . . . . . . . 94 178 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 98 180 1. Introduction 182 1.1. Scope and Background 184 Firewalls and Network Address Translators (NAT) have both been used 185 throughout the Internet for many years, and they will remain present 186 for the foreseeable future. Firewalls are used to protect networks 187 against certain types of attacks from internal networks and the 188 Internet, whereas NATs provide a virtual extension of the IP address 189 space. Both types of devices may be obstacles to some applications, 190 since they only allow traffic created by a limited set of 191 applications to traverse them, typically those that use protocols 192 with relatively predetermined and static properties (e.g., most HTTP 193 traffic, and other client/server applications). Other applications, 194 such as IP telephony and most other peer-to-peer applications, which 195 have more dynamic properties, create traffic that is unable to 196 traverse NATs and firewalls unassisted. In practice, the traffic of 197 many applications cannot traverse autonomous firewalls or NATs, even 198 when they have additional functionality which attempts to restore the 199 transparency of the network. 201 Several solutions to enable applications to traverse such entities 202 have been proposed and are currently in use. Typically, application 203 level gateways (ALG) have been integrated with the firewall or NAT to 204 configure the firewall or NAT dynamically. Another approach is 205 middlebox communication (MIDCOM). In this approach, ALGs external to 206 the firewall or NAT configure the corresponding entity via the MIDCOM 207 protocol [RFC3303]. Several other work-around solutions are 208 available, such as STUN [RFC5389]. However, all of these approaches 209 introduce other problems that are generally hard to solve, such as 210 dependencies on the type of NAT implementation (full-cone, symmetric, 211 etc), or dependencies on certain network topologies. 213 NAT and firewall (NATFW) signaling shares a property with Quality of 214 Service (QoS) signaling. The signaling of both must reach any device 215 on the data path that is involved in, respectively, NATFW or QoS 216 treatment of data packets. This means, that for both, NATFW and QoS, 217 it is convenient if signaling travels path-coupled, meaning that the 218 signaling messages follow exactly the same path that the data packets 219 take. RSVP [RFC2205] is an example of a current QoS signaling 220 protocol that is path-coupled. [rsvp-firewall] proposes the use of 221 RSVP as firewall signaling protocol but does not include NATs. 223 This memo defines a path-coupled signaling protocol for NAT and 224 firewall configuration within the framework of NSIS, called the NATFW 225 NSIS Signaling Layer Protocol (NSLP). The general requirements for 226 NSIS are defined in [RFC3726] and the general framework of NSIS is 227 outlined in [RFC4080]. It introduces the split between an NSIS 228 transport layer and an NSIS signaling layer. The transport of NSLP 229 messages is handled by an NSIS Network Transport Layer Protocol 230 (NTLP, with General Internet Signaling Transport (GIST) 231 [I-D.ietf-nsis-ntlp] being the implementation of the abstract NTLP). 232 The signaling logic for QoS and NATFW signaling is implemented in the 233 different NSLPs. The QoS NSLP is defined in 234 [I-D.ietf-nsis-qos-nslp]. 236 The NATFW NSLP is designed to request the dynamic configuration of 237 NATs and/or firewalls along the data path. Dynamic configuration 238 includes enabling data flows to traverse these devices without being 239 obstructed, as well as blocking of particular data flows at inbound 240 firewalls. Enabling data flows requires the loading of firewall 241 rules with an action that allows the data flow packets to be 242 forwarded and creating NAT bindings. Blocking of data flows requires 243 the loading of firewalls rules with an action that will deny 244 forwarding of the data flow packets. A simplified example for 245 enabling data flows: A source host sends a NATFW NSLP signaling 246 message towards its data destination. This message follows the data 247 path. Every NATFW NSLP-enabled NAT/firewall along the data path 248 intercepts this message, processes them, and configures itself 249 accordingly. Thereafter, the actual data flow can traverse all these 250 configured firewalls/NATs. 252 It is necessary to distinguish between two different basic scenarios 253 when operating the NATFW NSLP, independent of the type of the 254 middleboxes to be configured. 256 1. Both, data sender and data receiver, are NSIS NATFW NSLP aware. 257 This includes the cases where the data sender is logically 258 decomposed from the initiator of the NSIS signaling (the so- 259 called NSIS initiator) or the data receiver logically decomposed 260 from the receiver of the NSIS signaling (the so-called NSIS 261 receiver), but both sides support NSIS. This scenario assumes 262 deployment of NSIS all over the Internet, or at least at all NATs 263 and firewalls. This scenario is used as base assumption, if not 264 otherwise noted. 266 2. Only one end host or region of the network is NSIS NATFW NSLP 267 aware, either data receiver or data sender. This scenario is 268 referred to as proxy mode. 270 The NATFW NSLP has two basic signaling messages which are sufficient 271 to cope with the various possible scenarios likely to be encountered 272 before and after widespread deployment of NSIS: 274 CREATE message: Sent by the data sender for configuring a path 275 outbound from a data sender to a data receiver. 277 EXTERNAL message: Used by data receiver to locate inbound NATs/ 278 firewalls and prime them to expect inbound signaling and at NATs 279 to pre-allocate a public address. This is used for data receivers 280 behind these devices to enable their reachability. 282 CREATE and EXTERNAL messages are sent by the NSIS initiator (NI) 283 towards the NSIS responder (NR). Both type of messages are 284 acknowledged by a subsequent RESPONSE message. This RESPONSE message 285 is generated by the NR if the requested configuration can be 286 established, otherwise the NR or any of the NSIS forwarders (NFs) can 287 also generate such a message if an error occurs. NFs and the NR can 288 also generate asynchronous messages to notify the NI, the so called 289 NOTIFY messages. 291 If the data receiver resides in a private addressing realm or behind 292 a firewall, and needs to preconfigure the edge-NAT/edge-firewall to 293 provide a (publicly) reachable address for use by the data sender, a 294 combination of EXTERNAL and CREATE messages is used. 296 During the introduction of NSIS, it is likely that one or the other 297 of the data sender and receiver will not be NSIS aware. In these 298 cases, the NATFW NSLP can utilize NSIS aware middleboxes on the path 299 between the data sender and data receiver to provide proxy NATFW NSLP 300 services (i.e., the proxy mode). Typically, these boxes will be at 301 the boundaries of the realms in which the end hosts are located. 303 The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in 304 NSIS entities. NTLP state allows signaling messages to travel in the 305 forward (outbound) and the reverse (inbound) direction along the path 306 between a NAT/firewall NSLP sender and a corresponding receiver. 307 This state is managed using a soft-state mechanism, i.e., it expires 308 unless it is refreshed from time to time. The NAT bindings and 309 firewall rules being installed during the state setup are bound to 310 the particular signaling session. However, the exact local 311 implementation of the NAT bindings and firewall rules are NAT/ 312 firewall specific and it is out of scope of this memo. 314 This memo is structured as follows. Section 2 describes the network 315 environment for NATFW NSLP signaling. Section 3 defines the NATFW 316 signaling protocol and Section 4 defines the message components and 317 the overall messages used in the protocol. The remaining parts of 318 the main body of the document cover security considerations 319 Section 5, IAB considerations on UNilateral Self-Address Fixing 320 (UNSAF) [RFC3424] in Section 6 and IANA considerations in Section 7. 321 Please note that readers familiar with firewalls and NATs and their 322 possible location within networks can safely skip Section 2. 324 1.2. Terminology and Abbreviations 326 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 327 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 328 document are to be interpreted as described in [RFC2119]. 330 This document uses a number of terms defined in [RFC3726] and 331 [RFC4080]. The following additional terms are used: 333 o Policy rule: A policy rule is "a basic building block of a policy- 334 based system. It is the binding of a set of actions to a set of 335 conditions - where the conditions are evaluated to determine 336 whether the actions are performed" [RFC3198]. In the context of 337 NSIS NATFW NSLP, the conditions are the specification of a set of 338 packets to which the rule is applied. The set of actions always 339 contains just a single element per rule, and is limited to either 340 action "deny" or action "allow". 342 o Reserved policy rule: A policy rule stored at NATs or firewalls 343 for activation by a later, different signaling exchange. This 344 type of policy rule is kept in the NATFW NSLP and is not loaded 345 into the firewall or NAT engine, i.e., it does not affect the data 346 flow handling. 348 o Installed policy rule: A policy rule in operation at NATs or 349 firewalls. This type of rule is kept in the NATFW NSLP and is 350 loaded into the firewall or NAT engine, i.e., it is affecting the 351 data flow. 353 o Remembered policy rule: A policy rule stored at NATs and firewalls 354 for immediate use, as soon as the signaling exchange is 355 successfully completed. 357 o Firewall: A packet filtering device that matches packets against a 358 set of policy rules and applies the actions. 360 o Network Address Translator: Network Address Translation is a 361 method by which IP addresses are mapped from one IP address realm 362 to another, in an attempt to provide transparent routing between 363 hosts (see [RFC2663]). Network Address Translators are devices 364 that perform this work by modifying packets passing through them. 366 o Data Receiver (DR): The node in the network that is receiving the 367 data packets of a flow. 369 o Data Sender (DS): The node in the network that is sending the data 370 packets of a flow. 372 o NATFW NSLP peer or peer: An NSIS NATFW NSLP node with which an 373 NTLP adjacency has been created as defined in 374 [I-D.ietf-nsis-ntlp]. 376 o NATFW NSLP signaling session or signaling session: A signaling 377 session defines an association between the NI, NFs, and the NR 378 related to a data flow. All the NATFW NSLP peers on the path, 379 including the NI and the NR, use the same identifier to refer to 380 the state stored for the association. The same NI and NR may have 381 more than one signaling session active at any time. The state for 382 NATFW NSLP consists of NSLP state and associated policy rules at a 383 middlebox. 385 o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP 386 address which is reachable from the public Internet. 388 o Edge-firewall: An edge-firewall is a firewall device that is 389 located on the border line of an administrative domain. 391 o Public Network: "A Global or Public Network is an address realm 392 with unique network addresses assigned by Internet Assigned 393 Numbers Authority (IANA) or an equivalent address registry. This 394 network is also referred as external network during NAT 395 discussions" [RFC2663]. 397 o Private/Local Network: "A private network is an address realm 398 independent of external network addresses. Private network may 399 also be referred alternately as Local Network. Transparent 400 routing between hosts in private realm and external realm is 401 facilitated by a NAT router" [RFC2663]. 403 o Public/Global IP address: An IP address located in the public 404 network according to Section 2.7 of [RFC2663]. 406 o Private/Local IP address: An IP address located in the private 407 network according to Section 2.8 of [RFC2663]. 409 o Signaling Destination Address (SDA): An IP address generally taken 410 from the public/global IP address range, although, the SDA may in 411 certain circumstances be part of the private/local IP address 412 range. This address is used in EXTERNAL signaling message 413 exchanges, if the data receiver's IP address is unknown. 415 1.3. Notes on the Experimental Status 417 The same deployment issues and extensibility considerations described 418 in [I-D.ietf-nsis-ntlp] and [I-D.ietf-nsis-ext] also apply to this 419 document. 421 1.4. Middleboxes 423 The term middlebox covers a range of devices and is well-defined in 424 [RFC3234]: "A middlebox is defined as any intermediate device 425 performing functions other than the normal, standard functions of an 426 IP router on the datagram path between source host and a destination 427 host". As such, middleboxes fall into a number of categories with a 428 wide range of functionality, not all of which is pertinent to the 429 NATFW NSLP. Middlebox categories in the scope of this memo are 430 firewalls that filter data packets against a set of filter rules, and 431 NATs that translate packet addresses from one address realm to 432 another address realm. Other categories of middleboxes, such as QoS 433 traffic shapers, are out of scope of this memo. 435 The term NAT used in this document is a placeholder for a range of 436 different NAT flavors. We consider the following types of NATs: 438 o Traditional NAT (basic NAT and NAPT) 440 o Bi-directional NAT 442 o Twice-NAT 444 o Multihomed NAT 446 For definitions and a detailed discussion about the characteristics 447 of each NAT type please see [RFC2663]. 449 All types of middleboxes under consideration here, use policy rules 450 to make a decision on data packet treatment. Policy rules consist of 451 a flow identifier which selects the packets to which the policy 452 applies and an associated action; data packets matching the flow 453 identifier are subjected to the policy rule action. A typical flow 454 identifier is the 5-tuple selector which matches the following fields 455 of a packet to configured values: 457 o Source and destination IP addresses 459 o Transport protocol number 461 o Transport source and destination port numbers 463 Actions for firewalls are usually one or more of: 465 o Allow: forward data packet 467 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.5. 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. This communication 515 establishment may require that the applications contact an 516 application server which serves as a rendezvous point between both 517 parties to exchange their IP address and port(s). The local 518 applications trigger the NSIS entity at the local host to control 519 provisioning for middlebox traversal along the prospective data path 520 (e.g., via an API call). The NSIS entity in turn uses NSIS NATFW 521 NSLP signaling to establish policy rules along the data path, 522 allowing the data to travel from the sender to the receiver 523 unobstructed. 525 Application Application Server (0, 1, or more) Application 527 +----+ +----+ +----+ 528 | +------------------------+ +------------------------+ | 529 +-+--+ +----+ +-+--+ 530 | | 531 | NSIS Entities NSIS Entities | 532 +-+--+ +----+ +-----+ +-+--+ 533 | +--------+ +----------------------------+ +-----+ | 534 +-+--+ +-+--+ +--+--+ +-+--+ 535 | | ------ | | 536 | | //// \\\\\ | | 537 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 538 | | | | | Internet | | | | | 539 | +--------+ +-----+ +----+ +-----+ | 540 +----+ +----+ |\ | +----+ +----+ 541 \\\\ ///// 542 sender NATFW (1+) ------ NATFW (1+) receiver 544 Note that 1+ refers to one or more NATFW nodes. 546 Figure 1: Generic View of NSIS with NATs and/or firewalls 548 For end-to-end NATFW signaling, it is necessary that each firewall 549 and each NAT along the path between the data sender and the data 550 receiver implements the NSIS NATFW NSLP. There might be several NATs 551 and FWs in various possible combinations on a path between two hosts. 552 Section 2 presents a number of likely scenarios with different 553 combinations of NATs and firewalls. However, the scenarios given in 554 the following sections are not limiting the scope of the NATFW NSLP 555 to them only, but they are examples only. 557 2. Network Deployment Scenarios using the NATFW NSLP 559 This section introduces several scenarios for middlebox placement 560 within IP networks. Middleboxes are typically found at various 561 different locations, including at enterprise network borders, within 562 enterprise networks, as mobile phone network gateways, etc. Usually, 563 middleboxes are placed more towards the edge of networks than in 564 network cores. Firewalls and NATs may be found at these locations 565 either alone, or they may be combined; other categories of 566 middleboxes may also be found at such locations, possibly combined 567 with the NATs and/or firewalls. 569 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 570 regular data path to the NSIS responder (NR). On the data path, 571 NATFW NSLP signaling messages reach different NSIS nodes that 572 implement the NATFW NSLP. Each NATFW NSLP node processes the 573 signaling messages according to Section 3 and, if necessary, installs 574 policy rules for subsequent data packets. 576 Each of the following sub-sections introduces a different scenario 577 for a different set of middleboxes and their ordering within the 578 topology. It is assumed that each middlebox implements the NSIS 579 NATFW NSLP signaling protocol. 581 2.1. Firewall Traversal 583 This section describes a scenario with firewalls only; NATs are not 584 involved. Each end host is behind a firewall. The firewalls are 585 connected via the public Internet. Figure 2 shows the topology. The 586 part labeled "public" is the Internet connecting both firewalls. 588 +----+ //----\\ +----+ 589 NI -----| FW |---| |------| FW |--- NR 590 +----+ \\----// +----+ 592 private public private 594 FW: Firewall 595 NI: NSIS Initiator 596 NR: NSIS Responder 598 Figure 2: Firewall Traversal Scenario 600 Each firewall on the data path must provide traversal service for 601 NATFW NSLP in order to permit the NSIS message to reach the other end 602 host. All firewalls process NSIS signaling and establish appropriate 603 policy rules, so that the required data packet flow can traverse 604 them. 606 There are several very different ways to place firewalls in a network 607 topology. To distinguish firewalls located at network borders, such 608 as administrative domains, from others located internally, the term 609 edge-firewall is used. A similar distinction can be made for NATs, 610 with an edge-NAT fulfilling the equivalent role. 612 2.2. NAT with two Private Networks 614 Figure 3 shows a scenario with NATs at both ends of the network. 615 Therefore, each application instance, the NSIS initiator and the NSIS 616 responder, are behind NATs. The outermost NAT, known as the edge-NAT 617 (MB2 and MB3), at each side is connected to the public Internet. The 618 NATs are generically labeled as MBX (for middlebox No. X), since 619 those devices certainly implement NAT functionality, but can 620 implement firewall functionality as well. 622 Only two middleboxes MB are shown in Figure 3 at each side, but in 623 general, any number of MBs on each side must be considered. 625 +----+ +----+ //----\\ +----+ +----+ 626 NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR 627 +----+ +----+ \\----// +----+ +----+ 629 private public private 631 MB: Middlebox 632 NI: NSIS Initiator 633 NR: NSIS Responder 635 Figure 3: NAT with two Private Networks Scenario 637 Signaling traffic from NI to NR has to traverse all the middleboxes 638 on the path (MB1 to MB4, in this order), and all the middleboxes must 639 be configured properly to allow NSIS signaling to traverse them. The 640 NATFW signaling must configure all middleboxes and consider any 641 address translation that will result from this configuration in 642 further signaling. The sender (NI) has to know the IP address of the 643 receiver (NR) in advance, otherwise it will not be possible to send 644 any NSIS signaling messages towards the responder. Note that this IP 645 address is not the private IP address of the responder but the NAT's 646 public IP address (here MB3's IP address). Instead a NAT binding 647 (including a public IP address) has to be previously installed on the 648 NAT MB3. This NAT binding subsequently allows packets reaching the 649 NAT to be forwarded to the receiver within the private address realm. 651 The receiver might have a number of ways to learn its public IP 652 address and port number (including the NATFW NSLP) and might need to 653 signal this information to the sender using an application level 654 signaling protocol. 656 2.3. NAT with Private Network on Sender Side 658 This scenario shows an application instance at the sending node that 659 is behind one or more NATs (shown as generic MB, see discussion in 660 Section 2.2). The receiver is located in the public Internet. 662 +----+ +----+ //----\\ 663 NI --| MB |-----| MB |---| |--- NR 664 +----+ +----+ \\----// 666 private public 668 MB: Middlebox 669 NI: NSIS Initiator 670 NR: NSIS Responder 672 Figure 4: NAT with Private Network on Sender Side 674 The traffic from NI to NR has to traverse middleboxes only on the 675 sender's side. The receiver has a public IP address. The NI sends 676 its signaling message directly to the address of the NSIS responder. 677 Middleboxes along the path intercept the signaling messages and 678 configure accordingly. 680 The data sender does not necessarily know whether the receiver is 681 behind a NAT or not, hence, it is the receiving side that has to 682 detect whether itself is behind a NAT or not. 684 2.4. NAT with Private Network on Receiver Side Scenario 686 The application instance receiving data is behind one or more NATs 687 shown as MB (see discussion in Section 2.2). 689 //----\\ +----+ +----+ 690 NI ---| |---| MB |-----| MB |--- NR 691 \\----// +----+ +----+ 693 public private 695 MB: Middlebox 696 NI: NSIS Initiator 697 NR: NSIS Responder 699 Figure 5: NAT with Private Network on Receiver Scenario 701 Initially, the NSIS responder must determine its publicly reachable 702 IP address at the external middlebox and notify the NSIS initiator 703 about this address. One possibility is that an application level 704 protocol is used, meaning that the public IP address is signaled via 705 this protocol to the NI. Afterwards the NI can start its signaling 706 towards the NR and therefore establish the path via the middleboxes 707 in the receiver side private network. 709 This scenario describes the use case for the EXTERNAL message of the 710 NATFW NSLP. 712 2.5. Both End Hosts behind twice-NATs 714 This is a special case, where the main problem arises from the need 715 to detect that both end hosts are logically within the same address 716 space, but are also in two partitions of the address realm on either 717 side of a twice-NAT (see [RFC2663] for a discussion of twice-NAT 718 functionality). 720 Sender and receiver are both within a single private address realm 721 but the two partitions potentially have overlapping IP address 722 ranges. Figure 6 shows the arrangement of NATs. 724 public 726 +----+ +----+ //----\\ 727 NI --| MB |--+--| MB |---| | 728 +----+ | +----+ \\----// 729 | 730 | +----+ 731 +--| MB |------------ NR 732 +----+ 734 private 736 MB: Middlebox 737 NI: NSIS Initiator 738 NR: NSIS Responder 740 Figure 6: NAT to Public, Sender and Receiver on either side of a 741 twice-NAT Scenario 743 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 744 addresses and port numbers on both sides, meaning the mapping of 745 source and destination address at the private and public interfaces. 747 This scenario requires the assistance of application level entities, 748 such as a DNS server. The application level entities must handle 749 requests that are based on symbolic names, and configure the 750 middleboxes so that data packets are correctly forwarded from NI to 751 NR. The configuration of those middleboxes may require other 752 middlebox communication protocols, such as MIDCOM [RFC3303]. NSIS 753 signaling is not required in the twice-NAT only case, since 754 middleboxes of the twice-NAT type are normally configured by other 755 means. Nevertheless, NSIS signaling might be useful when there are 756 also firewalls on the path. In this case NSIS will not configure any 757 policy rule at twice-NATs, but will configure policy rules at the 758 firewalls on the path. The NSIS signaling protocol must be at least 759 robust enough to survive this scenario. This requires that twice- 760 NATs must implement the NATFW NSLP also and participate in NATFW 761 signaling sessions but they do not change the configuration of the 762 NAT, i.e., they only read the address mapping information out of the 763 NAT and translate the Message Routing Information (MRI, 764 [I-D.ietf-nsis-ntlp]) within the NSLP and NTLP accordingly. For more 765 information see Appendix D.4 767 2.6. Both End Hosts Behind Same NAT 769 When NSIS initiator and NSIS responder are behind the same NAT (thus 770 being in the same address realm, see Figure 7), they are most likely 771 not aware of this fact. As in Section 2.4 the NSIS responder must 772 determine its public IP address in advance and transfer it to the 773 NSIS initiator. Afterwards, the NSIS initiator can start sending the 774 signaling messages to the responder's public IP address. During this 775 process, a public IP address will be allocated for the NSIS initiator 776 at the same middlebox as for the responder. Now, the NSIS signaling 777 and the subsequent data packets will traverse the NAT twice: from 778 initiator to public IP address of responder (first time) and from 779 public IP address of responder to responder (second time). 781 NI public 782 \ +----+ //----\\ 783 +-| MB |----| | 784 / +----+ \\----// 785 NR 786 private 788 MB: Middlebox 789 NI: NSIS Initiator 790 NR: NSIS Responder 792 Figure 7: NAT to Public, Both Hosts Behind Same NAT 794 2.7. Multihomed Network with NAT 796 The previous sub-sections sketched network topologies where several 797 NATs and/or firewalls are ordered sequentially on the path. This 798 section describes a multihomed scenario with two NATs placed on 799 alternative paths to the public network. 801 +----+ //---\\ 802 NI -------| MB |---| | 803 \ +----+ \\-+-// 804 \ | 805 \ +----- NR 806 \ | 807 \ +----+ //-+-\\ 808 --| MB |---| | 809 +----+ \\---// 811 private public 813 MB: Middlebox 814 NI: NSIS Initiator 815 NR: NSIS Responder 817 Figure 8: Multihomed Network with Two NATs 819 Depending on the destination, either one or the other middlebox is 820 used for the data flow. Which middlebox is used, depends on local 821 policy or routing decisions. NATFW NSLP must be able to handle this 822 situation properly, see Section 3.7.2 for an extended discussion of 823 this topic with respect to NATs. 825 2.8. Multihomed Network with Firewall 827 This section describes a multihomed scenario with two firewalls 828 placed on alternative paths to the public network (Figure 9). The 829 routing in the private and public network decides which firewall is 830 being taken for data flows. Depending on the data flow's direction, 831 either outbound or inbound, a different firewall could be traversed. 832 This is a challenge for the EXTERNAL message of the NATFW NSLP where 833 the NSIS responder is located behind these firewalls within the 834 private network. The EXTERNAL message is used to block a particular 835 data flow on an inbound firewall. NSIS must route the EXTERNAL 836 message inbound from NR to NI probably without knowing which path the 837 data traffic will take from NI to NR (see also Appendix C). 839 +----+ 840 NR -------| FW |\ 841 \ +----+ \ //---\\ 842 \ -| |-- NI 843 \ \\---// 844 \ +----+ | 845 --| FW |-------+ 846 +----+ 847 private 849 private public 851 FW: Firewall 852 NI: NSIS Initiator 853 NR: NSIS Responder 855 Figure 9: Multihomed Network with two firewalls 857 3. Protocol Description 859 This section defines messages, objects, and protocol semantics for 860 the NATFW NSLP. 862 3.1. Policy Rules 864 Policy rules, bound to a NATFW NSLP signaling session, are the 865 building blocks of middlebox devices considered in the NATFW NSLP. 866 For firewalls the policy rule usually consists of a 5-tuple and an 867 action such as allow or deny. The information contained in the tuple 868 includes source/destination addresses, transport protocol and source/ 869 destination port numbers. For NATs the policy rule consists of the 870 action 'translate this address' and further mapping information, that 871 might be, in the simplest case, internal IP address and external IP 872 address. 874 The NATFW NSLP carries, in conjunction with the NTLP's Message 875 Routing Information (MRI), the policy rules to be installed at NATFW 876 peers. This policy rule is an abstraction with respect to the real 877 policy rule to be installed at the respective firewall or NAT. It 878 conveys the initiator's request and must be mapped to the possible 879 configuration on the particular used NAT and/or firewall in use. For 880 pure firewalls one or more filter rules must be created and for pure 881 NATs one or more NAT bindings must be created. In mixed firewall and 882 NAT boxes, the policy rule must be mapped to filter rules and 883 bindings observing the ordering of the firewall and NAT engine. 884 Depending on the ordering, NAT before firewall or vice versa, the 885 firewall rules must carry public or private IP addresses. However, 886 the exact mapping depends on the implementation of the firewall or 887 NAT which is possibly different for each implementation. 889 The policy rule at the NATFW NSLP level comprises the message routing 890 information (MRI) part, carried in the NTLP, and the information 891 available in the NATFW NSLP. The information provided by the NSLP is 892 stored in the 'extend flow information' (NATFW_EFI) and 'data 893 terminal information' (NATFW_DTINFO) objects, and the message type. 894 Additional information, such as the external IP address and port 895 number, stored in the NAT or firewall, will be used as well. The MRI 896 carries the filter part of the NAT/firewall-level policy rule that is 897 to be installed. 899 The NATFW NSLP specifies two actions for the policy rules: deny and 900 allow. A policy rule with action set to deny will result in all 901 packets matching this rule to be dropped. A policy rule with action 902 set to allow will result in all packets matching this rule to be 903 forwarded. 905 3.2. Basic Protocol Overview 907 The NSIS NATFW NSLP is carried over the General Internet Signaling 908 Transport (GIST, the implementation of the NTLP) defined in 909 [I-D.ietf-nsis-ntlp]. NATFW NSLP messages are initiated by the NSIS 910 initiator (NI), handled by NSIS forwarders (NF) and received by the 911 NSIS responder (NR). It is required that at least NI and NR 912 implement this NSLP, intermediate NFs only implement this NSLP when 913 they provide relevant middlebox functions. NSIS forwarders that do 914 not have any NATFW NSLP functions just forward these packets as they 915 have no interest in them. 917 3.2.1. Signaling for Outbound Traffic 919 A Data Sender (DS), intending to send data to a Data Receiver (DR) 920 has to start NATFW NSLP signaling. This causes the NI associated 921 with the data sender (DS) to launch NSLP signaling towards the 922 address of data receiver (DR) (see Figure 10). Although it is 923 expected that the DS and the NATFW NSLP NI will usually reside on the 924 same host, this specification does not rule out scenarios where the 925 DS and NI reside on different hosts, the so-called proxy mode (see 926 Section 3.7.6.) 928 +-------+ +-------+ +-------+ +-------+ 929 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 930 | |--->| NF1 |--->| NF2 |--->| | 931 +-------+ +-------+ +-------+ +-------+ 933 ========================================> 934 Data Traffic Direction (outbound) 936 ---> : NATFW NSLP request signaling 937 ~~~> : NATFW NSLP response signaling 938 DS/NI : Data sender and NSIS initiator 939 DR/NR : Data receiver and NSIS responder 940 MB1 : Middlebox 1 and NSIS forwarder 1 941 MB2 : Middlebox 2 and NSIS forwarder 2 943 Figure 10: General NSIS signaling 945 The following list shows the normal sequence of NSLP events without 946 detailing the interaction with the NTLP and the interactions on the 947 the NTLP level. 949 o NSIS initiators generate request messages (which are either CREATE 950 or EXTERNAL messages) and send these towards the NSIS responder. 952 This request message is the initial message which creates a new 953 NATFW NSLP signaling session. The NI and the NR will most likely 954 already share an application session before they start the NATFW 955 NSLP signaling session. Note well the difference between both 956 sessions. 958 o NSLP request messages are processed each time a NF with NATFW NSLP 959 support is traversed. Each NF that is intercepting a request 960 message and is accepting it for further treatment is joining the 961 particular NATFW NSLP signaling session. These nodes process the 962 message, check local policies for authorization and 963 authentication, possibly create policy rules, and forward the 964 signaling message to the next NSIS node. The request message is 965 forwarded until it reaches the NSIS responder. 967 o NSIS responders will check received messages and process them if 968 applicable. NSIS responders generate RESPONSE messages and send 969 them hop-by-hop back to the NI via the same chain of NFs 970 (traversal of the same NF chain is guaranteed through the 971 established reverse message routing state in the NTLP). The NR is 972 also joining the NATFW NSLP signaling session if the request 973 message is accepted. 975 o The RESPONSE message is processed at each NF that has been 976 included in the prior NATFW NSLP signaling session setup. 978 o If the NI has received a successful RESPONSE message and if the 979 signaling NATFW NSLP session started with a CREATE message, the 980 data sender can start sending its data flow to the data receiver. 981 If the NI has received a successful RESPONSE message and if the 982 signaling NATFW NSLP session started with a EXTERNAL message, the 983 data receiver is ready to receive further CREATE messages. 985 Because NATFW NSLP signaling follows the data path from DS to DR, 986 this immediately enables communication between both hosts for 987 scenarios with only firewalls on the data path or NATs on the sender 988 side. For scenarios with NATs on the receiver side certain problems 989 arise, as described in Section 2.4. 991 3.2.2. Signaling for Inbound Traffic 993 When the NR and the NI are located in different address realms and 994 the NR is located behind a NAT, the NI cannot signal to the NR 995 address directly. The DR/NR is not reachable from other NIs using 996 the private address of the NR and thus NATFW signaling messages 997 cannot be sent to the NR/DR's address. Therefore, the NR must first 998 obtain a NAT binding that provides an address that is reachable for 999 the NI. Once the NR has acquired a public IP address, it forwards 1000 this information to the DS via a separate protocol. This application 1001 layer signaling, which is out of scope of the NATFW NSLP, may involve 1002 third parties that assist in exchanging these messages. 1004 The same holds partially true for NRs located behind firewalls that 1005 block all traffic by default. In this case, NR must tell its inbound 1006 firewalls of inbound NATFW NSLP signaling and corresponding data 1007 traffic. Once the NR has informed the inbound firewalls, it can 1008 start its application level signaling to initiate communication with 1009 the NI. This mechanism can be used by machines hosting services 1010 behind firewalls as well. In this case, the NR informs the inbound 1011 firewalls as described, but does not need to communicate this to the 1012 NIs. 1014 NATFW NSLP signaling supports this scenario by using the EXTERNAL 1015 message 1017 1. The DR acquires a public address by signaling on the reverse path 1018 (DR towards DS) and thus making itself available to other hosts. 1019 This process of acquiring public addresses is called reservation. 1020 During this process the DR reserves publicly reachable addresses 1021 and ports suitable for further usage in application level 1022 signaling and the publicly reachable address for further NATFW 1023 NSLP signaling. However, the data traffic will not be allowed to 1024 use this address/port initially (see next point). In the process 1025 of reservation the DR becomes the NI for the messages necessary 1026 to obtain the publicly reachable IP address, i.e., the NI for 1027 this specific NATFW NSLP signaling session. 1029 2. Now on the side of DS, the NI creates a new NATFW NSLP signaling 1030 session and signals directly to the public IP address of DR. 1031 This public IP address is used as NR's address, as the NI would 1032 do if there is no NAT in between, and creates policy rules at 1033 middleboxes. Note, that the reservation will only allow 1034 forwarding of signaling messages, but not data flow packets. 1035 Policy rules allowing forwarding of data flow packets set up by 1036 the prior EXTERNAL message signaling will be activated when the 1037 signaling from NI towards NR is confirmed with a positive 1038 RESPONSE message. The EXTERNAL message is described in 1039 Section 3.7.2. 1041 3.2.3. Signaling for Proxy Mode 1042 administrative domain 1043 ----------------------------------\ 1044 | 1045 +-------+ +-------+ +-------+ | +-------+ 1046 | DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR | 1047 | |--->| NF1 |--->| NR | | | | 1048 +-------+ +-------+ +-------+ | +-------+ 1049 | 1050 ----------------------------------/ 1052 ========================================> 1053 Data Traffic Direction (outbound) 1055 ---> : NATFW NSLP request signaling 1056 ~~~> : NATFW NSLP response signaling 1057 DS/NI : Data sender and NSIS initiator 1058 DR/NR : Data receiver and NSIS responder 1059 MB1 : Middlebox 1 and NSIS forwarder 1 1060 MB2 : Middlebox 2 and NSIS responder 1062 Figure 11: proxy mode signaling for data sender 1064 The above usage assumes that both ends of a communication support 1065 NSIS, but fails when NSIS is only deployed at one end of the path. 1066 In this case only one of the sending Figure 11 or receiving Figure 12 1067 side is NSIS aware and not both at the same time. NATFW NSLP 1068 supports both scenarios (i.e., either the DS or DR do not support 1069 NSIS) by using a proxy mode, as described in Section 3.7.6 1070 administrative domain 1071 / ---------------------------------- 1072 | 1073 +-------+ | +-------+ +-------+ +-------+ 1074 | DS | | | MB2/ |~~~>| MB1/ |~~~>| DR | 1075 | | | | NR |<---| NF1 |<---| | 1076 +-------+ | +-------+ +-------+ +-------+ 1077 | 1078 \---------------------------------- 1080 ========================================> 1081 Data Traffic Direction (inbound) 1083 ---> : NATFW NSLP request signaling 1084 ~~~> : NATFW NSLP response signaling 1085 DS/NI : Data sender and NSIS initiator 1086 DR/NR : Data receiver and NSIS responder 1087 MB1 : Middlebox 1 and NSIS forwarder 1 1088 MB2 : Middlebox 2 and NSIS responder 1090 Figure 12: proxy mode signaling for data receiver 1092 3.2.4. Blocking Traffic 1094 The basic functionality of the NATFW NSLP provides for opening 1095 firewall pin holes and creating NAT bindings to enable data flows to 1096 traverse these devices. Firewalls are normally expected to work on a 1097 'deny-all' policy, meaning that traffic not explicitly matching any 1098 firewall filter rule will be blocked. Similarly, the normal behavior 1099 of NATs is to block all traffic that does not match any already 1100 configured/installed binding or NATFW NSLP session. However, some 1101 scenarios require support of firewalls having 'allow-all' policies, 1102 allowing data traffic to traverse the firewall unless it is blocked 1103 explicitly. Data receivers can utilize NATFW NSLP's EXTERNAL message 1104 with action set to 'deny' to install policy rules at inbound 1105 firewalls to block unwanted traffic. 1107 3.2.5. State and Error Maintenance 1109 The protocol works on a soft-state basis, meaning that whatever state 1110 is installed or reserved on a middlebox will expire, and thus be de- 1111 installed or forgotten after a certain period of time. To prevent 1112 premature removal of state that is needed for ongoing communication, 1113 the NATFW NI involved will have to specifically request a NATFW NSLP 1114 signaling session extension. An explicit NATFW NSLP state deletion 1115 capability is also provided by the protocol. 1117 If the actions requested by a NATFW NSLP message cannot be carried 1118 out, NFs and the NR must return a failure, such that appropriate 1119 actions can be taken. They can do this either during the request 1120 message handling (synchronously) by sending an error RESPONSE 1121 message, or at any time (asynchronously) by sending a NOTIFY 1122 notification message. 1124 The next sections define the NATFW NSLP message types and formats, 1125 protocol operations, and policy rule operations. 1127 3.2.6. Message Types 1129 The protocol uses four messages types: 1131 o CREATE: a request message used for creating, changing, refreshing, 1132 and deleting NATFW NSLP signaling sessions, i.e., open the data 1133 path from DS to DR. 1135 o EXTERNAL: a request message used for reserving, changing, 1136 refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions. 1137 EXTERNAL messages are forwarded to the edge-NAT or edge-firewall 1138 and allow inbound CREATE messages to be forwarded to the NR. 1139 Additionally, EXTERNAL messages reserve an external address and, 1140 if applicable, port number at an edge-NAT. 1142 o NOTIFY: an asynchronous message used by NATFW peers to alert other 1143 NATFW peers about specific events (especially failures). 1145 o RESPONSE: used as a response to CREATE and EXTERNAL request 1146 messages. 1148 3.2.7. Classification of RESPONSE Messages 1150 RESPONSE messages will be generated synchronously to CREATE and 1151 EXTERNAL messages by NSIS Forwarders and Responders to report success 1152 or failure of operations or some information relating to the NATFW 1153 NSLP signaling session or a node. RESPONSE messages MUST NOT be 1154 generated for any other message, such as NOTIFY and RESPONSE. 1156 All RESPONSE messages MUST carry a NATFW_INFO object which contains a 1157 severity class code and a response code (see Section 4.2.5). This 1158 section defines terms for groups of RESPONSE messages depending on 1159 the severity class. 1161 o Successful RESPONSE: Messages carrying NATFW_INFO with severity 1162 class 'Success' (0x2). 1164 o Informational RESPONSE: Messages carrying NATFW_INFO with severity 1165 class 'Informational' (0x1) (only used with NOTIFY messages). 1167 o Error RESPONSE: Messages carrying NATFW_INFO with severity class 1168 other than 'Success' or 'Informational'. 1170 3.2.8. NATFW NSLP Signaling Sessions 1172 A NATFW NSLP signaling session defines an association between the NI, 1173 NFs, and the NR related to a data flow. This association is created 1174 when the initial CREATE or EXTERNAL message is successfully received 1175 at the NFs or the NR. There is signaling NATFW NSLP session state 1176 stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP 1177 signaling session state for the NATFW NSLP comprises NSLP state and 1178 the associated policy rules at a middlebox. 1180 The NATFW NSLP signaling session is identified by the session ID 1181 (plus other information at the NTLP level). The session ID is 1182 generated by the NI before the initial CREATE or EXTERNAL message is 1183 sent. The value of the session ID MUST be generated as a 1184 cryptographically random number (see [RFC4086] by the NI, i.e., the 1185 output MUST NOT be easily guessable by third parties. The session ID 1186 is not stored in any NATFW NSLP message but passed on to the NTLP. 1188 A NATFW NSLP signaling session has several conceptional states that 1189 describes in what state a signaling session is at a given time. The 1190 signaling session can have these states at a node: 1192 o Pending: The NATFW NSLP signaling session has been created and the 1193 node is waiting for a RESPONSE message to the CREATE or EXTERNAL 1194 message. A NATFW NSLP signaling session in state 'Pending' MUST 1195 be marked as 'Dead' if no corresponding RESPONSE message has been 1196 received within the time of the locally granted NATFW NSLP 1197 signaling session lifetime of the forwarded CREATE or EXTERNAL 1198 message (as described in Section 3.4). 1200 o Established: The NATFW NSLP signaling session is established, i.e, 1201 the signaling has been successfully performed and the lifetime of 1202 NATFW NSLP signaling session is counted from now on. A NATFW NSLP 1203 signaling session in state 'Established' MUST be marked as 'Dead' 1204 if no refresh message has been received within the time of the 1205 locally granted NATFW NSLP signaling session lifetime of the 1206 RESPONSE message (as described in Section 3.4). 1208 o Dead: Either the NATFW NSLP signaling session is timed out or the 1209 node has received an error RESPONSE message for the NATFW NSLP 1210 signaling session and the NATFW NSLP signaling session can be 1211 deleted. 1213 o Transitory: The node has received an asynchronous message, i.e., a 1214 NOTIFY, and can delete the NATFW NSLP signaling session if needed 1215 after some time. When a node has received a NOTIFY message, it 1216 marks the signaling session as 'transitory'. This signaling 1217 session SHOULD NOT be deleted before a minimum hold time of 30 1218 second, i.e., it can be removed after 30 seconds or more. This 1219 hold time ensures that the existing signaling session can be 1220 reused by the NI, e.g., a part of a signalling session that is not 1221 affected by the route change can be reused once the updating 1222 request message is received. 1224 3.3. Basic Message Processing 1226 All NATFW messages are subject to some basic message processing when 1227 received at a node, independent of the message type. Initially, the 1228 syntax of the NSLP message is checked and a RESPONSE message with an 1229 appropriate error of class 'Protocol error' (0x3) code is generated 1230 if a non recoverable syntax error is detected. A recoverable error 1231 is, for instance, when a node receives a message with reserved flags 1232 set to values other than zero. This also refers to unknown NSLP 1233 objects and their handling, according to Section 4.2. If a message 1234 is delivered to the NATFW NSLP, this implies that the NTLP layer has 1235 been able to correlate it with the SID and MRI entries in its 1236 database. There is therefore enough information to identify the 1237 source of the message and routing information to route the message 1238 back to the NI through an established chain of NTLP messaging 1239 associations. The message is not further forwarded if any error in 1240 the syntax is detected. The specific response codes stemming from 1241 the processing of objects are described in the respective object 1242 definition section (see Section 4). After passing this check, the 1243 NATFW NSLP node performs authentication/authorization related checks 1244 described in Section 3.6. Further processing is executed only if 1245 these tests have been successfully passed, otherwise the processing 1246 stops and an error RESPONSE is returned. 1248 Further message processing stops whenever an error RESPONSE message 1249 is generated, and the EXTERNAL or CREATE message is discarded. 1251 3.4. Calculation of Signaling Session Lifetime 1253 NATFW NSLP signaling sessions, and the corresponding policy rules 1254 which may have been installed, are maintained via a soft-state 1255 mechanism. Each signaling session is assigned a signaling session 1256 lifetime and the signaling session is kept alive as long as the 1257 lifetime is valid. After the expiration of the signaling session 1258 lifetime, signaling sessions and policy rules MUST be removed 1259 automatically and resources bound to them MUST be freed as well. 1260 Signaling session lifetime is handled at every NATFW NSLP node. The 1261 NSLP forwarders and NSLP responder MUST NOT trigger signaling session 1262 lifetime extension refresh messages (see Section 3.7.3): this is the 1263 task of the NSIS initiator. 1265 The NSIS initiator MUST choose a NATFW NSLP signaling session 1266 lifetime value (expressed in seconds) before sending any message, 1267 including the initial message which creates the NATFW NSLP signaling 1268 session, to other NSLP nodes. It is RECOMMENDED that the NATFW NSLP 1269 signaling session lifetime value is calculated based on: 1271 o the number of lost refresh messages that NFs should cope with; 1273 o the end-to-end delay between the NI and NR; 1275 o network vulnerability due to NATFW NSLP signaling session 1276 hijacking ([RFC4081]), NATFW NSLP signaling session hijacking is 1277 made easier when the NI does not explicitly remove the NATFW NSLP 1278 signaling session; 1280 o the user application's data exchange duration, in terms of time 1281 and networking needs. This duration is modeled as R, with R the 1282 message refresh period (in seconds); 1284 o the load on the signaling plane. Short lifetimes imply more 1285 frequent signaling messages. 1287 o the acceptable time for a NATFW NSLP signaling session to be 1288 present after it is no longer actually needed. For example, if 1289 the existence of the NATFW NSLP signaling session implies a 1290 monetary cost and teardown cannot be guaranteed, shorter lifetimes 1291 would be preferable; 1293 o the lease time of the NI's IP address. The lease time of the IP 1294 address must be larger than chosen NATFW NSLP signaling session 1295 lifetime, otherwise the IP address can be re-assigned to a 1296 different node. This node may receive unwanted traffic, although 1297 it never has requested a NAT/firewall configuration, which might 1298 be an issue in environments with mobile hosts. 1300 The RSVP specification [RFC2205] provides an appropriate algorithm 1301 for calculating the NATFW NSLP signaling session lifetime as well as 1302 means to avoid refresh message synchronization between NATFW NSLP 1303 signaling sessions. [RFC2205] recommends: 1305 1. The refresh message timer to be randomly set to a value in the 1306 range [0.5R, 1.5R]. 1308 2. To avoid premature loss of state, lt (with lt being the NATFW 1309 NSLP signaling session lifetime) must satisfy lt >= (K + 1310 0.5)*1.5*R, where K is a small integer. Then in the worst case, 1311 K-1 successive messages may be lost without state being deleted. 1312 Currently K = 3 is suggested as the default. However, it may be 1313 necessary to set a larger K value for hops with high loss rate. 1314 Other algorithms could be used to define the relation between the 1315 NATFW NSLP signaling session lifetime and the refresh message 1316 period; the algorithm provided is only given as an example. 1318 It is RECOMMENDED to use a refresh timer of 300 s (5 minutes), unless 1319 the NI or the requesting application at the NI has other requirements 1320 (e.g., flows lasting a very short time). 1322 This requested NATFW NSLP signaling session lifetime value lt is 1323 stored in the NATFW_LT object of the NSLP message. 1325 NSLP forwarders and the NSLP responder can execute the following 1326 behavior with respect to the requested lifetime handling: 1328 Requested signaling session lifetime acceptable: 1330 No changes to the NATFW NSLP signaling session lifetime values are 1331 needed. The CREATE or EXTERNAL message is forwarded, if 1332 applicable. 1334 Signaling session lifetime can be lowered: 1336 An NSLP forwarded or the NSLP responder MAY also lower the 1337 requested NATFW NSLP signaling session lifetime to an acceptable 1338 value (based on its local policies). If an NF changes the NATFW 1339 NSLP signaling session lifetime value, it MUST store the new value 1340 in the NATFW_LT object. The CREATE or EXTERNAL message is 1341 forwarded. 1343 Requested signaling session lifetime is too big: 1345 An NSLP forwarded or the NSLP responder MAY reject the requested 1346 NATFW NSLP signaling session lifetime value as being too big and 1347 MUST generate an error RESPONSE message of class 'Signaling 1348 session failure' (0x6) with response code 'Requested lifetime is 1349 too big' (0x02) upon rejection. Lowering the lifetime is 1350 preferred instead of generating an error message. 1352 Requested signaling session lifetime is too small: 1354 An NSLP forwarded or the NSLP responder MAY reject the requested 1355 NATFW NSLP signaling session lifetime value as being to small and 1356 MUST generate an error RESPONSE message of class 'Signaling 1357 session failure' (0x6) with response code 'Requested lifetime is 1358 too small' (0x10) upon rejection. 1360 NFs or the NR MUST NOT increase the NATFW NSLP signaling session 1361 lifetime value. Messages can be rejected on the basis of the NATFW 1362 NSLP signaling session lifetime being too long when a NATFW NSLP 1363 signaling session is first created and also on refreshes. 1365 The NSLP responder generates a successful RESPONSE for the received 1366 CREATE or EXTERNAL message, sets the NATFW NSLP signaling session 1367 lifetime value in the NATFW_LT object to the above granted lifetime 1368 and sends the message back towards NSLP initiator. 1370 Each NSLP forwarder processes the RESPONSE message, reads and stores 1371 the granted NATFW NSLP signaling session lifetime value. The 1372 forwarders MUST accept the granted NATFW NSLP signaling session 1373 lifetime, if the lifetime value is within the acceptable range. The 1374 acceptable value refers to the value accepted by the NSLP forwarder 1375 when processing the CREATE or EXTERNAL message. For received values 1376 greater than the acceptable value, NSLP forwarders MUST generate a 1377 RESPONSE message of class 'Signaling session failure' (0x6) with 1378 response code 'Modified lifetime is too big' (0x11), including a 1379 Signaling Session Lifetime object that carries the maximum acceptable 1380 signaling session lifetime for this node. For received values lower 1381 than the values acceptable by the node local policy, NSLP forwarders 1382 MUST generate a RESPONSE message of class 'Signaling session failure' 1383 (0x6) with response code 'Modified lifetime is too small' (0x12), 1384 including a Signaling Session Lifetime object that carries the 1385 minimum acceptable signaling session lifetime for this node. In both 1386 cases, either 'Modified lifetime is too big' (0x11) or 'Modified 1387 lifetime is too small' (0x12), the NF MUST generate a NOTIFY message 1388 and send it outbound with the error class set to 'Informational' 1389 (0x1) and with the severity class to 'NATFW signaling session 1390 terminated.' (0x05). 1392 Figure 13 shows the procedure with an example, where an initiator 1393 requests 60 seconds lifetime in the CREATE message and the lifetime 1394 is shortened along the path by the forwarder to 20 seconds and by the 1395 responder to 15 seconds. When the NSLP forwarder receives the 1396 RESPONSE message with a NATFW NSLP signaling session lifetime value 1397 of 15 seconds it checks whether this value is lower or equal to the 1398 acceptable value. 1400 +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ 1401 | |---------------->| NSLP |---------------->| | 1402 | NI | | forwarder | | NR | 1403 | |<----------------| check 15<20 |<----------------| | 1404 +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ 1406 lt = lifetime 1408 Figure 13: Signaling Session Lifetime Setting Example 1410 3.5. Message Sequencing 1412 NATFW NSLP messages need to carry an identifier so that all nodes 1413 along the path can distinguish messages sent at different points in 1414 time. Messages can be lost along the path or duplicated. So all 1415 NATFW NSLP nodes should be able to identify either old messages that 1416 have been received before (duplicated), or the case that messages 1417 have been lost before (loss). For message replay protection it is 1418 necessary to keep information about messages that have already been 1419 received and requires every NATFW NSLP message to carry a message 1420 sequence number (MSN), see also Section 4.2.7. 1422 The MSN MUST be set by the NI and MUST NOT be set or modified by any 1423 other node. The initial value for the MSN MUST be generated randomly 1424 and MUST be unique only within the NATFW NSLP signaling session for 1425 which it is used. The NI MUST increment the MSN by one for every 1426 message sent. Once the MSN has reached the maximum value, the next 1427 value it takes is zero. All NATFW NSLP nodes MUST use the algorithm 1428 defined in [RFC1982] to detect MSN wrap-arounds. 1430 NSIS forwarders and the responder store the MSN from the initial 1431 CREATE or EXTERNAL packet which creates the NATFW NSLP signaling 1432 session as the start value for the NATFW NSLP signaling session. NFs 1433 and NRs MUST include the received MSN value in the corresponding 1434 RESPONSE message that they generate. 1436 When receiving a CREATE or EXTERNAL message, a NATFW NSLP node uses 1437 the MSN given in the message to determine whether the state being 1438 requested is different to the state already installed. The message 1439 MUST be discarded if the received MSN value is equal to or lower than 1440 the stored MSN value. Such a received MSN value can indicate a 1441 duplicated and delayed message or replayed message. If the received 1442 MSN value is greater than the already stored MSN value, the NATFW 1443 NSLP MUST update its stored state accordingly, if permitted by all 1444 security checks (see Section 3.6), and store the updated MSN value 1445 accordingly. 1447 3.6. Authentication, Authorization, and Policy Decisions 1449 NATFW NSLP nodes receiving signaling messages MUST first check 1450 whether this message is authenticated and authorized to perform the 1451 requested action. NATFW NSLP nodes requiring more information than 1452 provided MUST generate an error RESPONSE of class 'Permanent failure' 1453 (0x5) with response code 'Authentication failed' (0x01) or with 1454 response code 'Authorization failed' (0x02). 1456 The NATFW NSLP is expected to run in various environments, such as 1457 IP-based telephone systems, enterprise networks, home networks, etc. 1458 The requirements on authentication and authorization are quite 1459 different between these use cases. While a home gateway, or an 1460 Internet cafe, using NSIS may well be happy with a "NATFW signaling 1461 coming from inside the network" policy for authorization of 1462 signaling, enterprise networks are likely to require more strongly 1463 authenticated/authorized signaling. This enterprise scenario may 1464 require the use of an infrastructure and administratively assigned 1465 identities to operate the NATFW NSLP. 1467 Once the NI is authenticated and authorized, another step is 1468 performed. The requested policy rule for the NATFW NSLP signaling 1469 session is checked against a set of policy rules, i.e., whether the 1470 requesting NI is allowed to request the policy rule to be loaded in 1471 the device. If this fails the NF or NR must send an error RESPONSE 1472 of class 'Permanent failure' (0x5) and with response code 1473 'Authorization failed' (0x02). 1475 3.7. Protocol Operations 1477 This section defines the protocol operations including, how to create 1478 NATFW NSLP signaling sessions, maintain them, delete them, and how to 1479 reserve addresses. 1481 This section requires a good knowledge of the NTLP 1482 ([I-D.ietf-nsis-ntlp]) and the message routing method mechanism and 1483 the associated message routing information (MRI). The NATFW NSLP 1484 uses information from the MRI, e.g., the destination and source 1485 ports, and the NATFW NSLP to construct the policy rules used on the 1486 NATFW NSLP level. See also Appendix D for further information about 1487 this. 1489 3.7.1. Creating Signaling Sessions 1491 Allowing two hosts to exchange data even in the presence of 1492 middleboxes is realized in the NATFW NSLP by use of the CREATE 1493 message. The NI (either the data sender or a proxy) generates a 1494 CREATE message as defined in Section 4.3.1 and hands it to the NTLP. 1496 The NTLP forwards the whole message on the basis of the message 1497 routing information (MRI) towards the NR. Each NSIS forwarder along 1498 the path that implements NATFW NSLP, processes the NSLP message. 1499 Forwarding is done hop-by-hop but may pass transparently through NSIS 1500 forwarders which do not contain NATFW NSLP functionality and non-NSIS 1501 aware routers between NSLP hop way points. When the message reaches 1502 the NR, the NR can accept the request or reject it. The NR generates 1503 a response to CREATE and this response is transported hop-by-hop 1504 towards the NI. NATFW NSLP forwarders may reject requests at any 1505 time. Figure 14 sketches the message flow between NI (DS in this 1506 example), a NF (e.g., NAT), and NR (DR in this example). 1508 NI Private Network NF Public Internet NR 1509 | | | 1510 | CREATE | | 1511 |----------------------------->| | 1512 | | | 1513 | | | 1514 | | CREATE | 1515 | |--------------------------->| 1516 | | | 1517 | | RESPONSE | 1518 | RESPONSE |<---------------------------| 1519 |<-----------------------------| | 1520 | | | 1521 | | | 1523 Figure 14: CREATE message flow with success RESPONSE 1525 There are several processing rules for a NATFW peer when generating 1526 and receiving CREATE messages, since this message type is used for 1527 creating new NATFW NSLP signaling session, updating existing, 1528 extending the lifetime and deleting NATFW NSLP signaling session. 1529 The three latter functions operate in the same way for all kinds of 1530 CREATE message, and are therefore described in separate sections: 1532 o Extending the lifetime of NATFW NSLP signaling sessions is 1533 described in Section 3.7.3. 1535 o Deleting NATFW NSLP signaling sessions is described in 1536 Section 3.7.4. 1538 o Updating policy rules is described in Section 3.10. 1540 For an initial CREATE message creating a new NATFW NSLP signaling 1541 session, the processing of CREATE messages is different for every 1542 NATFW node type: 1544 o NSLP initiator: An NI only generates CREATE messages and hands 1545 them over to the NTLP. The NI should never receive CREATE 1546 messages and MUST discard it. 1548 o NATFW NSLP forwarder: NFs that are unable to forward the CREATE 1549 message to the next hop MUST generate an error RESPONSE of class 1550 'Permanent failure' (0x6) with response code 'Did not reach the 1551 NR' (0x07). This case may occur if the NTLP layer cannot find an 1552 NATFW NSLP peer, either another NF or the NR, and returns an error 1553 via the GIST API (a timeout error reported by GIST). The NSLP 1554 message processing at the NFs depends on the middlebox type: 1556 * NAT: When the initial CREATE message is received at the public 1557 side of the NAT, it looks for a reservation made in advance, by 1558 using a EXTERNAL message (see Section 3.7.2). The matching 1559 process considers the received MRI information and the stored 1560 MRI information, as described in Section 3.8. If no matching 1561 reservation can be found, i.e., no reservation has been made in 1562 advance, the NSLP MUST return an error RESPONSE of class 1563 'Signaling session failure' (0x6) with response code 'No 1564 reservation found matching the MRI of the CREATE request' 1565 (0x03). If there is a matching reservation, the NSLP stores 1566 the data sender's address (and if applicable port number) as 1567 part of the source address of the policy rule ('the remembered 1568 policy rule') to be loaded and forwards the message with the 1569 destination address set to the internal (private in most cases) 1570 address of NR. When the initial CREATE message is received at 1571 the private side, the NAT binding is allocated, but not 1572 activated (see also Appendix D.3). An error RESPONSE message 1573 is generated, if the requested policy rule cannot be reserved 1574 right away, of class 'Signaling session failure' (0x6) with 1575 response code 'Requested policy rule denied due to policy 1576 conflict' (0x4). The MRI information is updated to reflect the 1577 address, and if applicable port, translation. The NSLP message 1578 is forwarded towards the NR with source address set to the 1579 NAT's external address from the newly remembered binding. 1581 * Firewall: When the initial CREATE message is received, the NSLP 1582 just remembers the requested policy rule, but does not install 1583 any policy rule. Afterwards, the message is forwarded towards 1584 the NR. An error RESPONSE message is generated, if the 1585 requested policy rule cannot be reserved right away, with of 1586 class 'Signaling session failure' (0x6) with response code 1587 'Requested policy rule denied due to policy conflict' (0x4). 1589 * Combined NAT and firewall: Processing at combined firewall and 1590 NAT middleboxes is the same as in the NAT case. No policy 1591 rules are installed. Implementations MUST take into account 1592 the order of packet processing in the firewall and NAT 1593 functions within the device. This will be referred to as 1594 'order of functions' and is generally different depending on 1595 whether the packet arrives at the external or internal side of 1596 the middlebox. 1598 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1599 with a success RESPONSE of class 'Success' (0x2) with response 1600 code set to 'All successfully processed' (0x01), if they accept 1601 the CREATE message. Otherwise they MUST generate a RESPONSE 1602 message with a suitable response code. RESPONSE messages are sent 1603 back NSLP hop-by-hop towards the NI, irrespective of the response 1604 codes, either success or error. 1606 Remembered policy rules at middleboxes MUST be only installed upon 1607 receiving a corresponding successful RESPONSE message with the same 1608 SID as the CREATE message that caused them to be remembered. This is 1609 a countermeasure to several problems, for example, wastage of 1610 resources due to loading policy rules at intermediate NFs when the 1611 CREATE message does not reach the final NR for some reason. 1613 Processing of a RESPONSE message is different for every NSIS node 1614 type: 1616 o NSLP initiator: After receiving a successful RESPONSE, the data 1617 path is configured and the DS can start sending its data to the 1618 DR. After receiving an error RESPONSE message, the NI MAY try to 1619 generate the CREATE message again or give up and report the 1620 failure to the application, depending on the error condition. 1622 o NSLP forwarder: NFs install the remembered policy rules, if a 1623 successful RESPONSE message with matching SID is received. If an 1624 ERROR RESPONSE message with matching SID is received, the NATFW 1625 NSLP session is marked as dead, no policy rule is installed and 1626 the remembered rule is discarded. 1628 o NSIS responder: The NR should never receive RESPONSE messages and 1629 MUST silently drop any such messages received. 1631 NFs and the NR can also tear down the CREATE session at any time by 1632 generating a NOTIFY message with the appropriate response code set. 1634 3.7.2. Reserving External Addresses 1636 NSIS signaling is intended to travel end-to-end, even in the presence 1637 of NATs and firewalls on-path. This works well in cases where the 1638 data sender is itself behind a NAT or a firewall as described in 1639 Section 3.7.1. For scenarios where the data receiver is located 1640 behind a NAT or a firewall and it needs to receive data flows from 1641 outside its own network (usually referred to as inbound flows, see 1642 Figure 5) the problem is more troublesome. 1644 NSIS signaling, as well as subsequent data flows, are directed to a 1645 particular destination IP address that must be known in advance and 1646 reachable. Data receivers must tell the local NSIS infrastructure 1647 (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP 1648 signaling and data flows before they can receive these flows. It is 1649 necessary to differentiate between data receivers behind NATs and 1650 behind firewalls for understanding the further NATFW procedures. 1651 Data receivers that are only behind firewalls already have a public 1652 IP address and they need only to be reachable for NATFW signaling. 1653 Unlike data receivers behind just firewalls, data receivers behind 1654 NATs do not have public IP addresses; consequently they are not 1655 reachable for NATFW signaling by entities outside their addressing 1656 realm. 1658 The preceding discussion addresses the situation where a DR node that 1659 wants to be reachable is unreachable because the NAT lacks a suitable 1660 rule with the 'allow' action which would forward inbound data. 1661 However, in certain scenarios, a node situated behind inbound 1662 firewalls that do not block inbound data traffic (firewalls with 1663 "default to allow") unless requested might wish to prevent traffic 1664 being sent to it from specified addresses. In this case, NSIS NATFW 1665 signaling can be used to achieve this by installing a policy rule 1666 with its action set to 'deny' using the same mechanisms as for 1667 'allow' rules. 1669 The required result is obtained by sending a EXTERNAL message in the 1670 inbound direction of the intended data flow. When using this 1671 functionality the NSIS initiator for the 'Reserve External Address' 1672 signaling is typically the node that will become the DR for the 1673 eventual data flow. To distinguish this initiator from the usual 1674 case where the NI is associated with the DS, the NI is denoted by NI+ 1675 and the NSIS responder is similarly denoted by NR+. 1677 Public Internet Private Address 1678 Space 1680 Edge 1681 NI(DS) NAT/FW NAT NR(DR) 1682 NR+ NI+ 1684 | | | | 1685 | | | | 1686 | | | | 1687 | | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] | 1688 | |<----------------------|<----------------------| 1689 | | | | 1690 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1691 | |---------------------->|---------------------->| 1692 | | | | 1693 | | | | 1695 ============================================================> 1696 Data Traffic Direction 1698 Figure 15: Reservation message flow for DR behind NAT or firewall 1700 Figure 15 shows the EXTERNAL message flow for enabling inbound NATFW 1701 NSLP signaling messages. In this case the roles of the different 1702 NSIS entities are: 1704 o The data receiver (DR) for the anticipated data traffic is the 1705 NSIS initiator (NI+) for the EXTERNAL message, but becomes the 1706 NSIS responder (NR) for following CREATE messages. 1708 o The actual data sender (DS) will be the NSIS initiator (NI) for 1709 later CREATE messages and may be the NSIS target of the signaling 1710 (NR+). 1712 o It may be necessary to use a signaling destination address (SDA) 1713 as the actual target of the EXTERNAL message (NR+) if the DR is 1714 located behind a NAT and the address of the DS is unknown. The 1715 SDA is an arbitrary address in the outermost address realm on the 1716 other side of the NAT from the DR. Typically this will be a 1717 suitable public IP address when the 'outside' realm is the public 1718 Internet. This choice of address causes the EXTERNAL message to 1719 be routed through the NATs towards the outermost realm and would 1720 force interception of the message by the outermost NAT in the 1721 network at the boundary between the private address and the public 1722 address realm (the edge-NAT). It may also be intercepted by other 1723 NATs and firewalls on the path to the edge-NAT. 1725 Basically, there are two different signaling scenarios. Either 1727 1. the DR behind the NAT/firewall knows the IP address of the DS in 1728 advance, 1730 2. or the address of DS is not known in advance. 1732 Case 1 requires the NATFW NSLP to request the path-coupled message 1733 routing method (PC-MRM) from the NTLP. The EXTERNAL message MUST be 1734 sent with PC-MRM (see Section 5.8.1 in [I-D.ietf-nsis-ntlp]) with the 1735 direction set to 'upstream' (inbound). The handling of case 2 1736 depends on the situation of DR: If DR is solely located behind a 1737 firewall, the EXTERNAL message MUST be sent with the PC-MRM, 1738 direction 'upstream' (inbound), and data flow source IP address set 1739 to wildcard. If DR is located behind a NAT, the EXTERNAL message 1740 MUST be sent with the loose-end message routing method (LE-MRM, see 1741 Section 5.8.2 in [I-D.ietf-nsis-ntlp]), the destination-address set 1742 to the signaling destination address (SDA, see also Appendix A). For 1743 scenarios with DR being behind a firewall, special conditions apply 1744 (see applicability statement in Appendix C). The data receiver is 1745 challenged to determine whether it is solely located behind firewalls 1746 or NATs, for choosing the right message routing method. This 1747 decision can depend on a local configuration parameter, possibly 1748 given through DHCP, or it could be discovered through other non-NSLP 1749 related testing of the network configuration. It is RECOMMENDED to 1750 use the PC-MRM with the known data sender's IP address. This gives 1751 GIST the best possible handled to route the message 'upstream' 1752 (outbound). It is RECOMMENDED to use the LE-MRM, if and only if the 1753 data sender's IP address is not known and the data receiver is behind 1754 a NAT. 1756 For case 2 with NAT, the NI+ (which could be on the data receiver DR 1757 or on any other host within the private network) sends the EXTERNAL 1758 message targeted to the signaling destination address. The message 1759 routing for the EXTERNAL message is in the reverse direction to the 1760 normal message routing used for path-coupled signaling where the 1761 signaling is sent outbound (as opposed to inbound in this case). 1762 When establishing NAT bindings (and an NATFW NSLP signaling session) 1763 the signaling direction does not matter since the data path is 1764 modified through route pinning due to the external IP address at the 1765 NAT. Subsequent NSIS messages (and also data traffic) will travel 1766 through the same NAT boxes. However, this is only valid for the NAT 1767 boxes, but not for any intermediate firewall. That is the reason for 1768 having a separate CREATE message enabling the reservations made with 1769 EXTERNAL at the NATs and either enabling prior reservations or 1770 creating new pinholes at the firewalls which are encountered on the 1771 outbound path depending on whether the inbound and outbound routes 1772 coincide. 1774 The EXTERNAL signaling message creates an NSIS NATFW signaling 1775 session at any intermediate NSIS NATFW peer(s) encountered, 1776 independent of the message routing method used. Furthermore, it has 1777 to be ensured that the edge-NAT or edge-firewall device is discovered 1778 as part of this process. The end host cannot be assumed to know this 1779 device - instead the NAT or firewall box itself is assumed to know 1780 that it is located at the outer perimeter of the network. Forwarding 1781 of the EXTERNAL message beyond this entity is not necessary, and MUST 1782 be prohibited as it may provide information on the capabilities of 1783 internal hosts. It should be noted, that it is the outermost NAT or 1784 firewall that is the edge-device that must be found during this 1785 discovery process. For instance, when there are a NAT and afterwards 1786 a firewall on the outbound path at the network border, the firewall 1787 is the edge-firewall. All messages must be forwarded to the 1788 topology-wise outermost edge-device, to ensure that this device knows 1789 about the NATFW NSLP signaling sessions for incoming CREATE messages. 1790 However, the NAT is still the edge-NAT because it has a public 1791 globally routable IP address on its public side: this is not affected 1792 by any firewall between the edge-NAT and the public network. 1794 Possible edge arrangements are: 1796 Public Net ----------------- Private net -------------- 1798 | Public Net|--|Edge-FW|--|FW|...|FW|--|DR| 1800 | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR| 1802 | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR| 1804 The edge-NAT or edge-firewall device closest to the public realm 1805 responds to the EXTERNAL request message with a successful RESPONSE 1806 message. An edge-NAT includes an NATFW_EXTERNAL-IP object (see 1807 Section 4.2.2), carrying the public reachable IP address, and if 1808 applicable port number. 1810 The NI+ can request each intermediate NAT (i.e., a NAT that is not 1811 the edge-NAT) to include the external binding address (and if 1812 applicable port number) in the external binding address object. The 1813 external binding address object stores the external IP address (and 1814 port) at the particular NAT. The NI+ has to include the external 1815 binding address (see Section 4.2.3) object in the request message, if 1816 it wishes to obtain the information. 1818 There are several processing rules for a NATFW peer when generating 1819 and receiving EXTERNAL messages, since this message type is used for 1820 creating new reserve NATFW NSLP signaling sessions, updating 1821 existing, extending the lifetime and deleting NATFW NSLP signaling 1822 session. The three latter functions operate in the same way for all 1823 kinds of CREATE and EXTERNAL messages, and are therefore described in 1824 separate sections: 1826 o Extending the lifetime of NATFW NSLP signaling sessions is 1827 described in Section 3.7.3. 1829 o Deleting NATFW NSLP signaling sessions is described in 1830 Section 3.7.4. 1832 o Updating policy rules is described in Section 3.10. 1834 The NI+ MUST always include a NATFW_DTINFO object in the EXTERNAL 1835 message. Especially, the LE-MRM does not include enough information 1836 for some types of NATs (basically, those NATs which also translate 1837 port numbers) to perform the address translation. This information 1838 is provided in the NATFW_DTINFO (see Section 4.2.8). This 1839 information MUST include at least the 'dst port number' and 1840 'protocol' fields, in the NATFW_DTINFO object as these may be 1841 required by en-route NATs, depending on the type of the NAT. All 1842 other fields MAY be set by the NI+ to restrict the set of possible 1843 NIs. An edge-NAT will use the information provided in the 1844 NATFW_DTINFO object to allow only a NATFW CREATE message with a 1845 matching MRI to be forwarded. The MRI of the NATFW CREATE message 1846 has to use the parameters set in NATFW_DTINFO object ('src IPv4/v6 1847 address', 'src port number', 'protocol') as the source address/port 1848 of the flow from DS to DR. A NAT requiring information carried in 1849 the NATFW_DTINFO can generate a number of error RESPONSE messages of 1850 class 'Signaling session failure' (0x6): 1852 o 'Requested policy rule denied due to policy conflict' (0x04) 1854 o 'NATFW_DTINFO object is required' (0x07) 1856 o 'Requested value in sub_ports field in NATFW_EFI not permitted' 1857 (0x08) 1859 o 'Requested IP protocol not supported' (0x09) 1861 o 'Plain IP policy rules not permitted -- need transport layer 1862 information' (0x0A) 1864 o 'source IP address range is too large' (0x0C) 1866 o 'destination IP address range is too large' (0x0D) 1867 o 'source L4-port range is too large' (0x0E) 1869 o 'destination L4-port range is too large' (0x0F) 1871 Processing of EXTERNAL messages is specific to the NSIS node type: 1873 o NSLP initiator: NI+ only generate EXTERNAL messages. When the 1874 data sender's address information is known in advance the NI+ can 1875 include a NATFW_DTINFO object in the EXTERNAL message, if not 1876 anyway required to do so (see above). When the data sender's IP 1877 address is not known, the NI+ MUST NOT include an IP address in 1878 the NATFW_DTINFO object. The NI should never receive EXTERNAL 1879 messages and MUST silently discard it. 1881 o NSLP forwarder: The NSLP message processing at NFs depends on the 1882 middlebox type: 1884 * NAT: NATs check whether the message is received at the external 1885 (public in most cases) address or at the internal (private) 1886 address. If received at the external an NF MUST generate an 1887 error RESPONSE of class 'Protocol error' (0x3) with response 1888 code 'Received EXTERNAL request message on external side' 1889 (0x0B). If received at the internal (private address) and the 1890 NATFW_EFI object contains the action 'deny', an error RESPONSE 1891 of class 'Protocol error' (0x3) with response code 'Requested 1892 rule action not applicable' (0x06) MUST be generated. If 1893 received at the internal address, an IP address, and if 1894 applicable one or more ports, are reserved. If the 1895 NATFW_EXTERNAL_BINDING object is present in the message, any 1896 NAT that is not an edge-NAT MUST include the allocated external 1897 IP address, and if applicable one or more ports, (the external 1898 binding address) in the NATFW_EXTERNAL_BINDING object. If it 1899 is an edge-NAT and there is no edge-firewall beyond, the NSLP 1900 message is not forwarded any further and a successful RESPONSE 1901 message is generated containing an NATFW_EXTERNAL-IP object 1902 holding the translated address, and if applicable, port 1903 information from the binding reserved as a result of the 1904 EXTERNAL message. The edge-NAT MUST copy the 1905 NATFW_EXTERNAL_BINDING object to response message, if the 1906 object is included in the EXTERNAL message. The RESPONSE 1907 message is sent back towards the NI+. If it is not an edge- 1908 NAT, the NSLP message is forwarded further using the translated 1909 IP address as signaling source address in the LE-MRM and 1910 translated port in the NATFW_DTINFO object in the field 'DR 1911 port number', i.e., the NATFW_DTINFO object is updated to 1912 reflect the translated port number. The edge-NAT or any other 1913 NAT MUST reject EXTERNAL messages not carrying a NATFW_DTINFO 1914 object or if the address information within this object is 1915 invalid or is not compliant with local policies (e.g., the 1916 information provided relates to a range of addresses 1917 ('wildcarded') but the edge-NAT requires exact information 1918 about DS' IP address and port) with the above mentioned 1919 response codes. 1921 * Firewall: Non edge-firewalls remember the requested policy 1922 rule, keep NATFW NSLP signaling session state, and forward the 1923 message. Edge-firewalls stop forwarding the EXTERNAL message. 1924 The policy rule is immediately loaded if the action in the 1925 NATFW_EFI object is set to 'deny' and the node is an edge- 1926 firewall. The policy rule is remembered, but not activated, if 1927 the action in the NATFW_EFI object is set to 'allow'. In both 1928 cases, a successful RESPONSE message is generated. If the 1929 action is 'allow', and the NATFW_DTINFO object is included, and 1930 the MRM is set to LE-MRM in the request, additionally an 1931 NATFW_EXTERNAL-IP object is included in the RESPONSE message, 1932 holding the translated address, and if applicable port, 1933 information. This information is obtained from the 1934 NATFW_DTINFO object's 'DR port number' and the source-address 1935 of the LE-MRM. The edge-firewall MUST copy the 1936 NATFW_EXTERNAL_BINDING object to response message, if the 1937 object is included in the EXTERNAL message. 1939 * Combined NAT and firewall: Processing at combined firewall and 1940 NAT middleboxes is the same as in the NAT case. 1942 o NSLP receiver: This type of message should never be received by 1943 any NR+ and it MUST generate an error RESPONSE message of class 1944 'Permanent failure' (0x5) with response code 'No edge-device here' 1945 (0x06). 1947 Processing of a RESPONSE message is different for every NSIS node 1948 type: 1950 o NSLP initiator: Upon receiving a successful RESPONSE message, the 1951 NI+ can rely on the requested configuration for future inbound 1952 NATFW NSLP signaling sessions. If the response contains an 1953 NATFW_EXTERNAL-IP object, the NI can use IP address and port pairs 1954 carried for further application signaling. After receiving a 1955 error RESPONSE message, the NI+ MAY try to generate the EXTERNAL 1956 message again or give up and report the failure to the 1957 application, depending on the error condition. 1959 o NSLP forwarder: NFs simply forward this message as long as they 1960 keep state for the requested reservation, if the RESPONSE message 1961 contains NATFW_INFO object with class set to 'Success' (0x2). If 1962 the RESPONSE message contains NATFW_INFO object with class set not 1963 to 'Success' (0x2), the NATFW NSLP signaling session is marked as 1964 dead. 1966 o NSIS responder: This type of message should never be received by 1967 any NR+. The NF should never receive response messages and MUST 1968 silently discard it. 1970 NFs and the NR can also tear down the EXTERNAL session at any time by 1971 generating a NOTIFY message with the appropriate response code set. 1973 Reservations with action 'allow' made with EXTERNAL MUST be enabled 1974 by a subsequent CREATE message. A reservation made with EXTERNAL 1975 (independent of selected action) is kept alive as long as the NI+ 1976 refreshes the particular NATFW NSLP signaling session and it can be 1977 reused for multiple, different CREATE messages. An NI+ may decide to 1978 teardown a reservation immediately after receiving a CREATE message. 1979 This implies that a new NATFW NSLP signaling session must be created 1980 for each new CREATE message. The CREATE message does not re-use the 1981 NATFW NSLP signaling session created by EXTERNAL. 1983 Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode 1984 (see Section 3.7.6) no data traffic will be forwarded to DR beyond 1985 the edge-NAT or edge-firewall. The only function of EXTERNAL is to 1986 ensure that subsequent CREATE messages traveling towards the NR will 1987 be forwarded across the public-private boundary towards the DR. 1988 Correlation of incoming CREATE messages to EXTERNAL reservation 1989 states is described in Section 3.8. 1991 3.7.3. NATFW NSLP Signaling Session Refresh 1993 NATFW NSLP signaling sessions are maintained on a soft-state basis. 1994 After a specified timeout, sessions and corresponding policy rules 1995 are removed automatically by the middlebox, if they are not 1996 refreshed. Soft-state is created by CREATE and EXTERNAL and the 1997 maintenance of this state must be done by these messages. State 1998 created by CREATE must be maintained by CREATE, state created by 1999 EXTERNAL must be maintained by EXTERNAL. Refresh messages, are 2000 messages carrying the same session ID as the initial message and a 2001 NATFW_LT lifetime object with a lifetime greater than zero. Messages 2002 with the same SID but carrying a different MRI are treated as updates 2003 of the policy rules and are processed as defined in Section 3.10. 2004 Every refresh CREATE or EXTERNAL message MUST be acknowledged by an 2005 appropriate response message generated by the NR. Upon reception by 2006 each NSIS forwarder, the state for the given session ID is extended 2007 by the NATFW NSLP signaling session refresh period, a period of time 2008 calculated based on a proposed refresh message period. The new 2009 (extended) lifetime of a NATFW NSLP signaling session is calculated 2010 as current local time plus proposed lifetime value (NATFW NSLP 2011 signaling session refresh period). Section 3.4 defines the process 2012 of calculating lifetimes in detail. 2014 NI Public Internet NAT Private address NR 2016 | | space | 2017 | CREATE[lifetime > 0] | | 2019 |----------------------------->| | 2020 | | | 2021 | | | 2022 | | CREATE[lifetime > 0] | 2023 | |--------------------------->| 2024 | | | 2025 | | RESPONSE[Success/Error] | 2026 | RESPONSE[Success/Error] |<---------------------------| 2027 |<-----------------------------| | 2028 | | | 2029 | | | 2031 Figure 16: Successful Refresh Message Flow, CREATE as example 2033 Processing of NATFW NSLP signaling session refresh CREATE and 2034 EXTERNAL messages is different for every NSIS node type: 2036 o NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling 2037 session refresh CREATE/EXTERNAL messages before the NATFW NSLP 2038 signaling session times out. The rate at which the refresh 2039 CREATE/EXTERNAL messages are sent and their relation to the NATFW 2040 NSLP signaling session state lifetime is discussed further in 2041 Section 3.4. 2043 o NSLP forwarder: Processing of this message is independent of the 2044 middlebox type and is as described in Section 3.4. 2046 o NSLP responder: NRs accepting a NATFW NSLP signaling session 2047 refresh CREATE/EXTERNAL message generate a successful RESPONSE 2048 message, including the granted lifetime value of Section 3.4 in a 2049 NATFW_LT object. 2051 3.7.4. Deleting Signaling Sessions 2053 NATFW NSLP signaling sessions can be deleted at any time. NSLP 2054 initiators can trigger this deletion by using a CREATE or EXTERNAL 2055 messages with a lifetime value set to 0, as shown in Figure 17. 2056 Whether a CREATE or EXTERNAL message type is used, depends on how the 2057 NATFW NSLP signaling session was created. 2059 NI Public Internet NAT Private address NR 2061 | | space | 2062 | CREATE[lifetime=0] | | 2063 |----------------------------->| | 2064 | | | 2065 | | CREATE[lifetime=0] | 2066 | |--------------------------->| 2067 | | | 2069 Figure 17: Delete message flow, CREATE as example 2071 NSLP nodes receiving this message delete the NATFW NSLP signaling 2072 session immediately. Policy rules associated with this particular 2073 NATFW NSLP signaling session MUST be also deleted immediately. This 2074 message is forwarded until it reaches the final NR. The CREATE/ 2075 EXTERNAL message with a lifetime value of 0, does not generate any 2076 response, neither positive nor negative, since there is no NSIS state 2077 left at the nodes along the path. 2079 NSIS initiators can use CREATE/EXTERNAL message with lifetime set to 2080 zero in an aggregated way, such that a single CREATE or EXTERNAL 2081 message is terminating multiple NATFW NSLP signaling sessions. NIs 2082 can follow this procedure if they like to aggregate NATFW NSLP 2083 signaling session deletion requests: The NI uses the CREATE or 2084 EXTERNAL message with the session ID set to zero and the MRI's 2085 source-address set to its used IP address. All other fields of the 2086 respective NATFW NSLP signaling sessions to be terminated are set as 2087 well, otherwise these fields are completely wildcarded. The NSLP 2088 message is transferred to the NTLP requesting 'explicit routing' as 2089 described in Sections 5.2.1 and 7.1.4. in [I-D.ietf-nsis-ntlp]. 2091 The outbound NF receiving such an aggregated CREATE or EXTERNAL 2092 message MUST reject it with an error RESPONSE of class 'Permanent 2093 failure' (0x5) with response code 'Authentication failed' (0x01) if 2094 the authentication fails and with an error RESPONSE of class 2095 'Permanent failure' (0x5) with response code 'Authorization failed' 2096 (0x02) if the authorization fails. Per NATFW NSLP signaling session 2097 proof of ownership, as it is defined in this memo, is not possible 2098 anymore when using this aggregated way. However, the outbound NF can 2099 use the relationship between the information of the received CREATE 2100 or EXTERNAL message and the GIST messaging association where the 2101 request has been received. The outbound NF MUST only accept this 2102 aggregated CREATE or EXTERNAL message through already established 2103 GIST messaging associations with the NI. The outbound NF MUST NOT 2104 propagate this aggregated CREATE or EXTERNAL message but it MAY 2105 generate and forward per NATFW NSLP signaling session CREATE or 2106 EXTERNAL messages. 2108 3.7.5. Reporting Asynchronous Events 2110 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 2111 to report asynchronous events to other NATFW NSLP nodes, especially 2112 to allow reporting back to the NATFW NSLP initiator. Such 2113 asynchronous events may be premature NATFW NSLP signaling session 2114 termination, changes in local policies, route change or any other 2115 reason that indicates change of the NATFW NSLP signaling session 2116 state. 2118 NFs and NRs may generate NOTIFY messages upon asynchronous events, 2119 with a NATFW_INFO object indicating the reason for event. These 2120 reasons can be carried in the NATFW_INFO object (class MUST be set to 2121 'Informational' (0x1)) within the NOTIFY message. This list shows 2122 the response codes and the associated actions to take at NFs and the 2123 NI: 2125 o 'Route change: possible route change on the outbound path' (0x01): 2126 Follow instructions in Section 3.9. This MUST be sent inbound and 2127 outbound, if the signalling session is any state except 2128 'Transitory'. The NOTIFY message for signalling sessions in state 2129 transitory MUST be discarded, as the signalling session is anyhow 2130 transitory. The outbound NOTIFY message MUST be sent with 2131 explicit routing by providing the SII-Handle to the NTLP. 2133 o 'Re-authentication required' (0x02): The NI should re-send the 2134 authentication. This MUST be sent inbound. 2136 o 'NATFW node is going down soon' (0x03): The NI and other NFs 2137 should be prepared for a service interruption at any time. This 2138 message MAY be sent inbound and outbound. 2140 o 'NATFW signaling session lifetime expired' (0x04): The NATFW 2141 signaling session has been expired and the signaling session is 2142 invalid now. NFs MUST mark the signaling session as 'Dead'. This 2143 message MAY be sent inbound and outbound. 2145 o 'NATFW signaling session terminated' (0x05): The NATFW signaling 2146 session has been terminated by any reason and the signaling 2147 session is invalid now. NFs MUST mark the signaling session as 2148 'Dead'. This message MAY be sent inbound and outbound. 2150 NOTIFY messages are always sent hop-by-hop inbound towards NI until 2151 they reach NI or outbound towards the NR as indicated in the list 2152 above. 2154 The initial processing when receiving a NOTIFY message is the same 2155 for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages 2156 through already established NTLP messaging associations. The further 2157 processing is different for each NATFW NSLP node type and depends on 2158 the events notified: 2160 o NSLP initiator: NIs analyze the notified event and behave 2161 appropriately based on the event type. NIs MUST NOT generate 2162 NOTIFY messages. 2164 o NSLP forwarder: NFs analyze the notified event and behave based on 2165 the above description per response code. NFs SHOULD generate 2166 NOTIFY messages upon asynchronous events and forward them inbound 2167 towards the NI or outbound towards the NR, depending on the 2168 received direction, i.e., inbound messages MUST be forwarded 2169 further inbound and outbound messages MUST be forwarded further 2170 outbound. NFs MUST silently discard NOTIFY messages that have 2171 been received outbound but are only allowed to be sent inbound, 2172 e.g. 'Re-authentication required' (0x02). 2174 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 2175 asynchronous events including a response code based on the 2176 reported event. The NR MUST silently discard NOTIFY messages that 2177 have been received outbound but are only allowed to be sent 2178 inbound, e.g. 'Re-authentication required' (0x02), 2180 NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions 2181 at the same time, can experience problems when shutting down service 2182 suddenly. This sudden shutdown can be result of node local failure, 2183 for instance, due to a hardware failure. This NF generates NOTIFY 2184 messages for each of the NATFW NSLP signaling sessions and tries to 2185 send them inbound. Due to the number of NOTIFY messages to be sent, 2186 the shutdown of the node may be unnecessarily prolonged, since not 2187 all messages can be sent at the same time. This case can be 2188 described as a NOTIFY storm, if a multitude of NATFW NSLP signaling 2189 sessions is involved. 2191 To avoid the need of generating per NATFW NSLP signaling session 2192 NOTIFY messages in such a scenario described or similar cases, NFs 2193 SHOULD follow this procedure: The NF uses the NOTIFY message with the 2194 session ID in the NTLP set to zero, with the MRI completely 2195 wildcarded, using the 'explicit routing' as described in Sections 2196 5.2.1 and 7.1.4. in [I-D.ietf-nsis-ntlp]. The inbound NF receiving 2197 this type of NOTIFY immediately regards all NATFW NSLP signaling 2198 sessions from that peer matching the MRI as void. This message will 2199 typically result in multiple NOTIFY messages at the inbound NF, i.e., 2200 the NF can generate per terminated NATFW NSLP signaling session a 2201 NOTIFY message. However, a NF MAY aggregate again the NOTIFY 2202 messages as described here. 2204 3.7.6. Proxy Mode of Operation 2206 Some migration scenarios need specialized support to cope with cases 2207 where NSIS is only deployed in same areas of the Internet. End-to- 2208 end signaling is going to fail without NSIS support at or near both 2209 data sender and data receiver terminals. A proxy mode of operation 2210 is needed. This proxy mode of operation must terminate the NATFW 2211 NSLP signaling topologically-wise as close as possible to the 2212 terminal for which it is proxying and proxy all messages. This NATFW 2213 NSLP node doing the proxying of the signaling messages becomes either 2214 the NI or the NR for the particular NATFW NSLP signaling session, 2215 depending on whether it is the DS or DR that does not support NSIS. 2216 Typically, the edge-NAT or the edge-firewall would be used to proxy 2217 NATFW NSLP messages. 2219 This proxy mode operation does not require any new CREATE or EXTERNAL 2220 message type, but relies on extended CREATE and EXTERNAL message 2221 types. They are called respectively CREATE-PROXY and EXTERNAL-PROXY 2222 and are distinguished by setting the P flag in the NSLP header to 2223 P=1. This flag instructs edge-NATs and edge-firewalls receiving them 2224 to operate in proxy mode for the NATFW NSLP signaling session in 2225 question. The semantics of the CREATE and EXTERNAL message types are 2226 not changed and the behavior of the various node types is as defined 2227 in Section 3.7.1 and Section 3.7.2, except for the proxying node. 2228 The following paragraphs describe the proxy mode operation for data 2229 receivers behind middleboxes and data senders behind middleboxes. 2231 3.7.6.1. Proxying for a Data Sender 2233 The NATFW NSLP gives the NR the ability to install state on the 2234 inbound path towards the data sender for outbound data packets, even 2235 when only the receiving side is running NSIS (as shown in Figure 18). 2236 The goal of the method described is to trigger the edge-NAT/ 2237 edge-firewall to generate a CREATE message on behalf of the data 2238 receiver. In this case, an NR can signal towards the network border 2239 as it is performed in the standard EXTERNAL message handling scenario 2240 as in Section 3.7.2. The message is forwarded until the edge-NAT/ 2241 edge-firewall is reached. A public IP address and port number is 2242 reserved at an edge-NAT/edge-firewall. As shown in Figure 18, unlike 2243 the standard EXTERNAL message handling case, the edge-NAT/ 2244 edge-firewall is triggered to send a CREATE message on a new reverse 2245 path which traverse several firewalls or NATs. The new reverse path 2246 for CREATE is necessary to handle routing asymmetries between the 2247 edge-NAT/edge-firewall and DR. It must be stressed that the 2248 semantics of the CREATE and EXTERNAL messages is not changed, i.e., 2249 each is processed as described earlier. 2251 DS Public Internet NAT/FW Private address DR 2252 No NI NF space NR 2253 NR+ NI+ 2255 | | EXTERNAL-PROXY[(DTInfo)] | 2256 | |<------------------------- | 2257 | | RESPONSE[Error/Success] | 2258 | | ---------------------- > | 2259 | | CREATE | 2260 | | ------------------------> | 2261 | | RESPONSE[Error/Success] | 2262 | | <---------------------- | 2263 | | | 2265 Figure 18: EXTERNAL Triggering Sending of CREATE Message 2267 A NATFW_NONCE object, carried in the EXTERNAL and CREATE message, is 2268 used to build the relationship between received CREATEs at the 2269 message initiator. An NI+ uses the presence of the NATFW_NONCE 2270 object to correlate it to the particular EXTERNAL-PROXY. The absence 2271 of a NONCE object indicates a CREATE initiated by the DS and not by 2272 the edge-NAT. The two signaling sessions, i.e., the session for 2273 EXTERNAL-PROXY and the session for CREATE, are not independent. The 2274 primary session is the EXTERNAL-PROXY session. The CREATE session is 2275 secondary to the EXTERNAL-PROXY session, i.e., the CREATE session is 2276 valid as long as the EXTERNAL-PROXY session is the signaling states 2277 'Established' or 'Transitory'. There is no CREATE session in any 2278 other signaling state of the EXTERNAL-PROXY, i.e., 'pending' or 2279 'dead'. This ensures a fate-sharing between both signaling sessions. 2281 These processing rules of EXTERNAL-PROXY messages are added to the 2282 regular EXTERNAL processing: 2284 o NSLP initiator (NI+): The NI+ MUST take the session ID (SID) value 2285 of the EXTERNAL-PROXY session as the nonce value of the 2286 NATFW_NONCE object. 2288 o NSLP forwarder being either edge-NAT or edge-firewall: When the NF 2289 accepts a EXTERNAL-PROXY message, it generates a successful 2290 RESPONSE message as if it were the NR and additionally, it 2291 generates a CREATE message as defined in Section 3.7.1 and 2292 includes a NATFW_NONCE object having the same value as of the 2293 received NATFW_NONCE object. The NF MUST NOT generate a CREATE- 2294 PROXY message. The NF MUST refresh the CREATE message signaling 2295 session only if a EXTERNAL-PROXY refresh message has been received 2296 first. This also includes tearing down signaling sessions, i.e., 2297 the NF must teardown the CREATE signaling session only if a 2298 EXTERNAL-PROXY message with lifetime set to 0 has been received 2299 first. 2301 The scenario described in this section challenges the data receiver 2302 because it must make a correct assumption about the data sender's 2303 ability to use NSIS NATFW NSLP signaling. It is possible for the DR 2304 to make the wrong assumption in two different ways: 2306 a) the DS is NSIS unaware but the DR assumes the DS to be NSIS 2307 aware and 2309 b) the DS is NSIS aware but the DR assumes the DS to be NSIS 2310 unaware. 2312 Case a) will result in middleboxes blocking the data traffic, since 2313 DS will never send the expected CREATE message. Case b) will result 2314 in the DR successfully requesting proxy mode support by the edge-NAT 2315 or edge-firewall. The edge-NAT/edge-firewall will send CREATE 2316 messages and DS will send CREATE messages as well. Both CREATE 2317 messages are handled as separated NATFW NSLP signaling sessions and 2318 therefore the common rules per NATFW NSLP signaling session apply; 2319 the NATFW_NONCE object is used to differentiate CREATE messages 2320 generated by the edge-NAT/edge-firewall from NI initiated CREATE 2321 messages. It is the NR's responsibility to decide whether to 2322 teardown the EXTERNAL-PROXY signaling sessions in the case where the 2323 data sender's side is NSIS aware, but was incorrectly assumed not to 2324 be so by the DR. It is RECOMMENDED that a DR behind NATs uses the 2325 proxy mode of operation by default, unless the DR knows that the DS 2326 is NSIS aware. The DR MAY cache information about data senders which 2327 it has found to be NSIS aware in past NATFW NSLP signaling sessions. 2329 There is a possible race condition between the RESPONSE message to 2330 the EXTERNAL-PROXY and the CREATE message generated by the edge-NAT. 2331 The CREATE message can arrive earlier than the RESPONSE message. An 2332 NI+ MUST accept CREATE messages generated by the edge-NAT even if the 2333 RESPONSE message to the EXTERNAL-PROXY was not received. 2335 3.7.6.2. Proxying for a Data Receiver 2337 As with data receivers behind middleboxes, data senders behind 2338 middleboxes can require proxy mode support. The issue here is that 2339 there is no NSIS support at the data receiver's side and, by default, 2340 there will be no response to CREATE messages. This scenario requires 2341 the last NSIS NATFW NSLP aware node to terminate the forwarding and 2342 to proxy the response to the CREATE message, meaning that this node 2343 is generating RESPONSE messages. This last node may be an edge-NAT/ 2344 edge-firewall, or any other NATFW NSLP peer, that detects that there 2345 is no NR available (probably as a result of GIST timeouts but there 2346 may be other triggers). 2348 DS Private Address NAT/FW Public Internet NR 2349 NI Space NF no NR 2351 | | | 2352 | CREATE-PROXY | | 2353 |------------------------------>| | 2354 | | | 2355 | RESPONSE[SUCCESS/ERROR] | | 2356 |<------------------------------| | 2357 | | | 2359 Figure 19: Proxy Mode CREATE Message Flow 2361 The processing of CREATE-PROXY messages and RESPONSE messages is 2362 similar to Section 3.7.1, except that forwarding is stopped at the 2363 edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to 2364 NI according to the situation (error/success) and will be the NR for 2365 future NATFW NSLP communication. 2367 The NI can choose the proxy mode of operation although the DR is NSIS 2368 aware. The CREATE-PROXY mode would not configure all NATs and 2369 firewalls along the data path, since it is terminated at the edge- 2370 device. Any device beyond this point will never receive any NATFW 2371 NSLP signaling for this flow. 2373 3.7.6.3. Incremental Deployment using the Proxy Mode 2375 The above sections described the the proxy mode for cases where the 2376 NATFW NSLP is solely deployed at the network edges. However, the 2377 NATFW NSLP might be incrementally deployed first in some network 2378 edges, but later on also in other parts of the network. Using the 2379 proxy mode only, would prevent the NI to determine whether the other 2380 parts of the network have also been upgraded to use the NATFW NSLP. 2381 One way of determining whether the path from the NI to the NR is 2382 NATFW NSLP capable is to use the regular CREATE message and to wait 2383 for a successful response or an error response. This will lead to 2384 extra messages being sent, as a CREATE message in addition to the 2385 anyhow required CREATE-PROXY message is sent from the NI. 2387 The NATFW NSLP allows the usage of the proxy-mode and a further 2388 probing of the path by the edge-NAT or edge-firewall. The NI can 2389 request proxy-mode handling as described, and can set the E flag (see 2390 Section Figure 20) to request the edge-NAT or edge-firewall to probe 2391 the further path for NATFW NSLP enabled NFs or NR. 2393 The edge-NAT or edge-firewall MUST continue to send the CREATE-PROXY 2394 or EXTERNAL-proxy towards the NR, if the received proxy-mode message 2395 has the E flag set, in addition to the regular proxy mode handling. 2397 The edge-NAT or edge-firewall relies on the NTLP measures to 2398 determine whether there is no other NATFW NSLP reachable towards NR. 2399 A failed attempt to forward the request message to the NR will be 2400 silently discarded. A successful attempt of forwarding the request 2401 message to the NR will be acknowledged by the NR with a successful 2402 response message, which is subject to the regular behavior described 2403 in the proxy-mode sections. 2405 3.7.6.4. Deployment Considerations for Edge-Devices 2407 The proxy mode assumes that the edge-NAT or edge-firewall are 2408 properly configured by network operator, i.e., the edge-device is 2409 really the final NAT or firewall of that particular network. There 2410 is currently no known way of letting the NATFW NSLP automatically 2411 detect which of the NAT or firewalls are the actual edge of a 2412 network. Therefore, it is important for the network operator to 2413 configure the edge-NAT or edge-firewall and also to re-configure 2414 these devices if they are not at the edge anymore. For instance, an 2415 edge-NAT is located within an ISP and the ISP chooses to place 2416 another NAT in front of this edge-NAT. In this case, the ISP needs 2417 to reconfigure the old edge-NAT to be a regular NATFW NLSP NAT and to 2418 configure the newly installed NAT to be the edge-NAT. 2420 3.8. De-Multiplexing at NATs 2422 Section 3.7.2 describes how NSIS nodes behind NATs can obtain a 2423 public reachable IP address and port number at a NAT and and how the 2424 resulting mapping rule can be activated by using CREATE messages (see 2425 Section 3.7.1). The information about the public IP address/port 2426 number can be transmitted via an application level signaling protocol 2427 and/or third party to the communication partner that would like to 2428 send data toward the host behind the NAT. However, NSIS signaling 2429 flows are sent towards the address of the NAT at which this 2430 particular IP address and port number is allocated and not directly 2431 to the allocated IP address and port number. The NATFW NSLP 2432 forwarder at this NAT needs to know how the incoming NSLP CREATE 2433 messages are related to reserved addresses, meaning how to de- 2434 multiplex incoming NSIS CREATE messages. 2436 The de-multiplexing method uses information stored at the local NATFW 2437 NSLP node and in the policy rule. The policy rule uses the LE-MRM 2438 MRI source-address (see [I-D.ietf-nsis-ntlp]) as the flow destination 2439 IP address and the network-layer-version (IP-ver) as IP version. The 2440 external IP address at the NAT is stored as the external flow 2441 destination IP address. All other parameters of the policy rule 2442 other than the flow destination IP address are wildcarded if no 2443 NATFW_DTINFO object is included in the EXTERNAL message. The LE-MRM 2444 MRI destination-address MUST NOT be used in the policy rule, since it 2445 is solely a signaling destination address. 2447 If the NATFW_DTINFO object is included in the EXTERNAL message, the 2448 policy rule is filled with further information. The 'dst port 2449 number' field of the NATFW_DTINFO is stored as the flow destination 2450 port number. The 'protocol' field is stored as the flow protocol. 2451 The 'src port number' field is stored as the flow source port number. 2452 The 'data sender's IPv4 address' is stored as the flow source IP 2453 address. Note that some of these field can contain wildcards. 2455 When receiving a CREATE message at the NATFW NSLP it uses the flow 2456 information stored in the MRI to do the matching process. This table 2457 shows the parameters to be compared against each others. Note that 2458 not all parameters can be present in a MRI at the same time. 2460 +-------------------------------+--------------------------------+ 2461 | Flow parameter (Policy Rule) | MRI parameter (CREATE message) | 2462 +-------------------------------+--------------------------------+ 2463 | IP version | network-layer-version | 2464 | | | 2465 | Protocol | IP-protocol | 2466 | | | 2467 | source IP address (w) | source-address (w) | 2468 | | | 2469 | external IP address | destination-address | 2470 | | | 2471 | destination IP address (n/u) | N/A | 2472 | | | 2473 | source port number (w) | L4-source-port (w) | 2474 | | | 2475 | external port number (w) | L4-destination-port (w) | 2476 | | | 2477 | destination port number (n/u) | N/A | 2478 | | | 2479 | IPsec-SPI | ipsec-SPI | 2480 +-------------------------------+--------------------------------+ 2482 Table entries marked with (w) can be wildcarded and entries marked 2483 with (n/u) are not used for the matching. 2485 Table 1 2487 It should be noted that the Protocol/IP-protocol entries in Table 1 2488 refers to 'Protocol' field in the IPv4 header or the 'next header' 2489 entry in the IPv6 header. 2491 3.9. Reacting to Route Changes 2493 The NATFW NSLP needs to react to route changes in the data path. 2494 This assumes the capability to detect route changes, to perform NAT 2495 and firewall configuration on the new path and possibly to tear down 2496 NATFW NSLP signaling session state on the old path. The detection of 2497 route changes is described in Section 7 of [I-D.ietf-nsis-ntlp] and 2498 the NATFW NSLP relies on notifications about route changes by the 2499 NTLP. This notification will be conveyed by the API between NTLP and 2500 NSLP, which is out of scope of this memo. 2502 A NATFW NSLP node other than the NI or NI+ detecting a route change, 2503 by means described in the NTLP specification or others, generates a 2504 NOTIFY message indicating this change and sends this inbound towards 2505 NI and outbound towards the NR (see also Section 3.7.5.). 2506 Intermediate NFs on the way to the NI can use this information to 2507 decide later if their NATFW NSLP signaling session can be deleted 2508 locally, if they do not receive an update within a certain time 2509 period, as described in Section 3.2.8. It is important to consider 2510 the transport limitations of NOTIFY messages as mandated in 2511 Section 3.7.5. 2513 The NI receiving this NOTIFY message MAY generate a new CREATE or 2514 EXTERNAL message and send it towards the NATFW NSLP signaling 2515 session's NI as for the initial message using the same session ID. 2516 All the remaining processing and message forwarding, such as NSLP 2517 next hop discovery, is subject to regular NSLP processing as 2518 described in the particular sections. Normal routing will guide the 2519 new CREATE or EXTERNAL message to the correct NFs along the changed 2520 route. NFs that were on the original path receiving these new CREATE 2521 or EXTERNAL messages (see also Section 3.10), can use the session ID 2522 to update the existing NATFW NSLP signaling session, whereas NFs that 2523 were not on the original path will create new state for this NATFW 2524 NSLP signaling session. The next section describes how policy rules 2525 are updated. 2527 3.10. Updating Policy Rules 2529 NSIS initiators can request an update of the installed/reserved 2530 policy rules at any time within a NATFW NSLP signaling session. 2531 Updates to policy rules can be required due to node mobility (NI is 2532 moving from one IP address to another), route changes (this can 2533 result in a different NAT mapping at a different NAT device), or the 2534 wish of the NI to simply change the rule. NIs can update policy 2535 rules in existing NATFW NSLP signaling sessions by sending an 2536 appropriate CREATE or EXTERNAL message (similar to Section 3.4) with 2537 modified message routing information (MRI) as compared with that 2538 installed previously, but using the existing session ID to identify 2539 the intended target of the update. With respect to authorization and 2540 authentication, this update CREATE or EXTERNAL message is treated in 2541 exactly the same way as any initial message. Therefore, any node 2542 along in the NATFW NSLP signaling session can reject the update with 2543 an error RESPONSE message, as defined in the previous sections. 2545 The message processing and forwarding is executed as defined in the 2546 particular sections. A NF or the NR receiving an update, simply 2547 replaces the installed policy rules installed in the firewall/NAT. 2548 The local procedures on how to update the MRI in the firewall/NAT is 2549 out of scope of this memo. 2551 4. NATFW NSLP Message Components 2553 A NATFW NSLP message consists of a NSLP header and one or more 2554 objects following the header. The NSLP header is carried in all 2555 NATFW NSLP messages and objects are Type-Length-Value (TLV) encoded 2556 using big endian (network ordered) binary data representations. 2557 Header and objects are aligned to 32 bit boundaries and object 2558 lengths that are not multiples of 32 bits must be padded to the next 2559 higher 32 bit multiple. 2561 The whole NSLP message is carried as payload of a NTLP message. 2563 Note that the notation 0x is used to indicate hexadecimal numbers. 2565 4.1. NSLP Header 2567 All GIST NSLP-Data objects for the NATFW NSLP MUST contain this 2568 common header as the first 32 bits of the object (this is not the 2569 same as the GIST Common Header). It contains two fields, the NSLP 2570 message type and the P Flag, plus two reserved fields. The total 2571 length is 32 bits. The layout of the NSLP header is defined by 2572 Figure 20. 2574 0 1 2 3 2575 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 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 | Message type |P|E| reserved | reserved | 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 Figure 20: Common NSLP header 2582 The reserved field MUST be set to zero in the NATFW NSLP header 2583 before sending and MUST be ignored during processing of the header. 2585 The defined messages types are: 2587 o 0x1 : CREATE 2589 o 0x2 : EXTERNAL 2591 o 0x3: RESPONSE 2593 o 0x4: NOTIFY 2595 If a message with another type is received, an error RESPONSE of 2596 class 'Protocol error' (0x3) with response code 'Illegal message 2597 type' (0x01) MUST be generated. 2599 The P flag indicates the usage of proxy mode. If proxy mode is used 2600 it MUST be set to 1. Proxy mode usage MUST only be used in 2601 combination with the message types CREATE and EXTERNAL. The P flag 2602 MUST be ignored when processing messages with type RESPONSE or 2603 NOTIFY. 2605 The E flag indicates in proxy mode whether the edge-NAT or edge- 2606 firewall MUST continue sending the message to the NR, i.e. end-to- 2607 end. The E flag MUST only be set to 1 if the P flag is set, 2608 otherwise it MUST be ignored. The E flag MUST only be used in 2609 combination with the message types CREATE and EXTERNAL. The E flag 2610 MUST be ignored when processing messages with type RESPONSE or 2611 NOTIFY. 2613 4.2. NSLP Objects 2615 NATFW NSLP objects use a common header format defined by Figure 21. 2616 The object header contains these fields: two flags, two reserved 2617 bits, the NSLP object type, a reserved field of 4 bits, and the 2618 object length. Its total length is 32 bits. 2620 0 1 2 3 2621 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 2622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 Figure 21: Common NSLP object header 2628 The object length field contains the total length of the object 2629 without the object header. The unit is a word, consisting of 4 2630 octets. The particular values of type and length for each NSLP 2631 object are listed in the subsequent sections that define the NSLP 2632 objects. An error RESPONSE of class 'Protocol error' (0x3) with 2633 response code 'Wrong object length' (0x07) MUST be generated if the 2634 length given for the object in the object header did not match the 2635 length of the object data present. The two leading bits of the NSLP 2636 object header are used to signal the desired treatment for objects 2637 whose treatment has not been defined in this memo (see 2638 [I-D.ietf-nsis-ntlp], Section A.2.1), i.e., the Object Type has not 2639 been defined. NATFW NSLP uses a subset of the categories defined in 2640 GIST: 2642 o AB=00 ("Mandatory"): If the object is not understood, the entire 2643 message containing it MUST be rejected with an error RESPONSE of 2644 class 'Protocol error' (0x3) with response code 'Unknown object 2645 present' (0x06). 2647 o AB=01 ("Optional"): If the object is not understood, it should be 2648 deleted and then the rest of the message processed as usual. 2650 o AB=10 ("Forward"): If the object is not understood, it should be 2651 retained unchanged in any message forwarded as a result of message 2652 processing, but not stored locally. 2654 The combination AB=11 MUST NOT be used and an error RESPONSE of class 2655 'Protocol error' (0x3) with response code 'Invalid Flag-Field 2656 combination' (0x09) MUST be generated. 2658 The following sections do not repeat the common NSLP object header, 2659 they just list the type and the length. 2661 4.2.1. Signaling Session Lifetime Object 2663 The signaling session lifetime object carries the requested or 2664 granted lifetime of a NATFW NSLP signaling session measured in 2665 seconds. 2667 Type: NATFW_LT (IANA-TBD) 2669 Length: 1 2671 0 1 2 3 2672 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 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | NATFW NSLP signaling session lifetime | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 Figure 22: Signaling Session Lifetime object 2679 4.2.2. External Address Object 2681 The external address object can be included in RESPONSE messages 2682 (Section 4.3.3) only. It carries the publicly reachable IP address, 2683 and if applicable port number, at an edge-NAT. 2685 Type: NATFW_EXTERNAL-IP (IANA-TBD) 2687 Length: 2 2688 0 1 2 3 2689 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | port number |IP-Ver | reserved | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | IPv4 address | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 Figure 23: External Address Object for IPv4 addresses 2698 Please note that the field 'port number' MUST be set to 0 if only an 2699 IP address has been reserved, for instance, by a traditional NAT. A 2700 port number of 0 MUST be ignored in processing this object. 2702 IP-Ver (4 bits): The IP version number. This field MUST be set to 4. 2704 4.2.3. External Binding Address Object 2706 The external binding address object can be included in RESPONSE 2707 messages (Section 4.3.3) and EXTERNAL (Section 3.7.2) messages. It 2708 carries one or multiple external binding addresses, and if applicable 2709 port number, for multi-level NATs deployments (for an example see 2710 Section 2.5). The utilization of the information carried in this 2711 object is described in Appendix B. 2713 Type: NATFW_EXTERNAL_BINDING (IANA-TBD) 2715 Length: 1 + number of IPv4 addresses 2717 0 1 2 3 2718 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 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 | port number |IP-Ver | reserved | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | IPv4 address #1 | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 // . . . // 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | IPv4 address #n | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 Figure 24: External Binding Address Object 2731 Please note that the field 'port number' MUST be set to 0 if only an 2732 IP address has been reserved, for instance, by a traditional NAT. A 2733 port number of 0 MUST be ignored in processing this object. 2735 IP-Ver (4 bits): The IP version number. This field MUST be set to 4. 2737 4.2.4. Extended Flow Information Object 2739 In general, flow information is kept in the message routing 2740 information (MRI) of the NTLP. Nevertheless, some additional 2741 information may be required for NSLP operations. The 'extended flow 2742 information' object carries this additional information about the 2743 action of the policy rule for firewalls/NATs and contiguous port . 2745 Type: NATFW_EFI (IANA-TBD) 2747 Length: 1 2749 0 1 2 3 2750 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 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 | rule action | sub_ports | 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2755 Figure 25: Extended Flow Information 2757 This object has two fields, 'rule action' and 'sub_ports'. The 'rule 2758 action' field has these meanings: 2760 o 0x0001: Allow: A policy rule with this action allows data traffic 2761 to traverse the middlebox and the NATFW NSLP MUST allow NSLP 2762 signaling to be forwarded. 2764 o 0x0002: Deny: A policy rule with this action blocks data traffic 2765 from traversing the middlebox and the NATFW NSLP MUST NOT allow 2766 NSLP signaling to be forwarded. 2768 If the 'rule action' field contains neither 0x0001 nor 0x0002, an 2769 error RESPONSE of class 'Signaling session failure' (0x6) with 2770 response code 'Unknown policy rule action' (0x05) MUST be generated. 2772 The 'sub_ports' field contains the number of contiguous transport 2773 layer ports to which this rule applies. The default value of this 2774 field is 0, i.e., only the port specified in the NTLP's MRM or 2775 NATFW_DTINFO object is used for the policy rule. A value of 1 2776 indicates that additionally to the port specified in the NTLP's MRM 2777 (port1), a second port (port2) is used. This value of port 2 is 2778 calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT 2779 be used in this field and an error RESPONSE of class 'Signaling 2780 session failure' (0x6) with response code 'Requested value in 2781 sub_ports field in NATFW_EFI not permitted' (0x08) MUST be generated. 2783 This two contiguous port numbered ports, can be used by legacy voice 2784 over IP equipment. This legacy equipment assumes two adjacent port 2785 numbers for its RTP/RTCP flows respectively. 2787 4.2.5. Information Code Object 2789 This object carries the response code, which may be indications for 2790 either a successful or failed CREATE or EXTERNAL message depending on 2791 the value of the 'response code' field. 2793 Type: NATFW_INFO (IANA-TBD) 2795 Length: 1 2797 0 1 2 3 2798 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 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 | Resv. | Class | Response Code |r|r|r|r| Object Type | 2801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2803 Figure 26: Information Code Object 2805 The field 'resv.' is reserved for future extensions and MUST be set 2806 to zero when generating such an object and MUST be ignored when 2807 receiving. The 'Object Type' field contains the type of the object 2808 causing the error. The value of 'Object Type' is set to 0, if no 2809 object is concerned. The leading fours bits marked with 'r' are 2810 always set to zero and ignored. The 4 bit class field contains the 2811 severity class. The following classes are defined: 2813 o 0x0: Reserved 2815 o 0x1: Informational (NOTIFY only) 2817 o 0x2: Success 2819 o 0x3: Protocol error 2821 o 0x4: Transient failure 2823 o 0x5: Permanent failure 2825 o 0x6: Signaling session failure 2827 Within each severity class a number of responses values are defined 2828 o Informational: 2830 * 0x01: Route change: possible route change on the outbound path. 2832 * 0x02: Re-authentication required. 2834 * 0x03: NATFW node is going down soon. 2836 * 0x04: NATFW signaling session lifetime expired. 2838 * 0x05: NATFW signaling session terminated. 2840 o Success: 2842 * 0x01: All successfully processed. 2844 o Protocol error: 2846 * 0x01: Illegal message type: the type given in the Message Type 2847 field of the NSLP header is unknown. 2849 * 0x02: Wrong message length: the length given for the message in 2850 the NSLP header does not match the length of the message data. 2852 * 0x03: Bad flags value: an undefined flag or combination of 2853 flags was set in the NSLP header. 2855 * 0x04: Mandatory object missing: an object required in a message 2856 of this type was missing. 2858 * 0x05: Illegal object present: an object was present which must 2859 not be used in a message of this type. 2861 * 0x06: Unknown object present: an object of an unknown type was 2862 present in the message. 2864 * 0x07: Wrong object length: the length given for the object in 2865 the object header did not match the length of the object data 2866 present. 2868 * 0x08: Unknown object field value: a field in an object had an 2869 unknown value. 2871 * 0x09: Invalid Flag-Field combination: An object contains an 2872 invalid combination of flags and/or fields. 2874 * 0x0A: Duplicate object present. 2876 * 0x0B: Received EXTERNAL request message on external side. 2878 o Transient failure: 2880 * 0x01: Requested resources temporarily not available. 2882 o Permanent failure: 2884 * 0x01: Authentication failed. 2886 * 0x02: Authorization failed. 2888 * 0x04: Internal or system error. 2890 * 0x06: No edge-device here. 2892 * 0x07: Did not reach the NR. 2894 o Signaling session failure: 2896 * 0x01: Session terminated asynchronously. 2898 * 0x02: Requested lifetime is too big. 2900 * 0x03: No reservation found matching the MRI of the CREATE 2901 request. 2903 * 0x04: Requested policy rule denied due to policy conflict. 2905 * 0x05: Unknown policy rule action. 2907 * 0x06: Requested rule action not applicable. 2909 * 0x07: NATFW_DTINFO object is required. 2911 * 0x08: Requested value in sub_ports field in NATFW_EFI not 2912 permitted. 2914 * 0x09: Requested IP protocol not supported. 2916 * 0x0A: Plain IP policy rules not permitted -- need transport 2917 layer information. 2919 * 0x0B: ICMP type value not permitted. 2921 * 0x0C: source IP address range is too large. 2923 * 0x0D: destination IP address range is too large. 2925 * 0x0E: source L4-port range is too large. 2927 * 0x0F: destination L4-port range is too large. 2929 * 0x10: Requested lifetime is too small. 2931 * 0x11: Modified lifetime is too big. 2933 * 0x12: Modified lifetime is too small. 2935 4.2.6. Nonce Object 2937 This object carries the nonce value as described in Section 3.7.6. 2939 Type: NATFW_NONCE (IANA-TBD) 2941 Length: 1 2943 0 1 2 3 2944 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 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 | nonce | 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 Figure 27: Nonce Object 2951 4.2.7. Message Sequence Number Object 2953 This object carries the MSN value as described in Section 3.5. 2955 Type: NATFW_MSN (IANA-TBD) 2957 Length: 1 2959 0 1 2 3 2960 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 2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 | message sequence number | 2963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 Figure 28: Message Sequence Number Object 2967 4.2.8. Data Terminal Information Object 2969 The 'data terminal information' object carries additional information 2970 MUST be included the EXTERNAL message. EXTERNAL messages are 2971 transported by the NTLP using the Loose-End message routing method 2972 (LE-MRM). The LE-MRM contains only DR's IP address and a signaling 2973 destination address (destination address). This destination address 2974 is used for message routing only and is not necessarily reflecting 2975 the address of the data sender. This object contains information 2976 about (if applicable) DR's port number (the destination port number), 2977 DS' port number (the source port number), the used transport 2978 protocol, the prefix length of the IP address, and DS' IP address. 2980 Type: NATFW_DTINFO (IANA-TBD) 2982 Length: variable. Maximum 3. 2984 0 1 2 3 2985 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 2986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2987 |I|P|S| reserved | sender prefix | protocol | 2988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2989 : DR port number | DS port number : 2990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2991 : IPsec-SPI : 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2993 | data sender's IPv4 address | 2994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2996 Figure 29: Data Terminal IPv4 Address Object 2998 The flags are: 3000 o I: I=1 means that 'protocol' should be interpreted. 3002 o P: P=1 means that 'dst port number' and 'src port number' are 3003 present and should be interpreted. 3005 o S: S=1 means that SPI is present and should be interpreted. 3007 The SPI field is only present if S is set. The port numbers are only 3008 present if P is set. The flags P and S MUST NOT be set at the same 3009 time. An error RESPONSE of class 'Protocol error' (0x3) with 3010 response code 'Invalid Flag-Field combination' (0x09) MUST be 3011 generated if they are both set. If either P or S is set, I MUST be 3012 set as well and the protocol field MUST carry the particular 3013 protocol. An error RESPONSE of class 'Protocol error' (0x3) with 3014 response code 'Invalid Flag-Field combination' (0x09) MUST be 3015 generated if S or P is set but I is not set. 3017 The fields MUST be interpreted according to these rules: 3019 o (data) sender prefix: This parameter indicates the prefix length 3020 of the 'data sender's IP address' in bits. For instance, a full 3021 IPv4 address requires 'sender prefix' to be set to 32. A value of 3022 0 indicates an IP address wildcard. 3024 o protocol: The IP protocol field. This field MUST be interpreted 3025 if I=1, otherwise it MUST be set to 0 and MUST be ignored. 3027 o DR port number: The port number at the data receiver (DR), i.e., 3028 the destination port. A value of 0 indicates a port wildcard, 3029 i.e., the destination port number is not known. Any other value 3030 indicates the destination port number. 3032 o DS port number: The port number at the data sender (DS), i.e., the 3033 source port. A value of 0 indicates a port wildcard, i.e., the 3034 source port number is not known. Any other value indicates the 3035 source port number. 3037 o data sender's IPv4 address: The source IP address of the data 3038 sender. This field MUST be set to zero if no IP address is 3039 provided, i.e., a complete wildcard is desired (see dest prefix 3040 field above). 3042 4.2.9. ICMP Types Object 3044 The 'ICMP types' object contains additional information needed to 3045 configure a NAT of firewall with rules to control ICMP traffic. The 3046 object contains a number of values of the ICMP Type field for which a 3047 filter action should be set up: 3049 Type: NATFW_ICMP_TYPES (IANA-TBD) 3051 Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 3053 Where DIV is an integer division. 3055 0 1 2 3 3056 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 3057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3058 | Count | Type | Type | ........ | 3059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3060 | ................ | 3061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 | ........ | Type | (Padding) | 3063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 Figure 30: ICMP Types Object 3067 The fields MUST be interpreted according to these rules: 3069 count: 8 bit integer specifying the number of 'Type' entries in 3070 the object. 3072 type: 8 bit field specifying an ICMP Type value to which this rule 3073 applies. 3075 padding: Sufficient 0 bits to pad out the last word so that the 3076 total size of object is an even multiple of words. Ignored on 3077 reception. 3079 4.3. Message Formats 3081 This section defines the content of each NATFW NSLP message type. 3082 The message types are defined in Section 4.1. 3084 Basically, each message is constructed of NSLP header and one or more 3085 NSLP objects. The order of objects is not defined, meaning that 3086 objects may occur in any sequence. Objects are marked either with 3087 mandatory (M) or optional (O). Where (M) implies that this 3088 particular object MUST be included within the message and where (O) 3089 implies that this particular object is OPTIONAL within the message. 3090 Objects defined in this memo always carry the flag combination AB=00 3091 in the NSLP object header. An error RESPONSE message of class 3092 'Protocol error' (0x3) with response code 'Mandatory object missing' 3093 (0x04) MUST be generated if a mandatory declared object is missing. 3094 An error RESPONSE message of class 'Protocol error' (0x3) with 3095 response code 'Illegal object present' (0x05) MUST be generated if an 3096 object was present which must not be used in a message of this type. 3097 An error RESPONSE message of class 'Protocol error' (0x3) with 3098 response code 'Duplicate object present' (0x0A) MUST be generated if 3099 an object appears more than once in a message. 3101 Each section elaborates the required settings and parameters to be 3102 set by the NSLP for the NTLP, for instance, how the message routing 3103 information is set. 3105 4.3.1. CREATE 3107 The CREATE message is used to create NATFW NSLP signaling sessions 3108 and to create policy rules. Furthermore, CREATE messages are used to 3109 refresh NATFW NSLP signaling sessions and to delete them. 3111 The CREATE message carries these objects: 3113 o Signaling Session Lifetime object (M) 3115 o Extended flow information object (M) 3117 o Message sequence number object (M) 3119 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 3120 (O) 3122 o ICMP Types Object (O) 3124 The message routing information in the NTLP MUST be set to DS as 3125 source address and DR as destination address. All other parameters 3126 MUST be set according the required policy rule. CREATE messages MUST 3127 be transported by using the path-coupled MRM with direction set to 3128 'downstream' (outbound). 3130 4.3.2. EXTERNAL 3132 The EXTERNAL message is used to a) reserve an external IP address/ 3133 port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to 3134 block incoming data traffic at inbound firewalls. 3136 The EXTERNAL message carries these objects: 3138 o Signaling Session Lifetime object (M) 3140 o Message sequence number object (M) 3142 o Extended flow information object (M) 3144 o Data terminal information object (M) 3146 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 3147 (O) 3149 o ICMP Types Object (O) 3150 o External binding address object (O) 3152 The selected message routing method of the EXTERNAL message depends 3153 on a number of considerations. Section 3.7.2 describes it 3154 exhaustively how to select the correct method. EXTERNAL messages can 3155 be transported via the path-coupled message routing method (PC-MRM) 3156 or via the loose-end message routing method (LE-MRM). In the case of 3157 PC-MRM, the source-address is set to DS' address and the destination 3158 address is set to DR's address, the direction is set to inbound. In 3159 the case of LE-MRM, the destination-address is set to DR's address or 3160 to the signaling destination address. The source-address is set to 3161 DS's address. 3163 4.3.3. RESPONSE 3165 RESPONSE messages are responses to CREATE and EXTERNAL messages. 3166 RESPONSE messages MUST NOT be generated for any other message, such 3167 as NOTIFY and RESPONSE. 3169 The RESPONSE message for the class 'Success' (0x2) carries these 3170 objects: 3172 o Signaling Session Lifetime object (M) 3174 o Message sequence number object (M) 3176 o Information code object (M) 3178 o External address object (O) 3180 o External binding address object (O) 3182 The RESPONSE message for other classes than 'Success' (0x2) carries 3183 these objects: 3185 o Message sequence number object (M) 3187 o Information code object (M) 3189 o Signaling Session Lifetime object (O) 3191 This message is routed towards the NI hop-by-hop, using existing NTLP 3192 messaging associations. The MRM used for this message MUST be the 3193 same as MRM used by the corresponding CREATE or EXTERNAL message. 3195 4.3.4. NOTIFY 3197 The NOTIFY messages is used to report asynchronous events happening 3198 along the signaled path to other NATFW NSLP nodes. 3200 The NOTIFY message carries this object: 3202 o Information code object (M). 3204 The NOTIFY message is routed towards the next NF, NI, or NR hop-by- 3205 hop using the existing inbound or outbound node messaging association 3206 entry within the node's Message Routing State table. The MRM used 3207 for this message MUST be the same as MRM used by the corresponding 3208 CREATE or EXTERNAL message. 3210 5. Security Considerations 3212 Security is of major concern particularly in case of firewall 3213 traversal. This section provides security considerations for the 3214 NAT/firewall traversal and is organized as follows. 3216 In Section 5.1 we describe how the participating entities relate to 3217 each other from a security point of view. This subsection also 3218 motivates a particular authorization model. 3220 Security threats that focus on NSIS in general are described in 3221 [RFC4081] and they are applicable to this document as well. 3223 Finally, we illustrate how the security requirements that were 3224 created based on the security threats can be fulfilled by specific 3225 security mechanisms. These aspects will be elaborated in 3226 Section 5.2. 3228 5.1. Authorization Framework 3230 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 3231 and is, as such, not a two-party protocol. Figure 1 and Figure 2 of 3232 [RFC4081] already depict the possible set of communication patterns. 3233 In this section we will re-evaluate these communication patters with 3234 respect to the NATFW NSLP protocol interaction. 3236 The security solutions for providing authorization have a direct 3237 impact on the treatment of different NSLPs. As it can be seen from 3238 the QoS NSLP [I-D.ietf-nsis-qos-nslp] and the corresponding Diameter 3239 QoS work [I-D.ietf-dime-diameter-qos] accounting and charging seems 3240 to play an important role for QoS reservations, whereas monetary 3241 aspects might only indirectly effect authorization decisions for NAT 3242 and firewall signaling. Hence, there are differences in the semantic 3243 of authorization handling between QoS and NATFW signaling. A NATFW 3244 aware node will most likely want to authorize the entity (e.g., user 3245 or machine) requesting the establishment of pinholes or NAT bindings. 3246 The outcome of the authorization decision is either allowed or 3247 disallowed whereas a QoS authorization decision might indicate that a 3248 different set of QoS parameters is authorization (see 3249 [I-D.ietf-dime-diameter-qos] as an example). 3251 5.1.1. Peer-to-Peer Relationship 3253 Starting with the simplest scenario, it is assumed that neighboring 3254 nodes are able to authenticate each other and to establish keying 3255 material to protect the signaling message communication. The nodes 3256 will have to authorize each other, additionally to the 3257 authentication. We use the term 'Security Context' as a placeholder 3258 for referring to the entire security procedure, the necessary 3259 infrastructure that needs to be in place in order for this to work 3260 (e.g., key management) and the established security related state. 3261 The required long-term key (symmetric or asymmetric keys) used for 3262 authentication are either made available using an out-of-band 3263 mechanism between the two NSIS NATFW nodes or they are dynamically 3264 established using mechanisms not further specified in this document. 3265 Note that the deployment environment will most likely have an impact 3266 on the choice of credentials being used. The choice of these 3267 credentials used is also outside the scope of this document. 3269 +------------------------+ +-------------------------+ 3270 |Network A | | Network B| 3271 | +---------+ +---------+ | 3272 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3273 | | | box 1 | Security | box 2 | | | 3274 | | +---------+ Context +---------+ | | 3275 | | Security | | Security | | 3276 | | Context | | Context | | 3277 | | | | | | 3278 | +--+---+ | | +--+---+ | 3279 | | Host | | | | Host | | 3280 | | A | | | | B | | 3281 | +------+ | | +------+ | 3282 +------------------------+ +-------------------------+ 3284 Figure 31: Peer-to-Peer Relationship 3286 Figure 31 shows a possible relationship between participating NSIS 3287 aware nodes. Host A might be, for example, a host in an enterprise 3288 network that has keying material established (e.g., a shared secret) 3289 with the company's firewall (Middlebox 1). The network administrator 3290 of Network A (company network) has created access control lists for 3291 Host A (or whatever identifiers a particular company wants to use). 3292 Exactly the same procedure might also be used between Host B and 3293 Middlebox 2 in Network B. For the communication between Middlebox 1 3294 and Middlebox 2 a security context is also assumed in order to allow 3295 authentication, authorization and signaling message protection to be 3296 successful. 3298 5.1.2. Intra-Domain Relationship 3300 In larger corporations, for example, a middlebox is used to protect 3301 individual departments. In many cases, the entire enterprise is 3302 controlled by a single (or a small number of) security department, 3303 which gives instructions to the department administrators. In such a 3304 scenario, the previously discussed peer-to-peer relationship might be 3305 prevalent. Sometimes it might be necessary to preserve 3306 authentication and authorization information within the network. As 3307 a possible solution, a centralized approach could be used, whereby an 3308 interaction between the individual middleboxes and a central entity 3309 (for example a policy decision point - PDP) takes place. As an 3310 alternative, individual middleboxes exchange the authorization 3311 decision with another middlebox within the same trust domain. 3312 Individual middleboxes within an administrative domain may exploit 3313 their relationship instead of requesting authentication and 3314 authorization of the signaling initiator again and again. Figure 32 3315 illustrates a network structure which uses a centralized entity. 3317 +-----------------------------------------------------------+ 3318 | Network A | 3319 | +---------+ +---------+ 3320 | +----///--------+ Middle- +------///------++ Middle- +--- 3321 | | Security | box 2 | Security | box 2 | 3322 | | Context +----+----+ Context +----+----+ 3323 | +----+----+ | | | 3324 | | Middle- +--------+ +---------+ | | 3325 | | box 1 | | | | | 3326 | +----+----+ | | | | 3327 | | Security | +----+-----+ | | 3328 | | Context | | Policy | | | 3329 | +--+---+ +-----------+ Decision +----------+ | 3330 | | Host | | Point | | 3331 | | A | +----------+ | 3332 | +------+ | 3333 +-----------------------------------------------------------+ 3335 Figure 32: Intra-domain Relationship 3337 The interaction between individual middleboxes and a policy decision 3338 point (or AAA server) is outside the scope of this document. 3340 5.1.3. End-to-Middle Relationship 3342 The peer-to-peer relationship between neighboring NSIS NATFW NSLP 3343 nodes might not always be sufficient. Network B might require 3344 additional authorization of the signaling message initiator (in 3345 addition to the authorization of the neighboring node). If 3346 authentication and authorization information is not attached to the 3347 initial signaling message then the signaling message arriving at 3348 Middlebox 2 would result in an error message being created, which 3349 indicates the additional authorization requirement. In many cases 3350 the signaling message initiator might already be aware of the 3351 additionally required authorization before the signaling message 3352 exchange is executed. 3354 Figure 33 shows this scenario. 3356 +--------------------+ +---------------------+ 3357 | Network A | |Network B | 3358 | | Security | | 3359 | +---------+ Context +---------+ | 3360 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3361 | | | box 1 | +-------+ box 2 | | | 3362 | | +---------+ | +---------+ | | 3363 | |Security | | | Security | | 3364 | |Context | | | Context | 3365 | | | | | | | 3366 | +--+---+ | | | +--+---+ | 3367 | | Host +----///----+------+ | | Host | | 3368 | | A | | Security | | B | | 3369 | +------+ | Context | +------+ | 3370 +--------------------+ +---------------------+ 3372 Figure 33: End-to-Middle Relationship 3374 5.2. Security Framework for the NAT/Firewall NSLP 3376 The following list of security requirements has been created to 3377 ensure proper secure operation of the NATFW NSLP. 3379 5.2.1. Security Protection between neighboring NATFW NSLP Nodes 3381 Based on the analyzed threats it is RECOMMENDED to provide, between 3382 neighboring NATFW NSLP nodes, the following mechanism: 3384 o data origin authentication 3386 o replay protection 3388 o integrity protection and 3390 o optionally confidentiality protection 3392 It is RECOMMENDED to use the authentication and key exchange security 3393 mechanisms provided in [I-D.ietf-nsis-ntlp] between neighboring nodes 3394 when sending NATFW signaling messages. The proposed security 3395 mechanisms of GIST provide support for authentication and key 3396 exchange in addition to denial of service protection. Depending on 3397 the chosen security protocol, support for multiple authentication 3398 protocols might be provided. If security between neighboring nodes 3399 is desired than the usage of C-MODE for the delivery of data packets 3400 and the usage of D-MODE only to discover the next NATFW NSLP aware 3401 node along the path is highly RECOMMENDED. Almost all security 3402 threats at the NATFW NSLP layer can be prevented by using a mutually 3403 authenticated Transport Layer secured connection and by relying on 3404 authorization by the neighboring NATFW NSLP entities. 3406 The NATFW NSLP relies on an established security association between 3407 neighboring peers to prevent unauthorized nodes to modify or delete 3408 installed state. Between non-neighboring nodes the session ID (SID) 3409 carried in the NTLP is used to show ownership of a NATFW NSLP 3410 signaling session. The session ID MUST be generated in a random way 3411 and thereby prevent an off-path adversary to mount targeted attacks. 3412 Hence, an adversary would have to learn the randomly generated 3413 session ID to perform an attack. In a mobility environment a former 3414 on-path node that is now off-path can perform an attack. Messages 3415 for a particular NATFW NSLP signaling session are handled by the NTLP 3416 to the NATFW NSLP for further processing. Messages carrying a 3417 different session ID not associated with any NATFW NSLP are subject 3418 to the regular processing for new NATFW NSLP signaling sessions. 3420 5.2.2. Security Protection between non-neighboring NATFW NSLP Nodes 3422 Based on the security threats and the listed requirements it was 3423 noted that some threats also demand authentication and authorization 3424 of a NATFW signaling entity (including the initiator) towards a non- 3425 neighboring node. This mechanism mainly demands entity 3426 authentication. The most important information exchanged at the 3427 NATFW NSLP is information related to the establishment for firewall 3428 pinholes and NAT bindings. This information can, however, not be 3429 protected over multiple NSIS NATFW NSLP hops since this information 3430 might change depending on the capability of each individual NATFW 3431 NSLP node. 3433 Some scenarios might also benefit from the usage of authorization 3434 tokens. Their purpose is to associate two different signaling 3435 protocols (e.g., SIP and NSIS) and their authorization decision. 3436 These tokens are obtained by non-NSIS protocols, such as SIP or as 3437 part of network access authentication. When a NAT or firewall along 3438 the path receives the token it might be verified locally or passed to 3439 the AAA infrastructure. Examples of authorization tokens can be 3440 found in RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. Figure 34 shows 3441 an example of this protocol interaction. 3443 An authorization token is provided by the SIP proxy, which acts as 3444 the assertion generating entity and gets delivered to the end host 3445 with proper authentication and authorization. When the NATFW 3446 signaling message is transmitted towards the network, the 3447 authorization token is attached to the signaling messages to refer to 3448 the previous authorization decision. The assertion verifying entity 3449 needs to process the token or it might be necessary to interact with 3450 the assertion granting entity using HTTP (or other protocols). As a 3451 result of a successfully authorization by a NATFW NSLP node, the 3452 requested action is executed and later a RESPONSE message is 3453 generated. 3455 +----------------+ Trust Relationship +----------------+ 3456 | +------------+ |<.......................>| +------------+ | 3457 | | Protocol | | | | Assertion | | 3458 | | requesting | | HTTP, SIP Request | | Granting | | 3459 | | authz | |------------------------>| | Entity | | 3460 | | assertions | |<------------------------| +------------+ | 3461 | +------------+ | Artifact/Assertion | Entity Cecil | 3462 | ^ | +----------------+ 3463 | | | ^ ^| 3464 | | | . || HTTP, 3465 | | | Trust . || other 3466 | API Access | Relationship. || protocols 3467 | | | . || 3468 | | | . || 3469 | | | v |v 3470 | v | +----------------+ 3471 | +------------+ | | +------------+ | 3472 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3473 | | using authz| | Assertion/Artifact | | Verifying | | 3474 | | assertion | | ----------------------- | | Entity | | 3475 | +------------+ | | +------------+ | 3476 | Entity Alice | <---------------------- | Entity Bob | 3477 +----------------+ RESPONSE +----------------+ 3479 Figure 34: Authorization Token Usage 3481 Threats against the usage of authorization tokens have been mentioned 3482 in [RFC4081]. Hence, it is required to provide confidentiality 3483 protection to avoid allowing an eavesdropper to learn the token and 3484 to use it in another NATFW NSLP signaling session (replay attack). 3485 The token itself also needs to be protected against tempering. 3487 5.3. Implementation of NATFW NSLP Security 3489 The prior sections describe how to secure the NATFW NSLP in the 3490 presence of established trust between the various players and the 3491 particular relationships (e.g., intra-domain, end-to-middle, or peer- 3492 to-peer. However, in typical Internet deployments there is no 3493 established trust, other than granting access to a network, but not 3494 between various sites in the Internet. Furthermore, the NATFW NSLP 3495 may be incrementally deployed with a heavily varying ability of using 3496 authentication and authorization services. 3498 The NATFW NSLP offers a way to keep the authentication and 3499 authorization at the "edge" of the network. The local edge network 3500 can deploy and use any type of Authentication and Authorization (AA) 3501 scheme without the need to have AA technology match with other edges 3502 in the Internet (assuming that firewalls and NATs are deployed at the 3503 edges of the network and not somewhere in the cores). 3505 Each network edge that has the NATFW NSLP deployed can use the 3506 EXTERNAL request message to allow a secure access to the network. 3507 Using the EXTERNAL request message does allow the DR to open the 3508 firewall/NAT on the receiver's side. However, the edge-devices 3509 should not allow to be opened up completely (i.e., applying an allow- 3510 all policy), but to let DR's to reserve very specific policies. For 3511 instance, a DR can request to reserve an 'allow' policy rule for an 3512 incoming TCP connection for a Jabber file transfer. This reserved 3513 policy (see Figure 15) rule must be activated by matching the CREATE 3514 request message (see Figure 15). This mechanism allows that the 3515 authentication and authorization issues are kept locally at the 3516 particular edge-network. On the reverse, the CREATE request message 3517 can be handled independently on the the DS side with respect to 3518 authentication and authorization. 3520 The usage described in the above paragraph is even simplified for an 3521 incremental deployment: There is no requirement to activate a 3522 reserved policy rule with a CREATE request message. This is 3523 completely handled by the EXTERNAL-PROXY request message and the 3524 associated CREATE request message. Both of them are handled by the 3525 local authentication and authorization scheme. 3527 6. IAB Considerations on UNSAF 3529 UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a 3530 process at originating endpoints that attempt to determine or fix the 3531 address (and port) by which they are known to another endpoint. 3532 UNSAF proposals, such as STUN [RFC5389] are considered as a general 3533 class of workarounds for NAT traversal and as solutions for scenarios 3534 with no middlebox communication. 3536 This memo specifies a path-coupled middlebox communication protocol, 3537 i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are 3538 not intended as a short-term workaround, but more as a long-term 3539 solution for middlebox communication. In NSIS, endpoints are 3540 involved in allocating, maintaining, and deleting addresses and ports 3541 at the middlebox. However, the full control of addresses and ports 3542 at the middlebox is at the NATFW NSLP daemon located at the 3543 respective NAT. 3545 Therefore, this document addresses the UNSAF considerations in 3546 [RFC3424] by proposing a long-term alternative solution. 3548 7. IANA Considerations 3550 This section provides guidance to the Internet Assigned Numbers 3551 Authority (IANA) regarding registration of values related to the 3552 NATFW NSLP, in accordance with BCP 26 RFC 5226 [RFC5226]. 3554 The NATFW NSLP requires IANA to create a number of new registries: 3556 o NATFW NSLP Message Type Registry 3558 o NATFW NSLP Header Flag Registry 3560 o NSLP Response Code Registry 3562 It also requires registration of new values in a number of 3563 registries: 3565 o NSLP Object Types 3567 o GIST NSLP-ID 3569 o Router Alert Option Values (IPv4 and IPv6) 3571 7.1. NATFW NSLP Message Type Registry 3573 The NATFW NSLP Message Type is a 8 bit value. The allocation of 3574 values for new message types requires IETF Review. Updates and 3575 deletion of values from the registry is not possible. This 3576 specification defines four NATFW NSLP message types, which form the 3577 initial contents of this registry. IANA is requested to add these 3578 four NATFW NSLP Message Types: CREATE (0x1), EXTERNAL (0x2), RESPONSE 3579 (0x3), and NOTIFY (0x4). The registry entries consist of Name of 3580 Message Type, value, and reference to the relevant section. 3582 7.2. NATFW NSLP Header Flag Registry 3584 NATFW NSLP messages have a messages-specific 8 bit flags/reserved 3585 field in their header. The registration of flags is subject to IANA 3586 registration. The allocation of values for flag types requires IETF 3587 Review. Updates and deletion of values from the registry is not 3588 possible. This specification defines only two flags in Section 4.1, 3589 the E flag and the P flag. The registry entries consist of Name of 3590 the Flag and reference to the relevant section. 3592 7.3. NSLP Object Type Registry 3594 [ Delete the part in square brackets if registry is already created 3595 by another NSLP: 3597 A new registry is to be created for NSLP Message Objects. This is a 3598 12-bit field (giving values from 0 to 4095). This registry is shared 3599 between a number of NSLPs. Allocation policies are as follows: 3601 0-1023: IETF Review 3603 1024-1999: Specification Required 3605 2000-2047: Private/Experimental Use 3607 2048-4095: Reserved 3609 When a new object is defined, the extensibility bits (A/B) must also 3610 be defined. ] 3612 This document defines 9 objects for the NATFW NSLP: NATFW_LT, 3613 NATFW_EXTERNAL-IP, NATFW_EXTERNAL_BINDING, NATFW_EFI, NATFW_INFO, 3614 NATFW_NONCE, NATFW_MSN, NATFW_DTINFO, NATFW_ICMP_TYPES. IANA is 3615 request to assigned values for them from NSLP Object Type registry 3616 and to replace the corresponding IANA-TBD tags in this memo with the 3617 numeric values. 3619 7.4. NSLP Response Code Registry 3621 In addition it defines a number of Response Codes for the NATFW NSLP. 3622 These can be found in Section 4.2.5 and are to be assigned values 3623 from NSLP Response Code registry. The allocation of new values for 3624 Response Codes Codes requires IETF Review. IANA is request to 3625 assigned values for them from NSLP Response Code registry as given in 3626 Section 4.2.5for the severity class and also for the number of 3627 responses values per each severity class. The registry entries 3628 consist out of Name of class or response code, value, and reference 3629 to the relevant section. 3631 7.5. NSLP IDs and Router Alert Option Values 3633 GIST NSLPID 3635 This specification defines an NSLP for use with GIST and thus 3636 requires an assigned NSLP identifier. IANA is requested to add one 3637 new value to the NSLP Identifiers (NSLPID) registry defined in 3638 [I-D.ietf-nsis-ntlp] for the NATFW NSLP. 3640 IPv4 and IPv6 Router Alert Option (RAO) value 3642 The GIST specification also requires that each NSLP-ID be associated 3643 with specific Router Alert Option (RAO) value. For the purposes of 3644 the NATFW NSLP, just a single IPv4 RAO value and a single IPv6 RAO 3645 must be allocated. 3647 8. Acknowledgments 3649 We would like to thank the following individuals for their 3650 contributions to this document at different stages: 3652 o Marcus Brunner and Henning Schulzrinne for their work on IETF 3653 drafts which lead us to start with this document; 3655 o Miquel Martin for his large contribution on the initial version of 3656 this document and one of the first prototype implementations; 3658 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3659 NAT/firewall threats draft; 3661 o Henning Peters for his comments and suggestions; 3663 o Ben Campbell as Gen-ART reviewer; 3665 o and the NSIS working group. 3667 9. References 3669 9.1. Normative References 3671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3672 Requirement Levels", BCP 14, RFC 2119, March 1997. 3674 [I-D.ietf-nsis-ntlp] 3675 Schulzrinne, H. and M. Stiemerling, "GIST: General 3676 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 3677 (work in progress), June 2009. 3679 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 3680 August 1996. 3682 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3683 Requirements for Security", BCP 106, RFC 4086, June 2005. 3685 9.2. Informative References 3687 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3688 Bosch, "Next Steps in Signaling (NSIS): Framework", 3689 RFC 4080, June 2005. 3691 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 3692 RFC 3726, April 2004. 3694 [I-D.ietf-nsis-qos-nslp] 3695 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 3696 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 3697 (work in progress), January 2010. 3699 [I-D.ietf-nsis-ext] 3700 Manner, J., Bless, R., Loughney, J., and E. Davies, "Using 3701 and Extending the NSIS Protocol Family", 3702 draft-ietf-nsis-ext-07 (work in progress), April 2010. 3704 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 3705 A. Rayhan, "Middlebox communication architecture and 3706 framework", RFC 3303, August 2002. 3708 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 3709 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 3711 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3712 Translator (NAT) Terminology and Considerations", 3713 RFC 2663, August 1999. 3715 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 3716 Issues", RFC 3234, February 2002. 3718 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 3719 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 3720 Functional Specification", RFC 2205, September 1997. 3722 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 3723 Self-Address Fixing (UNSAF) Across Network Address 3724 Translation", RFC 3424, November 2002. 3726 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3727 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3728 May 2008. 3730 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3731 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3732 October 2008. 3734 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 3735 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 3736 J., and S. Waldbusser, "Terminology for Policy-Based 3737 Management", RFC 3198, November 2001. 3739 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 3740 "Session Authorization Policy Element", RFC 3520, 3741 April 2003. 3743 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 3744 Session Set-up with Media Authorization", RFC 3521, 3745 April 2003. 3747 [I-D.ietf-dime-diameter-qos] 3748 Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., 3749 and G. Zorn, "Diameter Quality of Service Application", 3750 draft-ietf-dime-diameter-qos-15 (work in progress), 3751 March 2010. 3753 [rsvp-firewall] 3754 Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, 3755 "RSVP as firewall Signalling Protocol", Proceedings of the 3756 6th IEEE Symposium on Computers and Communications, 3757 Hammamet, Tunisia pp. 57 to 62, IEEE Computer Society 3758 Press, July 2001. 3760 Appendix A. Selecting Signaling Destination Addresses for EXTERNAL 3762 As with all other message types, EXTERNAL messages need a reachable 3763 IP address of the data sender on the GIST level. For the path- 3764 coupled MRM the source-address of GIST is the reachable IP address 3765 (i.e., the real IP address of the data sender, or a wildcard). While 3766 this is straight forward, it is not necessarily so for the loose-end 3767 MRM. Many applications do not provide the IP address of the 3768 communication counterpart, i.e., either the data sender or both a 3769 data sender and receiver. For the EXTERNAL messages, the case of 3770 data sender is of interest only. The rest of this section gives 3771 informational guidance about determining a good destination-address 3772 of the LE-MRM in GIST for EXTERNAL messages. 3774 This signaling destination address (SDA, the destination-address in 3775 GIST) can be the data sender, but for applications which do not 3776 provide an address upfront, the destination address has to be chosen 3777 independently, as it is unknown at the time when the NATFW NSLP 3778 signaling has to start. Choosing the 'correct' destination IP 3779 address may be difficult and it is possible that there is no 'right 3780 answer' for all applications relying on the NATFW NSLP. 3782 Whenever possible it is RECOMMENDED to chose the data sender's IP 3783 address as SDA. It is necessary to differentiate between the 3784 received IP addresses on the data sender. Some application level 3785 signaling protocols (e.g., SIP) have the ability to transfer multiple 3786 contact IP addresses of the data sender. For instance, private IP 3787 address, public IP address at NAT, and public IP address at a relay. 3788 It is RECOMMENDED to use all non-private IP addresses as SDAs. 3790 A different SDA must be chosen, if the IP address of the data sender 3791 is unknown. This can have multiple reasons: The application level 3792 signaling protocol cannot determine any data sender IP address at 3793 this point of time or the data receiver is server behind a NAT, i.e., 3794 accepting inbound packets from any host. In this case, the NATFW 3795 NSLP can be instructed to use the public IP address of an application 3796 server or any other node. Choosing the SDA in this case is out of 3797 the scope of the NATFW NSLP and depends on the application's choice. 3798 The local network can provide a network-SDA, i.e., a SDA which is 3799 only meaningful to the local network. This will ensure that GIST 3800 packets with destination-address set to this network-SDA are going to 3801 be routed to a edge-NAT or edge-firewall. 3803 Appendix B. Usage of External Binding Addresses 3805 The NATFW_EXTERNAL_BINDING object carries information, that has a 3806 different utility the information carried within the 3807 NATFW_EXTERNAL-IP object. The NATFW_EXTERNAL-IP object has the 3808 public IP address and potentially port numbers that can be used by 3809 the application at the NI to be reachable via the public Internet. 3810 However, there are cases were various NIs are located behind the same 3811 public NAT, but are subject to a multi-level NAT deployment, as shown 3812 in Figure 35. They can use their public IP address port assigned to 3813 them to communicate between each other (e.g., NI with NR1 and NR2) 3814 but they are forced to send their traffic through the edge-NAT, even 3815 though there is a short way possible. 3817 NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP) 3818 | 3819 NR1--192.168.0/24-- NAT3-- 3820 | 3821 NR2 10.1.2.3 3823 Figure 35: Multi-Level NAT Scenario 3825 Figure 35 shows an example that is explored here: 3827 1. NI -> NR1: Both NI and NR1 does EXTERNAL towards NAT2 and get an 3828 external address+port binding. Then they exchange that external 3829 binding and all traffic gets pinned to NAT2 instead of taking 3830 shortes path by NAT1 to NAT3 directly. However to do that NR1 3831 and NI both needs to be aware that they also have the address on 3832 the external side of NAT1 and NAT3 respectively. If there is ICE 3833 deployed and there is actually a STUN server in the 10/8 network 3834 configured, it is possible to get the shorter path to work. The 3835 NATFW NSLP provides all external addresses in the 3836 NATFW_EXTERNAL_BINDING towards the public network it could allow 3837 for optimizations. 3839 2. For the case NI -> NR2 is even more obvious. Pinning this to 3840 NAT2 is an important fall back, but allowing for trying for a 3841 direct path between NAT1 and NAT3 might be worth it. 3843 Please note that if there are overlapping address domains between NR 3844 and the public Internet the regular routing will not necessary allow 3845 sending the packet to the right domain. 3847 Appendix C. Applicability Statement on Data Receivers behind Firewalls 3849 Section 3.7.2 describes how data receivers behind middleboxes can 3850 instruct inbound firewalls/NATs to forward NATFW NSLP signaling 3851 towards them. Finding an inbound edge-NAT in address environment 3852 with NAT'ed addresses is quite easy. It is only required to find 3853 some edge-NAT, as the data traffic will be route-pinned to the NAT. 3854 Locating the appropriate edge-firewall with the PC-MRM, sent inbound 3855 is difficult. For cases with a single, symmetric route from the 3856 Internet to the data receiver, it is quite easy; simply follow the 3857 default route in the inbound direction. 3859 +------+ Data Flow 3860 +-------| EFW1 +----------+ <=========== 3861 | +------+ ,--+--. 3862 +--+--+ / \ 3863 NI+-----| FW1 | (Internet )----NR+/NI/DS 3864 NR +--+--+ \ / 3865 | +------+ `--+--' 3866 +-------| EFW2 +----------+ 3867 +------+ 3869 ~~~~~~~~~~~~~~~~~~~~~> 3870 Signaling Flow 3872 Figure 36: Data receiver behind multiple, parallel located firewalls 3874 When a data receiver, and thus NR, is located in a network site that 3875 is multihomed with several independently firewalled connections to 3876 the public Internet (as shown in Figure 36), the specific firewall 3877 through which the data traffic will be routed has to be ascertained. 3878 NATFW NSLP signaling messages sent from the NI+/NR during the 3879 EXTERNAL message exchange towards the NR+ must be routed by the NTLP 3880 to the edge-firewall that will be passed by the data traffic as well. 3881 The NTLP would need to be aware about the routing within the Internet 3882 to determine the path between DS and DR. Out of this, the NTLP could 3883 determine which of the edge-firewalls, either EFW1 or EFW2, must be 3884 selected to forward the NATFW NSLP signaling. Signaling to the wrong 3885 edge-firewall, as shown in Figure 36, would install the NATFW NSLP 3886 policy rules at the wrong device. This causes either a blocked data 3887 flow (when the policy rule is 'allow') or an ongoing attack (when the 3888 policy rule is 'deny'). Requiring the NTLP to know all about the 3889 routing within the Internet is definitely a tough challenge and 3890 usually not possible. In such described case, the NTLP must 3891 basically give up and return an error to the NSLP level, indicating 3892 that the next hop discovery is not possible. 3894 Appendix D. Firewall and NAT Resources 3896 This section gives some examples on how NATFW NSLP policy rules could 3897 be mapped to real firewall or NAT resources. The firewall rules and 3898 NAT bindings are described in a natural way, i.e., in a way one will 3899 find it in common implementations. 3901 D.1. Wildcarding of Policy Rules 3903 The policy rule/MRI to be installed can be wildcarded to some degree. 3904 Wildcarding applies to IP address, transport layer port numbers, and 3905 the IP payload (or next header in IPv6). Processing of wildcarding 3906 splits into the NTLP and the NATFW NSLP layer. The processing at the 3907 NTLP layer is independent of the NSLP layer processing and per layer 3908 constraints apply. For wildcarding in the NTLP see Section 5.8 of 3909 [I-D.ietf-nsis-ntlp]. 3911 Wildcarding at the NATFW NSLP level is always a node local policy 3912 decision. A signaling message carrying a wildcarded MRI (and thus 3913 policy rule) arriving at an NSLP node can be rejected if the local 3914 policy does not allow the request. For instance, a MRI with IP 3915 addresses set (not wildcarded), transport protocol TCP, and TCP port 3916 numbers completely wildcarded. Now the local policy allows only 3917 requests for TCP with all ports set and not wildcarded. The request 3918 is going to be rejected. 3920 D.2. Mapping to Firewall Rules 3922 This section describes how a NSLP policy rule signaled with a CREATE 3923 message is mapped to a firewall rule. The MRI is set as follows: 3925 o network-layer-version=IPv4 3927 o source-address=192.0.2.100, prefix-length=32 3929 o destination-address=192.0.50.5, prefix-length=32 3931 o IP-protocol=UDP 3933 o L4-source-port=34543, L4-destination-port=23198 3935 The NATFW_EFI object is set to action=allow and sub_ports=0. 3937 The resulting policy rule (firewall rule) to be installed might look 3938 like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198 3940 D.3. Mapping to NAT Bindings 3942 This section describes how a NSLP policy rule signaled with a 3943 EXTERNAL message is mapped to a NAT binding. It is assumed that the 3944 EXTERNAL message is sent by a NI+ being located behind a NAT and does 3945 contain a NATFW_DTINFO object. The MRI is set following using the 3946 signaling destination address, since the IP address of the real data 3947 sender is not known: 3949 o network-layer-version=IPv4 3951 o source-address= 192.168.5.100 3953 o destination-address=SDA 3955 o IP-protocol=UDP 3957 The NATFW_EFI object is set to action=allow and sub_ports=0. The 3958 NATFW_DTINFO object contains these parameters: 3960 o P=1 3962 o dest prefix=0 3964 o protocol=UDP 3966 o dst port number = 20230, src port number=0 3968 o src IP=0.0.0.0 3970 The edge-NAT allocates the external IP 192.0.2.79 and port 45000. 3972 The resulting policy rule (NAT binding) to be installed could look 3973 like: translate udp from any to 192.0.2.79 port=45000 to 3974 192.168.5.100 port=20230 3976 D.4. NSLP Handling of Twice-NAT 3978 The dynamic configuration of twice-NATs requires application level 3979 support, as stated in Section 2.5. The NATFW NSLP cannot be used for 3980 configuring twice-NATs if application level support is needed. 3981 Assuming application level support performing the configuration of 3982 the twice-NAT and the NATFW NSLP being installed at this devices, the 3983 NATFW NSLP must be able to traverse it. The NSLP is probably able to 3984 traverse the twice-NAT, as any other data traffic, but the flow 3985 information stored in the NTLP's MRI will be invalidated through the 3986 translation of source and destination address. The NATFW NSLP 3987 implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP 3988 signaling messages as any other NATFW NSLP node does. For the given 3989 signaling flow, the NATFW NSLP node MUST look up the corresponding IP 3990 address translation and modify the NTLP/NSLP signaling accordingly. 3991 The modification results in an updated MRI with respect to the source 3992 and destination IP addresses. 3994 Appendix E. Example for Receiver Proxy Case 3996 This section gives an example on how to use the NATFW NLSP for 3997 receiver behind a NAT, where only the receiving side is NATFW NSLP 3998 enabled. We assume FTP as application to show a working example. A 3999 FTP server is located behind a NAT, as shown in Figure 5, and uses 4000 the NATFW NSLP to allocated NAT bindings for the control and data 4001 channel of the FTP protocol. The information where to reach the 4002 server is communicated by a separated protocol, e.g., email, chat, to 4003 the DS side. 4005 Public Internet Private Address 4006 Space 4007 FTP Client FTP Server 4009 DS NAT NI+ 4010 | | | 4011 | | EXTERNAL | 4012 | |<---------------------------|(1) 4013 | | | 4014 | |RESPONSE[Success] | 4015 | |--------------------------->|(2) 4016 | |CREATE | 4017 | |--------------------------->|(3) 4018 | |RESPONSE[Success] | 4019 | |<---------------------------|(4) 4020 | | | 4021 | | | 4022 |<=======================================================|(5) 4023 |FTP control port=XYZ | FTP control port=21 | 4024 |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(6) 4025 | | | 4026 | FTP control/get X | FTP control/get X | 4027 |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(7) 4028 | | EXTERNAL | 4029 | |<---------------------------|(8) 4030 | | | 4031 | |RESPONSE[Success] | 4032 | |--------------------------->|(9) 4033 | |CREATE | 4034 | |--------------------------->|(10) 4035 | |RESPONSE[Success] | 4036 | |<---------------------------|(11) 4037 | | | 4038 | Use port=FOO, IP=a.b.c.d | Use port=FOO, IP=a.b.c.d | 4039 |<~~~~~~~~~~~~~~~~~~~~~~~~~~|<~~~~~~~~~~~~~~~~~~~~~~~~~~~|(12) 4040 | | | 4041 |FTP data to port=FOO | FTP data to port=20 | 4042 |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(13) 4044 Figure 37: Flow Chart 4046 1. EXTERNAL request message sent to NAT, with these objects: 4047 signaling session lifetime, extended flow information object 4048 (rule action=allow, sub_ports=0), message sequence number 4049 object, nonce object (carrying nonce for CREATE), and the data 4050 terminal information object (I/P-flags set, sender prefix=0, 4051 protocol=TCP, DR port number = 21, DS' IP address=0); using the 4052 LE-MRM. This is used to allocated the external binding for the 4053 FTP control channel (TCP, port 21) 4055 2. successful RESPONSE sent to NI+, with these objects: signaling 4056 session lifetime, message sequence number object, information 4057 code object (success:0x1), external address object (port=XYZ, 4058 IPv4 addr=a.b.c.d) 4060 3. The NAT sends a CREATE towards NI+, with these objects:signaling 4061 session lifetime, extended flow information object (rule 4062 action=allow, sub_ports=0), message sequence number object, 4063 nonce object (with copied value from (1)); using the PC-MRM 4064 (src-IP=a.b.c.d, src-port=XYZ, dst-IP=NI+, dst-port=21, 4065 downstream) 4067 4. successful RESPONSE sent to NAT, with these objects: signaling 4068 session lifetime, message sequence number object, information 4069 code object (success:0x1) 4071 5. application at NI+ sends external NAT binding information to 4072 other end, i.e., the FTP client at the DS 4074 6. the FTP client connects the FTP control channel to port=XYZ, 4075 IP=a.b.c.d 4077 7. the FTP client sends a get command for file X 4079 8. EXTERNAL request message sent to NAT, with these objects: 4080 signaling session lifetime, extended flow information object 4081 (rule action=allow, sub_ports=0), message sequence number 4082 object, nonce object (carrying nonce for CREATE), and the data 4083 terminal information object (I/P-flags set, sender prefix=32, 4084 protocol=TCP, DR port number = 20, DS' IP address=DS-IP); using 4085 the LE-MRM. This is used to allocated the external binding for 4086 the FTP data channel (TCP, port 22) 4088 9. successful RESPONSE sent to NI+, with these objects: signaling 4089 session lifetime, message sequence number object, information 4090 code object (success:0x1), external address object (port=FOO, 4091 IPv4 addr=a.b.c.d) 4093 10. The NAT sends a CREATE towards NI+, with these objects:signaling 4094 session lifetime, extended flow information object (rule 4095 action=allow, sub_ports=0), message sequence number object, 4096 nonce object (with copied value from (1)); using the PC-MRM 4097 (src-IP=a.b.c.d, src-port=FOO, dst-IP=NI+, dst-port=20, 4098 downstream) 4100 11. successful RESPONSE sent to NAT, with these objects: signaling 4101 session lifetime, message sequence number object, information 4102 code object (success:0x1) 4104 12. the FTP server responses with port=FOO and IP=a.b.c.d 4106 13. the FTP clients connects the data channel to port=FOO and 4107 IP=a.b.c.d 4109 Authors' Addresses 4111 Martin Stiemerling 4112 NEC Europe Ltd. and University of Goettingen 4113 Kurfuersten-Anlage 36 4114 Heidelberg 69115 4115 Germany 4117 Phone: +49 (0) 6221 4342 113 4118 Email: Martin.Stiemerling@neclab.eu 4119 URI: http://www.stiemerling.org 4121 Hannes Tschofenig 4122 Nokia Siemens Networks 4123 Linnoitustie 6 4124 Espoo 02600 4125 Finland 4127 Phone: +358 (50) 4871445 4128 Email: Hannes.Tschofenig@nsn.com 4129 URI: http://www.tschofenig.com 4131 Cedric Aoun 4132 Paris 4133 France 4135 Email: cedric@caoun.net 4137 Elwyn Davies 4138 Folly Consulting 4139 Soham 4140 UK 4142 Phone: +44 7889 488 335 4143 Email: elwynd@dial.pipex.com