Draft: draft-ietf-ice-rfc5245bis

Commentary: Important nits ; please address : 1 ) Sec 14.2 : RFC 6928 , RFC 5389 , and RFC 6298 should be actual references and listed in the reference section . 2 ) Sec 14.2 : Maybe you should really not use normative language in the reasoning part of this section ? ! I find especially this SHOULD in the following sentence confusing ( as it does n't give a reference to another RFC that defines this ): " Let MinPacing be the minimum pacing interval between transactions , which SHOULD be 5ms . " Given that the previous text says : " all transactions from all agents [ ... ] MUST NOT be sent more often than once every 5ms " My recommendation : please use lower cases " shoulds " and " musts " in the reasoning part ! 3 ) Sec 19.4.1 : " ( say , Ta=20ms ) " Maybe use also a value of 50ms here to avoid confusion .
Protocols establishing communication sessions between peers typically
involve exchanging IP addresses and ports for the data sources and
sinks.  However this poses challenges when operated through Network
Address Translators (NATs) RFC3235.  These protocols also seek to
create a data flow directly between participants, so that there is no
application layer intermediary between them.  This is done to reduce
data latency, decrease packet loss, and reduce the operational costs
of deploying the application.  However, this is difficult to
accomplish through NATs.  A full treatment of the reasons for this is
beyond the scope of this specification.
Protocols establishing communication sessions between peers typically
involve exchanging IP addresses and ports for the data sources and
sinks.  However, this poses challenges when operated through Network
Address Translators (NATs) RFC3235.  These protocols also seek to
create a data flow directly between participants, so that there is no
application layer intermediary between them.  This is done to reduce
data latency, decrease packet loss, and reduce the operational costs
of deploying the application.  However, this is difficult to
accomplish through NATs.  A full treatment of the reasons for this is
beyond the scope of this specification.
Numerous solutions have been defined for allowing these protocols to
operate through NATs.  These include Application Layer Gateways
(ALGs), the RFC3303, the original RFC3489 specification, and RFC3102
RFC3103 along with session description extensions needed to make them
work, such as the Session Description Protocol (SDP) RFC4566
attribute for the Real Time Control Protocol (RTCP) RFC3605.
Unfortunately, these techniques all have pros and cons which, make
each one optimal in some network topologies, but a poor choice in
others.  The result is that administrators and implementors are
making assumptions about the topologies of the networks in which
their solutions will be deployed.  This introduces complexity and
brittleness into the system.  What is needed is a single solution
that is flexible enough to work well in all situations.
Numerous solutions have been defined for allowing these protocols to
operate through NATs.  These include Application Layer Gateways
(ALGs), the RFC3303, the original RFC3489 specification, and RFC3102
RFC3103 along with session description extensions needed to make them
work, such as the Session Description Protocol (SDP) RFC4566
attribute for the Real Time Control Protocol (RTCP) RFC3605.
Unfortunately, these techniques all have pros and cons that make each
one optimal in some network topologies, but a poor choice in others.
The result is that administrators and implementers are making
assumptions about the topologies of the networks in which their
solutions will be deployed.  This introduces complexity and
brittleness into the system.
This specification defines Interactive Connectivity Establishment
(ICE) as a technique for NAT traversal for UDP-based data streams
(though ICE has been extended to handle other transport protocols,
such as TCP RFC6544).  ICE works by exchanging a multiplicity of IP
addresses and ports which are then tested for connectivity by peer-
to-peer connectivity checks.  The IP addresses and ports are
exchanged exchanged using ICE usage-specific mechanisms (for example,
including in a offer/answer exchange) and the connectivity checks are
performed using Session Traversal Utilities for NAT (STUN)
specification RFC5389.  ICE also makes use of Traversal Using Relays
around NAT (TURN) RFC5766, an extension to STUN.  Because ICE
exchanges a multiplicity of IP addresses and ports for each media
stream, it also allows for address selection for multihomed and dual-
stack hosts.  For this reason RFC 5245 RFC5245 deprecated RFC 4091
RFC4091 and RFC 4092 RFC4092.
This specification defines Interactive Connectivity Establishment
(ICE) as a technique for NAT traversal for UDP-based data streams
(though ICE has been extended to handle other transport protocols,
such as TCP RFC6544).  ICE works by exchanging a multiplicity of IP
addresses and ports which are then tested for connectivity by peer-
to-peer connectivity checks.  The IP addresses and ports are
exchanged using ICE usage-specific mechanisms (for example, including
in a offer/answer exchange) and the connectivity checks are performed
using STUN RFC5389.  ICE also makes use of Traversal Using Relays
around NAT (TURN) RFC5766, an extension to STUN.  Because ICE
exchanges a multiplicity of IP addresses and ports for each media
stream, it also allows for address selection for multihomed and dual-
stack hosts.  For this reason, RFC 5245 RFC5245 deprecated the
solutions previously defined in RFC 4091 RFC4091 and RFC 4092
RFC4092.
fig-ice-ref-arch shows a typical ICE deployment.  The agents are
labelled L and R.  Both L and R are behind their own respective NATs
though they may not be aware of it.  The type of NAT and its
properties are also unknown.  L and R are capable of engaging in an
candidate exchange process, whose purpose is to set up a data session
between L and R.  Typically, this exchange will occur through a
signaling server (e.g., SIP proxy).
In addition to the agents, a signaling server and NATs, ICE is
typically used in concert with STUN or TURN servers in the network.
Each agent can have its own STUN or TURN server, or they can be the
same.
fig-ice-ref-arch shows a typical ICE deployment.  The agents are
labelled L and R.  Both L and R are behind their own respective NATs
though they may not be aware of it.  The type of NAT and its
properties are also unknown.  L and R are capable of engaging in a
candidate exchange process, whose purpose is to set up a data session
between L and R.  Typically, this exchange will occur through a
signaling server (e.g., SIP proxy).
In addition to the agents, a signaling server, and NATs, ICE is
typically used in concert with STUN or TURN servers in the network.
Each agent can have its own STUN or TURN server, or they can be the
same.
At least one viable candidate has a transport address obtained
directly from a local interface.  Such a candidate is called a host
candidate.  The local interface could be Ethernet or WiFi, or it
could be one that is obtained through a tunnel mechanism, such as a
Virtual Private Network (VPN) or Mobile IP (MIP).  In all cases, such
a network interface appears to the agent as a local interface from
which ports (and thus candidates) can be allocated.
The first category of candidates are those with a transport address
obtained directly from a local interface.  Such a candidate is called
a host candidate.  The local interface could be Ethernet or WiFi, or
it could be one that is obtained through a tunnel mechanism, such as
a Virtual Private Network (VPN) or Mobile IP (MIP).  In all cases,
such a network interface appears to the agent as a local interface
from which ports (and thus candidates) can be allocated.
When the agent sends the TURN Allocate request from IP address and
port X:x, the NAT (assuming there is one) will create a binding
X1':x1', mapping this server reflexive candidate to the host
candidate X:x.  Outgoing packets sent from the host candidate will be
translated by the NAT to the server reflexive candidate.  Incoming
packets sent to the server reflexive candidate will be translated by
the NAT to the host candidate and forwarded to the agent.  The host
candidate associated with a given server reflexive candidate is the
BASE.
When the agent sends a TURN Allocate request from IP address and port
X:x, the NAT (assuming there is one) will create a binding X1':x1',
mapping this server reflexive candidate to the host candidate X:x.
Outgoing packets sent from the host candidate will be translated by
the NAT to the server reflexive candidate.  Incoming packets sent to
the server reflexive candidate will be translated by the NAT to the
host candidate and forwarded to the agent.  The host candidate
associated with a given server reflexive candidate is the BASE.
The agent works through the check list by sending a STUN request for
the next candidate pair on the list periodically.  These are called
ordinary checks.  When a STUN transaction succeeds, one or more
candidate pairs will become so called valid pairs, and will be added
to a candidate pair list called the valid list.
As an optimization, as soon as R gets L's check message, R schedules
a connectivity check message to be sent to L on the same candidate
pair.  This is called a triggered check, and accelerates the process
of finding valid pairs.
The agent works through the check list by sending a STUN request for
the next candidate pair on the list periodically.  These are called
"ordinary checks".  When a STUN transaction succeeds, one or more
candidate pairs will become so called valid pairs, and will be added
to a candidate pair list called the valid list.
As an optimization, as soon as R gets L's check message, R schedules
a connectivity check message to be sent to L on the same candidate
pair.  This is called a "triggered check", and accelerates the
process of finding valid pairs.
Once ICE is concluded, it can be restarted at any time for one or all
of the data streams by either ICE agent.  This is done by sending an
updated candidate information indicating a restart.
Once ICE is concluded, it can be restarted at any time for one or all
of the data streams by either ICE agent.  This is done by sending
updated candidate information indicating a restart.
This document specifies generic use of ICE with protocols that
provide means to exchange candidate information between the ICE
agents.  The specific details of (i.e how to encode candidate
information and the actual candidate exchange process) for different
protocols using ICE (referred to as using protocol) are described in
separate usage documents.
This document specifies generic use of ICE with protocols that
provide means to exchange candidate information between the ICE
agents.  The specific details (i.e., how to encode candidate
information and the actual candidate exchange process) for different
protocols using ICE (referred to as "using protocol") are described
in separate usage documents.
A receiving agent is an ICE agent that receives and responds to
the candidate exchange process initiated by the initiating agent.
A responding agent is an ICE agent that receives and responds to
the candidate exchange process initiated by the initiating agent.
A component is a piece of a data stream.  A data stream may
require multiple components, each of which has to work in order
for the data stream as a whole to work.  For RTP/RTCP data
streams, unless RTP and RTCP are multiplexed in the same port,
there are two components per data stream -- one for RTP, and one
for RTCP.  A component has a candidate pair, which cannot be used
by other components.
A transport address related to a candidate, useful for diagnostics
and other purposes.  If a candidate is server or peer reflexive,
the related address and port is equal to the base for that server
or peer reflexive candidate.  If the candidate is relayed, the
related address and port is equal to the mapped address in the
Allocate response that provided the client with that relayed
candidate.  If the candidate is a host candidate, the related
address and port is identical to the host candidate.
The process of the controlling agent indicating to the controlled
agent which candidate pair the ICE agents will use for sending and
receiving data.
The process of the controlling agent indicating to the controlled
agent which candidate pair the ICE agents will use for sending and
receiving data.  The nomination process defined in this
specification was referred to "regular nomination" in RFC 5245.
The nomination process that was referred to "aggressive
nomination" in RFC 5245 has been deprecated in this specification.
As part of ICE processing, both the initiating and responding agents
exchange encoded candidate information as defined by the Usage
Protocol (ICE Usage).  Specifics of the encoding mechanism and the
semantics of candidate information exchange is out of scope of this
specification.
However at a higher level, the diagram below shows how the ICE agents
(initiator and responder) exchange their respective candidate(s)
information.
As shown, the agents involved in the candidate exchange perform (1)
candidate gathering, (2) candidate prioritization, (3) redundant
candidate elimination, and (4) sending of the candidates to the peer.
NOTE: When STUN and TURN are used with ICE, timer HTO is used instead
of timer Ti RFC3264 as transaction timeout timer.
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 Usage
Protocol (ICE Usage).  Specifics of the candidate encoding mechanism
and the semantics of candidate information exchange is out of scope
of this specification.
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.
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.
For other than RTP/RTCP streams, use of multiple components is
discouraged since using them 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.
For uses other than RTP/RTCP streams, use of multiple components is
discouraged, since using them 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.
Host candidates corresponding to IPv6 link-local addresses MUST
NOT be gathered.
If one or more host candidates corresponding to an IPv6 address
generated using a mechanism that prevents location tracking
RFC7721 are gathered, host candidates corresponding to IPv6
addresses that do allow location tracking that are configured on
the same interface and are part of the same network prefix MUST
NOT be gathered; and host candidates corresponding to IPv6 link-
local addresses RFC4291 MUST NOT be gathered.
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 either be 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 one
every time Ta expires.  See sec-ta for guidance on how to set Ta and
the STUN retransmit timer, RTO.
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 either be 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 one
every time Ta expires.  See sec-ta for guidance on how to set Ta and
the STUN retransmit timer, RTO.
For reflexive and relayed candidates, the STUN or TURN servers
used to obtain them have the same IP address.
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, or
their transport protocols are different.
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).
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.
If a host is v4-only, it SHOULD set the IP precedence to 65535.  If a
host is v6 or dual-stack, the IP precedence SHOULD be 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, and therefore that
candidate is the default.  If a host is IPv6 or dual-stack, the
selection of default is a matter of local policy.  This default
SHOULD be chosen such that it is the candidate most likely to be used
with a peer.  For IPv6-only hosts, this would typically be a globally
scoped IPv6 address.  For dual-stack hosts, the IPv4 address is
RECOMMENDED.
Each candidate is assigned a foundation.  The foundation MUST be
different for two candidates allocated from different IP addresses,
and MUST be the same otherwise.  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 sec-rec-form is used to calculate the
priority, the type preference value SHOULD be set to 126.  If a host
is v4-only, the local preference value SHOULD be set to 65535.  If a
host is v6 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, and 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 of 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 using protocol may (or may not) need to deal with backwards
compatibility with older implementations that do not support ICE.  If
the fallback mechanism 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.
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 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.
Certain middleboxes, such as ALGs, can alter signaling information in
ways that break ICE.  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.
Certain middleboxes, such as ALGs, can alter signaling information in
ways that break ICE break ICE (for example, 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.
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.  For a full agent, this
means nominating the candidate pairs that can be used by ICE for each
data stream, and for updating the peer with the ICE's selection, when
needed.  The controlled agent is told which candidate pairs to use
for each data stream, and does not require updating the peer to
signal this information.  The sections below describe in detail the
actual procedures followed by controlling and controlled nodes.
The initiating agent which started the ICE processing MUST take
the controlling role, and the other MUST take the controlled role.
Both agents will form check lists, run the ICE state machines, and
generate connectivity checks.  The controlling agent will execute
the logic in sec-conclude-full 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 sec-conc-state.
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.
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 check lists, run the ICE state machines, and
generate connectivity checks.  The controlling agent will execute
the logic in sec-conclude-full 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 sec-conc-state.
The initiating agent which 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 sec-conclude 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.
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 sec-conclude 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.
NOTE: There are certain 3PCC (third party call control) scenarios
where an ICE restart might cause a role conflict.
NOTE: There are certain 3PCC (third party call control) RFC3725
scenarios where an ICE restart might cause a role conflict.
There is one check list for each data stream.  To form a check list,
initiating and responding ICE agents form candidate pairs, computes
pair priorities, orders pairs by priority, prunes pairs, removes
lower-priority pairs, and sets check list states.  If candidates are
added to a check list (e.g, due to detection of peer reflexive
candidates), the agent will re-perform these steps for the updated
check list.
There is one check list for each data stream.  To form a check list,
initiating and responding ICE agents form candidate pairs, compute
pair priorities, order pairs by priority, prune pairs, remove lower-
priority pairs, and set check list states.  If candidates are added
to a check list (e.g., due to detection of peer reflexive
candidates), the agent will re-perform these steps for the updated
check list.
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 RFC4291 MUST NOT be paired with other
than link-local addresses.
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 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, where G>D?1:0
is an expression whose value is 1 if G is greater than D, and 0
otherwise.
The table in fig-state-initial illustrates an example.
The table below illustrates an example.
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 check list set have been set, a check is
performed for a candidate pair within the first check list in the
Running state, following the procedures in sec-connectivity_check.
After that, whenever Ta fires the next check list in the Running
state in the check list set is picked, and a check is performed for a
candidate within that check list.  After the last check list in the
Running state in the check list set has been processed, the first
check list is picked again.  Etc.
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 check list set have been set, a check is
performed for a candidate pair within the first check list in the
Running state, following the procedures in sec-connectivity_check.
After that, whenever Ta fires the next check list in the Running
state in the check list set is picked, and a check is performed for a
candidate within that check list.  After the last check list in the
Running state in the check list set has been processed, the first
check list is picked again, etc.
Once the agent has picked a candidate pair, for which a connectivity
check is to be performed, the agent performs the check by sending a
STUN request from the base associated with the local candidate of the
pair to the remote candidate of the pair, as described in sec-send-
check.
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 sec-
send-check.
The Initiator performs the ordinary checks on receiving the candidate
information from the Peer (responder) and having formed the check
lists.  On the other hand the responding agent either performs the
triggered or ordinary checks as described above.
Lite implementations skips most of the steps in sec-candidate_proc
except for verifying the peer's ICE support and determining its role
in the ICE processing.
Lite implementations skip most of the steps in sec-candidate_proc
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 updating the peer
with the new candidate information reflecting that selection, when
needed (it is never needed for an IPv4-only host).  The controlled
agent is told which candidate pairs to use for each data stream, and
no further candidate updates are needed to signal this information.
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 updating the peer
with the new candidate information reflecting that selection, if
needed (it is never needed for an IPv4-only host).
If the agent is using Diffserv Codepoint markings RFC2475 in data
packets that it will send, the agent SHOULD apply the same markings
to Binding responses that it will send.
If the agent is using Diffserv Codepoint markings RFC2475 in data
packets that it will send, the agent SHOULD apply the same markings
to Binding requests and responses that it will send.
Once the agent has switched its role, the agent MUST add the
candidate pair whose check generated the 487 error response to the
triggered check queue associated with the check list to which the
pair belongs, and set the candidate pair state to Waiting.  When the
triggered connectivity check is later performed, the ICE-CONTROLLING/
ICE-CONTROLLED attribute of the Binding request will indicate the
agent's new role.  The agent MAY change the tie-breaker value.
Once the agent has switched its role, the agent MUST add the
candidate pair whose check generated the 487 error response to the
triggered check queue associated with the check list to which the
pair belongs, and set the candidate pair state to Waiting.  When the
triggered connectivity check is later performed, the ICE-CONTROLLING/
ICE-CONTROLLED attribute of the Binding request will indicate the
agent's new role.  The agent MUST change the tie-breaker value.
An ICE agent MAY support processing of ICMP errors for connectivity
checks.  If the agent supports processing of ICMP errors, and if a
Binging request generates a hard ICMP error, the agent SHOULD set the
state of the candidate pair to Failed.  Implementers need to be aware
that ICMP errors can be used as a method for denial of service
attacks when making a decision on how and if to process ICMP errors.
An ICE agent MAY support processing of ICMP errors for connectivity
checks.  If the agent supports processing of ICMP errors, and if a
Binding request generates a hard ICMP error, the agent SHOULD set the
state of the candidate pair to Failed.  Implementers need to be aware
that ICMP errors can be used as a method for denial of service
attacks when making a decision on how and if to process ICMP errors.
The base is local candidate of the candidate pair from which the
Binding request was sent.
The base is the local candidate of the candidate pair from which
the Binding request was sent.
The valid pair may equal the pair that generated the connectivity
check, or it may equal a different pair in a check list (sometimes in
a different check list than the one to which the pair that generated
the connectivity checks), or it may be a pair not currently in any
check list.
The valid pair might equal the pair that generated the connectivity
check, a different pair in the check list, or a pair currently not in
the check list.
If neither ICE-CONTROLLING nor ICE-CONTROLLED is present in the
request, the peer agent may have implemented a previous version of
this specification.  There may be a conflict, but it cannot be
detected.
If the state of that pair is In-Progress, the agent cancels the
in-progress transaction.  Cancellation means that the agent
will not retransmit the request, will not treat the lack of
response to be a failure, but will wait the duration of the
transaction timeout for a response.  In addition, the agent
MUST create a new connectivity check for that pair
(representing a new STUN Binding request transaction) by
enqueueing the pair in the triggered check queue.  The state of
the pair is then changed to Waiting.
If the state of that pair is In-Progress or Succeeded, nothing
further is done.
If the state of that pair is Succeeded, nothing further is
done.
The criterion details for stopping the connectivity checks and for
selecting a pair for nomination, are outside the scope of this
specification.  They are a matter of local optimization.  The only
requirement is that the agent MUST eventually pick one and only one
candidate pair and generate a check for that pair with the USE-
CANDIDATE attribute set.
The criteria for stopping the connectivity checks and for selecting a
pair for nomination, are outside the scope of this specification.
They are a matter of local optimization.  The only requirement is
that the agent MUST eventually pick one and only one candidate pair
and generate a check for that pair with the USE-CANDIDATE attribute
set.
NOTE: A controlling agent that does not support this specification
(i.e. it is implemented according to RFC 5245) might nominate more
than one candidate pair.  This was referred to as aggressive
nomination in RFC 5245.  The usage of the 'ice2' ice option (sec-ice-
option) by endpoints supporting this specification is supposed to
prevent such controlling agents from using aggressive nomination.
NOTE: A controlling agent that does not support this specification
(i.e. it is implemented according to RFC 5245) might nominate more
than one candidate pair.  This was referred to as "aggressive
nomination" in RFC 5245.  The usage of the 'ice2' ice option (sec-
ice-option) by endpoints supporting this specification is supposed to
prevent such controlling agents from using aggressive nomination.
NOTE: In RFC 5245, usage of "aggressive nomination" allowed agents to
continuously nominate pairs, before a pair was eventually selected,
in order to allow sending of data on those pairs.  In this
specification, data can always be sent on any valid pair, without
nomination.  Hence, there is no longer a need for aggressive
nomination.
The agent MAY begin transmitting data for this data stream as
described in sec-send-media.
Once a check list has reached the Completed state, the agent SHOULD
wait an additional three seconds, and then it can cease responding to
checks or generating triggered checks on all local candidates other
than the ones that became selected candidates.  Once all ICE sessions
have ceased using a given local candidate (a candidate may be used by
multiple ICE sessions, e.g. in forking scenarios), the agent can free
that candidate.  The three-second delay handles cases when aggressive
nomination is used, and the selected pairs can quickly change after
ICE has completed.
Once a check list has reached the Completed state, the agent SHOULD
wait an additional three seconds, and then it can cease responding to
checks or generating triggered checks on all local candidates other
than the ones that became selected candidates.  Once all ICE sessions
have ceased using a given local candidate (a candidate may be used by
multiple ICE sessions, e.g., in forking scenarios), the agent can
free that candidate.  The three-second delay handles cases when
aggressive nomination is used, and the selected pairs can quickly
change after ICE has completed.
An ICE agent MAY restart ICE for existing data streams.  An ICE
restart causes all previous state of the data streams, excluding the
roles of the agents to be flushed.  The only difference between an
ICE restart and a brand new data session is that during the restart,
data can continue to be sent using existing data sessions, and that a
new data session always requires the roles to be determined.
An ICE agent MAY restart ICE for existing data streams.  An ICE
restart causes all previous state of the data streams, excluding the
roles of the agents, to be flushed.  The only difference between an
ICE restart and a brand new data session is that during the restart,
data can continue to be sent using existing data sessions, and that a
new data session always requires the roles to be determined.
To restart ICE, an agent MUST change both the password and the
username fragment for the data stream(s) being restarted.  The agent
MUST verify that it has not used the new values in recent ICE
sessions, as packets from those sessions might still be present in
the network.
To restart ICE, an agent MUST change both the password and the
username fragment for the data stream(s) being restarted.
This section defines a new ICE option, 'ice2'.  The ICE option
indicates that the ICE agent that includes it in a candidate exchange
is compliant to this specification.  For example, the agent will not
use the aggressive nomination procedure defined in RFC 5245.
This section defines a new ICE option, 'ice2'.  The ICE option
indicates that the ICE agent that includes it in a candidate exchange
is compliant to this specification.  For example, the agent will not
use the aggressive nomination procedure defined in RFC 5245.  In
addition, it will ensure that an RFC 5245-compliant peer does not use
aggressive nomination either, as required by Section 14 of RFC 5245
for peers which receive unknown ICE options.
Once selected pairs have been produced for a data stream, an agent
MUST send data on those pairs.
Once selected pairs have been produced for a data stream, an agent
MUST send data on those pairs only.
Even though ICE agents are only allowed to send data using valid
candidate pairs (and, once selected pairs have been produced, only on
the selected pairs) ICE implementations SHOULD by default be prepared
to receive data on any of the candidates provided in the most recent
candidate exchange with the peer.  ICE usages MAY define rules that
differs from this, e.g., by defining that data will not be sent until
selected pairs have been produced for a data stream.
Even though ICE agents are only allowed to send data using valid
candidate pairs (and, once selected pairs have been produced, only on
the selected pairs) ICE implementations SHOULD by default be prepared
to receive data on any of the candidates provided in the most recent
candidate exchange with the peer.  ICE usages MAY define rules that
differ from this, e.g., by defining that data will not be sent until
selected pairs have been produced for a data stream.
First, ICE provides the ice-options attribute.  Each extension or
change to ICE is associated with a token.  When an agent supporting
such an extension or change triggers candidate exchange, it MUST
include the token for that extension in this attribute.  This allows
each side to know what the other side is doing.  This attribute MUST
NOT be present if the agent doesn't support any ICE extensions or
changes.
One of the complications in achieving interoperability is that ICE
relies on a distributed algorithm running on both agents to converge
on an agreed set of candidate pairs.  If the two agents run different
algorithms, it can be difficult to guarantee convergence on the same
candidate pairs.  The regular nomination procedure described in sec-
conclude eliminates some of the tight coordination by delegating the
selection algorithm completely to the controlling agent.
Consequently, when a controlling agent is communicating with a peer
that supports options it doesn't know about, the agent MUST run a
regular nomination algorithm.  When regular nomination is used, ICE
will converge perfectly even when both agents use different pair
prioritization algorithms.  One of the keys to such convergence is
triggered checks, which ensure that the nominated pair is validated
by both agents.  Consequently, any future ICE enhancements MUST
preserve triggered checks.
First, ICE provides the ICE option concept.  Each extension or change
to ICE is associated with an ICE option.  When an agent supports such
an extension or change, it provides the ICE option to the peer agent
as part of the candidate exchange.
One of the complications in achieving interoperability is that ICE
relies on a distributed algorithm running on both agents to converge
on an agreed set of candidate pairs.  If the two agents run different
algorithms, it can be difficult to guarantee convergence on the same
candidate pairs.  The nomination procedure described in sec-conclude
eliminates some of the need for tight coordination by delegating the
selection algorithm completely to the controlling agent, and ICE will
converge perfectly even when both agents use different pair
prioritization algorithms.  One of the keys to such convergence is
triggered checks, which ensure that the nominated pair is validated
by both agents.
ICE agents SHOULD use the default Ta value, 50 ms, but MAY use
another value based on the characteristics of the associated data.
ICE agents SHOULD use a default Ta value, 50 ms, but MAY use another
value based on the characteristics of the associated data.
Let MaxBytes be the maximum number of bytes allowed to be
outstanding in the network at start-up, which SHOULD be 14600
bytes per RFC 6928.
Let HTO be the transaction timeout, which SHOULD be 2*RTT if
RTT is known and 500ms otherwise.  This is based on the RTO for
STUN messages from RFC 5389 and the the TCP initial RTO, which
is 1 sec in RFC 6298.
Let MinPacing be the minimum pacing interval between
transactions, which SHOULD be 5ms.
Let MaxBytes be the maximum number of bytes allowed to be
outstanding in the network at start-up, which SHOULD be 14600,
as defined in Section 2 of RFC6928.
Let HTO be the transaction timeout, which SHOULD be 2*RTT if
RTT is known and 500ms otherwise.  This is based on the RTO for
STUN messages from RFC5389 and the the TCP initial RTO, which
is 1 sec in RFC6298.
Let MinPacing be the minimum pacing interval between
transactions, which is 5ms (see above).
The example is based on the simplified topology of fig-ex-topo.
Two ICE agents, L and R, are using ICE.  Both are full ICE
implementations.  Both agents have a single IPv4 address.  For agent
L, it is 10.0.1.1 in private address space RFC1918, and for agent R,
192.0.2.1 on the public Internet.  Both are configured with the same
STUN server (shown in this example for simplicity, although in
practice the agents do not need to use the same STUN server), which
is listening for STUN Binding requests at an IP address of 192.0.2.2
and port 3478.  TURN servers are not used in this example.  Agent L
is behind a NAT, and agent R is on the public Internet.  The NAT has
an endpoint independent mapping property and an address dependent
filtering property.  The public side of the NAT has an IP address of
192.0.2.3.
This section shows two ICE examples: one using IPv4 addresses, and
one using IPv6 addresses.
The STUN server has advertised transport address STUN-PUB-1 (which is
192.0.2.2:3478).
First, agent L obtains a host candidate from its local IP address
(not shown), and from that, sends a STUN Binding request to the STUN
server to get a server reflexive candidate (messages 1-4).  Recall
that the NAT has the address and port independent mapping property.
Here, it creates a binding of NAT-PUB-1 for this UDP request, and
this becomes the server reflexive candidate.
Agent L sets a type preference of 126 for the host candidate and 100
for the server reflexive.  The local preference is 65535.  Based on
this, the priority of the host candidate is 2130706431 and for the
server reflexive candidate is 1694498815.  The host candidate is
assigned a foundation of 1, and the server reflexive, a foundation of
2.  These are sent to the peer.
This candidate information is received at agent R.  Agent R will
obtain a host candidate, and from it, obtain a server reflexive
candidate (messages 6-7).  Since R is not behind a NAT, this
candidate is identical to its host candidate, and they share the same
base.  It therefore discards this redundant candidate and ends up
with a single host candidate.  With identical type and local
preferences as L, the priority for this candidate is 2130706431.  It
chooses a foundation of 1 for its single candidate.  Then R's
candidates are then sent to L.
Since neither side indicated that it is lite, the initiating agent
that began ICE processing (agent L) becomes the controlling agent.
Agents L and R both pair up the candidates.  They both initially have
two pairs.  However, agent L will prune the pair containing its
server reflexive candidate, resulting in just one.  At agent L, this
pair has a local candidate of $L_PRIV_1 and remote candidate of
$R_PUB_1, and has a candidate pair priority of 9151314442783293438.
At agent R, there are two pairs.  The highest priority has a local
candidate of $R_PUB_1 and remote candidate of $L_PRIV_1 and has a
priority of 9151314442783293438, and the second has a local candidate
of $R_PUB_1 and remote candidate of $NAT_PUB_1 and priority
7277816997797167102.
Agent R begins its connectivity check (message 9) for the first pair
(between the two host candidates).  Since R is the controlled agent
for this session, the check omits the USE-CANDIDATE attribute.  The
host candidate from agent L is private and behind a NAT, and thus
this check won't be successful, because the packet cannot be routed
from R to L.
When agent L gets the R's candidates, it performs its one and only
connectivity check (messages 10-13).  Since the check succeeds, agent
L creates a new pair, whose local candidate is from the mapped
address in the Binding response (NAT-PUB-1 from message 13) and whose
remote candidate is the destination of the request (R-PUB-1 from
message 10).  This is added to the valid list.  Agent L can now send
data if it so chooses.
Soon after receipt of the STUN Binding request from agent L (message
11), agent R will generate its triggered check.  This check happens
to match the next one on its check list -- from its host candidate to
agent L's server reflexive candidate.  This check (messages 14-17)
will succeed.  Consequently, agent R constructs a new candidate pair
using the mapped address from the response as the local candidate (R-
PUB-1) and the destination of the request (NAT-PUB-1) as the remote
candidate.  This pair is added to the valid list for that data
stream.  Since the check was generated in the reverse direction of a
check that contained the USE-CANDIDATE attribute, the candidate pair
is marked as selected.  Consequently, processing for this stream
moves into the Completed state, and agent R can also send data.
This specification defines four new STUN attributes, PRIORITY, USE-
CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
The example is using the topology shown in fig-ex-topo-ipv4.
Messages 1-4: Agent L gathers a host candidate from its local IP
address, and from that sends a STUN Binding request to the STUN
Server.  The request creates a NAT binding.  The NAT public IP
address of the binding becomes agent L's server reflexive candidate.
Message 5: Agent L sends its local candidate information to agent R,
using the signalling protocol associated with the ICE usage.
Messages 6-7: Agent R gathers a host candidate from its local IP
address, and from that sends a STUN Binding request to the STUN
Server.  Since agent R is not behind a NAT, R's server reflexive
candidate will be identical to the host candidate.
Message 8: Agent R sends its local candidate information to agent L,
using the signalling protocol associated with the ICE usage.
Message 9: Agent R initiates a connectivity check for pair #2.  As
the remote candidate of the pair is the private address of agent L,
the check will not be successful, as the request cannot be routed
from R to L, and will be dropped by the network.
Messages 10-13: Agent L initiates a connectivity check for pair L1.
The check succeeds, and L creates a new pair (L2).  The local
candidate of the new pair is $NAT_PUB_1 and the remote candidate is
$R_PUB_1.  The pair (L2) is added to the valid list of agent L.
Agent L can now send and receive data on the pair (L2) if it wishes.
Messages 14-17: When agent R receives the Binding request from agent
L (message 11) it will initiate a triggered connectivity check.  The
pair matches one of agent R's existing pairs (R2).  The check
succeeds, and the pair (R2) is added to the valid list of agent R.
Agent R can now send and receive data on the pair (R2) if it wishes.
Messages 18-21: At some point, the controlling agent (agent L)
decides to nominate a pair (L2) in the valid list.  It performs a
connectivity check on the pair (L2), and includes the USE-CANDIDATE
attribute in the Binding request.  As the check succeeds, agent L
sets the nominated flag value of the pair (L2) to 'true'.  Agent R
sets the nominated flag value of the matching pair (R2) to 'true'.
As there are no more components associated with the stream, the
nominated pairs become the selected pairs.  Consequently, processing
for this stream moves into the Completed state.  The ICE process also
moves into the Completed state.
The example is using the topology shown in fig-ex-topo-ipv6.
Messages 1-2: Agent L gathers a host candidate from its local IP
address, and from that sends a STUN Binding request to the STUN
Server.  Since agent L is not behind a NAT, L's server reflexive
candidate will be identical to the host candidate.
Message 3: Agent L sends its local candidate information to agent R,
using the signalling protocol associated with the ICE usage.
Messages 4-5: Agent R gathers a host candidate from its local IP
address, and from that sends a STUN Binding request to the STUN
Server.  Since agent R is not behind a NAT, R's server reflexive
candidate will be identical to the host candidate.
Message 6: Agent R sends its local candidate information to agent L,
using the signalling protocol associated with the ICE usage.
Messages 7-8: Agent L initiates a connectivity check for pair L1.
The check succeeds, and the pair (L1) is added to the valid list of
agent L.  Agent L can now send and receive data on the pair (L1) if
it wishes.
Messages 9-10: When agent R receives the Binding request from agent L
(message 7) it will initiate a triggered connectivity check.  The
pair matches agent R's existing pair (R1).  The check succeeds, and
the pair (R1) is added to the valid list of agent R.  Agent R can now
send and receive data on the pair (R1) if it wishes.
Messages 11-12: At some point, the controlling agent (agent L)
decides to nominate a pair (L1) in the valid list.  It performs a
connectivity check on the pair (L1), and includes the USE-CANDIDATE
attribute in the Binding request.  As the check succeeds, agent L
sets the nominated flag value of the pair (L1) to 'true'.  Agent R
sets the nominated flag value of the matching pair (R1) to 'true'.
As there are no more components associated with the stream, the
nominated pairs become the selected pairs.  Consequently, processing
for this stream moves into the Completed state.  The ICE process also
moves into the Completed state.
This specification defines four STUN attributes: PRIORITY, USE-
CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
The ICE-CONTROLLED attribute is present in a Binding request.  The
attribute indicates that the client believes it is currently in the
controlled role.  The content of the attribute is a 64-bit unsigned
integer in network byte order, which contains a random number.  The
number is used for solving role conflicts, when it is referred to as
the tie-breaker value.  An ICE agent MUST use the same number for all
Binding requests, for all streams, within an ICE session.  The agent
MAY change the number when an ICE restart occurs.
The ICE-CONTROLLED attribute is present in a Binding request.  The
attribute indicates that the client believes it is currently in the
controlled role.  The content of the attribute is a 64-bit unsigned
integer in network byte order, which contains a random number.  The
number is used for solving role conflicts, when it is referred to as
the tie-breaker value.  An ICE agent MUST use the same number for all
Binding requests, for all streams, within an ICE session, unless it
has received a 487 response, in which case it MUST change the number
(sec-recv-response-conf).  The agent MAY change the number when an
ICE restart occurs.
The ICE-CONTROLLING attribute is present in a Binding request.  The
attribute indicates that the client believes it is currently in the
controlling role.  The content of the attribute is a 64-bit unsigned
integer in network byte order, which contains a random number.  As
for the ICE-CONTROLLED attribute, the number is used for solving role
conflicts.  An agent MUST use the same number for all Binding
requests, for all streams, within an ICE session.  The agent MAY
change the number when an ICE restart occurs.
The ICE-CONTROLLING attribute is present in a Binding request.  The
attribute indicates that the client believes it is currently in the
controlling role.  The content of the attribute is a 64-bit unsigned
integer in network byte order, which contains a random number.  As
for the ICE-CONTROLLED attribute, the number is used for solving role
conflicts.  An agent MUST use the same number for all Binding
requests, for all streams, within an ICE session, unless it has
received a 487 response, in which case it MUST change the number
(sec-recv-response-conf).  The agent MAY change the number when an
ICE restart occurs.
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 NAT.
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.
First and foremost, ICE makes use of TURN and STUN servers, which
would typically be located in the 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 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).
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
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
NAT, it is exactly zero.  At time of writing, large-scale consumer
deployments were seeing between 5 and 10 percent of calls requiring
TURN servers.  Considering a voice-only deployment using G.711 (so 80
kbps in each direction), with .2 erlangs during the busy hour, this
is N*3.2 kbps.  For a population of one million users, this is 3.2
Gbps, assuming a 10% usage of TURN servers.
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 multi-
media scenarios (e.g., audio and video conferences), and when the
numbers of participants in a session grow.
Deployments utilizing a mix of ICE and ICE-lite interoperate
perfectly.  They have been explicitly designed to do so.
Deployments utilizing a mix of ICE and ICE-lite interoperate with
each other.  They have been explicitly designed to do so.
ICE has built-in features to help deal with these problems.
Signaling servers, typically deployed in the 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.
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.
The IAB has studied the problem of "Unilateral Self-Address Fixing",
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
IAB.  Indeed, ICE can be considered a B-SAF (Bilateral Self-Address
Fixing) 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
requirements.
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 B-SAF (Bilateral Self-
Address Fixing) 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
requirements.
less, and can eventually be remove when their usage goes to zero.
less, and can eventually be removed when their usage goes to zero.
needs to be validated.  The IP destination and UDP destination port
needs to match either the targeted candidate address and port, or the
candidates 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.  Thus the
validation is a weak defence, and the sending of spoofed ICMP attacks
is possible also for off-path attackers from a node in a network
without source address validation.
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.  Thus the
validation is a weak defence, and the sending of spoofed ICMP attacks
is possible also for off-path attackers from a node in a network
without source address validation.
However, TURN servers are susceptible to DNS attacks for purposes of
turning it into a zombie or rogue server.  These attacks can be
mitigated by DNS-SEC and through good box and software security on
TURN servers.
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 an 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.  The answerer will start a new connectivity
check every Ta ms (say, Ta=20ms).  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.
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 an 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.  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.
The original ICE specification registered four new STUN attributes,
and one new STUN error response.  The STUN attributes and error
response are reproduced here.  In addition, this specification
registers a new ICE option.
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
ICE option.
Make technical changes, due to discovered flows in RFC 5245 and
based on feedback from the community that has implemented and
deployed ICE applications based on RFC 5245.
Make technical changes, due to discovered flaws in RFC 5245 and
based on feedback from the community that has implemented and
deployed ICE applications based on RFC 5245.