tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5245

 Errata 
Proposed STD
Pages: 117
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MMUSIC

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

Part 1 of 5, p. 1 to 19
None       Next RFC Part

Obsoletes:    4091    4092
Updated by:    6336


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                      J. Rosenberg
Request for Comments: 5245                                   jdrosen.net
Obsoletes: 4091, 4092                                         April 2010
Category: Standards Track
ISSN: 2070-1721


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

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.

Page 2 
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  . . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Overview of ICE . . . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Gathering Candidate Addresses . . . . . . . . . . . . . .   9
     2.2.  Connectivity Checks . . . . . . . . . . . . . . . . . . .  11
     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
   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.1.2.  Server Reflexive and Relayed Candidates . . . . .  20
         4.1.1.3.  Computing Foundations . . . . . . . . . . . . . .  22
         4.1.1.4.  Keeping Candidates Alive  . . . . . . . . . . . .  22
       4.1.2.  Prioritizing Candidates . . . . . . . . . . . . . . .  22
         4.1.2.1.  Recommended Formula . . . . . . . . . . . . . . .  23
         4.1.2.2.  Guidelines for Choosing Type and Local
                   Preferences . . . . . . . . . . . . . . . . . . .  23
       4.1.3.  Eliminating Redundant Candidates  . . . . . . . . . .  25
       4.1.4.  Choosing Default Candidates . . . . . . . . . . . . .  25
     4.2.  Lite Implementation Requirements  . . . . . . . . . . . .  25
     4.3.  Encoding the SDP  . . . . . . . . . . . . . . . . . . . .  26
   5.  Receiving the Initial Offer . . . . . . . . . . . . . . . . .  28
     5.1.  Verifying ICE Support . . . . . . . . . . . . . . . . . .  28
     5.2.  Determining Role  . . . . . . . . . . . . . . . . . . . .  29
     5.3.  Gathering Candidates  . . . . . . . . . . . . . . . . . .  30
     5.4.  Prioritizing Candidates . . . . . . . . . . . . . . . . .  30
     5.5.  Choosing Default Candidates . . . . . . . . . . . . . . .  31

Top      ToC       Page 3 
     5.6.  Encoding the SDP  . . . . . . . . . . . . . . . . . . . .  31
     5.7.  Forming the Check Lists . . . . . . . . . . . . . . . . .  31
       5.7.1.  Forming Candidate Pairs . . . . . . . . . . . . . . .  31
       5.7.2.  Computing Pair Priority and Ordering Pairs  . . . . .  34
       5.7.3.  Pruning the Pairs . . . . . . . . . . . . . . . . . .  34
       5.7.4.  Computing States  . . . . . . . . . . . . . . . . . .  34
     5.8.  Scheduling Checks . . . . . . . . . . . . . . . . . . . .  37
   6.  Receipt of the Initial Answer . . . . . . . . . . . . . . . .  39
     6.1.  Verifying ICE Support . . . . . . . . . . . . . . . . . .  39
     6.2.  Determining Role  . . . . . . . . . . . . . . . . . . . .  39
     6.3.  Forming the Check List  . . . . . . . . . . . . . . . . .  40
     6.4.  Performing Ordinary Checks  . . . . . . . . . . . . . . .  40
   7.  Performing Connectivity Checks  . . . . . . . . . . . . . . .  40
     7.1.  STUN Client Procedures  . . . . . . . . . . . . . . . . .  40
       7.1.1.  Creating Permissions for Relayed Candidates . . . . .  40
       7.1.2.  Sending the Request . . . . . . . . . . . . . . . . .  40
         7.1.2.1.  PRIORITY and USE-CANDIDATE  . . . . . . . . . . .  41
         7.1.2.2.  ICE-CONTROLLED and ICE-CONTROLLING  . . . . . . .  41
         7.1.2.3.  Forming Credentials . . . . . . . . . . . . . . .  41
         7.1.2.4.  DiffServ Treatment  . . . . . . . . . . . . . . .  42
       7.1.3.  Processing the Response . . . . . . . . . . . . . . .  42
         7.1.3.1.  Failure Cases . . . . . . . . . . . . . . . . . .  42
         7.1.3.2.  Success Cases . . . . . . . . . . . . . . . . . .  43
           7.1.3.2.1.  Discovering Peer Reflexive Candidates . . . .  43
           7.1.3.2.2.  Constructing a Valid Pair . . . . . . . . . .  44
           7.1.3.2.3.  Updating Pair States  . . . . . . . . . . . .  45
           7.1.3.2.4.  Updating the Nominated Flag . . . . . . . . .  46
         7.1.3.3.  Check List and Timer State Updates  . . . . . . .  46
     7.2.  STUN Server Procedures  . . . . . . . . . . . . . . . . .  46
       7.2.1.  Additional Procedures for Full Implementations  . . .  47
         7.2.1.1.  Detecting and Repairing Role Conflicts  . . . . .  47
         7.2.1.2.  Computing Mapped Address  . . . . . . . . . . . .  48
         7.2.1.3.  Learning Peer Reflexive Candidates  . . . . . . .  49
         7.2.1.4.  Triggered Checks  . . . . . . . . . . . . . . . .  49
         7.2.1.5.  Updating the Nominated Flag . . . . . . . . . . .  50
       7.2.2.  Additional Procedures for Lite Implementations  . . .  51
   8.  Concluding ICE Processing . . . . . . . . . . . . . . . . . .  51
     8.1.  Procedures for Full Implementations . . . . . . . . . . .  51
       8.1.1.  Nominating Pairs  . . . . . . . . . . . . . . . . . .  51
         8.1.1.1.  Regular Nomination  . . . . . . . . . . . . . . .  52
         8.1.1.2.  Aggressive Nomination . . . . . . . . . . . . . .  52
       8.1.2.  Updating States . . . . . . . . . . . . . . . . . . .  53
     8.2.  Procedures for Lite Implementations . . . . . . . . . . .  54
       8.2.1.  Peer Is Full  . . . . . . . . . . . . . . . . . . . .  54
       8.2.2.  Peer Is Lite  . . . . . . . . . . . . . . . . . . . .  55
     8.3.  Freeing Candidates  . . . . . . . . . . . . . . . . . . .  56
       8.3.1.  Full Implementation Procedures  . . . . . . . . . . .  56
       8.3.2.  Lite Implementation Procedures  . . . . . . . . . . .  56

Top      ToC       Page 4 
   9.  Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . .  56
     9.1.  Generating the Offer  . . . . . . . . . . . . . . . . . .  57
       9.1.1.  Procedures for All Implementations  . . . . . . . . .  57
         9.1.1.1.  ICE Restarts  . . . . . . . . . . . . . . . . . .  57
         9.1.1.2.  Removing a Media Stream . . . . . . . . . . . . .  58
         9.1.1.3.  Adding a Media Stream . . . . . . . . . . . . . .  58
       9.1.2.  Procedures for Full Implementations . . . . . . . . .  58
         9.1.2.1.  Existing Media Streams with ICE Running . . . . .  58
         9.1.2.2.  Existing Media Streams with ICE Completed . . . .  59
       9.1.3.  Procedures for Lite Implementations . . . . . . . . .  59
         9.1.3.1.  Existing Media Streams with ICE Running . . . . .  59
         9.1.3.2.  Existing Media Streams with ICE Completed . . . .  60
     9.2.  Receiving the Offer and Generating an Answer  . . . . . .  60
       9.2.1.  Procedures for All Implementations  . . . . . . . . .  60
         9.2.1.1.  Detecting ICE Restart . . . . . . . . . . . . . .  60
         9.2.1.2.  New Media Stream  . . . . . . . . . . . . . . . .  61
         9.2.1.3.  Removed Media Stream  . . . . . . . . . . . . . .  61
       9.2.2.  Procedures for Full Implementations . . . . . . . . .  61
         9.2.2.1.  Existing Media Streams with ICE Running and no
                   remote-candidates . . . . . . . . . . . . . . . .  61
         9.2.2.2.  Existing Media Streams with ICE Completed and
                   no remote-candidates  . . . . . . . . . . . . . .  61
         9.2.2.3.  Existing Media Streams and remote-candidates  . .  61
       9.2.3.  Procedures for Lite Implementations . . . . . . . . .  62
     9.3.  Updating the Check and Valid Lists  . . . . . . . . . . .  63
       9.3.1.  Procedures for Full Implementations . . . . . . . . .  63
         9.3.1.1.  ICE Restarts  . . . . . . . . . . . . . . . . . .  63
         9.3.1.2.  New Media Stream  . . . . . . . . . . . . . . . .  63
         9.3.1.3.  Removed Media Stream  . . . . . . . . . . . . . .  64
         9.3.1.4.  ICE Continuing for Existing Media Stream  . . . .  64
       9.3.2.  Procedures for Lite Implementations . . . . . . . . .  64
   10. Keepalives  . . . . . . . . . . . . . . . . . . . . . . . . .  65
   11. Media Handling  . . . . . . . . . . . . . . . . . . . . . . .  66
     11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . .  66
       11.1.1. Procedures for Full Implementations . . . . . . . . .  66
       11.1.2. Procedures for Lite Implementations . . . . . . . . .  67
       11.1.3. Procedures for All Implementations  . . . . . . . . .  67
     11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . .  67
   12. Usage with SIP  . . . . . . . . . . . . . . . . . . . . . . .  68
     12.1. Latency Guidelines  . . . . . . . . . . . . . . . . . . .  68
       12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . .  68
       12.1.2. Offer in Response . . . . . . . . . . . . . . . . . .  70
     12.2. SIP Option Tags and Media Feature Tags  . . . . . . . . .  70
     12.3. Interactions with Forking . . . . . . . . . . . . . . . .  70
     12.4. Interactions with Preconditions . . . . . . . . . . . . .  70
     12.5. Interactions with Third Party Call Control  . . . . . . .  71
   13. Relationship with ANAT  . . . . . . . . . . . . . . . . . . .  71
   14. Extensibility Considerations  . . . . . . . . . . . . . . . .  72

Top      ToC       Page 5 
   15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . .  73
     15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . .  73
     15.2. "remote-candidates" Attribute . . . . . . . . . . . . . .  75
     15.3. "ice-lite" and "ice-mismatch" Attributes  . . . . . . . .  75
     15.4. "ice-ufrag" and "ice-pwd" Attributes  . . . . . . . . . .  76
     15.5. "ice-options" Attribute . . . . . . . . . . . . . . . . .  76
   16. Setting Ta and RTO  . . . . . . . . . . . . . . . . . . . . .  76
     16.1. RTP Media Streams . . . . . . . . . . . . . . . . . . . .  77
     16.2. Non-RTP Sessions  . . . . . . . . . . . . . . . . . . . .  78
   17. Example . . . . . . . . . . . . . . . . . . . . . . . . . . .  79
   18. Security Considerations . . . . . . . . . . . . . . . . . . .  85
     18.1. Attacks on Connectivity Checks  . . . . . . . . . . . . .  86
     18.2. Attacks on Server Reflexive Address Gathering . . . . . .  88
     18.3. Attacks on Relayed Candidate Gathering  . . . . . . . . .  89
     18.4. Attacks on the Offer/Answer Exchanges . . . . . . . . . .  89
     18.5. Insider Attacks . . . . . . . . . . . . . . . . . . . . .  90
       18.5.1. The Voice Hammer Attack . . . . . . . . . . . . . . .  90
       18.5.2. STUN Amplification Attack . . . . . . . . . . . . . .  90
     18.6. Interactions with Application Layer Gateways and SIP  . .  91
   19. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . .  92
     19.1. New Attributes  . . . . . . . . . . . . . . . . . . . . .  92
     19.2. New Error Response Codes  . . . . . . . . . . . . . . . .  93
   20. Operational Considerations  . . . . . . . . . . . . . . . . .  93
     20.1. NAT and Firewall Types  . . . . . . . . . . . . . . . . .  93
     20.2. Bandwidth Requirements  . . . . . . . . . . . . . . . . .  93
       20.2.1. STUN and TURN Server Capacity Planning  . . . . . . .  93
       20.2.2. Gathering and Connectivity Checks . . . . . . . . . .  94
       20.2.3. Keepalives  . . . . . . . . . . . . . . . . . . . . .  94
     20.3. ICE and ICE-lite  . . . . . . . . . . . . . . . . . . . .  95
     20.4. Troubleshooting and Performance Management  . . . . . . .  95
     20.5. Endpoint Configuration  . . . . . . . . . . . . . . . . .  95
   21. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  96
     21.1. SDP Attributes  . . . . . . . . . . . . . . . . . . . . .  96
       21.1.1. candidate Attribute . . . . . . . . . . . . . . . . .  96
       21.1.2. remote-candidates Attribute . . . . . . . . . . . . .  96
       21.1.3. ice-lite Attribute  . . . . . . . . . . . . . . . . .  97
       21.1.4. ice-mismatch Attribute  . . . . . . . . . . . . . . .  97
       21.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . .  98
       21.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . .  98
       21.1.7. ice-options Attribute . . . . . . . . . . . . . . . .  98
     21.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . .  99
     21.3. STUN Error Responses  . . . . . . . . . . . . . . . . . .  99
   22. IAB Considerations  . . . . . . . . . . . . . . . . . . . . .  99
     22.1. Problem Definition  . . . . . . . . . . . . . . . . . . . 100
     22.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 100
     22.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 101
     22.4. Requirements for a Long-Term Solution . . . . . . . . . . 102
     22.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 102

Top      ToC       Page 6 
   23. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 102
   24. References  . . . . . . . . . . . . . . . . . . . . . . . . . 103
     24.1. Normative References  . . . . . . . . . . . . . . . . . . 103
     24.2. Informative References  . . . . . . . . . . . . . . . . . 104
   Appendix A.  Lite and Full Implementations  . . . . . . . . . . . 107
   Appendix B.  Design Motivations . . . . . . . . . . . . . . . . . 108
     B.1.  Pacing of STUN Transactions . . . . . . . . . . . . . . . 108
     B.2.  Candidates with Multiple Bases  . . . . . . . . . . . . . 109
     B.3.  Purpose of the <rel-addr> and <rel-port> Attributes . . . 111
     B.4.  Importance of the STUN Username . . . . . . . . . . . . . 111
     B.5.  The Candidate Pair Priority Formula . . . . . . . . . . . 113
     B.6.  The remote-candidates Attribute . . . . . . . . . . . . . 113
     B.7.  Why Are Keepalives Needed?  . . . . . . . . . . . . . . . 114
     B.8.  Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 115
     B.9.  Why Send an Updated Offer?  . . . . . . . . . . . . . . . 115
     B.10. Why Are Binding Indications Used for Keepalives?  . . . . 115
     B.11. Why Is the Conflict Resolution Mechanism Needed?  . . . . 116

1.  Introduction

   RFC 3264 [RFC3264] defines a two-phase exchange of Session
   Description Protocol (SDP) messages [RFC4566] for the purposes of
   establishment of multimedia sessions.  This offer/answer mechanism is
   used by protocols such as the Session Initiation Protocol (SIP)
   [RFC3261].

   Protocols using offer/answer are difficult to operate through Network
   Address Translators (NATs).  Because their purpose is to establish a
   flow of media packets, they tend to carry the IP addresses and ports
   of media sources and sinks within their messages, which is known to
   be problematic through NAT [RFC3235].  The protocols also seek to
   create a media flow directly between participants, so that there is
   no application layer intermediary between them.  This is done to
   reduce media latency, decrease packet loss, and reduce the
   operational costs of deploying the application.  However, this is
   difficult to accomplish through NAT.  A full treatment of the reasons
   for this is beyond the scope of this specification.

   Numerous solutions have been defined for allowing these protocols to
   operate through NAT.  These include Application Layer Gateways
   (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple
   Traversal of UDP Through NAT (STUN) [RFC3489] specification, and
   Realm Specific IP [RFC3102] [RFC3103] along with session description
   extensions needed to make them work, such as the Session Description
   Protocol (SDP) [RFC4566] attribute for the Real Time Control Protocol
   (RTCP) [RFC3605].  Unfortunately, these techniques all have pros and
   cons which, make each one optimal in some network topologies, but a
   poor choice in others.  The result is that administrators and

Top      ToC       Page 7 
   implementors are making assumptions about the topologies of the
   networks in which their solutions will be deployed.  This introduces
   complexity and brittleness into the system.  What is needed is a
   single solution that is flexible enough to work well in all
   situations.

   This specification defines Interactive Connectivity Establishment
   (ICE) as a technique for NAT traversal for UDP-based media streams
   (though ICE can be extended to handle other transport protocols, such
   as TCP [ICE-TCP]) established by the offer/answer model.  ICE is an
   extension to the offer/answer model, and works by including a
   multiplicity of IP addresses and ports in SDP offers and answers,
   which are then tested for connectivity by peer-to-peer connectivity
   checks.  The IP addresses and ports included in the SDP and the
   connectivity checks are performed using the revised STUN
   specification [RFC5389], now renamed to Session Traversal Utilities
   for NAT.  The new name and new specification reflect its new role as
   a tool that is used with other NAT traversal techniques (namely ICE)
   rather than a standalone NAT traversal solution, as the original STUN
   specification was.  ICE also makes use of Traversal Using Relays
   around NAT (TURN) [RFC5766], an extension to STUN.  Because ICE
   exchanges a multiplicity of IP addresses and ports for each media
   stream, it also allows for address selection for multihomed and dual-
   stack hosts, and for this reason it deprecates RFC 4091 [RFC4091] and
   [RFC4092].

2.  Overview of ICE

   In a typical ICE deployment, we have two endpoints (known as AGENTS
   in RFC 3264 terminology) that 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 [RFC3264]
   messages.  Note that ICE is not intended for NAT traversal for SIP,
   which is assumed to be provided via another mechanism [RFC5626].  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
   properties are also unknown.  Agents L and R are capable of engaging
   in an offer/answer exchange by which they can exchange SDP messages,
   whose purpose is to set up a media session between L and R.
   Typically, this exchange will occur through a SIP server.

Top      ToC       Page 8 
   In addition to the agents, a SIP server and NATs, ICE is typically
   used in concert with STUN or TURN servers in the network.  Each agent
   can have its own STUN or TURN server, or they can be the same.

                              +-------+
                              | SIP   |
           +-------+          | Srvr  |          +-------+
           | STUN  |          |       |          | STUN  |
           | Srvr  |          +-------+          | Srvr  |
           |       |         /         \         |       |
           +-------+        /           \        +-------+
                           /             \
                          /               \
                         /                 \
                        /                   \
                       /  <-  Signaling  ->  \
                      /                       \
                     /                         \
               +--------+                   +--------+
               |  NAT   |                   |  NAT   |
               +--------+                   +--------+
                 /                                \
                /                                  \
               /                                    \
           +-------+                             +-------+
           | Agent |                             | Agent |
           |   L   |                             |   R   |
           |       |                             |       |
           +-------+                             +-------+

                     Figure 1: ICE Deployment Scenario

   The basic idea behind ICE is as follows: each agent has a variety of
   candidate TRANSPORT ADDRESSES (combination of IP address and port for
   a particular transport protocol, which is always UDP in this
   specification)) it could use to communicate with the other agent.
   These might include:

   o  A transport address on a directly attached network interface

   o  A translated transport address on the public side of a NAT (a
      "server reflexive" address)

   o  A transport address allocated from a TURN server (a "relayed
      address").

   Potentially, any of L's candidate transport addresses can be used to
   communicate with any of R's candidate transport addresses.  In

Top      ToC       Page 9 
   practice, however, many combinations will not work.  For instance, if
   L and R are both behind NATs, their directly attached interface
   addresses are unlikely to be able to communicate directly (this is
   why ICE is needed, after all!).  The purpose of ICE is to discover
   which pairs of addresses will work.  The way that ICE does this is to
   systematically try all possible pairs (in a carefully sorted order)
   until it finds one or more that work.

2.1.  Gathering Candidate Addresses

   In order to execute ICE, an agent has to identify all of its address
   candidates.  A CANDIDATE is a transport address -- a combination of
   IP address and port for a particular transport protocol (with only
   UDP specified here).  This document defines three types of
   candidates, some derived from physical or logical network interfaces,
   others discoverable via STUN and TURN.  Naturally, one viable
   candidate is a transport address obtained directly from a local
   interface.  Such a candidate is called a HOST CANDIDATE.  The local
   interface could be ethernet or WiFi, or it could be one that is
   obtained through a tunnel mechanism, such as a Virtual Private
   Network (VPN) or Mobile IP (MIP).  In all cases, such a network
   interface appears to the agent as a local interface from which ports
   (and thus candidates) can be allocated.

   If an agent is multihomed, it obtains a candidate from each IP
   address.  Depending on the location of the PEER (the other agent in
   the session) on the IP network relative to the agent, the agent may
   be reachable by the peer through one or more of those IP addresses.
   Consider, for example, an agent that has a local IP address on a
   private net 10 network (I1), and a second connected to the public
   Internet (I2).  A candidate from I1 will be directly reachable when
   communicating with a peer on the same private net 10 network, while a
   candidate from I2 will be directly reachable when communicating with
   a peer on the public Internet.  Rather than trying to guess which IP
   address will work prior to sending an offer, the offering agent
   includes both candidates in its offer.

   Next, the agent uses STUN or TURN to obtain additional candidates.
   These come in two flavors: translated addresses on the public side of
   a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers
   (RELAYED CANDIDATES).  When TURN servers are utilized, both types of
   candidates are obtained from the TURN server.  If only STUN servers
   are utilized, only server reflexive candidates are obtained from
   them.  The relationship of these candidates to the host candidate is
   shown in Figure 2.  In this figure, both types of candidates are
   discovered using TURN.  In the figure, the notation X:x means IP
   address X and UDP port x.

Top      ToC       Page 10 
                 To Internet

                     |
                     |
                     |  /------------  Relayed
                 Y:y | /               Address
                 +--------+
                 |        |
                 |  TURN  |
                 | Server |
                 |        |
                 +--------+
                     |
                     |
                     | /------------  Server
              X1':x1'|/               Reflexive
               +------------+         Address
               |    NAT     |
               +------------+
                     |
                     | /------------  Local
                 X:x |/               Address
                 +--------+
                 |        |
                 | Agent  |
                 |        |
                 +--------+

                     Figure 2: Candidate Relationships

   When the agent sends the TURN Allocate request from IP address and
   port X:x, the NAT (assuming there is one) will create a binding
   X1':x1', mapping this server reflexive candidate to the host
   candidate X:x.  Outgoing packets sent from the host candidate will be
   translated by the NAT to the server reflexive candidate.  Incoming
   packets sent to the server reflexive candidate will be translated by
   the NAT to the host candidate and forwarded to the agent.  We call
   the host candidate associated with a given server reflexive candidate
   the BASE.

      Note: "Base" refers to the address an agent sends from for a
      particular candidate.  Thus, as a degenerate case host candidates
      also have a base, but it's the same as the host candidate.

   When there are multiple NATs between the agent and the TURN server,
   the TURN request will create a binding on each NAT, but only the
   outermost server reflexive candidate (the one nearest the TURN

Top      ToC       Page 11 
   server) will be discovered by the agent.  If the agent is not behind
   a NAT, then the base candidate will be the same as the server
   reflexive candidate and the server reflexive candidate is redundant
   and will be eliminated.

   The Allocate request then arrives at the TURN server.  The TURN
   server allocates a port y from its local IP address Y, and generates
   an Allocate response, informing the agent of this relayed candidate.
   The TURN server also informs the agent of the server reflexive
   candidate, X1':x1' by copying the source transport address of the
   Allocate request into the Allocate response.  The TURN server acts as
   a packet relay, forwarding traffic between L and R. In order to send
   traffic to L, R sends traffic to the TURN server at Y:y, and the TURN
   server forwards that to X1':x1', which passes through the NAT where
   it is mapped to X:x and delivered to L.

   When only STUN servers are utilized, the agent sends a STUN Binding
   request [RFC5389] to its STUN server.  The STUN server will inform
   the agent of the server reflexive candidate X1':x1' by copying the
   source transport address of the Binding request into the Binding
   response.

2.2.  Connectivity Checks

   Once L has gathered all of its candidates, it orders them in highest
   to lowest priority and sends them to R over the signaling channel.
   The candidates are carried in attributes in the SDP offer.  When R
   receives the offer, it performs the same gathering process and
   responds with its own list of candidates.  At the end of this
   process, each agent has a complete list of both its candidates and
   its peer's candidates.  It pairs them up, resulting in CANDIDATE
   PAIRS.  To see which pairs work, each agent schedules a series of
   CHECKS.  Each check is a STUN request/response transaction that the
   client will perform on a particular candidate pair by sending a STUN
   request from the local candidate to the remote candidate.

   The basic principle of the connectivity checks is simple:

   1.  Sort the candidate pairs in priority order.

   2.  Send checks on each candidate pair in priority order.

   3.  Acknowledge checks received from the other agent.

Top      ToC       Page 12 
   With both agents performing a check on a candidate pair, the result
   is a 4-way handshake:

   L                        R
   -                        -
   STUN request ->             \  L's
             <- STUN response  /  check

              <- STUN request  \  R's
   STUN response ->            /  check

                    Figure 3: Basic Connectivity Check

   It is important to note that the STUN requests are sent to and from
   the exact same IP addresses and ports that will be used for media
   (e.g., RTP and RTCP).  Consequently, agents demultiplex STUN and RTP/
   RTCP using contents of the packets, rather than the port on which
   they are received.  Fortunately, this demultiplexing is easy to do,
   especially for RTP and RTCP.

   Because a STUN Binding request is used for the connectivity check,
   the STUN Binding response will contain the agent's translated
   transport address on the public side of any NATs between the agent
   and its peer.  If this transport address is different from other
   candidates the agent already learned, it represents a new candidate,
   called a PEER REFLEXIVE CANDIDATE, which then gets tested by ICE just
   the same as any other candidate.

   As an optimization, as soon as R gets L's check message, R schedules
   a connectivity check message to be sent to L on the same candidate
   pair.  This accelerates the process of finding a valid candidate, and
   is called a TRIGGERED CHECK.

   At the end of this handshake, both L and R know that they can send
   (and receive) messages end-to-end in both directions.

2.3.  Sorting Candidates

   Because the algorithm above searches all candidate pairs, if a
   working pair exists it will eventually find it no matter what order
   the candidates are tried in.  In order to produce faster (and better)
   results, the candidates are sorted in a specified order.  The
   resulting list of sorted candidate pairs is called the CHECK LIST.
   The algorithm is described in Section 4.1.2 but follows two general
   principles:

   o  Each agent gives its candidates a numeric priority, which is sent
      along with the candidate to the peer.

Top      ToC       Page 13 
   o  The local and remote priorities are combined so that each agent
      has the same ordering for the candidate pairs.

   The second property is important for getting ICE to work when there
   are NATs in front of L and R.  Frequently, NATs will not allow
   packets in from a host until the agent behind the NAT has sent a
   packet towards that host.  Consequently, ICE checks in each direction
   will not succeed until both sides have sent a check through their
   respective NATs.

   The agent works through this check list by sending a STUN request for
   the next candidate pair on the list periodically.  These are called
   ORDINARY CHECKS.

   In general, the priority algorithm is designed so that candidates of
   similar type get similar priorities and so that more direct routes
   (that is, through fewer media relays and through fewer NATs) are
   preferred over indirect ones (ones with more media relays and more
   NATs).  Within those guidelines, however, agents have a fair amount
   of discretion about how to tune their algorithms.

2.4.  Frozen Candidates

   The previous description only addresses the case where the agents
   wish to establish a media session with one COMPONENT (a piece of a
   media stream requiring a single transport address; a media stream may
   require multiple components, each of which has to work for the media
   stream as a whole to be work).  Typically (e.g., with RTP and RTCP),
   the agents actually need to establish connectivity for more than one
   flow.

   The network properties are likely to be very similar for each
   component (especially because RTP and RTCP are sent and received from
   the same IP address).  It is usually possible to leverage information
   from one media component in order to determine the best candidates
   for another.  ICE does this with a mechanism called "frozen
   candidates".

   Each candidate is associated with a property called its FOUNDATION.
   Two candidates have the same foundation when they are "similar" -- of
   the same type and obtained from the same host candidate and STUN
   server using the same protocol.  Otherwise, their foundation is
   different.  A candidate pair has a foundation too, which is just the
   concatenation of the foundations of its two candidates.  Initially,
   only the candidate pairs with unique foundations are tested.  The
   other candidate pairs are marked "frozen".  When the connectivity
   checks for a candidate pair succeed, the other candidate pairs with

Top      ToC       Page 14 
   the same foundation are unfrozen.  This avoids repeated checking of
   components that are superficially more attractive but in fact are
   likely to fail.

   While we've described "frozen" here as a separate mechanism for
   expository purposes, in fact it is an integral part of ICE and the
   ICE prioritization algorithm automatically ensures that the right
   candidates are unfrozen and checked in the right order.

2.5.  Security for Checks

   Because ICE is used to discover which addresses can be used to send
   media between two agents, it is important to ensure that the process
   cannot be hijacked to send media to the wrong location.  Each STUN
   connectivity check is covered by a message authentication code (MAC)
   computed using a key exchanged in the signaling channel.  This MAC
   provides message integrity and data origin authentication, thus
   stopping an attacker from forging or modifying connectivity check
   messages.  Furthermore, if the SIP [RFC3261] caller is using ICE, and
   their call forks, the ICE exchanges happen independently with each
   forked recipient.  In such a case, the keys exchanged in the
   signaling help associate each ICE exchange with each forked
   recipient.

2.6.  Concluding ICE

   ICE checks are performed in a specific sequence, so that high-
   priority candidate pairs are checked first, followed by lower-
   priority ones.  One way to conclude ICE is to declare victory as soon
   as a check for each component of each media stream completes
   successfully.  Indeed, this is a reasonable algorithm, and details
   for it are provided below.  However, it is possible that a packet
   loss will cause a higher-priority check to take longer to complete.
   In that case, allowing ICE to run a little longer might produce
   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 round-trip time (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
   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.

Top      ToC       Page 15 
   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.  This is shown in Figure 4.

   L                        R
   -                        -
   STUN request ->             \  L's
             <- STUN response  /  check

              <- STUN request  \  R's
   STUN response ->            /  check

   STUN request + flag ->      \  L's
             <- STUN response  /  check

                       Figure 4: Regular Nomination

   Once the STUN transaction with the flag completes, both sides cancel
   any future checks for that media stream.  ICE will now send media
   using this pair.  The pair an ICE agent is using for media is called
   the SELECTED PAIR.

   In aggressive nomination, the controlling agent puts the flag in
   every STUN request it sends.  This way, once the first check
   succeeds, ICE processing is complete for that media stream and the
   controlling agent doesn't have to send a second STUN request.  The
   selected pair will be the highest-priority valid pair whose check
   succeeded.  Aggressive nomination is faster than regular nomination,
   but gives less flexibility.  Aggressive nomination is shown in
   Figure 5.

   L                        R
   -                        -
   STUN request + flag ->      \  L's
             <- STUN response  /  check

              <- STUN request  \  R's
   STUN response ->            /  check

                      Figure 5: Aggressive Nomination

   Once all of the media streams are completed, the controlling endpoint
   sends an updated offer if the candidates in the m and c lines for the
   media stream (called the DEFAULT CANDIDATES) don't match ICE's
   SELECTED CANDIDATES.

Top      ToC       Page 16 
   Once ICE is concluded, it can be restarted at any time for one or all
   of the media streams by either agent.  This is done by sending an
   updated offer indicating a restart.

2.7.  Lite Implementations

   In order for ICE to be used in a call, both agents need to support
   it.  However, certain agents will always be connected to the public
   Internet and have a public IP address at which it can receive packets
   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.  Lite agents do not generate
   connectivity checks or run the state machines, though they need to be
   able to respond to connectivity checks.  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.  When two lite implementations connect, no checks are sent.

   For guidance on when a lite implementation is appropriate, see the
   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
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Readers should be familiar with the terminology defined in the offer/
   answer model [RFC3264], STUN [RFC5389], and NAT Behavioral
   requirements for UDP [RFC4787].

   This specification makes use of the following additional terminology:

   Agent:  As defined in RFC 3264, an agent is the protocol
      implementation involved in the offer/answer exchange.  There are
      two agents involved in an offer/answer exchange.

Top      ToC       Page 17 
   Peer:  From the perspective of one of the agents in a session, its
      peer is the other agent.  Specifically, from the perspective of
      the offerer, the peer is the answerer.  From the perspective of
      the answerer, the peer is the offerer.

   Transport Address:  The combination of an IP address and transport
      protocol (such as UDP or TCP) port.

   Candidate:  A transport address that is a potential point of contact
      for receipt of media.  Candidates also have properties -- their
      type (server reflexive, relayed or host), priority, foundation,
      and base.

   Component:  A component is a piece of a media stream requiring a
      single transport address; a media stream may require multiple
      components, each of which has to work for the media stream as a
      whole to work.  For media streams based on RTP, there are two
      components per media stream -- one for RTP, and one for RTCP.

   Host Candidate:  A candidate obtained by binding to a specific port
      from an IP address on the host.  This includes IP addresses on
      physical interfaces and logical ones, such as ones obtained
      through Virtual Private Networks (VPNs) and Realm Specific IP
      (RSIP) [RFC3102] (which lives at the operating system level).

   Server Reflexive Candidate:  A candidate whose IP address and port
      are a binding allocated by a NAT for an agent when it sent a
      packet through the NAT to a server.  Server reflexive candidates
      can be learned by STUN servers using the Binding request, or TURN
      servers, which provides both a relayed and server reflexive
      candidate.

   Peer Reflexive Candidate:  A candidate whose IP address and port are
      a binding allocated by a NAT for an agent when it sent a STUN
      Binding request through the NAT to its peer.

   Relayed Candidate:  A candidate obtained by sending a TURN Allocate
      request from a host candidate to a TURN server.  The relayed
      candidate is resident on the TURN server, and the TURN server
      relays packets back towards the agent.

   Base:  The base of a server reflexive candidate is the host candidate
      from which it was derived.  A host candidate is also said to have
      a base, equal to that candidate itself.  Similarly, the base of a
      relayed candidate is that candidate itself.

Top      ToC       Page 18 
   Foundation:  An arbitrary string that is the same for two candidates
      that have the same type, base IP address, protocol (UDP, TCP,
      etc.), and STUN or TURN server.  If any of these are different,
      then the foundation will be different.  Two candidate pairs with
      the same foundation pairs are likely to have similar network
      characteristics.  Foundations are used in the frozen algorithm.

   Local Candidate:  A candidate that an agent has obtained and included
      in an offer or answer it sent.

   Remote Candidate:  A candidate that an agent received in an offer or
      answer from its peer.

   Default Destination/Candidate:  The default destination for a
      component of a media stream is the transport address that would be
      used by an agent that is not ICE aware.  For the RTP component,
      the default IP address is in the c line of the SDP, and the port
      is in the m line.  For the RTCP component, it is in the rtcp
      attribute when present, and when not present, the IP address is in
      the c line and 1 plus the port is in the m line.  A default
      candidate for a component is one whose transport address matches
      the default destination for that component.

   Candidate Pair:  A pairing containing a local candidate and a remote
      candidate.

   Check, Connectivity Check, STUN Check:  A STUN Binding request
      transaction for the purposes of verifying connectivity.  A check
      is sent from the local candidate to the remote candidate of a
      candidate pair.

   Check List:  An ordered set of candidate pairs that an agent will use
      to generate checks.

   Ordinary Check:  A connectivity check generated by an agent as a
      consequence of a timer that fires periodically, instructing it to
      send a check.

   Triggered Check:  A connectivity check generated as a consequence of
      the receipt of a connectivity check from the peer.

   Valid List:  An ordered set of candidate pairs for a media stream
      that have been validated by a successful STUN transaction.

   Full:  An ICE implementation that performs the complete set of
      functionality defined by this specification.

Top      ToC       Page 19 
   Lite:  An ICE implementation that omits certain functions,
      implementing only as much as is necessary for a peer
      implementation that is full to gain the benefits of ICE.  Lite
      implementations do not maintain any of the state machines and do
      not generate connectivity checks.

   Controlling Agent:  The ICE agent that is responsible for selecting
      the final choice of candidate pairs and signaling them through
      STUN and an updated offer, if needed.  In any session, one agent
      is always controlling.  The other is the controlled agent.

   Controlled Agent:  An ICE agent that waits for the controlling agent
      to select the final choice of candidate pairs.

   Regular Nomination:  The process of picking a valid candidate pair
      for media traffic by validating the pair with one STUN request,
      and then picking it by sending a second STUN request with a flag
      indicating its nomination.

   Aggressive Nomination:  The process of picking a valid candidate pair
      for media traffic by including a flag in every STUN request, such
      that the first one to produce a valid candidate pair is used for
      media.

   Nominated:  If a valid candidate pair has its nominated flag set, it
      means that it may be selected by ICE for sending and receiving
      media.

   Selected Pair, Selected Candidate:  The candidate pair selected by
      ICE for sending and receiving media is called the selected pair,
      and each of its candidates is called the selected candidate.



(page 19 continued on part 2)

Next RFC Part