idnits 2.17.1 draft-ietf-nsis-nslp-natfw-06.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4225. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1003 has weird spacing: '...creates polic...' == Line 1004 has weird spacing: '...rvation mode ...' == Line 1033 has weird spacing: '...nvolved will ...' == Line 1286 has weird spacing: '... o The data ...' == Line 1328 has weird spacing: '... device respo...' == (5 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * Firewall: Firewalls MUST not change their configuration upon a REA message. They simply MUST forward the message and MUST keep NTLP state. Firewalls that are configured as edge-Firewalls MAY return an error of type 'no NAT here'. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * NAT: NATs check whether the message is received at the external (public in most cases) address or at the internal (private) address. If received at the external address a NF MAY generate a RESPONSE message with an error of type 'REA received from outside' and stop forwarding. If received at the internal address, an IP address/port is reserved. If it is not an edge-NAT, the NSLP message is forwarded further with the translated IP address/port. In the case it is an edge-NAT, the NSLP message is not forwarded any further. The edge-NAT checks whether it is willing to send CREATE messages on behalf on NI+ and if so it checks the DSInfo object. The edge-NAT MAY reject the REA-PROXY request if there is no DSInfo object or if the address information within DSInfo is not valid or too much wildcarded. If accepted a RESPONSE message with the external address and port information is generated. When the edge-NAT accepts it generates a CREATE message as defined in Section 3.3.1. The edge-NAT MUST not generate a CREATE-PROXY message. The edge-NAT MUST refresh the CREATE message session only if a REA-PROXY refresh message has been received first. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * Firewall: Firewalls MUST not change their configuration upon a REA message. They simply MUST forward the message and MUST keep NTLP state. Edge-Firewalls SHOULD reply with an error RESPONSE indicating 'no egde-NAT here'. -- 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 (May 16, 2005) is 6913 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) -- Looks like a reference, but probably isn't: 'Error' on line 1430 -- Looks like a reference, but probably isn't: 'M' on line 2699 -- Looks like a reference, but probably isn't: 'O' on line 2688 -- Looks like a reference, but probably isn't: 'RFC 2113' on line 4083 == Unused Reference: '10' is defined on line 3798, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 3806, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 3823, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 3830, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 3834, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 3873, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-06 -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '8') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '17') (Obsoleted by RFC 3852) == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-vpn-problem-statement-req-02 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '24') (Obsoleted by RFC 5389) == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-07 == Outdated reference: A later version (-05) exists of draft-tschofenig-sip-saml-02 Summary: 5 errors (**), 0 flaws (~~), 22 warnings (==), 14 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 Expires: November 17, 2005 H. Tschofenig 5 Siemens 6 C. Aoun 7 Nortel 8 May 16, 2005 10 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 11 draft-ietf-nsis-nslp-natfw-06 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 17, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This memo defines the NSIS Signaling Layer Protocol (NSLP) for 45 Network Address Translators and Firewalls. This NSLP allows hosts to 46 signal along a data path for Network Address Translators and 47 Firewalls to be configured according to the data flow needs. The 48 network scenarios, problems and solutions for path-coupled Network 49 Address Translator and Firewall signaling are described. The overall 50 architecture is given by the framework and requirements defined by 51 the Next Steps in Signaling (NSIS) working group. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.1 Terminology and Abbreviations . . . . . . . . . . . . . . 7 57 1.2 Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 58 1.3 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 59 1.4 General Scenario for NATFW Traversal . . . . . . . . . . . 11 61 2. Network Deployment Scenarios using NATFW NSLP . . . . . . . 13 62 2.1 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13 63 2.2 NAT with two private Networks . . . . . . . . . . . . . . 14 64 2.3 NAT with Private Network on Sender Side . . . . . . . . . 15 65 2.4 NAT with Private Network on Receiver Side Scenario . . . . 15 66 2.5 Both End Hosts behind twice-NATs . . . . . . . . . . . . . 16 67 2.6 Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 17 68 2.7 IPv4/v6 NAT with two Private Networks . . . . . . . . . . 18 69 2.8 Multihomed Network with NAT . . . . . . . . . . . . . . . 19 70 2.9 Multihomed Network with Firewall . . . . . . . . . . . . . 20 72 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 21 73 3.1 Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 21 74 3.2 Basic protocol overview . . . . . . . . . . . . . . . . . 21 75 3.3 Protocol Operations . . . . . . . . . . . . . . . . . . . 25 76 3.3.1 Creating Sessions . . . . . . . . . . . . . . . . . . 25 77 3.3.2 Reserving External Addresses . . . . . . . . . . . . . 28 78 3.3.3 NATFW Session refresh . . . . . . . . . . . . . . . . 32 79 3.3.4 Deleting Sessions . . . . . . . . . . . . . . . . . . 34 80 3.3.5 Reporting Asynchronous Events . . . . . . . . . . . . 35 81 3.3.6 Query and diagnosis capabilities within the NATFW 82 NSLP protocol . . . . . . . . . . . . . . . . . . . . 35 83 3.3.7 Proxy Mode for Data Receiver behind NAT . . . . . . . 39 84 3.3.8 Proxy Mode for Data Sender behind Middleboxes . . . . 43 85 3.3.9 Proxy Mode for Data Receiver behind Firewall . . . . . 44 86 3.4 Calculation of Session Lifetime . . . . . . . . . . . . . 46 87 3.5 Message Sequencing . . . . . . . . . . . . . . . . . . . . 48 88 3.6 De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 49 89 3.7 Selecting Opportunistic Addresses for REA . . . . . . . . 49 91 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . 51 92 4.1 NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 51 93 4.2 NSLP message types . . . . . . . . . . . . . . . . . . . . 51 94 4.3 NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 52 95 4.3.1 Session Lifetime Object . . . . . . . . . . . . . . . 53 96 4.3.2 External Address Object . . . . . . . . . . . . . . . 53 97 4.3.3 Extended Flow Information Object . . . . . . . . . . . 54 98 4.3.4 Response Code Object . . . . . . . . . . . . . . . . . 55 99 4.3.5 Proxy Support Type Object . . . . . . . . . . . . . . 56 100 4.3.6 Message Sequence Number Object . . . . . . . . . . . . 56 101 4.3.7 Bound Session ID Object . . . . . . . . . . . . . . . 56 102 4.3.8 Data Sender Information Object . . . . . . . . . . . . 57 103 4.3.9 NATFW NF Hop Count Object . . . . . . . . . . . . . . 57 104 4.3.10 Maximum Hops Object . . . . . . . . . . . . . . . . 58 105 4.3.11 Session Status object . . . . . . . . . . . . . . . 58 106 4.3.12 QDRQ type . . . . . . . . . . . . . . . . . . . . . 59 107 4.3.13 QDRQ Response object . . . . . . . . . . . . . . . . 59 108 4.4 Message Formats . . . . . . . . . . . . . . . . . . . . . 60 109 4.4.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . . 60 110 4.4.2 RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . . 60 111 4.4.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 61 112 4.4.4 QDRQ . . . . . . . . . . . . . . . . . . . . . . . . . 61 113 4.4.5 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 62 114 4.4.6 UCREATE . . . . . . . . . . . . . . . . . . . . . . . 62 116 5. NATFW NSLP NTLP Requirements . . . . . . . . . . . . . . . . 63 118 6. NSIS NAT and Firewall Transition Issues . . . . . . . . . . 64 120 7. Security Considerations . . . . . . . . . . . . . . . . . . 65 121 7.1 Trust Relationship and Authorization . . . . . . . . . . . 65 122 7.1.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . 66 123 7.1.2 Intra-Domain Trust Relationship . . . . . . . . . . . 66 124 7.1.3 End-to-Middle Trust Relationship . . . . . . . . . . . 67 125 7.2 Security Threats and Requirements . . . . . . . . . . . . 68 126 7.2.1 Attacks related to authentication and authorization . 68 127 7.2.2 Denial-of-Service Attacks . . . . . . . . . . . . . . 75 128 7.2.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 76 129 7.2.4 Message Modification by non-NSIS on-path node . . . . 77 130 7.2.5 Message Modification by malicous NSIS node . . . . . . 77 131 7.2.6 Session Modification/Deletion . . . . . . . . . . . . 78 132 7.2.7 Misuse of unreleased sessions . . . . . . . . . . . . 81 133 7.2.8 Data traffic injection . . . . . . . . . . . . . . . . 82 134 7.2.9 Eavesdropping and traffic analysis . . . . . . . . . . 84 135 7.3 Security Framework for the NAT/Firewall NSLP . . . . . . . 85 136 7.3.1 Security Protection between neighboring NATFW NSLP 137 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 85 138 7.3.2 Security Protection between non-neighboring NATFW 139 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 85 140 7.3.3 End-to-End Security . . . . . . . . . . . . . . . . . 87 142 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 88 144 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 89 145 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 146 10.1 Normative References . . . . . . . . . . . . . . . . . . 90 147 10.2 Informative References . . . . . . . . . . . . . . . . . 90 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 92 151 A. Firewall and NAT Resources . . . . . . . . . . . . . . . . . 94 152 A.1 Mapping to Firewall Rules . . . . . . . . . . . . . . . . 94 153 A.2 Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 94 154 A.3 Mapping for combined NAT and Firewall . . . . . . . . . . 94 156 B. Problems and Challenges . . . . . . . . . . . . . . . . . . 95 157 B.1 Missing Network-to-Network Trust Relationship . . . . . . 95 158 B.2 Relationship with routing . . . . . . . . . . . . . . . . 96 159 B.3 Affected Parts of the Network . . . . . . . . . . . . . . 96 160 B.4 NSIS backward compatibility with NSIS unaware NAT and 161 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 96 162 B.5 Authentication and Authorization . . . . . . . . . . . . . 97 163 B.6 Directional Properties . . . . . . . . . . . . . . . . . . 97 164 B.7 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 98 165 B.8 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 98 166 B.9 Combining Middlebox and QoS signaling . . . . . . . . . . 98 167 B.10 Inability to know the scenario . . . . . . . . . . . . . 99 169 C. Object ID allocation for testing . . . . . . . . . . . . . . 100 171 D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 101 173 Intellectual Property and Copyright Statements . . . . . . . 102 175 1. Introduction 177 Firewalls and Network Address Translators (NAT) have both been used 178 throughout the Internet for many years, and they will remain present 179 for the foreseeable future. Firewalls are used to protect networks 180 against certain types of attacks from the outside, and in times of 181 IPv4 address depletion, NATs virtually extend the IP address space. 182 Both types of devices may be obstacles to some applications, since 183 they only allow traffic created by a limited set of applications to 184 traverse them (e.g., most HTTP traffic, and client/server 185 applications), due to the relatively static properties of the 186 protocols used. Other applications, such as IP telephony and most 187 other peer-to-peer applications, which have more dynamic properties, 188 create traffic which is unable to traverse NATs and Firewalls 189 unassisted. In practice, the traffic from many applications cannot 190 traverse autonomous Firewalls or NATs, even when they have added 191 functionality which attempts to restore the transparency of the 192 network. 194 Several solutions to enable applications to traverse such entities 195 have been proposed and are currently in use. Typically, application 196 level gateways (ALG) have been integrated with the Firewall or NAT to 197 configure the Firewall or NAT dynamically. Another approach is 198 middlebox communication (MIDCOM, currently under standardization at 199 the IETF). In this approach, ALGs external to the Firewall or NAT 200 configure the corresponding entity via the MIDCOM protocol [5]. 201 Several other work-around solutions are available, including STUN 202 [24] and TURN [27]. However, all of these approaches introduce other 203 problems that are generally hard to solve, such as dependencies on 204 the type of NAT implementation (full-cone, symmetric, ...), or 205 dependencies on certain network topologies. 207 NAT and Firewall (NATFW) signaling shares a property with Quality of 208 Service (QoS) signaling. The signaling of both must reach any device 209 on the data path that is involved in QoS or NATFW treatment of data 210 packets. This means, that for both, NATFW and QoS, it is convenient 211 if signaling travels path-coupled, meaning that the signaling 212 messages follow exactly the same path that the data packets take. 213 RSVP [11] is an example of a current QoS signaling protocol that is 214 path-coupled. 216 This memo defines a path-coupled signaling protocol for NAT and 217 Firewall configuration within the framework of NSIS, called the NATFW 218 NSIS Signaling Layer Protocol (NSLP). The general requirements for 219 NSIS are defined in [3]. The general framework of NSIS is outlined 220 in [2]. It introduces the split between an NSIS transport layer and 221 an NSIS signaling layer. The transport of NSLP messages is handled 222 by an NSIS Network Transport Layer Protocol (NTLP, with GIMPS [1] 223 being the implementation of the abstract NTLP). The signaling logic 224 for QoS and NATFW signaling is implemented in the different NSLPs. 225 The QoS NSLP is defined in [4], while the NATFW NSLP is defined in 226 this memo. 228 The NATFW NSLP is designed to request the dynamic configuration of 229 NATs and/or Firewalls along the data path. Dynamic configuration 230 includes enabling data flows to traverse these devices without being 231 obstructed as well as blocking of particular data flows at upstream 232 firewalls. Enabling data flows requires the loading of firewall pin 233 holes (loading of firewall rules with action allow) and creating NAT 234 bindings. Blocking of data flows requires the loading of firewalls 235 rules with action deny/drop. A simplified example for enabling data 236 flows: A source host sends a NATFW NSLP signaling message towards 237 its data destination. This message follows the data path. Every 238 NATFW NSLP NAT/Firewall along the data path intercepts these 239 messages, processes them, and configures itself accordingly. 240 Afterwards, the actual data flow can traverse every configured 241 Firewall/NAT. 243 It is necessary to distinguish between two different basic scenarios 244 when operating the NATFW NSLP, independent of the type of middlebox 245 to be configured. 247 1. Both data sender and data receiver of the network are NSIS NATFW 248 NSLP aware. This includes the cases where the data sender is 249 logically decomposed from the NSIS initiator or the data receiver 250 logically decomposed from the NSIS receiver, but both sides 251 support NSIS. This scenario assumes deployment of NSIS all over 252 the Internet, or at least at all NATs and firewalls. 254 2. Only one end host is NSIS NATFW NSLP aware, either data receiver 255 or data sender. 257 NATFW NSLP provides three modes to cope with various possible 258 scenarios likely to be encountered before and after widespread 259 deployment of NSIS. Once there is full deployment of NSIS (in the 260 sense that both end hosts support NATFW NSLP signaling), the 261 requisite NAT and firewall state can be created using either just 262 CREATE mode if the data receiver resides in a public addressing 263 realm, or a combination of RESERVE-EXTERNAL-ADDRESS and CREATE modes 264 if the data receiver resides in a private addressing realm and needs 265 to preconfigure the boundary NAT to provide a publically reachable 266 address for use by the data sender. During the introduction of NSIS, 267 it is likely that one or other of the data sender and receiver will 268 not be NSIS capable. In these cases the NATFW NSLP can utilise NSIS 269 aware middleboxes on the path between the sender and receiver to 270 provide proxy NATFW NSLP services. Typically these boxes will be at 271 the boundaries of the realms in which the end hosts are located. If 272 the data receiver is NSIS unaware, the normal modes can be employed 273 but the NSIS signaling terminates at the NSIS aware node 274 topologically closest to the receiver which then acts as a proxy for 275 the receiver. If the data sender is unaware a variant of the 276 RESERVE-EXTERNAL-ADDRESS mode can be used by a data receiver behind a 277 NAT and the specialised UCREATE mode can be used by a data receiver 278 behind a firewall. 280 All modes of operation create NATFW NSLP and NTLP state in NSIS 281 entities. NTLP state allows signaling messages to travel in the 282 forward (downstream) and the reverse (upstream) direction along the 283 path between a NAT/Firewall NSLP sender and a corresponding receiver. 284 NAT bindings and firewall rules are NAT/Firewall specific state. 285 This state is managed using a soft-state mechanism, i.e., it expires 286 unless it is refreshed from time to time. 288 Section 2 describes the network environment for NATFW NSLP signaling, 289 highlighting the trust relationships and authorization required. 290 Section 3 defines the NATFW signaling protocol. Section 4 defines 291 the messages and and message components. In the remaining parts of 292 the main body of the document, Section 6 covers transition issues and 293 Section 7 addresses security considerations. Currently unsolved 294 problems and challenges are listed and discussed in Appendix B. 295 Please note that readers familiar with Firewalls and NATs and their 296 possible location within networks can safely skip Section 2. 298 1.1 Terminology and Abbreviations 300 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 301 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 302 document are to be interpreted as described in RFC 2119. 304 This document uses a number of terms defined in [3]. The following 305 additional terms are used: 307 o Policy rule: A policy rule is "a basic building block of a policy- 308 based system. It is the binding of a set of actions to a set of 309 conditions - where the conditions are evaluated to determine 310 whether the actions are performed" [26]. In the context of NSIS 311 NATFW NSLP, the condition is a specification of a set of packets 312 to which rules are applied. The set of actions always contains 313 just a single element per rule, and is limited to either action 314 "reserved", "deny" or action "allow". 316 o Firewall: A packet filtering device that matches packets against a 317 set of policy rules and applies the actions. In the context of 318 NSIS NATFW NSLP we refer to this device as a Firewall. 320 o Network Address Translator: Network Address Translation is a 321 method by which IP addresses are mapped from one IP address realm 322 to another, in an attempt to provide transparent routing between 323 hosts (see [7]). Network Address Translators are devices that 324 perform this work. 326 o Middlebox: "A middlebox is defined as any intermediate device 327 performing functions other than the normal, standard functions of 328 an IP router on the datagram path between a source host and a 329 destination host" [9]. In the context of this document, the term 330 middlebox refers to Firewalls and NATs only. Other types of 331 middlebox are currently outside of the scope of this document. 333 o Security Gateway: IPsec based gateways. 335 o (Data) Receiver (DR or R): The node in the network that is 336 receiving the data packets of a flow. 338 o (Data) Sender (DS or S): The node in the network that is sending 339 the data packets of a flow. 341 o NATFW NSLP session: An application layer flow of information for 342 which some network control state information is to be manipulated 343 or monitored (as defined in [2]). The control state for NATFW 344 NSLP consists of NSLP state and associated policy rules at a 345 middlebox. 347 o NSIS peer or peer: An NSIS node with which an NSIS adjacency has 348 been created as defined in [1]. 350 o Edge-NAT: An edge-NAT is a NAT device that is reachable from the 351 public Internet and that has a globally routable IP address. 353 o Edge-Firewall: An edge-Firewall is a Firewall device that is 354 located on the demarcation line of an administrative domain. 356 o Public Network: "A Global or Public Network is an address realm 357 with unique network addresses assigned by Internet Assigned 358 Numbers Authority (IANA) or an equivalent address registry. This 359 network is also referred as external network during NAT 360 discussions" [7]. 362 o Private/Local Network: "A private network is an address realm 363 independent of external network addresses. Private network may 364 also be referred alternately as Local Network. Transparent 365 routing between hosts in private realm and external realm is 366 facilitated by a NAT router" [7]. IP address space allocation for 367 private networks is recommended in [25] 369 o Public/Global IP address: An IP address located in the public 370 network according to Section 2.7 of [7]. 372 o Private/Local IP address: An IP address located in the private 373 network according to Section 2.8 of [7]. 375 o Initial CREATE: A CREATE message creating a new session. 377 1.2 Middleboxes 379 The term middlebox covers a range of devices which intercept the flow 380 of packets between end hosts and perform actions other than standard 381 forwarding expected in an IP router. As such, middleboxes fall into 382 a number of categories with a wide range of functionality, not all of 383 which is pertinent to the NATFW NSLP. Middlebox categories in the 384 scope of this memo are Firewalls that filter data packets against a 385 set of filter rules, and NATs that translate packet addresses from 386 one address realm to another address realm. Other categories of 387 middleboxes, such as QoS traffic shapers and security gateways, are 388 out of scope. 390 The term NAT used in this document is a placeholder for a range of 391 different NAT flavors. We consider the following types of NATs: 393 o traditional NAT (basic NAT and NAPT) 395 o Bi-directional NAT 397 o Twice-NAT 399 o Multihomed NAT 401 For definitions and a detailed discussion about the characteristics 402 of each NAT type please see [7]. 404 Both types of middleboxes under consideration here use policy rules 405 to make a decision on data packet treatment. Policy rules consist of 406 a flow identifier which selects the packets to which the policy 407 applies and an associated action; data packets matching the flow 408 identifier are subjected to the policy rule action. A typical flow 409 identifier is the 5-tuple selector which matches the following fields 410 of a packet to configured values: 412 o Source and destination IP addresses 414 o Transport protocol number 415 o Transport source and destination port numbers 417 For further examples of flow identifiers see Section 5.2.2 of [1]. 419 Actions for Firewalls are usually one or more of: 421 o Allow: forward data packet 423 o Deny: block data packet and discard it 425 o Other actions such as logging, diverting, duplicating, etc 427 Actions for NATs include (amongst many others): 429 o Change source IP address and transport port number to a globally 430 routeable IP address and associated port number. 432 o Change destination IP address and transport port number to a 433 private IP address and associated port number. 435 1.3 Non-Goals 437 Traversal of non-NSIS and non-NATFW NSLP aware NATs and Firewalls 438 is outside the scope of this document. 440 Only Firewalls and NATs are considered in this document, any other 441 types of devices, for instance IPSec security gateway, are out of 442 scope. 444 The exact implementation of policy rules and their mapping to 445 firewall rule sets and NAT bindings or sessions at the middlebox 446 is an implementation issue and thus out of scope of this document. 448 Some devices categorized as firewalls only accept traffic after 449 cryptographic verification (i.e., IPsec protected data traffic). 450 Particularly for network access scenarios, either link layer or 451 network layer data protection is common. We do not address these 452 types of devices (referred to as security gateways) since per-flow 453 signaling is typically not used in this environment. 455 Another application, for which NSIS signaling has been proposed 456 but which is out of scope for this document, is discovering 457 security gateways, for the purpose of executing IKE to create an 458 IPsec SA. 460 In mobility scenarios, a common problem is the traversal of a 461 security gateway at the edge of a corporate network. Network 462 administrators allow only authenticated data to enter the network. 463 A problem statement for the traversal of these security gateways 464 in the context of Mobile IP can be found in [22]). This topic is 465 not within the scope of the present document. 467 1.4 General Scenario for NATFW Traversal 469 The purpose of NSIS NATFW signaling is to enable communication 470 between endpoints across networks even in the presence of NAT and 471 Firewall middleboxes. It is assumed that these middleboxes will be 472 statically configured in such a way that NSIS NATFW signaling 473 messages themselves are allowed to traverse them. NSIS NATFW NSLP 474 signaling is used to dynamically install additional policy rules in 475 all NATFW middleboxes along the data path. Firewalls are configured 476 to forward data packets matching the policy rule provided by the NSLP 477 signaling. NATs are configured to translate data packets matching 478 the policy rule provided by the NSLP signaling. However, there is an 479 exception to the primary goal of NSIS NATFW signaling, NSIS NATFW 480 nodes can request blocking of particular data flows instead of 481 enabling these flows at upstream firewalls. 483 The basic high-level picture of NSIS usage is that end hosts are 484 located behind middleboxes, meaning that there is a middlebox on the 485 data path from the end host in a private network and the external 486 network (NAT/FW in Figure 1). Applications located at these end 487 hosts try to establish communication with corresponding applications 488 on other such end hosts. They trigger the NSIS entity at the local 489 host to provide for middlebox traversal along the prospective data 490 path (e.g., via an API call). The NSIS entity in turn uses NSIS 491 NATFW NSLP signaling to establish policy rules along the data path, 492 allowing the data to travel from the sender to the receiver 493 unobstructed. 495 Application Application Server (0, 1, or more) Application 497 +----+ +----+ +----+ 498 | +------------------------+ +------------------------+ | 499 +-+--+ +----+ +-+--+ 500 | | 501 | NSIS Entities NSIS Entities | 502 +-+--+ +----+ +-----+ +-+--+ 503 | +--------+ +----------------------------+ +-----+ | 504 +-+--+ +-+--+ +--+--+ +-+--+ 505 | | ------ | | 506 | | //// \\\\\ | | 507 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 508 | | | | | Internet | | | | | 509 | +--------+ +-----+ +----+ +-----+ | 510 +----+ +----+ |\ | +----+ +----+ 511 \\\\ ///// 512 sender NAT/FW (1+) ------ NATFW (1+) receiver 514 Figure 1: Generic View on NSIS in a NAT / Firewall case 516 For end-to-end NATFW signaling, it is necessary that each firewall 517 and each NAT along the path between the data sender and the data 518 receiver implements the NSIS NATFW NSLP. There might be several NATs 519 and FWs in various possible combinations on a path between two hosts. 520 Section 2 presents a number of likely scenarios with different 521 combinations of NATs and firewalls. 523 2. Network Deployment Scenarios using NATFW NSLP 525 This section introduces several scenarios for middlebox placement 526 within IP networks. Middleboxes are typically found at various 527 different locations, including at Enterprise network borders, within 528 enterprise networks, as mobile phone network gateways, etc. Usually, 529 middleboxes are placed more towards the edge of networks than in 530 network cores. Firewalls and NATs may be found at these locations 531 either alone, or they may be combined; other categories of 532 middleboxes may also be found at such locations, possibly combined 533 with the NATs and/or Firewalls. To reduce the number of network 534 elements needed, combined Firewall and NATs have been made available. 536 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 537 regular data path to the NSIS responder (NR). On the data path, 538 NATFW NSLP signaling messages reach different NSIS nodes that 539 implement the NATFW NSLP. Each NATFW NSLP node processes the 540 signaling messages according to Section 3 and, if necessary, installs 541 policy rules for subsequent data packets. 543 Each of the following sub-sections introduces a different scenario 544 for a different set of middleboxes and their ordering within the 545 topology. It is assumed that each middlebox implements the NSIS 546 NATFW NSLP signaling protocol. 548 2.1 Firewall Traversal 550 This section describes a scenario with Firewalls only; NATs are not 551 involved. Each end host is behind a Firewall. The Firewalls are 552 connected via the public Internet. Figure 2 shows the topology. The 553 part labeled "public" is the Internet connecting both Firewalls. 555 +----+ //----\\ +----+ 556 NI -----| FW |---| |------| FW |--- NR 557 +----+ \\----// +----+ 559 private public private 561 FW: Firewall 562 NI: NSIS Initiator 563 NR: NSIS Responder 565 Figure 2: Firewall Traversal Scenario 567 Each Firewall on the data path must provide traversal service for 568 NATFW NSLP in order to permit the NSIS message to reach the other end 569 host. All Firewalls process NSIS signaling and establish appropriate 570 policy rules, so that the required data packet flow can traverse 571 them. 573 Placing firewalls in a network topology can be done in several very 574 different ways. To distinguish firewalls located at network borders, 575 such as administrative domains, from others located internally, the 576 term edge-Firewall is used. A similar distinction can be made for 577 NATs, with an edge-NAT fulfilling the equivalent role. 579 2.2 NAT with two private Networks 581 Figure 3 shows a scenario with NATs at both ends of the network. 582 Therefore, each application instance, NSIS initiator and NSIS 583 responder, are behind NATs. The outermost NAT, called edge-NAT, at 584 each side is connected to the public Internet. The NATs are 585 generically labeled as MB (for middlebox), since those devices 586 certainly implement NAT functionality, but can implement firewall 587 functionality as well. 589 Only two middleboxes MB are shown in Figure 3 at each side, but in 590 general, any number of MBs on each side must be considered. 592 +----+ +----+ //----\\ +----+ +----+ 593 NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR 594 +----+ +----+ \\----// +----+ +----+ 596 private public private 598 MB: Middlebox 599 NI: NSIS Initiator 600 NR: NSIS Responder 602 Figure 3: NAT with two Private Networks Scenario 604 Signaling traffic from NI to NR has to traverse all the middleboxes 605 on the path, and all the middleboxes must be configured properly to 606 allow NSIS signaling to traverse them. The NATFW signaling must 607 configure all middleboxes and consider any address translation that 608 will result from this configuration in further signaling. The sender 609 (NI) has to know the IP address of the receiver (NR) in advance, 610 otherwise it will not be possible to send any NSIS signaling messages 611 towards the responder. Note that this IP address is not the private 612 IP address of the responder. Instead a NAT binding (including a 613 public IP address) has to be previously installed on the NAT that 614 subsequently allows packets reaching the NAT to be forwarded to the 615 receiver within the private address realm. This generally requires 616 further support from an application layer protocol for the purpose of 617 discovering and exchanging information. The receiver might have a 618 number of ways to learn its public IP address and port number and 619 might need to signal this information to the sender using the 620 application level signaling protocol. 622 2.3 NAT with Private Network on Sender Side 624 This scenario shows an application instance at the sending node that 625 is behind one or more NATs (shown as generic MB, see discussion in 626 Section 2.2). The receiver is located in the public Internet. 628 +----+ +----+ //----\\ 629 NI --| MB |-----| MB |---| |--- NR 630 +----+ +----+ \\----// 632 private public 634 MB: Middlebox 635 NI: NSIS Initiator 636 NR: NSIS Responder 638 Figure 4: NAT with Private Network on Sender Side Scenario 640 The traffic from NI to NR has to traverse middleboxes only on the 641 sender's side. The receiver has a public IP address. The NI sends 642 its signaling message directly to the address of the NSIS responder. 643 Middleboxes along the path intercept the signaling messages and 644 configure the policy rules accordingly. 646 Note that the data sender does not necessarily know whether the 647 receiver is behind a NAT or not, hence, it is the receiving side that 648 has to detect whether itself is behind a NAT or not. As described in 649 Section 3.3.2 NSIS can also provide help for this procedure. 651 2.4 NAT with Private Network on Receiver Side Scenario 653 The application instance receiving data is behind one or more NATs 654 shown as MB (see discussion in Section 2.2). 656 //----\\ +----+ +----+ 657 NI ---| |---| MB |-----| MB |--- NR 658 \\----// +----+ +----+ 660 public private 662 MB: Middlebox 663 NI: NSIS Initiator 664 NR: NSIS Responder 666 Figure 5: NAT with Private Network on Receiver Scenario 668 Initially, the NSIS responder must determine its publicly reachable 669 IP address at the external middlebox and notify the NSIS initiator 670 about this address. One possibility is that an application level 671 protocol is used, meaning that the public IP address is signaled via 672 this protocol to the NI. Afterwards the NI can start its signaling 673 towards the NR and so establish the path via the middleboxes in the 674 receiver side private network. 676 This scenario describes the use case for the RESERVE-EXTERNAL-ADDRESS 677 mode of the NATFW NSLP. 679 2.5 Both End Hosts behind twice-NATs 681 This is a special case, where the main problem arises from the need 682 to detect that both end hosts are logically within the same address 683 space, but are also in two partitions of the address realm on either 684 side of a twice-NAT (see [7] for a discussion of twice-NAT 685 functionality). 687 Sender and receiver are both within a single private address realm 688 but the two partitions potentially have overlapping IP address 689 ranges. Figure 6 shows the arrangement of NATs. This is a common 690 configuration in networks, particularly after the merging of 691 companies that have used the same private address space, resulting in 692 overlapping address ranges. 694 public 695 +----+ +----+ //----\\ 696 NI --| MB |--+--| MB |---| | 697 +----+ | +----+ \\----// 698 | 699 | +----+ 700 +--| MB |------------ NR 701 +----+ 703 private 705 MB: Middlebox 706 NI: NSIS Initiator 707 NR: NSIS Responder 709 Figure 6: NAT to Public, Sender and Receiver on either side of a 710 twice-NAT Scenario 712 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 713 addresses and port numbers on both sides, meaning the mapping of 714 source and destination address at the private and public interfaces. 716 This scenario requires the assistance of application level entities, 717 such as a DNS server. The application level gateways must handle 718 requests that are based on symbolic names, and configure the 719 middleboxes so that data packets are correctly forwarded from NI to 720 NR. The configuration of those middleboxes may require other 721 middlebox communication protocols, such as MIDCOM [5]. NSIS 722 signaling is not required in the twice-NAT only case, since 723 middleboxes of the twice-NAT type are normally configured by other 724 means. Nevertheless, NSIS signaling might by useful when there are 725 also Firewalls on path. In this case NSIS will not configure any 726 policy rule at twice-NATs, but will configure policy rules at the 727 Firewalls on the path. The NSIS signaling protocol must be at least 728 robust enough to survive this scenario. This requires that twice- 729 NATs must implement the NATFW NSLP also and participate in NATFW 730 sessions but they do not change the configuration of the NAT, i.e., 731 they only read the address mapping information out of the NAT and 732 translate the Message Routing Information (MRI, [1])within the NSLP 733 and NTLP accordingly. 735 2.6 Both End Hosts Behind Same NAT 737 When NSIS initiator and NSIS responder are behind the same NAT (thus 738 being in the same address realm, see Figure 7), they are most likely 739 not aware of this fact. As in Section 2.4 the NSIS responder must 740 determine its public IP address in advance and transfer it to the 741 NSIS initiator. Afterwards, the NSIS initiator can start sending the 742 signaling messages to the responder's public IP address. During this 743 process, a public IP address will be allocated for the NSIS initiator 744 at the same middlebox as for the responder. Now, the NSIS signaling 745 and the subsequent data packets will traverse the NAT twice: from 746 initiator to public IP address of responder (first time) and from 747 public IP address of responder to responder (second time). This is 748 the worst case in which both sender and receiver obtain a public IP 749 address at the NAT, and the communication path is certainly not 750 optimal in this case. 752 NI public 753 \ +----+ //----\\ 754 +-| MB |----| | 755 / +----+ \\----// 756 NR 757 private 759 MB: Middlebox 760 NI: NSIS Initiator 761 NR: NSIS Responder 763 Figure 7: NAT to Public, Both Hosts Behind Same NAT 765 The NSIS NATFW signaling protocol should support mechanisms to detect 766 such a scenario. 768 2.7 IPv4/v6 NAT with two Private Networks 770 This scenario combines the use case described in Section 2.2 with the 771 IPv4 to IPv6 transition scenario involving address and protocol 772 translation, i.e., using Network Address and Protocol Translators 773 (NAT-PT, [8]). 775 The difference from the other scenarios is the use of IPv6 to IPv4 776 (and vice versa) address and protocol translation. Additionally, the 777 base NTLP must support transport of messages in mixed IPv4 and IPv6 778 networks where some NSIS peers provide translation. 780 +----+ +----+ //---\\ +----+ //---\\ +----+ +----+ 781 NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR 782 +----+ +----+ \\---// +----+ \\---// +----+ +----+ 784 private public public private 785 IPv4 IPv6 787 MB: Middlebox 788 NI: NSIS Initiator 789 NR: NSIS Responder 791 Figure 8: IPv4/v6 NAT with two Private Networks 793 This scenario needs the same type of application level support as 794 described in Section 2.5, and so the issues relating to twice-NATs 795 apply here as well. 797 2.8 Multihomed Network with NAT 799 The previous sub-sections sketched network topologies where several 800 NATs and/or Firewalls are ordered sequentially on the path. This 801 section describes a multihomed scenario with two NATs placed on 802 alternative paths to the public network. 804 +----+ 805 NI -------| MB |\ 806 \ +----+ \ //---\\ 807 \ -| |-- NR 808 \ \\---// 809 \ +----+ | 810 --| MB |-------+ 811 +----+ 812 private 813 private public 815 MB: Middlebox 816 NI: NSIS Initiator 817 NR: NSIS Responder 819 Figure 9: Multihomed Network with Two NATs 821 Depending on the destination or load balancing requirements, either 822 one or the other middlebox is used for the data flow. Which 823 middlebox is used depends on local policy or routing decisions. 824 NATFW NSLP must be able to handle this situation properly, see 825 Section 3.3.2 for an expanded discussion of this topic with respect 826 to NATs. 828 2.9 Multihomed Network with Firewall 830 This section describes a multihomed scenario with two firewalls 831 placed on alternative paths to the public network (Figure 10). The 832 routing in the private and public network decided which firewall is 833 being taken for data flows. Depending on the data flow's direction, 834 either outbound or inbound, a different firewall could be traversed. 835 This is a challenge for a certain mode of the NATFW NSLP where the 836 NSIS responder is located behind these firewalls within the private 837 network: the UCREATE mode. The UCREATE mode is used to block a 838 particular data flow on an upstream firewall. NSIS must route the 839 UCREATE mode message upstream from NR to NI without probably knowing 840 the data traffic's subsequent path will take from NI to NR. 842 +----+ 843 NR -------| MB |\ 844 \ +----+ \ //---\\ 845 \ -| |-- NI 846 \ \\---// 847 \ +----+ | 848 --| MB |-------+ 849 +----+ 850 private 851 private public 853 MB: Middlebox 854 NI: NSIS Initiator 855 NR: NSIS Responder 857 Figure 10: Multihomed Network with Two Firewalls 859 3. Protocol Description 861 This section defines messages, objects, and protocol semantics for 862 the NATFW NSLP. Section 3.1 introduces the base element of a NSLP 863 session , the policy rule. Section 3.2 introduces the protocol and 864 the protocol behavior is defined in Section 3.3. Section 4 defines 865 the syntax of the messages and objects. 867 3.1 Policy Rules 869 Policy rules, bound to a session, are the building block of middlebox 870 devices considered in the NATFW NSLP. For Firewalls the policy rule 871 usually consists of a 5-tuple, source/destination addresses, 872 transport protocol, and source/destination port numbers, plus an 873 action, such as allow or deny. For NATs the policy rule consists of 874 action 'translate this address' and further mapping information, that 875 might be, in the simplest case, internal IP address and external IP 876 address. 878 Policy rules are usually carried in one piece in signaling 879 applications. In NSIS the policy rule is divided into the flow 880 identifier, an allow or deny action, and additional information. The 881 filter specification is carried within NTLP's message routing 882 information (MRI) and additional information, including the 883 specification of the action, is carried in NSLP's objects. 884 Additional information is, for example, the lifetime of a policy rule 885 or session. 887 3.2 Basic protocol overview 889 The NSIS NATFW NSLP is carried over the NSIS Transport Layer Protocol 890 (NTLP) defined in [1]. The interworking with the NTLP and other 891 components is shown in Figure 56. NATFW NSLP messages are initiated 892 by the NSIS initiator (NI), handled by NSIS forwarders (NF) and 893 finally processed by the NSIS responder (NR). It is required that at 894 least NI and NR implement this NSLP, intermediate NFs only implement 895 this NSLP when they provide relevant middlebox functions. NSIS 896 forwarders that do not have any NATFW NSLP functions just forward 897 these packets when they have no interest. 899 A Data Sender (DS), intending to send data to a Data Receiver (DR) 900 must first initiate NATFW NSLP signaling. This causes the NI 901 associated with the data sender (DS) to launch NSLP signaling towards 902 the address of data receiver DR (see Figure 11). Although it is 903 expected that the DS and the NATFW NSLP NI will usually reside on the 904 same host, this specification does not rule out scenarios where the 905 DS and NI reside on different hosts, the so-called proxy mode (see 906 Section 1.) 907 +-------+ +-------+ +-------+ +-------+ 908 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 909 | |--->| NF1 |--->| NF2 |--->| | 910 +-------+ +-------+ +-------+ +-------+ 912 ========================================> 913 Data Traffic Direction 915 ---> : NATFW NSLP request signaling 916 ~~~> : NATFW NSLP response signaling 917 DS/NI : Data sender and NSIS initiator 918 DR/NR : Data receiver and NSIS responder 919 MB1 : Middlebox 1 and NSIS forwarder 1 920 MB2 : Middlebox 2 and NSIS forwarder 2 922 Figure 11: General NSIS signaling 924 +-------+ +-------+ +-------+ +-------+ 925 | DS/NI |<~~~| MB1/ |<~~~| NR | | DR | 926 | |--->| NF1 |--->| | | | 927 +-------+ +-------+ +-------+ +-------+ 929 ========================================> 930 Data Traffic Direction 932 ---> : NATFW NSLP request signaling 933 ~~~> : NATFW NSLP response signaling 934 DS/NI : Data sender and NSIS initiator 935 DR/NR : Data receiver and NSIS responder 936 MB1 : Middlebox 1 and NSIS forwarder 1 937 MB2 : Middlebox 2 and NSIS forwarder 2 939 Figure 12: A NSIS proxy mode signaling 941 The sequence of NSLP events is as follows: 943 o NSIS initiators generate NATFW NSLP request messages and send 944 those towards the NSIS responder. Note, that the NSIS initiator 945 may not necessarily be the data sender but may be the data 946 receiver, for instance, when using the RESERVE-EXTERNAL-ADDRESS 947 message. 949 o NSLP request messages are processed each time a NF with NATFW NSLP 950 support is traversed. These nodes process the message, check 951 local policies for authorization and authentication, possibly 952 create policy rules, and forward the signaling message to the next 953 NSIS node. The request message is forwarded until it reaches the 954 NSIS responder. 956 o NSIS responders will check received messages and process them if 957 applicable. NSIS responders generate response messages and send 958 them hop-by-hop back to the NI via the same chain of NFs 959 (traversal of the same NF chain is guaranteed through the 960 established reverse message routing state in the NTLP). Note, 961 that NSIS responder may not necessarily be the data receiver but 962 may be any intermediate NSIS node that terminates the forwarding, 963 for example, in a proxy mode case where an edge-NAT is replying to 964 requests 966 o The response message is processed at each NF implementing the 967 NATFW NSLP. 969 o Once the NI has received a successful response, the data sender 970 can start sending its data flow to the data receiver. 972 Because NATFW NSLP signaling follows the data path from DS to DR, 973 this immediately enables communication between both hosts for 974 scenarios with only Firewalls on the data path or NATs on sender 975 side. For scenarios with NATs on the receiver side certain problems 976 arise, as described in Section 2. 978 When the NR and the NI are located in different address realms and 979 the NR is located behind a NAT, the NI cannot signal to the NR 980 directly. The DR and NR are not reachable from the NIs using the 981 private address of the NR and thus NATFW signaling messages cannot be 982 sent to the NR/DR's address. Therefore, the NR must first obtain a 983 NAT binding that provides an address that is reachable for the NI. 984 Once the NR has acquired a public IP address, it forwards this 985 information to the DS via a separate protocol (such as SDP within 986 SIP). This application layer signaling, which is out of scope of the 987 NATFW NSLP, may involve third parties that assist in exchanging these 988 messages. 990 NATFW NSLP signaling supports this scenario by using the RESERVE- 991 EXTERNAL-ADDRESS mode of operation 993 1. The NR acquires a public address by signaling on the reverse path 994 (NR towards NI) and thus making itself available to other hosts. 996 This process of acquiring a public addresses is called 997 reservation. During this process the DR reserves publicly 998 reachable addresses and ports suitable for NATFW NSLP signaling, 999 but data traffic will not be allowed to use this address/port 1000 initially. 1002 2. The NI signals directly to the NR as the NI would do if there is 1003 no NAT in between, and creates policy rules at middleboxes. 1004 Note, that the reservation mode will only allow the forwarding 1005 of signaling messages but not data flow packets. Data flow 1006 packets will be 'activated' by the signaling from NI towards NR. 1007 The RESERVE-EXTERNAL-ADDRESS mode of operation is detailed in 1008 Section 3.3.2 1010 The above usage assumes that both ends of a communication support 1011 NSIS but fail when NSIS is only deployed at one end of the network. 1012 In this case only the receiving or sending side are NSIS aware and 1013 not both at the same time (see also Section 1). NATFW NSLP supports 1014 this scenario by using a proxy mode, as described in Section 3.3.7 1015 and Section 3.3.8. 1017 The basic functionality of the NATFW NSLP provides for opening 1018 firewall pin holes and creating NAT bindings to enable data flows to 1019 traverse these devices. Firewalls are expected to work on a deny-all 1020 policy, meaning that traffic that does not explicitly match any 1021 firewall filter rule will be blocked. In contrast, the normal 1022 behavior of NATs is to block all traffic that does not match any 1023 already configured/installed binding or session. However, in some 1024 scenarios it is required to support firewalls having allow-all 1025 policies, allowing data traffic to traverse unless it is blocked 1026 explicitly. Data receivers can utilize NATFW NSLP's UCREATE message 1027 to install policy rules at upstream firewalls to block unwanted 1028 traffic. 1030 The protocol works on a soft-state basis, meaning that whatever state 1031 is installed or reserved on a middlebox will expire, and thus be de- 1032 installed/ forgotten after a certain period of time. To prevent 1033 this, the NATFW nodes involved will have to specifically request a 1034 session extension. An explicit NATFW NSLP state deletion capability 1035 is also provided by the protocol. 1037 Middleboxes should return an error in case of a failure, such that 1038 appropriate actions can be taken; this ability would allow debugging 1039 and error recovery. Error messages could be sent upstream (for 1040 errors related to received messages as well as asynchronous error 1041 notification messages) towards the NI as well as downstream towards 1042 the NR (in the case of asynchronous error notification messages). 1044 The next sections define the NATFW NSLP message types and formats, 1045 protocol operations, and policy rule operations. 1047 3.3 Protocol Operations 1049 This section defines the protocol operations including, how to create 1050 sessions, maintain them, and how to reserve addresses. All the NATFW 1051 NSLP protocol messages require C-mode handling by the NTLP and cannot 1052 be piggybacked into D-mode NTLP messages used during the NTLP path 1053 discovery/refresh phase. The usage of the NTLP by protocol messages 1054 is described in detail in Section 4. 1056 The protocol uses six messages: 1058 o CREATE: a request message used for creating, changing, refreshing 1059 and deleting NATFW NSLP sessions. 1061 o RESERVE-EXTERNAL-ADDRESS (REA): a request message used for 1062 reserving an external address and probably port number, depending 1063 on the type of NAT. 1065 o Query and Diagnosis ReQuest (QDRQ): a request message used by 1066 authorized NATFW NEs for querying and diagnosing installed NATFW 1067 states 1069 o NOTIFY: an asynchronous message used by NATFW NEs to alert 1070 upstream and/or downstream NATFW NEs about specific events 1071 (especially failures). 1073 o UCREATE: a request message used by data receivers to instruct 1074 upstream firewalls to block data traffic. 1076 o RESPONSE: used as a response to CREATE, REA, UCREATE and QUERY 1077 messages with Success or Error information 1079 3.3.1 Creating Sessions 1081 Allowing two hosts to exchange data even in the presence of 1082 middleboxes is realized in the NATFW NSLP by the CREATE request 1083 message. The data sender generates a CREATE message as defined in 1084 Section 4.4.1 and hands it to the NTLP. The NTLP forwards the whole 1085 message on the basis of the message routing information towards the 1086 NR. Each NSIS forwarder along the path that implements NATFW NSLP, 1087 processes the NSLP message. Forwarding is thus managed NSLP hop-by- 1088 hop but may pass transparently through NSIS forwarders which do not 1089 contain NATFW NSLP functionality and non-NSIS aware routers between 1090 NSLP hop waypoints. When the message reaches the NR, the NR can 1091 accept the request or reject it. The NR generates a response to the 1092 request and this response is transported hop-by-hop towards the NI. 1093 NATFW NSLP forwarders may reject requests at any time. Figure 13 1094 sketches the message flow between NI (DS), a NF (NAT), and NR (DR). 1096 NI Private Network NF Public Internet NR 1097 | | | 1098 | CREATE | | 1099 |----------------------------->| | 1100 | | | 1101 | RESPONSE[Error](if necessary)| | 1102 |<-----------------------------| CREATE | 1103 | |--------------------------->| 1104 | | | 1105 | | RESPONSE[Success/Error] | 1106 | RESPONSE[Success/Error] |<---------------------------| 1107 |<-----------------------------| | 1108 | | | 1109 | | | 1111 Figure 13: Creation message flow 1113 Since the CREATE message is used for several purposes within the 1114 lifetime of a session, there are several processing rules for NATFW 1115 NEs when generating and receiving CREATE messages. The different 1116 processing methods depend not only on the function which the CREATE 1117 is performing (to create, modify, refresh or delete a session) but 1118 also on the node at which the processing happens. For an initial 1119 CREATE message, the CREATE message creating a new NSIS session, the 1120 processing of CREATE messages is different for every NSIS node type: 1122 o NSLP initiator: NI only generates initial CREATE messages and 1123 hands them over to the NTLP. After receiving a successful 1124 response, the data path is configured and the DS can start 1125 sending its data to the DR. After receiving an 'error' response 1126 message the NI MAY try to generate the CREATE message again or 1127 give up and report the failure to the application, depending on 1128 the error condition. 1130 o NATFW NSLP forwarder: NFs receiving an initial CREATE message 1131 MUST first check authentication and authorization before any 1132 further processing is executed. The NF SHOULD check with its 1133 local policies if it can accept the desired policy rule given the 1134 combination of the NTLP's 'Message-Routing-Information' (MRI) [1] 1135 (the flow description information) and the CREATE payload 1136 (behavior to be enforced on the packet stream). An initial CREATE 1137 is distinguished from subsequent CREATE messages by the absence of 1138 existing NSLP session state related to the same session ID or the 1139 same MRI. The NSLP message processing depends on the middlebox 1140 type: 1142 * NAT: When the initial CREATE message is received at the public 1143 side of the NAT, it looks for a reservation made in advance, by 1144 using a REA message Section 3.3.2, that matches the destination 1145 address/port of the MRI provided by the NTLP. If no 1146 reservation had been made in advance the NSLP MAY return an 1147 error response message of type 'no reservation found' and 1148 discard the request. If there is a reservation, NSLP stores 1149 the data sender's address as part of the policy rule to be 1150 loaded and forwards the message with the address set to the 1151 internal (private in most cases) address of the next NSIS node. 1152 When the initial CREATE message, for a new session, is received 1153 at the private side the NAT binding is reserved, but not 1154 activated. The NSLP message is forwarded to the next NSIS hop 1155 with source address set to the NAT's external address from the 1156 newly reserved binding. 1158 * Firewall: When the initial CREATE message is received the NSLP 1159 just remembers the requested policy rule, but does not install 1160 any policy rule. Afterwards, the message is forwarded to the 1161 next NSLP hop. There is a difference between requests from 1162 trusted (authorized NIs) and un-trusted (un-authorized NIs); 1163 requests from trusted NIs will be pre-authorized, whereas 1164 requests from un-trusted NIs will not be pre-authorized. This 1165 difference is required to speed-up the protocol operations as 1166 well as for proxy mode usage (please refer to Section 3.3.7 and 1167 [13]). 1169 * Combined NAT and Firewall: Processing at combined Firewall and 1170 NAT middleboxes is the same as in the NAT case. No policy 1171 rules are installed. Implementations MUST take into account 1172 the order of packet processing in the Firewall and NAT 1173 functions within the device. This will be referred to as 1174 'order of functions' and is generally different depending on 1175 whether the packet arrives at the external or internal side of 1176 the middlebox. 1178 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1179 with a 'success' (response object has success information) 1180 RESPONSE message if they accept the CREATE request message and the 1181 authorization and authentication checks have been successful. 1182 Otherwise they SHOULD generate a RESPONSE message with an error 1183 code. RESPONSE messages are sent back NSLP hop-by-hop towards the 1184 NI, independently of the response codes, either success or error. 1186 Policy rules at middleboxes MUST be only installed upon receiving a 1187 successful response. This is a countermeasure to several problems, 1188 for example wastage of resources due to loading policy rules at 1189 intermediate NF when the CREATE message does not reach the final NR 1190 for some reason. 1192 3.3.2 Reserving External Addresses 1194 NSIS signaling is intended to travel end-to-end, even in the presence 1195 of NATs and Firewalls on-path. This works well in cases where the 1196 data sender is itself behind a NAT as described in Section 3.3.1. 1197 For scenarios where the data receiver is located behind a NAT and 1198 needs to receive data flows from outside its own network (see 1199 Figure 5) the problem is more troublesome. NSIS signaling, as well 1200 as subsequent data flows, are directed to a particular destination IP 1201 address that must be known in advance and reachable. 1203 +-------------+ AS-Data Receiver Communication 1204 +-------->| Application |<-----------------------------+ 1205 | | Server | | 1206 | +-------------+ | 1207 | IP(R-NAT_B) | 1208 | NSIS Signaling Message +-------+--+ 1209 | +------------------------------------------>| NAT/NAPT | 1210 | | | B | 1211 | | +-------+--+ 1212 | | | 1213 AS-Data| | | 1214 Receiver| | +----------+ | 1215 Comm.| | | NAT/NAPT | | 1216 | | | A | | 1217 | | +----------+ | 1218 | | | 1219 | | | 1220 | | | 1221 | | | 1222 v | IP(R) v 1223 +--------+ +---------+ 1224 | Data | | Data | 1225 | Sender | | Receiver| 1226 +--------+ +---------+ 1227 Figure 14: The Data Receiver behind NAT problem 1229 Figure 14 describes a typical message communication in a peer-to-peer 1230 networking environment whereby the two end points learn of each 1231 others existence with the help of a third party (referred to as an 1232 Application Server). Communication between the application server 1233 and each of the two end points (data sender and data receiver) 1234 enables the two end hosts to learn each other's IP addresses. The 1235 approach described in this memo supports this peer-to-peer approach, 1236 but is not limited to it. 1238 Some sort of communication between the data sender/data receiver and 1239 a third party is typically necessary (independently of whether NSIS 1240 is used). NSIS signaling messages cannot be used to communicate the 1241 relevant application level end point identifiers (in the generic case 1242 at least) as a replacement for communication with the application 1243 server. 1245 If the data receiver is behind a NAT then an NSIS signaling message 1246 will be addressed to the IP address allocated at the NAT (assuming 1247 one had already been allocated). If no corresponding NSIS NAT 1248 Forwarding State at NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) 1249 then the signaling message will terminate at the NAT device (most 1250 likely without generating a proper response message). The signaling 1251 message transmitted by the data sender cannot install the NAT binding 1252 or NSIS NAT Forwarding State "on-the-fly" since this would assume 1253 that the data sender knows the topology at the data receiver side 1254 (i.e., the number and the arrangement of the NAT and the private IP 1255 address(es) of the data receiver). The primary goal of path-coupled 1256 middlebox communication was not to avoid end hosts learning and 1257 preserving this type of topology knowledge. Data receivers behind a 1258 NAT must first reserve an external IP address (probably port number 1259 too). 1261 Public Internet Private Address 1262 Space 1263 Edge 1264 NI(DS) NAT NAT NR(DR) 1265 NR+ NI+ 1266 | | | | 1267 | | | | 1268 | | | | 1269 | | REA | REA | 1270 | |<----------------------|<----------------------| 1271 | | | | 1272 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1273 | |---------------------->|---------------------->| 1274 | | | | 1275 | | | | 1277 ============================================================> 1278 Data Traffic Direction 1280 Figure 15: Reservation message flow 1282 Figure 15 shows the message flow for reserving an external address/ 1283 port at a NAT. In this case the roles of the different NSIS entities 1284 are: 1286 o The data receiver (DR) for the anticipated data traffic is the 1287 NSIS initiator (NI+) for the RESERVE-EXTERNAL-ADDRESS (REA) 1288 message, but becomes the NSIS responder (NR) for following CREATE 1289 messages. 1291 o The actual data sender (DS) will be the NSIS initiator (NI) for 1292 later CREATE messages and may be the NSIS target of the signaling 1293 (NR+). 1295 o The actual target of the REA message, the Opportunistic Address 1296 (OA) is an arbitrary address, that would force the message to get 1297 intercepted by the far outmost NAT in the network. The 1298 Opportunistic Address is shown as NR+. 1300 The NI+ (could be on the data receiver DR or on any other host within 1301 the private network) sends a the REA message targeted to the 1302 Opportunistic Address (OA defined earlier). The OA selection for 1303 this message is discussed in Section 3.7. The message routing for 1304 the REA message is in the reverse direction to the normal message 1305 routing used for path-coupled signaling where the signaling is sent 1306 downstream (as opposed to upstream in this case). When establishing 1307 NAT bindings (and NSIS session state) the direction does not matter 1308 since the data path is modified through route pinning due to the 1309 external NAT address. Subsequent NSIS messages (and also data 1310 traffic) will travel through the same NAT boxes. 1312 NI+ may include a data sender's address information object (DSInfo) 1313 if they are aware about the data sender. The DSInfo object is used 1314 by the edge-NAT to limit the possible NI addresses to one address. A 1315 NI+ can specify a specific IP address and port from where the 1316 subsequent NSIS signaling must be originated. 1318 The REA signaling message creates NSIS NAT session state at any 1319 intermediate NSIS NAT peer(s) encountered. Furthermore it has to be 1320 ensured that the edge-NAT device is discovered as part of this 1321 process. The end host cannot be assumed to know this device - 1322 instead the NAT box itself is assumed to know that it is located at 1323 the outer perimeter of the private network addressing realm. 1324 Forwarding of the REA message beyond this entity is not necessary, 1325 and should be prohibited as it provides information on the 1326 capabilities of internal hosts. 1328 The edge-NAT device responds to the REA message with a RESPONSE 1329 message containing a success object carrying the public reachable IP 1330 address/port number. 1332 Processing of REA messages is specific to the NSIS node type: 1334 o NSLP initiator: NI+ only generate REA messages and should never 1335 receive them. When the data sender's address information is known 1336 in advance the NI+ MAY include a DSInfo object in the REA message. 1337 When the data sender's IP address is not known, NI+s MUST NOT 1338 include a DSInfo object. 1340 o NSLP forwarder: NSLP forwarders receiving REA messages MUST first 1341 check authentication and authorization before any further 1342 processing is executed. The NF SHOULD check with its local 1343 policies if it can accept the desired policy rule given by NTLP's 1344 message routing information (MRI). Further processing depends on 1345 the middlebox type: 1347 * NAT: NATs check whether the message is received at the 1348 external (public in most cases) address or at the internal 1349 (private) address. If received at the external address a NF 1350 MAY generate a RESPONSE message with an error of type 'REA 1351 received from outside'. If received at the internal address, 1352 an IP address/port is reserved. In the case it is an edge-NAT, 1353 the NSLP message is not forwarded any further and a RESPONSE 1354 message with the external address and port information is 1355 generated. If it is not an edge-NAT, the NSLP message is 1356 forwarded further with the translated IP address/port. The 1357 edge-NAT MAY reject REA messages not carrying a DSInfo object 1358 or if the address information within this object is invalid or 1359 too much wildcarded. 1361 * Firewall: Firewalls MUST not change their configuration upon a 1362 REA message. They simply MUST forward the message and MUST 1363 keep NTLP state. Firewalls that are configured as edge- 1364 Firewalls MAY return an error of type 'no NAT here'. 1366 * Combined NAT and Firewall: Processing at combined Firewall and 1367 NAT middleboxes is the same as in the NAT case. 1369 o NSLP receiver: This type of message should never be received by 1370 any NR+ and it SHOULD be discarded silently. 1372 Processing of a RESPONSE message with an external address object is 1373 different for every NSIS node type: 1375 o NSLP initiator: Upon receiving a RESPONSE message with an 1376 external address object, the NI+ can use the IP address and port 1377 pairs carried for further application signaling. 1379 o NSLP forwarder: NFs simply forward this message as long as they 1380 keep state for the requested reservation. 1382 o NSIS responder: This type of message should never be received by 1383 an NR and it SHOULD be discarded silently. 1385 o Edge-NATs: This type of message should never be received by any 1386 Edge-NAT and it SHOULD be discarded silently. 1388 Reservations made with REA MUST be enabled by a subsequent CREATE 1389 message. Without using CREATE (Section 3.3.1 or REA in proxy mode 1390 Section 3.3.7 no data traffic will be forwarded to DR beyond the 1391 edge-NAT. REA is just taking care about enabling the forwarding of 1392 subsequent CREATE messages traveling towards the NR. Correlation of 1393 incoming CREATE messages to REA reservation states is described in 1394 Section 3.6 1396 EDITOR's note: How long REA session must be kept alive? REA sessions 1397 are not replaced by CREATE sessions but rather handled as all other 1398 sessions too, meaning they must be either teared down or left to be 1399 timeout. 1401 3.3.3 NATFW Session refresh 1403 NATFW NSLP sessions are maintained on a soft-state basis. After a 1404 specified timeout, sessions and corresponding policy rules are 1405 removed automatically by the middlebox, if they are not refreshed. 1406 Soft-state is created by CREATE, REA, and UCREATE and the maintenance 1407 of this state must be done by these messages. State created by 1408 CREATE must be maintained by CREATE, state created by REA must be 1409 maintained by REA, and state created by UCREATE must be maintained by 1410 UCREATE. Refresh messages, either CREATE/REA/UCREATE, are messages 1411 carrying the exact MRI and session ID as the initial message and a 1412 lifetime object with a lifetime greater than zero. Every refresh 1413 request message MUST be acknowledged by an appropriate response 1414 message generated by the NR. This response message is routed back 1415 towards the NI, to allow the intermediate NFs to propose a refresh 1416 period that would align with their local policies. The NI sends 1417 refresh messages destined for the NR. Upon reception by each NSIS 1418 forwarder, the state for the given session ID is extended by the 1419 session refresh period, a period of time calculated based on a 1420 proposed refresh message period. The lifetime extension of a session 1421 is calculated as current local time plus proposed lifetime value 1422 (session refresh period). Section 3.4 defines the process of 1423 calculating lifetimes in detail. 1425 NI Public Internet NAT Private address NR 1426 | | space | 1427 | CREATE[lifetime > 0] | | 1428 |----------------------------->| | 1429 | | | 1430 | RESPONSE[Error] (if needed) | | 1431 |<-----------------------------| CREATE[lifetime > 0] | 1432 | |--------------------------->| 1433 | | | 1434 | | RESPONSE[Success/Error] | 1435 | RESPONSE[Success/Error] |<---------------------------| 1436 |<-----------------------------| | 1437 | | | 1438 | | | 1440 Figure 16: State Refresh Message Flow, CREATE as example 1442 Processing of session refresh CREATE/REA/UCREATE messages is 1443 different for every NSIS node type: 1445 o NSLP initiator: The NI can generate session refresh CREATE/REA/ 1446 UCREATE messages before the session times out. The rate at which 1447 the refresh CREATE/REA/UCREATE messages are sent and their 1448 relation to the session state lifetime are further discussed in 1449 Section 3.4. The message routing information and the extended 1450 flow information object MUST be set equal to the values of the 1451 initial request message. 1453 o NSLP forwarder: NSLP forwarders receiving session refresh messages 1454 MUST first check authentication and authorization before any 1455 further processing is executed. The NF SHOULD check with its 1456 local policies if it can accept the desired lifetime extension for 1457 the session referred by the session ID. Processing of this 1458 message is independent of the middlebox type. 1460 o NSLP responder: NRs accepting a session refresh CREATE/REA/UCREATE 1461 message generate a RESPONSE message with response object set to 1462 success. NRs MUST check for authorization and authentication. 1464 3.3.4 Deleting Sessions 1466 NATFW NSLP sessions may be deleted at any time. NSLP initiators can 1467 trigger this deletion by using a CREATE, REA, or UCREATE messages 1468 with a lifetime value set to 0, as shown in Figure 17. 1470 NI Public Internet NAT Private address NR 1471 | | space | 1472 | CREATE[lifetime=0] | | 1473 |----------------------------->| | 1474 | | | 1475 | | CREATE[lifetime=0] | 1476 | |--------------------------->| 1477 | | | 1479 Figure 17: Delete message flow, CREATE as example 1481 NSLP nodes receiving this message MUST first check for authorization 1482 and authentication and afterwards MUST delete the session 1483 immediately. Policy rules associated with this particular session 1484 MUST be deleted immediately. This message is forwarded until it 1485 reaches the final NR. The CREATE/REA/UCREATE request message with a 1486 lifetime value of 0, does not generate any response, neither positive 1487 nor negative, since there is no NSIS state left at the nodes along 1488 the path. 1490 3.3.5 Reporting Asynchronous Events 1492 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 1493 to report asynchronous events to other NATFW NSLP nodes, especially 1494 to allow reporting back to the NATFW NSLP initiator. Such 1495 asynchronous events may be premature session termination, changes in 1496 local policies, routing change or any other reason that indicates 1497 change of the NATFW NSLP session state. Currently, asynchronous 1498 session termination, re-authorization required and route change 1499 detected are the only events that are defined, but other events may 1500 be defined in later versions of this memo. One or several events 1501 could be reported within the NOTIFY message. 1503 NFs and NRs may generate NOTIFY messages upon asynchronous events, 1504 with a response object indicating the reason of the event and a 1505 corresponding session ID. NOTIFY messages are sent hop-by-hop 1506 upstream towards NI until they reach NI. 1508 Processing is different for every NATFW NSLP node type and depends on 1509 the notified events: 1511 o NSLP initiator: NIs receiving NOTIFY messages MUST first check for 1512 authentication and authorization. After successfully doing so, 1513 NIs analyze the notified event(s) and behave appropriately based 1514 on the event type. Section 4.3.4 discusses the required behavior 1515 for each notified event. NIs MUST NOT generate NOTIFY messages. 1517 o NSLP forwarder: NFs receiving NOTIFY messages MUST first check for 1518 authentication and authorization and MUST only accept NOTIFY 1519 messages from downstream peers. After successfully doing so, NFs 1520 analyze the notified event(s) and behave based on the notified 1521 events defined in Section 4.3.4. NFs occurring an asynchronous 1522 event generate NOTIFY messages and set the response object(s) code 1523 based on the reported event(s). NOTIFY messages are sent further 1524 hop-by-hop upstream towards the NI. NFs SHOULD generate NOTIFY 1525 messages upon asynchronous events and forward them upstream 1526 towards the NI. 1528 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 1529 asynchronous events. NRs receiving NOTIFY messages MUST ignore 1530 this message and discard it. NOTIFY messages are sent hop-by-hop 1531 upstream towards NI 1533 3.3.6 Query and diagnosis capabilities within the NATFW NSLP protocol 1535 The NATFW NSLP provides query and diagnosis capabilities that could 1536 be used by a session(s) owner to monitor the state of those sessions. 1538 This would be used for: 1540 o Diagnostic purposes when no data packets were received (or the 1541 packet stream is subject to significant packet loss) and NATFW 1542 NSLP signaling was supposed to have created appropriate policy 1543 rules on the NATFW NFs along the data path. 1545 o Discover the number of NATFW NSLP Hops between the NI and the NR 1546 (or the last NATFW NE responding to the QDRQ) 1548 o Collecting session states owned by a specific NI, this is required 1549 in case the NI loses its sessions' information (mainly due to node 1550 system issues). 1552 The QDRQ message can be used to query and diagnose the following 1553 session information: session id, the number of NE hops (between the 1554 NI and the last NE responding to the QDRQ) and the following 1555 session's status ordered from best to worst: up, high traffic (used 1556 to detect DOS attack or unexpected traffic rate), pending, down. The 1557 status of the policy rule will probably provide sufficient diagnostic 1558 information in most cases;if more diagnostic information is required 1559 it could be provided by the NATFW NF logs. QDRQ messages may include 1560 an optional maximum hop count number value provided by the NI, when 1561 the hop count value reaches the maximum hop count the receiving NF 1562 should stop propagating the QDRQ and generate a response message to 1563 be sent back upstream to the NI. A QDRQ message usage is shown in 1564 Figure 18 where downstream NF increments the hop counter (except when 1565 they are the responding NF) and when the session's state is not "UP" 1566 (or "UP" but a QDRQ of type LIST is sent) they insert a session 1567 status value and their IP address. The Session information could be 1568 retrieved by sending a QDRQ against a specific session id or a QDRQ 1569 type equal to LIST (this is only applicable when the NI's identity is 1570 available and identical to the one used during the session's 1571 establishment process). In the message sequences shown in Figure 18, 1572 the QDRQ message (which a QDRQ type value of SINGLE) is sent for a 1573 single session ID (provided through the NTLP API), the traversed NAT 1574 didn't have any issues to report for the session however the 1575 Firewall's (FW) traffic meters reported that the flow has exceeded 1576 the maximum number of packets provisioned against the flow, hence in 1577 addition to the session status the firewall provides its address. As 1578 the firewall is the last hop (it is configured to proxy and respond 1579 to QDRQ messages) it does not increment the hop counter and responds 1580 hop by hop back to the NI. 1582 NI Private address NAT FW 1583 | | | 1584 |QDRQ(SINGLE,HOPCNT=0)| | 1585 |-------------------->| | 1586 | |QDRQ(SINGLE,HOPCNT=1) | 1587 | |---------------------> | 1588 | | | 1589 | |RESPONSE(SINGLE, | 1590 | |HOPCNT=1, | 1591 | | [HIGH_PPS,FW@] | 1592 | |<--------------------- | 1593 |RESPONSE(SINGLE, | | 1594 |HOPCNT=1,[HIGH_PPS, | | 1595 | FW@]) | | 1596 |<--------------------| | 1598 Figure 18: Query and Diagnosis operation 1600 QDRQ message processing is dependent on the NATFW NSLP node type: 1602 o NSLP initiator: NIs only generate QDRQ messages, while inserting: 1604 * a HOPCNT object with a zero value 1606 * a QDRQ type to indicate if the QDRQ is for a single session 1607 (QDRQ type would be SINGLE) or to gather information on all the 1608 sessions initiated by the NI (QDRQ type would be LIST) 1610 * When required (i.e. this is optional) a maximum hop count value 1612 * A SID (embedded in the Bound SIP object) when the QDRQ is not 1613 related to the session handled within the Message Routing State 1614 used to route the QDRQ. 1616 An NI MUST discard received QDRQ messages. 1618 o NSLP forwarder: NFs receiving QDRQ messages MUST first 1619 authenticate and authorize the message source. After successfully 1620 doing so, NFs will behave differently depending if the QDRQ is 1621 specific to one session and whether the NF co-hosts a NAT engine 1622 or not. 1624 * If the QDRQ is about a single session: 1626 1. the NF checks first if the QDRQ includes a maximum hop 1627 count, if the current hop counter is smaller (else the 1628 procedures continues as defined in 2) and the NF was 1629 previously able to forward NSLP messages downstream for the 1630 same session (else the procedure continues as defined in 1631 2), the NF increments the hop counter. Furthermore if the 1632 NF's session status is not "UP", the NF will insert a 1633 session status object, which includes the session's status 1634 and the node's IP address, as defined in Section 4.3.11. 1635 In case the NF was co-hosting a NAT engine, the NF needs to 1636 ensure the validity of the session status object's embedded 1637 IP address and modify the address based on the local NAT 1638 bind entry. After completing these operations the NF 1639 forwards the message downstream. 1641 2. In addition to the conditions discussed above, this 1642 procedure is applied when the QDRQ message is scoped by the 1643 receiving NF. The NF responds, with a RESPONSE message, 1644 hop by hop back to the NI while copying the hop counter, 1645 the bound session ID if it was present and a series of 1646 session status objects. 1648 * If the QDRQ is of type LIST then the following procedures are 1649 applied: 1651 1. the NF checks first if the QDRQ includes a maximum hop 1652 counter, if the current hop counter is smaller (else the 1653 procedures continues as defined in 2), the NF creates one 1654 or several QDRQ response objects which include a bound 1655 session ID (session ID created by the NI before it lost all 1656 its session states), a flow descriptor and the session 1657 status object (session state and NF's IP address). This is 1658 only performed if the NF is able to get the NI's proof of 1659 ownership on stored sessions within the node. In case the 1660 NF was co-hosting a NAT engine, the NF needs to ensure the 1661 validity of all embedded IP addresses includes in QDRQ 1662 objects and modify the addresses based on the local NAT 1663 bind entry. After completing these operations the NF 1664 increments the hop counter and forwards the message 1665 downstream, if there were no downstream nodes then the hop 1666 counter is decremented and the procedure continues as 1667 described below in step 2. 1669 2. In addition to the conditions discussed above, this 1670 procedure is applied when the QDRQ message is scoped by the 1671 receiving NF. The NF responds, with a RESPONSE message, 1672 hop by hop back to the NI while copying the hop counter and 1673 the series of QDRQ response objects which would include in 1674 addition to the session status objects, bound session ID as 1675 discussed in Section 4.3.13. 1677 o NSLP responder: NRs (any node being the destination of the 1678 message) receiving QDRQ messages MUST first check for 1679 authentication and authorization. After successfully doing so, 1680 NRs must process the message as the NFs when responding with a 1681 RESPONSE message to the NI. The RESPONSE message would include a 1682 copy of all the received objects within the QDRQ message. The 1683 RESPONSE message will travel along the established reverse path 1684 given by the message routing state. 1686 Responses to QDRQ messages are processed differently depending on 1687 theNATFW NSLP node type: 1689 o NSLP initiator: NIs receiving RESPONSEs to QDRQ messages MUST 1690 first check for authentication and authorization. After 1691 successfully doing so, the objects within the RESPONSE messages 1692 are provided up to the application layers and the session state 1693 remains as it was unless the application triggers NATFW NSLP state 1694 changes. 1696 o NSLP forwarder: NFs receiving RESPONSEs to QDRQ messages MUST 1697 first check for authentication and authorization. After 1698 successfully doing so, NFs forward the message upstream without 1699 any interpretation. 1701 o NSLP responder: if an NR receives a RESPONSE to QDRQ message it 1702 MUST discard it. 1704 QDRQ messages are mainly sent for debugging and outage recovery and 1705 hence should be sent within a trusted network infrastructure, this 1706 could either be achieved by implicitly scoping QDRQ messages at the 1707 edge of the trusted network infrastructure or using the maximum hop 1708 count counter. 1710 3.3.7 Proxy Mode for Data Receiver behind NAT 1712 Some migration scenarios need specialized support to cope with cases 1713 where only the receiving side is running NSIS. End-to-end signaling 1714 is going to fail without NSIS support at both data sender and data 1715 receiver, unless the NATFW NSLP also gives the NR the ability to 1716 install state on the upstream path towards the data sender for 1717 downstream data packets. The goal of the described method is to 1718 trigger the network to generate a CREATE message at the edge-NAT on 1719 behalf of the data receiver. In this case, a NR can signal towards 1720 the Opportunistic Address as is performed in the standard REA message 1721 handling scenario for NATs as in Section 3.3.2. The message is 1722 forwarded until the edge-NAT is reached. A public IP address and 1723 port number is reserved at an edge-NAT. As shown in Figure 19, 1724 unlike the standard REA message handling case, the edge-NAT is 1725 triggered to send a CREATE message on a new reverse path which 1726 traverse several firewalls or NATs. The new reverse path for CREATE 1727 is necessary to handle routing asymmetries between the edge-NAT and 1728 DR. This behavior requires an indication to the edge-NAT within the 1729 REA message if either the standard behavior (as defined in 1730 Section 3.3.2) is required or a CREATE message is required to be sent 1731 by the edge-NAT. In addition when a CREATE message needs to be sent 1732 by the edge-NAT, the REA message may include the data sender's 1733 address (DSInfo), if available to the data receiver. Figure 19 shows 1734 this proxy mode REA as REA-PROXY. 1736 DS Public Internet NAT Private address NR 1737 No NI NF space NI+ 1738 NR+ 1739 | | REA-PROXY[(DSInfo)] | 1740 | |<------------------------- | 1741 | | RESPONSE[Error/Success] | 1742 | | ---------------------- > | 1743 | | CREATE | 1744 | | ------------------------> | 1745 | | RESPONSE[Error/Success] | 1746 | | <---------------------- | 1747 | | | 1748 | | | 1750 Figure 19: REA Triggering Sending of CREATE Message on Separate 1751 Reverse Path 1753 The processing of REA-PROXY messages is different for every NSIS 1754 entity: 1756 o NSLP initiator (NI+): When the data sender's address information 1757 is known in advance the NI+ MAY include a DSInfo object in the 1758 REA-PROXY request message. When the data sender's address is not 1759 known, NI+'s MUST NOT include a DSInfo object. NI+ only generate 1760 REA-PROXY messages and should never receive them. 1762 o NSLP forwarder: NSLP forwarders receiving REA-PROXY messages MUST 1763 first check authentication and authorization before any further 1764 processing is executed. The NF SHOULD check with its local 1765 policies if it can accept the desired policy rule given by NTLP's 1766 message routing information (MRI). Further processing depends on 1767 the middlebox type: 1769 * NAT: NATs check whether the message is received at the 1770 external (public in most cases) address or at the internal 1771 (private) address. If received at the external address a NF 1772 MAY generate a RESPONSE message with an error of type 'REA 1773 received from outside' and stop forwarding. If received at the 1774 internal address, an IP address/port is reserved. If it is not 1775 an edge-NAT, the NSLP message is forwarded further with the 1776 translated IP address/port. In the case it is an edge-NAT, the 1777 NSLP message is not forwarded any further. The edge-NAT checks 1778 whether it is willing to send CREATE messages on behalf on NI+ 1779 and if so it checks the DSInfo object. The edge-NAT MAY reject 1780 the REA-PROXY request if there is no DSInfo object or if the 1781 address information within DSInfo is not valid or too much 1782 wildcarded. If accepted a RESPONSE message with the external 1783 address and port information is generated. When the edge-NAT 1784 accepts it generates a CREATE message as defined in 1785 Section 3.3.1. The edge-NAT MUST not generate a CREATE-PROXY 1786 message. The edge-NAT MUST refresh the CREATE message session 1787 only if a REA-PROXY refresh message has been received first. 1789 * Firewall: Firewalls MUST not change their configuration upon a 1790 REA message. They simply MUST forward the message and MUST 1791 keep NTLP state. Edge-Firewalls SHOULD reply with an error 1792 RESPONSE indicating 'no egde-NAT here'. 1794 * Combined NAT and Firewall: Processing at combined Firewall and 1795 NAT middleboxes is the same as in the NAT case. 1797 o NSLP receiver: This type of message should never be received by 1798 any NR+ and it SHOULD be discarded silently. 1800 Processing of a RESPONSE message with an external address object is 1801 different for every NSIS node type: 1803 o NSLP initiator: Upon receiving a RESPONSE message with an 1804 external address object, the NI+ can use the IP address and port 1805 pairs carried for further application signaling. 1807 o NSLP forwarder: NFs simply forward this message as long as they 1808 keep state for the requested reservation. 1810 o NSIS responder: This type of message should never be received by 1811 an NR and it SHOULD be discarded silently. 1813 o Edge-NATs/edge-Firewall: This type of message should never be 1814 received by any Edge-NAT/edge-Firewall and it SHOULD be discarded 1815 silently. 1817 The scenario described in this chapter challenges the data receiver 1818 in a way that it must make a correct assumption about the data 1819 sender's ability to use NSIS NATFW NSLP signaling. There are two 1820 cases a) DS is NSIS unaware and DR assumes DS to be NSIS aware and b) 1821 DS is NSIS aware but DR assumes DS to be NSIS unaware. Case a) will 1822 result in middleboxes blocking the data traffic, since DS will never 1823 send the expected CREATE message. Case b) will result in the DR 1824 successfully requesting proxy mode support by the edge-NAT. The 1825 edge-NAT will send CREATE messages and DS will send CREATE messages 1826 too. Both CREATE messages are handled as separated sessions and 1827 therefore the common rules per session apply. It is up to the NR's 1828 responsibility to decide whether to teardown the REA-PROXY sessions 1829 in the case of the data sender's side being NSIS aware. 1831 EDITOR's NOTE: The NI* for the REA session has currently no means to 1832 distinguish between a CREATE message initiated by the edge-NAT and a 1833 CREATE message initiated by the other end. In the case of using REA- 1834 PROXY and having a NSIS aware data sender though, the data receivers 1835 needs a handle to decide which CREATE session to teardown. There are 1836 multiple design choices: 1838 The NI* includes a session ID proposal in its REA-PROXY message. 1839 The edge-NAT uses this proposed session ID in its CREATE signaling 1840 as session ID. This would violate the basic semantics of NIs 1841 randomly generating their session ID on their own. 1843 The edge-NAT could include the to be used session ID of the CREATE 1844 session in its RESPONSE message to the REA-PROXY. This leads to 1845 the question of race conditions between the arrival time of the 1846 RESPONSE to REA-PROXY and the arrival time of the CREATE. More 1847 see below within next note. 1849 The NI* could included another handle that is only inserted in the 1850 REA-PROXY message, but not in REA messages. The CREATE would need 1851 to include this handle. This handle could be either a number or 1852 in the simple case a flag indicating that the particular CREATE is 1853 an answer to REA-PROXY. 1855 EDITOR's NOTE: The above note mentions a possible race condition 1856 between the RESPONSE message to the REA-PROXY and the CREATE message 1857 generated by the edge-NAT. The CREATE message could arrive earlier 1858 than the RESPONSE message. This is currently neither described nor 1859 semantically clean defined. 1861 3.3.8 Proxy Mode for Data Sender behind Middleboxes 1863 As with data receivers behind middleboxes in Section 3.3.7 also data 1864 senders behind middleboxes require proxy mode support as well. The 1865 problem here is that there is no NSIS support at the data receiver's 1866 side and, by default, there will be no response to CREATE request 1867 messages. This scenario requires the last NSIS NATFW NSLP aware node 1868 to terminate the forwarding and to proxy the response to the CREATE 1869 message, meaning that this node is generating RESPONSE messages. 1870 This last node may be an edge-NAT/edge-Firewall, or any other NATFW 1871 NSLP peer, that detects that there is no NR available (probably 1872 through GIMPS timeouts but not limited to). This proxy mode handles 1873 data senders behind a middlebox only; for receivers behind a NAT see 1874 Section 3.3.7. 1876 NIs being aware about a NSIS unaware DR, send a CREATE message 1877 towards DR with a proxy support object. Intermediate NFs can use 1878 this additional information to decide whether to terminate the 1879 message forwarding or not. This proxy support object is an implicit 1880 scoping of the CREATE message. Termination of CREATE-PROXY request 1881 messages with proxy support object included MUST only be done by 1882 egde-NATs/edge-Firewalls; future revisions of this document may 1883 change this behavior. 1885 DS Private Address FW Public Internet NR 1886 NI Space NF no NR 1887 | | | 1888 | CREATE-PROXY | | 1889 |------------------------------>| | 1890 | | | 1891 | RESPONSE[SUCCESS/ERROR] | | 1892 |<------------------------------| | 1893 | | | 1895 Figure 20: Proxy Mode Create Message Flow 1897 The processing of CREATE-PROXY messages and RESPONSE messages is 1898 similar to Section 3.3.1, except that forwarding is stopped at the 1899 edge-NAT/edge-Firewall. The edge-NAT/edge-Firewall responds back to 1900 NI according the situation (error/success) and will be the NR for 1901 future NATFW NSLP communication. 1903 3.3.9 Proxy Mode for Data Receiver behind Firewall 1905 Data receivers behind firewalls would like to provide a similar sort 1906 of proxy mode operation to those behind NATs. While finding the 1907 upstream edge-NAT is quite easy, it is only required to find an edge- 1908 NAT but not a very specific one and then the data traffic is route 1909 pinned to the NAT, the location of the appropriate edge-Firewall is 1910 more difficult. Data receivers that are located behind several 1911 firewalls that are placed topology-wise in parallel (multi-homed 1912 network), must find out the one firewall the data traffic will 1913 traverse. This feature of locating the right firewall can be used 1914 for proxy mode support and for blocking certain incoming data 1915 traffic. Proxy mode support is similar to Section 3.3.7 where the DR 1916 is behind one or more NATs and installs "allow" policy rules. 1917 Blocking incoming data traffic requires that the NATFW NSLP locates 1918 the appropriate firewall in order to install a deny policy rule. 1920 The upstream CREATE (UCREATE) message is used to locate upstream 1921 firewalls and to request installation of deny policy rules. The goal 1922 of the method described is to trigger the network to generate a 1923 CREATE message at the edge-Firewall on behalf of the data receiver. 1924 In this case, a NR can signal towards the data sender's address as in 1925 the standard REA message handling scenario for NATs Section 3.3.2. 1926 The message is forwarded until it reaches the edge-Firewall. As 1927 shown in Figure 21, the edge-Firewall is triggered to send a CREATE 1928 message on a new reverse path which could go through internal 1929 firewalls or NATs. The new reverse path for CREATE is necessary to 1930 handle routing asymmetries between the edge-Firewall and DR. UCREATE 1931 does not install any policy rule but the subsequent CREATE message 1932 initiated by the edge-Firewall does. 1934 DS Public Internet NAT Private address NR 1935 No NI NF space NI+ 1936 NR+ 1937 | | UCREATE | 1938 | |<------------------------- | 1939 | | RESPONSE[Error/Success] | 1940 | | ---------------------- > | 1941 | | CREATE | 1942 | | ------------------------> | 1943 | | RESPONSE[Error/Success] | 1944 | | <---------------------- | 1945 | | | 1946 | | | 1948 Figure 21: UCREATE Triggering Sending of CREATE Message on Separate 1949 Reverse Path 1951 The processing of UCREATE messages is different for every NSIS 1952 entity: 1954 o NSLP initiator (NI+): NI+ MUST always direct UCREATE message to 1955 the address of DS. NI+ only generate UCREATE messages and should 1956 never receive them. 1958 o NSLP forwarder: NSLP forwarders receiving UCREATE messages MUST 1959 first check authentication and authorization before any further 1960 processing is executed. The NF SHOULD check with its local 1961 policies if it can accept the desired policy rule given by NTLP's 1962 message routing information (MRI). Further processing depends on 1963 the middlebox type: 1965 * NAT: NATs check whether the message is received at the 1966 external (public in most cases) address or at the internal 1967 (private) address. If received at the internal interface, NATs 1968 allocated a public IP address and port and forward the message 1969 further. Edge-NATs receiving UCREATE SHOULD response with 1970 error RESPONSE indicating 'no edge-Firewall' 1972 * Firewall: Non edge-Firewalls simply forward the message. Edge- 1973 Firewalls stop forwarding the check for authentication and 1974 authorization. If the message is accepted, load the specified 1975 policy rule and generate CREATE messages back towards the DR as 1976 defined in Section 3.3.1. 1978 * Combined NAT and Firewall: Processing at combined Firewall and 1979 NAT middleboxes is the same as in the Firewall case. 1981 o NSLP receiver: This type of message should never be received by 1982 any NR+ and it SHOULD be discarded silently. 1984 Processing of a RESPONSE message with an external address object is 1985 different for every NSIS node type: 1987 o NSLP initiator (NI+): Upon receiving a RESPONSE message NI+ 1988 should await incoming corresponding CREATE messages. 1990 o NSLP forwarder: NFs simply forward this message as long as they 1991 keep state for the requested reservation. 1993 o NSIS responder: This type of message should never be received by 1994 an NR and it SHOULD be discarded silently. 1996 o Edge-NATs/edge-Firewall: This type of message should never be 1997 received by any Edge-NAT/edge-Firewall and it SHOULD be discarded 1998 silently. 2000 EDITOR's NOTE: The protocol behavior described within this section 2001 must be discussed at next IETF meeting. 2003 3.4 Calculation of Session Lifetime 2005 NATFW NSLP sessions, and the corresponding policy rules which may 2006 have been installed, are maintained via soft-state mechanism. Each 2007 session is assigned a lifetime and the session is kept alive as long 2008 as the lifetime is valid. After the expiration of the lifetime, 2009 sessions and policy rules MUST be removed automatically and resources 2010 bound to them should be freed as well. Session lifetime is kept at 2011 every NATFW NSLP node. The NSLP forwarders and NSLP responder are 2012 not responsible for triggering lifetime extension refresh messages 2013 (see Section 3.3.3): this is the task of the NSIS initiator. 2015 The NSIS initiator MUST choose a session lifetime (expressed in 2016 seconds) value before sending any message (lifetime is set to zero 2017 for deleting sessions) to other NSLP nodes. The session lifetime 2018 value is calculated based on: 2020 o The number of lost refresh messages that NFs should cope with 2022 o The end to end delay between the NI and NR 2024 o Network vulnerability due to session hijacking ([6]). Session 2025 hijacking is made easier when the NI does not explicitly remove 2026 the session. 2028 o The user application's data exchange duration, in terms of 2029 seconds, minutes or hours and networking needs. This duration is 2030 modeled as M x R, with R the message refresh period (in seconds) 2031 and M a multiplier for R. 2033 As opposed to the NTLP Message Routing state [1] lifetime, the NSLP 2034 session lifetime is not required to have a small value since the NSLP 2035 state refresh is not handling routing changes but security related 2036 concerns. [11] provides a good algorithm to calculate the session 2037 lifetime as well as how to avoid refresh message synchronization 2038 within the network. [11] recommends: 2040 1. The refresh message timer to be randomly set to a value in the 2041 range [0.5R, 1.5R]. 2043 2. To avoid premature loss of state, L (with L being the session 2044 lifetime) must satisfy L >= (K + 0.5)*1.5*R, where K is a small 2045 integer. Then in the worst case, K-1 successive messages may be 2046 lost without state being deleted. Currently K = 3 is suggested 2047 as the default. However, it may be necessary to set a larger K 2048 value for hops with high loss rate. Other algorithms could be 2049 used to define the relation between the session lifetime and the 2050 refresh message period, the algorithm provided is only given as 2051 an example. 2053 This requested lifetime value is placed in the 'lifetime' object of 2054 the NSLP message and messages are forwarded to the next NATFW NSLP 2055 node. 2057 NATFW NFs processing the request message along the path MAY change 2058 the requested lifetime to fit their needs and/or local policy. If an 2059 NF changes the lifetime value it must also indicate the corresponding 2060 refresh message period. NFs MUST NOT increase the lifetime value; 2061 they MAY reject the requested lifetime immediately and MUST generate 2062 an error response message of type 'lifetime too big' upon rejection. 2063 The NSLP request message is forwarded until it reaches the NSLP 2064 responder. NSLP responder MAY reject the requested lifetime value 2065 and MUST generate an error response message of type 'lifetime too 2066 big' upon rejection. The NSLP responder MAY also lower the requested 2067 lifetime to an acceptable value (based on its local policies). NSLP 2068 responders generate their appropriate response message for the 2069 received request message, sets the lifetime value to the above 2070 granted lifetime and sends the message back hop-by-hop towards NSLP 2071 initiator. 2073 Each NSLP forwarder processes the response message, reads and stores 2074 the granted lifetime value. The forwarders SHOULD accept the granted 2075 lifetime, as long as the value is within the tolerable lifetime range 2076 defined in their local policies. They MAY reject the lifetime and 2077 generate a 'lifetime not acceptable' error response message. 2078 Figure 22 shows the procedure with an example, where an initiator 2079 requests 60 seconds lifetime in the CREATE message and the lifetime 2080 is shortened along the path by the forwarder to 20 seconds and by the 2081 responder to 15 seconds. 2083 +-------+ CREATE(lt=60s) +-----------+ CREATE(lt=20s) +--------+ 2084 | |---------------->| NSLP |---------------->| | 2085 | NI | | | | NR | 2086 | |<----------------| forwarder |<----------------| | 2087 +-------+ RESPONSE(lt=15s +-----------+ RESPONSE(lt=15s +--------+ 2088 MRR=3s) MRR=3s) 2090 lt = lifetime 2091 MRR = Message Refresh Rate 2093 Figure 22: Lifetime Calculation Example 2095 3.5 Message Sequencing 2097 NATFW NSLP messages need to carry an identifier so that all nodes 2098 along the path can distinguish messages sent at different points of 2099 time. Messages can be lost along the path, delayed, or duplicated. 2100 So all NATFW NSLP nodes should be able to identify either old 2101 messages that have been received before (duplicated), or the case 2102 that messages have been lost before (loss). Furthermore, for message 2103 replay protection it is necessary to keep information about already 2104 received messages. Therefore, it is required that every NATFW NSLP 2105 message MUST carry a message sequence number (MSN), see also 2106 Section 4.3.6. 2108 The MSN MUST be only set by the NI and MUST no be set or modified by 2109 any other node. The initial value for the MSN MUST be generated 2110 randomly and MUST be only unique within the used session. The NI 2111 MUST increment the MSN for every message sent. Once the MSN has 2112 reached the maximum value, the next value it takes is zero. 2114 NSIS forwarders and the responder store the MSN received with the 2115 initial packet as start value. NFs and NRs include the received MSN 2116 value in their response messages if generated. 2118 When receiving a message, a NATFW NSLP node uses the MSN given in the 2119 message to determine whether the state being requested is different 2120 to the state already installed. The message MUST be discarded if the 2121 received MSN value is lower or equal than the stored MSN value. This 2122 received MSN value can indicate a delayed message or replayed 2123 message. If the received MSN value is greater than the already 2124 stored MSN value, the NATFW NSLP MUST update its stored state 2125 accordingly, if permitted by all security checks, and store the 2126 updated MSN value accordingly. 2128 This semantics applied to a CREATE message exchange means that the 2129 first CREATE (initial CREATE to setup the path and session) carries 2130 the initial, randomly generated, MSN. All nodes along the path store 2131 this value and the responder includes the received value in its 2132 response (assuming that the CREATE message reaches the responder). 2133 Subsequent CREATE messages, updating the request policy rule or 2134 lifetime, carry an increment MSN value, so that intermediate nodes 2135 can note the requested update. 2137 3.6 De-Multiplexing at NATs 2139 Section 3.3.2 describes how NSIS nodes behind NATs can obtain a 2140 public reachable IP address and port number at a NAT and how it can 2141 be activated by using CREATE messages (see Section 3.3.1)". The 2142 information about the public IP address/port number can be 2143 transmitted via an application level signaling protocol and/or third 2144 party to the communication partner that would like to send data 2145 toward the host behind the NAT. However, NSIS signaling flows are 2146 sent towards the address of the NAT at which this particular IP 2147 address and port number is allocated and not directly to the 2148 allocated IP address and port number. The NATFW NSLP forwarder at 2149 this NAT needs to know how the incoming NSLP requests are related to 2150 reserved addresses, meaning how to de-multiplex incoming NSIS 2151 requests. 2153 The de-multiplexing method uses information stored at NATs (such as 2154 mapping of public IP address to private, transport protocol, port 2155 numbers), information given by NTLP's message routing information and 2156 further authentication credentials. 2158 3.7 Selecting Opportunistic Addresses for REA 2160 As with all other message types, REA messages need a reachable final 2161 destination IP address. But as many applications do not provide a 2162 destination IP address in the first place, there is a need to choose 2163 a destination address for REA messages. This destination address can 2164 be the final target, but for applications which do not provide an 2165 upfront address, the destination address has to be chosen 2166 independently. Choosing the 'correct' destination IP address may be 2167 difficult and it is possible there is no 'right answer'. [15] shows 2168 choices for SIP and this section provides some hints about choosing a 2169 good destination IP address. 2171 1. Public IP address of the data sender: 2173 * Assumption: 2175 + The data receiver already learned the IP address of the 2176 data sender (e.g., via a third party). 2178 * Problems: 2180 + The data sender might also be behind a NAT. In this case 2181 the public IP address of the data receiver is the IP 2182 address allocated at this NAT. 2184 + Due to routing asymmetry it might be possible that the 2185 routes taken by a) the data sender and the application 2186 server b) the data sender and NAT B might be different, 2187 this could happen in a network deployment such as in 2188 Figure 14. As a consequence it might be necessary to 2189 advertise a new (and different) external IP address within 2190 the application (which may or may not allow that) after 2191 using NSIS to establish a NAT binding. 2193 2. Public IP address of the data receiver: 2195 * Assumption: 2197 + The data receiver already learned his externally visible IP 2198 address (e.g., based on the third party communication). 2200 * Problems: 2202 + Communication with a third party is required. 2204 3. IP address of the Application Server: 2206 * Assumption: 2208 + An application server (or a different third party) is 2209 available. 2211 * Problems: 2213 + If the NSIS signaling message is not terminated at the NAT 2214 of the local network then an NSIS unaware application 2215 server might discard the message. 2217 + Routing might not be optimal since the route between a) the 2218 data receiver and the application server b) the data 2219 receiver and the data sender might be different. 2221 4. NATFW NSLP Message Components 2223 A NATFW NSLP message consists of a NSLP header and one or more 2224 objects following the header. The NSLP header is common for all 2225 NSLPs and objects are Type-Length-Value (TLV) encoded using big 2226 endian (network ordered) binary data representations. Header and 2227 objects are aligned to 32 bit boundaries and object lengths that are 2228 not multiples of 32 bits must be padded to the next higher 32 bit 2229 multiple. 2231 The whole NSLP message is carried as payload of a NTLP message. 2233 Note that the notation 0x is used to indicate hexadecimal numbers. 2235 4.1 NSLP Header 2237 The NSLP header is common to all NSLPs and is the first part of all 2238 NSLP messages. It contains two fields, the NSLP message type and a 2239 reserved field. The total length is 32 bits. The layout of the NSLP 2240 header is defined by Figure 23. 2242 0 16 31 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | NSLP message type | reserved | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 Figure 23: Common NSLP header 2249 The reserved field MUST be set to zero in the NATFW NSLP header 2250 before sending and MUST be ignored during processing of the header. 2251 Note that other NSLPs use this field as a flag field. 2253 4.2 NSLP message types 2255 The message types identify requests and responses. Defined messages 2256 types are: 2258 o 0x0101 : CREATE 2260 o 0x0102 : RESERVE-EXTERNAL-ADDRESS(REA) 2262 o 0x0104 : UCREATE 2263 o 0x0108 : QDRQ 2265 o 0x0201 : RESPONSE 2267 o 0x0301 : NOTIFY 2269 4.3 NSLP Objects 2271 NATFW NSLP objects use a common header format defined by Figure 24. 2272 The object header contains two fields, the NSLP object type and the 2273 object length. Its total length is 32 bits. 2275 0 1 2 3 2276 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 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 Figure 24: Common NSLP object header 2283 The length is the total length of the object without the object 2284 header. The unit is a word, consisting of 4 octets. The particular 2285 values of type and length for each NSLP object are listed in the 2286 subsequent sections that define the NSLP objects. The two leading 2287 bits of the NSLP object header are used to signal the desired 2288 treatment for objects whose treatment has not been defined in this 2289 memo (see [1], Section 3.2), i.e., the Object Type has not been 2290 defined. NATFW NSLP uses a subset of the categories defined in 2291 GIMPS: 2293 o AB=00 ("Mandatory"): If the object is not understood, the entire 2294 message containing it must be rejected with an error indication. 2296 o AB=01 ("Optional"): If the object is not understood, it should be 2297 deleted and then the rest of the message processed as usual. 2299 o AB=10 ("Forward"): If the object is not understood, it should be 2300 retained unchanged in any message forwarded as a result of message 2301 processing, but not stored locally. 2303 The combination AB=11 ("Refresh") MUST NOT be used since the NATFW 2304 NSLP refreshes its state end-to-end and not locally. Fields marked 2305 with 'r' are reserved for future use. 2307 The following sections do not repeat the common NSLP object header, 2308 they just state the type and the length. 2310 4.3.1 Session Lifetime Object 2312 The session lifetime object carries the requested or granted lifetime 2313 of a NATFW NSLP session measured in seconds. The Message refresh 2314 rate value is set by default to 0xFFFF and only set to a specific 2315 value when an intermediate node changes the message lifetime and 2316 informs the upstream node about the recommended message refresh rate. 2318 Type: NATFW_LT 2320 Length: 1 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 | NATFW NSLP session lifetime | 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 | NATFW NSLP message refresh rate | 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 Figure 25: Lifetime object 2330 4.3.2 External Address Object 2332 The external address object can be included in RESPONSE messages 2333 (Section 4.4.3) only. 2335 Type: NATFW_EXT_IPv4 2337 Length: 2 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | port number | reserved | 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | IPv4 address | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 Figure 26: External Address Object for IPv4 addresses 2347 Type: NATFW_EXT_IPv6 2349 Length: 5 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | port number | reserved | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | | 2355 + + 2356 | | 2357 + IPv6 address + 2358 | | 2359 + + 2360 | | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 Figure 27: External Address Object for IPv6 addresses 2365 Please note that the field 'port number' MUST be set to 0 if only an 2366 IP address has been reserved, for instance, by a traditional NAT. A 2367 port number of 0 MUST be ignored in processing this object. 2369 4.3.3 Extended Flow Information Object 2371 In general, flow information is kept at the NTLP level during 2372 signaling. The message routing information of the NTLP carries all 2373 necessary information. Nevertheless, some additional information may 2374 be required for NSLP operations. The 'extended flow information' 2375 object carries this additional information about action to be taken 2376 on the installed policy rules. 2378 Type: NATFW_EXT_FLOW 2380 Length: 1 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | rule action | reserved | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 Figure 28: Extended Flow Information 2388 These fields are defined for the policy rule object: 2390 o Rule action: This field indicates the action for the policy rule 2391 to be activated. Allowed values are 'allow' (0x01) and 'deny' 2392 (0x02) 2394 4.3.4 Response Code Object 2396 This object carries the response code, which may be indications for 2397 either a successful request or failed request depending on the value 2398 of the 'response code' field. 2400 Type: NATFW_RESPONSE 2402 Length: 1 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 | response code | 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 Figure 29: Response Code Object 2410 TBD: Define response classes, success codes and error codes. 2411 Possible error classes are: 2413 o Policy rule errors 2415 o Authentication and Authorization errors 2417 o NAT 2419 Currently errors defined in this memo are: 2421 o lifetime too big 2423 o lifetime not acceptable 2425 o no NAT here 2427 o no reservation found 2429 o requested external address from outside 2430 o re-authorization needed 2432 o routing change detected 2434 4.3.5 Proxy Support Type Object 2436 This object indicates that proxy mode support is required. Either in 2437 a REA message or CREATE message. 2439 Type: NATFW_RESP_TYPE 2441 Length: 0, only object header 2443 EDITOR's NOTE: This is quite a short object and probably better moved 2444 to a flag somewhere. 2446 4.3.6 Message Sequence Number Object 2448 This object carries the MSN value as described in Section 3.5. 2450 Type: NATFW_RESP_MSN 2452 Length: 1 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2455 | message sequence number | 2456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 Figure 30: Message Sequence Number Object 2460 4.3.7 Bound Session ID Object 2462 This object carries a session ID and is used for QUERY messages only. 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 | bound session ID | 2466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 Figure 31: Bound Session ID Object 2470 This object is used when a session owner queries multiple session, 2471 every session would be indicated with the bound session ID object. 2473 4.3.8 Data Sender Information Object 2475 Type: NATFW_DSINFO_IPv4 2477 Length: 1 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 | port number | reserved | 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | IPv4 address | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 Figure 32: Data Sender's IPv4 Address Object 2487 Type: NATFW_DSINFO_IPv6 2489 Length: 1 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 | port number | reserved | 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | | 2495 + + 2496 | | 2497 + IPv6 address + 2498 | | 2499 + + 2500 | | 2501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 Figure 33: ata Sender's IPv6 Address Object for IPv6 addresses 2505 4.3.9 NATFW NF Hop Count Object 2506 Type: NATFW_NF_HOPCNT 2508 Length: 1 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | NATFW NF HOP COUNT | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 Figure 34: NATFW NF Hop Count Object 2516 Editor note next revision will include Hop count, maximum hops and 2517 QDRQ type in the same object to minimize the overhead since 4 bits 2518 would be sufficient for the counters. 2520 4.3.10 Maximum Hops Object 2522 Type: NATFW_NF_MAX_HOPCNT 2524 Length: 1 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 | NATFW NF MAX HOP COUNT | 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 Figure 35: NATFW NF Maximum Hop Count Object 2532 4.3.11 Session Status object 2534 The session status object is inserted within the QDRQ message and 2535 copied in a response message. It embeds the current local node's 2536 session status and the node's IP address 2538 Type: SESSION_STS 2540 Length: 2 or 5 2542 SESSION STATUS: 2544 Length 1, Possible values: UP(0),HIGH_PPS(1), PENDING(2), DOWN(3) 2546 Reserved bits: RRR 2548 Length 3 bits 2550 IP version: V bit 2552 Length 1 bit: IPv4(0), IPv6(1) 2554 NODE IP ADDRESS: 2556 Length 1 or 4 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 | SESSION STATUS |R|R|R|V| 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2561 | NODE IP ADDRESS (1 or 4 words) | 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 Figure 36: Session Status Object 2566 4.3.12 QDRQ type 2568 Type: QDRQ_TYPE 2570 Length: 1 2572 Possible values: SINGLE(0), LIST(1) 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 | QDRQ TYPE | 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 Figure 37: QDRQ TYPE object 2580 4.3.13 QDRQ Response object 2582 TBC for next version: includes an optional bound session id, an 2583 optional flow descriptor (used when a LIST QDRQ type is used) and a 2584 mandatory session status 2586 4.4 Message Formats 2588 This section defines the content of each NATFW NSLP message type. 2589 The message types are defined in Section 4.2. First, the request 2590 messages are defined with their respective objects to be included in 2591 the message. Second, the response messages are defined with their 2592 respective objects to be included. 2594 Basically, each message is constructed of NSLP header and one or more 2595 NSLP objects. The order of objects is not defined, meaning that 2596 objects may occur in any sequence. Objects are marked either with 2597 mandatory [M] or optional [O]. Where [M] implies that this 2598 particular object MUST be included within the message and where [O] 2599 implies that this particular object is OPTIONAL within the message. 2601 Each section elaborates the required settings and parameters to be 2602 set by the NSLP for the NTLP, for instance, how the message routing 2603 information is set. 2605 4.4.1 CREATE 2607 The CREATE request message is used to create NSLP sessions and to 2608 create policy rules. Furthermore, CREATE messages are used to 2609 refresh sessions and to delete them. 2611 The CREATE message carries these objects: 2613 o Lifetime object [M] 2615 o Extended flow information object [M] 2617 o Message sequence number object [M] 2619 o Proxy support object [O] 2621 The message routing information in the NTLP MUST be set to DS as 2622 source address and DR as destination address. All other parameters 2623 MUST be set according the required policy rule. 2625 4.4.2 RESERVE-EXTERNAL-ADDRESS (REA) 2627 The RESERVE-EXTERNAL-ADDRESS (REA) request message is used to target 2628 a NAT and to allocated an external IP address and possibly port 2629 number, so that the initiator of the REA request has a public 2630 reachable IP address/port number. 2632 The REA request message carries these objects: 2634 o Lifetime object [M] 2636 o Message sequence number object [M] 2638 o Extended flow information object [M] 2640 o Proxy support object [O] 2642 o Data sender information object [O] 2644 The REA message needs special NTLP treatment. First of all, REA 2645 messages travel the wrong way, from the DR towards DS. Second, the 2646 DS' address used during the signaling may be not the actual DS (see 2647 Section 3.7). Therefore, the NTLP flow routing information is set to 2648 DR as initiator and DS as responders, a special field is given in the 2649 NTLP: The signaling destination. 2651 4.4.3 RESPONSE 2653 RESPONSE messages are responses to CREATE, REA, UCREATE, and QUERY 2654 messages. 2656 The RESPONSE message carries these objects: 2658 o Lifetime object [M] 2660 o Message sequence number object [M] 2662 o Response code object [M] 2664 o External address object [O]([M] for success responses to REA) 2666 This message is routed upstream. 2668 EDITOR's note: Text says that this section is defining the behavior 2669 depending on the response type. 2671 4.4.4 QDRQ 2673 QDRQ messages are used for query and diagnosis purposes. 2675 The QDRQ message carries these objects: 2677 o Response object [M] 2678 o Message sequence number object [M] 2680 o NATFW NSLP Hop Count [M] 2682 o Maximum Hop Count value [O] 2684 o Bound session ID [O] 2686 o Session status [O] 2688 o QDRQ type [O] 2690 This message is routed downstream. 2692 4.4.5 NOTIFY 2694 The NOTIFY messages is used to report asynchronous events happening 2695 along the signaled path to other NATFW NSLP nodes. 2697 The NOTIFY message carries this object: 2699 o Response code object with NOTIFY code [M]. 2701 The message routing information in the NTLP MUST be set with the NI's 2702 address being the destination address and the node's address as 2703 source address. The message is forwarded upstream hop by hop using 2704 the existing upstream node address entry within the node's Message 2705 Routing State table. The session id object must be set to the 2706 corresponding session that is effected by this asynchronous event. 2708 4.4.6 UCREATE 2710 TBD: XYX. 2712 5. NATFW NSLP NTLP Requirements 2714 The NATFW NSLP requires the following capabilities from the NTLP: 2716 o Ability to detect that the NSIS Responder does not support NATFW 2717 NSLP. This capability is key to launching the proxy mode behavior 2718 as described in Section 3.3.7 and [13]. 2720 o Detection of NATs and their support of the NSIS NATFW NSLP. If 2721 the NTLP discovers that the NSIS host is behind an NSIS aware NAT, 2722 the NR will send REA messages to the opportunistic address. If 2723 the NTLP discovers that the NSIS host is behind a NAT that does 2724 not support NSIS then the NSIS host will need to use a separate 2725 NAT traversal mechanism. 2727 o Message origin authentication and message integrity protection 2729 o Detection of routing changes 2731 o Protection against malicious announcement of fake path changes, 2732 this is needed to mitigate a threat discussed in Section 7 of [6] 2734 6. NSIS NAT and Firewall Transition Issues 2736 NSIS NAT and Firewall transition issues are premature and will be 2737 addressed in a separate draft (see [13]). An update of this section 2738 will be based on consensus. 2740 7. Security Considerations 2742 Security is of major concern particularly in case of Firewall 2743 traversal. This section provides security considerations for the 2744 NAT/Firewall traversal and is organized as follows: 2746 Section 7.1 describes the framework assumptions with regard to the 2747 assumed trust relationships between the participating entities. This 2748 subsection also motivates a particular authorization model. 2750 Security threats that focus on NSIS in general are described in [6] 2751 and they are applicable to this document. Within Section 7.2 we 2752 extend this threat investigation by considering NATFW NSLP specific 2753 threats. Based on the security threats we list security 2754 requirements. 2756 Finally we illustrate how the security requirements that were created 2757 based on the security threats can be fullfilled by specific security 2758 mechanisms. These aspects will be elaborated in Section 7.3. 2760 7.1 Trust Relationship and Authorization 2762 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 2763 and is, as such, not a two-party protocol. This fact requires more 2764 thoughts about scenarios, trust relationships and authorization 2765 mechanisms. Trust relationships and authorization are very important 2766 for the protocol machinery and they are closely related to each other 2767 in the sense that a certain degree of trust is required to authorize 2768 a particular action. For any action (e.g. create/delete pinholes), 2769 authorization is very important due to the nature of middleboxes. 2770 More problematic scenarios are described in Appendix B. 2772 Different types of trust relationships may affect different 2773 categories of middleboxes. As explained in [21], establishment of a 2774 financial relationship is typically very important for QoS signaling, 2775 whereas financial relationships are less directly of interest for 2776 NATFW middlebox signaling. It is therefore not particularly 2777 surprising that there are differences in the nature and level of 2778 authorization likely to be required in a QoS signaling environment 2779 and in NATFW middlebox signaling. Typically NATFW signaling requires 2780 authorization to configure firewalls or to modify NAT bindings. The 2781 outcome of the authorization is either allowed or disallowed whereas 2782 QoS signaling might just indicate that a lower QoS reservation is 2783 allowed. 2785 Different trust relationships that appear in middlebox signaling 2786 environments are described in the subsequent sub-sections. As a 2787 comparison with other NSIS signaling application it might be 2788 interesting to mention that QoS signaling relies on peer-to-peer 2789 trust relationships and authorization between neighboring nodes or 2790 neighboring networks. These type of trust relationships turn out to 2791 be simpler for a protocol. However, there are reasons to believe 2792 that this is not the only type of trust relationship found in today's 2793 networks. 2795 7.1.1 Peer-to-Peer Trust Relationship 2797 Starting with the simplest scenario, it is assumed that neighboring 2798 nodes trust each other. The required security association to 2799 authenticate and to protect a signaling message is either available 2800 (after manual configuration), or has been dynamically established 2801 with the help of an authentication and key exchange protocol. If 2802 nodes are located closely together, it is assumed that security 2803 association establishment is easier than establishing it between 2804 distant nodes. It is, however, difficult to describe this 2805 relationship generally due to the different usage scenarios and 2806 environments. Authorization heavily depends on the participating 2807 entities, but for this scenario, it is assumed that neighboring 2808 entities trust each other (at least for the purpose of policy rule 2809 creation, maintenance, and deletion). Note that Figure 38 does not 2810 illustrate the trust relationship between the end host and the access 2811 network. 2813 +------------------------+ +-------------------------+ 2814 |Network A | | Network B| 2815 | +---------+ +---------+ | 2816 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 2817 | | | box 1 | Trust | box 2 | | | 2818 | | +---------+ Relationship +---------+ | | 2819 | | Trust | | Trust | | 2820 | | Relationship | | Relationship | | 2821 | | | | | | 2822 | +--+---+ | | +--+---+ | 2823 | | Host | | | | Host | | 2824 | | A | | | | B | | 2825 | +------+ | | +------+ | 2826 +------------------------+ +-------------------------+ 2828 Figure 38: Peer-to-Peer Trust Relationship 2830 7.1.2 Intra-Domain Trust Relationship 2832 In larger corporations, often more than one middlebox is used to 2833 protect or serve different departments. In many cases, the entire 2834 enterprise is controlled by a security department, which gives 2835 instructions to the department administrators. In such a scenario, a 2836 peer-to-peer trust-relationship might be prevalent. Sometimes it 2837 might be necessary to preserve authentication and authorization 2838 information within the network. As a possible solution, a 2839 centralized approach could be used, whereby an interaction between 2840 the individual middleboxes and a central entity (for example a policy 2841 decision point - PDP) takes place. As an alternative, individual 2842 middleboxes could exchange the authorization decision with another 2843 middlebox within the same trust domain. Individual middleboxes 2844 within an administrative domain should exploit their trust 2845 relationship instead of requesting authentication and authorization 2846 of the signaling initiator again and again. Thereby complex protocol 2847 interactions are avoided. This provides both a performance 2848 improvement without a security disadvantage since a single 2849 administrative domain can be seen as a single entity. Figure 39 2850 illustrates a network structure which uses a centralized entity. 2852 +-----------------------------------------------------------+ 2853 | Network A | 2854 | +---------+ +---------+ 2855 | +----///--------+ Middle- +------///------++ Middle- +--- 2856 | | | box 2 | | box 2 | 2857 | | +----+----+ +----+----+ 2858 | +----+----+ | | | 2859 | | Middle- +--------+ +---------+ | | 2860 | | box 1 | | | | | 2861 | +----+----+ | | | | 2862 | | | +----+-----+ | | 2863 | | | | Policy | | | 2864 | +--+---+ +-----------+ Decision +----------+ | 2865 | | Host | | Point | | 2866 | | A | +----------+ | 2867 | +------+ | 2868 +-----------------------------------------------------------+ 2870 Figure 39: Intra-domain Trust Relationship 2872 7.1.3 End-to-Middle Trust Relationship 2874 In some scenarios, a simple peer-to-peer trust relationship between 2875 participating nodes is not sufficient. Network B might require 2876 additional authorization of the signaling message initiator. If 2877 authentication and authorization information is not attached to the 2878 initial signaling message then the signaling message arriving at 2879 Middlebox 2 would result in an error message being created, which 2880 indicates the additional authorization requirement. In many cases 2881 the signaling message initiator is already aware of the additionally 2882 required authorization before the signaling message exchange is 2883 executed. Replay protection is a requirement for authentication to 2884 the non-neighboring middlebox, which might be difficult to accomplish 2885 without adding additional roundtrips to the signaling protocol (e.g., 2886 by adding a challenge/response type of message exchange). 2888 Figure 40 shows the slightly more complex trust relationships in this 2889 scenario. 2891 +--------------------+ +---------------------+ 2892 | Network A | Trust |Network B | 2893 | | Relationship | | 2894 | +---------+ +---------+ | 2895 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 2896 | | | box 1 | +-------+ box 2 | | | 2897 | | +---------+ | +---------+ | | 2898 | |Trust | | | Trust | | 2899 | |Relationship | | | Relationship| | 2900 | | | | | | | 2901 | +--+---+ | | | +--+---+ | 2902 | | Host +----///----+------+ | | Host | | 2903 | | A | |Trust | | B | | 2904 | +------+ |Relationship | +------+ | 2905 +--------------------+ +---------------------+ 2907 Figure 40: End-to-Middle Trust Relationship 2909 7.2 Security Threats and Requirements 2911 This section describes NATFW specific security threats and 2912 requirements. 2914 7.2.1 Attacks related to authentication and authorization 2916 The NSIS message which installs policy rules at a middlebox is the 2917 CREATE message. The CREATE message travels from the Data Sender (DS) 2918 toward the Data Receiver (DR). The packet filter or NAT binding is 2919 marked as pending by the middleboxes along the path. If it is 2920 confirmed with a success RESPONSE message from the DR, the requested 2921 policy rules on the middleboxes are installed to allow the traversal 2922 of a data flow. 2924 +-----+ +-----+ +-----+ 2925 | DS | | MB | | DR | 2926 +-----+ +-----+ +-----+ 2927 | | | 2928 | CREATE | CREATE | 2929 |-------------------->+-------------------->| 2930 | | | 2931 | Succeeded/Error | Succeeded/Error | 2932 |<--------------------+<--------------------| 2933 | | | 2934 ==========================================> 2935 Direction of data traffic 2937 Figure 41: CREATE Mode 2939 In this section we will consider some simple scenarios for middlebox 2940 configuration: 2942 o Data Sender (DS) behind a firewall 2944 o Data Sender (DS) behind a NAT 2946 o Data Receiver (DR) behind a firewall 2948 o Data Receiver (DR) behind a NAT 2950 A real-world scenario could include a combination of these firewall/ 2951 NAT placements, such as, a DS and/or a DR behind a chain of NATs and 2952 firewalls. 2954 Figure 42 shows one possible scenario: 2956 +-------------------+ +--------------------+ 2957 | Network A | | Network B | 2958 | | | | 2959 | +-----+ | //-----\\ | +-----+ | 2960 | | MB2 |--------+----| INET |----+--------| MB3 | | 2961 | +-----+ | \\-----// | +-----+ | 2962 | | | | | | 2963 | +-----+ | | +-----+ | 2964 | | MB1 | | | | MB4 | | 2965 | +-----+ | | +-----+ | 2966 | | | | | | 2967 | +-----+ | | +-----+ | 2968 | | DS | | | | DR | | 2969 | +-----+ | | +-----+ | 2970 +-------------------+ +--------------------+ 2972 MB: Middle box (NAT or Firewall or a combination) 2973 DS: Data Sender 2974 DR: Data Receiver 2976 Figure 42: Several middleboxes per network 2978 7.2.1.1 Data Sender (DS) behind a firewall 2980 +------------------------------+ 2981 | | 2982 | +-----+ create +-----+ 2983 | | DS | --------------> | FW | 2984 | +-----+ +-----+ 2985 | | 2986 +------------------------------+ 2988 DS sends a CREATE message to request the traversal of a data flow. 2990 It is up to network operators to decide how far they can trust users 2991 inside their networks. However, there are several reasons why they 2992 should not. 2994 The following attacks are possible: 2996 o DS could open a firewall pinhole with a source address different 2997 from its own host. 2999 o DS could open firewall pinholes for incoming data flows that are 3000 not supposed to enter the network. 3002 o DS could request installation of any policy rules and allow all 3003 traffic go through. 3005 SECURITY REQUIREMENT: The middlebox MUST authenticate and authorize 3006 the neighboring NAT/FW NSLP node which requests an action. 3007 Authentication and authorization of the initiator SHOULD be 3008 provided to NATs and Firewalls along the path. 3010 7.2.1.2 Data Sender (DS) behind a NAT 3012 The case 'DS behind a NAT' is analogous to the case 'DS behind a 3013 firewall'. 3015 Figure 44 illustrates such a scenario: 3017 +------------------------------+ 3018 | | 3019 | +------+ CREATE | 3020 | | NI_1 | ------\ +-----+ CREATE +-----+ 3021 | +------+ \------> | NAT |-------->| MB | 3022 | +-----+ +-----+ 3023 | +------+ | 3024 | | NI_2 | | 3025 | +------+ | 3026 +------------------------------+ 3028 Figure 44: Several NIs behind a NAT 3030 In this case the middlebox MB does not know who is the NSIS Initiator 3031 since both NI_1 and NI_2 are behind a NAT (which is also NSIS aware). 3032 Authentication needs to be provided by other means such as the NSLP 3033 or the application layer. 3035 SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that 3036 the neighboring NAT/FW NSLP node is authorized to request an 3037 action. Authentication and authorization of the initiator (which 3038 is the DR in this scenario) to the middleboxes (via another NSIS 3039 aware middlebox) SHOULD be provided. 3041 7.2.1.3 Data Receiver (DR) behind a firewall 3043 In this case a CREATE message comes from an entity DS outside the 3044 network towards the DR inside the network. 3046 +------------------------------+ 3047 | | 3048 +-----+ CREATE +-----+ CREATE +-----+ | 3049 | DS | -------------> | FW | -------------> | DR | | 3050 +-----+ <------------- +-----+ <------------- +-----+ | 3051 success RESPONSE | success RESPONSE | 3052 | | 3053 +------------------------------+ 3055 Since policy rules at middleboxes must only be installed after 3056 receiving a successful response it is necessary that the middlebox 3057 waits until the Data Receiver DR confirms the request of the Data 3058 Sender DS with a success RESPONSE message. This is, however, only 3059 necessary 3061 o if the action requested with the CREATE message cannot be 3062 authorized and 3064 o if the middlebox is still forwarding the signaling message towards 3065 the end host (without state creation/deletion/modification). 3067 This confirmation implies that the data receiver is expecting the 3068 data flow. 3070 At this point we differentiate two cases: 3072 1. DR knows the IP address of the DS (for instance because of some 3073 previous application layer signaling) and is expecting the data 3074 flow. 3076 2. DR might be expecting the data flow (for instance because of some 3077 previous application layer signaling) but does not know the IP 3078 address of the Data Sender DS. 3080 For the second case, Figure 46 illustrates a possible attack: an 3081 adversary Mallory M could be sniffing the application layer signaling 3082 and thus knows the address and port number where DR is expecting the 3083 data flow. Thus it could pretend to be DS and send a CREATE message 3084 towards DR with the data flow description (M -> DR). Since DR does 3085 not know the IP address of DS, it is not able to recognize that the 3086 request is coming from the "wrong guy". It will send a success 3087 RESPONSE message back and the middlebox will install policy rules 3088 that will allow Mallory M to inject its data into the network. 3090 Application Layer signaling 3091 <------------------------------------> 3092 / \ 3093 / +-----------------\------------+ 3094 / | \ | 3095 +-----+ +-----+ +-----+ | 3096 | DS | -> | FW | | DR | | 3097 +-----+ / +-----+ +-----+ | 3098 CREATE / | | 3099 +-----+ / +-------------------------------+ 3100 | M |---------- 3101 +-----+ 3103 Figure 46: DR behind a firewall with an adversary 3105 Network administrators will probably not rely on a DR to check the IP 3106 address of the DS. Thus we have to assume the worst case with an 3107 attack such as in Figure 46. Many operators might not allow NSIS 3108 signaling message to traverse the firewall in Figure 46 without 3109 proper authorization. In this case the threat is not applicable. 3111 SECURITY REQUIREMENT: A binding between the application layer and the 3112 NSIS signaling SHOULD be provided. 3114 7.2.1.4 Data Receiver (DR) behind a NAT 3116 When a data receiver DR behind a NAT sends a RESERVE-EXTERNAL-ADDRESS 3117 (REA) message to get a public reachable address that can be used as a 3118 contact address by an arbitrary data sender if the DR was unable to 3119 restrict the future data sender. The NAT reserves an external 3120 address and port number and sends them back to DR. The NAT adds an 3121 address mapping entry in its reservation list which links the public 3122 and private addresses as follows: 3124 (DR_ext <=> DR_int) (*). 3126 The NAT sends a RESPONSE message with the external address' object 3127 back to the DR with the address DR_ext. DR informs DS about the 3128 public address that it has recently received, for instance, by means 3129 of application layer signaling. 3131 When a data sender sends a CREATE message towards DR_ext then the 3132 message will be forwarded to the DR. The data sender might want to 3133 update the NAT binding stored at the edge-NAT to make it more 3134 restrictive. 3136 We assume that the adversary Mallory M obtains the contact address 3137 (i.e., external address and port) allocated at the NAT possibly by 3138 eavesdropping on the application layer signaling and sends a CREATE 3139 message. As a consequence Mallory would be able to communicate with 3140 DR (if M is authorized by the edge-NAT and if the DR accepts CREATE 3141 and returns a RESPONSE. 3143 Application Layer signaling 3144 <------------------------------------> 3145 / \ 3146 / +-----------------\------------+ 3147 / | REA \ | 3148 +-----+ +-----+ <----------- +-----+ | 3149 | DS | -> | NAT | -----------> | DR | | 3150 +-----+ / +-----+ rtn_ext_addr +-----+ | 3151 CREATE / | | 3152 +-----+ / +-------------------------------+ 3153 | M |---------- 3154 +-----+ 3156 SECURITY REQUIREMENT: The DR MUST be able to specify which data 3157 sender are allowed to traverse the NAT in order to be forwarded to 3158 DRs address. 3160 7.2.1.5 NSLP Message Injection 3162 Malicious hosts, located either off-path or on-path, could inject 3163 arbitrary NATFW NSLP messages into the signaling path, causing 3164 several problems. These problems apply when no proper authorization 3165 and authentication scheme is available. 3167 By injecting a bogus CREATE message with lifetime set to zero, a 3168 malicious host could try to teardown NATFW NSLP session state 3169 partially or completely on a data path, causing a service 3170 interruption. 3172 By injecting a bogus responses or NOTIFY message, for instance, 3173 timeout, a malicious host could try to teardown NATFW NSLP session 3174 state as well. This could affect the data path partially or totally, 3175 causing a service interruption. 3177 SECURITY REQUIREMENT: Messages, such as TRIGGER, can be misused by 3178 malicious hosts, and therefore need to be authorized. 3180 7.2.2 Denial-of-Service Attacks 3182 In this section we describe several ways how an adversary could 3183 launch a Denial of service (DoS) attack on networks running NSIS for 3184 middlebox configuration to exhaust their resources. 3186 7.2.2.1 Flooding with CREATE messages from outside 3188 7.2.2.1.1 Attacks due to NSLP state 3190 A CREATE message requests the NSLP to store state information such as 3191 a NAT binding or a policy rule. 3193 The policy rules requested in the CREATE message will be installed at 3194 the arrival of a confirmation from the Data Receiver with a success 3195 RESPONSE message. A successful RESPONSE message includes the session 3196 ID. So the NSLP looks up the NSIS session and installs the requested 3197 policy rules. 3199 An adversary from outside could launch a DoS attack with arbitrary 3200 CREATE messages. For each of these messages the middlebox needs to 3201 store state information such as the policy rules to be loaded, i.e., 3202 the middlebox could run out of memory. This kind of attack is also 3203 mentioned in [6] Section 4.8. 3205 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 'create- 3206 session' message before storing state information. 3208 7.2.2.1.2 Attacks due to authentication complexity 3210 This kind of attack is possible if authentication is based on 3211 mechanisms that require computing power, for example, digital 3212 signatures. 3214 For a more detailed treatment of this kind of attack, the reader is 3215 encouraged to see [6]. 3217 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 3218 denial of service attacks based on authentication or key 3219 management mechanisms. 3221 7.2.2.1.3 Attacks to the endpoints 3223 The NATFW NSLP requires firewalls to forward NSLP messages, a 3224 malicious node may keep sending NSLP messages to a target. This may 3225 consume the access network resources of the victim, drain the battery 3226 of the victim's terminal and may force the victim to pay for the 3227 received although undesired data. 3229 This threat may be more particularly be relevant in networks where 3230 access link is a limited resource, for instance in cellular networks, 3231 and where the terminal capacities are limited. 3233 SECURITY REQUIREMENT: A NATFW NSLP aware firewall or NAT MUST be able 3234 to block unauthorized signaling message, if this threat is a 3235 concern. 3237 7.2.2.2 Flooding with REA messages from inside 3239 Although we are more concerned with possible attacks from outside the 3240 network, we need also to consider possible attacks from inside the 3241 network. 3243 An adversary inside the network could send arbitrary RESERVE- 3244 EXTERNAL-ADDRESS messages. At a certain point the NAT will run out 3245 of port numbers and the access for other users to the outside will be 3246 disabled. 3248 SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state 3249 creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, 3250 the NAT/FW NSLP implementation MUST prevent denial of service 3251 attacks involving the allocation of an arbitrary number of NAT 3252 bindings or the installation of a large number of packet filters. 3254 7.2.3 Man-in-the-Middle Attacks 3256 Figure 48 illustrates a possible man-in-the-middle attack using the 3257 RESERVE-EXTERNAL-ADDRESS (REA) message. This message travels from DR 3258 towards the public Internet. The message might not be intercepted 3259 because there are no NSIS aware middleboxes. 3261 Imagine such an NSIS signaling message is then intercepted by an 3262 adversary Mallory (M). M returns a faked RESPONSE message whereby 3263 the adversary pretends that a NAT binding was created. This NAT 3264 binding is returned with the RESPONSE message. Malory might insert 3265 it own IP address in the response, the IP address of a third party or 3266 the address of a black hole. In the first case, the DR thinks that 3267 the address of Mallory M is its public address and will inform the DS 3268 about it. As a consequence, the DS will send the data traffic to 3269 Mallory M. 3271 The data traffic from the DS to the DR will re-directed to Mallory M. 3273 M will be able to read, modify or block the data traffic (if the end- 3274 to-end communication itself does not experience protection). 3275 Eavesdropping and modification is only possible if the data traffic 3276 is itself unprotected. 3278 +-----+ +-----+ +-----+ 3279 | DS | | M | | DR | 3280 +-----+ +-----+ +-----+ 3281 | | | 3282 | | REA | 3283 | | <------------------ | 3284 | | | 3285 | | RESPONSE | 3286 | | ------------------> | 3287 | | | 3288 | data traffic | | 3289 |===============>| data traffic | 3290 | |====================>| 3292 Figure 48: MITM attack using the RESERVE-EXTERNAL-ADDRESS message 3294 SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW 3295 NSLP MUST be provided. To ensure that only legitimate nodes along 3296 the path act as NSIS entities the initiator MUST authorize the 3297 responder. In the example in Figure 48 the firewall FW must 3298 perform an authorization with the neighboring entities. 3300 7.2.4 Message Modification by non-NSIS on-path node 3302 An unauthorized on-path node along the path towards the destination 3303 could easily modify, inject or just drop an NSIS message. It could 3304 also hijack or disrupt the communication. 3306 SECURITY REQUIREMENT: Message integrity, replay protection and data 3307 origin authentication between neighboring NAT/FW NSLPs MUST be 3308 provided. 3310 7.2.5 Message Modification by malicous NSIS node 3312 Message modification by a NSIS node that became malicious is more 3313 serious. An adversary could easily create arbitrary pinholes or NAT 3314 bindigs. For example: 3316 o NATs need to modify the source/destination of the data flow in the 3317 'create session' message. 3319 o Each middlebox along the path may change the requested lifetime in 3320 the CREATE message to fit their needs and/or local policy. 3322 SECURITY REQUIREMENT: None. Malicous NSIS NATs and Firewalls will 3323 not be addressed. 3325 7.2.6 Session Modification/Deletion 3327 The Session ID is included in signaling messages as a reference to 3328 the established state. If an adversary is able to obtain the Session 3329 Identifier for example by eavesdropping on signaling messages, it 3330 would be able to add the same Session Identifier to a new signaling 3331 message and effect some modifications. 3333 Consider the scenario described in Figure 49. Here an adversary 3334 pretends to be 'DS in mobility'. The signaling messages start from 3335 the DS and go through a series of routers towards the DR. We assume 3336 that an off-path adversary is connected to one of the routers along 3337 the old path (here Router 3). We also assume that the adversary 3338 knows the Session ID of the NSIS session initiated by the DS. 3339 Knowing the Session ID, the adversary now sends signalling messages 3340 towards the DR. When the signaling message reaches Router3 then 3341 existing state information can be modified or even deleted. The 3342 adversary can modify or delete the established reservation causing 3343 unexpected behavior for the legitimate user. The source of the 3344 problem is that the Router 3 (cross-over router) is unable to decide 3345 whether the new signaling message was initiated from the owner of the 3346 session. In this scenario, the adversary need not even be located in 3347 the DS-DR path. This problem and the solution approaches are 3348 described in more detail in [23]. 3350 Session ID(SID-x) 3351 +--------+ +--------+ 3352 +-------->--------+ Router +-------->+ DR | 3353 Session ID(SID-x)| | 4 | | | 3354 +---+----+ +--------+ +--------+ 3355 | Router | 3356 +------+ 3 +******* 3357 | +---+----+ * 3358 | * 3359 | Session ID(SID-x) * Session ID(SID-x) 3360 +---+----+ +---+----+ 3361 | Access | | Access | 3362 | Router | | Router | 3363 | 1 | | 2 | 3364 +---+----+ +---+----+ 3365 | * 3366 | Session ID(SID-x) * Session ID(SID-x) 3367 +----+------+ +----+------+ 3368 | DS | | Adversary | 3369 | | | | 3370 +-----------+ +-----------+ 3372 Figure 49: State Modification by off-path adversary 3374 As a summary, an off-path adversary's knowledge of Session-ID could 3375 cause session modification/deletion. 3377 SECURITY REQUIREMENT: The initiator MUST be able to demonstrate 3378 ownership of the session it wishes to modify. 3380 7.2.6.1 Misuse of mobility in NAT handling 3382 Another kind of session modification is related to mobility 3383 scenarios. NSIS allows end hosts to be mobile, it is possible that 3384 an NSIS node behind a NAT needs to update its NAT binding in case of 3385 address change. Whenever a host behind a NAT initiates a data 3386 transfer, it is assigned an external IP and port number. In typical 3387 mobility scenarios, the DR might also obtain a new address according 3388 to the topology and it should convey its new IP address to the NAT. 3389 The NAT is assumed to modify these NAT bindings based on the new IP 3390 address conveyed by the endhost. 3392 Public Private Address 3393 Internet space 3395 +----------+ +----------+ 3396 +----------| NAT |------------------|End host | 3397 | | | | 3398 +----------+ +----------+ 3399 | 3400 | +----------+ 3401 \--------------------|Malicious | 3402 |End host | 3403 +----------+ 3404 data traffic 3405 <======================== 3407 Figure 50: Misuse of mobility in NAT binding 3409 A NAT binding can be changed with the help of NSIS signalling. When 3410 a DR moves to a new location and obtains a new IP address, it sends 3411 an NSIS signalling message to modify the NAT binding. It would use 3412 the Session-ID and the new flow-id to update the state. The NAT 3413 updates the binding and the DR continues to receive the data traffic. 3414 Consider the scenario in Figure 50 where an the endhost(DR) and the 3415 adversary are behind a NAT. The adversary pretending that it is the 3416 end host could generate a spurious signaling message to update the 3417 state at the NAT. This could be done for these purposes: 3419 Connection hijacking by redirecting packets to the attacker as in 3420 Figure 51 3422 Third party flooding by redirecting packets to arbitrary hosts 3424 Service disruption by redirecting to non-existing hosts 3425 +----------+ +----------+ +----------+ 3426 | NAT | |End host | |Malicious | 3427 | | | | |End host | 3428 +----------+ +----------+ +----------+ 3429 | | | 3430 | Data Traffic | | 3431 |--------->----------| | 3432 | | Spurious | 3433 | | NAT binding update | 3434 |---------<----------+--------<------------| 3435 | | | 3436 | Data Traffic | | 3437 |--------->----------+-------->------------| 3438 | | | 3440 Figure 51: Connection Hijacking 3442 SECURITY REQUIREMENT: A NAT/FW signaling message MUST be 3443 authenticated, authorized, integrity protected and replay 3444 protected between neighboring NAT/FW NSLP nodes. 3446 7.2.7 Misuse of unreleased sessions 3448 Assume that DS (N1) initiates NSIS session with DR (N2) through a 3449 series of middleboxes as in Figure 52. When the DS is sending data 3450 to DR, it might happen that the DR disconnects from the network 3451 (crashes or moves out of the network in mobility scenarios). In such 3452 cases, it is possible that another node N3 (which recently entered 3453 the network protected by the same firewall) is assigned the same IP 3454 address that was previously allocated to N2. The DS could take 3455 advantage of the firewall policies installed already, if the refresh 3456 interval time is very high. The DS can flood the node (N3), which 3457 will consume the access network resources of the victim forcing it to 3458 pay for unwanted traffic as shown in Figure 53. Note that here we 3459 make the assumption that the data receiver has to pay for receiving 3460 data packets. 3462 Public Internet 3463 +--------------------------+ 3464 | | 3465 +-------+ CREATE +---+-----+ +-------+ | 3466 | |-------------->------| |---->---| | | 3467 | N1 |--------------<------| FW |----<---| N2 | | 3468 | | success RESPONSE | | | | | 3469 | |==============>======| |====>===| | | 3470 +-------+ Data Traffic +---+-----+ +-------+ | 3471 | | 3472 +--------------------------+ 3474 Figure 52: Before mobility 3476 Public Internet 3477 +--------------------------+ 3478 | | 3479 +-------+ +---+-----+ +-------+ | 3480 | | | | | | | 3481 | N1 |==============>======| FW |====>===| N3 | | 3482 | | Data Traffic | | | | | 3483 +-------+ +---+-----+ +-------+ | 3484 | | 3485 +--------------------------+ 3487 Figure 53: After mobility 3489 Also, this threat is valid for the other direction as well. The DS 3490 which is communicating with the DR may disconnect from the network 3491 and this IP address may be assigned to a new node that had recently 3492 entered the network. This new node could pretend to be the DS and 3493 send data traffic to the DR in conformance with the firewall policies 3494 and cause service disruption. 3496 SECURITY REQUIREMENT: Data origin authentication is needed to 3497 mitigate this threat. In order to allow firewalls to verify that 3498 a legitimate end host transmitted the data traffic data origin 3499 authentication is required. This is, however, outside the scope 3500 of this document. Hence, there are no security requirements 3501 imposed by this section which will be addressed by the NATFW NSLP. 3503 7.2.8 Data traffic injection 3505 In some environments, such as enterprise networks, it is still common 3506 to perform authorization for access to a service based on the source 3507 IP address of the service requestor. There is no doubt that this by 3508 itself represents a security weakness.Hence by spoofing a connection, 3509 an attacker is able to reach the target machines, using the existing 3510 firewall rules. 3512 The adversary is able to inject its own data traffic in conformance 3513 with the firewall policies simultaneously along with the genuine DS. 3515 SECURITY REQUIREMENT: Since IP spoofing is a general limitation of 3516 non-cryptographic packet filters no security requirement needs to 3517 be created for the NAT/FW NSLP. Techniques such as ingress 3518 filtering (described below) and data origin authentication (such 3519 as provided with IPsec based VPNs) can help mitigate this threat. 3520 This issue is, however, outside the scope of this document. 3522 Ingress Filtering: Consider the scenario shown in Figure 54. In this 3523 scenario the DS is behind a router (R1) and a malicious node (M) is 3524 behind another router (R2). The DS communicates with the DR through 3525 a firewall (FW). The DS initiates NSIS signaling and installs 3526 firewall policies at FW. But the malicious node is also able to send 3527 data traffic using DS's source address. If R2 implements ingress 3528 filtering, these spoofed packets will be blocked. But this ingress 3529 filtering may not work in all scenarios. If both the DS and the 3530 malicious node are behind the same router, then the ingress filter 3531 will not be able to detect the spoofed packets as both the DS and the 3532 malicious node are in the same address range. 3534 +-----------------------------------+ 3535 | +------------------+ | 3536 | | +-------+ +---+---+ | 3537 | | | DS +>--+ R1 +->+ | 3538 | | | | | | | | 3539 | | +-------+ +---+---+ | | 3540 | | | | | 3541 | +------------------+ | +---+---+ +-------+ 3542 | | | | | | 3543 | +---+ FW +-->--| DR | 3544 | +------------------+ ****| |*****| | 3545 | | | * +---+---+ +-------+ 3546 | | +-------+ +---+---+ * | 3547 | | | M | | R2 | * | 3548 | | | |***| |*** | 3549 | | +-------+ +---+---+ | 3550 | +------------------+ | 3551 +-----------------------------------+ 3553 ---->---- = genuine data traffic 3554 ********* = spoofed data traffic 3556 Figure 54: Ingress filtering 3558 7.2.9 Eavesdropping and traffic analysis 3560 By collecting NSLP messages, an adversary is able to learn policy 3561 rules for packet filters and knows which ports are open. It can use 3562 this to inject its own data traffic due to the IP spoofing capability 3563 as already mentioned in Section 7.2.8. 3565 An adversary could learn authorization tokens included in CREATE 3566 messages and use them to launch replay-attacks or to create a session 3567 with its own address as source address. (cut-and-paste attack) 3569 As shown in Section 4.3 of [23] one possible solution for the session 3570 ownership problem is confidentiality protection of signaling messages 3572 SECURITY REQUIREMENT: The threat of eavesdropping itself does not 3573 mandate the usage of confidentiality protection since an adversary 3574 can also eavesdrop on data traffic. In the context of a 3575 particular security solutions (e.g., authorization tokens) it 3576 might be necessary to offer confidentiality protection. 3577 Confidentiality protection also needs to be offered to the refresh 3578 period. 3580 7.3 Security Framework for the NAT/Firewall NSLP 3582 Based on the identified threats a list of security requirements has 3583 been created. 3585 7.3.1 Security Protection between neighboring NATFW NSLP Nodes 3587 Based on the analyzed threats it is necessary to provide, between 3588 neighboring NATFW NSLP nodes, the following mechanism: provide 3590 o data origin authentication 3592 o replay protection 3594 o integrity protection and 3596 o optionally confidentiality protection 3598 To consider the aspect of authentication and key exchange the 3599 security mechanisms provided in [1] between neighboring nodes MUST be 3600 enabled when sending NATFW signaling messages. The proposed security 3601 mechanisms at GIMPS provide support for authentication and key 3602 exchange in addition to denial of service protection. Depending on 3603 the chosen protocol, support for flexible authentication protocols 3604 could be provided. The mandatory support for security, demands the 3605 usage of C-MODE for the delivery of data packets and the usage of 3606 D-MODE only to discover the next NATFW NSLP aware node along the 3607 path. 3609 7.3.2 Security Protection between non-neighboring NATFW NSLP Nodes 3611 Based on the security threats and the listed requirements it was 3612 noted that some scenarios also demand authentication and 3613 authorization of a NATFW signaling entity (including the initiator) 3614 towards a non-neighboring node. This mechanism mainly demands entity 3615 authentication. Additionally, security protection of certain 3616 payloads MAY be required between non-neighboring signaling entities 3617 and the Cryptographic Message Syntax (CMS) [17] SHOULD be used. CMS 3618 can be used 3620 o This might be, for example, useful to authenticate and authorize a 3621 user towards a middlebox and vice versa. 3623 o If objects have to be protected between certain non-neighboring 3624 NATFW NSLP nodes. 3626 Details about the identifiers, replay protection and the usage of a 3627 dynamic key management with the help of CMS is for further study. In 3628 some scenarios it is also required to use authorization token. Their 3629 purpose is to associate two different signalling protocols (e.g., SIP 3630 and NSIS) and their authorization decision. These tokens are 3631 obtained by non-NSIS protocols, such as SIP or as part of network 3632 access authentication. When a NAT or Firewall along the path 3633 receives the token it might be verified locally or passed to the AAA 3634 infrastructure. 3636 Examples of authorization tokens or assertions can be found in RFC 3637 3520 [29] and RFC 3521 [30]. More recent work on authorization token 3638 alike mechanisms is Security Assertion Markup Language (SAML). For 3639 details about SAML see [31], [32] and [33]. Figure 55 shows an 3640 example of this protocol interaction. An authorization token is 3641 provided by the SIP proxy, which acts as the assertion generating 3642 entity and gets delivered to the end host with proper authentication 3643 and authorization. When the NATFW signalling message is transmitted 3644 towards the network, the authorization token is attached to the 3645 signalling messages to refer to the previous authorization decision. 3646 The assertion verifying entity needs to process the token or it might 3647 be necessary to interact with the assertion granting entity using 3648 HTTP (or other protocols). As a result of a successful authorization 3649 by a NATFW NSLP node, the requested action is executed and later a 3650 RESPONSE message is generated. 3652 +----------------+ Trust Relationship +----------------+ 3653 | +------------+ |<.......................>| +------------+ | 3654 | | Protocol | | | | Assertion | | 3655 | | requesting | | HTTP, SIP Request | | Granting | | 3656 | | authz | |------------------------>| | Entity | | 3657 | | assertions | |<------------------------| +------------+ | 3658 | +------------+ | Artifact/Assertion | Entity Cecil | 3659 | ^ | +----------------+ 3660 | | | ^ ^| 3661 | | | . || HTTP, 3662 | | | Trust . || other 3663 | API Access | Relationship. || protocols 3664 | | | . || 3665 | | | . || 3666 | | | v |v 3667 | v | +----------------+ 3668 | +------------+ | | +------------+ | 3669 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3670 | | using authz| | Assertion/Artifact | | Verifying | | 3671 | | assertion | | ----------------------- | | Entity | | 3672 | +------------+ | | +------------+ | 3673 | Entity Alice | <---------------------- | Entity Bob | 3674 +----------------+ RESPONSE +----------------+ 3676 Figure 55: Authorization Token Usage 3678 Threats against the usage of authorization tokens have been mentioned 3679 in [6] and also in Section 7.2. Hence, it is required to provide 3680 confidentiality protection to avoid allowing an eavesdropper to learn 3681 the token and to use it in another session (replay attack). The 3682 token itself also needs to be protected against tempering. 3684 7.3.3 End-to-End Security 3686 As part of the threat analysis we concluded that end-to-end security 3687 is not required and, if used, would be difficult to deploy. 3688 Furthermore, it might be difficult to use the suitable identifiers 3689 and to establish the necessary infrastructure for this propose. 3691 The only reasonable end-to-end security protection needed within NSIS 3692 seems to be a binding between an NSIS signaling session and 3693 application layer session. This aspect is, however, for further 3694 study. 3696 In order to solicit feedback from the IETF community on some hard 3697 security problems for path-coupled NATFW signaling a more detailed 3698 description in [20] is available. 3700 8. Open Issues 3702 The NATFW NSLP has a series of related documents discussing several 3703 other aspects of path-coupled NATFW signaling, including security 3704 [20], migration (i.e., traversal of nsis unaware NATs) [13], intra- 3705 realm signaling [14], and inter-working with SIP [15]. Summaries of 3706 the outcomes from these documents may be added, depending on WG 3707 feedback, to a later version of this draft. 3709 A more detailed list of open issue can be found at: 3710 https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/index 3712 It is intended to add an overview figure for all NATFW NSLP building 3713 blocks into the next version of this memo. Figure 56 sketches the 3714 overview 3716 +------------------+ 3717 |Security Policies | 3718 | Server | 3719 +--------^---------+ 3720 | 3721 +--------------------------------|----------------------+ 3722 | +---------+ +-----------V----+ +-------+| 3723 | |Firewall |<-----> | |<------>| NAT || 3724 | |Engine | | Security policy| | Engine|| 3725 | +----^----+ | Table/Cache | +-^-----+| 3726 | | | ^ | | | 3727 | | +---- --------|--+ | | 3728 | +--|---------------------------|-------------|--+ | 3729 | | V NATFW NSLP V V | | 3730 | | | | 3731 | +-----------------------------------------------+ | 3732 | +--------------------------------------------------+| 3733 | | GIMPS || 3734 | | || 3735 | +--------------------------------------------------+| 3736 | +---------+ +-------+ +------+ +-------+ +------+| 3737 | | TCP | | UDP | | DCCP | | SCTP | | ICMP || 3738 | +---------+ +-------+ +------+ +-------+ +------+| 3739 | +-----------------------------+ +--------------------| 3740 | | IPv4 | | IPv6 | 3741 | +-----------------------------+ +--------------------| 3742 +-------------------------------------------------------+ 3744 Figure 56: NATFW NSLP Building Blocks 3746 9. Contributors 3748 We would like to thank the following individuals for their 3749 contributions to this document: 3751 o Marcus Brunner and Henning Schulzrinne for work on work on IETF 3752 drafts which lead us to start with this document. 3754 o Miquel Martin for his help on the initial version of this 3755 document. 3757 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3758 NAT/Firewall Threats draft. 3760 o Elywn Davies for his help to make this document more readable. 3762 10. References 3764 10.1 Normative References 3766 [1] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for 3767 Signaling", draft-ietf-nsis-ntlp-05 (work in progress), 3768 February 2005. 3770 10.2 Informative References 3772 [2] Hancock, R., "Next Steps in Signaling: Framework", 3773 draft-ietf-nsis-fw-07 (work in progress), December 2004. 3775 [3] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 3776 April 2004. 3778 [4] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality- 3779 of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in 3780 progress), February 2005. 3782 [5] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 3783 Rayhan, "Middlebox communication architecture and framework", 3784 RFC 3303, August 2002. 3786 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 3787 draft-ietf-nsis-threats-06 (work in progress), October 2004. 3789 [7] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 3790 (NAT) Terminology and Considerations", RFC 2663, August 1999. 3792 [8] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 3793 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 3795 [9] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 3796 RFC 3234, February 2002. 3798 [10] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, 3799 "DNS extensions to Network Address Translators (DNS_ALG)", 3800 RFC 2694, September 1999. 3802 [11] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 3803 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 3804 Specification", RFC 2205, September 1997. 3806 [12] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 3807 Herzog, S., and R. Hess, "Identity Representation for RSVP", 3808 RFC 3182, October 2001. 3810 [13] Aoun, C., Brunner, M., Stiemerling, M., Martin, M., and H. 3811 Tschofenig, "NAT/Firewall NSLP Migration Considerations", 3812 draft-aoun-nsis-nslp-natfw-migration-02 (work in progress), 3813 July 2004. 3815 [14] Aoun, C., "NATFirewall NSLP Intra-realm considerations", 3816 draft-aoun-nsis-nslp-natfw-intrarealm-01 (work in progress), 3817 July 2004. 3819 [15] Martin, M., "SIP NSIS Interactions for NAT/Firewall Traversal", 3820 draft-martin-nsis-nslp-natfw-sip-01 (work in progress), 3821 July 2004. 3823 [16] Tschofenig, H., "Extended QoS Authorization for the QoS NSLP", 3824 draft-tschofenig-nsis-qos-ext-authz-00 (work in progress), 3825 July 2004. 3827 [17] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 3828 August 2002. 3830 [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3831 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3832 Session Initiation Protocol", RFC 3261, June 2002. 3834 [19] Ohba, Y., "Problem Statement and Usage Scenarios for PANA", 3835 draft-ietf-pana-usage-scenarios-06 (work in progress), 3836 April 2003. 3838 [20] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security 3839 Problems", 3840 DRAFT draft-tschofenig-nsis-natfw-security-problems-00.txt, 3841 July 2004. 3843 [21] Tschofenig, H., Buechli, M., Van den Bosch, S., and H. 3844 Schulzrinne, "NSIS Authentication, Authorization and Accounting 3845 Issues", March 2003. 3847 [22] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 3848 Traversal of VPN Gateways", 3849 DRAFT draft-ietf-mobileip-vpn-problem-statement-req-02.txt, 3850 April 2003. 3852 [23] Tschofenig, H., "Security Implications of the Session 3853 Identifier", draft-tschofenig-nsis-sid-00 (work in progress), 3854 June 2003. 3856 [24] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 3857 - Simple Traversal of User Datagram Protocol (UDP) Through 3858 Network Address Translators (NATs)", RFC 3489, March 2003. 3860 [25] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 3861 Lear, "Address Allocation for Private Internets", BCP 5, 3862 RFC 1918, February 1996. 3864 [26] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 3865 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and 3866 S. Waldbusser, "Terminology for Policy-Based Management", 3867 RFC 3198, November 2001. 3869 [27] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 3870 draft-rosenberg-midcom-turn-07 (work in progress), 3871 February 2005. 3873 [28] Tschofenig, H., "Using SAML for SIP", 3874 draft-tschofenig-sip-saml-02 (work in progress), December 2004. 3876 [29] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 3877 Authorization Policy Element", RFC 3520, April 2003. 3879 [30] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session 3880 Set-up with Media Authorization", RFC 3521, April 2003. 3882 [31] Maler, E., Philpott, R., and P. Mishra, "Bindings and Profiles 3883 for the OASIS Security Assertion Markup Language (SAML) V1.1", 3884 September 2003. 3886 [32] Maler, E., Philpott, R., and P. Mishra, "Assertions and 3887 Protocol for the OASIS Security Assertion Markup Language 3888 (SAML) V1.1", September 2003. 3890 [33] Maler, E. and J. Hughes, "Technical Overview of the OASIS 3891 Security Assertion Markup Language (SAML) V1.1", March 2004. 3893 Authors' Addresses 3895 Martin Stiemerling 3896 Network Laboratories, NEC Europe Ltd. 3897 Kurfuersten-Anlage 36 3898 Heidelberg 69115 3899 Germany 3901 Phone: +49 (0) 6221 905 11 13 3902 Email: stiemerling@netlab.nec.de 3903 URI: http://www.stiemerling.org 3904 Hannes Tschofenig 3905 Siemens AG 3906 Otto-Hahn-Ring 6 3907 Munich 81739 3908 Germany 3910 Phone: 3911 Email: Hannes.Tschofenig@siemens.com 3912 URI: http://www.tschofenig.com 3914 Cedric Aoun 3915 Nortel/ENST Paris 3916 France 3918 Email: cedric.aoun@nortel.com 3920 Appendix A. Firewall and NAT Resources 3922 The NATFW NSLP carries, in conjunction with the NTLP's Message 3923 Routing Information (MRI), the policy rules to be installed at NATFW 3924 peers. This policy rule is an abstraction with respect to the real 3925 policy rule to be installed at the respective firewall or NAT, since 3926 it only conveys the initiator's request and must be mapped to the 3927 possible configuration on the particular used NAT and/or firewall. 3928 For pure firewalls a filter rule must be created and for pure NATs a 3929 NAT binding must be created. In mixed firewall and NAT boxes, the 3930 policy rule must be mapped in filter rules and bindings observing the 3931 ordering of the firewall and NAT engine. Depending on the ordering, 3932 NAT before firewall or vice versa, the firewall rules must carry 3933 private or public addresses. However, the exact mapping depends on 3934 the implementation of the firewall or NAT and is very different per 3935 vendor. The remainder of this section gives thus only an abstract 3936 mapping of NATFW NSLP policy rules to firewall rules and NAT 3937 bindings, without going into the specifics on single configuration 3938 parameter possibilities. 3940 A policy rule consists out of the message routing information (MRI), 3941 carried in the NTLP, and information available in the NATFW NSLP. 3942 The information of the NSLP is stored in the extend flow information 3943 object and the message type, in particular the flow direction. 3944 Additional information, such as the external IP address and port 3945 number, stored in the NAT or firewall will be used as well. 3947 EDITOR's NOTE: This section needs to describe how to map flow routing 3948 information to middlebox policy rules. Further, this section must 3949 clarify wildcarding. 3951 EDITOR's NOTE: Should this section describe how NATFW NSLP messages 3952 are handled in twice-NATs? 3954 A.1 Mapping to Firewall Rules 3956 EDITOR's NOTE: This section is to be done (CREATE, UCREATE). 3958 A.2 Mapping to NAT Bindings 3960 EDITOR's NOTE: This section is to be done (CREATE, REA). 3962 A.3 Mapping for combined NAT and Firewall 3964 EDITOR's NOTE: This section is to be done. 3966 Appendix B. Problems and Challenges 3968 This section describes a number of problems that have to be addressed 3969 for NSIS NAT/Firewall. Issues presented here are subject to further 3970 discussions. These issues might be also of relevance to other NSLP 3971 protocols. 3973 B.1 Missing Network-to-Network Trust Relationship 3975 Peer-to-peer trust relationship, as shown in Figure 38, is a very 3976 convenient assumption that allows simplified signaling message 3977 processing. However, it might not always be applicable, especially 3978 between two arbitrary access networks (over a core network where 3979 signaling messages are not interpreted). Possibly peer-to-peer trust 3980 relationship does not exist because of the large number of networks 3981 and the unwillingness of administrators to have other network 3982 operators to create holes in their Firewalls without proper 3983 authorization. 3985 +----------------------+ +--------------------------+ 3986 | | | | 3987 | Network A | | Network B | 3988 | | | | 3989 | +---------+ Missing +---------+ | 3990 | +-///-+ Middle- | Trust | Middle- +-///-+ | 3991 | | | box 1 | Relation- | box 2 | | | 3992 | | +---------+ ship +---------+ | | 3993 | | | or | | | 3994 | | | Authorization| | | 3995 | | | | | | 3996 | | Trust | | Trust | | 3997 | | Relationship | | Relationship | | 3998 | | | | | | 3999 | | | | | | 4000 | | | | | | 4001 | +--+---+ | | +--+---+ | 4002 | | Host | | | | Host | | 4003 | | A | | | | B | | 4004 | +------+ | | +------+ | 4005 +----------------------+ +--------------------------+ 4007 Figure 57: Missing Network-to-Network Trust Relationship 4009 Figure 57 illustrates a problem whereby an external node is not 4010 allowed to manipulate (create, delete, query, etc.) packet filters at 4011 a Firewall. Opening pinholes is only allowed for internal nodes or 4012 with a certain authorization permission. Hence the solution 4013 alternatives in Section 3.3.2 focus on establishing the necessary 4014 trust with cooperation of internal nodes. 4016 B.2 Relationship with routing 4018 The data path is following the "normal" routes. The NAT/FW devices 4019 along the data path are those providing the service. In this case 4020 the service is something like "open a pinhole" or even more general 4021 "allow for connectivity between two communication partners". The 4022 benefit of using path-coupled signaling is that the NSIS NATFW NSLP 4023 does not need to determine what middleboxes or in what order the data 4024 flow will go through. 4026 Creating NAT bindings modifies the path of data packets between two 4027 end points. Without NATs involved, packets flow from endhost to 4028 endhost following the path given by the routing. With NATs involved, 4029 this end-to-end flow is not directly possible, because of separated 4030 address realms. Thus, data packets flow towards the external IP 4031 address at a NAT (external IP address may be a public IP address). 4032 Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with 4033 routing - instead they only follow the path of the data packets. 4035 B.3 Affected Parts of the Network 4037 NATs and Firewalls are usually located at the edge of the network, 4038 whereby other signaling applications affect all nodes along the path. 4039 One typical example is QoS signaling where all networks along the 4040 path must provide QoS in order to achieve true end-to-end QoS. In 4041 the NAT/Firewall case, only some of the domains/nodes are affected 4042 (typically access networks), whereas most parts of the networks and 4043 nodes are unaffected (e.g., the core network). 4045 This fact raises some questions. Should an NSIS NTLP node intercept 4046 every signaling message independently of the upper layer signaling 4047 application or should it be possible to make the discovery procedure 4048 more intelligent to skip nodes. These questions are also related to 4049 the question whether NSIS NAT/FW should be combined with other NSIS 4050 signaling applications. 4052 B.4 NSIS backward compatibility with NSIS unaware NAT and Firewalls 4054 Backward compatibility is a key for NSIS deployments, as such the 4055 NSIS protocol suite should be sufficiently robust to allow traversal 4056 of none NSIS aware routers (QoS gates, Firewalls, NATs, etc ). 4058 NSIS NATFW NSLP's backward compatibility issues are different than 4059 the NSIS QoS NSLP backward compatibility issues, where an NSIS 4060 unaware QoS gate will simply forward the QoS NSLP message. An NSIS 4061 unaware Firewall rejects NSIS messages, since Firewalls typically 4062 implement the policy "default to deny". 4064 The NSIS backward compatibility support on none NSIS aware Firewall 4065 would typically consist of configuring a static policy rule that 4066 allows the forwarding of the NSIS protocol messages (either protocol 4067 type if raw transport mode is used or transport port number in case a 4068 transport protocol is used). 4070 For NATs backward compatibility is more problematic since signaling 4071 messages are forwarded (at least in one direction), but with a 4072 changed IP address and changed port numbers. The content of the NSIS 4073 signaling message is, however, unchanged. This can lead to 4074 unexpected results, both due to embedded unchanged local scoped 4075 addresses and none NSIS aware Firewalls configured with specific 4076 policy rules allowing forwarding of the NSIS protocol (case of 4077 transport protocols are used for the NTLP). NSIS unaware NATs must 4078 be detected to maintain a well-known deterministic mode of operation 4079 for all the involved NSIS entities. Such a "legacy" NAT detection 4080 procedure can be done during the NSIS discover procedure itself. 4082 Based on experience it was discovered that routers unaware of the 4083 Router Alert IP option [RFC 2113] discarded packets, this is 4084 certainly a problem for NSIS signaling. 4086 B.5 Authentication and Authorization 4088 For both types of middleboxes, Firewall and NAT security is a strong 4089 requirement. Authentication and authorization means must be 4090 provided. 4092 For NATFW signaling applications it is partially not possible to do 4093 authentication and authorization based on IP addresses. Since NATs 4094 change IP addresses, such an address based authentication and 4095 authorization scheme would fail. 4097 B.6 Directional Properties 4099 There two directional properties that need to be addressed by the 4100 NATFW NSLP: 4102 o Directionality of the data 4104 o Directionality of NSLP signaling 4106 Both properties are relevant to NATFW NSLP aware NATs and Firewalls. 4108 With regards to NSLP signaling directionality: As stated in the 4109 previous sections, the authentication and authorization of NSLP 4110 signaling messages received from hosts within the same trust domain 4111 (typically from hosts located within the security perimeter delimited 4112 by Firewalls) is normally simpler than received messages sent by 4113 hosts located in different trust domains. 4115 The way NSIS signaling messages enters the NSIS entity of a Firewall 4116 (see Figure 2) might be important, because different policies might 4117 apply for authentication and admission control. 4119 Hosts deployed within the secured network perimeter delimited by a 4120 Firewall, are protected from hosts deployed outside the secured 4121 network perimeter, hence by nature the Firewall has more restrictions 4122 on flows triggered from hosts deployed outside the security 4123 perimeter. 4125 B.7 Addressing 4127 A more general problem of NATs is the addressing of the end-point. 4128 NSIS signaling message have to be addressed to the other end host to 4129 follow data packets subsequently sent. Therefore, a public IP 4130 address of the receiver has to be known prior to sending an NSIS 4131 message. When NSIS signaling messages contain IP addresses of the 4132 sender and the receiver in the signaling message payloads, then an 4133 NSIS entity must modify them. This is one of the cases, where a NSIS 4134 aware NATs is also helpful for other types of signaling applications 4135 e.g., QoS signaling. 4137 B.8 NTLP/NSLP NAT Support 4139 It must be possible for NSIS NATs along the path to change NTLP 4140 and/or NSLP message payloads, which carry IP address and port 4141 information. This functionality includes the support of providing 4142 mid-session and mid-path modification of these payloads. As a 4143 consequence these payloads must not be reordered, integrity protected 4144 and/or encrypted in a non peer-to-peer fashion (e.g., end-to-middle, 4145 end-to-end protection). Ideally these mutable payloads must be 4146 marked (e.g., a protected flag) to assist NATs in their effort of 4147 adjusting these payloads. 4149 B.9 Combining Middlebox and QoS signaling 4151 In many cases, middlebox and QoS signaling has to be combined at 4152 least logically. Hence, it was suggested to combine them into a 4153 single signaling message or to tie them together with the help of 4154 some sort of data connection identifier, later on referred as Session 4155 ID. This, however, has some disadvantages such as: 4157 - NAT/FW NSLP signaling affects a much small number of NSIS nodes 4158 along the path (for example compared to the QoS signaling). 4160 - NAT/FW signaling might show different signaling patterns (e.g., 4161 required end-to-middle communication). 4163 - The refresh interval is likely to be different. 4165 - The number of error cases increase as different signaling 4166 applications are combined into a single message. The combination of 4167 error cases has to be considered. 4169 B.10 Inability to know the scenario 4171 In Section 2 a number of different scenarios are presented. Data 4172 receiver and sender may be located behind zero, one, or more 4173 Firewalls and NATs. Depending on the scenario, different signaling 4174 approaches have to be taken. For instance, data receiver with no 4175 NAT and Firewall can receive any sort of data and signaling without 4176 any further action. Data receivers behind a NAT must first obtain a 4177 public IP address before any signaling can happen. The scenario 4178 might even change over time with moving networks, ad-hoc networks or 4179 with mobility. 4181 NSIS signaling must assume the worst case and cannot put 4182 responsibility to the user to know which scenario is currently 4183 applicable. As a result, it might be necessary to perform a 4184 "discovery" periodically such that the NSIS entity at the end host 4185 has enough information to decide which scenario is currently 4186 applicable. This additional messaging, which might not be necessary 4187 in all cases, requires additional performance, bandwidth and adds 4188 complexity. Additional, information by the user can provide 4189 information to assist this "discovery" process, but cannot replace 4190 it. 4192 Appendix C. Object ID allocation for testing 4194 TBD. 4196 Appendix D. Acknowledgments 4198 We would like to acknowledge: Vishal Sankhla and Joao Girao for their 4199 input to this draft; and Reinaldo Penno for his comments on the 4200 initial version of the document. Furthermore, we would like thank 4201 Elwyn Davies for his valuable help and input. 4203 Intellectual Property Statement 4205 The IETF takes no position regarding the validity or scope of any 4206 Intellectual Property Rights or other rights that might be claimed to 4207 pertain to the implementation or use of the technology described in 4208 this document or the extent to which any license under such rights 4209 might or might not be available; nor does it represent that it has 4210 made any independent effort to identify any such rights. Information 4211 on the procedures with respect to rights in RFC documents can be 4212 found in BCP 78 and BCP 79. 4214 Copies of IPR disclosures made to the IETF Secretariat and any 4215 assurances of licenses to be made available, or the result of an 4216 attempt made to obtain a general license or permission for the use of 4217 such proprietary rights by implementers or users of this 4218 specification can be obtained from the IETF on-line IPR repository at 4219 http://www.ietf.org/ipr. 4221 The IETF invites any interested party to bring to its attention any 4222 copyrights, patents or patent applications, or other proprietary 4223 rights that may cover technology that may be required to implement 4224 this standard. Please address the information to the IETF at 4225 ietf-ipr@ietf.org. 4227 Disclaimer of Validity 4229 This document and the information contained herein are provided on an 4230 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4231 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4232 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4233 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4234 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4235 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4237 Copyright Statement 4239 Copyright (C) The Internet Society (2005). This document is subject 4240 to the rights, licenses and restrictions contained in BCP 78, and 4241 except as set forth therein, the authors retain all their rights. 4243 Acknowledgment 4245 Funding for the RFC Editor function is currently provided by the 4246 Internet Society.