idnits 2.17.1 draft-brunner-nsis-midcom-ps-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 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 760: '... 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 398 has weird spacing: '...e might be th...' -- 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 (June 17, 2003) is 7590 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 754 == 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') == 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. '2') ** Obsolete normative reference: RFC 3489 (ref. '3') (Obsoleted by RFC 5389) ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. '4') == 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: 7 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group M. Brunner 3 Internet-Draft M. Stiemerling 4 Expires: December 16, 2003 M. Martin 5 NEC 6 H. Tschofenig 7 Siemens 8 H. Schulzrinne 9 Columbia U. 10 June 17, 2003 12 NSIS NAT/FW NSLP: Problem Statement and Framework 13 draft-brunner-nsis-midcom-ps-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 December 16, 2003. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 This memo presents the problems for using the Next Steps in Signaling 45 base protocol for firewall/NAT traversal commonly refered to 46 middlebox traversal. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Terminology and Abbreviations . . . . . . . . . . . . . . . 5 52 3. What problem should be solved? . . . . . . . . . . . . . . . 6 53 4. Basic NSIS Usage for NAT/FW traversal . . . . . . . . . . . 8 54 5. Scenarios for Protocol Functionality . . . . . . . . . . . . 9 55 5.1 Firewall traversal . . . . . . . . . . . . . . . . . . . . . 9 56 5.2 NAT with two private networks . . . . . . . . . . . . . . . 9 57 5.3 NAT with private network on sender side . . . . . . . . . . 10 58 5.4 NAT with private network on receiver side . . . . . . . . . 11 59 5.5 Both end hosts are in same private network behind NATs . . . 12 60 5.6 IPv4/v6 NAT with two private networks . . . . . . . . . . . 13 61 6. Trust Relationship and Authorization . . . . . . . . . . . . 14 62 6.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . . . . 14 63 6.2 Intra-Domain Trust Relationship . . . . . . . . . . . . . . 15 64 6.3 End-to-Middle Trust Relationship . . . . . . . . . . . . . . 16 65 7. Problems and Challenges . . . . . . . . . . . . . . . . . . 18 66 7.1 Missing Network-to-Network Trust Relationship . . . . . . . 18 67 7.2 End-to-end significance . . . . . . . . . . . . . . . . . . 19 68 7.3 Relationship with routing . . . . . . . . . . . . . . . . . 19 69 7.4 Dynamic state installation and maintenance . . . . . . . . . 20 70 7.5 Affected Parts of the Network . . . . . . . . . . . . . . . 20 71 7.6 Traversing NSIS unaware domains . . . . . . . . . . . . . . 20 72 7.7 Authentication and Authorization . . . . . . . . . . . . . . 21 73 7.8 Directional Property . . . . . . . . . . . . . . . . . . . . 21 74 7.9 Routing Asymmetry . . . . . . . . . . . . . . . . . . . . . 22 75 7.10 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 22 76 7.11 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . . 22 77 7.12 Route changes . . . . . . . . . . . . . . . . . . . . . . . 23 78 7.13 Combining Middlebox and QoS signaling . . . . . . . . . . . 23 79 7.14 Difference between sender- and receiver-initiated 80 signaling . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 7.15 Inability to know the scenario . . . . . . . . . . . . . . . 23 82 8. Security Considerations . . . . . . . . . . . . . . . . . . 25 83 Normative References . . . . . . . . . . . . . . . . . . . . 26 84 Informative References . . . . . . . . . . . . . . . . . . . 27 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 86 A. Interworking of SIP with NSIS NATFW NSLP . . . . . . . . . . 30 87 A.1 The Session Initiation Protocol . . . . . . . . . . . . . . 30 88 A.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 35 89 B. Ad-Hoc networks . . . . . . . . . . . . . . . . . . . . . . 36 90 C. Interworking of Security Mechanisms and NSIS NATFW NSLP . . 37 91 D. Solution approaches in case of missing authorization . . . . 38 92 D.1 Solution Approach: Local authorization from both end 93 points . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 94 D.2 Solution Approach: Access Network-Only Signaling . . . . . . 39 95 D.3 Solution Approach: Authorization Tokens . . . . . . . . . . 39 96 Intellectual Property and Copyright Statements . . . . . . . 42 98 1. Introduction 100 Even though the NSIS WG (Next Steps in Signaling) has as a primary 101 application the signaling for QoS in mind, other types of 102 applications should be possible. 104 In this draft, we look into the scenario, framework, problems, and 105 issues of using a signaling protocol for middlebox traversal, where a 106 middlebox in most cases is a Network Address Translator (NAT) or 107 firewall. 109 One of the requirements in NSIS [1] is that the NTLP signaling 110 protocol must be independent of the service requested. The thinking 111 definitely goes into the direction to request end-to-end or edge-to- 112 edge QoS from IP networks. However, the service might be "open me" 113 the data path through all the firewalls through the network to host 114 X". Also this type of service is running end-to-end. 116 See also [10] and [11] for proposals to use RSVP or CASP for NAT and 117 Firewall traversal. 119 2. Terminology and Abbreviations 121 Sender-/Receiver Initiated Signaling 123 Sender-initiated: NAT bindings and firewall rules are created 124 immediately when the "path" message hits the nsis nodes. With "path" 125 message we refer to the signaling message traveling from the data 126 sender towards the data receiver. 128 Receiver-initiated: NAT bindings and firewall rules are created when 129 the "resv" message returns from the other end. With "resv" message 130 we refer to a signaling message on the reverse path, this means from 131 the receiver to the sender (i.e. backwards routed). 133 Note that these definitions have nothing to do with number of 134 roundtrips, who performs authorization etc. 136 Firewalls vs. Security Gateway: As discussed in Section 3 different 137 types of firewalls exist. This document focuses on firewalls, which 138 perform packet filtering, and possibly application level filtering 139 and does not address IPsec based security gateways. 141 Middlebox: 143 From [13]: "A middlebox is defined as any intermediate device 144 performing functions other than the normal, standard functions of an 145 IP router on the datagram path between a source host and a 146 destination host." 148 The term middlebox in context of this document and in NSIS refers to 149 firewalls and NATs only. Other types of middlebox are currently 150 outside the scope. 152 The following abbreviations are used in various figures throughout 153 the document: 155 o MB - Middlebox 157 o FW - Firewall 159 o S - Data Sender 161 o R - Data Receiver 163 3. What problem should be solved? 165 The term firewall and middlebox in general raises different 166 expectations about the functionality provided by such a device. 167 Different groups have worked on the problem of securing access to a 168 network which different procedures with the help of different 169 protocols. From an abstract point of view two different mechanisms 170 for restricting access to a network can be differentiated: 172 o Packet Filters 174 o Cryptographically protected data traffic 176 Within this document we assume that packet filters are installed at 177 devices along the path. These packet filters typically consist of a 178 5 tuple (src/dst ip address, transport protocol, src/dst port). Some 179 devices entitled as firewalls only accept traffic after cryptographic 180 verification (i.e. IPsec protected data traffic). Particularly for 181 network access scenarios either link layer or network layer data 182 protection is common. Hence we do not address these types of devices 183 (referred as security gateways) since per-flow signaling is rather 184 uncommon in this environment. For a discussion of network access 185 authentication and associated scenarios the reader is referred to the 186 PANA working group (see. [9] ). 188 In mobility scenarios an often experienced problem is the traversal 189 of a security gateway at the edge of the corporate network. Network 190 administrators often rely on the policy that only authenticated data 191 traffic is allowed to enter the network. A problem statement for the 192 traversal of these security gateways in the context of Mobile IP can 193 be found at [8] ). 195 The goal of NSIS FW/NAT signaling therefore focuses on packet filter 196 installation, due to the nature of the path-coupled discovery 197 procedure and signaling message delivery. Discovering security 198 gateways, which was also mentioned as an application for NSIS 199 signaling, for the purpose of executing an IKE to create an IPsec SA, 200 is already solved without requiring NSIS. 202 Installing packet filters provides some security but has some 203 weaknesses, which heavily depend on the type of packet filter 204 installed. A packet filter cannot prevent an adversary to inject 205 traffic (due to the IP spoofing capabilities). This type of attack 206 might not be particular helpful if the packet filter is a standard 5 207 tuple which is very restrictive. If packet filter installation, 208 however, allows specifying a rule, which restricts only the source IP 209 address, then IP spoofing allows transmitting traffic to an arbitrary 210 address. NSIS aims to provide path-coupled signaling and therefore 211 an adversary is somewhat restricted in the location from which 212 attacks can be performed. Some trust is therefore assumed from nodes 213 and networks along the path. 215 4. Basic NSIS Usage for NAT/FW traversal 217 The basic high-level picture for using NSIS for NAT and firewall 218 traversals is that at end host there are applications running, which 219 need to communicate. Potentially, there are some application level 220 intermediate servers. For example a SIP proxy would be such an 221 application server. But also Gaming servers etc could be though of. 222 Naturally, none, one, or more of these application server instances 223 are possible. 225 End hosts use the NSIS NATFW NSLP for opening firewall pinholes and 226 for creating NAT bindings. Therefore it is necessary that each 227 firewall and each NAT involved in the signaling communication needs 228 to run an NSIS daemon. There might be several NATs and FWs in 229 various combinations possible on a path between two hosts. The 230 reader is referred to Section 5 where different scenarios are 231 presented. 233 Application Application Server (0, 1, or more) Application 235 +----+ +----+ +----+ 236 | +------------------------+ +------------------------+ | 237 +-+--+ +----+ +-+--+ 238 | | 239 | NSIS Agents | 240 +-+--+ +----+ +-----+ +-+--+ 241 | +--------+ +----------------------------+ +-----+ | 242 +-+--+ +-+--+ +--+--+ +-+--+ 243 | | ------ | | 244 | | //// \\\\\ | | 245 +-+--+ +-+--+ |/ | +-+--+ +-+--+ 246 | | | | | Internet | | | | | 247 | +--------+ +-----+ +----+ +-----+ | 248 +----+ +----+ |\ | +----+ +----+ 249 \\\\ ///// 250 sender NAT/FW (1+) ------ NATFW (1+) receiver 252 Figure 1: Generic View on NSIS in a NAT / Firewall case 254 5. Scenarios for Protocol Functionality 256 This section introduces several scenarios for middleboxes in the 257 Internet. These middleboxes are firewalls or different flavours of 258 NATs, like NAPT. Combination of both in the same device are possible 259 as well. 261 Each section introduces a different scenario for a different set of 262 middleboxes and their ordering within the topology. 264 5.1 Firewall traversal 266 The following scenario shows two end hosts behind a firewall but 267 connected via the public Internet. The application can somehow 268 trigger firewall traversal (e.g. via an API call) at the NSIS agent 269 at the local host. The NSIS agent then signals this request to the 270 next NSIS aware node and therefore to the receiver. Each firewall in 271 the middle must provide traversal service in order to permit the NSIS 272 message to reach the other end host. 274 The difference between this scenario and the following is that only 275 firewalls are on the path, but no NATs. This has specific 276 implication concerning the path-coupled signaling. 278 +----+ +----+ //----\\ +----+ +----+ 279 S --| FW |-----| FW |---| |---| FW |-----| FW |--- R 280 +----+ +----+ \\----// +----+ +----+ 282 private public private 284 FW: Firewall 285 S: Data Sender 286 R: Data Receiver 288 Figure 2: Firewall Traversal Scenario 290 5.2 NAT with two private networks 292 This scenario deals with NATs on both ends of the network. 293 Therefore, each application instance is behind a NAT and is connected 294 to the public Internet (see Figure 3 ). 296 The case where more than one MB on each side ("only" two are shown in 297 the figure) is present must be taken into account. This aspect 298 introduces more topology problems. 300 +----+ +----+ //----\\ +----+ +----+ 301 S --| MB |-----| MB |---| |---| MB |-----| MB |--- R 302 +----+ +----+ \\----// +----+ +----+ 304 private public private 306 MB: Middlebox 307 S: Data Sender 308 R: Data Receiver 310 Figure 3: NAT with two private networks Scenario 312 Data traffic from the sender to the receiver has to traverse all four 313 middleboxes on the path and all four middleboxes must be configured 314 properly to allow subsequent data packets to flow. The sender has to 315 know the IP address of the receiver in advance, i.e. before any NSIS 316 message can be sent. Or more general the NSIS Initiator must know 317 the IP addresses of the NSIS Responder, otherwise he cannot send a 318 single NSIS signaling message towards the responder. Note that this 319 IP address is not the private IP address of the responder. Instead a 320 NAT binding (including an public IP address) has to be obtained from 321 the NAT which subsequently allows packets hitting the NAT to be 322 forwarded to the receiver within the private address realm. This in 323 general requires further support from an application layer protocol 324 for the purpose of discovering and exchanging information. The 325 receiver might have a number of ways to learn its public IP address 326 and port number and might need to signal this information to the 327 sender using the application level signaling protocol. 329 5.3 NAT with private network on sender side 331 This scenario shows an application instance at the sending node which 332 is behind one ore more FW/NATs. The receiver is located in the 333 public internet. 335 +----+ +----+ //----\\ 336 S --| MB |-----| MB |---| |--- R 337 +----+ +----+ \\----// 339 private public 341 MB: Middlebox 342 S: Data Sender 343 R: Data Receiver 345 Figure 4: NAT with private network on sender scenario 347 The traffic from the sender to the receiver has to traverse only 348 middleboxes on the sender's side. The receiver has a public IP 349 address and therefore the procedure is simple. The sender sends its 350 signaling message directly to the receiver whereby it is intercepted 351 by the middleboxes along the path. 353 Note that the data sender does not necessarily knows whether the 354 receiver is behind a NAT or not, and so, it is the receiving side 355 that has to detect it. As described later NSIS can also provide help 356 for this procedure. 358 5.4 NAT with private network on receiver side 360 The application instance receiving data is behind one or more NATs. 362 //----\\ +----+ +----+ 363 S ---| |---| MB |-----| MB |--- R 364 \\----// +----+ +----+ 366 public private 368 MB: Middlebox 369 S: Data Sender 370 R: Data Receiver 372 Figure 5: NAT with private network on receiver Scenario 374 First, the sender must determine the public IP address of the 375 receiver. 377 One possibility is that an application level protocol is used. In 378 this case, the receiver must first find out its public IP addresses 379 at the middlebox on its side. This information about IP address and 380 port numbers could be signalled somehow to the actual sender directly 381 or indirectly via a third party. In the scenario, this means the 382 receiver has to determine its public IP address (NAT binding) and 383 register this address with the third party. 385 The sender can start NSIS signaling after he has received information 386 about the receiver's address and port number. 388 Note that it is part of the solution design where to terminate the 389 signaling messages. 391 5.5 Both end hosts are in same private network behind NATs 393 This is a special case, where the main problem is to detect that both 394 nodes are within the same network behind a NAT. This scenario 395 primarily addresses performance aspects. 397 Sender and receiver are both within a private address space and even 398 the address space might be the same. Figure 6 shows the ordering of 399 NATs. This is a common configuration in several networks. For 400 instance after two companies merge each network uses the same private 401 IP address space. 403 public 404 +----+ +----+ //----\\ 405 S --| MB |--+--| MB |---| | 406 +----+ | +----+ \\----// 407 | 408 | +----+ 409 +--| MB |------------ R 410 +----+ 412 private 414 MB: Middlebox 415 S: Data Sender 416 R: Data Receiver 418 Figure 6: NAT to public, receiver in same private network Scenario 420 The middleboxes are twice-NATs, i.e. they map the IP addresses and 421 port numbers on both sides, private and public interface. 423 From a protocol point of view, this means that the protocol must be 424 robust enough to at least not break with this scenario. 426 In the worst case, both sender and receiver obtain a public IP 427 address at the NAT and the communication path is not optimal anymore. 429 5.6 IPv4/v6 NAT with two private networks 431 This scenario combines the usage case mentioned in Section 5.2 with 432 the IPv4 to IPv6 transition scenario, i.e. using Network Address and 433 Protocol Translators (NAT-PT). 435 The difference to the other scenarios lies in the use of IPv6 - IPv4 436 address translation, which happens in both directions. Additionally, 437 the base NTLP must take care of this case for its own functionality 438 of forwarding messages between NSIS peers. 440 +----+ +----+ //----\\ +----+ //----\\ +----+ +----+ 441 S --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- R 442 +----+ +----+ \\----// +----+ \\----// +----+ +----+ 444 private public public private 445 IPv4 IPv6 447 MB: Middlebox 448 S: Data Sender 449 R: Data Receiver 451 Figure 7: IPv4/v6 NAT with two private networks 453 6. Trust Relationship and Authorization 455 Trust relationships and authorization are very important for the 456 protocol machinery. Trust and authorization closely related to each 457 other in the sense that a certain degree of trust is required to 458 authorize a particular action. If the action is "create/delete 459 packet filters" then authorization is very important due to the 460 nature of a firewall. 462 It is not particular surprising that differences exist between 463 authorization in a QoS signaling environment and firewall signaling. 464 As elaborate in [6] the establishment of a financial relationship is 465 very important for QoS signaling whereas for firewall signaling is 466 not directly of interest. 468 In the subsequent sections different trust relationships will be 469 described which appear in firewall signaling environments. 470 Peer-to-peer trust relationships are those, which are used in QoS 471 signaling today and seem to be the simplest. However, there are 472 reasons to believe that this is not the only type of trust 473 relationship found in today's networks. 475 6.1 Peer-to-Peer Trust Relationship 477 Starting with the simplest scenario it is assumed that neighboring 478 nodes trust each other. They required security association to 479 authenticate a signaling message and to protect it is either 480 available (manual configuration) or dynamically established with the 481 help of an authentication and key exchange protocol. If nodes are 482 located closely together it is assumed that security association 483 establishment is easier than establishing it between far distant 484 node. It is, however, difficult to describe this relationship 485 generally due to the different usage scenarios and environments. 486 Authorization heavily depends on the participating entities but for 487 this scenario it is assumed that neighboring entities are trust each 488 other to an extend that the packet filter creation and deletion is 489 allowed. Note that Figure 8 does not illustrate the trust 490 relationship between the end host and the access network, which is 491 dynamically established as part of the network access authentication 492 procedure as motivated in Section 1 . 494 +------------------------+ +-------------------------+ 495 | | | | 496 | Network A | | Network B | 497 | | | | 498 | +---------+ +---------+ | 499 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 500 | | | box 1 | Trust | box 2 | | | 501 | | +---------+ Relationship +---------+ | | 502 | | | | | | 503 | | | | | | 504 | | | | | | 505 | | Trust | | Trust | | 506 | | Relationship | | Relationship | | 507 | | | | | | 508 | | | | | | 509 | | | | | | 510 | +--+---+ | | +--+---+ | 511 | | Host | | | | Host | | 512 | | A | | | | B | | 513 | +------+ | | +------+ | 514 +------------------------+ +-------------------------+ 516 Figure 8: Peer-to-Peer Trust Relationship 518 6.2 Intra-Domain Trust Relationship 520 In larger corporations often more than one firewall is used to 521 protect different departments. In many cases the entire enterprise 522 is controlled by a security department, which gives instructions to 523 the department administrators. In such a scenario a peer-to-peer 524 trust-relationship might be prevalent. Sometimes however it might be 525 necessary to preserve authentication and authorization information 526 within the network. As a possible solution a centralized approach 527 could be used whereby an interaction between the individual 528 middleboxes and a central entity (for example a policy decision point 529 - PDP) takes place. As an alternative individual firewalls could 530 exchange the authorization decision to another firewalls within the 531 same trust domain. Individual middleboxes within an administrative 532 domain should exploit their trust relationship instead of requesting 533 authentication and authorization of the signaling initiator again and 534 again. Thereby complex protocol interaction is avoided. This 535 provides both a performance improvement without a security 536 disadvantage since a single administrative domain can be seen as a 537 single entity. Figure 9 illustrates a network structure which uses a 538 centralized entity. 540 +-----------------------------------------------------------+ 541 | | 542 | Network A | 543 | | 544 | | 545 | +---------+ +---------+ 546 | +----///--------+ Middle- +------///------++ Middle- +--- 547 | | | box 2 | | box 2 | 548 | | +----+----+ +----+----+ 549 | | | | | 550 | +----+----+ | | | 551 | | Middle- +--------+ +---------+ | | 552 | | box 1 | | | | | 553 | +----+----+ | | | | 554 | | | | | | 555 | - | | | | 556 | - | +----+-----+ | | 557 | | | | Policy | | | 558 | +--+---+ +-----------+ Decision +----------+ | 559 | | Host | | Point | | 560 | | A | +----------+ | 561 | +------+ | 562 +-----------------------------------------------------------+ 564 Figure 9: Intra-domain Trust Relationship 566 6.3 End-to-Middle Trust Relationship 568 In some scenarios a simple peer-to-peer trust relationship between 569 participating nodes is not sufficient. Network B might require 570 additional authorization of the signaling message initiator. If 571 authentication and authorization information is not attached to the 572 initial signaling message then the signaling message arriving at 573 Middlebox 2 would cause an error message to created which indicates 574 the additional authorization requirement. In many cases the 575 signaling message initiator is already aware of the additional 576 required authorization before the signaling message exchange is 577 executed. Replay protection is a requirement for authentication to 578 the non-neighboring firewall which might be difficult to accomplish 579 without adding additional roundtrips to the signaling protocol (e.g. 580 by adding a challenge/response type of message exchange). 582 Figure 10 shows the slightly more complex trust relationships in this 583 scenario. 585 +----------------------+ +--------------------------+ 586 | | | | 587 | Network A | | Network B | 588 | | | | 589 | | Trust | | 590 | | Relationship | | 591 | +---------+ +---------+ | 592 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 593 | | | box 1 | +-------+ box 2 | | | 594 | | +---------+ | +---------+ | | 595 | | | | | | | 596 | |Trust | | | | | 597 | |Relationship | | | | | 598 | | | | | Trust | | 599 | | | | | Relationship| | 600 | | | | | | | 601 | | | | | | | 602 | | | | | | | 603 | | | | | | | 604 | +--+---+ | | | +--+---+ | 605 | | Host +----///----+------+ | | Host | | 606 | | A | |Trust | | B | | 607 | +------+ |Relationship | +------+ | 608 +----------------------+ +--------------------------+ 610 Figure 10: End-to-Middle Trust Relationship 612 7. Problems and Challenges 614 This section describes a number of problems which have to be 615 addressed for NSIS NAT/Firewall. There are also of relevance for 616 other NSLP protocols. 618 7.1 Missing Network-to-Network Trust Relationship 620 Peer-to-peer trust relationship, as shown in Figure 8 , is a very 621 convenient assumption that allows simplified signaling message 622 processing. However, it might not always be applicable. Especially 623 the trust relationship between two arbitrary access networks (over a 624 core network where signaling messages are not interpreted) does 625 possibly not exist because of the large number of networks and the 626 unwillingness of administrators to have other network operators to 627 create holes in their firewalls without proper authorization. Hence 628 in the following scenario we assume a somewhat different message 629 processing and show three possible approaches to tackle the problem. 630 None of these three approaches is without drawbacks or constraining 631 assumptions. 633 +----------------------+ +--------------------------+ 634 | | | | 635 | Network A | | Network B | 636 | | | | 637 | +---------+ Missing +---------+ | 638 | +-///-+ Middle- | Trust | Middle- +-///-+ | 639 | | | box 1 | Relation- | box 2 | | | 640 | | +---------+ ship +---------+ | | 641 | | | or | | | 642 | | | Authorization| | | 643 | | | | | | 644 | | Trust | | Trust | | 645 | | Relationship | | Relationship | | 646 | | | | | | 647 | | | | | | 648 | | | | | | 649 | +--+---+ | | +--+---+ | 650 | | Host | | | | Host | | 651 | | A | | | | B | | 652 | +------+ | | +------+ | 653 +----------------------+ +--------------------------+ 655 Figure 11: Missing Network-to-Network Trust Relationship 657 Figure 11 illustrates a problem whereby an external node is not 658 allowed to manipulate (create, delete, query, etc.) packet filters at 659 a firewall. Opening pinholes is only allowed for internal nodes or 660 with a certain authorization permission. Hence the solution 661 alternatives focus on establishing the necessary trust with 662 cooperation of internal nodes. We have identified three possible 663 approaches of tackling the problem which are described in Appendix 664 D. 666 7.2 End-to-end significance 668 Also in the case of NAT/firewall traversals, we need to have the 669 end-to-end significance since more than one NAT/Firewall might be in 670 the path between a data sender and a data receiver. 672 7.3 Relationship with routing 674 The data path is following the "normal" routes. The NAT/FW devices 675 along the data path are those providing the service. In this case 676 the service is something like "open a pinhole" or even more general 677 "allow for connectivity between two communication partners". The 678 benefit of using path-coupled signaling is that the NSIS NATFW NSLP 679 does not need to take care where middleboxes can be found and in 680 which order they appear. 682 Creating NAT bindings modifies routing of data packets between end 683 points. This is unlike other NSIS NSLPs, which do not interfere with 684 routing - instead they only follow the path of the data packets. 686 7.4 Dynamic state installation and maintenance 688 For NAT/Firewall traversal, the lifetime of a NAT binding or a packet 689 filter must be provided and needs to be continuously refreshed. So 690 specifically for short-lived flows signaling for pinholes and NAT 691 bindings is preferable. The capability to specify a lifetime for a 692 NAT binding provides some advantages to what exists today where 693 unknown NAT binding lifetimes can lead to unexpected protocol 694 actions. 696 For more static behavior both NAT bindings and pinholes can be 697 provisioned statically and no signaling is used. For static state 698 other mechanisms than an NSIS signaling protocol might be preferable. 699 Most time this is a matter of configuration of a middlebox using a 700 management protocol such as SNMP or CLI. 702 7.5 Affected Parts of the Network 704 NATs and Firewalls tend to be located at the edge of the network, 705 whereby other signaling applications effect all nodes along the path. 706 One typical example is QoS signaling where all networks along the 707 path must provide QoS in order to achieve true end-to-end QoS. In 708 the NAT/Firewall case, only some of the domains/nodes are affected 709 (typically access networks), whereas most parts of the networks and 710 nodes are unaffected (e.g. the core network). 712 This fact raises some questions. Should an NSIS NTLP node intercept 713 every signaling message independently of the upper layer signaling 714 application or should it be possible to make the discovery procedure 715 more intelligent to skip nodes. These questions are also related to 716 the question whether NSIS NAT/FW should be combined with other NSIS 717 signaling applications. 719 7.6 Traversing NSIS unaware domains 721 Signaling of QoS information even works if NSIS (or QoS NSLP) unaware 722 domains are traversed. The thinking behind this is that we hope to 723 get the best even if traversing unaware domains. Although it might 724 not produce the desired effect from a Quality of Service point of 725 view it is still possible for NSIS messages to reach the intended end 726 host. 728 With firewalls the situation is somewhat different. An NSIS unaware 729 firewall should actually reject such a request. Since firewalls 730 typically implement the policy "default = deny" the traversal of NSIS 731 signaling messages must be We believe this is easily possible by 732 normal firewall functionality. So this does not seam to be a real 733 problem in most cases. But this is a deployment problem, since all 734 firewalls along the path must be NSIS aware in order to get an open 735 path. Which packet filters are required to allow NSIS signaling 736 messages itself to pass the firewall depends on the NSIS signaling 737 message. Since RSVP signaling messages are addressed end-to-end (in 738 case of the path message) it is necessary to create a packet filter, 739 which allows IP datagrams using protocol 46 to pass. For signaling 740 protocols, which perform peer-to-peer addressing, addressing of a 741 specific port needs to be allowed (assuming that a transport protocol 742 is used and that the firewall or NAT is NSIS aware). 744 For NATs this is more problematic since signaling messages are 745 forwarded (at least in one direction), but with a changed IP address 746 and changed port numbers. The content of the NSIS signaling message 747 is, however, unchanged. This can lead to unexpected results. NSIS 748 unaware NATs must be detected in order to let all entities involved 749 take care of that situation and in order to work correctly. Such a 750 "legacy" NAT detection procedure can be done during the NSIS discover 751 procedure itself. 753 Based on experience it was discovered that routers unaware of the 754 Router Alert IP option [RFC 2113] discarded packets. This is 755 certainly a problem for NSIS signaling. 757 7.7 Authentication and Authorization 759 Since a firewall has security functionality, strong authentication 760 and authorization means MUST be provided. 762 For NATs security is not a major concern, but might play a role in 763 the perceived security measure of some administrators. For NAT 764 sometimes address depletion is mentioned as a threat. 766 7.8 Directional Property 768 A firewall has a directional property. Hosts are sitting behind a 769 firewall, or hosts are in the intra-net. Others are outside the 770 firewall. So from a security point of view, the way NSIS signaling 771 messages enters the NSIS agent of a firewall (see Figure 2) might be 772 important, because different policies might apply for authentication 773 and admission control. 775 Also for NATs there is a natural direction from the private to the 776 public address space. Only after establishing the NAT binding 777 packets can flow in both directions. NAT bindings are therefore 778 typically created by data traffic originating from the internal 779 network. 781 Most of the time hosts inside the firewall-protected domain are more 782 trusted than external hosts. However, based on changes in the 783 network architecture and the corporate policy not even this might be 784 true anymore. Nevertheless it would imply that the data sender and 785 the data receiver might need to tell their respective firewalls that 786 it should open a pinhole. In general it is inappropriate to perform 787 operations on the firewall from the outside; particularly without 788 sufficient authorization privileges. 790 7.9 Routing Asymmetry 792 Routing asymmetry [7] is a general problem for path-coupled 793 signaling. Similarly to path-coupled QoS signaling firewall 794 signaling also has to be aware of the routing asymmetry although the 795 routing asymmetry might not be large within the local networks where 796 firewalls are typically located. For signaling NAT bindings this 797 issue comes with a different flavor since an established NAT binding 798 changes the path of the data packets. Hence a data receiver might 799 still be able to send NSIS signaling messages to create a NAT 800 binding, although they travel the previously "wrong" path. 802 7.10 Addressing 804 Also a more general problem of NATs is the addressing of the 805 end-point. NSIS signaling message have to be addressed to the other 806 end host to follow data packets subsequently sent. Therefore a 807 public IP address of the receiver has to be known. When NSIS 808 signaling messages contain IP addresses of the sender and the 809 receiver in the signaling message payloads, then an NSIS agent must 810 modify them. This is one of the cases, where a NSIS aware NATs is 811 also helpful for other types of signaling applications e.g. QoS 812 signaling. 814 7.11 NTLP/NSLP NAT Support 816 It must be possible for NSIS NATs along the path to change NTLP and/ 817 or NSLP message payloads , which carry IP address and port 818 information. This functionality includes the support of providing 819 mid-session and mid-path modification of these payloads. As a 820 consequence these payloads must not be reordered, integrity protected 821 and/or encrypted in a non peer-to-peer fashion (e.g. end-to-middle, 822 end-to-end protection). Ideally these mutable payloads must be 823 marked (e.g. a protected flag) to assist NATs in their effort of 824 adjusting these payloads. 826 7.12 Route changes 828 The effect of route changes are more severe than in other signaling 829 applications since a firewall pinhole and NAT binding is needed 830 before further communication can takes place. This is true for both 831 NSIS signaling and for subsequent data traffic. If a route changes 832 and NSIS signaling messages do not configure NSIS NATs and firewalls 833 along the new path then the communication is temporarily interrupted. 834 This is naturally a big problem for networks where routes frequently 835 change e.g. ad-hoc networks or in case of fast mobility. In these 836 cases either refresh messages and/or triggers have to provide a 837 mechanism for fast reaction. 839 7.13 Combining Middlebox and QoS signaling 841 In many cases, middlebox and QoS signaling has to be combined at 842 least logically. Hence it was suggested to combine them into a 843 single signaling message or to tie them together with the help of the 844 same session identifier. This, however, has some disadvantages such 845 as: - NAT/FW NSLP signaling affects a much small number of NSIS nodes 846 along the path (for example compared to the QoS signaling). - NAT/FW 847 signaling might show different signaling patters (e.g. required 848 end-to-middle communication). - The refresh intervals are likely to 849 be different. - The number of error cases increase as different 850 signaling applications are combined into a single message. The 851 combination of error cases has to be considered. 853 7.14 Difference between sender- and receiver-initiated signaling 855 For NAT/FW signaling there seems to be little difference between 856 sender- and receiver- initiated signaling messages. Some other 857 characteristics of QoS signaling protocols are not applicable (e.g. 858 the adspec object) to the NAT/FW context. It seems that a full 859 roundtrip is always required if the protocol aims to be generic 860 enough. 862 7.15 Inability to know the scenario 864 In Section 5 a number of different scenarios are presented. In some 865 scenario NSIS signaling is fairly easy whereas in others it is quite 866 complex. Additionally different trust relationships exist between 867 networks along the path, which might require interaction with the end 868 host or a different signaling behavior. However, the user (or the 869 NSIS agent initially) typically does not know which scenario is 870 currently applicable. To make things worse, the scenario might 871 actually change with moving networks, adhoc networks or with mobility 872 in general. Hence NSIS signaling must assume the worst case and 873 cannot put responsibility to the user to know which scenario is 874 currently applicable. As a result, it might be necessary to perform 875 a "discovery" periodically such that the NSIS agent at the end host 876 has enough information to decide which scenario is currently 877 applicable. This additional messaging, which might not be necessary 878 in all cases, eats performance, bandwidth and adds complexity. 879 Additional information by the user can provide information to assist 880 this "discovery" process but cannot replace it. 882 Some protocols already aim to provide a solution for an end host to 883 learn something about the topology such as STUN [3]. To some extend 884 these protocols can help NSIS NAT/FW signaling. 886 8. Security Considerations 888 Security is of major concern specifically if the middlebox is a 889 firewall. General threats to signaling have been discussed in [2]. 890 These apply here as well. Additionally, the draft discusses some 891 problems concerning security for that specific purpose. 893 Normative References 895 [1] Brunner et al., M., "Requirements for Signaling Protocols", 896 DRAFT draft-ietf-nsis-req-07.txt, March 2003. 898 [2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 899 DRAFT draft-ietf-nsis-threats-01.txt, January 2003. 901 [3] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 902 Simple Traversal of User Datagram Protocol (UDP) Through Network 903 Address Translators (NATs)", RFC 3489, March 2003. 905 [4] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 906 Rayhan, "Middlebox communication architecture and framework", 907 RFC 3303, August 2002. 909 Informative References 911 [5] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K. 912 Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt, 913 November 2002. 915 [6] Tschofenig, H., Buechli, M., Van den Bosch, S. and H. 916 Schulzrinne, "NSIS Authentication, Authorization and Accounting 917 Issues", draft-tschofenig-nsis-aaa-issues-01 (work in 918 progress), March 2003. 920 [7] Amini, L. and H. Schulzrinne, "Observations from router-level 921 internet traces", DIMACS Workshop on Internet and WWW 922 Measurement, Mapping and Modelin Jersey) , Februar 2002. 924 [8] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 925 Traversal of VPN Gateways", 926 draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in 927 progress), April 2003. 929 [9] Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin, 930 "Problem Space and Usage Scenarios for PANA", 931 draft-ietf-pana-usage-scenarios-06 (work in progress), April 932 2003. 934 [10] Shore, M., "The TIST (Topology-Insensitive Service Traversal) 935 Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002. 937 [11] Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT 938 Traversal Client for CASP", DRAFT 939 draft-tschofenig-nsis-casp-midcom-01.txt, March 2003. 941 [12] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 942 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 943 Session Initiation Protocol", RFC 3261, June 2002. 945 [13] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 946 RFC 3234, February 2002. 948 Authors' Addresses 950 Marcus Brunner 951 Network Laboratories, NEC Europe Ltd. 952 Kurfuersten-Anlage 36 953 Heidelberg 69115 954 Germany 956 Phone: +49 (0) 6221 905 11 29 957 EMail: brunner@ccrle.nec.de 958 URI: http://www.brubers.org/marcus 960 Martin Stiemerling 961 Network Laboratories, NEC Europe Ltd. 962 Kurfuersten-Anlage 36 963 Heidelberg 69115 964 Germany 966 Phone: +49 (0) 6221 905 11 13 967 EMail: stiemerling@ccrle.nec.de 968 URI: 970 Miquel Martin 971 Network Laboratories, NEC Europe Ltd. 972 Kurfuersten-Anlage 36 973 Heidelberg 69115 974 Germany 976 Phone: +49 (0) 6221 905 11 0 977 EMail: lopez@ccrle.nec.de 978 URI: 980 Hannes Tschofenig 981 Siemens AG 982 Otto-Hahn-Ring 6 983 Munich 81739 984 Germany 986 Phone: 987 EMail: Hannes.Tschofenig@siemens.com 988 URI: 990 Henning Schulzrinne 991 Columbia University, Dept. of Computer Science 992 1214 Amsterdam Avenue 993 New York NY 10027 994 USA 996 Phone: 997 EMail: schulzrinne@cs.columbia.edu 998 URI: http://www.cs.columbia.edu/~hgs/ 1000 Appendix A. Interworking of SIP with NSIS NATFW NSLP 1002 This document aims at pinpointing the problems of using SIP in 1003 nowadays networks, focusing on the problems derived of NAT's, 1004 Firewalls and multi-path communications. It is intended to fit in a 1005 scenario description that shows the necessity of NSIS, as well as 1006 depicting it's requirements. However, note that there are a number 1007 of other solutions available. For example the IETF Midcom working 1008 group is working on [4]. 1010 A.1 The Session Initiation Protocol 1012 [12] describes the Session Initiation Protocol, an application-layer 1013 control protocol that can establish, modify, and terminate multimedia 1014 sessions. This often involves several flows for video and voice, 1015 which are transported over new connections. These use of dynamically 1016 allocated ports which results in protocol complexity which can not be 1017 handled by nowadays NAT's and Firewalls. 1019 Session initiation when one or both of the users is behind a NAT is 1020 also not possible, given the impossibility to address a private IP 1021 over the internet. Moreover, network deployments often allow for 1022 different paths per connection and direction, making the setup of the 1023 middle boxes even more complicated. 1025 The following figure depicts a typical SIP connection: 1027 Ernie(192.0.2.1) Bert(192.0.2.2) 1028 | | 1029 | 1# SIP INVITE | 1030 +--------------------------------------->| 1031 | 1032 | 2# SIP Ringing | 1033 |<---------------------------------------+ 1034 | | 1035 | 3# SIP OK | <-- Call accepted 1036 |<---------------------------------------+ 1037 | | 1038 | 4# SIP ACK | 1039 +--------------------------------------->| 1040 | | 1041 | 5# DATA | 1042 |=======================================>| 1043 |<=======================================| 1044 | | 1046 1# SIP Invite (192.0.2.1:? -> 192.0.2.2:SIP): I Listen on 1047 192.0.2.1:1000 Ernie invites Bert to the conference, and informs 1048 it's awaiting media data on port 1000. 1050 2# SIP Ringing (192.0.2.2:SIP -> 192.0.2.1:?): Ringing Bert's 1051 phone The ringing simply inplies that there's something sip aware 1052 on Berts side, and that it's ringing his phone 1054 3# SIP OK (192.0.2.2:SIP -> 192.0.2.1:?): Call accepted, I listen 1055 on 192.0.2.2:2000 This OK means that the Bert took the phone off 1056 hook, and thus accepted the call. It also informs Ernie that Bert 1057 is awaiting his media data at port 2000 1059 4# SIP ACK (192.0.2.1:? -> 192.0.2.2:SIP): All is fine, start 1060 transmitting. ACK means the ports are accepted and the call can 1061 start in the slected data ports on both sides. 1063 5# DATA (192.0.2.1:? -> 192.0.2.2:2000 and 192.0.2.2:? -> 1064 192.0.2.1:1000): Voice,image, video.. This is the actual data 1065 being transmited. 1067 In the above example, SIP is used successfully to establish a 1068 communication, which includes negotiating the data ports for the 1069 actual transmission. Unfortunatelly, this scheme will not work for 1070 more complex setups. 1072 Let's now consider one firewall in the data path, be it on Ernie's or 1073 Bert's network, or elsewhere in the middle. We assume that the 1074 firewall is allowing traffic directed to the SIP port. As to the 1075 rest of the ports, a typical setup involves outgoing connections 1076 being allowed, and incoming connections being dropped, except for 1077 those already established. That is, we allow packets to go out and 1078 their replies to come in, but disable all other traffic. 1080 In this case, the connection is as follows, for the case of a 1081 firewall on Ernie's network: 1083 Ernie(192.0.2.1) FW Bert(192.0.2.2) 1084 | | | 1085 | 1# SIP INVITE | | 1086 +--------------------------------------->| 1087 | | | 1088 | | 2# SIP Ringing | 1089 |<---------------------------------------+ 1090 | | | 1091 | | 3# SIP OK | <-- Call accepted 1092 |<---------------------------------------+ 1093 | | | 1094 | 4# SIP ACK | | 1095 +--------------------------------------->| 1096 | | | 1097 | 5# DATA | | 1098 |=======================================>| 1099 | |<=======================| 1100 | | | 1102 Notice how the SIP messages #1 and #4 traverse the firewall, because 1103 they are outbound, and how 2# and 3# traverse it too, because they 1104 are replies to the connection established at 1#. 1106 Notice now how 5# can go outwards, but Bert can not go through the 1107 firewall to reach Ernie's port 1000. The reason is the connection is 1108 a new one, and the firewall won't allow it through. 1110 Bert will now get media from Ernie, but Ernie is never going to get 1111 anything from Bert. The call is thus considered unsuccessful. The 1112 reason is that the application level port negotiation is never 1113 acknowledge by the network-transport layer firewall, which doesn't 1114 know what to expect. We would still face the same problem if the 1115 connection used a SIP Proxy, for it would only translate names into 1116 IP addresses. 1118 Let us now assume that we indeed have an application layer firewall, 1119 be it by design, or because we load some sort of SIP module to it. 1120 The previous case would now work, since the firewall can now 1121 understand the packets going through it and open the necessary ports. 1122 Still, we cannot assume that SIP signalization packets and the actual 1123 data follow the same path. The following figure shows a likely 1124 setup. FW+ stands for one or more firewalls: 1126 SIP Signalization Path +-----+ 1127 /---------------->-----------| FW+ |-------\ 1128 | +-----+ | 1129 +------+ +------+ +-----+ 1130 |Ernie |----|Router| |Bert | 1131 +------+ +------+ +-----+ 1132 | Data Path +-----+ | 1133 \---------------->-----------| FW+ |-------/ 1134 +-----+ 1136 The SIP packets with the information about the listening ports now 1137 travels on the SIP Signalization path, and so the firewalls on that 1138 path can read them. The Data, though, is traveling through the Data 1139 path, and the firewalls in that path never get to see the Invite and 1140 Ok packets. They are thus unable to open the ports. 1142 Two issues are arisen here: first, we need on-path signalization 1143 unless we already know the path our packets will take; a highly 1144 unlikely situation in today's internet. Second, if we patch the 1145 firewalls to understand SIP, we will provide any caller with a 1146 hole-puncher for the firewall, since SIP is not provisioned with 1147 proper authentication mechanism. 1149 It is now clear that tight firewalls prevent SIP from successfully 1150 working. There is still another obstacle: NATs. 1152 NATs provide for a link between two different address spaces, 1153 typically connecting a private range network to a public range one. 1154 As a consequence, connections going from the inside (usually the 1155 private range) are translated using the NAT's public interface 1156 address, and the replies are routed back. The public side of the 1157 network can only see the NATs public interface, and know nothing of 1158 the private network inside. This means computers outside the NAT 1159 won't be able to address computers inside the NAT. 1161 Let us analyze the SIP example when Ernie is behind a NAT. The 1162 following figure depicts a typical session: 1164 Ernie(10.0.0.2) (10.0.0.1) NAT (192.0.2.1) Bert(192.0.2.2) 1165 | | | 1166 | 1# SIP INVITE | | 1167 +--------------------------\ | 1168 | |----------------->| 1169 | | | 1170 | | 2# SIP Ringing | 1171 | /------------------+ 1172 |<-------------------------| | 1173 | | | 1174 | | 3# SIP OK | <-- Call accepted 1175 | /------------------+ 1176 |<-------------------------| | 1177 | | | 1178 | 4# SIP ACK | | 1179 +--------------------------\ | 1180 | |----------------->| 1181 | | | 1182 | 5# DATA | | 1183 |==========================\ | 1184 | |=================>| 1185 | | ?<=============| 1186 | | | 1188 The communication is analogous to the one in the previous examples, 1189 except for the fact the NAT is rewriting the source address of the 1190 packets as they traverse it. 1192 For instance, packet 1# is going from 10.0.0.2:? towards 1193 192.0.2.2:SIP. The NAT box intercepts the message and puts 1194 192.0.2.1:? as the source address and port, with ? being a 1195 dynamically picked port, which might be different from the original 1196 one 1# used. 1198 On the way back, Bert is replyinc to the source of the IP packet, 1199 that is, 192.0.2.1, and so, when 2# reaches 192.0.2.1, the NAT know 1200 it is a reply from 1#, because it established a NAT binding, and this 1201 replaces the destination address, 192.0.2.1:? with 10.0.0.2:? and 1202 forwards the packet inside the NAT. 1204 As a result, Ernie never knows there is a NAT in his communication 1205 path, since he sends and receives packets from 192.0.2.2 normally. 1206 This means that the INVITE packet will tell Bert to send data back to 1207 10.0.0.2, a private IP. Once the signalization is finished, and the 1208 actual DATA transmission starts, Bert tries to connect to 10.0.0.2, a 1209 private IP address, from the internet; The routers don't know how to 1210 route this, and the packet is eventually dropped. 1212 One possible solution would be for Ernie to know the NAT exists, and 1213 already indicate that it listens on 192.0.2.1, and not 10.0.0.2. 1214 That, still would not work, since the NAT binding is not performed at 1215 the NAT box. 1217 A.2 Conclusions 1219 The above examples display the inability to use standard SIP through 1220 tight firewalls or NATs, and points at the necessity of a secure 1221 on-path protocol to negotiate firewall pinholes and NAT bindings. 1223 Appendix B. Ad-Hoc networks 1225 Some forms of ad-hoc networks exist where trust in the network is not 1226 justified. Figure Figure 16 mainly illustrates the problems of 1227 malicious NSIS entities graphically: 1229 +------------------------------------------+ +--------// 1230 | Adhoc | | ISP 1231 | Network | | 1232 | regular data | | 1233 | traffic by +---------+ | | 1234 | node A |Malicious| | +-+--------+ 1235 | +-------------->+ Node +-----+///-->+ Firewall +-// 1236 | ^ | 3 |===========>| 1 | 1237 | | +---------+ injected +-+--------+ 1238 | | data traffic | 1239 | | | | 1240 | | | | 1241 | +---+-----+ +---------+ | | 1242 | + Node | | Node | | | 1243 | | 1 | | 2 | | | 1244 | +---------+ +---------+ | | 1245 | ^ | +--------// 1246 | | | 1247 +----------+-------------------------------+ 1248 | 1249 +--+---+ 1250 | Node | 1251 | A | 1252 +------+ 1254 Figure 16: Limits of packet filter security 1256 An ad-hoc networks consists of a number of nodes between the end host 1257 (Node A) and the ISP to which Node A wants to get access. Although 1258 Node A uses an authentication and key exchange protocol to create a 1259 policy rule at the firewall 1 it is still possible for an untrusted 1260 node (in this case Node 3) to inject data traffic which will pass 1261 Firewall 1 since the data traffic is not authenticated. To prevent 1262 this type of threat two approaches are possible. First, a 1263 restrictive packet filter limits the capabilities of an adversary. 1264 Finally, there is always the option of using data traffic protection. 1266 Appendix C. Interworking of Security Mechanisms and NSIS NATFW NSLP 1268 TBD 1270 Appendix D. Solution approaches in case of missing authorization 1272 D.1 Solution Approach: Local authorization from both end points 1274 The first approach makes use of local authorization from both end 1275 points. If Host A sends a signaling message toward the destination 1276 to Middlebox 1 the message will perform the desired action in Network 1277 A. Middlebox 1 establishes some state information and forwards the 1278 signaling message towards Host B. Signaling message protection 1279 between the two access networks might be difficult. A missing trust 1280 relationship does not necessarily mean that no security association 1281 establishment is possible. The lacking trust disallows Middlebox 1 1282 (or indirectly Host A where the signaling message was initiated) to 1283 create packet filters at Middlebox 2. We assume that the NSIS 1284 signaling message is allowed to pass the firewall then it finally 1285 reaches Host B. Due to the missing authorization no packet filter 1286 specific state is created. The filters will be installed later after 1287 receiving an authorization from Host B. When Host B returns a 1288 confirmation or acknowledgement then Middlebox 2 treats it as an 1289 authorization and finally triggers filter creation. The message is 1290 then forwarded to Middlebox 1, where filters are either already 1291 installed or require an additional confirmation. Finally the 1292 signaling message is forwarded to Host A, which can be assured that 1293 subsequent data traffic can be transmitted end-to-end from Host A to 1294 Host B. The same procedure has to be applied again to signal 1295 information for the other direction (Host B to Host A). 1297 The following behavior has to be assumed in order for this approach 1298 to be applicable: 1300 1. Signaling messages must be allowed to pass firewalls along the 1301 path. 1303 2. NSIS signaling must operate in the described manner which could 1304 be described as: Install where you have authorization - delay and 1305 forward where you have no authorization. 1307 This approach suffers from the following drawbacks: 1309 1. Firewalls which block NSIS signaling from external networks or 1310 nodes prevent a successful operation. 1312 2. A full roundtrip is required to signal packet filter information. 1313 The NSIS signaling message must therefore provide the capability 1314 to route signaling message in both direction which might either 1315 require state installation at nodes along the path (route 1316 pinning) or a stateless version via record-route. Some risk of 1317 DoS protection might exist. 1319 D.2 Solution Approach: Access Network-Only Signaling 1321 The next approach is based on signaling packet filter information by 1322 both hosts into the local access network only. An NSIS allows 1323 specifying such a behavior by indicating the signaling endpoint with 1324 the help of scoping (for example with domain name or a "local network 1325 only" flag). Scoping means that the signaling message although 1326 addressed to a particular destination IP address terminates somewhere 1327 along the path. If packet filters for both directions have to be 1328 installed then the signaling messages have to make packet filter 1329 installations up- and downstream along the data path. Similar to 1330 proposals in the area of QoS signaling some problems are likely to 1331 occur. One such problem is that downstream signaling in general 1332 causes problems because of asymmetric routes. In particular it is 1333 difficult to determine the firewall where the downstream data traffic 1334 will enter a network. The problem of triggering downstream 1335 reservations is for example described in [5] . Another problem for 1336 example is the placement of a firewall or NAT along the path other 1337 than in the access network. This would prevent a successful data 1338 exchange. 1340 The following behavior has to be assumed in order for this approach 1341 to be applicable: 1343 1. It must be possible to trigger a signaling message exchange for a 1344 downstream signaling message exchange at the firewall where the 1345 data traffic enters the network. 1347 2. No other firewalls or NATs are present along the path other than 1348 in the access network. 1350 This approach suffers from the following drawbacks: 1352 1. To signal policy rules only within the access network (by both 1353 end-points) has a number of disadvantage and challenges (see for 1354 example [5] ). The complex message processing caused by this 1355 approach strongly argues against it although it might sound 1356 simple (and even might be simple in restricted environments). 1358 2. Complex topologies might lead to ineffective policy rules (i.e. 1359 data traffic hits firewalls hits wrong firewalls). 1361 D.3 Solution Approach: Authorization Tokens 1363 The last approach is based on some exchanged authorization tokens 1364 which are created by an authorized entity (such as the PDP) or by a 1365 trusted third party. Both end hosts need to exchange these tokens 1366 with protocols such as SIP or HTTP since these protocols are likely 1367 to be allowed to bypass the firewall. The basic idea of this 1368 approach is to provide an end host, which requests access to the 1369 network, with credentials (referred as authorization tokens). These 1370 tokens have to possess some properties, namely: 1372 1. They have to be restrictive by including lifetimes, source and 1373 destination identifiers, usage indication and more. 1375 2. They have to provide basic replay protection to prevent 1376 unauthorized reuse. 1378 3. The have be cryptographically protected to prevent manipulations. 1380 4. There has to be a mechanism to dynamically create them for a 1381 specific reason and to distribute them to the end points. 1383 5. It has to be possible to exchange tokens via a trusted third part 1384 in cases where no direct communication between the end hosts is 1385 possible (due to NAT). 1387 6. The token can be created locally at the network or by a trusted 1388 third party. 1390 An example of a possible signaling communication could have the 1391 following structure: After exchanging the tokens between the two end 1392 hosts. Host A would include the received authorization token to the 1393 signaling message for Network B. When the signaling message arrives 1394 at Middlebox 2 then the token is verified by the token-creating 1395 entity. In order to prevent parties from reusing the token 1396 timestamps (e.g. token creation, token lifetime, etc.) have to be 1397 included. Adding IP address information about Host A would create 1398 difficulties in relationship with NATs. Information about Host B 1399 might be possible to include in order to limit attacks where a token 1400 is lost and reused by a different host for a different purpose. The 1401 goal is to restrict the usage of the token for a specific session. 1402 The content of the token only needs to be verified by the originator 1403 of the token since it only has to be verified locally. Since 1404 authorization needs to be linked to the authorized actions, which 1405 have to be performed on the packets matching the packet filter, the 1406 token may include the associated action or a reference to it. The 1407 following behavior has to be assumed in order for this approach to be 1408 applicable: 1410 1. The exchange of authorization tokens between end-systems must be 1411 possible. These protocols must be allowed to pass the firewalls. 1413 2. An end-system must be able to request such an authorization token 1414 at some entity in the local network or at a trusted third party. 1416 This approach suffers from the following drawback: 1418 1. Possibly an additional protocol is required for an end host to 1419 request an authorization token from an entity in the local 1420 network. 1422 Intellectual Property Statement 1424 The IETF takes no position regarding the validity or scope of any 1425 intellectual property or other rights that might be claimed to 1426 pertain to the implementation or use of the technology described in 1427 this document or the extent to which any license under such rights 1428 might or might not be available; neither does it represent that it 1429 has made any effort to identify any such rights. Information on the 1430 IETF's procedures with respect to rights in standards-track and 1431 standards-related documentation can be found in BCP-11. Copies of 1432 claims of rights made available for publication and any assurances of 1433 licenses to be made available, or the result of an attempt made to 1434 obtain a general license or permission for the use of such 1435 proprietary rights by implementors or users of this specification can 1436 be obtained from the IETF Secretariat. 1438 The IETF invites any interested party to bring to its attention any 1439 copyrights, patents or patent applications, or other proprietary 1440 rights which may cover technology that may be required to practice 1441 this standard. Please address the information to the IETF Executive 1442 Director. 1444 Full Copyright Statement 1446 Copyright (C) The Internet Society (2003). All Rights Reserved. 1448 This document and translations of it may be copied and furnished to 1449 others, and derivative works that comment on or otherwise explain it 1450 or assist in its implementation may be prepared, copied, published 1451 and distributed, in whole or in part, without restriction of any 1452 kind, provided that the above copyright notice and this paragraph are 1453 included on all such copies and derivative works. However, this 1454 document itself may not be modified in any way, such as by removing 1455 the copyright notice or references to the Internet Society or other 1456 Internet organizations, except as needed for the purpose of 1457 developing Internet standards in which case the procedures for 1458 copyrights defined in the Internet Standards process must be 1459 followed, or as required to translate it into languages other than 1460 English. 1462 The limited permissions granted above are perpetual and will not be 1463 revoked by the Internet Society or its successors or assignees. 1465 This document and the information contained herein is provided on an 1466 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1467 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1468 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1469 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1470 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1472 Acknowledgement 1474 Funding for the RFC Editor function is currently provided by the 1475 Internet Society.