idnits 2.17.1 draft-ietf-sip-refer-with-norefersub-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 344. ** 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. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 137 has weird spacing: '... where pro...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (July 17, 2005) is 6852 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 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-04 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP O. Levin 3 Internet-Draft Microsoft Corporation 4 Expires: January 18, 2006 July 17, 2005 6 Suppression of Session Initiation Protocol REFER Method Implicit 7 Subscription 8 draft-ietf-sip-refer-with-norefersub-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 18, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This specification defines a way to suppress an implicit subscription 42 with the Session Initiation Protocol (SIP) REFER method. A new SIP 43 option tag "norefersub" is defined to indicate support for this 44 extension. A new SIP header field "Refer-Sub" is defined to request 45 the usage of this extension. 47 Table of Contents 49 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 5. Preventing Forking of REFER Requests . . . . . . . . . . . . . 5 54 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 10.1 Normative References . . . . . . . . . . . . . . . . . . . 7 60 10.2 Informational References . . . . . . . . . . . . . . . . . 8 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 62 Intellectual Property and Copyright Statements . . . . . . . . 9 64 1. Terminology 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [1]. 70 To simplify discussions of the REFER method and its extensions, the 71 three terms below are being used throughout the document: 72 o REFER-Issuer: the UA issuing the REFER request 73 o REFER-Recipient: the UA receiving the REFER request 74 o REFER-Target: the UA designated in the Refer-To URI 76 2. Introduction 78 The REFER specification specifies that every REFER creates an 79 implicit subscription between the REFER-Issuer and the REFER- 80 Recipient. 82 This document defines a new SIP header field: "Refer-Sub" meaningful 83 within a REFER transaction only. This header field, when set to 84 "false", specifies that a REFER-Issuer requests that the REFER- 85 Recipient doesn't establish an explicit subscription and the 86 resultant dialog. 88 This document defines a new option tag: "norefersub". This tag, when 89 included in the Supported header field, indicates that a User Agent 90 (UA) is capable of accepting a REFER request without creating an 91 implicit subscription when acting as a REFER-Recipient. 93 3. Motivation 95 The REFER specification mandates that every REFER creates an implicit 96 subscription between the REFER-Issuer and the REFER-Recipient. This 97 subscription results in at least one NOTIFY being sent from the 98 REFER-Recipient to the REFER-Issuer. The REFER-Recipient may choose 99 to cancel the implicit subscription with this NOTIFY. The REFER- 100 Issuer may choose to cancel this implicit subscription with an 101 explicit SUBSCRIBE (Expires: 0) after receipt of the initial NOTIFY. 103 One purpose of requiring the implicit subscription and initial NOTIFY 104 is to allow for the situation where the REFER request gets forked and 105 the REFER-Issuer needs a way to see the multiple dialogs that may be 106 established as a result of the forked REFER. This is the same 107 approach used to handle forking of SUBSCRIBE [4] requests. Where the 108 REFER-Issuer explicitly specifies that forking not occur, the 109 requirement that an implicit subscription be established is 110 unnecessary. 112 Another purpose of the NOTIFY is to inform the REFER-Issuer of the 113 progress of the SIP transaction that results from the REFER at the 114 REFER-Recipient. In the case where the REFER-Issuer is already aware 115 of the progress of the requested operation, such as when the REFER- 116 Issuer has an explicit subscription to the dialog event package at 117 the REFER-Recipient, the implicit subscription and resultant NOTIFY 118 traffic related to the REFER can create an unnecessary network 119 overhead. 121 4. Definitions 123 This document defines a new SIP header field: "Refer-Sub". This 124 header field is meaningful and MAY be used with a REFER request and 125 the corresponding 2XX response only. This header field set to 126 "false" specifies that a REFER-Issuer requests that the REFER- 127 Recipient doesn't establish an explicit subscription and the 128 resultant dialog. Note that when using this extension, the REFER 129 remains a target refresh request (as in the default case - when the 130 extension is not used). 132 This document adds the following entry to Table 2 of [2]. The 133 additions to this table are also provided for extension methods at 134 the time of publication of this document. This is provided as a 135 courtesy to the reader and is not normative in any way: 137 Header field where proxy ACK BYE CAN INV OPT REG MSG 139 Refer-Sub R, 2xx - - - - - - - 141 Header field where SUB NOT REF INF UPD PRA PUB 143 Refer-Sub R, 2xx - - o - - - - 145 The Refer-Sub header field MAY be encrypted as part of end-to-end 146 encryption. 148 The syntax of the header field follows the BNF defined below: 150 Refer-Sub = "Refer-Sub" HCOLON refer-sub-value extension-value 151 refer-sub-value = "true" / "false" 152 extension-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 154 The "Refer-Sub" header field set to "false" MAY be used by the REFER- 155 Issuer only when the REFER-Issuer can be certain that the REFER 156 request will not be forked. 158 If the REFER-Recipient supports the extension and is willing to 159 process the REFER transaction without establishing an implicit 160 subscription, it MUST insert the "Refer-Sub" header field set to 161 "false" in the 2xx response to the REFER-Issuer. In this case no 162 implicit subscription is created. Consequently, no new dialog is 163 created if this REFER was issued outside any existing dialog. 165 If the REFER-Issuer inserts the "Refer-Sub" header field set to 166 "false", but the REFER-Recipient doesn't grant the suggestion (i.e. 167 either does not include the "Refer-Sub" header field or includes the 168 "Refer-Sub" header field set to "true" in the 2xx response), an 169 implicit subscription is created as in default case. 171 This document also defines a new option tag, "norefersub". This tag, 172 when included in the Supported header field, specifies that a User 173 Agent (UA) is capable of accepting a REFER request without creating 174 an implicit subscription when acting as a REFER-Recipient. 176 If the capabilities of the REFER-Recipient are not known, using the 177 "norefersub" tag with the Require header field is NOT RECOMMENDED. 178 This is due to the fact that in the event the REFER-Recipient doesn't 179 support the extension, in order to fallback to the normal REFER, the 180 REFER-Issuer will need to issue a new REFER transaction thus 181 resulting in additional round-trips. 183 The "norefersub" tag, when included in the Require header field 184 (always in conjunction with the "Refer-Sub" header field set to 185 "false"), specifies that the REFER-Recipient MUST process a REFER 186 transaction without establishing an explicit subscription. In this 187 case, if the REFER-Recipient either doesn't support the extension or 188 is not willing to grant the request, the REFER request MUST be 189 rejected by sending "420 Bad Extension" response back to the REFER- 190 Issuer. 192 5. Preventing Forking of REFER Requests 194 The REFER specification allows for the possibility of forking a REFER 195 request which is sent outside of an existing dialog. In addition, a 196 proxy may fork an unknown method type. Should forking occur, the 197 sender of the REFER with "Refer-Sub" will not be aware as only a 198 single 2xx response will be forwarded by the forking proxy. As a 199 result, the responsibility is on the issuer of the REFER with "Refer- 200 Sub" to ensure that no forking will result. 202 The best way that the REFER-Issuer can ensure that REFER doesn't get 203 forked is by only sending a REFER with "Refer-Sub" with a Request-URI 204 which has GRUU properties according to definitions of [5]. 206 If this is not known, the other way to ensure that forking will not 207 occur is to ensure that there are no proxies between the REFER-Issuer 208 and the REFER-Recipient. This could be done by sending the REFER 209 with a Max-Forwards: 0 header field. Any proxy receiving this 210 request will return a "483 Too Many Hops" response, indicating that 211 it is not safe to use this extension. 213 6. Example 215 An example of REFER which suppresses the implicit subscription is 216 shown below: 218 REFER sip:pc-b@example.com SIP/2.0 219 Via: SIP/2.0/TCP issuer.example.com;branch=z9hG4bK-a-1 220 From: ;tag=1a 221 To: 222 Call-ID: 1@issuer.example.com 223 CSeq: 234234 REFER 224 Max-Forwards: 70 225 Refer-To: 226 Refer-Sub: false 227 Supported: norefersub 228 Contact: sip:a@issuer.example.com 229 Content-Length: 0 231 7. IANA Considerations 233 This document registers a new SIP header field "Refer-Sub". This 234 header field is only meaningful for the REFER request defined in RFC 235 3515 [3] and the corresponding response. The following information 236 to be added to the header field sub-registry under 237 http://www.iana.org/assignments/sip-parameters: 238 o Header Name: Refer-Sub 239 o Compact Form: None 240 o Reference: [Substitute with this RFC number] 242 This document also registers a new SIP option tag, "norefersub". The 243 required information for this registration, as specified in RFC 3261 244 [2], is: 245 o Name: norefersub 246 o Description: This option tag specifies a User Agent ability of 247 accepting a REFER request without establishing an implicit 248 subscription (compared to the default case defined in RFC 3515 249 [3]). 251 8. Security Considerations 253 The purpose of this SIP extension is to modify the expected behavior 254 of the REFER-Recipient. The change in behavior is for the REFER- 255 Recipient to not establish a dialog and to not send NOTIFY messages 256 back to the REFER-Issuer. As such, a malicious inclusion of a 257 "Refer-Sub" header field set to "false" reduces the processing and 258 state requirements on the recipient. As a result, its use in a 259 denial of service attack seems limited. 261 Should an intermediary maliciously insert a "Refer-Sub" header field 262 set to "false", two possibilities may occur. If the REFER-Recipient 263 does not support the extension, the REFER will fail with a "420 Bad 264 Extension" response. The REFER-Issuer will be confused as no "Refer- 265 Sub" was in the request, and the resulting request will fail. Should 266 the REFER-Recipient support the extension, the 2xx response will 267 contain the "Refer-Sub" header field set to "false". In any case, 268 the REFER-Recipient will not establish a new dialog and send NOTIFYs. 269 As a result the REFER-Recipient will not learn the outcome of the 270 operation on the Refer-To URI. 272 Should an intermediary maliciously remove a "Refer-Sub" header field 273 set to "false", the REFER-Recipient will try to sent notifications 274 over the "explicitly established" dialog. It may confuse the REFER- 275 Issuer, unless the Man in the Middle (MitM) has the motivation and 276 the ability to intercept the notifications. 278 To protect against these kinds of MitM attacks, integrity protection 279 should be used. For example, the REFER-Issuer could use S/MIME as 280 discussed in RFC 3261 [2] to protect against these kinds of attacks. 282 9. Acknowledgements 284 The SIP community would like to thank Sriram Parameswar for his ideas 285 being originally presented in draft-parameswar-sipping-norefersub-00 286 and served as the basis for this specification. 288 10. References 290 10.1 Normative References 292 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 293 Levels", BCP 14, RFC 2119, March 1997. 295 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 296 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 297 Session Initiation Protocol", RFC 3261, June 2002. 299 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 300 Method", RFC 3515, April 2003. 302 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 303 Notification", RFC 3265, June 2002. 305 10.2 Informational References 307 [5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 308 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 309 draft-ietf-sip-gruu-04 (work in progress), July 2005. 311 Author's Address 313 Orit Levin 314 Microsoft Corporation 315 One Microsoft Way 316 Redmond, WA 98052 317 USA 319 Phone: 425-722-2225 320 Email: oritl@microsoft.com 322 Intellectual Property Statement 324 The IETF takes no position regarding the validity or scope of any 325 Intellectual Property Rights or other rights that might be claimed to 326 pertain to the implementation or use of the technology described in 327 this document or the extent to which any license under such rights 328 might or might not be available; nor does it represent that it has 329 made any independent effort to identify any such rights. Information 330 on the procedures with respect to rights in RFC documents can be 331 found in BCP 78 and BCP 79. 333 Copies of IPR disclosures made to the IETF Secretariat and any 334 assurances of licenses to be made available, or the result of an 335 attempt made to obtain a general license or permission for the use of 336 such proprietary rights by implementers or users of this 337 specification can be obtained from the IETF on-line IPR repository at 338 http://www.ietf.org/ipr. 340 The IETF invites any interested party to bring to its attention any 341 copyrights, patents or patent applications, or other proprietary 342 rights that may cover technology that may be required to implement 343 this standard. Please address the information to the IETF at 344 ietf-ipr@ietf.org. 346 Disclaimer of Validity 348 This document and the information contained herein are provided on an 349 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 350 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 351 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 352 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 353 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 354 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 356 Copyright Statement 358 Copyright (C) The Internet Society (2005). This document is subject 359 to the rights, licenses and restrictions contained in BCP 78, and 360 except as set forth therein, the authors retain all their rights. 362 Acknowledgment 364 Funding for the RFC Editor function is currently provided by the 365 Internet Society.