idnits 2.17.1 draft-ietf-nsis-nslp-natfw-00.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 4 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? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 833: '... authorization means MUST be provided....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 176 has weird spacing: '...t state is...' == Line 264 has weird spacing: '...ombined with ...' == Line 805 has weird spacing: '...irewall rejec...' == Line 814 has weird spacing: '...ibility is mo...' == Line 861 has weird spacing: '...ited by a...' == (4 more instances...) -- 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 (October 18, 2003) is 7494 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: 'RFC 2113' on line 827 -- Looks like a reference, but probably isn't: 'NATP2P' on line 1068 == Unused Reference: '7' is defined on line 2513, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-nsis-req-07 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-req (ref. '1') ** Obsolete normative reference: RFC 3330 (ref. '2') (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. '3') ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '9') (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '11') (Obsoleted by RFC 5389) == 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: 8 errors (**), 0 flaws (~~), 14 warnings (==), 7 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: April 17, 2004 H. Tschofenig 5 Siemens 6 M. Martin 7 NEC 8 C. Aoun 9 Nortel Networks 10 October 18, 2003 12 A NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 13 draft-ietf-nsis-nslp-natfw-00 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 17, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 This draft describes scenarios, problems and solutions for 45 path-coupled Network Address Translator and Firewall signaling. 46 This is one of the two NSIS Signaling Layer Protocols (NSLPs) the 47 working group will address during its work. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology and Abbreviations . . . . . . . . . . . . . . 5 55 3. Framework and Scenarios . . . . . . . . . . . . . . . . . 7 56 3.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.2 What problem should be solved? . . . . . . . . . . . . . . 7 58 3.3 Basic NSIS Usage for NAT/FW traversal . . . . . . . . . . 8 59 3.4 Scenarios for Protocol Functionality . . . . . . . . . . . 9 60 3.4.1 Firewall traversal . . . . . . . . . . . . . . . . . . . . 9 61 3.4.2 NAT with two private networks . . . . . . . . . . . . . . 10 62 3.4.3 NAT with private network on sender side . . . . . . . . . 11 63 3.4.4 NAT with private network on receiver side . . . . . . . . 11 64 3.4.5 Both end hosts in same private network behind NATs . . . . 12 65 3.4.5.1 Both end hosts in same private network behind same NAT . . 13 66 3.4.6 IPv4/v6 NAT with two private networks . . . . . . . . . . 13 67 3.5 Trust Relationship and Authorization . . . . . . . . . . . 14 68 3.5.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . . . 14 69 3.5.2 Intra-Domain Trust Relationship . . . . . . . . . . . . . 15 70 3.5.3 End-to-Middle Trust Relationship . . . . . . . . . . . . . 16 72 4. Problems and Challenges . . . . . . . . . . . . . . . . . 18 73 4.1 Missing Network-to-Network Trust Relationship . . . . . . 18 74 4.2 End-to-end significance . . . . . . . . . . . . . . . . . 19 75 4.3 Relationship with routing . . . . . . . . . . . . . . . . 19 76 4.4 Dynamic state installation and maintenance . . . . . . . . 20 77 4.5 Affected Parts of the Network . . . . . . . . . . . . . . 20 78 4.6 NSIS backward compatibility with NSIS unaware NAT and 79 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 20 80 4.7 Authentication and Authorization . . . . . . . . . . . . . 21 81 4.8 Directional Properties . . . . . . . . . . . . . . . . . . 21 82 4.9 Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 22 83 4.10 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 22 84 4.11 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 23 85 4.12 Route changes . . . . . . . . . . . . . . . . . . . . . . 23 86 4.13 Combining Middlebox and QoS signaling . . . . . . . . . . 23 87 4.14 Difference between sender- and receiver-initiated 88 signaling . . . . . . . . . . . . . . . . . . . . . . . . 24 89 4.15 Inability to know the scenario . . . . . . . . . . . . . . 24 91 5. NSIS NAT Handling Solution . . . . . . . . . . . . . . . . 25 92 5.1 Problem Description . . . . . . . . . . . . . . . . . . . 25 93 5.2 Solution Overview . . . . . . . . . . . . . . . . . . . . 28 94 5.2.1 Destination IP address Selection . . . . . . . . . . . . . 30 96 6. Protocol Description . . . . . . . . . . . . . . . . . . . 32 97 6.1 Basic protocol overview . . . . . . . . . . . . . . . . . 32 98 6.2 Message format and types . . . . . . . . . . . . . . . . . 32 99 6.3 Message flow . . . . . . . . . . . . . . . . . . . . . . . 35 100 6.4 Middle box configuration . . . . . . . . . . . . . . . . . 36 101 6.5 Message handling . . . . . . . . . . . . . . . . . . . . . 37 102 6.5.1 Detailed behaviour . . . . . . . . . . . . . . . . . . . . 38 103 6.5.1.1 Reserve external address message . . . . . . . . . . . . . 38 104 6.5.1.2 Return external address message . . . . . . . . . . . . . 39 105 6.5.1.3 Create message . . . . . . . . . . . . . . . . . . . . . . 39 106 6.5.1.4 Delete session message . . . . . . . . . . . . . . . . . . 41 107 6.5.1.5 Prolong session message . . . . . . . . . . . . . . . . . 41 108 6.5.1.6 Path Succeded message . . . . . . . . . . . . . . . . . . 41 110 7. Solution examples . . . . . . . . . . . . . . . . . . . . 43 111 7.1 Firewall traversal . . . . . . . . . . . . . . . . . . . . 43 112 7.2 NAT with private network on sender side . . . . . . . . . 43 113 7.3 NAT with private network on receiver side . . . . . . . . 45 114 7.4 Both end hosts are in same private network behind NATs . . 49 115 7.5 IPv4/v6 NAT with two private networks . . . . . . . . . . 52 116 7.6 Full example for NAT/FW with two private networks . . . . 52 118 8. NSIS NAT and Firewall transitions issues . . . . . . . . . 59 120 9. Security Considerations . . . . . . . . . . . . . . . . . 60 122 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 62 124 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . 63 126 Normative References . . . . . . . . . . . . . . . . . . . 64 128 Informative References . . . . . . . . . . . . . . . . . . 65 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 66 132 A. Interworking of SIP with NSIS NATFW NSLP . . . . . . . . . 68 133 A.1 The Session Initiation Protocol . . . . . . . . . . . . . 68 134 A.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 73 136 B. Ad-Hoc networks . . . . . . . . . . . . . . . . . . . . . 74 138 C. Interworking of Security Mechanisms and NSIS NATFW NSLP . 75 140 D. Solution approaches in case of missing authorization . . . 76 141 D.1 Solution Approach: Local authorization from both end 142 points . . . . . . . . . . . . . . . . . . . . . . . . . . 76 143 D.2 Solution Approach: Access Network-Only Signaling . . . . . 77 144 D.3 Solution Approach: Authorization Tokens . . . . . . . . . 77 145 E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 80 147 Intellectual Property and Copyright Statements . . . . . . 81 149 1. Introduction 151 Even though the NSIS WG (Next Steps in Signaling) has QoS signaling 152 as a primary application, other types of applications should be 153 possible. 155 In this draft, we address the scenario, framework, problems, and 156 issues when signaling Network Address Translators (NAT) and/or 157 Firewalls to allow packet traversal. 159 One of the requirements in NSIS [1] is that the NTLP signaling 160 protocol must be independent of the service requested. In some 161 cases the NSIS protocol suite could be used to request end-to-end or 162 edge-to-edge QoS from IP networks; in other cases the service might 163 be allow packet traversal from one host to the other through all the 164 NATs and firewalls deployed on the data path. 166 See also [17] and [18] for proposals to use RSVP or CASP for NAT and 167 Firewall traversal. 169 2. Terminology and Abbreviations 171 This document uses terms defined in [22]. In addition the following 172 terms are used: 174 o NSIS NAT Forwarding State: The term "NSIS NAT Forwarding State" in 175 this context refers to a state used to forward the NSIS signaling 176 message beyond the targeted destination address; that state is 177 typically used when the NSIS Responder address is not known 179 o Sender-/Receiver Initiated Signaling 181 Sender-initiated: NAT bindings and firewall rules are created 182 immediately when the "path" message hits the NSIS nodes. With 183 "path" message we refer to the signaling message traveling from 184 the data sender towards the data receiver. 186 Receiver-initiated: NAT bindings and firewall rules are created 187 when the "resv" message returns from the other end. With 188 "resv" message we refer to a signaling message on the reverse 189 path, this means from the receiver to the sender (i.e. 190 backwards routed). 192 Note that these definitions have nothing to do with number of 193 roundtrips, who performs authorization etc. 195 o Firewalls vs. Security Gateway: As discussed in Section 3.1 196 different types of firewalls exist. This document focuses on 197 firewalls, which perform packet filtering, and possibly 198 application level filtering and does not address IPsec based 199 security gateways. 201 o NSIS Initiator (NI): the signaling entity which makes the resource 202 request, usually as a result of user application request. 204 o NSIS Responder (NR): the signaling entity that acts as the 205 endpoint for the signaling and can optionally interact with 206 applications as well. 208 o NSIS Forwarder (NF): the signaling entity between an NI and NR 209 which propagates NSIS signaling further through the network. 211 o Receiver (DR or R): the node in the network which is receiving the 212 data packets in a flow. 214 o Sender (DS or S): the node in the network which is sending the 215 data packets in a flow. 217 o NATFW NSLP session: an artifact that groups the installed states 218 for a given data flow. 220 o Middlebox: from [21]: "A middlebox is defined as any intermediate 221 device performing functions other than the normal, standard 222 functions of an IP router on the datagram path between a source 223 host and a destination host". The term middlebox in context of 224 this document and in NSIS refers to firewalls and NATs only. 225 Other types of middlebox are currently outside the scope. 227 3. Framework and Scenarios 229 3.1 Scope 231 The term firewall and middlebox in general raises different 232 expectations about the functionality provided by such a device. 233 Different groups have worked on the problem of securing access to a 234 network by using different procedures and protocols. From an 235 abstract point of view two different mechanisms for restricting 236 access to a network can be differentiated: 238 o Packet Filters 240 o Cryptographically protected data traffic 242 Within this document we assume that packet filters are installed at 243 devices along the path. These packet filters may consist of a 5 244 tuple (src/dst ip address, transport protocol, src/dst port). Some 245 devices entitled as firewalls only accept traffic after cryptographic 246 verification (i.e. IPsec protected data traffic). Particularly for 247 network access scenarios either link layer or network layer data 248 protection is common. Hence we do not address these types of devices 249 (referred as security gateways) since per-flow signaling is rather 250 uncommon in this environment. For a discussion of network access 251 authentication and associated scenarios the reader is referred to the 252 PANA working group (see [16]). 254 In mobility scenarios an often experienced problem is the traversal 255 of a security gateway at the edge of the corporate network. Network 256 administrators often rely on the policy that only authenticated data 257 traffic is allowed to enter the network. A problem statement for the 258 traversal of these security gateways in the context of Mobile IP can 259 be found at [15]). 261 3.2 What problem should be solved? 263 The goal of NSIS FW/NAT signaling therefore focuses on packet filter 264 installation combined with associated actions to be enforced on 265 packets matching the filter expression. In the case of NATs and 266 Firewalls the associated actions are packet forwarding and address/ 267 port translation in packet headers. 269 Discovering security gateways, which was also mentioned as an 270 application for NSIS signaling, for the purpose of executing an IKE 271 to create an IPsec SA, is already solved without requiring NSIS. 273 Installing packet filters provides some security but has some 274 weaknesses, which heavily depend on the type of packet filter 275 installed. A packet filter cannot prevent an adversary to inject 276 traffic (due to the IP spoofing capabilities). This type of attack 277 might not be particular helpful if the packet filter is a standard 5 278 tuple which is very restrictive. If packet filter installation, 279 however, allows specifying a rule, which restricts only the source IP 280 address, then IP spoofing allows transmitting traffic to an arbitrary 281 address. NSIS aims to provide path-coupled signaling and therefore 282 an adversary is somewhat restricted in the location from which 283 attacks can be performed. Some trust is therefore assumed from nodes 284 and networks along the path. 286 3.3 Basic NSIS Usage for NAT/FW traversal 288 The basic high-level picture of NSIS usage is that of the endhosts 289 signaling to establish packet filters and NAT bindings on a data 290 path, which allows the said data to travel from the endhost to the 291 endpoint unobstructed. 293 Therefore it is necessary that each firewall and each NAT involved in 294 the signaling communication runs an NSIS daemon. There might be 295 several NATs and FWs in various possible combinations on a path 296 between two hosts. The reader is referred to Section 3.4 where 297 different scenarios are presented. 299 Application Application Server (0, 1, or more) Application 301 +----+ +----+ +----+ 302 | +------------------------+ +------------------------+ | 303 +-+--+ +----+ +-+--+ 304 | | 305 | NSIS Agents | 306 +-+--+ +----+ +-----+ +-+--+ 307 | +--------+ +----------------------------+ +-----+ | 308 +-+--+ +-+--+ +--+--+ +-+--+ 309 | | ------ | | 310 | | //// \\\\\ | | 311 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 312 | | | | | Internet | | | | | 313 | +--------+ +-----+ +----+ +-----+ | 314 +----+ +----+ |\ | +----+ +----+ 315 \\\\ ///// 316 sender NAT/FW (1+) ------ NATFW (1+) receiver 318 Figure 1: Generic View on NSIS in a NAT / Firewall case 320 3.4 Scenarios for Protocol Functionality 322 This section introduces several scenarios for middleboxes in the 323 Internet. These middleboxes are firewalls or different flavours of 324 NATs [5], like NAPT. Combinations of Firewalls and NATs in the same 325 device are possible as well. 327 Each section introduces a different scenario for a different set of 328 middleboxes and their ordering within the topology. 330 3.4.1 Firewall traversal 332 The following scenario shows two end hosts behind a firewall but 333 connected via the public Internet. The application can somehow 334 trigger firewall traversal (e.g. via an API call) at the NSIS agent 335 at the local host. The NSIS agent then signals this request to the 336 next NSIS aware node and therefore to the receiver. Each firewall in 337 the middle must provide traversal service in order to permit the NSIS 338 message to reach the other end host. 340 The difference between this scenario and the following is that 341 firewalls are on the path, but no NATs. This has specific 342 implication concerning the used destination address for path-coupled 343 signaling message sent by the NSIS Initiator to an NR hosted behind a 344 NAT. 346 +----+ //----\\ +----+ 347 S -----| FW |---| |------| FW |--- R 348 +----+ \\----// +----+ 350 private public private 352 FW: Firewall 353 S: Data Sender 354 R: Data Receiver 356 Figure 2: Firewall Traversal Scenario 358 3.4.2 NAT with two private networks 360 This scenario deals with NATs on both ends of the network. 361 Therefore, each application instance is behind a NAT and is connected 362 to the public Internet (see Figure 3 ). 364 The case where more than one MB on each side ("only" two are shown in 365 the figure) is present must be taken into account. This aspect 366 introduces more topology problems. 368 +----+ +----+ //----\\ +----+ +----+ 369 S --| MB |-----| MB |---| |---| MB |-----| MB |--- R 370 +----+ +----+ \\----// +----+ +----+ 372 private public private 374 MB: Middlebox 375 S: Data Sender 376 R: Data Receiver 378 Figure 3: NAT with two private networks Scenario 380 Data traffic from the sender to the receiver has to traverse all four 381 middleboxes on the path and all four middleboxes must be configured 382 properly to allow subsequent data packets to flow. The sender has to 383 know the IP address of the receiver in advance, i.e. before any NSIS 384 message can be sent. Or more general the NSIS Initiator must know 385 the IP addresses of the NSIS Responder, otherwise he cannot send a 386 single NSIS signaling message towards the responder. Note that this 387 IP address is not the private IP address of the responder. Instead a 388 NAT binding (including a public IP address) has to be obtained from 389 the NAT which subsequently allows packets hitting the NAT to be 390 forwarded to the receiver within the private address realm. This in 391 general requires further support from an application layer protocol 392 for the purpose of discovering and exchanging information. The 393 receiver might have a number of ways to learn its public IP address 394 and port number and might need to signal this information to the 395 sender using the application level signaling protocol. 397 3.4.3 NAT with private network on sender side 399 This scenario shows an application instance at the sending node which 400 is behind one ore more FW/NATs. The receiver is located in the 401 public internet. 403 +----+ +----+ //----\\ 404 S --| MB |-----| MB |---| |--- R 405 +----+ +----+ \\----// 407 private public 409 MB: Middlebox 410 S: Data Sender 411 R: Data Receiver 413 Figure 4: NAT with private network on sender scenario 415 The traffic from the sender to the receiver has to traverse only 416 middleboxes on the sender's side. The receiver has a public IP 417 address and therefore the procedure is simple. The sender sends its 418 signaling message directly to the receiver whereby it is intercepted 419 by the middleboxes along the path. 421 Note that the data sender does not necessarily know whether the 422 receiver is behind a NAT or not, hence, it is the receiving side that 423 has to detect the whether it is behind a NAT or not. As described in 424 Section 5 NSIS can also provide help for this procedure. 426 3.4.4 NAT with private network on receiver side 428 The application instance receiving data is behind one or more NATs. 430 //----\\ +----+ +----+ 431 S ---| |---| MB |-----| MB |--- R 432 \\----// +----+ +----+ 434 public private 436 MB: Middlebox 437 S: Data Sender 438 R: Data Receiver 440 Figure 5: NAT with private network on receiver Scenario 442 First, the sender must determine the public IP address of the 443 receiver. 445 One possibility is that an application level protocol is used. In 446 this case, the receiver must first find out its public IP addresses 447 at the middlebox on its side. This information about IP address and 448 port numbers could be signalled somehow to the actual sender directly 449 or indirectly via a third party. In the scenario, this means the 450 receiver has to determine its public IP address (NAT binding) and 451 register this address with the third party. 453 The sender can start NSIS signaling after he has received information 454 about the receiver's address and port number. 456 Note: The solution design will determine where to discontinue 457 forwarding the signaling messages. 459 3.4.5 Both end hosts in same private network behind NATs 461 This is a special case, where the main problem is to detect that both 462 nodes are within the same network behind a NAT. This scenario 463 primarily addresses performance aspects. 465 Sender and receiver are both within a private address realm and 466 potentially have overlapped addresses. Figure 6 shows the ordering 467 of NATs. This is a common configuration in several networks, 468 particularly after the merging of companies that have overlapped 469 addresses. 471 public 472 +----+ +----+ //----\\ 473 S --| MB |--+--| MB |---| | 474 +----+ | +----+ \\----// 475 | 476 | +----+ 477 +--| MB |------------ R 478 +----+ 480 private 482 MB: Middlebox 483 S: Data Sender 484 R: Data Receiver 486 Figure 6: NAT to public, receiver in same private network Scenario 488 The middleboxes are twice-NATs, i.e. they map the IP addresses and 489 port numbers on both sides, private and public interface. 491 From a protocol point of view, this means that the protocol must be 492 robust enough to at least not break with this scenario. 494 In the worst case, both sender and receiver obtain a public IP 495 address at the NAT and the communication path is not optimal anymore. 497 3.4.5.1 Both end hosts in same private network behind same NAT 499 A slight variation of the previous scenario consists in having both 500 the DS and the DR behind the same NAT. In case the data sender and 501 data receiver can not communicate which address is the most suitable 502 among the several available (local scoped or globally scoped) 503 addresses to be used for the NSIS messages, the protocol should be 504 robust enough to handle the worst case, where the messages are sent 505 through the NAT. 507 3.4.6 IPv4/v6 NAT with two private networks 509 This scenario combines the usage case mentioned in Section 3.4.2 with 510 the IPv4 to IPv6 transition scenario, i.e. using Network Address and 511 Protocol Translators (NAT-PT). 513 The difference to the other scenarios lies in the use of IPv6 - IPv4 514 address translation, which happens in both directions. Additionally, 515 the base NTLP must take care of this case for its own functionality 516 of forwarding messages between NSIS peers. 518 +----+ +----+ //----\\ +----+ //----\\ +----+ +----+ 519 S --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- R 520 +----+ +----+ \\----// +----+ \\----// +----+ +----+ 522 private public public private 523 IPv4 IPv6 525 MB: Middlebox 526 S: Data Sender 527 R: Data Receiver 529 Figure 7: IPv4/v6 NAT with two private networks 531 3.5 Trust Relationship and Authorization 533 Trust relationships and authorization are very important for the 534 protocol machinery. Trust and authorization closely related to each 535 other in the sense that a certain degree of trust is required to 536 authorize a particular action. If the action is "create/delete 537 packet filters" then authorization is very important due to the 538 nature of a firewall. 540 It is not particularly surprising that differences exist between 541 authorization in a QoS signaling environment and firewall signaling. 542 As elaborated in [13] the establishment of a financial relationship 543 is very important for QoS, signaling whereas for firewall signaling 544 is not directly of interest. 546 In the subsequent sections different trust relationships will be 547 described which appear in firewall signaling environments. 548 Peer-to-peer trust relationships are those, which are used in QoS 549 signaling today and seem to be the simplest. However, there are 550 reasons to believe that this is not the only type of trust 551 relationship found in today's networks. 553 3.5.1 Peer-to-Peer Trust Relationship 555 Starting with the simplest scenario it is assumed that neighboring 556 nodes trust each other. The required security association to 557 authenticate and to protect a signaling message is either available 558 (manual configuration) or dynamically established with the help of an 559 authentication and key exchange protocol. If nodes are located 560 closely together it is assumed that security association 561 establishment is easier than establishing it between far distant 562 node. It is, however, difficult to describe this relationship 563 generally due to the different usage scenarios and environments. 565 Authorization heavily depends on the participating entities but for 566 this scenario it is assumed that neighboring entities trust each 567 other (at least for the purpose of packet filter creation and 568 deletion). Note that Figure 8 does not illustrate the trust 569 relationship between the end host and the access network, which is 570 dynamically established as part of the network access authentication 571 procedure as stated in Section 1. 573 +------------------------+ +-------------------------+ 574 | | | | 575 | Network A | | Network B | 576 | | | | 577 | +---------+ +---------+ | 578 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 579 | | | box 1 | Trust | box 2 | | | 580 | | +---------+ Relationship +---------+ | | 581 | | | | | | 582 | | | | | | 583 | | | | | | 584 | | Trust | | Trust | | 585 | | Relationship | | Relationship | | 586 | | | | | | 587 | | | | | | 588 | | | | | | 589 | +--+---+ | | +--+---+ | 590 | | Host | | | | Host | | 591 | | A | | | | B | | 592 | +------+ | | +------+ | 593 +------------------------+ +-------------------------+ 595 Figure 8: Peer-to-Peer Trust Relationship 597 3.5.2 Intra-Domain Trust Relationship 599 In larger corporations often more than one firewall is used to 600 protect different departments. In many cases the entire enterprise 601 is controlled by a security department, which gives instructions to 602 the department administrators. In such a scenario a peer-to-peer 603 trust-relationship might be prevalent. Sometimes however it might be 604 necessary to preserve authentication and authorization information 605 within the network. As a possible solution a centralized approach 606 could be used whereby an interaction between the individual 607 middleboxes and a central entity (for example a policy decision point 608 - PDP) takes place. As an alternative individual firewalls could 609 exchange the authorization decision to another firewalls within the 610 same trust domain. Individual middleboxes within an administrative 611 domain should exploit their trust relationship instead of requesting 612 authentication and authorization of the signaling initiator again and 613 again. Thereby complex protocol interaction is avoided. This 614 provides both a performance improvement without a security 615 disadvantage since a single administrative domain can be seen as a 616 single entity. Figure 9 illustrates a network structure which uses a 617 centralized entity. 619 +-----------------------------------------------------------+ 620 | | 621 | Network A | 622 | | 623 | | 624 | +---------+ +---------+ 625 | +----///--------+ Middle- +------///------++ Middle- +--- 626 | | | box 2 | | box 2 | 627 | | +----+----+ +----+----+ 628 | | | | | 629 | +----+----+ | | | 630 | | Middle- +--------+ +---------+ | | 631 | | box 1 | | | | | 632 | +----+----+ | | | | 633 | | | | | | 634 | - | | | | 635 | - | +----+-----+ | | 636 | | | | Policy | | | 637 | +--+---+ +-----------+ Decision +----------+ | 638 | | Host | | Point | | 639 | | A | +----------+ | 640 | +------+ | 641 +-----------------------------------------------------------+ 643 Figure 9: Intra-domain Trust Relationship 645 3.5.3 End-to-Middle Trust Relationship 647 In some scenarios a simple peer-to-peer trust relationship between 648 participating nodes is not sufficient. Network B might require 649 additional authorization of the signaling message initiator. If 650 authentication and authorization information is not attached to the 651 initial signaling message then the signaling message arriving at 652 Middlebox 2 would cause an error message to be created, which 653 indicates the additional authorization requirement. In many cases 654 the signaling message initiator is already aware of the additionally 655 required authorization before the signaling message exchange is 656 executed. Replay protection is a requirement for authentication to 657 the non-neighboring firewall which might be difficult to accomplish 658 without adding additional roundtrips to the signaling protocol (e.g. 659 by adding a challenge/response type of message exchange). 661 Figure 10 shows the slightly more complex trust relationships in this 662 scenario. 664 +----------------------+ +--------------------------+ 665 | | | | 666 | Network A | | Network B | 667 | | | | 668 | | Trust | | 669 | | Relationship | | 670 | +---------+ +---------+ | 671 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 672 | | | box 1 | +-------+ box 2 | | | 673 | | +---------+ | +---------+ | | 674 | | | | | | | 675 | |Trust | | | | | 676 | |Relationship | | | | | 677 | | | | | Trust | | 678 | | | | | Relationship| | 679 | | | | | | | 680 | | | | | | | 681 | | | | | | | 682 | | | | | | | 683 | +--+---+ | | | +--+---+ | 684 | | Host +----///----+------+ | | Host | | 685 | | A | |Trust | | B | | 686 | +------+ |Relationship | +------+ | 687 +----------------------+ +--------------------------+ 689 Figure 10: End-to-Middle Trust Relationship 691 4. Problems and Challenges 693 This section describes a number of problems which have to be 694 addressed for NSIS NAT/Firewall. These are also of relevance for 695 other NSLP protocols. 697 4.1 Missing Network-to-Network Trust Relationship 699 Peer-to-peer trust relationship, as shown in Figure 8, is a very 700 convenient assumption that allows simplified signaling message 701 processing. However, it might not always be applicable, especially 702 between two arbitrary access networks (over a core network where 703 signaling messages are not interpreted) does possibly not exist 704 because of the large number of networks and the unwillingness of 705 administrators to have other network operators to create holes in 706 their firewalls without proper authorization. Hence in the following 707 scenario we assume a somewhat different message processing and show 708 three possible approaches to tackle the problem. None of these three 709 approaches is without drawbacks or constraining assumptions. 711 +----------------------+ +--------------------------+ 712 | | | | 713 | Network A | | Network B | 714 | | | | 715 | +---------+ Missing +---------+ | 716 | +-///-+ Middle- | Trust | Middle- +-///-+ | 717 | | | box 1 | Relation- | box 2 | | | 718 | | +---------+ ship +---------+ | | 719 | | | or | | | 720 | | | Authorization| | | 721 | | | | | | 722 | | Trust | | Trust | | 723 | | Relationship | | Relationship | | 724 | | | | | | 725 | | | | | | 726 | | | | | | 727 | +--+---+ | | +--+---+ | 728 | | Host | | | | Host | | 729 | | A | | | | B | | 730 | +------+ | | +------+ | 731 +----------------------+ +--------------------------+ 733 Figure 11: Missing Network-to-Network Trust Relationship 735 Figure 11 illustrates a problem whereby an external node is not 736 allowed to manipulate (create, delete, query, etc.) packet filters at 737 a firewall. Opening pinholes is only allowed for internal nodes or 738 with a certain authorization permission. Hence the solution 739 alternatives in Section 5 focus on establishing the necessary trust 740 with cooperation of internal nodes. 742 4.2 End-to-end significance 744 In the case of NAT/firewalls traversal, the NSIS signaling messages 745 need to be sent all they way from the DS and DR or viceversa. This 746 is so because a middle box does not know wether the remaining path to 747 the destination is clear of pottentially obstructing middleboxes or 748 not. 750 4.3 Relationship with routing 752 The data path is following the "normal" routes. The NAT/FW devices 753 along the data path are those providing the service. In this case 754 the service is something like "open a pinhole" or even more general 755 "allow for connectivity between two communication partners". The 756 benefit of using path-coupled signaling is that the NSIS NATFW NSLP 757 does not need to determine what middleboxes or in what order the data 758 flow will go through. 760 Creating NAT bindings modifies routing of data packets between end 761 points. This is unlike other NSIS NSLPs, which do not interfere with 762 routing - instead they only follow the path of the data packets. 764 4.4 Dynamic state installation and maintenance 766 For NAT/Firewall traversal, the lifetime of a NAT binding or a packet 767 filter must be determined is often mantained through periodic 768 refresh.For short-lived flows, having unpredictable filtersi, 769 signaling for pinholes and NAT bindings is preferable as opposed to 770 statically configured NAT bindings and pinholes requested for long 771 duration in time. The capability to specify a lifetime for a NAT 772 binding provides some advantages to what exists today where unknown 773 NAT binding lifetimes can lead to unexpected protocol actions. 775 For static state other mechanisms than an NSIS signaling protocol 776 might be preferable; such mechanisms would include a management 777 protocols such as SNMP or CLI. 779 4.5 Affected Parts of the Network 781 NATs and Firewalls tend to be located at the edge of the network, 782 whereby other signaling applications affect all nodes along the path. 783 One typical example is QoS signaling where all networks along the 784 path must provide QoS in order to achieve true end-to-end QoS. In 785 the NAT/Firewall case, only some of the domains/nodes are affected 786 (typically access networks), whereas most parts of the networks and 787 nodes are unaffected (e.g. the core network). 789 This fact raises some questions. Should an NSIS NTLP node intercept 790 every signaling message independently of the upper layer signaling 791 application or should it be possible to make the discovery procedure 792 more intelligent to skip nodes. These questions are also related to 793 the question whether NSIS NAT/FW should be combined with other NSIS 794 signaling applications. 796 4.6 NSIS backward compatibility with NSIS unaware NAT and Firewalls 798 Backward compatibility is key for NSIS deployments, as such the NSIS 799 protocol suite should be sufficiently robust to allow traversal of 800 none NSIS aware routers (Qos gates, Firewalls, NATs, etc ) 802 NSIS NATFW NSLP's backward compatibility issues is different than the 803 NSIS QoS NSLP backward compatibility issues, where an NSIS unaware 804 Qos gate will simply forward the Qos NSLP message. An NSIS unaware 805 firewall rejects NSIS messages, since firewalls typically implement 806 the policy "default = deny". 808 The NSIS backward compatibility support on none NSIS aware firewall 809 would typically consist of configuring a static policy rule that 810 allows the forwarding of the NSIS protocol messages (either protocol 811 type if raw transport mode is used or transport port number in case a 812 transport protocol is used). 814 For NATs backward compatibility is more problematic since signaling 815 messages are forwarded (at least in one direction), but with a 816 changed IP address and changed port numbers. The content of the NSIS 817 signaling message is, however, unchanged. This can lead to 818 unexpected results, both due to embedded unchanged local scoped 819 addresses and none NSIS aware firewalls configured with specific 820 policy rules allowing forwarding of the NSIS protocol (case of 821 transport protocols are used for the NTLP). NSIS unaware NATs must 822 be detected to maintain a well known deterministic mode of operation 823 for all the involved NSIS entities. Such a "legacy" NAT detection 824 procedure can be done during the NSIS discover procedure itself. 826 Based on experience it was discovered that routers unaware of the 827 Router Alert IP option [RFC 2113] discarded packets,this is certainly 828 a problem for NSIS signaling. 830 4.7 Authentication and Authorization 832 Since a firewall has security functionality, strong authentication 833 and authorization means MUST be provided. 835 For NATs security is not a major concern, but might play a role in 836 the perceived security measure of some administrators. For NAT 837 sometimes address depletion is considered as a threat. 839 4.8 Directional Properties 841 There two directional properties that need to be addressed by the 842 NATFW NSLP: 844 o Directionality of the data 846 o Directionality of NSLP signaling 848 Both properties are relevant to NATFW NSLP aware NATs and Firewalls. 850 With regards to NSLP signaling directionality: As stated in the 851 previous sections, the authentication and authorization of NSLP 852 signaling messages received from hosts within the same trust domain 853 (typically from hosts located within the security perimeter delimited 854 by firewalls) is normally simpler than received messages sent by 855 hosts located in different trust domains. 857 The way NSIS signaling messages enters the NSIS agent of a firewall 858 (see Figure 2) might be important, because different policies might 859 apply for authentication and admission control. 861 Hosts deployed within the secured network perimeter delimited by a 862 Firewall, are protected from hosts deployed outside the secured 863 network perimeter, hence by nature the firewall has more restrictions 864 on flows triggered from hosts deployed outside the security 865 perimeter. 867 As opposed to traditional NAT [6] where the NAT bind was implicitly 868 created when an outbound packet was sent; the NSIS NATFW NSLP aware 869 NATs will be explicitly requested to create NAT binds. Hence data 870 packet directionality is no longer significant for the bind creation, 871 in the case of signaled NAT bind creations on NSIS aware NATs. 872 However depending on the used NAT implementation, data directionality 873 may still apply to implicitly maintain the NAT bind (since NAT binds 874 consume memory and addressing resources); as such some NAT 875 implementation might still require that outbound packet ONLY maintain 876 (implicitly and not explicitly) binds. 878 4.9 Routing Asymmetry 880 Routing asymmetry [14] is a general problem for path-coupled 881 signaling, especially when installed states on NSIS forwarders are 882 related to bi-directional flows. 884 Path state, on an NSIS forwarder, including the next NSIS hop (for 885 packets sent from the NR to NI), is used to handle routing asymmetry 886 for NSIS messages but not for data flows (i.e. no route pinning for 887 data flows). 889 Similarly to path-coupled QoS signaling, firewall signaling also has 890 to be aware of the routing asymmetry when bi-directional flows 891 relevant states need to be installed on NSIS aware nodes, although 892 the routing asymmetry might not be significant within the local 893 networks where firewalls are typically located. For signaling NAT 894 bindings this issue comes with a different flavor since an 895 established NAT binding changes the path of the data packets. Hence 896 a data receiver might still be able to send NSIS signaling messages 897 to create a NAT binding, although they travel the previously "wrong" 898 path. 900 4.10 Addressing 901 A more general problem of NATs is the addressing of the end-point. 902 NSIS signaling message have to be addressed to the other end host to 903 follow data packets subsequently sent. Therefore a public IP address 904 of the receiver has to be known prior to sending an nsis message. 905 When NSIS signaling messages contain IP addresses of the sender and 906 the receiver in the signaling message payloads, then an NSIS agent 907 must modify them. This is one of the cases, where a NSIS aware NATs 908 is also helpful for other types of signaling applications e.g. QoS 909 signaling. 911 4.11 NTLP/NSLP NAT Support 913 It must be possible for NSIS NATs along the path to change NTLP and/ 914 or NSLP message payloads , which carry IP address and port 915 information. This functionality includes the support of providing 916 mid-session and mid-path modification of these payloads. As a 917 consequence these payloads must not be reordered, integrity protected 918 and/or encrypted in a non peer-to-peer fashion (e.g. end-to-middle, 919 end-to-end protection). Ideally these mutable payloads must be 920 marked (e.g. a protected flag) to assist NATs in their effort of 921 adjusting these payloads. 923 4.12 Route changes 925 The effect of route changes are more severe than in other signaling 926 applications since a firewall pinhole and NAT binding is needed 927 before further communication can takes place. This is true for both 928 NSIS signaling and for subsequent data traffic. If a route changes 929 and NSIS signaling messages do not configure NSIS NATs and firewalls 930 along the new path then the communication is temporarily interrupted. 931 This is naturally a big problem for networks where routes frequently 932 change e.g. ad-hoc networks or in case of fast mobility. In these 933 cases state refresh messages have to provide a mechanism for fast 934 reaction. 936 4.13 Combining Middlebox and QoS signaling 938 In many cases, middlebox and QoS signaling has to be combined at 939 least logically. Hence it was suggested to combine them into a 940 single signaling message or to tie them together with the help of 941 some sort of data connection identifier, later on refered as Session 942 ID. This, however, has some disadvantages such as: 944 - NAT/FW NSLP signaling affects a much small number of NSIS nodes 945 along the path (for example compared to the QoS signaling). 947 - NAT/FW signaling might show different signaling patterns (e.g. 948 required end-to-middle communication). 950 - The refresh interval is likely to be different. 952 - The number of error cases increase as different signaling 953 applications are combined into a single message. The combination of 954 error cases has to be considered. 956 4.14 Difference between sender- and receiver-initiated signaling 958 For NAT/FW signaling there seems to be little difference between 959 sender- and receiver- initiated signaling messages. Some other 960 characteristics of QoS signaling protocols are not applicable (e.g. 961 the adspec object) to the NAT/FW context. It seems that a full 962 roundtrip is always required if the protocol aims to be generic 963 enough. 965 4.15 Inability to know the scenario 967 In Section 3.4 a number of different scenarios are presented. In 968 some scenario NSIS signaling is fairly easy whereas in others it is 969 quite complex. Additionally different trust relationships exist 970 between networks along the path, which might require interaction with 971 the end host or a different signaling behavior. However, the user 972 (or the NSIS agent initially) typically does not know which scenario 973 is currently applicable. To make things worse, the scenario might 974 actually change with moving networks, adhoc networks or with mobility 975 in general. Hence NSIS signaling must assume the worst case and 976 cannot put responsibility to the user to know which scenario is 977 currently applicable. As a result, it might be necessary to perform 978 a "discovery" periodically such that the NSIS agent at the end host 979 has enough information to decide which scenario is currently 980 applicable. This additional messaging, which might not be necessary 981 in all cases, eats performance, bandwidth and adds complexity. 982 Additional information by the user can provide information to assist 983 this "discovery" process but cannot replace it. 985 Some protocols already aim to provide a solution for an end host to 986 learn something about the topology such as STUN [11]. To some extend 987 these protocols can help NSIS NAT/FW signaling. 989 5. NSIS NAT Handling Solution 991 This section describes a mechanism for allowing NSIS signaling 992 messages to travel end-to-end in the presence of NATs at the 993 receiving side. This requires to establish state information at the 994 NSIS-aware NAT device. 996 Note: The discussed mechanism only creates state relevant for NSIS 997 message handling. It does not create NAT bindings for data traffic. 999 5.1 Problem Description 1001 NSIS signaling messages follow the data path from the data sender to 1002 the data receiver. To provide this property of being path-coupled 1003 the discovery process sends signaling messages along the same route 1004 as taken by subsequent data packets. The NSIS messages are directed 1005 to a particular destination IP address and hence the destination 1006 address needs to be known in advance before NSIS signaling can 1007 start. 1009 +-------------+ AS-Data Receiver Communication 1010 +-------->| Application |<-----------------------------+ 1011 | | Server | | 1012 | +-------------+ | 1013 | IP(R-NAT_B) | 1014 | NSIS Signaling Message +-------+--+ 1015 | +------------------------------------------>| NAT/NAPT | 1016 | | | B | 1017 | | +-------+--+ 1018 | | | 1019 AS-Data| | | 1020 Receiver| | +----------+ | 1021 Comm.| | | NAT/NAPT | | 1022 | | | A | | 1023 | | +----------+ | 1024 | | | 1025 | | | 1026 | | | 1027 | | | 1028 v | IP(R) v 1029 +--------+ +---------+ 1030 | Data | | Data | 1031 | Sender | | Receiver| 1032 +--------+ +---------+ 1034 Figure 12: The Data Receiver behind NAT problem 1036 Figure 12 describes a typical message communication in a peer-to-peer 1037 networking environment whereby the two end points learn of each 1038 others existence with the help of a third party (referred as 1039 Application Server). The communication with the application server 1040 and the two end points (data sender and data receivers) serves a 1041 number of functions. As one of the most important functions it 1042 enables the two end hosts to learn the IP address of each other. 1044 Without the proposed mechanism it would not be possible to establish 1045 a NAT binding end-to-end in all scenarios. 1047 Some sort of communication between the end hosts and a third party is 1048 typically necessary (independently of NSIS). NSIS signaling messages 1049 cannot be used to communicate application level relevant end point 1050 identifiers (in the generic case at least) as a replacement for the 1051 communication with the application server. 1053 If the data receiver is behind a NAT then an NSIS signaling message 1054 will be addressed to the IP address allocated at the NAT (if there 1055 was one allocated). If no corresponding NSIS NAT Forwarding State at 1056 NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the signaling 1057 message will terminate at the NAT device (most likely without proper 1058 response message). The signaling message transmitted by the data 1059 sender cannot install the NAT binding or NSIS NAT Forwarding State 1060 "on-the-fly" since this would assume that the data sender knows the 1061 topology at the data receiver side (i.e. the number and the 1062 arrangement of the NAT and the private IP address(es) of the data 1063 receiver). The primary goal of path-coupled middlebox communication 1064 was not to force end hosts to have this type of topology knowledge. 1066 A number of solutions exist to allow nodes behind a NAT to establish 1067 a NAT binding to allow the receiver to receive IP packets. These 1068 solutions can at best be labeled as hacks (see [NATP2P]) and they 1069 have their drawbacks: 1071 o They assume a certain behavior of NAT boxes. 1073 o They work in some environments whereas in others they do not 1074 properly function. 1076 o They only allow NAT bindings for UDP traffic to be established. 1078 o They often fail. 1080 Some other solutions assume that both nodes are registered in the DNS 1081 directory (see [19]). 1083 The requirements for an NSIS solution are two-fold: 1085 1. NSIS signaling messages must be able to travel end-to-end 1086 (between data sender and data receiver) - if desired. This is 1087 important for a number of NSIS NSLPs 1089 2. NSIS relies on a generic solution which works in all scenarios 1090 (see section 5 of [22]). 1092 Since the NSIS signaling messages are intercepted at each NSIS device 1093 the NAT solution depends on the properties of the NTLP. In 1094 particular, multiplexing capability is important. Two possible 1095 options are feasible: 1097 1. Multiplexing with the help of transport layer information (i.e. 1098 port information) 1100 2. Multiplexing at the NSIS application layer (e.g. based on 1101 session identifier) 1103 We describe the second approach although we believe that alternatives 1104 are possible. 1106 Enough information has to be available to convert IP address 1107 information of an incoming signaling message to different IP 1108 addresses of an outgoing NSIS message. Finally the signaling message 1109 must reach the data receiver. 1111 It seems that the session identifier can be used to associate state 1112 information of the two independent signaling exchanges. The two 1113 exchanges (as described in Section 5.2) are: 1115 1. Signaling exchange from the data receiver (NR) to the NAT(s) 1117 2. End-to-end NSIS signaling message exchange from the NI to the NR. 1119 If the session identifier is used for this purpose then it is 1120 necessary to communicate the session id from the data receiver (NR) 1121 to the NI. Communicating the IP address information instead (as an 1122 alternative solution approach) is easier since this functionality is 1123 already provided by SIP whereas securely exchanging (e.g. 1124 confidentiality protected) the Session Identifier is not available. 1126 5.2 Solution Overview 1128 The data receiver starts to signal an NSIS Create-NAT-Binding message 1129 into the "wrong direction". By "wrong" we refer to the usual 1130 behavior of path-coupled signaling where the data sender starts 1131 signaling in order to tackle with routing asymmetry. The data 1132 receiver would typically return signaling messages to the data sender 1133 in the reverse direction by utilizing state created at nodes along 1134 the path (i.e. to reverse route signaling messages). The concept of 1135 path-coupled or path-decoupled signaling is, however, no relevant for 1136 this special type of signaling communication. In case of 1137 establishing NAT bindings (and NSIS NAT Forwarding State) the 1138 direction does not matter since routing is modified. Subsequent NSIS 1139 messages (and also data traffic) will travel through the same NAT 1140 boxes. 1142 The proposed solution requires two NSIS signaling messages: 1144 1. Create-NAT-Binding Request 1146 2. Create-NAT-Binding Acknowledgement 1148 The semantic of the two messages will be described in detail in this 1149 section. 1151 The data receiver sends a Create-NAT-Binding NSIS signaling message 1152 into the local network (before the data sender starts NSIS 1153 signaling). In Section Section 5.2.1 we will discuss where to 1154 address this signaling message (i.e. which destination IP address to 1155 use). 1157 The signaling message creates NSIS NAT Forwarding State at 1158 intermediate NSIS NAT node(s). Furthermore it has to be ensured that 1159 the edge NAT device is discovered as part of this process. By edge 1160 NAT we refer to the NAT device which is reachable from outside and 1161 has a globally routable IP address. The end host cannot be assumed 1162 to know this device - instead the NAT box itself is assumed to know 1163 that it has such a capability. Forwarding of the Create-NAT-Binding 1164 NSIS message beyond this entity is not necessary, and should be 1165 prohibited as it provides information on internal hosts capabilities. 1167 Create-NAT-Binding Request 1168 +-------+ +-------+ +-------+ +---------+ 1169 | NAT X |<---| NAT Y |<---| NAT Z |<---| Data | 1170 | |--->| |--->| |--->| Receiver| 1171 +-------+ +-------+ +-------+ +---------+ 1172 Create-NAT-Binding Response 1174 ========================================> 1175 Data Traffic Direction 1177 Figure 13: Create-NAT-Binding NSIS Signaling Message 1179 The goal of this signaling message exchange is: 1181 o to create one (or more) NAT binding(s) 1183 o to allow the data receiver to learn its global routable IP address 1184 (for communication with NSIS) 1186 o not to require the data receiver to learn topology information. 1188 Figure 13 shows a number of NAT devices at the data receivers network 1189 side. NSIS NAT Forwarding State is established at these network 1190 elements. 1192 The Create-NAT-Binding Request message triggers the state creation 1193 and the discovery. The message carries information where the sender 1194 expects incoming NSIS signaling messages. 1196 The Create-NAT-Binding Response message confirms the state creation 1197 and allows to return information about the NATs and the topology to 1198 the end host (for informational purposes). As a result the end host 1199 will learn the public IP address which can be used by the data sender 1200 to address NSIS signaling messages. 1202 5.2.1 Destination IP address Selection 1204 The Create-NAT-Binding Request message has to be addressed to a 1205 specific destination IP address. Since there is no natural candidate 1206 a few alternatives might be considered. The discussed options refer 1207 to entities of Figure 12 1209 Possible options are: 1211 1. Public IP address of the data sender 1213 2. Public IP address of the data receiver (allocated at NAT B) 1215 3. IP address at the Application Server 1217 Actually, there is no "correct" answer to this question and from a 1218 theoretical point of view it does not really matter as long as Host A 1219 learns an IP address where he has to send the NSIS signaling message. 1220 >From a performance point of view there is, however, a difference 1221 since it would be desirable to create an "optimal" routing path. 1223 1. Public IP address of the data sender: 1225 * Assumption: 1227 + The data receiver already learned the IP address of the 1228 data sender (e.g. via a third party). 1230 * Problems: 1232 + The data sender might also be behind a NAT. In this case 1233 the public IP address of the data receiver is the IP 1234 address allocated at this NAT. 1236 + Due to routing asymmetry it might be possible that the 1237 routes taken by a) the data sender and the application 1238 server b) the data sender and NAT B might be different. As 1239 a consequence it might be necessary to advertise a new (and 1240 different) external IP address with SIP after using NSIS to 1241 establish a NAT binding. 1243 2. Public IP address of the data receiver (allocated at NAT B): 1245 * Assumption: 1247 + The data receiver already learned his externally visible IP 1248 address (e.g. based on the third party communication). 1250 * Problems: 1252 + Communication with a third party is required. 1254 3. IP address at the Application Server: 1256 * Assumption: 1258 + An application server (or a different third party) is 1259 available. 1261 * Problems: 1263 + If the NSIS signaling message is not terminated at the NAT 1264 of the local network then an NSIS unaware application 1265 server might discard the message. 1267 + Routing might not be optimal since the route between a) the 1268 data receiver and the application server b) the data 1269 receiver and the data sender might be different. 1271 6. Protocol Description 1273 6.1 Basic protocol overview 1275 In the NSIS protocol, hosts try to communicate with each other in 1276 spite of firewalls or NAT's by opening pinholes or making NAT 1277 bindings in them. For things to work, we need to signal the proper 1278 boxes, and that means we will have to send the signals on the data 1279 path, and in the proper direction. So, if the Data Sender (DS) wants 1280 to send data to the Data Receiver (DR), it is DS that will have to 1281 signal towards DR. 1283 Problems arise when DR has a private IP address and is not publicly 1284 reachable. In that case, DR will have to make due for it, and get a 1285 public IP address it can use by using specific NSIS signaling. DS 1286 will then signal towards the public address DR got. 1288 Given this fact, we have two modes of operation: 1290 o First, DR making itself available by signaling on the reverse path 1291 (DR towards DS). This way, it reserves publicly reachable 1292 addresses and ports, which it communicates to DR through means out 1293 of the scope of this document, but probably involving a third 1294 party and an application level protocol. 1296 o And second, DS signaling directly to DR, and creating NAT bindings 1297 and installing FW rules. Nothe that the first mode will usually 1298 make reservations only, which will be "activated" by the signaling 1299 from DS towards DR. The first mode is detailed in the Section 5 1301 The protocol is meant to work on a soft-state basis. This means, 1302 that whatever state is installed or reserved on a middle box, will 1303 expire, and thus be uninstalled/forgotten after a certain timeout. 1304 To prevent this the involved boxes will have to specifically request 1305 a session prolongation. An explicit NATFW NSLP state deletion 1306 message is also provided by the protocol. 1308 Middle boxes should report back in case of error, so that appropriate 1309 measures and debugging can be performed. 1311 6.2 Message format and types 1313 At the moment of writing this document, no decision has been reached 1314 on the details of the NTLP, (NSIS Transport Layer Protocol), hence 1315 the current NATFW NSLP protocol specification uses raw IP transport 1316 with an arbitrary protocol number. The NSIS Protocol Data Unit is 1317 constituted of a header, and a series of objects. 1319 The NSIS header contains: 1321 o header_len: length of the nsisp header in bytes 1323 o version: protocol version number. 1325 o obj_count: number of objects that follow after the nsis header. 1327 It is followed by a series of objects. Each object is composed of an 1328 object header and the object data. The object header format is 1329 common to all the object types, and has the following format: 1331 o obj_len: total length of the object 1333 o obj_h_len: length of the object header 1335 o obj_type: type of NATFW NSLP object. Identifies the data that 1336 follows. 1338 The object data is attached next to the object header, and varies 1339 depending on the required action to be taken. For the moment four 1340 object types are defined as follows, if required others could be 1341 defined later on. 1343 Create session (a temporary pinhole or a nat-binding): 1345 o sid: Session ID. Randomly generated by the endhosts. 1347 o src_addr: where the data will come from. If it is DS sending data 1348 to DR, the source address is either DS or the closest NAT in the 1349 route from DS to the middlebox that gets the packet; That is, the 1350 address where each middlebox will see the packet come from. 1352 o dst_addr: whre the data is headed. If it is DS sending data to 1353 DR, the destination address is either DR or the public address DR 1354 reserved itself. 1356 o src_port: the transport port the data will come from 1358 o dst_port: the transport port the data will go to. 1360 o proto: protocol number. 1362 Note: you might want to leave the source address or port set to ANY, 1363 to accept any source address port. This makes the pinhole not so pin 1364 like, but might be necessary at the integration with certain NAT/FW 1365 types. Whether this loose pinhole is authorized or not by the middle 1366 box, is a policy decision based on the middle box configuration. 1368 Prolong session: 1370 o sid: the session we intend to prolong. 1372 Delete session: 1374 o sid: the session we want to delete. 1376 Reserve external addr: 1378 o sid: session for the reserve external address process. 1380 o tgt_addr: address we want our external address to point to. If A 1381 reserves an external address in a NAT, it will want that external 1382 address to point to A. 1384 o tgt_port: port the external addres:port pair should point to. 1386 o src_addr: The address the data will come from. We might want to 1387 set this to 0.0.0.0, to make a loose pinhole reservation, if we 1388 don't the src_addr yet. 1390 o src_port: The port the data will come from. Can also be set to 1391 zero if unknown. 1393 Note that no state, be it a firewall rule or a nat binding, is 1394 installed as a result of this message. The state is only remembered, 1395 and might be later installed by a create message. 1397 Return external addr: 1399 o sid: the session this packet is replyng about. 1401 o ext_addr: the external address that the nat has just created for 1402 the endhost. 1404 o ext_port: the external port. 1406 Path succeeded: 1408 o sid: the session ID for which a path was succesfully installed 1410 Error: 1412 o sid: the session id of the object that generated the error 1414 o error_code: what the error was. 1416 6.3 Message flow 1418 Of the shown message types, 4 of them are sent by the end hosts to 1419 achieve some service (create, reserve, prolong, and delete) and 3 are 1420 sent back as a response (return external address, path succeded and 1421 error). 1423 The usual message flow for the reservation mode of operation, to 1424 achieve an external address, is: 1426 DS Public Internet NAT Private addres DR 1427 | | space | 1428 | | | 1429 | | Reserve | 1430 | |<---------------------------| 1431 | | | 1432 | | Return ext addr / Error | 1433 | |--------------------------->| 1434 | | | 1435 | | | 1437 In the case of the creation mode, when rules are actually installed, 1438 the message flow is as follows: 1440 DS Public Internet NAT Private addres DR 1441 | | space | 1442 | Create | | 1443 |----------------------------->| | 1444 | | | 1445 | Error (if necessary) | | 1446 |<-----------------------------| Create | 1447 | |--------------------------->| 1448 | | | 1449 | | Path Succeeded/Error | 1450 | Path Succeeded/Error |<---------------------------| 1451 |<-----------------------------| | 1452 | | | 1453 | | | 1455 When it comes to prolonging or deleting sessions: 1457 DS Public Internet NAT Private addres DR 1458 | | space | 1459 | Prolong/Delete | | 1460 |----------------------------->| | 1461 | | | 1462 | Error (if necessary) | | 1463 |<-----------------------------| Prolong/Delete | 1464 | |--------------------------->| 1465 | | | 1466 | | Error (if necessary) | 1467 | Error (if necessary) |<---------------------------| 1468 |<-----------------------------| | 1469 | | | 1470 | | | 1472 6.4 Middle box configuration 1474 The way a message is handled in each box will depend on its 1475 configuration. 1477 Currently defined ocal NSIS NAT/FW configuration parameters are: 1479 o nat_capabilities: am I a NAT? 1481 o nat_external_addr: if I'm a nat, what is the address closest to 1482 the public internet? 1484 o edge_nat: true, false or auto. Tells us how much of an edge_nat 1485 we are. See explanation below. 1487 The edge_nat parameter requires some more explanation, though. When 1488 a host reserves an external address, as seen in Section 5, it makes 1489 itself reachable by the other end. This does not always mean a 1490 public internet address. In Section 7.4 we see that a private 1491 address can also be reachable by another box in the same address 1492 space. Still, things work well if we get a public ip address, only 1493 the route is unnecesarily long (see an example in Section 7.4). 1495 For this reason, we can set up the boxes to always or never behave as 1496 an edge nat, or else set it to auto. The auto setting will compare 1497 the destination ip address of the reserve address objects, and see if 1498 they belong to the same address space as the nat external address. 1499 If it is so, the nat behaves as an edge_nat for this connection, 1500 otherwise, it doesn't. 1502 Note that the address spaces are set in RFC3330 [2]. 1504 6.5 Message handling 1506 When a box receives an NSIS message, it might take an action based on 1507 the message type, the nature of the box, its configuration and its 1508 security policies. 1510 As a summary, here's the behaviour of the boxes, depending on message 1511 type and config parameters: 1513 NAT FW NAT+FW DS DR 1514 reserve 5 - 5 + + 1515 ret_ext_addr - - - + 8 1516 create 1 2 3 + 4 1517 prolong 6 6 6 + 4 1518 delete 7 7 7 + 4 1519 path_succeed - - - 8 + 1521 1: install the rule, rewriting either the source or destination 1522 address depending on whether the packet comes from the 1523 external_address or not. Always forward. 1525 2: Install the rule, always forward. 1527 3: 1+2. The order depends on whether it comes from the outside 1528 address (NAT, then FW) or the inside one (FW, then NAT) 1529 4: If it fits one of its requests, send a path_succeeded packet 1530 back. Drop the packet. 1532 5: Make a reservation. If edge_nat is set, send back the 1533 external_addr and don't forward. Otherwise, forward and don't 1534 send anything back. 1536 6: Prolong the session. Always forward. 1538 7: Terminate the session. Always forward. 1540 8: hand it over to superior layers, and drop it. 1542 -: ignore and forward. 1544 +: ignore and drop. 1546 Note that the order is important, when it comes to NAT+FW boxes, 1547 because the filter rules have to be set up according to the packet 1548 they will see. Source NAT is done at the end so it doesn't disturb 1549 routing decisons, this means the filter sees the original packets. 1550 Destination NAT, on the other hand, is done at the beginning, so it 1551 can be routed properly, and so the filter sees the modified packets. 1553 Note also that for each action, the host might demand a certain 1554 degree of authorization, and thus refuse to take the action, sending 1555 an error message back instead. 1557 The details of the message handling in each of the boxes follows. 1559 6.5.1 Detailed behaviour 1561 6.5.1.1 Reserve external address message 1563 o NAT Box: 1565 When a NAT box gets a Reserve external addressm message, it checks 1566 whether it arrived on the public address, or the private one. If 1567 it arrived in the public one, an error message of the type: 1568 "Requested an external address from the outside" is sent back. 1570 If it arrived on the private side, an entry is made in the 1571 internal reservation list with the packet information. If the box 1572 is an edge nat (either by configuring it to true, or just for that 1573 connection if it is set to auto), it drops the message, and 1574 replies with a return external address message containing the 1575 allocated address port pair. If it is not an edge NAT, it 1576 forwards the packet on. 1578 o Firewall Box: 1580 Reserve messages are silently ignored in Firewall boxes. They are 1581 simply forwarded on. 1583 o NAT+FW Box: 1585 When a box that integrates both a NAT and a Firewall gets a 1586 reserve message, it will hand it to its NAT part. Its firewall 1587 part will simple ignore it. 1589 o Data Sender: 1591 The message should never get here. It should be ignored and 1592 dropped. 1594 o Data Receiver: 1596 The message should never get here. It should be ignored and 1597 dropped. 1599 6.5.1.2 Return external address message 1601 o NAT Box, Firewall Box and NAT+Firewall Box: 1603 When one of these boxes gets a Return external address message, it 1604 must simply ignore it and let it traverse. 1606 o Data Sender: 1608 The message should never get here. It should be ignored and 1609 dropped. 1611 o Data Receiver: 1613 A return external address message in the Data receiver, has 1614 reached its destination. It must be dropped, and it's information 1615 handed to superior layers. 1617 6.5.1.3 Create message 1619 o NAT Box: 1621 When a NAT box gets a create message, it first checks if it 1622 arrived on the public address or not. 1624 If it came from the public side, it means an external box will try 1625 to send data. It then looks for a reservation in its reservation 1626 list, that matches the dst_addr and dst_port of the packet. If it 1627 doesn't find it, it returns an error message of the type "No 1628 reservation found". If it finds it, it fills in the reservation 1629 with the data from the packet, and installs the given rule. It 1630 then changes the dst_addr and dst_port fields of the create packet 1631 and forwards it to the tgt_addr of the reservation. 1633 If it came from the private side, it installs the nat rule with 1634 the information in the packet. It then changes the src_addr and 1635 src_port of the create message to its own external address and 1636 port. 1638 o Firwall Box: 1640 When a firewall box gets a create message, it simply installs the 1641 rule specified in the message and forwards the packet. 1643 o NAT+FW Box: 1645 When a box that integrates both a NAT and a Firewall gets a create 1646 message, it first checks whether it arrived on the public address 1647 or not. 1649 If it arrived on the public side, the NAT part of the box takes 1650 care of the packet first, as said in the NAT Box case. 1651 Afterwards, the modified packet is handed to the firewall part, 1652 where it is handled as in the Firewall Box case. 1654 If it arrived on the private side, the message is handed to the 1655 firewall part first, and then to the NAT one. 1657 o Data Sender: 1659 The message should never get here. It should be ignored and 1660 dropped. 1662 o Data Receiver: 1664 If the data receiver gets a create message, it means all the boxes 1665 on the way accepted it, and so the signaling succeded. All it 1666 does is drop the packet, and send back a Path Succeded message to 1667 the ip packet source address. 1669 6.5.1.4 Delete session message 1671 o NAT Box, Firewall Box and NAT+Firewall Box: 1673 When one of these boxes gets a Delete session message, it should 1674 erase the session refered in the message. 1676 o Data Sender: 1678 As in the create session message, this packet should never get to 1679 the DS, so it is to be ignored and dropped. 1681 o Data Receiver: 1683 As in the create session message, this is the final destination of 1684 the message. If it got here, everything is fine. No further 1685 action should be taken on the packet, which means it is dropped at 1686 the endhost. 1688 6.5.1.5 Prolong session message 1690 o NAT Box, Firewall Box and NAT+Firewall Box: 1692 When one of these boxes gets a Prolong session message, the 1693 expiration time of the session should be changed to the time of 1694 reception plus the configured session lifetime. 1696 o Data Sender: 1698 As in the create session message, this packet is sent from the DS 1699 to the DR, and should never arrive at the DS. Again, it should be 1700 ignored and dropped. 1702 o Data Receiver: 1704 The same behaviour as in the case of a Delete session message on 1705 the DR should be applied. 1707 6.5.1.6 Path Succeded message 1709 o NAT Box, Firewall Box and NAT+Firewall Box: 1711 When one of these boxes gets a Path succeded message, it should 1712 simply ignore it and allow it to traverse. 1714 o Data Sender: 1716 The message ends here. It must be dropped, and its contents sent 1717 to upper software layers. 1719 o Data Receiver: 1721 The message should never get here. It should be ignored and 1722 dropped. 1724 7. Solution examples 1726 7.1 Firewall traversal 1728 DS wants to send ata traffic to DR through tight firewalls, as seen 1729 in Figure 18. To do that, it will have to signal using NSIS, on the 1730 data path. 1732 +-----+ +-----+ //----\\ +-----+ +-----+ 1733 DS --| FW1 |-----| FW2 |---| |---| FW3 |-----| FW4 |--- DR 1734 +-----+ +-----+ \\----// +-----+ +-----+ 1736 private public private 1738 Data Flow 1739 ===============================> 1741 Figure 18: Firewall Traversal Scenario 1743 Therefore, DS initiates signaling to DR by sending a create object to 1744 the ip address od DR. Note that DS already knows its source address 1745 and port (say, 1111), and the destination address of DR. The 1746 destination port (let's say 9999) has been send to DS by DR via 1747 application layer messages, possibily, but not necessarily involving 1748 a third party. The message looks like: 1750 o dst_addr = DR 1752 o dst_port = 9999 1754 o src_addr = DS 1756 o src_port = 1111 1758 This message is received by FW1, which installs the state that reads: 1759 "Any packet coming from DS:1111 headed for DR:9999 will be allowed 1760 traversal" 1762 FW2, FW3 and FW4 do exactly the same, and forward the packet to each 1763 other, until it finally reaches DR. At this point, the data path is 1764 open, and DR sends back a Path succeeded message to DS, which can now 1765 start sending traffic. 1767 7.2 NAT with private network on sender side 1768 In the example in Figure 19, DS is in a private network and wants to 1769 send data to DR, out in the public internet. To do so, DS will have 1770 to initiate NSIS signaling towards DR 1772 +------+ +------+ //----\\ 1773 DS --| NAT1 |-----| NAT2 |---| |--- DR 1774 +------+ +------+ \\----// 1776 private public 1778 Figure 19: NAT with private network on sender scenario 1780 Now, this is a deceivingly easy example. Apparently, the normal NAT 1781 functionality will take care of sending the data from DS out into the 1782 public internet, and route back the replies from DR. This is indeed 1783 true, but doesn't give NSIS control on what the source address or 1784 port is, as it is usually asigned dinamycally by the NAT. Moreover, 1785 the NSLP would have no information on this hops, and could not 1786 install proper pinholes, as it would set DS as the source address, 1787 and not that of the last NAT. 1789 DS builds a create packet with the information he has, which is the 1790 same as that in Section 7.1. It looks like this: 1792 o dst_addr = DR 1794 o dst_port = 9999 1796 o src_addr = DS 1798 o src_port = 1111 1800 NAT1 is the first to get the packet; It is not coming from its 1801 configured "nat external address", and so, it knows it will have to 1802 rewrite the information on the source, and not that of the 1803 destination. NAT1 then picks a free port (incidentally 1011) and 1804 installs a nat rule that reads: "Whatever packet comes from DS:111, 1805 heading for DR:9999 will be rewriten so that the source address looks 1806 like NAT1:1011". 1808 It then rewrites the packet it received as follows: 1810 o dst_addr = DR 1812 o dst_port = 9999 1813 o src_addr = NAT1 1815 o src_port = 1011 1817 And forwards the packet. 1819 NAT2 gets it now, and does exactly the same. Port 2022 is chosen, 1820 and the rule: "Whatever packet comes from NAT1:1011, heading for 1821 DR:9999 will be rewriten so that the source address looks like 1822 NAT2:2022" is installed. The packet gets modified as follows: 1824 o dst_addr = DR 1826 o dst_port = 9999 1828 o src_addr = NAT2 1830 o src_port = 2022 1832 And is forwarded. It eventually reaches DR, who sends back a path 1833 succeded message. Data flow from DS:1111 to DR:9999 is now possible. 1835 7.3 NAT with private network on receiver side 1837 In this example, DS wants to send data to DR over the network in 1838 Figure 20: 1840 //----\\ +------+ +------+ 1841 DS ---| |---| NAT1 |-----| NAT2 |--- DR 1842 \\----// +------+ +------+ 1844 public private 1846 Figure 20: NAT with private network on receiver Scenario 1848 The problem, of course, is that DR is not publicly reachable. 1849 Because of that, DR will have to signal on the data path, in the 1850 opposite direction (DR->DS) to get itself a public address it can 1851 use. This method is described in Section 5 1853 To get an external address, DR sends a packet to DS. It could 1854 actually send it to anything in the public internet, as it would 1855 force it to traverse what NATs are on its way. In the case of 1856 multihomed environments, though, more than one NAT to the outside is 1857 possible, so the better we "aim" the more the chances we go out the 1858 right NATs and get more optimal routes. 1860 The said packet is an NSIS reserve_addr object which looks like this: 1862 o tgt_addr = DR 1864 o tgt_port = 9999 1866 o src_addr = 0.0.0.0 1868 o src_port = 0 1870 Notice that this is a really loose pinhole, since any src_addr and 1871 port is allowed. 1873 NAT2 gets the packet and looks for a free port (say, 2022, for 1874 clarity's sake). It then adds an entry to its reservation list. The 1875 entry looks like this: 1877 o src_addr = 0.0.0.0 1879 o src_port = 0 1881 o dst_addr = NAT2 1883 o dst_port = 2022 1885 o tgt_addr = DR 1887 o tgt_port = 9999 1889 This means simply that packets coming from any source, destinated to 1890 the public address we just reserved, shoud be targeted to the 1891 internal box DR, on port 9999 1893 It then rewrites the packet so that it looks like: 1895 o tgt_addr = NAT2 1897 o tgt_port = 2022 1899 o src_addr = 0.0.0.0 1901 o src_port = 0 1903 Because it is not an edge nat, it forwards the modified packet and 1904 does not sent a return_external_addr object to DR. Note that no nat 1905 binding is installed so far in NAT2, although the state is now 1906 reserved. 1908 NAT1 now gets the packet, picks free port 1011 and adds the following 1909 entry to its reservation list: 1911 o src_addr = 0.0.0.0 1913 o src_port = 0 1915 o dst_addr = NAT1 1917 o dst_port = 1011 1919 o tgt_addr = NAT2 1921 o tgt_port = 2022 1923 As it turns out, NAT1 IS an edge_nat, so it doesn't forward the 1924 packet. Instead, it replies to DR sending back a return external 1925 address packet on the same connection, so it finds its way back 1926 through the NATs: 1928 o ext_addr = NAT2 1930 o ext_port = 2022 1932 By using some application layer protocol, and possibly, although not 1933 necesarily, using a third party box, DR sends it's freshly allocated 1934 external address and port to DS. 1936 DS now knows who to signal, so it sends a create message: 1938 o dst_addr = NAT1 1940 o dst_port = 1011 1942 o src_addr = DS 1944 o src_port = 1111 1946 When it reaches NAT1, it does so through NAT1 external address. It 1947 realizes it is being asked to forward the traffic from some outside 1948 box towards the inside. It then looks up its reservation list, 1949 looking for a session that has the external address and port 1950 NAT1:1011 assigned. It finds this: 1952 o src_addr = 0.0.0.0 1953 o src_port = 0 1955 o dst_addr = NAT1 1957 o dst_port = 1011 1959 o tgt_addr = NAT2 1961 o tgt_port = 2022 1963 Using the information in the create object, it then fills in this 1964 structure to: 1966 o src_addr = DS 1968 o src_port = 1111 1970 o dst_addr = NAT1 1972 o dst_port = 1011 1974 o tgt_addr = NAT2 1976 o tgt_port = 2022 1978 This IS a tight pinhole. NAT1 installs the rules now, which say: 1979 "Whatever packet comes from DS:1111 heading for NAT1:1011, should 1980 have its destination address changed to NAT2:2022, and be forwarded". 1981 The packet is also rewritten into this: 1983 o src_addr = DS 1985 o src_port = 1111 1987 o dst_addr = NAT2 1989 o dst_port = 2022 1991 And is forwarded to NAT2. Upon arrival, a similar process issues. 1992 NAT2 finds its reservation entry: 1994 o src_addr = 0.0.0.0 1996 o src_port = 0 1998 o dst_addr = NAT2 2000 o dst_port = 2022 2001 o tgt_addr = DR 2003 o tgt_port = 9999 2005 Fills it in accordingly: 2007 o src_addr = DS 2009 o src_port = 1111 2011 o dst_addr = NAT2 2013 o dst_port = 2022 2015 o tgt_addr = DR 2017 o tgt_port = 9999 2019 Rewrites the packet: 2021 o src_addr = DS 2023 o src_port = 1111 2025 o dst_addr = DR 2027 o dst_port = 2222 2029 And forwards it to DR. Once there, DR acknowledges it by sending 2030 back a path succeded message in reply, back to DS. 2032 The path is now open and data transmission from DS:1111->DR:9999 can 2033 comence. 2035 7.4 Both end hosts are in same private network behind NATs 2037 In this example (see Figure 21), DS, in a private address space, 2038 wants to send data to DR, in another private address space. The 2039 point marked "%" is yet another private address space. Notice that 2040 since NAT1 and NAT3 have addresses in the same address space, NAT3 2041 might want to consider itself an edge nat. We will consider both 2042 situations. 2044 public 2045 +------+ % +------+ //----\\ 2046 DS --| NAT1 |--+--| NAT2 |---| | 2047 +------+ | +------+ \\----// 2048 | 2049 | +------+ 2050 +--| NAT3 |------------ DR 2051 +------+ 2053 private 2055 Figure 21: NAT to public, receiver in same private network Scenario 2057 We will first assume that NAT3 has the edge_nat option set to false. 2058 In this case, the connection is a combination of Section 7.3 and 2059 Section 7.2. 2061 Firstly DR will signal against on the data path, against the data 2062 flow, with a reserve external address object. NAT3 will reserve the 2063 address and forward the packet on to NAT2, who IS an edge nat in all 2064 cases. NAT2 will reply with the external address, and the connection 2065 goes on just as in Section 7.2, except for the fact the topology 2066 becomes: 2068 public 2069 +------+ +------+ 2070 DS --| NAT1 |-----o------o---+ 2071 +------+ | | | 2072 | NAT2 |---+ 2073 | | | 2074 +--o------o---+ 2075 | +------+ 2076 | 2077 | +------+ 2078 +--| NAT3 |------------ DR 2079 +------+ 2081 private 2083 Figure 22: New topology due to the non optimal edge nat parameter 2084 decision 2086 This is not optimal, but the connection does succeed, and data flow 2087 can commence. 2089 Let us now solve the case in which NAT3 has edge_nat set to auto. 2090 Back in Figure 21, NAT3 will decide it IS an edge_nat if the 2091 destination we pick up for the reserve address packet is in the 2092 address space marked as "%", and will NOT consider itself an edge_nat 2093 if we point it anywhere else. This is an optimality issue such as 2094 the one pointed out in Section 7.3. 2096 Well so, if it doesn't consider itself an edge nat, we already saw 2097 what the topological equivalent is, and how it proceeds. If it IS an 2098 edge nat, the topological equivalent would be: 2100 +------+ 2101 DS --| NAT1 |--+ 2102 +------+ | 2103 | 2104 | +------+ 2105 +--| NAT3 |------------ DR 2106 +------+ 2108 private 2110 Figure 23: A good edge nat decision brings an optimal route 2112 And we would proceed in the same way, only on a more optimal route. 2114 7.5 IPv4/v6 NAT with two private networks 2116 TBD 2118 7.6 Full example for NAT/FW with two private networks 2120 The NAT's have the nat_capabilities variable set to true. NAT+FW3 2121 and NAT+FW5 have the edge_nat variable set to true. The rest of 2122 boxses have it set to false. 2124 Let's now suppose that DR wants to get a data stream from DS in 2125 Figure 24. For that, we need some way for B to get messages from A, 2126 be it through some third party application server or some publicly 2127 reachable proxy, perhaps made public through a nat binding. 2129 +-----+ 2130 +--------| FW4 |--------+ 2131 | +-----+ | 2132 +---------+ +---------+ 2133 | NAT+FW3 | | NAT+FW5 | 2134 +---------+ +---------+ 2135 | | 2136 +---------+ +---------+ 2137 | NAT3 | | NAT6 | 2138 +---------+ +---------+ 2139 | | 2140 +---------+ +---------+ 2141 | FW1 | | FW7 | 2142 +---------+ +---------+ 2143 | | 2144 +---------+ +---------+ 2145 | DS | | DR | 2146 +---------+ +---------+ 2148 Data Flow 2149 ==========================> 2151 Figure 24: Example network topology 2153 DR wants a data stream from DS, which means that the direction of the 2154 data is DS->DR. A will have to make itself publicly reachable by 2155 signaling its NATs and firewalls as necessary. This is a step by 2156 step guide to the whole process. 2158 In steps 1 to 4, DR makes itself publicly reachable. From 5 and on, 2159 DS is signaling on the data path towards DR. 2161 1. DR wants to get data from DS, so it sends a reserve_addr object 2162 to a target in the public internet. The closest this target is, the 2163 more the chances that the outcoming route is optimal, but any will 2164 work. The reserve_addr obj looks like this: 2166 o tgt_addr = DR 2168 o tgt_port = 888 2170 o src_addr = 0.0.0.0 2172 o src_port = 0 2174 Notice that this is a really loose pinhole, since any src_addr and 2175 port is allowed. 2177 2. FW7 gets the packet, ignores its contents and forwards it. 2178 Firewalls always ignore reserve_addr objects. 2180 3. NAT6 gets the packet, and looks for a free port (say, 666, for 2181 clarity's sake). It then adds an entry to its reservation list. The 2182 entry looks like this: 2184 o src_addr = 0.0.0.0 2186 o src_port = 0 2188 o dst_addr = NAT6 2190 o dst_port = 666 2192 o tgt_addr = DR 2194 o tgt_port = 888 2196 It then rewrites the packet so that it looks like: 2198 o tgt_addr = NAT6 2200 o tgt_port = 666 2202 o src_addr = 0.0.0.0 2204 o src_port = 0 2206 Because it is not an edge nat (edge_nat=false), it does not sent a 2207 return_external_addr object to DR, but rather forwards the modified 2208 packet. Note that no nat binding is installed so far in NAT6, 2209 although the state is now reserved. 2211 4. NAT+FW5 receives the packet. The firewall part gets the object, 2212 but, being as it is an address reservation only object, it ignores 2213 it. The NAT part gets it next. Because it is a NAT, it binds a free 2214 port, which is thus reserved. An entry to the reservation list is 2215 added: 2217 o src_addr = 0.0.0.0 2219 o src_port = 0 2221 o dst_addr = NAT+FW5 2223 o dst_port = 555 2224 o tgt_addr = NAT6 2226 o tgt_port = 666 2228 Because it is an edge_nat, it sends a return_external_addr packet 2229 with address NAT+FW5 and port 555 back to DR. It does so by simply 2230 sending it back to the source IP addr in the IP header of the packet. 2231 In this case, it is NAT6. The standard capabilities of NAT6 will 2232 send it back to DR, since we are always working on the same 2233 connection. Because it is an edge_nat and this is a 2234 reserve_external_addr packet, it does not forward the packet. 2236 At this stage, the end host DR has learned what its (reserved) 2237 external address is, even if it can not be used. It is now publicly 2238 reachable, and path-coupled nsis signaling in direction DS->DR can 2239 start. 2241 5. Firstly, DR tells DS about it's freshly reserved outside address 2242 through some higher layer protocol, using the third-party box. 2244 6. DS now initiates signaling to DR by sending a create object to 2245 the brand new public address of DR. It looks like: 2247 o dst_addr = NAT+FW5 2249 o dst_port = 555 2251 o src_addr = DS 2253 o src_port = 111 2255 7. The firewall FW1 gets it, and installs the requested pinhole. 2256 (Note this IS a tight pinhole with well defined source and 2257 destination). It then forwards the packet. 2259 8. NAT2 gets the packet. Because it is NOT coming from it's 2260 external address, it realizes it is being asked to forward DS's 2261 future data packets, and so, it will have to rewrite it's source 2262 address. To do so, NAT2 picks a random free port (which turns out to 2263 be 222), and installs a nat rule that says: "Whatever packet comes 2264 from DS:111, heading for NAT+FW5:555 will be rewriten so that the 2265 source address looks like NAT2:222". That is usually known as Source 2266 NAT. The nsis create request is then rewriten to look like: 2268 o dst_addr = NAT+FW5 2270 o dst_port = 555 2271 o src_addr = NAT2 2273 o src_port = 222 2275 Because it is not an edge nat, it simply forwards the modified 2276 packet. 2278 9. NAT+FW3 gets the packet next. Because it is NOT coming from the 2279 extarnal_addr of the NAT+FW, The firewall part gets it first, and 2280 installs the filter rule that says: "Allow traversal of packets going 2281 from NAT2:222 towards NAT+FW5:555". It then hands it to the NAT 2282 part. 2284 The NAT part gets it then. It is not coming from its external addr, 2285 and so, it does as NAT2, binding a port (333) and installing a rule 2286 that says: "Whatever packet comes from NAT2:222, heading for 2287 NAT+FW5:555, will be rewriten so that the source address looks like 2288 NAT+FW3:333". It will then rewrite the create object to: 2290 o dst_addr = NAT+FW5 2292 o dst_port = 555 2294 o src_addr = NAT+FW3 2296 o src_port = 333 2298 Note that the box won't send a packet back to DS informing it of its 2299 external address, because DS will never need that. 2301 10. FW4 gets the create object, and installs the rule "Allow 2302 traversal of packets going from NAT+FW3:333 towards NAT+FW5:555" It 2303 then forwards the object. 2305 11. NAT+FW5 gets the create object. It arrived at its external 2306 address, so it realizes it doesn't have to change the source address 2307 of the future data packets of DS, but rather its destination. It 2308 also means that the NAT part will have to handle it first. It then 2309 tries to find out where it has to re-destinate it to, by looking up 2310 its reservation tables. It finds the previous reservation, by 2311 matching it with ther dst_addr and dst_port of the create object: 2313 o src_addr = 0.0.0.0 2315 o src_port = 0 2317 o dst_addr = NAT+FW5 2318 o dst_port = 555 2320 o tgt_addr = NAT6 2322 o tgt_port = 666 2324 And proceeds to fill it in with the information of the create object 2325 (src_addr and src_port): 2327 o src_addr = NAT+FW3 2329 o src_port = 333 2331 o dst_addr = NAT+FW5 2333 o dst_port = 555 2335 o tgt_addr = NAT6 2337 o tgt_port = 666 2339 It then installs a NAT rule with that information. It reads: 2340 "Whatever packet comes from NAT+FW3:333, heading for NAT+FW5:555 will 2341 be rewritten, so that its destination address looks like NAT6:666". 2342 The reservation is erased and the rule starts working. The NAT 2343 binding becomes thus usable. 2345 The object is modified, so that it now looks like: 2347 o dst_addr = NAT+FW3 2349 o dst_port = 333 2351 o src_addr = NAT6 2353 o src_port = 666 2355 The FW part now gets the object, and installs the rule: "Allow 2356 traversal of whatever packet that comes from NAT+FW3:333 heading for 2357 NAT6:666". The packet is then forwarded. 2359 12. NAT6 gets the packet. As it comes from the external adddress, 2360 it does as NAT+FW5, looking up the reservation list and filling it in 2361 with: 2363 o src_addr = NAT+FW3 2365 o src_port = 333 2366 o dst_addr = NAT6 2368 o dst_port = 666 2370 o tgt_addr = DR 2372 o tgt_port = 888 2374 It then installs the rule: "Whatever packet comes from NAT+FW3:333, 2375 heading for NAT6:666 will be rewritten, so that its destination 2376 address looks like DR:888". The rule reservation is erased, and the 2377 NAT binding becomes active. The object is rewritten as: 2379 o src_addr = NAT+FW3 2381 o src_port = 333 2383 o dst_addr = DR 2385 o dst_port = 888 2387 The object is thus forwarded. 2389 13. FW7 gets the packet now, and installs the rule: "Allow traversal 2390 of whatever packet that comes from NAT+FW3:333 heading for DR:888". 2391 It forwards the packet. 2393 14: DR gets (finally) the packet. It realizes it is a create object 2394 headed for him, to the port which he expected, and so it sees 2395 everything went well. A reply to the packet is send, and the NAT's 2396 on the way, knowing the already established connection, will route it 2397 to DS. The packet is a path_succesful message, which simply means 2398 "Everything's fine, send data whenever you want". 2400 8. NSIS NAT and Firewall transitions issues 2402 NSIS NAT and Firewall transition issues are premature and will be 2403 addressed in a separate draft (see [8]). An update of this section 2404 will be based on consensus. 2406 9. Security Considerations 2408 Security is of major concern particularly in case of firewall 2409 traversal. Generic threats for NSIS signaling have been discussed in 2410 [3] and are applicable here as well. It is necessary to provide 2411 proper signaling message protection and proper authorization. Note 2412 that the NAT is likely to be co-located with a firewall and might 2413 therefore require packet filters to be changed in order to allow the 2414 signaling message to process and to traverse. This section aims to 2415 raise some items for further discussion and illustrates the problems 2416 the authors faced when creating a security solution for the NAT/ 2417 Firewall NSLP. Without doubts there is a dependency on the security 2418 provided by the NTLP. At the time of writing this version of the 2419 document no NTLP draft is available (or accessible for the authors). 2420 Section Section 4 and Section 3.5 motivates some trust relationship 2421 and authorization scenarios. These scenarios deserve a discussion 2422 since some of them (particularly one with a missing 2423 network-to-network trust relationship) is different to what is know 2424 from QoS signaling. To address some of these trust relationships and 2425 authorization issues requires security mechanisms between 2426 non-neighboring nodes at the NSLP layer. For the group of authors it 2427 seems that peer-to-peer and end-to-middle security needs to be 2428 provided. An NSLP security mechanism between neighboring NSLP peers 2429 might be necessary if security mechanisms at the NTLP do not provide 2430 adequate protection mechanisms. This issue is, however, still in 2431 discussion. As a design goal it seems to be favorable to reuse 2432 existing mechanisms to the best extend possible. In most cases it is 2433 necessary to carry the objects for end-to-middle as NSLP payloads 2434 since the precesence of NATs might prevent direct communication. 2435 Three security mechanisms have to be considered in more detail in a 2436 future version of this document: CMS [9] and Identity Representation 2437 for RSVP [10]. The authors believe that CMS more suitable (since it 2438 provides much more functionality). The details deserve further 2439 discussion and implementation experience. 2441 With regard to signal between two end hosts even though the receiver 2442 is behind a NAT this proposal suggests creating state by the data 2443 receiver first. This allows NSIS signaling messages to traverse a 2444 NAT at the receiver side (due to the established state at this NAT 2445 box) and simplifies security handling.To achieve this behavior it is 2446 required to install NSIS NTLP and NSLP state. Furthermore, it is 2447 envisioned to associate the two signaling parts (one part from the 2448 data sender to the NAT and the other part from the NAT to the data 2449 receiver) with the help of the Session Identifier. As such, the 2450 discussion in [10] is relevant for this document. 2452 Another interesting property of this protocol proposal is to prevent 2453 Denial of Service attacks against NAT boxes whereby an adversary 2454 allocates NAT bindings with the help of data packets. Since these 2455 data packets do not provide any type of authentication and are not 2456 authorized any adversary is able to mount such an attack. This 2457 attack has been mentioned at several places in the literature 2458 already and is particularly harmful if no NAPT functionality is used 2459 (i.e. if a new NAT binding consumes one IP address of a pool of IP 2460 addresses). Using the protocol described in this document additional 2461 security can be achieved and more fairness can be provided. 2463 10. Open Issues 2465 At least the following issues require further discussion: 2467 o Message format: The exact message format is still to be 2468 determined, both in regards of bit level details and on 2469 parameters, such as the need for an object header length, since, 2470 until now, that is a constant. 2472 o Error codes: error codes have to be defined still. Among others, 2473 we will need: missing authorization, out of resources, unable to 2474 understand the packet, or maximum resources for that individual 2475 already allocated. 2477 o Middle box default policies: allow for the configuration of the 2478 default policies of the box. For a NAT+Firewall box, for 2479 instance, the firewall default policy might be "accept", and so, 2480 no packet filters would have to be installed on that regard (we 2481 would still need the nat bindings, though). 2483 11. Contributors 2485 A number of individuals have contributed to this draft. Since it was 2486 not possible to list them all in the authors section, it was decided 2487 to split it and move Marcus Brunner and Henning Schulzrinne into the 2488 contributors section. Separating into two groups was done without 2489 treating any one of them better (or worse) than others. 2491 Normative References 2493 [1] Brunner et al., M., "Requirements for Signaling Protocols", 2494 DRAFT draft-ietf-nsis-req-07.txt, March 2003. 2496 [2] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 2498 [3] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 2499 DRAFT draft-ietf-nsis-threats-01.txt, January 2003. 2501 [4] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 2502 Rayhan, "Middlebox communication architecture and framework", 2503 RFC 3303, August 2002. 2505 Informative References 2507 [5] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 2508 (NAT) Terminology and Considerations, RFC 2663", August 1999. 2510 [6] Srisuresh, P. and E. Egevang, "Traditional IP Network Address 2511 Translator (Traditional NAT), RFC 3022", January 2001. 2513 [7] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and 2514 X. Fu, "Security Implications of the Session Identifier", June 2515 2003. 2517 [8] Aoun and others...., C., "NAT/Firewall NSLP migration, routing, 2518 NTLP requirements and off-path Considerations", October 2003. 2520 [9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 2521 August 2002. 2523 [10] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 2524 Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 2525 3182, October 2001. 2527 [11] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 2528 Simple Traversal of User Datagram Protocol (UDP) Through 2529 Network Address Translators (NATs)", RFC 3489, March 2003. 2531 [12] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K. 2532 Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt, 2533 November 2002. 2535 [13] Tschofenig, H., Buechli, M., Van den Bosch, S. and H. 2536 Schulzrinne, "NSIS Authentication, Authorization and Accounting 2537 Issues", draft-tschofenig-nsis-aaa-issues-01 (work in 2538 progress), March 2003. 2540 [14] Amini, L. and H. Schulzrinne, "Observations from router-level 2541 internet traces", DIMACS Workshop on Internet and WWW 2542 Measurement, Mapping and Modelin Jersey) , Februar 2002. 2544 [15] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 2545 Traversal of VPN Gateways", 2546 draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in 2547 progress), April 2003. 2549 [16] Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin, 2550 "Problem Space and Usage Scenarios for PANA", 2551 draft-ietf-pana-usage-scenarios-06 (work in progress), April 2552 2003. 2554 [17] Shore, M., "The TIST (Topology-Insensitive Service Traversal) 2555 Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002. 2557 [18] Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT 2558 Traversal Client for CASP", DRAFT 2559 draft-tschofenig-nsis-casp-midcom-01.txt, March 2003. 2561 [19] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, 2562 "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2563 2694, September 1999. 2565 [20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2566 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2567 Session Initiation Protocol", RFC 3261, June 2002. 2569 [21] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 2570 RFC 3234, February 2002. 2572 [22] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H. and H. 2573 Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and 2574 Framework", DRAFT draft-brunner-nsis-midcom-ps-00.txt, June 2575 2003. 2577 Authors' Addresses 2579 Martin Stiemerling 2580 Network Laboratories, NEC Europe Ltd. 2581 Kurfuersten-Anlage 36 2582 Heidelberg 69115 2583 Germany 2585 Phone: +49 (0) 6221 905 11 13 2586 EMail: stiemerling@ccrle.nec.de 2587 URI: 2589 Hannes Tschoefenig 2590 Siemens AG 2591 Otto-Hahn-Ring 6 2592 Munich 81739 2593 Germany 2595 Phone: 2596 EMail: Hannes.Tschofenig@siemens.com 2597 URI: 2599 Miquel Martin 2600 Network Laboratories, NEC Europe Ltd. 2601 Kurfuersten-Anlage 36 2602 Heidelberg 69115 2603 Germany 2605 Phone: +49 (0) 6221 905 11 16 2606 EMail: lopez@ccrle.nec.de 2607 URI: 2609 Cedric Aoun 2610 Nortel Networks 2612 France 2614 EMail: cedric.aoun@nortelnetworks.com 2616 Appendix A. Interworking of SIP with NSIS NATFW NSLP 2618 This document aims at pinpointing the problems of using SIP in 2619 nowadays networks, focusing on the problems derived of NAT's, 2620 Firewalls and multi-path communications. It is intended to fit in a 2621 scenario description that shows the necessity of NSIS, as well as 2622 depicting it's requirements. However, note that there are a number 2623 of other solutions available. For example the IETF Midcom working 2624 group is working on [4]. 2626 A.1 The Session Initiation Protocol 2628 [20] describes the Session Initiation Protocol, an application-layer 2629 control protocol that can establish, modify, and terminate multimedia 2630 sessions. This often involves several flows for video and voice, 2631 which are transported over new connections. These use of dynamically 2632 allocated ports which results in protocol complexity which can not be 2633 handled by nowadays NAT's and Firewalls. 2635 Session initiation when one or both of the users is behind a NAT is 2636 also not possible, given the impossibility to address a private IP 2637 over the internet. Moreover, network deployments often allow for 2638 different paths per connection and direction, making the setup of the 2639 middle boxes even more complicated. 2641 The following figure depicts a typical SIP connection: 2643 Ernie(192.0.2.1) Bert(192.0.2.2) 2644 | | 2645 | 1# SIP INVITE | 2646 +--------------------------------------->| 2647 | 2648 | 2# SIP Ringing | 2649 |<---------------------------------------+ 2650 | | 2651 | 3# SIP OK | <-- Call accepted 2652 |<---------------------------------------+ 2653 | | 2654 | 4# SIP ACK | 2655 +--------------------------------------->| 2656 | | 2657 | 5# DATA | 2658 |=======================================>| 2659 |<=======================================| 2660 | | 2662 1# SIP Invite (192.0.2.1:? -> 192.0.2.2:SIP): I Listen on 2663 192.0.2.1:1000 Ernie invites Bert to the conference, and informs 2664 it's awaiting media data on port 1000. 2666 2# SIP Ringing (192.0.2.2:SIP -> 192.0.2.1:?): Ringing Bert's 2667 phone The ringing simply inplies that there's something sip aware 2668 on Berts side, and that it's ringing his phone 2670 3# SIP OK (192.0.2.2:SIP -> 192.0.2.1:?): Call accepted, I listen 2671 on 192.0.2.2:2000 This OK means that the Bert took the phone off 2672 hook, and thus accepted the call. It also informs Ernie that Bert 2673 is awaiting his media data at port 2000 2675 4# SIP ACK (192.0.2.1:? -> 192.0.2.2:SIP): All is fine, start 2676 transmitting. ACK means the ports are accepted and the call can 2677 start in the slected data ports on both sides. 2679 5# DATA (192.0.2.1:? -> 192.0.2.2:2000 and 192.0.2.2:? -> 2680 192.0.2.1:1000): Voice,image, video.. This is the actual data 2681 being transmited. 2683 In the above example, SIP is used successfully to establish a 2684 communication, which includes negotiating the data ports for the 2685 actual transmission. Unfortunatelly, this scheme will not work for 2686 more complex setups. 2688 Let's now consider one firewall in the data path, be it on Ernie's or 2689 Bert's network, or elsewhere in the middle. We assume that the 2690 firewall is allowing traffic directed to the SIP port. As to the 2691 rest of the ports, a typical setup involves outgoing connections 2692 being allowed, and incoming connections being dropped, except for 2693 those already established. That is, we allow packets to go out and 2694 their replies to come in, but disable all other traffic. 2696 In this case, the connection is as follows, for the case of a 2697 firewall on Ernie's network: 2699 Ernie(192.0.2.1) FW Bert(192.0.2.2) 2700 | | | 2701 | 1# SIP INVITE | | 2702 +--------------------------------------->| 2703 | | | 2704 | | 2# SIP Ringing | 2705 |<---------------------------------------+ 2706 | | | 2707 | | 3# SIP OK | <-- Call accepted 2708 |<---------------------------------------+ 2709 | | | 2710 | 4# SIP ACK | | 2711 +--------------------------------------->| 2712 | | | 2713 | 5# DATA | | 2714 |=======================================>| 2715 | |<=======================| 2716 | | | 2718 Notice how the SIP messages #1 and #4 traverse the firewall, because 2719 they are outbound, and how 2# and 3# traverse it too, because they 2720 are replies to the connection established at 1#. 2722 Notice now how 5# can go outwards, but Bert can not go through the 2723 firewall to reach Ernie's port 1000. The reason is the connection is 2724 a new one, and the firewall won't allow it through. 2726 Bert will now get media from Ernie, but Ernie is never going to get 2727 anything from Bert. The call is thus considered unsuccessful. The 2728 reason is that the application level port negotiation is never 2729 acknowledge by the network-transport layer firewall, which doesn't 2730 know what to expect. We would still face the same problem if the 2731 connection used a SIP Proxy, for it would only translate names into 2732 IP addresses. 2734 Let us now assume that we indeed have an application layer firewall, 2735 be it by design, or because we load some sort of SIP module to it. 2736 The previous case would now work, since the firewall can now 2737 understand the packets going through it and open the necessary ports. 2738 Still, we cannot assume that SIP signalization packets and the actual 2739 data follow the same path. The following figure shows a likely 2740 setup. FW+ stands for one or more firewalls: 2742 SIP Signalization Path +-----+ 2743 /---------------->-----------| FW+ |-------\ 2744 | +-----+ | 2745 +------+ +------+ +-----+ 2746 |Ernie |----|Router| |Bert | 2747 +------+ +------+ +-----+ 2748 | Data Path +-----+ | 2749 \---------------->-----------| FW+ |-------/ 2750 +-----+ 2752 The SIP packets with the information about the listening ports now 2753 travels on the SIP Signalization path, and so the firewalls on that 2754 path can read them. The Data, though, is traveling through the Data 2755 path, and the firewalls in that path never get to see the Invite and 2756 Ok packets. They are thus unable to open the ports. 2758 Two issues are arisen here: first, we need on-path signalization 2759 unless we already know the path our packets will take; a highly 2760 unlikely situation in today's internet. Second, if we patch the 2761 firewalls to understand SIP, we will provide any caller with a 2762 hole-puncher for the firewall, since SIP is not provisioned with 2763 proper authentication mechanism. 2765 It is now clear that tight firewalls prevent SIP from successfully 2766 working. There is still another obstacle: NATs. 2768 NATs provide for a link between two different address spaces, 2769 typically connecting a private range network to a public range one. 2770 As a consequence, connections going from the inside (usually the 2771 private range) are translated using the NAT's public interface 2772 address, and the replies are routed back. The public side of the 2773 network can only see the NATs public interface, and know nothing of 2774 the private network inside. This means computers outside the NAT 2775 won't be able to address computers inside the NAT. 2777 Let us analyze the SIP example when Ernie is behind a NAT. The 2778 following figure depicts a typical session: 2780 Ernie(10.0.0.2) (10.0.0.1) NAT (192.0.2.1) Bert(192.0.2.2) 2781 | | | 2782 | 1# SIP INVITE | | 2783 +--------------------------\ | 2784 | |----------------->| 2785 | | | 2786 | | 2# SIP Ringing | 2787 | /------------------+ 2788 |<-------------------------| | 2789 | | | 2790 | | 3# SIP OK | <-- Call accepted 2791 | /------------------+ 2792 |<-------------------------| | 2793 | | | 2794 | 4# SIP ACK | | 2795 +--------------------------\ | 2796 | |----------------->| 2797 | | | 2798 | 5# DATA | | 2799 |==========================\ | 2800 | |=================>| 2801 | | ?<=============| 2802 | | | 2804 The communication is analogous to the one in the previous examples, 2805 except for the fact the NAT is rewriting the source address of the 2806 packets as they traverse it. 2808 For instance, packet 1# is going from 10.0.0.2:? towards 2809 192.0.2.2:SIP. The NAT box intercepts the message and puts 2810 192.0.2.1:? as the source address and port, with ? being a 2811 dynamically picked port, which might be different from the original 2812 one 1# used. 2814 On the way back, Bert is replyinc to the source of the IP packet, 2815 that is, 192.0.2.1, and so, when 2# reaches 192.0.2.1, the NAT know 2816 it is a reply from 1#, because it established a NAT binding, and this 2817 replaces the destination address, 192.0.2.1:? with 10.0.0.2:? and 2818 forwards the packet inside the NAT. 2820 As a result, Ernie never knows there is a NAT in his communication 2821 path, since he sends and receives packets from 192.0.2.2 normally. 2822 This means that the INVITE packet will tell Bert to send data back to 2823 10.0.0.2, a private IP. Once the signalization is finished, and the 2824 actual DATA transmission starts, Bert tries to connect to 10.0.0.2, a 2825 private IP address, from the internet; The routers don't know how to 2826 route this, and the packet is eventually dropped. 2828 One possible solution would be for Ernie to know the NAT exists, and 2829 already indicate that it listens on 192.0.2.1, and not 10.0.0.2. 2830 That, still would not work, since the NAT binding is not performed at 2831 the NAT box. 2833 A.2 Conclusions 2835 The above examples display the inability to use standard SIP through 2836 tight firewalls or NATs, and points at the necessity of a secure 2837 on-path protocol to negotiate firewall pinholes and NAT bindings. 2839 Appendix B. Ad-Hoc networks 2841 Some forms of ad-hoc networks exist where trust in the network is not 2842 justified. Figure Figure 29 mainly illustrates the problems of 2843 malicious NSIS entities graphically: 2845 +------------------------------------------+ +--------// 2846 | Adhoc | | ISP 2847 | Network | | 2848 | regular data | | 2849 | traffic by +---------+ | | 2850 | node A |Malicious| | +-+--------+ 2851 | +-------------->+ Node +-----+///-->+ Firewall +-// 2852 | ^ | 3 |===========>| 1 | 2853 | | +---------+ injected +-+--------+ 2854 | | data traffic | 2855 | | | | 2856 | | | | 2857 | +---+-----+ +---------+ | | 2858 | + Node | | Node | | | 2859 | | 1 | | 2 | | | 2860 | +---------+ +---------+ | | 2861 | ^ | +--------// 2862 | | | 2863 +----------+-------------------------------+ 2864 | 2865 +--+---+ 2866 | Node | 2867 | A | 2868 +------+ 2870 Figure 29: Limits of packet filter security 2872 An ad-hoc network consists of a number of nodes between the end host 2873 (Node A) and the ISP to which Node A wants to get access. Although 2874 Node A uses an authentication and key exchange protocol to create a 2875 policy rule at the firewall 1 it is still possible for an untrusted 2876 node (in this case Node 3) to inject data traffic which will pass 2877 Firewall 1 since the data traffic is not authenticated. To prevent 2878 this type of threat two approaches are possible. First, a 2879 restrictive packet filter limits the capabilities of an adversary. 2880 Finally, there is always the option of using data traffic protection. 2882 Appendix C. Interworking of Security Mechanisms and NSIS NATFW NSLP 2884 TBD 2886 Appendix D. Solution approaches in case of missing authorization 2888 D.1 Solution Approach: Local authorization from both end points 2890 The first approach makes use of local authorization from both end 2891 points. If Host A sends a signaling message toward the destination 2892 to Middlebox 1 the message will perform the desired action in Network 2893 A. Middlebox 1 establishes some state information and forwards the 2894 signaling message towards Host B. Signaling message protection 2895 between the two access networks might be difficult. A missing trust 2896 relationship does not necessarily mean that no security association 2897 establishment is possible. The lacking trust disallows Middlebox 1 2898 (or indirectly Host A where the signaling message was initiated) to 2899 create packet filters at Middlebox 2. We assume that the NSIS 2900 signaling message is allowed to pass the firewall then it finally 2901 reaches Host B. Due to the missing authorization no packet filter 2902 specific state is created. The filters will be installed later after 2903 receiving an authorization from Host B. When Host B returns a 2904 confirmation or acknowledgement then Middlebox 2 treats it as an 2905 authorization and finally triggers filter creation. The message is 2906 then forwarded to Middlebox 1, where filters are either already 2907 installed or require an additional confirmation. Finally the 2908 signaling message is forwarded to Host A, which can be assured that 2909 subsequent data traffic can be transmitted end-to-end from Host A to 2910 Host B. The same procedure has to be applied again to signal 2911 information for the other direction (Host B to Host A). 2913 The following behavior has to be assumed in order for this approach 2914 to be applicable: 2916 1. Signaling messages must be allowed to pass firewalls along the 2917 path. 2919 2. NSIS signaling must operate in the described manner which could 2920 be described as: Install where you have authorization - delay and 2921 forward where you have no authorization. 2923 This approach suffers from the following drawbacks: 2925 1. Firewalls which block NSIS signaling from external networks or 2926 nodes prevent a successful operation. 2928 2. A full roundtrip is required to signal packet filter information. 2929 The NSIS signaling message must therefore provide the capability 2930 to route signaling message in both direction which might either 2931 require state installation at nodes along the path (route 2932 pinning) or a stateless version via record-route. Some risk of 2933 DoS protection might exist. 2935 D.2 Solution Approach: Access Network-Only Signaling 2937 The next approach is based on signaling packet filter information by 2938 both hosts into the local access network only. An NSIS allows 2939 specifying such a behavior by indicating the signaling endpoint with 2940 the help of scoping (for example with domain name or a "local network 2941 only" flag). Scoping means that the signaling message although 2942 addressed to a particular destination IP address terminates somewhere 2943 along the path. If packet filters for both directions have to be 2944 installed then the signaling messages have to make packet filter 2945 installations up- and downstream along the data path. Similar to 2946 proposals in the area of QoS signaling some problems are likely to 2947 occur. One such problem is that downstream signaling in general 2948 causes problems because of asymmetric routes. In particular it is 2949 difficult to determine the firewall where the downstream data traffic 2950 will enter a network. The problem of triggering downstream 2951 reservations is for example described in [12] . Another problem for 2952 example is the placement of a firewall or NAT along the path other 2953 than in the access network. This would prevent a successful data 2954 exchange. 2956 The following behavior has to be assumed in order for this approach 2957 to be applicable: 2959 1. It must be possible to trigger a signaling message exchange for a 2960 downstream signaling message exchange at the firewall where the 2961 data traffic enters the network. 2963 2. No other firewalls or NATs are present along the path other than 2964 in the access network. 2966 This approach suffers from the following drawbacks: 2968 1. To signal policy rules only within the access network (by both 2969 end-points) has a number of disadvantage and challenges (see for 2970 example [12] ). The complex message processing caused by this 2971 approach strongly argues against it although it might sound 2972 simple (and even might be simple in restricted environments). 2974 2. Complex topologies might lead to ineffective policy rules (i.e. 2975 data traffic hits firewalls hits wrong firewalls). 2977 D.3 Solution Approach: Authorization Tokens 2979 The last approach is based on some exchanged authorization tokens 2980 which are created by an authorized entity (such as the PDP) or by a 2981 trusted third party. Both end hosts need to exchange these tokens 2982 with protocols such as SIP or HTTP since these protocols are likely 2983 to be allowed to bypass the firewall. The basic idea of this 2984 approach is to provide an end host, which requests access to the 2985 network, with credentials (referred as authorization tokens). These 2986 tokens have to possess some properties, namely: 2988 1. They have to be restrictive by including lifetimes, source and 2989 destination identifiers, usage indication and more. 2991 2. They have to provide basic replay protection to prevent 2992 unauthorized reuse. 2994 3. The have be cryptographically protected to prevent manipulations. 2996 4. There has to be a mechanism to dynamically create them for a 2997 specific reason and to distribute them to the end points. 2999 5. It has to be possible to exchange tokens via a trusted third part 3000 in cases where no direct communication between the end hosts is 3001 possible (due to NAT). 3003 6. The token can be created locally at the network or by a trusted 3004 third party. 3006 An example of a possible signaling communication could have the 3007 following structure: After exchanging the tokens between the two end 3008 hosts. Host A would include the received authorization token to the 3009 signaling message for Network B. When the signaling message arrives 3010 at Middlebox 2 then the token is verified by the token-creating 3011 entity. In order to prevent parties from reusing the token 3012 timestamps (e.g. token creation, token lifetime, etc.) have to be 3013 included. Adding IP address information about Host A would create 3014 difficulties in relationship with NATs. Information about Host B 3015 might be possible to include in order to limit attacks where a token 3016 is lost and reused by a different host for a different purpose. The 3017 goal is to restrict the usage of the token for a specific session. 3018 The content of the token only needs to be verified by the originator 3019 of the token since it only has to be verified locally. Since 3020 authorization needs to be linked to the authorized actions, which 3021 have to be performed on the packets matching the packet filter, the 3022 token may include the associated action or a reference to it. The 3023 following behavior has to be assumed in order for this approach to be 3024 applicable: 3026 1. The exchange of authorization tokens between end-systems must be 3027 possible. These protocols must be allowed to pass the firewalls. 3029 2. An end-system must be able to request such an authorization token 3030 at some entity in the local network or at a trusted third party. 3032 This approach suffers from the following drawback: 3034 1. Possibly an additional protocol is required for an end host to 3035 request an authorization token from an entity in the local 3036 network. 3038 Appendix E. Acknowledgements 3040 We would like to acknowledge Vishal Sankhla and Joao Girao for their 3041 input to this draft. 3043 Intellectual Property Statement 3045 The IETF takes no position regarding the validity or scope of any 3046 intellectual property or other rights that might be claimed to 3047 pertain to the implementation or use of the technology described in 3048 this document or the extent to which any license under such rights 3049 might or might not be available; neither does it represent that it 3050 has made any effort to identify any such rights. Information on the 3051 IETF's procedures with respect to rights in standards-track and 3052 standards-related documentation can be found in BCP-11. Copies of 3053 claims of rights made available for publication and any assurances of 3054 licenses to be made available, or the result of an attempt made to 3055 obtain a general license or permission for the use of such 3056 proprietary rights by implementors or users of this specification can 3057 be obtained from the IETF Secretariat. 3059 The IETF invites any interested party to bring to its attention any 3060 copyrights, patents or patent applications, or other proprietary 3061 rights which may cover technology that may be required to practice 3062 this standard. Please address the information to the IETF Executive 3063 Director. 3065 Full Copyright Statement 3067 Copyright (C) The Internet Society (2003). All Rights Reserved. 3069 This document and translations of it may be copied and furnished to 3070 others, and derivative works that comment on or otherwise explain it 3071 or assist in its implementation may be prepared, copied, published 3072 and distributed, in whole or in part, without restriction of any 3073 kind, provided that the above copyright notice and this paragraph are 3074 included on all such copies and derivative works. However, this 3075 document itself may not be modified in any way, such as by removing 3076 the copyright notice or references to the Internet Society or other 3077 Internet organizations, except as needed for the purpose of 3078 developing Internet standards in which case the procedures for 3079 copyrights defined in the Internet Standards process must be 3080 followed, or as required to translate it into languages other than 3081 English. 3083 The limited permissions granted above are perpetual and will not be 3084 revoked by the Internet Society or its successors or assignees. 3086 This document and the information contained herein is provided on an 3087 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3088 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3089 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3090 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3091 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3093 Acknowledgement 3095 Funding for the RFC Editor function is currently provided by the 3096 Internet Society.