Draft: draft-ietf-ice-rfc5245bis

Commentary: Section 7.3.1.4 says : " If the state of the pair is Failed , it is changed to Waiting and the agent  create a new connectivity check for that pair ( representing a new STUN Binding request transaction ) , by enqueueing the pair in the triggered check queue . " Does n't this mean that the state of the check list may change ? Assume it was previously set to Failed , but as the state of the pair now changes , it may impact the check list state . 
 I have a sentence to the text , clarifying that a change of the pair state might also trigger a change of the check list state : " If the state of the pair is Failed , it is changed to Waiting and the agent  create a new connectivity check for that pair ( representing a new STUN Binding request transaction ) , by enqueueing the pair in the triggered check queue . Note that the change of the state pair might also trigger a change of the check list state , if the current check list state is Failed . " 
 Section 7.2.1.5 of RFC 5245 says : " If the state of this pair is Succeeded , it means that the check generated by this pair produced a successful response . This would have caused the agent to construct a valid pair when that success response was received ( see Section 7.1.3.2.2 ) . The agent now sets the nominated flag in the valid pair to true . " In section 7.3.1.5 of 5245bis-16 , the last sentence only says : " The agent sets the nominated flag value of the pair to true . " ISSUE : It could be misunderstood which pair the text refers to . SUGGESTION : s / pair / valid pair 
 Has been fixed in :
sec-designmotivations provides background information and motivations
regarding the design decisions that were made when designing ICE.
In order to execute ICE, an ICE agent has to identify all of its
address candidates.  A candidate has a transport address -- a
combination of IP address and port for a particular transport
protocol (with only UDP specified here).  There are different types
of candidates, some derived from physical or logical network
interfaces, others discoverable via STUN and TURN.  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.
In order to execute ICE, an ICE agent identifies and gathers one or
more address candidates.  A candidate has a transport address -- a
combination of IP address and port for a particular transport
protocol (with only UDP specified here).  There are different types
of candidates, some derived from physical or logical network
interfaces, others discoverable via STUN and TURN.
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.
RFC7825 defines an ICE usage for the Real-Time Streaming Protocol
(RTSP).  Note, however, that the ICE usage is based on RFC 5245.
The timer for generating new STUN or TURN transactions.
The retransmission timer for a given STUN or TURN transaction.
The timeout timer for a given STUN or TURN transaction.
Host candidates do not time out, but the candidate addresses may
change or disappear for a number of reasons.  An ICE agent SHOULD
monitor the interfaces it uses, invalidate candidates whose base has
gone away, and acquire new candidates as appropriate when new
interfaces appear.
Host candidates do not time out, but the candidate addresses may
change or disappear for a number of reasons.  An ICE agent SHOULD
monitor the interfaces it uses, invalidate candidates whose base has
gone away, and acquire new candidates as appropriate when new IP
addresses (on new or currently used interfaces) appear.
The prioritization process results in the assignment of a priority to
each candidate.  Each candidate for a data stream MUST have a unique
priority that MUST be a positive integer between 1 and (2**31 - 1).
This priority will be used by ICE to determine the order of the
connectivity checks and the relative preference for candidates.
The prioritization process results in the assignment of a priority to
each candidate.  Each candidate for a data stream MUST have a unique
priority that MUST be a positive integer between 1 and (2**31 - 1).
This priority will be used by ICE to determine the order of the
connectivity checks and the relative preference for candidates.
Higher priority values give more priority over lower values.
Lite implementations only utilize host candidates.  A lite
implementation MUST, for each component of each data stream, allocate
zero or one IPv4 candidates.  It MAY allocate zero or more IPv6
candidates, but no more than one per each IPv6 address utilized by
the host.  Since there can be no more than one IPv4 candidate per
component of each data stream, if an ICE agent has multiple IPv4
addresses, it MUST choose one for allocating the candidate.  If a
host is dual-stack, it is RECOMMENDED that it allocate one IPv4
candidate and one global IPv6 address.  With the lite implementation,
ICE cannot be used to dynamically choose amongst candidates.
Therefore, including more than one candidate from a particular scope
is NOT RECOMMENDED, since only a connectivity check can truly
determine whether to use one address or the other.
Lite implementations only utilize host candidates.  For each IP
address, independent of IP address family, there MUST be zero or one
candidate.  With the lite implementation, ICE cannot be used to
dynamically choose amongst candidates.  Therefore, including more
than one candidate from a particular IP address family is NOT
RECOMMENDED, since only a connectivity check can truly determine
whether to use one address or the other.  Instead agents that have
multiple public IP addresses are RECOMMENDED to run full ICE
implementations to ensure the best usage of its addresses.
The procedures in this section is common across the initiating and
responding agents.
The procedures in this section are common across the initiating and
responding agents.
Values used to perform connectivity checks.  The username fragment
MUST contain at least 24 bits of randomness, and the password MUST
contain at least 128 bits of randomness.
Values used to perform connectivity checks.  The values MUST be
unguessable, with at least 128 bits of random number generator
output used to generate the password, and at least 24 bits output
to generate the username fragment.
NOTE: There are certain 3PCC scenarios where an ICE restart might
cause a role conflict.
An agent MUST be prepared that the peer might re-determine the roles
as part of any ICE restart, even if the criteria for doing so are not
fulfilled.  This can happen if the peer is compliant with an older
version of this specification.
NOTE: There are certain 3PCC (third party call control) scenarios
where an ICE restart might cause a role conflict.
An agent MUST accept if the peer initiates a re-determination of the
roles even if the criteria for doing so are not fulfilled.  This can
happen if the peer is compliant with RFC 5245.
The controlling agent MUST include the USE-CANDIDATE attribute in
order to nominate a candidate pair sec-choose-favor.  The controlled
agent MUST NOT include the USE-CANDIDATE attribute in a Binding
request.
The controlling agent MUST include the USE-CANDIDATE attribute in
order to nominate a candidate pair (sec-choose-favor).  The
controlled agent MUST NOT include the USE-CANDIDATE attribute in a
Binding request.
The content of either attribute are used as tie-breaker values when
an ICE role conflict occurs sec-role-conflict.
The content of either attribute are used as tie-breaker values when
an ICE role conflict occurs (sec-role-conflict).
If an ICE agent is using Diffserv Codepoint markings RFC2475 in its
data packets, the agent SHOULD apply those same markings to its
connectivity checks.
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 Binding request generates a 487 (Role Conflict) error
response, and if the ICE agent included an ICE-CONTROLLED attribute
in the request, the agent MUST switch to the controlling role.  If
the agent included an ICE-CONTROLLING attribute in the request, the
agent MUST switch to the controlled role.
If the Binding request generates a 487 (Role Conflict) error response
(sec-role-conflict), and if the ICE agent included an ICE-CONTROLLED
attribute in the request, the agent MUST switch to the controlling
role.  If the agent included an ICE-CONTROLLING attribute in the
request, the agent MUST switch to the controlled role.
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 an ICMP error, the agent SHOULD set the
state of the candidate pair to Failed.
If the Binding request times out, the ICE agent MUST set the
candidate pair state to Failed.
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.
If the Binding request transaction times out, the ICE agent MUST set
the candidate pair state to Failed.
If the controlling agent sends a Binding request with the USE-
CANDIDATE attribute set, and if the ICE agent receives a successful
response to the request, the agent sets the nominated flag of the
pair to true.  If the request fails sec-client-failure, the agent
MUST remove the candidate pair from the valid list, set the candidate
pair state to Failed and set the check list state to Failed.
If the controlled agent receives a successful response to a Binding
request sent by the agent, and that Binding request was triggered by
a received Binding request with the USE-CANDIDATE attribute set sec-
triggered, the agent sets the nominated flag of the pair to true.  If
the triggered request fails, the agent MUST remove the candidate pair
from the valid list, set the candidate pair state to Failed and set
the check list state to Failed.
Once the nominated flag is set for a component of a data stream, it
concludes the ICE processing for that component.  See sec-conclude.
If the controlling agent sends a Binding request with the USE-
CANDIDATE attribute set, and if the ICE agent receives a successful
response to the request, the agent sets the nominated flag of the
pair to true.  If the request fails (sec-client-failure), the agent
MUST remove the candidate pair from the valid list, set the candidate
pair state to Failed and set the check list state to Failed.
If the controlled agent receives a successful response to a Binding
request sent by the agent, and that Binding request was triggered by
a received Binding request with the USE-CANDIDATE attribute set (sec-
triggered), the agent sets the nominated flag of the pair to true.
If the triggered request fails, the agent MUST remove the candidate
pair from the valid list, set the candidate pair state to Failed and
set the check list state to Failed.
Once the nominated flag is set for a component of a data stream, it
concludes the ICE processing for that component (sec-conclude).
In certain usages of ICE (such as third party call control), both ICE
agents may end up choosing the same role, resulting in a role
conflict.  The section describes a mechanism for detecting and
repairing role conflicts.  The usage document MUST specify whether
this mechanism is needed.
In certain usages of ICE (such as 3PCC), both ICE agents may end up
choosing the same role, resulting in a role conflict.  The section
describes a mechanism for detecting and repairing role conflicts.
The usage document MUST specify whether this mechanism is needed.
If the state of the pair is Failed, it is changed to Waiting
and 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.
If the state of the pair is Failed, it is changed to Waiting
and 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.  Note that
the change of the state pair might also trigger a change of the
check list state, if the current check list state is Failed.
If the state of this pair is Succeeded, it means that the check
previously sent by this pair produced a successful response, and
generated a valid pair (sec-valid-cons).  The agent sets the
nominated flag value of the pair to true.
If the received Binding request triggered a new check to be enqued
in the triggered check queue (sec-triggered), once the check is
sent and if it generates a successful response, and generates a
valid pair, the agent sets the nominated flag of the pair to true.
If the request fails sec-client-failure, the agent MUST remove the
candidate pair from the valid list, set the candidate pair state
to Failed and set the check list state to Failed.
If the state of this pair is Succeeded, it means that the check
previously sent by this pair produced a successful response, and
generated a valid pair (sec-valid-cons).  The agent sets the
nominated flag value of the valid pair to true.
If the received Binding request triggered a new check to be enqued
in the triggered check queue (sec-triggered), once the check is
sent and if it generates a successful response, and generates a
valid pair, the agent sets the nominated flag of the pair to true.
If the request fails (sec-client-failure), the agent MUST remove
the candidate pair from the valid list, set the candidate pair
state to Failed and set the check list state to Failed.
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.
The procedures in sec-conclude require that an ICE agent continue to
listen for STUN requests and continue to generate triggered checks
for a data stream, even once processing for that stream completes.
The rules in this section describe when it is safe for an agent to
cease sending or receiving checks on a candidate that did not become
a selected candidate (is not associated with a selected pair), and
then free the candidate.
The rules in this section describe when it is safe for an agent to
cease sending or receiving checks on a candidate that did not become
a selected candidate (is not associated with a selected pair), and
then free the candidate.
To restart ICE, an agent MUST change both the password and the
username fragment for the data stream(s) being restarted.  The new
candidate set MAY include some, none, or all of the previous
candidates.
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.
When the ICE is restarted, the candidate set for the new ICE session
might include some, none, or all of the candidates used in the
current ICE session.
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 4.57566E+18 (note that
an implementation would represent this as a 64-bit integer so as not
to lose precision).  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 4.57566E+18, and the second has a
local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and
priority 3.63891E+18.
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.
The ICE-CONTROLLED attribute is present in a Binding request and
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-CONTROLLING attribute is present in a Binding request and
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.  The number is
used for solving role conflicts, when it is referred to as the tie-
breaker value.  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-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-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 Binding request contained either the ICE-CONTROLLING or ICE-
CONTROLLED attribute, indicating an ICE role that conflicted with
the server.  The server compared the tie-breaker values of the
client and the server and determined that the client needs to
switch roles.
This section discusses issues relevant to network operators looking
to deploy ICE.
The Binding request contained either the ICE-CONTROLLING or ICE-
CONTROLLED attribute, indicating an ICE role that conflicted with
the server.  The remote server compared the tie-breaker values of
the client and the server and determined that the client needs to
switch roles.
This section discusses issues relevant to operators operating
networks where ICE will be used by endpoints.
First and foremost, ICE makes use of TURN and STUN servers, which
would typically be located in the network operator's 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 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).
The process of gathering of candidates and performing of connectivity
checks can be bandwidth intensive.  ICE has been designed to pace
both of these processes.  The gathering phase and the connectivity
check phase are meant to generate traffic at roughly the same
bandwidth as the data traffic itself.  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.  Of course, the ICE
checks will cause a marginal increase in the total utilization;
however, this will typically be an extremely small increase.
The process of gathering of candidates and performing of connectivity
checks can be bandwidth intensive.  ICE has been designed to pace
both of these processes.  The gathering phase and the connectivity
check phase are meant to generate traffic at roughly the same
bandwidth as the data traffic itself will consume once the ICE
process conclude.  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
keep-alives will later cause a marginal increase in the total
bandwidth utilization; however, this will typically be an extremely
small increase.
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 that are not
utilizing Voice Activity Detection (VAD), the keepalives are never
used and there is no increase in bandwidth usage.  When VAD is being
used, 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
don't have any real impact on capacity planning.
Deployments utilizing a mix of ICE and ICE-lite interoperate
perfectly.  They have been explicitly designed to do so, without loss
of function.
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.
Deployments utilizing a mix of ICE and ICE-lite interoperate
perfectly.  They have been explicitly designed to do so.
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.  Local IPv6 addresses can be preferred.  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 remove when their usage goes to zero.
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.  IPv6 address from the local host can be
preferred.  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 remove when their usage goes to zero.
addresses are revealed.
There are several types of attacks possible in an ICE system.  This
section considers these attacks and their countermeasures.
addresses are revealed.  For example, I-D.ietf-rtcweb-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.  In 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.
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, and 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 defence.  For Type 3 code=4 the outer IP header provides no
validation, unless the connectivity check was sent with DF=0.  For
code 2 or 3, which are originated by the host, the address is
expected to be any of the remote agents host, reflexive, or relay
candidates IP addresses.  The ICMP message include the IP header and
UDP header of the message triggering the error.  These fields also
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.
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 DNS-SEC is not required to address it.
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.
he STUN amplification attack is similar to a "voice hammer" attack,
The STUN amplification attack is similar to a "voice hammer" attack,