idnits 2.17.1 draft-ietf-nsis-nslp-natfw-01.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.) ** There are 5 instances of lines with control characters in the document. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 287 has weird spacing: '...ch some netwo...' == Line 921 has weird spacing: '...he data packe...' == Line 1127 has weird spacing: '...ult, it might...' == Line 1489 has weird spacing: '...rvation mode ...' == Line 2128 has weird spacing: '...network and w...' == (1 more instance...) -- 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 (February 16, 2004) is 7368 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 245 -- Looks like a reference, but probably isn't: 'RFC 2113' on line 983 -- Looks like a reference, but probably isn't: 'NATP2P' on line 1214 == Unused Reference: '4' is defined on line 2889, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2906, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2927, 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') ** Obsolete normative reference: RFC 3330 (ref. '4') (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. '5') ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. '6') -- Duplicate reference: RFC2663, mentioned in '8', was also mentioned in '7'. -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '10') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '17') (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 Summary: 9 errors (**), 0 flaws (~~), 17 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: August 16, 2004 H. Tschofenig 5 Siemens 6 M. Martin 7 NEC 8 C. Aoun 9 Nortel Networks 10 February 16, 2004 12 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 13 draft-ietf-nsis-nslp-natfw-01 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 other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 16, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This memo defines the NSIS Signaling Layer Protocol (NSLP) for 44 Network Address Translators and Firewalls. The network scenarios, 45 problems and solutions for path-coupled Network Address Translator 46 and Firewall signaling are described. The overall architecture is 47 given by the framework and requirements defined by Next Steps in 48 Signaling (NSIS) working group. This is one of two NSIS Signaling 49 Layer Protocols (NSLPs) the working group will address during its 50 work. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.1 Terminology and Abbreviations . . . . . . . . . . . . . . 6 56 1.2 Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 7 57 1.3 General Scenario for NATFW Traversal . . . . . . . . . . . 9 59 2. Network Environment . . . . . . . . . . . . . . . . . . . 11 60 2.1 Network Scenarios for Protocol Functionality . . . . . . . 11 61 2.1.1 Firewall traversal . . . . . . . . . . . . . . . . . . . . 11 62 2.1.2 NAT with two private Networks . . . . . . . . . . . . . . 12 63 2.1.3 NAT with private network on sender side . . . . . . . . . 13 64 2.1.4 NAT with private network on receiver side . . . . . . . . 13 65 2.1.5 Both End Hosts behind twice-NATs . . . . . . . . . . . . . 14 66 2.1.6 Both End Hosts behind same NAT . . . . . . . . . . . . . . 15 67 2.1.7 IPv4/v6 NAT with two private networks . . . . . . . . . . 16 68 2.2 Trust Relationship and Authorization . . . . . . . . . . . 17 69 2.2.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . . . 17 70 2.2.2 Intra-Domain Trust Relationship . . . . . . . . . . . . . 18 71 2.2.3 End-to-Middle Trust Relationship . . . . . . . . . . . . . 19 73 3. Problems and Challenges . . . . . . . . . . . . . . . . . 21 74 3.1 Missing Network-to-Network Trust Relationship . . . . . . 21 75 3.2 End-to-end significance . . . . . . . . . . . . . . . . . 22 76 3.3 Relationship with routing . . . . . . . . . . . . . . . . 22 77 3.4 Dynamic state installation and maintenance . . . . . . . . 22 78 3.5 Affected Parts of the Network . . . . . . . . . . . . . . 22 79 3.6 NSIS backward compatibility with NSIS unaware NAT and 80 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 23 81 3.7 Authentication and Authorization . . . . . . . . . . . . . 24 82 3.8 Directional Properties . . . . . . . . . . . . . . . . . . 24 83 3.9 Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 24 84 3.10 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 25 85 3.11 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 25 86 3.12 Route changes . . . . . . . . . . . . . . . . . . . . . . 25 87 3.13 Combining Middlebox and QoS signaling . . . . . . . . . . 26 88 3.14 Difference between sender- and receiver-initiated 89 signaling . . . . . . . . . . . . . . . . . . . . . . . . 26 90 3.15 Inability to know the scenario . . . . . . . . . . . . . . 26 92 4. NSIS NAT Handling Solution . . . . . . . . . . . . . . . . 28 93 4.1 Problem Description . . . . . . . . . . . . . . . . . . . 28 94 4.2 Solution Overview . . . . . . . . . . . . . . . . . . . . 31 95 4.2.1 Destination IP address Selection . . . . . . . . . . . . . 33 97 5. Protocol Description . . . . . . . . . . . . . . . . . . . 35 98 5.1 Basic protocol overview . . . . . . . . . . . . . . . . . 35 99 5.2 NATFW NSLP Header . . . . . . . . . . . . . . . . . . . . 37 100 5.3 NATFW NSLP Objects . . . . . . . . . . . . . . . . . . . . 37 101 5.3.1 NATFW NSLP Object Header . . . . . . . . . . . . . . . . . 37 102 5.3.2 NATFW Session ID Object . . . . . . . . . . . . . . . . . 38 103 5.3.3 Lifetime Object . . . . . . . . . . . . . . . . . . . . . 38 104 5.3.4 Policy Rule Object . . . . . . . . . . . . . . . . . . . . 38 105 5.3.5 External Address Object . . . . . . . . . . . . . . . . . 39 106 5.4 Request Message Formats . . . . . . . . . . . . . . . . . 39 107 5.4.1 Create Session . . . . . . . . . . . . . . . . . . . . . . 40 108 5.4.2 Prolong Session . . . . . . . . . . . . . . . . . . . . . 40 109 5.4.3 Delete Session . . . . . . . . . . . . . . . . . . . . . . 40 110 5.4.4 Reserve External Address . . . . . . . . . . . . . . . . . 40 111 5.5 Response Messages . . . . . . . . . . . . . . . . . . . . 41 112 5.5.1 Return External Address Response . . . . . . . . . . . . . 41 113 5.5.2 Path Succeeded Response . . . . . . . . . . . . . . . . . 42 114 5.5.3 Error Response Messages . . . . . . . . . . . . . . . . . 42 115 5.6 Protocol Operations . . . . . . . . . . . . . . . . . . . 42 116 5.6.1 Message Handling Overview . . . . . . . . . . . . . . . . 42 117 5.6.1.1 Reserving Addresses . . . . . . . . . . . . . . . . . . . 44 118 5.6.1.2 Creating Sessions . . . . . . . . . . . . . . . . . . . . 46 119 5.6.1.3 Prolonging Session . . . . . . . . . . . . . . . . . . . . 47 120 5.6.1.4 Deleting Sessions . . . . . . . . . . . . . . . . . . . . 48 122 6. Solution examples . . . . . . . . . . . . . . . . . . . . 50 123 6.1 Firewall traversal . . . . . . . . . . . . . . . . . . . . 50 124 6.2 NAT with private network on sender side . . . . . . . . . 51 125 6.3 NAT with private network on receiver side . . . . . . . . 52 126 6.4 Both end hosts are in same private network behind NATs . . 56 127 6.5 IPv4/v6 NAT with two private networks . . . . . . . . . . 58 128 6.6 Full example for NAT/FW with two private networks . . . . 58 130 7. NSIS NAT and Firewall transitions issues . . . . . . . . . 65 132 8. Security Considerations . . . . . . . . . . . . . . . . . 66 134 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 68 136 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . 69 138 Normative References . . . . . . . . . . . . . . . . . . . 70 140 Informative References . . . . . . . . . . . . . . . . . . 71 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 72 144 A. Inter-working of SIP with NSIS NATFW NSLP . . . . . . . . 74 145 A.1 The Session Initiation Protocol . . . . . . . . . . . . . 74 146 A.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 79 148 B. Ad-Hoc networks . . . . . . . . . . . . . . . . . . . . . 80 150 C. Interworking of Security Mechanisms and NSIS NATFW NSLP . 81 152 D. Solution approaches in case of missing authorization . . . 82 153 D.1 Solution Approach: Local authorization from both end 154 points . . . . . . . . . . . . . . . . . . . . . . . . . . 82 155 D.2 Solution Approach: Access Network-Only Signaling . . . . . 83 156 D.3 Solution Approach: Authorization Tokens . . . . . . . . . 83 158 E. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 86 160 Intellectual Property and Copyright Statements . . . . . . 87 162 1. Introduction 164 Firewalls and Network Address Translators (NAT) have been both used 165 throughout the Internet for many years and they will be present in 166 future. Using firewalls brings security to networks and in times of 167 IPv4 address depletion NATs virtually extend IP address space. In 168 general, both types are obstacles to many applications, since they 169 only allow specific applications to traverse them (i.e. HTTP 170 traffic). Other applications, as for instance IP telephony, with 171 more dynamic properties suffer from firewalls and NATs so that they 172 don't work at all. Therefore, many applications cannot traverse any 173 kind of firewall or NAT. 175 Several solutions to enable any application to traverse those boxes 176 have been proposed and are currently used. Typically, application 177 level gateways (ALG) have been integrated and so configuring 178 firewalls and NATs dynamically. Another approach is middlebox 179 communication (MIDCOM, currently under standardization at the IETF). 180 In this approach firewall and NAT external ALGs configure them via 181 the MIDCOM protocol [6]. Several other work around solutions are 182 available as well. Anyway, all of these approaches introduce other 183 problems that are hard to solve; one of them is dependency on 184 topology issues. 186 NAT and firewall (NATFW) signaling share a property with Quality of 187 Service (QoS) signaling, i.e. in both cases it is needed to reach any 188 device on the data path that is involved in QoS or NATFW treatment of 189 data packets. Currently, RSVP [13] is used for QoS signaling, but 190 the conception of a new IP signaling protocol is under work in the 191 Next Step of Signaling (NSIS) working group. This new signaling 192 protocol is path-coupled, like RSVP is, and its primary use is QoS 193 signaling, but NATFW signaling is considered as well. 195 This memo defines this NATFW path-coupled protocol. The NATFW 196 signaling protocol is carried over the NSIS Network Transport Layer 197 Protocol (NTLP, [3]) as NATFW NSIS Signaling Layer Protocol (NSLP). 198 This NATFW NSLP is used to open pin-holes in firewalls and create NAT 199 address mappings along the data path, so that subsequent data packets 200 can traverse those devices. 202 Traversal of non NATFW NSLPs or the NTLP is out of scope of this 203 document. Furthermore, only firewalls and NATs are considered in 204 this document, any other device, for instance IPSec security gateway, 205 is out of scope. 207 Section 2 describes the network environment for NATFW NSLP signaling 208 and highlights the trust relationship/ authorization. Problems and 209 challenges are listed in section 3, whereas a NSIS NAT handling 210 solution is described in section 4. Section 5 describes the protocol 211 itself and section 6 gives some usage examples. 213 Readers are recommended to read the NSIS framework [1] and 214 requirements documents beforehand [2]). 216 1.1 Terminology and Abbreviations 218 This document uses terms defined in [2]. Furthermore, these following 219 terms are used: 221 o NSIS NAT Forwarding State: The term "NSIS NAT Forwarding State" in 222 this context refers to a state used to forward the NSIS signaling 223 message beyond the targeted destination address; that state is 224 typically used when the NSIS Responder address is not known 226 o Sender-/Receiver Initiated Signaling 228 Sender-initiated: NAT bindings and firewall rules are created 229 immediately when the "path" message hits the NSIS nodes. With 230 "path" message we refer to the signaling message traveling from 231 the data sender towards the data receiver. 233 Receiver-initiated: NAT bindings and firewall rules are created 234 when the "reserve" message returns from the other end. With 235 "reserve" message we refer to a signaling message on the 236 reverse path, this means from the receiver to the sender (i.e. 237 backwards routed). 239 Note that these definitions have nothing to do with number of 240 roundtrips, who performs authorization etc. 242 o Policy rule: In general, a policy rule is "a basic building block 243 of a policy-based system. It is the binding of a set of actions 244 to a set of conditions - where the conditions are evaluated to 245 determine whether the actions are performed." [RFC3198]. In the 246 context of NSIS NATFW NSLP the condition is a specification of a 247 set of packets to which rules are applied. The set of actions 248 always contains just a single element per rule, and is limited to 249 either action "reserved" or action "enable". 251 o Firewall: A packet filtering device that matches packet against a 252 set of policy rules and applies the actions. In the context of 253 NSIS NATFW NSLP we refer to this device as firewall. 255 o Network Address Translator: Network Address Translation is a 256 method by which IP addresses are mapped from one realm to another, 257 in an attempt to provide transparent routing to hosts (see [8]). 259 Network Address Translator are devices that perform this method. 261 o Middlebox: from [11]: "A middlebox is defined as any intermediate 262 device performing functions other than the normal, standard 263 functions of an IP router on the datagram path between a source 264 host and a destination host". The term middlebox in context of 265 this document and in NSIS refers to firewalls and NATs only. 266 Other types of middlebox are currently outside the scope. 268 o Security Gateway: IPsec based gateways. 270 o NSIS Initiator (NI): the signaling entity which makes the resource 271 request, usually as a result of user application request. 273 o NSIS Responder (NR): the signaling entity that acts as the final 274 destination for the signaling and can optionally interact with 275 applications as well. 277 o NSIS Forwarder (NF): the signaling entity between an NI and NR 278 which propagates NSIS signaling further through the network. 280 o Receiver (DR or R): the node in the network which is receiving the 281 data packets of a flow. 283 o Sender (DS or S): the node in the network which is sending the 284 data packets of a flow. 286 o NATFW NSLP session: Application layer flow of information for 287 which some network control state information is to be manipulated 288 or monitored (as defined in [1]). The control state for NATFW NSLP 289 is NSLP state and associated policy rules at the middlebox. 291 o NSIS peer or peer: NSIS node with which a NSIS adjacency has been 292 created as defined in [3]. 294 o Edge NAT: By edge NAT we refer to the NAT device which is 295 reachable from outside and has a globally routable IP address. 297 1.2 Middleboxes 299 The term middlebox raises different expectations about functionality 300 provided by such a device. Middleboxes in the scope of this memo are 301 firewalls that filter data packets against their set of filter rules 302 and NATs that translate addresses from one address realm to another 303 address realm. Other types of middleboxes, for instance QoS traffic 304 shapers and security gateways, are out of scope. 306 The term NAT used in this document is placeholder for a range of 307 different NAT flavors. We consider those types of NATs: 309 o traditional NAT (basic NAT and NAPT) 311 o Bi-directional NAT 313 o Twice-NAT 315 o Multihomed NAT 317 For a detailed discussion about each NAT type please see [7]. 319 Both types of middleboxes use policy rules for decision on data 320 packet treatment. Policy rules consist of a 5-tuple and an 321 associated action; Data packets matching this 5-tuple experience the 322 policy rule action. A 5-tuple consists of: 324 o Source IP address and port number 326 o Destination IP address and port number 328 o Transport protocol 330 Actions for firewalls are usually: 332 o Allow: forward data packet 334 o Deny: block data packet and discard it 336 o Other actions like logging, diverting, etc 338 Actions for NATs are (amongst many others): 340 o Change source IP address and port number to an global routeable IP 341 address and port number. 343 o Change destination IP address and port number to a private IP 344 address and port number. 346 The exact implementation of policy rules and mapping to firewall rule 347 sets and NAT bindings or sessions at the middlebox is an 348 implementation issue and thus out of scope of this document. 350 Some devices entitled as firewalls only accept traffic after 351 cryptographic verification (i.e. IPsec protected data traffic). 352 Particularly for network access scenarios either link layer or 353 network layer data protection is common. Hence we do not address 354 these types of devices (referred as security gateways) since per-flow 355 signaling is rather uncommon in this environment. For a discussion 356 of network access authentication and associated scenarios the reader 357 is referred to the PANA working group (see [22]). 359 Discovering security gateways, which was also mentioned as an 360 application for NSIS signaling, for the purpose of executing an IKE 361 to create an IPsec SA, is already solved without requiring NSIS. 363 In mobility scenarios an often experienced problem is the traversal 364 of a security gateway at the edge of the corporate network. Network 365 administrators often rely on the policy that only authenticated data 366 traffic is allowed to enter the network. A problem statement for the 367 traversal of these security gateways in the context of Mobile IP can 368 be found at [21]). 370 Other proposals for path-coupled NAT and firewall traversal like RSVP 371 and CASP are described in [23] and [24]. 373 1.3 General Scenario for NATFW Traversal 375 The purpose of NSIS NATFW signaling is to enable any communication 376 between endpoints across networks even in presence of middleboxes. It 377 is expected that those middleboxes are configured in such a way that 378 NSIS NATFW signaling messages itself are allowed to traverse them. 379 NSIS NATFW NSLP signaling is used to install such policy rules in all 380 middleboxes along the data path. Firewalls are configured to forward 381 data packets matching the policy rule provided by the NSLP signaling. 382 NATs are configured to translate data packets matching the policy 383 rule provided by the NSLP signaling. 385 The basic high-level picture of NSIS usage is that endhosts are 386 located behind middleboxes (NAT/FW in Figure 1). Applications located 387 at these endhosts try to establish communication between them and use 388 NSIS NATFW NSLP signaling to establish policy rules on a data path, 389 which allows the said data to travel from the endhost to the endpoint 390 unobstructed. The applications can somehow trigger middlebox 391 traversal (e.g. via an API call) at the NSIS agent at the local host. 393 Application Application Server (0, 1, or more) Application 395 +----+ +----+ +----+ 396 | +------------------------+ +------------------------+ | 397 +-+--+ +----+ +-+--+ 398 | | 399 | NSIS Agents | 400 +-+--+ +----+ +-----+ +-+--+ 401 | +--------+ +----------------------------+ +-----+ | 402 +-+--+ +-+--+ +--+--+ +-+--+ 403 | | ------ | | 404 | | //// \\\\\ | | 405 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 406 | | | | | Internet | | | | | 407 | +--------+ +-----+ +----+ +-----+ | 408 +----+ +----+ |\ | +----+ +----+ 409 \\\\ ///// 410 sender NAT/FW (1+) ------ NATFW (1+) receiver 412 Figure 1: Generic View on NSIS in a NAT / Firewall case 414 For running NATFW signaling it is necessary that each firewall and 415 each NAT involved in the signaling communication runs an NSIS NATFW 416 agent. There might be several NATs and FWs in various possible 417 combinations on a path between two hosts. The reader is referred to 418 Section 2.1 where different scenarios are presented. 420 2. Network Environment 422 2.1 Network Scenarios for Protocol Functionality 424 This section introduces several scenarios for middleboxes in the 425 Internet. Middleboxes are located in different locations, i.e. at 426 Enterprise network borders, within enterprise networks, mobile phone 427 network gateways, etc. In general, middleboxes are place more 428 towards the edge of networks and less in network cores. Those 429 middleboxes are not only either firewall or NAT, but any type of 430 combination is possible. Thus, combined firewall and NATs are 431 available. 433 NSIS NATFW NSLP signaling messages are sent by the NSIS initiator 434 (NI) via the regular data path to the NSIS responder (NR). On the 435 data path NATFW NSLP signaling messages reach different NSIS peers 436 that have the NATFW NSLP implemented. Each NATFW NSLP node processes 437 the signaling messages according to Section 5 and installs, if 438 necessary, policy rules for subsequent data packets. 440 Each following section introduces a different scenario for a 441 different set of middleboxes and their ordering within the topology. 442 It is assumed that each middlebox implements the NSIS NATFW NSLP 443 signaling protocol. 445 2.1.1 Firewall traversal 447 This section describes a scenario with firewalls only, no NATs are 448 involved. Both end hosts are behind a firewall that are connected 449 via the public Internet. Figure 2 shows the topology. The part 450 labeled "public" is the Internet connection both firewalls. 452 +----+ //----\\ +----+ 453 NI -----| FW |---| |------| FW |--- NR 454 +----+ \\----// +----+ 456 private public private 458 FW: Firewall 459 NI: NSIS Initiator 460 NR: NSIS Responder 462 Figure 2: Firewall Traversal Scenario 464 Each firewall on-path must provide traversal service for NATFW NSLP 465 in order to permit the NSIS message to reach the other end host. All 466 firewalls process NSIS signaling and establish appropriate policy 467 rules, so that the required data packet flow can traverse them. 469 The difference between this scenario and the following is that only 470 firewalls are on the path, but no NATs. This has specific 471 implication concerning the used destination address for path-coupled 472 signaling message sent by the NSIS initiator to an NSIS responder 473 hosted behind a NAT. 475 2.1.2 NAT with two private Networks 477 Figure 3 shows a scenario with NATs at both ends of the network. 478 Therefore, each application instance, NSIS initiator and NSIS 479 responder are behind NATs. The outermost NAT at each side is 480 connected to the public Internet. The NATs are labeled as MB (for 481 middlebox), since those devices implement at least NAT-only, but can 482 implement firewalling as well. 484 Only two middleboxes MB are shown in Figure 3 at each side, but in 485 general more than one MB on each side must be considered. 487 +----+ +----+ //----\\ +----+ +----+ 488 NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR 489 +----+ +----+ \\----// +----+ +----+ 491 private public private 493 MB: Middlebox 494 NI: NSIS Initiator 495 NR: NSIS Responder 497 Figure 3: NAT with two private networks Scenario 499 Signaling traffic from NI to NR has to traverse all four middleboxes 500 on the path and all four middleboxes must be configured properly to 501 allow NSIS signaling to traverse. The NATFW signaling must configure 502 all middleboxes and consider any address translation in further 503 signaling. The sender (NI) has to know the IP address of the receiver 504 (NR) in advance, otherwise he cannot send a single NSIS signaling 505 message towards the responder. Note that this IP address is not the 506 private IP address of the responder. Instead a NAT binding 507 (including a public IP address) has to be obtained from the NAT which 508 subsequently allows packets hitting the NAT to be forwarded to the 509 receiver within the private address realm. This generally requires 510 further support from an application layer protocol for the purpose of 511 discovering and exchanging information. The receiver might have a 512 number of ways to learn its public IP address and port number and 513 might need to signal this information to the sender using the 514 application level signaling protocol. 516 2.1.3 NAT with private network on sender side 518 This scenario shows an application instance at the sending node which 519 is behind one or more NATs (shown as MB). The receiver is located in 520 the public Internet. 522 +----+ +----+ //----\\ 523 NI --| MB |-----| MB |---| |--- NR 524 +----+ +----+ \\----// 526 private public 528 MB: Middlebox 529 NI: NSIS Initiator 530 NR: NSIS Responder 532 Figure 4: NAT with private network on sender scenario 534 The traffic from NI to NR has to traverse only middleboxes on the 535 sender's side. The receiver has a public IP address. The NI sends 536 its signaling message directly to the address of the NSIS responder. 537 Middleboxes along the path intercept the signaling messages and 538 configure the policy rules accordingly. 540 Note that the data sender does not necessarily know whether the 541 receiver is behind a NAT or not, hence, it is the receiving side that 542 has to detect the whether it is behind a NAT or not. As described in 543 Section 4 NSIS can also provide help for this procedure. 545 2.1.4 NAT with private network on receiver side 547 The application instance receiving data is behind one or more NATs. 549 //----\\ +----+ +----+ 550 NI ---| |---| MB |-----| MB |--- NR 551 \\----// +----+ +----+ 553 public private 555 MB: Middlebox 556 NI: NSIS Initiator 557 NR: NSIS Responder 559 Figure 5: NAT with private network on receiver Scenario 561 First, the sender must determine the public IP address of the 562 receiver. One possibility is that an application level protocol is 563 used. In this case, the receiver must first fix its public IP 564 addresses at the middlebox on its side. This information about IP 565 address and port number could be signaled via an application level 566 protocol to the actual sender directly or indirectly via a third 567 party (e.g. proxy). In the scenario, this means the receiver has 568 first to determine its public IP address (NAT binding) and register 569 this address with a third party. 571 The NSIS initiator can start NSIS signaling after he has received 572 information about the receiver's public IP address and port number. 574 2.1.5 Both End Hosts behind twice-NATs 576 This is a special case, where the main problem is to detect that both 577 nodes are logically within the same address space, also behind a 578 twice-NAT (see [7] for discussion about twice-NAT functionality). 579 This scenario primarily addresses performance aspects. 581 Sender and receiver are both within a private address realm and 582 potentially have overlapping IP addresses. Figure 6 shows the 583 ordering of NATs. This is a common configuration in several 584 networks, particularly after the merging of companies that have use 585 the same address space, thus having overlapping addresses in many 586 cases. 588 public 589 +----+ +----+ //----\\ 590 NI --| MB |--+--| MB |---| | 591 +----+ | +----+ \\----// 592 | 593 | +----+ 594 +--| MB |------------ NR 595 +----+ 597 private 599 MB: Middlebox 600 NI: NSIS Initiator 601 NR: NSIS Responder 603 Figure 6: NAT to public, sender and receiver behind twice-NAT 604 Scenario 606 The middleboxes shown in Figure 6 are twice-NATs, i.e. they map IP 607 addresses and port numbers on both sides, at private and public 608 interfaces. 610 This scenario requires assistance of application level entities, like 611 DNS server. Those application level gateways must handle request 612 that are based on symbolic names and configure the middleboxes so 613 that data packets are correctly forwarded from NI to NR. The 614 configuration of those middleboxes may require other middlebox 615 communication protocols, like MIDCOM [6]. NSIS signaling is not 616 required in the twice-NAT only case, since the middleboxes of type 617 twice-NAT are configured by other means. Nevertheless, NSIS 618 signaling might by useful when there are firewalls in between. In 619 this case NSIS will not configure any policy rule at twice-NATs, but 620 will configure policy rules at the intermediate firewalls. The NSIS 621 signaling protocol must be at least robust enough to survive this 622 scenario. 624 2.1.6 Both End Hosts behind same NAT 626 When NSIS initiator and NSIS responder are behind the same NAT (thus 627 being in the same address realm, see Figure 7) , they are most likely 628 not aware of this fact. As in Section 2.1.4 the NSIS responder must 629 determine its public IP address in advance and transfer it to the 630 NSIS initiator. Afterwards, the NSIS initiator can start sending the 631 signaling messages to the responder's public IP address. During this 632 process, a public IP address will be allocated for the NSIS initiator 633 at the same middlebox as for the responder. Now, the NSIS signaling 634 and the subsequent data packets will traverse the NAT twice: from 635 initiator to public IP address of responder (first time) and from 636 public IP address of responder to responder (second time). This is 637 the worst case, both sender and receiver obtain a public IP address 638 at the NAT and the communication path is not optimal anymore. 640 NI public 641 \ +----+ //----\\ 642 +-| MB |----| | 643 / +----+ \\----// 644 NR 645 private 647 MB: Middlebox 648 NI: NSIS Initiator 649 NR: NSIS Responder 651 Figure 7: NAT to public, both host behind same NAT 653 NSIS NATFW signaling protocol should support mechanisms to detect 654 such a scenario. The signaling should directly by exchanged between 655 NI and NR without involving the middlebox. 657 2.1.7 IPv4/v6 NAT with two private networks 659 This scenario combines the usage case mentioned in Section 2.1.2 660 with the IPv4 to IPv6 transition scenario, i.e. using Network Address 661 and Protocol Translators (NAT-PT, [10]). 663 The difference to the other scenarios is the use of IPv6 to IPv4 (and 664 vice versa) address and protocol translation. Additionally, the base 665 NTLP must take care of this case for its own functionality of 666 forwarding messages between NSIS peers. 668 +----+ +----+ //---\\ +----+ //---\\ +----+ +----+ 669 NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR 670 +----+ +----+ \\---// +----+ \\---// +----+ +----+ 672 private public public private 673 IPv4 IPv6 675 MB: Middlebox 676 NI: NSIS Initiator 677 NR: NSIS Responder 679 Figure 8: IPv4/v6 NAT with two private networks 681 This scenario needs the same type of application level support as 682 described in Section 2.1.5 and so those issues of twice-NATs apply 683 here as well. 685 2.2 Trust Relationship and Authorization 687 Trust relationships and authorization are very important for the 688 protocol machinery. Trust and authorization are closely related to 689 each other in the sense that a certain degree of trust is required to 690 authorize a particular action. For any action (e.g. "create/delete / 691 prolong policy rules" then authorization is very important due to the 692 nature of middleboxes. 694 It is particularly not surprising that different degrees of required 695 authorization in a QoS signaling environment and middlebox signaling 696 exist. As elaborated in [19], establishment of a financial 697 relationship is very important for QoS signaling, whereas for 698 middlebox signaling is not directly of interest. For middlebox 699 signaling a stronger or weaker degree of authorization might be 700 needed. 702 Different trust relationships that appear in middlebox signaling 703 environments are described in the subsequent sections. Peer-to-peer 704 trust relationships are those, which are used in QoS signaling today 705 and seem to be the simplest. However, there are reasons to believe 706 that this is not the only type of trust relationship found in today's 707 networks. 709 2.2.1 Peer-to-Peer Trust Relationship 711 Starting with the simplest scenario it is assumed that neighboring 712 nodes trust each other. The required security association to 713 authenticate and to protect a signaling message is either available 714 (manual configuration) or dynamically established with the help of an 715 authentication and key exchange protocol. If nodes are located 716 closely together it is assumed that security association 717 establishment is easier than establishing it between far distant 718 node. It is, however, difficult to describe this relationship 719 generally due to the different usage scenarios and environments. 720 Authorization heavily depends on the participating entities but for 721 this scenario it is assumed that neighboring entities trust each 722 other (at least for the purpose of policy rule creation, maintenance 723 and deletion). Note that Figure 9 does not illustrate the trust 724 relationship between the end host and the access network. 726 +------------------------+ +-------------------------+ 727 | | | | 728 | Network A | | Network B | 729 | | | | 730 | +---------+ +---------+ | 731 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 732 | | | box 1 | Trust | box 2 | | | 733 | | +---------+ Relationship +---------+ | | 734 | | | | | | 735 | | | | | | 736 | | | | | | 737 | | Trust | | Trust | | 738 | | Relationship | | Relationship | | 739 | | | | | | 740 | | | | | | 741 | | | | | | 742 | +--+---+ | | +--+---+ | 743 | | Host | | | | Host | | 744 | | A | | | | B | | 745 | +------+ | | +------+ | 746 +------------------------+ +-------------------------+ 748 Figure 9: Peer-to-Peer Trust Relationship 750 2.2.2 Intra-Domain Trust Relationship 752 In larger corporations often more than one middlebox is used to 753 protect different departments. In many cases the entire enterprise is 754 controlled by a security department, which gives instructions to the 755 department administrators. In such a scenario a peer-to-peer 756 trust-relationship might be prevalent. Sometimes it might be 757 necessary to preserve authentication and authorization information 758 within the network. As a possible solution a centralized approach 759 could be used whereby an interaction between the individual 760 middleboxes and a central entity (for example a policy decision point 761 - PDP) takes place. As an alternative individual middleboxes could 762 exchange the authorization decision to another middlebox within the 763 same trust domain. Individual middleboxes within an administrative 764 domain should exploit their trust relationship instead of requesting 765 authentication and authorization of the signaling initiator again and 766 again. Thereby complex protocol interaction is avoided. This 767 provides both a performance improvement without a security 768 disadvantage since a single administrative domain can be seen as a 769 single entity. Figure 10 illustrates a network structure which uses 770 a centralized entity. 772 +-----------------------------------------------------------+ 773 | | 774 | Network A | 775 | | 776 | | 777 | +---------+ +---------+ 778 | +----///--------+ Middle- +------///------++ Middle- +--- 779 | | | box 2 | | box 2 | 780 | | +----+----+ +----+----+ 781 | | | | | 782 | +----+----+ | | | 783 | | Middle- +--------+ +---------+ | | 784 | | box 1 | | | | | 785 | +----+----+ | | | | 786 | | | | | | 787 | - | | | | 788 | - | +----+-----+ | | 789 | | | | Policy | | | 790 | +--+---+ +-----------+ Decision +----------+ | 791 | | Host | | Point | | 792 | | A | +----------+ | 793 | +------+ | 794 +-----------------------------------------------------------+ 796 Figure 10: Intra-domain Trust Relationship 798 2.2.3 End-to-Middle Trust Relationship 800 In some scenarios a simple peer-to-peer trust relationship between 801 participating nodes is not sufficient. Network B might require 802 additional authorization of the signaling message initiator. If 803 authentication and authorization information is not attached to the 804 initial signaling message then the signaling message arriving at 805 Middlebox 2 would cause an error message to be created, which 806 indicates the additional authorization requirement. In many cases the 807 signaling message initiator is already aware of the additionally 808 required authorization before the signaling message exchange is 809 executed. Replay protection is a requirement for authentication to 810 the non-neighboring middlebox which might be difficult to accomplish 811 without adding additional roundtrips to the signaling protocol (e.g. 812 by adding a challenge/response type of message exchange). 814 Figure 11 shows the slightly more complex trust relationships in this 815 scenario. 817 +----------------------+ +--------------------------+ 818 | | | | 819 | Network A | | Network B | 820 | | | | 821 | | Trust | | 822 | | Relationship | | 823 | +---------+ +---------+ | 824 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 825 | | | box 1 | +-------+ box 2 | | | 826 | | +---------+ | +---------+ | | 827 | | | | | | | 828 | |Trust | | | | | 829 | |Relationship | | | | | 830 | | | | | Trust | | 831 | | | | | Relationship| | 832 | | | | | | | 833 | | | | | | | 834 | | | | | | | 835 | | | | | | | 836 | +--+---+ | | | +--+---+ | 837 | | Host +----///----+------+ | | Host | | 838 | | A | |Trust | | B | | 839 | +------+ |Relationship | +------+ | 840 +----------------------+ +--------------------------+ 842 Figure 11: End-to-Middle Trust Relationship 844 3. Problems and Challenges 846 This section describes a number of problems which have to be 847 addressed for NSIS NAT/Firewall. These might be also of relevance to 848 other NSLP protocols. 850 3.1 Missing Network-to-Network Trust Relationship 852 Peer-to-peer trust relationship, as shown in Figure 9, is a very 853 convenient assumption that allows simplified signaling message 854 processing. However, it might not always be applicable, especially 855 between two arbitrary access networks (over a core network where 856 signaling messages are not interpreted). Possibly peer-to-peer 857 trust relationship does not exist because of the large number of 858 networks and the unwillingness of administrators to have other 859 network operators to create holes in their firewalls without proper 860 authorization. Hence in the following scenario we assume a somewhat 861 different message processing and show three possible approaches to 862 tackle the problem. None of these three approaches is without 863 drawbacks or constraining assumptions. 865 +----------------------+ +--------------------------+ 866 | | | | 867 | Network A | | Network B | 868 | | | | 869 | +---------+ Missing +---------+ | 870 | +-///-+ Middle- | Trust | Middle- +-///-+ | 871 | | | box 1 | Relation- | box 2 | | | 872 | | +---------+ ship +---------+ | | 873 | | | or | | | 874 | | | Authorization| | | 875 | | | | | | 876 | | Trust | | Trust | | 877 | | Relationship | | Relationship | | 878 | | | | | | 879 | | | | | | 880 | | | | | | 881 | +--+---+ | | +--+---+ | 882 | | Host | | | | Host | | 883 | | A | | | | B | | 884 | +------+ | | +------+ | 885 +----------------------+ +--------------------------+ 887 Figure 12: Missing Network-to-Network Trust Relationship 889 Figure 12 illustrates a problem whereby an external node is not 890 allowed to manipulate (create, delete, query, etc.) packet filters at 891 a firewall. Opening pinholes is only allowed for internal nodes or 892 with a certain authorization permission. Hence the solution 893 alternatives in Section 4 focus on establishing the necessary trust 894 with cooperation of internal nodes. 896 3.2 End-to-end significance 898 In the case of NAT/firewalls traversal, the NSIS signaling messages 899 need to be sent all they way from the DS and DR or vice versa. This 900 is so because a middlebox does not know whether the remaining path to 901 the destination is clear of potentially obstructing middleboxes or 902 not. 904 3.3 Relationship with routing 906 The data path is following the "normal" routes. The NAT/FW devices 907 along the data path are those providing the service. In this case 908 the service is something like "open a pinhole" or even more general 909 "allow for connectivity between two communication partners". The 910 benefit of using path-coupled signaling is that the NSIS NATFW NSLP 911 does not need to determine what middleboxes or in what order the data 912 flow will go through. 914 Creating NAT bindings modifies the path of data packets between two 915 end points. Without NATs involved, packets flow from endhost to 916 endhost following the path given by the routing. With NATs involved, 917 this end-to-end flow is not directly possible, because of separated 918 address realms. Thus, data packets flow towards the external IP 919 address at a NAT (external IP address may be a public IP address). 920 Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with 921 routing - instead they only follow the path of the data packets. 923 3.4 Dynamic state installation and maintenance 925 For NAT/Firewall traversal, the lifetime of a NAT binding or a packet 926 filter is maintained through periodic refresh. For short-lived 927 flows, having unpredictable filters, signaling for dynamically policy 928 rules is preferable as opposed to statically configured policy rules 929 requested for long duration in time. 931 For static state other mechanisms than an NSIS signaling protocol 932 might be preferable; such mechanisms would include a management 933 protocols such as SNMP or command line interfaces. 935 3.5 Affected Parts of the Network 937 NATs and Firewalls are usually located at the edge of the network, 938 whereby other signaling applications affect all nodes along the path. 939 One typical example is QoS signaling where all networks along the 940 path must provide QoS in order to achieve true end-to-end QoS. In 941 the NAT/Firewall case, only some of the domains/nodes are affected 942 (typically access networks), whereas most parts of the networks and 943 nodes are unaffected (e.g. the core network). 945 This fact raises some questions. Should an NSIS NTLP node intercept 946 every signaling message independently of the upper layer signaling 947 application or should it be possible to make the discovery procedure 948 more intelligent to skip nodes. These questions are also related to 949 the question whether NSIS NAT/FW should be combined with other NSIS 950 signaling applications. 952 3.6 NSIS backward compatibility with NSIS unaware NAT and Firewalls 954 Backward compatibility is a key for NSIS deployments, as such the 955 NSIS protocol suite should be sufficiently robust to allow traversal 956 of none NSIS aware routers (QoS gates, Firewalls, NATs, etc ). 958 NSIS NATFW NSLP's backward compatibility issues is different than the 959 NSIS QoS NSLP backward compatibility issues, where an NSIS unaware 960 QoS gate will simply forward the QoS NSLP message. An NSIS unaware 961 firewall rejects NSIS messages, since firewalls typically implement 962 the policy "default to deny". 964 The NSIS backward compatibility support on none NSIS aware firewall 965 would typically consist of configuring a static policy rule that 966 allows the forwarding of the NSIS protocol messages (either protocol 967 type if raw transport mode is used or transport port number in case a 968 transport protocol is used). 970 For NATs backward compatibility is more problematic since signaling 971 messages are forwarded (at least in one direction), but with a 972 changed IP address and changed port numbers. The content of the NSIS 973 signaling message is, however, unchanged. This can lead to 974 unexpected results, both due to embedded unchanged local scoped 975 addresses and none NSIS aware firewalls configured with specific 976 policy rules allowing forwarding of the NSIS protocol (case of 977 transport protocols are used for the NTLP). NSIS unaware NATs must 978 be detected to maintain a well known deterministic mode of operation 979 for all the involved NSIS entities. Such a "legacy" NAT detection 980 procedure can be done during the NSIS discover procedure itself. 982 Based on experience it was discovered that routers unaware of the 983 Router Alert IP option [RFC 2113] discarded packets, this is 984 certainly a problem for NSIS signaling. 986 3.7 Authentication and Authorization 988 For both types of middleboxes, firewall and NAT security is a strong 989 requirement. Authentication and authorization means must be 990 provided. 992 For NATFW signaling applications it is partially not possible to do 993 authentication and authorization based on IP addresses. Since NATs 994 change IP addresses, such a address based authentication and 995 authorization scheme would fail. 997 3.8 Directional Properties 999 There two directional properties that need to be addressed by the 1000 NATFW NSLP: 1002 o Directionality of the data 1004 o Directionality of NSLP signaling 1006 Both properties are relevant to NATFW NSLP aware NATs and Firewalls. 1008 With regards to NSLP signaling directionality: As stated in the 1009 previous sections, the authentication and authorization of NSLP 1010 signaling messages received from hosts within the same trust domain 1011 (typically from hosts located within the security perimeter delimited 1012 by firewalls) is normally simpler than received messages sent by 1013 hosts located in different trust domains. 1015 The way NSIS signaling messages enters the NSIS agent of a firewall 1016 (see Figure 2) might be important, because different policies might 1017 apply for authentication and admission control. 1019 Hosts deployed within the secured network perimeter delimited by a 1020 firewall, are protected from hosts deployed outside the secured 1021 network perimeter, hence by nature the firewall has more restrictions 1022 on flows triggered from hosts deployed outside the security 1023 perimeter. 1025 3.9 Routing Asymmetry 1027 Routing asymmetry [20] is a general problem for path-coupled 1028 signaling, especially when installed states on NSIS forwarders are 1029 related to bi-directional flows. 1031 Path state, on an NSIS forwarder, including the next NSIS hop (for 1032 packets sent from the NR to NI), is used to handle routing asymmetry 1033 for NSIS messages, but not for data flows (i.e. no route pinning for 1034 data flows). 1036 Similarly to path-coupled QoS signaling, middlebox signaling also has 1037 to be aware of the routing asymmetry when bi-directional flows 1038 relevant states need to be installed on NSIS aware nodes, although 1039 the routing asymmetry might not be significant within the local 1040 networks where firewalls are typically located. For signaling NAT 1041 bindings this issue comes with a different flavor since an 1042 established NAT binding changes the path of the data packets. Hence a 1043 data receiver might still be able to send NSIS signaling messages to 1044 create a NAT binding, although they travel the previously "wrong" 1045 path. 1047 3.10 Addressing 1049 A more general problem of NATs is the addressing of the end-point. 1050 NSIS signaling message have to be addressed to the other end host to 1051 follow data packets subsequently sent. Therefore, a public IP address 1052 of the receiver has to be known prior to sending an NSIS message. 1053 When NSIS signaling messages contain IP addresses of the sender and 1054 the receiver in the signaling message payloads, then an NSIS agent 1055 must modify them. This is one of the cases, where a NSIS aware NATs 1056 is also helpful for other types of signaling applications e.g. QoS 1057 signaling. 1059 3.11 NTLP/NSLP NAT Support 1061 It must be possible for NSIS NATs along the path to change NTLP and/ 1062 or NSLP message payloads , which carry IP address and port 1063 information. This functionality includes the support of providing 1064 mid-session and mid-path modification of these payloads. As a 1065 consequence these payloads must not be reordered, integrity protected 1066 and/or encrypted in a non peer-to-peer fashion (e.g. end-to-middle, 1067 end-to-end protection). Ideally these mutable payloads must be marked 1068 (e.g. a protected flag) to assist NATs in their effort of adjusting 1069 these payloads. 1071 3.12 Route changes 1073 The effect of route changes are more severe than in other signaling 1074 applications since a firewall pinhole and NAT binding is needed 1075 before further communication can take place. This is true for both 1076 NSIS signaling and for subsequent data traffic. If a route changes 1077 and NSIS signaling messages do not configure NSIS NATs and firewalls 1078 along the new path then the communication is temporarily interrupted. 1079 This is naturally a big problem for networks where routes frequently 1080 change e.g. ad-hoc networks or in case of fast mobility. In these 1081 cases state refresh messages have to provide a mechanism for fast 1082 reaction. 1084 3.13 Combining Middlebox and QoS signaling 1086 In many cases, middlebox and QoS signaling has to be combined at 1087 least logically. Hence, it was suggested to combine them into a 1088 single signaling message or to tie them together with the help of 1089 some sort of data connection identifier, later on referred as Session 1090 ID. This, however, has some disadvantages such as: 1092 - NAT/FW NSLP signaling affects a much small number of NSIS nodes 1093 along the path (for example compared to the QoS signaling). 1095 - NAT/FW signaling might show different signaling patterns (e.g. 1096 required end-to-middle communication). 1098 - The refresh interval is likely to be different. 1100 - The number of error cases increase as different signaling 1101 applications are combined into a single message. The combination of 1102 error cases has to be considered. 1104 3.14 Difference between sender- and receiver-initiated signaling 1106 For NAT/FW signaling there seems to be little difference between 1107 sender- and receiver-initiated signaling messages. Some other 1108 characteristics of QoS signaling protocols are not applicable (e.g. 1109 the adspec object) to the NAT/FW context. It seems that a full 1110 roundtrip is always required if the protocol aims to be generic 1111 enough. 1113 3.15 Inability to know the scenario 1115 In Section 2.1 a number of different scenarios are presented. Data 1116 receiver and sender may be located behind zero, one, or more 1117 firewalls and NATs. Depending on the scenario, different signaling 1118 approaches have to be taken. For instance, data receiver with no 1119 NAT and firewall can receive any sort of data and signaling without 1120 any further action. Data receivers behind a NAT must first obtain a 1121 public IP address before any signaling can happen. The scenario might 1122 even change over time with moving networks, ad-hoc networks or with 1123 mobility. 1125 NSIS signaling must assume the worst case and cannot put 1126 responsibility to the user to know which scenario is currently 1127 applicable. As a result, it might be necessary to perform a 1128 "discovery" periodically such that the NSIS agent at the end host has 1129 enough information to decide which scenario is currently applicable. 1131 This additional messaging, which might not be necessary in all cases, 1132 requires additional performance, bandwidth and adds complexity. 1133 Additional, information by the user can provide information to assist 1134 this "discovery" process but cannot replace it. 1136 4. NSIS NAT Handling Solution 1138 This section describes a mechanism for allowing NSIS signaling 1139 messages to travel end-to-end in the presence of NATs at the 1140 receiving side. This requires to establish state information at the 1141 NSIS-aware NAT device. 1143 Note: The discussed mechanism only creates state relevant for NSIS 1144 message handling. It does not create NAT bindings for data traffic. 1146 4.1 Problem Description 1148 NSIS signaling messages follow the data path from the data sender to 1149 the data receiver. To provide this property of being path-coupled a 1150 discovery process sends signaling messages along the same route as 1151 taken by subsequent data packets. The NSIS messages are directed to 1152 a particular destination IP address and hence the destination address 1153 needs to be known in advance before NSIS signaling can start. 1155 +-------------+ AS-Data Receiver Communication 1156 +-------->| Application |<-----------------------------+ 1157 | | Server | | 1158 | +-------------+ | 1159 | IP(R-NAT_B) | 1160 | NSIS Signaling Message +-------+--+ 1161 | +------------------------------------------>| NAT/NAPT | 1162 | | | B | 1163 | | +-------+--+ 1164 | | | 1165 AS-Data| | | 1166 Receiver| | +----------+ | 1167 Comm.| | | NAT/NAPT | | 1168 | | | A | | 1169 | | +----------+ | 1170 | | | 1171 | | | 1172 | | | 1173 | | | 1174 v | IP(R) v 1175 +--------+ +---------+ 1176 | Data | | Data | 1177 | Sender | | Receiver| 1178 +--------+ +---------+ 1180 Figure 13: The Data Receiver behind NAT problem 1182 Figure 13 describes a typical message communication in a peer-to-peer 1183 networking environment whereby the two end points learn of each 1184 others existence with the help of a third party (referred as 1185 Application Server). The communication with the application server 1186 and the two end points (data sender and data receivers) serves a 1187 number of functions. As one of the most important functions it 1188 enables the two end hosts to learn the IP address of each other. 1190 Without the proposed mechanism it would not be possible to establish 1191 a NAT binding end-to-end in all scenarios. 1193 Some sort of communication between the end hosts and a third party is 1194 typically necessary (independently of NSIS). NSIS signaling messages 1195 cannot be used to communicate application level relevant end point 1196 identifiers (in the generic case at least) as a replacement for the 1197 communication with the application server. 1199 If the data receiver is behind a NAT then an NSIS signaling message 1200 will be addressed to the IP address allocated at the NAT (if there 1201 was one allocated). If no corresponding NSIS NAT Forwarding State at 1202 NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the signaling 1203 message will terminate at the NAT device (most likely without proper 1204 response message). The signaling message transmitted by the data 1205 sender cannot install the NAT binding or NSIS NAT Forwarding State 1206 "on-the-fly" since this would assume that the data sender knows the 1207 topology at the data receiver side (i.e. the number and the 1208 arrangement of the NAT and the private IP address(es) of the data 1209 receiver). The primary goal of path-coupled middlebox communication 1210 was not to force end hosts to have this type of topology knowledge. 1212 A number of solutions exist to allow nodes behind a NAT to establish 1213 a NAT binding to allow the receiver to receive IP packets. These 1214 solutions can at best be labeled as hacks (see [NATP2P]) and they 1215 have their drawbacks: 1217 o They assume a certain behavior of NAT boxes. 1219 o They work in some environments whereas in others they do not 1220 properly function. 1222 o They only allow NAT bindings for UDP traffic to be established. 1224 o They often fail. 1226 Some other solutions assume that both nodes are registered in the DNS 1227 directory (see [12]). 1229 The requirements for an NSIS solution are two-fold: 1231 1. NSIS signaling messages must be able to travel end-to-end 1232 (between data sender and data receiver) - if desired. This is 1233 important for a number of NSIS NSLPs 1235 2. NSIS relies on a generic solution which works in all scenarios 1236 (see section 5 of [26]). 1238 Since the NSIS signaling messages are intercepted at each NSIS 1239 device, the NAT solution depends on the properties of the NTLP. In 1240 particular, multiplexing capability is important. Two possible 1241 options are feasible: 1243 1. Multiplexing with the help of transport layer information (i.e. 1244 port information) 1246 2. Multiplexing at the NSIS application layer (e.g. based on session 1247 identifier) 1249 We describe the second approach although we believe that alternatives 1250 are possible. 1252 Enough information has to be available to convert IP address 1253 information of an incoming signaling message to different IP 1254 addresses of an outgoing NSIS message. Finally the signaling message 1255 must reach the data receiver. 1257 It seems that the session identifier can be used to associate state 1258 information of the two independent signaling exchanges. The two 1259 exchanges (as described in Section 4.2) are: 1261 1. Signaling exchange from the data receiver (NR) to the NAT(s) 1263 2. End-to-end NSIS signaling message exchange from the NI to the NR. 1265 If the session identifier is used for this purpose then it is 1266 necessary to communicate the session ID from the data receiver (NR) 1267 to the NI. Communicating the IP address information instead (as an 1268 alternative solution approach) is easier since this functionality is 1269 already provided by SIP whereas securely exchanging (e.g. 1270 confidentiality protected) the Session Identifier is not available. 1272 4.2 Solution Overview 1274 The data receiver starts to signal an NSIS Create-NAT-Binding message 1275 into the "wrong direction". By "wrong" we refer to the usual 1276 behavior of path-coupled signaling where the data sender starts 1277 signaling in order to tackle with routing asymmetry. The data 1278 receiver would typically return signaling messages to the data sender 1279 in the reverse direction by utilizing state created at nodes along 1280 the path (i.e. to reverse route signaling messages). The concept of 1281 path-coupled or path-decoupled signaling is, however, no relevant for 1282 this special type of signaling communication. In case of 1283 establishing NAT bindings (and NSIS NAT Forwarding State) the 1284 direction does not matter since routing is modified. Subsequent NSIS 1285 messages (and also data traffic) will travel through the same NAT 1286 boxes. 1288 The proposed solution requires two NSIS signaling messages: 1290 1. Reserve External Address Request 1292 2. Reserve External Address Acknowledgment 1294 The semantics of the two messages will be described in detail in this 1295 section. 1297 The data receiver sends a Reserve External Address NSIS signaling 1298 message into the local network (before the data sender starts NSIS 1299 signaling). In Section Section 4.2.1 we will discuss where to address 1300 this signaling message (i.e. which destination IP address to use). 1302 The signaling message creates NSIS NAT Forwarding State at 1303 intermediate NSIS NAT node(s). Furthermore it has to be ensured that 1304 the edge NAT device is discovered as part of this process. The end 1305 host cannot be assumed to know this device - instead the NAT box 1306 itself is assumed to know that it has such a capability. Forwarding 1307 of the Reserve External Address NSIS message beyond this entity is 1308 not necessary, and should be prohibited as it provides information on 1309 internal hosts capabilities. 1311 Reserve External Address Request 1312 +-------+ +-------+ +-------+ +---------+ 1313 | NAT X |<---| NAT Y |<---| NAT Z |<---| Data | 1314 | |--->| |--->| |--->| Receiver| 1315 +-------+ +-------+ +-------+ +---------+ 1316 Reserve External Address Response 1318 ========================================> 1319 Data Traffic Direction 1321 Figure 14: Reserve External Address NSIS Signaling Message 1323 The goal of this signaling message exchange is: 1325 o to create one (or more) NAT binding(s) 1327 o to allow the data receiver to learn its global routable IP address 1328 (for communication with NSIS) 1330 o not to require the data receiver to learn topology information. 1332 Figure 14 shows a number of NAT devices at the data receivers network 1333 side. NSIS NAT Forwarding State is established at these network 1334 elements. 1336 The Reserve External Address Request message triggers the state 1337 creation and the discovery. The message carries information where the 1338 sender expects incoming NSIS signaling messages. 1340 The Reserve External Address Response message confirms the state 1341 creation and allows to return information about the NATs and the 1342 topology to the end host (for informational purposes). As a result 1343 the end host will learn the public IP address which can be used by 1344 the data sender to address NSIS signaling messages. 1346 4.2.1 Destination IP address Selection 1348 The Reserve External Address Request message has to be addressed to a 1349 specific destination IP address. Since there is no natural candidate 1350 a few alternatives might be considered. The discussed options refer 1351 to entities of Figure 13 1353 Possible options are: 1355 1. Public IP address of the data sender 1357 2. Public IP address of the data receiver (allocated at NAT B) 1359 3. IP address at the Application Server 1361 Actually, there is no "correct" answer to this question and from a 1362 theoretical point of view it does not really matter as long as Host A 1363 learns an IP address where he has to send the NSIS signaling message. 1364 From a performance point of view there is, however, a difference 1365 since it would be desirable to create an "optimal" routing path. 1367 1. Public IP address of the data sender: 1369 * Assumption: 1371 + The data receiver already learned the IP address of the 1372 data sender (e.g. via a third party). 1374 * Problems: 1376 + The data sender might also be behind a NAT. In this case 1377 the public IP address of the data receiver is the IP 1378 address allocated at this NAT. 1380 + Due to routing asymmetry it might be possible that the 1381 routes taken by a) the data sender and the application 1382 server b) the data sender and NAT B might be different. As 1383 a consequence it might be necessary to advertise a new (and 1384 different) external IP address with SIP after using NSIS to 1385 establish a NAT binding. 1387 2. Public IP address of the data receiver (allocated at NAT B): 1389 * Assumption: 1391 + The data receiver already learned his externally visible IP 1392 address (e.g. based on the third party communication). 1394 * Problems: 1396 + Communication with a third party is required. 1398 3. IP address at the Application Server: 1400 * Assumption: 1402 + An application server (or a different third party) is 1403 available. 1405 * Problems: 1407 + If the NSIS signaling message is not terminated at the NAT 1408 of the local network then an NSIS unaware application 1409 server might discard the message. 1411 + Routing might not be optimal since the route between a) the 1412 data receiver and the application server b) the data 1413 receiver and the data sender might be different. 1415 5. Protocol Description 1417 5.1 Basic protocol overview 1419 The NSIS Signaling Layer Protocol (NSLP) for NAT and FW traversal is 1420 carried over the NSIS Transport Layer Protocol (NTLP) defined in [3]. 1421 NATFW NSLP messages are initiated by the NSIS initiator, (NI) handled 1422 by NSIS forwarders (NF) and finally processed by the NSIS responder 1423 (NR). It is required that at least NI and NR implement this NSLP, 1424 intermediate NF only implement this NSLP when they provide middlebox 1425 functions. Forwarders that do not have any NATFW NSLP functions just 1426 forward these messages; those forwarders implement NTLP and one or 1427 more other NSLPs. 1429 A Data Sender (DS) that intents to send data to a Data Receiver (DR) 1430 must start its NATFW NSLP signaling. So the NI at the data sender 1431 (DR) starts NSLP signaling towards the address of data receiver DR 1432 (see Figure 15). 1434 +-------+ +-------+ +-------+ +-------+ 1435 | DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR | 1436 | |--->| NF1 |--->| NF2 |--->| | 1437 +-------+ +-------+ +-------+ +-------+ 1439 ========================================> 1440 Data Traffic Direction 1442 ---> : NATFW NSLP request signaling 1443 ~~~> : NATFW NSLP response signaling 1444 DS/NI : Data sender and NSIS initiator 1445 DR/NR : Data receiver and NSIS responder 1446 MB1 : Middlebox 1 and NSIS forwarder 1 1447 MB2 : Middlebox 2 and NSIS forwarder 2 1449 Figure 15: General NSIS signaling 1451 The NSLP request messages are processed each time a NF with NATFW 1452 NSLP support is passed. Those nodes process the message, check local 1453 policies for authorization and authentication, possibly create policy 1454 rules, and forward the signaling message to the next NSIS node. The 1455 request message is forwarded until it reaches the NSIS responder. 1456 NSIS responders will check received messages and process those if 1457 applicable. NSIS responders generate response messages and sent them 1458 back to the NI via the same chain of NFs. The response message is 1459 processed at each NI forwarder implementing NATFW NSLP. The Data 1460 Sender can start sending its data flow to the Data Receiver, when the 1461 signaling was successful, meaning that NI has received a successful 1462 response. 1464 In general, NATFW NSLP signaling follows the data path from DS to DR. 1465 This enables communication between both hosts for scenarios with only 1466 firewalls on the data path or NATs on sender side. For scenarios 1467 with NATs on the receiver side certain problems arise. 1469 When Data receiver (DR) and Data Sender (DS) are located in different 1470 address realms and DR is behind a NAT, DS cannot signal to DR. DR is 1471 not reachable from DS and thus no NATFW signaling can be sent to DR's 1472 address. Therefore, DR must first fix a address at a NAT that is 1473 reachable for DS, for instance DR must determine its public IP 1474 address. Once DR has fixed a public address it forwards this to DS 1475 via a separate mechanism, which may be application level signaling 1476 like SIP. This application level signaling may involve third parties 1477 that assist in exchanging this information. This separate mechanism 1478 is out of scope of NATFW NSLP. 1480 NATFW NSLP signaling supports this public address fixing with this 1481 mechanism: 1483 o First, DR fixes a public address by signaling on the reverse path 1484 (DR towards DS) and thus making itself available to other hosts. 1485 This process of fixing public addresses is called reservation. 1486 This way DR reserves publicly reachable addresses and ports. 1488 o Second, DS is signaling directly to DR, creating policy rules at 1489 middleboxes. Note, that the reservation mode will usually make 1490 reservations only, which will be "activated" by the signaling from 1491 DS towards DR. The first mode is detailed in the Section 4 1493 The protocol is intended to work on a soft-state basis. This means, 1494 that whatever state is installed or reserved on a middlebox, will 1495 expire, and thus be de-installed/ forgotten after a certain period of 1496 time. To prevent this the involved boxes will have to specifically 1497 request a session prolongation. An explicit NATFW NSLP state 1498 deletion message is also provided by the protocol. 1500 Middleboxes should report back in case of error, so that appropriate 1501 measures and debugging can be performed. 1503 The next sections define the NATFW NSLP message types and formats, 1504 protocol operations, and policy rule operations. 1506 5.2 NATFW NSLP Header 1508 The NATFW NSLP header is common to all messages and follows directly 1509 the NTLP header. A NSLP node can distinguish based on this header 1510 whether a request or response message is passed in the packet. It is 1511 followed by a series of objects. 1513 The NSIS NATFW NSLP header contains: 1515 o version: NSIS NATFW NSLP protocol version number. 1517 o header_len: length of the NSLP payload in bytes, including NSLP 1518 header 1520 o obj_count: number of objects that follow after the NSIS header. 1522 o message type: The type of the NSLP message, request or response. 1523 Sub-types are encoded in this field as well. 1525 Message type indicates whether the NSLP packet is a request or a 1526 response. For request messages, four sub-types are defined: 1528 o Create Session 1530 o Prolong Session 1532 o Delete Session 1534 o Reserve Session 1536 For response messages, three sub-types are defined: 1538 o Return External Address 1540 o Path Succeeded 1542 o Error 1544 The next sections define which objects are included in which message 1545 type. For each message type the allowed combination of objects is 1546 described. 1548 5.3 NATFW NSLP Objects 1550 5.3.1 NATFW NSLP Object Header 1552 NATFW NSLP objects carry the actual information about policy rules, 1553 lifetimes and error conditions. All objects share the same object 1554 header. An object header is followed by the object data, whereas the 1555 format of the object data depends on the object type. A NATFW NSLP 1556 payload may contain several objects. 1558 The object header has the following format: 1560 o obj_len: total length of the object, including object header 1562 o obj_type: type of NATFW NSLP object. Identifies the data that 1563 follows. 1565 For the moment four object types are defined in the next sections. 1566 Other objects can be defined later on. These four objects each 1567 describe a message request type. 1569 5.3.2 NATFW Session ID Object 1571 The NATFW Session ID is the handle to the NATFW session at a 1572 particular NSIS node. It is randomly generated by the NSIS 1573 initiator. 1575 5.3.3 Lifetime Object 1577 The lifetime object indicates the lifetime of a NATFW NSLP session. 1578 The real lifetime at a NSIS peer is the current time plus the 1579 lifetime value of this object. 1581 5.3.4 Policy Rule Object 1583 The policy rule objects contains the flow information for the data 1584 traffic from DS to DR. The information contained in this object will 1585 change as soon as NATs are involved. 1587 The policy rule object has these fields: 1589 o Source address: The IP address where the data will come from. If 1590 it is DS sending data to DR, the source address is either DS or 1591 the closest NAT in the route from DS to the middlebox that gets 1592 the packet; That is, the address where each middlebox will see the 1593 packet come from. 1595 o Destination address: The IP address where the data is headed. If 1596 it is DS sending data to DR, the destination address is either DR 1597 or the public address DR reserved itself. 1599 o Protocol: The protocol carried in the IP data packet. Currently 1600 TCP, UDP and IP is defined. 1602 o Source Port: The transport layer port the data will come from 1604 o Destination Port: The transport layer port the data will go to. 1606 o IPv flow label: The IPv6 flow label (Editor's note: needs further 1607 in-depth discussion). 1609 Note: you might want to leave the source address or port set to ANY, 1610 to accept any source address port. This makes the pinhole not so pin 1611 like, but might be necessary at the integration with certain NAT/FW 1612 types. Whether this loose pinhole is authorized or not by the 1613 middlebox, is a policy decision based on the middlebox configuration. 1615 5.3.5 External Address Object 1617 This object contains the reserved external address and if applicable 1618 port number. 1620 The object has these fields: 1622 o External IP address: The reserved external IP address at the NAT. 1624 o External port number: The reserved external port number at the 1625 NAT. 1627 5.4 Request Message Formats 1629 This section defines the message types and their format for the NATFW 1630 NSLP. Note, that at the moment of writing this document, no final 1631 decision has been reached on the details of the NTLP. Thus, message 1632 types and formats may change in future revisions of this document. 1634 Currently, the NATFW NSLP header and 4 request messages are defined. 1635 Furthermore, three response message types are defined. All those 1636 messages are explained in this chapter. 1638 The NATFW payload of a NSIS NTLP packet consists of a NATFW NSLP 1639 header that is common to all request, response and error messages. 1640 Several NATFW NSLP objects follow the NSLP header, depending on the 1641 message type. 1643 NOTE: Any bit-level definition of messages and headers are to be done 1644 in future revision of this memo. Furthermore, any order of object 1645 fields below is not mandating their order in the actual bit-level 1646 definition. 1648 5.4.1 Create Session 1650 The create session request message is used to create policy rules on 1651 middleboxes. Middleboxes receiving this message type will, if 1652 authenticated and authorized, enable the requested policy rules, so 1653 that data packets of the specified data flow can traverse. 1655 The create session messages carries these objects: 1657 o Session ID object: A newly generated session ID 1659 o Policy Rule object: The description of the data flow 1661 o Lifetime Object: A request lifetime for this NSIS NATFW NSLP 1662 session 1664 5.4.2 Prolong Session 1666 The prolong session request message is used to extend the lifetime of 1667 a NATFW NSLP session. The NSIS initiator requests a certain lifetime 1668 extension. 1670 The prolong session message carries these objects: 1672 o Session ID object: Session to be prolonged 1674 o Lifetime Object: Requested new lifetime 1676 5.4.3 Delete Session 1678 The delete session request message is used to delete NATFW NSLP 1679 session. 1681 The delete session object carries this object: 1683 o Session ID: The session to be deleted. 1685 5.4.4 Reserve External Address 1687 The reserve external address request message is used in the case that 1688 a Data Receiver (DR) is located behind a NAT. The DR needs to 1689 received data and so uses this request message to reserve an external 1690 IP address at a NAT. 1692 The reserve external address message carries these objects: 1694 o Session ID: The session ID for the reservation. Note that this 1695 session ID is only valid for the reservation. Create messages 1696 using the reservation will use their own generate session ID. 1698 o Lifetime: The lifetime of the reservation 1700 o Policy Rule: In the reserve external address message the policy 1701 rule object must be set accordingly: 1703 Source address: The source address of the data flow. This is 1704 the destination of the NATFW reserve address packet. The way 1705 of NSLP signaling is in the reverse way of the data flow. 1707 Source port: The source port of the data flow. 1709 Destination address: The internal IP address to where data 1710 flow will be destined. This is the source address of the NATFW 1711 reserve address packet. 1713 Destination port: The destination port of the data flow 1715 Protocol: Expected protocol 1717 The direction of NSIS NATFW NSLP signaling is reverse to the reserved 1718 data flow. The source address of the expected data flow is the 1719 destination of the signaling. Vice versa, the destination address of 1720 the expected data flow is the source of the signaling (see section 1721 Section 4). 1723 Note that no state, be it a firewall rule or a NAT binding, is 1724 installed as a result of this message. The state is only remembered, 1725 and might be later installed by a create message. 1727 5.5 Response Messages 1729 The following messages are responses messages that are generate 1730 either by any NF or NR. Currently, three different types of request 1731 messages are defined. 1733 5.5.1 Return External Address Response 1735 The return external address response message is sent as a successful 1736 reply to a reserve external address request. 1738 Return external address message contains these objects: 1740 o Session ID: The session this packet is replying to. 1742 o External address object: Contains reserved external IP address 1743 and port number 1745 o Lifetime: The minimum granted lifetime for this reservation. 1747 5.5.2 Path Succeeded Response 1749 The path succeeded response message is sent as a successful reply to 1750 a create session request. 1752 The Path succeeded response message contains these objects: 1754 o Session ID: The session ID for which a path was successfully 1755 installed 1757 o Lifetime: The minimum granted lifetime of this session 1759 5.5.3 Error Response Messages 1761 Any NATFW NSLP error occurring at NF or NR is reported via the error 1762 response message towards the NI. 1764 The error message contains these objects: 1766 o Session ID: The session id of the object that generated the error 1768 o Error code: The error to report. 1770 Possible error code classes are: 1772 o Policy rule errors 1774 o Authentication and Authorization errors 1776 o NATFW NSLP protocol errors 1778 5.6 Protocol Operations 1780 This section defines the message flow and protocol operation for all 1781 message types 1783 5.6.1 Message Handling Overview 1785 When a NSIS NATFW peer receives an NSIS message, it might take an 1786 action based on the message type, the nature of the middlebox 1787 function, its configuration and local security policies. 1789 As a summary, here's the behavior of the boxes, depending on message 1790 type and configuration parameters: 1792 NAT FW NAT+FW DS DR 1793 reserve 5 - 5 + + 1794 ret_ext_addr - - - + 8 1795 create 1 2 3 + 4 1796 prolong 6 6 6 + 4 1797 delete 7 7 7 + 4 1798 path_succeed 9 9 9 8 + 1800 ret_ext_addr: Return External Address response message 1802 1: Remember the policy rule, but do not install. Rewriting either 1803 the source or destination address depending on whether the packet 1804 comes from the external_address or not. Always forward. 1806 2: Remember policy rule, but do not install. Always forward. 1808 3: 1+2. The order depends on whether it comes from the outside 1809 address (NAT, then FW) or the inside one (FW, then NAT) 1811 4: If it fits one of its requests, send a path_succeeded packet 1812 back. Otherwise, drop the packet. 1814 5: Make a reservation. If middlebox is an edge NAT is set, send 1815 back the reserved external address and do not forward the message 1816 further. Otherwise, forward and do not send anything back. 1818 6: Prolong the session. Always forward. 1820 7: Terminate the session. Always forward. 1822 8: hand it over to upper layers, and stop processing. 1824 9: If it fits a prior request, enable policy rule that has been 1825 remembered only before. 1827 -: ignore and forward. 1829 +: ignore and drop. 1831 Note that policy rule ordering at middlebox is important, when it 1832 comes to combined NAT and firewall middleboxes, because the filter 1833 rules have to be set up according to the packet they will see. 1834 Source NAT is done at the end so it does not disturb routing 1835 decisions, meaning that filter sees the original packets. 1836 Destination NAT, on the other hand, is done at the beginning, so it 1837 can be routed properly, and so the filter sees the modified packets. 1839 Note also that for each action, the host might demand a certain 1840 degree of authorization, and thus refuse to take the action, sending 1841 an error message back instead. 1843 The details of protocol operations for each request type is defined 1844 in the next sections. Each section describes the exact handling for 1845 each type of middlebox. 1847 5.6.1.1 Reserving Addresses 1849 As explained in section Section 4, data receivers located behind a 1850 NAT must first reserve an external address and port number (if 1851 applicable) before any NSIS message can be send towards them. 1853 With the reserved external address message exchange NSIS peers can 1854 obtain this required external address and port number at a NAT. 1855 Therefore, NI sets the policy rule object and sends the signaling 1856 message to an address chosen on its own (see Section 4.2.1. The 1857 reserve message is sent in this way: 1859 Public Internet Private Address 1860 Space 1861 Edge 1862 DS NAT NAT NI(DR) 1863 | | | | 1864 | | | | 1865 | | | | 1866 | | Reserve | Reserve | 1867 | |<---------|<----------------| 1868 | | | | 1869 | | Return | ext addr/Error | 1870 | |--------->|---------------->| 1871 | | | | 1872 | | | | 1874 Handling of reserve external address messages depends on the 1875 middlebox type and NSIS peer: 1877 o NAT Box: 1879 When a NAT box gets a Reserve external address message, it checks 1880 whether it arrived on the public address, or the private one. If 1881 it arrived in the public one, an error message of the type: 1882 "Requested an external address from the outside" is sent back. 1884 If it arrived on the private side, an entry is made in the 1885 internal reservation list with the packet information. If the box 1886 is an edge NAT (either by configuring it to true, or just for that 1887 connection if it is set to auto), it drops the message, and 1888 replies with a return external address message containing the 1889 allocated address port pair. If it is not an edge NAT, it forwards 1890 the packet on. 1892 o Firewall Box: 1894 Reserve messages are silently ignored in Firewall boxes. They are 1895 simply forwarded on. 1897 o NAT+FW Box: 1899 When a box that integrates both a NAT and a Firewall gets a 1900 reserve message, it will hand it to its NAT part. Its firewall 1901 part will simple ignore it. 1903 o Data Sender: 1905 The message should never get here. It should be ignored and 1906 dropped. 1908 o Data Receiver: 1910 The message should never get here. It should be ignored and 1911 dropped. 1913 Response messages are handled differently depending on NSIS peer 1914 type: 1916 o NAT Box, Firewall Box and NAT+Firewall Box: 1918 When one of these boxes gets a Return external address message, it 1919 must simply ignore it and let it traverse. 1921 o Data Sender: 1923 The message should never get here. It should be ignored and 1924 dropped. 1926 o Data Receiver: 1928 A return external address message in the Data receiver, has 1929 reached its destination. It must be dropped, and it's information 1930 handed to superior layers. 1932 5.6.1.2 Creating Sessions 1934 Creating sessions enables communication between DS and DR. Both are 1935 enabled to exchange data packets even with middleboxes on path. DS 1936 generates a create session message with a chosen session ID, the 1937 policy rule object set to the requested flow, and a requested 1938 lifetime. DS sends the create session message towards DR. The 1939 message flow is sketched in the next figure. 1941 DS Public Internet NAT Private address DR 1942 | | space | 1943 | Create | | 1944 |----------------------------->| | 1945 | | | 1946 | Error (if necessary) | | 1947 |<-----------------------------| Create | 1948 | |--------------------------->| 1949 | | | 1950 | | Path Succeeded/Error | 1951 | Path Succeeded/Error |<---------------------------| 1952 |<-----------------------------| | 1953 | | | 1954 | | | 1956 Create session messages are processed differently at each NSIS peer: 1958 o NAT Box: 1960 When a NAT box gets a create message, it first checks if it 1961 arrived on the public address or not. 1963 If it came from the public side, it means an external box will try 1964 to send data. It then looks for a reservation in its reservation 1965 list, that matches the dst_addr and dst_port of policy rule 1966 included in the create message. If it does not find it, it 1967 returns an error message of the type "No reservation found". If it 1968 finds it, it fills in the reservation with the data from the 1969 packet, and remembers the given rule. It then changes the dst_addr 1970 and dst_port fields of the create packet and forwards it to the 1971 tgt_addr of the reservation. 1973 If it came from the private side, it installs the NAT rule with 1974 the information in the packet. It then changes the src_addr and 1975 src_port of the create message to its own external address and 1976 port. 1978 o Firewall Box: 1980 When a firewall box gets a create message, it simply remembers the 1981 rule specified in the message and forwards the packet. 1983 o NAT+FW Box: 1985 When a box that integrates both a NAT and a Firewall gets a create 1986 message, it first checks whether it arrived on the public address 1987 or not. 1989 If it arrived on the public side, the NAT part of the box takes 1990 care of the packet first, as said in the NAT Box case. Afterwards, 1991 the modified packet is handed to the firewall part, where it is 1992 handled as in the Firewall Box case. 1994 If it arrived on the private side, the message is handed to the 1995 firewall part first, and then to the NAT one. 1997 o Data Sender: 1999 The message should never get here. It should be ignored and 2000 dropped. 2002 o Data Receiver: 2004 If the data receiver gets a create message, it means all the boxes 2005 on the way accepted it, and so the signaling succeeded. All it 2006 does is drop the packet, and send back a Path Succeeded message to 2007 the IP packet source address. 2009 As described above, DRs return a path succeeded when the create 2010 message arrived at DR. The path succeeded message is returned along 2011 all NSIS forwarders. Each NSIS forwarder enables the prior 2012 remembered policy rules and forwards the message to next NSIS hop. 2014 Forwarding of the path succeeded messages is terminated at the DS. 2016 5.6.1.3 Prolonging Session 2018 NATFW NSLP sessions are maintained on a soft-state base. After a 2019 certain timeout they are removed automatically by the middlebox, if 2020 they are not refreshed by a prolong session message. DS is sending 2021 prolong message towards DR and each NSIS forwarder maintaining state 2022 for the given session ID extends the lifetime of the session. 2024 Extending lifetime of a session is calculated as current local time 2025 plus lifetime. 2027 DS Public Internet NAT Private address DR 2028 | | space | 2029 | Prolong/Delete | | 2030 |----------------------------->| | 2031 | | | 2032 | Error (if necessary) | | 2033 |<-----------------------------| Prolong/Delete | 2034 | |--------------------------->| 2035 | | | 2036 | | Error (if necessary) | 2037 | Error (if necessary) |<---------------------------| 2038 |<-----------------------------| | 2039 | | | 2040 | | | 2042 Figure 19: Prolongation message flow 2044 o NAT Box, Firewall Box and NAT+Firewall Box: 2046 When one of these boxes gets a Prolong session message, the 2047 expiration time of the session should be changed to the time of 2048 reception plus the configured session lifetime. 2050 o Data Sender: 2052 As in the create session message, this packet is sent from the DS 2053 to the DR, and should never arrive at the DS. Again, it should be 2054 ignored and dropped. 2056 o Data Receiver: 2058 The same behavior as in the case of a Delete session message on 2059 the DR should be applied. 2061 5.6.1.4 Deleting Sessions 2063 Deleting sessions is done via the delete session message. DS can 2064 request the deletion of a session at any time by sending this 2065 message. Processing of these messages at: 2067 o NAT Box, Firewall Box and NAT+Firewall Box: 2069 When one of these boxes gets a Delete session message, it erases 2070 the session referred in the message. 2072 o Data Sender: 2074 This packet should never get to the DS, so it is to be ignored and 2075 dropped. 2077 o Data Receiver: 2079 As in the create session message, this is the final destination of 2080 the message. DR erases its session. Message forwarding stops 2081 here. 2083 6. Solution examples 2085 6.1 Firewall traversal 2087 DS wants to send data traffic to DR through tight firewalls, as seen 2088 in Figure 20. To do that, it will have to signal using NSIS, on the 2089 data path. 2091 +-----+ +-----+ //----\\ +-----+ +-----+ 2092 DS --| FW1 |-----| FW2 |---| |---| FW3 |-----| FW4 |--- DR 2093 +-----+ +-----+ \\----// +-----+ +-----+ 2095 private public private 2097 Data Flow 2098 ===============================> 2100 Figure 20: Firewall Traversal Scenario 2102 Therefore, DS initiates signaling to DR by sending a create object to 2103 the IP address of DR. Note that DS already knows its source address 2104 and port (say, 1111), and the destination address of DR. The 2105 destination port (let's say 9999) has been send to DS by DR via 2106 application layer messages, possibly, but not necessarily involving a 2107 third party. The message looks like: 2109 o dst_addr = DR 2111 o dst_port = 9999 2113 o src_addr = DS 2115 o src_port = 1111 2117 This message is received by FW1, which installs the state that reads: 2118 "Any packet coming from DS:1111 headed for DR:9999 will be allowed 2119 traversal" 2121 FW2, FW3 and FW4 do exactly the same, and forward the packet to each 2122 other, until it finally reaches DR. At this point, the data path is 2123 open, and DR sends back a Path succeeded message to DS, which can now 2124 start sending traffic. 2126 6.2 NAT with private network on sender side 2128 In the example in Figure 21, DS is in a private network and wants to 2129 send data to DR, out in the public internet. To do so, DS will have 2130 to initiate NSIS signaling towards DR 2132 +------+ +------+ //----\\ 2133 DS --| NAT1 |-----| NAT2 |---| |--- DR 2134 +------+ +------+ \\----// 2136 private public 2138 Figure 21: NAT with private network on sender scenario 2140 Apparently, the normal NAT functionality will take care of sending 2141 the data from DS out into the public internet, and route back the 2142 replies from DR. This is indeed true, but doesn't give NSIS control 2143 on what the source address or port is, as it is usually assigned 2144 dynamically by the NAT. Moreover, the NSLP would have no information 2145 on this hops, and could not install proper pinholes, as it would set 2146 DS as the source address, and not that of the last NAT. 2148 DS builds a create packet with the information he has, which is the 2149 same as that in Section 6.1. It looks like this: 2151 o dst_addr = DR 2153 o dst_port = 9999 2155 o src_addr = DS 2157 o src_port = 1111 2159 NAT1 is the first to get the packet; It is not coming from its 2160 configured "nat external address", and so, it knows it will have to 2161 rewrite the information on the source, and not that of the 2162 destination. NAT1 then picks a free port (incidentally 1011) and 2163 installs a nat rule that reads: "Whatever packet comes from DS:111, 2164 heading for DR:9999 will be rewritten so that the source address 2165 looks like NAT1:1011". 2167 It then rewrites the packet it received as follows: 2169 o dst_addr = DR 2170 o dst_port = 9999 2172 o src_addr = NAT1 2174 o src_port = 1011 2176 And forwards the packet. 2178 NAT2 gets it now, and does exactly the same. Port 2022 is chosen, and 2179 the rule: "Whatever packet comes from NAT1:1011, heading for DR:9999 2180 will be rewritten so that the source address looks like NAT2:2022" is 2181 installed. The packet gets modified as follows: 2183 o dst_addr = DR 2185 o dst_port = 9999 2187 o src_addr = NAT2 2189 o src_port = 2022 2191 And is forwarded. It eventually reaches DR, who sends back a path 2192 succeeded message. Data flow from DS:1111 to DR:9999 is now possible. 2194 6.3 NAT with private network on receiver side 2196 In this example, DS wants to send data to DR over the network in 2197 Figure 22: 2199 //----\\ +------+ +------+ 2200 DS ---| |---| NAT1 |-----| NAT2 |--- DR 2201 \\----// +------+ +------+ 2203 public private 2205 Figure 22: NAT with private network on receiver Scenario 2207 The problem, of course, is that DR is not publicly reachable. Because 2208 of that, DR will have to signal on the data path, in the opposite 2209 direction (DR->DS) to get itself a public address it can use. This 2210 method is described in Section 4 2212 To get an external address, DR sends a packet to DS. It could 2213 actually send it to anything in the public internet, as it would 2214 force it to traverse what NATs are on its way. In the case of 2215 multihomed environments, though, more than one NAT to the outside is 2216 possible, so the better we "aim" the more the chances we go out the 2217 right NATs and get more optimal routes. 2219 The said packet is an NSIS reserve_addr object which looks like this: 2221 o tgt_addr = DR 2223 o tgt_port = 9999 2225 o src_addr = 0.0.0.0 2227 o src_port = 0 2229 Notice that this is a really loose pinhole, since any src_addr and 2230 port is allowed. 2232 NAT2 gets the packet and looks for a free port (say, 2022, for 2233 clarity's sake). It then adds an entry to its reservation list. The 2234 entry looks like this: 2236 o src_addr = 0.0.0.0 2238 o src_port = 0 2240 o dst_addr = NAT2 2242 o dst_port = 2022 2244 o tgt_addr = DR 2246 o tgt_port = 9999 2248 This means simply that packets coming from any source, destined to 2249 the public address we just reserved, should be targeted to the 2250 internal box DR, on port 9999 2252 It then rewrites the packet so that it looks like: 2254 o tgt_addr = NAT2 2256 o tgt_port = 2022 2258 o src_addr = 0.0.0.0 2260 o src_port = 0 2262 Because it is not an edge NAT, it forwards the modified packet and 2263 does not sent a return_external_addr object to DR. Note that no NAT 2264 binding is installed so far in NAT2, although the state is now 2265 reserved. 2267 NAT1 now gets the packet, picks free port 1011 and adds the following 2268 entry to its reservation list: 2270 o src_addr = 0.0.0.0 2272 o src_port = 0 2274 o dst_addr = NAT1 2276 o dst_port = 1011 2278 o tgt_addr = NAT2 2280 o tgt_port = 2022 2282 As it turns out, NAT1 IS an edge_nat, so it doesn't forward the 2283 packet. Instead, it replies to DR sending back a return external 2284 address packet on the same connection, so it finds its way back 2285 through the NATs: 2287 o ext_addr = NAT2 2289 o ext_port = 2022 2291 By using some application layer protocol, and possibly, although not 2292 necessarily, using a third party box, DR sends it's freshly allocated 2293 external address and port to DS. 2295 DS now knows who to signal, so it sends a create message: 2297 o dst_addr = NAT1 2299 o dst_port = 1011 2301 o src_addr = DS 2303 o src_port = 1111 2305 When it reaches NAT1, it does so through NAT1 external address. It 2306 realizes it is being asked to forward the traffic from some outside 2307 box towards the inside. It then looks up its reservation list, 2308 looking for a session that has the external address and port 2309 NAT1:1011 assigned. It finds this: 2311 o src_addr = 0.0.0.0 2313 o src_port = 0 2315 o dst_addr = NAT1 2317 o dst_port = 1011 2319 o tgt_addr = NAT2 2321 o tgt_port = 2022 2323 Using the information in the create object, it then fills in this 2324 structure to: 2326 o src_addr = DS 2328 o src_port = 1111 2330 o dst_addr = NAT1 2332 o dst_port = 1011 2334 o tgt_addr = NAT2 2336 o tgt_port = 2022 2338 This IS a tight pinhole. NAT1 installs the rules now, which say: 2339 "Whatever packet comes from DS:1111 heading for NAT1:1011, should 2340 have its destination address changed to NAT2:2022, and be forwarded". 2341 The packet is also rewritten into this: 2343 o src_addr = DS 2345 o src_port = 1111 2347 o dst_addr = NAT2 2349 o dst_port = 2022 2351 And is forwarded to NAT2. Upon arrival, a similar process issues. 2352 NAT2 finds its reservation entry: 2354 o src_addr = 0.0.0.0 2356 o src_port = 0 2358 o dst_addr = NAT2 2359 o dst_port = 2022 2361 o tgt_addr = DR 2363 o tgt_port = 9999 2365 Fills it in accordingly: 2367 o src_addr = DS 2369 o src_port = 1111 2371 o dst_addr = NAT2 2373 o dst_port = 2022 2375 o tgt_addr = DR 2377 o tgt_port = 9999 2379 Rewrites the packet: 2381 o src_addr = DS 2383 o src_port = 1111 2385 o dst_addr = DR 2387 o dst_port = 2222 2389 And forwards it to DR. Once there, DR acknowledges it by sending back 2390 a path succeeded message in reply, back to DS. 2392 The path is now open and data transmission from DS:1111->DR:9999 can 2393 commence. 2395 6.4 Both end hosts are in same private network behind NATs 2397 In this example (see Figure 23), DS, in a private address space, 2398 wants to send data to DR, in another private address space. The point 2399 marked "%" is yet another private address space. Notice that since 2400 NAT1 and NAT3 have addresses in the same address space, NAT3 might 2401 want to consider itself an edge NAT. We will consider both 2402 situations. 2404 public 2405 +------+ % +------+ //----\\ 2406 DS --| NAT1 |--+--| NAT2 |---| | 2407 +------+ | +------+ \\----// 2408 | 2409 | +------+ 2410 +--| NAT3 |------------ DR 2411 +------+ 2413 private 2415 Figure 23: NAT to public, receiver in same private network Scenario 2417 We will first assume that NAT3 has the edge_nat option set to false. 2418 In this case, the connection is a combination of Section 6.3 and 2419 Section 6.2. 2421 Firstly DR will signal against on the data path, against the data 2422 flow, with a reserve external address object. NAT3 will reserve the 2423 address and forward the packet on to NAT2, who IS an edge NAT in all 2424 cases. NAT2 will reply with the external address, and the connection 2425 goes on just as in Section 6.2, except for the fact the topology 2426 becomes: 2428 public 2429 +------+ +------+ 2430 DS --| NAT1 |-----o------o---+ 2431 +------+ | | | 2432 | NAT2 |---+ 2433 | | | 2434 +--o------o---+ 2435 | +------+ 2436 | 2437 | +------+ 2438 +--| NAT3 |------------ DR 2439 +------+ 2441 private 2443 Figure 24: New topology due to the non optimal edge nat parameter 2444 decision 2446 This is not optimal, but the connection does succeed, and data flow 2447 can commence. 2449 Let us now solve the case in which NAT3 has edge_nat set to auto. 2450 Back in Figure 23, NAT3 will decide it IS an edge_nat if the 2451 destination we pick up for the reserve address packet is in the 2452 address space marked as "%", and will NOT consider itself an edge_nat 2453 if we point it anywhere else. This is an optimization issue such as 2454 the one pointed out in Section 6.3. 2456 Well so, if it doesn't consider itself an edge NAT, we already saw 2457 what the topological equivalent is, and how it proceeds. If it IS an 2458 edge NAT, the topological equivalent would be: 2460 +------+ 2461 DS --| NAT1 |--+ 2462 +------+ | 2463 | 2464 | +------+ 2465 +--| NAT3 |------------ DR 2466 +------+ 2468 private 2470 Figure 25: A good edge nat decision brings an optimal route 2472 And we would proceed in the same way, only on a more optimal route. 2474 6.5 IPv4/v6 NAT with two private networks 2476 TBD 2478 6.6 Full example for NAT/FW with two private networks 2480 The NAT's have the nat_capabilities variable set to true. NAT+FW3 and 2481 NAT+FW5 have the edge_nat variable set to true. The rest of boxes 2482 have it set to false. 2484 Let's now suppose that DR wants to get a data stream from DS in 2485 Figure 26. For that, we need some way for B to get messages from A, 2486 be it through some third party application server or some publicly 2487 reachable proxy, perhaps made public through a NAT binding. 2489 +-----+ 2490 +--------| FW4 |--------+ 2491 | +-----+ | 2492 +---------+ +---------+ 2493 | NAT+FW3 | | NAT+FW5 | 2494 +---------+ +---------+ 2495 | | 2496 +---------+ +---------+ 2497 | NAT3 | | NAT6 | 2498 +---------+ +---------+ 2499 | | 2500 +---------+ +---------+ 2501 | FW1 | | FW7 | 2502 +---------+ +---------+ 2503 | | 2504 +---------+ +---------+ 2505 | DS | | DR | 2506 +---------+ +---------+ 2508 Data Flow 2509 ==========================> 2511 Figure 26: Example network topology 2513 DR wants a data stream from DS, which means that the direction of the 2514 data is DS->DR. A will have to make itself publicly reachable by 2515 signaling its NATs and firewalls as necessary. This is a step by step 2516 guide to the whole process. 2518 In steps 1 to 4, DR makes itself publicly reachable. From 5 and on, 2519 DS is signaling on the data path towards DR. 2521 1. DR wants to get data from DS, so it sends a reserve_addr object to 2522 a target in the public internet. The closest this target is, the more 2523 the chances that the resulting route is optimal, but any will work. 2524 The reserve_addr obj looks like this: 2526 o tgt_addr = DR 2528 o tgt_port = 888 2530 o src_addr = 0.0.0.0 2532 o src_port = 0 2534 Notice that this is a really loose pinhole, since any src_addr and 2535 port is allowed. 2537 2. FW7 gets the packet, ignores its contents and forwards it. 2538 Firewalls always ignore reserve_addr objects. 2540 3. NAT6 gets the packet, and looks for a free port (say, 666, for 2541 clarity's sake). It then adds an entry to its reservation list. The 2542 entry looks like this: 2544 o src_addr = 0.0.0.0 2546 o src_port = 0 2548 o dst_addr = NAT6 2550 o dst_port = 666 2552 o tgt_addr = DR 2554 o tgt_port = 888 2556 It then rewrites the packet so that it looks like: 2558 o tgt_addr = NAT6 2560 o tgt_port = 666 2562 o src_addr = 0.0.0.0 2564 o src_port = 0 2566 Because it is not an edge NAT (edge_nat=false), it does not sent a 2567 return_external_addr object to DR, but rather forwards the modified 2568 packet. Note that no NAT binding is installed so far in NAT6, 2569 although the state is now reserved. 2571 4. NAT+FW5 receives the packet. The firewall part gets the object, 2572 but, being as it is an address reservation only object, it ignores 2573 it. The NAT part gets it next. Because it is a NAT, it binds a free 2574 port, which is thus reserved. An entry to the reservation list is 2575 added: 2577 o src_addr = 0.0.0.0 2579 o src_port = 0 2581 o dst_addr = NAT+FW5 2583 o dst_port = 555 2584 o tgt_addr = NAT6 2586 o tgt_port = 666 2588 Because it is an edge_nat, it sends a return_external_addr packet 2589 with address NAT+FW5 and port 555 back to DR. It does so by simply 2590 sending it back to the source IP address in the IP header of the 2591 packet. In this case, it is NAT6. The standard capabilities of NAT6 2592 will send it back to DR, since we are always working on the same 2593 connection. Because it is an edge_nat and this is a 2594 reserve_external_addr packet, it does not forward the packet. 2596 At this stage, the end host DR has learned what its (reserved) 2597 external address is, even if it can not be used. It is now publicly 2598 reachable, and path-coupled NSIS signaling in direction DS->DR can 2599 start. 2601 5. Firstly, DR tells DS about it's freshly reserved outside address 2602 through some higher layer protocol, using the third-party box. 2604 6. DS now initiates signaling to DR by sending a create object to the 2605 brand new public address of DR. It looks like: 2607 o dst_addr = NAT+FW5 2609 o dst_port = 555 2611 o src_addr = DS 2613 o src_port = 111 2615 7. The firewall FW1 gets it, and installs the requested pinhole. 2616 (Note this IS a tight pinhole with well defined source and 2617 destination). It then forwards the packet. 2619 8. NAT2 gets the packet. Because it is NOT coming from it's external 2620 address, it realizes it is being asked to forward DS's future data 2621 packets, and so, it will have to rewrite it's source address. To do 2622 so, NAT2 picks a random free port (which turns out to be 222), and 2623 installs a NAT rule that says: "Whatever packet comes from DS:111, 2624 heading for NAT+FW5:555 will be rewritten so that the source address 2625 looks like NAT2:222". That is usually known as Source NAT. The NSIS 2626 create request is then rewritten to look like: 2628 o dst_addr = NAT+FW5 2630 o dst_port = 555 2631 o src_addr = NAT2 2633 o src_port = 222 2635 Because it is not an edge NAT, it simply forwards the modified 2636 packet. 2638 9. NAT+FW3 gets the packet next. Because it is NOT coming from the 2639 extarnal_addr of the NAT+FW, The firewall part gets it first, and 2640 installs the filter rule that says: "Allow traversal of packets going 2641 from NAT2:222 towards NAT+FW5:555". It then hands it to the NAT part. 2643 The NAT part gets it then. It is not coming from its external 2644 address, and so, it does as NAT2, binding a port (333) and installing 2645 a rule that says: "Whatever packet comes from NAT2:222, heading for 2646 NAT+FW5:555, will be rewritten so that the source address looks like 2647 NAT+FW3:333". It will then rewrite the create object to: 2649 o dst_addr = NAT+FW5 2651 o dst_port = 555 2653 o src_addr = NAT+FW3 2655 o src_port = 333 2657 Note that the box won't send a packet back to DS informing it of its 2658 external address, because DS will never need that. 2660 10. FW4 gets the create object, and installs the rule "Allow 2661 traversal of packets going from NAT+FW3:333 towards NAT+FW5:555" It 2662 then forwards the object. 2664 11. NAT+FW5 gets the create object. It arrived at its external 2665 address, so it realizes it doesn't have to change the source address 2666 of the future data packets of DS, but rather its destination. It also 2667 means that the NAT part will have to handle it first. It then tries 2668 to find out where it has to re-destined it to, by looking up its 2669 reservation tables. It finds the previous reservation, by matching it 2670 with their dst_addr and dst_port of the create object: 2672 o src_addr = 0.0.0.0 2674 o src_port = 0 2676 o dst_addr = NAT+FW5 2678 o dst_port = 555 2679 o tgt_addr = NAT6 2681 o tgt_port = 666 2683 And proceeds to fill it in with the information of the create object 2684 (src_addr and src_port): 2686 o src_addr = NAT+FW3 2688 o src_port = 333 2690 o dst_addr = NAT+FW5 2692 o dst_port = 555 2694 o tgt_addr = NAT6 2696 o tgt_port = 666 2698 It then installs a NAT rule with that information. It reads: 2699 "Whatever packet comes from NAT+FW3:333, heading for NAT+FW5:555 will 2700 be rewritten, so that its destination address looks like NAT6:666". 2701 The reservation is erased and the rule starts working. The NAT 2702 binding becomes thus usable. 2704 The object is modified, so that it now looks like: 2706 o dst_addr = NAT+FW3 2708 o dst_port = 333 2710 o src_addr = NAT6 2712 o src_port = 666 2714 The FW part now gets the object, and installs the rule: "Allow 2715 traversal of whatever packet that comes from NAT+FW3:333 heading for 2716 NAT6:666". The packet is then forwarded. 2718 12. NAT6 gets the packet. As it comes from the external address, it 2719 does as NAT+FW5, looking up the reservation list and filling it in 2720 with: 2722 o src_addr = NAT+FW3 2724 o src_port = 333 2726 o dst_addr = NAT6 2727 o dst_port = 666 2729 o tgt_addr = DR 2731 o tgt_port = 888 2733 It then installs the rule: "Whatever packet comes from NAT+FW3:333, 2734 heading for NAT6:666 will be rewritten, so that its destination 2735 address looks like DR:888". The rule reservation is erased, and the 2736 NAT binding becomes active. The object is rewritten as: 2738 o src_addr = NAT+FW3 2740 o src_port = 333 2742 o dst_addr = DR 2744 o dst_port = 888 2746 The object is thus forwarded. 2748 13. FW7 gets the packet now, and installs the rule: "Allow traversal 2749 of whatever packet that comes from NAT+FW3:333 heading for DR:888". 2750 It forwards the packet. 2752 14: DR gets (finally) the packet. It realizes it is a create object 2753 headed for him, to the port which he expected, and so it sees 2754 everything went well. A reply to the packet is send, and the NAT's on 2755 the way, knowing the already established connection, will route it to 2756 DS. The packet is a path_succesful message, which simply means 2757 "Everything is fine, send data whenever you want". 2759 7. NSIS NAT and Firewall transitions issues 2761 NSIS NAT and Firewall transition issues are premature and will be 2762 addressed in a separate draft (see [16]). An update of this section 2763 will be based on consensus. 2765 8. Security Considerations 2767 Security is of major concern particularly in case of firewall 2768 traversal. Generic threats for NSIS signaling have been discussed in 2769 [5] and are applicable here as well. It is necessary to provide 2770 proper signaling message protection and proper authorization. Note 2771 that the NAT is likely to be co-located with a firewall and might 2772 therefore require packet filters to be changed in order to allow the 2773 signaling message to process and to traverse. This section aims to 2774 raise some items for further discussion and illustrates the problems 2775 the authors faced when creating a security solution for the NAT/ 2776 Firewall NSLP. 2778 Installing packet filters provides some security, but has some 2779 weaknesses, which heavily depend on the type of packet filter 2780 installed. A packet filter cannot prevent an adversary to inject 2781 traffic (due to the IP spoofing capabilities). This type of attack 2782 might not be particular helpful if the packet filter is a standard 5 2783 tuple which is very restrictive. If packet filter installation, 2784 however, allows specifying a rule, which restricts only the source IP 2785 address, then IP spoofing allows transmitting traffic to an arbitrary 2786 address. NSIS aims to provide path-coupled signaling and therefore an 2787 adversary is somewhat restricted in the location from which attacks 2788 can be performed. Some trust is therefore assumed from nodes and 2789 networks along the path. 2791 Without doubts there is a dependency on the security provided by the 2792 NTLP. Section Section 3 and Section 2.2 motivates some trust 2793 relationship and authorization scenarios. These scenarios deserve a 2794 discussion since some of them (particularly one with a missing 2795 network-to-network trust relationship) is different to what is know 2796 from QoS signaling. To address some of these trust relationships and 2797 authorization issues requires security mechanisms between 2798 non-neighboring nodes at the NSLP layer. For the group of authors it 2799 seems that peer-to-peer and end-to-middle security needs to be 2800 provided. An NSLP security mechanism between neighboring NSLP peers 2801 might be necessary if security mechanisms at the NTLP do not provide 2802 adequate protection mechanisms. This issue is, however, still in 2803 discussion. 2805 As a design goal it seems to be favorable to reuse existing 2806 mechanisms to the best extend possible. In most cases it is 2807 necessary to carry the objects for end-to-middle as NSLP payloads 2808 since the presence of NATs might prevent direct communication. Three 2809 security mechanisms have to be considered in more detail in a future 2810 version of this document: CMS [17] and Identity Representation for 2811 RSVP [14]. The authors believe that CMS more suitable (since it 2812 provides much more functionality). The details deserve further 2813 discussion and implementation experience. 2815 With regard to signal between two end hosts even though the receiver 2816 is behind a NAT this proposal suggests creating state by the data 2817 receiver first. This allows NSIS signaling messages to traverse a 2818 NAT at the receiver side (due to the established state at this NAT 2819 box) and simplifies security handling. To achieve this behavior it 2820 is required to install NSIS NTLP and NSLP state. Furthermore, it is 2821 envisioned to associate the two signaling parts (one part from the 2822 data sender to the NAT and the other part from the NAT to the data 2823 receiver) with the help of the Session Identifier. As such, the 2824 discussion in [14] is relevant for this document. 2826 Another interesting property of this protocol proposal is to prevent 2827 Denial of Service attacks against NAT boxes whereby an adversary 2828 allocates NAT bindings with the help of data packets. Since these 2829 data packets do not provide any type of authentication and are not 2830 authorized any adversary is able to mount such an attack. This attack 2831 has been mentioned at several places in the literature already and 2832 is particularly harmful if no NAPT functionality is used (i.e. if a 2833 new NAT binding consumes one IP address of a pool of IP addresses). 2834 Using the protocol described in this document additional security can 2835 be achieved and more fairness can be provided. 2837 9. Open Issues 2839 At least the following issues require further discussion: 2841 o Message format: The exact message format is still to be 2842 determined, both in regards of bit level details and on 2843 parameters, such as the need for an object header length, since, 2844 until now, that is a constant. 2846 o Message type numbering 2848 o Error codes: error codes have to be defined still. Among others, 2849 we will need: missing authorization, out of resources, unable to 2850 understand the packet, or maximum resources for that individual 2851 already allocated. 2853 o middlebox default policies: allow for the configuration of the 2854 default policies of the box. For a NAT+Firewall box, for instance, 2855 the firewall default policy might be "accept", and so, no packet 2856 filters would have to be installed on that regard (we would still 2857 need the NAT bindings, though). 2859 o IPv6 flow label usage 2861 o Stacking 2863 o Edit Section 6 "Solution Examples" 2865 o Edit Security Consideration section 2867 o Edit Appendix A. 2869 10. Contributors 2871 A number of individuals have contributed to this draft. Since it was 2872 not possible to list them all in the authors section, it was decided 2873 to split it and move Marcus Brunner and Henning Schulzrinne into the 2874 contributors section. Separating into two groups was done without 2875 treating any one of them better (or worse) than others. 2877 Normative References 2879 [1] Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT 2880 draft-ietf-nsis-fw-05.txt, October 2003. 2882 [2] Brunner et al., M., "Requirements for Signaling Protocols", 2883 DRAFT draft-ietf-nsis-req-09.txt, October 2003. 2885 [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 2886 Messaging Protocol for Signaling", DRAFT 2887 draft-ietf-nsis-ntlp-00.txt, October 2003. 2889 [4] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 2891 [5] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 2892 DRAFT draft-ietf-nsis-threats-01.txt, January 2003. 2894 [6] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 2895 Rayhan, "Middlebox communication architecture and framework", 2896 RFC 3303, August 2002. 2898 Informative References 2900 [7] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 2901 (NAT) Terminology and Considerations, RFC 2663", August 1999. 2903 [8] Srisuresh, P. and M. Holdrege, "Network Address Translator 2904 (NAT)Terminology and Considerations, RFC 2663". 2906 [9] Srisuresh, P. and E. Egevang, "Traditional IP Network Address 2907 Translator (Traditional NAT), RFC 3022", January 2001. 2909 [10] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 2910 Protocol Translation (NAT-PT), RFC 2766", February 2000. 2912 [11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 2913 RFC 3234, February 2002. 2915 [12] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, 2916 "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2917 2694, September 1999. 2919 [13] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 2920 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 2921 Specification", September 1997. 2923 [14] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 2924 Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 2925 3182, October 2001. 2927 [15] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and 2928 X. Fu, "Security Implications of the Session Identifier", June 2929 2003. 2931 [16] Aoun and others...., C., "NAT/Firewall NSLP migration, routing, 2932 NTLP requirements and off-path Considerations", October 2003. 2934 [17] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 2935 August 2002. 2937 [18] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K. 2938 Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt, 2939 November 2002. 2941 [19] Tschofenig, H., Buechli, M., Van den Bosch, S. and H. 2942 Schulzrinne, "NSIS Authentication, Authorization and Accounting 2943 Issues", March 2003. 2945 [20] Amini, L. and H. Schulzrinne, "Observations from router-level 2946 internet traces", DIMACS Workshop on Internet and WWW 2947 Measurement, Mapping and Modelin Jersey) , Februar 2002. 2949 [21] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 2950 Traversal of VPN Gateways", 2951 draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in 2952 progress), April 2003. 2954 [22] Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin, 2955 "Problem Space and Usage Scenarios for PANA", 2956 draft-ietf-pana-usage-scenarios-06 (work in progress), April 2957 2003. 2959 [23] Shore, M., "The TIST (Topology-Insensitive Service Traversal) 2960 Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002. 2962 [24] Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT 2963 Traversal Client for CASP", DRAFT 2964 draft-tschofenig-nsis-casp-midcom-01.txt, March 2003. 2966 [25] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2967 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2968 Session Initiation Protocol", RFC 3261, June 2002. 2970 [26] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H. and H. 2971 Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and 2972 Framework", DRAFT draft-brunner-nsis-midcom-ps-00.txt, June 2973 2003. 2975 Authors' Addresses 2977 Martin Stiemerling 2978 Network Laboratories, NEC Europe Ltd. 2979 Kurfuersten-Anlage 36 2980 Heidelberg 69115 2981 Germany 2983 Phone: +49 (0) 6221 905 11 13 2984 EMail: stiemerling@netlab.nec.de 2985 URI: 2987 Hannes Tschoefenig 2988 Siemens AG 2989 Otto-Hahn-Ring 6 2990 Munich 81739 2991 Germany 2993 Phone: 2994 EMail: Hannes.Tschofenig@siemens.com 2995 URI: 2997 Miquel Martin 2998 Network Laboratories, NEC Europe Ltd. 2999 Kurfuersten-Anlage 36 3000 Heidelberg 69115 3001 Germany 3003 Phone: +49 (0) 6221 905 11 16 3004 EMail: miquel.martin@netlab.nec.de 3005 URI: 3007 Cedric Aoun 3008 Nortel Networks 3010 France 3012 EMail: cedric.aoun@nortelnetworks.com 3014 Appendix A. Inter-working of SIP with NSIS NATFW NSLP 3016 This document aims at pinpointing the problems of using SIP in 3017 nowadays networks, focusing on the problems derived of NAT's, 3018 Firewalls and multi-path communications. It is intended to fit in a 3019 scenario description that shows the necessity of NSIS, as well as 3020 depicting it's requirements. However, note that there are a number of 3021 other solutions available. For example the IETF Midcom working group 3022 is working on [6]. 3024 A.1 The Session Initiation Protocol 3026 [25] describes the Session Initiation Protocol, an application-layer 3027 control protocol that can establish, modify, and terminate multimedia 3028 sessions. This often involves several flows for video and voice, 3029 which are transported over new connections. These use of dynamically 3030 allocated ports which results in protocol complexity which can not be 3031 handled by nowadays NAT's and Firewalls. 3033 Session initiation when one or both of the users is behind a NAT is 3034 also not possible, given the impossibility to address a private IP 3035 over the internet. Moreover, network deployments often allow for 3036 different paths per connection and direction, making the setup of the 3037 middleboxes even more complicated. 3039 The following figure depicts a typical SIP connection: 3041 Ernie(192.0.2.1) Bert(192.0.2.2) 3042 | | 3043 | 1# SIP INVITE | 3044 +--------------------------------------->| 3045 | 3046 | 2# SIP Ringing | 3047 |<---------------------------------------+ 3048 | | 3049 | 3# SIP OK | <-- Call accepted 3050 |<---------------------------------------+ 3051 | | 3052 | 4# SIP ACK | 3053 +--------------------------------------->| 3054 | | 3055 | 5# DATA | 3056 |=======================================>| 3057 |<=======================================| 3058 | | 3060 1# SIP Invite (192.0.2.1:? -> 192.0.2.2:SIP): I Listen on 3061 192.0.2.1:1000 Ernie invites Bert to the conference, and informs 3062 it's awaiting media data on port 1000. 3064 2# SIP Ringing (192.0.2.2:SIP -> 192.0.2.1:?): Ringing Bert's 3065 phone The ringing simply implies that there's something sip aware 3066 on Bert's side, and that it's ringing his phone 3068 3# SIP OK (192.0.2.2:SIP -> 192.0.2.1:?): Call accepted, I listen 3069 on 192.0.2.2:2000 This OK means that the Bert took the phone off 3070 hook, and thus accepted the call. It also informs Ernie that Bert 3071 is awaiting his media data at port 2000 3073 4# SIP ACK (192.0.2.1:? -> 192.0.2.2:SIP): All is fine, start 3074 transmitting. ACK means the ports are accepted and the call can 3075 start in the selected data ports on both sides. 3077 5# DATA (192.0.2.1:? -> 192.0.2.2:2000 and 192.0.2.2:? -> 3078 192.0.2.1:1000): Voice,image, video.. This is the actual data 3079 being transmitted. 3081 In the above example, SIP is used successfully to establish a 3082 communication, which includes negotiating the data ports for the 3083 actual transmission. Unfortunately, this scheme will not work for 3084 more complex setups. 3086 Let's now consider one firewall in the data path, be it on Ernie's or 3087 Bert's network, or elsewhere in the middle. We assume that the 3088 firewall is allowing traffic directed to the SIP port. As to the rest 3089 of the ports, a typical setup involves outgoing connections being 3090 allowed, and incoming connections being dropped, except for those 3091 already established. That is, we allow packets to go out and their 3092 replies to come in, but disable all other traffic. 3094 In this case, the connection is as follows, for the case of a 3095 firewall on Ernie's network: 3097 Ernie(192.0.2.1) FW Bert(192.0.2.2) 3098 | | | 3099 | 1# SIP INVITE | | 3100 +--------------------------------------->| 3101 | | | 3102 | | 2# SIP Ringing | 3103 |<---------------------------------------+ 3104 | | | 3105 | | 3# SIP OK | <-- Call accepted 3106 |<---------------------------------------+ 3107 | | | 3108 | 4# SIP ACK | | 3109 +--------------------------------------->| 3110 | | | 3111 | 5# DATA | | 3112 |=======================================>| 3113 | |<=======================| 3114 | | | 3116 Notice how the SIP messages #1 and #4 traverse the firewall, because 3117 they are outbound, and how 2# and 3# traverse it too, because they 3118 are replies to the connection established at 1#. 3120 Notice now how 5# can go outwards, but Bert can not go through the 3121 firewall to reach Ernie's port 1000. The reason is the connection is 3122 a new one, and the firewall won't allow it through. 3124 Bert will now get media from Ernie, but Ernie is never going to get 3125 anything from Bert. The call is thus considered unsuccessful. The 3126 reason is that the application level port negotiation is never 3127 acknowledge by the network-transport layer firewall, which doesn't 3128 know what to expect. We would still face the same problem if the 3129 connection used a SIP Proxy, for it would only translate names into 3130 IP addresses. 3132 Let us now assume that we indeed have an application layer firewall, 3133 be it by design, or because we load some sort of SIP module to it. 3134 The previous case would now work, since the firewall can now 3135 understand the packets going through it and open the necessary ports. 3136 Still, we cannot assume that SIP signalization packets and the actual 3137 data follow the same path. The following figure shows a likely setup. 3138 FW+ stands for one or more firewalls: 3140 SIP Signalization Path +-----+ 3141 /---------------->-----------| FW+ |-------\ 3142 | +-----+ | 3143 +------+ +------+ +-----+ 3144 |Ernie |----|Router| |Bert | 3145 +------+ +------+ +-----+ 3146 | Data Path +-----+ | 3147 \---------------->-----------| FW+ |-------/ 3148 +-----+ 3150 The SIP packets with the information about the listening ports now 3151 travels on the SIP Signalization path, and so the firewalls on that 3152 path can read them. The Data, though, is traveling through the Data 3153 path, and the firewalls in that path never get to see the Invite and 3154 Ok packets. They are thus unable to open the ports. 3156 Two issues are arisen here: first, we need on-path signalization 3157 unless we already know the path our packets will take; a highly 3158 unlikely situation in today's internet. Second, if we patch the 3159 firewalls to understand SIP, we will provide any caller with a 3160 hole-puncher for the firewall, since SIP is not provisioned with 3161 proper authentication mechanism. 3163 It is now clear that tight firewalls prevent SIP from successfully 3164 working. There is still another obstacle: NATs. 3166 NATs provide for a link between two different address spaces, 3167 typically connecting a private range network to a public range one. 3168 As a consequence, connections going from the inside (usually the 3169 private range) are translated using the NAT's public interface 3170 address, and the replies are routed back. The public side of the 3171 network can only see the NATs public interface, and know nothing of 3172 the private network inside. This means computers outside the NAT 3173 won't be able to address computers inside the NAT. 3175 Let us analyse the SIP example when Ernie is behind a NAT. The 3176 following figure depicts a typical session: 3178 Ernie(10.0.0.2) (10.0.0.1) NAT (192.0.2.1) Bert(192.0.2.2) 3179 | | | 3180 | 1# SIP INVITE | | 3181 +--------------------------\ | 3182 | |----------------->| 3183 | | | 3184 | | 2# SIP Ringing | 3185 | /------------------+ 3186 |<-------------------------| | 3187 | | | 3188 | | 3# SIP OK | <-- Call accepted 3189 | /------------------+ 3190 |<-------------------------| | 3191 | | | 3192 | 4# SIP ACK | | 3193 +--------------------------\ | 3194 | |----------------->| 3195 | | | 3196 | 5# DATA | | 3197 |==========================\ | 3198 | |=================>| 3199 | | ?<=============| 3200 | | | 3202 The communication is analogous to the one in the previous examples, 3203 except for the fact the NAT is rewriting the source address of the 3204 packets as they traverse it. 3206 For instance, packet 1# is going from 10.0.0.2:? towards 3207 192.0.2.2:SIP. The NAT box intercepts the message and puts 3208 192.0.2.1:? as the source address and port, with ? being a 3209 dynamically picked port, which might be different from the original 3210 one 1# used. 3212 On the way back, Bert is replying to the source of the IP packet, 3213 that is, 192.0.2.1, and so, when 2# reaches 192.0.2.1, the NAT know 3214 it is a reply from 1#, because it established a NAT binding, and this 3215 replaces the destination address, 192.0.2.1:? with 10.0.0.2:? and 3216 forwards the packet inside the NAT. 3218 As a result, Ernie never knows there is a NAT in his communication 3219 path, since he sends and receives packets from 192.0.2.2 normally. 3220 This means that the INVITE packet will tell Bert to send data back to 3221 10.0.0.2, a private IP. Once the signalization is finished, and the 3222 actual DATA transmission starts, Bert tries to connect to 10.0.0.2, a 3223 private IP address, from the internet; The routers don't know how to 3224 route this, and the packet is eventually dropped. 3226 One possible solution would be for Ernie to know the NAT exists, and 3227 already indicate that it listens on 192.0.2.1, and not 10.0.0.2. 3228 That, still would not work, since the NAT binding is not performed at 3229 the NAT box. 3231 A.2 Conclusions 3233 The above examples display the inability to use standard SIP through 3234 tight firewalls or NATs, and points at the necessity of a secure 3235 on-path protocol to negotiate firewall pinholes and NAT bindings. 3237 Appendix B. Ad-Hoc networks 3239 Some forms of ad-hoc networks exist where trust in the network is not 3240 justified. Figure Figure 31 mainly illustrates the problems of 3241 malicious NSIS entities graphically: 3243 +------------------------------------------+ +--------// 3244 | Ad-Hoc | | ISP 3245 | Network | | 3246 | regular data | | 3247 | traffic by +---------+ | | 3248 | node A |Malicious| | +-+--------+ 3249 | +-------------->+ Node +-----+///-->+ Firewall +-// 3250 | ^ | 3 |===========>| 1 | 3251 | | +---------+ injected +-+--------+ 3252 | | data traffic | 3253 | | | | 3254 | | | | 3255 | +---+-----+ +---------+ | | 3256 | + Node | | Node | | | 3257 | | 1 | | 2 | | | 3258 | +---------+ +---------+ | | 3259 | ^ | +--------// 3260 | | | 3261 +----------+-------------------------------+ 3262 | 3263 +--+---+ 3264 | Node | 3265 | A | 3266 +------+ 3268 Figure 31: Limits of packet filter security 3270 An ad-hoc network consists of a number of nodes between the end host 3271 (Node A) and the ISP to which Node A wants to get access. Although 3272 Node A uses an authentication and key exchange protocol to create a 3273 policy rule at the firewall 1 it is still possible for an untrusted 3274 node (in this case Node 3) to inject data traffic which will pass 3275 Firewall 1 since the data traffic is not authenticated. To prevent 3276 this type of threat two approaches are possible. First, a restrictive 3277 packet filter limits the capabilities of an adversary. Finally, there 3278 is always the option of using data traffic protection. 3280 Appendix C. Interworking of Security Mechanisms and NSIS NATFW NSLP 3282 TBD 3284 Appendix D. Solution approaches in case of missing authorization 3286 D.1 Solution Approach: Local authorization from both end points 3288 The first approach makes use of local authorization from both end 3289 points. If Host A sends a signaling message toward the destination to 3290 Middlebox 1 the message will perform the desired action in Network A. 3291 Middlebox 1 establishes some state information and forwards the 3292 signaling message towards Host B. Signaling message protection 3293 between the two access networks might be difficult. A missing trust 3294 relationship does not necessarily mean that no security association 3295 establishment is possible. The lacking trust disallows Middlebox 1 3296 (or indirectly Host A where the signaling message was initiated) to 3297 create packet filters at Middlebox 2. We assume that the NSIS 3298 signaling message is allowed to pass the firewall then it finally 3299 reaches Host B. Due to the missing authorization no packet filter 3300 specific state is created. The filters will be installed later after 3301 receiving an authorization from Host B. When Host B returns a 3302 confirmation or acknowledgement then Middlebox 2 treats it as an 3303 authorization and finally triggers filter creation. The message is 3304 then forwarded to Middlebox 1, where filters are either already 3305 installed or require an additional confirmation. Finally the 3306 signaling message is forwarded to Host A, which can be assured that 3307 subsequent data traffic can be transmitted end-to-end from Host A to 3308 Host B. The same procedure has to be applied again to signal 3309 information for the other direction (Host B to Host A). 3311 The following behavior has to be assumed in order for this approach 3312 to be applicable: 3314 1. Signaling messages must be allowed to pass firewalls along the 3315 path. 3317 2. NSIS signaling must operate in the described manner which could 3318 be described as: Install where you have authorization - delay and 3319 forward where you have no authorization. 3321 This approach suffers from the following drawbacks: 3323 1. Firewalls which block NSIS signaling from external networks or 3324 nodes prevent a successful operation. 3326 2. A full roundtrip is required to signal packet filter information. 3327 The NSIS signaling message must therefore provide the capability 3328 to route signaling message in both direction which might either 3329 require state installation at nodes along the path (route 3330 pinning) or a stateless version via record-route. Some risk of 3331 DoS protection might exist. 3333 D.2 Solution Approach: Access Network-Only Signaling 3335 The next approach is based on signaling packet filter information by 3336 both hosts into the local access network only. An NSIS allows 3337 specifying such a behavior by indicating the signaling endpoint with 3338 the help of scoping (for example with domain name or a "local network 3339 only" flag). Scoping means that the signaling message although 3340 addressed to a particular destination IP address terminates somewhere 3341 along the path. If packet filters for both directions have to be 3342 installed then the signaling messages have to make packet filter 3343 installations up- and downstream along the data path. Similar to 3344 proposals in the area of QoS signaling some problems are likely to 3345 occur. One such problem is that downstream signaling in general 3346 causes problems because of asymmetric routes. In particular it is 3347 difficult to determine the firewall where the downstream data traffic 3348 will enter a network. The problem of triggering downstream 3349 reservations is for example described in [18] . Another problem for 3350 example is the placement of a firewall or NAT along the path other 3351 than in the access network. This would prevent a successful data 3352 exchange. 3354 The following behavior has to be assumed in order for this approach 3355 to be applicable: 3357 1. It must be possible to trigger a signaling message exchange for a 3358 downstream signaling message exchange at the firewall where the 3359 data traffic enters the network. 3361 2. No other firewalls or NATs are present along the path other than 3362 in the access network. 3364 This approach suffers from the following drawbacks: 3366 1. To signal policy rules only within the access network (by both 3367 end-points) has a number of disadvantage and challenges (see for 3368 example [18] ). The complex message processing caused by this 3369 approach strongly argues against it although it might sound 3370 simple (and even might be simple in restricted environments). 3372 2. Complex topologies might lead to ineffective policy rules (i.e. 3373 data traffic hits firewalls hits wrong firewalls). 3375 D.3 Solution Approach: Authorization Tokens 3377 The last approach is based on some exchanged authorization tokens 3378 which are created by an authorized entity (such as the PDP) or by a 3379 trusted third party. Both end hosts need to exchange these tokens 3380 with protocols such as SIP or HTTP since these protocols are likely 3381 to be allowed to bypass the firewall. The basic idea of this approach 3382 is to provide an end host, which requests access to the network, with 3383 credentials (referred as authorization tokens). These tokens have to 3384 possess some properties, namely: 3386 1. They have to be restrictive by including lifetimes, source and 3387 destination identifiers, usage indication and more. 3389 2. They have to provide basic replay protection to prevent 3390 unauthorized reuse. 3392 3. The have be cryptographically protected to prevent manipulations. 3394 4. There has to be a mechanism to dynamically create them for a 3395 specific reason and to distribute them to the end points. 3397 5. It has to be possible to exchange tokens via a trusted third part 3398 in cases where no direct communication between the end hosts is 3399 possible (due to NAT). 3401 6. The token can be created locally at the network or by a trusted 3402 third party. 3404 An example of a possible signaling communication could have the 3405 following structure: After exchanging the tokens between the two end 3406 hosts. Host A would include the received authorization token to the 3407 signaling message for Network B. When the signaling message arrives 3408 at Middlebox 2 then the token is verified by the token-creating 3409 entity. In order to prevent parties from reusing the token timestamps 3410 (e.g. token creation, token lifetime, etc.) have to be included. 3411 Adding IP address information about Host A would create difficulties 3412 in relationship with NATs. Information about Host B might be possible 3413 to include in order to limit attacks where a token is lost and reused 3414 by a different host for a different purpose. The goal is to restrict 3415 the usage of the token for a specific session. The content of the 3416 token only needs to be verified by the originator of the token since 3417 it only has to be verified locally. Since authorization needs to be 3418 linked to the authorized actions, which have to be performed on the 3419 packets matching the packet filter, the token may include the 3420 associated action or a reference to it. The following behavior has to 3421 be assumed in order for this approach to be applicable: 3423 1. The exchange of authorization tokens between end-systems must be 3424 possible. These protocols must be allowed to pass the firewalls. 3426 2. An end-system must be able to request such an authorization token 3427 at some entity in the local network or at a trusted third party. 3429 This approach suffers from the following drawback: 3431 1. Possibly an additional protocol is required for an end host to 3432 request an authorization token from an entity in the local 3433 network. 3435 Appendix E. Acknowledgments 3437 We would like to acknowledge Vishal Sankhla and Joao Girao for their 3438 input to this draft. 3440 Intellectual Property Statement 3442 The IETF takes no position regarding the validity or scope of any 3443 intellectual property or other rights that might be claimed to 3444 pertain to the implementation or use of the technology described in 3445 this document or the extent to which any license under such rights 3446 might or might not be available; neither does it represent that it 3447 has made any effort to identify any such rights. Information on the 3448 IETF's procedures with respect to rights in standards-track and 3449 standards-related documentation can be found in BCP-11. Copies of 3450 claims of rights made available for publication and any assurances of 3451 licenses to be made available, or the result of an attempt made to 3452 obtain a general license or permission for the use of such 3453 proprietary rights by implementors or users of this specification can 3454 be obtained from the IETF Secretariat. 3456 The IETF invites any interested party to bring to its attention any 3457 copyrights, patents or patent applications, or other proprietary 3458 rights which may cover technology that may be required to practice 3459 this standard. Please address the information to the IETF Executive 3460 Director. 3462 Full Copyright Statement 3464 Copyright (C) The Internet Society (2004). All Rights Reserved. 3466 This document and translations of it may be copied and furnished to 3467 others, and derivative works that comment on or otherwise explain it 3468 or assist in its implementation may be prepared, copied, published 3469 and distributed, in whole or in part, without restriction of any 3470 kind, provided that the above copyright notice and this paragraph are 3471 included on all such copies and derivative works. However, this 3472 document itself may not be modified in any way, such as by removing 3473 the copyright notice or references to the Internet Society or other 3474 Internet organizations, except as needed for the purpose of 3475 developing Internet standards in which case the procedures for 3476 copyrights defined in the Internet Standards process must be 3477 followed, or as required to translate it into languages other than 3478 English. 3480 The limited permissions granted above are perpetual and will not be 3481 revoked by the Internet Society or its successors or assignees. 3483 This document and the information contained herein is provided on an 3484 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3485 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3486 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3487 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3488 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3490 Acknowledgment 3492 Funding for the RFC Editor function is currently provided by the 3493 Internet Society.