17. Operational Considerations
This section discusses issues relevant to operators operating
networks where ICE will be used by endpoints.
17.1. NAT and Firewall Types
ICE was designed to work with existing NAT and firewall equipment.
Consequently, it is not necessary to replace or reconfigure existing
firewall and NAT equipment in order to facilitate deployment of ICE.
Indeed, ICE was developed to be deployed in environments where the
Voice over IP (VoIP) operator has no control over the IP network
infrastructure, including firewalls and NATs.
That said, ICE works best in environments where the NAT devices are
"behave" compliant, meeting the recommendations defined in [RFC4787]
and [RFC5382]. In networks with behave-compliant NAT, ICE will work
without the need for a TURN server, thus improving voice quality,
decreasing call setup times, and reducing the bandwidth demands on
the network operator.
17.2. Bandwidth Requirements
Deployment of ICE can have several interactions with available
network capacity that operators need to take into consideration.
17.2.1. STUN and TURN Server-Capacity Planning
First and foremost, ICE makes use of TURN and STUN servers, which
would typically be located in data centers. The STUN servers require
relatively little bandwidth. For each component of each data stream,
there will be one or more STUN transactions from each client to the
STUN server. In a basic voice-only IPv4 VoIP deployment, there will
be four transactions per call (one for RTP and one for RTCP, for both
the caller and callee). Each transaction is a single request and a
single response, the former being 20 bytes long, and the latter, 28.
Consequently, if a system has N users, and each makes four calls in a
busy hour, this would require N*1.7bps. For one million users, this
is 1.7 Mbps, a very small number (relatively speaking).
TURN traffic is more substantial. The TURN server will see traffic
volume equal to the STUN volume (indeed, if TURN servers are
deployed, there is no need for a separate STUN server), in addition
to the traffic for the actual data. The amount of calls requiring
TURN for data relay is highly dependent on network topologies, and
can and will vary over time. In a network with 100% behave-compliant
NATs, it is exactly zero.
The planning considerations above become more significant in
multimedia scenarios (e.g., audio and video conferences) and when the
numbers of participants in a session grow.
17.2.2. Gathering and Connectivity Checks
The process of gathering candidates and performing connectivity
checks can be bandwidth intensive. ICE has been designed to pace
both of these processes. The gathering and connectivity-check phases
are meant to generate traffic at roughly the same bandwidth as the
data traffic itself will consume once the ICE process concludes.
This was done to ensure that if a network is designed to support
communication traffic of a certain type (voice, video, or just text),
it will have sufficient capacity to support the ICE checks for that
data. Once ICE has concluded, the subsequent ICE keepalives will
later cause a marginal increase in the total bandwidth utilization;
however, this will typically be an extremely small increase.
Congestion due to the gathering and check phases has proven to be a
problem in deployments that did not utilize pacing. Typically,
access links became congested as the endpoints flooded the network
with checks as fast as they could send them. Consequently, network
operators need to ensure that their ICE implementations support the
pacing feature. Though this pacing does increase call setup times,
it makes ICE network friendly and easier to deploy.
STUN keepalives (in the form of STUN Binding Indications) are sent in
the middle of a data session. However, they are sent only in the
absence of actual data traffic. In deployments with continuous media
and without utilizing Voice Activity Detection (VAD), or deployments
where VAD is utilized together with short interval (max 1 second)
comfort noise, the keepalives are never used and there is no increase
in bandwidth usage. When VAD is being used without comfort noise,
keepalives will be sent during silence periods. This involves a
single packet every 15-20 seconds, far less than the packet every
20-30 ms that is sent when there is voice. Therefore, keepalives do
not have any real impact on capacity planning.
17.3. ICE and ICE-Lite
Deployments utilizing a mix of ICE and ICE-lite interoperate with
each other. They have been explicitly designed to do so.
However, ICE-lite can only be deployed in limited use cases. Those
cases, and the caveats involved in doing so, are documented in
17.4. Troubleshooting and Performance Management
ICE utilizes end-to-end connectivity checks and places much of the
processing in the endpoints. This introduces a challenge to the
network operator -- how can they troubleshoot ICE deployments? How
can they know how ICE is performing?
ICE has built-in features to help deal with these problems.
Signaling servers, typically deployed in data centers of the network
operator, will see the contents of the candidate exchanges that
convey the ICE parameters. These parameters include the type of each
candidate (host, server reflexive, or relayed), along with their
related addresses. Once ICE processing has completed, an updated
candidate exchange takes place, signaling the selected address (and
its type). This updated signaling is performed exactly for the
purposes of educating network equipment (such as a diagnostic tool
attached to a signaling) about the results of ICE processing.
As a consequence, through the logs generated by a signaling server, a
network operator can observe what types of candidates are being used
for each call and what addresses were selected by ICE. This is the
primary information that helps evaluate how ICE is performing.
17.5. Endpoint Configuration
ICE relies on several pieces of data being configured into the
endpoints. This configuration data includes timers, credentials for
TURN servers, and hostnames for STUN and TURN servers. ICE itself
does not provide a mechanism for this configuration. Instead, it is
assumed that this information is attached to whatever mechanism is
used to configure all of the other parameters in the endpoint. For
SIP phones, standard solutions such as the configuration framework
[RFC6080] have been defined.
18. IAB Considerations
The IAB has studied the problem of "Unilateral Self-Address Fixing"
(UNSAF), which is the general process by which an ICE agent attempts
to determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism [RFC3424]. ICE
is an example of a protocol that performs this type of function.
Interestingly, the process for ICE is not unilateral, but bilateral,
and the difference has a significant impact on the issues raised by
the IAB. Indeed, ICE can be considered a Bilateral Self-Address
Fixing (B-SAF) protocol, rather than an UNSAF protocol. Regardless,
the IAB has mandated that any protocols developed for this purpose
document a specific set of considerations. This section meets those
18.1. Problem Definition
From RFC 3424, any UNSAF proposal needs to provide:
Precise definition of a specific, limited-scope problem that is to
be solved with the UNSAF proposal. A short term fix should not be
generalized to solve other problems. Such generalizations lead to
the the prolonged dependence on and usage of the supposed short
term fix -- meaning that it is no longer accurate to call it
The specific problems being solved by ICE are:
Providing a means for two peers to determine the set of transport
addresses that can be used for communication.
Providing a means for an agent to determine an address that is
reachable by another peer with which it wishes to communicate.
18.2. Exit Strategy
From RFC 3424, any UNSAF proposal needs to provide:
Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed.
ICE itself doesn't easily get phased out. However, it is useful even
in a globally connected Internet, to serve as a means for detecting
whether a router failure has temporarily disrupted connectivity, for
example. ICE also helps prevent certain security attacks that have
nothing to do with NAT. However, what ICE does is help phase out
other UNSAF mechanisms. ICE effectively picks amongst those
mechanisms, prioritizing ones that are better and deprioritizing ones
that are worse. As NATs begin to dissipate as IPv6 is introduced,
server-reflexive and relayed candidates (both forms of UNSAF
addresses) simply never get used, because higher-priority
connectivity exists to the native host candidates. Therefore, the
servers get used less and less and can eventually be removed when
their usage goes to zero.
Indeed, ICE can assist in the transition from IPv4 to IPv6. It can
be used to determine whether to use IPv6 or IPv4 when two dual-stack
hosts communicate with SIP (IPv6 gets used). It can also allow a
network with both 6to4 and native v6 connectivity to determine which
address to use when communicating with a peer.
18.3. Brittleness Introduced by ICE
From RFC 3424, any UNSAF proposal needs to provide:
Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition.
ICE actually removes brittleness from existing UNSAF mechanisms. In
particular, classic STUN (as described in RFC 3489 [RFC3489]) has
several points of brittleness. One of them is the discovery process
that requires an ICE agent to try to classify the type of NAT it is
behind. This process is error prone. With ICE, that discovery
process is simply not used. Rather than unilaterally assessing the
validity of the address, its validity is dynamically determined by
measuring connectivity to a peer. The process of determining
connectivity is very robust.
Another point of brittleness in classic STUN and any other unilateral
mechanism is its absolute reliance on an additional server. ICE
makes use of a server for allocating unilateral addresses, but it
allows agents to directly connect if possible. Therefore, in some
cases, the failure of a STUN server would still allow for a call to
progress when ICE is used.
Another point of brittleness in classic STUN is that it assumes the
STUN server is on the public Internet. Interestingly, with ICE, that
is not necessary. There can be a multitude of STUN servers in a
variety of address realms. ICE will discover the one that has
provided a usable address.
The most troubling point of brittleness in classic STUN is that it
doesn't work in all network topologies. In cases where there is a
shared NAT between each agent and the STUN server, traditional STUN
may not work. With ICE, that restriction is removed.
Classic STUN also introduces some security considerations.
Fortunately, those security considerations are also mitigated by ICE.
Consequently, ICE serves to repair the brittleness introduced in
classic STUN, and it does not introduce any additional brittleness
into the system.
The penalty of these improvements is that ICE increases session
18.4. Requirements for a Long-Term Solution
From RFC 3424, any UNSAF proposal needs to provide the following:
Identify requirements for longer term, sound technical solutions;
contribute to the process of finding the right longer term
Our conclusions from RFC 3489 remain unchanged. However, we feel ICE
actually helps because we believe it can be part of the long-term
18.5. Issues with Existing NAPT Boxes
From RFC 3424, any UNSAF proposal needs to provide:
Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports.
A number of NAT boxes are now being deployed into the market that try
to provide "generic" ALG functionality. These generic ALGs hunt for
IP addresses, in either text or binary form within a packet, and
rewrite them if they match a binding. This interferes with classic
STUN. However, the update to STUN [RFC5389] uses an encoding that
hides these binary addresses from generic ALGs.
Existing NAPT boxes have non-deterministic and typically short
expiration times for UDP-based bindings. This requires
implementations to send periodic keepalives to maintain those
bindings. ICE uses a default of 15 s, which is a very conservative
estimate. Eventually, over time, as NAT boxes become compliant to
behave [RFC4787], this minimum keepalive will become deterministic
and well known, and the ICE timers can be adjusted. Having a way to
discover and control the minimum keepalive interval would be far
19. Security Considerations
19.1. IP Address Privacy
The process of probing for candidates reveals the source addresses of
the client and its peer to any on-network listening attacker, and the
process of exchanging candidates reveals the addresses to any
attacker that is able to see the negotiation. Some addresses, such
as the server-reflexive addresses gathered through the local
interface of VPN users, may be sensitive information. If these
potential attacks cannot be mitigated, ICE usages can define
mechanisms for controlling which addresses are revealed to the
negotiation and/or probing process. Individual implementations may
also have implementation-specific rules for controlling which
addresses are revealed. For example, [WebRTC-IP-HANDLING] provides
additional information about the privacy aspects of revealing IP
addresses via ICE for WebRTC applications. ICE implementations where
such issues can arise are RECOMMENDED to provide a programmatic or
user interface that provides control over which network interfaces
are used to generate candidates.
Based on the types of candidates provided by the peer, and the
results of the connectivity tests performed against those candidates,
the peer might be able to determine characteristics of the local
network, e.g., if different timings are apparent to the peer. Within
the limit, the peer might be able to probe the local network.
There are several types of attacks possible in an ICE system. The
subsections consider these attacks and their countermeasures.
19.2. Attacks on Connectivity Checks
An attacker might attempt to disrupt the STUN connectivity checks.
Ultimately, all of these attacks fool an ICE agent into thinking
something incorrect about the results of the connectivity checks.
Depending on the type of attack, the attacker needs to have different
capabilities. In some cases, the attacker needs to be on the path of
the connectivity checks. In other cases, the attacker does not need
to be on the path, as long as it is able to generate STUN
connectivity checks. While attacks on connectivity checks are
typically performed by network entities, if an attacker is able to
control an endpoint, it might be able to trigger connectivity-check
attacks. The possible false conclusions an attacker can try and
False Invalid: An attacker can fool a pair of agents into thinking a
candidate pair is invalid, when it isn't. This can be used to
cause an agent to prefer a different candidate (such as one
injected by the attacker) or to disrupt a call by forcing all
candidates to fail.
False Valid: An attacker can fool a pair of agents into thinking a
candidate pair is valid, when it isn't. This can cause an agent
to proceed with a session but then not be able to receive any
False Peer-Reflexive Candidate: An attacker can cause an agent to
discover a new peer-reflexive candidate when it is not expected
to. This can be used to redirect data streams to a DoS target or
to the attacker, for eavesdropping or other purposes.
False Valid on False Candidate: An attacker has already convinced an
agent that there is a candidate with an address that does not
actually route to that agent (e.g., by injecting a false peer-
reflexive candidate or false server-reflexive candidate). The
attacker then launches an attack that forces the agents to believe
that this candidate is valid.
If an attacker can cause a false peer-reflexive candidate or false
valid on a false candidate, it can launch any of the attacks
described in [RFC5389].
To force the false invalid result, the attacker has to wait for the
connectivity check from one of the agents to be sent. When it is,
the attacker needs to inject a fake response with an unrecoverable
error response (such as a 400), or drop the response so that it never
reaches the agent. However, since the candidate is, in fact, valid,
the original request may reach the peer agent and result in a success
response. The attacker needs to force this packet or its response to
be dropped through a DoS attack, a Layer 2 network disruption, or
another technique. If it doesn't do this, the success response will
also reach the originator, alerting it to a possible attack. The
ability for the attacker to generate a fake response is mitigated
through the STUN short-term credential mechanism. In order for this
response to be processed, the attacker needs the password. If the
candidate exchange signaling is secured, the attacker will not have
the password, and its response will be discarded.
Spoofed ICMP Hard Errors (Type 3, codes 2-4) can also be used to
create false invalid results. If an ICE agent implements a response
to these ICMP errors, the attacker is capable of generating an ICMP
message that is delivered to the agent sending the connectivity
check. The validation of the ICMP error message by the agent is its
only defense. For Type 3 code=4, the outer IP header provides no
validation, unless the connectivity check was sent with DF=0. For
codes 2 or 3, which are originated by the host, the address is
expected to be any of the remote agent's host, reflexive, or relay
candidate IP addresses. The ICMP message includes the IP header and
UDP header of the message triggering the error. These fields also
need to be validated. The IP destination and UDP destination port
need to match either the targeted candidate address and port or the
candidate's base address. The source IP address and port can be any
candidate for the same base address of the agent sending the
connectivity check. Thus, any attacker having access to the exchange
of the candidates will have the necessary information. Hence, the
validation is a weak defense, and the sending of spoofed ICMP attacks
is also possible for off-path attackers from a node in a network
without source address validation.
Forcing the fake valid result works in a similar way. The attacker
needs to wait for the Binding request from each agent and inject a
fake success response. Again, due to the STUN short-term credential
mechanism, in order for the attacker to inject a valid success
response, the attacker needs the password. Alternatively, the
attacker can route (e.g., using a tunneling mechanism) a valid
success response, which normally would be dropped or rejected by the
network, to the agent.
Forcing the false peer-reflexive candidate result can be done with
either fake requests or responses, or with replays. We consider the
fake requests and responses case first. It requires the attacker to
send a Binding request to one agent with a source IP address and port
for the false candidate. In addition, the attacker needs to wait for
a Binding request from the other agent and generate a fake response
with a XOR-MAPPED-ADDRESS attribute containing the false candidate.
Like the other attacks described here, this attack is mitigated by
the STUN message integrity mechanisms and secure candidate exchanges.
Forcing the false peer-reflexive candidate result with packet replays
is different. The attacker waits until one of the agents sends a
check. It intercepts this request and replays it towards the other
agent with a faked source IP address. It also needs to prevent the
original request from reaching the remote agent, by either launching
a DoS attack to cause the packet to be dropped or forcing it to be
dropped using Layer 2 mechanisms. The replayed packet is received at
the other agent, and accepted, since the integrity check passes (the
integrity check cannot and does not cover the source IP address and
port). It is then responded to. This response will contain a XOR-
MAPPED-ADDRESS with the false candidate, and it will be sent to that
false candidate. The attacker then needs to receive it and relay it
towards the originator.
The other agent will then initiate a connectivity check towards that
false candidate. This validation needs to succeed. This requires
the attacker to force a false valid on a false candidate. The
injecting of fake requests or responses to achieve this goal is
prevented using the integrity mechanisms of STUN and the candidate
exchange. Thus, this attack can only be launched through replays.
To do that, the attacker needs to intercept the check towards this
false candidate and replay it towards the other agent. Then, it
needs to intercept the response and replay that back as well.
This attack is very hard to launch unless the attacker is identified
by the fake candidate. This is because it requires the attacker to
intercept and replay packets sent by two different hosts. If both
agents are on different networks (e.g., across the public Internet),
this attack can be hard to coordinate, since it needs to occur
against two different endpoints on different parts of the network at
the same time.
If the attacker itself is identified by the fake candidate, the
attack is easier to coordinate. However, if the data path is secured
(e.g., using the Secure Real-time Transport Protocol (SRTP)
[RFC3711]), the attacker will not be able to process the data
packets, but will only be able to discard them, effectively disabling
the data stream. However, this attack requires the agent to disrupt
packets in order to block the connectivity check from reaching the
target. In that case, if the goal is to disrupt the data stream,
it's much easier to just disrupt it with the same mechanism, rather
than attack ICE.
19.3. Attacks on Server-Reflexive Address Gathering
ICE endpoints make use of STUN Binding requests for gathering server-
reflexive candidates from a STUN server. These requests are not
authenticated in any way. As a consequence, there are numerous
techniques an attacker can employ to provide the client with a false
o An attacker can compromise the DNS, causing DNS queries to return
a rogue STUN server address. That server can provide the client
with fake server-reflexive candidates. This attack is mitigated
by DNS security, though DNSSEC is not required to address it.
o An attacker that can observe STUN messages (such as an attacker on
a shared network segment, like Wi-Fi) can inject a fake response
that is valid and will be accepted by the client.
o An attacker can compromise a STUN server and cause it to send
responses with incorrect mapped addresses.
A false mapped address learned by these attacks will be used as a
server-reflexive candidate in the establishment of the ICE session.
For this candidate to actually be used for data, the attacker also
needs to attack the connectivity checks, and in particular, force a
false valid on a false candidate. This attack is very hard to launch
if the false address identifies a fourth party (neither the
initiator, responder, nor attacker), since it requires attacking the
checks generated by each ICE agent in the session and is prevented by
SRTP if it identifies the attacker itself.
If the attacker elects not to attack the connectivity checks, the
worst it can do is prevent the server-reflexive candidate from being
used. However, if the peer agent has at least one candidate that is
reachable by the agent under attack, the STUN connectivity checks
themselves will provide a peer-reflexive candidate that can be used
for the exchange of data. Peer-reflexive candidates are generally
preferred over server-reflexive candidates. As such, an attack
solely on the STUN address gathering will normally have no impact on
a session at all.
19.4. Attacks on Relayed Candidate Gathering
An attacker might attempt to disrupt the gathering of relayed
candidates, forcing the client to believe it has a false relayed
candidate. Exchanges with the TURN server are authenticated using a
long-term credential. Consequently, injection of fake responses or
requests will not work. In addition, unlike Binding requests,
Allocate requests are not susceptible to replay attacks with modified
source IP addresses and ports, since the source IP address and port
are not utilized to provide the client with its relayed candidate.
Even if an attacker has caused the client to believe in a false
relayed candidate, the connectivity checks cause such a candidate to
be used only if they succeed. Thus, an attacker needs to launch a
false valid on a false candidate, per above, which is a very
difficult attack to coordinate.
19.5. Insider Attacks
In addition to attacks where the attacker is a third party trying to
insert fake candidate information or STUN messages, there are attacks
possible with ICE when the attacker is an authenticated and valid
participant in the ICE exchange.
19.5.1. STUN Amplification Attack
The STUN amplification attack is similar to a "voice hammer" attack,
where the attacker causes other agents to direct voice packets to the
attack target. However, instead of voice packets being directed to
the target, STUN connectivity checks are directed to the target. The
attacker sends a large number of candidates, say, 50. The responding
agent receives the candidate information and starts its checks, which
are directed at the target, and consequently, never generate a
response. In the case of WebRTC, the user might not even be aware
that this attack is ongoing, since it might be triggered in the
The answerer will start a new connectivity check every Ta ms (say,
Ta=50ms). However, the retransmission timers are set to a large
number due to the large number of candidates. As a consequence,
packets will be sent at an interval of one every Ta milliseconds and
then with increasing intervals after that. Thus, STUN will not send
packets at a rate faster than data would be sent, and the STUN
packets persist only briefly, until ICE fails for the session.
Nonetheless, this is an amplification mechanism.
It is impossible to eliminate the amplification, but the volume can
be reduced through a variety of heuristics. ICE agents SHOULD limit
the total number of connectivity checks they perform to 100.
Additionally, agents MAY limit the number of candidates they will
Frequently, protocols that wish to avoid these kinds of attacks force
the initiator to wait for a response prior to sending the next
message. However, in the case of ICE, this is not possible. It is
not possible to differentiate the following two cases:
o There was no response because the initiator is being used to
launch a DoS attack against an unsuspecting target that will not
o There was no response because the IP address and port are not
reachable by the initiator.
In the second case, another check will be sent at the next
opportunity, while in the former case, no further checks will be
20. IANA Considerations
The original ICE specification registered four STUN attributes and
one new STUN error response. The STUN attributes and error response
are reproduced here. In addition, this specification registers a new
20.1. STUN Attributes
IANA has registered four STUN attributes:
20.2. STUN Error Responses
IANA has registered the following STUN error-response code:
487 Role Conflict: The client asserted an ICE role (controlling or
controlled) that is in conflict with the role of the server.
20.3. ICE Options
IANA has registered the following ICE option in the "ICE Options"
subregistry of the "Interactive Connectivity Establishment (ICE)"
registry, following the procedures defined in [RFC6336].
ICE Option name:
The ICE option indicates that the ICE agent using the ICE option
is implemented according to RFC 8445.
21. Changes from RFC 5245
The purpose of this updated ICE specification is to:
o Clarify procedures in RFC 5245.
o Make technical changes, due to discovered flaws in RFC 5245 and
feedback from the community that has implemented and deployed ICE
applications based on RFC 5245.
o Make the procedures independent of the signaling protocol, by
removing the SIP and SDP procedures. Procedures specific to a
signaling protocol will be defined in separate usage documents.
[ICE-SIP-SDP] defines ICE usage with SIP and SDP.
The following technical changes have been done:
o Aggressive nomination removed.
o The procedures for calculating candidate pair states and
scheduling connectivity checks modified.
o Procedures for calculation of Ta and RTO modified.
o Active checklist and Frozen checklist definitions removed.
o 'ice2' ICE option added.
o IPv6 considerations modified.
o Usage with no-op for keepalives, and keepalives with non-ICE
22.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,