Draft: draft-ietf-ice-rfc5245bis

Commentary: Reverts ice - wg / rfc5245bis
Once an agent has candidates from it's peer, it will check if the
peer supports ICE, determine its own role, exchanges candidates (sec-
gathering_exchange) and for full implementations, forms the check
lists and begins connectivity checks as explained in this section.
Once an agent has gathered its candidates and exchanged candidates
with its peer (sec-gathering_exchange), it will determine its own
role.  In addition, full implementations will form check lists, and
begin performing connectivity checks with the peer.
This section describes how connectivity checks are performed.  All
ICE implementations are required to be compliant to RFC5389, as
opposed to the older RFC3489.  However, whereas a full implementation
will both generate checks (acting as a STUN client) and receive them
(acting as a STUN server), a lite implementation will only receive
checks, and thus will only act as a STUN server.
These procedures define how an agent sends a connectivity check,
whether it is an ordinary or a triggered check.  These procedures are
only applicable to full implementations.
This section describes how connectivity checks are performed.
An ICE agent MUST be compliant to to RFC5389.  A full implementation
acts both as a STUN client and a STUN server, while a lite
implemenation only acts as a STUN server (as it does not generate
connectivity checks).
ICE extends STUN by defining new attributes: PRIORITY, USE-CANDIDATE,
ICE-CONTROLLED, and ICE-CONTROLLING.  The new attributes are formally
defined in sec-ice-newatts.  This section describes the usage of the
new attributes.
The new attributes are only applicable to ICE connectivity checks.
The attribute MUST be set equal to the priority that would be
assigned, based on the algorithm in sec-prioritizing, to a peer
reflexive candidate, should one be learned as a consequence of this
check (see sec-learn-peer-client for how peer reflexive candidates
are learned).  This priority value will be computed identically to
how the priority for the local candidate of the pair was computed,
except that the type preference is set to the value for peer
reflexive candidate types.
An ICE agent MUST include the PRIORITY attribute in a Binding
request.
The controlling ICE agent includes the USE-CANDIDATE attribute in
order to nominate a candidate pair sec-choose-favor.  The controlled
ICE agent MUST NOT include the USE-CANDIDATE attribute in a Binding
request.
The controlling ICE agent MUST include the ICE-CONTROLLED attribute
in a Binding request.  The controlled ICE agent MUST include the ICE-
CONTROLLING attribute in a Binding request.
A connectivity check is generated by sending a Binding request from a
local candidate to a remote candidate.  RFC5389 describes how Binding
requests are constructed and generated.  A connectivity check MUST
utilize the STUN short-term credential mechanism.  Support for
backwards compatibility with RFC 3489 MUST NOT be used or assumed
with connectivity checks.  The FINGERPRINT mechanism MUST be used for
connectivity checks.
ICE extends STUN by defining several new attributes, including
PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.  These
new attributes are formally defined in sec-ice-newatts, and their
usage is described in the subsections below.  These STUN extensions
are applicable only to connectivity checks used for ICE.
An agent MUST include the PRIORITY attribute in its Binding request.
The attribute MUST be set equal to the priority that would be
assigned, based on the algorithm in sec-prioritizing, to a peer
reflexive candidate, should one be learned as a consequence of this
check (see sec-learn-peer-client for how peer reflexive candidates
are learned).  This priority value will be computed identically to
how the priority for the local candidate of the pair was computed,
except that the type preference is set to the value for peer
reflexive candidate types.
The controlling agent includes 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 its Binding request.
The agent MUST include the ICE-CONTROLLED attribute in the request if
it is in the controlled role, and MUST include the ICE-CONTROLLING
attribute in the request if it is in the controlling role.
The ICE-CONTROLLED and ICE-CONTROLLING attributes are defined in sec-
ice-newatts.
A Binding request serving as a connectivity check MUST utilize the
STUN short-term credential mechanism.  The username for the
credential is formed by concatenating the username fragment provided
by the peer with the username fragment of the agent sending the
request, separated by a colon (":").  The password is equal to the
password provided by the peer.  For example, consider the case where
agent L is the initiating , agent and agent R is the responding
agent.  Agent L included a username fragment of LFRAG for its
candidates and a password of LPASS.  Agent R provided a username
fragment of RFRAG and a password of RPASS.  A connectivity check from
L to R utilizes the username RFRAG:LFRAG and a password of RPASS.  A
connectivity check from R to L utilizes the username LFRAG:RFRAG and
a password of LPASS.  The responses utilize the same usernames and
passwords as the requests (note that the USERNAME attribute is not
present in the response).
If the agent is using Diffserv Codepoint markings RFC2475 in its
media packets, it SHOULD apply those same markings to its
connectivity checks.
When a Binding response is received, it is correlated to its Binding
request using the transaction ID, as defined in RFC5389, which then
ties it to the candidate pair for which the Binding request was sent.
This section defines additional procedures for processing Binding
responses specific to this usage of STUN.
If the STUN transaction generates a 487 (Role Conflict) error
response, the agent checks whether it included an ICE-CONTROLLED or
ICE-CONTROLLING attribute in the associated Binding request.  If the
request contained an ICE-CONTROLLED attribute, the agent MUST switch
to the controlling role.  If the request contained an ICE-CONTROLLING
attribute, the agent MUST switch to the controlled role.
Once the agent has switched its role, the agent MUST enqueue the
candidate pair whose check generated the 487 into the triggered check
queue.  The state of that pair is set to Waiting.  When the triggered
check is sent, it will contain an ICE-CONTROLLING or ICE-CONTROLLED
attribute reflecting its new role.  The agent MUST NOT change the
tie-breaker value.
A change in roles will require an agent to recompute pair priorities
(sec-comp-pair-prio), since those priorities are a function of
controlling and controlled roles.  The change in role will also
impact whether the agent is responsible for selecting nominated pairs
and generating updated candidate information for sharing upon
conclusion of ICE.
Agents MAY support receipt of ICMP errors for connectivity checks.
If the STUN transaction generates an ICMP error, the agent sets the
state of the pair to Failed.  If the STUN transaction generates a
STUN error response that is unrecoverable (as defined in RFC5389) or
times out, the agent sets the state of the pair to Failed.
The agent MUST check that the source IP address and port of the
response equal the destination IP address and port to which the
Binding request was sent, and that the destination IP address and
port of the response match the source IP address and port from which
the Binding request was sent.  In other words, the source and
destination transport addresses in the request and responses are
symmetric.  If they are not symmetric, the agent sets the state of
the pair to Failed.
The STUN transaction generated a success response.
The source IP address and port of the response equals the
destination IP address and port to which the Binding request was
sent.
The destination IP address and port of the response match the
source IP address and port from which the Binding request was
sent.
Its type is equal to peer reflexive.
Its base is set equal to the local candidate of the candidate pair
from which the STUN check was sent.
Its priority is set equal to the value of the PRIORITY attribute
in the Binding request.
Its foundation is selected as described in sec-computing-
foundations.
This peer reflexive candidate is then added to the list of local
candidates for the media stream.  Its username fragment and password
are the same as all other local candidates for that media stream.
However, the peer reflexive candidate is not paired with other remote
candidates.  This is not necessary; a valid pair will be generated
from it momentarily based on the procedures in sec-valid-cons.  If an
agent wishes to pair the peer reflexive candidate with other remote
candidates besides the one in the valid pair that will be generated,
the agent MAY generate an update the peer with the candidate
information that includes the peer reflexive candidate.  This will
cause it to be paired with all other remote candidates.
The agent constructs a candidate pair whose local candidate equals
the mapped address of the response, and whose remote candidate equals
the destination address to which the request was sent.  This is
called a valid pair, since it has been validated by a STUN
connectivity check.  The valid pair may equal the pair that generated
the check, may equal a different pair in the check list, or may be a
pair not currently on any check list.  If the pair equals the pair
that generated the check or is on a check list currently, it is also
added to the VALID LIST, which is maintained by the agent for each
media stream.  This list is empty at the start of ICE processing, and
fills as checks are performed, resulting in valid candidate pairs.
It will be very common that the pair will not be on any check list.
Recall that the check list has pairs whose local candidates are never
reflexive; those pairs had their local candidates converted to the
base of the reflexive candidates, and then pruned if they were
redundant.  When the response to the STUN check arrives, the mapped
address will be reflexive if there is a NAT between the two.  In that
case, the valid pair will have a local candidate that doesn't match
any of the pairs in the check list.
If the pair is not on any check list, the agent computes the priority
for the pair based on the priority of each candidate, using the
algorithm in sec-forming.  The priority of the local candidate
depends on its type.  If it is not peer reflexive, it is equal to the
priority signaled for that candidate in the candidate exchange.  If
it is peer reflexive, it is equal to the PRIORITY attribute the agent
placed in the Binding request that just completed.  The priority of
the remote candidate is taken from the candidate information of the
peer.  If the candidate does not appear there, then the check must
have been a triggered check to a new remote candidate.  In that case,
the priority is taken as the value of the PRIORITY attribute in the
Binding request that triggered the check that just completed.  The
pair is then added to the VALID LIST.
The agent changes the states for all other Frozen pairs for the
same media stream and same foundation to Waiting.  Typically, but
not always, these other pairs will have different component IDs.
If the check list is active, the agent changes the state of all
Frozen pairs in that check list whose foundation matches a pair
in the valid list under consideration to Waiting.
If the check list is frozen, and there is at least one pair in
the check list whose foundation matches a pair in the valid
list under consideration, the state of all pairs in the check
list whose foundation matches a pair in the valid list under
consideration is set to Waiting.  This will cause the check
list to become active, and ordinary checks will begin for it,
as described in sec-periodic.
for each group, sets the state of the pair with the lowest
component ID to Waiting.  If there is more than one such
pair, the one with the highest-priority is used.
If the agent was a controlling agent, and it had included a USE-
CANDIDATE attribute in the Binding request, the valid pair generated
from that check has its nominated flag set to true.  This flag
indicates that this valid pair SHOULD be used for media, unless the
sending agent detects that the candidiate pair does not work.  This
concludes the ICE processing for this media stream or all media
streams; see sec-conclude.
If the agent is the controlled agent, the response may be the result
of a triggered check that was sent in response to a request that
itself had the USE-CANDIDATE attribute.  This case is described in
sec-up-fav, and may now result in setting the nominated flag for the
pair learned from the original request.
An agent MUST NOT select a candidate pair until it has sent a Binding
request, and received the corresponding Binding response, associated
with the candidiate pair.
Regardless of whether the check was successful or failed, the
completion of the transaction may require updating of check list and
timer states.
If there is not a pair in the valid list for each component of the
media stream, the state of the check list is set to Failed.
for each group, sets the state of the pair with the lowest
component ID to Waiting.  If there is more than one such pair,
the one with the highest-priority is used.
If none of the pairs in the check list are in the Waiting or Frozen
state, the check list is no longer considered active, and will not
count towards the value of N in the computation of timers for
ordinary checks as described in sec-periodic.
A connectivity check Binding request MUST utilize the STUN short-term
credential mechanism.
The username for the credential is formed by concatenating the
username fragment provided by the peer with the username fragment of
the agent sending the request, separated by a colon (":").
The password is equal to the password provided by the peer.
For example, consider the case where ICE agent L is the Initiating
agent and ICE agent R is the Responding agent.  Agent L included a
username fragment of LFRAG for its candidates and a password of
LPASS.  Agent R provided a username fragment of RFRAG and a password
of RPASS.  A connectivity check from L to R utilizes the username
RFRAG:LFRAG and a password of RPASS.  A connectivity check from R to
L utilizes the username LFRAG:RFRAG and a password of LPASS.  The
responses utilize the same usernames and passwords as the requests
(note that the USERNAME attribute is not present in the response).
If an ICE agent is using Diffserv Codepoint markings RFC2475 in its
media packets, the agent SHOULD apply those same markings to its
connectivity checks.
A connectivity check is generated by sending a Binding request from
the base associated with a local candidate to a remote candidate.
RFC5389 describes how Binding requests are constructed and generated.
Support for backwards compatibility with RFC 3489 MUST NOT be assumed
when performing connectivity checks.  The FINGERPRINT mechanism MUST
be used for connectivity checks.
This section defines additional procedures for processing Binding
responses specific to ICE connectivity checks.
When a Binding response is received, it is correlated to the
corresponding Binding request using the transaction ID RFC5389, which
then associates the response with the candidate pair for which the
Binding request was sent.  After that, the response is processed
according to the procedures for a role conflict, a failure, or a
success, according to the procedures below.
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 ICE agent included an ICE-CONTROLLING attribute in the request,
the agent MUST switch to the controlled role.
Once the ICE 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 ICE agent MUST NOT change the tie-breaker
value.
NOTE: A role switch requires an ICE agent to recompute pair
priorities (sec-comp-pair-prio), since the priority values depend on
the role.
NOTE: A role switch will also impact whether the ICE agent is
responsible for nominating candidate pairs, and whether the agent is
responsible for initiating the exchange of the updated candidate
information with the peer once ICE is concluded.
This section describes cases when the candidate pair state is set to
Failed.
NOTE: When the ICE agent sets the candidate pair state to Failed as a
result a connectivity check error, the agent does not change the
states of other candidate pairs with the same foundation.
The ICE agent MUST check that the source and destination transport
addresses in the Binding request and response are symmetric.  I.e.,
the source IP address and port of the response MUST be equal the
destination IP address and port to which the Binding request was
sent, and that the destination IP address and port of the response
MUST be equal to the source IP address and port from which the
Binding request was sent.  If the addresses are not symmetric, 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 an ICMP error, the agent SHOULD set the
state of the candidate pair to Failed.
If the Binding request generates a STUN error response that is
unrecoverable RFC5389) or times out, the ICE agent SHOULD set the
candidate pair state to Failed.
The source and destination transport addresses in the Binding
request and response are symmetric.
The type is equal to peer reflexive.
The base is set equal to the local candidate of the candidate pair
from which the Binding request was sent.
The priority is set equal to the value of the PRIORITY attribute
in the Binding request.
The foundation is set as described in sec-computing-foundations.
The peer reflexive candidate is then added to the list of local
candidates for the media stream.  The username fragment and password
are the same as for all other local candidates for that media stream.
The ICE agent does not need to pair the peer reflexive candidate with
remote candidates, as a valid candiate pair will be created due to
the procedures in sec-valid-cons.  If an ICE agent wishes to pair the
peer reflexive candidate with other remote candidates besides the one
in the valid pair that will be generated, the agent MAY provide
updated candidiate information to the peer that includes the peer
reflexive candidate.  This will cause the peer reflexive candidate to
be paired with all other remote candidates.
The ICE agent constructs a candidate pair whose local candidate
equals the mapped address of the response, and whose remote candidate
equals the destination address to which the request was sent.  This
is called a valid pair.
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 check blongs), or it may be a pair not currently in
any check list.
The ICE agent maintains a separate list, called the valid list, for
each check list in the CHECK LIST SET.  The valid list will contain
valid pairs.  Initially each valid list is empty.
If the valid pair is not in any check list, the agent computes the
priority for the pair based on the priority of each candidate,
using the algorithm in sec-forming.  The priority of the local
candidate depends on its type.  Unless the type is peer reflexive,
the priority is equal to the priority signaled for that candidate
in the candidate exchange.  If the type is peer reflexive, it is
equal to the PRIORITY attribute the agent placed in the Binding
request that just completed.  The priority of the remote candidate
is taken from the candidate information of the peer.  If the
candidate does not appear there, then the check must have been a
triggered check to a new remote candidate.  In that case, the
priority is taken as the value of the PRIORITY attribute in the
Binding request that triggered the check that just completed.  The
pair is then added to the valid list.
NOTE: It will be very common that the valid pair will not be in any
check list.  Recall that the check list has pairs whose local
candidates are never reflexive; those pairs had their local
candidates converted to the base of the reflexive candidates, and
then pruned if they were redundant.  When the response to the Binding
request arrives, the mapped address will be reflexive if there is a
NAT between the two.  In that case, the valid pair will have a local
candidate that doesn't match any of the pairs in the check list.
The ICE agent sets the state of both the candidate pair that
generated the check, and the constructed valid pair, to Succeeded.
Note that the pair which generated the check may be different than
the valid pair constructed in sec-valid-cons.
The success of the connectivity check might also cause the state of
other candidate pairs to change.  The ICE agent MUST set the states
for all other Frozen candidiate pairs (in each check list in the
CHECK LIST SET) with the same foundation to Waiting.
NOTE: Within a given check list, candidate pairs with the same
foundations will typically have different componend ID values.
If the ICE agent was a controlling agent, and the agent had included
a USE-CANDIDATE attribute in the Binding request, the valid pair
generated from that check has its nominated flag set to true.  This
flag indicates that this valid pair SHOULD be used for media, unless
the sending agent detects that the candidate pair does not work.
This concludes the ICE processing for this media stream or all media
streams; see sec-conclude.
If the ICE agent is the controlled agent, the response may be the
result of a triggered check that was sent in response to a request
that itself had the USE-CANDIDATE attribute.  This case is described
in sec-up-fav, and may now result in setting the nominated flag for
the pair learned from the original request.
An ICE agent MUST NOT select a candidate pair until it has sent a
Binding request, and received the corresponding Binding response,
associated with the candidiate pair.
Regardless of whether a connectivity check was successful or failed,
the completion of the check may require updating of check list
states.  For each check list in the CHECK LIST SET, if all of the
candidate pairs are in either Failed or Succeeded state, and if there
is not a valid pair in the valid list for each component of the media
stream associated with the check list, the state of the check list is
set to Failed.  If there is a valid pair for each component in the
valid list, the state of the check list is set to Succeeded.