idnits 2.17.1 draft-rosenberg-mmusic-ice-tcp-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 672. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 241: '... TCP, the agent SHOULD obtain a set o...' RFC 2119 keyword, line 246: '... [4] can run over TCP [8]. As such, it is RECOMMENDED that both UDP...' RFC 2119 keyword, line 250: '... it is RECOMMENDED that agents be co...' RFC 2119 keyword, line 294: '... MUST NOT initiate the connection fr...' RFC 2119 keyword, line 301: '...date, the client SHOULD NOT attempt an...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2005) is 6759 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3489 (ref. '1') (Obsoleted by RFC 5389) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-05 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-11 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: April 20, 2006 October 17, 2005 6 TCP Alternatives with Interactive Connectivity Establishment (ICE 7 draft-rosenberg-mmusic-ice-tcp-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 20, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Interactive Connectivity Establishment (ICE) defines a mechanism for 41 NAT traversal for multimedia communication protocols based on the 42 offer/answer model of session negotiation. ICE works by providing a 43 set of candidate transport addresses for each media stream, which are 44 then validated with peer-to-peer connectivity checks based on Simple 45 Traversal of UDP over NAT (STUN). ICE provides a general framework 46 for describing alternates, but only defines UDP-based transport 47 protocols. This specification extends ICE to TCP-based media, 48 including the ability to offer a mix of TCP and UDP-based candidates 49 for a single stream. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 4 55 3. Gathering Addresses . . . . . . . . . . . . . . . . . . . . 6 56 4. Prioritization . . . . . . . . . . . . . . . . . . . . . . . 8 57 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 6. Ordering the Candidate Pairs . . . . . . . . . . . . . . . . 9 59 7. Performing the Connectivity Checks . . . . . . . . . . . . . 9 60 8. Promoting a Candidate to Active . . . . . . . . . . . . . . 12 61 9. Learning New Candidates from Connectivity Checks . . . . . . 12 62 10. Subsequent Offers . . . . . . . . . . . . . . . . . . . . . 12 63 11. Binding Keepalives . . . . . . . . . . . . . . . . . . . . . 13 64 12. Security Considerations . . . . . . . . . . . . . . . . . . 14 65 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 66 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 14.1 Normative References . . . . . . . . . . . . . . . . . . 14 68 14.2 Informative References . . . . . . . . . . . . . . . . . 14 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 70 Intellectual Property and Copyright Statements . . . . . . . 16 72 1. Introduction 74 Interactive Connectivity Establishment (ICE) [5] defines a mechanism 75 for NAT traversal for multimedia communication protocols based on the 76 offer/answer model [2] of session negotiation. ICE works by 77 providing a set of candidate transport addresses for each media 78 stream, which are then validated with peer-to-peer connectivity 79 checks based on Simple Traversal of UDP over NAT (STUN) [1]. ICE 80 provides a general framework for describing alternates, but only 81 defines procedures for UDP-based transport protocols. 83 There are many reasons why ICE support for TCP is important. 84 Firstly, there are media protocols that run over TCP. Examples of 85 such protocols are web and application sharing and instant messaging 86 [7]. For these protocols to work in the presence of NAT, unless they 87 define their own nat traversal mechanisms, ICE support for TCP is 88 needed. In addition, RTP itself can run over TCP [8]. Typically, it 89 is preferable to run RTP over UDP, and not TCP. However, in a 90 variety of network environments, overly restrictive NAT and firewall 91 devices prevent UDP-based communications altogether, but general TCP- 92 based communications are permitted. In such environments, sending 93 RTP over TCP, and thus establishing the media session, may be 94 preferable to having it fail altogether. With ICE, agents can gather 95 both UDP and TCP candidates for an RTP-based stream, list the UDP 96 ones with higher priority, and then only use the TCP-based ones if 97 the UDP ones fail altogether. This provides a fallback mechanism 98 that allows multimedia communicatoins to be highly reliable. 100 The usage of RTP over TCP is particularly useful when combined with 101 TURN. In that usage, one of the agents would connect to its TURN 102 server using TCP, and obtain a TCP-based transport address. It would 103 offer this up to its peer agent as a candidate. That agent would 104 initiate a TCP connection towards the TURN server. When that 105 connection is established, media can flow over the connections, 106 through the relay. The benefit of this usage is that it only 107 requires the agents to make outbound TCP connections to a server on 108 the public network. This kind of operation is broadly interoperable 109 through NAT and firewall devices. Since it is a goal of ICE and this 110 extension to provide highly reliable communications that "just works" 111 in as a broad a set of network deployments as possible, this usage is 112 particularly important. 114 This specification extends ICE by defining its usage with TCP-based 115 candidates. ICE indicates in each of its sections where there is 116 transport-specific logic. It requests that specifications which 117 define usage of ICE with other transport protocols - as this one does 118 - define a version of that logic. This specification does so by 119 following the outline of ICE itself, and calling out the transport 120 protocol specific logic needed in each section. 122 2. Overview of Operation 124 The usage of ICE with TCP is relatively straightforward. The main 125 area of specification is around how and when connections are opened, 126 and how those connections relate to transport address pairs and 127 candidates. 129 When the agents perform address allocations to gather TCP-based 130 candidates, the transport addresses they obtain are always used in a 131 passive mode. As such, a candidate pair formed through an offer/ 132 answer exchange will contain a pair of transport addresses, both of 133 which can only be used in passive mode. When it comes time to 134 perform a connectivity check on the candidate pair, both sides open a 135 TCP connection, but do so from an ephemeral port on the same 136 interface as their passive transport address. If the connection 137 setup succeeds, the active side sends a STUN Binding Request over the 138 connection. With TCP, the STUN Binding Requests are not so much for 139 validation of connectivity (which TCP itself will provide), but 140 rather, identification of the connection and correlation of it with a 141 peer agent. 143 Since the connection was opened from a different port, the agent will 144 see a new source IP address and port in the Binding Request. This 145 will result in the creation of a new peer-derived TCP candidate and a 146 candidate pair. If the connection attempt succeeded in the other 147 direction, a second peer-derived TCP candidate and candidate pair 148 would be created. The peer-derived candidate pairs each hold a 149 single TCP connection, whereas the original candidate pair will never 150 hold any. Effectively, the original candidate pair only serves the 151 purpose of spawning peer-derived candidate pairs that actually 152 contain the TCP connections. 154 This is shown pictorially in Figure 1. The picture shows two agents 155 L and R. Agent L has an IP interface with IP address M, and agent R 156 has one with IP address N. Agent L binds to a TCP port on interface M 157 with port X, and Agent R binds to a TCP port on interface N with port 158 A. An offer answer exchange takes place, resulting in a candidate 159 pair with a transport address pair containing M:X and N:A. When this 160 candidate pair is selected for a connectivity check, agent L 161 initiates the connection on interface M, but from ephemeral port Y. 162 The connection is opened to N:A. Similarly, agent R opens a 163 connection from interface N, but from ephemeral port B. The 164 connection is opened to M:X. Each agent sends a STUN Binding Request 165 over the connection it opened. This will result in a pair of peer 166 derived candidates, each with a transport address pair and a TCP 167 connection. One contains the transport address pair {N:B,M:X} and 168 the connection with that 5-tuple, and the other contains the 169 transport address pair {M:Y,N:A} and the connection with that 170 5-tuple. Note how there is no TCP connection associated with the 171 original candidate pair. 173 Agent Agent 174 L R 176 +-----+ +-----+ 177 ............. ............ 178 ....................................... 179 . . | | . . | | . . Original 180 . . | X |^ . . | A | . . Candidate 181 . ........| \ . . ^| ....... . Pair 182 ....................................... 183 | |. \ . / |. | 184 | | . \ . . / . | 185 | | . \. . .| | 186 | | . . / . . | | 187 | | .. \/ . | | 188 | | .. /\ . . | | 189 | | . . \. .| | 190 | | . / . .\ . | 191 | | . / . \ |. | 192 | | . / . . \ | . | 193 .......... / . . \ | ....... 194 Peer-Derived. | | / . . \| | .Peer-Derived 195 Candidate . | Y |/ . . | B | .Candidate 196 Pair . | | . . | | .Pair 197 ............ ........... 198 | | | | 199 +-----+ +-----+ 201 Interface Interface 202 M N 204 Figure 1 206 Because of the reliable nature of TCP, a Binding Request is needed 207 only from the active side of the connection to the passive side, 208 entirely for identification purposes. Once complete, the peer- 209 derived candidate pair and its connection are valid, and can be 210 promoted to the m/c-line. 212 The reason why connections are not opened from the same port as the 213 transport address is that doing so would produce a simultaneous open 214 between the agents in many cases. True simultaneous opens fail to 215 work through many NATs, therefore defeating the purpose of this 216 specification. 218 When a TCP-based candidate is promoted to the m/c-line, the SDP 219 extensions for connection oriented media [3] are used to signal that 220 an existing connection should be used, rather than opening a new one. 221 In addition, the original candidate is no longer listed with 222 a=candidate attributes. This is to prevent usage of STUN for 223 keepalives. Separating STUN from the media data over the same TCP 224 connection may not be possible, and for this reason application-layer 225 keepalives are used with TCP. 227 3. Gathering Addresses 229 Section 7.1 of ICE defines the procedures for gathering of transport 230 addresses for usage in candidates. These procedures are defined for 231 local candidates, STUN-derived candidates and TURN-derived 232 candidates. ICE indicates that these procedures are transport 233 protocol specific, and requires extensions to ICE to define 234 procedures for other transport protocols. This section defines those 235 procedures for TCP. 237 For each TCP-only media stream the agent wishes to use, the agent 238 obtains a set of candidates by binding to N ephemeral TCP ports on 239 each interface, where N is the number of transport addresses needed 240 for the candidate. For media streams that can support either UDP or 241 TCP, the agent SHOULD obtain a set of candidates by binding to N 242 ephemeral UDP and N ephemeral TCP ports on each interface, where N is 243 the number of transport addresses needed for the candidate. 245 Media streams carried using the Real Time Transport Protocol (RTP) 246 [4] can run over TCP [8]. As such, it is RECOMMENDED that both UDP 247 and TCP candidates be obtained. However, providers of real-time 248 communications services may decide that it is preferable to have no 249 media at all than it is to have media over TCP. To allow for choice, 250 it is RECOMMENDED that agents be configurable with whether they 251 obtain TCP candidates for real time media. 253 Having it be configurable, and then configuring it to be off, is 254 far better than not having the capability at all. An important 255 goal of this specification is to provide a single mechanism that 256 can be used across all types of endpoints. As such, it is 257 preferable to account for provider and network variation through 258 configuration, instead of hard-coded limitations in an 259 implementation. Furthermore, network characteristics and 260 connectivity assumptions can, and will change over time. Just 261 because a agent is communicating with a server on the public 262 network today, doesn't mean that it won't need to communicate with 263 one behind a NAT tomorrow. Just because a agent is behind a full 264 cone NAT today, doesn't mean that tomorrow they won't pick up 265 their agent and take it to a public network access point where 266 there is a symmetric NAT or one that only allows outbound TCP. 267 The way to handle these cases and build a reliable system is for 268 agents to implement a diverse set of techniques for allocating 269 addresses, so that at least one of them is almost certainly going 270 to work in any situation. Implementors should consider very 271 carefully any assumptions that they make about deployments before 272 electing not to implement one of the mechanisms for address 273 allocation. In particular, implementors should consider whether 274 the elements in the system may be mobile, and connect through 275 different networks with different connectivity. They should also 276 consider whether endpoints which are under their control, in terms 277 of location and network connectivity, would always be under their 278 control. Only in cases where there isn't now, and never will be, 279 endpoint mobility or nomadicity of any sort, should a technique be 280 omitted. 282 STUN-based candidates for TCP streams are not possible, since STUN 283 only works with UDP. 285 To obtain a TURN-derived TCP candidates, the client takes a local TCP 286 candidate, and for each configured TURN server, produces a TCP TURN 287 candidate. It is anticipated that clients may have a multiplicity of 288 TURN servers configured in network environments where there are 289 multiple layers of NAT, and that layering is known to the provider of 290 the client. To produce the TURN candidate from a local candidate, it 291 iterates through the local transport addresses in the local 292 candidate, and for for each one, initiates a TCP connection from the 293 same interface of the local transport address to the TURN server. It 294 MUST NOT initiate the connection from the actual port in the local 295 transport address, but rather, from an ephemeral port. Following the 296 procedures of Section 8 of [6], it initiates an Allocate Request 297 transaction over the connection. The Allocate Response will provide 298 the client with its TCP TURN derived transport address in the MAPPED- 299 ADDRESS attribute. Once the TURN allocations against a particular 300 TURN server succeed from all of the transport addresses in a 301 particular local candidate, the client SHOULD NOT attempt any further 302 TURN allocations to that particular server from the transport 303 addresses in any other local candidates. 305 Like its UDP counterparts, TCP-based TURN allocations are paced out 306 at one every Ta seconds. This pacing refers to the establishment of 307 a TCP connection to the server and the subsequent TURN request. That 308 is, every Ta seconds, the agent will open a new TCP connection and 309 send a TURN Allocate request. 311 4. Prioritization 313 Section 7.2 of ICE defines guidelines for prioritizing the set of 314 candidates learned through the gathering process. It specifies that 315 if there are considerations that are specific to the transport 316 protocol, these considerations should be called out in the ICE 317 extension which defines usage with that transport protocol. This 318 section describes considerations specific to TCP. 320 The transport protocol itself is a criteria for choosing one 321 candidate over another. If a particular media stream can run over 322 UDP or TCP, the UDP candidates might be preferred over the TCP 323 candidates. This allows ICE to use the lower latency UDP 324 connectivity if it exists, but fallback to TCP if UDP doesn't work. 326 Section 7.2 of ICE also defines guidelines for selecting an active 327 candidate in the initial offer. It specifies that if there are 328 considerations that are specific to the transport protocol, these 329 considerations should be called out in the ICE extension which 330 defines usage with that transport protocol. This section describes 331 considerations specific to TCP. 333 When TCP-based media streams are used with ICE, the ICE mechanisms 334 described here are responsible for opening the connections and 335 testing them. Once validated, they are promoted to active and then, 336 and only then, can be used for media transport. For this reason, in 337 an initial offer, prior to validation, the active candidate will 338 either be non-TCP (for example, with RTP, it is anticipated that the 339 active candidate would be UDP-based, with TCP candidates as lower 340 priority alternatives), or there is no active candidate. 342 5. Encoding 344 Section 7.3 of ICE defines procedurs for encoding the candidates into 345 an SDP offer or answer. It specifies that if there are 346 considerations that are specific to the transport protocol, these 347 considerations should be called out in the ICE extension which 348 defines usage with that transport protocol. This section describes 349 considerations specific to TCP. 351 TCP-based candidates are encoded into a=candidate lines identically 352 to the UDP encoding described in [5]. However, the transport 353 protocol is set to "tcp" rather than "udp". 355 Encoding of the active candidate in the m/c-line, however, requires 356 special considerations for TCP. If there is no active candidate, the 357 media session MUST include an a=holdconn attribute as defined in RFC 358 4145 [3]. This has the effect of suspending opening of the TCP 359 connections - exactly the desired effect since they are opened by the 360 procedures defined in this specification. The IP address and port 361 encoded into the m/c-line are inconsequential, since they are never 362 used anyway. 364 If there is an active candidate, it will be because a candidate pair 365 has been validated. The m/c-line contains the native IP address and 366 port for the candidate, which will be the ephemeral port if the agent 367 had opened the connection. This is in contrast to RFC 4145, which 368 recommends that the active side of a connection place a port with 369 value '9'. In addition, the media session MUST NOT contain the 370 a=holdconn attribute. It MUST contain the a=active attribute if the 371 agent had opened the TCP connection corresponding to the active 372 candidate, and a=passive if it had been the passive side of the 373 connection. Finally, the media session MUST contain the a=existing 374 attribute, indicating that an existing connection is to be used, 375 rather than opening a new one. 377 6. Ordering the Candidate Pairs 379 Section 7.5 of ICE defines procedurs for ordering the candidates into 380 an SDP offer or answer. It specifies that if there are 381 considerations that are specific to the transport protocol, these 382 considerations should be called out in the ICE extension which 383 defines usage with that transport protocol. This section describes 384 considerations specific to TCP. 386 ICE defines two orderings for candidate pairs - a priority order and 387 a check order. These differ only by the position of the active 388 candidate in the list. However, with TCP, prior to validation, there 389 is no active TCP candidate. As a consequence, the two lists are 390 equivalent if there is no active candidate. 392 7. Performing the Connectivity Checks 394 Section 7.6 of ICE defines procedures for performing the connectivity 395 checks. These are based on a state machine that captures 396 progressions of the checks. This state machine is specific to the 397 transport protocol, and the version for TCP is described here. 399 The set of states visited by the offerer and answerer are depicted 400 graphically in Figure 2 401 | 402 |Start 403 | 404 | 405 V 406 +------------+ 407 +------| |------+ 408 Cnxn Attempt | | | | Get Req. 409 ------------ | | Waiting | | -------- 410 Accept | | | | Send Res. 411 +----->| |<-----+ 412 +------------+ 413 | 414 | Timer Ta 415 | --------. 416 | Open Conn, 417 V Send Req 418 +------------+ 419 | | 420 |new pair | | |new pair 421 |learned | Testing | |learned 422 |from | | |from 423 |Response | | |Request 424 | +------------+ | 425 | | | 426 | | Error | 427 | | ----- | 428 | | - | 429 | V | 430 | +------------+ | 431 | | | | 432 | | | | 433 | | Invalid | | 434 | | | | 435 | | | | 436 | +------------+ | 437 | ^ | 438 | | Error | 439 | | ----- | 440 | | - | 441 | +------------+ | 442 | | | | 443 | | | | 444 +-------------->| Valid |<-------------+ 445 | | 446 | | 447 +------------+ 449 Figure 2 451 The state machine has four states - waiting, testing, Valid and 452 Invalid. Initially, all transport address pairs start in the waiting 453 state. In this state, the agent waits for one of a chance to open a 454 connection and send a Binding Request. 456 STUN Binding Requests and Responses are mapped to transport address 457 pairs and their state machines as described in Section 7.6 of ICE. 459 Every Ta seconds, the agent starts a new connectivity check for a 460 transport address pair. The check is started for the first transport 461 address pair in the transport address pair check ordered list that is 462 in the Waiting state. The state machine for this transport address 463 pair is moved to the Testing state, and the agent opens a TCP 464 connection to the remote transport address in the transport address 465 pair, and do so "from" its native transport address. Here, "from" 466 means something different than the UDP case. If the native transport 467 address is a local transport address, the agent opens the TCP 468 connection from the same IP interface used to obtain the local 469 transport address, but from a different and ephemeral port. Indeed, 470 that port MUST NOT be the same as the port in the local transport 471 address. If the native transport address is a TURN-derived TCP 472 transport address, no attempt is made to open a connection at all. 473 TURN-derived TCP transport addresses can only be used in passive 474 mode. 476 Once the connection is opened, the agent sends a STUN Binding Request 477 according to the procedures of Section 7.7 of ICE. That section 478 indicates that STUN extensions should define any transport specific 479 considerations for transmission of the STUN request. In the case of 480 TCP, the STUN request is sent on the connection that was just opened. 481 The STUN request is not retransmitted. STUN messages include length 482 indicators, allowing them to be framed over a connection-oriented 483 transport protocol. 485 If, while in the Waiting state, the agent receives a connection setup 486 attempt on one of its candidates, it creates the connection. If it 487 receives a STUN Binding Request, it generates a response according to 488 the procedures in Section 7.8 of ICE, including generation of the 489 MAPPED-ADDRESS attribute in the response. Note that, in the case of 490 TCP, there is no need to disambiguate STUN and media traffic sent 491 over the same connection. When a connection is opened initially, the 492 first packet sent (and received) is a stun message. No further STUN 493 messages are sent; the connection is either eventually torn down, or 494 promoted to active, in which case media packets will follow. 496 If the STUN transaction produces an error, the state machine moves 497 into the Invalid state. Note that there is no change of state if it 498 produces a success response. Rather, that response will yield a new 499 peer-derived transport address and corresponding state machine that 500 moves directly to the Valid state, as described below. Similarly, if 501 an agent receives a STUN request that generates a success response, a 502 peer derived transport address is created, and its corresponding 503 transport address pair moves to the Valid state. 505 8. Promoting a Candidate to Active 507 Promotion of a candidate to active occurs as described in Section 7.9 508 of ICE. The only difference to note is that, with TCP, the candidate 509 pair priority ordered list and candidate pair check ordered list are 510 identical, since there is no active TCP candidate. As a consequence, 511 as soon as a candidate is validated, if it is the first in the 512 priority list, an offer is sent immediately. Otherwise, timer Tws is 513 set, and the offer will be sent when it fires. 515 9. Learning New Candidates from Connectivity Checks 517 Section 7.10 of ICE describes procedures for learning new candidates 518 from connectivity checks. ICE indicates that the behavior of the 519 state machines are transport protocol specific, and extensions to ICE 520 for new transport protocols are asked to describe the behavior of the 521 state machines. This section does so for TCP. 523 Firstly, it is important to realize that a successul TCP connection 524 attempt and STUN connectivity check will always result in a peer- 525 derived candidate being constructed. ICE talks about learning new 526 peer-derived candidates as a consequence of symmetric NAT. Here, 527 they are learned as a consequence of opening TCP connections from an 528 ephemeral port. 530 When a new peer-derived candidate is formed as a result of receipt of 531 a STUN Binding Request that generates a successful response, the 532 state machine for that candidate enters the Valid state. Unlike UDP, 533 a Binding Request is not sent back to the source of the request. 534 Similarly, when a new peer-derived candidate is formed as a result of 535 receipt of a successful STUN Binding Response, the state machine for 536 that candidate enters the Valid state. In both cases, the new 537 candidate pair is inserted into the ordered list of pairs and 538 processing follows the logic described in Section 7. 540 10. Subsequent Offers 542 Section 7.11 of ICE describes procedures for subsequent offer/answer 543 exchanges. ICE indicates that if there are any considerations that 544 are transport protocol specific, new transport protocols are asked to 545 describe them. This section does so for TCP. 547 The procedures defined in Section 7.11 of ICE apply to TCP as 548 defined. However, if a candidate is not valid, it MUST NOT be placed 549 into the m/c-line of a subsequent offer or answer. Only valid 550 candidates are placed into the m/c-line for TCP. This is in contrast 551 to UDP, where a partially valid one can be used. 553 Once the offer/answer exchange has completed, the m/c-lines from each 554 agent, when put together, identify a complete 5-tuple. This 5-tuple 555 is used to identify the TCP connection on which media can now be 556 sent. 558 In addition, if a candidate pair is removed as a consequence of the 559 processing defined in Section 7.11, and that candidate pair was TCP- 560 based, its corresponding TCP connection (if any) is torn down. 562 Additional considerations do apply, however, to the usage of RFC 4145 563 attributes in the m/c-line. The offerer will include the a=existing 564 and either a=active or a=inactive attributes in the m-line, depending 565 on whether the agent had opened or closed the connection. When the 566 answerer receives this, it follows the procedures of RFC 4145 to 567 generate the attributes in the response. It MUST indicate that the 568 existing connection is being reused, by including an a=existing 569 attribute in the answer. 571 Furthermore, RFC 4145 defines the a=existing attribute to mean the 572 reuse of the existing connection established as a consequence of RFC 573 4145 processing for this media stream. This specification broadens 574 that definition. The existing connection can also be one established 575 as a consequence of the mechanisms defined in this specification, and 576 the specific TCP connection to use is defined by the 5-tuple 577 constructed from the m/c-line in the offer and the m/c-line in the 578 answer. 580 RFC 4145 also describes TCP connection lifecycle management 581 procedures. If the TCP connection used in the m/c-line was opened by 582 ICE processing, it is closed by ICE processing as well. This occurs 583 when the session terminates, or when the generating candidate for the 584 active one ceases to be retained in a subsequent offer/answer 585 exchange. 587 11. Binding Keepalives 589 As mention in ICE, STUN-based keepalives are not used for TCP-based 590 media streams. Instead, application layer keepalives MUST be used. 591 For RTP, the considerations described in Section 7.12 of ICE for 592 communicating with non-ICE endpoints apply to the selection of a 593 keepalive mechanism. 595 12. Security Considerations 597 13. IANA Considerations 599 There are no IANA considerations associated with this specification. 601 14. References 603 14.1 Normative References 605 [1] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - 606 Simple Traversal of User Datagram Protocol (UDP) Through Network 607 Address Translators (NATs)", RFC 3489, March 2003. 609 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 610 Session Description Protocol (SDP)", RFC 3264, June 2002. 612 [3] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 613 Session Description Protocol (SDP)", RFC 4145, September 2005. 615 [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 616 "RTP: A Transport Protocol for Real-Time Applications", 617 RFC 3550, July 2003. 619 [5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 620 Methodology for Network Address Translator (NAT) Traversal for 621 Offer/Answer Protocols", draft-ietf-mmusic-ice-05 (work in 622 progress), July 2005. 624 [6] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 625 draft-rosenberg-midcom-turn-08 (work in progress), 626 September 2005. 628 14.2 Informative References 630 [7] Campbell, B., "The Message Session Relay Protocol", 631 draft-ietf-simple-message-sessions-11 (work in progress), 632 July 2005. 634 [8] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- 635 Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06 636 (work in progress), September 2005. 638 Author's Address 640 Jonathan Rosenberg 641 Cisco Systems 642 600 Lanidex Plaza 643 Parsippany, NJ 07054 644 US 646 Phone: +1 973 952-5000 647 Email: jdrosen@cisco.com 648 URI: http://www.jdrosen.net 650 Intellectual Property Statement 652 The IETF takes no position regarding the validity or scope of any 653 Intellectual Property Rights or other rights that might be claimed to 654 pertain to the implementation or use of the technology described in 655 this document or the extent to which any license under such rights 656 might or might not be available; nor does it represent that it has 657 made any independent effort to identify any such rights. Information 658 on the procedures with respect to rights in RFC documents can be 659 found in BCP 78 and BCP 79. 661 Copies of IPR disclosures made to the IETF Secretariat and any 662 assurances of licenses to be made available, or the result of an 663 attempt made to obtain a general license or permission for the use of 664 such proprietary rights by implementers or users of this 665 specification can be obtained from the IETF on-line IPR repository at 666 http://www.ietf.org/ipr. 668 The IETF invites any interested party to bring to its attention any 669 copyrights, patents or patent applications, or other proprietary 670 rights that may cover technology that may be required to implement 671 this standard. Please address the information to the IETF at 672 ietf-ipr@ietf.org. 674 Disclaimer of Validity 676 This document and the information contained herein are provided on an 677 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 678 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 679 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 680 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 681 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 682 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 684 Copyright Statement 686 Copyright (C) The Internet Society (2005). This document is subject 687 to the rights, licenses and restrictions contained in BCP 78, and 688 except as set forth therein, the authors retain all their rights. 690 Acknowledgment 692 Funding for the RFC Editor function is currently provided by the 693 Internet Society.