Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8445

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

Pages: 100
Proposed Standard
Errata
Obsoletes:  5245
Updated by:  8863
Part 2 of 6 – Pages 18 to 38
First   Prev   Next

Top   ToC   RFC8445 - Page 18   prevText

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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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   ToC   RFC8445 - 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