idnits 2.17.1 draft-camarillo-sip-anat-option-tag-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 247. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 263), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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 1, 2004) is 7268 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 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 (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: November 30, 2004 J. Rosenberg 4 dynamicsoft 5 June 1, 2004 7 The sdp-anat Session Initiation Protocol (SIP) Option-Tag 8 draft-camarillo-sip-anat-option-tag-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document defines the sdp-anat SIP option-tag. The presence of 41 this option-tag in a Supported header field indicates support for the 42 SDP grouping framework and for the ANAT (Alternative Network Address 43 Types) semantics. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. The sdp-anat Option-Tag . . . . . . . . . . . . . . . . . . . 3 50 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 3 51 4.1 Answerer Supports All the Network Types Offered . . . . . 3 52 4.2 Answerer does not Support All the Network Types Offered . 4 53 4.3 OPTIONS Requests . . . . . . . . . . . . . . . . . . . . . 4 54 5. Option-Tag Usage . . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 59 Intellectual Property and Copyright Statements . . . . . . . . 7 61 1. Introduction 63 SIP [3] UAs (User Agents) with support for different network types 64 can use the ANAT semantics [6] of the SDP [2] grouping framework [5] 65 to offer alterative addresses of different types. For example, an 66 IPv4/IPv6 dual stack SIP UA following the offer/answer model [4] 67 would generate an offer grouping its IPv6 address and its IPv4 68 address using ANAT. 70 If the recipient of an offer that uses ANAT supports the ANAT 71 semantics, everything works as described in the ANAT specification 72 [6]. Nevertheless, the recipient of such an offer (i.e., the 73 answerer) may not support ANAT. In this case, different 74 implementations of the answerer would react in different ways. This 75 document discusses the answerer behaviors that are most likely to be 76 found and defines the sdp-anat SIP option-tag. 78 The sdp-anat option-tag can be used to ensure that an offer using 79 ANAT is not processed by answerers without support for ANAT. This 80 option-tag can also be used to explicitly discover the capabilities 81 of a UA (i.e., whether or not it supports ANAT). 83 2. Terminology 85 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 86 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 87 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 88 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 89 compliant implementations. 91 3. The sdp-anat Option-Tag 93 We define the option-tag sdp-anat for use in the Require and 94 Supported SIP [3] header fields. SIP user agents that place this 95 option-tag in a Supported header field understand the ANAT semantics 96 as defined in [6]. 98 4. Backward Compatibility 100 Answerers without support for ANAT will react in different ways on 101 reception of an offer using ANAT. We expect that, even under the same 102 circumstances, different implementations behave in different ways. In 103 this section, we analyze these behaviors (i.e., the next subsections 104 assume that the answerer does not support ANAT). 106 4.1 Answerer Supports All the Network Types Offered 108 If the answerer supports all the network types in the offer, it may 109 accept the offer and establish all the media streams in it. This 110 behavior is not what the offerer expected because it results in too 111 many media streams being established. If the answerer starts sending 112 media over all of them, the result may be a high bandwidth usage. 114 The answerer may also reject the offer, because although it supports 115 all the network types in it, the answerer may not support them 116 simultaneously. The error response sent by the answerer will most 117 likely not be explicit enough about the situation. So, the offerer 118 will not understand what went wrong. 120 In the previous scenarios, the sdp-anat option-tag would avoid the 121 establishment of too many media streams and would allow the answerer 122 to explicitly inform the offerer that the answerer did not support 123 ANAT. 125 4.2 Answerer does not Support All the Network Types Offered 127 If the answerer does not support all the network types in the offer, 128 it may only establish the media streams whose address types 129 understands (it would reject the rest). This would be an acceptable 130 behavior from the offerer's point of view. 132 On the other hand, the answerer may also reject the offer because it 133 contains unknown address types. The error response sent by the 134 answerer will most likely not be explicit enough about the situation. 135 So, the offerer will not understand what went wrong. 137 In the previous scenario, the sdp-anat option-tag would allow the 138 answerer to explicitly inform the offerer that the answerer did not 139 support ANAT. 141 4.3 OPTIONS Requests 143 Although RFC 3388 [5] provides servers with a means to indicate 144 support for ANAT in an SDP description, many servers do not include 145 an SDP description in their responses to OPTIONS requests. The 146 sdp-anat option-tag makes it possible to discover if any server 147 supports ANAT, since they would include this option-tag in a 148 Supported header field in their responses. 150 5. Option-Tag Usage 152 As discussed in the previous section, the use of the sdp-anat 153 option-tag makes SIP messages more explicit about ANAT support, which 154 is generally a good property. So, SIP entities generating an offer 155 that uses the ANAT semantics SHOULD place the sdp-anat option-tag in 156 a Require header field. SIP entities that support the ANAT semantics 157 MUST understand the sdp-anat option-tag. 159 6. Security Considerations 161 An attacker may attempt to add the sdp-anat option tag to the Require 162 header field of a message to perform a DoS attack. If the UAS does 163 not support ANAT, it will return an error response instead of 164 processing the message. 166 An attacker may attemp to remove the sdp-anat option-tag from the 167 Require header field of a message. This may result in the 168 establishment of too many media streams. 170 To avoid the previous attacks, it is RECOMMENDED that the Require 171 header field is integrity protected. The natural choice to integrity 172 protect header fields in SIP is S/MIME. 174 7. IANA Considerations 176 This document defines a SIP option-tag (sdp-anat) in Section 3. It 177 should be registered in the SIP parameter registry at: 179 http://www.iana.org/assignments/sip-parameters 181 SIP user agents that place the sdp-anat option-tag in a Supported 182 header field understand the ANAT semantics. 184 8 Normative References 186 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 187 Levels", BCP 14, RFC 2119, March 1997. 189 [2] Handley, M. and V. Jacobson, "SDP: Session Description 190 Protocol", RFC 2327, April 1998. 192 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 193 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 194 Session Initiation Protocol", RFC 3261, June 2002. 196 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 197 Session Description Protocol (SDP)", RFC 3264, June 2002. 199 [5] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, 200 "Grouping of Media Lines in the Session Description Protocol 201 (SDP)", RFC 3388, December 2002. 203 [6] Camarillo, G., "The Alternative Network Address Types Semantics 204 for the Session Description Protocol Grouping Framework", 205 draft-ietf-mmusic-anat-00 (work in progress), December 2003. 207 Authors' Addresses 209 Gonzalo Camarillo 210 Ericsson 211 Hirsalantie 11 212 Jorvas 02420 213 Finland 215 EMail: Gonzalo.Camarillo@ericsson.com 217 Jonathan Rosenberg 218 dynamicsoft 219 600 Lanidex Plaza 220 Parsippany, NJ 07054 221 US 223 EMail: jdrosen@dynamicsoft.com 225 Intellectual Property Statement 227 The IETF takes no position regarding the validity or scope of any 228 Intellectual Property Rights or other rights that might be claimed to 229 pertain to the implementation or use of the technology described in 230 this document or the extent to which any license under such rights 231 might or might not be available; nor does it represent that it has 232 made any independent effort to identify any such rights. Information 233 on the IETF's procedures with respect to rights in IETF Documents can 234 be found in BCP 78 and BCP 79. 236 Copies of IPR disclosures made to the IETF Secretariat and any 237 assurances of licenses to be made available, or the result of an 238 attempt made to obtain a general license or permission for the use of 239 such proprietary rights by implementers or users of this 240 specification can be obtained from the IETF on-line IPR repository at 241 http://www.ietf.org/ipr. 243 The IETF invites any interested party to bring to its attention any 244 copyrights, patents or patent applications, or other proprietary 245 rights that may cover technology that may be required to implement 246 this standard. Please address the information to the IETF at 247 ietf-ipr@ietf.org. 249 Disclaimer of Validity 251 This document and the information contained herein are provided on an 252 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 253 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 254 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 255 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 256 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 257 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 259 Copyright Statement 261 Copyright (C) The Internet Society (2004). This document is subject 262 to the rights, licenses and restrictions contained in BCP 78, and 263 except as set forth therein, the authors retain all their rights. 265 Acknowledgment 267 Funding for the RFC Editor function is currently provided by the 268 Internet Society.