TCP Candidates with Interactive Connectivity Establishment (ICE)
Extracted elements (29)
TCP candidates require the regular (not aggressive) ICE selection algorithm because aggressive selection might pick a transient pair, causing the agent to close other connections—one of which might be about to be selected as a better candidate. This race condition could accidentally close the connection for the ultimately selected pair.
TCP media streams using ICE must use the RFC 4571 framing shim even if the application protocol is not RTP. Stream-oriented transports require a framing mechanism to extract STUN packets from application-layer traffic; RFC 4571 provides this, allowing ICE to demultiplex STUN and data on the same TCP connection.
The active candidate's port is set to 9 (Discard) because it is meaningless — the actual port is chosen at connection time. The spec sets a port value anyway to keep active candidate encoding consistent with passive and S-O candidates, allowing uniform SDP parsing.
TURN over TCP is an especially important use case for ICE TCP because it only requires agents to make outbound TCP connections to a public server, which is broadly permitted through NATs and firewalls. This provides a high-reliability fallback when direct UDP and TCP paths both fail.
ICE TCP has lower NAT traversal success probability than UDP-based ICE when both hosts are behind NATs, because many deployed NATs have endpoint-dependent mapping behavior or do not correctly handle TCP simultaneous-open handshake packets. Measurements from 2005 found TCP simultaneous-open succeeded in roughly 45% of cases.
Implementations should include both IPv4 and IPv6 candidates. If the local network does not support IPv6, clients SHOULD use techniques such as TURN-IPv6 (RFC 6156), Teredo (RFC 4380), or SOCKS IPv4-IPv6 gatewaying (RFC 3089) to obtain IPv6 candidates.
When ICE selects a TCP candidate pair for a media stream protected by SRTP, it is RECOMMENDED that the agent still uses SRTP over the ICE-established TCP connection rather than RTP over TLS. RTP over TLS breaks RTP header compression and on-path RTP analysis tools.
When TLS or DTLS is used, it runs over the RFC 4571 framing shim while STUN runs outside the (D)TLS connection. ICE and (D)TLS are peers in the protocol stack; STUN messages are never sent within the TLS or DTLS-SRTP session, even for keepalive purposes.
Agents SHOULD obtain host candidates (passive and S-O) for each component of each TCP-capable media stream on each interface. It is highly RECOMMENDED that a host obtain at least one set of host candidates and one set of relayed candidates.
An ICE TCP agent (full or lite) MUST be prepared to receive incoming TCP connection requests on the base of any simultaneous-open or passive TCP candidate. When a connection request is received, the agent MUST accept it and MUST utilize RFC 4571 framing for the lifetime of the connection.
During an ICE restart for a media stream with selected TCP candidate pairs, agents MUST NOT close the existing connections. If both agents include a S-O candidate matching the previously selected connection, they MUST NOT attempt to open a new connection; instead the existing connection is reused for STUN checks.
For RTP-based media streams it is RECOMMENDED that UDP candidates are preferred over TCP candidates. The default candidate SHOULD NOT be a simultaneous-open candidate; for real-time streams the default candidates SHOULD be UDP-based when both UDP and TCP are offered.
For TCP candidates, the local preference in the ICE priority formula is updated to: local preference = (2^13) * direction-pref + other-pref. The direction-pref MUST be between 0 and 7 inclusive and other-pref MUST be between 0 and 8191 inclusive. Any two candidates with the same type-preference and direction-pref MUST have a unique other-pref.
If a relayed candidate from a TURN server was selected by ICE, the TCP connection to the TURN server MUST be kept open for the duration of the media session. If the connection to the TURN server fails, the client SHOULD reconnect, obtain a new allocation, and restart ICE for the media stream.
If a TCP connection cannot be established for a connectivity check, the check is considered to have failed, and a full-mode agent MUST update the pair state to Failed in the check list. STUN retransmissions are not needed over TCP since TCP provides reliable delivery.
If an agent's local candidate is tcp-active or tcp-so and the selected TCP connection has closed, it MUST reopen a connection to the remote candidate of the selected pair. If the local candidate is tcp-passive, the agent MUST await an incoming connection and cannot send media until one arrives.
If both agents use lite mode, the answerer MUST still accept incoming TCP connections to any of its passive candidates from any IP address listed in the initial offer. If a connection created in parallel does not match the candidate pair in the new offer, it MUST be closed and ICE restart SHOULD be performed.
If the default candidate is TCP-based, the agent MUST include the a=setup and a=connection attributes from RFC 4145 in the SDP. If an agent is the answerer, the a=setup attribute MUST meet the constraints of RFC 4145 based on the value in the offer.
If there are TCP candidates for a media stream, a controlling agent MUST use the regular selection algorithm (not aggressive). This prevents a race condition where aggressive selection could cause a transient pair to be selected, causing other connections to be closed prematurely.
Once TCP candidates have been obtained, the agent MUST keep the TCP connections open until ICE processing has completed.
The RFC 4571 framing MUST be used when sending and receiving media. When sending non-RTP media, if the arbitrary bytes chosen would be interpreted as a STUN packet (based on RFC 5389 checks on the two most significant bits, magic cookie, length, and fingerprint), the sender MUST choose a different number of bytes.
When forming candidate pairs for TCP, only these pairings are valid: tcp-so with tcp-so, tcp-active with tcp-passive, and tcp-passive with tcp-active. When pruning the check list, the agent MUST remove any pair for which the local candidate is a passive TCP candidate.
When sending a TCP connectivity check, if a connection does not yet exist the agent opens one. Once established, the agent MUST utilize the RFC 4571 shim for the duration the connection remains open; STUN Binding requests and responses are sent on top of this shim with the RFC 4571 length field preceding each STUN message.
ICE TCP defines three TCP candidate types: active (agent initiates connection but won't receive incoming), passive (agent receives incoming but won't initiate), and simultaneous-open (S-O; agent attempts to open a connection simultaneously with its peer). These types govern how TCP connections are established during connectivity checks.
IANA created a new sub-registry 'ICE Transport Protocols' under the 'Interactive Connectivity Establishment (ICE)' registry for ICE candidate-attribute transport extensions. Initial values are UDP (RFC 5245, Section 15.1) and TCP (RFC 6544, Section 4.5); future assignments require IETF Review or IESG Approval.
A STUN amplification attack (described in RFC 5245 Section 18.5.2) is more severe for TCP than UDP because TCP connection establishment is required before any checks are performed. An ICE agent SHOULD NOT have more than 5 outstanding TCP connection attempts with the same peer to the same IP address.
The main threat in ICE is connection hijacking to direct media to DoS targets or malicious users. Full ICE TCP implementations prevent this by requiring STUN validation (which requires a shared secret from the rendezvous protocol) on each TCP connection before it can carry media. Usage of SIPS is RECOMMENDED to protect the rendezvous exchange.
When both agents use lite mode, no connectivity checks are sent, so additional procedures such as media-level security are needed to validate the connection. The lack of checks is especially problematic when a host is behind a NAT with a private address, as the peer may accidentally connect to a different host in the same private address space.
TCP candidates are encoded in a=candidate lines with the transport set to 'TCP' and a mandatory tcptype extension attribute: 'tcptype' SP tcp-type where tcp-type is 'active', 'passive', or 'so'. The connection-address for active candidates MUST be a valid IP but the port(s) MUST be set to 9 (Discard) because the port is meaningless for active candidates.