draft-ietf-mmusic-ice-03.txt   draft-ietf-mmusic-ice-04.txt 
MMUSIC J. Rosenberg MMUSIC J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: April 25, 2005 October 25, 2004 Expires: August 22, 2005 February 21, 2005
Interactive Connectivity Establishment (ICE): A Methodology for Interactive Connectivity Establishment (ICE): A Methodology for
Network Address Translator (NAT) Traversal for Multimedia Session Network Address Translator (NAT) Traversal for Multimedia Session
Establishment Protocols Establishment Protocols
draft-ietf-mmusic-ice-03 draft-ietf-mmusic-ice-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any 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 become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
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."
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 April 25, 2005. This Internet-Draft will expire on August 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a methodology for Network Address Translator This document describes a methodology for Network Address Translator
(NAT) traversal for multimedia session signaling protocols, such as (NAT) traversal for multimedia session signaling protocols, such as
the Session Initiation Protocol (SIP). This methodology is called the Session Initiation Protocol (SIP). This methodology is called
Interactive Connectivity Establishment (ICE). ICE makes use of Interactive Connectivity Establishment (ICE). ICE makes use of
existing protocols, such as Simple Traversal of UDP Through NAT existing protocols, such as Simple Traversal of UDP Through NAT
(STUN) and Traversal Using Relay NAT (TURN). ICE makes use of STUN (STUN) and Traversal Using Relay NAT (TURN). ICE makes use of STUN
in peer-to-peer cooperative fashion, allowing participants to in peer-to-peer cooperative fashion, allowing participants to
discover, create and verify mutual connectivity. discover, create and verify mutual connectivity.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Multimedia Signaling Protocol Abstraction . . . . . . . . . . 4 2. Multimedia Signaling Protocol Abstraction . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 8
5. Detailed ICE Algorithm . . . . . . . . . . . . . . . . . . . . 9 5. Detailed ICE Algorithm . . . . . . . . . . . . . . . . . . . . 10
5.1 Initiator Processing . . . . . . . . . . . . . . . . . . . 10 5.1 Initiator Processing . . . . . . . . . . . . . . . . . . . 11
5.1.1 Sending the Initiate Message . . . . . . . . . . . . . 10 5.1.1 Sending the Initiate Message . . . . . . . . . . . . . 11
5.1.2 Processing the Accept . . . . . . . . . . . . . . . . 11 5.1.2 Processing the Accept . . . . . . . . . . . . . . . . 12
5.2 Responder Processing . . . . . . . . . . . . . . . . . . . 11 5.2 Responder Processing . . . . . . . . . . . . . . . . . . . 12
5.2.1 Processing the Initiate Message . . . . . . . . . . . 11 5.2.1 Processing the Initiate Message . . . . . . . . . . . 12
5.3 Common Procedures . . . . . . . . . . . . . . . . . . . . 12 5.3 Common Procedures . . . . . . . . . . . . . . . . . . . . 13
5.3.1 Gathering Transport Addresses . . . . . . . . . . . . 12 5.3.1 Gathering Transport Addresses . . . . . . . . . . . . 13
5.3.2 Enabling STUN on Each Local Transport Address . . . . 14 5.3.2 Enabling STUN on Each Local Transport Address . . . . 15
5.3.3 Prioritizing the Transport Addresses and Choosing 5.3.3 Prioritizing the Transport Addresses and Choosing
a Default . . . . . . . . . . . . . . . . . . . . . . 16 a Default . . . . . . . . . . . . . . . . . . . . . . 17
5.3.4 Sending STUN Connectivity Checks . . . . . . . . . . . 18 5.3.4 Sending STUN Connectivity Checks . . . . . . . . . . . 19
5.3.5 Receiving STUN Requests . . . . . . . . . . . . . . . 23 5.3.5 Receiving STUN Requests . . . . . . . . . . . . . . . 24
5.3.6 Management of Resources . . . . . . . . . . . . . . . 24 5.3.6 Management of Resources . . . . . . . . . . . . . . . 25
5.3.7 Binding Keepalives . . . . . . . . . . . . . . . . . . 24 5.3.7 Binding Keepalives . . . . . . . . . . . . . . . . . . 25
6. Running STUN on Derived Transport Addresses . . . . . . . . . 25 6. Running STUN on Derived Transport Addresses . . . . . . . . . 26
6.1 STUN on a TURN Derived Transport Address . . . . . . . . . 26 6.1 STUN on a TURN Derived Transport Address . . . . . . . . . 27
6.2 STUN on a STUN Derived Transport Address . . . . . . . . . 28 6.2 STUN on a STUN Derived Transport Address . . . . . . . . . 29
7. XML Schema for ICE Messages . . . . . . . . . . . . . . . . . 29 7. XML Schema for ICE Messages . . . . . . . . . . . . . . . . . 30
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. Mapping ICE into SIP . . . . . . . . . . . . . . . . . . . . . 34 9. Mapping ICE into SIP . . . . . . . . . . . . . . . . . . . . . 35
9.1 Message Mapping . . . . . . . . . . . . . . . . . . . . . 34 9.1 Message Mapping . . . . . . . . . . . . . . . . . . . . . 35
9.2 SIP and SDP Specific Security Considerations . . . . . . . 36 9.2 SIP and SDP Specific Security Considerations . . . . . . . 37
9.3 Updates in the Offer/Answer Model . . . . . . . . . . . . 36 9.3 Updates in the Offer/Answer Model . . . . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . 37
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
11.1 SDP Attribute Name . . . . . . . . . . . . . . . . . . . . 37 11.1 SDP Attribute Name . . . . . . . . . . . . . . . . . . . . 38
11.2 URN Sub-Namespace Registration . . . . . . . . . . . . . . 38 11.2 URN Sub-Namespace Registration . . . . . . . . . . . . . . 39
11.3 XML Schema Registration . . . . . . . . . . . . . . . . . 39 11.3 XML Schema Registration . . . . . . . . . . . . . . . . . 40
12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 39 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 40
12.1 Problem Definition . . . . . . . . . . . . . . . . . . . . 40 12.1 Problem Definition . . . . . . . . . . . . . . . . . . . . 41
12.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 40 12.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 41
12.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . 41 12.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . 42
12.4 Requirements for a Long Term Solution . . . . . . . . . . 41 12.4 Requirements for a Long Term Solution . . . . . . . . . . 42
12.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . 42 12.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . 43
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 42 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 43
14.2 Informative References . . . . . . . . . . . . . . . . . . . 43 14.2 Informative References . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . . 46
1. Introduction 1. Introduction
A multimedia session signaling protocol is a protocol that exchanges A multimedia session signaling protocol is a protocol that exchanges
control messages between a pair of agents for the purposes of control messages between a pair of agents for the purposes of
establishing the flow of media traffic between them. This media flow establishing the flow of media traffic between them. This media flow
is distinct from the flow of control messages, and may take a is distinct from the flow of control messages, and may take a
different path through the network. Examples of such protocols are different path through the network. Examples of such protocols are
the Session Initiation Protocol (SIP) [3], the Real Time Streaming the Session Initiation Protocol (SIP) [3], the Real Time Streaming
Protocol (RTSP) [9] and the International Telecommunications Union Protocol (RTSP) [9] and the International Telecommunications Union
skipping to change at page 22, line 24 skipping to change at page 23, line 24
It means that a new STUN transaction begins 50ms after the completion It means that a new STUN transaction begins 50ms after the completion
of the previous one. STUN transactions themselves employ of the previous one. STUN transactions themselves employ
exponentially back off retransmit timers. The second timer, called exponentially back off retransmit timers. The second timer, called
the Giveup Timer, determines how long the client will keep trying the Giveup Timer, determines how long the client will keep trying
until it decides that the remote transport address is unreachable. until it decides that the remote transport address is unreachable.
This timer SHOULD be configurable. It is RECOMMENDED that it default This timer SHOULD be configurable. It is RECOMMENDED that it default
to 50 seconds. This is a reasonable approximation of the maximum SIP to 50 seconds. This is a reasonable approximation of the maximum SIP
transaction duration. transaction duration.
If, from the INIT state the STUN transaction generates a race-failure If, from the INIT state the STUN transaction generates a race-failure
event, it means that the peer has not yet completed the initiate/ event, it means that the peer has not yet completed the
accept exchange, and thus the username has not been allocated. initiate/accept exchange, and thus the username has not been
Another BindingRequest transaction needs to take place to try again. allocated. Another BindingRequest transaction needs to take place to
Thus, the same retry and giveup timers as in the timeout event are try again. Thus, the same retry and giveup timers as in the timeout
started. event are started.
If, from the INIT state, the STUN transaction generates an error, the If, from the INIT state, the STUN transaction generates an error, the
FSM moves into the BAD state. This state means that the connection FSM moves into the BAD state. This state means that the connection
is definitively unreachable, and it will not be used subsequently in is definitively unreachable, and it will not be used subsequently in
the session. the session.
If, while in the HANDSHAKING state, the Giveup timer fires, or the If, while in the HANDSHAKING state, the Giveup timer fires, or the
STUN transaction results in an error, the client moves into the BAD STUN transaction results in an error, the client moves into the BAD
state. If, while in the HANDSHAKING state, the Rapid Retry timer state. If, while in the HANDSHAKING state, the Rapid Retry timer
fires, a new STUN transaction is started. The output of that fires, a new STUN transaction is started. The output of that
skipping to change at page 43, line 7 skipping to change at page 44, line 7
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [5] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002. Comfort Noise (CN)", RFC 3389, September 2002.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004. 2004.
[7] Camarillo, G., "The Alternative Network Address Types Semantics [7] Camarillo, G., "The Alternative Network Address Types Semantics
for the Session Description Protocol Grouping Framework", (ANAT) for theSession Description Protocol (SDP) Grouping
draft-ietf-mmusic-anat-01 (work in progress), June 2004. Framework", draft-ietf-mmusic-anat-02 (work in progress),
October 2004.
[8] Rosenberg, J., "Traversal Using Relay NAT (TURN)", [8] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-05 (work in progress), July 2004. draft-rosenberg-midcom-turn-06 (work in progress), October 2004.
14.2 Informative References 14.2 Informative References
[9] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming [9] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
[10] Senie, D., "Network Address Translator (NAT)-Friendly [10] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002. Application Design Guidelines", RFC 3235, January 2002.
[11] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. [11] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
skipping to change at page 43, line 47 skipping to change at page 44, line 48
3550, July 2003. 3550, July 2003.
[16] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. [16] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004. 3711, March 2004.
[17] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via [17] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[18] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", [18] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
draft-huitema-v6ops-teredo-02 (work in progress), June 2004. draft-huitema-v6ops-teredo-04 (work in progress), January 2005.
[19] Hellstrom, G., "RTP Payload for Text Conversation", [19] Hellstrom, G., "RTP Payload for Text Conversation",
draft-ietf-avt-rfc2793bis-09 (work in progress), August 2004. draft-ietf-avt-rfc2793bis-09 (work in progress), August 2004.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 45, line 41 skipping to change at page 46, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/