idnits 2.17.1 draft-ietf-midcom-scenarios-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 94 instances of lines with control characters in the document. ** The abstract seems to contain references ([Invite], [MIDBOXFRAME]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 17, 2001) is 8379 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) -- Missing reference section? 'MIDBOXFRAME' on line 968 looks like a reference -- Missing reference section? 'RFC2237' on line 958 looks like a reference -- Missing reference section? 'RFC1889' on line 961 looks like a reference -- Missing reference section? 'RFC2766' on line 965 looks like a reference -- Missing reference section? 'RFC3056' on line 955 looks like a reference -- Missing reference section? 'Bradner' on line 922 looks like a reference -- Missing reference section? '1996' on line 922 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 Expires November 17, 2001 May 17, 2001 5 MIDCOM Scenarios 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 As trusted third parties are increasingly being asked to make policy 31 decisions on behalf of the various entities participating in an 32 application's operation, a need has developed for applications to be 33 able to communicate their needs to the devices in the network that 34 provide transport policy enforcement. Examples of these devices 35 include firewalls, network address translators (both within and 36 between address families), signature management for intrusion 37 detection systems, and multimedia buffer management. These devices 38 are a subset of what can be referred to as 'middle boxes.' This 39 document describes traversal scenarios that a 'middle box traversal 40 protocol' should enable. 42 1 Introduction 44 In order to delineate the requirement of the MIDCOM protocol, we 45 present here a set of scenarios that should be enabled by this 46 protocol. The scenarios include running a server behind a 47 NAT/Firewall, enabling direct connection between peers that exchange 48 addresses in an ad-hoc way, e.g. through an instant messaging 49 service, and enabling peer-to-peer communication with explicit 50 signaling, e.g. using SIP or H.323. These scenarios may include 51 several variants that we will present. We also present the evolution 52 of these scenarios when IPv6 provides global addresses, and 53 introduce the "6to4 router" scenario required for IPv6 transition, 54 and the IPSEC scenario enabled by IPv6. 56 Huitema [Page 1] 57 The main purpose of this exercise is to explain the nature of the 58 holes that would have to be opened for the applications to work, so 59 as to derive the "functional requirements" of the firewall traversal 60 protocol. It is quite clear that there are other requirements, 61 notably security requirements. The scenarios described what the 62 application needs in order to run; whether the application is 63 actually allowed to run or not is a matter of local policy. In order 64 to meet the security requirements, the protocol will have to enable 65 adequate controls. In order to better understand how a security and 66 control can be applied, the scenarios include examples where 67 authentication is a gating operation. 69 This memo uses the definitions introduced in [MIDBOXFRAME], in 70 particular the definition of a Firewall/NAT. 72 2 Scenarios 74 In the following, we document a set of realistic scenarios that 75 should be enabled by a firewall traversal protocol. These scenarios 76 include: 78 * Placing a server behind a firewall/NAT, 80 * Enabling ad-hoc peer-to-peer applications, 82 * Enabling peer-to-peer communication through explicit signaling 83 systems such as SIP or H.323. 85 We also take into account the deployment of IPv6, which introduces 86 variants of the previous scenarios, as well as new scenarios such as 87 the establishment of tunnels for carrying IPv6 packets through a 88 firewall, or the establishment of IPSEC associations between 89 internal and external hosts. 91 2.1 TCP server behind a firewall/NAT 93 An internal server wants to receive TCP-IP connections requests from 94 the outside (where outside is some place outside a domain). An 95 example is, running a web server in a domain protected by a 96 firewall. 97 __________ _________ 98 | |-----[DNS Query]-------->| | ___________ 99 | external |<---[DNS Response]------<| N.S. | | | 100 | host | |_________| | Internal | 101 |__________| | Host | 102 v |___________| 103 v __________ v ^ 104 v | |<--midcom -----/ ^ 105 v | firewall | ^ 106 \>>>Connection Attempt>>>>| / NAT |>>>>>>>>>>>>>>>>>>^ 107 |__________| 109 Huitema [Page 2] 110 In this scenario, the internal host publishes the IP address and TCP 111 port number at which it can be joined in a name server, using for 112 example SRV and A records in the DNS. The IP address that is 113 published must be valid in the "external" domain; if this external 114 domain is the current Internet, the published IP address must be 115 valid in the global Internet. 117 The scenario implies that the following operations happen in 118 sequence: 120 1) The internal host interacts with the firewall/NAT, using the 121 midcom protocol. As a result of the interaction, the internal 122 host learns the IP address and TCP port that it may advertise to 123 external parties. 125 2) The internal host publishes the information in a name server. 127 3) The external host obtains the information from the name server. 129 4) The external host issues a TCP connection request, and sends a 130 TCP SYN packet. 132 5) The firewall/NAT receives the packet, performs address 133 translations and port mapping if necessary, and relays the TCP 134 SYN packet to the internal host. 136 6) After that point, the TCP connection proceeds. 138 In the diagram, we depict only one external host, but this is an 139 example, not a limitation. Once the address and ports are published 140 in the name server, an unlimited number of external hosts may 141 attempt to connect to the internal server. 143 It is quite clear that the interaction between the internal host and 144 the firewall/NAT described in the first step of the scenario may 145 require some form of access control. The specific form of access 146 control will depend of the internal domain's policies. In practical 147 examples, these policies varies from allowing all internal hosts to 148 run services, in un-managed domains, to allowing only a specific set 149 of services on a specific set of hosts. 151 A particular result of the access control is that the first step of 152 this scenario may indeed fail, either because the opening of a hole 153 is not authorized or because the firewall/NAT does not have 154 sufficient resources. The internal host will explicitly learn that 155 it should not advertise any IP address or TCP port to third parties. 156 In this case, the host should not publish information, and external 157 hosts should not attempt to establish connections. 159 It is important that the behavior of the firewall/NAT be consistent: 160 if the mapping request at step 1 fails, then we expect that an 162 Huitema [Page 3] 163 attempt to establish a connection from an external host will be 164 rejected; conversely, if the mapping request succeed, then we expect 165 the establishment of TCP connections to also succeed. 167 There are two interesting variants of that scenario: the use of UDP 168 instead of TCP, and the control of the firewall/NAT by a third party 169 instead of the internal host. 171 2.1.1 UDP Server behind a firewall/NAT 173 This scenario is exactly the same as the TCP server scenario, with 174 the difference that the external host issues unsolicited UDP 175 packets, instead of TCP/SYN packets. An example of this scenario is, 176 running a SIP server or a DNS server behind a NAT/Firewall. 178 2.1.2 TCP/UDP server authorized by a third party 180 This scenario differs from the base scenario in a simple way: the 181 midcom protocol is exercised by a third party instead of the host 182 itself. In the diagram, we call this third party a management 183 server: 185 __________ _________ ___________ 186 | |-----[DNS Query]-------->| | | | 187 | external |<---[DNS Response]------<| N.S. | | Management| 188 | host | |_________| | Server | 189 |__________| |___________| 190 v __________ v 191 v | |<--midcom -----/ 192 v | firewall | ___________ 193 \>>>Connection Attempt>>>>| / NAT |>>>>>>>| Internal | 194 |__________| | Host | 195 |___________| 197 The management server will interact with the firewall/NAT, using the 198 midcom protocol, as in the step 1 of the main scenario. The other 199 steps will be unchanged. A key point of this scenario is that the 200 internal host is unaware of the midcom protocol; in practical 201 deployment, the internal host can be an unmodified server, such as a 202 web server responding to HTTP requests on incoming TCP connections, 203 or a DNS server responding to name requests on incoming UDP packets. 205 As in the original scenario, the mapping request may be rejected, 206 for example if the "management server" that attempts to establish 207 the mapping is not actually authorized to do so. 209 2.2 Peer-to-peer communication with ad-hoc rendezvous 211 The mediated peer-to-peer communication scenario describes hosts 212 that communicate through some external third party, such as an 213 instant messaging service, and then establish a direct communication 214 channel, such as a TCP connection. An example of this scenario is, 216 Huitema [Page 4] 217 starting the exchange of files from an IM service. 219 __________ ___________ 220 | | | | 221 | external |<-- Messaging --> | IM Server | <-- Messaging -. 222 | host | |___________| __v________ 223 |__________| | | 224 v | internal | 225 v | host | 226 v |___________| 227 v __________ v ^ 228 v | |<--midcom -----/ ^ 229 v | firewall | ^ 230 \>>>Connection Attempt>>>>| / NAT |>>>>>>>>>>>>>>>>>>^ 231 |__________| 233 This scenario does not involve any particular cooperation between 234 the firewall/NAT and the IM server. The connection between the 235 internal host and the IM system can use any protocol, in particular 236 combinations of TCP, HTTP and TLS. 238 The scenario implies that the following operations happen in 239 sequence: 241 1) The internal and external hosts communicate through some form of 242 instant messaging service or chat room. At some point, they 243 decide to establish a direct channel, e.g. to exchange files. 245 2) The internal host interacts with the firewall/NAT, using the 246 midcom protocol. As a result of the interaction, the internal 247 host learns the IP address and TCP port that it may advertise to 248 the external host. 250 3) The internal host sends the IP address and the TCP port to the 251 external host. 253 4) The external host issues a TCP connection request, and sends a 254 TCP SYN packet. 256 5) The firewall/NAT receives the packet, performs address 257 translations and port mapping if necessary, and relays the TCP 258 SYN packet to the internal host. 260 6) After that point, the TCP connection proceeds. 262 7) After the application has finished using the connection, the 263 internal host may interact with the firewall/NAT and close the 264 hole. 266 In this scenario, the NAT firewall only has to authorize the 267 communication between a single internal host and a well identified 268 external host; the authorization typically only needs to remain 270 Huitema [Page 5] 271 valid for a single TCP connection, or in any case for a limited 272 duration. The request in step 2 may be rejected by the firewall, 273 either for policy reasons, or because there are not sufficient 274 resource available; in this case, the peers should not attempt to 275 establish a connection. As we noted in scenario 2.1.1, it is 276 important that the behavior of the firewall/NAT be consistent: if 277 the mapping request at step 2 fails, then we expect that an attempt 278 to establish a connection at step 5 will be rejected; conversely, if 279 the mapping request succeeds, then we expect the establishment of 280 TCP connection to also succeed. 282 We expect that the decision to authorize the mapping request or not 283 will depend on a variety of parameters, such as the identity of the 284 internal user, the configuration of the internal system, the 285 identity of the external peer, the purpose of the connection, and 286 the amount of resource requested for the connection. The purpose of 287 the connection may be a generic notation such as "audio" or "video", 288 or a coded description of the application. 290 There are two variants of that scenario, when the dialog occurs over 291 UDP and when both hosts are hidden behind a firewall/NAT. 293 2.2.1 Peer-to-peer communication using UDP 295 This scenario is exactly the same as the TCP scenario, with the 296 difference that the external host issues UDP packets, instead of 297 TCP/SYN packets. An example of this scenario is, streaming audio or 298 video between two peers. 300 2.2.2 Both peers behind firewalls 302 When both peers are behind firewalls, it is hard to predict the IP 303 address that will be used by the host initiating the TCP connection. 304 In this situation, there are two options: 306 1) Allow the internal host to accept TCP connections from any 307 external address. 309 2) Let the "external" host use the midcom protocol to predict the 310 "external" IP address that it will use for the incoming 311 connection. 313 The first option may look insecure, but the possible insecurity of 314 accepting connections from multiple source is often mitigated by 315 application level protections, such as security tokens exchanged 316 through the IM channel. A variation of this option is to accept 317 connections from multiple sources, but restrict the hole to exactly 318 one source once the connection has been established. As in all other 319 scenarios, the firewall will have the option to accept or refuse the 320 requested hole; it is important that the confirmation or refusal be 321 explicit, and that the behavior of the firewall be consistent, i.e. 323 Huitema [Page 6] 324 actually accept the connection if it accepted to open the hole. 326 2.3 Peer-to-peer communication with explicit signaling 328 In these scenarios, two peers that want to communicate use a 329 standard signaling protocol such as SIP or H.323. The communication 330 requests for internal host arrive to an internal server, e.g. the 331 "sip proxy" for the internal domain. In the diagram, we call this 332 agent the "internal server". The following description assumes the 333 use of SIP; scenarios that use an H.323 gatekeeper will use a 334 different message flow, but will involve similar interactions 335 between the gatekeeper and the firewall/NAT. 337 The scenarios imply that the internal server can receive signaling 338 packets from external hosts and servers. This is an application of 339 the previously described scenarios: TCP or UDP server behind a 340 firewall/NAT. 342 In these scenarios, the "internal server" has to understand the 343 location of the firewall/NAT in order to open the proper holes; this 344 may be difficult in big corporations with multiple firewalls, e.g. 345 in cases when the signaling flow will traverse a different 346 firewall/NAT than the media path. This will require some form of 347 firewall discovery; however, describing how discovery happens is 348 outside the scope of this document; the scenarios merely assume that 349 discovery somehow has happened, and that the server knows which 350 firewall/NAT will be used. 352 There are really two scenarios to consider, depending on whether the 353 call initiates from an internal host or from an external host. These 354 two scenarios assume that the firewall/NAT interacts with the 355 internal server. We will then consider a variant, in which the 356 interactions with the firewall/Nat are directly performed by the 357 internal host. 359 2.3.1 Explicit call from an internal host 361 In this scenario, an internal host calls a third party through the 362 internal server. 364 __________ _________ __________ 365 | |<--[Invite]---<| |<----------| |<--. 366 | external |---[response]->| Server |---------->| Internal |--.| 367 | host | |_________| | Server | || 368 |__________| |__________| || 369 ^v __________ v || 370 ^v | |<--midcom-/ || 371 ^v | firewall | ______v|___ 372 ^\>>> Media over UDP >>>>>>| / NAT |>>>>>>>| Internal | 373 \<<<<<<<<<<<<<<<<<<<<<<<<<<|__________|<<<<<<<| Host | 374 |___________| 376 Huitema [Page 7] 377 The scenario implies that the following operations happen in 378 sequence: 380 1) The internal host who want to start the call sends an invite 381 message to its preferred internal server. The invite message 382 carries the name of the invited user, and the IP address and UDP 383 ports through which the internal host intends to receive the 384 media, e.g. voice or video. 386 2) The internal server determines that the target of the invite is 387 located outside the internal domain. If the firewall/NAT performs 388 address and port mapping, the internal server must interact with 389 the firewall/NAT and learn the "external mappings" corresponding 390 to the IP address and UDP ports used by the internal host. 392 3) The internal server updates the address and port information in 393 the invite message, and relays the call to the "external server." 395 4) The external server determines that the target of the invite is 396 located in a specific external host. It relays the call to this 397 host. 399 5) The external host responds to the call. The response provides the 400 IP address and UDP port at which the external host will be 401 expecting to receive the media. 403 6) The response message is relayed by the external server to the 404 internal server. 406 7) The internal server receives the response. At this point, it 407 knows the IP addresses and ports used by both the internal and 408 the external host. The internal server interacts with the 409 firewall/NAT using the midcom protocol, to guarantee that the 410 exchange between the internal and external host will be 411 authorized. 413 8) The response message is relayed by the internal server to the 414 internal host. 416 9) The external and internal hosts send media packets to the 417 addresses and ports mentioned in the invite and response message; 418 these packets pass through the Firewall/NAT and reach their 419 destination. 421 We should note that, at step 2, the internal server must learn the 422 external mappings of the internal address and ports; at this stage, 423 it does no know the IP address and ports of the third party. 425 There is a potential race condition between the signaling message 426 that "responds to the call" and the first media packets sent by the 427 called party. Should the signaling loose the 429 Huitema [Page 8] 430 race, the early media packets will bang against a closed firewall 431 and be clipped. It is in theory possible to design signaling 432 exchange that include a three ways handshake before media 433 transmission can start, followed by a message asking to start 434 ringing only after the availability of all necessary resource has 435 been verified. However, this is not compatible with existing 436 implementations of SIP or H.323, and would require a serious 437 revisiting of the gatewaying between SIP or H.323 and the telephone 438 network. 440 The description assumes that the hosts use the same UDP ports in 441 both direction of the media communication. This is not necessarily 442 the case. The source IP address may be unpredictable in the case of 443 multi-homed hosts; the source port may be systematically different 444 from the receive port in some implementation, e.g. parallel 445 processing of the send and receive channels by different software or 446 hardware components. 448 The scenario does not necessarily require a strict control by the 449 firewall/NAT of the source address and port authorized to send data. 450 Many implementations already support exchange of media level 451 authentication and encryption keys during the call set-up. This 452 provides a level of security that is at least as good as any control 453 of the source address and port: if attackers can manage to read the 454 signaling exchange and get the keys, they can just as well discover 455 the IP addresses and ports, and send forged packets. 457 As any other scenario, the firewall/NAT will have the option to 458 accept or refuse the requested hole. In this scenario, we observe 459 two successive interactions between the internal server and the 460 firewall/NAT: to request a mapping at step 2, to provide the address 461 of the external peer at step 7. It is important that the behavior of 462 the firewall/NAT be consistent, and that a hole opening authorized 463 at step 2 not be refused at step 5, when more details are available. 464 If the internal server learns early that the call will be refused, 465 it can terminate it without ever trying to "ring" the external peer. 466 If a call was first authorized and later refused, then the call will 467 proceed, the peer will be ringed and will accept the call, and only 468 at that point discover that there is no way to exchange media; this 469 is obviously very undesirable. 471 2.3.2 Explicit call to an internal host 473 In this scenario, a third party host calls an internal through the 474 internal server. 476 Huitema [Page 9] 477 __________ _________ __________ 478 | |---[Invite]--->| |---------->| |---. 479 | external |<--[response]-<| Server |<----------| Internal |<-.| 480 | host | |_________| | Server | || 481 |__________| |__________| || 482 ^v __________ v || 483 ^v | |<--midcom-/ || 484 ^v | firewall | ______|v___ 485 ^\>>> Media over UDP >>>>>>| / NAT |>>>>>>>| Internal | 486 \<<<<<<<<<<<<<<<<<<<<<<<<<<|__________|<<<<<<<| Host | 487 |___________| 489 The scenario implies that the following operations happen in 490 sequence: 492 1) The external host who want to start the call sends an invite 493 message to its preferred external server. The invite message 494 carries the name of the invited user, and the IP address and UDP 495 ports through which the external host intends to receive the 496 media, e.g. voice or video. 498 2) The external server determines that the target of the invite is 499 located in the internal domain. It relays the call to the 500 "internal server." 502 3) The internal server determines that the target of the invite is 503 located in a specific internal host. It relays the call to this 504 host. 506 4) The internal host responds to the call. The response provides the 507 "internal" IP address and UDP port at which the internal host 508 will be expecting to receive the media, e.g. voice and video. 510 5) The internal server receives the host's response. At this point, 511 it knows the IP addresses and ports used by both the internal and 512 the external host. 514 6) The internal server interacts with the firewall/NAT using the 515 midcom protocol. If the firewall/NAT performs address mapping, 516 the internal server retrieves the mapping of the IP address(es) 517 and port(s) used by the internal host. 519 7) The internal server prepares an updated response message that 520 reflects the mapping of the internal addresses. It sends the 521 response message to the external server. 523 8) The response message is relayed to the external host by the 524 external server. 526 9) The external and internal hosts send media packets to the 527 addresses and ports mentioned in the invite and response message; 528 these packets pass through the Firewall/NAT and reach their 529 destination. 531 We note that in this sequence the interaction with the firewall only 532 occurs after the internal host has accepted the call. This can 533 create an annoying effect if the interaction with the firewall 534 fails, equivalent to hearing a void telephone line after picking an 535 incoming call. To avoid this effect, the internal server will have 536 to somehow guarantee that the Firewall/NAT interaction will be 537 successful before relaying the call to the internal host. A possible 538 solution is to include the request of a provisional hole of some 539 sort at step 3, before the call is relayed to the internal host; if 540 the provisional hole is refused by the firewall/NAT, the internal 541 server can refuse the call without disturbing the internal user. 543 Just like scenario 2.3.1, it may not be possible or desirable to 544 predict or check the source IP address and UDP ports used by the 545 internal and external hosts. 547 2.3.3 Firewall interaction by the internal host 549 It is possible to update the previous two scenarios so that the 550 internal host interacts directly with the Firewall/NAT, rather than 551 relying on the internal server. This set-up has the advantage of 552 avoiding the "void telephone line" effect mentioned in the previous 553 scenario: the internal host that receives the invite can pick the 554 UDP ports used for audio and video and interact with the 555 firewall/NAT before "ringing" the user; if the interaction fails, 556 the call can be rejected without bothering the user. This set-up 557 however has the disadvantage that all internal hosts must become 558 able to interact with the Firewall/NAT, which in many cases may not 559 be practical. 561 The direct interaction between the internal host and the 562 NAT/Firewall is already described in the "peer-to-peer" scenarios of 563 the previous section. The only difference between these scenarios is 564 the possibility for the internal server to pass some form of 565 "authorization token" to the internal host. 567 2.3.4 Early media 569 The "early media" scenario is an important variations of the 570 scenario 2.3.1. Early media designates media transmission sent 571 before the actual completion of the call. Examples are ringing tones 572 and voice messages describing particular network conditions, such as 573 "we are trying to locate your correspondent." In the early media 574 scenario, the following interactions will happen in sequence: 576 1) The internal host who want to start the call sends an invite 577 message to its preferred internal server, as in 2.3.1, 579 2) The internal server determines that the target of the invite is 580 located outside the internal domain. If the firewall/NAT performs 581 address and port mapping, the internal server must interact with 582 the firewall/NAT and learn the "external mappings" corresponding 583 to the IP address and UDP ports used by the internal host, as in 584 2.3.1. In addition, the internal server requests the 585 authorization to receive packets from a yet unspecified external 586 source. 588 3) The internal server updates the address and port information in 589 the invite message, and relays the call to the "external server." 591 4) The external server, or a secondary server acting on its behalf, 592 sends a stream of voice packets towards the "external mappings" 593 of the IP address and UDP ports used by the internal host, 595 5) The firewall/NAT receives these packets and forwards them to the 596 internal host, 598 6) The call proceeds as in 2.3.1. 600 There is a common telephony practice of sending recorded 601 announcements during call set-up; the source IP address of these 602 announcements is not likely to be the same as the source IP address 603 used after call set-up is complete. It is theoretically possible 604 to use the equivalent of call transfer to switch between multiple 605 source in a controlled fashion, but this introduce a lot of 606 signaling complexity, and is incompatible with currently deployed 607 hardware and software. In practice, this scenario requires that the 608 firewall/NAT "opens a hole" without knowing the IP address and port 609 of the external peer. 611 2.3.5 Mobility of the external host 613 The mobility scenario can be thought as a complication of scenarios 614 2.3.1 or 2.3.2, in which the IP address of one of the peers is 615 allowed to change during a call, due to either mobility or network 616 renumbering. The scenario involves the following exchanges: 618 1) The external host receives a new IP address, and sends a 619 signaling packet to the "internal server" mentioning the new IP 620 address, 622 2) The internal server programs the firewall/NAT to start 623 authorizing packets between this new address and the internal 624 host, 626 3) In parallel with 2, the internal server relays the signaling 627 message to the internal host, 629 4) The internal and external hosts exchange packets with the new 630 address; the firewall/NAT authorizes these packets to proceed. 632 SIP supports that through the re-invite mechanism, but we should 633 note that there is either a gap in the call or a race condition 634 between media packets with the new source address and the signaling 635 message. The external host is likely to source packets with its new 636 address immediately after the address change; if the packets arrive 637 before the firewall/NAT has been programmed to accept them, the 638 packets will bang against the closed firewall/NAT and be dropped. 640 2.3.6 Multiple ports, port ranges 642 The SIP messages use the encoding defined in SDP [RFC2237] to 643 describe the IP addresses and TCP or UDP ports used my the various 644 media. In many cases, a single media stream will be spread over 645 multiple ports. SDP carries only one port number per media, and 646 states that "other ports used by the media application (such as the 647 RTCP port) should be derived algorithmically from the base media 648 port." When the media is transmitted using RTP [RFC1889], the choice 649 of the port number is very specific: "for UDP and similar protocols, 650 RTP uses an even port number and the corresponding RTCP stream uses 651 the next higher (odd) port number; if an application is supplied 652 with an odd number for use as the RTP port, it should replace this 653 number with the next lower (even) number." This obviously poses a 654 constraint to the allocation of ports and mappings by a NAT. 656 Most media streams are transmitted using a single pair of RTP and 657 RTCP ports. It is possible however to transmit a single media over 658 several RTP flows, for example using hierarchical encoding. In this 659 case, SDP will encode the port number used by RTP on the first flow, 660 and the number of flows, as in: 662 m=video 49170/2 RTP/AVP 31 664 In this example, the media is sent over 2 consecutive pairs of 665 ports, corresponding respectively to RTP for the first flow (even 666 number, 49170), RTCP for the first flow (odd number, 49171), RTP for 667 the second flow (even number, 49172), and RTCP for the second flow 668 (odd number, 49173). This places a further constraint to any NAT 669 firewall traversal scheme: we must be able to ensure that a 670 consecutive range of N ports starting with an even number is mapped 671 to another consecutive range of N ports, also starting with an even 672 number. 674 2.4 IPv6 Scenarios 676 All of the scenarios mentioned above can be modified if the domains 677 have been upgraded to run IPv6. One difference between the IPv6 and 678 IPv4 scenarios is that the internal hosts can use global addresses; 679 however, there will also be cases in which address translation is 680 required after the introduction of IPv6, notably if one provides 681 interoperation between IPv6 and IPv4 using the NAT-PT scheme 682 [RFC2766]. When any form of address translation is required, e.g. 683 between IPv6 and IPv4 addresses, the scenarios are basically 684 unchanged; what may change is the content of the MIDCOM protocol 685 messages, which will have to include a mix of IPv4 and IPv6 686 addresses. On the other hand, when only global addresses are used in 687 the exchanges, the scenario are modified; the "middle box" does not 688 necessarily disappears, since in many domains there will still be 689 the need to perform explicit authorizations before letting data go 690 in and out; in these cases the "Firewall/NAT" combination becomes 691 strictly a "Firewall". In this section, we review how the 692 introduction of IPv6 and the use of global addresses can affect the 693 three classes of scenarios mentioned in the previous sections. 695 The transition to IPv6 will require the introduction of relay 696 routers, as specified in [RFC3056]; we discuss here how the MIDCOM 697 protocol can be used to open holes for the "tunnels" leading to 698 these relay routers. 700 In addition, the global addressing allows the introduction of 701 another scenario, the use of IPSEC between an internal and an 702 external host. 704 2.4.1 IPv6 TCP or UDP server behind a firewall 706 In this scenario, the internal host publishes the IP address and TCP 707 port number at which it can be joined in a name server, using for 708 example SRV and A6 records in the DNS. The sequence of operation is 709 the same as in the IPv4 case, but each of the step has a different 710 emphasis: 712 1) The internal host interacts with the firewall, using the midcom 713 protocol. As a result of the interaction, the firewall learns the 714 IP address and TCP port that the host will use. 716 2) The internal host publishes the information in a name server. 718 3) The external host obtains the information from the name server. 720 4) The external host issues a TCP connection request, and sends a 721 TCP SYN packet. 723 5) The firewall receives the packet, checks that the destination 724 address and port are authorized, and relays the TCP SYN packet to 725 the internal host. 727 6) After that point, the TCP connection proceeds. 729 The only reason for the first step in the scenario is access 730 control. If the domain's policy is to authorize all hosts to receive 731 all traffic, there is no need for this step - indeed, the firewall 732 becomes mostly a transparent IPv6 router. The impact of IPv6 on the 733 two variants of that scenario is obvious: the use of UDP will have 734 to be authorized if needed, and there may be a need to let a third 735 party perform the authorizations. 737 2.4.2 Peer-to-peer communication with ad-hoc rendezvous and IPv6 739 If both peers have a global IPv6 address, they will only have to 740 interact with a firewall if the domain's manager insists on having a 741 firewall control all incoming traffic; there will not be a need for 742 a NAT functionality. The internal host may still need to interact 743 with the firewall in order to "open a hole" for the packets coming 744 from the remote peer, but it will always be able to specify the 745 complete "five tuple" of protocol type, IP addresses and UDP ports; 746 the problem exposed in the case when both hosts were being firewalls 747 disappears. 749 2.4.3 Peer-to-peer communication with explicit signaling and IPv6 751 This scenario is also made simpler by the availability of global 752 addresses. In the case of a call from an internal host, the internal 753 server will not have to rewrite the addresses in the outgoing 754 "invite"; it will only have to interact with the firewall to open a 755 hole after the reception of the response. In the case of a call to 756 an internal host, the internal server may still have to interact 757 with a firewall if the domain managers insist on requiring this type 758 of protection; it will do so with an explicit knowledge of the IPv6 759 addresses and UDP ports used by both ends of the connection. 761 2.4.4 IPv6 transition service behind a firewall/NAT 763 A typical IPv6 transition scenario is described in [RFC3056]. In 764 this scenario, IPv6 is progressively made available by installing in 765 each site a "6to4" router, which receives IPv6 packets through 766 automatic tunnels and forwards them to internal IPv6 hosts. 768 __________ _________ 769 | |-----[DNS Query]--->| | ___________ 770 | external |<---[DNS Response]-<| N.S. | | | 771 | host | |_________| | 6to4 | 772 |__________| | Router | 773 ^ |___________| 774 | __________ v ^ ^ 775 | | |<--midcom -/ | | 776 | | firewall | | \-> 777 \--- IPv6/IPv4 -->| / NAT |<-- IPv6/IPv4 -/ IPv6 778 |__________| 780 In this scenario, the 6to4 router provides the internal IPv6 hosts 781 with IPv6 addresses; the IPv6 prefix in these addresses is based on 782 a "global" IPv4 address of the domain. The IPv6 hosts will publish 783 their IPv6 addresses in the DNS. The external hosts will send IPv6 784 packets encapsulated in IPv4 headers, whose destination will be the 785 internal 6to4 router; the 6to4 router will receive the packets sent 786 by internal hosts to external hosts, and will encapsulate them with 787 adequate IPv4 headers. 789 The scenario implies that the following operations happen in 790 sequence: 792 1) The 6to4 router interacts with the firewall/NAT, using the midcom 793 protocol. As a result of the interaction, the 6to4 router learns 794 a global IPv4 address that it can use to build a 6to4 prefix. 796 2) The internal hosts publish IPv6 addresses based on this prefix in 797 a name server. 799 3) The external host obtains the information from the name server. 801 4) The external host sends IPv6 packets towards this address. 803 5) The firewall/NAT receives the packet, notes that these are IPv6 804 packets carried in IPv4 (protocol type = 41), translates the 805 destination address if necessary and relays the packet to the 806 6to4 router. 808 6) The 6to4 router removes the IPv4 header and forwards the IPv6 809 packet to the internal host. 811 7) When the 6to4 router receives an IPv6 packet, it determines the 812 adequate IPv4 destination, and uses it to build an encapsulation 813 IPv4 header. 815 8) The firewall/NAT receives the encapsulated packet. It may perform 816 translation of the source address if needed. It forwards the 817 packet to the IPv4 destination. 819 In the diagram, we depict only one external host, but this is an 820 example, not a limitation. 822 It is quite clear that, if fire walling function are desired for the 823 IPv6 traffic, these functions will have to be provided by the 6to4 824 router. 826 2.4.5 Enabling an IPSEC connection between IPv6 hosts 828 Once IPv6 provides global addresses to internal hosts, it becomes 829 possible to establish IPSEC associations between an internal host 830 and an external host. The establishment of the association will 831 start by a key exchange, and will continue with the exchange of 832 encrypted traffic. 834 __________ 835 | | 836 | external | 837 | host | ___________ 838 |__________| | | 839 ^ | internal | 840 | | host | 841 | |___________| 842 | __________ v ^ 843 | | |<--midcom -----/ | 844 \-- Key exchange, IPSEC ->| firewall |<-----------------/ 845 |__________| 847 The scenario implies that the following operations happen in 848 sequence: 850 1) The internal and external hosts decide to communicate, e.g. after 851 the internal host finds the address of the external host in the 852 DNS. 854 2) The internal host and the external host exchange key negotiation 855 packets (IKE). The firewall passes these packets. 857 3) The internal host uses the midcom protocol to signal to the 858 firewall that it is going to exchange encrypted traffic with an 859 external host, and obtains the authorization to proceed. 861 4) IPSEC packets are exchanged. 863 5) After the hosts have finished using the IPSEC association, the 864 internal host may interact with the firewall and close the hole. 866 We should note that this scenario requires that the firewall 867 delegates some of its control functions to the internal host: 868 encrypted traffic cannot be inspected. 870 As in all other scenarios, the firewall will have to explicitly 871 authorize the opening of a hole for the IPSEC association. 873 3 Security Considerations 875 Firewalls are used by domain managers to control the traffic that 876 can be exchanged between their domain and the Internet. In the 877 scenarios that we described, this control is relaxed in order to 878 enable certain applications. Relaxing the control has to be a 879 conscious decision of the domain manager. 881 4 IANA Considerations 883 The purpose of this memo is to document the allocation by IANA of an 884 IPv4 prefix dedicated to the 6to4 gateways to the native v6 885 Internet; there is no need for any recurring assignment. 887 5 Copyright 889 The following copyright notice is copied from RFC 2026 [Bradner, 890 1996], Section 10.4, and describes the applicable copyright for this 891 document. 893 Copyright (C) The Internet Society March 23, 2001. All Rights 894 Reserved. 896 This document and translations of it may be copied and furnished to 897 others, and derivative works that comment on or otherwise explain it 898 or assist in its implementation may be prepared, copied, published 899 and distributed, in whole or in part, without restriction of any 900 kind, provided that the above copyright notice and this paragraph 901 are included on all such copies and derivative works. However, this 902 document itself may not be modified in any way, such as by removing 903 the copyright notice or references to the Internet Society or other 904 Internet organizations, except as needed for the purpose of 905 developing Internet standards in which case the procedures for 906 copyrights defined in the Internet Standards process must be 907 followed, or as required to translate it into languages other than 908 English. 910 The limited permissions granted above are perpetual and will not be 911 revoked by the Internet Society or its successors or assignees. 913 This document and the information contained herein is provided on an 914 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 915 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 916 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 917 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 918 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 920 6 Intellectual Property 922 The following notice is copied from RFC 2026 [Bradner, 1996], 923 Section 10.4, and describes the position of the IETF concerning 924 intellectual property claims made against this document. 926 The IETF takes no position regarding the validity or scope of any 927 intellectual property or other rights that might be claimed to 928 pertain to the implementation or use other technology described in 929 this document or the extent to which any license under such rights 930 might or might not be available; neither does it represent that it 931 has made any effort to identify any such rights. Information on the 932 IETF's procedures with respect to rights in standards-track and 933 standards-related documentation can be found in BCP-11. Copies of 934 claims of rights made available for publication and any assurances 935 of licenses to be made available, or the result of an attempt made 936 to obtain a general license or permission for the use of such 937 proprietary rights by implementers or users of this specification 938 can be obtained from the IETF Secretariat. 940 The IETF invites any interested party to bring to its attention any 941 copyrights, patents or patent applications, or other proprietary 942 rights which may cover technology that may be required to practice 943 this standard. Please address the information to the IETF Executive 944 Director. 946 7 Acknowledgements 948 The discussion presented here was triggered by the meeting of the 949 MIDCOM working group in Minneapolis. An initial description of the 950 "TCP server" scenario was sent to the group's e-mail list by Eliot 951 Lear. 953 8 References 955 [RFC3056] B. Carpenter, K. Moore. "Connection of IPv6 Domains via 956 IPv4 Clouds." RFC 3056, February 2001. 958 [RFC2237] M. Handley, V. Jacobson, "SDP: Session Description 959 Protocol", RFC 2327, April 1998. 961 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: 962 A Transport Protocol for Real-Time Applications", RFC 1889, January 963 1996. 965 [RFC2766] G. Tsirtsis, P. Srisuresh. "Network Address Translation - 966 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 968 [MIDBOXFRAME] Middlebox Communication Architecture and Framework. 969 Work in progress. 971 9 Author's Address 973 Christian Huitema 974 Microsoft Corporation 975 One Microsoft Way 976 Redmond, WA 98052-6399 978 Email: huitema@microsoft.com