draft-ietf-mmusic-rfc5245bis-01.txt   draft-ietf-mmusic-rfc5245bis-02.txt 
MMUSIC A. Keranen MMUSIC A. Keranen
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 5245 (if approved) J. Rosenberg Obsoletes: 5245 (if approved) J. Rosenberg
Intended status: Standards Track jdrosen.net Intended status: Standards Track jdrosen.net
Expires: July 19, 2014 January 15, 2014 Expires: January 5, 2015 July 4, 2014
Interactive Connectivity Establishment (ICE): A Protocol for Network Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols Address Translator (NAT) Traversal for Offer/Answer Protocols
draft-ietf-mmusic-rfc5245bis-01 draft-ietf-mmusic-rfc5245bis-02
Abstract Abstract
This document describes a protocol for Network Address Translator This document describes a protocol for Network Address Translator
(NAT) traversal for UDP-based multimedia sessions established with (NAT) traversal for UDP-based multimedia sessions established with
the offer/answer model. This protocol is called Interactive the offer/answer model. This protocol is called Interactive
Connectivity Establishment (ICE). ICE makes use of the Session Connectivity Establishment (ICE). ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Utilities for NAT (STUN) protocol and its extension,
Traversal Using Relay NAT (TURN). ICE can be used by any protocol Traversal Using Relay NAT (TURN). ICE can be used by any protocol
utilizing the offer/answer model, such as the Session Initiation utilizing the offer/answer model, such as the Session Initiation
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 19, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19
4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19
4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20
4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 21 4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 21
4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22 4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22
4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22
4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22
4.1.2.2. Guidelines for Choosing Type and Local 4.1.2.2. Guidelines for Choosing Type and Local
Preferences . . . . . . . . . . . . . . . . . . . 23 Preferences . . . . . . . . . . . . . . . . . . . 23
4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 24 4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 24
4.2. Lite Implementation Requirements . . . . . . . . . . . . 24 4.2. Lite Implementation Requirements . . . . . . . . . . . . 25
4.3. Encoding the Offer . . . . . . . . . . . . . . . . . . . 25 4.3. Encoding the Offer . . . . . . . . . . . . . . . . . . . 26
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 27 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 28
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 27 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28
5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 28 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 28
5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 29 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 29
5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 29 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 29
5.5. Encoding the Answer . . . . . . . . . . . . . . . . . . . 29 5.5. Encoding the Answer . . . . . . . . . . . . . . . . . . . 29
5.6. Forming the Check Lists . . . . . . . . . . . . . . . . . 29 5.6. Forming the Check Lists . . . . . . . . . . . . . . . . . 30
5.6.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 29 5.6.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 30
5.6.2. Computing Pair Priority and Ordering Pairs . . . . . 32 5.6.2. Computing Pair Priority and Ordering Pairs . . . . . 33
5.6.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 32 5.6.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 33
5.6.4. Computing States . . . . . . . . . . . . . . . . . . 32 5.6.4. Computing States . . . . . . . . . . . . . . . . . . 33
5.7. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 35 5.7. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 36
6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 37 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 38
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 37 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 38
6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 37 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 38
6.3. Forming the Check List . . . . . . . . . . . . . . . . . 37 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 38
6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 37 6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 38
7. Performing Connectivity Checks . . . . . . . . . . . . . . . 37 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 38
7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 38 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 39
7.1.1. Creating Permissions for Relayed Candidates . . . . . 38 7.1.1. Creating Permissions for Relayed Candidates . . . . . 39
7.1.2. Sending the Request . . . . . . . . . . . . . . . . . 38 7.1.2. Sending the Request . . . . . . . . . . . . . . . . . 39
7.1.2.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 38 7.1.2.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 39
7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 39 7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 40
7.1.2.3. Forming Credentials . . . . . . . . . . . . . . . 39 7.1.2.3. Forming Credentials . . . . . . . . . . . . . . . 40
7.1.2.4. DiffServ Treatment . . . . . . . . . . . . . . . 39 7.1.2.4. DiffServ Treatment . . . . . . . . . . . . . . . 40
7.1.3. Processing the Response . . . . . . . . . . . . . . . 39 7.1.3. Processing the Response . . . . . . . . . . . . . . . 40
7.1.3.1. Failure Cases . . . . . . . . . . . . . . . . . . 40 7.1.3.1. Failure Cases . . . . . . . . . . . . . . . . . . 41
7.1.3.2. Success Cases . . . . . . . . . . . . . . . . . . 40 7.1.3.2. Success Cases . . . . . . . . . . . . . . . . . . 41
7.1.3.2.1. Discovering Peer Reflexive Candidates . . . . 41 7.1.3.2.1. Discovering Peer Reflexive Candidates . . . . 42
7.1.3.2.2. Constructing a Valid Pair . . . . . . . . . . 41 7.1.3.2.2. Constructing a Valid Pair . . . . . . . . . . 42
7.1.3.2.3. Updating Pair States . . . . . . . . . . . . 42 7.1.3.2.3. Updating Pair States . . . . . . . . . . . . 43
7.1.3.2.4. Updating the Nominated Flag . . . . . . . . . 43 7.1.3.2.4. Updating the Nominated Flag . . . . . . . . . 44
7.1.3.3. Check List and Timer State Updates . . . . . . . 43 7.1.3.3. Check List and Timer State Updates . . . . . . . 44
7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 44 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 45
7.2.1. Additional Procedures for Full Implementations . . . 45 7.2.1. Additional Procedures for Full Implementations . . . 46
7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 45 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 46
7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 46 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 47
7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 46 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 47
7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 47 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 48
7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 48 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 49
7.2.2. Additional Procedures for Lite Implementations . . . 48 7.2.2. Additional Procedures for Lite Implementations . . . 49
8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 49 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 50
8.1. Procedures for Full Implementations . . . . . . . . . . . 49 8.1. Procedures for Full Implementations . . . . . . . . . . . 50
8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 49 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 50
8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 49 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 50
8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 50 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 51
8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 50 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 51
8.2. Procedures for Lite Implementations . . . . . . . . . . . 52 8.2. Procedures for Lite Implementations . . . . . . . . . . . 53
8.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . 52 8.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . 53
8.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . 52 8.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . 53
8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 53 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 54
8.3.1. Full Implementation Procedures . . . . . . . . . . . 53 8.3.1. Full Implementation Procedures . . . . . . . . . . . 54
8.3.2. Lite Implementation Procedures . . . . . . . . . . . 53 8.3.2. Lite Implementation Procedures . . . . . . . . . . . 54
9. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 53 9. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 54
10. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 54 10. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 55
10.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 55 10.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 56
10.1.1. Procedures for Full Implementations . . . . . . . . 55 10.1.1. Procedures for Full Implementations . . . . . . . . 56
10.1.2. Procedures for Lite Implementations . . . . . . . . 55 10.1.2. Procedures for Lite Implementations . . . . . . . . 56
10.1.3. Procedures for All Implementations . . . . . . . . . 56 10.1.3. Procedures for All Implementations . . . . . . . . . 57
10.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 56 10.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 57
11. Extensibility Considerations . . . . . . . . . . . . . . . . 56 11. Extensibility Considerations . . . . . . . . . . . . . . . . 57
12. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 57 12. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 58
12.1. RTP Media Streams . . . . . . . . . . . . . . . . . . . 58 12.1. Real-time Media Streams . . . . . . . . . . . . . . . . 59
12.2. Non-RTP Sessions . . . . . . . . . . . . . . . . . . . . 59 12.2. Non-real-time Sessions . . . . . . . . . . . . . . . . . 60
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
14. Security Considerations . . . . . . . . . . . . . . . . . . . 64 14. Security Considerations . . . . . . . . . . . . . . . . . . . 66
14.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 65 14.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 66
14.2. Attacks on Server Reflexive Address Gathering . . . . . 67 14.2. Attacks on Server Reflexive Address Gathering . . . . . 68
14.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 68 14.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 69
14.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . 68 14.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . 70
14.4.1. STUN Amplification Attack . . . . . . . . . . . . . 69 14.4.1. STUN Amplification Attack . . . . . . . . . . . . . 70
15. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 69 15. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 71
15.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 69 15.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 71
15.2. New Error Response Codes . . . . . . . . . . . . . . . . 70 15.2. New Error Response Codes . . . . . . . . . . . . . . . . 71
16. Operational Considerations . . . . . . . . . . . . . . . . . 70 16. Operational Considerations . . . . . . . . . . . . . . . . . 71
16.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 70 16.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 72
16.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 71 16.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 72
16.2.1. STUN and TURN Server Capacity Planning . . . . . . . 71 16.2.1. STUN and TURN Server Capacity Planning . . . . . . . 72
16.2.2. Gathering and Connectivity Checks . . . . . . . . . 71 16.2.2. Gathering and Connectivity Checks . . . . . . . . . 73
16.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 72 16.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 73
16.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 72 16.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 73
16.4. Troubleshooting and Performance Management . . . . . . . 72 16.4. Troubleshooting and Performance Management . . . . . . . 73
16.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 73 16.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 74
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
17.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 73 17.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 74
17.2. STUN Error Responses . . . . . . . . . . . . . . . . . . 73 17.2. STUN Error Responses . . . . . . . . . . . . . . . . . . 75
18. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 73 18. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75
18.1. Problem Definition . . . . . . . . . . . . . . . . . . . 74 18.1. Problem Definition . . . . . . . . . . . . . . . . . . . 75
18.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 74 18.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 75
18.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 75 18.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 76
18.4. Requirements for a Long-Term Solution . . . . . . . . . 76 18.4. Requirements for a Long-Term Solution . . . . . . . . . 77
18.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 76 18.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 77
19. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 76 19. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 78
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 78
21.1. Normative References . . . . . . . . . . . . . . . . . . 77 21.1. Normative References . . . . . . . . . . . . . . . . . . 78
21.2. Informative References . . . . . . . . . . . . . . . . . 77 21.2. Informative References . . . . . . . . . . . . . . . . . 79
Appendix A. Lite and Full Implementations . . . . . . . . . . . 80 Appendix A. Lite and Full Implementations . . . . . . . . . . . 81
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 81 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 82
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 81 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 83
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 82 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 84
B.3. Purpose of the Related Address and Related Port B.3. Purpose of the Related Address and Related Port
Attributes . . . . . . . . . . . . . . . . . . . . . . . 84 Attributes . . . . . . . . . . . . . . . . . . . . . . . 86
B.4. Importance of the STUN Username . . . . . . . . . . . . . 84 B.4. Importance of the STUN Username . . . . . . . . . . . . . 86
B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 85 B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 87
B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 86 B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 88
B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 86 B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 88
B.8. Why Are Binding Indications Used for Keepalives? . . . . 87 B.8. Why Are Binding Indications Used for Keepalives? . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89
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 41 skipping to change at page 6, line 41
tiers of NATs). ICE allows the agents to discover enough information tiers of NATs). ICE allows the agents to discover enough information
about their topologies to potentially find one or more paths by which about their topologies to potentially find one or more paths by which
they can communicate. they can communicate.
Figure 1 shows a typical environment for ICE deployment. The two Figure 1 shows a typical environment for ICE deployment. The two
endpoints are labelled L and R (for left and right, which helps endpoints are labelled L and R (for left and right, which helps
visualize call flows). Both L and R are behind their own respective visualize call flows). Both L and R are behind their own respective
NATs though they may not be aware of it. The type of NAT and its NATs though they may not be aware of it. The type of NAT and its
properties are also unknown. Agents L and R are capable of engaging properties are also unknown. Agents L and R are capable of engaging
in an offer/answer exchange, whose purpose is to set up a media in an offer/answer exchange, whose purpose is to set up a media
session between L and R. Typically, this exchange will occur through session between L and R. Typically, this exchange will occur through
a signaling (e.g., SIP) server. a signaling (e.g., SIP) server.
In addition to the agents, a signaling server and NATs, ICE is In addition to the agents, a signaling server and NATs, ICE is
typically used in concert with STUN or TURN servers in the network. typically used in concert with STUN or TURN servers in the network.
Each agent can have its own STUN or TURN server, or they can be the Each agent can have its own STUN or TURN server, or they can be the
same. same.
+---------+ +---------+
+--------+ |Signaling| +--------+ +--------+ |Signaling| +--------+
| STUN | |Server | | STUN | | STUN | |Server | | STUN |
skipping to change at page 9, line 38 skipping to change at page 9, line 38
| | | |
| Agent | | Agent |
| | | |
+--------+ +--------+
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 reflexive 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.
skipping to change at page 10, line 15 skipping to change at page 10, line 15
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 IP address 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
request [RFC5389] to its STUN server. The STUN server will inform request [RFC5389] to its STUN server. The STUN server will inform
the agent of the server reflexive candidate X1':x1' by copying the the agent of the server reflexive candidate X1':x1' by copying the
source transport address of the Binding request into the Binding source transport address of the Binding request into the Binding
response. response.
skipping to change at page 12, line 6 skipping to change at page 12, line 6
The algorithm is described in Section 4.1.2 but follows two general The algorithm is described in Section 4.1.2 but follows two general
principles: principles:
o Each agent gives its candidates a numeric priority, which is sent o Each agent gives its candidates a numeric priority, which is sent
along with the candidate to the peer. along with the candidate to the peer.
o The local and remote priorities are combined so that each agent o The local and remote priorities are combined so that each agent
has the same ordering for the candidate pairs. has the same ordering for the candidate pairs.
The second property is important for getting ICE to work when there The second property is important for getting ICE to work when there
are NATs in front of L and R. Frequently, NATs will not allow packets are NATs in front of L and R. Frequently, NATs will not allow
in from a host until the agent behind the NAT has sent a packet packets in from a host until the agent behind the NAT has sent a
towards that host. Consequently, ICE checks in each direction will packet towards that host. Consequently, ICE checks in each direction
not succeed until both sides have sent a check through their will not succeed until both sides have sent a check through their
respective NATs. respective NATs.
The agent works through this check list by sending a STUN request for The agent works through this check list by sending a STUN request for
the next candidate pair on the list periodically. These are called the next candidate pair on the list periodically. These are called
ORDINARY CHECKS. ORDINARY CHECKS.
In general, the priority algorithm is designed so that candidates of In general, the priority algorithm is designed so that candidates of
similar type get similar priorities and so that more direct routes similar type get similar priorities and so that more direct routes
(that is, through fewer media relays and through fewer NATs) are (that is, through fewer media relays and through fewer NATs) are
preferred over indirect ones (ones with more media relays and more preferred over indirect ones (ones with more media relays and more
skipping to change at page 23, line 13 skipping to change at page 23, line 13
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 IP address 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. 65535 represents the highest preference,
65535 represents the highest preference, and a zero, the lowest. and a zero, the lowest. When there is only a single IP address, this
When there is only a single IP address, this value SHOULD be set to value SHOULD be set to 65535. More generally, if there are multiple
65535. More generally, if there are multiple candidates for a candidates for a particular component for a particular media stream
particular component for a particular media stream that have the same that have the same type, the local preference MUST be unique for each
type, the local preference MUST be unique for each one. In this one. In this specification, this only happens for multihomed hosts
specification, this only happens for multihomed hosts. If a host is or if an agent is using multiple TURN servers. If a host is
multihomed because it is dual-stack, the local preference SHOULD be multihomed because it is dual-stack, the local preference SHOULD be
set equal to the precedence value for IP addresses described in RFC set equal to the precedence value for IP addresses described in RFC
6724 [RFC6724]. If the host operating system provides an API for 6724 [RFC6724]. If the host operating system provides an API for
discovering preference among different addresses, those preferences discovering preference among different addresses, those preferences
SHOULD be used for the local preference to prioritize addresses SHOULD be used for the local preference to prioritize addresses
indicated as preferred by the operating system. indicated as preferred by the operating system.
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.
skipping to change at page 23, line 47 skipping to change at page 23, line 47
a media intermediary. Another are host candidates obtained from a a media intermediary. Another are host candidates obtained from a
VPN interface. When media is transited through a media intermediary, VPN interface. When media is transited through a media intermediary,
it can increase the latency between transmission and reception. It it can increase the latency between transmission and reception. It
can increase the packet losses, because of the additional router hops can 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 multihomed and 0 for relayed candidates.
and has multiple IP addresses, the local preference for host
candidates from a VPN interface SHOULD have a priority of 0. Furthermore, if an agent is multihomed and has multiple IP addresses,
the local preference for host candidates from a VPN interface SHOULD
have a priority of 0. If multiple TURN servers are used, local
priorities for the candidates obtained from the TURN servers are
chosen in a similar fashion as for multihomed local candidates: the
local preference value is used to indicate preference among different
servers but the preference MUST be unique for each one.
Another criterion for selection of preferences is IP address family. Another criterion 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 addresses, followed by the preferences could be assigned to the v6 addresses, followed by the
6to4 addresses, followed by the v4 addresses. This allows a site to 6to4 addresses, followed by the v4 addresses. This allows a site to
skipping to change at page 26, line 29 skipping to change at page 26, line 36
Component-ID: This would be present only if the using protocol Component-ID: This would be present only if the using protocol
were utilizing the concept of components. If it is, it would were utilizing the concept of components. If it is, it would
be a positive integer that indicates the component ID for which be a positive integer that indicates the component ID for which
this is a candidate. this is a candidate.
Priority: An encoding of the 32-bit priority value. Priority: An encoding of the 32-bit priority value.
Candidate Type: The candidate type, as defined in ICE. Candidate Type: The candidate type, as defined in ICE.
Related Address and Port: The related IP address and port for Related Address and Port: The related IP address and port for
this candidate, as defined by ICE. this candidate, as defined by ICE. These MAY be omitted or set
to invalid values if the agent does not want to reveal them,
e.g., for privacy reasons.
Extensibility Parameters: The using protocol should define some Extensibility Parameters: The using protocol should define some
means for adding new per-candidate ICE parameters in the means for adding new per-candidate ICE parameters in the
future. future.
Lite Flag: If ICE lite is used by the using protocol, it needs to Lite Flag: If ICE lite is used by the using protocol, it needs to
convey a boolean parameter which indicates whether the convey a boolean parameter which indicates whether the
implementation is lite or not. implementation is lite or not.
Connectivity check pacing value: If an agent wants to use other than
the default pacing values for the connectivity checks, it MUST
indicate this in the ICE exchange.
Username Fragment and Password: The using protocol has to convey a Username Fragment and Password: The using protocol has to convey a
username fragment and password. The username fragment MUST username fragment and password. The username fragment MUST
contain at least 24 bits of randomness, and the password MUST contain at least 24 bits of randomness, and the password MUST
contain at least 128 bits of randomness. contain at least 128 bits of randomness.
ICE extensions: In addition to the per-candidate extensions above, ICE extensions: In addition to the per-candidate extensions above,
the using protocol should allow for new media-stream or session- the using protocol should allow for new media-stream or session-
level attributes (ice-options). level attributes (ice-options).
If the using protocol is using the ICE mismatch feature, a way is If the using protocol is using the ICE mismatch feature, a way is
skipping to change at page 35, line 32 skipping to change at page 36, line 32
Running: In this state, ICE checks are still in progress for this Running: In this state, ICE checks are still in progress for this
media stream. media stream.
Completed: In this state, ICE checks have produced nominated pairs Completed: In this state, ICE checks have produced nominated pairs
for each component of the media stream. Consequently, ICE has for each component of the media stream. Consequently, ICE has
succeeded and media can be sent. succeeded and media can be sent.
Failed: In this state, the ICE checks have not completed Failed: In this state, the ICE checks have not completed
successfully for this media stream. successfully for this media stream.
When a check list is first constructed as the consequence of an offer When a check list is first constructed as the consequence of an
/answer exchange, it is placed in the Running state. offer/answer exchange, it is placed in the Running state.
ICE processing across all media streams also has a state associated ICE processing across all media streams also has a state associated
with it. This state is equal to Running while ICE processing is with it. This state is equal to Running while ICE processing is
under way. The state is Completed when ICE processing is complete under way. The state is Completed when ICE processing is complete
and Failed if it failed without success. Rules for transitioning and Failed if it failed without success. Rules for transitioning
between states are described below. between states are described below.
5.7. Scheduling Checks 5.7. Scheduling Checks
Checks are generated only by full implementations. Lite Checks are generated only by full implementations. Lite
skipping to change at page 58, line 5 skipping to change at page 59, line 5
performing connectivity checks (Section 7), an agent sends STUN and performing connectivity checks (Section 7), an agent sends STUN and
TURN transactions. These transactions are paced at a rate of one TURN transactions. These transactions are paced at a rate of one
every Ta milliseconds, and utilize a specific RTO. This section every Ta milliseconds, and utilize a specific RTO. This section
describes how the values of Ta and RTO are computed. This describes how the values of Ta and RTO are computed. This
computation depends on whether ICE is being used with a real-time computation depends on whether ICE is being used with a real-time
media stream (such as RTP) or something else. When ICE is used for a media stream (such as RTP) or something else. When ICE is used for a
stream with a known maximum bandwidth, the computation in stream with a known maximum bandwidth, the computation in
Section 12.1 MAY be followed to rate-control the ICE exchanges. For Section 12.1 MAY be followed to rate-control the ICE exchanges. For
all other streams, the computation in Section 12.2 MUST be followed. all other streams, the computation in Section 12.2 MUST be followed.
12.1. RTP Media Streams 12.1. Real-time Media Streams
The values of RTO and Ta change during the lifetime of ICE The values of RTO and Ta change during the lifetime of ICE
processing. One set of values applies during the gathering phase, processing. One set of values applies during the gathering phase,
and the other, for connectivity checks. and the other, for connectivity checks.
The value of Ta SHOULD be configurable, and SHOULD have a default of: The value of Ta SHOULD be configurable, and SHOULD have a default of:
For each media stream i: For each media stream i:
Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime
skipping to change at page 59, line 38 skipping to change at page 60, line 38
maintains a nicely constant rate, but becomes more sensitive to maintains a nicely constant rate, but becomes more sensitive to
packet loss. The loss of the first single packet for any packet loss. The loss of the first single packet for any
connectivity check is likely to cause that pair to take a long time connectivity check is likely to cause that pair to take a long time
to be validated, and instead, a lower-priority check (but one for to be validated, and instead, a lower-priority check (but one for
which there was no packet loss) is much more likely to complete which there was no packet loss) is much more likely to complete
first. This results in ICE performing sub-optimally, choosing lower- first. This results in ICE performing sub-optimally, choosing lower-
priority pairs over higher-priority pairs. Implementors should be priority pairs over higher-priority pairs. Implementors should be
aware of this consequence, but still should utilize the timer values aware of this consequence, but still should utilize the timer values
described here. described here.
12.2. Non-RTP Sessions 12.2. Non-real-time Sessions
In cases where ICE is used to establish some kind of session that is In cases where ICE is used to establish some kind of session that is
not real time, and has no fixed rate associated with it that is known not real time, and has no fixed rate associated with it that is known
to work on the network in which ICE is deployed, Ta and RTO revert to to work on the network in which ICE is deployed, Ta and RTO revert to
more conservative values. Ta SHOULD be configurable, SHOULD have a more conservative values. Ta SHOULD be configurable, SHOULD have a
default of 500 ms, and MUST NOT be configurable to be less than 500 default of 500 ms, and MUST NOT be configurable to be less than 500
ms. ms.
If other Ta value than the default is used, the agent MUST indicate
the value it prefers to use in the ICE exchange. Both agents MUST
use the higher out of the two proposed values.
In addition, the retransmission timer for the STUN transactions, RTO, In addition, the retransmission timer for the STUN transactions, RTO,
SHOULD be configurable and during the gathering phase, SHOULD have a SHOULD be configurable and during the gathering phase, SHOULD have a
default of: default of:
RTO = MAX (500ms, Ta * (number of pairs)) RTO = MAX (500ms, Ta * (number of pairs))
where the number of pairs refers to the number of pairs of candidates where the number of pairs refers to the number of pairs of candidates
with STUN or TURN servers. with STUN or TURN servers.
For connectivity checks, RTO SHOULD be configurable and SHOULD have a For connectivity checks, RTO SHOULD be configurable and SHOULD have a
skipping to change at page 63, line 35 skipping to change at page 64, line 42
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
2. These are sent to the peer in an offer. 2. These are sent to the peer in an offer.
This offer is received at agent R. Agent R will obtain a host This offer is received at agent R. Agent R will obtain a host
candidate, and from it, obtain a server reflexive candidate (messages candidate, and from it, obtain a server reflexive candidate (messages
6-7). Since R is not behind a NAT, this candidate is identical to 6-7). Since R is not behind a NAT, this candidate is identical to
its host candidate, and they share the same base. It therefore its host candidate, and they share the same base. It therefore
discards this redundant candidate and ends up with a single host discards this redundant candidate and ends up with a single host
candidate. With identical type and local preferences as L, the candidate. With identical type and local preferences as L, the
priority for this candidate is 2130706431. It chooses a foundation priority for this candidate is 2130706431. It chooses a foundation
of 1 for its single candidate. The answerer's candidates are then of 1 for its single candidate. The answerer's candidates are then
sent to the offerer. sent to the offerer.
Since neither side indicated that it is lite, the agent that sent the Since neither side indicated that it is lite, the agent that sent the
skipping to change at page 64, line 39 skipping to change at page 65, line 46
the Binding request contained the USE-CANDIDATE attribute. Since the Binding request contained the USE-CANDIDATE attribute. Since
there is a selected candidate in the Valid list for the one component there is a selected candidate in the Valid list for the one component
of this media stream, ICE processing for this stream moves into the of this media stream, ICE processing for this stream moves into the
Completed state. Agent L can now send media if it so chooses. Completed state. Agent L can now send media if it so chooses.
Soon after receipt of the STUN Binding request from agent L (message Soon after receipt of the STUN Binding request from agent L (message
11), agent R will generate its triggered check. This check happens 11), agent R will generate its triggered check. This check happens
to match the next one on its check list -- from its host candidate to to match the next one on its check list -- from its host candidate to
agent L's server reflexive candidate. This check (messages 14-17) agent L's server reflexive candidate. This check (messages 14-17)
will succeed. Consequently, agent R constructs a new candidate pair will succeed. Consequently, agent R constructs a new candidate pair
using the mapped address from the response as the local candidate using the mapped address from the response as the local candidate (R-
(R-PUB-1) and the destination of the request (NAT-PUB-1) as the PUB-1) and the destination of the request (NAT-PUB-1) as the remote
remote candidate. This pair is added to the Valid list for that candidate. This pair is added to the Valid list for that media
media stream. Since the check was generated in the reverse direction stream. Since the check was generated in the reverse direction of a
of a check that contained the USE-CANDIDATE attribute, the candidate check that contained the USE-CANDIDATE attribute, the candidate pair
pair is marked as selected. Consequently, processing for this stream is marked as selected. Consequently, processing for this stream
moves into the Completed state, and agent R can also send media. moves into the Completed state, and agent R can also send media.
14. Security Considerations 14. Security Considerations
There are several types of attacks possible in an ICE system. This There are several types of attacks possible in an ICE system. This
section considers these attacks and their countermeasures. These section considers these attacks and their countermeasures. These
countermeasures include: countermeasures include:
o Using ICE in conjunction with secure signaling techniques, such as o Using ICE in conjunction with secure signaling techniques, such as
SIPS. SIPS.
skipping to change at page 65, line 20 skipping to change at page 66, line 26
offer or answer. offer or answer.
14.1. Attacks on Connectivity Checks 14.1. Attacks on Connectivity Checks
An attacker might attempt to disrupt the STUN connectivity checks. An attacker might attempt to disrupt the STUN connectivity checks.
Ultimately, all of these attacks fool an agent into thinking Ultimately, all of these attacks fool an agent into thinking
something incorrect about the results of the connectivity checks. something incorrect about the results of the connectivity checks.
The possible false conclusions an attacker can try and cause are: The possible false conclusions an attacker can try and cause are:
False Invalid: An attacker can fool a pair of agents into thinking a False Invalid: An attacker can fool a pair of agents into thinking a
candidate pair is invalid, when it isn't. This can be used to candidate pair is invalid, when it isn't. This can be used to
cause an agent to prefer a different candidate (such as one cause an agent to prefer a different candidate (such as one
injected by the attacker) or to disrupt a call by forcing all injected by the attacker) or to disrupt a call by forcing all
candidates to fail. candidates to fail.
False Valid: An attacker can fool a pair of agents into thinking a False Valid: An attacker can fool a pair of agents into thinking a
candidate pair is valid, when it isn't. This can cause an agent to candidate pair is valid, when it isn't. This can cause an agent
proceed with a session, but then not be able to receive any media. to proceed with a session, but then not be able to receive any
media.
False Peer Reflexive Candidate: An attacker can cause an agent to False Peer Reflexive Candidate: An attacker can cause an agent to
discover a new peer reflexive candidate, when it shouldn't have. discover a new peer reflexive candidate, when it shouldn't have.
This can be used to redirect media streams to a Denial-of-Service This can be used to redirect media streams to a Denial-of-Service
(DoS) target or to the attacker, for eavesdropping or other (DoS) target or to the attacker, for eavesdropping or other
purposes. purposes.
False Valid on False Candidate: An attacker has already convinced an False Valid on False Candidate: An attacker has already convinced an
agent that there is a candidate with an address that doesn't agent that there is a candidate with an address that doesn't
actually route to that agent (for example, by injecting a false actually route to that agent (for example, by injecting a false
skipping to change at page 79, line 42 skipping to change at page 81, line 11
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", draft- Andreasen, F., "A No-Op Payload Format for RTP", draft-
ietf-avt-rtp-no-op-04 (work in progress), May 2007. ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[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.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session [RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", RFC Initiation Protocol User Agent Profile Delivery", RFC
6080, March 2011. 6080, March 2011.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
skipping to change at page 81, line 43 skipping to change at page 83, line 21
these transactions paced, and why are these formulas used? these transactions paced, and why are these formulas used?
Sending of these STUN requests will often have the effect of creating Sending of these STUN requests will often have the effect of creating
bindings on NAT devices between the client and the STUN servers. bindings on NAT devices between the client and the STUN servers.
Experience has shown that many NAT devices have upper limits on the Experience has shown that many NAT devices have upper limits on the
rate at which they will create new bindings. Experiments have shown rate at which they will create new bindings. Experiments have shown
that once every 20 ms is well supported, but not much lower than that once every 20 ms is well supported, but not much lower than
that. This is why Ta has a lower bound of 20 ms. Furthermore, that. This is why Ta has a lower bound of 20 ms. Furthermore,
transmission of these packets on the network makes use of bandwidth transmission of these packets on the network makes use of bandwidth
and needs to be rate limited by the agent. Deployments based on and needs to be rate limited by the agent. Deployments based on
earlier draft versions of this document tended to overload rate- earlier draft versions of [RFC5245] tended to overload rate-
constrained access links and perform poorly overall, in addition to constrained access links and perform poorly overall, in addition to
negatively impacting the network. As a consequence, the pacing negatively impacting the network. As a consequence, the pacing
ensures that the NAT device does not get overloaded and that traffic ensures that the NAT device does not get overloaded and that traffic
is kept at a reasonable rate. is kept at a reasonable rate.
The definition of a "reasonable" rate is that STUN should not use The definition of a "reasonable" rate is that STUN should not use
more bandwidth than the RTP itself will use, once media starts more bandwidth than the RTP itself will use, once media starts
flowing. The formula for Ta is designed so that, if a STUN packet flowing. The formula for Ta is designed so that, if a STUN packet
were sent every Ta seconds, it would consume the same amount of were sent every Ta seconds, it would consume the same amount of
bandwidth as RTP packets, summed across all media streams. Of bandwidth as RTP packets, summed across all media streams. Of
skipping to change at page 83, line 49 skipping to change at page 85, line 49
----- -----
Figure 10: Identical Candidates with Different Bases Figure 10: Identical Candidates with Different Bases
In this case, the offerer is multihomed. It has one IP address, In this case, the offerer is multihomed. It has one IP address,
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 IP address 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 IP address 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 IP address 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
skipping to change at page 85, line 7 skipping to change at page 87, line 7
B.4. Importance of the STUN Username B.4. Importance of the STUN Username
ICE requires the usage of message integrity with STUN using its ICE requires the usage of message integrity with STUN using its
short-term credential functionality. The actual short-term short-term credential functionality. The actual short-term
credential is formed by exchanging username fragments in the offer/ credential is formed by exchanging username fragments in the offer/
answer exchange. The need for this mechanism goes beyond just answer exchange. The need for this mechanism goes beyond just
security; it is actually required for correct operation of ICE in the security; it is actually required for correct operation of ICE in the
first place. first place.
Consider agents L, R, and Z. L and R are within private enterprise 1, Consider agents L, R, and Z. L and R are within private enterprise
which is using 10.0.0.0/8. Z is within private enterprise 2, which 1, which is using 10.0.0.0/8. Z is within private enterprise 2,
is also using 10.0.0.0/8. As it turns out, R and Z both have IP which is also using 10.0.0.0/8. As it turns out, R and Z both have
address 10.0.1.1. L sends an offer to Z. Z, in its answer, provides IP address 10.0.1.1. L sends an offer to Z. Z, in its answer,
L with its host candidates. In this case, those candidates are provides L with its host candidates. In this case, those candidates
10.0.1.1:8866 and 10.0.1.1:8877. As it turns out, R is in a session are 10.0.1.1:8866 and 10.0.1.1:8877. As it turns out, R is in a
at that same time, and is also using 10.0.1.1:8866 and 10.0.1.1:8877 session at that same time, and is also using 10.0.1.1:8866 and
as host candidates. This means that R is prepared to accept STUN 10.0.1.1:8877 as host candidates. This means that R is prepared to
messages on those ports, just as Z is. L will send a STUN request to accept STUN messages on those ports, just as Z is. L will send a
10.0.1.1:8866 and another to 10.0.1.1:8877. However, these do not go STUN request to 10.0.1.1:8866 and another to 10.0.1.1:8877. However,
to Z as expected. Instead, they go to R! If R just replied to them, these do not go to Z as expected. Instead, they go to R! If R just
L would believe it has connectivity to Z, when in fact it has replied to them, L would believe it has connectivity to Z, when in
connectivity to a completely different user, R. To fix this, the STUN fact it has connectivity to a completely different user, R. To fix
short-term credential mechanisms are used. The username fragments this, the STUN short-term credential mechanisms are used. The
are sufficiently random that it is highly unlikely that R would be username fragments are sufficiently random that it is highly unlikely
using the same values as Z. Consequently, R would reject the STUN that R would be using the same values as Z. Consequently, R would
request since the credentials were invalid. In essence, the STUN reject the STUN request since the credentials were invalid. In
username fragments provide a form of transient host identifiers, essence, the STUN username fragments provide a form of transient host
bound to a particular offer/answer session. identifiers, bound to a particular offer/answer session.
An unfortunate consequence of the non-uniqueness of IP addresses is An unfortunate consequence of the non-uniqueness of IP addresses is
that, in the above example, R might not even be an ICE agent. It that, in the above example, R might not even be an ICE agent. It
could be any host, and the port to which the STUN packet is directed could be any host, and the port to which the STUN packet is directed
could be any ephemeral port on that host. If there is an application could be any ephemeral port on that host. If there is an application
listening on this socket for packets, and it is not prepared to listening on this socket for packets, and it is not prepared to
handle malformed packets for whatever protocol is in use, the handle malformed packets for whatever protocol is in use, the
operation of that application could be affected. Fortunately, since operation of that application could be affected. Fortunately, since
the ports exchanged in offer/answer are ephemeral and usually drawn the ports exchanged in offer/answer are ephemeral and usually drawn
from the dynamic or registered range, the odds are good that the port from the dynamic or registered range, the odds are good that the port
 End of changes. 27 change blocks. 
162 lines changed or deleted 184 lines changed or added

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