idnits 2.17.1 draft-ietf-sipping-uri-services-06.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 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 339 has weird spacing: '...nt-list the...' == 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 (September 17, 2006) is 6430 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) ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-consent-framework (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '5') (Obsoleted by RFC 4960) == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-11 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-conferencing-00 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-subscribe-00 == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-00 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: March 21, 2007 A. Roach 4 Estacado Systems 5 September 17, 2006 7 Framework and Security Considerations for Session Initiation Protocol 8 (SIP) Uniform Resource Identifier (URI)-List Services 9 draft-ietf-sipping-uri-services-06.txt 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 March 21, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes the need for SIP URI-list services and 43 provides requirements for their invocation. Additionaly, it defines 44 a framework for SIP URI-List services, which includes security 45 considerations applicable to these services. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Requirements for URI-List Services Using 53 Request-Contained Lists . . . . . . . . . . . . . . . . . 4 54 3.2. General Requirements for URI-List Services . . . . . . . . 4 55 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Carrying URI-Lists in SIP . . . . . . . . . . . . . . . . 4 57 4.2. Processing of URI-Lists . . . . . . . . . . . . . . . . . 5 58 4.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 5.1. List Integrity and Confidentiality . . . . . . . . . . . . 6 61 5.2. Amplification Attacks . . . . . . . . . . . . . . . . . . 6 62 5.3. General Issues . . . . . . . . . . . . . . . . . . . . . . 8 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 7. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 69 Intellectual Property and Copyright Statements . . . . . . . . . . 12 71 1. Introduction 73 Some applications require that, at a given moment, a SIP [3] UA (User 74 Agent) performs a similar transaction with a number of remote UAs. 75 For example, an instant messaging application that needs to send a 76 particular message (e.g., "Hello folks") to n receivers needs to send 77 n MESSAGE requests; one to each receiver. 79 When the transacton that needs to be repeated consists of a large 80 request, the number of recipients is high, or both, the access 81 network of the UA needs to carry a considerable amount of traffic. 82 Completing all the transactions on a low-bandwidth access would 83 require a long time. This is unacceptable for a number of 84 applications. 86 A solution to this problem consists of introducing URI-list services 87 in the network. The task of a SIP URI-list service is to receive a 88 request that contains or references a URI-list (i.e., a list of one 89 or more URIs) and send a number of similar requests to the 90 destinations in this list. Once the requests are sent, the URI-list 91 service typically informs the UA about their status. Effectively, 92 the URI-list service behaves as a B2BUA (Back-To-Back-User-Agent). 94 A given URI-list service can take as an input a URI-list contained in 95 the SIP request sent by the client or an external URI-list (e.g., the 96 Request-URI is a SIP URI which is associated with a URI-list at the 97 server). External URI-lists are typically set up using out-of-band 98 mechanisms (e.g., XCAP [10]). An example of a URI-list service for 99 SUBSCRIBE requests that uses stored URI-lists is described in [8]. 101 The Advanced Instant Messaging Requirements for SIP [9] mentions the 102 need for request-contained URI-list services for MESSAGE 103 transactions: 105 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 106 group, where the identities of the recipients are carried in the 107 message itself." 109 The remainder of this document provides requirements and a framework 110 for URI-list services using request-contained URI-lists, external 111 URI-lists, or both. 113 2. Terminology 115 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 116 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 117 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 118 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 119 compliant implementations. 121 3. Requirements 123 Section 3.1 discusses requirements that only apply to URI-list 124 services that use request-contained lists and Section 3.2 discusses 125 requirements that also apply services using external lists. 127 3.1. Requirements for URI-List Services Using Request-Contained Lists 129 REQ 1: The URI-list service invocation mechanism MUST allow the 130 invoker to provide a list of destination URIs to the URI-list 131 service. 132 REQ 2: The invocation mechanism SHOULD NOT require more than one RTT 133 (Round-Trip Time). 135 3.2. General Requirements for URI-List Services 137 GEN 1: A URI-list service MAY include services beyond sending 138 requests to the URIs in the URI-list. That is, URI-list services 139 can be modelled as application servers. For example, a URI-list 140 service handling INVITE requests may behave as a conference server 141 and perform media mixing for all the participants. 142 GEN 2: The interpretation of the meaning of the URI-list sent by the 143 invoker MUST be at the discretion of the application to which the 144 list is sent. 145 GEN 3: It MUST be possible for the invoker to find out about the 146 result of the operations performed by the URI-list service with 147 the URI-list. An invoker may, for instance, be interested in the 148 status of the transactions initiated by the URI-list service. 149 GEN 4: URI-list services MUST NOT send requests to any destination 150 without authenticating the invoker. 152 4. Framework 154 This framework is not restricted to application servers that only 155 provide request fan-out services. Per GEN 1, this framework also 156 deals with application servers that provide a particular service that 157 includes a request fan-out (e.g., a conference server that INVITEs 158 several participants which are chosen by a user agent). 160 4.1. Carrying URI-Lists in SIP 162 The requirements related to URI-list services that use request- 163 contained lists identify the need for a mechanism to provide a SIP 164 URI-list service with a URI-list in a single RTT. We define a new 165 disposition type [2] for the Content-Disposition header field: 166 recipient-list. Both requests and responses MAY carry recipient-list 167 bodies. Bodies whose disposition type is recipient-list carry a list 168 of URIs that contains the final recipients of the requests to be 169 generated by a URI-list service. 171 The default format for recipient-list bodies is service specific. 172 So, URI-list services specifications MUST specify a default format 173 for recipient-list bodies used within a particular service. In any 174 case, clients SHOULD NOT include any particular URI more than once in 175 a given URI-list. 177 A UA server receiving a request with more than one recipient-list 178 body parts (e.g., each body part using a different URI-list format) 179 MUST behave as if it had received a single URI-list which contains 180 all the URIs present in the different body parts. 182 A UA server receiving a recipient-list URI-list which contains a URI 183 more than once MUST behave as if that URI appeared in the URI-list 184 only once. The UA server uses the comparison rules specific to the 185 URI scheme of each of the URIs in the URI-list to determine if there 186 is any URI which appears more than once. 188 The way a UA server receiving a URI-list interprets it is service 189 specific, as described in Section 4.2. 191 4.2. Processing of URI-Lists 193 According to GEN 1 and GEN 2, URI-list services can behave as 194 application servers. That is, taking a URI-list as an input, they 195 can provide arbitrary services. So, the interpretation of the URI- 196 list by the server depends on the service to be provided. For 197 example, for a conference server, the URIs in the list may identify 198 the initial set of participants. On the other hand, for a server 199 dealing with MESSAGEs, the URIs in the list may identify the 200 recipients of an instant message. 202 At the SIP level, this implies that the behavior of application 203 servers receiving requests with URI-lists SHOULD be specified on a 204 per service basis. Examples of such specifications are [11] for 205 INVITE, [13] for MESSAGE, and [12] for SUBSCRIBE. 207 4.3. Results 209 According to GEN 3, user agents should have a way to obtain 210 information about the operations performed by the application server. 211 Since these operations are service specific, the way user agents are 212 kept informed is also service specific. For example, a user agent 213 establishing an adhoc conference with an INVITE with a URI-list may 214 discover which participants were successfully brought in into the 215 conference by using the conference package [7]. 217 5. Security Considerations 219 Security plays an important role in the implementation of any URI- 220 list service. In fact, it is the most important common area across 221 all types of URI-list services. 223 By definition, a URI-list service takes one request in and sends a 224 potentially large number of them out. Attackers may attempt to use 225 URI-list services as traffic amplifiers to launch DoS (Denial of 226 Service) attacks. This section provides guidelines to avoid these 227 attacks. 229 5.1. List Integrity and Confidentiality 231 Attackers may attempt to modify URI-lists sent from clients to 232 servers. This would cause a different behavior at the server than 233 expected by the client (e.g., requests being sent to different 234 recipients as the ones specified by the client). To prevent this 235 attack, clients SHOULD integrity protect URI-lists using mechanisms 236 such as S/MIME, which can also provide URI-list confidentiality if 237 needed. 239 5.2. Amplification Attacks 241 URI-list services take a request in and send a potentially large 242 number of them out. Given that URI-list services are typically 243 implemented on top of powerful servers with high-bandwidth access 244 links, we should be careful to keep attackers from using them as 245 amplification tools to launch DoS (Denial of Service) attacks. 247 Attackers may attempt to send a URI-list containing URIs whose host 248 parts route to the victims of the DoS attack. These victims do not 249 need to be SIP nodes; they can be non-SIP endpoints or even routers. 250 If this attack is successful, the result is that an attacker can 251 flood with traffic a set of nodes, or a single node, without needing 252 to generate a high volume of traffic itself. 254 Note, in any case, that this problem is not specific to SIP URI- 255 list services; it also appears in scenarios which relate to 256 multihoming where a server needs to contact a set of IP addresses 257 provided by a client (e.g., an SCTP [5] endpoint using HEARTBEATs 258 to check the status of the IP addresses provided by its peer at 259 association establishment). 261 There are several measures that need to be taken to prevent this type 262 of attack. The first one is keeping unauthorized users from using 263 URI-list services. So, URI-list services MUST NOT perform any 264 request explosion for an unauthorized user. URI-list services MUST 265 authenticate users and check whether they are authorized to request 266 the service before performing any request fan-out. 268 Note that the risk of this attack also exists when a client uses 269 stored URI-lists. Application servers MUST use authentication and 270 authorization mechanisms with equivalent security properties when 271 dealing with stored and request-contained URI-lists. 273 Even though the previous rule keeps unauthorized users from using 274 URI-list services, authorized users may still launch attacks using a 275 these services. To prevent these attacks, we introduce the concept 276 of opt-in lists. That is, URI-list services should not allow a 277 client to place a user (identified by his or her URI) in a URI-list 278 unless the user has previously agreed to be placed in such a URI- 279 list. So, URI-list services MUST NOT send a request to a destination 280 which has not agreed to receive requests from the URI-list service 281 beforehand. Users can agree to receive requests from a URI-list 282 service in several ways, such as filling a web page, sending an 283 email, signing a contract, or using the Framework for Consent-Based 284 Communications in SIP [4], whose requirements are discussed in [6]. 285 Additionally, users MUST be able to further describe the requests 286 they are willing to receive. For example, a user may only want to 287 receive requests from a particular URI-list service on behalf of a 288 particular user. Effectively, these rules make URI-lists used by 289 URI-list services opt-in lists. 291 When a URI-list service receives a request with a URI-list from a 292 client, the URI-list service checks whether all the destinations have 293 agreed beforehand to receive requests from the service on behalf of 294 this client. If the URI-list has permission to send requests to all 295 of the targets in the request, it does so. If not, it does not send 296 any request at all. 298 The Framework for Consent-Based Communications in SIP [4] specifies a 299 means for the URI-list service to inform the client that some 300 permissions were missing and how to request them. 302 Note that the mechanism used to obtain permissions should not 303 create opportunities to launch DoS amplification attacks. These 304 attacks would be possible if, for instance, the URI-list service 305 automatically contacted the full set of targets for which it did 306 not have permissions in order to request permissions. The URI- 307 list service would be receiving one SIP request and sending out a 308 number of authorization request messages. The Framework for 309 Consent-Based Communications in SIP [4] avoids this type of attack 310 by having the client generate roughly the same amount of traffic 311 towards the URI-list service as the service generates towards the 312 destinations. 314 In order to have an interoperable way to meet the requirements 315 related to opt-in lists described in this section, URI-list services 316 MUST implement, and SHOULD use, The Framework for Consent-Based 317 Communications in SIP [4]. 319 5.3. General Issues 321 URI-list services MAY have policies that limit the number of URIs in 322 the lists they accept, as a very long list could be used in a denial 323 of service attack to place a large burden on the URI-list service to 324 send a large number of SIP requests. 326 The general requirement GEN 4, which states that URI-list services 327 need to authenticate their clients, and the previous rules apply to 328 URI-list services in general. In addition, specifications dealing 329 with individual methods MUST describe the security issues that relate 330 to each particular method. 332 6. IANA Considerations 334 This document defines a new Content-Disposition header field 335 disposition type (recipient-list) in Section 4.1. This value should 336 be registered in the IANA registry for Mail Content Disposition 337 Values and Parameters with the following description: 339 recipient-list the body contains a list of URIs 341 7. Acknowledges 343 Duncan Mills and Miguel A. Garcia-Martin supported the idea of 1 to n 344 MESSAGEs. Jon Peterson, Dean Willis, and Jonathan Rosenberg provided 345 useful comments. 347 8. References 348 8.1. Normative References 350 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 351 Levels", BCP 14, RFC 2119, March 1997. 353 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 354 Presentation Information in Internet Messages: The Content- 355 Disposition Header Field", RFC 2183, August 1997. 357 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 358 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 359 Session Initiation Protocol", RFC 3261, June 2002. 361 [4] Rosenberg, J., "A Framework for Consent-Based Communications in 362 the Session Initiation Protocol (SIP)", 363 draft-ietf-sipping-consent-framework-05 (work in progress), 364 June 2006. 366 8.2. Informative References 368 [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 369 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 370 Paxson, "Stream Control Transmission Protocol", RFC 2960, 371 October 2000. 373 [6] Rosenberg, J., Camarillo, G., and D. Willis, "Requirements for 374 Consent-Based Communications in the Session Initiation Protocol 375 (SIP)", RFC 4453, April 2006. 377 [7] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 378 Initiation Protocol (SIP) Event Package for Conference State", 379 RFC 4575, August 2006. 381 [8] Roach, A., Campbell, B., and J. Rosenberg, "A Session 382 Initiation Protocol (SIP) Event Notification Extension for 383 Resource Lists", RFC 4662, August 2006. 385 [9] Rosenberg, J. and M. Isomaki, "Advanced Instant Messaging 386 Requirements for the Session Initiation Protocol (SIP)", 387 draft-ietf-simple-messaging-requirements-00 (work in progress), 388 June 2006. 390 [10] Rosenberg, J., "The Extensible Markup Language (XML) 391 Configuration Access Protocol (XCAP)", 392 draft-ietf-simple-xcap-11 (work in progress), May 2006. 394 [11] Camarillo, G. and A. Johnston, "Conference Establishment Using 395 Request-Contained Lists in the Session Initiation Protocol 396 (SIP)", draft-ietf-sip-uri-list-conferencing-00 (work in 397 progress), September 2006. 399 [12] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to 400 Request-Contained Resource Lists in the Session Initiation 401 Protocol (SIP)", draft-ietf-sip-uri-list-subscribe-00 (work in 402 progress), September 2006. 404 [13] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 405 Requests in the Session Initiation Protocol (SIP)", 406 draft-ietf-sip-uri-list-message-00 (work in progress), 407 September 2006. 409 Authors' Addresses 411 Gonzalo Camarillo 412 Ericsson 413 Hirsalantie 11 414 Jorvas 02420 415 Finland 417 Email: Gonzalo.Camarillo@ericsson.com 419 Adam Roach 420 Estacado Systems 421 Dallas, TX 422 US 424 Email: adam@estacado.net 426 Intellectual Property Statement 428 The IETF takes no position regarding the validity or scope of any 429 Intellectual Property Rights or other rights that might be claimed to 430 pertain to the implementation or use of the technology described in 431 this document or the extent to which any license under such rights 432 might or might not be available; nor does it represent that it has 433 made any independent effort to identify any such rights. Information 434 on the procedures with respect to rights in RFC documents can be 435 found in BCP 78 and BCP 79. 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use of 440 such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository at 442 http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights that may cover technology that may be required to implement 447 this standard. Please address the information to the IETF at 448 ietf-ipr@ietf.org. 450 Disclaimer of Validity 452 This document and the information contained herein are provided on an 453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 455 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 456 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 457 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Copyright Statement 462 Copyright (C) The Internet Society (2006). This document is subject 463 to the rights, licenses and restrictions contained in BCP 78, and 464 except as set forth therein, the authors retain all their rights. 466 Acknowledgment 468 Funding for the RFC Editor function is currently provided by the 469 Internet Society.