SIP J. Rosenberg Internet-Draft Cisco Systems Expires: July 7, 2007 January 3, 2007 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) draft-ietf-sip-ice-option-tag-00 Status of this Memo By submitting this Internet-Draft, each 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 7, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a UA to communicate to its registrar that it supports ICE. The option tag allows a User Agent (UA) to require support for ICE in order for a call to proceed. Rosenberg Expires July 7, 2007 [Page 1]
Internet-Draft ICE Support January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Mandating Support for ICE . . . . . . . . . . . . . . . . . 4 4. Media Feature Tag Definition . . . . . . . . . . . . . . . . . 4 5. Option Tag Definition . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 5 7.2. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Rosenberg Expires July 7, 2007 [Page 2]
Internet-Draft ICE Support January 2007 1. Introduction RFC 3264 [3] defines a two-phase exchange of Session Description Protocol (SDP) messages [5] for the purposes of establishment of multimedia sessions. This offer/answer mechanism is used by protocols such as the Session Initiation Protocol (SIP) [2]. Protocols using offer/answer are difficult to operate through Network Address Translators (NAT). Because their purpose is to establish a flow of media packets, they tend to carry IP addresses within their messages, which is known to be problematic through NAT [7]. To remedy this, an extension to SDP, called Interactive Connectivity Establishment (ICE) has been defined [6]. ICE defines procedures by which agents gather a multiplicity of addresses, include all of them in an SDP offer or answer, and then use peer-to-peer Simple Traversal Underneath NAT (STUN) [8] connectivity checks to determine a valid address. This specification defines a media feature tag, "sip.ice", and a SIP option tag, "ice", that can be used by SIP user agents that make use of ICE. Section 3 motivates the need for the media feature tag and option tag, and Section 4 and Section 5 formally define them. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 3. Motivation There are two primary motivations for defining an option tag and a media feature tag. They are support for gateways, and requiring ICE for a call. 3.1. Gateways Unfortunately, ICE requires both endpoints to support it in order for it to be used. Within a domain, there will typically be user agents that do and do not support ICE. In order to facilitate deployment of ICE, it is anticipated that domains will make use of gateways which act as ICE agents on one side, an non-ICE agents on the other side. This would allow a call from domain A into domain B to make use of ICE, even if the device in domain B does not itself yet support ICE. However, when domain B receives a call, it will need to know whether the call needs to pass through such a gateway, or whether it can go Rosenberg Expires July 7, 2007 [Page 3]
Internet-Draft ICE Support January 2007 to the terminating UA directly. In order to make such a determination, this specification defines a media feature tag, sip.ice, which can be included in the Contact header field of a REGISTER request [4]. This allows the registrar to track whether a UA supports ICE or not. This information can be accessed by a proxy in order to determine whether a call needs to route through a gateway or not. 3.2. Mandating Support for ICE Although ICE provides a built in fall back to non-ICE operation when the answerer doesn't support it, there are cases where the offerer would rather abort the call rather than proceed without ICE. Typically, this is because they would like to choose a different m/c- line address for a non-ICE peer than they would for an ICE capable peer. To do this, the "ice" SIP option tag can be included in the Require header field of an INVITE request. 4. Media Feature Tag Definition The sip.ice media feature tag indicates support for ICE. An agent supports ICE if it is capable of acting in either full or passive- only mode, and consequently, is capable of including candidate attributes in an SDP offer or answer for at least one transport protocol. An agent that supports ICE SHOULD include this media feature tag in the Contact header field of its REGISTER requests and OPTION responses. An agent MAY include them in the Contact header field of an INVITE or INVITE response; however, doing so is redundant with ICE attributes in the SDP which indicate the same thing. 5. Option Tag Definition This "ice" OPTION tag SHOULD NOT be used in conjunction with the Supported header field. The media feature tag is used as the one and only mechanism for indicating support for ICE. The option tag is meant to be used only with the Require header field. When placed in the Require header field of an INVITE request, it indicates that the UAS must support ICE in order to process the call. An agent supports ICE if it is capable of acting in either full or passive-only mode, and consequently, is capable of including candidate attributes in an SDP offer or answer for at least one transport protocol. Rosenberg Expires July 7, 2007 [Page 4]
Internet-Draft ICE Support January 2007 6. Security Considerations A malicious intermediary might attempt to modify a SIP message by inserting a Require header field containing the "ice" option tag. If ICE were not supported on the UAS, this would cause the call to fail when it would otherwise succeed. Of course, this attack is not specific to ICE, and can be done using any option tag. This attack is prevented by usage of the SIPS mechanism as defined in RFC 3261. Similarly, an intermediary might attempt to remove the media feature tag from a REGISTER request or OPTIONS request, which might cause a call to skip ICE processing when it otherwise might make use of it. This attack is also prevented using the SIP mechanism. 7. IANA Considerations This specification defines a new media feature tag and SIP option tag. 7.1. Option Tag This section defines a new SIP option tag per the guidelines in Section 27.1 of RFC 3261. Name: ice Description: This option tag is used to identify the Interactive Connectivity Establishment (ICE) extension. When present in a Supported header field, it indicates that ICE is supported by an agent. 7.2. Media Feature Tag This section registers a new media feature tag in the SIP tree, defined in Section 12.1 of RFC 3840 [4]. Media feature tag name: sip.ice ASN.1 Identifier: 1.3.6.1.8.4.22 Summary of the media feature indicated by this tag: This feature tag indicates that the device supports Interactive Connectivity Establishment (ICE). Rosenberg Expires July 7, 2007 [Page 5]
Internet-Draft ICE Support January 2007 Values appropriate for use with this feature tag: Boolean. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA. Examples of typical use: Routing a call to a phone that can support ICE. Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] Security Considerations: Security considerations for this media feature tag are discussed in Section 6 of RFC XXXX . [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in progress), October 2006. Rosenberg Expires July 7, 2007 [Page 6]
Internet-Draft ICE Support January 2007 8.2. Informative References [7] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. [8] Rosenberg, J., "Simple Traversal Underneath Network Address Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-04 (work in progress), July 2006. Rosenberg Expires July 7, 2007 [Page 7]
Internet-Draft ICE Support January 2007 Author's Address Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 Email: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Expires July 7, 2007 [Page 8]
Internet-Draft ICE Support January 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires July 7, 2007 [Page 9]
