Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

Internet Engineering Task Force (IETF)
Request for Comments: 5245
Obsoletes: 4091, 4092
Category: Standards Track
ISSN: 2070-1721

J. Rosenberg
jdrosen.net
April 2010

Abstract

This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based 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 and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP).

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5245.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Overview of ICE
  • 2.1. Gathering Candidate Addresses
  • 2.2. Connectivity Checks
  • 2.3. Sorting Candidates
  • 2.4. Frozen Candidates
  • 2.5. Security for Checks
  • 2.6. Concluding ICE
  • 2.7. Lite Implementations
• 3. Terminology
• 4. Sending the Initial Offer
  • 4.1. Full Implementation Requirements
    • 4.1.1. Gathering Candidates
      • 4.1.1.1. Host Candidates
      • 4.1.1.2. Server Reflexive and Relayed Candidates
      • 4.1.1.3. Computing Foundations
      • 4.1.1.4. Keeping Candidates Alive
    • 4.1.2. Prioritizing Candidates
      • 4.1.2.1. Recommended Formula
      • 4.1.2.2. Guidelines for Choosing Type and Local Preferences
    • 4.1.3. Eliminating Redundant Candidates
    • 4.1.4. Choosing Default Candidates
  • 4.2. Lite Implementation Requirements
  • 4.3. Encoding the SDP
• 5. Receiving the Initial Offer
  • 5.1. Verifying ICE Support
  • 5.2. Determining Role
  • 5.3. Gathering Candidates
  • 5.4. Prioritizing Candidates
  • 5.5. Choosing Default Candidates
  • 5.6. Encoding the SDP
  • 5.7. Forming the Check Lists
    • 5.7.1. Forming Candidate Pairs
    • 5.7.2. Computing Pair Priority and Ordering Pairs
    • 5.7.3. Pruning the Pairs
    • 5.7.4. Computing States
  • 5.8. Scheduling Checks
• 6. Receipt of the Initial Answer
  • 6.1. Verifying ICE Support
  • 6.2. Determining Role
  • 6.3. Forming the Check List
  • 6.4. Performing Ordinary Checks
• 7. Performing Connectivity Checks
  • 7.1. STUN Client Procedures
    • 7.1.1. Creating Permissions for Relayed Candidates
    • 7.1.2. Sending the Request
      • 7.1.2.1. PRIORITY and USE-CANDIDATE
      • 7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING
      • 7.1.2.3. Forming Credentials
      • 7.1.2.4. DiffServ Treatment
    • 7.1.3. Processing the Response
      • 7.1.3.1. Failure Cases
      • 7.1.3.2. Success Cases
        • 7.1.3.2.1. Discovering Peer Reflexive Candidates
        • 7.1.3.2.2. Constructing a Valid Pair
        • 7.1.3.2.3. Updating Pair States
        • 7.1.3.2.4. Updating the Nominated Flag
      • 7.1.3.3. Check List and Timer State Updates
  • 7.2. STUN Server Procedures
    • 7.2.1. Additional Procedures for Full Implementations
      • 7.2.1.1. Detecting and Repairing Role Conflicts
      • 7.2.1.2. Computing Mapped Address
      • 7.2.1.3. Learning Peer Reflexive Candidates
      • 7.2.1.4. Triggered Checks
      • 7.2.1.5. Updating the Nominated Flag
    • 7.2.2. Additional Procedures for Lite Implementations
• 8. Concluding ICE Processing
  • 8.1. Procedures for Full Implementations
    • 8.1.1. Nominating Pairs
      • 8.1.1.1. Regular Nomination
      • 8.1.1.2. Aggressive Nomination
    • 8.1.2. Updating States
  • 8.2. Procedures for Lite Implementations
    • 8.2.1. Peer Is Full
    • 8.2.2. Peer Is Lite
  • 8.3. Freeing Candidates
    • 8.3.1. Full Implementation Procedures
    • 8.3.2. Lite Implementation Procedures
• 9. Subsequent Offer/Answer Exchanges
  • 9.1. Generating the Offer
    • 9.1.1. Procedures for All Implementations
      • 9.1.1.1. ICE Restarts
      • 9.1.1.2. Removing a Media Stream
      • 9.1.1.3. Adding a Media Stream
    • 9.1.2. Procedures for Full Implementations
      • 9.1.2.1. Existing Media Streams with ICE Running
      • 9.1.2.2. Existing Media Streams with ICE Completed
    • 9.1.3. Procedures for Lite Implementations
      • 9.1.3.1. Existing Media Streams with ICE Running
      • 9.1.3.2. Existing Media Streams with ICE Completed
  • 9.2. Receiving the Offer and Generating an Answer
    • 9.2.1. Procedures for All Implementations
      • 9.2.1.1. Detecting ICE Restart
      • 9.2.1.2. New Media Stream
      • 9.2.1.3. Removed Media Stream
    • 9.2.2. Procedures for Full Implementations
      • 9.2.2.1. Existing Media Streams with ICE Running and no remote-candidates
      • 9.2.2.2. Existing Media Streams with ICE Completed and no remote-candidates
      • 9.2.2.3. Existing Media Streams and remote-candidates
    • 9.2.3. Procedures for Lite Implementations
  • 9.3. Updating the Check and Valid Lists
    • 9.3.1. Procedures for Full Implementations
      • 9.3.1.1. ICE Restarts
      • 9.3.1.2. New Media Stream
      • 9.3.1.3. Removed Media Stream
      • 9.3.1.4. ICE Continuing for Existing Media Stream
    • 9.3.2. Procedures for Lite Implementations
• 10. Keepalives
• 11. Media Handling
  • 11.1. Sending Media
    • 11.1.1. Procedures for Full Implementations
    • 11.1.2. Procedures for Lite Implementations
    • 11.1.3. Procedures for All Implementations
  • 11.2. Receiving Media
• 12. Usage with SIP
  • 12.1. Latency Guidelines
    • 12.1.1. Offer in INVITE
    • 12.1.2. Offer in Response
  • 12.2. SIP Option Tags and Media Feature Tags
  • 12.3. Interactions with Forking
  • 12.4. Interactions with Preconditions
  • 12.5. Interactions with Third Party Call Control
• 13. Relationship with ANAT
• 14. Extensibility Considerations
• 15. Grammar
  • 15.1. "candidate" Attribute
  • 15.2. "remote-candidates" Attribute
  • 15.3. "ice-lite" and "ice-mismatch" Attributes
  • 15.4. "ice-ufrag" and "ice-pwd" Attributes
  • 15.5. "ice-options" Attribute
• 16. Setting Ta and RTO
  • 16.1. RTP Media Streams
  • 16.2. Non-RTP Sessions
• 17. Example
• 18. Security Considerations
  • 18.1. Attacks on Connectivity Checks
  • 18.2. Attacks on Server Reflexive Address Gathering
  • 18.3. Attacks on Relayed Candidate Gathering
  • 18.4. Attacks on the Offer/Answer Exchanges
  • 18.5. Insider Attacks
    • 18.5.1. The Voice Hammer Attack
    • 18.5.2. STUN Amplification Attack
  • 18.6. Interactions with Application Layer Gateways and SIP
• 19. STUN Extensions
  • 19.1. New Attributes
  • 19.2. New Error Response Codes
• 20. Operational Considerations
  • 20.1. NAT and Firewall Types
  • 20.2. Bandwidth Requirements
    • 20.2.1. STUN and TURN Server Capacity Planning
    • 20.2.2. Gathering and Connectivity Checks
    • 20.2.3. Keepalives
  • 20.3. ICE and ICE-lite
  • 20.4. Troubleshooting and Performance Management
  • 20.5. Endpoint Configuration
• 21. IANA Considerations
  • 21.1. SDP Attributes
    • 21.1.1. candidate Attribute
    • 21.1.2. remote-candidates Attribute
    • 21.1.3. ice-lite Attribute
    • 21.1.4. ice-mismatch Attribute
    • 21.1.5. ice-pwd Attribute
    • 21.1.6. ice-ufrag Attribute
    • 21.1.7. ice-options Attribute
  • 21.2. STUN Attributes
  • 21.3. STUN Error Responses
• 22. IAB Considerations
  • 22.1. Problem Definition
  • 22.2. Exit Strategy
  • 22.3. Brittleness Introduced by ICE
  • 22.4. Requirements for a Long-Term Solution
  • 22.5. Issues with Existing NAPT Boxes
• 23. Acknowledgements
• 24. References
  • 24.1. Normative References
  • 24.2. Informative References
• Appendix A. Lite and Full Implementations
• Appendix B. Design Motivations
  • B.1. Pacing of STUN Transactions
  • B.2. Candidates with Multiple Bases
  • B.3. Purpose of the <rel-addr> and <rel-port> Attributes
  • B.4. Importance of the STUN Username
  • B.5. The Candidate Pair Priority Formula
  • B.6. The remote-candidates Attribute
  • B.7. Why Are Keepalives Needed?
  • B.8. Why Prefer Peer Reflexive Candidates?
  • B.9. Why Send an Updated Offer?
  • B.10. Why Are Binding Indications Used for Keepalives?
  • B.11. Why Is the Conflict Resolution Mechanism Needed?