idnits 2.17.1 draft-ietf-mmusic-rfc5245bis-05.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 15 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 == 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 (September 10, 2015) is 3151 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 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-06 == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-07 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC A. Keranen 3 Internet-Draft Ericsson 4 Obsoletes: 5245 (if approved) J. Rosenberg 5 Intended status: Standards Track jdrosen.net 6 Expires: March 13, 2016 September 10, 2015 8 Interactive Connectivity Establishment (ICE): A Protocol for Network 9 Address Translator (NAT) Traversal 10 draft-ietf-mmusic-rfc5245bis-05 12 Abstract 14 This document describes a protocol for Network Address Translator 15 (NAT) traversal for UDP-based multimedia. This protocol is called 16 Interactive Connectivity Establishment (ICE). ICE makes use of the 17 Session Traversal Utilities for NAT (STUN) protocol and its 18 extension, Traversal Using Relay NAT (TURN). 20 This document obsoletes RFC 5245. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 13, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 8 71 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10 72 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 11 73 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 12 74 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 13 75 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 13 76 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 15 77 2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 15 78 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19 80 4.1. Full Implementation Requirements . . . . . . . . . . . . 19 81 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 82 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19 83 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 84 4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 22 85 4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22 86 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 23 87 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 23 88 4.1.2.2. Guidelines for Choosing Type and Local 89 Preferences . . . . . . . . . . . . . . . . . . . 24 90 4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 25 91 4.2. Lite Implementation Requirements . . . . . . . . . . . . 25 92 4.3. Encoding the Offer . . . . . . . . . . . . . . . . . . . 26 93 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 28 94 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28 95 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 29 96 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 30 97 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 30 98 5.5. Encoding the Answer . . . . . . . . . . . . . . . . . . . 30 99 5.6. Forming the Check Lists . . . . . . . . . . . . . . . . . 30 100 5.6.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 30 101 5.6.2. Computing Pair Priority and Ordering Pairs . . . . . 33 102 5.6.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 33 103 5.6.4. Computing States . . . . . . . . . . . . . . . . . . 33 104 5.7. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 36 105 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 38 106 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 38 107 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 38 108 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 38 109 6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 38 110 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 38 111 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 39 112 7.1.1. Creating Permissions for Relayed Candidates . . . . . 39 113 7.1.2. Sending the Request . . . . . . . . . . . . . . . . . 39 114 7.1.2.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 39 115 7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 40 116 7.1.2.3. Forming Credentials . . . . . . . . . . . . . . . 40 117 7.1.2.4. DiffServ Treatment . . . . . . . . . . . . . . . 40 118 7.1.3. Processing the Response . . . . . . . . . . . . . . . 40 119 7.1.3.1. Failure Cases . . . . . . . . . . . . . . . . . . 41 120 7.1.3.2. Success Cases . . . . . . . . . . . . . . . . . . 41 121 7.1.3.2.1. Discovering Peer Reflexive Candidates . . . . 42 122 7.1.3.2.2. Constructing a Valid Pair . . . . . . . . . . 42 123 7.1.3.2.3. Updating Pair States . . . . . . . . . . . . 43 124 7.1.3.2.4. Updating the Nominated Flag . . . . . . . . . 44 125 7.1.3.3. Check List and Timer State Updates . . . . . . . 44 126 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 45 127 7.2.1. Additional Procedures for Full Implementations . . . 46 128 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 46 129 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 47 130 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 47 131 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 48 132 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 49 133 7.2.2. Additional Procedures for Lite Implementations . . . 49 134 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 50 135 8.1. Procedures for Full Implementations . . . . . . . . . . . 50 136 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 50 137 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 50 138 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 51 139 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 51 140 8.2. Procedures for Lite Implementations . . . . . . . . . . . 53 141 8.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . 53 142 8.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . 53 143 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 54 144 8.3.1. Full Implementation Procedures . . . . . . . . . . . 54 145 8.3.2. Lite Implementation Procedures . . . . . . . . . . . 54 146 9. ICE Restarts . . . . . . . . . . . . . . . . . . . . . . . . 54 147 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 55 148 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 56 149 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 56 150 11.1.1. Procedures for Full Implementations . . . . . . . . 56 151 11.1.2. Procedures for Lite Implementations . . . . . . . . 57 152 11.1.3. Procedures for All Implementations . . . . . . . . . 57 153 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 57 154 12. Extensibility Considerations . . . . . . . . . . . . . . . . 58 155 13. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 59 156 13.1. Real-time Media Streams . . . . . . . . . . . . . . . . 59 157 13.2. Non-real-time Sessions . . . . . . . . . . . . . . . . . 61 158 14. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 159 15. Security Considerations . . . . . . . . . . . . . . . . . . . 66 160 15.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 66 161 15.2. Attacks on Server Reflexive Address Gathering . . . . . 69 162 15.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 70 163 15.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . 70 164 15.4.1. STUN Amplification Attack . . . . . . . . . . . . . 70 165 16. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 71 166 16.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 71 167 16.2. New Error Response Codes . . . . . . . . . . . . . . . . 72 168 17. Operational Considerations . . . . . . . . . . . . . . . . . 72 169 17.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 72 170 17.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 72 171 17.2.1. STUN and TURN Server Capacity Planning . . . . . . . 72 172 17.2.2. Gathering and Connectivity Checks . . . . . . . . . 73 173 17.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 73 174 17.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 74 175 17.4. Troubleshooting and Performance Management . . . . . . . 74 176 17.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 74 177 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 178 18.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 75 179 18.2. STUN Error Responses . . . . . . . . . . . . . . . . . . 75 180 19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75 181 19.1. Problem Definition . . . . . . . . . . . . . . . . . . . 75 182 19.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 76 183 19.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 76 184 19.4. Requirements for a Long-Term Solution . . . . . . . . . 77 185 19.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 78 186 20. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 78 187 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 188 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 189 22.1. Normative References . . . . . . . . . . . . . . . . . . 79 190 22.2. Informative References . . . . . . . . . . . . . . . . . 79 191 Appendix A. Lite and Full Implementations . . . . . . . . . . . 83 192 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 84 193 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 84 194 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 85 195 B.3. Purpose of the Related Address and Related Port 196 Attributes . . . . . . . . . . . . . . . . . . . . . . . 87 197 B.4. Importance of the STUN Username . . . . . . . . . . . . . 88 198 B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 89 199 B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 89 200 B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 90 201 B.8. Why Are Binding Indications Used for Keepalives? . . . . 90 202 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 204 1. Introduction 206 Protocols establishing multimedia sessions between peers typically 207 involve exchanging IP addresses and ports for the media sources and 208 sinks. However this poses challenges when operated through Network 209 Address Translators (NATs) [RFC3235]. These protocols also seek to 210 create a media flow directly between participants, so that there is 211 no application layer intermediary between them. This is done to 212 reduce media latency, decrease packet loss, and reduce the 213 operational costs of deploying the application. However, this is 214 difficult to accomplish through NAT. A full treatment of the reasons 215 for this is beyond the scope of this specification. 217 Numerous solutions have been defined for allowing these protocols to 218 operate through NAT. These include Application Layer Gateways 219 (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple 220 Traversal of UDP Through NAT (STUN) [RFC3489] specification, and 221 Realm Specific IP [RFC3102] [RFC3103] along with session description 222 extensions needed to make them work, such as the Session Description 223 Protocol (SDP) [RFC4566] attribute for the Real Time Control Protocol 224 (RTCP) [RFC3605]. Unfortunately, these techniques all have pros and 225 cons which, make each one optimal in some network topologies, but a 226 poor choice in others. The result is that administrators and 227 implementors are making assumptions about the topologies of the 228 networks in which their solutions will be deployed. This introduces 229 complexity and brittleness into the system. What is needed is a 230 single solution that is flexible enough to work well in all 231 situations. 233 This specification defines Interactive Connectivity Establishment 234 (ICE) as a technique for NAT traversal for UDP-based media streams 235 (though ICE has been extended to handle other transport protocols, 236 such as TCP [RFC6544]) established by the offer/answer model. ICE is 237 an extension to the offer/answer model, and works by including a 238 multiplicity of IP addresses and ports in the offers and answers, 239 which are then tested for connectivity by peer-to-peer connectivity 240 checks. The IP addresses and ports included in the offer and answer 241 and the connectivity checks are performed using Session Traversal 242 Utilities for NAT (STUN) specification [RFC5389]. ICE also makes use 243 of Traversal Using Relays around NAT (TURN) [RFC5766], an extension 244 to STUN. Because ICE exchanges a multiplicity of IP addresses and 245 ports for each media stream, it also allows for address selection for 246 multihomed and dual-stack hosts, and for this reason it deprecates 247 [RFC4091] and [RFC4092]. 249 2. Overview of ICE 251 In a typical ICE deployment, we have two endpoints (known as AGENTS 252 in RFC 3264 terminology) that want to communicate. They are able to 253 communicate indirectly via some signaling protocol (such as SIP), by 254 which they can perform an offer/answer exchange. Note that ICE is 255 not intended for NAT traversal for the signaling protocol, which is 256 assumed to be provided via another mechanism. At the beginning of 257 the ICE process, the agents are ignorant of their own topologies. In 258 particular, they might or might not be behind a NAT (or multiple 259 tiers of NATs). ICE allows the agents to discover enough information 260 about their topologies to potentially find one or more paths by which 261 they can communicate. 263 Figure 1 shows a typical environment for ICE deployment. The two 264 endpoints are labelled L and R (for left and right, which helps 265 visualize call flows). Both L and R are behind their own respective 266 NATs though they may not be aware of it. The type of NAT and its 267 properties are also unknown. Agents L and R are capable of engaging 268 in an offer/answer exchange, whose purpose is to set up a media 269 session between L and R. Typically, this exchange will occur through 270 a signaling (e.g., SIP) server. 272 In addition to the agents, a signaling server and NATs, ICE is 273 typically used in concert with STUN or TURN servers in the network. 274 Each agent can have its own STUN or TURN server, or they can be the 275 same. 277 +---------+ 278 +--------+ |Signaling| +--------+ 279 | STUN | |Server | | STUN | 280 | Server | +---------+ | Server | 281 +--------+ / \ +--------+ 282 / \ 283 / \ 284 / <- Signaling -> \ 285 / \ 286 +--------+ +--------+ 287 | NAT | | NAT | 288 +--------+ +--------+ 289 / \ 290 / \ 291 +-------+ +-------+ 292 | Agent | | Agent | 293 | L | | R | 294 +-------+ +-------+ 296 Figure 1: ICE Deployment Scenario 298 The basic idea behind ICE is as follows: each agent has a variety of 299 candidate TRANSPORT ADDRESSES (combination of IP address and port for 300 a particular transport protocol, which is always UDP in this 301 specification) it could use to communicate with the other agent. 302 These might include: 304 o A transport address on a directly attached network interface 306 o A translated transport address on the public side of a NAT (a 307 "server reflexive" address) 309 o A transport address allocated from a TURN server (a "relayed 310 address") 312 Potentially, any of L's candidate transport addresses can be used to 313 communicate with any of R's candidate transport addresses. In 314 practice, however, many combinations will not work. For instance, if 315 L and R are both behind NATs, their directly attached interface 316 addresses are unlikely to be able to communicate directly (this is 317 why ICE is needed, after all!). The purpose of ICE is to discover 318 which pairs of addresses will work. The way that ICE does this is to 319 systematically try all possible pairs (in a carefully sorted order) 320 until it finds one or more that work. 322 2.1. Gathering Candidate Addresses 324 In order to execute ICE, an agent has to identify all of its address 325 candidates. A CANDIDATE is a transport address -- a combination of 326 IP address and port for a particular transport protocol (with only 327 UDP specified here). This document defines three types of 328 candidates, some derived from physical or logical network interfaces, 329 others discoverable via STUN and TURN. Naturally, one viable 330 candidate is a transport address obtained directly from a local 331 interface. Such a candidate is called a HOST CANDIDATE. The local 332 interface could be Ethernet or WiFi, or it could be one that is 333 obtained through a tunnel mechanism, such as a Virtual Private 334 Network (VPN) or Mobile IP (MIP). In all cases, such a network 335 interface appears to the agent as a local interface from which ports 336 (and thus candidates) can be allocated. 338 If an agent is multihomed, it obtains a candidate from each IP 339 address. Depending on the location of the PEER (the other agent in 340 the session) on the IP network relative to the agent, the agent may 341 be reachable by the peer through one or more of those IP addresses. 342 Consider, for example, an agent that has a local IP address on a 343 private net 10 network (I1), and a second connected to the public 344 Internet (I2). A candidate from I1 will be directly reachable when 345 communicating with a peer on the same private net 10 network, while a 346 candidate from I2 will be directly reachable when communicating with 347 a peer on the public Internet. Rather than trying to guess which IP 348 address will work prior to sending an offer, the offering agent 349 includes both candidates in its offer. 351 Next, the agent uses STUN or TURN to obtain additional candidates. 352 These come in two flavors: translated addresses on the public side of 353 a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers 354 (RELAYED CANDIDATES). When TURN servers are utilized, both types of 355 candidates are obtained from the TURN server. If only STUN servers 356 are utilized, only server reflexive candidates are obtained from 357 them. The relationship of these candidates to the host candidate is 358 shown in Figure 2. In this figure, both types of candidates are 359 discovered using TURN. In the figure, the notation X:x means IP 360 address X and UDP port x. 362 To Internet 364 | 365 | 366 | /------------ Relayed 367 Y:y | / Address 368 +--------+ 369 | | 370 | TURN | 371 | Server | 372 | | 373 +--------+ 374 | 375 | 376 | /------------ Server 377 X1':x1'|/ Reflexive 378 +------------+ Address 379 | NAT | 380 +------------+ 381 | 382 | /------------ Local 383 X:x |/ Address 384 +--------+ 385 | | 386 | Agent | 387 | | 388 +--------+ 390 Figure 2: Candidate Relationships 392 When the agent sends the TURN Allocate request from IP address and 393 port X:x, the NAT (assuming there is one) will create a binding 394 X1':x1', mapping this server reflexive candidate to the host 395 candidate X:x. Outgoing packets sent from the host candidate will be 396 translated by the NAT to the server reflexive candidate. Incoming 397 packets sent to the server reflexive candidate will be translated by 398 the NAT to the host candidate and forwarded to the agent. We call 399 the host candidate associated with a given server reflexive candidate 400 the BASE. 402 Note: "Base" refers to the address an agent sends from for a 403 particular candidate. Thus, as a degenerate case host candidates 404 also have a base, but it's the same as the host candidate. 406 When there are multiple NATs between the agent and the TURN server, 407 the TURN request will create a binding on each NAT, but only the 408 outermost server reflexive candidate (the one nearest the TURN 409 server) will be discovered by the agent. If the agent is not behind 410 a NAT, then the base candidate will be the same as the server 411 reflexive candidate and the server reflexive candidate is redundant 412 and will be eliminated. 414 The Allocate request then arrives at the TURN server. The TURN 415 server allocates a port y from its local IP address Y, and generates 416 an Allocate response, informing the agent of this relayed candidate. 417 The TURN server also informs the agent of the server reflexive 418 candidate, X1':x1' by copying the source transport address of the 419 Allocate request into the Allocate response. The TURN server acts as 420 a packet relay, forwarding traffic between L and R. In order to send 421 traffic to L, R sends traffic to the TURN server at Y:y, and the TURN 422 server forwards that to X1':x1', which passes through the NAT where 423 it is mapped to X:x and delivered to L. 425 When only STUN servers are utilized, the agent sends a STUN Binding 426 request [RFC5389] to its STUN server. The STUN server will inform 427 the agent of the server reflexive candidate X1':x1' by copying the 428 source transport address of the Binding request into the Binding 429 response. 431 2.2. Connectivity Checks 433 Once L has gathered all of its candidates, it orders them in highest 434 to lowest-priority and sends them to R over the signaling channel. 435 The candidates are carried in attributes in the offer. When R 436 receives the offer, it performs the same gathering process and 437 responds with its own list of candidates. At the end of this 438 process, each agent has a complete list of both its candidates and 439 its peer's candidates. It pairs them up, resulting in CANDIDATE 440 PAIRS. To see which pairs work, each agent schedules a series of 441 CHECKS. Each check is a STUN request/response transaction that the 442 client will perform on a particular candidate pair by sending a STUN 443 request from the local candidate to the remote candidate. 445 The basic principle of the connectivity checks is simple: 447 1. Sort the candidate pairs in priority order. 449 2. Send checks on each candidate pair in priority order. 451 3. Acknowledge checks received from the other agent. 453 With both agents performing a check on a candidate pair, the result 454 is a 4-way handshake: 456 L R 457 - - 458 STUN request -> \ L's 459 <- STUN response / check 461 <- STUN request \ R's 462 STUN response -> / check 464 Figure 3: Basic Connectivity Check 466 It is important to note that the STUN requests are sent to and from 467 the exact same IP addresses and ports that will be used for media 468 (e.g., RTP and RTCP). Consequently, agents demultiplex STUN and RTP/ 469 RTCP using contents of the packets, rather than the port on which 470 they are received. Fortunately, this demultiplexing is easy to do, 471 especially for RTP and RTCP. 473 Because a STUN Binding request is used for the connectivity check, 474 the STUN Binding response will contain the agent's translated 475 transport address on the public side of any NATs between the agent 476 and its peer. If this transport address is different from other 477 candidates the agent already learned, it represents a new candidate, 478 called a PEER REFLEXIVE CANDIDATE, which then gets tested by ICE just 479 the same as any other candidate. 481 As an optimization, as soon as R gets L's check message, R schedules 482 a connectivity check message to be sent to L on the same candidate 483 pair. This accelerates the process of finding a valid candidate, and 484 is called a TRIGGERED CHECK. 486 At the end of this handshake, both L and R know that they can send 487 (and receive) messages end-to-end in both directions. 489 2.3. Sorting Candidates 491 Because the algorithm above searches all candidate pairs, if a 492 working pair exists it will eventually find it no matter what order 493 the candidates are tried in. In order to produce faster (and better) 494 results, the candidates are sorted in a specified order. The 495 resulting list of sorted candidate pairs is called the CHECK LIST. 496 The algorithm is described in Section 4.1.2 but follows two general 497 principles: 499 o Each agent gives its candidates a numeric priority, which is sent 500 along with the candidate to the peer. 502 o The local and remote priorities are combined so that each agent 503 has the same ordering for the candidate pairs. 505 The second property is important for getting ICE to work when there 506 are NATs in front of L and R. Frequently, NATs will not allow 507 packets in from a host until the agent behind the NAT has sent a 508 packet towards that host. Consequently, ICE checks in each direction 509 will not succeed until both sides have sent a check through their 510 respective NATs. 512 The agent works through this check list by sending a STUN request for 513 the next candidate pair on the list periodically. These are called 514 ORDINARY CHECKS. 516 In general, the priority algorithm is designed so that candidates of 517 similar type get similar priorities and so that more direct routes 518 (that is, through fewer media relays and through fewer NATs) are 519 preferred over indirect ones (ones with more media relays and more 520 NATs). Within those guidelines, however, agents have a fair amount 521 of discretion about how to tune their algorithms. 523 2.4. Frozen Candidates 525 The previous description only addresses the case where the agents 526 wish to establish a media session with one COMPONENT (a piece of a 527 media stream requiring a single transport address; a media stream may 528 require multiple components, each of which has to work for the media 529 stream as a whole to be work). Often (e.g., with RTP and RTCP), the 530 agents actually need to establish connectivity for more than one 531 flow. 533 The network properties are likely to be very similar for each 534 component (especially because RTP and RTCP are sent and received from 535 the same IP address). It is usually possible to leverage information 536 from one media component in order to determine the best candidates 537 for another. ICE does this with a mechanism called "frozen 538 candidates". 540 Each candidate is associated with a property called its FOUNDATION. 541 Two candidates have the same foundation when they are "similar" -- of 542 the same type and obtained from the same host candidate and STUN/TURN 543 server using the same protocol. Otherwise, their foundation is 544 different. A candidate pair has a foundation too, which is just the 545 concatenation of the foundations of its two candidates. Initially, 546 only the candidate pairs with unique foundations are tested. The 547 other candidate pairs are marked "frozen". When the connectivity 548 checks for a candidate pair succeed, the other candidate pairs with 549 the same foundation are unfrozen. This avoids repeated checking of 550 components that are superficially more attractive but in fact are 551 likely to fail. 553 While we've described "frozen" here as a separate mechanism for 554 expository purposes, in fact it is an integral part of ICE and the 555 ICE prioritization algorithm automatically ensures that the right 556 candidates are unfrozen and checked in the right order. However, if 557 the ICE usage does not utilize multiple components or media streams, 558 it does not need to implement this algorithm. 560 2.5. Security for Checks 562 Because ICE is used to discover which addresses can be used to send 563 media between two agents, it is important to ensure that the process 564 cannot be hijacked to send media to the wrong location. Each STUN 565 connectivity check is covered by a message authentication code (MAC) 566 computed using a key exchanged in the signaling channel. This MAC 567 provides message integrity and data origin authentication, thus 568 stopping an attacker from forging or modifying connectivity check 569 messages. Furthermore, if for example a SIP [RFC3261] caller is 570 using ICE, and their call forks, the ICE exchanges happen 571 independently with each forked recipient. In such a case, the keys 572 exchanged in the signaling help associate each ICE exchange with each 573 forked recipient. 575 2.6. Concluding ICE 577 ICE checks are performed in a specific sequence, so that high- 578 priority candidate pairs are checked first, followed by lower- 579 priority ones. One way to conclude ICE is to declare victory as soon 580 as a check for each component of each media stream completes 581 successfully. Indeed, this is a reasonable algorithm, and details 582 for it are provided below. However, it is possible that a packet 583 loss will cause a higher-priority check to take longer to complete. 584 In that case, allowing ICE to run a little longer might produce 585 better results. More fundamentally, however, the prioritization 586 defined by this specification may not yield "optimal" results. As an 587 example, if the aim is to select low-latency media paths, usage of a 588 relay is a hint that latencies may be higher, but it is nothing more 589 than a hint. An actual round-trip time (RTT) measurement could be 590 made, and it might demonstrate that a pair with lower priority is 591 actually better than one with higher priority. 593 Consequently, ICE assigns one of the agents in the role of the 594 CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The 595 controlling agent gets to nominate which candidate pairs will get 596 used for media amongst the ones that are valid. It can do this in 597 one of two ways -- using REGULAR NOMINATION or AGGRESSIVE NOMINATION. 599 With regular nomination, the controlling agent lets the checks 600 continue until at least one valid candidate pair for each media 601 stream is found. Then, it picks amongst those that are valid, and 602 sends a second STUN request on its NOMINATED candidate pair, but this 603 time with a flag set to tell the peer that this pair has been 604 nominated for use. This is shown in Figure 4. 606 L R 607 - - 608 STUN request -> \ L's 609 <- STUN response / check 611 <- STUN request \ R's 612 STUN response -> / check 614 STUN request + flag -> \ L's 615 <- STUN response / check 617 Figure 4: Regular Nomination 619 Once the STUN transaction with the flag completes, both sides cancel 620 any future checks for that media stream. ICE will now send media 621 using this pair. The pair an ICE agent is using for media is called 622 the SELECTED PAIR. 624 In aggressive nomination, the controlling agent puts the flag in 625 every connectivity check STUN request it sends. This way, once the 626 first check succeeds, ICE processing is complete for that media 627 stream and the controlling agent doesn't have to send a second STUN 628 request. The selected pair will be the highest-priority valid pair 629 whose check succeeded. Aggressive nomination is faster than regular 630 nomination, but gives less flexibility. Aggressive nomination is 631 shown in Figure 5. 633 L R 634 - - 635 STUN request + flag -> \ L's 636 <- STUN response / check 638 <- STUN request \ R's 639 STUN response -> / check 641 Figure 5: Aggressive Nomination 643 Once ICE is concluded, it can be restarted at any time for one or all 644 of the media streams by either agent. This is done by sending an 645 updated offer indicating a restart. 647 2.7. Lite Implementations 649 In order for ICE to be used in a call, both agents need to support 650 it. However, certain agents will always be connected to the public 651 Internet and have a public IP address at which it can receive packets 652 from any correspondent. To make it easier for these devices to 653 support ICE, ICE defines a special type of implementation called LITE 654 (in contrast to the normal FULL implementation). A lite 655 implementation doesn't gather candidates; it includes only host 656 candidates for any media stream. Lite agents do not generate 657 connectivity checks or run the state machines, though they need to be 658 able to respond to connectivity checks. When a lite implementation 659 connects with a full implementation, the full agent takes the role of 660 the controlling agent, and the lite agent takes on the controlled 661 role. When two lite implementations connect, no checks are sent. 663 For guidance on when a lite implementation is appropriate, see the 664 discussion in Appendix A. 666 It is important to note that the lite implementation was added to 667 this specification to provide a stepping stone to full 668 implementation. Even for devices that are always connected to the 669 public Internet, a full implementation is preferable if achievable. 671 2.8. Usages of ICE 673 This document specifies generic use of ICE with protocols that 674 provide offer/answer semantics. The specific details (e.g., how to 675 encode candidates) for different protocols using ICE are described in 676 separate usage documents. For example, usage with SIP and SDP is 677 described in [I-D.ietf-mmusic-ice-sip-sdp]. 679 3. Terminology 681 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 682 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 683 "OPTIONAL" in this document are to be interpreted as described in RFC 684 2119 [RFC2119]. 686 Readers should be familiar with the terminology defined in the offer/ 687 answer model [RFC3264], STUN [RFC5389], and NAT Behavioral 688 requirements for UDP [RFC4787]. 690 This specification makes use of the following additional terminology: 692 Agent: An agent is the protocol implementation involved in the 693 offer/answer exchange. There are two agents involved in an offer/ 694 answer exchange. 696 ICE offer/answer: The process where the ICE agents exchange 697 information (e.g., candidates and passwords) that is needed to 698 perform ICE. RFC 3264 offer/answer with SDP is one example of a 699 protocol that can be used for ICE offer and answer. 701 Peer: From the perspective of one of the agents in a session, its 702 peer is the other agent. Specifically, from the perspective of 703 the offerer, the peer is the answerer. From the perspective of 704 the answerer, the peer is the offerer. 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: A transport address that is a potential point of contact 718 for receipt of media. Candidates also have properties -- their 719 type (server reflexive, relayed, or host), priority, foundation, 720 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, there are two 726 components per media stream -- one for RTP, and one for RTCP. 728 Host Candidate: A candidate obtained by binding to a specific port 729 from an IP address on the host. This includes IP addresses on 730 physical interfaces and logical ones, such as ones obtained 731 through Virtual Private Networks (VPNs) and Realm Specific IP 732 (RSIP) [RFC3102] (which lives at the operating system level). 734 Server Reflexive Candidate: A candidate whose IP address and port 735 are a binding allocated by a NAT for an agent when it sent a 736 packet through the NAT to a server. Server reflexive candidates 737 can be learned by STUN servers using the Binding request, or TURN 738 servers, which provides both a relayed and server reflexive 739 candidate. 741 Peer Reflexive Candidate: A candidate whose IP address and port are 742 a binding allocated by a NAT for an agent when it sent a STUN 743 Binding request through the NAT to its peer. 745 Relayed Candidate: A candidate obtained by sending a TURN Allocate 746 request from a host candidate to a TURN server. The relayed 747 candidate is resident on the TURN server, and the TURN server 748 relays packets back towards the agent. 750 Base: The base of a server reflexive candidate is the host candidate 751 from which it was derived. A host candidate is also said to have 752 a base, equal to that candidate itself. Similarly, the base of a 753 relayed candidate is that candidate itself. 755 Foundation: An arbitrary string that is the same for two candidates 756 that have the same type, base IP address, protocol (UDP, TCP, 757 etc.), and STUN or TURN server. If any of these are different, 758 then the foundation will be different. Two candidate pairs with 759 the same foundation pairs are likely to have similar network 760 characteristics. Foundations are used in the frozen algorithm. 762 Local Candidate: A candidate that an agent has obtained and included 763 in an offer or answer it sent. 765 Remote Candidate: A candidate that an agent received in an offer or 766 answer from its peer. 768 Default Destination/Candidate: The default destination for a 769 component of a media stream is the transport address that would be 770 used by an agent that is not ICE aware. A default candidate for a 771 component is one whose transport address matches the default 772 destination for that component. 774 Candidate Pair: A pairing containing a local candidate and a remote 775 candidate. 777 Check, Connectivity Check, STUN Check: A STUN Binding request 778 transaction for the purposes of verifying connectivity. A check 779 is sent from the local candidate to the remote candidate of a 780 candidate pair. 782 Check List: An ordered set of candidate pairs that an agent will use 783 to generate checks. 785 Ordinary Check: A connectivity check generated by an agent as a 786 consequence of a timer that fires periodically, instructing it to 787 send a check. 789 Triggered Check: A connectivity check generated as a consequence of 790 the receipt of a connectivity check from the peer. 792 Valid List: An ordered set of candidate pairs for a media stream 793 that have been validated by a successful STUN transaction. 795 Full: An ICE implementation that performs the complete set of 796 functionality defined by this specification. 798 Lite: An ICE implementation that omits certain functions, 799 implementing only as much as is necessary for a peer 800 implementation that is full to gain the benefits of ICE. Lite 801 implementations do not maintain any of the state machines and do 802 not generate connectivity checks. 804 Controlling Agent: The ICE agent that is responsible for selecting 805 the final choice of candidate pairs and signaling them through 806 STUN. In any session, one agent is always controlling. The other 807 is the controlled agent. 809 Controlled Agent: An ICE agent that waits for the controlling agent 810 to select the final choice of candidate pairs. 812 Regular Nomination: The process of picking a valid candidate pair 813 for media traffic by validating the pair with one STUN request, 814 and then picking it by sending a second STUN request with a flag 815 indicating its nomination. 817 Aggressive Nomination: The process of picking a valid candidate pair 818 for media traffic by including a flag in every connectivity check 819 STUN request, such that the first one to produce a valid candidate 820 pair is used for media. 822 Nominated: If a valid candidate pair has its nominated flag set, it 823 means that it may be selected by ICE for sending and receiving 824 media. 826 Selected Pair, Selected Candidate: The candidate pair selected by 827 ICE for sending and receiving media is called the selected pair, 828 and each of its candidates is called the selected candidate. 830 Using Protocol, ICE Usage: The protocol that uses ICE for NAT 831 traversal. A usage specification defines the protocol specific 832 details on how the procedures defined here are applied to that 833 protocol. 835 4. Sending the Initial Offer 837 In order to send the initial offer in an offer/answer exchange, an 838 agent must (1) gather candidates, (2) prioritize them, (3) eliminate 839 redundant candidates, (4) (possibly) choose default candidates, and 840 then (5) formulate and send the offer. All but the last of these 841 five steps differ for full and lite implementations. 843 4.1. Full Implementation Requirements 845 4.1.1. Gathering Candidates 847 An agent gathers candidates when it believes that communication is 848 imminent. An offerer can do this based on a user interface cue, or 849 based on an explicit request to initiate a session. Every candidate 850 is a transport address. It also has a type and a base. Four types 851 are defined and gathered by this specification -- host candidates, 852 server reflexive candidates, peer reflexive candidates, and relayed 853 candidates. The server reflexive candidates are gathered using STUN 854 or TURN, and relayed candidates are obtained through TURN. Peer 855 reflexive candidates are obtained in later phases of ICE, as a 856 consequence of connectivity checks. The base of a candidate is the 857 candidate that an agent must send from when using that candidate. 859 4.1.1.1. Host Candidates 861 The first step is to gather host candidates. Host candidates are 862 obtained by binding to ports (typically ephemeral) on a IP address 863 attached to an interface (physical or virtual, including VPN 864 interfaces) on the host. 866 For each UDP media stream the agent wishes to use, the agent SHOULD 867 obtain a candidate for each component of the media stream on each IP 868 address that the host has, with the exceptions listed below. The 869 agent obtains each candidate by binding to a UDP port on the specific 870 IP address. A host candidate (and indeed every candidate) is always 871 associated with a specific component for which it is a candidate. 873 Each component has an ID assigned to it, called the component ID. 874 For RTP-based media streams, the RTP itself has a component ID of 1, 875 and RTCP a component ID of 2. If an agent is using RTCP, it MUST 876 obtain a candidate for it. If an agent is using both RTP and RTCP, 877 it would end up with 2*K host candidates if an agent has K IP 878 addresses. 880 For other than RTP-based streams, use of multiple components is 881 discouraged since using them increases the complexity of ICE 882 processing. If multiple components are needed, the component IDs 883 SHOULD start with 1 and increase by 1 for each component. 885 The base for each host candidate is set to the candidate itself. 887 The host candidates are gathered from all IP addresses with the 888 following exceptions: 890 o Addresses from a loopback interface MUST NOT be included in the 891 candidate addresses. 893 o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site- 894 local unicast addresses [RFC3879] MUST NOT be included in the 895 address candidates. 897 o IPv4-mapped IPv6 addresses SHOULD NOT be included in the offered 898 candidates unless the application using ICE does not support IPv4 899 (i.e., is an IPv6-only application [RFC4038]). 901 o If one or more host candidates corresponding to an IPv6 address 902 generated using a mechanism that prevents location tracking 903 [I-D.ietf-6man-ipv6-address-generation-privacy] are gathered, host 904 candidates corresponding to IPv6 addresses that do allow location 905 tracking, that are configured on the same interface, and are part 906 of the same network prefix MUST NOT be gathered; and host 907 candidates corresponding to IPv6 link-local addresses MUST NOT be 908 gathered. 910 4.1.1.2. Server Reflexive and Relayed Candidates 912 Agents SHOULD obtain relayed candidates and SHOULD obtain server 913 reflexive candidates. These requirements are at SHOULD strength to 914 allow for provider variation. Use of STUN and TURN servers may be 915 unnecessary in closed networks where agents are never connected to 916 the public Internet or to endpoints outside of the closed network. 917 In such cases, a full implementation would be used for agents that 918 are dual-stack or multihomed, to select a host candidate. Use of 919 TURN servers is expensive, and when ICE is being used, they will only 920 be utilized when both endpoints are behind NATs that perform address 921 and port dependent mapping. Consequently, some deployments might 922 consider this use case to be marginal, and elect not to use TURN 923 servers. If an agent does not gather server reflexive or relayed 924 candidates, it is RECOMMENDED that the functionality be implemented 925 and just disabled through configuration, so that it can be re-enabled 926 through configuration if conditions change in the future. 928 If an agent is gathering both relayed and server reflexive 929 candidates, it uses a TURN server. If it is gathering just server 930 reflexive candidates, it uses a STUN server. 932 The agent next pairs each host candidate with the STUN or TURN server 933 with which it is configured or has discovered by some means. If a 934 STUN or TURN server is configured, it is RECOMMENDED that a domain 935 name be configured, and the DNS procedures in [RFC5389] (using SRV 936 records with the "stun" service) be used to discover the STUN server, 937 and the DNS procedures in [RFC5766] (using SRV records with the 938 "turn" service) be used to discover the TURN server. 940 This specification only considers usage of a single STUN or TURN 941 server. When there are multiple choices for that single STUN or TURN 942 server (when, for example, they are learned through DNS records and 943 multiple results are returned), an agent SHOULD use a single STUN or 944 TURN server (based on its IP address) for all candidates for a 945 particular session. This improves the performance of ICE. The 946 result is a set of pairs of host candidates with STUN or TURN 947 servers. The agent then chooses one pair, and sends a Binding or 948 Allocate request to the server from that host candidate. Binding 949 requests to a STUN server are not authenticated, and any ALTERNATE- 950 SERVER attribute in a response is ignored. Agents MUST support the 951 backwards compatibility mode for the Binding request defined in 952 [RFC5389]. Allocate requests SHOULD be authenticated using a long- 953 term credential obtained by the client through some other means. 955 Every Ta milliseconds thereafter, the agent can generate another new 956 STUN or TURN transaction. This transaction can either be a retry of 957 a previous transaction that failed with a recoverable error (such as 958 authentication failure), or a transaction for a new host candidate 959 and STUN or TURN server pair. The agent SHOULD NOT generate 960 transactions more frequently than one every Ta milliseconds. See 961 Section 13 for guidance on how to set Ta and the STUN retransmit 962 timer, RTO. 964 The agent will receive a Binding or Allocate response. A successful 965 Allocate response will provide the agent with a server reflexive 966 candidate (obtained from the mapped address) and a relayed candidate 967 in the XOR-RELAYED-ADDRESS attribute. If the Allocate request is 968 rejected because the server lacks resources to fulfill it, the agent 969 SHOULD instead send a Binding request to obtain a server reflexive 970 candidate. A Binding response will provide the agent with only a 971 server reflexive candidate (also obtained from the mapped address). 972 The base of the server reflexive candidate is the host candidate from 973 which the Allocate or Binding request was sent. The base of a 974 relayed candidate is that candidate itself. If a relayed candidate 975 is identical to a host candidate (which can happen in rare cases), 976 the relayed candidate MUST be discarded. 978 If an IPv6-only agent is in a network that utilizes NAT64 [RFC6146] 979 and DNS64 [RFC6147] technologies, it may gather also IPv4 server 980 reflexive and/or relayed candidates from IPv4-only STUN or TURN 981 servers. IPv6-only agents SHOULD also utilize IPv6 prefix discovery 982 [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and 983 generate server reflexive candidates for each IPv6-only interface 984 accordingly. The NAT64 server reflexive candidates are prioritized 985 like IPv4 server reflexive candidates. 987 4.1.1.3. Computing Foundations 989 Finally, the agent assigns each candidate a foundation. The 990 foundation is an identifier, scoped within a session. Two candidates 991 MUST have the same foundation ID when all of the following are true: 993 o they are of the same type (host, relayed, server reflexive, or 994 peer reflexive) 996 o their bases have the same IP address (the ports can be different) 998 o for reflexive and relayed candidates, the STUN or TURN servers 999 used to obtain them have the same IP address 1001 o they were obtained using the same transport protocol (TCP, UDP, 1002 etc.) 1004 Similarly, two candidates MUST have different foundations if their 1005 types are different, their bases have different IP addresses, the 1006 STUN or TURN servers used to obtain them have different IP addresses, 1007 or their transport protocols are different. 1009 4.1.1.4. Keeping Candidates Alive 1011 Once server reflexive and relayed candidates are allocated, they MUST 1012 be kept alive until ICE processing has completed, as described in 1013 Section 8.3. For server reflexive candidates learned through a 1014 Binding request, the bindings MUST be kept alive by additional 1015 Binding requests to the server. Refreshes for allocations are done 1016 using the Refresh transaction, as described in [RFC5766]. The 1017 Refresh requests will also refresh the server reflexive candidate. 1019 4.1.2. Prioritizing Candidates 1021 The prioritization process results in the assignment of a priority to 1022 each candidate. Each candidate for a media stream MUST have a unique 1023 priority that MUST be a positive integer between 1 and (2**31 - 1). 1024 This priority will be used by ICE to determine the order of the 1025 connectivity checks and the relative preference for candidates. 1027 An agent SHOULD compute this priority using the formula in 1028 Section 4.1.2.1 and choose its parameters using the guidelines in 1029 Section 4.1.2.2. If an agent elects to use a different formula, ICE 1030 will take longer to converge since both agents will not be 1031 coordinated in their checks. 1033 4.1.2.1. Recommended Formula 1035 When using the formula, an agent computes the priority by determining 1036 a preference for each type of candidate (server reflexive, peer 1037 reflexive, relayed, and host), and, when the agent is multihomed, 1038 choosing a preference for its IP addresses. These two preferences 1039 are then combined to compute the priority for a candidate. That 1040 priority is computed using the following formula: 1042 priority = (2^24)*(type preference) + 1043 (2^8)*(local preference) + 1044 (2^0)*(256 - component ID) 1046 The type preference MUST be an integer from 0 to 126 inclusive, and 1047 represents the preference for the type of the candidate (where the 1048 types are local, server reflexive, peer reflexive, and relayed). A 1049 126 is the highest preference, and a 0 is the lowest. Setting the 1050 value to a 0 means that candidates of this type will only be used as 1051 a last resort. The type preference MUST be identical for all 1052 candidates of the same type and MUST be different for candidates of 1053 different types. The type preference for peer reflexive candidates 1054 MUST be higher than that of server reflexive candidates. Note that 1055 candidates gathered based on the procedures of Section 4.1.1 will 1056 never be peer reflexive candidates; candidates of these type are 1057 learned from the connectivity checks performed by ICE. 1059 The local preference MUST be an integer from 0 to 65535 inclusive. 1060 It represents a preference for the particular IP address from which 1061 the candidate was obtained. 65535 represents the highest preference, 1062 and a zero, the lowest. When there is only a single IP address, this 1063 value SHOULD be set to 65535. More generally, if there are multiple 1064 candidates for a particular component for a particular media stream 1065 that have the same type, the local preference MUST be unique for each 1066 one. In this specification, this only happens for multihomed hosts 1067 or if an agent is using multiple TURN servers. If a host is 1068 multihomed because it is dual-stack, the local preference SHOULD be 1069 set equal to the precedence value for IP addresses described in RFC 1070 6724 [RFC6724]. If the host operating system provides an API for 1071 discovering preference among different addresses, those preferences 1072 SHOULD be used for the local preference to prioritize addresses 1073 indicated as preferred by the operating system. 1075 The component ID is the component ID for the candidate, and MUST be 1076 between 1 and 256 inclusive. 1078 4.1.2.2. Guidelines for Choosing Type and Local Preferences 1080 One criterion for selection of the type and local preference values 1081 is the use of a media intermediary, such as a TURN server, VPN 1082 server, or NAT. With a media intermediary, if media is sent to that 1083 candidate, it will first transit the media intermediary before being 1084 received. Relayed candidates are one type of candidate that involves 1085 a media intermediary. Another are host candidates obtained from a 1086 VPN interface. When media is transited through a media intermediary, 1087 it can increase the latency between transmission and reception. It 1088 can increase the packet losses, because of the additional router hops 1089 that may be taken. It may increase the cost of providing service, 1090 since media will be routed in and right back out of a media 1091 intermediary run by a provider. If these concerns are important, the 1092 type preference for relayed candidates SHOULD be lower than host 1093 candidates. The RECOMMENDED values are 126 for host candidates, 100 1094 for server reflexive candidates, 110 for peer reflexive candidates, 1095 and 0 for relayed candidates. 1097 Furthermore, if an agent is multihomed and has multiple IP addresses, 1098 the local preference for host candidates from a VPN interface SHOULD 1099 have a priority of 0. If multiple TURN servers are used, local 1100 priorities for the candidates obtained from the TURN servers are 1101 chosen in a similar fashion as for multihomed local candidates: the 1102 local preference value is used to indicate preference among different 1103 servers but the preference MUST be unique for each one. 1105 Another criterion for selection of preferences is IP address family. 1106 ICE works with both IPv4 and IPv6. It therefore provides a 1107 transition mechanism that allows dual-stack hosts to prefer 1108 connectivity over IPv6, but to fall back to IPv4 in case the v6 1109 networks are disconnected (due, for example, to a failure in a 6to4 1110 relay) [RFC3056]. It can also help with hosts that have both a 1111 native IPv6 address and a 6to4 address. In such a case, higher local 1112 preferences could be assigned to the v6 addresses, followed by the 1113 6to4 addresses, followed by the v4 addresses. This allows a site to 1114 obtain and begin using native v6 addresses immediately, yet still 1115 fall back to 6to4 addresses when communicating with agents in other 1116 sites that do not yet have native v6 connectivity. 1118 Another criterion for selecting preferences is security. If a user 1119 is a telecommuter, and therefore connected to a corporate network and 1120 a local home network, the user may prefer their voice traffic to be 1121 routed over the VPN in order to keep it on the corporate network when 1122 communicating within the enterprise, but use the local network when 1123 communicating with users outside of the enterprise. In such a case, 1124 a VPN address would have a higher local preference than any other 1125 address. 1127 Another criterion for selecting preferences is topological awareness. 1128 This is most useful for candidates that make use of intermediaries. 1129 In those cases, if an agent has preconfigured or dynamically 1130 discovered knowledge of the topological proximity of the 1131 intermediaries to itself, it can use that to assign higher local 1132 preferences to candidates obtained from closer intermediaries. 1134 4.1.3. Eliminating Redundant Candidates 1136 Next, the agent eliminates redundant candidates. A candidate is 1137 redundant if its transport address equals another candidate, and its 1138 base equals the base of that other candidate. Note that two 1139 candidates can have the same transport address yet have different 1140 bases, and these would not be considered redundant. Frequently, a 1141 server reflexive candidate and a host candidate will be redundant 1142 when the agent is not behind a NAT. The agent SHOULD eliminate the 1143 redundant candidate with the lower priority. 1145 4.2. Lite Implementation Requirements 1147 Lite implementations only utilize host candidates. A lite 1148 implementation MUST, for each component of each media stream, 1149 allocate zero or one IPv4 candidates. It MAY allocate zero or more 1150 IPv6 candidates, but no more than one per each IPv6 address utilized 1151 by the host. Since there can be no more than one IPv4 candidate per 1152 component of each media stream, if an agent has multiple IPv4 1153 addresses, it MUST choose one for allocating the candidate. If a 1154 host is dual-stack, it is RECOMMENDED that it allocate one IPv4 1155 candidate and one global IPv6 address. With the lite implementation, 1156 ICE cannot be used to dynamically choose amongst candidates. 1157 Therefore, including more than one candidate from a particular scope 1158 is NOT RECOMMENDED, since only a connectivity check can truly 1159 determine whether to use one address or the other. 1161 Each component has an ID assigned to it, called the component ID. 1162 For RTP-based media streams, the RTP itself has a component ID of 1, 1163 and RTCP a component ID of 2. If an agent is using RTCP, it MUST 1164 obtain candidates for it. 1166 Each candidate is assigned a foundation. The foundation MUST be 1167 different for two candidates allocated from different IP addresses, 1168 and MUST be the same otherwise. A simple integer that increments for 1169 each IP address will suffice. In addition, each candidate MUST be 1170 assigned a unique priority amongst all candidates for the same media 1171 stream. This priority SHOULD be equal to: 1173 priority = (2^24)*(126) + 1174 (2^8)*(IP precedence) + 1175 (2^0)*(256 - component ID) 1177 If a host is v4-only, it SHOULD set the IP precedence to 65535. If a 1178 host is v6 or dual-stack, the IP precedence SHOULD be the precedence 1179 value for IP addresses described in RFC 6724 [RFC6724]. 1181 Next, an agent chooses a default candidate for each component of each 1182 media stream. If a host is IPv4-only, there would only be one 1183 candidate for each component of each media stream, and therefore that 1184 candidate is the default. If a host is IPv6 or dual-stack, the 1185 selection of default is a matter of local policy. This default 1186 SHOULD be chosen such that it is the candidate most likely to be used 1187 with a peer. For IPv6-only hosts, this would typically be a globally 1188 scoped IPv6 address. For dual-stack hosts, the IPv4 address is 1189 RECOMMENDED. 1191 4.3. Encoding the Offer 1193 The syntax for the offer and answer messages is entirely a matter of 1194 convenience for the using protocol. However, the following 1195 parameters and their data types needs to be conveyed in the initial 1196 exchange: 1198 Candidate attribute There will be one or more of these for each 1199 "media stream". Each candidate is composed of: 1201 Connection Address: The IP address and transport protocol port of 1202 the candidate. 1204 Transport: An indicator of the transport protocol for this 1205 candidate. This need not be present if the using protocol will 1206 only ever run over a single transport protocol. If it runs 1207 over more than one, or if others are anticipated to be used in 1208 the future, this should be present. 1210 Foundation: A sequence of up to 32 characters. 1212 Component-ID: This would be present only if the using protocol 1213 were utilizing the concept of components. If it is, it would 1214 be a positive integer that indicates the component ID for which 1215 this is a candidate. 1217 Priority: An encoding of the 32-bit priority value. 1219 Candidate Type: The candidate type, as defined in ICE. 1221 Related Address and Port: The related IP address and port for 1222 this candidate, as defined by ICE. These MAY be omitted or set 1223 to invalid values if the agent does not want to reveal them, 1224 e.g., for privacy reasons. 1226 Extensibility Parameters: The using protocol should define some 1227 means for adding new per-candidate ICE parameters in the 1228 future. 1230 Lite Flag: If ICE lite is used by the using protocol, it needs to 1231 convey a boolean parameter which indicates whether the 1232 implementation is lite or not. 1234 Connectivity check pacing value: If an agent wants to use other than 1235 the default pacing values for the connectivity checks, it MUST 1236 indicate this in the ICE exchange. 1238 Username Fragment and Password: The using protocol has to convey a 1239 username fragment and password. The username fragment MUST 1240 contain at least 24 bits of randomness, and the password MUST 1241 contain at least 128 bits of randomness. 1243 ICE extensions: In addition to the per-candidate extensions above, 1244 the using protocol should allow for new media-stream or session- 1245 level attributes (ice-options). 1247 If the using protocol is using the ICE mismatch feature, a way is 1248 needed to convey this parameter in answers. It is a boolean flag. 1250 The exchange of parameters is symmetric; both agents need to send the 1251 same set of attributes as defined above. 1253 The using protocol may (or may not) need to deal with backwards 1254 compatibility with older implementations that do not support ICE. If 1255 the fallback mechanism is being used, then presumably the using 1256 protocol provides a way of conveying the default candidate (its IP 1257 address and port) in addition to the ICE parameters. 1259 STUN connectivity checks between agents are authenticated using the 1260 short-term credential mechanism defined for STUN [RFC5389]. This 1261 mechanism relies on a username and password that are exchanged 1262 through protocol machinery between the client and server. With ICE, 1263 the offer/answer exchange is used to exchange them. The username 1264 part of this credential is formed by concatenating a username 1265 fragment from each agent, separated by a colon. Each agent also 1266 provides a password, used to compute the message integrity for 1267 requests it receives. The username fragment and password are 1268 exchanged in the offer and answer. In addition to providing 1269 security, the username provides disambiguation and correlation of 1270 checks to media streams. See Appendix B.4 for motivation. 1272 If an agent is a lite implementation, it MUST indicate this in the 1273 offer. 1275 ICE provides for extensibility by allowing an offer or answer to 1276 contain a series of tokens that identify the ICE extensions used by 1277 that agent. If an agent supports an ICE extension, it MUST include 1278 the token defined for that extension in the offer. 1280 Once an agent has sent its offer or its answer, that agent MUST be 1281 prepared to receive both STUN and media packets on each candidate. 1282 As discussed in Section 11.1, media packets can be sent to a 1283 candidate prior to its appearance as the default destination for 1284 media in an offer or answer. 1286 5. Receiving the Initial Offer 1288 When an agent receives an initial offer, it will check if the offerer 1289 supports ICE, determine its own role, gather candidates, prioritize 1290 them, choose default candidates, encode and send an answer, and for 1291 full implementations, form the check lists and begin connectivity 1292 checks. 1294 5.1. Verifying ICE Support 1296 Certain middleboxes, such as ALGs, may alter the ICE offer and/or 1297 answer in a way that breaks ICE. If the using protocol is vulnerable 1298 to this kind of changes, called ICE mismatch, the answerer needs to 1299 detect this and signal this back to the offerer. The details on 1300 whether this is needed and how it is done is defined by the usage 1301 specifications. 1303 5.2. Determining Role 1305 For each session, each agent takes on a role. There are two roles -- 1306 controlling and controlled. The controlling agent is responsible for 1307 the choice of the final candidate pairs used for communications. For 1308 a full agent, this means nominating the candidate pairs that can be 1309 used by ICE for each media stream, and for generating the updated 1310 offer based on ICE's selection, when needed. For a lite 1311 implementation, being the controlling agent means selecting a 1312 candidate pair based on the ones in the offer and answer (for IPv4, 1313 there is only ever one pair), and then generating an updated offer 1314 reflecting that selection, when needed (it is never needed for an 1315 IPv4-only host). The controlled agent is told which candidate pairs 1316 to use for each media stream, and does not generate an updated offer 1317 to signal this information. The sections below describe in detail 1318 the actual procedures followed by controlling and controlled nodes. 1320 The rules for determining the role and the impact on behavior are as 1321 follows: 1323 Both agents are full: The agent that generated the offer which 1324 started the ICE processing MUST take the controlling role, and the 1325 other MUST take the controlled role. Both agents will form check 1326 lists, run the ICE state machines, and generate connectivity 1327 checks. The controlling agent will execute the logic in 1328 Section 8.1 to nominate pairs that will be selected by ICE, and 1329 then both agents end ICE as described in Section 8.1.2. 1331 One agent full, one lite: The full agent MUST take the controlling 1332 role, and the lite agent MUST take the controlled role. The full 1333 agent will form check lists, run the ICE state machines, and 1334 generate connectivity checks. That agent will execute the logic 1335 in Section 8.1 to nominate pairs that will be selected by ICE, and 1336 use the logic in Section 8.1.2 to end ICE. The lite 1337 implementation will just listen for connectivity checks, receive 1338 them and respond to them, and then conclude ICE as described in 1339 Section 8.2. For the lite implementation, the state of ICE 1340 processing for each media stream is considered to be Running, and 1341 the state of ICE overall is Running. 1343 Both lite: The agent that generated the offer which started the ICE 1344 processing MUST take the controlling role, and the other MUST take 1345 the controlled role. In this case, no connectivity checks are 1346 ever sent. Rather, once the offer/answer exchange completes, each 1347 agent performs the processing described in Section 8 without 1348 connectivity checks. It is possible that both agents will believe 1349 they are controlled or controlling. In the latter case, the 1350 conflict is resolved through glare detection capabilities in the 1351 signaling protocol carrying the offer/answer exchange. The state 1352 of ICE processing for each media stream is considered to be 1353 Running, and the state of ICE overall is Running. 1355 Once roles are determined for a session, they persist unless ICE is 1356 restarted. An ICE restart causes a new selection of roles and tie- 1357 breakers. 1359 5.3. Gathering Candidates 1361 The process for gathering candidates at the answerer is identical to 1362 the process for the offerer as described in Section 4.1.1 for full 1363 implementations and Section 4.2 for lite implementations. It is 1364 RECOMMENDED that this process begin immediately on receipt of the 1365 offer, prior to alerting the user. Such gathering MAY begin when an 1366 agent starts. 1368 5.4. Prioritizing Candidates 1370 The process for prioritizing candidates at the answerer is identical 1371 to the process followed by the offerer, as described in Section 4.1.2 1372 for full implementations and Section 4.2 for lite implementations. 1374 5.5. Encoding the Answer 1376 The process for encoding the answer is identical to the process 1377 followed by the offerer for both full and lite implementations, as 1378 described in Section 4.3. 1380 5.6. Forming the Check Lists 1382 Forming check lists is done only by full implementations. Lite 1383 implementations MUST skip the steps defined in this section. 1385 There is one check list per in-use media stream resulting from the 1386 offer/answer exchange. To form the check list for a media stream, 1387 the agent forms candidate pairs, computes a candidate pair priority, 1388 orders the pairs by priority, prunes them, and sets their states. 1389 These steps are described in this section. 1391 5.6.1. Forming Candidate Pairs 1393 First, the agent takes each of its candidates for a media stream 1394 (called LOCAL CANDIDATES) and pairs them with the candidates it 1395 received from its peer (called REMOTE CANDIDATES) for that media 1396 stream. In order to prevent the attacks described in Section 15.4.1, 1397 agents MAY limit the number of candidates they'll accept in an offer 1398 or answer. A local candidate is paired with a remote candidate if 1399 and only if the two candidates have the same component ID and have 1400 the same IP address version. It is possible that some of the local 1401 candidates won't get paired with remote candidates, and some of the 1402 remote candidates won't get paired with local candidates. This can 1403 happen if one agent doesn't include candidates for the all of the 1404 components for a media stream. If this happens, the number of 1405 components for that media stream is effectively reduced, and 1406 considered to be equal to the minimum across both agents of the 1407 maximum component ID provided by each agent across all components for 1408 the media stream. 1410 In the case of RTP, this would happen when one agent provides 1411 candidates for RTCP, and the other does not. As another example, the 1412 offerer can multiplex RTP and RTCP on the same port and signals that 1413 it can do that in the SDP through an SDP attribute [RFC5761]. 1414 However, since the offerer doesn't know if the answerer can perform 1415 such multiplexing, the offerer includes candidates for RTP and RTCP 1416 on separate ports, so that the offer has two components per media 1417 stream. If the answerer can perform such multiplexing, it would 1418 include just a single component for each candidate -- for the 1419 combined RTP/RTCP mux. ICE would end up acting as if there was just 1420 a single component for this candidate. 1422 With IPv6 it is common for a host to have multiple host candidates 1423 for each interface. To keep the amount of resulting candidate pairs 1424 reasonable and to avoid candidate pairs that are highly unlikely to 1425 work, IPv6 link-local addresses [RFC4291] MUST NOT be paired with 1426 other than link-local addresses. 1428 The candidate pairs whose local and remote candidates are both the 1429 default candidates for a particular component is called, 1430 unsurprisingly, the default candidate pair for that component. This 1431 is the pair that would be used to transmit media if both agents had 1432 not been ICE aware. 1434 In order to aid understanding, Figure 6 shows the relationships 1435 between several key concepts -- transport addresses, candidates, 1436 candidate pairs, and check lists, in addition to indicating the main 1437 properties of candidates and candidate pairs. 1439 +--------------------------------------------+ 1440 | | 1441 | +---------------------+ | 1442 | |+----+ +----+ +----+ | +Type | 1443 | || IP | |Port| |Tran| | +Priority | 1444 | ||Addr| | | | | | +Foundation | 1445 | |+----+ +----+ +----+ | +Component ID | 1446 | | Transport | +Related Address | 1447 | | Addr | | 1448 | +---------------------+ +Base | 1449 | Candidate | 1450 +--------------------------------------------+ 1451 * * 1452 * ************************************* 1453 * * 1454 +-------------------------------+ 1455 .| | 1456 | Local Remote | 1457 | +----+ +----+ +default? | 1458 | |Cand| |Cand| +valid? | 1459 | +----+ +----+ +nominated?| 1460 | +State | 1461 | | 1462 | | 1463 | Candidate Pair | 1464 +-------------------------------+ 1465 * * 1466 * ************ 1467 * * 1468 +------------------+ 1469 | Candidate Pair | 1470 +------------------+ 1471 +------------------+ 1472 | Candidate Pair | 1473 +------------------+ 1474 +------------------+ 1475 | Candidate Pair | 1476 +------------------+ 1478 Check 1479 List 1481 Figure 6: Conceptual Diagram of a Check List 1483 5.6.2. Computing Pair Priority and Ordering Pairs 1485 Once the pairs are formed, a candidate pair priority is computed. 1486 Let G be the priority for the candidate provided by the controlling 1487 agent. Let D be the priority for the candidate provided by the 1488 controlled agent. The priority for a pair is computed as: 1490 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 1492 Where G>D?1:0 is an expression whose value is 1 if G is greater than 1493 D, and 0 otherwise. Once the priority is assigned, the agent sorts 1494 the candidate pairs in decreasing order of priority. If two pairs 1495 have identical priority, the ordering amongst them is arbitrary. 1497 5.6.3. Pruning the Pairs 1499 This sorted list of candidate pairs is used to determine a sequence 1500 of connectivity checks that will be performed. Each check involves 1501 sending a request from a local candidate to a remote candidate. 1502 Since an agent cannot send requests directly from a reflexive 1503 candidate, but only from its base, the agent next goes through the 1504 sorted list of candidate pairs. For each pair where the local 1505 candidate is server reflexive, the server reflexive candidate MUST be 1506 replaced by its base. Once this has been done, the agent MUST prune 1507 the list. This is done by removing a pair if its local and remote 1508 candidates are identical to the local and remote candidates of a pair 1509 higher up on the priority list. The result is a sequence of ordered 1510 candidate pairs, called the check list for that media stream. 1512 In addition, in order to limit the attacks described in 1513 Section 15.4.1, an agent MUST limit the total number of connectivity 1514 checks the agent performs across all check lists to a specific value, 1515 and this value MUST be configurable. A default of 100 is 1516 RECOMMENDED. This limit is enforced by discarding the lower-priority 1517 candidate pairs until there are less than 100. It is RECOMMENDED 1518 that a lower value be utilized when possible, set to the maximum 1519 number of plausible checks that might be seen in an actual deployment 1520 configuration. The requirement for configuration is meant to provide 1521 a tool for fixing this value in the field if, once deployed, it is 1522 found to be problematic. 1524 5.6.4. Computing States 1526 Each candidate pair in the check list has a foundation and a state. 1527 The foundation is the combination of the foundations of the local and 1528 remote candidates in the pair. The state is assigned once the check 1529 list for each media stream has been computed. There are five 1530 potential values that the state can have: 1532 Waiting: A check has not been performed for this pair, and can be 1533 performed as soon as it is the highest-priority Waiting pair on 1534 the check list. 1536 In-Progress: A check has been sent for this pair, but the 1537 transaction is in progress. 1539 Succeeded: A check for this pair was already done and produced a 1540 successful result. 1542 Failed: A check for this pair was already done and failed, either 1543 never producing any response or producing an unrecoverable failure 1544 response. 1546 Frozen: A check for this pair hasn't been performed, and it can't 1547 yet be performed until some other check succeeds, allowing this 1548 pair to unfreeze and move into the Waiting state. 1550 As ICE runs, the pairs will move between states as shown in Figure 7. 1552 +-----------+ 1553 | | 1554 | | 1555 | Frozen | 1556 | | 1557 | | 1558 +-----------+ 1559 | 1560 |unfreeze 1561 | 1562 V 1563 +-----------+ +-----------+ 1564 | | | | 1565 | | perform | | 1566 | Waiting |-------->|In-Progress| 1567 | | | | 1568 | | | | 1569 +-----------+ +-----------+ 1570 / | 1571 // | 1572 // | 1573 // | 1574 / | 1575 // | 1576 failure // |success 1577 // | 1578 / | 1579 // | 1580 // | 1581 // | 1582 V V 1583 +-----------+ +-----------+ 1584 | | | | 1585 | | | | 1586 | Failed | | Succeeded | 1587 | | | | 1588 | | | | 1589 +-----------+ +-----------+ 1591 Figure 7: Pair State FSM 1593 The initial states for each pair in a check list are computed by 1594 performing the following sequence of steps: 1596 1. The agent sets all of the pairs in each check list to the Frozen 1597 state. 1599 2. The agent examines the check list for the first media stream. 1600 For that media stream: 1602 * For all pairs with the same foundation, it sets the state of 1603 the pair with the lowest component ID to Waiting. If there is 1604 more than one such pair, the one with the highest-priority is 1605 used. 1607 One of the check lists will have some number of pairs in the Waiting 1608 state, and the other check lists will have all of their pairs in the 1609 Frozen state. A check list with at least one pair that is Waiting is 1610 called an active check list, and a check list with all pairs Frozen 1611 is called a frozen check list. 1613 The check list itself is associated with a state, which captures the 1614 state of ICE checks for that media stream. There are three states: 1616 Running: In this state, ICE checks are still in progress for this 1617 media stream. 1619 Completed: In this state, ICE checks have produced nominated pairs 1620 for each component of the media stream. Consequently, ICE has 1621 succeeded and media can be sent. 1623 Failed: In this state, the ICE checks have not completed 1624 successfully for this media stream. 1626 When a check list is first constructed as the consequence of an 1627 offer/answer exchange, it is placed in the Running state. 1629 ICE processing across all media streams also has a state associated 1630 with it. This state is equal to Running while ICE processing is 1631 under way. The state is Completed when ICE processing is complete 1632 and Failed if it failed without success. Rules for transitioning 1633 between states are described below. 1635 5.7. Scheduling Checks 1637 Checks are generated only by full implementations. Lite 1638 implementations MUST skip the steps described in this section. 1640 An agent performs ordinary checks and triggered checks. The 1641 generation of both checks is governed by a timer that fires 1642 periodically for each media stream. The agent maintains a FIFO 1643 queue, called the triggered check queue, which contains candidate 1644 pairs for which checks are to be sent at the next available 1645 opportunity. When the timer fires, the agent removes the top pair 1646 from the triggered check queue, performs a connectivity check on that 1647 pair, and sets the state of the candidate pair to In-Progress. If 1648 there are no pairs in the triggered check queue, an ordinary check is 1649 sent. 1651 Once the agent has computed the check lists as described in 1652 Section 5.6, it sets a timer for each active check list. The timer 1653 fires every Ta*N seconds, where N is the number of active check lists 1654 (initially, there is only one active check list). Implementations 1655 MAY set the timer to fire less frequently than this. Implementations 1656 SHOULD take care to spread out these timers so that they do not fire 1657 at the same time for each media stream. Ta and the retransmit timer 1658 RTO are computed as described in Section 13. Multiplying by N allows 1659 this aggregate check throughput to be split between all active check 1660 lists. The first timer fires immediately, so that the agent performs 1661 a connectivity check the moment the offer/answer exchange has been 1662 done, followed by the next check Ta seconds later (since there is 1663 only one active check list). 1665 When the timer fires and there is no triggered check to be sent, the 1666 agent MUST choose an ordinary check as follows: 1668 o Find the highest-priority pair in that check list that is in the 1669 Waiting state. 1671 o If there is such a pair: 1673 * Send a STUN check from the local candidate of that pair to the 1674 remote candidate of that pair. The procedures for forming the 1675 STUN request for this purpose are described in Section 7.1.2. 1677 * Set the state of the candidate pair to In-Progress. 1679 o If there is no such pair: 1681 * Find the highest-priority pair in that check list that is in 1682 the Frozen state. 1684 * If there is such a pair: 1686 + Unfreeze the pair. 1688 + Perform a check for that pair, causing its state to 1689 transition to In-Progress. 1691 * If there is no such pair: 1693 + Terminate the timer for that check list. 1695 To compute the message integrity for the check, the agent uses the 1696 remote username fragment and password learned from the offer or 1697 answer from its peer. The local username fragment is known directly 1698 by the agent for its own candidate. 1700 6. Receipt of the Initial Answer 1702 This section describes the procedures that an agent follows when it 1703 receives the answer from the peer. It verifies that its peer 1704 supports ICE, determines its role, and for full implementations, 1705 forms the check list and begins performing ordinary checks. 1707 6.1. Verifying ICE Support 1709 The logic at the offerer is identical to that of the answerer as 1710 described in Section 5.1, with the exception that an offerer would 1711 not ever indicate ICE mismatch. 1713 6.2. Determining Role 1715 The offerer follows the same procedures described for the answerer in 1716 Section 5.2. 1718 6.3. Forming the Check List 1720 Formation of check lists is performed only by full implementations. 1721 The offerer follows the same procedures described for the answerer in 1722 Section 5.6. 1724 6.4. Performing Ordinary Checks 1726 Ordinary checks are performed only by full implementations. The 1727 offerer follows the same procedures described for the answerer in 1728 Section 5.7. 1730 7. Performing Connectivity Checks 1732 This section describes how connectivity checks are performed. All 1733 ICE implementations are required to be compliant to [RFC5389], as 1734 opposed to the older [RFC3489]. However, whereas a full 1735 implementation will both generate checks (acting as a STUN client) 1736 and receive them (acting as a STUN server), a lite implementation 1737 will only receive checks, and thus will only act as a STUN server. 1739 7.1. STUN Client Procedures 1741 These procedures define how an agent sends a connectivity check, 1742 whether it is an ordinary or a triggered check. These procedures are 1743 only applicable to full implementations. 1745 7.1.1. Creating Permissions for Relayed Candidates 1747 If the connectivity check is being sent using a relayed local 1748 candidate, the client MUST create a permission first if it has not 1749 already created one previously. It would have created one previously 1750 if it had told the TURN server to create a permission for the given 1751 relayed candidate towards the IP address of the remote candidate. To 1752 create the permission, the agent follows the procedures defined in 1753 [RFC5766]. The permission MUST be created towards the IP address of 1754 the remote candidate. It is RECOMMENDED that the agent defer 1755 creation of a TURN channel until ICE completes, in which case 1756 permissions for connectivity checks are normally created using a 1757 CreatePermission request. Once established, the agent MUST keep the 1758 permission active until ICE concludes. 1760 7.1.2. Sending the Request 1762 A connectivity check is generated by sending a Binding request from a 1763 local candidate to a remote candidate. [RFC5389] describes how 1764 Binding requests are constructed and generated. A connectivity check 1765 MUST utilize the STUN short-term credential mechanism. Support for 1766 backwards compatibility with RFC 3489 MUST NOT be used or assumed 1767 with connectivity checks. The FINGERPRINT mechanism MUST be used for 1768 connectivity checks. 1770 ICE extends STUN by defining several new attributes, including 1771 PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. These 1772 new attributes are formally defined in Section 16.1, and their usage 1773 is described in the subsections below. These STUN extensions are 1774 applicable only to connectivity checks used for ICE. 1776 7.1.2.1. PRIORITY and USE-CANDIDATE 1778 An agent MUST include the PRIORITY attribute in its Binding request. 1779 The attribute MUST be set equal to the priority that would be 1780 assigned, based on the algorithm in Section 4.1.2, to a peer 1781 reflexive candidate, should one be learned as a consequence of this 1782 check (see Section 7.1.3.2.1 for how peer reflexive candidates are 1783 learned). This priority value will be computed identically to how 1784 the priority for the local candidate of the pair was computed, except 1785 that the type preference is set to the value for peer reflexive 1786 candidate types. 1788 The controlling agent MAY include the USE-CANDIDATE attribute in the 1789 Binding request. The controlled agent MUST NOT include it in its 1790 Binding request. This attribute signals that the controlling agent 1791 wishes to cease checks for this component, and use the candidate pair 1792 resulting from the check for this component. Section 8.1.1 provides 1793 guidance on determining when to include it. 1795 7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING 1797 The agent MUST include the ICE-CONTROLLED attribute in the request if 1798 it is in the controlled role, and MUST include the ICE-CONTROLLING 1799 attribute in the request if it is in the controlling role. The 1800 content of either attribute MUST be the tie-breaker that was 1801 determined in Section 5.2. These attributes are defined fully in 1802 Section 16.1. 1804 7.1.2.3. Forming Credentials 1806 A Binding request serving as a connectivity check MUST utilize the 1807 STUN short-term credential mechanism. The username for the 1808 credential is formed by concatenating the username fragment provided 1809 by the peer with the username fragment of the agent sending the 1810 request, separated by a colon (":"). The password is equal to the 1811 password provided by the peer. For example, consider the case where 1812 agent L is the offerer, and agent R is the answerer. Agent L 1813 included a username fragment of LFRAG for its candidates and a 1814 password of LPASS. Agent R provided a username fragment of RFRAG and 1815 a password of RPASS. A connectivity check from L to R utilizes the 1816 username RFRAG:LFRAG and a password of RPASS. A connectivity check 1817 from R to L utilizes the username LFRAG:RFRAG and a password of 1818 LPASS. The responses utilize the same usernames and passwords as the 1819 requests (note that the USERNAME attribute is not present in the 1820 response). 1822 7.1.2.4. DiffServ Treatment 1824 If the agent is using Diffserv Codepoint markings [RFC2475] in its 1825 media packets, it SHOULD apply those same markings to its 1826 connectivity checks. 1828 7.1.3. Processing the Response 1830 When a Binding response is received, it is correlated to its Binding 1831 request using the transaction ID, as defined in [RFC5389], which then 1832 ties it to the candidate pair for which the Binding request was sent. 1833 This section defines additional procedures for processing Binding 1834 responses specific to this usage of STUN. 1836 7.1.3.1. Failure Cases 1838 If the STUN transaction generates a 487 (Role Conflict) error 1839 response, the agent checks whether it included the ICE-CONTROLLED or 1840 ICE-CONTROLLING attribute in the Binding request. If the request 1841 contained the ICE-CONTROLLED attribute, the agent MUST switch to the 1842 controlling role if it has not already done so. If the request 1843 contained the ICE-CONTROLLING attribute, the agent MUST switch to the 1844 controlled role if it has not already done so. Once it has switched, 1845 the agent MUST enqueue the candidate pair whose check generated the 1846 487 into the triggered check queue. The state of that pair is set to 1847 Waiting. When the triggered check is sent, it will contain an ICE- 1848 CONTROLLING or ICE-CONTROLLED attribute reflecting its new role. 1849 Note, however, that the tie-breaker value MUST NOT be reselected. 1851 A change in roles will require an agent to recompute pair priorities 1852 (Section 5.6.2), since those priorities are a function of controlling 1853 and controlled roles. The change in role will also impact whether 1854 the agent is responsible for selecting nominated pairs and generating 1855 updated offers upon conclusion of ICE. 1857 Agents MAY support receipt of ICMP errors for connectivity checks. 1858 If the STUN transaction generates an ICMP error, the agent sets the 1859 state of the pair to Failed. If the STUN transaction generates a 1860 STUN error response that is unrecoverable (as defined in [RFC5389]) 1861 or times out, the agent sets the state of the pair to Failed. 1863 The agent MUST check that the source IP address and port of the 1864 response equal the destination IP address and port to which the 1865 Binding request was sent, and that the destination IP address and 1866 port of the response match the source IP address and port from which 1867 the Binding request was sent. In other words, the source and 1868 destination transport addresses in the request and responses are 1869 symmetric. If they are not symmetric, the agent sets the state of 1870 the pair to Failed. 1872 7.1.3.2. Success Cases 1874 A check is considered to be a success if all of the following are 1875 true: 1877 o The STUN transaction generated a success response. 1879 o The source IP address and port of the response equals the 1880 destination IP address and port to which the Binding request was 1881 sent. 1883 o The destination IP address and port of the response match the 1884 source IP address and port from which the Binding request was 1885 sent. 1887 7.1.3.2.1. Discovering Peer Reflexive Candidates 1889 The agent checks the mapped address from the STUN response. If the 1890 transport address does not match any of the local candidates that the 1891 agent knows about, the mapped address represents a new candidate -- a 1892 peer reflexive candidate. Like other candidates, it has a type, 1893 base, priority, and foundation. They are computed as follows: 1895 o Its type is equal to peer reflexive. 1897 o Its base is set equal to the local candidate of the candidate pair 1898 from which the STUN check was sent. 1900 o Its priority is set equal to the value of the PRIORITY attribute 1901 in the Binding request. 1903 o Its foundation is selected as described in Section 4.1.1.3. 1905 This peer reflexive candidate is then added to the list of local 1906 candidates for the media stream. Its username fragment and password 1907 are the same as all other local candidates for that media stream. 1908 However, the peer reflexive candidate is not paired with other remote 1909 candidates. This is not necessary; a valid pair will be generated 1910 from it momentarily based on the procedures in Section 7.1.3.2.2. If 1911 an agent wishes to pair the peer reflexive candidate with other 1912 remote candidates besides the one in the valid pair that will be 1913 generated, the agent MAY generate an updated offer which includes the 1914 peer reflexive candidate. This will cause it to be paired with all 1915 other remote candidates. 1917 7.1.3.2.2. Constructing a Valid Pair 1919 The agent constructs a candidate pair whose local candidate equals 1920 the mapped address of the response, and whose remote candidate equals 1921 the destination address to which the request was sent. This is 1922 called a valid pair, since it has been validated by a STUN 1923 connectivity check. The valid pair may equal the pair that generated 1924 the check, may equal a different pair in the check list, or may be a 1925 pair not currently on any check list. If the pair equals the pair 1926 that generated the check or is on a check list currently, it is also 1927 added to the VALID LIST, which is maintained by the agent for each 1928 media stream. This list is empty at the start of ICE processing, and 1929 fills as checks are performed, resulting in valid candidate pairs. 1931 It will be very common that the pair will not be on any check list. 1932 Recall that the check list has pairs whose local candidates are never 1933 server reflexive; those pairs had their local candidates converted to 1934 the base of the server reflexive candidates, and then pruned if they 1935 were redundant. When the response to the STUN check arrives, the 1936 mapped address will be reflexive if there is a NAT between the two. 1937 In that case, the valid pair will have a local candidate that doesn't 1938 match any of the pairs in the check list. 1940 If the pair is not on any check list, the agent computes the priority 1941 for the pair based on the priority of each candidate, using the 1942 algorithm in Section 5.6. The priority of the local candidate 1943 depends on its type. If it is not peer reflexive, it is equal to the 1944 priority signaled for that candidate in the offer or answer. If it 1945 is peer reflexive, it is equal to the PRIORITY attribute the agent 1946 placed in the Binding request that just completed. The priority of 1947 the remote candidate is taken from the offer/answer of the peer. If 1948 the candidate does not appear there, then the check must have been a 1949 triggered check to a new remote candidate. In that case, the 1950 priority is taken as the value of the PRIORITY attribute in the 1951 Binding request that triggered the check that just completed. The 1952 pair is then added to the VALID LIST. 1954 7.1.3.2.3. Updating Pair States 1956 The agent sets the state of the pair that *generated* the check to 1957 Succeeded. Note that, the pair which *generated* the check may be 1958 different than the valid pair constructed in Section 7.1.3.2.2 as a 1959 consequence of the response. The success of this check might also 1960 cause the state of other checks to change as well. The agent MUST 1961 perform the following two steps: 1963 1. The agent changes the states for all other Frozen pairs for the 1964 same media stream and same foundation to Waiting. Typically, but 1965 not always, these other pairs will have different component IDs. 1967 2. If there is a pair in the valid list for every component of this 1968 media stream (where this is the actual number of components being 1969 used, in cases where the number of components signaled in the 1970 offer/answer differs from offerer to answerer), the success of 1971 this check may unfreeze checks for other media streams. Note 1972 that this step is followed not just the first time the valid list 1973 under consideration has a pair for every component, but every 1974 subsequent time a check succeeds and adds yet another pair to 1975 that valid list. The agent examines the check list for each 1976 other media stream in turn: 1978 * If the check list is active, the agent changes the state of 1979 all Frozen pairs in that check list whose foundation matches a 1980 pair in the valid list under consideration to Waiting. 1982 * If the check list is frozen, and there is at least one pair in 1983 the check list whose foundation matches a pair in the valid 1984 list under consideration, the state of all pairs in the check 1985 list whose foundation matches a pair in the valid list under 1986 consideration is set to Waiting. This will cause the check 1987 list to become active, and ordinary checks will begin for it, 1988 as described in Section 5.7. 1990 * If the check list is frozen, and there are no pairs in the 1991 check list whose foundation matches a pair in the valid list 1992 under consideration, the agent 1994 + groups together all of the pairs with the same foundation, 1995 and 1997 + for each group, sets the state of the pair with the lowest 1998 component ID to Waiting. If there is more than one such 1999 pair, the one with the highest-priority is used. 2001 7.1.3.2.4. Updating the Nominated Flag 2003 If the agent was a controlling agent, and it had included a USE- 2004 CANDIDATE attribute in the Binding request, the valid pair generated 2005 from that check has its nominated flag set to true. This flag 2006 indicates that this valid pair should be used for media if it is the 2007 highest-priority one amongst those whose nominated flag is set. This 2008 may conclude ICE processing for this media stream or all media 2009 streams; see Section 8. 2011 If the agent is the controlled agent, the response may be the result 2012 of a triggered check that was sent in response to a request that 2013 itself had the USE-CANDIDATE attribute. This case is described in 2014 Section 7.2.1.5, and may now result in setting the nominated flag for 2015 the pair learned from the original request. 2017 7.1.3.3. Check List and Timer State Updates 2019 Regardless of whether the check was successful or failed, the 2020 completion of the transaction may require updating of check list and 2021 timer states. 2023 If all of the pairs in the check list are now either in the Failed or 2024 Succeeded state: 2026 o If there is not a pair in the valid list for each component of the 2027 media stream, the state of the check list is set to Failed. 2029 o For each frozen check list, the agent 2031 * groups together all of the pairs with the same foundation, and 2033 * for each group, sets the state of the pair with the lowest 2034 component ID to Waiting. If there is more than one such pair, 2035 the one with the highest-priority is used. 2037 If none of the pairs in the check list are in the Waiting or Frozen 2038 state, the check list is no longer considered active, and will not 2039 count towards the value of N in the computation of timers for 2040 ordinary checks as described in Section 5.7. 2042 7.2. STUN Server Procedures 2044 An agent MUST be prepared to receive a Binding request on the base of 2045 each candidate it included in its most recent offer or answer. This 2046 requirement holds even if the peer is a lite implementation. 2048 The agent MUST use the short-term credential mechanism (i.e., the 2049 MESSAGE-INTEGRITY attribute) to authenticate the request and perform 2050 a message integrity check. Likewise, the short-term credential 2051 mechanism MUST be used for the response. The agent MUST consider the 2052 username to be valid if it consists of two values separated by a 2053 colon, where the first value is equal to the username fragment 2054 generated by the agent in an offer or answer for a session in- 2055 progress. It is possible (and in fact very likely) that an offerer 2056 will receive a Binding request prior to receiving the answer from its 2057 peer. If this happens, the agent MUST immediately generate a 2058 response (including computation of the mapped address as described in 2059 Section 7.2.1.2). The agent has sufficient information at this point 2060 to generate the response; the password from the peer is not required. 2061 Once the answer is received, it MUST proceed with the remaining steps 2062 required, namely, Section 7.2.1.3, Section 7.2.1.4, and 2063 Section 7.2.1.5 for full implementations. In cases where multiple 2064 STUN requests are received before the answer, this may cause several 2065 pairs to be queued up in the triggered check queue. 2067 An agent MUST NOT utilize the ALTERNATE-SERVER mechanism, and MUST 2068 NOT support the backwards-compatibility mechanisms to RFC 3489. It 2069 MUST utilize the FINGERPRINT mechanism. 2071 If the agent is using Diffserv Codepoint markings [RFC2475] in its 2072 media packets, it SHOULD apply those same markings to its responses 2073 to Binding requests. The same would apply to any layer 2 markings 2074 the endpoint might be applying to media packets. 2076 7.2.1. Additional Procedures for Full Implementations 2078 This subsection defines the additional server procedures applicable 2079 to full implementations. 2081 7.2.1.1. Detecting and Repairing Role Conflicts 2083 Normally, the rules for selection of a role in Section 5.2 will 2084 result in each agent selecting a different role -- one controlling 2085 and one controlled. However, in unusual call flows, typically 2086 utilizing third party call control, it is possible for both agents to 2087 select the same role. This section describes procedures for checking 2088 for this case and repairing it. These procedures apply only to 2089 usages of ICE that require conflict resolution. The usage document 2090 MUST specify whether this mechanism is needed. 2092 An agent MUST examine the Binding request for either the ICE- 2093 CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these 2094 procedures: 2096 o If neither ICE-CONTROLLING nor ICE-CONTROLLED is present in the 2097 request, the peer agent may have implemented a previous version of 2098 this specification. There may be a conflict, but it cannot be 2099 detected. 2101 o If the agent is in the controlling role, and the ICE-CONTROLLING 2102 attribute is present in the request: 2104 * If the agent's tie-breaker is larger than or equal to the 2105 contents of the ICE-CONTROLLING attribute, the agent generates 2106 a Binding error response and includes an ERROR-CODE attribute 2107 with a value of 487 (Role Conflict) but retains its role. 2109 * If the agent's tie-breaker is less than the contents of the 2110 ICE-CONTROLLING attribute, the agent switches to the controlled 2111 role. 2113 o If the agent is in the controlled role, and the ICE-CONTROLLED 2114 attribute is present in the request: 2116 * If the agent's tie-breaker is larger than or equal to the 2117 contents of the ICE-CONTROLLED attribute, the agent switches to 2118 the controlling role. 2120 * If the agent's tie-breaker is less than the contents of the 2121 ICE-CONTROLLED attribute, the agent generates a Binding error 2122 response and includes an ERROR-CODE attribute with a value of 2123 487 (Role Conflict) but retains its role. 2125 o If the agent is in the controlled role and the ICE-CONTROLLING 2126 attribute was present in the request, or the agent was in the 2127 controlling role and the ICE-CONTROLLED attribute was present in 2128 the request, there is no conflict. 2130 A change in roles will require an agent to recompute pair priorities 2131 (Section 5.6.2), since those priorities are a function of controlling 2132 and controlled roles. The change in role will also impact whether 2133 the agent is responsible for selecting nominated pairs and generated 2134 updated offers upon conclusion of ICE. 2136 The remaining sections in Section 7.2.1 are followed if the server 2137 generated a successful response to the Binding request, even if the 2138 agent changed roles. 2140 7.2.1.2. Computing Mapped Address 2142 For requests being received on a relayed candidate, the source 2143 transport address used for STUN processing (namely, generation of the 2144 XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the 2145 TURN server. That source transport address will be present in the 2146 XOR-PEER-ADDRESS attribute of a Data Indication message, if the 2147 Binding request was delivered through a Data Indication. If the 2148 Binding request was delivered through a ChannelData message, the 2149 source transport address is the one that was bound to the channel. 2151 7.2.1.3. Learning Peer Reflexive Candidates 2153 If the source transport address of the request does not match any 2154 existing remote candidates, it represents a new peer reflexive remote 2155 candidate. This candidate is constructed as follows: 2157 o The priority of the candidate is set to the PRIORITY attribute 2158 from the request. 2160 o The type of the candidate is set to peer reflexive. 2162 o The foundation of the candidate is set to an arbitrary value, 2163 different from the foundation for all other remote candidates. If 2164 any subsequent offer/answer exchanges contain this peer reflexive 2165 candidate, it will signal the actual foundation for the candidate. 2167 o The component ID of this candidate is set to the component ID for 2168 the local candidate to which the request was sent. 2170 This candidate is added to the list of remote candidates. However, 2171 the agent does not pair this candidate with any local candidates. 2173 7.2.1.4. Triggered Checks 2175 Next, the agent constructs a pair whose local candidate is equal to 2176 the transport address on which the STUN request was received, and a 2177 remote candidate equal to the source transport address where the 2178 request came from (which may be the peer reflexive remote candidate 2179 that was just learned). The local candidate will either be a host 2180 candidate (for cases where the request was not received through a 2181 relay) or a relayed candidate (for cases where it is received through 2182 a relay). The local candidate can never be a server reflexive 2183 candidate. Since both candidates are known to the agent, it can 2184 obtain their priorities and compute the candidate pair priority. 2185 This pair is then looked up in the check list. There can be one of 2186 several outcomes: 2188 o If the pair is already on the check list: 2190 * If the state of that pair is Waiting or Frozen, a check for 2191 that pair is enqueued into the triggered check queue if not 2192 already present. 2194 * If the state of that pair is In-Progress, the agent cancels the 2195 in-progress transaction. Cancellation means that the agent 2196 will not retransmit the request, will not treat the lack of 2197 response to be a failure, but will wait the duration of the 2198 transaction timeout for a response. In addition, the agent 2199 MUST create a new connectivity check for that pair 2200 (representing a new STUN Binding request transaction) by 2201 enqueueing the pair in the triggered check queue. The state of 2202 the pair is then changed to Waiting. 2204 * If the state of the pair is Failed, it is changed to Waiting 2205 and the agent MUST create a new connectivity check for that 2206 pair (representing a new STUN Binding request transaction), by 2207 enqueueing the pair in the triggered check queue. 2209 * If the state of that pair is Succeeded, nothing further is 2210 done. 2212 These steps are done to facilitate rapid completion of ICE when both 2213 agents are behind NAT. 2215 o If the pair is not already on the check list: 2217 * The pair is inserted into the check list based on its priority. 2219 * Its state is set to Waiting. 2221 * The pair is enqueued into the triggered check queue. 2223 When a triggered check is to be sent, it is constructed and processed 2224 as described in Section 7.1.2. These procedures require the agent to 2225 know the transport address, username fragment, and password for the 2226 peer. The username fragment for the remote candidate is equal to the 2227 part after the colon of the USERNAME in the Binding request that was 2228 just received. Using that username fragment, the agent can check the 2229 offers/answers received from its peer (there may be more than one in 2230 cases of forking), and find this username fragment. The 2231 corresponding password is then selected. 2233 7.2.1.5. Updating the Nominated Flag 2235 If the Binding request received by the agent had the USE-CANDIDATE 2236 attribute set, and the agent is in the controlled role, the agent 2237 looks at the state of the pair computed in Section 7.2.1.4: 2239 o If the state of this pair is Succeeded, it means that the check 2240 generated by this pair produced a successful response. This would 2241 have caused the agent to construct a valid pair when that success 2242 response was received (see Section 7.1.3.2.2). The agent now sets 2243 the nominated flag in the valid pair to true. This may end ICE 2244 processing for this media stream; see Section 8. 2246 o If the state of this pair is In-Progress, if its check produces a 2247 successful result, the resulting valid pair has its nominated flag 2248 set when the response arrives. This may end ICE processing for 2249 this media stream when it arrives; see Section 8. 2251 7.2.2. Additional Procedures for Lite Implementations 2253 If the check that was just received contained a USE-CANDIDATE 2254 attribute, the agent constructs a candidate pair whose local 2255 candidate is equal to the transport address on which the request was 2256 received, and whose remote candidate is equal to the source transport 2257 address of the request that was received. This candidate pair is 2258 assigned an arbitrary priority, and placed into a list of valid 2259 candidates called the valid list. The agent sets the nominated flag 2260 for that pair to true. ICE processing is considered complete for a 2261 media stream if the valid list contains a candidate pair for each 2262 component. 2264 8. Concluding ICE Processing 2266 This section describes how an agent completes ICE. 2268 8.1. Procedures for Full Implementations 2270 Concluding ICE involves nominating pairs by the controlling agent and 2271 updating of state machinery. 2273 8.1.1. Nominating Pairs 2275 The controlling agent nominates pairs to be selected by ICE by using 2276 one of two techniques: regular nomination or aggressive nomination. 2277 If its peer has a lite implementation, an agent MUST use a regular 2278 nomination algorithm. If its peer is using ICE options (present in 2279 an ice-options attribute from the peer) that the agent does not 2280 understand, the agent MUST use a regular nomination algorithm. If 2281 its peer is a full implementation and isn't using any ICE options or 2282 is using ICE options understood by the agent, the agent MAY use 2283 either the aggressive or the regular nomination algorithm. However, 2284 the regular algorithm is RECOMMENDED since it provides greater 2285 stability. 2287 8.1.1.1. Regular Nomination 2289 With regular nomination, the agent lets some number of checks 2290 complete, each of which omit the USE-CANDIDATE attribute. Once one 2291 or more checks complete successfully for a component of a media 2292 stream, valid pairs are generated and added to the valid list. The 2293 agent lets the checks continue until some stopping criterion is met, 2294 and then picks amongst the valid pairs based on an evaluation 2295 criterion. The criteria for stopping the checks and for evaluating 2296 the valid pairs is entirely a matter of local optimization. 2298 When the controlling agent selects the valid pair, it repeats the 2299 check that produced this valid pair (by enqueueing the pair that 2300 generated the check into the triggered check queue), this time with 2301 the USE-CANDIDATE attribute. This check should succeed (since the 2302 previous did), causing the nominated flag of that and only that pair 2303 to be set. Consequently, there will be only a single nominated pair 2304 in the valid list for each component, and when the state of the check 2305 list moves to completed, that exact pair is selected by ICE for 2306 sending and receiving media for that component. 2308 Regular nomination provides the most flexibility, since the agent has 2309 control over the stopping and selection criteria for checks. The 2310 only requirement is that the agent MUST eventually pick one and only 2311 one candidate pair and generate a check for that pair with the USE- 2312 CANDIDATE attribute present. Regular nomination also improves ICE's 2313 resilience to variations in implementation (see Section 12). Regular 2314 nomination is also more stable, allowing both agents to converge on a 2315 single pair for media without any transient selections, which can 2316 happen with the aggressive algorithm. The drawback of regular 2317 nomination is that it is guaranteed to increase latencies because it 2318 requires an additional check to be done. 2320 8.1.1.2. Aggressive Nomination 2322 With aggressive nomination, the controlling agent includes the USE- 2323 CANDIDATE attribute in every check it sends. Once the first check 2324 for a component succeeds, it will be added to the valid list and have 2325 its nominated flag set. When all components have a nominated pair in 2326 the valid list, media can begin to flow using the highest-priority 2327 nominated pair. However, because the agent included the USE- 2328 CANDIDATE attribute in all of its checks, another check may yet 2329 complete, causing another valid pair to have its nominated flag set. 2330 ICE always selects the highest-priority nominated candidate pair from 2331 the valid list as the one used for media. Consequently, the selected 2332 pair may actually change briefly as ICE checks complete, resulting in 2333 a set of transient selections until it stabilizes. 2335 If certain connectivity check messages are lost, ICE agents using 2336 aggressive nomination may end up with different views on the selected 2337 candidate pair. In this case, if a security protocol that is able to 2338 authenticate the communicating parties (e.g., DTLS) is used, the 2339 controlled agent may receive valid secured traffic or handshake 2340 initialization originating from the controlling agent on a candidate 2341 pair that is different from the one the controlled agent considers as 2342 the selected pair. If this happens, the controlled agent MUST 2343 consider the pair with the secured traffic as the correct selected 2344 pair. If such security protocol is not used, both agents SHOULD 2345 continue sending connectivity check messages on the selected pair 2346 even after a pair has already been selected for use. In order to 2347 prevent the problem described here, at least one check from both 2348 agents needs to fully succeed on the selected pair. 2350 8.1.2. Updating States 2352 For both controlling and controlled agents, the state of ICE 2353 processing depends on the presence of nominated candidate pairs in 2354 the valid list and on the state of the check list. Note that, at any 2355 time, more than one of the following cases can apply: 2357 o If there are no nominated pairs in the valid list for a media 2358 stream and the state of the check list is Running, ICE processing 2359 continues. 2361 o If there is at least one nominated pair in the valid list for a 2362 media stream and the state of the check list is Running: 2364 * The agent MUST remove all Waiting and Frozen pairs in the check 2365 list and triggered check queue for the same component as the 2366 nominated pairs for that media stream. 2368 * If an In-Progress pair in the check list is for the same 2369 component as a nominated pair, the agent SHOULD cease 2370 retransmissions for its check if its pair priority is lower 2371 than the lowest-priority nominated pair for that component. 2373 o Once there is at least one nominated pair in the valid list for 2374 every component of at least one media stream and the state of the 2375 check list is Running: 2377 * The agent MUST change the state of processing for its check 2378 list for that media stream to Completed. 2380 * The agent MUST continue to respond to any checks it may still 2381 receive for that media stream, and MUST perform triggered 2382 checks if required by the processing of Section 7.2. 2384 * The agent MUST continue retransmitting any In-Progress checks 2385 for that check list. 2387 * The agent MAY begin transmitting media for this media stream as 2388 described in Section 11.1. 2390 o Once the state of each check list is Completed: 2392 * The agent sets the state of ICE processing overall to 2393 Completed. 2395 * If the controlling agent is using an aggressive nomination 2396 algorithm, this may result in several updated offers as the 2397 pairs selected for media change. An agent MAY delay sending 2398 the offer for a brief interval (one second is RECOMMENDED) in 2399 order to allow the selected pairs to stabilize. 2401 o If the state of the check list is Failed, ICE has not been able to 2402 complete for this media stream. The correct behavior depends on 2403 the state of the check lists for other media streams: 2405 * If all check lists are Failed, ICE processing overall is 2406 considered to be in the Failed state, and the agent SHOULD 2407 consider the session a failure, SHOULD NOT restart ICE, and the 2408 controlling agent SHOULD terminate the entire session. 2410 * If at least one of the check lists for other media streams is 2411 Completed, the controlling agent SHOULD remove the failed media 2412 stream from the session in its updated offer. 2414 * If none of the check lists for other media streams are 2415 Completed, but at least one is Running, the agent SHOULD let 2416 ICE continue. 2418 8.2. Procedures for Lite Implementations 2420 Concluding ICE for a lite implementation is relatively 2421 straightforward. There are two cases to consider: 2423 The implementation is lite, and its peer is full. 2425 The implementation is lite, and its peer is lite. 2427 The effect of ICE concluding is that the agent can free any allocated 2428 host candidates that were not utilized by ICE, as described in 2429 Section 8.3. 2431 8.2.1. Peer Is Full 2433 In this case, the agent will receive connectivity checks from its 2434 peer. When an agent has received a connectivity check that includes 2435 the USE-CANDIDATE attribute for each component of a media stream, the 2436 state of ICE processing for that media stream moves from Running to 2437 Completed. When the state of ICE processing for all media streams is 2438 Completed, the state of ICE processing overall is Completed. 2440 The lite implementation will never itself determine that ICE 2441 processing has failed for a media stream; rather, the full peer will 2442 make that determination and then remove or restart the failed media 2443 stream in a subsequent offer. 2445 8.2.2. Peer Is Lite 2447 Once the offer/answer exchange has completed, both agents examine 2448 their candidates and those of its peer. For each media stream, each 2449 agent pairs up its own candidates with the candidates of its peer for 2450 that media stream. Two candidates are paired up when they are for 2451 the same component, utilize the same transport protocol (UDP in this 2452 specification), and are from the same IP address family (IPv4 or 2453 IPv6). 2455 o If there is a single pair per component, that pair is added to the 2456 Valid list. If all of the components for a media stream had one 2457 pair, the state of ICE processing for that media stream is set to 2458 Completed. If all media streams are Completed, the state of ICE 2459 processing is set to Completed overall. This will always be the 2460 case for implementations that are IPv4-only. 2462 o If there is more than one pair per component: 2464 * The agent MUST select a pair based on local policy. Since this 2465 case only arises for IPv6, it is RECOMMENDED that an agent 2466 follow the procedures of RFC 6724 [RFC6724] to select a single 2467 pair. 2469 * The agent adds the selected pair for each component to the 2470 valid list. As described in Section 11.1, this will permit 2471 media to begin flowing. However, it is possible (and in fact 2472 likely) that both agents have chosen different pairs. 2474 * To reconcile this, the controlling agent MUST send an updated 2475 offer which will include the remote-candidates attribute. 2477 * The agent MUST NOT update the state of ICE processing when the 2478 offer is sent. If this subsequent offer completes, the 2479 controlling agent MUST change the state of ICE processing to 2480 Completed for all media streams, and the state of ICE 2481 processing overall to Completed. 2483 8.3. Freeing Candidates 2485 8.3.1. Full Implementation Procedures 2487 The procedures in Section 8 require that an agent continue to listen 2488 for STUN requests and continue to generate triggered checks for a 2489 media stream, even once processing for that stream completes. The 2490 rules in this section describe when it is safe for an agent to cease 2491 sending or receiving checks on a candidate that was not selected by 2492 ICE, and then free the candidate. 2494 8.3.2. Lite Implementation Procedures 2496 A lite implementation MAY free candidates not selected by ICE as soon 2497 as ICE processing has reached the Completed state for all peers for 2498 all media streams using those candidates. 2500 9. ICE Restarts 2502 An agent MAY restart ICE processing for an existing media stream. An 2503 ICE restart, as the name implies, will cause all previous states of 2504 ICE processing to be flushed and checks to start anew. The only 2505 difference between an ICE restart and a brand new media session is 2506 that, during the restart, media can continue to be sent to the 2507 previously validated pair. 2509 An agent MUST restart ICE for a media stream if: 2511 o The offer is being generated for the purposes of changing the 2512 target of the media stream. In other words, if an agent wants to 2513 generate an updated offer that, had ICE not been in use, would 2514 result in a new value for the destination of a media component. 2516 o An agent is changing its implementation level. This typically 2517 only happens in third party call control use cases, where the 2518 entity performing the signaling is not the entity receiving the 2519 media, and it has changed the target of media mid-session to 2520 another entity that has a different ICE implementation. 2522 To restart ICE, an agent MUST change both the password and the user 2523 name fragment for the media stream in an offer. The set of 2524 candidates in the new offer MAY include some, none, or all of the 2525 previous candidates for that stream and MAY include a totally new set 2526 of candidates 2528 10. Keepalives 2530 All endpoints MUST send keepalives for each media session. These 2531 keepalives serve the purpose of keeping NAT bindings alive for the 2532 media session. These keepalives MUST be sent even if ICE is not 2533 being utilized for the session at all. The keepalive SHOULD be sent 2534 using a format that is supported by its peer. ICE endpoints allow 2535 for STUN-based keepalives for UDP streams, and as such, STUN 2536 keepalives MUST be used when an agent is a full ICE implementation 2537 and is communicating with a peer that supports ICE (lite or full). 2538 If the peer does not support ICE, the choice of a packet format for 2539 keepalives is a matter of local implementation. A format that allows 2540 packets to easily be sent in the absence of actual media content is 2541 RECOMMENDED. Examples of formats that readily meet this goal are RTP 2542 No-Op [I-D.ietf-avt-rtp-no-op], and in cases where both sides support 2543 it, RTP comfort noise [RFC3389]. If the peer doesn't support any 2544 formats that are particularly well suited for keepalives, an agent 2545 SHOULD send RTP packets with an incorrect version number, or some 2546 other form of error that would cause them to be discarded by the 2547 peer. 2549 If there has been no packet sent on the candidate pair ICE is using 2550 for a media component for Tr seconds (where packets include those 2551 defined for the component (RTP or RTCP) and previous keepalives), an 2552 agent MUST generate a keepalive on that pair. Tr SHOULD be 2553 configurable and SHOULD have a default of 15 seconds. Tr MUST NOT be 2554 configured to less than 15 seconds. Alternatively, if an agent has a 2555 dynamic way to discover the binding lifetimes of the intervening 2556 NATs, it can use that value to determine Tr. Administrators 2557 deploying ICE in more controlled networking environments SHOULD set 2558 Tr to the longest duration possible in their environment. 2560 If STUN is being used for keepalives, a STUN Binding Indication is 2561 used [RFC5389]. The Indication MUST NOT utilize any authentication 2562 mechanism. It SHOULD contain the FINGERPRINT attribute to aid in 2563 demultiplexing, but SHOULD NOT contain any other attributes. It is 2564 used solely to keep the NAT bindings alive. The Binding Indication 2565 is sent using the same local and remote candidates that are being 2566 used for media. Though Binding Indications are used for keepalives, 2567 an agent MUST be prepared to receive a connectivity check as well. 2568 If a connectivity check is received, a response is generated as 2569 discussed in [RFC5389], but there is no impact on ICE processing 2570 otherwise. 2572 An agent MUST begin the keepalive processing once ICE has selected 2573 candidates for usage with media, or media begins to flow, whichever 2574 happens first. Keepalives end once the session terminates or the 2575 media stream is removed. 2577 11. Media Handling 2579 11.1. Sending Media 2581 Procedures for sending media differ for full and lite 2582 implementations. 2584 11.1.1. Procedures for Full Implementations 2586 Agents always send media using a candidate pair, called the selected 2587 candidate pair. An agent will send media to the remote candidate in 2588 the selected pair (setting the destination address and port of the 2589 packet equal to that remote candidate), and will send it from the 2590 local candidate of the selected pair. When the local candidate is 2591 server or peer reflexive, media is originated from the base. Media 2592 sent from a relayed candidate is sent from the base through that TURN 2593 server, using procedures defined in [RFC5766]. 2595 If the local candidate is a relayed candidate, it is RECOMMENDED that 2596 an agent create a channel on the TURN server towards the remote 2597 candidate. This is done using the procedures for channel creation as 2598 defined in Section 11 of [RFC5766]. 2600 The selected pair for a component of a media stream is: 2602 o empty if the state of the check list for that media stream is 2603 Running, and there is no previous selected pair for that component 2604 due to an ICE restart 2606 o equal to the previous selected pair for a component of a media 2607 stream if the state of the check list for that media stream is 2608 Running, and there was a previous selected pair for that component 2609 due to an ICE restart 2611 o equal to the highest-priority nominated pair for that component in 2612 the valid list if the state of the check list is Completed 2614 If the selected pair for at least one component of a media stream is 2615 empty, an agent MUST NOT send media for any component of that media 2616 stream. If the selected pair for each component of a media stream 2617 has a value, an agent MAY send media for all components of that media 2618 stream. 2620 11.1.2. Procedures for Lite Implementations 2622 A lite implementation MUST NOT send media until it has a Valid list 2623 that contains a candidate pair for each component of that media 2624 stream. Once that happens, the agent MAY begin sending media 2625 packets. To do that, it sends media to the remote candidate in the 2626 pair (setting the destination address and port of the packet equal to 2627 that remote candidate), and will send it from the local candidate. 2629 11.1.3. Procedures for All Implementations 2631 ICE has interactions with jitter buffer adaptation mechanisms. An 2632 RTP stream can begin using one candidate, and switch to another one, 2633 though this happens rarely with ICE. The newer candidate may result 2634 in RTP packets taking a different path through the network -- one 2635 with different delay characteristics. As discussed below, agents are 2636 encouraged to re-adjust jitter buffers when there are changes in 2637 source or destination address of media packets. Furthermore, many 2638 audio codecs use the marker bit to signal the beginning of a 2639 talkspurt, for the purposes of jitter buffer adaptation. For such 2640 codecs, it is RECOMMENDED that the sender set the marker bit 2641 [RFC3550] when an agent switches transmission of media from one 2642 candidate pair to another. 2644 11.2. Receiving Media 2646 ICE implementations MUST be prepared to receive media on each 2647 component on any candidates provided for that component in the most 2648 recent offer/answer exchange (in the case of RTP, this would include 2649 both RTP and RTCP if candidates were provided for both). 2651 It is RECOMMENDED that, when an agent receives an RTP packet with a 2652 new source or destination IP address for a particular media stream, 2653 that the agent re-adjust its jitter buffers. 2655 RFC 3550 [RFC3550] describes an algorithm in Section 8.2 for 2656 detecting synchronization source (SSRC) collisions and loops. These 2657 algorithms are based, in part, on seeing different source transport 2658 addresses with the same SSRC. However, when ICE is used, such 2659 changes will sometimes occur as the media streams switch between 2660 candidates. An agent will be able to determine that a media stream 2661 is from the same peer as a consequence of the STUN exchange that 2662 proceeds media transmission. Thus, if there is a change in source 2663 transport address, but the media packets come from the same peer 2664 agent, this SHOULD NOT be treated as an SSRC collision. 2666 12. Extensibility Considerations 2668 This specification makes very specific choices about how both agents 2669 in a session coordinate to arrive at the set of candidate pairs that 2670 are selected for media. It is anticipated that future specifications 2671 will want to alter these algorithms, whether they are simple changes 2672 like timer tweaks or larger changes like a revamp of the priority 2673 algorithm. When such a change is made, providing interoperability 2674 between the two agents in a session is critical. 2676 First, ICE provides the ice-options attribute. Each extension or 2677 change to ICE is associated with a token. When an agent supporting 2678 such an extension or change generates an offer or an answer, it MUST 2679 include the token for that extension in this attribute. This allows 2680 each side to know what the other side is doing. This attribute MUST 2681 NOT be present if the agent doesn't support any ICE extensions or 2682 changes. 2684 One of the complications in achieving interoperability is that ICE 2685 relies on a distributed algorithm running on both agents to converge 2686 on an agreed set of candidate pairs. If the two agents run different 2687 algorithms, it can be difficult to guarantee convergence on the same 2688 candidate pairs. The regular nomination procedure described in 2689 Section 8 eliminates some of the tight coordination by delegating the 2690 selection algorithm completely to the controlling agent. 2691 Consequently, when a controlling agent is communicating with a peer 2692 that supports options it doesn't know about, the agent MUST run a 2693 regular nomination algorithm. When regular nomination is used, ICE 2694 will converge perfectly even when both agents use different pair 2695 prioritization algorithms. One of the keys to such convergence is 2696 triggered checks, which ensure that the nominated pair is validated 2697 by both agents. Consequently, any future ICE enhancements MUST 2698 preserve triggered checks. 2700 ICE is also extensible to other media streams beyond RTP, and for 2701 transport protocols beyond UDP. Extensions to ICE for non-RTP media 2702 streams need to specify how many components they utilize, and assign 2703 component IDs to them, starting at 1 for the most important component 2704 ID. Specifications for new transport protocols must define how, if 2705 at all, various steps in the ICE processing differ from UDP. 2707 13. Setting Ta and RTO 2709 During the gathering phase of ICE (Section 4.1.1) and while ICE is 2710 performing connectivity checks (Section 7), an agent sends STUN and 2711 TURN transactions. These transactions are paced at a rate of one 2712 every Ta milliseconds, and utilize a specific RTO. This section 2713 describes how the values of Ta and RTO are computed. This 2714 computation depends on whether ICE is being used with a real-time 2715 media stream (such as RTP) or something else. When ICE is used for a 2716 stream with a known maximum bandwidth, the computation in 2717 Section 13.1 MAY be followed to rate-control the ICE exchanges. For 2718 all other streams, the computation in Section 13.2 MUST be followed. 2720 13.1. Real-time Media Streams 2722 The values of RTO and Ta change during the lifetime of ICE 2723 processing. One set of values applies during the gathering phase, 2724 and the other, for connectivity checks. 2726 The value of Ta SHOULD be configurable, and SHOULD have a default of: 2728 For each media stream i: 2729 Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime 2731 1 2732 Ta = MAX (20ms, ------------------- ) 2733 k 2734 ---- 2735 \ 1 2736 > ------ 2737 / Ta_i 2738 ---- 2739 i=1 2741 where k is the number of media streams. During the gathering phase, 2742 Ta is computed based on the number of media streams the agent has 2743 indicated in its offer or answer, and the RTP packet size and RTP 2744 ptime are those of the most preferred codec for each media stream. 2746 Once an offer and answer have been exchanged, the agent recomputes Ta 2747 to pace the connectivity checks. In that case, the value of Ta is 2748 based on the number of media streams that will actually be used in 2749 the session, and the RTP packet size and RTP ptime are those of the 2750 most preferred codec with which the agent will send. 2752 In addition, the retransmission timer for the STUN transactions, RTO, 2753 defined in [RFC5389], SHOULD be configurable and during the gathering 2754 phase, SHOULD have a default of: 2756 RTO = MAX (100ms, Ta * (number of pairs)) 2758 where the number of pairs refers to the number of pairs of candidates 2759 with STUN or TURN servers. 2761 For connectivity checks, RTO SHOULD be configurable and SHOULD have a 2762 default of: 2764 RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress)) 2766 where Num-Waiting is the number of checks in the check list in the 2767 Waiting state, and Num-In-Progress is the number of checks in the In- 2768 Progress state. Note that the RTO will be different for each 2769 transaction as the number of checks in the Waiting and In-Progress 2770 states change. 2772 These formulas are aimed at causing STUN transactions to be paced at 2773 the same rate as media. This ensures that ICE will work properly 2774 under the same network conditions needed to support the media as 2775 well. See Appendix B.1 for additional discussion and motivations. 2776 Because of this pacing, it will take a certain amount of time to 2777 obtain all of the server reflexive and relayed candidates. 2778 Implementations should be aware of the time required to do this, and 2779 if the application requires a time budget, limit the number of 2780 candidates that are gathered. 2782 The formulas result in a behavior whereby an agent will send its 2783 first packet for every single connectivity check before performing a 2784 retransmit. This can be seen in the formulas for the RTO (which 2785 represents the retransmit interval). Those formulas scale with N, 2786 the number of checks to be performed. As a result of this, ICE 2787 maintains a nicely constant rate, but becomes more sensitive to 2788 packet loss. The loss of the first single packet for any 2789 connectivity check is likely to cause that pair to take a long time 2790 to be validated, and instead, a lower-priority check (but one for 2791 which there was no packet loss) is much more likely to complete 2792 first. This results in ICE performing sub-optimally, choosing lower- 2793 priority pairs over higher-priority pairs. Implementors should be 2794 aware of this consequence, but still should utilize the timer values 2795 described here. 2797 13.2. Non-real-time Sessions 2799 In cases where ICE is used to establish some kind of session that is 2800 not real time, and has no fixed rate associated with it that is known 2801 to work on the network in which ICE is deployed, Ta and RTO revert to 2802 more conservative values. Ta SHOULD be configurable, SHOULD have a 2803 default of 500 ms, and MUST NOT be configurable to be less than 500 2804 ms. 2806 If other Ta value than the default is used, the agent MUST indicate 2807 the value it prefers to use in the ICE exchange. Both agents MUST 2808 use the higher out of the two proposed values. 2810 In addition, the retransmission timer for the STUN transactions, RTO, 2811 SHOULD be configurable and during the gathering phase, SHOULD have a 2812 default of: 2814 RTO = MAX (500ms, Ta * (number of pairs)) 2816 where the number of pairs refers to the number of pairs of candidates 2817 with STUN or TURN servers. 2819 For connectivity checks, RTO SHOULD be configurable and SHOULD have a 2820 default of: 2822 RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress)) 2824 14. Example 2826 The example is based on the simplified topology of Figure 8. 2828 +-------+ 2829 |STUN | 2830 |Server | 2831 +-------+ 2832 | 2833 +---------------------+ 2834 | | 2835 | Internet | 2836 | | 2837 +---------------------+ 2838 | | 2839 | | 2840 +---------+ | 2841 | NAT | | 2842 +---------+ | 2843 | | 2844 | | 2845 +-----+ +-----+ 2846 | L | | R | 2847 +-----+ +-----+ 2849 Figure 8: Example Topology 2851 Two agents, L and R, are using ICE. Both are full-mode ICE 2852 implementations and use aggressive nomination when they are 2853 controlling. Both agents have a single IPv4 address. For agent L, 2854 it is 10.0.1.1 in private address space [RFC1918], and for agent R, 2855 192.0.2.1 on the public Internet. Both are configured with the same 2856 STUN server (shown in this example for simplicity, although in 2857 practice the agents do not need to use the same STUN server), which 2858 is listening for STUN Binding requests at an IP address of 192.0.2.2 2859 and port 3478. TURN servers are not used in this example. Agent L 2860 is behind a NAT, and agent R is on the public Internet. The NAT has 2861 an endpoint independent mapping property and an address dependent 2862 filtering property. The public side of the NAT has an IP address of 2863 192.0.2.3. 2865 To facilitate understanding, transport addresses are listed using 2866 variables that have mnemonic names. The format of the name is 2867 entity-type-seqno, where entity refers to the entity whose IP address 2868 the transport address is on, and is one of "L", "R", "STUN", or 2869 "NAT". The type is either "PUB" for transport addresses that are 2870 public, and "PRIV" for transport addresses that are private. 2871 Finally, seq-no is a sequence number that is different for each 2872 transport address of the same type on a particular entity. Each 2873 variable has an IP address and port, denoted by varname.IP and 2874 varname.PORT, respectively, where varname is the name of the 2875 variable. 2877 The STUN server has advertised transport address STUN-PUB-1 (which is 2878 192.0.2.2:3478). 2880 In the call flow itself, STUN messages are annotated with several 2881 attributes. The "S=" attribute indicates the source transport 2882 address of the message. The "D=" attribute indicates the destination 2883 transport address of the message. The "MA=" attribute is used in 2884 STUN Binding response messages and refers to the mapped address. 2885 "USE-CAND" implies the presence of the USE-CANDIDATE attribute. 2887 The call flow examples omit STUN authentication operations and RTCP, 2888 and focus on RTP for a single media stream between two full 2889 implementations. 2891 L NAT STUN R 2892 |RTP STUN alloc. | | 2893 |(1) STUN Req | | | 2894 |S=$L-PRIV-1 | | | 2895 |D=$STUN-PUB-1 | | | 2896 |------------->| | | 2897 | |(2) STUN Req | | 2898 | |S=$NAT-PUB-1 | | 2899 | |D=$STUN-PUB-1 | | 2900 | |------------->| | 2901 | |(3) STUN Res | | 2902 | |S=$STUN-PUB-1 | | 2903 | |D=$NAT-PUB-1 | | 2904 | |MA=$NAT-PUB-1 | | 2905 | |<-------------| | 2906 |(4) STUN Res | | | 2907 |S=$STUN-PUB-1 | | | 2908 |D=$L-PRIV-1 | | | 2909 |MA=$NAT-PUB-1 | | | 2910 |<-------------| | | 2911 |(5) Offer | | | 2912 |------------------------------------------->| 2913 | | | | RTP STUN 2914 | | | | alloc. 2915 | | |(6) STUN Req | 2916 | | |S=$R-PUB-1 | 2917 | | |D=$STUN-PUB-1 | 2918 | | |<-------------| 2919 | | |(7) STUN Res | 2920 | | |S=$STUN-PUB-1 | 2921 | | |D=$R-PUB-1 | 2922 | | |MA=$R-PUB-1 | 2923 | | |------------->| 2924 |(8) answer | | | 2925 |<-------------------------------------------| 2926 | |(9) Bind Req | |Begin 2927 | |S=$R-PUB-1 | |Connectivity 2928 | |D=L-PRIV-1 | |Checks 2929 | |<----------------------------| 2930 | |Dropped | | 2931 |(10) Bind Req | | | 2932 |S=$L-PRIV-1 | | | 2933 |D=$R-PUB-1 | | | 2934 |USE-CAND | | | 2935 |------------->| | | 2936 | |(11) Bind Req | | 2937 | |S=$NAT-PUB-1 | | 2938 | |D=$R-PUB-1 | | 2939 | |USE-CAND | | 2940 | |---------------------------->| 2941 | |(12) Bind Res | | 2942 | |S=$R-PUB-1 | | 2943 | |D=$NAT-PUB-1 | | 2944 | |MA=$NAT-PUB-1 | | 2945 | |<----------------------------| 2946 |(13) Bind Res | | | 2947 |S=$R-PUB-1 | | | 2948 |D=$L-PRIV-1 | | | 2949 |MA=$NAT-PUB-1 | | | 2950 |<-------------| | | 2951 |RTP flows | | | 2952 | |(14) Bind Req | | 2953 | |S=$R-PUB-1 | | 2954 | |D=$NAT-PUB-1 | | 2955 | |<----------------------------| 2956 |(15) Bind Req | | | 2957 |S=$R-PUB-1 | | | 2958 |D=$L-PRIV-1 | | | 2959 |<-------------| | | 2960 |(16) Bind Res | | | 2961 |S=$L-PRIV-1 | | | 2962 |D=$R-PUB-1 | | | 2963 |MA=$R-PUB-1 | | | 2964 |------------->| | | 2965 | |(17) Bind Res | | 2966 | |S=$NAT-PUB-1 | | 2967 | |D=$R-PUB-1 | | 2968 | |MA=$R-PUB-1 | | 2969 | |---------------------------->| 2970 | | | |RTP flows 2971 Figure 9: Example Flow 2973 First, agent L obtains a host candidate from its local IP address 2974 (not shown), and from that, sends a STUN Binding request to the STUN 2975 server to get a server reflexive candidate (messages 1-4). Recall 2976 that the NAT has the address and port independent mapping property. 2977 Here, it creates a binding of NAT-PUB-1 for this UDP request, and 2978 this becomes the server reflexive candidate for RTP. 2980 Agent L sets a type preference of 126 for the host candidate and 100 2981 for the server reflexive. The local preference is 65535. Based on 2982 this, the priority of the host candidate is 2130706431 and for the 2983 server reflexive candidate is 1694498815. The host candidate is 2984 assigned a foundation of 1, and the server reflexive, a foundation of 2985 2. These are sent to the peer in an offer. 2987 This offer is received at agent R. Agent R will obtain a host 2988 candidate, and from it, obtain a server reflexive candidate (messages 2989 6-7). Since R is not behind a NAT, this candidate is identical to 2990 its host candidate, and they share the same base. It therefore 2991 discards this redundant candidate and ends up with a single host 2992 candidate. With identical type and local preferences as L, the 2993 priority for this candidate is 2130706431. It chooses a foundation 2994 of 1 for its single candidate. The answerer's candidates are then 2995 sent to the offerer. 2997 Since neither side indicated that it is lite, the agent that sent the 2998 offer that began ICE processing (agent L) becomes the controlling 2999 agent. 3001 Agents L and R both pair up the candidates. They both initially have 3002 two pairs. However, agent L will prune the pair containing its 3003 server reflexive candidate, resulting in just one. At agent L, this 3004 pair has a local candidate of $L_PRIV_1 and remote candidate of 3005 $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that 3006 an implementation would represent this as a 64-bit integer so as not 3007 to lose precision). At agent R, there are two pairs. The highest 3008 priority has a local candidate of $R_PUB_1 and remote candidate of 3009 $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a 3010 local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and 3011 priority 3.63891E+18. 3013 Agent R begins its connectivity check (message 9) for the first pair 3014 (between the two host candidates). Since R is the controlled agent 3015 for this session, the check omits the USE-CANDIDATE attribute. The 3016 host candidate from agent L is private and behind a NAT, and thus 3017 this check won't be successful, because the packet cannot be routed 3018 from R to L. 3020 When agent L gets the answer, it performs its one and only 3021 connectivity check (messages 10-13). It implements the aggressive 3022 nomination algorithm, and thus includes a USE-CANDIDATE attribute in 3023 this check. Since the check succeeds, agent L creates a new pair, 3024 whose local candidate is from the mapped address in the Binding 3025 response (NAT-PUB-1 from message 13) and whose remote candidate is 3026 the destination of the request (R-PUB-1 from message 10). This is 3027 added to the valid list. In addition, it is marked as selected since 3028 the Binding request contained the USE-CANDIDATE attribute. Since 3029 there is a selected candidate in the Valid list for the one component 3030 of this media stream, ICE processing for this stream moves into the 3031 Completed state. Agent L can now send media if it so chooses. 3033 Soon after receipt of the STUN Binding request from agent L (message 3034 11), agent R will generate its triggered check. This check happens 3035 to match the next one on its check list -- from its host candidate to 3036 agent L's server reflexive candidate. This check (messages 14-17) 3037 will succeed. Consequently, agent R constructs a new candidate pair 3038 using the mapped address from the response as the local candidate (R- 3039 PUB-1) and the destination of the request (NAT-PUB-1) as the remote 3040 candidate. This pair is added to the Valid list for that media 3041 stream. Since the check was generated in the reverse direction of a 3042 check that contained the USE-CANDIDATE attribute, the candidate pair 3043 is marked as selected. Consequently, processing for this stream 3044 moves into the Completed state, and agent R can also send media. 3046 15. Security Considerations 3048 There are several types of attacks possible in an ICE system. This 3049 section considers these attacks and their countermeasures. These 3050 countermeasures include: 3052 o Using ICE in conjunction with secure signaling techniques, such as 3053 SIPS. 3055 o Limiting the total number of connectivity checks to 100, and 3056 optionally limiting the number of candidates they'll accept in an 3057 offer or answer. 3059 15.1. Attacks on Connectivity Checks 3061 An attacker might attempt to disrupt the STUN connectivity checks. 3062 Ultimately, all of these attacks fool an agent into thinking 3063 something incorrect about the results of the connectivity checks. 3064 The possible false conclusions an attacker can try and cause are: 3066 False Invalid: An attacker can fool a pair of agents into thinking a 3067 candidate pair is invalid, when it isn't. This can be used to 3068 cause an agent to prefer a different candidate (such as one 3069 injected by the attacker) or to disrupt a call by forcing all 3070 candidates to fail. 3072 False Valid: An attacker can fool a pair of agents into thinking a 3073 candidate pair is valid, when it isn't. This can cause an agent 3074 to proceed with a session, but then not be able to receive any 3075 media. 3077 False Peer Reflexive Candidate: An attacker can cause an agent to 3078 discover a new peer reflexive candidate, when it shouldn't have. 3079 This can be used to redirect media streams to a Denial-of-Service 3080 (DoS) target or to the attacker, for eavesdropping or other 3081 purposes. 3083 False Valid on False Candidate: An attacker has already convinced an 3084 agent that there is a candidate with an address that doesn't 3085 actually route to that agent (for example, by injecting a false 3086 peer reflexive candidate or false server reflexive candidate). It 3087 must then launch an attack that forces the agents to believe that 3088 this candidate is valid. 3090 If an attacker can cause a false peer reflexive candidate or false 3091 valid on a false candidate, it can launch any of the attacks 3092 described in [RFC5389]. 3094 To force the false invalid result, the attacker has to wait for the 3095 connectivity check from one of the agents to be sent. When it is, 3096 the attacker needs to inject a fake response with an unrecoverable 3097 error response, such as a 400. However, since the candidate is, in 3098 fact, valid, the original request may reach the peer agent, and 3099 result in a success response. The attacker needs to force this 3100 packet or its response to be dropped, through a DoS attack, layer 2 3101 network disruption, or other technique. If it doesn't do this, the 3102 success response will also reach the originator, alerting it to a 3103 possible attack. Fortunately, this attack is mitigated completely 3104 through the STUN short-term credential mechanism. The attacker needs 3105 to inject a fake response, and in order for this response to be 3106 processed, the attacker needs the password. If the offer/answer 3107 signaling is secured, the attacker will not have the password and its 3108 response will be discarded. 3110 Forcing the fake valid result works in a similar way. The agent 3111 needs to wait for the Binding request from each agent, and inject a 3112 fake success response. The attacker won't need to worry about 3113 disrupting the actual response since, if the candidate is not valid, 3114 it presumably wouldn't be received anyway. However, like the fake 3115 invalid attack, this attack is mitigated by the STUN short-term 3116 credential mechanism in conjunction with a secure offer/answer 3117 exchange. 3119 Forcing the false peer reflexive candidate result can be done either 3120 with fake requests or responses, or with replays. We consider the 3121 fake requests and responses case first. It requires the attacker to 3122 send a Binding request to one agent with a source IP address and port 3123 for the false candidate. In addition, the attacker must wait for a 3124 Binding request from the other agent, and generate a fake response 3125 with a XOR-MAPPED-ADDRESS attribute containing the false candidate. 3126 Like the other attacks described here, this attack is mitigated by 3127 the STUN message integrity mechanisms and secure offer/answer 3128 exchanges. 3130 Forcing the false peer reflexive candidate result with packet replays 3131 is different. The attacker waits until one of the agents sends a 3132 check. It intercepts this request, and replays it towards the other 3133 agent with a faked source IP address. It must also prevent the 3134 original request from reaching the remote agent, either by launching 3135 a DoS attack to cause the packet to be dropped, or forcing it to be 3136 dropped using layer 2 mechanisms. The replayed packet is received at 3137 the other agent, and accepted, since the integrity check passes (the 3138 integrity check cannot and does not cover the source IP address and 3139 port). It is then responded to. This response will contain a XOR- 3140 MAPPED-ADDRESS with the false candidate, and will be sent to that 3141 false candidate. The attacker must then receive it and relay it 3142 towards the originator. 3144 The other agent will then initiate a connectivity check towards that 3145 false candidate. This validation needs to succeed. This requires 3146 the attacker to force a false valid on a false candidate. Injecting 3147 of fake requests or responses to achieve this goal is prevented using 3148 the integrity mechanisms of STUN and the offer/answer exchange. 3149 Thus, this attack can only be launched through replays. To do that, 3150 the attacker must intercept the check towards this false candidate, 3151 and replay it towards the other agent. Then, it must intercept the 3152 response and replay that back as well. 3154 This attack is very hard to launch unless the attacker is identified 3155 by the fake candidate. This is because it requires the attacker to 3156 intercept and replay packets sent by two different hosts. If both 3157 agents are on different networks (for example, across the public 3158 Internet), this attack can be hard to coordinate, since it needs to 3159 occur against two different endpoints on different parts of the 3160 network at the same time. 3162 If the attacker itself is identified by the fake candidate, the 3163 attack is easier to coordinate. However, if the media path is 3164 secured (e.g., using SRTP [RFC3711]), the attacker will not be able 3165 to play the media packets, but will only be able to discard them, 3166 effectively disabling the media stream for the call. However, this 3167 attack requires the agent to disrupt packets in order to block the 3168 connectivity check from reaching the target. In that case, if the 3169 goal is to disrupt the media stream, it's much easier to just disrupt 3170 it with the same mechanism, rather than attack ICE. 3172 15.2. Attacks on Server Reflexive Address Gathering 3174 ICE endpoints make use of STUN Binding requests for gathering server 3175 reflexive candidates from a STUN server. These requests are not 3176 authenticated in any way. As a consequence, there are numerous 3177 techniques an attacker can employ to provide the client with a false 3178 server reflexive candidate: 3180 o An attacker can compromise the DNS, causing DNS queries to return 3181 a rogue STUN server address. That server can provide the client 3182 with fake server reflexive candidates. This attack is mitigated 3183 by DNS security, though DNS-SEC is not required to address it. 3185 o An attacker that can observe STUN messages (such as an attacker on 3186 a shared network segment, like WiFi) can inject a fake response 3187 that is valid and will be accepted by the client. 3189 o An attacker can compromise a STUN server by means of a virus, and 3190 cause it to send responses with incorrect mapped addresses. 3192 A false mapped address learned by these attacks will be used as a 3193 server reflexive candidate in the ICE exchange. For this candidate 3194 to actually be used for media, the attacker must also attack the 3195 connectivity checks, and in particular, force a false valid on a 3196 false candidate. This attack is very hard to launch if the false 3197 address identifies a fourth party (neither the offerer, answerer, nor 3198 attacker), since it requires attacking the checks generated by each 3199 agent in the session, and is prevented by SRTP if it identifies the 3200 attacker themself. 3202 If the attacker elects not to attack the connectivity checks, the 3203 worst it can do is prevent the server reflexive candidate from being 3204 used. However, if the peer agent has at least one candidate that is 3205 reachable by the agent under attack, the STUN connectivity checks 3206 themselves will provide a peer reflexive candidate that can be used 3207 for the exchange of media. Peer reflexive candidates are generally 3208 preferred over server reflexive candidates. As such, an attack 3209 solely on the STUN address gathering will normally have no impact on 3210 a session at all. 3212 15.3. Attacks on Relayed Candidate Gathering 3214 An attacker might attempt to disrupt the gathering of relayed 3215 candidates, forcing the client to believe it has a false relayed 3216 candidate. Exchanges with the TURN server are authenticated using a 3217 long-term credential. Consequently, injection of fake responses or 3218 requests will not work. In addition, unlike Binding requests, 3219 Allocate requests are not susceptible to replay attacks with modified 3220 source IP addresses and ports, since the source IP address and port 3221 are not utilized to provide the client with its relayed candidate. 3223 However, TURN servers are susceptible to DNS attacks, or to viruses 3224 aimed at the TURN server, for purposes of turning it into a zombie or 3225 rogue server. These attacks can be mitigated by DNS-SEC and through 3226 good box and software security on TURN servers. 3228 Even if an attacker has caused the client to believe in a false 3229 relayed candidate, the connectivity checks cause such a candidate to 3230 be used only if they succeed. Thus, an attacker must launch a false 3231 valid on a false candidate, per above, which is a very difficult 3232 attack to coordinate. 3234 15.4. Insider Attacks 3236 In addition to attacks where the attacker is a third party trying to 3237 insert fake offers, answers, or stun messages, there are attacks 3238 possible with ICE when the attacker is an authenticated and valid 3239 participant in the ICE exchange. 3241 15.4.1. STUN Amplification Attack 3243 The STUN amplification attack is similar to the voice hammer. 3244 However, instead of voice packets being directed to the target, STUN 3245 connectivity checks are directed to the target. The attacker sends 3246 an offer with a large number of candidates, say, 50. The answerer 3247 receives the offer, and starts its checks, which are directed at the 3248 target, and consequently, never generate a response. The answerer 3249 will start a new connectivity check every Ta ms (say, Ta=20ms). 3250 However, the retransmission timers are set to a large number due to 3251 the large number of candidates. As a consequence, packets will be 3252 sent at an interval of one every Ta milliseconds, and then with 3253 increasing intervals after that. Thus, STUN will not send packets at 3254 a rate faster than media would be sent, and the STUN packets persist 3255 only briefly, until ICE fails for the session. Nonetheless, this is 3256 an amplification mechanism. 3258 It is impossible to eliminate the amplification, but the volume can 3259 be reduced through a variety of heuristics. Agents SHOULD limit the 3260 total number of connectivity checks they perform to 100. 3261 Additionally, agents MAY limit the number of candidates they'll 3262 accept in an offer or answer. 3264 Frequently, protocols that wish to avoid these kinds of attacks force 3265 the initiator to wait for a response prior to sending the next 3266 message. However, in the case of ICE, this is not possible. It is 3267 not possible to differentiate the following two cases: 3269 o There was no response because the initiator is being used to 3270 launch a DoS attack against an unsuspecting target that will not 3271 respond. 3273 o There was no response because the IP address and port are not 3274 reachable by the initiator. 3276 In the second case, another check should be sent at the next 3277 opportunity, while in the former case, no further checks should be 3278 sent. 3280 16. STUN Extensions 3282 16.1. New Attributes 3284 This specification defines four new attributes, PRIORITY, USE- 3285 CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. 3287 The PRIORITY attribute indicates the priority that is to be 3288 associated with a peer reflexive candidate, should one be discovered 3289 by this check. It is a 32-bit unsigned integer, and has an attribute 3290 value of 0x0024. 3292 The USE-CANDIDATE attribute indicates that the candidate pair 3293 resulting from this check should be used for transmission of media. 3294 The attribute has no content (the Length field of the attribute is 3295 zero); it serves as a flag. It has an attribute value of 0x0025. 3297 The ICE-CONTROLLED attribute is present in a Binding request and 3298 indicates that the client believes it is currently in the controlled 3299 role. The content of the attribute is a 64-bit unsigned integer in 3300 network byte order, which contains a random number used for tie- 3301 breaking of role conflicts. 3303 The ICE-CONTROLLING attribute is present in a Binding request and 3304 indicates that the client believes it is currently in the controlling 3305 role. The content of the attribute is a 64-bit unsigned integer in 3306 network byte order, which contains a random number used for tie- 3307 breaking of role conflicts. 3309 16.2. New Error Response Codes 3311 This specification defines a single error response code: 3313 487 (Role Conflict): The Binding request contained either the ICE- 3314 CONTROLLING or ICE-CONTROLLED attribute, indicating a role that 3315 conflicted with the server. The server ran a tie-breaker based on 3316 the tie-breaker value in the request and determined that the 3317 client needs to switch roles. 3319 17. Operational Considerations 3321 This section discusses issues relevant to network operators looking 3322 to deploy ICE. 3324 17.1. NAT and Firewall Types 3326 ICE was designed to work with existing NAT and firewall equipment. 3327 Consequently, it is not necessary to replace or reconfigure existing 3328 firewall and NAT equipment in order to facilitate deployment of ICE. 3329 Indeed, ICE was developed to be deployed in environments where the 3330 Voice over IP (VoIP) operator has no control over the IP network 3331 infrastructure, including firewalls and NAT. 3333 That said, ICE works best in environments where the NAT devices are 3334 "behave" compliant, meeting the recommendations defined in [RFC4787] 3335 and [RFC5382]. In networks with behave-compliant NAT, ICE will work 3336 without the need for a TURN server, thus improving voice quality, 3337 decreasing call setup times, and reducing the bandwidth demands on 3338 the network operator. 3340 17.2. Bandwidth Requirements 3342 Deployment of ICE can have several interactions with available 3343 network capacity that operators should take into consideration. 3345 17.2.1. STUN and TURN Server Capacity Planning 3347 First and foremost, ICE makes use of TURN and STUN servers, which 3348 would typically be located in the network operator's data centers. 3349 The STUN servers require relatively little bandwidth. For each 3350 component of each media stream, there will be one or more STUN 3351 transactions from each client to the STUN server. In a basic voice- 3352 only IPv4 VoIP deployment, there will be four transactions per call 3353 (one for RTP and one for RTCP, for both caller and callee). Each 3354 transaction is a single request and a single response, the former 3355 being 20 bytes long, and the latter, 28. Consequently, if a system 3356 has N users, and each makes four calls in a busy hour, this would 3357 require N*1.7bps. For one million users, this is 1.7 Mbps, a very 3358 small number (relatively speaking). 3360 TURN traffic is more substantial. The TURN server will see traffic 3361 volume equal to the STUN volume (indeed, if TURN servers are 3362 deployed, there is no need for a separate STUN server), in addition 3363 to the traffic for the actual media traffic. The amount of calls 3364 requiring TURN for media relay is highly dependent on network 3365 topologies, and can and will vary over time. In a network with 100% 3366 behave-compliant NAT, it is exactly zero. At time of writing, large- 3367 scale consumer deployments were seeing between 5 and 10 percent of 3368 calls requiring TURN servers. Considering a voice-only deployment 3369 using G.711 (so 80 kbps in each direction), with .2 erlangs during 3370 the busy hour, this is N*3.2 kbps. For a population of one million 3371 users, this is 3.2 Gbps, assuming a 10% usage of TURN servers. 3373 17.2.2. Gathering and Connectivity Checks 3375 The process of gathering of candidates and performing of connectivity 3376 checks can be bandwidth intensive. ICE has been designed to pace 3377 both of these processes. The gathering phase and the connectivity 3378 check phase are meant to generate traffic at roughly the same 3379 bandwidth as the media traffic itself. This was done to ensure that, 3380 if a network is designed to support multimedia traffic of a certain 3381 type (voice, video, or just text), it will have sufficient capacity 3382 to support the ICE checks for that media. Of course, the ICE checks 3383 will cause a marginal increase in the total utilization; however, 3384 this will typically be an extremely small increase. 3386 Congestion due to the gathering and check phases has proven to be a 3387 problem in deployments that did not utilize pacing. Typically, 3388 access links became congested as the endpoints flooded the network 3389 with checks as fast as they can send them. Consequently, network 3390 operators should make sure that their ICE implementations support the 3391 pacing feature. Though this pacing does increase call setup times, 3392 it makes ICE network friendly and easier to deploy. 3394 17.2.3. Keepalives 3396 STUN keepalives (in the form of STUN Binding Indications) are sent in 3397 the middle of a media session. However, they are sent only in the 3398 absence of actual media traffic. In deployments that are not 3399 utilizing Voice Activity Detection (VAD), the keepalives are never 3400 used and there is no increase in bandwidth usage. When VAD is being 3401 used, keepalives will be sent during silence periods. This involves 3402 a single packet every 15-20 seconds, far less than the packet every 3403 20-30 ms that is sent when there is voice. Therefore, keepalives 3404 don't have any real impact on capacity planning. 3406 17.3. ICE and ICE-lite 3408 Deployments utilizing a mix of ICE and ICE-lite interoperate 3409 perfectly. They have been explicitly designed to do so, without loss 3410 of function. 3412 However, ICE-lite can only be deployed in limited use cases. Those 3413 cases, and the caveats involved in doing so, are documented in 3414 Appendix A. 3416 17.4. Troubleshooting and Performance Management 3418 ICE utilizes end-to-end connectivity checks, and places much of the 3419 processing in the endpoints. This introduces a challenge to the 3420 network operator -- how can they troubleshoot ICE deployments? How 3421 can they know how ICE is performing? 3423 ICE has built-in features to help deal with these problems. SIP 3424 servers on the signaling path, typically deployed in the data centers 3425 of the network operator, will see the contents of the offer/answer 3426 exchanges that convey the ICE parameters. These parameters include 3427 the type of each candidate (host, server reflexive, or relayed), 3428 along with their related addresses. Once ICE processing has 3429 completed, an updated offer/answer exchange takes place, signaling 3430 the selected address (and its type). This updated re-INVITE is 3431 performed exactly for the purposes of educating network equipment 3432 (such as a diagnostic tool attached to a SIP server) about the 3433 results of ICE processing. 3435 As a consequence, through the logs generated by the SIP server, a 3436 network operator can observe what types of candidates are being used 3437 for each call, and what address was selected by ICE. This is the 3438 primary information that helps evaluate how ICE is performing. 3440 17.5. Endpoint Configuration 3442 ICE relies on several pieces of data being configured into the 3443 endpoints. This configuration data includes timers, credentials for 3444 TURN servers, and hostnames for STUN and TURN servers. ICE itself 3445 does not provide a mechanism for this configuration. Instead, it is 3446 assumed that this information is attached to whatever mechanism is 3447 used to configure all of the other parameters in the endpoint. For 3448 SIP phones, standard solutions such as the configuration framework 3449 [RFC6080] have been defined. 3451 18. IANA Considerations 3453 The original ICE specification registered four new STUN attributes, 3454 and one new STUN error response. The STUN attributes and error 3455 response are reproduced here. 3457 18.1. STUN Attributes 3459 IANA has registered four STUN attributes: 3461 0x0024 PRIORITY 3462 0x0025 USE-CANDIDATE 3463 0x8029 ICE-CONTROLLED 3464 0x802A ICE-CONTROLLING 3466 18.2. STUN Error Responses 3468 IANA has registered following STUN error response code: 3470 487 Role Conflict: The client asserted an ICE role (controlling or 3471 controlled) that is in conflict with the role of the server. 3473 19. IAB Considerations 3475 The IAB has studied the problem of "Unilateral Self-Address Fixing", 3476 which is the general process by which a agent attempts to determine 3477 its address in another realm on the other side of a NAT through a 3478 collaborative protocol reflection mechanism [RFC3424]. ICE is an 3479 example of a protocol that performs this type of function. 3480 Interestingly, the process for ICE is not unilateral, but bilateral, 3481 and the difference has a significant impact on the issues raised by 3482 IAB. Indeed, ICE can be considered a B-SAF (Bilateral Self-Address 3483 Fixing) protocol, rather than an UNSAF protocol. Regardless, the IAB 3484 has mandated that any protocols developed for this purpose document a 3485 specific set of considerations. This section meets those 3486 requirements. 3488 19.1. Problem Definition 3490 >From RFC 3424, any UNSAF proposal must provide: 3492 Precise definition of a specific, limited-scope problem that is to 3493 be solved with the UNSAF proposal. A short-term fix should not be 3494 generalized to solve other problems; this is why "short-term fixes 3495 usually aren't". 3497 The specific problems being solved by ICE are: 3499 Provide a means for two peers to determine the set of transport 3500 addresses that can be used for communication. 3502 Provide a means for a agent to determine an address that is 3503 reachable by another peer with which it wishes to communicate. 3505 19.2. Exit Strategy 3507 >From RFC 3424, any UNSAF proposal must provide: 3509 Description of an exit strategy/transition plan. The better 3510 short-term fixes are the ones that will naturally see less and 3511 less use as the appropriate technology is deployed. 3513 ICE itself doesn't easily get phased out. However, it is useful even 3514 in a globally connected Internet, to serve as a means for detecting 3515 whether a router failure has temporarily disrupted connectivity, for 3516 example. ICE also helps prevent certain security attacks that have 3517 nothing to do with NAT. However, what ICE does is help phase out 3518 other UNSAF mechanisms. ICE effectively selects amongst those 3519 mechanisms, prioritizing ones that are better, and deprioritizing 3520 ones that are worse. Local IPv6 addresses can be preferred. As NATs 3521 begin to dissipate as IPv6 is introduced, server reflexive and 3522 relayed candidates (both forms of UNSAF addresses) simply never get 3523 used, because higher-priority connectivity exists to the native host 3524 candidates. Therefore, the servers get used less and less, and can 3525 eventually be remove when their usage goes to zero. 3527 Indeed, ICE can assist in the transition from IPv4 to IPv6. It can 3528 be used to determine whether to use IPv6 or IPv4 when two dual-stack 3529 hosts communicate with SIP (IPv6 gets used). It can also allow a 3530 network with both 6to4 and native v6 connectivity to determine which 3531 address to use when communicating with a peer. 3533 19.3. Brittleness Introduced by ICE 3535 >From RFC 3424, any UNSAF proposal must provide: 3537 Discussion of specific issues that may render systems more 3538 "brittle". For example, approaches that involve using data at 3539 multiple network layers create more dependencies, increase 3540 debugging challenges, and make it harder to transition. 3542 ICE actually removes brittleness from existing UNSAF mechanisms. In 3543 particular, classic STUN (as described in RFC 3489 [RFC3489]) has 3544 several points of brittleness. One of them is the discovery process 3545 that requires an agent to try to classify the type of NAT it is 3546 behind. This process is error-prone. With ICE, that discovery 3547 process is simply not used. Rather than unilaterally assessing the 3548 validity of the address, its validity is dynamically determined by 3549 measuring connectivity to a peer. The process of determining 3550 connectivity is very robust. 3552 Another point of brittleness in classic STUN and any other unilateral 3553 mechanism is its absolute reliance on an additional server. ICE 3554 makes use of a server for allocating unilateral addresses, but allows 3555 agents to directly connect if possible. Therefore, in some cases, 3556 the failure of a STUN server would still allow for a call to progress 3557 when ICE is used. 3559 Another point of brittleness in classic STUN is that it assumes that 3560 the STUN server is on the public Internet. Interestingly, with ICE, 3561 that is not necessary. There can be a multitude of STUN servers in a 3562 variety of address realms. ICE will discover the one that has 3563 provided a usable address. 3565 The most troubling point of brittleness in classic STUN is that it 3566 doesn't work in all network topologies. In cases where there is a 3567 shared NAT between each agent and the STUN server, traditional STUN 3568 may not work. With ICE, that restriction is removed. 3570 Classic STUN also introduces some security considerations. 3571 Fortunately, those security considerations are also mitigated by ICE. 3573 Consequently, ICE serves to repair the brittleness introduced in 3574 classic STUN, and does not introduce any additional brittleness into 3575 the system. 3577 The penalty of these improvements is that ICE increases session 3578 establishment times. 3580 19.4. Requirements for a Long-Term Solution 3582 From RFC 3424, any UNSAF proposal must provide: 3584 ... requirements for longer term, sound technical solutions -- 3585 contribute to the process of finding the right longer term 3586 solution. 3588 Our conclusions from RFC 3489 remain unchanged. However, we feel ICE 3589 actually helps because we believe it can be part of the long-term 3590 solution. 3592 19.5. Issues with Existing NAPT Boxes 3594 From RFC 3424, any UNSAF proposal must provide: 3596 Discussion of the impact of the noted practical issues with 3597 existing, deployed NA[P]Ts and experience reports. 3599 A number of NAT boxes are now being deployed into the market that try 3600 to provide "generic" ALG functionality. These generic ALGs hunt for 3601 IP addresses, either in text or binary form within a packet, and 3602 rewrite them if they match a binding. This interferes with classic 3603 STUN. However, the update to STUN [RFC5389] uses an encoding that 3604 hides these binary addresses from generic ALGs. 3606 Existing NAPT boxes have non-deterministic and typically short 3607 expiration times for UDP-based bindings. This requires 3608 implementations to send periodic keepalives to maintain those 3609 bindings. ICE uses a default of 15 s, which is a very conservative 3610 estimate. Eventually, over time, as NAT boxes become compliant to 3611 behave [RFC4787], this minimum keepalive will become deterministic 3612 and well-known, and the ICE timers can be adjusted. Having a way to 3613 discover and control the minimum keepalive interval would be far 3614 better still. 3616 20. Changes from RFC 5245 3618 Following is the list of changes from RFC 5245 3620 o The specification was generalized to be more usable with any 3621 protocol and the parts that are specific to SIP and SDP were moved 3622 to a SIP/SDP usage document [I-D.ietf-mmusic-ice-sip-sdp]. 3624 o Default candidates, multiple components, ICE mismatch detection, 3625 subsequent offer/answer, and role conflict resolution were made 3626 optional since they are not needed with every protocol using ICE. 3628 o With IPv6, the precedence rules of RFC 6724 are used instead of 3629 the obsoleted RFC 3483 and using address preferences provided by 3630 the host operating system is recommended. 3632 o Candidate gathering rules regarding loopback addresses and IPv6 3633 addresses were clarified. 3635 21. Acknowledgements 3637 Most of the text in this document comes from the original ICE 3638 specification, RFC 5245. The authors would like to thank everyone 3639 who has contributed to that document. For additional contributions 3640 to this revision of the specification we would like to thank Christer 3641 Holmberg, Emil Ivov, Paul Kyzivat, Pal-Erik Martinsen, Simon 3642 Perrault, Eric Rescorla, Thomas Stach, Peter Thatcher, Martin 3643 Thomson, Justin Uberti, and Suhas Nandakumar. 3645 22. References 3647 22.1. Normative References 3649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3650 Requirement Levels", BCP 14, RFC 2119, 3651 DOI 10.17487/RFC2119, March 1997, 3652 . 3654 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3655 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3656 DOI 10.17487/RFC5389, October 2008, 3657 . 3659 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 3660 Relays around NAT (TURN): Relay Extensions to Session 3661 Traversal Utilities for NAT (STUN)", RFC 5766, 3662 DOI 10.17487/RFC5766, April 2010, 3663 . 3665 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 3666 "Default Address Selection for Internet Protocol Version 6 3667 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 3668 . 3670 22.2. Informative References 3672 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 3673 in Session Description Protocol (SDP)", RFC 3605, 3674 DOI 10.17487/RFC3605, October 2003, 3675 . 3677 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3678 A., Peterson, J., Sparks, R., Handley, M., and E. 3679 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3680 DOI 10.17487/RFC3261, June 2002, 3681 . 3683 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 3684 with Session Description Protocol (SDP)", RFC 3264, 3685 DOI 10.17487/RFC3264, June 2002, 3686 . 3688 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 3689 "STUN - Simple Traversal of User Datagram Protocol (UDP) 3690 Through Network Address Translators (NATs)", RFC 3489, 3691 DOI 10.17487/RFC3489, March 2003, 3692 . 3694 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 3695 Application Design Guidelines", RFC 3235, 3696 DOI 10.17487/RFC3235, January 2002, 3697 . 3699 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 3700 A. Rayhan, "Middlebox communication architecture and 3701 framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, 3702 . 3704 [RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, 3705 "Realm Specific IP: Framework", RFC 3102, 3706 DOI 10.17487/RFC3102, October 2001, 3707 . 3709 [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, 3710 "Realm Specific IP: Protocol Specification", RFC 3103, 3711 DOI 10.17487/RFC3103, October 2001, 3712 . 3714 [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for 3715 UNilateral Self-Address Fixing (UNSAF) Across Network 3716 Address Translation", RFC 3424, DOI 10.17487/RFC3424, 3717 November 2002, . 3719 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3720 Jacobson, "RTP: A Transport Protocol for Real-Time 3721 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 3722 July 2003, . 3724 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3725 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 3726 RFC 3711, DOI 10.17487/RFC3711, March 2004, 3727 . 3729 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 3730 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 3731 2001, . 3733 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 3734 Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, 3735 September 2002, . 3737 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 3738 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 3739 2004, . 3741 [RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and 3742 E. Castro, "Application Aspects of IPv6 Transition", 3743 RFC 4038, DOI 10.17487/RFC4038, March 2005, 3744 . 3746 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 3747 Address Types (ANAT) Semantics for the Session Description 3748 Protocol (SDP) Grouping Framework", RFC 4091, 3749 DOI 10.17487/RFC4091, June 2005, 3750 . 3752 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 3753 Description Protocol (SDP) Alternative Network Address 3754 Types (ANAT) Semantics in the Session Initiation Protocol 3755 (SIP)", RFC 4092, DOI 10.17487/RFC4092, June 2005, 3756 . 3758 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3759 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3760 2006, . 3762 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3763 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 3764 July 2006, . 3766 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3767 and W. Weiss, "An Architecture for Differentiated 3768 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 3769 . 3771 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 3772 and E. Lear, "Address Allocation for Private Internets", 3773 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 3774 . 3776 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 3777 Translation (NAT) Behavioral Requirements for Unicast 3778 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 3779 2007, . 3781 [I-D.ietf-avt-rtp-no-op] 3782 Andreasen, F., "A No-Op Payload Format for RTP", draft- 3783 ietf-avt-rtp-no-op-04 (work in progress), May 2007. 3785 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 3786 Control Packets on a Single Port", RFC 5761, 3787 DOI 10.17487/RFC5761, April 2010, 3788 . 3790 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 3791 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 3792 . 3794 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 3795 (ICE): A Protocol for Network Address Translator (NAT) 3796 Traversal for Offer/Answer Protocols", RFC 5245, 3797 DOI 10.17487/RFC5245, April 2010, 3798 . 3800 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 3801 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 3802 RFC 5382, DOI 10.17487/RFC5382, October 2008, 3803 . 3805 [RFC6080] Petrie, D. and S. Channabasappa, Ed., "A Framework for 3806 Session Initiation Protocol User Agent Profile Delivery", 3807 RFC 6080, DOI 10.17487/RFC6080, March 2011, 3808 . 3810 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 3811 "TCP Candidates with Interactive Connectivity 3812 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 3813 March 2012, . 3815 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3816 NAT64: Network Address and Protocol Translation from IPv6 3817 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3818 April 2011, . 3820 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 3821 Beijnum, "DNS64: DNS Extensions for Network Address 3822 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 3823 DOI 10.17487/RFC6147, April 2011, 3824 . 3826 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 3827 the IPv6 Prefix Used for IPv6 Address Synthesis", 3828 RFC 7050, DOI 10.17487/RFC7050, November 2013, 3829 . 3831 [I-D.ietf-mmusic-ice-sip-sdp] 3832 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using 3833 Interactive Connectivity Establishment (ICE) with Session 3834 Description Protocol (SDP) offer/answer and Session 3835 Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- 3836 sdp-06 (work in progress), September 2015. 3838 [I-D.ietf-6man-ipv6-address-generation-privacy] 3839 Cooper, A., Gont, F., and D. Thaler, "Privacy 3840 Considerations for IPv6 Address Generation Mechanisms", 3841 draft-ietf-6man-ipv6-address-generation-privacy-07 (work 3842 in progress), June 2015. 3844 Appendix A. Lite and Full Implementations 3846 ICE allows for two types of implementations. A full implementation 3847 supports the controlling and controlled roles in a session, and can 3848 also perform address gathering. In contrast, a lite implementation 3849 is a minimalist implementation that does little but respond to STUN 3850 checks. 3852 Because ICE requires both endpoints to support it in order to bring 3853 benefits to either endpoint, incremental deployment of ICE in a 3854 network is more complicated. Many sessions involve an endpoint that 3855 is, by itself, not behind a NAT and not one that would worry about 3856 NAT traversal. A very common case is to have one endpoint that 3857 requires NAT traversal (such as a VoIP hard phone or soft phone) make 3858 a call to one of these devices. Even if the phone supports a full 3859 ICE implementation, ICE won't be used at all if the other device 3860 doesn't support it. The lite implementation allows for a low-cost 3861 entry point for these devices. Once they support the lite 3862 implementation, full implementations can connect to them and get the 3863 full benefits of ICE. 3865 Consequently, a lite implementation is only appropriate for devices 3866 that will *always* be connected to the public Internet and have a 3867 public IP address at which it can receive packets from any 3868 correspondent. ICE will not function when a lite implementation is 3869 placed behind a NAT. 3871 ICE allows a lite implementation to have a single IPv4 host candidate 3872 and several IPv6 addresses. In that case, candidate pairs are 3873 selected by the controlling agent using a static algorithm, such as 3874 the one in RFC 6724, which is recommended by this specification. 3875 However, static mechanisms for address selection are always prone to 3876 error, since they cannot ever reflect the actual topology and can 3877 never provide actual guarantees on connectivity. They are always 3878 heuristics. Consequently, if an agent is implementing ICE just to 3879 select between its IPv4 and IPv6 addresses, and none of its IP 3880 addresses are behind NAT, usage of full ICE is still RECOMMENDED in 3881 order to provide the most robust form of address selection possible. 3883 It is important to note that the lite implementation was added to 3884 this specification to provide a stepping stone to full 3885 implementation. Even for devices that are always connected to the 3886 public Internet with just a single IPv4 address, a full 3887 implementation is preferable if achievable. A full implementation 3888 will reduce call setup times, since ICE's aggressive mode can be 3889 used. Full implementations also obtain the security benefits of ICE 3890 unrelated to NAT traversal; in particular, the voice hammer attack 3891 described in Section 15 is prevented only for full implementations, 3892 not lite. Finally, it is often the case that a device that finds 3893 itself with a public address today will be placed in a network 3894 tomorrow where it will be behind a NAT. It is difficult to 3895 definitively know, over the lifetime of a device or product, that it 3896 will always be used on the public Internet. Full implementation 3897 provides assurance that communications will always work. 3899 Appendix B. Design Motivations 3901 ICE contains a number of normative behaviors that may themselves be 3902 simple, but derive from complicated or non-obvious thinking or use 3903 cases that merit further discussion. Since these design motivations 3904 are not necessary to understand for purposes of implementation, they 3905 are discussed here in an appendix to the specification. This section 3906 is non-normative. 3908 B.1. Pacing of STUN Transactions 3910 STUN transactions used to gather candidates and to verify 3911 connectivity are paced out at an approximate rate of one new 3912 transaction every Ta milliseconds. Each transaction, in turn, has a 3913 retransmission timer RTO that is a function of Ta as well. Why are 3914 these transactions paced, and why are these formulas used? 3916 Sending of these STUN requests will often have the effect of creating 3917 bindings on NAT devices between the client and the STUN servers. 3918 Experience has shown that many NAT devices have upper limits on the 3919 rate at which they will create new bindings. Experiments have shown 3920 that once every 20 ms is well supported, but not much lower than 3921 that. This is why Ta has a lower bound of 20 ms. Furthermore, 3922 transmission of these packets on the network makes use of bandwidth 3923 and needs to be rate limited by the agent. Deployments based on 3924 earlier draft versions of [RFC5245] tended to overload rate- 3925 constrained access links and perform poorly overall, in addition to 3926 negatively impacting the network. As a consequence, the pacing 3927 ensures that the NAT device does not get overloaded and that traffic 3928 is kept at a reasonable rate. 3930 The definition of a "reasonable" rate is that STUN should not use 3931 more bandwidth than the RTP itself will use, once media starts 3932 flowing. The formula for Ta is designed so that, if a STUN packet 3933 were sent every Ta seconds, it would consume the same amount of 3934 bandwidth as RTP packets, summed across all media streams. Of 3935 course, STUN has retransmits, and the desire is to pace those as 3936 well. For this reason, RTO is set such that the first retransmit on 3937 the first transaction happens just as the first STUN request on the 3938 last transaction occurs. Pictorially: 3940 First Packets Retransmits 3942 | | 3943 | | 3944 -------+------ -------+------ 3945 / \ / \ 3946 / \ / \ 3948 +--+ +--+ +--+ +--+ +--+ +--+ 3949 |A1| |B1| |C1| |A2| |B2| |C2| 3950 +--+ +--+ +--+ +--+ +--+ +--+ 3952 ---+-------+-------+-------+-------+-------+------------ Time 3953 0 Ta 2Ta 3Ta 4Ta 5Ta 3955 In this picture, there are three transactions that will be sent (for 3956 example, in the case of candidate gathering, there are three host 3957 candidate/STUN server pairs). These are transactions A, B, and C. 3958 The retransmit timer is set so that the first retransmission on the 3959 first transaction (packet A2) is sent at time 3Ta. 3961 Subsequent retransmits after the first will occur even less 3962 frequently than Ta milliseconds apart, since STUN uses an exponential 3963 back-off on its retransmissions. 3965 B.2. Candidates with Multiple Bases 3967 Section 4.1.3 talks about eliminating candidates that have the same 3968 transport address and base. However, candidates with the same 3969 transport addresses but different bases are not redundant. When can 3970 an agent have two candidates that have the same IP address and port, 3971 but different bases? Consider the topology of Figure 10: 3973 +----------+ 3974 | STUN Srvr| 3975 +----------+ 3976 | 3977 | 3978 ----- 3979 // \\ 3980 | | 3981 | B:net10 | 3982 | | 3983 \\ // 3984 ----- 3985 | 3986 | 3987 +----------+ 3988 | NAT | 3989 +----------+ 3990 | 3991 | 3992 ----- 3993 // \\ 3994 | A | 3995 |192.168/16 | 3996 | | 3997 \\ // 3998 ----- 3999 | 4000 | 4001 |192.168.1.100 ----- 4002 +----------+ // \\ +----------+ 4003 | | | | | | 4004 | Offerer |---------| C:net10 |-----------| Answerer | 4005 | |10.0.1.100| | 10.0.1.101 | | 4006 +----------+ \\ // +----------+ 4007 ----- 4009 Figure 10: Identical Candidates with Different Bases 4011 In this case, the offerer is multihomed. It has one IP address, 4012 10.0.1.100, on network C, which is a net 10 private network. The 4013 answerer is on this same network. The offerer is also connected to 4014 network A, which is 192.168/16. The offerer has an IP address of 4015 192.168.1.100 on this network. There is a NAT on this network, 4016 natting into network B, which is another net 10 private network, but 4017 not connected to network C. There is a STUN server on network B. 4019 The offerer obtains a host candidate on its IP address on network C 4020 (10.0.1.100:2498) and a host candidate on its IP address on network A 4021 (192.168.1.100:3344). It performs a STUN query to its configured 4022 STUN server from 192.168.1.100:3344. This query passes through the 4023 NAT, which happens to assign the binding 10.0.1.100:2498. The STUN 4024 server reflects this in the STUN Binding response. Now, the offerer 4025 has obtained a server reflexive candidate with a transport address 4026 that is identical to a host candidate (10.0.1.100:2498). However, 4027 the server reflexive candidate has a base of 192.168.1.100:3344, and 4028 the host candidate has a base of 10.0.1.100:2498. 4030 B.3. Purpose of the Related Address and Related Port Attributes 4032 The candidate attribute contains two values that are not used at all 4033 by ICE itself -- related address and related port. Why are they 4034 present? 4036 There are two motivations for its inclusion. The first is 4037 diagnostic. It is very useful to know the relationship between the 4038 different types of candidates. By including it, an agent can know 4039 which relayed candidate is associated with which reflexive candidate, 4040 which in turn is associated with a specific host candidate. When 4041 checks for one candidate succeed and not for others, this provides 4042 useful diagnostics on what is going on in the network. 4044 The second reason has to do with off-path Quality of Service (QoS) 4045 mechanisms. When ICE is used in environments such as PacketCable 4046 2.0, proxies will, in addition to performing normal SIP operations, 4047 inspect the SDP in SIP messages, and extract the IP address and port 4048 for media traffic. They can then interact, through policy servers, 4049 with access routers in the network, to establish guaranteed QoS for 4050 the media flows. This QoS is provided by classifying the RTP traffic 4051 based on 5-tuple, and then providing it a guaranteed rate, or marking 4052 its Diffserv codepoints appropriately. When a residential NAT is 4053 present, and a relayed candidate gets selected for media, this 4054 relayed candidate will be a transport address on an actual TURN 4055 server. That address says nothing about the actual transport address 4056 in the access router that would be used to classify packets for QoS 4057 treatment. Rather, the server reflexive candidate towards the TURN 4058 server is needed. By carrying the translation in the SDP, the proxy 4059 can use that transport address to request QoS from the access router. 4061 B.4. Importance of the STUN Username 4063 ICE requires the usage of message integrity with STUN using its 4064 short-term credential functionality. The actual short-term 4065 credential is formed by exchanging username fragments in the offer/ 4066 answer exchange. The need for this mechanism goes beyond just 4067 security; it is actually required for correct operation of ICE in the 4068 first place. 4070 Consider agents L, R, and Z. L and R are within private enterprise 4071 1, which is using 10.0.0.0/8. Z is within private enterprise 2, 4072 which is also using 10.0.0.0/8. As it turns out, R and Z both have 4073 IP address 10.0.1.1. L sends an offer to Z. Z, in its answer, 4074 provides L with its host candidates. In this case, those candidates 4075 are 10.0.1.1:8866 and 10.0.1.1:8877. As it turns out, R is in a 4076 session at that same time, and is also using 10.0.1.1:8866 and 4077 10.0.1.1:8877 as host candidates. This means that R is prepared to 4078 accept STUN messages on those ports, just as Z is. L will send a 4079 STUN request to 10.0.1.1:8866 and another to 10.0.1.1:8877. However, 4080 these do not go to Z as expected. Instead, they go to R! If R just 4081 replied to them, L would believe it has connectivity to Z, when in 4082 fact it has connectivity to a completely different user, R. To fix 4083 this, the STUN short-term credential mechanisms are used. The 4084 username fragments are sufficiently random that it is highly unlikely 4085 that R would be using the same values as Z. Consequently, R would 4086 reject the STUN request since the credentials were invalid. In 4087 essence, the STUN username fragments provide a form of transient host 4088 identifiers, bound to a particular offer/answer session. 4090 An unfortunate consequence of the non-uniqueness of IP addresses is 4091 that, in the above example, R might not even be an ICE agent. It 4092 could be any host, and the port to which the STUN packet is directed 4093 could be any ephemeral port on that host. If there is an application 4094 listening on this socket for packets, and it is not prepared to 4095 handle malformed packets for whatever protocol is in use, the 4096 operation of that application could be affected. Fortunately, since 4097 the ports exchanged in offer/answer are ephemeral and usually drawn 4098 from the dynamic or registered range, the odds are good that the port 4099 is not used to run a server on host R, but rather is the agent side 4100 of some protocol. This decreases the probability of hitting an 4101 allocated port, due to the transient nature of port usage in this 4102 range. However, the possibility of a problem does exist, and network 4103 deployers should be prepared for it. Note that this is not a problem 4104 specific to ICE; stray packets can arrive at a port at any time for 4105 any type of protocol, especially ones on the public Internet. As 4106 such, this requirement is just restating a general design guideline 4107 for Internet applications -- be prepared for unknown packets on any 4108 port. 4110 B.5. The Candidate Pair Priority Formula 4112 The priority for a candidate pair has an odd form. It is: 4114 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 4116 Why is this? When the candidate pairs are sorted based on this 4117 value, the resulting sorting has the MAX/MIN property. This means 4118 that the pairs are first sorted based on decreasing value of the 4119 minimum of the two priorities. For pairs that have the same value of 4120 the minimum priority, the maximum priority is used to sort amongst 4121 them. If the max and the min priorities are the same, the 4122 controlling agent's priority is used as the tie-breaker in the last 4123 part of the expression. The factor of 2*32 is used since the 4124 priority of a single candidate is always less than 2*32, resulting in 4125 the pair priority being a "concatenation" of the two component 4126 priorities. This creates the MAX/MIN sorting. MAX/MIN ensures that, 4127 for a particular agent, a lower-priority candidate is never used 4128 until all higher-priority candidates have been tried. 4130 B.6. Why Are Keepalives Needed? 4132 Once media begins flowing on a candidate pair, it is still necessary 4133 to keep the bindings alive at intermediate NATs for the duration of 4134 the session. Normally, the media stream packets themselves (e.g., 4135 RTP) meet this objective. However, several cases merit further 4136 discussion. Firstly, in some RTP usages, such as SIP, the media 4137 streams can be "put on hold". This is accomplished by using the SDP 4138 "sendonly" or "inactive" attributes, as defined in RFC 3264 4139 [RFC3264]. RFC 3264 directs implementations to cease transmission of 4140 media in these cases. However, doing so may cause NAT bindings to 4141 timeout, and media won't be able to come off hold. 4143 Secondly, some RTP payload formats, such as the payload format for 4144 text conversation [RFC4103], may send packets so infrequently that 4145 the interval exceeds the NAT binding timeouts. 4147 Thirdly, if silence suppression is in use, long periods of silence 4148 may cause media transmission to cease sufficiently long for NAT 4149 bindings to time out. 4151 For these reasons, the media packets themselves cannot be relied 4152 upon. ICE defines a simple periodic keepalive utilizing STUN Binding 4153 indications. This makes its bandwidth requirements highly 4154 predictable, and thus amenable to QoS reservations. 4156 B.7. Why Prefer Peer Reflexive Candidates? 4158 Section 4.1.2 describes procedures for computing the priority of 4159 candidate based on its type and local preferences. That section 4160 requires that the type preference for peer reflexive candidates 4161 always be higher than server reflexive. Why is that? The reason has 4162 to do with the security considerations in Section 15. It is much 4163 easier for an attacker to cause an agent to use a false server 4164 reflexive candidate than it is for an attacker to cause an agent to 4165 use a false peer reflexive candidate. Consequently, attacks against 4166 address gathering with Binding requests are thwarted by ICE by 4167 preferring the peer reflexive candidates. 4169 B.8. Why Are Binding Indications Used for Keepalives? 4171 Media keepalives are described in Section 10. These keepalives make 4172 use of STUN when both endpoints are ICE capable. However, rather 4173 than using a Binding request transaction (which generates a 4174 response), the keepalives use an Indication. Why is that? 4176 The primary reason has to do with network QoS mechanisms. Once media 4177 begins flowing, network elements will assume that the media stream 4178 has a fairly regular structure, making use of periodic packets at 4179 fixed intervals, with the possibility of jitter. If an agent is 4180 sending media packets, and then receives a Binding request, it would 4181 need to generate a response packet along with its media packets. 4182 This will increase the actual bandwidth requirements for the 5-tuple 4183 carrying the media packets, and introduce jitter in the delivery of 4184 those packets. Analysis has shown that this is a concern in certain 4185 layer 2 access networks that use fairly tight packet schedulers for 4186 media. 4188 Additionally, using a Binding Indication allows integrity to be 4189 disabled, allowing for better performance. This is useful for large- 4190 scale endpoints, such as PSTN gateways and SBCs. 4192 Authors' Addresses 4194 Ari Keranen 4195 Ericsson 4196 Hirsalantie 11 4197 02420 Jorvas 4198 Finland 4200 Email: ari.keranen@ericsson.com 4201 Jonathan Rosenberg 4202 jdrosen.net 4203 Monmouth, NJ 4204 US 4206 Email: jdrosen@jdrosen.net 4207 URI: http://www.jdrosen.net