idnits 2.17.1 draft-ietf-mmusic-ice-tcp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 673. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 217: '... The offerer MUST be a full ICE impl...' RFC 2119 keyword, line 222: '...ither be UDP or TCP), the agent SHOULD...' RFC 2119 keyword, line 237: '...or choice, it is RECOMMENDED that agen...' RFC 2119 keyword, line 269: '... Each agent SHOULD "obtain" an activ...' RFC 2119 keyword, line 276: '... base, the agent SHOULD obtain server ...' (52 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2007) is 6262 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) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 ** Obsolete normative reference: RFC 4572 (ref. '5') (Obsoleted by RFC 8122) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-02 == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track March 5, 2007 5 Expires: September 6, 2007 7 TCP Candidates with Interactive Connectivity Establishment (ICE 8 draft-ietf-mmusic-ice-tcp-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 6, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Interactive Connectivity Establishment (ICE) defines a mechanism for 42 NAT traversal for multimedia communication protocols based on the 43 offer/answer model of session negotiation. ICE works by providing a 44 set of candidate transport addresses for each media stream, which are 45 then validated with peer-to-peer connectivity checks based on Simple 46 Traversal of UDP over NAT (STUN). ICE provides a general framework 47 for describing alternates, but only defines UDP-based transport 48 protocols. This specification extends ICE to TCP-based media, 49 including the ability to offer a mix of TCP and UDP-based candidates 50 for a single stream. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 56 3. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 5 57 3.1. Gathering Candidates . . . . . . . . . . . . . . . . . . . 5 58 3.2. Prioritization . . . . . . . . . . . . . . . . . . . . . . 7 59 3.3. Choosing Default Candidates . . . . . . . . . . . . . . . 8 60 3.4. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 8 61 4. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 9 62 4.1. Forming the Check Lists . . . . . . . . . . . . . . . . . 9 63 5. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 9 64 5.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 9 65 5.1.1. Sending the Request . . . . . . . . . . . . . . . . . 9 66 5.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 10 67 6. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 10 68 7. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 11 69 7.1. ICE Restarts . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 11 72 8.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 11 73 9. Connection Management . . . . . . . . . . . . . . . . . . . . 12 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Intellectual Property and Copyright Statements . . . . . . . . . . 15 83 1. Introduction 85 Interactive Connectivity Establishment (ICE) [6] defines a mechanism 86 for NAT traversal for multimedia communication protocols based on the 87 offer/answer model [2] of session negotiation. ICE works by 88 providing a set of candidate transport addresses for each media 89 stream, which are then validated with peer-to-peer connectivity 90 checks based on Session Traversal Utilities for NAT (STUN) [1]. 91 However, ICE only defines procedures for UDP-based transport 92 protocols. 94 There are many reasons why ICE support for TCP is important. 95 Firstly, there are media protocols that only run over TCP. Examples 96 of such protocols are web and application sharing and instant 97 messaging [9]. For these protocols to work in the presence of NAT, 98 unless they define their own NAT traversal mechanisms, ICE support 99 for TCP is needed. In addition, RTP itself can run over TCP (without 100 [4] and with TLS [5]). Typically, it is preferable to run RTP over 101 UDP, and not TCP. However, in a variety of network environments, 102 overly restrictive NAT and firewall devices prevent UDP-based 103 communications altogether, but general TCP-based communications are 104 permitted. In such environments, sending RTP over TCP, and thus 105 establishing the media session, may be preferable to having it fail 106 altogether. With ICE, agents can gather UDP and TCP candidates for 107 an RTP-based stream, list the UDP ones with higher priority, and then 108 only use the TCP-based ones if the UDP ones fail altogether. This 109 provides a fallback mechanism that allows multimedia communications 110 to be highly reliable. 112 The usage of RTP over TCP is particularly useful when combined with 113 the STUN relay usage [7]. In that usage, one of the agents would 114 connect to its STUN relay server using TCP, and obtain a TCP-based 115 relayed candidate. It would offer this to its peer agent as a 116 candidate. The answerer would initiate a TCP connection towards the 117 STUN relay server. When that connection is established, media can 118 flow over the connections, through the relay. The benefit of this 119 usage is that it only requires the agents to make outbound TCP 120 connections to a server on the public network. This kind of 121 operation is broadly interoperable through NAT and firewall devices. 122 Since it is a goal of ICE and this extension to provide highly 123 reliable communications that "just works" in as a broad a set of 124 network deployments as possible, this usage is particularly 125 important. 127 The usage of RTP over TCP/TLS is also useful when communicating 128 between single-user agents (such as a softphone or hardphone) and an 129 agent run by a provider that is meant to service many users, such as 130 a PSTN gateway. In such a deployment, the multi-user agent would act 131 as the TLS server, and have a certificate. The single-user agent can 132 then connect, validate the certificate, but offer none of its own 133 (since its not likely to have one). STUN itself would then provide 134 authentication of the softphone to the gateway, leveraging the 135 exchange of a short term credential in the SIP signaling. 137 This specification extends ICE by defining its usage with TCP 138 candidates. This specification does so by following the outline of 139 ICE itself, and calling out the additions and changes necessary in 140 each section of ICE to support TCP candidates. 142 2. Overview of Operation 144 The usage of ICE with TCP is relatively straightforward. The main 145 area of specification is around how and when connections are opened, 146 and how those connections relate to candidate pairs. 148 When the agents perform address allocations to gather TCP-based 149 candidates, three types of candidates can be obtained. These are 150 active candidates, passive candidates, and simultaneous-open 151 candidates. An active candidate is one for which the agent will 152 attempt to open an outbound connection, but will not receive incoming 153 connection requests. A passive candidate is one for which the agent 154 will receive incoming connection attempts, but not attempt a 155 connection. A simultaneous-open candidate is one for which the agent 156 will attempt to open a connection simultaneously with its peer. 158 Because this specification requires multiple candidates for a media 159 stream, it is not compatible with ICE's lite implementation, and can 160 only be used by full implementations. 162 When gathering candidates from a host interface, the agent typically 163 obtains an active, passive and simultaneous-open candidates. 164 Similarly, communications with a STUN server will provide server 165 reflexive and relayed versions of all three types. 167 When encoding these candidates into offers and answers, the type of 168 the candidate is signaled. In the case of active candidates, an IP 169 address and port is present, but it is meaningless, as it is ignored 170 by the peer. As a consequence, active candidates do not need to be 171 physically allocated at the time of address gathering. Rather, the 172 physical allocations, which occur as a consequence of a connection 173 attempt, occur at the time of the connectivity checks. 175 When the candidates are paired together, active candidates are always 176 paired with passive, and simultaneous-open candidates with each 177 other. When a connectivity check is to be made on a candidate pair, 178 each agent determines whether it is to make a connection attempt for 179 this pair. 181 Why have both active and simultaneous-open candidates? Why not 182 just simultaneous-open? The reason is that NAT treatment of 183 simultaneous opens is currently not well defined, though 184 specifications are being developed to address this [8]. Some NATs 185 block the second TCP SYN packet or improperly process the 186 subsequent SYNACK, which will cause the connection attempt to 187 fail. Therefore, if only simultaneous opens are used, connections 188 may often fail. Alternatively, using unidirectional opens (where 189 one side is active and the other is passive) is more reliable, but 190 will always require a relay if both sides are behind NAT. 191 Therefore, in the spirit of the ICE philosophy, both are tried. 192 Simultaneous-opens are preferred since, if it does work, it will 193 not require a relay even when both sides are behind a different 194 NAT. 196 The actual processing of generating connectivity checks, managing the 197 state of the check list, and updating the Valid list, work 198 identically for TCP as they do for UDP. 200 ICE requires an agent to demultiplex STUN and application layer 201 traffic, since they appear on the same port. This demultiplexing is 202 described by ICE, and is done using the magic cookie and other fields 203 of the message. Stream-oriented transports introduce another 204 wrinkle, since they require a way to frame the connection so that the 205 application and STUN packets can be extracted in order to determine 206 which is which. For this reason, TCP media streams utilizing ICE use 207 the basic framing provided in RFC 4571 [4], even if the application 208 layer protocol is not RTP. 210 When an updated offer is generated by the controlling endpoint, the 211 SDP extensions for connection oriented media [3] are used to signal 212 that an existing connection should be used, rather than opening a new 213 one. 215 3. Sending the Initial Offer 217 The offerer MUST be a full ICE implementation. 219 3.1. Gathering Candidates 221 For each TCP capable media stream the agent wishes to use (including 222 ones, like RTP, which can either be UDP or TCP), the agent SHOULD 223 obtain two host candidates for each component of the media stream on 224 each interface that the host has - one for the simultaneous open, and 225 one for the passive candidate. If an agent is not capable of acting 226 in one of these modes (for example, the TCP connection is being used 227 with TLS and the agent can only act as the client), it would omit 228 those candidates. 230 OPEN ISSUE: What happens with TLS and simultaneous opens? Who 231 sends the ClientHello? 233 > 235 Providers of real-time communications services may decide that it is 236 preferable to have no media at all than it is to have media over TCP. 237 To allow for choice, it is RECOMMENDED that agents be configurable 238 with whether they obtain TCP candidates for real time media. 240 Having it be configurable, and then configuring it to be off, is 241 far better than not having the capability at all. An important 242 goal of this specification is to provide a single mechanism that 243 can be used across all types of endpoints. As such, it is 244 preferable to account for provider and network variation through 245 configuration, instead of hard-coded limitations in an 246 implementation. Furthermore, network characteristics and 247 connectivity assumptions can, and will change over time. Just 248 because a agent is communicating with a server on the public 249 network today, doesn't mean that it won't need to communicate with 250 one behind a NAT tomorrow. Just because a agent is behind a NAT 251 with endpoint indpendent mapping today, doesn't mean that tomorrow 252 they won't pick up their agent and take it to a public network 253 access point where there is a NAT with address and port dependent 254 mapping properties, or one that only allows outbound TCP. The way 255 to handle these cases and build a reliable system is for agents to 256 implement a diverse set of techniques for allocating addresses, so 257 that at least one of them is almost certainly going to work in any 258 situation. Implementors should consider very carefully any 259 assumptions that they make about deployments before electing not 260 to implement one of the mechanisms for address allocation. In 261 particular, implementors should consider whether the elements in 262 the system may be mobile, and connect through different networks 263 with different connectivity. They should also consider whether 264 endpoints which are under their control, in terms of location and 265 network connectivity, would always be under their control. In 266 environments where mobility and user control are possible, a 267 multiplicity of techniques is essential for reliability. 269 Each agent SHOULD "obtain" an active host candidate for each 270 component of each TCP capable media stream on each interface that the 271 host has. The agent does not have to actually allocate a port for 272 these candidates. These candidates serve as a placeholder for the 273 creation of the check lists. 275 Using each simultaneous-open and passive host TCP candidate as a 276 base, the agent SHOULD obtain server reflexive candidate. In 277 addition, the agent SHOULD choose, amongst all host TCP candidates 278 for a component that have the same foundation (there will typically 279 be two - a passive and simultaneous-open), one of those candidates, 280 and from it, obtain two server reflexive candidates - one that will 281 be simultaneous-open, and one that will be passive. If an agent 282 requires both a server reflexive and relayed candidate using a 283 particular host candidate as a based, it SHOULD obtain both at the 284 same time using a STUN Allocate request. Otherwise, if just a server 285 reflexive candidate is required, the agent SHOULD use a STUN Binding 286 Request. 288 An agent MAY use an additional host TCP candidate to request a UDP- 289 based candidate from the server. Usage of the UDP candidate from the 290 relay follows the procedures defined in ICE for UDP candidates. 292 Each agent SHOULD "obtain" an active relayed candidate for each 293 component of each TCP capable media stream on each interface that the 294 host has. The agent does not have to actually allocate a port for 295 these candidates from the relay at this time. These candidates serve 296 as a placeholder for the creation of the check lists. 298 Like its UDP counterparts, TCP-based STUN transactions are paced out 299 at one every Ta seconds. This pacing refers to the establishment of 300 a TCP connection to the STUN server and the subsequent STUN request. 301 That is, every Ta seconds, the agent will open a new TCP connection 302 and send a STUN request, either an Allocate or Binding request. 304 3.2. Prioritization 306 The transport protocol itself is a criteria for choosing one 307 candidate over another. If a particular media stream can run over 308 UDP or TCP, the UDP candidates might be preferred over the TCP 309 candidates. This allows ICE to use the lower latency UDP 310 connectivity if it exists, but fallback to TCP if UDP doesn't work. 312 To accomplish this, the local preference SHOULD be defined as: 314 local-preference = (2^12)*(transport-pref) + 315 (2^9)*(direction-pref) + 316 (2^0)*(other-pref) 318 When this formulation is used, the transport-pref MUST be between 0 319 and 15, with 15 being the most preferred. The direction-pref MUST be 320 between 0 and 7, with 7 being the most preferred. Other-pref MUST be 321 between 0 and 511, with 511 being the most preferred. For RTP-based 322 media streams, it is RECOMMENDED that UDP have a transport-pref of 15 323 and TCP of 6. It is RECOMMENDED that, for all connection-oriented 324 media, simultaneous-open candidates have a direction-pref of 7, 325 active of 5 and passive of 2. If any two candidates have the same 326 type-preference, transport-pref, and direction-pref, they MUST have a 327 unique other-pref. With this specification, the only way that can 328 happen is with multi-homed hosts, in which case other-pref is a 329 preference amongst interfaces. 331 3.3. Choosing Default Candidates 333 The default candidate is chosen primarily based on the likelihood of 334 it working with a non-ICE peer. When media streams supporting mixed 335 modes (both TCP and UDP) are used with ICE, it is RECOMMENDED that, 336 for real-time streams (such as RTP), the default candidates be UDP- 337 based. However, the default SHOULD NOT be the simultaneous-open 338 candidate. 340 If a media stream is inherently TCP-based, the agent SHOULD NOT 341 select the simultaneous-open candidate as default. 343 3.4. Encoding the SDP 345 TCP-based candidates are encoded into a=candidate lines identically 346 to the UDP encoding described in [6]. However, the transport 347 protocol is set to "tcp-so" for TCP simultaneous-open candidates, 348 "tcp-act" for TCP active candidates, and "tcp-pass" for TCP passive 349 candidates. The addr and port encoded into the candidate attribute 350 for active candidates MUST be set to IP address that will be used for 351 the attempt, but the port MUST be set to 9 (i.e., Discard). For 352 relayed candidates, the IP address that will be used for the attempt 353 is the one from a passive or simultaneous-open candidate from the 354 same STUN server. 356 If the default candidate is TCP, the agent MUST include any SDP 357 parameters required for establishing that TCP connection for that 358 media stream, in case the peer is not ICE aware. For example, if a 359 TCP-based media stream utilizes RFC 4145 [3], the agent MUST follow 360 the procedures defined there for constructing an offer, as if ICE was 361 not in use. For example, if an agent selects its passive candidate 362 as default and the media stream utilizes RFC 4145, the agent MUST 363 include an a=passive attribute. Note that these parameters are not 364 used by ICE, they are only relevant for non-ICE entities. 366 In addition, if a TCP-based candidate is offered, and the default 367 candidate is UDP based, the SDP MUST include any parameters that 368 would be required for the TCP stream to be utilized once set up, 369 should it be selected by ICE. This excludes the connection 370 parameters from RFC 4145, which are not utilized between ICE peers. 371 However, if a TCP candidate was meant to be used for TLS, and the 372 default candidate was UDP-based (and of course if it was TCP-based), 373 the parameters of RFC 4572 [5] would need to be included in the SDP. 374 This signals that the TCP candidate is to be used with TLS. 376 4. Receiving the Initial Offer 378 4.1. Forming the Check Lists 380 When forming candidate pairs, the following types of candidates can 381 be paired with each other: 383 Local Remote 384 Candidate Candidate 385 ---------------------------- 386 tcp-so tcp-so 387 tcp-act tcp-pass 388 tcp-pass tcp-act 390 When the agent prunes the check list, it MUST also remove any pair 391 for which the local candidate is tcp-pass. 393 The remainder of check list processing works like the UDP case. 395 5. Connectivity Checks 397 5.1. Client Procedures 399 5.1.1. Sending the Request 401 When an agent wants to send a TCP-based connectivity check, it first 402 opens a TCP connection if none yet exists for the 5-tuple on which 403 the check is to be sent. This connection is opened from the local 404 candidate of the check to the remote candidate of the check. If the 405 local candidate is tcp-act, the agent MUST open a connection from the 406 interface associated with that local candidate. This connection MUST 407 be opened from an unallocated port. For host candidates, this is 408 readily done by connecting from the candidates interface. For 409 relayed candidates, the agent uses the procedures in [7] to initiate 410 a new connection from the specified interface on the relay. [[TODO: 411 need to make sure this reconciles with latest TURN]]. 413 If the offer/answer exchange, one completed, indicates that the TCP 414 candidates for a media stream will utilize TLS (for example, as a 415 consequence of the presence of the fingerprint attribute from RFC 416 4572), the agent that opened the connection MUST proceed with TLS 417 handshakes to secure the link prior to proceeding with STUN checks. 419 Once the TCP or TCP/TLS connection is established, connectivity 420 checks are sent over the connection. The agent MUST use the framing 421 defined in RFC 4571 [4], even though the data will include both media 422 (possibly RTP) and STUN packets. This framing MUST be used for the 423 lifetime of this connection. 425 If the TCP connection cannot be established, or the TLS handshakes 426 fail, the check is considered to have failed, and a full-mode agent 427 MUST update the pair state to Failed in the check list. 429 5.2. Server Procedures 431 An agent MUST be prepared to receive incoming TCP connection requests 432 on any host or relayed TCP candidate that is simultaneous-open or 433 passive. When the connection request is received, the agent MUST 434 accept it. If the offer/answer exchange indicates that TLS is in 435 use, the agent MUST be prepared for TLS negotiation, and complete 436 that exchange prior to receiving STUN requests. 438 The agent MUST use the framing defined in RFC 4571 [4], even though 439 the data will include both media (possibly RTP) and STUN packets. 440 This framing MUST be used for the lifetime of this connection. 442 Once the connection is established, server procedures are identical 443 to those for UDP candidates. Note that STUN requests received on a 444 passive TCP or TCP/TLS candidate will typically produce a remote peer 445 reflexive candidate. 447 6. Concluding ICE Processing 449 If there are TCP candidates for a media stream, a controlling agent 450 MUST use a regular selection algorithm. 452 When ICE processing for a media stream completes, each agent SHOULD 453 close all TCP connections except the one between the candidate pairs 454 selected by ICE. 456 These two rules are related; the closure of connection on 457 completion of ICE implies that a regular selection algorithm has 458 to be used. This is because aggressive selection might cause 459 transient pairs to be selected. Once such a pair was selected, 460 the agents would close the other connections, one of which may be 461 about to be selected as a better choice. This race condition may 462 result in TCP connections being accidentally closed for the pair 463 that ICE selects. 465 7. Subsequent Offer/Answer Exchanges 467 7.1. ICE Restarts 469 If an ICE restart occurs for a media stream with TCP candidate pairs 470 that have been selected by ICE, the agents MUST NOT close the 471 connections after the restart. In the offer or answer that causes 472 the restart, an agent MAY include a simultaneous-open candidate whose 473 transport address matches the previously selected candidate. If both 474 agents do this, the result will be a simultaneous-open candidate pair 475 matching an existing TCP connection. In this case, the agents MUST 476 NOT attempt to open a new connection (or start new TLS procedures). 477 Instead, that existing connection is reused and STUN checks are 478 performed. 480 Once the restart completes, if the selected pair does not match the 481 previously selected pair, the TCP connection for the previously 482 selected pair SHOULD be closed by the agent. 484 8. Media Handling 486 8.1. Sending Media 488 When sending media, if the selected candidate pair matches an 489 existing TCP connection, that connection MUST be used for sending 490 media. 492 The framing defined in RFC 4571 MUST be used when sending media. For 493 media streams that are not RTP-based and do not normally use RFC 494 4571, the agent treats the media stream as a byte stream, and assumes 495 that it has its own framing of some sort. It then takes an arbitrary 496 number of bytes from the bytestream, and places that as a payload in 497 the RFC 4571 frames, including the length. The recipient can extract 498 the bytestream and apply the application-specific framing on it. 500 8.2. Receiving Media 502 The framing defined in RFC 4571 MUST be used when receiving media. 503 For media streams that are not RTP-based and do not normally use RFC 504 4571, the agent extracts the payload of each RFC 4571 frame, and 505 determines if it is a STUN or an application layer data based on the 506 procedures in [6]. If it is application layer data, the agent 507 appends this to the ongoing bytestream collected from the frames. It 508 then parses the bytestream as if it had been directly received over 509 the TCP or TCP/TLS connection. This allows for ICE-tcp to work 510 without regard to the framing mechanism used by the application layer 511 protocol. 513 9. Connection Management 515 Once a TCP or TCP/TLS connection is opened by ICE, its lifecycle 516 depends on how it is used. If that candidate pair is selected by ICE 517 for usage for media, an agent SHOULD keep the connection open until: 519 o The session terminates 521 o The media stream is removed 523 o An ICE restart takes place, resulting in the selection of a 524 different candidate pair. 526 In these cases, the agent SHOULD close the connection when that event 527 occurs. 529 If a connection has been selected by ICE, an agent MAY close it 530 anyway. As described in the next paragraph, this will cause it to be 531 reopened almost immediately, and in the interim media cannot be sent. 532 Consequently, such closures have a negative effect and are NOT 533 RECOMMENDED. However, there may be cases where an agent needs to 534 close a connection for some reason. 536 If an agent needs to send media on the selected candidate pair, and 537 its TCP connection has closed, either on purpose or due to some 538 error, then: 540 o If the agent's local candidate is tcp-act or tcp-so, it MUST 541 reopen a connection to the remote candidate of the selected pair. 543 o If the agent's local candidate is tcp-pass, the agent MUST await 544 an incoming connection request, and consequently, will not be able 545 to send media until it has been opened. 547 If the TCP connection is established, and the SDP indicates that TLS 548 is in use, the agents MUST redo the TLS handshakes. Once complete, 549 the connection MAY be used for media; re-validation using STUN is not 550 required. 552 OPEN ISSUE: Can we use session resumption to avoid redoing this? 554 If the TCP connection cannot be established, the controlling agent 555 SHOULD restart ICE for this media stream. 557 10. Security Considerations 559 The main threat in ICE is hijacking of connections for the purposes 560 of directing media streams to DoS targets or to malicious users. 561 ICE-tcp prevents that by only using TCP connections that have been 562 validated. Validation requires a STUN transaction to take place over 563 the connection. This transaction cannot complete without both 564 participants knowing a shared secret exchanged in the rendezvous 565 protocol used with ICE, such as SIP. This shared secret, in turn, is 566 protected by that protocol exchange. In the case of SIP, the usage 567 of the sips mechanism is RECOMMENDED. When this is done, an 568 attacker, even if it knows or can guess the port on which an agent is 569 listening for incoming TCP connections, will not be able to open a 570 connection and send media to the agent. 572 A more detailed analysis of this attack and the various ways ICE 573 prevents it are described in [6]. Those considerations apply to this 574 specification. 576 11. IANA Considerations 578 There are no IANA considerations associated with this specification. 580 12. Acknowledgements 582 The authors would like to thank Tim Moore, Francois Audet and Roni 583 Even for the reviews and input on this document. 585 13. References 587 13.1. Normative References 589 [1] Rosenberg, J., "Simple Traversal Underneath Network Address 590 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 (work 591 in progress), October 2006. 593 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 594 Session Description Protocol (SDP)", RFC 3264, June 2002. 596 [3] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 597 Session Description Protocol (SDP)", RFC 4145, September 2005. 599 [4] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP 600 Control Protocol (RTCP) Packets over Connection-Oriented 601 Transport", RFC 4571, July 2006. 603 [5] Lennox, J., "Connection-Oriented Media Transport over the 604 Transport Layer Security (TLS) Protocol in the Session 605 Description Protocol (SDP)", RFC 4572, July 2006. 607 [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 608 Methodology for Network Address Translator (NAT) Traversal for 609 Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in 610 progress), January 2007. 612 [7] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 613 Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in 614 progress), October 2006. 616 13.2. Informative References 618 [8] Guha, S., "NAT Behavioral Requirements for TCP", 619 draft-ietf-behave-tcp-05 (work in progress), February 2007. 621 [9] Campbell, B., "The Message Session Relay Protocol", 622 draft-ietf-simple-message-sessions-19 (work in progress), 623 February 2007. 625 Author's Address 627 Jonathan Rosenberg 628 Cisco 629 Edison, NJ 630 US 632 Email: jdrosen@cisco.com 633 URI: http://www.jdrosen.net 635 Full Copyright Statement 637 Copyright (C) The IETF Trust (2007). 639 This document is subject to the rights, licenses and restrictions 640 contained in BCP 78, and except as set forth therein, the authors 641 retain all their rights. 643 This document and the information contained herein are provided on an 644 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 645 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 646 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 647 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 648 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 649 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 651 Intellectual Property 653 The IETF takes no position regarding the validity or scope of any 654 Intellectual Property Rights or other rights that might be claimed to 655 pertain to the implementation or use of the technology described in 656 this document or the extent to which any license under such rights 657 might or might not be available; nor does it represent that it has 658 made any independent effort to identify any such rights. Information 659 on the procedures with respect to rights in RFC documents can be 660 found in BCP 78 and BCP 79. 662 Copies of IPR disclosures made to the IETF Secretariat and any 663 assurances of licenses to be made available, or the result of an 664 attempt made to obtain a general license or permission for the use of 665 such proprietary rights by implementers or users of this 666 specification can be obtained from the IETF on-line IPR repository at 667 http://www.ietf.org/ipr. 669 The IETF invites any interested party to bring to its attention any 670 copyrights, patents or patent applications, or other proprietary 671 rights that may cover technology that may be required to implement 672 this standard. Please address the information to the IETF at 673 ietf-ipr@ietf.org. 675 Acknowledgment 677 Funding for the RFC Editor function is provided by the IETF 678 Administrative Support Activity (IASA).