draft-ietf-mmusic-ice-17.txt   draft-ietf-mmusic-ice-18.txt 
MMUSIC J. Rosenberg MMUSIC J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 4091 (if approved) July 9, 2007 Obsoletes: 4091 (if approved) September 13, 2007
Intended status: Standards Track Intended status: Standards Track
Expires: January 10, 2008 Expires: March 16, 2008
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-ice-17 draft-ietf-mmusic-ice-18
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008. This Internet-Draft will expire on March 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a protocol for Network Address Translator This document describes a protocol for Network Address Translator
(NAT) traversal for multimedia sessions established with the offer/ (NAT) traversal for multimedia sessions established with the offer/
answer model. This protocol is called Interactive Connectivity answer model. This protocol is called Interactive Connectivity
Establishment (ICE). ICE makes use of the Session Traversal Establishment (ICE). ICE makes use of the Session Traversal
Utilities for NAT (STUN) protocol and its extension, Traversal Using Utilities for NAT (STUN) protocol and its extension, Traversal Using
Relay NAT (TURN). ICE can be used by any protocol utilizing the Relay NAT (TURN). ICE can be used by any protocol utilizing the
offer/answer model, such as the Session Initiation Protocol (SIP). offer/answer model, such as the Session Initiation Protocol (SIP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 9 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 10
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 11 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 12
2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 12 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 13
2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 13 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 14
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 14 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 15
2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 14 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 15
2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 16 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 17
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 20
4.1. Full Implementation Requirements . . . . . . . . . . . . 19 4.1. Full Implementation Requirements . . . . . . . . . . . . 20
4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 20
4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 20 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 21
4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 21
4.1.1.3. Eliminating Redundant Candidates . . . . . . . . 21 4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 23
4.1.1.4. Computing Foundations . . . . . . . . . . . . . . 22 4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 23
4.1.1.5. Keeping Candidates Alive . . . . . . . . . . . . 22 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 23
4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 24
4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 23
4.1.2.2. Guidelines for Choosing Type and Local 4.1.2.2. Guidelines for Choosing Type and Local
Preferences . . . . . . . . . . . . . . . . . . . 24 Preferences . . . . . . . . . . . . . . . . . . . 25
4.1.3. Choosing Default Candidates . . . . . . . . . . . . . 25 4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 26
4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 25 4.1.4. Choosing Default Candidates . . . . . . . . . . . . . 26
4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 26 4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 26
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 28 4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 27
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 29
5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 29 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 29
5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 30 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 30
5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 30 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 31
5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 30 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 31
5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 30 5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 31
5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 31 5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 31
5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 31 5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 32
5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 33 5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 32
5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 33 5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 34
5.7.4. Computing States . . . . . . . . . . . . . . . . . . 33 5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 34
5.8. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 36 5.7.4. Computing States . . . . . . . . . . . . . . . . . . 34
6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 38 5.8. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 37
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 38 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 39
6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 38 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 39
6.3. Forming the Check List . . . . . . . . . . . . . . . . . 39 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 39
6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 39 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 40
7. Performing Connectivity Checks . . . . . . . . . . . . . . . 39 6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 40
7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 39 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 40
7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 39 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 40
7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 40 7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 40
7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 40 7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 41
7.1.1.3. Forming Credentials . . . . . . . . . . . . . . . 40 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 41
7.1.1.4. DiffServ Treatment . . . . . . . . . . . . . . . 40 7.1.1.3. Forming Credentials . . . . . . . . . . . . . . . 41
7.1.2. Processing the Response . . . . . . . . . . . . . . . 41 7.1.1.4. DiffServ Treatment . . . . . . . . . . . . . . . 41
7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 41 7.1.2. Processing the Response . . . . . . . . . . . . . . . 42
7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 41 7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 42
7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 42 7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 42
7.1.2.2.2. Constructing a Valid Pair . . . . . . . . . . 42 7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 43
7.1.2.2.3. Updating Pair States . . . . . . . . . . . . 43 7.1.2.2.2. Constructing a Valid Pair . . . . . . . . . . 43
7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 44 7.1.2.2.3. Updating Pair States . . . . . . . . . . . . 44
7.1.2.3. Check List and Timer State Updates . . . . . . . 44 7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 45
7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 45 7.1.2.3. Check List and Timer State Updates . . . . . . . 45
7.2.1. Additional Procedures for Full Implementations . . . 46 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 46
7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 46 7.2.1. Additional Procedures for Full Implementations . . . 47
7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 47 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 47
7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 47 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 48
7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 48 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 48
7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 49 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 49
7.2.2. Additional Procedures for Lite Implementations . . . 49 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 50
8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 49 7.2.2. Additional Procedures for Lite Implementations . . . 50
8.1. Procedures for Full Implementations . . . . . . . . . . . 50 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 50
8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 50 8.1. Procedures for Full Implementations . . . . . . . . . . . 51
8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 50 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 51
8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 51 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 51
8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 51 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 52
8.2. Procedures for Lite Implementations . . . . . . . . . . . 52 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 52
8.2.1. Peer is Full . . . . . . . . . . . . . . . . . . . . 53 8.2. Procedures for Lite Implementations . . . . . . . . . . . 53
8.2.2. Peer is Lite . . . . . . . . . . . . . . . . . . . . 53 8.2.1. Peer is Full . . . . . . . . . . . . . . . . . . . . 54
8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 54 8.2.2. Peer is Lite . . . . . . . . . . . . . . . . . . . . 54
8.3.1. Full Implementation Procedures . . . . . . . . . . . 54 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 55
8.3.2. Lite Implementations . . . . . . . . . . . . . . . . 54 8.3.1. Full Implementation Procedures . . . . . . . . . . . 55
9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 54 8.3.2. Lite Implementations . . . . . . . . . . . . . . . . 55
9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 55 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 55
9.1.1. Procedures for All Implementations . . . . . . . . . 55 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 56
9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 55 9.1.1. Procedures for All Implementations . . . . . . . . . 56
9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 56 9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 56
9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 56 9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 57
9.1.2. Procedures for Full Implementations . . . . . . . . . 56 9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 57
9.1.2.1. Existing Media Streams with ICE Running . . . . . 56 9.1.2. Procedures for Full Implementations . . . . . . . . . 57
9.1.2.2. Existing Media Streams with ICE Completed . . . . 57 9.1.2.1. Existing Media Streams with ICE Running . . . . . 57
9.1.3. Procedures for Lite Implementations . . . . . . . . . 57 9.1.2.2. Existing Media Streams with ICE Completed . . . . 58
9.1.3.1. Existing Media Streams with ICE Running . . . . . 57 9.1.3. Procedures for Lite Implementations . . . . . . . . . 58
9.1.3.2. Existing Media Streams with ICE Completed . . . . 58 9.1.3.1. Existing Media Streams with ICE Running . . . . . 58
9.2. Receiving the Offer and Generating an Answer . . . . . . 58 9.1.3.2. Existing Media Streams with ICE Completed . . . . 59
9.2.1. Procedures for All Implementations . . . . . . . . . 58 9.2. Receiving the Offer and Generating an Answer . . . . . . 59
9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 58 9.2.1. Procedures for All Implementations . . . . . . . . . 59
9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 59 9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 59
9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 59 9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 60
9.2.2. Procedures for Full Implementations . . . . . . . . . 59 9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 60
9.2.2. Procedures for Full Implementations . . . . . . . . . 60
9.2.2.1. Existing Media Streams with ICE Running and no 9.2.2.1. Existing Media Streams with ICE Running and no
remote-candidates . . . . . . . . . . . . . . . . 59 remote-candidates . . . . . . . . . . . . . . . . 60
9.2.2.2. Existing Media Streams with ICE Completed and 9.2.2.2. Existing Media Streams with ICE Completed and
no remote-candidates . . . . . . . . . . . . . . 59 no remote-candidates . . . . . . . . . . . . . . 60
9.2.2.3. Existing Media Streams and remote-candidates . . 59 9.2.2.3. Existing Media Streams and remote-candidates . . 60
9.2.3. Procedures for Lite Implementations . . . . . . . . . 60 9.2.3. Procedures for Lite Implementations . . . . . . . . . 61
9.3. Updating the Check and Valid Lists . . . . . . . . . . . 61 9.3. Updating the Check and Valid Lists . . . . . . . . . . . 62
9.3.1. Procedures for Full Implementations . . . . . . . . . 61 9.3.1. Procedures for Full Implementations . . . . . . . . . 62
9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 61 9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 62
9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 61 9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 62
9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 62 9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 63
9.3.1.4. ICE Continuing for Existing Media Stream . . . . 62 9.3.1.4. ICE Continuing for Existing Media Stream . . . . 63
9.3.2. Procedures for Lite Implementations . . . . . . . . . 62 9.3.2. Procedures for Lite Implementations . . . . . . . . . 63
10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 63 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 64
11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 64 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 65
11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 64 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 65
11.1.1. Procedures for Full Implementations . . . . . . . . . 64 11.1.1. Procedures for Full Implementations . . . . . . . . . 65
11.1.2. Procedures for Lite Implementations . . . . . . . . . 65 11.1.2. Procedures for Lite Implementations . . . . . . . . . 66
11.1.3. Procedures for All Implementations . . . . . . . . . 65 11.1.3. Procedures for All Implementations . . . . . . . . . 66
11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 65 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 66
12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 66 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 67
12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 66 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 67
12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 66 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 67
12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 67 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 68
12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 68 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 69
12.3. Interactions with Forking . . . . . . . . . . . . . . . . 68 12.3. Interactions with Forking . . . . . . . . . . . . . . . . 69
12.4. Interactions with Preconditions . . . . . . . . . . . . . 68 12.4. Interactions with Preconditions . . . . . . . . . . . . . 69
12.5. Interactions with Third Party Call Control . . . . . . . 69 12.5. Interactions with Third Party Call Control . . . . . . . 70
13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 69 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 70
14. Extensibility Considerations . . . . . . . . . . . . . . . . 69 14. Extensibility Considerations . . . . . . . . . . . . . . . . 71
15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 71 15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 72
15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 73 15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 74
15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 73 15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 74
15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 73 15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 75
15.5. "ice-options" Attribute . . . . . . . . . . . . . . . . . 74 15.5. "ice-options" Attribute . . . . . . . . . . . . . . . . . 75
16. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 74 16. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 76
17. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 16.1. RTP Media Streams . . . . . . . . . . . . . . . . . . . . 76
18. Security Considerations . . . . . . . . . . . . . . . . . . . 82 16.2. Non-RTP Sessions . . . . . . . . . . . . . . . . . . . . 77
18.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 82 17. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
18.2. Attacks on Server Reflexive Address Gathering . . . . . . 84 18. Security Considerations . . . . . . . . . . . . . . . . . . . 84
18.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 85 18.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 84
18.4. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 86 18.2. Attacks on Server Reflexive Address Gathering . . . . . . 87
18.5. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 86 18.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 87
18.5.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 86 18.4. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 88
18.5.2. STUN Amplification Attack . . . . . . . . . . . . . . 86 18.5. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 88
18.6. Interactions with Application Layer Gateways and SIP . . 87 18.5.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 88
19. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 88 18.5.2. STUN Amplification Attack . . . . . . . . . . . . . . 89
19.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 88 18.6. Interactions with Application Layer Gateways and SIP . . 90
19.2. New Error Response Codes . . . . . . . . . . . . . . . . 89 19. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 91
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 19.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 91
20.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 89 19.2. New Error Response Codes . . . . . . . . . . . . . . . . 91
20.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 89 20. Operational Considerations . . . . . . . . . . . . . . . . . 92
20.1.2. remote-candidates Attribute . . . . . . . . . . . . . 90 20.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 92
20.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 90 20.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 92
20.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 91 20.2.1. STUN and TURN Server Capacity Planning . . . . . . . 92
20.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 91 20.2.2. Gathering and Connectivity Checks . . . . . . . . . . 93
20.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 91 20.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 93
20.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 92 20.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 93
20.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 92 20.4. Troubleshooting and Performance Management . . . . . . . 94
20.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 93 20.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 94
21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 93 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94
21.1. Problem Definition . . . . . . . . . . . . . . . . . . . 93 21.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 94
21.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 93 21.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 95
21.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 94 21.1.2. remote-candidates Attribute . . . . . . . . . . . . . 95
21.4. Requirements for a Long Term Solution . . . . . . . . . . 95 21.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 95
21.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 95 21.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 96
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 21.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 96
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 21.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 97
23.1. Normative References . . . . . . . . . . . . . . . . . . 96 21.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 97
23.2. Informative References . . . . . . . . . . . . . . . . . 97 21.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 98
Appendix A. Lite and Full Implementations . . . . . . . . . . . 99 21.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 98
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 100 22. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 98
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 101 22.1. Problem Definition . . . . . . . . . . . . . . . . . . . 98
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 102 22.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 99
B.3. Purpose of the <rel-addr> and <rel-port> Attributes . . . 104 22.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 99
B.4. Importance of the STUN Username . . . . . . . . . . . . . 104 22.4. Requirements for a Long Term Solution . . . . . . . . . . 100
B.5. The Candidate Pair Sequence Number Formula . . . . . . . 105 22.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 101
B.6. The remote-candidates attribute . . . . . . . . . . . . . 106 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 101
B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 107 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 108 24.1. Normative References . . . . . . . . . . . . . . . . . . 102
B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 108 24.2. Informative References . . . . . . . . . . . . . . . . . 103
B.10. Why are Binding Indications Used for Keepalives? . . . . 108 Appendix A. Lite and Full Implementations . . . . . . . . . . . 105
B.11. Why is the Conflict Resolution Mechanism Needed? . . . . 109 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 106
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 110 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 106
Intellectual Property and Copyright Statements . . . . . . . . . 111 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 108
B.3. Purpose of the <rel-addr> and <rel-port> Attributes . . . 109
B.4. Importance of the STUN Username . . . . . . . . . . . . . 110
B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 111
B.6. The remote-candidates attribute . . . . . . . . . . . . . 111
B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 112
B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 113
B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 113
B.10. Why are Binding Indications Used for Keepalives? . . . . 113
B.11. Why is the Conflict Resolution Mechanism Needed? . . . . 114
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 115
Intellectual Property and Copyright Statements . . . . . . . . . 116
1. Introduction 1. Introduction
RFC 3264 [RFC3264] defines a two-phase exchange of Session RFC 3264 [RFC3264] defines a two-phase exchange of Session
Description Protocol (SDP) messages [RFC4566] for the purposes of Description Protocol (SDP) messages [RFC4566] for the purposes of
establishment of multimedia sessions. This offer/answer mechanism is establishment of multimedia sessions. This offer/answer mechanism is
used by protocols such as the Session Initiation Protocol (SIP) used by protocols such as the Session Initiation Protocol (SIP)
[RFC3261]. [RFC3261].
Protocols using offer/answer are difficult to operate through Network Protocols using offer/answer are difficult to operate through Network
skipping to change at page 6, line 25 skipping to change at page 7, line 25
flow of media packets, they tend to carry the IP addresses and ports flow of media packets, they tend to carry the IP addresses and ports
of media sources and sinks within their messages, which is known to of media sources and sinks within their messages, which is known to
be problematic through NAT [RFC3235]. The protocols also seek to be problematic through NAT [RFC3235]. The protocols also seek to
create a media flow directly between participants, so that there is create a media flow directly between participants, so that there is
no application layer intermediary between them. This is done to no application layer intermediary between them. This is done to
reduce media latency, decrease packet loss, and reduce the reduce media latency, decrease packet loss, and reduce the
operational costs of deploying the application. However, this is operational costs of deploying the application. However, this is
difficult to accomplish through NAT. A full treatment of the reasons difficult to accomplish through NAT. A full treatment of the reasons
for this is beyond the scope of this specification. for this is beyond the scope of this specification.
Numerous solutions have been proposed for allowing these protocols to Numerous solutions have been defined for allowing these protocols to
operate through NAT. These include Application Layer Gateways operate through NAT. These include Application Layer Gateways
(ALGs), the Middlebox Control Protocol [RFC3303], Simple Traversal (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple
Underneath NAT (STUN) [RFC3489] and its revision, retitled Session Traversal of UDP Through NAT (STUN) [RFC3489] specification, and
Traversal Utilities for NAT [I-D.ietf-behave-rfc3489bis], Traversal Realm Specific IP [RFC3102] [RFC3103] along with session description
Using Relay NAT (TURN) [I-D.ietf-behave-turn], and Realm Specific IP extensions needed to make them work, such as the Session Description
[RFC3102] [RFC3103] along with session description extensions needed Protocol (SDP) [RFC4566] attribute for the Real Time Control Protocol
to make them work, such as the Session Description Protocol (SDP) (RTCP) [RFC3605]. Unfortunately, these techniques all have pros and
[RFC4566] attribute for the Real Time Control Protocol (RTCP) cons which make each one optimal in some network topologies, but a
[RFC3605]. Unfortunately, these techniques all have pros and cons poor choice in others. The result is that administrators and
which make each one optimal in some network topologies, but a poor implementors are making assumptions about the topologies of the
choice in others. The result is that administrators and implementors networks in which their solutions will be deployed. This introduces
are making assumptions about the topologies of the networks in which complexity and brittleness into the system. What is needed is a
their solutions will be deployed. This introduces complexity and single solution which is flexible enough to work well in all
brittleness into the system. What is needed is a single solution situations.
which is flexible enough to work well in all situations.
This specification defines Interactive Connectivity Establishment This specification defines Interactive Connectivity Establishment
(ICE) as a technique for NAT traversal for media streams established (ICE) as a technique for NAT traversal for media streams established
by the offer/answer model. ICE is an extension to the offer/answer by the offer/answer model. ICE is an extension to the offer/answer
model, and works by including a multiplicity of IP addresses and model, and works by including a multiplicity of IP addresses and
ports in SDP offers and answers, which are then tested for ports in SDP offers and answers, which are then tested for
connectivity by peer-to-peer STUN exchanges. The IP addresses and connectivity by peer-to-peer connectivity checks. The IP addresses
ports included in the SDP are gathered using STUN and ports included in the SDP and the connectivity checks are
[I-D.ietf-behave-rfc3489bis] and Traversal Using Relay NAT (TURN) performed using the revised STUN specification
[I-D.ietf-behave-turn]. Because ICE exchanges a multiplicity of IP [I-D.ietf-behave-rfc3489bis], now renamed to Session Traversal
addresses and ports for each media stream, it also allows for address Utilities for NAT. The new name and new specification reflect its
selection for multi-homed and dual-stack hosts, and for this reason new role as a tool that is used with other NAT traversal techniques
it deprecates RFC 4091 [RFC4091]. (namely ICE) rather than a standalone NAT traversal solution, as the
original STUN specification was. ICE also makes use of Traversal
Using Relay NAT (TURN) [I-D.ietf-behave-turn], an extension to STUN.
Because ICE exchanges a multiplicity of IP addresses and ports for
each media stream, it also allows for address selection for multi-
homed and dual-stack hosts, and for this reason it deprecates RFC
4091 [RFC4091].
2. Overview of ICE 2. Overview of ICE
In a typical ICE deployment, we have two endpoints (known as AGENTS In a typical ICE deployment, we have two endpoints (known as AGENTS
in RFC 3264 terminology) which want to communicate. They are able to in RFC 3264 terminology) which want to communicate. They are able to
communicate indirectly via some signaling protocol (such as SIP), by communicate indirectly via some signaling protocol (such as SIP), by
which they can perform an offer/answer exchange of SDP [RFC3264] which they can perform an offer/answer exchange of SDP [RFC3264]
messages. Note that ICE is not intended for NAT traversal for SIP, messages. Note that ICE is not intended for NAT traversal for SIP,
which is assumed to be provided via another mechanism which is assumed to be provided via another mechanism
[I-D.ietf-sip-outbound]. At the beginning of the ICE process, the [I-D.ietf-sip-outbound]. At the beginning of the ICE process, the
skipping to change at page 8, line 34 skipping to change at page 9, line 34
/ \ / \
+-------+ +-------+ +-------+ +-------+
| Agent | | Agent | | Agent | | Agent |
| L | | R | | L | | R |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
Figure 1: ICE Deployment Scenario Figure 1: ICE Deployment Scenario
The basic idea behind ICE is as follows: each agent has a variety of The basic idea behind ICE is as follows: each agent has a variety of
candidate TRANSPORT ADDRESSES (combination of IP address and port) it candidate TRANSPORT ADDRESSES (combination of IP address and port for
could use to communicate with the other agent. These might include: a particular transport protocol, which is always UDP in this
specification)) it could use to communicate with the other agent.
These might include:
o A transport address on a directly attached network interface o A transport address on a directly attached network interface
o A translated transport address on the public side of a NAT (a o A translated transport address on the public side of a NAT (a
"server reflexive" address) "server reflexive" address)
o The transport address allocated from a TURN server(a "relayed o The transport address allocated from a TURN server(a "relayed
address". address".
Potentially, any of L's candidate transport addresses can be used to Potentially, any of L's candidate transport addresses can be used to
skipping to change at page 9, line 10 skipping to change at page 10, line 12
addresses are unlikely to be able to communicate directly (this is addresses are unlikely to be able to communicate directly (this is
why ICE is needed, after all!). The purpose of ICE is to discover why ICE is needed, after all!). The purpose of ICE is to discover
which pairs of addresses will work. The way that ICE does this is to which pairs of addresses will work. The way that ICE does this is to
systematically try all possible pairs (in a carefully sorted order) systematically try all possible pairs (in a carefully sorted order)
until it finds one or more that works. until it finds one or more that works.
2.1. Gathering Candidate Addresses 2.1. Gathering Candidate Addresses
In order to execute ICE, an agent has to identify all of its address In order to execute ICE, an agent has to identify all of its address
candidates. A CANDIDATE is a transport address - a combination of IP candidates. A CANDIDATE is a transport address - a combination of IP
address and port for a particular transport protocol. This document address and port for a particular transport protocol (with only UDP
defines three types of candidates, some derived from physical or specified here). This document defines three types of candidates,
logical network interfaces, others discoverable via STUN and TURN. some derived from physical or logical network interfaces, others
Naturally, one viable candidate is a transport address obtained discoverable via STUN and TURN. Naturally, one viable candidate is a
directly from a local interface. Such a candidate is called a HOST transport address obtained directly from a local interface. Such a
CANDIDATE. The local interface could be ethernet or WiFi, or it candidate is called a HOST CANDIDATE. The local interface could be
could be one that is obtained through a tunnel mechanism, such as a ethernet or WiFi, or it could be one that is obtained through a
Virtual Private Network (VPN) or Mobile IP (MIP). In all cases, such tunnel mechanism, such as a Virtual Private Network (VPN) or Mobile
a network interface appears to the agent as a local interface from IP (MIP). In all cases, such a network interface appears to the
which ports (and thus a candidate) can be allocated. agent as a local interface from which ports (and thus candidates) can
be allocated.
If an agent is multihomed, it obtains a candidate from each If an agent is multihomed, it obtains a candidate from each IP
interface. Depending on the location of the PEER (the other agent in address. Depending on the location of the PEER (the other agent in
the session) on the IP network relative to the agent, the agent may the session) on the IP network relative to the agent, the agent may
be reachable by the peer through one or more of those interfaces. be reachable by the peer through one or more of those IP addresses.
Consider, for example, an agent which has a local interface to a Consider, for example, an agent which has a local IP address on a
private net 10 network (I1), and a second connected to the public private net 10 network (I1), and a second connected to the public
Internet (I2). A candidate from I1 will be directly reachable when Internet (I2). A candidate from I1 will be directly reachable when
communicating with a peer on the same private net 10 network, while a communicating with a peer on the same private net 10 network, while a
candidate from I2 will be directly reachable when communicating with candidate from I2 will be directly reachable when communicating with
a peer on the public Internet. Rather than trying to guess which a peer on the public Internet. Rather than trying to guess which IP
interface will work prior to sending an offer, the offering agent address will work prior to sending an offer, the offering agent
includes both candidates in its offer. includes both candidates in its offer.
Next, the agent uses STUN or TURN to obtain additional candidates. Next, the agent uses STUN or TURN to obtain additional candidates.
These come in two flavors: translated addresses on the public side of These come in two flavors: translated addresses on the public side of
a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers
(RELAYED CANDIDATES). When TURN servers are utilized, both types of (RELAYED CANDIDATES). When TURN servers are utilized, both types of
candidates are obtained from the TURN server. If only STUN servers candidates are obtained from the TURN server. If only STUN servers
are utilized, only server reflexive canddiates are obtained from are utilized, only server reflexive candidates are obtained from
them. The relationship of these candidates to the host candidate is them. The relationship of these candidates to the host candidate is
shown in Figure 2. In this figure, both types of candidates are shown in Figure 2. In this figure, both types of candidates are
discovered using TURN. In the figure, the notation X:x means IP discovered using TURN. In the figure, the notation X:x means IP
address X and port x. address X and UDP port x.
To Internet To Internet
| |
| |
| /------------ Relayed | /------------ Relayed
Y:y | / Address Y:y | / Address
+--------+ +--------+
| | | |
| TURN | | TURN |
skipping to change at page 10, line 40 skipping to change at page 11, line 40
| | | |
+--------+ +--------+
Figure 2: Candidate Relationships Figure 2: Candidate Relationships
When the agent sends the TURN Allocate Request from IP address and When the agent sends the TURN Allocate Request from IP address and
port X:x, the NAT (assuming there is one) will create a binding port X:x, the NAT (assuming there is one) will create a binding
X1':x1', mapping this server reflexive candidate to the host X1':x1', mapping this server reflexive candidate to the host
candidate X:x. Outgoing packets sent from the host candidate will be candidate X:x. Outgoing packets sent from the host candidate will be
translated by the NAT to the server reflexive candidate. Incoming translated by the NAT to the server reflexive candidate. Incoming
packets sent to the server relexive candidate will be translated by packets sent to the server reflexive candidate will be translated by
the NAT to the host candidate and forwarded to the agent. We call the NAT to the host candidate and forwarded to the agent. We call
the host candidate associated with a given server reflexive candidate the host candidate associated with a given server reflexive candidate
the BASE. the BASE.
NOTE: "Base" refers to the address an agent sends from for a NOTE: "Base" refers to the address an agent sends from for a
particular candidate. Thus, as a degenerate case host candidates particular candidate. Thus, as a degenerate case host candidates
also have a base, but it's the same as the host candidate. also have a base, but it's the same as the host candidate.
When there are multiple NATs between the agent and the TURN server, When there are multiple NATs between the agent and the TURN server,
the TURN request will create a binding on each NAT, but only the the TURN request will create a binding on each NAT, but only the
outermost server reflexive candidate (the one nearest the TURN outermost server reflexive candidate (the one nearest the TURN
server) will be discovered by the agent. If the agent is not behind server) will be discovered by the agent. If the agent is not behind
a NAT, then the base candidate will be the same as the server a NAT, then the base candidate will be the same as the server
reflexive candidate and the server reflexive candidate is redundant reflexive candidate and the server reflexive candidate is redundant
and will be eliminated. and will be eliminated.
The Allocate request then arrives at the TURN server. The TURN The Allocate request then arrives at the TURN server. The TURN
server allocates a port y from its local interface Y, and generates server allocates a port y from its local IP address Y, and generates
an Allocate response, informing the agent of this relayed candidate. an Allocate response, informing the agent of this relayed candidate.
The TURN server also informs the agent of the server reflexive The TURN server also informs the agent of the server reflexive
candidate, X1':x1' by copying the source transport address of the candidate, X1':x1' by copying the source transport address of the
Allocate request into the Allocate response. The TURN server acts as Allocate request into the Allocate response. The TURN server acts as
a packet relay, forwarding traffic between L and R. In order to send a packet relay, forwarding traffic between L and R. In order to send
traffic to L, R sends traffic to the TURN server at Y:y, and the TURN traffic to L, R sends traffic to the TURN server at Y:y, and the TURN
server forwards that to X1':x1', which passes through the NAT where server forwards that to X1':x1', which passes through the NAT where
it is mapped to X:x and delivered to L. it is mapped to X:x and delivered to L.
When only STUN servers are utilized, the agent sends a STUN Binding When only STUN servers are utilized, the agent sends a STUN Binding
skipping to change at page 11, line 35 skipping to change at page 12, line 35
2.2. Connectivity Checks 2.2. Connectivity Checks
Once L has gathered all of its candidates, it orders them in highest Once L has gathered all of its candidates, it orders them in highest
to lowest priority and sends them to R over the signalling channel. to lowest priority and sends them to R over the signalling channel.
The candidates are carried in attributes in the SDP offer. When R The candidates are carried in attributes in the SDP offer. When R
receives the offer, it performs the same gathering process and receives the offer, it performs the same gathering process and
responds with its own list of candidates. At the end of this responds with its own list of candidates. At the end of this
process, each agent has a complete list of both its candidates and process, each agent has a complete list of both its candidates and
its peer's candidates. It pairs them up, resulting in CANDIDATE its peer's candidates. It pairs them up, resulting in CANDIDATE
PAIRS. To see which pairs work, the agent schedules a series of PAIRS. To see which pairs work, each agent schedules a series of
CHECKS. Each check is a STUN request/response transaction that the CHECKS. Each check is a STUN request/response transaction that the
client will perform on a particular candidate pair by sending a STUN client will perform on a particular candidate pair by sending a STUN
request from the local candidate to the remote candidate. request from the local candidate to the remote candidate.
The basic principle of the connectivity checks is simple: The basic principle of the connectivity checks is simple:
1. Sort the candidate pairs in priority order. 1. Sort the candidate pairs in priority order.
2. Send checks on each candidate pair in priority order. 2. Send checks on each candidate pair in priority order.
skipping to change at page 13, line 42 skipping to change at page 14, line 42
The network properties are likely to be very similar for each The network properties are likely to be very similar for each
component (especially because RTP and RTCP are sent and received from component (especially because RTP and RTCP are sent and received from
the same IP address). It is usually possible to leverage information the same IP address). It is usually possible to leverage information
from one media component in order to determine the best candidates from one media component in order to determine the best candidates
for another. ICE does this with a mechanism called "frozen for another. ICE does this with a mechanism called "frozen
candidates." candidates."
Each candidate is associated with a property called its FOUNDATION. Each candidate is associated with a property called its FOUNDATION.
Two candidates have the same foundation when they are "similar" - of Two candidates have the same foundation when they are "similar" - of
the same type and obtained from the same interface and STUN server the same type and obtained from the same host candidate and STUN
using the same protocol. Otherwise, their foundation is different. server using the same protocol. Otherwise, their foundation is
A candidate pair has a foundation too, which is just the different. A candidate pair has a foundation too, which is just the
concatenation of the foundations of its two candidates. Initially, concatenation of the foundations of its two candidates. Initially,
only the candidate pairs with unique foundations are tested. The only the candidate pairs with unique foundations are tested. The
other candidate pairs are marked "frozen". When the connectivity other candidate pairs are marked "frozen". When the connectivity
checks for a candidate pair succeed, the other candidate pairs with checks for a candidate pair succeed, the other candidate pairs with
the same foundation are unfrozen. This avoids repeated checking of the same foundation are unfrozen. This avoids repeated checking of
components which are superficially more attractive but in fact are components which are superficially more attractive but in fact are
likely to fail. likely to fail.
While we've described "frozen" here as a separate mechanism for While we've described "frozen" here as a separate mechanism for
expository purposes, in fact it is an integral part of ICE and the expository purposes, in fact it is an integral part of ICE and the
skipping to change at page 14, line 19 skipping to change at page 15, line 19
2.5. Security for Checks 2.5. Security for Checks
Because ICE is used to discover which addresses can be used to send Because ICE is used to discover which addresses can be used to send
media between two agents, it is important to ensure that the process media between two agents, it is important to ensure that the process
cannot be hijacked to send media to the wrong location. Each STUN cannot be hijacked to send media to the wrong location. Each STUN
connectivity check is covered by a message authentication code (MAC) connectivity check is covered by a message authentication code (MAC)
computed using a key exchanged in the signalling channel. This MAC computed using a key exchanged in the signalling channel. This MAC
provides message integrity and data origin authentication, thus provides message integrity and data origin authentication, thus
stopping an attacker from forging or modifying connectivity check stopping an attacker from forging or modifying connectivity check
messages. The MAC also aids in disambiguating ICE exchanges from messages. Furthermore, if the SIP [RFC3261] caller is using ICE, and
forked calls when ICE is used with SIP [RFC3261]. their call forks, the ICE exchanges happen independently with each
forked recipient. In such a case, the keys exchanged in the
signaling help associate each ICE exchange with each forked
recipient.
2.6. Concluding ICE 2.6. Concluding ICE
ICE checks are performed in a specific sequence, so that high ICE checks are performed in a specific sequence, so that high
priority candidate pairs are checked first, followed by lower priority candidate pairs are checked first, followed by lower
priority ones. One way to conclude ICE is to declare victory as soon priority ones. One way to conclude ICE is to declare victory as soon
as a check for each component of each media stream completes as a check for each component of each media stream completes
successfully. Indeed, this is a reasonable algorithm, and details successfully. Indeed, this is a reasonable algorithm, and details
for it are provided below. However, it is possible that packet for it are provided below. However, it is possible that a packet
losses will cause a higher priority check to take longer to complete. loss will cause a higher priority check to take longer to complete.
In that case, allowing ICE to run a little longer might produce In that case, allowing ICE to run a little longer might produce
better results. More fundamentally, however, the prioritization better results. More fundamentally, however, the prioritization
defined by this specification may not yield "optimal" results. As an defined by this specification may not yield "optimal" results. As an
example, if the aim is to select low latency media paths, usage of a example, if the aim is to select low latency media paths, usage of a
relay is a hint that latencies may be higher, but it is nothing more relay is a hint that latencies may be higher, but it is nothing more
than a hint. An actual RTT measurement could be made, and it might than a hint. An actual RTT measurement could be made, and it might
demonstrate that a pair with lower priority is actually better than demonstrate that a pair with lower priority is actually better than
one with higher priority. one with higher priority.
Consequently, ICE assigns one of the agents in the role of the Consequently, ICE assigns one of the agents in the role of the
skipping to change at page 15, line 28 skipping to change at page 16, line 30
Once the STUN transaction with the flag completes, both sides cancel Once the STUN transaction with the flag completes, both sides cancel
any future checks for that media stream. ICE will now send media any future checks for that media stream. ICE will now send media
using this pair. The pair an ICE agent is using for media is called using this pair. The pair an ICE agent is using for media is called
the SELECTED PAIR. the SELECTED PAIR.
In aggressive nomination, the controlling agent puts the flag in In aggressive nomination, the controlling agent puts the flag in
every STUN request it sends. This way, once the first check every STUN request it sends. This way, once the first check
succeeds, ICE processing is complete for that media stream and the succeeds, ICE processing is complete for that media stream and the
controlling agent doesn't have to send a second STUN request. The controlling agent doesn't have to send a second STUN request. The
selected pair will be the highest priority valid pair whose check selected pair will be the highest priority valid pair whose check
succeeeded. Aggressive nomination is faster than regular nomination, succeeded. Aggressive nomination is faster than regular nomination,
but gives less flexibility. Aggressive nomination is shown in but gives less flexibility. Aggressive nomination is shown in
Figure 5. Figure 5.
L R L R
- - - -
STUN request + flag -> \ L's STUN request + flag -> \ L's
<- STUN response / check <- STUN response / check
<- STUN request \ R's <- STUN request \ R's
STUN response -> / check STUN response -> / check
skipping to change at page 17, line 20 skipping to change at page 18, line 25
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
components per media stream - one for RTP, and one for RTCP. components per media stream - one for RTP, and one for RTCP.
Host Candidate: A candidate obtained by binding to a specific port Host Candidate: A candidate obtained by binding to a specific port
from an interface on the host. This includes both physical from an IP address on the host. This includes IP addresses on
interfaces and logical ones, such as ones obtained through Virtual physical interfaces and logical ones, such as ones obtained
Private Networks (VPNs) and Realm Specific IP (RSIP) [RFC3102] through Virtual Private Networks (VPNs) and Realm Specific IP
(which lives at the operating system level). (RSIP) [RFC3102] (which lives at the operating system level).
Server Reflexive Candidate: A candidate whose IP address and port Server Reflexive Candidate: A candidate whose IP address and port
are a binding allocated by a NAT for an agent when it sent a are a binding allocated by a NAT for an agent when it sent a
packet through the NAT to a server. Server reflexive candidates packet through the NAT to a server. Server reflexive candidates
can be learned by STUN servers using the Binding Request, or TURN can be learned by STUN servers using the Binding Request, or TURN
servers, which provides both a Relayed and Server Reflexive servers, which provides both a Relayed and Server Reflexive
candidate. candidate.
Peer Reflexive Candidate: A candidate whose IP address and port are Peer Reflexive Candidate: A candidate whose IP address and port are
a binding allocated by a NAT for an agent when it sent a STUN a binding allocated by a NAT for an agent when it sent a STUN
skipping to change at page 19, line 35 skipping to change at page 20, line 41
media. media.
Selected Pair, Selected Candidate: The candidate pair selected by Selected Pair, Selected Candidate: The candidate pair selected by
ICE for sending and receiving media is called the selected pair, ICE for sending and receiving media is called the selected pair,
and each of its candidates is called the selected candidate. and each of its candidates is called the selected candidate.
4. Sending the Initial Offer 4. Sending the Initial Offer
In order to send the initial offer in an offer/answer exchange, an In order to send the initial offer in an offer/answer exchange, an
agent must (1) gather candidates, (2) prioritize them, (3) choose agent must (1) gather candidates, (2) prioritize them, (3) choose
default candidates, and then (4) formulate and send the SDP. The default candidates, and then (4) formulate and send the SDP offer.
first of these four steps differ for full and lite implementations. All but the last of these four steps differ for full and lite
implementations.
4.1. Full Implementation Requirements 4.1. Full Implementation Requirements
4.1.1. Gathering Candidates 4.1.1. Gathering Candidates
An agent gathers candidates when it believes that communications is An agent gathers candidates when it believes that communications is
imminent. An offerer can do this based on a user interface cue, or imminent. An offerer can do this based on a user interface cue, or
based on an explicit request to initiate a session. Every candidate based on an explicit request to initiate a session. Every candidate
is a transport address. It also has a type and a base. Three types is a transport address. It also has a type and a base. Four types
are defined and gathered by this specification - host candidates, are defined and gathered by this specification - host candidates,
server reflexive candidates, and relayed candidates. The server server reflexive candidates, peer reflexive candidates, and relayed
reflexive and relayed candidates are gathered using STUN or TURN, and candidates. The server reflexive and relayed candidates are gathered
relayed candidates are obtained through TURN. The base of a using STUN or TURN, and relayed candidates are obtained through TURN.
candidate is the candidate that an agent must send from when using Peer reflexive candidates are obtained in later phases of ICE, as a
that candidate. consequence of connectivity checks. The base of a candidate is the
candidate that an agent must send from when using that candidate.
4.1.1.1. Host Candidates 4.1.1.1. Host Candidates
The first step is to gather host candidates. Host candidates are The first step is to gather host candidates. Host candidates are
obtained by binding to ports (typically ephemeral) on an interface obtained by binding to ports (typically ephemeral) on a IP address
(physical or virtual, including VPN interfaces) on the host. The attached to an interface (physical or virtual, including VPN
process for gathering host candidates depends on the transport interfaces) on the host.
protocol. Procedures are specified here for UDP.
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 obtain a candidate for each component of the media stream on each IP
interface that the host has. It obtains each candidate by binding to address that the host has. It obtains each candidate by binding to a
a UDP port on the specific interface. A host candidate (and indeed UDP port on the specific IP address. A host candidate (and indeed
every candidate) is always associated with a specific component for every candidate) is always associated with a specific component for
which it is a candidate. Each component has an ID assigned to it, which it is a candidate. Each component has an ID assigned to it,
called the component ID. For RTP-based media streams, the RTP itself called the component ID. For RTP-based media streams, the RTP itself
has a component ID of 1, and RTCP a component ID of 2. If an agent has a component ID of 1, and RTCP a component ID of 2. If an agent
is using RTCP it MUST obtain a candidate for it. If an agent is is using RTCP it MUST obtain a candidate for it. If an agent is
using both RTP and RTCP, it would end up with 2*K host candidates if using both RTP and RTCP, it would end up with 2*K host candidates if
an agent has K interfaces. an agent has K IP addresses.
The base for each host candidate is set to the candidate itself. The base for each host candidate is set to the candidate itself.
4.1.1.2. Server Reflexive and Relayed Candidates 4.1.1.2. Server Reflexive and Relayed Candidates
Agents SHOULD obtain relayed candidates and SHOULD obtain server Agents SHOULD obtain relayed candidates and SHOULD obtain server
reflexive candidates. These requirements are at SHOULD strength to reflexive candidates. These requirements are at SHOULD strength to
allow for provider variation. Use of STUN and TURN servers may be allow for provider variation. Use of STUN and TURN servers may be
unnecessary in closed networks where agents are never connected to unnecessary in closed networks where agents are never connected to
the public Internet or to endpoints outside of the closed network. the public Internet or to endpoints outside of the closed network.
skipping to change at page 21, line 22 skipping to change at page 22, line 31
multiple results are returned), an agent SHOULD use a single STUN or multiple results are returned), an agent SHOULD use a single STUN or
TURN server (based on its IP address) for all candidates for a TURN server (based on its IP address) for all candidates for a
particular session. This improves the performance of ICE. The particular session. This improves the performance of ICE. The
result is a set of pairs of host candidates with STUN or TURN result is a set of pairs of host candidates with STUN or TURN
servers. The agent then chooses one pair, and sends a Binding or servers. The agent then chooses one pair, and sends a Binding or
Allocate request to the server from that host candidate. Binding Allocate request to the server from that host candidate. Binding
Requests to a STUN server are not authenticated, and any ALTERNATE- Requests to a STUN server are not authenticated, and any ALTERNATE-
SERVER attribute in a response is ignored. Agents MUST support the SERVER attribute in a response is ignored. Agents MUST support the
backwards compatibility mode for the Binding Request defined in backwards compatibility mode for the Binding Request defined in
[I-D.ietf-behave-rfc3489bis]. Allocate requests SHOULD be [I-D.ietf-behave-rfc3489bis]. Allocate requests SHOULD be
authenticated using a long-term credential provisioned into the authenticated using a long-term credential obtained by the client
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 which failed with a recoverable error (such as a previous transaction which 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 16 for guidance on how to set Ta and the STUN retransmit Section 16 for guidance on how to set Ta and the STUN retransmit
timer, RTO. timer, RTO.
skipping to change at page 21, line 48 skipping to change at page 23, line 8
because the server lacks resources to fulfill it, the agent SHOULD because the server lacks resources to fulfill it, the agent SHOULD
instead send a Binding Request to obtain a server reflexive 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).
The base of the server reflexive candidate is the host candidate from The base of the server reflexive candidate is the host candidate from
which the Allocate or Binding request was sent. The base of a which the Allocate or Binding request was sent. The base of a
relayed candidate is that candidate itself. If a relayed candidate relayed candidate is that candidate itself. If a relayed candidate
is identical to a host candidate (which can happen in rare cases), is identical to a host candidate (which can happen in rare cases),
the relayed candidate MUST be discarded. the relayed candidate MUST be discarded.
4.1.1.3. Eliminating Redundant Candidates 4.1.1.3. Computing Foundations
Next, the agent eliminates redundant candidates. A candidate is
redundant if its transport address equals another candidate, and its
base equals the base of that other candidate. Note that two
candidates can have the same transport address yet have different
bases, and these would not be considered redundant. Frequently, a
server reflexive candidate and a host candidate will be redundant
when the agent is not behind a NAT.
4.1.1.4. Computing Foundations
Finally, the agent assigns each candidate a foundation. The Finally, the agent assigns each candidate a foundation. The
foundation is an identifier, scoped within a session. Two candidates foundation is an identifier, scoped within a session. Two candidates
MUST have the same foundation ID when all of the following are true: MUST have the same foundation ID when all of the following are true:
o they are of the same type (host, relayed, server reflexive, or o they are of the same type (host, relayed, server reflexive, or
peer reflexive) peer reflexive)
o their bases have the same IP address (the ports can be different) o their bases have the same IP address (the ports can be different)
skipping to change at page 22, line 32 skipping to change at page 23, line 30
used to obtain them have the same IP address. used to obtain them have the same IP address.
o they were obtained using the same transport protocol (TCP, UDP, o they were obtained using the same transport protocol (TCP, UDP,
etc.) etc.)
Similarly, two candidates MUST have different foundations if their Similarly, two candidates MUST have different foundations if their
types are different, their bases have different IP addresses, the types are different, their bases have different IP addresses, the
STUN or TURN servers used to obtain them have different IP addresses, STUN or TURN servers used to obtain them have different IP addresses,
or their transport protocols are different. or their transport protocols are different.
4.1.1.5. Keeping Candidates Alive 4.1.1.4. Keeping Candidates Alive
Once server reflexive and relayed candidates are allocated, they MUST Once server reflexive and relayed candidates are allocated, they MUST
be kept alive until ICE processing has completed, as described in be kept alive until ICE processing has completed, as described in
Section 8.3. For server reflexive candidates learned through a Section 8.3. For server reflexive candidates learned through a
Binding request, the bindings MUST be kept alive by another Binding Binding request, the bindings MUST be kept alive by additional
Request to the server. For relayed candidates learned through an Binding Requests to the server. For relayed candidates learned
Allocate request, the keepalive MUST be a new Allocate request. The through an Allocate request, the keepalive MUST be new Allocate
Allocate request will also refresh the server reflexive candidate. requests. The Allocate requests will also refresh the server
reflexive candidate.
4.1.2. Prioritizing Candidates 4.1.2. Prioritizing Candidates
The prioritization process results in the assignment of a priority to The prioritization process results in the assignment of a priority to
each candidate. Each candidate for a media stream MUST have a unique each candidate. Each candidate for a media stream MUST have a unique
priority that MUST be a positive integer between 1 and (2**32 - 1). priority that MUST be a positive integer between 1 and (2**32 - 1).
This priority will be used by ICE to determine the order of the This priority will be used by ICE to determine the order of the
connectivity checks and the relative preference for candidates. connectivity checks and the relative preference for candidates.
An agent SHOULD compute this priority using the formula in An agent SHOULD compute this priority using the formula in
Section 4.1.2.1 and choose its parameters using the guidelines in Section 4.1.2.1 and choose its parameters using the guidelines in
Section 4.1.2.2. If an agent elects to use a different formula, ICE Section 4.1.2.2. If an agent elects to use a different formula, ICE
will take longer to converge since both agents will not be will take longer to converge since both agents will not be
coordinated in their checks. coordinated in their checks.
4.1.2.1. Recommended Formula 4.1.2.1. Recommended Formula
When using the formula, an agent computes the priority by determining When using the formula, an agent computes the priority by determining
a preference for each type of candidate (server reflexive, peer a preference for each type of candidate (server reflexive, peer
reflexive, relayed and host), and, when the agent is multihomed, reflexive, relayed and host), and, when the agent is multihomed,
choosing a preference for its interfaces. These two preferences are choosing a preference for its IP addresses. These two preferences
then combined to compute the priority for a candidate. That priority are then combined to compute the priority for a candidate. That
is computed using the following formula: priority is computed using the following formula:
priority = (2^24)*(type preference) + priority = (2^24)*(type preference) +
(2^8)*(local preference) + (2^8)*(local preference) +
(2^0)*(256 - component ID) (2^0)*(256 - component ID)
The type preference MUST be an integer from 0 to 126 inclusive, and The type preference MUST be an integer from 0 to 126 inclusive, and
represents the preference for the type of the candidate (where the represents the preference for the type of the candidate (where the
types are local, server reflexive, peer reflexive and relayed). A types are local, server reflexive, peer reflexive and relayed). A
126 is the highest preference, and a 0 is the lowest. Setting the 126 is the highest preference, and a 0 is the lowest. Setting the
value to a 0 means that candidates of this type will only be used as value to a 0 means that candidates of this type will only be used as
a last resort. The type preference MUST be identical for all a last resort. The type preference MUST be identical for all
candidates of the same type and MUST be different for candidates of candidates of the same type and MUST be different for candidates of
different types. The type preference for peer reflexive candidates different types. The type preference for peer reflexive candidates
MUST be higher than that of server reflexive candidates. Note that MUST be higher than that of server reflexive candidates. Note that
candidates gathered based on the procedures of Section 4.1.1 will candidates gathered based on the procedures of Section 4.1.1 will
never be peer reflexive candidates; candidates of these type are never be peer reflexive candidates; candidates of these type are
learned from the connectivity checks performed by ICE. learned from the connectivity checks performed by ICE.
The local preference MUST be an integer from 0 to 65535 inclusive. The local preference MUST be an integer from 0 to 65535 inclusive.
It represents a preference for the particular interface from which It represents a preference for the particular IP address from which
the candidate was obtained, in cases where an agent is multihomed. the candidate was obtained, in cases where an agent is multihomed.
65535 represents the highest preference, and a zero, the lowest. 65535 represents the highest preference, and a zero, the lowest.
When there is only a single interface, this value SHOULD be set to When there is only a single IP address, this value SHOULD be set to
65535. More generally, if there are multiple candidates for a 65535. More generally, if there are multiple candidates for a
particular component for a particular media stream which have the particular component for a particular media stream which have the
same type, the local preference MUST be unique for each one. In this same type, the local preference MUST be unique for each one. In this
specification, this only happens for multi-homed hosts. specification, this only happens for multi-homed hosts. If a host is
multi-homed because it is dual stacked, the local preference SHOULD
be set equal to the precedence value for IP addresses described in
RFC 3484 [RFC3484].
The component ID is the component ID for the candidate, and MUST be The component ID is the component ID for the candidate, and MUST be
between 1 and 256 inclusive. between 1 and 256 inclusive.
4.1.2.2. Guidelines for Choosing Type and Local Preferences 4.1.2.2. Guidelines for Choosing Type and Local Preferences
One criteria for selection of the type and local preference values is One criteria for selection of the type and local preference values is
the use of a media intermediary, such as a TURN server, VPN server or the use of a media intermediary, such as a TURN server, VPN server or
NAT. With a media intermediary, if media is sent to that candidate, NAT. With a media intermediary, if media is sent to that candidate,
it will first transit the media intermediary before being received. it will first transit the media intermediary before being received.
skipping to change at page 24, line 23 skipping to change at page 25, line 23
interface. When media is transited through a media intermediary, it interface. When media is transited through a media intermediary, it
can increase the latency between transmission and reception. It can can increase the latency between transmission and reception. It can
increase the packet losses, because of the additional router hops increase the packet losses, because of the additional router hops
that may be taken. It may increase the cost of providing service, that may be taken. It may increase the cost of providing service,
since media will be routed in and right back out of a media since media will be routed in and right back out of a media
intermediary run by a provider. If these concerns are important, the intermediary run by a provider. If these concerns are important, the
type preference for relayed candidates SHOULD be lower than host type preference for relayed candidates SHOULD be lower than host
candidates. The RECOMMENDED values are 126 for host candidates, 100 candidates. The RECOMMENDED values are 126 for host candidates, 100
for server reflexive candidates, 110 for peer reflexive candidates, for server reflexive candidates, 110 for peer reflexive candidates,
and 0 for relayed candidates. Furthermore, if an agent is multi- and 0 for relayed candidates. Furthermore, if an agent is multi-
homed and has multiple interfaces, the local preference for host homed and has multiple IP addresses, the local preference for host
candidates from a VPN interface SHOULD have a priority of 0. candidates from a VPN interface SHOULD have a priority of 0.
Another criteria for selection of preferences is IP address family. Another criteria for selection of preferences is IP address family.
ICE works with both IPv4 and IPv6. It therefore provides a ICE works with both IPv4 and IPv6. It therefore provides a
transition mechanism that allows dual-stack hosts to prefer transition mechanism that allows dual-stack hosts to prefer
connectivity over IPv6, but to fall back to IPv4 in case the v6 connectivity over IPv6, but to fall back to IPv4 in case the v6
networks are disconnected (due, for example, to a failure in a 6to4 networks are disconnected (due, for example, to a failure in a 6to4
relay) [RFC3056]. It can also help with hosts that have both a relay) [RFC3056]. It can also help with hosts that have both a
native IPv6 address and a 6to4 address. In such a case, higher local native IPv6 address and a 6to4 address. In such a case, higher local
preferences could be assigned to the v6 interface, followed by the preferences could be assigned to the v6 addresses, followed by the
6to4 interfaces, followed by the v4 interfaces. This allows a site 6to4 addresses, followed by the v4 addresses. This allows a site to
to obtain and begin using native v6 addresses immediately, yet still obtain and begin using native v6 addresses immediately, yet still
fallback to 6to4 addresses when communicating with agents in other fallback to 6to4 addresses when communicating with agents in other
sites that do not yet have native v6 connectivity. sites that do not yet have native v6 connectivity.
Another criteria for selecting preferences is security. If a user is Another criteria for selecting preferences is security. If a user is
a telecommuter, and therefore connected to their corporate network a telecommuter, and therefore connected to their corporate network
and a local home network, they may prefer their voice traffic to be and a local home network, they may prefer their voice traffic to be
routed over the VPN in order to keep it on the corporate network when routed over the VPN in order to keep it on the corporate network when
communicating within the enterprise, but use the local network when communicating within the enterprise, but use the local network when
communicating with users outside of the enterprise. In such a case, communicating with users outside of the enterprise. In such a case,
a VPN interface would have a higher local preference than any other a VPN address would have a higher local preference than any other
interface. address.
Another criteria for selecting preferences is topological awareness. Another criteria for selecting preferences is topological awareness.
This is most useful for candidates that make use of intermediaries. This is most useful for candidates that make use of intermediaries.
In those cases, if an agent has preconfigured or dynamically In those cases, if an agent has preconfigured or dynamically
discovered knowledge of the topological proximity of the discovered knowledge of the topological proximity of the
intermediaries to itself, it can use that to assign higher local intermediaries to itself, it can use that to assign higher local
preferences to candidates obtained from closer intermediaries. preferences to candidates obtained from closer intermediaries.
4.1.3. Choosing Default Candidates 4.1.3. Eliminating Redundant Candidates
Next, the agent eliminates redundant candidates. A candidate is
redundant if its transport address equals another candidate, and its
base equals the base of that other candidate. Note that two
candidates can have the same transport address yet have different
bases, and these would not be considered redundant. Frequently, a
server reflexive candidate and a host candidate will be redundant
when the agent is not behind a NAT. The agent SHOULD eliminate the
redundant candididate with the lower priority.
4.1.4. Choosing Default Candidates
A candidate is said to be default if it would be the target of media A candidate is said to be default if it would be the target of media
from a non-ICE peer; that target being called the DEFAULT from a non-ICE peer; that target being called the DEFAULT
DESTINATION. If the default candidates are not selected by the ICE DESTINATION. If the default candidates are not selected by the ICE
algorithm when communicating with an ICE-aware peer, an updated algorithm when communicating with an ICE-aware peer, an updated
offer/answer will be required after ICE processing completes in order offer/answer will be required after ICE processing completes in order
to "fix-up" the SDP so that the default destination for media matches to "fix-up" the SDP so that the default destination for media matches
the candidates selected by ICE. If ICE happens to select the default the candidates selected by ICE. If ICE happens to select the default
candidates, no updated offer/answer is required. candidates, no updated offer/answer is required.
skipping to change at page 25, line 38 skipping to change at page 26, line 49
and finally host candidates. and finally host candidates.
4.2. Lite Implementation 4.2. Lite Implementation
Lite implementations only utilize host candidates. A lite Lite implementations only utilize host candidates. A lite
implementation MUST, for each component of each media stream, implementation MUST, for each component of each media stream,
allocate zero or one IPv4 candidates. It MAY allocate zero or more allocate zero or one IPv4 candidates. It MAY allocate zero or more
IPv6 candidates, but no more than one per each IPv6 address utilized IPv6 candidates, but no more than one per each IPv6 address utilized
by the host. Since there can be no more than one IPv4 candidate per by the host. Since there can be no more than one IPv4 candidate per
component of each media stream, if an agent has multiple IPv4 component of each media stream, if an agent has multiple IPv4
interfaces, it MUST choose one for allocating the candidate. If a addresses, it MUST choose one for allocating the candidate. If a
host is dual-stack, it is RECOMMENDED that it allocate one IPv4 host is dual-stack, it is RECOMMENDED that it allocate one IPv4
candidate and one global IPv6 address. With the lite implementation, candidate and one global IPv6 address. With the lite implementation,
ICE cannot be used to dynamically choose amongst candidates. ICE cannot be used to dynamically choose amongst candidates.
Therefore, including more than one candidate from a particular scope Therefore, including more than one candidate from a particular scope
is NOT RECOMMENDED, since only a connectivity check can truly is NOT RECOMMENDED, since only a connectivity check can truly
determine whether to use one address or the other. determine whether to use one address or the other.
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
skipping to change at page 26, line 15 skipping to change at page 27, line 26
and MUST be the same otherwise. A simple integer that increments for and MUST be the same otherwise. A simple integer that increments for
each IP address will suffice. In addition, each candidate MUST be each IP address will suffice. In addition, each candidate MUST be
assigned a unique priority amongst all candidates for the same media assigned a unique priority amongst all candidates for the same media
stream. This priority SHOULD be equal to: stream. This priority SHOULD be equal to:
priority = (2^24)*(126) + priority = (2^24)*(126) +
(2^8)*(IP precedence) + (2^8)*(IP precedence) +
(2^0)*(256 - component ID) (2^0)*(256 - component ID)
If a host is v4-only, it SHOULD set the IP precedence to 65535. If a If a host is v4-only, it SHOULD set the IP precedence to 65535. If a
host is v6 or dual-stack, the IP precedence is the precedence value host is v6 or dual-stack, the IP precedence SHOULD be the precedence
for IP addresses described in RFC 3484 [RFC3484]. value for IP addresses described in RFC 3484 [RFC3484].
Next, an agent chooses a default candidate for each component of each Next, an agent chooses a default candidate for each component of each
media stream. If a host is IPv4 only, there would only be one media stream. If a host is IPv4 only, there would only be one
candidate for each component of each media stream, and therefore that candidate for each component of each media stream, and therefore that
candidate is the default. If a host is IPv6 or dual stack, the candidate is the default. If a host is IPv6 or dual stack, the
selection of default is a matter of local policy. This default selection of default is a matter of local policy. This default
SHOULD be chosen, such that, it is the candidate most likely to be SHOULD be chosen, such that, it is the candidate most likely to be
used with a peer. For IPv6-only hosts, this would typically by a used with a peer. For IPv6-only hosts, this would typically by a
globally scoped IPv6 address. For dual-stack hosts, the IPv4 address globally scoped IPv6 address. For dual-stack hosts, the IPv4 address
is RECOMMENDED. is RECOMMENDED.
skipping to change at page 30, line 43 skipping to change at page 31, line 43
5.4. Prioritizing Candidates 5.4. Prioritizing Candidates
The process for prioritizing candidates at the answerer is identical The process for prioritizing candidates at the answerer is identical
to the process followed by the offerer, as described in Section 4.1.2 to the process followed by the offerer, as described in Section 4.1.2
for full implementations and Section 4.2 for lite implementations. for full implementations and Section 4.2 for lite implementations.
5.5. Choosing Default Candidates 5.5. Choosing Default Candidates
The process for selecting default candidates at the answerer is The process for selecting default candidates at the answerer is
identical to the process followed by the offerer, as described in identical to the process followed by the offerer, as described in
Section 4.1.3 for full implementations and Section 4.2 for lite Section 4.1.4 for full implementations and Section 4.2 for lite
implementations. implementations.
5.6. Encoding the SDP 5.6. Encoding the SDP
The process for encoding the SDP at the answerer is identical to the The process for encoding the SDP at the answerer is identical to the
process followed by the offerer for both full and lite process followed by the offerer for both full and lite
implementations, as described in Section 4.3. implementations, as described in Section 4.3.
5.7. Forming the Check Lists 5.7. Forming the Check Lists
skipping to change at page 33, line 38 skipping to change at page 34, line 38
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 18.5.2, an agent SHOULD limit the total number of Section 18.5.2, an agent SHOULD limit the total number of
connectivity checks they perform across all check lists to 100, by connectivity checks they perform across all check lists to a
discarding the lower priority candidate pairs until there are less configurable value. A default of 100 is RECOMMENDED. This limit is
than 100. enforced by discarding the lower priority candidate pairs until there
are less than 100. It is RECOMMENDED that a lower value be utilized
when possible, set to the maximum number of plausible checks that
might be seen in an actual deployment configuration.
5.7.4. Computing States 5.7.4. Computing States
Each candidate pair in the check list has a foundation and a state. Each candidate pair in the check list has a foundation and a state.
The foundation is the combination of the foundations of the local and The foundation is the combination of the foundations of the local and
remote candidates in the pair. The state is assigned once the check remote candidates in the pair. The state is assigned once the check
list for each media stream has been computed. There are five list for each media stream has been computed. There are five
potential values that the state can have: potential values that the state can have:
Waiting: A check has not been performed for this pair, and can be Waiting: A check has not been performed for this pair, and can be
skipping to change at page 40, line 14 skipping to change at page 41, line 14
7.1.1.1. PRIORITY and USE-CANDIDATE 7.1.1.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.2.2.1 for how peer reflexive candidates are check (see Section 7.1.2.2.1 for how peer reflexive candidates are
learned). This priority value will be computed identically to how learned). This priority value will be computed identically to how
the priority for the local candidate of the pair was computed, except the priority for the local candidate of the pair was computed, except
that the type preference is set to the value for peer derived that the type preference is set to the value for peer reflexive
candidate types. candidate types.
The controlling agent MAY include the USE-CANDIDATE attribute in the The controlling agent MAY include the USE-CANDIDATE attribute in the
Binding Request. The controlled agent MUST NOT include it in its Binding Request. The controlled agent MUST NOT include it in its
Binding Request. This attribute signals that the controlling agent Binding Request. This attribute signals that the controlling agent
wishes to cease checks for this component, and use the candidate pair wishes to cease checks for this component, and use the candidate pair
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.1.2. ICE-CONTROLLED and ICE-CONTROLLING 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING
skipping to change at page 63, line 34 skipping to change at page 64, line 34
[I-D.ietf-avt-rtp-no-op], and in cases where both sides support it, [I-D.ietf-avt-rtp-no-op], and in cases where both sides support it,
RTP comfort noise [RFC3389]. If the peer doesn't support any formats RTP comfort noise [RFC3389]. If the peer doesn't support any formats
that are particularly well suited for keepalives, an agent SHOULD that are particularly well suited for keepalives, an agent SHOULD
send RTP packets with an incorrect version number, or some other form send RTP packets with an incorrect version number, or some other form
of error which would cause them to be discarded by the peer. of error which would cause them to be discarded by the peer.
If there has been no packet sent on the candidate pair ICE is using If there has been no packet sent on the candidate pair ICE is using
for a media component for Tr seconds (where packets include those for a media component for Tr seconds (where packets include those
defined for the component (RTP or RTCP) and previous keepalives), an defined for the component (RTP or RTCP) and previous keepalives), an
agent MUST generate a keepalive on that pair. Tr SHOULD be agent MUST generate a keepalive on that pair. Tr SHOULD be
configurable and SHOULD have a default of 15 seconds. Alternatively, configurable and SHOULD have a default of 15 seconds. Tr MUST NOT be
if an agent has a dynamic way to discover the binding lifetimes of configured to less than 15 seconds. Alternatively, if an agent has a
the intervening NATs, it can use that value to determine Tr. dynamic way to discover the binding lifetimes of the intervening
NATs, it can use that value to determine Tr. Administrators
deploying ICE in more controlled networking environments SHOULD set
Tr to the longest duration possible in their environment.
If STUN is being used for keepalives, a STUN Binding Indication is If STUN is being used for keepalives, a STUN Binding Indication is
used [I-D.ietf-behave-rfc3489bis]. The Indication MUST NOT utilize used [I-D.ietf-behave-rfc3489bis]. The Indication MUST NOT utilize
any authentication mechanism, and SHOULD NOT contain any attributes. any authentication mechanism, and SHOULD NOT contain any attributes.
It is used solely to keep the NAT bindings alive. The Binding It is used solely to keep the NAT bindings alive. The Binding
Indication is sent using the same local and remote candidates that Indication is sent using the same local and remote candidates that
are being used for media. Though Binding Indications are used for are being used for media. Though Binding Indications are used for
keepalives, an agent MUST be prepared to receive a connectivity check keepalives, an agent MUST be prepared to receive a connectivity check
as well. If a connectivity check is received, a response is as well. If a connectivity check is received, a response is
generated as discussed in [I-D.ietf-behave-rfc3489bis], but there is generated as discussed in [I-D.ietf-behave-rfc3489bis], but there is
skipping to change at page 69, line 31 skipping to change at page 70, line 35
The flows for continued operation, as described in Section 7 of RFC The flows for continued operation, as described in Section 7 of RFC
3725, require additional behavior of ICE implementations to support. 3725, require additional behavior of ICE implementations to support.
In particular, if an agent receives a mid-dialog re-INVITE that In particular, if an agent receives a mid-dialog re-INVITE that
contains no offer, it MUST restart ICE for each media stream and go contains no offer, it MUST restart ICE for each media stream and go
through the process of gathering new candidates. Furthermore, that through the process of gathering new candidates. Furthermore, that
list of candidates SHOULD include the ones currently being used for list of candidates SHOULD include the ones currently being used for
media. media.
13. Relationship with ANAT 13. Relationship with ANAT
RFC 4091 [RFC4091] defines a mechanism for indicating that an agent RFC 4091 [RFC4091], the Alternative Network Address Types (ANAT)
can support both IPv4 and IPv6 for a media stream, and it does so by Semantics for the SDP grouping framework, defines a mechanism for
including two m-lines, one for v4, and one for v6. This is similar indicating that an agent can support both IPv4 and IPv6 for a media
to ICE, which allows for an agent to indicate multiple transport stream, and it does so by including two m-lines, one for v4, and one
addresses using the candidate attribute. However, ANAT relies on for v6. This is similar to ICE, which allows for an agent to
static selection to pick between choices, rather than a dynamic indicate multiple transport addresses using the candidate attribute.
connectivity check used by ICE. However, ANAT relies on static selection to pick between choices,
rather than a dynamic connectivity check used by ICE.
This specification deprecates RFC 4091. Instead, agents wishing to This specification deprecates RFC 4091. Instead, agents wishing to
support dual-stack will utilize ICE. Because a dual-stack agent will support dual-stack will utilize ICE. Because a dual-stack agent will
require at least two candidates, one for IPv4 and one for IPv6, dual- require at least two candidates, one for IPv4 and one for IPv6, dual-
stack agents MUST be full implementations. However, agents that are stack agents MUST be full implementations. However, agents that are
implementing dual-stack and are running on closed networks where it implementing dual-stack and are running on closed networks where it
is known that there are no NAT, MAY include only host candidates in is known that there are no NAT, MAY include only host candidates in
their offers, skipping server reflexive and relayed candidates. their offers, skipping server reflexive and relayed candidates.
14. Extensibility Considerations 14. Extensibility Considerations
skipping to change at page 70, line 20 skipping to change at page 71, line 25
First, ICE provides the a=ice-options SDP attribute. Each extension First, ICE provides the a=ice-options SDP attribute. Each extension
or change to ICE is associated with a token. When an agent or change to ICE is associated with a token. When an agent
supporting such an extension or change generates an offer or an supporting such an extension or change generates an offer or an
answer, it MUST include the token for that extension in this answer, it MUST include the token for that extension in this
attribute. This allows each side to know what the other side is attribute. This allows each side to know what the other side is
doing. This attribute MUST NOT be present if the agent doesn't doing. This attribute MUST NOT be present if the agent doesn't
support any ICE extensions or changes. support any ICE extensions or changes.
At this time, no IANA registry or registration procedures are defined At this time, no IANA registry or registration procedures are defined
for these option tags. At time of writing, it is unclear whether ICE for these option tags. At time of writing, it is unclear whether ICE
changes and extensions will be sufficiently common to warrrant a changes and extensions will be sufficiently common to warrant a
registry. registry.
One of the complications in achieving interoperability is that ICE One of the complications in achieving interoperability is that ICE
relies on a distributed algorithm running on both agents to converge relies on a distributed algorithm running on both agents to converge
on an agreed set of candidate pairs. If the two agents run different on an agreed set of candidate pairs. If the two agents run different
algorithms, it can be difficult to guarantee convergence on the same algorithms, it can be difficult to guarantee convergence on the same
candidate pairs. The regular nomination procedure described in candidate pairs. The regular nomination procedure described in
Section 8 eliminates some of the tight coordination by delegating the Section 8 eliminates some of the tight coordination by delegating the
selection algorithm completely to the controlling agent. selection algorithm completely to the controlling agent.
Consequently, when a controlling agent is communicating with a peer Consequently, when a controlling agent is communicating with a peer
skipping to change at page 73, line 48 skipping to change at page 75, line 13
offer arrived with a default destination for a media component that offer arrived with a default destination for a media component that
didn't have a corresponding candidate attribute. didn't have a corresponding candidate attribute.
15.4. "ice-ufrag" and "ice-pwd" Attributes 15.4. "ice-ufrag" and "ice-pwd" Attributes
The "ice-ufrag" and "ice-pwd" attributes convey the username fragment The "ice-ufrag" and "ice-pwd" attributes convey the username fragment
and password used by ICE for message integrity. Their syntax is: and password used by ICE for message integrity. Their syntax is:
ice-pwd-att = "ice-pwd" ":" password ice-pwd-att = "ice-pwd" ":" password
ice-ufrag-att = "ice-ufrag" ":" ufrag ice-ufrag-att = "ice-ufrag" ":" ufrag
password = 22*1024ice-char password = 22*256ice-char
ufrag = 4*1024ice-char ufrag = 4*256ice-char
The "ice-pwd" and "ice-ufrag" attributes can appear at either the The "ice-pwd" and "ice-ufrag" attributes can appear at either the
session-level or media-level. When present in both, the value in the session-level or media-level. When present in both, the value in the
media-level takes precedence. Thus, the value at the session level media-level takes precedence. Thus, the value at the session level
is effectively a default that applies to all media streams, unless is effectively a default that applies to all media streams, unless
overriden by a media-level value. Whether present at the session or overriden by a media-level value. Whether present at the session or
media level, there MUST be an ice-pwd and ice-ufrag attribute for media level, there MUST be an ice-pwd and ice-ufrag attribute for
each media stream. If two media streams have identical ice-ufrag's, each media stream. If two media streams have identical ice-ufrag's,
they MUST have identical ice-pwd's. they MUST have identical ice-pwd's.
The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the
beginning of a session. The ice-ufrag attribute MUST contain at beginning of a session. The ice-ufrag attribute MUST contain at
least 24 bits of randomness, and the ice-pwd attribute MUST contain least 24 bits of randomness, and the ice-pwd attribute MUST contain
at least 128 bits of randomness. This means that the ice-ufrag at least 128 bits of randomness. This means that the ice-ufrag
attribute will be at least 4 characters long, and the ice-pwd at attribute will be at least 4 characters long, and the ice-pwd at
least 22 characters long, since the grammar for these attributes least 22 characters long, since the grammar for these attributes
allows for 6 bits of randomness per character. The attributes MAY be allows for 6 bits of randomness per character. The attributes MAY be
longer than 4 and 22 characters respectively, of course, up to 1024 longer than 4 and 22 characters respectively, of course, up to 256
characters. The upper limit allows for buffer sizing in characters. The upper limit allows for buffer sizing in
implementations. Its large upper limit allows for increased amounts implementations. Its large upper limit allows for increased amounts
of randomness to be added over time. of randomness to be added over time.
15.5. "ice-options" Attribute 15.5. "ice-options" Attribute
The "ice-options" attribute is a session level attribute. It The "ice-options" attribute is a session level attribute. It
contains a series of tokens which identify the options supported by contains a series of tokens which identify the options supported by
the agent. Its grammar is: the agent. Its grammar is:
ice-options = "ice-options" ":" ice-option-tag ice-options = "ice-options" ":" ice-option-tag
0*(SP ice-option-tag) 0*(SP ice-option-tag)
ice-option-tag = 1*ice-char ice-option-tag = 1*ice-char
16. Setting Ta and RTO 16. 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 transcations are paced at a rate of one TURN transactions. These transcations 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 value of Ta and RTO are computed. Their values describes how the value of Ta and RTO are computed. This computation
change during the lifetime of ICE processing. One set of values depends on whether ICE is being used with a real time media stream
applies during the gathering phase, and the other, for connectivity (such as RTP) or something else.
checks.
16.1. RTP Media Streams
The values of RTP and Ta change during the lifetime of ICE
processing. One set of values applies during the gathering phase,
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
1 1
Ta = MAX (20ms, ------------------- ) Ta = MAX (20ms, ------------------- )
k k
---- ----
skipping to change at page 76, line 4 skipping to change at page 77, line 23
RTO = MAX (100ms, Ta*N * (Num-Waiting)) RTO = MAX (100ms, Ta*N * (Num-Waiting))
Where Num-Waiting are the number of checks in the check list in the Where Num-Waiting are the number of checks in the check list in the
Waiting state. Note that the RTO will be different for each Waiting state. Note that the RTO will be different for each
transaction as the number of checks in the Waiting state changes. transaction as the number of checks in the Waiting state changes.
These formulas are aimed at causing STUN transactions to be paced at These formulas are aimed at causing STUN transactions to be paced at
the same rate as media. This ensures that ICE will work properly the same rate as media. This ensures that ICE will work properly
under the same network conditions needed to support the media as under the same network conditions needed to support the media as
well. See Appendix B.1 for additional discussion and motivations. well. See Appendix B.1 for additional discussion and motivations.
Because of this pacing, it will take a certain amount of time to Because of this pacing, it will take a certain amount of time to
obtain all of the server reflexive and relayed candidates. obtain all of the server reflexive and relayed candidates.
Implementations should be aware of the time required to do this, and Implementations should be aware of the time required to do this, and
if the application requires a time budget, limit the number of if the application requires a time budget, limit the number of
candidates which are gathered. candidates which are gathered.
16.2. Non-RTP Sessions
In cases where ICE is used to establish some kind of session which is
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
more conservative values. Ta SHOULD be configurable and SHOULD have
a default of 500ms.
In addition, the retransmission timer for the STUN transactions, RTO,
SHOULD be configurable and during the gathering phase, SHOULD have a
default of:
RTO = MAX (500ms, Ta * (number of pairs))
Where the number of pairs refers to the number of pairs of candidates
with STUN or TURN servers.
For connectivity checks, RTO SHOULD be configurable and SHOULD have a
default of:
RTO = MAX (500ms, Ta*N * (Num-Waiting))
17. Example 17. Example
The example is based on the simplified topology of Figure 19. The example is based on the simplified topology of Figure 21.
+-----+ +-----+
| | | |
|STUN | |STUN |
| Srvr| | Srvr|
+-----+ +-----+
| |
+---------------------+ +---------------------+
| | | |
| Internet | | Internet |
skipping to change at page 76, line 41 skipping to change at page 78, line 35
+---------+ | +---------+ |
| | | |
| | | |
| | | |
+-----+ +-----+ +-----+ +-----+
| | | | | | | |
| L | | R | | L | | R |
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
Figure 19: Example Topology Figure 21: Example Topology
Two agents, L and R, are using ICE. Both are full-mode ICE Two agents, L and R, are using ICE. Both are full-mode ICE
implementations. Both agents have a single IPv4 interface. For implementations and use aggressive nomination when they are
agent L, it is 10.0.1.1 in private address space [RFC1918], and for controlling. Both agents have a single IPv4 address. For agent L,
agent R, 192.0.2.1 on the public Internet. Both are configured with it is 10.0.1.1 in private address space [RFC1918], and for agent R,
the same STUN server (shown in this example for simplicity, although 192.0.2.1 on the public Internet. Both are configured with the same
in practice the agents do not need to use the same STUN server), STUN server (shown in this example for simplicity, although in
which is listening for STUN Binding Requests at an IP address of practice the agents do not need to use the same STUN server), which
192.0.2.2 and port 3478. TURN servers are not used in this example. is listening for STUN Binding Requests at an IP address of 192.0.2.2
and port 3478. TURN servers are not used in this example. Agent L
Agent L is behind a NAT, and agent R is on the public Internet. The is behind a NAT, and agent R is on the public Internet. The NAT has
NAT has an endpoint independent mapping property and an address an endpoint independent mapping property and an address dependent
dependent filtering property. The public side of the NAT has an IP filtering property. The public side of the NAT has an IP address of
address of 192.0.2.3. 192.0.2.3.
To facilitate understanding, transport addresses are listed using To facilitate understanding, transport addresses are listed using
variables that have mnemonic names. The format of the name is variables that have mnemonic names. The format of the name is
entity-type-seqno, where entity refers to the entity whose interface entity-type-seqno, where entity refers to the entity whose IP address
the transport address is on, and is one of "L", "R", "STUN", or the transport address is on, and is one of "L", "R", "STUN", or
"NAT". The type is either "PUB" for transport addresses that are "NAT". The type is either "PUB" for transport addresses that are
public, and "PRIV" for transport addresses that are private. public, and "PRIV" for transport addresses that are private.
Finally, seq-no is a sequence number that is different for each Finally, seq-no is a sequence number that is different for each
transport address of the same type on a particular entity. Each transport address of the same type on a particular entity. Each
variable has an IP address and port, denoted by varname.IP and variable has an IP address and port, denoted by varname.IP and
varname.PORT, respectively, where varname is the name of the varname.PORT, respectively, where varname is the name of the
variable. variable.
The STUN server has advertised transport address STUN-PUB-1 (which is The STUN server has advertised transport address STUN-PUB-1 (which is
skipping to change at page 78, line 22 skipping to change at page 80, line 16
| | |S=$R-PUB-1 | | | |S=$R-PUB-1 |
| | |D=$STUN-PUB-1 | | | |D=$STUN-PUB-1 |
| | |<-------------| | | |<-------------|
| | |(7) STUN Res | | | |(7) STUN Res |
| | |S=$STUN-PUB-1 | | | |S=$STUN-PUB-1 |
| | |D=$R-PUB-1 | | | |D=$R-PUB-1 |
| | |MA=$R-PUB-1 | | | |MA=$R-PUB-1 |
| | |------------->| | | |------------->|
|(8) answer | | | |(8) answer | | |
|<-------------------------------------------| |<-------------------------------------------|
| |(9) Bind Req | | | |(9) Bind Req | |Begin
| |S=$R-PUB-1 | | | |S=$R-PUB-1 | |Connectivity
| |D=L-PRIV-1 | | | |D=L-PRIV-1 | |Checks
| |<----------------------------| | |<----------------------------|
| |Dropped | | | |Dropped | |
|(10) Bind Req | | | |(10) Bind Req | | |
|S=$L-PRIV-1 | | | |S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | | |D=$R-PUB-1 | | |
|USE-CAND | | | |USE-CAND | | |
|------------->| | | |------------->| | |
| |(11) Bind Req | | | |(11) Bind Req | |
| |S=$NAT-PUB-1 | | | |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | | | |D=$R-PUB-1 | |
skipping to change at page 79, line 20 skipping to change at page 81, line 14
|D=$R-PUB-1 | | | |D=$R-PUB-1 | | |
|MA=$R-PUB-1 | | | |MA=$R-PUB-1 | | |
|------------->| | | |------------->| | |
| |(17) Bind Res | | | |(17) Bind Res | |
| |S=$NAT-PUB-1 | | | |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | | | |D=$R-PUB-1 | |
| |MA=$R-PUB-1 | | | |MA=$R-PUB-1 | |
| |---------------------------->| | |---------------------------->|
| | | |RTP flows | | | |RTP flows
Figure 20: Example Flow Figure 22: Example Flow
First, agent L obtains a host candidate from its local interface (not First, agent L obtains a host candidate from its local IP address
shown), and from that, sends a STUN Binding Request to the STUN (not shown), and from that, sends a STUN Binding Request to the STUN
server to get a server reflexive candidate (messages 1-4). Recall server to get a server reflexive candidate (messages 1-4). Recall
that the NAT has the address and port independent mapping property. that the NAT has the address and port independent mapping property.
Here, it creates a binding of NAT-PUB-1 for this UDP request, and Here, it creates a binding of NAT-PUB-1 for this UDP request, and
this becomes the server reflexive candidate for RTP. this becomes the server reflexive candidate for RTP.
Agent L sets a type preference of 126 for the host candidate and 100 Agent L sets a type preference of 126 for the host candidate and 100
for the server reflexive. The local preference is 65535. Based on for the server reflexive. The local preference is 65535. Based on
this, the priority of the host candidate is 2130706431 and for the this, the priority of the host candidate is 2130706431 and for the
server reflexive candidate is 1694498815. The host candidate is server reflexive candidate is 1694498815. The host candidate is
assigned a foundation of 1, and the server reflexive, a foundation of assigned a foundation of 1, and the server reflexive, a foundation of
skipping to change at page 82, line 21 skipping to change at page 84, line 21
(R-PUB-1) and the destination of the request (NAT-PUB-1) as the (R-PUB-1) and the destination of the request (NAT-PUB-1) as the
remote candidate. This pair is added to the Valid list for that remote candidate. This pair is added to the Valid list for that
media stream. Since the check was generated in the reverse direction media stream. Since the check was generated in the reverse direction
of a check that contained the USE-CANDIDATE attribute, the candidate of a check that contained the USE-CANDIDATE attribute, the candidate
pair is marked as selected. Consequently, processing for this stream pair 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.
18. Security Considerations 18. 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. section considers these attacks and their countermeasures. These
countermeasures include:
o Using ICE in conjunction with secure signaling techniques, such as
SIPS
o Limiting the total number of connectivity checks to 100, and
optionally limiting the number of candidates they'll accept in an
offer or answer.
18.1. Attacks on Connectivity Checks 18.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
skipping to change at page 84, line 42 skipping to change at page 87, line 8
only be able to discard them, effectively disabling the media stream only be able to discard them, effectively disabling the media stream
for the call. However, this attack requires the agent to disrupt for the call. However, this attack requires the agent to disrupt
packets in order to block the connectivity check from reaching the packets in order to block the connectivity check from reaching the
target. In that case, if the goal is to disrupt the media stream, target. In that case, if the goal is to disrupt the media stream,
its much easier to just disrupt it with the same mechanism, rather its much easier to just disrupt it with the same mechanism, rather
than attack ICE. than attack ICE.
18.2. Attacks on Server Reflexive Address Gathering 18.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 andidates 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
techinques 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
by DNS security, though DNS-SEC is not required to address it. by DNS security, though DNS-SEC is not required to address it.
o An attacker that can observe STUN messages (such as an attacker on o An attacker that can observe STUN messages (such as an attacker on
a shared network segment, like WiFi), can inject a fake response a shared network segment, like WiFi), can inject a fake response
that is valid and will be accepted by the client. that is valid and will be accepted by the client.
skipping to change at page 87, line 20 skipping to change at page 89, line 34
a rate faster than media would be sent, and the STUN packets persist a rate faster than media would be sent, and the STUN packets persist
only briefly, until ICE fails for the session. Nonetheless, this is only briefly, until ICE fails for the session. Nonetheless, this is
an amplification mechanism. an amplification mechanism.
It is impossible to eliminate the amplification, but the volume can It is impossible to eliminate the amplification, but the volume can
be reduced through a variety of heuristics. Agents SHOULD limit the be reduced through a variety of heuristics. Agents SHOULD limit the
total number of connectivity checks they perform to 100. total number of connectivity checks they perform to 100.
Additionally, agents MAY limit the number of candidates they'll Additionally, agents MAY limit the number of candidates they'll
accept in an offer or answer. accept in an offer or answer.
Frequently, protocols that wish to avoid these kinds of attacks force
the initiator to wait for a response prior to sending the next
message. However, in the case of ICE, this is not possible. It is
not possible to differentiate the following two cases:
o There was no response because the initiator is being used to
launch a DoS attack against an unsuspecting target that will not
respond
o There was no response because the IP address and port is not
reachable by the initiator
In the second case, another check should be sent at the next
opportunity, while in the former case, no further checks should be
sent.
18.6. Interactions with Application Layer Gateways and SIP 18.6. Interactions with Application Layer Gateways and SIP
Application Layer Gateways (ALGs) are functions present in a NAT Application Layer Gateways (ALGs) are functions present in a NAT
device which inspect the contents of packets and modify them, in device which inspect the contents of packets and modify them, in
order to facilitate NAT traversal for application protocols. Session order to facilitate NAT traversal for application protocols. Session
Border Controllers (SBC) are close cousins of ALGs, but are less Border Controllers (SBC) are close cousins of ALGs, but are less
transparent since they actually exist as application layer SIP transparent since they actually exist as application layer SIP
intermediaries. ICE has interactions with SBCs and ALGs. intermediaries. ICE has interactions with SBCs and ALGs.
If an ALG is SIP aware but not ICE aware, ICE will work through it as If an ALG is SIP aware but not ICE aware, ICE will work through it as
long as the ALG correctly modifies the SDP. A correct ALG long as the ALG correctly modifies the SDP. A correct ALG
implementation behave as follows: implementation behaves as follows:
o The ALG does not modify the m and c lines or the rtcp attribute if o The ALG does not modify the m and c lines or the rtcp attribute if
they contain external addresses. they contain external addresses.
o If the m and c lines contain internal addresses, the modification o If the m and c lines contain internal addresses, the modification
depends on the state of the ALG: depends on the state of the ALG:
If the ALG already has a binding established that maps an If the ALG already has a binding established that maps an
external port to an internal IP address and port matching the external port to an internal IP address and port matching the
values in the m and c lines or rtcp attribute , the ALG uses values in the m and c lines or rtcp attribute , the ALG uses
skipping to change at page 89, line 18 skipping to change at page 92, line 5
19.2. New Error Response Codes 19.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.
20. IANA Considerations 20. Operational Considerations
This section discusses issues relevant to network operators looking
to deploy ICE.
20.1. NAT and Firewall Types
ICE was designed to work with existing NAT and firewall equipment.
Consequently, it is not neccesary to replace or reconfigure existing
firewall and NAT equipment in order to facilitate deployment of ICE.
Indeed, ICE was developed to be deployed in environments where the
VoIP operator has no control over the IP network infrastructure,
including firewalls and NAT.
That said, ICE works best in environments where the NAT devices are
"behave" compliant, meeting the recommendations defined in [RFC4787]
and [I-D.ietf-behave-tcp]. In networks with behave-compliant NAT,
ICE will work without the need for a TURN server, thus improving
voice quality, increasing call setup times, and reducing the
bandwidth demands on the network operator.
20.2. Bandwidth Requirements
Deployment of ICE can have several interactions with available
network capacity that operators should take into consideration.
20.2.1. STUN and TURN Server Capacity Planning
First and foremost, ICE makes use of TURN and STUN servers, which
would typically be located in the network operator's data centers.
The STUN servers require relatively little bandwidth. For each
component of each media stream, there will be one or more STUN
transactions from each client to the STUN server. In a basic voice-
only IPv4 VoIP deployment, there will be four transactions per call
(one for RTP and one for RTCP, for both caller and callee). Each
transaction is a single request and a single response, the former
being 20 bytes long, and the latter, 28. Consequently, if a system
has N users, and each makes four calls in a busy hour, this would
require N*1.7bps. For one million users, this is 1.7 Mbps, a very
small number (relatively speaking).
TURN traffic is more substantial. The TURN server will see traffic
volume equal to the STUN volume (indeed, if TURN servers are
deployed, there is no need for a separate STUN server), in addition
to the traffic for the actual media traffic. The amount of calls
requiring TURN for media relay is highly dependent on network
topologies, and can and will vary over time. In a network with 100%
behave compliant NAT, it is exactly zero. At time of writing, large-
scale consumer deployments were seeing between 5 and 10 percent of
calls requiring TURN servers. Considering a voice-only deployment
using G.711 (so 80kbps in each direction), with .2 erlangs during the
busy hour, this is N*3.2kbps. For a population of one million users,
this is 3.2Gbps, assuming a 10% usage of TURN servers.
20.2.2. Gathering and Connectivity Checks
The process of gathering of candidates and performing of connectivity
checks can be banwdidth intensive. ICE has been designed to pace
both of these processes. The gathering phase and the connectivity
check phase are meant to generate traffic at roughly the same
bandwidth as the media traffic itself. This was done to ensure that,
if a network is designed to support multimedia traffic of a certain
type (voice, video or just text), it will have sufficient capacity to
support the ICE checks for that media. Of course, the ICE checks
will cause a marginal increase in the total utilization; however this
will typically be an extremely small increase.
Congestion due to the gathering and check phases has proven to be a
problem in deployments that did not utilize pacing. Typically,
access links became congested as the endpoints flooded the network
with checks as fast as they can send them. Consequently, network
operators should make sure that their ICE implementations support the
pacing feature. Though this pacing does increase call setup times,
it makes ICE network friendly and easier to deploy.
20.2.3. Keepalives
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
absence of actual media traffic. In deployments that are not
utilizing Voice Activity Detection (VAD), the keepalives are never
used and there is no increase in bandwidth usage. When VAD is being
used, keepalives will be sent during silence periods. This involves
a single packet every 15-20 seconds, far less than the packet every
20-30ms that is sent when there is voice. Therefore, keepalives
don't have any real impact on capacity planning.
20.3. ICE and ICE-lite
Deployments utilizing a mix of ICE and ICE-lite interoperate
perfectly. They have been explicitly designed to do so, without loss
of function.
However, ICE-lite can only be deployed in limited use cases. Those
cases, and the caveats involved in doing so, are documented in
Appendix A.
20.4. Troubleshooting and Performance Management
ICE utilizes end-to-end connectivity checks, and places much of the
processing in the endpoints. This introduces a challenge to the
network operator - how can they troubleshoot ICE deployments? How
can they know how ICE is performing?
ICE has built in features to help deal with these problems. SIP
servers on the signaling path, typically deployed in the data centers
of the network operator, will see the contents of the offer/answer
exchanges that convey the ICE parameters. These parameters include
the type of each candidate (host, server reflexive, or relayed),
along with their related addresses. Once ICE processing has
completed, an updated offer/answer exchange takes place, signaling
the selected address (and its type). This updated re-INVITE is
performed exactly for the purposes of educating network equipment
(such as a diagnostic tool attached to a SIP server) about the
results of ICE processing.
As a consequence, through the logs generated by the SIP server, a
network operator can observe what types of candidates are being used
for each call, and what address was selected by ICE. This is the
primary information that helps evaluate how ICE is performing.
20.5. Endpoint Configuration
ICE relies on several pieces of data being configured into the
endpoints. This configuration data includes timers, credentials for
TURN servers, and hostnames for STUN and TURN servers. ICE itself
does not provide a mechanism for this configuration. Instead, it is
assumed that this information is attached to whatever mechanism is
used to configure all of the other parameters in the endpoint. For
SIP phones, standard solutions such as the configuration framework
[I-D.ietf-sipping-config-framework] have been defined.
21. IANA Considerations
This specification registers new SDP attributes, four new STUN This specification registers new SDP attributes, four new STUN
attributes and one new STUN error response. attributes and one new STUN error response.
20.1. SDP Attributes 21.1. SDP Attributes
This specification defines seven new SDP attributes per the This specification defines seven new SDP attributes per the
procedures of Section 8.2.4 of [RFC4566]. The required information procedures of Section 8.2.4 of [RFC4566]. The required information
for the registrations are included here. for the registrations are included here.
20.1.1. candidate Attribute 21.1.1. candidate Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: candidate Attribute Name: candidate
Long Form: candidate Long Form: candidate
Type of Attribute: media level Type of Attribute: media level
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
skipping to change at page 90, line 8 skipping to change at page 95, line 27
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides one of many possible candidate Establishment (ICE), and provides one of many possible candidate
addresses for communication. These addresses are validated with addresses for communication. These addresses are validated with
an end-to-end connectivity check using Simple Traversal Underneath an end-to-end connectivity check using Simple Traversal Underneath
NAT (STUN). NAT (STUN).
Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification]. please replace XXXX with the RFC number of this specification].
20.1.2. remote-candidates Attribute 21.1.2. remote-candidates Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: remote-candidates Attribute Name: remote-candidates
Long Form: remote-candidates Long Form: remote-candidates
Type of Attribute: media level Type of Attribute: media level
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the identity of the remote Establishment (ICE), and provides the identity of the remote
candidates that the offerer wishes the answerer to use in its candidates that the offerer wishes the answerer to use in its
answer. answer.
Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification]. please replace XXXX with the RFC number of this specification].
20.1.3. ice-lite Attribute 21.1.3. ice-lite Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: ice-lite Attribute Name: ice-lite
Long Form: ice-lite Long Form: ice-lite
Type of Attribute: session level Type of Attribute: session level
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates that an agent has the minimum Establishment (ICE), and indicates that an agent has the minimum
functionality required to support ICE inter-operation with a peer functionality required to support ICE inter-operation with a peer
that has a full implementation. that has a full implementation.
Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification]. please replace XXXX with the RFC number of this specification].
20.1.4. ice-mismatch Attribute 21.1.4. ice-mismatch Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: ice-mismatch Attribute Name: ice-mismatch
Long Form: ice-mismatch Long Form: ice-mismatch
Type of Attribute: session level Type of Attribute: session level
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates that an agent is ICE capable, Establishment (ICE), and indicates that an agent is ICE capable,
but did not proceed with ICE due to a mismatch of candidates with but did not proceed with ICE due to a mismatch of candidates with
the default destination for media signaled in the SDP. the default destination for media signaled in the SDP.
Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification]. please replace XXXX with the RFC number of this specification].
20.1.5. ice-pwd Attribute 21.1.5. ice-pwd Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: ice-pwd Attribute Name: ice-pwd
Long Form: ice-pwd Long Form: ice-pwd
Type of Attribute: session or media level Type of Attribute: session or media level
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the password used to protect Establishment (ICE), and provides the password used to protect
STUN connectivity checks. STUN connectivity checks.
skipping to change at page 91, line 46 skipping to change at page 97, line 18
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the password used to protect Establishment (ICE), and provides the password used to protect
STUN connectivity checks. STUN connectivity checks.
Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification]. please replace XXXX with the RFC number of this specification].
20.1.6. ice-ufrag Attribute 21.1.6. ice-ufrag Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: ice-ufrag Attribute Name: ice-ufrag
Long Form: ice-ufrag Long Form: ice-ufrag
Type of Attribute: session or media level Type of Attribute: session or media level
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the fragments used to construct Establishment (ICE), and provides the fragments used to construct
the username in STUN connectivity checks. the username in STUN connectivity checks.
Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification]. please replace XXXX with the RFC number of this specification].
20.1.7. ice-options Attribute 21.1.7. ice-options Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: ice-options Attribute Name: ice-options
Long Form: ice-options Long Form: ice-options
Type of Attribute: session level Type of Attribute: session level
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates the ICE options or extensions Establishment (ICE), and indicates the ICE options or extensions
used by the agent. used by the agent.
Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification]. please replace XXXX with the RFC number of this specification].
20.2. STUN Attributes 21.2. STUN Attributes
This section registers four new STUN attributes per the procedures in This section registers four new STUN attributes per the procedures in
[I-D.ietf-behave-rfc3489bis]. [I-D.ietf-behave-rfc3489bis].
0x0024 PRIORITY 0x0024 PRIORITY
0x0025 USE-CANDIDATE 0x0025 USE-CANDIDATE
0x8029 ICE-CONTROLLED 0x8029 ICE-CONTROLLED
0x802a ICE-CONTROLLING 0x802a ICE-CONTROLLING
20.3. STUN Error Responses 21.3. STUN Error Responses
This section registers one new STUN error response code per the This section registers one new STUN error response code per the
procedures in [I-D.ietf-behave-rfc3489bis]. procedures in [I-D.ietf-behave-rfc3489bis].
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.
21. IAB Considerations 22. 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 signficant 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.
21.1. Problem Definition 22.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 which can be used for communication. addresses which 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.
21.2. Exit Strategy 22.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 short Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed. 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 94, line 29 skipping to change at page 99, line 46
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.
21.3. Brittleness Introduced by ICE 22.3. Brittleness Introduced by ICE
From RFC3424, any UNSAF proposal must provide: From RFC3424, 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 95, line 27 skipping to change at page 100, line 48
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.
21.4. Requirements for a Long Term Solution 22.4. Requirements for a Long Term Solution
From RFC 3424, any UNSAF proposal must provide: From RFC 3424, any UNSAF proposal must provide:
Identify requirements for longer term, sound technical solutions Identify 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.
21.5. Issues with Existing NAPT Boxes 22.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 which A number of NAT boxes are now being deployed into the market which
try and provide "generic" ALG functionality. These generic ALGs hunt try and provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and for 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 96, line 15 skipping to change at page 101, line 37
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 15s, which is a very conservative bindings. ICE uses a default of 15s, 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.
22. Acknowledgements 23. Acknowledgements
The authors would like to thank Dan Wing, Eric Rescorla, Flemming The authors would like to thank Dan Wing, Eric Rescorla, Flemming
Andreasen, Rohan Mahy, Dean Willis, Eric Cooper, Jason Fischl, Andreasen, Rohan Mahy, Dean Willis, Eric Cooper, Jason Fischl,
Douglas Otis, Tim Moore, Jean-Francois Mule, Kevin Johns, Jonathan Douglas Otis, Tim Moore, Jean-Francois Mule, Kevin Johns, Jonathan
Lennox and Francois Audet for their comments and input. A special Lennox and Francois Audet for their comments and input. A special
thanks goes to Bill May, who suggested several of the concepts in thanks goes to Bill May, who suggested several of the concepts in
this specification, Philip Matthews, who suggested many of the key this specification, Philip Matthews, who suggested many of the key
performance optimizations in this specification, Eric Rescorla, who performance optimizations in this specification, Eric Rescorla, who
drafted the text in the introduction, and Magnus Westerlund, for drafted the text in the introduction, and Magnus Westerlund, for
doing several detailed reviews on the various revisions of this doing several detailed reviews on the various revisions of this
specification. specification.
23. References 24. References
23.1. Normative References 24.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.
[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, in Session Description Protocol (SDP)", RFC 3605,
October 2003. October 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.
skipping to change at page 97, line 31 skipping to change at page 103, line 4
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005. Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., "Session Traversal Utilities for (NAT) Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D.
(STUN)", draft-ietf-behave-rfc3489bis-06 (work in Wing, "Session Traversal Utilities for (NAT) (STUN)",
progress), March 2007. draft-ietf-behave-rfc3489bis-08 (work in progress),
July 2007.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., "Obtaining Relay Addresses from Simple Rosenberg, J., "Traversal Using Relays around NAT (TURN):
Traversal Underneath NAT (STUN)", Relay Extensions to Session Traversal Utilities for NAT
draft-ietf-behave-turn-03 (work in progress), March 2007. (STUN)", draft-ietf-behave-turn-04 (work in progress),
July 2007.
[I-D.ietf-sip-ice-option-tag] [I-D.ietf-sip-ice-option-tag]
Rosenberg, J., "Indicating Support for Interactive Rosenberg, J., "Indicating Support for Interactive
Connectivity Establishment (ICE) in the Session Connectivity Establishment (ICE) in the Session
Initiation Protocol (SIP)", Initiation Protocol (SIP)",
draft-ietf-sip-ice-option-tag-02 (work in progress), draft-ietf-sip-ice-option-tag-02 (work in progress),
June 2007. June 2007.
23.2. Informative References 24.2. Informative References
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002. Application Design Guidelines", RFC 3235, January 2002.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
skipping to change at page 99, line 22 skipping to change at page 104, line 48
draft-ietf-mmusic-connectivity-precon-02 (work in draft-ietf-mmusic-connectivity-precon-02 (work in
progress), June 2006. progress), June 2006.
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.ietf-avt-rtp-and-rtcp-mux] [I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-05 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
May 2007. August 2007.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-09 (work in progress), June 2007. draft-ietf-sip-outbound-10 (work in progress), July 2007.
[I-D.ietf-behave-tcp]
Guha, S., "NAT Behavioral Requirements for TCP",
draft-ietf-behave-tcp-07 (work in progress), April 2007.
[I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-12 (work in progress),
June 2007.
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 100, line 23 skipping to change at page 106, line 10
placed behind a NAT. placed behind a NAT.
ICE allows a lite implementation to have a single IPv4 host candidate ICE allows a lite implementation to have a single IPv4 host candidate
and several IPv6 addresses. In that case, candidate pairs are and several IPv6 addresses. In that case, candidate pairs are
selected by the controlling agent using a static algorithm, such as selected by the controlling agent using a static algorithm, such as
the one in RFC 3484, which is recommended by this specification. the one in RFC 3484, which is recommended by this specification.
However, static mechanisms for address selection are always prone to However, static mechanisms for address selection are always prone to
error, since they cannot ever reflect the actual topology and can error, since they cannot ever reflect the actual topology and can
never provide actual guarantees on connectivity. They are always never provide actual guarantees on connectivity. They are always
heuristics. Consequently, if an agent is implementing ICE just to heuristics. Consequently, if an agent is implementing ICE just to
select between its IPv4 and IPv6 addresses, and it is none of its select between its IPv4 and IPv6 addresses, and it is none of its IP
interfaces are behind NAT, usage of full ICE is still RECOMMENDED in addresses are behind NAT, usage of full ICE is still RECOMMENDED in
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
skipping to change at page 102, line 16 skipping to change at page 108, line 7
candidate/STUN server pairs). These are transactions A, B and C. The candidate/STUN server pairs). These are transactions A, B and C. The
retransmit timer is set so that the first retransmission on the first retransmit timer is set so that the first retransmission on the first
transaction (packet A2) is sent at time 3Ta. transaction (packet A2) is sent at time 3Ta.
Subsequent retransmits after the first will occur even less Subsequent retransmits after the first will occur even less
frequently than Ta milliseconds apart, since STUN uses an exponential frequently than Ta milliseconds apart, since STUN uses an exponential
back-off on its retransmissions. back-off on its retransmissions.
B.2. Candidates with Multiple Bases B.2. Candidates with Multiple Bases
Section 4.1.1.3 talks about eliminating candidates that have the same Section 4.1.3 talks about eliminating candidates that have the same
transport address and base. However, candidates with the same transport address and base. However, candidates with the same
transport addresses but different bases are not redundant . When can transport addresses but different bases are not redundant . When can
an agent have two candidates that have the same IP address and port, an agent have two candidates that have the same IP address and port,
but different bases? Consider the topology of Figure 28: but different bases? Consider the topology of Figure 30:
+----------+ +----------+
| STUN Srvr| | STUN Srvr|
+----------+ +----------+
| |
| |
----- -----
// \\ // \\
| | | |
| B:net10 | | B:net10 |
skipping to change at page 103, line 40 skipping to change at page 109, line 4
----- -----
| |
| |
|192.168.1.100 ----- |192.168.1.100 -----
+----------+ // \\ +----------+ +----------+ // \\ +----------+
| | | | | | | | | | | |
| Offerer |---------| C:net10 |-----------| Answerer | | Offerer |---------| C:net10 |-----------| Answerer |
| |10.0.1.100| | 10.0.1.101 | | | |10.0.1.100| | 10.0.1.101 | |
+----------+ \\ // +----------+ +----------+ \\ // +----------+
----- -----
Figure 30: Identical Candidates with Different Bases
Figure 28: Identical Candidates with Different Bases In this case, the offerer is multi-homed. It has one IP address,
In this case, the offerer is multi-homed. It has one interface,
10.0.1.100, on network C, which is a net 10 private network. The 10.0.1.100, on network C, which is a net 10 private network. The
Answerer is on this same network. The offerer is also connected to Answerer is on this same network. The offerer is also connected to
network A, which is 192.168/16. The offerer has an interface of network A, which is 192.168/16. The offerer has an IP address of
192.168.1.100 on this network. There is a NAT on this network, 192.168.1.100 on this network. There is a NAT on this network,
natting into network B, which is another net 10 private network, but natting into network B, which is another net 10 private network, but
not connected to network C. There is a STUN server on network B. not connected to network C. There is a STUN server on network B.
The offerer obtains a host candidate on its interface on network C The offerer obtains a host candidate on its IP address on network C
(10.0.1.100:2498) and a host candidate on its interface on network A (10.0.1.100:2498) and a host candidate on its IP address on network A
(192.168.1.100:3344). It performs a STUN query to its configured (192.168.1.100:3344). It performs a STUN query to its configured
STUN server from 192.168.1.100:3344. This query passes through the STUN server from 192.168.1.100:3344. This query passes through the
NAT, which happens to assign the binding 10.0.1.100:2498. The STUN NAT, which happens to assign the binding 10.0.1.100:2498. The STUN
server reflects this in the STUN Binding Response. Now, the offerer server reflects this in the STUN Binding Response. Now, the offerer
has obtained a server reflexive candidate with a transport address has obtained a server reflexive candidate with a transport address
that is identical to a host candidate (10.0.1.100:2498). However, that is identical to a host candidate (10.0.1.100:2498). However,
the server reflexive candidate has a base of 192.168.1.100:3344, and the server reflexive candidate has a base of 192.168.1.100:3344, and
the host candidate has a base of 10.0.1.100:2498. the host candidate has a base of 10.0.1.100:2498.
B.3. Purpose of the <rel-addr> and <rel-port> Attributes B.3. Purpose of the <rel-addr> and <rel-port> Attributes
skipping to change at page 105, line 45 skipping to change at page 111, line 7
protocol. This decreases the probability of hitting an allocated protocol. This decreases the probability of hitting an allocated
port, due to the transient nature of port usage in this range. port, due to the transient nature of port usage in this range.
However, the possibility of a problem does exist, and network However, the possibility of a problem does exist, and network
deployers should be prepared for it. Note that this is not a problem deployers should be prepared for it. Note that this is not a problem
specific to ICE; stray packets can arrive at a port at any time for specific to ICE; stray packets can arrive at a port at any time for
any type of protocol, especially ones on the public Internet. As any type of protocol, especially ones on the public Internet. As
such, this requirement is just restating a general design guideline such, this requirement is just restating a general design guideline
for Internet applications - be prepared for unknown packets on any for Internet applications - be prepared for unknown packets on any
port. port.
B.5. The Candidate Pair Sequence Number Formula B.5. The Candidate Pair Priority Formula
The sequence number for a candidate pair has an odd form. It is: The priority for a candidate pair has an odd form. It is:
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Why is this? When the candidate pairs are sorted based on this Why is this? When the candidate pairs are sorted based on this
value, the resulting sorting has the MAX/MIN property. This means value, the resulting sorting has the MAX/MIN property. This means
that the pairs are first sorted based on decreasing value of the that the pairs are first sorted based on decreasing value of the
maximum of the two sequence numbers. For pairs that have the same minimum of the two priorities. For pairs that have the same value of
value of the maximum sequence number, the minimum sequence number is the minimum priority, the maximum priority is used to sort amongst
used to sort amongst them. If the max and the min sequence numbers them. If the max and the min priorities are the same, the
are the same, the offerers priority is used as the tie breaker in the controlling agent's priority is used as the tie breaker in the last
last part of the expression. The factor of 2*32 is used since the part of the expression. The factor of 2*32 is used since the
priority of a single candidate is always less than 2*32, resulting in priority of a single candidate is always less than 2*32, resulting in
the pair priority being a "concatenation" of the two component the pair priority being a "concatenation" of the two component
priorities. This creates the MAX/MIN sorting. MAX/MIN ensures that, priorities. This creates the MAX/MIN sorting. MAX/MIN ensures that,
for a particular agent, a lower priority candidate is never used for a particular agent, a lower priority candidate is never used
until all higher priority candidates have been tried. until all higher priority candidates have been tried.
B.6. The remote-candidates attribute B.6. The remote-candidates attribute
The a=remote-candidates attribute exists to eliminate a race The a=remote-candidates attribute exists to eliminate a race
condition between the updated offer and the response to the STUN condition between the updated offer and the response to the STUN
Binding Request that moved a candidate into the Valid list. This Binding Request that moved a candidate into the Valid list. This
race condition is shown in Figure 29. On receipt of message 4, agent race condition is shown in Figure 31. On receipt of message 4, agent
L adds a candidate pair to the valid list. If there was only a L adds a candidate pair to the valid list. If there was only a
single media stream with a single component, agent L could now send single media stream with a single component, agent L could now send
an updated offer. However, the check from agent R has not yet an updated offer. However, the check from agent R has not yet
generated a response, and agent R receives the updated offer (message generated a response, and agent R receives the updated offer (message
7) before getting the response (message 9). Thus, it does not yet 7) before getting the response (message 9). Thus, it does not yet
know that this particular pair is valid. To eliminate this know that this particular pair is valid. To eliminate this
condition, the actual candidates at R that were selected by the condition, the actual candidates at R that were selected by the
offerer (the remote candidates) are included in the offer itself, and offerer (the remote candidates) are included in the offer itself, and
the answerer delays its answer until those pairs validate. the answerer delays its answer until those pairs validate.
skipping to change at page 107, line 28 skipping to change at page 112, line 28
| |Lost | | |Lost |
|(7) Offer | | |(7) Offer | |
|------------------------------------------>| |------------------------------------------>|
|(8) STUN Req. | | |(8) STUN Req. | |
|<------------------------------------------| |<------------------------------------------|
|(9) STUN Res. | | |(9) STUN Res. | |
|------------------------------------------>| |------------------------------------------>|
|(10) Answer | | |(10) Answer | |
|<------------------------------------------| |<------------------------------------------|
Figure 29: Race Condition Flow Figure 31: Race Condition Flow
B.7. Why are Keepalives Needed? B.7. Why are Keepalives Needed?
Once media begins flowing on a candidate pair, it is still necessary Once media begins flowing on a candidate pair, it is still necessary
to keep the bindings alive at intermediate NATs for the duration of to keep the bindings alive at intermediate NATs for the duration of
the session. Normally, the media stream packets themselves (e.g., the session. Normally, the media stream packets themselves (e.g.,
RTP) meet this objective. However, several cases merit further RTP) meet this objective. However, several cases merit further
discussion. Firstly, in some RTP usages, such as SIP, the media discussion. Firstly, in some RTP usages, such as SIP, the media
streams can be "put on hold". This is accomplished by using the SDP streams can be "put on hold". This is accomplished by using the SDP
"sendonly" or "inactive" attributes, as defined in RFC 3264 "sendonly" or "inactive" attributes, as defined in RFC 3264
skipping to change at page 109, line 47 skipping to change at page 114, line 47
|------------->| | |------------->| |
| |(3) INV() | | |(3) INV() |
| |------------->| | |------------->|
| |(4) 200(SDP2) | | |(4) 200(SDP2) |
| |<-------------| | |<-------------|
|(5) ACK(SDP2) | | |(5) ACK(SDP2) | |
|<-------------| | |<-------------| |
| |(6) ACK(SDP1) | | |(6) ACK(SDP1) |
| |------------->| | |------------->|
Figure 30: Role Conflict Flow Figure 32: Role Conflict Flow
This flow is a variation on flow III of RFC 3725 [RFC3725]. In fact, This flow is a variation on flow III of RFC 3725 [RFC3725]. In fact,
it works better than flow III since it produces fewer messages. In it works better than flow III since it produces fewer messages. In
this flow, the controller sends an offerless INVITE to agent A, which this flow, the controller sends an offerless INVITE to agent A, which
responds with its offer, SDP1. The agent then sends an offerless responds with its offer, SDP1. The agent then sends an offerless
INVITE to agent B, which it responds to with its offer, SDP2. The INVITE to agent B, which it responds to with its offer, SDP2. The
controller then uses the offer from each agent to generate the controller then uses the offer from each agent to generate the
answers. When this flow is used, ICE will run between agents A and answers. When this flow is used, ICE will run between agents A and
B, but both will believe they are in the controlling role. With the B, but both will believe they are in the controlling role. With the
role conflict resolution procedures, this flow will function properly role conflict resolution procedures, this flow will function properly
 End of changes. 109 change blocks. 
392 lines changed or deleted 619 lines changed or added

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