idnits 2.17.1 draft-ietf-sipping-uri-services-01.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 466. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 349 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 2004) is 7157 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) == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-05 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-02 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-05 == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-03 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-uri-list-conferencing-00 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-multiple-refer-00 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-uri-list-message-00 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-uri-list-subscribe-00 == Outdated reference: A later version (-01) exists of draft-rosenberg-sipping-spam-00 Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 7 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 2, 2005 A. Roach 4 Estacado Systems 5 September 2004 7 Framework and Security Considerations for Session Initiation Protocol 8 (SIP) Uniform Resource Identifier (URI)-List Services 9 draft-ietf-sipping-uri-services-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 2, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document describes the need for SIP URI-list services and 45 provides requirements for their invocation. Additionaly, it defines 46 a framework for SIP URI-List services which includes security 47 considerations applicable to these services. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1 Requirements for URI-List Services Using 55 Request-Contained Lists . . . . . . . . . . . . . . . . . 4 56 3.2 General Requirements for URI-List Services . . . . . . . . 4 57 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1 Carrying URI-Lists in SIP . . . . . . . . . . . . . . . . 4 59 4.2 Processing of URI-Lists . . . . . . . . . . . . . . . . . 5 60 4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5.1 List Integrity and Confidentiality . . . . . . . . . . . . 6 63 5.2 Amplification Attacks . . . . . . . . . . . . . . . . . . 6 64 5.3 Unsolicited Requests . . . . . . . . . . . . . . . . . . . 8 65 5.4 General Issues . . . . . . . . . . . . . . . . . . . . . . 8 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 7. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 70 8.2 Informational References . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 72 Intellectual Property and Copyright Statements . . . . . . . . 11 74 1. Introduction 76 Some applications require that, at a given moment, a SIP [2] UA (User 77 Agent) performs a similar transaction with a number of remote UAs. 78 For example, an instant messaging application that needs to send a 79 particular message (e.g., "Hello folks") to n receivers needs to send 80 n MESSAGE requests; one to each receiver. 82 When the transacton that needs to be repeated consists of a large 83 request, or the number of recipients is high, or both, the access 84 network of the UA needs to carry a considerable amount of traffic. 85 Completing all the transactions on a low-bandwidth access would 86 require a long time. This is unacceptable for a number of 87 applications. 89 A solution to this problem consists of introducing URI-list services 90 in the network. The task of a SIP URI-list service is to receive a 91 request that contains or references a URI-list (i.e., a list of one 92 or more URIs) and send a number of similar requests to the 93 destinations in this list. Once the requests are sent, the URI-list 94 service typically informs the UA about their status. Effectively, 95 the URI-list service behaves as a B2BUA (Back-To-Back-User-Agent). 97 A given URI-list service can take as an input a URI-list contained in 98 the SIP request sent by the client or an external URI-list (e.g., the 99 Request-URI is a SIP URI which is associated with a URI-list at the 100 server). External URI-lists are typically set up using out-of-band 101 mechanisms (e.g., XCAP [8]). An example of a URI-list service for 102 SUBSCRIBE requests that uses stored URI-lists is described in [4]. 104 The Advanced Instant Messaging Requirements for SIP [5] mentions the 105 need for request-contained URI-list services for MESSAGE 106 transactions: 108 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 109 group, where the identities of the recipients are carried in the 110 message itself." 112 The remainder of this document provides requirements for URI-list 113 services using request-contained URI-lists, external URI-lists, or 114 both. 116 2. Terminology 118 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 119 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 120 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 121 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 122 compliant implementations. 124 3. Requirements 126 Section 3.1 discusses requirements that only apply to URI-list 127 services that use request-contained lists and Section 3.2 discusses 128 requirements that also apply services using external lists. 130 3.1 Requirements for URI-List Services Using Request-Contained Lists 132 REQ 1: The URI-list service invocation mechanism MUST allow the 133 invoker to provide a list of destination URIs to the URI-list 134 service. 135 REQ 2: The invocation mechanism SHOULD NOT require more than one RTT 136 (Round-Trip Time). 138 3.2 General Requirements for URI-List Services 140 GEN 1: A URI-list service MAY include services beyond sending 141 requests to the URIs in the URI-list. That is, URI-list services 142 can be modelled as application servers. For example, a URI-list 143 service handling INVITE requests may behave as a conference server 144 and perform media mixing for all the participants. 145 GEN 2: The interpretation of the meaning of the URI-list sent by the 146 invoker MUST be at the discretion of the application to which the 147 list is sent. 148 GEN 3: It MUST be possible for the invoker to find out about the 149 result of the operations performed by the URI-list service with 150 the URI-list. An invoker may, for instance, be interested in the 151 status of the transactions initiated by the URI-list service. 152 GEN 4: URI-list services MUST NOT send requests to any destination 153 without authenticating the invoker. 155 4. Framework 157 This framework is not restricted to application servers that only 158 provide request fan-out services. Per GEN 1, this framework also 159 deals with application servers that provide a particular service that 160 includes a request fan-out (e.g., a conference server that INVITEs 161 several participants which are chosen by a user agent). 163 4.1 Carrying URI-Lists in SIP 165 The requirements that relate to URI-list services that use 166 request-contained lists identify the need for a mechanism to provide 167 a SIP URI-list service with a URI-list in a single RTT. We define a 168 new disposition type for the Content-Disposition header field: 169 recipient-list. Both requests and responses MAY carry recipient-list 170 bodies. Bodies whose disposition type is recipient-list carry a list 171 of URIs that contains the final recipients of the requests to be 172 generated by a URI-list service. 174 The default format for recipient-list bodies is service specific. 175 So, URI-list services specifications MUST specify a default format 176 for recipient-list bodies used within a particular service. 178 A UA server receiving a request with more than one recipient-list 179 body parts (e.g., each body part using a different URI-list format) 180 MUST behave as if it had received a single URI-list which contains 181 all the URIs present in the different body parts. 183 The way a UA server receiving a URI-list interprets it is service 184 specific, as described in Section 4.2. 186 4.2 Processing of URI-Lists 188 According to GEN 1 and GEN 2, URI-list services can behave as 189 application servers. That is, taking a URI-list as an input, they 190 can provide arbitrary services. So, the interpretation of the 191 URI-list by the server depends on the service to be provided. For 192 example, for a conference server, the URIs in the list may identify 193 the initial set of participants. On the other hand, for a server 194 dealing with MESSAGEs, the URIs in the list may identify the 195 recipients of an instant message. 197 At the SIP level, this implies that the behavior of application 198 servers receiving requests with URI-lists SHOULD be specified on a 199 per service basis. Examples of such specifications are [9] for 200 INVITE, [10] for REFER, [11] for MESSAGE, and [12] for SUBSCRIBE. 202 4.3 Results 204 According to GEN 3, user agents should have a way to obtain 205 information about the operations performed by the application server. 206 Since these operations are service specific, the way user agents are 207 kept informed is also service specific. For example, a user agent 208 establishing an adhoc conference with an INVITE with a URI-list may 209 discover which participants were successfully brought in into the 210 conference by using the conference package [7]. 212 5. Security Considerations 214 Security plays an important role in the implementation of any 215 URI-list service. In fact, it is the most important common area 216 across all types of URI-list services. 218 By definition, a URI-list service takes one request in and sends a 219 potentially large number of them out. Attackers may attempt to use 220 URI-list services as traffic amplifiers to launch DoS attacks. In 221 addition, malicious users may attempt to use URI-list services to 222 distribute unsolicited messages (i.e., SPAM) or to make unsolicited 223 VoIP calls. This section provides guidelines to avoid these attacks. 225 5.1 List Integrity and Confidentiality 227 Attackers may attempt to modify URI-lists sent from clients to 228 servers. This would cause a different behavior at the server than 229 expected by the client (e.g., requests being sent to different 230 recipients as the ones specified by the client). To prevent this 231 attack, clients SHOULD integrity protect URI-lists using mechanisms 232 such as S/MIME, which can also provide URI-list confidentiality if 233 needed. 235 5.2 Amplification Attacks 237 URI-list services take a request in and send a potentially large 238 number of them out. Given that URI-list services are typically 239 implemented on top of powerful servers with high-bandwidth access 240 links, we should be careful to keep attackers from using them as 241 amplification tools to launch DoS (Denial of Service) attacks. 243 Attackers may attempt to send a URI-list containing URIs whose host 244 parts route to the victims of the DoS attack. These victims do not 245 need to be SIP nodes; they can be non-SIP endpoints or even routers. 246 If this attack is successful, the result is that an attacker can 247 flood with traffic a set of nodes, or a single node, without needing 248 to generate a high volume of traffic itself. 250 Note, in any case, that this problem is not specific to SIP 251 URI-list services; it also appears in scenarios which relate to 252 multihoming where a server needs to contact a set of IP addresses 253 provided by a client (e.g., an SCTP [3] endpoint using HEARTBEATs 254 to check the status of the IP addresses provided by its peer at 255 association establishment). 257 There are several measures that need to be taken to prevent this type 258 of attack. The first one is keeping unauthorized users from using 259 URI-list services. So, URI-list services MUST NOT perform any 260 request explosion for an unauthorized user. URI-list services MUST 261 authenticate users and check whether they are authorized to request 262 the service before performing any request fan-out. 264 Note that the risk of this attack also exists when a client uses 265 stored URI-lists. Application servers MUST use authentication and 266 authorization mechanisms with equivalent security properties when 267 dealing with stored and request-contained URI-lists. 269 Even though the previous rule keeps unauthorized users from using 270 URI-list services, authorized users may still launch attacks using a 271 these services. To prevent these attacks, we introduce the concept 272 of opt-in lists. That is, URI-list services should not allow a 273 client to place a user (identified by his or her URI) in a URI-list 274 unless the user has previously agreed to be placed in such a 275 URI-list. So, URI-list services MUST NOT send a request to a 276 destination which has not agreed to receive requests from the 277 URI-list service beforehand. Users can agree to receive requests 278 from a URI-list service in several ways, such as filling a web page, 279 sending an email, or signing a contract. Additionally, users MUST be 280 able to further describe the requests they are willing to receive. 281 For example, a user may only want to receive requests from a 282 particular URI-list service on behalf of a particular user. 283 Effectively, these rules make URI-lists used by URI-list services 284 opt-in lists. 286 When a URI-list service receives a request with a URI-list from a 287 client, the URI-list service checks whether all the destinations have 288 agreed beforehand to receive requests from the service on behalf of 289 this client. If the URI-list has permission to send requests to all 290 of the targets in the request, it does so. If not, the URI-list 291 service rejects the request, indicating in the rejection the set of 292 targets for which it did not have permission. This allows the client 293 to request permission for those targets. 295 DoS amplification would still happen if the URI-list service 296 automatically contacted the full set of targets for which it did not 297 have permission in order to request permission. The URI-list service 298 would be receiving one SIP request and sending out a number of 299 authorization request messages. In order to avoid this 300 amplification, the URI-list service must ensure that the client 301 generates roughly the same amount of traffic towards the URI-list 302 service as the service generates towards the destinations. 303 Consequently, the URI-list service MUST require that clients send and 304 individual authorization request for each destination. 306 These individual authorization requests sent by the client may or may 307 not be routed through the URI-list service. In any case, the 308 URI-list service MUST be informed about the destinations' responses 309 to these authorization requests in order to authorize requests 310 towards them. One possible mechanism for clients to send 311 authorization requests to the destinations is specified in [13], 312 which discusses consent-based communications in SIP. The 313 requirements for consent-based communications in SIP are discussed in 314 [14]. 316 5.3 Unsolicited Requests 318 Opt-in lists should help fighting SPAMMERS. Still, if a URI-list 319 service is used to send unsolicited requests to one or several 320 destinations, it should be possible to track down the sender of such 321 requests. To do that, URI-list services MAY provide information 322 about the identity of the original sender of the request in their 323 outgoing requests by using the SIP identity mechanism [6]. A 324 detailed study of SPAM in SIP can be found in [15]. 326 5.4 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 The general requirement number 4, which states that URI-list services 334 need to authenticate their clients, and the previous rules apply to 335 URI-list services in general. In addition, specifications dealing 336 with individual methods MUST describe the security issues that relate 337 to each particular method. 339 6. IANA Considerations 341 This document defines a new Content-Disposition header field 342 disposition type (recipient-list) in Section 4.1. This value should 343 be registered in the IANA registry for Content-Dispositions on 345 http://www.iana.org/assignments/mail-cont-disp 347 with the following description: 349 recipient-list the body contains a list of URIs 351 7. Acknowledges 353 Duncan Mills and Miguel A. Garcia-Martin supported the idea of 1 to 354 n MESSAGEs. Jon Peterson, Dean Willis, and Jonathan Rosenberg 355 provided useful comments. 357 8. References 359 8.1 Normative References 361 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 362 Levels", BCP 14, RFC 2119, March 1997. 364 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 365 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 366 Session Initiation Protocol", RFC 3261, June 2002. 368 8.2 Informational References 370 [3] Bradner, S., "A Proposal for an MOU-Based ICANN Protocol 371 Support Organization", RFC 2690, September 1999. 373 [4] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 374 Protocol (SIP) Event Notification Extension for Resource 375 Lists", draft-ietf-simple-event-list-05 (work in progress), 376 August 2004. 378 [5] Rosenberg, J., "Advanced Instant Messaging Requirements for the 379 Session Initiation Protocol (SIP)", 380 draft-rosenberg-simple-messaging-requirements-01 (work in 381 progress), February 2004. 383 [6] Peterson, J., "Enhancements for Authenticated Identity 384 Management in the Session Initiation Protocol (SIP)", 385 draft-ietf-sip-identity-02 (work in progress), May 2004. 387 [7] Rosenberg, J. and H. Schulzrinne, "A Session Initiation 388 Protocol (SIP) Event Package for Conference State", 389 draft-ietf-sipping-conference-package-05 (work in progress), 390 July 2004. 392 [8] Rosenberg, J., "The Extensible Markup Language (XML) 393 Configuration Access Protocol (XCAP)", 394 draft-ietf-simple-xcap-03 (work in progress), July 2004. 396 [9] Camarillo, G. and A. Johnston, "Conference Establishment Using 397 Request-Contained Lists in the Session Initiation Protocol 398 (SIP)", draft-ietf-sipping-uri-list-conferencing-00 (work in 399 progress), July 2004. 401 [10] "Refering to Multiple Resources in the Session Initiation 402 Protocol (SIP)", draft-ietf-sipping-multiple-refer-00 (work in 403 progress), July 2004. 405 [11] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 406 Requests in the Session Initiation Protocol (SIP)", 407 draft-ietf-sipping-uri-list-message-00 (work in progress), July 408 2004. 410 [12] Camarillo, G. and A. Roach, "Subscriptions to Request-Contained 411 Resource Lists in the Session Initiation Protocol (SIP)", 412 draft-ietf-sipping-uri-list-subscribe-00 (work in progress), 413 July 2004. 415 [13] Rosenberg, J., "A Framework for Consent-Based Communications in 416 the Session Initiation Protocol (SIP)", 417 draft-rosenberg-sipping-consent-framework-00 (work in 418 progress), July 2004. 420 [14] Rosenberg, J., "Requirements for Consent-Based Communications 421 in the Session Initiation Protocol (SIP)", 422 draft-rosenberg-sipping-consent-reqs-00 (work in progress), 423 July 2004. 425 [15] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol 426 (SIP) and Spam", draft-rosenberg-sipping-spam-00 (work in 427 progress), July 2004. 429 Authors' Addresses 431 Gonzalo Camarillo 432 Ericsson 433 Hirsalantie 11 434 Jorvas 02420 435 Finland 437 EMail: Gonzalo.Camarillo@ericsson.com 439 Adam Roach 440 Estacado Systems 442 EMail: adam@estacado.net 444 Intellectual Property Statement 446 The IETF takes no position regarding the validity or scope of any 447 Intellectual Property Rights or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; nor does it represent that it has 451 made any independent effort to identify any such rights. Information 452 on the procedures with respect to rights in RFC documents can be 453 found in BCP 78 and BCP 79. 455 Copies of IPR disclosures made to the IETF Secretariat and any 456 assurances of licenses to be made available, or the result of an 457 attempt made to obtain a general license or permission for the use of 458 such proprietary rights by implementers or users of this 459 specification can be obtained from the IETF on-line IPR repository at 460 http://www.ietf.org/ipr. 462 The IETF invites any interested party to bring to its attention any 463 copyrights, patents or patent applications, or other proprietary 464 rights that may cover technology that may be required to implement 465 this standard. Please address the information to the IETF at 466 ietf-ipr@ietf.org. 468 Disclaimer of Validity 470 This document and the information contained herein are provided on an 471 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 472 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 473 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 474 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 475 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 476 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 478 Copyright Statement 480 Copyright (C) The Internet Society (2004). This document is subject 481 to the rights, licenses and restrictions contained in BCP 78, and 482 except as set forth therein, the authors retain all their rights. 484 Acknowledgment 486 Funding for the RFC Editor function is currently provided by the 487 Internet Society.