idnits 2.17.1 draft-ietf-mmusic-rfc5245bis-04.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 (March 9, 2015) is 3337 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-04 == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-04 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: September 10, 2015 March 9, 2015 8 Interactive Connectivity Establishment (ICE): A Protocol for Network 9 Address Translator (NAT) Traversal for Offer/Answer Protocols 10 draft-ietf-mmusic-rfc5245bis-04 12 Abstract 14 This document describes a protocol for Network Address Translator 15 (NAT) traversal for UDP-based multimedia sessions established with 16 the offer/answer model. This protocol is called Interactive 17 Connectivity Establishment (ICE). ICE makes use of the Session 18 Traversal Utilities for NAT (STUN) protocol and its extension, 19 Traversal Using Relay NAT (TURN). ICE can be used by any protocol 20 utilizing the offer/answer model, such as the Session Initiation 21 Protocol (SIP). 23 This document obsoletes RFC 5245. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 10, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 6 73 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 8 74 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10 75 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 11 76 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 12 77 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 13 78 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 13 79 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 15 80 2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 15 81 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19 83 4.1. Full Implementation Requirements . . . . . . . . . . . . 19 84 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 85 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19 86 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 87 4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 22 88 4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22 89 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22 90 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 23 91 4.1.2.2. Guidelines for Choosing Type and Local 92 Preferences . . . . . . . . . . . . . . . . . . . 24 93 4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 25 94 4.2. Lite Implementation Requirements . . . . . . . . . . . . 25 95 4.3. Encoding the Offer . . . . . . . . . . . . . . . . . . . 26 96 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 28 97 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28 98 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 28 99 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 29 100 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 30 101 5.5. Encoding the Answer . . . . . . . . . . . . . . . . . . . 30 102 5.6. Forming the Check Lists . . . . . . . . . . . . . . . . . 30 103 5.6.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 30 104 5.6.2. Computing Pair Priority and Ordering Pairs . . . . . 33 105 5.6.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 33 106 5.6.4. Computing States . . . . . . . . . . . . . . . . . . 33 107 5.7. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 36 108 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 38 109 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 38 110 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 38 111 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 38 112 6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 38 113 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 38 114 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 39 115 7.1.1. Creating Permissions for Relayed Candidates . . . . . 39 116 7.1.2. Sending the Request . . . . . . . . . . . . . . . . . 39 117 7.1.2.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 39 118 7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 40 119 7.1.2.3. Forming Credentials . . . . . . . . . . . . . . . 40 120 7.1.2.4. DiffServ Treatment . . . . . . . . . . . . . . . 40 121 7.1.3. Processing the Response . . . . . . . . . . . . . . . 40 122 7.1.3.1. Failure Cases . . . . . . . . . . . . . . . . . . 41 123 7.1.3.2. Success Cases . . . . . . . . . . . . . . . . . . 41 124 7.1.3.2.1. Discovering Peer Reflexive Candidates . . . . 42 125 7.1.3.2.2. Constructing a Valid Pair . . . . . . . . . . 42 126 7.1.3.2.3. Updating Pair States . . . . . . . . . . . . 43 127 7.1.3.2.4. Updating the Nominated Flag . . . . . . . . . 44 128 7.1.3.3. Check List and Timer State Updates . . . . . . . 44 129 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 45 130 7.2.1. Additional Procedures for Full Implementations . . . 46 131 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 46 132 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 47 133 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 47 134 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 48 135 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 49 136 7.2.2. Additional Procedures for Lite Implementations . . . 49 137 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 50 138 8.1. Procedures for Full Implementations . . . . . . . . . . . 50 139 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 50 140 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 50 141 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 51 142 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 51 143 8.2. Procedures for Lite Implementations . . . . . . . . . . . 53 144 8.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . 53 145 8.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . 53 146 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 54 147 8.3.1. Full Implementation Procedures . . . . . . . . . . . 54 148 8.3.2. Lite Implementation Procedures . . . . . . . . . . . 54 149 9. ICE Restarts . . . . . . . . . . . . . . . . . . . . . . . . 54 150 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 55 151 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 56 152 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 56 153 11.1.1. Procedures for Full Implementations . . . . . . . . 56 154 11.1.2. Procedures for Lite Implementations . . . . . . . . 57 155 11.1.3. Procedures for All Implementations . . . . . . . . . 57 156 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 57 157 12. Extensibility Considerations . . . . . . . . . . . . . . . . 58 158 13. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 59 159 13.1. Real-time Media Streams . . . . . . . . . . . . . . . . 59 160 13.2. Non-real-time Sessions . . . . . . . . . . . . . . . . . 61 161 14. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 162 15. Security Considerations . . . . . . . . . . . . . . . . . . . 66 163 15.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 66 164 15.2. Attacks on Server Reflexive Address Gathering . . . . . 69 165 15.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 70 166 15.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . 70 167 15.4.1. STUN Amplification Attack . . . . . . . . . . . . . 70 168 16. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 71 169 16.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 71 170 16.2. New Error Response Codes . . . . . . . . . . . . . . . . 72 171 17. Operational Considerations . . . . . . . . . . . . . . . . . 72 172 17.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 72 173 17.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 72 174 17.2.1. STUN and TURN Server Capacity Planning . . . . . . . 72 175 17.2.2. Gathering and Connectivity Checks . . . . . . . . . 73 176 17.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 73 177 17.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 74 178 17.4. Troubleshooting and Performance Management . . . . . . . 74 179 17.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 74 180 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 181 18.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 75 182 18.2. STUN Error Responses . . . . . . . . . . . . . . . . . . 75 183 19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75 184 19.1. Problem Definition . . . . . . . . . . . . . . . . . . . 75 185 19.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 76 186 19.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 76 187 19.4. Requirements for a Long-Term Solution . . . . . . . . . 77 188 19.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 78 189 20. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 78 190 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 191 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 192 22.1. Normative References . . . . . . . . . . . . . . . . . . 79 193 22.2. Informative References . . . . . . . . . . . . . . . . . 79 194 Appendix A. Lite and Full Implementations . . . . . . . . . . . 82 195 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 83 196 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 83 197 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 84 198 B.3. Purpose of the Related Address and Related Port 199 Attributes . . . . . . . . . . . . . . . . . . . . . . . 86 200 B.4. Importance of the STUN Username . . . . . . . . . . . . . 86 201 B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 87 202 B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 88 203 B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 88 204 B.8. Why Are Binding Indications Used for Keepalives? . . . . 89 205 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 207 1. Introduction 209 RFC 3264 [RFC3264] defines a two-phase exchange of Session 210 Description Protocol (SDP) messages [RFC4566] for the purposes of 211 establishment of multimedia sessions. This offer/answer mechanism is 212 used by protocols such as the Session Initiation Protocol (SIP) 213 [RFC3261]. 215 Protocols using offer/answer are difficult to operate through Network 216 Address Translators (NATs). Because their purpose is to establish a 217 flow of media packets, they tend to carry the IP addresses and ports 218 of media sources and sinks within their messages, which is known to 219 be problematic through NAT [RFC3235]. The protocols also seek to 220 create a media flow directly between participants, so that there is 221 no application layer intermediary between them. This is done to 222 reduce media latency, decrease packet loss, and reduce the 223 operational costs of deploying the application. However, this is 224 difficult to accomplish through NAT. A full treatment of the reasons 225 for this is beyond the scope of this specification. 227 Numerous solutions have been defined for allowing these protocols to 228 operate through NAT. These include Application Layer Gateways 229 (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple 230 Traversal of UDP Through NAT (STUN) [RFC3489] specification, and 231 Realm Specific IP [RFC3102] [RFC3103] along with session description 232 extensions needed to make them work, such as the Session Description 233 Protocol (SDP) [RFC4566] attribute for the Real Time Control Protocol 234 (RTCP) [RFC3605]. Unfortunately, these techniques all have pros and 235 cons which, make each one optimal in some network topologies, but a 236 poor choice in others. The result is that administrators and 237 implementors are making assumptions about the topologies of the 238 networks in which their solutions will be deployed. This introduces 239 complexity and brittleness into the system. What is needed is a 240 single solution that is flexible enough to work well in all 241 situations. 243 This specification defines Interactive Connectivity Establishment 244 (ICE) as a technique for NAT traversal for UDP-based media streams 245 (though ICE has been extended to handle other transport protocols, 246 such as TCP [RFC6544]) established by the offer/answer model. ICE is 247 an extension to the offer/answer model, and works by including a 248 multiplicity of IP addresses and ports in the offers and answers, 249 which are then tested for connectivity by peer-to-peer connectivity 250 checks. The IP addresses and ports included in the offer and answer 251 and the connectivity checks are performed using Session Traversal 252 Utilities for NAT (STUN) specification [RFC5389]. ICE also makes use 253 of Traversal Using Relays around NAT (TURN) [RFC5766], an extension 254 to STUN. Because ICE exchanges a multiplicity of IP addresses and 255 ports for each media stream, it also allows for address selection for 256 multihomed and dual-stack hosts, and for this reason it deprecates 257 [RFC4091] and [RFC4092]. 259 2. Overview of ICE 261 In a typical ICE deployment, we have two endpoints (known as AGENTS 262 in RFC 3264 terminology) that want to communicate. They are able to 263 communicate indirectly via some signaling protocol (such as SIP), by 264 which they can perform an offer/answer exchange. Note that ICE is 265 not intended for NAT traversal for the signaling protocol, which is 266 assumed to be provided via another mechanism. At the beginning of 267 the ICE process, the agents are ignorant of their own topologies. In 268 particular, they might or might not be behind a NAT (or multiple 269 tiers of NATs). ICE allows the agents to discover enough information 270 about their topologies to potentially find one or more paths by which 271 they can communicate. 273 Figure 1 shows a typical environment for ICE deployment. The two 274 endpoints are labelled L and R (for left and right, which helps 275 visualize call flows). Both L and R are behind their own respective 276 NATs though they may not be aware of it. The type of NAT and its 277 properties are also unknown. Agents L and R are capable of engaging 278 in an offer/answer exchange, whose purpose is to set up a media 279 session between L and R. Typically, this exchange will occur through 280 a signaling (e.g., SIP) server. 282 In addition to the agents, a signaling server and NATs, ICE is 283 typically used in concert with STUN or TURN servers in the network. 284 Each agent can have its own STUN or TURN server, or they can be the 285 same. 287 +---------+ 288 +--------+ |Signaling| +--------+ 289 | STUN | |Server | | STUN | 290 | Server | +---------+ | Server | 291 +--------+ / \ +--------+ 292 / \ 293 / \ 294 / <- Signaling -> \ 295 / \ 296 +--------+ +--------+ 297 | NAT | | NAT | 298 +--------+ +--------+ 299 / \ 300 / \ 301 +-------+ +-------+ 302 | Agent | | Agent | 303 | L | | R | 304 +-------+ +-------+ 306 Figure 1: ICE Deployment Scenario 308 The basic idea behind ICE is as follows: each agent has a variety of 309 candidate TRANSPORT ADDRESSES (combination of IP address and port for 310 a particular transport protocol, which is always UDP in this 311 specification) it could use to communicate with the other agent. 312 These might include: 314 o A transport address on a directly attached network interface 316 o A translated transport address on the public side of a NAT (a 317 "server reflexive" address) 319 o A transport address allocated from a TURN server (a "relayed 320 address") 322 Potentially, any of L's candidate transport addresses can be used to 323 communicate with any of R's candidate transport addresses. In 324 practice, however, many combinations will not work. For instance, if 325 L and R are both behind NATs, their directly attached interface 326 addresses are unlikely to be able to communicate directly (this is 327 why ICE is needed, after all!). The purpose of ICE is to discover 328 which pairs of addresses will work. The way that ICE does this is to 329 systematically try all possible pairs (in a carefully sorted order) 330 until it finds one or more that work. 332 2.1. Gathering Candidate Addresses 334 In order to execute ICE, an agent has to identify all of its address 335 candidates. A CANDIDATE is a transport address -- a combination of 336 IP address and port for a particular transport protocol (with only 337 UDP specified here). This document defines three types of 338 candidates, some derived from physical or logical network interfaces, 339 others discoverable via STUN and TURN. Naturally, one viable 340 candidate is a transport address obtained directly from a local 341 interface. Such a candidate is called a HOST CANDIDATE. The local 342 interface could be Ethernet or WiFi, or it could be one that is 343 obtained through a tunnel mechanism, such as a Virtual Private 344 Network (VPN) or Mobile IP (MIP). In all cases, such a network 345 interface appears to the agent as a local interface from which ports 346 (and thus candidates) can be allocated. 348 If an agent is multihomed, it obtains a candidate from each IP 349 address. Depending on the location of the PEER (the other agent in 350 the session) on the IP network relative to the agent, the agent may 351 be reachable by the peer through one or more of those IP addresses. 352 Consider, for example, an agent that has a local IP address on a 353 private net 10 network (I1), and a second connected to the public 354 Internet (I2). A candidate from I1 will be directly reachable when 355 communicating with a peer on the same private net 10 network, while a 356 candidate from I2 will be directly reachable when communicating with 357 a peer on the public Internet. Rather than trying to guess which IP 358 address will work prior to sending an offer, the offering agent 359 includes both candidates in its offer. 361 Next, the agent uses STUN or TURN to obtain additional candidates. 362 These come in two flavors: translated addresses on the public side of 363 a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers 364 (RELAYED CANDIDATES). When TURN servers are utilized, both types of 365 candidates are obtained from the TURN server. If only STUN servers 366 are utilized, only server reflexive candidates are obtained from 367 them. The relationship of these candidates to the host candidate is 368 shown in Figure 2. In this figure, both types of candidates are 369 discovered using TURN. In the figure, the notation X:x means IP 370 address X and UDP port x. 372 To Internet 374 | 375 | 376 | /------------ Relayed 377 Y:y | / Address 378 +--------+ 379 | | 380 | TURN | 381 | Server | 382 | | 383 +--------+ 384 | 385 | 386 | /------------ Server 387 X1':x1'|/ Reflexive 388 +------------+ Address 389 | NAT | 390 +------------+ 391 | 392 | /------------ Local 393 X:x |/ Address 394 +--------+ 395 | | 396 | Agent | 397 | | 398 +--------+ 400 Figure 2: Candidate Relationships 402 When the agent sends the TURN Allocate request from IP address and 403 port X:x, the NAT (assuming there is one) will create a binding 404 X1':x1', mapping this server reflexive candidate to the host 405 candidate X:x. Outgoing packets sent from the host candidate will be 406 translated by the NAT to the server reflexive candidate. Incoming 407 packets sent to the server reflexive candidate will be translated by 408 the NAT to the host candidate and forwarded to the agent. We call 409 the host candidate associated with a given server reflexive candidate 410 the BASE. 412 Note: "Base" refers to the address an agent sends from for a 413 particular candidate. Thus, as a degenerate case host candidates 414 also have a base, but it's the same as the host candidate. 416 When there are multiple NATs between the agent and the TURN server, 417 the TURN request will create a binding on each NAT, but only the 418 outermost server reflexive candidate (the one nearest the TURN 419 server) will be discovered by the agent. If the agent is not behind 420 a NAT, then the base candidate will be the same as the server 421 reflexive candidate and the server reflexive candidate is redundant 422 and will be eliminated. 424 The Allocate request then arrives at the TURN server. The TURN 425 server allocates a port y from its local IP address Y, and generates 426 an Allocate response, informing the agent of this relayed candidate. 427 The TURN server also informs the agent of the server reflexive 428 candidate, X1':x1' by copying the source transport address of the 429 Allocate request into the Allocate response. The TURN server acts as 430 a packet relay, forwarding traffic between L and R. In order to send 431 traffic to L, R sends traffic to the TURN server at Y:y, and the TURN 432 server forwards that to X1':x1', which passes through the NAT where 433 it is mapped to X:x and delivered to L. 435 When only STUN servers are utilized, the agent sends a STUN Binding 436 request [RFC5389] to its STUN server. The STUN server will inform 437 the agent of the server reflexive candidate X1':x1' by copying the 438 source transport address of the Binding request into the Binding 439 response. 441 2.2. Connectivity Checks 443 Once L has gathered all of its candidates, it orders them in highest 444 to lowest-priority and sends them to R over the signaling channel. 445 The candidates are carried in attributes in the offer. When R 446 receives the offer, it performs the same gathering process and 447 responds with its own list of candidates. At the end of this 448 process, each agent has a complete list of both its candidates and 449 its peer's candidates. It pairs them up, resulting in CANDIDATE 450 PAIRS. To see which pairs work, each agent schedules a series of 451 CHECKS. Each check is a STUN request/response transaction that the 452 client will perform on a particular candidate pair by sending a STUN 453 request from the local candidate to the remote candidate. 455 The basic principle of the connectivity checks is simple: 457 1. Sort the candidate pairs in priority order. 459 2. Send checks on each candidate pair in priority order. 461 3. Acknowledge checks received from the other agent. 463 With both agents performing a check on a candidate pair, the result 464 is a 4-way handshake: 466 L R 467 - - 468 STUN request -> \ L's 469 <- STUN response / check 471 <- STUN request \ R's 472 STUN response -> / check 474 Figure 3: Basic Connectivity Check 476 It is important to note that the STUN requests are sent to and from 477 the exact same IP addresses and ports that will be used for media 478 (e.g., RTP and RTCP). Consequently, agents demultiplex STUN and RTP/ 479 RTCP using contents of the packets, rather than the port on which 480 they are received. Fortunately, this demultiplexing is easy to do, 481 especially for RTP and RTCP. 483 Because a STUN Binding request is used for the connectivity check, 484 the STUN Binding response will contain the agent's translated 485 transport address on the public side of any NATs between the agent 486 and its peer. If this transport address is different from other 487 candidates the agent already learned, it represents a new candidate, 488 called a PEER REFLEXIVE CANDIDATE, which then gets tested by ICE just 489 the same as any other candidate. 491 As an optimization, as soon as R gets L's check message, R schedules 492 a connectivity check message to be sent to L on the same candidate 493 pair. This accelerates the process of finding a valid candidate, and 494 is called a TRIGGERED CHECK. 496 At the end of this handshake, both L and R know that they can send 497 (and receive) messages end-to-end in both directions. 499 2.3. Sorting Candidates 501 Because the algorithm above searches all candidate pairs, if a 502 working pair exists it will eventually find it no matter what order 503 the candidates are tried in. In order to produce faster (and better) 504 results, the candidates are sorted in a specified order. The 505 resulting list of sorted candidate pairs is called the CHECK LIST. 506 The algorithm is described in Section 4.1.2 but follows two general 507 principles: 509 o Each agent gives its candidates a numeric priority, which is sent 510 along with the candidate to the peer. 512 o The local and remote priorities are combined so that each agent 513 has the same ordering for the candidate pairs. 515 The second property is important for getting ICE to work when there 516 are NATs in front of L and R. Frequently, NATs will not allow 517 packets in from a host until the agent behind the NAT has sent a 518 packet towards that host. Consequently, ICE checks in each direction 519 will not succeed until both sides have sent a check through their 520 respective NATs. 522 The agent works through this check list by sending a STUN request for 523 the next candidate pair on the list periodically. These are called 524 ORDINARY CHECKS. 526 In general, the priority algorithm is designed so that candidates of 527 similar type get similar priorities and so that more direct routes 528 (that is, through fewer media relays and through fewer NATs) are 529 preferred over indirect ones (ones with more media relays and more 530 NATs). Within those guidelines, however, agents have a fair amount 531 of discretion about how to tune their algorithms. 533 2.4. Frozen Candidates 535 The previous description only addresses the case where the agents 536 wish to establish a media session with one COMPONENT (a piece of a 537 media stream requiring a single transport address; a media stream may 538 require multiple components, each of which has to work for the media 539 stream as a whole to be work). Often (e.g., with RTP and RTCP), the 540 agents actually need to establish connectivity for more than one 541 flow. 543 The network properties are likely to be very similar for each 544 component (especially because RTP and RTCP are sent and received from 545 the same IP address). It is usually possible to leverage information 546 from one media component in order to determine the best candidates 547 for another. ICE does this with a mechanism called "frozen 548 candidates". 550 Each candidate is associated with a property called its FOUNDATION. 551 Two candidates have the same foundation when they are "similar" -- of 552 the same type and obtained from the same host candidate and STUN/TURN 553 server using the same protocol. Otherwise, their foundation is 554 different. A candidate pair has a foundation too, which is just the 555 concatenation of the foundations of its two candidates. Initially, 556 only the candidate pairs with unique foundations are tested. The 557 other candidate pairs are marked "frozen". When the connectivity 558 checks for a candidate pair succeed, the other candidate pairs with 559 the same foundation are unfrozen. This avoids repeated checking of 560 components that are superficially more attractive but in fact are 561 likely to fail. 563 While we've described "frozen" here as a separate mechanism for 564 expository purposes, in fact it is an integral part of ICE and the 565 ICE prioritization algorithm automatically ensures that the right 566 candidates are unfrozen and checked in the right order. However, if 567 the ICE usage does not utilize multiple components or media streams, 568 it does not need to implement this algorithm. 570 2.5. Security for Checks 572 Because ICE is used to discover which addresses can be used to send 573 media between two agents, it is important to ensure that the process 574 cannot be hijacked to send media to the wrong location. Each STUN 575 connectivity check is covered by a message authentication code (MAC) 576 computed using a key exchanged in the signaling channel. This MAC 577 provides message integrity and data origin authentication, thus 578 stopping an attacker from forging or modifying connectivity check 579 messages. Furthermore, if for example a SIP [RFC3261] caller is 580 using ICE, and their call forks, the ICE exchanges happen 581 independently with each forked recipient. In such a case, the keys 582 exchanged in the signaling help associate each ICE exchange with each 583 forked recipient. 585 2.6. Concluding ICE 587 ICE checks are performed in a specific sequence, so that high- 588 priority candidate pairs are checked first, followed by lower- 589 priority ones. One way to conclude ICE is to declare victory as soon 590 as a check for each component of each media stream completes 591 successfully. Indeed, this is a reasonable algorithm, and details 592 for it are provided below. However, it is possible that a packet 593 loss will cause a higher-priority check to take longer to complete. 594 In that case, allowing ICE to run a little longer might produce 595 better results. More fundamentally, however, the prioritization 596 defined by this specification may not yield "optimal" results. As an 597 example, if the aim is to select low-latency media paths, usage of a 598 relay is a hint that latencies may be higher, but it is nothing more 599 than a hint. An actual round-trip time (RTT) measurement could be 600 made, and it might demonstrate that a pair with lower priority is 601 actually better than one with higher priority. 603 Consequently, ICE assigns one of the agents in the role of the 604 CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The 605 controlling agent gets to nominate which candidate pairs will get 606 used for media amongst the ones that are valid. It can do this in 607 one of two ways -- using REGULAR NOMINATION or AGGRESSIVE NOMINATION. 609 With regular nomination, the controlling agent lets the checks 610 continue until at least one valid candidate pair for each media 611 stream is found. Then, it picks amongst those that are valid, and 612 sends a second STUN request on its NOMINATED candidate pair, but this 613 time with a flag set to tell the peer that this pair has been 614 nominated for use. This is shown in Figure 4. 616 L R 617 - - 618 STUN request -> \ L's 619 <- STUN response / check 621 <- STUN request \ R's 622 STUN response -> / check 624 STUN request + flag -> \ L's 625 <- STUN response / check 627 Figure 4: Regular Nomination 629 Once the STUN transaction with the flag completes, both sides cancel 630 any future checks for that media stream. ICE will now send media 631 using this pair. The pair an ICE agent is using for media is called 632 the SELECTED PAIR. 634 In aggressive nomination, the controlling agent puts the flag in 635 every connectivity check STUN request it sends. This way, once the 636 first check succeeds, ICE processing is complete for that media 637 stream and the controlling agent doesn't have to send a second STUN 638 request. The selected pair will be the highest-priority valid pair 639 whose check succeeded. Aggressive nomination is faster than regular 640 nomination, but gives less flexibility. Aggressive nomination is 641 shown in Figure 5. 643 L R 644 - - 645 STUN request + flag -> \ L's 646 <- STUN response / check 648 <- STUN request \ R's 649 STUN response -> / check 651 Figure 5: Aggressive Nomination 653 Once ICE is concluded, it can be restarted at any time for one or all 654 of the media streams by either agent. This is done by sending an 655 updated offer indicating a restart. 657 2.7. Lite Implementations 659 In order for ICE to be used in a call, both agents need to support 660 it. However, certain agents will always be connected to the public 661 Internet and have a public IP address at which it can receive packets 662 from any correspondent. To make it easier for these devices to 663 support ICE, ICE defines a special type of implementation called LITE 664 (in contrast to the normal FULL implementation). A lite 665 implementation doesn't gather candidates; it includes only host 666 candidates for any media stream. Lite agents do not generate 667 connectivity checks or run the state machines, though they need to be 668 able to respond to connectivity checks. When a lite implementation 669 connects with a full implementation, the full agent takes the role of 670 the controlling agent, and the lite agent takes on the controlled 671 role. When two lite implementations connect, no checks are sent. 673 For guidance on when a lite implementation is appropriate, see the 674 discussion in Appendix A. 676 It is important to note that the lite implementation was added to 677 this specification to provide a stepping stone to full 678 implementation. Even for devices that are always connected to the 679 public Internet, a full implementation is preferable if achievable. 681 2.8. Usages of ICE 683 This document specifies generic use of ICE with protocols that 684 provide offer/answer semantics. The specific details (e.g., how to 685 encode candidates) for different protocols using ICE are described in 686 separate usage documents. For example, usage with SIP and SDP is 687 described in [I-D.ietf-mmusic-ice-sip-sdp]. 689 3. Terminology 691 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 692 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 693 "OPTIONAL" in this document are to be interpreted as described in RFC 694 2119 [RFC2119]. 696 Readers should be familiar with the terminology defined in the offer/ 697 answer model [RFC3264], STUN [RFC5389], and NAT Behavioral 698 requirements for UDP [RFC4787]. 700 This specification makes use of the following additional terminology: 702 Agent: An agent is the protocol implementation involved in the 703 offer/answer exchange. There are two agents involved in an offer/ 704 answer exchange. 706 ICE offer/answer: The process where the ICE agents exchange 707 information (e.g., candidates and passwords) that is needed to 708 perform ICE. RFC 3264 offer/answer with SDP is one example of a 709 protocol that can be used for ICE offer and answer. 711 Peer: From the perspective of one of the agents in a session, its 712 peer is the other agent. Specifically, from the perspective of 713 the offerer, the peer is the answerer. From the perspective of 714 the answerer, the peer is the offerer. 716 Transport Address: The combination of an IP address and transport 717 protocol (such as UDP or TCP) port. 719 Media, Media Stream, Media Session: When ICE is used to setup 720 multimedia sessions, the media is usually transported over RTP, 721 and a media stream composes of a stream of RTP packets. When ICE 722 is used with other than multimedia sessions, the terms "media", 723 "media stream", and "media session" are still used in this 724 specification to refer to the IP data packets that are exchanged 725 between the peers on the path created and tested with ICE. 727 Candidate: A transport address that is a potential point of contact 728 for receipt of media. Candidates also have properties -- their 729 type (server reflexive, relayed, or host), priority, foundation, 730 and base. 732 Component: A component is a piece of a media stream requiring a 733 single transport address; a media stream may require multiple 734 components, each of which has to work for the media stream as a 735 whole to work. For media streams based on RTP, there are two 736 components per media stream -- one for RTP, and one for RTCP. 738 Host Candidate: A candidate obtained by binding to a specific port 739 from an IP address on the host. This includes IP addresses on 740 physical interfaces and logical ones, such as ones obtained 741 through Virtual Private Networks (VPNs) and Realm Specific IP 742 (RSIP) [RFC3102] (which lives at the operating system level). 744 Server Reflexive Candidate: A candidate whose IP address and port 745 are a binding allocated by a NAT for an agent when it sent a 746 packet through the NAT to a server. Server reflexive candidates 747 can be learned by STUN servers using the Binding request, or TURN 748 servers, which provides both a relayed and server reflexive 749 candidate. 751 Peer Reflexive Candidate: A candidate whose IP address and port are 752 a binding allocated by a NAT for an agent when it sent a STUN 753 Binding request through the NAT to its peer. 755 Relayed Candidate: A candidate obtained by sending a TURN Allocate 756 request from a host candidate to a TURN server. The relayed 757 candidate is resident on the TURN server, and the TURN server 758 relays packets back towards the agent. 760 Base: The base of a server reflexive candidate is the host candidate 761 from which it was derived. A host candidate is also said to have 762 a base, equal to that candidate itself. Similarly, the base of a 763 relayed candidate is that candidate itself. 765 Foundation: An arbitrary string that is the same for two candidates 766 that have the same type, base IP address, protocol (UDP, TCP, 767 etc.), and STUN or TURN server. If any of these are different, 768 then the foundation will be different. Two candidate pairs with 769 the same foundation pairs are likely to have similar network 770 characteristics. Foundations are used in the frozen algorithm. 772 Local Candidate: A candidate that an agent has obtained and included 773 in an offer or answer it sent. 775 Remote Candidate: A candidate that an agent received in an offer or 776 answer from its peer. 778 Default Destination/Candidate: The default destination for a 779 component of a media stream is the transport address that would be 780 used by an agent that is not ICE aware. A default candidate for a 781 component is one whose transport address matches the default 782 destination for that component. 784 Candidate Pair: A pairing containing a local candidate and a remote 785 candidate. 787 Check, Connectivity Check, STUN Check: A STUN Binding request 788 transaction for the purposes of verifying connectivity. A check 789 is sent from the local candidate to the remote candidate of a 790 candidate pair. 792 Check List: An ordered set of candidate pairs that an agent will use 793 to generate checks. 795 Ordinary Check: A connectivity check generated by an agent as a 796 consequence of a timer that fires periodically, instructing it to 797 send a check. 799 Triggered Check: A connectivity check generated as a consequence of 800 the receipt of a connectivity check from the peer. 802 Valid List: An ordered set of candidate pairs for a media stream 803 that have been validated by a successful STUN transaction. 805 Full: An ICE implementation that performs the complete set of 806 functionality defined by this specification. 808 Lite: An ICE implementation that omits certain functions, 809 implementing only as much as is necessary for a peer 810 implementation that is full to gain the benefits of ICE. Lite 811 implementations do not maintain any of the state machines and do 812 not generate connectivity checks. 814 Controlling Agent: The ICE agent that is responsible for selecting 815 the final choice of candidate pairs and signaling them through 816 STUN. In any session, one agent is always controlling. The other 817 is the controlled agent. 819 Controlled Agent: An ICE agent that waits for the controlling agent 820 to select the final choice of candidate pairs. 822 Regular Nomination: The process of picking a valid candidate pair 823 for media traffic by validating the pair with one STUN request, 824 and then picking it by sending a second STUN request with a flag 825 indicating its nomination. 827 Aggressive Nomination: The process of picking a valid candidate pair 828 for media traffic by including a flag in every connectivity check 829 STUN request, such that the first one to produce a valid candidate 830 pair is used for media. 832 Nominated: If a valid candidate pair has its nominated flag set, it 833 means that it may be selected by ICE for sending and receiving 834 media. 836 Selected Pair, Selected Candidate: The candidate pair selected by 837 ICE for sending and receiving media is called the selected pair, 838 and each of its candidates is called the selected candidate. 840 Using Protocol, ICE Usage: The protocol that uses ICE for NAT 841 traversal. A usage specification defines the protocol specific 842 details on how the procedures defined here are applied to that 843 protocol. 845 4. Sending the Initial Offer 847 In order to send the initial offer in an offer/answer exchange, an 848 agent must (1) gather candidates, (2) prioritize them, (3) eliminate 849 redundant candidates, (4) (possibly) choose default candidates, and 850 then (5) formulate and send the offer. All but the last of these 851 five steps differ for full and lite implementations. 853 4.1. Full Implementation Requirements 855 4.1.1. Gathering Candidates 857 An agent gathers candidates when it believes that communication is 858 imminent. An offerer can do this based on a user interface cue, or 859 based on an explicit request to initiate a session. Every candidate 860 is a transport address. It also has a type and a base. Four types 861 are defined and gathered by this specification -- host candidates, 862 server reflexive candidates, peer reflexive candidates, and relayed 863 candidates. The server reflexive candidates are gathered using STUN 864 or TURN, and relayed candidates are obtained through TURN. Peer 865 reflexive candidates are obtained in later phases of ICE, as a 866 consequence of connectivity checks. The base of a candidate is the 867 candidate that an agent must send from when using that candidate. 869 4.1.1.1. Host Candidates 871 The first step is to gather host candidates. Host candidates are 872 obtained by binding to ports (typically ephemeral) on a IP address 873 attached to an interface (physical or virtual, including VPN 874 interfaces) on the host. 876 For each UDP media stream the agent wishes to use, the agent SHOULD 877 obtain a candidate for each component of the media stream on each IP 878 address that the host has, with the exceptions listed below. The 879 agent obtains each candidate by binding to a UDP port on the specific 880 IP address. A host candidate (and indeed every candidate) is always 881 associated with a specific component for which it is a candidate. 883 Each component has an ID assigned to it, called the component ID. 884 For RTP-based media streams, the RTP itself has a component ID of 1, 885 and RTCP a component ID of 2. If an agent is using RTCP, it MUST 886 obtain a candidate for it. If an agent is using both RTP and RTCP, 887 it would end up with 2*K host candidates if an agent has K IP 888 addresses. 890 For other than RTP-based streams, use of multiple components is 891 discouraged since using them increases the complexity of ICE 892 processing. If multiple components are needed, the component IDs 893 SHOULD start with 1 and increase by 1 for each component. 895 The base for each host candidate is set to the candidate itself. 897 The host candidates are gathered from all IP addresses with the 898 following exceptions: 900 o Addresses from a loopback interface MUST NOT be included in the 901 candidate addresses. 903 o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site- 904 local unicast addresses [RFC3879] MUST NOT be included in the 905 address candidates. 907 o IPv4-mapped IPv6 addresses SHOULD NOT be included in the offered 908 candidates unless the application using ICE does not support IPv4 909 (i.e., is an IPv6-only application [RFC4038]). 911 o If one or more host candidates corresponding to an IPv6 address 912 generated using a mechanism that prevents location tracking 913 [I-D.ietf-6man-ipv6-address-generation-privacy] are gathered, host 914 candidates corresponding to IPv6 addresses that do allow location 915 tracking, that are configured on the same interface, and are part 916 of the same network prefix MUST NOT be gathered; and host 917 candidates corresponding to IPv6 link-local addresses MUST NOT be 918 gathered. 920 4.1.1.2. Server Reflexive and Relayed Candidates 922 Agents SHOULD obtain relayed candidates and SHOULD obtain server 923 reflexive candidates. These requirements are at SHOULD strength to 924 allow for provider variation. Use of STUN and TURN servers may be 925 unnecessary in closed networks where agents are never connected to 926 the public Internet or to endpoints outside of the closed network. 927 In such cases, a full implementation would be used for agents that 928 are dual-stack or multihomed, to select a host candidate. Use of 929 TURN servers is expensive, and when ICE is being used, they will only 930 be utilized when both endpoints are behind NATs that perform address 931 and port dependent mapping. Consequently, some deployments might 932 consider this use case to be marginal, and elect not to use TURN 933 servers. If an agent does not gather server reflexive or relayed 934 candidates, it is RECOMMENDED that the functionality be implemented 935 and just disabled through configuration, so that it can be re-enabled 936 through configuration if conditions change in the future. 938 If an agent is gathering both relayed and server reflexive 939 candidates, it uses a TURN server. If it is gathering just server 940 reflexive candidates, it uses a STUN server. 942 The agent next pairs each host candidate with the STUN or TURN server 943 with which it is configured or has discovered by some means. If a 944 STUN or TURN server is configured, it is RECOMMENDED that a domain 945 name be configured, and the DNS procedures in [RFC5389] (using SRV 946 records with the "stun" service) be used to discover the STUN server, 947 and the DNS procedures in [RFC5766] (using SRV records with the 948 "turn" service) be used to discover the TURN server. 950 This specification only considers usage of a single STUN or TURN 951 server. When there are multiple choices for that single STUN or TURN 952 server (when, for example, they are learned through DNS records and 953 multiple results are returned), an agent SHOULD use a single STUN or 954 TURN server (based on its IP address) for all candidates for a 955 particular session. This improves the performance of ICE. The 956 result is a set of pairs of host candidates with STUN or TURN 957 servers. The agent then chooses one pair, and sends a Binding or 958 Allocate request to the server from that host candidate. Binding 959 requests to a STUN server are not authenticated, and any ALTERNATE- 960 SERVER attribute in a response is ignored. Agents MUST support the 961 backwards compatibility mode for the Binding request defined in 962 [RFC5389]. Allocate requests SHOULD be authenticated using a long- 963 term credential obtained by the client through some other means. 965 Every Ta milliseconds thereafter, the agent can generate another new 966 STUN or TURN transaction. This transaction can either be a retry of 967 a previous transaction that failed with a recoverable error (such as 968 authentication failure), or a transaction for a new host candidate 969 and STUN or TURN server pair. The agent SHOULD NOT generate 970 transactions more frequently than one every Ta milliseconds. See 971 Section 13 for guidance on how to set Ta and the STUN retransmit 972 timer, RTO. 974 The agent will receive a Binding or Allocate response. A successful 975 Allocate response will provide the agent with a server reflexive 976 candidate (obtained from the mapped address) and a relayed candidate 977 in the XOR-RELAYED-ADDRESS attribute. If the Allocate request is 978 rejected because the server lacks resources to fulfill it, the agent 979 SHOULD instead send a Binding request to obtain a server reflexive 980 candidate. A Binding response will provide the agent with only a 981 server reflexive candidate (also obtained from the mapped address). 982 The base of the server reflexive candidate is the host candidate from 983 which the Allocate or Binding request was sent. The base of a 984 relayed candidate is that candidate itself. If a relayed candidate 985 is identical to a host candidate (which can happen in rare cases), 986 the relayed candidate MUST be discarded. 988 4.1.1.3. Computing Foundations 990 Finally, the agent assigns each candidate a foundation. The 991 foundation is an identifier, scoped within a session. Two candidates 992 MUST have the same foundation ID when all of the following are true: 994 o they are of the same type (host, relayed, server reflexive, or 995 peer reflexive) 997 o their bases have the same IP address (the ports can be different) 999 o for reflexive and relayed candidates, the STUN or TURN servers 1000 used to obtain them have the same IP address 1002 o they were obtained using the same transport protocol (TCP, UDP, 1003 etc.) 1005 Similarly, two candidates MUST have different foundations if their 1006 types are different, their bases have different IP addresses, the 1007 STUN or TURN servers used to obtain them have different IP addresses, 1008 or their transport protocols are different. 1010 4.1.1.4. Keeping Candidates Alive 1012 Once server reflexive and relayed candidates are allocated, they MUST 1013 be kept alive until ICE processing has completed, as described in 1014 Section 8.3. For server reflexive candidates learned through a 1015 Binding request, the bindings MUST be kept alive by additional 1016 Binding requests to the server. Refreshes for allocations are done 1017 using the Refresh transaction, as described in [RFC5766]. The 1018 Refresh requests will also refresh the server reflexive candidate. 1020 4.1.2. Prioritizing Candidates 1022 The prioritization process results in the assignment of a priority to 1023 each candidate. Each candidate for a media stream MUST have a unique 1024 priority that MUST be a positive integer between 1 and (2**31 - 1). 1025 This priority will be used by ICE to determine the order of the 1026 connectivity checks and the relative preference for candidates. 1028 An agent SHOULD compute this priority using the formula in 1029 Section 4.1.2.1 and choose its parameters using the guidelines in 1030 Section 4.1.2.2. If an agent elects to use a different formula, ICE 1031 will take longer to converge since both agents will not be 1032 coordinated in their checks. 1034 4.1.2.1. Recommended Formula 1036 When using the formula, an agent computes the priority by determining 1037 a preference for each type of candidate (server reflexive, peer 1038 reflexive, relayed, and host), and, when the agent is multihomed, 1039 choosing a preference for its IP addresses. These two preferences 1040 are then combined to compute the priority for a candidate. That 1041 priority is computed using the following formula: 1043 priority = (2^24)*(type preference) + 1044 (2^8)*(local preference) + 1045 (2^0)*(256 - component ID) 1047 The type preference MUST be an integer from 0 to 126 inclusive, and 1048 represents the preference for the type of the candidate (where the 1049 types are local, server reflexive, peer reflexive, and relayed). A 1050 126 is the highest preference, and a 0 is the lowest. Setting the 1051 value to a 0 means that candidates of this type will only be used as 1052 a last resort. The type preference MUST be identical for all 1053 candidates of the same type and MUST be different for candidates of 1054 different types. The type preference for peer reflexive candidates 1055 MUST be higher than that of server reflexive candidates. Note that 1056 candidates gathered based on the procedures of Section 4.1.1 will 1057 never be peer reflexive candidates; candidates of these type are 1058 learned from the connectivity checks performed by ICE. 1060 The local preference MUST be an integer from 0 to 65535 inclusive. 1061 It represents a preference for the particular IP address from which 1062 the candidate was obtained. 65535 represents the highest preference, 1063 and a zero, the lowest. When there is only a single IP address, this 1064 value SHOULD be set to 65535. More generally, if there are multiple 1065 candidates for a particular component for a particular media stream 1066 that have the same type, the local preference MUST be unique for each 1067 one. In this specification, this only happens for multihomed hosts 1068 or if an agent is using multiple TURN servers. If a host is 1069 multihomed because it is dual-stack, the local preference SHOULD be 1070 set equal to the precedence value for IP addresses described in RFC 1071 6724 [RFC6724]. If the host operating system provides an API for 1072 discovering preference among different addresses, those preferences 1073 SHOULD be used for the local preference to prioritize addresses 1074 indicated as preferred by the operating system. 1076 The component ID is the component ID for the candidate, and MUST be 1077 between 1 and 256 inclusive. 1079 4.1.2.2. Guidelines for Choosing Type and Local Preferences 1081 One criterion for selection of the type and local preference values 1082 is the use of a media intermediary, such as a TURN server, VPN 1083 server, or NAT. With a media intermediary, if media is sent to that 1084 candidate, it will first transit the media intermediary before being 1085 received. Relayed candidates are one type of candidate that involves 1086 a media intermediary. Another are host candidates obtained from a 1087 VPN interface. When media is transited through a media intermediary, 1088 it can increase the latency between transmission and reception. It 1089 can increase the packet losses, because of the additional router hops 1090 that may be taken. It may increase the cost of providing service, 1091 since media will be routed in and right back out of a media 1092 intermediary run by a provider. If these concerns are important, the 1093 type preference for relayed candidates SHOULD be lower than host 1094 candidates. The RECOMMENDED values are 126 for host candidates, 100 1095 for server reflexive candidates, 110 for peer reflexive candidates, 1096 and 0 for relayed candidates. 1098 Furthermore, if an agent is multihomed and has multiple IP addresses, 1099 the local preference for host candidates from a VPN interface SHOULD 1100 have a priority of 0. If multiple TURN servers are used, local 1101 priorities for the candidates obtained from the TURN servers are 1102 chosen in a similar fashion as for multihomed local candidates: the 1103 local preference value is used to indicate preference among different 1104 servers but the preference MUST be unique for each one. 1106 Another criterion for selection of preferences is IP address family. 1107 ICE works with both IPv4 and IPv6. It therefore provides a 1108 transition mechanism that allows dual-stack hosts to prefer 1109 connectivity over IPv6, but to fall back to IPv4 in case the v6 1110 networks are disconnected (due, for example, to a failure in a 6to4 1111 relay) [RFC3056]. It can also help with hosts that have both a 1112 native IPv6 address and a 6to4 address. In such a case, higher local 1113 preferences could be assigned to the v6 addresses, followed by the 1114 6to4 addresses, followed by the v4 addresses. This allows a site to 1115 obtain and begin using native v6 addresses immediately, yet still 1116 fall back to 6to4 addresses when communicating with agents in other 1117 sites that do not yet have native v6 connectivity. 1119 Another criterion for selecting preferences is security. If a user 1120 is a telecommuter, and therefore connected to a corporate network and 1121 a local home network, the user may prefer their voice traffic to be 1122 routed over the VPN in order to keep it on the corporate network when 1123 communicating within the enterprise, but use the local network when 1124 communicating with users outside of the enterprise. In such a case, 1125 a VPN address would have a higher local preference than any other 1126 address. 1128 Another criterion for selecting preferences is topological awareness. 1129 This is most useful for candidates that make use of intermediaries. 1130 In those cases, if an agent has preconfigured or dynamically 1131 discovered knowledge of the topological proximity of the 1132 intermediaries to itself, it can use that to assign higher local 1133 preferences to candidates obtained from closer intermediaries. 1135 4.1.3. Eliminating Redundant Candidates 1137 Next, the agent eliminates redundant candidates. A candidate is 1138 redundant if its transport address equals another candidate, and its 1139 base equals the base of that other candidate. Note that two 1140 candidates can have the same transport address yet have different 1141 bases, and these would not be considered redundant. Frequently, a 1142 server reflexive candidate and a host candidate will be redundant 1143 when the agent is not behind a NAT. The agent SHOULD eliminate the 1144 redundant candidate with the lower priority. 1146 4.2. Lite Implementation Requirements 1148 Lite implementations only utilize host candidates. A lite 1149 implementation MUST, for each component of each media stream, 1150 allocate zero or one IPv4 candidates. It MAY allocate zero or more 1151 IPv6 candidates, but no more than one per each IPv6 address utilized 1152 by the host. Since there can be no more than one IPv4 candidate per 1153 component of each media stream, if an agent has multiple IPv4 1154 addresses, it MUST choose one for allocating the candidate. If a 1155 host is dual-stack, it is RECOMMENDED that it allocate one IPv4 1156 candidate and one global IPv6 address. With the lite implementation, 1157 ICE cannot be used to dynamically choose amongst candidates. 1158 Therefore, including more than one candidate from a particular scope 1159 is NOT RECOMMENDED, since only a connectivity check can truly 1160 determine whether to use one address or the other. 1162 Each component has an ID assigned to it, called the component ID. 1163 For RTP-based media streams, the RTP itself has a component ID of 1, 1164 and RTCP a component ID of 2. If an agent is using RTCP, it MUST 1165 obtain candidates for it. 1167 Each candidate is assigned a foundation. The foundation MUST be 1168 different for two candidates allocated from different IP addresses, 1169 and MUST be the same otherwise. A simple integer that increments for 1170 each IP address will suffice. In addition, each candidate MUST be 1171 assigned a unique priority amongst all candidates for the same media 1172 stream. This priority SHOULD be equal to: 1174 priority = (2^24)*(126) + 1175 (2^8)*(IP precedence) + 1176 (2^0)*(256 - component ID) 1178 If a host is v4-only, it SHOULD set the IP precedence to 65535. If a 1179 host is v6 or dual-stack, the IP precedence SHOULD be the precedence 1180 value for IP addresses described in RFC 6724 [RFC6724]. 1182 Next, an agent chooses a default candidate for each component of each 1183 media stream. If a host is IPv4-only, there would only be one 1184 candidate for each component of each media stream, and therefore that 1185 candidate is the default. If a host is IPv6 or dual-stack, the 1186 selection of default is a matter of local policy. This default 1187 SHOULD be chosen such that it is the candidate most likely to be used 1188 with a peer. For IPv6-only hosts, this would typically be a globally 1189 scoped IPv6 address. For dual-stack hosts, the IPv4 address is 1190 RECOMMENDED. 1192 4.3. Encoding the Offer 1194 The syntax for the offer and answer messages is entirely a matter of 1195 convenience for the using protocol. However, the following 1196 parameters and their data types needs to be conveyed in the initial 1197 exchange: 1199 Candidate attribute There will be one or more of these for each 1200 "media stream". Each candidate is composed of: 1202 Connection Address: The IP address and transport protocol port of 1203 the candidate. 1205 Transport: An indicator of the transport protocol for this 1206 candidate. This need not be present if the using protocol will 1207 only ever run over a single transport protocol. If it runs 1208 over more than one, or if others are anticipated to be used in 1209 the future, this should be present. 1211 Foundation: A sequence of up to 32 characters. 1213 Component-ID: This would be present only if the using protocol 1214 were utilizing the concept of components. If it is, it would 1215 be a positive integer that indicates the component ID for which 1216 this is a candidate. 1218 Priority: An encoding of the 32-bit priority value. 1220 Candidate Type: The candidate type, as defined in ICE. 1222 Related Address and Port: The related IP address and port for 1223 this candidate, as defined by ICE. These MAY be omitted or set 1224 to invalid values if the agent does not want to reveal them, 1225 e.g., for privacy reasons. 1227 Extensibility Parameters: The using protocol should define some 1228 means for adding new per-candidate ICE parameters in the 1229 future. 1231 Lite Flag: If ICE lite is used by the using protocol, it needs to 1232 convey a boolean parameter which indicates whether the 1233 implementation is lite or not. 1235 Connectivity check pacing value: If an agent wants to use other than 1236 the default pacing values for the connectivity checks, it MUST 1237 indicate this in the ICE exchange. 1239 Username Fragment and Password: The using protocol has to convey a 1240 username fragment and password. The username fragment MUST 1241 contain at least 24 bits of randomness, and the password MUST 1242 contain at least 128 bits of randomness. 1244 ICE extensions: In addition to the per-candidate extensions above, 1245 the using protocol should allow for new media-stream or session- 1246 level attributes (ice-options). 1248 If the using protocol is using the ICE mismatch feature, a way is 1249 needed to convey this parameter in answers. It is a boolean flag. 1251 The exchange of parameters is symmetric; both agents need to send the 1252 same set of attributes as defined above. 1254 The using protocol may (or may not) need to deal with backwards 1255 compatibility with older implementations that do not support ICE. If 1256 the fallback mechanism is being used, then presumably the using 1257 protocol provides a way of conveying the default candidate (its IP 1258 address and port) in addition to the ICE parameters. 1260 STUN connectivity checks between agents are authenticated using the 1261 short-term credential mechanism defined for STUN [RFC5389]. This 1262 mechanism relies on a username and password that are exchanged 1263 through protocol machinery between the client and server. With ICE, 1264 the offer/answer exchange is used to exchange them. The username 1265 part of this credential is formed by concatenating a username 1266 fragment from each agent, separated by a colon. Each agent also 1267 provides a password, used to compute the message integrity for 1268 requests it receives. The username fragment and password are 1269 exchanged in the offer and answer. In addition to providing 1270 security, the username provides disambiguation and correlation of 1271 checks to media streams. See Appendix B.4 for motivation. 1273 If an agent is a lite implementation, it MUST indicate this in the 1274 offer. 1276 ICE provides for extensibility by allowing an offer or answer to 1277 contain a series of tokens that identify the ICE extensions used by 1278 that agent. If an agent supports an ICE extension, it MUST include 1279 the token defined for that extension in the offer. 1281 Once an agent has sent its offer or its answer, that agent MUST be 1282 prepared to receive both STUN and media packets on each candidate. 1283 As discussed in Section 11.1, media packets can be sent to a 1284 candidate prior to its appearance as the default destination for 1285 media in an offer or answer. 1287 5. Receiving the Initial Offer 1289 When an agent receives an initial offer, it will check if the offerer 1290 supports ICE, determine its own role, gather candidates, prioritize 1291 them, choose default candidates, encode and send an answer, and for 1292 full implementations, form the check lists and begin connectivity 1293 checks. 1295 5.1. Verifying ICE Support 1297 Certain middleboxes, such as ALGs, may alter the ICE offer and/or 1298 answer in a way that breaks ICE. If the using protocol is vulnerable 1299 to this kind of changes, called ICE mismatch, the answerer needs to 1300 detect this and signal this back to the offerer. The details on 1301 whether this is needed and how it is done is defined by the usage 1302 specifications. 1304 5.2. Determining Role 1306 For each session, each agent takes on a role. There are two roles -- 1307 controlling and controlled. The controlling agent is responsible for 1308 the choice of the final candidate pairs used for communications. For 1309 a full agent, this means nominating the candidate pairs that can be 1310 used by ICE for each media stream, and for generating the updated 1311 offer based on ICE's selection, when needed. For a lite 1312 implementation, being the controlling agent means selecting a 1313 candidate pair based on the ones in the offer and answer (for IPv4, 1314 there is only ever one pair), and then generating an updated offer 1315 reflecting that selection, when needed (it is never needed for an 1316 IPv4-only host). The controlled agent is told which candidate pairs 1317 to use for each media stream, and does not generate an updated offer 1318 to signal this information. The sections below describe in detail 1319 the actual procedures followed by controlling and controlled nodes. 1321 The rules for determining the role and the impact on behavior are as 1322 follows: 1324 Both agents are full: The agent that generated the offer which 1325 started the ICE processing MUST take the controlling role, and the 1326 other MUST take the controlled role. Both agents will form check 1327 lists, run the ICE state machines, and generate connectivity 1328 checks. The controlling agent will execute the logic in 1329 Section 8.1 to nominate pairs that will be selected by ICE, and 1330 then both agents end ICE as described in Section 8.1.2. 1332 One agent full, one lite: The full agent MUST take the controlling 1333 role, and the lite agent MUST take the controlled role. The full 1334 agent will form check lists, run the ICE state machines, and 1335 generate connectivity checks. That agent will execute the logic 1336 in Section 8.1 to nominate pairs that will be selected by ICE, and 1337 use the logic in Section 8.1.2 to end ICE. The lite 1338 implementation will just listen for connectivity checks, receive 1339 them and respond to them, and then conclude ICE as described in 1340 Section 8.2. For the lite implementation, the state of ICE 1341 processing for each media stream is considered to be Running, and 1342 the state of ICE overall is Running. 1344 Both lite: The agent that generated the offer which started the ICE 1345 processing MUST take the controlling role, and the other MUST take 1346 the controlled role. In this case, no connectivity checks are 1347 ever sent. Rather, once the offer/answer exchange completes, each 1348 agent performs the processing described in Section 8 without 1349 connectivity checks. It is possible that both agents will believe 1350 they are controlled or controlling. In the latter case, the 1351 conflict is resolved through glare detection capabilities in the 1352 signaling protocol carrying the offer/answer exchange. The state 1353 of ICE processing for each media stream is considered to be 1354 Running, and the state of ICE overall is Running. 1356 Once roles are determined for a session, they persist unless ICE is 1357 restarted. An ICE restart causes a new selection of roles and tie- 1358 breakers. 1360 5.3. Gathering Candidates 1362 The process for gathering candidates at the answerer is identical to 1363 the process for the offerer as described in Section 4.1.1 for full 1364 implementations and Section 4.2 for lite implementations. It is 1365 RECOMMENDED that this process begin immediately on receipt of the 1366 offer, prior to alerting the user. Such gathering MAY begin when an 1367 agent starts. 1369 5.4. Prioritizing Candidates 1371 The process for prioritizing candidates at the answerer is identical 1372 to the process followed by the offerer, as described in Section 4.1.2 1373 for full implementations and Section 4.2 for lite implementations. 1375 5.5. Encoding the Answer 1377 The process for encoding the answer is identical to the process 1378 followed by the offerer for both full and lite implementations, as 1379 described in Section 4.3. 1381 5.6. Forming the Check Lists 1383 Forming check lists is done only by full implementations. Lite 1384 implementations MUST skip the steps defined in this section. 1386 There is one check list per in-use media stream resulting from the 1387 offer/answer exchange. To form the check list for a media stream, 1388 the agent forms candidate pairs, computes a candidate pair priority, 1389 orders the pairs by priority, prunes them, and sets their states. 1390 These steps are described in this section. 1392 5.6.1. Forming Candidate Pairs 1394 First, the agent takes each of its candidates for a media stream 1395 (called LOCAL CANDIDATES) and pairs them with the candidates it 1396 received from its peer (called REMOTE CANDIDATES) for that media 1397 stream. In order to prevent the attacks described in Section 15.4.1, 1398 agents MAY limit the number of candidates they'll accept in an offer 1399 or answer. A local candidate is paired with a remote candidate if 1400 and only if the two candidates have the same component ID and have 1401 the same IP address version. It is possible that some of the local 1402 candidates won't get paired with remote candidates, and some of the 1403 remote candidates won't get paired with local candidates. This can 1404 happen if one agent doesn't include candidates for the all of the 1405 components for a media stream. If this happens, the number of 1406 components for that media stream is effectively reduced, and 1407 considered to be equal to the minimum across both agents of the 1408 maximum component ID provided by each agent across all components for 1409 the media stream. 1411 In the case of RTP, this would happen when one agent provides 1412 candidates for RTCP, and the other does not. As another example, the 1413 offerer can multiplex RTP and RTCP on the same port and signals that 1414 it can do that in the SDP through an SDP attribute [RFC5761]. 1415 However, since the offerer doesn't know if the answerer can perform 1416 such multiplexing, the offerer includes candidates for RTP and RTCP 1417 on separate ports, so that the offer has two components per media 1418 stream. If the answerer can perform such multiplexing, it would 1419 include just a single component for each candidate -- for the 1420 combined RTP/RTCP mux. ICE would end up acting as if there was just 1421 a single component for this candidate. 1423 With IPv6 it is common for a host to have multiple host candidates 1424 for each interface. To keep the amount of resulting candidate pairs 1425 reasonable and to avoid candidate pairs that are highly unlikely to 1426 work, IPv6 link-local addresses [RFC4291] MUST NOT be paired with 1427 other than link-local addresses. 1429 The candidate pairs whose local and remote candidates are both the 1430 default candidates for a particular component is called, 1431 unsurprisingly, the default candidate pair for that component. This 1432 is the pair that would be used to transmit media if both agents had 1433 not been ICE aware. 1435 In order to aid understanding, Figure 6 shows the relationships 1436 between several key concepts -- transport addresses, candidates, 1437 candidate pairs, and check lists, in addition to indicating the main 1438 properties of candidates and candidate pairs. 1440 +--------------------------------------------+ 1441 | | 1442 | +---------------------+ | 1443 | |+----+ +----+ +----+ | +Type | 1444 | || IP | |Port| |Tran| | +Priority | 1445 | ||Addr| | | | | | +Foundation | 1446 | |+----+ +----+ +----+ | +Component ID | 1447 | | Transport | +Related Address | 1448 | | Addr | | 1449 | +---------------------+ +Base | 1450 | Candidate | 1451 +--------------------------------------------+ 1452 * * 1453 * ************************************* 1454 * * 1455 +-------------------------------+ 1456 .| | 1457 | Local Remote | 1458 | +----+ +----+ +default? | 1459 | |Cand| |Cand| +valid? | 1460 | +----+ +----+ +nominated?| 1461 | +State | 1462 | | 1463 | | 1464 | Candidate Pair | 1465 +-------------------------------+ 1466 * * 1467 * ************ 1468 * * 1469 +------------------+ 1470 | Candidate Pair | 1471 +------------------+ 1472 +------------------+ 1473 | Candidate Pair | 1474 +------------------+ 1475 +------------------+ 1476 | Candidate Pair | 1477 +------------------+ 1479 Check 1480 List 1482 Figure 6: Conceptual Diagram of a Check List 1484 5.6.2. Computing Pair Priority and Ordering Pairs 1486 Once the pairs are formed, a candidate pair priority is computed. 1487 Let G be the priority for the candidate provided by the controlling 1488 agent. Let D be the priority for the candidate provided by the 1489 controlled agent. The priority for a pair is computed as: 1491 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 1493 Where G>D?1:0 is an expression whose value is 1 if G is greater than 1494 D, and 0 otherwise. Once the priority is assigned, the agent sorts 1495 the candidate pairs in decreasing order of priority. If two pairs 1496 have identical priority, the ordering amongst them is arbitrary. 1498 5.6.3. Pruning the Pairs 1500 This sorted list of candidate pairs is used to determine a sequence 1501 of connectivity checks that will be performed. Each check involves 1502 sending a request from a local candidate to a remote candidate. 1503 Since an agent cannot send requests directly from a reflexive 1504 candidate, but only from its base, the agent next goes through the 1505 sorted list of candidate pairs. For each pair where the local 1506 candidate is server reflexive, the server reflexive candidate MUST be 1507 replaced by its base. Once this has been done, the agent MUST prune 1508 the list. This is done by removing a pair if its local and remote 1509 candidates are identical to the local and remote candidates of a pair 1510 higher up on the priority list. The result is a sequence of ordered 1511 candidate pairs, called the check list for that media stream. 1513 In addition, in order to limit the attacks described in 1514 Section 15.4.1, an agent MUST limit the total number of connectivity 1515 checks the agent performs across all check lists to a specific value, 1516 and this value MUST be configurable. A default of 100 is 1517 RECOMMENDED. This limit is enforced by discarding the lower-priority 1518 candidate pairs until there are less than 100. It is RECOMMENDED 1519 that a lower value be utilized when possible, set to the maximum 1520 number of plausible checks that might be seen in an actual deployment 1521 configuration. The requirement for configuration is meant to provide 1522 a tool for fixing this value in the field if, once deployed, it is 1523 found to be problematic. 1525 5.6.4. Computing States 1527 Each candidate pair in the check list has a foundation and a state. 1528 The foundation is the combination of the foundations of the local and 1529 remote candidates in the pair. The state is assigned once the check 1530 list for each media stream has been computed. There are five 1531 potential values that the state can have: 1533 Waiting: A check has not been performed for this pair, and can be 1534 performed as soon as it is the highest-priority Waiting pair on 1535 the check list. 1537 In-Progress: A check has been sent for this pair, but the 1538 transaction is in progress. 1540 Succeeded: A check for this pair was already done and produced a 1541 successful result. 1543 Failed: A check for this pair was already done and failed, either 1544 never producing any response or producing an unrecoverable failure 1545 response. 1547 Frozen: A check for this pair hasn't been performed, and it can't 1548 yet be performed until some other check succeeds, allowing this 1549 pair to unfreeze and move into the Waiting state. 1551 As ICE runs, the pairs will move between states as shown in Figure 7. 1553 +-----------+ 1554 | | 1555 | | 1556 | Frozen | 1557 | | 1558 | | 1559 +-----------+ 1560 | 1561 |unfreeze 1562 | 1563 V 1564 +-----------+ +-----------+ 1565 | | | | 1566 | | perform | | 1567 | Waiting |-------->|In-Progress| 1568 | | | | 1569 | | | | 1570 +-----------+ +-----------+ 1571 / | 1572 // | 1573 // | 1574 // | 1575 / | 1576 // | 1577 failure // |success 1578 // | 1579 / | 1580 // | 1581 // | 1582 // | 1583 V V 1584 +-----------+ +-----------+ 1585 | | | | 1586 | | | | 1587 | Failed | | Succeeded | 1588 | | | | 1589 | | | | 1590 +-----------+ +-----------+ 1592 Figure 7: Pair State FSM 1594 The initial states for each pair in a check list are computed by 1595 performing the following sequence of steps: 1597 1. The agent sets all of the pairs in each check list to the Frozen 1598 state. 1600 2. The agent examines the check list for the first media stream. 1601 For that media stream: 1603 * For all pairs with the same foundation, it sets the state of 1604 the pair with the lowest component ID to Waiting. If there is 1605 more than one such pair, the one with the highest-priority is 1606 used. 1608 One of the check lists will have some number of pairs in the Waiting 1609 state, and the other check lists will have all of their pairs in the 1610 Frozen state. A check list with at least one pair that is Waiting is 1611 called an active check list, and a check list with all pairs Frozen 1612 is called a frozen check list. 1614 The check list itself is associated with a state, which captures the 1615 state of ICE checks for that media stream. There are three states: 1617 Running: In this state, ICE checks are still in progress for this 1618 media stream. 1620 Completed: In this state, ICE checks have produced nominated pairs 1621 for each component of the media stream. Consequently, ICE has 1622 succeeded and media can be sent. 1624 Failed: In this state, the ICE checks have not completed 1625 successfully for this media stream. 1627 When a check list is first constructed as the consequence of an 1628 offer/answer exchange, it is placed in the Running state. 1630 ICE processing across all media streams also has a state associated 1631 with it. This state is equal to Running while ICE processing is 1632 under way. The state is Completed when ICE processing is complete 1633 and Failed if it failed without success. Rules for transitioning 1634 between states are described below. 1636 5.7. Scheduling Checks 1638 Checks are generated only by full implementations. Lite 1639 implementations MUST skip the steps described in this section. 1641 An agent performs ordinary checks and triggered checks. The 1642 generation of both checks is governed by a timer that fires 1643 periodically for each media stream. The agent maintains a FIFO 1644 queue, called the triggered check queue, which contains candidate 1645 pairs for which checks are to be sent at the next available 1646 opportunity. When the timer fires, the agent removes the top pair 1647 from the triggered check queue, performs a connectivity check on that 1648 pair, and sets the state of the candidate pair to In-Progress. If 1649 there are no pairs in the triggered check queue, an ordinary check is 1650 sent. 1652 Once the agent has computed the check lists as described in 1653 Section 5.6, it sets a timer for each active check list. The timer 1654 fires every Ta*N seconds, where N is the number of active check lists 1655 (initially, there is only one active check list). Implementations 1656 MAY set the timer to fire less frequently than this. Implementations 1657 SHOULD take care to spread out these timers so that they do not fire 1658 at the same time for each media stream. Ta and the retransmit timer 1659 RTO are computed as described in Section 13. Multiplying by N allows 1660 this aggregate check throughput to be split between all active check 1661 lists. The first timer fires immediately, so that the agent performs 1662 a connectivity check the moment the offer/answer exchange has been 1663 done, followed by the next check Ta seconds later (since there is 1664 only one active check list). 1666 When the timer fires and there is no triggered check to be sent, the 1667 agent MUST choose an ordinary check as follows: 1669 o Find the highest-priority pair in that check list that is in the 1670 Waiting state. 1672 o If there is such a pair: 1674 * Send a STUN check from the local candidate of that pair to the 1675 remote candidate of that pair. The procedures for forming the 1676 STUN request for this purpose are described in Section 7.1.2. 1678 * Set the state of the candidate pair to In-Progress. 1680 o If there is no such pair: 1682 * Find the highest-priority pair in that check list that is in 1683 the Frozen state. 1685 * If there is such a pair: 1687 + Unfreeze the pair. 1689 + Perform a check for that pair, causing its state to 1690 transition to In-Progress. 1692 * If there is no such pair: 1694 + Terminate the timer for that check list. 1696 To compute the message integrity for the check, the agent uses the 1697 remote username fragment and password learned from the offer or 1698 answer from its peer. The local username fragment is known directly 1699 by the agent for its own candidate. 1701 6. Receipt of the Initial Answer 1703 This section describes the procedures that an agent follows when it 1704 receives the answer from the peer. It verifies that its peer 1705 supports ICE, determines its role, and for full implementations, 1706 forms the check list and begins performing ordinary checks. 1708 6.1. Verifying ICE Support 1710 The logic at the offerer is identical to that of the answerer as 1711 described in Section 5.1, with the exception that an offerer would 1712 not ever indicate ICE mismatch. 1714 6.2. Determining Role 1716 The offerer follows the same procedures described for the answerer in 1717 Section 5.2. 1719 6.3. Forming the Check List 1721 Formation of check lists is performed only by full implementations. 1722 The offerer follows the same procedures described for the answerer in 1723 Section 5.6. 1725 6.4. Performing Ordinary Checks 1727 Ordinary checks are performed only by full implementations. The 1728 offerer follows the same procedures described for the answerer in 1729 Section 5.7. 1731 7. Performing Connectivity Checks 1733 This section describes how connectivity checks are performed. All 1734 ICE implementations are required to be compliant to [RFC5389], as 1735 opposed to the older [RFC3489]. However, whereas a full 1736 implementation will both generate checks (acting as a STUN client) 1737 and receive them (acting as a STUN server), a lite implementation 1738 will only receive checks, and thus will only act as a STUN server. 1740 7.1. STUN Client Procedures 1742 These procedures define how an agent sends a connectivity check, 1743 whether it is an ordinary or a triggered check. These procedures are 1744 only applicable to full implementations. 1746 7.1.1. Creating Permissions for Relayed Candidates 1748 If the connectivity check is being sent using a relayed local 1749 candidate, the client MUST create a permission first if it has not 1750 already created one previously. It would have created one previously 1751 if it had told the TURN server to create a permission for the given 1752 relayed candidate towards the IP address of the remote candidate. To 1753 create the permission, the agent follows the procedures defined in 1754 [RFC5766]. The permission MUST be created towards the IP address of 1755 the remote candidate. It is RECOMMENDED that the agent defer 1756 creation of a TURN channel until ICE completes, in which case 1757 permissions for connectivity checks are normally created using a 1758 CreatePermission request. Once established, the agent MUST keep the 1759 permission active until ICE concludes. 1761 7.1.2. Sending the Request 1763 A connectivity check is generated by sending a Binding request from a 1764 local candidate to a remote candidate. [RFC5389] describes how 1765 Binding requests are constructed and generated. A connectivity check 1766 MUST utilize the STUN short-term credential mechanism. Support for 1767 backwards compatibility with RFC 3489 MUST NOT be used or assumed 1768 with connectivity checks. The FINGERPRINT mechanism MUST be used for 1769 connectivity checks. 1771 ICE extends STUN by defining several new attributes, including 1772 PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. These 1773 new attributes are formally defined in Section 16.1, and their usage 1774 is described in the subsections below. These STUN extensions are 1775 applicable only to connectivity checks used for ICE. 1777 7.1.2.1. PRIORITY and USE-CANDIDATE 1779 An agent MUST include the PRIORITY attribute in its Binding request. 1780 The attribute MUST be set equal to the priority that would be 1781 assigned, based on the algorithm in Section 4.1.2, to a peer 1782 reflexive candidate, should one be learned as a consequence of this 1783 check (see Section 7.1.3.2.1 for how peer reflexive candidates are 1784 learned). This priority value will be computed identically to how 1785 the priority for the local candidate of the pair was computed, except 1786 that the type preference is set to the value for peer reflexive 1787 candidate types. 1789 The controlling agent MAY include the USE-CANDIDATE attribute in the 1790 Binding request. The controlled agent MUST NOT include it in its 1791 Binding request. This attribute signals that the controlling agent 1792 wishes to cease checks for this component, and use the candidate pair 1793 resulting from the check for this component. Section 8.1.1 provides 1794 guidance on determining when to include it. 1796 7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING 1798 The agent MUST include the ICE-CONTROLLED attribute in the request if 1799 it is in the controlled role, and MUST include the ICE-CONTROLLING 1800 attribute in the request if it is in the controlling role. The 1801 content of either attribute MUST be the tie-breaker that was 1802 determined in Section 5.2. These attributes are defined fully in 1803 Section 16.1. 1805 7.1.2.3. Forming Credentials 1807 A Binding request serving as a connectivity check MUST utilize the 1808 STUN short-term credential mechanism. The username for the 1809 credential is formed by concatenating the username fragment provided 1810 by the peer with the username fragment of the agent sending the 1811 request, separated by a colon (":"). The password is equal to the 1812 password provided by the peer. For example, consider the case where 1813 agent L is the offerer, and agent R is the answerer. Agent L 1814 included a username fragment of LFRAG for its candidates and a 1815 password of LPASS. Agent R provided a username fragment of RFRAG and 1816 a password of RPASS. A connectivity check from L to R utilizes the 1817 username RFRAG:LFRAG and a password of RPASS. A connectivity check 1818 from R to L utilizes the username LFRAG:RFRAG and a password of 1819 LPASS. The responses utilize the same usernames and passwords as the 1820 requests (note that the USERNAME attribute is not present in the 1821 response). 1823 7.1.2.4. DiffServ Treatment 1825 If the agent is using Diffserv Codepoint markings [RFC2475] in its 1826 media packets, it SHOULD apply those same markings to its 1827 connectivity checks. 1829 7.1.3. Processing the Response 1831 When a Binding response is received, it is correlated to its Binding 1832 request using the transaction ID, as defined in [RFC5389], which then 1833 ties it to the candidate pair for which the Binding request was sent. 1834 This section defines additional procedures for processing Binding 1835 responses specific to this usage of STUN. 1837 7.1.3.1. Failure Cases 1839 If the STUN transaction generates a 487 (Role Conflict) error 1840 response, the agent checks whether it included the ICE-CONTROLLED or 1841 ICE-CONTROLLING attribute in the Binding request. If the request 1842 contained the ICE-CONTROLLED attribute, the agent MUST switch to the 1843 controlling role if it has not already done so. If the request 1844 contained the ICE-CONTROLLING attribute, the agent MUST switch to the 1845 controlled role if it has not already done so. Once it has switched, 1846 the agent MUST enqueue the candidate pair whose check generated the 1847 487 into the triggered check queue. The state of that pair is set to 1848 Waiting. When the triggered check is sent, it will contain an ICE- 1849 CONTROLLING or ICE-CONTROLLED attribute reflecting its new role. 1850 Note, however, that the tie-breaker value MUST NOT be reselected. 1852 A change in roles will require an agent to recompute pair priorities 1853 (Section 5.6.2), since those priorities are a function of controlling 1854 and controlled roles. The change in role will also impact whether 1855 the agent is responsible for selecting nominated pairs and generating 1856 updated offers upon conclusion of ICE. 1858 Agents MAY support receipt of ICMP errors for connectivity checks. 1859 If the STUN transaction generates an ICMP error, the agent sets the 1860 state of the pair to Failed. If the STUN transaction generates a 1861 STUN error response that is unrecoverable (as defined in [RFC5389]) 1862 or times out, the agent sets the state of the pair to Failed. 1864 The agent MUST check that the source IP address and port of the 1865 response equal the destination IP address and port to which the 1866 Binding request was sent, and that the destination IP address and 1867 port of the response match the source IP address and port from which 1868 the Binding request was sent. In other words, the source and 1869 destination transport addresses in the request and responses are 1870 symmetric. If they are not symmetric, the agent sets the state of 1871 the pair to Failed. 1873 7.1.3.2. Success Cases 1875 A check is considered to be a success if all of the following are 1876 true: 1878 o The STUN transaction generated a success response. 1880 o The source IP address and port of the response equals the 1881 destination IP address and port to which the Binding request was 1882 sent. 1884 o The destination IP address and port of the response match the 1885 source IP address and port from which the Binding request was 1886 sent. 1888 7.1.3.2.1. Discovering Peer Reflexive Candidates 1890 The agent checks the mapped address from the STUN response. If the 1891 transport address does not match any of the local candidates that the 1892 agent knows about, the mapped address represents a new candidate -- a 1893 peer reflexive candidate. Like other candidates, it has a type, 1894 base, priority, and foundation. They are computed as follows: 1896 o Its type is equal to peer reflexive. 1898 o Its base is set equal to the local candidate of the candidate pair 1899 from which the STUN check was sent. 1901 o Its priority is set equal to the value of the PRIORITY attribute 1902 in the Binding request. 1904 o Its foundation is selected as described in Section 4.1.1.3. 1906 This peer reflexive candidate is then added to the list of local 1907 candidates for the media stream. Its username fragment and password 1908 are the same as all other local candidates for that media stream. 1909 However, the peer reflexive candidate is not paired with other remote 1910 candidates. This is not necessary; a valid pair will be generated 1911 from it momentarily based on the procedures in Section 7.1.3.2.2. If 1912 an agent wishes to pair the peer reflexive candidate with other 1913 remote candidates besides the one in the valid pair that will be 1914 generated, the agent MAY generate an updated offer which includes the 1915 peer reflexive candidate. This will cause it to be paired with all 1916 other remote candidates. 1918 7.1.3.2.2. Constructing a Valid Pair 1920 The agent constructs a candidate pair whose local candidate equals 1921 the mapped address of the response, and whose remote candidate equals 1922 the destination address to which the request was sent. This is 1923 called a valid pair, since it has been validated by a STUN 1924 connectivity check. The valid pair may equal the pair that generated 1925 the check, may equal a different pair in the check list, or may be a 1926 pair not currently on any check list. If the pair equals the pair 1927 that generated the check or is on a check list currently, it is also 1928 added to the VALID LIST, which is maintained by the agent for each 1929 media stream. This list is empty at the start of ICE processing, and 1930 fills as checks are performed, resulting in valid candidate pairs. 1932 It will be very common that the pair will not be on any check list. 1933 Recall that the check list has pairs whose local candidates are never 1934 server reflexive; those pairs had their local candidates converted to 1935 the base of the server reflexive candidates, and then pruned if they 1936 were redundant. When the response to the STUN check arrives, the 1937 mapped address will be reflexive if there is a NAT between the two. 1938 In that case, the valid pair will have a local candidate that doesn't 1939 match any of the pairs in the check list. 1941 If the pair is not on any check list, the agent computes the priority 1942 for the pair based on the priority of each candidate, using the 1943 algorithm in Section 5.6. The priority of the local candidate 1944 depends on its type. If it is not peer reflexive, it is equal to the 1945 priority signaled for that candidate in the offer or answer. If it 1946 is peer reflexive, it is equal to the PRIORITY attribute the agent 1947 placed in the Binding request that just completed. The priority of 1948 the remote candidate is taken from the offer/answer of the peer. If 1949 the candidate does not appear there, then the check must have been a 1950 triggered check to a new remote candidate. In that case, the 1951 priority is taken as the value of the PRIORITY attribute in the 1952 Binding request that triggered the check that just completed. The 1953 pair is then added to the VALID LIST. 1955 7.1.3.2.3. Updating Pair States 1957 The agent sets the state of the pair that *generated* the check to 1958 Succeeded. Note that, the pair which *generated* the check may be 1959 different than the valid pair constructed in Section 7.1.3.2.2 as a 1960 consequence of the response. The success of this check might also 1961 cause the state of other checks to change as well. The agent MUST 1962 perform the following two steps: 1964 1. The agent changes the states for all other Frozen pairs for the 1965 same media stream and same foundation to Waiting. Typically, but 1966 not always, these other pairs will have different component IDs. 1968 2. If there is a pair in the valid list for every component of this 1969 media stream (where this is the actual number of components being 1970 used, in cases where the number of components signaled in the 1971 offer/answer differs from offerer to answerer), the success of 1972 this check may unfreeze checks for other media streams. Note 1973 that this step is followed not just the first time the valid list 1974 under consideration has a pair for every component, but every 1975 subsequent time a check succeeds and adds yet another pair to 1976 that valid list. The agent examines the check list for each 1977 other media stream in turn: 1979 * If the check list is active, the agent changes the state of 1980 all Frozen pairs in that check list whose foundation matches a 1981 pair in the valid list under consideration to Waiting. 1983 * If the check list is frozen, and there is at least one pair in 1984 the check list whose foundation matches a pair in the valid 1985 list under consideration, the state of all pairs in the check 1986 list whose foundation matches a pair in the valid list under 1987 consideration is set to Waiting. This will cause the check 1988 list to become active, and ordinary checks will begin for it, 1989 as described in Section 5.7. 1991 * If the check list is frozen, and there are no pairs in the 1992 check list whose foundation matches a pair in the valid list 1993 under consideration, the agent 1995 + groups together all of the pairs with the same foundation, 1996 and 1998 + for each group, sets the state of the pair with the lowest 1999 component ID to Waiting. If there is more than one such 2000 pair, the one with the highest-priority is used. 2002 7.1.3.2.4. Updating the Nominated Flag 2004 If the agent was a controlling agent, and it had included a USE- 2005 CANDIDATE attribute in the Binding request, the valid pair generated 2006 from that check has its nominated flag set to true. This flag 2007 indicates that this valid pair should be used for media if it is the 2008 highest-priority one amongst those whose nominated flag is set. This 2009 may conclude ICE processing for this media stream or all media 2010 streams; see Section 8. 2012 If the agent is the controlled agent, the response may be the result 2013 of a triggered check that was sent in response to a request that 2014 itself had the USE-CANDIDATE attribute. This case is described in 2015 Section 7.2.1.5, and may now result in setting the nominated flag for 2016 the pair learned from the original request. 2018 7.1.3.3. Check List and Timer State Updates 2020 Regardless of whether the check was successful or failed, the 2021 completion of the transaction may require updating of check list and 2022 timer states. 2024 If all of the pairs in the check list are now either in the Failed or 2025 Succeeded state: 2027 o If there is not a pair in the valid list for each component of the 2028 media stream, the state of the check list is set to Failed. 2030 o For each frozen check list, the agent 2032 * groups together all of the pairs with the same foundation, and 2034 * for each group, sets the state of the pair with the lowest 2035 component ID to Waiting. If there is more than one such pair, 2036 the one with the highest-priority is used. 2038 If none of the pairs in the check list are in the Waiting or Frozen 2039 state, the check list is no longer considered active, and will not 2040 count towards the value of N in the computation of timers for 2041 ordinary checks as described in Section 5.7. 2043 7.2. STUN Server Procedures 2045 An agent MUST be prepared to receive a Binding request on the base of 2046 each candidate it included in its most recent offer or answer. This 2047 requirement holds even if the peer is a lite implementation. 2049 The agent MUST use the short-term credential mechanism (i.e., the 2050 MESSAGE-INTEGRITY attribute) to authenticate the request and perform 2051 a message integrity check. Likewise, the short-term credential 2052 mechanism MUST be used for the response. The agent MUST consider the 2053 username to be valid if it consists of two values separated by a 2054 colon, where the first value is equal to the username fragment 2055 generated by the agent in an offer or answer for a session in- 2056 progress. It is possible (and in fact very likely) that an offerer 2057 will receive a Binding request prior to receiving the answer from its 2058 peer. If this happens, the agent MUST immediately generate a 2059 response (including computation of the mapped address as described in 2060 Section 7.2.1.2). The agent has sufficient information at this point 2061 to generate the response; the password from the peer is not required. 2062 Once the answer is received, it MUST proceed with the remaining steps 2063 required, namely, Section 7.2.1.3, Section 7.2.1.4, and 2064 Section 7.2.1.5 for full implementations. In cases where multiple 2065 STUN requests are received before the answer, this may cause several 2066 pairs to be queued up in the triggered check queue. 2068 An agent MUST NOT utilize the ALTERNATE-SERVER mechanism, and MUST 2069 NOT support the backwards-compatibility mechanisms to RFC 3489. It 2070 MUST utilize the FINGERPRINT mechanism. 2072 If the agent is using Diffserv Codepoint markings [RFC2475] in its 2073 media packets, it SHOULD apply those same markings to its responses 2074 to Binding requests. The same would apply to any layer 2 markings 2075 the endpoint might be applying to media packets. 2077 7.2.1. Additional Procedures for Full Implementations 2079 This subsection defines the additional server procedures applicable 2080 to full implementations. 2082 7.2.1.1. Detecting and Repairing Role Conflicts 2084 Normally, the rules for selection of a role in Section 5.2 will 2085 result in each agent selecting a different role -- one controlling 2086 and one controlled. However, in unusual call flows, typically 2087 utilizing third party call control, it is possible for both agents to 2088 select the same role. This section describes procedures for checking 2089 for this case and repairing it. These procedures apply only to 2090 usages of ICE that require conflict resolution. The usage document 2091 MUST specify whether this mechanism is needed. 2093 An agent MUST examine the Binding request for either the ICE- 2094 CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these 2095 procedures: 2097 o If neither ICE-CONTROLLING nor ICE-CONTROLLED is present in the 2098 request, the peer agent may have implemented a previous version of 2099 this specification. There may be a conflict, but it cannot be 2100 detected. 2102 o If the agent is in the controlling role, and the ICE-CONTROLLING 2103 attribute is present in the request: 2105 * If the agent's tie-breaker is larger than or equal to the 2106 contents of the ICE-CONTROLLING attribute, the agent generates 2107 a Binding error response and includes an ERROR-CODE attribute 2108 with a value of 487 (Role Conflict) but retains its role. 2110 * If the agent's tie-breaker is less than the contents of the 2111 ICE-CONTROLLING attribute, the agent switches to the controlled 2112 role. 2114 o If the agent is in the controlled role, and the ICE-CONTROLLED 2115 attribute is present in the request: 2117 * If the agent's tie-breaker is larger than or equal to the 2118 contents of the ICE-CONTROLLED attribute, the agent switches to 2119 the controlling role. 2121 * If the agent's tie-breaker is less than the contents of the 2122 ICE-CONTROLLED attribute, the agent generates a Binding error 2123 response and includes an ERROR-CODE attribute with a value of 2124 487 (Role Conflict) but retains its role. 2126 o If the agent is in the controlled role and the ICE-CONTROLLING 2127 attribute was present in the request, or the agent was in the 2128 controlling role and the ICE-CONTROLLED attribute was present in 2129 the request, there is no conflict. 2131 A change in roles will require an agent to recompute pair priorities 2132 (Section 5.6.2), since those priorities are a function of controlling 2133 and controlled roles. The change in role will also impact whether 2134 the agent is responsible for selecting nominated pairs and generated 2135 updated offers upon conclusion of ICE. 2137 The remaining sections in Section 7.2.1 are followed if the server 2138 generated a successful response to the Binding request, even if the 2139 agent changed roles. 2141 7.2.1.2. Computing Mapped Address 2143 For requests being received on a relayed candidate, the source 2144 transport address used for STUN processing (namely, generation of the 2145 XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the 2146 TURN server. That source transport address will be present in the 2147 XOR-PEER-ADDRESS attribute of a Data Indication message, if the 2148 Binding request was delivered through a Data Indication. If the 2149 Binding request was delivered through a ChannelData message, the 2150 source transport address is the one that was bound to the channel. 2152 7.2.1.3. Learning Peer Reflexive Candidates 2154 If the source transport address of the request does not match any 2155 existing remote candidates, it represents a new peer reflexive remote 2156 candidate. This candidate is constructed as follows: 2158 o The priority of the candidate is set to the PRIORITY attribute 2159 from the request. 2161 o The type of the candidate is set to peer reflexive. 2163 o The foundation of the candidate is set to an arbitrary value, 2164 different from the foundation for all other remote candidates. If 2165 any subsequent offer/answer exchanges contain this peer reflexive 2166 candidate, it will signal the actual foundation for the candidate. 2168 o The component ID of this candidate is set to the component ID for 2169 the local candidate to which the request was sent. 2171 This candidate is added to the list of remote candidates. However, 2172 the agent does not pair this candidate with any local candidates. 2174 7.2.1.4. Triggered Checks 2176 Next, the agent constructs a pair whose local candidate is equal to 2177 the transport address on which the STUN request was received, and a 2178 remote candidate equal to the source transport address where the 2179 request came from (which may be the peer reflexive remote candidate 2180 that was just learned). The local candidate will either be a host 2181 candidate (for cases where the request was not received through a 2182 relay) or a relayed candidate (for cases where it is received through 2183 a relay). The local candidate can never be a server reflexive 2184 candidate. Since both candidates are known to the agent, it can 2185 obtain their priorities and compute the candidate pair priority. 2186 This pair is then looked up in the check list. There can be one of 2187 several outcomes: 2189 o If the pair is already on the check list: 2191 * If the state of that pair is Waiting or Frozen, a check for 2192 that pair is enqueued into the triggered check queue if not 2193 already present. 2195 * If the state of that pair is In-Progress, the agent cancels the 2196 in-progress transaction. Cancellation means that the agent 2197 will not retransmit the request, will not treat the lack of 2198 response to be a failure, but will wait the duration of the 2199 transaction timeout for a response. In addition, the agent 2200 MUST create a new connectivity check for that pair 2201 (representing a new STUN Binding request transaction) by 2202 enqueueing the pair in the triggered check queue. The state of 2203 the pair is then changed to Waiting. 2205 * If the state of the pair is Failed, it is changed to Waiting 2206 and the agent MUST create a new connectivity check for that 2207 pair (representing a new STUN Binding request transaction), by 2208 enqueueing the pair in the triggered check queue. 2210 * If the state of that pair is Succeeded, nothing further is 2211 done. 2213 These steps are done to facilitate rapid completion of ICE when both 2214 agents are behind NAT. 2216 o If the pair is not already on the check list: 2218 * The pair is inserted into the check list based on its priority. 2220 * Its state is set to Waiting. 2222 * The pair is enqueued into the triggered check queue. 2224 When a triggered check is to be sent, it is constructed and processed 2225 as described in Section 7.1.2. These procedures require the agent to 2226 know the transport address, username fragment, and password for the 2227 peer. The username fragment for the remote candidate is equal to the 2228 part after the colon of the USERNAME in the Binding request that was 2229 just received. Using that username fragment, the agent can check the 2230 offers/answers received from its peer (there may be more than one in 2231 cases of forking), and find this username fragment. The 2232 corresponding password is then selected. 2234 7.2.1.5. Updating the Nominated Flag 2236 If the Binding request received by the agent had the USE-CANDIDATE 2237 attribute set, and the agent is in the controlled role, the agent 2238 looks at the state of the pair computed in Section 7.2.1.4: 2240 o If the state of this pair is Succeeded, it means that the check 2241 generated by this pair produced a successful response. This would 2242 have caused the agent to construct a valid pair when that success 2243 response was received (see Section 7.1.3.2.2). The agent now sets 2244 the nominated flag in the valid pair to true. This may end ICE 2245 processing for this media stream; see Section 8. 2247 o If the state of this pair is In-Progress, if its check produces a 2248 successful result, the resulting valid pair has its nominated flag 2249 set when the response arrives. This may end ICE processing for 2250 this media stream when it arrives; see Section 8. 2252 7.2.2. Additional Procedures for Lite Implementations 2254 If the check that was just received contained a USE-CANDIDATE 2255 attribute, the agent constructs a candidate pair whose local 2256 candidate is equal to the transport address on which the request was 2257 received, and whose remote candidate is equal to the source transport 2258 address of the request that was received. This candidate pair is 2259 assigned an arbitrary priority, and placed into a list of valid 2260 candidates called the valid list. The agent sets the nominated flag 2261 for that pair to true. ICE processing is considered complete for a 2262 media stream if the valid list contains a candidate pair for each 2263 component. 2265 8. Concluding ICE Processing 2267 This section describes how an agent completes ICE. 2269 8.1. Procedures for Full Implementations 2271 Concluding ICE involves nominating pairs by the controlling agent and 2272 updating of state machinery. 2274 8.1.1. Nominating Pairs 2276 The controlling agent nominates pairs to be selected by ICE by using 2277 one of two techniques: regular nomination or aggressive nomination. 2278 If its peer has a lite implementation, an agent MUST use a regular 2279 nomination algorithm. If its peer is using ICE options (present in 2280 an ice-options attribute from the peer) that the agent does not 2281 understand, the agent MUST use a regular nomination algorithm. If 2282 its peer is a full implementation and isn't using any ICE options or 2283 is using ICE options understood by the agent, the agent MAY use 2284 either the aggressive or the regular nomination algorithm. However, 2285 the regular algorithm is RECOMMENDED since it provides greater 2286 stability. 2288 8.1.1.1. Regular Nomination 2290 With regular nomination, the agent lets some number of checks 2291 complete, each of which omit the USE-CANDIDATE attribute. Once one 2292 or more checks complete successfully for a component of a media 2293 stream, valid pairs are generated and added to the valid list. The 2294 agent lets the checks continue until some stopping criterion is met, 2295 and then picks amongst the valid pairs based on an evaluation 2296 criterion. The criteria for stopping the checks and for evaluating 2297 the valid pairs is entirely a matter of local optimization. 2299 When the controlling agent selects the valid pair, it repeats the 2300 check that produced this valid pair (by enqueueing the pair that 2301 generated the check into the triggered check queue), this time with 2302 the USE-CANDIDATE attribute. This check should succeed (since the 2303 previous did), causing the nominated flag of that and only that pair 2304 to be set. Consequently, there will be only a single nominated pair 2305 in the valid list for each component, and when the state of the check 2306 list moves to completed, that exact pair is selected by ICE for 2307 sending and receiving media for that component. 2309 Regular nomination provides the most flexibility, since the agent has 2310 control over the stopping and selection criteria for checks. The 2311 only requirement is that the agent MUST eventually pick one and only 2312 one candidate pair and generate a check for that pair with the USE- 2313 CANDIDATE attribute present. Regular nomination also improves ICE's 2314 resilience to variations in implementation (see Section 12). Regular 2315 nomination is also more stable, allowing both agents to converge on a 2316 single pair for media without any transient selections, which can 2317 happen with the aggressive algorithm. The drawback of regular 2318 nomination is that it is guaranteed to increase latencies because it 2319 requires an additional check to be done. 2321 8.1.1.2. Aggressive Nomination 2323 With aggressive nomination, the controlling agent includes the USE- 2324 CANDIDATE attribute in every check it sends. Once the first check 2325 for a component succeeds, it will be added to the valid list and have 2326 its nominated flag set. When all components have a nominated pair in 2327 the valid list, media can begin to flow using the highest-priority 2328 nominated pair. However, because the agent included the USE- 2329 CANDIDATE attribute in all of its checks, another check may yet 2330 complete, causing another valid pair to have its nominated flag set. 2331 ICE always selects the highest-priority nominated candidate pair from 2332 the valid list as the one used for media. Consequently, the selected 2333 pair may actually change briefly as ICE checks complete, resulting in 2334 a set of transient selections until it stabilizes. 2336 If certain connectivity check messages are lost, ICE agents using 2337 aggressive nomination may end up with different views on the selected 2338 candidate pair. In this case, if a security protocol that is able to 2339 authenticate the communicating parties (e.g., DTLS) is used, the 2340 controlled agent may receive valid secured traffic or handshake 2341 initialization originating from the controlling agent on a candidate 2342 pair that is different from the one the controlled agent considers as 2343 the selected pair. If this happens, the controlled agent MUST 2344 consider the pair with the secured traffic as the correct selected 2345 pair. If such security protocol is not used, both agents SHOULD 2346 continue sending connectivity check messages on the selected pair 2347 even after a pair has already been selected for use. In order to 2348 prevent the problem described here, at least one check from both 2349 agents needs to fully succeed on the selected pair. 2351 8.1.2. Updating States 2353 For both controlling and controlled agents, the state of ICE 2354 processing depends on the presence of nominated candidate pairs in 2355 the valid list and on the state of the check list. Note that, at any 2356 time, more than one of the following cases can apply: 2358 o If there are no nominated pairs in the valid list for a media 2359 stream and the state of the check list is Running, ICE processing 2360 continues. 2362 o If there is at least one nominated pair in the valid list for a 2363 media stream and the state of the check list is Running: 2365 * The agent MUST remove all Waiting and Frozen pairs in the check 2366 list and triggered check queue for the same component as the 2367 nominated pairs for that media stream. 2369 * If an In-Progress pair in the check list is for the same 2370 component as a nominated pair, the agent SHOULD cease 2371 retransmissions for its check if its pair priority is lower 2372 than the lowest-priority nominated pair for that component. 2374 o Once there is at least one nominated pair in the valid list for 2375 every component of at least one media stream and the state of the 2376 check list is Running: 2378 * The agent MUST change the state of processing for its check 2379 list for that media stream to Completed. 2381 * The agent MUST continue to respond to any checks it may still 2382 receive for that media stream, and MUST perform triggered 2383 checks if required by the processing of Section 7.2. 2385 * The agent MUST continue retransmitting any In-Progress checks 2386 for that check list. 2388 * The agent MAY begin transmitting media for this media stream as 2389 described in Section 11.1. 2391 o Once the state of each check list is Completed: 2393 * The agent sets the state of ICE processing overall to 2394 Completed. 2396 * If the controlling agent is using an aggressive nomination 2397 algorithm, this may result in several updated offers as the 2398 pairs selected for media change. An agent MAY delay sending 2399 the offer for a brief interval (one second is RECOMMENDED) in 2400 order to allow the selected pairs to stabilize. 2402 o If the state of the check list is Failed, ICE has not been able to 2403 complete for this media stream. The correct behavior depends on 2404 the state of the check lists for other media streams: 2406 * If all check lists are Failed, ICE processing overall is 2407 considered to be in the Failed state, and the agent SHOULD 2408 consider the session a failure, SHOULD NOT restart ICE, and the 2409 controlling agent SHOULD terminate the entire session. 2411 * If at least one of the check lists for other media streams is 2412 Completed, the controlling agent SHOULD remove the failed media 2413 stream from the session in its updated offer. 2415 * If none of the check lists for other media streams are 2416 Completed, but at least one is Running, the agent SHOULD let 2417 ICE continue. 2419 8.2. Procedures for Lite Implementations 2421 Concluding ICE for a lite implementation is relatively 2422 straightforward. There are two cases to consider: 2424 The implementation is lite, and its peer is full. 2426 The implementation is lite, and its peer is lite. 2428 The effect of ICE concluding is that the agent can free any allocated 2429 host candidates that were not utilized by ICE, as described in 2430 Section 8.3. 2432 8.2.1. Peer Is Full 2434 In this case, the agent will receive connectivity checks from its 2435 peer. When an agent has received a connectivity check that includes 2436 the USE-CANDIDATE attribute for each component of a media stream, the 2437 state of ICE processing for that media stream moves from Running to 2438 Completed. When the state of ICE processing for all media streams is 2439 Completed, the state of ICE processing overall is Completed. 2441 The lite implementation will never itself determine that ICE 2442 processing has failed for a media stream; rather, the full peer will 2443 make that determination and then remove or restart the failed media 2444 stream in a subsequent offer. 2446 8.2.2. Peer Is Lite 2448 Once the offer/answer exchange has completed, both agents examine 2449 their candidates and those of its peer. For each media stream, each 2450 agent pairs up its own candidates with the candidates of its peer for 2451 that media stream. Two candidates are paired up when they are for 2452 the same component, utilize the same transport protocol (UDP in this 2453 specification), and are from the same IP address family (IPv4 or 2454 IPv6). 2456 o If there is a single pair per component, that pair is added to the 2457 Valid list. If all of the components for a media stream had one 2458 pair, the state of ICE processing for that media stream is set to 2459 Completed. If all media streams are Completed, the state of ICE 2460 processing is set to Completed overall. This will always be the 2461 case for implementations that are IPv4-only. 2463 o If there is more than one pair per component: 2465 * The agent MUST select a pair based on local policy. Since this 2466 case only arises for IPv6, it is RECOMMENDED that an agent 2467 follow the procedures of RFC 6724 [RFC6724] to select a single 2468 pair. 2470 * The agent adds the selected pair for each component to the 2471 valid list. As described in Section 11.1, this will permit 2472 media to begin flowing. However, it is possible (and in fact 2473 likely) that both agents have chosen different pairs. 2475 * To reconcile this, the controlling agent MUST send an updated 2476 offer which will include the remote-candidates attribute. 2478 * The agent MUST NOT update the state of ICE processing when the 2479 offer is sent. If this subsequent offer completes, the 2480 controlling agent MUST change the state of ICE processing to 2481 Completed for all media streams, and the state of ICE 2482 processing overall to Completed. 2484 8.3. Freeing Candidates 2486 8.3.1. Full Implementation Procedures 2488 The procedures in Section 8 require that an agent continue to listen 2489 for STUN requests and continue to generate triggered checks for a 2490 media stream, even once processing for that stream completes. The 2491 rules in this section describe when it is safe for an agent to cease 2492 sending or receiving checks on a candidate that was not selected by 2493 ICE, and then free the candidate. 2495 8.3.2. Lite Implementation Procedures 2497 A lite implementation MAY free candidates not selected by ICE as soon 2498 as ICE processing has reached the Completed state for all peers for 2499 all media streams using those candidates. 2501 9. ICE Restarts 2503 An agent MAY restart ICE processing for an existing media stream. An 2504 ICE restart, as the name implies, will cause all previous states of 2505 ICE processing to be flushed and checks to start anew. The only 2506 difference between an ICE restart and a brand new media session is 2507 that, during the restart, media can continue to be sent to the 2508 previously validated pair. 2510 An agent MUST restart ICE for a media stream if: 2512 o The offer is being generated for the purposes of changing the 2513 target of the media stream. In other words, if an agent wants to 2514 generate an updated offer that, had ICE not been in use, would 2515 result in a new value for the destination of a media component. 2517 o An agent is changing its implementation level. This typically 2518 only happens in third party call control use cases, where the 2519 entity performing the signaling is not the entity receiving the 2520 media, and it has changed the target of media mid-session to 2521 another entity that has a different ICE implementation. 2523 To restart ICE, an agent MUST change both the password and the user 2524 name fragment for the media stream in an offer. The set of 2525 candidates in the new offer MAY include some, none, or all of the 2526 previous candidates for that stream and MAY include a totally new set 2527 of candidates 2529 10. Keepalives 2531 All endpoints MUST send keepalives for each media session. These 2532 keepalives serve the purpose of keeping NAT bindings alive for the 2533 media session. These keepalives MUST be sent even if ICE is not 2534 being utilized for the session at all. The keepalive SHOULD be sent 2535 using a format that is supported by its peer. ICE endpoints allow 2536 for STUN-based keepalives for UDP streams, and as such, STUN 2537 keepalives MUST be used when an agent is a full ICE implementation 2538 and is communicating with a peer that supports ICE (lite or full). 2539 If the peer does not support ICE, the choice of a packet format for 2540 keepalives is a matter of local implementation. A format that allows 2541 packets to easily be sent in the absence of actual media content is 2542 RECOMMENDED. Examples of formats that readily meet this goal are RTP 2543 No-Op [I-D.ietf-avt-rtp-no-op], and in cases where both sides support 2544 it, RTP comfort noise [RFC3389]. If the peer doesn't support any 2545 formats that are particularly well suited for keepalives, an agent 2546 SHOULD send RTP packets with an incorrect version number, or some 2547 other form of error that would cause them to be discarded by the 2548 peer. 2550 If there has been no packet sent on the candidate pair ICE is using 2551 for a media component for Tr seconds (where packets include those 2552 defined for the component (RTP or RTCP) and previous keepalives), an 2553 agent MUST generate a keepalive on that pair. Tr SHOULD be 2554 configurable and SHOULD have a default of 15 seconds. Tr MUST NOT be 2555 configured to less than 15 seconds. Alternatively, if an agent has a 2556 dynamic way to discover the binding lifetimes of the intervening 2557 NATs, it can use that value to determine Tr. Administrators 2558 deploying ICE in more controlled networking environments SHOULD set 2559 Tr to the longest duration possible in their environment. 2561 If STUN is being used for keepalives, a STUN Binding Indication is 2562 used [RFC5389]. The Indication MUST NOT utilize any authentication 2563 mechanism. It SHOULD contain the FINGERPRINT attribute to aid in 2564 demultiplexing, but SHOULD NOT contain any other attributes. It is 2565 used solely to keep the NAT bindings alive. The Binding Indication 2566 is sent using the same local and remote candidates that are being 2567 used for media. Though Binding Indications are used for keepalives, 2568 an agent MUST be prepared to receive a connectivity check as well. 2569 If a connectivity check is received, a response is generated as 2570 discussed in [RFC5389], but there is no impact on ICE processing 2571 otherwise. 2573 An agent MUST begin the keepalive processing once ICE has selected 2574 candidates for usage with media, or media begins to flow, whichever 2575 happens first. Keepalives end once the session terminates or the 2576 media stream is removed. 2578 11. Media Handling 2580 11.1. Sending Media 2582 Procedures for sending media differ for full and lite 2583 implementations. 2585 11.1.1. Procedures for Full Implementations 2587 Agents always send media using a candidate pair, called the selected 2588 candidate pair. An agent will send media to the remote candidate in 2589 the selected pair (setting the destination address and port of the 2590 packet equal to that remote candidate), and will send it from the 2591 local candidate of the selected pair. When the local candidate is 2592 server or peer reflexive, media is originated from the base. Media 2593 sent from a relayed candidate is sent from the base through that TURN 2594 server, using procedures defined in [RFC5766]. 2596 If the local candidate is a relayed candidate, it is RECOMMENDED that 2597 an agent create a channel on the TURN server towards the remote 2598 candidate. This is done using the procedures for channel creation as 2599 defined in Section 11 of [RFC5766]. 2601 The selected pair for a component of a media stream is: 2603 o empty if the state of the check list for that media stream is 2604 Running, and there is no previous selected pair for that component 2605 due to an ICE restart 2607 o equal to the previous selected pair for a component of a media 2608 stream if the state of the check list for that media stream is 2609 Running, and there was a previous selected pair for that component 2610 due to an ICE restart 2612 o equal to the highest-priority nominated pair for that component in 2613 the valid list if the state of the check list is Completed 2615 If the selected pair for at least one component of a media stream is 2616 empty, an agent MUST NOT send media for any component of that media 2617 stream. If the selected pair for each component of a media stream 2618 has a value, an agent MAY send media for all components of that media 2619 stream. 2621 11.1.2. Procedures for Lite Implementations 2623 A lite implementation MUST NOT send media until it has a Valid list 2624 that contains a candidate pair for each component of that media 2625 stream. Once that happens, the agent MAY begin sending media 2626 packets. To do that, it sends media to the remote candidate in the 2627 pair (setting the destination address and port of the packet equal to 2628 that remote candidate), and will send it from the local candidate. 2630 11.1.3. Procedures for All Implementations 2632 ICE has interactions with jitter buffer adaptation mechanisms. An 2633 RTP stream can begin using one candidate, and switch to another one, 2634 though this happens rarely with ICE. The newer candidate may result 2635 in RTP packets taking a different path through the network -- one 2636 with different delay characteristics. As discussed below, agents are 2637 encouraged to re-adjust jitter buffers when there are changes in 2638 source or destination address of media packets. Furthermore, many 2639 audio codecs use the marker bit to signal the beginning of a 2640 talkspurt, for the purposes of jitter buffer adaptation. For such 2641 codecs, it is RECOMMENDED that the sender set the marker bit 2642 [RFC3550] when an agent switches transmission of media from one 2643 candidate pair to another. 2645 11.2. Receiving Media 2647 ICE implementations MUST be prepared to receive media on each 2648 component on any candidates provided for that component in the most 2649 recent offer/answer exchange (in the case of RTP, this would include 2650 both RTP and RTCP if candidates were provided for both). 2652 It is RECOMMENDED that, when an agent receives an RTP packet with a 2653 new source or destination IP address for a particular media stream, 2654 that the agent re-adjust its jitter buffers. 2656 RFC 3550 [RFC3550] describes an algorithm in Section 8.2 for 2657 detecting synchronization source (SSRC) collisions and loops. These 2658 algorithms are based, in part, on seeing different source transport 2659 addresses with the same SSRC. However, when ICE is used, such 2660 changes will sometimes occur as the media streams switch between 2661 candidates. An agent will be able to determine that a media stream 2662 is from the same peer as a consequence of the STUN exchange that 2663 proceeds media transmission. Thus, if there is a change in source 2664 transport address, but the media packets come from the same peer 2665 agent, this SHOULD NOT be treated as an SSRC collision. 2667 12. Extensibility Considerations 2669 This specification makes very specific choices about how both agents 2670 in a session coordinate to arrive at the set of candidate pairs that 2671 are selected for media. It is anticipated that future specifications 2672 will want to alter these algorithms, whether they are simple changes 2673 like timer tweaks or larger changes like a revamp of the priority 2674 algorithm. When such a change is made, providing interoperability 2675 between the two agents in a session is critical. 2677 First, ICE provides the ice-options attribute. Each extension or 2678 change to ICE is associated with a token. When an agent supporting 2679 such an extension or change generates an offer or an answer, it MUST 2680 include the token for that extension in this attribute. This allows 2681 each side to know what the other side is doing. This attribute MUST 2682 NOT be present if the agent doesn't support any ICE extensions or 2683 changes. 2685 One of the complications in achieving interoperability is that ICE 2686 relies on a distributed algorithm running on both agents to converge 2687 on an agreed set of candidate pairs. If the two agents run different 2688 algorithms, it can be difficult to guarantee convergence on the same 2689 candidate pairs. The regular nomination procedure described in 2690 Section 8 eliminates some of the tight coordination by delegating the 2691 selection algorithm completely to the controlling agent. 2692 Consequently, when a controlling agent is communicating with a peer 2693 that supports options it doesn't know about, the agent MUST run a 2694 regular nomination algorithm. When regular nomination is used, ICE 2695 will converge perfectly even when both agents use different pair 2696 prioritization algorithms. One of the keys to such convergence is 2697 triggered checks, which ensure that the nominated pair is validated 2698 by both agents. Consequently, any future ICE enhancements MUST 2699 preserve triggered checks. 2701 ICE is also extensible to other media streams beyond RTP, and for 2702 transport protocols beyond UDP. Extensions to ICE for non-RTP media 2703 streams need to specify how many components they utilize, and assign 2704 component IDs to them, starting at 1 for the most important component 2705 ID. Specifications for new transport protocols must define how, if 2706 at all, various steps in the ICE processing differ from UDP. 2708 13. Setting Ta and RTO 2710 During the gathering phase of ICE (Section 4.1.1) and while ICE is 2711 performing connectivity checks (Section 7), an agent sends STUN and 2712 TURN transactions. These transactions are paced at a rate of one 2713 every Ta milliseconds, and utilize a specific RTO. This section 2714 describes how the values of Ta and RTO are computed. This 2715 computation depends on whether ICE is being used with a real-time 2716 media stream (such as RTP) or something else. When ICE is used for a 2717 stream with a known maximum bandwidth, the computation in 2718 Section 13.1 MAY be followed to rate-control the ICE exchanges. For 2719 all other streams, the computation in Section 13.2 MUST be followed. 2721 13.1. Real-time Media Streams 2723 The values of RTO and Ta change during the lifetime of ICE 2724 processing. One set of values applies during the gathering phase, 2725 and the other, for connectivity checks. 2727 The value of Ta SHOULD be configurable, and SHOULD have a default of: 2729 For each media stream i: 2730 Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime 2732 1 2733 Ta = MAX (20ms, ------------------- ) 2734 k 2735 ---- 2736 \ 1 2737 > ------ 2738 / Ta_i 2739 ---- 2740 i=1 2742 where k is the number of media streams. During the gathering phase, 2743 Ta is computed based on the number of media streams the agent has 2744 indicated in its offer or answer, and the RTP packet size and RTP 2745 ptime are those of the most preferred codec for each media stream. 2747 Once an offer and answer have been exchanged, the agent recomputes Ta 2748 to pace the connectivity checks. In that case, the value of Ta is 2749 based on the number of media streams that will actually be used in 2750 the session, and the RTP packet size and RTP ptime are those of the 2751 most preferred codec with which the agent will send. 2753 In addition, the retransmission timer for the STUN transactions, RTO, 2754 defined in [RFC5389], SHOULD be configurable and during the gathering 2755 phase, SHOULD have a default of: 2757 RTO = MAX (100ms, Ta * (number of pairs)) 2759 where the number of pairs refers to the number of pairs of candidates 2760 with STUN or TURN servers. 2762 For connectivity checks, RTO SHOULD be configurable and SHOULD have a 2763 default of: 2765 RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress)) 2767 where Num-Waiting is the number of checks in the check list in the 2768 Waiting state, and Num-In-Progress is the number of checks in the In- 2769 Progress state. Note that the RTO will be different for each 2770 transaction as the number of checks in the Waiting and In-Progress 2771 states change. 2773 These formulas are aimed at causing STUN transactions to be paced at 2774 the same rate as media. This ensures that ICE will work properly 2775 under the same network conditions needed to support the media as 2776 well. See Appendix B.1 for additional discussion and motivations. 2777 Because of this pacing, it will take a certain amount of time to 2778 obtain all of the server reflexive and relayed candidates. 2779 Implementations should be aware of the time required to do this, and 2780 if the application requires a time budget, limit the number of 2781 candidates that are gathered. 2783 The formulas result in a behavior whereby an agent will send its 2784 first packet for every single connectivity check before performing a 2785 retransmit. This can be seen in the formulas for the RTO (which 2786 represents the retransmit interval). Those formulas scale with N, 2787 the number of checks to be performed. As a result of this, ICE 2788 maintains a nicely constant rate, but becomes more sensitive to 2789 packet loss. The loss of the first single packet for any 2790 connectivity check is likely to cause that pair to take a long time 2791 to be validated, and instead, a lower-priority check (but one for 2792 which there was no packet loss) is much more likely to complete 2793 first. This results in ICE performing sub-optimally, choosing lower- 2794 priority pairs over higher-priority pairs. Implementors should be 2795 aware of this consequence, but still should utilize the timer values 2796 described here. 2798 13.2. Non-real-time Sessions 2800 In cases where ICE is used to establish some kind of session that is 2801 not real time, and has no fixed rate associated with it that is known 2802 to work on the network in which ICE is deployed, Ta and RTO revert to 2803 more conservative values. Ta SHOULD be configurable, SHOULD have a 2804 default of 500 ms, and MUST NOT be configurable to be less than 500 2805 ms. 2807 If other Ta value than the default is used, the agent MUST indicate 2808 the value it prefers to use in the ICE exchange. Both agents MUST 2809 use the higher out of the two proposed values. 2811 In addition, the retransmission timer for the STUN transactions, RTO, 2812 SHOULD be configurable and during the gathering phase, SHOULD have a 2813 default of: 2815 RTO = MAX (500ms, Ta * (number of pairs)) 2817 where the number of pairs refers to the number of pairs of candidates 2818 with STUN or TURN servers. 2820 For connectivity checks, RTO SHOULD be configurable and SHOULD have a 2821 default of: 2823 RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress)) 2825 14. Example 2827 The example is based on the simplified topology of Figure 8. 2829 +-------+ 2830 |STUN | 2831 |Server | 2832 +-------+ 2833 | 2834 +---------------------+ 2835 | | 2836 | Internet | 2837 | | 2838 +---------------------+ 2839 | | 2840 | | 2841 +---------+ | 2842 | NAT | | 2843 +---------+ | 2844 | | 2845 | | 2846 +-----+ +-----+ 2847 | L | | R | 2848 +-----+ +-----+ 2850 Figure 8: Example Topology 2852 Two agents, L and R, are using ICE. Both are full-mode ICE 2853 implementations and use aggressive nomination when they are 2854 controlling. Both agents have a single IPv4 address. For agent L, 2855 it is 10.0.1.1 in private address space [RFC1918], and for agent R, 2856 192.0.2.1 on the public Internet. Both are configured with the same 2857 STUN server (shown in this example for simplicity, although in 2858 practice the agents do not need to use the same STUN server), which 2859 is listening for STUN Binding requests at an IP address of 192.0.2.2 2860 and port 3478. TURN servers are not used in this example. Agent L 2861 is behind a NAT, and agent R is on the public Internet. The NAT has 2862 an endpoint independent mapping property and an address dependent 2863 filtering property. The public side of the NAT has an IP address of 2864 192.0.2.3. 2866 To facilitate understanding, transport addresses are listed using 2867 variables that have mnemonic names. The format of the name is 2868 entity-type-seqno, where entity refers to the entity whose IP address 2869 the transport address is on, and is one of "L", "R", "STUN", or 2870 "NAT". The type is either "PUB" for transport addresses that are 2871 public, and "PRIV" for transport addresses that are private. 2872 Finally, seq-no is a sequence number that is different for each 2873 transport address of the same type on a particular entity. Each 2874 variable has an IP address and port, denoted by varname.IP and 2875 varname.PORT, respectively, where varname is the name of the 2876 variable. 2878 The STUN server has advertised transport address STUN-PUB-1 (which is 2879 192.0.2.2:3478). 2881 In the call flow itself, STUN messages are annotated with several 2882 attributes. The "S=" attribute indicates the source transport 2883 address of the message. The "D=" attribute indicates the destination 2884 transport address of the message. The "MA=" attribute is used in 2885 STUN Binding response messages and refers to the mapped address. 2886 "USE-CAND" implies the presence of the USE-CANDIDATE attribute. 2888 The call flow examples omit STUN authentication operations and RTCP, 2889 and focus on RTP for a single media stream between two full 2890 implementations. 2892 L NAT STUN R 2893 |RTP STUN alloc. | | 2894 |(1) STUN Req | | | 2895 |S=$L-PRIV-1 | | | 2896 |D=$STUN-PUB-1 | | | 2897 |------------->| | | 2898 | |(2) STUN Req | | 2899 | |S=$NAT-PUB-1 | | 2900 | |D=$STUN-PUB-1 | | 2901 | |------------->| | 2902 | |(3) STUN Res | | 2903 | |S=$STUN-PUB-1 | | 2904 | |D=$NAT-PUB-1 | | 2905 | |MA=$NAT-PUB-1 | | 2906 | |<-------------| | 2907 |(4) STUN Res | | | 2908 |S=$STUN-PUB-1 | | | 2909 |D=$L-PRIV-1 | | | 2910 |MA=$NAT-PUB-1 | | | 2911 |<-------------| | | 2912 |(5) Offer | | | 2913 |------------------------------------------->| 2914 | | | | RTP STUN 2915 | | | | alloc. 2916 | | |(6) STUN Req | 2917 | | |S=$R-PUB-1 | 2918 | | |D=$STUN-PUB-1 | 2919 | | |<-------------| 2920 | | |(7) STUN Res | 2921 | | |S=$STUN-PUB-1 | 2922 | | |D=$R-PUB-1 | 2923 | | |MA=$R-PUB-1 | 2924 | | |------------->| 2925 |(8) answer | | | 2926 |<-------------------------------------------| 2927 | |(9) Bind Req | |Begin 2928 | |S=$R-PUB-1 | |Connectivity 2929 | |D=L-PRIV-1 | |Checks 2930 | |<----------------------------| 2931 | |Dropped | | 2932 |(10) Bind Req | | | 2933 |S=$L-PRIV-1 | | | 2934 |D=$R-PUB-1 | | | 2935 |USE-CAND | | | 2936 |------------->| | | 2937 | |(11) Bind Req | | 2938 | |S=$NAT-PUB-1 | | 2939 | |D=$R-PUB-1 | | 2940 | |USE-CAND | | 2941 | |---------------------------->| 2942 | |(12) Bind Res | | 2943 | |S=$R-PUB-1 | | 2944 | |D=$NAT-PUB-1 | | 2945 | |MA=$NAT-PUB-1 | | 2946 | |<----------------------------| 2947 |(13) Bind Res | | | 2948 |S=$R-PUB-1 | | | 2949 |D=$L-PRIV-1 | | | 2950 |MA=$NAT-PUB-1 | | | 2951 |<-------------| | | 2952 |RTP flows | | | 2953 | |(14) Bind Req | | 2954 | |S=$R-PUB-1 | | 2955 | |D=$NAT-PUB-1 | | 2956 | |<----------------------------| 2957 |(15) Bind Req | | | 2958 |S=$R-PUB-1 | | | 2959 |D=$L-PRIV-1 | | | 2960 |<-------------| | | 2961 |(16) Bind Res | | | 2962 |S=$L-PRIV-1 | | | 2963 |D=$R-PUB-1 | | | 2964 |MA=$R-PUB-1 | | | 2965 |------------->| | | 2966 | |(17) Bind Res | | 2967 | |S=$NAT-PUB-1 | | 2968 | |D=$R-PUB-1 | | 2969 | |MA=$R-PUB-1 | | 2970 | |---------------------------->| 2971 | | | |RTP flows 2972 Figure 9: Example Flow 2974 First, agent L obtains a host candidate from its local IP address 2975 (not shown), and from that, sends a STUN Binding request to the STUN 2976 server to get a server reflexive candidate (messages 1-4). Recall 2977 that the NAT has the address and port independent mapping property. 2978 Here, it creates a binding of NAT-PUB-1 for this UDP request, and 2979 this becomes the server reflexive candidate for RTP. 2981 Agent L sets a type preference of 126 for the host candidate and 100 2982 for the server reflexive. The local preference is 65535. Based on 2983 this, the priority of the host candidate is 2130706431 and for the 2984 server reflexive candidate is 1694498815. The host candidate is 2985 assigned a foundation of 1, and the server reflexive, a foundation of 2986 2. These are sent to the peer in an offer. 2988 This offer is received at agent R. Agent R will obtain a host 2989 candidate, and from it, obtain a server reflexive candidate (messages 2990 6-7). Since R is not behind a NAT, this candidate is identical to 2991 its host candidate, and they share the same base. It therefore 2992 discards this redundant candidate and ends up with a single host 2993 candidate. With identical type and local preferences as L, the 2994 priority for this candidate is 2130706431. It chooses a foundation 2995 of 1 for its single candidate. The answerer's candidates are then 2996 sent to the offerer. 2998 Since neither side indicated that it is lite, the agent that sent the 2999 offer that began ICE processing (agent L) becomes the controlling 3000 agent. 3002 Agents L and R both pair up the candidates. They both initially have 3003 two pairs. However, agent L will prune the pair containing its 3004 server reflexive candidate, resulting in just one. At agent L, this 3005 pair has a local candidate of $L_PRIV_1 and remote candidate of 3006 $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that 3007 an implementation would represent this as a 64-bit integer so as not 3008 to lose precision). At agent R, there are two pairs. The highest 3009 priority has a local candidate of $R_PUB_1 and remote candidate of 3010 $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a 3011 local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and 3012 priority 3.63891E+18. 3014 Agent R begins its connectivity check (message 9) for the first pair 3015 (between the two host candidates). Since R is the controlled agent 3016 for this session, the check omits the USE-CANDIDATE attribute. The 3017 host candidate from agent L is private and behind a NAT, and thus 3018 this check won't be successful, because the packet cannot be routed 3019 from R to L. 3021 When agent L gets the answer, it performs its one and only 3022 connectivity check (messages 10-13). It implements the aggressive 3023 nomination algorithm, and thus includes a USE-CANDIDATE attribute in 3024 this check. Since the check succeeds, agent L creates a new pair, 3025 whose local candidate is from the mapped address in the Binding 3026 response (NAT-PUB-1 from message 13) and whose remote candidate is 3027 the destination of the request (R-PUB-1 from message 10). This is 3028 added to the valid list. In addition, it is marked as selected since 3029 the Binding request contained the USE-CANDIDATE attribute. Since 3030 there is a selected candidate in the Valid list for the one component 3031 of this media stream, ICE processing for this stream moves into the 3032 Completed state. Agent L can now send media if it so chooses. 3034 Soon after receipt of the STUN Binding request from agent L (message 3035 11), agent R will generate its triggered check. This check happens 3036 to match the next one on its check list -- from its host candidate to 3037 agent L's server reflexive candidate. This check (messages 14-17) 3038 will succeed. Consequently, agent R constructs a new candidate pair 3039 using the mapped address from the response as the local candidate (R- 3040 PUB-1) and the destination of the request (NAT-PUB-1) as the remote 3041 candidate. This pair is added to the Valid list for that media 3042 stream. Since the check was generated in the reverse direction of a 3043 check that contained the USE-CANDIDATE attribute, the candidate pair 3044 is marked as selected. Consequently, processing for this stream 3045 moves into the Completed state, and agent R can also send media. 3047 15. Security Considerations 3049 There are several types of attacks possible in an ICE system. This 3050 section considers these attacks and their countermeasures. These 3051 countermeasures include: 3053 o Using ICE in conjunction with secure signaling techniques, such as 3054 SIPS. 3056 o Limiting the total number of connectivity checks to 100, and 3057 optionally limiting the number of candidates they'll accept in an 3058 offer or answer. 3060 15.1. Attacks on Connectivity Checks 3062 An attacker might attempt to disrupt the STUN connectivity checks. 3063 Ultimately, all of these attacks fool an agent into thinking 3064 something incorrect about the results of the connectivity checks. 3065 The possible false conclusions an attacker can try and cause are: 3067 False Invalid: An attacker can fool a pair of agents into thinking a 3068 candidate pair is invalid, when it isn't. This can be used to 3069 cause an agent to prefer a different candidate (such as one 3070 injected by the attacker) or to disrupt a call by forcing all 3071 candidates to fail. 3073 False Valid: An attacker can fool a pair of agents into thinking a 3074 candidate pair is valid, when it isn't. This can cause an agent 3075 to proceed with a session, but then not be able to receive any 3076 media. 3078 False Peer Reflexive Candidate: An attacker can cause an agent to 3079 discover a new peer reflexive candidate, when it shouldn't have. 3080 This can be used to redirect media streams to a Denial-of-Service 3081 (DoS) target or to the attacker, for eavesdropping or other 3082 purposes. 3084 False Valid on False Candidate: An attacker has already convinced an 3085 agent that there is a candidate with an address that doesn't 3086 actually route to that agent (for example, by injecting a false 3087 peer reflexive candidate or false server reflexive candidate). It 3088 must then launch an attack that forces the agents to believe that 3089 this candidate is valid. 3091 If an attacker can cause a false peer reflexive candidate or false 3092 valid on a false candidate, it can launch any of the attacks 3093 described in [RFC5389]. 3095 To force the false invalid result, the attacker has to wait for the 3096 connectivity check from one of the agents to be sent. When it is, 3097 the attacker needs to inject a fake response with an unrecoverable 3098 error response, such as a 400. However, since the candidate is, in 3099 fact, valid, the original request may reach the peer agent, and 3100 result in a success response. The attacker needs to force this 3101 packet or its response to be dropped, through a DoS attack, layer 2 3102 network disruption, or other technique. If it doesn't do this, the 3103 success response will also reach the originator, alerting it to a 3104 possible attack. Fortunately, this attack is mitigated completely 3105 through the STUN short-term credential mechanism. The attacker needs 3106 to inject a fake response, and in order for this response to be 3107 processed, the attacker needs the password. If the offer/answer 3108 signaling is secured, the attacker will not have the password and its 3109 response will be discarded. 3111 Forcing the fake valid result works in a similar way. The agent 3112 needs to wait for the Binding request from each agent, and inject a 3113 fake success response. The attacker won't need to worry about 3114 disrupting the actual response since, if the candidate is not valid, 3115 it presumably wouldn't be received anyway. However, like the fake 3116 invalid attack, this attack is mitigated by the STUN short-term 3117 credential mechanism in conjunction with a secure offer/answer 3118 exchange. 3120 Forcing the false peer reflexive candidate result can be done either 3121 with fake requests or responses, or with replays. We consider the 3122 fake requests and responses case first. It requires the attacker to 3123 send a Binding request to one agent with a source IP address and port 3124 for the false candidate. In addition, the attacker must wait for a 3125 Binding request from the other agent, and generate a fake response 3126 with a XOR-MAPPED-ADDRESS attribute containing the false candidate. 3127 Like the other attacks described here, this attack is mitigated by 3128 the STUN message integrity mechanisms and secure offer/answer 3129 exchanges. 3131 Forcing the false peer reflexive candidate result with packet replays 3132 is different. The attacker waits until one of the agents sends a 3133 check. It intercepts this request, and replays it towards the other 3134 agent with a faked source IP address. It must also prevent the 3135 original request from reaching the remote agent, either by launching 3136 a DoS attack to cause the packet to be dropped, or forcing it to be 3137 dropped using layer 2 mechanisms. The replayed packet is received at 3138 the other agent, and accepted, since the integrity check passes (the 3139 integrity check cannot and does not cover the source IP address and 3140 port). It is then responded to. This response will contain a XOR- 3141 MAPPED-ADDRESS with the false candidate, and will be sent to that 3142 false candidate. The attacker must then receive it and relay it 3143 towards the originator. 3145 The other agent will then initiate a connectivity check towards that 3146 false candidate. This validation needs to succeed. This requires 3147 the attacker to force a false valid on a false candidate. Injecting 3148 of fake requests or responses to achieve this goal is prevented using 3149 the integrity mechanisms of STUN and the offer/answer exchange. 3150 Thus, this attack can only be launched through replays. To do that, 3151 the attacker must intercept the check towards this false candidate, 3152 and replay it towards the other agent. Then, it must intercept the 3153 response and replay that back as well. 3155 This attack is very hard to launch unless the attacker is identified 3156 by the fake candidate. This is because it requires the attacker to 3157 intercept and replay packets sent by two different hosts. If both 3158 agents are on different networks (for example, across the public 3159 Internet), this attack can be hard to coordinate, since it needs to 3160 occur against two different endpoints on different parts of the 3161 network at the same time. 3163 If the attacker itself is identified by the fake candidate, the 3164 attack is easier to coordinate. However, if the media path is 3165 secured (e.g., using SRTP [RFC3711]), the attacker will not be able 3166 to play the media packets, but will only be able to discard them, 3167 effectively disabling the media stream for the call. However, this 3168 attack requires the agent to disrupt packets in order to block the 3169 connectivity check from reaching the target. In that case, if the 3170 goal is to disrupt the media stream, it's much easier to just disrupt 3171 it with the same mechanism, rather than attack ICE. 3173 15.2. Attacks on Server Reflexive Address Gathering 3175 ICE endpoints make use of STUN Binding requests for gathering server 3176 reflexive candidates from a STUN server. These requests are not 3177 authenticated in any way. As a consequence, there are numerous 3178 techniques an attacker can employ to provide the client with a false 3179 server reflexive candidate: 3181 o An attacker can compromise the DNS, causing DNS queries to return 3182 a rogue STUN server address. That server can provide the client 3183 with fake server reflexive candidates. This attack is mitigated 3184 by DNS security, though DNS-SEC is not required to address it. 3186 o An attacker that can observe STUN messages (such as an attacker on 3187 a shared network segment, like WiFi) can inject a fake response 3188 that is valid and will be accepted by the client. 3190 o An attacker can compromise a STUN server by means of a virus, and 3191 cause it to send responses with incorrect mapped addresses. 3193 A false mapped address learned by these attacks will be used as a 3194 server reflexive candidate in the ICE exchange. For this candidate 3195 to actually be used for media, the attacker must also attack the 3196 connectivity checks, and in particular, force a false valid on a 3197 false candidate. This attack is very hard to launch if the false 3198 address identifies a fourth party (neither the offerer, answerer, nor 3199 attacker), since it requires attacking the checks generated by each 3200 agent in the session, and is prevented by SRTP if it identifies the 3201 attacker themself. 3203 If the attacker elects not to attack the connectivity checks, the 3204 worst it can do is prevent the server reflexive candidate from being 3205 used. However, if the peer agent has at least one candidate that is 3206 reachable by the agent under attack, the STUN connectivity checks 3207 themselves will provide a peer reflexive candidate that can be used 3208 for the exchange of media. Peer reflexive candidates are generally 3209 preferred over server reflexive candidates. As such, an attack 3210 solely on the STUN address gathering will normally have no impact on 3211 a session at all. 3213 15.3. Attacks on Relayed Candidate Gathering 3215 An attacker might attempt to disrupt the gathering of relayed 3216 candidates, forcing the client to believe it has a false relayed 3217 candidate. Exchanges with the TURN server are authenticated using a 3218 long-term credential. Consequently, injection of fake responses or 3219 requests will not work. In addition, unlike Binding requests, 3220 Allocate requests are not susceptible to replay attacks with modified 3221 source IP addresses and ports, since the source IP address and port 3222 are not utilized to provide the client with its relayed candidate. 3224 However, TURN servers are susceptible to DNS attacks, or to viruses 3225 aimed at the TURN server, for purposes of turning it into a zombie or 3226 rogue server. These attacks can be mitigated by DNS-SEC and through 3227 good box and software security on TURN servers. 3229 Even if an attacker has caused the client to believe in a false 3230 relayed candidate, the connectivity checks cause such a candidate to 3231 be used only if they succeed. Thus, an attacker must launch a false 3232 valid on a false candidate, per above, which is a very difficult 3233 attack to coordinate. 3235 15.4. Insider Attacks 3237 In addition to attacks where the attacker is a third party trying to 3238 insert fake offers, answers, or stun messages, there are attacks 3239 possible with ICE when the attacker is an authenticated and valid 3240 participant in the ICE exchange. 3242 15.4.1. STUN Amplification Attack 3244 The STUN amplification attack is similar to the voice hammer. 3245 However, instead of voice packets being directed to the target, STUN 3246 connectivity checks are directed to the target. The attacker sends 3247 an offer with a large number of candidates, say, 50. The answerer 3248 receives the offer, and starts its checks, which are directed at the 3249 target, and consequently, never generate a response. The answerer 3250 will start a new connectivity check every Ta ms (say, Ta=20ms). 3251 However, the retransmission timers are set to a large number due to 3252 the large number of candidates. As a consequence, packets will be 3253 sent at an interval of one every Ta milliseconds, and then with 3254 increasing intervals after that. Thus, STUN will not send packets at 3255 a rate faster than media would be sent, and the STUN packets persist 3256 only briefly, until ICE fails for the session. Nonetheless, this is 3257 an amplification mechanism. 3259 It is impossible to eliminate the amplification, but the volume can 3260 be reduced through a variety of heuristics. Agents SHOULD limit the 3261 total number of connectivity checks they perform to 100. 3262 Additionally, agents MAY limit the number of candidates they'll 3263 accept in an offer or answer. 3265 Frequently, protocols that wish to avoid these kinds of attacks force 3266 the initiator to wait for a response prior to sending the next 3267 message. However, in the case of ICE, this is not possible. It is 3268 not possible to differentiate the following two cases: 3270 o There was no response because the initiator is being used to 3271 launch a DoS attack against an unsuspecting target that will not 3272 respond. 3274 o There was no response because the IP address and port are not 3275 reachable by the initiator. 3277 In the second case, another check should be sent at the next 3278 opportunity, while in the former case, no further checks should be 3279 sent. 3281 16. STUN Extensions 3283 16.1. New Attributes 3285 This specification defines four new attributes, PRIORITY, USE- 3286 CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. 3288 The PRIORITY attribute indicates the priority that is to be 3289 associated with a peer reflexive candidate, should one be discovered 3290 by this check. It is a 32-bit unsigned integer, and has an attribute 3291 value of 0x0024. 3293 The USE-CANDIDATE attribute indicates that the candidate pair 3294 resulting from this check should be used for transmission of media. 3295 The attribute has no content (the Length field of the attribute is 3296 zero); it serves as a flag. It has an attribute value of 0x0025. 3298 The ICE-CONTROLLED attribute is present in a Binding request and 3299 indicates that the client believes it is currently in the controlled 3300 role. The content of the attribute is a 64-bit unsigned integer in 3301 network byte order, which contains a random number used for tie- 3302 breaking of role conflicts. 3304 The ICE-CONTROLLING attribute is present in a Binding request and 3305 indicates that the client believes it is currently in the controlling 3306 role. The content of the attribute is a 64-bit unsigned integer in 3307 network byte order, which contains a random number used for tie- 3308 breaking of role conflicts. 3310 16.2. New Error Response Codes 3312 This specification defines a single error response code: 3314 487 (Role Conflict): The Binding request contained either the ICE- 3315 CONTROLLING or ICE-CONTROLLED attribute, indicating a role that 3316 conflicted with the server. The server ran a tie-breaker based on 3317 the tie-breaker value in the request and determined that the 3318 client needs to switch roles. 3320 17. Operational Considerations 3322 This section discusses issues relevant to network operators looking 3323 to deploy ICE. 3325 17.1. NAT and Firewall Types 3327 ICE was designed to work with existing NAT and firewall equipment. 3328 Consequently, it is not necessary to replace or reconfigure existing 3329 firewall and NAT equipment in order to facilitate deployment of ICE. 3330 Indeed, ICE was developed to be deployed in environments where the 3331 Voice over IP (VoIP) operator has no control over the IP network 3332 infrastructure, including firewalls and NAT. 3334 That said, ICE works best in environments where the NAT devices are 3335 "behave" compliant, meeting the recommendations defined in [RFC4787] 3336 and [RFC5382]. In networks with behave-compliant NAT, ICE will work 3337 without the need for a TURN server, thus improving voice quality, 3338 decreasing call setup times, and reducing the bandwidth demands on 3339 the network operator. 3341 17.2. Bandwidth Requirements 3343 Deployment of ICE can have several interactions with available 3344 network capacity that operators should take into consideration. 3346 17.2.1. STUN and TURN Server Capacity Planning 3348 First and foremost, ICE makes use of TURN and STUN servers, which 3349 would typically be located in the network operator's data centers. 3350 The STUN servers require relatively little bandwidth. For each 3351 component of each media stream, there will be one or more STUN 3352 transactions from each client to the STUN server. In a basic voice- 3353 only IPv4 VoIP deployment, there will be four transactions per call 3354 (one for RTP and one for RTCP, for both caller and callee). Each 3355 transaction is a single request and a single response, the former 3356 being 20 bytes long, and the latter, 28. Consequently, if a system 3357 has N users, and each makes four calls in a busy hour, this would 3358 require N*1.7bps. For one million users, this is 1.7 Mbps, a very 3359 small number (relatively speaking). 3361 TURN traffic is more substantial. The TURN server will see traffic 3362 volume equal to the STUN volume (indeed, if TURN servers are 3363 deployed, there is no need for a separate STUN server), in addition 3364 to the traffic for the actual media traffic. The amount of calls 3365 requiring TURN for media relay is highly dependent on network 3366 topologies, and can and will vary over time. In a network with 100% 3367 behave-compliant NAT, it is exactly zero. At time of writing, large- 3368 scale consumer deployments were seeing between 5 and 10 percent of 3369 calls requiring TURN servers. Considering a voice-only deployment 3370 using G.711 (so 80 kbps in each direction), with .2 erlangs during 3371 the busy hour, this is N*3.2 kbps. For a population of one million 3372 users, this is 3.2 Gbps, assuming a 10% usage of TURN servers. 3374 17.2.2. Gathering and Connectivity Checks 3376 The process of gathering of candidates and performing of connectivity 3377 checks can be bandwidth intensive. ICE has been designed to pace 3378 both of these processes. The gathering phase and the connectivity 3379 check phase are meant to generate traffic at roughly the same 3380 bandwidth as the media traffic itself. This was done to ensure that, 3381 if a network is designed to support multimedia traffic of a certain 3382 type (voice, video, or just text), it will have sufficient capacity 3383 to support the ICE checks for that media. Of course, the ICE checks 3384 will cause a marginal increase in the total utilization; however, 3385 this will typically be an extremely small increase. 3387 Congestion due to the gathering and check phases has proven to be a 3388 problem in deployments that did not utilize pacing. Typically, 3389 access links became congested as the endpoints flooded the network 3390 with checks as fast as they can send them. Consequently, network 3391 operators should make sure that their ICE implementations support the 3392 pacing feature. Though this pacing does increase call setup times, 3393 it makes ICE network friendly and easier to deploy. 3395 17.2.3. Keepalives 3397 STUN keepalives (in the form of STUN Binding Indications) are sent in 3398 the middle of a media session. However, they are sent only in the 3399 absence of actual media traffic. In deployments that are not 3400 utilizing Voice Activity Detection (VAD), the keepalives are never 3401 used and there is no increase in bandwidth usage. When VAD is being 3402 used, keepalives will be sent during silence periods. This involves 3403 a single packet every 15-20 seconds, far less than the packet every 3404 20-30 ms that is sent when there is voice. Therefore, keepalives 3405 don't have any real impact on capacity planning. 3407 17.3. ICE and ICE-lite 3409 Deployments utilizing a mix of ICE and ICE-lite interoperate 3410 perfectly. They have been explicitly designed to do so, without loss 3411 of function. 3413 However, ICE-lite can only be deployed in limited use cases. Those 3414 cases, and the caveats involved in doing so, are documented in 3415 Appendix A. 3417 17.4. Troubleshooting and Performance Management 3419 ICE utilizes end-to-end connectivity checks, and places much of the 3420 processing in the endpoints. This introduces a challenge to the 3421 network operator -- how can they troubleshoot ICE deployments? How 3422 can they know how ICE is performing? 3424 ICE has built-in features to help deal with these problems. SIP 3425 servers on the signaling path, typically deployed in the data centers 3426 of the network operator, will see the contents of the offer/answer 3427 exchanges that convey the ICE parameters. These parameters include 3428 the type of each candidate (host, server reflexive, or relayed), 3429 along with their related addresses. Once ICE processing has 3430 completed, an updated offer/answer exchange takes place, signaling 3431 the selected address (and its type). This updated re-INVITE is 3432 performed exactly for the purposes of educating network equipment 3433 (such as a diagnostic tool attached to a SIP server) about the 3434 results of ICE processing. 3436 As a consequence, through the logs generated by the SIP server, a 3437 network operator can observe what types of candidates are being used 3438 for each call, and what address was selected by ICE. This is the 3439 primary information that helps evaluate how ICE is performing. 3441 17.5. Endpoint Configuration 3443 ICE relies on several pieces of data being configured into the 3444 endpoints. This configuration data includes timers, credentials for 3445 TURN servers, and hostnames for STUN and TURN servers. ICE itself 3446 does not provide a mechanism for this configuration. Instead, it is 3447 assumed that this information is attached to whatever mechanism is 3448 used to configure all of the other parameters in the endpoint. For 3449 SIP phones, standard solutions such as the configuration framework 3450 [RFC6080] have been defined. 3452 18. IANA Considerations 3454 The original ICE specification registered four new STUN attributes, 3455 and one new STUN error response. The STUN attributes and error 3456 response are reproduced here. 3458 18.1. STUN Attributes 3460 IANA has registered four STUN attributes: 3462 0x0024 PRIORITY 3463 0x0025 USE-CANDIDATE 3464 0x8029 ICE-CONTROLLED 3465 0x802A ICE-CONTROLLING 3467 18.2. STUN Error Responses 3469 IANA has registered following STUN error response code: 3471 487 Role Conflict: The client asserted an ICE role (controlling or 3472 controlled) that is in conflict with the role of the server. 3474 19. IAB Considerations 3476 The IAB has studied the problem of "Unilateral Self-Address Fixing", 3477 which is the general process by which a agent attempts to determine 3478 its address in another realm on the other side of a NAT through a 3479 collaborative protocol reflection mechanism [RFC3424]. ICE is an 3480 example of a protocol that performs this type of function. 3481 Interestingly, the process for ICE is not unilateral, but bilateral, 3482 and the difference has a significant impact on the issues raised by 3483 IAB. Indeed, ICE can be considered a B-SAF (Bilateral Self-Address 3484 Fixing) protocol, rather than an UNSAF protocol. Regardless, the IAB 3485 has mandated that any protocols developed for this purpose document a 3486 specific set of considerations. This section meets those 3487 requirements. 3489 19.1. Problem Definition 3491 >From RFC 3424, any UNSAF proposal must provide: 3493 Precise definition of a specific, limited-scope problem that is to 3494 be solved with the UNSAF proposal. A short-term fix should not be 3495 generalized to solve other problems; this is why "short-term fixes 3496 usually aren't". 3498 The specific problems being solved by ICE are: 3500 Provide a means for two peers to determine the set of transport 3501 addresses that can be used for communication. 3503 Provide a means for a agent to determine an address that is 3504 reachable by another peer with which it wishes to communicate. 3506 19.2. Exit Strategy 3508 >From RFC 3424, any UNSAF proposal must provide: 3510 Description of an exit strategy/transition plan. The better 3511 short-term fixes are the ones that will naturally see less and 3512 less use as the appropriate technology is deployed. 3514 ICE itself doesn't easily get phased out. However, it is useful even 3515 in a globally connected Internet, to serve as a means for detecting 3516 whether a router failure has temporarily disrupted connectivity, for 3517 example. ICE also helps prevent certain security attacks that have 3518 nothing to do with NAT. However, what ICE does is help phase out 3519 other UNSAF mechanisms. ICE effectively selects amongst those 3520 mechanisms, prioritizing ones that are better, and deprioritizing 3521 ones that are worse. Local IPv6 addresses can be preferred. As NATs 3522 begin to dissipate as IPv6 is introduced, server reflexive and 3523 relayed candidates (both forms of UNSAF addresses) simply never get 3524 used, because higher-priority connectivity exists to the native host 3525 candidates. Therefore, the servers get used less and less, and can 3526 eventually be remove when their usage goes to zero. 3528 Indeed, ICE can assist in the transition from IPv4 to IPv6. It can 3529 be used to determine whether to use IPv6 or IPv4 when two dual-stack 3530 hosts communicate with SIP (IPv6 gets used). It can also allow a 3531 network with both 6to4 and native v6 connectivity to determine which 3532 address to use when communicating with a peer. 3534 19.3. Brittleness Introduced by ICE 3536 >From RFC 3424, any UNSAF proposal must provide: 3538 Discussion of specific issues that may render systems more 3539 "brittle". For example, approaches that involve using data at 3540 multiple network layers create more dependencies, increase 3541 debugging challenges, and make it harder to transition. 3543 ICE actually removes brittleness from existing UNSAF mechanisms. In 3544 particular, classic STUN (as described in RFC 3489 [RFC3489]) has 3545 several points of brittleness. One of them is the discovery process 3546 that requires an agent to try to classify the type of NAT it is 3547 behind. This process is error-prone. With ICE, that discovery 3548 process is simply not used. Rather than unilaterally assessing the 3549 validity of the address, its validity is dynamically determined by 3550 measuring connectivity to a peer. The process of determining 3551 connectivity is very robust. 3553 Another point of brittleness in classic STUN and any other unilateral 3554 mechanism is its absolute reliance on an additional server. ICE 3555 makes use of a server for allocating unilateral addresses, but allows 3556 agents to directly connect if possible. Therefore, in some cases, 3557 the failure of a STUN server would still allow for a call to progress 3558 when ICE is used. 3560 Another point of brittleness in classic STUN is that it assumes that 3561 the STUN server is on the public Internet. Interestingly, with ICE, 3562 that is not necessary. There can be a multitude of STUN servers in a 3563 variety of address realms. ICE will discover the one that has 3564 provided a usable address. 3566 The most troubling point of brittleness in classic STUN is that it 3567 doesn't work in all network topologies. In cases where there is a 3568 shared NAT between each agent and the STUN server, traditional STUN 3569 may not work. With ICE, that restriction is removed. 3571 Classic STUN also introduces some security considerations. 3572 Fortunately, those security considerations are also mitigated by ICE. 3574 Consequently, ICE serves to repair the brittleness introduced in 3575 classic STUN, and does not introduce any additional brittleness into 3576 the system. 3578 The penalty of these improvements is that ICE increases session 3579 establishment times. 3581 19.4. Requirements for a Long-Term Solution 3583 From RFC 3424, any UNSAF proposal must provide: 3585 ... requirements for longer term, sound technical solutions -- 3586 contribute to the process of finding the right longer term 3587 solution. 3589 Our conclusions from RFC 3489 remain unchanged. However, we feel ICE 3590 actually helps because we believe it can be part of the long-term 3591 solution. 3593 19.5. Issues with Existing NAPT Boxes 3595 From RFC 3424, any UNSAF proposal must provide: 3597 Discussion of the impact of the noted practical issues with 3598 existing, deployed NA[P]Ts and experience reports. 3600 A number of NAT boxes are now being deployed into the market that try 3601 to provide "generic" ALG functionality. These generic ALGs hunt for 3602 IP addresses, either in text or binary form within a packet, and 3603 rewrite them if they match a binding. This interferes with classic 3604 STUN. However, the update to STUN [RFC5389] uses an encoding that 3605 hides these binary addresses from generic ALGs. 3607 Existing NAPT boxes have non-deterministic and typically short 3608 expiration times for UDP-based bindings. This requires 3609 implementations to send periodic keepalives to maintain those 3610 bindings. ICE uses a default of 15 s, which is a very conservative 3611 estimate. Eventually, over time, as NAT boxes become compliant to 3612 behave [RFC4787], this minimum keepalive will become deterministic 3613 and well-known, and the ICE timers can be adjusted. Having a way to 3614 discover and control the minimum keepalive interval would be far 3615 better still. 3617 20. Changes from RFC 5245 3619 Following is the list of changes from RFC 5245 3621 o The specification was generalized to be more usable with any 3622 protocol and the parts that are specific to SIP and SDP were moved 3623 to a SIP/SDP usage document [I-D.ietf-mmusic-ice-sip-sdp]. 3625 o Default candidates, multiple components, ICE mismatch detection, 3626 subsequent offer/answer, and role conflict resolution were made 3627 optional since they are not needed with every protocol using ICE. 3629 o With IPv6, the precedence rules of RFC 6724 are used instead of 3630 the obsoleted RFC 3483 and using address preferences provided by 3631 the host operating system is recommended. 3633 o Candidate gathering rules regarding loopback addresses and IPv6 3634 addresses were clarified. 3636 21. Acknowledgements 3638 Most of the text in this document comes from the original ICE 3639 specification, RFC 5245. The authors would like to thank everyone 3640 who has contributed to that document. For additional contributions 3641 to this revision of the specification we would like to thank Christer 3642 Holmberg, Emil Ivov, Paul Kyzivat, Pal-Erik Martinsen, Simon 3643 Perrault, Eric Rescorla, Thomas Stach, Peter Thatcher, Martin 3644 Thomson, and Justin Uberti. 3646 22. References 3648 22.1. Normative References 3650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3651 Requirement Levels", BCP 14, RFC 2119, March 1997. 3653 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3654 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3655 October 2008. 3657 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 3658 Relays around NAT (TURN): Relay Extensions to Session 3659 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 3661 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 3662 "Default Address Selection for Internet Protocol Version 6 3663 (IPv6)", RFC 6724, September 2012. 3665 22.2. Informative References 3667 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 3668 in Session Description Protocol (SDP)", RFC 3605, October 3669 2003. 3671 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3672 A., Peterson, J., Sparks, R., Handley, M., and E. 3673 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3674 June 2002. 3676 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 3677 with Session Description Protocol (SDP)", RFC 3264, June 3678 2002. 3680 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 3681 "STUN - Simple Traversal of User Datagram Protocol (UDP) 3682 Through Network Address Translators (NATs)", RFC 3489, 3683 March 2003. 3685 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 3686 Application Design Guidelines", RFC 3235, January 2002. 3688 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 3689 A. Rayhan, "Middlebox communication architecture and 3690 framework", RFC 3303, August 2002. 3692 [RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, 3693 "Realm Specific IP: Framework", RFC 3102, October 2001. 3695 [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, 3696 "Realm Specific IP: Protocol Specification", RFC 3103, 3697 October 2001. 3699 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 3700 Self-Address Fixing (UNSAF) Across Network Address 3701 Translation", RFC 3424, November 2002. 3703 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3704 Jacobson, "RTP: A Transport Protocol for Real-Time 3705 Applications", STD 64, RFC 3550, July 2003. 3707 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3708 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 3709 RFC 3711, March 2004. 3711 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 3712 via IPv4 Clouds", RFC 3056, February 2001. 3714 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 3715 Comfort Noise (CN)", RFC 3389, September 2002. 3717 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 3718 Addresses", RFC 3879, September 2004. 3720 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 3721 Castro, "Application Aspects of IPv6 Transition", RFC 3722 4038, March 2005. 3724 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 3725 Address Types (ANAT) Semantics for the Session Description 3726 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 3728 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 3729 Description Protocol (SDP) Alternative Network Address 3730 Types (ANAT) Semantics in the Session Initiation Protocol 3731 (SIP)", RFC 4092, June 2005. 3733 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3734 Architecture", RFC 4291, February 2006. 3736 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3737 Description Protocol", RFC 4566, July 2006. 3739 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3740 and W. Weiss, "An Architecture for Differentiated 3741 Services", RFC 2475, December 1998. 3743 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3744 E. Lear, "Address Allocation for Private Internets", BCP 3745 5, RFC 1918, February 1996. 3747 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3748 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3749 RFC 4787, January 2007. 3751 [I-D.ietf-avt-rtp-no-op] 3752 Andreasen, F., "A No-Op Payload Format for RTP", draft- 3753 ietf-avt-rtp-no-op-04 (work in progress), May 2007. 3755 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 3756 Control Packets on a Single Port", RFC 5761, April 2010. 3758 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 3759 Conversation", RFC 4103, June 2005. 3761 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 3762 (ICE): A Protocol for Network Address Translator (NAT) 3763 Traversal for Offer/Answer Protocols", RFC 5245, April 3764 2010. 3766 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 3767 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 3768 RFC 5382, October 2008. 3770 [RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session 3771 Initiation Protocol User Agent Profile Delivery", RFC 3772 6080, March 2011. 3774 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 3775 "TCP Candidates with Interactive Connectivity 3776 Establishment (ICE)", RFC 6544, March 2012. 3778 [I-D.ietf-mmusic-ice-sip-sdp] 3779 Petit-Huguenin, M. and A. Keranen, "Using Interactive 3780 Connectivity Establishment (ICE) with Session Description 3781 Protocol (SDP) offer/answer and Session Initiation 3782 Protocol (SIP)", draft-ietf-mmusic-ice-sip-sdp-04 (work in 3783 progress), October 2014. 3785 [I-D.ietf-6man-ipv6-address-generation-privacy] 3786 Cooper, A., Gont, F., and D. Thaler, "Privacy 3787 Considerations for IPv6 Address Generation Mechanisms", 3788 draft-ietf-6man-ipv6-address-generation-privacy-04 (work 3789 in progress), February 2015. 3791 Appendix A. Lite and Full Implementations 3793 ICE allows for two types of implementations. A full implementation 3794 supports the controlling and controlled roles in a session, and can 3795 also perform address gathering. In contrast, a lite implementation 3796 is a minimalist implementation that does little but respond to STUN 3797 checks. 3799 Because ICE requires both endpoints to support it in order to bring 3800 benefits to either endpoint, incremental deployment of ICE in a 3801 network is more complicated. Many sessions involve an endpoint that 3802 is, by itself, not behind a NAT and not one that would worry about 3803 NAT traversal. A very common case is to have one endpoint that 3804 requires NAT traversal (such as a VoIP hard phone or soft phone) make 3805 a call to one of these devices. Even if the phone supports a full 3806 ICE implementation, ICE won't be used at all if the other device 3807 doesn't support it. The lite implementation allows for a low-cost 3808 entry point for these devices. Once they support the lite 3809 implementation, full implementations can connect to them and get the 3810 full benefits of ICE. 3812 Consequently, a lite implementation is only appropriate for devices 3813 that will *always* be connected to the public Internet and have a 3814 public IP address at which it can receive packets from any 3815 correspondent. ICE will not function when a lite implementation is 3816 placed behind a NAT. 3818 ICE allows a lite implementation to have a single IPv4 host candidate 3819 and several IPv6 addresses. In that case, candidate pairs are 3820 selected by the controlling agent using a static algorithm, such as 3821 the one in RFC 6724, which is recommended by this specification. 3822 However, static mechanisms for address selection are always prone to 3823 error, since they cannot ever reflect the actual topology and can 3824 never provide actual guarantees on connectivity. They are always 3825 heuristics. Consequently, if an agent is implementing ICE just to 3826 select between its IPv4 and IPv6 addresses, and none of its IP 3827 addresses are behind NAT, usage of full ICE is still RECOMMENDED in 3828 order to provide the most robust form of address selection possible. 3830 It is important to note that the lite implementation was added to 3831 this specification to provide a stepping stone to full 3832 implementation. Even for devices that are always connected to the 3833 public Internet with just a single IPv4 address, a full 3834 implementation is preferable if achievable. A full implementation 3835 will reduce call setup times, since ICE's aggressive mode can be 3836 used. Full implementations also obtain the security benefits of ICE 3837 unrelated to NAT traversal; in particular, the voice hammer attack 3838 described in Section 15 is prevented only for full implementations, 3839 not lite. Finally, it is often the case that a device that finds 3840 itself with a public address today will be placed in a network 3841 tomorrow where it will be behind a NAT. It is difficult to 3842 definitively know, over the lifetime of a device or product, that it 3843 will always be used on the public Internet. Full implementation 3844 provides assurance that communications will always work. 3846 Appendix B. Design Motivations 3848 ICE contains a number of normative behaviors that may themselves be 3849 simple, but derive from complicated or non-obvious thinking or use 3850 cases that merit further discussion. Since these design motivations 3851 are not necessary to understand for purposes of implementation, they 3852 are discussed here in an appendix to the specification. This section 3853 is non-normative. 3855 B.1. Pacing of STUN Transactions 3857 STUN transactions used to gather candidates and to verify 3858 connectivity are paced out at an approximate rate of one new 3859 transaction every Ta milliseconds. Each transaction, in turn, has a 3860 retransmission timer RTO that is a function of Ta as well. Why are 3861 these transactions paced, and why are these formulas used? 3863 Sending of these STUN requests will often have the effect of creating 3864 bindings on NAT devices between the client and the STUN servers. 3865 Experience has shown that many NAT devices have upper limits on the 3866 rate at which they will create new bindings. Experiments have shown 3867 that once every 20 ms is well supported, but not much lower than 3868 that. This is why Ta has a lower bound of 20 ms. Furthermore, 3869 transmission of these packets on the network makes use of bandwidth 3870 and needs to be rate limited by the agent. Deployments based on 3871 earlier draft versions of [RFC5245] tended to overload rate- 3872 constrained access links and perform poorly overall, in addition to 3873 negatively impacting the network. As a consequence, the pacing 3874 ensures that the NAT device does not get overloaded and that traffic 3875 is kept at a reasonable rate. 3877 The definition of a "reasonable" rate is that STUN should not use 3878 more bandwidth than the RTP itself will use, once media starts 3879 flowing. The formula for Ta is designed so that, if a STUN packet 3880 were sent every Ta seconds, it would consume the same amount of 3881 bandwidth as RTP packets, summed across all media streams. Of 3882 course, STUN has retransmits, and the desire is to pace those as 3883 well. For this reason, RTO is set such that the first retransmit on 3884 the first transaction happens just as the first STUN request on the 3885 last transaction occurs. Pictorially: 3887 First Packets Retransmits 3889 | | 3890 | | 3891 -------+------ -------+------ 3892 / \ / \ 3893 / \ / \ 3895 +--+ +--+ +--+ +--+ +--+ +--+ 3896 |A1| |B1| |C1| |A2| |B2| |C2| 3897 +--+ +--+ +--+ +--+ +--+ +--+ 3899 ---+-------+-------+-------+-------+-------+------------ Time 3900 0 Ta 2Ta 3Ta 4Ta 5Ta 3902 In this picture, there are three transactions that will be sent (for 3903 example, in the case of candidate gathering, there are three host 3904 candidate/STUN server pairs). These are transactions A, B, and C. 3905 The retransmit timer is set so that the first retransmission on the 3906 first transaction (packet A2) is sent at time 3Ta. 3908 Subsequent retransmits after the first will occur even less 3909 frequently than Ta milliseconds apart, since STUN uses an exponential 3910 back-off on its retransmissions. 3912 B.2. Candidates with Multiple Bases 3914 Section 4.1.3 talks about eliminating candidates that have the same 3915 transport address and base. However, candidates with the same 3916 transport addresses but different bases are not redundant. When can 3917 an agent have two candidates that have the same IP address and port, 3918 but different bases? Consider the topology of Figure 10: 3920 +----------+ 3921 | STUN Srvr| 3922 +----------+ 3923 | 3924 | 3925 ----- 3926 // \\ 3927 | | 3928 | B:net10 | 3929 | | 3930 \\ // 3931 ----- 3932 | 3933 | 3934 +----------+ 3935 | NAT | 3936 +----------+ 3937 | 3938 | 3939 ----- 3940 // \\ 3941 | A | 3942 |192.168/16 | 3943 | | 3944 \\ // 3945 ----- 3946 | 3947 | 3948 |192.168.1.100 ----- 3949 +----------+ // \\ +----------+ 3950 | | | | | | 3951 | Offerer |---------| C:net10 |-----------| Answerer | 3952 | |10.0.1.100| | 10.0.1.101 | | 3953 +----------+ \\ // +----------+ 3954 ----- 3956 Figure 10: Identical Candidates with Different Bases 3958 In this case, the offerer is multihomed. It has one IP address, 3959 10.0.1.100, on network C, which is a net 10 private network. The 3960 answerer is on this same network. The offerer is also connected to 3961 network A, which is 192.168/16. The offerer has an IP address of 3962 192.168.1.100 on this network. There is a NAT on this network, 3963 natting into network B, which is another net 10 private network, but 3964 not connected to network C. There is a STUN server on network B. 3966 The offerer obtains a host candidate on its IP address on network C 3967 (10.0.1.100:2498) and a host candidate on its IP address on network A 3968 (192.168.1.100:3344). It performs a STUN query to its configured 3969 STUN server from 192.168.1.100:3344. This query passes through the 3970 NAT, which happens to assign the binding 10.0.1.100:2498. The STUN 3971 server reflects this in the STUN Binding response. Now, the offerer 3972 has obtained a server reflexive candidate with a transport address 3973 that is identical to a host candidate (10.0.1.100:2498). However, 3974 the server reflexive candidate has a base of 192.168.1.100:3344, and 3975 the host candidate has a base of 10.0.1.100:2498. 3977 B.3. Purpose of the Related Address and Related Port Attributes 3979 The candidate attribute contains two values that are not used at all 3980 by ICE itself -- related address and related port. Why are they 3981 present? 3983 There are two motivations for its inclusion. The first is 3984 diagnostic. It is very useful to know the relationship between the 3985 different types of candidates. By including it, an agent can know 3986 which relayed candidate is associated with which reflexive candidate, 3987 which in turn is associated with a specific host candidate. When 3988 checks for one candidate succeed and not for others, this provides 3989 useful diagnostics on what is going on in the network. 3991 The second reason has to do with off-path Quality of Service (QoS) 3992 mechanisms. When ICE is used in environments such as PacketCable 3993 2.0, proxies will, in addition to performing normal SIP operations, 3994 inspect the SDP in SIP messages, and extract the IP address and port 3995 for media traffic. They can then interact, through policy servers, 3996 with access routers in the network, to establish guaranteed QoS for 3997 the media flows. This QoS is provided by classifying the RTP traffic 3998 based on 5-tuple, and then providing it a guaranteed rate, or marking 3999 its Diffserv codepoints appropriately. When a residential NAT is 4000 present, and a relayed candidate gets selected for media, this 4001 relayed candidate will be a transport address on an actual TURN 4002 server. That address says nothing about the actual transport address 4003 in the access router that would be used to classify packets for QoS 4004 treatment. Rather, the server reflexive candidate towards the TURN 4005 server is needed. By carrying the translation in the SDP, the proxy 4006 can use that transport address to request QoS from the access router. 4008 B.4. Importance of the STUN Username 4010 ICE requires the usage of message integrity with STUN using its 4011 short-term credential functionality. The actual short-term 4012 credential is formed by exchanging username fragments in the offer/ 4013 answer exchange. The need for this mechanism goes beyond just 4014 security; it is actually required for correct operation of ICE in the 4015 first place. 4017 Consider agents L, R, and Z. L and R are within private enterprise 4018 1, which is using 10.0.0.0/8. Z is within private enterprise 2, 4019 which is also using 10.0.0.0/8. As it turns out, R and Z both have 4020 IP address 10.0.1.1. L sends an offer to Z. Z, in its answer, 4021 provides L with its host candidates. In this case, those candidates 4022 are 10.0.1.1:8866 and 10.0.1.1:8877. As it turns out, R is in a 4023 session at that same time, and is also using 10.0.1.1:8866 and 4024 10.0.1.1:8877 as host candidates. This means that R is prepared to 4025 accept STUN messages on those ports, just as Z is. L will send a 4026 STUN request to 10.0.1.1:8866 and another to 10.0.1.1:8877. However, 4027 these do not go to Z as expected. Instead, they go to R! If R just 4028 replied to them, L would believe it has connectivity to Z, when in 4029 fact it has connectivity to a completely different user, R. To fix 4030 this, the STUN short-term credential mechanisms are used. The 4031 username fragments are sufficiently random that it is highly unlikely 4032 that R would be using the same values as Z. Consequently, R would 4033 reject the STUN request since the credentials were invalid. In 4034 essence, the STUN username fragments provide a form of transient host 4035 identifiers, bound to a particular offer/answer session. 4037 An unfortunate consequence of the non-uniqueness of IP addresses is 4038 that, in the above example, R might not even be an ICE agent. It 4039 could be any host, and the port to which the STUN packet is directed 4040 could be any ephemeral port on that host. If there is an application 4041 listening on this socket for packets, and it is not prepared to 4042 handle malformed packets for whatever protocol is in use, the 4043 operation of that application could be affected. Fortunately, since 4044 the ports exchanged in offer/answer are ephemeral and usually drawn 4045 from the dynamic or registered range, the odds are good that the port 4046 is not used to run a server on host R, but rather is the agent side 4047 of some protocol. This decreases the probability of hitting an 4048 allocated port, due to the transient nature of port usage in this 4049 range. However, the possibility of a problem does exist, and network 4050 deployers should be prepared for it. Note that this is not a problem 4051 specific to ICE; stray packets can arrive at a port at any time for 4052 any type of protocol, especially ones on the public Internet. As 4053 such, this requirement is just restating a general design guideline 4054 for Internet applications -- be prepared for unknown packets on any 4055 port. 4057 B.5. The Candidate Pair Priority Formula 4059 The priority for a candidate pair has an odd form. It is: 4061 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 4063 Why is this? When the candidate pairs are sorted based on this 4064 value, the resulting sorting has the MAX/MIN property. This means 4065 that the pairs are first sorted based on decreasing value of the 4066 minimum of the two priorities. For pairs that have the same value of 4067 the minimum priority, the maximum priority is used to sort amongst 4068 them. If the max and the min priorities are the same, the 4069 controlling agent's priority is used as the tie-breaker in the last 4070 part of the expression. The factor of 2*32 is used since the 4071 priority of a single candidate is always less than 2*32, resulting in 4072 the pair priority being a "concatenation" of the two component 4073 priorities. This creates the MAX/MIN sorting. MAX/MIN ensures that, 4074 for a particular agent, a lower-priority candidate is never used 4075 until all higher-priority candidates have been tried. 4077 B.6. Why Are Keepalives Needed? 4079 Once media begins flowing on a candidate pair, it is still necessary 4080 to keep the bindings alive at intermediate NATs for the duration of 4081 the session. Normally, the media stream packets themselves (e.g., 4082 RTP) meet this objective. However, several cases merit further 4083 discussion. Firstly, in some RTP usages, such as SIP, the media 4084 streams can be "put on hold". This is accomplished by using the SDP 4085 "sendonly" or "inactive" attributes, as defined in RFC 3264 4086 [RFC3264]. RFC 3264 directs implementations to cease transmission of 4087 media in these cases. However, doing so may cause NAT bindings to 4088 timeout, and media won't be able to come off hold. 4090 Secondly, some RTP payload formats, such as the payload format for 4091 text conversation [RFC4103], may send packets so infrequently that 4092 the interval exceeds the NAT binding timeouts. 4094 Thirdly, if silence suppression is in use, long periods of silence 4095 may cause media transmission to cease sufficiently long for NAT 4096 bindings to time out. 4098 For these reasons, the media packets themselves cannot be relied 4099 upon. ICE defines a simple periodic keepalive utilizing STUN Binding 4100 indications. This makes its bandwidth requirements highly 4101 predictable, and thus amenable to QoS reservations. 4103 B.7. Why Prefer Peer Reflexive Candidates? 4105 Section 4.1.2 describes procedures for computing the priority of 4106 candidate based on its type and local preferences. That section 4107 requires that the type preference for peer reflexive candidates 4108 always be higher than server reflexive. Why is that? The reason has 4109 to do with the security considerations in Section 15. It is much 4110 easier for an attacker to cause an agent to use a false server 4111 reflexive candidate than it is for an attacker to cause an agent to 4112 use a false peer reflexive candidate. Consequently, attacks against 4113 address gathering with Binding requests are thwarted by ICE by 4114 preferring the peer reflexive candidates. 4116 B.8. Why Are Binding Indications Used for Keepalives? 4118 Media keepalives are described in Section 10. These keepalives make 4119 use of STUN when both endpoints are ICE capable. However, rather 4120 than using a Binding request transaction (which generates a 4121 response), the keepalives use an Indication. Why is that? 4123 The primary reason has to do with network QoS mechanisms. Once media 4124 begins flowing, network elements will assume that the media stream 4125 has a fairly regular structure, making use of periodic packets at 4126 fixed intervals, with the possibility of jitter. If an agent is 4127 sending media packets, and then receives a Binding request, it would 4128 need to generate a response packet along with its media packets. 4129 This will increase the actual bandwidth requirements for the 5-tuple 4130 carrying the media packets, and introduce jitter in the delivery of 4131 those packets. Analysis has shown that this is a concern in certain 4132 layer 2 access networks that use fairly tight packet schedulers for 4133 media. 4135 Additionally, using a Binding Indication allows integrity to be 4136 disabled, allowing for better performance. This is useful for large- 4137 scale endpoints, such as PSTN gateways and SBCs. 4139 Authors' Addresses 4141 Ari Keranen 4142 Ericsson 4143 Hirsalantie 11 4144 02420 Jorvas 4145 Finland 4147 Email: ari.keranen@ericsson.com 4149 Jonathan Rosenberg 4150 jdrosen.net 4151 Monmouth, NJ 4152 US 4154 Email: jdrosen@jdrosen.net 4155 URI: http://www.jdrosen.net