--- 1/draft-ietf-mmusic-ice-14.txt 2007-03-28 22:12:18.000000000 +0200 +++ 2/draft-ietf-mmusic-ice-15.txt 2007-03-28 22:12:18.000000000 +0200 @@ -1,19 +1,20 @@ MMUSIC J. Rosenberg Internet-Draft Cisco -Intended status: Standards Track March 5, 2007 -Expires: September 6, 2007 +Obsoletes: 4091 (if approved) March 26, 2007 +Intended status: Standards Track +Expires: September 27, 2007 Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols - draft-ietf-mmusic-ice-14 + draft-ietf-mmusic-ice-15 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,213 +25,217 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 6, 2007. + This Internet-Draft will expire on September 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes a protocol for Network Address Translator (NAT) traversal for multimedia sessions established with the offer/ answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol, applying its binding discovery and relay usages, in addition to defining a new usage for checking connectivity between peers. ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 9 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 11 - 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 12 + 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 12 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 13 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 14 - 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . 14 - 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . . 16 + 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 14 + 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 16 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19 - 4.1. Full Implementation Requirements . . . . . . . . . . . . . 19 - 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . . 19 - 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 20 + 4.1. Full Implementation Requirements . . . . . . . . . . . . 19 + 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 + 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 - 4.1.1.3. Eliminating Redundant Candidates . . . . . . . . . 21 + 4.1.1.3. Eliminating Redundant Candidates . . . . . . . . 21 4.1.1.4. Computing Foundations . . . . . . . . . . . . . . 21 - 4.1.1.5. Keeping Candidates Alive . . . . . . . . . . . . . 22 + 4.1.1.5. Keeping Candidates Alive . . . . . . . . . . . . 22 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22 4.1.2.2. Guidelines for Choosing Type and Local Preferences . . . . . . . . . . . . . . . . . . . 23 4.1.3. Choosing Default Candidates . . . . . . . . . . . . . 24 4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 25 - 4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 25 + 4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 25 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 27 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 27 - 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 27 - 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . . 28 - 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 28 - 5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 28 - 5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 28 - 5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 28 + 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 28 + 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 28 + 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 29 + 5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 29 + 5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 29 + 5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 29 5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 29 - 5.7.2. Computing Pair Priority and Ordering Pairs . . . . . . 31 - 5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 31 - 5.7.4. Computing States . . . . . . . . . . . . . . . . . . . 31 - 5.8. Performing Periodic Checks . . . . . . . . . . . . . . . . 34 - 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 35 - 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 36 - 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 36 - 6.3. Forming the Check List . . . . . . . . . . . . . . . . . . 36 - 6.4. Performing Periodic Checks . . . . . . . . . . . . . . . . 36 - 7. Performing Connectivity Checks . . . . . . . . . . . . . . . . 36 - 7.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 37 - 7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 37 - 7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . . 37 - 7.1.1.2. Forming Credentials . . . . . . . . . . . . . . . 37 - 7.1.1.3. DiffServ Treatment . . . . . . . . . . . . . . . . 38 - 7.1.2. Processing the Response . . . . . . . . . . . . . . . 38 - 7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 38 - 7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 38 - 7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 38 - 7.1.2.2.2. Updating Pair States . . . . . . . . . . . . . 39 - 7.1.2.2.3. Constructing a Valid Pair . . . . . . . . . . 40 - 7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 40 - 7.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 41 - 7.2.1. Additional Procedures for Full Implementations . . . . 41 - 7.2.1.1. Computing Mapped Address . . . . . . . . . . . . . 41 - 7.2.1.2. Learning Peer Reflexive Candidates . . . . . . . . 42 - 7.2.1.3. Triggered Checks . . . . . . . . . . . . . . . . . 42 - 7.2.1.4. Updating the Nominated Flag . . . . . . . . . . . 43 - 7.2.2. Additional Procedures for Lite Implementations . . . . 43 - 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 43 - 8.1. Nominating Pairs . . . . . . . . . . . . . . . . . . . . . 44 - 8.1.1. Regular Nomination . . . . . . . . . . . . . . . . . . 44 - 8.1.2. Aggressive Nomination . . . . . . . . . . . . . . . . 45 - 8.2. Updating States . . . . . . . . . . . . . . . . . . . . . 45 - 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 46 - 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . . 46 - 9.1.1. Procedures for All Implementations . . . . . . . . . . 46 - 9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . . 46 - 9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 47 - 9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 47 - 9.1.2. Procedures for Full Implementations . . . . . . . . . 47 - 9.1.2.1. Existing Media Streams with ICE Running . . . . . 48 - 9.1.2.2. Existing Media Streams with ICE Completed . . . . 48 - 9.1.3. Procedures for Lite Implementations . . . . . . . . . 49 - 9.2. Receiving the Offer and Generating an Answer . . . . . . . 49 - 9.2.1. Procedures for All Implementations . . . . . . . . . . 49 - 9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 49 - 9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . . 50 - 9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . . 50 - 9.2.2. Procedures for Full Implementations . . . . . . . . . 50 + 5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 32 + 5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 32 + 5.7.4. Computing States . . . . . . . . . . . . . . . . . . 32 + 5.8. Performing Periodic Checks . . . . . . . . . . . . . . . 35 + 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 37 + 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 37 + 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 37 + 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 37 + 6.4. Performing Periodic Checks . . . . . . . . . . . . . . . 37 + 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 37 + 7.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 38 + 7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 38 + 7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 38 + 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 38 + 7.1.1.3. Forming Credentials . . . . . . . . . . . . . . . 39 + 7.1.1.4. DiffServ Treatment . . . . . . . . . . . . . . . 39 + 7.1.2. Processing the Response . . . . . . . . . . . . . . . 39 + 7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 39 + 7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 40 + 7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 40 + 7.1.2.2.2. Updating Pair States . . . . . . . . . . . . 41 + 7.1.2.2.3. Constructing a Valid Pair . . . . . . . . . . 42 + 7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 42 + 7.1.2.3. Check List and Timer State Updates . . . . . . . 43 + 7.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 43 + 7.2.1. Additional Procedures for Full Implementations . . . 44 + 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 44 + 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 45 + 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 45 + 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 46 + 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 47 + 7.2.2. Additional Procedures for Lite Implementations . . . 47 + 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 47 + 8.1. Nominating Pairs . . . . . . . . . . . . . . . . . . . . 48 + 8.1.1. Regular Nomination . . . . . . . . . . . . . . . . . 48 + 8.1.2. Aggressive Nomination . . . . . . . . . . . . . . . . 49 + 8.2. Updating States . . . . . . . . . . . . . . . . . . . . . 49 + 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 50 + 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 51 + 9.1.1. Procedures for All Implementations . . . . . . . . . 51 + 9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 51 + 9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 52 + 9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 52 + 9.1.2. Procedures for Full Implementations . . . . . . . . . 52 + 9.1.2.1. Existing Media Streams with ICE Running . . . . . 52 + 9.1.2.2. Existing Media Streams with ICE Completed . . . . 53 + 9.1.3. Procedures for Lite Implementations . . . . . . . . . 53 + 9.2. Receiving the Offer and Generating an Answer . . . . . . 53 + 9.2.1. Procedures for All Implementations . . . . . . . . . 53 + 9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 54 + 9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 54 + 9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 54 + 9.2.2. Procedures for Full Implementations . . . . . . . . . 54 9.2.2.1. Existing Media Streams with ICE Running and no - remote-candidates . . . . . . . . . . . . . . . . 50 + remote-candidates . . . . . . . . . . . . . . . . 55 9.2.2.2. Existing Media Streams with ICE Completed and - no remote-candidates . . . . . . . . . . . . . . . 50 - 9.2.2.3. Existing Media Streams and remote-candidates . . . 50 - 9.2.3. Procedures for Lite Implementations . . . . . . . . . 51 - 9.3. Updating the Check and Valid Lists . . . . . . . . . . . . 52 - 9.3.1. Procedures for Full Implementations . . . . . . . . . 52 - 9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . . 52 - 9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . . 52 - 9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . . 52 - 9.3.1.4. ICE Continuing for Existing Media Stream . . . . . 52 - 9.3.2. Procedures for Lite Implementations . . . . . . . . . 53 - 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 53 - 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 54 - 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 54 - 11.1.1. Procedures for Full Implementations . . . . . . . . . 54 - 11.1.2. Procedures for Lite Implementations . . . . . . . . . 55 - 11.1.3. Procedures for All Implementations . . . . . . . . . . 55 - 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 56 - 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . . 56 - 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . . 56 - 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 56 - 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 58 - 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . . 58 - 12.3. Interactions with Forking . . . . . . . . . . . . . . . . 58 - 12.4. Interactions with Preconditions . . . . . . . . . . . . . 59 - 12.5. Interactions with Third Party Call Control . . . . . . . . 59 - 13. Usage with ANAT . . . . . . . . . . . . . . . . . . . . . . . 59 - 14. Extensibility Considerations . . . . . . . . . . . . . . . . . 60 - 15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 - 15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 61 - 15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 64 - 15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . . 64 - 15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . . 64 - 15.5. "ice-options> Attribute . . . . . . . . . . . . . . . . . 65 - 16. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 - 17. Security Considerations . . . . . . . . . . . . . . . . . . . 72 - 17.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 72 - 17.2. Attacks on Address Gathering . . . . . . . . . . . . . . . 74 - 17.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 75 - 17.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 75 - 17.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 75 - 17.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 76 - 17.5. Interactions with Application Layer Gateways and SIP . . . 76 - 18. Definition of Connectivity Check Usage . . . . . . . . . . . . 77 - 18.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 77 - 18.2. Client Discovery of Server . . . . . . . . . . . . . . . . 78 - 18.3. Server Determination of Usage . . . . . . . . . . . . . . 78 - 18.4. New Requests or Indications . . . . . . . . . . . . . . . 78 - 18.5. New Attributes . . . . . . . . . . . . . . . . . . . . . . 78 - 18.6. New Error Response Codes . . . . . . . . . . . . . . . . . 78 - 18.7. Client Procedures . . . . . . . . . . . . . . . . . . . . 78 - 18.8. Server Procedures . . . . . . . . . . . . . . . . . . . . 78 - 18.9. Security Considerations for Connectivity Check . . . . . . 79 - 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 - 19.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 79 - 19.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 79 - 19.1.2. remote-candidates Attribute . . . . . . . . . . . . . 79 - 19.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . . 80 - 19.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . . 80 - 19.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 81 - 19.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 81 - 19.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 82 - 19.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 82 - 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 82 - 20.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 83 - 20.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 83 - 20.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 84 - 20.4. Requirements for a Long Term Solution . . . . . . . . . . 84 - 20.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 85 - 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 85 - 22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 - 22.1. Normative References . . . . . . . . . . . . . . . . . . . 86 - 22.2. Informative References . . . . . . . . . . . . . . . . . . 87 - Appendix A. Lite and Full Implementations . . . . . . . . . . . . 88 - Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 89 - B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 90 - B.2. Candidates with Multiple Bases . . . . . . . . . . . . . . 90 - B.3. Purpose of the and Attributes . . . 92 - B.4. Importance of the STUN Username . . . . . . . . . . . . . 92 - B.5. The Candidate Pair Sequence Number Formula . . . . . . . . 93 - B.6. The remote-candidates attribute . . . . . . . . . . . . . 94 - B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . . 95 - B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 96 - B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . . 96 - B.10. Why are Binding Indications Used for Keepalives? . . . . . 96 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 97 - Intellectual Property and Copyright Statements . . . . . . . . . . 98 + no remote-candidates . . . . . . . . . . . . . . 55 + 9.2.2.3. Existing Media Streams and remote-candidates . . 55 + 9.2.3. Procedures for Lite Implementations . . . . . . . . . 56 + 9.3. Updating the Check and Valid Lists . . . . . . . . . . . 56 + 9.3.1. Procedures for Full Implementations . . . . . . . . . 56 + 9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 56 + 9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 56 + 9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 56 + 9.3.1.4. ICE Continuing for Existing Media Stream . . . . 57 + 9.3.2. Procedures for Lite Implementations . . . . . . . . . 57 + 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 57 + 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 58 + 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 58 + 11.1.1. Procedures for Full Implementations . . . . . . . . . 59 + 11.1.2. Procedures for Lite Implementations . . . . . . . . . 59 + 11.1.3. Procedures for All Implementations . . . . . . . . . 60 + 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 60 + 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 60 + 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 60 + 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 61 + 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 62 + 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 63 + 12.3. Interactions with Forking . . . . . . . . . . . . . . . . 63 + 12.4. Interactions with Preconditions . . . . . . . . . . . . . 63 + 12.5. Interactions with Third Party Call Control . . . . . . . 63 + 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 64 + 14. Extensibility Considerations . . . . . . . . . . . . . . . . 64 + 15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 + 15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 65 + 15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 67 + 15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 68 + 15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 68 + 15.5. "ice-options> Attribute . . . . . . . . . . . . . . . . . 69 + 16. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 + 17. Security Considerations . . . . . . . . . . . . . . . . . . . 76 + 17.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 76 + 17.2. Attacks on Address Gathering . . . . . . . . . . . . . . 78 + 17.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 79 + 17.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 79 + 17.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 80 + 17.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 80 + 17.5. Interactions with Application Layer Gateways and SIP . . 81 + 18. Definition of Connectivity Check Usage . . . . . . . . . . . 81 + 18.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 82 + 18.2. Client Discovery of Server . . . . . . . . . . . . . . . 82 + 18.3. Server Determination of Usage . . . . . . . . . . . . . . 82 + 18.4. New Requests or Indications . . . . . . . . . . . . . . . 82 + 18.5. New Attributes . . . . . . . . . . . . . . . . . . . . . 82 + 18.6. New Error Response Codes . . . . . . . . . . . . . . . . 83 + 18.7. Client Procedures . . . . . . . . . . . . . . . . . . . . 83 + 18.8. Server Procedures . . . . . . . . . . . . . . . . . . . . 83 + 18.9. Security Considerations for Connectivity Check . . . . . 83 + 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 + 19.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 84 + 19.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 84 + 19.1.2. remote-candidates Attribute . . . . . . . . . . . . . 84 + 19.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 85 + 19.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 85 + 19.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 86 + 19.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 86 + 19.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 86 + 19.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 87 + 19.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 87 + 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 87 + 20.1. Problem Definition . . . . . . . . . . . . . . . . . . . 88 + 20.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 88 + 20.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 89 + 20.4. Requirements for a Long Term Solution . . . . . . . . . . 89 + 20.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 90 + 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 + 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 + 22.1. Normative References . . . . . . . . . . . . . . . . . . 91 + 22.2. Informative References . . . . . . . . . . . . . . . . . 92 + Appendix A. Lite and Full Implementations . . . . . . . . . . . 93 + Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 94 + B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 94 + B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 95 + B.3. Purpose of the and Attributes . . . 97 + B.4. Importance of the STUN Username . . . . . . . . . . . . . 97 + B.5. The Candidate Pair Sequence Number Formula . . . . . . . 98 + B.6. The remote-candidates attribute . . . . . . . . . . . . . 99 + B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 100 + B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 101 + B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 101 + B.10. Why are Binding Indications Used for Keepalives? . . . . 101 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 102 + Intellectual Property and Copyright Statements . . . . . . . . . 103 1. Introduction RFC 3264 [4] defines a two-phase exchange of Session Description Protocol (SDP) messages [10] for the purposes of establishment of multimedia sessions. This offer/answer mechanism is used by protocols such as the Session Initiation Protocol (SIP) [3]. Protocols using offer/answer are difficult to operate through Network Address Translators (NAT). Because their purpose is to establish a @@ -270,21 +275,21 @@ acquisition techniques in [12] and relay allocation procedures in [13]. 2. Overview of ICE In a typical ICE deployment, we have two endpoints (known as AGENTS in RFC 3264 terminology) which want to communicate. They are able to communicate indirectly via some signaling protocol (such as SIP), by which they can perform an offer/answer exchange of SDP [4] messages. Note that ICE is not intended for NAT traversal for SIP, which is - assumed to be provided via another mechanism [35]. At the beginning + assumed to be provided via another mechanism [34]. At the beginning of the ICE process, the agents are ignorant of their own topologies. In particular, they might or might not be behind a NAT (or multiple tiers of NATs). ICE allows the agents to discover enough information about their topologies to potentially find one or more paths by which they can communicate. Figure 1 shows a typical environment for ICE deployment. The two endpoints are labelled L and R (for left and right, which helps visualize call flows). Both L and R are behind their own respective NATs though they may not be aware of it. The type of NAT and its @@ -600,23 +605,23 @@ better results. More fundamentally, however, the prioritization defined by this specification may not yield "optimal" results. As an example, if the aim is to select low latency media paths, usage of a relay is a hint that latencies may be higher, but it is nothing more than a hint. An actual RTT measurement could be made, and it might demonstrate that a pair with lower priority is actually better than one with higher priority. Consequently, ICE assigns one of the agents in the role of the CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The - controlled agent gets to nominate which candidate pairs will get used - for media amongst the ones that are valid. It can do this in one of - two ways - using REGULAR NOMINATION or AGGRESSIVE NOMINATION. + controlling agent gets to nominate which candidate pairs will get + used for media amongst the ones that are valid. It can do this in + one of two ways - using REGULAR NOMINATION or AGGRESSIVE NOMINATION. With regular nomination, the controlling agent lets the checks continue until at least one valid candidate pair for each media stream is found. Then, it picks amongst those that are valid, and sends a second STUN request on its NOMINATED candidate pair, but this time with a flag set to tell the peer that this pair has been nominated for use. A This is shown in Figure 4. L R - - @@ -671,22 +676,21 @@ from any correspondent. To make it easier for these devices to support ICE, ICE defines a special type of implementation called LITE (in contrast to the normal FULL implementation). A lite implementation doesn't gather candidates; it includes only host candidates for any media stream. When a lite implementation connects with a full implementation, the full agent takes the role of the controlling agent, and the lite agent takes on the controlled role. In addition, lite agents do not need to generate connectivity checks, run the state machines, or compute candidate pairs. Additional guidance on when a lite implementation is appropriate, see the - discussion in Appendix A. For an informational summary of ICE - processing as seen by a lite agent, see [36]. + discussion in Appendix A. It is important to note that the lite implementation was added to this specification to provide a stepping stone to full implementation. Even for devices that are always connected to the public Internet, a full implementation is preferable if achievable. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -864,30 +868,35 @@ called the component ID. For RTP-based media streams, the RTP itself has a component ID of 1, and RTCP a component ID of 2. If an agent is using RTCP it MUST obtain a candidate for it. If an agent is using both RTP and RTCP, it would end up with 2*K host candidates if an agent has K interfaces. The base for each host candidate is set to the candidate itself. 4.1.1.2. Server Reflexive and Relayed Candidates - Agents SHOULD obtain relayed candidates and MUST obtain server - reflexive candidates. The requirement to obtain relayed candidates - is at SHOULD strength to allow for provider variation. Use of relays - is expensive, and when ICE is being used, relays will only be - required when both endpoints are behind NATs that perform address and - port dependent mapping. Consequently, some deployments might - consider this use case to be marginal, and elect not to use relays. - If they are not used, it is RECOMMENDED that it be implemented and - just disabled through configuration, so that it can re-enabled - through configuration if conditions change in the future. + Agents SHOULD obtain relayed candidates and SHOULD obtain server + reflexive candidates. These requirements are at SHOULD strength to + allow for provider variation. Use of STUN servers may be unnecessary + in closed networks where agents are never connected to the public + Internet or to endpoints outside of the closed network. In such + cases, a full implementation would be used for agents that are dual- + stack or multi-homed, to select a host candidate. Use of relays is + expensive, and when ICE is being used, relays will only be utilized + when both endpoints are behind NATs that perform address and port + dependent mapping. Consequently, some deployments might consider + this use case to be marginal, and elect not to use relays. If an + agent does not gather server reflexive or relayed candidates, it is + RECOMMENDED that the functionality be implemented and just disabled + through configuration, so that it can re-enabled through + configuration if conditions change in the future. The agent next pairs each host candidate with the STUN server with which it is configured or has discovered by some means. This specification only considers usage of a single STUN server. At that very instance, and then every Ta milliseconds thereafter, the agent chooses another such pair (the order is inconsequential), and sends a STUN request to the server from that host candidate. If the agent is using both relayed and server reflexive candidates, this request MUST be a STUN Allocate request using the relay usage [13]. If the agent is using only server reflexive candidates, the request MUST be a STUN @@ -915,21 +924,22 @@ candidate in the RELAY-ADDRESS attribute. If the Allocate request is rejected because the server lacks resources to fulfill it, the agent SHOULD instead send a Binding Request to obtain a server reflexive candidate. A Binding Response will provide the agent with only a server reflexive candidate (also obtained from the mapped address). The base of the server reflexive candidate is the host candidate from which the Allocate or Binding request was sent. The base of a relayed candidate is that candidate itself. If a relayed candidate is identical to a host candidate (which can happen in rare cases), the relayed candidate MUST be discarded. Proper operation of ICE - depends on each base being unique. + depends on candidate having a unique base when their transport + addresses are identical. 4.1.1.3. Eliminating Redundant Candidates Next, the agent eliminates redundant candidates. A candidate is redundant if its transport address equals another candidate, and its base equals the base of that other candidate. Note that two candidates can have the same transport address yet have different bases, and these would not be considered redundant. 4.1.1.4. Computing Foundations @@ -1169,51 +1179,56 @@ (lines folded for readability): v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 + b=RS:0 + b=RR:0 a=rtpmap:0 PCMU/8000 - a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local + a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 + Once an agent has sent its offer or sent its answer, that agent MUST be prepared to receive both STUN and media packets on each candidate. As discussed in Section 11.1, media packets can be sent to a candidate prior to its appearance as the default destination for media in an offer or answer. 5. Receiving the Initial Offer When an agent receives an initial offer, it will check if the offeror - supports ICE, determine its own role, gather candidates, prioritize - them, choose default candidates, encode and send an answer, and for - full implementations, form the check lists and begin connectivity - checks. + supports sufficient ICE functionality to proceed (i.e., if both + offeror and answerer are lite implementations, ICE cannot proceed), + determine its own role, gather candidates, prioritize them, choose + default candidates, encode and send an answer, and for full + implementations, form the check lists and begin connectivity checks. 5.1. Verifying ICE Support The answerer will proceed with the ICE procedures defined in this specification if the following are all true: o For each media stream, the default destination for at least one component of the media stream appears in a candidate attribute. For example, in the case of RTP, the IP address and port in the c and m line, respectively, appears in a candidate attribute, or the value in the rtcp attribute appears in a candidate attribute. o The offer omitted an a=ice-lite attribute or the answerer is a - full implementation. + full implementation. In other words, if both agents are lite + implementations, the agent does not proceed with ICE. If any of these conditions are not met, the agent MUST process the SDP based on normal RFC 3264 procedures, without using any of the ICE mechanisms described in the remainder of this specification with the following exceptions: 1. The agent MUST follow the rules of Section 10, which describe keepalive procedures for all agents. 2. If the agent is not proceeding with ICE because there were @@ -1231,23 +1246,31 @@ pairs to use for each media stream, and does not generate an updated offer to signal this information. If one of the agents is a lite implementation, it MUST assume the controlled role, and its peer (which will be full; if it was lite, ICE would have aborted) MUST assume the controlling role. If the agent and its peer are both full implementations, the agent which generated the offer which started the ICE processing takes on the controlling role, and the other takes the controlled role. - Based on this definition, once roles are determined for a session, - they persist unless ICE is restarted. A ICE restart (Section 9.1 - causes a new selection of roles. + In unusual cases it is possible for both agents to mistakenly believe + they are controlled or controlling. To deal with such cases, at the + time an agent determines its role, it MUST select a random number, + called the tie-breaker, uniformly distributed between 0 and (2**64) - + 1 (that is, a 64 bit positive integer). This number is used in STUN + checks to detect and repair this case, as described in + Section 7.1.1.2. + + Once roles are determined for a session, they persist unless ICE is + restarted. A ICE restart (Section 9.1 causes a new selection of + roles and tie-breakers. 5.3. Gathering Candidates The process for gathering candidates at the answerer is identical to the process for the offerer as described in Section 4.1.1 for full implementations and Section 4.2 for lite implementations. It is RECOMMENDED that this process begin immediately on receipt of the offer, prior to alerting the user. Such gathering MAY begin when an agent starts. @@ -1260,21 +1283,22 @@ 5.5. Choosing Default Candidates The process for selecting default candidates at the answerer is identical to the process followed by the offerer, as described in Section 4.1.3 for full implementations and Section 4.2 for lite implementations. 5.6. Encoding the SDP The process for encoding the SDP at the answerer is identical to the - process followed by the offerer, as described in Section 4.3. + process followed by the offerer for both full and lite + implementations, as described in Section 4.3. 5.7. Forming the Check Lists Forming check lists is done only by full implementations. Lite implementations MUST skip the steps defined in this section. There is one check list per in-use media stream resulting from the offer/answer exchange. To form the check list for a media stream, the agent forms candidate pairs, computes a candidate pair priority, orders the pairs by priority, prunes them, and sets their states. @@ -1471,75 +1495,81 @@ +-----------+ +-----------+ Figure 9: Pair State FSM The initial states for each pair in the check list are computed by performing the following sequence of steps: 1. The agent sets all of the pairs in each check list to the Frozen state. - 2. It takes the first pair in the check list for the first media - stream (a media stream is the first media stream when it is - described by the first m-line in the SDP offer and answer), and - sets its state to Waiting. + 2. The agent examines the check list for the first media stream (a + media stream is the first media stream when it is described by + the first m-line in the SDP offer and answer). For that media + stream, it: - 3. It finds all of the other pairs in that check list with the same - component ID, but different foundations, and sets all of their - states to Waiting as well. + * Groups together all of the pairs with the same foundation, + + * For each group, sets the state of the pair with the lowest + component ID to Waiting. If there is more than one such pair, + the one with the highest priority is used. One of the check lists will have some number of pairs in the Waiting state, and the other check lists will have all of their pairs in the - Frozen state. A check list with at least one pair that is not Frozen - is called an active check list. + Frozen state. A check list with at least one pair that is Waiting is + called an active check list, and a check list with all pairs frozen + is called a frozen check list. The check list itself is associated with a state, which captures the state of ICE checks for that media stream. There are two states: Running: In this state, ICE checks are still in progress for this media stream. - Completed: In this state, ICE checks have completed for this media - stream. + Completed: In this state, ICE checks have completed successfully for + this media stream. + + Failed: In this state, the ICE checks have not completed + successfully for this media stream. When a check list is first constructed as the consequence of an offer/answer exchange, it is placed in the Running state. ICE processing across all media streams also has a state associated with it. This state is equal to Running while checks are in progress. The state is Completed when all checks have been completed. Rules for transitioning between states are described below. 5.8. Performing Periodic Checks Checks are generated only by full implementations. Lite implementations MUST skip the steps described in this section. An agent performs periodic checks and triggered checks. Periodic checks occur periodically for each media stream, and involve choosing the highest priority pair in the Waiting state from each check list, and sending a check on it. Triggered checks are performed on receipt - of a connectivity check from the peer (see Section 7.2.1.3). This + of a connectivity check from the peer (see Section 7.2.1.4). This section describes how periodic checks are performed. Once the agent has computed the check lists as described in Section 5.7, it sets a timer for each active check list. The timer - fires every Ta/N seconds, where N is the number of active check lists + fires every Ta*N seconds, where N is the number of active check lists (initially, there is only one active check list). Implementations MAY set the timer to fire less frequently than this. Ta is the same value used to pace the gathering of candidates, as described in - Section 4.1.1. Dividing by N allows this aggregate check throughput - to be split between all active check lists. The first timer for each - active check list fires immediately, so that the agent performs a - connectivity check the moment the offer/answer exchange has been - done, followed by the next periodic check Ta seconds later. + Section 4.1.1. Multiplying by N allows this aggregate check + throughput to be split between all active check lists. The first + timer for each active check list fires immediately, so that the agent + performs a connectivity check the moment the offer/answer exchange + has been done, followed by the next periodic check Ta seconds later. When the timer fires, the agent MUST: o Find the highest priority pair in that check list that is in the Waiting state. o If there is such a pair: * Send a STUN check from the local candidate of that pair to the remote candidate of that pair. The procedures for forming the @@ -1552,22 +1582,20 @@ * If there is such a pair: + Unfreeze the pair. + Perform a check for that pair, causing its state to transition to In-Progress. * If there is no such pair: - + Set the state of the check list to Completed. - + Terminate the timer for that check list. To compute the message integrity for the check, the agent uses the remote username fragment and password learned from the SDP from its peer. The local username fragment is known directly by the agent for its own candidate. 6. Receipt of the Initial Answer This section describes the procedures that an agent follows when it @@ -1648,21 +1676,29 @@ that the type preference is set to the value for peer derived candidate types. The controlling agent MAY include the USE-CANDIDATE attribute in the Binding Request. The controlled agent MUST NOT include it in its Binding Request. This attribute signals that the controlling agent wishes to cease checks for this component, and use the candidate pair resulting from the check for this component. Section 8.1 provides guidance on determining when to include it. -7.1.1.2. Forming Credentials +7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING + + The agent MUST include the ICE-CONTROLLED attribute in the request if + it is in the controlled role, and MUST include the ICE-CONTROLLING + attribute in the request if it is in the controlling role. The + content of either attribute MUST be the tie breaker that was + determined in Section 5.2. + +7.1.1.3. Forming Credentials A Binding Request serving as a connectivity check MUST utilize a STUN short term credential. The agent MUST include the USERNAME and MESSAGE-INTEGRITY attributes. An agent MUST NOT wait to be challenged for short term credentials. Rather, it MUST provide them in each Binding Request. Rather than being learned from a Shared Secret request, the short term credential is exchanged in the offer/answer procedures. In particular, the username is formed by concatenating the username @@ -1670,55 +1706,71 @@ sending the request, separated by a colon (":"). The password is equal to the password provided by the peer. For example, consider the case where agent L is the offerer, and agent R is the answerer. Agent L included a username fragment of LFRAG for its candidates, and a password of LPASS. Agent R provided a username fragment of RFRAG and a password of RPASS. A connectivity check from L to R (and its response of course) utilize the username RFRAG:LFRAG and a password of RPASS. A connectivity check from R to L (and its response) utilize the username LFRAG:RFRAG and a password of LPASS. -7.1.1.3. DiffServ Treatment +7.1.1.4. DiffServ Treatment If the agent is using Diffserv Codepoint markings [27] in its media packets, it SHOULD apply those same markings to its connectivity checks. 7.1.2. Processing the Response When a Binding Response is received, it is correlated to its Binding Request using the transaction ID, as defined in [12], which then ties it to the candidate pair for which the Binding Request was sent. 7.1.2.1. Failure Cases + If the STUN transaction generates a 487 (Role Conflict) error + response, the agent checks whether it had included the ICE-CONTROLLED + or ICE-CONTROLLING attribute in the Binding Request. If the request + had contained the ICE-CONTROLLED attribute, the agent MUST switch to + the controlling role if it has not already done so. If the request + had contained the ICE-CONTROLLING attribute, the agent MUST switch to + the controlled role if it has not already done so. Once it has + switched, the agent MUST immediately retry the request with the ICE- + CONTROLLING or ICE-CONTROLLED attribute reflecting its new role. + Note, however, that the tie-breaker value MUST NOT be reselected. + If the STUN transaction generates an ICMP error, or generates a STUN error response that is unrecoverable (as defined in [12], or times out, the agent sets the state of the pair to Failed. The agent MUST check that the source IP address and port of the response equals the destination IP address and port that the Binding Request was sent to, and that the destination IP address and port of the response match the source IP address and port that the Binding Request was sent from. In other words, the source and destination transport addresses in the request and responses are the symmetric. If they are not symmetric, the agent sets the state of the pair to Failed. 7.1.2.2. Success Cases - If the STUN transaction generated a response between 200 and 299, and - the source IP address and port of the response equals the destination - IP address and port that the Binding Request was sent to, and the - destination IP address and port of the response match the source IP - address and port that the Binding Request was sent from, the check - was a success. + A check is considered to be a success if all of the following are + true: + + o the STUN transaction generated a success response + + o the source IP address and port of the response equals the + destination IP address and port that the Binding Request was sent + to + + o the destination IP address and port of the response match the + source IP address and port that the Binding Request was sent from 7.1.2.2.1. Discovering Peer Reflexive Candidates The agent checks the mapped address from the STUN response. If the transport address does not match any of the local candidates that the agent knows about, the mapped address represents a new candidate - a peer reflexive candidate. Like other candidates, it has a type, base, priority and foundation. They are computed as follows: o Its type is equal to peer reflexive. @@ -1739,37 +1791,58 @@ from it momentarily based on the procedures in Section 7.1.2.2.3. If an agent wishes to pair the peer reflexive candidate with other remote candidates besides the one in the valid pair that will be generated, the agent MAY generate an updated offer which includes the peer reflexive candidate. This will cause it to be paired with all other remote candidates. 7.1.2.2.2. Updating Pair States The agent sets the state of the pair that generated the check to - succeeded. The agent sees if the success for this pair can cause - other pairs to be unfrozen. There are three cases: + Succeeded. The success of this check might also cause the state of + other checks to change as well. The agent MUST perform the following + two steps: - o If the pair had a component ID of 1, the agent MUST change the - states for all other Frozen pairs for the same media stream and - same foundation, but different component IDs, to Waiting. + 1. The agent changes the states for all other Frozen pairs for the + same media stream and same foundation to Waiting. Typically + these other pairs will have different component IDs but not + always. - o If the pair had a component ID equal to the number of components - for the media stream (where this is the actual number of - components being used, in cases where the number of components - signaled in the SDP differs from offerer to answerer), the agent - MUST change the state for all other Frozen pairs for the first - component of different media streams (and thus in different check - lists) but the same foundation, to Waiting. + 2. If there is a pair in the valid list for every component of this + media stream (where this is the actual number of components being + used, in cases where the number of components signaled in the SDP + differs from offerer to answerer), the success of this check may + unfreeze checks for other media streams. Note that this step is + followed not just the first time the valid list under + consideration has a pair for every component, but every + subsequent time a check succeeds and adds yet another pair to + that valid list. The agent examines the check list for each + other media stream in turn: - o If the pair has any other component ID, no other pairs can be - unfrozen. + * If the check list is active, the agent changes the state of + all Frozen pairs in that check list whose foundation matches a + pair in the valid list under consideration, to Waiting. + + * If the check list is frozen, and there is at least one pair in + the check list whose foundation matches a pair in the valid + list under consideration, the state of all pairs in the check + list whose foundation matches a pair in the valid list under + consideration are set to Waiting. + + * If the check list is frozen, and there are no pairs in the + check list whose foundation matches a pair in the valid list + under consideration, the agent + + + Groups together all of the pairs with the same foundation, + + For each group, sets the state of the pair with the lowest + component ID to Waiting. If there is more than one such + pair, the one with the highest priority is used. 7.1.2.2.3. Constructing a Valid Pair Next, the agent constructs a candidate pair whose local candidate equals the mapped address of the response, and whose remote candidate equals the destination address to which the request was sent. This is called a valid pair, since it has been validated by a STUN connectivity check. The valid pair may equal the pair that generated the check, may equal a different pair in the check list, or may be a pair not currently on any check list. If the pair equals the pair @@ -1799,106 +1872,196 @@ a new remote candidate. In that case, the priority is taken as the value of the PRIORITY attribute in the Binding Request which triggered the check that just completed. The pair is then added to the VALID LIST. 7.1.2.2.4. Updating the Nominated Flag If the agent was a controlling agent, and it had included a USE- CANDIDATE attribute in the Binding Request, the valid pair generated from that check has its nominated flag set to true. This flag - indicates that this candidate should be used for media if it is the + indicates that this valid pair should be used for media if it is the highest priority one amongst those whose nominated flag is set. This may conclude ICE processing for this media stream or all media streams; see Section 8. If the agent is the controlled agent, the response may result in the - valid pair having its nominated flag set. See Section 7.2.1.4 for + valid pair having its nominated flag set. See Section 7.2.1.5 for the procedure. +7.1.2.3. Check List and Timer State Updates + + Regardless of whether the check was successful or failed, the + completion of the transaction may require updating of check list and + timer states. + + If all of the pairs in the check list are now either in the Failed or + Succeeded state, and there is not a pair in the valid list for each + component of the media stream, the state of the check list is set to + Failed. For each frozen check list, the agent: + + o Groups together all of the pairs with the same foundation, + + o For each group, sets the state of the pair with the lowest + component ID to Waiting. If there is more than one such pair, the + one with the highest priority is used. + + If none of the pairs in the check list are in the Waiting or Frozen + state, the check list is no longer considered active, and will not + count towards the value of N in the computation of timers for + periodic checks as described in Section 5.8. + 7.2. Server Procedures An agent MUST be prepared to receive a Binding Request on the base of each candidate it included in its most recent offer or answer. Receipt of a Binding Request on a base is an indication that the connectivity check usage applies to the request. The agent MUST use a short term credential to authenticate the request and perform a message integrity check. The agent MUST accept a credential if the username consists of two values separated by a colon, where the first value is equal to the username fragment generated by the agent in an offer or answer for a session in- progress, and the MESSAGE-INTEGRITY is the output of a hash of the password and the STUN packet's contents. It is possible (and in fact very likely) that an offeror will receive a Binding Request prior to - receiving the answer from its peer. However, the request can be - processed without receiving this answer, and a response generated. - By doing this, ICE processing completes faster. + receiving the answer from its peer. If this happens, the agent MUST + generate a response (including computation of the mapped address as + described in Section 7.2.1.2. Once the answer is received, it MUST + proceed with the remaining steps required, namely Section 7.2.1.3, + Section 7.2.1.4, and Section 7.2.1.5 for full implementations. In + cases where multiple STUN requests are received before the answer, + this may cause several triggered notifications to all be sent at the + same time, If the agent is using Diffserv Codepoint markings [27] in its media packets, it SHOULD apply those same markings to its responses to - Binding Requests. + Binding Requests. The same would apply to any layer 2 markings the + endpoint might be applying to media packets. 7.2.1. Additional Procedures for Full Implementations This subsection defines the additional server procedures applicable - to full implementations when generating a successful response to a - Binding Request. + to full implementations. -7.2.1.1. Computing Mapped Address +7.2.1.1. Detecting and Repairing Role Conflicts + + Normally, the rules for selection of a role in Section 5.2 will + result in each agent selecting a different role - one controlling, + and one controlled. However, in unusual call flows, typically + utilizing third party call control, it is possible for both agents to + select the same role. This section describes procedures for checking + for this case and repairing it. + + An agent MUST examine the Binding Request for either the ICE- + CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these + procedures: + + o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the + request, there is no conflict. + + o If the agent is in the controlling role, and the ICE-CONTROLLING + attribute is present in the request: + + * If the agent's tie-breaker is larger than or equal to the + contents of the ICE-CONTROLLING attribute, the agent generates + a Binding Error Response and includes an ERROR-CODE attribute + with a value of 487 (Role Conflict) but retains its role. + + * If the agent's tie-breaker is less than the contents of the + ICE-CONTROLLING attribute, the agent switches to the controlled + role. + + o If the agent is in the controlled role, and the ICE-CONTROLLED + attribute is present in the request: + + * If the agent's tie-breaker is larger than or equal to the + contents of the ICE-CONTROLLED attribute, the agent switches to + the controlling role. + + * If the agent's tie-breaker is less than the contents of the + ICE-CONTROLLED attribute, the agent generates a Binding Error + Response and includes an ERROR-CODE attribute with a value of + 487 (Role Conflict) but retains its role. + + o If the agent is in the controlled role and the ICE-CONTROLLING + attribute was present in the request, or the agent was in the + controlling role and the ICE-CONTROLLED attribute was present in + the request, there is no conflict. + + The remaining sections in Section 7.2.1 are followed if the server + generated a successful response to the Binding Request, even if the + agent changed roles. + +7.2.1.2. Computing Mapped Address For requests being received on a relayed candidate, the source transport address used for STUN processing (namely, generation of the XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the relay. That source transport address will be present in the REMOTE- ADDRESS attribute of a STUN Data Indication message, if the Binding Request was delivered through a Data Indication (a STUN relay delivers packets encapsulated in a Data Indication when no active destination is set). If the Binding Request was not encapsulated in a Data Indication, that source address is equal to the current active destination for the STUN relay session. -7.2.1.2. Learning Peer Reflexive Candidates +7.2.1.3. Learning Peer Reflexive Candidates If the source transport address of the request does not match any existing remote candidates, it represents a new peer reflexive remote - candidate. The full-mode agent gives the candidate a priority equal - to the PRIORITY attribute from the request. The type of the - candidate is equal to peer reflexive. Its foundation is set to an - arbitrary value, different from the foundation for all other remote - candidates. If any subsequent offer/answer exchanges contain this - peer reflexive candidate in the SDP, it will signal the actual - foundation for the candidate. This candidate is then added to the - list of remote candidates. However, the agent does not pair this - candidate with any local candidates. + candidate. This candidate is constructed as follows: -7.2.1.3. Triggered Checks + o The priority of the candidate is set to the PRIORITY attribute + from the request. + + o The type of the candidate is set to peer reflexive. + + o The foundation of the candidate is set to an arbitrary value, + different from the foundation for all other remote candidates. If + any subsequent offer/answer exchanges contain this peer reflexive + candidate in the SDP, it will signal the actual foundation for the + candidate. + + o The component ID of this candidate is set to the component ID for + the local candidate to which the request was sent. + + This candidate is added to the list of remote candidates. However, + the agent does not pair this candidate with any local candidates. + +7.2.1.4. Triggered Checks Next, the agent constructs a pair whose local candidate is equal to the transport address on which the STUN request was received, and a remote candidate equal to the source transport address where the request came from (which may be peer-reflexive remote candidate that was just learned). Since both candidates are known to the agent, it can obtain their priorities and compute the candidate pair priority. This pair is then looked up in the check list. There can be one of several outcomes: o If the pair is already on the check list: * If the state of that pair is Waiting or Frozen, its state is changed to In-Progress and a check for that pair is performed immediately. This is called a triggered check. * If the state of that pair is In-Progress, the agent SHOULD generate an immediate retransmit of the Binding Request for the check in progress. This is to facilitate rapid completion of - ICE when both agents are behind NAT. + ICE when both agents are behind NAT. It is RECOMMENDED that, + after the immediate retransmit, the next retransmission occur T + milliseconds later, where T is the current STUN retransmit + interval. If the immediate retransmit causes the total number + of requests transmitted to equal the maximum value defined in + [12], the agent SHOULD NOT send any further retransmits. * If the state of that pair is Failed or Succeeded, no triggered check is sent. o If the pair is not already on the check list: * The pair is inserted into the check list based on its priority * Its state is set to In-Progress @@ -1911,25 +2074,25 @@ candidate is equal to the part after the colon of the USERNAME in the Binding Request that was just received. Using that username fragment, the agent can check the SDP messages received from its peer (there may be more than one in cases of forking), and find this username fragment. The corresponding password is then selected. If agent has not yet received the username in an SDP (a likely case for the offerer in the initial offer/answer exchange), it MUST wait for the SDP to be received (since it won't have its peer's ICE password without it), and then proceed with the triggered check. -7.2.1.4. Updating the Nominated Flag +7.2.1.5. Updating the Nominated Flag If the Binding Request received by the agent had the USE-CANDIDATE attribute set, and the agent is in the controlled role, the agent - looks at the state of the pair computed in Section 7.2.1.3: + looks at the state of the pair computed in Section 7.2.1.4: o If the state of this pair is succeeded, it means that the check generated by this pair produced a successful response. This would have caused the agent to construct a valid pair when that success response was received (see Section 7.1.2.2.3). The agent now sets the nominated flag in the valid pair to true. This may end ICE processing for this media stream; see Section 8. o If the state of this pair is In-Progress, if its check produces a successful result, the resulting valid pair has its nominated flag @@ -1986,21 +2149,21 @@ the nominated flag of that and only that pair to be set. Consequently, there will be only a single nominated pair in the valid list, and when the state of the check list moves to completed, that exact pair is selected by ICE for sending and receiving media. Regular nomination provides the most flexibility, since the agent has control over the stopping and selection criteria for checks. The only requirement is that the agent MUST eventually pick one and only one candidate pair and generate a check for that pair with the USE- CANDIDATE attribute present. Regular nomination also improves ICE's - resilience to variations in implementation (see Section 14. Regular + resilience to variations in implementation (see Section 14). Regular nomination is also more stable, allowing both agents to converge on a single pair for media without any transient selections, which can happen with the aggressive algorithm. The drawback of regular nomination is that it is guaranteed to increase latencies because it requires an additional check to be done. 8.1.2. Aggressive Nomination With aggressive nomination, the controlling agent includes the USE- CANDIDATE attribute in every check it sends. Once the first check @@ -2011,66 +2174,85 @@ complete, causing another valid pair to have its nominated flag set. ICE always selects the highest priority nominated candidate pair from the valid list as the one used for media. Consequently, the selected pair may actually change briefly as ICE checks complete, resulting in a set of transient selections until it stabilizes. 8.2. Updating States For both controlling and controlled agents, the state of ICE processing depends on the presence of nominated candidate pairs in - the valid list: + the valid list and on the state of the check list: o If there are no nominated pairs in the valid list for a media - stream, ICE processing continues. + stream and the state of the check list is Running, ICE processing + continues. - o If there is at least one nominated pair in the valid list: + o If there is at least one nominated pair in the valid list for a + media stream and the state of the check list is Running: * The agent MUST remove all Waiting and Frozen pairs in the check list for the same component as the nominated pairs for that media stream * If an In-Progress pair in the check list is for the same component as a nominated pair, the agent SHOULD cease retransmissions for its check if its pair priority is lower than the lowest priority nominated pair for that component o Once there is at least one nominated pair in the valid list for - every component of at least one media stream: + every component of at least one media stream and the state of the + check list is Running: * The agent MUST change the state of processing for its check list for that media stream to Completed. * The agent MUST continue to respond to any checks it may still receive for that media stream, and MUST perform triggered checks if required by the processing of Section 7.2. * The agent MAY begin transmitting media for this media stream as described in Section 11.1 - o Once there is at least one nominated pair in the valid list for - each component of each media stream: + + o Once the state of each check list is Completed: * The agent sets the state of ICE processing overall to Completed. * If an agent is controlling, it examines the highest priority nominated candidate pair for each component of each media stream. If any of those candidate pairs differ from the default candidate pairs in the most recent offer/answer exchange, the controlling agent MUST generate an updated offer as described in Section 9. If the controlling agent is using an aggressive nomination algorithm, this may result in several updated offers as the pairs selected for media change. An agent MAY delay sending the offer for a brief interval (one second is RECOMMENDED) in order to allow the selected pairs to stabilize. + o If the state of the check list is Failed, ICE has not been able to + complete for this media stream. The correct behavior depends on + the state of the check lists for other media streams: + + * If all check lists are Failed, the agent SHOULD consider the + session a failure, SHOULD NOT restart ICE, and the controlling + agent SHOULD terminate the entire session. + + * If at least one of the check lists for other media streams is + Completed, the controlling agent SHOULD remove the failed media + stream from the session in its updated offer. + + * If none of the check lists for other media streams are + Completed, but at least one is Running, the agent SHOULD let + ICE continue. + 9. Subsequent Offer/Answer Exchanges Either agent MAY generate a subsequent offer at any time allowed by RFC 3264 [4]. The rules in Section 8 will cause the controlling agent to send an updated offer at the conclusion of ICE processing when ICE has selected different candidate pairs from the default pairs. This section defines rules for construction of subsequent offers and answers. 9.1. Generating the Offer @@ -2695,62 +2876,37 @@ never generate a re-INVITE. The flows for continued operation, as described in Section 7 of RFC 3725, require additional behavior of ICE implementations to support. In particular, if an agent receives a mid-dialog re-INVITE that contains no offer, it MUST restart ICE for each media stream and go through the process of gathering new candidates. Furthermore, that list of candidates SHOULD include the ones currently being used for media. -13. Usage with ANAT +13. Relationship with ANAT RFC 4091 [11] defines a mechanism for indicating that an agent can support both IPv4 and IPv6 for a media stream, and it does so by including two m-lines, one for v4, and one for v6. This is similar to ICE, which allows for an agent to indicate multiple transport - addresses using the candidate attribute. - - However, ICE is not a replacement for ANAT. When an agent has a v4 - and v6 interface and requires just a static choice of address - use - v6 if both support v6, else v4 - ANAT alone is used. If an agent - wishes the choice of v4 or v6 to be dynamic and depend on actual - verification of connectivity, an agent would use ANAT in concert with - ICE. To do that, The agent MUST include two media stream alternates, - one for v4 and one for v6, as defined in RFC 4091. In addition, the - agent MUST include a v4 candidate as a session attribute for the v4 - stream alternate, and a v6 candidate as a session attribute of the v6 - stream alternate. ICE will then perform its checks for each stream - alternate. The agent MUST order the ICE selected pairs for each - stream alternate based on their mid preference, and choose the - highest one. This means that if ICE doesn't select any pair for a - stream alternate (because, for example, no checks succeeded), the - agent will choose the next highest preference pair which was - selected. This allows v6 to be used if a v6 path can be verified, - but to fallback to v4 if it cannot be verified. - - This extends naturally to multiple candidates for each alternate. An - agent MAY include multiple v4 candidates for the v4 stream alternate - and multiple v6 candidates for the v6 stream alternate. All of the - candidates for a v4 stream alternate MUST be v4, and all of the - candidates for a v6 stream alternate MUST be v6. This will cause ICE - to choose a v6 pair as long as one of the pairs works, else it will - fall back to v4. + addresses using the candidate attribute. However, ANAT relies on + static selection to pick between choices, rather than a dynamic + connectivity check used by ICE. - Of course, an agent can use ICE with v4 and v6 candidates without - ANAT. In that mode, it would have just a single media stream, with a - default destination that is either v4 or v6. The candidates can - include both v4 and v6 candidates. This brings an agent the - flexibility of choosing a v4 candidate even if a v6 candidate - validates, perhaps due to differing path characteristics measured - dynamically by the agent. That kind of flexibility is not possible - when ANAT is used. + This specification deprecates RFC 4091. Instead, agents wishing to + support dual-stack will utilize ICE. Because a dual-stack agent will + require at least two candidates, one for IPv4 and one for IPv6, dual- + stack agents MUST be full implementations. However, agents that are + implementing dual-stack and are running on closed networks where it + is known that there are no NAT, MAY include only host candidates in + their offers, skipping server reflexive and relayed candidates. 14. Extensibility Considerations This specification makes very specific choices about how both agents in a session coordinate to arrive at the set of candidate pairs that are selected for media. It is anticipated that future specifications will want to alter these algorithms, whether they are simple changes like timer tweaks, or larger changes like a revamp of the priority algorithm. When such a change is made, providing interoperability between the two agents in a session is critical. @@ -2780,21 +2936,21 @@ regular nomination algorithm. When regular nomination is used, ICE will converge perfectly even when both agents use different pair prioritization algorithms. One of the keys to such convergence are triggered checks, which ensure that the nominated pair is validated by both agents. Consequently, any future ICE enhancements MUST preserve triggered checks. ICE is also extensible to other media streams beyond RTP, and for transport protocols beyond UDP. Extensions to ICE for non-RTP media streams need to specify how many components they utilize, and assign - component IDS to them, starting at 1 for the most important component + component IDs to them, starting at 1 for the most important component ID. Specifications for new transport protocols must define how, if at all, various steps in the ICE processing differ from UDP. 15. Grammar This specification defines seven new SDP attributes - the "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- ufrag", "ice-pwd" and "ice-options" attributes. 15.1. "candidate" Attribute @@ -2828,21 +2984,21 @@ rel-port = "rport" SP port extension-att-name = byte-string ;from RFC 4566 extension-att-value = byte-string ice-char = ALPHA / DIGIT / "+" / "/" This grammar encodes the primary information about a candidate: its IP address, port and transport protocol, and its properties: the foundation, component ID, priority, type, and related transport address: - : is taken from RFC 4566 [10]. It is the IP + : is taken from RFC 4566 [10]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses and FQDNs. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS using an A or AAAA record, and the resulting IP address is used for the remainder of ICE processing. : is also taken from RFC 4566 [10]. It is the port of the candidate. @@ -3134,73 +3290,82 @@ offer (message 5) looks like (lines folded for clarity): v=0 o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP s= c=IN IP4 $NAT-PUB-1.IP t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio $NAT-PUB-1.PORT RTP/AVP 0 + b=RS:0 + b=RR:0 a=rtpmap:0 PCMU/8000 - a=candidate:1 1 UDP 2130706178 $L-PRIV-1.IP $L-PRIV-1.PORT typ local + a=candidate:1 1 UDP 2130706178 $L-PRIV-1.IP $L-PRIV-1.PORT typ host a=candidate:2 1 UDP 1694498562 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT The offer, with the variables replaced with their values, will look like (lines folded for clarity): v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 + b=RS:0 + b=RR:0 a=rtpmap:0 PCMU/8000 - a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local + a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 This offer is received at agent R. Agent R will obtain a host candidate, and from it, obtain a server reflexive candidate (messages 6-7). Since R is not behind a NAT, this candidate is identical to its host candidate, and they share the same base. It therefore discards this redundant candidate and ends up with a single host candidate. With identical type and local preferences as L, the priority for this candidate is 2130706178. It chooses a foundation of 1 for its single candidate. Its resulting answer looks like: v=0 o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP s= c=IN IP4 $R-PUB-1.IP t=0 0 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-ufrag:9uB6 m=audio $R-PUB-1.PORT RTP/AVP 0 + b=RS:0 + b=RR:0 a=rtpmap:0 PCMU/8000 - a=candidate:1 1 UDP 2130706178 $R-PUB-1.IP $R-PUB-1.PORT typ local + a=candidate:1 1 UDP 2130706178 $R-PUB-1.IP $R-PUB-1.PORT typ host With the variables filled in: v=0 o=bob 2808844564 2808844564 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.1 t=0 0 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-ufrag:9uB6 m=audio 3478 RTP/AVP 0 + b=RS:0 + b=RR:0 a=rtpmap:0 PCMU/8000 - a=candidate:1 1 UDP 2130706178 192.0.2.1 3478 typ local + a=candidate:1 1 UDP 2130706178 192.0.2.1 3478 typ host + Since neither side indicated that they are lite, the agent which sent the offer that began ICE processing (agent L) becomes the controlling agent. Agents L and R both pair up the candidates. They both initially have two pairs. However, agent L will prune the pair containing its server reflexive candidate, resulting in just one. At agent L, this pair has a local candidate of $L_PRIV_1 and remote candidate of $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that an implementation would represent this as a 64 bit integer so as not @@ -3547,35 +3712,54 @@ addresses in its candidates on which it expects to receive STUN packets. Consequently, any STUN packets received on the base of a candidate offered in SDP will be for the connectivity check usage. 18.4. New Requests or Indications This usage does not define any new message types. 18.5. New Attributes - This usage defines two new attributes, PRIORITY and USE-CANDIDATE. + This usage defines four new attributes, PRIORITY, USE-CANDIDATE, ICE- + CONTROLLED and ICE-CONTROLLING. The PRIORITY attribute indicates the priority that is to be associated with a peer reflexive candidate, should one be discovered by this check. It is a 32 bit unsigned integer, and has an attribute value of 0x0024. The USE-CANDIDATE attribute indicates that the candidate pair resulting from this check should be used for transmission of media. The attribute has no content (the Length field of the attribute is zero); it serves as a flag. It has an attribute value of 0x0025. + The ICE-CONTROLLED attribute is present in a Binding Request, and + indicates that the client believes it is currently in the controlled + role. The content of the attribute is a 64 bit unsigned integer in + network byte ordering, which contains a random number used for tie- + breaking of role conflicts. + + The ICE-CONTROLLING attribute is present in a Binding Request, and + indicates that the client believes it is currently in the controlling + role. The content of the attribute is a 64 bit unsigned integer in + network byte ordering, which contains a random number used for tie- + breaking of role conflicts. + 18.6. New Error Response Codes - This usage does not define any new error response codes. + This usage defines a single error response code: + + 487 (Role Conflict): The Binding Request contained either the ICE- + CONTROLLING or ICE-CONTROLLED attribute, indicating a role that + conflicted with the server. The server ran a tie-breaker based on + the tie-breaker value in the request, and determined that the + client needs to switch roles. 18.7. Client Procedures Client procedures are defined in Section 7.1. 18.8. Server Procedures Server procedures are defined in Section 7.2. 18.9. Security Considerations for Connectivity Check @@ -3732,25 +3917,34 @@ Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates the ICE options or extensions used by the agent. Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: please replace XXXX with the RFC number of this specification]. 19.2. STUN Attributes - This section registers two new STUN attributes per the procedures in + This section registers four new STUN attributes per the procedures in [12]. 0x0024 PRIORITY 0x0025 USE-CANDIDATE + 0x8029 ICE-CONTROLLED + 0x802a ICE-CONTROLLING + +19.3. STUN Error Responses + + This section registers one new STUN error response code per the + procedures in [12]. + + 487 Role Conflict 20. IAB Considerations The IAB has studied the problem of "Unilateral Self Address Fixing", which is the general process by which a agent attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [21]. ICE is an example of a protocol that performs this type of function. Interestingly, the process for ICE is not unilateral, but bilateral, and the difference has a signficant impact on the issues raised by IAB. @@ -3877,36 +4071,37 @@ for IP addresses, either in text or binary form within a packet, and rewrite them if they match a binding. This interferes with traditional STUN. However, the update to STUN [12] uses an encoding which hides these binary addresses from generic ALGs. Existing NAPT boxes have non-deterministic and typically short expiration times for UDP-based bindings. This requires implementations to send periodic keepalives to maintain those bindings. ICE uses a default of 15s, which is a very conservative estimate. Eventually, over time, as NAT boxes become compliant to - behave [34], this minimum keepalive will become deterministic and + behave [29], this minimum keepalive will become deterministic and well-known, and the ICE timers can be adjusted. Having a way to discover and control the minimum keepalive interval would be far better still. 21. Acknowledgements The authors would like to thank Dan Wing, Eric Rescorla, Flemming Andreasen, Rohan Mahy, Dean Willis, Eric Cooper, Jason Fischl, - Douglas Otis, Tim Moore, Jean-Francois Mule, and Francois Audet for - their comments and input. A special thanks goes to Bill May, who - suggested several of the concepts in this specification, Philip - Matthews, who suggested many of the key performance optimizations in - this specification, Eric Rescorla, who drafted the text in the - introduction, and Magnus Westerlund, for doing several detailed - reviews on the various revisions of this specification. + Douglas Otis, Tim Moore, Jean-Francois Mule, Jonathan Lennox and + Francois Audet for their comments and input. A special thanks goes + to Bill May, who suggested several of the concepts in this + specification, Philip Matthews, who suggested many of the key + performance optimizations in this specification, Eric Rescorla, who + drafted the text in the introduction, and Magnus Westerlund, for + doing several detailed reviews on the various revisions of this + specification. 22. References 22.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. @@ -4021,33 +4216,24 @@ [31] Andreasen, F., "A No-Op Payload Format for RTP", draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005. [32] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [33] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005. - [34] Audet, F. and C. Jennings, "NAT Behavioral Requirements for - Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), - October 2006. - - [35] Jennings, C. and R. Mahy, "Managing Client Initiated + [34] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-07 (work in progress), January 2007. - [36] Rescorla, E., "Overview of the Lite Implementation of - Interactive Connectivity Establishment (ICE)", - draft-ietf-mmusic-ice-lite-00.txt (work in progress), - January 2007. - Appendix A. Lite and Full Implementations ICE allows for two types of implementations. A full implementation supports the controlling and controlled roles in a session, and can also perform address gathering. In contrast, a lite implementation is a minimalist implementation that does little but respond to STUN checks. Because ICE requires both endpoints to support it in order to bring benefits to either endpoint, incremental deployment of ICE in a @@ -4106,21 +4292,21 @@ transmission of these packets on the network makes use of bandwidth and needs to be rate limited by the agent. As a consequence, the pacing ensures that the NAT devices does not get overloaded and that traffic is kept at a reasonable rate. B.2. Candidates with Multiple Bases Section 4.1.1 talks about merging together candidates that are identical but have different bases. When can an agent have two candidates that have the same IP address and port, but different - bases? Consider the topology of Figure 22: + bases? Consider the topology of Figure 23: +----------+ | STUN Srvr| +----------+ | | ----- // \\ | | | B:net10 | @@ -4144,21 +4330,21 @@ | | |192.168.1.1 ----- +----------+ // \\ +----------+ | | | | | | | Offerer |---------| C:net10 |---------| Answerer | | |10.0.1.1 | | 10.0.1.2 | | +----------+ \\ // +----------+ ----- - Figure 22: Identical Candidates with Different Bases + Figure 23: Identical Candidates with Different Bases In this case, the offerer is multi-homed. It has one interface, 10.0.1.1, on network C, which is a net 10 private network. The Answerer is on this same network. The offerer is also connected to network A, which is 192.168/16. The offerer has an interface of 192.168.1.1 on this network. There is a NAT on this network, natting into network B, which is another net 10 private network, but not connected to network C. There is a STUN server on network B. The offerer obtains a host candidate on its interface on network C @@ -4266,56 +4452,55 @@ last part of the expression. The factor of 2*32 is used since the priority of a single candidate is always less than 2*32, resulting in the pair priority being a "concatenation" of the two component priorities. This creates the desired sorting property. B.6. The remote-candidates attribute The a=remote-candidates attribute exists to eliminate a race condition between the updated offer and the response to the STUN Binding Request that moved a candidate into the Valid list. This - race condition is shown in Figure 23. On receipt of message 4, agent + race condition is shown in Figure 24. On receipt of message 4, agent L adds a candidate pair to the valid list. If there was only a single media stream with a single component, agent L could now send an updated offer. However, the check from agent R has not yet generated a response, and agent R receives the updated offer (message - 7) before getting the response (message 10). Thus, it does not yet + 7) before getting the response (message 9). Thus, it does not yet know that this particular pair is valid. To eliminate this condition, the actual candidates at R that were selected by the - offerer (the remote candidates) are included in the offer itself. - Note, however, that agent R will not send media until it has received - this STUN response. + offerer (the remote candidates) are included in the offer itself, and + the answerer delays its answer until those pairs validate. - Agent L Network Agent R + Agent A Network Agent B |(1) Offer | | |------------------------------------------>| |(2) Answer | | |<------------------------------------------| |(3) STUN Req. | | |------------------------------------------>| |(4) STUN Res. | | |<------------------------------------------| |(5) STUN Req. | | |<------------------------------------------| |(6) STUN Res. | | |-------------------->| | | |Lost | |(7) Offer | | |------------------------------------------>| - |(8) Answer | | - |<------------------------------------------| - |(9) STUN Req. | | + |(8) STUN Req. | | |<------------------------------------------| - |(10) STUN Res. | | + |(9) STUN Res. | | |------------------------------------------>| + |(10) Answer | | + |<------------------------------------------| - Figure 23: Race Condition Flow + Figure 24: Race Condition Flow B.7. Why are Keepalives Needed? Once media begins flowing on a candidate pair, it is still necessary to keep the bindings alive at intermediate NATs for the duration of the session. Normally, the media stream packets themselves (e.g., RTP) meet this objective. However, several cases merit further discussion. Firstly, in some RTP usages, such as SIP, the media streams can be "put on hold". This is accomplished by using the SDP "sendonly" or "inactive" attributes, as defined in RFC 3264 [4]. RFC