idnits 2.17.1 draft-ietf-sipping-uri-services-07.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 478. 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 == Line 351 has weird spacing: '...nt-list the...' -- 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 (November 13, 2007) is 5999 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. 'I-D.ietf-sipping-consent-framework') == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-conferencing-01 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-subscribe-01 == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-01 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-capacity-attribute-04 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Intended status: Standards Track A. Roach 5 Expires: May 16, 2008 Estacado Systems 6 November 13, 2007 8 Framework and Security Considerations for Session Initiation Protocol 9 (SIP) Uniform Resource Identifier (URI)-List Services 10 draft-ietf-sipping-uri-services-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 16, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes the need for SIP URI-list services and 44 provides requirements for their invocation. Additionaly, it defines 45 a framework for SIP URI-List services, which includes security 46 considerations applicable to these services. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Requirements for URI-List Services Using 54 Request-Contained Lists . . . . . . . . . . . . . . . . . 4 55 3.2. General Requirements for URI-List Services . . . . . . . . 4 56 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Carrying URI Lists in SIP . . . . . . . . . . . . . . . . 4 58 4.2. Processing of URI Lists . . . . . . . . . . . . . . . . . 5 59 4.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 5.1. List Integrity and Confidentiality . . . . . . . . . . . . 6 62 5.2. Amplification Attacks . . . . . . . . . . . . . . . . . . 6 63 5.3. General Issues . . . . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 70 Intellectual Property and Copyright Statements . . . . . . . . . . 11 72 1. Introduction 74 Some applications require that, at a given moment, a SIP [RFC3261] UA 75 (User Agent) performs a similar transaction with a number of remote 76 UAs. For example, an instant messaging application that needs to 77 send a particular message (e.g., "Hello folks") to n receivers needs 78 to send n MESSAGE requests; one to each receiver. 80 When the transacton that needs to be repeated consists of a large 81 request, the number of recipients is high, or both, the access 82 network of the UA needs to carry a considerable amount of traffic. 83 Completing all the transactions on a low-bandwidth access would 84 require a long time. This is unacceptable for a number of 85 applications. 87 A solution to this problem consists of introducing URI-list services 88 in the network. The task of a SIP URI-list service is to receive a 89 request that contains or references a URI list (i.e., a list of one 90 or more URIs) and send a number of similar requests to the 91 destinations in this list. Once the requests are sent, the URI-list 92 service typically informs the UA about their status. Effectively, 93 the URI-list service behaves as a B2BUA (Back-To-Back-User-Agent). 95 A given URI-list service can take as an input a URI-list contained in 96 the SIP request sent by the client or an external URI list (e.g., the 97 Request-URI is a SIP URI which is associated with a URI list at the 98 server). External URI lists are typically set up using out-of-band 99 mechanisms (e.g., XCAP [RFC4825]). An example of a URI-list service 100 for SUBSCRIBE requests that uses stored URI lists is described in 101 [RFC4662]. 103 The remainder of this document provides requirements and a framework 104 for URI-list services using request-contained URI lists, external URI 105 lists, or both. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Requirements 115 Section 3.1 discusses requirements that only apply to URI-list 116 services that use request-contained lists and Section 3.2 discusses 117 requirements that also apply services using external lists. 119 3.1. Requirements for URI-List Services Using Request-Contained Lists 121 REQ 1: The URI-list service invocation mechanism MUST allow the 122 invoker to provide a list of destination URIs to the URI-list 123 service. 125 REQ 2: The invocation mechanism SHOULD NOT require more than one RTT 126 (Round-Trip Time). 128 3.2. General Requirements for URI-List Services 130 GEN 1: A URI-list service MAY include services beyond sending 131 requests to the URIs in the URI list. That is, URI-list services 132 can be modelled as application servers. For example, a URI-list 133 service handling INVITE requests may behave as a conference server 134 and perform media mixing for all the participants. 136 GEN 2: The interpretation of the meaning of the URI list sent by the 137 invoker MUST be at the discretion of the application to which the 138 list is sent. 140 GEN 3: It MUST be possible for the invoker to find out about the 141 result of the operations performed by the URI-list service with 142 the URI list. An invoker may, for instance, be interested in the 143 status of the transactions initiated by the URI-list service. 145 GEN 4: URI-list services MUST NOT send requests to any destination 146 without authenticating the invoker. 148 4. Framework 150 This framework is not restricted to application servers that only 151 provide request fan-out services. Per GEN 1, this framework also 152 deals with application servers that provide a particular service that 153 includes a request fan-out (e.g., a conference server that INVITEs 154 several participants which are chosen by a user agent). 156 4.1. Carrying URI Lists in SIP 158 The requirements related to URI-list services that use request- 159 contained lists identify the need for a mechanism to provide a SIP 160 URI-list service with a URI list in a single RTT. We define a new 161 disposition type [RFC2183] for the Content-Disposition header field: 162 recipient-list. Both requests and responses MAY carry recipient-list 163 bodies. Bodies whose disposition type is recipient-list carry a list 164 of URIs that contains the final recipients of the requests to be 165 generated by a URI-list service. 167 The default format for recipient-list bodies is service specific. 168 So, URI-list services specifications MUST specify a default format 169 for recipient-list bodies used within a particular service. In any 170 case, clients SHOULD NOT include any particular URI more than once in 171 a given URI list. 173 A UA server receiving a request with more than one recipient-list 174 body parts (e.g., each body part using a different URI-list format) 175 MUST behave as if it had received a single URI-list which contains 176 all the URIs present in the different body parts. 178 A UA server receiving a recipient-list URI list which contains a URI 179 more than once MUST behave as if that URI appeared in the URI list 180 only once. The UA server uses the comparison rules specific to the 181 URI scheme of each of the URIs in the URI list to determine if there 182 is any URI which appears more than once. Additionally, Section 4 of 183 the XML Format Extension for Representing Copy Control Attributes in 184 Resource Lists [I-D.ietf-sipping-capacity-attribute] discusses cases 185 where duplicated URI entries are tagged with different values of the 186 'copyControl' attribute. Naturally, URI-list services using the 187 'copyControl' attribute defined in 188 [I-D.ietf-sipping-capacity-attribute] need to follow the 189 recommendations in [I-D.ietf-sipping-capacity-attribute] with respect 190 to avoiding sending duplicated requests. 192 The way a UA server receiving a URI list interprets it is service 193 specific, as described in Section 4.2. 195 4.2. Processing of URI Lists 197 According to GEN 1 and GEN 2, URI-list services can behave as 198 application servers. That is, taking a URI list as an input, they 199 can provide arbitrary services. So, the interpretation of the URI 200 list by the server depends on the service to be provided. For 201 example, for a conference server, the URIs in the list may identify 202 the initial set of participants. On the other hand, for a server 203 dealing with MESSAGEs, the URIs in the list may identify the 204 recipients of an instant message. 206 At the SIP level, this implies that the behavior of application 207 servers receiving requests with URI-lists SHOULD be specified on a 208 per service basis. Examples of such specifications are 209 [I-D.ietf-sip-uri-list-conferencing] for INVITE, 210 [I-D.ietf-sip-uri-list-message] for MESSAGE, and 211 [I-D.ietf-sip-uri-list-subscribe] for SUBSCRIBE. 213 4.3. Results 215 According to GEN 3, user agents should have a way to obtain 216 information about the operations performed by the application server. 217 Since these operations are service specific, the way user agents are 218 kept informed is also service specific. For example, a user agent 219 establishing an adhoc conference with an INVITE with a URI-list may 220 discover which participants were successfully brought in into the 221 conference by using the conference package [RFC4575]. 223 5. Security Considerations 225 Security plays an important role in the implementation of any URI- 226 list service. In fact, it is the most important common area across 227 all types of URI-list services. 229 By definition, a URI-list service takes one request in and sends a 230 potentially large number of them out. Attackers may attempt to use 231 URI-list services as traffic amplifiers to launch DoS (Denial of 232 Service) attacks. This section provides guidelines to avoid these 233 attacks. 235 5.1. List Integrity and Confidentiality 237 Attackers may attempt to modify URI lists sent from clients to 238 servers. This would cause a different behavior at the server than 239 expected by the client (e.g., requests being sent to different 240 recipients as the ones specified by the client). To prevent this 241 attack, clients SHOULD integrity protect URI lists using mechanisms 242 such as S/MIME, which can also provide URI-list confidentiality if 243 needed. 245 5.2. Amplification Attacks 247 URI-list services take a request in and send a potentially large 248 number of them out. Given that URI-list services are typically 249 implemented on top of powerful servers with high-bandwidth access 250 links, we should be careful to keep attackers from using them as 251 amplification tools to launch DoS (Denial of Service) attacks. 253 Attackers may attempt to send a URI list containing URIs whose host 254 parts route to the victims of the DoS attack. These victims do not 255 need to be SIP nodes; they can be non-SIP endpoints or even routers. 256 If this attack is successful, the result is that an attacker can 257 flood with traffic a set of nodes, or a single node, without needing 258 to generate a high volume of traffic itself. 260 Note, in any case, that this problem is not specific to SIP URI- 261 list services; it also appears in scenarios which relate to 262 multihoming where a server needs to contact a set of IP addresses 263 provided by a client. 265 There are several measures that need to be taken to prevent this type 266 of attack. The first one is keeping unauthorized users from using 267 URI-list services. So, URI-list services MUST NOT perform any 268 request explosion for an unauthorized user. URI-list services MUST 269 authenticate users and check whether they are authorized to request 270 the service before performing any request fan-out. 272 Note that the risk of this attack also exists when a client uses 273 stored URI lists. Application servers MUST use authentication and 274 authorization mechanisms with equivalent security properties when 275 dealing with stored and request-contained URI lists. 277 Even though the previous rule keeps unauthorized users from using 278 URI-list services, authorized users may still launch attacks using a 279 these services. To prevent these attacks, we introduce the concept 280 of opt-in lists. That is, URI-list services should not allow a 281 client to place a user (identified by his or her URI) in a URI list 282 unless the user has previously agreed to be placed in such a URI 283 list. So, URI-list services MUST NOT send a request to a destination 284 which has not agreed to receive requests from the URI-list service 285 beforehand. Users can agree to receive requests from a URI-list 286 service in several ways, such as filling a web page, sending an 287 email, signing a contract, or using the Framework for Consent-Based 288 Communications in SIP [I-D.ietf-sipping-consent-framework], whose 289 requirements are discussed in [RFC4453]. Additionally, users MUST be 290 able to further describe the requests they are willing to receive. 291 For example, a user may only want to receive requests from a 292 particular URI-list service on behalf of a particular user. 293 Effectively, these rules make URI lists used by URI-list services 294 opt-in lists. 296 When a URI-list service receives a request with a URI list from a 297 client, the URI-list service checks whether all the destinations have 298 agreed beforehand to receive requests from the service on behalf of 299 this client. If the URI list has permission to send requests to all 300 of the targets in the request, it does so. If not, it does not send 301 any request at all. 303 The Framework for Consent-Based Communications in SIP 304 [I-D.ietf-sipping-consent-framework] specifies a means for the URI- 305 list service to inform the client that some permissions were missing 306 and how to request them. 308 Note that the mechanism used to obtain permissions should not 309 create opportunities to launch DoS amplification attacks. These 310 attacks would be possible if, for instance, the URI-list service 311 automatically contacted the full set of targets for which it did 312 not have permissions in order to request permissions. The URI- 313 list service would be receiving one SIP request and sending out a 314 number of authorization request messages. The Framework for 315 Consent-Based Communications in SIP 316 [I-D.ietf-sipping-consent-framework] avoids this type of attack by 317 having the client generate roughly the same amount of traffic 318 towards the URI-list service as the service generates towards the 319 destinations. 321 In order to have an interoperable way to meet the requirements 322 related to opt-in lists described in this section, URI-list services 323 MUST implement, and SHOULD use, The Framework for Consent-Based 324 Communications in SIP [I-D.ietf-sipping-consent-framework]. 326 5.3. General Issues 328 URI-list services MAY have policies that limit the number of URIs in 329 the lists they accept, as a very long list could be used in a denial 330 of service attack to place a large burden on the URI-list service to 331 send a large number of SIP requests. 333 A URI-list service generates a set of requests from a URI list. 334 Section 19.1.5 of [RFC3261] provides recommendations that need to be 335 taken into consideration when forming a request from a URI. 336 Naturally, those recommendations apply to all SIP URI-list services. 338 The general requirement GEN 4, which states that URI-list services 339 need to authenticate their clients, and the previous rules apply to 340 URI-list services in general. In addition, specifications dealing 341 with individual methods MUST describe the security issues that relate 342 to each particular method. 344 6. IANA Considerations 346 This document defines a new Content-Disposition header field 347 disposition type (recipient-list) in Section 4.1. This value should 348 be registered in the IANA registry for Mail Content Disposition 349 Values and Parameters with the following description: 351 recipient-list the body contains a list of URIs 353 7. Acknowledges 355 Duncan Mills and Miguel A. Garcia-Martin supported the idea of 1 to n 356 MESSAGE requests. Jon Peterson, Dean Willis, and Jonathan Rosenberg 357 provided useful comments. 359 8. References 361 8.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, March 1997. 366 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 367 Presentation Information in Internet Messages: The 368 Content-Disposition Header Field", RFC 2183, August 1997. 370 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 371 A., Peterson, J., Sparks, R., Handley, M., and E. 372 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 373 June 2002. 375 [I-D.ietf-sipping-consent-framework] 376 Rosenberg, J., "A Framework for Consent-Based 377 Communications in the Session Initiation Protocol (SIP)", 378 draft-ietf-sipping-consent-framework-05 (work in 379 progress), June 2006. 381 8.2. Informative References 383 [RFC4453] Rosenberg, J., Camarillo, G., and D. Willis, "Requirements 384 for Consent-Based Communications in the Session Initiation 385 Protocol (SIP)", RFC 4453, April 2006. 387 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 388 Initiation Protocol (SIP) Event Package for Conference 389 State", RFC 4575, August 2006. 391 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 392 Initiation Protocol (SIP) Event Notification Extension for 393 Resource Lists", RFC 4662, August 2006. 395 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 396 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 398 [I-D.ietf-sip-uri-list-conferencing] 399 Camarillo, G. and A. Johnston, "Conference Establishment 400 Using Request-Contained Lists in the Session Initiation 401 Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-01 402 (work in progress), January 2007. 404 [I-D.ietf-sip-uri-list-subscribe] 405 Camarillo, G., "Subscriptions to Request-Contained 406 Resource Lists in the Session Initiation Protocol (SIP)", 407 draft-ietf-sip-uri-list-subscribe-01 (work in progress), 408 January 2007. 410 [I-D.ietf-sip-uri-list-message] 411 Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 412 MESSAGE Requests in the Session Initiation Protocol 413 (SIP)", draft-ietf-sip-uri-list-message-01 (work in 414 progress), January 2007. 416 [I-D.ietf-sipping-capacity-attribute] 417 Garcia-Martin, M. and G. Camarillo, "Extensible Markup 418 Language (XML) Format Extension for Representing Copy 419 Control Attributes in Resource Lists", 420 draft-ietf-sipping-capacity-attribute-04 (work in 421 progress), March 2007. 423 Authors' Addresses 425 Gonzalo Camarillo 426 Ericsson 427 Hirsalantie 11 428 Jorvas 02420 429 Finland 431 Email: Gonzalo.Camarillo@ericsson.com 433 Adam Roach 434 Estacado Systems 435 Dallas, TX 436 US 438 Email: adam@estacado.net 440 Full Copyright Statement 442 Copyright (C) The IETF Trust (2007). 444 This document is subject to the rights, licenses and restrictions 445 contained in BCP 78, and except as set forth therein, the authors 446 retain all their rights. 448 This document and the information contained herein are provided on an 449 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 450 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 451 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 452 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 453 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 454 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 456 Intellectual Property 458 The IETF takes no position regarding the validity or scope of any 459 Intellectual Property Rights or other rights that might be claimed to 460 pertain to the implementation or use of the technology described in 461 this document or the extent to which any license under such rights 462 might or might not be available; nor does it represent that it has 463 made any independent effort to identify any such rights. Information 464 on the procedures with respect to rights in RFC documents can be 465 found in BCP 78 and BCP 79. 467 Copies of IPR disclosures made to the IETF Secretariat and any 468 assurances of licenses to be made available, or the result of an 469 attempt made to obtain a general license or permission for the use of 470 such proprietary rights by implementers or users of this 471 specification can be obtained from the IETF on-line IPR repository at 472 http://www.ietf.org/ipr. 474 The IETF invites any interested party to bring to its attention any 475 copyrights, patents or patent applications, or other proprietary 476 rights that may cover technology that may be required to implement 477 this standard. Please address the information to the IETF at 478 ietf-ipr@ietf.org. 480 Acknowledgment 482 Funding for the RFC Editor function is provided by the IETF 483 Administrative Support Activity (IASA).