idnits 2.17.1 draft-ietf-mmusic-ice-tcp-16.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 : ---------------------------------------------------------------------------- == There are 12 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 15, 2011) is 4539 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 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6156 (Obsoleted by RFC 8656) == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-17 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 Summary: 5 errors (**), 0 flaws (~~), 4 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 18, 2012 Ericsson 6 B. Lowekamp 7 Skype 8 A. Roach 9 Tekelec 10 November 15, 2011 12 TCP Candidates with Interactive Connectivity Establishment (ICE) 13 draft-ietf-mmusic-ice-tcp-16 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 media streams. 24 This specification extends ICE to TCP-based media, including the 25 ability to offer a mix of TCP and UDP-based candidates for a single 26 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 18, 2012. 45 Copyright Notice 47 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . 8 80 4.3. Choosing Default Candidates . . . . . . . . . . . . . . . 10 81 4.4. Lite Implementation Requirements . . . . . . . . . . . . . 10 82 4.5. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 11 83 5. Candidate Collection Techniques . . . . . . . . . . . . . . . 12 84 5.1. Host Candidates . . . . . . . . . . . . . . . . . . . . . 13 85 5.2. Server Reflexive Candidates . . . . . . . . . . . . . . . 13 86 5.3. NAT-Assisted Candidates . . . . . . . . . . . . . . . . . 14 87 5.4. UDP-Tunneled Candidates . . . . . . . . . . . . . . . . . 14 88 5.5. Relayed Candidates . . . . . . . . . . . . . . . . . . . . 15 89 6. Receiving the Initial Offer and Answer . . . . . . . . . . . . 15 90 6.1. Considerations with Two Lite Agents . . . . . . . . . . . 16 91 6.2. Forming the Check Lists . . . . . . . . . . . . . . . . . 16 92 7. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 17 93 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . . 17 94 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . . 18 95 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 18 96 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 18 97 9.1. Updated Offer . . . . . . . . . . . . . . . . . . . . . . 18 98 9.2. ICE Restarts . . . . . . . . . . . . . . . . . . . . . . . 19 99 10. Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 19 100 10.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 19 101 10.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 20 102 11. Connection Management . . . . . . . . . . . . . . . . . . . . 20 103 11.1. Connections Formed During Connectivity Checks . . . . . . 20 104 11.2. Connections Formed for Gathering Candidates . . . . . . . 21 105 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 106 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 107 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 108 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 15.1. Normative References . . . . . . . . . . . . . . . . . . . 23 110 15.2. Informative References . . . . . . . . . . . . . . . . . . 24 111 Appendix A. Limitations of ICE TCP . . . . . . . . . . . . . . . 26 112 Appendix B. Implementation Considerations for BSD Sockets . . . . 26 113 Appendix C. SDP Examples . . . . . . . . . . . . . . . . . . . . 27 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 116 1. Introduction 118 Interactive Connectivity Establishment (ICE) [RFC5245] defines a 119 mechanism for NAT traversal for multimedia communication protocols 120 based on the offer/answer model [RFC3264] of session negotiation. 121 ICE works by providing a set of candidate transport addresses for 122 each media stream, which are then validated with peer-to-peer 123 connectivity checks based on Session Traversal Utilities for NAT 124 (STUN) [RFC5389]. However, ICE only defines procedures for UDP-based 125 transport protocols. 127 There are many reasons why ICE support for TCP is important. 128 Firstly, there are media protocols that only run over TCP. Such 129 protocols are used, for example, for screen sharing and instant 130 messaging [RFC4975]. For these protocols to work in the presence of 131 NAT, unless they define their own NAT traversal mechanisms, ICE 132 support for TCP is needed. In addition, RTP can also run over TCP 133 [RFC4571]. Typically, it is preferable to run RTP over UDP, and not 134 TCP. However, in a variety of network environments, overly 135 restrictive NAT and firewall devices prevent UDP-based communications 136 altogether, but general TCP-based communications are permitted. In 137 such environments, sending RTP over TCP, and thus establishing the 138 media session, may be preferable to having it fail altogether. With 139 this specification, agents can gather UDP and TCP candidates for a 140 media stream, list the UDP ones with higher priority, and then only 141 use the TCP-based ones if the UDP ones fail. This provides a 142 fallback mechanism that allows multimedia communications to be highly 143 reliable. 145 The usage of RTP over TCP is particularly useful when combined with 146 Traversal Using Relays around NAT (TURN) [RFC5766]. In this case, 147 one of the agents would connect to its TURN server using TCP, and 148 obtain a TCP-based relayed candidate. It would offer this to its 149 peer agent as a candidate. The other agent would initiate a TCP 150 connection towards the TURN server. When that connection is 151 established, media can flow over the connections, through the TURN 152 server. The benefit of this usage is that it only requires the 153 agents to make outbound TCP connections to a server on the public 154 network. This kind of operation is broadly interoperable through NAT 155 and firewall devices. Since it is a goal of ICE and this extension 156 to provide highly reliable communications that "just works" in as 157 broad set of network deployments as possible, this use case is 158 particularly important. 160 This specification extends ICE by defining its usage with TCP 161 candidates. It also defines how ICE can be used with RTP and Secure 162 RTP (SRTP) to provide both TCP and UDP candidates. This 163 specification does so by following the outline of ICE itself, and 164 calling out the additions and changes to support TCP candidates in 165 ICE. The base behavior of ICE [RFC5245] remains unchanged except for 166 the extensions in this document that define the usage of ICE with TCP 167 candidates. 169 It should be noted that since TCP NAT traversal is more complicated 170 than with UDP, ICE TCP is not in general as efficient as UDP-based 171 ICE. Discussion about this topic can be found in Appendix A. 173 2. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in RFC 178 2119 [RFC2119]. 180 This document uses the same terminology as ICE (see Section 3 of 181 [RFC5245]). 183 3. Overview of Operation 185 The usage of ICE with TCP is relatively straightforward. The main 186 area of specification is around how and when connections are opened, 187 and how those connections relate to candidate pairs. 189 When the agents perform address allocations to gather TCP-based 190 candidates, three types of candidates can be obtained. These are 191 active candidates, passive candidates, and simultaneous-open (S-O) 192 candidates. An active candidate is one for which the agent will 193 attempt to open an outbound connection, but will not receive incoming 194 connection requests. A passive candidate is one for which the agent 195 will receive incoming connection attempts, but not attempt a 196 connection. S-O candidate is one for which the agent will attempt to 197 open a connection simultaneously with its peer. 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 (see 203 Section 5). Connections to servers used for relayed and server 204 reflexive 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, both IP 208 address and port are present, but the port is meaningless (it is 209 there only for making encoding of active candidates consistent with 210 the other candidate types and is ignored by the peer). As a 211 consequence, active candidates do not need to be physically allocated 212 at the time of address gathering. Rather, the physical allocations, 213 which occur as a consequence of a connection attempt, occur at the 214 time of the connectivity checks. 216 When the candidates are paired together, active candidates are always 217 paired with passive, and S-O candidates with each other. When a 218 connectivity check is to be made on a candidate pair, each agent 219 determines whether it is to make a connection attempt for this pair. 221 The actual process of generating connectivity checks, managing the 222 state of the check list, and updating the Valid list, work 223 identically for TCP as they do for UDP. 225 ICE requires an agent to demultiplex STUN and application layer 226 traffic, since they appear on the same port. This demultiplexing is 227 described in [RFC5245], and is done using the magic cookie and other 228 fields of the message. Stream-oriented transports introduce another 229 wrinkle, since they require a way to frame the connection so that the 230 application and STUN packets can be extracted in order to determine 231 STUN packets from application layer traffic. For this reason, TCP 232 media streams utilizing ICE use the basic framing provided in RFC 233 4571 [RFC4571], even if the application layer protocol is not RTP. 235 When TLS or DTLS is used, they are also run over the RFC 4571 framing 236 shim, while STUN runs outside of the (D)TLS connection. The 237 resulting ICE TCP protocol stack is shown in Figure 1; with (D)TLS on 238 the left side and without it on the right side. 240 +----------+ 241 | | 242 | App | 243 +----------+----------+ +----------+----------+ 244 | | | | | | 245 | STUN | (D)TLS | | STUN | App | 246 +----------+----------+ +----------+----------+ 247 | | | | 248 | RFC 4571 | | RFC 4571 | 249 +---------------------+ +---------------------+ 250 | | | | 251 | TCP | | TCP | 252 +---------------------+ +---------------------+ 253 | | | | 254 | IP | | IP | 255 +---------------------+ +---------------------+ 257 Figure 1: ICE TCP Stack With and Without (D)TLS 259 The implication of this is that, for any media stream protected by 260 (D)TLS, the agent will first run ICE procedures, exchanging STUN 261 messages. Then, once ICE completes, (D)TLS procedures begin. ICE 262 and (D)TLS are thus "peers" in the protocol stack. The STUN messages 263 are not sent over the (D)TLS connection, even ones sent for the 264 purposes of keepalive in the middle of the media session. 266 4. Sending the Initial Offer 268 For offerers making use of ICE for TCP streams, the procedures below 269 are used. Main differences compared to UDP candidates are the new 270 methods for gathering candidates, how TCP candidates are prioritized, 271 and how they are encoded in the Session Description Protocol (SDP) 272 offer and answer. 274 4.1. Gathering Candidates 276 Providers of real-time communications services may decide that it is 277 preferable to have no media at all than it is to have media over TCP. 278 To allow for choice, it is RECOMMENDED that agents be configurable 279 with whether they obtain TCP candidates for real time media. 281 Having it be configurable, and then configuring it to be off, is 282 far better than not having the capability at all. An important 283 goal of this specification is to provide a single mechanism that 284 can be used across all types of endpoints. As such, it is 285 preferable to account for provider and network variation through 286 configuration, instead of hard-coded limitations in an 287 implementation. Besides, network characteristics and connectivity 288 assumptions can, and will change over time. Just because an agent 289 is communicating with a server on the public network today, 290 doesn't mean that it won't need to communicate with one behind a 291 NAT tomorrow. Just because an agent is behind a NAT with 292 endpoint-independent mapping today, doesn't mean that tomorrow 293 they won't pick up their agent and take it to a public network 294 access point where there is a NAT with address and port-dependent 295 mapping properties, or one that only allows outbound TCP. The way 296 to handle these cases and build a reliable system is for agents to 297 implement a diverse set of techniques for allocating addresses, so 298 that at least one of them is almost certainly going to work in any 299 situation. Implementors should consider very carefully any 300 assumptions made about deployments before electing not to 301 implement one of the mechanisms for address allocation. In 302 particular, implementors should consider whether the elements in 303 the system may be mobile, and connect through different networks 304 with different connectivity. They should also consider whether 305 endpoints which are under their control, in terms of location and 306 network connectivity, would always be under their control. In 307 environments where mobility and user control are possible, a 308 multiplicity of techniques is essential for reliability. 310 First, agents SHOULD obtain host candidates as described in 311 Section 5.1. Then, each agent SHOULD "obtain" (allocate a 312 placeholder for) an active host candidate for each component of each 313 TCP-capable media stream on each interface that the host has. The 314 agent does not have to yet actually allocate a port for these 315 candidates, but they are used for the creation of the check lists. 317 The agent SHOULD then obtain server reflexive, NAT-assisted, and/or 318 UDP-tunneled candidates (see Section 5.2, Section 5.3, and 319 Section 5.4). The mechanisms for establishing these candidates and 320 the number of candidates to collect vary from technique to technique. 321 These considerations are discussed in the relevant sections. 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 It is highly RECOMMENDED that a host obtains at least one set of host 329 and one set of relayed candidates. Obtaining additional candidates 330 will increase the chance of successfully creating a direct 331 connection. 333 Once the candidates have been obtained, the agent MUST keep the TCP 334 connections open until ICE processing has completed. See Appendix B 335 for important implementation guidelines. 337 If a media stream is UDP-based (such as RTP), an agent MAY use an 338 additional host TCP candidate to request a UDP-based candidate from a 339 TURN server (or some other relay with similar functionality). Usage 340 of such UDP candidates follows the procedures defined in ICE for UDP 341 candidates. 343 Like its UDP counterparts, TCP-based STUN transactions are paced out 344 at one every Ta milliseconds (see Section 16 of [RFC5245]). This 345 pacing refers strictly to STUN transactions (both Binding and 346 Allocate requests). If performance of the transaction requires 347 establishment of a TCP connection, then the connection gets opened 348 when the transaction is performed. 350 4.2. Prioritization 352 The transport protocol itself is a criteria for choosing one 353 candidate over another. If a particular media stream can run over 354 UDP or TCP, the UDP candidates might be preferred over the TCP 355 candidates. This allows ICE to use the lower latency UDP 356 connectivity if it exists, but fallback to TCP if UDP doesn't work. 358 In Section 4.1.2.1. of [RFC5245] a recommended formula for UDP ICE 359 candidate prioritization is defined. For the TCP candidates the same 360 formula and candidate type preferences SHOULD be used and the 361 RECOMMENDED type preferences for the new candidate types defined in 362 this document (see Section 5) are 105 for NAT-assisted candidates and 363 75 for UDP-tunneled candidates. 365 When both UDP and TCP candidates are offered for the same media 366 stream, and one transport protocol should be preferred over the 367 other, the type preferences for the preferred transport protocol 368 candidates SHOULD be increased and/or the type preferences for the 369 other transport protocol candidates SHOULD be decreased. How much 370 the values should be increased or decreased depends on whether it is 371 more important to choose certain transport protocol or certain 372 candidate type. If the candidate type is more important (e.g., even 373 if UDP is preferred, TCP host candidates are preferred over UDP 374 server reflexive candidates) changing type preference values by one 375 for the other transport protocol candidates is enough. On the other 376 hand, if the transport protocol is more important (e.g., any UDP 377 candidate is preferred over any TCP candidate) all the preferred 378 transport protocol candidates SHOULD have type preference higher than 379 the other transport protocol candidates. However, it is RECOMMENDED 380 that the relayed candidates are still preferred lower than the other 381 candidate types. For RTP-based media streams, it is RECOMMENDED that 382 UDP candidates are preferred over TCP candidates. 384 With TCP candidates the local preference part of the recommended 385 priority formula is updated to include also the directionality 386 (active, passive, or simultaneous-open) of the TCP connection. The 387 RECOMMENDED local preference is then defined as: 389 local preference = (2^13) * direction-pref + other-pref 391 The direction-pref MUST be between 0 and 7 (both inclusive), with 7 392 being the most preferred. The other-pref MUST be between 0 and 8191 393 (both inclusive), with 8191 being the most preferred. It is 394 RECOMMENDED that the host, UDP-tunneled, and relayed TCP candidates 395 have the direction-pref assigned as follows: 6 for active, 4 for 396 passive, and 2 for S-O. For the NAT-assisted and server reflexive 397 candidates the RECOMMENDED values are: 6 for S-O, 4 for active, and 2 398 for passive. 400 The preference priorities listed here are simply recommendations 401 that try to strike a balance between success probability and 402 resulting path's efficiency. Depending on the scenario where ICE 403 TCP is used, different values may be appropriate. For example, if 404 the overhead of a UDP tunnel is not an issue, those candidates 405 should be prioritized higher since they are likely to have a high 406 success probability. Also, simultaneous-open is prioritized 407 higher than active and passive candidates for NAT-assisted and 408 server reflexive candidates since if TCP S-O is supported by the 409 operating systems of both endpoints, it should work at least as 410 well as the active-passive approach. If an implementation is 411 uncertain whether S-O candidates are supported, it may be 412 reasonable to prioritize them lower. For host, UDP-tunneled, and 413 relayed candidates the S-O candidates are prioritized lower than 414 active and passive since active-passive candidates should work 415 with them at least as well as the S-O candidates. 417 If any two candidates have the same type-preference and direction- 418 pref, they MUST have a unique other-pref. With this specification, 419 this usually only happens with multi-homed hosts, in which case 420 other-pref is the preference for the particular IP address from which 421 the candidate was obtained. When there is only a single IP address, 422 this value SHOULD be set to the maximum allowed value (8191). 424 4.3. Choosing Default Candidates 426 The default candidate is chosen primarily based on the likelihood of 427 it working with a non-ICE peer. When media streams supporting mixed 428 modes (both TCP and UDP) are used with ICE, it is RECOMMENDED that, 429 for real-time streams (such as RTP), the default candidates be UDP- 430 based. However, the default SHOULD NOT be a simultaneous-open 431 candidate. 433 If a media stream is inherently TCP-based, it is RECOMMENDED for an 434 offering full agent to select an active candidate as the default 435 candidate and use [RFC4145] "setup" attribute value "active". This 436 increases the chances for a successful NAT traversal even without ICE 437 support if the agent is behind a NAT and the peer is not. For the 438 same reason, for a lite agent, it is RECOMMENDED to use a passive 439 candidate and "setup" attribute value "passive" in the offer. 441 4.4. Lite Implementation Requirements 443 If an offerer meets the criteria for the lite mode as described in 444 Appendix A of [RFC5245] (i.e., it will always have a public, globally 445 unique IP address), it MAY use the lite mode of ICE also for TCP 446 candidates. In the lite mode, for the TCP candidates, only passive 447 host candidates are gathered; unless active candidates are needed as 448 the default candidates. Otherwise the procedures described for lite 449 mode in [RFC5245] apply also to TCP candidates. If UDP and TCP 450 candidates are mixed in a media stream, the mode (lite or full) 451 applies to both UDP and TCP candidates. 453 4.5. Encoding the SDP 455 TCP-based candidates are encoded into a=candidate lines like the UDP 456 candidates described in [RFC5245]. However, the transport protocol 457 (i.e., value of the transport-extension token defined in [RFC5245] 458 Section 15.1) is set to "TCP" and the connection type (active, 459 passive, or S-O) is encoded using a new extension attribute. With 460 TCP candidates, the candidate-attribute syntax with Augmented BNF 461 [RFC5234] is then: 463 candidate-attribute = "candidate" ":" foundation SP component-id SP 464 "TCP" SP 465 priority SP 466 connection-address SP 467 port SP 468 cand-type 469 [SP rel-addr] 470 [SP rel-port] 471 SP tcp-type-ext 472 *(SP extension-att-name SP 473 extension-att-value) 475 tcp-type-ext = "tcptype" SP tcp-type 476 tcp-type = "active" / "passive" / "so" 478 The connection-address encoded into the candidate attribute for 479 active candidates MUST be set to the IP address that will be used for 480 the attempt, but the port(s) MUST be set to 9 (i.e., Discard). For 481 active relayed candidates, the value for connection-address MUST be 482 identical to the IP address of a passive or simultaneous-open 483 candidate from the same relay server. 485 If the default candidate is TCP-based, the agent MUST include the 486 a=setup and a=connection attributes from RFC 4145 [RFC4145], 487 following the procedures defined there as if ICE was not in use. In 488 particular, if an agent is the answerer, the a=setup attribute MUST 489 meet the constraints in RFC 4145 based on the value in the offer. 491 If an agent is utilizing SRTP [RFC3711], it MAY include a mix of UDP 492 and TCP candidates. If ICE selects a TCP candidate pair, it is 493 RECOMMENDED that the agent still utilizes SRTP, but runs it over the 494 connection established by ICE. The alternative, RTP over TLS, breaks 495 RTP header compression and on-path RTP analysis tools, and hence 496 SHOULD be avoided. In the case of DTLS-SRTP [RFC5764], the 497 directionality attributes (a=setup) are utilized strictly to 498 determine the direction of the DTLS handshake. Directionality of the 499 TCP connection establishment are determined by the ICE attributes and 500 procedures defined here. 502 If an agent is securing non-RTP media over TCP/TLS, the SDP MUST be 503 constructed as described in RFC 4572 [RFC4572]. The directionality 504 attributes (a=setup) are utilized strictly to determine the direction 505 of the TLS handshake. Directionality of the TCP connection 506 establishment are determined by the ICE attributes and procedures 507 defined here. 509 Examples of SDP offers and answers with ICE TCP extensions are shown 510 in Appendix C. 512 5. Candidate Collection Techniques 514 The following sections discuss a number of techniques that can be 515 used to obtain candidates for use with ICE TCP. It is important to 516 note that this list is not intended to be exhaustive, nor is 517 implementation of any specific technique beyond host candidates 518 (Section 5.1) considered mandatory. 520 Implementors are encouraged to implement as many of the following 521 techniques from the following list as is practical, as well as to 522 explore additional NAT-traversal techniques beyond those discussed in 523 this document. However, to get a reasonable success ratio, one 524 SHOULD implement at least one relayed technique (e.g., TURN) and one 525 technique for discovering the address given for the host by a NAT 526 (e.g., STUN). 528 To increase the success probability with the techniques described 529 below and to aid with transition to IPv6, implementors SHOULD take 530 particular care to include both IPv4 and IPv6 candidates as part of 531 the process of gathering candidates. If the local network or host 532 does not support IPv6 addressing, then clients SHOULD make use of 533 other techniques, e.g., TURN-IPv6 [RFC6156], Teredo [RFC4380] or 534 SOCKS IPv4-IPv6 gatewaying [RFC3089], for obtaining IPv6 candidates. 536 While implementations SHOULD support as many techniques as feasible, 537 they SHOULD also consider which of them to use if multiple options 538 are available. Since different candidates are paired with each 539 other, offering a large amount of candidates results in a large 540 checklist and potentially long lasting connectivity checks. For 541 example, using multiple NAT-assisted techniques with the same NAT 542 usually results only in redundant candidates. Similarly, out of 543 multiple different UDP tunneling or relaying techniques using just 544 one is often enough. 546 5.1. Host Candidates 548 Host candidates are the most simple candidates since they only 549 require opening TCP sockets on the host's interfaces and sending/ 550 receiving connectivity checks from them. However, if the hosts are 551 behind different NATs, host candidates usually fail to work. On the 552 other hand, if there are no NATs between the hosts, host candidates 553 are the most efficient method since they require no additional NAT 554 traversal protocols or techniques. 556 For each TCP-capable media stream the agent wishes to use (including 557 ones, like RTP, which can either be UDP or TCP), the agent SHOULD 558 obtain two host candidates (each on a different port) for each 559 component of the media stream on each interface that the host has - 560 one for the simultaneous-open, and one for the passive candidate. If 561 an agent is not capable of acting in one of these modes it would omit 562 those candidates. 564 5.2. Server Reflexive Candidates 566 Server reflexive techniques aim to discover the address a NAT has 567 given for the host by asking that from a server on the other side of 568 the NAT and then creating proper bindings (unless such already exist) 569 on the NATs with connectivity checks sent between the hosts. Success 570 of these techniques depends on the NATs' mapping and filtering 571 behavior [RFC5382] and also whether the NATs and hosts support the 572 TCP simultaneous-open technique. 574 Obtaining server reflexive passive candidates may require initiating 575 connections from host's passive candidates; see Appendix B for 576 implementation details on this. Server reflexive active candidates 577 can be derived from passive or S-O candidates by using the same IP 578 addresses and interfaces as those candidates. It is useful to obtain 579 both server reflexive passive and S-O candidates since it depends on 580 the hosts and NATs which one actually works better. Furthermore, 581 some techniques (e.g., TURN relaying) require knowing the IP address 582 of the peer's active candidates beforehand, so also active server 583 reflexive candidates are needed for such techniques to function 584 properly. 586 A widely used protocol for obtaining server reflexive candidates is 587 STUN, whose TCP-specific behavior is described in [RFC5389] Section 588 7.2.2. 590 5.3. NAT-Assisted Candidates 592 NAT-assisted techniques communicate with the NATs directly and this 593 way discover the address NAT has given to the host and also create 594 proper bindings on the NATs. The benefit of these techniques over 595 the server reflexive techniques is that the NATs can adjust their 596 mapping and filtering behavior so that connections can be 597 successfully created. A downside of NAT-assisted techniques is that 598 they commonly allow communicating only with a NAT that is in the same 599 subnet as the host and thus often fail in scenarios with multiple 600 layers of NATs. These techniques also rely on NATs supporting the 601 specific protocols and that the NATs allow the users to modify their 602 behavior. 604 These candidates are encoded in the ICE offer and answer like the 605 server reflexive candidates but they (commonly) use a higher priority 606 (as described in Section 4.2) and hence are tested before the server 607 reflexive candidates. 609 Currently, the UPnP forum's Internet Gateway Device (IGD) protocol 610 [UPnP-IGD] and the NAT Port Mapping Protocol (PMP) 611 [I-D.cheshire-nat-pmp] are widely supported NAT-assisted techniques. 612 Other known protocols include Port Control Protocol (PCP) 613 [I-D.ietf-pcp-base], SOCKS [RFC1928], Realm Specific IP (RSIP) 614 [RFC3103], and SIMCO [RFC4540]. Also, MIDCOM MIB [RFC5190] defines 615 an SNMP-based mechanism for controlling NATs. 617 5.4. UDP-Tunneled Candidates 619 UDP-tunneled NAT traversal techniques utilize the fact that UDP NAT 620 traversal is simpler and more efficient than TCP NAT traversal. With 621 these techniques, the TCP packets (or possibly complete IP packets) 622 are encapsulated in UDP packets. Because of the encapsulation these 623 techniques increase the overhead for the connection and may require 624 support from both of the endpoints, but on the other hand UDP 625 tunneling commonly results in reliable and fairly simple TCP NAT 626 traversal. 628 UDP-tunneled candidates can be encoded in the ICE offer and answer 629 either as relayed or server reflexive candidates, depending on 630 whether the tunneling protocol utilizes a relay between the hosts. 631 The UDP-tunneled candidates may appear to applications as host 632 candidates from a local pseudo-interface. Treating these candidates 633 as host candidates results in incorrect prioritization and possibly 634 non-optimal candidate selection. Implementations may attempt to 635 detect pseudo-interfaces, e.g., from the address prefix of the 636 interface, but detection details vary from technique to technique. 638 For example, the Teredo protocol [RFC4380] [RFC6081] provides 639 automatic UDP tunneling and IPv6 interworking. The Teredo UDP tunnel 640 is visible to the host application as an IPv6 address and thus Teredo 641 candidates are encoded as IPv6 addresses. 643 5.5. Relayed Candidates 645 Relaying packets through a relay server is often the NAT traversal 646 technique that has the highest success probability: communicating via 647 a relay that is in the public Internet looks like normal client- 648 server communication for the NATs and that is supported in practice 649 by all existing NATs, regardless of their filtering and mapping 650 behavior. However, using a relay has several drawbacks, e.g., it 651 usually results in a sub-optimal path for the packets, the relay 652 needs to exist and it needs to be discovered, the relay is a possible 653 single point of failure, relaying consumes potentially a lot of 654 resources of the relay server, etc. Therefore, relaying is often 655 used as the last resort when no direct path can be created with other 656 NAT traversal techniques. 658 With relayed candidates the host commonly needs to obtain only a 659 passive candidate since any of the peer's server reflexive (and NAT- 660 assisted if the peer can communicate with the outermost NAT) active 661 candidates should work with the passive relayed candidate. However, 662 if the relay is behind a NAT or a firewall, using also active and S-O 663 candidates will increase success probability. 665 Relaying protocols capable of relaying TCP connections include TURN 666 TCP [RFC6062] and SOCKS [RFC1928] (which can also be used for IPv4- 667 IPv6 gatewaying [RFC3089]). It is also possible to use, e.g., an SSH 668 [RFC4251] tunnel as a relayed candidate if a suitable server is 669 available and the server permits this. 671 6. Receiving the Initial Offer and Answer 673 Handling an ICE offer with TCP candidates works in a similar way as 674 with UDP candidates. First, ICE support is verified (including the 675 check for ice-mismatch described in Section 5.1 of [RFC5245]) and 676 agent roles are determined. Candidates are gathered using the 677 techniques described in Section 5 and prioritized as described in 678 Section 4.2. Default candidates are selected taking into account 679 considerations of Section 4.3. The SDP answer is encoded as in 680 Section 4.3 of [RFC5245] with the exception of TCP candidates whose 681 encoding was described in Section 4.5. 683 When the offerer receives the initial answer, it also verifies ICE 684 support and determines its role. If both of the agents use lite 685 implementations, the offerer takes the controlling role and uses the 686 procedures defined in [RFC4145] to select the most preferred 687 candidate pair with a new offer. 689 6.1. Considerations with Two Lite Agents 691 If both agents are using the lite mode, and if the offerer uses 692 a=setup:active attribute [RFC4145] in the new offer, the offerer MAY 693 initiate the TCP connection on the selected pair in parallel with the 694 new offer to speedup the connection establishment. Consequently, the 695 answerer MUST still accept incoming TCP connections to any of the 696 passive candidates it listed in the answer, from any of the IP 697 addresses the offerer listed in the initial offer. 699 If the answerer receives the new offer matching to the candidate pair 700 where connection was already created in parallel with the new offer, 701 it MUST accept the offer and respond to it while keeping the already 702 created connection. If the connection that was created in parallel 703 with the new offer does not match to the candidate pair in the new 704 offer, the connection MUST be closed and ICE restart SHOULD be 705 performed. 707 Since the connection endpoints are not authenticated using the 708 connectivity checks in the scenario where both agents use the lite 709 mode, unless media-level security (e.g., TLS) is used, it is 710 RECOMMENDED to use the full mode instead. For more lite vs. full 711 implementation considerations, see Appendix A of [RFC5245]. 713 6.2. Forming the Check Lists 715 As with UDP, checklists are formed only by full ICE implementations. 716 When forming candidate pairs, the following types of TCP candidates 717 can be paired with each other: 719 Local Remote 720 Candidate Candidate 721 --------------------------- 722 tcp-so tcp-so 723 tcp-active tcp-passive 724 tcp-passive tcp-active 726 When the agent prunes the check list, it MUST also remove any pair 727 for which the local candidate is a passive TCP candidate. With 728 pruning, the NAT-assisted candidates are treated like server 729 reflexive candidates if the base is used also as a host candidate. 731 The remainder of check list processing works like in the UDP case. 733 7. Connectivity Checks 735 The TCP connectivity checks, like with UDP, are generated only by 736 full implementations. The TCP candidate pairs are in the same 737 checklist with the UDP candidate pairs and they are scheduled for 738 connectivity checks, as described in Section 5.8 in [RFC5245], based 739 on the priority order. 741 7.1. STUN Client Procedures 743 When an agent wants to send a TCP-based connectivity check, it first 744 opens a TCP connection, if none yet exists, for the 5-tuple defined 745 by the candidate pair for which the check is to be sent. This 746 connection is opened from the local candidate of the pair to the 747 remote candidate of the pair. If the local candidate is tcp-active, 748 the agent MUST open a connection from the interface associated with 749 that local candidate. This connection SHOULD be opened from an 750 unallocated port. For host candidates, this is readily done by 751 connecting from the local candidate's interface. For relayed, NAT- 752 assisted, and UDP-tunneled candidates, the agent may need to use 753 additional procedures specific to the protocol. 755 Once the connection is established, the agent MUST utilize the shim 756 defined in RFC 4571 [RFC4571] for the duration this connection 757 remains open. The STUN Binding requests and responses are sent on 758 top of this shim, so that the length field defined in RFC 4571 759 precedes each STUN message. If TLS or DTLS-SRTP is to be utilized 760 for the media session, the TLS or DTLS-SRTP handshakes will take 761 place on top of this shim as well. However, they only start once ICE 762 processing has completed. In essence, the TLS or DTLS-SRTP 763 handshakes are considered a part of the media protocol. STUN is 764 never run within the TLS or DTLS-SRTP session as part of the ICE 765 procedures. 767 If the TCP connection cannot be established, the check is considered 768 to have failed, and a full-mode agent MUST update the pair state to 769 Failed in the check list. See Section 7.2.2 in [RFC5389] for more 770 details on STUN over TCP. 772 Once the connection is established, client procedures are identical 773 to those for UDP candidates. However, retransmissions of the STUN 774 connectivity check messages are not needed, since TCP takes care of 775 reliable delivery of the messages. Note also that STUN responses 776 received on an active TCP candidate will typically produce a peer 777 reflexive candidate. If the response to the first connectivity check 778 on the established TCP connection is something other than a STUN 779 message, the remote candidate address apparently was not one of the 780 peer's addresses and the agent SHOULD close the connection and 781 consider all pairs with that remote candidate as failed. 783 7.2. STUN Server Procedures 785 An ICE TCP agent, full or lite, MUST be prepared to receive incoming 786 TCP connection requests on the base of any TCP candidate that is 787 simultaneous-open or passive. When the connection request is 788 received, the agent MUST accept it. The agent MUST utilize the 789 framing defined in RFC 4571 [RFC4571] for the lifetime of this 790 connection. Due to this framing, the agent will receive data in 791 discrete frames. Each frame could be media (such as RTP or SRTP), 792 TLS, DTLS, or STUN packets. The STUN packets are extracted as 793 described in Section 10.2. 795 Once the connection is established, STUN server procedures are 796 identical to those for UDP candidates. Note that STUN requests 797 received on a passive TCP candidate will typically produce a remote 798 peer reflexive candidate. 800 8. Concluding ICE Processing 802 If there are TCP candidates for a media stream, a controlling agent 803 MUST use the regular selection algorithm. 805 When ICE processing for a media stream completes, each agent SHOULD 806 close all TCP connections (that were opened due to this ICE session) 807 except the ones between the candidate pairs selected by ICE. 809 These two rules are related; the closure of connection on 810 completion of ICE implies that a regular selection algorithm has 811 to be used. This is because aggressive selection might cause 812 transient pairs to be selected. Once such a pair was selected, 813 the agents would close the other connections, one of which may be 814 about to be selected as a better choice. This race condition may 815 result in TCP connections being accidentally closed for the pair 816 that ICE selects. 818 9. Subsequent Offer/Answer Exchanges 820 9.1. Updated Offer 822 When an updated offer is generated by the controlling endpoint after 823 the connectivity checks have succeeded, the SDP extensions for 824 connection oriented media [RFC4145] are used to signal that an 825 existing connection should be used, rather than opening a new one. 827 9.2. ICE Restarts 829 If an ICE restart occurs for a media stream with TCP candidate pairs 830 that have been selected by ICE, the agents MUST NOT close the 831 connections after the restart. In the offer or answer that causes 832 the restart, an agent MAY include a simultaneous-open candidate whose 833 transport address matches the previously selected candidate. If both 834 agents do this, the result will be a simultaneous-open candidate pair 835 matching an existing TCP connection. In this case, the agents MUST 836 NOT attempt to open a new connection (or start new TLS or DTLS-SRTP 837 procedures). Instead, that existing connection is reused and STUN 838 checks are performed. 840 Once the restart completes, if the selected pair does not match the 841 previously selected pair, the TCP connection for the previously 842 selected pair SHOULD be closed by the agent. 844 10. Media Handling 846 10.1. Sending Media 848 When sending media, if the selected candidate pair matches an 849 existing TCP connection, that connection MUST be used for sending 850 media. 852 The framing defined in RFC 4571 MUST be used when sending media. For 853 media streams that are not RTP-based and do not normally use RFC 854 4571, the agent treats the media stream as a byte stream, and assumes 855 that it has its own framing of some sort, if needed. It then takes 856 an arbitrary number of bytes from the byte stream, and places that as 857 a payload in the RFC 4571 frames, including the length. Next, the 858 sender checks to see if the resulting set of bytes would be viewed as 859 a STUN packet based on the rules in Sections 6 and 8 of [RFC5389]. 860 This includes a check on the most significant two bits, the magic 861 cookie, the length, and the fingerprint. If, based on those rules, 862 the bytes would be viewed as a STUN message, the sender MUST utilize 863 a different number of bytes so that the length checks will fail. 864 Though it is normally highly unlikely that an arbitrary number of 865 bytes from a byte stream would resemble a STUN packet based on all of 866 the checks, it can happen if the content of the application stream 867 happens to contain a STUN message (for example, a file transfer of 868 logs from a client which includes STUN messages). 870 If TLS or DTLS-SRTP procedures are being utilized to protect the 871 media stream, those procedures start at the point that media is 872 permitted to flow, as defined in the ICE specification [RFC5245]. 873 The TLS or DTLS-SRTP handshakes occur on top of the RFC 4571 shim, 874 and are considered part of the media stream for purposes of this 875 specification. 877 10.2. Receiving Media 879 The framing defined in RFC 4571 MUST be used when receiving media. 880 For media streams that are not RTP-based and do not normally use RFC 881 4571, the agent extracts the payload of each RFC 4571 frame, and 882 determines if it is a STUN or an application layer data based on the 883 procedures in ICE [RFC5245]. If media is being protected with DTLS- 884 SRTP, the DTLS, RTP and STUN packets are demultiplexed as described 885 in Section 5.1.2 [RFC5764]. 887 For non-STUN data, the agent appends this to the ongoing byte stream 888 collected from the frames. It then parses the byte stream as if it 889 had been directly received over the TCP connection. This allows for 890 ICE TCP to work without regard to the framing mechanism used by the 891 application layer protocol. 893 11. Connection Management 895 11.1. Connections Formed During Connectivity Checks 897 Once a TCP or TCP/TLS connection is opened by ICE for the purpose of 898 connectivity checks, its life cycle depends on how it is used. If 899 that candidate pair is selected by ICE for usage for media, an agent 900 SHOULD keep the connection open until: 902 o The session terminates 904 o The media stream is removed 906 o An ICE restart takes place, resulting in the selection of a 907 different candidate pair. 909 In these cases, the agent SHOULD close the connection when that event 910 occurs. This applies to both agents in a session, in which case 911 usually one of the agents will end up closing the connection first. 913 If a connection has been selected by ICE, an agent MAY close it 914 anyway. As described in the next paragraph, this will cause it to be 915 reopened almost immediately, and in the interim media cannot be sent. 916 Consequently, such closures have a negative effect and are NOT 917 RECOMMENDED. However, there may be cases where an agent needs to 918 close a connection for some reason. 920 If an agent needs to send media on the selected candidate pair, and 921 its TCP connection has closed, either on purpose or due to some 922 error, then: 924 o If the agent's local candidate is tcp-active or tcp-so, it MUST 925 reopen a connection to the remote candidate of the selected pair. 927 o If the agent's local candidate is tcp-passive, the agent MUST 928 await an incoming connection request, and consequently, will not 929 be able to send media until it has been opened. 931 If the TCP connection is established, the framing of RFC 4571 is 932 utilized. If the agent opened the connection, and is a full agent, 933 it MUST send a STUN connectivity check. An agent MUST be prepared to 934 receive a connectivity check over a connection it opened or accepted 935 (note that this is true in general; ICE requires that an agent be 936 prepared to receive a connectivity check at any time, even after ICE 937 processing completes). If a full agent receives a connectivity check 938 after re-establishment of the connection, it MUST generate a 939 triggered check over that connection in response if it has not 940 already sent a check. Once an agent has sent a check and received a 941 successful response, the connection is considered Valid and media can 942 be sent (which includes a TLS or DTLS-SRTP session resumption or 943 restart). 945 If the TCP connection cannot be established, the controlling agent 946 SHOULD restart ICE for this media stream. This will happen in cases 947 where one of the agents is behind a NAT with connection-dependent 948 mapping properties [RFC5382]. 950 11.2. Connections Formed for Gathering Candidates 952 If the agent opened a connection to a STUN server, or another similar 953 server, for the purposes of gathering a server reflexive candidate, 954 that connection SHOULD be closed by the client once ICE processing 955 has completed. This happens irregardless of whether the candidate 956 learned from the server was selected by ICE. 958 If the agent opened a connection to a TURN server for the purposes of 959 gathering a relayed candidate, that connection MUST be kept open by 960 the client for the duration of the media session if a relayed 961 candidate from the TURN server was selected by ICE. Otherwise, the 962 connection to the TURN server SHOULD be closed once ICE processing 963 completes. 965 If, despite efforts of the client, a TCP connection to a TURN server 966 fails during the lifetime of the media session utilizing a transport 967 address allocated by that server, the client SHOULD reconnect to the 968 TURN server, obtain a new allocation, and restart ICE for that media 969 stream. Similar measures SHOULD apply also to other type of relaying 970 servers. 972 12. Security Considerations 974 The main threat in ICE is hijacking of connections for the purposes 975 of directing media streams to DoS targets or to malicious users. 976 When full implementations are used, ICE TCP prevents that by only 977 using TCP connections that have been validated. Validation requires 978 a STUN transaction to take place over the connection. This 979 transaction cannot complete without both participants knowing a 980 shared secret exchanged in the rendezvous protocol used with ICE, 981 such as SIP [RFC3261]. This shared secret, in turn, is protected by 982 that protocol exchange. In the case of SIP, the usage of the SIPS 983 [RFC3261] mechanism is RECOMMENDED. When this is done, an attacker, 984 even if it knows or can guess the port on which an agent is listening 985 for incoming TCP connections, will not be able to open a connection 986 and send media to the agent. 988 If the rendezvous protocol exchange is compromised, the shared secret 989 can be learned by an attacker and the attacker may be able to fake 990 the connectivity check validation and open a TCP connection to the 991 target. Hence, using additional security mechanisms (e.g., 992 application layer security) that mitigate these risks is RECOMMENDED. 994 A STUN amplification attack is described in Section 18.5.2 of 995 [RFC5245]. The same considerations apply to TCP, but the 996 amplification effect with TCP is larger due to need for establishing 997 a TCP connection before any checks are performed. Therefore, an ICE 998 agent SHOULD NOT have more than 5 outstanding TCP connection attempts 999 with the same peer to the same IP address. 1001 If both agents use the lite mode, no connectivity checks are sent, 1002 and additional procedures (e.g., media-level security) are needed to 1003 validate the connection. The lack of connectivity checks is 1004 especially problematic if one of the hosts is behind a NAT and has an 1005 address from a private address space: the peer may accidentally 1006 connect to a host in a different subnet that uses the same private 1007 address space. This is one of the reasons why the lite mode is not 1008 appropriate for an ICE agent located behind a NAT. 1010 A more detailed analysis of different attacks and the various ways 1011 ICE prevents them are described in [RFC5245]. Those considerations 1012 apply to this specification. 1014 13. IANA Considerations 1016 IANA is requested to create a new registry "Interactive Connectivity 1017 Establishment (ICE) Transport Extensions" for ICE candidate attribute 1018 transport extensions. Initial value is given below; future 1019 assignments are to be made through IETF Review or IESG Approval 1020 [RFC5226]. Assignments consist of an extension token (as defined in 1021 Section 15.1 of [RFC5245]) and a reference to the document defining 1022 the extension. 1024 Token Reference 1025 ----- --------- 1026 TCP RFC XXXX Section 4.5 1028 [RFC Editor: please change XXXX to the RFC number of this document; 1029 and update the section number if needed] 1031 14. Acknowledgements 1033 The authors would like to thank Tim Moore, Saikat Guha, Francois 1034 Audet, Roni Even, Simon Perreault, Alfred Heggestad, Hadriel Kaplan, 1035 Jonathan Lennox, Flemming Andreasen, Dan Wing, and Vijay Gurbani for 1036 the reviews and input on this document. Special thanks to Marc 1037 Petit-Huguenin for providing the SDP examples. 1039 15. References 1041 15.1. Normative References 1043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1044 Requirement Levels", BCP 14, RFC 2119, March 1997. 1046 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1047 A., Peterson, J., Sparks, R., Handley, M., and E. 1048 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1049 June 2002. 1051 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1052 with Session Description Protocol (SDP)", RFC 3264, 1053 June 2002. 1055 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1056 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1057 RFC 3711, March 2004. 1059 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1060 the Session Description Protocol (SDP)", RFC 4145, 1061 September 2005. 1063 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1064 and RTP Control Protocol (RTCP) Packets over Connection- 1065 Oriented Transport", RFC 4571, July 2006. 1067 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1068 Transport Layer Security (TLS) Protocol in the Session 1069 Description Protocol (SDP)", RFC 4572, July 2006. 1071 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1072 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1073 May 2008. 1075 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1076 (ICE): A Protocol for Network Address Translator (NAT) 1077 Traversal for Offer/Answer Protocols", RFC 5245, 1078 April 2010. 1080 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1081 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1083 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1084 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1085 October 2008. 1087 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1088 Security (DTLS) Extension to Establish Keys for the Secure 1089 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1091 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1092 Relays around NAT (TURN): Relay Extensions to Session 1093 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1095 15.2. Informative References 1097 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1098 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1099 March 1996. 1101 [RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", 1102 RFC 3089, April 2001. 1104 [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, 1105 "Realm Specific IP: Protocol Specification", RFC 3103, 1106 October 2001. 1108 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1109 Protocol Architecture", RFC 4251, January 2006. 1111 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1112 Network Address Translations (NATs)", RFC 4380, 1113 February 2006. 1115 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 1116 Middlebox Configuration (SIMCO) Protocol Version 3.0", 1117 RFC 4540, May 2006. 1119 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1120 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1122 [RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh, 1123 "Definitions of Managed Objects for Middlebox 1124 Communication", RFC 5190, March 2008. 1126 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1127 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1128 RFC 5382, October 2008. 1130 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1131 around NAT (TURN) Extensions for TCP Allocations", 1132 RFC 6062, November 2010. 1134 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. 1136 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 1137 Using Relays around NAT (TURN) Extension for IPv6", 1138 RFC 6156, April 2011. 1140 [I-D.ietf-pcp-base] 1141 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1142 Selkirk, "Port Control Protocol (PCP)", 1143 draft-ietf-pcp-base-17 (work in progress), October 2011. 1145 [I-D.cheshire-nat-pmp] 1146 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1147 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1149 [UPnP-IGD] 1150 Warrier, U., Iyer, P., Pennerath, F., Marynissen, G., 1151 Schmitz, M., Siddiqi, W., and M. Blaszczak, "Internet 1152 Gateway Device (IGD) Standardized Device Control Protocol 1153 V 1.0", November 2001. 1155 [IMC05] Guha, S. and P. Francis, "Characterization and Measurement 1156 of TCP Traversal through NATs and Firewalls", Proceedings 1157 of the 5th ACM SIGCOMM conference on Internet Measurement, 1158 2005. 1160 Appendix A. Limitations of ICE TCP 1162 Compared to UDP-based ICE, ICE TCP has in general lower success 1163 probability for enabling connectivity without a relay if both of the 1164 hosts are behind a NAT. This happens because many of the currently 1165 deployed NATs have endpoint-dependent mapping behavior or they do not 1166 support the flow of TCP handshake packets seen in case of TCP 1167 simultaneous-open: e.g., some NATs do not allow incoming TCP SYN 1168 packets from an address where a SYN packet has been sent to recently 1169 or the subsequent SYN-ACK is not processed properly. 1171 It has been reported in [IMC05] that with the population of NATs 1172 deployed at the time of the measurements (2005), one of the NAT 1173 traversal techniques described here, TCP simultaneous-open, worked in 1174 roughly 45% of the cases. Also, all operating systems do not 1175 implement TCP simultaneous-open properly and thus are not able to use 1176 such candidates. However, when more NATs comply with the 1177 requirements set by [RFC5382] and operating system TCP stacks are 1178 fixed, the success probability of simultaneous-open is likely to 1179 increase. Also, it is important to implement additional techniques 1180 with higher success ratio, such as Teredo, whose success in different 1181 scenarios is described in Figure 1 of [RFC6081]. 1183 Finally, it should be noted that implementing various techniques 1184 listed in Section 5 should increase the success probability, but many 1185 of these techniques require support from the endpoints and/or from 1186 some network elements (e.g., from the NATs). Without comprehensive 1187 experimental data on how well different techniques are supported the 1188 actual increase of success probability is hard to evaluate. 1190 Appendix B. Implementation Considerations for BSD Sockets 1192 This specification requires unusual handling of TCP connections, the 1193 implementation of which in traditional BSD socket APIs is non- 1194 trivial. 1196 In particular, ICE requires an agent to obtain a local TCP candidate, 1197 bound to a local IP and port, and then from that local port, initiate 1198 a TCP connection (e.g., to the STUN server, in order to obtain server 1199 reflexive candidates, to the TURN server, to obtain a relayed 1200 candidate, or to the peer as part of a connectivity check), and be 1201 prepared to receive incoming TCP connections (for passive and 1202 simultaneous-open candidates). A "typical" BSD socket is used either 1203 for initiating or receiving connections, and not for both. The code 1204 required to allow incoming and outgoing connections on the same local 1205 IP and port is non-obvious. The following pseudocode, contributed by 1206 Saikat Guha, has been found to work on many platforms: 1208 for i in 0 to MAX 1209 sock_i = socket() 1210 set(sock_i, SO_REUSEADDR) 1211 bind(sock_i, local) 1213 listen(sock_0) 1214 connect(sock_1, stun) 1215 connect(sock_2, remote_a) 1216 connect(sock_3, remote_b) 1218 The key here is that, prior to the listen() call, the full set of 1219 sockets that need to be utilized for outgoing connections must be 1220 allocated and bound to the local IP address and port. This number, 1221 MAX, represents the maximum number of TCP connections to different 1222 destinations that might need to be established from the same local 1223 candidate. This number can be potentially large for simultaneous- 1224 open candidates. If a request forks, ICE procedures may take place 1225 with multiple peers. Furthermore, for each peer, connections would 1226 need to be established to each passive or simultaneous-open candidate 1227 for the same component. If we assume a worst case of 5 forked 1228 branches, and for each peer, five simultaneous-open candidates, that 1229 results in MAX=25. 1231 Appendix C. SDP Examples 1233 This section shows two examples of SDP offer and answer when the ICE 1234 TCP extension is used. Both examples are based on the simplified 1235 topology of Figure 8 in [RFC5245], with the same IP addresses. The 1236 examples shown here should be considered as strictly informative. 1238 In the first example, the offer contains only TCP candidates (lines 1239 folded in examples to satisfy RFC formatting rules): 1241 v=0 1242 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 1243 s= 1244 c=IN IP4 192.0.2.3 1245 t=0 0 1246 a=ice-pwd:asd88fgpdd777uzjYhagZg 1247 a=ice-ufrag:8hhY 1248 m=audio 45664 TCP/RTP/AVP 0 1249 b=RS:0 1250 b=RR:0 1251 a=rtpmap:0 PCMU/8000 1252 a=setup:active 1253 a=connection:new 1254 a=candidate:1 1 TCP 2128609279 10.0.1.1 9 typ host tcptype active 1255 a=candidate:2 1 TCP 2124414975 10.0.1.1 8998 typ host tcptype passive 1256 a=candidate:3 1 TCP 2120220671 10.0.1.1 8999 typ host tcptype so 1257 a=candidate:4 1 TCP 1688207359 192.0.2.3 9 typ srflx raddr 10.0.1.1 1258 rport 9 tcptype active 1259 a=candidate:5 1 TCP 1684013055 192.0.2.3 45664 typ srflx raddr 1260 10.0.1.1 rport 8998 tcptype passive 1261 a=candidate:6 1 TCP 1692401663 192.0.2.3 45687 typ srflx raddr 1262 10.0.1.1 rport 8999 tcptype so 1264 The answer to that offer could look like this: 1266 v=0 1267 o=bob 2808844564 2808844564 IN IP4 192.0.2.1 1268 s= 1269 c=IN IP4 192.0.2.1 1270 t=0 0 1271 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 1272 a=ice-ufrag:9uB6 1273 m=audio 3478 TCP/RTP/AVP 0 1274 b=RS:0 1275 b=RR:0 1276 a=setup:passive 1277 a=connection:new 1278 a=rtpmap:0 PCMU/8000 1279 a=candidate:1 1 TCP 2128609279 192.0.2.1 9 typ host tcptype active 1280 a=candidate:2 1 TCP 2124414975 192.0.2.1 3478 typ host tcptype passive 1281 a=candidate:3 1 TCP 2120220671 192.0.2.1 3482 typ host tcptype so 1283 In the second example, UDP and TCP media streams are mixed but S-O 1284 candidates are omitted due to hosts not supporting TCP simultaneous- 1285 open and UDP candidates are preferred (but preference order for 1286 candidate types is kept the same) by decreasing the TCP candidate 1287 type preferences by one (i.e., using type preference 125 for the host 1288 candidates and 99 for the server reflexive candidates): 1290 v=0 1291 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 1292 s= 1293 c=IN IP4 192.0.2.3 1294 t=0 0 1295 a=ice-pwd:asd88fgpdd777uzjYhagZg 1296 a=ice-ufrag:8hhY 1297 m=audio 45664 RTP/AVP 0 1298 b=RS:0 1299 b=RR:0 1300 a=rtpmap:0 PCMU/8000 1301 a=candidate:1 1 TCP 2111832063 10.0.1.1 9 typ host tcptype active 1302 a=candidate:2 1 TCP 2107637759 10.0.1.1 9012 typ host tcptype passive 1303 a=candidate:3 1 TCP 1671430143 192.0.2.3 9 typ srflx raddr 10.0.1.1 1304 rport 9 tcptype active 1305 a=candidate:4 1 TCP 1667235839 192.0.2.3 44642 typ srflx raddr 1306 10.0.1.1 rport 9012 tcptype passive 1307 a=candidate:5 1 UDP 2130706431 10.0.1.1 8998 typ host 1308 a=candidate:6 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 1309 10.0.1.1 rport 8998 1311 The corresponding answer could look like this: 1313 v=0 1314 o=bob 2808844564 2808844564 IN IP4 192.0.2.1 1315 s= 1316 c=IN IP4 192.0.2.1 1317 t=0 0 1318 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 1319 a=ice-ufrag:9uB6 1320 m=audio 3478 RTP/AVP 0 1321 b=RS:0 1322 b=RR:0 1323 a=rtpmap:0 PCMU/8000 1324 a=candidate:1 1 TCP 2111832063 192.0.2.1 9 typ host tcptype active 1325 a=candidate:2 1 TCP 2107637759 192.0.2.1 3478 typ host tcptype passive 1326 a=candidate:3 1 UDP 2130706431 192.0.2.1 3478 typ host 1328 Authors' Addresses 1330 Jonathan Rosenberg 1331 Skype 1333 Email: jdrosen@jdrosen.net 1334 URI: http://www.jdrosen.net 1335 Ari Keranen 1336 Ericsson 1337 Hirsalantie 11 1338 02420 Jorvas 1339 Finland 1341 Email: ari.keranen@ericsson.com 1343 Bruce B. Lowekamp 1344 Skype 1346 Email: bbl@lowekamp.net 1348 Adam Roach 1349 Tekelec 1350 17210 Campbell Rd. 1351 Suite 250 1352 Dallas, TX 75252 1353 US 1355 Email: adam@nostrum.com