Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
obsoleted by
- rfc-8445 — Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
- rfc-8839 — Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)
obsoletes
- rfc-4091 — The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework
- rfc-4092 — Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
updated by
- rfc-6336 — IANA Registry for Interactive Connectivity Establishment (ICE) Options
Extracted elements (28)
ICE uses STUN Binding Indications (rather than Binding Requests) for keepalives after ICE completes because requests require a response which consumes TURN bandwidth and creates unnecessary load; indications are one-way and sufficient to maintain NAT bindings without the overhead of a full request/response cycle.
Peer reflexive candidates are preferred over server reflexive candidates (given higher type preference) because they represent the actual address seen by the peer after all NATs, which is more directly useful for communication, while server reflexive candidates are discovered from a third-party STUN server and may not reflect the exact NAT binding used toward the peer.
The remote-candidates SDP attribute is sent by the controlling agent in the updated offer after ICE completes, allowing the answerer to immediately begin sending media to the nominated candidate even before the answer is received. Without it, the answerer would not know which remote candidate was nominated until the offer/answer round trip completes.
When an agent receives an offer/answer where ICE candidates are present but none match the default destination for a media component, the agent MUST include an 'a=ice-mismatch' attribute in its answer and process the SDP using normal RFC 3264 procedures rather than ICE, signaling to the peer that ICE cannot be used for this session.
After ICE completes, agents MUST send keepalives at least once every 15 seconds on each selected candidate pair using STUN Binding Indications, to maintain NAT bindings. If the selected pair uses a relayed candidate, TURN channel data or Send indications may substitute.
Agents MUST support both Regular Nomination and respond correctly to the USE-CANDIDATE flag. The controlling agent nominates by sending a STUN request with the USE-CANDIDATE attribute set; once the nominated pair's STUN transaction completes, both sides cancel further checks for that media stream.
Agents SHOULD obtain relayed candidates and SHOULD obtain server reflexive candidates; these are at SHOULD strength to permit closed-network deployments to omit STUN/TURN. If not gathered, the functionality SHOULD be implemented but disabled via configuration for future re-enablement.
An agent MUST limit the total number of connectivity checks across all check lists to a configurable value, with a default of 100 RECOMMENDED. Lower-priority pairs are discarded to enforce this limit, defending against STUN amplification attacks.
Each agent MUST select a 64-bit random tie-breaker value uniformly distributed between 0 and 2^64-1. This value is used in ICE-CONTROLLED and ICE-CONTROLLING STUN attributes to detect and resolve role conflicts when both agents mistakenly believe they have the same role.
Each candidate for a media stream MUST have a unique priority that MUST be a positive integer between 1 and (2^31 - 1). The recommended formula is: priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID), where type preference is 0-126 and local preference is 0-65535.
If a lite implementation is deployed, it MUST include an 'a=ice-lite' session-level attribute in its SDP; full implementations MUST NOT include this attribute. Lite implementations only use host candidates and do not run state machines or generate connectivity checks.
Media MUST be sent using the selected candidate pair once ICE nominates it. Before ICE completes, a full implementation MAY send media on any valid candidate pair; after completing, it MUST use only the selected pair.
Once server reflexive and relayed candidates are allocated, they MUST be kept alive until ICE processing completes. Server reflexive bindings are refreshed via additional Binding requests; TURN allocations are refreshed using the TURN Refresh transaction.
STUN connectivity checks MUST use the short-term credential mechanism with credentials exchanged via ice-ufrag and ice-pwd SDP attributes. The username for a check is formed by concatenating the remote agent's ufrag, a colon, and the local agent's ufrag.
The agent SHOULD NOT generate STUN/TURN transactions during candidate gathering more frequently than one every Ta milliseconds, where Ta is computed based on the number of candidates and streams. This pacing prevents network congestion from parallel check storms.
A candidate pair consists of a local candidate and a remote candidate with the same component ID and IP address version. Pairs have states (Frozen, Waiting, In-Progress, Succeeded, Failed) and properties including default, valid, nominated flags, and priority computed from controlling and controlled agent priorities.
ICE defines three candidate types: host candidates (obtained from local interfaces), server reflexive candidates (public-side NAT bindings discovered via STUN/TURN), and relayed candidates (allocated from a TURN server). Each candidate is a transport address (IP + port + protocol) with associated properties: type, priority, foundation, component ID, and base.
Peer reflexive candidates are discovered during connectivity checks when the STUN Binding response's XOR-MAPPED-ADDRESS differs from all known candidates. They represent NAT bindings created for the STUN check itself and are added to the valid list for further nomination consideration.
Triggered checks are connectivity checks initiated immediately upon receiving a STUN Binding request from a peer on a candidate pair, rather than waiting for the periodic timer. They accelerate convergence by allowing both directions to be verified quickly and are enqueued at the head of the triggered check queue.
This document registers four new STUN attributes with IANA: PRIORITY (0x0024), USE-CANDIDATE (0x0025), ICE-CONTROLLED (0x8029), and ICE-CONTROLLING (0x802A), and one new STUN error response code: 487 Role Conflict.
This document registers seven new SDP attributes with IANA: 'candidate', 'remote-candidates', 'ice-lite', 'ice-mismatch', 'ice-pwd', 'ice-ufrag', and 'ice-options', all under the existing SDP attribute registry.
ICE connectivity checks are protected by HMAC-SHA1 message integrity using credentials exchanged via the signaling channel. This prevents an off-path attacker from forging checks to redirect media; however, it does not protect against attackers who can intercept the signaling (e.g., SIP without TLS).
The STUN Amplification attack exploits the check list to cause an agent to send many STUN requests to a victim address. ICE mitigates this by limiting the total number of connectivity checks (default 100) and requiring agents to limit candidates accepted in offer/answer.
The Voice Hammer attack occurs when a malicious ICE agent directs media floods toward a victim by listing the victim's address as a candidate. ICE mitigates this by requiring a successful STUN check (with MAC) before media flows, ensuring the remote address has consented to receive traffic.
Candidate pair states transition as follows: pairs start Frozen; unfreeze moves them to Waiting; sending a check moves to In-Progress; a successful STUN response moves to Succeeded; failure moves to Failed. The controlling agent nominates a Succeeded pair to conclude ICE.
ICE defines three new STUN attributes: PRIORITY (32-bit unsigned integer, type 0x0024), USE-CANDIDATE (flag, no value, type 0x0025), ICE-CONTROLLED (64-bit tie-breaker, type 0x8029), and ICE-CONTROLLING (64-bit tie-breaker, type 0x802A).
The ice-ufrag attribute carries a minimum of 4 and maximum of 256 UTF-8 characters of random username fragment; the ice-pwd attribute carries a minimum of 22 and maximum of 256 UTF-8 characters password. Both provide at least 24 bits and 128 bits of randomness respectively.
The SDP 'candidate' attribute encodes: foundation (1-32 chars), component ID (1-256), transport (UDP), priority (32-bit integer), connection address, port, candidate type, and optional related address/port for reflexive and relayed candidates. Grammar is defined in Section 15.1.