idnits 2.17.1 draft-ietf-nsis-nslp-natfw-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3777. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3801. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5646 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-17 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-16 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-06 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group M. Stiemerling 3 Internet-Draft NEC 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 7, 2009 Nokia Siemens Networks 6 C. Aoun 7 E. Davies 8 Folly Consulting 9 November 3, 2008 11 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 12 draft-ietf-nsis-nslp-natfw-20.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 7, 2009. 39 Abstract 41 This memo defines the NSIS Signaling Layer Protocol (NSLP) for 42 Network Address Translators (NATs) and firewalls. This NSLP allows 43 hosts to signal on the data path for NATs and firewalls to be 44 configured according to the needs of the application data flows. For 45 instance, it enables hosts behind NATs to obtain a public reachable 46 address and hosts behind firewalls to receive data traffic. The 47 overall architecture is given by the framework and requirements 48 defined by the Next Steps in Signaling (NSIS) working group. The 49 network scenarios, the protocol itself, and examples for path-coupled 50 signaling are given in this memo. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 5 56 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 8 57 1.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 58 1.4. General Scenario for NATFW Traversal . . . . . . . . . . . 11 60 2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 13 61 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13 62 2.2. NAT with two Private Networks . . . . . . . . . . . . . . 14 63 2.3. NAT with Private Network on Sender Side . . . . . . . . . 15 64 2.4. NAT with Private Network on Receiver Side Scenario . . . . 15 65 2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . . 16 66 2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 17 67 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18 68 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 19 70 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 20 71 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 20 72 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21 73 3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 21 74 3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 22 75 3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 23 76 3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 25 77 3.2.5. State and Error Maintenance . . . . . . . . . . . . . 25 78 3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 26 79 3.2.7. Classification of RESPONSE Messages . . . . . . . . . 26 80 3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 27 81 3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 28 82 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 28 83 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 31 84 3.6. Authentication, Authorization, and Policy Decisions . . . 32 85 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 33 86 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 33 87 3.7.2. Reserving External Addresses . . . . . . . . . . . . . 36 88 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 43 89 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 45 90 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 46 91 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 48 92 3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 51 93 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 53 94 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 54 96 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 55 97 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 55 98 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 56 99 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 57 100 4.2.2. External Address Object . . . . . . . . . . . . . . . 57 101 4.2.3. Extended Flow Information Object . . . . . . . . . . . 58 102 4.2.4. Information Code Object . . . . . . . . . . . . . . . 59 103 4.2.5. Nonce Object . . . . . . . . . . . . . . . . . . . . . 62 104 4.2.6. Message Sequence Number Object . . . . . . . . . . . . 62 105 4.2.7. Data Terminal Information Object . . . . . . . . . . . 63 106 4.2.8. ICMP Types Object . . . . . . . . . . . . . . . . . . 64 107 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 65 108 4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 66 109 4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 66 110 4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 67 111 4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 67 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 69 114 5.1. Authorization Framework . . . . . . . . . . . . . . . . . 69 115 5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 69 116 5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 70 117 5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 71 118 5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 72 119 5.2.1. Security Protection between neighboring NATFW NSLP 120 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 72 121 5.2.2. Security Protection between non-neighboring NATFW 122 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 73 124 6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 75 126 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 128 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 130 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 131 9.1. Normative References . . . . . . . . . . . . . . . . . . . 79 132 9.2. Informative References . . . . . . . . . . . . . . . . . . 79 134 Appendix A. Selecting Signaling Destination Addresses for 135 EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 81 137 Appendix B. Applicability Statement on Data Receivers behind 138 Firewalls . . . . . . . . . . . . . . . . . . . . . . 82 140 Appendix C. Firewall and NAT Resources . . . . . . . . . . . . . 84 141 C.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 84 142 C.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 84 143 C.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 85 144 C.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 85 146 Appendix D. Protocols Numbers for Testing . . . . . . . . . . . . 87 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 149 Intellectual Property and Copyright Statements . . . . . . . . . . 89 151 1. Introduction 153 1.1. Scope and Background 155 Firewalls and Network Address Translators (NAT) have both been used 156 throughout the Internet for many years, and they will remain present 157 for the foreseeable future. Firewalls are used to protect networks 158 against certain types of attacks from internal networks and the 159 Internet, whereas NATs provide a virtual extension of the IP address 160 space. Both types of devices may be obstacles to some applications, 161 since they only allow traffic created by a limited set of 162 applications to traverse them, typically those that use protocols 163 with relatively predetermined and static properties (e.g., most HTTP 164 traffic, and other client/server applications). Other applications, 165 such as IP telephony and most other peer-to-peer applications, which 166 have more dynamic properties, create traffic that is unable to 167 traverse NATs and firewalls unassisted. In practice, the traffic of 168 many applications cannot traverse autonomous firewalls or NATs, even 169 when they have additional functionality which attempts to restore the 170 transparency of the network. 172 Several solutions to enable applications to traverse such entities 173 have been proposed and are currently in use. Typically, application 174 level gateways (ALG) have been integrated with the firewall or NAT to 175 configure the firewall or NAT dynamically. Another approach is 176 middlebox communication (MIDCOM). In this approach, ALGs external to 177 the firewall or NAT configure the corresponding entity via the MIDCOM 178 protocol [RFC3303]. Several other work-around solutions are 179 available, such as STUN [RFC5389]. However, all of these approaches 180 introduce other problems that are generally hard to solve, such as 181 dependencies on the type of NAT implementation (full-cone, symmetric, 182 etc), or dependencies on certain network topologies. 184 NAT and firewall (NATFW) signaling shares a property with Quality of 185 Service (QoS) signaling. The signaling of both must reach any device 186 on the data path that is involved in, respectively, NATFW or QoS 187 treatment of data packets. This means, that for both, NATFW and QoS, 188 it is convenient if signaling travels path-coupled, meaning that the 189 signaling messages follow exactly the same path that the data packets 190 take. RSVP [RFC2205] is an example of a current QoS signaling 191 protocol that is path-coupled. [rsvp-firewall] proposes the use of 192 RSVP as firewall signaling protocol but does not include NATs. 194 This memo defines a path-coupled signaling protocol for NAT and 195 firewall configuration within the framework of NSIS, called the NATFW 196 NSIS Signaling Layer Protocol (NSLP). The general requirements for 197 NSIS are defined in [RFC3726] and the general framework of NSIS is 198 outlined in [RFC4080]. It introduces the split between an NSIS 199 transport layer and an NSIS signaling layer. The transport of NSLP 200 messages is handled by an NSIS Network Transport Layer Protocol 201 (NTLP, with General Internet Signaling Transport (GIST) 202 [I-D.ietf-nsis-ntlp] being the implementation of the abstract NTLP). 203 The signaling logic for QoS and NATFW signaling is implemented in the 204 different NSLPs. The QoS NSLP is defined in 205 [I-D.ietf-nsis-qos-nslp]. 207 The NATFW NSLP is designed to request the dynamic configuration of 208 NATs and/or firewalls along the data path. Dynamic configuration 209 includes enabling data flows to traverse these devices without being 210 obstructed, as well as blocking of particular data flows at inbound 211 firewalls. Enabling data flows requires the loading of firewall 212 rules with an action that allows the data flow packets to be 213 forwarded and creating NAT bindings. Blocking of data flows requires 214 the loading of firewalls rules with an action that will deny 215 forwarding of the data flow packets. A simplified example for 216 enabling data flows: A source host sends a NATFW NSLP signaling 217 message towards its data destination. This message follows the data 218 path. Every NATFW NSLP-enabled NAT/firewall along the data path 219 intercepts this message, processes them, and configures itself 220 accordingly. Thereafter, the actual data flow can traverse all these 221 configured firewalls/NATs. 223 It is necessary to distinguish between two different basic scenarios 224 when operating the NATFW NSLP, independent of the type of the 225 middleboxes to be configured. 227 1. Both, data sender and data receiver, are NSIS NATFW NSLP aware. 228 This includes the cases where the data sender is logically 229 decomposed from the initiator of the NSIS signaling (the so- 230 called NSIS initiator) or the data receiver logically decomposed 231 from the receiver of the NSIS signaling (the so-called NSIS 232 receiver), but both sides support NSIS. This scenario assumes 233 deployment of NSIS all over the Internet, or at least at all NATs 234 and firewalls. This scenario is used as base assumption, if not 235 otherwise noted. 237 2. Only one end host or region of the network is NSIS NATFW NSLP 238 aware, either data receiver or data sender. This scenario is 239 referred to as proxy mode. 241 The NATFW NSLP has two basic signaling messages which are sufficient 242 to cope with the various possible scenarios likely to be encountered 243 before and after widespread deployment of NSIS: 245 CREATE message: Sent by the data sender for configuring a path 246 outbound from a data sender to a data receiver. 248 EXTERNAL message: Used by data receiver to locate inbound NATs/ 249 firewalls and prime them to expect inbound signaling and at NATs 250 to pre-allocate a public address. This is used for data receivers 251 behind these devices to enable their reachability. 253 CREATE and EXTERNAL messages are sent by the NSIS initiator (NI) 254 towards the NSIS responder (NR). Both type of messages are 255 acknowledged by a subsequent RESPONSE message. This RESPONSE message 256 is generated by the NR if the requested configuration can be 257 established, otherwise the NR or any of the NSIS forwarders (NFs) can 258 also generate such a message if an error occurs. NFs and the NR can 259 also generate asynchronous messages to notify the NI, the so called 260 NOTIFY messages. 262 If the data receiver resides in a private addressing realm or behind 263 a firewall, and needs to preconfigure the edge-NAT/edge-firewall to 264 provide a (publicly) reachable address for use by the data sender, a 265 combination of EXTERNAL and CREATE messages is used. 267 During the introduction of NSIS, it is likely that one or the other 268 of the data sender and receiver will not be NSIS aware. In these 269 cases, the NATFW NSLP can utilize NSIS aware middleboxes on the path 270 between the data sender and data receiver to provide proxy NATFW NSLP 271 services (i.e., the proxy mode). Typically, these boxes will be at 272 the boundaries of the realms in which the end hosts are located. 274 The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in 275 NSIS entities. NTLP state allows signaling messages to travel in the 276 forward (outbound) and the reverse (inbound) direction along the path 277 between a NAT/firewall NSLP sender and a corresponding receiver. 278 This state is managed using a soft-state mechanism, i.e., it expires 279 unless it is refreshed from time to time. The NAT bindings and 280 firewall rules being installed during the state setup are bound to 281 the particular signaling session. However, the exact local 282 implementation of the NAT bindings and firewall rules are NAT/ 283 firewall specific and it is out of scope of this memo. 285 This memo is structured as follows. Section 2 describes the network 286 environment for NATFW NSLP signaling. Section 3 defines the NATFW 287 signaling protocol and Section 4 defines the message components and 288 the overall messages used in the protocol. The remaining parts of 289 the main body of the document cover security considerations 290 Section 5, IAB considerations on UNilateral Self-Address Fixing 291 (UNSAF) [RFC3424] in Section 6 and IANA considerations in Section 7. 292 Please note that readers familiar with firewalls and NATs and their 293 possible location within networks can safely skip Section 2. 295 1.2. Terminology and Abbreviations 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 299 document are to be interpreted as described in [RFC2119]. 301 This document uses a number of terms defined in [RFC3726] and 302 [RFC4080]. The following additional terms are used: 304 o Policy rule: A policy rule is "a basic building block of a policy- 305 based system. It is the binding of a set of actions to a set of 306 conditions - where the conditions are evaluated to determine 307 whether the actions are performed" [RFC3198]. In the context of 308 NSIS NATFW NSLP, the conditions are the specification of a set of 309 packets to which the rule is applied. The set of actions always 310 contains just a single element per rule, and is limited to either 311 action "deny" or action "allow". 313 o Reserved policy rule: A policy rule stored at NATs or firewalls 314 for activation by a later, different signaling exchange. This 315 type of policy rule is kept in the NATFW NSLP and is not loaded 316 into the firewall or NAT engine, i.e., it does not affect the data 317 flow handling. 319 o Installed policy rule: A policy rule in operation at NATs or 320 firewalls. This type of rule is kept in the NATFW NSLP and is 321 loaded into the firewall or NAT engine, i.e., it is affecting the 322 data flow. 324 o Remembered policy rule: A policy rule stored at NATs and firewalls 325 for immediate use, as soon as the signaling exchange is 326 successfully completed. 328 o Firewall: A packet filtering device that matches packets against a 329 set of policy rules and applies the actions. 331 o Network Address Translator: Network Address Translation is a 332 method by which IP addresses are mapped from one IP address realm 333 to another, in an attempt to provide transparent routing between 334 hosts (see [RFC2663]). Network Address Translators are devices 335 that perform this work by modifying packets passing through them. 337 o Data Receiver (DR): The node in the network that is receiving the 338 data packets of a flow. 340 o Data Sender (DS): The node in the network that is sending the data 341 packets of a flow. 343 o NATFW NSLP peer or peer: An NSIS NATFW NSLP node with which an 344 NTLP adjacency has been created as defined in 345 [I-D.ietf-nsis-ntlp]. 347 o NATFW NSLP signaling session or signaling session: A signaling 348 session defines an association between the NI, NFs, and the NR 349 related to a data flow. All the NATFW NSLP peers on the path, 350 including the NI and the NR, use the same identifier to refer to 351 the state stored for the association. The same NI and NR may have 352 more than one signaling session active at any time. The state for 353 NATFW NSLP consists of NSLP state and associated policy rules at a 354 middlebox. 356 o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP 357 address which is reachable from the public Internet. 359 o Edge-firewall: An edge-firewall is a firewall device that is 360 located on the border line of an administrative domain. 362 o Public Network: "A Global or Public Network is an address realm 363 with unique network addresses assigned by Internet Assigned 364 Numbers Authority (IANA) or an equivalent address registry. This 365 network is also referred as external network during NAT 366 discussions" [RFC2663]. 368 o Private/Local Network: "A private network is an address realm 369 independent of external network addresses. Private network may 370 also be referred alternately as Local Network. Transparent 371 routing between hosts in private realm and external realm is 372 facilitated by a NAT router" [RFC2663]. 374 o Public/Global IP address: An IP address located in the public 375 network according to Section 2.7 of [RFC2663]. 377 o Private/Local IP address: An IP address located in the private 378 network according to Section 2.8 of [RFC2663]. 380 o Signaling Destination Address (SDA): An IP address generally taken 381 from the public/global IP address range, although, the SDA may in 382 certain circumstances be part of the private/local IP address 383 range. This address is used in EXTERNAL signaling message 384 exchanges, if the data receiver's IP address is unknown. 386 1.3. Middleboxes 388 The term middlebox covers a range of devices and is well-defined in 389 [RFC3234]: "A middlebox is defined as any intermediate device 390 performing functions other than the normal, standard functions of an 391 IP router on the datagram path between source host and a destination 392 host". As such, middleboxes fall into a number of categories with a 393 wide range of functionality, not all of which is pertinent to the 394 NATFW NSLP. Middlebox categories in the scope of this memo are 395 firewalls that filter data packets against a set of filter rules, and 396 NATs that translate packet addresses from one address realm to 397 another address realm. Other categories of middleboxes, such as QoS 398 traffic shapers, are out of scope of this memo. 400 The term NAT used in this document is a placeholder for a range of 401 different NAT flavors. We consider the following types of NATs: 403 o Traditional NAT (basic NAT and NAPT) 405 o Bi-directional NAT 407 o Twice-NAT 409 o Multihomed NAT 411 For definitions and a detailed discussion about the characteristics 412 of each NAT type please see [RFC2663]. 414 All types of middleboxes under consideration here, use policy rules 415 to make a decision on data packet treatment. Policy rules consist of 416 a flow identifier which selects the packets to which the policy 417 applies and an associated action; data packets matching the flow 418 identifier are subjected to the policy rule action. A typical flow 419 identifier is the 5-tuple selector which matches the following fields 420 of a packet to configured values: 422 o Source and destination IP addresses 424 o Transport protocol number 426 o Transport source and destination port numbers 428 Actions for firewalls are usually one or more of: 430 o Allow: forward data packet 432 o Deny: block data packet and discard it 434 o Other actions such as logging, diverting, duplicating, etc 436 Actions for NATs include (amongst many others): 438 o Change source IP address and transport port number to a globally 439 routable IP address and associated port number. 441 o Change destination IP address and transport port number to a 442 private IP address and associated port number. 444 It should be noted that a middlebox may contain two logical 445 representations of the policy rule. The policy rule has a 446 representation within the NATFW NSLP, comprising the message routing 447 information (MRI) of the NTLP and NSLP information (such as the rule 448 action). The other representation is the implementation of the NATFW 449 NSLP policy rule within the NAT and firewall engine of the particular 450 device. Refer to Appendix C for further details. 452 1.4. General Scenario for NATFW Traversal 454 The purpose of NSIS NATFW signaling is to enable communication 455 between endpoints across networks, even in the presence of NAT and 456 firewall middleboxes that have not been specially engineered to 457 facilitate communication with the application protocols used. This 458 removes the need to create and maintain application layer gateways 459 for specific protocols that have been commonly used to provide 460 transparency in previous generations of NAT and firewall middleboxes. 461 It is assumed that these middleboxes will be statically configured in 462 such a way that NSIS NATFW signaling messages themselves are allowed 463 to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP 464 signaling is used to dynamically install additional policy rules in 465 all NATFW middleboxes along the data path that will allow 466 transmission of the application data flow(s). Firewalls are 467 configured to forward data packets matching the policy rule provided 468 by the NSLP signaling. NATs are configured to translate data packets 469 matching the policy rule provided by the NSLP signaling. An 470 additional capability, that is an exception to the primary goal of 471 NSIS NATFW signaling, is that the NATFW nodes can request blocking of 472 particular data flows instead of enabling these flows at inbound 473 firewalls. 475 The basic high-level picture of NSIS usage is that end hosts are 476 located behind middleboxes, meaning that there is at least one 477 middlebox on the data path from the end host in a private network to 478 the external network (NATFW in Figure 1). Applications located at 479 these end hosts try to establish communication with corresponding 480 applications on other such end hosts. They trigger the NSIS entity 481 at the local host to control provisioning for middlebox traversal 482 along the prospective data path (e.g., via an API call). The NSIS 483 entity in turn uses NSIS NATFW NSLP signaling to establish policy 484 rules along the data path, allowing the data to travel from the 485 sender to the receiver unobstructed. 487 Application Application Server (0, 1, or more) Application 489 +----+ +----+ +----+ 490 | +------------------------+ +------------------------+ | 491 +-+--+ +----+ +-+--+ 492 | | 493 | NSIS Entities NSIS Entities | 494 +-+--+ +----+ +-----+ +-+--+ 495 | +--------+ +----------------------------+ +-----+ | 496 +-+--+ +-+--+ +--+--+ +-+--+ 497 | | ------ | | 498 | | //// \\\\\ | | 499 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 500 | | | | | Internet | | | | | 501 | +--------+ +-----+ +----+ +-----+ | 502 +----+ +----+ |\ | +----+ +----+ 503 \\\\ ///// 504 sender NATFW (1+) ------ NATFW (1+) receiver 506 Note that 1+ refers to one or more NATFW nodes. 508 Figure 1: Generic View of NSIS with NATs and/or firewalls 510 For end-to-end NATFW signaling, it is necessary that each firewall 511 and each NAT along the path between the data sender and the data 512 receiver implements the NSIS NATFW NSLP. There might be several NATs 513 and FWs in various possible combinations on a path between two hosts. 514 Section 2 presents a number of likely scenarios with different 515 combinations of NATs and firewalls. However, the scenarios given in 516 the following sections are not limiting the scope of the NATFW NSLP 517 to them only, but they are examples only. 519 2. Network Deployment Scenarios using the NATFW NSLP 521 This section introduces several scenarios for middlebox placement 522 within IP networks. Middleboxes are typically found at various 523 different locations, including at enterprise network borders, within 524 enterprise networks, as mobile phone network gateways, etc. Usually, 525 middleboxes are placed more towards the edge of networks than in 526 network cores. Firewalls and NATs may be found at these locations 527 either alone, or they may be combined; other categories of 528 middleboxes may also be found at such locations, possibly combined 529 with the NATs and/or firewalls. 531 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 532 regular data path to the NSIS responder (NR). On the data path, 533 NATFW NSLP signaling messages reach different NSIS nodes that 534 implement the NATFW NSLP. Each NATFW NSLP node processes the 535 signaling messages according to Section 3 and, if necessary, installs 536 policy rules for subsequent data packets. 538 Each of the following sub-sections introduces a different scenario 539 for a different set of middleboxes and their ordering within the 540 topology. It is assumed that each middlebox implements the NSIS 541 NATFW NSLP signaling protocol. 543 2.1. Firewall Traversal 545 This section describes a scenario with firewalls only; NATs are not 546 involved. Each end host is behind a firewall. The firewalls are 547 connected via the public Internet. Figure 2 shows the topology. The 548 part labeled "public" is the Internet connecting both firewalls. 550 +----+ //----\\ +----+ 551 NI -----| FW |---| |------| FW |--- NR 552 +----+ \\----// +----+ 554 private public private 556 FW: Firewall 557 NI: NSIS Initiator 558 NR: NSIS Responder 560 Figure 2: Firewall Traversal Scenario 562 Each firewall on the data path must provide traversal service for 563 NATFW NSLP in order to permit the NSIS message to reach the other end 564 host. All firewalls process NSIS signaling and establish appropriate 565 policy rules, so that the required data packet flow can traverse 566 them. 568 There are several very different ways to place firewalls in a network 569 topology. To distinguish firewalls located at network borders, such 570 as administrative domains, from others located internally, the term 571 edge-firewall is used. A similar distinction can be made for NATs, 572 with an edge-NAT fulfilling the equivalent role. 574 2.2. NAT with two Private Networks 576 Figure 3 shows a scenario with NATs at both ends of the network. 577 Therefore, each application instance, the NSIS initiator and the NSIS 578 responder, are behind NATs. The outermost NAT, known as the edge-NAT 579 (MB2 and MB3), at each side is connected to the public Internet. The 580 NATs are generically labeled as MBX (for middlebox No. X), since 581 those devices certainly implement NAT functionality, but can 582 implement firewall functionality as well. 584 Only two middleboxes MB are shown in Figure 3 at each side, but in 585 general, any number of MBs on each side must be considered. 587 +----+ +----+ //----\\ +----+ +----+ 588 NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR 589 +----+ +----+ \\----// +----+ +----+ 591 private public private 593 MB: Middlebox 594 NI: NSIS Initiator 595 NR: NSIS Responder 597 Figure 3: NAT with two Private Networks Scenario 599 Signaling traffic from NI to NR has to traverse all the middleboxes 600 on the path (MB1 to MB4, in this order), and all the middleboxes must 601 be configured properly to allow NSIS signaling to traverse them. The 602 NATFW signaling must configure all middleboxes and consider any 603 address translation that will result from this configuration in 604 further signaling. The sender (NI) has to know the IP address of the 605 receiver (NR) in advance, otherwise it will not be possible to send 606 any NSIS signaling messages towards the responder. Note that this IP 607 address is not the private IP address of the responder but the NAT's 608 public IP address (here MB3's IP address). Instead a NAT binding 609 (including a public IP address) has to be previously installed on the 610 NAT MB3. This NAT binding subsequently allows packets reaching the 611 NAT to be forwarded to the receiver within the private address realm. 613 The receiver might have a number of ways to learn its public IP 614 address and port number (including the NATFW NSLP) and might need to 615 signal this information to the sender using an application level 616 signaling protocol. 618 2.3. NAT with Private Network on Sender Side 620 This scenario shows an application instance at the sending node that 621 is behind one or more NATs (shown as generic MB, see discussion in 622 Section 2.2). The receiver is located in the public Internet. 624 +----+ +----+ //----\\ 625 NI --| MB |-----| MB |---| |--- NR 626 +----+ +----+ \\----// 628 private public 630 MB: Middlebox 631 NI: NSIS Initiator 632 NR: NSIS Responder 634 Figure 4: NAT with Private Network on Sender Side 636 The traffic from NI to NR has to traverse middleboxes only on the 637 sender's side. The receiver has a public IP address. The NI sends 638 its signaling message directly to the address of the NSIS responder. 639 Middleboxes along the path intercept the signaling messages and 640 configure accordingly. 642 The data sender does not necessarily know whether the receiver is 643 behind a NAT or not, hence, it is the receiving side that has to 644 detect whether itself is behind a NAT or not. 646 2.4. NAT with Private Network on Receiver Side Scenario 648 The application instance receiving data is behind one or more NATs 649 shown as MB (see discussion in Section 2.2). 651 //----\\ +----+ +----+ 652 NI ---| |---| MB |-----| MB |--- NR 653 \\----// +----+ +----+ 655 public private 657 MB: Middlebox 658 NI: NSIS Initiator 659 NR: NSIS Responder 661 Figure 5: NAT with Private Network on Receiver Scenario 663 Initially, the NSIS responder must determine its publicly reachable 664 IP address at the external middlebox and notify the NSIS initiator 665 about this address. One possibility is that an application level 666 protocol is used, meaning that the public IP address is signaled via 667 this protocol to the NI. Afterwards the NI can start its signaling 668 towards the NR and therefore establish the path via the middleboxes 669 in the receiver side private network. 671 This scenario describes the use case for the EXTERNAL message of the 672 NATFW NSLP. 674 2.5. Both End Hosts behind twice-NATs 676 This is a special case, where the main problem arises from the need 677 to detect that both end hosts are logically within the same address 678 space, but are also in two partitions of the address realm on either 679 side of a twice-NAT (see [RFC2663] for a discussion of twice-NAT 680 functionality). 682 Sender and receiver are both within a single private address realm 683 but the two partitions potentially have overlapping IP address 684 ranges. Figure 6 shows the arrangement of NATs. 686 public 688 +----+ +----+ //----\\ 689 NI --| MB |--+--| MB |---| | 690 +----+ | +----+ \\----// 691 | 692 | +----+ 693 +--| MB |------------ NR 694 +----+ 696 private 698 MB: Middlebox 699 NI: NSIS Initiator 700 NR: NSIS Responder 702 Figure 6: NAT to Public, Sender and Receiver on either side of a 703 twice-NAT Scenario 705 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 706 addresses and port numbers on both sides, meaning the mapping of 707 source and destination address at the private and public interfaces. 709 This scenario requires the assistance of application level entities, 710 such as a DNS server. The application level entities must handle 711 requests that are based on symbolic names, and configure the 712 middleboxes so that data packets are correctly forwarded from NI to 713 NR. The configuration of those middleboxes may require other 714 middlebox communication protocols, such as MIDCOM [RFC3303]. NSIS 715 signaling is not required in the twice-NAT only case, since 716 middleboxes of the twice-NAT type are normally configured by other 717 means. Nevertheless, NSIS signaling might be useful when there are 718 also firewalls on the path. In this case NSIS will not configure any 719 policy rule at twice-NATs, but will configure policy rules at the 720 firewalls on the path. The NSIS signaling protocol must be at least 721 robust enough to survive this scenario. This requires that twice- 722 NATs must implement the NATFW NSLP also and participate in NATFW 723 signaling sessions but they do not change the configuration of the 724 NAT, i.e., they only read the address mapping information out of the 725 NAT and translate the Message Routing Information (MRI, 726 [I-D.ietf-nsis-ntlp]) within the NSLP and NTLP accordingly. For more 727 information see Appendix C.4 729 2.6. Both End Hosts Behind Same NAT 731 When NSIS initiator and NSIS responder are behind the same NAT (thus 732 being in the same address realm, see Figure 7), they are most likely 733 not aware of this fact. As in Section 2.4 the NSIS responder must 734 determine its public IP address in advance and transfer it to the 735 NSIS initiator. Afterwards, the NSIS initiator can start sending the 736 signaling messages to the responder's public IP address. During this 737 process, a public IP address will be allocated for the NSIS initiator 738 at the same middlebox as for the responder. Now, the NSIS signaling 739 and the subsequent data packets will traverse the NAT twice: from 740 initiator to public IP address of responder (first time) and from 741 public IP address of responder to responder (second time). 743 NI public 744 \ +----+ //----\\ 745 +-| MB |----| | 746 / +----+ \\----// 747 NR 748 private 750 MB: Middlebox 751 NI: NSIS Initiator 752 NR: NSIS Responder 754 Figure 7: NAT to Public, Both Hosts Behind Same NAT 756 2.7. Multihomed Network with NAT 758 The previous sub-sections sketched network topologies where several 759 NATs and/or firewalls are ordered sequentially on the path. This 760 section describes a multihomed scenario with two NATs placed on 761 alternative paths to the public network. 763 +----+ //---\\ 764 NI -------| MB |---| | 765 \ +----+ \\-+-// 766 \ | 767 \ +----- NR 768 \ | 769 \ +----+ //-+-\\ 770 --| MB |---| | 771 +----+ \\---// 773 private public 775 MB: Middlebox 776 NI: NSIS Initiator 777 NR: NSIS Responder 779 Figure 8: Multihomed Network with Two NATs 781 Depending on the destination, either one or the other middlebox is 782 used for the data flow. Which middlebox is used, depends on local 783 policy or routing decisions. NATFW NSLP must be able to handle this 784 situation properly, see Section 3.7.2 for an extended discussion of 785 this topic with respect to NATs. 787 2.8. Multihomed Network with Firewall 789 This section describes a multihomed scenario with two firewalls 790 placed on alternative paths to the public network (Figure 9). The 791 routing in the private and public network decides which firewall is 792 being taken for data flows. Depending on the data flow's direction, 793 either outbound or inbound, a different firewall could be traversed. 794 This is a challenge for the EXTERNAL message of the NATFW NSLP where 795 the NSIS responder is located behind these firewalls within the 796 private network. The EXTERNAL message is used to block a particular 797 data flow on an inbound firewall. NSIS must route the EXTERNAL 798 message inbound from NR to NI probably without knowing which path the 799 data traffic will take from NI to NR (see also Appendix B). 801 +----+ 802 NR -------| FW |\ 803 \ +----+ \ //---\\ 804 \ -| |-- NI 805 \ \\---// 806 \ +----+ | 807 --| FW |-------+ 808 +----+ 809 private 811 private public 813 FW: Firewall 814 NI: NSIS Initiator 815 NR: NSIS Responder 817 Figure 9: Multihomed Network with two firewalls 819 3. Protocol Description 821 This section defines messages, objects, and protocol semantics for 822 the NATFW NSLP. 824 3.1. Policy Rules 826 Policy rules, bound to a NATFW NSLP signaling session, are the 827 building blocks of middlebox devices considered in the NATFW NSLP. 828 For firewalls the policy rule usually consists of a 5-tuple and an 829 action such as allow or deny. The information contained in the tuple 830 includes source/destination addresses, transport protocol and source/ 831 destination port numbers. For NATs the policy rule consists of the 832 action 'translate this address' and further mapping information, that 833 might be, in the simplest case, internal IP address and external IP 834 address. 836 The NATFW NSLP carries, in conjunction with the NTLP's Message 837 Routing Information (MRI), the policy rules to be installed at NATFW 838 peers. This policy rule is an abstraction with respect to the real 839 policy rule to be installed at the respective firewall or NAT. It 840 conveys the initiator's request and must be mapped to the possible 841 configuration on the particular used NAT and/or firewall in use. For 842 pure firewalls one or more filter rules must be created and for pure 843 NATs one or more NAT bindings must be created. In mixed firewall and 844 NAT boxes, the policy rule must be mapped to filter rules and 845 bindings observing the ordering of the firewall and NAT engine. 846 Depending on the ordering, NAT before firewall or vice versa, the 847 firewall rules must carry public or private IP addresses. However, 848 the exact mapping depends on the implementation of the firewall or 849 NAT which is possibly different for each implementation. 851 The policy rule at the NATFW NSLP level comprises the message routing 852 information (MRI) part, carried in the NTLP, and the information 853 available in the NATFW NSLP. The information provided by the NSLP is 854 stored in the 'extend flow information' (NATFW_EFI) and 'data 855 terminal information' (NATFW_DTINFO) objects, and the message type. 856 Additional information, such as the external IP address and port 857 number, stored in the NAT or firewall, will be used as well. The MRI 858 carries the filter part of the NAT/firewall-level policy rule that is 859 to be installed. 861 The NATFW NSLP specifies two actions for the policy rules: deny and 862 allow. A policy rule with action set to deny will result in all 863 packets matching this rule to be dropped. A policy rule with action 864 set to allow will result in all packets matching this rule to be 865 forwarded. 867 3.2. Basic Protocol Overview 869 The NSIS NATFW NSLP is carried over the General Internet Signaling 870 Transport (GIST, the implementation of the NTLP) defined in 871 [I-D.ietf-nsis-ntlp]. NATFW NSLP messages are initiated by the NSIS 872 initiator (NI), handled by NSIS forwarders (NF) and received by the 873 NSIS responder (NR). It is required that at least NI and NR 874 implement this NSLP, intermediate NFs only implement this NSLP when 875 they provide relevant middlebox functions. NSIS forwarders that do 876 not have any NATFW NSLP functions just forward these packets as they 877 have no interest in them. 879 3.2.1. Signaling for Outbound Traffic 881 A Data Sender (DS), intending to send data to a Data Receiver (DR) 882 has to start NATFW NSLP signaling. This causes the NI associated 883 with the data sender (DS) to launch NSLP signaling towards the 884 address of data receiver (DR) (see Figure 10). Although it is 885 expected that the DS and the NATFW NSLP NI will usually reside on the 886 same host, this specification does not rule out scenarios where the 887 DS and NI reside on different hosts, the so-called proxy mode (see 888 Section 3.7.6.) 890 +-------+ +-------+ +-------+ +-------+ 891 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 892 | |--->| NF1 |--->| NF2 |--->| | 893 +-------+ +-------+ +-------+ +-------+ 895 ========================================> 896 Data Traffic Direction (outbound) 898 ---> : NATFW NSLP request signaling 899 ~~~> : NATFW NSLP response signaling 900 DS/NI : Data sender and NSIS initiator 901 DR/NR : Data receiver and NSIS responder 902 MB1 : Middlebox 1 and NSIS forwarder 1 903 MB2 : Middlebox 2 and NSIS forwarder 2 905 Figure 10: General NSIS signaling 907 The following list shows the normal sequence of NSLP events without 908 detailing the interaction with the NTLP and the interactions on the 909 the NTLP level. 911 o NSIS initiators generate request messages (which are either CREATE 912 or EXTERNAL messages) and send these towards the NSIS responder. 914 This request message is the initial message which creates a new 915 NATFW NSLP signaling session. The NI and the NR will most likely 916 already share an application session before they start the NATFW 917 NSLP signaling session. Note well the difference between both 918 sessions. 920 o NSLP request messages are processed each time a NF with NATFW NSLP 921 support is traversed. Each NF that is intercepting a request 922 message and is accepting it for further treatment is joining the 923 particular NATFW NSLP signaling session. These nodes process the 924 message, check local policies for authorization and 925 authentication, possibly create policy rules, and forward the 926 signaling message to the next NSIS node. The request message is 927 forwarded until it reaches the NSIS responder. 929 o NSIS responders will check received messages and process them if 930 applicable. NSIS responders generate RESPONSE messages and send 931 them hop-by-hop back to the NI via the same chain of NFs 932 (traversal of the same NF chain is guaranteed through the 933 established reverse message routing state in the NTLP). The NR is 934 also joining the NATFW NSLP signaling session if the request 935 message is accepted. 937 o The RESPONSE message is processed at each NF that has been 938 included in the prior NATFW NSLP signaling session setup. 940 o If the NI has received a successful RESPONSE message and if the 941 signaling NATFW NSLP session started with a CREATE message, the 942 data sender can start sending its data flow to the data receiver. 943 If the NI has received a successful RESPONSE message and if the 944 signaling NATFW NSLP session started with a EXTERNAL message, the 945 data receiver is ready to receive further CREATE messages. 947 Because NATFW NSLP signaling follows the data path from DS to DR, 948 this immediately enables communication between both hosts for 949 scenarios with only firewalls on the data path or NATs on the sender 950 side. For scenarios with NATs on the receiver side certain problems 951 arise, as described in Section 2.4. 953 3.2.2. Signaling for Inbound Traffic 955 When the NR and the NI are located in different address realms and 956 the NR is located behind a NAT, the NI cannot signal to the NR 957 address directly. The DR/NR is not reachable from other NIs using 958 the private address of the NR and thus NATFW signaling messages 959 cannot be sent to the NR/DR's address. Therefore, the NR must first 960 obtain a NAT binding that provides an address that is reachable for 961 the NI. Once the NR has acquired a public IP address, it forwards 962 this information to the DS via a separate protocol. This application 963 layer signaling, which is out of scope of the NATFW NSLP, may involve 964 third parties that assist in exchanging these messages. 966 The same holds partially true for NRs located behind firewalls that 967 block all traffic by default. In this case, NR must tell its inbound 968 firewalls of inbound NATFW NSLP signaling and corresponding data 969 traffic. Once the NR has informed the inbound firewalls, it can 970 start its application level signaling to initiate communication with 971 the NI. This mechanism can be used by machines hosting services 972 behind firewalls as well. In this case, the NR informs the inbound 973 firewalls as described, but does not need to communicate this to the 974 NIs. 976 NATFW NSLP signaling supports this scenario by using the EXTERNAL 977 message 979 1. The DR acquires a public address by signaling on the reverse path 980 (DR towards DS) and thus making itself available to other hosts. 981 This process of acquiring public addresses is called reservation. 982 During this process the DR reserves publicly reachable addresses 983 and ports suitable for further usage in application level 984 signaling and the publicly reachable address for further NATFW 985 NSLP signaling. However, the data traffic will not be allowed to 986 use this address/port initially (see next point). In the process 987 of reservation the DR becomes the NI for the messages necessary 988 to obtain the publicly reachable IP address, i.e., the NI for 989 this specific NATFW NSLP signaling session. 991 2. Now on the side of DS, the NI creates a new NATFW NSLP signaling 992 session and signals directly to the public IP address of DR. 993 This public IP address is used as NR's address, as the NI would 994 do if there is no NAT in between, and creates policy rules at 995 middleboxes. Note, that the reservation will only allow 996 forwarding of signaling messages, but not data flow packets. 997 Policy rules allowing forwarding of data flow packets set up by 998 the prior EXTERNAL message signaling will be activated when the 999 signaling from NI towards NR is confirmed with a positive 1000 RESPONSE message. The EXTERNAL message is described in 1001 Section 3.7.2. 1003 3.2.3. Signaling for Proxy Mode 1004 administrative domain 1005 ----------------------------------\ 1006 | 1007 +-------+ +-------+ +-------+ | +-------+ 1008 | DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR | 1009 | |--->| NF1 |--->| NR | | | | 1010 +-------+ +-------+ +-------+ | +-------+ 1011 | 1012 ----------------------------------/ 1014 ========================================> 1015 Data Traffic Direction (outbound) 1017 ---> : NATFW NSLP request signaling 1018 ~~~> : NATFW NSLP response signaling 1019 DS/NI : Data sender and NSIS initiator 1020 DR/NR : Data receiver and NSIS responder 1021 MB1 : Middlebox 1 and NSIS forwarder 1 1022 MB2 : Middlebox 2 and NSIS responder 1024 Figure 11: proxy mode signaling for data sender 1026 The above usage assumes that both ends of a communication support 1027 NSIS, but fails when NSIS is only deployed at one end of the path. 1028 In this case only one of the sending Figure 11 or receiving Figure 12 1029 side is NSIS aware and not both at the same time. NATFW NSLP 1030 supports both scenarios (i.e., either the DS or DR do not support 1031 NSIS) by using a proxy mode, as described in Section 3.7.6 1032 administrative domain 1033 / ---------------------------------- 1034 | 1035 +-------+ | +-------+ +-------+ +-------+ 1036 | DS | | | MB2/ |~~~>| MB1/ |~~~>| DR | 1037 | | | | NR |<---| NF1 |<---| | 1038 +-------+ | +-------+ +-------+ +-------+ 1039 | 1040 \---------------------------------- 1042 ========================================> 1043 Data Traffic Direction (inbound) 1045 ---> : NATFW NSLP request signaling 1046 ~~~> : NATFW NSLP response signaling 1047 DS/NI : Data sender and NSIS initiator 1048 DR/NR : Data receiver and NSIS responder 1049 MB1 : Middlebox 1 and NSIS forwarder 1 1050 MB2 : Middlebox 2 and NSIS responder 1052 Figure 12: proxy mode signaling for data receiver 1054 3.2.4. Blocking Traffic 1056 The basic functionality of the NATFW NSLP provides for opening 1057 firewall pin holes and creating NAT bindings to enable data flows to 1058 traverse these devices. Firewalls are normally expected to work on a 1059 'deny-all' policy, meaning that traffic not explicitly matching any 1060 firewall filter rule will be blocked. Similarly, the normal behavior 1061 of NATs is to block all traffic that does not match any already 1062 configured/installed binding or NATFW NSLP session. However, some 1063 scenarios require support of firewalls having 'allow-all' policies, 1064 allowing data traffic to traverse the firewall unless it is blocked 1065 explicitly. Data receivers can utilize NATFW NSLP's EXTERNAL message 1066 with action set to 'deny' to install policy rules at inbound 1067 firewalls to block unwanted traffic. 1069 3.2.5. State and Error Maintenance 1071 The protocol works on a soft-state basis, meaning that whatever state 1072 is installed or reserved on a middlebox will expire, and thus be de- 1073 installed or forgotten after a certain period of time. To prevent 1074 premature removal of state that is needed for ongoing communication, 1075 the NATFW NI involved will have to specifically request a NATFW NSLP 1076 signaling session extension. An explicit NATFW NSLP state deletion 1077 capability is also provided by the protocol. 1079 If the actions requested by a NATFW NSLP message cannot be carried 1080 out, NFs and the NR must return a failure, such that appropriate 1081 actions can be taken. They can do this either during the request 1082 message handling (synchronously) by sending an error RESPONSE 1083 message, or at any time (asynchronously) by sending a NOTIFY 1084 notification message. 1086 The next sections define the NATFW NSLP message types and formats, 1087 protocol operations, and policy rule operations. 1089 3.2.6. Message Types 1091 The protocol uses four messages types: 1093 o CREATE: a request message used for creating, changing, refreshing, 1094 and deleting NATFW NSLP signaling sessions, i.e., open the data 1095 path from DS to DR. 1097 o EXTERNAL: a request message used for reserving, changing, 1098 refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions. 1099 EXTERNAL messages are forwarded to the edge-NAT or edge-firewall 1100 and allow inbound CREATE messages to be forwarded to the NR. 1101 Additionally, EXTERNAL messages reserve an external address and, 1102 if applicable, port number at an edge-NAT. 1104 o NOTIFY: an asynchronous message used by NATFW peers to alert other 1105 NATFW peers about specific events (especially failures). 1107 o RESPONSE: used as a response to CREATE and EXTERNAL request 1108 messages. 1110 3.2.7. Classification of RESPONSE Messages 1112 RESPONSE messages will be generated synchronously to CREATE and 1113 EXTERNAL messages by NSIS Forwarders and Responders to report success 1114 or failure of operations or some information relating to the NATFW 1115 NSLP signaling session or a node. RESPONSE messages MUST NOT be 1116 generated for any other message, such as NOTIFY and RESPONSE. 1118 All RESPONSE messages MUST carry a NATFW_INFO object which contains a 1119 severity class code and a response code (see Section 4.2.4). This 1120 section defines terms for groups of RESPONSE messages depending on 1121 the severity class. 1123 o Successful RESPONSE: Messages carrying NATFW_INFO with severity 1124 class 'Success' (0x2). 1126 o Informational RESPONSE: Messages carrying NATFW_INFO with severity 1127 class 'Informational' (0x1) (only used with NOTIFY messages). 1129 o Error RESPONSE: Messages carrying NATFW_INFO with severity class 1130 other than 'Success' or 'Informational'. 1132 3.2.8. NATFW NSLP Signaling Sessions 1134 A NATFW NSLP signaling session defines an association between the NI, 1135 NFs, and the NR related to a data flow. This association is created 1136 when the initial CREATE or EXTERNAL message is successfully received 1137 at the NFs or the NR. There is signaling NATFW NSLP session state 1138 stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP 1139 signaling session state for the NATFW NSLP comprises NSLP state and 1140 the associated policy rules at a middlebox. 1142 The NATFW NSLP signaling session is identified by the session ID 1143 (plus other information at the NTLP level). The session ID is 1144 generated by the NI before the initial CREATE or EXTERNAL message is 1145 sent. The value of the session ID MUST be generated in a random way 1146 by the NI, i.e., the output MUST NOT be easily guessable by third 1147 parties. The session ID is not stored in any NATFW NSLP message but 1148 passed on to the NTLP. 1150 A NATFW NSLP signaling session has several conceptional states that 1151 describes in what state a signaling session is at a given time. The 1152 signaling session can have these states at a node: 1154 o Pending: The NATFW NSLP signaling session has been created and the 1155 node is waiting for a RESPONSE message to the CREATE or EXTERNAL 1156 message. A NATFW NSLP signaling session in state 'Pending' MUST 1157 be marked as 'Dead' if no corresponding RESPONSE message has been 1158 received within the time of the locally granted NATFW NSLP 1159 signaling session lifetime of the forwarded CREATE or EXTERNAL 1160 message (as described in Section 3.4). 1162 o Established: The NATFW NSLP signaling session is established, i.e, 1163 the signaling has been successfully performed and the lifetime of 1164 NATFW NSLP signaling session is counted from now on. A NATFW NSLP 1165 signaling session in state 'Established' MUST be marked as 'Dead' 1166 if no refresh message has been received within the time of the 1167 locally granted NATFW NSLP signaling session lifetime of the 1168 RESPONSE message (as described in Section 3.4). 1170 o Dead: Either the NATFW NSLP signaling session is timed out or the 1171 node has received an error RESPONSE message for the NATFW NSLP 1172 signaling session and the NATFW NSLP signaling session can be 1173 deleted. 1175 o Transitory: The node has received an asynchronous message, i.e., a 1176 NOTIFY, and can delete the NATFW NSLP signaling session if needed 1177 after some time. When a node has received a NOTIFY message, it 1178 marks the signaling session as 'transitory'. This signaling 1179 session SHOULD NOT be deleted before a minimum hold time of 30 1180 second, i.e., it can be removed after 30 seconds or more. This 1181 hold time ensures that the existing signaling session can be 1182 reused by the NI, e.g., a part of a signalling session that is not 1183 affected by the route change can be reused once the updating 1184 request message is received. 1186 3.3. Basic Message Processing 1188 All NATFW messages are subject to some basic message processing when 1189 received at a node, independent of the message type. Initially, the 1190 syntax of the NSLP message is checked and a RESPONSE message with an 1191 appropriate error of class 'Protocol error' (0x3) code is generated 1192 if any problem is detected. If a message is delivered to the NATFW 1193 NSLP, this implies that the NTLP layer has been able to correlate it 1194 with the SID and MRI entries in its database. There is therefore 1195 enough information to identify the source of the message and routing 1196 information to route the message back to the NI through an 1197 established chain of NTLP messaging associations. The message is not 1198 further forwarded if any error in the syntax is detected. The 1199 specific response codes stemming from the processing of objects are 1200 described in the respective object definition section (see 1201 Section 4). After passing this check, the NATFW NSLP node performs 1202 authentication/authorization related checks described in Section 3.6. 1203 Further processing is executed only if these tests have been 1204 successfully passed, otherwise the processing stops and an error 1205 RESPONSE is returned. 1207 Further message processing stops whenever an error RESPONSE message 1208 is generated, and the EXTERNAL or CREATE message is discarded. 1210 3.4. Calculation of Signaling Session Lifetime 1212 NATFW NSLP signaling sessions, and the corresponding policy rules 1213 which may have been installed, are maintained via a soft-state 1214 mechanism. Each signaling session is assigned a signaling session 1215 lifetime and the signaling session is kept alive as long as the 1216 lifetime is valid. After the expiration of the signaling session 1217 lifetime, signaling sessions and policy rules MUST be removed 1218 automatically and resources bound to them MUST be freed as well. 1219 Signaling session lifetime is handled at every NATFW NSLP node. The 1220 NSLP forwarders and NSLP responder MUST NOT trigger signaling session 1221 lifetime extension refresh messages (see Section 3.7.3): this is the 1222 task of the NSIS initiator. 1224 The NSIS initiator MUST choose a NATFW NSLP signaling session 1225 lifetime value (expressed in seconds) before sending any message, 1226 including the initial message which creates the NATFW NSLP signaling 1227 session, to other NSLP nodes. The NATFW NSLP signaling session 1228 lifetime value is calculated based on: 1230 o the number of lost refresh messages that NFs should cope with; 1232 o the end-to-end delay between the NI and NR; 1234 o network vulnerability due to NATFW NSLP signaling session 1235 hijacking ([RFC4081]), NATFW NSLP signaling session hijacking is 1236 made easier when the NI does not explicitly remove the NATFW NSLP 1237 signaling session); 1239 o the user application's data exchange duration, in terms of time 1240 and networking needs. This duration is modeled as R, with R the 1241 message refresh period (in seconds); 1243 o the load on the signaling plane. Short lifetimes imply more 1244 frequent signaling messages. 1246 o the acceptable time for a NATFW NSLP signaling session to be 1247 present after it is no longer actually needed. For example, if 1248 the existence of the NATFW NSLP signaling session implies a 1249 monetary cost and teardown cannot be guaranteed, shorter lifetimes 1250 would be preferable; 1252 o the lease time of the NI's IP address. The lease time of the IP 1253 address must be larger than chosen NATFW NSLP signaling session 1254 lifetime, otherwise the IP address can be re-assigned to a 1255 different node. This node may receive unwanted traffic, although 1256 it never has requested a NAT/firewall configuration, which might 1257 be an issue in environments with mobile hosts. 1259 The RSVP specification [RFC2205] provides an appropriate algorithm 1260 for calculating the NATFW NSLP signaling session lifetime as well as 1261 means to avoid refresh message synchronization between NATFW NSLP 1262 signaling sessions. [RFC2205] recommends: 1264 1. The refresh message timer to be randomly set to a value in the 1265 range [0.5R, 1.5R]. 1267 2. To avoid premature loss of state, lt (with lt being the NATFW 1268 NSLP signaling session lifetime) must satisfy lt >= (K + 1269 0.5)*1.5*R, where K is a small integer. Then in the worst case, 1270 K-1 successive messages may be lost without state being deleted. 1271 Currently K = 3 is suggested as the default. However, it may be 1272 necessary to set a larger K value for hops with high loss rate. 1273 Other algorithms could be used to define the relation between the 1274 NATFW NSLP signaling session lifetime and the refresh message 1275 period; the algorithm provided is only given as an example. 1277 This requested NATFW NSLP signaling session lifetime value lt is 1278 stored in the NATFW_LT object of the NSLP message. 1280 NSLP forwarders and the NSLP responder can execute the following 1281 behavior with respect to the requested lifetime handling: 1283 Requested signaling session lifetime acceptable: 1285 No changes to the NATFW NSLP signaling session lifetime values are 1286 needed. The CREATE or EXTERNAL message is forwarded, if 1287 applicable. 1289 Signaling session lifetime can be lowered: 1291 An NSLP forwarded or the NSLP responder MAY also lower the 1292 requested NATFW NSLP signaling session lifetime to an acceptable 1293 value (based on its local policies). If an NF changes the NATFW 1294 NSLP signaling session lifetime value, it MUST store the new value 1295 in the NATFW_LT object. The CREATE or EXTERNAL message is 1296 forwarded. 1298 Requested signaling session lifetime is too big: 1300 An NSLP forwarded or the NSLP responder MAY reject the requested 1301 NATFW NSLP signaling session lifetime value as being too big and 1302 MUST generate an error RESPONSE message of class 'Signaling 1303 session failure' (0x6) with response code 'Requested lifetime is 1304 too big' (0x02) upon rejection. Lowering the lifetime is 1305 preferred instead of generating an error message. 1307 Requested signaling session lifetime is too small: 1309 An NSLP forwarded or the NSLP responder MAY reject the requested 1310 NATFW NSLP signaling session lifetime value as being to small and 1311 MUST generate an error RESPONSE message of class 'Signaling 1312 session failure' (0x6) with response code 'Requested lifetime is 1313 too small' (0x10) upon rejection. 1315 NFs or the NR MUST NOT increase the NATFW NSLP signaling session 1316 lifetime value. Messages can be rejected on the basis of the NATFW 1317 NSLP signaling session lifetime being too long when a NATFW NSLP 1318 signaling session is first created and also on refreshes. 1320 The NSLP responder generates a successful RESPONSE for the received 1321 CREATE or EXTERNAL message, sets the NATFW NSLP signaling session 1322 lifetime value in the NATFW_LT object to the above granted lifetime 1323 and sends the message back towards NSLP initiator. 1325 Each NSLP forwarder processes the RESPONSE message, reads and stores 1326 the granted NATFW NSLP signaling session lifetime value. The 1327 forwarders MUST accept the granted NATFW NSLP signaling session 1328 lifetime, if the lifetime value is within the acceptable range. The 1329 acceptable value refers to the value accepted by the NSLP forwarder 1330 when processing the CREATE or EXTERNAL message. For received values 1331 greater than the acceptable value, NSLP forwarders MUST generate a 1332 RESPONSE message of class 'Signaling session failure' (0x6) with 1333 response code 'Modified lifetime is too big' (0x11). For received 1334 values lower than the values acceptable by the node local policy, 1335 NSLP forwarders MUST generate a RESPONSE message of class 'Signaling 1336 session failure' (0x6) with response code 'Modified lifetime is too 1337 small' (0x12). 1339 Figure 13 shows the procedure with an example, where an initiator 1340 requests 60 seconds lifetime in the CREATE message and the lifetime 1341 is shortened along the path by the forwarder to 20 seconds and by the 1342 responder to 15 seconds. When the NSLP forwarder receives the 1343 RESPONSE message with a NATFW NSLP signaling session lifetime value 1344 of 15 seconds it checks whether this value is lower or equal to the 1345 acceptable value. 1347 +-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+ 1348 | |---------------->| NSLP |---------------->| | 1349 | NI | | forwarder | | NR | 1350 | |<----------------| check 15<20 |<----------------| | 1351 +-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+ 1353 lt = lifetime 1355 Figure 13: Signaling Session Lifetime Setting Example 1357 3.5. Message Sequencing 1359 NATFW NSLP messages need to carry an identifier so that all nodes 1360 along the path can distinguish messages sent at different points in 1361 time. Messages can be lost along the path or duplicated. So all 1362 NATFW NSLP nodes should be able to identify either old messages that 1363 have been received before (duplicated), or the case that messages 1364 have been lost before (loss). For message replay protection it is 1365 necessary to keep information about messages that have already been 1366 received and requires every NATFW NSLP message to carry a message 1367 sequence number (MSN), see also Section 4.2.6. 1369 The MSN MUST be set by the NI and MUST NOT be set or modified by any 1370 other node. The initial value for the MSN MUST be generated randomly 1371 and MUST be unique only within the NATFW NSLP signaling session for 1372 which it is used. The NI MUST increment the MSN by one for every 1373 message sent. Once the MSN has reached the maximum value, the next 1374 value it takes is zero. All NATFW NSLP nodes MUST use the algorithm 1375 defined in [RFC1982] to detect MSN wrap-arounds. 1377 NSIS forwarders and the responder store the MSN from the initial 1378 CREATE or EXTERNAL packet which creates the NATFW NSLP signaling 1379 session as the start value for the NATFW NSLP signaling session. NFs 1380 and NRs MUST include the received MSN value in the corresponding 1381 RESPONSE message that they generate. 1383 When receiving a CREATE or EXTERNAL message, a NATFW NSLP node uses 1384 the MSN given in the message to determine whether the state being 1385 requested is different to the state already installed. The message 1386 MUST be discarded if the received MSN value is equal to or lower than 1387 the stored MSN value. Such a received MSN value can indicate a 1388 duplicated and delayed message or replayed message. If the received 1389 MSN value is greater than the already stored MSN value, the NATFW 1390 NSLP MUST update its stored state accordingly, if permitted by all 1391 security checks (see Section 3.6), and store the updated MSN value 1392 accordingly. 1394 3.6. Authentication, Authorization, and Policy Decisions 1396 NATFW NSLP nodes receiving signaling messages MUST first check 1397 whether this message is authenticated and authorized to perform the 1398 requested action. NATFW NSLP nodes requiring more information than 1399 provided MUST generate an error RESPONSE of class 'Permanent failure' 1400 (0x5) with response code 'Authentication failed' (0x01) or with 1401 response code 'Authorization failed' (0x02). 1403 The NATFW NSLP is expected to run in various environments, such as 1404 IP-based telephone systems, enterprise networks, home networks, etc. 1405 The requirements on authentication and authorization are quite 1406 different between these use cases. While a home gateway, or an 1407 Internet cafe, using NSIS may well be happy with a "NATFW signaling 1408 coming from inside the network" policy for authorization of 1409 signaling, enterprise networks are likely to require more strongly 1410 authenticated/authorized signaling. This enterprise scenario may 1411 require the use of an infrastructure and administratively assigned 1412 identities to operate the NATFW NSLP. 1414 Once the NI is authenticated and authorized, another step is 1415 performed. The requested policy rule for the NATFW NSLP signaling 1416 session is checked against a set of policy rules, i.e., whether the 1417 requesting NI is allowed to request the policy rule to be loaded in 1418 the device. If this fails the NF or NR must send an error RESPONSE 1419 of class 'Permanent failure' (0x5) and with response code 1420 'Authorization failed' (0x02). 1422 3.7. Protocol Operations 1424 This section defines the protocol operations including, how to create 1425 NATFW NSLP signaling sessions, maintain them, delete them, and how to 1426 reserve addresses. 1428 3.7.1. Creating Signaling Sessions 1430 Allowing two hosts to exchange data even in the presence of 1431 middleboxes is realized in the NATFW NSLP by use of the CREATE 1432 message. The NI (either the data sender or a proxy) generates a 1433 CREATE message as defined in Section 4.3.1 and hands it to the NTLP. 1434 The NTLP forwards the whole message on the basis of the message 1435 routing information (MRI) towards the NR. Each NSIS forwarder along 1436 the path that implements NATFW NSLP, processes the NSLP message. 1437 Forwarding is done hop-by-hop but may pass transparently through NSIS 1438 forwarders which do not contain NATFW NSLP functionality and non-NSIS 1439 aware routers between NSLP hop way points. When the message reaches 1440 the NR, the NR can accept the request or reject it. The NR generates 1441 a response to CREATE and this response is transported hop-by-hop 1442 towards the NI. NATFW NSLP forwarders may reject requests at any 1443 time. Figure 14 sketches the message flow between NI (DS in this 1444 example), a NF (e.g., NAT), and NR (DR in this example). 1446 NI Private Network NF Public Internet NR 1447 | | | 1448 | CREATE | | 1449 |----------------------------->| | 1450 | | | 1451 | | | 1452 | | CREATE | 1453 | |--------------------------->| 1454 | | | 1455 | | RESPONSE | 1456 | RESPONSE |<---------------------------| 1457 |<-----------------------------| | 1458 | | | 1459 | | | 1461 Figure 14: CREATE message flow with success RESPONSE 1463 There are several processing rules for a NATFW peer when generating 1464 and receiving CREATE messages, since this message type is used for 1465 creating new NATFW NSLP signaling session, updating existing, 1466 extending the lifetime and deleting NATFW NSLP signaling session. 1467 The three latter functions operate in the same way for all kinds of 1468 CREATE message, and are therefore described in separate sections: 1470 o Extending the lifetime of NATFW NSLP signaling sessions is 1471 described in Section 3.7.3. 1473 o Deleting NATFW NSLP signaling sessions is described in 1474 Section 3.7.4. 1476 o Updating policy rules is described in Section 3.10. 1478 For an initial CREATE message creating a new NATFW NSLP signaling 1479 session, the processing of CREATE messages is different for every 1480 NATFW node type: 1482 o NSLP initiator: An NI only generates CREATE messages and hands 1483 them over to the NTLP. The NI should never receive CREATE 1484 messages and MUST discard it. 1486 o NATFW NSLP forwarder: NFs that are unable to forward the CREATE 1487 message to the next hop MUST generate an error RESPONSE of class 1488 'Permanent failure' (0x6) with response code 'Did not reach the 1489 NR' (0x07). This case may occur if the NTLP layer cannot find an 1490 NATFW NSLP peer, either another NF or the NR, and returns an error 1491 via the GIST API (a timeout error reported by GIST). The NSLP 1492 message processing at the NFs depends on the middlebox type: 1494 * NAT: When the initial CREATE message is received at the public 1495 side of the NAT, it looks for a reservation made in advance, by 1496 using a EXTERNAL message (see Section 3.7.2). The matching 1497 process considers the received MRI information and the stored 1498 MRI information, as described in Section 3.8. If no matching 1499 reservation can be found, i.e., no reservation has been made in 1500 advance, the NSLP MUST return an error RESPONSE of class 1501 'Signaling session failure' (0x6) with response code 'No 1502 reservation found matching the MRI of the CREATE request' 1503 (0x03). If there is a matching reservation, the NSLP stores 1504 the data sender's address (and if applicable port number) as 1505 part of the source address of the policy rule ('the remembered 1506 policy rule') to be loaded and forwards the message with the 1507 destination address set to the internal (private in most cases) 1508 address of NR. When the initial CREATE message is received at 1509 the private side, the NAT binding is allocated, but not 1510 activated (see also Appendix C.3). An error RESPONSE message 1511 is generated, if the requested policy rule cannot be installed 1512 later on, of class 'Signaling session failure' (0x6) with 1513 response code 'Requested policy rule denied due to policy 1514 conflict' (0x4). The MRI information is updated to reflect the 1515 address, and if applicable port, translation. The NSLP message 1516 is forwarded towards the NR with source address set to the 1517 NAT's external address from the newly remembered binding. 1519 * Firewall: When the initial CREATE message is received, the NSLP 1520 just remembers the requested policy rule, but does not install 1521 any policy rule. Afterwards, the message is forwarded towards 1522 the NR. An error RESPONSE message is generated, if the 1523 requested policy rule cannot be installed later on, with of 1524 class 'Signaling session failure' (0x6) with response code 1525 'Requested policy rule denied due to policy conflict' (0x4). 1527 * Combined NAT and firewall: Processing at combined firewall and 1528 NAT middleboxes is the same as in the NAT case. No policy 1529 rules are installed. Implementations MUST take into account 1530 the order of packet processing in the firewall and NAT 1531 functions within the device. This will be referred to as 1532 'order of functions' and is generally different depending on 1533 whether the packet arrives at the external or internal side of 1534 the middlebox. 1536 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1537 with a success RESPONSE of class 'Success' (0x2) with response 1538 code set to 'All successfully processed' (0x01), if they accept 1539 the CREATE message. Otherwise they MUST generate a RESPONSE 1540 message with a suitable response code. RESPONSE messages are sent 1541 back NSLP hop-by-hop towards the NI, irrespective of the response 1542 codes, either success or error. 1544 Remembered policy rules at middleboxes MUST be only installed upon 1545 receiving a corresponding successful RESPONSE message with the same 1546 SID as the CREATE message that caused them to be remembered. This is 1547 a countermeasure to several problems, for example, wastage of 1548 resources due to loading policy rules at intermediate NFs when the 1549 CREATE message does not reach the final NR for some reason. 1551 Processing of a RESPONSE message is different for every NSIS node 1552 type: 1554 o NSLP initiator: After receiving a successful RESPONSE, the data 1555 path is configured and the DS can start sending its data to the 1556 DR. After receiving an error RESPONSE message, the NI MAY try to 1557 generate the CREATE message again or give up and report the 1558 failure to the application, depending on the error condition. 1560 o NSLP forwarder: NFs install the remembered policy rules, if a 1561 successful RESPONSE message with matching SID is received. If an 1562 ERROR RESPONSE message with matching SID is received, the NATFW 1563 NSLP session is marked as dead, no policy rule is installed and 1564 the remembered rule is discarded. 1566 o NSIS responder: The NR should never receive RESPONSE messages and 1567 MUST silently drop any such messages received. 1569 NFs and the NR can also tear down the CREATE session at any time by 1570 generating a NOTIFY message with the appropriate response code set. 1572 3.7.2. Reserving External Addresses 1574 NSIS signaling is intended to travel end-to-end, even in the presence 1575 of NATs and firewalls on-path. This works well in cases where the 1576 data sender is itself behind a NAT or a firewall as described in 1577 Section 3.7.1. For scenarios where the data receiver is located 1578 behind a NAT or a firewall and it needs to receive data flows from 1579 outside its own network (usually referred to as inbound flows, see 1580 Figure 5) the problem is more troublesome. 1582 NSIS signaling, as well as subsequent data flows, are directed to a 1583 particular destination IP address that must be known in advance and 1584 reachable. Data receivers must tell the local NSIS infrastructure 1585 (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP 1586 signaling and data flows before they can receive these flows. It is 1587 necessary to differentiate between data receivers behind NATs and 1588 behind firewalls for understanding the further NATFW procedures. 1589 Data receivers that are only behind firewalls already have a public 1590 IP address and they need only to be reachable for NATFW signaling. 1591 Unlike data receivers behind just firewalls, data receivers behind 1592 NATs do not have public IP addresses; consequently they are not 1593 reachable for NATFW signaling by entities outside their addressing 1594 realm. 1596 The preceding discussion addresses the situation where a DR node that 1597 wants to be reachable is unreachable because the NAT lacks a suitable 1598 rule with the 'allow' action which would forward inbound data. 1599 However, in certain scenarios, a node situated behind inbound 1600 firewalls that do not block inbound data traffic (firewalls with 1601 "default to allow") unless requested might wish to prevent traffic 1602 being sent to it from specified addresses. In this case, NSIS NATFW 1603 signaling can be used to achieve this by installing a policy rule 1604 with its action set to 'deny' using the same mechanisms as for 1605 'allow' rules. 1607 The required result is obtained by sending a EXTERNAL message in the 1608 inbound direction of the intended data flow. When using this 1609 functionality the NSIS initiator for the 'Reserve External Address' 1610 signaling is typically the node that will become the DR for the 1611 eventual data flow. To distinguish this initiator from the usual 1612 case where the NI is associated with the DS, the NI is denoted by NI+ 1613 and the NSIS responder is similarly denoted by NR+. 1615 Public Internet Private Address 1616 Space 1618 Edge 1619 NI(DS) NAT/FW NAT NR(DR) 1620 NR+ NI+ 1622 | | | | 1623 | | | | 1624 | | | | 1625 | | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] | 1626 | |<----------------------|<----------------------| 1627 | | | | 1628 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1629 | |---------------------->|---------------------->| 1630 | | | | 1631 | | | | 1633 ============================================================> 1634 Data Traffic Direction 1636 Figure 15: Reservation message flow for DR behind NAT or firewall 1638 Figure 15 shows the EXTERNAL message flow for enabling inbound NATFW 1639 NSLP signaling messages. In this case the roles of the different 1640 NSIS entities are: 1642 o The data receiver (DR) for the anticipated data traffic is the 1643 NSIS initiator (NI+) for the EXTERNAL message, but becomes the 1644 NSIS responder (NR) for following CREATE messages. 1646 o The actual data sender (DS) will be the NSIS initiator (NI) for 1647 later CREATE messages and may be the NSIS target of the signaling 1648 (NR+). 1650 o It may be necessary to use a signaling destination address (SDA) 1651 as the actual target of the EXTERNAL message (NR+) if the DR is 1652 located behind a NAT and the address of the DS is unknown. The 1653 SDA is an arbitrary address in the outermost address realm on the 1654 other side of the NAT from the DR. Typically this will be a 1655 suitable public IP address when the 'outside' realm is the public 1656 Internet. This choice of address causes the EXTERNAL message to 1657 be routed through the NATs towards the outermost realm and would 1658 force interception of the message by the outermost NAT in the 1659 network at the boundary between the private address and the public 1660 address realm (the edge-NAT). It may also be intercepted by other 1661 NATs and firewalls on the path to the edge-NAT. 1663 Basically, there are two different signaling scenarios. Either 1665 1. the DR behind the NAT/firewall knows the IP address of the DS in 1666 advance, 1668 2. or the address of DS is not known in advance. 1670 Case 1 requires the NATFW NSLP to request the path-coupled message 1671 routing method (PC-MRM) from the NTLP. The EXTERNAL message MUST be 1672 sent with PC-MRM (see Section 5.8.1 in [I-D.ietf-nsis-ntlp]) with the 1673 direction set to 'upstream' (inbound). The handling of case 2 1674 depends on the situation of DR: If DR is solely located behind a 1675 firewall, the EXTERNAL message MUST be sent with the PC-MRM, 1676 direction 'upstream' (inbound), and data flow source IP address set 1677 to wildcard. If DR is located behind a NAT, the EXTERNAL message 1678 MUST be sent with the loose-end message routing method (LE-MRM, see 1679 Section 5.8.2 in [I-D.ietf-nsis-ntlp]), the destination-address set 1680 to the signaling destination address (SDA, see also Appendix A). For 1681 scenarios with DR being behind a firewall, special conditions apply 1682 (see applicability statement in Appendix B). The data receiver is 1683 challenged to determine whether it is solely located behind firewalls 1684 or NATs, for choosing the right message routing method. This 1685 decision can depend on a local configuration parameter, possibly 1686 given through DHCP, or it could be discovered through other non-NSLP 1687 related testing of the network configuration. It is RECOMMENDED to 1688 use the PC-MRM with the known data sender's IP address. This gives 1689 GIST the best possible handled to route the message 'upstream' 1690 (outbound). It is RECOMMENDED to use the LE-MRM, if and only if the 1691 data sender's IP address is not known and the data receiver is behind 1692 a NAT. 1694 For case 2 with NAT, the NI+ (which could be on the data receiver DR 1695 or on any other host within the private network) sends the EXTERNAL 1696 message targeted to the signaling destination address. The message 1697 routing for the EXTERNAL message is in the reverse direction to the 1698 normal message routing used for path-coupled signaling where the 1699 signaling is sent outbound (as opposed to inbound in this case). 1700 When establishing NAT bindings (and an NATFW NSLP signaling session) 1701 the signaling direction does not matter since the data path is 1702 modified through route pinning due to the external IP address at the 1703 NAT. Subsequent NSIS messages (and also data traffic) will travel 1704 through the same NAT boxes. However, this is only valid for the NAT 1705 boxes, but not for any intermediate firewall. That is the reason for 1706 having a separate CREATE message enabling the reservations made with 1707 EXTERNAL at the NATs and either enabling prior reservations or 1708 creating new pinholes at the firewalls which are encountered on the 1709 outbound path depending on whether the inbound and outbound routes 1710 coincide. 1712 The EXTERNAL signaling message creates an NSIS NATFW signaling 1713 session at any intermediate NSIS NATFW peer(s) encountered, 1714 independent of the message routing method used. Furthermore, it has 1715 to be ensured that the edge-NAT or edge-firewall device is discovered 1716 as part of this process. The end host cannot be assumed to know this 1717 device - instead the NAT or firewall box itself is assumed to know 1718 that it is located at the outer perimeter of the network. Forwarding 1719 of the EXTERNAL message beyond this entity is not necessary, and MUST 1720 be prohibited as it may provide information on the capabilities of 1721 internal hosts. It should be noted, that it is the outermost NAT or 1722 firewall that is the edge-device that must be found during this 1723 discovery process. For instance, when there are a NAT and afterwards 1724 a firewall on the outbound path at the network border, the firewall 1725 is the edge-firewall. All messages must be forwarded to the 1726 topology-wise outermost edge-device, to ensure that this device knows 1727 about the NATFW NSLP signaling sessions for incoming CREATE messages. 1728 However, the NAT is still the edge-NAT because it has a public 1729 globally routable IP address on its public side: this is not affected 1730 by any firewall between the edge-NAT and the public network. 1732 Possible edge arrangements are: 1734 Public Net ----------------- Private net -------------- 1736 | Public Net|--|Edge-FW|--|FW|...|FW|--|DR| 1738 | Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR| 1740 | Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR| 1742 The edge-NAT or edge-firewall device closest to the public realm 1743 responds to the EXTERNAL message with a successful RESPONSE message. 1744 An edge-NAT includes an NATFW_EXTERNAL-IP object (see Section 4.2.2), 1745 carrying the public reachable IP address, and if applicable port 1746 number. 1748 There are several processing rules for a NATFW peer when generating 1749 and receiving EXTERNAL messages, since this message type is used for 1750 creating new reserve NATFW NSLP signaling sessions, updating 1751 existing, extending the lifetime and deleting NATFW NSLP signaling 1752 session. The three latter functions operate in the same way for all 1753 kinds of CREATE and EXTERNAL messages, and are therefore described in 1754 separate sections: 1756 o Extending the lifetime of NATFW NSLP signaling sessions is 1757 described in Section 3.7.3. 1759 o Deleting NATFW NSLP signaling sessions is described in 1760 Section 3.7.4. 1762 o Updating policy rules is described in Section 3.10. 1764 The NI+ MUST always include a NATFW_DTINFO object in the EXTERNAL 1765 message. Especially, the LE-MRM does not include enough information 1766 for some types of NATs (basically, those NATs which also translate 1767 port numbers) to perform the address translation. This information 1768 is provided in the NATFW_DTINFO (see Section 4.2.7). This 1769 information MUST include at least the 'dst port number' and 1770 'protocol' fields, in the NATFW_DTINFO object as these may be 1771 required by en-route NATs, depending on the type of the NAT. All 1772 other fields MAY be set by the NI+ to restrict the set of possible 1773 NIs. An edge-NAT will use the information provided in the 1774 NATFW_DTINFO object to allow only NATFW CREATE message with the MRI 1775 matching ('src IPv4/v6 address', 'src port number', 'protocol') to be 1776 forwarded. A NAT requiring information carried in the NATFW_DTINFO 1777 can generate a number of error RESPONSE messages of class 'Signaling 1778 session failure' (0x6): 1780 o 'Requested policy rule denied due to policy conflict' (0x04) 1782 o 'NATFW_DTINFO object is required' (0x07) 1784 o 'Requested value in sub_ports field in NATFW_EFI not permitted' 1785 (0x08) 1787 o 'Requested IP protocol not supported' (0x09) 1789 o 'Plain IP policy rules not permitted -- need transport layer 1790 information' (0x0A) 1792 o 'source IP address range is too large' (0x0C) 1794 o 'destination IP address range is too large' (0x0D) 1796 o 'source L4-port range is too large' (0x0E) 1798 o 'destination L4-port range is too large' (0x0F) 1800 Processing of EXTERNAL messages is specific to the NSIS node type: 1802 o NSLP initiator: NI+ only generate EXTERNAL messages. When the 1803 data sender's address information is known in advance the NI+ can 1804 include a NATFW_DTINFO object in the EXTERNAL message, if not 1805 anyway required to do so (see above). When the data sender's IP 1806 address is not known, the NI+ MUST NOT include an IP address in 1807 the NATFW_DTINFO object. The NI should never receive EXTERNAL 1808 messages and MUST silently discard it. 1810 o NSLP forwarder: The NSLP message processing at NFs depends on the 1811 middlebox type: 1813 * NAT: NATs check whether the message is received at the external 1814 (public in most cases) address or at the internal (private) 1815 address. If received at the external an NF MUST generate an 1816 error RESPONSE of class 'Protocol error' (0x3) with response 1817 code 'Received EXTERNAL request message on external side' 1818 (0x0B). If received at the internal (private address) and the 1819 NATFW_EFI object contains the action 'deny', an error RESPONSE 1820 of class 'Protocol error' (0x3) with response code 'Requested 1821 rule action not applicable' (0x06) MUST be generated. If 1822 received at the internal address, an IP address, and if 1823 applicable one or more ports, are reserved. If it is an edge- 1824 NAT and there is no edge-firewall beyond, the NSLP message is 1825 not forwarded any further and a successful RESPONSE message is 1826 generated containing an NATFW_EXTERNAL-IP object holding the 1827 translated address, and if applicable, port information from 1828 the binding reserved as a result of the EXTERNAL message. The 1829 RESPONSE message is sent back towards the NI+. If it is not an 1830 edge-NAT, the NSLP message is forwarded further using the 1831 translated IP address as signaling source address in the LE-MRM 1832 and translated port in the NATFW_DTINFO object in the field 'DR 1833 port number', i.e., the NATFW_DTINFO object is updated to 1834 reflect the translated port number. The edge-NAT or any other 1835 NAT MUST reject EXTERNAL messages not carrying a NATFW_DTINFO 1836 object or if the address information within this object is 1837 invalid or is not compliant with local policies (e.g., the 1838 information provided relates to a range of addresses 1839 ('wildcarded') but the edge-NAT requires exact information 1840 about DS' IP address and port) with the above mentioned 1841 response codes. 1843 * Firewall: Non edge-firewalls remember the requested policy 1844 rule, keep NATFW NSLP signaling session state, and forward the 1845 message. Edge-firewalls stop forwarding the EXTERNAL message. 1846 The policy rule is immediately loaded if the action in the 1847 NATFW_EFI object is set to 'deny' and the node is an edge- 1848 firewall. The policy rule is remembered, but not activated, if 1849 the action in the NATFW_EFI object is set to 'allow'. In both 1850 cases, a successful RESPONSE message is generated. If the 1851 action is 'allow', and the NATFW_DTINFO object is included, and 1852 the MRM is set to LE-MRM in the request, additionally an 1853 NATFW_EXTERNAL-IP object is included in the RESPONSE message, 1854 holding the translated address, and if applicable port, 1855 information. This information is obtained from the 1856 NATFW_DTINFO object's 'DR port number' and the source-address 1857 of the LE-MRM. 1859 * Combined NAT and firewall: Processing at combined firewall and 1860 NAT middleboxes is the same as in the NAT case. 1862 o NSLP receiver: This type of message should never be received by 1863 any NR+ and it MUST generate an error RESPONSE message of class 1864 'Permanent failure' (0x5) with response code 'No edge-device here' 1865 (0x06). 1867 Processing of a RESPONSE message is different for every NSIS node 1868 type: 1870 o NSLP initiator: Upon receiving a successful RESPONSE message, the 1871 NI+ can rely on the requested configuration for future inbound 1872 NATFW NSLP signaling sessions. If the response contains an 1873 NATFW_EXTERNAL-IP object, the NI can use IP address and port pairs 1874 carried for further application signaling. After receiving a 1875 error RESPONSE message, the NI+ MAY try to generate the EXTERNAL 1876 message again or give up and report the failure to the 1877 application, depending on the error condition. 1879 o NSLP forwarder: NFs simply forward this message as long as they 1880 keep state for the requested reservation, if the RESPONSE message 1881 contains NATFW_INFO object with class set to 'Success' (0x2). If 1882 the RESPONSE message contains NATFW_INFO object with class set not 1883 to 'Success' (0x2), the NATFW NSLP signaling session is marked as 1884 dead. 1886 o NSIS responder: This type of message should never be received by 1887 any NR+. The NF should never receive response messages and MUST 1888 silently discard it. 1890 NFs and the NR can also tear down the EXTERNAL session at any time by 1891 generating a NOTIFY message with the appropriate response code set. 1893 Reservations with action 'allow' made with EXTERNAL MUST be enabled 1894 by a subsequent CREATE message. A reservation made with EXTERNAL 1895 (independent of selected action) is kept alive as long as the NI+ 1896 refreshes the particular NATFW NSLP signaling session and it can be 1897 reused for multiple, different CREATE messages. An NI+ may decide to 1898 teardown a reservation immediately after receiving a CREATE message. 1899 This implies that a new NATFW NSLP signaling session must be created 1900 for each new CREATE message. The CREATE message does not re-use the 1901 NATFW NSLP signaling session created by EXTERNAL. 1903 Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode 1904 (see Section 3.7.6) no data traffic will be forwarded to DR beyond 1905 the edge-NAT or edge-firewall. The only function of EXTERNAL is to 1906 ensure that subsequent CREATE messages traveling towards the NR will 1907 be forwarded across the public-private boundary towards the DR. 1908 Correlation of incoming CREATE messages to EXTERNAL reservation 1909 states is described in Section 3.8. 1911 3.7.3. NATFW NSLP Signaling Session Refresh 1913 NATFW NSLP signaling sessions are maintained on a soft-state basis. 1914 After a specified timeout, sessions and corresponding policy rules 1915 are removed automatically by the middlebox, if they are not 1916 refreshed. Soft-state is created by CREATE and EXTERNAL and the 1917 maintenance of this state must be done by these messages. State 1918 created by CREATE must be maintained by CREATE, state created by 1919 EXTERNAL must be maintained by EXTERNAL. Refresh messages, are 1920 messages carrying the same session ID as the initial message and a 1921 NATFW_LT lifetime object with a lifetime greater than zero. Messages 1922 with the same SID but carrying a different MRI are treated as updates 1923 of the policy rules and are processed as defined in Section 3.10. 1925 Every refresh CREATE or EXTERNAL message MUST be acknowledged by an 1926 appropriate response message generated by the NR. Upon reception by 1927 each NSIS forwarder, the state for the given session ID is extended 1928 by the NATFW NSLP signaling session refresh period, a period of time 1929 calculated based on a proposed refresh message period. The new 1930 (extended) lifetime of a NATFW NSLP signaling session is calculated 1931 as current local time plus proposed lifetime value (NATFW NSLP 1932 signaling session refresh period). Section 3.4 defines the process 1933 of calculating lifetimes in detail. 1935 NI Public Internet NAT Private address NR 1937 | | space | 1938 | CREATE[lifetime > 0] | | 1940 |----------------------------->| | 1941 | | | 1942 | | | 1943 | | CREATE[lifetime > 0] | 1944 | |--------------------------->| 1945 | | | 1946 | | RESPONSE[Success/Error] | 1947 | RESPONSE[Success/Error] |<---------------------------| 1948 |<-----------------------------| | 1949 | | | 1950 | | | 1952 Figure 16: Successful Refresh Message Flow, CREATE as example 1954 Processing of NATFW NSLP signaling session refresh CREATE and 1955 EXTERNAL messages is different for every NSIS node type: 1957 o NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling 1958 session refresh CREATE/EXTERNAL messages before the NATFW NSLP 1959 signaling session times out. The rate at which the refresh 1960 CREATE/EXTERNAL messages are sent and their relation to the NATFW 1961 NSLP signaling session state lifetime is discussed further in 1962 Section 3.4. 1964 o NSLP forwarder: Processing of this message is independent of the 1965 middlebox type and is as described in Section 3.4. 1967 o NSLP responder: NRs accepting a NATFW NSLP signaling session 1968 refresh CREATE/EXTERNAL message generate a successful RESPONSE 1969 message, including the granted lifetime value of Section 3.4 in a 1970 NATFW_LT object. 1972 3.7.4. Deleting Signaling Sessions 1974 NATFW NSLP signaling sessions can be deleted at any time. NSLP 1975 initiators can trigger this deletion by using a CREATE or EXTERNAL 1976 messages with a lifetime value set to 0, as shown in Figure 17. 1977 Whether a CREATE or EXTERNAL message type is used, depends on how the 1978 NATFW NSLP signaling session was created. 1980 NI Public Internet NAT Private address NR 1982 | | space | 1983 | CREATE[lifetime=0] | | 1984 |----------------------------->| | 1985 | | | 1986 | | CREATE[lifetime=0] | 1987 | |--------------------------->| 1988 | | | 1990 Figure 17: Delete message flow, CREATE as example 1992 NSLP nodes receiving this message delete the NATFW NSLP signaling 1993 session immediately. Policy rules associated with this particular 1994 NATFW NSLP signaling session MUST be also deleted immediately. This 1995 message is forwarded until it reaches the final NR. The CREATE/ 1996 EXTERNAL message with a lifetime value of 0, does not generate any 1997 response, neither positive nor negative, since there is no NSIS state 1998 left at the nodes along the path. 2000 NSIS initiators can use CREATE/EXTERNAL message with lifetime set to 2001 zero in an aggregated way, such that a single CREATE or EXTERNAL 2002 message is terminating multiple NATFW NSLP signaling sessions. NIs 2003 can follow this procedure if they like to aggregate NATFW NSLP 2004 signaling session deletion requests: The NI uses the CREATE or 2005 EXTERNAL message with the session ID set to zero and the MRI's 2006 source-address set to its used IP address. All other fields of the 2007 respective NATFW NSLP signaling sessions to be terminated are set as 2008 well, otherwise these fields are completely wildcarded. The NSLP 2009 message is transferred to the NTLP requesting 'explicit routing' as 2010 described in Sections 5.2.1 and 7.1.4. in [I-D.ietf-nsis-ntlp]. 2012 The outbound NF receiving such an aggregated CREATE or EXTERNAL 2013 message MUST reject it with an error RESPONSE of class 'Permanent 2014 failure' (0x5) with response code 'Authentication failed' (0x01) if 2015 the authentication fails and with an error RESPONSE of class 2016 'Permanent failure' (0x5) with response code 'Authorization failed' 2017 (0x02) if the authorization fails. Per NATFW NSLP signaling session 2018 proof of ownership, as it is defined in this memo, is not possible 2019 anymore when using this aggregated way. However, the outbound NF can 2020 use the relationship between the information of the received CREATE 2021 or EXTERNAL message and the GIST messaging association where the 2022 request has been received. The outbound NF MUST only accept this 2023 aggregated CREATE or EXTERNAL message through already established 2024 GIST messaging associations with the NI. The outbound NF MUST NOT 2025 propagate this aggregated CREATE or EXTERNAL message but it MAY 2026 generate and forward per NATFW NSLP signaling session CREATE or 2027 EXTERNAL messages. 2029 3.7.5. Reporting Asynchronous Events 2031 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 2032 to report asynchronous events to other NATFW NSLP nodes, especially 2033 to allow reporting back to the NATFW NSLP initiator. Such 2034 asynchronous events may be premature NATFW NSLP signaling session 2035 termination, changes in local policies, route change or any other 2036 reason that indicates change of the NATFW NSLP signaling session 2037 state. 2039 NFs and NRs may generate NOTIFY messages upon asynchronous events, 2040 with a NATFW_INFO object indicating the reason for event. These 2041 reasons can be carried in the NATFW_INFO object (class MUST be set to 2042 'Informational' (0x1)) within the NOTIFY message. This list shows 2043 the response codes and the associated actions to take at NFs and the 2044 NI: 2046 o 'Route change: possible route change on the outbound path' (0x01): 2047 Follow instructions in Section 3.9. This MUST be sent inbound and 2048 outbound, if the signalling session is any state expect 2049 'Transitory'. The NOTIFY message for signalling sessions in state 2050 transitory MUST be discarded, as the signalling session is anyhow 2051 transitory. The outbound NOTIFY message MUST be sent with 2052 explicit routing by providing the SII-Handle to the NTLP. 2054 o 'Re-authentication required' (0x02): The NI should re-send the 2055 authentication. This MUST be sent inbound. 2057 o 'NATFW node is going down soon' (0x03): The NI and other NFs 2058 should be prepared for a service interruption at any time. This 2059 message MAY be sent inbound and outbound. 2061 o 'NATFW signaling session lifetime expired' (0x04): The NATFW 2062 signaling session has been expired and the signaling session is 2063 invalid now. NFs MUST mark the signaling session as 'Dead'. This 2064 message MAY be sent inbound and outbound. 2066 o 'NATFW signaling session terminated' (0x05): The NATFW signaling 2067 session has been terminated by any reason and the signaling 2068 session is invalid now. NFs MUST mark the signaling session as 2069 'Dead'. This message MAY be sent inbound and outbound. 2071 NOTIFY messages are always sent hop-by-hop inbound towards NI until 2072 they reach NI or outbound towards the NR as indicated in the list 2073 above. 2075 The initial processing when receiving a NOTIFY message is the same 2076 for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages 2077 through already established NTLP messaging associations. The further 2078 processing is different for each NATFW NSLP node type and depends on 2079 the events notified: 2081 o NSLP initiator: NIs analyze the notified event and behave 2082 appropriately based on the event type. NIs MUST NOT generate 2083 NOTIFY messages. 2085 o NSLP forwarder: NFs analyze the notified event and behave based on 2086 the above description per response code. NFs SHOULD generate 2087 NOTIFY messages upon asynchronous events and forward them inbound 2088 towards the NI or outbound towards the NR, depending on the 2089 received direction, i.e., inbound messages MUST be forwarded 2090 further inbound and outbound messages MUST be forwarded further 2091 outbound. NFs MUST silently discard NOTIFY messages that have 2092 been received outbound but are only allowed to be sent inbound, 2093 e.g. 'Re-authentication required' (0x02). 2095 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 2096 asynchronous events including a response code based on the 2097 reported event. The NR MUST silently discard NOTIFY messages that 2098 have been received outbound but are only allowed to be sent 2099 inbound, e.g. 'Re-authentication required' (0x02), 2101 NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions 2102 at the same time, can experience problems when shutting down service 2103 suddenly. This sudden shutdown can be result of node local failure, 2104 for instance, due to a hardware failure. This NF generates NOTIFY 2105 messages for each of the NATFW NSLP signaling sessions and tries to 2106 send them inbound. Due to the number of NOTIFY messages to be sent, 2107 the shutdown of the node may be unnecessarily prolonged, since not 2108 all messages can be sent at the same time. This case can be 2109 described as a NOTIFY storm, if a multitude of NATFW NSLP signaling 2110 sessions is involved. 2112 To avoid the need of generating per NATFW NSLP signaling session 2113 NOTIFY messages in such a scenario described or similar cases, NFs 2114 SHOULD follow this procedure: The NF uses the NOTIFY message with the 2115 session ID in the NTLP set to zero, with the MRI completely 2116 wildcarded, using the 'explicit routing' as described in Sections 2117 5.2.1 and 7.1.4. in [I-D.ietf-nsis-ntlp]. The inbound NF receiving 2118 this type of NOTIFY immediately regards all NATFW NSLP signaling 2119 sessions from that peer matching the MRI as void. This message will 2120 typically result in multiple NOTIFY messages at the inbound NF, i.e., 2121 the NF can generate per terminated NATFW NSLP signaling session a 2122 NOTIFY message. However, a NF MAY aggregate again the NOTIFY 2123 messages as described here. 2125 3.7.6. Proxy Mode of Operation 2127 Some migration scenarios need specialized support to cope with cases 2128 where NSIS is only deployed in same areas of the Internet. End-to- 2129 end signaling is going to fail without NSIS support at or near both 2130 data sender and data receiver terminals. A proxy mode of operation 2131 is needed. This proxy mode of operation must terminate the NATFW 2132 NSLP signaling topologically-wise as close as possible to the 2133 terminal for which it is proxying and proxy all messages. This NATFW 2134 NSLP node doing the proxying of the signaling messages becomes either 2135 the NI or the NR for the particular NATFW NSLP signaling session, 2136 depending on whether it is the DS or DR that does not support NSIS. 2137 Typically, the edge-NAT or the edge-firewall would be used to proxy 2138 NATFW NSLP messages. 2140 This proxy mode operation does not require any new CREATE or EXTERNAL 2141 message type, but relies on extended CREATE and EXTERNAL message 2142 types. They are called respectively CREATE-PROXY and EXTERNAL-PROXY 2143 and are distinguished by setting the P flag in the NSLP header to 2144 P=1. This flag instructs edge-NATs and edge-firewalls receiving them 2145 to operate in proxy mode for the NATFW NSLP signaling session in 2146 question. The semantics of the CREATE and EXTERNAL message types are 2147 not changed and the behavior of the various node types is as defined 2148 in Section 3.7.1 and Section 3.7.2, except for the proxying node. 2149 The following paragraphs describe the proxy mode operation for data 2150 receivers behind middleboxes and data senders behind middleboxes. 2152 3.7.6.1. Proxying for a Data Sender 2154 The NATFW NSLP gives the NR the ability to install state on the 2155 inbound path towards the data sender for outbound data packets, even 2156 when only the receiving side is running NSIS (as shown in Figure 18). 2157 The goal of the method described is to trigger the edge-NAT/ 2158 edge-firewall to generate a CREATE message on behalf of the data 2159 receiver. In this case, an NR can signal towards the network border 2160 as it is performed in the standard EXTERNAL message handling scenario 2161 as in Section 3.7.2. The message is forwarded until the edge-NAT/ 2162 edge-firewall is reached. A public IP address and port number is 2163 reserved at an edge-NAT/edge-firewall. As shown in Figure 18, unlike 2164 the standard EXTERNAL message handling case, the edge-NAT/ 2165 edge-firewall is triggered to send a CREATE message on a new reverse 2166 path which traverse several firewalls or NATs. The new reverse path 2167 for CREATE is necessary to handle routing asymmetries between the 2168 edge-NAT/edge-firewall and DR. It must be stressed that the 2169 semantics of the CREATE and EXTERNAL messages is not changed, i.e., 2170 each is processed as described earlier. 2172 DS Public Internet NAT/FW Private address DR 2173 No NI NF space NR 2174 NR+ NI+ 2176 | | EXTERNAL-PROXY[(DTInfo)] | 2177 | |<------------------------- | 2178 | | RESPONSE[Error/Success] | 2179 | | ---------------------- > | 2180 | | CREATE | 2181 | | ------------------------> | 2182 | | RESPONSE[Error/Success] | 2183 | | <---------------------- | 2184 | | | 2186 Figure 18: EXTERNAL Triggering Sending of CREATE Message 2188 A NATFW_NONCE object, carried in the EXTERNAL and CREATE message, is 2189 used to build the relationship between received CREATEs at the 2190 message initiator. An NI+ uses the presence of the NATFW_NONCE 2191 object to correlate it to the particular EXTERNAL-PROXY. The absence 2192 of a NONCE object indicates a CREATE initiated by the DS and not by 2193 the edge-NAT. The two signaling sessions, i.e., the session for 2194 EXTERNAL-PROXY and the session for CREATE, are not independent. The 2195 primary session is the EXTERNAL-PROXY session. The CREATE session is 2196 secondary to the EXTERNAL-PROXY session, i.e., the CREATE session is 2197 valid as long as the EXTERNAL-PROXY session is the signaling states 2198 'Established' or 'Transitory'. There is no CREATE session in any 2199 other signaling state of the EXTERNAL-PROXY, i.e., 'pending' or 2200 'dead'. This ensures a faith-sharing between both signaling 2201 sessions. 2203 These processing rules of EXTERNAL-PROXY messages are added to the 2204 regular EXTERNAL processing: 2206 o NSLP initiator (NI+): The NI+ MUST take the session ID (SID) value 2207 of the EXTERNAL-PROXY session as the nonce value of the 2208 NATFW_NONCE object. 2210 o NSLP forwarder being either edge-NAT or edge-firewall: When the NF 2211 accepts a EXTERNAL-PROXY message, it generates a successful 2212 RESPONSE message as if it were the NR and additionally, it 2213 generates a CREATE message as defined in Section 3.7.1 and 2214 includes a NATFW_NONCE object having the same value as of the 2215 received NATFW_NONCE object. The NF MUST NOT generate a CREATE- 2216 PROXY message. The NF MUST refresh the CREATE message signaling 2217 session only if a EXTERNAL-PROXY refresh message has been received 2218 first. This also includes tearing down signaling sessions, i.e., 2219 the NF must teardown the CREATE signaling session only if a 2220 EXTERNAL-PROXY message with lifetime set to 0 has been received 2221 first. 2223 The scenario described in this section challenges the data receiver 2224 because it must make a correct assumption about the data sender's 2225 ability to use NSIS NATFW NSLP signaling. It is possible for the DR 2226 to make the wrong assumption in two different ways: 2228 a) the DS is NSIS unaware but the DR assumes the DS to be NSIS 2229 aware and 2231 b) the DS is NSIS aware but the DR assumes the DS to be NSIS 2232 unaware. 2234 Case a) will result in middleboxes blocking the data traffic, since 2235 DS will never send the expected CREATE message. Case b) will result 2236 in the DR successfully requesting proxy mode support by the edge-NAT 2237 or edge-firewall. The edge-NAT/edge-firewall will send CREATE 2238 messages and DS will send CREATE messages as well. Both CREATE 2239 messages are handled as separated NATFW NSLP signaling sessions and 2240 therefore the common rules per NATFW NSLP signaling session apply; 2241 the NATFW_NONCE object is used to differentiate CREATE messages 2242 generated by the edge-NAT/edge-firewall from NI initiated CREATE 2243 messages. It is the NR's responsibility to decide whether to 2244 teardown the EXTERNAL-PROXY signaling sessions in the case where the 2245 data sender's side is NSIS aware, but was incorrectly assumed not to 2246 be so by the DR. It is RECOMMENDED that a DR behind NATs uses the 2247 proxy mode of operation by default, unless the DR knows that the DS 2248 is NSIS aware. The DR MAY cache information about data senders which 2249 it has found to be NSIS aware in past NATFW NSLP signaling sessions. 2251 There is a possible race condition between the RESPONSE message to 2252 the EXTERNAL-PROXY and the CREATE message generated by the edge-NAT. 2253 The CREATE message can arrive earlier than the RESPONSE message. An 2254 NI+ MUST accept CREATE messages generated by the edge-NAT even if the 2255 RESPONSE message to the EXTERNAL-PROXY was not received. 2257 3.7.6.2. Proxying for a Data Receiver 2259 As with data receivers behind middleboxes, data senders behind 2260 middleboxes can require proxy mode support. The issue here is that 2261 there is no NSIS support at the data receiver's side and, by default, 2262 there will be no response to CREATE messages. This scenario requires 2263 the last NSIS NATFW NSLP aware node to terminate the forwarding and 2264 to proxy the response to the CREATE message, meaning that this node 2265 is generating RESPONSE messages. This last node may be an edge-NAT/ 2266 edge-firewall, or any other NATFW NSLP peer, that detects that there 2267 is no NR available (probably as a result of GIST timeouts but there 2268 may be other triggers). 2270 DS Private Address NAT/FW Public Internet NR 2271 NI Space NF no NR 2273 | | | 2274 | CREATE-PROXY | | 2275 |------------------------------>| | 2276 | | | 2277 | RESPONSE[SUCCESS/ERROR] | | 2278 |<------------------------------| | 2279 | | | 2281 Figure 19: Proxy Mode CREATE Message Flow 2283 The processing of CREATE-PROXY messages and RESPONSE messages is 2284 similar to Section 3.7.1, except that forwarding is stopped at the 2285 edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to 2286 NI according to the situation (error/success) and will be the NR for 2287 future NATFW NSLP communication. 2289 The NI can choose the proxy mode of operation although the DR is NSIS 2290 aware. The CREATE-PROXY mode would not configure all NATs and 2291 firewalls along the data path, since it is terminated at the edge- 2292 device. Any device beyond this point will never receive any NATFW 2293 NSLP signaling for this flow. 2295 3.8. De-Multiplexing at NATs 2297 Section 3.7.2 describes how NSIS nodes behind NATs can obtain a 2298 public reachable IP address and port number at a NAT and and how the 2299 resulting mapping rule can be activated by using CREATE messages (see 2300 Section 3.7.1). The information about the public IP address/port 2301 number can be transmitted via an application level signaling protocol 2302 and/or third party to the communication partner that would like to 2303 send data toward the host behind the NAT. However, NSIS signaling 2304 flows are sent towards the address of the NAT at which this 2305 particular IP address and port number is allocated and not directly 2306 to the allocated IP address and port number. The NATFW NSLP 2307 forwarder at this NAT needs to know how the incoming NSLP CREATE 2308 messages are related to reserved addresses, meaning how to de- 2309 multiplex incoming NSIS CREATE messages. 2311 The de-multiplexing method uses information stored at the local NATFW 2312 NSLP node and in the policy rule. The policy rule uses the LE-MRM 2313 MRI source-address (see [I-D.ietf-nsis-ntlp]) as the flow destination 2314 IP address and the network-layer-version as IP version. The external 2315 IP address at the NAT is stored as the external flow destination IP 2316 address. All other parameters of the policy rule other than the flow 2317 destination IP address are wildcarded if no NATFW_DTINFO object is 2318 included in the EXTERNAL message. The LE-MRM MRI destination-address 2319 MUST NOT be used in the policy rule, since it is solely a signaling 2320 destination address. 2322 If the NATFW_DTINFO object is included in the EXTERNAL message, the 2323 policy rule is filled with further information. The 'dst port 2324 number' field of the NATFW_DTINFO is stored as the flow destination 2325 port number. The 'protocol' field is stored as the flow protocol. 2326 The 'src port number' field is stored as the flow source port number. 2327 The 'data sender's IPv4 address' is stored as the flow source IP 2328 address. Note that some of these field can contain wildcards. 2330 When receiving a CREATE message at the NATFW NSLP it uses the flow 2331 information stored in the MRI to do the matching process. This table 2332 shows the parameters to be compared against each others. Note that 2333 not all parameters can be present in a MRI at the same time. 2335 +-------------------------------+--------------------------------+ 2336 | Flow parameter (Policy Rule) | MRI parameter (CREATE message) | 2337 +-------------------------------+--------------------------------+ 2338 | IP version | network-layer-version | 2339 | | | 2340 | Protocol | IP-protocol | 2341 | | | 2342 | source IP address (w) | source-address (w) | 2343 | | | 2344 | external IP address | destination-address | 2345 | | | 2346 | destination IP address (n/u) | N/A | 2347 | | | 2348 | source port number (w) | L4-source-port (w) | 2349 | | | 2350 | external port number (w) | L4-destination-port (w) | 2351 | | | 2352 | destination port number (n/u) | N/A | 2353 | | | 2354 | IPsec-SPI | ipsec-SPI | 2355 +-------------------------------+--------------------------------+ 2357 Table entries marked with (w) can be wildcarded and entries marked 2358 with (n/u) are not used for the matching. 2360 Table 1 2362 3.9. Reacting to Route Changes 2364 The NATFW NSLP needs to react to route changes in the data path. 2365 This assumes the capability to detect route changes, to perform NAT 2366 and firewall configuration on the new path and possibly to tear down 2367 NATFW NSLP signaling session state on the old path. The detection of 2368 route changes is described in Section 7 of [I-D.ietf-nsis-ntlp] and 2369 the NATFW NSLP relies on notifications about route changes by the 2370 NTLP. This notification will be conveyed by the API between NTLP and 2371 NSLP, which is out of scope of this memo. 2373 A NATFW NSLP node other than the NI or NI+ detecting a route change, 2374 by means described in the NTLP specification or others, generates a 2375 NOTIFY message indicating this change and sends this inbound towards 2376 NI and outbound towards the NR (see also Section 3.7.5.). 2377 Intermediate NFs on the way to the NI can use this information to 2378 decide later if their NATFW NSLP signaling session can be deleted 2379 locally, if they do not receive an update within a certain time 2380 period, as described in Section 3.2.8. It is important to consider 2381 the transport limitations of NOTIFY messages as mandated in 2382 Section 3.7.5. 2384 The NI receiving this NOTIFY message MAY generate a new CREATE or 2385 EXTERNAL message and send it towards the NATFW NSLP signaling 2386 session's NI as for the initial message using the same session ID. 2387 All the remaining processing and message forwarding, such as NSLP 2388 next hop discovery, is subject to regular NSLP processing as 2389 described in the particular sections. Normal routing will guide the 2390 new CREATE or EXTERNAL message to the correct NFs along the changed 2391 route. NFs that were on the original path receiving these new CREATE 2392 or EXTERNAL messages (see also Section 3.10), can use the session ID 2393 to update the existing NATFW NSLP signaling session, whereas NFs that 2394 were not on the original path will create new state for this NATFW 2395 NSLP signaling session. The next section describes how policy rules 2396 are updated. 2398 3.10. Updating Policy Rules 2400 NSIS initiators can request an update of the installed/reserved 2401 policy rules at any time within a NATFW NSLP signaling session. 2402 Updates to policy rules can be required due to node mobility (NI is 2403 moving from one IP address to another), route changes (this can 2404 result in a different NAT mapping at a different NAT device), or the 2405 wish of the NI to simply change the rule. NIs can update policy 2406 rules in existing NATFW NSLP signaling sessions by sending an 2407 appropriate CREATE or EXTERNAL message (similar to Section 3.4) with 2408 modified message routing information (MRI) as compared with that 2409 installed previously, but using the existing session ID to identify 2410 the intended target of the update. With respect to authorization and 2411 authentication, this update CREATE or EXTERNAL message is treated in 2412 exactly the same way as any initial message. Therefore, any node 2413 along in the NATFW NSLP signaling session can reject the update with 2414 an error RESPONSE message, as defined in the previous sections. 2416 The message processing and forwarding is executed as defined in the 2417 particular sections. A NF or the NR receiving an update, simply 2418 replaces the installed policy rules installed in the firewall/NAT. 2419 The local procedures on how to update the MRI in the firewall/NAT is 2420 out of scope of this memo. 2422 4. NATFW NSLP Message Components 2424 A NATFW NSLP message consists of a NSLP header and one or more 2425 objects following the header. The NSLP header is carried in all 2426 NATFW NSLP messages and objects are Type-Length-Value (TLV) encoded 2427 using big endian (network ordered) binary data representations. 2428 Header and objects are aligned to 32 bit boundaries and object 2429 lengths that are not multiples of 32 bits must be padded to the next 2430 higher 32 bit multiple. 2432 The whole NSLP message is carried as payload of a NTLP message. 2434 Note that the notation 0x is used to indicate hexadecimal numbers. 2436 4.1. NSLP Header 2438 All GIST NSLP-Data objects for the NATFW NSLP MUST contain this 2439 common header as the first 32 bits of the object (this is not the 2440 same as the GIST Common Header). It contains two fields, the NSLP 2441 message type and the P Flag, plus two reserved fields. The total 2442 length is 32 bits. The layout of the NSLP header is defined by 2443 Figure 20. 2445 0 1 2 3 2446 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 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | Message type |P| reserved | reserved | 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 Figure 20: Common NSLP header 2453 The reserved field MUST be set to zero in the NATFW NSLP header 2454 before sending and MUST be ignored during processing of the header. 2456 The defined messages types are: 2458 o IANA-TBD(1) : CREATE 2460 o IANA-TBD(2) : EXTERNAL 2462 o IANA-TBD(3) : RESPONSE 2464 o IANA-TBD(4) : NOTIFY 2466 If a message with another type is received, an error RESPONSE of 2467 class 'Protocol error' (0x3) with response code 'Illegal message 2468 type' (0x01) MUST be generated. 2470 The P flag indicates the usage of proxy mode. If proxy mode is used 2471 it MUST be set to 1. Proxy mode usage MUST only be used in 2472 combination with the message types CREATE and EXTERNAL. The P flag 2473 MUST be ignored when processing messages with type RESPONSE or 2474 NOTIFY. 2476 4.2. NSLP Objects 2478 NATFW NSLP objects use a common header format defined by Figure 21. 2479 The object header contains these fields: two flags, two reserved 2480 bits, the NSLP object type, a rerserved field of 4 bits, and the 2481 object length. Its total length is 32 bits. 2483 0 1 2 3 2484 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 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 Figure 21: Common NSLP object header 2491 The object length field contains the total length of the object 2492 without the object header. The unit is a word, consisting of 4 2493 octets. The particular values of type and length for each NSLP 2494 object are listed in the subsequent sections that define the NSLP 2495 objects. An error RESPONSE of class 'Protocol error' (0x3) with 2496 response code 'Wrong object length' (0x07) MUST be generated if the 2497 length given for the object in the object header did not match the 2498 length of the object data present. The two leading bits of the NSLP 2499 object header are used to signal the desired treatment for objects 2500 whose treatment has not been defined in this memo (see 2501 [I-D.ietf-nsis-ntlp], Section A.2.1), i.e., the Object Type has not 2502 been defined. NATFW NSLP uses a subset of the categories defined in 2503 GIST: 2505 o AB=00 ("Mandatory"): If the object is not understood, the entire 2506 message containing it MUST be rejected with an error RESPONSE of 2507 class 'Protocol error' (0x3) with response code 'Unknown object 2508 present' (0x06). 2510 o AB=01 ("Optional"): If the object is not understood, it should be 2511 deleted and then the rest of the message processed as usual. 2513 o AB=10 ("Forward"): If the object is not understood, it should be 2514 retained unchanged in any message forwarded as a result of message 2515 processing, but not stored locally. 2517 The combination AB=11 MUST NOT be used and an error RESPONSE of class 2518 'Protocol error' (0x3) with response code 'Invalid Flag-Field 2519 combination' (0x09) MUST be generated. 2521 The following sections do not repeat the common NSLP object header, 2522 they just list the type and the length. 2524 4.2.1. Signaling Session Lifetime Object 2526 The signaling session lifetime object carries the requested or 2527 granted lifetime of a NATFW NSLP signaling session measured in 2528 seconds. 2530 Type: NATFW_LT (IANA-TBD) 2532 Length: 1 2534 0 1 2 3 2535 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 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 | NATFW NSLP signaling session lifetime | 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2540 Figure 22: Signaling Session Lifetime object 2542 4.2.2. External Address Object 2544 The external address object can be included in RESPONSE messages 2545 (Section 4.3.3) only. It carries the publicly reachable IP address, 2546 and if applicable port number, at an edge-NAT. 2548 Type: NATFW_EXTERNAL-IP (IANA-TBD) 2550 Length: 2 2552 0 1 2 3 2553 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 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 | port number | reserved | 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 | IPv4 address | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 Figure 23: External Address Object for IPv4 addresses 2562 Please note that the field 'port number' MUST be set to 0 if only an 2563 IP address has been reserved, for instance, by a traditional NAT. A 2564 port number of 0 MUST be ignored in processing this object. 2566 4.2.3. Extended Flow Information Object 2568 In general, flow information is kept in the message routing 2569 information (MRI) of the NTLP. Nevertheless, some additional 2570 information may be required for NSLP operations. The 'extended flow 2571 information' object carries this additional information about the 2572 action of the policy rule for firewalls/NATs and contiguous port . 2574 Type: NATFW_EFI (IANA-TBD) 2576 Length: 1 2578 0 1 2 3 2579 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 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 | rule action | sub_ports | 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 Figure 24: Extended Flow Information 2586 This object has two fields, 'rule action' and 'sub_ports'. The 'rule 2587 action' field has these meanings: 2589 o 0x0001: Allow: A policy rule with this action allows data traffic 2590 to traverse the middlebox and the NATFW NSLP MUST allow NSLP 2591 signaling to be forwarded. 2593 o 0x0002: Deny: A policy rule with this action blocks data traffic 2594 from traversing the middlebox and the NATFW NSLP MUST NOT allow 2595 NSLP signaling to be forwarded. 2597 If the 'rule action' field contains neither 0x0001 nor 0x0002, an 2598 error RESPONSE of class 'Signaling session failure' (0x6) with 2599 response code 'Unknown policy rule action' (0x05) MUST be generated. 2601 The 'sub_ports' field contains the number of contiguous transport 2602 layer ports to which this rule applies. The default value of this 2603 field is 0, i.e., only the port specified in the NTLP's MRM or 2604 NATFW_DTINFO object is used for the policy rule. A value of 1 2605 indicates that additionally to the port specified in the NTLP's MRM 2606 (port1), a second port (port2) is used. This value of port 2 is 2607 calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT 2608 be used in this field and an error RESPONSE of class 'Signaling 2609 session failure' (0x6) with response code 'Requested value in 2610 sub_ports field in NATFW_EFI not permitted' (0x08) MUST be generated. 2611 This two contiguous port numbered ports, can be used by legacy voice 2612 over IP equipment. This legacy equipment assumes that two adjacent 2613 port numbers for its RTP/RTCP flows respectively. 2615 4.2.4. Information Code Object 2617 This object carries the response code, which may be indications for 2618 either a successful or failed CREATE or EXTERNAL message depending on 2619 the value of the 'response code' field. 2621 Type: NATFW_INFO (IANA-TBD) 2623 Length: 1 2625 0 1 2 3 2626 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 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 | Resv. | Class | Response Code |r|r|r|r| Object Type | 2629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 Figure 25: Information Code Object 2633 The field 'resv.' is reserved for future extensions and MUST be set 2634 to zero when generating such an object and MUST be ignored when 2635 receiving. The 'Object Type' field contains the type of the object 2636 causing the error. The value of 'Object Type' is set to 0, if no 2637 object is concerned. The leading fours bits marked with 'r' are 2638 always set to zero and ignored. The 4 bit class field contains the 2639 severity class. The following classes are defined: 2641 o 0x0: Reserved 2643 o 0x1: Informational (NOTIFY only) 2645 o 0x2: Success 2647 o 0x3: Protocol error 2649 o 0x4: Transient failure 2651 o 0x5: Permanent failure 2653 o 0x6: Signaling session failure 2655 Within each severity class a number of responses values are defined 2656 o Informational: 2658 * 0x01: Route change: possible route change on the outbound path. 2660 * 0x02: Re-authentication required. 2662 * 0x03: NATFW node is going down soon. 2664 * 0x04: NATFW signaling session lifetime expired. 2666 * 0x05: NATFW signaling session terminated. 2668 o Success: 2670 * 0x01: All successfully processed. 2672 o Protocol error: 2674 * 0x01: Illegal message type: the type given in the Message Type 2675 field of the NSLP header is unknown. 2677 * 0x02: Wrong message length: the length given for the message in 2678 the NSLP header does not match the length of the message data. 2680 * 0x03: Bad flags value: an undefined flag or combination of 2681 flags was set in the NSLP header. 2683 * 0x04: Mandatory object missing: an object required in a message 2684 of this type was missing. 2686 * 0x05: Illegal object present: an object was present which must 2687 not be used in a message of this type. 2689 * 0x06: Unknown object present: an object of an unknown type was 2690 present in the message. 2692 * 0x07: Wrong object length: the length given for the object in 2693 the object header did not match the length of the object data 2694 present. 2696 * 0x08: Unknown object field value: a field in an object had an 2697 unknown value. 2699 * 0x09: Invalid Flag-Field combination: An object contains an 2700 invalid combination of flags and/or fields. 2702 * 0x0A: Duplicate object present. 2704 * 0x0B: Received EXTERNAL request message on external side. 2706 o Transient failure: 2708 * 0x01: Requested resources temporarily not available. 2710 o Permanent failure: 2712 * 0x01: Authentication failed. 2714 * 0x02: Authorization failed. 2716 * 0x04: Internal or system error. 2718 * 0x06: No edge-device here. 2720 * 0x07: Did not reach the NR. 2722 o Signaling session failure: 2724 * 0x01: Session terminated asynchronously. 2726 * 0x02: Requested lifetime is too big. 2728 * 0x03: No reservation found matching the MRI of the CREATE 2729 request. 2731 * 0x04: Requested policy rule denied due to policy conflict. 2733 * 0x05: Unknown policy rule action. 2735 * 0x06: Requested rule action not applicable. 2737 * 0x07: NATFW_DTINFO object is required. 2739 * 0x08: Requested value in sub_ports field in NATFW_EFI not 2740 permitted. 2742 * 0x09: Requested IP protocol not supported. 2744 * 0x0A: Plain IP policy rules not permitted -- need transport 2745 layer information. 2747 * 0x0B: ICMP type value not permitted. 2749 * 0x0C: source IP address range is too large. 2751 * 0x0D: destination IP address range is too large. 2753 * 0x0E: source L4-port range is too large. 2755 * 0x0F: destination L4-port range is too large. 2757 * 0x10: Requested lifetime is too small. 2759 * 0x11: Modified lifetime is too big. 2761 * 0x12: Modified lifetime is too small. 2763 4.2.5. Nonce Object 2765 This object carries the nonce value as described in Section 3.7.6. 2767 Type: NATFW_NONCE (IANA-TBD) 2769 Length: 1 2771 0 1 2 3 2772 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 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | nonce | 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 Figure 26: Nonce Object 2779 4.2.6. Message Sequence Number Object 2781 This object carries the MSN value as described in Section 3.5. 2783 Type: NATFW_MSN (IANA-TBD) 2785 Length: 1 2787 0 1 2 3 2788 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 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2790 | message sequence number | 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2793 Figure 27: Message Sequence Number Object 2795 4.2.7. Data Terminal Information Object 2797 The 'data terminal information' object carries additional information 2798 MUST be included the EXTERNAL message. EXTERNAL messages are 2799 transported by the NTLP using the Loose-End message routing method 2800 (LE-MRM). The LE-MRM contains only DR's IP address and a signaling 2801 destination address (destination address). This destination address 2802 is used for message routing only and is not necessarily reflecting 2803 the address of the data sender. This object contains information 2804 about (if applicable) DR's port number (the destination port number), 2805 DS' port number (the source port number), the used transport 2806 protocol, the prefix length of the IP address, and DS' IP address. 2808 Type: NATFW_DTINFO (IANA-TBD) 2810 Length: variable. Maximum 3. 2812 0 1 2 3 2813 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 2814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 |I|P|S| reserved | sender prefix | protocol | 2816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2817 : DR port number | DS port number : 2818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 : IPsec-SPI : 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2821 | data sender's IPv4 address | 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2824 Figure 28: Data Terminal IPv4 Address Object 2826 The flags are: 2828 o I: I=1 means that 'protocol' should be interpreted. 2830 o P: P=1 means that 'dst port number' and 'src port number' are 2831 present and should be interpreted. 2833 o S: S=1 means that SPI is present and should be interpreted. 2835 The SPI field is only present if S is set. The port numbers are only 2836 present if P is set. The flags P and S MUST NOT be set at the same 2837 time. An error RESPONSE of class 'Protocol error' (0x3) with 2838 response code 'Invalid Flag-Field combination' (0x09) MUST be 2839 generated if they are both set. If either P or S is set, I MUST be 2840 set as well and the protocol field MUST carry the particular 2841 protocol. An error RESPONSE of class 'Protocol error' (0x3) with 2842 response code 'Invalid Flag-Field combination' (0x09) MUST be 2843 generated if S or P is set but I is not set. 2845 The fields MUST be interpreted according to these rules: 2847 o (data) sender prefix: This parameter indicates the prefix length 2848 of the 'data sender's IP address' in bits. For instance, a full 2849 IPv4 address requires 'sender prefix' to be set to 32. A value of 2850 0 indicates an IP address wildcard. 2852 o protocol: The IP protocol field. This field MUST be interpreted 2853 if I=1, otherwise it MUST be set to 0 and MUST be ignored. 2855 o DR port number: The port number at the data receiver (DR), i.e., 2856 the destination port. A value of 0 indicates a port wildcard, 2857 i.e., the destination port number is not known. Any other value 2858 indicates the destination port number. 2860 o DS port number: The port number at the data sender (DS), i.e., the 2861 source port. A value of 0 indicates a port wildcard, i.e., the 2862 source port number is not known. Any other value indicates the 2863 source port number. 2865 o data sender's IPv4 address: The source IP address of the data 2866 sender. This field MUST be set to zero if no IP address is 2867 provided, i.e., a complete wildcard is desired (see dest prefix 2868 field above). 2870 4.2.8. ICMP Types Object 2872 The 'ICMP types' object contains additional information needed to 2873 configure a NAT of firewall with rules to control ICMP traffic. The 2874 object contains a number of values of the ICMP Type field for which a 2875 filter action should be set up: 2877 Type: NATFW_ICMP_TYPES (IANA-TBD) 2879 Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 2881 Where DIV is an integer division. 2883 0 1 2 3 2884 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 2885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2886 | Count | Type | Type | ........ | 2887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 | ................ | 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2890 | ........ | Type | (Padding) | 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 Figure 29: ICMP Types Object 2895 The fields MUST be interpreted according to these rules: 2897 count: 8 bit integer specifying the number of 'Type' entries in 2898 the object. 2900 type: 8 bit field specifying an ICMP Type value to which this rule 2901 applies. 2903 padding: Sufficient 0 bits to pad out the last word so that the 2904 total size of object is an even multiple of words. Ignored on 2905 reception. 2907 4.3. Message Formats 2909 This section defines the content of each NATFW NSLP message type. 2910 The message types are defined in Section 4.1. 2912 Basically, each message is constructed of NSLP header and one or more 2913 NSLP objects. The order of objects is not defined, meaning that 2914 objects may occur in any sequence. Objects are marked either with 2915 mandatory (M) or optional (O). Where (M) implies that this 2916 particular object MUST be included within the message and where (O) 2917 implies that this particular object is OPTIONAL within the message. 2918 Objects defined in this memo always carry the flag combination AB=00 2919 in the NSLP object header. An error RESPONSE message of class 2920 'Protocol error' (0x3) with response code 'Mandatory object missing' 2921 (0x04) MUST be generated if a mandatory declared object is missing. 2922 An error RESPONSE message of class 'Protocol error' (0x3) with 2923 response code 'Illegal object present' (0x05) MUST be generated if an 2924 object was present which must not be used in a message of this type. 2925 An error RESPONSE message of class 'Protocol error' (0x3) with 2926 response code 'Duplicate object present' (0x0A) MUST be generated if 2927 an object appears more than once in a message. 2929 Each section elaborates the required settings and parameters to be 2930 set by the NSLP for the NTLP, for instance, how the message routing 2931 information is set. 2933 4.3.1. CREATE 2935 The CREATE message is used to create NATFW NSLP signaling sessions 2936 and to create policy rules. Furthermore, CREATE messages are used to 2937 refresh NATFW NSLP signaling sessions and to delete them. 2939 The CREATE message carries these objects: 2941 o Signaling Session Lifetime object (M) 2943 o Extended flow information object (M) 2945 o Message sequence number object (M) 2947 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 2948 (O) 2950 o ICMP Types Object (O) 2952 The message routing information in the NTLP MUST be set to DS as 2953 source address and DR as destination address. All other parameters 2954 MUST be set according the required policy rule. CREATE messages MUST 2955 be transported by using the path-coupled MRM with direction set to 2956 'downstream' (outbound). 2958 4.3.2. EXTERNAL 2960 The EXTERNAL message is used to a) reserve an external IP address/ 2961 port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to 2962 block incoming data traffic at inbound firewalls. 2964 The EXTERNAL message carries these objects: 2966 o Signaling Session Lifetime object (M) 2968 o Message sequence number object (M) 2970 o Extended flow information object (M) 2972 o Data terminal information object (M) 2974 o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise 2975 (O) 2977 o ICMP Types Object (O) 2978 The selected message routing method of the EXTERNAL message depends 2979 on a number of considerations. Section 3.7.2 describes it 2980 exhaustively how to select the correct method. EXTERNAL messages can 2981 be transported via the path-coupled message routing method (PC-MRM) 2982 or via the loose-end message routing method (LE-MRM). In the case of 2983 PC-MRM, the source-address is set to DS' address and the destination 2984 address is set to DR's address, the direction is set to inbound. In 2985 the case of LE-MRM, the destination-address is set to DR's address or 2986 to the signaling destination address. The source-address is set to 2987 DS's address. 2989 4.3.3. RESPONSE 2991 RESPONSE messages are responses to CREATE and EXTERNAL messages. 2992 RESPONSE messages MUST NOT be generated for any other message, such 2993 as NOTIFY and RESPONSE. 2995 The RESPONSE message for the class 'Success' (0x2) carries these 2996 objects: 2998 o Signaling Session Lifetime object (M) 3000 o Message sequence number object (M) 3002 o Information code object (M) 3004 o External address object (O) 3006 The RESPONSE message for other classes than 'Success' (0x2) carries 3007 these objects: 3009 o Message sequence number object (M) 3011 o Information code object (M) 3013 This message is routed towards the NI hop-by-hop, using existing NTLP 3014 messaging associations. The MRM used for this message MUST be the 3015 same as MRM used by the corresponding CREATE or EXTERNAL message. 3017 4.3.4. NOTIFY 3019 The NOTIFY messages is used to report asynchronous events happening 3020 along the signaled path to other NATFW NSLP nodes. 3022 The NOTIFY message carries this object: 3024 o Information code object (M). 3026 The NOTIFY message is routed towards the NI hop-by-hop using the 3027 existing inbound node messaging association entry within the node's 3028 Message Routing State table. The MRM used for this message MUST be 3029 the same as MRM used by the corresponding CREATE or EXTERNAL message. 3031 5. Security Considerations 3033 Security is of major concern particularly in case of firewall 3034 traversal. This section provides security considerations for the 3035 NAT/firewall traversal and is organized as follows. 3037 In Section 5.1 we describe how the participating entities relate to 3038 each other from a security point of view. This subsection also 3039 motivates a particular authorization model. 3041 Security threats that focus on NSIS in general are described in 3042 [RFC4081] and they are applicable to this document as well. 3044 Finally, we illustrate how the security requirements that were 3045 created based on the security threats can be fulfilled by specific 3046 security mechanisms. These aspects will be elaborated in 3047 Section 5.2. 3049 5.1. Authorization Framework 3051 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 3052 and is, as such, not a two-party protocol. Figure 1 and Figure 2 of 3053 [RFC4081] already depict the possible set of communication patterns. 3054 In this section we will re-evaluate these communication patters with 3055 respect to the NATFW NSLP protocol interaction. 3057 The security solutions for providing authorization have a direct 3058 impact on the treatment of different NSLPs. As it can be seen from 3059 the QoS NSLP [I-D.ietf-nsis-qos-nslp] and the corresponding Diameter 3060 QoS work [I-D.ietf-dime-diameter-qos] accounting and charging seems 3061 to play an important role for QoS reservations, whereas monetary 3062 aspects might only indirectly effect authorization decisions for NAT 3063 and firewall signaling. Hence, there are differences in the semantic 3064 of authorization handling between QoS and NATFW signaling. A NATFW 3065 aware node will most likely want to authorize the entity (e.g., user 3066 or machine) requesting the establishment of pinholes or NAT bindings. 3067 The outcome of the authorization decision is either allowed or 3068 disallowed whereas a QoS authorization decision might indicate that a 3069 different set of QoS parameters is authorization (see 3070 [I-D.ietf-dime-diameter-qos] as an example). 3072 5.1.1. Peer-to-Peer Relationship 3074 Starting with the simplest scenario, it is assumed that neighboring 3075 nodes are able to authenticate each other and to establish keying 3076 material to protect the signaling message communication. The nodes 3077 will have to authorize each other, additionally to the 3078 authentication. We use the term 'Security Context' as a placeholder 3079 for referring to the entire security procedure, the necessary 3080 infrastructure that needs to be in place in order for this to work 3081 (e.g., key management) and the established security related state. 3082 The required long-term key (symmetric or asymmetric keys) used for 3083 authentication are either made available using an out-of-band 3084 mechanism between the two NSIS NATFW nodes or they are dynamically 3085 established using mechanisms not further specified in this document. 3086 Note that the deployment environment will most likely have an impact 3087 on the choice of credentials being used. The choice of these 3088 credentials used is also outside the scope of this document. 3090 +------------------------+ +-------------------------+ 3091 |Network A | | Network B| 3092 | +---------+ +---------+ | 3093 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3094 | | | box 1 | Security | box 2 | | | 3095 | | +---------+ Context +---------+ | | 3096 | | Security | | Security | | 3097 | | Context | | Context | | 3098 | | | | | | 3099 | +--+---+ | | +--+---+ | 3100 | | Host | | | | Host | | 3101 | | A | | | | B | | 3102 | +------+ | | +------+ | 3103 +------------------------+ +-------------------------+ 3105 Figure 30: Peer-to-Peer Relationship 3107 Figure 30 shows a possible relationship between participating NSIS 3108 aware nodes. Host A might be, for example, a host in an enterprise 3109 network that has keying material established (e.g., a shared secret) 3110 with the company's firewall (Middlebox 1). The network administrator 3111 of Network A (company network) has created access control lists for 3112 Host A (or whatever identifiers a particular company wants to use). 3113 Exactly the same procedure might also be used between Host B and 3114 Middlebox 2 in Network B. For the communication between Middlebox 1 3115 and Middlebox 2 a security context is also assumed in order to allow 3116 authentication, authorization and signaling message protection to be 3117 successful. 3119 5.1.2. Intra-Domain Relationship 3121 In larger corporations, for example, a middlebox is used to protect 3122 individual departments. In many cases, the entire enterprise is 3123 controlled by a single (or a small number of) security department, 3124 which gives instructions to the department administrators. In such a 3125 scenario, the previously discussed peer-to-peer relationship might be 3126 prevalent. Sometimes it might be necessary to preserve 3127 authentication and authorization information within the network. As 3128 a possible solution, a centralized approach could be used, whereby an 3129 interaction between the individual middleboxes and a central entity 3130 (for example a policy decision point - PDP) takes place. As an 3131 alternative, individual middleboxes exchange the authorization 3132 decision with another middlebox within the same trust domain. 3133 Individual middleboxes within an administrative domain may exploit 3134 their relationship instead of requesting authentication and 3135 authorization of the signaling initiator again and again. Figure 31 3136 illustrates a network structure which uses a centralized entity. 3138 +-----------------------------------------------------------+ 3139 | Network A | 3140 | +---------+ +---------+ 3141 | +----///--------+ Middle- +------///------++ Middle- +--- 3142 | | Security | box 2 | Security | box 2 | 3143 | | Context +----+----+ Context +----+----+ 3144 | +----+----+ | | | 3145 | | Middle- +--------+ +---------+ | | 3146 | | box 1 | | | | | 3147 | +----+----+ | | | | 3148 | | Security | +----+-----+ | | 3149 | | Context | | Policy | | | 3150 | +--+---+ +-----------+ Decision +----------+ | 3151 | | Host | | Point | | 3152 | | A | +----------+ | 3153 | +------+ | 3154 +-----------------------------------------------------------+ 3156 Figure 31: Intra-domain Relationship 3158 The interaction between individual middleboxes and a policy decision 3159 point (or AAA server) is outside the scope of this document. 3161 5.1.3. End-to-Middle Relationship 3163 The peer-to-peer relationship between neighboring NSIS NATFW NSLP 3164 nodes might not always be sufficient. Network B might require 3165 additional authorization of the signaling message initiator (in 3166 addition to the authorization of the neighboring node). If 3167 authentication and authorization information is not attached to the 3168 initial signaling message then the signaling message arriving at 3169 Middlebox 2 would result in an error message being created, which 3170 indicates the additional authorization requirement. In many cases 3171 the signaling message initiator might already be aware of the 3172 additionally required authorization before the signaling message 3173 exchange is executed. 3175 Figure 32 shows this scenario. 3177 +--------------------+ +---------------------+ 3178 | Network A | |Network B | 3179 | | Security | | 3180 | +---------+ Context +---------+ | 3181 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3182 | | | box 1 | +-------+ box 2 | | | 3183 | | +---------+ | +---------+ | | 3184 | |Security | | | Security | | 3185 | |Context | | | Context | 3186 | | | | | | | 3187 | +--+---+ | | | +--+---+ | 3188 | | Host +----///----+------+ | | Host | | 3189 | | A | | Security | | B | | 3190 | +------+ | Context | +------+ | 3191 +--------------------+ +---------------------+ 3193 Figure 32: End-to-Middle Relationship 3195 5.2. Security Framework for the NAT/Firewall NSLP 3197 The following list of security requirements has been created to 3198 ensure proper secure operation of the NATFW NSLP. 3200 5.2.1. Security Protection between neighboring NATFW NSLP Nodes 3202 Based on the analyzed threats it is RECOMMENDED to provide, between 3203 neighboring NATFW NSLP nodes, the following mechanism: 3205 o data origin authentication 3207 o replay protection 3209 o integrity protection and 3211 o optionally confidentiality protection 3213 It is RECOMMENDED to use the authentication and key exchange security 3214 mechanisms provided in [I-D.ietf-nsis-ntlp] between neighboring nodes 3215 when sending NATFW signaling messages. The proposed security 3216 mechanisms of GIST provide support for authentication and key 3217 exchange in addition to denial of service protection. Depending on 3218 the chosen security protocol, support for multiple authentication 3219 protocols might be provided. If security between neighboring nodes 3220 is desired than the usage of C-MODE for the delivery of data packets 3221 and the usage of D-MODE only to discover the next NATFW NSLP aware 3222 node along the path is highly RECOMMENDED. Almost all security 3223 threats at the NATFW NSLP layer can be prevented by using a mutually 3224 authenticated Transport Layer secured connection and by relying on 3225 authorization by the neighboring NATFW NSLP entities. 3227 The NATFW NSLP relies on an established security association between 3228 neighboring peers to prevent unauthorized nodes to modify or delete 3229 installed state. Between non-neighboring nodes the session ID (SID) 3230 carried in the NTLP is used to show ownership of a NATFW NSLP 3231 signaling session. The session ID MUST be generated in a random way 3232 and thereby prevent an off-path adversary to mount targeted attacks. 3233 Hence, an adversary would have to learn the randomly generated 3234 session ID to perform an attack. In a mobility environment a former 3235 on-path node that is now off-path can perform an attack. Messages 3236 for a particular NATFW NSLP signaling session are handled by the NTLP 3237 to the NATFW NSLP for further processing. Messages carrying a 3238 different session ID not associated with any NATFW NSLP are subject 3239 to the regular processing for new NATFW NSLP signaling sessions. 3241 5.2.2. Security Protection between non-neighboring NATFW NSLP Nodes 3243 Based on the security threats and the listed requirements it was 3244 noted that some threats also demand authentication and authorization 3245 of a NATFW signaling entity (including the initiator) towards a non- 3246 neighboring node. This mechanism mainly demands entity 3247 authentication. The most important information exchanged at the 3248 NATFW NSLP is information related to the establishment for firewall 3249 pinholes and NAT bindings. This information can, however, not be 3250 protected over multiple NSIS NATFW NSLP hops since this information 3251 might change depending on the capability of each individual NATFW 3252 NSLP node. 3254 Some scenarios might also benefit from the usage of authorization 3255 tokens. Their purpose is to associate two different signaling 3256 protocols (e.g., SIP and NSIS) and their authorization decision. 3257 These tokens are obtained by non-NSIS protocols, such as SIP or as 3258 part of network access authentication. When a NAT or firewall along 3259 the path receives the token it might be verified locally or passed to 3260 the AAA infrastructure. Examples of authorization tokens can be 3261 found in RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. Figure 33 shows 3262 an example of this protocol interaction. 3264 An authorization token is provided by the SIP proxy, which acts as 3265 the assertion generating entity and gets delivered to the end host 3266 with proper authentication and authorization. When the NATFW 3267 signaling message is transmitted towards the network, the 3268 authorization token is attached to the signaling messages to refer to 3269 the previous authorization decision. The assertion verifying entity 3270 needs to process the token or it might be necessary to interact with 3271 the assertion granting entity using HTTP (or other protocols). As a 3272 result of a successfully authorization by a NATFW NSLP node, the 3273 requested action is executed and later a RESPONSE message is 3274 generated. 3276 +----------------+ Trust Relationship +----------------+ 3277 | +------------+ |<.......................>| +------------+ | 3278 | | Protocol | | | | Assertion | | 3279 | | requesting | | HTTP, SIP Request | | Granting | | 3280 | | authz | |------------------------>| | Entity | | 3281 | | assertions | |<------------------------| +------------+ | 3282 | +------------+ | Artifact/Assertion | Entity Cecil | 3283 | ^ | +----------------+ 3284 | | | ^ ^| 3285 | | | . || HTTP, 3286 | | | Trust . || other 3287 | API Access | Relationship. || protocols 3288 | | | . || 3289 | | | . || 3290 | | | v |v 3291 | v | +----------------+ 3292 | +------------+ | | +------------+ | 3293 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3294 | | using authz| | Assertion/Artifact | | Verifying | | 3295 | | assertion | | ----------------------- | | Entity | | 3296 | +------------+ | | +------------+ | 3297 | Entity Alice | <---------------------- | Entity Bob | 3298 +----------------+ RESPONSE +----------------+ 3300 Figure 33: Authorization Token Usage 3302 Threats against the usage of authorization tokens have been mentioned 3303 in [RFC4081]. Hence, it is required to provide confidentiality 3304 protection to avoid allowing an eavesdropper to learn the token and 3305 to use it in another NATFW NSLP signaling session (replay attack). 3306 The token itself also needs to be protected against tempering. 3308 6. IAB Considerations on UNSAF 3310 UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a 3311 process at originating endpoints that attempt to determine or fix the 3312 address (and port) by which they are known to another endpoint. 3313 UNSAF proposals, such as STUN [RFC5389] are considered as a general 3314 class of workarounds for NAT traversal and as solutions for scenarios 3315 with no middlebox communication. 3317 This memo specifies a path-coupled middlebox communication protocol, 3318 i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are 3319 not intended as a short-term workaround, but more as a long-term 3320 solution for middlebox communication. In NSIS, endpoints are 3321 involved in allocating, maintaining, and deleting addresses and ports 3322 at the middlebox. However, the full control of addresses and ports 3323 at the middlebox is at the NATFW NSLP daemon located at the 3324 respective NAT. 3326 Therefore, this document addresses the UNSAF considerations in 3327 [RFC3424] by proposing a long-term alternative solution. 3329 7. IANA Considerations 3331 This section provides guidance to the Internet Assigned Numbers 3332 Authority (IANA) regarding registration of values related to the 3333 NATFW NSLP, in accordance with BCP 26 RFC 5226 [RFC5226]. 3335 The NATFW NSLP requires IANA to create a number of new registries. 3336 These registries may require further coordination with the registries 3337 of the NTLP [I-D.ietf-nsis-ntlp] and the QoS NSLP 3338 [I-D.ietf-nsis-qos-nslp]. 3340 NATFW NSLP Message Type Registry 3342 The NATFW NSLP Message Type is a 8 bit value. The allocation of 3343 values for new message types requires standards action. Updates and 3344 deletion of values from the registry is not possible. This 3345 specification defines four NATFW NSLP message types, which form the 3346 initial contents of this registry. IANA is requested to add these 3347 four NATFW NSLP Message Types: CREATE, EXT, RESPONSE, and NOTIFY. 3349 NATFW NSLP Header Flag Registry 3351 NATFW NSLP messages have a messages-specific 8 bit flags/reserved 3352 field in their header. The registration of flags is subject to IANA 3353 registration. The allocation of values for flag types requires 3354 standards action. Updates and deletion of values from the registry 3355 is not possible. This specification defines only one flag, the P 3356 flag in Figure 20. 3358 NSLP Object Type Registry 3360 [Delete this part if already done by another NSLP: 3362 A new registry is to be created for NSLP Message Objects. This is a 3363 12-bit field (giving values from 0 to 4095). This registry is shared 3364 between a number of NSLPs. Allocation policies are as follows: 3366 0-1023: Standards Action 3368 1024-1999: Specification Required 3370 2000-2047: Private/Experimental Use 3372 2048-4095: Reserved 3374 When a new object is defined, the extensibility bits (A/B) must also 3375 be defined.] 3376 This document defines 8 objects for the NATFW NSLP: NATFW_LT, 3377 NATFW_EXTERNAL-IP, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, 3378 NATFW_DTINFO, NATFW_ICMP_TYPES. IANA is request to assigned values 3379 for them from NSLP Object Type registry and to replace the 3380 corresponding IANA-TBD tags with the numeric values. 3382 NSLP Response Code Registry 3384 In addition it defines a number of Response Codes for the NATFW NSLP. 3385 These can be found in Section 4.2.4 and are to be assigned values 3386 from NSLP Response Code registry. The allocation of values for 3387 Response Codes Codes requires standards action. IANA is request to 3388 assigned values for them from NSLP Response Code registry. 3390 GIST NSLPID 3392 This specification defines an NSLP for use with GIST and thus 3393 requires an assigned NSLP identifier. IANA is requested to add a new 3394 value to the NSLP Identifiers (NSLPID) registry defined in 3395 [I-D.ietf-nsis-ntlp] for the NATFW NSLP. 3397 8. Acknowledgments 3399 We would like to thank the following individuals for their 3400 contributions to this document at different stages: 3402 o Marcus Brunner and Henning Schulzrinne for their work on IETF 3403 drafts which lead us to start with this document; 3405 o Miquel Martin for his large contribution on the initial version of 3406 this document and one of the first prototype implemenations; 3408 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3409 NAT/firewall threats draft; 3411 o Henning Peters for his comments and suggestions; 3413 o and the NSIS working group. 3415 9. References 3417 9.1. Normative References 3419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3420 Requirement Levels", BCP 14, RFC 2119, March 1997. 3422 [I-D.ietf-nsis-ntlp] 3423 Schulzrinne, H. and R. Hancock, "GIST: General Internet 3424 Signalling Transport", draft-ietf-nsis-ntlp-17 (work in 3425 progress), October 2008. 3427 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 3428 August 1996. 3430 9.2. Informative References 3432 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3433 Bosch, "Next Steps in Signaling (NSIS): Framework", 3434 RFC 4080, June 2005. 3436 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 3437 RFC 3726, April 2004. 3439 [I-D.ietf-nsis-qos-nslp] 3440 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 3441 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 3442 (work in progress), February 2008. 3444 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 3445 A. Rayhan, "Middlebox communication architecture and 3446 framework", RFC 3303, August 2002. 3448 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 3449 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 3451 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3452 Translator (NAT) Terminology and Considerations", 3453 RFC 2663, August 1999. 3455 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 3456 Issues", RFC 3234, February 2002. 3458 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 3459 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 3460 Functional Specification", RFC 2205, September 1997. 3462 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 3463 Self-Address Fixing (UNSAF) Across Network Address 3464 Translation", RFC 3424, November 2002. 3466 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3467 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3468 May 2008. 3470 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3471 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3472 October 2008. 3474 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 3475 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 3476 J., and S. Waldbusser, "Terminology for Policy-Based 3477 Management", RFC 3198, November 2001. 3479 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 3480 "Session Authorization Policy Element", RFC 3520, 3481 April 2003. 3483 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 3484 Session Set-up with Media Authorization", RFC 3521, 3485 April 2003. 3487 [I-D.ietf-dime-diameter-qos] 3488 Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 3489 and G. Zorn, "Diameter Quality of Service Application", 3490 draft-ietf-dime-diameter-qos-06 (work in progress), 3491 July 2008. 3493 [rsvp-firewall] 3494 Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, 3495 "RSVP as firewall Signalling Protocol", Proceedings of the 3496 6th IEEE Symposium on Computers and Communications, 3497 Hammamet, Tunisia pp. 57 to 62, IEEE Computer Society 3498 Press, July 2001. 3500 Appendix A. Selecting Signaling Destination Addresses for EXTERNAL 3502 As with all other message types, EXTERNAL messages need a reachable 3503 IP address of the data sender on the GIST level. For the path- 3504 coupled MRM the source-address of GIST is the reachable IP address 3505 (i.e., the real IP address of the data sender, or a wildcard). While 3506 this is straight forward, it is not necessarily so for the loose-end 3507 MRM. Many applications do not provide the IP address of the 3508 communication counterpart, i.e., either the data sender or both a 3509 data sender and receiver. For the EXTERNAL messages, the case of 3510 data sender is of interest only. The rest of this section gives 3511 informational guidance about determining a good destination-address 3512 of the LE-MRM in GIST for EXTERNAL messages. 3514 This signaling destination address (SDA, the destination-address in 3515 GIST) can be the data sender, but for applications which do not 3516 provide an address upfront, the destination address has to be chosen 3517 independently, as it is unknown at the time when the NATFW NSLP 3518 signaling has to start. Choosing the 'correct' destination IP 3519 address may be difficult and it is possible that there is no 'right 3520 answer' for all applications relying on the NATFW NSLP. 3522 Whenever possible it is RECOMMENDED to chose the data sender's IP 3523 address as SDA. It is necessary to differentiate between the 3524 received IP addresses on the data sender. Some application level 3525 signaling protocols (e.g., SIP) have the ability to transfer multiple 3526 contact IP addresses of the data sender. For instance, private IP 3527 address, public IP address at NAT, and public IP address at a relay. 3528 It is RECOMMENDED to use all non-private IP addresses as SDAs. 3530 A different SDA must be chosen, if the IP address of the data sender 3531 is unknown. This can have multiple reasons: The application level 3532 signaling protocol cannot determine any data sender IP address at 3533 this point of time or the data receiver is server behind a NAT, i.e., 3534 accepting inbound packets from any host. In this case, the NATFW 3535 NSLP can be instructed to use the public IP address of an application 3536 server or any other node. Choosing the SDA in this case is out of 3537 the scope of the NATFW NSLP and depends on the application's choice. 3538 The local network can provide a network-SDA, i.e., a SDA which is 3539 only meaningful to the local network. This will ensure that GIST 3540 packets with destination-address set to this network-SDA are going to 3541 be routed to a edge-NAT or edge-firewall. 3543 Appendix B. Applicability Statement on Data Receivers behind Firewalls 3545 Section 3.7.2 describes how data receivers behind middleboxes can 3546 instruct inbound firewalls/NATs to forward NATFW NSLP signaling 3547 towards them. Finding an inbound edge-NAT in address environment 3548 with NAT'ed addresses is quite easy. It is only required to find 3549 some edge-NAT, as the data traffic will be route-pinned to the NAT. 3550 Locating the appropriate edge-firewall with the PC-MRM, sent inbound 3551 is difficult. For cases with a single, symmetric route from the 3552 Internet to the data receiver, it is quite easy; simply follow the 3553 default route in the inbound direction. 3555 +------+ Data Flow 3556 +-------| EFW1 +----------+ <=========== 3557 | +------+ ,--+--. 3558 +--+--+ / \ 3559 NI+-----| FW1 | (Internet )----NR+/NI/DS 3560 NR +--+--+ \ / 3561 | +------+ `--+--' 3562 +-------| EFW2 +----------+ 3563 +------+ 3565 ~~~~~~~~~~~~~~~~~~~~~> 3566 Signaling Flow 3568 Figure 34: Data receiver behind multiple, parallel located firewalls 3570 When a data receiver, and thus NR, is located in a network site that 3571 is multihomed with several independently firewalled connections to 3572 the public Internet (as shown in Figure 34), the specific firewall 3573 through which the data traffic will be routed has to be ascertained. 3574 NATFW NSLP signaling messages sent from the NI+/NR during the 3575 EXTERNAL message exchange towards the NR+ must be routed by the NTLP 3576 to the edge-firewall that will be passed by the data traffic as well. 3577 The NTLP would need to be aware about the routing within the Internet 3578 to determine the path between DS and DR. Out of this, the NTLP could 3579 determine which of the edge-firewalls, either EFW1 or EFW2, must be 3580 selected to forward the NATFW NSLP signaling. Signaling to the wrong 3581 edge-firewall, as shown in Figure 34, would install the NATFW NSLP 3582 policy rules at the wrong device. This causes either a blocked data 3583 flow (when the policy rule is 'allow') or an ongoing attack (when the 3584 policy rule is 'deny'). Requiring the NTLP to know all about the 3585 routing within the Internet is definitely a tough challenge and 3586 usually not possible. In such described case, the NTLP must 3587 basically give up and return an error to the NSLP level, indicating 3588 that the next hop discovery is not possible. 3590 Appendix C. Firewall and NAT Resources 3592 This section gives some examples on how NATFW NSLP policy rules could 3593 be mapped to real firewall or NAT resources. The firewall rules and 3594 NAT bindings are described in a natural way, i.e., in a way one will 3595 find it in common implementations. 3597 C.1. Wildcarding of Policy Rules 3599 The policy rule/MRI to be installed can be wildcarded to some degree. 3600 Wildcarding applies to IP address, transport layer port numbers, and 3601 the IP payload (or next header in IPv6). Processing of wildcarding 3602 splits into the NTLP and the NATFW NSLP layer. The processing at the 3603 NTLP layer is independent of the NSLP layer processing and per layer 3604 constraints apply. For wildcarding in the NTLP see Section 5.8 of 3605 [I-D.ietf-nsis-ntlp]. 3607 Wildcarding at the NATFW NSLP level is always a node local policy 3608 decision. A signaling message carrying a wildcarded MRI (and thus 3609 policy rule) arriving at an NSLP node can be rejected if the local 3610 policy does not allow the request. For instance, a MRI with IP 3611 addresses set (not wildcarded), transport protocol TCP, and TCP port 3612 numbers completely wildcarded. Now the local policy allows only 3613 requests for TCP with all ports set and not wildcarded. The request 3614 is going to be rejected. 3616 C.2. Mapping to Firewall Rules 3618 This section describes how a NSLP policy rule signaled with a CREATE 3619 message is mapped to a firewall rule. The MRI is set as follows: 3621 o network-layer-version=IPv4 3623 o source-address=192.0.2.100, prefix-length=32 3625 o destination-address=192.0.50.5, prefix-length=32 3627 o IP-protocol=UDP 3629 o L4-source-port=34543, L4-destination-port=23198 3631 The NATFW_EFI object is set to action=allow and sub_ports=0. 3633 The resulting policy rule (firewall rule) to be installed might look 3634 like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198 3636 C.3. Mapping to NAT Bindings 3638 This section describes how a NSLP policy rule signaled with a 3639 EXTERNAL message is mapped to a NAT binding. It is assumed that the 3640 EXTERNAL message is sent by a NI+ being located behind a NAT and does 3641 contain a NATFW_DTINFO object. The MRI is set following using the 3642 signaling destination address, since the IP address of the real data 3643 sender is not known: 3645 o network-layer-version=IPv4 3647 o source-address= 192.168.5.100 3649 o destination-address=SDA 3651 o IP-protocol=UDP 3653 The NATFW_EFI object is set to action=allow and sub_ports=0. The 3654 NATFW_DTINFO object contains these parameters: 3656 o P=1 3658 o dest prefix=0 3660 o protocol=UDP 3662 o dst port number = 20230, src port number=0 3664 o src IP=0.0.0.0 3666 The edge-NAT allocates the external IP 192.0.2.79 and port 45000. 3668 The resulting policy rule (NAT binding) to be installed could look 3669 like: translate udp from any to 192.0.2.79 port=45000 to 3670 192.168.5.100 port=20230 3672 C.4. NSLP Handling of Twice-NAT 3674 The dynamic configuration of twice-NATs requires application level 3675 support, as stated in Section 2.5. The NATFW NSLP cannot be used for 3676 configuring twice-NATs if application level support is needed. 3677 Assuming application level support performing the configuration of 3678 the twice-NAT and the NATFW NSLP being installed at this devices, the 3679 NATFW NSLP must be able to traverse it. The NSLP is probably able to 3680 traverse the twice-NAT, as any other data traffic, but the flow 3681 information stored in the NTLP's MRI will be invalidated through the 3682 translation of source and destination address. The NATFW NSLP 3683 implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP 3684 signaling messages as any other NATFW NSLP node does. For the given 3685 signaling flow, the NATFW NSLP node MUST look up the corresponding IP 3686 address translation and modify the NTLP/NSLP signaling accordingly. 3687 The modification results in an updated MRI with respect to the source 3688 and destination IP addresses. 3690 Appendix D. Protocols Numbers for Testing 3692 NOTE for the RFC editor: This section MUST be removed before 3693 publication. 3695 This section defines temporarily used values of the NATFW NSLP for 3696 testing the different implementations. 3698 Values for the NATFW NSLP message types: 3700 o CREATE: 0x01 3702 o EXTERNAL: 0x02 3704 o RESPONSE: 0x03 3706 o NOTIFY: 0x04 3708 Values for the NSLP object types 3710 o NATFW_LT: 0x00F1 3712 o NATFW_EXTERNAL-IP: 0x00F2 3714 o NATFW_EFI: 0x00F3 3716 o NATFW_INFO: 0x00F4 3718 o NATFW_NONCE: 0x00F5 3720 o NATFW_MSN: 0x00F6 3722 o NATFW_DTINFO: 0x00F7 3724 o NATFW_ICMP_TYPES: 0x00F9 3726 1345 3728 Authors' Addresses 3730 Martin Stiemerling 3731 NEC Europe Ltd. and University of Goettingen 3732 Kurfuersten-Anlage 36 3733 Heidelberg 69115 3734 Germany 3736 Phone: +49 (0) 6221 4342 113 3737 Email: stiemerling@nw.neclab.eu 3739 Hannes Tschofenig 3740 Nokia Siemens Networks 3741 Linnoitustie 6 3742 Espoo 02600 3743 Finland 3745 Phone: +358 (50) 4871445 3746 Email: Hannes.Tschofenig@nsn.com 3747 URI: http://www.tschofenig.com 3749 Cedric Aoun 3750 Paris 3751 France 3753 Email: cedric@caoun.net 3755 Elwyn Davies 3756 Folly Consulting 3757 Soham 3758 UK 3760 Phone: +44 7889 488 335 3761 Email: elwynd@dial.pipex.com 3763 Full Copyright Statement 3765 Copyright (C) The IETF Trust (2008). 3767 This document is subject to the rights, licenses and restrictions 3768 contained in BCP 78, and except as set forth therein, the authors 3769 retain all their rights. 3771 This document and the information contained herein are provided on an 3772 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3773 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3774 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3775 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3776 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3777 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3779 Intellectual Property 3781 The IETF takes no position regarding the validity or scope of any 3782 Intellectual Property Rights or other rights that might be claimed to 3783 pertain to the implementation or use of the technology described in 3784 this document or the extent to which any license under such rights 3785 might or might not be available; nor does it represent that it has 3786 made any independent effort to identify any such rights. Information 3787 on the procedures with respect to rights in RFC documents can be 3788 found in BCP 78 and BCP 79. 3790 Copies of IPR disclosures made to the IETF Secretariat and any 3791 assurances of licenses to be made available, or the result of an 3792 attempt made to obtain a general license or permission for the use of 3793 such proprietary rights by implementers or users of this 3794 specification can be obtained from the IETF on-line IPR repository at 3795 http://www.ietf.org/ipr. 3797 The IETF invites any interested party to bring to its attention any 3798 copyrights, patents or patent applications, or other proprietary 3799 rights that may cover technology that may be required to implement 3800 this standard. Please address the information to the IETF at 3801 ietf-ipr@ietf.org.