idnits 2.17.1 draft-ietf-mmusic-ice-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 5048. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5059. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5066. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5072. 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 20 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? -- The draft header indicates that this document obsoletes RFC4091, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 2007) is 6163 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 4234 (ref. '8') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (ref. '10') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4091 (ref. '11') (Obsoleted by RFC 5245) ** Obsolete normative reference: RFC 3484 (ref. '12') (Obsoleted by RFC 6724) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-02 == Outdated reference: A later version (-02) exists of draft-ietf-sip-ice-option-tag-00 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '16') (Obsoleted by RFC 5389) == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-connectivity-precon-02 == Outdated reference: A later version (-04) exists of draft-ietf-avt-rtp-no-op-00 == Outdated reference: A later version (-07) exists of draft-ietf-avt-rtp-and-rtcp-mux-03 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-07 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Rosenberg 3 Internet-Draft Cisco 4 Obsoletes: 4091 (if approved) June 12, 2007 5 Intended status: Standards Track 6 Expires: December 14, 2007 8 Interactive Connectivity Establishment (ICE): A Protocol for Network 9 Address Translator (NAT) Traversal for Offer/Answer Protocols 10 draft-ietf-mmusic-ice-16 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 14, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes a protocol for Network Address Translator 44 (NAT) traversal for multimedia sessions established with the offer/ 45 answer model. This protocol is called Interactive Connectivity 46 Establishment (ICE). ICE makes use of the Session Traversal 47 Utilities for NAT (STUN) protocol, applying its binding discovery and 48 relay usages, in addition to defining a new usage for checking 49 connectivity between peers. ICE can be used by any protocol 50 utilizing the offer/answer model, such as the Session Initiation 51 Protocol (SIP). 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 56 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 8 57 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 10 58 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 12 59 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 13 60 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 14 61 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 15 62 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 15 63 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 17 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17 65 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 20 66 4.1. Full Implementation Requirements . . . . . . . . . . . . 20 67 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 20 68 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 21 69 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 21 70 4.1.1.3. Eliminating Redundant Candidates . . . . . . . . 23 71 4.1.1.4. Computing Foundations . . . . . . . . . . . . . . 23 72 4.1.1.5. Keeping Candidates Alive . . . . . . . . . . . . 23 73 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 24 74 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 24 75 4.1.2.2. Guidelines for Choosing Type and Local 76 Preferences . . . . . . . . . . . . . . . . . . . 25 77 4.1.3. Choosing Default Candidates . . . . . . . . . . . . . 26 78 4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 26 79 4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 27 80 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 29 81 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 29 82 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 30 83 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 31 84 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 31 85 5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 31 86 5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 31 87 5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 32 88 5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 32 89 5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 34 90 5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 34 91 5.7.4. Computing States . . . . . . . . . . . . . . . . . . 34 92 5.8. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 37 93 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 39 94 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 39 95 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 40 96 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 40 97 6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 40 98 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 40 99 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 40 100 7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 40 101 7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 41 102 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 41 103 7.1.1.3. FINGERPRINT . . . . . . . . . . . . . . . . . . . 41 104 7.1.1.4. Forming Credentials . . . . . . . . . . . . . . . 41 105 7.1.1.5. DiffServ Treatment . . . . . . . . . . . . . . . 42 106 7.1.2. Processing the Response . . . . . . . . . . . . . . . 42 107 7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 42 108 7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 43 109 7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 43 110 7.1.2.2.2. Constructing a Valid Pair . . . . . . . . . . 44 111 7.1.2.2.3. Updating Pair States . . . . . . . . . . . . 44 112 7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 45 113 7.1.2.3. Check List and Timer State Updates . . . . . . . 46 114 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 46 115 7.2.1. Additional Procedures for Full Implementations . . . 47 116 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 47 117 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 48 118 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 48 119 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 49 120 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 50 121 7.2.2. Additional Procedures for Lite Implementations . . . 51 122 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 51 123 8.1. Procedures for Full Implementations . . . . . . . . . . . 51 124 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 51 125 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 51 126 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 52 127 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 52 128 8.2. Procedures for Lite Implementations . . . . . . . . . . . 54 129 8.2.1. Peer is Full . . . . . . . . . . . . . . . . . . . . 54 130 8.2.2. Peer is Lite . . . . . . . . . . . . . . . . . . . . 54 131 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 55 132 8.3.1. Full Implementation Procedures . . . . . . . . . . . 55 133 8.3.2. Lite Implementations . . . . . . . . . . . . . . . . 56 134 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 56 135 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 56 136 9.1.1. Procedures for All Implementations . . . . . . . . . 56 137 9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 56 138 9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 57 139 9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 57 140 9.1.2. Procedures for Full Implementations . . . . . . . . . 57 141 9.1.2.1. Existing Media Streams with ICE Running . . . . . 57 142 9.1.2.2. Existing Media Streams with ICE Completed . . . . 58 143 9.1.3. Procedures for Lite Implementations . . . . . . . . . 58 144 9.1.3.1. Existing Media Streams with ICE Running . . . . . 59 145 9.1.3.2. Existing Media Streams with ICE Completed . . . . 59 146 9.2. Receiving the Offer and Generating an Answer . . . . . . 59 147 9.2.1. Procedures for All Implementations . . . . . . . . . 59 148 9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 60 149 9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 60 150 9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 60 151 9.2.2. Procedures for Full Implementations . . . . . . . . . 60 152 9.2.2.1. Existing Media Streams with ICE Running and no 153 remote-candidates . . . . . . . . . . . . . . . . 61 154 9.2.2.2. Existing Media Streams with ICE Completed and 155 no remote-candidates . . . . . . . . . . . . . . 61 156 9.2.2.3. Existing Media Streams and remote-candidates . . 61 157 9.2.3. Procedures for Lite Implementations . . . . . . . . . 62 158 9.3. Updating the Check and Valid Lists . . . . . . . . . . . 63 159 9.3.1. Procedures for Full Implementations . . . . . . . . . 63 160 9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 63 161 9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 63 162 9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 63 163 9.3.1.4. ICE Continuing for Existing Media Stream . . . . 63 164 9.3.2. Procedures for Lite Implementations . . . . . . . . . 64 165 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 64 166 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 65 167 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 65 168 11.1.1. Procedures for Full Implementations . . . . . . . . . 65 169 11.1.2. Procedures for Lite Implementations . . . . . . . . . 66 170 11.1.3. Procedures for All Implementations . . . . . . . . . 66 171 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 67 172 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 67 173 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 67 174 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 67 175 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 69 176 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 69 177 12.3. Interactions with Forking . . . . . . . . . . . . . . . . 69 178 12.4. Interactions with Preconditions . . . . . . . . . . . . . 70 179 12.5. Interactions with Third Party Call Control . . . . . . . 70 180 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 71 181 14. Extensibility Considerations . . . . . . . . . . . . . . . . 71 182 15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 183 15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 72 184 15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 74 185 15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 75 186 15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 75 187 15.5. "ice-options" Attribute . . . . . . . . . . . . . . . . . 76 188 16. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 189 17. Security Considerations . . . . . . . . . . . . . . . . . . . 83 190 17.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 83 191 17.2. Attacks on Address Gathering . . . . . . . . . . . . . . 85 192 17.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 86 193 17.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 86 194 17.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 87 195 17.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 87 196 17.5. Interactions with Application Layer Gateways and SIP . . 88 197 18. Definition of Connectivity Check Usage . . . . . . . . . . . 89 198 18.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 89 199 18.2. Client Discovery of Server . . . . . . . . . . . . . . . 89 200 18.3. Server Determination of Usage . . . . . . . . . . . . . . 89 201 18.4. New Requests or Indications . . . . . . . . . . . . . . . 89 202 18.5. New Attributes . . . . . . . . . . . . . . . . . . . . . 90 203 18.6. New Error Response Codes . . . . . . . . . . . . . . . . 90 204 18.7. Client Procedures . . . . . . . . . . . . . . . . . . . . 90 205 18.8. Server Procedures . . . . . . . . . . . . . . . . . . . . 90 206 18.9. Security Considerations for Connectivity Check . . . . . 91 207 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91 208 19.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 91 209 19.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 91 210 19.1.2. remote-candidates Attribute . . . . . . . . . . . . . 91 211 19.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 92 212 19.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 92 213 19.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 93 214 19.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 93 215 19.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 94 216 19.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 94 217 19.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 94 218 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 94 219 20.1. Problem Definition . . . . . . . . . . . . . . . . . . . 95 220 20.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 95 221 20.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 96 222 20.4. Requirements for a Long Term Solution . . . . . . . . . . 97 223 20.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 97 224 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 98 225 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 98 226 22.1. Normative References . . . . . . . . . . . . . . . . . . 98 227 22.2. Informative References . . . . . . . . . . . . . . . . . 99 228 Appendix A. Lite and Full Implementations . . . . . . . . . . . 101 229 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 102 230 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 102 231 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 103 232 B.3. Purpose of the and Attributes . . . 105 233 B.4. Importance of the STUN Username . . . . . . . . . . . . . 105 234 B.5. The Candidate Pair Sequence Number Formula . . . . . . . 106 235 B.6. The remote-candidates attribute . . . . . . . . . . . . . 107 236 B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 108 237 B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 109 238 B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 109 239 B.10. Why are Binding Indications Used for Keepalives? . . . . 109 240 B.11. Why is the Conflict Resolution Mechanism Needed? . . . . 110 241 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 111 242 Intellectual Property and Copyright Statements . . . . . . . . . 112 244 1. Introduction 246 RFC 3264 [4] defines a two-phase exchange of Session Description 247 Protocol (SDP) messages [10] for the purposes of establishment of 248 multimedia sessions. This offer/answer mechanism is used by 249 protocols such as the Session Initiation Protocol (SIP) [3]. 251 Protocols using offer/answer are difficult to operate through Network 252 Address Translators (NAT). Because their purpose is to establish a 253 flow of media packets, they tend to carry the IP addresses and ports 254 of media sources and sinks within their messages, which is known to 255 be problematic through NAT [17]. The protocols also seek to create a 256 media flow directly between participants, so that there is no 257 application layer intermediary between them. This is done to reduce 258 media latency, decrease packet loss, and reduce the operational costs 259 of deploying the application. However, this is difficult to 260 accomplish through NAT. A full treatment of the reasons for this is 261 beyond the scope of this specification. 263 Numerous solutions have been proposed for allowing these protocols to 264 operate through NAT. These include Application Layer Gateways 265 (ALGs), the Middlebox Control Protocol [18], Simple Traversal 266 Underneath NAT (STUN) [16] and its revision, retitled Session 267 Traversal Utilities for NAT [13], the STUN Relay Usage [14], and 268 Realm Specific IP [20] [21] along with session description extensions 269 needed to make them work, such as the Session Description Protocol 270 (SDP) [10] attribute for the Real Time Control Protocol (RTCP) [2]. 271 Unfortunately, these techniques all have pros and cons which make 272 each one optimal in some network topologies, but a poor choice in 273 others. The result is that administrators and implementors are 274 making assumptions about the topologies of the networks in which 275 their solutions will be deployed. This introduces complexity and 276 brittleness into the system. What is needed is a single solution 277 which is flexible enough to work well in all situations. 279 This specification defines Interactive Connectivity Establishment 280 (ICE) as a technique for NAT traversal for media streams established 281 by the offer/answer model. ICE is an extension to the offer/answer 282 model, and works by including a multiplicity of IP addresses and 283 ports in SDP offers and answers, which are then tested for 284 connectivity by peer-to-peer STUN exchanges. The IP addresses and 285 ports included in the SDP are gathered using the STUN binding 286 acquisition techniques in [13] and relay allocation procedures in 287 [14] Because ICE exchanges a multiplicity of IP addresses and ports 288 for each media stream, it also allows for address selection for 289 multi-homed and dual-stack hosts, and for this reason it deprecates 290 RFC 4091 [11]. 292 2. Overview of ICE 294 In a typical ICE deployment, we have two endpoints (known as AGENTS 295 in RFC 3264 terminology) which want to communicate. They are able to 296 communicate indirectly via some signaling protocol (such as SIP), by 297 which they can perform an offer/answer exchange of SDP [4] messages. 298 Note that ICE is not intended for NAT traversal for SIP, which is 299 assumed to be provided via another mechanism [36]. At the beginning 300 of the ICE process, the agents are ignorant of their own topologies. 301 In particular, they might or might not be behind a NAT (or multiple 302 tiers of NATs). ICE allows the agents to discover enough information 303 about their topologies to potentially find one or more paths by which 304 they can communicate. 306 Figure 1 shows a typical environment for ICE deployment. The two 307 endpoints are labelled L and R (for left and right, which helps 308 visualize call flows). Both L and R are behind their own respective 309 NATs though they may not be aware of it. The type of NAT and its 310 properties are also unknown. Agents L and R are capable of engaging 311 in an offer/answer exchange by which they can exchange SDP messages, 312 whose purpose is to set up a media session between L and R. 313 Typically, this exchange will occur through a SIP server. 315 In addition to the agents, a SIP server and NATs, ICE is typically 316 used in concert with STUN servers in the network. Each agent can 317 have its own STUN server, or they can be the same. 319 +-------+ 320 | SIP | 321 +-------+ | Srvr | +-------+ 322 | STUN | | | | STUN | 323 | Srvr | +-------+ | Srvr | 324 | | / \ | | 325 +-------+ / \ +-------+ 326 / \ 327 / \ 328 / \ 329 / \ 330 / <- Signalling -> \ 331 / \ 332 / \ 333 +--------+ +--------+ 334 | NAT | | NAT | 335 +--------+ +--------+ 336 / \ 337 / \ 338 / \ 339 +-------+ +-------+ 340 | Agent | | Agent | 341 | L | | R | 342 | | | | 343 +-------+ +-------+ 345 Figure 1: ICE Deployment Scenario 347 The basic idea behind ICE is as follows: each agent has a variety of 348 candidate TRANSPORT ADDRESSES (combination of IP address and port) it 349 could use to communicate with the other agent. These might include: 351 o A transport address on a directly attached network interface 353 o A translated transport address on the public side of a NAT (a 354 "server reflexive" address) 356 o The transport address of a media relay the agent is using. 358 Potentially, any of L's candidate transport addresses can be used to 359 communicate with any of R's candidate transport addresses. In 360 practice, however, many combinations will not work. For instance, if 361 L and R are both behind NATs, their directly attached interface 362 addresses are unlikely to be able to communicate directly (this is 363 why ICE is needed, after all!). The purpose of ICE is to discover 364 which pairs of addresses will work. The way that ICE does this is to 365 systematically try all possible pairs (in a carefully sorted order) 366 until it finds one or more that works. 368 2.1. Gathering Candidate Addresses 370 In order to execute ICE, an agent has to identify all of its address 371 candidates. A CANDIDATE is a transport address - a combination of IP 372 address and port for a particular transport protocol. This document 373 defines three types of candidates, some derived from physical or 374 logical network interfaces, others discoverable via STUN. Naturally, 375 one viable candidate is a transport address obtained directly from a 376 local interface. Such a candidate is called a HOST CANDIDATE. The 377 local interface could be ethernet or WiFi, or it could be one that is 378 obtained through a tunnel mechanism, such as a Virtual Private 379 Network (VPN) or Mobile IP (MIP). In all cases, such a network 380 interface appears to the agent as a local interface from which ports 381 (and thus a candidate) can be allocated. 383 If an agent is multihomed, it obtains a candidate from each 384 interface. Depending on the location of the PEER (the other agent in 385 the session) on the IP network relative to the agent, the agent may 386 be reachable by the peer through one or more of those interfaces. 387 Consider, for example, an agent which has a local interface to a 388 private net 10 network (I1), and a second connected to the public 389 Internet (I2). A candidate from I1 will be directly reachable when 390 communicating with a peer on the same private net 10 network, while a 391 candidate from I2 will be directly reachable when communicating with 392 a peer on the public Internet. Rather than trying to guess which 393 interface will work prior to sending an offer, the offering agent 394 includes both candidates in its offer. 396 Next, the agent uses STUN to obtain additional candidates. These 397 come in two flavors: translated addresses on the public side of a NAT 398 (SERVER REFLEXIVE CANDIDATES) and addresses of media relays (RELAYED 399 CANDIDATES). The relationship of these candidates to the host 400 candidate is shown in Figure 2. Both types of candidates are 401 discovered using STUN. In the figure, the notation X:x means IP 402 address X and port x. 404 To Internet 406 | 407 | 408 | /------------ Relayed 409 Y:y | / Address 410 +--------+ 411 | | 412 | STUN | 413 | Server | 414 | | 415 +--------+ 416 | 417 | 418 | /------------ Server 419 X1':x1'|/ Reflexive 420 +------------+ Address 421 | NAT | 422 +------------+ 423 | 424 | /------------ Local 425 X:x |/ Address 426 +--------+ 427 | | 428 | Agent | 429 | | 430 +--------+ 432 Figure 2: Candidate Relationships 434 To find a server reflexive candidate, the agent sends a STUN Binding 435 Request, using the Binding Discovery Usage [13] from each host 436 candidate, to its STUN server. It is assumed that the address of the 437 STUN server is manually configured or learned in some unspecified 438 way. 440 When the agent sends the Binding Request from IP address and port 441 X:x, the NAT (assuming there is one) will allocate a binding X1':x1', 442 mapping this server reflexive candidate to the host candidate X:x. 443 Outgoing packets sent from the host candidate will be translated by 444 the NAT to the server reflexive candidate. Incoming packets sent to 445 the server relexive candidate will be translated by the NAT to the 446 host candidate and forwarded to the agent. We call the host 447 candidate associated with a given server reflexive candidate the 448 BASE. 450 NOTE: "Base" refers to the address an agent sends from for a 451 particular candidate. Thus, as a degenerate case host candidates 452 also have a base, but it's the same as the host candidate. 454 When there are multiple NATs between the agent and the STUN server, 455 the STUN request will create a binding on each NAT, but only the 456 outermost server reflexive candidate (the one nearest the STUN 457 server) will be discovered by the agent. If the agent is not behind 458 a NAT, then the base candidate will be the same as the server 459 reflexive candidate and the server reflexive candidate is redundant 460 and will be eliminated. 462 The final type of candidate is a RELAYED CANDIDATE. The STUN Relay 463 Usage [14] allows a STUN server to act as a media relay, forwarding 464 traffic between L and R. In order to send traffic to L, R sends 465 traffic to the media relay at Y:y, and the relay forwards that to 466 X1':x1', which passes through the NAT where it is mapped to X:x and 467 delivered to L. 469 2.2. Connectivity Checks 471 Once L has gathered all of its candidates, it orders them in highest 472 to lowest priority and sends them to R over the signalling channel. 473 The candidates are carried in attributes in the SDP offer. When R 474 receives the offer, it performs the same gathering process and 475 responds with its own list of candidates. At the end of this 476 process, each agent has a complete list of both its candidates and 477 its peer's candidates. It pairs them up, resulting in CANDIDATE 478 PAIRS. To see which pairs work, the agent schedules a series of 479 CHECKS. Each check is a STUN transaction that the client will 480 perform on a particular candidate pair by sending a STUN request from 481 the local candidate to the remote candidate. 483 The basic principle of the connectivity checks is simple: 485 1. Sort the candidate pairs in priority order. 487 2. Send checks on each candidate pair in priority order. 489 3. Acknowledge checks received from the other agent. 491 With both agents performing a check on a candidate pair, the result 492 is a 4-way handshake: 494 L R 495 - - 496 STUN request -> \ L's 497 <- STUN response / check 499 <- STUN request \ R's 500 STUN response -> / check 502 Figure 3: Basic Connectivity Check 504 It is important to note that the STUN requests are sent to and from 505 the exact same IP addresses and ports that will be used for media 506 (e.g., RTP and RTCP). Consequently, agents demultiplex STUN and RTP/ 507 RTCP using contents of the packets, rather than the port on which 508 they are received. Fortunately, this demultiplexing is easy to do, 509 especially for RTP and RTCP. 511 Because STUN is used for the connectivity check, the STUN response 512 will contain the agent's translated transport address on the public 513 side any NATs between the agent and its peer. If this transport 514 address is different from other candidates the agent already learned, 515 it represents a new candidate, called a PEER REFLEXIVE CANDIDATE, 516 which then gets tested by ICE just the same as any other candidate. 518 As an optimization, as soon as R gets L's check message R immediately 519 sends a check message to L on the same candidate pair. This 520 accelerates the process of finding a valid candidate, and is called a 521 TRIGGERED CHECK. 523 At the end of this handshake, both L and R know that they can send 524 (and receive) messages end-to-end in both directions. 526 2.3. Sorting Candidates 528 Because the algorithm above searches all candidate pairs, if a 529 working pair exists it will eventually find it no matter what order 530 the candidates are tried in. In order to produce faster (and better) 531 results, the candidates are sorted in a specified order. The 532 resulting list of sorted candidate pairs is called the CHECK LIST. 533 The algorithm is described in Section 4.1.2 but follows two general 534 principles: 536 o Each agent gives its candidates a numeric priority which is sent 537 along with the candidate to the peer 539 o The local and remote priorities are combined so that each agent 540 has the same ordering for the candidate pairs. 542 The second property is important for getting ICE to work when there 543 are NATs in front of L and R. Frequently, NATs will not allow packets 544 in from a host until the agent behind the NAT has sent a packet 545 towards that host. Consequently, ICE checks in each direction will 546 not succeed until both sides have sent a check through their 547 respective NATs. 549 The agent works through this check list by sending a STUN request for 550 the next candidate pair on the list periodically. These are called 551 ORDINARY CHECKS. 553 In general the priority algorithm is designed so that candidates of 554 similar type get similar priorities and so that more direct routes 555 (that is, through fewer media relays and through fewer NATs) are 556 preferred over indirect ones (ones with more media relays and more 557 NATs). Within those guidelines, however, agents have a fair amount 558 of discretion about how to tune their algorithms. 560 2.4. Frozen Candidates 562 The previous description only addresses the case where the agents 563 wish to establish a media session with one COMPONENT (a piece of a 564 media stream requiring a single transport address; a media stream may 565 require multiple components, each of which has to work for the media 566 stream as a whole to be work). Typically, (e.g., with RTP and RTCP) 567 the agents actually need to establish connectivity for more than one 568 flow. 570 The network properties are likely to be very similar for each 571 component (especially because RTP and RTCP are sent and received from 572 the same IP address). It is usually possible to leverage information 573 from one media component in order to determine the best candidates 574 for another. ICE does this with a mechanism called "frozen 575 candidates." 577 Each candidate is associated with a property called its FOUNDATION. 578 Two candidates have the same foundation when they are "similar" - of 579 the same type and obtained from the same interface and STUN server. 580 Otherwise, their foundation is different. A candidate pair has a 581 foundation too, which is just the concatenation of the foundations of 582 its two candidates. Initially, only the candidate pairs with unique 583 foundations are tested. The other candidate pairs are marked 584 "frozen". When the connectivity checks for a candidate pair succeed, 585 the other candidate pairs with the same foundation are unfrozen. 586 This avoids repeated checking of components which are superficially 587 more attractive but in fact are likely to fail. 589 While we've described "frozen" here as a separate mechanism for 590 expository purposes, in fact it is an integral part of ICE and the 591 the ICE prioritization algorithm automatically ensures that the right 592 candidates are unfrozen and checked in the right order. 594 2.5. Security for Checks 596 Because ICE is used to discover which addresses can be used to send 597 media between two agents, it is important to ensure that the process 598 cannot be hijacked to send media to the wrong location. Each STUN 599 connectivity check is covered by a message authentication code (MAC) 600 computed using a key exchanged in the signalling channel. This MAC 601 provides message integrity and data origin authentication, thus 602 stopping an attacker from forging or modifying connectivity check 603 messages. The MAC also aids in disambiguating ICE exchanges from 604 forked calls when ICE is used with SIP [3]. 606 2.6. Concluding ICE 608 ICE checks are performed in a specific sequence, so that high 609 priority candidate pairs are checked first, followed by lower 610 priority ones. One way to conclude ICE is to declare victory as soon 611 as a check for each component of each media stream completes 612 successfully. Indeed, this is a reasonable algorithm, and details 613 for it are provided below. However, it is possible that packet 614 losses will cause a higher priority check to take longer to complete. 615 In that case, allowing ICE to run a little longer might produce 616 better results. More fundamentally, however, the prioritization 617 defined by this specification may not yield "optimal" results. As an 618 example, if the aim is to select low latency media paths, usage of a 619 relay is a hint that latencies may be higher, but it is nothing more 620 than a hint. An actual RTT measurement could be made, and it might 621 demonstrate that a pair with lower priority is actually better than 622 one with higher priority. 624 Consequently, ICE assigns one of the agents in the role of the 625 CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The 626 controlling agent gets to nominate which candidate pairs will get 627 used for media amongst the ones that are valid. It can do this in 628 one of two ways - using REGULAR NOMINATION or AGGRESSIVE NOMINATION. 630 With regular nomination, the controlling agent lets the checks 631 continue until at least one valid candidate pair for each media 632 stream is found. Then, it picks amongst those that are valid, and 633 sends a second STUN request on its NOMINATED candidate pair, but this 634 time with a flag set to tell the peer that this pair has been 635 nominated for use. This is shown in Figure 4. 637 L R 638 - - 639 STUN request -> \ L's 640 <- STUN response / check 642 <- STUN request \ R's 643 STUN response -> / check 645 STUN request + flag -> \ L's 646 <- STUN response / check 648 Figure 4: Regular Nomination 650 Once the STUN transaction with the flag completes, both sides cancel 651 any future checks for that media stream. ICE will now send media 652 using this pair. The pair an ICE agent is using for media is called 653 the SELECTED PAIR. 655 In aggressive nomination, the controlling agent puts the flag in 656 every STUN request it sends. This way, once the first check 657 succeeds, ICE processing is complete for that media stream and the 658 controlling agent doesn't have to send a second STUN request. The 659 selected pair will be the highest priority valid pair whose check 660 succeeeded. Aggressive nomination is faster than regular nomination, 661 but gives less flexibility. Aggressive nomination is shown in 662 Figure 5. 664 L R 665 - - 666 STUN request + flag -> \ L's 667 <- STUN response / check 669 <- STUN request \ R's 670 STUN response -> / check 672 Figure 5: Aggressive Nomination 674 Once all of the media streams are completed, the controlling endpoint 675 sends an updated offer if the candidates in the m and c lines for the 676 media stream (called the DEFAULT CANDIDATES) don't match ICE's 677 SELECTED CANDIDATES. 679 Once ICE is concluded, it can be restarted at any time for one or all 680 of the media streams by either agent. This is done by sending an 681 updated offer indicating a restart. 683 2.7. Lite Implementations 685 In order for ICE to be used in a call, both agents need to support 686 it. However, certain agents will always be connected to the public 687 Internet and have a public IP address at which it can receive packets 688 from any correspondent. To make it easier for these devices to 689 support ICE, ICE defines a special type of implementation called LITE 690 (in contrast to the normal FULL implementation). A lite 691 implementation doesn't gather candidates; it includes only host 692 candidates for any media stream. Lite agents do not generate 693 connectivity checks or run the state machines, though they need to be 694 able to respond to connectivity checks. When a lite implementation 695 connects with a full implementation, the full agent takes the role of 696 the controlling agent, and the lite agent takes on the controlled 697 role. When two lite implementations connect, no checks are sent. 699 For guidance on when a lite implementation is appropriate, see the 700 discussion in Appendix A. 702 It is important to note that the lite implementation was added to 703 this specification to provide a stepping stone to full 704 implementation. Even for devices that are always connected to the 705 public Internet, a full implementation is preferable if achievable. 707 3. Terminology 709 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 710 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 711 document are to be interpreted as described in RFC 2119 [1]. 713 Readers should be familiar with the terminology defined in the offer/ 714 answer model [4], STUN [13] and NAT Behavioral requirements for UDP 715 [30] 717 This specification makes use of the following additional terminology: 719 Agent: As defined in RFC 3264, an agent is the protocol 720 implementation involved in the offer/answer exchange. There are 721 two agents involved in an offer/answer exchange. 723 Peer: From the perspective of one of the agents in a session, its 724 peer is the other agent. Specifically, from the perspective of 725 the offerer, the peer is the answerer. From the perspective of 726 the answerer, the peer is the offerer. 728 Transport Address: The combination of an IP address and transport 729 protocol (such as UDP or TCP) port. 731 Candidate: A transport address that is a potential point of contact 732 for receipt of media. Candidates also have properties - their 733 type (server reflexive, relayed or host), priority, foundation, 734 and base. 736 Component: A component is a piece of a media stream requiring a 737 single transport address; a media stream may require multiple 738 components, each of which has to work for the media stream as a 739 whole to work. For media streams based on RTP, there are two 740 components per media stream - one for RTP, and one for RTCP. 742 Host Candidate: A candidate obtained by binding to a specific port 743 from an interface on the host. This includes both physical 744 interfaces and logical ones, such as ones obtained through Virtual 745 Private Networks (VPNs) and Realm Specific IP (RSIP) [20] (which 746 lives at the operating system level). 748 Server Reflexive Candidate: A candidate obtained by sending a STUN 749 request from a host candidate to a STUN server, distinct from the 750 peer. The STUN server's address is configured or learned by the 751 client prior to an offer/answer exchange. 753 Peer Reflexive Candidate: A candidate obtained by sending a STUN 754 request from a host candidate to the STUN server running on a 755 peer's candidate. 757 Relayed Candidate: A candidate obtained by sending a STUN Allocate 758 request from a host candidate to a STUN server. The relayed 759 candidate is resident on the STUN server, and the STUN server 760 relays packets back towards the agent. 762 Base: The base of a server reflexive candidate is the host candidate 763 from which it was derived. A host candidate is also said to have 764 a base, equal to that candidate itself. Similarly, the base of a 765 relayed candidate is that candidate itself. 767 Foundation: An arbitrary string that is the same for two candidates 768 that have the same type, base IP address, and STUN server. If any 769 of these are different then the foundation will be different. Two 770 candidate pairs with the same foundation pairs are likely to have 771 similar network characteristics. Foundations are used in the 772 frozen algorithm. 774 Local Candidate: A candidate that an agent has obtained and included 775 in an offer or answer it sent. 777 Remote Candidate: A candidate that an agent received in an offer or 778 answer from its peer. 780 Default Destination/Candidate: The default destination for a 781 component of a media stream is the transport address that would be 782 used by an agent that is not ICE aware. For the RTP component, 783 the default IP address is in the c line of the SDP, and the port 784 in the m line. For the RTCP component it is in the rtcp attribute 785 when present, and when not present, the IP address in the c line 786 and 1 plus the port in the m line. A default candidate for a 787 component is one whose transport address matches the default 788 destination for that component. 790 Candidate Pair: A pairing containing a local candidate and a remote 791 candidate. 793 Check, Connectivity Check, STUN Check: A STUN Binding Request 794 transaction for the purposes of verifying connectivity. A check 795 is sent from the local candidate to the remote candidate of a 796 candidate pair. 798 Check List: An ordered set of candidate pairs that an agent will use 799 to generate checks. 801 Ordinary Check: A connectivity check generated by an agent as a 802 consequence of a timer that fires periodically, instructing it to 803 send a check. 805 Triggered Check: A connectivity check generated as a consequence of 806 the receipt of a connectivity check from the peer. 808 Valid List: An ordered set of candidate pairs for a media stream 809 that have been validated by a successful STUN transaction. 811 Full: An ICE implementation that performs the complete set of 812 functionality defined by this specification. 814 Lite: An ICE implementation that omits certain functions, 815 implementing only as much as is necessary for a peer 816 implementation that is full to gain the benefits of ICE. Lite 817 implementations do not maintain any of the state machines and do 818 not generate connectivity checks. 820 Controlling Agent: The STUN agent which is responsible for selecting 821 the final choice of candidate pairs and signaling them through 822 STUN and an updated offer, if needed. In any session, one agent 823 is always controlling. The other is the controlled agent. 825 Controlled Agent: A STUN agent which waits for the controlling agent 826 to select the final choice of candidate pairs. 828 Regular Nomination: The process of picking a valid candidate pair 829 for media traffic by validating the pair with one STUN request, 830 and then picking it by sending a second STUN request with a flag 831 indicating its nomination. 833 Aggressive Nomination: The process of picking a valid candidate pair 834 for media traffic by including a flag in every STUN request, such 835 that the first one to produce a valid candidate pair is used for 836 media. 838 Nominated: If a valid candidate pair has its nominated flag set, it 839 means that it may be selected by ICE for sending and receiving 840 media. 842 Selected Pair, Selected Candidate: The candidate pair selected by 843 ICE for sending and receiving media is called the selected pair, 844 and each of its candidates is called the selected candidate. 846 4. Sending the Initial Offer 848 In order to send the initial offer in an offer/answer exchange, an 849 agent must (1) gather candidates, (2) prioritize them, (3) choose 850 default candidates, and then (4) formulate and send the SDP. The 851 first of these four 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 communications 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. Three types 861 are defined and gathered by this specification - host candidates, 862 server reflexive candidates, and relayed candidates. The server 863 reflexive and relayed candidates are gathered using STUN's Binding 864 Discovery and Relay Usages. The base of a candidate is the candidate 865 that an agent must send from when using that candidate. 867 4.1.1.1. Host Candidates 869 The first step is to gather host candidates. Host candidates are 870 obtained by binding to ports (typically ephemeral) on an interface 871 (physical or virtual, including VPN interfaces) on the host. The 872 process for gathering host candidates depends on the transport 873 protocol. Procedures are specified here for UDP. 875 For each UDP media stream the agent wishes to use, the agent SHOULD 876 obtain a candidate for each component of the media stream on each 877 interface that the host has. It obtains each candidate by binding to 878 a UDP port on the specific interface. A host candidate (and indeed 879 every candidate) is always associated with a specific component for 880 which it is a candidate. Each component has an ID assigned to it, 881 called the component ID. For RTP-based media streams, the RTP itself 882 has a component ID of 1, and RTCP a component ID of 2. If an agent 883 is using RTCP it MUST obtain a candidate for it. If an agent is 884 using both RTP and RTCP, it would end up with 2*K host candidates if 885 an agent has K interfaces. 887 The base for each host candidate is set to the candidate itself. 889 4.1.1.2. Server Reflexive and Relayed Candidates 891 Agents SHOULD obtain relayed candidates and SHOULD obtain server 892 reflexive candidates. These requirements are at SHOULD strength to 893 allow for provider variation. Use of STUN servers may be unnecessary 894 in closed networks where agents are never connected to the public 895 Internet or to endpoints outside of the closed network. In such 896 cases, a full implementation would be used for agents that are dual- 897 stack or multi-homed, to select a host candidate. Use of relays is 898 expensive, and when ICE is being used, relays will only be utilized 899 when both endpoints are behind NATs that perform address and port 900 dependent mapping. Consequently, some deployments might consider 901 this use case to be marginal, and elect not to use relays. If an 902 agent does not gather server reflexive or relayed candidates, it is 903 RECOMMENDED that the functionality be implemented and just disabled 904 through configuration, so that it can re-enabled through 905 configuration if conditions change in the future. 907 The agent next pairs each host candidate with the STUN server with 908 which it is configured or has discovered by some means. This 909 specification only considers usage of a single STUN server. When 910 there are multiple choices for that single STUN server (when, for 911 example, they are learned through DNS records and multiple results 912 are returned), an agent SHOULD use a single STUN server (based on its 913 IP address) for all candidates for a particular session. This 914 improves the performance of ICE. The result is a set of host 915 candidate/STUN server pairs. The agent then chooses one pair, and 916 sends a STUN request to the server from that host candidate. If the 917 agent is using both relayed and server reflexive candidates, this 918 request MUST be a STUN Allocate request using the relay usage [14]. 919 If the agent is using only server reflexive candidates, the request 920 MUST be a STUN Binding request using the binding discovery usage 921 [13]. 923 Every Ta milliseconds thereafter, the agent can generate another new 924 STUN transaction. This transaction can either be a retry of a 925 previous transaction which failed with a recoverable error (such as 926 authentication failure), or a transaction for a new candidate/STUN 927 server pair. The agent SHOULD NOT generate transactions more 928 frequently than one every Ta milliseconds. 930 The value of Ta SHOULD be configurable, and SHOULD have a default of: 932 For each media stream i: 933 Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime 935 1 936 Ta = MAX (20ms, ------------------- ) 937 k 938 ---- 939 \ 1 940 > ------ 941 / Ta_i 942 ---- 943 i=1 945 Where k is the number of media streams. In addition, the 946 retransmission timer for the STUN transactions, RTO, defined in [13], 947 SHOULD be configurable and SHOULD have a default of: 949 RTO = MAX (100ms, Ta * (number of candidate/STUN server pairs)) 951 See Appendix B.1 for a discussion on this formula and its 952 implications. Because of this pacing, it will take a certain amount 953 of time to obtain all of the server reflexive and relayed candidates. 954 Implementations should be aware of the time required to do this, and 955 if the application requires a time budget, limit the number of 956 candidates which are gathered. 958 The agent will receive a STUN Binding or Allocate response. A 959 successful Allocate Response will provide the agent with a server 960 reflexive candidate (obtained from the mapped address) and a relayed 961 candidate in the RELAY-ADDRESS attribute. If the Allocate request is 962 rejected because the server lacks resources to fulfill it, the agent 963 SHOULD instead send a Binding Request to obtain a server reflexive 964 candidate. A Binding Response will provide the agent with only a 965 server reflexive candidate (also obtained from the mapped address). 966 The base of the server reflexive candidate is the host candidate from 967 which the Allocate or Binding request was sent. The base of a 968 relayed candidate is that candidate itself. If a relayed candidate 969 is identical to a host candidate (which can happen in rare cases), 970 the relayed candidate MUST be discarded. 972 4.1.1.3. Eliminating Redundant Candidates 974 Next, the agent eliminates redundant candidates. A candidate is 975 redundant if its transport address equals another candidate, and its 976 base equals the base of that other candidate. Note that two 977 candidates can have the same transport address yet have different 978 bases, and these would not be considered redundant. Frequently, a 979 server reflexive candidate and a host candidate will be redundant 980 when the agent is not behind a NAT. 982 4.1.1.4. Computing Foundations 984 Finally, the agent assigns each candidate a foundation. The 985 foundation is an identifier, scoped within a session. Two candidates 986 MUST have the same foundation ID when all of the following are true: 988 o they are of the same type (host, relayed, server reflexive, or 989 peer reflexive) 991 o their bases have the same IP address (the ports can be different) 993 o for reflexive and relayed candidates, the STUN servers used to 994 obtain them have the same IP address. 996 Similarly, two candidates MUST have different foundations if their 997 types are different, their bases have different IP addresses, or the 998 STUN servers used to obtain them have different IP addresses. 1000 4.1.1.5. Keeping Candidates Alive 1002 Once server reflexive and relayed candidates are allocated, they MUST 1003 be kept alive until ICE processing has completed, as described in 1004 Section 8.3. For server reflexive candidates learned through the 1005 Binding Discovery usage, the bindings MUST be kept alive by another 1006 Binding Request from the Binding Discovery usage. For relayed 1007 candidates learned through the Relay Usage, the keepalive MUST be a 1008 new Allocate request. The Allocate request will also refresh the 1009 server reflexive candidate. 1011 4.1.2. Prioritizing Candidates 1013 The prioritization process results in the assignment of a priority to 1014 each candidate. Each candidate for a media stream MUST have a unique 1015 priority that MUST be a positive integer between 1 and (2**32 - 1). 1016 This priority will be used by ICE to determine the order of the 1017 connectivity checks and the relative preference for candidates. 1019 An agent SHOULD compute this priority using the formula in 1020 Section 4.1.2.1 and choose its parameters using the guidelines in 1021 Section 4.1.2.2. If an agent elects to use a different formula, ICE 1022 will take longer to converge since both agents will not be 1023 coordinated in their checks. 1025 4.1.2.1. Recommended Formula 1027 When using the formula, an agent computes the priority by determining 1028 a preference for each type of candidate (server reflexive, peer 1029 reflexive, relayed and host), and, when the agent is multihomed, 1030 choosing a preference for its interfaces. These two preferences are 1031 then combined to compute the priority for a candidate. That priority 1032 is computed using the following formula: 1034 priority = (2^24)*(type preference) + 1035 (2^8)*(local preference) + 1036 (2^0)*(256 - component ID) 1038 The type preference MUST be an integer from 0 to 126 inclusive, and 1039 represents the preference for the type of the candidate (where the 1040 types are local, server reflexive, peer reflexive and relayed). A 1041 126 is the highest preference, and a 0 is the lowest. Setting the 1042 value to a 0 means that candidates of this type will only be used as 1043 a last resort. The type preference MUST be identical for all 1044 candidates of the same type and MUST be different for candidates of 1045 different types. The type preference for peer reflexive candidates 1046 MUST be higher than that of server reflexive candidates. Note that 1047 candidates gathered based on the procedures of Section 4.1.1 will 1048 never be peer reflexive candidates; candidates of these type are 1049 learned from the STUN connectivity checks performed by ICE. 1051 The local preference MUST be an integer from 0 to 65535 inclusive. 1052 It represents a preference for the particular interface from which 1053 the candidate was obtained, in cases where an agent is multihomed. 1054 65535 represents the highest preference, and a zero, the lowest. 1055 When there is only a single interface, this value SHOULD be set to 1056 65535. More generally, if there are multiple candidates for a 1057 particular component for a particular media stream which have the 1058 same type, the local preference MUST be unique for each one. In this 1059 specification, this only happens for multi-homed hosts. 1061 The component ID is the component ID for the candidate, and MUST be 1062 between 1 and 256 inclusive. 1064 4.1.2.2. Guidelines for Choosing Type and Local Preferences 1066 One criteria for selection of the type and local preference values is 1067 the use of an intermediary, such as a media relay. With an 1068 intermediary, if media is sent to that candidate, it will first 1069 transit the intermediary before being received. Relayed candidates 1070 are one type of candidate that involves an intermediary. Another are 1071 host candidates obtained from a VPN interface. When media is 1072 transited through an intermediary, it can increase the latency 1073 between transmission and reception. It can increase the packet 1074 losses, because of the additional router hops that may be taken. It 1075 may increase the cost of providing service, since media will be 1076 routed in and right back out of a media relay run by the provider. 1077 If these concerns are important, the type preference for relayed 1078 candidates SHOULD be lower than host candidates. The RECOMMENDED 1079 values are 126 for host candidates, 100 for server reflexive 1080 candidates, 110 for peer reflexive candidates, and 0 for relayed 1081 candidates. Furthermore, if an agent is multi-homed and has multiple 1082 interfaces, the local preference for host candidates from a VPN 1083 interface SHOULD have a priority of 0. 1085 Another criteria for selection of preferences is IP address family. 1086 ICE works with both IPv4 and IPv6. It therefore provides a 1087 transition mechanism that allows dual-stack hosts to prefer 1088 connectivity over IPv6, but to fall back to IPv4 in case the v6 1089 networks are disconnected (due, for example, to a failure in a 6to4 1090 relay) [25]. It can also help with hosts that have both a native 1091 IPv6 address and a 6to4 address. In such a case, higher local 1092 preferences could be assigned to the v6 interface, followed by the 1093 6to4 interfaces, followed by the v4 interfaces. This allows a site 1094 to obtain and begin using native v6 addresses immediately, yet still 1095 fallback to 6to4 addresses when communicating with agents in other 1096 sites that do not yet have native v6 connectivity. 1098 Another criteria for selecting preferences is security. If a user is 1099 a telecommuter, and therefore connected to their corporate network 1100 and a local home network, they may prefer their voice traffic to be 1101 routed over the VPN in order to keep it on the corporate network when 1102 communicating within the enterprise, but use the local network when 1103 communicating with users outside of the enterprise. In such a case, 1104 a VPN interface would have a higher local preference than any other 1105 interface. 1107 Another criteria for selecting preferences is topological awareness. 1108 This is most useful for candidates that make use of relays. In those 1109 cases, if an agent has preconfigured or dynamically discovered 1110 knowledge of the topological proximity of the relays to itself, it 1111 can use that to assign higher local preferences to candidates 1112 obtained from closer relays. 1114 4.1.3. Choosing Default Candidates 1116 A candidate is said to be default if it would be the target of media 1117 from a non-ICE peer; that target being called the DEFAULT 1118 DESTINATION. If the default candidates are not selected by the ICE 1119 algorithm when communicating with an ICE-aware peer, an updated 1120 offer/answer will be required after ICE processing completes in order 1121 to "correct" the SDP so that the default destination for media 1122 matches the candidates selected by ICE. If ICE happens to select the 1123 default candidates, no updated offer/answer is required. 1125 An agent MUST choose a set of candidates, one for each component of 1126 each in-use media stream, to be default. A media stream is in-use if 1127 it does not have a port of zero (which is used in RFC 3264 to reject 1128 a media stream). Consequently, a media stream is in-use even if it 1129 is marked as a=inactive [10] or has a bandwidth value of zero. 1131 It is RECOMMENDED that default candidates be chosen based on the 1132 likelihood of those candidates to work with the peer that is being 1133 contacted. It is RECOMMENDED that the default candidates are the 1134 relayed candidates (if relayed candidates are available), server 1135 reflexive candidates (if server reflexive candidates are available), 1136 and finally host candidates. 1138 4.2. Lite Implementation 1140 Lite implementations only utilize host candidates. A lite 1141 implementation MUST, for each component of each media stream, 1142 allocate zero or one IPv4 candidates. It MAY allocate zero or more 1143 IPv6 candidates, but no more than one per each IPv6 address utilized 1144 by the host. Since there can be no more than one IPv4 candidate per 1145 component of each media stream, if an agent has multiple IPv4 1146 interfaces, it MUST choose one for allocating the candidate. If a 1147 host is dual-stack, it is RECOMMENDED that it allocate one IPv4 1148 candidate, one link local and one global IPv6 address. With the lite 1149 implementation, ICE cannot be used to dynamically choose amongst 1150 candidates. Therefore, including more than one candidate from a 1151 particular scope is NOT RECOMMENDED, since only a connectivity check 1152 can truly determine whether to use one address or the other. 1154 Each component has an ID assigned to it, called the component ID. 1155 For RTP-based media streams the RTP itself has a component ID of 1, 1156 and RTCP a component ID of 2. If an agent is using RTCP it MUST 1157 obtain candidates for it. 1159 Each candidate is assigned a foundation. The foundation MUST be 1160 different for two candidates allocated from different IP addresses, 1161 and MUST be the same otherwise. A simple integer that increments for 1162 each IP address will suffice. In addition, each candidate MUST be 1163 assigned a unique priority amongst all candidates for the same media 1164 stream. This priority SHOULD be equal to: 1166 priority = (2^24)*(126) + 1167 (2^8)*(IP precedence) + 1168 (2^0)*(256 - component ID) 1170 If a host is v4-only, it SHOULD set the IP precedence to 65535. If a 1171 host is v6 or dual-stack, the IP precedence is the precedence value 1172 for IP addresses described in RFC 3484 [12]. 1174 Next, an agent chooses a default candidate for each component of each 1175 media stream. If a host is IPv4 only, there would only be one 1176 candidate for each component of each media stream, and therefore that 1177 candidate is the default. If a host is IPv6 or dual stack, the 1178 selection of default is a matter of local policy. This default 1179 SHOULD be chosen, such that, it is the candidate most likely to be 1180 used with a peer. For IPv6-only hosts, this would typically by a 1181 globally scoped IPv6 address. For dual-stack hosts, the IPv4 address 1182 is RECOMMENDED. 1184 4.3. Encoding the SDP 1186 The process of encoding the SDP is identical between full and lite 1187 implementations. 1189 The agent will include an m-line for each media stream it wishes to 1190 use. The ordering of media streams in the SDP is relevant for ICE. 1191 ICE will perform its connectivity checks for the first m-line first, 1192 and consequently media will be able to flow for that stream first. 1193 Agents SHOULD place their most important media stream, if there is 1194 one, first in the SDP. 1196 There will be a candidate attribute for each candidate for a 1197 particular media stream. Section 15 provides detailed rules for 1198 constructing this attribute. The attribute carries the IP address, 1199 port and transport protocol for the candidate, in addition to its 1200 properties that need to be signaled to the peer for ICE to work: the 1201 priority, foundation, and component ID. The candidate attribute also 1202 carries information about the candidate that is useful for 1203 diagnostics and other functions: its type and related transport 1204 addresses. 1206 STUN connectivity checks between agents make use of a short term 1207 credential that is exchanged in the offer/answer process. The 1208 username part of this credential is formed by concatenating a 1209 username fragment from each agent, separated by a colon. Each agent 1210 also provides a password, used to compute the message integrity for 1211 requests it receives. The username fragment and password are 1212 exchanged in the ice-ufrag and ice-pwd attributes, respectively. In 1213 addition to providing security, the username provides disambiguation 1214 and correlation of checks to media streams. See Appendix B.4 for 1215 motivation. 1217 If an agent is a lite implementation, it MUST include an "a=ice-lite" 1218 session level attribute in its SDP. If an agent is a full 1219 implementation, it MUST NOT include this attribute. 1221 The default candidates are added to the SDP as the default 1222 destination for media. For streams based on RTP, this is done by 1223 placing the IP address and port of the RTP candidate into the c and m 1224 lines, respectively. If the agent is utilizing RTCP, it MUST encode 1225 the RTCP candidate using the a=rtcp attribute as defined in RFC 3605 1226 [2]. If RTCP is not in use, the agent MUST signal that using b=RS:0 1227 and b=RR:0 as defined in RFC 3556 [5]. 1229 The transport addresses that will be the default destination for 1230 media when communicating with non-ICE peers MUST also be present as 1231 candidates in one or more a=candidate lines. 1233 ICE provides for extensibility by allowing an offer or answer to 1234 contain a series of tokens which identify the ICE extensions used by 1235 that agent. If an agent supports an ICE extension, it MUST include 1236 the token defined for that extension in the ice-options attribute. 1238 The following is an example SDP message that includes ICE attributes 1239 (lines folded for readability): 1241 v=0 1242 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 1243 s= 1244 c=IN IP4 192.0.2.3 1245 t=0 0 1246 a=ice-pwd:asd88fgpdd777uzjYhagZg 1247 a=ice-ufrag:8hhY 1248 m=audio 45664 RTP/AVP 0 1249 b=RS:0 1250 b=RR:0 1251 a=rtpmap:0 PCMU/8000 1252 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 1253 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 1254 10.0.1.1 rport 8998 1256 Once an agent has sent its offer or sent its answer, that agent MUST 1257 be prepared to receive both STUN and media packets on each candidate. 1258 As discussed in Section 11.1, media packets can be sent to a 1259 candidate prior to its appearance as the default destination for 1260 media in an offer or answer. 1262 5. Receiving the Initial Offer 1264 When an agent receives an initial offer, it will check if the offerer 1265 supports ICE, determine its own role, gather candidates, prioritize 1266 them, choose default candidates, encode and send an answer, and for 1267 full implementations, form the check lists and begin connectivity 1268 checks. 1270 5.1. Verifying ICE Support 1272 The agent will proceed with the ICE procedures defined in this 1273 specification if, for each media stream in the SDP it received, the 1274 default destination for each component of that media stream appears 1275 in a candidate attribute. For example, in the case of RTP, the IP 1276 address and port in the c and m line, respectively, appears in a 1277 candidate attribute and the value in the rtcp attribute appears in a 1278 candidate attribute. 1280 If this condition is not met, the agent MUST process the SDP based on 1281 normal RFC 3264 procedures, without using any of the ICE mechanisms 1282 described in the remainder of this specification with the following 1283 exceptions: 1285 1. The agent MUST follow the rules of Section 10, which describe 1286 keepalive procedures for all agents. 1288 2. If the agent is not proceeding with ICE because there were 1289 a=candidate attributes, but none that matched the default 1290 destination of the media stream, the agent MUST include an a=ice- 1291 mismatch attribute in its answer. 1293 5.2. Determining Role 1295 For each session, each agent takes on a role. There are two roles - 1296 controlling, and controlled. The controlling agent is responsible 1297 for the choice of the final candidate pairs used for communications. 1298 For a full agent, this means nominating the candidate pairs that can 1299 be used by ICE for each media stream, and for generating the updated 1300 offer based on ICE's selection, when needed. For a lite 1301 implementation, being the controlling agent means selecting a 1302 candidate pair based on the ones in the offer and answer (for IPv4, 1303 there is only ever one pair), and then generating an updated offer 1304 reflecting that selection, when needed (it is never needed for an 1305 IPv4 only host). The controlled agent is told which candidate pairs 1306 to use for each media stream, and does not generate an updated offer 1307 to signal this information. The sections below describe in detail 1308 the actual procedures following by controlling and controlled nodes. 1310 The rules for determining the role and the impact on behavior are as 1311 follows: 1313 Both agents are full: The agent which generated the offer which 1314 started the ICE processing MUST take the controlling role, and the 1315 other MUST take the controlled role. Both agents will form check 1316 lists, run the ICE state machines, and generate connectivity 1317 checks. The controlling agent will execute the logic in 1318 Section 8.1 to nominate pairs that will be selected by ICE, and 1319 then both agents end ICE as described in Section 8.1.2. In 1320 unusual cases, described in Appendix B.11, it is possible for both 1321 agents to mistakenly believe they are controlled or controlling. 1322 To resolve this, each agent MUST select a random number, called 1323 the tie-breaker, uniformly distributed between 0 and (2**64) - 1 1324 (that is, a 64 bit positive integer). This number is used in STUN 1325 checks to detect and repair this case, as described in 1326 Section 7.1.1.2. 1328 One agent Full, one Lite: The full agent MUST take the controlling 1329 role, and the lite agent MUST take the controlled role. The full 1330 agent will form check lists, run the ICE state machines, and 1331 generate connectivity checks. That agent will execute the logic 1332 in Section 8.1 to nominate pairs that will be selected by ICE, and 1333 use the logic in Section 8.1.2 to end ICE. The lite 1334 implementation will just listen for connectivity checks, receive 1335 them and respond to them, and then conclude ICE as described in 1336 Section 8.2. For the lite implementation, the state of ICE 1337 processing for each media stream is considered to be Running, and 1338 the state of ICE overall is Running. 1340 Both Lite: The agent which generated the offer which started the ICE 1341 processing MUST take the controlling role, and the other MUST take 1342 the controlled role. In this case, no connectivity checks are 1343 ever sent. Rather, once the offer/answer exchange completes, each 1344 agent performs the processing described in Section 8 without 1345 connectivity checks. It is possible that both agents will believe 1346 they are controlled or controlling. In the latter case, the 1347 conflict is resolved through glare detection capabilities in the 1348 signaling protocol carrying the offer/answer exchange. The state 1349 of ICE processing for each media stream is considered to be 1350 Running, and the state of ICE overall is Running. 1352 Once roles are determined for a session, they persist unless ICE is 1353 restarted. A ICE restart (Section 9.1) causes a new selection of 1354 roles and tie-breakers. 1356 5.3. Gathering Candidates 1358 The process for gathering candidates at the answerer is identical to 1359 the process for the offerer as described in Section 4.1.1 for full 1360 implementations and Section 4.2 for lite implementations. It is 1361 RECOMMENDED that this process begin immediately on receipt of the 1362 offer, prior to alerting the user. Such gathering MAY begin when an 1363 agent starts. 1365 5.4. Prioritizing Candidates 1367 The process for prioritizing candidates at the answerer is identical 1368 to the process followed by the offerer, as described in Section 4.1.2 1369 for full implementations and Section 4.2 for lite implementations. 1371 5.5. Choosing Default Candidates 1373 The process for selecting default candidates at the answerer is 1374 identical to the process followed by the offerer, as described in 1375 Section 4.1.3 for full implementations and Section 4.2 for lite 1376 implementations. 1378 5.6. Encoding the SDP 1380 The process for encoding the SDP at the answerer is identical to the 1381 process followed by the offerer for both full and lite 1382 implementations, as described in Section 4.3. 1384 5.7. Forming the Check Lists 1386 Forming check lists is done only by full implementations. Lite 1387 implementations MUST skip the steps defined in this section. 1389 There is one check list per in-use media stream resulting from the 1390 offer/answer exchange. To form the check list for a media stream, 1391 the agent forms candidate pairs, computes a candidate pair priority, 1392 orders the pairs by priority, prunes them, and sets their states. 1393 These steps are described in this section. 1395 5.7.1. Forming Candidate Pairs 1397 First, the agent takes each of its candidates for a media stream 1398 (called LOCAL CANDIDATES) and pairs them with the candidates it 1399 received from its peer (called REMOTE CANDIDATES) for that media 1400 stream. In order to prevent the attacks described in Section 17.4.2, 1401 agents MAY limit the number of candidates they'll accept in an offer 1402 or answer. A local candidate is paired with a remote candidate if 1403 and only if the two candidates have the same component ID and have 1404 the same IP address version. It is possible that some of the local 1405 candidates don't get paired with a remote candidate, and some of the 1406 remote candidates don't get paired with local candidates. This can 1407 happen if one agent didn't include candidates for the all of the 1408 components for a media stream. If this happens, the number of 1409 components for that media stream is effectively reduced, and 1410 considered to be equal to the minimum across both agents of the 1411 maximum component ID provided by each agent across all components for 1412 the media stream. 1414 In the case of RTP, this would happen when one agent provided 1415 candidates for RTCP, and the other did not. As another example, the 1416 offerer can multiplex RTP and RTCP on the same port and signals it 1417 can do that in the SDP through an SDP attribute [33]. However, since 1418 the offerer doesn't know if the answerer can perform such 1419 multiplexing, the offerer includes candidates for RTP and RTCP on 1420 separate ports, so that the offer has two components per media 1421 stream. If the answerer can perform such multiplexing, it would 1422 include just a single component for each candidate - for the combined 1423 RTP/RTCP mux. ICE would end up acting as if there was just a single 1424 component for this candidate. 1426 The candidate pairs whose local and remote candidates were both the 1427 default candidates for a particular component is called, 1428 unsurprisingly, the default candidate pair for that component. This 1429 is the pair that would be used to transmit media if both agents had 1430 not been ICE aware. 1432 In order to aid understanding, Figure 11 shows the relationships 1433 between several key concepts - transport addresses, candidates, 1434 candidate pairs, and check lists, in addition to indicating the main 1435 properties of candidates and candidate pairs. 1437 +------------------------------------------+ 1438 | | 1439 | +---------------------+ | 1440 | |+----+ +----+ +----+ | +Type | 1441 | || IP | |Port| |Tran| | +Priority | 1442 | ||Addr| | | | | | +Foundation | 1443 | |+----+ +----+ +----+ | +ComponentiD | 1444 | | Transport | +RelatedAddr | 1445 | | Addr | | 1446 | +---------------------+ +Base | 1447 | Candidate | 1448 +------------------------------------------+ 1449 * * 1450 * ************************************* 1451 * * 1452 +-------------------------------+ 1453 .| | 1454 | Local Remote | 1455 | +----+ +----+ +default? | 1456 | |Cand| |Cand| +valid? | 1457 | +----+ +----+ +nominated?| 1458 | +State | 1459 | | 1460 | | 1461 | Candidate Pair | 1462 +-------------------------------+ 1463 * * 1464 * ************ 1465 * * 1466 +------------------+ 1467 | Candidate Pair | 1468 +------------------+ 1469 +------------------+ 1470 | Candidate Pair | 1471 +------------------+ 1472 +------------------+ 1473 | Candidate Pair | 1474 +------------------+ 1476 Check 1477 List 1478 Figure 11: Conceptual Diagram of a Check List 1480 5.7.2. Computing Pair Priority and Ordering Pairs 1482 Once the pairs are formed, a candidate pair priority is computed. 1483 Let G be the priority for the candidate provided by the controlling 1484 agent. Let D be the priority for the candidate provided by the 1485 controlled agent. The priority for a pair is computed as: 1487 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 1489 Where G>D?1:0 is an expression whose value is 1 if G is greater than 1490 D, and 0 otherwise. This formula ensures a unique priority for each 1491 pair. Once the priority is assigned, the agent sorts the candidate 1492 pairs in decreasing order of priority. If two pairs have identical 1493 priority, the ordering amongst them is arbitrary. 1495 5.7.3. Pruning the Pairs 1497 This sorted list of candidate pairs is used to determine a sequence 1498 of connectivity checks that will be performed. Each check involves 1499 sending a request from a local candidate to a remote candidate. 1500 Since an agent cannot send requests directly from a reflexive 1501 candidate, but only from its base, the agent next goes through the 1502 sorted list of candidate pairs. For each pair where the local 1503 candidate is server reflexive, the server reflexive candidate MUST be 1504 replaced by its base. Once this has been done, the agent MUST prune 1505 the list. This is done by removing a pair if its local and remote 1506 candidates are identical to the local and remote candidates of a pair 1507 higher up on the priority list. The result is a sequence of ordered 1508 candidate pairs, called the check list for that media stream. 1510 In addition, in order to limit the attacks described in 1511 Section 17.4.2, an agent SHOULD limit the total number of 1512 connectivity checks they perform across all check lists to 100, by 1513 discarding the lower priority candidate pairs until there are less 1514 than 100. 1516 5.7.4. Computing States 1518 Each candidate pair in the check list has a foundation and a state. 1519 The foundation is the combination of the foundations of the local and 1520 remote candidates in the pair. The state is assigned once the check 1521 list for each media stream has been computed. There are five 1522 potential values that the state can have: 1524 Waiting: A check has not been performed for this pair, and can be 1525 performed as soon as it is the highest priority Waiting pair on 1526 the check list. 1528 In-Progress: A check has been sent for this pair, but the 1529 transaction is in progress. 1531 Succeeded: A check for this pair was already done and produced a 1532 successful result. 1534 Failed: A check for this pair was already done and failed, either 1535 never producing any response or producing an unrecoverable failure 1536 response. 1538 Frozen: A check for this pair hasn't been performed, and it can't 1539 yet be performed until some other check succeeds, allowing this 1540 pair to unfreeze and move into the Waiting state. 1542 As ICE runs, the pairs will move between states as shown in 1543 Figure 12. 1545 +-----------+ 1546 | | 1547 | | 1548 | Frozen | 1549 | | 1550 | | 1551 +-----------+ 1552 | 1553 |unfreeze 1554 | 1555 V 1556 +-----------+ +-----------+ 1557 | | | | 1558 | | perform | | 1559 | Waiting |-------->|In-Progress| 1560 | | | | 1561 | | | | 1562 +-----------+ +-----------+ 1563 / | 1564 // | 1565 // | 1566 // | 1567 / | 1568 // | 1569 failure // |success 1570 // | 1571 / | 1572 // | 1573 // | 1574 // | 1575 V V 1576 +-----------+ +-----------+ 1577 | | | | 1578 | | | | 1579 | Failed | | Succeeded | 1580 | | | | 1581 | | | | 1582 +-----------+ +-----------+ 1584 Figure 12: Pair State FSM 1586 The initial states for each pair in a check list are computed by 1587 performing the following sequence of steps: 1589 1. The agent sets all of the pairs in each check list to the Frozen 1590 state. 1592 2. The agent examines the check list for the first media stream (a 1593 media stream is the first media stream when it is described by 1594 the first m-line in the SDP offer and answer). For that media 1595 stream, it: 1597 * Groups together all of the pairs with the same foundation, 1599 * For each group, sets the state of the pair with the lowest 1600 component ID to Waiting. If there is more than one such pair, 1601 the one with the highest priority is used. 1603 One of the check lists will have some number of pairs in the Waiting 1604 state, and the other check lists will have all of their pairs in the 1605 Frozen state. A check list with at least one pair that is Waiting is 1606 called an active check list, and a check list with all pairs frozen 1607 is called a frozen check list. 1609 The check list itself is associated with a state, which captures the 1610 state of ICE checks for that media stream. There are three states: 1612 Running: In this state, ICE checks are still in progress for this 1613 media stream. 1615 Completed: In this state, ICE checks have produced nominated pairs 1616 for each component of the media stream. Consequently, ICE has 1617 succeeded and media can be sent. 1619 Failed: In this state, the ICE checks have not completed 1620 successfully for this media stream. 1622 When a check list is first constructed as the consequence of an 1623 offer/answer exchange, it is placed in the Running state. 1625 ICE processing across all media streams also has a state associated 1626 with it. This state is equal to Running while ICE processing is 1627 underway. The state is Completed when ICE processing is complete and 1628 Failed if it failed without success. Rules for transitioning between 1629 states are described below. 1631 5.8. Scheduling Checks 1633 Checks are generated only by full implementations. Lite 1634 implementations MUST skip the steps described in this section. 1636 An agent performs ordinary checks and triggered checks. The 1637 generation of both checks is governed by a timer which fires 1638 periodically for each media stream. The agent maintains a FIFO 1639 queue, called the triggered check queue, which contains candidate 1640 pairs for which checks are to be sent at the next available 1641 opportunity. When the timer fires, the agent removes the top pair 1642 from triggered check queue, performs a connectivity check on that 1643 pair, and sets the state of the candidate pair to In-Progress. If 1644 there are no pairs in the triggered check queue, an ordinary check is 1645 sent. 1647 Once the agent has computed the check lists as described in 1648 Section 5.7, it sets a timer for each active check list. The timer 1649 fires every Ta*N seconds, where N is the number of active check lists 1650 (initially, there is only one active check list). Implementations 1651 MAY set the timer to fire less frequently than this. Implementations 1652 SHOULD take care to spread out these timers so that they do not fire 1653 at the same time for each media stream. Ta is the same value used to 1654 pace the gathering of candidates, as described in Section 4.1.1. 1655 Multiplying by N allows this aggregate check throughput to be split 1656 between all active check lists. The first timer fires immediately, 1657 so that the agent performs a connectivity check the moment the offer/ 1658 answer exchange has been done, followed by the next check Ta seconds 1659 later. 1661 When a connectivity check begins, its retransmission timer RTO SHOULD 1662 be configurable and SHOULD have a default of: 1664 RTO = MAX (100ms, Ta*N * (Num-Waiting)) 1666 Where Num-Waiting are the number of checks in the check list in the 1667 Waiting state. Note that the RTO will be different for each 1668 transaction as the number of checks in the Waiting state changes. 1670 When the timer fires, and there is no triggered check to be sent, the 1671 agent MUST choose an ordinary check as follows: 1673 o Find the highest priority pair in that check list that is in the 1674 Waiting state. 1676 o If there is such a pair: 1678 * Send a STUN check from the local candidate of that pair to the 1679 remote candidate of that pair. The procedures for forming the 1680 STUN request for this purpose are described in Section 7.1.1. 1682 * Set the state of the candidate pair to In-Progress. 1684 o If there is no such pair: 1686 * Find the highest priority pair in that check list that is in 1687 the Frozen state. 1689 * If there is such a pair: 1691 + Unfreeze the pair. 1693 + Perform a check for that pair, causing its state to 1694 transition to In-Progress. 1696 * If there is no such pair: 1698 + Terminate the timer for that check list. 1700 To compute the message integrity for the check, the agent uses the 1701 remote username fragment and password learned from the SDP from its 1702 peer. The local username fragment is known directly by the agent for 1703 its own candidate. 1705 6. Receipt of the Initial Answer 1707 This section describes the procedures that an agent follows when it 1708 receives the answer from the peer. It verifies that its peer 1709 supports ICE, determines its role, and for full implementations, 1710 forms the check list and begins performing ordinary checks. 1712 When ICE is used with SIP, forking may result in a single offer 1713 generating a multiplicity of answers. In that each, ICE proceeds 1714 completely in parallel and independently for each answer, treating 1715 the combination of its offer and each answer as an independent offer/ 1716 answer exchange, with its own set of pairs, check lists, states, and 1717 so on. The only case in which processing of one pair impacts another 1718 is freeing of candidates, discussed below in Section 8.3. 1720 6.1. Verifying ICE Support 1722 The logic at the offerer is identical to that of the answerer as 1723 described in Section 5.1, with the exception that an offerer would 1724 not ever generate a=ice-mismatch attributes in an SDP. 1726 In some cases, the answer may omit a=candidate attributes for the 1727 media streams, and instead include an a=ice-mismatch attribute for 1728 one or more of the media streams in the SDP. This signals to the 1729 offerer that the answerer supports ICE, but that ICE processing was 1730 not used for the session because an intermediary modified the default 1731 destination for media components without modifying the corresponding 1732 candidate attributes. See Section 17 for a discussion of cases where 1733 this can happen. This specification provides no guidance on how an 1734 agent should proceed in such a failure case. 1736 6.2. Determining Role 1738 The offerer follows the same procedures described for the answerer in 1739 Section 5.2. 1741 6.3. Forming the Check List 1743 Formation of check lists is performed only by full implementations. 1744 The offerer follows the same procedures described for the answerer in 1745 Section 5.7. 1747 6.4. Performing Ordinary Checks 1749 Ordinary checks are performed only by full implementations. The 1750 offerer follows the same procedures described for the answerer in 1751 Section 5.8. 1753 7. Performing Connectivity Checks 1755 This section describes how connectivity checks are performed. All 1756 ICE implementations are required to be compliant to [13], as opposed 1757 to the older [16]. However, whereas a full implementation will both 1758 generate checks (acting as a STUN client) and receive them (acting as 1759 a STUN server), a lite implementation will only ever receive checks, 1760 and thus will only act as a STUN server. 1762 7.1. STUN Client Procedures 1764 These procedures define how an agent sends a connectivity check, 1765 whether it is an ordinary or a triggered check. These procedures are 1766 only applicable to full implementations. 1768 7.1.1. Sending the Request 1770 The check is generated by sending a Binding Request from a local 1771 candidate, to a remote candidate. [13] describes how Binding Requests 1772 are constructed and generated. This section defines additional 1773 procedures involving the PRIORITY and USE-CANDIDATE attributes, 1774 defined for the connectivity check usage in Section 18.5, and details 1775 how credentials for message integrity and diffserv markings are 1776 computed. 1778 7.1.1.1. PRIORITY and USE-CANDIDATE 1780 An agent MUST include the PRIORITY attribute in its Binding Request. 1781 The attribute MUST be set equal to the priority that would be 1782 assigned, based on the algorithm in Section 4.1.2, to a peer 1783 reflexive candidate, should one be learned as a consequence of this 1784 check (see Section 7.1.2.2.1 for how peer reflexive candidates are 1785 learned). This priority value will be computed identically to how 1786 the priority for the local candidate of the pair was computed, except 1787 that the type preference is set to the value for peer derived 1788 candidate types. 1790 The controlling agent MAY include the USE-CANDIDATE attribute in the 1791 Binding Request. The controlled agent MUST NOT include it in its 1792 Binding Request. This attribute signals that the controlling agent 1793 wishes to cease checks for this component, and use the candidate pair 1794 resulting from the check for this component. Section 8.1.1 provides 1795 guidance on determining when to include it. 1797 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING 1799 The agent MUST include the ICE-CONTROLLED attribute in the request if 1800 it is in the controlled role, and MUST include the ICE-CONTROLLING 1801 attribute in the request if it is in the controlling role. The 1802 content of either attribute MUST be the tie breaker that was 1803 determined in Section 5.2. These attributes are defined fully in 1804 Section 18.5. 1806 7.1.1.3. FINGERPRINT 1808 The agent MUST include the FINGERPRINT attribute in its connectivity 1809 checks. 1811 7.1.1.4. Forming Credentials 1813 A Binding Request serving as a connectivity check MUST utilize a STUN 1814 short term credential. The agent MUST include the USERNAME and 1815 MESSAGE-INTEGRITY attributes. An agent MUST NOT wait to be 1816 challenged for short term credentials. Rather, it MUST provide them 1817 in each Binding Request. 1819 Rather than being learned from a Shared Secret request, the short 1820 term credential is exchanged in the offer/answer procedures. In 1821 particular, the username is formed by concatenating the username 1822 fragment provided by the peer with the username fragment of the agent 1823 sending the request, separated by a colon (":"). The password is 1824 equal to the password provided by the peer. For example, consider 1825 the case where agent L is the offerer, and agent R is the answerer. 1827 Agent L included a username fragment of LFRAG for its candidates, and 1828 a password of LPASS. Agent R provided a username fragment of RFRAG 1829 and a password of RPASS. A connectivity check from L to R (and its 1830 response of course) utilize the username RFRAG:LFRAG and a password 1831 of RPASS. A connectivity check from R to L (and its response) 1832 utilize the username LFRAG:RFRAG and a password of LPASS. 1834 7.1.1.5. DiffServ Treatment 1836 If the agent is using Diffserv Codepoint markings [28] in its media 1837 packets, it SHOULD apply those same markings to its connectivity 1838 checks. 1840 7.1.2. Processing the Response 1842 When a Binding Response is received, it is correlated to its Binding 1843 Request using the transaction ID, as defined in [13], which then ties 1844 it to the candidate pair for which the Binding Request was sent. 1846 7.1.2.1. Failure Cases 1848 If the STUN transaction generates a 487 (Role Conflict) error 1849 response, the agent checks whether it had included the ICE-CONTROLLED 1850 or ICE-CONTROLLING attribute in the Binding Request. If the request 1851 had contained the ICE-CONTROLLED attribute, the agent MUST switch to 1852 the controlling role if it has not already done so. If the request 1853 had contained the ICE-CONTROLLING attribute, the agent MUST switch to 1854 the controlled role if it has not already done so. Once it has 1855 switched, the agent MUST enqueue the candidate pair whose check 1856 generated the 487 into the triggered check queue. The state of that 1857 pair is set to Waiting. When the triggered check is sent, it will 1858 contain an ICE-CONTROLLING or ICE-CONTROLLED attribute reflecting its 1859 new role. Note, however, that the tie-breaker value MUST NOT be 1860 reselected. 1862 Agents MAY support receipt of ICMP errors for connectivity checks. 1863 If the STUN transaction generates an ICMP error, the agent sets the 1864 state of the pair to Failed. If the STUN transaction generates a 1865 STUN error response that is unrecoverable (as defined in [13]), or 1866 times out, the agent sets the state of the pair to Failed. 1868 The agent MUST check that the source IP address and port of the 1869 response equals the destination IP address and port that the Binding 1870 Request was sent to, and that the destination IP address and port of 1871 the response match the source IP address and port that the Binding 1872 Request was sent from. In other words, the source and destination 1873 transport addresses in the request and responses are the symmetric. 1874 If they are not symmetric, the agent sets the state of the pair to 1875 Failed. 1877 7.1.2.2. Success Cases 1879 A check is considered to be a success if all of the following are 1880 true: 1882 o the STUN transaction generated a success response 1884 o the source IP address and port of the response equals the 1885 destination IP address and port that the Binding Request was sent 1886 to 1888 o the destination IP address and port of the response match the 1889 source IP address and port that the Binding Request was sent from 1891 7.1.2.2.1. Discovering Peer Reflexive Candidates 1893 The agent checks the mapped address from the STUN response. If the 1894 transport address does not match any of the local candidates that the 1895 agent knows about, the mapped address represents a new candidate - a 1896 peer reflexive candidate. Like other candidates, it has a type, 1897 base, priority and foundation. They are computed as follows: 1899 o Its type is equal to peer reflexive. 1901 o Its base is set equal to the local candidate of the candidate pair 1902 from which the STUN check was sent. 1904 o Its priority is set equal to the value of the PRIORITY attribute 1905 in the Binding Request. 1907 o Its foundation is selected as described in Section 4.1.1. 1909 This peer reflexive candidate is then added to the list of local 1910 candidates for the media stream. Its username fragment and password 1911 are the same as all other local candidates for that media stream. 1912 However, the peer reflexive candidate is not paired with other remote 1913 candidates. This is not necessary; a valid pair will be generated 1914 from it momentarily based on the procedures in Section 7.1.2.2.2. If 1915 an agent wishes to pair the peer reflexive candidate with other 1916 remote candidates besides the one in the valid pair that will be 1917 generated, the agent MAY generate an updated offer which includes the 1918 peer reflexive candidate. This will cause it to be paired with all 1919 other remote candidates. 1921 7.1.2.2.2. Constructing a Valid Pair 1923 The agent constructs a candidate pair whose local candidate equals 1924 the mapped address of the response, and whose remote candidate equals 1925 the destination address to which the request was sent. This is 1926 called a valid pair, since it has been validated by a STUN 1927 connectivity check. The valid pair may equal the pair that generated 1928 the check, may equal a different pair in the check list, or may be a 1929 pair not currently on any check list. If the pair equals the pair 1930 that generated the check or is on a check list currently, it is also 1931 added to the VALID LIST, which is maintained by the agent for each 1932 media stream. This list is empty at the start of ICE processing, and 1933 fills as checks are performed, resulting in valid candidate pairs. 1935 It will be very common that the pair will not be on any check list. 1936 Recall that the check list has pairs whose local candidates are never 1937 server reflexive; those pairs had their local candidates converted to 1938 the base of the server reflexive candidates, and then pruned if they 1939 were redundant. When the response to the STUN check arrives, the 1940 mapped address will be reflexive if there is a NAT between the two. 1941 In that case, the valid pair will have a local candidate that doesn't 1942 match any of the pairs in the check list. 1944 If the pair is not on any check list, the agent computes the priority 1945 for the pair based on the priority of each candidate, using the 1946 algorithm in Section 5.7. The priority of the local candidate 1947 depends on its type. If it is not peer reflexive, it is equal to the 1948 priority signaled for that candidate in the SDP. If it is peer 1949 reflexive, it is equal to the PRIORITY attribute the agent placed in 1950 the Binding Request which just completed. The priority of the remote 1951 candidate is taken from the SDP of the peer. If the candidate does 1952 not appear there, then the check must have been a triggered check to 1953 a new remote candidate. In that case, the priority is taken as the 1954 value of the PRIORITY attribute in the Binding Request which 1955 triggered the check that just completed. The pair is then added to 1956 the VALID LIST. 1958 7.1.2.2.3. Updating Pair States 1960 The agent sets the state of the pair that generated the check to 1961 Succeeded. The success of this check might also cause the state of 1962 other checks to change as well. The agent MUST perform the following 1963 two steps: 1965 1. The agent changes the states for all other Frozen pairs for the 1966 same media stream and same foundation to Waiting. Typically 1967 these other pairs will have different component IDs but not 1968 always. 1970 2. If there is a pair in the valid list for every component of this 1971 media stream (where this is the actual number of components being 1972 used, in cases where the number of components signaled in the SDP 1973 differs from offerer to answerer), the success of this check may 1974 unfreeze checks for other media streams. Note that this step is 1975 followed not just the first time the valid list under 1976 consideration has a pair for every component, but every 1977 subsequent time a check succeeds and adds yet another pair to 1978 that valid list. The agent examines the check list for each 1979 other media stream in turn: 1981 * If the check list is active, the agent changes the state of 1982 all Frozen pairs in that check list whose foundation matches a 1983 pair in the valid list under consideration, to Waiting. 1985 * If the check list is frozen, and there is at least one pair in 1986 the check list whose foundation matches a pair in the valid 1987 list under consideration, the state of all pairs in the check 1988 list whose foundation matches a pair in the valid list under 1989 consideration are set to Waiting. This will cause the check 1990 list to become active, and ordinary checks will begin for it, 1991 as described in Section 5.8. 1993 * If the check list is frozen, and there are no pairs in the 1994 check list whose foundation matches a pair in the valid list 1995 under consideration, the agent 1997 + Groups together all of the pairs with the same foundation, 1999 + For each group, sets the state of the pair with the lowest 2000 component ID to Waiting. If there is more than one such 2001 pair, the one with the highest priority is used. 2003 7.1.2.2.4. Updating the Nominated Flag 2005 If the agent was a controlling agent, and it had included a USE- 2006 CANDIDATE attribute in the Binding Request, the valid pair generated 2007 from that check has its nominated flag set to true. This flag 2008 indicates that this valid pair should be used for media if it is the 2009 highest priority one amongst those whose nominated flag is set. This 2010 may conclude ICE processing for this media stream or all media 2011 streams; see Section 8. 2013 If the agent is the controlled agent, the response may result in the 2014 valid pair having its nominated flag set. See Section 7.2.1.5 for 2015 the procedure. 2017 7.1.2.3. Check List and Timer State Updates 2019 Regardless of whether the check was successful or failed, the 2020 completion of the transaction may require updating of check list and 2021 timer states. 2023 If all of the pairs in the check list are now either in the Failed or 2024 Succeeded state: 2026 o If there is not a pair in the valid list for each component of the 2027 media stream, the state of the check list is set to Failed. 2029 o For each frozen check list, the agent: 2031 * Groups together all of the pairs with the same foundation, 2033 * For each group, sets the state of the pair with the lowest 2034 component ID to Waiting. If there is more than one such pair, 2035 the one with the highest priority is used. 2037 If none of the pairs in the check list are in the Waiting or Frozen 2038 state, the check list is no longer considered active, and will not 2039 count towards the value of N in the computation of timers for 2040 ordinary checks as described in Section 5.8. 2042 7.2. STUN Server Procedures 2044 An agent MUST be prepared to receive a Binding Request on the base of 2045 each candidate it included in its most recent offer or answer. This 2046 requirement holds even if the peer is a lite implementation. Receipt 2047 of a Binding Request on a base is an indication that the connectivity 2048 check usage applies to the request. 2050 The agent MUST use a short term credential to authenticate the 2051 request and perform a message integrity check. The agent MUST accept 2052 a credential if the username consists of two values separated by a 2053 colon, where the first value is equal to the username fragment 2054 generated by the agent in an offer or answer for a session in- 2055 progress, and the MESSAGE-INTEGRITY is the output of a hash of the 2056 password and the STUN packet's contents. It is possible (and in fact 2057 very likely) that an offerer will receive a Binding Request prior to 2058 receiving the answer from its peer. If this happens, the agent MUST 2059 generate a response (including computation of the mapped address as 2060 described in Section 7.2.1.2. Once the answer is received, it MUST 2061 proceed with the remaining steps required, namely Section 7.2.1.3, 2062 Section 7.2.1.4, and Section 7.2.1.5 for full implementations. In 2063 cases where multiple STUN requests are received before the answer, 2064 this may cause several pairs to be queued up in the triggered check 2065 queue. 2067 An agent MUST NOT generate a Binding Error Response with an ERROR- 2068 CODE attribute of 300 (Try Alternate). That code is not meaningful 2069 for connectivity checks. 2071 An agent MUST NOT include a NONCE attribute in any response. Though 2072 permitted by STUN for authentication using short term credentials, 2073 with ICE it significantly increases delays. 2075 The agent MUST include the FINGERPRINT attribute in its responses to 2076 connectivity checks. 2078 If the agent is using Diffserv Codepoint markings [28] in its media 2079 packets, it SHOULD apply those same markings to its responses to 2080 Binding Requests. The same would apply to any layer 2 markings the 2081 endpoint might be applying to media packets. 2083 7.2.1. Additional Procedures for Full Implementations 2085 This subsection defines the additional server procedures applicable 2086 to full implementations. 2088 7.2.1.1. Detecting and Repairing Role Conflicts 2090 Normally, the rules for selection of a role in Section 5.2 will 2091 result in each agent selecting a different role - one controlling, 2092 and one controlled. However, in unusual call flows, typically 2093 utilizing third party call control, it is possible for both agents to 2094 select the same role. This section describes procedures for checking 2095 for this case and repairing it. 2097 An agent MUST examine the Binding Request for either the ICE- 2098 CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these 2099 procedures: 2101 o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the 2102 request, the peer agent may have implemented a previous version of 2103 this specification. There may be a conflict, but it cannot be 2104 detected. 2106 o If the agent is in the controlling role, and the ICE-CONTROLLING 2107 attribute is present in the request: 2109 * If the agent's tie-breaker is larger than or equal to the 2110 contents of the ICE-CONTROLLING attribute, the agent generates 2111 a Binding Error Response and includes an ERROR-CODE attribute 2112 with a value of 487 (Role Conflict) but retains its role. 2114 * If the agent's tie-breaker is less than the contents of the 2115 ICE-CONTROLLING attribute, the agent switches to the controlled 2116 role. 2118 o If the agent is in the controlled role, and the ICE-CONTROLLED 2119 attribute is present in the request: 2121 * If the agent's tie-breaker is larger than or equal to the 2122 contents of the ICE-CONTROLLED attribute, the agent switches to 2123 the controlling role. 2125 * If the agent's tie-breaker is less than the contents of the 2126 ICE-CONTROLLED attribute, the agent generates a Binding Error 2127 Response and includes an ERROR-CODE attribute with a value of 2128 487 (Role Conflict) but retains its role. 2130 o If the agent is in the controlled role and the ICE-CONTROLLING 2131 attribute was present in the request, or the agent was in the 2132 controlling role and the ICE-CONTROLLED attribute was present in 2133 the request, there is no conflict. 2135 A change in roles will require an agent to recompute pair priorities 2136 Section 5.7.2, since those priorities are a function of controlling 2137 and controlled role. The change in role will also impact whether the 2138 agent is responsible for selecting nominated pairs and generated 2139 updated offers upon conclusion of ICE. 2141 The remaining sections in Section 7.2.1 are followed if the server 2142 generated a successful response to the Binding Request, even if the 2143 agent changed roles. 2145 7.2.1.2. Computing Mapped Address 2147 For requests being received on a relayed candidate, the source 2148 transport address used for STUN processing (namely, generation of the 2149 XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the 2150 relay. That source transport address will be present in the REMOTE- 2151 ADDRESS attribute of a STUN Data Indication message, if the Binding 2152 Request was delivered through a Data Indication (a STUN relay 2153 delivers packets encapsulated in a Data Indication when no active 2154 destination is set). If the Binding Request was not encapsulated in 2155 a Data Indication, that source address is equal to the current active 2156 destination for the STUN relay session. 2158 7.2.1.3. Learning Peer Reflexive Candidates 2160 If the source transport address of the request does not match any 2161 existing remote candidates, it represents a new peer reflexive remote 2162 candidate. This candidate is constructed as follows: 2164 o The priority of the candidate is set to the PRIORITY attribute 2165 from the request. 2167 o The type of the candidate is set to peer reflexive. 2169 o The foundation of the candidate is set to an arbitrary value, 2170 different from the foundation for all other remote candidates. If 2171 any subsequent offer/answer exchanges contain this peer reflexive 2172 candidate in the SDP, it will signal the actual foundation for the 2173 candidate. 2175 o The component ID of this candidate is set to the component ID for 2176 the local candidate to which the request was sent. 2178 This candidate is added to the list of remote candidates. However, 2179 the agent does not pair this candidate with any local candidates. 2181 7.2.1.4. Triggered Checks 2183 Next, the agent constructs a pair whose local candidate is equal to 2184 the transport address on which the STUN request was received, and a 2185 remote candidate equal to the source transport address where the 2186 request came from (which may be peer-reflexive remote candidate that 2187 was just learned). Since both candidates are known to the agent, it 2188 can obtain their priorities and compute the candidate pair priority. 2189 This pair is then looked up in the check list. There can be one of 2190 several outcomes: 2192 o If the pair is already on the check list: 2194 * If the state of that pair is Waiting or Frozen, a check for 2195 that pair is enqueued into the triggered check queue. 2197 * If the state of that pair is In-Progress, the agent cancels the 2198 in-progress transaction. Cancellation means that the agent 2199 will not retransmit the request, will not treat the lack of 2200 response to be a failure, but will wait the duration of the 2201 transaction timeout for a response. In addition, the agent 2202 MUST create a new connectivity check for that pair 2203 (representing a new STUN Binding Request transaction) by 2204 enqueueing the pair in the triggered check queue. The state of 2205 the pair is then changed to Waiting. 2207 * If the state of the pair is Failed, it is changed to Waiting 2208 and the agent MUST create a new connectivity check for that 2209 pair (representing a new STUN Binding Request transaction), by 2210 enqueueing the pair in the triggered check queue. 2212 * If the state of that pair is Succeeded, nothing further is 2213 done. 2215 o These steps are done to facilitate rapid completion of ICE when 2216 both agents are behind NAT. 2218 o If the pair is not already on the check list: 2220 * The pair is inserted into the check list based on its priority 2222 * Its state is set to Waiting 2224 * The pair is enqueued into the triggered check queue. 2226 When a triggered check is to be sent, it is constructed and processed 2227 as described in Section 7.1.1. These procedures require the agent to 2228 know the transport address, username fragment and password for the 2229 peer. The username fragment for the remote candidate is equal to the 2230 part after the colon of the USERNAME in the Binding Request that was 2231 just received. Using that username fragment, the agent can check the 2232 SDP messages received from its peer (there may be more than one in 2233 cases of forking), and find this username fragment. The 2234 corresponding password is then selected. 2236 7.2.1.5. Updating the Nominated Flag 2238 If the Binding Request received by the agent had the USE-CANDIDATE 2239 attribute set, and the agent is in the controlled role, the agent 2240 looks at the state of the pair computed in Section 7.2.1.4: 2242 o If the state of this pair is Succeeded, it means that the check 2243 generated by this pair produced a successful response. This would 2244 have caused the agent to construct a valid pair when that success 2245 response was received (see Section 7.1.2.2.2). The agent now sets 2246 the nominated flag in the valid pair to true. This may end ICE 2247 processing for this media stream; see Section 8. 2249 o If the state of this pair is In-Progress, if its check produces a 2250 successful result, the resulting valid pair has its nominated flag 2251 set when the response arrives. This may end ICE processing for 2252 this media stream when it arrives; see Section 8. 2254 7.2.2. Additional Procedures for Lite Implementations 2256 If the check that was just received contained a USE-CANDIDATE 2257 attribute, the agent constructs a candidate pair whose local 2258 candidate is equal to the transport address on which the request was 2259 received, and whose remote candidate is equal to the source transport 2260 address of the request that was received. This candidate pair is 2261 assigned an arbitrary priority, and placed into a list of valid 2262 candidates called the valid list. The agent sets the nominated flag 2263 for that pair to true. ICE processing is considered complete for a 2264 media stream if the valid list contains a candidate pair for each 2265 component. 2267 8. Concluding ICE Processing 2269 This section describes how an agent completes ICE. 2271 8.1. Procedures for Full Implementations 2273 Concluding ICE involves nominating pairs by the controlling agent and 2274 updating of state machinery. 2276 8.1.1. Nominating Pairs 2278 The controlling agent nominates pairs to be selected by ICE by using 2279 one of two techniques: regular nomination or aggressive nomination. 2280 If its peer has a lite implementation, an agent MUST use a regular 2281 nomination algorithm. If its peer is using ICE options (present in 2282 an ice-options attribute from the peer) that the agent does not 2283 understand, the agent MUST use a regular nomination algorithm. If 2284 its peer is a full implementation and isn't using any ICE options or 2285 is using ICE options understood by the agent, the agent MAY use 2286 either the aggressive or the regular nomination algorithm. However, 2287 the regular algorithm is RECOMMENDED since it provides greater 2288 stability. 2290 8.1.1.1. Regular Nomination 2292 With regular nomination, the agent lets some number of checks 2293 complete, each of which omit the USE-CANDIDATE attribute. Once one 2294 or more checks complete successfully for a component of a media 2295 stream, valid pairs are generated and added to the valid list. The 2296 agent lets the checks continue until some stopping criteria is met, 2297 and then picks amongst the valid pairs based on an evaluation 2298 criteria. The criteria for stopping the checks and for evaluating 2299 the valid pairs is entirely a matter of local optimization. 2301 When the controlling agent selects the valid pair, it repeats the 2302 check that produced this valid pair (by enqueuing the pair that 2303 generated the check into the triggered check queue), this time with 2304 the USE-CANDIDATE attribute. This check should succeed (since the 2305 previous did), causing the nominated flag of that and only that pair 2306 to be set. Consequently, there will be only a single nominated pair 2307 in the valid list for each component, and when the state of the check 2308 list moves to completed, that exact pair is selected by ICE for 2309 sending and receiving media for that component. 2311 Regular nomination provides the most flexibility, since the agent has 2312 control over the stopping and selection criteria for checks. The 2313 only requirement is that the agent MUST eventually pick one and only 2314 one candidate pair and generate a check for that pair with the USE- 2315 CANDIDATE attribute present. Regular nomination also improves ICE's 2316 resilience to variations in implementation (see Section 14). Regular 2317 nomination is also more stable, allowing both agents to converge on a 2318 single pair for media without any transient selections, which can 2319 happen with the aggressive algorithm. The drawback of regular 2320 nomination is that it is guaranteed to increase latencies because it 2321 requires an additional check to be done. 2323 8.1.1.2. Aggressive Nomination 2325 With aggressive nomination, the controlling agent includes the USE- 2326 CANDIDATE attribute in every check it sends. Once the first check 2327 for a component succeeds, it will be added to the valid list, and 2328 have its nominated flag set. When all components have a nominated 2329 pair in the valid list, it will cause ICE processing to cease for 2330 this check list. However, because the agent included the USE- 2331 CANDIDATE attribute in all of its checks, another check may yet 2332 complete, causing another valid pair to have its nominated flag set. 2333 ICE always selects the highest priority nominated candidate pair from 2334 the valid list as the one used for media. Consequently, the selected 2335 pair may actually change briefly as ICE checks complete, resulting in 2336 a set of transient selections until it stabilizes. 2338 8.1.2. Updating States 2340 For both controlling and controlled agents, the state of ICE 2341 processing depends on the presence of nominated candidate pairs in 2342 the valid list and on the state of the check list. Note that, at any 2343 time, more than one of the following cases can apply: 2345 o If there are no nominated pairs in the valid list for a media 2346 stream and the state of the check list is Running, ICE processing 2347 continues. 2349 o If there is at least one nominated pair in the valid list for a 2350 media stream and the state of the check list is Running: 2352 * The agent MUST remove all Waiting and Frozen pairs in the check 2353 list and triggered check queue for the same component as the 2354 nominated pairs for that media stream 2356 * If an In-Progress pair in the check list is for the same 2357 component as a nominated pair, the agent SHOULD cease 2358 retransmissions for its check if its pair priority is lower 2359 than the lowest priority nominated pair for that component 2361 o Once there is at least one nominated pair in the valid list for 2362 every component of at least one media stream and the state of the 2363 check list is Running: 2365 * The agent MUST change the state of processing for its check 2366 list for that media stream to Completed. 2368 * The agent MUST continue to respond to any checks it may still 2369 receive for that media stream, and MUST perform triggered 2370 checks if required by the processing of Section 7.2. 2372 * The agent MAY begin transmitting media for this media stream as 2373 described in Section 11.1 2375 o Once the state of each check list is Completed: 2377 * The agent sets the state of ICE processing overall to 2378 Completed. 2380 * If an agent is controlling, it examines the highest priority 2381 nominated candidate pair for each component of each media 2382 stream. If any of those candidate pairs differ from the 2383 default candidate pairs in the most recent offer/answer 2384 exchange, the controlling agent MUST generate an updated offer 2385 as described in Section 9. If the controlling agent is using 2386 an aggressive nomination algorithm, this may result in several 2387 updated offers as the pairs selected for media change. An 2388 agent MAY delay sending the offer for a brief interval (one 2389 second is RECOMMENDED) in order to allow the selected pairs to 2390 stabilize. 2392 o If the state of the check list is Failed, ICE has not been able to 2393 complete for this media stream. The correct behavior depends on 2394 the state of the check lists for other media streams: 2396 * If all check lists are Failed, ICE processing overall is 2397 considered to be in the Failed state, and the agent SHOULD 2398 consider the session a failure, SHOULD NOT restart ICE, and the 2399 controlling agent SHOULD terminate the entire session. 2401 * If at least one of the check lists for other media streams is 2402 Completed, the controlling agent SHOULD remove the failed media 2403 stream from the session in its updated offer. 2405 * If none of the check lists for other media streams are 2406 Completed, but at least one is Running, the agent SHOULD let 2407 ICE continue. 2409 8.2. Procedures for Lite Implementations 2411 Concluding ICE for a lite implementation is relatively 2412 straightforward. There are two cases to consider: 2414 The implementation is lite, and its peer is full. 2416 The implementation is lite, and its peer is lite. 2418 The effect of ICE concluding is that the agent can free any allocated 2419 host candidates that were not utilized by ICE, as described in 2420 Section 8.3. 2422 8.2.1. Peer is Full 2424 In this case, the agent will receive connectivity checks from its 2425 peer. When an agent has received a connectivity check that includes 2426 the USE-CANDIDATE attribute for each component of a media stream, the 2427 state of ICE processing for that media stream moves from Running to 2428 Completed. When the state of ICE processing for all media streams is 2429 Completed, the state of ICE processing overall is Completed. 2431 The lite implementation will never itself determine that ICE 2432 processing has failed for a media stream; rather, the full peer will 2433 make that determination and then remove or restart the failed media 2434 stream in a subsequent offer. 2436 8.2.2. Peer is Lite 2438 Once the offer/answer exchange has completed, the controlling agent 2439 examines its own candidate pairs and those of its peer. For each 2440 media stream, it pairs up its own candidates with the candidates of 2441 its peer for that media stream. Two candidates are paired up when 2442 they are for the same component, utilize the same transport protocol 2443 (UDP in this specification), and are from the same IP address family 2444 (IPv4 or IPv6). If an implementation is IPv4 only, this will always 2445 produce a single pair per component. That pair is added to the Valid 2446 list and the state of ICE processing is set to Completed for each 2447 media stream and for ICE overall. 2449 If there is more than one pair per component: 2451 o The agent MUST select a pair based on local policy. Since this 2452 case only arises for IPv6, it is RECOMMENDED that an agent follow 2453 the procedures of RFC 3484 [12] to select a single pair. 2455 o The agent adds the selected pair for each component to the valid 2456 list. As described in Section 11.1, this will permit media to 2457 begin flowing. However, it is possible (and in fact likely) that 2458 both agents have chosen different pairs. 2460 o To reconcile this, the controlling agent MUST send an updated 2461 offer as described in Section 9.1.3, which will include the 2462 remote-candidates attribute. 2464 o The agent MUST NOT update the state of ICE processing when the 2465 offer is sent. If this subsequent offer completes, the 2466 controlling agent MUST change the state of ICE processing to 2467 Completed for all media streams, and the state of ICE processing 2468 overall to Completed. The states for the controlled agent are set 2469 based on the logic in Section 9.2.3. 2471 8.3. Freeing Candidates 2473 8.3.1. Full Implementation Procedures 2475 The procedures in Section 8 require that an agent continue to listen 2476 for STUN requests and continue to generate triggered checks for a 2477 media stream, even once processing for that stream completes. The 2478 rules in this section describe when it is safe for an agent to cease 2479 sending or receiving checks on a candidate that was not selected by 2480 ICE, and then free the candidate. 2482 When ICE is used with SIP, and an offer is forked to multiple 2483 recipients, ICE proceeds in parallel and independently with each 2484 answerer, all using the same local candidates. Once ICE processing 2485 has reached the Completed state for all peers for media streams using 2486 those candidates, the agent SHOULD wait an additional three seconds, 2487 and then it MAY cease responding to checks or generating triggered 2488 checks on that candidate. It MAY free the candidate at that time. 2489 Freeing of server reflexive candidates is never explicit; it happens 2490 by lack of a keepalive. The three second delay handles cases when 2491 aggressive nomination is used, and the selected pairs can quickly 2492 change after ICE has completed. 2494 8.3.2. Lite Implementations 2496 A lite implementation MAY free candidates not selected by ICE as soon 2497 as ICE processing has reached the completed state for all peers for 2498 all media streams using those candidates. 2500 9. Subsequent Offer/Answer Exchanges 2502 Either agent MAY generate a subsequent offer at any time allowed by 2503 RFC 3264 [4]. The rules in Section 8 will cause the controlling 2504 agent to send an updated offer at the conclusion of ICE processing 2505 when ICE has selected different candidate pairs from the default 2506 pairs. This section defines rules for construction of subsequent 2507 offers and answers. 2509 Should a subsequent offer be rejected, ICE processing continues as if 2510 the subsequent offer had never been made. 2512 9.1. Generating the Offer 2514 9.1.1. Procedures for All Implementations 2516 9.1.1.1. ICE Restarts 2518 An agent MAY restart ICE processing for an existing media stream. An 2519 ICE restart, as the name implies, will cause all previous state of 2520 ICE processing to be flushed and checks to start anew. The only 2521 difference between an ICE restart and a brand new media session is 2522 that, during the restart, media can continue to be sent to the 2523 previously validated pair. 2525 An agent MUST restart ICE for a media stream if: 2527 o The offer is being generated for the purposes of changing the 2528 target of the media stream. In other words, if an agent wants to 2529 generated an updated offer which, had ICE not been in use, would 2530 result in a new value for the destination of a media component. 2532 o An agent is changing its implementation level. This typically 2533 only happens in third party call control use cases, where the 2534 entity performing the signaling is not the entity receiving the 2535 media, and it has changed the target of media mid-session to 2536 another entity that has a different ICE implementation. 2538 These rules imply that setting the IP address in the c line to 2539 0.0.0.0 will cause an ICE restart. Consequently, ICE implementations 2540 MUST NOT utilize this mechanism for call hold, and instead MUST use 2541 a=inactive and a=sendonly as described in [4] 2543 To restart ICE, an agent MUST change both the ice-pwd and the ice- 2544 ufrag for the media stream in an offer. Note that it is permissible 2545 to use a session-level attribute in one offer, but to provide the 2546 same ice-pwd or ice-ufrag as a media-level attribute in a subsequent 2547 offer. This is not a change in password, just a change in its 2548 representation, and does not cause an ICE restart. 2550 An agent sets the rest of the fields in the SDP for this media stream 2551 as it would in an initial offer of this media stream (see 2552 Section 4.3). Consequently, the set of candidates MAY include some, 2553 none, or all of the previous candidates for that stream and MAY 2554 include a totally new set of candidates gathered as described in 2555 Section 4.1.1. 2557 9.1.1.2. Removing a Media Stream 2559 If an agent removes a media stream by setting its port to zero, it 2560 MUST NOT include any candidate attributes for that media stream and 2561 SHOULD NOT include any other ICE-related attributes defined in 2562 Section 15 for that media stream. 2564 9.1.1.3. Adding a Media Stream 2566 If an agent wishes to add a new media stream, it sets the fields in 2567 the SDP for this media stream as if this was an initial offer for 2568 that media stream (see Section 4.3). This will cause ICE processing 2569 to begin for this media stream. 2571 9.1.2. Procedures for Full Implementations 2573 This section describes additional procedures for full 2574 implementations, covering existing media streams. 2576 The username fragments, password, and implementation level MUST 2577 remain the same as used previously. If an agent needs to change one 2578 of these it MUST restart ICE for that media stream. 2580 Additional behavior depends on the state ICE processing for that 2581 media stream. 2583 9.1.2.1. Existing Media Streams with ICE Running 2585 If an agent generates an updated offer including media stream that 2586 was previously established, and for which ICE checks are in the 2587 Running state, the agent follows the procedures defined here. 2589 An agent MUST include candidate attributes for all local candidates 2590 it had signaled previously for that media stream. The properties of 2591 that candidate as signaled in SDP - the priority, foundation, type 2592 and related transport address SHOULD remain the same. The IP 2593 address, port and transport protocol, which fundamentally identify 2594 that candidate, MUST remain the same (if they change, it would be a 2595 new candidate). The component ID MUST remain the same. The agent 2596 MAY include additional candidates it did not offer previously, but 2597 which it has gathered since the last offer/answer exchange, including 2598 peer reflexive candidates. 2600 The agent MAY change the default destination for media. As with 2601 initial offers, there MUST be a set of candidate attributes in the 2602 offer matching this default destination. 2604 9.1.2.2. Existing Media Streams with ICE Completed 2606 If an agent generates an updated offer including media stream that 2607 was previously established, and for which ICE checks are in the 2608 Completed state, the agent follows the procedures defined here. 2610 The default destination for media (i.e., the values of the IP 2611 addresses and ports in the m and c line used for that media stream) 2612 MUST be the local candidate from the highest priority nominated pair 2613 in the valid list for each component. This "fixes" the default 2614 destination for media to equal the destination ICE has selected for 2615 media. 2617 The agent MUST include a candidate attributes for candidates matching 2618 the default destination for each component of the media stream, and 2619 MUST NOT include any other candidates. 2621 In addition, if the agent is controlling, it MUST include the 2622 a=remote-candidates attribute for each media stream whose check list 2623 is in the Completed state. The attribute contains the remote 2624 candidates from the highest priority nominated pair in the valid list 2625 for each component of that media stream. It is needed to avoid a 2626 race condition whereby the controlling agent chooses its pairs, but 2627 the updated offer beats the connectivity checks to the controlled 2628 agent, which doesn't even know these pairs are valid, let alone 2629 selected. See Appendix B.6 for elaboration on this race condition. 2631 9.1.3. Procedures for Lite Implementations 2632 9.1.3.1. Existing Media Streams with ICE Running 2634 This section describes procedures for lite implementations for 2635 existing streams for which ICE is running. 2637 A lite implementation MUST include all of its candidates for each 2638 component of each media stream in an a=candidate attribute in any 2639 subsequent offer. These candidates are formed identically to the 2640 procedures for initial offers, as described in Section 4.2. 2642 A lite implementation MUST NOT add additional host candidates in a 2643 subsequent offer. If an agent needs to offer additional candidates, 2644 it MUST restart ICE. 2646 The username fragments, password, and implementation level MUST 2647 remain the same as used previously. If an agent needs to change one 2648 of these it MUST restart ICE for that media stream. 2650 9.1.3.2. Existing Media Streams with ICE Completed 2652 If ICE has completed for a media stream, the default destination for 2653 that media stream MUST be set to the remote candidate of the 2654 candidate pair for that component in the valid list. For a lite 2655 implementation, there is always just a single candidate pair in the 2656 valid list for each component of a media stream. Additionally, the 2657 agent MUST include a candidate attribute for each default 2658 destination. 2660 Additionally, if the agent is controlling (which only happens when 2661 both agents are lite), the agent MUST include the a=remote-candidates 2662 attribute for each media stream. The attribute contains the remote 2663 candidates from the candidate pairs in the valid list (one pair for 2664 each component of each media stream). 2666 9.2. Receiving the Offer and Generating an Answer 2668 9.2.1. Procedures for All Implementations 2670 When receiving a subsequent offer within an existing session, an 2671 agent MUST re-apply the verification procedures in Section 5.1 2672 without regard to the results of verification from any previous 2673 offer/answer exchanges. Indeed, it is possible that a previous 2674 offer/answer exchange resulted in ICE not being used, but it is used 2675 as a consequence of a subsequent exchange. 2677 9.2.1.1. Detecting ICE Restart 2679 If the offer contained a change in the a=ice-ufrag or a=ice-pwd 2680 attributes compared to the previous SDP from the peer, it indicates 2681 that ICE is restarting for this media stream. If all media streams 2682 are restarting, than ICE is restarting overall. 2684 If ICE is restarting for a media stream: 2686 o The agent MUST change the a=ice-ufrag and a=ice-pwd attributes in 2687 the answer. 2689 o The agent MAY change its implementation level in the answer. 2691 An agent sets the rest of the fields in the SDP for this media stream 2692 as it would in an initial answer to this media stream (see 2693 Section 4.3). Consequently, the set of candidates MAY include some, 2694 none, or all of the previous candidates for that stream and MAY 2695 include a totally new set of candidates gathered as described in 2696 Section 4.1.1. 2698 9.2.1.2. New Media Stream 2700 If the offer contains a new media stream, the agent sets the fields 2701 in the answer as if it had received an initial offer containing that 2702 media stream (see Section 4.3). This will cause ICE processing to 2703 begin for this media stream. 2705 9.2.1.3. Removed Media Stream 2707 If an offer contains a media stream whose port is zero, the agent 2708 MUST NOT include any candidate attributes for that media stream in 2709 its answer and SHOULD NOT include any other ICE-related attributes 2710 defined in Section 15 for that media stream. 2712 9.2.2. Procedures for Full Implementations 2714 Unless the agent has detected an ICE restart from the offer, the 2715 username fragments, password, and implementation level MUST remain 2716 the same as used previously. If an agent needs to change one of 2717 these it MUST restart ICE for that media stream by generating an 2718 offer; ICE cannot be restarted in an answer. 2720 Additional behaviors depend on the state of ICE processing for that 2721 media stream. 2723 9.2.2.1. Existing Media Streams with ICE Running and no remote- 2724 candidates 2726 If ICE is running for a media stream, and the offer for that media 2727 stream lacked the remote-candidates attribute, the rules for 2728 construction of the answer are identical to those for the offerer as 2729 described in Section 9.1.2.1. 2731 9.2.2.2. Existing Media Streams with ICE Completed and no remote- 2732 candidates 2734 If ICE is Completed for a media stream, and the offer for that media 2735 stream lacked the remote-candidates attribute, the rules for 2736 construction of the answer are identical to those for the offerer as 2737 described in Section 9.1.2.2, except that the answerer MUST NOT 2738 include the a=remote-candidates attribute in the answer. 2740 9.2.2.3. Existing Media Streams and remote-candidates 2742 A controlled agent will receive an offer with the a=remote-candidates 2743 attribute for a media stream when its peer has concluded ICE 2744 processing for that media stream. This attribute is present in the 2745 offer to deal with a race condition between the receipt of the offer, 2746 and the receipt of the Binding Response which tells the answerer the 2747 candidate which will be selected by ICE. See Appendix B.6 for an 2748 explanation of this race condition. Consequently, processing of an 2749 offer with this attribute depends on the winner of the race. 2751 The agent forms a candidate pair for each component of the media 2752 stream by: 2754 o Setting the remote candidate equal to the offerers default 2755 destination for that component (e.g., the contents of the m and 2756 c-lines for RTP, and the a=rtcp attribute for RTCP) 2758 o Setting the local candidate equal to the transport address for 2759 that same component in the a=remote-candidates attribute in the 2760 offer. 2762 The agent then sees if each of these candidate pairs are present in 2763 the valid list. If a particular pair is not in the valid list, the 2764 check has "lost" the race. Call such a pair a "losing pair". 2766 The agent finds all the pairs in the check list whose remote 2767 candidates equal the remote candidate in the losing pair: 2769 o If none of the pairs are In-Progress, and at least one is Failed, 2770 it is most likely that a network failure, such as a network 2771 partition or serious packet loss, has occurred. The agent SHOULD 2772 generate an answer for this media stream as if the remote- 2773 candidates attribute had not been present, and then restart ICE 2774 for this stream. 2776 o If at least one of the pairs are In-Progress, the agent SHOULD 2777 wait for those checks to complete, and as each completes, redo the 2778 processing in this section until there are no losing pairs. 2780 Once there are no losing pairs, the agent can generate the answer. 2781 It MUST set the default destination for media to the candidates in 2782 the remote-candidates attribute from the offer (each of which will 2783 now be the local candidate of a candidate pair in the valid list). 2784 It MUST include a candidate attribute in the answer for each 2785 candidate in the remote-candidates attribute in the offer. 2787 9.2.3. Procedures for Lite Implementations 2789 If the received offer contains the remote-candidates attribute for a 2790 media stream, the agent forms a candidate pair for each component of 2791 the media stream by: 2793 o Setting the remote candidate equal to the offerers default 2794 destination for that component (e.g., the contents of the m and 2795 c-lines for RTP, and the a=rtcp attribute for RTCP) 2797 o Setting the local candidate equal to the transport address for 2798 that same component in the a=remote-candidates attribute in the 2799 offer. 2801 It then places those candidates into the Valid list for the media 2802 stream. The state of ICE processing for that media stream is set to 2803 Completed. 2805 Furthermore, if the agent believed it was controlling, but the offer 2806 contained the remote-candidates attribute, both agents believe they 2807 are controlling. In this case, both would have sent updated offers 2808 around the same time. However, the signaling protocol carrying the 2809 offer/answer exchanges will have resolved this glare condition, so 2810 that one agent is always the 'winner' by having its offer received 2811 before its peer has sent an offer. The winner takes the role of 2812 controlled, so that the loser (the answerer under consideration in 2813 this section MUST change its role to controlled. Consequently, if 2814 the agent was going to send an updated offer since, based on the 2815 rules in Section 8.2.2, it was controlling, it no longer needs to. 2817 Besides the potential role change, change in the Valid list, and 2818 state changes, the construction of the answer is performed 2819 identically to the construction of an offer as described in 2820 Section 9.1.3. 2822 9.3. Updating the Check and Valid Lists 2824 9.3.1. Procedures for Full Implementations 2826 9.3.1.1. ICE Restarts 2828 The agent MUST remember the highest priority nominated pairs in the 2829 Valid list for each component of the media stream, called the 2830 previous selected pairs, prior to the restart. The agent will 2831 continue to send media using these pairs, as described in 2832 Section 11.1. Once these destinations are noted, the agent MUST 2833 flush the valid and check lists, and then recompute the check list 2834 and its states as described in Section 5.7. 2836 9.3.1.2. New Media Stream 2838 If the offer/answer exchange added a new media stream, the agent MUST 2839 create a new check list for it (and an empty Valid list to start of 2840 course), as described in Section 5.7. 2842 9.3.1.3. Removed Media Stream 2844 If the offer/answer exchange removed a media stream, or an answer 2845 rejected an offered media stream, an agent MUST flush the Valid list 2846 for that media stream. It MUST terminate any STUN transactions in 2847 progress for that media stream. An agent MUST remove the check list 2848 for that media stream and cancel any pending ordinary checks for it. 2850 9.3.1.4. ICE Continuing for Existing Media Stream 2852 The valid list is not affected by an updated offer/answer exchange 2853 unless ICE is restarting. 2855 If an agent is in the Running state for that media stream, the check 2856 list is updated (the check list is irrelevant if the state is 2857 completed). To do that, the agent recomputes the check list using 2858 the procedures described in Section 5.7. If a pair on the new check 2859 list was also on the previous check list, and its state was Waiting, 2860 In-Progress, Succeeded or Failed, its state is copied over. 2861 Otherwise, its state is set to Frozen. 2863 If none of the check lists are active (meaning that the pairs in each 2864 check list are Frozen), the full-mode agent sets the first pair in 2865 the check list for the first media stream to Waiting, and then sets 2866 the state of all other pairs in that check list for the same 2867 component ID and with the same foundation to Waiting as well. 2869 Next, the agent goes through each check list, starting with the 2870 highest priority pair. If a pair has a state of Succeeded, and it 2871 has a component ID of 1, then all Frozen pairs in the same check list 2872 with the same foundation whose component IDs are not 1, have their 2873 state set to Waiting. If, for a particular check list, there are 2874 pairs for each component of that media stream in the Succeeded state, 2875 the agent moves the state of all Frozen pairs for the first component 2876 of all other media streams (and thus in different check lists) with 2877 the same foundation to Waiting. 2879 9.3.2. Procedures for Lite Implementations 2881 If ICE is restarting for a media stream, the agent MUST start a new 2882 Valid list for that media stream. It MUST remember the pairs in the 2883 previous Valid list for each component of the media stream, called 2884 the previous selected pairs, and continue to send media there as 2885 described in Section 11.1. The state of ICE processing for each 2886 media stream MUST change to Running, and the state of ICE processing 2887 MUST change to running. 2889 10. Keepalives 2891 All endpoints MUST send keepalives for each media session. These 2892 keepalives serve the purpose of keeping NAT bindings alive for the 2893 media session. These keepalives MUST be sent regardless of whether 2894 the media stream is currently inactive, sendonly, recvonly or 2895 sendrecv, and regardless of the presence or value of the bandwidth 2896 attribute. These keepalives MUST be sent even if ICE is not being 2897 utilized for the session at all. The keepalive SHOULD be sent using 2898 a format which is supported by its peer. ICE endpoints allow for 2899 STUN-based keepalives for UDP streams, and as such, STUN keepalives 2900 MUST be used when an agent is communicating with a peer that supports 2901 ICE. An agent can determine that its peer supports ICE by the 2902 presence of a=candidate attributes for each media session. If the 2903 peer does not support ICE, the choice of a packet format for 2904 keepalives is a matter of local implementation. A format which 2905 allows packets to easily be sent in the absence of actual media 2906 content is RECOMMENDED. Examples of formats which readily meet this 2907 goal are RTP No-Op [32], and in cases where both sides support it, 2908 RTP comfort noise [26]. If the peer doesn't support any formats that 2909 are particularly well suited for keepalives, an agent SHOULD send RTP 2910 packets with an incorrect version number, or some other form of error 2911 which would cause them to be discarded by the peer. 2913 If there has been no packet sent on the candidate pair ICE is using 2914 for a media component for Tr seconds (where packets include those 2915 defined for the component (RTP or RTCP) and previous keepalives), an 2916 agent MUST generate a keepalive on that pair. Tr SHOULD be 2917 configurable and SHOULD have a default of 15 seconds. Alternatively, 2918 if an agent has a dynamic way to discover the binding lifetimes of 2919 the intervening NATs, it can use that value to determine Tr. 2921 If STUN is being used for keepalives, a STUN Binding Indication using 2922 the Indication Keepalive usage is used [13]. The Indication SHOULD 2923 NOT contain the ICE-CONTROLLING, ICE-CONTROLLED, PRIORITY or USE- 2924 CANDIDATE attributes defined in this document, as they are part of 2925 the connectivity check usage, not the Indication Keepalive usage. 2926 The Binding Indication is sent using the same local and remote 2927 candidates that are being used for media. Though Binding Indications 2928 are used for keepalives, an agent MUST be prepared to receive a 2929 connectivity check as well. If a connectivity check is received, a 2930 response is generated as discussed in [13], but there is no impact on 2931 ICE processing otherwise. 2933 An agent MUST begin the keepalive processing once ICE has selected 2934 candidates for usage with media, or media begins to flow, whichever 2935 happens first. Keepalives end once the session terminates or the 2936 media stream is removed. 2938 11. Media Handling 2940 11.1. Sending Media 2942 Procedures for sending media differ for full and lite 2943 implementations. 2945 11.1.1. Procedures for Full Implementations 2947 Agents always send media using a candidate pair, called the selected 2948 candidate pair. An agent will send media to the remote candidate in 2949 the selected pair (setting the destination address and port of the 2950 packet equal to that remote candidate), and will send it from the 2951 local candidate of the selected pair. When the local candidate is 2952 server or peer reflexive, media is originated from the base. Media 2953 sent from a relayed candidate is sent from the base through that 2954 relay, using procedures defined in [14]. 2956 The selected pair for a component of a media stream is: 2958 o empty if the state of the check list for that media stream is 2959 Running, and there is no previous selected pair for that component 2960 due to an ICE restart 2962 o equal to the previous selected pair for a component of a media 2963 stream if the state of the check list for that media stream is 2964 Running, and there was a previous selected pair for that component 2965 due to an ICE restart 2967 o equal to the highest priority nominated pair for that component in 2968 the valid list if the state of the check list is Completed 2970 If the selected pair for at least one component of a media stream is 2971 empty, an agent MUST NOT send media for any component of that media 2972 stream. If the selected pair for each component of a media stream 2973 has a value, an agent MAY send media for all components of that media 2974 stream. 2976 Note that the selected pair for a component of a media stream may not 2977 equal the default pair for that same component from the most recent 2978 offer/answer exchange. When this happens, the selected pair is used 2979 for media, not the default pair. When ICE first completes, if the 2980 selected pairs aren't a match for the default pairs, the controlling 2981 agent sends an updated offer/answer exchange to remedy this 2982 disparity. However, until that updated offer arrives, there will not 2983 be a match. Furthermore, in very unusual cases, the default 2984 candidates in the updated offer/answer will not be a match. 2986 11.1.2. Procedures for Lite Implementations 2988 A lite implementation MUST NOT send media until it has a Valid list 2989 that contains a candidate pair for each component of that media 2990 stream. Once that happens, the agent MAY begin sending media 2991 packets. To do that, it sends media to the remote candidate in the 2992 pair (setting the destination address and port of the packet equal to 2993 that remote candidate), and will send it from the local candidate. 2995 11.1.3. Procedures for All Implementations 2997 ICE has interactions with jitter buffer adaptation mechanisms. An 2998 RTP stream can begin using one candidate, and switch to another one, 2999 though this happens rarely with ICE. The newer candidate may result 3000 in RTP packets taking a different path through the network - one with 3001 different delay characteristics. As discussed below, agents are 3002 encouraged to re-adjust jitter buffers when there are changes in 3003 source or destination address of media packets. Furthermore, many 3004 audio codecs use the marker bit to signal the beginning of a 3005 talkspurt, for the purposes of jitter buffer adaptation. For such 3006 codecs, it is RECOMMENDED that the sender set the marker bit [23] 3007 when an agent switches transmission of media from one candidate pair 3008 to another. 3010 11.2. Receiving Media 3012 ICE implementations MUST be prepared to receive media on each 3013 component on any candidates provided for that component in the most 3014 recent offer/answer exchange (in the case of RTP, this would include 3015 both RTP and RTCP if candidates were provided for both). 3017 It is RECOMMENDED that, when an agent receives an RTP packet with a 3018 new source or destination IP address for a particular media stream, 3019 that the agent re-adjust its jitter buffers. 3021 RFC 3550 [23] describes an algorithm in Section 8.2 for detecting 3022 SSRC collisions and loops. These algorithms are based, in part, on 3023 seeing different source transport addresses with the same SSRC. 3024 However, when ICE is used, such changes will sometimes occur as the 3025 media streams switch between candidates. An agent will be able to 3026 determine that a media stream is from the same peer as a consequence 3027 of the STUN exchange that proceeds media transmission. Thus, if 3028 there is a change in source transport address, but the media packets 3029 come from the same peer agent, this SHOULD NOT be treated as an SSRC 3030 collision. 3032 12. Usage with SIP 3034 12.1. Latency Guidelines 3036 ICE requires a series of STUN-based connectivity checks to take place 3037 between endpoints. These checks start from the answerer on 3038 generation of its answer, and start from the offerer when it receives 3039 the answer. These checks can take time to complete, and as such, the 3040 selection of messages to use with offers and answers can effect 3041 perceived user latency. Two latency figures are of particular 3042 interest. These are the post-pickup delay and the post-dial delay. 3043 The post-pickup delay refers to the time between when a user "answers 3044 the phone" and when any speech they utter can be delivered to the 3045 caller. The post-dial delay refers to the time between when a user 3046 enters the destination address for the user, and ringback begins as a 3047 consequence of having successfully started ringing the phone of the 3048 called party. 3050 Two cases can be considered - one where the offer is present in the 3051 initial INVITE, and one where it is in a response. 3053 12.1.1. Offer in INVITE 3055 To reduce post-dial delays, it is RECOMMENDED that the caller begin 3056 gathering candidates prior to actually sending its initial INVITE. 3058 This can be started upon user interface cues that a call is pending, 3059 such as activity on a keypad or the phone going offhook. 3061 If an offer is received in an INVITE request, the answerer SHOULD 3062 begin to gather its candidates on receipt of the offer and then 3063 generate an answer in a provisional response once it has completed 3064 that process. ICE requires that a provisional response with an SDP 3065 be transmitted reliably. This can be done through the existing PRACK 3066 mechanism [9], or through an optimization that is specific to ICE. 3067 With this optimization, provisional responses containing an SDP 3068 answer that begins ICE processing for one or more media streams can 3069 be sent reliably without RFC 3262. To do this, the agent retransmits 3070 the provisional response with the exponential backoff timers 3071 described in RFC 3262. Retransmits MUST cease on receipt of a STUN 3072 Binding Request for one of the media streams signaled in that SDP 3073 (because receipt of a binding request indicates the offerer has 3074 received the answer) or on transmission of the answer in a 2xx 3075 response. If the peer agent is lite, there will never be a STUN 3076 Binding Request. In such a case, the agent MUST cease retransmitting 3077 the 18x after sending it four times (ICE will actually work even if 3078 the peer never receives the 18x; however, experience has shown that 3079 sending it is important for middleboxes and firewall traversal). If 3080 no Binding Request is received prior to the last retransmit, the 3081 agent does not consider the session terminated. Despite the fact 3082 that the provisional response will be delivered reliably, the rules 3083 for when an agent can send an updated offer or answer do not change 3084 from those specified in RFC 3262. Specifically, if the INVITE 3085 contained an offer, the same answer appears in all of the 1xx and in 3086 the 2xx response to the INVITE. Only after that 2xx has been sent 3087 can an updated offer/answer exchange occur. This optimization SHOULD 3088 NOT be used if both agents support PRACK. Note that the optimization 3089 is very specific to provisional response carrying answers that start 3090 ICE processing; it is not a general technique for 1xx reliability. 3092 Alternatively, an agent MAY delay sending an answer until the 200 OK, 3093 however this results in a poor user experience and is NOT 3094 RECOMMENDED. 3096 Once the answer has been sent, the agent SHOULD begin its 3097 connectivity checks. Once candidate pairs for each component of a 3098 media stream enter the valid list, the answerer can begin sending 3099 media on that media stream. 3101 However, prior to this point, any media that needs to be sent towards 3102 the caller (such as SIP early media [27] MUST NOT be transmitted. 3103 For this reason, implementations SHOULD delay alerting the called 3104 party until candidates for each component of each media stream have 3105 entered the valid list. In the case of a PSTN gateway, this would 3106 mean that the setup message into the PSTN is delayed until this 3107 point. Doing this increases the post-dial delay, but has the effect 3108 of eliminating 'ghost rings'. Ghost rings are cases where the called 3109 party hears the phone ring, picks up, but hears nothing and cannot be 3110 heard. This technique works without requiring support for, or usage 3111 of, preconditions [6], since its a localized decision. It also has 3112 the benefit of guaranteeing that not a single packet of media will 3113 get clipped, so that post-pickup delay is zero. If an agent chooses 3114 to delay local alerting in this way, it SHOULD generate a 180 3115 response once alerting begins. 3117 12.1.2. Offer in Response 3119 In addition to uses where the offer is in an INVITE, and the answer 3120 is in the provisional and/or 200 OK response, ICE works with cases 3121 where the offer appears in the response. In such cases, which are 3122 common in third party call control [19], ICE agents SHOULD generate 3123 their offers in a reliable provisional response (which MUST utilize 3124 RFC 3262), and not alert the user on receipt of the INVITE. The 3125 answer will arrive in a PRACK. This allows for ICE processing to 3126 take place prior to alerting, so that there is no post-pickup delay, 3127 at the expense of increased call setup delays. Once ICE completes, 3128 the callee can alert the user and then generate a 200 OK when they 3129 answer. The 200 OK would contain no SDP, since the offer/answer 3130 exchange has completed. 3132 Alternatively, agents MAY place the offer in a 2xx instead (in which 3133 case the answer comes in the ACK). When this happens, the callee 3134 will alert the user on receipt of the INVITE, and the ICE exchanges 3135 will take place only after the user answers. This has the effect of 3136 reducing call setup delay, but can cause substantial post-pickup 3137 delays and media clipping. 3139 12.2. SIP Option Tags and Media Feature Tags 3141 [15] specifies a SIP option tag and media feature tag for usage with 3142 ICE. ICE implementations using SIP SHOULD support this 3143 specification, which uses a feature tag in registrations to 3144 facilitate interoperability through intermediaries. 3146 12.3. Interactions with Forking 3148 ICE interacts very well with forking. Indeed, ICE fixes some of the 3149 problems associated with forking. Without ICE, when a call forks and 3150 the caller receives multiple incoming media streams, it cannot 3151 determine which media stream corresponds to which callee. 3153 With ICE, this problem is resolved. The connectivity checks which 3154 occur prior to transmission of media carry username fragments, which 3155 in turn are correlated to a specific callee. Subsequent media 3156 packets which arrive on the same candidate pair as the connectivity 3157 check will be associated with that same callee. Thus, the caller can 3158 perform this correlation as long as it has received an answer. 3160 12.4. Interactions with Preconditions 3162 Quality of Service (QoS) preconditions, which are defined in RFC 3312 3163 [6] and RFC 4032 [7], apply only to the transport addresses listed as 3164 the default targets for media in an offer/answer. If ICE changes the 3165 transport address where media is received, this change is reflected 3166 in an updated offer which changes the default destination for media 3167 to match ICE's selection. As such, it appears like any other re- 3168 INVITE would, and is fully treated in RFC 3312 and 4032, which apply 3169 without regard to the fact that the destination for media is changing 3170 due to ICE negotiations occurring "in the background". 3172 Indeed, an agent SHOULD NOT indicate that Qos preconditions have been 3173 met until the checks have completed and selected the candidate pairs 3174 to be used for media. 3176 ICE also has (purposeful) interactions with connectivity 3177 preconditions [31]. Those interactions are described there. Note 3178 that the procedures described in Section 12.1 describe their own type 3179 of "preconditions", albeit with less functionality than those 3180 provided by the explicit preconditions in [31]. 3182 12.5. Interactions with Third Party Call Control 3184 ICE works with Flows I, III and IV as described in [19]. Flow I 3185 works without the controller supporting or being aware of ICE. Flow 3186 IV will work as long as the controller passes along the ICE 3187 attributes without alteration. Flow II is fundamentally incompatible 3188 with ICE; each agent will believe itself to be the answerer and thus 3189 never generate a re-INVITE. 3191 The flows for continued operation, as described in Section 7 of RFC 3192 3725, require additional behavior of ICE implementations to support. 3193 In particular, if an agent receives a mid-dialog re-INVITE that 3194 contains no offer, it MUST restart ICE for each media stream and go 3195 through the process of gathering new candidates. Furthermore, that 3196 list of candidates SHOULD include the ones currently being used for 3197 media. 3199 13. Relationship with ANAT 3201 RFC 4091 [11] defines a mechanism for indicating that an agent can 3202 support both IPv4 and IPv6 for a media stream, and it does so by 3203 including two m-lines, one for v4, and one for v6. This is similar 3204 to ICE, which allows for an agent to indicate multiple transport 3205 addresses using the candidate attribute. However, ANAT relies on 3206 static selection to pick between choices, rather than a dynamic 3207 connectivity check used by ICE. 3209 This specification deprecates RFC 4091. Instead, agents wishing to 3210 support dual-stack will utilize ICE. Because a dual-stack agent will 3211 require at least two candidates, one for IPv4 and one for IPv6, dual- 3212 stack agents MUST be full implementations. However, agents that are 3213 implementing dual-stack and are running on closed networks where it 3214 is known that there are no NAT, MAY include only host candidates in 3215 their offers, skipping server reflexive and relayed candidates. 3217 14. Extensibility Considerations 3219 This specification makes very specific choices about how both agents 3220 in a session coordinate to arrive at the set of candidate pairs that 3221 are selected for media. It is anticipated that future specifications 3222 will want to alter these algorithms, whether they are simple changes 3223 like timer tweaks, or larger changes like a revamp of the priority 3224 algorithm. When such a change is made, providing interoperability 3225 between the two agents in a session is critical. 3227 First, ICE provides the a=ice-options SDP attribute. Each extension 3228 or change to ICE is associated with a token. When an agent 3229 supporting such an extension or change generates an offer or an 3230 answer, it MUST include the token for that extension in this 3231 attribute. This allows each side to know what the other side is 3232 doing. This attribute MUST NOT be present if the agent doesn't 3233 support any ICE extensions or changes. 3235 At this time, no IANA registry or registration procedures are defined 3236 for these option tags. At time of writing, it is unclear whether ICE 3237 changes and extensions will be sufficiently common to warrrant a 3238 registry. 3240 One of the complications in achieving interoperability is that ICE 3241 relies on a distributed algorithm running on both agents to converge 3242 on an agreed set of candidate pairs. If the two agents run different 3243 algorithms, it can be difficult to guarantee convergence on the same 3244 candidate pairs. The regular nomination procedure described in 3245 Section 8 eliminates some of the tight coordination by delegating the 3246 selection algorithm completely to the controlling agent. 3247 Consequently, when a controlling agent is communicating with a peer 3248 that supports options it doesn't know about, the agent MUST run a 3249 regular nomination algorithm. When regular nomination is used, ICE 3250 will converge perfectly even when both agents use different pair 3251 prioritization algorithms. One of the keys to such convergence are 3252 triggered checks, which ensure that the nominated pair is validated 3253 by both agents. Consequently, any future ICE enhancements MUST 3254 preserve triggered checks. 3256 ICE is also extensible to other media streams beyond RTP, and for 3257 transport protocols beyond UDP. Extensions to ICE for non-RTP media 3258 streams need to specify how many components they utilize, and assign 3259 component IDs to them, starting at 1 for the most important component 3260 ID. Specifications for new transport protocols must define how, if 3261 at all, various steps in the ICE processing differ from UDP. 3263 15. Grammar 3265 This specification defines seven new SDP attributes - the 3266 "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- 3267 ufrag", "ice-pwd" and "ice-options" attributes. 3269 15.1. "candidate" Attribute 3271 The candidate attribute is a media-level attribute only. It contains 3272 a transport address for a candidate that can be used for connectivity 3273 checks. 3275 The syntax of this attribute is defined using Augmented BNF as 3276 defined in RFC 4234 [8]: 3278 candidate-attribute = "candidate" ":" foundation SP component-id SP 3279 transport SP 3280 priority SP 3281 connection-address SP ;from RFC 4566 3282 port ;port from RFC 4566 3283 SP cand-type 3284 [SP rel-addr] 3285 [SP rel-port] 3286 *(SP extension-att-name SP 3287 extension-att-value) 3289 foundation = 1*32ice-char 3290 component-id = 1*5DIGIT 3291 transport = "UDP" / transport-extension 3292 transport-extension = token ; from RFC 3261 3293 priority = 1*10DIGIT 3294 cand-type = "typ" SP candidate-types 3295 candidate-types = "host" / "srflx" / "prflx" / "relay" / token 3296 rel-addr = "raddr" SP connection-address 3297 rel-port = "rport" SP port 3298 extension-att-name = byte-string ;from RFC 4566 3299 extension-att-value = byte-string 3300 ice-char = ALPHA / DIGIT / "+" / "/" 3302 This grammar encodes the primary information about a candidate: its 3303 IP address, port and transport protocol, and its properties: the 3304 foundation, component ID, priority, type, and related transport 3305 address: 3307 : is taken from RFC 4566 [10]. It is the IP 3308 address of the candidate, allowing for IPv4 addresses, IPv6 3309 addresses and FQDNs. An IP address SHOULD be used, but an FQDN 3310 MAY be used in place of an IP address. In that case, when 3311 receiving an offer or answer containing an FQDN in an a=candidate 3312 attribute, the FQDN is looked up in the DNS first using an AAAA 3313 record (assuming the agent supports IPv6), and if no result is 3314 found or the agent only supports IPv4, using an A. If the DNS 3315 query returns more than one IP address, one is chosen, and then 3316 used for the remainder of ICE processing. 3318 : is also taken from RFC 4566 [10]. It is the port of the 3319 candidate. 3321 : indicates the transport protocol for the candidate. 3322 This specification only defines UDP. However, extensibility is 3323 provided to allow for future transport protocols to be used with 3324 ICE, such as TCP or the Datagram Congestion Control Protocol 3325 (DCCP) [34]. 3327 : is composed of one to thirty two . It is an 3328 identifier that is equivalent for two candidates that are of the 3329 same type, share the same base, and come from the same STUN 3330 server. The foundation is used to optimize ICE performance in the 3331 Frozen algorithm. 3333 : is a positive integer between 1 and 256 which 3334 identifies the specific component of the media stream for which 3335 this is a candidate. It MUST start at 1 and MUST increment by 1 3336 for each component of a particular candidate. For media streams 3337 based on RTP, candidates for the actual RTP media MUST have a 3338 component ID of 1, and candidates for RTCP MUST have a component 3339 ID of 2. Other types of media streams which require multiple 3340 components MUST develop specifications which define the mapping of 3341 components to component IDs. See Section 14 for additional 3342 discussion on extending ICE to new media streams. 3344 : is a positive integer between 1 and (2**32 - 1). 3346 : encodes the type of candidate. This specification 3347 defines the values "host", "srflx", "prflx" and "relay" for host, 3348 server reflexive, peer reflexive and relayed candidates, 3349 respectively. The set of candidate types is extensible for the 3350 future. 3352 and : convey transport addresses related to the 3353 candidate, useful for diagnostics and other purposes. 3354 and MUST be present for server reflexive, peer 3355 reflexive and relayed candidates. If a candidate is server or 3356 peer reflexive, and is equal to the base for 3357 that server or peer reflexive candidate. If the candidate is 3358 relayed, and is equal to the mapped address 3359 in the Allocate Response that provided the client with that 3360 relayed candidate (see Appendix B.3 for a discussion of its 3361 purpose). If the candidate is a host candidate and 3362 MUST be omitted. 3364 The candidate attribute can itself be extended. The grammar allows 3365 for new name/value pairs to be added at the end of the attribute. An 3366 implementation MUST ignore any name/value pairs it doesn't 3367 understand. 3369 15.2. "remote-candidates" Attribute 3371 The syntax of the "remote-candidates" attribute is defined using 3372 Augmented BNF as defined in RFC 4234 [8]. The remote-candidates 3373 attribute is a media level attribute only. 3375 remote-candidate-att = "remote-candidates" ":" remote-candidate 3376 0*(SP remote-candidate) 3377 remote-candidate = component-ID SP connection-address SP port 3379 The attribute contains a connection-address and port for each 3380 component. The ordering of components is irrelevant. However, a 3381 value MUST be present for each component of a media stream. This 3382 attribute MUST be included in an offer by a controlling agent for a 3383 media stream that is Completed, and MUST NOT be included in any other 3384 case. 3386 15.3. "ice-lite" and "ice-mismatch" Attributes 3388 The syntax of the "ice-lite" and "ice-mismatch" attributes, both of 3389 which are flags, is: 3391 ice-lite = "ice-lite" 3392 ice-mismatch = "ice-mismatch" 3394 "ice-lite" is a session level attribute only, and indicates that an 3395 agent is a lite implementation. "ice-mismatch" is a media level 3396 attribute only, and when present in an answer, indicates that the 3397 offer arrived with a default destination for a media component that 3398 didn't have a corresponding candidate attribute. 3400 15.4. "ice-ufrag" and "ice-pwd" Attributes 3402 The "ice-ufrag" and "ice-pwd" attributes convey the username fragment 3403 and password used by ICE for message integrity. Their syntax is: 3405 ice-pwd-att = "ice-pwd" ":" password 3406 ice-ufrag-att = "ice-ufrag" ":" ufrag 3407 password = 22*1024ice-char 3408 ufrag = 4*1024ice-char 3410 The "ice-pwd" and "ice-ufrag" attributes can appear at either the 3411 session-level or media-level. When present in both, the value in the 3412 media-level takes precedence. Thus, the value at the session level 3413 is effectively a default that applies to all media streams, unless 3414 overriden by a media-level value. Whether present at the session or 3415 media level, there MUST be an ice-pwd and ice-ufrag attribute for 3416 each media stream. If two media streams have identical ice-ufrag's, 3417 they MUST have identical ice-pwd's. 3419 The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the 3420 beginning of a session. The ice-ufrag attribute MUST contain at 3421 least 24 bits of randomness, and the ice-pwd attribute MUST contain 3422 at least 128 bits of randomness. This means that the ice-ufrag 3423 attribute will be at least 4 characters long, and the ice-pwd at 3424 least 22 characters long, since the grammar for these attributes 3425 allows for 6 bits of randomness per character. The attributes MAY be 3426 longer than 4 and 22 characters respectively, of course, up to 1024 3427 characters. The upper limit allows for buffer sizing in 3428 implementations. Its large upper limit allows for increased amounts 3429 of randomness to be added over time. 3431 15.5. "ice-options" Attribute 3433 The "ice-options" attribute is a session level attribute. It 3434 contains a series of tokens which identify the options supported by 3435 the agent. Its grammar is: 3437 ice-options = "ice-options" ":" ice-option-tag 3438 0*(SP ice-option-tag) 3439 ice-option-tag = 1*ice-char 3441 16. Example 3443 The example is based on the simplified topology of Figure 19. 3445 +-----+ 3446 | | 3447 |STUN | 3448 | Srvr| 3449 +-----+ 3450 | 3451 +---------------------+ 3452 | | 3453 | Internet | 3454 | | 3455 | | 3456 +---------------------+ 3457 | | 3458 | | 3459 +---------+ | 3460 | NAT | | 3461 +---------+ | 3462 | | 3463 | | 3464 | | 3465 +-----+ +-----+ 3466 | | | | 3467 | L | | R | 3468 | | | | 3469 +-----+ +-----+ 3471 Figure 19: Example Topology 3473 Two agents, L and R, are using ICE. Both are full-mode ICE 3474 implementations. Both agents have a single IPv4 interface. For 3475 agent L, it is 10.0.1.1 in private address space [29], and for agent 3476 R, 192.0.2.1 on the public Internet. Both are configured with the 3477 same STUN server (shown in this example for simplicity, although in 3478 practice the agents do not need to use the same STUN server), which 3479 is listening for STUN requests at an IP address of 192.0.2.2 and port 3480 3478. This STUN server supports only the Binding Discovery usage; 3481 relays are not used in this example. Agent L is behind a NAT, and 3482 agent R is on the public Internet. The NAT has an endpoint 3483 independent mapping property and an address dependent filtering 3484 property. The public side of the NAT has an IP address of 192.0.2.3. 3486 To facilitate understanding, transport addresses are listed using 3487 variables that have mnemonic names. The format of the name is 3488 entity-type-seqno, where entity refers to the entity whose interface 3489 the transport address is on, and is one of "L", "R", "STUN", or 3490 "NAT". The type is either "PUB" for transport addresses that are 3491 public, and "PRIV" for transport addresses that are private. 3492 Finally, seq-no is a sequence number that is different for each 3493 transport address of the same type on a particular entity. Each 3494 variable has an IP address and port, denoted by varname.IP and 3495 varname.PORT, respectively, where varname is the name of the 3496 variable. 3498 The STUN server has advertised transport address STUN-PUB-1 (which is 3499 192.0.2.2:3478) for the binding discovery usage. 3501 In the call flow itself, STUN messages are annotated with several 3502 attributes. The "S=" attribute indicates the source transport 3503 address of the message. The "D=" attribute indicates the destination 3504 transport address of the message. The "MA=" attribute is used in 3505 STUN Binding Response messages and refers to the mapped address. 3506 "USE-CAND" implies the presence of the USE-CANDIDATE attribute. 3508 The call flow examples omit STUN authentication operations and RTCP, 3509 and focus on RTP for a single media stream between two full 3510 implementations. 3512 L NAT STUN R 3513 |RTP STUN alloc. | | 3514 |(1) STUN Req | | | 3515 |S=$L-PRIV-1 | | | 3516 |D=$STUN-PUB-1 | | | 3517 |------------->| | | 3518 | |(2) STUN Req | | 3519 | |S=$NAT-PUB-1 | | 3520 | |D=$STUN-PUB-1 | | 3521 | |------------->| | 3522 | |(3) STUN Res | | 3523 | |S=$STUN-PUB-1 | | 3524 | |D=$NAT-PUB-1 | | 3525 | |MA=$NAT-PUB-1 | | 3526 | |<-------------| | 3527 |(4) STUN Res | | | 3528 |S=$STUN-PUB-1 | | | 3529 |D=$L-PRIV-1 | | | 3530 |MA=$NAT-PUB-1 | | | 3531 |<-------------| | | 3532 |(5) Offer | | | 3533 |------------------------------------------->| 3534 | | | |RTP STUN alloc. 3535 | | |(6) STUN Req | 3536 | | |S=$R-PUB-1 | 3537 | | |D=$STUN-PUB-1 | 3538 | | |<-------------| 3539 | | |(7) STUN Res | 3540 | | |S=$STUN-PUB-1 | 3541 | | |D=$R-PUB-1 | 3542 | | |MA=$R-PUB-1 | 3543 | | |------------->| 3544 |(8) answer | | | 3545 |<-------------------------------------------| 3546 | |(9) Bind Req | | 3547 | |S=$R-PUB-1 | | 3548 | |D=L-PRIV-1 | | 3549 | |<----------------------------| 3550 | |Dropped | | 3551 |(10) Bind Req | | | 3552 |S=$L-PRIV-1 | | | 3553 |D=$R-PUB-1 | | | 3554 |USE-CAND | | | 3555 |------------->| | | 3556 | |(11) Bind Req | | 3557 | |S=$NAT-PUB-1 | | 3558 | |D=$R-PUB-1 | | 3559 | |USE-CAND | | 3560 | |---------------------------->| 3561 | |(12) Bind Res | | 3562 | |S=$R-PUB-1 | | 3563 | |D=$NAT-PUB-1 | | 3564 | |MA=$NAT-PUB-1 | | 3565 | |<----------------------------| 3566 |(13) Bind Res | | | 3567 |S=$R-PUB-1 | | | 3568 |D=$L-PRIV-1 | | | 3569 |MA=$NAT-PUB-1 | | | 3570 |<-------------| | | 3571 |RTP flows | | | 3572 | |(14) Bind Req | | 3573 | |S=$R-PUB-1 | | 3574 | |D=$NAT-PUB-1 | | 3575 | |<----------------------------| 3576 |(15) Bind Req | | | 3577 |S=$R-PUB-1 | | | 3578 |D=$L-PRIV-1 | | | 3579 |<-------------| | | 3580 |(16) Bind Res | | | 3581 |S=$L-PRIV-1 | | | 3582 |D=$R-PUB-1 | | | 3583 |MA=$R-PUB-1 | | | 3584 |------------->| | | 3585 | |(17) Bind Res | | 3586 | |S=$NAT-PUB-1 | | 3587 | |D=$R-PUB-1 | | 3588 | |MA=$R-PUB-1 | | 3589 | |---------------------------->| 3590 | | | |RTP flows 3592 Figure 20: Example Flow 3594 First, agent L obtains a host candidate from its local interface (not 3595 shown), and from that, sends a STUN Binding Request to the STUN 3596 server to get a server reflexive candidate (messages 1-4). Recall 3597 that the NAT has the address and port independent mapping property. 3598 Here, it creates a binding of NAT-PUB-1 for this UDP request, and 3599 this becomes the server reflexive candidate for RTP. 3601 Agent L sets a type preference of 126 for the host candidate and 100 3602 for the server reflexive. The local preference is 65535. Based on 3603 this, the priority of the host candidate is 2130706431 and for the 3604 server reflexive candidate is 1694498815. The host candidate is 3605 assigned a foundation of 1, and the server reflexive, a foundation of 3606 2. It chooses its server reflexive candidate as the default 3607 candidate, and encodes it into the m and c lines. The resulting 3608 offer (message 5) looks like (lines folded for clarity): 3610 v=0 3611 o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP 3612 s= 3613 c=IN IP4 $NAT-PUB-1.IP 3614 t=0 0 3615 a=ice-pwd:asd88fgpdd777uzjYhagZg 3616 a=ice-ufrag:8hhY 3617 m=audio $NAT-PUB-1.PORT RTP/AVP 0 3618 b=RS:0 3619 b=RR:0 3620 a=rtpmap:0 PCMU/8000 3621 a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ host 3622 a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ 3623 srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT 3625 The offer, with the variables replaced with their values, will look 3626 like (lines folded for clarity): 3628 v=0 3629 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 3630 s= 3631 c=IN IP4 192.0.2.3 3632 t=0 0 3633 a=ice-pwd:asd88fgpdd777uzjYhagZg 3634 a=ice-ufrag:8hhY 3635 m=audio 45664 RTP/AVP 0 3636 b=RS:0 3637 b=RR:0 3638 a=rtpmap:0 PCMU/8000 3639 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 3640 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 3641 10.0.1.1 rport 8998 3643 This offer is received at agent R. Agent R will obtain a host 3644 candidate, and from it, obtain a server reflexive candidate (messages 3645 6-7). Since R is not behind a NAT, this candidate is identical to 3646 its host candidate, and they share the same base. It therefore 3647 discards this redundant candidate and ends up with a single host 3648 candidate. With identical type and local preferences as L, the 3649 priority for this candidate is 2130706431. It chooses a foundation 3650 of 1 for its single candidate. Its resulting answer looks like: 3652 v=0 3653 o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP 3654 s= 3655 c=IN IP4 $R-PUB-1.IP 3656 t=0 0 3657 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 3658 a=ice-ufrag:9uB6 3659 m=audio $R-PUB-1.PORT RTP/AVP 0 3660 b=RS:0 3661 b=RR:0 3662 a=rtpmap:0 PCMU/8000 3663 a=candidate:1 1 UDP 2130706431 $R-PUB-1.IP $R-PUB-1.PORT typ host 3665 With the variables filled in: 3667 v=0 3668 o=bob 2808844564 2808844564 IN IP4 192.0.2.1 3669 s= 3670 c=IN IP4 192.0.2.1 3671 t=0 0 3672 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 3673 a=ice-ufrag:9uB6 3674 m=audio 3478 RTP/AVP 0 3675 b=RS:0 3676 b=RR:0 3677 a=rtpmap:0 PCMU/8000 3678 a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host 3680 Since neither side indicated that they are lite, the agent which sent 3681 the offer that began ICE processing (agent L) becomes the controlling 3682 agent. 3684 Agents L and R both pair up the candidates. They both initially have 3685 two pairs. However, agent L will prune the pair containing its 3686 server reflexive candidate, resulting in just one. At agent L, this 3687 pair has a local candidate of $L_PRIV_1 and remote candidate of 3688 $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that 3689 an implementation would represent this as a 64 bit integer so as not 3690 to lose precision). At agent R, there are two pairs. The highest 3691 priority has a local candidate of $R_PUB_1 and remote candidate of 3692 $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a 3693 local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and 3694 priority 3.63891E+18. 3696 Agent R begins its connectivity check (message 9) for the first pair 3697 (between the two host candidates). Since R is the controlled agent 3698 for this session, the check omits the USE-CANDIDATE attribute. The 3699 host candidate from agent L is private and behind a NAT, and thus 3700 this check won't be successful, because the packet cannot be routed 3701 from R to L. 3703 When agent L gets the answer, it performs its one and only 3704 connectivity check (messages 10-13). It implements the aggressive 3705 nomination algorithm, and thus includes a USE-CANDIDATE attribute in 3706 this check. Since the check succeeds, agent L creates a new pair, 3707 whose local candidate is from the mapped address in the binding 3708 response (NAT-PUB-1 from message 13) and whose remote candidate is 3709 the destination of the request (R-PUB-1 from message 10). This is 3710 added to the valid list. In addition, it is marked as selected since 3711 the Binding Request contained the USE-CANDIDATE attribute. Since 3712 there is a selected candidate in the Valid list for the one component 3713 of this media stream, ICE processing for this stream moves into the 3714 Completed state. Agent L can now send media if it so chooses. 3716 Soon after receipt of the STUN Binding Request from agent L (message 3717 11), agent R will generate its triggered check. This check happens 3718 to match the next one on its check list - from its host candidate to 3719 agent L's server reflexive candidate. This check (messages 14-17) 3720 will succeed. Consequently, agent R constructs a new candidate pair 3721 using the mapped address from the response as the local candidate 3722 (R-PUB-1) and the destination of the request (NAT-PUB-1) as the 3723 remote candidate. This pair is added to the Valid list for that 3724 media stream. Since the check was generated in the reverse direction 3725 of a check that contained the USE-CANDIDATE attribute, the candidate 3726 pair is marked as selected. Consequently, processing for this stream 3727 moves into the Completed state, and agent R can also send media. 3729 17. Security Considerations 3731 There are several types of attacks possible in an ICE system. This 3732 section considers these attacks and their countermeasures. 3734 17.1. Attacks on Connectivity Checks 3736 An attacker might attempt to disrupt the STUN connectivity checks. 3737 Ultimately, all of these attacks fool an agent into thinking 3738 something incorrect about the results of the connectivity checks. 3739 The possible false conclusions an attacker can try and cause are: 3741 False Invalid: An attacker can fool a pair of agents into thinking a 3742 candidate pair is invalid, when it isn't. This can be used to 3743 cause an agent to prefer a different candidate (such as one 3744 injected by the attacker), or to disrupt a call by forcing all 3745 candidates to fail. 3747 False Valid: An attacker can fool a pair of agents into thinking a 3748 candidate pair is valid, when it isn't. This can cause an agent 3749 to proceed with a session, but then not be able to receive any 3750 media. 3752 False Peer-Reflexive Candidate: An attacker can cause an agent to 3753 discover a new peer reflexive candidate, when it shouldn't have. 3754 This can be used to redirect media streams to a DoS target or to 3755 the attacker, for eavesdropping or other purposes. 3757 False Valid on False Candidate: An attacker has already convinced an 3758 agent that there is a candidate with an address that doesn't 3759 actually route to that agent (for example, by injecting a false 3760 peer reflexive candidate or false server reflexive candidate). It 3761 must then launch an attack that forces the agents to believe that 3762 this candidate is valid. 3764 Of the various techniques for creating faked STUN messages described 3765 in [13], many are not applicable for the connectivity checks. 3766 Compromises of STUN servers are not much of a concern, since the STUN 3767 servers are embedded in endpoints and distributed throughout the 3768 network. Thus, compromising the peer's embedded STUN server is 3769 equivalent to comprimising the endpoint, and if that happens, far 3770 more problematic attacks are possible than those against ICE. 3771 Similarly, DNS attacks are usually irrelevant since STUN servers are 3772 not typically discovered via DNS, they are normally signaled via IP 3773 addresses embedded in SDP. If the SDP does contain an FQDN for a 3774 host, then connectivity checks would be susceptible to the DNS 3775 vulnerabilities described in [13]; however it is far more common to 3776 use IP addresses. Injection of fake responses and relaying modified 3777 requests all can be handled in ICE with the countermeasures discussed 3778 below. 3780 To force the false invalid result, the attacker has to wait for the 3781 connectivity check from one of the agents to be sent. When it is, 3782 the attacker needs to inject a fake response with an unrecoverable 3783 error response, such as a 600. However, since the candidate is, in 3784 fact, valid, the original request may reach the peer agent, and 3785 result in a success response. The attacker needs to force this 3786 packet or its response to be dropped, through a DoS attack, layer 2 3787 network disruption, or other technique. If it doesn't do this, the 3788 success response will also reach the originator, alerting it to a 3789 possible attack. Fortunately, this attack is mitigated completely 3790 through the STUN message integrity mechanism. The attacker needs to 3791 inject a fake response, and in order for this response to be 3792 processed, the attacker needs the password. If the offer/answer 3793 signaling is secured, the attacker will not have the password. 3795 Forcing the fake valid result works in a similar way. The agent 3796 needs to wait for the Binding Request from each agent, and inject a 3797 fake success response. The attacker won't need to worry about 3798 disrupting the actual response since, if the candidate is not valid, 3799 it presumably wouldn't be received anyway. However, like the fake 3800 invalid attack, this attack is mitigated completely through the STUN 3801 message integrity and offer/answer security techniques. 3803 Forcing the false peer reflexive candidate result can be done either 3804 with fake requests or responses, or with replays. We consider the 3805 fake requests and responses case first. It requires the attacker to 3806 send a Binding Request to one agent with a source IP address and port 3807 for the false candidate. In addition, the attacker must wait for a 3808 Binding Request from the other agent, and generate a fake response 3809 with a XOR-MAPPED-ADDRESS attribute containing the false candidate. 3810 Like the other attacks described here, this attack is mitigated by 3811 the STUN message integrity mechanisms and secure offer/answer 3812 exchanges. 3814 Forcing the false peer reflexive candidate result with packet replays 3815 is different. The attacker waits until one of the agents sends a 3816 check. It intercepts this request, and replays it towards the other 3817 agent with a faked source IP address. It must also prevent the 3818 original request from reaching the remote agent, either by launching 3819 a DoS attack to cause the packet to be dropped, or forcing it to be 3820 dropped using layer 2 mechanisms. The replayed packet is received at 3821 the other agent, and accepted, since the integrity check passes (the 3822 integrity check cannot and does not cover the source IP address and 3823 port). It is then responded to. This response will contain a XOR- 3824 MAPPED-ADDRESS with the false candidate, and will be sent to that 3825 false candidate. The attacker must then receive it and relay it 3826 towards the originator. 3828 The other agent will then initiate a connectivity check towards that 3829 false candidate. This validation needs to succeed. This requires 3830 the attacker to force a false valid on a false candidate. Injecting 3831 of fake requests or responses to achieve this goal is prevented using 3832 the integrity mechanisms of STUN and the offer/answer exchange. 3833 Thus, this attack can only be launched through replays. To do that, 3834 the attacker must intercept the check towards this false candidate, 3835 and replay it towards the other agent. Then, it must intercept the 3836 response and replay that back as well. 3838 This attack is very hard to launch unless the attacker is identified 3839 by the fake candidate. This is because it requires the attacker to 3840 intercept and replay packets sent by two different hosts. If both 3841 agents are on different networks (for example, across the public 3842 Internet), this attack can be hard to coordinate, since it needs to 3843 occur against two different endpoints on different parts of the 3844 network at the same time. 3846 If the attacker themself is identified by the fake candidate the 3847 attack is easier to coordinate. However, if SRTP is used [24], the 3848 attacker will not be able to play the media packets, they will only 3849 be able to discard them, effectively disabling the media stream for 3850 the call. However, this attack requires the agent to disrupt packets 3851 in order to block the connectivity check from reaching the target. 3852 In that case, if the goal is to disrupt the media stream, its much 3853 easier to just disrupt it with the same mechanism, rather than attack 3854 ICE. 3856 17.2. Attacks on Address Gathering 3858 ICE endpoints make use of STUN for gathering candidates from a STUN 3859 server in the network. This is corresponds to the Binding Discovery 3860 usage of STUN described in [13]. As a consequence, the attacks 3861 against STUN itself that are described in that specification can 3862 still be used against the binding discovery usage when utilized with 3863 ICE. 3865 However, the additional mechanisms provided by ICE actually 3866 counteract such attacks, making binding discovery with STUN more 3867 secure when combined with ICE than without ICE. 3869 Consider an attacker which is able to provide an agent with a faked 3870 mapped address in a STUN Binding Request that is used for address 3871 gathering. This is the primary attack primitive described in [13]. 3872 This address will be used as a server reflexive candidate in the ICE 3873 exchange. For this candidate to actually be used for media, the 3874 attacker must also attack the connectivity checks, and in particular, 3875 force a false valid on a false candidate. This attack is very hard 3876 to launch if the false address identifies a fourth party (neither the 3877 offerer, answerer, or attacker), since it requires attacking the 3878 checks generated by each agent in the session, and is prevented by 3879 SRTP if it identifies the attacker themself. 3881 If the attacker elects not to attack the connectivity checks, the 3882 worst it can do is prevent the server reflexive candidate from being 3883 used. However, if the peer agent has at least one candidate that is 3884 reachable by the agent under attack, the STUN connectivity checks 3885 themselves will provide a peer reflexive candidate that can be used 3886 for the exchange of media. Peer reflexive candidates are generally 3887 preferred over server reflexive candidates. As such, an attack 3888 solely on the STUN address gathering will normally have no impact on 3889 a session at all. 3891 17.3. Attacks on the Offer/Answer Exchanges 3893 An attacker that can modify or disrupt the offer/answer exchanges 3894 themselves can readily launch a variety of attacks with ICE. They 3895 could direct media to a target of a DoS attack, they could insert 3896 themselves into the media stream, and so on. These are similar to 3897 the general security considerations for offer/answer exchanges, and 3898 the security considerations in RFC 3264 [4] apply. These require 3899 techniques for message integrity and encryption for offers and 3900 answers, which are satisfied by the SIPS mechanism [3] when SIP is 3901 used. As such, the usage of SIPS with ICE is RECOMMENDED. 3903 17.4. Insider Attacks 3905 In addition to attacks where the attacker is a third party trying to 3906 insert fake offers, answers or stun messages, there are several 3907 attacks possible with ICE when the attacker is an authenticated and 3908 valid participant in the ICE exchange. 3910 17.4.1. The Voice Hammer Attack 3912 The voice hammer attack is an amplification attack. In this attack, 3913 the attacker initiates sessions to other agents, and maliciously 3914 includes the IP address and port of a DoS target as the destination 3915 for media traffic signaled in the SDP. This causes substantial 3916 amplification; a single offer/answer exchange can create a continuing 3917 flood of media packets, possibly at high rates (consider video 3918 sources). This attack is not specific to ICE, but ICE can help 3919 provide remediation. 3921 Specifically, if ICE is used, the agent receiving the malicious SDP 3922 will first perform connectivity checks to the target of media before 3923 sending media there. If this target is a third party host, the 3924 checks will not succeed, and media is never sent. 3926 Unfortunately, ICE doesn't help if its not used, in which case an 3927 attacker could simply send the offer without the ICE parameters. 3928 However, in environments where the set of clients are known, and 3929 limited to ones that support ICE, the server can reject any offers or 3930 answers that don't indicate ICE support. 3932 17.4.2. STUN Amplification Attack 3934 The STUN amplification attack is similar to the voice hammer. 3935 However, instead of voice packets being directed to the target, STUN 3936 connectivity checks are directed to the target. The attacker sends 3937 an offer with a large number of candidates, say 50. The answerer 3938 receives the offer, and starts its checks, which are directed at the 3939 target, and consequently, never generate a response. The answerer 3940 will start a new connectivity check every Ta ms (say Ta=20ms). 3941 However, the retransmission timers are set to a large number due to 3942 the large number of candidates. As a consequence, packets will be 3943 sent at an interval of one every Ta milliseconds, and then with 3944 increasing intervals after that. Thus, STUN will not send packets at 3945 a rate faster than media would be sent, and the STUN packets persist 3946 only briefly, until ICE fails for the session. Nonetheless, this is 3947 an amplification mechanism. 3949 It is impossible to eliminate the amplification, but the volume can 3950 be reduced through a variety of heuristics. Agents SHOULD limit the 3951 total number of connectivity checks they perform to 100. 3952 Additionally, agents MAY limit the number of candidates they'll 3953 accept in an offer or answer. 3955 17.5. Interactions with Application Layer Gateways and SIP 3957 Application Layer Gateways (ALGs) are functions present in a NAT 3958 device which inspect the contents of packets and modify them, in 3959 order to facilitate NAT traversal for application protocols. Session 3960 Border Controllers (SBC) are close cousins of ALGs, but are less 3961 transparent since they actually exist as application layer SIP 3962 intermediaries. ICE has interactions with SBCs and ALGs. 3964 If an ALG is SIP aware but not ICE aware, ICE will work through it as 3965 long as the ALG correctly modifies the SDP. A correct ALG 3966 implementation behave as follows: 3968 o The ALG does not modify the m and c lines or the rtcp attribute if 3969 they contain external addresses. 3971 o If the m and c lines contain internal addresses, the modification 3972 depends on the state of the ALG: 3974 If the ALG already has a binding established that maps an 3975 external port to an internal IP address and port matching the 3976 values in the m and c lines or rtcp attribute , the ALG uses 3977 that binding instead of creating a new one. 3979 If the ALG does not already have a binding, it creates a new 3980 one and modifies the SDP, rewriting the m and c lines and rtcp 3981 attribute. 3983 Unfortunately, many ALG are known to work poorly in these corner 3984 cases. ICE does not try to work around broken ALGs, as this is 3985 outside the scope of its functionality. ICE can help diagnose these 3986 conditions, which often show up as a mismatch between the set of 3987 candidates and the m and c lines and rtcp attributes. The ice- 3988 mismatch attribute is used for this purpose. 3990 ICE works best through ALGs when the signaling is run over TLS. This 3991 prevents the ALG from manipulating the SDP messages and interfering 3992 with ICE operation. Implementations which are expected to be 3993 deployed behind ALGs SHOULD provide for TLS transport of the SDP. 3995 If an SBC is SIP aware but not ICE aware, the result depends on the 3996 behavior of the SBC. If it is acting as a proper Back-to-Back User 3997 Agent (B2BUA), the SBC will remove any SDP attributes it doesn't 3998 understand, including the ICE attributes. Consequently, the call 3999 will appear to both endpoints as if the other side doesn't support 4000 ICE. This will result in ICE being disabled, and media flowing 4001 through the SBC, if the SBC has requested it. If, however, the SBC 4002 passes the ICE attributes without modification, yet modifies the 4003 default destination for media (contained in the m and c lines and 4004 rtcp attribute), this will be detected as an ICE mismatch, and ICE 4005 processing is aborted for the call. It is outside of the scope of 4006 ICE for it to act as a tool for "working around" SBCs. If one is 4007 present, ICE will not be used and the SBC techniques take precedence. 4009 18. Definition of Connectivity Check Usage 4011 STUN [13] requires that new usages provide a specific set of 4012 information as part of their formal definition. This section meets 4013 the requirements spelled out there. 4015 18.1. Applicability 4017 This STUN usage provides a connectivity check between two peers 4018 participating in an offer/answer exchange. This check serves to 4019 validate a pair of candidates for usage of exchange of media. 4020 Connectivity checks also allow agents to discover reflexive 4021 candidates towards their peers, called peer reflexive candidates. 4022 Finally, this usage allows a Binding Indication to be used to keep 4023 NAT bindings alive. 4025 It is fundamental to this STUN usage that the addresses and ports 4026 used for media are the same ones used for the Binding Requests and 4027 responses. Consequently, it will be necessary to demultiplex STUN 4028 traffic from applications on that same port (e.g., RTP or RTCP). 4029 This demultiplexing is done using the techniques described in [13]. 4031 18.2. Client Discovery of Server 4033 The client does not follow the DNS-based procedures defined in [13]. 4034 Rather, the remote candidate of the check to be performed is used as 4035 the transport address of the STUN server. Note that the STUN server 4036 is a logical entity, and is not a physically distinct server in this 4037 usage. 4039 18.3. Server Determination of Usage 4041 The server is aware of this usage because it signaled transport 4042 addresses in its candidates on which it expects to receive STUN 4043 packets. Consequently, any STUN packets received on the base of a 4044 candidate offered in SDP will be for the connectivity check usage. 4046 18.4. New Requests or Indications 4048 This usage does not define any new message types. 4050 18.5. New Attributes 4052 This usage defines four new attributes, PRIORITY, USE-CANDIDATE, ICE- 4053 CONTROLLED and ICE-CONTROLLING. 4055 The PRIORITY attribute indicates the priority that is to be 4056 associated with a peer reflexive candidate, should one be discovered 4057 by this check. It is a 32 bit unsigned integer, and has an attribute 4058 value of 0x0024. 4060 The USE-CANDIDATE attribute indicates that the candidate pair 4061 resulting from this check should be used for transmission of media. 4062 The attribute has no content (the Length field of the attribute is 4063 zero); it serves as a flag. It has an attribute value of 0x0025. 4065 The ICE-CONTROLLED attribute is present in a Binding Request, and 4066 indicates that the client believes it is currently in the controlled 4067 role. The content of the attribute is a 64 bit unsigned integer in 4068 network byte ordering, which contains a random number used for tie- 4069 breaking of role conflicts. 4071 The ICE-CONTROLLING attribute is present in a Binding Request, and 4072 indicates that the client believes it is currently in the controlling 4073 role. The content of the attribute is a 64 bit unsigned integer in 4074 network byte ordering, which contains a random number used for tie- 4075 breaking of role conflicts. 4077 18.6. New Error Response Codes 4079 This usage defines a single error response code: 4081 487 (Role Conflict): The Binding Request contained either the ICE- 4082 CONTROLLING or ICE-CONTROLLED attribute, indicating a role that 4083 conflicted with the server. The server ran a tie-breaker based on 4084 the tie-breaker value in the request, and determined that the 4085 client needs to switch roles. 4087 18.7. Client Procedures 4089 Client procedures are defined in Section 7.1. 4091 18.8. Server Procedures 4093 Server procedures are defined in Section 7.2. 4095 18.9. Security Considerations for Connectivity Check 4097 Security considerations for the connectivity check are discussed in 4098 Section 17. 4100 19. IANA Considerations 4102 This specification registers new SDP attributes and new STUN 4103 attributes. 4105 19.1. SDP Attributes 4107 This specification defines seven new SDP attributes per the 4108 procedures of Section 8.2.4 of [10]. The required information for 4109 the registrations are included here. 4111 19.1.1. candidate Attribute 4113 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4115 Attribute Name: candidate 4117 Long Form: candidate 4119 Type of Attribute: media level 4121 Charset Considerations: The attribute is not subject to the charset 4122 attribute. 4124 Purpose: This attribute is used with Interactive Connectivity 4125 Establishment (ICE), and provides one of many possible candidate 4126 addresses for communication. These addresses are validated with 4127 an end-to-end connectivity check using Simple Traversal Underneath 4128 NAT (STUN). 4130 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4131 please replace XXXX with the RFC number of this specification]. 4133 19.1.2. remote-candidates Attribute 4135 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4137 Attribute Name: remote-candidates 4138 Long Form: remote-candidates 4140 Type of Attribute: media level 4142 Charset Considerations: The attribute is not subject to the charset 4143 attribute. 4145 Purpose: This attribute is used with Interactive Connectivity 4146 Establishment (ICE), and provides the identity of the remote 4147 candidates that the offerer wishes the answerer to use in its 4148 answer. 4150 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4151 please replace XXXX with the RFC number of this specification]. 4153 19.1.3. ice-lite Attribute 4155 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4157 Attribute Name: ice-lite 4159 Long Form: ice-lite 4161 Type of Attribute: session level 4163 Charset Considerations: The attribute is not subject to the charset 4164 attribute. 4166 Purpose: This attribute is used with Interactive Connectivity 4167 Establishment (ICE), and indicates that an agent has the minimum 4168 functionality required to support ICE inter-operation with a peer 4169 that has a full implementation. 4171 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4172 please replace XXXX with the RFC number of this specification]. 4174 19.1.4. ice-mismatch Attribute 4176 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4178 Attribute Name: ice-mismatch 4180 Long Form: ice-mismatch 4182 Type of Attribute: session level 4183 Charset Considerations: The attribute is not subject to the charset 4184 attribute. 4186 Purpose: This attribute is used with Interactive Connectivity 4187 Establishment (ICE), and indicates that an agent is ICE capable, 4188 but did not proceed with ICE due to a mismatch of candidates with 4189 the default destination for media signaled in the SDP. 4191 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4192 please replace XXXX with the RFC number of this specification]. 4194 19.1.5. ice-pwd Attribute 4196 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4198 Attribute Name: ice-pwd 4200 Long Form: ice-pwd 4202 Type of Attribute: session or media level 4204 Charset Considerations: The attribute is not subject to the charset 4205 attribute. 4207 Purpose: This attribute is used with Interactive Connectivity 4208 Establishment (ICE), and provides the password used to protect 4209 STUN connectivity checks. 4211 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4212 please replace XXXX with the RFC number of this specification]. 4214 19.1.6. ice-ufrag Attribute 4216 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4218 Attribute Name: ice-ufrag 4220 Long Form: ice-ufrag 4222 Type of Attribute: session or media level 4224 Charset Considerations: The attribute is not subject to the charset 4225 attribute. 4227 Purpose: This attribute is used with Interactive Connectivity 4228 Establishment (ICE), and provides the fragments used to construct 4229 the username in STUN connectivity checks. 4231 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4232 please replace XXXX with the RFC number of this specification]. 4234 19.1.7. ice-options Attribute 4236 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4238 Attribute Name: ice-options 4240 Long Form: ice-options 4242 Type of Attribute: session level 4244 Charset Considerations: The attribute is not subject to the charset 4245 attribute. 4247 Purpose: This attribute is used with Interactive Connectivity 4248 Establishment (ICE), and indicates the ICE options or extensions 4249 used by the agent. 4251 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4252 please replace XXXX with the RFC number of this specification]. 4254 19.2. STUN Attributes 4256 This section registers four new STUN attributes per the procedures in 4257 [13]. 4259 0x0024 PRIORITY 4260 0x0025 USE-CANDIDATE 4261 0x8029 ICE-CONTROLLED 4262 0x802a ICE-CONTROLLING 4264 19.3. STUN Error Responses 4266 This section registers one new STUN error response code per the 4267 procedures in [13]. 4269 487 Role Conflict 4271 20. IAB Considerations 4273 The IAB has studied the problem of "Unilateral Self Address Fixing", 4274 which is the general process by which a agent attempts to determine 4275 its address in another realm on the other side of a NAT through a 4276 collaborative protocol reflection mechanism [22]. ICE is an example 4277 of a protocol that performs this type of function. Interestingly, 4278 the process for ICE is not unilateral, but bilateral, and the 4279 difference has a signficant impact on the issues raised by IAB. 4280 Indeed, ICE can be considered a B-SAF (Bilateral Self-Address Fixing) 4281 protocol, rather than an UNSAF protocol. Regardless, the IAB has 4282 mandated that any protocols developed for this purpose document a 4283 specific set of considerations. This section meets those 4284 requirements. 4286 20.1. Problem Definition 4288 From RFC 3424 any UNSAF proposal must provide: 4290 Precise definition of a specific, limited-scope problem that is to 4291 be solved with the UNSAF proposal. A short term fix should not be 4292 generalized to solve other problems; this is why "short term fixes 4293 usually aren't". 4295 The specific problems being solved by ICE are: 4297 Provide a means for two peers to determine the set of transport 4298 addresses which can be used for communication. 4300 Provide a means for resolving many of the limitations of other 4301 UNSAF mechanisms by wrapping them in an additional layer of 4302 processing (the ICE methodology). 4304 Provide a means for a agent to determine an address that is 4305 reachable by another peer with which it wishes to communicate. 4307 20.2. Exit Strategy 4309 From RFC 3424, any UNSAF proposal must provide: 4311 Description of an exit strategy/transition plan. The better short 4312 term fixes are the ones that will naturally see less and less use 4313 as the appropriate technology is deployed. 4315 ICE itself doesn't easily get phased out. However, it is useful even 4316 in a globally connected Internet, to serve as a means for detecting 4317 whether a router failure has temporarily disrupted connectivity, for 4318 example. ICE also helps prevent certain security attacks which have 4319 nothing to do with NAT. However, what ICE does is help phase out 4320 other UNSAF mechanisms. ICE effectively selects amongst those 4321 mechanisms, prioritizing ones that are better, and deprioritizing 4322 ones that are worse. Local IPv6 addresses can be preferred. As NATs 4323 begin to dissipate as IPv6 is introduced, server reflexive and 4324 relayed candidates (both forms of UNSAF mechanisms) simply never get 4325 used, because higher priority connectivity exists to the native host 4326 candidates. Therefore, the servers get used less and less, and can 4327 eventually be remove when their usage goes to zero. 4329 Indeed, ICE can assist in the transition from IPv4 to IPv6. It can 4330 be used to determine whether to use IPv6 or IPv4 when two dual-stack 4331 hosts communicate with SIP (IPv6 gets used). It can also allow a 4332 network with both 6to4 and native v6 connectivity to determine which 4333 address to use when communicating with a peer. 4335 20.3. Brittleness Introduced by ICE 4337 From RFC3424, any UNSAF proposal must provide: 4339 Discussion of specific issues that may render systems more 4340 "brittle". For example, approaches that involve using data at 4341 multiple network layers create more dependencies, increase 4342 debugging challenges, and make it harder to transition. 4344 ICE actually removes brittleness from existing UNSAF mechanisms. In 4345 particular, traditional STUN (as described in RFC 3489 [16]) has 4346 several points of brittleness. One of them is the discovery process 4347 which requires a agent to try and classify the type of NAT it is 4348 behind. This process is error-prone. With ICE, that discovery 4349 process is simply not used. Rather than unilaterally assessing the 4350 validity of the address, its validity is dynamically determined by 4351 measuring connectivity to a peer. The process of determining 4352 connectivity is very robust. 4354 Another point of brittleness in traditional STUN and any other 4355 unilateral mechanism is its absolute reliance on an additional 4356 server. ICE makes use of a server for allocating unilateral 4357 addresses, but allows agents to directly connect if possible. 4358 Therefore, in some cases, the failure of a STUN server would still 4359 allow for a call to progress when ICE is used. 4361 Another point of brittleness in traditional STUN is that it assumes 4362 that the STUN server is on the public Internet. Interestingly, with 4363 ICE, that is not necessary. There can be a multitude of STUN servers 4364 in a variety of address realms. ICE will discover the one that has 4365 provided a usable address. 4367 The most troubling point of brittleness in traditional STUN is that 4368 it doesn't work in all network topologies. In cases where there is a 4369 shared NAT between each agent and the STUN server, traditional STUN 4370 may not work. With ICE, that restriction is removed. 4372 Traditional STUN also introduces some security considerations. 4373 Fortunately, those security considerations are also mitigated by ICE. 4375 Consequently, ICE serves to repair the brittleness introduced in 4376 other UNSAF mechanisms, and does not introduce any additional 4377 brittleness into the system. 4379 The penalty of these improvements is that ICE increases session 4380 establishment times. 4382 20.4. Requirements for a Long Term Solution 4384 From RFC 3424, any UNSAF proposal must provide: 4386 Identify requirements for longer term, sound technical solutions 4387 -- contribute to the process of finding the right longer term 4388 solution. 4390 Our conclusions from STUN remain unchanged. However, we feel ICE 4391 actually helps because we believe it can be part of the long term 4392 solution. 4394 20.5. Issues with Existing NAPT Boxes 4396 From RFC 3424, any UNSAF proposal must provide: 4398 Discussion of the impact of the noted practical issues with 4399 existing, deployed NA[P]Ts and experience reports. 4401 A number of NAT boxes are now being deployed into the market which 4402 try and provide "generic" ALG functionality. These generic ALGs hunt 4403 for IP addresses, either in text or binary form within a packet, and 4404 rewrite them if they match a binding. This interferes with 4405 traditional STUN. However, the update to STUN [13] uses an encoding 4406 which hides these binary addresses from generic ALGs. 4408 Existing NAPT boxes have non-deterministic and typically short 4409 expiration times for UDP-based bindings. This requires 4410 implementations to send periodic keepalives to maintain those 4411 bindings. ICE uses a default of 15s, which is a very conservative 4412 estimate. Eventually, over time, as NAT boxes become compliant to 4413 behave [30], this minimum keepalive will become deterministic and 4414 well-known, and the ICE timers can be adjusted. Having a way to 4415 discover and control the minimum keepalive interval would be far 4416 better still. 4418 21. Acknowledgements 4420 The authors would like to thank Dan Wing, Eric Rescorla, Flemming 4421 Andreasen, Rohan Mahy, Dean Willis, Eric Cooper, Jason Fischl, 4422 Douglas Otis, Tim Moore, Jean-Francois Mule, Kevin Johns, Jonathan 4423 Lennox and Francois Audet for their comments and input. A special 4424 thanks goes to Bill May, who suggested several of the concepts in 4425 this specification, Philip Matthews, who suggested many of the key 4426 performance optimizations in this specification, Eric Rescorla, who 4427 drafted the text in the introduction, and Magnus Westerlund, for 4428 doing several detailed reviews on the various revisions of this 4429 specification. 4431 22. References 4433 22.1. Normative References 4435 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4436 Levels", BCP 14, RFC 2119, March 1997. 4438 [2] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 4439 Session Description Protocol (SDP)", RFC 3605, October 2003. 4441 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 4442 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 4443 Session Initiation Protocol", RFC 3261, June 2002. 4445 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 4446 Session Description Protocol (SDP)", RFC 3264, June 2002. 4448 [5] Casner, S., "Session Description Protocol (SDP) Bandwidth 4449 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 4450 July 2003. 4452 [6] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 4453 Resource Management and Session Initiation Protocol (SIP)", 4454 RFC 3312, October 2002. 4456 [7] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation 4457 Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. 4459 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 4460 Specifications: ABNF", RFC 4234, October 2005. 4462 [9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 4463 Responses in Session Initiation Protocol (SIP)", RFC 3262, 4464 June 2002. 4466 [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4467 Description Protocol", RFC 4566, July 2006. 4469 [11] Camarillo, G. and J. Rosenberg, "The Alternative Network 4470 Address Types (ANAT) Semantics for the Session Description 4471 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 4473 [12] Draves, R., "Default Address Selection for Internet Protocol 4474 version 6 (IPv6)", RFC 3484, February 2003. 4476 [13] Rosenberg, J., "Simple Traversal Underneath Network Address 4477 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 4478 (work in progress), October 2006. 4480 [14] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 4481 Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in 4482 progress), October 2006. 4484 [15] Rosenberg, J., "Indicating Support for Interactive Connectivity 4485 Establishment (ICE) in the Session Initiation Protocol (SIP)", 4486 draft-ietf-sip-ice-option-tag-00 (work in progress), 4487 January 2007. 4489 22.2. Informative References 4491 [16] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 4492 - Simple Traversal of User Datagram Protocol (UDP) Through 4493 Network Address Translators (NATs)", RFC 3489, March 2003. 4495 [17] Senie, D., "Network Address Translator (NAT)-Friendly 4496 Application Design Guidelines", RFC 3235, January 2002. 4498 [18] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 4499 Rayhan, "Middlebox communication architecture and framework", 4500 RFC 3303, August 2002. 4502 [19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 4503 "Best Current Practices for Third Party Call Control (3pcc) in 4504 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 4505 April 2004. 4507 [20] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm 4508 Specific IP: Framework", RFC 3102, October 2001. 4510 [21] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm 4511 Specific IP: Protocol Specification", RFC 3103, October 2001. 4513 [22] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 4514 Address Fixing (UNSAF) Across Network Address Translation", 4515 RFC 3424, November 2002. 4517 [23] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 4518 "RTP: A Transport Protocol for Real-Time Applications", 4519 RFC 3550, July 2003. 4521 [24] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 4522 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 4523 RFC 3711, March 2004. 4525 [25] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 4526 IPv4 Clouds", RFC 3056, February 2001. 4528 [26] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 4529 Comfort Noise (CN)", RFC 3389, September 2002. 4531 [27] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone 4532 Generation in the Session Initiation Protocol (SIP)", RFC 3960, 4533 December 2004. 4535 [28] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. 4536 Weiss, "An Architecture for Differentiated Services", RFC 2475, 4537 December 1998. 4539 [29] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 4540 Lear, "Address Allocation for Private Internets", BCP 5, 4541 RFC 1918, February 1996. 4543 [30] Audet, F. and C. Jennings, "Network Address Translation (NAT) 4544 Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, 4545 January 2007. 4547 [31] Andreasen, F., "Connectivity Preconditions for Session 4548 Description Protocol Media Streams", 4549 draft-ietf-mmusic-connectivity-precon-02 (work in progress), 4550 June 2006. 4552 [32] Andreasen, F., "A No-Op Payload Format for RTP", 4553 draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005. 4555 [33] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 4556 Control Packets on a Single Port", 4557 draft-ietf-avt-rtp-and-rtcp-mux-03 (work in progress), 4558 December 2006. 4560 [34] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 4561 Control Protocol (DCCP)", RFC 4340, March 2006. 4563 [35] Hellstrom, G. and P. Jones, "RTP Payload for Text 4564 Conversation", RFC 4103, June 2005. 4566 [36] Jennings, C. and R. Mahy, "Managing Client Initiated 4567 Connections in the Session Initiation Protocol (SIP)", 4568 draft-ietf-sip-outbound-07 (work in progress), January 2007. 4570 Appendix A. Lite and Full Implementations 4572 ICE allows for two types of implementations. A full implementation 4573 supports the controlling and controlled roles in a session, and can 4574 also perform address gathering. In contrast, a lite implementation 4575 is a minimalist implementation that does little but respond to STUN 4576 checks. 4578 Because ICE requires both endpoints to support it in order to bring 4579 benefits to either endpoint, incremental deployment of ICE in a 4580 network is more complicated. Many sessions involve an endpoint which 4581 is, by itself, not behind a NAT and not one that would worry about 4582 NAT traversal. A very common case is to have one endpoint that 4583 requires NAT traversal (such as a VoIP hard phone or soft phone) make 4584 a call to one of these devices. Even if the phone supports a full 4585 ICE implementation, ICE won't be used at all if the other device 4586 doesn't support it. The lite implementation allows for a low-cost 4587 entry point for these devices. Once they support the lite 4588 implementation, full implementations can connect to them and get the 4589 full benefits of ICE. 4591 Consequently, a lite implementation is only appropriate for devices 4592 that will *always* be connected to the public Internet and have a 4593 public IP address at which it can receive packets from any 4594 correspondent. ICE will not function when a lite implementation is 4595 placed behind a NAT. 4597 ICE allows a lite implementation to have a single IPv4 host candidate 4598 and several IPv6 addresses. In that case, candidate pairs are 4599 selected by the controlling agent using a static algorithm, such as 4600 the one in RFC 3484, which is recommended by this specification. 4601 However, static mechanisms for address selection are always prone to 4602 error, since they cannot ever reflect the actual topology and can 4603 never provide actual guarantees on connectivity. They are always 4604 heuristics. Consequently, if an agent is implementing ICE just to 4605 select between its IPv4 and IPv6 addresses, and it is none of its 4606 interfaces are behind NAT, usage of full ICE is still RECOMMENDED in 4607 order to provide the most robust form of address selection possible. 4609 It is important to note that the lite implementation was added to 4610 this specification to provide a stepping stone to full 4611 implementation. Even for devices that are always connected to the 4612 public Internet with just a single IPv4 address, a full 4613 implementation is preferable if achievable. A full implementation 4614 will reduce call setup times, since ICE's aggressive mode can be 4615 used. Full implementations also obtain the security benefits of ICE 4616 unrelated to NAT traversal; in particular, the voice hammer attack 4617 described in Section 17 is prevented only for full implementations, 4618 not lite. Finally, it is often the case that a device which finds 4619 itself with a public address today will be placed in a network 4620 tomorrow where it will be behind a NAT. It is difficult to 4621 definitively know, over the lifetime of a device or product, that it 4622 will always be used on the public Internet. Full implementation 4623 provides assurance that communications will always work. 4625 Appendix B. Design Motivations 4627 ICE contains a number of normative behaviors which may themselves be 4628 simple, but derive from complicated or non-obvious thinking or use 4629 cases which merit further discussion. Since these design motivations 4630 are not neccesary to understand for purposes of implementation, they 4631 are discussed here in an appendix to the specification. This section 4632 is non-normative. 4634 B.1. Pacing of STUN Transactions 4636 STUN transactions used to gather candidates and to verify 4637 connectivity are paced out at an approximate rate of one new 4638 transaction every Ta milliseconds. Each transaction, in turn, has a 4639 retransmission timer RTO that is a function of Ta as well. Why are 4640 these transactions paced, and why are these formulas used? 4642 Sending of these STUN requests will often have the effect of creating 4643 bindings on NAT devices between the client and the STUN servers. 4644 Experience has shown that many NAT devices have upper limits on the 4645 rate at which they will create new bindings. Experiments have shown 4646 that once every 20ms is well supported, but not much lower than that. 4647 This is why Ta has a lower bound of 20ms. Furthermore, transmission 4648 of these packets on the network makes use of bandwidth and needs to 4649 be rate limited by the agent. As a consequence, the pacing ensures 4650 that the NAT devices does not get overloaded and that traffic is kept 4651 at a reasonable rate. 4653 The definition of a "reasonable" rate is that STUN should not use 4654 more bandwidth than the RTP itself will use, once media starts 4655 flowing. The formula for Ta is designed so that, if a STUN packet 4656 were sent every Ta seconds, it would consume the same amount of 4657 bandwidth as RTP packets, summed across all media streams. Of 4658 course, STUN has retransmits, and the desire is to pace those as 4659 well. For this reason, RTO is set such that the first retransmit on 4660 the first transaction happens just as the first STUN request on the 4661 last transaction occurs. Pictorially: 4663 First Packets Retransmits 4665 | | 4666 | | 4667 -------+------ -------+------ 4668 / \ / \ 4669 / \ / \ 4671 +--+ +--+ +--+ +--+ +--+ +--+ 4672 |A1| |B1| |C1| |A2| |B2| |C2| 4673 +--+ +--+ +--+ +--+ +--+ +--+ 4675 ---+-------+-------+-------+-------+-------+------------ Time 4676 0 Ta 2Ta 3Ta 4Ta 5Ta 4678 In this picture, there are three transactions that will be sent (for 4679 example, in the case of candidate gathering, there are three host 4680 candidate/STUN server pairs). These are transactions A, B and C. The 4681 retransmit timer is set so that the first retransmission on the first 4682 transaction (packet A2) is sent at time 3Ta. 4684 Subsequent retransmits after the first will occur even less 4685 frequently than Ta milliseconds apart, since STUN uses an exponential 4686 back-off on its retransmissions. 4688 B.2. Candidates with Multiple Bases 4690 Section 4.1.1.3 talks about eliminating candidates that have the same 4691 transport address and base. However, candidates with the same 4692 transport addresses but different bases are not redundant . When can 4693 an agent have two candidates that have the same IP address and port, 4694 but different bases? Consider the topology of Figure 28: 4696 +----------+ 4697 | STUN Srvr| 4698 +----------+ 4699 | 4700 | 4701 ----- 4702 // \\ 4703 | | 4704 | B:net10 | 4705 | | 4706 \\ // 4707 ----- 4708 | 4709 | 4710 +----------+ 4711 | NAT | 4712 +----------+ 4713 | 4714 | 4715 ----- 4716 // \\ 4717 | A | 4718 |192.168/16 | 4719 | | 4720 \\ // 4721 ----- 4722 | 4723 | 4724 |192.168.1.100 ----- 4725 +----------+ // \\ +----------+ 4726 | | | | | | 4727 | Offerer |---------| C:net10 |-----------| Answerer | 4728 | |10.0.1.100| | 10.0.1.101 | | 4729 +----------+ \\ // +----------+ 4730 ----- 4732 Figure 28: Identical Candidates with Different Bases 4734 In this case, the offerer is multi-homed. It has one interface, 4735 10.0.1.100, on network C, which is a net 10 private network. The 4736 Answerer is on this same network. The offerer is also connected to 4737 network A, which is 192.168/16. The offerer has an interface of 4738 192.168.1.100 on this network. There is a NAT on this network, 4739 natting into network B, which is another net 10 private network, but 4740 not connected to network C. There is a STUN server on network B. 4742 The offerer obtains a host candidate on its interface on network C 4743 (10.0.1.100:2498) and a host candidate on its interface on network A 4744 (192.168.1.100:3344). It performs a STUN query to its configured 4745 STUN server from 192.168.1.100:3344. This query passes through the 4746 NAT, which happens to assign the binding 10.0.1.100:2498. The STUN 4747 server reflects this in the STUN Binding Response. Now, the offerer 4748 has obtained a server reflexive candidate with a transport address 4749 that is identical to a host candidate (10.0.1.100:2498). However, 4750 the server reflexive candidate has a base of 192.168.1.100:3344, and 4751 the host candidate has a base of 10.0.1.100:2498. 4753 B.3. Purpose of the and Attributes 4755 The candidate attribute contains two values that are not used at all 4756 by ICE itself - and . Why is it present? 4758 There are two motivations for its inclusion. The first is 4759 diagnostic. It is very useful to know the relationship between the 4760 different types of candidates. By including it, an agent can know 4761 which relayed candidate is associated with which reflexive candidate, 4762 which in turn is associated with a specific host candidate. When 4763 checks for one candidate succeed and not the others, this provides 4764 useful diagnostics on what is going on in the network. 4766 The second reason has to do with off-path Quality of Service (QoS) 4767 mechanisms. When ICE is used in environments such as PacketCable 4768 2.0, proxies will, in addition to performing normal SIP operations, 4769 inspect the SDP in SIP messages, and extract the IP address and port 4770 for media traffic. They can then interact, through policy servers, 4771 with access routers in the network, to establish guaranteed QoS for 4772 the media flows. This QoS is provided by classifying the RTP traffic 4773 based on 5-tuple, and then providing it a guaranteed rate, or marking 4774 its Diffserv codepoints appropriately. When a residential NAT is 4775 present, and a relayed candidate gets selected for media, this 4776 relayed candidate will be a transport address on an actual STUN 4777 relay. That address says nothing about the actual transport address 4778 in the access router that would be used to classify packets for QoS 4779 treatment. Rather, the server reflexive candidate towards that relay 4780 is needed. By carrying the translation in the SDP, the proxy can use 4781 that transport address to request QoS from the access router. 4783 B.4. Importance of the STUN Username 4785 ICE requires the usage of message integrity with STUN using its short 4786 term credential functionality. The actual short term credential is 4787 formed by exchanging username fragments in the SDP offer/answer 4788 exchange. The need for this mechanism goes beyond just security; it 4789 is actual required for correct operation of ICE in the first place. 4791 Consider agents L, R, and Z. L and R are within private enterprise 1, 4792 which is using 10.0.0.0/8. Z is within private enterprise 2, which 4793 is also using 10.0.0.0/8. As it turns out, R and Z both have IP 4794 address 10.0.1.1. L sends an offer to Z. Z, in its answer, provides 4795 L with its host candidates. In this case, those candidates are 4796 10.0.1.1:8866 and 10.0.1.1:8877. As it turns out, R is in a session 4797 at that same time, and is also using 10.0.1.1:8866 and 10.0.1.1:8877 4798 as host candidates. This means that R is prepared to accept STUN 4799 messages on those ports, just as Z is. L will send a STUN request to 4800 10.0.1.1:8866 and and another to 10.0.1.1:8877. However, these do 4801 not go to Z as expected. Instead, they go to R! If R just replied 4802 to them, L would believe it has connectivity to Z, when in fact it 4803 has connectivity to a completely different user, R. To fix this, the 4804 STUN short term credential mechanisms are used. The username 4805 fragments are sufficiently random that it is highly unlikely that R 4806 would be using the same values as Z. Consequently, R would reject the 4807 STUN request since the credentials were invalid. In essence, the 4808 STUN username fragments provide a form of transient host identifiers, 4809 bound to a particular offer/answer session. 4811 An unfortunate consequence of the non-uniqueness of IP addresses is 4812 that, in the above example, R might not even be an ICE agent. It 4813 could be any host, and the port to which the STUN packet is directed 4814 could be any ephemeral port on that host. If there is an application 4815 listening on this socket for packets, and it is not prepared to 4816 handle malformed packets for whatever protocol is in use, the 4817 operation of that application could be affected. Fortunately, since 4818 the ports exchanged in SDP are ephemeral and usually drawn from the 4819 dynamic or registered range, the odds are good that the port is not 4820 used to run a server on host R, but rather is the agent side of some 4821 protocol. This decreases the probability of hitting an allocated 4822 port, due to the transient nature of port usage in this range. 4823 However, the possibility of a problem does exist, and network 4824 deployers should be prepared for it. Note that this is not a problem 4825 specific to ICE; stray packets can arrive at a port at any time for 4826 any type of protocol, especially ones on the public Internet. As 4827 such, this requirement is just restating a general design guideline 4828 for Internet applications - be prepared for unknown packets on any 4829 port. 4831 B.5. The Candidate Pair Sequence Number Formula 4833 The sequence number for a candidate pair has an odd form. It is: 4835 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 4837 Why is this? When the candidate pairs are sorted based on this 4838 value, the resulting sorting has the MAX/MIN property. This means 4839 that the pairs are first sorted based on decreasing value of the 4840 maximum of the two sequence numbers. For pairs that have the same 4841 value of the maximum sequence number, the minimum sequence number is 4842 used to sort amongst them. If the max and the min sequence numbers 4843 are the same, the offerers priority is used as the tie breaker in the 4844 last part of the expression. The factor of 2*32 is used since the 4845 priority of a single candidate is always less than 2*32, resulting in 4846 the pair priority being a "concatenation" of the two component 4847 priorities. This creates the MAX/MIN sorting. MAX/MIN ensures that, 4848 for a particular agent, a lower priority candidate is never used 4849 until all higher priority candidates have been tried. 4851 B.6. The remote-candidates attribute 4853 The a=remote-candidates attribute exists to eliminate a race 4854 condition between the updated offer and the response to the STUN 4855 Binding Request that moved a candidate into the Valid list. This 4856 race condition is shown in Figure 29. On receipt of message 4, agent 4857 L adds a candidate pair to the valid list. If there was only a 4858 single media stream with a single component, agent L could now send 4859 an updated offer. However, the check from agent R has not yet 4860 generated a response, and agent R receives the updated offer (message 4861 7) before getting the response (message 9). Thus, it does not yet 4862 know that this particular pair is valid. To eliminate this 4863 condition, the actual candidates at R that were selected by the 4864 offerer (the remote candidates) are included in the offer itself, and 4865 the answerer delays its answer until those pairs validate. 4867 Agent A Network Agent B 4868 |(1) Offer | | 4869 |------------------------------------------>| 4870 |(2) Answer | | 4871 |<------------------------------------------| 4872 |(3) STUN Req. | | 4873 |------------------------------------------>| 4874 |(4) STUN Res. | | 4875 |<------------------------------------------| 4876 |(5) STUN Req. | | 4877 |<------------------------------------------| 4878 |(6) STUN Res. | | 4879 |-------------------->| | 4880 | |Lost | 4881 |(7) Offer | | 4882 |------------------------------------------>| 4883 |(8) STUN Req. | | 4884 |<------------------------------------------| 4885 |(9) STUN Res. | | 4886 |------------------------------------------>| 4887 |(10) Answer | | 4888 |<------------------------------------------| 4890 Figure 29: Race Condition Flow 4892 B.7. Why are Keepalives Needed? 4894 Once media begins flowing on a candidate pair, it is still necessary 4895 to keep the bindings alive at intermediate NATs for the duration of 4896 the session. Normally, the media stream packets themselves (e.g., 4897 RTP) meet this objective. However, several cases merit further 4898 discussion. Firstly, in some RTP usages, such as SIP, the media 4899 streams can be "put on hold". This is accomplished by using the SDP 4900 "sendonly" or "inactive" attributes, as defined in RFC 3264 [4]. RFC 4901 3264 directs implementations to cease transmission of media in these 4902 cases. However, doing so may cause NAT bindings to timeout, and 4903 media won't be able to come off hold. 4905 Secondly, some RTP payload formats, such as the payload format for 4906 text conversation [35], may send packets so infrequently that the 4907 interval exceeds the NAT binding timeouts. 4909 Thirdly, if silence suppression is in use, long periods of silence 4910 may cause media transmission to cease sufficiently long for NAT 4911 bindings to time out. 4913 For these reasons, the media packets themselves cannot be relied 4914 upon. ICE defines a simple periodic keepalive that operates 4915 independently of media transmission. This makes its bandwidth 4916 requirements highly predictable, and thus amenable to QoS 4917 reservations. 4919 B.8. Why Prefer Peer Reflexive Candidates? 4921 Section 4.1.2 describes procedures for computing the priority of 4922 candidate based on its type and local preferences. That section 4923 requires that the type preference for peer reflexive candidates 4924 always be higher than server reflexive. Why is that? The reason has 4925 to do with the security considerations in Section 17. It is much 4926 easier for an attacker to cause an agent to use a false server 4927 reflexive candidate than it is for an attacker to cause an agent to 4928 use a false peer reflexive candidate. Consequently, attacks against 4929 the STUN binding discovery usage are thwarted by ICE by preferring 4930 the peer reflexive candidates. 4932 B.9. Why Send an Updated Offer? 4934 Section 11.1 describes rules for sending media. Both agents can send 4935 media once ICE checks complete, without waiting for an updated offer. 4936 Indeed, the only purpose of the updated offer is to "correct" the SDP 4937 so that the default destination for media matches where media is 4938 being sent based on ICE procedures (which will be the highest 4939 priority nominated candidate pair). 4941 This begs the question - why is the updated offer/answer exchange 4942 needed at all? Indeed, in a pure offer/answer environment, it would 4943 not be. The offerer and answerer will agree on the candidates to use 4944 through ICE, and then can begin using them. As far as the agents 4945 themselves are concerned, the updated offer/answer provides no new 4946 information. However, in practice, numerous components along the 4947 signaling path look at the SDP information. These include entities 4948 performing off-path QoS reservations, NAT traversal components such 4949 as ALGs and Session Border Controllers (SBCs) and diagnostic tools 4950 that passively monitor the network. For these tools to continue to 4951 function without change, the core property of SDP - that the 4952 existing, pre-ICE definitions of the addresses used for media - the m 4953 and c lines and the rtcp attribute - must be retained. For this 4954 reason, an updated offer must be sent. 4956 B.10. Why are Binding Indications Used for Keepalives? 4958 Media keepalives are described in Section 10. These keepalives make 4959 use of STUN when both endpoints are ICE capable. However, rather 4960 than using a Binding Request transaction (which generates a 4961 response), the keepalives use an Indication. Why is that? 4962 The primary reason has to do with network QoS mechanisms. Once media 4963 begins flowing, network elements will assume that the media stream 4964 has a fairly regular structure, making use of periodic packets at 4965 fixed intervals, with the possibility of jitter. If an agent is 4966 sending media packets, and then receives a Binding Request, it would 4967 need to generate a response packet along with its media packets. 4968 This will increase the actual bandwidth requirements for the 5-tuple 4969 carrying the media packets, and introduce jitter in the delivery of 4970 those packets. Analysis has shown that this is a concern in certain 4971 layer 2 access networks that use fairly tight packet schedulers for 4972 media. 4974 Additionally, using a Binding Indication allows integrity to be 4975 disabled, allowing for better performance. This is useful for large 4976 scale endpoints, such as PSTN gateways and SBCs. 4978 B.11. Why is the Conflict Resolution Mechanism Needed? 4980 When ICE runs between two peers, one agent acts as controlled, and 4981 the other as controlling. Rules are defined as a function of 4982 implementation type and offerer/answerer to determine who is 4983 controlling and who is controlled. However, the specification 4984 mentions that, in some cases, both sides might believe they are 4985 controlling, or both sides might believe they are controlled. How 4986 can this happen? 4988 The condition when both agents believe they are controlled shows up 4989 in third party call control cases. Consider the following flow: 4991 A Controller B 4992 |(1) INV() | | 4993 |<-------------| | 4994 |(2) 200(SDP1) | | 4995 |------------->| | 4996 | |(3) INV() | 4997 | |------------->| 4998 | |(4) 200(SDP2) | 4999 | |<-------------| 5000 |(5) ACK(SDP2) | | 5001 |<-------------| | 5002 | |(6) ACK(SDP1) | 5003 | |------------->| 5005 Figure 30: Role Conflict Flow 5007 This flow is a variation on flow III of RFC 3725 [19]. In fact, it 5008 works better than flow III since it produces fewer messages. In this 5009 flow, the controller sends an offerless INVITE to agent A, which 5010 responds with its offer, SDP1. The agent then sends an offerless 5011 INVITE to agent B, which it responds to with its offer, SDP2. The 5012 controller then uses the offer from each agent to generate the 5013 answers. When this flow is used, ICE will run between agents A and 5014 B, but both will believe they are in the controlling role. With the 5015 role conflict resolution procedures, this flow will function properly 5016 when ICE is used. 5018 At this time, there are no documented flows which can result in the 5019 case where both agents believe they are controlled. However, the 5020 conflict resolution procedures allow for this case, should a flow 5021 arise which would fit into this category. 5023 Author's Address 5025 Jonathan Rosenberg 5026 Cisco 5027 Edison, NJ 5028 US 5030 Phone: +1 973 952-5000 5031 Email: jdrosen@cisco.com 5032 URI: http://www.jdrosen.net 5034 Full Copyright Statement 5036 Copyright (C) The IETF Trust (2007). 5038 This document is subject to the rights, licenses and restrictions 5039 contained in BCP 78, and except as set forth therein, the authors 5040 retain all their rights. 5042 This document and the information contained herein are provided on an 5043 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5044 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5045 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5046 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5047 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5048 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5050 Intellectual Property 5052 The IETF takes no position regarding the validity or scope of any 5053 Intellectual Property Rights or other rights that might be claimed to 5054 pertain to the implementation or use of the technology described in 5055 this document or the extent to which any license under such rights 5056 might or might not be available; nor does it represent that it has 5057 made any independent effort to identify any such rights. Information 5058 on the procedures with respect to rights in RFC documents can be 5059 found in BCP 78 and BCP 79. 5061 Copies of IPR disclosures made to the IETF Secretariat and any 5062 assurances of licenses to be made available, or the result of an 5063 attempt made to obtain a general license or permission for the use of 5064 such proprietary rights by implementers or users of this 5065 specification can be obtained from the IETF on-line IPR repository at 5066 http://www.ietf.org/ipr. 5068 The IETF invites any interested party to bring to its attention any 5069 copyrights, patents or patent applications, or other proprietary 5070 rights that may cover technology that may be required to implement 5071 this standard. Please address the information to the IETF at 5072 ietf-ipr@ietf.org. 5074 Acknowledgment 5076 Funding for the RFC Editor function is provided by the IETF 5077 Administrative Support Activity (IASA).