Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: ICE

RFC 8445

Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal

Pages: 100
Proposed STD
Obsoletes:  5245
Part 5 of 6 – Pages 70 to 88
First   Prev   Next

Top   ToC   Page 70   prevText
17.  Operational Considerations

   This section discusses issues relevant to operators operating
   networks where ICE will be used by endpoints.

17.1.  NAT and Firewall Types

   ICE was designed to work with existing NAT and firewall equipment.
   Consequently, it is not necessary to replace or reconfigure existing
   firewall and NAT equipment in order to facilitate deployment of ICE.
   Indeed, ICE was developed to be deployed in environments where the
   Voice over IP (VoIP) operator has no control over the IP network
   infrastructure, including firewalls and NATs.

   That said, ICE works best in environments where the NAT devices are
   "behave" compliant, meeting the recommendations defined in [RFC4787]
   and [RFC5382].  In networks with behave-compliant NAT, ICE will work
   without the need for a TURN server, thus improving voice quality,
   decreasing call setup times, and reducing the bandwidth demands on
   the network operator.

17.2.  Bandwidth Requirements

   Deployment of ICE can have several interactions with available
   network capacity that operators need to take into consideration.

17.2.1.  STUN and TURN Server-Capacity Planning

   First and foremost, ICE makes use of TURN and STUN servers, which
   would typically be located in data centers.  The STUN servers require
   relatively little bandwidth.  For each component of each data stream,
   there will be one or more STUN transactions from each client to the
   STUN server.  In a basic voice-only IPv4 VoIP deployment, there will
   be four transactions per call (one for RTP and one for RTCP, for both
   the caller and callee).  Each transaction is a single request and a
   single response, the former being 20 bytes long, and the latter, 28.
Top   ToC   Page 71
   Consequently, if a system has N users, and each makes four calls in a
   busy hour, this would require N*1.7bps.  For one million users, this
   is 1.7 Mbps, a very small number (relatively speaking).

   TURN traffic is more substantial.  The TURN server will see traffic
   volume equal to the STUN volume (indeed, if TURN servers are
   deployed, there is no need for a separate STUN server), in addition
   to the traffic for the actual data.  The amount of calls requiring
   TURN for data relay is highly dependent on network topologies, and
   can and will vary over time.  In a network with 100% behave-compliant
   NATs, it is exactly zero.

   The planning considerations above become more significant in
   multimedia scenarios (e.g., audio and video conferences) and when the
   numbers of participants in a session grow.

17.2.2.  Gathering and Connectivity Checks

   The process of gathering candidates and performing connectivity
   checks can be bandwidth intensive.  ICE has been designed to pace
   both of these processes.  The gathering and connectivity-check phases
   are meant to generate traffic at roughly the same bandwidth as the
   data traffic itself will consume once the ICE process concludes.
   This was done to ensure that if a network is designed to support
   communication traffic of a certain type (voice, video, or just text),
   it will have sufficient capacity to support the ICE checks for that
   data.  Once ICE has concluded, the subsequent ICE keepalives will
   later cause a marginal increase in the total bandwidth utilization;
   however, this will typically be an extremely small increase.

   Congestion due to the gathering and check phases has proven to be a
   problem in deployments that did not utilize pacing.  Typically,
   access links became congested as the endpoints flooded the network
   with checks as fast as they could send them.  Consequently, network
   operators need to ensure that their ICE implementations support the
   pacing feature.  Though this pacing does increase call setup times,
   it makes ICE network friendly and easier to deploy.

17.2.3.  Keepalives

   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
Top   ToC   Page 72
   single packet every 15-20 seconds, far less than the packet every
   20-30 ms that is sent when there is voice.  Therefore, keepalives do
   not have any real impact on capacity planning.

17.3.  ICE and ICE-Lite

   Deployments utilizing a mix of ICE and ICE-lite interoperate with
   each other.  They have been explicitly designed to do so.

   However, ICE-lite can only be deployed in limited use cases.  Those
   cases, and the caveats involved in doing so, are documented in
   Appendix A.

17.4.  Troubleshooting and Performance Management

   ICE utilizes end-to-end connectivity checks and places much of the
   processing in the endpoints.  This introduces a challenge to the
   network operator -- how can they troubleshoot ICE deployments?  How
   can they know how ICE is performing?

   ICE has built-in features to help deal with these problems.
   Signaling servers, typically deployed in data centers of the network
   operator, will see the contents of the candidate exchanges that
   convey the ICE parameters.  These parameters include the type of each
   candidate (host, server reflexive, or relayed), along with their
   related addresses.  Once ICE processing has completed, an updated
   candidate exchange takes place, signaling the selected address (and
   its type).  This updated signaling is performed exactly for the
   purposes of educating network equipment (such as a diagnostic tool
   attached to a signaling) about the results of ICE processing.

   As a consequence, through the logs generated by a signaling server, a
   network operator can observe what types of candidates are being used
   for each call and what addresses were selected by ICE.  This is the
   primary information that helps evaluate how ICE is performing.

17.5.  Endpoint Configuration

   ICE relies on several pieces of data being configured into the
   endpoints.  This configuration data includes timers, credentials for
   TURN servers, and hostnames for STUN and TURN servers.  ICE itself
   does not provide a mechanism for this configuration.  Instead, it is
   assumed that this information is attached to whatever mechanism is
   used to configure all of the other parameters in the endpoint.  For
   SIP phones, standard solutions such as the configuration framework
   [RFC6080] have been defined.
Top   ToC   Page 73
18.  IAB Considerations

   The IAB has studied the problem of "Unilateral Self-Address Fixing"
   (UNSAF), which is the general process by which an ICE agent attempts
   to determine its address in another realm on the other side of a NAT
   through a collaborative protocol reflection mechanism [RFC3424].  ICE
   is an example of a protocol that performs this type of function.
   Interestingly, the process for ICE is not unilateral, but bilateral,
   and the difference has a significant impact on the issues raised by
   the IAB.  Indeed, ICE can be considered a Bilateral Self-Address
   Fixing (B-SAF) protocol, rather than an UNSAF protocol.  Regardless,
   the IAB has mandated that any protocols developed for this purpose
   document a specific set of considerations.  This section meets those

18.1.  Problem Definition

   From RFC 3424, any UNSAF proposal needs to provide:

      Precise definition of a specific, limited-scope problem that is to
      be solved with the UNSAF proposal.  A short term fix should not be
      generalized to solve other problems.  Such generalizations lead to
      the the prolonged dependence on and usage of the supposed short
      term fix -- meaning that it is no longer accurate to call it
      "short term".

   The specific problems being solved by ICE are:

      Providing a means for two peers to determine the set of transport
      addresses that can be used for communication.

      Providing a means for an agent to determine an address that is
      reachable by another peer with which it wishes to communicate.

18.2.  Exit Strategy

   From RFC 3424, any UNSAF proposal needs to provide:

      Description of an exit strategy/transition plan.  The better short
      term fixes are the ones that will naturally see less and less use
      as the appropriate technology is deployed.

   ICE itself doesn't easily get phased out.  However, it is useful even
   in a globally connected Internet, to serve as a means for detecting
   whether a router failure has temporarily disrupted connectivity, for
   example.  ICE also helps prevent certain security attacks that have
   nothing to do with NAT.  However, what ICE does is help phase out
   other UNSAF mechanisms.  ICE effectively picks amongst those
Top   ToC   Page 74
   mechanisms, prioritizing ones that are better and deprioritizing ones
   that are worse.  As NATs begin to dissipate as IPv6 is introduced,
   server-reflexive and relayed candidates (both forms of UNSAF
   addresses) simply never get used, because higher-priority
   connectivity exists to the native host candidates.  Therefore, the
   servers get used less and less and can eventually be removed when
   their usage goes to zero.

   Indeed, ICE can assist in the transition from IPv4 to IPv6.  It can
   be used to determine whether to use IPv6 or IPv4 when two dual-stack
   hosts communicate with SIP (IPv6 gets used).  It can also allow a
   network with both 6to4 and native v6 connectivity to determine which
   address to use when communicating with a peer.

18.3.  Brittleness Introduced by ICE

   From RFC 3424, any UNSAF proposal needs to provide:

      Discussion of specific issues that may render systems more
      "brittle".  For example, approaches that involve using data at
      multiple network layers create more dependencies, increase
      debugging challenges, and make it harder to transition.

   ICE actually removes brittleness from existing UNSAF mechanisms.  In
   particular, classic STUN (as described in RFC 3489 [RFC3489]) has
   several points of brittleness.  One of them is the discovery process
   that requires an ICE agent to try to classify the type of NAT it is
   behind.  This process is error prone.  With ICE, that discovery
   process is simply not used.  Rather than unilaterally assessing the
   validity of the address, its validity is dynamically determined by
   measuring connectivity to a peer.  The process of determining
   connectivity is very robust.

   Another point of brittleness in classic STUN and any other unilateral
   mechanism is its absolute reliance on an additional server.  ICE
   makes use of a server for allocating unilateral addresses, but it
   allows agents to directly connect if possible.  Therefore, in some
   cases, the failure of a STUN server would still allow for a call to
   progress when ICE is used.

   Another point of brittleness in classic STUN is that it assumes the
   STUN server is on the public Internet.  Interestingly, with ICE, that
   is not necessary.  There can be a multitude of STUN servers in a
   variety of address realms.  ICE will discover the one that has
   provided a usable address.
Top   ToC   Page 75
   The most troubling point of brittleness in classic STUN is that it
   doesn't work in all network topologies.  In cases where there is a
   shared NAT between each agent and the STUN server, traditional STUN
   may not work.  With ICE, that restriction is removed.

   Classic STUN also introduces some security considerations.
   Fortunately, those security considerations are also mitigated by ICE.

   Consequently, ICE serves to repair the brittleness introduced in
   classic STUN, and it does not introduce any additional brittleness
   into the system.

   The penalty of these improvements is that ICE increases session
   establishment times.

18.4.  Requirements for a Long-Term Solution

   From RFC 3424, any UNSAF proposal needs to provide the following:

      Identify requirements for longer term, sound technical solutions;
      contribute to the process of finding the right longer term

   Our conclusions from RFC 3489 remain unchanged.  However, we feel ICE
   actually helps because we believe it can be part of the long-term

18.5.  Issues with Existing NAPT Boxes

   From RFC 3424, any UNSAF proposal needs to provide:

      Discussion of the impact of the noted practical issues with
      existing, deployed NA[P]Ts and experience reports.

   A number of NAT boxes are now being deployed into the market that try
   to provide "generic" ALG functionality.  These generic ALGs hunt for
   IP addresses, in either text or binary form within a packet, and
   rewrite them if they match a binding.  This interferes with classic
   STUN.  However, the update to STUN [RFC5389] uses an encoding that
   hides these binary addresses from generic ALGs.

   Existing NAPT boxes have non-deterministic and typically short
   expiration times for UDP-based bindings.  This requires
   implementations to send periodic keepalives to maintain those
   bindings.  ICE uses a default of 15 s, which is a very conservative
   estimate.  Eventually, over time, as NAT boxes become compliant to
   behave [RFC4787], this minimum keepalive will become deterministic
Top   ToC   Page 76
   and well known, and the ICE timers can be adjusted.  Having a way to
   discover and control the minimum keepalive interval would be far
   better still.

19.  Security Considerations

19.1.  IP Address Privacy

   The process of probing for candidates reveals the source addresses of
   the client and its peer to any on-network listening attacker, and the
   process of exchanging candidates reveals the addresses to any
   attacker that is able to see the negotiation.  Some addresses, such
   as the server-reflexive addresses gathered through the local
   interface of VPN users, may be sensitive information.  If these
   potential attacks cannot be mitigated, ICE usages can define
   mechanisms for controlling which addresses are revealed to the
   negotiation and/or probing process.  Individual implementations may
   also have implementation-specific rules for controlling which
   addresses are revealed.  For example, [WebRTC-IP-HANDLING] provides
   additional information about the privacy aspects of revealing IP
   addresses via ICE for WebRTC applications.  ICE implementations where
   such issues can arise are RECOMMENDED to provide a programmatic or
   user interface that provides control over which network interfaces
   are used to generate candidates.

   Based on the types of candidates provided by the peer, and the
   results of the connectivity tests performed against those candidates,
   the peer might be able to determine characteristics of the local
   network, e.g., if different timings are apparent to the peer.  Within
   the limit, the peer might be able to probe the local network.

   There are several types of attacks possible in an ICE system.  The
   subsections consider these attacks and their countermeasures.

19.2.  Attacks on Connectivity Checks

   An attacker might attempt to disrupt the STUN connectivity checks.
   Ultimately, all of these attacks fool an ICE agent into thinking
   something incorrect about the results of the connectivity checks.
   Depending on the type of attack, the attacker needs to have different
   capabilities.  In some cases, the attacker needs to be on the path of
   the connectivity checks.  In other cases, the attacker does not need
   to be on the path, as long as it is able to generate STUN
   connectivity checks.  While attacks on connectivity checks are
   typically performed by network entities, if an attacker is able to
   control an endpoint, it might be able to trigger connectivity-check
   attacks.  The possible false conclusions an attacker can try and
   cause are:
Top   ToC   Page 77
   False Invalid:  An attacker can fool a pair of agents into thinking a
      candidate pair is invalid, when it isn't.  This can be used to
      cause an agent to prefer a different candidate (such as one
      injected by the attacker) or to disrupt a call by forcing all
      candidates to fail.

   False Valid:  An attacker can fool a pair of agents into thinking a
      candidate pair is valid, when it isn't.  This can cause an agent
      to proceed with a session but then not be able to receive any

   False Peer-Reflexive Candidate:  An attacker can cause an agent to
      discover a new peer-reflexive candidate when it is not expected
      to.  This can be used to redirect data streams to a DoS target or
      to the attacker, for eavesdropping or other purposes.

   False Valid on False Candidate:  An attacker has already convinced an
      agent that there is a candidate with an address that does not
      actually route to that agent (e.g., by injecting a false peer-
      reflexive candidate or false server-reflexive candidate).  The
      attacker then launches an attack that forces the agents to believe
      that this candidate is valid.

      If an attacker can cause a false peer-reflexive candidate or false
      valid on a false candidate, it can launch any of the attacks
      described in [RFC5389].

   To force the false invalid result, the attacker has to wait for the
   connectivity check from one of the agents to be sent.  When it is,
   the attacker needs to inject a fake response with an unrecoverable
   error response (such as a 400), or drop the response so that it never
   reaches the agent.  However, since the candidate is, in fact, valid,
   the original request may reach the peer agent and result in a success
   response.  The attacker needs to force this packet or its response to
   be dropped through a DoS attack, a Layer 2 network disruption, or
   another technique.  If it doesn't do this, the success response will
   also reach the originator, alerting it to a possible attack.  The
   ability for the attacker to generate a fake response is mitigated
   through the STUN short-term credential mechanism.  In order for this
   response to be processed, the attacker needs the password.  If the
   candidate exchange signaling is secured, the attacker will not have
   the password, and its response will be discarded.

   Spoofed ICMP Hard Errors (Type 3, codes 2-4) can also be used to
   create false invalid results.  If an ICE agent implements a response
   to these ICMP errors, the attacker is capable of generating an ICMP
   message that is delivered to the agent sending the connectivity
   check.  The validation of the ICMP error message by the agent is its
Top   ToC   Page 78
   only defense.  For Type 3 code=4, the outer IP header provides no
   validation, unless the connectivity check was sent with DF=0.  For
   codes 2 or 3, which are originated by the host, the address is
   expected to be any of the remote agent's host, reflexive, or relay
   candidate IP addresses.  The ICMP message includes the IP header and
   UDP header of the message triggering the error.  These fields also
   need to be validated.  The IP destination and UDP destination port
   need to match either the targeted candidate address and port or the
   candidate's base address.  The source IP address and port can be any
   candidate for the same base address of the agent sending the
   connectivity check.  Thus, any attacker having access to the exchange
   of the candidates will have the necessary information.  Hence, the
   validation is a weak defense, and the sending of spoofed ICMP attacks
   is also possible for off-path attackers from a node in a network
   without source address validation.

   Forcing the fake valid result works in a similar way.  The attacker
   needs to wait for the Binding request from each agent and inject a
   fake success response.  Again, due to the STUN short-term credential
   mechanism, in order for the attacker to inject a valid success
   response, the attacker needs the password.  Alternatively, the
   attacker can route (e.g., using a tunneling mechanism) a valid
   success response, which normally would be dropped or rejected by the
   network, to the agent.

   Forcing the false peer-reflexive candidate result can be done with
   either fake requests or responses, or with replays.  We consider the
   fake requests and responses case first.  It requires the attacker to
   send a Binding request to one agent with a source IP address and port
   for the false candidate.  In addition, the attacker needs to wait for
   a Binding request from the other agent and generate a fake response
   with a XOR-MAPPED-ADDRESS attribute containing the false candidate.
   Like the other attacks described here, this attack is mitigated by
   the STUN message integrity mechanisms and secure candidate exchanges.

   Forcing the false peer-reflexive candidate result with packet replays
   is different.  The attacker waits until one of the agents sends a
   check.  It intercepts this request and replays it towards the other
   agent with a faked source IP address.  It also needs to prevent the
   original request from reaching the remote agent, by either launching
   a DoS attack to cause the packet to be dropped or forcing it to be
   dropped using Layer 2 mechanisms.  The replayed packet is received at
   the other agent, and accepted, since the integrity check passes (the
   integrity check cannot and does not cover the source IP address and
   port).  It is then responded to.  This response will contain a XOR-
   MAPPED-ADDRESS with the false candidate, and it will be sent to that
   false candidate.  The attacker then needs to receive it and relay it
   towards the originator.
Top   ToC   Page 79
   The other agent will then initiate a connectivity check towards that
   false candidate.  This validation needs to succeed.  This requires
   the attacker to force a false valid on a false candidate.  The
   injecting of fake requests or responses to achieve this goal is
   prevented using the integrity mechanisms of STUN and the candidate
   exchange.  Thus, this attack can only be launched through replays.
   To do that, the attacker needs to intercept the check towards this
   false candidate and replay it towards the other agent.  Then, it
   needs to intercept the response and replay that back as well.

   This attack is very hard to launch unless the attacker is identified
   by the fake candidate.  This is because it requires the attacker to
   intercept and replay packets sent by two different hosts.  If both
   agents are on different networks (e.g., across the public Internet),
   this attack can be hard to coordinate, since it needs to occur
   against two different endpoints on different parts of the network at
   the same time.

   If the attacker itself is identified by the fake candidate, the
   attack is easier to coordinate.  However, if the data path is secured
   (e.g., using the Secure Real-time Transport Protocol (SRTP)
   [RFC3711]), the attacker will not be able to process the data
   packets, but will only be able to discard them, effectively disabling
   the data stream.  However, this attack requires the agent to disrupt
   packets in order to block the connectivity check from reaching the
   target.  In that case, if the goal is to disrupt the data stream,
   it's much easier to just disrupt it with the same mechanism, rather
   than attack ICE.

19.3.  Attacks on Server-Reflexive Address Gathering

   ICE endpoints make use of STUN Binding requests for gathering server-
   reflexive candidates from a STUN server.  These requests are not
   authenticated in any way.  As a consequence, there are numerous
   techniques an attacker can employ to provide the client with a false
   server-reflexive candidate:

   o  An attacker can compromise the DNS, causing DNS queries to return
      a rogue STUN server address.  That server can provide the client
      with fake server-reflexive candidates.  This attack is mitigated
      by DNS security, though DNSSEC is not required to address it.

   o  An attacker that can observe STUN messages (such as an attacker on
      a shared network segment, like Wi-Fi) can inject a fake response
      that is valid and will be accepted by the client.

   o  An attacker can compromise a STUN server and cause it to send
      responses with incorrect mapped addresses.
Top   ToC   Page 80
   A false mapped address learned by these attacks will be used as a
   server-reflexive candidate in the establishment of the ICE session.
   For this candidate to actually be used for data, the attacker also
   needs to attack the connectivity checks, and in particular, force a
   false valid on a false candidate.  This attack is very hard to launch
   if the false address identifies a fourth party (neither the
   initiator, responder, nor attacker), since it requires attacking the
   checks generated by each ICE agent in the session and is prevented by
   SRTP if it identifies the attacker itself.

   If the attacker elects not to attack the connectivity checks, the
   worst it can do is prevent the server-reflexive candidate from being
   used.  However, if the peer agent has at least one candidate that is
   reachable by the agent under attack, the STUN connectivity checks
   themselves will provide a peer-reflexive candidate that can be used
   for the exchange of data.  Peer-reflexive candidates are generally
   preferred over server-reflexive candidates.  As such, an attack
   solely on the STUN address gathering will normally have no impact on
   a session at all.

19.4.  Attacks on Relayed Candidate Gathering

   An attacker might attempt to disrupt the gathering of relayed
   candidates, forcing the client to believe it has a false relayed
   candidate.  Exchanges with the TURN server are authenticated using a
   long-term credential.  Consequently, injection of fake responses or
   requests will not work.  In addition, unlike Binding requests,
   Allocate requests are not susceptible to replay attacks with modified
   source IP addresses and ports, since the source IP address and port
   are not utilized to provide the client with its relayed candidate.

   Even if an attacker has caused the client to believe in a false
   relayed candidate, the connectivity checks cause such a candidate to
   be used only if they succeed.  Thus, an attacker needs to launch a
   false valid on a false candidate, per above, which is a very
   difficult attack to coordinate.

19.5.  Insider Attacks

   In addition to attacks where the attacker is a third party trying to
   insert fake candidate information or STUN messages, there are attacks
   possible with ICE when the attacker is an authenticated and valid
   participant in the ICE exchange.
Top   ToC   Page 81
19.5.1.  STUN Amplification Attack

   The STUN amplification attack is similar to a "voice hammer" attack,
   where the attacker causes other agents to direct voice packets to the
   attack target.  However, instead of voice packets being directed to
   the target, STUN connectivity checks are directed to the target.  The
   attacker sends a large number of candidates, say, 50.  The responding
   agent receives the candidate information and starts its checks, which
   are directed at the target, and consequently, never generate a
   response.  In the case of WebRTC, the user might not even be aware
   that this attack is ongoing, since it might be triggered in the
   background by malicious JavaScript code that the user has fetched.
   The answerer will start a new connectivity check every Ta ms (say,
   Ta=50ms).  However, the retransmission timers are set to a large
   number due to the large number of candidates.  As a consequence,
   packets will be sent at an interval of one every Ta milliseconds and
   then with increasing intervals after that.  Thus, STUN will not send
   packets at a rate faster than data would be sent, and the STUN
   packets persist only briefly, until ICE fails for the session.
   Nonetheless, this is an amplification mechanism.

   It is impossible to eliminate the amplification, but the volume can
   be reduced through a variety of heuristics.  ICE agents SHOULD limit
   the total number of connectivity checks they perform to 100.
   Additionally, agents MAY limit the number of candidates they will

   Frequently, protocols that wish to avoid these kinds of attacks force
   the initiator to wait for a response prior to sending the next
   message.  However, in the case of ICE, this is not possible.  It is
   not possible to differentiate the following two cases:

   o  There was no response because the initiator is being used to
      launch a DoS attack against an unsuspecting target that will not

   o  There was no response because the IP address and port are not
      reachable by the initiator.

   In the second case, another check will be sent at the next
   opportunity, while in the former case, no further checks will be
Top   ToC   Page 82
20.  IANA Considerations

   The original ICE specification registered four STUN attributes and
   one new STUN error response.  The STUN attributes and error response
   are reproduced here.  In addition, this specification registers a new
   ICE option.

20.1.  STUN Attributes

   IANA has registered four STUN attributes:

      0x0024 PRIORITY
      0x0025 USE-CANDIDATE
      0x8029 ICE-CONTROLLED

20.2.  STUN Error Responses

   IANA has registered the following STUN error-response code:

    487   Role Conflict: The client asserted an ICE role (controlling or
          controlled) that is in conflict with the role of the server.

20.3.  ICE Options

   IANA has registered the following ICE option in the "ICE Options"
   subregistry of the "Interactive Connectivity Establishment (ICE)"
   registry, following the procedures defined in [RFC6336].

   ICE Option name:

      Name:    IESG

   Change Controller:

      The ICE option indicates that the ICE agent using the ICE option
      is implemented according to RFC 8445.

      RFC 8445
Top   ToC   Page 83
21.  Changes from RFC 5245

   The purpose of this updated ICE specification is to:

   o  Clarify procedures in RFC 5245.

   o  Make technical changes, due to discovered flaws in RFC 5245 and
      feedback from the community that has implemented and deployed ICE
      applications based on RFC 5245.

   o  Make the procedures independent of the signaling protocol, by
      removing the SIP and SDP procedures.  Procedures specific to a
      signaling protocol will be defined in separate usage documents.
      [ICE-SIP-SDP] defines ICE usage with SIP and SDP.

   The following technical changes have been done:

   o  Aggressive nomination removed.

   o  The procedures for calculating candidate pair states and
      scheduling connectivity checks modified.

   o  Procedures for calculation of Ta and RTO modified.

   o  Active checklist and Frozen checklist definitions removed.

   o  'ice2' ICE option added.

   o  IPv6 considerations modified.

   o  Usage with no-op for keepalives, and keepalives with non-ICE
      peers, removed.

22.  References

22.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
Top   ToC   Page 84
   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              DOI 10.17487/RFC5389, October 2008,

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766,
              DOI 10.17487/RFC5766, April 2010,

   [RFC6336]  Westerlund, M. and C. Perkins, "IANA Registry for
              Interactive Connectivity Establishment (ICE) Options",
              RFC 6336, DOI 10.17487/RFC6336, July 2011,

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

22.2.  Informative References

              Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
              "Session Description Protocol (SDP) Offer/Answer
              procedures for Interactive Connectivity Establishment
              (ICE)", Work in Progress,
              draft-ietf-mmusic-ice-sip-sdp-21, June 2018.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,

   [RFC3102]  Borella, M., Lo, J., Grabelsky, D., and G. Montenegro,
              "Realm Specific IP: Framework", RFC 3102,
              DOI 10.17487/RFC3102, October 2001,
Top   ToC   Page 85
   [RFC3103]  Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi,
              "Realm Specific IP: Protocol Specification", RFC 3103,
              DOI 10.17487/RFC3103, October 2001,

   [RFC3235]  Senie, D., "Network Address Translator (NAT)-Friendly
              Application Design Guidelines", RFC 3235,
              DOI 10.17487/RFC3235, January 2002,

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,

   [RFC3303]  Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
              A. Rayhan, "Middlebox communication architecture and
              framework", RFC 3303, DOI 10.17487/RFC3303, August 2002,

   [RFC3424]  Daigle, L., Ed. and IAB, "IAB Considerations for
              UNilateral Self-Address Fixing (UNSAF) Across Network
              Address Translation", RFC 3424, DOI 10.17487/RFC3424,
              November 2002, <>.

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              DOI 10.17487/RFC3489, March 2003,

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <>.

   [RFC3605]  Huitema, C., "Real Time Control Protocol (RTCP) attribute
              in Session Description Protocol (SDP)", RFC 3605,
              DOI 10.17487/RFC3605, October 2003,
Top   ToC   Page 86
   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,

   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, DOI 10.17487/RFC3879, September
              2004, <>.

   [RFC4038]  Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and
              E. Castro, "Application Aspects of IPv6 Transition",
              RFC 4038, DOI 10.17487/RFC4038, March 2005,

   [RFC4091]  Camarillo, G. and J. Rosenberg, "The Alternative Network
              Address Types (ANAT) Semantics for the Session Description
              Protocol (SDP) Grouping Framework", RFC 4091,
              DOI 10.17487/RFC4091, June 2005,

   [RFC4092]  Camarillo, G. and J. Rosenberg, "Usage of the Session
              Description Protocol (SDP) Alternative Network Address
              Types (ANAT) Semantics in the Session Initiation Protocol
              (SIP)", RFC 4092, DOI 10.17487/RFC4092, June 2005,

   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <>.

   [RFC4787]  Audet, F., Ed. and C. Jennings, "Network Address
              Translation (NAT) Behavioral Requirements for Unicast
              UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
              2007, <>.
Top   ToC   Page 87
   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              DOI 10.17487/RFC5245, April 2010,

   [RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, DOI 10.17487/RFC5382, October 2008,

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761,
              DOI 10.17487/RFC5761, April 2010,

   [RFC6080]  Petrie, D. and S. Channabasappa, Ed., "A Framework for
              Session Initiation Protocol User Agent Profile Delivery",
              RFC 6080, DOI 10.17487/RFC6080, March 2011,

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <>.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              DOI 10.17487/RFC6147, April 2011,

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298,
              DOI 10.17487/RFC6298, June 2011,

   [RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
              "TCP Candidates with Interactive Connectivity
              Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
              March 2012, <>.

   [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
              "Increasing TCP's Initial Window", RFC 6928,
              DOI 10.17487/RFC6928, April 2013,
Top   ToC   Page 88
   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, DOI 10.17487/RFC7050, November 2013,

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,

   [RFC7825]  Goldberg, J., Westerlund, M., and T. Zeng, "A Network
              Address Translator (NAT) Traversal Mechanism for Media
              Controlled by the Real-Time Streaming Protocol (RTSP)",
              RFC 7825, DOI 10.17487/RFC7825, December 2016,

   [RFC8421]  Martinsen, P., Reddy, T., and P. Patil, "Interactive
              Connectivity Establishment (ICE) Multihomed and IPv4/IPv6
              Dual-Stack Guidelines", RFC 8421, DOI 10.17487/RFC8421,
              July 2018, <>.

              Uberti, J. and G. Shieh, "WebRTC IP Address Handling
              Requirements", Work in Progress, draft-ietf-rtcweb-ip-
              handling-09, June 2018.