idnits 2.17.1 draft-ietf-ice-trickle-17.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 (February 25, 2018) is 2244 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-14 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-ip-handling-04 -- 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 (~~), 4 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: August 29, 2018 RTFM, Inc. 6 J. Uberti 7 Google 8 P. Saint-Andre 9 Mozilla 10 February 25, 2018 12 Trickle ICE: Incremental Provisioning of Candidates for the Interactive 13 Connectivity Establishment (ICE) Protocol 14 draft-ietf-ice-trickle-17 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 https://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 August 29, 2018. 43 Copyright Notice 45 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. Initiator Procedures . . . . . . . . . . . . . . . . . . . . 8 69 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 8 70 7.1. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 9 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-16 . . . . . . . . . 27 96 C.2. Changes from draft-ietf-ice-trickle-15 . . . . . . . . . 27 97 C.3. Changes from draft-ietf-ice-trickle-14 . . . . . . . . . 27 98 C.4. Changes from draft-ietf-ice-trickle-13 . . . . . . . . . 27 99 C.5. Changes from draft-ietf-ice-trickle-12 . . . . . . . . . 27 100 C.6. Changes from draft-ietf-ice-trickle-11 . . . . . . . . . 27 101 C.7. Changes from draft-ietf-ice-trickle-10 . . . . . . . . . 27 102 C.8. Changes from draft-ietf-ice-trickle-09 . . . . . . . . . 27 103 C.9. Changes from draft-ietf-ice-trickle-08 . . . . . . . . . 28 104 C.10. Changes from draft-ietf-ice-trickle-07 . . . . . . . . . 28 105 C.11. Changes from draft-ietf-ice-trickle-06 . . . . . . . . . 28 106 C.12. Changes from draft-ietf-ice-trickle-05 . . . . . . . . . 28 107 C.13. Changes from draft-ietf-ice-trickle-04 . . . . . . . . . 28 108 C.14. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 28 109 C.15. Changes from draft-ietf-ice-trickle-02 . . . . . . . . . 29 110 C.16. Changes from draft-ietf-ice-trickle-01 . . . . . . . . . 29 111 C.17. Changes from draft-ietf-ice-trickle-00 . . . . . . . . . 29 112 C.18. Changes from draft-mmusic-trickle-ice-02 . . . . . . . . 29 113 C.19. Changes from draft-ivov-01 and draft-mmusic-00 . . . . . 29 114 C.20. Changes from draft-ivov-00 . . . . . . . . . . . . . . . 30 115 C.21. Changes from draft-rescorla-01 . . . . . . . . . . . . . 31 116 C.22. Changes from draft-rescorla-00 . . . . . . . . . . . . . 31 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 119 1. Introduction 121 The Interactive Connectivity Establishment (ICE) protocol 122 [rfc5245bis] describes mechanisms for gathering candidates, 123 prioritizing them, choosing default ones, exchanging them with a 124 remote party, pairing them, and ordering the candidate pairs into 125 check lists. Once all of these actions have been completed (and only 126 then), the parties can begin a phase of connectivity checks and 127 eventually select the pair of candidates that will be used in a media 128 session or for a given media stream. 130 Although the sequence described above has the advantage of being 131 relatively straightforward to implement and debug once deployed, it 132 can also be rather lengthy. Candidate gathering often involves 133 things like querying STUN [RFC5389] servers and allocating relayed 134 candidates at TURN [RFC5766] servers. All of these actions can be 135 delayed for a noticeable amount of time; although they can be run in 136 parallel, they still need to respect the pacing requirements from 137 [rfc5245bis], which is likely to delay them even further. Some or 138 all of these actions also need be completed by the responder. Both 139 agents would next perform connectivity checks and only then would 140 they be ready to begin streaming media. 142 These factors can lead to relatively lengthy session establishment 143 times and thus to a degraded user experience. 145 This document defines a supplementary mode of operation for ICE 146 implementations, known as "Trickle ICE", in which candidates can be 147 exchanged incrementally. This enables ICE agents to exchange 148 candidates as soon as an ICE session has been initiated and a 149 candidate has become available. Connectivity checks for a media 150 stream can also start as soon as the first candidates for that stream 151 become available. 153 Trickle ICE can reduce session establishment times in cases where 154 connectivity is confirmed for the first exchanged candidates (e.g., 155 where candidates for one of the agents are directly reachable from 156 the second agent, such as candidates at a media relay). Even when 157 this is not the case, performing candidate gathering for both agents 158 and connectivity checks in parallel can considerably shorten ICE 159 processing times. 161 It is worth noting that there is quite a bit of operational 162 experience with the Trickle ICE technique, going back as far as 2005 163 (when the XMPP Jingle extension defined a "dribble mode" as specified 164 in [XEP-0176]); this document incorporates feedback from those who 165 have implemented and deployed the technique. 167 In addition to the basics of Trickle ICE, this document also 168 describes how to discover support for Trickle ICE, how regular ICE 169 processing needs to be modified when forming and updating check 170 lists, and how Trickle ICE implementations interoperate with agents 171 that only implement regular ICE processing as defined in 172 [rfc5245bis]. 174 This specification does not define the usage of Trickle ICE with any 175 specific signaling protocol (however, see 176 [I-D.ietf-mmusic-trickle-ice-sip] for usage with SIP [RFC3261] and 177 [XEP-0176] for usage with XMPP [RFC6120]). Similarly, it does not 178 define Trickle ICE in terms of the Session Description Protocol (SDP) 179 [RFC4566] or the offer/answer model [RFC3264] because the technique 180 can be and already is used in application protocols that are not tied 181 to SDP or to offer/answer semantics. However, because SDP and the 182 offer/answer model are familiar to most readers of this 183 specification, some examples in this document use those particulars 184 in order to explain the underlying concepts. 186 2. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 This specification makes use of all terminology defined for 193 Interactive Connectivity Establishment in [rfc5245bis]. In addition, 194 it defines the following terms: 196 Full Trickle: The typical mode of operation for Trickle ICE agents, 197 in which the initial ICE description can include any number of 198 candidates (even zero candidates) and does not need to include a 199 full generation of candidates as in half trickle. 201 Generation: All of the candidates conveyed within an ICE session; 202 these are the candidates that are associated with a specific 203 local/remote Username Fragment and Password combination (which 204 will change on ICE restart, if any occurs). 206 Half Trickle: A Trickle ICE mode of operation where the initiator 207 gathers a full generation of candidates strictly before creating 208 and conveying the initial ICE description. Once conveyed, this 209 candidate information can be processed by regular ICE agents, 210 which do not require support for this specification. It also 211 allows Trickle ICE capable responders to still gather candidates 212 and perform connectivity checks in a non-blocking way, thus 213 roughly providing "half" the advantages of Trickle ICE. The 214 mechanism is mostly meant for use in cases where the responder's 215 support for Trickle ICE cannot be confirmed prior to conveying the 216 initial ICE description. 218 ICE Description: Any session-related (as opposed to candidate- 219 related) attributes required to configure an ICE agent. These 220 include but are not limited to the username fragment, password, 221 and other attributes. 223 Trickled Candidates: Candidates that a Trickle ICE agent conveys 224 after conveying the initial ICE description or responding to the 225 initial ICE description, but within the same ICE session. 226 Trickled candidates can be conveyed in parallel with candidate 227 gathering and connectivity checks. 229 Trickling: The act of conveying trickled candidates. 231 3. Determining Support for Trickle ICE 233 To fully support Trickle ICE, applications SHOULD incorporate one of 234 the following mechanisms to enable implementations to determine 235 whether Trickle ICE is supported: 237 1. Provide a capabilities discovery method so that agents can verify 238 support of Trickle ICE prior to initiating a session (XMPP's 239 Service Discovery [XEP-0030] is one such mechanism). 241 2. Make support for Trickle ICE mandatory so that user agents can 242 assume support. 244 If an application protocol does not provide a method of determining 245 ahead of time whether Trickle ICE is supported, agents can make use 246 of the half trickle procedure described in Section 14. 248 Prior to conveying the initial ICE description, agents using 249 signaling protocols that support capabilities discovery can attempt 250 to verify whether or not the remote party supports Trickle ICE. If 251 an agent determines that the remote party does not support Trickle 252 ICE, it MUST fall back to using regular ICE or abandon the entire 253 session. 255 Even if a signaling protocol does not include a capabilities 256 discovery method, a user agent can provide an indication within the 257 ICE description that it supports Trickle ICE by communicating an ICE 258 option of 'trickle'. This token MUST be provided either at the 259 session level or, if at the media stream level, for every media 260 stream (an agent MUST NOT specify Trickle ICE support for some media 261 streams but not others). NOTE: The encoding of the 'trickle' ICE 262 option, and the message(s) used to carry it to the peer, are protocol 263 specific. The encoding for the Session Description Protocol (SDP) 264 [RFC4566] is defined in [I-D.ietf-mmusic-trickle-ice-sip]. 266 Dedicated discovery semantics and half trickle are needed only prior 267 to session initiation. After a session is established and Trickle 268 ICE support is confirmed for both parties, either agent can use full 269 trickle for subsequent exchanges. 271 4. Conveying the Initial ICE Description 273 An initiator can start gathering candidates as soon as it has an 274 indication that communication is imminent (e.g., a user interface cue 275 or an explicit request to initiate a session). Unlike in regular 276 ICE, in Trickle ICE implementations do not need to gather candidates 277 in a blocking manner. Therefore, unless half trickle is being used, 278 the user experience is improved if the initiator generates and 279 transmits their initial ICE description as early as possible (thus 280 enabling the remote party to start gathering and trickling 281 candidates). 283 An initiator MAY include any mix of candidates when conveying the 284 initial ICE description. This includes the possibility of conveying 285 all the candidates the initiator plans to use (as in half trickle 286 mode), conveying only a publicly-reachable IP address (e.g., a 287 candidate at a media relay that is known to not be behind a 288 firewall), or conveying no candidates at all (in which case the 289 initiator can obtain the responder's initial candidate list sooner 290 and the responder can begin candidate gathering more quickly). 292 Methods for calculating priorities and foundations, as well as 293 determining redundancy of candidates, work just as with regular ICE 294 (with the exception of pruning of duplicate peer reflexive candidates 295 as described under Section 5.2). 297 5. Responder Procedures 299 When a responder receives the initial ICE description, it will first 300 check if the ICE description or initiator indicates support for 301 Trickle ICE as explained in Section 3. If this is not the case, the 302 responder MUST process the initial ICE description according to 303 regular ICE procedures [rfc5245bis] (or, if no ICE support is 304 detected at all, according to relevant processing rules for the 305 underlying signaling protocol, such as offer/answer processing rules 306 [RFC3264]). 308 If support for Trickle ICE is confirmed, a responder will 309 automatically assume support for regular ICE as well. Specifically, 310 the rules from [rfc5245bis] would imply that ICE itself is not 311 supported if the initial ICE description includes no candidates; 312 however, such a conclusion is not warranted if the responder can 313 confirm that the initiator supports Trickle ICE; in this case, 314 fallback to non-ICE processing rules is not necessary. 316 If the initial ICE description indicates support for Trickle ICE, the 317 responder will determine its role and start gathering and 318 prioritizing candidates; while doing so, it will also respond by 319 conveying its own ICE description, so that both the initiator and the 320 responder can start forming check lists and begin connectivity 321 checks. 323 5.1. Conveying the Initial Response 325 A responder can respond to the initial ICE description at any point 326 while gathering candidates. Here again the ICE description MAY 327 contain any set of candidates, including all candidates or no 328 candidates. (The benefit of including no candidates is to convey the 329 ICE description as quickly as possible, so that both parties can 330 consider the overall session to be under active negotiation as soon 331 as possible.) 333 As noted in Section 3, in application protocols that use SDP the 334 responder's ICE description can indicate support for Trickle ICE by 335 including a token of "trickle" in the ice-options attribute. 337 5.2. Forming Check Lists and Beginning Connectivity Checks 339 As soon as the agents have obtained local and remote candidates, both 340 agents begin forming candidate pairs, computing candidate pair 341 priorities, ordering candidate pairs, pruning duplicate pairs, and 342 creating check lists according to regular ICE procedures 343 [rfc5245bis]. 345 According to those procedures, in order for candidate pairing to be 346 possible and for duplicate candidates to be pruned, the candidates 347 would need to be provided in the relevant ICE descriptions. By 348 contrast, under Trickle ICE check lists can be empty until candidates 349 are conveyed or received. Therefore Trickle ICE agents handle check 350 lists and candidate pairing in a slightly different way than regular 351 ICE agents: the agents still form the check lists, but they populate 352 the check lists only after they actually have the candidate pairs. 353 Every check list is initially placed in the Running state, even if 354 there are not yet any candidate pairs in the check list. 356 A Trickle ICE agent initially considers all candidate pairs in all 357 check lists to be frozen. It then inspects the first check list and 358 attempts to unfreeze all candidate pairs it has received so far that 359 belong to the first component on the first media stream (i.e., the 360 first media stream that was reported to the ICE implementation from 361 the using application). If that first component of the first media 362 stream does not contain candidates for one or more of the currently 363 known pair foundations, and if candidate pairs already exist for that 364 foundation in one of the following components or media streams, then 365 the agent unfreezes the first of those candidate pairs. 367 With regard to pruning of duplicate candidate pairs, a Trickle ICE 368 agent SHOULD follow a policy of keeping the higher priority candidate 369 unless it is peer reflexive. 371 6. Initiator Procedures 373 When processing the initial ICE description from a responder, the 374 initiator follows regular ICE procedures to determine its role, after 375 which it forms check lists (as described in Section 5.2) and begins 376 connectivity checks. 378 7. Performing Connectivity Checks 380 For the most part, Trickle ICE agents perform connectivity checks 381 following regular ICE procedures. However, the fact that gathering 382 and communicating candidates is asynchronous in Trickle ICE imposes a 383 number of changes as described in the following sections. 385 7.1. Scheduling Checks 387 The ICE specification [rfc5245bis], Section 6.1.4.2, specifies that 388 an agent will terminate the timer for a triggered check in relation 389 to a check list once the agent has exhausted all frozen pairs in the 390 check list. This will not work with Trickle ICE, because more pairs 391 will be added to the check list incrementally. 393 Therefore, a Trickle ICE agent SHOULD NOT terminate the timer until 394 the state of the check list is Completed or Failed as specified 395 herein (see Section 8.2). 397 7.2. Check List and Timer State Updates 399 The ICE specification [rfc5245bis], Section 7.2.5.3.3, requires that 400 agents update check lists and timer states upon completing a 401 connectivity check transaction. During such an update, regular ICE 402 agents would set the state of a check list to Failed if both of the 403 following two conditions are satisfied: 405 o all of the pairs in the check list are either in the Failed state 406 or Succeeded state; and 408 o there is not a pair in the valid list for each component of the 409 media stream. 411 With Trickle ICE, the above situation would often occur when 412 candidate gathering and trickling are still in progress, even though 413 it is quite possible that future checks will succeed. For this 414 reason, Trickle ICE agents add the following conditions to the above 415 list: 417 o all candidate gathering has completed and the agent is not 418 expecting to discover any new local candidates; 420 o the remote agent has conveyed an end-of-candidates indication for 421 that check list as described in Section 8.2. 423 When a check list is set to Failed as described above, regular ICE 424 requires the agent to update all other check lists, placing one pair 425 from each check list into the Waiting state and thereby effectively 426 placing all remaining check lists into the Running state. However, 427 under Trickle ICE other check lists might still be empty at this 428 point (because candidates have not yet been received), and following 429 only the rules from regular ICE would prevent the agent from forming 430 those check lists (because the state of a check list depends on the 431 state of the candidate pairs in that check list, but there might not 432 yet by any candidate pairs in a given check list). In accordance 433 with the ICE specification [rfc5245bis], Section 6.1.2.1, a Trickle 434 ICE agent considers an empty check list to be in the Running state; 435 in accordance with Section 8.1.1, when inserting a new candidate pair 436 into an empty check list, the agent sets the pair to a state of 437 Waiting. 439 8. Discovering and Conveying Additional Local Candidates 441 After candidate information has been conveyed, agents will most 442 likely continue discovering new local candidates as STUN, TURN, and 443 other non-host candidate gathering mechanisms begin to yield results. 444 Whenever an agent discovers such a new candidate it will compute its 445 priority, type, foundation and component ID according to regular ICE 446 procedures. 448 The new candidate is then checked for redundancy against the existing 449 list of local candidates. If its transport address and base match 450 those of an existing candidate, it will be considered redundant and 451 will be ignored. This would often happen for server reflexive 452 candidates that match the host addresses they were obtained from 453 (e.g., when the latter are public IPv4 addresses). Contrary to 454 regular ICE, Trickle ICE agents will consider the new candidate 455 redundant regardless of its priority. 457 Next the agent "trickles" the newly discovered candidate(s) to the 458 remote agent. The actual delivery of the new candidates is handled 459 by a signaling protocol such as SIP or XMPP. Trickle ICE imposes no 460 restrictions on the way this is done (e.g., some applications may 461 choose not to trickle updates for server reflexive candidates and 462 instead rely on the discovery of peer reflexive ones). 464 When candidates are trickled, the signaling protocol MUST deliver 465 each candidate (and any end-of-candidates indication as described in 466 Section 8.2) to the receiving Trickle ICE implementation not more 467 than once and in the same order it was conveyed. If the signaling 468 protocol provides any candidate retransmissions, they need to be 469 hidden from the ICE implementation. 471 Also, candidate trickling needs to be correlated to a specific ICE 472 session, so that if there is an ICE restart, any delayed updates for 473 a previous session can be recognized as such and ignored by the 474 receiving party. For example, applications that choose to signal 475 candidates via SDP may include a Username Fragment value in the 476 corresponding a=candidate line, such as: 478 a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY 480 Or as another example, WebRTC implementations may include a Username 481 Fragment in the JavaScript objects that represent candidates. 483 Note: The signaling protocol needs to provide a mechanism for both 484 parties to indicate and agree on the ICE session in force (as 485 identified by the Username Fragment and Password combination) so that 486 they have a consistent view of which candidates are to be paired. 487 This is especially important in the case of ICE restarts (see 488 Section 13). 490 Once the candidate has been conveyed to the remote party, the agent 491 checks if any remote candidates are currently known for this same 492 stream and component. If not, the new candidate will simply be added 493 to the list of local candidates. 495 Otherwise, if the agent has already learned of one or more remote 496 candidates for this stream and component, it will begin pairing the 497 new local candidates with them and adding the pairs to the existing 498 check lists according to their priority. 500 Note: A Trickle ICE agent MUST NOT pair a local candidate until it 501 has been trickled to the remote agent. 503 8.1. Pairing Newly Learned Candidates and Updating Check Lists 505 Forming candidate pairs works as described in the ICE specification 506 [rfc5245bis]. However, actually adding the new pair to a check list 507 happens according to the rules described below. 509 If the check list where the pair is to be added already contains the 510 maximum number of candidate pairs (100 by default as per 511 [rfc5245bis]), the new pair is discarded. 513 If the new pair's local candidate is server reflexive, the server 514 reflexive candidate MUST be replaced by its base before adding the 515 pair to the list. 517 Once this is done, the agent examines the check list looking for 518 another pair that would be redundant with the new one. If such a 519 pair exists and the type of its remote candidate is not peer 520 reflexive, the pair with the higher priority is kept and the one with 521 the lower priority is discarded. If, on the other hand, the type of 522 the remote candidate in the pre-existing pair is peer reflexive, the 523 agent MUST replace it with the newly formed pair (regardless of their 524 respective priorities); this is done by setting the priority of the 525 new candidate to the priority of the pre-existing candidate and then 526 re-sorting the check list. 528 For all other pairs, including those with a server reflexive local 529 candidate that were not found to be redundant, the rules specified in 530 the following section apply. 532 8.1.1. Inserting a New Pair in a Check List 534 Consider the following tabular representation of all check lists in 535 an agent (note that initially for one of the foundations, i.e., f5, 536 there are no candidate pairs): 538 +-----------------+------+------+------+------+------+ 539 | | f1 | f2 | f3 | f4 | f5 | 540 +-----------------+------+------+------+------+------+ 541 | m1 (Audio.RTP) | F | F | F | | | 542 +-----------------+------+------+------+------+------+ 543 | m2 (Audio.RTCP) | F | F | F | F | | 544 +-----------------+------+------+------+------+------+ 545 | m3 (Video.RTP) | F | | | | | 546 +-----------------+------+------+------+------+------+ 547 | m4 (Video.RTCP) | F | | | | | 548 +-----------------+------+------+------+------+------+ 550 Figure 1: Example of Check List State 552 Each row in the table represents a component for a given media stream 553 (e.g., m1 and m2 might be the RTP and RTCP components for audio). 554 Each column represents one foundation. Each cell represents one 555 candidate pair. In the foregoing table, "F" stands for "frozen"; in 556 the tables below, "W" stands for "waiting" and "S" stands for 557 "succeeded". 559 When an agent commences ICE processing, in accordance with 560 Section 6.1.2.6 of [rfc5245bis] it will unfreeze (i.e., place in the 561 Waiting state) the topmost candidate pair in every column (i.e., the 562 pair with the lowest component ID). This state is shown in the 563 following table, with candidate pairs in the Waiting state marked by 564 "W". 566 +-----------------+------+------+------+------+------+ 567 | | f1 | f2 | f3 | f4 | f5 | 568 +-----------------+------+------+------+------+------+ 569 | m1 (Audio.RTP) | W | W | W | | | 570 +-----------------+------+------+------+------+------+ 571 | m2 (Audio.RTCP) | F | F | F | W | | 572 +-----------------+------+------+------+------+------+ 573 | m3 (Video.RTP) | F | | | | | 574 +-----------------+------+------+------+------+------+ 575 | m4 (Video.RTCP) | F | | | | | 576 +-----------------+------+------+------+------+------+ 578 Figure 2: Initial Check List State 580 Then, as the checks proceed (see Section 7.2.5.4 of [rfc5245bis]), 581 for each pair that enters the Succeeded state (denoted here by "S"), 582 the agent will unfreeze all pairs for all media streams with the same 583 foundation (e.g., if the pair in column 1, row 1 succeeds then the 584 agent will unfreeze the pair in column 1, rows 2, 3, and 4). 586 +-----------------+------+------+------+------+------+ 587 | | f1 | f2 | f3 | f4 | f5 | 588 +-----------------+------+------+------+------+------+ 589 | m1 (Audio.RTP) | S | W | W | | | 590 +-----------------+------+------+------+------+------+ 591 | m2 (Audio.RTCP) | W | F | F | W | | 592 +-----------------+------+------+------+------+------+ 593 | m3 (Video.RTP) | W | | | | W | 594 +-----------------+------+------+------+------+------+ 595 | m4 (Video.RTCP) | W | | | | F | 596 +-----------------+------+------+------+------+------+ 598 Figure 3: Check List State with Unfrozen Media Stream 600 Trickle ICE preserves all of these rules as they apply to what we 601 might call "static" check list sets. This implies that if, for some 602 reason, a Trickle agent were to begin connectivity checks with all of 603 its pairs already present, the way that pair states change is 604 indistinguishable from that of a regular ICE agent. 606 Of course, the major difference with Trickle ICE is that check list 607 sets can be dynamically updated because candidates can arrive after 608 connectivity checks have started. When this happens, an agent sets 609 the state of the newly formed pair as described below. 611 Case 1: If the newly formed pair is the topmost pair in its column 612 (i.e. the topmost pair among all the check lists for this 613 foundation), set the state to Waiting (e.g., this would be the case 614 if the newly formed pair were placed in column 5, row 1). 616 +-----------------+------+------+------+------+------+ 617 | | f1 | f2 | f3 | f4 | f5 | 618 +-----------------+------+------+------+------+------+ 619 | m1 (Audio.RTP) | S | W | W | | W | 620 +-----------------+------+------+------+------+------+ 621 | m2 (Audio.RTCP) | W | F | F | W | | 622 +-----------------+------+------+------+------+------+ 623 | m3 (Video.RTP) | W | | | | | 624 +-----------------+------+------+------+------+------+ 625 | m4 (Video.RTCP) | W | | | | | 626 +-----------------+------+------+------+------+------+ 628 Figure 4: Check List State with Newly Formed Pair, Case 1 630 Case 2: If the pair immediately above the newly formed pair in its 631 column is in the Succeeded state, set the state to Waiting (e.g., 632 this would be the case if the pair in column 5, row 1 succeeded and 633 the newly formed pair were placed in column 5, row 2); 635 +-----------------+------+------+------+------+------+ 636 | | f1 | f2 | f3 | f4 | f5 | 637 +-----------------+------+------+------+------+------+ 638 | m1 (Audio.RTP) | S | W | W | | S | 639 +-----------------+------+------+------+------+------+ 640 | m2 (Audio.RTCP) | W | F | F | W | W | 641 +-----------------+------+------+------+------+------+ 642 | m3 (Video.RTP) | W | | | | | 643 +-----------------+------+------+------+------+------+ 644 | m4 (Video.RTCP) | W | | | | | 645 +-----------------+------+------+------+------+------+ 647 Figure 5: Check List State with Newly Formed Pair, Case 2 649 Case 3: If there is at least one Succeeded pair in its column above 650 the row of the newly formed pair, set the state to Waiting (e.g., 651 this would be the case if the pair in column 5, row 1 succeeded and 652 two newly formed pairs were placed in column 5, rows 3 and 4). 654 +-----------------+------+------+------+------+------+ 655 | | f1 | f2 | f3 | f4 | f5 | 656 +-----------------+------+------+------+------+------+ 657 | m1 (Audio.RTP) | S | W | W | | S | 658 +-----------------+------+------+------+------+------+ 659 | m2 (Audio.RTCP) | W | F | F | W | W | 660 +-----------------+------+------+------+------+------+ 661 | m3 (Video.RTP) | W | | | | W | 662 +-----------------+------+------+------+------+------+ 663 | m4 (Video.RTCP) | W | | | | W | 664 +-----------------+------+------+------+------+------+ 666 Figure 6: Check List State with Newly Formed Pair, Case 3 668 Case 4: In all other cases, set the state to Frozen. 670 8.2. Announcing End of Candidates 672 Once all candidate gathering is completed or expires for an ICE 673 session associated with a specific media stream, the agent will 674 generate an "end-of-candidates" indication for that session and 675 convey it to the remote agent via the signaling channel. Although 676 the exact form of the indication depends on the application protocol, 677 the indication MUST specify the generation (Username Fragment and 678 Password combination) so that an agent can correlate the end-of- 679 candidates indication with a particular ICE session. The indication 680 can be conveyed in the following ways: 682 o As part of an initiation request (which would typically be the 683 case with the initial ICE description for half trickle) 685 o Along with the last candidate an agent can send for a stream 687 o As a standalone notification (e.g., after STUN Binding requests or 688 TURN Allocate requests to a server time out and the agent has is 689 not actively gathering candidates) 691 Conveying an end-of-candidates indication in a timely manner is 692 important in order to avoid ambiguities and speed up the conclusion 693 of ICE processing. In particular: 695 o A controlled Trickle ICE agent SHOULD convey an end-of-candidates 696 indication after it has completed gathering for a media stream, 697 unless ICE processing terminates before the agent has had a chance 698 to complete gathering. 700 o A controlling agent MAY conclude ICE processing prior to conveying 701 end-of-candidates indications for all streams. However, it is 702 RECOMMENDED for a controlling agent to convey end-of-candidates 703 indications whenever possible for the sake of consistency and to 704 keep middleboxes and controlled agents up-to-date on the state of 705 ICE processing. 707 When conveying an end-of-candidates indication during trickling 708 (rather than as a part of the initial ICE description or a response 709 thereto), it is the responsibility of the using protocol to define 710 methods for relating the indication to one or more specific media 711 streams. 713 Receiving an end-of-candidates indication enables an agent to update 714 check list states and, in case valid pairs do not exist for every 715 component in every media stream, determine that ICE processing has 716 failed. It also enables an agent to speed up the conclusion of ICE 717 processing when a candidate pair has been validated but it involves 718 the use of lower-preference transports such as TURN. In such 719 situations, an implementation MAY choose to wait and see if higher- 720 priority candidates are received; in this case the end-of-candidates 721 indication provides a notification that such candidates are not 722 forthcoming. 724 An agent MAY also choose to generate an end-of-candidates indication 725 before candidate gathering has actually completed, if the agent 726 determines that gathering has continued for more than an acceptable 727 period of time. However, an agent MUST NOT convey any more 728 candidates after it has conveyed an end-of-candidates indication. 730 When performing half trickle, an agent SHOULD convey an end-of- 731 candidates indication together with its initial ICE description 732 unless it is planning to potentially trickle additional candidates 733 (e.g., in case the remote party turns out to support Trickle ICE). 735 After an agent conveys the end-of-candidates indication, it will 736 update the state of the corresponding check list as explained in 737 Section 7.2. Past that point, an agent MUST NOT trickle any new 738 candidates within this ICE session. After an agent has received an 739 end-of-candidates indication, it MUST also ignore any newly received 740 candidates for that media stream or media session. Therefore, adding 741 new candidates to the negotiation is possible only through an ICE 742 restart (see Section 13). 744 This specification does not override regular ICE semantics for 745 concluding ICE processing. Therefore, even if end-of-candidates 746 indications are conveyed, an agent will still need to go through pair 747 nomination. Also, if pairs have been nominated for components and 748 media streams, ICE processing MAY still conclude even if end-of- 749 candidates indications have not been received for all streams. 751 9. Receiving Additional Remote Candidates 753 At any time during ICE processing, a Trickle ICE agent might receive 754 new candidates from the remote agent. When this happens and no local 755 candidates are currently known for this same stream, the new remote 756 candidates are added to the list of remote candidates. 758 Otherwise, the new candidates are used for forming candidate pairs 759 with the pool of local candidates and they are added to the local 760 check lists as described in Section 8.1. 762 Once the remote agent has completed candidate gathering, it will 763 convey an end-of-candidates indication. Upon receiving such an 764 indication, the local agent MUST update check list states as per 765 Section 7.2. This might lead to some check lists being marked as 766 Failed. 768 10. Receiving an End-Of-Candidates Indication 770 When an agent receives an end-of-candidates indication for a specific 771 media stream, it will update the state of the relevant check list as 772 per Section 7.2. If the check list is still in the Active state 773 after the update, the agent will persist the fact that an end-of- 774 candidates indication has been received and take it into account in 775 future updates to the check list. 777 11. Trickle ICE and Peer Reflexive Candidates 779 Even though Trickle ICE does not explicitly modify the procedures for 780 handling peer-reflexive candidates, use of Trickle ICE can have an 781 impact on how they are processed. With Trickle ICE, it is possible 782 that server reflexive candidates can be discovered as peer reflexive 783 in cases where incoming connectivity checks are received from these 784 candidates before the trickle updates that carry them. 786 While this would certainly increase the number of cases where ICE 787 processing nominates and selects candidates discovered as peer- 788 reflexive, it does not require any change in processing. 790 It is also likely that some applications would prefer not to trickle 791 server reflexive candidates to entities that are known to be publicly 792 accessible and where sending a direct STUN binding request is likely 793 to reach the destination faster than the trickle update that travels 794 through the signaling path. 796 12. Concluding ICE Processing 798 This specification does not directly modify the procedures for ending 799 ICE processing described in Section 8 of [rfc5245bis], and Trickle 800 ICE implementations follow the same rules. 802 13. Subsequent Exchanges 804 Before conveying an end-of-candidates indication, either agent MAY 805 convey subsequent candidate information at any time allowed by the 806 signaling protocol in use. When this happens, agents will use 807 [rfc5245bis] semantics to determine whether or not the new candidate 808 information require an ICE restart. If an ICE restart occurs, the 809 agents can assume that Trickle ICE is still supported if support was 810 determined previously, and thus can engage in Trickle ICE behavior as 811 they would in an initial exchange of ICE descriptions where support 812 was determined through a capabilities discovery method. 814 14. Unilateral Use of Trickle ICE (Half Trickle) 816 In half trickle mode, the initiator conveys the initial ICE 817 description with a full generation of candidates. This ensures that 818 the ICE description can be processed by a regular ICE responder and 819 is mostly meant for use in cases where support for Trickle ICE cannot 820 be confirmed prior to conveying the initial ICE description. The 821 initial ICE description indicate support for Trickle ICE, which means 822 the responder can respond with something less than a full generation 823 of candidates and then trickle the rest. The initial ICE description 824 for half trickle would typically contain an end-of-candidates 825 indication, although this is not mandatory because if trickle support 826 is confirmed then the initiator can choose to trickle additional 827 candidates before it conveys an end-of-candidates indication. 829 The half trickle mechanism can be used in cases where there is no way 830 for an agent to verify in advance whether a remote party supports 831 Trickle ICE. Because the initial ICE description contain a full 832 generation of candidates, it can thus be handled by a regular ICE 833 agent, while still allowing a Trickle ICE agent to use the 834 optimization defined in this specification. This prevents 835 negotiation from failing in the former case while still giving 836 roughly half the Trickle ICE benefits in the latter (hence the name 837 of the mechanism). 839 Use of half trickle is only necessary during an initial exchange of 840 ICE descriptions. After both parties have received an ICE 841 description from their peer, they can each reliably determine Trickle 842 ICE support and use it for all subsequent exchanges. 844 In some instances, using half trickle might bring more than just half 845 the improvement in terms of user experience. This can happen when an 846 agent starts gathering candidates upon user interface cues that the 847 user will soon be initiating an interaction, such as activity on a 848 keypad or the phone going off hook. This would mean that some or all 849 of the candidate gathering could be completed before the agent 850 actually needs to convey the candidate information. Because the 851 responder will be able to trickle candidates, both agents will be 852 able to start connectivity checks and complete ICE processing earlier 853 than with regular ICE and potentially even as early as with full 854 trickle. 856 However, such anticipation is not always possible. For example, a 857 multipurpose user agent or a WebRTC web page where communication is a 858 non-central feature (e.g., calling a support line in case of a 859 problem with the main features) would not necessarily have a way of 860 distinguishing between call intentions and other user activity. In 861 such cases, using full trickle is most likely to result in an ideal 862 user experience. Even so, using half trickle would be an improvement 863 over regular ICE because it would result in a better experience for 864 responders. 866 15. Requirements for Signaling Protocols 868 In order to fully enable the use of Trickle ICE, this specification 869 defines the following requirements for signaling protocols. 871 o A signaling protocol SHOULD provide a way for parties to advertise 872 and discover support for Trickle ICE before an ICE session begins 873 (see Section 3). 875 o A signaling protocol MUST provide methods for incrementally 876 conveying (i.e., "trickling") additional candidates after 877 conveying the initial ICE description (see Section 8). 879 o A signaling protocol MUST deliver each trickled candidate or end- 880 of-candidates indication not more than once and in the same order 881 it was conveyed (see Section 8). 883 o A signaling protocol MUST provide a mechanism for both parties to 884 indicate and agree on the ICE session in force (see Section 8). 886 o A signaling protocol MUST provide a way for parties to communicate 887 the end-of-candidates indication, which MUST specify the 888 particular ICE session to which the indication applies (see 889 Section 8.2). 891 16. Preserving Candidate Order while Trickling 893 One important aspect of regular ICE is that connectivity checks for a 894 specific foundation and component are attempted simultaneously by 895 both agents, so that any firewalls or NATs fronting the agents would 896 whitelist both endpoints and allow all except for the first 897 ("suicide") packets to go through. This is also important to 898 unfreezing candidates at the right time. While not crucial, 899 preserving this behavior in Trickle ICE is likely to improve ICE 900 performance. 902 To achieve this, when trickling candidates, agents MUST respect the 903 order in which the components and streams appear (implicitly or 904 explicitly) as they have been negotiated by means of the relevant 905 candidate information. Therefore candidates for a given component 906 MUST NOT be conveyed prior to candidates for a component with a lower 907 ID number within the same foundation. In addition, candidates MUST 908 be paired, following the procedures in Section 8.1.1, in the same 909 order they are conveyed. 911 For example, the following SDP description contains two components 912 (RTP and RTCP) and two foundations (host and server reflexive): 914 v=0 915 o=jdoe 2890844526 2890842807 IN IP6 2001:db8:a0b:12f0::1 916 s= 917 c=IN IP6 2001:db8:a0b:12f0::1 918 t=0 0 919 a=ice-pwd:asd88fgpdd777uzjYhagZg 920 a=ice-ufrag:8hhY 921 m=audio 5000 RTP/AVP 0 922 a=rtpmap:0 PCMU/8000 923 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host 924 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host 925 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 926 raddr 2001:db8:a0b:12f0::1 rport 8998 927 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx 928 raddr 2001:db8:a0b:12f0::1 rport 8998 930 For this candidate information the RTCP host candidate would not be 931 conveyed prior to the RTP host candidate. Similarly the RTP server 932 reflexive candidate would be conveyed together with or prior to the 933 RTCP server reflexive candidate. 935 Similar considerations apply at the level of media streams in 936 addition to foundations; this is covered by the requirement to always 937 start unfreezing candidates starting from the first media stream as 938 described under Section 5.2. 940 17. Example Flow 942 As an example, a typical successful Trickle ICE exchange with a 943 signaling protocol that follows the offer/answer model would look 944 this way: 946 Alice Bob 947 | Offer | 948 |---------------------------------------------->| 949 | Additional Candidates | 950 |---------------------------------------------->| 951 | | 952 | Answer | 953 |<----------------------------------------------| 954 | Additional Candidates | 955 |<----------------------------------------------| 956 | | 957 | Additional Candidates and Connectivity Checks | 958 |<--------------------------------------------->| 959 | | 960 |<=============== MEDIA FLOWS =================>| 962 Figure 7: Example 964 18. IANA Considerations 966 IANA is requested to register the following ICE option in the "ICE 967 Options" sub-registry of the "Interactive Connectivity Establishment 968 (ICE) registry", following the procedures defined in [RFC6336]. 970 ICE Option: trickle 972 Contact: IESG, iesg@ietf.org 974 Change control: IESG 976 Description: An ICE option of "trickle" indicates support for 977 incremental communication of ICE candidates. 979 Reference: RFC XXXX 981 19. Security Considerations 983 This specification inherits most of its semantics from [rfc5245bis] 984 and as a result all security considerations described there apply to 985 Trickle ICE. 987 If the privacy implications of revealing host addresses on an 988 endpoint device are a concern (see for example the discussion in 989 [I-D.ietf-rtcweb-ip-handling] and in Section 19 of [rfc5245bis]), 990 agents can generate ICE descriptions that contain no candidates and 991 then only trickle candidates that do not reveal host addresses (e.g., 992 relayed candidates). 994 20. Acknowledgements 996 The authors would like to thank Bernard Aboba, Flemming Andreasen, 997 Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer 998 Holmberg, Ari Keranen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco, 999 Pal Martinsen, Nils Ohlmeier, Thomas Stach, Peter Thatcher, Martin 1000 Thomson, Dale R. Worley, and Brandon Williams for their reviews and 1001 suggestions on improving this document. Thanks also to Ari Keranen 1002 and Peter Thatcher in their role as chairs, and Ben Campbell in his 1003 role as responsible Area Director. 1005 21. References 1007 21.1. Normative References 1009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1010 Requirement Levels", BCP 14, RFC 2119, 1011 DOI 10.17487/RFC2119, March 1997, 1012 . 1014 [rfc5245bis] 1015 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1016 Connectivity Establishment (ICE): A Protocol for Network 1017 Address Translator (NAT) Traversal", draft-ietf-ice- 1018 rfc5245bis-17 (work in progress), February 2018. 1020 21.2. Informative References 1022 [I-D.ietf-mmusic-trickle-ice-sip] 1023 Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 1024 Session Initiation Protocol (SIP) usage for Trickle ICE", 1025 draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), 1026 February 2018. 1028 [I-D.ietf-rtcweb-ip-handling] 1029 Uberti, J. and G. Shieh, "WebRTC IP Address Handling 1030 Requirements", draft-ietf-rtcweb-ip-handling-04 (work in 1031 progress), July 2017. 1033 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1034 and E. Lear, "Address Allocation for Private Internets", 1035 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1036 . 1038 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1039 A., Peterson, J., Sparks, R., Handley, M., and E. 1040 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1041 DOI 10.17487/RFC3261, June 2002, 1042 . 1044 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1045 with Session Description Protocol (SDP)", RFC 3264, 1046 DOI 10.17487/RFC3264, June 2002, 1047 . 1049 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1050 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1051 July 2006, . 1053 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1054 Translation (NAT) Behavioral Requirements for Unicast 1055 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1056 2007, . 1058 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1059 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1060 DOI 10.17487/RFC5389, October 2008, 1061 . 1063 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1064 Relays around NAT (TURN): Relay Extensions to Session 1065 Traversal Utilities for NAT (STUN)", RFC 5766, 1066 DOI 10.17487/RFC5766, April 2010, 1067 . 1069 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1070 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1071 March 2011, . 1073 [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for 1074 Interactive Connectivity Establishment (ICE) Options", 1075 RFC 6336, DOI 10.17487/RFC6336, July 2011, 1076 . 1078 [XEP-0030] 1079 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1080 Andre, "XEP-0030: Service Discovery", XEP XEP-0030, June 1081 2008. 1083 [XEP-0176] 1084 Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., 1085 Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP 1086 Transport Method", XEP XEP-0176, June 2009. 1088 Appendix A. Interaction with Regular ICE 1090 The ICE protocol was designed to be flexible enough to work in and 1091 adapt to as many network environments as possible. Despite that 1092 flexibility, ICE as specified in [rfc5245bis] does not by itself 1093 support trickle ICE. This section describes how trickling of 1094 candidates interacts with ICE. 1096 [rfc5245bis] describes the conditions required to update check lists 1097 and timer states while an ICE agent is in the Running state. These 1098 conditions are verified upon transaction completion and one of them 1099 stipulates that: 1101 If there is not a pair in the valid list for each component of the 1102 media stream, the state of the check list is set to Failed. 1104 This could be a problem and cause ICE processing to fail prematurely 1105 in a number of scenarios. Consider the following case: 1107 1. Alice and Bob are both located in different networks with Network 1108 Address Translation (NAT). Alice and Bob themselves have 1109 different address but both networks use the same private internet 1110 block (e.g., the "20-bit block" 172.16/12 specified in 1111 [RFC1918]). 1113 2. Alice conveys to Bob the candidate 172.16.0.1 which also happens 1114 to correspond to an existing host on Bob's network. 1116 3. Bob creates a check list consisting solely of 172.16.0.1 and 1117 starts checks. 1119 4. These checks reach the host at 172.16.0.1 in Bob's network, which 1120 responds with an ICMP "port unreachable" error; per [rfc5245bis] 1121 Bob marks the transaction as Failed. 1123 At this point the check list only contains Failed candidates and the 1124 valid list is empty. This causes the media stream and potentially 1125 all ICE processing to fail, even though if trickle agents could 1126 subsequently convey candidates that would cause previously empty 1127 check lists to become non-empty. 1129 A similar race condition would occur if the initial ICE description 1130 from Alice contain only candidates that can be determined as 1131 unreachable from any of the candidates that Bob has gathered (e.g., 1132 this would be the case if Bob's candidates only contain IPv4 1133 addresses and the first candidate that he receives from Alice is an 1134 IPv6 one). 1136 Another potential problem could arise when a non-trickle ICE 1137 implementation initiates an interaction with a Trickle ICE 1138 implementation. Consider the following case: 1140 1. Alice's client has a non-Trickle ICE implementation. 1142 2. Bob's client has support for Trickle ICE. 1144 3. Alice and Bob are behind NATs with address-dependent filtering 1145 [RFC4787]. 1147 4. Bob has two STUN servers but one of them is currently 1148 unreachable. 1150 After Bob's agent receives Alice's initial ICE description it would 1151 immediately start connectivity checks. It would also start gathering 1152 candidates, which would take a long time because of the unreachable 1153 STUN server. By the time Bob's answer is ready and conveyed to 1154 Alice, Bob's connectivity checks may well have failed: until Alice 1155 gets Bob's answer, she won't be able to start connectivity checks and 1156 punch holes in her NAT. The NAT would hence be filtering Bob's 1157 checks as originating from an unknown endpoint. 1159 Appendix B. Interaction with ICE Lite 1161 The behavior of ICE lite agents that are capable of Trickle ICE does 1162 not require any particular rules other than those already defined in 1163 this specification and [rfc5245bis]. This section is hence provided 1164 only for informational purposes. 1166 An ICE lite agent would generate candidate information as per 1167 [rfc5245bis] and would indicate support for Trickle ICE. Given that 1168 the candidate information will contain a full generation of 1169 candidates, it would also be accompanied by an end-of-candidates 1170 indication. 1172 When performing full trickle, a full ICE implementation could convey 1173 the initial ICE description or response thereto with no candidates. 1174 After receiving a response that identifies the remote agent as an ICE 1175 lite implementation, the initiator can choose to not trickle any 1176 additional candidates. The same is also true in the case when the 1177 ICE lite agent initiates the interaction and the full ICE agent is 1178 the responder. In these cases the connectivity checks would be 1179 enough for the ICE lite implementation to discover all potentially 1180 useful candidates as peer reflexive. The following example 1181 illustrates one such ICE session using SDP syntax: 1183 ICE Lite Bob 1184 Agent 1185 | Offer (a=ice-lite a=ice-options:trickle) | 1186 |---------------------------------------------->| 1187 | |no cand 1188 | Answer (a=ice-options:trickle) |trickling 1189 |<----------------------------------------------| 1190 | Connectivity Checks | 1191 |<--------------------------------------------->| 1192 peer rflx| | 1193 cand disco| | 1194 | | 1195 |<=============== MEDIA FLOWS =================>| 1197 Figure 8: Example 1199 In addition to reducing signaling traffic this approach also removes 1200 the need to discover STUN bindings or make TURN allocations, which 1201 may considerably lighten ICE processing. 1203 Appendix C. Changes from Earlier Versions 1205 Note to the RFC Editor: please remove this section prior to 1206 publication as an RFC. 1208 C.1. Changes from draft-ietf-ice-trickle-16 1210 o Made "ufrag" terminology consistent with 5245bis. 1212 o Applied in-order delivery rule to end-of-candidates indication. 1214 C.2. Changes from draft-ietf-ice-trickle-15 1216 o Adjustments to address AD review feedback. 1218 C.3. Changes from draft-ietf-ice-trickle-14 1220 o Minor modifications to track changes to ICE core. 1222 C.4. Changes from draft-ietf-ice-trickle-13 1224 o Removed independent monitoring of check list "states" of frozen or 1225 active, since this is handled by placing a check list in the 1226 Running state defined in ICE core. 1228 C.5. Changes from draft-ietf-ice-trickle-12 1230 o Specified that the end-of-candidates indication must include the 1231 generation (ufrag/pwd) to enable association with a particular ICE 1232 session. 1234 o Further editorial fixes to address WGLC feedback. 1236 C.6. Changes from draft-ietf-ice-trickle-11 1238 o Editorial and terminological fixes to address WGLC feedback. 1240 C.7. Changes from draft-ietf-ice-trickle-10 1242 o Minor editorial fixes. 1244 C.8. Changes from draft-ietf-ice-trickle-09 1246 o Removed immediate unfreeze upon Fail. 1248 o Specified MUST NOT regarding ice-options. 1250 o Changed terminology regarding initial ICE parameters to avoid 1251 implementer confusion. 1253 C.9. Changes from draft-ietf-ice-trickle-08 1255 o Reinstated text about in-order processing of messages as a 1256 requirement for signaling protocols. 1258 o Added IANA registration template for ICE option. 1260 o Corrected Case 3 rule in Section 8.1.1 to ensure consistency with 1261 regular ICE rules. 1263 o Added tabular representations to Section 8.1.1 in order to 1264 illustrate the new pair rules. 1266 C.10. Changes from draft-ietf-ice-trickle-07 1268 o Changed "ICE description" to "candidate information" for 1269 consistency with 5245bis. 1271 C.11. Changes from draft-ietf-ice-trickle-06 1273 o Addressed editorial feedback from chairs' review. 1275 o Clarified terminology regarding generations. 1277 C.12. Changes from draft-ietf-ice-trickle-05 1279 o Rewrote the text on inserting a new pair into a check list. 1281 C.13. Changes from draft-ietf-ice-trickle-04 1283 o Removed dependency on SDP and offer/answer model. 1285 o Removed mentions of aggressive nomination, since it is deprecated 1286 in 5245bis. 1288 o Added section on requirements for signaling protocols. 1290 o Clarified terminology. 1292 o Addressed various WG feedback. 1294 C.14. Changes from draft-ietf-ice-trickle-03 1296 o Provided more detailed description of unfreezing behavior, 1297 specifically how to replace pre-existing peer-reflexive candidates 1298 with higher-priority ones received via trickling. 1300 C.15. Changes from draft-ietf-ice-trickle-02 1302 o Adjusted unfreezing behavior when there are disparate foundations. 1304 C.16. Changes from draft-ietf-ice-trickle-01 1306 o Changed examples to use IPv6. 1308 C.17. Changes from draft-ietf-ice-trickle-00 1310 o Removed dependency on SDP (which is to be provided in a separate 1311 specification). 1313 o Clarified text about the fact that a check list can be empty if no 1314 candidates have been sent or received yet. 1316 o Clarified wording about check list states so as not to define new 1317 states for "Active" and "Frozen" because those states are not 1318 defined for check lists (only for candidate pairs) in ICE core. 1320 o Removed open issues list because it was out of date. 1322 o Completed a thorough copy edit. 1324 C.18. Changes from draft-mmusic-trickle-ice-02 1326 o Addressed feedback from Rajmohan Banavi and Brandon Williams. 1328 o Clarified text about determining support and about how to proceed 1329 if it can be determined that the answering agent does not support 1330 Trickle ICE. 1332 o Clarified text about check list and timer updates. 1334 o Clarified when it is appropriate to use half trickle or to send no 1335 candidates in an offer or answer. 1337 o Updated the list of open issues. 1339 C.19. Changes from draft-ivov-01 and draft-mmusic-00 1341 o Added a requirement to trickle candidates by order of components 1342 to avoid deadlocks in the unfreezing algorithm. 1344 o Added an informative note on peer-reflexive candidates explaining 1345 that nothing changes for them semantically but they do become a 1346 more likely occurrence for Trickle ICE. 1348 o Limit the number of pairs to 100 to comply with 5245. 1350 o Added clarifications on the non-importance of how newly discovered 1351 candidates are trickled/sent to the remote party or if this is 1352 done at all. 1354 o Added transport expectations for trickled candidates as per Dale 1355 Worley's recommendation. 1357 C.20. Changes from draft-ivov-00 1359 o Specified that end-of-candidates is a media level attribute which 1360 can of course appear as session level, which is equivalent to 1361 having it appear in all m-lines. Also made end-of-candidates 1362 optional for cases such as aggressive nomination for controlled 1363 agents. 1365 o Added an example for ICE lite and Trickle ICE to illustrate how, 1366 when talking to an ICE lite agent doesn't need to send or even 1367 discover any candidates. 1369 o Added an example for ICE lite and Trickle ICE to illustrate how, 1370 when talking to an ICE lite agent doesn't need to send or even 1371 discover any candidates. 1373 o Added wording that explicitly states ICE lite agents have to be 1374 prepared to receive no candidates over signaling and that they 1375 should not freak out if this happens. (Closed the corresponding 1376 open issue). 1378 o It is now mandatory to use MID when trickling candidates and using 1379 m-line indexes is no longer allowed. 1381 o Replaced use of 0.0.0.0 to IP6 :: in order to avoid potential 1382 issues with RFC2543 SDP libraries that interpret 0.0.0.0 as an on- 1383 hold operation. Also changed the port number here from 1 to 9 1384 since it already has a more appropriate meaning. (Port change 1385 suggested by Jonathan Lennox). 1387 o Closed the Open Issue about use about what to do with cands 1388 received after end-of-cands. Solution: ignore, do an ICE restart 1389 if you want to add something. 1391 o Added more terminology, including trickling, trickled candidates, 1392 half trickle, full trickle, 1394 o Added a reference to the SIP usage for Trickle ICE as requested at 1395 the Boston interim. 1397 C.21. Changes from draft-rescorla-01 1399 o Brought back explicit use of Offer/Answer. There are no more 1400 attempts to try to do this in an O/A independent way. Also 1401 removed the use of ICE Descriptions. 1403 o Added SDP specification for trickled candidates, the trickle 1404 option and 0.0.0.0 addresses in m-lines, and end-of-candidates. 1406 o Support and Discovery. Changed that section to be less abstract. 1407 As discussed in IETF85, the draft now says implementations and 1408 usages need to either determine support in advance and directly 1409 use trickle, or do half trickle. Removed suggestion about use of 1410 discovery in SIP or about letting implementing protocols do what 1411 they want. 1413 o Defined Half Trickle. Added a section that says how it works. 1414 Mentioned that it only needs to happen in the first o/a (not 1415 necessary in updates), and added Jonathan's comment about how it 1416 could, in some cases, offer more than half the improvement if you 1417 can pre-gather part or all of your candidates before the user 1418 actually presses the call button. 1420 o Added a short section about subsequent offer/answer exchanges. 1422 o Added a short section about interactions with ICE Lite 1423 implementations. 1425 o Added two new entries to the open issues section. 1427 C.22. Changes from draft-rescorla-00 1429 o Relaxed requirements about verifying support following a 1430 discussion on MMUSIC. 1432 o Introduced ICE descriptions in order to remove ambiguous use of 1433 3264 language and inappropriate references to offers and answers. 1435 o Removed inappropriate assumption of adoption by RTCWEB pointed out 1436 by Martin Thomson. 1438 Authors' Addresses 1439 Emil Ivov 1440 Atlassian 1441 303 Colorado Street, #1600 1442 Austin, TX 78701 1443 USA 1445 Phone: +1-512-640-3000 1446 Email: eivov@atlassian.com 1448 Eric Rescorla 1449 RTFM, Inc. 1450 2064 Edgewood Drive 1451 Palo Alto, CA 94303 1452 USA 1454 Phone: +1 650 678 2350 1455 Email: ekr@rtfm.com 1457 Justin Uberti 1458 Google 1459 747 6th St S 1460 Kirkland, WA 98033 1461 USA 1463 Phone: +1 857 288 8888 1464 Email: justin@uberti.name 1466 Peter Saint-Andre 1467 Mozilla 1468 P.O. Box 787 1469 Parker, CO 80134 1470 USA 1472 Phone: +1 720 256 6756 1473 Email: stpeter@mozilla.com 1474 URI: https://www.mozilla.com/