Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)
updates
Extracted elements (17)
A side effect of the PAC timer is that scenarios where ICE should fail (e.g., both sides provide unsupported address families) will no longer fail immediately but will only fail after the PAC timer expires. Because most ICE scenarios already require extended time to determine failure, the application impact is expected to be minimal.
Candidates provided by one side may be discarded by the peer if they use an unsupported address family (e.g., an IPv6 host candidate in a NAT64 scenario), leaving an empty checklist and triggering immediate ICE failure; the PAC timer provides time for peer-reflexive candidate discovery in this case.
Per RFC 8838, an ICE agent may provide zero candidates if it knows the remote endpoint is directly reachable. Under strict RFC 8445 procedures this causes immediate ICE failure because the peer's checklist is empty; the PAC timer prevents this premature failure.
RFC 8445 Section 7.2.5.2 defines conditions under which a candidate pair fails well before the connectivity check transaction timeout — for example, a check to a non-routable address that immediately receives an ICMP error — leaving only failed pairs in the checklist and triggering premature failure.
The 39.5-second recommended PAC timer value is chosen to roughly coincide with the maximum possible duration of ICE connectivity checks from the remote peer, which, if successful, could create peer-reflexive candidates. Because the local agent does not know the remote side's candidate pair count or pacing interval, this is an educated guess.
The core problem ICE PAC addresses is premature ICE failure: if an agent runs out of candidate pairs to check before inbound connectivity checks from the remote peer have had a chance to trigger peer-reflexive candidate discovery, it will declare failure even though a valid pair could still be found.
In most ICE deployments, the lengthy per-transaction connectivity check timeouts (typically tens of seconds) naturally prevent premature failure; the scenarios described in this document are specific edge cases where the problem frequently occurs, such as NAT64 deployments or trickle ICE with zero initial candidates.
RFC 8838 Trickle ICE already addresses a related problem by waiting for an end-of-candidates indication before declaring failure. However, this is insufficient on its own because peer-reflexive candidates may still be discovered after the end-of-candidates indication is received, so the PAC timer is still required.
Even when using Trickle ICE (RFC 8838), the PAC timer solution MUST still be used, because peer-reflexive candidates may be discovered after the end-of-candidates indication has been received.
ICE agents MAY use the PAC timer to serve as an end-of-candidates fallback when using Trickle ICE, since sending an end-of-candidates indication is only a SHOULD-strength requirement and agents need a backup mechanism.
The controlling ICE agent SHOULD wait a sufficient amount of time before nominating candidate pairs to allow peer-reflexive candidates to be discovered and checked, and it MAY use the PAC timer for this purpose.
The RECOMMENDED duration for the PAC timer is equal to the agent's connectivity check transaction timeout including all retransmissions. With default RTO and Rc values this amounts to 39.5 seconds as defined in RFC 5389 Section 7.2.1.
When a full ICE implementation begins ICE processing as described in RFC 8445 Section 6.1, it MUST set a PAC timer (Patiently Awaiting Connectivity) to ensure ICE runs for a minimum amount of time before determining failure.
When the PAC timer period elapses, the ICE agent MUST resume typical ICE processing, including setting the state of any checklists to Failed if they have no pairs left to check and handling consequences as indicated in RFC 8445 Section 8.1.2.
While the PAC timer is still running, the ICE agent MUST NOT update a checklist state from Running to Failed, even if there are no pairs left in the checklist to check. As a result, the ICE agent will not remove any data streams or set the ICE session state to Failed while the timer is running.
The PAC timer (Patiently Awaiting Connectivity) is started once the ICE agent has sent credentials (Username Fragment and Password) and received an indication that the remote side is ready to begin connectivity checks. The timer starts even if no ICE candidates have been sent or received.
The security considerations for ICE are defined in RFC 8445. This specification only recommends that ICE agents wait for a certain period before declaring ICE failure and introduces no new security considerations.