idnits 2.17.1 draft-ietf-ice-rfc5245bis-09.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 14 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1717 has weird spacing: '... | f-cp f-cp ...' == Line 1719 has weird spacing: '... | f-cp f-cp ...' == Line 1730 has weird spacing: '... | w-cp w-cp ...' == Line 1732 has weird spacing: '... | f-cp f-cp ...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 20, 2017) is 2553 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6336 (Obsoleted by RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 4091 (Obsoleted by RFC 5245) -- Obsolete informational reference (is this intentional?): RFC 4092 (Obsoleted by RFC 5245) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-12 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICE A. Keranen 3 Internet-Draft C. Holmberg 4 Obsoletes: 5245 (if approved) Ericsson 5 Intended status: Standards Track J. Rosenberg 6 Expires: October 22, 2017 jdrosen.net 7 April 20, 2017 9 Interactive Connectivity Establishment (ICE): A Protocol for Network 10 Address Translator (NAT) Traversal 11 draft-ietf-ice-rfc5245bis-09 13 Abstract 15 This document describes a protocol for Network Address Translator 16 (NAT) traversal for UDP-based multimedia. This protocol is called 17 Interactive Connectivity Establishment (ICE). ICE makes use of the 18 Session Traversal Utilities for NAT (STUN) protocol and its 19 extension, Traversal Using Relay NAT (TURN). 21 This document obsoletes RFC 5245. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 22, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 8 72 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10 73 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 11 74 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 12 75 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 13 76 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 13 77 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 14 78 2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 15 79 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 4. ICE Candidate Gathering and Exchange . . . . . . . . . . . . 18 81 4.1. Procedures for Full Implementation . . . . . . . . . . . 19 82 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 83 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 20 84 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 21 85 4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 23 86 4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 23 87 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 24 88 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 24 89 4.1.2.2. Guidelines for Choosing Type and Local 90 Preferences . . . . . . . . . . . . . . . . . . . 25 91 4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 26 92 4.2. Lite Implementation Procedures . . . . . . . . . . . . . 26 93 4.3. Encoding the Candidate Information . . . . . . . . . . . 27 94 4.4. Verifying ICE Support . . . . . . . . . . . . . . . . . . 29 95 5. ICE Candidate Processing . . . . . . . . . . . . . . . . . . 29 96 5.1. Procedures for Full Implementation . . . . . . . . . . . 30 97 5.1.1. Determining Role . . . . . . . . . . . . . . . . . . 30 98 5.1.2. Forming the Check Lists . . . . . . . . . . . . . . . 31 99 5.1.2.1. Check List State . . . . . . . . . . . . . . . . 31 100 5.1.2.2. Forming Candidate Pairs . . . . . . . . . . . . . 32 101 5.1.2.3. Computing Pair Priority and Ordering Pairs . . . 35 102 5.1.2.4. Pruning the Pairs . . . . . . . . . . . . . . . . 35 103 5.1.2.5. Removing lower-priority Pairs . . . . . . . . . . 35 104 5.1.2.6. Computing Candidate Pair States . . . . . . . . . 35 105 5.1.3. ICE State . . . . . . . . . . . . . . . . . . . . . . 39 106 5.1.4. Scheduling Checks . . . . . . . . . . . . . . . . . . 40 107 5.1.4.1. Triggered Check Queue . . . . . . . . . . . . . . 40 108 5.1.4.2. Performing Connectivity Checks . . . . . . . . . 40 109 5.2. Lite Implementation Procedures . . . . . . . . . . . . . 41 110 6. Performing Connectivity Checks . . . . . . . . . . . . . . . 42 111 6.1. STUN Extensions . . . . . . . . . . . . . . . . . . . . . 42 112 6.1.1. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 42 113 6.1.2. USE-CANDIDATE . . . . . . . . . . . . . . . . . . . . 42 114 6.1.3. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . . . 42 115 6.2. STUN Client Procedures . . . . . . . . . . . . . . . . . 43 116 6.2.1. Creating Permissions for Relayed Candidates . . . . . 43 117 6.2.2. Forming Credentials . . . . . . . . . . . . . . . . . 43 118 6.2.3. DiffServ Treatment . . . . . . . . . . . . . . . . . 43 119 6.2.4. Sending the Request . . . . . . . . . . . . . . . . . 44 120 6.2.5. Processing the Response . . . . . . . . . . . . . . . 44 121 6.2.5.1. Role Conflict . . . . . . . . . . . . . . . . . . 44 122 6.2.5.2. Failure . . . . . . . . . . . . . . . . . . . . . 45 123 6.2.5.2.1. Non-Symmetric Transport Addresses . . . . . . 45 124 6.2.5.2.2. ICMP Error . . . . . . . . . . . . . . . . . 45 125 6.2.5.2.3. Unrecoverable STUN Response . . . . . . . . . 45 126 6.2.5.3. Success . . . . . . . . . . . . . . . . . . . . . 45 127 6.2.5.3.1. Discovering Peer Reflexive Candidates . . . . 45 128 6.2.5.3.2. Constructing a Valid Pair . . . . . . . . . . 46 129 6.2.5.3.3. Updating Candidate Pair States . . . . . . . 47 130 6.2.5.3.4. Updating the Nominated Flag . . . . . . . . . 48 131 6.2.5.4. Check List State Updates . . . . . . . . . . . . 48 132 6.3. STUN Server Procedures . . . . . . . . . . . . . . . . . 48 133 6.3.1. Additional Procedures for Full Implementations . . . 49 134 6.3.1.1. Detecting and Repairing Role Conflicts . . . . . 49 135 6.3.1.2. Computing Mapped Address . . . . . . . . . . . . 50 136 6.3.1.3. Learning Peer Reflexive Candidates . . . . . . . 51 137 6.3.1.4. Triggered Checks . . . . . . . . . . . . . . . . 51 138 6.3.1.5. Updating the Nominated Flag . . . . . . . . . . . 52 139 6.3.2. Additional Procedures for Lite Implementations . . . 53 140 7. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 53 141 7.1. Procedures for Full Implementations . . . . . . . . . . . 53 142 7.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 53 143 7.1.2. Updating States . . . . . . . . . . . . . . . . . . . 54 144 7.2. Procedures for Lite Implementations . . . . . . . . . . . 55 145 7.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . 56 146 7.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . 56 147 7.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 57 148 7.3.1. Full Implementation Procedures . . . . . . . . . . . 57 149 7.3.2. Lite Implementation Procedures . . . . . . . . . . . 57 150 8. ICE Restarts . . . . . . . . . . . . . . . . . . . . . . . . 57 151 9. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . . 58 152 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 58 153 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 59 154 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 59 155 11.1.1. Procedures for Full Implementations . . . . . . . . 59 156 11.1.2. Procedures for Lite Implementations . . . . . . . . 60 157 11.1.3. Procedures for All Implementations . . . . . . . . . 60 158 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 61 159 12. Extensibility Considerations . . . . . . . . . . . . . . . . 61 160 13. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 62 161 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 62 162 13.2. Ta . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 163 13.3. RTO . . . . . . . . . . . . . . . . . . . . . . . . . . 64 164 14. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 165 15. Security Considerations . . . . . . . . . . . . . . . . . . . 69 166 15.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 70 167 15.2. Attacks on Server Reflexive Address Gathering . . . . . 72 168 15.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 73 169 15.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . 73 170 15.4.1. STUN Amplification Attack . . . . . . . . . . . . . 73 171 16. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 74 172 16.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 74 173 16.2. New Error Response Codes . . . . . . . . . . . . . . . . 75 174 17. Operational Considerations . . . . . . . . . . . . . . . . . 75 175 17.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 75 176 17.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 76 177 17.2.1. STUN and TURN Server Capacity Planning . . . . . . . 76 178 17.2.2. Gathering and Connectivity Checks . . . . . . . . . 76 179 17.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 77 180 17.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 77 181 17.4. Troubleshooting and Performance Management . . . . . . . 77 182 17.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 78 183 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 184 18.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 78 185 18.2. STUN Error Responses . . . . . . . . . . . . . . . . . . 78 186 18.3. ICE Options . . . . . . . . . . . . . . . . . . . . . . 78 187 19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 79 188 19.1. Problem Definition . . . . . . . . . . . . . . . . . . . 79 189 19.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 80 190 19.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 80 191 19.4. Requirements for a Long-Term Solution . . . . . . . . . 81 192 19.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 82 194 20. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 82 195 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82 196 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 197 22.1. Normative References . . . . . . . . . . . . . . . . . . 83 198 22.2. Informative References . . . . . . . . . . . . . . . . . 83 199 Appendix A. Lite and Full Implementations . . . . . . . . . . . 87 200 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 88 201 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 88 202 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 89 203 B.3. Purpose of the Related Address and Related Port 204 Attributes . . . . . . . . . . . . . . . . . . . . . . . 91 205 B.4. Importance of the STUN Username . . . . . . . . . . . . . 91 206 B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 93 207 B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 93 208 B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 94 209 B.8. Why Are Binding Indications Used for Keepalives? . . . . 94 210 Appendix C. Connectivity Check Bandwidth . . . . . . . . . . . . 94 211 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95 213 1. Introduction 215 Protocols establishing multimedia sessions between peers typically 216 involve exchanging IP addresses and ports for the media sources and 217 sinks. However this poses challenges when operated through Network 218 Address Translators (NATs) [RFC3235]. These protocols also seek to 219 create a media flow directly between participants, so that there is 220 no application layer intermediary between them. This is done to 221 reduce media latency, decrease packet loss, and reduce the 222 operational costs of deploying the application. However, this is 223 difficult to accomplish through NAT. A full treatment of the reasons 224 for this is beyond the scope of this specification. 226 Numerous solutions have been defined for allowing these protocols to 227 operate through NAT. These include Application Layer Gateways 228 (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple 229 Traversal of UDP Through NAT (STUN) [RFC3489] specification, and 230 Realm Specific IP [RFC3102] [RFC3103] along with session description 231 extensions needed to make them work, such as the Session Description 232 Protocol (SDP) [RFC4566] attribute for the Real Time Control Protocol 233 (RTCP) [RFC3605]. Unfortunately, these techniques all have pros and 234 cons which, make each one optimal in some network topologies, but a 235 poor choice in others. The result is that administrators and 236 implementors are making assumptions about the topologies of the 237 networks in which their solutions will be deployed. This introduces 238 complexity and brittleness into the system. What is needed is a 239 single solution that is flexible enough to work well in all 240 situations. 242 This specification defines Interactive Connectivity Establishment 243 (ICE) as a technique for NAT traversal for UDP-based media streams 244 (though ICE has been extended to handle other transport protocols, 245 such as TCP [RFC6544]). ICE works by exchanging a multiplicity of IP 246 addresses and ports which are then tested for connectivity by peer- 247 to-peer connectivity checks. The IP addresses and ports are 248 exchanged via mechanisms (for example, including in a offer/answer 249 exchange) and the connectivity checks are performed using Session 250 Traversal Utilities for NAT (STUN) specification [RFC5389]. ICE also 251 makes use of Traversal Using Relays around NAT (TURN) [RFC5766], an 252 extension to STUN. Because ICE exchanges a multiplicity of IP 253 addresses and ports for each media stream, it also allows for address 254 selection for multihomed and dual-stack hosts, and for this reason it 255 deprecates [RFC4091] and [RFC4092]. 257 2. Overview of ICE 259 In a typical ICE deployment, we have two endpoints (known as ICE 260 AGENTS) that want to communicate. They are able to communicate 261 indirectly via some signaling protocol (such as SIP), by which they 262 can exchange ICE candidates. Note that ICE is not intended for NAT 263 traversal for the signaling protocol, which is assumed to be provided 264 via another mechanism. At the beginning of the ICE process, the 265 agents are ignorant of their own topologies. In particular, they 266 might or might not be behind a NAT (or multiple tiers of NATs). ICE 267 allows the agents to discover enough information about their 268 topologies to potentially find one or more paths by which they can 269 communicate. 271 Figure 1 shows a typical environment for ICE deployment. The two 272 endpoints are labelled L and R (for left and right, which helps 273 visualize call flows). Both L and R are behind their own respective 274 NATs though they may not be aware of it. The type of NAT and its 275 properties are also unknown. Agents L and R are capable of engaging 276 in an candidate exchange process, whose purpose is to set up a media 277 session between L and R. Typically, this exchange will occur through 278 a signaling (e.g., SIP) server. 280 In addition to the agents, a signaling server and NATs, ICE is 281 typically used in concert with STUN or TURN servers in the network. 282 Each agent can have its own STUN or TURN server, or they can be the 283 same. 285 +---------+ 286 +--------+ |Signaling| +--------+ 287 | STUN | |Server | | STUN | 288 | Server | +---------+ | Server | 289 +--------+ / \ +--------+ 290 / \ 291 / \ 292 / <- Signaling -> \ 293 / \ 294 +--------+ +--------+ 295 | NAT | | NAT | 296 +--------+ +--------+ 297 / \ 298 / \ 299 +-------+ +-------+ 300 | Agent | | Agent | 301 | L | | R | 302 +-------+ +-------+ 304 Figure 1: ICE Deployment Scenario 306 The basic idea behind ICE is as follows: each agent has a variety of 307 candidate TRANSPORT ADDRESSES (combination of IP address and port for 308 a particular transport protocol, which is always UDP in this 309 specification) it could use to communicate with the other agent. 310 These might include: 312 o A transport address on a directly attached network interface 314 o A translated transport address on the public side of a NAT (a 315 "server reflexive" address) 317 o A transport address allocated from a TURN server (a "relayed 318 address") 320 Potentially, any of L's candidate transport addresses can be used to 321 communicate with any of R's candidate transport addresses. In 322 practice, however, many combinations will not work. For instance, if 323 L and R are both behind NATs, their directly attached interface 324 addresses are unlikely to be able to communicate directly (this is 325 why ICE is needed, after all!). The purpose of ICE is to discover 326 which pairs of addresses will work. The way that ICE does this is to 327 systematically try all possible pairs (in a carefully sorted order) 328 until it finds one or more that work. 330 2.1. Gathering Candidate Addresses 332 In order to execute ICE, an agent has to identify all of its address 333 candidates. A CANDIDATE is a transport address -- a combination of 334 IP address and port for a particular transport protocol (with only 335 UDP specified here). This document defines three types of 336 candidates, some derived from physical or logical network interfaces, 337 others discoverable via STUN and TURN. Naturally, one viable 338 candidate is a transport address obtained directly from a local 339 interface. Such a candidate is called a HOST CANDIDATE. The local 340 interface could be Ethernet or WiFi, or it could be one that is 341 obtained through a tunnel mechanism, such as a Virtual Private 342 Network (VPN) or Mobile IP (MIP). In all cases, such a network 343 interface appears to the agent as a local interface from which ports 344 (and thus candidates) can be allocated. 346 If an agent is multihomed, it obtains a candidate from each IP 347 address. Depending on the location of the PEER (the other agent in 348 the session) on the IP network relative to the agent, the agent may 349 be reachable by the peer through one or more of those IP addresses. 350 Consider, for example, an agent that has a local IP address on a 351 private net 10 network (I1), and a second connected to the public 352 Internet (I2). A candidate from I1 will be directly reachable when 353 communicating with a peer on the same private net 10 network, while a 354 candidate from I2 will be directly reachable when communicating with 355 a peer on the public Internet. Rather than trying to guess which IP 356 address will work, the initiating sends both the candidates to its 357 peer. 359 Next, the agent uses STUN or TURN to obtain additional candidates. 360 These come in two flavors: translated addresses on the public side of 361 a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers 362 (RELAYED CANDIDATES). When TURN servers are utilized, both types of 363 candidates are obtained from the TURN server. If only STUN servers 364 are utilized, only server reflexive candidates are obtained from 365 them. The relationship of these candidates to the host candidate is 366 shown in Figure 2. In this figure, both types of candidates are 367 discovered using TURN. In the figure, the notation X:x means IP 368 address X and UDP port x. 370 To Internet 372 | 373 | 374 | /------------ Relayed 375 Y:y | / Address 376 +--------+ 377 | | 378 | TURN | 379 | Server | 380 | | 381 +--------+ 382 | 383 | 384 | /------------ Server 385 X1':x1'|/ Reflexive 386 +------------+ Address 387 | NAT | 388 +------------+ 389 | 390 | /------------ Local 391 X:x |/ Address 392 +--------+ 393 | | 394 | Agent | 395 | | 396 +--------+ 398 Figure 2: Candidate Relationships 400 When the agent sends the TURN Allocate request from IP address and 401 port X:x, the NAT (assuming there is one) will create a binding 402 X1':x1', mapping this server reflexive candidate to the host 403 candidate X:x. Outgoing packets sent from the host candidate will be 404 translated by the NAT to the server reflexive candidate. Incoming 405 packets sent to the server reflexive candidate will be translated by 406 the NAT to the host candidate and forwarded to the agent. We call 407 the host candidate associated with a given server reflexive candidate 408 the BASE. 410 Note: "Base" refers to the address an agent sends from for a 411 particular candidate. Thus, as a degenerate case host candidates 412 also have a base, but it's the same as the host candidate. 414 When there are multiple NATs between the agent and the TURN server, 415 the TURN request will create a binding on each NAT, but only the 416 outermost server reflexive candidate (the one nearest the TURN 417 server) will be discovered by the agent. If the agent is not behind 418 a NAT, then the base candidate will be the same as the server 419 reflexive candidate and the server reflexive candidate is redundant 420 and will be eliminated. 422 The Allocate request then arrives at the TURN server. The TURN 423 server allocates a port y from its local IP address Y, and generates 424 an Allocate response, informing the agent of this relayed candidate. 425 The TURN server also informs the agent of the server reflexive 426 candidate, X1':x1' by copying the source transport address of the 427 Allocate request into the Allocate response. The TURN server acts as 428 a packet relay, forwarding traffic between L and R. In order to send 429 traffic to L, R sends traffic to the TURN server at Y:y, and the TURN 430 server forwards that to X1':x1', which passes through the NAT where 431 it is mapped to X:x and delivered to L. 433 When only STUN servers are utilized, the agent sends a STUN Binding 434 request [RFC5389] to its STUN server. The STUN server will inform 435 the agent of the server reflexive candidate X1':x1' by copying the 436 source transport address of the Binding request into the Binding 437 response. 439 2.2. Connectivity Checks 441 Once L has gathered all of its candidates, it orders them in highest 442 to lowest-priority and sends them to R over the signaling channel. 443 When R receives the candidates from L, it performs the same gathering 444 process and responds with its own list of candidates. At the end of 445 this process, each agent has a complete list of both its candidates 446 and its peer's candidates. It pairs them up, resulting in CANDIDATE 447 PAIRS. To see which pairs work, each agent schedules a series of 448 CHECKS. Each check is a STUN request/response transaction that the 449 client will perform on a particular candidate pair by sending a STUN 450 request from the local candidate to the remote candidate. 452 The basic principle of the connectivity checks is simple: 454 1. Sort the candidate pairs in priority order. 456 2. Send checks on each candidate pair in priority order. 458 3. Acknowledge checks received from the other agent. 460 With both agents performing a check on a candidate pair, the result 461 is a 4-way handshake: 463 L R 464 - - 465 STUN request -> \ L's 466 <- STUN response / check 468 <- STUN request \ R's 469 STUN response -> / check 471 Figure 3: Basic Connectivity Check 473 It is important to note that the STUN requests are sent to and from 474 the exact same IP addresses and ports that will be used for media 475 (e.g., RTP and RTCP). Consequently, agents demultiplex STUN and RTP/ 476 RTCP using contents of the packets, rather than the port on which 477 they are received. Fortunately, this demultiplexing is easy to do, 478 especially for RTP and RTCP. 480 Because a STUN Binding request is used for the connectivity check, 481 the STUN Binding response will contain the agent's translated 482 transport address on the public side of any NATs between the agent 483 and its peer. If this transport address is different from other 484 candidates the agent already learned, it represents a new candidate, 485 called a PEER REFLEXIVE CANDIDATE, which then gets tested by ICE just 486 the same as any other candidate. 488 As an optimization, as soon as R gets L's check message, R schedules 489 a connectivity check message to be sent to L on the same candidate 490 pair. This accelerates the process of finding a valid candidate, and 491 is called a TRIGGERED CHECK. 493 At the end of this handshake, both L and R know that they can send 494 (and receive) messages end-to-end in both directions. 496 2.3. Sorting Candidates 498 Because the algorithm above searches all candidate pairs, if a 499 working pair exists it will eventually find it no matter what order 500 the candidates are tried in. In order to produce faster (and better) 501 results, the candidates are sorted in a specified order. The 502 resulting list of sorted candidate pairs is called the CHECK LIST. 503 The algorithm is described in Section 4.1.2 but follows two general 504 principles: 506 o Each agent gives its candidates a numeric priority, which is sent 507 along with the candidate to the peer. 509 o The local and remote priorities are combined so that each agent 510 has the same ordering for the candidate pairs. 512 The second property is important for getting ICE to work when there 513 are NATs in front of L and R. Frequently, NATs will not allow 514 packets in from a host until the agent behind the NAT has sent a 515 packet towards that host. Consequently, ICE checks in each direction 516 will not succeed until both sides have sent a check through their 517 respective NATs. 519 The agent works through this CHECK LIST by sending a STUN request for 520 the next candidate pair on the list periodically. These are called 521 ORDINARY CHECKS. 523 In general, the priority algorithm is designed so that candidates of 524 similar type get similar priorities and so that more direct routes 525 (that is, through fewer media relays and through fewer NATs) are 526 preferred over indirect ones (ones with more media relays and more 527 NATs). Within those guidelines, however, agents have a fair amount 528 of discretion about how to tune their algorithms. 530 2.4. Frozen Candidates 532 The previous description only addresses the case where the agents 533 wish to establish a media session with one COMPONENT (a piece of a 534 media stream requiring a single transport address; a media stream may 535 require multiple components, each of which has to work for the media 536 stream as a whole to be work). Sometimes (e.g., with RTP and RTCP in 537 separate components), the agents actually need to establish 538 connectivity for more than one flow. 540 The network properties are likely to be very similar for each 541 component (especially because RTP and RTCP are sent and received from 542 the same IP address). It is usually possible to leverage information 543 from one media component in order to determine the best candidates 544 for another. ICE does this with a mechanism called "frozen 545 candidates". 547 Each candidate is associated with a property called its FOUNDATION. 548 Two candidates have the same foundation when they are "similar" -- of 549 the same type and obtained from the same host candidate and STUN/TURN 550 server using the same protocol. Otherwise, their foundation is 551 different. A candidate pair has a foundation too, which is just the 552 concatenation of the foundations of its two candidates. Initially, 553 only the candidate pairs with unique foundations are tested. The 554 other candidate pairs are marked "frozen". When the connectivity 555 checks for a candidate pair succeed, the other candidate pairs with 556 the same foundation are unfrozen. This avoids repeated checking of 557 components that are superficially more attractive but in fact are 558 likely to fail. 560 While we've described "frozen" here as a separate mechanism for 561 expository purposes, in fact it is an integral part of ICE and the 562 ICE prioritization algorithm automatically ensures that the right 563 candidates are unfrozen and checked in the right order. However, if 564 the ICE usage does not utilize multiple components or media streams, 565 it does not need to implement this algorithm. 567 2.5. Security for Checks 569 Because ICE is used to discover which addresses can be used to send 570 media between two agents, it is important to ensure that the process 571 cannot be hijacked to send media to the wrong location. Each STUN 572 connectivity check is covered by a message authentication code (MAC) 573 computed using a key exchanged in the signaling channel. This MAC 574 provides message integrity and data origin authentication, thus 575 stopping an attacker from forging or modifying connectivity check 576 messages. Furthermore, if for example a SIP [RFC3261] caller is 577 using ICE, and their call forks, the ICE exchanges happen 578 independently with each forked recipient. In such a case, the keys 579 exchanged in the signaling help associate each ICE exchange with each 580 forked recipient. 582 2.6. Concluding ICE 584 ICE checks are performed in a specific sequence, so that high- 585 priority candidate pairs are checked first, followed by lower- 586 priority ones. One way to conclude ICE is to declare victory as soon 587 as a check for each component of each media stream completes 588 successfully. Indeed, this is a reasonable algorithm, and details 589 for it are provided below. However, it is possible that a packet 590 loss will cause a higher-priority check to take longer to complete. 591 In that case, allowing ICE to run a little longer might produce 592 better results. More fundamentally, however, the prioritization 593 defined by this specification may not yield "optimal" results. As an 594 example, if the aim is to select low-latency media paths, usage of a 595 relay is a hint that latencies may be higher, but it is nothing more 596 than a hint. An actual round-trip time (RTT) measurement could be 597 made, and it might demonstrate that a pair with lower priority is 598 actually better than one with higher priority. 600 Consequently, ICE assigns one of the agents in the role of the 601 CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The 602 controlling agent gets to nominate which candidate pairs will get 603 used for media amongst the ones that are valid. 605 When nominating, the controlling agent lets the checks continue until 606 at least one valid candidate pair for each media stream is found. 607 Then, it picks amongst those that are valid, and sends a second STUN 608 request on its NOMINATED candidate pair, but this time with a flag 609 set to tell the peer that this pair has been nominated for use. This 610 is shown in Figure 4. 612 L R 613 - - 614 STUN request -> \ L's 615 <- STUN response / check 617 <- STUN request \ R's 618 STUN response -> / check 620 STUN request + flag -> \ L's 621 <- STUN response / check 623 Figure 4: Nomination 625 Once the STUN transaction with the flag completes, both sides cancel 626 any future checks for that media stream. ICE will now send media 627 using this pair. The pair an ICE agent is using for media is called 628 the SELECTED PAIR. 630 Once ICE is concluded, it can be restarted at any time for one or all 631 of the media streams by either agent. This is done by sending an 632 updated candidate information indicating a restart. 634 2.7. Lite Implementations 636 In order for ICE to be used in a call, both agents need to support 637 it. However, certain agents will always be connected to the public 638 Internet and have a public IP address at which it can receive packets 639 from any correspondent. To make it easier for these devices to 640 support ICE, ICE defines a special type of implementation called LITE 641 (in contrast to the normal FULL implementation). A lite 642 implementation doesn't gather candidates; it includes only host 643 candidates for any media stream. Lite agents do not generate 644 connectivity checks or run the state machines, though they need to be 645 able to respond to connectivity checks. When a lite implementation 646 connects with a full implementation, the full agent takes the role of 647 the controlling agent, and the lite agent takes on the controlled 648 role. When two lite implementations connect, no checks are sent. 650 For guidance on when a lite implementation is appropriate, see the 651 discussion in Appendix A. 653 It is important to note that the lite implementation was added to 654 this specification to provide a stepping stone to full 655 implementation. Even for devices that are always connected to the 656 public Internet, a full implementation is preferable if achievable. 658 2.8. Usages of ICE 660 This document specifies generic use of ICE with protocols that 661 provide means to exchange candidate information between the ICE 662 Peers. The specific details of (i.e how to encode candidate 663 information and the actual candidate exchange process) for different 664 protocols using ICE are described in separate usage documents. One 665 possible way the agents can exchange the candidate information is to 666 use [RFC3264] based Offer/Answer semantics as part of the SIP 667 [RFC3261] protocol [I-D.ietf-mmusic-ice-sip-sdp]. 669 3. Terminology 671 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 672 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 673 "OPTIONAL" in this document are to be interpreted as described in RFC 674 2119 [RFC2119]. 676 Readers should be familiar with the terminology defined in the STUN 677 [RFC5389], and NAT Behavioral requirements for UDP [RFC4787]. 679 This specification makes use of the following additional terminology: 681 ICE Agent: An agent is the protocol implementation involved in the 682 ICE candidate exchange. There are two agents involved in a 683 typical candidate exchange. 685 Initiating Peer, Initiating Agent, Initiator: An initiating agent is 686 the protocol implementation involved in the ICE candidate exchange 687 that initiates the ICE candidate exchange process. 689 Responding Peer, Responding Agent, Responder: A receiving agent is 690 the protocol implementation involved in the ICE candidate exchange 691 that receives and responds to the candidate exchange process 692 initiated by the Initiator. 694 ICE Candidate Exchange, Candidate Exchange: The process where the 695 ICE agents exchange information (e.g., candidates and passwords) 696 that is needed to perform ICE. [RFC3264] Offer/Answer with SDP 697 encoding is one example of a protocol that can be used for 698 exchanging the candidate information. 700 Peer: From the perspective of one of the agents in a session, its 701 peer is the other agent. Specifically, from the perspective of 702 the initiating agent, the peer is the responding agent. From the 703 perspective of the responding agent, the peer is the initiating 704 agent. 706 Transport Address: The combination of an IP address and transport 707 protocol (such as UDP or TCP) port. 709 Media, Media Stream, Media Session: When ICE is used to setup 710 multimedia sessions, the media is usually transported over RTP, 711 and a media stream composes of a stream of RTP packets. When ICE 712 is used with other than multimedia sessions, the terms "media", 713 "media stream", and "media session" are still used in this 714 specification to refer to the IP data packets that are exchanged 715 between the peers on the path created and tested with ICE. 717 Candidate, Candidate Information: A transport address that is a 718 potential point of contact for receipt of media. Candidates also 719 have properties -- their type (server reflexive, relayed, or 720 host), priority,foundation, and base. 722 Component: A component is a piece of a media stream requiring a 723 single transport address; a media stream may require multiple 724 components, each of which has to work for the media stream as a 725 whole to work. For media streams based on RTP, unless RTP and 726 RTCP are multiplexed in the same port, there are two components 727 per media stream -- one for RTP, and one for RTCP. 729 Host Candidate: A candidate obtained by binding to a specific port 730 from an IP address on the host. This includes IP addresses on 731 physical interfaces and logical ones, such as ones obtained 732 through Virtual Private Networks (VPNs) and Realm Specific IP 733 (RSIP) [RFC3102] (which lives at the operating system level). 735 Server Reflexive Candidate: A candidate whose IP address and port 736 are a binding allocated by a NAT for an agent when it sent a 737 packet through the NAT to a server. Server reflexive candidates 738 can be learned by STUN servers using the Binding request, or TURN 739 servers, which provides both a relayed and server reflexive 740 candidate. 742 Peer Reflexive Candidate: A candidate whose IP address and port are 743 a binding allocated by a NAT for an agent when it sent a STUN 744 Binding request through the NAT to its peer. 746 Relayed Candidate: A candidate obtained by sending a TURN Allocate 747 request from a host candidate to a TURN server. The relayed 748 candidate is resident on the TURN server, and the TURN server 749 relays packets back towards the agent. 751 Base: The transport address that an agent sends from for a 752 particular candidate. For host-, server reflexive- and peer 753 reflexive candidates the base is the same as the host candidate. 754 For relayed candidates the base is the same as the relayed 755 candidate (i.e., the transport address used by the TURN server to 756 send from). 758 Foundation: An arbitrary string that is the same for two candidates 759 that have the same type, base IP address, protocol (UDP, TCP, 760 etc.), and STUN or TURN server. If any of these are different, 761 then the foundation will be different. Two candidate pairs with 762 the same foundation pairs are likely to have similar network 763 characteristics. Foundations are used in the frozen algorithm. 765 Local Candidate: A candidate that an agent has obtained and shared 766 with the peer. 768 Remote Candidate: A candidate that an agent received from its peer. 770 Default Destination/Candidate: The default destination for a 771 component of a media stream is the transport address that would be 772 used by an agent that is not ICE aware. A default candidate for a 773 component is one whose transport address matches the default 774 destination for that component. 776 Candidate Pair: A pairing containing a local candidate and a remote 777 candidate. 779 Check, Connectivity Check, STUN Check: A STUN Binding request 780 transaction for the purposes of verifying connectivity. A check 781 is sent from the local candidate to the remote candidate of a 782 candidate pair. 784 Check List: An ordered set of candidate pairs that an agent will use 785 to generate checks. 787 Ordinary Check: A connectivity check generated by an agent as a 788 consequence of a timer that fires periodically, instructing it to 789 send a check. 791 Triggered Check: A connectivity check generated as a consequence of 792 the receipt of a connectivity check from the peer. 794 VALID LIST: An ordered set of candidate pairs for a media stream 795 that have been validated by a successful STUN transaction. 797 Check List Set: An ordered list of CHECK LISTs. 799 Full: An ICE implementation that performs the complete set of 800 functionality defined by this specification. 802 Lite: An ICE implementation that omits certain functions, 803 implementing only as much as is necessary for a peer 804 implementation that is full to gain the benefits of ICE. Lite 805 implementations do not maintain any of the state machines and do 806 not generate connectivity checks. 808 Controlling Agent: The ICE agent that is responsible for selecting 809 the final choice of candidate pairs and signaling them through 810 STUN. In any session, one agent is always controlling. The other 811 is the controlled agent. 813 Controlled Agent: An ICE agent that waits for the controlling agent 814 to select the final choice of candidate pairs. 816 Nomination, Regular Nomination: The process of picking a valid 817 candidate pair for media traffic by validating the pair with one 818 STUN request, and then picking it by sending a second STUN request 819 with a flag indicating its nomination. 821 Nominated: If a valid candidate pair has its nominated flag set, it 822 means that it may be selected by ICE for sending and receiving 823 media. 825 Selected Pair, Selected Candidate: The candidate pair selected by 826 ICE for sending and receiving media is called the selected pair, 827 and each of its candidates is called the selected candidate. 828 Before a pair has been selected, any valid candidate pair can be 829 used for sending and receiving media (only one candidate pair at 830 any given time). 832 Using Protocol, ICE Usage: The protocol that uses ICE for NAT 833 traversal. A usage specification defines the protocol specific 834 details on how the procedures defined here are applied to that 835 protocol. 837 4. ICE Candidate Gathering and Exchange 839 As part of ICE processing, both the initiating and responding agents 840 exchange encoded candidate information as defined by the Usage 841 Protocol (ICE Usage). Specifics of encoding mechanism and the 842 semantics of candidate information exchange is out of scope of this 843 specification. 845 However at a higher level, the below diagram captures ICE processing 846 sequence in the agents (initiator and responder) for exchange of 847 their respective candidate(s) information. 849 Initiating Responding 850 Agent Agent 851 (I) (R) 852 Gather, | | 853 prioritize, | | 854 eliminate | | 855 redundant | | 856 candidates, | | 857 Encode | | 858 candidates | | 859 | I's Candidate Information | 860 |------------------------------>| 861 | | Gather, 862 | | prioritize, 863 | | eliminate 864 | | redundant 865 | | candidates, 866 | | Encode 867 | | candidates 868 | R's Candidate Information | 869 |<------------------------------| 870 | | 872 Figure 5: Candidate Gathering and Exchange Sequence 874 As shown, the agents involved in the candidate exchange perform (1) 875 candidate gathering, (2) candidate prioritization, (3) eliminating 876 redundant candidates, (4) (possibly) choose default candidates, and 877 then (5) formulate and send the candidates to the Peer ICE agent. 878 All but the last of these five steps differ for full and lite 879 implementations. 881 4.1. Procedures for Full Implementation 883 4.1.1. Gathering Candidates 885 An agent gathers candidates when it believes that communication is 886 imminent. An initiating agent can do this based on a user interface 887 cue, or based on an explicit request to initiate a session. Every 888 candidate is a transport address. It also has a type and a base. 889 Four types are defined and gathered by this specification -- host 890 candidates, server reflexive candidates, peer reflexive candidates, 891 and relayed candidates. The server reflexive candidates are gathered 892 using STUN or TURN, and relayed candidates are obtained through TURN. 893 Peer reflexive candidates are obtained in later phases of ICE, as a 894 consequence of connectivity checks. 896 The process for gathering candidates at the responding agent is 897 identical to the process for the initiating agent. It is RECOMMENDED 898 that the responding agent begins this process immediately on receipt 899 of the candidate information, prior to alerting the user. Such 900 gathering MAY begin when an agent starts. 902 4.1.1.1. Host Candidates 904 The first step is to gather host candidates. Host candidates are 905 obtained by binding to ports (typically ephemeral) on a IP address 906 attached to an interface (physical or virtual, including VPN 907 interfaces) on the host. 909 For each UDP media stream the agent wishes to use, the agent SHOULD 910 obtain a candidate for each component of the media stream on each IP 911 address that the host has, with the exceptions listed below. The 912 agent obtains each candidate by binding to a UDP port on the specific 913 IP address. A host candidate (and indeed every candidate) is always 914 associated with a specific component for which it is a candidate. 916 Each component has an ID assigned to it, called the component ID. 917 For RTP-based media streams, unless both RTP and RTCP are multiplexed 918 in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a 919 component ID of 1, and RTCP a component ID of 2. In case of RTP/RTCP 920 multiplexing, a component ID of 1 is used for both RTP and RTCP. 922 When candidates are obtained, unless the agent knows for sure that 923 RTP/RTCP multiplexing will be used (i.e. the agent knows that the 924 other agent also supports, and is willing to use, RTP/RTCP 925 multiplexing), or unless the agent only supports RTP/RTCP 926 multiplexing, the agent MUST obtain a separate candidate for RTCP. 927 If an agent has obtained a candidate for RTCP, and ends up using RTP/ 928 RTCP multiplexing, the agent does not need to perform connectivity 929 checks on the RTCP candidate. 931 If an agent is using separate candidates for RTP and RTCP, it will 932 end up with 2*K host candidates if an agent has K IP addresses. 934 Note that the responding agent, when obtaining its candidates, will 935 typically know if the other agent supports RTP/RTCP multiplexing, in 936 which case it will not need to obtain a separate candidate for RTCP. 937 However, absence of a component ID 2 as such does not imply use of 938 RTCP/RTP multiplexing, as it could also mean that RTCP is not used. 940 For other than RTP-based streams, use of multiple components is 941 discouraged since using them increases the complexity of ICE 942 processing. If multiple components are needed, the component IDs 943 SHOULD start with 1 and increase by 1 for each component. 945 The base for each host candidate is set to the candidate itself. 947 The host candidates are gathered from all IP addresses with the 948 following exceptions: 950 o Addresses from a loopback interface MUST NOT be included in the 951 candidate addresses. 953 o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site- 954 local unicast addresses [RFC3879] MUST NOT be included in the 955 address candidates. 957 o IPv4-mapped IPv6 addresses SHOULD NOT be included in the offered 958 candidates unless the application using ICE does not support IPv4 959 (i.e., is an IPv6-only application [RFC4038]). 961 o If one or more host candidates corresponding to an IPv6 address 962 generated using a mechanism that prevents location tracking 963 [RFC7721] are gathered, host candidates corresponding to IPv6 964 addresses that do allow location tracking, that are configured on 965 the same interface, and are part of the same network prefix MUST 966 NOT be gathered; and host candidates corresponding to IPv6 link- 967 local addresses MUST NOT be gathered. 969 4.1.1.2. Server Reflexive and Relayed Candidates 971 Agents SHOULD obtain relayed candidates and SHOULD obtain server 972 reflexive candidates. These requirements are at SHOULD strength to 973 allow for provider variation. Use of STUN and TURN servers may be 974 unnecessary in closed networks where agents are never connected to 975 the public Internet or to endpoints outside of the closed network. 976 In such cases, a full implementation would be used for agents that 977 are dual-stack or multihomed, to select a host candidate. Use of 978 TURN servers is expensive, and when ICE is being used, they will only 979 be utilized when both endpoints are behind NATs that perform address 980 and port dependent mapping. Consequently, some deployments might 981 consider this use case to be marginal, and elect not to use TURN 982 servers. If an agent does not gather server reflexive or relayed 983 candidates, it is RECOMMENDED that the functionality be implemented 984 and just disabled through configuration, so that it can be re-enabled 985 through configuration if conditions change in the future. 987 If an agent is gathering both relayed and server reflexive 988 candidates, it uses a TURN server. If it is gathering just server 989 reflexive candidates, it uses a STUN server. 991 The agent next pairs each host candidate with the STUN or TURN server 992 with which it is configured or has discovered by some means. If a 993 STUN or TURN server is configured, it is RECOMMENDED that a domain 994 name be configured, and the DNS procedures in [RFC5389] (using SRV 995 records with the "stun" service) be used to discover the STUN server, 996 and the DNS procedures in [RFC5766] (using SRV records with the 997 "turn" service) be used to discover the TURN server. 999 This specification only considers usage of a single STUN or TURN 1000 server. When there are multiple choices for that single STUN or TURN 1001 server (when, for example, they are learned through DNS records and 1002 multiple results are returned), an agent SHOULD use a single STUN or 1003 TURN server (based on its IP address) for all candidates for a 1004 particular session. This improves the performance of ICE. The 1005 result is a set of pairs of host candidates with STUN or TURN 1006 servers. The agent then chooses one pair, and sends a Binding or 1007 Allocate request to the server from that host candidate. Binding 1008 requests to a STUN server are not authenticated, and any ALTERNATE- 1009 SERVER attribute in a response is ignored. Agents MUST support the 1010 backwards compatibility mode for the Binding request defined in 1011 [RFC5389]. Allocate requests SHOULD be authenticated using a long- 1012 term credential obtained by the client through some other means. 1014 Every Ta milliseconds thereafter, the agent can generate another new 1015 STUN or TURN transaction. This transaction can either be a retry of 1016 a previous transaction that failed with a recoverable error (such as 1017 authentication failure), or a transaction for a new host candidate 1018 and STUN or TURN server pair. The agent SHOULD NOT generate 1019 transactions more frequently than one every Ta milliseconds. See 1020 Section 13 for guidance on how to set Ta and the STUN retransmit 1021 timer, RTO. 1023 The agent will receive a Binding or Allocate response. A successful 1024 Allocate response will provide the agent with a server reflexive 1025 candidate (obtained from the mapped address) and a relayed candidate 1026 in the XOR-RELAYED-ADDRESS attribute. If the Allocate request is 1027 rejected because the server lacks resources to fulfill it, the agent 1028 SHOULD instead send a Binding request to obtain a server reflexive 1029 candidate. A Binding response will provide the agent with only a 1030 server reflexive candidate (also obtained from the mapped address). 1031 The base of the server reflexive candidate is the host candidate from 1032 which the Allocate or Binding request was sent. The base of a 1033 relayed candidate is that candidate itself. If a relayed candidate 1034 is identical to a host candidate (which can happen in rare cases), 1035 the relayed candidate MUST be discarded. 1037 If an IPv6-only agent is in a network that utilizes NAT64 [RFC6146] 1038 and DNS64 [RFC6147] technologies, it may gather also IPv4 server 1039 reflexive and/or relayed candidates from IPv4-only STUN or TURN 1040 servers. IPv6-only agents SHOULD also utilize IPv6 prefix discovery 1041 [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and 1042 generate server reflexive candidates for each IPv6-only interface 1043 accordingly. The NAT64 server reflexive candidates are prioritized 1044 like IPv4 server reflexive candidates. 1046 4.1.1.3. Computing Foundations 1048 Finally, the agent assigns each candidate a foundation. The 1049 foundation is an identifier, scoped within a session. Two candidates 1050 MUST have the same foundation ID when all of the following are true: 1052 o they are of the same type (host, relayed, server reflexive, or 1053 peer reflexive) 1055 o their bases have the same IP address (the ports can be different) 1057 o for reflexive and relayed candidates, the STUN or TURN servers 1058 used to obtain them have the same IP address 1060 o they were obtained using the same transport protocol (TCP, UDP, 1061 etc.) 1063 Similarly, two candidates MUST have different foundations if their 1064 types are different, their bases have different IP addresses, the 1065 STUN or TURN servers used to obtain them have different IP addresses, 1066 or their transport protocols are different. 1068 4.1.1.4. Keeping Candidates Alive 1070 Once server reflexive and relayed candidates are allocated, they MUST 1071 be kept alive until ICE processing has completed, as described in 1072 Section 7.3. For server reflexive candidates learned through a 1073 Binding request, the bindings MUST be kept alive by additional 1074 Binding requests to the server. Refreshes for allocations are done 1075 using the Refresh transaction, as described in [RFC5766]. The 1076 Refresh requests will also refresh the server reflexive candidate. 1078 4.1.2. Prioritizing Candidates 1080 The prioritization process results in the assignment of a priority to 1081 each candidate. Each candidate for a media stream MUST have a unique 1082 priority that MUST be a positive integer between 1 and (2**31 - 1). 1083 This priority will be used by ICE to determine the order of the 1084 connectivity checks and the relative preference for candidates. 1086 An agent SHOULD compute this priority using the formula in 1087 Section 4.1.2.1 and choose its parameters using the guidelines in 1088 Section 4.1.2.2. If an agent elects to use a different formula, ICE 1089 will take longer to converge since both agents will not be 1090 coordinated in their checks. 1092 The process for prioritizing candidates is common across the 1093 initiating and the responding agent. 1095 4.1.2.1. Recommended Formula 1097 When using the formula, an agent computes the priority by determining 1098 a preference for each type of candidate (server reflexive, peer 1099 reflexive, relayed, and host), and, when the agent is multihomed, 1100 choosing a preference for its IP addresses. These two preferences 1101 are then combined to compute the priority for a candidate. That 1102 priority is computed using the following formula: 1104 priority = (2^24)*(type preference) + 1105 (2^8)*(local preference) + 1106 (2^0)*(256 - component ID) 1108 The type preference MUST be an integer from 0 to 126 inclusive, and 1109 represents the preference for the type of the candidate (where the 1110 types are local, server reflexive, peer reflexive, and relayed). A 1111 126 is the highest preference, and a 0 is the lowest. Setting the 1112 value to a 0 means that candidates of this type will only be used as 1113 a last resort. The type preference MUST be identical for all 1114 candidates of the same type and MUST be different for candidates of 1115 different types. The type preference for peer reflexive candidates 1116 MUST be higher than that of server reflexive candidates. Note that 1117 candidates gathered based on the procedures of Section 4.1.1 will 1118 never be peer reflexive candidates; candidates of these type are 1119 learned from the connectivity checks performed by ICE. 1121 The local preference MUST be an integer from 0 to 65535 inclusive. 1122 It represents a preference for the particular IP address from which 1123 the candidate was obtained. 65535 represents the highest preference, 1124 and a zero, the lowest. When there is only a single IP address, this 1125 value SHOULD be set to 65535. More generally, if there are multiple 1126 candidates for a particular component for a particular media stream 1127 that have the same type, the local preference MUST be unique for each 1128 one. In this specification, this only happens for multihomed hosts 1129 or if an agent is using multiple TURN servers. If a host is 1130 multihomed because it is dual-stack, the local preference should be 1131 set according to the current best practice described in 1132 [I-D.ietf-ice-dualstack-fairness]. 1134 The component ID is the component ID for the candidate, and MUST be 1135 between 1 and 256 inclusive. 1137 4.1.2.2. Guidelines for Choosing Type and Local Preferences 1139 One criterion for selection of the type and local preference values 1140 is the use of a media intermediary, such as a TURN server, a tunnel 1141 service such as VPN server, or NAT. With a media intermediary, if 1142 media is sent to that candidate, it will first transit the media 1143 intermediary before being received. Relayed candidates are one type 1144 of candidate that involves a media intermediary. Another are host 1145 candidates obtained from a VPN interface. When media is transited 1146 through a media intermediary, it can have a positive or negative 1147 effect on the latency between transmission and reception. It may or 1148 may not increase the packet losses, because of the additional router 1149 hops that may be taken. It may increase the cost of providing 1150 service, since media will be routed in and right back out of a media 1151 intermediary run by a provider. If these concerns are important, the 1152 type preference for relayed candidates must be carefully chosen. The 1153 RECOMMENDED values are 126 for host candidates, 100 for server 1154 reflexive candidates, 110 for peer reflexive candidates, and 0 for 1155 relayed candidates. 1157 Furthermore, if an agent is multihomed and has multiple IP addresses, 1158 the recommendation in [I-D.ietf-ice-dualstack-fairness] should be 1159 followed. If multiple TURN servers are used, local priorities for 1160 the candidates obtained from the TURN servers are chosen in a similar 1161 fashion as for multihomed local candidates: the local preference 1162 value is used to indicate a preference among different servers but 1163 the preference MUST be unique for each one. 1165 Another criterion for selection of preferences is IP address family. 1166 ICE works with both IPv4 and IPv6. It provides a transition 1167 mechanism that allows dual-stack hosts to prefer connectivity over 1168 IPv6, but to fall back to IPv4 in case the v6 networks are 1169 disconnected. Implementation should follow the guidelines from 1170 [I-D.ietf-ice-dualstack-fairness] to avoid excessively delays in the 1171 connectivity check phase if broken paths exist. 1173 Another criterion for selecting preferences is topological awareness. 1174 This is most useful for candidates that make use of intermediaries. 1175 In those cases, if an agent has preconfigured or dynamically 1176 discovered knowledge of the topological proximity of the 1177 intermediaries to itself, it can use that to assign higher local 1178 preferences to candidates obtained from closer intermediaries. 1180 Another criterion for selecting preferences might be security or 1181 privacy. If a user is a telecommuter, and therefore connected to a 1182 corporate network and a local home network, the user may prefer their 1183 voice traffic to be routed over the VPN or similar tunnel in order to 1184 keep it on the corporate network when communicating within the 1185 enterprise, but use the local network when communicating with users 1186 outside of the enterprise. In such a case, a VPN address would have 1187 a higher local preference than any other address. 1189 4.1.3. Eliminating Redundant Candidates 1191 Next, the agent eliminates redundant candidates. A candidate is 1192 redundant if its transport address equals another candidate, and its 1193 base equals the base of that other candidate. Note that two 1194 candidates can have the same transport address yet have different 1195 bases, and these would not be considered redundant. Frequently, a 1196 server reflexive candidate and a host candidate will be redundant 1197 when the agent is not behind a NAT. The agent SHOULD eliminate the 1198 redundant candidate with the lower priority. 1200 This process is common across the initiating and responding agents. 1202 4.2. Lite Implementation Procedures 1204 Lite implementations only utilize host candidates. A lite 1205 implementation MUST, for each component of each media stream, 1206 allocate zero or one IPv4 candidates. It MAY allocate zero or more 1207 IPv6 candidates, but no more than one per each IPv6 address utilized 1208 by the host. Since there can be no more than one IPv4 candidate per 1209 component of each media stream, if an agent has multiple IPv4 1210 addresses, it MUST choose one for allocating the candidate. If a 1211 host is dual-stack, it is RECOMMENDED that it allocate one IPv4 1212 candidate and one global IPv6 address. With the lite implementation, 1213 ICE cannot be used to dynamically choose amongst candidates. 1214 Therefore, including more than one candidate from a particular scope 1215 is NOT RECOMMENDED, since only a connectivity check can truly 1216 determine whether to use one address or the other. 1218 Each component has an ID assigned to it, called the component ID. 1219 For RTP-based media streams, unless RTCP is multiplexed in the same 1220 port with RTP, the RTP itself has a component ID of 1, and RTCP a 1221 component ID of 2. If an agent is using RTCP without multiplexing, 1222 it MUST obtain candidates for it. However, absence of a component ID 1223 2 as such does not imply use of RTCP/RTP multiplexing, as it could 1224 also mean that RTCP is not used. 1226 Each candidate is assigned a foundation. The foundation MUST be 1227 different for two candidates allocated from different IP addresses, 1228 and MUST be the same otherwise. A simple integer that increments for 1229 each IP address will suffice. In addition, each candidate MUST be 1230 assigned a unique priority amongst all candidates for the same media 1231 stream. This priority SHOULD be equal to: 1233 priority = (2^24)*(126) + 1234 (2^8)*(IP precedence) + 1235 (2^0)*(256 - component ID) 1237 If a host is v4-only, it SHOULD set the IP precedence to 65535. If a 1238 host is v6 or dual-stack, the IP precedence SHOULD be the precedence 1239 value for IP addresses described in RFC 6724 [RFC6724]. 1241 Next, an agent chooses a default candidate for each component of each 1242 media stream. If a host is IPv4-only, there would only be one 1243 candidate for each component of each media stream, and therefore that 1244 candidate is the default. If a host is IPv6 or dual-stack, the 1245 selection of default is a matter of local policy. This default 1246 SHOULD be chosen such that it is the candidate most likely to be used 1247 with a peer. For IPv6-only hosts, this would typically be a globally 1248 scoped IPv6 address. For dual-stack hosts, the IPv4 address is 1249 RECOMMENDED. 1251 The procedures in this section is common across the initiating and 1252 responding agents. 1254 4.3. Encoding the Candidate Information 1256 Regardless of the agent being an Initiator or Responder Agent, the 1257 following parameters and their data types needs to be conveyed as 1258 part of the candidate exchange process. The specifics of syntax for 1259 encoding the candidate information is out of scope of this 1260 specification. 1262 Candidate attribute There will be one or more of these for each 1263 "media stream". Each candidate is composed of: 1265 Connection Address: The IP address and transport protocol port of 1266 the candidate. 1268 Transport: An indicator of the transport protocol for this 1269 candidate. This need not be present if the using protocol will 1270 only ever run over a single transport protocol. If it runs 1271 over more than one, or if others are anticipated to be used in 1272 the future, this should be present. 1274 Foundation: A sequence of up to 32 characters. 1276 Component-ID: This would be present only if the using protocol 1277 were utilizing the concept of components. If it is, it would 1278 be a positive integer that indicates the component ID for which 1279 this is a candidate. 1281 Priority: An encoding of the 32-bit priority value. 1283 Candidate Type: The candidate type, as defined in ICE. 1285 Related Address and Port: The related IP address and port for 1286 this candidate, as defined by ICE. These MAY be omitted or set 1287 to invalid values if the agent does not want to reveal them, 1288 e.g., for privacy reasons. 1290 Extensibility Parameters: The using protocol should define some 1291 means for adding new per-candidate ICE parameters in the 1292 future. 1294 Lite Flag: If ICE lite is used by the using protocol, it needs to 1295 convey a boolean parameter which indicates whether the 1296 implementation is lite or not. 1298 Connectivity check pacing value: If an agent wants to use other than 1299 the default pacing values for the connectivity checks, it MUST 1300 indicate this in the ICE exchange. 1302 Username Fragment and Password: The using protocol has to convey a 1303 username fragment and password. The username fragment MUST 1304 contain at least 24 bits of randomness, and the password MUST 1305 contain at least 128 bits of randomness. 1307 ICE extensions: In addition to the per-candidate extensions above, 1308 the using protocol should allow for new media-stream or session- 1309 level attributes (ice-options). 1311 If the using protocol is using the ICE mismatch feature, a way is 1312 needed to convey this parameter in answers. It is a boolean flag. 1314 The exchange of parameters is symmetric; both agents need to send the 1315 same set of attributes as defined above. 1317 The using protocol may (or may not) need to deal with backwards 1318 compatibility with older implementations that do not support ICE. If 1319 the fallback mechanism is being used, then presumably the using 1320 protocol provides a way of conveying the default candidate (its IP 1321 address and port) in addition to the ICE parameters. 1323 STUN connectivity checks between agents are authenticated using the 1324 short-term credential mechanism defined for STUN [RFC5389]. This 1325 mechanism relies on a username and password that are exchanged 1326 through protocol machinery between the client and server. The 1327 username part of this credential is formed by concatenating a 1328 username fragment from each agent, separated by a colon. Each agent 1329 also provides a password, used to compute the message integrity for 1330 requests it receives. The username fragment and password are 1331 exchanged between the peers. In addition to providing security, the 1332 username provides disambiguation and correlation of checks to media 1333 streams. See Appendix B.4 for motivation. 1335 If the initiating agent is a lite implementation, it MUST indicate 1336 this when sending its candidates . 1338 ICE provides for extensibility by allowing an agent to include a 1339 series of tokens that identify ICE extensions as part of the 1340 candidate exchange process. 1342 Once an agent has sent its candidate information, that agent MUST be 1343 prepared to receive both STUN and media packets on each candidate. 1344 As discussed in Section 11.1, media packets can be sent to a 1345 candidate prior to its appearance as the default destination for 1346 media. 1348 4.4. Verifying ICE Support 1350 Certain middleboxes, such as ALGs, may alter the ICE candidate 1351 information that breaks ICE. If the using protocol is vulnerable to 1352 this kind of changes, called ICE mismatch, the responding agent needs 1353 to detect this and signal this back to the initiating agent. The 1354 details on whether this is needed and how it is done is defined by 1355 the usage specifications. One exception to the above is that an 1356 initiating agent would never indicate ICE mismatch. 1358 5. ICE Candidate Processing 1360 Once an agent has gathered its candidates and exchanged candidates 1361 with its peer (Section 4), it will determine its own role. In 1362 addition, full implementations will form CHECK LISTs, and begin 1363 performing connectivity checks with the peer. 1365 5.1. Procedures for Full Implementation 1367 5.1.1. Determining Role 1369 For each session, each agent (Initiating and Responding) takes on a 1370 role. There are two roles -- controlling and controlled. The 1371 controlling agent is responsible for the choice of the final 1372 candidate pairs used for communications. For a full agent, this 1373 means nominating the candidate pairs that can be used by ICE for each 1374 media stream, and for updating the peer with the ICE's selection, 1375 when needed. The controlled agent is told which candidate pairs to 1376 use for each media stream, and does not require updating the peer to 1377 signal this information. The sections below describe in detail the 1378 actual procedures followed by controlling and controlled nodes. 1380 The rules for determining the role and the impact on behavior are as 1381 follows: 1383 Both agents are full: The Initiating Agent which started the ICE 1384 processing MUST take the controlling role, and the other MUST take 1385 the controlled role. Both agents will form check lists, run the 1386 ICE state machines, and generate connectivity checks. The 1387 controlling agent will execute the logic in Section 7.1 to 1388 nominate pairs that will be selected by ICE, and then both agents 1389 end ICE as described in Section 7.1.2. 1391 One agent full, one lite: The full agent MUST take the controlling 1392 role, and the lite agent MUST take the controlled role. The full 1393 agent will form CHECK LISTs, run the ICE state machines, and 1394 generate connectivity checks. That agent will execute the logic 1395 in Section 7.1 to nominate pairs that will be selected by ICE, and 1396 use the logic in Section 7.1.2 to end ICE. The lite 1397 implementation will just listen for connectivity checks, receive 1398 them and respond to them, and then conclude ICE as described in 1399 Section 7.2. For the lite implementation, the state of ICE 1400 processing for each media stream is considered to be Running, and 1401 the state of ICE overall is Running. 1403 Both lite: The Initiating Agent which started the ICE processing 1404 MUST take the controlling role, and the other MUST take the 1405 controlled role. In this case, no connectivity checks are ever 1406 sent. Rather, once the candidates are exchanged, each agent 1407 performs the processing described in Section 7 without 1408 connectivity checks. It is possible that both agents will believe 1409 they are controlled or controlling. In the latter case, the 1410 conflict is resolved through glare detection capabilities in the 1411 signaling protocol enabling the candidate exchange. The state of 1412 ICE processing for each media stream is considered to be Running, 1413 and the state of ICE overall is Running. 1415 Once the roles are determined for a session, they persist througout 1416 the lifetime of the session. The roles can be re-determined as part 1417 of an ICE restart (Section 8), but an ICE agent MUST NOT re-determine 1418 the role as part of an ICE restart unless one or more of the 1419 following criteria is fulfilled: 1421 Full becomes lite: If the controlling agent is full, and switches to 1422 lite, the roles MUST be re-determined if the peer agent is also 1423 full. 1425 Role conflict: If the ICE restart causes a role conflict, the roles 1426 might be re-determined due to the role conflict procedures in 1427 Section 6.3.1.1. 1429 NOTE: There are certain 3PCC scenarios where an ICE restart might 1430 cause a role conflict. 1432 NOTE: The ICE agents needs to inform each other whether they are full 1433 or lite before the roles are determined. The mechanism for that is 1434 signalling protocol specific, and outside the scope of the document. 1436 An ICE agent MUST be prepared that the peer might re-determine the 1437 roles as part of any ICE restart, even if the criteria for doing so 1438 are not fulfilled. This can happen if the peer is compliant with an 1439 older version of this specification. 1441 5.1.2. Forming the Check Lists 1443 There is one CHECK LIST per in-use media stream resulting from the 1444 candidate exchange. To form the CHECK LIST for a media stream, the 1445 agent forms candidate pairs, computes a candidate pair priority, 1446 orders the pairs by priority, prunes them, removes lower-priority 1447 candidates and sets their states. These steps are described in this 1448 section. If a CHECK LIST is updated (e.g, due to detection of peer 1449 reflexive candidates), the agent will re-perform the steps for the 1450 updated CHECK LIST. 1452 5.1.2.1. Check List State 1454 Each CHECK LIST has a state, which captures the state of ICE checks 1455 for the media stream associated with the CHECK LIST. The states are: 1457 Running: In this state, ICE checks are still in progress for this 1458 media stream. Check lists are initially set to the Running state. 1460 Completed: In this state, ICE checks have produced selected pairs 1461 for each component of the media stream. 1463 Failed: In this state, the ICE checks have not completed 1464 successfully for this media stream. 1466 A CHECK LIST with at least one pair that is Waiting is called an 1467 active CHECK LIST, and a CHECK LIST with all pairs Frozen is called a 1468 frozen CHECK LIST. 1470 5.1.2.2. Forming Candidate Pairs 1472 First, the agent takes each of its candidates for a media stream 1473 (called LOCAL CANDIDATES) and pairs them with the candidates it 1474 received from its peer (called REMOTE CANDIDATES) for that media 1475 stream. A local candidate is paired with a remote candidate if and 1476 only if the two candidates have the same component ID and have the 1477 same IP address version. It is possible that some of the local 1478 candidates won't get paired with remote candidates, and some of the 1479 remote candidates won't get paired with local candidates. This can 1480 happen if one agent doesn't include candidates for the all of the 1481 components for a media stream. If this happens, the number of 1482 components for that media stream is effectively reduced, and 1483 considered to be equal to the minimum across both agents of the 1484 maximum component ID provided by each agent across all components for 1485 the media stream. 1487 In the case of RTP, this would happen when one agent provides 1488 candidates for RTCP, and the other does not. As another example, the 1489 initiating agent can multiplex RTP and RTCP on the same port 1490 [RFC5761]. However, since the initiating agent doesn't know if the 1491 peer agent can perform such multiplexing, it includes candidates for 1492 RTP and RTCP on separate ports. If the peer agent can perform such 1493 multiplexing, it would include just a single component for each 1494 candidate -- for the combined RTP/RTCP mux. ICE would end up acting 1495 as if there was just a single component for this candidate. 1497 With IPv6 it is common for a host to have multiple host candidates 1498 for each interface. To keep the amount of resulting candidate pairs 1499 reasonable and to avoid candidate pairs that are highly unlikely to 1500 work, IPv6 link-local addresses [RFC4291] MUST NOT be paired with 1501 other than link-local addresses. 1503 The candidate pairs whose local and remote candidates are both the 1504 default candidates for a particular component is called the default 1505 candidate pair for that component. This is the pair that would be 1506 used to transmit media if both agents had not been ICE aware. 1508 In order to aid understanding, Figure 6 shows the relationships 1509 between several key concepts -- transport addresses, candidates, 1510 candidate pairs, and CHECK LISTs, in addition to indicating the main 1511 properties of candidates and candidate pairs. 1513 +--------------------------------------------+ 1514 | | 1515 | +---------------------+ | 1516 | |+----+ +----+ +----+ | +Type | 1517 | || IP | |Port| |Tran| | +Priority | 1518 | ||Addr| | | | | | +Foundation | 1519 | |+----+ +----+ +----+ | +Component ID | 1520 | | Transport | +Related Address | 1521 | | Addr | | 1522 | +---------------------+ +Base | 1523 | Candidate | 1524 +--------------------------------------------+ 1525 * * 1526 * ************************************* 1527 * * 1528 +-------------------------------+ 1529 .| | 1530 | Local Remote | 1531 | +----+ +----+ +default? | 1532 | |Cand| |Cand| +valid? | 1533 | +----+ +----+ +nominated?| 1534 | +State | 1535 | | 1536 | | 1537 | Candidate Pair | 1538 +-------------------------------+ 1539 * * 1540 * ************ 1541 * * 1542 +------------------+ 1543 | Candidate Pair | 1544 +------------------+ 1545 +------------------+ 1546 | Candidate Pair | 1547 +------------------+ 1548 +------------------+ 1549 | Candidate Pair | 1550 +------------------+ 1552 Check 1553 List 1555 Figure 6: Conceptual Diagram of a Check List 1557 5.1.2.3. Computing Pair Priority and Ordering Pairs 1559 Once the pairs are formed, a candidate pair priority is computed. 1560 Let G be the priority for the candidate provided by the controlling 1561 agent. Let D be the priority for the candidate provided by the 1562 controlled agent. The priority for a pair is computed as: 1564 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 1566 Where G>D?1:0 is an expression whose value is 1 if G is greater than 1567 D, and 0 otherwise. Once the priority is assigned, the agent sorts 1568 the candidate pairs in decreasing order of priority. If two pairs 1569 have identical priority, the ordering amongst them is arbitrary. 1571 5.1.2.4. Pruning the Pairs 1573 This sorted list of candidate pairs is used to determine a sequence 1574 of connectivity checks that will be performed. Each check involves 1575 sending a request from a local candidate to a remote candidate. 1576 Since an agent cannot send requests directly from a reflexive 1577 candidate (server reflexive or peer reflexive), but only from its 1578 base, the agent next goes through the sorted list of candidate pairs. 1579 For each pair where the local candidate is reflexive, the candidate 1580 MUST be replaced by its base. Once this has been done, the agent 1581 MUST prune the list. This is done by removing a pair if its local 1582 and remote candidates are identical to the local and remote 1583 candidates of a pair higher up on the priority list. The result is a 1584 sequence of ordered candidate pairs, called the CHECK LIST for that 1585 media stream. 1587 5.1.2.5. Removing lower-priority Pairs 1589 In order to limit the attacks described in Section 15.4.1, an agent 1590 MUST limit the total number of connectivity checks the agent performs 1591 across all CHECK LISTs to a specific value, and this value MUST be 1592 configurable. A default of 100 is RECOMMENDED. This limit is 1593 enforced by discarding the lower-priority candidate pairs until there 1594 are less than 100. It is RECOMMENDED that a lower value be utilized 1595 when possible, set to the maximum number of plausible checks that 1596 might be seen in an actual deployment configuration. The requirement 1597 for configuration is meant to provide a tool for fixing this value in 1598 the field if, once deployed, it is found to be problematic. 1600 5.1.2.6. Computing Candidate Pair States 1602 Each candidate pair in the CHECK LIST has a foundation and a state. 1603 The foundation is the combination of the foundations of the local and 1604 remote candidates in the pair. The state is assigned once the check 1605 list for each media stream has been computed. There are five 1606 potential values that the state can have: 1608 Waiting: A check has not been sent for this pair, but can be sent as 1609 soon as the pair is chosen based on the criteria for selecting for 1610 which candidate pair a check is to be sent. 1612 In-Progress: A check has been sent for this pair, but the 1613 transaction is in progress. 1615 Succeeded: A check has been sent for this pair, and produced a 1616 successful result. 1618 Failed: A check has been sent for this pair, and failed (a response 1619 to the check was never received, or a failure response was 1620 received). 1622 Frozen: A check for this pair has not been sent, and it can not be 1623 sent until the pair is unfrozen and moved into the Waiting state. 1625 As ICE runs, the pairs will move between states as shown in Figure 7. 1627 +-----------+ 1628 | | 1629 | | 1630 | Frozen | 1631 | | 1632 | | 1633 +-----------+ 1634 | 1635 |unfreeze 1636 | 1637 V 1638 +-----------+ +-----------+ 1639 | | | | 1640 | | perform | | 1641 | Waiting |-------->|In-Progress| 1642 | | | | 1643 | | | | 1644 +-----------+ +-----------+ 1645 / | 1646 // | 1647 // | 1648 // | 1649 / | 1650 // | 1651 failure // |success 1652 // | 1653 / | 1654 // | 1655 // | 1656 // | 1657 V V 1658 +-----------+ +-----------+ 1659 | | | | 1660 | | | | 1661 | Failed | | Succeeded | 1662 | | | | 1663 | | | | 1664 +-----------+ +-----------+ 1666 Figure 7: Pair State FSM 1668 The initial states for each pair in a CHECK LIST are computed by 1669 performing the following sequence of steps: 1671 1. The CHECK LISTs are placed in an ordered list (the order is 1672 determined by each ICE usage), called the CHECK LIST SET. 1674 2. The agent sets all of the candidate pairs in the CHECK LIST SET 1675 to the Frozen state. 1677 3. The agent sets all of the CHECK LISTs in the CHECK LIST SET to 1678 the Running state. 1680 4. The agent examines each CHECK LIST, starting from the first CHECK 1681 LISTs in the CHECK LIST SET, in the following way: 1683 * For each foundation, the candidate pair with the lowest 1684 component ID (in case of multiple such pairs, the pair with 1685 the highest priority) is placed in the Waiting state, unless a 1686 candidate pair associated with the same foundation has already 1687 been put in the Waiting state in one of the other examined 1688 CHECK LISTs. This will ensure that, within the CHECK LIST 1689 SET, only one pair with a given foundation is initially placed 1690 in the Waiting state, while other pairs with the same 1691 foundation remain in the Frozen state. 1693 NOTE: The procedures above are different from RFC5245, where only 1694 candidate pairs in the first CHECK LIST of the CHECK LIST SET were 1695 initially placed in the Waiting state. 1697 The table in Figure 8 illustrates how the initial states of the 1698 candidate pairs in the CHECK LIST SET. 1700 Table legend: 1702 Each row (m1, m2,...) represents a CHECK LIST associated with a media 1703 stream. m1 represents the first CHECK LIST in the CHECK LIST SET. 1705 Each column (f1, f2,...) represents a foundation. Every candidate pair 1706 within a given column share the same foundation. 1708 f-cp represents a candidate pair in the Frozen state. 1710 w-cp represents a candidate pair in the Waiting state. 1712 1. The agent sets all of the pairs in the CHECK LIST SET to the Frozen 1713 state. 1715 f1 f2 f3 f4 f5 1716 ----------------------------- 1717 m1 | f-cp f-cp f-cp 1718 | 1719 m2 | f-cp f-cp f-cp f-cp 1720 | 1721 m3 | f-cp f-cp 1723 2. For each foundation, the candidate pair with the lowest component ID 1724 is placed in the Waiting state, unless a candidate pair associated with 1725 the same foundation has already been put in the Waiting state in one of 1726 the other examined CHECK LISTs in the CHECK LIST SET. 1728 f1 f2 f3 f4 f5 1729 ----------------------------- 1730 m1 | w-cp w-cp w-cp 1731 | 1732 m2 | f-cp f-cp f-cp w-cp 1733 | 1734 m3 | f-cp w-cp 1736 In the first CHECK LIST (m1) the candidate pair for each foundation is 1737 placed in the Waiting state, as no pairs for the same foundations have 1738 yet been placed in the Waiting state. 1740 In the second CHECK LIST (m2) the candidate pair for foundation f4 is 1741 placed in the Waiting state. The candidate pair for foundations f1, f2 1742 and f3 are kept in the Frozen state, as candidate pairs for those 1743 foundations have already been placed in the Waiting state (within check 1744 list m1). 1746 In the third CHECK LIST (m3) the candidate pair for foundation f5 is 1747 placed in the Waiting state. The candidate pair for foundation f1 is 1748 kept in the Frozen state, as a candidate pair for that foundation have 1749 already been placed in the Waiting state (within CHECK LIST m1). 1751 Once each CHECK LIST have been processed, one candidate pair for each 1752 foundation in the CHECK LIST SET has been placed in the Waiting state. 1754 Figure 8: Initial Pair State 1756 5.1.3. ICE State 1758 ICE processing across the CHECK LIST SET has a state associated with 1759 it. This state is set to Running while ICE processing is under way. 1760 The state is set to Completed when ICE processing is complete and set 1761 to Failed if it failed without success. 1763 5.1.4. Scheduling Checks 1765 5.1.4.1. Triggered Check Queue 1767 Once the agent has computed the CHECK LISTs and created the CHECK 1768 LIST SET, as described in Section 5.1.2, the agent will begin 1769 performing connectivity checks (ordinary and triggered). For 1770 triggered connectivity checks, the agent maintains a FIFO queue for 1771 each CHECK LIST, called the TRIGGERED CHECK QUEUE, which contains 1772 candidate pairs for which checks are to be sent at the next available 1773 opportunity. 1775 5.1.4.2. Performing Connectivity Checks 1777 The generation of ordinary and triggered connectivity checks is 1778 govererned by timer Ta. As soon as the initial states for the 1779 candidate pairs in the CHECK LIST SET have been set, a check is 1780 performed for a candidate pair within the first CHECK LIST in the 1781 Running state, following the procedures in Section 6. After that, 1782 whenever Ta fires the next CHECK LIST in the Running state in the 1783 CHECK LIST SET is selected, and a check is performed for a candidate 1784 within that CHECK LIST. After the last CHECK LIST in the Running 1785 state in the CHECK LIST SET has been processed, the first CHECK LIST 1786 is selected again. Etc. 1788 NOTE: When timer Ta fires, and the agent processes a CHECK LIST, if 1789 no check is performed for a pair in the CHECK LIST (based on the 1790 rules below), the agent can immediately select the next CHECK LIST in 1791 the Running state, without waiting for timer Ta to expire again. 1793 Whenever Ta fires, the agent will perform a check for a candidate 1794 pair within the selected CHECK LIST as follows: 1796 o If the TRIGGERED CHECK QUEUE associated with the CHECK LIST 1797 contains one or more candidate pairs, the agent removes the top 1798 pair from the queue, performs a connectivity check on that pair 1799 and puts the candidate pair state to In-Progress; or 1801 o If the TRIGGERED CHECK QUEUE associated with the CHECK LIST is 1802 empty, and if there are one or more candidate pairs in the Waiting 1803 state, the agent selects the highest-priority candidate pair (if 1804 there are multiple pairs with the same priority, the pair with the 1805 lowest component ID is selected) in the Waiting state, performs a 1806 connectivity check on that pair and puts the candidate pair par 1807 state to In-Progress; or 1809 o If there is no candidate pair in the Waiting state, and if there 1810 are one or more pairs in the Frozen state, for each pair in the 1811 Frozen state the the agent checks the foundation associated with 1812 the pair. For a given foundation, if there is no pair (in any 1813 CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress 1814 state, the agent performs a connectivity check on the pair and 1815 puts the pair state to In-Prograss. If, for the same foundation, 1816 there are one or more pairs in the Waiting or In-Progress state, 1817 (in any CHECK LIST in the CHECK LIST SET) the agent does not 1818 perform a connectivity check on the pair. 1820 Once the agent has selected a candidate pair, for which a 1821 connectivity check is to be performed, the agent performs the check 1822 by sending a STUN request from the base associated with the local 1823 candiditate of the pair to the remote candidate of the pair, as 1824 described in Section 6.2.4. 1826 Based on local policy, an agent MAY choose to terminate perfoming the 1827 connectivity checks for one or more checks lists in the CHECK LIST 1828 SET at any time. However, only the controlling agent is allowed to 1829 conclude ICE (Section 7). 1831 To compute the message integrity for the check, the agent uses the 1832 remote username fragment and password learned from the candidate 1833 information obtained from its peer. The local username fragment is 1834 known directly by the agent for its own candidate. 1836 The Initiator performs the ordinary checks on receiving the candidate 1837 information from the Peer (responder) and having formed the CHECK 1838 LISTs. On the other hand the responding agent either performs the 1839 triggered or ordinary checks as described above. 1841 5.2. Lite Implementation Procedures 1843 Lite implementations skips most of the steps in Section 5 except for 1844 verifying the peer's ICE support and determining its role in the ICE 1845 processing. 1847 On determining the role for a lite implementation being the 1848 controlling agent means selecting a candidate pair based on the ones 1849 in the candidate exchange (for IPv4, there is only ever one pair), 1850 and then updating the peer with the new candidate information 1851 reflecting that selection, when needed (it is never needed for an 1852 IPv4-only host). The controlled agent is told which candidate pairs 1853 to use for each media stream, and no further candidate updates are 1854 needed to signal this information. 1856 6. Performing Connectivity Checks 1858 This section describes how connectivity checks are performed. 1860 An ICE agent MUST be compliant to to [RFC5389]. A full 1861 implementation acts both as a STUN client and a STUN server, while a 1862 lite implemenation only acts as a STUN server (as it does not 1863 generate connectivity checks). 1865 6.1. STUN Extensions 1867 ICE extends STUN by defining new attributes: PRIORITY, USE-CANDIDATE, 1868 ICE-CONTROLLED, and ICE-CONTROLLING. The new attributes are formally 1869 defined in Section 16.1. This section describes the usage of the new 1870 attributes. 1872 The new attributes are only applicable to ICE connectivity checks. 1874 6.1.1. PRIORITY 1876 The attribute MUST be set equal to the priority that would be 1877 assigned, based on the algorithm in Section 4.1.2, to a peer 1878 reflexive candidate, should one be learned as a consequence of this 1879 check (see Section 6.2.5.3.1 for how peer reflexive candidates are 1880 learned). This priority value will be computed identically to how 1881 the priority for the local candidate of the pair was computed, except 1882 that the type preference is set to the value for peer reflexive 1883 candidate types. 1885 An ICE agent MUST include the PRIORITY attribute in a Binding 1886 request. 1888 6.1.2. USE-CANDIDATE 1890 The controlling ICE agent includes the USE-CANDIDATE attribute in 1891 order to nominate a candidate pair Section 7.1.1. The controlled ICE 1892 agent MUST NOT include the USE-CANDIDATE attribute in a Binding 1893 request. 1895 6.1.3. ICE-CONTROLLED and ICE-CONTROLLING 1897 The controlling ICE agent MUST include the ICE-CONTROLLED attribute 1898 in a Binding request. The controlled ICE agent MUST include the ICE- 1899 CONTROLLING attribute in a Binding request. 1901 The content of either attribute are used as tie-breaker values when 1902 an ICE role conflict occurs Section 6.3.1.1. 1904 6.2. STUN Client Procedures 1906 6.2.1. Creating Permissions for Relayed Candidates 1908 If the connectivity check is being sent using a relayed local 1909 candidate, the client MUST create a permission first if it has not 1910 already created one previously. It would have created one previously 1911 if it had told the TURN server to create a permission for the given 1912 relayed candidate towards the IP address of the remote candidate. To 1913 create the permission, the agent follows the procedures defined in 1914 [RFC5766]. The permission MUST be created towards the IP address of 1915 the remote candidate. It is RECOMMENDED that the agent defer 1916 creation of a TURN channel until ICE completes, in which case 1917 permissions for connectivity checks are normally created using a 1918 CreatePermission request. Once established, the agent MUST keep the 1919 permission active until ICE concludes. 1921 6.2.2. Forming Credentials 1923 A connectivity check Binding request MUST utilize the STUN short-term 1924 credential mechanism. 1926 The username for the credential is formed by concatenating the 1927 username fragment provided by the peer with the username fragment of 1928 the agent sending the request, separated by a colon (":"). 1930 The password is equal to the password provided by the peer. 1932 For example, consider the case where ICE agent L is the Initiating 1933 agent and ICE agent R is the Responding agent. Agent L included a 1934 username fragment of LFRAG for its candidates and a password of 1935 LPASS. Agent R provided a username fragment of RFRAG and a password 1936 of RPASS. A connectivity check from L to R utilizes the username 1937 RFRAG:LFRAG and a password of RPASS. A connectivity check from R to 1938 L utilizes the username LFRAG:RFRAG and a password of LPASS. The 1939 responses utilize the same usernames and passwords as the requests 1940 (note that the USERNAME attribute is not present in the response). 1942 6.2.3. DiffServ Treatment 1944 If an ICE agent is using Diffserv Codepoint markings [RFC2475] in its 1945 media packets, the agent SHOULD apply those same markings to its 1946 connectivity checks. 1948 6.2.4. Sending the Request 1950 A connectivity check is generated by sending a Binding request from 1951 the base associated with a local candidate to a remote candidate. 1952 [RFC5389] describes how Binding requests are constructed and 1953 generated. 1955 Support for backwards compatibility with RFC 3489 MUST NOT be assumed 1956 when performing connectivity checks. The FINGERPRINT mechanism MUST 1957 be used for connectivity checks. 1959 6.2.5. Processing the Response 1961 This section defines additional procedures for processing Binding 1962 responses specific to ICE connectivity checks. 1964 When a Binding response is received, it is correlated to the 1965 corresponding Binding request using the transaction ID [RFC5389], 1966 which then associates the response with the candidate pair for which 1967 the Binding request was sent. After that, the response is processed 1968 according to the procedures for a role conflict, a failure, or a 1969 success, according to the procedures below. 1971 6.2.5.1. Role Conflict 1973 If the Binding request generates a 487 (Role Conflict) error 1974 response, and if the ICE agent included an ICE-CONTROLLED attribute 1975 in the request, the agent MUST switch to the controlling role. If 1976 the ICE agent included an ICE-CONTROLLING attribute in the request, 1977 the agent MUST switch to the controlled role. 1979 Once the ICE agent has switched its role, the agent MUST add the 1980 candidate pair whose check generated the 487 error response to the 1981 TRIGGERED CHECK QUEUE associated with the CHECK LIST to which the 1982 pair belongs, and set the candidate pair state to Waiting. When the 1983 triggered connectivity check is later performed, the ICE-CONTROLLING/ 1984 ICE-CONTROLLED attribute of the Binding request will indicate the 1985 agent's new role. The ICE agent MUST NOT change the tie-breaker 1986 value. 1988 NOTE: A role switch requires an ICE agent to recompute pair 1989 priorities (Section 5.1.2.3), since the priority values depend on the 1990 role. 1992 NOTE: A role switch will also impact whether the ICE agent is 1993 responsible for nominating candidate pairs, and whether the agent is 1994 responsible for initiating the exchange of the updated candidate 1995 information with the peer once ICE is concluded. 1997 6.2.5.2. Failure 1999 This section describes cases when the candidate pair state is set to 2000 Failed. 2002 NOTE: When the ICE agent sets the candidate pair state to Failed as a 2003 result a connectivity check error, the agent does not change the 2004 states of other candidate pairs with the same foundation. 2006 6.2.5.2.1. Non-Symmetric Transport Addresses 2008 The ICE agent MUST check that the source and destination transport 2009 addresses in the Binding request and response are symmetric. I.e., 2010 the source IP address and port of the response MUST be equal the 2011 destination IP address and port to which the Binding request was 2012 sent, and that the destination IP address and port of the response 2013 MUST be equal to the source IP address and port from which the 2014 Binding request was sent. If the addresses are not symmetric, the 2015 ICE agent MUST set the candidate pair state to Failed. 2017 6.2.5.2.2. ICMP Error 2019 An ICE agent MAY support processing of ICMP errors for connectivity 2020 checks. If the agent supports processing of ICMP errors, and if a 2021 Binging request generates an ICMP error, the agent SHOULD set the 2022 state of the candidate pair to Failed. 2024 6.2.5.2.3. Unrecoverable STUN Response 2026 If the Binding request generates a STUN error response that is 2027 unrecoverable [RFC5389]) or times out, the ICE agent SHOULD set the 2028 candidate pair state to Failed. 2030 6.2.5.3. Success 2032 A connectivity check is considered a success if each of the following 2033 criteria is true: 2035 o The Binding request generated a success response; and 2037 o The source and destination transport addresses in the Binding 2038 request and response are symmetric. 2040 6.2.5.3.1. Discovering Peer Reflexive Candidates 2042 The ICE agent MUST check the mapped address from the STUN response. 2043 If the transport address does not match any of the local candidates 2044 that the agent knows about, the mapped address represents a new 2045 candidate: a peer reflexive candidate. Like other candidates, a peer 2046 reflexive candidate has a type, base, priority, and foundation. They 2047 are computed as follows: 2049 o The type is equal to peer reflexive. 2051 o The base is set equal to the local candidate of the candidate pair 2052 from which the Binding request was sent. 2054 o The priority is set equal to the value of the PRIORITY attribute 2055 in the Binding request. 2057 o The foundation is set as described in Section 4.1.1.3. 2059 The peer reflexive candidate is then added to the list of local 2060 candidates for the media stream. The username fragment and password 2061 are the same as for all other local candidates for that media stream. 2063 The ICE agent does not need to pair the peer reflexive candidate with 2064 remote candidates, as a valid candiate pair will be created due to 2065 the procedures in Section 6.2.5.3.2. If an ICE agent wishes to pair 2066 the peer reflexive candidate with other remote candidates besides the 2067 one in the valid pair that will be generated, the agent MAY provide 2068 updated candidate information to the peer that includes the peer 2069 reflexive candidate. This will cause the peer reflexive candidate to 2070 be paired with all other remote candidates. 2072 6.2.5.3.2. Constructing a Valid Pair 2074 The ICE agent constructs a candidate pair whose local candidate 2075 equals the mapped address of the response, and whose remote candidate 2076 equals the destination address to which the request was sent. This 2077 is called a valid pair. 2079 The valid pair may equal the pair that generated the connectivity 2080 check, or it may equal a different pair in a CHECK LIST (sometimes in 2081 a different CHECK LIST than the one to which the pair that generated 2082 the connectivity checks), or it may be a pair not currently in any 2083 CHECK LIST. 2085 The ICE agent maintains a separate list, called the VALID LIST, for 2086 each check list in the CHECK LIST SET. The VALID LIST will contain 2087 valid pairs. Initially each VALID LIST is empty. 2089 Each valid pair within the VALID LIST has a flag, called the 2090 Nominated Flag. When a valid pair is added to a VALID LIST, the flag 2091 value is set to 'false'. 2093 The valid pair will be added to a VALID LIST as follows: 2095 1. If the valid pair equals the pair that generated the check, the 2096 pair is added to the VALID LIST associated with the CHECK LIST to 2097 which the pair belongs; or 2099 2. If the valid pair equals another pair in a CHECK LIST, that pair 2100 is added to the VALID LIST associated with the CHECK LIST of that 2101 pair. The pair that generated the check is not added to a VALID 2102 LIST; or 2104 3. If the valid pair is not in any CHECK LIST, the agent computes 2105 the priority for the pair based on the priority of each 2106 candidate, using the algorithm in Section 5.1.2. The priority of 2107 the local candidate depends on its type. Unless the type is peer 2108 reflexive, the priority is equal to the priority signaled for 2109 that candidate in the candidate exchange. If the type is peer 2110 reflexive, it is equal to the PRIORITY attribute the agent placed 2111 in the Binding request that just completed. The priority of the 2112 remote candidate is taken from the candidate information of the 2113 peer. If the candidate does not appear there, then the check 2114 must have been a triggered check to a new remote candidate. In 2115 that case, the priority is taken as the value of the PRIORITY 2116 attribute in the Binding request that triggered the check that 2117 just completed. The pair is then added to the VALID LIST. 2119 NOTE: It will be very common that the valid pair will not be in any 2120 CHECK LIST. Recall that the CHECK LIST has pairs whose local 2121 candidates are never reflexive; those pairs had their local 2122 candidates converted to the base of the reflexive candidates, and 2123 then pruned if they were redundant. When the response to the Binding 2124 request arrives, the mapped address will be reflexive if there is a 2125 NAT between the two. In that case, the valid pair will have a local 2126 candidate that doesn't match any of the pairs in the CHECK LIST. 2128 6.2.5.3.3. Updating Candidate Pair States 2130 The ICE agent sets the state of both the candidate pair that 2131 generated the check, and the constructed valid pair, to Succeeded. 2132 Note that the pair which generated the check may be different than 2133 the valid pair constructed in Section 6.2.5.3.2. 2135 The success of the connectivity check might also cause the state of 2136 other candidate pairs to change. The ICE agent MUST set the states 2137 for all other Frozen candidate pairs (in each CHECK LIST in the CHECK 2138 LIST SET) with the same foundation to Waiting. 2140 NOTE: Within a given CHECK LIST, candidate pairs with the same 2141 foundations will typically have different component ID values. 2143 6.2.5.3.4. Updating the Nominated Flag 2145 If the ICE agent was a controlling agent, and the agent had included 2146 a USE-CANDIDATE attribute in the Binding request, the valid pair 2147 generated from that check has its nominated flag value set to true. 2148 This flag indicates that this valid pair SHOULD be used for media, 2149 unless the sending agent detects that the candidate pair does not 2150 work. This concludes the ICE processing for this media stream or all 2151 media streams; see Section 7. 2153 If the ICE agent is the controlled agent, the response may be the 2154 result of a triggered check that was sent in response to a request 2155 that itself had the USE-CANDIDATE attribute. This case is described 2156 in Section 6.3.1.5, and may now result in setting the nominated flag 2157 for the pair learned from the original request. 2159 An ICE agent MUST NOT select a candidate pair until it has sent a 2160 Binding request, and received the corresponding Binding response, 2161 associated with the candidate pair. 2163 6.2.5.4. Check List State Updates 2165 Regardless of whether a connectivity check was successful or failed, 2166 the completion of the check may require updating of CHECK LIST 2167 states. For each CHECK LIST in the CHECK LIST SET, if all of the 2168 candidate pairs are in either Failed or Succeeded state, and if there 2169 is not a valid pair in the VALID LIST for each component of the media 2170 stream associated with the CHECK LIST, the state of the CHECK LIST is 2171 set to Failed. If there is a valid pair for each component in the 2172 VALID LIST, the state of the check list is set to Succeeded. 2174 6.3. STUN Server Procedures 2176 An agent MUST be prepared to receive a Binding request on the base of 2177 each candidate it included in its most recent candidate exchange. 2178 This requirement holds even if the peer is a lite implementation. 2180 The agent MUST use the short-term credential mechanism (i.e., the 2181 MESSAGE-INTEGRITY attribute) to authenticate the request and perform 2182 a message integrity check. Likewise, the short-term credential 2183 mechanism MUST be used for the response. The agent MUST consider the 2184 username to be valid if it consists of two values separated by a 2185 colon, where the first value is equal to the username fragment 2186 generated by the agent in an candidate exchange for a session in- 2187 progress. It is possible (and in fact very likely) that the 2188 initiating agent will receive a Binding request prior to receiving 2189 the candidates from its peer. If this happens, the agent MUST 2190 immediately generate a response (including computation of the mapped 2191 address as described in Section 6.3.1.2). The agent has sufficient 2192 information at this point to generate the response; the password from 2193 the peer is not required. Once the answer is received, it MUST 2194 proceed with the remaining steps required, namely, Section 6.3.1.3, 2195 Section 6.3.1.4, and Section 6.3.1.5 for full implementations. In 2196 cases where multiple STUN requests are received before the answer, 2197 this may cause several pairs to be queued up in the TRIGGERED CHECK 2198 QUEUE. 2200 An agent MUST NOT utilize the ALTERNATE-SERVER mechanism, and MUST 2201 NOT support the backwards-compatibility mechanisms to RFC 3489. It 2202 MUST utilize the FINGERPRINT mechanism. 2204 If the agent is using Diffserv Codepoint markings [RFC2475] in its 2205 media packets, it SHOULD apply those same markings to its responses 2206 to Binding requests. The same would apply to any layer 2 markings 2207 the endpoint might be applying to media packets. 2209 6.3.1. Additional Procedures for Full Implementations 2211 This subsection defines the additional server procedures applicable 2212 to full implementations. 2214 6.3.1.1. Detecting and Repairing Role Conflicts 2216 Normally, the rules for selection of a role in Section 5.1.1 will 2217 result in each agent selecting a different role -- one controlling 2218 and one controlled. However, in unusual call flows, typically 2219 utilizing third party call control, it is possible for both agents to 2220 select the same role. This section describes procedures for checking 2221 for this case and repairing it. These procedures apply only to 2222 usages of ICE that require conflict resolution. The usage document 2223 MUST specify whether this mechanism is needed. 2225 An agent MUST examine the Binding request for either the ICE- 2226 CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these 2227 procedures: 2229 o If neither ICE-CONTROLLING nor ICE-CONTROLLED is present in the 2230 request, the peer agent may have implemented a previous version of 2231 this specification. There may be a conflict, but it cannot be 2232 detected. 2234 o If the agent is in the controlling role, and the ICE-CONTROLLING 2235 attribute is present in the request: 2237 * If the agent's tie-breaker value is larger than or equal to the 2238 contents of the ICE-CONTROLLING attribute, the agent generates 2239 a Binding error response and includes an ERROR-CODE attribute 2240 with a value of 487 (Role Conflict) but retains its role. 2242 * If the agent's tie-breaker value is less than the contents of 2243 the ICE-CONTROLLING attribute, the agent switches to the 2244 controlled role. 2246 o If the agent is in the controlled role, and the ICE-CONTROLLED 2247 attribute is present in the request: 2249 * If the agent's tie-breaker value is larger than or equal to the 2250 contents of the ICE-CONTROLLED attribute, the agent switches to 2251 the controlling role. 2253 * If the agent's tie-breaker value is less than the contents of 2254 the ICE-CONTROLLED attribute, the agent generates a Binding 2255 error response and includes an ERROR-CODE attribute with a 2256 value of 487 (Role Conflict) but retains its role. 2258 o If the agent is in the controlled role and the ICE-CONTROLLING 2259 attribute was present in the request, or the agent was in the 2260 controlling role and the ICE-CONTROLLED attribute was present in 2261 the request, there is no conflict. 2263 A change in roles will require an agent to recompute pair priorities 2264 (Section 5.1.2.3), since those priorities are a function of 2265 controlling and controlled roles. The change in role will also 2266 impact whether the agent is responsible for selecting nominated pairs 2267 and initiating exchange with updated candidate information upon 2268 conclusion of ICE. 2270 The remaining sections in Section 6.3.1 are followed if the server 2271 generated a successful response to the Binding request, even if the 2272 agent changed roles. 2274 6.3.1.2. Computing Mapped Address 2276 For requests being received on a relayed candidate, the source 2277 transport address used for STUN processing (namely, generation of the 2278 XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the 2279 TURN server. That source transport address will be present in the 2280 XOR-PEER-ADDRESS attribute of a Data Indication message, if the 2281 Binding request was delivered through a Data Indication. If the 2282 Binding request was delivered through a ChannelData message, the 2283 source transport address is the one that was bound to the channel. 2285 6.3.1.3. Learning Peer Reflexive Candidates 2287 If the source transport address of the request does not match any 2288 existing remote candidates, it represents a new peer reflexive remote 2289 candidate. This candidate is constructed as follows: 2291 o The priority of the candidate is set to the PRIORITY attribute 2292 from the request. 2294 o The type of the candidate is set to peer reflexive. 2296 o The foundation of the candidate is set to an arbitrary value, 2297 different from the foundation for all other remote candidates. If 2298 any subsequent candidate exchanges contain this peer reflexive 2299 candidate, it will signal the actual foundation for the candidate. 2301 o The component ID of this candidate is set to the component ID for 2302 the local candidate to which the request was sent. 2304 This candidate is added to the list of remote candidates. However, 2305 the agent does not pair this candidate with any local candidates. 2307 6.3.1.4. Triggered Checks 2309 Next, the agent constructs a pair whose local candidate is equal to 2310 the transport address on which the STUN request was received, and a 2311 remote candidate equal to the source transport address where the 2312 request came from (which may be the peer reflexive remote candidate 2313 that was just learned). The local candidate will either be a host 2314 candidate (for cases where the request was not received through a 2315 relay) or a relayed candidate (for cases where it is received through 2316 a relay). The local candidate can never be a server reflexive 2317 candidate. Since both candidates are known to the agent, it can 2318 obtain their priorities and compute the candidate pair priority. 2319 This pair is then looked up in the CHECK LIST. There can be one of 2320 several outcomes: 2322 o If the pair is already on the CHECK LIST: 2324 * If the state of that pair is Waiting or Frozen, a check for 2325 that pair is enqueued into the TRIGGERED CHECK QUEUE if not 2326 already present. 2328 * If the state of that pair is In-Progress, the agent cancels the 2329 in-progress transaction. Cancellation means that the agent 2330 will not retransmit the request, will not treat the lack of 2331 response to be a failure, but will wait the duration of the 2332 transaction timeout for a response. In addition, the agent 2333 MUST create a new connectivity check for that pair 2334 (representing a new STUN Binding request transaction) by 2335 enqueueing the pair in the TRIGGERED CHECK QUEUE. The state of 2336 the pair is then changed to Waiting. 2338 * If the state of the pair is Failed, it is changed to Waiting 2339 and the agent MUST create a new connectivity check for that 2340 pair (representing a new STUN Binding request transaction), by 2341 enqueueing the pair in the TRIGGERED CHECK QUEUE. 2343 * If the state of that pair is Succeeded, nothing further is 2344 done. 2346 These steps are done to facilitate rapid completion of ICE when both 2347 agents are behind NAT. 2349 o If the pair is not already on the CHECK LIST: 2351 * The pair is inserted into the CHECK LIST based on its priority. 2353 * Its state is set to Waiting. 2355 * The pair is enqueued into the TRIGGERED CHECK QUEUE. 2357 When a triggered check is to be sent, it is constructed and processed 2358 as described in Section 6.2.4. These procedures require the agent to 2359 know the transport address, username fragment, and password for the 2360 peer. The username fragment for the remote candidate is equal to the 2361 part after the colon of the USERNAME in the Binding request that was 2362 just received. Using that username fragment, the agent can check the 2363 candidates received from its peer (there may be more than one in 2364 cases of forking), and find this username fragment. The 2365 corresponding password is then selected. 2367 6.3.1.5. Updating the Nominated Flag 2369 If the Binding request received by the agent had the USE-CANDIDATE 2370 attribute set, and the agent is in the controlled role, the agent 2371 looks at the state of the pair computed in Section 6.3.1.4: 2373 o If the state of this pair is Succeeded, it means that the check 2374 generated by this pair produced a successful response. This would 2375 have caused the agent to construct a valid pair when that success 2376 response was received (see Section 6.2.5.3.2). The agent now sets 2377 the nominated flag value of the valid pair to true. This may end 2378 ICE processing for this media stream; see Section 7. 2380 o If the state of this pair is In-Progress, and if its check 2381 produces a successful result, the resulting valid pair has its 2382 nominated flag set when the response arrives. This may end ICE 2383 processing for this media stream when it arrives; see Section 7. 2385 6.3.2. Additional Procedures for Lite Implementations 2387 If the check that was just received contained a USE-CANDIDATE 2388 attribute, the agent constructs a candidate pair whose local 2389 candidate is equal to the transport address on which the request was 2390 received, and whose remote candidate is equal to the source transport 2391 address of the request that was received. This candidate pair is 2392 assigned an arbitrary priority, and placed into a list of valid 2393 candidates called the VALID LIST. The agent sets the nominated flag 2394 for that pair to true. ICE processing is considered complete for a 2395 media stream if the VALID LIST contains a candidate pair for each 2396 component. 2398 7. Concluding ICE Processing 2400 This section describes how an agent completes ICE. 2402 7.1. Procedures for Full Implementations 2404 Concluding ICE involves nominating pairs by the controlling agent and 2405 updating of state machinery. 2407 7.1.1. Nominating Pairs 2409 Prior to nominating, the agent let connectivity quecks continue until 2410 some stopping criterion is met. After that, based on an evaluation 2411 criterion, the agent selects a pair among the valid pairs in the 2412 VALID LIST for nomination. 2414 Once the controlling agent has selected a valid pair for nomination, 2415 it repeats the connectivity check that produced this valid pair (by 2416 enqueueing the pair that generated the check into the TRIGGERED CHECK 2417 QUEUE), this time with the USE-CANDIDATE attribute. The connectivity 2418 check should succeed (since the previous did), causing the nominated 2419 flag value of that and only that pair to be set to true. 2421 Eventually, there will be only a single nominated pair in the VALID 2422 LIST for each component. Once the state of the CHECK LIST is set to 2423 Completed, that exact pair is selected by ICE for sending and 2424 receiving media for that component. 2426 The criterion details for stopping the connectivity checks and for 2427 selecting a pair for nomiation, are outside the scope of this 2428 specification. They are a matter of local optimization. The only 2429 requirement is that the agent MUST eventually pick one and only one 2430 candidate pair and generate a check for that pair with the USE- 2431 CANDIDATE attribute present. 2433 The controlled agent SHOULD select the candidate pair nominated by 2434 the controlling agent if the controlled agent is receiving Binding 2435 responses associated with that candidate pair. Before the agent has 2436 received Binding responses associated with the candidate pair, the 2437 agent can send media on any candidate for which it has received 2438 Binding responses. 2440 If more than one candidate pair is nominated by the controlling 2441 agent, the controlled agent SHOULD select the candidate pair with the 2442 highest priority. 2444 NOTE: A controlling agent that does not support this specification 2445 (i.e. it is implemented according to RFC 5245) might nominate more 2446 than one candidate pair. This was referred to as aggressive 2447 nomination in RFC 5245. The usage of the 'ice2' ice option by 2448 endpoints supporting this specifcation should prevent such 2449 controlling agents from using aggressive nomination. 2451 7.1.2. Updating States 2453 For both controlling and controlled agents, the state of ICE 2454 processing depends on the presence of nominated candidate pairs in 2455 the VALID LIST and on the state of the CHECK LIST. Note that, at any 2456 time, more than one of the following cases can apply: 2458 o If there are no nominated pairs in the VALID LIST for a media 2459 stream and the state of the CHECK LIST is Running, ICE processing 2460 continues. 2462 o If there is at least one nominated pair in the VALID LIST for a 2463 media stream and the state of the CHECK LIST is Running: 2465 * The agent MUST remove all Waiting and Frozen pairs in the CHECK 2466 LIST and TRIGGERED CHECK QUEUE for the same component as the 2467 nominated pairs for that media stream. 2469 * If an In-Progress pair in the CHECK LIST is for the same 2470 component as a nominated pair, the agent SHOULD cease 2471 retransmissions for its check if its pair priority is lower 2472 than the lowest-priority nominated pair for that component. 2474 o Once there is at least one nominated pair in the VALID LIST for 2475 every component of at least one media stream and the state of the 2476 CHECK LIST is Running: 2478 * The agent MUST change the state of processing for its CHECK 2479 LIST for that media stream to Completed. 2481 * The agent MUST continue to respond to any checks it may still 2482 receive for that media stream, and MUST perform triggered 2483 checks if required by the processing of Section 6.3. 2485 * The agent MUST continue retransmitting any In-Progress checks 2486 for that CHECK LIST. 2488 * The agent MAY begin transmitting media for this media stream as 2489 described in Section 11.1. 2491 o Once the state of each CHECK LIST is Completed: 2493 * The agent sets the state of ICE processing overall to 2494 Completed. 2496 o If the state of the CHECK LIST is Failed, ICE has not been able to 2497 complete for this media stream. The correct behavior depends on 2498 the state of the CHECK LISTs for other media streams: 2500 * If all CHECK LISTs are Failed, ICE processing overall is 2501 considered to be in the Failed state, and the agent SHOULD 2502 consider the session a failure, SHOULD NOT restart ICE, and the 2503 controlling agent SHOULD terminate the entire session. 2505 * If at least one of the CHECK LISTs for other media streams is 2506 Completed, the controlling agent SHOULD remove the failed media 2507 stream from the session while sending updated candidate list to 2508 its peer. 2510 * If none of the CHECK LISTs for other media streams are 2511 Completed, but at least one is Running, the agent SHOULD let 2512 ICE continue. 2514 7.2. Procedures for Lite Implementations 2516 Concluding ICE for a lite implementation is relatively 2517 straightforward. There are two cases to consider: 2519 The implementation is lite, and its peer is full. 2521 The implementation is lite, and its peer is lite. 2523 The effect of ICE concluding is that the agent can free any allocated 2524 host candidates that were not utilized by ICE, as described in 2525 Section 7.3. 2527 7.2.1. Peer Is Full 2529 In this case, the agent will receive connectivity checks from its 2530 peer. When an agent has received a connectivity check that includes 2531 the USE-CANDIDATE attribute for each component of a media stream, the 2532 state of ICE processing for that media stream moves from Running to 2533 Completed. When the state of ICE processing for all media streams is 2534 Completed, the state of ICE processing overall is Completed. 2536 The lite implementation will never itself determine that ICE 2537 processing has failed for a media stream; rather, the full peer will 2538 make that determination and then remove or restart the failed media 2539 stream as part of subsequent candidate exchange process. 2541 7.2.2. Peer Is Lite 2543 Once the candidate exchange has completed, both agents examine their 2544 candidates and those of its peer. For each media stream, each agent 2545 pairs up its own candidates with the candidates of its peer for that 2546 media stream. Two candidates are paired up when they are for the 2547 same component, utilize the same transport protocol (UDP in this 2548 specification), and are from the same IP address family (IPv4 or 2549 IPv6). 2551 o If there is a single pair per component, that pair is added to the 2552 VALID LIST. If all of the components for a media stream had one 2553 pair, the state of ICE processing for that media stream is set to 2554 Completed. If all media streams are Completed, the state of ICE 2555 processing is set to Completed overall. This will always be the 2556 case for implementations that are IPv4-only. 2558 o If there is more than one pair per component: 2560 * The agent MUST select a pair based on local policy. Since this 2561 case only arises for IPv6, it is RECOMMENDED that an agent 2562 follow the procedures of RFC 6724 [RFC6724] to select a single 2563 pair. 2565 * The agent adds the selected pair for each component to the 2566 valid list. As described in Section 11.1, this will permit 2567 media to begin flowing. However, it is possible (and in fact 2568 likely) that both agents have chosen different pairs. 2570 * To reconcile this, the controlling agent MUST send updated 2571 candidate list which will include the remote-candidates 2572 attribute. 2574 * The agent MUST NOT update the state of ICE processing until 2575 after the candidate exchange completes. Then the controlling 2576 agent MUST change the state of ICE processing to Completed for 2577 all media streams, and the state of ICE processing overall to 2578 Completed. 2580 7.3. Freeing Candidates 2582 7.3.1. Full Implementation Procedures 2584 The procedures in Section 7 require that an agent continue to listen 2585 for STUN requests and continue to generate triggered checks for a 2586 media stream, even once processing for that stream completes. The 2587 rules in this section describe when it is safe for an agent to cease 2588 sending or receiving checks on a candidate that was not selected by 2589 ICE, and then free the candidate. 2591 Once ICE processing has reached the Completed state for all peers for 2592 media streams using those candidates, the agent SHOULD wait an 2593 additional three seconds, and then it MAY cease responding to checks 2594 or generating triggered checks on that candidate. It MAY free the 2595 candidate at that time. Freeing of server reflexive candidates is 2596 never explicit; it happens by lack of a keepalive. The three-second 2597 delay handles cases when aggressive nomination is used, and the 2598 selected pairs can quickly change after ICE has completed. 2600 7.3.2. Lite Implementation Procedures 2602 A lite implementation MAY free candidates not selected by ICE as soon 2603 as ICE processing has reached the Completed state for all peers for 2604 all media streams using those candidates. 2606 8. ICE Restarts 2608 An agent MAY restart ICE processing for an existing media stream. An 2609 ICE restart will cause all previous states, excluding the roles of 2610 the agents, of ICE processing to be flushed and checks to start anew. 2611 The only difference between an ICE restart and a brand new media 2612 session is that during the restart media can continue to be sent to 2613 the previously validated pair, and that a new media session always 2614 requires the roles to be determined. 2616 An agent MUST restart ICE for a media stream if: 2618 o The candidate(s) is being generated for the purposes of changing 2619 the target of the media stream. In other words, if an agent wants 2620 to generate an updated candidate information that, had ICE not 2621 been in use, would result in a new value for the destination of a 2622 media component. 2624 o An agent is changing its implementation level. This typically 2625 only happens in third party call control use cases, where the 2626 entity performing the signaling is not the entity receiving the 2627 media, and it has changed the target of media mid-session to 2628 another entity that has a different ICE implementation. 2630 To restart ICE, an agent MUST change both the password and the user 2631 name fragment for the media stream when exchanging the candidates. 2632 The new candidate set MAY include some, none, or all of the previous 2633 candidates for that stream and MAY include a totally new set of 2634 candidates. 2636 As described in Section 5.1.1, ICE agents MUST NOT re-determine the 2637 roles as part as an ICE restart, unless certain criteria that require 2638 the roles to be re-determined is fulfilled. 2640 9. ICE Option 2642 This section defines a new ICE option, 'ice2'. The ICE option 2643 indicates that the ICE agent that includes it (in an ice-options 2644 attribute) is compliant to this specification. For example, the ICE 2645 agent will not use the aggressive nomination procedure defined in 2646 [RFC5245]. 2648 An ICE agent compliant to this specification MUST inform the peer 2649 about the compliance using the 'ice2' ICE option. 2651 NOTE: The encoding of the 'ice2' ICE option, and the message(s) used 2652 to carry it to the peer, are protocol specific. The encoding for the 2653 Session Description Protocol (SDP) [RFC4566] is defined in 2654 [I-D.ietf-mmusic-ice-sip-sdp]. 2656 10. Keepalives 2658 All endpoints MUST send keepalives for each media session. These 2659 keepalives serve the purpose of keeping NAT bindings alive for the 2660 media session. The keepalives SHOULD be sent using a format that is 2661 supported by its peer. ICE endpoints allow for STUN-based keepalives 2662 for UDP streams, and as such, STUN keepalives MUST be used when an 2663 agent is a full ICE implementation and is communicating with a peer 2664 that supports ICE (lite or full). 2666 If there has been no packet sent on the candidate pair ICE is using 2667 for a media component for Tr seconds (where packets include those 2668 defined for the component (RTP or RTCP) and previous keepalives), an 2669 agent MUST generate a keepalive on that pair. ICE endpoints SHOULD 2670 use a Tr value of 15 seconds, but MAY use another value, e.g. based 2671 on configuration or network/NAT characteristics. For example, if an 2672 agent has a dynamic way to discover the binding lifetimes of the 2673 intervening NATs, it can use that value to determine Tr. 2674 Administrators deploying ICE in more controlled networking 2675 environments SHOULD set Tr to the longest duration possible in their 2676 environment. ICE endpoints MUST NOT use a Tr value smaller than 15 2677 seconds. 2679 When STUN is being used for keepalives, a STUN Binding Indication is 2680 used [RFC5389]. The Indication MUST NOT utilize any authentication 2681 mechanism. It SHOULD contain the FINGERPRINT attribute to aid in 2682 demultiplexing, but SHOULD NOT contain any other attributes. It is 2683 used solely to keep the NAT bindings alive. The Binding Indication 2684 is sent using the same local and remote candidates that are being 2685 used for media. Though Binding Indications are used for keepalives, 2686 an agent MUST be prepared to receive a connectivity check as well. 2687 If a connectivity check is received, a response is generated as 2688 discussed in [RFC5389], but there is no impact on ICE processing 2689 otherwise. 2691 An agent MUST begin the keepalive processing once ICE has selected 2692 candidates for usage with media, or media begins to flow, whichever 2693 happens first. Keepalives end once the session terminates or the 2694 media stream is removed. 2696 11. Media Handling 2698 11.1. Sending Media 2700 Procedures for sending media differ for full and lite 2701 implementations. 2703 11.1.1. Procedures for Full Implementations 2705 Agents always send media using a candidate pair, using candidate 2706 pairs in the VALID LIST. Once a candidate pair has been selected 2707 only that candidate pair (referred to as selected pair) is used for 2708 sending media. An agent will send media to the remote candidate 2709 (i.e., setting the destination address and port of the packet equal 2710 to that remote candidate), and will send it from the base associated 2711 with the candidate pair used for sending media. In case of a relayed 2712 candidate, media is sent from the agent and forwarded through the 2713 base (located in the TURN server), using the procedures defined in 2714 [RFC5766]. 2716 If the local candidate is a relayed candidate, it is RECOMMENDED that 2717 an agent creates a channel on the TURN server towards the remote 2718 candidate. This is done using the procedures for channel creation as 2719 defined in Section 11 of [RFC5766]. 2721 The selected pair for a component of a media stream is: 2723 o empty if the state of the CHECK LIST for that media stream is 2724 Running, and there is no previous selected pair for that component 2725 due to an ICE restart 2727 o equal to the previous selected pair for a component of a media 2728 stream if the state of the CHECK LIST for that media stream is 2729 Running, and there was a previous selected pair for that component 2730 due to an ICE restart 2732 Unless an agent is able to produce a selected pair for all components 2733 associated with a media stream, the agent MUST NOT continue sending 2734 media for any component associated with that media stream. 2736 11.1.2. Procedures for Lite Implementations 2738 A lite implementation MUST NOT send media until it has a VALID LIST 2739 that contains a candidate pair for each component of that media 2740 stream. Once that happens, the agent MAY begin sending media 2741 packets. To do that, it sends media to the remote candidate in the 2742 pair (setting the destination address and port of the packet equal to 2743 that remote candidate), and will send it from the base associated 2744 with the candidate pair used for sending media. In case of a relayed 2745 candidate, media is sent from the agent and forwarded through the 2746 base (located in the TURN server), using the procedures defined in 2747 [RFC5766]. 2749 11.1.3. Procedures for All Implementations 2751 ICE has interactions with jitter buffer adaptation mechanisms. An 2752 RTP stream can begin using one candidate, and switch to another one, 2753 though this happens rarely with ICE. The newer candidate may result 2754 in RTP packets taking a different path through the network -- one 2755 with different delay characteristics. As discussed below, agents are 2756 encouraged to re-adjust jitter buffers when there are changes in 2757 source or destination address of media packets. Furthermore, many 2758 audio codecs use the marker bit to signal the beginning of a 2759 talkspurt, for the purposes of jitter buffer adaptation. For such 2760 codecs, it is RECOMMENDED that the sender set the marker bit 2762 [RFC3550] when an agent switches transmission of media from one 2763 candidate pair to another. 2765 11.2. Receiving Media 2767 Even though ICE agents are only allowed to send media using valid 2768 candidate pairs (and, once a candidate pair has been selected, only 2769 on the selected pair) ICE implementations SHOULD by default be 2770 prepared to receive media on any of the candidates provided in the 2771 most recent candidate exchange with the peer. Specific ICE usages 2772 MAY define rules that differs from this, e.g., by defining that media 2773 must not be sent until selected pairs have been procduced for each 2774 component associated with that media. 2776 It is RECOMMENDED that, when an agent receives an RTP packet with a 2777 new source or destination IP address for a particular media stream, 2778 that the agent re-adjust its jitter buffers. 2780 RFC 3550 [RFC3550] describes an algorithm in Section 8.2 for 2781 detecting synchronization source (SSRC) collisions and loops. These 2782 algorithms are based, in part, on seeing different source transport 2783 addresses with the same SSRC. However, when ICE is used, such 2784 changes will sometimes occur as the media streams switch between 2785 candidates. An agent will be able to determine that a media stream 2786 is from the same peer as a consequence of the STUN exchange that 2787 proceeds media transmission. Thus, if there is a change in source 2788 transport address, but the media packets come from the same peer 2789 agent, this SHOULD NOT be treated as an SSRC collision. 2791 12. Extensibility Considerations 2793 This specification makes very specific choices about how both agents 2794 in a session coordinate to arrive at the set of candidate pairs that 2795 are selected for media. It is anticipated that future specifications 2796 will want to alter these algorithms, whether they are simple changes 2797 like timer tweaks or larger changes like a revamp of the priority 2798 algorithm. When such a change is made, providing interoperability 2799 between the two agents in a session is critical. 2801 First, ICE provides the ice-options attribute. Each extension or 2802 change to ICE is associated with a token. When an agent supporting 2803 such an extension or change triggers candidate exchange, it MUST 2804 include the token for that extension in this attribute. This allows 2805 each side to know what the other side is doing. This attribute MUST 2806 NOT be present if the agent doesn't support any ICE extensions or 2807 changes. 2809 One of the complications in achieving interoperability is that ICE 2810 relies on a distributed algorithm running on both agents to converge 2811 on an agreed set of candidate pairs. If the two agents run different 2812 algorithms, it can be difficult to guarantee convergence on the same 2813 candidate pairs. The regular nomination procedure described in 2814 Section 7 eliminates some of the tight coordination by delegating the 2815 selection algorithm completely to the controlling agent. 2816 Consequently, when a controlling agent is communicating with a peer 2817 that supports options it doesn't know about, the agent MUST run a 2818 regular nomination algorithm. When regular nomination is used, ICE 2819 will converge perfectly even when both agents use different pair 2820 prioritization algorithms. One of the keys to such convergence is 2821 triggered checks, which ensure that the nominated pair is validated 2822 by both agents. Consequently, any future ICE enhancements MUST 2823 preserve triggered checks. 2825 ICE is also extensible to other media streams beyond RTP, and for 2826 transport protocols beyond UDP. Extensions to ICE for non-RTP media 2827 streams need to specify how many components they utilize, and assign 2828 component IDs to them, starting at 1 for the most important component 2829 ID. Specifications for new transport protocols must define how, if 2830 at all, various steps in the ICE processing differ from UDP. 2832 13. Setting Ta and RTO 2834 13.1. General 2836 During the ICE gathering phase (Section 4.1.1) and while ICE is 2837 performing connectivity checks (Section 6), an agent triggers STUN 2838 and TURN transactions. These transactions are paced at a rate 2839 indicated by Ta, and the retransmission interval for each transaction 2840 is calculated based on the the retransmission timer for the STUN 2841 transactions (RTO) [RFC5389]. 2843 This section describes how the Ta and RTO values are computed during 2844 the ICE gathering phase and while ICE is performing connectivity 2845 checks. 2847 NOTE: Previously, in RFC 5245, different formulas were defined for 2848 computing Ta and RTO, depending on whether ICE was used for a real- 2849 time media stream (e.g. RTP) or not. 2851 The formulas below result in a behavior whereby an agent will send 2852 its first packet for every single connectivity check before 2853 performing a retransmit. This can be seen in the formulas for the 2854 RTO (which represents the retransmit interval). Those formulas scale 2855 with N, the number of checks to be performed. As a result of this, 2856 ICE maintains a nicely constant rate, but becomes more sensitive to 2857 packet loss. The loss of the first single packet for any 2858 connectivity check is likely to cause that pair to take a long time 2859 to be validated, and instead, a lower-priority check (but one for 2860 which there was no packet loss) is much more likely to complete 2861 first. This results in ICE performing sub-optimally, choosing lower- 2862 priority pairs over higher-priority pairs. Implementors should be 2863 aware of this consequence, but still should utilize the timer values 2864 described here. 2866 13.2. Ta 2868 ICE agents SHOULD use the default Ta value, 50 ms, but MAY use 2869 another value based on the characteristics of the associated media. 2871 If an ICE agent wants to use another Ta value than the default value, 2872 the agent MUST indicate the proposed value to its peer during the ICE 2873 exchange. Both agents MUST use the higher value of the proposed 2874 values. If an agent does not propose a value, the default value is 2875 used for that agent when comparing which value is higher. 2877 Regardless of the Ta value chosen for each ICE agent, the combination 2878 of all transactions from all ICE agents (if a given implementation 2879 runs several concurrent ICE agents) MUST NOT be sent more often than 2880 once every 5ms (as though there were one global Ta value for pacing 2881 all ICE agents). 2883 This mechanism of a global minimum pacing interval of 5ms is not 2884 generally applicable to transport protocols, but is applicable to ICE 2885 based on the following reasoning. 2887 o Start with the following rules which would be generally applicable 2888 to transport protocols: 2890 1. Let MaxBytes be the maximum number of bytes allowed to be 2891 outstanding in the network at start-up, which SHOULD be 14600 2892 bytes per RFC 6928. 2894 2. Let HTO be the transaction timeout, which SHOULD be 2*RTT if 2895 RTT is known and 500ms otherwise. This is based on the RTO 2896 for STUN messages from RFC 5389 and the the TCP initial RTO, 2897 which is 1 sec in RFC 6298. 2899 3. Let MinPacing be the minimum pacing interval between 2900 transactions, which SHOULD be 5ms. 2902 o Observe that ICE agents typically do not know the RTT for ICE 2903 transactions (connectivity checks in particular), meaning that HTO 2904 will almost always be 500ms. 2906 o Observe that a MinPacing of 5ms and HTO of 500ms gives at most 100 2907 packets/HTO, which for a typical ICE check of less than 120 bytes 2908 means a maximum of 12000 outstanding bytes in the network, which 2909 is less than the maximum expressed by rule 1. 2911 o Thus, for ICE, the rule set reduces down to just the MinPacing 2912 rule, which is equivalant to having a global Ta value. 2914 NOTE: Appendix C shows examples of required bandwidth, using 2915 different Ta values. 2917 13.3. RTO 2919 During the ICE gathering phase, ICE agents SHOULD calculate the RTO 2920 value using the following formula: 2922 RTO = MAX (500ms, Ta * (Num-Of-Pairs)) 2924 Num-Of-Pairs: the number of pairs of candidates 2925 with STUN or TURN servers. 2927 For connectivity checks, ICE agents SHOULD calculate the RTO value 2928 using the following formula: 2930 RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress)) 2932 Num-Waiting: the number of checks in the CHECK LIST in the 2933 Waiting state. 2935 Num-In-Progress: the number of checks in the In-Progress state. 2937 Note that the RTO will be different for each transaction as the 2938 number of checks in the Waiting and In-Progress states change. 2940 ICE agents MAY calculate the RTO value using other mechanisms than 2941 those described above. ICE agents MUST NOT use a RTO value smaller 2942 than 500 ms. 2944 14. Example 2946 The example is based on the simplified topology of Figure 9. 2948 +-------+ 2949 |STUN | 2950 |Server | 2951 +-------+ 2952 | 2953 +---------------------+ 2954 | | 2955 | Internet | 2956 | | 2957 +---------------------+ 2958 | | 2959 | | 2960 +---------+ | 2961 | NAT | | 2962 +---------+ | 2963 | | 2964 | | 2965 +-----+ +-----+ 2966 | L | | R | 2967 +-----+ +-----+ 2969 Figure 9: Example Topology 2971 Two agents, L and R, are using ICE. Both are full-mode ICE 2972 implementations and use aggressive nomination when they are 2973 controlling. Both agents have a single IPv4 address. For agent L, 2974 it is 10.0.1.1 in private address space [RFC1918], and for agent R, 2975 192.0.2.1 on the public Internet. Both are configured with the same 2976 STUN server (shown in this example for simplicity, although in 2977 practice the agents do not need to use the same STUN server), which 2978 is listening for STUN Binding requests at an IP address of 192.0.2.2 2979 and port 3478. TURN servers are not used in this example. Agent L 2980 is behind a NAT, and agent R is on the public Internet. The NAT has 2981 an endpoint independent mapping property and an address dependent 2982 filtering property. The public side of the NAT has an IP address of 2983 192.0.2.3. 2985 To facilitate understanding, transport addresses are listed using 2986 variables that have mnemonic names. The format of the name is 2987 entity-type-seqno, where entity refers to the entity whose IP address 2988 the transport address is on, and is one of "L", "R", "STUN", or 2989 "NAT". The type is either "PUB" for transport addresses that are 2990 public, and "PRIV" for transport addresses that are private. 2992 Finally, seq-no is a sequence number that is different for each 2993 transport address of the same type on a particular entity. Each 2994 variable has an IP address and port, denoted by varname.IP and 2995 varname.PORT, respectively, where varname is the name of the 2996 variable. 2998 The STUN server has advertised transport address STUN-PUB-1 (which is 2999 192.0.2.2:3478). 3001 In the call flow itself, STUN messages are annotated with several 3002 attributes. The "S=" attribute indicates the source transport 3003 address of the message. The "D=" attribute indicates the destination 3004 transport address of the message. The "MA=" attribute is used in 3005 STUN Binding response messages and refers to the mapped address. 3006 "USE-CAND" implies the presence of the USE-CANDIDATE attribute. 3008 The call flow examples omit STUN authentication operations and RTCP, 3009 and focus on RTP for a single media stream between two full 3010 implementations. 3012 L NAT STUN R 3013 |RTP STUN alloc. | | 3014 |(1) STUN Req | | | 3015 |S=$L-PRIV-1 | | | 3016 |D=$STUN-PUB-1 | | | 3017 |------------->| | | 3018 | |(2) STUN Req | | 3019 | |S=$NAT-PUB-1 | | 3020 | |D=$STUN-PUB-1 | | 3021 | |------------->| | 3022 | |(3) STUN Res | | 3023 | |S=$STUN-PUB-1 | | 3024 | |D=$NAT-PUB-1 | | 3025 | |MA=$NAT-PUB-1 | | 3026 | |<-------------| | 3027 |(4) STUN Res | | | 3028 |S=$STUN-PUB-1 | | | 3029 |D=$L-PRIV-1 | | | 3030 |MA=$NAT-PUB-1 | | | 3031 |<-------------| | | 3032 |(5) L's Candidate Information| | 3033 |------------------------------------------->| 3034 | | | | RTP STUN 3035 | | | | alloc. 3036 | | |(6) STUN Req | 3037 | | |S=$R-PUB-1 | 3038 | | |D=$STUN-PUB-1 | 3039 | | |<-------------| 3040 | | |(7) STUN Res | 3041 | | |S=$STUN-PUB-1 | 3042 | | |D=$R-PUB-1 | 3043 | | |MA=$R-PUB-1 | 3044 | | |------------->| 3045 |(8) R's Candidate Information| | 3046 |<-------------------------------------------| 3047 | |(9) Bind Req | |Begin 3048 | |S=$R-PUB-1 | |Connectivity 3049 | |D=L-PRIV-1 | |Checks 3050 | |<----------------------------| 3051 | |Dropped | | 3052 |(10) Bind Req | | | 3053 |S=$L-PRIV-1 | | | 3054 |D=$R-PUB-1 | | | 3055 |USE-CAND | | | 3056 |------------->| | | 3057 | |(11) Bind Req | | 3058 | |S=$NAT-PUB-1 | | 3059 | |D=$R-PUB-1 | | 3060 | |USE-CAND | | 3061 | |---------------------------->| 3062 | |(12) Bind Res | | 3063 | |S=$R-PUB-1 | | 3064 | |D=$NAT-PUB-1 | | 3065 | |MA=$NAT-PUB-1 | | 3066 | |<----------------------------| 3067 |(13) Bind Res | | | 3068 |S=$R-PUB-1 | | | 3069 |D=$L-PRIV-1 | | | 3070 |MA=$NAT-PUB-1 | | | 3071 |<-------------| | | 3072 |RTP flows | | | 3073 | |(14) Bind Req | | 3074 | |S=$R-PUB-1 | | 3075 | |D=$NAT-PUB-1 | | 3076 | |<----------------------------| 3077 |(15) Bind Req | | | 3078 |S=$R-PUB-1 | | | 3079 |D=$L-PRIV-1 | | | 3080 |<-------------| | | 3081 |(16) Bind Res | | | 3082 |S=$L-PRIV-1 | | | 3083 |D=$R-PUB-1 | | | 3084 |MA=$R-PUB-1 | | | 3085 |------------->| | | 3086 | |(17) Bind Res | | 3087 | |S=$NAT-PUB-1 | | 3088 | |D=$R-PUB-1 | | 3089 | |MA=$R-PUB-1 | | 3090 | |---------------------------->| 3091 | | | |RTP flows 3093 Figure 10: Example Flow 3095 First, agent L obtains a host candidate from its local IP address 3096 (not shown), and from that, sends a STUN Binding request to the STUN 3097 server to get a server reflexive candidate (messages 1-4). Recall 3098 that the NAT has the address and port independent mapping property. 3099 Here, it creates a binding of NAT-PUB-1 for this UDP request, and 3100 this becomes the server reflexive candidate for RTP. 3102 Agent L sets a type preference of 126 for the host candidate and 100 3103 for the server reflexive. The local preference is 65535. Based on 3104 this, the priority of the host candidate is 2130706431 and for the 3105 server reflexive candidate is 1694498815. The host candidate is 3106 assigned a foundation of 1, and the server reflexive, a foundation of 3107 2. These are sent to the peer. 3109 This candidate information is received at agent R. Agent R will 3110 obtain a host candidate, and from it, obtain a server reflexive 3111 candidate (messages 6-7). Since R is not behind a NAT, this 3112 candidate is identical to its host candidate, and they share the same 3113 base. It therefore discards this redundant candidate and ends up 3114 with a single host candidate. With identical type and local 3115 preferences as L, the priority for this candidate is 2130706431. It 3116 chooses a foundation of 1 for its single candidate. Then R's 3117 candidates are then sent to L. 3119 Since neither side indicated that it is lite, the initiating agent 3120 that began ICE processing (agent L) becomes the controlling agent. 3122 Agents L and R both pair up the candidates. They both initially have 3123 two pairs. However, agent L will prune the pair containing its 3124 server reflexive candidate, resulting in just one. At agent L, this 3125 pair has a local candidate of $L_PRIV_1 and remote candidate of 3126 $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that 3127 an implementation would represent this as a 64-bit integer so as not 3128 to lose precision). At agent R, there are two pairs. The highest 3129 priority has a local candidate of $R_PUB_1 and remote candidate of 3130 $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a 3131 local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and 3132 priority 3.63891E+18. 3134 Agent R begins its connectivity check (message 9) for the first pair 3135 (between the two host candidates). Since R is the controlled agent 3136 for this session, the check omits the USE-CANDIDATE attribute. The 3137 host candidate from agent L is private and behind a NAT, and thus 3138 this check won't be successful, because the packet cannot be routed 3139 from R to L. 3141 When agent L gets the R's candidates, it performs its one and only 3142 connectivity check (messages 10-13). It implements the aggressive 3143 nomination algorithm, and thus includes a USE-CANDIDATE attribute in 3144 this check. Since the check succeeds, agent L creates a new pair, 3145 whose local candidate is from the mapped address in the Binding 3146 response (NAT-PUB-1 from message 13) and whose remote candidate is 3147 the destination of the request (R-PUB-1 from message 10). This is 3148 added to the VALID LIST. In addition, it is marked as selected since 3149 the Binding request contained the USE-CANDIDATE attribute. Since 3150 there is a selected candidate in the VALID LIST for the one component 3151 of this media stream, ICE processing for this stream moves into the 3152 Completed state. Agent L can now send media if it so chooses. 3154 Soon after receipt of the STUN Binding request from agent L (message 3155 11), agent R will generate its triggered check. This check happens 3156 to match the next one on its CHECK LIST -- from its host candidate to 3157 agent L's server reflexive candidate. This check (messages 14-17) 3158 will succeed. Consequently, agent R constructs a new candidate pair 3159 using the mapped address from the response as the local candidate (R- 3160 PUB-1) and the destination of the request (NAT-PUB-1) as the remote 3161 candidate. This pair is added to the VALID LIST for that media 3162 stream. Since the check was generated in the reverse direction of a 3163 check that contained the USE-CANDIDATE attribute, the candidate pair 3164 is marked as selected. Consequently, processing for this stream 3165 moves into the Completed state, and agent R can also send media. 3167 15. Security Considerations 3169 There are several types of attacks possible in an ICE system. This 3170 section considers these attacks and their countermeasures. These 3171 countermeasures include: 3173 o Using ICE in conjunction with secure signaling techniques, such as 3174 SIPS. 3176 o Limiting the total number of connectivity checks to 100, and 3177 optionally limiting the number of candidates they'll accept in an 3178 candidate exchange. 3180 15.1. Attacks on Connectivity Checks 3182 An attacker might attempt to disrupt the STUN connectivity checks. 3183 Ultimately, all of these attacks fool an agent into thinking 3184 something incorrect about the results of the connectivity checks. 3185 The possible false conclusions an attacker can try and cause are: 3187 False Invalid: An attacker can fool a pair of agents into thinking a 3188 candidate pair is invalid, when it isn't. This can be used to 3189 cause an agent to prefer a different candidate (such as one 3190 injected by the attacker) or to disrupt a call by forcing all 3191 candidates to fail. 3193 False Valid: An attacker can fool a pair of agents into thinking a 3194 candidate pair is valid, when it isn't. This can cause an agent 3195 to proceed with a session, but then not be able to receive any 3196 media. 3198 False Peer Reflexive Candidate: An attacker can cause an agent to 3199 discover a new peer reflexive candidate, when it shouldn't have. 3200 This can be used to redirect media streams to a Denial-of-Service 3201 (DoS) target or to the attacker, for eavesdropping or other 3202 purposes. 3204 False Valid on False Candidate: An attacker has already convinced an 3205 agent that there is a candidate with an address that doesn't 3206 actually route to that agent (for example, by injecting a false 3207 peer reflexive candidate or false server reflexive candidate). It 3208 must then launch an attack that forces the agents to believe that 3209 this candidate is valid. 3211 If an attacker can cause a false peer reflexive candidate or false 3212 valid on a false candidate, it can launch any of the attacks 3213 described in [RFC5389]. 3215 To force the false invalid result, the attacker has to wait for the 3216 connectivity check from one of the agents to be sent. When it is, 3217 the attacker needs to inject a fake response with an unrecoverable 3218 error response, such as a 400. However, since the candidate is, in 3219 fact, valid, the original request may reach the peer agent, and 3220 result in a success response. The attacker needs to force this 3221 packet or its response to be dropped, through a DoS attack, layer 2 3222 network disruption, or other technique. If it doesn't do this, the 3223 success response will also reach the originator, alerting it to a 3224 possible attack. Fortunately, this attack is mitigated completely 3225 through the STUN short-term credential mechanism. The attacker needs 3226 to inject a fake response, and in order for this response to be 3227 processed, the attacker needs the password. If the candidate 3228 exchange signaling is secured, the attacker will not have the 3229 password and its response will be discarded. 3231 Forcing the fake valid result works in a similar way. The agent 3232 needs to wait for the Binding request from each agent, and inject a 3233 fake success response. The attacker won't need to worry about 3234 disrupting the actual response since, if the candidate is not valid, 3235 it presumably wouldn't be received anyway. However, like the fake 3236 invalid attack, this attack is mitigated by the STUN short-term 3237 credential mechanism in conjunction with a secure candidate exchange. 3239 Forcing the false peer reflexive candidate result can be done either 3240 with fake requests or responses, or with replays. We consider the 3241 fake requests and responses case first. It requires the attacker to 3242 send a Binding request to one agent with a source IP address and port 3243 for the false candidate. In addition, the attacker must wait for a 3244 Binding request from the other agent, and generate a fake response 3245 with a XOR-MAPPED-ADDRESS attribute containing the false candidate. 3246 Like the other attacks described here, this attack is mitigated by 3247 the STUN message integrity mechanisms and secure candidate exchanges. 3249 Forcing the false peer reflexive candidate result with packet replays 3250 is different. The attacker waits until one of the agents sends a 3251 check. It intercepts this request, and replays it towards the other 3252 agent with a faked source IP address. It must also prevent the 3253 original request from reaching the remote agent, either by launching 3254 a DoS attack to cause the packet to be dropped, or forcing it to be 3255 dropped using layer 2 mechanisms. The replayed packet is received at 3256 the other agent, and accepted, since the integrity check passes (the 3257 integrity check cannot and does not cover the source IP address and 3258 port). It is then responded to. This response will contain a XOR- 3259 MAPPED-ADDRESS with the false candidate, and will be sent to that 3260 false candidate. The attacker must then receive it and relay it 3261 towards the originator. 3263 The other agent will then initiate a connectivity check towards that 3264 false candidate. This validation needs to succeed. This requires 3265 the attacker to force a false valid on a false candidate. Injecting 3266 of fake requests or responses to achieve this goal is prevented using 3267 the integrity mechanisms of STUN and the candidate exchange. Thus, 3268 this attack can only be launched through replays. To do that, the 3269 attacker must intercept the check towards this false candidate, and 3270 replay it towards the other agent. Then, it must intercept the 3271 response and replay that back as well. 3273 This attack is very hard to launch unless the attacker is identified 3274 by the fake candidate. This is because it requires the attacker to 3275 intercept and replay packets sent by two different hosts. If both 3276 agents are on different networks (for example, across the public 3277 Internet), this attack can be hard to coordinate, since it needs to 3278 occur against two different endpoints on different parts of the 3279 network at the same time. 3281 If the attacker itself is identified by the fake candidate, the 3282 attack is easier to coordinate. However, if the media path is 3283 secured (e.g., using SRTP [RFC3711]), the attacker will not be able 3284 to play the media packets, but will only be able to discard them, 3285 effectively disabling the media stream for the call. However, this 3286 attack requires the agent to disrupt packets in order to block the 3287 connectivity check from reaching the target. In that case, if the 3288 goal is to disrupt the media stream, it's much easier to just disrupt 3289 it with the same mechanism, rather than attack ICE. 3291 15.2. Attacks on Server Reflexive Address Gathering 3293 ICE endpoints make use of STUN Binding requests for gathering server 3294 reflexive candidates from a STUN server. These requests are not 3295 authenticated in any way. As a consequence, there are numerous 3296 techniques an attacker can employ to provide the client with a false 3297 server reflexive candidate: 3299 o An attacker can compromise the DNS, causing DNS queries to return 3300 a rogue STUN server address. That server can provide the client 3301 with fake server reflexive candidates. This attack is mitigated 3302 by DNS security, though DNS-SEC is not required to address it. 3304 o An attacker that can observe STUN messages (such as an attacker on 3305 a shared network segment, like WiFi) can inject a fake response 3306 that is valid and will be accepted by the client. 3308 o An attacker can compromise a STUN server by means of a virus, and 3309 cause it to send responses with incorrect mapped addresses. 3311 A false mapped address learned by these attacks will be used as a 3312 server reflexive candidate in the ICE exchange. For this candidate 3313 to actually be used for media, the attacker must also attack the 3314 connectivity checks, and in particular, force a false valid on a 3315 false candidate. This attack is very hard to launch if the false 3316 address identifies a fourth party (neither the initiator, responder, 3317 nor attacker), since it requires attacking the checks generated by 3318 each agent in the session, and is prevented by SRTP if it identifies 3319 the attacker themself. 3321 If the attacker elects not to attack the connectivity checks, the 3322 worst it can do is prevent the server reflexive candidate from being 3323 used. However, if the peer agent has at least one candidate that is 3324 reachable by the agent under attack, the STUN connectivity checks 3325 themselves will provide a peer reflexive candidate that can be used 3326 for the exchange of media. Peer reflexive candidates are generally 3327 preferred over server reflexive candidates. As such, an attack 3328 solely on the STUN address gathering will normally have no impact on 3329 a session at all. 3331 15.3. Attacks on Relayed Candidate Gathering 3333 An attacker might attempt to disrupt the gathering of relayed 3334 candidates, forcing the client to believe it has a false relayed 3335 candidate. Exchanges with the TURN server are authenticated using a 3336 long-term credential. Consequently, injection of fake responses or 3337 requests will not work. In addition, unlike Binding requests, 3338 Allocate requests are not susceptible to replay attacks with modified 3339 source IP addresses and ports, since the source IP address and port 3340 are not utilized to provide the client with its relayed candidate. 3342 However, TURN servers are susceptible to DNS attacks, or to viruses 3343 aimed at the TURN server, for purposes of turning it into a zombie or 3344 rogue server. These attacks can be mitigated by DNS-SEC and through 3345 good box and software security on TURN servers. 3347 Even if an attacker has caused the client to believe in a false 3348 relayed candidate, the connectivity checks cause such a candidate to 3349 be used only if they succeed. Thus, an attacker must launch a false 3350 valid on a false candidate, per above, which is a very difficult 3351 attack to coordinate. 3353 15.4. Insider Attacks 3355 In addition to attacks where the attacker is a third party trying to 3356 insert fake candidate information or stun messages, there are attacks 3357 possible with ICE when the attacker is an authenticated and valid 3358 participant in the ICE exchange. 3360 15.4.1. STUN Amplification Attack 3362 The STUN amplification attack is similar to the voice hammer. 3363 However, instead of voice packets being directed to the target, STUN 3364 connectivity checks are directed to the target. The attacker sends 3365 an a large number of candidates, say, 50. The responding agent 3366 receives the candidate information, and starts its checks, which are 3367 directed at the target, and consequently, never generate a response. 3368 The answerer will start a new connectivity check every Ta ms (say, 3369 Ta=20ms). However, the retransmission timers are set to a large 3370 number due to the large number of candidates. As a consequence, 3371 packets will be sent at an interval of one every Ta milliseconds, and 3372 then with increasing intervals after that. Thus, STUN will not send 3373 packets at a rate faster than media would be sent, and the STUN 3374 packets persist only briefly, until ICE fails for the session. 3375 Nonetheless, this is an amplification mechanism. 3377 It is impossible to eliminate the amplification, but the volume can 3378 be reduced through a variety of heuristics. Agents SHOULD limit the 3379 total number of connectivity checks they perform to 100. 3380 Additionally, agents MAY limit the number of candidates they'll 3381 accept. 3383 Frequently, protocols that wish to avoid these kinds of attacks force 3384 the initiator to wait for a response prior to sending the next 3385 message. However, in the case of ICE, this is not possible. It is 3386 not possible to differentiate the following two cases: 3388 o There was no response because the initiator is being used to 3389 launch a DoS attack against an unsuspecting target that will not 3390 respond. 3392 o There was no response because the IP address and port are not 3393 reachable by the initiator. 3395 In the second case, another check should be sent at the next 3396 opportunity, while in the former case, no further checks should be 3397 sent. 3399 16. STUN Extensions 3401 16.1. New Attributes 3403 This specification defines four new attributes, PRIORITY, USE- 3404 CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. 3406 The PRIORITY attribute indicates the priority that is to be 3407 associated with a peer reflexive candidate, should one be discovered 3408 by this check. It is a 32-bit unsigned integer, and has an attribute 3409 value of 0x0024. 3411 The USE-CANDIDATE attribute indicates that the candidate pair 3412 resulting from this check should be used for transmission of media. 3413 The attribute has no content (the Length field of the attribute is 3414 zero); it serves as a flag. It has an attribute value of 0x0025. 3416 The ICE-CONTROLLED attribute is present in a Binding request and 3417 indicates that the client believes it is currently in the controlled 3418 role. The content of the attribute is a 64-bit unsigned integer in 3419 network byte order, which contains a random number. The number is 3420 used for solving role conflicts, when it is referred to as the tie- 3421 breaker value. An ICE agent MUST use the same number for all Binding 3422 requests, for all streams, within an ICE session. The ICE agent MAY 3423 change the number when an ICE restart occurs. 3425 The ICE-CONTROLLING attribute is present in a Binding request and 3426 indicates that the client believes it is currently in the controlling 3427 role. The content of the attribute is a 64-bit unsigned integer in 3428 network byte order, which contains a random number. The number is 3429 used for solving role conflicts, when it is referred to as the tie- 3430 breaker value. An ICE agent MUST use the same number for all Binding 3431 requests, for all streams, within an ICE session. The ICE agent MAY 3432 change the number when an ICE restart occurs. 3434 16.2. New Error Response Codes 3436 This specification defines a single error response code: 3438 487 (Role Conflict): The Binding request contained either the ICE- 3439 CONTROLLING or ICE-CONTROLLED attribute, indicating an ICE role 3440 that conflicted with the server. The server compared the tie- 3441 breaker values of the client and the server and determined that 3442 the client needs to switch roles. 3444 17. Operational Considerations 3446 This section discusses issues relevant to network operators looking 3447 to deploy ICE. 3449 17.1. NAT and Firewall Types 3451 ICE was designed to work with existing NAT and firewall equipment. 3452 Consequently, it is not necessary to replace or reconfigure existing 3453 firewall and NAT equipment in order to facilitate deployment of ICE. 3454 Indeed, ICE was developed to be deployed in environments where the 3455 Voice over IP (VoIP) operator has no control over the IP network 3456 infrastructure, including firewalls and NAT. 3458 That said, ICE works best in environments where the NAT devices are 3459 "behave" compliant, meeting the recommendations defined in [RFC4787] 3460 and [RFC5382]. In networks with behave-compliant NAT, ICE will work 3461 without the need for a TURN server, thus improving voice quality, 3462 decreasing call setup times, and reducing the bandwidth demands on 3463 the network operator. 3465 17.2. Bandwidth Requirements 3467 Deployment of ICE can have several interactions with available 3468 network capacity that operators should take into consideration. 3470 17.2.1. STUN and TURN Server Capacity Planning 3472 First and foremost, ICE makes use of TURN and STUN servers, which 3473 would typically be located in the network operator's data centers. 3474 The STUN servers require relatively little bandwidth. For each 3475 component of each media stream, there will be one or more STUN 3476 transactions from each client to the STUN server. In a basic voice- 3477 only IPv4 VoIP deployment, there will be four transactions per call 3478 (one for RTP and one for RTCP, for both caller and callee). Each 3479 transaction is a single request and a single response, the former 3480 being 20 bytes long, and the latter, 28. Consequently, if a system 3481 has N users, and each makes four calls in a busy hour, this would 3482 require N*1.7bps. For one million users, this is 1.7 Mbps, a very 3483 small number (relatively speaking). 3485 TURN traffic is more substantial. The TURN server will see traffic 3486 volume equal to the STUN volume (indeed, if TURN servers are 3487 deployed, there is no need for a separate STUN server), in addition 3488 to the traffic for the actual media traffic. The amount of calls 3489 requiring TURN for media relay is highly dependent on network 3490 topologies, and can and will vary over time. In a network with 100% 3491 behave-compliant NAT, it is exactly zero. At time of writing, large- 3492 scale consumer deployments were seeing between 5 and 10 percent of 3493 calls requiring TURN servers. Considering a voice-only deployment 3494 using G.711 (so 80 kbps in each direction), with .2 erlangs during 3495 the busy hour, this is N*3.2 kbps. For a population of one million 3496 users, this is 3.2 Gbps, assuming a 10% usage of TURN servers. 3498 17.2.2. Gathering and Connectivity Checks 3500 The process of gathering of candidates and performing of connectivity 3501 checks can be bandwidth intensive. ICE has been designed to pace 3502 both of these processes. The gathering phase and the connectivity 3503 check phase are meant to generate traffic at roughly the same 3504 bandwidth as the media traffic itself. This was done to ensure that, 3505 if a network is designed to support multimedia traffic of a certain 3506 type (voice, video, or just text), it will have sufficient capacity 3507 to support the ICE checks for that media. Of course, the ICE checks 3508 will cause a marginal increase in the total utilization; however, 3509 this will typically be an extremely small increase. 3511 Congestion due to the gathering and check phases has proven to be a 3512 problem in deployments that did not utilize pacing. Typically, 3513 access links became congested as the endpoints flooded the network 3514 with checks as fast as they can send them. Consequently, network 3515 operators should make sure that their ICE implementations support the 3516 pacing feature. Though this pacing does increase call setup times, 3517 it makes ICE network friendly and easier to deploy. 3519 17.2.3. Keepalives 3521 STUN keepalives (in the form of STUN Binding Indications) are sent in 3522 the middle of a media session. However, they are sent only in the 3523 absence of actual media traffic. In deployments that are not 3524 utilizing Voice Activity Detection (VAD), the keepalives are never 3525 used and there is no increase in bandwidth usage. When VAD is being 3526 used, keepalives will be sent during silence periods. This involves 3527 a single packet every 15-20 seconds, far less than the packet every 3528 20-30 ms that is sent when there is voice. Therefore, keepalives 3529 don't have any real impact on capacity planning. 3531 17.3. ICE and ICE-lite 3533 Deployments utilizing a mix of ICE and ICE-lite interoperate 3534 perfectly. They have been explicitly designed to do so, without loss 3535 of function. 3537 However, ICE-lite can only be deployed in limited use cases. Those 3538 cases, and the caveats involved in doing so, are documented in 3539 Appendix A. 3541 17.4. Troubleshooting and Performance Management 3543 ICE utilizes end-to-end connectivity checks, and places much of the 3544 processing in the endpoints. This introduces a challenge to the 3545 network operator -- how can they troubleshoot ICE deployments? How 3546 can they know how ICE is performing? 3548 ICE has built-in features to help deal with these problems. SIP 3549 servers on the signaling path, typically deployed in the data centers 3550 of the network operator, will see the contents of the candidate 3551 exchanges that convey the ICE parameters. These parameters include 3552 the type of each candidate (host, server reflexive, or relayed), 3553 along with their related addresses. Once ICE processing has 3554 completed, an updated candidate exchange takes place, signaling the 3555 selected address (and its type). This updated re-INVITE is performed 3556 exactly for the purposes of educating network equipment (such as a 3557 diagnostic tool attached to a SIP server) about the results of ICE 3558 processing. 3560 As a consequence, through the logs generated by the SIP server, a 3561 network operator can observe what types of candidates are being used 3562 for each call, and what address was selected by ICE. This is the 3563 primary information that helps evaluate how ICE is performing. 3565 17.5. Endpoint Configuration 3567 ICE relies on several pieces of data being configured into the 3568 endpoints. This configuration data includes timers, credentials for 3569 TURN servers, and hostnames for STUN and TURN servers. ICE itself 3570 does not provide a mechanism for this configuration. Instead, it is 3571 assumed that this information is attached to whatever mechanism is 3572 used to configure all of the other parameters in the endpoint. For 3573 SIP phones, standard solutions such as the configuration framework 3574 [RFC6080] have been defined. 3576 18. IANA Considerations 3578 The original ICE specification registered four new STUN attributes, 3579 and one new STUN error response. The STUN attributes and error 3580 response are reproduced here. In addition, this specification 3581 registers a new ICE option. 3583 18.1. STUN Attributes 3585 IANA has registered four STUN attributes: 3587 0x0024 PRIORITY 3588 0x0025 USE-CANDIDATE 3589 0x8029 ICE-CONTROLLED 3590 0x802A ICE-CONTROLLING 3592 18.2. STUN Error Responses 3594 IANA has registered following STUN error response code: 3596 487 Role Conflict: The client asserted an ICE role (controlling or 3597 controlled) that is in conflict with the role of the server. 3599 18.3. ICE Options 3601 IANA is requested to register the following ICE option in the "ICE 3602 Options" sub-registry of the "Interactive Connectivity Establishment 3603 (ICE) registry", following the procedures defined in [RFC6336]. 3605 ICE Option name: 3607 ice2 3609 Contact: 3611 Name: Christer Holmberg 3612 E-mail: christer.holmberg(at)ericsson(dot)com 3613 Address: Oy LM Ericsson Ab, 02420 Jorvas, FINLAND 3615 Change control: 3617 IESG 3619 Description: 3621 The ICE option indicates that the ICE agent using the ICE option 3622 is compliant and implemented according to RFC XXXX. 3624 Reference: 3626 RFC XXXX 3628 19. IAB Considerations 3630 The IAB has studied the problem of "Unilateral Self-Address Fixing", 3631 which is the general process by which a agent attempts to determine 3632 its address in another realm on the other side of a NAT through a 3633 collaborative protocol reflection mechanism [RFC3424]. ICE is an 3634 example of a protocol that performs this type of function. 3635 Interestingly, the process for ICE is not unilateral, but bilateral, 3636 and the difference has a significant impact on the issues raised by 3637 IAB. Indeed, ICE can be considered a B-SAF (Bilateral Self-Address 3638 Fixing) protocol, rather than an UNSAF protocol. Regardless, the IAB 3639 has mandated that any protocols developed for this purpose document a 3640 specific set of considerations. This section meets those 3641 requirements. 3643 19.1. Problem Definition 3645 >From RFC 3424, any UNSAF proposal must provide: 3647 Precise definition of a specific, limited-scope problem that is to 3648 be solved with the UNSAF proposal. A short-term fix should not be 3649 generalized to solve other problems; this is why "short-term fixes 3650 usually aren't". 3652 The specific problems being solved by ICE are: 3654 Provide a means for two peers to determine the set of transport 3655 addresses that can be used for communication. 3657 Provide a means for a agent to determine an address that is 3658 reachable by another peer with which it wishes to communicate. 3660 19.2. Exit Strategy 3662 >From RFC 3424, any UNSAF proposal must provide: 3664 Description of an exit strategy/transition plan. The better 3665 short-term fixes are the ones that will naturally see less and 3666 less use as the appropriate technology is deployed. 3668 ICE itself doesn't easily get phased out. However, it is useful even 3669 in a globally connected Internet, to serve as a means for detecting 3670 whether a router failure has temporarily disrupted connectivity, for 3671 example. ICE also helps prevent certain security attacks that have 3672 nothing to do with NAT. However, what ICE does is help phase out 3673 other UNSAF mechanisms. ICE effectively selects amongst those 3674 mechanisms, prioritizing ones that are better, and deprioritizing 3675 ones that are worse. Local IPv6 addresses can be preferred. As NATs 3676 begin to dissipate as IPv6 is introduced, server reflexive and 3677 relayed candidates (both forms of UNSAF addresses) simply never get 3678 used, because higher-priority connectivity exists to the native host 3679 candidates. Therefore, the servers get used less and less, and can 3680 eventually be remove when their usage goes to zero. 3682 Indeed, ICE can assist in the transition from IPv4 to IPv6. It can 3683 be used to determine whether to use IPv6 or IPv4 when two dual-stack 3684 hosts communicate with SIP (IPv6 gets used). It can also allow a 3685 network with both 6to4 and native v6 connectivity to determine which 3686 address to use when communicating with a peer. 3688 19.3. Brittleness Introduced by ICE 3690 >From RFC 3424, any UNSAF proposal must provide: 3692 Discussion of specific issues that may render systems more 3693 "brittle". For example, approaches that involve using data at 3694 multiple network layers create more dependencies, increase 3695 debugging challenges, and make it harder to transition. 3697 ICE actually removes brittleness from existing UNSAF mechanisms. In 3698 particular, classic STUN (as described in RFC 3489 [RFC3489]) has 3699 several points of brittleness. One of them is the discovery process 3700 that requires an agent to try to classify the type of NAT it is 3701 behind. This process is error-prone. With ICE, that discovery 3702 process is simply not used. Rather than unilaterally assessing the 3703 validity of the address, its validity is dynamically determined by 3704 measuring connectivity to a peer. The process of determining 3705 connectivity is very robust. 3707 Another point of brittleness in classic STUN and any other unilateral 3708 mechanism is its absolute reliance on an additional server. ICE 3709 makes use of a server for allocating unilateral addresses, but allows 3710 agents to directly connect if possible. Therefore, in some cases, 3711 the failure of a STUN server would still allow for a call to progress 3712 when ICE is used. 3714 Another point of brittleness in classic STUN is that it assumes that 3715 the STUN server is on the public Internet. Interestingly, with ICE, 3716 that is not necessary. There can be a multitude of STUN servers in a 3717 variety of address realms. ICE will discover the one that has 3718 provided a usable address. 3720 The most troubling point of brittleness in classic STUN is that it 3721 doesn't work in all network topologies. In cases where there is a 3722 shared NAT between each agent and the STUN server, traditional STUN 3723 may not work. With ICE, that restriction is removed. 3725 Classic STUN also introduces some security considerations. 3726 Fortunately, those security considerations are also mitigated by ICE. 3728 Consequently, ICE serves to repair the brittleness introduced in 3729 classic STUN, and does not introduce any additional brittleness into 3730 the system. 3732 The penalty of these improvements is that ICE increases session 3733 establishment times. 3735 19.4. Requirements for a Long-Term Solution 3737 From RFC 3424, any UNSAF proposal must provide: 3739 ... requirements for longer term, sound technical solutions -- 3740 contribute to the process of finding the right longer term 3741 solution. 3743 Our conclusions from RFC 3489 remain unchanged. However, we feel ICE 3744 actually helps because we believe it can be part of the long-term 3745 solution. 3747 19.5. Issues with Existing NAPT Boxes 3749 From RFC 3424, any UNSAF proposal must provide: 3751 Discussion of the impact of the noted practical issues with 3752 existing, deployed NA[P]Ts and experience reports. 3754 A number of NAT boxes are now being deployed into the market that try 3755 to provide "generic" ALG functionality. These generic ALGs hunt for 3756 IP addresses, either in text or binary form within a packet, and 3757 rewrite them if they match a binding. This interferes with classic 3758 STUN. However, the update to STUN [RFC5389] uses an encoding that 3759 hides these binary addresses from generic ALGs. 3761 Existing NAPT boxes have non-deterministic and typically short 3762 expiration times for UDP-based bindings. This requires 3763 implementations to send periodic keepalives to maintain those 3764 bindings. ICE uses a default of 15 s, which is a very conservative 3765 estimate. Eventually, over time, as NAT boxes become compliant to 3766 behave [RFC4787], this minimum keepalive will become deterministic 3767 and well-known, and the ICE timers can be adjusted. Having a way to 3768 discover and control the minimum keepalive interval would be far 3769 better still. 3771 20. Changes from RFC 5245 3773 Following is the list of changes from RFC 5245 3775 o The specification was generalized to be more usable with any 3776 protocol and the parts that are specific to SIP and SDP were moved 3777 to a SIP/SDP usage document [I-D.ietf-mmusic-ice-sip-sdp]. 3779 o Default candidates, multiple components, ICE mismatch detection, 3780 subsequent offer/answer, and role conflict resolution were made 3781 optional since they are not needed with every protocol using ICE. 3783 o With IPv6, the precedence rules of RFC 6724 are used instead of 3784 the obsoleted RFC 3483 and using address preferences provided by 3785 the host operating system is recommended. 3787 o Candidate gathering rules regarding loopback addresses and IPv6 3788 addresses were clarified. 3790 21. Acknowledgements 3792 Most of the text in this document comes from the original ICE 3793 specification, RFC 5245. The authors would like to thank everyone 3794 who has contributed to that document. For additional contributions 3795 to this revision of the specification we would like to thank Emil 3796 Ivov, Paul Kyzivat, Pal-Erik Martinsen, Simon Perrault, Eric 3797 Rescorla, Thomas Stach, Peter Thatcher, Martin Thomson, Justin 3798 Uberti, and Suhas Nandakumar. 3800 22. References 3802 22.1. Normative References 3804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3805 Requirement Levels", BCP 14, RFC 2119, 3806 DOI 10.17487/RFC2119, March 1997, 3807 . 3809 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3810 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3811 DOI 10.17487/RFC5389, October 2008, 3812 . 3814 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 3815 Relays around NAT (TURN): Relay Extensions to Session 3816 Traversal Utilities for NAT (STUN)", RFC 5766, 3817 DOI 10.17487/RFC5766, April 2010, 3818 . 3820 [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for 3821 Interactive Connectivity Establishment (ICE) Options", 3822 RFC 6336, DOI 10.17487/RFC6336, July 2011, 3823 . 3825 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 3826 "Default Address Selection for Internet Protocol Version 6 3827 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 3828 . 3830 22.2. Informative References 3832 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 3833 in Session Description Protocol (SDP)", RFC 3605, 3834 DOI 10.17487/RFC3605, October 2003, 3835 . 3837 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3838 A., Peterson, J., Sparks, R., Handley, M., and E. 3839 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3840 DOI 10.17487/RFC3261, June 2002, 3841 . 3843 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 3844 with Session Description Protocol (SDP)", RFC 3264, 3845 DOI 10.17487/RFC3264, June 2002, 3846 . 3848 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 3849 "STUN - Simple Traversal of User Datagram Protocol (UDP) 3850 Through Network Address Translators (NATs)", RFC 3489, 3851 DOI 10.17487/RFC3489, March 2003, 3852 . 3854 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 3855 Application Design Guidelines", RFC 3235, 3856 DOI 10.17487/RFC3235, January 2002, 3857 . 3859 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 3860 A. Rayhan, "Middlebox communication architecture and 3861 framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, 3862 . 3864 [RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, 3865 "Realm Specific IP: Framework", RFC 3102, 3866 DOI 10.17487/RFC3102, October 2001, 3867 . 3869 [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, 3870 "Realm Specific IP: Protocol Specification", RFC 3103, 3871 DOI 10.17487/RFC3103, October 2001, 3872 . 3874 [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for 3875 UNilateral Self-Address Fixing (UNSAF) Across Network 3876 Address Translation", RFC 3424, DOI 10.17487/RFC3424, 3877 November 2002, . 3879 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3880 Jacobson, "RTP: A Transport Protocol for Real-Time 3881 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 3882 July 2003, . 3884 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3885 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 3886 RFC 3711, DOI 10.17487/RFC3711, March 2004, 3887 . 3889 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 3890 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 3891 2004, . 3893 [RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and 3894 E. Castro, "Application Aspects of IPv6 Transition", 3895 RFC 4038, DOI 10.17487/RFC4038, March 2005, 3896 . 3898 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 3899 Address Types (ANAT) Semantics for the Session Description 3900 Protocol (SDP) Grouping Framework", RFC 4091, 3901 DOI 10.17487/RFC4091, June 2005, 3902 . 3904 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 3905 Description Protocol (SDP) Alternative Network Address 3906 Types (ANAT) Semantics in the Session Initiation Protocol 3907 (SIP)", RFC 4092, DOI 10.17487/RFC4092, June 2005, 3908 . 3910 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3911 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3912 2006, . 3914 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3915 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 3916 July 2006, . 3918 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3919 and W. Weiss, "An Architecture for Differentiated 3920 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 3921 . 3923 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 3924 and E. Lear, "Address Allocation for Private Internets", 3925 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 3926 . 3928 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 3929 Translation (NAT) Behavioral Requirements for Unicast 3930 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 3931 2007, . 3933 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 3934 Control Packets on a Single Port", RFC 5761, 3935 DOI 10.17487/RFC5761, April 2010, 3936 . 3938 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 3939 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 3940 . 3942 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 3943 (ICE): A Protocol for Network Address Translator (NAT) 3944 Traversal for Offer/Answer Protocols", RFC 5245, 3945 DOI 10.17487/RFC5245, April 2010, 3946 . 3948 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 3949 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 3950 RFC 5382, DOI 10.17487/RFC5382, October 2008, 3951 . 3953 [RFC6080] Petrie, D. and S. Channabasappa, Ed., "A Framework for 3954 Session Initiation Protocol User Agent Profile Delivery", 3955 RFC 6080, DOI 10.17487/RFC6080, March 2011, 3956 . 3958 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3959 NAT64: Network Address and Protocol Translation from IPv6 3960 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3961 April 2011, . 3963 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 3964 Beijnum, "DNS64: DNS Extensions for Network Address 3965 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 3966 DOI 10.17487/RFC6147, April 2011, 3967 . 3969 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 3970 "TCP Candidates with Interactive Connectivity 3971 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 3972 March 2012, . 3974 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 3975 the IPv6 Prefix Used for IPv6 Address Synthesis", 3976 RFC 7050, DOI 10.17487/RFC7050, November 2013, 3977 . 3979 [I-D.ietf-mmusic-ice-sip-sdp] 3980 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using 3981 Interactive Connectivity Establishment (ICE) with Session 3982 Description Protocol (SDP) offer/answer and Session 3983 Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- 3984 sdp-12 (work in progress), March 2017. 3986 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 3987 Considerations for IPv6 Address Generation Mechanisms", 3988 RFC 7721, DOI 10.17487/RFC7721, March 2016, 3989 . 3991 [I-D.ietf-ice-dualstack-fairness] 3992 Martinsen, P., Reddy, T., and P. Patil, "ICE Multihomed 3993 and IPv4/IPv6 Dual Stack Guidelines", draft-ietf-ice- 3994 dualstack-fairness-07 (work in progress), November 2016. 3996 Appendix A. Lite and Full Implementations 3998 ICE allows for two types of implementations. A full implementation 3999 supports the controlling and controlled roles in a session, and can 4000 also perform address gathering. In contrast, a lite implementation 4001 is a minimalist implementation that does little but respond to STUN 4002 checks. 4004 Because ICE requires both endpoints to support it in order to bring 4005 benefits to either endpoint, incremental deployment of ICE in a 4006 network is more complicated. Many sessions involve an endpoint that 4007 is, by itself, not behind a NAT and not one that would worry about 4008 NAT traversal. A very common case is to have one endpoint that 4009 requires NAT traversal (such as a VoIP hard phone or soft phone) make 4010 a call to one of these devices. Even if the phone supports a full 4011 ICE implementation, ICE won't be used at all if the other device 4012 doesn't support it. The lite implementation allows for a low-cost 4013 entry point for these devices. Once they support the lite 4014 implementation, full implementations can connect to them and get the 4015 full benefits of ICE. 4017 Consequently, a lite implementation is only appropriate for devices 4018 that will *always* be connected to the public Internet and have a 4019 public IP address at which it can receive packets from any 4020 correspondent. ICE will not function when a lite implementation is 4021 placed behind a NAT. 4023 ICE allows a lite implementation to have a single IPv4 host candidate 4024 and several IPv6 addresses. In that case, candidate pairs are 4025 selected by the controlling agent using a static algorithm, such as 4026 the one in RFC 6724, which is recommended by this specification. 4027 However, static mechanisms for address selection are always prone to 4028 error, since they cannot ever reflect the actual topology and can 4029 never provide actual guarantees on connectivity. They are always 4030 heuristics. Consequently, if an agent is implementing ICE just to 4031 select between its IPv4 and IPv6 addresses, and none of its IP 4032 addresses are behind NAT, usage of full ICE is still RECOMMENDED in 4033 order to provide the most robust form of address selection possible. 4035 It is important to note that the lite implementation was added to 4036 this specification to provide a stepping stone to full 4037 implementation. Even for devices that are always connected to the 4038 public Internet with just a single IPv4 address, a full 4039 implementation is preferable if achievable. Full implementations 4040 also obtain the security benefits of ICE unrelated to NAT traversal; 4041 in particular, the voice hammer attack described in Section 15 is 4042 prevented only for full implementations, not lite. Finally, it is 4043 often the case that a device that finds itself with a public address 4044 today will be placed in a network tomorrow where it will be behind a 4045 NAT. It is difficult to definitively know, over the lifetime of a 4046 device or product, that it will always be used on the public 4047 Internet. Full implementation provides assurance that communications 4048 will always work. 4050 Appendix B. Design Motivations 4052 ICE contains a number of normative behaviors that may themselves be 4053 simple, but derive from complicated or non-obvious thinking or use 4054 cases that merit further discussion. Since these design motivations 4055 are not necessary to understand for purposes of implementation, they 4056 are discussed here in an appendix to the specification. This section 4057 is non-normative. 4059 B.1. Pacing of STUN Transactions 4061 STUN transactions used to gather candidates and to verify 4062 connectivity are paced out at an approximate rate of one new 4063 transaction every Ta milliseconds. Each transaction, in turn, has a 4064 retransmission timer RTO that is a function of Ta as well. Why are 4065 these transactions paced, and why are these formulas used? 4067 Sending of these STUN requests will often have the effect of creating 4068 bindings on NAT devices between the client and the STUN servers. 4069 Experience has shown that many NAT devices have upper limits on the 4070 rate at which they will create new bindings. Experiments have shown 4071 that once every 5 ms is well supported. This is why Ta has a lower 4072 bound of 5 ms. Furthermore, transmission of these packets on the 4073 network makes use of bandwidth and needs to be rate limited by the 4074 agent. Deployments based on earlier draft versions of [RFC5245] 4075 tended to overload rate-constrained access links and perform poorly 4076 overall, in addition to negatively impacting the network. As a 4077 consequence, the pacing ensures that the NAT device does not get 4078 overloaded and that traffic is kept at a reasonable rate. 4080 The definition of a "reasonable" rate is that STUN should not use 4081 more bandwidth than the RTP itself will use, once media starts 4082 flowing. The formula for Ta is designed so that, if a STUN packet 4083 were sent every Ta seconds, it would consume the same amount of 4084 bandwidth as RTP packets, summed across all media streams. Of 4085 course, STUN has retransmits, and the desire is to pace those as 4086 well. For this reason, RTO is set such that the first retransmit on 4087 the first transaction happens just as the first STUN request on the 4088 last transaction occurs. Pictorially: 4090 First Packets Retransmits 4092 | | 4093 | | 4094 -------+------ -------+------ 4095 / \ / \ 4096 / \ / \ 4098 +--+ +--+ +--+ +--+ +--+ +--+ 4099 |A1| |B1| |C1| |A2| |B2| |C2| 4100 +--+ +--+ +--+ +--+ +--+ +--+ 4102 ---+-------+-------+-------+-------+-------+------------ Time 4103 0 Ta 2Ta 3Ta 4Ta 5Ta 4105 In this picture, there are three transactions that will be sent (for 4106 example, in the case of candidate gathering, there are three host 4107 candidate/STUN server pairs). These are transactions A, B, and C. 4108 The retransmit timer is set so that the first retransmission on the 4109 first transaction (packet A2) is sent at time 3Ta. 4111 Subsequent retransmits after the first will occur even less 4112 frequently than Ta milliseconds apart, since STUN uses an exponential 4113 back-off on its retransmissions. 4115 B.2. Candidates with Multiple Bases 4117 Section 4.1.3 talks about eliminating candidates that have the same 4118 transport address and base. However, candidates with the same 4119 transport addresses but different bases are not redundant. When can 4120 an agent have two candidates that have the same IP address and port, 4121 but different bases? Consider the topology of Figure 11: 4123 +----------+ 4124 | STUN Srvr| 4125 +----------+ 4126 | 4127 | 4128 ----- 4129 // \\ 4130 | | 4131 | B:net10 | 4132 | | 4133 \\ // 4134 ----- 4135 | 4136 | 4137 +----------+ 4138 | NAT | 4139 +----------+ 4140 | 4141 | 4142 ----- 4143 // \\ 4144 | A | 4145 |192.168/16 | 4146 | | 4147 \\ // 4148 ----- 4149 | 4150 | 4151 |192.168.1.100 ----- 4152 +----------+ // \\ +----------+ 4153 | | | | | | 4154 | Initiator|---------| C:net10 |-----------| Responder| 4155 | |10.0.1.100| | 10.0.1.101 | | 4156 +----------+ \\ // +----------+ 4157 ----- 4159 Figure 11: Identical Candidates with Different Bases 4161 In this case, the initiating agent is multihomed. It has one IP 4162 address, 10.0.1.100, on network C, which is a net 10 private network. 4163 The responding agent is on this same network. The initiating agent 4164 is also connected to network A, which is 192.168/16 and has an IP 4165 address of 192.168.1.100 on this network. There is a NAT on this 4166 network, natting into network B, which is another net 10 private 4167 network, but not connected to network C. There is a STUN server on 4168 network B. 4170 The initiating agent obtains a host candidate on its IP address on 4171 network C (10.0.1.100:2498) and a host candidate on its IP address on 4172 network A (192.168.1.100:3344). It performs a STUN query to its 4173 configured STUN server from 192.168.1.100:3344. This query passes 4174 through the NAT, which happens to assign the binding 10.0.1.100:2498. 4175 The STUN server reflects this in the STUN Binding response. Now, the 4176 initiating agent has obtained a server reflexive candidate with a 4177 transport address that is identical to a host candidate 4178 (10.0.1.100:2498). However, the server reflexive candidate has a 4179 base of 192.168.1.100:3344, and the host candidate has a base of 4180 10.0.1.100:2498. 4182 B.3. Purpose of the Related Address and Related Port Attributes 4184 The candidate attribute contains two values that are not used at all 4185 by ICE itself -- related address and related port. Why are they 4186 present? 4188 There are two motivations for its inclusion. The first is 4189 diagnostic. It is very useful to know the relationship between the 4190 different types of candidates. By including it, an agent can know 4191 which relayed candidate is associated with which reflexive candidate, 4192 which in turn is associated with a specific host candidate. When 4193 checks for one candidate succeed and not for others, this provides 4194 useful diagnostics on what is going on in the network. 4196 The second reason has to do with off-path Quality of Service (QoS) 4197 mechanisms. When ICE is used in environments such as PacketCable 4198 2.0, proxies will, in addition to performing normal SIP operations, 4199 inspect the SDP in SIP messages, and extract the IP address and port 4200 for media traffic. They can then interact, through policy servers, 4201 with access routers in the network, to establish guaranteed QoS for 4202 the media flows. This QoS is provided by classifying the RTP traffic 4203 based on 5-tuple, and then providing it a guaranteed rate, or marking 4204 its Diffserv codepoints appropriately. When a residential NAT is 4205 present, and a relayed candidate gets selected for media, this 4206 relayed candidate will be a transport address on an actual TURN 4207 server. That address says nothing about the actual transport address 4208 in the access router that would be used to classify packets for QoS 4209 treatment. Rather, the server reflexive candidate towards the TURN 4210 server is needed. By carrying the translation in the SDP, the proxy 4211 can use that transport address to request QoS from the access router. 4213 B.4. Importance of the STUN Username 4215 ICE requires the usage of message integrity with STUN using its 4216 short-term credential functionality. The actual short-term 4217 credential is formed by exchanging username fragments in the 4218 candidate exchange. The need for this mechanism goes beyond just 4219 security; it is actually required for correct operation of ICE in the 4220 first place. 4222 Consider agents L, R, and Z. L and R are within private enterprise 4223 1, which is using 10.0.0.0/8. Z is within private enterprise 2, 4224 which is also using 10.0.0.0/8. As it turns out, R and Z both have 4225 IP address 10.0.1.1. L sends candidates to Z. Z, in responds L with 4226 its host candidates. In this case, those candidates are 4227 10.0.1.1:8866 and 10.0.1.1:8877. As it turns out, R is in a session 4228 at that same time, and is also using 10.0.1.1:8866 and 10.0.1.1:8877 4229 as host candidates. This means that R is prepared to accept STUN 4230 messages on those ports, just as Z is. L will send a STUN request to 4231 10.0.1.1:8866 and another to 10.0.1.1:8877. However, these do not go 4232 to Z as expected. Instead, they go to R! If R just replied to them, 4233 L would believe it has connectivity to Z, when in fact it has 4234 connectivity to a completely different user, R. To fix this, the 4235 STUN short-term credential mechanisms are used. The username 4236 fragments are sufficiently random that it is highly unlikely that R 4237 would be using the same values as Z. Consequently, R would reject 4238 the STUN request since the credentials were invalid. In essence, the 4239 STUN username fragments provide a form of transient host identifiers, 4240 bound to a particular session established as part of the candidate 4241 exchange. 4243 An unfortunate consequence of the non-uniqueness of IP addresses is 4244 that, in the above example, R might not even be an ICE agent. It 4245 could be any host, and the port to which the STUN packet is directed 4246 could be any ephemeral port on that host. If there is an application 4247 listening on this socket for packets, and it is not prepared to 4248 handle malformed packets for whatever protocol is in use, the 4249 operation of that application could be affected. Fortunately, since 4250 the ports exchanged are ephemeral and usually drawn from the dynamic 4251 or registered range, the odds are good that the port is not used to 4252 run a server on host R, but rather is the agent side of some 4253 protocol. This decreases the probability of hitting an allocated 4254 port, due to the transient nature of port usage in this range. 4255 However, the possibility of a problem does exist, and network 4256 deployers should be prepared for it. Note that this is not a problem 4257 specific to ICE; stray packets can arrive at a port at any time for 4258 any type of protocol, especially ones on the public Internet. As 4259 such, this requirement is just restating a general design guideline 4260 for Internet applications -- be prepared for unknown packets on any 4261 port. 4263 B.5. The Candidate Pair Priority Formula 4265 The priority for a candidate pair has an odd form. It is: 4267 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 4269 Why is this? When the candidate pairs are sorted based on this 4270 value, the resulting sorting has the MAX/MIN property. This means 4271 that the pairs are first sorted based on decreasing value of the 4272 minimum of the two priorities. For pairs that have the same value of 4273 the minimum priority, the maximum priority is used to sort amongst 4274 them. If the max and the min priorities are the same, the 4275 controlling agent's priority is used as the tie-breaker in the last 4276 part of the expression. The factor of 2*32 is used since the 4277 priority of a single candidate is always less than 2*32, resulting in 4278 the pair priority being a "concatenation" of the two component 4279 priorities. This creates the MAX/MIN sorting. MAX/MIN ensures that, 4280 for a particular agent, a lower-priority candidate is never used 4281 until all higher-priority candidates have been tried. 4283 B.6. Why Are Keepalives Needed? 4285 Once media begins flowing on a candidate pair, it is still necessary 4286 to keep the bindings alive at intermediate NATs for the duration of 4287 the session. Normally, the media stream packets themselves (e.g., 4288 RTP) meet this objective. However, several cases merit further 4289 discussion. Firstly, in some RTP usages, such as SIP, the media 4290 streams can be "put on hold". This is accomplished by using the SDP 4291 "sendonly" or "inactive" attributes, as defined in RFC 3264 4292 [RFC3264]. RFC 3264 directs implementations to cease transmission of 4293 media in these cases. However, doing so may cause NAT bindings to 4294 timeout, and media won't be able to come off hold. 4296 Secondly, some RTP payload formats, such as the payload format for 4297 text conversation [RFC4103], may send packets so infrequently that 4298 the interval exceeds the NAT binding timeouts. 4300 Thirdly, if silence suppression is in use, long periods of silence 4301 may cause media transmission to cease sufficiently long for NAT 4302 bindings to time out. 4304 For these reasons, the media packets themselves cannot be relied 4305 upon. ICE defines a simple periodic keepalive utilizing STUN Binding 4306 indications. This makes its bandwidth requirements highly 4307 predictable, and thus amenable to QoS reservations. 4309 B.7. Why Prefer Peer Reflexive Candidates? 4311 Section 4.1.2 describes procedures for computing the priority of 4312 candidate based on its type and local preferences. That section 4313 requires that the type preference for peer reflexive candidates 4314 always be higher than server reflexive. Why is that? The reason has 4315 to do with the security considerations in Section 15. It is much 4316 easier for an attacker to cause an agent to use a false server 4317 reflexive candidate than it is for an attacker to cause an agent to 4318 use a false peer reflexive candidate. Consequently, attacks against 4319 address gathering with Binding requests are thwarted by ICE by 4320 preferring the peer reflexive candidates. 4322 B.8. Why Are Binding Indications Used for Keepalives? 4324 Media keepalives are described in Section 10. These keepalives make 4325 use of STUN when both endpoints are ICE capable. However, rather 4326 than using a Binding request transaction (which generates a 4327 response), the keepalives use an Indication. Why is that? 4329 The primary reason has to do with network QoS mechanisms. Once media 4330 begins flowing, network elements will assume that the media stream 4331 has a fairly regular structure, making use of periodic packets at 4332 fixed intervals, with the possibility of jitter. If an agent is 4333 sending media packets, and then receives a Binding request, it would 4334 need to generate a response packet along with its media packets. 4335 This will increase the actual bandwidth requirements for the 5-tuple 4336 carrying the media packets, and introduce jitter in the delivery of 4337 those packets. Analysis has shown that this is a concern in certain 4338 layer 2 access networks that use fairly tight packet schedulers for 4339 media. 4341 Additionally, using a Binding Indication allows integrity to be 4342 disabled, allowing for better performance. This is useful for large- 4343 scale endpoints, such as PSTN gateways and SBCs. 4345 Appendix C. Connectivity Check Bandwidth 4347 The tables below show, for IPv4 and IPv6, the bandwidth required for 4348 performing connectivity checks, using different Ta values (given in 4349 ms) and different ufrag sizes (given in bytes). 4351 The results were provided by Jusin Uberti (Google) 11th April 2016. 4353 IP version: IPv4 4354 Packet len (bytes): 108 + ufrag 4355 | 4356 ms | 4 8 12 16 4357 -----|------------------------ 4358 500 | 1.86k 1.98k 2.11k 2.24k 4359 200 | 4.64k 4.96k 5.28k 5.6k 4360 100 | 9.28k 9.92k 10.6k 11.2k 4361 50 | 18.6k 19.8k 21.1k 22.4k 4362 20 | 46.4k 49.6k 52.8k 56.0k 4363 10 | 92.8k 99.2k 105k 112k 4364 5 | 185k 198k 211k 224k 4365 2 | 464k 496k 528k 560k 4366 1 | 928k 992k 1.06M 1.12M 4368 IP version: IPv6 4369 Packet len (bytes): 128 + ufrag 4370 | 4371 ms | 4 8 12 16 4372 -----|------------------------ 4373 500 | 2.18k 2.3k 2.43k 2.56k 4374 200 | 5.44k 5.76k 6.08k 6.4k 4375 100 | 10.9k 11.5k 12.2k 12.8k 4376 50 | 21.8k 23.0k 24.3k 25.6k 4377 20 | 54.4k 57.6k 60.8k 64.0k 4378 10 | 108k 115k 121k 128k 4379 5 | 217k 230k 243k 256k 4380 2 | 544k 576k 608k 640k 4381 1 | 1.09M 1.15M 1.22M 1.28M 4383 Figure 12: Connectivity Check Bandwidth 4385 Authors' Addresses 4387 Ari Keranen 4388 Ericsson 4389 Hirsalantie 11 4390 02420 Jorvas 4391 Finland 4393 Email: ari.keranen@ericsson.com 4394 Christer Holmberg 4395 Ericsson 4396 Hirsalantie 11 4397 02420 Jorvas 4398 Finland 4400 Email: christer.holmberg@ericsson.com 4402 Jonathan Rosenberg 4403 jdrosen.net 4404 Monmouth, NJ 4405 US 4407 Email: jdrosen@jdrosen.net 4408 URI: http://www.jdrosen.net