idnits 2.17.1 draft-ietf-mmusic-ice-tcp-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 10, 2010) is 4915 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 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Rosenberg 3 Internet-Draft Skype 4 Intended status: Standards Track A. Keranen 5 Expires: May 14, 2011 Ericsson 6 B. Lowekamp 7 Skype 8 A. Roach 9 Tekelec 10 November 10, 2010 12 TCP Candidates with Interactive Connectivity Establishment (ICE) 13 draft-ietf-mmusic-ice-tcp-11 15 Abstract 17 Interactive Connectivity Establishment (ICE) defines a mechanism for 18 NAT traversal for multimedia communication protocols based on the 19 offer/answer model of session negotiation. ICE works by providing a 20 set of candidate transport addresses for each media stream, which are 21 then validated with peer-to-peer connectivity checks based on Session 22 Traversal Utilities for NAT (STUN). ICE provides a general framework 23 for describing candidates, but only defines UDP-based transport 24 protocols. This specification extends ICE to TCP-based media, 25 including the ability to offer a mix of TCP and UDP-based candidates 26 for a single stream. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 14, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 77 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 7 78 4.1. Gathering Candidates . . . . . . . . . . . . . . . . . . . 7 79 4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . . 9 80 4.3. Choosing Default Candidates . . . . . . . . . . . . . . . 10 81 4.4. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 11 82 5. Candidate Collection Techniques . . . . . . . . . . . . . . . 11 83 5.1. Host Candidates . . . . . . . . . . . . . . . . . . . . . 12 84 5.2. Server Reflexive Candidates . . . . . . . . . . . . . . . 13 85 5.3. NAT-Assisted Candidates . . . . . . . . . . . . . . . . . 13 86 5.4. UDP-Tunneled Candidates . . . . . . . . . . . . . . . . . 13 87 5.5. Relayed Candidates . . . . . . . . . . . . . . . . . . . . 14 88 6. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 14 89 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 14 90 6.2. Forming the Check Lists . . . . . . . . . . . . . . . . . 15 91 7. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 15 92 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . . 15 93 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . . 16 94 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 16 95 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 17 96 9.1. ICE Restarts . . . . . . . . . . . . . . . . . . . . . . . 17 97 10. Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 17 98 10.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 17 99 10.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 18 100 11. Connection Management . . . . . . . . . . . . . . . . . . . . 18 101 11.1. Connections Formed During Connectivity Checks . . . . . . 18 102 11.2. Connections Formed for Gathering Candidates . . . . . . . 19 103 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 104 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 105 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 106 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 15.1. Normative References . . . . . . . . . . . . . . . . . . . 21 108 15.2. Informative References . . . . . . . . . . . . . . . . . . 21 109 Appendix A. Limitations of ICE TCP . . . . . . . . . . . . . . . 23 110 Appendix B. Implementation Considerations for BSD Sockets . . . . 23 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 113 1. Introduction 115 Interactive Connectivity Establishment (ICE) [RFC5245] defines a 116 mechanism for NAT traversal for multimedia communication protocols 117 based on the offer/answer model [RFC3264] of session negotiation. 118 ICE works by providing a set of candidate transport addresses for 119 each media stream, which are then validated with peer-to-peer 120 connectivity checks based on Session Traversal Utilities for NAT 121 (STUN) [RFC5389]. However, ICE only defines procedures for UDP-based 122 transport protocols. 124 There are many reasons why ICE support for TCP is important. 125 Firstly, there are media protocols that only run over TCP. Such 126 protocols are used, for example, for screen sharing and instant 127 messaging [RFC4975]. For these protocols to work in the presence of 128 NAT, unless they define their own NAT traversal mechanisms, ICE 129 support for TCP is needed. In addition, RTP can also run over TCP 130 [RFC4571]. Typically, it is preferable to run RTP over UDP, and not 131 TCP. However, in a variety of network environments, overly 132 restrictive NAT and firewall devices prevent UDP-based communications 133 altogether, but general TCP-based communications are permitted. In 134 such environments, sending RTP over TCP, and thus establishing the 135 media session, may be preferable to having it fail altogether. With 136 this specification, agents can gather UDP and TCP candidates for a 137 media stream, list the UDP ones with higher priority, and then only 138 use the TCP-based ones if the UDP ones fail. This provides a 139 fallback mechanism that allows multimedia communications to be highly 140 reliable. 142 The usage of RTP over TCP is particularly useful when combined with 143 Traversal Using Relays around NAT (TURN) [RFC5766]. In this case, 144 one of the agents would connect to its TURN server using TCP, and 145 obtain a TCP-based relayed candidate. It would offer this to its 146 peer agent as a candidate. The answerer would initiate a TCP 147 connection towards the TURN server. When that connection is 148 established, media can flow over the connections, through the TURN 149 server. The benefit of this usage is that it only requires the 150 agents to make outbound TCP connections to a server on the public 151 network. This kind of operation is broadly interoperable through NAT 152 and firewall devices. Since it is a goal of ICE and this extension 153 to provide highly reliable communications that "just works" in as a 154 broad a set of network deployments as possible, this use case is 155 particularly important. 157 This specification extends ICE by defining its usage with TCP 158 candidates. It also defines how ICE can be used with RTP and Secure 159 RTP (SRTP) to provide both TCP and UDP candidates. This 160 specification does so by following the outline of ICE itself, and 161 calling out the additions and changes necessary in each section of 162 ICE to support TCP candidates. 164 It should be noted that since TCP NAT traversal is more complicated 165 than with UDP, ICE TCP is not as efficient as UDP-based ICE. 166 Discussion about this topic can be found in Appendix A. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 This document uses the same terminology as ICE (see Section 3 of 175 [RFC5245]). 177 3. Overview of Operation 179 The usage of ICE with TCP is relatively straightforward. The main 180 area of specification is around how and when connections are opened, 181 and how those connections relate to candidate pairs. 183 When the agents perform address allocations to gather TCP-based 184 candidates, three types of candidates can be obtained. These are 185 active candidates, passive candidates, and simultaneous-open (S-O) 186 candidates. An active candidate is one for which the agent will 187 attempt to open an outbound connection, but will not receive incoming 188 connection requests. A passive candidate is one for which the agent 189 will receive incoming connection attempts, but not attempt a 190 connection. S-O candidate is one for which the agent will attempt to 191 open a connection simultaneously with its peer. 193 Unlike for UDP, there are no lite implementation defined for TCP. 194 Instead, an implementation that meets the criteria for a lite 195 implementation as discussed in Appendix A of [RFC5245] can just use 196 the mechanisms defined in [RFC4145], with constraints defined here on 197 selection of attribute values (see Section 4). 199 When gathering candidates from a host interface, the agent typically 200 obtains active, passive, and S-O candidates. Similarly, one can use 201 different techniques for obtaining, e.g., server reflexive, NAT- 202 assisted, tunneled, or relayed candidates of these three types. 203 Connections to servers used for relayed and server reflexive 204 candidates are kept open during ICE processing. 206 When encoding these candidates into offers and answers, the type of 207 the candidate is signaled. In the case of active candidates, an IP 208 address and port is present, but it is meaningless, as it is ignored 209 by the peer. As a consequence, active candidates do not need to be 210 physically allocated at the time of address gathering. Rather, the 211 physical allocations, which occur as a consequence of a connection 212 attempt, occur at the time of the connectivity checks. 214 When the candidates are paired together, active candidates are always 215 paired with passive, and S-O candidates with each other. When a 216 connectivity check is to be made on a candidate pair, each agent 217 determines whether it is to make a connection attempt for this pair. 219 The actual process of generating connectivity checks, managing the 220 state of the check list, and updating the Valid list, work 221 identically for TCP as they do for UDP. 223 ICE requires an agent to demultiplex STUN and application layer 224 traffic, since they appear on the same port. This demultiplexing is 225 described by ICE, and is done using the magic cookie and other fields 226 of the message. Stream-oriented transports introduce another 227 wrinkle, since they require a way to frame the connection so that the 228 application and STUN packets can be extracted in order to determine 229 which is which. For this reason, TCP media streams utilizing ICE use 230 the basic framing provided in RFC 4571 [RFC4571], even if the 231 application layer protocol is not RTP. 233 When TLS is in use (for non-RTP traffic) or DTLS (for RTP traffic), 234 it runs over the RFC 4571 framing shim, so that STUN runs outside of 235 the (D)TLS connection. Pictorially: 237 +----------+ 238 | | 239 | App | 240 +----------+----------+ 241 | | | 242 | STUN | (D)TLS | 243 +----------+----------+ 244 | | 245 | RFC 4571 | 246 +---------------------+ 247 | | 248 | TCP | 249 +---------------------+ 250 | | 251 | IP | 252 +---------------------+ 254 Figure 1: ICE TCP Stack 256 The implication of this is that, for any media stream protected by 257 (D)TLS, the agent will first run ICE procedures, exchanging STUN 258 messages. Then, once ICE completes, (D)TLS procedures begin. ICE 259 and (D)TLS are thus "peers" in the protocol stack. The STUN messages 260 are not sent over the (D)TLS connection, even ones sent for the 261 purposes of keepalive in the middle of the media session. 263 When an updated offer is generated by the controlling endpoint, the 264 SDP extensions for connection oriented media [RFC4145] are used to 265 signal that an existing connection should be used, rather than 266 opening a new one. 268 4. Sending the Initial Offer 270 If an offerer meets the criteria for lite as defined in Appendix A of 271 [RFC5245], it omits any ICE attributes for its TCP-based media 272 streams. Instead, the offerer follows the procedures defined in 273 [RFC4145] for constructing the offer. However, the offerer MUST use 274 a setup attribute of "actpass" for those streams. 276 For offerers making use of ICE for TCP streams, the procedures below 277 are used. 279 4.1. Gathering Candidates 281 Providers of real-time communications services may decide that it is 282 preferable to have no media at all than it is to have media over TCP. 283 To allow for choice, it is RECOMMENDED that agents be configurable 284 with whether they obtain TCP candidates for real time media. 286 Having it be configurable, and then configuring it to be off, is 287 far better than not having the capability at all. An important 288 goal of this specification is to provide a single mechanism that 289 can be used across all types of endpoints. As such, it is 290 preferable to account for provider and network variation through 291 configuration, instead of hard-coded limitations in an 292 implementation. Furthermore, network characteristics and 293 connectivity assumptions can, and will change over time. Just 294 because an agent is communicating with a server on the public 295 network today, doesn't mean that it won't need to communicate with 296 one behind a NAT tomorrow. Just because an agent is behind a NAT 297 with endpoint independent mapping today, doesn't mean that 298 tomorrow they won't pick up their agent and take it to a public 299 network access point where there is a NAT with address and port 300 dependent mapping properties, or one that only allows outbound 301 TCP. The way to handle these cases and build a reliable system is 302 for agents to implement a diverse set of techniques for allocating 303 addresses, so that at least one of them is almost certainly going 304 to work in any situation. Implementors should consider very 305 carefully any assumptions that they make about deployments before 306 electing not to implement one of the mechanisms for address 307 allocation. In particular, implementors should consider whether 308 the elements in the system may be mobile, and connect through 309 different networks with different connectivity. They should also 310 consider whether endpoints which are under their control, in terms 311 of location and network connectivity, would always be under their 312 control. In environments where mobility and user control are 313 possible, a multiplicity of techniques is essential for 314 reliability. 316 First, agents SHOULD obtain host candidates as described in 317 Section 5.1. Then, each agent SHOULD "obtain" (allocate a 318 placeholder for) an active host candidate for each component of each 319 TCP capable media stream on each interface that the host has. The 320 agent does not have to yet actually allocate a port for these 321 candidates, but they are used for the creation of the check lists. 323 Next, the agents SHOULD obtain passive (and possibly S-O) relayed 324 candidates for each component as described in Section 5.5. Each 325 agent SHOULD also allocate a placeholder for an active relayed 326 candidate for each component of each TCP capable media stream. 328 The agent SHOULD then obtain server reflexive, NAT-assisted, and/or 329 UDP-tunneled candidates (see Section 5.2, Section 5.3, and 330 Section 5.4). The mechanisms for establishing these candidates and 331 the number of candidates to collect vary from technique to technique. 332 These considerations are discussed in the relevant sections, below. 334 It is highly recommended that a host obtains at least one set of host 335 and one set of relayed candidates. Obtaining additional candidates 336 will increase the chance of successfully creating a direct 337 connection. 339 Once the candidates have been obtained, the agent MUST keep the TCP 340 connections open until ICE processing has completed. See Appendix B 341 for important implementation guidelines. 343 If a media stream is UDP-based (such as RTP), an agent MAY use an 344 additional host TCP candidate to request a UDP-based candidate from a 345 TURN server (or some other relay with similar functionality). Usage 346 of such UDP candidates follows the procedures defined in ICE for UDP 347 candidates. 349 Like its UDP counterparts, TCP-based STUN transactions are paced out 350 at one every Ta seconds. This pacing refers strictly to STUN 351 transactions (both Binding and Allocate requests). If performance of 352 the transaction requires establishment of a TCP connection, then the 353 connection gets opened when the transaction is performed. 355 4.2. Prioritization 357 The transport protocol itself is a criteria for choosing one 358 candidate over another. If a particular media stream can run over 359 UDP or TCP, the UDP candidates might be preferred over the TCP 360 candidates. This allows ICE to use the lower latency UDP 361 connectivity if it exists, but fallback to TCP if UDP doesn't work. 363 To accomplish this, the local preference SHOULD be defined as: 365 local-preference = (2^12)*(transport-pref) + 366 (2^7)*(class-pref) + 367 (2^0)*(other-pref) 369 Transport-pref is the relative preference for candidates with this 370 particular transport protocol (UDP or TCP), and class-pref is the 371 preference for candidates with this particular establishment 372 directionality and class (active, passive, or S-O with different 373 class of NAT traversal techniques). Other-pref is used as a 374 differentiator when two candidates would otherwise have identical 375 local preferences. 377 Transport-pref MUST be between 0 and 15, with 15 being the most 378 preferred. Class-pref MUST be between 0 and 31, with 31 being the 379 most preferred. Other-pref MUST be between 0 and 127, with 127 being 380 the most preferred. For RTP-based media streams, it is RECOMMENDED 381 that UDP have a transport-pref of 12 and TCP of 6. It is RECOMMENDED 382 that, for all connection-oriented media, candidates have a class-pref 383 assigned as follows: 385 29 Host active candidate 386 28 Host passive candidate 387 27 Host S-O candidate 388 23 NAT-assisted S-O candidate 389 22 NAT-assisted active candidate 390 21 NAT-assisted passive candidate 391 17 Server reflexive S-O candidate 392 16 Server reflexive active candidate 393 15 Server reflexive passive candidate 394 11 UDP-tunneled active candidate 395 10 UDP-tunneled passive candidate 396 9 UDP-tunneled S-O candidate 397 5 Relayed active candidate 398 4 Relayed passive candidate 399 3 Relayed S-O candidate 401 If it is more important to use certain kind (NAT-assisted, server 402 reflexive, etc.) of candidates rather than certain transport 403 protocol, it is RECOMMENDED that the type preference for NAT-assisted 404 candidates be set higher than that for server-reflexive candidates 405 and that the type preference for UDP-tunneled candidates be set lower 406 than that for server-reflexive candidates. The RECOMMENDED values 407 are 105 for NAT-assisted candidates and 75 for UDP-tunneled 408 candidates. However, if the transport protocol is more important, 409 NAT-assisted and UDP-tunneled candidates MAY use the same type 410 preference as the server-reflexive candidates. 412 The class-pref priorities listed above are simply recommendations 413 that try to strike a balance between success probability and 414 resulting path's efficiency. Depending on the scenario where ICE TCP 415 is used, different values may be appropriate. For example, if the 416 overhead of a UDP tunnel is not an issue, those candidates should be 417 prioritized higher since they are likely to have a high success 418 probability. Also, simultaneous-open is prioritized higher than 419 active and passive candidates for NAT-assisted and server reflexive 420 candidates since if TCP S-O is supported by the operating systems of 421 both endpoints, it should work at least as well as the act-pass 422 approach. If an implementation is uncertain whether S-O candidates 423 are supported, it may be reasonable to prioritize them lower. For 424 host, UDP-tunneled, and relayed candidates the S-O candidates are 425 prioritized lower than active and passive since act-pass candidates 426 should work with them at least as well as the S-O candidates. 428 If any two candidates have the same type-preference, transport-pref, 429 and class-pref, they MUST have a unique other-pref. With this 430 specification, this usually only happens with multi-homed hosts, in 431 which case other-pref is a preference amongst interfaces. 433 4.3. Choosing Default Candidates 435 The default candidate is chosen primarily based on the likelihood of 436 it working with a non-ICE peer. When media streams supporting mixed 437 modes (both TCP and UDP) are used with ICE, it is RECOMMENDED that, 438 for real-time streams (such as RTP), the default candidates be UDP- 439 based. However, the default SHOULD NOT be a simultaneous-open 440 candidate. 442 If a media stream is inherently TCP-based, the agent MUST select the 443 active candidate as default. This ensures proper directionality of 444 connection establishment for NAT traversal with non-ICE 445 implementations. 447 4.4. Encoding the SDP 449 TCP-based candidates are encoded into a=candidate lines identically 450 to the UDP encoding described in [RFC5245]. However, the transport 451 protocol (i.e., value of the transport-extension token defined in 452 [RFC5245] Section 15.1) is set to "tcp-so" for TCP simultaneous-open 453 candidates, "tcp-act" for TCP active candidates, and "tcp-pass" for 454 TCP passive candidates. The addr and port encoded into the candidate 455 attribute for active candidates MUST be set to IP address that will 456 be used for the attempt, but the port MUST be set to 9 (i.e., 457 Discard). For active relayed candidates, the value for addr must be 458 identical to the IP address of a passive or simultaneous-open 459 candidate from the same relay server. 461 If the default candidate is TCP, the agent MUST include the a=setup 462 and a=connection attributes from RFC 4145 [RFC4145], following the 463 procedures defined there as if ICE was not in use. In particular, if 464 an agent is the answerer, the a=setup attribute MUST meet the 465 constraints in RFC 4145 based on the value in the offer. Since an 466 ICE ICE offerer always uses the active candidate as default, an ICE 467 ICE answerer will always use the passive attribute as default and 468 include the a=setup:passive attribute in the answer. 470 If an agent is utilizing SRTP [RFC3711], it MAY include a mix of UDP 471 and TCP candidates. If ICE selects a TCP candidate pair, the agent 472 MUST still utilize SRTP, but run it over the connection established 473 by ICE. The alternative, RTP over TLS, MUST NOT be used. This 474 allows for the higher layer protocols (the security handshakes and 475 media transport) to be independent of the underlying transport 476 protocol. In the case of DTLS-SRTP [RFC5764], the directionality 477 attributes (a=setup) are utilized strictly to determine the direction 478 of the DTLS handshake. Directionality of the TCP connection 479 establishment are determined by the ICE attributes and procedures 480 defined here. 482 If an agent is securing non-RTP media over TCP/TLS, the SDP MUST be 483 constructed as described in RFC 4572 [RFC4572]. The directionality 484 attributes (a=setup) are utilized strictly to determine the direction 485 of the TLS handshake. Directionality of the TCP connection 486 establishment are determined by the ICE attributes and procedures 487 defined here. 489 5. Candidate Collection Techniques 491 The following sections discuss a number of techniques that can be 492 used to obtain candidates for use with ICE TCP. It is important to 493 note that this list is not intended to be exhaustive, nor is 494 implementation of any specific technique beyond Host Candidates 495 (Section 5.1) considered mandatory. 497 Implementors are encouraged to implement as many of the following 498 techniques from the following list as is practical, as well as to 499 explore additional NAT-traversal techniques beyond those discussed in 500 this document. However, to get a reasonable success ratio, one 501 SHOULD implement at least one relayed technique (e.g., TURN) and one 502 technique for discovering the address given for the host by a NAT 503 (e.g., STUN). 505 To increase the success probability with the techniques described 506 below and to aid with transition to IPv6, implementors SHOULD take 507 particular care to include both IPv4 and IPv6 candidates as part of 508 the process of gathering candidates. If the local network or host 509 does not support IPv6 addressing, then clients SHOULD make use of 510 other techniques, e.g., Teredo [RFC4380] or SOCKS IPv4-IPv6 511 gatewaying [RFC3089], for obtaining IPv6 candidates. 513 While implementations SHOULD support as many techniques as feasible, 514 they SHOULD also consider which of them to use if multiple options 515 are available. Since different candidates are paired with each 516 other, offering a large amount of candidates results in a large 517 checklist and potentially long lasting connectivity checks. For 518 example, using multiple NAT-assisted techniques with the same NAT 519 usually results only in redundant candidates and similarly out of 520 multiple different UDP tunneling or relaying techniques with similar 521 features using just one is often enough. 523 5.1. Host Candidates 525 Host candidates are the most simple candidates since they only 526 require opening TCP sockets on one the host's interfaces and sending/ 527 receiving connectivity checks from them. However, if the hosts are 528 behind different NATs, host candidates usually fail to work. On the 529 other hand, if there are no NATs between the hosts, host candidates 530 are the most efficient method since they require no additional NAT 531 traversal protocols or techniques. 533 For each TCP capable media stream the agent wishes to use (including 534 ones, like RTP, which can either be UDP or TCP), the agent SHOULD 535 obtain two host candidates (each on a different port) for each 536 component of the media stream on each interface that the host has - 537 one for the simultaneous-open, and one for the passive candidate. If 538 an agent is not capable of acting in one of these modes it would omit 539 those candidates. 541 5.2. Server Reflexive Candidates 543 Server reflexive techniques aim to discover the address a NAT has 544 given for the host by asking that from a server on the other side of 545 the NAT and then creating proper bindings (unless such already exist) 546 on the NATs with connectivity checks sent between the hosts. Success 547 of these techniques depends on the NATs' mapping and filtering 548 behavior [RFC5382] and also whether the NATs and hosts support TCP 549 simultaneous-open technique. 551 A widely used protocol for obtaining server reflexive candidates is 552 STUN, whose TCP specific behavior is described in [RFC5389] Section 553 7.2.2. 555 5.3. NAT-Assisted Candidates 557 NAT-assisted techniques communicate with the NATs directly and this 558 way discover the address NAT has given to the host and also create 559 proper bindings on the NATs. The benefit of these techniques over 560 the server reflexive techniques is that the NATs can adjust their 561 mapping and filtering behavior so that connections can be 562 successfully created. A downside of NAT-assisted techniques is that 563 they commonly allow communicating only with a NAT that is in the same 564 subnet as the host and thus often fail in scenarios with multiple 565 layers of NATs. These techniques also rely on NATs supporting the 566 specific protocols and that the NATs allow the users to modify their 567 behavior. 569 These candidates are encoded in the ICE offer and answer like the 570 server reflexive candidates but they (commonly) use a higher priority 571 (as described in Section 4.2) and hence are tested before the server 572 reflexive candidates. 574 Currently, the UPnP forum's Internet Gateway Device (IGD) protocol 575 [UPnP-IGD] and the NAT Port Mapping Protocol (PMP) 576 [I-D.cheshire-nat-pmp] are widely supported NAT-assisted techniques. 577 Other known protocols include SOCKS [RFC1928], Realm Specific IP 578 (RSIP) [RFC3103], and SIMCO [RFC4540]. Also, MIDCOM MIB [RFC5190] 579 defines an SNMP-based mechanism for controlling NATs. 581 5.4. UDP-Tunneled Candidates 583 UDP-tunneled NAT traversal techniques utilize the fact that UDP NAT 584 traversal is simpler and more efficient than TCP NAT traversal. With 585 these techniques, the TCP packets (or possibly complete IP packets) 586 are encapsulated in UDP packets. Because of the encapsulation these 587 techniques increase the overhead for the connection and may require 588 support from both of the endpoints, but on the other hand UDP 589 tunneling commonly results in reliable and fairly simple TCP NAT 590 traversal. 592 UDP-tunneled candidates can be encoded in the ICE offer and answer 593 either as relayed or server reflexive candidates, depending on 594 whether the tunneling protocol utilizes a relay between the hosts. 596 For example, the Teredo protocol [RFC4380] provides automatic UDP 597 tunneling and IPv6 interworking. The Teredo UDP tunnel is visible to 598 the host application as an IPv6 address and thus Teredo candidates 599 are encoded as IPv6 addresses. 601 5.5. Relayed Candidates 603 Relaying packets through a relay server is often the NAT traversal 604 technique that has the highest success probability: communicating via 605 a relay that is in the public Internet looks like normal client- 606 server communication for the NATs and that is supported in practice 607 by all existing NATs, regardless of their filtering and mapping 608 behavior. However, using a relay has several drawbacks, e.g., it 609 usually results in a sub-optimal path for the packets, the relay 610 needs to exist and it needs to be discovered, the relay is a possible 611 single point of failure, relaying consumes potentially a lot of 612 resources of the relay server, etc. Therefore, relaying is often 613 used as the last resort when no direct path can be created with other 614 NAT traversal techniques. 616 With relayed candidates the host commonly needs to obtain only a 617 passive candidate since any of the peer's server reflexive (and NAT- 618 assisted if the peer can communicate with the outermost NAT) active 619 candidates should work with the passive relayed candidate. However, 620 if the relay is behind a NAT or a firewall, using also active and S-O 621 candidates will increase success probability. 623 Relaying protocols capable of relaying TCP connections include TURN 624 TCP [I-D.ietf-behave-turn-tcp] and SOCKS [RFC1928] (which can also be 625 used for IPv4-IPv6 gatewaying [RFC3089]). It is also possible to 626 use, e.g., an SSH [RFC4250] tunnel as a relayed candidate if a 627 suitable server is available and the server permits this. 629 6. Receiving the Initial Offer 631 6.1. Verifying ICE Support 633 Since this specification does not define a lite mode for ICE TCP, a 634 lite implementation will include candidate attributes for its UDP 635 streams, but no such attributes for its TCP streams. An agent 636 receiving such an offer MUST proceed with ICE in this case. ICE will 637 be used for the UDP streams, and [RFC4145] procedures will be used 638 for the TCP streams. However, if the offer indicates a setup 639 direction of actpass, the answerer MUST utilize a=setup:active in the 640 answer. This is required to ensure proper directionality of 641 connection establishment to work through NAT. 643 Similarly, if an agent is lite, and receives an offer that includes 644 streams with TCP candidates, it will omit candidates from the answer 645 for those streams. This will cause [RFC4145] procedures to be used 646 for those streams. In this case, the offer will indicate a direction 647 of active, and the agent will use passive in its answer. 649 6.2. Forming the Check Lists 651 When forming candidate pairs, the following types of candidates can 652 be paired with each other: 654 Local Remote 655 Candidate Candidate 656 ---------------------------- 657 tcp-so tcp-so 658 tcp-act tcp-pass 659 tcp-pass tcp-act 661 When the agent prunes the check list, it MUST also remove any pair 662 for which the local candidate is tcp-pass. Also NAT-assisted 663 candidates MUST be pruned from the check list like server reflexive 664 candidates when the same address is used also as an active host 665 candidate. 667 The remainder of check list processing works like in the UDP case. 669 7. Connectivity Checks 671 7.1. STUN Client Procedures 673 7.1.1. Sending the Request 675 When an agent wants to send a TCP-based connectivity check, it first 676 opens a TCP connection if none yet exists for the 5-tuple defined by 677 the candidate pair for which the check is to be sent. This 678 connection is opened from the local candidate of the pair to the 679 remote candidate of the pair. If the local candidate is tcp-act, the 680 agent MUST open a connection from the interface associated with that 681 local candidate. This connection MUST be opened from an unallocated 682 port. For host candidates, this is readily done by connecting from 683 the candidates interface. For relayed candidates, the agent uses 684 procedures specific to the relaying protocol. 686 Once the connection is established, the agent MUST utilize the shim 687 defined in RFC 4571 [RFC4571] for the duration this connection 688 remains open. The STUN Binding requests and responses are sent on 689 top of this shim, so that the length field defined in RFC 4571 690 precedes each STUN message. If TLS or DTLS-SRTP is to be utilized 691 for the media session, the TLS or DTLS-SRTP handshakes will take 692 place on top of this shim as well. However, they only start once ICE 693 processing has completed. In essence, the TLS or DTLS-SRTP 694 handshakes are considered a part of the media protocol. STUN is 695 never run within the TLS or DTLS-SRTP session. 697 If the TCP connection cannot be established, the check is considered 698 to have failed, and a full-mode agent MUST update the pair state to 699 Failed in the check list. 701 Once the connection is established, client procedures are identical 702 to those for UDP candidates. Note that STUN responses received on an 703 active TCP candidate will typically produce a remote peer reflexive 704 candidate. 706 7.2. STUN Server Procedures 708 An agent MUST be prepared to receive incoming TCP connection requests 709 on any host, relayed, or UDP-tunneled TCP candidate that is 710 simultaneous-open or passive. When the connection request is 711 received, the agent MUST accept it. The agent MUST utilize the 712 framing defined in RFC 4571 [RFC4571] for the lifetime of this 713 connection. Due to this framing, the agent will receive data in 714 discrete frames. Each frame could be media (such as RTP or SRTP), 715 TLS, DTLS, or STUN packets. The STUN packets are extracted as 716 described in Section 10.2. 718 Once the connection is established, STUN server procedures are 719 identical to those for UDP candidates. Note that STUN requests 720 received on a passive TCP candidate will typically produce a remote 721 peer reflexive candidate. 723 8. Concluding ICE Processing 725 If there are TCP candidates for a media stream, a controlling agent 726 MUST use a regular selection algorithm. 728 When ICE processing for a media stream completes, each agent SHOULD 729 close all TCP connections except the ones between the candidate pairs 730 selected by ICE. 732 These two rules are related; the closure of connection on 733 completion of ICE implies that a regular selection algorithm has 734 to be used. This is because aggressive selection might cause 735 transient pairs to be selected. Once such a pair was selected, 736 the agents would close the other connections, one of which may be 737 about to be selected as a better choice. This race condition may 738 result in TCP connections being accidentally closed for the pair 739 that ICE selects. 741 9. Subsequent Offer/Answer Exchanges 743 9.1. ICE Restarts 745 If an ICE restart occurs for a media stream with TCP candidate pairs 746 that have been selected by ICE, the agents MUST NOT close the 747 connections after the restart. In the offer or answer that causes 748 the restart, an agent MAY include a simultaneous-open candidate whose 749 transport address matches the previously selected candidate. If both 750 agents do this, the result will be a simultaneous-open candidate pair 751 matching an existing TCP connection. In this case, the agents MUST 752 NOT attempt to open a new connection (or start new TLS or DTLS-SRTP 753 procedures). Instead, that existing connection is reused and STUN 754 checks are performed. 756 Once the restart completes, if the selected pair does not match the 757 previously selected pair, the TCP connection for the previously 758 selected pair SHOULD be closed by the agent. 760 10. Media Handling 762 10.1. Sending Media 764 When sending media, if the selected candidate pair matches an 765 existing TCP connection, that connection MUST be used for sending 766 media. 768 The framing defined in RFC 4571 MUST be used when sending media. For 769 media streams that are not RTP-based and do not normally use RFC 770 4571, the agent treats the media stream as a byte stream, and assumes 771 that it has its own framing of some sort. It then takes an arbitrary 772 number of bytes from the byte stream, and places that as a payload in 773 the RFC 4571 frames, including the length. Next, the sender checks 774 to see if the resulting set of bytes would be viewed as a STUN packet 775 based on the rules in Sections 6 and 8 of [RFC5389]. This includes a 776 check on the most significant two bits, the magic cookie, the length, 777 and the fingerprint. If, based on those rules, the bytes would be 778 viewed as a STUN message, the sender SHOULD utilize a different 779 number of bytes so that the length checks will fail. Though it is 780 normally highly unlikely that an arbitrary number of bytes from a 781 byte stream would resemble a STUN packet based on all of the checks, 782 it can happen if the content of the application stream happens to 783 contain a STUN message (for example, a file transfer of logs from a 784 client which includes STUN messages). 786 If TLS or DTLS-SRTP procedures are being utilized to protect the 787 media stream, those procedures start at the point that media is 788 permitted to flow, as defined in the ICE specification [RFC5245]. 789 The TLS or DTLS-SRTP handshakes occur on top of the RFC 4571 shim, 790 and are considered part of the media stream for purposes of this 791 specification. 793 10.2. Receiving Media 795 The framing defined in RFC 4571 MUST be used when receiving media. 796 For media streams that are not RTP-based and do not normally use RFC 797 4571, the agent extracts the payload of each RFC 4571 frame, and 798 determines if it is a STUN or an application layer data based on the 799 procedures in ICE [RFC5245]. If media is being protected with DTLS- 800 SRTP, the DTLS, RTP and STUN packets are demultiplexed as described 801 in Section 5.1.2 [RFC5764]. 803 For non-STUN data, the agent appends this to the ongoing byte stream 804 collected from the frames. It then parses the byte stream as if it 805 had been directly received over the TCP connection. This allows for 806 ICE TCP to work without regard to the framing mechanism used by the 807 application layer protocol. 809 11. Connection Management 811 11.1. Connections Formed During Connectivity Checks 813 Once a TCP or TCP/TLS connection is opened by ICE for the purpose of 814 connectivity checks, its life cycle depends on how it is used. If 815 that candidate pair is selected by ICE for usage for media, an agent 816 SHOULD keep the connection open until: 818 o The session terminates 820 o The media stream is removed 821 o An ICE restart takes place, resulting in the selection of a 822 different candidate pair. 824 In these cases, the agent SHOULD close the connection when that event 825 occurs. This applies to both agents in a session, in which case 826 usually one of the agents will end up closing the connection first. 828 If a connection has been selected by ICE, an agent MAY close it 829 anyway. As described in the next paragraph, this will cause it to be 830 reopened almost immediately, and in the interim media cannot be sent. 831 Consequently, such closures have a negative effect and are NOT 832 RECOMMENDED. However, there may be cases where an agent needs to 833 close a connection for some reason. 835 If an agent needs to send media on the selected candidate pair, and 836 its TCP connection has closed, either on purpose or due to some 837 error, then: 839 o If the agent's local candidate is tcp-act or tcp-so, it MUST 840 reopen a connection to the remote candidate of the selected pair. 842 o If the agent's local candidate is tcp-pass, the agent MUST await 843 an incoming connection request, and consequently, will not be able 844 to send media until it has been opened. 846 If the TCP connection is established, the framing of RFC 4571 is 847 utilized. If the agent opened the connection, it MUST send a STUN 848 connectivity check. An agent MUST be prepared to receive a 849 connectivity check over a connection it opened or accepted (note that 850 this is true in general; ICE requires that an agent be prepared to 851 receive a connectivity check at any time, even after ICE processing 852 completes). If an agent receives a connectivity check after re- 853 establishment of the connection, it MUST generate a triggered check 854 over that connection in response if it has not already sent a check. 855 Once an agent has sent a check and received a successful response, 856 the connection is considered Valid and media can be sent (which 857 includes a TLS or DTLS-SRTP session resumption or restart). 859 If the TCP connection cannot be established, the controlling agent 860 SHOULD restart ICE for this media stream. This will happen in cases 861 where one of the agents is behind a NAT with connection dependent 862 mapping properties [RFC5382]. 864 11.2. Connections Formed for Gathering Candidates 866 If the agent opened a connection to a STUN server, or another similar 867 server, for the purposes of gathering a server reflexive candidate, 868 that connection SHOULD be closed by the client once ICE processing 869 has completed. This happens irregardless of whether the candidate 870 learned from the server was selected by ICE. 872 If the agent opened a connection to a TURN server for the purposes of 873 gathering a relayed candidate, that connection MUST be kept open by 874 the client for the duration of the media session if a relayed 875 candidate from the TURN server was selected by ICE. Otherwise, the 876 connection to the TURN server SHOULD be closed once ICE processing 877 completes. 879 If, despite efforts of the client, a TCP connection to a TURN server 880 fails during the lifetime of the media session utilizing a transport 881 address allocated by that server, the client SHOULD reconnect to the 882 TURN server, obtain a new allocation, and restart ICE for that media 883 stream. Similar measures SHOULD apply also to other type of relaying 884 servers. 886 12. Security Considerations 888 The main threat in ICE is hijacking of connections for the purposes 889 of directing media streams to DoS targets or to malicious users. ICE 890 TCP prevents that by only using TCP connections that have been 891 validated. Validation requires a STUN transaction to take place over 892 the connection. This transaction cannot complete without both 893 participants knowing a shared secret exchanged in the rendezvous 894 protocol used with ICE, such as SIP [RFC3261]. This shared secret, 895 in turn, is protected by that protocol exchange. In the case of SIP, 896 the usage of the sips mechanism is RECOMMENDED. When this is done, 897 an attacker, even if it knows or can guess the port on which an agent 898 is listening for incoming TCP connections, will not be able to open a 899 connection and send media to the agent. 901 A more detailed analysis of this attack and the various ways ICE 902 prevents it are described in [RFC5245]. Those considerations apply 903 to this specification. 905 13. IANA Considerations 907 There are no IANA considerations associated with this specification. 909 14. Acknowledgements 911 The authors would like to thank Tim Moore, Saikat Guha, Francois 912 Audet, Roni Even, Simon Perreault, and Alfred Heggestad for the 913 reviews and input on this document. 915 15. References 917 15.1. Normative References 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, March 1997. 922 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 923 with Session Description Protocol (SDP)", RFC 3264, 924 June 2002. 926 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 927 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 928 RFC 3711, March 2004. 930 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 931 the Session Description Protocol (SDP)", RFC 4145, 932 September 2005. 934 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 935 and RTP Control Protocol (RTCP) Packets over Connection- 936 Oriented Transport", RFC 4571, July 2006. 938 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 939 Transport Layer Security (TLS) Protocol in the Session 940 Description Protocol (SDP)", RFC 4572, July 2006. 942 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 943 (ICE): A Protocol for Network Address Translator (NAT) 944 Traversal for Offer/Answer Protocols", RFC 5245, 945 April 2010. 947 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 948 Security (DTLS) Extension to Establish Keys for the Secure 949 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 951 15.2. Informative References 953 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 954 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 955 March 1996. 957 [RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", 958 RFC 3089, April 2001. 960 [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, 961 "Realm Specific IP: Protocol Specification", RFC 3103, 962 October 2001. 964 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 965 A., Peterson, J., Sparks, R., Handley, M., and E. 966 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 967 June 2002. 969 [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) 970 Protocol Assigned Numbers", RFC 4250, January 2006. 972 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 973 Network Address Translations (NATs)", RFC 4380, 974 February 2006. 976 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 977 Middlebox Configuration (SIMCO) Protocol Version 3.0", 978 RFC 4540, May 2006. 980 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 981 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 983 [RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh, 984 "Definitions of Managed Objects for Middlebox 985 Communication", RFC 5190, March 2008. 987 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 988 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 989 RFC 5382, October 2008. 991 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 992 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 993 October 2008. 995 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 996 Relays around NAT (TURN): Relay Extensions to Session 997 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 999 [I-D.ietf-behave-turn-tcp] 1000 Perreault, S. and J. Rosenberg, "Traversal Using Relays 1001 around NAT (TURN) Extensions for TCP Allocations", 1002 draft-ietf-behave-turn-tcp-07 (work in progress), 1003 July 2010. 1005 [I-D.cheshire-nat-pmp] 1006 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1007 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1009 [UPnP-IGD] 1010 Warrier, U., Iyer, P., Pennerath, F., Marynissen, G., 1011 Schmitz, M., Siddiqi, W., and M. Blaszczak, "Internet 1012 Gateway Device (IGD) Standardized Device Control Protocol 1013 V 1.0", November 2001. 1015 [IMC05] Guha, S. and P. Francis, "Characterization and Measurement 1016 of TCP Traversal through NATs and Firewalls", Proceedings 1017 of the 5th ACM SIGCOMM conference on Internet Measurement, 1018 2005. 1020 Appendix A. Limitations of ICE TCP 1022 Compared to UDP-based ICE, ICE TCP has in general lower success 1023 probability for enabling connectivity without a relay if both of the 1024 hosts are behind a NAT. This happens because many of the currently 1025 deployed NATs have endpoint dependent mapping behavior or they do not 1026 support the flow of TCP hand shake packets seen in case of TCP 1027 simultaneous-open: e.g., some NATs do not allow incoming TCP SYN 1028 packets from an address where a SYN packet has been sent to recently 1029 or the subsequent SYNACK is not processed properly. 1031 It has been reported in [IMC05] that with the population of NATs 1032 deployed at the time of the measurements (2005), simultaneous-open 1033 technique worked in roughly 45% of the cases. Also, all operating 1034 systems do not implement TCP simultaneous-open properly and thus are 1035 not able to use such candidates. 1037 Alternatively, using unidirectional opens (where one side is active 1038 and the other is passive) is more reliable, but will commonly require 1039 a relay if both sides are behind different NATs. Therefore, in the 1040 spirit of the ICE philosophy, both simultaneous-open and 1041 unidirectional candidates are tried. Simultaneous-opens are 1042 preferred since, if it does work, it will not require a relay even 1043 when both sides are behind a different NAT. Also, if/when more NATs 1044 comply with the requirements set by [RFC5382] and operating system 1045 TCP stacks are fixed, the success probability of simultaneous-open is 1046 likely to increase. 1048 Finally, implementing various techniques listed in Section 5 should 1049 increase the success probability, but many of these techniques 1050 require support from the endpoints and/or from some network elements 1051 (e.g., from the NATs). Without comprehensive experimental data on 1052 how well different techniques are supported the actual increase of 1053 success probability is hard to evaluate. 1055 Appendix B. Implementation Considerations for BSD Sockets 1057 This specification requires unusual handling of TCP connections, the 1058 implementation of which in traditional BSD socket APIs is non- 1059 trivial. 1061 In particular, ICE requires an agent to obtain a local TCP candidate, 1062 bound to a local IP and port, and then from that local port, initiate 1063 a TCP connection (e.g., to the STUN server, in order to obtain server 1064 reflexive candidates, to the TURN server, to obtain a relayed 1065 candidate, or to the peer as part of a connectivity check), and be 1066 prepared to receive incoming TCP connections (for passive and 1067 simultaneous-open candidates). A "typical" BSD socket is used either 1068 for initiating or receiving connections, and not for both. The code 1069 required to allow incoming and outgoing connections on the same local 1070 IP and port is non-obvious. The following pseudocode, contributed by 1071 Saikat Guha, has been found to work on many platforms: 1073 for i in 0 to MAX 1074 sock_i = socket() 1075 set(sock_i, SO_REUSEADDR) 1076 bind(sock_i, local) 1078 listen(sock_0) 1079 connect(sock_1, stun) 1080 connect(sock_2, remote_a) 1081 connect(sock_3, remote_b) 1083 The key here is that, prior to the listen() call, the full set of 1084 sockets that need to be utilized for outgoing connections must be 1085 allocated and bound to the local IP address and port. This number, 1086 MAX, represents the maximum number of TCP connections to different 1087 destinations that might need to be established from the same local 1088 candidate. This number can be potentially large for simultaneous- 1089 open candidates. If a request forks, ICE procedures may take place 1090 with multiple peers. Furthermore, for each peer, connections would 1091 need to be established to each passive or simultaneous-open candidate 1092 for the same component. If we assume a worst case of 5 forked 1093 branches, and for each peer, five simultaneous-open candidates, that 1094 results in MAX=25. 1096 Authors' Addresses 1098 Jonathan Rosenberg 1099 Skype 1101 Email: jdrosen@jdrosen.net 1102 URI: http://www.jdrosen.net 1103 Ari Keranen 1104 Ericsson 1105 Hirsalantie 11 1106 02420 Jorvas 1107 Finland 1109 Email: ari.keranen@ericsson.com 1111 Bruce B. Lowekamp 1112 Skype 1114 Email: bbl@lowekamp.net 1116 Adam Roach 1117 Tekelec 1118 17210 Campbell Rd. 1119 Suite 250 1120 Dallas, TX 75252 1121 US 1123 Email: adam@nostrum.com