idnits 2.17.1 draft-ietf-nsis-nslp-natfw-07.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 4494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4484. ** 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 1014 has weird spacing: '...creates polic...' == Line 1015 has weird spacing: '...rvation mode ...' == Line 1044 has weird spacing: '...nvolved will ...' == Line 1298 has weird spacing: '... o The data ...' == Line 1340 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 and includes a NONCE object having the same value as of the received NONCE object. 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 (July 18, 2005) is 6857 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 1441 -- Looks like a reference, but probably isn't: 'M' on line 2914 -- Looks like a reference, but probably isn't: 'O' on line 2903 -- Looks like a reference, but probably isn't: 'RFC 2113' on line 4342 == Unused Reference: '11' is defined on line 4020, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 4028, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 4045, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 4052, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 4056, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 4095, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-06 ** 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. '9') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '18') (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. '25') (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: January 19, 2006 H. Tschofenig 5 Siemens 6 C. Aoun 7 ENST 8 July 18, 2005 10 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 11 draft-ietf-nsis-nslp-natfw-07 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 January 19, 2006. 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 . . . . . . . . . . . . . . . . . . . . 36 83 3.3.7 Proxy Mode for Data Receiver behind NAT . . . . . . . 39 84 3.3.8 Proxy Mode for Data Sender behind Middleboxes . . . . 42 85 3.3.9 Proxy Mode for Data Receiver behind Firewall . . . . . 43 86 3.4 Calculation of Session Lifetime . . . . . . . . . . . . . 45 87 3.5 Message Sequencing . . . . . . . . . . . . . . . . . . . . 47 88 3.6 De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 48 89 3.7 Selecting Opportunistic Addresses for REA . . . . . . . . 49 90 3.8 Session Ownership . . . . . . . . . . . . . . . . . . . . 50 91 3.9 Authentication and Authorization . . . . . . . . . . . . . 53 92 3.10 Reacting to Route Changes . . . . . . . . . . . . . . . 54 94 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . 55 95 4.1 NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 55 96 4.2 NSLP message types . . . . . . . . . . . . . . . . . . . . 55 97 4.3 NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 56 98 4.3.1 Session Lifetime Object . . . . . . . . . . . . . . . 57 99 4.3.2 PBK Public Key . . . . . . . . . . . . . . . . . . . . 57 100 4.3.3 External Address Object . . . . . . . . . . . . . . . 58 101 4.3.4 Extended Flow Information Object . . . . . . . . . . . 59 102 4.3.5 Response Code Object . . . . . . . . . . . . . . . . . 59 103 4.3.6 Proxy Support Object . . . . . . . . . . . . . . . . . 60 104 4.3.7 Nonce Object . . . . . . . . . . . . . . . . . . . . . 60 105 4.3.8 Message Sequence Number Object . . . . . . . . . . . . 61 106 4.3.9 Bound Session ID Object . . . . . . . . . . . . . . . 61 107 4.3.10 Data Sender Information Object . . . . . . . . . . . 62 108 4.3.11 NATFW NF Hop Count Object . . . . . . . . . . . . . 62 109 4.3.12 Maximum Hops Object . . . . . . . . . . . . . . . . 63 110 4.3.13 Session Status object . . . . . . . . . . . . . . . 63 111 4.3.14 QDRQ type . . . . . . . . . . . . . . . . . . . . . 64 112 4.3.15 QDRQ Response object . . . . . . . . . . . . . . . . 64 113 4.4 Message Formats . . . . . . . . . . . . . . . . . . . . . 64 114 4.4.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . . 65 115 4.4.2 RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . . 65 116 4.4.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 66 117 4.4.4 QDRQ . . . . . . . . . . . . . . . . . . . . . . . . . 66 118 4.4.5 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 67 119 4.4.6 UCREATE . . . . . . . . . . . . . . . . . . . . . . . 67 121 5. NATFW NSLP NTLP Requirements . . . . . . . . . . . . . . . . 68 123 6. NSIS NAT and Firewall Transition Issues . . . . . . . . . . 69 125 7. Security Considerations . . . . . . . . . . . . . . . . . . 70 126 7.1 Trust Relationship and Authorization . . . . . . . . . . . 70 127 7.1.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . 71 128 7.1.2 Intra-Domain Trust Relationship . . . . . . . . . . . 71 129 7.1.3 End-to-Middle Trust Relationship . . . . . . . . . . . 72 130 7.2 Security Threats and Requirements . . . . . . . . . . . . 73 131 7.2.1 Attacks related to authentication and authorization . 73 132 7.2.2 Denial-of-Service Attacks . . . . . . . . . . . . . . 80 133 7.2.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 81 134 7.2.4 Message Modification by non-NSIS on-path node . . . . 82 135 7.2.5 Message Modification by malicious NSIS node . . . . . 82 136 7.2.6 Session Modification/Deletion . . . . . . . . . . . . 83 137 7.2.7 Misuse of unreleased sessions . . . . . . . . . . . . 86 138 7.2.8 Data traffic injection . . . . . . . . . . . . . . . . 87 139 7.2.9 Eavesdropping and traffic analysis . . . . . . . . . . 89 140 7.3 Security Framework for the NAT/Firewall NSLP . . . . . . . 90 141 7.3.1 Security Protection between neighboring NATFW NSLP 142 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 90 143 7.3.2 Security Protection between non-neighboring NATFW 144 NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 90 146 7.3.3 End-to-End Security . . . . . . . . . . . . . . . . . 92 148 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 93 150 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 94 152 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 153 10.1 Normative References . . . . . . . . . . . . . . . . . . 95 154 10.2 Informative References . . . . . . . . . . . . . . . . . 95 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 98 158 A. Firewall and NAT Resources . . . . . . . . . . . . . . . . . 99 159 A.1 Wildcarding of Policy Rules . . . . . . . . . . . . . . . 99 160 A.2 Mapping to Firewall Rules . . . . . . . . . . . . . . . . 100 161 A.3 Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 100 162 A.4 Mapping for combined NAT and Firewall . . . . . . . . . . 100 163 A.5 NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 100 165 B. Problems and Challenges . . . . . . . . . . . . . . . . . . 101 166 B.1 Missing Network-to-Network Trust Relationship . . . . . . 101 167 B.2 Relationship with routing . . . . . . . . . . . . . . . . 102 168 B.3 Affected Parts of the Network . . . . . . . . . . . . . . 102 169 B.4 NSIS backward compatibility with NSIS unaware NAT and 170 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 102 171 B.5 Authentication and Authorization . . . . . . . . . . . . . 103 172 B.6 Directional Properties . . . . . . . . . . . . . . . . . . 103 173 B.7 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 104 174 B.8 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 104 175 B.9 Combining Middlebox and QoS signaling . . . . . . . . . . 104 176 B.10 Inability to know the scenario . . . . . . . . . . . . . 105 178 C. Object ID allocation for testing . . . . . . . . . . . . . . 106 180 D. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 107 182 Intellectual Property and Copyright Statements . . . . . . . 108 184 1. Introduction 186 Firewalls and Network Address Translators (NAT) have both been used 187 throughout the Internet for many years, and they will remain present 188 for the foreseeable future. Firewalls are used to protect networks 189 against certain types of attacks from the outside, and in times of 190 IPv4 address depletion, NATs virtually extend the IP address space. 191 Both types of devices may be obstacles to some applications, since 192 they only allow traffic created by a limited set of applications to 193 traverse them (e.g., most HTTP traffic, and client/server 194 applications), due to the relatively static properties of the 195 protocols used. Other applications, such as IP telephony and most 196 other peer-to-peer applications, which have more dynamic properties, 197 create traffic which is unable to traverse NATs and Firewalls 198 unassisted. In practice, the traffic from many applications cannot 199 traverse autonomous Firewalls or NATs, even when they have added 200 functionality which attempts to restore the transparency of the 201 network. 203 Several solutions to enable applications to traverse such entities 204 have been proposed and are currently in use. Typically, application 205 level gateways (ALG) have been integrated with the Firewall or NAT to 206 configure the Firewall or NAT dynamically. Another approach is 207 middlebox communication (MIDCOM, currently under standardization at 208 the IETF). In this approach, ALGs external to the Firewall or NAT 209 configure the corresponding entity via the MIDCOM protocol [6]. 210 Several other work-around solutions are available, including STUN 211 [25] and TURN [28]. However, all of these approaches introduce other 212 problems that are generally hard to solve, such as dependencies on 213 the type of NAT implementation (full-cone, symmetric, ...), or 214 dependencies on certain network topologies. 216 NAT and Firewall (NATFW) signaling shares a property with Quality of 217 Service (QoS) signaling. The signaling of both must reach any device 218 on the data path that is involved in QoS or NATFW treatment of data 219 packets. This means, that for both, NATFW and QoS, it is convenient 220 if signaling travels path-coupled, meaning that the signaling 221 messages follow exactly the same path that the data packets take. 222 RSVP [12] is an example of a current QoS signaling protocol that is 223 path-coupled. [35] proposes the use of RSVP as firewall signaling 224 protocol but does not include NATs. 226 This memo defines a path-coupled signaling protocol for NAT and 227 Firewall configuration within the framework of NSIS, called the NATFW 228 NSIS Signaling Layer Protocol (NSLP). The general requirements for 229 NSIS are defined in [4]. The general framework of NSIS is outlined 230 in [3]. It introduces the split between an NSIS transport layer and 231 an NSIS signaling layer. The transport of NSLP messages is handled 232 by an NSIS Network Transport Layer Protocol (NTLP, with GIMPS [1] 233 being the implementation of the abstract NTLP). The signaling logic 234 for QoS and NATFW signaling is implemented in the different NSLPs. 235 The QoS NSLP is defined in [5], while the NATFW NSLP is defined in 236 this memo. 238 The NATFW NSLP is designed to request the dynamic configuration of 239 NATs and/or Firewalls along the data path. Dynamic configuration 240 includes enabling data flows to traverse these devices without being 241 obstructed as well as blocking of particular data flows at upstream 242 firewalls. Enabling data flows requires the loading of firewall pin 243 holes (loading of firewall rules with action allow) and creating NAT 244 bindings. Blocking of data flows requires the loading of firewalls 245 rules with action deny/drop. A simplified example for enabling data 246 flows: A source host sends a NATFW NSLP signaling message towards 247 its data destination. This message follows the data path. Every 248 NATFW NSLP NAT/Firewall along the data path intercepts these 249 messages, processes them, and configures itself accordingly. 250 Afterwards, the actual data flow can traverse every configured 251 Firewall/NAT. 253 It is necessary to distinguish between two different basic scenarios 254 when operating the NATFW NSLP, independent of the type of middlebox 255 to be configured. 257 1. Both data sender and data receiver of the network are NSIS NATFW 258 NSLP aware. This includes the cases where the data sender is 259 logically decomposed from the NSIS initiator or the data receiver 260 logically decomposed from the NSIS receiver, but both sides 261 support NSIS. This scenario assumes deployment of NSIS all over 262 the Internet, or at least at all NATs and firewalls. 264 2. Only one end host is NSIS NATFW NSLP aware, either data receiver 265 or data sender. 267 NATFW NSLP provides three modes to cope with various possible 268 scenarios likely to be encountered before and after widespread 269 deployment of NSIS. Once there is full deployment of NSIS (in the 270 sense that both end hosts support NATFW NSLP signaling), the 271 requisite NAT and firewall state can be created using either just 272 CREATE mode if the data receiver resides in a public addressing 273 realm, or a combination of RESERVE-EXTERNAL-ADDRESS and CREATE modes 274 if the data receiver resides in a private addressing realm and needs 275 to preconfigure the boundary NAT to provide a publicly reachable 276 address for use by the data sender. During the introduction of NSIS, 277 it is likely that one or other of the data sender and receiver will 278 not be NSIS capable. In these cases the NATFW NSLP can utilize NSIS 279 aware middleboxes on the path between the sender and receiver to 280 provide proxy NATFW NSLP services. Typically these boxes will be at 281 the boundaries of the realms in which the end hosts are located. If 282 the data receiver is NSIS unaware, the normal modes can be employed 283 but the NSIS signaling terminates at the NSIS aware node 284 topologically closest to the receiver which then acts as a proxy for 285 the receiver. If the data sender is unaware a variant of the 286 RESERVE-EXTERNAL-ADDRESS mode can be used by a data receiver behind a 287 NAT and the specialized UCREATE mode can be used by a data receiver 288 behind a firewall. 290 All modes of operation create NATFW NSLP and NTLP state in NSIS 291 entities. NTLP state allows signaling messages to travel in the 292 forward (downstream) and the reverse (upstream) direction along the 293 path between a NAT/Firewall NSLP sender and a corresponding receiver. 294 NAT bindings and firewall rules are NAT/Firewall specific state. 295 This state is managed using a soft-state mechanism, i.e., it expires 296 unless it is refreshed from time to time. 298 Section 2 describes the network environment for NATFW NSLP signaling, 299 highlighting the trust relationships and authorization required. 300 Section 3 defines the NATFW signaling protocol. Section 4 defines 301 the messages and and message components. In the remaining parts of 302 the main body of the document, Section 6 covers transition issues and 303 Section 7 addresses security considerations. Currently unsolved 304 problems and challenges are listed and discussed in Appendix B. 305 Please note that readers familiar with Firewalls and NATs and their 306 possible location within networks can safely skip Section 2. 308 1.1 Terminology and Abbreviations 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 311 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 312 document are to be interpreted as described in RFC 2119. 314 This document uses a number of terms defined in [4]. The following 315 additional terms are used: 317 o Policy rule: A policy rule is "a basic building block of a policy- 318 based system. It is the binding of a set of actions to a set of 319 conditions - where the conditions are evaluated to determine 320 whether the actions are performed" [27]. In the context of NSIS 321 NATFW NSLP, the condition is a specification of a set of packets 322 to which rules are applied. The set of actions always contains 323 just a single element per rule, and is limited to either action 324 "reserved", "deny" or action "allow". 326 o Firewall: A packet filtering device that matches packets against a 327 set of policy rules and applies the actions. In the context of 328 NSIS NATFW NSLP we refer to this device as a Firewall. 330 o Network Address Translator: Network Address Translation is a 331 method by which IP addresses are mapped from one IP address realm 332 to another, in an attempt to provide transparent routing between 333 hosts (see [8]). Network Address Translators are devices that 334 perform this work. 336 o Middlebox: "A middlebox is defined as any intermediate device 337 performing functions other than the normal, standard functions of 338 an IP router on the datagram path between a source host and a 339 destination host" [10]. In the context of this document, the term 340 middlebox refers to Firewalls and NATs only. Other types of 341 middlebox are currently outside of the scope of this document. 343 o Security Gateway: IPsec based gateways. 345 o (Data) Receiver (DR or R): The node in the network that is 346 receiving the data packets of a flow. 348 o (Data) Sender (DS or S): The node in the network that is sending 349 the data packets of a flow. 351 o NATFW NSLP session: An application layer flow of information for 352 which some network control state information is to be manipulated 353 or monitored (as defined in [3]). The control state for NATFW 354 NSLP consists of NSLP state and associated policy rules at a 355 middlebox. 357 o NSIS peer or peer: An NSIS node with which an NSIS adjacency has 358 been created as defined in [1]. 360 o Edge-NAT: An edge-NAT is a NAT device that is reachable from the 361 public Internet and that has a globally routable IP address. 363 o Edge-Firewall: An edge-Firewall is a Firewall device that is 364 located on the demarcation line of an administrative domain. 366 o Public Network: "A Global or Public Network is an address realm 367 with unique network addresses assigned by Internet Assigned 368 Numbers Authority (IANA) or an equivalent address registry. This 369 network is also referred as external network during NAT 370 discussions" [8]. 372 o Private/Local Network: "A private network is an address realm 373 independent of external network addresses. Private network may 374 also be referred alternately as Local Network. Transparent 375 routing between hosts in private realm and external realm is 376 facilitated by a NAT router" [8]. IP address space allocation for 377 private networks is recommended in [26] 379 o Public/Global IP address: An IP address located in the public 380 network according to Section 2.7 of [8]. 382 o Private/Local IP address: An IP address located in the private 383 network according to Section 2.8 of [8]. 385 o Initial CREATE: A CREATE message creating a new session. 387 1.2 Middleboxes 389 The term middlebox covers a range of devices which intercept the flow 390 of packets between end hosts and perform actions other than standard 391 forwarding expected in an IP router. As such, middleboxes fall into 392 a number of categories with a wide range of functionality, not all of 393 which is pertinent to the NATFW NSLP. Middlebox categories in the 394 scope of this memo are Firewalls that filter data packets against a 395 set of filter rules, and NATs that translate packet addresses from 396 one address realm to another address realm. Other categories of 397 middleboxes, such as QoS traffic shapers and security gateways, are 398 out of scope. 400 The term NAT used in this document is a placeholder for a range of 401 different NAT flavors. We consider the following types of NATs: 403 o traditional NAT (basic NAT and NAPT) 405 o Bi-directional NAT 407 o Twice-NAT 409 o Multihomed NAT 411 For definitions and a detailed discussion about the characteristics 412 of each NAT type please see [8]. 414 Both types of middleboxes under consideration here use policy rules 415 to make a decision on data packet treatment. Policy rules consist of 416 a flow identifier which selects the packets to which the policy 417 applies and an associated action; data packets matching the flow 418 identifier are subjected to the policy rule action. A typical flow 419 identifier is the 5-tuple selector which matches the following fields 420 of a packet to configured values: 422 o Source and destination IP addresses 424 o Transport protocol number 426 o Transport source and destination port numbers 428 For further examples of flow identifiers see Section 5.2.2 of [1]. 430 Actions for Firewalls are usually one or more of: 432 o Allow: forward data packet 434 o Deny: block data packet and discard it 436 o Other actions such as logging, diverting, duplicating, etc 438 Actions for NATs include (amongst many others): 440 o Change source IP address and transport port number to a globally 441 routeable IP address and associated port number. 443 o Change destination IP address and transport port number to a 444 private IP address and associated port number. 446 1.3 Non-Goals 448 Traversal of non-NSIS and non-NATFW NSLP aware NATs and Firewalls 449 is outside the scope of this document. 451 Only Firewalls and NATs are considered in this document, any other 452 types of devices, for instance IPSec security gateway, are out of 453 scope. 455 The exact implementation of policy rules and their mapping to 456 firewall rule sets and NAT bindings or sessions at the middlebox 457 is an implementation issue and thus out of scope of this document. 459 Some devices categorized as firewalls only accept traffic after 460 cryptographic verification (i.e., IPsec protected data traffic). 461 Particularly for network access scenarios, either link layer or 462 network layer data protection is common. We do not address these 463 types of devices (referred to as security gateways) since per-flow 464 signaling is typically not used in this environment. 466 Another application, for which NSIS signaling has been proposed 467 but which is out of scope for this document, is discovering 468 security gateways, for the purpose of executing IKE to create an 469 IPsec SA. 471 In mobility scenarios, a common problem is the traversal of a 472 security gateway at the edge of a corporate network. Network 473 administrators allow only authenticated data to enter the network. 474 A problem statement for the traversal of these security gateways 475 in the context of Mobile IP can be found in [23]). This topic is 476 not within the scope of the present document. 478 1.4 General Scenario for NATFW Traversal 480 The purpose of NSIS NATFW signaling is to enable communication 481 between endpoints across networks even in the presence of NAT and 482 Firewall middleboxes. It is assumed that these middleboxes will be 483 statically configured in such a way that NSIS NATFW signaling 484 messages themselves are allowed to traverse them. NSIS NATFW NSLP 485 signaling is used to dynamically install additional policy rules in 486 all NATFW middleboxes along the data path. Firewalls are configured 487 to forward data packets matching the policy rule provided by the NSLP 488 signaling. NATs are configured to translate data packets matching 489 the policy rule provided by the NSLP signaling. However, there is an 490 exception to the primary goal of NSIS NATFW signaling, NSIS NATFW 491 nodes can request blocking of particular data flows instead of 492 enabling these flows at upstream firewalls. 494 The basic high-level picture of NSIS usage is that end hosts are 495 located behind middleboxes, meaning that there is a middlebox on the 496 data path from the end host in a private network and the external 497 network (NAT/FW in Figure 1). Applications located at these end 498 hosts try to establish communication with corresponding applications 499 on other such end hosts. They trigger the NSIS entity at the local 500 host to provide for middlebox traversal along the prospective data 501 path (e.g., via an API call). The NSIS entity in turn uses NSIS 502 NATFW NSLP signaling to establish policy rules along the data path, 503 allowing the data to travel from the sender to the receiver 504 unobstructed. 506 Application Application Server (0, 1, or more) Application 508 +----+ +----+ +----+ 509 | +------------------------+ +------------------------+ | 510 +-+--+ +----+ +-+--+ 511 | | 512 | NSIS Entities NSIS Entities | 513 +-+--+ +----+ +-----+ +-+--+ 514 | +--------+ +----------------------------+ +-----+ | 515 +-+--+ +-+--+ +--+--+ +-+--+ 516 | | ------ | | 517 | | //// \\\\\ | | 518 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 519 | | | | | Internet | | | | | 520 | +--------+ +-----+ +----+ +-----+ | 521 +----+ +----+ |\ | +----+ +----+ 522 \\\\ ///// 523 sender NAT/FW (1+) ------ NATFW (1+) receiver 525 Figure 1: Generic View on NSIS in a NAT / Firewall case 527 For end-to-end NATFW signaling, it is necessary that each firewall 528 and each NAT along the path between the data sender and the data 529 receiver implements the NSIS NATFW NSLP. There might be several NATs 530 and FWs in various possible combinations on a path between two hosts. 531 Section 2 presents a number of likely scenarios with different 532 combinations of NATs and firewalls. 534 2. Network Deployment Scenarios using NATFW NSLP 536 This section introduces several scenarios for middlebox placement 537 within IP networks. Middleboxes are typically found at various 538 different locations, including at Enterprise network borders, within 539 enterprise networks, as mobile phone network gateways, etc. Usually, 540 middleboxes are placed more towards the edge of networks than in 541 network cores. Firewalls and NATs may be found at these locations 542 either alone, or they may be combined; other categories of 543 middleboxes may also be found at such locations, possibly combined 544 with the NATs and/or Firewalls. To reduce the number of network 545 elements needed, combined Firewall and NATs have been made available. 547 NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the 548 regular data path to the NSIS responder (NR). On the data path, 549 NATFW NSLP signaling messages reach different NSIS nodes that 550 implement the NATFW NSLP. Each NATFW NSLP node processes the 551 signaling messages according to Section 3 and, if necessary, installs 552 policy rules for subsequent data packets. 554 Each of the following sub-sections introduces a different scenario 555 for a different set of middleboxes and their ordering within the 556 topology. It is assumed that each middlebox implements the NSIS 557 NATFW NSLP signaling protocol. 559 2.1 Firewall Traversal 561 This section describes a scenario with Firewalls only; NATs are not 562 involved. Each end host is behind a Firewall. The Firewalls are 563 connected via the public Internet. Figure 2 shows the topology. The 564 part labeled "public" is the Internet connecting both Firewalls. 566 +----+ //----\\ +----+ 567 NI -----| FW |---| |------| FW |--- NR 568 +----+ \\----// +----+ 570 private public private 572 FW: Firewall 573 NI: NSIS Initiator 574 NR: NSIS Responder 576 Figure 2: Firewall Traversal Scenario 578 Each Firewall on the data path must provide traversal service for 579 NATFW NSLP in order to permit the NSIS message to reach the other end 580 host. All Firewalls process NSIS signaling and establish appropriate 581 policy rules, so that the required data packet flow can traverse 582 them. 584 Placing firewalls in a network topology can be done in several very 585 different ways. To distinguish firewalls located at network borders, 586 such as administrative domains, from others located internally, the 587 term edge-Firewall is used. A similar distinction can be made for 588 NATs, with an edge-NAT fulfilling the equivalent role. 590 2.2 NAT with two private Networks 592 Figure 3 shows a scenario with NATs at both ends of the network. 593 Therefore, each application instance, NSIS initiator and NSIS 594 responder, are behind NATs. The outermost NAT, called edge-NAT, at 595 each side is connected to the public Internet. The NATs are 596 generically labeled as MB (for middlebox), since those devices 597 certainly implement NAT functionality, but can implement firewall 598 functionality as well. 600 Only two middleboxes MB are shown in Figure 3 at each side, but in 601 general, any number of MBs on each side must be considered. 603 +----+ +----+ //----\\ +----+ +----+ 604 NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR 605 +----+ +----+ \\----// +----+ +----+ 607 private public private 609 MB: Middlebox 610 NI: NSIS Initiator 611 NR: NSIS Responder 613 Figure 3: NAT with two Private Networks Scenario 615 Signaling traffic from NI to NR has to traverse all the middleboxes 616 on the path, and all the middleboxes must be configured properly to 617 allow NSIS signaling to traverse them. The NATFW signaling must 618 configure all middleboxes and consider any address translation that 619 will result from this configuration in further signaling. The sender 620 (NI) has to know the IP address of the receiver (NR) in advance, 621 otherwise it will not be possible to send any NSIS signaling messages 622 towards the responder. Note that this IP address is not the private 623 IP address of the responder. Instead a NAT binding (including a 624 public IP address) has to be previously installed on the NAT that 625 subsequently allows packets reaching the NAT to be forwarded to the 626 receiver within the private address realm. This generally requires 627 further support from an application layer protocol for the purpose of 628 discovering and exchanging information. The receiver might have a 629 number of ways to learn its public IP address and port number and 630 might need to signal this information to the sender using the 631 application level signaling protocol. 633 2.3 NAT with Private Network on Sender Side 635 This scenario shows an application instance at the sending node that 636 is behind one or more NATs (shown as generic MB, see discussion in 637 Section 2.2). The receiver is located in the public Internet. 639 +----+ +----+ //----\\ 640 NI --| MB |-----| MB |---| |--- NR 641 +----+ +----+ \\----// 643 private public 645 MB: Middlebox 646 NI: NSIS Initiator 647 NR: NSIS Responder 649 Figure 4: NAT with Private Network on Sender Side Scenario 651 The traffic from NI to NR has to traverse middleboxes only on the 652 sender's side. The receiver has a public IP address. The NI sends 653 its signaling message directly to the address of the NSIS responder. 654 Middleboxes along the path intercept the signaling messages and 655 configure the policy rules accordingly. 657 Note that the data sender does not necessarily know whether the 658 receiver is behind a NAT or not, hence, it is the receiving side that 659 has to detect whether itself is behind a NAT or not. As described in 660 Section 3.3.2 NSIS can also provide help for this procedure. 662 2.4 NAT with Private Network on Receiver Side Scenario 664 The application instance receiving data is behind one or more NATs 665 shown as MB (see discussion in Section 2.2). 667 //----\\ +----+ +----+ 668 NI ---| |---| MB |-----| MB |--- NR 669 \\----// +----+ +----+ 671 public private 673 MB: Middlebox 674 NI: NSIS Initiator 675 NR: NSIS Responder 677 Figure 5: NAT with Private Network on Receiver Scenario 679 Initially, the NSIS responder must determine its publicly reachable 680 IP address at the external middlebox and notify the NSIS initiator 681 about this address. One possibility is that an application level 682 protocol is used, meaning that the public IP address is signaled via 683 this protocol to the NI. Afterwards the NI can start its signaling 684 towards the NR and so establish the path via the middleboxes in the 685 receiver side private network. 687 This scenario describes the use case for the RESERVE-EXTERNAL-ADDRESS 688 mode of the NATFW NSLP. 690 2.5 Both End Hosts behind twice-NATs 692 This is a special case, where the main problem arises from the need 693 to detect that both end hosts are logically within the same address 694 space, but are also in two partitions of the address realm on either 695 side of a twice-NAT (see [8] for a discussion of twice-NAT 696 functionality). 698 Sender and receiver are both within a single private address realm 699 but the two partitions potentially have overlapping IP address 700 ranges. Figure 6 shows the arrangement of NATs. This is a common 701 configuration in networks, particularly after the merging of 702 companies that have used the same private address space, resulting in 703 overlapping address ranges. 705 public 706 +----+ +----+ //----\\ 707 NI --| MB |--+--| MB |---| | 708 +----+ | +----+ \\----// 709 | 710 | +----+ 711 +--| MB |------------ NR 712 +----+ 714 private 716 MB: Middlebox 717 NI: NSIS Initiator 718 NR: NSIS Responder 720 Figure 6: NAT to Public, Sender and Receiver on either side of a 721 twice-NAT Scenario 723 The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP 724 addresses and port numbers on both sides, meaning the mapping of 725 source and destination address at the private and public interfaces. 727 This scenario requires the assistance of application level entities, 728 such as a DNS server. The application level gateways must handle 729 requests that are based on symbolic names, and configure the 730 middleboxes so that data packets are correctly forwarded from NI to 731 NR. The configuration of those middleboxes may require other 732 middlebox communication protocols, such as MIDCOM [6]. NSIS 733 signaling is not required in the twice-NAT only case, since 734 middleboxes of the twice-NAT type are normally configured by other 735 means. Nevertheless, NSIS signaling might by useful when there are 736 also Firewalls on path. In this case NSIS will not configure any 737 policy rule at twice-NATs, but will configure policy rules at the 738 Firewalls on the path. The NSIS signaling protocol must be at least 739 robust enough to survive this scenario. This requires that twice- 740 NATs must implement the NATFW NSLP also and participate in NATFW 741 sessions but they do not change the configuration of the NAT, i.e., 742 they only read the address mapping information out of the NAT and 743 translate the Message Routing Information (MRI, [1])within the NSLP 744 and NTLP accordingly. For more information see Appendix A.5 746 2.6 Both End Hosts Behind Same NAT 748 When NSIS initiator and NSIS responder are behind the same NAT (thus 749 being in the same address realm, see Figure 7), they are most likely 750 not aware of this fact. As in Section 2.4 the NSIS responder must 751 determine its public IP address in advance and transfer it to the 752 NSIS initiator. Afterwards, the NSIS initiator can start sending the 753 signaling messages to the responder's public IP address. During this 754 process, a public IP address will be allocated for the NSIS initiator 755 at the same middlebox as for the responder. Now, the NSIS signaling 756 and the subsequent data packets will traverse the NAT twice: from 757 initiator to public IP address of responder (first time) and from 758 public IP address of responder to responder (second time). This is 759 the worst case in which both sender and receiver obtain a public IP 760 address at the NAT, and the communication path is certainly not 761 optimal in this case. 763 NI public 764 \ +----+ //----\\ 765 +-| MB |----| | 766 / +----+ \\----// 767 NR 768 private 770 MB: Middlebox 771 NI: NSIS Initiator 772 NR: NSIS Responder 774 Figure 7: NAT to Public, Both Hosts Behind Same NAT 776 The NSIS NATFW signaling protocol should support mechanisms to detect 777 such a scenario. 779 2.7 IPv4/v6 NAT with two Private Networks 781 This scenario combines the use case described in Section 2.2 with the 782 IPv4 to IPv6 transition scenario involving address and protocol 783 translation, i.e., using Network Address and Protocol Translators 784 (NAT-PT, [9]). 786 The difference from the other scenarios is the use of IPv6 to IPv4 787 (and vice versa) address and protocol translation. Additionally, the 788 base NTLP must support transport of messages in mixed IPv4 and IPv6 789 networks where some NSIS peers provide translation. 791 +----+ +----+ //---\\ +----+ //---\\ +----+ +----+ 792 NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR 793 +----+ +----+ \\---// +----+ \\---// +----+ +----+ 795 private public public private 796 IPv4 IPv6 798 MB: Middlebox 799 NI: NSIS Initiator 800 NR: NSIS Responder 802 Figure 8: IPv4/v6 NAT with two Private Networks 804 This scenario needs the same type of application level support as 805 described in Section 2.5, and so the issues relating to twice-NATs 806 apply here as well. 808 2.8 Multihomed Network with NAT 810 The previous sub-sections sketched network topologies where several 811 NATs and/or Firewalls are ordered sequentially on the path. This 812 section describes a multihomed scenario with two NATs placed on 813 alternative paths to the public network. 815 +----+ 816 NI -------| MB |\ 817 \ +----+ \ //---\\ 818 \ -| |-- NR 819 \ \\---// 820 \ +----+ | 821 --| MB |-------+ 822 +----+ 823 private 824 private public 826 MB: Middlebox 827 NI: NSIS Initiator 828 NR: NSIS Responder 830 Figure 9: Multihomed Network with Two NATs 832 Depending on the destination or load balancing requirements, either 833 one or the other middlebox is used for the data flow. Which 834 middlebox is used depends on local policy or routing decisions. 835 NATFW NSLP must be able to handle this situation properly, see 836 Section 3.3.2 for an expanded discussion of this topic with respect 837 to NATs. 839 2.9 Multihomed Network with Firewall 841 This section describes a multihomed scenario with two firewalls 842 placed on alternative paths to the public network (Figure 10). The 843 routing in the private and public network decided which firewall is 844 being taken for data flows. Depending on the data flow's direction, 845 either outbound or inbound, a different firewall could be traversed. 846 This is a challenge for a certain mode of the NATFW NSLP where the 847 NSIS responder is located behind these firewalls within the private 848 network: the UCREATE mode. The UCREATE mode is used to block a 849 particular data flow on an upstream firewall. NSIS must route the 850 UCREATE mode message upstream from NR to NI without probably knowing 851 the data traffic's subsequent path will take from NI to NR. 853 +----+ 854 NR -------| MB |\ 855 \ +----+ \ //---\\ 856 \ -| |-- NI 857 \ \\---// 858 \ +----+ | 859 --| MB |-------+ 860 +----+ 861 private 862 private public 864 MB: Middlebox 865 NI: NSIS Initiator 866 NR: NSIS Responder 868 Figure 10: Multihomed Network with Two Firewalls 870 3. Protocol Description 872 This section defines messages, objects, and protocol semantics for 873 the NATFW NSLP. Section 3.1 introduces the base element of a NSLP 874 session , the policy rule. Section 3.2 introduces the protocol and 875 the protocol behavior is defined in Section 3.3. Section 4 defines 876 the syntax of the messages and objects. 878 3.1 Policy Rules 880 Policy rules, bound to a session, are the building block of middlebox 881 devices considered in the NATFW NSLP. For Firewalls the policy rule 882 usually consists of a 5-tuple, source/destination addresses, 883 transport protocol, and source/destination port numbers, plus an 884 action, such as allow or deny. For NATs the policy rule consists of 885 action 'translate this address' and further mapping information, that 886 might be, in the simplest case, internal IP address and external IP 887 address. 889 Policy rules are usually carried in one piece in signaling 890 applications. In NSIS the policy rule is divided into the flow 891 identifier, an allow or deny action, and additional information. The 892 filter specification is carried within NTLP's message routing 893 information (MRI) and additional information, including the 894 specification of the action, is carried in NSLP's objects. 895 Additional information is, for example, the lifetime of a policy rule 896 or session. 898 3.2 Basic protocol overview 900 The NSIS NATFW NSLP is carried over the NSIS Transport Layer Protocol 901 (NTLP) defined in [1]. The interworking with the NTLP and other 902 components is shown in Figure 60. NATFW NSLP messages are initiated 903 by the NSIS initiator (NI), handled by NSIS forwarders (NF) and 904 finally processed by the NSIS responder (NR). It is required that at 905 least NI and NR implement this NSLP, intermediate NFs only implement 906 this NSLP when they provide relevant middlebox functions. NSIS 907 forwarders that do not have any NATFW NSLP functions just forward 908 these packets when they have no interest. 910 A Data Sender (DS), intending to send data to a Data Receiver (DR) 911 must first initiate NATFW NSLP signaling. This causes the NI 912 associated with the data sender (DS) to launch NSLP signaling towards 913 the address of data receiver DR (see Figure 11). Although it is 914 expected that the DS and the NATFW NSLP NI will usually reside on the 915 same host, this specification does not rule out scenarios where the 916 DS and NI reside on different hosts, the so-called proxy mode (see 917 Section 1.) 918 +-------+ +-------+ +-------+ +-------+ 919 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 920 | |--->| NF1 |--->| NF2 |--->| | 921 +-------+ +-------+ +-------+ +-------+ 923 ========================================> 924 Data Traffic Direction 926 ---> : NATFW NSLP request signaling 927 ~~~> : NATFW NSLP response signaling 928 DS/NI : Data sender and NSIS initiator 929 DR/NR : Data receiver and NSIS responder 930 MB1 : Middlebox 1 and NSIS forwarder 1 931 MB2 : Middlebox 2 and NSIS forwarder 2 933 Figure 11: General NSIS signaling 935 +-------+ +-------+ +-------+ +-------+ 936 | DS/NI |<~~~| MB1/ |<~~~| NR | | DR | 937 | |--->| NF1 |--->| | | | 938 +-------+ +-------+ +-------+ +-------+ 940 ========================================> 941 Data Traffic Direction 943 ---> : NATFW NSLP request signaling 944 ~~~> : NATFW NSLP response signaling 945 DS/NI : Data sender and NSIS initiator 946 DR/NR : Data receiver and NSIS responder 947 MB1 : Middlebox 1 and NSIS forwarder 1 948 MB2 : Middlebox 2 and NSIS forwarder 2 950 Figure 12: A NSIS proxy mode signaling 952 The sequence of NSLP events is as follows: 954 o NSIS initiators generate NATFW NSLP request messages and send 955 those towards the NSIS responder. Note, that the NSIS initiator 956 may not necessarily be the data sender but may be the data 957 receiver, for instance, when using the RESERVE-EXTERNAL-ADDRESS 958 message. 960 o NSLP request messages are processed each time a NF with NATFW NSLP 961 support is traversed. These nodes process the message, check 962 local policies for authorization and authentication, possibly 963 create policy rules, and forward the signaling message to the next 964 NSIS node. The request message is forwarded until it reaches the 965 NSIS responder. 967 o NSIS responders will check received messages and process them if 968 applicable. NSIS responders generate response messages and send 969 them hop-by-hop back to the NI via the same chain of NFs 970 (traversal of the same NF chain is guaranteed through the 971 established reverse message routing state in the NTLP). Note, 972 that NSIS responder may not necessarily be the data receiver but 973 may be any intermediate NSIS node that terminates the forwarding, 974 for example, in a proxy mode case where an edge-NAT is replying to 975 requests 977 o The response message is processed at each NF implementing the 978 NATFW NSLP. 980 o Once the NI has received a successful response, the data sender 981 can start sending its data flow to the data receiver. 983 Because NATFW NSLP signaling follows the data path from DS to DR, 984 this immediately enables communication between both hosts for 985 scenarios with only Firewalls on the data path or NATs on sender 986 side. For scenarios with NATs on the receiver side certain problems 987 arise, as described in Section 2. 989 When the NR and the NI are located in different address realms and 990 the NR is located behind a NAT, the NI cannot signal to the NR 991 directly. The DR and NR are not reachable from the NIs using the 992 private address of the NR and thus NATFW signaling messages cannot be 993 sent to the NR/DR's address. Therefore, the NR must first obtain a 994 NAT binding that provides an address that is reachable for the NI. 995 Once the NR has acquired a public IP address, it forwards this 996 information to the DS via a separate protocol (such as SDP within 997 SIP). This application layer signaling, which is out of scope of the 998 NATFW NSLP, may involve third parties that assist in exchanging these 999 messages. 1001 NATFW NSLP signaling supports this scenario by using the RESERVE- 1002 EXTERNAL-ADDRESS mode of operation 1004 1. The NR acquires a public address by signaling on the reverse path 1005 (NR towards NI) and thus making itself available to other hosts. 1007 This process of acquiring a public addresses is called 1008 reservation. During this process the DR reserves publicly 1009 reachable addresses and ports suitable for NATFW NSLP signaling, 1010 but data traffic will not be allowed to use this address/port 1011 initially. 1013 2. The NI signals directly to the NR as the NI would do if there is 1014 no NAT in between, and creates policy rules at middleboxes. 1015 Note, that the reservation mode will only allow the forwarding 1016 of signaling messages but not data flow packets. Data flow 1017 packets will be 'activated' by the signaling from NI towards NR. 1018 The RESERVE-EXTERNAL-ADDRESS mode of operation is detailed in 1019 Section 3.3.2 1021 The above usage assumes that both ends of a communication support 1022 NSIS but fail when NSIS is only deployed at one end of the network. 1023 In this case only the receiving or sending side are NSIS aware and 1024 not both at the same time (see also Section 1). NATFW NSLP supports 1025 this scenario by using a proxy mode, as described in Section 3.3.7 1026 and Section 3.3.8. 1028 The basic functionality of the NATFW NSLP provides for opening 1029 firewall pin holes and creating NAT bindings to enable data flows to 1030 traverse these devices. Firewalls are expected to work on a deny-all 1031 policy, meaning that traffic that does not explicitly match any 1032 firewall filter rule will be blocked. In contrast, the normal 1033 behavior of NATs is to block all traffic that does not match any 1034 already configured/installed binding or session. However, in some 1035 scenarios it is required to support firewalls having allow-all 1036 policies, allowing data traffic to traverse unless it is blocked 1037 explicitly. Data receivers can utilize NATFW NSLP's UCREATE message 1038 to install policy rules at upstream firewalls to block unwanted 1039 traffic. 1041 The protocol works on a soft-state basis, meaning that whatever state 1042 is installed or reserved on a middlebox will expire, and thus be de- 1043 installed/ forgotten after a certain period of time. To prevent 1044 this, the NATFW nodes involved will have to specifically request a 1045 session extension. An explicit NATFW NSLP state deletion capability 1046 is also provided by the protocol. 1048 Middleboxes should return an error in case of a failure, such that 1049 appropriate actions can be taken; this ability would allow debugging 1050 and error recovery. Error messages could be sent upstream (for 1051 errors related to received messages as well as asynchronous error 1052 notification messages) towards the NI as well as downstream towards 1053 the NR (in the case of asynchronous error notification messages). 1055 The next sections define the NATFW NSLP message types and formats, 1056 protocol operations, and policy rule operations. 1058 3.3 Protocol Operations 1060 This section defines the protocol operations including, how to create 1061 sessions, maintain them, and how to reserve addresses. All the NATFW 1062 NSLP protocol messages require C-mode handling by the NTLP and cannot 1063 be piggybacked into D-mode NTLP messages used during the NTLP path 1064 discovery/refresh phase. The usage of the NTLP by protocol messages 1065 is described in detail in Section 4. 1067 The protocol uses six messages: 1069 o CREATE: a request message used for creating, changing, refreshing 1070 and deleting NATFW NSLP sessions. 1072 o RESERVE-EXTERNAL-ADDRESS (REA): a request message used for 1073 reserving an external address and probably port number, depending 1074 on the type of NAT. 1076 o Query and Diagnosis ReQuest (QDRQ): a request message used by 1077 authorized NATFW NEs for querying and diagnosing installed NATFW 1078 states 1080 o NOTIFY: an asynchronous message used by NATFW NEs to alert 1081 upstream and/or downstream NATFW NEs about specific events 1082 (especially failures). 1084 o UCREATE: a request message used by data receivers to instruct 1085 upstream firewalls to block data traffic. 1087 o RESPONSE: used as a response to CREATE, REA, UCREATE and QDRQ 1088 messages with Success or Error information 1090 3.3.1 Creating Sessions 1092 Allowing two hosts to exchange data even in the presence of 1093 middleboxes is realized in the NATFW NSLP by the CREATE request 1094 message. The data sender generates a CREATE message as defined in 1095 Section 4.4.1 and hands it to the NTLP. The NTLP forwards the whole 1096 message on the basis of the message routing information towards the 1097 NR. Each NSIS forwarder along the path that implements NATFW NSLP, 1098 processes the NSLP message. Forwarding is thus managed NSLP hop-by- 1099 hop but may pass transparently through NSIS forwarders which do not 1100 contain NATFW NSLP functionality and non-NSIS aware routers between 1101 NSLP hop way points. When the message reaches the NR, the NR can 1102 accept the request or reject it. The NR generates a response to the 1103 request and this response is transported hop-by-hop towards the NI. 1104 NATFW NSLP forwarders may reject requests at any time. Figure 13 1105 sketches the message flow between NI (DS), a NF (NAT), and NR (DR). 1107 NI Private Network NF Public Internet NR 1108 | | | 1109 | CREATE | | 1110 |----------------------------->| | 1111 | | | 1112 | RESPONSE[Error](if necessary)| | 1113 |<-----------------------------| CREATE | 1114 | |--------------------------->| 1115 | | | 1116 | | RESPONSE[Success/Error] | 1117 | RESPONSE[Success/Error] |<---------------------------| 1118 |<-----------------------------| | 1119 | | | 1120 | | | 1122 Figure 13: Creation message flow 1124 Since the CREATE message is used for several purposes within the 1125 lifetime of a session, there are several processing rules for NATFW 1126 NEs when generating and receiving CREATE messages. The different 1127 processing methods depend not only on the function which the CREATE 1128 is performing (to create, modify, refresh or delete a session) but 1129 also on the node at which the processing happens. For an initial 1130 CREATE message, the CREATE message creating a new NSIS session, the 1131 processing of CREATE messages is different for every NSIS node type: 1133 o NSLP initiator: NI only generates initial CREATE messages and 1134 hands them over to the NTLP. After receiving a successful 1135 response, the data path is configured and the DS can start 1136 sending its data to the DR. After receiving an 'error' response 1137 message the NI MAY try to generate the CREATE message again or 1138 give up and report the failure to the application, depending on 1139 the error condition. 1141 o NATFW NSLP forwarder: NFs receiving an initial CREATE message 1142 MUST first perform the checks defined in Section 3.8 and 1143 Section 3.9, if applicable, before any further processing is 1144 executed. The NF SHOULD check with its local policies if it can 1145 accept the desired policy rule given the combination of the NTLP's 1146 'Message-Routing-Information' (MRI) [1] (the flow description 1147 information) and the CREATE payload (behavior to be enforced on 1148 the packet stream). An initial CREATE is distinguished from 1149 subsequent CREATE messages by the absence of existing NSLP session 1150 state related to the same session ID or the same MRI. The NSLP 1151 message processing depends on the middlebox type: 1153 * NAT: When the initial CREATE message is received at the public 1154 side of the NAT, it looks for a reservation made in advance, by 1155 using a REA message Section 3.3.2, that matches the destination 1156 address/port of the MRI provided by the NTLP. If no 1157 reservation had been made in advance the NSLP MAY return an 1158 error response message of type 'no reservation found' and 1159 discard the request. If there is a reservation, NSLP stores 1160 the data sender's address as part of the policy rule to be 1161 loaded and forwards the message with the address set to the 1162 internal (private in most cases) address of the next NSIS node. 1163 When the initial CREATE message, for a new session, is received 1164 at the private side the NAT binding is reserved, but not 1165 activated. The NSLP message is forwarded to the next NSIS hop 1166 with source address set to the NAT's external address from the 1167 newly reserved binding. 1169 * Firewall: When the initial CREATE message is received the NSLP 1170 just remembers the requested policy rule, but does not install 1171 any policy rule. Afterwards, the message is forwarded to the 1172 next NSLP hop. There is a difference between requests from 1173 trusted (authorized NIs) and un-trusted (un-authorized NIs); 1174 requests from trusted NIs will be pre-authorized, whereas 1175 requests from un-trusted NIs will not be pre-authorized. This 1176 difference is required to speed-up the protocol operations as 1177 well as for proxy mode usage (please refer to Section 3.3.7 and 1178 [14]). 1180 * Combined NAT and Firewall: Processing at combined Firewall and 1181 NAT middleboxes is the same as in the NAT case. No policy 1182 rules are installed. Implementations MUST take into account 1183 the order of packet processing in the Firewall and NAT 1184 functions within the device. This will be referred to as 1185 'order of functions' and is generally different depending on 1186 whether the packet arrives at the external or internal side of 1187 the middlebox. 1189 o NSLP receiver: NRs receiving initial CREATE messages MUST reply 1190 with a 'success' (response object has success information) 1191 RESPONSE message if they accept the CREATE request message and the 1192 defined in Section 3.8 and Section 3.9, if applicable, have been 1193 successful executed. Otherwise they SHOULD generate a RESPONSE 1194 message with an error code. RESPONSE messages are sent back NSLP 1195 hop-by-hop towards the NI, independently of the response codes, 1196 either success or error. 1198 Policy rules at middleboxes MUST be only installed upon receiving a 1199 successful response. This is a countermeasure to several problems, 1200 for example wastage of resources due to loading policy rules at 1201 intermediate NF when the CREATE message does not reach the final NR 1202 for some reason. 1204 3.3.2 Reserving External Addresses 1206 NSIS signaling is intended to travel end-to-end, even in the presence 1207 of NATs and Firewalls on-path. This works well in cases where the 1208 data sender is itself behind a NAT as described in Section 3.3.1. 1209 For scenarios where the data receiver is located behind a NAT and 1210 needs to receive data flows from outside its own network (see 1211 Figure 5) the problem is more troublesome. NSIS signaling, as well 1212 as subsequent data flows, are directed to a particular destination IP 1213 address that must be known in advance and reachable. 1215 +-------------+ AS-Data Receiver Communication 1216 +-------->| Application |<-----------------------------+ 1217 | | Server | | 1218 | +-------------+ | 1219 | IP(R-NAT_B) | 1220 | NSIS Signaling Message +-------+--+ 1221 | +------------------------------------------>| NAT/NAPT | 1222 | | | B | 1223 | | +-------+--+ 1224 | | | 1225 AS-Data| | | 1226 Receiver| | +----------+ | 1227 Comm.| | | NAT/NAPT | | 1228 | | | A | | 1229 | | +----------+ | 1230 | | | 1231 | | | 1232 | | | 1233 | | | 1234 v | IP(R) v 1235 +--------+ +---------+ 1236 | Data | | Data | 1237 | Sender | | Receiver| 1238 +--------+ +---------+ 1239 Figure 14: The Data Receiver behind NAT problem 1241 Figure 14 describes a typical message communication in a peer-to-peer 1242 networking environment whereby the two end points learn of each 1243 others existence with the help of a third party (referred to as an 1244 Application Server). Communication between the application server 1245 and each of the two end points (data sender and data receiver) 1246 enables the two end hosts to learn each other's IP addresses. The 1247 approach described in this memo supports this peer-to-peer approach, 1248 but is not limited to it. 1250 Some sort of communication between the data sender/data receiver and 1251 a third party is typically necessary (independently of whether NSIS 1252 is used). NSIS signaling messages cannot be used to communicate the 1253 relevant application level end point identifiers (in the generic case 1254 at least) as a replacement for communication with the application 1255 server. 1257 If the data receiver is behind a NAT then an NSIS signaling message 1258 will be addressed to the IP address allocated at the NAT (assuming 1259 one had already been allocated). If no corresponding NSIS NAT 1260 Forwarding State at NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) 1261 then the signaling message will terminate at the NAT device (most 1262 likely without generating a proper response message). The signaling 1263 message transmitted by the data sender cannot install the NAT binding 1264 or NSIS NAT Forwarding State "on-the-fly" since this would assume 1265 that the data sender knows the topology at the data receiver side 1266 (i.e., the number and the arrangement of the NAT and the private IP 1267 address(es) of the data receiver). The primary goal of path-coupled 1268 middlebox communication was not to avoid end hosts learning and 1269 preserving this type of topology knowledge. Data receivers behind a 1270 NAT must first reserve an external IP address (probably port number 1271 too). 1273 Public Internet Private Address 1274 Space 1275 Edge 1276 NI(DS) NAT NAT NR(DR) 1277 NR+ NI+ 1278 | | | | 1279 | | | | 1280 | | | | 1281 | | REA | REA | 1282 | |<----------------------|<----------------------| 1283 | | | | 1284 | |RESPONSE[Success/Error]|RESPONSE[Success/Error]| 1285 | |---------------------->|---------------------->| 1286 | | | | 1287 | | | | 1289 ============================================================> 1290 Data Traffic Direction 1292 Figure 15: Reservation message flow 1294 Figure 15 shows the message flow for reserving an external address/ 1295 port at a NAT. In this case the roles of the different NSIS entities 1296 are: 1298 o The data receiver (DR) for the anticipated data traffic is the 1299 NSIS initiator (NI+) for the RESERVE-EXTERNAL-ADDRESS (REA) 1300 message, but becomes the NSIS responder (NR) for following CREATE 1301 messages. 1303 o The actual data sender (DS) will be the NSIS initiator (NI) for 1304 later CREATE messages and may be the NSIS target of the signaling 1305 (NR+). 1307 o The actual target of the REA message, the Opportunistic Address 1308 (OA) is an arbitrary address, that would force the message to get 1309 intercepted by the far outmost NAT in the network. The 1310 Opportunistic Address is shown as NR+. 1312 The NI+ (could be on the data receiver DR or on any other host within 1313 the private network) sends a the REA message targeted to the 1314 Opportunistic Address (OA defined earlier). The OA selection for 1315 this message is discussed in Section 3.7. The message routing for 1316 the REA message is in the reverse direction to the normal message 1317 routing used for path-coupled signaling where the signaling is sent 1318 downstream (as opposed to upstream in this case). When establishing 1319 NAT bindings (and NSIS session state) the direction does not matter 1320 since the data path is modified through route pinning due to the 1321 external NAT address. Subsequent NSIS messages (and also data 1322 traffic) will travel through the same NAT boxes. 1324 NI+ may include a data sender's address information object (DSInfo) 1325 if they are aware about the data sender. The DSInfo object is used 1326 by the edge-NAT to limit the possible NI addresses to one address. A 1327 NI+ can specify a specific IP address and port from where the 1328 subsequent NSIS signaling must be originated. 1330 The REA signaling message creates NSIS NAT session state at any 1331 intermediate NSIS NAT peer(s) encountered. Furthermore it has to be 1332 ensured that the edge-NAT device is discovered as part of this 1333 process. The end host cannot be assumed to know this device - 1334 instead the NAT box itself is assumed to know that it is located at 1335 the outer perimeter of the private network addressing realm. 1336 Forwarding of the REA message beyond this entity is not necessary, 1337 and should be prohibited as it provides information on the 1338 capabilities of internal hosts. 1340 The edge-NAT device responds to the REA message with a RESPONSE 1341 message containing a success object carrying the public reachable IP 1342 address/port number. 1344 Processing of REA messages is specific to the NSIS node type: 1346 o NSLP initiator: NI+ only generate REA messages and should never 1347 receive them. When the data sender's address information is known 1348 in advance the NI+ MAY include a DSInfo object in the REA message. 1349 When the data sender's IP address is not known, NI+s MUST NOT 1350 include a DSInfo object. 1352 o NSLP forwarder: NSLP forwarders receiving REA messages MUST first 1353 perform the checks defined in Section 3.8 and Section 3.9, if 1354 applicable, before any further processing is executed. The NF 1355 SHOULD check with its local policies if it can accept the desired 1356 policy rule given by NTLP's message routing information (MRI). 1357 Further processing depends on the middlebox type: 1359 * NAT: NATs check whether the message is received at the 1360 external (public in most cases) address or at the internal 1361 (private) address. If received at the external address a NF 1362 MAY generate a RESPONSE message with an error of type 'REA 1363 received from outside'. If received at the internal address, 1364 an IP address/port is reserved. In the case it is an edge-NAT, 1365 the NSLP message is not forwarded any further and a RESPONSE 1366 message with the external address and port information is 1367 generated. If it is not an edge-NAT, the NSLP message is 1368 forwarded further with the translated IP address/port. The 1369 edge-NAT MAY reject REA messages not carrying a DSInfo object 1370 or if the address information within this object is invalid or 1371 too much wildcarded. 1373 * Firewall: Firewalls MUST not change their configuration upon a 1374 REA message. They simply MUST forward the message and MUST 1375 keep NTLP state. Firewalls that are configured as edge- 1376 Firewalls MAY return an error of type 'no NAT here'. 1378 * Combined NAT and Firewall: Processing at combined Firewall and 1379 NAT middleboxes is the same as in the NAT case. 1381 o NSLP receiver: This type of message should never be received by 1382 any NR+ and it SHOULD be discarded silently. 1384 Processing of a RESPONSE message with an external address object is 1385 different for every NSIS node type: 1387 o NSLP initiator: Upon receiving a RESPONSE message with an 1388 external address object, the NI+ can use the IP address and port 1389 pairs carried for further application signaling. 1391 o NSLP forwarder: NFs simply forward this message as long as they 1392 keep state for the requested reservation. 1394 o NSIS responder: This type of message should never be received by 1395 an NR and it SHOULD be discarded silently. 1397 o Edge-NATs: This type of message should never be received by any 1398 Edge-NAT and it SHOULD be discarded silently. 1400 Reservations made with REA MUST be enabled by a subsequent CREATE 1401 message. A reservation made with REA is kept alive as long as the 1402 NI+ refreshes the particular signaling session and it can be reused 1403 for multiple, different CREATE messages. An NI+ may decide to 1404 teardown a reservation immediately after receiving a CREATE message. 1405 Without using CREATE (Section 3.3.1 or REA in proxy mode 1406 Section 3.3.7 no data traffic will be forwarded to DR beyond the 1407 edge-NAT. REA is just taking care about enabling the forwarding of 1408 subsequent CREATE messages traveling towards the NR. Correlation of 1409 incoming CREATE messages to REA reservation states is described in 1410 Section 3.6 1412 3.3.3 NATFW Session refresh 1414 NATFW NSLP sessions are maintained on a soft-state basis. After a 1415 specified timeout, sessions and corresponding policy rules are 1416 removed automatically by the middlebox, if they are not refreshed. 1417 Soft-state is created by CREATE, REA, and UCREATE and the maintenance 1418 of this state must be done by these messages. State created by 1419 CREATE must be maintained by CREATE, state created by REA must be 1420 maintained by REA, and state created by UCREATE must be maintained by 1421 UCREATE. Refresh messages, either CREATE/REA/UCREATE, are messages 1422 carrying the exact MRI and session ID as the initial message and a 1423 lifetime object with a lifetime greater than zero. Every refresh 1424 request message MUST be acknowledged by an appropriate response 1425 message generated by the NR. This response message is routed back 1426 towards the NI, to allow the intermediate NFs to propose a refresh 1427 period that would align with their local policies. The NI sends 1428 refresh messages destined for the NR. Upon reception by each NSIS 1429 forwarder, the state for the given session ID is extended by the 1430 session refresh period, a period of time calculated based on a 1431 proposed refresh message period. The lifetime extension of a session 1432 is calculated as current local time plus proposed lifetime value 1433 (session refresh period). Section 3.4 defines the process of 1434 calculating lifetimes in detail. 1436 NI Public Internet NAT Private address NR 1437 | | space | 1438 | CREATE[lifetime > 0] | | 1439 |----------------------------->| | 1440 | | | 1441 | RESPONSE[Error] (if needed) | | 1442 |<-----------------------------| CREATE[lifetime > 0] | 1443 | |--------------------------->| 1444 | | | 1445 | | RESPONSE[Success/Error] | 1446 | RESPONSE[Success/Error] |<---------------------------| 1447 |<-----------------------------| | 1448 | | | 1449 | | | 1451 Figure 16: State Refresh Message Flow, CREATE as example 1453 Processing of session refresh CREATE/REA/UCREATE messages is 1454 different for every NSIS node type: 1456 o NSLP initiator: The NI can generate session refresh CREATE/REA/ 1457 UCREATE messages before the session times out. The rate at which 1458 the refresh CREATE/REA/UCREATE messages are sent and their 1459 relation to the session state lifetime are further discussed in 1460 Section 3.4. The message routing information and the extended 1461 flow information object MUST be set equal to the values of the 1462 initial request message. 1464 o NSLP forwarder: NSLP forwarders receiving session refresh messages 1465 MUST first perform the checks defined in Section 3.8 and 1466 Section 3.9, if applicable, before any further processing is 1467 executed. The NF SHOULD check with its local policies if it can 1468 accept the desired lifetime extension for the session referred by 1469 the session ID. Processing of this message is independent of the 1470 middlebox type. 1472 o NSLP responder: NRs accepting a session refresh CREATE/REA/UCREATE 1473 message generate a RESPONSE message with response object set to 1474 success. NRs MUST perform the checks defined in Section 3.8 and 1475 Section 3.9, if applicable. 1477 3.3.4 Deleting Sessions 1479 NATFW NSLP sessions may be deleted at any time. NSLP initiators can 1480 trigger this deletion by using a CREATE, REA, or UCREATE messages 1481 with a lifetime value set to 0, as shown in Figure 17. 1483 NI Public Internet NAT Private address NR 1484 | | space | 1485 | CREATE[lifetime=0] | | 1486 |----------------------------->| | 1487 | | | 1488 | | CREATE[lifetime=0] | 1489 | |--------------------------->| 1490 | | | 1492 Figure 17: Delete message flow, CREATE as example 1494 NSLP nodes receiving this message MUST first perform the checks 1495 defined in Section 3.8 and Section 3.9, if applicable, and afterwards 1496 MUST delete the session immediately. Policy rules associated with 1497 this particular session MUST be deleted immediately. This message is 1498 forwarded until it reaches the final NR. The CREATE/REA/UCREATE 1499 request message with a lifetime value of 0, does not generate any 1500 response, neither positive nor negative, since there is no NSIS state 1501 left at the nodes along the path. 1503 3.3.5 Reporting Asynchronous Events 1505 NATFW NSLP forwarders and NATFW NSLP responders must have the ability 1506 to report asynchronous events to other NATFW NSLP nodes, especially 1507 to allow reporting back to the NATFW NSLP initiator. Such 1508 asynchronous events may be premature session termination, changes in 1509 local policies, route change or any other reason that indicates 1510 change of the NATFW NSLP session state. Currently, asynchronous 1511 session termination, re-authorization required and route change 1512 detected (see Section 3.10) are the only events that are defined, but 1513 other events may be defined in later versions of this memo. One or 1514 several events could be reported within the NOTIFY message. 1516 NFs and NRs may generate NOTIFY messages upon asynchronous events, 1517 with a response object indicating the reason of the event and a 1518 corresponding session ID. NOTIFY messages are sent hop-by-hop 1519 upstream towards NI until they reach NI. 1521 The initial processing when receiving a NOTIFY message is the same 1522 for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages 1523 through already established NTLP messaging associations. The further 1524 processing is different for each NATFW NSLP node type and depends on 1525 the events notified: 1527 o NSLP initiator: NIs receiving NOTIFY messages MUST first perform 1528 the checks defined in Section 3.8 and Section 3.9, if applicable. 1529 After successfully doing so, NIs analyze the notified event(s) and 1530 behave appropriately based on the event type. Section 4.3.5 1531 discusses the required behavior for each notified event. NIs MUST 1532 NOT generate NOTIFY messages. 1534 o NSLP forwarder: NFs receiving NOTIFY messages MUST first perform 1535 the checks defined in Section 3.8 and Section 3.9, if applicable, 1536 and MUST only accept NOTIFY messages from downstream peers. After 1537 successfully doing so, NFs analyze the notified event(s) and 1538 behave based on the notified events defined in Section 4.3.5. NFs 1539 occurring an asynchronous event generate NOTIFY messages and set 1540 the response object(s) code based on the reported event(s). 1541 NOTIFY messages are sent further hop-by-hop upstream towards the 1542 NI. NFs SHOULD generate NOTIFY messages upon asynchronous events 1543 and forward them upstream towards the NI. 1545 o NSLP responder: NRs SHOULD generate NOTIFY messages upon 1546 asynchronous events. NRs receiving NOTIFY messages MUST ignore 1547 this message and discard it. NOTIFY messages are sent hop-by-hop 1548 upstream towards NI 1550 3.3.6 Query and diagnosis capabilities within the NATFW NSLP protocol 1552 The NATFW NSLP provides query and diagnosis capabilities that could 1553 be used by a session(s) owner to monitor the state of those sessions. 1554 This would be used for: 1556 o Diagnostic purposes when no data packets were received (or the 1557 packet stream is subject to significant packet loss) and NATFW 1558 NSLP signaling was supposed to have created appropriate policy 1559 rules on the NATFW NFs along the data path. 1561 o Discover the number of NATFW NSLP Hops between the NI and the NR 1562 (or the last NATFW NE responding to the QDRQ) 1564 o Collecting session states owned by a specific NI, this is required 1565 in case the NI loses its sessions' information (mainly due to node 1566 system issues). 1568 The QDRQ message can be used to query and diagnose the following 1569 session information: session id, the number of NE hops (between the 1570 NI and the last NE responding to the QDRQ) and the following 1571 session's status ordered from best to worst: up, high traffic (used 1572 to detect DOS attack or unexpected traffic rate), pending, down. The 1573 status of the policy rule will probably provide sufficient diagnostic 1574 information in most cases;if more diagnostic information is required 1575 it could be provided by the NATFW NF logs. QDRQ messages may include 1576 an optional maximum hop count number value provided by the NI, when 1577 the hop count value reaches the maximum hop count the receiving NF 1578 should stop propagating the QDRQ and generate a response message to 1579 be sent back upstream to the NI. A QDRQ message usage is shown in 1580 Figure 18 where downstream NF increments the hop counter (except when 1581 they are the responding NF) and when the session's state is not "UP" 1582 (or "UP" but a QDRQ of type LIST is sent) they insert a session 1583 status value and their IP address. The Session information could be 1584 retrieved by sending a QDRQ against a specific session id or a QDRQ 1585 type equal to LIST (this is only applicable when the NI's identity is 1586 available and identical to the one used during the session's 1587 establishment process). In the message sequences shown in Figure 18, 1588 the QDRQ message (which a QDRQ type value of SINGLE) is sent for a 1589 single session ID (provided through the NTLP API), the traversed NAT 1590 didn't have any issues to report for the session however the 1591 Firewall's (FW) traffic meters reported that the flow has exceeded 1592 the maximum number of packets provisioned against the flow, hence in 1593 addition to the session status the firewall provides its address. As 1594 the firewall is the last hop (it is configured to proxy and respond 1595 to QDRQ messages) it does not increment the hop counter and responds 1596 hop by hop back to the NI. 1598 NI Private address NAT FW 1599 | | | 1600 |QDRQ(SINGLE,HOPCNT=0)| | 1601 |-------------------->| | 1602 | |QDRQ(SINGLE,HOPCNT=1) | 1603 | |---------------------> | 1604 | | | 1605 | |RESPONSE(SINGLE, | 1606 | |HOPCNT=1, | 1607 | | [HIGH_PPS,FW@] | 1608 | |<--------------------- | 1609 |RESPONSE(SINGLE, | | 1610 |HOPCNT=1,[HIGH_PPS, | | 1611 | FW@]) | | 1612 |<--------------------| | 1614 Figure 18: Query and Diagnosis operation 1616 QDRQ message processing is dependent on the NATFW NSLP node type: 1618 o NSLP initiator: NIs only generate QDRQ messages, while inserting: 1620 * a HOPCNT object with a zero value 1622 * a QDRQ type to indicate if the QDRQ is for a single session 1623 (QDRQ type would be SINGLE) or to gather information on all the 1624 sessions initiated by the NI (QDRQ type would be LIST) 1626 * When required (i.e. this is optional) a maximum hop count value 1628 * A SID (embedded in the Bound SIP object) when the QDRQ is not 1629 related to the session handled within the Message Routing State 1630 used to route the QDRQ. 1632 An NI MUST discard received QDRQ messages. 1634 o NSLP forwarder: NFs receiving QDRQ messages MUST first 1635 authenticate and authorize the message source. After successfully 1636 doing so, NFs will behave differently depending if the QDRQ is 1637 specific to one session and whether the NF co-hosts a NAT engine 1638 or not. 1640 * If the QDRQ is about a single session: 1642 1. the NF checks first if the QDRQ includes a maximum hop 1643 count, if the current hop counter is smaller (else the 1644 procedures continues as defined in 2) and the NF was 1645 previously able to forward NSLP messages downstream for the 1646 same session (else the procedure continues as defined in 1647 2), the NF increments the hop counter. Furthermore if the 1648 NF's session status is not "UP", the NF will insert a 1649 session status object, which includes the session's status 1650 and the node's IP address, as defined in Section 4.3.13. 1651 In case the NF was co-hosting a NAT engine, the NF needs to 1652 ensure the validity of the session status object's embedded 1653 IP address and modify the address based on the local NAT 1654 bind entry. After completing these operations the NF 1655 forwards the message downstream. 1657 2. In addition to the conditions discussed above, this 1658 procedure is applied when the QDRQ message is scoped by the 1659 receiving NF. The NF responds, with a RESPONSE message, 1660 hop by hop back to the NI while copying the hop counter, 1661 the bound session ID if it was present and a series of 1662 session status objects. 1664 * If the QDRQ is of type LIST then the following procedures are 1665 applied: 1667 1. the NF checks first if the QDRQ includes a maximum hop 1668 counter, if the current hop counter is smaller (else the 1669 procedures continues as defined in 2), the NF creates one 1670 or several QDRQ response objects which include a bound 1671 session ID (session ID created by the NI before it lost all 1672 its session states), a flow descriptor and the session 1673 status object (session state and NF's IP address). This is 1674 only performed if the NF is able to get the NI's proof of 1675 ownership on stored sessions within the node. In case the 1676 NF was co-hosting a NAT engine, the NF needs to ensure the 1677 validity of all embedded IP addresses includes in QDRQ 1678 objects and modify the addresses based on the local NAT 1679 bind entry. After completing these operations the NF 1680 increments the hop counter and forwards the message 1681 downstream, if there were no downstream nodes then the hop 1682 counter is decremented and the procedure continues as 1683 described below in step 2. 1685 2. In addition to the conditions discussed above, this 1686 procedure is applied when the QDRQ message is scoped by the 1687 receiving NF. The NF responds, with a RESPONSE message, 1688 hop by hop back to the NI while copying the hop counter and 1689 the series of QDRQ response objects which would include in 1690 addition to the session status objects, bound session ID as 1691 discussed in Section 4.3.15. 1693 o NSLP responder: NRs (any node being the destination of the 1694 message) receiving QDRQ messages MUST first perform the checks 1695 defined in Section 3.8 and Section 3.9, if applicable. After 1696 successfully doing so, NRs must process the message as the NFs 1697 when responding with a RESPONSE message to the NI. The RESPONSE 1698 message would include a copy of all the received objects within 1699 the QDRQ message. The RESPONSE message will travel along the 1700 established reverse path given by the message routing state. 1702 Responses to QDRQ messages are processed differently depending on 1703 theNATFW NSLP node type: 1705 o NSLP initiator: NIs receiving RESPONSEs to QDRQ messages MUST 1706 first perform the checks defined in Section 3.8 and Section 3.9, 1707 if applicable. After successfully doing so, the objects within 1708 the RESPONSE messages are provided up to the application layers 1709 and the session state remains as it was unless the application 1710 triggers NATFW NSLP state changes. 1712 o NSLP forwarder: NFs receiving RESPONSEs to QDRQ messages MUST 1713 first perform the checks defined in Section 3.8 and Section 3.9, 1714 if applicable. After successfully doing so, NFs forward the 1715 message upstream without any interpretation. 1717 o NSLP responder: if an NR receives a RESPONSE to QDRQ message it 1718 MUST discard it. 1720 QDRQ messages are mainly sent for debugging and outage recovery and 1721 hence should be sent within a trusted network infrastructure, this 1722 could either be achieved by implicitly scoping QDRQ messages at the 1723 edge of the trusted network infrastructure or using the maximum hop 1724 count counter. 1726 3.3.7 Proxy Mode for Data Receiver behind NAT 1728 Some migration scenarios need specialized support to cope with cases 1729 where only the receiving side is running NSIS. End-to-end signaling 1730 is going to fail without NSIS support at both data sender and data 1731 receiver, unless the NATFW NSLP also gives the NR the ability to 1732 install state on the upstream path towards the data sender for 1733 downstream data packets. The goal of the described method is to 1734 trigger the network to generate a CREATE message at the edge-NAT on 1735 behalf of the data receiver. In this case, a NR can signal towards 1736 the Opportunistic Address as is performed in the standard REA message 1737 handling scenario for NATs as in Section 3.3.2. The message is 1738 forwarded until the edge-NAT is reached. A public IP address and 1739 port number is reserved at an edge-NAT. As shown in Figure 19, 1740 unlike the standard REA message handling case, the edge-NAT is 1741 triggered to send a CREATE message on a new reverse path which 1742 traverse several firewalls or NATs. The new reverse path for CREATE 1743 is necessary to handle routing asymmetries between the edge-NAT and 1744 DR. This behavior requires an indication to the edge-NAT within the 1745 REA message if either the standard behavior (as defined in 1746 Section 3.3.2) is required or a CREATE message is required to be sent 1747 by the edge-NAT. In addition when a CREATE message needs to be sent 1748 by the edge-NAT, the REA message may include the data sender's 1749 address (DSInfo), if available to the data receiver. Figure 19 shows 1750 this proxy mode REA as REA-PROXY. 1752 DS Public Internet NAT Private address NR 1753 No NI NF space NI+ 1754 NR+ 1755 | | REA-PROXY[(DSInfo)] | 1756 | |<------------------------- | 1757 | | RESPONSE[Error/Success] | 1758 | | ---------------------- > | 1759 | | CREATE | 1760 | | ------------------------> | 1761 | | RESPONSE[Error/Success] | 1762 | | <---------------------- | 1763 | | | 1764 | | | 1766 Figure 19: REA Triggering Sending of CREATE Message on Separate 1767 Reverse Path 1769 The processing of REA-PROXY messages is different for every NSIS 1770 entity: 1772 o NSLP initiator (NI+): When the data sender's address information 1773 is known in advance the NI+ MAY include a DSInfo object in the 1774 REA-PROXY request message. When the data sender's address is not 1775 known, NI+'s MUST NOT include a DSInfo object. The NI+ MUST 1776 choose a random value and include it in the NONCE object. NI+ 1777 only generate REA-PROXY messages and should never receive them. 1779 o NSLP forwarder: NSLP forwarders receiving REA-PROXY messages MUST 1780 first perform the checks defined in Section 3.8 and Section 3.9, 1781 if applicable, before any further processing is executed. The NF 1782 SHOULD check with its local policies if it can accept the desired 1783 policy rule given by NTLP's message routing information (MRI). 1784 Further processing depends on the middlebox type: 1786 * NAT: NATs check whether the message is received at the 1787 external (public in most cases) address or at the internal 1788 (private) address. If received at the external address a NF 1789 MAY generate a RESPONSE message with an error of type 'REA 1790 received from outside' and stop forwarding. If received at the 1791 internal address, an IP address/port is reserved. If it is not 1792 an edge-NAT, the NSLP message is forwarded further with the 1793 translated IP address/port. In the case it is an edge-NAT, the 1794 NSLP message is not forwarded any further. The edge-NAT checks 1795 whether it is willing to send CREATE messages on behalf on NI+ 1796 and if so it checks the DSInfo object. The edge-NAT MAY reject 1797 the REA-PROXY request if there is no DSInfo object or if the 1798 address information within DSInfo is not valid or too much 1799 wildcarded. If accepted a RESPONSE message with the external 1800 address and port information is generated. When the edge-NAT 1801 accepts it generates a CREATE message as defined in 1802 Section 3.3.1 and includes a NONCE object having the same value 1803 as of the received NONCE object. The edge-NAT MUST not 1804 generate a CREATE-PROXY message. The edge-NAT MUST refresh the 1805 CREATE message session only if a REA-PROXY refresh message has 1806 been received first. 1808 * Firewall: Firewalls MUST not change their configuration upon a 1809 REA message. They simply MUST forward the message and MUST 1810 keep NTLP state. Edge-Firewalls SHOULD reply with an error 1811 RESPONSE indicating 'no egde-NAT here'. 1813 * Combined NAT and Firewall: Processing at combined Firewall and 1814 NAT middleboxes is the same as in the NAT case. 1816 o NSLP receiver: This type of message should never be received by 1817 any NR+ and it SHOULD be discarded silently. 1819 Processing of a RESPONSE message with an external address object is 1820 different for every NSIS node type: 1822 o NSLP initiator: Upon receiving a RESPONSE message with an 1823 external address object, the NI+ can use the IP address and port 1824 pairs carried for further application signaling. 1826 o NSLP forwarder: NFs simply forward this message as long as they 1827 keep state for the requested reservation. 1829 o NSIS responder: This type of message should never be received by 1830 an NR and it SHOULD be discarded silently. 1832 o Edge-NATs/edge-Firewall: This type of message should never be 1833 received by any Edge-NAT/edge-Firewall and it SHOULD be discarded 1834 silently. 1836 The scenario described in this chapter challenges the data receiver 1837 in a way that it must make a correct assumption about the data 1838 sender's ability to use NSIS NATFW NSLP signaling. There are two 1839 cases a) DS is NSIS unaware and DR assumes DS to be NSIS aware and b) 1840 DS is NSIS aware but DR assumes DS to be NSIS unaware. Case a) will 1841 result in middleboxes blocking the data traffic, since DS will never 1842 send the expected CREATE message. Case b) will result in the DR 1843 successfully requesting proxy mode support by the edge-NAT. The 1844 edge-NAT will send CREATE messages and DS will send CREATE messages 1845 too. Both CREATE messages are handled as separated sessions and 1846 therefore the common rules per session apply. It is up to the NR's 1847 responsibility to decide whether to teardown the REA-PROXY sessions 1848 in the case of the data sender's side being NSIS aware. It is 1849 RECOMMENDED that a DR behind NATs uses the proxy mode of operation by 1850 default, unless the DR knows that the DS is NSIS aware. 1852 The NONCE object is used to build the relationship between received 1853 CREATEs and the message initiator. An NI+ uses the presence of the 1854 NATFW_NONCE object to correlate it to the particular REA-PROXY 1855 request. The absence of an NATFW_NONCE object indicates a CREATE 1856 initiated by the DS and not by the edge-NAT. 1858 There is a possible race condition between the RESPONSE message to 1859 the REA-PROXY and the CREATE message generated by the edge-NAT. The 1860 CREATE message can arrive earlier than the RESPONSE message. An NI+ 1861 MUST accept CREATE messages generated by the edge-NAT even if the 1862 RESPONSE message to the REA-PROXY request was not received. 1864 3.3.8 Proxy Mode for Data Sender behind Middleboxes 1866 As with data receivers behind middleboxes in Section 3.3.7 also data 1867 senders behind middleboxes require proxy mode support as well. The 1868 problem here is that there is no NSIS support at the data receiver's 1869 side and, by default, there will be no response to CREATE request 1870 messages. This scenario requires the last NSIS NATFW NSLP aware node 1871 to terminate the forwarding and to proxy the response to the CREATE 1872 message, meaning that this node is generating RESPONSE messages. 1873 This last node may be an edge-NAT/edge-Firewall, or any other NATFW 1874 NSLP peer, that detects that there is no NR available (probably 1875 through GIMPS timeouts but not limited to). This proxy mode handles 1876 data senders behind a middlebox only; for receivers behind a NAT see 1877 Section 3.3.7. 1879 NIs being aware about a NSIS unaware DR, send a CREATE message 1880 towards DR with a proxy support object. Intermediate NFs can use 1881 this additional information to decide whether to terminate the 1882 message forwarding or not. This proxy support object is an implicit 1883 scoping of the CREATE message. Termination of CREATE-PROXY request 1884 messages with proxy support object included MUST only be done by 1885 egde-NATs/edge-Firewalls; future revisions of this document may 1886 change this behavior. 1888 DS Private Address FW Public Internet NR 1889 NI Space NF no NR 1890 | | | 1891 | CREATE-PROXY | | 1892 |------------------------------>| | 1893 | | | 1894 | RESPONSE[SUCCESS/ERROR] | | 1895 |<------------------------------| | 1896 | | | 1898 Figure 20: Proxy Mode Create Message Flow 1900 The processing of CREATE-PROXY messages and RESPONSE messages is 1901 similar to Section 3.3.1, except that forwarding is stopped at the 1902 edge-NAT/edge-Firewall. The edge-NAT/edge-Firewall responds back to 1903 NI according the situation (error/success) and will be the NR for 1904 future NATFW NSLP communication. 1906 3.3.9 Proxy Mode for Data Receiver behind Firewall 1908 Data receivers behind firewalls would like to use a similar sort of 1909 proxy mode operation to those behind NATs. While finding the 1910 upstream edge-NAT is quite easy, it is only required to find an edge- 1911 NAT but not a very specific one and then the data traffic is route 1912 pinned to the NAT, the location of the appropriate edge-Firewall is 1913 more difficult. Data receivers that are located behind several 1914 firewalls that are placed topology-wise in parallel (multi-homed 1915 network), must find out the one firewall the data traffic will 1916 traverse. This feature of locating the right firewall can be used 1917 for proxy mode support and for blocking certain incoming data 1918 traffic. Proxy mode support is similar to Section 3.3.7 where the DR 1919 is behind one or more NATs and installs "allow" policy rules. 1920 Blocking incoming data traffic requires that the NATFW NSLP locates 1921 the appropriate firewall in order to install a deny policy rule. 1923 The upstream CREATE (UCREATE) message is used to locate upstream 1924 firewalls and to request installation of deny policy rules. The goal 1925 of the method described is to trigger the network to generate a 1926 CREATE message at the edge-Firewall on behalf of the data receiver. 1927 In this case, a NR can signal towards the data sender's address as in 1928 the standard REA message handling scenario for NATs Section 3.3.2. 1929 The message is forwarded until it reaches the edge-Firewall. As 1930 shown in Figure 21, the edge-Firewall is triggered to send a CREATE 1931 message on a new reverse path which could go through internal 1932 firewalls or NATs. The new reverse path for CREATE is necessary to 1933 handle routing asymmetries between the edge-Firewall and DR. UCREATE 1934 does not install any policy rule but the subsequent CREATE message 1935 initiated by the edge-Firewall does. 1937 DS Public Internet FW Private address NR 1938 No NI NF space NI+ 1939 NR+ 1940 | | UCREATE | 1941 | |<------------------------- | 1942 | | RESPONSE[Error/Success] | 1943 | | ---------------------- > | 1944 | | CREATE | 1945 | | ------------------------> | 1946 | | RESPONSE[Error/Success] | 1947 | | <---------------------- | 1948 | | | 1949 | | | 1951 Figure 21: UCREATE Triggering Sending of CREATE Message on Separate 1952 Reverse Path 1954 The processing of UCREATE messages is different for every NSIS 1955 entity: 1957 o NSLP initiator (NI+): NI+ MUST always direct UCREATE message to 1958 the address of DS. NI+ only generates UCREATE messages and should 1959 never receive them. 1961 o NSLP forwarder: NSLP forwarders receiving UCREATE messages MUST 1962 first perform the checks defined in Section 3.8 and Section 3.9, 1963 if applicable, before any further processing is executed. The NF 1964 SHOULD check with its local policies if it can accept the desired 1965 policy rule given by NTLP's message routing information (MRI). 1966 Further processing depends on the middlebox type: 1968 * NAT: NATs check whether the message is received at the 1969 external (public in most cases) address or at the internal 1970 (private) address. If received at the internal interface, NATs 1971 allocated a public IP address and port and forward the message 1972 further. Edge-NATs receiving UCREATE SHOULD response with 1973 error RESPONSE indicating 'no edge-Firewall' 1975 * Firewall: Non edge-Firewalls simply forward the message. Edge- 1976 Firewalls stop forwarding the check for performing the checks 1977 defined in Section 3.8 and Section 3.9, if applicable. If the 1978 message is accepted, load the specified policy rule and 1979 generate CREATE messages back towards the DR as defined in 1980 Section 3.3.1. 1982 * Combined NAT and Firewall: Processing at combined Firewall and 1983 NAT middleboxes is the same as in the Firewall case. 1985 o NSLP receiver: This type of message should never be received by 1986 any NR+ and it SHOULD be discarded silently. 1988 Processing of a RESPONSE message with an external address object is 1989 different for every NSIS node type: 1991 o NSLP initiator (NI+): Upon receiving a RESPONSE message NI+ 1992 should await incoming corresponding CREATE messages. 1994 o NSLP forwarder: NFs simply forward this message as long as they 1995 keep state for the requested reservation. 1997 o NSIS responder: This type of message should never be received by 1998 an NR and it SHOULD be discarded silently. 2000 o Edge-NATs/edge-Firewall: This type of message should never be 2001 received by any Edge-NAT/edge-Firewall and it SHOULD be discarded 2002 silently. 2004 EDITOR's NOTE: The protocol behavior of UCREATE needs a refinement, 2005 see also issue no. 38. 2007 3.4 Calculation of Session Lifetime 2009 NATFW NSLP sessions, and the corresponding policy rules which may 2010 have been installed, are maintained via soft-state mechanism. Each 2011 session is assigned a lifetime and the session is kept alive as long 2012 as the lifetime is valid. After the expiration of the lifetime, 2013 sessions and policy rules MUST be removed automatically and resources 2014 bound to them should be freed as well. Session lifetime is kept at 2015 every NATFW NSLP node. The NSLP forwarders and NSLP responder are 2016 not responsible for triggering lifetime extension refresh messages 2017 (see Section 3.3.3): this is the task of the NSIS initiator. 2019 The NSIS initiator MUST choose a session lifetime (expressed in 2020 seconds) value before sending any message (lifetime is set to zero 2021 for deleting sessions) to other NSLP nodes. The session lifetime 2022 value is calculated based on: 2024 o The number of lost refresh messages that NFs should cope with 2026 o The end to end delay between the NI and NR 2028 o Network vulnerability due to session hijacking ([7]). Session 2029 hijacking is made easier when the NI does not explicitly remove 2030 the session. 2032 o The user application's data exchange duration, in terms of 2033 seconds, minutes or hours and networking needs. This duration is 2034 modeled as M x R, with R the message refresh period (in seconds) 2035 and M a multiplier for R. 2037 As opposed to the NTLP Message Routing state [1] lifetime, the NSLP 2038 session lifetime is not required to have a small value since the NSLP 2039 state refresh is not handling routing changes but security related 2040 concerns. [12] provides a good algorithm to calculate the session 2041 lifetime as well as how to avoid refresh message synchronization 2042 within the network. [12] recommends: 2044 1. The refresh message timer to be randomly set to a value in the 2045 range [0.5R, 1.5R]. 2047 2. To avoid premature loss of state, L (with L being the session 2048 lifetime) must satisfy L >= (K + 0.5)*1.5*R, where K is a small 2049 integer. Then in the worst case, K-1 successive messages may be 2050 lost without state being deleted. Currently K = 3 is suggested 2051 as the default. However, it may be necessary to set a larger K 2052 value for hops with high loss rate. Other algorithms could be 2053 used to define the relation between the session lifetime and the 2054 refresh message period, the algorithm provided is only given as 2055 an example. 2057 This requested lifetime value is placed in the 'lifetime' object of 2058 the NSLP message and messages are forwarded to the next NATFW NSLP 2059 node. 2061 NATFW NFs processing the request message along the path MAY change 2062 the requested lifetime to fit their needs and/or local policy. If an 2063 NF changes the lifetime value it must also indicate the corresponding 2064 refresh message period. NFs MUST NOT increase the lifetime value; 2065 they MAY reject the requested lifetime immediately and MUST generate 2066 an error response message of type 'lifetime too big' upon rejection. 2067 The NSLP request message is forwarded until it reaches the NSLP 2068 responder. NSLP responder MAY reject the requested lifetime value 2069 and MUST generate an error response message of type 'lifetime too 2070 big' upon rejection. The NSLP responder MAY also lower the requested 2071 lifetime to an acceptable value (based on its local policies). NSLP 2072 responders generate their appropriate response message for the 2073 received request message, sets the lifetime value to the above 2074 granted lifetime and sends the message back hop-by-hop towards NSLP 2075 initiator. 2077 Each NSLP forwarder processes the response message, reads and stores 2078 the granted lifetime value. The forwarders SHOULD accept the granted 2079 lifetime, as long as the value is within the tolerable lifetime range 2080 defined in their local policies. They MAY reject the lifetime and 2081 generate a 'lifetime not acceptable' error response message. 2082 Figure 22 shows the procedure with an example, where an initiator 2083 requests 60 seconds lifetime in the CREATE message and the lifetime 2084 is shortened along the path by the forwarder to 20 seconds and by the 2085 responder to 15 seconds. 2087 +-------+ CREATE(lt=60s) +-----------+ CREATE(lt=20s) +--------+ 2088 | |---------------->| NSLP |---------------->| | 2089 | NI | | | | NR | 2090 | |<----------------| forwarder |<----------------| | 2091 +-------+ RESPONSE(lt=15s +-----------+ RESPONSE(lt=15s +--------+ 2092 MRR=3s) MRR=3s) 2094 lt = lifetime 2095 MRR = Message Refresh Rate 2097 Figure 22: Lifetime Calculation Example 2099 3.5 Message Sequencing 2101 NATFW NSLP messages need to carry an identifier so that all nodes 2102 along the path can distinguish messages sent at different points of 2103 time. Messages can be lost along the path, delayed, or duplicated. 2104 So all NATFW NSLP nodes should be able to identify either old 2105 messages that have been received before (duplicated), or the case 2106 that messages have been lost before (loss). For message replay 2107 protection it is necessary to keep information about already received 2108 messages and requires every NATFW NSLP message to carry a message 2109 sequence number (MSN), see also Section 4.3.8. 2111 The MSN MUST be set by the NI and MUST no be set or modified by any 2112 other node. The initial value for the MSN MUST be generated randomly 2113 and MUST be only unique within the used session. The NI MUST 2114 increment the MSN for every message sent. Once the MSN has reached 2115 the maximum value, the next value it takes is zero. 2117 NSIS forwarders and the responder store the with the initial packet 2118 received MSN as start value. NFs and NRs include the received MSN 2119 value in their response messages. 2121 When receiving a request message, a NATFW NSLP node uses the MSN 2122 given in the message to determine whether the state being requested 2123 is different to the state already installed. The message MUST be 2124 discarded if the received MSN value is lower or equal than the stored 2125 MSN value. This received MSN value can indicate a duplicated and 2126 delayed message or replayed message. If the received MSN value is 2127 greater than the already stored MSN value, the NATFW NSLP MUST update 2128 its stored state accordingly, if permitted by all security checks 2129 (see Section 3.8 and Section 3.9, and stores the updated MSN value 2130 accordingly. 2132 These semantics applied to a CREATE message exchange mean that the 2133 first CREATE (initial CREATE to setup the path and session) carries 2134 the initial, randomly generated, MSN. All nodes along the path store 2135 this value and the NR includes the received value in its response 2136 (assuming that the CREATE message reaches the NR). Subsequent CREATE 2137 messages, updating the request policy rule or lifetime, carry an 2138 incremented MSN value, so that intermediate nodes can recognize the 2139 requested update. 2141 3.6 De-Multiplexing at NATs 2143 Section 3.3.2 describes how NSIS nodes behind NATs can obtain a 2144 public reachable IP address and port number at a NAT and how it can 2145 be activated by using CREATE messages (see Section 3.3.1)". The 2146 information about the public IP address/port number can be 2147 transmitted via an application level signaling protocol and/or third 2148 party to the communication partner that would like to send data 2149 toward the host behind the NAT. However, NSIS signaling flows are 2150 sent towards the address of the NAT at which this particular IP 2151 address and port number is allocated and not directly to the 2152 allocated IP address and port number. The NATFW NSLP forwarder at 2153 this NAT needs to know how the incoming NSLP requests are related to 2154 reserved addresses, meaning how to de-multiplex incoming NSIS 2155 requests. 2157 The de-multiplexing method uses information stored at NATs (such as 2158 mapping of public IP address to private, transport protocol, port 2159 numbers), information given by NTLP's message routing information and 2160 further authentication credentials. 2162 3.7 Selecting Opportunistic Addresses for REA 2164 As with all other message types, REA messages need a reachable final 2165 destination IP address. But as many applications do not provide a 2166 destination IP address in the first place, there is a need to choose 2167 a destination address for REA messages. This destination address can 2168 be the final target, but for applications which do not provide an 2169 upfront address, the destination address has to be chosen 2170 independently. Choosing the 'correct' destination IP address may be 2171 difficult and it is possible there is no 'right answer'. [16] shows 2172 choices for SIP and this section provides some hints about choosing a 2173 good destination IP address. 2175 1. Public IP address of the data sender: 2177 * Assumption: 2179 + The data receiver already learned the IP address of the 2180 data sender (e.g., via a third party). 2182 * Problems: 2184 + The data sender might also be behind a NAT. In this case 2185 the public IP address of the data receiver is the IP 2186 address allocated at this NAT. 2188 + Due to routing asymmetry it might be possible that the 2189 routes taken by a) the data sender and the application 2190 server b) the data sender and NAT B might be different, 2191 this could happen in a network deployment such as in 2192 Figure 14. As a consequence it might be necessary to 2193 advertise a new (and different) external IP address within 2194 the application (which may or may not allow that) after 2195 using NSIS to establish a NAT binding. 2197 2. Public IP address of the data receiver: 2199 * Assumption: 2201 + The data receiver already learned his externally visible IP 2202 address (e.g., based on the third party communication). 2204 * Problems: 2206 + Communication with a third party is required. 2208 3. IP address of the Application Server: 2210 * Assumption: 2212 + An application server (or a different third party) is 2213 available. 2215 * Problems: 2217 + If the NSIS signaling message is not terminated at the NAT 2218 of the local network then an NSIS unaware application 2219 server might discard the message. 2221 + Routing might not be optimal since the route between a) the 2222 data receiver and the application server b) the data 2223 receiver and the data sender might be different. 2225 3.8 Session Ownership 2227 Prove of session ownership is a fundamental part of the NATFW NSLP 2228 signaling protocol. It is used to validate the origin of a request, 2229 i.e. invariance of the message sender. Within the NATFW NSLP, the 2230 NSIS initiator (the NI and the NI+) is the ultimate session owner 2231 for all request messages. The request messages are CREATE, REA, 2232 QDRQ, and UCREATE. A prove of ownership MUST be provided for any 2233 request message sent downstream. All intermediate NATFW NSLP nodes 2234 MUST use this prove of ownership to validate the message's origin. 2236 All NATFW nodes along the path must be able to verify that the sender 2237 of a request is the same entity that initially created the session. 2238 As such, the path spans different administrative domains and cannot 2239 rely on different authentication protocols. This requirement demands 2240 a cryptographic scheme independent of the local authentication scheme 2241 in use and administrative requirements being enforced. Relying on a 2242 public key infrastructure (PKI) for the purpose of prove of session 2243 ownership is not reasonable due to deployment problems of a global 2244 PKI. 2246 As a solution, the NATFW NSLP uses purpose-built keys (PBK [2]) to 2247 provide session ownership. A Purpose-built key is an ephemeral 2248 public/private key pair aiming to ensure the sameness principle, 2249 i.e., once an initial exchange of keying material has taken place 2250 successive messages in the communication come from the same source. 2251 Note that the usage of Purpose-built keys does not replace the usage 2252 of hop-by-by security between two neighboring NATFW NSLP nodes. The 2253 usage of PBKs only aims to provider sender invariance and cannot 2254 provide user authentication and the ability for a NATFW node to 2255 authorize the request based on the authenticated identity. A number 2256 of security requirements discussed in this document require the usage 2257 of hop-by-hop security independently of the sender invariance 2258 property. The NATFW NSLP uses purpose-built keys (PBK, [2]) to prove 2259 the session ownership. A Purpose-built key is a public/private key 2260 pair generated per session. For every new session, the NI generates 2261 a new public/private key pair and uses a collision-resistant hash 2262 function to compute the hash of the public key. The hash value is 2263 used as session ID and may be truncated to fit the session ID 2264 object's size. The public key is used to sign certain parts of the 2265 signaling message, including the message sequence number (MSN) 2266 [EDITOR's note: objects to be included in the signature need to be 2267 listed]. The combination of signature and MSN mitigates replay 2268 attacks (see also Section 3.5). NATFW NSLP nodes receiving a request 2269 message can use the public key (if distributed along the path, see 2270 later) to verify the session ID and the signature. 2272 The public key must be distributed amongst participating NATFW NSLP 2273 nodes down the path. The absence of a deployed key distribution 2274 system forces distribution of the public key in-band with the NATFW 2275 NSLP signaling. The public key will be carried in a NATFW_PK object 2276 and needs to be included in the signaling message exchange at an 2277 early point in each session signaling message sequence. Selecting 2278 the point in the sequence for distributing the public key depends on 2279 a design choice to be made here. There are two design choices: 2281 1. The first message exchange from NI towards NR (either CREATE, 2282 REA, or UCREATE) creating a new session does not carry a 2283 signature nor the public key. The second message exchange from 2284 NI towards NR carries the signature and the public key. The 2285 public key is distributed with the second message exchange to all 2286 participating nodes. All further message exchanges must carry 2287 the signature but do not need to repeat the public key. 2288 Figure 23 shows an example with four NATFW NSLP nodes using the 2289 here proposed scheme. 2291 +----+ +-----+ +-----+ +----+ 2292 | NI |-------| NF1 |-------| NF2 |---------| NR | 2293 +----+ +-----+ +-----+ +----+ 2294 | | | | 2295 | CREATE(sid) | | | 2296 t0 |------------->|------------>|------------->| 2297 | | | OK(sid) | 2298 t1 |<-------------|<------------|--------------| 2299 | | | | 2300 | CREATE(sid,sig,pubkey) | | 2301 t2 |------------->|------------>|------------->| 2302 | | | OK(sid) | 2303 t3 |<-------------|<------------|<-------------| 2304 | | | | 2305 | CREATE(sid) | | | 2306 t4 |------------->|------------>|------------->| 2307 | | | OK(sid) | 2308 t5 |<-------------|<------------|--------------| 2309 | | | | 2311 Figure 23: Key Distribution Scheme 1 2313 This scheme first establishes the complete signaling path 2314 ultimately using the NTLP C-MODE with TLS support to secure the 2315 links hop-by-hop (Points t0 to t1). At point t2, the 2316 distribution of the public key along the path is started. 2318 2. The signature and the public key are included in the first 2319 message exchange from NI towards NR (either CREATE, REA, or 2320 UCREATE) and distributed amongst all nodes. All further message 2321 exchanges must carry the signature only but do not need to repeat 2322 the public key. Figure 24 shows an example with four NATFW NSLP 2323 nodes using the here proposed scheme. 2325 +----+ +----+ +----+ +----+ 2326 | NI |--------| NF |--------| NF |---------| NR | 2327 +----+ +----+ +----+ +----+ 2328 | | | | 2329 | CREATE(sid,sig,pubkey) | | 2330 t0 |------------->|------------>|------------->| 2331 | | | OK(sid) | 2332 t1 |<-------------|<------------|--------------| 2333 | | | | 2334 | CREATE(sid) | | | 2335 t2 |------------->|------------>|------------->| 2336 | | | OK(sid) | 2337 t3 |<-------------|<------------|--------------| 2338 | | | | 2339 | CREATE(sid) | | | 2340 t4 |------------->|------------>|------------->| 2341 | | | OK(sid) | 2342 t5 |<-------------|<------------|--------------| 2343 | | | | 2345 Figure 24: Key Distribution Scheme 2 2347 In this scheme, the distribution of the public key is started 2348 with the initial CREATE (point t0) and completed after the first 2349 completed message exchanged (point t1). The first CREATE (at 2350 point t0) is probably exchanged via the unsecured D-MODE. 2352 EDITOR's note: To be done: It is needed to define the hashing 2353 functions as well as the to be used public/private key method. 2355 3.9 Authentication and Authorization 2357 NATFW NSLP nodes receiving signaling messages MUST first check 2358 whether this message is authenticated and authorized to perform the 2359 requested action. 2361 The NATFW NSLP is expected to run in various environments, such as IP 2362 telephone systems, enterprise networks, home networks, etc. The 2363 requirements on authentication and authorization are quite different 2364 between these use cases. While a home gateway, or an Internet cafe, 2365 using NSIS may well be happy with a "NATFW signaling coming from 2366 inside the network" policy for authorization of signaling, enterprise 2367 networks are likely to require a stronger authenticated/authorized 2368 signaling. This enterprise scenario may require the use of an 2369 infrastructure and administratively assigned identities to operate 2370 the NATFW NSLP. 2372 EDITOR's note: It is still not clear what are the requirements for 2373 authentication and authorization in the NATFW case. This is going to 2374 be discussed at the next IETF meeting. 2376 3.10 Reacting to Route Changes 2378 The NATFW NSLP needs to react to route changes in the data path. 2379 This assumes the capability to detect route changes, to perform NAT 2380 and firewall configuration on the new path and possibly to tear down 2381 session state on the old path. The detection of route changes is 2382 described in Section 7 of [1] and the NATFW NSLP relies on 2383 notifications about route changes by the NTLP. This notification 2384 will be conveyed by the API between NTLP and NSLP, which is out of 2385 scope of this memo. 2387 A NATFW NSLP node detecting a route change, by means described in the 2388 NTLP specification or others, generates a NOTIFY message indicating 2389 this change and sends this upstream towards NI. Intermediate NFs on 2390 the way to the NI can use this information to decide later if their 2391 session can be deleted locally if they do not receive an update 2392 within a certain time period. 2394 The NI receiving this NOTIFY message SHOULD generate an update 2395 message and sends it downstream as for the initial exchange. All the 2396 remaining processing and message forwarding, such as NSLP next hop 2397 discovery, is subject to regular NSLP processing as described in the 2398 particular sections. Merge points, NFs receiving update CREATEs, can 2399 easily use the session ID and signature information (session 2400 ownership information) to update the session state. 2402 4. NATFW NSLP Message Components 2404 A NATFW NSLP message consists of a NSLP header and one or more 2405 objects following the header. The NSLP header is common for all 2406 NSLPs and objects are Type-Length-Value (TLV) encoded using big 2407 endian (network ordered) binary data representations. Header and 2408 objects are aligned to 32 bit boundaries and object lengths that are 2409 not multiples of 32 bits must be padded to the next higher 32 bit 2410 multiple. 2412 The whole NSLP message is carried as payload of a NTLP message. 2414 Note that the notation 0x is used to indicate hexadecimal numbers. 2416 4.1 NSLP Header 2418 The NSLP header is common to all NSLPs and is the first part of all 2419 NSLP messages. It contains two fields, the NSLP message type and a 2420 reserved field. The total length is 32 bits. The layout of the NSLP 2421 header is defined by Figure 25. 2423 0 16 31 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2425 | NSLP message type | reserved | 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 Figure 25: Common NSLP header 2430 The reserved field MUST be set to zero in the NATFW NSLP header 2431 before sending and MUST be ignored during processing of the header. 2432 Note that other NSLPs use this field as a flag field. 2434 4.2 NSLP message types 2436 The message types identify requests and responses. Defined messages 2437 types are: 2439 o 0x0101 : CREATE 2441 o 0x0102 : RESERVE-EXTERNAL-ADDRESS(REA) 2443 o 0x0104 : UCREATE 2444 o 0x0108 : QDRQ 2446 o 0x0201 : RESPONSE 2448 o 0x0301 : NOTIFY 2450 4.3 NSLP Objects 2452 NATFW NSLP objects use a common header format defined by Figure 26. 2453 The object header contains two fields, the NSLP object type and the 2454 object length. Its total length is 32 bits. 2456 0 1 2 3 2457 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 2458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2459 |A|B|r|r| Object Type |r|r|r|r| Object Length | 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 Figure 26: Common NSLP object header 2464 The length is the total length of the object without the object 2465 header. The unit is a word, consisting of 4 octets. The particular 2466 values of type and length for each NSLP object are listed in the 2467 subsequent sections that define the NSLP objects. The two leading 2468 bits of the NSLP object header are used to signal the desired 2469 treatment for objects whose treatment has not been defined in this 2470 memo (see [1], Section 3.2), i.e., the Object Type has not been 2471 defined. NATFW NSLP uses a subset of the categories defined in 2472 GIMPS: 2474 o AB=00 ("Mandatory"): If the object is not understood, the entire 2475 message containing it must be rejected with an error indication. 2477 o AB=01 ("Optional"): If the object is not understood, it should be 2478 deleted and then the rest of the message processed as usual. 2480 o AB=10 ("Forward"): If the object is not understood, it should be 2481 retained unchanged in any message forwarded as a result of message 2482 processing, but not stored locally. 2484 The combination AB=11 ("Refresh") MUST NOT be used since the NATFW 2485 NSLP refreshes its state end-to-end and not locally. Fields marked 2486 with 'r' are reserved for future use. 2488 The following sections do not repeat the common NSLP object header, 2489 they just state the type and the length. 2491 4.3.1 Session Lifetime Object 2493 The session lifetime object carries the requested or granted lifetime 2494 of a NATFW NSLP session measured in seconds. The Message refresh 2495 rate value is set by default to 0xFFFF and only set to a specific 2496 value when an intermediate node changes the message lifetime and 2497 informs the upstream node about the recommended message refresh rate. 2499 Type: NATFW_LT 2501 Length: 2 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 | NATFW NSLP session lifetime | 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 | NATFW NSLP message refresh rate | 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 Figure 27: Lifetime object 2511 4.3.2 PBK Public Key 2513 The PBK public key object carries the public key used for session 2514 ownership as described in Section 3.8. EDITOR's note: The key length 2515 needs to be defined. 2517 Type: NATFW_LT 2519 Length: tbd. 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 // Public Key // 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 Figure 28: PBK public key object 2527 4.3.3 External Address Object 2529 The external address object can be included in RESPONSE messages 2530 (Section 4.4.3) only. 2532 Type: NATFW_EXT_IPv4 2534 Length: 2 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 | port number | reserved | 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 | IPv4 address | 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 Figure 29: External Address Object for IPv4 addresses 2544 Type: NATFW_EXT_IPv6 2546 Length: 5 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | port number | reserved | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | | 2552 + + 2553 | | 2554 + IPv6 address + 2555 | | 2556 + + 2557 | | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 Figure 30: External Address Object for IPv6 addresses 2562 Please note that the field 'port number' MUST be set to 0 if only an 2563 IP address has been reserved, for instance, by a traditional NAT. A 2564 port number of 0 MUST be ignored in processing this object. 2566 4.3.4 Extended Flow Information Object 2568 In general, flow information is kept at the NTLP level during 2569 signaling. The message routing information of the NTLP carries all 2570 necessary information. Nevertheless, some additional information may 2571 be required for NSLP operations. The 'extended flow information' 2572 object carries this additional information about action to be taken 2573 on the installed policy rules. 2575 Type: NATFW_EXT_FLOW 2577 Length: 1 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 | rule action | reserved | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 Figure 31: Extended Flow Information 2585 These fields are defined for the policy rule object: 2587 o Rule action: This field indicates the action for the policy rule 2588 to be activated. Allowed values are 'allow' (0x01) and 'deny' 2589 (0x02) 2591 4.3.5 Response Code Object 2593 This object carries the response code, which may be indications for 2594 either a successful request or failed request depending on the value 2595 of the 'response code' field. 2597 Type: NATFW_RESPONSE 2599 Length: 1 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 | response code | 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 Figure 32: Response Code Object 2606 TBD: Define response classes, success codes and error codes. 2607 Possible error classes are: 2609 o Policy rule errors 2611 o Authentication and Authorization errors 2613 o NAT 2615 Currently errors defined in this memo are: 2617 o lifetime too big 2619 o lifetime not acceptable 2621 o no NAT here 2623 o no reservation found 2625 o requested external address from outside 2627 o re-authorization needed 2629 o routing change detected 2631 4.3.6 Proxy Support Object 2633 This object indicates that proxy mode support is required. Either in 2634 a REA message or CREATE message. 2636 Type: NATFW_PROXY 2638 Length: 0 2640 4.3.7 Nonce Object 2642 Type: NATFW_NONCE 2644 Length: 1 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 | nonce | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 Figure 33: Nonce Object 2652 4.3.8 Message Sequence Number Object 2654 This object carries the MSN value as described in Section 3.5. 2656 Type: NATFW_RESP_MSN 2658 Length: 1 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | message sequence number | 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 Figure 34: Message Sequence Number Object 2666 4.3.9 Bound Session ID Object 2668 This object carries a session ID and is used for QDRQ messages only. 2670 Type: NATFW_BSID 2672 Length: 1 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 | bound session ID | 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 Figure 35: Bound Session ID Object 2680 This object is used when a session owner queries multiple session, 2681 every session would be indicated with the bound session ID object. 2683 4.3.10 Data Sender Information Object 2685 Type: NATFW_DSINFO_IPv4 2687 Length: 2 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | port number | reserved | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | IPv4 address | 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 Figure 36: Data Sender's IPv4 Address Object 2697 Type: NATFW_DSINFO_IPv6 2699 Length: 5 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | port number | reserved | 2703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 | | 2705 + + 2706 | | 2707 + IPv6 address + 2708 | | 2709 + + 2710 | | 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 Figure 37: Data Sender's IPv6 Address Object for IPv6 addresses 2715 4.3.11 NATFW NF Hop Count Object 2717 Type: NATFW_NF_HOPCNT 2719 Length: 1 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | NATFW NF HOP COUNT | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 Figure 38: NATFW NF Hop Count Object 2727 Editor note next revision will include Hop count, maximum hops and 2728 QDRQ type in the same object to minimize the overhead since 4 bits 2729 would be sufficient for the counters. 2731 4.3.12 Maximum Hops Object 2733 Type: NATFW_NF_MAX_HOPCNT 2735 Length: 1 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | NATFW NF MAX HOP COUNT | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 Figure 39: NATFW NF Maximum Hop Count Object 2743 4.3.13 Session Status object 2745 The session status object is inserted within the QDRQ message and 2746 copied in a response message. It embeds the current local node's 2747 session status and the node's IP address 2749 Type: SESSION_STS 2751 Length: 2 or 5 2753 SESSION STATUS: 2755 Length 1, Possible values: UP(0),HIGH_PPS(1), PENDING(2), DOWN(3) 2757 Reserved bits: RRR 2759 Length 3 bits 2760 IP version: V bit 2762 Length 1 bit: IPv4(0), IPv6(1) 2764 NODE IP ADDRESS: 2766 Length 1 or 4 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 | SESSION STATUS |R|R|R|V| 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | NODE IP ADDRESS (1 or 4 words) | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 Figure 40: Session Status Object 2776 4.3.14 QDRQ type 2778 Type: QDRQ_TYPE 2780 Length: 1 2782 Possible values: SINGLE(0), LIST(1) 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | QDRQ TYPE | 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 Figure 41: QDRQ TYPE object 2790 4.3.15 QDRQ Response object 2792 TBC for next version: includes an optional bound session id, an 2793 optional flow descriptor (used when a LIST QDRQ type is used) and a 2794 mandatory session status 2796 4.4 Message Formats 2798 This section defines the content of each NATFW NSLP message type. 2800 The message types are defined in Section 4.2. First, the request 2801 messages are defined with their respective objects to be included in 2802 the message. Second, the response messages are defined with their 2803 respective objects to be included. 2805 Basically, each message is constructed of NSLP header and one or more 2806 NSLP objects. The order of objects is not defined, meaning that 2807 objects may occur in any sequence. Objects are marked either with 2808 mandatory [M] or optional [O]. Where [M] implies that this 2809 particular object MUST be included within the message and where [O] 2810 implies that this particular object is OPTIONAL within the message. 2812 Each section elaborates the required settings and parameters to be 2813 set by the NSLP for the NTLP, for instance, how the message routing 2814 information is set. 2816 4.4.1 CREATE 2818 The CREATE request message is used to create NSLP sessions and to 2819 create policy rules. Furthermore, CREATE messages are used to 2820 refresh sessions and to delete them. 2822 The CREATE message carries these objects: 2824 o Lifetime object [M] 2826 o Extended flow information object [M] 2828 o Message sequence number object [M] 2830 o Proxy support object [O] 2832 o Nonce object [M if CREATE-PROXY message] 2834 The message routing information in the NTLP MUST be set to DS as 2835 source address and DR as destination address. All other parameters 2836 MUST be set according the required policy rule. 2838 4.4.2 RESERVE-EXTERNAL-ADDRESS (REA) 2840 The RESERVE-EXTERNAL-ADDRESS (REA) request message is used to target 2841 a NAT and to allocated an external IP address and possibly port 2842 number, so that the initiator of the REA request has a public 2843 reachable IP address/port number. 2845 The REA request message carries these objects: 2847 o Lifetime object [M] 2849 o Message sequence number object [M] 2851 o Extended flow information object [M] 2853 o Proxy support object [O] 2855 o Nonce object [M if proxy support object is included] 2857 o Data sender information object [O] 2859 The REA message needs special NTLP treatment. First of all, REA 2860 messages travel the wrong way, from the DR towards DS. Second, the 2861 DS' address used during the signaling may be not the actual DS (see 2862 Section 3.7). Therefore, the NTLP flow routing information is set to 2863 DR as initiator and DS as responders, a special field is given in the 2864 NTLP: The signaling destination. 2866 4.4.3 RESPONSE 2868 RESPONSE messages are responses to CREATE, REA, UCREATE, and QDRQ 2869 messages. 2871 The RESPONSE message carries these objects: 2873 o Lifetime object [M] 2875 o Message sequence number object [M] 2877 o Response code object [M] 2879 o External address object [O]([M] for success responses to REA) 2881 This message is routed upstream. 2883 EDITOR's note: Text says that this section is defining the behavior 2884 depending on the response type. 2886 4.4.4 QDRQ 2888 QDRQ messages are used for query and diagnosis purposes. 2890 The QDRQ message carries these objects: 2892 o Response object [M] 2893 o Message sequence number object [M] 2895 o NATFW NSLP Hop Count [M] 2897 o Maximum Hop Count value [O] 2899 o Bound session ID [O] 2901 o Session status [O] 2903 o QDRQ type [O] 2905 This message is routed downstream. 2907 4.4.5 NOTIFY 2909 The NOTIFY messages is used to report asynchronous events happening 2910 along the signaled path to other NATFW NSLP nodes. 2912 The NOTIFY message carries this object: 2914 o Response code object with NOTIFY code [M]. 2916 The message routing information in the NTLP MUST be set with the NI's 2917 address being the destination address and the node's address as 2918 source address. The message is forwarded upstream hop by hop using 2919 the existing upstream node address entry within the node's Message 2920 Routing State table. The session id object must be set to the 2921 corresponding session that is effected by this asynchronous event. 2923 4.4.6 UCREATE 2925 TBD: XYX. 2927 5. NATFW NSLP NTLP Requirements 2929 The NATFW NSLP requires the following capabilities from the NTLP: 2931 o Ability to detect that the NSIS Responder does not support NATFW 2932 NSLP. This capability is key to launching the proxy mode behavior 2933 as described in Section 3.3.7 and [14]. 2935 o Detection of NATs and their support of the NSIS NATFW NSLP. If 2936 the NTLP discovers that the NSIS host is behind an NSIS aware NAT, 2937 the NR will send REA messages to the opportunistic address. If 2938 the NTLP discovers that the NSIS host is behind a NAT that does 2939 not support NSIS then the NSIS host will need to use a separate 2940 NAT traversal mechanism. 2942 o Message origin authentication and message integrity protection 2944 o Detection of routing changes 2946 o Protection against malicious announcement of fake path changes, 2947 this is needed to mitigate a threat discussed in Section 7 of [7] 2949 6. NSIS NAT and Firewall Transition Issues 2951 NSIS NAT and Firewall transition issues are premature and will be 2952 addressed in a separate draft (see [14]). An update of this section 2953 will be based on consensus. 2955 7. Security Considerations 2957 Security is of major concern particularly in case of Firewall 2958 traversal. This section provides security considerations for the 2959 NAT/Firewall traversal and is organized as follows: 2961 Section 7.1 describes the framework assumptions with regard to the 2962 assumed trust relationships between the participating entities. This 2963 subsection also motivates a particular authorization model. 2965 Security threats that focus on NSIS in general are described in [7] 2966 and they are applicable to this document. Within Section 7.2 we 2967 extend this threat investigation by considering NATFW NSLP specific 2968 threats. Based on the security threats we list security 2969 requirements. 2971 Finally we illustrate how the security requirements that were created 2972 based on the security threats can be fullfilled by specific security 2973 mechanisms. These aspects will be elaborated in Section 7.3. 2975 7.1 Trust Relationship and Authorization 2977 The NATFW NSLP is a protocol which may involve a number of NSIS nodes 2978 and is, as such, not a two-party protocol. This fact requires more 2979 thoughts about scenarios, trust relationships and authorization 2980 mechanisms. Trust relationships and authorization are very important 2981 for the protocol machinery and they are closely related to each other 2982 in the sense that a certain degree of trust is required to authorize 2983 a particular action. For any action (e.g. create/delete pinholes), 2984 authorization is very important due to the nature of middleboxes. 2985 More problematic scenarios are described in Appendix B. 2987 Different types of trust relationships may affect different 2988 categories of middleboxes. As explained in [22], establishment of a 2989 financial relationship is typically very important for QoS signaling, 2990 whereas financial relationships are less directly of interest for 2991 NATFW middlebox signaling. It is therefore not particularly 2992 surprising that there are differences in the nature and level of 2993 authorization likely to be required in a QoS signaling environment 2994 and in NATFW middlebox signaling. Typically NATFW signaling requires 2995 authorization to configure firewalls or to modify NAT bindings. The 2996 outcome of the authorization is either allowed or disallowed whereas 2997 QoS signaling might just indicate that a lower QoS reservation is 2998 allowed. 3000 Different trust relationships that appear in middlebox signaling 3001 environments are described in the subsequent sub-sections. As a 3002 comparison with other NSIS signaling application it might be 3003 interesting to mention that QoS signaling relies on peer-to-peer 3004 trust relationships and authorization between neighboring nodes or 3005 neighboring networks. These type of trust relationships turn out to 3006 be simpler for a protocol. However, there are reasons to believe 3007 that this is not the only type of trust relationship found in today's 3008 networks. 3010 7.1.1 Peer-to-Peer Trust Relationship 3012 Starting with the simplest scenario, it is assumed that neighboring 3013 nodes trust each other. The required security association to 3014 authenticate and to protect a signaling message is either available 3015 (after manual configuration), or has been dynamically established 3016 with the help of an authentication and key exchange protocol. If 3017 nodes are located closely together, it is assumed that security 3018 association establishment is easier than establishing it between 3019 distant nodes. It is, however, difficult to describe this 3020 relationship generally due to the different usage scenarios and 3021 environments. Authorization heavily depends on the participating 3022 entities, but for this scenario, it is assumed that neighboring 3023 entities trust each other (at least for the purpose of policy rule 3024 creation, maintenance, and deletion). Note that Figure 42 does not 3025 illustrate the trust relationship between the end host and the access 3026 network. 3028 +------------------------+ +-------------------------+ 3029 |Network A | | Network B| 3030 | +---------+ +---------+ | 3031 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3032 | | | box 1 | Trust | box 2 | | | 3033 | | +---------+ Relationship +---------+ | | 3034 | | Trust | | Trust | | 3035 | | Relationship | | Relationship | | 3036 | | | | | | 3037 | +--+---+ | | +--+---+ | 3038 | | Host | | | | Host | | 3039 | | A | | | | B | | 3040 | +------+ | | +------+ | 3041 +------------------------+ +-------------------------+ 3043 Figure 42: Peer-to-Peer Trust Relationship 3045 7.1.2 Intra-Domain Trust Relationship 3047 In larger corporations, often more than one middlebox is used to 3048 protect or serve different departments. In many cases, the entire 3049 enterprise is controlled by a security department, which gives 3050 instructions to the department administrators. In such a scenario, a 3051 peer-to-peer trust-relationship might be prevalent. Sometimes it 3052 might be necessary to preserve authentication and authorization 3053 information within the network. As a possible solution, a 3054 centralized approach could be used, whereby an interaction between 3055 the individual middleboxes and a central entity (for example a policy 3056 decision point - PDP) takes place. As an alternative, individual 3057 middleboxes could exchange the authorization decision with another 3058 middlebox within the same trust domain. Individual middleboxes 3059 within an administrative domain should exploit their trust 3060 relationship instead of requesting authentication and authorization 3061 of the signaling initiator again and again. Thereby complex protocol 3062 interactions are avoided. This provides both a performance 3063 improvement without a security disadvantage since a single 3064 administrative domain can be seen as a single entity. Figure 43 3065 illustrates a network structure which uses a centralized entity. 3067 +-----------------------------------------------------------+ 3068 | Network A | 3069 | +---------+ +---------+ 3070 | +----///--------+ Middle- +------///------++ Middle- +--- 3071 | | | box 2 | | box 2 | 3072 | | +----+----+ +----+----+ 3073 | +----+----+ | | | 3074 | | Middle- +--------+ +---------+ | | 3075 | | box 1 | | | | | 3076 | +----+----+ | | | | 3077 | | | +----+-----+ | | 3078 | | | | Policy | | | 3079 | +--+---+ +-----------+ Decision +----------+ | 3080 | | Host | | Point | | 3081 | | A | +----------+ | 3082 | +------+ | 3083 +-----------------------------------------------------------+ 3085 Figure 43: Intra-domain Trust Relationship 3087 7.1.3 End-to-Middle Trust Relationship 3089 In some scenarios, a simple peer-to-peer trust relationship between 3090 participating nodes is not sufficient. Network B might require 3091 additional authorization of the signaling message initiator. If 3092 authentication and authorization information is not attached to the 3093 initial signaling message then the signaling message arriving at 3094 Middlebox 2 would result in an error message being created, which 3095 indicates the additional authorization requirement. In many cases 3096 the signaling message initiator is already aware of the additionally 3097 required authorization before the signaling message exchange is 3098 executed. Replay protection is a requirement for authentication to 3099 the non-neighboring middlebox, which might be difficult to accomplish 3100 without adding additional roundtrips to the signaling protocol (e.g., 3101 by adding a challenge/response type of message exchange). 3103 Figure 44 shows the slightly more complex trust relationships in this 3104 scenario. 3106 +--------------------+ +---------------------+ 3107 | Network A | Trust |Network B | 3108 | | Relationship | | 3109 | +---------+ +---------+ | 3110 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 3111 | | | box 1 | +-------+ box 2 | | | 3112 | | +---------+ | +---------+ | | 3113 | |Trust | | | Trust | | 3114 | |Relationship | | | Relationship| | 3115 | | | | | | | 3116 | +--+---+ | | | +--+---+ | 3117 | | Host +----///----+------+ | | Host | | 3118 | | A | |Trust | | B | | 3119 | +------+ |Relationship | +------+ | 3120 +--------------------+ +---------------------+ 3122 Figure 44: End-to-Middle Trust Relationship 3124 7.2 Security Threats and Requirements 3126 This section describes NATFW specific security threats and 3127 requirements. 3129 7.2.1 Attacks related to authentication and authorization 3131 The NSIS message which installs policy rules at a middlebox is the 3132 CREATE message. The CREATE message travels from the Data Sender (DS) 3133 toward the Data Receiver (DR). The packet filter or NAT binding is 3134 marked as pending by the middleboxes along the path. If it is 3135 confirmed with a success RESPONSE message from the DR, the requested 3136 policy rules on the middleboxes are installed to allow the traversal 3137 of a data flow. 3139 +-----+ +-----+ +-----+ 3140 | DS | | MB | | DR | 3141 +-----+ +-----+ +-----+ 3142 | | | 3143 | CREATE | CREATE | 3144 |-------------------->+-------------------->| 3145 | | | 3146 | Succeeded/Error | Succeeded/Error | 3147 |<--------------------+<--------------------| 3148 | | | 3149 ==========================================> 3150 Direction of data traffic 3152 Figure 45: CREATE Mode 3154 In this section we will consider some simple scenarios for middlebox 3155 configuration: 3157 o Data Sender (DS) behind a firewall 3159 o Data Sender (DS) behind a NAT 3161 o Data Receiver (DR) behind a firewall 3163 o Data Receiver (DR) behind a NAT 3165 A real-world scenario could include a combination of these firewall/ 3166 NAT placements, such as, a DS and/or a DR behind a chain of NATs and 3167 firewalls. 3169 Figure 46 shows one possible scenario: 3171 +-------------------+ +--------------------+ 3172 | Network A | | Network B | 3173 | | | | 3174 | +-----+ | //-----\\ | +-----+ | 3175 | | MB2 |--------+----| INET |----+--------| MB3 | | 3176 | +-----+ | \\-----// | +-----+ | 3177 | | | | | | 3178 | +-----+ | | +-----+ | 3179 | | MB1 | | | | MB4 | | 3180 | +-----+ | | +-----+ | 3181 | | | | | | 3182 | +-----+ | | +-----+ | 3183 | | DS | | | | DR | | 3184 | +-----+ | | +-----+ | 3185 +-------------------+ +--------------------+ 3187 MB: Middle box (NAT or Firewall or a combination) 3188 DS: Data Sender 3189 DR: Data Receiver 3191 Figure 46: Several middleboxes per network 3193 7.2.1.1 Data Sender (DS) behind a firewall 3195 +------------------------------+ 3196 | | 3197 | +-----+ create +-----+ 3198 | | DS | --------------> | FW | 3199 | +-----+ +-----+ 3200 | | 3201 +------------------------------+ 3203 DS sends a CREATE message to request the traversal of a data flow. 3205 It is up to network operators to decide how far they can trust users 3206 inside their networks. However, there are several reasons why they 3207 should not. 3209 The following attacks are possible: 3211 o DS could open a firewall pinhole with a source address different 3212 from its own host. 3214 o DS could open firewall pinholes for incoming data flows that are 3215 not supposed to enter the network. 3217 o DS could request installation of any policy rules and allow all 3218 traffic go through. 3220 SECURITY REQUIREMENT: The middlebox MUST authenticate and authorize 3221 the neighboring NAT/FW NSLP node which requests an action. 3222 Authentication and authorization of the initiator SHOULD be 3223 provided to NATs and Firewalls along the path. 3225 7.2.1.2 Data Sender (DS) behind a NAT 3227 The case 'DS behind a NAT' is analogous to the case 'DS behind a 3228 firewall'. 3230 Figure 48 illustrates such a scenario: 3232 +------------------------------+ 3233 | | 3234 | +------+ CREATE | 3235 | | NI_1 | ------\ +-----+ CREATE +-----+ 3236 | +------+ \------> | NAT |-------->| MB | 3237 | +-----+ +-----+ 3238 | +------+ | 3239 | | NI_2 | | 3240 | +------+ | 3241 +------------------------------+ 3243 Figure 48: Several NIs behind a NAT 3245 In this case the middlebox MB does not know who is the NSIS Initiator 3246 since both NI_1 and NI_2 are behind a NAT (which is also NSIS aware). 3247 Authentication needs to be provided by other means such as the NSLP 3248 or the application layer. 3250 SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that 3251 the neighboring NAT/FW NSLP node is authorized to request an 3252 action. Authentication and authorization of the initiator (which 3253 is the DR in this scenario) to the middleboxes (via another NSIS 3254 aware middlebox) SHOULD be provided. 3256 7.2.1.3 Data Receiver (DR) behind a firewall 3258 In this case a CREATE message comes from an entity DS outside the 3259 network towards the DR inside the network. 3261 +------------------------------+ 3262 | | 3263 +-----+ CREATE +-----+ CREATE +-----+ | 3264 | DS | -------------> | FW | -------------> | DR | | 3265 +-----+ <------------- +-----+ <------------- +-----+ | 3266 success RESPONSE | success RESPONSE | 3267 | | 3268 +------------------------------+ 3270 Since policy rules at middleboxes must only be installed after 3271 receiving a successful response it is necessary that the middlebox 3272 waits until the Data Receiver DR confirms the request of the Data 3273 Sender DS with a success RESPONSE message. This is, however, only 3274 necessary 3276 o if the action requested with the CREATE message cannot be 3277 authorized and 3279 o if the middlebox is still forwarding the signaling message towards 3280 the end host (without state creation/deletion/modification). 3282 This confirmation implies that the data receiver is expecting the 3283 data flow. 3285 At this point we differentiate two cases: 3287 1. DR knows the IP address of the DS (for instance because of some 3288 previous application layer signaling) and is expecting the data 3289 flow. 3291 2. DR might be expecting the data flow (for instance because of some 3292 previous application layer signaling) but does not know the IP 3293 address of the Data Sender DS. 3295 For the second case, Figure 50 illustrates a possible attack: an 3296 adversary Mallory M could be sniffing the application layer signaling 3297 and thus knows the address and port number where DR is expecting the 3298 data flow. Thus it could pretend to be DS and send a CREATE message 3299 towards DR with the data flow description (M -> DR). Since DR does 3300 not know the IP address of DS, it is not able to recognize that the 3301 request is coming from the "wrong guy". It will send a success 3302 RESPONSE message back and the middlebox will install policy rules 3303 that will allow Mallory M to inject its data into the network. 3305 Application Layer signaling 3306 <------------------------------------> 3307 / \ 3308 / +-----------------\------------+ 3309 / | \ | 3310 +-----+ +-----+ +-----+ | 3311 | DS | -> | FW | | DR | | 3312 +-----+ / +-----+ +-----+ | 3313 CREATE / | | 3314 +-----+ / +-------------------------------+ 3315 | M |---------- 3316 +-----+ 3318 Figure 50: DR behind a firewall with an adversary 3320 Network administrators will probably not rely on a DR to check the IP 3321 address of the DS. Thus we have to assume the worst case with an 3322 attack such as in Figure 50. Many operators might not allow NSIS 3323 signaling message to traverse the firewall in Figure 50 without 3324 proper authorization. In this case the threat is not applicable. 3326 SECURITY REQUIREMENT: A binding between the application layer and the 3327 NSIS signaling SHOULD be provided. 3329 7.2.1.4 Data Receiver (DR) behind a NAT 3331 When a data receiver DR behind a NAT sends a RESERVE-EXTERNAL-ADDRESS 3332 (REA) message to get a public reachable address that can be used as a 3333 contact address by an arbitrary data sender if the DR was unable to 3334 restrict the future data sender. The NAT reserves an external 3335 address and port number and sends them back to DR. The NAT adds an 3336 address mapping entry in its reservation list which links the public 3337 and private addresses as follows: 3339 (DR_ext <=> DR_int) (*). 3341 The NAT sends a RESPONSE message with the external address' object 3342 back to the DR with the address DR_ext. DR informs DS about the 3343 public address that it has recently received, for instance, by means 3344 of application layer signaling. 3346 When a data sender sends a CREATE message towards DR_ext then the 3347 message will be forwarded to the DR. The data sender might want to 3348 update the NAT binding stored at the edge-NAT to make it more 3349 restrictive. 3351 We assume that the adversary Mallory M obtains the contact address 3352 (i.e., external address and port) allocated at the NAT possibly by 3353 eavesdropping on the application layer signaling and sends a CREATE 3354 message. As a consequence Mallory would be able to communicate with 3355 DR (if M is authorized by the edge-NAT and if the DR accepts CREATE 3356 and returns a RESPONSE. 3358 Application Layer signaling 3359 <------------------------------------> 3360 / \ 3361 / +-----------------\------------+ 3362 / | REA \ | 3363 +-----+ +-----+ <----------- +-----+ | 3364 | DS | -> | NAT | -----------> | DR | | 3365 +-----+ / +-----+ rtn_ext_addr +-----+ | 3366 CREATE / | | 3367 +-----+ / +-------------------------------+ 3368 | M |---------- 3369 +-----+ 3371 SECURITY REQUIREMENT: The DR MUST be able to specify which data 3372 sender are allowed to traverse the NAT in order to be forwarded to 3373 DRs address. 3375 7.2.1.5 NSLP Message Injection 3377 Malicious hosts, located either off-path or on-path, could inject 3378 arbitrary NATFW NSLP messages into the signaling path, causing 3379 several problems. These problems apply when no proper authorization 3380 and authentication scheme is available. 3382 By injecting a bogus CREATE message with lifetime set to zero, a 3383 malicious host could try to teardown NATFW NSLP session state 3384 partially or completely on a data path, causing a service 3385 interruption. 3387 By injecting a bogus responses or NOTIFY message, for instance, 3388 timeout, a malicious host could try to teardown NATFW NSLP session 3389 state as well. This could affect the data path partially or totally, 3390 causing a service interruption. 3392 SECURITY REQUIREMENT: Messages, such as TRIGGER, can be misused by 3393 malicious hosts, and therefore need to be authorized. 3395 7.2.2 Denial-of-Service Attacks 3397 In this section we describe several ways how an adversary could 3398 launch a Denial of service (DoS) attack on networks running NSIS for 3399 middlebox configuration to exhaust their resources. 3401 7.2.2.1 Flooding with CREATE messages from outside 3403 7.2.2.1.1 Attacks due to NSLP state 3405 A CREATE message requests the NSLP to store state information such as 3406 a NAT binding or a policy rule. 3408 The policy rules requested in the CREATE message will be installed at 3409 the arrival of a confirmation from the Data Receiver with a success 3410 RESPONSE message. A successful RESPONSE message includes the session 3411 ID. So the NSLP looks up the NSIS session and installs the requested 3412 policy rules. 3414 An adversary from outside could launch a DoS attack with arbitrary 3415 CREATE messages. For each of these messages the middlebox needs to 3416 store state information such as the policy rules to be loaded, i.e., 3417 the middlebox could run out of memory. This kind of attack is also 3418 mentioned in [7] Section 4.8. 3420 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 'create- 3421 session' message before storing state information. 3423 7.2.2.1.2 Attacks due to authentication complexity 3425 This kind of attack is possible if authentication is based on 3426 mechanisms that require computing power, for example, digital 3427 signatures. 3429 For a more detailed treatment of this kind of attack, the reader is 3430 encouraged to see [7]. 3432 SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new 3433 denial of service attacks based on authentication or key 3434 management mechanisms. 3436 7.2.2.1.3 Attacks to the endpoints 3438 The NATFW NSLP requires firewalls to forward NSLP messages, a 3439 malicious node may keep sending NSLP messages to a target. This may 3440 consume the access network resources of the victim, drain the battery 3441 of the victim's terminal and may force the victim to pay for the 3442 received although undesired data. 3444 This threat may be more particularly be relevant in networks where 3445 access link is a limited resource, for instance in cellular networks, 3446 and where the terminal capacities are limited. 3448 SECURITY REQUIREMENT: A NATFW NSLP aware firewall or NAT MUST be able 3449 to block unauthorized signaling message, if this threat is a 3450 concern. 3452 7.2.2.2 Flooding with REA messages from inside 3454 Although we are more concerned with possible attacks from outside the 3455 network, we need also to consider possible attacks from inside the 3456 network. 3458 An adversary inside the network could send arbitrary RESERVE- 3459 EXTERNAL-ADDRESS messages. At a certain point the NAT will run out 3460 of port numbers and the access for other users to the outside will be 3461 disabled. 3463 SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state 3464 creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, 3465 the NAT/FW NSLP implementation MUST prevent denial of service 3466 attacks involving the allocation of an arbitrary number of NAT 3467 bindings or the installation of a large number of packet filters. 3469 7.2.3 Man-in-the-Middle Attacks 3471 Figure 52 illustrates a possible man-in-the-middle attack using the 3472 RESERVE-EXTERNAL-ADDRESS (REA) message. This message travels from DR 3473 towards the public Internet. The message might not be intercepted 3474 because there are no NSIS aware middleboxes. 3476 Imagine such an NSIS signaling message is then intercepted by an 3477 adversary Mallory (M). M returns a faked RESPONSE message whereby 3478 the adversary pretends that a NAT binding was created. This NAT 3479 binding is returned with the RESPONSE message. Malory might insert 3480 it own IP address in the response, the IP address of a third party or 3481 the address of a black hole. In the first case, the DR thinks that 3482 the address of Mallory M is its public address and will inform the DS 3483 about it. As a consequence, the DS will send the data traffic to 3484 Mallory M. 3486 The data traffic from the DS to the DR will re-directed to Mallory M. 3488 M will be able to read, modify or block the data traffic (if the end- 3489 to-end communication itself does not experience protection). 3490 Eavesdropping and modification is only possible if the data traffic 3491 is itself unprotected. 3493 +-----+ +-----+ +-----+ 3494 | DS | | M | | DR | 3495 +-----+ +-----+ +-----+ 3496 | | | 3497 | | REA | 3498 | | <------------------ | 3499 | | | 3500 | | RESPONSE | 3501 | | ------------------> | 3502 | | | 3503 | data traffic | | 3504 |===============>| data traffic | 3505 | |====================>| 3507 Figure 52: MITM attack using the RESERVE-EXTERNAL-ADDRESS message 3509 SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW 3510 NSLP MUST be provided. To ensure that only legitimate nodes along 3511 the path act as NSIS entities the initiator MUST authorize the 3512 responder. In the example in Figure 52 the firewall FW must 3513 perform an authorization with the neighboring entities. 3515 7.2.4 Message Modification by non-NSIS on-path node 3517 An unauthorized on-path node along the path towards the destination 3518 could easily modify, inject or just drop an NSIS message. It could 3519 also hijack or disrupt the communication. 3521 SECURITY REQUIREMENT: Message integrity, replay protection and data 3522 origin authentication between neighboring NAT/FW NSLPs MUST be 3523 provided. 3525 7.2.5 Message Modification by malicious NSIS node 3527 Message modification by a NSIS node that became malicious is more 3528 serious. An adversary could easily create arbitrary pinholes or NAT 3529 bindings. For example: 3531 o NATs need to modify the source/destination of the data flow in the 3532 'create session' message. 3534 o Each middlebox along the path may change the requested lifetime in 3535 the CREATE message to fit their needs and/or local policy. 3537 SECURITY REQUIREMENT: None. Malicious NSIS NATs and Firewalls will 3538 not be addressed. 3540 7.2.6 Session Modification/Deletion 3542 The Session ID is included in signaling messages as a reference to 3543 the established state. If an adversary is able to obtain the Session 3544 Identifier for example by eavesdropping on signaling messages, it 3545 would be able to add the same Session Identifier to a new signaling 3546 message and effect some modifications. 3548 Consider the scenario described in Figure 53. Here an adversary 3549 pretends to be 'DS in mobility'. The signaling messages start from 3550 the DS and go through a series of routers towards the DR. We assume 3551 that an off-path adversary is connected to one of the routers along 3552 the old path (here Router 3). We also assume that the adversary 3553 knows the Session ID of the NSIS session initiated by the DS. 3554 Knowing the Session ID, the adversary now sends signaling messages 3555 towards the DR. When the signaling message reaches Router3 then 3556 existing state information can be modified or even deleted. The 3557 adversary can modify or delete the established reservation causing 3558 unexpected behavior for the legitimate user. The source of the 3559 problem is that the Router 3 (cross-over router) is unable to decide 3560 whether the new signaling message was initiated from the owner of the 3561 session. In this scenario, the adversary need not even be located in 3562 the DS-DR path. This problem and the solution approaches are 3563 described in more detail in [24]. 3565 Session ID(SID-x) 3566 +--------+ +--------+ 3567 +-------->--------+ Router +-------->+ DR | 3568 Session ID(SID-x)| | 4 | | | 3569 +---+----+ +--------+ +--------+ 3570 | Router | 3571 +------+ 3 +******* 3572 | +---+----+ * 3573 | * 3574 | Session ID(SID-x) * Session ID(SID-x) 3575 +---+----+ +---+----+ 3576 | Access | | Access | 3577 | Router | | Router | 3578 | 1 | | 2 | 3579 +---+----+ +---+----+ 3580 | * 3581 | Session ID(SID-x) * Session ID(SID-x) 3582 +----+------+ +----+------+ 3583 | DS | | Adversary | 3584 | | | | 3585 +-----------+ +-----------+ 3587 Figure 53: State Modification by off-path adversary 3589 As a summary, an off-path adversary's knowledge of Session-ID could 3590 cause session modification/deletion. 3592 SECURITY REQUIREMENT: The initiator MUST be able to demonstrate 3593 ownership of the session it wishes to modify. 3595 7.2.6.1 Misuse of mobility in NAT handling 3597 Another kind of session modification is related to mobility 3598 scenarios. NSIS allows end hosts to be mobile, it is possible that 3599 an NSIS node behind a NAT needs to update its NAT binding in case of 3600 address change. Whenever a host behind a NAT initiates a data 3601 transfer, it is assigned an external IP and port number. In typical 3602 mobility scenarios, the DR might also obtain a new address according 3603 to the topology and it should convey its new IP address to the NAT. 3604 The NAT is assumed to modify these NAT bindings based on the new IP 3605 address conveyed by the endhost. 3607 Public Private Address 3608 Internet space 3610 +----------+ +----------+ 3611 +----------| NAT |------------------|End host | 3612 | | | | 3613 +----------+ +----------+ 3614 | 3615 | +----------+ 3616 \--------------------|Malicious | 3617 |End host | 3618 +----------+ 3619 data traffic 3620 <======================== 3622 Figure 54: Misuse of mobility in NAT binding 3624 A NAT binding can be changed with the help of NSIS signaling. When a 3625 DR moves to a new location and obtains a new IP address, it sends an 3626 NSIS signaling message to modify the NAT binding. It would use the 3627 Session-ID and the new flow-id to update the state. The NAT updates 3628 the binding and the DR continues to receive the data traffic. 3629 Consider the scenario in Figure 54 where an the endhost(DR) and the 3630 adversary are behind a NAT. The adversary pretending that it is the 3631 end host could generate a spurious signaling message to update the 3632 state at the NAT. This could be done for these purposes: 3634 Connection hijacking by redirecting packets to the attacker as in 3635 Figure 55 3637 Third party flooding by redirecting packets to arbitrary hosts 3639 Service disruption by redirecting to non-existing hosts 3640 +----------+ +----------+ +----------+ 3641 | NAT | |End host | |Malicious | 3642 | | | | |End host | 3643 +----------+ +----------+ +----------+ 3644 | | | 3645 | Data Traffic | | 3646 |--------->----------| | 3647 | | Spurious | 3648 | | NAT binding update | 3649 |---------<----------+--------<------------| 3650 | | | 3651 | Data Traffic | | 3652 |--------->----------+-------->------------| 3653 | | | 3655 Figure 55: Connection Hijacking 3657 SECURITY REQUIREMENT: A NAT/FW signaling message MUST be 3658 authenticated, authorized, integrity protected and replay 3659 protected between neighboring NAT/FW NSLP nodes. 3661 7.2.7 Misuse of unreleased sessions 3663 Assume that DS (N1) initiates NSIS session with DR (N2) through a 3664 series of middleboxes as in Figure 56. When the DS is sending data 3665 to DR, it might happen that the DR disconnects from the network 3666 (crashes or moves out of the network in mobility scenarios). In such 3667 cases, it is possible that another node N3 (which recently entered 3668 the network protected by the same firewall) is assigned the same IP 3669 address that was previously allocated to N2. The DS could take 3670 advantage of the firewall policies installed already, if the refresh 3671 interval time is very high. The DS can flood the node (N3), which 3672 will consume the access network resources of the victim forcing it to 3673 pay for unwanted traffic as shown in Figure 57. Note that here we 3674 make the assumption that the data receiver has to pay for receiving 3675 data packets. 3677 Public Internet 3678 +--------------------------+ 3679 | | 3680 +-------+ CREATE +---+-----+ +-------+ | 3681 | |-------------->------| |---->---| | | 3682 | N1 |--------------<------| FW |----<---| N2 | | 3683 | | success RESPONSE | | | | | 3684 | |==============>======| |====>===| | | 3685 +-------+ Data Traffic +---+-----+ +-------+ | 3686 | | 3687 +--------------------------+ 3689 Figure 56: Before mobility 3691 Public Internet 3692 +--------------------------+ 3693 | | 3694 +-------+ +---+-----+ +-------+ | 3695 | | | | | | | 3696 | N1 |==============>======| FW |====>===| N3 | | 3697 | | Data Traffic | | | | | 3698 +-------+ +---+-----+ +-------+ | 3699 | | 3700 +--------------------------+ 3702 Figure 57: After mobility 3704 Also, this threat is valid for the other direction as well. The DS 3705 which is communicating with the DR may disconnect from the network 3706 and this IP address may be assigned to a new node that had recently 3707 entered the network. This new node could pretend to be the DS and 3708 send data traffic to the DR in conformance with the firewall policies 3709 and cause service disruption. 3711 SECURITY REQUIREMENT: Data origin authentication is needed to 3712 mitigate this threat. In order to allow firewalls to verify that 3713 a legitimate end host transmitted the data traffic data origin 3714 authentication is required. This is, however, outside the scope 3715 of this document. Hence, there are no security requirements 3716 imposed by this section which will be addressed by the NATFW NSLP. 3718 7.2.8 Data traffic injection 3720 In some environments, such as enterprise networks, it is still common 3721 to perform authorization for access to a service based on the source 3722 IP address of the service requester. There is no doubt that this by 3723 itself represents a security weakness. Hence by spoofing a 3724 connection, an attacker is able to reach the target machines, using 3725 the existing firewall rules. 3727 The adversary is able to inject its own data traffic in conformance 3728 with the firewall policies simultaneously along with the genuine DS. 3730 SECURITY REQUIREMENT: Since IP spoofing is a general limitation of 3731 non-cryptographic packet filters no security requirement needs to 3732 be created for the NAT/FW NSLP. Techniques such as ingress 3733 filtering (described below) and data origin authentication (such 3734 as provided with IPsec based VPNs) can help mitigate this threat. 3735 This issue is, however, outside the scope of this document. 3737 Ingress Filtering: Consider the scenario shown in Figure 58. In this 3738 scenario the DS is behind a router (R1) and a malicious node (M) is 3739 behind another router (R2). The DS communicates with the DR through 3740 a firewall (FW). The DS initiates NSIS signaling and installs 3741 firewall policies at FW. But the malicious node is also able to send 3742 data traffic using DS's source address. If R2 implements ingress 3743 filtering, these spoofed packets will be blocked. But this ingress 3744 filtering may not work in all scenarios. If both the DS and the 3745 malicious node are behind the same router, then the ingress filter 3746 will not be able to detect the spoofed packets as both the DS and the 3747 malicious node are in the same address range. 3749 +-----------------------------------+ 3750 | +------------------+ | 3751 | | +-------+ +---+---+ | 3752 | | | DS +>--+ R1 +->+ | 3753 | | | | | | | | 3754 | | +-------+ +---+---+ | | 3755 | | | | | 3756 | +------------------+ | +---+---+ +-------+ 3757 | | | | | | 3758 | +---+ FW +-->--| DR | 3759 | +------------------+ ****| |*****| | 3760 | | | * +---+---+ +-------+ 3761 | | +-------+ +---+---+ * | 3762 | | | M | | R2 | * | 3763 | | | |***| |*** | 3764 | | +-------+ +---+---+ | 3765 | +------------------+ | 3766 +-----------------------------------+ 3768 ---->---- = genuine data traffic 3769 ********* = spoofed data traffic 3771 Figure 58: Ingress filtering 3773 7.2.9 Eavesdropping and traffic analysis 3775 By collecting NSLP messages, an adversary is able to learn policy 3776 rules for packet filters and knows which ports are open. It can use 3777 this to inject its own data traffic due to the IP spoofing capability 3778 as already mentioned in Section 7.2.8. 3780 An adversary could learn authorization tokens included in CREATE 3781 messages and use them to launch replay-attacks or to create a session 3782 with its own address as source address. (cut-and-paste attack) 3784 As shown in Section 4.3 of [24] one possible solution for the session 3785 ownership problem is confidentiality protection of signaling messages 3787 SECURITY REQUIREMENT: The threat of eavesdropping itself does not 3788 mandate the usage of confidentiality protection since an adversary 3789 can also eavesdrop on data traffic. In the context of a 3790 particular security solutions (e.g., authorization tokens) it 3791 might be necessary to offer confidentiality protection. 3792 Confidentiality protection also needs to be offered to the refresh 3793 period. 3795 7.3 Security Framework for the NAT/Firewall NSLP 3797 Based on the identified threats a list of security requirements has 3798 been created. 3800 7.3.1 Security Protection between neighboring NATFW NSLP Nodes 3802 Based on the analyzed threats it is necessary to provide, between 3803 neighboring NATFW NSLP nodes, the following mechanism: provide 3805 o data origin authentication 3807 o replay protection 3809 o integrity protection and 3811 o optionally confidentiality protection 3813 To consider the aspect of authentication and key exchange the 3814 security mechanisms provided in [1] between neighboring nodes MUST be 3815 enabled when sending NATFW signaling messages. The proposed security 3816 mechanisms at GIMPS provide support for authentication and key 3817 exchange in addition to denial of service protection. Depending on 3818 the chosen protocol, support for flexible authentication protocols 3819 could be provided. The mandatory support for security, demands the 3820 usage of C-MODE for the delivery of data packets and the usage of 3821 D-MODE only to discover the next NATFW NSLP aware node along the 3822 path. 3824 7.3.2 Security Protection between non-neighboring NATFW NSLP Nodes 3826 Based on the security threats and the listed requirements it was 3827 noted that some scenarios also demand authentication and 3828 authorization of a NATFW signaling entity (including the initiator) 3829 towards a non-neighboring node. This mechanism mainly demands entity 3830 authentication. Additionally, security protection of certain 3831 payloads MAY be required between non-neighboring signaling entities 3832 and the Cryptographic Message Syntax (CMS) [18] SHOULD be used. CMS 3833 can be used 3835 o This might be, for example, useful to authenticate and authorize a 3836 user towards a middlebox and vice versa. 3838 o If objects have to be protected between certain non-neighboring 3839 NATFW NSLP nodes. 3841 Details about the identifiers, replay protection and the usage of a 3842 dynamic key management with the help of CMS is for further study. In 3843 some scenarios it is also required to use authorization token. Their 3844 purpose is to associate two different signaling protocols (e.g., SIP 3845 and NSIS) and their authorization decision. These tokens are 3846 obtained by non-NSIS protocols, such as SIP or as part of network 3847 access authentication. When a NAT or Firewall along the path 3848 receives the token it might be verified locally or passed to the AAA 3849 infrastructure. 3851 Examples of authorization tokens or assertions can be found in RFC 3852 3520 [30] and RFC 3521 [31]. More recent work on authorization token 3853 alike mechanisms is Security Assertion Markup Language (SAML). For 3854 details about SAML see [32], [33] and [34]. Figure 59 shows an 3855 example of this protocol interaction. An authorization token is 3856 provided by the SIP proxy, which acts as the assertion generating 3857 entity and gets delivered to the end host with proper authentication 3858 and authorization. When the NATFW signaling message is transmitted 3859 towards the network, the authorization token is attached to the 3860 signaling messages to refer to the previous authorization decision. 3861 The assertion verifying entity needs to process the token or it might 3862 be necessary to interact with the assertion granting entity using 3863 HTTP (or other protocols). As a result of a successful authorization 3864 by a NATFW NSLP node, the requested action is executed and later a 3865 RESPONSE message is generated. 3867 +----------------+ Trust Relationship +----------------+ 3868 | +------------+ |<.......................>| +------------+ | 3869 | | Protocol | | | | Assertion | | 3870 | | requesting | | HTTP, SIP Request | | Granting | | 3871 | | authz | |------------------------>| | Entity | | 3872 | | assertions | |<------------------------| +------------+ | 3873 | +------------+ | Artifact/Assertion | Entity Cecil | 3874 | ^ | +----------------+ 3875 | | | ^ ^| 3876 | | | . || HTTP, 3877 | | | Trust . || other 3878 | API Access | Relationship. || protocols 3879 | | | . || 3880 | | | . || 3881 | | | v |v 3882 | v | +----------------+ 3883 | +------------+ | | +------------+ | 3884 | | Protocol | | NSIS NATFW CREATE + | | Assertion | | 3885 | | using authz| | Assertion/Artifact | | Verifying | | 3886 | | assertion | | ----------------------- | | Entity | | 3887 | +------------+ | | +------------+ | 3888 | Entity Alice | <---------------------- | Entity Bob | 3889 +----------------+ RESPONSE +----------------+ 3891 Figure 59: Authorization Token Usage 3893 Threats against the usage of authorization tokens have been mentioned 3894 in [7] and also in Section 7.2. Hence, it is required to provide 3895 confidentiality protection to avoid allowing an eavesdropper to learn 3896 the token and to use it in another session (replay attack). The 3897 token itself also needs to be protected against tempering. 3899 7.3.3 End-to-End Security 3901 As part of the threat analysis we concluded that end-to-end security 3902 is not required and, if used, would be difficult to deploy. 3903 Furthermore, it might be difficult to use the suitable identifiers 3904 and to establish the necessary infrastructure for this propose. 3906 The only reasonable end-to-end security protection needed within NSIS 3907 seems to be a binding between an NSIS signaling session and 3908 application layer session. This aspect is, however, for further 3909 study. 3911 In order to solicit feedback from the IETF community on some hard 3912 security problems for path-coupled NATFW signaling a more detailed 3913 description in [21] is available. 3915 8. Open Issues 3917 The NATFW NSLP has a series of related documents discussing several 3918 other aspects of path-coupled NATFW signaling, including security 3919 [21], migration (i.e., traversal of NSIS unaware NATs) [14], intra- 3920 realm signaling [15], and inter-working with SIP [16]. Summaries of 3921 the outcomes from these documents may be added, depending on WG 3922 feedback, to a later version of this draft. 3924 A more detailed list of open issue can be found at: 3925 https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/index 3927 It is intended to add an overview figure for all NATFW NSLP building 3928 blocks into the next version of this memo. Figure 60 sketches the 3929 overview 3931 +------------------+ 3932 |Security Policies | 3933 | Server | 3934 +--------^---------+ 3935 | 3936 +--------------------------------|----------------------+ 3937 | +---------+ +-----------V----+ +-------+| 3938 | |Firewall |<-----> | |<------>| NAT || 3939 | |Engine | | Security policy| | Engine|| 3940 | +----^----+ | Table/Cache | +-^-----+| 3941 | | | ^ | | | 3942 | | +---- --------|--+ | | 3943 | +--|---------------------------|-------------|--+ | 3944 | | V NATFW NSLP V V | | 3945 | | | | 3946 | +-----------------------------------------------+ | 3947 | +--------------------------------------------------+| 3948 | | GIMPS || 3949 | | || 3950 | +--------------------------------------------------+| 3951 | +---------+ +-------+ +------+ +-------+ +------+| 3952 | | TCP | | UDP | | DCCP | | SCTP | | ICMP || 3953 | +---------+ +-------+ +------+ +-------+ +------+| 3954 | +-----------------------------+ +--------------------| 3955 | | IPv4 | | IPv6 | 3956 | +-----------------------------+ +--------------------| 3957 +-------------------------------------------------------+ 3959 Figure 60: NATFW NSLP Building Blocks 3961 9. Contributors 3963 We would like to thank the following individuals for their 3964 contributions to this document: 3966 o Marcus Brunner and Henning Schulzrinne for work on work on IETF 3967 drafts which lead us to start with this document, 3969 o Miquel Martin for his help on the initial version of this 3970 document, 3972 o Srinath Thiruvengadam and Ali Fessi work for their work on the 3973 NAT/firewall threats draft, 3975 o Elywn Davies for his help to make this document more readable, 3977 o and the NSIS working group. 3979 10. References 3981 10.1 Normative References 3983 [1] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 3984 Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06 (work 3985 in progress), May 2005. 3987 10.2 Informative References 3989 [2] Bradner, S., Mankin, A., and J. Schiller, "A Framework for 3990 Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in 3991 progress), June 2003. 3993 [3] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3994 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 3995 June 2005. 3997 [4] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 3998 April 2004. 4000 [5] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality- 4001 of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in 4002 progress), February 2005. 4004 [6] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 4005 Rayhan, "Middlebox communication architecture and framework", 4006 RFC 3303, August 2002. 4008 [7] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 4009 draft-ietf-nsis-threats-06 (work in progress), October 2004. 4011 [8] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 4012 (NAT) Terminology and Considerations", RFC 2663, August 1999. 4014 [9] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 4015 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 4017 [10] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 4018 RFC 3234, February 2002. 4020 [11] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, 4021 "DNS extensions to Network Address Translators (DNS_ALG)", 4022 RFC 2694, September 1999. 4024 [12] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 4025 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 4026 Specification", RFC 2205, September 1997. 4028 [13] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 4029 Herzog, S., and R. Hess, "Identity Representation for RSVP", 4030 RFC 3182, October 2001. 4032 [14] Aoun, C., Brunner, M., Stiemerling, M., Martin, M., and H. 4033 Tschofenig, "NAT/Firewall NSLP Migration Considerations", 4034 draft-aoun-nsis-nslp-natfw-migration-02 (work in progress), 4035 July 2004. 4037 [15] Aoun, C., "NATFirewall NSLP Intra-realm considerations", 4038 draft-aoun-nsis-nslp-natfw-intrarealm-01 (work in progress), 4039 July 2004. 4041 [16] Martin, M., "SIP NSIS Interactions for NAT/Firewall Traversal", 4042 draft-martin-nsis-nslp-natfw-sip-01 (work in progress), 4043 July 2004. 4045 [17] Tschofenig, H., "Extended QoS Authorization for the QoS NSLP", 4046 draft-tschofenig-nsis-qos-ext-authz-00 (work in progress), 4047 July 2004. 4049 [18] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 4050 August 2002. 4052 [19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 4053 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 4054 Session Initiation Protocol", RFC 3261, June 2002. 4056 [20] Ohba, Y., "Problem Statement and Usage Scenarios for PANA", 4057 draft-ietf-pana-usage-scenarios-06 (work in progress), 4058 April 2003. 4060 [21] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security 4061 Problems", 4062 DRAFT draft-tschofenig-nsis-natfw-security-problems-00.txt, 4063 July 2004. 4065 [22] Tschofenig, H., Buechli, M., Van den Bosch, S., and H. 4066 Schulzrinne, "NSIS Authentication, Authorization and Accounting 4067 Issues", March 2003. 4069 [23] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 4070 Traversal of VPN Gateways", 4071 DRAFT draft-ietf-mobileip-vpn-problem-statement-req-02.txt, 4072 April 2003. 4074 [24] Tschofenig, H., "Security Implications of the Session 4075 Identifier", draft-tschofenig-nsis-sid-00 (work in progress), 4076 June 2003. 4078 [25] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 4079 - Simple Traversal of User Datagram Protocol (UDP) Through 4080 Network Address Translators (NATs)", RFC 3489, March 2003. 4082 [26] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 4083 Lear, "Address Allocation for Private Internets", BCP 5, 4084 RFC 1918, February 1996. 4086 [27] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 4087 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and 4088 S. Waldbusser, "Terminology for Policy-Based Management", 4089 RFC 3198, November 2001. 4091 [28] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 4092 draft-rosenberg-midcom-turn-07 (work in progress), 4093 February 2005. 4095 [29] Tschofenig, H., "Using SAML for SIP", 4096 draft-tschofenig-sip-saml-02 (work in progress), December 2004. 4098 [30] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 4099 Authorization Policy Element", RFC 3520, April 2003. 4101 [31] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session 4102 Set-up with Media Authorization", RFC 3521, April 2003. 4104 [32] Maler, E., Philpott, R., and P. Mishra, "Bindings and Profiles 4105 for the OASIS Security Assertion Markup Language (SAML) V1.1", 4106 September 2003. 4108 [33] Maler, E., Philpott, R., and P. Mishra, "Assertions and 4109 Protocol for the OASIS Security Assertion Markup Language 4110 (SAML) V1.1", September 2003. 4112 [34] Maler, E. and J. Hughes, "Technical Overview of the OASIS 4113 Security Assertion Markup Language (SAML) V1.1", March 2004. 4115 [35] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as 4116 Firewall Signalling Protocol", Proceedings of the 6th IEEE 4117 Symposium on Computers and Communications, Hammamet, 4118 Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001. 4120 Authors' Addresses 4122 Martin Stiemerling 4123 Network Laboratories, NEC Europe Ltd. 4124 Kurfuersten-Anlage 36 4125 Heidelberg 69115 4126 Germany 4128 Phone: +49 (0) 6221 905 11 13 4129 Email: stiemerling@netlab.nec.de 4130 URI: http://www.stiemerling.org 4132 Hannes Tschofenig 4133 Siemens AG 4134 Otto-Hahn-Ring 6 4135 Munich 81739 4136 Germany 4138 Phone: 4139 Email: Hannes.Tschofenig@siemens.com 4140 URI: http://www.tschofenig.com 4142 Cedric Aoun 4143 Ecole Nationale Superieure des Telecommunications 4144 Paris 4145 France 4147 Email: cedric@caoun.net 4149 Appendix A. Firewall and NAT Resources 4151 The NATFW NSLP carries, in conjunction with the NTLP's Message 4152 Routing Information (MRI), the policy rules to be installed at NATFW 4153 peers. This policy rule is an abstraction with respect to the real 4154 policy rule to be installed at the respective firewall or NAT. It 4155 conveys the initiator's request and must be mapped to the possible 4156 configuration on the particular used NAT and/or firewall. For pure 4157 firewalls a filter rule must be created and for pure NATs a NAT 4158 binding must be created. In mixed firewall and NAT boxes, the policy 4159 rule must be mapped in filter rules and bindings observing the 4160 ordering of the firewall and NAT engine. Depending on the ordering, 4161 NAT before firewall or vice versa, the firewall rules must carry 4162 private or public IP addresses. However, the exact mapping depends 4163 on the implementation of the firewall or NAT which is different for 4164 each vendor. The remainder of this section gives thus only an 4165 abstract mapping of NATFW NSLP policy rules to firewall rules and NAT 4166 bindings, without going into the specifics on single configuration 4167 parameter possibilities. 4169 A policy rule consists out of the message routing information (MRI), 4170 carried in the NTLP, and information available in the NATFW NSLP. 4171 The information of the NSLP is stored in the extend flow information 4172 object and the message type, in particular the flow direction. 4173 Additional information, such as the external IP address and port 4174 number, stored in the NAT or firewall will be used as well. 4176 A.1 Wildcarding of Policy Rules 4178 The policy rule/MRI to be installed can be wildcarded to some degree. 4179 Wildcarding applies to IP address, transport layer port numbers, and 4180 the IP payload (or next header in IPv6). Processing of wildcarding 4181 splits into the NTLP and the NATFW NSLP layer. The processing at the 4182 NTLP layer is independent of the NSLP layer processing and per layer 4183 constraints apply. For wildcarding in the NTLP see Section 7.2 of 4184 [1]. 4186 Wildcarding at the NATFW NSLP level is always a node local policy 4187 decision. A signaling message carrying a wildcarded MRI (and thus 4188 policy rule) arriving at an NSLP node can be rejected if the local 4189 policy does not allow the request. For instance, a MRI with IP 4190 addresses set (not wildcarded), transport protocol TCP, and TCP port 4191 numbers completely wildcarded. Now the local policy allows only 4192 requests for TCP with all ports set and not wildcarded. The request 4193 is going to be rejected. 4195 A.2 Mapping to Firewall Rules 4197 EDITOR's NOTE: This section is to be done (CREATE, UCREATE). 4199 A.3 Mapping to NAT Bindings 4201 EDITOR's NOTE: This section is to be done (CREATE, REA). 4203 A.4 Mapping for combined NAT and Firewall 4205 EDITOR's NOTE: This section is to be done. 4207 A.5 NSLP Handling of Twice-NAT 4209 The dynamic configuration of twice-NATs requires application level 4210 support, as stated in Section 2.5. The NATFW NSLP cannot be used for 4211 configuring twice-NATs if application level support is needed. 4212 Assuming application level support performing the configuration of 4213 the twice-NAT and the NATFW NSLP being installed at this devices, the 4214 NATFW NSLP must be able to traverse it. The NSLP is probably able to 4215 traverse the twice-NAT, as any other data traffic, but the flow 4216 information stored in the NTLP's MRI will be invalidated through the 4217 translation of source and destination address. The NATFW NSLP 4218 implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP 4219 signaling messages as any other NATFW NSLP node does. For the given 4220 signaling flow, the NATFW NSLP node MUST look up the corresponding IP 4221 address translation and modify the NTLP/NSLP signaling accordingly. 4222 The modification results in an updated MRI with respect to the source 4223 and destination IP addresses. 4225 Appendix B. Problems and Challenges 4227 This section describes a number of problems that have to be addressed 4228 for NSIS NAT/Firewall. Issues presented here are subject to further 4229 discussions. These issues might be also of relevance to other NSLP 4230 protocols. 4232 B.1 Missing Network-to-Network Trust Relationship 4234 Peer-to-peer trust relationship, as shown in Figure 42, is a very 4235 convenient assumption that allows simplified signaling message 4236 processing. However, it might not always be applicable, especially 4237 between two arbitrary access networks (over a core network where 4238 signaling messages are not interpreted). Possibly peer-to-peer trust 4239 relationship does not exist because of the large number of networks 4240 and the unwillingness of administrators to have other network 4241 operators to create holes in their Firewalls without proper 4242 authorization. 4244 +----------------------+ +--------------------------+ 4245 | | | | 4246 | Network A | | Network B | 4247 | | | | 4248 | +---------+ Missing +---------+ | 4249 | +-///-+ Middle- | Trust | Middle- +-///-+ | 4250 | | | box 1 | Relation- | box 2 | | | 4251 | | +---------+ ship +---------+ | | 4252 | | | or | | | 4253 | | | Authorization| | | 4254 | | | | | | 4255 | | Trust | | Trust | | 4256 | | Relationship | | Relationship | | 4257 | | | | | | 4258 | | | | | | 4259 | | | | | | 4260 | +--+---+ | | +--+---+ | 4261 | | Host | | | | Host | | 4262 | | A | | | | B | | 4263 | +------+ | | +------+ | 4264 +----------------------+ +--------------------------+ 4266 Figure 61: Missing Network-to-Network Trust Relationship 4268 Figure 61 illustrates a problem whereby an external node is not 4269 allowed to manipulate (create, delete, query, etc.) packet filters at 4270 a Firewall. Opening pinholes is only allowed for internal nodes or 4271 with a certain authorization permission. Hence the solution 4272 alternatives in Section 3.3.2 focus on establishing the necessary 4273 trust with cooperation of internal nodes. 4275 B.2 Relationship with routing 4277 The data path is following the "normal" routes. The NAT/FW devices 4278 along the data path are those providing the service. In this case 4279 the service is something like "open a pinhole" or even more general 4280 "allow for connectivity between two communication partners". The 4281 benefit of using path-coupled signaling is that the NSIS NATFW NSLP 4282 does not need to determine what middleboxes or in what order the data 4283 flow will go through. 4285 Creating NAT bindings modifies the path of data packets between two 4286 end points. Without NATs involved, packets flow from endhost to 4287 endhost following the path given by the routing. With NATs involved, 4288 this end-to-end flow is not directly possible, because of separated 4289 address realms. Thus, data packets flow towards the external IP 4290 address at a NAT (external IP address may be a public IP address). 4291 Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with 4292 routing - instead they only follow the path of the data packets. 4294 B.3 Affected Parts of the Network 4296 NATs and Firewalls are usually located at the edge of the network, 4297 whereby other signaling applications affect all nodes along the path. 4298 One typical example is QoS signaling where all networks along the 4299 path must provide QoS in order to achieve true end-to-end QoS. In 4300 the NAT/Firewall case, only some of the domains/nodes are affected 4301 (typically access networks), whereas most parts of the networks and 4302 nodes are unaffected (e.g., the core network). 4304 This fact raises some questions. Should an NSIS NTLP node intercept 4305 every signaling message independently of the upper layer signaling 4306 application or should it be possible to make the discovery procedure 4307 more intelligent to skip nodes. These questions are also related to 4308 the question whether NSIS NAT/FW should be combined with other NSIS 4309 signaling applications. 4311 B.4 NSIS backward compatibility with NSIS unaware NAT and Firewalls 4313 Backward compatibility is a key for NSIS deployments, as such the 4314 NSIS protocol suite should be sufficiently robust to allow traversal 4315 of none NSIS aware routers (QoS gates, Firewalls, NATs, etc ). 4317 NSIS NATFW NSLP's backward compatibility issues are different than 4318 the NSIS QoS NSLP backward compatibility issues, where an NSIS 4319 unaware QoS gate will simply forward the QoS NSLP message. An NSIS 4320 unaware Firewall rejects NSIS messages, since Firewalls typically 4321 implement the policy "default to deny". 4323 The NSIS backward compatibility support on none NSIS aware Firewall 4324 would typically consist of configuring a static policy rule that 4325 allows the forwarding of the NSIS protocol messages (either protocol 4326 type if raw transport mode is used or transport port number in case a 4327 transport protocol is used). 4329 For NATs backward compatibility is more problematic since signaling 4330 messages are forwarded (at least in one direction), but with a 4331 changed IP address and changed port numbers. The content of the NSIS 4332 signaling message is, however, unchanged. This can lead to 4333 unexpected results, both due to embedded unchanged local scoped 4334 addresses and none NSIS aware Firewalls configured with specific 4335 policy rules allowing forwarding of the NSIS protocol (case of 4336 transport protocols are used for the NTLP). NSIS unaware NATs must 4337 be detected to maintain a well-known deterministic mode of operation 4338 for all the involved NSIS entities. Such a "legacy" NAT detection 4339 procedure can be done during the NSIS discover procedure itself. 4341 Based on experience it was discovered that routers unaware of the 4342 Router Alert IP option [RFC 2113] discarded packets, this is 4343 certainly a problem for NSIS signaling. 4345 B.5 Authentication and Authorization 4347 For both types of middleboxes, Firewall and NAT security is a strong 4348 requirement. Authentication and authorization means must be 4349 provided. 4351 For NATFW signaling applications it is partially not possible to do 4352 authentication and authorization based on IP addresses. Since NATs 4353 change IP addresses, such an address based authentication and 4354 authorization scheme would fail. 4356 B.6 Directional Properties 4358 There two directional properties that need to be addressed by the 4359 NATFW NSLP: 4361 o Directionality of the data 4363 o Directionality of NSLP signaling 4365 Both properties are relevant to NATFW NSLP aware NATs and Firewalls. 4367 With regards to NSLP signaling directionality: As stated in the 4368 previous sections, the authentication and authorization of NSLP 4369 signaling messages received from hosts within the same trust domain 4370 (typically from hosts located within the security perimeter delimited 4371 by Firewalls) is normally simpler than received messages sent by 4372 hosts located in different trust domains. 4374 The way NSIS signaling messages enters the NSIS entity of a Firewall 4375 (see Figure 2) might be important, because different policies might 4376 apply for authentication and admission control. 4378 Hosts deployed within the secured network perimeter delimited by a 4379 Firewall, are protected from hosts deployed outside the secured 4380 network perimeter, hence by nature the Firewall has more restrictions 4381 on flows triggered from hosts deployed outside the security 4382 perimeter. 4384 B.7 Addressing 4386 A more general problem of NATs is the addressing of the end-point. 4387 NSIS signaling message have to be addressed to the other end host to 4388 follow data packets subsequently sent. Therefore, a public IP 4389 address of the receiver has to be known prior to sending an NSIS 4390 message. When NSIS signaling messages contain IP addresses of the 4391 sender and the receiver in the signaling message payloads, then an 4392 NSIS entity must modify them. This is one of the cases, where a NSIS 4393 aware NATs is also helpful for other types of signaling applications 4394 e.g., QoS signaling. 4396 B.8 NTLP/NSLP NAT Support 4398 It must be possible for NSIS NATs along the path to change NTLP 4399 and/or NSLP message payloads, which carry IP address and port 4400 information. This functionality includes the support of providing 4401 mid-session and mid-path modification of these payloads. As a 4402 consequence these payloads must not be reordered, integrity protected 4403 and/or encrypted in a non peer-to-peer fashion (e.g., end-to-middle, 4404 end-to-end protection). Ideally these mutable payloads must be 4405 marked (e.g., a protected flag) to assist NATs in their effort of 4406 adjusting these payloads. 4408 B.9 Combining Middlebox and QoS signaling 4410 In many cases, middlebox and QoS signaling has to be combined at 4411 least logically. Hence, it was suggested to combine them into a 4412 single signaling message or to tie them together with the help of 4413 some sort of data connection identifier, later on referred as Session 4414 ID. This, however, has some disadvantages such as: 4416 - NAT/FW NSLP signaling affects a much small number of NSIS nodes 4417 along the path (for example compared to the QoS signaling). 4419 - NAT/FW signaling might show different signaling patterns (e.g., 4420 required end-to-middle communication). 4422 - The refresh interval is likely to be different. 4424 - The number of error cases increase as different signaling 4425 applications are combined into a single message. The combination of 4426 error cases has to be considered. 4428 B.10 Inability to know the scenario 4430 In Section 2 a number of different scenarios are presented. Data 4431 receiver and sender may be located behind zero, one, or more 4432 Firewalls and NATs. Depending on the scenario, different signaling 4433 approaches have to be taken. For instance, data receiver with no 4434 NAT and Firewall can receive any sort of data and signaling without 4435 any further action. Data receivers behind a NAT must first obtain a 4436 public IP address before any signaling can happen. The scenario 4437 might even change over time with moving networks, ad-hoc networks or 4438 with mobility. 4440 NSIS signaling must assume the worst case and cannot put 4441 responsibility to the user to know which scenario is currently 4442 applicable. As a result, it might be necessary to perform a 4443 "discovery" periodically such that the NSIS entity at the end host 4444 has enough information to decide which scenario is currently 4445 applicable. This additional messaging, which might not be necessary 4446 in all cases, requires additional performance, bandwidth and adds 4447 complexity. Additional, information by the user can provide 4448 information to assist this "discovery" process, but cannot replace 4449 it. 4451 Appendix C. Object ID allocation for testing 4453 TBD. 4455 Appendix D. Acknowledgments 4457 We would like to acknowledge: Vishal Sankhla and Joao Girao for their 4458 input to this draft; and Reinaldo Penno for his comments on the 4459 initial version of the document. Furthermore, we would like to 4460 especially thank Elwyn Davies for his valuable help and input. 4462 Intellectual Property Statement 4464 The IETF takes no position regarding the validity or scope of any 4465 Intellectual Property Rights or other rights that might be claimed to 4466 pertain to the implementation or use of the technology described in 4467 this document or the extent to which any license under such rights 4468 might or might not be available; nor does it represent that it has 4469 made any independent effort to identify any such rights. Information 4470 on the procedures with respect to rights in RFC documents can be 4471 found in BCP 78 and BCP 79. 4473 Copies of IPR disclosures made to the IETF Secretariat and any 4474 assurances of licenses to be made available, or the result of an 4475 attempt made to obtain a general license or permission for the use of 4476 such proprietary rights by implementers or users of this 4477 specification can be obtained from the IETF on-line IPR repository at 4478 http://www.ietf.org/ipr. 4480 The IETF invites any interested party to bring to its attention any 4481 copyrights, patents or patent applications, or other proprietary 4482 rights that may cover technology that may be required to implement 4483 this standard. Please address the information to the IETF at 4484 ietf-ipr@ietf.org. 4486 Disclaimer of Validity 4488 This document and the information contained herein are provided on an 4489 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4490 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4491 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4492 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4493 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4494 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4496 Copyright Statement 4498 Copyright (C) The Internet Society (2005). This document is subject 4499 to the rights, licenses and restrictions contained in BCP 78, and 4500 except as set forth therein, the authors retain all their rights. 4502 Acknowledgment 4504 Funding for the RFC Editor function is currently provided by the 4505 Internet Society.