idnits 2.17.1 draft-ietf-ice-trickle-14.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 3 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2017) is 2419 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-mmusic-trickle-ice-sip-08 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6336 (Obsoleted by RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Atlassian 4 Intended status: Standards Track E. Rescorla 5 Expires: March 15, 2018 RTFM, Inc. 6 J. Uberti 7 Google 8 P. Saint-Andre 9 Jabber.org 10 September 11, 2017 12 Trickle ICE: Incremental Provisioning of Candidates for the Interactive 13 Connectivity Establishment (ICE) Protocol 14 draft-ietf-ice-trickle-14 16 Abstract 18 This document describes "Trickle ICE", an extension to the 19 Interactive Connectivity Establishment (ICE) protocol that enables 20 ICE agents to send and receive candidates incrementally rather than 21 exchanging complete lists. With such incremental provisioning, ICE 22 agents can begin connectivity checks while they are still gathering 23 candidates and considerably shorten the time necessary for ICE 24 processing to complete. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 15, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Determining Support for Trickle ICE . . . . . . . . . . . . . 5 63 4. Conveying the Initial ICE Description . . . . . . . . . . . . 6 64 5. Responder Procedures . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Conveying the Initial Response . . . . . . . . . . . . . 7 66 5.2. Forming Check Lists and Beginning Connectivity 67 Checks . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Initiator Procedures . . . . . . . . . . . . . . . . . . . . 8 69 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 8 70 7.1. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 8 71 7.2. Check List and Timer State Updates . . . . . . . . . . . 9 72 8. Discovering and Conveying Additional Local Candidates . . . . 10 73 8.1. Pairing Newly Learned Candidates and Updating 74 Check Lists . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1.1. Inserting a New Pair in a Check List . . . . . . . . 12 76 8.2. Announcing End of Candidates . . . . . . . . . . . . . . 15 77 9. Receiving Additional Remote Candidates . . . . . . . . . . . 17 78 10. Receiving an End-Of-Candidates Indication . . . . . . . . . . 17 79 11. Trickle ICE and Peer Reflexive Candidates . . . . . . . . . . 17 80 12. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 18 81 13. Subsequent Exchanges . . . . . . . . . . . . . . . . . . . . 18 82 14. Unilateral Use of Trickle ICE (Half Trickle) . . . . . . . . 18 83 15. Requirements for Signaling Protocols . . . . . . . . . . . . 19 84 16. Preserving Candidate Order while Trickling . . . . . . . . . 20 85 17. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 21 86 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 87 19. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 89 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 21.1. Normative References . . . . . . . . . . . . . . . . . . 22 91 21.2. Informative References . . . . . . . . . . . . . . . . . 22 92 Appendix A. Interaction with Regular ICE . . . . . . . . . . . . 24 93 Appendix B. Interaction with ICE Lite . . . . . . . . . . . . . 25 94 Appendix C. Changes from Earlier Versions . . . . . . . . . . . 26 95 C.1. Changes from draft-ietf-ice-trickle-12 . . . . . . . . . 26 96 C.2. Changes from draft-ietf-ice-trickle-11 . . . . . . . . . 26 97 C.3. Changes from draft-ietf-ice-trickle-10 . . . . . . . . . 27 98 C.4. Changes from draft-ietf-ice-trickle-09 . . . . . . . . . 27 99 C.5. Changes from draft-ietf-ice-trickle-08 . . . . . . . . . 27 100 C.6. Changes from draft-ietf-ice-trickle-07 . . . . . . . . . 27 101 C.7. Changes from draft-ietf-ice-trickle-06 . . . . . . . . . 27 102 C.8. Changes from draft-ietf-ice-trickle-05 . . . . . . . . . 27 103 C.9. Changes from draft-ietf-ice-trickle-04 . . . . . . . . . 27 104 C.10. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 28 105 C.11. Changes from draft-ietf-ice-trickle-02 . . . . . . . . . 28 106 C.12. Changes from draft-ietf-ice-trickle-01 . . . . . . . . . 28 107 C.13. Changes from draft-ietf-ice-trickle-00 . . . . . . . . . 28 108 C.14. Changes from draft-mmusic-trickle-ice-02 . . . . . . . . 28 109 C.15. Changes from draft-ivov-01 and draft-mmusic-00 . . . . . 29 110 C.16. Changes from draft-ivov-00 . . . . . . . . . . . . . . . 29 111 C.17. Changes from draft-rescorla-01 . . . . . . . . . . . . . 30 112 C.18. Changes from draft-rescorla-00 . . . . . . . . . . . . . 30 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 115 1. Introduction 117 The Interactive Connectivity Establishment (ICE) protocol 118 [rfc5245bis] describes mechanisms for gathering candidates, 119 prioritizing them, choosing default ones, exchanging them with a 120 remote party, pairing them, and ordering the candidate pairs into 121 check lists. Once all of these actions have been completed (and only 122 then), the parties can begin a phase of connectivity checks and 123 eventually select the pair of candidates that will be used in a media 124 session or for a given media stream. 126 Although the sequence described above has the advantage of being 127 relatively straightforward to implement and debug once deployed, it 128 can also be rather lengthy. Candidate gathering often involves 129 things like querying STUN [RFC5389] servers and allocating relayed 130 candidates at TURN [RFC5766] servers. All of these actions can be 131 delayed for a noticeable amount of time; although they can be run in 132 parallel, they still need to respect the pacing requirements from 133 [rfc5245bis], which is likely to delay them even further. Some or 134 all of these actions also need be completed by the responder. Both 135 agents would next perform connectivity checks and only then would 136 they be ready to begin streaming media. 138 These factors can lead to relatively lengthy session establishment 139 times and thus to a degraded user experience. 141 This document defines a supplementary mode of operation for ICE 142 implementations, known as "Trickle ICE", in which candidates can be 143 exchanged incrementally. This enables ICE agents to exchange 144 candidates as soon as an ICE session has been initiated and a 145 candidate has become available. Connectivity checks for a media 146 stream can also start as soon as the first candidates for that stream 147 become available. 149 Trickle ICE can reduce session establishment times in cases where 150 connectivity is confirmed for the first exchanged candidates (e.g., 151 where candidates for one of the agents are directly reachable from 152 the second agent, such as candidates at a media relay). Even when 153 this is not the case, performing candidate gathering for both agents 154 and connectivity checks in parallel can considerably shorten ICE 155 processing times. 157 It is worth noting that there is quite a bit of operational 158 experience with the Trickle ICE technique, going back as far as 2005 159 (when the XMPP Jingle extension defined a "dribble mode" as specified 160 in [XEP-0176]); this document incorporates feedback from those who 161 have implemented and deployed the technique. 163 In addition to the basics of Trickle ICE, this document also 164 describes how to discover support for Trickle ICE, how regular ICE 165 processing needs to be modified when forming and updating check 166 lists, and how Trickle ICE implementations interoperate with agents 167 that only implement regular ICE processing as defined in 168 [rfc5245bis]. 170 This specification does not define the usage of Trickle ICE with any 171 specific signaling protocol (however, see 172 [I-D.ietf-mmusic-trickle-ice-sip] for usage with SIP [RFC3261] and 173 [XEP-0176] for usage with XMPP [RFC6120]). Similarly, it does not 174 define Trickle ICE in terms of the Session Description Protocol (SDP) 175 [RFC4566] or the offer/answer model [RFC3264] because the technique 176 can be and already is used in application protocols that are not tied 177 to SDP or to offer/answer semantics. However, because SDP and the 178 offer/answer model are familiar to most readers of this 179 specification, some examples in this document use those particulars 180 in order to explain the underlying concepts. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 This specification makes use of all terminology defined for 189 Interactive Connectivity Establishment in [rfc5245bis]. In addition, 190 it defines the following terms: 192 Generation: All of the candidates conveyed within an ICE session; 193 these are the candidates that are associated with a specific 194 local/remote ufrag pair (which will change on ICE restart, if any 195 occurs). 197 ICE Description: Any session-related (as opposed to candidate- 198 related) attributes required to configure an ICE agent. These 199 include but are not limited to the username fragment, password, 200 and other attributes. 202 Trickled Candidates: Candidates that a Trickle ICE agent conveys 203 after conveying the initial ICE description or responding to the 204 initial ICE description, but within the same ICE session. 205 Trickled candidates can be conveyed in parallel with candidate 206 gathering and connectivity checks. 208 Trickling: The act of conveying trickled candidates. 210 Half Trickle: A Trickle ICE mode of operation where the initiator 211 gathers a full generation of candidates strictly before creating 212 and conveying the initial ICE description. Once conveyed, this 213 candidate information can be processed by regular ICE agents, 214 which do not require support for this specification. It also 215 allows Trickle ICE capable responders to still gather candidates 216 and perform connectivity checks in a non-blocking way, thus 217 roughly providing "half" the advantages of Trickle ICE. The 218 mechanism is mostly meant for use in cases where the responder's 219 support for Trickle ICE cannot be confirmed prior to conveying the 220 initial ICE description. 222 Full Trickle: The typical mode of operation for Trickle ICE agents, 223 in which the initial ICE description can include any number of 224 candidates (even zero candidates) and does not need to include a 225 full generation of candidates as in half trickle. 227 3. Determining Support for Trickle ICE 229 To fully support Trickle ICE, applications SHOULD incorporate one of 230 the following mechanisms to enable implementations to determine 231 whether Trickle ICE is supported: 233 1. Provide a capabilities discovery method so that agents can verify 234 support of Trickle ICE prior to initiating a session (XMPP's 235 Service Discovery [XEP-0030] is one such mechanism). 237 2. Make support for Trickle ICE mandatory so that user agents can 238 assume support. 240 If an application protocol does not provide a method of determining 241 ahead of time whether Trickle ICE is supported, agents can make use 242 of the half trickle procedure described in Section 14. 244 Prior to conveying the initial ICE description, agents using 245 signaling protocols that support capabilities discovery can attempt 246 to verify whether or not the remote party supports Trickle ICE. If 247 an agent determines that the remote party does not support Trickle 248 ICE, it MUST fall back to using regular ICE or abandon the entire 249 session. 251 Even if a signaling protocol does not include a capabilities 252 discovery method, a user agent can provide an indication within the 253 ICE description that it supports Trickle ICE using a token of 254 "trickle" in the ice-options attribute. This token MUST be provided 255 either at the session level or, if at the media stream level, for 256 every media stream (an agent MUST NOT specify Trickle ICE support for 257 some media streams but not others). 259 Dedicated discovery semantics and half trickle are needed only prior 260 to session initiation. After a session is established and Trickle 261 ICE support is confirmed for both parties, either agent can use full 262 trickle for subsequent exchanges. 264 4. Conveying the Initial ICE Description 266 An initiator can start gathering candidates as soon as it has an 267 indication that communication is imminent (e.g., a user interface cue 268 or an explicit request to initiate a session). Unlike in regular 269 ICE, in Trickle ICE implementations do not need to gather candidates 270 in a blocking manner. Therefore, unless half trickle is being used, 271 the initiator SHOULD generate and transmit their initial ICE 272 description as early as possible, so that the remote party can start 273 gathering and trickling candidates. 275 An initiator MAY include any mix of candidates when conveying the 276 initial ICE description. This includes the possibility of conveying 277 all the candidates the initiator plans to use (as in half trickle 278 mode), conveying only a publicly-reachable IP address (e.g., a 279 candidate at a media relay that is known to not be behind a 280 firewall), or conveying no candidates at all (in which case the 281 initiator can obtain the responder's initial candidate list sooner 282 and the responder can begin candidate gathering more quickly). 284 Methods for calculating priorities and foundations, as well as 285 determining redundancy of candidates, work just as with regular ICE 286 (with the exception of pruning of duplicate peer reflexive candidates 287 as described under Section 5.2). 289 5. Responder Procedures 291 When a responder receives the initial ICE description, it will first 292 check if the ICE description or initiator indicates support for 293 Trickle ICE as explained in Section 3. If this is not the case, the 294 responder MUST process the initial ICE description according to 295 regular ICE procedures [rfc5245bis] (or, if no ICE support is 296 detected at all, according to relevant processing rules for the 297 underlying signaling protocol, such as offer/answer processing rules 298 [RFC3264]). 300 If support for Trickle ICE is confirmed, a responder will 301 automatically assume support for regular ICE as well. Specifically, 302 the rules from [rfc5245bis] would imply that ICE itself is not 303 supported if the initial ICE description includes no candidates; 304 however, such a conclusion is not warranted if the responder can 305 confirm that the initiator supports Trickle ICE; in this case, 306 fallback to [RFC3264] is not necessary. 308 If the initial ICE description indicates support for Trickle ICE, the 309 responder will determine its role and start gathering and 310 prioritizing candidates; while doing so, it will also respond by 311 conveying its own ICE description, so that both the initiator and the 312 responder can start forming check lists and begin connectivity 313 checks. 315 5.1. Conveying the Initial Response 317 A responder can respond to the initial ICE description at any point 318 while gathering candidates. Here again the ICE description MAY 319 contain any set of candidates, including all candidates or no 320 candidates. (The benefit of including no candidates is to convey the 321 ICE description as quickly as possible, so that both parties can 322 consider the overall session to be under active negotiation as soon 323 as possible.) 325 As noted in Section 3, in application protocols that use SDP the 326 responder's ICE description can indicate support for Trickle ICE by 327 including a token of "trickle" in the ice-options attribute. 329 5.2. Forming Check Lists and Beginning Connectivity Checks 331 As soon as the agents have obtained local and remote candidates, both 332 agents begin forming candidate pairs, computing candidate pair 333 priorities, ordering candidate pairs, pruning duplicate pairs, and 334 creating check lists according to regular ICE procedures 335 [rfc5245bis]. 337 According to those procedures, in order for candidate pairing to be 338 possible and for duplicate candidates to be pruned, the candidates 339 would need to be provided in the relevant ICE descriptions. By 340 contrast, under Trickle ICE check lists can be empty until candidates 341 are conveyed or received. Therefore Trickle ICE agents handle check 342 lists and candidate pairing in a slightly different way than regular 343 ICE agents: the agents still form the check lists, but they populate 344 the check lists only after they actually have the candidate pairs. 345 Every check list is initially placed in the Running state, even if 346 there are not yet any candidate pairs in the check list. 348 A Trickle ICE agent initially considers all candidate pairs in all 349 check lists to be frozen. It then inspects the first check list and 350 attempts to unfreeze all candidate pairs it has received so far that 351 belong to the first component on the first media stream (i.e., the 352 first media stream that was reported to the ICE implementation from 353 the using application). If that first component of the first media 354 stream does not contain candidates for one or more of the currently 355 known pair foundations, and if candidate pairs already exist for that 356 foundation in one of the following components or media streams, then 357 the agent unfreezes the first of those candidate pairs. 359 With regard to pruning of duplicate candidate pairs, a Trickle ICE 360 agent SHOULD follow a policy of keeping the higher priority candidate 361 unless it is peer reflexive. 363 6. Initiator Procedures 365 When processing the initial ICE description from a responder, the 366 initiator follows regular ICE procedures to determine its role, after 367 which it forms check lists (as described in Section 5.2) and begins 368 connectivity checks. 370 7. Performing Connectivity Checks 372 For the most part, Trickle ICE agents perform connectivity checks 373 following regular ICE procedures. However, the fact that gathering 374 and communicating candidates is asynchronous in Trickle ICE imposes a 375 number of changes as described in the following sections. 377 7.1. Scheduling Checks 379 The ICE specification [rfc5245bis], Section 5.1.4.2, specifies that 380 an agent will terminate the timer for a triggered check in relation 381 to a check list once the agent has exhausted all frozen pairs in the 382 check list. This will not work with Trickle ICE, because more pairs 383 will be added to the check list incrementally. 385 Therefore, a Trickle ICE agent SHOULD NOT terminate the timer until 386 the state of the check list is Completed or Failed as specified 387 herein (see Section 8.2). 389 7.2. Check List and Timer State Updates 391 The ICE specification [rfc5245bis], Section 6.2.5.3.3, requires that 392 agents update check lists and timer states upon completing a 393 connectivity check transaction. During such an update, regular ICE 394 agents would set the state of a check list to Failed if both of the 395 following two conditions are satisfied: 397 o all of the pairs in the check list are either in the Failed state 398 or Succeeded state; and 400 o there is not a pair in the valid list for each component of the 401 media stream. 403 With Trickle ICE, the above situation would often occur when 404 candidate gathering and trickling are still in progress, even though 405 it is quite possible that future checks will succeed. For this 406 reason, Trickle ICE agents add the following conditions to the above 407 list: 409 o all candidate gathering has completed and the agent is not 410 expecting to discover any new local candidates; 412 o the remote agent has conveyed an end-of-candidates indication for 413 that check list as described in Section 8.2. 415 When a check list is set to Failed as described above, regular ICE 416 requires the agent to update all other check lists, placing one pair 417 from each check list into the Waiting state and thereby effectively 418 placing all remaining check lists into the Running state. However, 419 under Trickle ICE other check lists might still be empty at this 420 point (because candidates have not yet been received), and following 421 only the rules from regular ICE would prevent the agent from forming 422 those check lists (because the state of a check list depends on the 423 state of the candidate pairs in that check list, but there might not 424 yet by any candidate pairs in a given check list). In accordance 425 with the ICE specification [rfc5245bis], Section 5.1.2.1, a Trickle 426 ICE agent considers an empty check list to be in the Running state; 427 in accordance with Section 8.1.1, when inserting a new candidate pair 428 into an empty check list, the agent sets the pair to a state of 429 Waiting. 431 8. Discovering and Conveying Additional Local Candidates 433 After candidate information has been conveyed, agents will most 434 likely continue discovering new local candidates as STUN, TURN, and 435 other non-host candidate gathering mechanisms begin to yield results. 436 Whenever an agent discovers such a new candidate it will compute its 437 priority, type, foundation and component ID according to regular ICE 438 procedures. 440 The new candidate is then checked for redundancy against the existing 441 list of local candidates. If its transport address and base match 442 those of an existing candidate, it will be considered redundant and 443 will be ignored. This would often happen for server reflexive 444 candidates that match the host addresses they were obtained from 445 (e.g., when the latter are public IPv4 addresses). Contrary to 446 regular ICE, Trickle ICE agents will consider the new candidate 447 redundant regardless of its priority. 449 Next the agent "trickles" the newly discovered candidate(s) to the 450 remote agent. The actual delivery of the new candidates is handled 451 by a signaling protocol such as SIP or XMPP. Trickle ICE imposes no 452 restrictions on the way this is done (e.g., some applications may 453 choose not to trickle updates for server reflexive candidates and 454 instead rely on the discovery of peer reflexive ones). 456 When candidates are trickled, the signaling protocol MUST deliver 457 each candidate to the receiving Trickle ICE implementation not more 458 than once and in the same order it was conveyed. If the signaling 459 protocol provides any candidate retransmissions, they need to be 460 hidden from the ICE implementation. 462 Also, candidate trickling needs to be correlated to a specific ICE 463 session, so that if there is an ICE restart, any delayed updates for 464 a previous session can be recognized as such and ignored by the 465 receiving party. For example, applications that choose to signal 466 candidates via SDP may include a ufrag value in the corresponding 467 a=candidate line such as: 469 a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY 471 Or as another example, WebRTC implementations may include a ufrag in 472 the JavaScript objects that represent candidates. 474 Note: The signaling protocol needs to provide a mechanism for both 475 parties to indicate and agree on the ICE session in force (as 476 identified by the ufrag) so that they have a consistent view of which 477 candidates are to be paired. This is especially important in the 478 case of ICE restarts (see Section 13). 480 Once the candidate has been conveyed to the remote party, the agent 481 checks if any remote candidates are currently known for this same 482 stream and component. If not, the new candidate will simply be added 483 to the list of local candidates. 485 Otherwise, if the agent has already learned of one or more remote 486 candidates for this stream and component, it will begin pairing the 487 new local candidates with them and adding the pairs to the existing 488 check lists according to their priority. 490 Note: A Trickle ICE agent MUST NOT pair a local candidate until it 491 has been trickled to the remote agent. 493 8.1. Pairing Newly Learned Candidates and Updating Check Lists 495 Forming candidate pairs works as described in the ICE specification 496 [rfc5245bis]. However, actually adding the new pair to a check list 497 happens according to the rules described below. 499 If the check list where the pair is to be added already contains the 500 maximum number of candidate pairs (100 by default as per 501 [rfc5245bis]), the new pair is discarded. 503 If the new pair's local candidate is server reflexive, the server 504 reflexive candidate MUST be replaced by its base before adding the 505 pair to the list. 507 Once this is done, the agent examines the check list looking for 508 another pair that would be redundant with the new one. If such a 509 pair exists and the type of its remote candidate is not peer 510 reflexive, the pair with the higher priority is kept and the one with 511 the lower priority is discarded. If, on the other hand, the type of 512 the remote candidate in the pre-existing pair is peer reflexive, the 513 agent MUST replace it with the newly formed pair (regardless of their 514 respective priorities); this is done by setting the priority of the 515 new candidate to the priority of the pre-existing candidate and then 516 re-sorting the check list. 518 For all other pairs, including those with a server reflexive local 519 candidate that were not found to be redundant, the rules specified in 520 the following section apply. 522 8.1.1. Inserting a New Pair in a Check List 524 Consider the following tabular representation of all check lists in 525 an agent (note that initially for one of the foundations, i.e., f5, 526 there are no candidate pairs): 528 +-----------------+------+------+------+------+------+ 529 | | f1 | f2 | f3 | f4 | f5 | 530 +-----------------+------+------+------+------+------+ 531 | m1 (Audio.RTP) | F | F | F | | | 532 +-----------------+------+------+------+------+------+ 533 | m2 (Audio.RTCP) | F | F | F | F | | 534 +-----------------+------+------+------+------+------+ 535 | m3 (Video.RTP) | F | | | | | 536 +-----------------+------+------+------+------+------+ 537 | m4 (Video.RTCP) | F | | | | | 538 +-----------------+------+------+------+------+------+ 540 Figure 1: Example of Check List State 542 Each row in the table represents a component for a given media stream 543 (e.g., m1 and m2 might be the RTP and RTCP components for audio). 544 Each column represents one foundation. Each cell represents one 545 candidate pair. In the foregoing table, "F" stands for "frozen"; in 546 the tables below, "W" stands for "waiting" and "S" stands for 547 "succeeded". 549 When an agent commences ICE processing, in accordance with 550 Section 5.1.2.6 of [rfc5245bis] it will unfreeze (i.e., place in the 551 Waiting state) the topmost candidate pair in every column (i.e., the 552 pair with the lowest component ID). This state is shown in the 553 following table, with candidate pairs in the Waiting state marked by 554 "W". 556 +-----------------+------+------+------+------+------+ 557 | | f1 | f2 | f3 | f4 | f5 | 558 +-----------------+------+------+------+------+------+ 559 | m1 (Audio.RTP) | W | W | W | | | 560 +-----------------+------+------+------+------+------+ 561 | m2 (Audio.RTCP) | F | F | F | W | | 562 +-----------------+------+------+------+------+------+ 563 | m3 (Video.RTP) | F | | | | | 564 +-----------------+------+------+------+------+------+ 565 | m4 (Video.RTCP) | F | | | | | 566 +-----------------+------+------+------+------+------+ 568 Figure 2: Initial Check List State 570 Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis]), 571 for each pair that enters the Succeeded state (denoted here by "S"), 572 the agent will unfreeze all pairs for all media streams with the same 573 foundation (e.g., if the pair in column 1, row 1 succeeds then the 574 agent will unfreeze the pair in column 1, rows 2, 3, and 4). 576 +-----------------+------+------+------+------+------+ 577 | | f1 | f2 | f3 | f4 | f5 | 578 +-----------------+------+------+------+------+------+ 579 | m1 (Audio.RTP) | S | W | W | | | 580 +-----------------+------+------+------+------+------+ 581 | m2 (Audio.RTCP) | W | F | F | W | | 582 +-----------------+------+------+------+------+------+ 583 | m3 (Video.RTP) | W | | | | W | 584 +-----------------+------+------+------+------+------+ 585 | m4 (Video.RTCP) | W | | | | F | 586 +-----------------+------+------+------+------+------+ 588 Figure 3: Check List State with Unfrozen Media Stream 590 Trickle ICE preserves all of these rules as they apply to what we 591 might call "static" check list sets. This implies that if, for some 592 reason, a Trickle agent were to begin connectivity checks with all of 593 its pairs already present, the way that pair states change is 594 indistinguishable from that of a regular ICE agent. 596 Of course, the major difference with Trickle ICE is that check list 597 sets can be dynamically updated because candidates can arrive after 598 connectivity checks have started. When this happens, an agent sets 599 the state of the newly formed pair as described below. 601 Case 1: If the newly formed pair is the topmost pair in its column 602 (i.e. the topmost pair among all the check lists for this 603 foundation), set the state to Waiting (e.g., this would be the case 604 if the newly formed pair were placed in column 5, row 1). 606 +-----------------+------+------+------+------+------+ 607 | | f1 | f2 | f3 | f4 | f5 | 608 +-----------------+------+------+------+------+------+ 609 | m1 (Audio.RTP) | S | W | W | | W | 610 +-----------------+------+------+------+------+------+ 611 | m2 (Audio.RTCP) | W | F | F | W | | 612 +-----------------+------+------+------+------+------+ 613 | m3 (Video.RTP) | W | | | | | 614 +-----------------+------+------+------+------+------+ 615 | m4 (Video.RTCP) | W | | | | | 616 +-----------------+------+------+------+------+------+ 618 Figure 4: Check List State with Newly Formed Pair, Case 1 620 Case 2: If the pair immediately above the newly formed pair in its 621 column is in the Succeeded state, set the state to Waiting (e.g., 622 this would be the case if the pair in column 5, row 1 succeeded and 623 the newly formed pair were placed in column 5, row 2); 625 +-----------------+------+------+------+------+------+ 626 | | f1 | f2 | f3 | f4 | f5 | 627 +-----------------+------+------+------+------+------+ 628 | m1 (Audio.RTP) | S | W | W | | S | 629 +-----------------+------+------+------+------+------+ 630 | m2 (Audio.RTCP) | W | F | F | W | W | 631 +-----------------+------+------+------+------+------+ 632 | m3 (Video.RTP) | W | | | | | 633 +-----------------+------+------+------+------+------+ 634 | m4 (Video.RTCP) | W | | | | | 635 +-----------------+------+------+------+------+------+ 637 Figure 5: Check List State with Newly Formed Pair, Case 2 639 Case 3: If there is at least one Succeeded pair in its column above 640 the row of the newly formed pair, set the state to Waiting (e.g., 641 this would be the case if the pair in column 5, row 1 succeeded and 642 two newly formed pairs were placed in column 5, rows 3 and 4). 644 +-----------------+------+------+------+------+------+ 645 | | f1 | f2 | f3 | f4 | f5 | 646 +-----------------+------+------+------+------+------+ 647 | m1 (Audio.RTP) | S | W | W | | S | 648 +-----------------+------+------+------+------+------+ 649 | m2 (Audio.RTCP) | W | F | F | W | W | 650 +-----------------+------+------+------+------+------+ 651 | m3 (Video.RTP) | W | | | | W | 652 +-----------------+------+------+------+------+------+ 653 | m4 (Video.RTCP) | W | | | | W | 654 +-----------------+------+------+------+------+------+ 656 Figure 6: Check List State with Newly Formed Pair, Case 3 658 Case 4: In all other cases, set the state to Frozen. 660 8.2. Announcing End of Candidates 662 Once all candidate gathering is completed or expires for an ICE 663 session associated with a specific media stream, the agent will 664 generate an "end-of-candidates" indication for that session and 665 convey it to the remote agent via the signaling channel. Although 666 the exact form of the indication depends on the application protocol, 667 the indication MUST specify the generation (ufrag/pwd combination) so 668 that an agent can correlate the end-of-candidates indication with a 669 particular ICE session. The indication can be conveyed in the 670 following ways: 672 o As part of an initiation request (which would typically be the 673 case with the initial ICE description for half trickle) 675 o Along with the last candidate an agent can send for a stream 677 o As a standalone notification (e.g., after STUN Binding requests or 678 TURN Allocate requests to a server time out and the agent has is 679 not actively gathering candidates) 681 Conveying an end-of-candidates indication in a timely manner is 682 important in order to avoid ambiguities and speed up the conclusion 683 of ICE processing. In particular: 685 o A controlled Trickle ICE agent SHOULD convey an end-of-candidates 686 indication after it has completed gathering for a media stream, 687 unless ICE processing terminates before the agent has had a chance 688 to complete gathering. 690 o A controlling agent MAY conclude ICE processing prior to conveying 691 end-of-candidates indications for all streams. However, it is 692 RECOMMENDED for a controlling agent to convey end-of-candidates 693 indications whenever possible for the sake of consistency and to 694 keep middleboxes and controlled agents up-to-date on the state of 695 ICE processing. 697 When conveying an end-of-candidates indication during trickling 698 (rather than as a part of the initial ICE description or a response 699 thereto), it is the responsibility of the using protocol to define 700 methods for relating the indication to one or more specific media 701 streams. 703 Receiving an end-of-candidates indication enables an agent to update 704 check list states and, in case valid pairs do not exist for every 705 component in every media stream, determine that ICE processing has 706 failed. It also enables an agent to speed up the conclusion of ICE 707 processing when a candidate pair has been validated but it involves 708 the use of lower-preference transports such as TURN. In such 709 situations, an implementation MAY choose to wait and see if higher- 710 priority candidates are received; in this case the end-of-candidates 711 indication provides a notification that such candidates are not 712 forthcoming. 714 An agent MAY also choose to generate an end-of-candidates indication 715 before candidate gathering has actually completed, if the agent 716 determines that gathering has continued for more than an acceptable 717 period of time. However, an agent MUST NOT convey any more 718 candidates after it has conveyed an end-of-candidates indication. 720 When performing half trickle, an agent SHOULD convey an end-of- 721 candidates indication together with its initial ICE description 722 unless it is planning to potentially trickle additional candidates 723 (e.g., in case the remote party turns out to support Trickle ICE). 725 After an agent conveys the end-of-candidates indication, it will 726 update the state of the corresponding check list as explained in 727 Section 7.2. Past that point, an agent MUST NOT trickle any new 728 candidates within this ICE session. After an agent has received an 729 end-of-candidates indication, it MUST also ignore any newly received 730 candidates for that media stream or media session. Therefore, adding 731 new candidates to the negotiation is possible only through an ICE 732 restart (see Section 13). 734 This specification does not override regular ICE semantics for 735 concluding ICE processing. Therefore, even if end-of-candidates 736 indications are conveyed, an agent will still need to go through pair 737 nomination. Also, if pairs have been nominated for components and 738 media streams, ICE processing MAY still conclude even if end-of- 739 candidates indications have not been received for all streams. 741 9. Receiving Additional Remote Candidates 743 At any time during ICE processing, a Trickle ICE agent might receive 744 new candidates from the remote agent. When this happens and no local 745 candidates are currently known for this same stream, the new remote 746 candidates are added to the list of remote candidates. 748 Otherwise, the new candidates are used for forming candidate pairs 749 with the pool of local candidates and they are added to the local 750 check lists as described in Section 8.1. 752 Once the remote agent has completed candidate gathering, it will 753 convey an end-of-candidates indication. Upon receiving such an 754 indication, the local agent MUST update check list states as per 755 Section 7.2. This might lead to some check lists being marked as 756 Failed. 758 10. Receiving an End-Of-Candidates Indication 760 When an agent receives an end-of-candidates indication for a specific 761 media stream, it will update the state of the relevant check list as 762 per Section 7.2. If the check list is still in the Active state 763 after the update, the agent will persist the fact that an end-of- 764 candidates indication has been received and take it into account in 765 future updates to the check list. 767 11. Trickle ICE and Peer Reflexive Candidates 769 Even though Trickle ICE does not explicitly modify the procedures for 770 handling peer-reflexive candidates, use of Trickle ICE can have an 771 impact on how they are processed. With Trickle ICE, it is possible 772 that server reflexive candidates can be discovered as peer reflexive 773 in cases where incoming connectivity checks are received from these 774 candidates before the trickle updates that carry them. 776 While this would certainly increase the number of cases where ICE 777 processing nominates and selects candidates discovered as peer- 778 reflexive, it does not require any change in processing. 780 It is also likely that some applications would prefer not to trickle 781 server reflexive candidates to entities that are known to be publicly 782 accessible and where sending a direct STUN binding request is likely 783 to reach the destination faster than the trickle update that travels 784 through the signaling path. 786 12. Concluding ICE Processing 788 This specification does not directly modify the procedures for ending 789 ICE processing described in Section 7 of [rfc5245bis], and Trickle 790 ICE implementations follow the same rules. 792 13. Subsequent Exchanges 794 Either agent MAY convey subsequent candidate information at any time 795 allowed by the signaling protocol in use. When this happens, agents 796 will use [rfc5245bis] semantics to determine whether or not the new 797 candidate information require an ICE restart. If an ICE restart 798 occurs, the agents can assume that Trickle ICE is still supported if 799 support was determined previously, and thus can engage in Trickle ICE 800 behavior as they would in an initial exchange of ICE descriptions 801 where support was determined through a capabilities discovery method. 803 14. Unilateral Use of Trickle ICE (Half Trickle) 805 In half trickle mode, the initiator conveys the initial ICE 806 description with a full generation of candidates. This ensures that 807 the ICE description can be processed by a regular ICE responder and 808 is mostly meant for use in cases where support for Trickle ICE cannot 809 be confirmed prior to conveying the initial ICE description. The 810 initial ICE description indicate support for Trickle ICE, which means 811 the responder can respond with something less than a full generation 812 of candidates and then trickle the rest. The initial ICE description 813 for half trickle would typically contain an end-of-candidates 814 indication, although this is not mandatory because if trickle support 815 is confirmed then the initiator can choose to trickle additional 816 candidates before it conveys an end-of-candidates indication. 818 The half trickle mechanism can be used in cases where there is no way 819 for an agent to verify in advance whether a remote party supports 820 Trickle ICE. Because the initial ICE description contain a full 821 generation of candidates, it can thus be handled by a regular ICE 822 agent, while still allowing a Trickle ICE agent to use the 823 optimization defined in this specification. This prevents 824 negotiation from failing in the former case while still giving 825 roughly half the Trickle ICE benefits in the latter (hence the name 826 of the mechanism). 828 Use of half trickle is only necessary during an initial exchange of 829 ICE descriptions. After both parties have received an ICE 830 description from their peer, they can each reliably determine Trickle 831 ICE support and use it for all subsequent exchanges. 833 In some instances, using half trickle might bring more than just half 834 the improvement in terms of user experience. This can happen when an 835 agent starts gathering candidates upon user interface cues that the 836 user will soon be initiating an interaction, such as activity on a 837 keypad or the phone going off hook. This would mean that some or all 838 of the candidate gathering could be completed before the agent 839 actually needs to convey the candidate information. Because the 840 responder will be able to trickle candidates, both agents will be 841 able to start connectivity checks and complete ICE processing earlier 842 than with regular ICE and potentially even as early as with full 843 trickle. 845 However, such anticipation is not always possible. For example, a 846 multipurpose user agent or a WebRTC web page where communication is a 847 non-central feature (e.g., calling a support line in case of a 848 problem with the main features) would not necessarily have a way of 849 distinguishing between call intentions and other user activity. In 850 such cases, using full trickle is most likely to result in an ideal 851 user experience. Even so, using half trickle would be an improvement 852 over regular ICE because it would result in a better experience for 853 responders. 855 15. Requirements for Signaling Protocols 857 In order to fully enable the use of Trickle ICE, this specification 858 defines the following requirements for signaling protocols. 860 o A signaling protocol SHOULD provide a way for parties to advertise 861 and discover support for Trickle ICE before an ICE session begins 862 (see Section 3). 864 o A signaling protocol MUST provide methods for incrementally 865 conveying (i.e., "trickling") additional candidates after 866 conveying the initial ICE description (see Section 8). 868 o A signaling protocol MUST deliver each trickled candidate not more 869 than once and in the same order it was conveyed (see Section 8). 871 o A signaling protocol MUST provide a mechanism for both parties to 872 indicate and agree on the ICE session in force (see Section 8). 874 o A signaling protocol MUST provide a way for parties to communicate 875 the end-of-candidates indication, which MUST specify the 876 particular ICE session to which the indication applies (see 877 Section 8.2). 879 16. Preserving Candidate Order while Trickling 881 One important aspect of regular ICE is that connectivity checks for a 882 specific foundation and component are attempted simultaneously by 883 both agents, so that any firewalls or NATs fronting the agents would 884 whitelist both endpoints and allow all except for the first 885 ("suicide") packets to go through. This is also important to 886 unfreezing candidates at the right time. While not crucial, 887 preserving this behavior in Trickle ICE is likely to improve ICE 888 performance. 890 To achieve this, when trickling candidates, agents MUST respect the 891 order in which the components and streams appear (implicitly or 892 explicitly) as they have been negotiated by means of the relevant 893 candidate information. Therefore a candidate for a specific 894 component MUST NOT be conveyed prior to candidates for other 895 components within the same foundation. In addition, candidates MUST 896 be paired, following the procedures in Section 8.1.1, in the same 897 order they are conveyed. 899 For example, the following SDP description contains two components 900 (RTP and RTCP) and two foundations (host and server reflexive): 902 v=0 903 o=jdoe 2890844526 2890842807 IN IP6 2001:db8:a0b:12f0::1 904 s= 905 c=IN IP6 2001:db8:a0b:12f0::1 906 t=0 0 907 a=ice-pwd:asd88fgpdd777uzjYhagZg 908 a=ice-ufrag:8hhY 909 m=audio 5000 RTP/AVP 0 910 a=rtpmap:0 PCMU/8000 911 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host 912 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host 913 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 914 raddr 2001:db8:a0b:12f0::1 rport 8998 915 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx 916 raddr 2001:db8:a0b:12f0::1 rport 8998 918 For this candidate information the RTCP host candidate MUST NOT be 919 conveyed prior to the RTP host candidate. Similarly the RTP server 920 reflexive candidate MUST be conveyed together with or prior to the 921 RTCP server reflexive candidate. 923 Similar considerations apply at the level of media streams in 924 addition to foundations; this is covered by the requirement to always 925 start unfreezing candidates starting from the first media stream as 926 described under Section 5.2. 928 17. Example Flow 930 As an example, a typical successful Trickle ICE exchange with a 931 signaling protocol that follows the offer/answer model would look 932 this way: 934 Alice Bob 935 | Offer | 936 |---------------------------------------------->| 937 | Additional Candidates | 938 |---------------------------------------------->| 939 | | 940 | Answer | 941 |<----------------------------------------------| 942 | Additional Candidates | 943 |<----------------------------------------------| 944 | | 945 | Additional Candidates and Connectivity Checks | 946 |<--------------------------------------------->| 947 | | 948 |<=============== MEDIA FLOWS =================>| 950 Figure 7: Example 952 18. IANA Considerations 954 IANA is requested to register the following ICE option in the "ICE 955 Options" sub-registry of the "Interactive Connectivity Establishment 956 (ICE) registry", following the procedures defined in [RFC6336]. 958 ICE Option: trickle 960 Contact: Emil Ivov, eivov@atlassian.com 962 Change control: IESG 964 Description: An ICE option of "trickle" indicates support for 965 incremental communication of ICE candidates. 967 Reference: RFC XXXX 969 19. Security Considerations 971 This specification inherits most of its semantics from [rfc5245bis] 972 and as a result all security considerations described there apply to 973 Trickle ICE. 975 If the privacy implications of revealing host addresses on an 976 endpoint device are a concern, agents can generate ICE descriptions 977 that contain no candidates and then only trickle candidates that do 978 not reveal host addresses (e.g., relayed candidates). 980 20. Acknowledgements 982 The authors would like to thank Bernard Aboba, Flemming Andreasen, 983 Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer 984 Holmberg, Ari Keranen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco, 985 Pal Martinsen, Nils Ohlmeier, Thomas Stach, Peter Thatcher, Martin 986 Thomson, Dale R. Worley, and Brandon Williams for their reviews and 987 suggestions on improving this document. Thanks also to Ari Keranen 988 and Peter Thatcher for chairing the ICE Working Group. 990 21. References 992 21.1. Normative References 994 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 995 Requirement Levels", BCP 14, RFC 2119, 996 DOI 10.17487/RFC2119, March 1997, . 999 [rfc5245bis] 1000 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1001 Connectivity Establishment (ICE): A Protocol for Network 1002 Address Translator (NAT) Traversal", draft-ietf-ice- 1003 rfc5245bis-10 (work in progress), May 2017. 1005 21.2. Informative References 1007 [I-D.ietf-mmusic-trickle-ice-sip] 1008 Ivov, E., Thomas, T., Marocco, E., and C. Holmberg, "A 1009 Session Initiation Protocol (SIP) usage for Trickle ICE", 1010 draft-ietf-mmusic-trickle-ice-sip-08 (work in progress), 1011 July 2017. 1013 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1014 and E. Lear, "Address Allocation for Private Internets", 1015 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1016 . 1018 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1019 A., Peterson, J., Sparks, R., Handley, M., and E. 1020 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1021 DOI 10.17487/RFC3261, June 2002, . 1024 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1025 with Session Description Protocol (SDP)", RFC 3264, 1026 DOI 10.17487/RFC3264, June 2002, . 1029 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1030 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1031 July 2006, . 1033 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1034 Translation (NAT) Behavioral Requirements for Unicast 1035 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1036 2007, . 1038 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1039 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1040 DOI 10.17487/RFC5389, October 2008, . 1043 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1044 Relays around NAT (TURN): Relay Extensions to Session 1045 Traversal Utilities for NAT (STUN)", RFC 5766, 1046 DOI 10.17487/RFC5766, April 2010, . 1049 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1050 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1051 March 2011, . 1053 [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for 1054 Interactive Connectivity Establishment (ICE) Options", 1055 RFC 6336, DOI 10.17487/RFC6336, July 2011, 1056 . 1058 [XEP-0030] 1059 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1060 Andre, "XEP-0030: Service Discovery", XEP XEP-0030, June 1061 2008. 1063 [XEP-0176] 1064 Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., 1065 Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP 1066 Transport Method", XEP XEP-0176, June 2009. 1068 Appendix A. Interaction with Regular ICE 1070 The ICE protocol was designed to be flexible enough to work in and 1071 adapt to as many network environments as possible. Despite that 1072 flexibility, ICE as specified in [rfc5245bis] does not by itself 1073 support trickle ICE. This section describes how trickling of 1074 candidates interacts with ICE. 1076 [rfc5245bis] describes the conditions required to update check lists 1077 and timer states while an ICE agent is in the Running state. These 1078 conditions are verified upon transaction completion and one of them 1079 stipulates that: 1081 If there is not a pair in the valid list for each component of the 1082 media stream, the state of the check list is set to Failed. 1084 This could be a problem and cause ICE processing to fail prematurely 1085 in a number of scenarios. Consider the following case: 1087 1. Alice and Bob are both located in different networks with Network 1088 Address Translation (NAT). Alice and Bob themselves have 1089 different address but both networks use the same private internet 1090 block (e.g., the "20-bit block" 172.16/12 specified in 1091 [RFC1918]). 1093 2. Alice conveys to Bob the candidate 172.16.0.1 which also happens 1094 to correspond to an existing host on Bob's network. 1096 3. Bob creates a check list consisting solely of 172.16.0.1 and 1097 starts checks. 1099 4. These checks reach the host at 172.16.0.1 in Bob's network, which 1100 responds with an ICMP "port unreachable" error; per [rfc5245bis] 1101 Bob marks the transaction as Failed. 1103 At this point the check list only contains Failed candidates and the 1104 valid list is empty. This causes the media stream and potentially 1105 all ICE processing to fail, even though if trickle agents could 1106 subsequently convey candidates that would cause previously empty 1107 check lists to become non-empty. 1109 A similar race condition would occur if the initial ICE description 1110 from Alice contain only candidates that can be determined as 1111 unreachable from any of the candidates that Bob has gathered (e.g., 1112 this would be the case if Bob's candidates only contain IPv4 1113 addresses and the first candidate that he receives from Alice is an 1114 IPv6 one). 1116 Another potential problem could arise when a non-trickle ICE 1117 implementation initiates an interaction with a Trickle ICE 1118 implementation. Consider the following case: 1120 1. Alice's client has a non-Trickle ICE implementation. 1122 2. Bob's client has support for Trickle ICE. 1124 3. Alice and Bob are behind NATs with address-dependent filtering 1125 [RFC4787]. 1127 4. Bob has two STUN servers but one of them is currently 1128 unreachable. 1130 After Bob's agent receives Alice's initial ICE description it would 1131 immediately start connectivity checks. It would also start gathering 1132 candidates, which would take a long time because of the unreachable 1133 STUN server. By the time Bob's answer is ready and conveyed to 1134 Alice, Bob's connectivity checks may well have failed: until Alice 1135 gets Bob's answer, she won't be able to start connectivity checks and 1136 punch holes in her NAT. The NAT would hence be filtering Bob's 1137 checks as originating from an unknown endpoint. 1139 Appendix B. Interaction with ICE Lite 1141 The behavior of ICE lite agents that are capable of Trickle ICE does 1142 not require any particular rules other than those already defined in 1143 this specification and [rfc5245bis]. This section is hence provided 1144 only for informational purposes. 1146 An ICE lite agent would generate candidate information as per 1147 [rfc5245bis] and would indicate support for Trickle ICE. Given that 1148 the candidate information will contain a full generation of 1149 candidates, it would also be accompanied by an end-of-candidates 1150 indication. 1152 When performing full trickle, a full ICE implementation could 1153 conveying the initial ICE description or response thereto with no 1154 candidates. After receiving a response that identifies the remote 1155 agent as an ICE lite implementation, the initiator can choose to not 1156 trickle any additional candidates. The same is also true in the case 1157 when the ICE lite agent initiates the interaction and the full ICE 1158 agent is the responder. In these cases the connectivity checks would 1159 be enough for the ICE lite implementation to discover all potentially 1160 useful candidates as peer reflexive. The following example 1161 illustrates one such ICE session using SDP syntax: 1163 ICE Lite Bob 1164 Agent 1165 | Offer (a=ice-lite a=ice-options:trickle) | 1166 |---------------------------------------------->| 1167 | |no cand 1168 | Answer (a=ice-options:trickle) |trickling 1169 |<----------------------------------------------| 1170 | Connectivity Checks | 1171 |<--------------------------------------------->| 1172 peer rflx| | 1173 cand disco| | 1174 | | 1175 |<=============== MEDIA FLOWS =================>| 1177 Figure 8: Example 1179 In addition to reducing signaling traffic this approach also removes 1180 the need to discover STUN bindings or make TURN allocations, which 1181 may considerably lighten ICE processing. 1183 Appendix C. Changes from Earlier Versions 1185 Note to the RFC-Editor: please remove this section prior to 1186 publication as an RFC. 1188 C.1. Changes from draft-ietf-ice-trickle-12 1190 o Specified that the end-of-candidates indication must include the 1191 generation (ufrag/pwd) to enable association with a particular ICE 1192 session. 1194 o Further editorial fixes to address WGLC feedback. 1196 C.2. Changes from draft-ietf-ice-trickle-11 1198 o Editorial and terminological fixes to address WGLC feedback. 1200 C.3. Changes from draft-ietf-ice-trickle-10 1202 o Minor editorial fixes. 1204 C.4. Changes from draft-ietf-ice-trickle-09 1206 o Removed immediate unfreeze upon Fail. 1208 o Specified MUST NOT regarding ice-options. 1210 o Changed terminology regarding initial ICE parameters to avoid 1211 implementer confusion. 1213 C.5. Changes from draft-ietf-ice-trickle-08 1215 o Reinstated text about in-order processing of messages as a 1216 requirement for signaling protocols. 1218 o Added IANA registration template for ICE option. 1220 o Corrected Case 3 rule in Section 8.1.1 to ensure consistency with 1221 regular ICE rules. 1223 o Added tabular representations to Section 8.1.1 in order to 1224 illustrate the new pair rules. 1226 C.6. Changes from draft-ietf-ice-trickle-07 1228 o Changed "ICE description" to "candidate information" for 1229 consistency with 5245bis. 1231 C.7. Changes from draft-ietf-ice-trickle-06 1233 o Addressed editorial feedback from chairs' review. 1235 o Clarified terminology regarding generations. 1237 C.8. Changes from draft-ietf-ice-trickle-05 1239 o Rewrote the text on inserting a new pair into a check list. 1241 C.9. Changes from draft-ietf-ice-trickle-04 1243 o Removed dependency on SDP and offer/answer model. 1245 o Removed mentions of aggressive nomination, since it is deprecated 1246 in 5245bis. 1248 o Added section on requirements for signaling protocols. 1250 o Clarified terminology. 1252 o Addressed various WG feedback. 1254 C.10. Changes from draft-ietf-ice-trickle-03 1256 o Provided more detailed description of unfreezing behavior, 1257 specifically how to replace pre-existing peer-reflexive candidates 1258 with higher-priority ones received via trickling. 1260 C.11. Changes from draft-ietf-ice-trickle-02 1262 o Adjusted unfreezing behavior when there are disparate foundations. 1264 C.12. Changes from draft-ietf-ice-trickle-01 1266 o Changed examples to use IPv6. 1268 C.13. Changes from draft-ietf-ice-trickle-00 1270 o Removed dependency on SDP (which is to be provided in a separate 1271 specification). 1273 o Clarified text about the fact that a check list can be empty if no 1274 candidates have been sent or received yet. 1276 o Clarified wording about check list states so as not to define new 1277 states for "Active" and "Frozen" because those states are not 1278 defined for check lists (only for candidate pairs) in ICE core. 1280 o Removed open issues list because it was out of date. 1282 o Completed a thorough copy edit. 1284 C.14. Changes from draft-mmusic-trickle-ice-02 1286 o Addressed feedback from Rajmohan Banavi and Brandon Williams. 1288 o Clarified text about determining support and about how to proceed 1289 if it can be determined that the answering agent does not support 1290 Trickle ICE. 1292 o Clarified text about check list and timer updates. 1294 o Clarified when it is appropriate to use half trickle or to send no 1295 candidates in an offer or answer. 1297 o Updated the list of open issues. 1299 C.15. Changes from draft-ivov-01 and draft-mmusic-00 1301 o Added a requirement to trickle candidates by order of components 1302 to avoid deadlocks in the unfreezing algorithm. 1304 o Added an informative note on peer-reflexive candidates explaining 1305 that nothing changes for them semantically but they do become a 1306 more likely occurrence for Trickle ICE. 1308 o Limit the number of pairs to 100 to comply with 5245. 1310 o Added clarifications on the non-importance of how newly discovered 1311 candidates are trickled/sent to the remote party or if this is 1312 done at all. 1314 o Added transport expectations for trickled candidates as per Dale 1315 Worley's recommendation. 1317 C.16. Changes from draft-ivov-00 1319 o Specified that end-of-candidates is a media level attribute which 1320 can of course appear as session level, which is equivalent to 1321 having it appear in all m-lines. Also made end-of-candidates 1322 optional for cases such as aggressive nomination for controlled 1323 agents. 1325 o Added an example for ICE lite and Trickle ICE to illustrate how, 1326 when talking to an ICE lite agent doesn't need to send or even 1327 discover any candidates. 1329 o Added an example for ICE lite and Trickle ICE to illustrate how, 1330 when talking to an ICE lite agent doesn't need to send or even 1331 discover any candidates. 1333 o Added wording that explicitly states ICE lite agents have to be 1334 prepared to receive no candidates over signaling and that they 1335 should not freak out if this happens. (Closed the corresponding 1336 open issue). 1338 o It is now mandatory to use MID when trickling candidates and using 1339 m-line indexes is no longer allowed. 1341 o Replaced use of 0.0.0.0 to IP6 :: in order to avoid potential 1342 issues with RFC2543 SDP libraries that interpret 0.0.0.0 as an on- 1343 hold operation. Also changed the port number here from 1 to 9 1344 since it already has a more appropriate meaning. (Port change 1345 suggested by Jonathan Lennox). 1347 o Closed the Open Issue about use about what to do with cands 1348 received after end-of-cands. Solution: ignore, do an ICE restart 1349 if you want to add something. 1351 o Added more terminology, including trickling, trickled candidates, 1352 half trickle, full trickle, 1354 o Added a reference to the SIP usage for Trickle ICE as requested at 1355 the Boston interim. 1357 C.17. Changes from draft-rescorla-01 1359 o Brought back explicit use of Offer/Answer. There are no more 1360 attempts to try to do this in an O/A independent way. Also 1361 removed the use of ICE Descriptions. 1363 o Added SDP specification for trickled candidates, the trickle 1364 option and 0.0.0.0 addresses in m-lines, and end-of-candidates. 1366 o Support and Discovery. Changed that section to be less abstract. 1367 As discussed in IETF85, the draft now says implementations and 1368 usages need to either determine support in advance and directly 1369 use trickle, or do half trickle. Removed suggestion about use of 1370 discovery in SIP or about letting implementing protocols do what 1371 they want. 1373 o Defined Half Trickle. Added a section that says how it works. 1374 Mentioned that it only needs to happen in the first o/a (not 1375 necessary in updates), and added Jonathan's comment about how it 1376 could, in some cases, offer more than half the improvement if you 1377 can pre-gather part or all of your candidates before the user 1378 actually presses the call button. 1380 o Added a short section about subsequent offer/answer exchanges. 1382 o Added a short section about interactions with ICE Lite 1383 implementations. 1385 o Added two new entries to the open issues section. 1387 C.18. Changes from draft-rescorla-00 1389 o Relaxed requirements about verifying support following a 1390 discussion on MMUSIC. 1392 o Introduced ICE descriptions in order to remove ambiguous use of 1393 3264 language and inappropriate references to offers and answers. 1395 o Removed inappropriate assumption of adoption by RTCWEB pointed out 1396 by Martin Thomson. 1398 Authors' Addresses 1400 Emil Ivov 1401 Atlassian 1402 303 Colorado Street, #1600 1403 Austin, TX 78701 1404 USA 1406 Phone: +1-512-640-3000 1407 Email: eivov@atlassian.com 1409 Eric Rescorla 1410 RTFM, Inc. 1411 2064 Edgewood Drive 1412 Palo Alto, CA 94303 1413 USA 1415 Phone: +1 650 678 2350 1416 Email: ekr@rtfm.com 1418 Justin Uberti 1419 Google 1420 747 6th St S 1421 Kirkland, WA 98033 1422 USA 1424 Phone: +1 857 288 8888 1425 Email: justin@uberti.name 1427 Peter Saint-Andre 1428 Jabber.org 1429 P.O. Box 787 1430 Parker, CO 80134 1431 USA 1433 Phone: +1 720 256 6756 1434 Email: peter@jabber.org 1435 URI: https://www.jabber.org/