idnits 2.17.1 draft-ietf-sip-anat-usage-00.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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 260. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 276), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 16, 2004) is 7216 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) == Unused Reference: '4' is defined on line 209, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3388 (ref. '5') (Obsoleted by RFC 5888) == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-anat-00 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: December 15, 2004 J. Rosenberg 4 dynamicsoft 5 June 16, 2004 7 Usage of the Session Description Protocol (SDP) Alternative Network 8 Address Types (ANAT) Semantics in the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sip-anat-usage-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-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 http:// 29 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 15, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes how to use the ANAT semantics of the SDP 43 grouping framework in SIP. In particular, we define the sdp-anat SIP 44 option-tag. This SIP option-tag ensures that SDP session descriptions 45 using ANAT are only handled by SIP entities with ANAT support. To 46 justify the need for such a SIP option-tag, we describe what could 47 possibly happen if an ANAT-unaware SIP entity tried to handle media 48 lines grouped with ANAT. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. The sdp-anat Option-Tag . . . . . . . . . . . . . . . . . . . 3 55 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 3 56 4.1 Answerer Supports All the Network Types Offered . . . . . 4 57 4.2 Answerer does Not Support All the Network Types Offered . 4 58 4.3 OPTIONS Requests . . . . . . . . . . . . . . . . . . . . . 4 59 5. Option-Tag Usage . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 64 Intellectual Property and Copyright Statements . . . . . . . . 7 66 1. Introduction 68 SIP [3] UAs (User Agents) have often support for different network 69 address types. For example, a UA may have an IPv6 address and an IPv4 70 address. Such a UA will typically be willing to use any of its 71 addresses to establish a media session with a remote UA. If the 72 remote UA only supports IPv6, for instance, both UAs will use IPv6 to 73 send and receive media. 75 The ANAT semantics [6] of the SDP [2] grouping framework [5] allow 76 UAs to offer alternative addresses of different types in an SDP 77 session description. The IPv4/IPv6 dual-stack SIP UA of our previous 78 example would generate an offer grouping an IPv6 media line and an 79 IPv4 media line using ANAT. On reception of this offer, the answerer 80 would accept one media line and reject the other. 82 If the recipient of an offer that uses ANAT supports the ANAT 83 semantics, everything works as described in the ANAT specification 84 [6]. Nevertheless, the recipient of such an offer (i.e., the 85 answerer) may not support ANAT. In this case, different 86 implementations of the answerer would react in different ways. This 87 document discusses the answerer's behaviors that are most likely to 88 be found and describes their consequences. To avoid these 89 consequences, we define the sdp-anat SIP option-tag. 91 The sdp-anat option-tag can be used to ensure that an offer using 92 ANAT is not processed by answerers without support for ANAT. This 93 option-tag can also be used to explicitly discover the capabilities 94 of a UA (i.e., whether or not it supports ANAT). 96 2. Terminology 98 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 99 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 100 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 101 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 102 compliant implementations. 104 3. The sdp-anat Option-Tag 106 We define the option-tag sdp-anat for use in the Require and 107 Supported SIP [3] header fields. SIP user agents that place this 108 option-tag in a Supported header field understand the ANAT semantics 109 as defined in [6]. 111 4. Backward Compatibility 113 Answerers without support for ANAT will react in different ways on 114 reception of an offer using ANAT. We expect that, even under the same 115 circumstances, different implementations behave in different ways. In 116 this section, we analyze these behaviors (i.e., the next subsections 117 assume that the answerer does not support ANAT). 119 4.1 Answerer Supports All the Network Types Offered 121 If the answerer supports all the network types in the offer, it may 122 accept the offer and establish all the media streams in it. This 123 behavior is not what the offerer expected because it results in too 124 many media streams being established. If the answerer starts sending 125 media over all of them, the result may be a high bandwidth usage. 127 The answerer may also reject the offer, because although it supports 128 all the network types in it, the answerer may not support them 129 simultaneously. The error response sent by the answerer will most 130 likely not be explicit enough about the situation. So, the offerer 131 will not understand what went wrong. 133 In the previous scenarios, the sdp-anat option-tag would avoid the 134 establishment of too many media streams and would allow the answerer 135 to explicitly inform the offerer that the answerer did not support 136 ANAT. 138 4.2 Answerer does Not Support All the Network Types Offered 140 If the answerer does not support all the network types in the offer, 141 it may only establish the media streams whose address types 142 understands (it would reject the rest). This would be an acceptable 143 behavior from the offerer's point of view. 145 On the other hand, the answerer may also reject the offer because it 146 contains unknown address types. The error response sent by the 147 answerer will most likely not be explicit enough about the situation. 148 So, the offerer will not understand what went wrong. 150 In the previous scenario, the sdp-anat option-tag would allow the 151 answerer to explicitly inform the offerer that the answerer did not 152 support ANAT. 154 4.3 OPTIONS Requests 156 Although RFC 3388 [5] provides servers with a means to indicate 157 support for ANAT in an SDP description, many servers do not include 158 an SDP description in their responses to OPTIONS requests. The 159 sdp-anat option-tag makes it possible to discover if any server 160 supports ANAT, since they would include this option-tag in a 161 Supported header field in their responses. 163 5. Option-Tag Usage 165 As discussed in the previous section, the use of the sdp-anat 166 option-tag makes SIP messages more explicit about ANAT support, which 167 is generally a good property. So, SIP entities generating an offer 168 that uses the ANAT semantics SHOULD place the sdp-anat option-tag in 169 a Require header field. SIP entities that support the ANAT semantics 170 MUST understand the sdp-anat option-tag. 172 6. Security Considerations 174 An attacker may attempt to add the sdp-anat option tag to the Require 175 header field of a message to perform a DoS attack. If the UAS does 176 not support ANAT, it will return an error response instead of 177 processing the message. 179 An attacker may attemp to remove the sdp-anat option-tag from the 180 Require header field of a message. This may result in the 181 establishment of too many media streams. 183 To avoid the previous attacks, it is RECOMMENDED that the Require 184 header field is integrity protected. The natural choice to integrity 185 protect header fields in SIP is S/MIME. 187 7. IANA Considerations 189 This document defines a SIP option-tag (sdp-anat) in Section 3. It 190 should be registered in the SIP parameter registry at: 192 http://www.iana.org/assignments/sip-parameters 194 SIP user agents that place the sdp-anat option-tag in a Supported 195 header field understand the ANAT semantics. 197 8 Normative References 199 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 200 Levels", BCP 14, RFC 2119, March 1997. 202 [2] Handley, M. and V. Jacobson, "SDP: Session Description 203 Protocol", RFC 2327, April 1998. 205 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 206 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 207 Session Initiation Protocol", RFC 3261, June 2002. 209 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 210 Session Description Protocol (SDP)", RFC 3264, June 2002. 212 [5] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, 213 "Grouping of Media Lines in the Session Description Protocol 214 (SDP)", RFC 3388, December 2002. 216 [6] Camarillo, G., "The Alternative Network Address Types Semantics 217 for the Session Description Protocol Grouping Framework", 218 draft-ietf-mmusic-anat-00 (work in progress), December 2003. 220 Authors' Addresses 222 Gonzalo Camarillo 223 Ericsson 224 Hirsalantie 11 225 Jorvas 02420 226 Finland 228 EMail: Gonzalo.Camarillo@ericsson.com 230 Jonathan Rosenberg 231 dynamicsoft 232 600 Lanidex Plaza 233 Parsippany, NJ 07054 234 US 236 EMail: jdrosen@dynamicsoft.com 238 Intellectual Property Statement 240 The IETF takes no position regarding the validity or scope of any 241 Intellectual Property Rights or other rights that might be claimed to 242 pertain to the implementation or use of the technology described in 243 this document or the extent to which any license under such rights 244 might or might not be available; nor does it represent that it has 245 made any independent effort to identify any such rights. Information 246 on the IETF's procedures with respect to rights in IETF Documents can 247 be found in BCP 78 and BCP 79. 249 Copies of IPR disclosures made to the IETF Secretariat and any 250 assurances of licenses to be made available, or the result of an 251 attempt made to obtain a general license or permission for the use of 252 such proprietary rights by implementers or users of this 253 specification can be obtained from the IETF on-line IPR repository at 254 http://www.ietf.org/ipr. 256 The IETF invites any interested party to bring to its attention any 257 copyrights, patents or patent applications, or other proprietary 258 rights that may cover technology that may be required to implement 259 this standard. Please address the information to the IETF at 260 ietf-ipr@ietf.org. 262 Disclaimer of Validity 264 This document and the information contained herein are provided on an 265 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 266 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 267 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 268 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 269 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 270 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 272 Copyright Statement 274 Copyright (C) The Internet Society (2004). This document is subject 275 to the rights, licenses and restrictions contained in BCP 78, and 276 except as set forth therein, the authors retain all their rights. 278 Acknowledgment 280 Funding for the RFC Editor function is currently provided by the 281 Internet Society.