idnits 2.17.1 draft-ietf-nsis-nslp-natfw-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 291 has weird spacing: '...ch some netwo...' == Line 949 has weird spacing: '...rvation mode ...' == Line 1691 has weird spacing: '...address used ...' == Line 1849 has weird spacing: '...ack has been ...' == Line 2125 has weird spacing: '...he data packe...' == (1 more instance...) == 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 public address or at the private address. If received at the public address a NF MAY generate an error message of type 'requested external address from outside'. If received at the private address, an IP address/port is reserved. In the case it is an edge-NAT, the NSLP message is not forwarded anymore and a response of type 'return external address' is generated. If it is not an edge-NAT, the NSLP message is forwarded further. * Firewall: Firewalls MUST not change their configuration upon a 'reserve external address' message. They simply MUST forward the message and MUST keep NTLP state. Firewalls that are configured as edge-Firewalls (XXX, do definition!) MAY return an error of type 'no NAT here'. * Combined NAT and Firewall: Processing at combined Firewall and NAT middleboxes is the same as in the NAT case. o NSLP receiver: This type of message should never be received by any NR and it SHOULD be discarded silently. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 21, 2004) is 7279 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: 'RFC3198' on line 259 -- Looks like a reference, but probably isn't: 'RFC 2113' on line 2175 == Unused Reference: '5' is defined on line 1904, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1921, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1930, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1942, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1966, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1974, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 1995, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 1999, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-fw (ref. '1') ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-req (ref. '2') == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '3') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '4') ** Obsolete normative reference: RFC 3330 (ref. '5') (Obsoleted by RFC 5735) == Outdated reference: A later version (-06) exists of draft-ietf-nsis-threats-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-threats (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. '7') -- Duplicate reference: RFC2663, mentioned in '9', was also mentioned in '8'. -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '11') (Obsoleted by RFC 4966) == Outdated reference: A later version (-02) exists of draft-aoun-nsis-nslp-natfw-migration-01 == Outdated reference: A later version (-01) exists of draft-aoun-nsis-nslp-natfw-intrarealm-00 == Outdated reference: A later version (-01) exists of draft-martin-nsis-nslp-natfw-sip-00 -- No information found for draft-martin-nsis-nslp-natfw-security - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '21') (Obsoleted by RFC 3852) == Outdated reference: A later version (-04) exists of draft-manner-lrsvp-00 == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-vpn-problem-statement-req-02 == Outdated reference: A later version (-03) exists of draft-ford-midcom-p2p-02 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '32') (Obsoleted by RFC 5389) Summary: 9 errors (**), 0 flaws (~~), 27 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group M. Stiemerling 3 Internet-Draft NEC 4 Expires: November 19, 2004 H. Tschofenig 5 Siemens 6 M. Martin 7 NEC 8 C. Aoun 9 Nortel Networks 10 May 21, 2004 12 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 13 draft-ietf-nsis-nslp-natfw-02 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 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 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 19, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 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 Next Steps in Signaling (NSIS) working group. This is one of two 52 NSIS Signaling Layer Protocols (NSLPs) the working group will address 53 during its work. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Terminology and Abbreviations . . . . . . . . . . . . . . 5 59 1.2 Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.3 General Scenario for NATFW Traversal . . . . . . . . . . . 8 62 2. Network Environment . . . . . . . . . . . . . . . . . . . . . 10 63 2.1 Network Scenarios for Protocol Functionality . . . . . . . 10 64 2.1.1 Firewall traversal . . . . . . . . . . . . . . . . . . 10 65 2.1.2 NAT with two private Networks . . . . . . . . . . . . 11 66 2.1.3 NAT with private network on sender side . . . . . . . 12 67 2.1.4 NAT with private network on receiver side . . . . . . 12 68 2.1.5 Both End Hosts behind twice-NATs . . . . . . . . . . . 13 69 2.1.6 Both End Hosts behind same NAT . . . . . . . . . . . . 14 70 2.1.7 IPv4/v6 NAT with two private networks . . . . . . . . 15 71 2.1.8 Multihomed Network with NAT . . . . . . . . . . . . . 16 72 2.2 Trust Relationship and Authorization . . . . . . . . . . . 17 73 2.2.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . 17 74 2.2.2 Intra-Domain Trust Relationship . . . . . . . . . . . 18 75 2.2.3 End-to-Middle Trust Relationship . . . . . . . . . . . 19 77 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 21 78 3.1 Basic protocol overview . . . . . . . . . . . . . . . . . 21 79 3.2 Protocol Operations . . . . . . . . . . . . . . . . . . . 23 80 3.2.1 Creating Sessions . . . . . . . . . . . . . . . . . . 23 81 3.2.2 Reserving External Addresses . . . . . . . . . . . . . 25 82 3.2.3 Reserving External Addresses and Create Session . . . 28 83 3.2.4 Prolonging Sessions . . . . . . . . . . . . . . . . . 28 84 3.2.5 Deleting Sessions . . . . . . . . . . . . . . . . . . 29 85 3.2.6 Authorization . . . . . . . . . . . . . . . . . . . . 30 86 3.2.7 Calculation of Lifetimes . . . . . . . . . . . . . . . 30 87 3.2.8 Middlebox Resource . . . . . . . . . . . . . . . . . . 31 88 3.2.9 De-Multiplexing at NATs . . . . . . . . . . . . . . . 31 89 3.2.10 Selecting Destination IP addresses for REA . . . . . . 32 90 3.3 NATFW NSLP Messages Components . . . . . . . . . . . . . . 33 91 3.3.1 NSLP Header . . . . . . . . . . . . . . . . . . . . . 33 92 3.3.2 NSLP message types . . . . . . . . . . . . . . . . . . 34 93 3.3.3 NSLP Objects . . . . . . . . . . . . . . . . . . . . . 34 94 3.3.3.1 Session ID Object . . . . . . . . . . . . . . . . 35 95 3.3.3.2 Session Lifetime Object . . . . . . . . . . . . . 35 96 3.3.3.3 External Address Object . . . . . . . . . . . . . 36 97 3.3.3.4 Extended Flow Information Object . . . . . . . . . 37 98 3.3.3.5 Error Object . . . . . . . . . . . . . . . . . . . 37 99 3.4 Message Formats . . . . . . . . . . . . . . . . . . . . . 38 100 3.4.1 Policy Rules . . . . . . . . . . . . . . . . . . . . . 38 101 3.4.2 Create Session (CRS) . . . . . . . . . . . . . . . . . 39 102 3.4.3 Reserve External Address (REA) . . . . . . . . . . . . 39 103 3.4.4 Reserve-Create (REC) . . . . . . . . . . . . . . . . . 39 104 3.4.5 Prolong Session (PLS) . . . . . . . . . . . . . . . . 39 105 3.4.6 Delete Session (DLS) . . . . . . . . . . . . . . . . . 40 106 3.4.7 Path Succeeded (PS) . . . . . . . . . . . . . . . . . 40 107 3.4.8 Path Deleted (PD) . . . . . . . . . . . . . . . . . . 40 108 3.4.9 Return External Address (RA) . . . . . . . . . . . . . 40 109 3.4.10 Error Response (ER) . . . . . . . . . . . . . . . . . 41 111 4. NSIS NAT and Firewall transitions issues . . . . . . . . . . . 42 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 43 115 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45 117 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 119 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 120 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 47 121 8.2 Informative References . . . . . . . . . . . . . . . . . . . 47 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49 125 A. Problems and Challenges . . . . . . . . . . . . . . . . . . . 51 126 A.1 Missing Network-to-Network Trust Relationship . . . . . . 51 127 A.2 Relationship with routing . . . . . . . . . . . . . . . . 52 128 A.3 Affected Parts of the Network . . . . . . . . . . . . . . 53 129 A.4 NSIS backward compatibility with NSIS unaware NAT and 130 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 53 131 A.5 Authentication and Authorization . . . . . . . . . . . . . 54 132 A.6 Directional Properties . . . . . . . . . . . . . . . . . . 54 133 A.7 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 54 134 A.8 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 55 135 A.9 Combining Middlebox and QoS signaling . . . . . . . . . . 55 136 A.10 Inability to know the scenario . . . . . . . . . . . . . . 55 138 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 140 Intellectual Property and Copyright Statements . . . . . . . . 58 142 1. Introduction 144 Firewalls and Network Address Translators (NAT) have been both used 145 throughout the Internet for many years and they will be present in 146 future. Using Firewalls brings security to networks and in times of 147 IPv4 address depletion NATs virtually extend IP address space. In 148 general, both types may be obstacles to many applications, since they 149 only allow specific applications to traverse them (i.e., HTTP traffic 150 or in general client/server applications). Other applications, for 151 instance, IP telephony or any other peer-to-peer application, with 152 more dynamic properties suffer from Firewalls and NATs so that they 153 do not work at all. Therefore, many applications cannot traverse 154 Firewall or NATs. 156 Several solutions to enable any application to traverse those boxes 157 have been proposed and are currently used. Typically, application 158 level gateways (ALG) have been integrated and so configuring 159 Firewalls and NATs dynamically. Another approach is middlebox 160 communication (MIDCOM, currently under standardization at the IETF). 161 In this approach Firewall and NAT external ALGs configure them via 162 the MIDCOM protocol [7]. Several other work around solutions are 163 available as well, see STUN [32] and [31]. However, all of these 164 approaches introduce other problems that are hard to solve; like 165 dependencies on certain NAT implementations or dependency on 166 topology. 168 NAT and Firewall (NATFW) signaling share a property with Quality of 169 Service (QoS) signaling, i.e., in both cases it is required to reach 170 any device on the data path that is involved in QoS or NATFW 171 treatment of data packets. For both, NATFW and QoS, signaling 172 travels path-coupled, meaning that the signaling messages follow 173 exactly the same path as the data packets do. RSVP [14] is an 174 example for a QoS signaling protocol. 176 This memo defines a path-coupled signaling protocol in the framework 177 of NSIS for NAT and Firewall configuration, called the NATFW NSIS 178 Signaling Layer Protocol (NSLP). The general framework of NSIS is 179 outlined in [1] and introduces the split between NSIS transport layer 180 and NSIS signaling layer. The transport of NSLP messages is handled 181 by NSIS Network Transport Layer Protocol (NTLP, see [3]) and takes 182 care about NSLP message transport. The signaling logic for QoS and 183 NATFW signaling is implemented in the different NSLPs. The QoS NSLP 184 is defined in [4], furthermore the general requirements for NSIS are 185 defined in [2]. 187 There is a series of related documents to NATFW NSLP discussing 188 several other aspects of path-coupled NATFW signaling, including 189 security [20], migration [17], intrarealm signaling [18], and 190 inter-working with SIP [19]. 192 The NATFW NSLP allows requesting the configuration of NATs and/or 193 Firewalls along the data path to enable data flows to traverse these 194 devices without being obstructed. A simplified example: A source 195 host sends a NATFW NSLP signaling message towards its data 196 destination. This message follows the data path and every NATFW NSLP 197 NAT/Firewall along the data path intercepts these messages, processes 198 it and configures itself accordingly. Afterwards, the actual data 199 flow can traverse every configured Firewall/NAT. 201 NATFW NSLP runs in two different modes, one is the path directed mode 202 where Firewalls and NATs are configured along the data path as 203 pointed out in the above example. The second one is the reserve 204 mode, where NATs are detected by the NSLP/NTLP within the network and 205 a public reachable IP address and port number are reserved. This 206 reserve mode enables hosts located behind NATs to receive data 207 originated in the public Internet on the reverse data path. Both 208 modes create NATFW NSLP and NTLP state in the network. The NSLP 209 state is maintained via a soft-state mechanism. State includes not 210 only signaling state, but as well as NAT bindings and Firewall rules. 211 This state is maintained via a lifetime and must be kept alive via a 212 lifetime extension mechanism if needed. Two signaling messages are 213 used for deleting state explicitly and extending state's lifetime. 214 In general, all NATFW NSLP signaling messages are exchanged 215 end-to-end. 217 Traversal of non NATFW NSLPs or the NTLP is out of scope of this 218 document. Furthermore, only Firewalls and NATs are considered in 219 this document, any other device, for instance IPSec security gateway, 220 is out of scope. 222 Section 2 describes the network environment for NATFW NSLP signaling 223 and highlights the required trust relationship/ authorization. 224 Section 3 defines the NATFW signaling protocol with its message 225 components, message formats, and protocol operations. The remaining 226 document refers in Section 4 to transition issues and security 227 considerations are handled in [20]. Currently unsolved problems and 228 challenges are listed and discussed in Appendix A. Please note that 229 readers familiar with possible locations of Firewalls and NAT in 230 networks can safely skip Section 2. 232 1.1 Terminology and Abbreviations 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 236 document are to be interpreted as described in RFC 2119. 238 This document uses terms defined in [2]. Furthermore, these 239 following terms are used: 240 o NSIS NAT Forwarding State: The term "NSIS NAT Forwarding State" in 241 this context refers to a state used to forward the NSIS signaling 242 message beyond the targeted destination address; that state is 243 typically used when the NSIS Responder address is not known 244 o Sender-/Receiver Initiated Signaling 245 Sender-initiated: NAT bindings and Firewall rules are created 246 immediately when the "path" message hits the NSIS nodes. With 247 "path" message we refer to the signaling message traveling from 248 the data sender towards the data receiver. 249 Receiver-initiated: NAT bindings and Firewall rules are created 250 when the "reserve" message returns from the other end. With 251 "reserve" message we refer to a signaling message on the 252 reverse path, this means from the receiver to the sender (i.e. 253 backwards routed). 254 Note that these definitions have nothing to do with number of 255 roundtrips, who performs authorization etc. 256 o Policy rule: In general, a policy rule is "a basic building block 257 of a policy-based system. It is the binding of a set of actions 258 to a set of conditions - where the conditions are evaluated to 259 determine whether the actions are performed." [RFC3198]. In the 260 context of NSIS NATFW NSLP the condition is a specification of a 261 set of packets to which rules are applied. The set of actions 262 always contains just a single element per rule, and is limited to 263 either action "reserved" or action "enable". 264 o Firewall: A packet filtering device that matches packet against a 265 set of policy rules and applies the actions. In the context of 266 NSIS NATFW NSLP we refer to this device as Firewall. 267 o Network Address Translator: Network Address Translation is a 268 method by which IP addresses are mapped from one realm to another, 269 in an attempt to provide transparent routing to hosts (see [9]). 270 Network Address Translators are devices that perform this method. 271 o Middlebox: from [12]: "A middlebox is defined as any intermediate 272 device performing functions other than the normal, standard 273 functions of an IP router on the datagram path between a source 274 host and a destination host". The term middlebox in context of 275 this document and in NSIS refers to Firewalls and NATs only. 276 Other types of middlebox are currently outside the scope. 277 o Security Gateway: IPsec based gateways. 278 o NSIS Initiator (NI): the signaling entity, which makes the 279 resource request, usually as a result of user application request. 280 o NSIS Responder (NR): the signaling entity , which acts as the 281 final destination for the signaling and can optionally interact 282 with applications as well. 283 o NSIS Forwarder (NF): the signaling entity between an NI and NR 284 which propagates NSIS signaling further through the network. 286 o Receiver (DR or R): the node in the network, which is receiving 287 the data packets of a flow. 288 o Sender (DS or S): the node in the network, which is sending the 289 data packets of a flow. 290 o NATFW NSLP session: Application layer flow of information for 291 which some network control state information is to be manipulated 292 or monitored (as defined in [1]). The control state for NATFW 293 NSLP is NSLP state and associated policy rules at the middlebox. 294 o NSIS peer or peer: NSIS node with which a NSIS adjacency has been 295 created as defined in [3]. 296 o Edge NAT: By edge NAT we refer to the NAT device, which is 297 reachable from outside and has a globally routable IP address. 298 o Public Network: Definition according to [8] is "A Global or Public 299 Network is an address realm with unique network addresses assigned 300 by Internet Assigned Numbers Authority (IANA) or an equivalent 301 address registry. This network is also referred as External 302 network during NAT discussions." 303 o Private/Local Network: Definition according to [8] is " A private 304 network is an address realm independent of external network 305 addresses. Private network may also be referred alternately as 306 Local Network. Transparent routing between hosts in private realm 307 and external realm is facilitated by a NAT router." IP address 308 space allocation for private networks is recommended in [33] 309 o Public/Global IP address: An IP address located in the public 310 network. 311 o Private/Local IP address: An IP address located in the private 312 network. 314 1.2 Middleboxes 316 The term middlebox raises different expectations about functionality 317 provided by such a device. Middleboxes in the scope of this memo are 318 Firewalls that filter data packets against their set of filter rules 319 and NATs that translate addresses from one address realm to another 320 address realm. Other types of middleboxes, for instance QoS traffic 321 shapers and security gateways, are out of scope. 323 The term NAT used in this document is placeholder for a range of 324 different NAT flavors. We consider those types of NATs: 325 o traditional NAT (basic NAT and NAPT) 326 o Bi-directional NAT 327 o Twice-NAT 328 o Multihomed NAT 329 For a detailed discussion about each NAT type please see [8]. 331 Both types of middleboxes use policy rules for decision on data 332 packet treatment. Policy rules consist of a 5-tuple and an 333 associated action. Data packets matching this 5-tuple experience the 334 policy rule action. A 5-tuple consists of: 335 o Source IP address and port number 336 o Destination IP address and port number 337 o Transport protocol 338 Actions for Firewalls are usually: 339 o Allow: forward data packet 340 o Deny: block data packet and discard it 341 o Other actions like logging, diverting, etc 342 Actions for NATs are (amongst many others): 343 o Change source IP address and port number to a global routeable IP 344 address and port number. 345 o Change destination IP address and port number to a private IP 346 address and port number. 348 The exact implementation of policy rules and mapping to Firewall rule 349 sets and NAT bindings or sessions at the middlebox is an 350 implementation issue and thus out of scope of this document. 352 Some devices entitled as Firewalls only accept traffic after 353 cryptographic verification (i.e. IPsec protected data traffic). 354 Particularly for network access scenarios either link layer or 355 network layer data protection is common. Hence we do not address 356 these types of devices (referred as security gateways) since per-flow 357 signaling is rather uncommon in this environment. For a discussion 358 of network access authentication and associated scenarios the reader 359 is referred to the PANA working group (see [26]). 361 Discovering security gateways, which was also mentioned as an 362 application for NSIS signaling, for the purpose of executing an IKE 363 to create an IPsec SA, is already solved without requiring NSIS. 365 In mobility scenarios an often experienced problem is the traversal 366 of a security gateway at the edge of the corporate network. Network 367 administrators often rely on the policy that only authenticated data 368 traffic is allowed to enter the network. A problem statement for the 369 traversal of these security gateways in the context of Mobile IP can 370 be found at [25]). 372 Other proposals for path-coupled NAT and Firewall traversal like RSVP 373 and CASP are described in [27] and [28]. 375 1.3 General Scenario for NATFW Traversal 377 The purpose of NSIS NATFW signaling is to enable any communication 378 between endpoints across networks even in presence of middleboxes. 379 It is expected that those middleboxes be configured in such a way 380 that NSIS NATFW signaling messages itself are allowed to traverse 381 them. NSIS NATFW NSLP signaling is used to install such policy rules 382 in all middleboxes along the data path. Firewalls are configured to 383 forward data packets matching the policy rule provided by the NSLP 384 signaling. NATs are configured to translate data packets matching 385 the policy rule provided by the NSLP signaling. 387 The basic high-level picture of NSIS usage is that endhosts are 388 located behind middleboxes (NAT/FW in Figure 1). Applications 389 located at these endhosts try to establish communication between them 390 and use NSIS NATFW NSLP signaling to establish policy rules on a data 391 path, which allows the said data to travel from the sender to the 392 receiver unobstructed. The applications can somehow trigger 393 middlebox traversal (e.g. via an API call) at the NSIS entity at the 394 local host. 396 Application Application Server (0, 1, or more) Application 398 +----+ +----+ +----+ 399 | +------------------------+ +------------------------+ | 400 +-+--+ +----+ +-+--+ 401 | | 402 | NSIS Entities NSIS Entities | 403 +-+--+ +----+ +-----+ +-+--+ 404 | +--------+ +----------------------------+ +-----+ | 405 +-+--+ +-+--+ +--+--+ +-+--+ 406 | | ------ | | 407 | | //// \\\\\ | | 408 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 409 | | | | | Internet | | | | | 410 | +--------+ +-----+ +----+ +-----+ | 411 +----+ +----+ |\ | +----+ +----+ 412 \\\\ ///// 413 sender NAT/FW (1+) ------ NATFW (1+) receiver 415 Figure 1: Generic View on NSIS in a NAT / Firewall case 417 For running NATFW signaling it is necessary that each Firewall and 418 each NAT involved in the signaling communication runs an NSIS NATFW 419 entity. There might be several NATs and FWs in various possible 420 combinations on a path between two hosts. The reader is referred to 421 Section 2.1 where different scenarios are presented. 423 2. Network Environment 425 2.1 Network Scenarios for Protocol Functionality 427 This section introduces several scenarios for middleboxes in the 428 Internet. Middleboxes are located at different locations, i.e. at 429 Enterprise network borders, within enterprise networks, mobile phone 430 network gateways, etc. In general, middleboxes are placed more 431 towards the edge of networks and less in network cores. Those 432 middleboxes are not only either Firewall or NAT and any other type of 433 combination is possible. Thus, combined Firewall and NATs are 434 available. 436 NSIS initiators (NI) are sending NSIS NATFW NSLP signaling messages 437 via the regular data path to the NSIS responder (NR). On the data 438 path NATFW NSLP signaling messages reach different NSIS peers that 439 have the NATFW NSLP implemented. Each NATFW NSLP node processes the 440 signaling messages according to Section 3 and installs, if necessary, 441 policy rules for subsequent data packets. 443 Each following section introduces a different scenario for a 444 different set of middleboxes and their ordering within the topology. 445 It is assumed that each middlebox implements the NSIS NATFW NSLP 446 signaling protocol. 448 2.1.1 Firewall traversal 450 This section describes a scenario with Firewalls only and NATs are 451 not involved. Both end hosts are behind a Firewall that is connected 452 via the public Internet. Figure 2 shows the topology. The part 453 labeled "public" is the Internet connection both Firewalls. 455 +----+ //----\\ +----+ 456 NI -----| FW |---| |------| FW |--- NR 457 +----+ \\----// +----+ 459 private public private 461 FW: Firewall 462 NI: NSIS Initiator 463 NR: NSIS Responder 465 Figure 2: Firewall Traversal Scenario 467 Each Firewall on-path must provide traversal service for NATFW NSLP 468 in order to permit the NSIS message to reach the other end host. All 469 Firewalls process NSIS signaling and establish appropriate policy 470 rules, so that the required data packet flow can traverse them. 472 2.1.2 NAT with two private Networks 474 Figure 3 shows a scenario with NATs at both ends of the network. 475 Therefore, each application instance, NSIS initiator and NSIS 476 responder, are behind NATs. The outermost NAT at each side is 477 connected to the public Internet. The NATs are labeled as MB (for 478 middlebox), since those devices implement at least NAT-only, but can 479 implement Firewalling as well. 481 Only two middleboxes MB are shown in Figure 3 at each side, but in 482 general more than one MB on each side must be considered. 484 +----+ +----+ //----\\ +----+ +----+ 485 NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR 486 +----+ +----+ \\----// +----+ +----+ 488 private public private 490 MB: Middlebox 491 NI: NSIS Initiator 492 NR: NSIS Responder 494 Figure 3: NAT with two private networks Scenario 496 Signaling traffic from NI to NR has to traverse all four middleboxes 497 on the path and all four middleboxes must be configured properly to 498 allow NSIS signaling to traverse. The NATFW signaling must configure 499 all middleboxes and consider any address translation in further 500 signaling. The sender (NI) has to know the IP address of the 501 receiver (NR) in advance, otherwise he cannot send a single NSIS 502 signaling message towards the responder. Note that this IP address 503 is not the private IP address of the responder. Instead a NAT 504 binding (including a public IP address) has to be obtained from the 505 NAT that subsequently allows packets hitting the NAT to be forwarded 506 to the receiver within the private address realm. This generally 507 requires further support from an application layer protocol for the 508 purpose of discovering and exchanging information. The receiver 509 might have a number of ways to learn its public IP address and port 510 number and might need to signal this information to the sender using 511 the application level signaling protocol. 513 2.1.3 NAT with private network on sender side 515 This scenario shows an application instance at the sending node that 516 is behind one or more NATs (shown as MB). The receiver is located in 517 the public Internet. 519 +----+ +----+ //----\\ 520 NI --| MB |-----| MB |---| |--- NR 521 +----+ +----+ \\----// 523 private public 525 MB: Middlebox 526 NI: NSIS Initiator 527 NR: NSIS Responder 529 Figure 4: NAT with private network on sender scenario 531 The traffic from NI to NR has to traverse only middleboxes on the 532 sender's side. The receiver has a public IP address. The NI sends 533 its signaling message directly to the address of the NSIS responder. 534 Middleboxes along the path intercept the signaling messages and 535 configure the policy rules accordingly. 537 Note that the data sender does not necessarily know whether the 538 receiver is behind a NAT or not, hence, it is the receiving side that 539 has to detect whether itself is behind a NAT or not. As described in 540 Section 3.2.2 NSIS can also provide help for this procedure. 542 2.1.4 NAT with private network on receiver side 544 The application instance receiving data is behind one or more NATs. 546 //----\\ +----+ +----+ 547 NI ---| |---| MB |-----| MB |--- NR 548 \\----// +----+ +----+ 550 public private 552 MB: Middlebox 553 NI: NSIS Initiator 554 NR: NSIS Responder 556 Figure 5: NAT with private network on receiver Scenario 558 Initially, the NSIS responder must determine its public reachable IP 559 address at the external middlebox and notify the NSIS initiator about 560 this address. One possibility is that an application level protocol 561 is used, meaning that the public IP address is signaled via this 562 protocol to the NI. Afterwards the NI can start its signaling 563 towards the NR and so establishing the path via the both middleboxes 564 MB. 566 This scenario describes the use case for the reserve mode of the 567 NATFW NSLP. 569 2.1.5 Both End Hosts behind twice-NATs 571 This is a special case, where the main problem is to detect that both 572 nodes are logically within the same address space, also behind a 573 twice-NAT (see [8] for discussion about twice-NAT functionality). 575 Sender and receiver are both within a private address realm and 576 potentially have overlapping IP addresses. Figure 6 shows the 577 ordering of NATs. This is a common configuration in several 578 networks, particularly after the merging of companies that have used 579 the same address space, thus having overlapping addresses in many 580 cases. 582 public 583 +----+ +----+ //----\\ 584 NI --| MB |--+--| MB |---| | 585 +----+ | +----+ \\----// 586 | 587 | +----+ 588 +--| MB |------------ NR 589 +----+ 591 private 593 MB: Middlebox 594 NI: NSIS Initiator 595 NR: NSIS Responder 597 Figure 6: NAT to public, sender and receiver behind twice-NAT 598 Scenario 600 The middleboxes shown in Figure 6 are twice-NATs, i.e. they map IP 601 addresses and port numbers on both sides, at private and public 602 interfaces. 604 This scenario requires assistance of application level entities, like 605 DNS server. Those application level gateways must handle request 606 that are based on symbolic names and configure the middleboxes so 607 that data packets are correctly forwarded from NI to NR. The 608 configuration of those middleboxes may require other middlebox 609 communication protocols, like MIDCOM [7]. NSIS signaling is not 610 required in the twice-NAT only case, since the middleboxes of type 611 twice-NAT are configured by other means. Nevertheless, NSIS 612 signaling might by useful when there are Firewalls on path. In this 613 case NSIS will not configure any policy rule at twice-NATs, but will 614 configure policy rules at the intermediate Firewalls. The NSIS 615 signaling protocol must be at least robust enough to survive this 616 scenario. 618 2.1.6 Both End Hosts behind same NAT 620 When NSIS initiator and NSIS responder are behind the same NAT (thus 621 being in the same address realm, see Figure 7), they are most likely 622 not aware of this fact. As in Section 2.1.4 the NSIS responder must 623 determine its public IP address in advance and transfer it to the 624 NSIS initiator. Afterwards, the NSIS initiator can start sending the 625 signaling messages to the responder's public IP address. During this 626 process, a public IP address will be allocated for the NSIS initiator 627 at the same middlebox as for the responder. Now, the NSIS signaling 628 and the subsequent data packets will traverse the NAT two times: from 629 initiator to public IP address of responder (first time) and from 630 public IP address of responder to responder (second time). This is 631 the worst case, both sender and receiver obtain a public IP address 632 at the NAT and the communication path is not optimal anymore. 634 NI public 635 \ +----+ //----\\ 636 +-| MB |----| | 637 / +----+ \\----// 638 NR 639 private 641 MB: Middlebox 642 NI: NSIS Initiator 643 NR: NSIS Responder 645 Figure 7: NAT to public, both host behind same NAT 647 NSIS NATFW signaling protocol should support mechanisms to detect 648 such a scenario. The signaling should directly by exchanged between 649 NI and NR without involving the middlebox. 651 2.1.7 IPv4/v6 NAT with two private networks 653 This scenario combines the usage case mentioned in Section 2.1.2 654 with the IPv4 to IPv6 transition scenario, i.e. using Network 655 Address and Protocol Translators (NAT-PT, [11]). 657 The difference to the other scenarios is the use of IPv6 to IPv4 (and 658 vice versa) address and protocol translation. Additionally, the base 659 NTLP must take care of this case for its own functionality of 660 forwarding messages between NSIS peers. 662 +----+ +----+ //---\\ +----+ //---\\ +----+ +----+ 663 NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR 664 +----+ +----+ \\---// +----+ \\---// +----+ +----+ 666 private public public private 667 IPv4 IPv6 669 MB: Middlebox 670 NI: NSIS Initiator 671 NR: NSIS Responder 673 Figure 8: IPv4/v6 NAT with two private networks 675 This scenario needs the same type of application level support as 676 described in Section 2.1.5 and so those issues of twice-NATs apply 677 here as well. 679 2.1.8 Multihomed Network with NAT 681 The previous chapters sketched network topologies where NAT and 682 Firewalls are ordered sequentially on the path. This chapter 683 describes a multihomed scenario with two NATs to the Internet. 685 +----+ 686 NI -------| MB |\ 687 \ +----+ \ //---\\ 688 \ -| |-- NR 689 \ \\---// 690 \ +----+ | 691 --| MB |-------+ 692 +----+ 693 private 694 private public 696 MB: Middlebox 697 NI: NSIS Initiator 698 NR: NSIS Responder 700 Figure 9: Multihomed Network with two NATs 702 Depending on the destination the one or the other middlebox is used 703 for the data flow. Which middlebox is used depends on local routing 704 decisions. NATFW NSLP must be able to handle this situation proper, 705 see Section 3.2.2 for a more elaborated discussion of this topic with 706 respect to NATs. 708 2.2 Trust Relationship and Authorization 710 Trust relationships and authorization are very important for the 711 protocol machinery. Trust and authorization are closely related to 712 each other in the sense that a certain degree of trust is required to 713 authorize a particular action. For any action (e.g. "create/delete 714 /prolong policy rules" then authorization is very important due to 715 the nature of middleboxes. 717 It is particularly not surprising that different degrees of required 718 authorization in a QoS signaling environment and middlebox signaling 719 exist. As elaborated in [23], establishment of a financial 720 relationship is very important for QoS signaling, whereas for 721 middlebox signaling is not directly of interest. For middlebox 722 signaling a stronger or weaker degree of authorization might be 723 needed. 725 Different trust relationships that appear in middlebox signaling 726 environments are described in the subsequent sections. Peer-to-peer 727 trust relationships are those, which are used in QoS signaling today 728 and seem to be the simplest. However, there are reasons to believe 729 that this is not the only type of trust relationship found in today's 730 networks. 732 2.2.1 Peer-to-Peer Trust Relationship 734 Starting with the simplest scenario it is assumed that neighboring 735 nodes trust each other. The required security association to 736 authenticate and to protect a signaling message is either available 737 (manual configuration) or dynamically established with the help of an 738 authentication and key exchange protocol. If nodes are located 739 closely together it is assumed that security association 740 establishment is easier than establishing it between far distant 741 node. It is, however, difficult to describe this relationship 742 generally due to the different usage scenarios and environments. 743 Authorization heavily depends on the participating entities but for 744 this scenario it is assumed that neighboring entities trust each 745 other (at least for the purpose of policy rule creation, maintenance 746 and deletion). Note that Figure 10 does not illustrate the trust 747 relationship between the end host and the access network. 749 +------------------------+ +-------------------------+ 750 | | | | 751 | Network A | | Network B | 752 | | | | 753 | +---------+ +---------+ | 754 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 755 | | | box 1 | Trust | box 2 | | | 756 | | +---------+ Relationship +---------+ | | 757 | | | | | | 758 | | | | | | 759 | | | | | | 760 | | Trust | | Trust | | 761 | | Relationship | | Relationship | | 762 | | | | | | 763 | | | | | | 764 | | | | | | 765 | +--+---+ | | +--+---+ | 766 | | Host | | | | Host | | 767 | | A | | | | B | | 768 | +------+ | | +------+ | 769 +------------------------+ +-------------------------+ 771 Figure 10: Peer-to-Peer Trust Relationship 773 2.2.2 Intra-Domain Trust Relationship 775 In larger corporations often more than one middlebox is used to 776 protect different departments. In many cases the entire enterprise 777 is controlled by a security department, which gives instructions to 778 the department administrators. In such a scenario a peer-to-peer 779 trust-relationship might be prevalent. Sometimes it might be 780 necessary to preserve authentication and authorization information 781 within the network. As a possible solution a centralized approach 782 could be used whereby an interaction between the individual 783 middleboxes and a central entity (for example a policy decision point 784 - PDP) takes place. As an alternative individual middleboxes could 785 exchange the authorization decision to another middlebox within the 786 same trust domain. Individual middleboxes within an administrative 787 domain should exploit their trust relationship instead of requesting 788 authentication and authorization of the signaling initiator again and 789 again. Thereby complex protocol interaction is avoided. This 790 provides both a performance improvement without a security 791 disadvantage since a single administrative domain can be seen as a 792 single entity. Figure 11 illustrates a network structure, which uses 793 a centralized entity. 795 +-----------------------------------------------------------+ 796 | | 797 | Network A | 798 | | 799 | | 800 | +---------+ +---------+ 801 | +----///--------+ Middle- +------///------++ Middle- +--- 802 | | | box 2 | | box 2 | 803 | | +----+----+ +----+----+ 804 | | | | | 805 | +----+----+ | | | 806 | | Middle- +--------+ +---------+ | | 807 | | box 1 | | | | | 808 | +----+----+ | | | | 809 | | | | | | 810 | - | | | | 811 | - | +----+-----+ | | 812 | | | | Policy | | | 813 | +--+---+ +-----------+ Decision +----------+ | 814 | | Host | | Point | | 815 | | A | +----------+ | 816 | +------+ | 817 +-----------------------------------------------------------+ 819 Figure 11: Intra-domain Trust Relationship 821 2.2.3 End-to-Middle Trust Relationship 823 In some scenarios a simple peer-to-peer trust relationship between 824 participating nodes is not sufficient. Network B might require 825 additional authorization of the signaling message initiator. If 826 authentication and authorization information is not attached to the 827 initial signaling message then the signaling message arriving at 828 Middlebox 2 would cause an error message to be created, which 829 indicates the additional authorization requirement. In many cases 830 the signaling message initiator is already aware of the additionally 831 required authorization before the signaling message exchange is 832 executed. Replay protection is a requirement for authentication to 833 the non-neighboring middlebox, which might be difficult to accomplish 834 without adding additional roundtrips to the signaling protocol (e.g. 835 by adding a challenge/response type of message exchange). 837 Figure 12 shows the slightly more complex trust relationships in this 838 scenario. 840 +----------------------+ +--------------------------+ 841 | | | | 842 | Network A | | Network B | 843 | | | | 844 | | Trust | | 845 | | Relationship | | 846 | +---------+ +---------+ | 847 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 848 | | | box 1 | +-------+ box 2 | | | 849 | | +---------+ | +---------+ | | 850 | | | | | | | 851 | |Trust | | | | | 852 | |Relationship | | | | | 853 | | | | | Trust | | 854 | | | | | Relationship| | 855 | | | | | | | 856 | | | | | | | 857 | | | | | | | 858 | | | | | | | 859 | +--+---+ | | | +--+---+ | 860 | | Host +----///----+------+ | | Host | | 861 | | A | |Trust | | B | | 862 | +------+ |Relationship | +------+ | 863 +----------------------+ +--------------------------+ 865 Figure 12: End-to-Middle Trust Relationship 867 3. Protocol Description 869 The protocol description section defines the NSIS NATFW NSLP with its 870 messages, objects, and the protocol semantics. Section 3.1 871 introduces the protocol and Section 3.3 defines the syntax of the 872 messages and objects. The protocol behavior is defined in Section 873 3.2. 875 3.1 Basic protocol overview 877 The NSIS Signaling Layer Protocol (NSLP) for NAT and FW traversal is 878 carried over the NSIS Transport Layer Protocol (NTLP) defined in [3]. 879 NATFW NSLP messages are initiated by the NSIS initiator (NI), handled 880 by NSIS forwarders (NF) and finally processed by the NSIS responder 881 (NR). It is required that at least NI and NR implement this NSLP, 882 intermediate NF only implement this NSLP when they provide middlebox 883 functions. Forwarders that do not have any NATFW NSLP functions just 884 forward these messages; those forwarders implement NTLP and one or 885 more other NSLPs. 887 A Data Sender (DS) that is intending to send data to a Data Receiver 888 (DR) must start its NATFW NSLP signaling. So the NI at the data 889 sender (DS) starts NSLP signaling towards the address of data 890 receiver DR (see Figure 13). 892 +-------+ +-------+ +-------+ +-------+ 893 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 894 | |--->| NF1 |--->| NF2 |--->| | 895 +-------+ +-------+ +-------+ +-------+ 897 ========================================> 898 Data Traffic Direction 900 ---> : NATFW NSLP request signaling 901 ~~~> : NATFW NSLP response signaling 902 DS/NI : Data sender and NSIS initiator 903 DR/NR : Data receiver and NSIS responder 904 MB1 : Middlebox 1 and NSIS forwarder 1 905 MB2 : Middlebox 2 and NSIS forwarder 2 907 Figure 13: General NSIS signaling 909 The NSLP request messages are processed each time a NF with NATFW 910 NSLP support is passed. Those nodes process the message, check local 911 policies for authorization and authentication, possibly create policy 912 rules, and forward the signaling message to the next NSIS node. The 913 request message is forwarded until it reaches the NSIS responder. 914 NSIS responders will check received messages and process those if 915 applicable. NSIS responders generate response messages and sent them 916 back to the NI via the same chain of NFs. The response message is 917 processed at each NI forwarder implementing NATFW NSLP. The Data 918 Sender can start sending its data flow to the Data Receiver, when the 919 signaling was successful, meaning that NI has received a successful 920 response. 922 In general, NATFW NSLP signaling follows the data path from DS to DR. 923 This enables communication between both hosts for scenarios with only 924 Firewalls on the data path or NATs on sender side. For scenarios 925 with NATs on the receiver side certain problems arise, see also 926 Section 2. 928 When Data receiver (DR) and Data Sender (DS) are located in different 929 address realms and DR is behind a NAT, DS cannot signal to DR 930 directly. DR is not reachable from DS and thus no NATFW signaling 931 can be sent to DR's address. Therefore, DR must first determine an 932 address at a NAT that is reachable for DS, for instance DR must 933 determine its public IP address. Once DR has determined a public 934 address it forwards this to DS via a separate mechanism, which may be 935 application level signaling like SIP. This application level 936 signaling may involve third parties that assist in exchanging this 937 information. This separate mechanism is out of scope of NATFW NSLP. 939 NATFW NSLP signaling supports this public address fixing with this 940 mechanism: 941 o First, DR determines a public address by signaling on the reverse 942 path (DR towards DS) and thus making itself available to other 943 hosts. This process of determining a public addresses is called 944 reservation. This way DR reserves publicly reachable addresses 945 and ports, but this address/port cannot be used by data traffic at 946 this point of time. 947 o Second, DS is signaling directly to DR as DS would do if there is 948 no NAT in between, and so creating policy rules at middleboxes. 949 Note, that the reservation mode will make reservations only, 950 which will be "activated" by the signaling from DS towards DR. 951 The first mode is detailed in the Section 3.2.2 953 The protocol works on a soft-state basis, meaning that that whatever 954 state is installed or reserved on a middlebox, it will expire, and 955 thus be de-installed/ forgotten after a certain period of time. To 956 prevent this, the involved boxes will have to specifically request a 957 session extension. An explicit NATFW NSLP state deletion message is 958 also provided by the protocol. 960 Middleboxes should report back in case of error, so that appropriate 961 measures and debugging can be performed. 963 The next sections define the NATFW NSLP message types and formats, 964 protocol operations, and policy rule operations. 966 3.2 Protocol Operations 968 This section defines the protocol operations, how to create sessions, 969 maintain them, and how to reserve addresses. 971 3.2.1 Creating Sessions 973 Allowing two hosts to exchange data even in the presence of 974 middleboxes is realized in the NATFW NSLP by the 'create session' 975 request message. The data sender generates a 'create session' 976 message as defined in Section 3.4.2 and handles it to the NTLP. The 977 NTLP forwards the whole message on the basis of the flow routing 978 information towards DR. Each NSIS forwarders along the path that is 979 implementing NATFW NSLP process the NSLP message, this is done NSLP 980 hop-by-hop. Finally, the message is approaching DR, DR can accept 981 the request or reject it. DR generates a response to the request, 982 this response is transported hop by hop towards (XXX terminology) DS. 983 NATFW NSLP forwarders may reject requests at any time. Figure 14 984 sketches the message flow between NI (DS), a NF (NAT), and NR (DR). 986 NI Private Network NF Public Internet NR 987 | | | 988 | Create | | 989 |----------------------------->| | 990 | | | 991 | Error (if necessary) | | 992 |<-----------------------------| Create | 993 | |--------------------------->| 994 | | | 995 | | Path Succeeded/Error | 996 | Path Succeeded/Error |<---------------------------| 997 |<-----------------------------| | 998 | | | 999 | | | 1001 Figure 14: Creation message flow 1003 Processing of 'create session' messages is differently per NSIS node: 1004 o NSLP initiator: NI only generate 'create session' messages and 1005 handle them over to the NTLP. After receiving a 'path succeeded' 1006 the data path is configured and the NI can start sending its data 1007 to NR. After receiving an 'error' message the NI MAY try to 1008 generate the 'create session' message again or give up, depending 1009 on the error condition. 1010 o NSLP forwarder: NSLP forwarders receiving 'create session' 1011 messages MUST first check authentication and authorization before 1012 any further processing is executed. The NF SHOULD check with its 1013 local policies if he can accept the desired policy rule given by 1014 NTLP's flow routing information. Further processing depends on 1015 the middlebox type: 1016 * NAT: When the 'create session' message is received at the 1017 public side a network external node is trying to open a NAT 1018 binding. First, it looks for a reservation made in advance by 1019 means of 'reserve external address' that matches the 1020 destination address/port of the flow routing information 1021 provided by the NTLP. If there is no reservation made in 1022 advance the NSLP SHOULD return an error message of type 'no 1023 reservation found' and discard the request. If there is a 1024 reservation, NSLP stores the data sender's address as part of 1025 the policy rule to be loaded and forwards the message with the 1026 address set to the internal address of the next NSIS node. 1027 When the 'create session' message is received at the private 1028 side the NAT binding is reserved, but not activated. The NSLP 1029 message is forwarded to next hop with source address set to the 1030 NAT's external address. 1031 * Firewall: When the 'create session' message is received the 1032 NSLP just remembers the requested policy rule, but does not 1033 install any policy rule. Afterwards, the message is forwarded 1034 to the next NSLP hop. 1035 * Combined NAT and Firewall: Processing at combined Firewall and 1036 NAT middleboxes is the same as in the NAT case. No policy 1037 rules are installed. Implementations MUST take care about the 1038 order of Firewall and NAT functions within the device. Order 1039 of functions is to be interpreted as how packets experience the 1040 treatment of those functions. 1041 o NSLP receiver: NRs receiving 'create session' messages MUST reply 1042 with a 'path succeeded' message if they accept the request 1043 message. Otherwise they SHOULD generate an error message. Both 1044 messages are sent back NSLP hop-by-hop towards NI. 1046 Policy rules at middleboxes MUST be only installed upon receiving a 1047 successful response of type 'path succeeded'. This is a 1048 countermeasure to several problems, for instance, loaded policy rules 1049 at intermediate NF without reaching the actual NR. 1051 3.2.2 Reserving External Addresses 1053 NSIS signaling is intended to travel end-to-end, even in the presence 1054 of NATs and Firewalls on-path. This works well in cases where the 1055 data sender is itself behind a NAT and (covered by Section 3.2.1). 1056 For scenarios where the data receiver is located behind a NAT and it 1057 needs to receive data flows from outside its own network (see Figure 1058 5) it is more troublesome. NSIS signaling, as well as subsequent 1059 data flows, are directed to a particular destination IP address that 1060 must be known in advance and reachable. 1062 +-------------+ AS-Data Receiver Communication 1063 +-------->| Application |<-----------------------------+ 1064 | | Server | | 1065 | +-------------+ | 1066 | IP(R-NAT_B) | 1067 | NSIS Signaling Message +-------+--+ 1068 | +------------------------------------------>| NAT/NAPT | 1069 | | | B | 1070 | | +-------+--+ 1071 | | | 1072 AS-Data| | | 1073 Receiver| | +----------+ | 1074 Comm.| | | NAT/NAPT | | 1075 | | | A | | 1076 | | +----------+ | 1077 | | | 1078 | | | 1079 | | | 1080 | | | 1081 v | IP(R) v 1082 +--------+ +---------+ 1083 | Data | | Data | 1084 | Sender | | Receiver| 1085 +--------+ +---------+ 1087 Figure 15: The Data Receiver behind NAT problem 1089 Figure 15 describes a typical message communication in a peer-to-peer 1090 networking environment whereby the two end points learn of each 1091 others existence with the help of a third party (referred as 1092 Application Server). The communication with the application server 1093 and the two end points (data sender and data receivers) serves a 1094 number of functions. As one of the most important functions it 1095 enables the two end hosts to learn the IP address of each other. The 1096 approach described in this memo supports this peer-to-peer approach, 1097 but is not limited to it. 1099 Some sort of communication between the data sender/data receiver and 1100 a third party is typically necessary (independently of NSIS). NSIS 1101 signaling messages cannot be used to communicate application level 1102 relevant end point identifiers (in the generic case at least) as a 1103 replacement for the communication with the application server. 1105 If the data receiver is behind a NAT then an NSIS signaling message 1106 will be addressed to the IP address allocated at the NAT (if there 1107 was one allocated). If no corresponding NSIS NAT Forwarding State at 1108 NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the signaling 1109 message will terminate at the NAT device (most likely without proper 1110 response message). The signaling message transmitted by the data 1111 sender cannot install the NAT binding or NSIS NAT Forwarding State 1112 "on-the-fly" since this would assume that the data sender knows the 1113 topology at the data receiver side (i.e. the number and the 1114 arrangement of the NAT and the private IP address(es) of the data 1115 receiver). The primary goal of path-coupled middlebox communication 1116 was not to force end hosts to have this type of topology knowledge. 1118 Public Internet Private Address 1119 Space 1120 Edge 1121 NI(DS) NAT NAT NR(DR) 1122 NR+ NI+ 1123 | | | | 1124 | | | | 1125 | | | | 1126 | | Reserve | Reserve | 1127 | |<---------|<----------------| 1128 | | | | 1129 | | Return | ext addr/Error | 1130 | |--------->|---------------->| 1131 | | | | 1132 | | | | 1134 ====================================================> 1135 Data Traffic Direction 1137 Figure 16: Reservation message flow 1139 Figure 16 shows the message flow for reserving an external address/ 1140 port at a NAT. In this case the roles of the different NSIS entities 1141 are: 1142 o The actual data receiver (DR) is the NSIS initiator (NI+) for the 1143 'reserved external address' message, but the NSIS responder (NR) 1144 for 'create session' messages following later. 1145 o The actual data sender (DS) will be the NSIS initiator (NI) for 1146 later 'create session' messages and may be the NSIS target of the 1147 signaling (NR+). 1148 o The actual target of the 'reserved external address' message may 1149 be an arbitrary address NR+. 1151 The data receiver DR starts to signal an 'reserve external address' 1152 message into the "wrong direction". By "wrong" we refer to the usual 1153 behavior of path-coupled signaling where the data sender starts 1154 signaling in order to tackle with routing asymmetry. The data 1155 receiver would typically return signaling messages to the data sender 1156 in the reverse direction by utilizing state created at nodes along 1157 the path (i.e. to reverse route signaling messages). In case of 1158 establishing NAT bindings (and NSIS NAT Forwarding State) the 1159 direction does not matter since the data path is modified through 1160 route pinning due to the external NAT address. Subsequent NSIS 1161 messages (and also data traffic) will travel through the same NAT 1162 boxes. The signaling target address selection for this message is 1163 discussed in Section 3.2.10. 1165 The signaling message creates NSIS NAT Forwarding State at 1166 intermediate NSIS NAT node(s). Furthermore it has to be ensured that 1167 the edge NAT device is discovered as part of this process. The end 1168 host cannot be assumed to know this device - instead the NAT box 1169 itself is assumed to know that it has such a capability. Forwarding 1170 of the 'reserve external address' message beyond this entity is not 1171 necessary, and should be prohibited as it provides information on 1172 internal hosts capabilities. 1174 The edge NAT device is responding with a 'return external address' 1175 message containing the public reachable IP address/port number. 1177 Processing of 'reserve external address' messages is differently per 1178 NSIS node: 1179 o NSLP initiator: NI+ only generate 'reserve external address' 1180 messages and should never receive them. 1181 o NSLP forwarder: NSLP forwarders receiving 'reserve external 1182 address' messages MUST first check authentication and 1183 authorization before any further processing is executed. The NF 1184 SHOULD check with its local policies if he can accept the desired 1185 policy rule given by NTLP's flow routing information. Further 1186 processing depends on the middlebox type: 1188 * NAT: NATs check whether the message is received at the public 1189 address or at the private address. If received at the public 1190 address a NF MAY generate an error message of type 'requested 1191 external address from outside'. If received at the private 1192 address, an IP address/port is reserved. In the case it is an 1193 edge-NAT, the NSLP message is not forwarded anymore and a 1194 response of type 'return external address' is generated. If it 1195 is not an edge-NAT, the NSLP message is forwarded further. 1196 * Firewall: Firewalls MUST not change their configuration upon a 1197 'reserve external address' message. They simply MUST forward 1198 the message and MUST keep NTLP state. Firewalls that are 1199 configured as edge-Firewalls (XXX, do definition!) MAY return 1200 an error of type 'no NAT here'. 1201 * Combined NAT and Firewall: Processing at combined Firewall and 1202 NAT middleboxes is the same as in the NAT case. 1203 o NSLP receiver: This type of message should never be received by 1204 any NR and it SHOULD be discarded silently. 1206 Processing of 'return external address' messages is differently per 1207 NSIS node: 1208 o NSLP initiator: Upon receiving a 'return external address' 1209 message the NI+ can use the obtained IP address and port number 1210 for further application signaling. 1211 o NSLP forwarder: NFs simply forward this message as long as they 1212 keep state for the requested reservation. 1213 o NSIS responder: This type of message should never be received by 1214 any NR and it SHOULD be discarded silently. 1216 3.2.3 Reserving External Addresses and Create Session 1218 Some migration scenarios need specialized support to cope with the 1219 situation where the receiving side is running NSIS only. End-to-end 1220 signaling is going to fail without NSIS support at both sides. For 1221 this the 'create-reverse' signaling mode is supported. In this case, 1222 a DR can signal towards the DS like in the 'reserve external address' 1223 message scenario. The message is forwarded until it reaches the 1224 edge-NAT and retrieves a public IP address and port number. Unlike 1225 in the 'reserve external address' no 'return external address' 1226 response message is created, the forwarding of the request message 1227 stops and a 'create session' message is generated by the edge-NAT. 1228 This request message is sent towards DR with DS as source address and 1229 follows the regular processing orders as 'create session' messages 1230 do. The exact definition of this mode is to be done. 1232 3.2.4 Prolonging Sessions 1234 NATFW NSLP sessions are maintained on a soft-state base. After a 1235 certain timeout sessions and corresponding policy rules are removed 1236 automatically by the middlebox, if they are not refreshed by a 1237 prolong session message. NI is sending prolong message towards NR 1238 and each NSIS forwarder maintaining state for the given session ID 1239 extends the lifetime of the session. Extending lifetime of a session 1240 is calculated as current local time plus lifetime. Section 3.2.7 is 1241 defining the process of calculating lifetimes in detail. 1243 NI Public Internet NAT Private address NR 1244 | | space | 1245 | Prolong | | 1246 |----------------------------->| | 1247 | | | 1248 | Error (if necessary) | | 1249 |<-----------------------------| Prolong | 1250 | |--------------------------->| 1251 | | | 1252 | | Error (if necessary) | 1253 | Error (if necessary) |<---------------------------| 1254 |<-----------------------------| | 1255 | | | 1256 | | | 1258 Figure 17: Prolongation message flow 1260 Processing of 'prolong session' messages is differently per NSIS 1261 node: 1262 o NSLP initiator: NI can generate 'prolong session' messages before 1263 the session times out. 1264 o NSLP forwarder: NSLP forwarders receiving 'prolong session' 1265 messages MUST first check authentication and authorization before 1266 any further processing is executed. The NF SHOULD check with its 1267 local policies if he can accept the desired lifetime extension for 1268 the session referred by the session ID. Processing of this 1269 message is independent of the middlebox type. 1270 o NSLP responder: NIs accepting this prolong message generate a 1271 'path succeeded' message. 1273 3.2.5 Deleting Sessions 1275 NATFW NSLP sessions may be deleted at any time. NSLP initiators can 1276 trigger this deletion via the 'delete session' message, as shown in 1277 Figure 17. 1279 NI Public Internet NAT Private address NR 1280 | | space | 1281 | Delete | | 1282 |----------------------------->| | 1283 | | | 1284 | | Delete | 1285 | |--------------------------->| 1286 | | | 1288 Figure 18: Delete message flow 1290 NSLP nodes receiving this message MUST delete the session 1291 immediately. Corresponding policy rules to this particular session 1292 MUST be deleted immediately, too. This message is forwarded until it 1293 reaches the final NR. The 'delete' message does not generate any 1294 response, neither positive nor negative, since there is no NSIS state 1295 left at the nodes along the path. 1297 3.2.6 Authorization 1299 Authorization and security issues are currently discussed in a 1300 different document and will be included after reaching consensus ( 1301 [20]). 1303 3.2.7 Calculation of Lifetimes 1305 NATFW NSLP sessions, and the corresponding policy rules possibly 1306 installed, are maintained via soft-state. Each session is assigned a 1307 lifetime and they are kept alive as long as the lifetime is valid. 1308 After the expiration of the lifetime sessions and policy rules MUST 1309 be removed automatically and resources bound to them should be freed 1310 as well. Session lifetime is kept at every NATFW NSLP node. The 1311 NSLP forwarders and NSLP responder are not responsible for triggering 1312 lifetime prolongination messages (see Section 3.2.4), this is the 1313 task of the NSIS initiator. 1315 NSIS initiator MUST choose a lifetime value before they can sent any 1316 message (except 'delete session' messages) to other NSLP nodes. This 1317 lifetime value should consider application's needs, i.e., duration in 1318 terms of minutes or hours, and networking needs, i.e., values in the 1319 range less than 30 seconds may not be useful. This requested 1320 lifetime value is placed in the 'lifetime object' of the NSLP message 1321 and messages are forwarded to the next NATFW NSLP node. 1323 NATFW NSLP forwarders processing the request message along the path 1324 MAY lower the request lifetime given to fit their needs and/or local 1325 policy. NATFW forwarders MUST NOT increase the lifetime value; they 1326 MAY reject the requested lifetime immediately and MUST generate an 1327 error response message of type 'lifetime too big' upon rejection. 1328 The NSLP request message is forwarded until it reaches the NSLP 1329 responder. NSLP responder MAY reject the requested lifetime value 1330 and MUST generate an error response message of type 'lifetime too 1331 big' upon rejection. NSLP responder MAY lower the requested lifetime 1332 as well to a granted lifetime. NSLP responders generate their 1333 appropriate response message for the received request message, sets 1334 the lifetime value to the above granted lifetime and sends the 1335 message back hop-by-hop towards NSLP initiator. 1337 Each NSLP forwarder processes the response message, reads and stores 1338 the granted lifetime value. The forwarders SHOULD accept the granted 1339 lifetime, as long as the value is equal or lower than the requested 1340 lifetime. They MAY reject the lifetime and generate a 'lifetime not 1341 acceptable' error response message. Figure 19 shows the procedure 1342 with an example, where an initiator requests 60 minutes lifetime in 1343 'create session' message and the lifetime is shortened along the path 1344 by the forwarder to 20 minutes and by the responder to 5 minutes. 1346 +-------+ CREATE(lt=60m) +-----------+ CREATE(lt=20m) +--------+ 1347 | |---------------->| NSLP |---------------->| | 1348 | NI | | | | NR | 1349 | |<----------------| forwarder |<----------------| | 1350 +-------+ OK(lt=5m) +-----------+ OK(lt=5m) +--------+ 1352 lt = lifetime 1353 CREATE = 'create session' message 1354 OK = 'path succeeded' message 1356 Figure 19: Lifetime Calculation Example 1358 3.2.8 Middlebox Resource 1360 This section needs to be done and should describe how to map flow 1361 routing information to middlebox policy rules. Further, this section 1362 should clarify wildcarding. XXX 1364 3.2.9 De-Multiplexing at NATs 1366 Section 3.2.2 describes how NSIS nodes behind NATs can obtain a 1367 public reachable IP address and port number at a NAT. The 1368 information IP address/port number can be transmitted via a signaling 1369 protocol and/or third party to the communication partner that would 1370 like to send data towards. However, NSIS signaling flows are sent 1371 towards the address of the NAT at which this particular IP address 1372 and port number is allocated. The NATFW NSLP forwarder at this NAT 1373 needs to know how the incoming NSLP requests are related to reserved 1374 addresses, meaning how to de-multiplex incoming requests. 1376 Two options for de-multiplexing incoming NSLP requests are: 1377 1. Based on flow routing information, like protocol number and TCP 1378 port numbers. 1379 2. Based on NSIS session IDs. 1381 Approach 2) would require that both NSIS ends, initiator and 1382 responder, use the same session ID in NSIS signaling. Since session 1383 IDs are usually generated randomly, application level signaling would 1384 have to be adapted to carry NSIS session IDs used during reservation 1385 to the other end (the NSIS initiator sending the 'create session' 1386 message). This approach SHOULD NOT be used. 1388 Approach 1) uses information stored at NATs (like mapping of public 1389 IP address to private, transport protocol, port numbers) and 1390 information given by NTLP's flow routing information to de-multiplex 1391 NSIS messages. This approach is RECOMMENDED. 1393 3.2.10 Selecting Destination IP addresses for REA 1395 Request messages of type 'reserve external address' do need, as any 1396 other message type as well, a final destination IP address to reach. 1397 But as many applications do not provide a destination IP address at 1398 the first place, there is a need to choose a destination address for 1399 the 'reserve external address' messages. This destination can be the 1400 final target, but for the mentioned type of application, the 1401 destination address can be arbitrary. Taking the "correct" 1402 destination IP address might be difficult and there is no right 1403 answer. [19] shows choices for SIP and this section provides some 1404 hints about choosing a good destination IP address in general. 1406 1. Public IP address of the data sender: 1407 * Assumption: 1408 + The data receiver already learned the IP address of the 1409 data sender (e.g. via a third party). 1410 * Problems: 1411 + The data sender might also be behind a NAT. In this case 1412 the public IP address of the data receiver is the IP 1413 address allocated at this NAT. 1415 + Due to routing asymmetry it might be possible that the 1416 routes taken by a) the data sender and the application 1417 server b) the data sender and NAT B might be different. As 1418 a consequence it might be necessary to advertise a new (and 1419 different) external IP address with SIP after using NSIS to 1420 establish a NAT binding. 1421 2. Public IP address of the data receiver (allocated at NAT B): 1422 * Assumption: 1423 + The data receiver already learned his externally visible IP 1424 address (e.g. based on the third party communication). 1425 * Problems: 1426 + Communication with a third party is required. 1427 3. IP address at the Application Server: 1428 * Assumption: 1429 + An application server (or a different third party) is 1430 available. 1431 * Problems: 1432 + If the NSIS signaling message is not terminated at the NAT 1433 of the local network then an NSIS unaware application 1434 server might discard the message. 1435 + Routing might not be optimal since the route between a) the 1436 data receiver and the application server b) the data 1437 receiver and the data sender might be different. 1439 3.3 NATFW NSLP Messages Components 1441 A NATFW NSLP message consists of a NSLP header and one or more 1442 objects following the header. The NSLP header is common for all 1443 NSLPs and objects are Type-Length-Value (TLV) encoded using big 1444 endian (network ordered) binary data representations. Header and 1445 objects are bound to 32 bits and objects that do not fall into 32 1446 bits boundaries must be padded to 32 bits. 1448 The whole NSLP message is carried in a NTLP message. 1450 Note that the notation 0x is used to indicate hexadecimal numbers. 1452 3.3.1 NSLP Header 1454 The NSLP header is common to all NSLPs and is the first part of all 1455 NSLP messages. It contains two fields, the NSLP message type and a 1456 reserved field. The total length is 32 bits. The layout of the NSLP 1457 header is defined by Figure 20. 1459 0 16 31 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | NSLP message type | reserved | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 Figure 20: Common NSLP header 1466 The reserved field MUST be set to zero in the NATFW NSLP header 1467 before sending and MUST be ignored during processing the header. 1468 Note that other NSLPs use this field as flag field. 1470 3.3.2 NSLP message types 1472 The message types identify requests and responses. Defined messages 1473 types for requests are: 1474 o 0x0101 : create 1475 o 0x0102 : reserve 1476 o 0x0103 : reserve-create 1477 o 0x0104 : prolong 1478 o 0x0105 : delete 1479 Defined message types for responses are: 1480 o 0x0201 : path_succeed 1481 o 0x0202 : path_deleted 1482 o 0x0203 : ret_ext_addr 1483 o 0x0204 : error 1485 3.3.3 NSLP Objects 1487 NATFW NSLP objects use a common header format defined by Figure 21. 1488 Objects are Type-Length-Value (TLV) encoded using big endian (network 1489 ordered) binary data representations. The object header contains two 1490 fields, the NSLP object type and the object length. Its total length 1491 is 32 bits. 1493 0 16 31 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | NSLP object type | NSLP object length | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 Figure 21: Common NSLP object header 1500 The length is the total length of the object without the object 1501 header. The unit is bytes. The particular values of type and length 1502 for each NSLP object are listed in the subsequent chapters that 1503 define the NSLP objects. 1505 3.3.3.1 Session ID Object 1507 The session ID object carries an identifier for the session of the 1508 signaled flow. The only field is the session ID of 16 bytes length. 1510 0 16 31 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 | 0x0001 | 16 bytes | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | | 1515 // 16 bytes session id // 1516 | | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 Figure 22: Session ID object 1521 The session ID is generated in random way by the NSIS initiator. 1523 3.3.3.2 Session Lifetime Object 1525 The session lifetime object carries the requested or granted lifetime 1526 of a NATFW NSLP session measured in seconds. The object consists 1527 only of the 4 bytes lifetime field. 1529 0 16 31 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | 0x0002 | 4 bytes | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | NATFW NSLP session lifetime | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 Figure 23: Lifetime object 1538 3.3.3.3 External Address Object 1540 The external address objects can be included in ret_ext_addr 1541 responses (Section 3.4.9) only. It contains the external IP address 1542 and port number allocated at the edge-NAT. Note that this address/ 1543 port may be either reserved or reserve-create. Two fields are 1544 defined, the external IP address, and the external port number. For 1545 IPv4 the object with value 0x0010 is defined. It has a length of 8 1546 bytes and is shown in Figure 24. 1548 0 16 31 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | 0x0010 | 8 bytes | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | port number | reserved | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | IPv4 address | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 Figure 24: External Address Object for IPv4 addresses 1559 For IPv6 the object with value 0x0011 is defined. It has a length of 1560 20 bytes and is shown in Figure 25. 1562 0 16 31 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | 0x0011 | 20 bytes | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | port number | reserved | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | | 1569 + + 1570 | | 1571 + IPv6 address + 1572 | | 1573 + + 1574 | | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 Figure 25: External Address Object for IPv6 addresses 1579 3.3.3.4 Extended Flow Information Object 1581 In general, flow information is kept at the NTLP level during 1582 signaling. Nevertheless, some additional information may be required 1583 for NSLP operations. The 'extended flow information' object carries 1584 this additional information about number of subsequent port numbers 1585 that should be allocated at middleboxes. 1587 These fields are defined for the policy rule object: 1588 o Number of ports: This field gives the number of ports that should 1589 be allocated beginnig at the port given in NTLP's flow routing 1590 information. 1592 0 16 31 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | 0x0011 | 4 bytes | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | number of ports | reserved | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 Figure 26: Extended Flow Information 1601 3.3.3.5 Error Object 1603 The error object carries the reason for an error. It has only one 1604 field, the error code, and is 2 bytes long. 1606 0 16 31 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | 0x0002 | 4 bytes | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | error code | reserved | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 Figure 27: Error 1615 TBD: Define error clases and define the error coded. Possible 1616 classes are: 1618 o Policy rule errors 1619 o Authentication and Authorization errors 1620 o NAT 1621 Currently in this memo defined errors: 1622 o lifetime too big 1623 o lifetime not acceptable 1624 o no NAT here 1625 o no reservation found 1626 o requested external address from outside 1628 3.4 Message Formats 1630 This section defines the content of each NATFW NSLP message type. 1631 The message types are defined in Section 3.3.2. First, the request 1632 messages are defined with their respective objects to be included in 1633 the message. Second, the response messages are defined with their 1634 respective objects to be included. 1636 Basically, each message is constructed of NSLP header and one or more 1637 NSLP objects. The order of objects is not defined, meaning that 1638 objects may occur in any sequence. 1640 Each section elaborates the required settings and parameters to be 1641 set by the NSLP at the NTLP, for instance, how the flow routing 1642 information is set. 1644 3.4.1 Policy Rules 1646 Policy rules are the building block of middlebox devices considered 1647 in the NATFW NSLP. For Firewalls the policy rule consists usually of 1648 a 5-tuple, source/destination address, transport protocol, and 1649 source/destination port number, plus an action like allow or deny. 1650 Other actions are available depending on the implementation of the 1651 Firewall, but NATFW NSLP uses only allow action, since a default to 1652 deny policy at the middlebox is assumed. For NATs the policy rule 1653 consists of action 'map this another address realm' and further 1654 mapping information, that might be in the most simply case internal 1655 IP address and external IP address. 1657 Policy rules are usually carried in one piece in signaling 1658 applications. In NSIS the policy rule is divided into the filter 1659 specification, an implicit allow action, and additional information. 1660 The filter specification is carried within NTLP's flow routing 1661 information and additional information is carried in NSLP's objects. 1662 Additional information is for instance the lifetime of a policy rule 1663 or session. 1665 3.4.2 Create Session (CRS) 1667 The create session request message is used to create NSLP sessions 1668 and at middleboxes to create policy rules. 1670 The create session messages carries these objects: 1671 o Session ID object 1672 o Lifetime object 1674 The flow routing information in the NTLP MUST be set to DS as source 1675 address and DR as destination address. All other parameters MUST be 1676 set according the required policy rule. 1678 3.4.3 Reserve External Address (REA) 1680 The reserve external address (REA) request message is used to lookup 1681 a NAT and to allocated an external IP address and possibly port 1682 number, so that the initiator of the REA request has a public 1683 reachable IP address/port number. 1685 The REA request message carries these objects: 1686 o Session ID object 1687 o Lifetime object 1689 The REA message needs special NTLP treatment. First of all, REA 1690 messages travel the wrong way, from the DR towards DS. Second, the 1691 DS' address used during the signaling may be not the actual DS (see 1692 Section 3.2.10). Therefore, the NTLP flow routing information is set 1693 to DR as initiator and DS as responders, a special field is given in 1694 the NTLP: The signaling destination. 1696 3.4.4 Reserve-Create (REC) 1698 XXX This is a proposal for a new message to support the reservation 1699 and simultaneous/implicit create message generation. 1701 The reserve-create message carries these objects: 1702 o Session ID object 1703 o Lifetime object 1705 NTLP issues: TBD. 1707 3.4.5 Prolong Session (PLS) 1709 The prolong request message is used to prolong (extend) the lifetime 1710 of a NATFW NSLP and policy rules at middleboxes. 1712 The prolong session message carries these objects: 1714 o Session ID object 1715 o Lifetime object 1717 The flow routing information in the NTLP MUST be set to DS as source 1718 address and DR as destination address. All other parameters MUST be 1719 set according the required policy rule. 1721 3.4.6 Delete Session (DLS) 1723 The delete request message is used to delete NATFW NSLP sessions. 1725 The delete session message carries these objects: 1726 o Session ID object 1728 The flow routing information in the NTLP MUST be set to DS as source 1729 address and DR as destination address. All other parameters MUST be 1730 set according the required policy rule. 1732 3.4.7 Path Succeeded (PS) 1734 The path succeeded response message is used to acknowledge a 1735 successful create and prolong. 1737 The path succeeded message carries these objects: 1738 o Session ID object 1739 o lifetime object 1741 This message is routed on the reverse path. 1743 3.4.8 Path Deleted (PD) 1745 The path deleted response message is used to acknowledge a successful 1746 delete request message. 1748 The path deleted message carries this object: 1749 o Session ID object 1751 This message is routed on the reverse path. 1753 3.4.9 Return External Address (RA) 1755 The return external address response message is sent back as a 1756 positive result of reserve external address request. It contains the 1757 reserved external IP address and port number. 1759 The path succeeded message carries these objects: 1760 o Session ID object 1761 o Lifetime object 1762 o External address object (either IPv4 or IPv6 type) 1764 This message is routed on the reverse path. 1766 3.4.10 Error Response (ER) 1768 The error response message is sent back by any NSIS node involved in 1769 the session that occurs an error condition. 1771 The error message carries these objects: 1772 o Session ID object 1773 o Error object 1775 This message is routed on the reverse path. 1777 4. NSIS NAT and Firewall transitions issues 1779 NSIS NAT and Firewall transition issues are premature and will be 1780 addressed in a separate draft (see [17]). An update of this section 1781 will be based on consensus. 1783 5. Security Considerations 1785 Security is of major concern particularly in case of Firewall 1786 traversal. Generic threats for NSIS signaling have been discussed in 1787 [6] and are applicable here as well. It is necessary to provide 1788 proper signaling message protection and proper authorization. Note 1789 that the NAT is likely to be co-located with a Firewall and might 1790 therefore require packet filters to be changed in order to allow the 1791 signaling message to process and to traverse. This section aims to 1792 raise some items for further discussion and illustrates the problems 1793 the authors faced when creating a security solution for the NAT/ 1794 Firewall NSLP. 1796 Installing packet filters provides some security, but has some 1797 weaknesses, which heavily depend on the type of packet filter 1798 installed. A packet filter cannot prevent an adversary to inject 1799 traffic (due to the IP spoofing capabilities). This type of attack 1800 might not be particular helpful if the packet filter is a standard 5 1801 tuple which is very restrictive. If packet filter installation, 1802 however, allows specifying a rule, which restricts only the source IP 1803 address, then IP spoofing allows transmitting traffic to an arbitrary 1804 address. NSIS aims to provide path-coupled signaling and therefore 1805 an adversary is somewhat restricted in the location from which 1806 attacks can be performed. Some trust is therefore assumed from nodes 1807 and networks along the path. 1809 Without doubts there is a dependency on the security provided by the 1810 NTLP. Section Appendix A and Section 2.2 motivates some trust 1811 relationship and authorization scenarios. These scenarios deserve a 1812 discussion since some of them (particularly one with a missing 1813 network-to-network trust relationship) is different to what is know 1814 from QoS signaling. To address some of these trust relationships and 1815 authorization issues requires security mechanisms between 1816 non-neighboring nodes at the NSLP layer. For the group of authors it 1817 seems that peer-to-peer and end-to-middle security needs to be 1818 provided. An NSLP security mechanism between neighboring NSLP peers 1819 might be necessary if security mechanisms at the NTLP do not provide 1820 adequate protection mechanisms. This issue is, however, still in 1821 discussion. 1823 As a design goal it seems to be favorable to reuse existing 1824 mechanisms to the best extend possible. In most cases it is 1825 necessary to carry the objects for end-to-middle as NSLP payloads 1826 since the presence of NATs might prevent direct communication. Three 1827 security mechanisms have to be considered in more detail in a future 1828 version of this document: CMS [21] and Identity Representation for 1829 RSVP [15]. The authors believe that CMS more suitable (since it 1830 provides much more functionality). The details deserve further 1831 discussion and implementation experience. 1833 With regard to signal between two end hosts even though the receiver 1834 is behind a NAT this proposal suggests creating state by the data 1835 receiver first. This allows NSIS signaling messages to traverse a 1836 NAT at the receiver side (due to the established state at this NAT 1837 box) and simplifies security handling. To achieve this behavior it 1838 is required to install NSIS NTLP and NSLP state. Furthermore, it is 1839 envisioned to associate the two signaling parts (one part from the 1840 data sender to the NAT and the other part from the NAT to the data 1841 receiver) with the help of the Session Identifier. As such, the 1842 discussion in [15] is relevant for this document. 1844 Another interesting property of this protocol proposal is to prevent 1845 Denial of Service attacks against NAT boxes whereby an adversary 1846 allocates NAT bindings with the help of data packets. Since these 1847 data packets do not provide any type of authentication and are not 1848 authorized any adversary is able to mount such an attack. This 1849 attack has been mentioned at several places in the literature 1850 already and is particularly harmful if no NAPT functionality is used 1851 (i.e. if a new NAT binding consumes one IP address of a pool of IP 1852 addresses). Using the protocol described in this document additional 1853 security can be achieved and more fairness can be provided. 1855 6. Open Issues 1857 At least the following issues require further discussion: 1858 o Option processing rules in presence of unknown options. 1859 o Terminology w.r.t. the term wrong way. 1860 o NTLP: New object and semantics for REA. 1861 o NTLP and NATFW NSLP interaction 1862 o List of NTLP transport modes per NSLP message 1863 o Routing Change detection 1864 o Query message, definition of semantics needed 1865 o Is there a need for a QoS NSLP RSN like object/mechanism in NATFW 1866 NSLP? 1867 o Add IANA considerations section. 1868 o re-work security considerations. 1869 o Query message: Syntax and semantics. 1870 o Add text about asynchronous messages. 1871 o Anycast address for REA. 1872 o Check common formats with QoS NSLP 1873 o Change length field of objects to long words as unit? 1874 o Variable length for session id? 1875 o Meaning of 0 as session ID. 1876 o Extended flow object: Needs refinement 1878 7. Contributors 1880 A number of individuals have contributed to this draft. Since it was 1881 not possible to list them all in the authors section, it was decided 1882 to split it and move Marcus Brunner and Henning Schulzrinne into the 1883 contributors section. Separating into two groups was done without 1884 treating any one of them better (or worse) than others. 1886 8. References 1888 8.1 Normative References 1890 [1] Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT 1891 draft-ietf-nsis-fw-05.txt, October 2003. 1893 [2] Brunner et al., M., "Requirements for Signaling Protocols", 1894 DRAFT draft-ietf-nsis-req-09.txt, October 2003. 1896 [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 1897 Messaging Protocol for Signaling", DRAFT 1898 draft-ietf-nsis-ntlp-00.txt, October 2003. 1900 [4] Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 1901 Quality-of-Service signaling", DRAFT 1902 draft-ietf-nsis-qos-nslp-03.txt, May 2004. 1904 [5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 1906 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 1907 DRAFT draft-ietf-nsis-threats-01.txt, January 2003. 1909 [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 1910 Rayhan, "Middlebox communication architecture and framework", 1911 RFC 3303, August 2002. 1913 8.2 Informative References 1915 [8] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1916 (NAT) Terminology and Considerations, RFC 2663", August 1999. 1918 [9] Srisuresh, P. and M. Holdrege, "Network Address Translator 1919 (NAT)Terminology and Considerations, RFC 2663". 1921 [10] Srisuresh, P. and E. Egevang, "Traditional IP Network Address 1922 Translator (Traditional NAT), RFC 3022", January 2001. 1924 [11] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 1925 Protocol Translation (NAT-PT), RFC 2766", February 2000. 1927 [12] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 1928 RFC 3234, February 2002. 1930 [13] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, 1931 "DNS extensions to Network Address Translators (DNS_ALG)", RFC 1932 2694, September 1999. 1934 [14] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 1935 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1936 Specification", September 1997. 1938 [15] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 1939 Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 1940 3182, October 2001. 1942 [16] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and 1943 X. Fu, "Security Implications of the Session Identifier", June 1944 2003. 1946 [17] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. 1947 Tschofenig, "NAT/Firewall NSLP Migration Considerations", DRAFT 1948 draft-aoun-nsis-nslp-natfw-migration-01.txt, Februar 2004. 1950 [18] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. 1951 Tschofenig, "NATFirewall NSLP Intra-realm considerations", 1952 DRAFT draft-aoun-nsis-nslp-natfw-intrarealm-00.txt, Februar 1953 2004. 1955 [19] Martin, M., Brunner, M. and M. Stiemerling, "SIP NSIS 1956 Interactions for NAT/Firewall Traversal", DRAFT 1957 draft-martin-nsis-nslp-natfw-sip-00.txt, Februar 2004. 1959 [20] Martin, M., Brunner, M., Stiemerling, M., Girao, J. and C. 1960 Aoun, "A NSIS NAT/Firewall NSLP Security Infrastructure", DRAFT 1961 draft-martin-nsis-nslp-natfw-security-01.txt, Februar 2004. 1963 [21] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 1964 August 2002. 1966 [22] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K. 1967 Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt, 1968 November 2002. 1970 [23] Tschofenig, H., Buechli, M., Van den Bosch, S. and H. 1971 Schulzrinne, "NSIS Authentication, Authorization and Accounting 1972 Issues", March 2003. 1974 [24] Amini, L. and H. Schulzrinne, "Observations from router-level 1975 internet traces", DIMACS Workshop on Internet and WWW 1976 Measurement, Mapping and Modelin Jersey) , Februar 2002. 1978 [25] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 1979 Traversal of VPN Gateways", 1980 draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in 1981 progress), April 2003. 1983 [26] Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin, 1984 "Problem Space and Usage Scenarios for PANA", 1985 draft-ietf-pana-usage-scenarios-06 (work in progress), April 1986 2003. 1988 [27] Shore, M., "The TIST (Topology-Insensitive Service Traversal) 1989 Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002. 1991 [28] Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT 1992 Traversal Client for CASP", DRAFT 1993 draft-tschofenig-nsis-casp-midcom-01.txt, March 2003. 1995 [29] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1996 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1997 Session Initiation Protocol", RFC 3261, June 2002. 1999 [30] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H. and H. 2000 Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and 2001 Framework", DRAFT draft-brunner-nsis-midcom-ps-00.txt, June 2002 2003. 2004 [31] Ford, B., Srisuresh, P. and D. Kegel, "Peer-to-Peer(P2P) 2005 communication Network Address Translators(NAT)", DRAFT 2006 draft-ford-midcom-p2p-02.txt, March 2004. 2008 [32] Rosenberg et al, J., "STUN - Simple Traversal of User Datagram 2009 Protocol (UDP) Through Network Address Translators (NATs)", RFC 2010 3489, March 2003. 2012 [33] Rekhter et al, Y., "Address Allocation for Private Internets", 2013 RFC 1918, February 1996. 2015 Authors' Addresses 2017 Martin Stiemerling 2018 Network Laboratories, NEC Europe Ltd. 2019 Kurfuersten-Anlage 36 2020 Heidelberg 69115 2021 Germany 2023 Phone: +49 (0) 6221 905 11 13 2024 EMail: stiemerling@netlab.nec.de 2025 URI: 2027 Hannes Tschoefenig 2028 Siemens AG 2029 Otto-Hahn-Ring 6 2030 Munich 81739 2031 Germany 2033 Phone: 2034 EMail: Hannes.Tschofenig@siemens.com 2035 URI: 2037 Miquel Martin 2038 Network Laboratories, NEC Europe Ltd. 2039 Kurfuersten-Anlage 36 2040 Heidelberg 69115 2041 Germany 2043 Phone: +49 (0) 6221 905 11 16 2044 EMail: miquel.martin@netlab.nec.de 2045 URI: 2047 Cedric Aoun 2048 Nortel Networks 2050 France 2052 EMail: cedric.aoun@nortelnetworks.com 2054 Appendix A. Problems and Challenges 2056 This section describes a number of problems that have to be addressed 2057 for NSIS NAT/Firewall. Issues presented here are subject to further 2058 discussions. These issues might be also of relevance to other NSLP 2059 protocols. 2061 A.1 Missing Network-to-Network Trust Relationship 2063 Peer-to-peer trust relationship, as shown in Figure 10, is a very 2064 convenient assumption that allows simplified signaling message 2065 processing. However, it might not always be applicable, especially 2066 between two arbitrary access networks (over a core network where 2067 signaling messages are not interpreted). Possibly peer-to-peer trust 2068 relationship does not exist because of the large number of networks 2069 and the unwillingness of administrators to have other network 2070 operators to create holes in their Firewalls without proper 2071 authorization. Hence in the following scenario we assume a somewhat 2072 different message processing and show three possible approaches to 2073 tackle the problem. None of these three approaches is without 2074 drawbacks or constraining assumptions. 2076 +----------------------+ +--------------------------+ 2077 | | | | 2078 | Network A | | Network B | 2079 | | | | 2080 | +---------+ Missing +---------+ | 2081 | +-///-+ Middle- | Trust | Middle- +-///-+ | 2082 | | | box 1 | Relation- | box 2 | | | 2083 | | +---------+ ship +---------+ | | 2084 | | | or | | | 2085 | | | Authorization| | | 2086 | | | | | | 2087 | | Trust | | Trust | | 2088 | | Relationship | | Relationship | | 2089 | | | | | | 2090 | | | | | | 2091 | | | | | | 2092 | +--+---+ | | +--+---+ | 2093 | | Host | | | | Host | | 2094 | | A | | | | B | | 2095 | +------+ | | +------+ | 2096 +----------------------+ +--------------------------+ 2098 Figure 28: Missing Network-to-Network Trust Relationship 2100 Figure 28 illustrates a problem whereby an external node is not 2101 allowed to manipulate (create, delete, query, etc.) packet filters at 2102 a Firewall. Opening pinholes is only allowed for internal nodes or 2103 with a certain authorization permission. Hence the solution 2104 alternatives in Section 3.2.2 focus on establishing the necessary 2105 trust with cooperation of internal nodes. 2107 A.2 Relationship with routing 2109 The data path is following the "normal" routes. The NAT/FW devices 2110 along the data path are those providing the service. In this case 2111 the service is something like "open a pinhole" or even more general 2112 "allow for connectivity between two communication partners". The 2113 benefit of using path-coupled signaling is that the NSIS NATFW NSLP 2114 does not need to determine what middleboxes or in what order the data 2115 flow will go through. 2117 Creating NAT bindings modifies the path of data packets between two 2118 end points. Without NATs involved, packets flow from endhost to 2119 endhost following the path given by the routing. With NATs involved, 2120 this end-to-end flow is not directly possible, because of separated 2121 address realms. Thus, data packets flow towards the external IP 2122 address at a NAT (external IP address may be a public IP address). 2124 Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with 2125 routing - instead they only follow the path of the data packets. 2127 A.3 Affected Parts of the Network 2129 NATs and Firewalls are usually located at the edge of the network, 2130 whereby other signaling applications affect all nodes along the path. 2131 One typical example is QoS signaling where all networks along the 2132 path must provide QoS in order to achieve true end-to-end QoS. In 2133 the NAT/Firewall case, only some of the domains/nodes are affected 2134 (typically access networks), whereas most parts of the networks and 2135 nodes are unaffected (e.g. the core network). 2137 This fact raises some questions. Should an NSIS NTLP node intercept 2138 every signaling message independently of the upper layer signaling 2139 application or should it be possible to make the discovery procedure 2140 more intelligent to skip nodes. These questions are also related to 2141 the question whether NSIS NAT/FW should be combined with other NSIS 2142 signaling applications. 2144 A.4 NSIS backward compatibility with NSIS unaware NAT and Firewalls 2146 Backward compatibility is a key for NSIS deployments, as such the 2147 NSIS protocol suite should be sufficiently robust to allow traversal 2148 of none NSIS aware routers (QoS gates, Firewalls, NATs, etc ). 2150 NSIS NATFW NSLP's backward compatibility issues are different than 2151 the NSIS QoS NSLP backward compatibility issues, where an NSIS 2152 unaware QoS gate will simply forward the QoS NSLP message. An NSIS 2153 unaware Firewall rejects NSIS messages, since Firewalls typically 2154 implement the policy "default to deny". 2156 The NSIS backward compatibility support on none NSIS aware Firewall 2157 would typically consist of configuring a static policy rule that 2158 allows the forwarding of the NSIS protocol messages (either protocol 2159 type if raw transport mode is used or transport port number in case a 2160 transport protocol is used). 2162 For NATs backward compatibility is more problematic since signaling 2163 messages are forwarded (at least in one direction), but with a 2164 changed IP address and changed port numbers. The content of the NSIS 2165 signaling message is, however, unchanged. This can lead to 2166 unexpected results, both due to embedded unchanged local scoped 2167 addresses and none NSIS aware Firewalls configured with specific 2168 policy rules allowing forwarding of the NSIS protocol (case of 2169 transport protocols are used for the NTLP). NSIS unaware NATs must 2170 be detected to maintain a well-known deterministic mode of operation 2171 for all the involved NSIS entities. Such a "legacy" NAT detection 2172 procedure can be done during the NSIS discover procedure itself. 2174 Based on experience it was discovered that routers unaware of the 2175 Router Alert IP option [RFC 2113] discarded packets, this is 2176 certainly a problem for NSIS signaling. 2178 A.5 Authentication and Authorization 2180 For both types of middleboxes, Firewall and NAT security is a strong 2181 requirement. Authentication and authorization means must be 2182 provided. 2184 For NATFW signaling applications it is partially not possible to do 2185 authentication and authorization based on IP addresses. Since NATs 2186 change IP addresses, such an address based authentication and 2187 authorization scheme would fail. 2189 A.6 Directional Properties 2191 There two directional properties that need to be addressed by the 2192 NATFW NSLP: 2193 o Directionality of the data 2194 o Directionality of NSLP signaling 2196 Both properties are relevant to NATFW NSLP aware NATs and Firewalls. 2198 With regards to NSLP signaling directionality: As stated in the 2199 previous sections, the authentication and authorization of NSLP 2200 signaling messages received from hosts within the same trust domain 2201 (typically from hosts located within the security perimeter delimited 2202 by Firewalls) is normally simpler than received messages sent by 2203 hosts located in different trust domains. 2205 The way NSIS signaling messages enters the NSIS entity of a Firewall 2206 (see Figure 2) might be important, because different policies might 2207 apply for authentication and admission control. 2209 Hosts deployed within the secured network perimeter delimited by a 2210 Firewall, are protected from hosts deployed outside the secured 2211 network perimeter, hence by nature the Firewall has more restrictions 2212 on flows triggered from hosts deployed outside the security 2213 perimeter. 2215 A.7 Addressing 2217 A more general problem of NATs is the addressing of the end-point. 2218 NSIS signaling message have to be addressed to the other end host to 2219 follow data packets subsequently sent. Therefore, a public IP 2220 address of the receiver has to be known prior to sending an NSIS 2221 message. When NSIS signaling messages contain IP addresses of the 2222 sender and the receiver in the signaling message payloads, then an 2223 NSIS entity must modify them. This is one of the cases, where a NSIS 2224 aware NATs is also helpful for other types of signaling applications 2225 e.g. QoS signaling. 2227 A.8 NTLP/NSLP NAT Support 2229 It must be possible for NSIS NATs along the path to change NTLP and/ 2230 or NSLP message payloads, which carry IP address and port 2231 information. This functionality includes the support of providing 2232 mid-session and mid-path modification of these payloads. As a 2233 consequence these payloads must not be reordered, integrity protected 2234 and/or encrypted in a non peer-to-peer fashion (e.g. end-to-middle, 2235 end-to-end protection). Ideally these mutable payloads must be 2236 marked (e.g. a protected flag) to assist NATs in their effort of 2237 adjusting these payloads. 2239 A.9 Combining Middlebox and QoS signaling 2241 In many cases, middlebox and QoS signaling has to be combined at 2242 least logically. Hence, it was suggested to combine them into a 2243 single signaling message or to tie them together with the help of 2244 some sort of data connection identifier, later on referred as Session 2245 ID. This, however, has some disadvantages such as: 2247 - NAT/FW NSLP signaling affects a much small number of NSIS nodes 2248 along the path (for example compared to the QoS signaling). 2250 - NAT/FW signaling might show different signaling patterns (e.g. 2251 required end-to-middle communication). 2253 - The refresh interval is likely to be different. 2255 - The number of error cases increase as different signaling 2256 applications are combined into a single message. The combination of 2257 error cases has to be considered. 2259 A.10 Inability to know the scenario 2261 In Section 2.1 a number of different scenarios are presented. Data 2262 receiver and sender may be located behind zero, one, or more 2263 Firewalls and NATs. Depending on the scenario, different signaling 2264 approaches have to be taken. For instance, data receiver with no 2265 NAT and Firewall can receive any sort of data and signaling without 2266 any further action. Data receivers behind a NAT must first obtain a 2267 public IP address before any signaling can happen. The scenario 2268 might even change over time with moving networks, ad-hoc networks or 2269 with mobility. 2271 NSIS signaling must assume the worst case and cannot put 2272 responsibility to the user to know which scenario is currently 2273 applicable. As a result, it might be necessary to perform a 2274 "discovery" periodically such that the NSIS entity at the end host 2275 has enough information to decide which scenario is currently 2276 applicable. This additional messaging, which might not be necessary 2277 in all cases, requires additional performance, bandwidth and adds 2278 complexity. Additional, information by the user can provide 2279 information to assist this "discovery" process, but cannot replace 2280 it. 2282 Appendix B. Acknowledgments 2284 We would like to acknowledge Vishal Sankhla and Joao Girao for their 2285 input to this draft. 2287 Intellectual Property Statement 2289 The IETF takes no position regarding the validity or scope of any 2290 intellectual property or other rights that might be claimed to 2291 pertain to the implementation or use of the technology described in 2292 this document or the extent to which any license under such rights 2293 might or might not be available; neither does it represent that it 2294 has made any effort to identify any such rights. Information on the 2295 IETF's procedures with respect to rights in standards-track and 2296 standards-related documentation can be found in BCP-11. Copies of 2297 claims of rights made available for publication and any assurances of 2298 licenses to be made available, or the result of an attempt made to 2299 obtain a general license or permission for the use of such 2300 proprietary rights by implementors or users of this specification can 2301 be obtained from the IETF Secretariat. 2303 The IETF invites any interested party to bring to its attention any 2304 copyrights, patents or patent applications, or other proprietary 2305 rights which may cover technology that may be required to practice 2306 this standard. Please address the information to the IETF Executive 2307 Director. 2309 Full Copyright Statement 2311 Copyright (C) The Internet Society (2004). All Rights Reserved. 2313 This document and translations of it may be copied and furnished to 2314 others, and derivative works that comment on or otherwise explain it 2315 or assist in its implementation may be prepared, copied, published 2316 and distributed, in whole or in part, without restriction of any 2317 kind, provided that the above copyright notice and this paragraph are 2318 included on all such copies and derivative works. However, this 2319 document itself may not be modified in any way, such as by removing 2320 the copyright notice or references to the Internet Society or other 2321 Internet organizations, except as needed for the purpose of 2322 developing Internet standards in which case the procedures for 2323 copyrights defined in the Internet Standards process must be 2324 followed, or as required to translate it into languages other than 2325 English. 2327 The limited permissions granted above are perpetual and will not be 2328 revoked by the Internet Society or its successors or assignees. 2330 This document and the information contained herein is provided on an 2331 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2332 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2333 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2334 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2335 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2337 Acknowledgment 2339 Funding for the RFC Editor function is currently provided by the 2340 Internet Society.