idnits 2.17.1 draft-ietf-sipping-uri-services-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 414. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 430), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2004) is 7227 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 (-02) exists of draft-camarillo-sipping-uri-list-01 == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-04 == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-02 == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-02 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-03 == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-02 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 6 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: January 5, 2005 July 7, 2004 5 Requirements and Framework for Session Initiation Protocol (SIP) 6 Uniform Resource Identifier (URI)-List Services 7 draft-ietf-sipping-uri-services-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 5, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes the need for SIP URI-List Services and 40 provides requirements for their invocation. Additionaly, it defines a 41 framework which includes all the SIP extensions needed to meet these 42 requirements. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3.1 Requirements for Request-Contained URI-List Services . . . 4 50 3.2 General Requirements for URI-List Services . . . . . . . . 4 51 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4.1 Carrying URI-Lists in SIP . . . . . . . . . . . . . . . . 5 53 4.2 Processing of URI-Lists . . . . . . . . . . . . . . . . . 5 54 4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 5.1 List Integrity and Confidentiality . . . . . . . . . . . . 6 57 5.2 Amplification Attacks . . . . . . . . . . . . . . . . . . 6 58 5.3 Unsolicited Requests . . . . . . . . . . . . . . . . . . . 8 59 5.4 General Issues . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 63 7.2 Informational References . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 65 Intellectual Property and Copyright Statements . . . . . . . . 10 67 1. Introduction 69 Some applications require that, at a given moment, a SIP [2] UA (User 70 Agent) performs a similar transaction with a number of remote UAs. 71 For example, an instant messaging application that needs to send a 72 particular message (e.g., "Hello folks") to n receivers needs to send 73 n MESSAGE requests; one to each receiver. 75 When the transacton that needs to be repeated consists of a large 76 request, or the number of recipients is high, or both, the access 77 network of the UA needs to carry a considerable amount of traffic. 78 Completing all the transactions on a low-bandwidth access would 79 require a long time. This is unacceptable for a number of 80 applications. 82 A solution to this problem consists of introducing URI-list services 83 in the network. The task of a SIP URI-list service is to receive a 84 request that contains or references a URI-list and send a number of 85 similar requests to the destinations in this list. Once the requests 86 are sent, the URI-list service typically informs the UA about their 87 status. Effectively, the URI-list service behaves as a B2BUA 88 (Back-To-Back-User-Agent). 90 If the request references an external URI-list (e.g., the Request-URI 91 is a SIP URI which is associated with a URI-list at the server), this 92 URI-list is referred to as an stored URI-list. If the request 93 contains the URI-list, the URI-list is referred to as a 94 request-contained URI-list. 96 Stored URI-lists are typically set up using out-of-band mechanisms 97 (e.g., XCAP [9]). An example of a URI-list service for SUBSCRIBE 98 requests that uses stored URI-lists is described in [4]. 100 The Advanced Instant Messaging Requirements for SIP [5] mentions the 101 need for request-contained URI-list services for MESSAGE transactions 103 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 104 group, where the identities of the recipients are carried in the 105 message itself." 107 The remainder of this document provides requirements for both stored 108 and request-contained SIP URI-list services. 110 2. Terminology 112 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 113 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 114 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 115 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 116 compliant implementations. 118 3. Requirements 120 Section 3.1 discusses requirements that only apply to 121 request-contained URI-list services and Section 3.2 discusses 122 requirements that apply to both stored and request-contained URI-list 123 services. 125 3.1 Requirements for Request-Contained URI-List Services 127 1. The URI-list service invocation mechanism MUST allow the invoker 128 to provide a list of destination URIs to the URI-list service. 129 This URI-list MAY consist of one or more URIs. 130 2. The mechanism to provide the URI-list to the URI-list service 131 MUST NOT be request specific. 132 3. The invocation mechanism SHOULD NOT require more than one RTT 133 (Round-Trip Time). 135 3.2 General Requirements for URI-List Services 137 1. An URI-list service MAY include services beyond sending requests 138 to the URIs in the URI-list. That is, URI-list services can be 139 modelled as application servers. For example, a URI-list service 140 handling INVITE requests may behave as a conference server and 141 perform media mixing for all the participants. 142 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 3. It MUST be possible for the invoker to find out about the result 146 of the operations performed by the URI-list service with the 147 URI-list. An invoker may, for instance, be interested in the 148 status of the transactions initiated by the URI-list service. 149 4. URI-list services MUST NOT send requests to multiple destinations 150 without authenticating the invoker. 152 4. Framework 154 Although Section 3 contains specific requirements for SIP URI-list 155 services, this framework is not restricted to application servers 156 that only provide request fan-out services. Per the general 157 requirement number 1, we also deal with application servers that 158 provide a particular service that includes a request fan-out (e.g., a 159 conference server that INVITEs several participants which are chosen 160 by a user agent). 162 4.1 Carrying URI-Lists in SIP 164 The requirements that relate to request-contained URI-list services 165 identify the need for a request-independent mechanism to provide a 166 SIP URI-list service with a URI-list in a single RTT. The mechanism 167 described in (draft-ietf-sipping-uri-list-00.txt) [3] meets these 168 three requirements. 170 UAs (User Agents) use body parts whose disposition type is uri-list 171 to transport URI-lists. The default URI-list format for SIP entities 172 is the XCAP resource list format defined in [6]. 174 4.2 Processing of URI-Lists 176 According to the general requirements 1 and 2, URI-list services can 177 behave as application servers. That is, taking a URI-list as an 178 input, they can provide arbitrary services. 180 So, the interpretation of the URI-list by the server depends on the 181 service to be provided. For example, for a conference server, the 182 URIs in the list may identify the initial set of participants. On the 183 other hand, for a server dealing with MESSAGEs, the URIs in the list 184 may identify the recipients of an instant message. 186 At the SIP level, this implies that the behavior of application 187 servers receiving requests with URI-lists SHOULD be specified on a 188 per method basis. Examples of such specifications are 189 [draft-ietf-sipping-uri-list-conferencing-00.txt] for INVITE, 190 [draft-ietf-sipping-multiple-refer-00.txt] for REFER, 191 [draft-ietf-sipping-uri-list-message-00.txt] for MESSAGE, and 192 [draft-ietf-sipping-uri-list-subscribe-00.txt] for SUBSCRIBE. 194 4.3 Results 196 According to requirement 6, user agents should have a way to obtain 197 information about the operations performed by the application server. 198 Since these operations are service specific, the way user agents are 199 kept informed is also service specific. For example, a user agent 200 establishing an adhoc conference with an INVITE with a URI-list may 201 discover which participants were successfully brought in into the 202 conference by using the conference package [8]. 204 5. Security Considerations 206 Security plays an important role in the implementation of any 207 URI-list service. By definition, a URI-list service takes one request 208 in and sends a potentially large number of them out. Attackers may 209 attempt to use URI-list services as traffic amplifiers to launch DoS 210 attacks. In addition, malicious users may attempt to use URI-list 211 services to distribute unsolicited messages (i.e., SPAM) or to make 212 unsolicited VoIP calls. This section provides guidelines to avoid 213 these attacks. 215 5.1 List Integrity and Confidentiality 217 Attackers may attempt to modify URI-lists sent from clients to 218 servers. This would cause a different behavior at the server than 219 expected by the client (e.g., requests being sent to different 220 recipients as the ones specified by the client). To prevent this 221 attack, clients SHOULD integrity protect URI-lists using mechanisms 222 such as S/MIME, which can also provide URI-list confidentiality if 223 needed. 225 5.2 Amplification Attacks 227 URI-list services take a request in and send a potentially large 228 number of them out. Given that URI-list services are typically 229 implemented on top of powerful servers with high-bandwidth access 230 links, we should be careful to keep attackers from using them as 231 amplification tools to launch DoS (Denial of Service) attacks. 233 Attackers may attempt to send a URI-list containing URIs whose host 234 parts route to the victims of the DoS attack. These victims do not 235 need to be SIP nodes; they can be non-SIP endpoints or even routers. 236 If this attack is successful, the result is that an attacker can 237 flood with traffic a set of nodes, or a single node, without needing 238 to generate a high volume of traffic itself. 240 Note, in any case, that this problem is not specific to SIP 241 URI-list services; it also appears in scenarios which relate to 242 multihoming where a server needs to contact a set of IP addresses 243 provided by a client (e.g., an SCTP [10] endpoint using HEARTBEATs 244 to check the status of the IP addresses provided by its peer at 245 association establishment). 247 There are several measures that need to be taken to prevent this type 248 of attack. The first one is keeping unauthorized users from using 249 URI-list services. So, URI-list services MUST NOT perform any request 250 explosion for an unauthorized user. URI-list services MUST 251 authenticate users and check whether they are authorized to request 252 the service before performing any request fan-out. 254 Note that the risk of this attack also exists when a client uses 255 stored URI-lists. Application servers MUST use authentication and 256 authorization mechanisms with equivalent security properties when 257 dealing with stored and request-contained URI-lists. 259 Even though the previous rule keeps unauthorized users from using 260 URI-list services, authorized users may still launch attacks using a 261 these services. To prevent these attacks, we introduce the concept of 262 opt-in lists. That is, URI-list services should not allow a client to 263 place a user (identified by his or her URI) in a URI-list unless the 264 user has previously agreed to be placed in such a URI-list. So, 265 URI-list services MUST NOT send a request to a destination which has 266 not agreed to receive requests from the URI-list service beforehand. 267 Users can agree to receive requests from a URI-list service in 268 several ways, such as filling a web page, sending an email, or 269 signing a contract. Additionally, users MUST be able to further 270 describe the requests they are willing to receive. For example, a 271 user may only want to receive requests from a particular URI-list 272 service on behalf of a particular user. Effectively, these rules make 273 URI-lists used by URI-list services opt-in lists. 275 When a URI-list service receives a request with a URI-list from a 276 client, the URI-list service checks whether all the destinations have 277 agreed beforehand to receive requests from the service on behalf of 278 this client. If the URI-list has permission to send requests to all 279 of the targets in the request, it does so. If not, the URI-list 280 service rejects the request, indicating in the rejection the set of 281 targets for which it did not have permission. This allows the client 282 to request permission for those targets. 284 DoS amplification would still happen if the URI-list service 285 automatically contacted the full set of targets for which it did not 286 have permission in order to request permission. The URI-list service 287 would be receiving one SIP request and sending out a number of 288 authorization request messages. In order to avoid this amplification, 289 the URI-list service must ensure that the client generates roughly 290 the same amount of traffic towards the URI-list service as the 291 service generates towards the destinations. Consequently, the 292 URI-list service MUST require that clients send and individual 293 authorization request for each destination. 295 These individual authorization requests sent by the client may or may 296 not be routed through the URI-list service. In any case, the URI-list 297 service MUST be informed about the destinations' responses to these 298 authorization requests in order to authorize requests towards them. 299 One possible mechanism for clients to send authorization requests to 300 the destinations is specified in 301 [draft-rosenberg-sipping-consent-framework-00.txt], which discusses 302 consent-based communications in SIP. The requirements for 303 consent-based communications in SIP are discussed in 304 [draft-rosenberg-sipping-consent-reqs-00.txt] 306 5.3 Unsolicited Requests 308 Opt-in lists should help fighting SPAMMERS. Still, if a URI-list 309 service is used to send unsolicited requests to one or several 310 destinations, it should be possible to track down the sender of such 311 requests. To do that, URI-list services MAY provide information about 312 the identity of the original sender of the request in their outgoing 313 requests. URI-list services can use Authenticated Identity Bodies 314 (AIB) [7] to provide this information. 316 5.4 General Issues 318 URI-list services MAY have policies that limit the number of URIs in 319 the lists they accept, as a very long list could be used in a denial 320 of service attack to place a large burden on the URI-list service to 321 send a large number of SIP requests. 323 The general requirement number 4, which states that URI-list services 324 need to authenticate their clients, and the previous rules apply to 325 URI-list services in general. In addition, specifications dealing 326 with individual methods MUST describe the security issues that relate 327 to each particular method. 329 6. Acknowledges 331 Duncan Mills and Miguel A. Garcia-Martin supported the idea of 1 to n 332 MESSAGEs. Jon Peterson and Dean Willis provided useful comments. 334 7. References 336 7.1 Normative References 338 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 339 Levels", BCP 14, RFC 2119, March 1997. 341 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 342 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 343 Session Initiation Protocol", RFC 3261, June 2002. 345 7.2 Informational References 347 [3] Camarillo, G., "Providing a Session Initiation Protocol (SIP) 348 Application Server with a List of URIs", 349 draft-camarillo-sipping-uri-list-01 (work in progress), 350 February 2004. 352 [4] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 353 Protocol (SIP) Event Notification Extension for Resource 354 Lists", draft-ietf-simple-event-list-04 (work in progress), 355 June 2003. 357 [5] Rosenberg, J., "Advanced Instant Messaging Requirements for the 358 Session Initiation Protocol (SIP)", 359 draft-rosenberg-simple-messaging-requirements-01 (work in 360 progress), February 2004. 362 [6] Rosenberg, J., "An Extensible Markup Language (XML) 363 Configuration Access Protocol (XCAP) Usage for Presence 364 Lists", draft-ietf-simple-xcap-list-usage-02 (work in 365 progress), February 2004. 367 [7] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 368 draft-ietf-sip-authid-body-02 (work in progress), July 2003. 370 [8] Rosenberg, J. and H. Schulzrinne, "A Session Initiation 371 Protocol (SIP) Event Package for Conference State", 372 draft-ietf-sipping-conference-package-03 (work in progress), 373 February 2004. 375 [9] Rosenberg, J., "The Extensible Markup Language (XML) 376 Configuration Access Protocol (XCAP)", 377 draft-ietf-simple-xcap-02 (work in progress), February 2004. 379 [10] Bradner, S., "A Proposal for an MOU-Based ICANN Protocol 380 Support Organization", RFC 2690, September 1999. 382 Author's Address 384 Gonzalo Camarillo 385 Ericsson 386 Hirsalantie 11 387 Jorvas 02420 388 Finland 390 EMail: Gonzalo.Camarillo@ericsson.com 392 Intellectual Property Statement 394 The IETF takes no position regarding the validity or scope of any 395 Intellectual Property Rights or other rights that might be claimed to 396 pertain to the implementation or use of the technology described in 397 this document or the extent to which any license under such rights 398 might or might not be available; nor does it represent that it has 399 made any independent effort to identify any such rights. Information 400 on the IETF's procedures with respect to rights in IETF Documents can 401 be found in BCP 78 and BCP 79. 403 Copies of IPR disclosures made to the IETF Secretariat and any 404 assurances of licenses to be made available, or the result of an 405 attempt made to obtain a general license or permission for the use of 406 such proprietary rights by implementers or users of this 407 specification can be obtained from the IETF on-line IPR repository at 408 http://www.ietf.org/ipr. 410 The IETF invites any interested party to bring to its attention any 411 copyrights, patents or patent applications, or other proprietary 412 rights that may cover technology that may be required to implement 413 this standard. Please address the information to the IETF at 414 ietf-ipr@ietf.org. 416 Disclaimer of Validity 418 This document and the information contained herein are provided on an 419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 421 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 422 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 423 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 426 Copyright Statement 428 Copyright (C) The Internet Society (2004). This document is subject 429 to the rights, licenses and restrictions contained in BCP 78, and 430 except as set forth therein, the authors retain all their rights. 432 Acknowledgment 434 Funding for the RFC Editor function is currently provided by the 435 Internet Society.