idnits 2.17.1 draft-ietf-mmusic-ice-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 17 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 371: '...ost. A multi-homed host SHOULD attempt...' RFC 2119 keyword, line 384: '...s, the initiator SHOULD obtain an addr...' RFC 2119 keyword, line 409: '... the server SHOULD reject any reques...' RFC 2119 keyword, line 438: '... client MUST choose a username and p...' RFC 2119 keyword, line 465: '...r is started, it MUST run until the fi...' (41 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2004) is 7368 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3489 (ref. '1') (Obsoleted by RFC 5389) -- Possible downref: Normative reference to a draft: ref. '3' -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '5') (Obsoleted by RFC 7826) == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-05 == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-03 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: August 16, 2004 February 16, 2004 6 Interactive Connectivity Establishment (ICE): A Methodology for 7 Network Address Translator (NAT) Traversal for Multimedia Session 8 Establishment Protocols 9 draft-ietf-mmusic-ice-01 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 16, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes a methodology for Network Address Translator 40 (NAT) traversal for multimedia session signaling protocols, such as 41 the Session Initiation Protocol (SIP). This methodology is called 42 Interactive Connectivity Establishment (ICE). ICE is not a new 43 protocol, but rather makes use of existing protocols, such as Simple 44 Traversal of UDP Through NAT (STUN), Traversal Using Relay NAT (TURN) 45 and even Real Specific IP (RSIP). ICE works through the mutual 46 cooperation of both endpoints in a session. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Multimedia Signaling Protocol Abstraction . . . . . . . . . 4 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . 8 54 5. Detailed ICE Algorithm . . . . . . . . . . . . . . . . . . . 10 55 5.1 Gathering Transport Addresses . . . . . . . . . . . . . . . 10 56 5.2 Enabling STUN on Each Transport Address . . . . . . . . . . 10 57 5.3 Prioritizing the Transport Addresses . . . . . . . . . . . . 12 58 5.4 Constructing the Initiate Message . . . . . . . . . . . . . 13 59 5.5 Responder Processing - Connectivity Checks and Gathering . . 13 60 5.6 Generating the Accept Message . . . . . . . . . . . . . . . 16 61 5.7 Initiator Processing of the Accept . . . . . . . . . . . . . 17 62 5.8 Additional ICE Cycles . . . . . . . . . . . . . . . . . . . 17 63 6. Running STUN on Derived Transport Addresses . . . . . . . . 19 64 6.1 STUN on a TURN Derived Transport Address . . . . . . . . . . 19 65 6.2 STUN on a STUN Derived Transport Address . . . . . . . . . . 20 66 7. XML Schema for ICE Messages . . . . . . . . . . . . . . . . 22 67 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 68 9. Mapping ICE into SIP . . . . . . . . . . . . . . . . . . . . 25 69 10. Security Considerations . . . . . . . . . . . . . . . . . . 27 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 71 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 29 72 12.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . 29 73 12.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . 29 74 12.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . . 30 75 12.4 Requirements for a Long Term Solution . . . . . . . . . . . 31 76 12.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . . 31 77 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 78 Normative References . . . . . . . . . . . . . . . . . . . . 33 79 Informative References . . . . . . . . . . . . . . . . . . . 34 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . 35 81 Intellectual Property and Copyright Statements . . . . . . . 36 83 1. Introduction 85 A multimedia session signaling protocol is a protocol that exchanges 86 messages between a pair of agents for the purposes of establishing 87 the flow of media traffic between them. This media flow is distinct 88 from the flow of control messages, and may take a different path 89 through the network. Examples of such protocols are the Session 90 Initiation Protocol (SIP) [4], the Real Time Streaming Protocol 91 (RTSP) [5] and ITU H.323. 93 These protocols, by nature of their design, are difficult to operate 94 through Network Address Translation (NAT). Because their purpose in 95 life is to establish a flow of packets, they tend to carry IP 96 addresses within their messages, which is known to be problematic 97 through NAT [6]. The protocols also aim for peer to peer media flow, 98 in order to reduce latency, which is also difficult to accomplish 99 through NAT. Many other aspects of these protocols are fundamentally 100 incompatible with NAT. A full treatment of the reasons for this is 101 beyond the scope of this specification. 103 Numerous solutions have been proposed for allowing these protocols to 104 operate through NAT. These include Application Layer Gateways (ALGs), 105 the Middlebox Control Protocol [7], Simple Traversal of UDP through 106 NAT (STUN) [1], Traversal Using Relay NAT [14], Realm Specific IP 107 [8][9], symmetric RTP [10], along with session description extensions 108 needed to make them work, such as [2]. Unfortunately, these 109 techniques all have pros and cons which make each one optimal in some 110 network topologies, but a poor choice in others. The result is that 111 administrators and implementors are making assumptions about the 112 topologies of the networks in which their solutions will be deployed. 113 This introduces a lot of complexity and brittleness into the system. 114 What is needed is a single solution which is flexible enough to work 115 well in all situations. 117 This specification provides that solution. It is called Interactive 118 Connectivity Establishment, or ICE. ICE makes use of many of the 119 protocols above, but uses them in a specific methodology which avoids 120 many of the pitfalls of using any one alone. ICE is not a new 121 protocol, and does not require extensions from STUN, TURN or RSIP. 122 However, it does require additional signaling capabilities to be 123 introduced into the multimedia session signaling protocols. For those 124 protocols which make use of the Session Description Protocol (SDP), 125 this specification defines the necessary extensions to it. Other 126 protocols will need to define their own mechanisms. 128 2. Multimedia Signaling Protocol Abstraction 130 This specification defines a general methodology that allows the 131 media streams of multimedia signaling protocols to successfully 132 traverse NAT. This methodology is independent of any particular 133 signaling protocol. In order to discuss the methodology, we need to 134 to define an abstraction of a multimedia signaling system, and define 135 terms that can be used throughout this specification. Figure 1 shows 136 the abstraction. 138 +-----------+ 139 | | 140 | | 141 > | Signaling |\ 142 / | Relay | \ 143 / | | \ 144 Initiate / | | \ Initiate 145 Message / / +-----------+ \ Message 146 / / < \ 147 / / \ \ 148 / / \ \ 149 / / Accept Accept \ \ 150 / / Message Message \ > 151 / / \ 152 +-----------+ / \ +-----------+ 153 | | < | | 154 | | Media Stream | | 155 | Session | ................................ | Session | 156 | Initiator | | Responder | 157 | | Media Stream | | 158 | | ................................ | | 159 +-----------+ +-----------+ 161 Figure 1 163 Communications occur between two clients - the session initiator and 164 the session responder, also referred to as the initiator and 165 responder. The initiator is the one that decides to engage in 166 communications. To do so, it sends an initiate message. The initiate 167 message contains parameters that describe the capabilities and 168 configuration of media streams for the initiator. This message may 169 travel through signaling intermediaries, called a signaling relay, 170 before finally arriving at the session responder. Assuming the 171 session responder wishes to communication, it generates an accept 172 message, which is relayed back to the initiator. This message 173 contains capabilities and configuration of media streams for the 174 responder. As a result, media streams are established between the 175 initiator and responder. The signaling protocol may also support an 176 operation that allows for modification of the media stream parameters 177 after establishment. We refer to this signaling messages as a modify 178 message. Its positive response is a modify acceptance message. The 179 signaling protocol may also support an operation that allows for 180 termination of the communications session. We refer to this signaling 181 message as a terminate message. 183 This abstraction is readily mapped to SIP, RTSP, and H.323, amongst 184 others. For SIP, the initiator is the User Agent Client (UAC), the 185 responder is the User Agent Server (UAS), the initiate message is an 186 INVITE containing an SDP offer, the accept message is a 200 OK 187 containing an SDP answer, the modify message is an INVITE with an 188 offer, the modify acceptance response is a 200 OK with an answer, and 189 the terminate message is a BYE. For RTSP, the initiator is the RTSP 190 client, the responder is the RTSP server, the initiate message is a 191 SETUP message, and the accept message is a SETUP response. The modify 192 message is a SETUP message, and the modify acceptance message is a 193 SETUP response. 195 This specification defines parameters that need to be included in 196 these various signaling messages in order to implement the 197 functionality described by ICE. Those parameters are represented in 198 XML for convenience. Any multimedia signaling protocol that uses ICE 199 will need to define how to map those parameters into its own protocol 200 messages. Section 9 provides such a mapping for SIP. 202 3. Terminology 204 Several new terms are introduced in this specification: 206 Session Initiator: A software entity that, at the request of a user, 207 tries to establish communications with another entity, called the 208 session responder. A session initiator is also called an 209 initiator. 211 Initiator: Another term for a session initiator. 213 Session Responder: A software entity that receives a request for 214 establishment of communications from the session initiator, and 215 either accepts or declines the request. A session responder is 216 also called a responder. 218 Responder: Another term for a session responder. 220 Client: Either the initiator or responder. 222 Peer: From the perspective of one of the clients in a session, its 223 peer is the other client. Specifically, from the perspective of 224 the initiator, the peer is the responder. From the perspective of 225 the responder, the peer is the initiator. 227 Signaling Relay: An intermediary of signaling messages. Examples are 228 SIP proxies and H.323 Gatekeepers. 230 Initiate Message: The signaling message used by an initiator to 231 establish communications. It contains capabilities and other 232 information needed by the responder to send media to the 233 initiator. 235 Accept Message: The signaling message used by a responder to agree to 236 communications. It contains capabilities and other information 237 needed by the initiator to send media to the responder. 239 Modify Message: The signaling message used by either an initiator or 240 responder to change the capability and other information needed by 241 the peer for sending media. 243 Modify Acceptance Message The signaling message used by a client to 244 agree to the changes proposed in a modify message, and to present 245 the capability or other information needed by its peer for sending 246 media. 248 Terminate Message The signaling message used by a client to terminate 249 the session and associated media streams. 251 Transport Address: The combination of an IP address and port. 253 Local Transport Address: A local transport address is transport 254 address that has been allocated from the operating system on the 255 host. This includes transport addresses obtained through VPNs, and 256 also transport addresses obtained through RSIP (which lives at the 257 operating system level). Transport addresses are typically 258 obtained by binding to an interface. 260 Derived Transport Address: A derived transport address is a transport 261 address which is associated with, but different from, a local 262 transport address. The derived transport address is associated 263 with the local transport address in that packets sent to the 264 derived transport address are received on the socket bound to that 265 local transport address. Derived addresses are obtained using 266 protocols like STUN and TURN, and more generally, any UNSAF 267 protocol [11]. 269 Peer Derived Transport Address: A peer derived transport address is a 270 derived transport address learned from a STUN server advertised by 271 a peer in a media session. 273 TURN Derived Transport Address: A derived transport address obtained 274 from a TURN server. 276 STUN Derived Transport Address: A derived transport address obtained 277 from a STUN server whose address has been provisioned into the UA. 278 This, by definition, excludes Peer Derived Transport Addresses. 280 Unilateral Allocations: Queries made to a network server which 281 provides an UNSAF service. 283 Bilateral Allocations: Addresses obtained by using an UNSAF service 284 that actually runs on the peer of the communications session. Peer 285 derived transport addresses are synonymous with bilateral 286 allocations. 288 4. Overview of ICE 290 ICE makes the fundamental assumption that clients exist in a network 291 of segmented connectivity. This segmentation is the result of a 292 number of addressing realms in which a client can simultaneously be 293 connected. We use "realms" here in the broadest sense. A realm is 294 defined purely by connectivity. Two clients are in the same realm if, 295 when they exchange the addresses each has in that realm, they are 296 able to send packets to each other. This includes IPv6 and IPv4 297 realms, which actually use different address spaces, in addition to 298 private networks connected to the public Internet through NAT. 300 The key assumption in ICE is that a client cannot know, apriori, 301 whether the peer it wishes to communicate with is connected to one or 302 all of the address realms it is in. Therefore, in order to 303 communicate, it has to try them all, and choose the best one that 304 works. 306 Before the initiator establishes a session, it obtains as many IP 307 address and port combinations in as many address realms as it can. 308 These adresses all represent potential points at which the initiator 309 will receive a specific media stream. Any protocol that provides a 310 client with an IP address and port on which it can receive traffic 311 can be used. These include STUN, TURN, RSIP, and even a VPN. The 312 client also uses any local interface addresses. A dual-stack v4/v6 313 client will obtain both a v6 and a v4 address/port. The only 314 requirement is that, across all of these addresses, the initiator can 315 be certain that at least one of them will work for any responder it 316 might communicate with. This is easily guaranteed by using TURN, 317 RSIP, MIDCOM or a VPN from a server on the public Internet to obtain 318 one of the addresses. 320 The initiator then makes a STUN server available on each of the 321 address/port combinations it has obtained. This STUN server is 322 running locally, on the initiator. All of these addresses are placed 323 into the initiate message, and they are ordered in terms of 324 preference. Local IPv6 addresses always have the highest preference, 325 followed by local IPv4 addresses, followed by STUN-allocated 326 addresses, followed last by addresses allocated through protocols 327 using relays, such as TURN and VPN. The initiate message also conveys 328 the STUN username and password which are required to gain access to 329 the STUN server on each address/port combination. 331 The initiate message is sent to the responder. This specification 332 does not address the issue of how the signaling messages themselves 333 traverse NAT. It is assumed that signaling protocol specific 334 mechanisms are used for that purpose. Once the responder receives the 335 initiate message, it sends STUN requests to each alternate address/ 336 port in the initiate message. These STUN requests include the 337 username and password obtained from the initiate message. None of the 338 STUN flags are used. The STUN requests serve two purposes. The first 339 is to check for connectivity. If a response is received, the 340 responder knows that it can reach the initiator at that address. The 341 second purpose is to obtain more addresses at which the responder can 342 be contacted. If there were NATs between the responder and initiator, 343 the responder may discover another address through the STUN 344 responses. In its accept message, the responder includes all 345 addresses that it can unilaterally determine (just as the initiator 346 did), in addition to any that were discovered using the STUN messages 347 to the initiator. 349 When the accept message arrives at the initiator, the initiator 350 performs a similar operation. Using STUN, it checks connectivity to 351 each of the addresses in the accept message. Through the STUN 352 responses, it may learn of additional addresses that it can use to 353 receive media. It can therefore generate a modify message to pass 354 this address to the responder. Generally, at the end of the first 355 exchange, both sides will have discovered one of more addresses which 356 they are capable of successfully sending media to. Each side uses the 357 most preferred address amongst the ones which worked. 359 In some cases, an additional exchange will be required. 361 5. Detailed ICE Algorithm 363 This section describes the detailed processing needed for ICE. 365 5.1 Gathering Transport Addresses 367 The initiator begins the process by gathering transport addresses. 368 There are two types of addresses it can gather - local transport 369 addresses, and derived transport addresses. Local transport addresses 370 are obtained by binding to an ephemeral port on an interface 371 (physical or virtual) on the host. A multi-homed host SHOULD attempt 372 to bind on all interfaces for all media streams it wishes to receive. 373 For media streams carried using the Real Time Transport Protocol 374 (RTP) [12], the initiator will need to bind to an ephemeral port for 375 both RTP and RTCP. 377 The result will be a set of local transport addresses. The initiator 378 may also have access to servers that provide unilateral self-address 379 fixing (UNSAF) [11]. Examples of such protocols include STUN, TURN, 380 and TEREDO [13]. For each of these protocols, the initiator may have 381 access to a multiplicity of servers. For example, a user connected to 382 a natted cable access network might have access to a STUN server in 383 the private cable network and in the public Internet. For each local 384 transport address, the initiator SHOULD obtain an address from every 385 server for each protocol it supports. The result of this will be a 386 set of derived transport addresses, with each derived address 387 associated with the local transport address it is derived from. 389 ICE works better the more options exist for connectivity. However, in 390 order to communicate with the peer, at least one of the offered 391 addresses has to be guaranteed to work with any peer that might be 392 called. This generally requires that at least one of the derived 393 addresses be obtained from a relay service (such as TURN) that exist 394 within the public Internet. ICE requires that a client know, through 395 configuration, which of the derived transport addresses is coming 396 from a provider on the public Internet. 398 5.2 Enabling STUN on Each Transport Address 400 Once the initiator has obtained a set of transport addresses, it 401 starts a STUN server on each local transport address (including ones 402 used for RTCP). This, by definition, means that the STUN service will 403 be reached for requests sent to the derived addresses. 405 However, the client does not need to provide STUN service on any 406 other IP address or port, unlike the normal STUN usage as described 407 in [1]. The need to run the service on multiple ports is to support 408 the change flags. However, those flags are not needed with ICE, and 409 the server SHOULD reject any requests with these flags set. 411 Furthermore, there is no need to support TLS or to be prepared to 412 receive SharedSecret request messages. Those messages are used to 413 obtain shared secrets to be used with BindingRequests. However, with 414 ICE, usernames and passwords are exchanged in the signaling protocol. 416 It is important to note that the client will receive both STUN 417 requests and media packets on each local transport address. This will 418 require the initiator to disambiguate STUN messages from messages for 419 the underlying media stream protocol. In the case of RTP/RTCP, this 420 disambiguation is easy. RTP and RTCP packets start with the bits 0b10 421 (v=2). The first two bits in STUN are always 0b00. Disambiguating 422 STUN with other media stream protocols may be more complicated. 423 However, it is guaranteed to always be possible by selecting an 424 appropriately random username (see below). 426 The need to run STUN on the same transport address as the media 427 stream represents the "ugliest" piece of ICE. However, it is an 428 essential part of the story. By sending STUN requests to the very 429 same place media is sent, any bindings learned through STUN will be 430 useful even when communicating through symmetric NATs. This results 431 in a substantial increase in the scope of applicability of STUN, in 432 terms of cases where it can provide connectivity. In that sense, the 433 usage of STUN here is radically different than the usage models 434 outlined in [1], where STUN is generally useless for dealing with 435 symmetric NAT. 437 For each local transport address where a STUN server is running, the 438 client MUST choose a username and password. The username MUST be 439 globally unique, so that no other host will select a username with 440 the same value. This username and password will be passed to the 441 responder in the initiate message. They are used by the responder to 442 authenticate the STUN requests to the server. 444 The global uniqueness requirement stems from the lack of uniquenes 445 afforded by IP addresses. Consider clients A, B, and C. A and B are 446 within private enterprise 1, which is using 10.0.0.0/8. C is within 447 private enterprise 2, which is also using 10.0.0.0/8. As it turns 448 out, B and C both have IP address 10.0.1.1. A initiates 449 communications to C. C, in its accept message, provides A with its 450 transport addresses. In this case, thats 10.0.1.1:8866 and 8877. As 451 it turns out, B is in a session at that same time, and is also using 452 10.0.1.1:8866 and 8877. This means that B has a STUN server running 453 on those ports, just as C does. A will send a STUN request to 454 10.0.1.1:8866 and 8877. However, these do not go to C as expected. 455 Instead, they go to B. If B just replied to them, A would believe it 456 has connectivity to C, when in fact it has connectivity to a 457 completely different user, B. To fix this, the STUN username takes on 458 the role of a unique identifier. C provides A with a unique username. 459 A uses this username in its STUN query to 10.0.1.1:8866. This STUN 460 query arrives at B. However, the username is unknown to B, and so the 461 request is rejected. A treats the rejected STUN request as if there 462 were no connectivity to C (which is actually true). Therefore, the 463 error is avoided. 465 Once the STUN server is started, it MUST run until the first media 466 packet arrives on that address. Once that occurs, the agent MAY 467 terminate the server. It is still possible that a late or lost STUN 468 message will show up, but these will generally fail any media stream 469 validity checks and be discarded (STUN packets always fail the RTP 470 validity checks). 472 While the server is running, it MUST act as a normal STUN server, but 473 MUST only accept STUN requests from clients that authenticate using 474 the username and password handed out for the dialog. 476 5.3 Prioritizing the Transport Addresses 478 With the STUN servers starting, the next step is to prioritize the 479 transport addresses. This priority reflects the desire that the UA 480 has to receive media on that address, and is assigned as a value from 481 0 to 1 (1 being most preferred). Although any prioritization is 482 possible, it is RECOMMENDED that the prioritization be based on the 483 number of intermediaries that will be traversed. The fewer 484 intermediaries, the higher the priority. Furthermore, it is 485 RECOMMENDED that, given an equal number of intermediaries, an IPv6 486 address receive higher priority than an IPv4 address. As a result of 487 this, local IPv6 transport addresses obtained from physical 488 interfaces have highest priority. Next are local IPv4 transport 489 addresses obtained from physical interfaces. Next are STUN derived 490 transport addresses, followed by TURN, RSIP or TEREDO derived 491 transport addresses. Peer derived transport addresses obtained 492 through STUN requests sent through a TURN relay using the SEND 493 command have a priority equal to TURN derived transport addresses. 494 Last up are local transport addresses obtained from VPN interfaces. 496 Ordering of transport addresses within any one of the groups above 497 (i.e., addresses obtained from relay services, such as TURN or RSIP), 498 is more complicated. When a device is configured to use a 499 multiplicity of these relays, each from the same provider, it is 500 RECOMMENDED that the client be configured with the relative 501 preference for each. This is useful, for example, in enterprises with 502 multiple layers of NAT, each of which hosts a relay. In such a case, 503 the preference for each relay would normally decrease as the relays 504 move farther away from the client. 506 5.4 Constructing the Initiate Message 508 The next step is to construct the initiate message. Section 7 509 provides the XML schema for the initiate message. The message 510 consists of a series of media streams. For each media stream, there 511 is a default address and a list of alternates. The default address is 512 the one that will be used by responders that don't understand ICE. 513 This is mapped to the address currently conveyed in the signaling 514 messages of SIP, H.323 and RTSP. The alternates provide additional 515 points of contact. 517 For each media stream, the client chooses the transport address which 518 has the highest probability of working with any arbitrary peer. 519 Generally, this will be a transport address learned from a relay 520 service on the public Internet, such as TURN. Frequently this is also 521 the lowest priority transport address. This transport address is 522 placed into default address in the initiate message. This is the 523 address that will be used by a peer that doesn't understand ICE. 524 Therefore, to maximize the ability to complete a call, the address 525 which is most likely to succeed is used. 527 The client then encodes all of its available transport addresses 528 (including the one that was set as the default) as a series of 529 alternate elements. Each alternate element conveys a transport 530 address for RTP, one for RTCP, the STUN username and STUN password. 531 The client MUST assign each alternate a unique identifier. These 532 identifiers MUST be unique across all alternates used within the 533 session. This identifier is encoded in the "id" attribute of the 534 alternate element. The priority for the transport address, as 535 computed above, is included as an attribute as well. 537 Once the initiate message is constructed, it is sent. 539 5.5 Responder Processing - Connectivity Checks and Gathering 541 Once the responder receives the initiate message, it does several 542 things in parallel. First, it performs the same processing described 543 in Section 5.1. Specifically, for each media stream in the initiate 544 message, the responder allocates a set of local transport addresses 545 and the full set of derived transport addresses. 547 Note that these addresses can be "pre-gathered" before the call is 548 even received, so that a set is always "on-deck". This will avoid any 549 increase in call setup times, at the expense of holding onto 550 addresses which may not get used. Retaining these addresses may also 551 require refresh traffic that consumes network bandwidth. 553 While the unilateral derived addresses are being obtained, the 554 responder sends a STUN BindingRequest from each local transport 555 address to each STUN server identified in an alternate in the 556 initiate message. This BindingRequest MUST contain the USERNAME 557 attribute, and the value of the USERNAME MUST equal the username from 558 that alternate element. Similarly, the BindingRequest MUST contain a 559 PASSWORD attribute, and the value of the PASSWORD MUST equal the 560 password from the alternate element. The BindingRequest MUST contain 561 a MESSAGE-INTEGRITY attribute, computed using the username and 562 password from the alternate element in the initiate message. The 563 BindingRequest MUST NOT contain the CHANGE-REQUEST or 564 RESPONSE-ADDRESS attribute. 566 It is RECOMMENDED that these STUN requests be sent in parallel. The 567 responder MAY alert the user during this time. Generally, if the user 568 is a human (and not an automata), the STUN transactions will have 569 completed before the call is answered. 571 If the responder had obtained an address from TURN, it MAY use the 572 TURN SEND primitive to relay STUN BindingRequest messages, in 573 addition to sending them from the associated local transport address. 574 Generally, this would be done only by clients in networks that 575 prevent the client from sending outbound traffic directly to the 576 public Internet. These networks frequently require outbound traffic 577 to pass through some kind of intermediary. A TURN server can play the 578 role of such an intermediary. It is RECOMMENDED that, whether a 579 client should or should not also relay its STUN BindingRequests 580 through the TURN server, be configurable. 582 When STUN BindingRequest messages are being sent through a TURN 583 server, the ordering of alternates which are tried makes a 584 difference. When one of these BindingRequest messages elicits a 585 response, the response packet causes the TURN server to lock down 586 towards that alternate. Once locked down, the relay cannot be used 587 for receiving traffic from other addresses. If the lock down occurs 588 to an alternate with low preference, the result is sub-optimal. To 589 avoid this, instead of trying each alternate in parallel, it is 590 RECOMMENDED that the client try the addresses sequentially, starting 591 with the alternate with the highest preference value. 593 OPEN ISSUE: Trying this sequentially is ugly. Any alternatives I 594 was able to come up with required the client to control lock down. 595 Once this happens, it becomes possible to misuse TURN to run 596 public services behind a NAT, which is considered a non-starter. 597 Is there some other way? 599 In all cases, if the STUN BindingRequest elicits a BindingResponse 600 before the STUN transaction times out, the result is considered a 601 success. For successful transactions, the responder stores the 602 transport address from the initiate message (which identifies both 603 the STUN server and the place where media is sent), the local 604 transport address from which the STUN request was sent, the id of 605 that alternate from the initiate message, and the preference from 606 that alternate. If the STUN transaction succeeds, the client knows 607 for certain that the media can reach the destination as well. That is 608 because the media traffic will be sent from the same transport 609 address, to the same trasport address, as the STUN packet was. 611 When a client receives an initiate message, it MAY begin sending 612 media immediately to the address and port specified in the default. 613 If that address and port was also listed as an alternate, the client 614 MUST send media from the same address and port used to send a STUN 615 request to the peer. As the STUN transactions begin to complete, the 616 client begins to learn which alternates it has connectivity to. If 617 one of those alternates has a higher priority than the one currently 618 in use, that transport address MUST be used instead (along with its 619 corresponding local address). Note that, between two transport 620 addresses with the same preference, a STUN derived address MUST be 621 used. Furthermore, once a client sends media to a transport address 622 with a specified priority, it MUST NOT, during the lifetime of the 623 session, send media to a connected transport address with a lower 624 priority. 626 This restriction allows a client to free derived transport addresses 627 once it knows that its peer has been able to connect to a transport 628 address with higher priority, or one of equal priority if it was peer 629 derived. A client can know that a peer was able to connect to a 630 transport address based on the receipt of a STUN BindingRequest 631 against that transport address. The username and password in the STUN 632 BindingRequest can be used to determine which transport address the 633 STUN request was generated against. Note that the transport address 634 that the STUN request was received on does not say anything about 635 which transport address the peer sent to, and so the username and 636 password are used. Such an address SHOULD be freed no earlier than 3 637 seconds after receipt of the STUN request. This provides a window of 638 time for the peer to cease using the address and switch to a better 639 one. 641 This connectivity check makes an important assumption. It assumes 642 that if a STUN request is able to get from A to B, the STUN 643 response will get from B to A (packet losses aside). To our 644 knowledge this is generally true, since it is one of the 645 definining characteristics of the client-server protocols that 646 NATs have been designed to pass. We need to make this assumption 647 in order to free up resources and also eliminate additional ICE 648 cycles. 650 The drawback of this restriction is that if connectivity should be 651 lost during the session, the client cannot fall back to lower 652 priority address. We believe that it is more important to free 653 unneeded resources than to hold onto them in case of the unlikely 654 event of a problem. 656 For those successful STUN transactions, the responder compares the 657 MAPPED-ADDRESS attribute in the response to the local transport 658 address from which the STUN request was sent. If the two differ, the 659 responder considers the MAPPED-ADDRESS as another transport address 660 that has been gathered for usage in this session. This transport 661 address is referred to as a peer derived transport address. The 662 preference of this transport address is set to the value of the 663 preference of that alternate from the initiate message. For example, 664 if the initiator provides a transport address obtained from a local 665 interface, it might set the preference to 1.0. If the responder sends 666 a STUN request to the server and obtains a new transport address, 667 that transport address is assigned a preference of 1.0. That 668 preference will be used in comparison to other addresses gathered by 669 the responder. 671 If any STUN BindingRequest results in a BindingErrorResponse, the 672 ERROR-CODE is examined. If it is 401, 430, 432 or 500, the client 673 SHOULD retry the request, applying any appropriate fixes specified by 674 the error code. In the case of 400, 431 and 600, the client MUST NOT 675 retry. This case is treated identically to a timeout, so that it is 676 equal to no connectivity at all. 678 5.6 Generating the Accept Message 680 At some point, the responder will decide to accept or reject the 681 communications. A rejection terminates ICE processing, of course. In 682 the case of acceptance, the accept message is constructed as follows. 684 At the time when the accept message is to be sent, the responder will 685 have gathered some number of transport addresses. Some of these will 686 be local transport addresses, some will be unilaterally derived 687 addresses, and some will be stun derived from the peer in the dialog. 688 Each of these will have a preference, based on either the rules in 689 Section 5.1 or Section 5.5. 691 Constructing the accept proceeds identically to the way in which the 692 initiate message is constructed (Section 5.4). The transport address 693 with the highest probability of success is placed into the default 694 element. All of the alternatives (including the one placed into the 695 default) are placed into an alternate element. Each is assigned a 696 unique ID. For alternates that were peer-dervived STUN addresses, the 697 derived element is present, and it contains the id of the initiator's 698 alternate it was derived from. Each alternate contains its preference 699 as computed above. Each alternate contains a username and password 700 that must be used to contact the STUN server listening on that 701 address. Each address SHOULD have a different username and password. 703 The accept is then sent. 705 5.7 Initiator Processing of the Accept 707 There are two possible cases for processing of the Accept message. If 708 the recipient of the Initiate message did not support ICE, the Accept 709 message will only contain the default address information. As a 710 result, the initiator knows that it cannot perform its connectivity 711 checks. In this case, it SHOULD just sent to the transport address 712 listed. However, if local configuration information tells the 713 initiator to try connectivity checks by sending them through the TURN 714 server, this means that packets sent directly to responder may be 715 dropped by a local firewall. To deal with this, the initiator SHOULD 716 allocate, using TURN, a new TURN derived transport address. It does 717 not advertise this address anywhere. Rather, it issues a SEND command 718 using this new transport address. The SEND command contains the media 719 packet to send to the responder. Once this command has been accepted, 720 the initiator SHOULD send all media packets to the TURN server, which 721 will then forward them towards the responder. 723 If the Accept message contains alternates, the processing of the 724 accept by the initiator is nearly identical to that of the responder 725 processing the initiate message. Specifically, the initiator will 726 send STUN requests to the STUN servers listed in the accept. This 727 results in the same connectivity processing, and will also result in 728 the gathering of new STUN derived addresses. The initiator can begin 729 sending media to the responder immediately using the address in the 730 default. Once STUN has verified connectivity of higher priority 731 addresses, media is sent to those addresses instead. When a client 732 sends media to an alternate with higher priority, if that alternate 733 contained the derived element, the client MUST send media from the 734 local transport address with the id contained in the derived element. 736 5.8 Additional ICE Cycles 738 After the completion of the initiate/accept exchange, both sides may 739 continue to obtain more derived transport addresses. This may occur 740 because a STUN transaction took too long to complete, and thus missed 741 the "window" of the previous initiate message/accept exchange. Or, it 742 may occur because the previous initiate/accept exchange provided 743 additional addresses which resulted in new STUN derived attributes. 745 At any point when either client has one or more new gathered 746 addresses, it MAY initiate a modify message, and therefore a new 747 corresponding ICE cycle. This modify message is identical to the 748 initiate or accept message generated previously by that client. 749 However, it would include any additional alternates learned since the 750 last message was sent. However, if the preference of those new 751 gathered addresses is lower than the preference for an address that 752 the peer has established connectivity to, the client SHOULD NOT 753 initiate a modify exchange just to convey this address. If an modify 754 exchange is taking place anyway (because a higher priority address is 755 available), the lower qvalue addresses SHOULD be included. A client 756 can determine which addresses a peer has established connectivity to 757 by checking if a STUN request was sent by the peer to that address. 759 OPEN ISSUE: This optimization doesnt work in cases where the peer 760 establishes connectivity by sending media through its TURN relay, 761 since the resulting priority is less. The client doesnt have any 762 way to know whether or not the connectivity check was made by 763 sending through a relay. 765 Typically, there won't be more than one or two ICE cycles before 766 convergence. Assuming that there is no network packet loss (which can 767 extend the STUN transaction) and zero network latency, it appears 768 that a maximum of two ICE cycles are needed to reach convergence. 770 6. Running STUN on Derived Transport Addresses 772 One of the seemingly bizarre operations done during the ICE 773 processing is the transmission of a STUN request to a transport 774 address which is obtained through TURN or STUN itself. This actually 775 does work, and in fact, has extremely useful properties. The 776 subsections below go through the detailed operations that would occur 777 at each point to demonstrate correctness and the properties derived 778 from it. 780 6.1 STUN on a TURN Derived Transport Address 782 Consider a client A that is behind a NAT. It connects to a TURN 783 server on the public side of the NAT. To do that, A binds to a local 784 transport address, say 10.0.1.1:8866, and then sends a TURN request 785 to the TURN server. The NAT translates the net-10 address to 786 192.0.2.88:5063. Assume that the TURN server is running on 192.0.2.1 787 and listening for TURN traffic on port 7764. The TURN server 788 allocates a derived transport address 192.0.2.1:26524 to the client, 789 and returns it in the TURN response. Remember that all traffic from 790 the TURN server to the client is sent from 192.0.2.1:7764 to 791 10.0.1.1:8866. 793 Now, the client runs a STUN server on 10.0.1.1:8866, and advertises 794 that its server actually runs on 192.0.2.1:26524. Another client, B, 795 sends a STUN request to this server. It sends it from a local 796 transport address, 192.0.2.77:1296. When it arrives at 797 192.0.2.1:26524, the TURN server "locks down" outgoing traffic, so 798 that data packets received from A are sent to 192.0.2.77:1296. The 799 STUN request is then forwarded to the client, sent with a source 800 address of 192.0.2.1:7764 and a destination address of 801 192.0.2.88:5063. This passes through the NAT, which rewrites the 802 source address to 10.0.1.1:8866. This arrives at A's STUN server. The 803 server observes the source address of 192.0.2.1:7764, and generates a 804 STUN response containing this value in the MAPPED-ADDRESS attribute. 805 The STUN response is sent with a source address fo 10.0.1.1:8866, and 806 a destination of 192.0.2.1:7764. This arrives at the TURN server, 807 which, because of the lock-down, sends the STUN response with a 808 source address of 192.0.2.1:26524 and destination of 192.0.2.77:1296, 809 which is B's STUN client. 811 Now, as far as B is concerned, it has obtained a new STUN derived 812 transport address of 192.0.2.1:7764. And indeed, it has! STUN derived 813 transport addresses are scoped to the session, so they can only be 814 used by the peer in the session. Furthermore, that peer has to send 815 requests from the socket on which the STUN server was running. In 816 this case, A is the peer, and its STUN server was on 10.0.1.1:8866. 817 If it sends to 192.0.2.1:7764, the packet goes to the TURN server, 818 and due to lock-down, is forwarded to B, and specifically, is 819 forwarded to the transport address B sent the STUN request from. 820 Therefore, the address is indeed a valid STUN derived transport 821 address. 823 The benefit of this is that it allows two clients to share the same 824 TURN server for media traffic in both directions. With "normal" TURN 825 usage, both clients would obtain a derived address from their own 826 TURN servers. The result is that, for a single call, there are two 827 bindings allocated by each side from their respective servers, and 828 all four are used. With ICE, that drops to two bindings allocated 829 from a single server. Of course, all four bindings are allocated 830 initially. However, once one of the clients begins receiving media on 831 its STUN derived address, it can deallocate its TURN resources. 833 [[TODO: Include a diagram that shows this pictorially.]] 835 6.2 STUN on a STUN Derived Transport Address 837 Consider a client A that is behind a NAT. It connects to a STUN 838 server on the public side of the NAT. To do that, A binds to a local 839 transport address, say 10.0.1.1:8866, and then sends a STUN request 840 to the STUN server. The NAT translates the net-10 address to 841 192.0.2.88:5063. Assume that the STUN server is running on 192.0.2.1 842 and listening for STUN traffic on port 3478, the default STUN port. 843 The STUN server sees a source IP address of 192.0.2.88:5063, and 844 returns that to the client in the STUN response. The NAT forwards the 845 response to the client. 847 Now, the client runs a STUN server on 10.0.1.1:8866, and advertises 848 that its server actually runs on 192.0.2.88:5063. Another client, B, 849 sends a STUN request to this address. It sends it from a local 850 transport address, 192.0.2.77:1296. When it arrives at 851 192.0.2.88:5063 (on the NAT), the NAT rewrites the source address to 852 10.0.1.1:8866, assuming that it is of the full-cone variety [1], or 853 is restricted, and the permission for 192.0.2.77:1296 is open. This 854 arrives at A's STUN server. The server observes the source address of 855 192.0.2.77:1296, and generates a STUN response containing this value 856 in the MAPPED-ADDRESS attribute. The STUN response is sent with a 857 source address of 10.0.1.1:8866, and a destination of 858 192.0.2.77:1296. This arrives at B's STUN client. 860 Now, as far as B is concerned, it has obtained a new STUN derived 861 transport address of 192.0.2.77:1296. Of course, this is the same 862 address as the local transport address, and therefore this derived 863 address is not used. However, had there been additonal NATs between B 864 and A's NAT, B would end up seeing the binding allocated by that 865 outermost NAT. The net result is that STUN requests sent to a STUN 866 derived address behave as normal STUN would. However, these STUN 867 requests have the side-effect of creating permissions in the NATs 868 which see those requests in the public to private direction. This 869 turns out to be very useful for traversing restricted NATs. 871 7. XML Schema for ICE Messages 873 This section contains the XML schema used to define the initiate, 874 accept, and modify messages. Any protocol that uses ICE needs to map 875 the parameters defined here into its own messages. 877 Note that STUN allows both the username and password to contain the 878 space character. However, usernames and passwords used with ICE 879 cannot contain the space. 881 882 884 885 886 This is the root element, which holds a series 887 of media stream elements. 888 889 890 891 892 893 There are zero or more media stream 894 elements. Each defines attributes for a specific media 895 stream. 896 897 898 899 900 901 The default address is used for 902 sending media before connectivity has been 903 verified. 904 905 906 907 908 909 910 911 912 914 915 Each alternate is a 916 possible point of contact. 917 918 919 920 921 923 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 966 8. Examples 968 TODO. Fill in with example XML message exchanges. 970 9. Mapping ICE into SIP 972 In this section, we show how to map ICE into SIP. This requires 973 extensions to SDP. 975 A new SDP attribute is defined to support ICE. It is called "alt". 976 The alt attribute MUST be present within a media block of the SDP. It 977 contains an alternative IP address and port (or pair of IP addresses 978 and ports in the case of RTP) that the recipient of the SDP can use 979 instead of the ones indicated in the m and c lines. There MAY be 980 multiple alt attributes in a media block. In that case, each of them 981 MUST contain a different IP address and port (or a differing pair of 982 IP address and ports in the case of RTP). 984 The syntax of this attribute is: 986 alt-attribute = "alt" ":" id SP qvalue SP derived-from SP 987 username SP password SP 988 unicast-address SP port [unicast-address SP port] 989 ;qvalue from RFC 3261 990 ;unicast-address, port from RFC 2327 991 username = non-ws-string 992 password = non-ws-string 993 id = token 994 derived-from = ":" / id 996 With the addition of the alt attribute, the mapping of the ICE 997 messages to SIP/SDP is straightforward. The ICE initiate message 998 corresponds to a SIP message with an SDP offer. The ICE accept 999 message corresponds to a SIP message with a SDP answer. The ICE 1000 modify message corresponds to a SIP INVITE or UPDATE with an offer, 1001 and the ICE modify accept message corresponds to an INVITE or UPDATE 1002 response with an answer. 1004 Each media stream element in an ICE message maps to a media block in 1005 the SDP. The default address maps to the m and c lines in the SDP. If 1006 the ICE message indicates an RTCP address and port that are not one 1007 higher than that of the RTP, the SDP RTCP attribute [2] MUST be used 1008 to convey them. 1010 Each alternate element in an ICE message maps either to an alt 1011 attribute in the SDP, or a new media block, depending on the IP 1012 version of the alternate. For the highest priority IPv6 alternate, it 1013 is mapped into a separate media block, using the IPV grouping [3]. 1014 Any additional IPv6 addresses are placed as alternates within this 1015 media block. For alternates that are IPv4 addresses, the alt 1016 attribute is used. The rtp-address element maps to the first 1017 unicast-address and port components of the alt attribute. The 1018 rtcp-address element maps to the second unicast-address and port 1019 components of the alt attribute. Note that, if the RTCP address is 1020 identical to the RTP address, and the port is one higher, the second 1021 unicast-address and port MAY be omitted. The preference value from 1022 the alternate element is mapped to the q-value component of the alt 1023 attribute. The STUN username and password elements map to the 1024 username and password components of the alt attribute. When the 1025 derived element is present in the ICE message, it is represented in 1026 the derived-from component of the alt attribute. If it is not present 1027 in the ICE message, the derived-from component of the alt attribute 1028 has a value of ":". 1030 10. Security Considerations 1032 ICE conveys the STUN username and password within its messages. If an 1033 eavesdropper should see the username and password, the worst they can 1034 do is send STUN requests to the host. Since STUN is a stateless 1035 protocol, the attacker can not alter the processing of the call or 1036 otherwise disrupt it. They could flood the server with BindingRequest 1037 packets. However, this would be no worse than if the attacker simply 1038 floods the host with any kind of packet. 1040 However, integrity protection of the username and password are more 1041 important. If an attacker is capable of intercepting the message and 1042 modifying the username or password, they could prevent connectivity 1043 from being established between peers, and therefore disrupt the call. 1044 Of course, if the attacker can intercept the message, there are many 1045 other ways in which they could do that, such as simply discarding the 1046 message. Injecting fake messages with incorect usernames and 1047 passwords can also disrupt a call, and does not require the 1048 compromise of an intermediate server. A similar attack is possible by 1049 modifying most of the ICE message attributes. To prevent these kinds 1050 of attacks, it is RECOMMENDED that the actual protocols the ICE maps 1051 to make use of security mechanisms that provide message integrity 1052 protection. 1054 11. IANA Considerations 1056 This specification defines one new media attribute: alt. Its syntax 1057 is defined in Section 9. 1059 12. IAB Considerations 1061 The IAB has studied the problem of "Unilateral Self Address Fixing", 1062 which is the general process by which a client attempts to determine 1063 its address in another realm on the other side of a NAT through a 1064 collaborative protocol reflection mechanism [11]. ICE is an example 1065 of a protocol that performs this type of function. Interestingly, the 1066 process for ICE is not unilateral, but bilateral, and the difference 1067 has a signficant impact on the issues raised by IAB. The IAB has 1068 mandated that any protocols developed for this purpose document a 1069 specific set of considerations. This section meets those 1070 requirements. 1072 12.1 Problem Definition 1074 From RFC 3424 any UNSAF proposal must provide: 1076 Precise definition of a specific, limited-scope problem that is to 1077 be solved with the UNSAF proposal. A short term fix should not 1078 be generalized to solve other problems; this is why "short term 1079 fixes usually aren't". 1081 The specific problems being solved by ICE are: 1083 Provide a means for two peers to determine the set of transport 1084 addresses which can be used for communication. 1086 Provide a means for resolving many of the limitations of other 1087 UNSAF mechanisms by wrapping them in an additional layer of 1088 processing (the ICE methodology). 1090 Provide a means for a client to determine an address that is 1091 reachable by another peer with which it wishes to communicate. 1093 12.2 Exit Strategy 1095 From RFC 3424, any UNSAF proposal must provide: 1097 Description of an exit strategy/transition plan. The better short 1098 term fixes are the ones that will naturally see less and less use 1099 as the appropriate technology is deployed. 1101 ICE itself doesn't easily get phased out. However, it is useful even 1102 in a globally connected Internet, to serve as a means for detecting 1103 whether a router failure has temporarily disrupted connectivity, for 1104 example. However, what ICE does is help phase out other UNSAF 1105 mechanisms. ICE effectively selects amongst those mechanisms, 1106 prioritizing ones that are better, and deprioritizing ones that are 1107 worse. Local IPv6 addresses are always the most preferred. As NATs 1108 begin to dissipate as IPv6 is introduced, derived transport addresses 1109 from other UNSAF mechanisms simply never get used, because higher 1110 priority connectivity exists. Therefore, the servers get used less 1111 and less, and can eventually be remove when their usage goes to zero. 1113 Indeed, ICE can assist in the transition from IPv4 to IPv6. It can be 1114 used to determine whether to use IPv6 or IPv4 when two dual-stack 1115 hosts communicate with SIP (IPv6 gets used). It can also allow a 1116 client in a v6 island to communicate with a v4 host on the other side 1117 of a 6to4 NAT, by allowing the v6 host to address-fix against the v4 1118 host, and in the process, obtain a v4 address which can be handed to 1119 the v4 client. 1121 12.3 Brittleness Introduced by ICE 1123 From RFC3424, any UNSAF proposal must provide: 1125 Discussion of specific issues that may render systems more 1126 "brittle". For example, approaches that involve using data at 1127 multiple network layers create more dependencies, increase 1128 debugging challenges, and make it harder to transition. 1130 ICE actually removes brittleness from existing UNSAF mechanisms. In 1131 particular, traditional STUN (the usage described in RFC 3489) has 1132 several points of brittleness. One of them is the discovery process 1133 which requires a client to try and classify the type of NAT it is 1134 behind. This process is error-prone. With ICE, that discovery process 1135 is simply not used. Rather than unilaterally assessing the validity 1136 of the address, its validity is dynamically determined by measuring 1137 connectivity to a peer. The process of determining connectivity is 1138 very robust. The only potential problem is that bilaterally fixed 1139 addresses through STUN can expire if traffic does not keep them 1140 alive. However, that is substantially less brittleness than the STUN 1141 discovery mechanisms. 1143 Another point of brittleness in STUN, TURN, and any other unilateral 1144 mechanism is its absolute reliance on an additional server. ICE makes 1145 use of a server for allocating unilateral addresses, but allows 1146 clients to directly connect if possible. Therefore, in some cases, 1147 the failure of a STUN or TURN server would still allow for a call to 1148 progress when ICE is used. 1150 Another point of brittleness in traditional STUN is that it assumes 1151 that the STUN server is on the public Internet. Interestingly, with 1152 ICE, that is not necessary. There can be a multitude of STUN servers 1153 in a variety of address realms. ICE will discover the one that has 1154 provided a usable address. 1156 The most troubling point of brittleness in traditional STUN is that 1157 it doesn't work in all network topologies. In cases where there is a 1158 shared NAT between each client and the STUN server, traditional STUN 1159 may not work. With ICE, that restriction can be lifted. 1161 Traditional STUN also introduces some security considerations. 1162 Unfortunately, since ICE still uses network resident STUN servers, 1163 those security considerations still exist. 1165 12.4 Requirements for a Long Term Solution 1167 From RFC 3424, any UNSAF proposal must provide: 1169 Identify requirements for longer term, sound technical solutions 1170 -- contribute to the process of finding the right longer term 1171 solution. 1173 Our conclusions from STUN remain unchanged. However, we feel ICE 1174 actually helps because we believe it can be part of the long term 1175 solution. 1177 12.5 Issues with Existing NAPT Boxes 1179 From RFC 3424, any UNSAF proposal must provide: 1181 Discussion of the impact of the noted practical issues with 1182 existing, deployed NA[P]Ts and experience reports. 1184 A number of NAT boxes are now being deployed into the market which 1185 try and provide "generic" ALG functionality. These generic ALGs hunt 1186 for IP addresses, either in text or binary form within a packet, and 1187 rewrite them if they match a binding. This will interfere with proper 1188 operation of any UNSAF mechanism, including ICE. 1190 13. Acknowledgements 1192 The authors would like to thank Douglas Otis and Francois Audet for 1193 their comments and input. 1195 Normative References 1197 [1] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 1198 Simple Traversal of User Datagram Protocol (UDP) Through Network 1199 Address Translators (NATs)", RFC 3489, March 2003. 1201 [2] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 1202 Session Description Protocol (SDP)", RFC 3605, October 2003. 1204 [3] Camarillo, G. and J. Rosenberg, "The Alternative Semantics for 1205 the Session Description Protocol Grouping Framework", 1206 draft-camarillo-mmusic-alt-02 (work in progress), October 2003. 1208 Informative References 1210 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1211 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1212 Session Initiation Protocol", RFC 3261, June 2002. 1214 [5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1215 Protocol (RTSP)", RFC 2326, April 1998. 1217 [6] Senie, D., "Network Address Translator (NAT)-Friendly 1218 Application Design Guidelines", RFC 3235, January 2002. 1220 [7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 1221 Rayhan, "Middlebox communication architecture and framework", 1222 RFC 3303, August 2002. 1224 [8] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm 1225 Specific IP: Framework", RFC 3102, October 2001. 1227 [9] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm 1228 Specific IP: Protocol Specification", RFC 3103, October 2001. 1230 [10] Yon, D., "Connection-Oriented Media Transport in SDP", 1231 draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 1232 2003. 1234 [11] Daigle, L. and IAB, "IAB Considerations for UNilateral 1235 Self-Address Fixing (UNSAF) Across Network Address 1236 Translation", RFC 3424, November 2002. 1238 [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1239 "RTP: A Transport Protocol for Real-Time Applications", RFC 1240 3550, July 2003. 1242 [13] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 1243 draft-ietf-ngtrans-shipworm-08 (work in progress), September 1244 2002. 1246 [14] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 1247 draft-rosenberg-midcom-turn-03 (work in progress), October 1248 2003. 1250 Author's Address 1252 Jonathan Rosenberg 1253 dynamicsoft 1254 600 Lanidex Plaza 1255 Parsippany, NJ 07054 1256 US 1258 Phone: +1 973 952-5000 1259 EMail: jdrosen@dynamicsoft.com 1260 URI: http://www.jdrosen.net 1262 Intellectual Property Statement 1264 The IETF takes no position regarding the validity or scope of any 1265 intellectual property or other rights that might be claimed to 1266 pertain to the implementation or use of the technology described in 1267 this document or the extent to which any license under such rights 1268 might or might not be available; neither does it represent that it 1269 has made any effort to identify any such rights. Information on the 1270 IETF's procedures with respect to rights in standards-track and 1271 standards-related documentation can be found in BCP-11. Copies of 1272 claims of rights made available for publication and any assurances of 1273 licenses to be made available, or the result of an attempt made to 1274 obtain a general license or permission for the use of such 1275 proprietary rights by implementors or users of this specification can 1276 be obtained from the IETF Secretariat. 1278 The IETF invites any interested party to bring to its attention any 1279 copyrights, patents or patent applications, or other proprietary 1280 rights which may cover technology that may be required to practice 1281 this standard. Please address the information to the IETF Executive 1282 Director. 1284 Full Copyright Statement 1286 Copyright (C) The Internet Society (2004). All Rights Reserved. 1288 This document and translations of it may be copied and furnished to 1289 others, and derivative works that comment on or otherwise explain it 1290 or assist in its implementation may be prepared, copied, published 1291 and distributed, in whole or in part, without restriction of any 1292 kind, provided that the above copyright notice and this paragraph are 1293 included on all such copies and derivative works. However, this 1294 document itself may not be modified in any way, such as by removing 1295 the copyright notice or references to the Internet Society or other 1296 Internet organizations, except as needed for the purpose of 1297 developing Internet standards in which case the procedures for 1298 copyrights defined in the Internet Standards process must be 1299 followed, or as required to translate it into languages other than 1300 English. 1302 The limited permissions granted above are perpetual and will not be 1303 revoked by the Internet Society or its successors or assignees. 1305 This document and the information contained herein is provided on an 1306 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1307 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1308 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1309 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1310 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1312 Acknowledgment 1314 Funding for the RFC Editor function is currently provided by the 1315 Internet Society.