Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8445

 
 
 

Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal

Part 2 of 6, p. 18 to 38
Prev Section       Next Section

 


prevText      Top      ToC       Page 18 
5.  ICE Candidate Gathering and Exchange

   As part of ICE processing, both the initiating and responding agents
   gather candidates, prioritize and eliminate redundant candidates, and
   exchange candidate information with the peer as defined by the using
   protocol (ICE usage).  Specifics of the candidate-encoding mechanism
   and the semantics of candidate information exchange is out of scope
   of this specification.

5.1.  Full Implementation

5.1.1.  Gathering Candidates

   An ICE agent gathers candidates when it believes that communication
   is imminent.  An initiating agent can do this based on a user
   interface cue or on an explicit request to initiate a session.  Every
   candidate has a transport address.  It also has a type and a base.
   Four types are defined and gathered by this specification -- host
   candidates, server-reflexive candidates, peer-reflexive candidates,
   and relayed candidates.  The server-reflexive candidates are gathered
   using STUN or TURN, and relayed candidates are obtained through TURN.
   Peer-reflexive candidates are obtained in later phases of ICE, as a
   consequence of connectivity checks.

   The process for gathering candidates at the responding agent is
   identical to the process for the initiating agent.  It is RECOMMENDED
   that the responding agent begin this process immediately on receipt
   of the candidate information, prior to alerting the user of the
   application associated with the ICE session.

5.1.1.1.  Host Candidates

   Host candidates are obtained by binding to ports on an IP address
   attached to an interface (physical or virtual, including VPN
   interfaces) on the host.

   For each component of each data stream the ICE agent wishes to use,
   the agent SHOULD obtain a candidate on each IP address that the host
   has, with the exceptions listed below.  The agent obtains each
   candidate by binding to a UDP port on the specific IP address.  A
   host candidate (and indeed every candidate) is always associated with
   a specific component for which it is a candidate.

   Each component has an ID assigned to it, called the "component ID".
   For RTP/RTCP data streams, unless both RTP and RTCP are multiplexed
   in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a
   component ID of 1, and RTCP has a component ID of 2.  In case of RTP/
   RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP.

Top      Up      ToC       Page 19 
   When candidates are obtained, unless the agent knows for sure that
   RTP/RTCP multiplexing will be used (i.e., the agent knows that the
   other agent also supports, and is willing to use, RTP/RTCP
   multiplexing), or unless the agent only supports RTP/RTCP
   multiplexing, the agent MUST obtain a separate candidate for RTCP.
   If an agent has obtained a candidate for RTCP, and ends up using RTP/
   RTCP multiplexing, the agent does not need to perform connectivity
   checks on the RTCP candidate.  Absence of a component ID 2 as such
   does not imply use of RTCP/RTP multiplexing, as it could also mean
   that RTCP is not used.

   If an agent is using separate candidates for RTP and RTCP, it will
   end up with 2*K host candidates if an agent has K IP addresses.

   Note that the responding agent, when obtaining its candidates, will
   typically know if the other agent supports RTP/RTCP multiplexing, in
   which case it will not need to obtain a separate candidate for RTCP.
   However, absence of a component ID 2 as such does not imply use of
   RTCP/RTP multiplexing, as it could also mean that RTCP is not used.

   The use of multiple components, other than for RTP/RTCP streams, is
   discouraged as it increases the complexity of ICE processing.  If
   multiple components are needed, the component IDs SHOULD start with 1
   and increase by 1 for each component.

   The base for each host candidate is set to the candidate itself.

   The host candidates are gathered from all IP addresses with the
   following exceptions:

   o  Addresses from a loopback interface MUST NOT be included in the
      candidate addresses.

   o  Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site-
      local unicast addresses [RFC3879] MUST NOT be included in the
      address candidates.

   o  IPv4-mapped IPv6 addresses SHOULD NOT be included in the address
      candidates unless the application using ICE does not support IPv4
      (i.e., it is an IPv6-only application [RFC4038]).

   o  If gathering one or more host candidates that correspond to an
      IPv6 address that was generated using a mechanism that prevents
      location tracking [RFC7721], host candidates that correspond to
      IPv6 addresses that do allow location tracking, are configured on
      the same interface, and are part of the same network prefix MUST
      NOT be gathered.  Similarly, when host candidates corresponding to

Top      Up      ToC       Page 20 
      an IPv6 address generated using a mechanism that prevents location
      tracking are gathered, then host candidates corresponding to IPv6
      link-local addresses [RFC4291] MUST NOT be gathered.

   The IPv6 default address selection specification [RFC6724] specifies
   that temporary addresses [RFC4941] are to be preferred over permanent
   addresses.

5.1.1.2.  Server-Reflexive and Relayed Candidates

   An ICE agent SHOULD gather server-reflexive and relayed candidates.
   However, use of STUN and TURN servers may be unnecessary in certain
   networks and use of TURN servers may be expensive, so some
   deployments may elect not to use them.  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 be re-enabled through configuration if conditions
   change in the future.

   The agent pairs each host candidate with the STUN or TURN servers
   with which it is configured or has discovered by some means.  It is
   RECOMMENDED that a domain name be configured, the DNS procedures in
   [RFC5389] (using SRV records with the "stun" service) be used to
   discover the STUN server, and the DNS procedures in [RFC5766] (using
   SRV records with the "turn" service) be used to discover the TURN
   server.

   When multiple STUN or TURN servers are available (or when they are
   learned through DNS records and multiple results are returned), the
   agent MAY gather candidates for all of them and SHOULD gather
   candidates for at least one of them (one STUN server and one TURN
   server).  It does so by pairing host candidates with STUN or TURN
   servers, and for each pair, the agent sends a Binding or Allocate
   request to the server from the host candidate.  Binding requests to a
   STUN server are not authenticated, and any ALTERNATE-SERVER attribute
   in a response is ignored.  Agents MUST support the backwards-
   compatibility mode for the Binding request defined in [RFC5389].
   Allocate requests SHOULD be authenticated using a long-term
   credential obtained by the client through some other means.

   The gathering process is controlled using a timer, Ta.  Every time Ta
   expires, the agent can generate another new STUN or TURN transaction.
   This transaction can be either a retry of a previous transaction that
   failed with a recoverable error (such as authentication failure) or a
   transaction for a new host candidate and STUN or TURN server pair.
   The agent SHOULD NOT generate transactions more frequently than once
   per each ta expiration.  See Section 14 for guidance on how to set Ta
   and the STUN retransmit timer, RTO.

Top      Up      ToC       Page 21 
   The agent will receive a Binding or Allocate response.  A successful
   Allocate response will provide the agent with a server-reflexive
   candidate (obtained from the mapped address) and a relayed candidate
   in the XOR-RELAYED-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.

   If an IPv6-only agent is in a network that utilizes NAT64 [RFC6146]
   and DNS64 [RFC6147] technologies, it may also gather IPv4 server-
   reflexive and/or relayed candidates from IPv4-only STUN or TURN
   servers.  IPv6-only agents SHOULD also utilize IPv6 prefix discovery
   [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and
   generate server-reflexive candidates for each IPv6-only interface,
   accordingly.  The NAT64 server-reflexive candidates are prioritized
   like IPv4 server-reflexive candidates.

5.1.1.3.  Computing Foundations

   The ICE agent assigns each candidate a foundation.  Two candidates
   have the same foundation when all of the following are true:

   o  They have the same type (host, relayed, server reflexive, or peer
      reflexive).

   o  Their bases have the same IP address (the ports can be different).

   o  For reflexive and relayed candidates, the STUN or TURN servers
      used to obtain them have the same IP address (the IP address used
      by the agent to contact the STUN or TURN server).

   o  They were obtained using the same transport protocol (TCP, UDP).

   Similarly, two candidates have different foundations if their types
   are different, their bases have different IP addresses, the STUN or
   TURN servers used to obtain them have different IP addresses (the IP
   addresses used by the agent to contact the STUN or TURN server), or
   their transport protocols are different.

Top      Up      ToC       Page 22 
5.1.1.4.  Keeping Candidates Alive

   Once server-reflexive and relayed candidates are allocated, they MUST
   be kept alive until ICE processing has completed, as described in
   Section 8.3.  For server-reflexive candidates learned through a
   Binding request, the bindings MUST be kept alive by additional
   Binding requests to the server.  Refreshes for allocations are done
   using the Refresh transaction, as described in [RFC5766].  The
   Refresh requests will also refresh the server-reflexive candidate.

   Host candidates do not time out, but the candidate addresses may
   change or disappear for a number of reasons.  An ICE agent SHOULD
   monitor the interfaces it uses, invalidate candidates whose base has
   gone away, and acquire new candidates as appropriate when new IP
   addresses (on new or currently used interfaces) appear.

5.1.2.  Prioritizing Candidates

   The prioritization process results in the assignment of a priority to
   each candidate.  Each candidate for a data stream MUST have a unique
   priority that MUST be a positive integer between 1 and (2**31 - 1).
   This priority will be used by ICE to determine the order of the
   connectivity checks and the relative preference for candidates.
   Higher-priority values give more priority over lower values.

   An ICE agent SHOULD compute this priority using the formula in
   Section 5.1.2.1 and choose its parameters using the guidelines in
   Section 5.1.2.2.  If an agent elects to use a different formula, ICE
   may take longer to converge since the agents will not be coordinated
   in their checks.

   The process for prioritizing candidates is common across the
   initiating and the responding agent.

5.1.2.1.  Recommended Formula

   The recommended formula combines a preference for the candidate type
   (server reflexive, peer reflexive, relayed, and host), a preference
   for the IP address for which the candidate was obtained, and a
   component ID using the following formula:

   priority = (2^24)*(type preference) +
              (2^8)*(local preference) +
              (2^0)*(256 - component ID)

   The type preference MUST be an integer from 0 (lowest preference) to
   126 (highest preference) inclusive, MUST be identical for all
   candidates of the same type, and MUST be different for candidates of

Top      Up      ToC       Page 23 
   different types.  The type preference for peer-reflexive candidates
   MUST be higher than that of server-reflexive candidates.  Setting the
   value to 0 means that candidates of this type will only be used as a
   last resort.  Note that candidates gathered based on the procedures
   of Section 5.1.1 will never be peer-reflexive candidates; candidates
   of this type are learned from the connectivity checks performed by
   ICE.

   The local preference MUST be an integer from 0 (lowest preference) to
   65535 (highest preference) inclusive.  When there is only a single IP
   address, this value SHOULD be set to 65535.  If there are multiple
   candidates for a particular component for a particular data stream
   that have the same type, the local preference MUST be unique for each
   one.  If an ICE agent is dual stack, the local preference SHOULD be
   set according to the current best practice described in [RFC8421].

   The component ID MUST be an integer between 1 and 256 inclusive.

5.1.2.2.  Guidelines for Choosing Type and Local Preferences

   The RECOMMENDED values for type preferences are 126 for host
   candidates, 110 for peer-reflexive candidates, 100 for server-
   reflexive candidates, and 0 for relayed candidates.

   If an ICE agent is multihomed and has multiple IP addresses, the
   recommendations in [RFC8421] SHOULD be followed.  If multiple TURN
   servers are used, local priorities for the candidates obtained from
   the TURN servers are chosen in a similar fashion as for multihomed
   local candidates: the local preference value is used to indicate a
   preference among different servers, but the preference MUST be unique
   for each one.

   When choosing type preferences, agents may take into account factors
   such as latency, packet loss, cost, network topology, security,
   privacy, and others.

5.1.3.  Eliminating Redundant Candidates

   Next, the ICE agents (initiating and responding) eliminate redundant
   candidates.  Two candidates can have the same transport address yet
   different bases, and these would not be considered redundant.
   Frequently, a server-reflexive candidate and a host candidate will be
   redundant when the agent is not behind a NAT.  A candidate is
   redundant if and only if its transport address and base equal those
   of another candidate.  The agent SHOULD eliminate the redundant
   candidate with the lower priority.

Top      Up      ToC       Page 24 
5.2.  Lite Implementation Procedures

   Lite implementations only utilize host candidates.  For each IP
   address, independent of an IP address family, there MUST be zero or
   one candidate.  With the lite implementation, ICE cannot be used to
   dynamically choose amongst candidates.  Therefore, including more
   than one candidate from a particular IP address family is NOT
   RECOMMENDED, since only a connectivity check can truly determine
   whether to use one address or the other.  Instead, it is RECOMMENDED
   that agents that have multiple public IP addresses run full ICE
   implementations to ensure the best usage of its addresses.

   Each component has an ID assigned to it, called the "component ID".
   For RTP/RTCP data streams, unless RTCP is multiplexed in the same
   port with RTP, the RTP itself has a component ID of 1 and RTCP a
   component ID of 2.  If an agent is using RTCP without multiplexing,
   it MUST obtain candidates for it.  However, absence of a component ID
   2 as such does not imply use of RTCP/RTP multiplexing, as it could
   also mean that RTCP is not used.

   Each candidate is assigned a foundation.  The foundation MUST be
   different for two candidates allocated from different IP addresses;
   otherwise, it MUST be the same.  A simple integer that increments for
   each IP address will suffice.  In addition, each candidate MUST be
   assigned a unique priority amongst all candidates for the same data
   stream.  If the formula in Section 5.1.2.1 is used to calculate the
   priority, the type preference value SHOULD be set to 126.  If a host
   is IPv4 only, the local preference value SHOULD be set to 65535.  If
   a host is IPv6 or dual stack, the local preference value SHOULD be
   set to the precedence value for IP addresses described in RFC 6724
   [RFC6724].

   Next, an agent chooses a default candidate for each component of each
   data stream.  If a host is IPv4 only, there would only be one
   candidate for each component of each data stream; therefore, that
   candidate is the default.  If a host is IPv6 only, the default
   candidate would typically be a globally scoped IPv6 address.  Dual-
   stack hosts SHOULD allow configuration whether IPv4 or IPv6 is used
   for the default candidate, and the configuration needs to be based on
   which one its administrator believes has a higher chance of success
   in the current network environment.

   The procedures in this section are common across the initiating and
   responding agents.

Top      Up      ToC       Page 25 
5.3.  Exchanging Candidate Information

   ICE agents (initiating and responding) need the following information
   about candidates to be exchanged.  Each ICE usage MUST define how the
   information is exchanged with the using protocol.  This section
   describes the information that needs to be exchanged.

   Candidates:   One or more candidates.  For each candidate:

      Address:  The IP address and transport protocol port of the
         candidate.

      Transport:  The transport protocol of the candidate.  This MAY be
         omitted if the using protocol only runs over a single transport
         protocol.

      Foundation:  A sequence of up to 32 characters.

      Component ID:  The component ID of the candidate.  This MAY be
         omitted if the using protocol does not use the concept of
         components.

      Priority:  The 32-bit priority of the candidate.

      Type:  The type of the candidate.

      Related Address and Port:  The related IP address and port of the
         candidate.  These MAY be omitted or set to invalid values if
         the agent does not want to reveal them, e.g., for privacy
         reasons.

      Extensibility Parameters:  The using protocol might define means
         for adding new per-candidate ICE parameters in the future.

   Lite or Full:   Whether the agent is a lite agent or full agent.

   Connectivity-Check Pacing Value:  The pacing value for connectivity
      checks that the agent wishes to use.  This MAY be omitted if the
      agent wishes to use a defined default value.

   Username Fragment and Password:  Values used to perform connectivity
      checks.  The values MUST be unguessable, with at least 128 bits of
      random number generator output used to generate the password, and
      at least 24 bits of output to generate the username fragment.

   Extensions:  New media-stream or session-level attributes (ICE
      options).

Top      Up      ToC       Page 26 
   If the using protocol is vulnerable to, and able to detect, ICE
   mismatch (Section 5.4), a way is needed for the detecting agent to
   convey this information to its peer.  It is a boolean flag.

   The using protocol may (or may not) need to deal with backwards
   compatibility with older implementations that do not support ICE.  If
   a fallback mechanism to non-ICE is supported and is being used, then
   presumably the using protocol provides a way of conveying the default
   candidate (its IP address and port) in addition to the ICE
   parameters.

   Once an agent has sent its candidate information, it MUST be prepared
   to receive both STUN and data packets on each candidate.  As
   discussed in Section 12.1, data packets can be sent to a candidate
   prior to its appearance as the default destination for data.

5.4.  ICE Mismatch

   Certain middleboxes, such as ALGs, can alter signaling information in
   ways that break ICE (e.g., by rewriting IP addresses in SDP).  This
   is referred to as "ICE mismatch".  If the using protocol is
   vulnerable to ICE mismatch, the responding agent needs to be able to
   detect it and inform the peer ICE agent about the ICE mismatch.

   Each using protocol needs to define whether the using protocol is
   vulnerable to ICE mismatch, how ICE mismatch is detected, and whether
   specific actions need to be taken when ICE mismatch is detected.

6.  ICE Candidate Processing

   Once an ICE agent has gathered its candidates and exchanged
   candidates with its peer (Section 5), it will determine its own role.
   In addition, full implementations will form checklists and begin
   performing connectivity checks with the peer.

6.1.  Procedures for Full Implementation

6.1.1.  Determining Role

   For each session, each ICE agent (initiating and responding) takes on
   a role.  There are two roles -- controlling and controlled.  The
   controlling agent is responsible for the choice of the final
   candidate pairs used for communications.  The sections below describe
   in detail the actual procedures followed by controlling and
   controlled agents.

Top      Up      ToC       Page 27 
   The rules for determining the role and the impact on behavior are as
   follows:

   Both agents are full:  The initiating agent that started the ICE
      processing MUST take the controlling role, and the other MUST take
      the controlled role.  Both agents will form checklists, run the
      ICE state machines, and generate connectivity checks.  The
      controlling agent will execute the logic in Section 8.1 to
      nominate pairs that will become (if the connectivity checks
      associated with the nominations succeed) the selected pairs, and
      then both agents end ICE as described in Section 8.1.2.

   One agent full, one lite:  The full agent MUST take the controlling
      role, and the lite agent MUST take the controlled role.  The full
      agent will form checklists, run the ICE state machines, and
      generate connectivity checks.  That agent will execute the logic
      in Section 8.1 to nominate pairs that will become (if the
      connectivity checks associated with the nominations succeed) the
      selected pairs and use the logic in Section 8.1.2 to end ICE.  The
      lite implementation will just listen for connectivity checks,
      receive them and respond to them, and then conclude ICE as
      described in Section 8.2.  For the lite implementation, the state
      of ICE processing for each data stream is considered to be
      Running, and the state of ICE overall is Running.

   Both lite:  The initiating agent that started the ICE processing MUST
      take the controlling role, and the other MUST take the controlled
      role.  In this case, no connectivity checks are ever sent.
      Rather, once the candidates are exchanged, each agent performs the
      processing described in Section 8 without connectivity checks.  It
      is possible that both agents will believe they are controlled or
      controlling.  In the latter case, the conflict is resolved through
      glare detection capabilities in the signaling protocol enabling
      the candidate exchange.  The state of ICE processing for each data
      stream is considered to be Running, and the state of ICE overall
      is Running.

   Once the roles are determined for a session, they persist throughout
   the lifetime of the session.  The roles can be redetermined as part
   of an ICE restart (Section 9), but an ICE agent MUST NOT redetermine
   the role as part of an ICE restart unless one or more of the
   following criteria is fulfilled:

   Full becomes lite:  If the controlling agent is full, and switches to
      lite, the roles MUST be redetermined if the peer agent is also
      full.

Top      Up      ToC       Page 28 
   Role conflict:  If the ICE restart causes a role conflict, the roles
      might be redetermined due to the role conflict procedures in
      Section 7.3.1.1.

   NOTE: There are certain Third Party Call Control (3PCC) [RFC3725]
   scenarios where an ICE restart might cause a role conflict.

   NOTE: The agents need to inform each other whether they are full or
   lite before the roles are determined.  The mechanism for that is
   specific to the signaling protocol and outside the scope of the
   document.

   An agent MUST accept if the peer initiates a redetermination of the
   roles even if the criteria for doing so are not fulfilled.  This can
   happen if the peer is compliant with RFC 5245.

6.1.2.  Forming the Checklists

   There is one checklist for each data stream.  To form a checklist,
   initiating and responding ICE agents form candidate pairs, compute
   pair priorities, order pairs by priority, prune pairs, remove lower-
   priority pairs, and set checklist states.  If candidates are added to
   a checklist (e.g., due to detection of peer-reflexive candidates),
   the agent will re-perform these steps for the updated checklist.

6.1.2.1.  Checklist State

   Each checklist has a state, which captures the state of ICE checks
   for the data stream associated with the checklist.  The states are:

   Running:  The checklist is neither Completed nor Failed yet.
      Checklists are initially set to the Running state.

   Completed:  The checklist contains a nominated pair for each
      component of the data stream.

   Failed:  The checklist does not have a valid pair for each component
      of the data stream, and all of the candidate pairs in the
      checklist are in either the Failed or the Succeeded state.  In
      other words, at least one component of the checklist has candidate
      pairs that are all in the Failed state, which means the component
      has failed, which means the checklist has failed.

6.1.2.2.  Forming Candidate Pairs

   The ICE agent pairs each local candidate with each remote candidate
   for the same component of the same data stream with the same IP
   address family.  It is possible that some of the local candidates

Top      Up      ToC       Page 29 
   won't get paired with remote candidates, and some of the remote
   candidates won't get paired with local candidates.  This can happen
   if one agent doesn't include candidates for all of the components for
   a data stream.  If this happens, the number of components for that
   data stream is effectively reduced and is considered to be equal to
   the minimum across both agents of the maximum component ID provided
   by each agent across all components for the data stream.

   In the case of RTP, this would happen when one agent provides
   candidates for RTCP, and the other does not.  As another example, the
   initiating agent can multiplex RTP and RTCP on the same port
   [RFC5761].  However, since the initiating agent doesn't know if the
   peer agent can perform such multiplexing, it includes candidates for
   RTP and RTCP on separate ports.  If the peer agent can perform such
   multiplexing, it would include just a single component for each
   candidate -- for the combined RTP/RTCP mux.  ICE would end up acting
   as if there was just a single component for this candidate.

   With IPv6, it is common for a host to have multiple host candidates
   for each interface.  To keep the amount of resulting candidate pairs
   reasonable and to avoid candidate pairs that are highly unlikely to
   work, IPv6 link-local addresses MUST NOT be paired with other than
   link-local addresses.

   The candidate pairs whose local and remote candidates are both the
   default candidates for a particular component is called the "default
   candidate pair" for that component.  This is the pair that would be
   used to transmit data if both agents had not been ICE aware.

Top      Up      ToC       Page 30 
   Figure 5 shows the properties of and relationships between transport
   addresses, candidates, candidate pairs, and checklists.

              +--------------------------------------------+
              |                                            |
              | +---------------------+                    |
              | |+----+ +----+ +----+ |   +Type            |
              | || IP | |Port| |Tran| |   +Priority        |
              | ||Addr| |    | |    | |   +Foundation      |
              | |+----+ +----+ +----+ |   +Component ID    |
              | |      Transport      |   +Related Address |
              | |        Addr         |                    |
              | +---------------------+   +Base            |
              |             Candidate                      |
              +--------------------------------------------+
              *                                         *
              *    *************************************
              *    *
            +-------------------------------+
            |                               |
            | Local     Remote              |
            | +----+    +----+   +default?  |
            | |Cand|    |Cand|   +valid?    |
            | +----+    +----+   +nominated?|
            |                    +State     |
            |                               |
            |                               |
            |          Candidate Pair       |
            +-------------------------------+
            *                              *
            *                  ************
            *                  *
            +------------------+
            |  Candidate Pair  |
            +------------------+
            +------------------+
            |  Candidate Pair  |
            +------------------+
            +------------------+
            |  Candidate Pair  |
            +------------------+

                 Checklist


                Figure 5: Conceptual Diagram of a Checklist

Top      Up      ToC       Page 31 
6.1.2.3.  Computing Pair Priority and Ordering Pairs

   The ICE agent computes a priority for each candidate pair.  Let G be
   the priority for the candidate provided by the controlling agent.
   Let D be the priority for the candidate provided by the controlled
   agent.  The priority for a pair is computed as follows:

      pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

   The agent sorts each checklist in decreasing order of candidate pair
   priority.  If two pairs have identical priority, the ordering amongst
   them is arbitrary.

6.1.2.4.  Pruning the Pairs

   This sorted list of candidate pairs is used to determine a sequence
   of connectivity checks that will be performed.  Each check involves
   sending a request from a local candidate to a remote candidate.
   Since an ICE agent cannot send requests directly from a reflexive
   candidate (server reflexive or peer reflexive), but only from its
   base, the agent next goes through the sorted list of candidate pairs.
   For each pair where the local candidate is reflexive, the candidate
   MUST be replaced by its base.

   The agent prunes each checklist.  This is done by removing a
   candidate pair if it is redundant with a higher-priority candidate
   pair in the same checklist.  Two candidate pairs are redundant if
   their local candidates have the same base and their remote candidates
   are identical.  The result is a sequence of ordered candidate pairs,
   called the "checklist" for that data stream.

6.1.2.5.  Removing Lower-Priority Pairs

   In order to limit the attacks described in Section 19.5.1, an ICE
   agent MUST limit the total number of connectivity checks the agent
   performs across all checklists in the checklist set.  This is done by
   limiting the total number of candidate pairs in the checklist set.
   The default limit of candidate pairs for the checklist set is 100,
   but the value MUST be configurable.  The limit is enforced by, within
   in each checklist, discarding lower-priority candidate pairs until
   the total number of candidate pairs in the checklist set is smaller
   than the limit value.  The discarding SHOULD be done evenly so that
   the number of candidate pairs in each checklist is reduced the same
   amount.

   It is RECOMMENDED that a lower-limit value than the default is picked
   when possible, and that the value is set to the maximum number of
   plausible candidate pairs that might be created in an actual

Top      Up      ToC       Page 32 
   deployment configuration.  The requirement for configuration is meant
   to provide a tool for fixing this value in the field if, once
   deployed, it is found to be problematic.

6.1.2.6.  Computing Candidate Pair States

   Each candidate pair in the checklist has a foundation (the
   combination of the foundations of the local and remote candidates in
   the pair) and one of the following states:

   Waiting:  A check has not been sent for this pair, but the pair is
      not Frozen.

   In-Progress:  A check has been sent for this pair, but the
      transaction is in progress.

   Succeeded:  A check has been sent for this pair, and it produced a
      successful result.

   Failed:  A check has been sent for this pair, and it failed (a
      response to the check was never received, or a failure response
      was received).

   Frozen:  A check for this pair has not been sent, and it cannot be
      sent until the pair is unfrozen and moved into the Waiting state.

Top      Up      ToC       Page 33 
   Pairs move between states as shown in Figure 6.

      +-----------+
      |           |
      |           |
      |  Frozen   |
      |           |
      |           |
      +-----------+
            |
            |unfreeze
            |
            V
      +-----------+         +-----------+
      |           |         |           |
      |           | perform |           |
      |  Waiting  |-------->|In-Progress|
      |           |         |           |
      |           |         |           |
      +-----------+         +-----------+
                                  / |
                                //  |
                              //    |
                            //      |
                           /        |
                         //         |
               failure //           |success
                     //             |
                    /               |
                  //                |
                //                  |
              //                    |
             V                      V
      +-----------+         +-----------+
      |           |         |           |
      |           |         |           |
      |   Failed  |         | Succeeded |
      |           |         |           |
      |           |         |           |
      +-----------+         +-----------+

              Figure 6: Pair State Finite State Machine (FSM)

Top      Up      ToC       Page 34 
   The initial states for each pair in a checklist are computed by
   performing the following sequence of steps:

   1.  The checklists are placed in an ordered list (the order is
       determined by each ICE usage), called the "checklist set".

   2.  The ICE agent initially places all candidate pairs in the Frozen
       state.

   3.  The agent sets all of the checklists in the checklist set to the
       Running state.

   4.  For each foundation, the agent sets the state of exactly one
       candidate pair to the Waiting state (unfreezing it).  The
       candidate pair to unfreeze is chosen by finding the first
       candidate pair (ordered by the lowest component ID and then the
       highest priority if component IDs are equal) in the first
       checklist (according to the usage-defined checklist set order)
       that has that foundation.

   NOTE: The procedures above are different from RFC 5245, where only
   candidate pairs in the first checklist were initially placed in the
   Waiting state.  Now it applies to candidate pairs in the first
   checklist that have that foundation, even if the checklist is not the
   first one in the checklist set.

   The table below illustrates an example.

Top      Up      ToC       Page 35 
   Table legend:

   Each row (m1, m2,...) represents a checklist associated with a
   data stream. m1 represents the first checklist in the checklist
   set.

   Each column (f1, f2,...) represents a foundation.  Every candidate
   pair within a given column share the same foundation.

   f-cp represents a candidate pair in the Frozen state.

   w-cp represents a candidate pair in the Waiting state.

   1.  The agent sets all of the pairs in the checklist set to the
       Frozen state.

         f1    f2    f3    f4    f5
       -----------------------------
   m1 | f-cp  f-cp  f-cp
      |
   m2 | f-cp  f-cp  f-cp  f-cp
      |
   m3 | f-cp                    f-cp


   2.  For each foundation, the candidate pair with the lowest
       component ID is placed in the Waiting state, unless a
       candidate pair associated with the same foundation has
       already been put in the Waiting state in one of the
       other examined checklists in the checklist set.

         f1    f2    f3    f4    f5
       -----------------------------
   m1 | w-cp  w-cp  w-cp
      |
   m2 | f-cp  f-cp  f-cp  w-cp
      |
   m3 | f-cp                    w-cp

                        Table 1: Pair State Example

   In the first checklist (m1), the candidate pair for each foundation
   is placed in the Waiting state, as no pairs for the same foundations
   have yet been placed in the Waiting state.

   In the second checklist (m2), the candidate pair for foundation f4 is
   placed in the Waiting state.  The candidate pair for foundations f1,
   f2, and f3 are kept in the Frozen state, as candidate pairs for those

Top      Up      ToC       Page 36 
   foundations have already been placed in the Waiting state (within
   checklist m1).

   In the third checklist (m3), the candidate pair for foundation f5 is
   placed in the Waiting state.  The candidate pair for foundation f1 is
   kept in the Frozen state, as a candidate pair for that foundation has
   already been placed in the Waiting state (within checklist m1).

   Once each checklist have been processed, one candidate pair for each
   foundation in the checklist set has been placed in the Waiting state.

6.1.3.  ICE State

   The ICE agent has a state determined by the state of the checklists.
   The state is Completed if all checklists are Completed, Failed if all
   checklists are Failed, or Running otherwise.

6.1.4.  Scheduling Checks

6.1.4.1.  Triggered-Check Queue

   Once the ICE agent has computed the checklists and created the
   checklist set, as described in Section 6.1.2, the agent will begin
   performing connectivity checks (ordinary and triggered).  For
   triggered connectivity checks, the agent maintains a FIFO queue for
   each checklist, referred to as the "triggered-check queue", which
   contains candidate pairs for which checks are to be sent at the next
   available opportunity.  The triggered-check queue is initially empty.

6.1.4.2.  Performing Connectivity Checks

   The generation of ordinary and triggered connectivity checks is
   governed by timer Ta.  As soon as the initial states for the
   candidate pairs in the checklist set have been set, a check is
   performed for a candidate pair within the first checklist in the
   Running state, following the procedures in Section 7.  After that,
   whenever Ta fires the next checklist in the Running state in the
   checklist set is picked, and a check is performed for a candidate
   within that checklist.  After the last checklist in the Running state
   in the checklist set has been processed, the first checklist is
   picked again, etc.

Top      Up      ToC       Page 37 
   Whenever Ta fires, the ICE agent will perform a check for a candidate
   pair within the checklist that was picked by performing the following
   steps:

   1.  If the triggered-check queue associated with the checklist
       contains one or more candidate pairs, the agent removes the top
       pair from the queue, performs a connectivity check on that pair,
       puts the candidate pair state to In-Progress, and aborts the
       subsequent steps.

   2.  If there is no candidate pair in the Waiting state, and if there
       are one or more pairs in the Frozen state, the agent checks the
       foundation associated with each pair in the Frozen state.  For a
       given foundation, if there is no pair (in any checklist in the
       checklist set) in the Waiting or In-Progress state, the agent
       puts the candidate pair state to Waiting and continues with the
       next step.

   3.  If there are one or more candidate pairs in the Waiting state,
       the agent picks the highest-priority candidate pair (if there are
       multiple pairs with the same priority, the pair with the lowest
       component ID is picked) in the Waiting state, performs a
       connectivity check on that pair, puts the candidate pair state to
       In-Progress, and aborts the subsequent steps.

   4.  If this step is reached, no check could be performed for the
       checklist that was picked.  So, without waiting for timer Ta to
       expire again, select the next checklist in the Running state and
       return to step #1.  If this happens for every single checklist in
       the Running state, meaning there are no remaining candidate pairs
       to perform connectivity checks for, abort these steps.

   Once the agent has picked a candidate pair for which a connectivity
   check is to be performed, the agent starts a check and sends the
   Binding request from the base associated with the local candidate of
   the pair to the remote candidate of the pair, as described in
   Section 7.2.4.

   Based on local policy, an agent MAY choose to terminate performing
   the connectivity checks for one or more checklists in the checklist
   set at any time.  However, only the controlling agent is allowed to
   conclude ICE (Section 8).

   To compute the message integrity for the check, the agent uses the
   remote username fragment and password learned from the candidate
   information obtained from its peer.  The local username fragment is
   known directly by the agent for its own candidate.

Top      Up      ToC       Page 38 
6.2.  Lite Implementation Procedures

   Lite implementations skip most of the steps in Section 6 except for
   verifying the peer's ICE support and determining its role in the ICE
   processing.

   If the lite implementation is the controlling agent (which will only
   happen if the peer ICE agent is also a lite implementation), it
   selects a candidate pair based on the ones in the candidate exchange
   (for IPv4, there is only ever one pair) and then updates the peer
   with the new candidate information reflecting that selection, if
   needed (it is never needed for an IPv4-only host).



(page 38 continued on part 3)

Next Section