idnits 2.17.1 draft-ietf-sip-ice-option-tag-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 316. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 19, 2007) is 6149 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (ref. '5') (Obsoleted by RFC 8866) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track June 19, 2007 5 Expires: December 21, 2007 7 Indicating Support for Interactive Connectivity Establishment (ICE) in 8 the Session Initiation Protocol (SIP) 9 draft-ietf-sip-ice-option-tag-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 21, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This specification defines a media feature tag and an option tag for 43 use with the Session Initiation Protocol (SIP). The media feature 44 tag allows a UA to communicate to its registrar that it supports ICE. 45 The option tag allows a User Agent (UA) to require support for ICE in 46 order for a call to proceed. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Mandating Support for ICE . . . . . . . . . . . . . . . . . 4 55 4. Media Feature Tag Definition . . . . . . . . . . . . . . . . . 4 56 5. Option Tag Definition . . . . . . . . . . . . . . . . . . . . . 4 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 59 7.1. Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.2. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Intellectual Property and Copyright Statements . . . . . . . . . . 8 67 1. Introduction 69 RFC 3264 [3] defines a two-phase exchange of Session Description 70 Protocol (SDP) messages [5] for the purposes of establishment of 71 multimedia sessions. This offer/answer mechanism is used by 72 protocols such as the Session Initiation Protocol (SIP) [2]. 74 Protocols using offer/answer are difficult to operate through Network 75 Address Translators (NAT). Because their purpose is to establish a 76 flow of media packets, they tend to carry IP addresses within their 77 messages, which is known to be problematic through NAT [7]. To 78 remedy this, an extension to SDP, called Interactive Connectivity 79 Establishment (ICE) has been defined [6]. ICE defines procedures by 80 which agents gather a multiplicity of addresses, include all of them 81 in an SDP offer or answer, and then use peer-to-peer Simple Traversal 82 Underneath NAT (STUN) [9] connectivity checks to determine a valid 83 address. 85 This specification defines a media feature tag, "sip.ice", and a SIP 86 option tag, "ice", that can be used by SIP user agents that make use 87 of ICE. Section 3 motivates the need for the media feature tag and 88 option tag, and Section 4 and Section 5 formally define them. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [1]. 96 3. Motivation 98 There are two primary motivations for defining an option tag and a 99 media feature tag. They are support for gateways, and requiring ICE 100 for a call. 102 3.1. Gateways 104 Unfortunately, ICE requires both endpoints to support it in order for 105 it to be used. Within a domain, there will typically be user agents 106 that do and do not support ICE. In order to facilitate deployment of 107 ICE, it is anticipated that domains will make use of gateways which 108 act as ICE agents on one side, an non-ICE agents on the other side. 109 This would allow a call from domain A into domain B to make use of 110 ICE, even if the device in domain B does not itself yet support ICE. 111 However, when domain B receives a call, it will need to know whether 112 the call needs to pass through such a gateway, or whether it can go 113 to the terminating UA directly. 115 In order to make such a determination, this specification defines a 116 media feature tag, "sip.ice", which can be included in the Contact 117 header field of a REGISTER request [4]. This allows the registrar to 118 track whether a UA supports ICE or not. This information can be 119 accessed by a proxy in order to determine whether a call needs to 120 route through a gateway or not. 122 3.2. Mandating Support for ICE 124 Although ICE provides a built in fall back to non-ICE operation when 125 the answerer doesn't support it, there are cases where the offerer 126 would rather abort the call rather than proceed without ICE. 127 Typically, this is because they would like to choose a different m/c- 128 line address for a non-ICE peer than they would for an ICE capable 129 peer. 131 To do this, the "ice" SIP option tag can be included in the Require 132 header field of an INVITE request. 134 4. Media Feature Tag Definition 136 The "sip.ice" media feature tag indicates support for ICE. An agent 137 supports ICE if it is either a lite or full implementation, and 138 consequently, is capable of including candidate attributes in an SDP 139 offer or answer for at least one transport protocol. An agent that 140 supports ICE SHOULD include this media feature tag in the Contact 141 header field of its REGISTER requests and OPTION responses. 143 An agent MAY include the media feature tag in the Contact header 144 field of an INVITE or INVITE response; however, doing so is redundant 145 with ICE attributes in the SDP which indicate the same thing. In 146 cases where an INVITE omits an offer, the lack or presence of the 147 media feature tag in the Contact header field cannot be used by the 148 callee (which will be the offerer) to determine whether the caller 149 supports ICE. In cases of third party call control [8], the caller 150 may be a controller that supports (or doesn't) ICE, while the 151 answerer may be an agent which does (or doesn't) support ICE. 153 5. Option Tag Definition 155 This "ice" OPTION tag SHOULD NOT be used in conjunction with the 156 Supported header field (this SHOULD NOT includes responses to OPTIONS 157 requests) The media feature tag is used as the one and only mechanism 158 for indicating support for ICE. The option tag is meant to be used 159 only with the Require header field. When placed in the Require 160 header field of an INVITE request, it indicates that the UAS must 161 support ICE in order to process the call. An agent supports ICE if 162 it is either a full or lite implementation, and consequently, is 163 capable of including candidate attributes in an SDP offer or answer 164 for at least one transport protocol. 166 6. Security Considerations 168 A malicious intermediary might attempt to modify a SIP message by 169 inserting a Require header field containing the "ice" option tag. If 170 ICE were not supported on the UAS, this would cause the call to fail 171 when it would otherwise succeed. Of course, this attack is not 172 specific to ICE, and can be done using any option tag. This attack 173 is prevented by usage of the SIPS mechanism as defined in RFC 3261. 175 Similarly, an intermediary might attempt to remove the media feature 176 tag from a REGISTER request or OPTIONS request, which might cause a 177 call to skip ICE processing when it otherwise might make use of it. 178 This attack is also prevented using the SIPS mechanism. 180 7. IANA Considerations 182 This specification defines a new media feature tag and SIP option 183 tag. 185 7.1. Option Tag 187 This section defines a new SIP option tag per the guidelines in 188 Section 27.1 of RFC 3261. 190 Name: ice 192 Description: This option tag is used to identify the Interactive 193 Connectivity Establishment (ICE) extension. When present in a 194 Require header field, it indicates that ICE is required by an 195 agent. 197 7.2. Media Feature Tag 199 This section registers a new media feature tag in the SIP tree, 200 defined in Section 12.1 of RFC 3840 [4]. 202 Media feature tag name: sip.ice 204 ASN.1 Identifier: 1.3.6.1.8.4.22 206 Summary of the media feature indicated by this tag: This feature tag 207 indicates that the device supports Interactive Connectivity 208 Establishment (ICE). 210 Values appropriate for use with this feature tag: Boolean. 212 The feature tag is intended primarily for use in the following 213 applications, protocols, services, or negotiation mechanisms: This 214 feature tag is most useful in a communications application, for 215 describing the capabilities of a device, such as a phone or PDA. 217 Examples of typical use: Routing a call to a phone that can support 218 ICE. 220 Related standards or documents: RFC XXXX [[Note to IANA: Please 221 replace XXXX with the RFC number of this specification.]] 223 Security Considerations: Security considerations for this media 224 feature tag are discussed in Section 6 of RFC XXXX . [[Note to 225 IANA: Please replace XXXX with the RFC number of this 226 specification.]] 228 8. References 230 8.1. Normative References 232 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 233 Levels", BCP 14, RFC 2119, March 1997. 235 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 236 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 237 Session Initiation Protocol", RFC 3261, June 2002. 239 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 240 Session Description Protocol (SDP)", RFC 3264, June 2002. 242 [4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User 243 Agent Capabilities in the Session Initiation Protocol (SIP)", 244 RFC 3840, August 2004. 246 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 247 Description Protocol", RFC 4566, July 2006. 249 [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 250 Methodology for Network Address Translator (NAT) Traversal for 251 Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in 252 progress), January 2007. 254 8.2. Informative References 256 [7] Senie, D., "Network Address Translator (NAT)-Friendly 257 Application Design Guidelines", RFC 3235, January 2002. 259 [8] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 260 "Best Current Practices for Third Party Call Control (3pcc) in 261 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 262 April 2004. 264 [9] Rosenberg, J., "Simple Traversal Underneath Network Address 265 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 (work 266 in progress), October 2006. 268 Author's Address 270 Jonathan Rosenberg 271 Cisco 272 Edison, NJ 273 US 275 Email: jdrosen@cisco.com 276 URI: http://www.jdrosen.net 278 Full Copyright Statement 280 Copyright (C) The IETF Trust (2007). 282 This document is subject to the rights, licenses and restrictions 283 contained in BCP 78, and except as set forth therein, the authors 284 retain all their rights. 286 This document and the information contained herein are provided on an 287 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 288 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 289 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 290 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 291 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 292 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 294 Intellectual Property 296 The IETF takes no position regarding the validity or scope of any 297 Intellectual Property Rights or other rights that might be claimed to 298 pertain to the implementation or use of the technology described in 299 this document or the extent to which any license under such rights 300 might or might not be available; nor does it represent that it has 301 made any independent effort to identify any such rights. Information 302 on the procedures with respect to rights in RFC documents can be 303 found in BCP 78 and BCP 79. 305 Copies of IPR disclosures made to the IETF Secretariat and any 306 assurances of licenses to be made available, or the result of an 307 attempt made to obtain a general license or permission for the use of 308 such proprietary rights by implementers or users of this 309 specification can be obtained from the IETF on-line IPR repository at 310 http://www.ietf.org/ipr. 312 The IETF invites any interested party to bring to its attention any 313 copyrights, patents or patent applications, or other proprietary 314 rights that may cover technology that may be required to implement 315 this standard. Please address the information to the IETF at 316 ietf-ipr@ietf.org. 318 Acknowledgment 320 Funding for the RFC Editor function is provided by the IETF 321 Administrative Support Activity (IASA).