draft-ietf-mmusic-rfc5245bis-02.txt   draft-ietf-mmusic-rfc5245bis-03.txt 
MMUSIC A. Keranen MMUSIC A. Keranen
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 5245 (if approved) J. Rosenberg Obsoletes: 5245 (if approved) J. Rosenberg
Intended status: Standards Track jdrosen.net Intended status: Standards Track jdrosen.net
Expires: January 5, 2015 July 4, 2014 Expires: April 29, 2015 October 26, 2014
Interactive Connectivity Establishment (ICE): A Protocol for Network Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols Address Translator (NAT) Traversal for Offer/Answer Protocols
draft-ietf-mmusic-rfc5245bis-02 draft-ietf-mmusic-rfc5245bis-03
Abstract Abstract
This document describes a protocol for Network Address Translator This document describes a protocol for Network Address Translator
(NAT) traversal for UDP-based multimedia sessions established with (NAT) traversal for UDP-based multimedia sessions established with
the offer/answer model. This protocol is called Interactive the offer/answer model. This protocol is called Interactive
Connectivity Establishment (ICE). ICE makes use of the Session Connectivity Establishment (ICE). ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Utilities for NAT (STUN) protocol and its extension,
Traversal Using Relay NAT (TURN). ICE can be used by any protocol Traversal Using Relay NAT (TURN). ICE can be used by any protocol
utilizing the offer/answer model, such as the Session Initiation utilizing the offer/answer model, such as the Session Initiation
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on April 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 8 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 8
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10
2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 11 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 11
2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 12 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 12
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 13 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 13
2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 13 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 13
2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 15 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 15
2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 15 2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 15
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 18 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19
4.1. Full Implementation Requirements . . . . . . . . . . . . 19 4.1. Full Implementation Requirements . . . . . . . . . . . . 19
4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19
4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19
4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20
4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 21 4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 21
4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22 4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22
4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22
4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22
4.1.2.2. Guidelines for Choosing Type and Local 4.1.2.2. Guidelines for Choosing Type and Local
Preferences . . . . . . . . . . . . . . . . . . . 23 Preferences . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 4, line 8 skipping to change at page 4, line 8
8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 50 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 50
8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 50 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 50
8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 51 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 51
8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 51 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 51
8.2. Procedures for Lite Implementations . . . . . . . . . . . 53 8.2. Procedures for Lite Implementations . . . . . . . . . . . 53
8.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . 53 8.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . 53
8.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . 53 8.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . 53
8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 54 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 54
8.3.1. Full Implementation Procedures . . . . . . . . . . . 54 8.3.1. Full Implementation Procedures . . . . . . . . . . . 54
8.3.2. Lite Implementation Procedures . . . . . . . . . . . 54 8.3.2. Lite Implementation Procedures . . . . . . . . . . . 54
9. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 54 9. ICE Restarts . . . . . . . . . . . . . . . . . . . . . . . . 54
10. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 55 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 56 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 56
10.1.1. Procedures for Full Implementations . . . . . . . . 56 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 56
10.1.2. Procedures for Lite Implementations . . . . . . . . 56 11.1.1. Procedures for Full Implementations . . . . . . . . 56
10.1.3. Procedures for All Implementations . . . . . . . . . 57 11.1.2. Procedures for Lite Implementations . . . . . . . . 57
10.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 57 11.1.3. Procedures for All Implementations . . . . . . . . . 57
11. Extensibility Considerations . . . . . . . . . . . . . . . . 57 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 57
12. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 58 12. Extensibility Considerations . . . . . . . . . . . . . . . . 58
12.1. Real-time Media Streams . . . . . . . . . . . . . . . . 59 13. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 59
12.2. Non-real-time Sessions . . . . . . . . . . . . . . . . . 60 13.1. Real-time Media Streams . . . . . . . . . . . . . . . . 59
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 13.2. Non-real-time Sessions . . . . . . . . . . . . . . . . . 61
14. Security Considerations . . . . . . . . . . . . . . . . . . . 66 14. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
14.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 66 15. Security Considerations . . . . . . . . . . . . . . . . . . . 66
14.2. Attacks on Server Reflexive Address Gathering . . . . . 68 15.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 66
14.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 69 15.2. Attacks on Server Reflexive Address Gathering . . . . . 69
14.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . 70 15.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 70
14.4.1. STUN Amplification Attack . . . . . . . . . . . . . 70 15.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . 70
15. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 71 15.4.1. STUN Amplification Attack . . . . . . . . . . . . . 70
15.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 71 16. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 71
15.2. New Error Response Codes . . . . . . . . . . . . . . . . 71 16.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 71
16. Operational Considerations . . . . . . . . . . . . . . . . . 71 16.2. New Error Response Codes . . . . . . . . . . . . . . . . 72
16.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 72 17. Operational Considerations . . . . . . . . . . . . . . . . . 72
16.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 72 17.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 72
16.2.1. STUN and TURN Server Capacity Planning . . . . . . . 72 17.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 72
16.2.2. Gathering and Connectivity Checks . . . . . . . . . 73 17.2.1. STUN and TURN Server Capacity Planning . . . . . . . 72
16.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 73 17.2.2. Gathering and Connectivity Checks . . . . . . . . . 73
16.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 73 17.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 73
16.4. Troubleshooting and Performance Management . . . . . . . 73 17.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 74
16.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 74 17.4. Troubleshooting and Performance Management . . . . . . . 74
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 17.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 74
17.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 74 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
17.2. STUN Error Responses . . . . . . . . . . . . . . . . . . 75 18.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 75
18. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75 18.2. STUN Error Responses . . . . . . . . . . . . . . . . . . 75
18.1. Problem Definition . . . . . . . . . . . . . . . . . . . 75 19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75
18.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 75 19.1. Problem Definition . . . . . . . . . . . . . . . . . . . 75
18.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 76 19.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 76
18.4. Requirements for a Long-Term Solution . . . . . . . . . 77 19.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 76
18.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 77 19.4. Requirements for a Long-Term Solution . . . . . . . . . 77
19. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 78 19.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 78
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 20. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 78
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
21.1. Normative References . . . . . . . . . . . . . . . . . . 78 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 79
21.2. Informative References . . . . . . . . . . . . . . . . . 79 22.1. Normative References . . . . . . . . . . . . . . . . . . 79
22.2. Informative References . . . . . . . . . . . . . . . . . 79
Appendix A. Lite and Full Implementations . . . . . . . . . . . 81 Appendix A. Lite and Full Implementations . . . . . . . . . . . 81
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 82 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 83
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 83 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 83
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 84 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 84
B.3. Purpose of the Related Address and Related Port B.3. Purpose of the Related Address and Related Port
Attributes . . . . . . . . . . . . . . . . . . . . . . . 86 Attributes . . . . . . . . . . . . . . . . . . . . . . . 86
B.4. Importance of the STUN Username . . . . . . . . . . . . . 86 B.4. Importance of the STUN Username . . . . . . . . . . . . . 86
B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 87 B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 87
B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 88 B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 88
B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 88 B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 88
B.8. Why Are Binding Indications Used for Keepalives? . . . . 89 B.8. Why Are Binding Indications Used for Keepalives? . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89
skipping to change at page 15, line 39 skipping to change at page 15, line 39
this specification to provide a stepping stone to full this specification to provide a stepping stone to full
implementation. Even for devices that are always connected to the implementation. Even for devices that are always connected to the
public Internet, a full implementation is preferable if achievable. public Internet, a full implementation is preferable if achievable.
2.8. Usages of ICE 2.8. Usages of ICE
This document specifies generic use of ICE with protocols that This document specifies generic use of ICE with protocols that
provide offer/answer semantics. The specific details (e.g., how to provide offer/answer semantics. The specific details (e.g., how to
encode candidates) for different protocols using ICE are described in encode candidates) for different protocols using ICE are described in
separate usage documents. For example, usage with SIP and SDP is separate usage documents. For example, usage with SIP and SDP is
described in [I-D.petithuguenin-mmusic-ice-sip-sdp]. described in [I-D.ietf-mmusic-ice-sip-sdp].
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
Readers should be familiar with the terminology defined in the offer/ Readers should be familiar with the terminology defined in the offer/
answer model [RFC3264], STUN [RFC5389], and NAT Behavioral answer model [RFC3264], STUN [RFC5389], and NAT Behavioral
requirements for UDP [RFC4787]. requirements for UDP [RFC4787].
This specification makes use of the following additional terminology: This specification makes use of the following additional terminology:
Agent: As defined in RFC 3264, an agent is the protocol Agent: An agent is the protocol implementation involved in the
implementation involved in the offer/answer exchange. There are offer/answer exchange. There are two agents involved in an offer/
two agents involved in an offer/answer exchange. answer exchange.
ICE offer/answer: The process where the ICE agents exchange
information (e.g., candidates and passwords) that is needed to
perform ICE. RFC 3264 offer/answer with SDP is one example of a
protocol that can be used for ICE offer and answer.
Peer: From the perspective of one of the agents in a session, its Peer: From the perspective of one of the agents in a session, its
peer is the other agent. Specifically, from the perspective of peer is the other agent. Specifically, from the perspective of
the offerer, the peer is the answerer. From the perspective of the offerer, the peer is the answerer. From the perspective of
the answerer, the peer is the offerer. the answerer, the peer is the offerer.
Transport Address: The combination of an IP address and transport Transport Address: The combination of an IP address and transport
protocol (such as UDP or TCP) port. protocol (such as UDP or TCP) port.
Media, Media Stream: When ICE is used to setup multimedia sessions, Media, Media Stream, Media Session: When ICE is used to setup
the media is usually transported over RTP, and a media stream multimedia sessions, the media is usually transported over RTP,
composes of a stream of RTP packets. When ICE is used with other and a media stream composes of a stream of RTP packets. When ICE
than multimedia sessions, the terms "media" and "media stream" are is used with other than multimedia sessions, the terms "media",
still used in this specification to refer to the IP data packets "media stream", and "media session" are still used in this
that are exchanged between the peers on the path created and specification to refer to the IP data packets that are exchanged
tested with ICE. between the peers on the path created and tested with ICE.
Candidate: A transport address that is a potential point of contact Candidate: A transport address that is a potential point of contact
for receipt of media. Candidates also have properties -- their for receipt of media. Candidates also have properties -- their
type (server reflexive, relayed, or host), priority, foundation, type (server reflexive, relayed, or host), priority, foundation,
and base. and base.
Component: A component is a piece of a media stream requiring a Component: A component is a piece of a media stream requiring a
single transport address; a media stream may require multiple single transport address; a media stream may require multiple
components, each of which has to work for the media stream as a components, each of which has to work for the media stream as a
whole to work. For media streams based on RTP, there are two whole to work. For media streams based on RTP, there are two
skipping to change at page 19, line 36 skipping to change at page 19, line 42
obtained by binding to ports (typically ephemeral) on a IP address obtained by binding to ports (typically ephemeral) on a IP address
attached to an interface (physical or virtual, including VPN attached to an interface (physical or virtual, including VPN
interfaces) on the host. interfaces) on the host.
For each UDP media stream the agent wishes to use, the agent SHOULD For each UDP media stream the agent wishes to use, the agent SHOULD
obtain a candidate for each component of the media stream on each IP obtain a candidate for each component of the media stream on each IP
address that the host has, with the exceptions listed below. The address that the host has, with the exceptions listed below. The
agent obtains each candidate by binding to a UDP port on the specific agent obtains each candidate by binding to a UDP port on the specific
IP address. A host candidate (and indeed every candidate) is always IP address. A host candidate (and indeed every candidate) is always
associated with a specific component for which it is a candidate. associated with a specific component for which it is a candidate.
Each component has an ID assigned to it, called the component ID. Each component has an ID assigned to it, called the component ID.
For RTP-based media streams, the RTP itself has a component ID of 1, For RTP-based media streams, the RTP itself has a component ID of 1,
and RTCP a component ID of 2. If an agent is using RTCP, it MUST and RTCP a component ID of 2. If an agent is using RTCP, it MUST
obtain a candidate for it. If an agent is using both RTP and RTCP, obtain a candidate for it. If an agent is using both RTP and RTCP,
it would end up with 2*K host candidates if an agent has K IP it would end up with 2*K host candidates if an agent has K IP
addresses. addresses. For other than RTP-based streams, if multiple components
are needed, the component IDs SHOULD start with 1 and increase by 1
for each component.
The base for each host candidate is set to the candidate itself. The base for each host candidate is set to the candidate itself.
The host candidates are gathered from all IP addresses with the The host candidates are gathered from all IP addresses with the
following exceptions: following exceptions:
o Addresses from a loopback interface MUST NOT be included in the o Addresses from a loopback interface MUST NOT be included in the
candidate addresses. candidate addresses.
o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site- o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site-
skipping to change at page 21, line 15 skipping to change at page 21, line 21
backwards compatibility mode for the Binding request defined in backwards compatibility mode for the Binding request defined in
[RFC5389]. Allocate requests SHOULD be authenticated using a long- [RFC5389]. Allocate requests SHOULD be authenticated using a long-
term credential obtained by the client through some other means. term credential obtained by the client through some other means.
Every Ta milliseconds thereafter, the agent can generate another new Every Ta milliseconds thereafter, the agent can generate another new
STUN or TURN transaction. This transaction can either be a retry of STUN or TURN transaction. This transaction can either be a retry of
a previous transaction that failed with a recoverable error (such as a previous transaction that failed with a recoverable error (such as
authentication failure), or a transaction for a new host candidate authentication failure), or a transaction for a new host candidate
and STUN or TURN server pair. The agent SHOULD NOT generate and STUN or TURN server pair. The agent SHOULD NOT generate
transactions more frequently than one every Ta milliseconds. See transactions more frequently than one every Ta milliseconds. See
Section 12 for guidance on how to set Ta and the STUN retransmit Section 13 for guidance on how to set Ta and the STUN retransmit
timer, RTO. timer, RTO.
The agent will receive a Binding or Allocate response. A successful The agent will receive a Binding or Allocate response. A successful
Allocate response will provide the agent with a server reflexive Allocate response will provide the agent with a server reflexive
candidate (obtained from the mapped address) and a relayed candidate candidate (obtained from the mapped address) and a relayed candidate
in the XOR-RELAYED-ADDRESS attribute. If the Allocate request is in the XOR-RELAYED-ADDRESS attribute. If the Allocate request is
rejected because the server lacks resources to fulfill it, the agent rejected because the server lacks resources to fulfill it, the agent
SHOULD instead send a Binding request to obtain a server reflexive SHOULD instead send a Binding request to obtain a server reflexive
candidate. A Binding response will provide the agent with only a candidate. A Binding response will provide the agent with only a
server reflexive candidate (also obtained from the mapped address). server reflexive candidate (also obtained from the mapped address).
skipping to change at page 27, line 49 skipping to change at page 28, line 4
If an agent is a lite implementation, it MUST indicate this in the If an agent is a lite implementation, it MUST indicate this in the
offer. offer.
ICE provides for extensibility by allowing an offer or answer to ICE provides for extensibility by allowing an offer or answer to
contain a series of tokens that identify the ICE extensions used by contain a series of tokens that identify the ICE extensions used by
that agent. If an agent supports an ICE extension, it MUST include that agent. If an agent supports an ICE extension, it MUST include
the token defined for that extension in the offer. the token defined for that extension in the offer.
Once an agent has sent its offer or its answer, that agent MUST be Once an agent has sent its offer or its answer, that agent MUST be
prepared to receive both STUN and media packets on each candidate. prepared to receive both STUN and media packets on each candidate.
As discussed in Section 10.1, media packets can be sent to a
As discussed in Section 11.1, media packets can be sent to a
candidate prior to its appearance as the default destination for candidate prior to its appearance as the default destination for
media in an offer or answer. media in an offer or answer.
5. Receiving the Initial Offer 5. Receiving the Initial Offer
When an agent receives an initial offer, it will check if the offerer When an agent receives an initial offer, it will check if the offerer
supports ICE, determine its own role, gather candidates, prioritize supports ICE, determine its own role, gather candidates, prioritize
them, choose default candidates, encode and send an answer, and for them, choose default candidates, encode and send an answer, and for
full implementations, form the check lists and begin connectivity full implementations, form the check lists and begin connectivity
checks. checks.
skipping to change at page 30, line 21 skipping to change at page 30, line 21
offer/answer exchange. To form the check list for a media stream, offer/answer exchange. To form the check list for a media stream,
the agent forms candidate pairs, computes a candidate pair priority, the agent forms candidate pairs, computes a candidate pair priority,
orders the pairs by priority, prunes them, and sets their states. orders the pairs by priority, prunes them, and sets their states.
These steps are described in this section. These steps are described in this section.
5.6.1. Forming Candidate Pairs 5.6.1. Forming Candidate Pairs
First, the agent takes each of its candidates for a media stream First, the agent takes each of its candidates for a media stream
(called LOCAL CANDIDATES) and pairs them with the candidates it (called LOCAL CANDIDATES) and pairs them with the candidates it
received from its peer (called REMOTE CANDIDATES) for that media received from its peer (called REMOTE CANDIDATES) for that media
stream. In order to prevent the attacks described in Section 14.4.1, stream. In order to prevent the attacks described in Section 15.4.1,
agents MAY limit the number of candidates they'll accept in an offer agents MAY limit the number of candidates they'll accept in an offer
or answer. A local candidate is paired with a remote candidate if or answer. A local candidate is paired with a remote candidate if
and only if the two candidates have the same component ID and have and only if the two candidates have the same component ID and have
the same IP address version. It is possible that some of the local the same IP address version. It is possible that some of the local
candidates won't get paired with remote candidates, and some of the candidates won't get paired with remote candidates, and some of the
remote candidates won't get paired with local candidates. This can remote candidates won't get paired with local candidates. This can
happen if one agent doesn't include candidates for the all of the happen if one agent doesn't include candidates for the all of the
components for a media stream. If this happens, the number of components for a media stream. If this happens, the number of
components for that media stream is effectively reduced, and components for that media stream is effectively reduced, and
considered to be equal to the minimum across both agents of the considered to be equal to the minimum across both agents of the
skipping to change at page 32, line 5 skipping to change at page 32, line 5
default candidates for a particular component is called, default candidates for a particular component is called,
unsurprisingly, the default candidate pair for that component. This unsurprisingly, the default candidate pair for that component. This
is the pair that would be used to transmit media if both agents had is the pair that would be used to transmit media if both agents had
not been ICE aware. not been ICE aware.
In order to aid understanding, Figure 6 shows the relationships In order to aid understanding, Figure 6 shows the relationships
between several key concepts -- transport addresses, candidates, between several key concepts -- transport addresses, candidates,
candidate pairs, and check lists, in addition to indicating the main candidate pairs, and check lists, in addition to indicating the main
properties of candidates and candidate pairs. properties of candidates and candidate pairs.
+------------------------------------------+ +--------------------------------------------+
| | | |
| +---------------------+ | | +---------------------+ |
| |+----+ +----+ +----+ | +Type | | |+----+ +----+ +----+ | +Type |
| || IP | |Port| |Tran| | +Priority | | || IP | |Port| |Tran| | +Priority |
| ||Addr| | | | | | +Foundation | | ||Addr| | | | | | +Foundation |
| |+----+ +----+ +----+ | +ComponentiD | | |+----+ +----+ +----+ | +Component ID |
| | Transport | +RelatedAddr | | | Transport | +Related Address |
| | Addr | | | | Addr | |
| +---------------------+ +Base | | +---------------------+ +Base |
| Candidate | | Candidate |
+------------------------------------------+ +--------------------------------------------+
* * * *
* ************************************* * *************************************
* * * *
+-------------------------------+ +-------------------------------+
.| | .| |
| Local Remote | | Local Remote |
| +----+ +----+ +default? | | +----+ +----+ +default? |
| |Cand| |Cand| +valid? | | |Cand| |Cand| +valid? |
| +----+ +----+ +nominated?| | +----+ +----+ +nominated?|
| +State | | +State |
skipping to change at page 33, line 35 skipping to change at page 33, line 35
candidate, but only from its base, the agent next goes through the candidate, but only from its base, the agent next goes through the
sorted list of candidate pairs. For each pair where the local sorted list of candidate pairs. For each pair where the local
candidate is server reflexive, the server reflexive candidate MUST be candidate is server reflexive, the server reflexive candidate MUST be
replaced by its base. Once this has been done, the agent MUST prune replaced by its base. Once this has been done, the agent MUST prune
the list. This is done by removing a pair if its local and remote the list. This is done by removing a pair if its local and remote
candidates are identical to the local and remote candidates of a pair candidates are identical to the local and remote candidates of a pair
higher up on the priority list. The result is a sequence of ordered higher up on the priority list. The result is a sequence of ordered
candidate pairs, called the check list for that media stream. candidate pairs, called the check list for that media stream.
In addition, in order to limit the attacks described in In addition, in order to limit the attacks described in
Section 14.4.1, an agent MUST limit the total number of connectivity Section 15.4.1, an agent MUST limit the total number of connectivity
checks the agent performs across all check lists to a specific value, checks the agent performs across all check lists to a specific value,
and this value MUST be configurable. A default of 100 is and this value MUST be configurable. A default of 100 is
RECOMMENDED. This limit is enforced by discarding the lower-priority RECOMMENDED. This limit is enforced by discarding the lower-priority
candidate pairs until there are less than 100. It is RECOMMENDED candidate pairs until there are less than 100. It is RECOMMENDED
that a lower value be utilized when possible, set to the maximum that a lower value be utilized when possible, set to the maximum
number of plausible checks that might be seen in an actual deployment number of plausible checks that might be seen in an actual deployment
configuration. The requirement for configuration is meant to provide configuration. The requirement for configuration is meant to provide
a tool for fixing this value in the field if, once deployed, it is a tool for fixing this value in the field if, once deployed, it is
found to be problematic. found to be problematic.
skipping to change at page 37, line 15 skipping to change at page 37, line 15
there are no pairs in the triggered check queue, an ordinary check is there are no pairs in the triggered check queue, an ordinary check is
sent. sent.
Once the agent has computed the check lists as described in Once the agent has computed the check lists as described in
Section 5.6, it sets a timer for each active check list. The timer Section 5.6, it sets a timer for each active check list. The timer
fires every Ta*N seconds, where N is the number of active check lists fires every Ta*N seconds, where N is the number of active check lists
(initially, there is only one active check list). Implementations (initially, there is only one active check list). Implementations
MAY set the timer to fire less frequently than this. Implementations MAY set the timer to fire less frequently than this. Implementations
SHOULD take care to spread out these timers so that they do not fire SHOULD take care to spread out these timers so that they do not fire
at the same time for each media stream. Ta and the retransmit timer at the same time for each media stream. Ta and the retransmit timer
RTO are computed as described in Section 12. Multiplying by N allows RTO are computed as described in Section 13. Multiplying by N allows
this aggregate check throughput to be split between all active check this aggregate check throughput to be split between all active check
lists. The first timer fires immediately, so that the agent performs lists. The first timer fires immediately, so that the agent performs
a connectivity check the moment the offer/answer exchange has been a connectivity check the moment the offer/answer exchange has been
done, followed by the next check Ta seconds later (since there is done, followed by the next check Ta seconds later (since there is
only one active check list). only one active check list).
When the timer fires and there is no triggered check to be sent, the When the timer fires and there is no triggered check to be sent, the
agent MUST choose an ordinary check as follows: agent MUST choose an ordinary check as follows:
o Find the highest-priority pair in that check list that is in the o Find the highest-priority pair in that check list that is in the
skipping to change at page 39, line 38 skipping to change at page 39, line 38
A connectivity check is generated by sending a Binding request from a A connectivity check is generated by sending a Binding request from a
local candidate to a remote candidate. [RFC5389] describes how local candidate to a remote candidate. [RFC5389] describes how
Binding requests are constructed and generated. A connectivity check Binding requests are constructed and generated. A connectivity check
MUST utilize the STUN short-term credential mechanism. Support for MUST utilize the STUN short-term credential mechanism. Support for
backwards compatibility with RFC 3489 MUST NOT be used or assumed backwards compatibility with RFC 3489 MUST NOT be used or assumed
with connectivity checks. The FINGERPRINT mechanism MUST be used for with connectivity checks. The FINGERPRINT mechanism MUST be used for
connectivity checks. connectivity checks.
ICE extends STUN by defining several new attributes, including ICE extends STUN by defining several new attributes, including
PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. These PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. These
new attributes are formally defined in Section 15.1, and their usage new attributes are formally defined in Section 16.1, and their usage
is described in the subsections below. These STUN extensions are is described in the subsections below. These STUN extensions are
applicable only to connectivity checks used for ICE. applicable only to connectivity checks used for ICE.
7.1.2.1. PRIORITY and USE-CANDIDATE 7.1.2.1. PRIORITY and USE-CANDIDATE
An agent MUST include the PRIORITY attribute in its Binding request. An agent MUST include the PRIORITY attribute in its Binding request.
The attribute MUST be set equal to the priority that would be The attribute MUST be set equal to the priority that would be
assigned, based on the algorithm in Section 4.1.2, to a peer assigned, based on the algorithm in Section 4.1.2, to a peer
reflexive candidate, should one be learned as a consequence of this reflexive candidate, should one be learned as a consequence of this
check (see Section 7.1.3.2.1 for how peer reflexive candidates are check (see Section 7.1.3.2.1 for how peer reflexive candidates are
skipping to change at page 40, line 19 skipping to change at page 40, line 19
resulting from the check for this component. Section 8.1.1 provides resulting from the check for this component. Section 8.1.1 provides
guidance on determining when to include it. guidance on determining when to include it.
7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING 7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING
The agent MUST include the ICE-CONTROLLED attribute in the request if The agent MUST include the ICE-CONTROLLED attribute in the request if
it is in the controlled role, and MUST include the ICE-CONTROLLING it is in the controlled role, and MUST include the ICE-CONTROLLING
attribute in the request if it is in the controlling role. The attribute in the request if it is in the controlling role. The
content of either attribute MUST be the tie-breaker that was content of either attribute MUST be the tie-breaker that was
determined in Section 5.2. These attributes are defined fully in determined in Section 5.2. These attributes are defined fully in
Section 15.1. Section 16.1.
7.1.2.3. Forming Credentials 7.1.2.3. Forming Credentials
A Binding request serving as a connectivity check MUST utilize the A Binding request serving as a connectivity check MUST utilize the
STUN short-term credential mechanism. The username for the STUN short-term credential mechanism. The username for the
credential is formed by concatenating the username fragment provided credential is formed by concatenating the username fragment provided
by the peer with the username fragment of the agent sending the by the peer with the username fragment of the agent sending the
request, separated by a colon (":"). The password is equal to the request, separated by a colon (":"). The password is equal to the
password provided by the peer. For example, consider the case where password provided by the peer. For example, consider the case where
agent L is the offerer, and agent R is the answerer. Agent L agent L is the offerer, and agent R is the answerer. Agent L
skipping to change at page 51, line 5 skipping to change at page 51, line 5
to be set. Consequently, there will be only a single nominated pair to be set. Consequently, there will be only a single nominated pair
in the valid list for each component, and when the state of the check in the valid list for each component, and when the state of the check
list moves to completed, that exact pair is selected by ICE for list moves to completed, that exact pair is selected by ICE for
sending and receiving media for that component. sending and receiving media for that component.
Regular nomination provides the most flexibility, since the agent has Regular nomination provides the most flexibility, since the agent has
control over the stopping and selection criteria for checks. The control over the stopping and selection criteria for checks. The
only requirement is that the agent MUST eventually pick one and only only requirement is that the agent MUST eventually pick one and only
one candidate pair and generate a check for that pair with the USE- one candidate pair and generate a check for that pair with the USE-
CANDIDATE attribute present. Regular nomination also improves ICE's CANDIDATE attribute present. Regular nomination also improves ICE's
resilience to variations in implementation (see Section 11). Regular resilience to variations in implementation (see Section 12). Regular
nomination is also more stable, allowing both agents to converge on a nomination is also more stable, allowing both agents to converge on a
single pair for media without any transient selections, which can single pair for media without any transient selections, which can
happen with the aggressive algorithm. The drawback of regular happen with the aggressive algorithm. The drawback of regular
nomination is that it is guaranteed to increase latencies because it nomination is that it is guaranteed to increase latencies because it
requires an additional check to be done. requires an additional check to be done.
8.1.1.2. Aggressive Nomination 8.1.1.2. Aggressive Nomination
With aggressive nomination, the controlling agent includes the USE- With aggressive nomination, the controlling agent includes the USE-
CANDIDATE attribute in every check it sends. Once the first check CANDIDATE attribute in every check it sends. Once the first check
skipping to change at page 52, line 32 skipping to change at page 52, line 32
list for that media stream to Completed. list for that media stream to Completed.
* The agent MUST continue to respond to any checks it may still * The agent MUST continue to respond to any checks it may still
receive for that media stream, and MUST perform triggered receive for that media stream, and MUST perform triggered
checks if required by the processing of Section 7.2. checks if required by the processing of Section 7.2.
* The agent MUST continue retransmitting any In-Progress checks * The agent MUST continue retransmitting any In-Progress checks
for that check list. for that check list.
* The agent MAY begin transmitting media for this media stream as * The agent MAY begin transmitting media for this media stream as
described in Section 10.1. described in Section 11.1.
o Once the state of each check list is Completed: o Once the state of each check list is Completed:
* The agent sets the state of ICE processing overall to * The agent sets the state of ICE processing overall to
Completed. Completed.
* If the controlling agent is using an aggressive nomination * If the controlling agent is using an aggressive nomination
algorithm, this may result in several updated offers as the algorithm, this may result in several updated offers as the
pairs selected for media change. An agent MAY delay sending pairs selected for media change. An agent MAY delay sending
the offer for a brief interval (one second is RECOMMENDED) in the offer for a brief interval (one second is RECOMMENDED) in
skipping to change at page 54, line 16 skipping to change at page 54, line 16
case for implementations that are IPv4-only. case for implementations that are IPv4-only.
o If there is more than one pair per component: o If there is more than one pair per component:
* The agent MUST select a pair based on local policy. Since this * The agent MUST select a pair based on local policy. Since this
case only arises for IPv6, it is RECOMMENDED that an agent case only arises for IPv6, it is RECOMMENDED that an agent
follow the procedures of RFC 6724 [RFC6724] to select a single follow the procedures of RFC 6724 [RFC6724] to select a single
pair. pair.
* The agent adds the selected pair for each component to the * The agent adds the selected pair for each component to the
valid list. As described in Section 10.1, this will permit valid list. As described in Section 11.1, this will permit
media to begin flowing. However, it is possible (and in fact media to begin flowing. However, it is possible (and in fact
likely) that both agents have chosen different pairs. likely) that both agents have chosen different pairs.
* To reconcile this, the controlling agent MUST send an updated * To reconcile this, the controlling agent MUST send an updated
offer which will include the remote-candidates attribute. offer which will include the remote-candidates attribute.
* The agent MUST NOT update the state of ICE processing when the * The agent MUST NOT update the state of ICE processing when the
offer is sent. If this subsequent offer completes, the offer is sent. If this subsequent offer completes, the
controlling agent MUST change the state of ICE processing to controlling agent MUST change the state of ICE processing to
Completed for all media streams, and the state of ICE Completed for all media streams, and the state of ICE
skipping to change at page 54, line 46 skipping to change at page 54, line 46
rules in this section describe when it is safe for an agent to cease rules in this section describe when it is safe for an agent to cease
sending or receiving checks on a candidate that was not selected by sending or receiving checks on a candidate that was not selected by
ICE, and then free the candidate. ICE, and then free the candidate.
8.3.2. Lite Implementation Procedures 8.3.2. Lite Implementation Procedures
A lite implementation MAY free candidates not selected by ICE as soon A lite implementation MAY free candidates not selected by ICE as soon
as ICE processing has reached the Completed state for all peers for as ICE processing has reached the Completed state for all peers for
all media streams using those candidates. all media streams using those candidates.
9. Keepalives 9. ICE Restarts
An agent MAY restart ICE processing for an existing media stream. An
ICE restart, as the name implies, will cause all previous states of
ICE processing to be flushed and checks to start anew. The only
difference between an ICE restart and a brand new media session is
that, during the restart, media can continue to be sent to the
previously validated pair.
An agent MUST restart ICE for a media stream if:
o The offer is being generated for the purposes of changing the
target of the media stream. In other words, if an agent wants to
generate an updated offer that, had ICE not been in use, would
result in a new value for the destination of a media component.
o An agent is changing its implementation level. This typically
only happens in third party call control use cases, where the
entity performing the signaling is not the entity receiving the
media, and it has changed the target of media mid-session to
another entity that has a different ICE implementation.
To restart ICE, an agent MUST change both the password and the user
name fragment for the media stream in an offer. The set of
candidates in the new offer MAY include some, none, or all of the
previous candidates for that stream and MAY include a totally new set
of candidates
10. Keepalives
All endpoints MUST send keepalives for each media session. These All endpoints MUST send keepalives for each media session. These
keepalives serve the purpose of keeping NAT bindings alive for the keepalives serve the purpose of keeping NAT bindings alive for the
media session. These keepalives MUST be sent even if ICE is not media session. These keepalives MUST be sent even if ICE is not
being utilized for the session at all. The keepalive SHOULD be sent being utilized for the session at all. The keepalive SHOULD be sent
using a format that is supported by its peer. ICE endpoints allow using a format that is supported by its peer. ICE endpoints allow
for STUN-based keepalives for UDP streams, and as such, STUN for STUN-based keepalives for UDP streams, and as such, STUN
keepalives MUST be used when an agent is a full ICE implementation keepalives MUST be used when an agent is a full ICE implementation
and is communicating with a peer that supports ICE (lite or full). and is communicating with a peer that supports ICE (lite or full).
If the peer does not support ICE, the choice of a packet format for If the peer does not support ICE, the choice of a packet format for
skipping to change at page 55, line 47 skipping to change at page 56, line 27
an agent MUST be prepared to receive a connectivity check as well. an agent MUST be prepared to receive a connectivity check as well.
If a connectivity check is received, a response is generated as If a connectivity check is received, a response is generated as
discussed in [RFC5389], but there is no impact on ICE processing discussed in [RFC5389], but there is no impact on ICE processing
otherwise. otherwise.
An agent MUST begin the keepalive processing once ICE has selected An agent MUST begin the keepalive processing once ICE has selected
candidates for usage with media, or media begins to flow, whichever candidates for usage with media, or media begins to flow, whichever
happens first. Keepalives end once the session terminates or the happens first. Keepalives end once the session terminates or the
media stream is removed. media stream is removed.
10. Media Handling 11. Media Handling
10.1. Sending Media
11.1. Sending Media
Procedures for sending media differ for full and lite Procedures for sending media differ for full and lite
implementations. implementations.
10.1.1. Procedures for Full Implementations 11.1.1. Procedures for Full Implementations
Agents always send media using a candidate pair, called the selected Agents always send media using a candidate pair, called the selected
candidate pair. An agent will send media to the remote candidate in candidate pair. An agent will send media to the remote candidate in
the selected pair (setting the destination address and port of the the selected pair (setting the destination address and port of the
packet equal to that remote candidate), and will send it from the packet equal to that remote candidate), and will send it from the
local candidate of the selected pair. When the local candidate is local candidate of the selected pair. When the local candidate is
server or peer reflexive, media is originated from the base. Media server or peer reflexive, media is originated from the base. Media
sent from a relayed candidate is sent from the base through that TURN sent from a relayed candidate is sent from the base through that TURN
server, using procedures defined in [RFC5766]. server, using procedures defined in [RFC5766].
skipping to change at page 56, line 45 skipping to change at page 57, line 23
o equal to the highest-priority nominated pair for that component in o equal to the highest-priority nominated pair for that component in
the valid list if the state of the check list is Completed the valid list if the state of the check list is Completed
If the selected pair for at least one component of a media stream is If the selected pair for at least one component of a media stream is
empty, an agent MUST NOT send media for any component of that media empty, an agent MUST NOT send media for any component of that media
stream. If the selected pair for each component of a media stream stream. If the selected pair for each component of a media stream
has a value, an agent MAY send media for all components of that media has a value, an agent MAY send media for all components of that media
stream. stream.
10.1.2. Procedures for Lite Implementations 11.1.2. Procedures for Lite Implementations
A lite implementation MUST NOT send media until it has a Valid list A lite implementation MUST NOT send media until it has a Valid list
that contains a candidate pair for each component of that media that contains a candidate pair for each component of that media
stream. Once that happens, the agent MAY begin sending media stream. Once that happens, the agent MAY begin sending media
packets. To do that, it sends media to the remote candidate in the packets. To do that, it sends media to the remote candidate in the
pair (setting the destination address and port of the packet equal to pair (setting the destination address and port of the packet equal to
that remote candidate), and will send it from the local candidate. that remote candidate), and will send it from the local candidate.
10.1.3. Procedures for All Implementations 11.1.3. Procedures for All Implementations
ICE has interactions with jitter buffer adaptation mechanisms. An ICE has interactions with jitter buffer adaptation mechanisms. An
RTP stream can begin using one candidate, and switch to another one, RTP stream can begin using one candidate, and switch to another one,
though this happens rarely with ICE. The newer candidate may result though this happens rarely with ICE. The newer candidate may result
in RTP packets taking a different path through the network -- one in RTP packets taking a different path through the network -- one
with different delay characteristics. As discussed below, agents are with different delay characteristics. As discussed below, agents are
encouraged to re-adjust jitter buffers when there are changes in encouraged to re-adjust jitter buffers when there are changes in
source or destination address of media packets. Furthermore, many source or destination address of media packets. Furthermore, many
audio codecs use the marker bit to signal the beginning of a audio codecs use the marker bit to signal the beginning of a
talkspurt, for the purposes of jitter buffer adaptation. For such talkspurt, for the purposes of jitter buffer adaptation. For such
codecs, it is RECOMMENDED that the sender set the marker bit codecs, it is RECOMMENDED that the sender set the marker bit
[RFC3550] when an agent switches transmission of media from one [RFC3550] when an agent switches transmission of media from one
candidate pair to another. candidate pair to another.
10.2. Receiving Media 11.2. Receiving Media
ICE implementations MUST be prepared to receive media on each ICE implementations MUST be prepared to receive media on each
component on any candidates provided for that component in the most component on any candidates provided for that component in the most
recent offer/answer exchange (in the case of RTP, this would include recent offer/answer exchange (in the case of RTP, this would include
both RTP and RTCP if candidates were provided for both). both RTP and RTCP if candidates were provided for both).
It is RECOMMENDED that, when an agent receives an RTP packet with a It is RECOMMENDED that, when an agent receives an RTP packet with a
new source or destination IP address for a particular media stream, new source or destination IP address for a particular media stream,
that the agent re-adjust its jitter buffers. that the agent re-adjust its jitter buffers.
skipping to change at page 57, line 44 skipping to change at page 58, line 20
detecting synchronization source (SSRC) collisions and loops. These detecting synchronization source (SSRC) collisions and loops. These
algorithms are based, in part, on seeing different source transport algorithms are based, in part, on seeing different source transport
addresses with the same SSRC. However, when ICE is used, such addresses with the same SSRC. However, when ICE is used, such
changes will sometimes occur as the media streams switch between changes will sometimes occur as the media streams switch between
candidates. An agent will be able to determine that a media stream candidates. An agent will be able to determine that a media stream
is from the same peer as a consequence of the STUN exchange that is from the same peer as a consequence of the STUN exchange that
proceeds media transmission. Thus, if there is a change in source proceeds media transmission. Thus, if there is a change in source
transport address, but the media packets come from the same peer transport address, but the media packets come from the same peer
agent, this SHOULD NOT be treated as an SSRC collision. agent, this SHOULD NOT be treated as an SSRC collision.
11. Extensibility Considerations 12. Extensibility Considerations
This specification makes very specific choices about how both agents This specification makes very specific choices about how both agents
in a session coordinate to arrive at the set of candidate pairs that in a session coordinate to arrive at the set of candidate pairs that
are selected for media. It is anticipated that future specifications are selected for media. It is anticipated that future specifications
will want to alter these algorithms, whether they are simple changes will want to alter these algorithms, whether they are simple changes
like timer tweaks or larger changes like a revamp of the priority like timer tweaks or larger changes like a revamp of the priority
algorithm. When such a change is made, providing interoperability algorithm. When such a change is made, providing interoperability
between the two agents in a session is critical. between the two agents in a session is critical.
First, ICE provides the ice-options attribute. Each extension or First, ICE provides the ice-options attribute. Each extension or
skipping to change at page 58, line 38 skipping to change at page 59, line 12
by both agents. Consequently, any future ICE enhancements MUST by both agents. Consequently, any future ICE enhancements MUST
preserve triggered checks. preserve triggered checks.
ICE is also extensible to other media streams beyond RTP, and for ICE is also extensible to other media streams beyond RTP, and for
transport protocols beyond UDP. Extensions to ICE for non-RTP media transport protocols beyond UDP. Extensions to ICE for non-RTP media
streams need to specify how many components they utilize, and assign streams need to specify how many components they utilize, and assign
component IDs to them, starting at 1 for the most important component component IDs to them, starting at 1 for the most important component
ID. Specifications for new transport protocols must define how, if ID. Specifications for new transport protocols must define how, if
at all, various steps in the ICE processing differ from UDP. at all, various steps in the ICE processing differ from UDP.
12. Setting Ta and RTO 13. Setting Ta and RTO
During the gathering phase of ICE (Section 4.1.1) and while ICE is During the gathering phase of ICE (Section 4.1.1) and while ICE is
performing connectivity checks (Section 7), an agent sends STUN and performing connectivity checks (Section 7), an agent sends STUN and
TURN transactions. These transactions are paced at a rate of one TURN transactions. These transactions are paced at a rate of one
every Ta milliseconds, and utilize a specific RTO. This section every Ta milliseconds, and utilize a specific RTO. This section
describes how the values of Ta and RTO are computed. This describes how the values of Ta and RTO are computed. This
computation depends on whether ICE is being used with a real-time computation depends on whether ICE is being used with a real-time
media stream (such as RTP) or something else. When ICE is used for a media stream (such as RTP) or something else. When ICE is used for a
stream with a known maximum bandwidth, the computation in stream with a known maximum bandwidth, the computation in
Section 12.1 MAY be followed to rate-control the ICE exchanges. For Section 13.1 MAY be followed to rate-control the ICE exchanges. For
all other streams, the computation in Section 12.2 MUST be followed. all other streams, the computation in Section 13.2 MUST be followed.
12.1. Real-time Media Streams 13.1. Real-time Media Streams
The values of RTO and Ta change during the lifetime of ICE The values of RTO and Ta change during the lifetime of ICE
processing. One set of values applies during the gathering phase, processing. One set of values applies during the gathering phase,
and the other, for connectivity checks. and the other, for connectivity checks.
The value of Ta SHOULD be configurable, and SHOULD have a default of: The value of Ta SHOULD be configurable, and SHOULD have a default of:
For each media stream i: For each media stream i:
Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime
skipping to change at page 60, line 38 skipping to change at page 61, line 9
maintains a nicely constant rate, but becomes more sensitive to maintains a nicely constant rate, but becomes more sensitive to
packet loss. The loss of the first single packet for any packet loss. The loss of the first single packet for any
connectivity check is likely to cause that pair to take a long time connectivity check is likely to cause that pair to take a long time
to be validated, and instead, a lower-priority check (but one for to be validated, and instead, a lower-priority check (but one for
which there was no packet loss) is much more likely to complete which there was no packet loss) is much more likely to complete
first. This results in ICE performing sub-optimally, choosing lower- first. This results in ICE performing sub-optimally, choosing lower-
priority pairs over higher-priority pairs. Implementors should be priority pairs over higher-priority pairs. Implementors should be
aware of this consequence, but still should utilize the timer values aware of this consequence, but still should utilize the timer values
described here. described here.
12.2. Non-real-time Sessions 13.2. Non-real-time Sessions
In cases where ICE is used to establish some kind of session that is In cases where ICE is used to establish some kind of session that is
not real time, and has no fixed rate associated with it that is known not real time, and has no fixed rate associated with it that is known
to work on the network in which ICE is deployed, Ta and RTO revert to to work on the network in which ICE is deployed, Ta and RTO revert to
more conservative values. Ta SHOULD be configurable, SHOULD have a more conservative values. Ta SHOULD be configurable, SHOULD have a
default of 500 ms, and MUST NOT be configurable to be less than 500 default of 500 ms, and MUST NOT be configurable to be less than 500
ms. ms.
If other Ta value than the default is used, the agent MUST indicate If other Ta value than the default is used, the agent MUST indicate
the value it prefers to use in the ICE exchange. Both agents MUST the value it prefers to use in the ICE exchange. Both agents MUST
skipping to change at page 61, line 19 skipping to change at page 61, line 36
RTO = MAX (500ms, Ta * (number of pairs)) RTO = MAX (500ms, Ta * (number of pairs))
where the number of pairs refers to the number of pairs of candidates where the number of pairs refers to the number of pairs of candidates
with STUN or TURN servers. with STUN or TURN servers.
For connectivity checks, RTO SHOULD be configurable and SHOULD have a For connectivity checks, RTO SHOULD be configurable and SHOULD have a
default of: default of:
RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress)) RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
13. Example 14. Example
The example is based on the simplified topology of Figure 8. The example is based on the simplified topology of Figure 8.
+-------+ +-------+
|STUN | |STUN |
|Server | |Server |
+-------+ +-------+
| |
+---------------------+ +---------------------+
| | | |
skipping to change at page 66, line 5 skipping to change at page 66, line 31
agent L's server reflexive candidate. This check (messages 14-17) agent L's server reflexive candidate. This check (messages 14-17)
will succeed. Consequently, agent R constructs a new candidate pair will succeed. Consequently, agent R constructs a new candidate pair
using the mapped address from the response as the local candidate (R- using the mapped address from the response as the local candidate (R-
PUB-1) and the destination of the request (NAT-PUB-1) as the remote PUB-1) and the destination of the request (NAT-PUB-1) as the remote
candidate. This pair is added to the Valid list for that media candidate. This pair is added to the Valid list for that media
stream. Since the check was generated in the reverse direction of a stream. Since the check was generated in the reverse direction of a
check that contained the USE-CANDIDATE attribute, the candidate pair check that contained the USE-CANDIDATE attribute, the candidate pair
is marked as selected. Consequently, processing for this stream is marked as selected. Consequently, processing for this stream
moves into the Completed state, and agent R can also send media. moves into the Completed state, and agent R can also send media.
14. Security Considerations 15. Security Considerations
There are several types of attacks possible in an ICE system. This There are several types of attacks possible in an ICE system. This
section considers these attacks and their countermeasures. These section considers these attacks and their countermeasures. These
countermeasures include: countermeasures include:
o Using ICE in conjunction with secure signaling techniques, such as o Using ICE in conjunction with secure signaling techniques, such as
SIPS. SIPS.
o Limiting the total number of connectivity checks to 100, and o Limiting the total number of connectivity checks to 100, and
optionally limiting the number of candidates they'll accept in an optionally limiting the number of candidates they'll accept in an
offer or answer. offer or answer.
14.1. Attacks on Connectivity Checks 15.1. Attacks on Connectivity Checks
An attacker might attempt to disrupt the STUN connectivity checks. An attacker might attempt to disrupt the STUN connectivity checks.
Ultimately, all of these attacks fool an agent into thinking Ultimately, all of these attacks fool an agent into thinking
something incorrect about the results of the connectivity checks. something incorrect about the results of the connectivity checks.
The possible false conclusions an attacker can try and cause are: The possible false conclusions an attacker can try and cause are:
False Invalid: An attacker can fool a pair of agents into thinking a 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 candidate pair is invalid, when it isn't. This can be used to
cause an agent to prefer a different candidate (such as one cause an agent to prefer a different candidate (such as one
injected by the attacker) or to disrupt a call by forcing all injected by the attacker) or to disrupt a call by forcing all
skipping to change at page 68, line 35 skipping to change at page 69, line 12
If the attacker itself is identified by the fake candidate, the If the attacker itself is identified by the fake candidate, the
attack is easier to coordinate. However, if the media path is attack is easier to coordinate. However, if the media path is
secured (e.g., using SRTP [RFC3711]), the attacker will not be able secured (e.g., using SRTP [RFC3711]), the attacker will not be able
to play the media packets, but will only be able to discard them, to play the media packets, but will only be able to discard them,
effectively disabling the media stream for the call. However, this effectively disabling the media stream for the call. However, this
attack requires the agent to disrupt packets in order to block the attack requires the agent to disrupt packets in order to block the
connectivity check from reaching the target. In that case, if the connectivity check from reaching the target. In that case, if the
goal is to disrupt the media stream, it's much easier to just disrupt goal is to disrupt the media stream, it's much easier to just disrupt
it with the same mechanism, rather than attack ICE. it with the same mechanism, rather than attack ICE.
14.2. Attacks on Server Reflexive Address Gathering 15.2. Attacks on Server Reflexive Address Gathering
ICE endpoints make use of STUN Binding requests for gathering server ICE endpoints make use of STUN Binding requests for gathering server
reflexive candidates from a STUN server. These requests are not reflexive candidates from a STUN server. These requests are not
authenticated in any way. As a consequence, there are numerous authenticated in any way. As a consequence, there are numerous
techniques an attacker can employ to provide the client with a false techniques an attacker can employ to provide the client with a false
server reflexive candidate: server reflexive candidate:
o An attacker can compromise the DNS, causing DNS queries to return o An attacker can compromise the DNS, causing DNS queries to return
a rogue STUN server address. That server can provide the client a rogue STUN server address. That server can provide the client
with fake server reflexive candidates. This attack is mitigated with fake server reflexive candidates. This attack is mitigated
skipping to change at page 69, line 28 skipping to change at page 70, line 5
If the attacker elects not to attack the connectivity checks, the If the attacker elects not to attack the connectivity checks, the
worst it can do is prevent the server reflexive candidate from being 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 used. However, if the peer agent has at least one candidate that is
reachable by the agent under attack, the STUN connectivity checks reachable by the agent under attack, the STUN connectivity checks
themselves will provide a peer reflexive candidate that can be used themselves will provide a peer reflexive candidate that can be used
for the exchange of media. Peer reflexive candidates are generally for the exchange of media. Peer reflexive candidates are generally
preferred over server reflexive candidates. As such, an attack preferred over server reflexive candidates. As such, an attack
solely on the STUN address gathering will normally have no impact on solely on the STUN address gathering will normally have no impact on
a session at all. a session at all.
14.3. Attacks on Relayed Candidate Gathering 15.3. Attacks on Relayed Candidate Gathering
An attacker might attempt to disrupt the gathering of relayed An attacker might attempt to disrupt the gathering of relayed
candidates, forcing the client to believe it has a false relayed candidates, forcing the client to believe it has a false relayed
candidate. Exchanges with the TURN server are authenticated using a candidate. Exchanges with the TURN server are authenticated using a
long-term credential. Consequently, injection of fake responses or long-term credential. Consequently, injection of fake responses or
requests will not work. In addition, unlike Binding requests, requests will not work. In addition, unlike Binding requests,
Allocate requests are not susceptible to replay attacks with modified Allocate requests are not susceptible to replay attacks with modified
source IP addresses and ports, since the source IP address and port source IP addresses and ports, since the source IP address and port
are not utilized to provide the client with its relayed candidate. are not utilized to provide the client with its relayed candidate.
skipping to change at page 70, line 5 skipping to change at page 70, line 27
aimed at the TURN server, for purposes of turning it into a zombie or aimed at the TURN server, for purposes of turning it into a zombie or
rogue server. These attacks can be mitigated by DNS-SEC and through rogue server. These attacks can be mitigated by DNS-SEC and through
good box and software security on TURN servers. good box and software security on TURN servers.
Even if an attacker has caused the client to believe in a false Even if an attacker has caused the client to believe in a false
relayed candidate, the connectivity checks cause such a candidate to relayed candidate, the connectivity checks cause such a candidate to
be used only if they succeed. Thus, an attacker must launch a false be used only if they succeed. Thus, an attacker must launch a false
valid on a false candidate, per above, which is a very difficult valid on a false candidate, per above, which is a very difficult
attack to coordinate. attack to coordinate.
14.4. Insider Attacks 15.4. Insider Attacks
In addition to attacks where the attacker is a third party trying to In addition to attacks where the attacker is a third party trying to
insert fake offers, answers, or stun messages, there are attacks insert fake offers, answers, or stun messages, there are attacks
possible with ICE when the attacker is an authenticated and valid possible with ICE when the attacker is an authenticated and valid
participant in the ICE exchange. participant in the ICE exchange.
14.4.1. STUN Amplification Attack 15.4.1. STUN Amplification Attack
The STUN amplification attack is similar to the voice hammer. The STUN amplification attack is similar to the voice hammer.
However, instead of voice packets being directed to the target, STUN However, instead of voice packets being directed to the target, STUN
connectivity checks are directed to the target. The attacker sends connectivity checks are directed to the target. The attacker sends
an offer with a large number of candidates, say, 50. The answerer an offer with a large number of candidates, say, 50. The answerer
receives the offer, and starts its checks, which are directed at the receives the offer, and starts its checks, which are directed at the
target, and consequently, never generate a response. The answerer target, and consequently, never generate a response. The answerer
will start a new connectivity check every Ta ms (say, Ta=20ms). will start a new connectivity check every Ta ms (say, Ta=20ms).
However, the retransmission timers are set to a large number due to However, the retransmission timers are set to a large number due to
the large number of candidates. As a consequence, packets will be the large number of candidates. As a consequence, packets will be
skipping to change at page 71, line 5 skipping to change at page 71, line 24
launch a DoS attack against an unsuspecting target that will not launch a DoS attack against an unsuspecting target that will not
respond. respond.
o There was no response because the IP address and port are not o There was no response because the IP address and port are not
reachable by the initiator. reachable by the initiator.
In the second case, another check should be sent at the next In the second case, another check should be sent at the next
opportunity, while in the former case, no further checks should be opportunity, while in the former case, no further checks should be
sent. sent.
15. STUN Extensions 16. STUN Extensions
15.1. New Attributes 16.1. New Attributes
This specification defines four new attributes, PRIORITY, USE- This specification defines four new attributes, PRIORITY, USE-
CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
The PRIORITY attribute indicates the priority that is to be The PRIORITY attribute indicates the priority that is to be
associated with a peer reflexive candidate, should one be discovered associated with a peer reflexive candidate, should one be discovered
by this check. It is a 32-bit unsigned integer, and has an attribute by this check. It is a 32-bit unsigned integer, and has an attribute
value of 0x0024. value of 0x0024.
The USE-CANDIDATE attribute indicates that the candidate pair The USE-CANDIDATE attribute indicates that the candidate pair
skipping to change at page 71, line 34 skipping to change at page 72, line 5
role. The content of the attribute is a 64-bit unsigned integer in role. The content of the attribute is a 64-bit unsigned integer in
network byte order, which contains a random number used for tie- network byte order, which contains a random number used for tie-
breaking of role conflicts. breaking of role conflicts.
The ICE-CONTROLLING attribute is present in a Binding request and The ICE-CONTROLLING attribute is present in a Binding request and
indicates that the client believes it is currently in the controlling indicates that the client believes it is currently in the controlling
role. The content of the attribute is a 64-bit unsigned integer in role. The content of the attribute is a 64-bit unsigned integer in
network byte order, which contains a random number used for tie- network byte order, which contains a random number used for tie-
breaking of role conflicts. breaking of role conflicts.
15.2. New Error Response Codes 16.2. New Error Response Codes
This specification defines a single error response code: This specification defines a single error response code:
487 (Role Conflict): The Binding request contained either the ICE- 487 (Role Conflict): The Binding request contained either the ICE-
CONTROLLING or ICE-CONTROLLED attribute, indicating a role that CONTROLLING or ICE-CONTROLLED attribute, indicating a role that
conflicted with the server. The server ran a tie-breaker based on conflicted with the server. The server ran a tie-breaker based on
the tie-breaker value in the request and determined that the the tie-breaker value in the request and determined that the
client needs to switch roles. client needs to switch roles.
16. Operational Considerations 17. Operational Considerations
This section discusses issues relevant to network operators looking This section discusses issues relevant to network operators looking
to deploy ICE. to deploy ICE.
16.1. NAT and Firewall Types 17.1. NAT and Firewall Types
ICE was designed to work with existing NAT and firewall equipment. ICE was designed to work with existing NAT and firewall equipment.
Consequently, it is not necessary to replace or reconfigure existing Consequently, it is not necessary to replace or reconfigure existing
firewall and NAT equipment in order to facilitate deployment of ICE. firewall and NAT equipment in order to facilitate deployment of ICE.
Indeed, ICE was developed to be deployed in environments where the Indeed, ICE was developed to be deployed in environments where the
Voice over IP (VoIP) operator has no control over the IP network Voice over IP (VoIP) operator has no control over the IP network
infrastructure, including firewalls and NAT. infrastructure, including firewalls and NAT.
That said, ICE works best in environments where the NAT devices are That said, ICE works best in environments where the NAT devices are
"behave" compliant, meeting the recommendations defined in [RFC4787] "behave" compliant, meeting the recommendations defined in [RFC4787]
and [RFC5382]. In networks with behave-compliant NAT, ICE will work and [RFC5382]. In networks with behave-compliant NAT, ICE will work
without the need for a TURN server, thus improving voice quality, without the need for a TURN server, thus improving voice quality,
decreasing call setup times, and reducing the bandwidth demands on decreasing call setup times, and reducing the bandwidth demands on
the network operator. the network operator.
16.2. Bandwidth Requirements 17.2. Bandwidth Requirements
Deployment of ICE can have several interactions with available Deployment of ICE can have several interactions with available
network capacity that operators should take into consideration. network capacity that operators should take into consideration.
16.2.1. STUN and TURN Server Capacity Planning 17.2.1. STUN and TURN Server Capacity Planning
First and foremost, ICE makes use of TURN and STUN servers, which First and foremost, ICE makes use of TURN and STUN servers, which
would typically be located in the network operator's data centers. would typically be located in the network operator's data centers.
The STUN servers require relatively little bandwidth. For each The STUN servers require relatively little bandwidth. For each
component of each media stream, there will be one or more STUN component of each media stream, there will be one or more STUN
transactions from each client to the STUN server. In a basic voice- transactions from each client to the STUN server. In a basic voice-
only IPv4 VoIP deployment, there will be four transactions per call only IPv4 VoIP deployment, there will be four transactions per call
(one for RTP and one for RTCP, for both caller and callee). Each (one for RTP and one for RTCP, for both caller and callee). Each
transaction is a single request and a single response, the former transaction is a single request and a single response, the former
being 20 bytes long, and the latter, 28. Consequently, if a system being 20 bytes long, and the latter, 28. Consequently, if a system
skipping to change at page 73, line 5 skipping to change at page 73, line 20
to the traffic for the actual media traffic. The amount of calls to the traffic for the actual media traffic. The amount of calls
requiring TURN for media relay is highly dependent on network requiring TURN for media relay is highly dependent on network
topologies, and can and will vary over time. In a network with 100% topologies, and can and will vary over time. In a network with 100%
behave-compliant NAT, it is exactly zero. At time of writing, large- behave-compliant NAT, it is exactly zero. At time of writing, large-
scale consumer deployments were seeing between 5 and 10 percent of scale consumer deployments were seeing between 5 and 10 percent of
calls requiring TURN servers. Considering a voice-only deployment calls requiring TURN servers. Considering a voice-only deployment
using G.711 (so 80 kbps in each direction), with .2 erlangs during using G.711 (so 80 kbps in each direction), with .2 erlangs during
the busy hour, this is N*3.2 kbps. For a population of one million the busy hour, this is N*3.2 kbps. For a population of one million
users, this is 3.2 Gbps, assuming a 10% usage of TURN servers. users, this is 3.2 Gbps, assuming a 10% usage of TURN servers.
16.2.2. Gathering and Connectivity Checks 17.2.2. Gathering and Connectivity Checks
The process of gathering of candidates and performing of connectivity The process of gathering of candidates and performing of connectivity
checks can be bandwidth intensive. ICE has been designed to pace checks can be bandwidth intensive. ICE has been designed to pace
both of these processes. The gathering phase and the connectivity both of these processes. The gathering phase and the connectivity
check phase are meant to generate traffic at roughly the same check phase are meant to generate traffic at roughly the same
bandwidth as the media traffic itself. This was done to ensure that, bandwidth as the media traffic itself. This was done to ensure that,
if a network is designed to support multimedia traffic of a certain if a network is designed to support multimedia traffic of a certain
type (voice, video, or just text), it will have sufficient capacity type (voice, video, or just text), it will have sufficient capacity
to support the ICE checks for that media. Of course, the ICE checks to support the ICE checks for that media. Of course, the ICE checks
will cause a marginal increase in the total utilization; however, will cause a marginal increase in the total utilization; however,
this will typically be an extremely small increase. this will typically be an extremely small increase.
Congestion due to the gathering and check phases has proven to be a Congestion due to the gathering and check phases has proven to be a
problem in deployments that did not utilize pacing. Typically, problem in deployments that did not utilize pacing. Typically,
access links became congested as the endpoints flooded the network access links became congested as the endpoints flooded the network
with checks as fast as they can send them. Consequently, network with checks as fast as they can send them. Consequently, network
operators should make sure that their ICE implementations support the operators should make sure that their ICE implementations support the
pacing feature. Though this pacing does increase call setup times, pacing feature. Though this pacing does increase call setup times,
it makes ICE network friendly and easier to deploy. it makes ICE network friendly and easier to deploy.
16.2.3. Keepalives 17.2.3. Keepalives
STUN keepalives (in the form of STUN Binding Indications) are sent in STUN keepalives (in the form of STUN Binding Indications) are sent in
the middle of a media session. However, they are sent only in the the middle of a media session. However, they are sent only in the
absence of actual media traffic. In deployments that are not absence of actual media traffic. In deployments that are not
utilizing Voice Activity Detection (VAD), the keepalives are never utilizing Voice Activity Detection (VAD), the keepalives are never
used and there is no increase in bandwidth usage. When VAD is being used and there is no increase in bandwidth usage. When VAD is being
used, keepalives will be sent during silence periods. This involves used, keepalives will be sent during silence periods. This involves
a single packet every 15-20 seconds, far less than the packet every 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 20-30 ms that is sent when there is voice. Therefore, keepalives
don't have any real impact on capacity planning. don't have any real impact on capacity planning.
16.3. ICE and ICE-lite 17.3. ICE and ICE-lite
Deployments utilizing a mix of ICE and ICE-lite interoperate Deployments utilizing a mix of ICE and ICE-lite interoperate
perfectly. They have been explicitly designed to do so, without loss perfectly. They have been explicitly designed to do so, without loss
of function. of function.
However, ICE-lite can only be deployed in limited use cases. Those However, ICE-lite can only be deployed in limited use cases. Those
cases, and the caveats involved in doing so, are documented in cases, and the caveats involved in doing so, are documented in
Appendix A. Appendix A.
16.4. Troubleshooting and Performance Management 17.4. Troubleshooting and Performance Management
ICE utilizes end-to-end connectivity checks, and places much of the ICE utilizes end-to-end connectivity checks, and places much of the
processing in the endpoints. This introduces a challenge to the processing in the endpoints. This introduces a challenge to the
network operator -- how can they troubleshoot ICE deployments? How network operator -- how can they troubleshoot ICE deployments? How
can they know how ICE is performing? can they know how ICE is performing?
ICE has built-in features to help deal with these problems. SIP ICE has built-in features to help deal with these problems. SIP
servers on the signaling path, typically deployed in the data centers servers on the signaling path, typically deployed in the data centers
of the network operator, will see the contents of the offer/answer of the network operator, will see the contents of the offer/answer
exchanges that convey the ICE parameters. These parameters include exchanges that convey the ICE parameters. These parameters include
skipping to change at page 74, line 24 skipping to change at page 74, line 39
the selected address (and its type). This updated re-INVITE is the selected address (and its type). This updated re-INVITE is
performed exactly for the purposes of educating network equipment performed exactly for the purposes of educating network equipment
(such as a diagnostic tool attached to a SIP server) about the (such as a diagnostic tool attached to a SIP server) about the
results of ICE processing. results of ICE processing.
As a consequence, through the logs generated by the SIP server, a As a consequence, through the logs generated by the SIP server, a
network operator can observe what types of candidates are being used network operator can observe what types of candidates are being used
for each call, and what address was selected by ICE. This is the for each call, and what address was selected by ICE. This is the
primary information that helps evaluate how ICE is performing. primary information that helps evaluate how ICE is performing.
16.5. Endpoint Configuration 17.5. Endpoint Configuration
ICE relies on several pieces of data being configured into the ICE relies on several pieces of data being configured into the
endpoints. This configuration data includes timers, credentials for endpoints. This configuration data includes timers, credentials for
TURN servers, and hostnames for STUN and TURN servers. ICE itself TURN servers, and hostnames for STUN and TURN servers. ICE itself
does not provide a mechanism for this configuration. Instead, it is does not provide a mechanism for this configuration. Instead, it is
assumed that this information is attached to whatever mechanism is assumed that this information is attached to whatever mechanism is
used to configure all of the other parameters in the endpoint. For used to configure all of the other parameters in the endpoint. For
SIP phones, standard solutions such as the configuration framework SIP phones, standard solutions such as the configuration framework
[RFC6080] have been defined. [RFC6080] have been defined.
17. IANA Considerations 18. IANA Considerations
The original ICE specification registered four new STUN attributes, The original ICE specification registered four new STUN attributes,
and one new STUN error response. The STUN attributes and error and one new STUN error response. The STUN attributes and error
response are reproduced here. response are reproduced here.
17.1. STUN Attributes 18.1. STUN Attributes
IANA has registered four STUN attributes: IANA has registered four STUN attributes:
0x0024 PRIORITY 0x0024 PRIORITY
0x0025 USE-CANDIDATE 0x0025 USE-CANDIDATE
0x8029 ICE-CONTROLLED 0x8029 ICE-CONTROLLED
0x802A ICE-CONTROLLING 0x802A ICE-CONTROLLING
17.2. STUN Error Responses 18.2. STUN Error Responses
IANA has registered following STUN error response code: IANA has registered following STUN error response code:
487 Role Conflict: The client asserted an ICE role (controlling or 487 Role Conflict: The client asserted an ICE role (controlling or
controlled) that is in conflict with the role of the server. controlled) that is in conflict with the role of the server.
18. IAB Considerations 19. IAB Considerations
The IAB has studied the problem of "Unilateral Self-Address Fixing", The IAB has studied the problem of "Unilateral Self-Address Fixing",
which is the general process by which a agent attempts to determine which is the general process by which a agent attempts to determine
its address in another realm on the other side of a NAT through a its address in another realm on the other side of a NAT through a
collaborative protocol reflection mechanism [RFC3424]. ICE is an collaborative protocol reflection mechanism [RFC3424]. ICE is an
example of a protocol that performs this type of function. example of a protocol that performs this type of function.
Interestingly, the process for ICE is not unilateral, but bilateral, Interestingly, the process for ICE is not unilateral, but bilateral,
and the difference has a significant impact on the issues raised by and the difference has a significant impact on the issues raised by
IAB. Indeed, ICE can be considered a B-SAF (Bilateral Self-Address IAB. Indeed, ICE can be considered a B-SAF (Bilateral Self-Address
Fixing) protocol, rather than an UNSAF protocol. Regardless, the IAB Fixing) protocol, rather than an UNSAF protocol. Regardless, the IAB
has mandated that any protocols developed for this purpose document a has mandated that any protocols developed for this purpose document a
specific set of considerations. This section meets those specific set of considerations. This section meets those
requirements. requirements.
18.1. Problem Definition 19.1. Problem Definition
>From RFC 3424, any UNSAF proposal must provide: >From RFC 3424, any UNSAF proposal must provide:
Precise definition of a specific, limited-scope problem that is to Precise definition of a specific, limited-scope problem that is to
be solved with the UNSAF proposal. A short-term fix should not be be solved with the UNSAF proposal. A short-term fix should not be
generalized to solve other problems; this is why "short-term fixes generalized to solve other problems; this is why "short-term fixes
usually aren't". usually aren't".
The specific problems being solved by ICE are: The specific problems being solved by ICE are:
Provide a means for two peers to determine the set of transport Provide a means for two peers to determine the set of transport
addresses that can be used for communication. addresses that can be used for communication.
Provide a means for a agent to determine an address that is Provide a means for a agent to determine an address that is
reachable by another peer with which it wishes to communicate. reachable by another peer with which it wishes to communicate.
18.2. Exit Strategy 19.2. Exit Strategy
>From RFC 3424, any UNSAF proposal must provide: >From RFC 3424, any UNSAF proposal must provide:
Description of an exit strategy/transition plan. The better Description of an exit strategy/transition plan. The better
short-term fixes are the ones that will naturally see less and short-term fixes are the ones that will naturally see less and
less use as the appropriate technology is deployed. less use as the appropriate technology is deployed.
ICE itself doesn't easily get phased out. However, it is useful even 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 in a globally connected Internet, to serve as a means for detecting
whether a router failure has temporarily disrupted connectivity, for whether a router failure has temporarily disrupted connectivity, for
skipping to change at page 76, line 25 skipping to change at page 76, line 41
used, because higher-priority connectivity exists to the native host used, because higher-priority connectivity exists to the native host
candidates. Therefore, the servers get used less and less, and can candidates. Therefore, the servers get used less and less, and can
eventually be remove when their usage goes to zero. eventually be remove when their usage goes to zero.
Indeed, ICE can assist in the transition from IPv4 to IPv6. It can 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 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 hosts communicate with SIP (IPv6 gets used). It can also allow a
network with both 6to4 and native v6 connectivity to determine which network with both 6to4 and native v6 connectivity to determine which
address to use when communicating with a peer. address to use when communicating with a peer.
18.3. Brittleness Introduced by ICE 19.3. Brittleness Introduced by ICE
>From RFC 3424, any UNSAF proposal must provide: >From RFC 3424, any UNSAF proposal must provide:
Discussion of specific issues that may render systems more Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at "brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition. debugging challenges, and make it harder to transition.
ICE actually removes brittleness from existing UNSAF mechanisms. In ICE actually removes brittleness from existing UNSAF mechanisms. In
particular, classic STUN (as described in RFC 3489 [RFC3489]) has particular, classic STUN (as described in RFC 3489 [RFC3489]) has
skipping to change at page 77, line 23 skipping to change at page 77, line 39
Classic STUN also introduces some security considerations. Classic STUN also introduces some security considerations.
Fortunately, those security considerations are also mitigated by ICE. Fortunately, those security considerations are also mitigated by ICE.
Consequently, ICE serves to repair the brittleness introduced in Consequently, ICE serves to repair the brittleness introduced in
classic STUN, and does not introduce any additional brittleness into classic STUN, and does not introduce any additional brittleness into
the system. the system.
The penalty of these improvements is that ICE increases session The penalty of these improvements is that ICE increases session
establishment times. establishment times.
18.4. Requirements for a Long-Term Solution 19.4. Requirements for a Long-Term Solution
From RFC 3424, any UNSAF proposal must provide: From RFC 3424, any UNSAF proposal must provide:
... requirements for longer term, sound technical solutions -- ... requirements for longer term, sound technical solutions --
contribute to the process of finding the right longer term contribute to the process of finding the right longer term
solution. solution.
Our conclusions from RFC 3489 remain unchanged. However, we feel ICE Our conclusions from RFC 3489 remain unchanged. However, we feel ICE
actually helps because we believe it can be part of the long-term actually helps because we believe it can be part of the long-term
solution. solution.
18.5. Issues with Existing NAPT Boxes 19.5. Issues with Existing NAPT Boxes
From RFC 3424, any UNSAF proposal must provide: From RFC 3424, any UNSAF proposal must provide:
Discussion of the impact of the noted practical issues with Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports. existing, deployed NA[P]Ts and experience reports.
A number of NAT boxes are now being deployed into the market that try A number of NAT boxes are now being deployed into the market that try
to provide "generic" ALG functionality. These generic ALGs hunt for to provide "generic" ALG functionality. These generic ALGs hunt for
IP addresses, either in text or binary form within a packet, and IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This interferes with classic rewrite them if they match a binding. This interferes with classic
skipping to change at page 78, line 11 skipping to change at page 78, line 29
Existing NAPT boxes have non-deterministic and typically short Existing NAPT boxes have non-deterministic and typically short
expiration times for UDP-based bindings. This requires expiration times for UDP-based bindings. This requires
implementations to send periodic keepalives to maintain those implementations to send periodic keepalives to maintain those
bindings. ICE uses a default of 15 s, which is a very conservative bindings. ICE uses a default of 15 s, which is a very conservative
estimate. Eventually, over time, as NAT boxes become compliant to estimate. Eventually, over time, as NAT boxes become compliant to
behave [RFC4787], this minimum keepalive will become deterministic behave [RFC4787], this minimum keepalive will become deterministic
and well-known, and the ICE timers can be adjusted. Having a way to and well-known, and the ICE timers can be adjusted. Having a way to
discover and control the minimum keepalive interval would be far discover and control the minimum keepalive interval would be far
better still. better still.
19. Changes from RFC 5245 20. Changes from RFC 5245
Following is the list of changes from RFC 5245 Following is the list of changes from RFC 5245
o The specification was generalized to be more usable with any o The specification was generalized to be more usable with any
protocol and the parts that are specific to SIP and SDP were moved protocol and the parts that are specific to SIP and SDP were moved
to a SIP/SDP usage document to a SIP/SDP usage document [I-D.ietf-mmusic-ice-sip-sdp].
[I-D.petithuguenin-mmusic-ice-sip-sdp].
o Default candidates, multiple components, ICE mismatch detection, o Default candidates, multiple components, ICE mismatch detection,
subsequent offer/answer, and role conflict resolution were made subsequent offer/answer, and role conflict resolution were made
optional since they are not needed with every protocol using ICE. optional since they are not needed with every protocol using ICE.
o With IPv6, the precedence rules of RFC 6724 are used instead of o With IPv6, the precedence rules of RFC 6724 are used instead of
the obsoleted RFC 3483 and using address preferences provided by the obsoleted RFC 3483 and using address preferences provided by
the host operating system is recommended. the host operating system is recommended.
o Candidate gathering rules regarding loopback addresses and IPv6 o Candidate gathering rules regarding loopback addresses and IPv6
addresses were clarified. addresses were clarified.
20. Acknowledgements 21. Acknowledgements
Most of the text in this document comes from the original ICE Most of the text in this document comes from the original ICE
specification, RFC 5245. The authors would like to thank everyone specification, RFC 5245. The authors would like to thank everyone
who has contributed to that document. who has contributed to that document.
21. References 22. References
21.1. Normative References 22.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
21.2. Informative References 22.2. Informative References
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October in Session Description Protocol (SDP)", RFC 3605, October
2003. 2003.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
skipping to change at page 81, line 28 skipping to change at page 81, line 40
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session [RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", RFC Initiation Protocol User Agent Profile Delivery", RFC
6080, March 2011. 6080, March 2011.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, March 2012.
[I-D.petithuguenin-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M. and A. Keranen, "Using Interactive Petit-Huguenin, M. and A. Keranen, "Using Interactive
Connectivity Establishment (ICE) with Session Description Connectivity Establishment (ICE) with Session Description
Protocol (SDP) offer/answer and Session Initiation Protocol (SDP) offer/answer and Session Initiation
Protocol (SIP)", draft-petithuguenin-mmusic-ice-sip-sdp-01 Protocol (SIP)", draft-ietf-mmusic-ice-sip-sdp-03 (work in
(work in progress), February 2013. progress), July 2014.
Appendix A. Lite and Full Implementations Appendix A. Lite and Full Implementations
ICE allows for two types of implementations. A full implementation ICE allows for two types of implementations. A full implementation
supports the controlling and controlled roles in a session, and can supports the controlling and controlled roles in a session, and can
also perform address gathering. In contrast, a lite implementation also perform address gathering. In contrast, a lite implementation
is a minimalist implementation that does little but respond to STUN is a minimalist implementation that does little but respond to STUN
checks. checks.
Because ICE requires both endpoints to support it in order to bring Because ICE requires both endpoints to support it in order to bring
skipping to change at page 82, line 33 skipping to change at page 82, line 46
order to provide the most robust form of address selection possible. order to provide the most robust form of address selection possible.
It is important to note that the lite implementation was added to It is important to note that the lite implementation was added to
this specification to provide a stepping stone to full this specification to provide a stepping stone to full
implementation. Even for devices that are always connected to the implementation. Even for devices that are always connected to the
public Internet with just a single IPv4 address, a full public Internet with just a single IPv4 address, a full
implementation is preferable if achievable. A full implementation implementation is preferable if achievable. A full implementation
will reduce call setup times, since ICE's aggressive mode can be will reduce call setup times, since ICE's aggressive mode can be
used. Full implementations also obtain the security benefits of ICE used. Full implementations also obtain the security benefits of ICE
unrelated to NAT traversal; in particular, the voice hammer attack unrelated to NAT traversal; in particular, the voice hammer attack
described in Section 14 is prevented only for full implementations, described in Section 15 is prevented only for full implementations,
not lite. Finally, it is often the case that a device that finds not lite. Finally, it is often the case that a device that finds
itself with a public address today will be placed in a network itself with a public address today will be placed in a network
tomorrow where it will be behind a NAT. It is difficult to tomorrow where it will be behind a NAT. It is difficult to
definitively know, over the lifetime of a device or product, that it definitively know, over the lifetime of a device or product, that it
will always be used on the public Internet. Full implementation will always be used on the public Internet. Full implementation
provides assurance that communications will always work. provides assurance that communications will always work.
Appendix B. Design Motivations Appendix B. Design Motivations
ICE contains a number of normative behaviors that may themselves be ICE contains a number of normative behaviors that may themselves be
skipping to change at page 88, line 51 skipping to change at page 88, line 51
upon. ICE defines a simple periodic keepalive utilizing STUN Binding upon. ICE defines a simple periodic keepalive utilizing STUN Binding
indications. This makes its bandwidth requirements highly indications. This makes its bandwidth requirements highly
predictable, and thus amenable to QoS reservations. predictable, and thus amenable to QoS reservations.
B.7. Why Prefer Peer Reflexive Candidates? B.7. Why Prefer Peer Reflexive Candidates?
Section 4.1.2 describes procedures for computing the priority of Section 4.1.2 describes procedures for computing the priority of
candidate based on its type and local preferences. That section candidate based on its type and local preferences. That section
requires that the type preference for peer reflexive candidates requires that the type preference for peer reflexive candidates
always be higher than server reflexive. Why is that? The reason has always be higher than server reflexive. Why is that? The reason has
to do with the security considerations in Section 14. It is much to do with the security considerations in Section 15. It is much
easier for an attacker to cause an agent to use a false server easier for an attacker to cause an agent to use a false server
reflexive candidate than it is for an attacker to cause an agent to reflexive candidate than it is for an attacker to cause an agent to
use a false peer reflexive candidate. Consequently, attacks against use a false peer reflexive candidate. Consequently, attacks against
address gathering with Binding requests are thwarted by ICE by address gathering with Binding requests are thwarted by ICE by
preferring the peer reflexive candidates. preferring the peer reflexive candidates.
B.8. Why Are Binding Indications Used for Keepalives? B.8. Why Are Binding Indications Used for Keepalives?
Media keepalives are described in Section 9. These keepalives make Media keepalives are described in Section 10. These keepalives make
use of STUN when both endpoints are ICE capable. However, rather use of STUN when both endpoints are ICE capable. However, rather
than using a Binding request transaction (which generates a than using a Binding request transaction (which generates a
response), the keepalives use an Indication. Why is that? response), the keepalives use an Indication. Why is that?
The primary reason has to do with network QoS mechanisms. Once media The primary reason has to do with network QoS mechanisms. Once media
begins flowing, network elements will assume that the media stream begins flowing, network elements will assume that the media stream
has a fairly regular structure, making use of periodic packets at has a fairly regular structure, making use of periodic packets at
fixed intervals, with the possibility of jitter. If an agent is fixed intervals, with the possibility of jitter. If an agent is
sending media packets, and then receives a Binding request, it would sending media packets, and then receives a Binding request, it would
need to generate a response packet along with its media packets. need to generate a response packet along with its media packets.
 End of changes. 72 change blocks. 
138 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/