idnits 2.17.1 draft-hautakorpi-sipping-uri-list-handling-refused-03.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, updated by RFC 4748 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 569. 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 -- 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 12, 2007) is 6009 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFCxxxx' on line 464 ** Obsolete normative reference: RFC 4234 (ref. '4') (Obsoleted by RFC 5234) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-06 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-conferencing-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group J. Hautakorpi 3 Internet-Draft G. Camarillo 4 Intended status: Informational Ericsson 5 Expires: May 15, 2008 November 12, 2007 7 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header 8 (P-Header) 9 draft-hautakorpi-sipping-uri-list-handling-refused-03.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 May 15, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies the Session Initiation Protocol (SIP) 43 P-Refused-URI-List Private-Header (P-Header). This P-Header is used 44 in the Open Mobile Alliance's (OMA) Pust to talk over Cellular (PoC) 45 system. It enables URI-list servers to refuse the handling of 46 incoming URI-list that have embedded URI-lists. This P-Header also 47 makes it possible for the URI-list server to inform the client about 48 the embedded URI-list that caused the rejection and the individual 49 URIs that form such a URI-list. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 57 5. Syntax of P-Refused-URI-List Header Field . . . . . . . . . . 6 58 6. Response Generation . . . . . . . . . . . . . . . . . . . . . 7 59 7. Message Sequence Example . . . . . . . . . . . . . . . . . . . 7 60 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 66 12.2. Informative References . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Intellectual Property and Copyright Statements . . . . . . . . . . 14 70 1. Introduction 72 The Open Mobile Alliance (OMA) has specified the Push to talk over 73 Cellular (PoC) service, which uses the Session Initiation Protocol 74 (SIP) [3] and Uniform Resource Identifier (URI)-list services [5] 75 (more information about OMA PoC can be found at [8]). 77 OMA PoC needs a mechanism for servers to refuse the handling of 78 incoming URI-lists when these have embedded URI-lists. Such a 79 mechanism is intended to be used to establish a particular type of 80 PoC session called an ad-hoc PoC group session. 82 The remainder of this document is organized as follows. Section 3 83 describes the scenario where the mechanism will be used. Section 4 84 provides an overview of the mechanism, which includes a new P-Header 85 called P-Refused-URI-List. Section 5 defines the syntax of this new 86 P-Header. Section 6 specifies how to use the P-Header. Section 7 87 provides a usage example. Section 8 describes the applicability of 88 the P-Header. Security considerations are discussed in Section 9 and 89 finally the IANA consideration are stated in Section 10. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [1]. 97 3. Usage Scenario 99 An ad-hoc PoC group session is a type of multi-party PoC session. 100 The originator of a particular ad-hoc PoC group session chooses in an 101 ad-hoc manner (e.g., selecting from an address book) the set of 102 desired participants. In order to establish the ad-hoc PoC group 103 session, the originator sends an INVITE request with a URI list that 104 contains the URIs of those participants. 106 The PoC network, following the procedures defined in [6], receives 107 such an INVITE request and generates an individual INVITE request 108 towards each of the URIs in the URI list. 110 In previous versions of the OMA PoC service, the originator of an ad- 111 hoc PoC group session was only allowed to populate the initial URI 112 list with URIs identifying individual PoC users. Later versions of 113 the service allow the originator to also include uri lists whose 114 entries represent URI lists. That is, the initial URI list contains 115 entries that are URI lists themselves. The expected service behavior 116 then is that the members of the embedded URI lists are invited to 117 join the ad-hoc PoC group session. 119 Figure 1 illustrates the desired behavior. The originator (not 120 shown) places the URI list friends@example.org, along with the URI 121 alice@example.com, in the initial URI list. The PoC network resolves 122 friends@example.org into its members, bob@example.org and 123 carol@example.net, and sends INVITE requests to all the recipients. 125 2. INVITE 126 +------------------> 127 | alice@example.com 128 | 129 | 130 +-------------+ 131 | | 132 1. INVITE | | 3. INVITE 133 ------------------>| PoC Network |----------------> 134 alice@example.com | | bob@example.org 135 friends@example.org | | 136 +-------------+ 137 | 138 | 139 | 140 | 4. INVITE 141 +------------------> 142 carol@example.net 144 Figure 1: PoC Expected Behavior 146 The PoC network in Figure 1 consists of PoC servers, which are SIP 147 entities that can behave as proxies or B2BUAs (Back-to-back User 148 Agents). There are two types of logical PoC servers: controlling and 149 participating. 151 In an ad-hoc PoC group session, there is always exactly one 152 controlling PoC server. The controlling PoC server of an ad-hoc PoC 153 group session resolves an incoming URI list and sends INVITEs to the 154 members of the list. The controlling PoC Server also functions as 155 the focus of the session. Every participant in an ad-hoc PoC group 156 has an associated participating PoC server, which resides in the home 157 domain of the participant. 159 Figure 2 shows how the PoC servers of the PoC network behave in the 160 scenario shown in Figure 1. An originating PoC user agent sends an 161 INVITE request (1) with a URI list to its participating PoC server. 162 The participating PoC server of the originator receives the INVITE 163 request, assumes the role of controlling PoC server for the ad-hoc 164 PoC group session, and sends an INVITE request to each of the URIs in 165 the URI list. 167 +-------------+ 168 2. INVITE | Particip. | 169 +------------------>| PoC server |-> 170 | alice@example.com | example.com | 171 | +-------------+ 172 | 173 +-------------+ 3. INVITE +-------------+ 174 | |-------------------->| | 175 1. INVITE | Controlling | friends@example.org | Particip. | 176 ---------------->| PoC server | | PoC server |-> 177 alice@example.com | | 4. 403 Forbidden | example.org | 178 friends@example.org| |<--------------------| | 179 +-------------+ bob@example.org +-------------+ 180 | | carol@example.net ^ 181 | | | 182 | | 5. INVITE | 183 | +--------------------------------+ 184 | bob@example.org 185 | 186 | +------------+ 187 | 6. INVITE | Particip. | 188 +------------------>| PoC server |-> 189 carol@example.net | example.net| 190 +------------+ 192 Figure 2: PoC Network Behavior 194 The first URI of the list, alice@example.com, identifies a single 195 user. The second URI of the URI list, friends@example.org, 196 identifies a URI list. In PoC terminology, friends@example.com 197 identifies a pre-arranged PoC group. The PoC server at example.org, 198 which knows the membership of friends@example.com, cannot send INVITE 199 requests to the members of friends@example.org because that PoC 200 server does not act as a controlling PoC server for the ad-hoc PoC 201 group session being established. Instead, it informs the controlling 202 PoC server that friends@example.org is a list whose members are 203 bob@example.org and carol@example.net. Upon receiving this 204 information, the controlling PoC server generates INVITE requests 205 towards bob@example.org and carol@example.net. 207 Although not shown in the above example, based on policy, presence of 208 the members, etc., the participating PoC server (example.org) can 209 include just a partial list of URIs of the URI list; furthermore, a 210 URI that the participating PoC server returns can be URI list. 212 At present, there is neither a mechanism for a participating PoC 213 server to inform a controlling PoC server that a URI identifies a 214 list and about the members of that list, nor to indicate the URIs 215 contained in the list. This document defines such a mechanism: the 216 P-Refused-URI-List P-Header. 218 4. Overview of Operation 220 When a URI-list server receives an INVITE request with a URI list, 221 some of which entries are URI lists themselves that the server cannot 222 handle, it returns a 403 (Forbidden) response with a P-Refused-URI- 223 List P-Header, as shown in Figure 3. The P-Refused-URI P-Header 224 contains the members of the URI list or lists that caused the 225 rejection of the request. This way, the client can send requests 226 directly to those member URIs. 228 +---------+ INVITE request +----------+ 229 | |------------------------------>| | 230 | | [URI-list in a URI-list] | URI-list | 231 | Client | | server | 232 | | 403 Forbidden | | 233 | |<------------------------------| | 234 | | [Content of refused URI-list] | | 235 +---------+ +----------+ 237 Figure 3: Operational Overview 239 5. Syntax of P-Refused-URI-List Header Field 241 The following is the augmented Backus-Naur Form (BNF) [4] syntax of 242 the P-Refused-URI-List P-Header: 244 P-Refused-URI-List = "P-Refused-URI-List" HCOLON 245 uri-list-entry 246 *(COMMA uri-list-entry) 247 uri-list-entry = ( name-addr / addr-spec ) 248 *( SEMI refused-param ) 249 refused-param = members-param / generic-param 250 members-param = "members" EQUAL 251 LDQUOT *( qdtext / quoted-pair ) RDQUOT 253 The members P-Header parameter MUST contain a cid-url, which is 254 defined in RFC 2392 [2]. 256 The HCOLON, SEMI, EQUAL, LDQUOT, RDQUOT, and generic-param are 257 defined in [3]. 259 6. Response Generation 261 A 403 (Forbidden) response can contain more than one P-Refused-URI- 262 List entries. The P-Refused-URI-List header field MUST NOT be used 263 with any other response. The P-Refused-URI-List P-Header contains 264 one or more URIs, which were present in the URI-list in the incoming 265 request and could not be handled by the server. Additionally, the 266 P-Refused-URI-List can optionally carry some or all of the members of 267 the URI lists identified by those URIs. 269 The 403 (Forbidden) response MAY contain body parts which contain 270 URI-lists. Those body parts can be referenced by the P-Refused-URI- 271 List entries through their Content-IDs [2]. If there is a Content-ID 272 defined in the P-Refused-URI-List, one of the body parts MUST have an 273 equivalent Content-ID. The format of a URI-list is service specific. 275 This kind of message structure enables clients to determine which URI 276 relates to which URI-list, if the URI-list server is willing to 277 disclose that information. Furthermore, the information enclosed in 278 the URI lists enable clients to take further actions to remedy the 279 rejection situation (e.g., send individual requests to the members of 280 the URI list). 282 7. Message Sequence Example 284 In the following message sequence example, a controlling PoC server 285 sends an INVITE request to a participating PoC server. The 286 participating PoC server rejects the request with a 403 (Forbidden) 287 response. The 403 response has a P-Refused-URI-List P-Header that 288 carries the members of the rejected URI-lists that the participating 289 PoC server determines to disclose to this controlling PoC server in 290 the body of the message. 292 Controlling PoC server Participating PoC server 293 example.com example.net 295 | | 296 | INVITE | 297 |-------------------------------->| 298 | | 299 | 403 Forbidden | 300 |<--------------------------------| 301 | | 303 Figure 4: Message Sequence Example 305 The INVITE request shown in Figure 4 is the following (Via header 306 fields are not shown for simplicity): 308 INVITE sip:poc-service@example.net SIP/2.0 309 Max-Forwards: 70 310 From: PoC service ;tag=4fxaed73sl 311 To: PoC service 312 Call-ID: 7xTn9vxNit65XU7p4@example.com 313 CSeq: 1 INVITE 314 Contact: 315 Require: recipient-list-invite 316 Content-Type: multipart/mixed;boundary="boundary1" 317 Content-Length: 538 319 --boundary1 320 Content-Type: application/sdp 322 (SDP not shown) 324 --boundary1 325 Content-Type: application/resource-lists+xml 326 Content-Disposition: recipient-list 328 329 330 331 332 333 334 335 336 --boundary1-- 338 The URIs sip:friends-list@example.net and 339 sip:colleagues-list@example.net in the example above are actually 340 references to URI lists (i.e., pre-arranged PoC groups). In the 341 following response, the URI lists are in the XML resource list format 342 [7]. 344 The content of the 403 (Forbidden) response in Figure 4 is the 345 following (Via header fields are not shown for simplicity): 347 SIP/2.0 403 Forbidden 348 From: PoC service ;tag=4fxaed73sl 349 To: PoC service ;tag=814254 350 Call-ID: 7xTn9vxNit65XU7p4@example.com 351 CSeq: 1 INVITE 352 P-Refused-URI-List: sip:friends-list@example.net; 353 members= 354 P-Refused-URI-List: sip:colleagues-list@example.net; 355 members= 356 Content-Type: multipart/mixed;boundary="boundary1" 357 Content-Length: 745 359 --boundary1 360 Content-Type: application/resource-lists+xml 361 Content-Disposition: recipient-list 362 Content-ID: 364 365 366 367 368 369 370 371 373 --boundary1 374 Content-Type: application/resource-lists+xml 375 Content-Disposition: recipient-list 376 Content-ID: 378 379 380 381 382 383 384 385 --boundary1-- 387 Using the message body of the 403 (Forbidden) response above, the 388 controlling PoC server can determine the members of 389 sip:friend-list@example.net and sip:colleagues-list@example.net that 390 the participating PoC Server determines to disclose to this 391 controlling PoC Server. Furthermore, the controlling PoC server can 392 deduce that the participating PoC server has not sent any outgoing 393 requests, per regular URI-list server procedures. 395 8. Applicability 397 The P-Refused-URI-list header field is intended to be used in OMA PoC 398 networks. This header field is used between PoC servers and carries 399 information about those URI-lists that were rejected by the server 400 receiving the request. 402 The OMA PoC services is designed so that, in a given session, only 403 one PoC server can resolve incoming URI lists and send INVITEs to 404 members of these lists. This restriction is not present on services 405 developed to be used on the public Internet. Therefore, the 406 P-Refused-URI-List P-Header does not seem to have general 407 applicability outside the OMA PoC service. 409 Additionally, the use of the P-Refused-URI-List P-Header requires 410 special trust relationships between servers that do not typically 411 exist on the public Internet. 413 It is important to note that the P-Refused-URI-List is optional and 414 does not change the basic behavior of a SIP URI-list service. The 415 P-Refused-URI-List only provides clients with additional information 416 about the refusal of the request. 418 9. Security Considerations 420 It is assumed that the network elements handling the P-Refused-URI- 421 List P-Header are trusted. Also, attackers are not supposed to have 422 access to the protocol messages between those elements. This is 423 because the P-Refused-URI-List is intended to be used in the OMA PoC 424 environment, which is implemented in the operators' core network; for 425 more on OMA PoC security assumptions, see [9]. Traffic protection 426 between network elements is achieved by using IP Security (IPsec) and 427 sometimes by physically protecting the network. 429 However, implementors and administrators should be aware of two 430 special security consideration related to the use of P-Refused-URI- 431 List: 433 Eavesdropping: 403 (Forbidden) responses may contain information 434 about the members of a given URI list. Eavesdroppers can acquire 435 this information if the 403 (Forbidden) responses are not 436 encrypted. Therefore it is RECOMMENDED that either hop-by-hop or 437 end-to-end encryption is used. 439 Disclosing information: A rogue entity may be able to acquire 440 information about the members of a given URI list if the URI-list 441 server sends information about those URI-lists also to 442 unauthorized users. Therefore, it is RECOMMENDED that URI-list 443 server discloses the content of URI-list only to authorized 444 clients. 446 10. IANA Considerations 448 The IANA is requested to make two additions to the Session Initiation 449 Protocol (SIP) Parameters registry. The first addition is to add the 450 following header field to the already existing Header Fields sub- 451 registry 453 Header Name compact Reference 454 ----------------- ------- --------- 455 P-Refused-URI-List [RFCxxxx] 457 The second addition is to add the following header field parameter to 458 the already existing Header Field Parameters and Parameter Values 459 sub-registry. 461 Predefined 462 Header Field Parameter Name Values Reference 463 ---------------------------- --------------- --------- --------- 464 P-Refused-URI-List members No [RFCxxxx] 466 Note for the RFC Editor: The two occurrences of 'RFCxxxx' in the 467 above should be a reference to the coming RFC number of this draft. 469 11. Acknowledgements 471 Authors would like to thank Tom Hiller who did a thorough, dedicated 472 review for this draft. 474 12. References 476 12.1. Normative References 478 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 479 Levels", BCP 14, RFC 2119, March 1997. 481 [2] Levinson, E., "Content-ID and Message-ID Uniform Resource 482 Locators", RFC 2392, August 1998. 484 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 485 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 486 Session Initiation Protocol", RFC 3261, June 2002. 488 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 489 Specifications: ABNF", RFC 4234, October 2005. 491 [5] Camarillo, G. and A. Roach, "Framework and Security 492 Considerations for Session Initiation Protocol (SIP) Uniform 493 Resource Identifier (URI)-List Services", 494 draft-ietf-sipping-uri-services-06 (work in progress), 495 September 2006. 497 [6] Camarillo, G. and A. Johnston, "Conference Establishment Using 498 Request-Contained Lists in the Session Initiation Protocol 499 (SIP)", draft-ietf-sip-uri-list-conferencing-01 (work in 500 progress), January 2007. 502 12.2. Informative References 504 [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for 505 Representing Resource Lists", 506 draft-ietf-simple-xcap-list-usage-05 (work in progress), 507 February 2005. 509 [8] "OMA PoC System Description: Draft Version 2.0", April 2007. 511 [9] "Push to talk over Cellular (PoC) - Architecture: Draft Version 512 2.0", April 2007. 514 Authors' Addresses 516 Jani Hautakorpi 517 Ericsson 518 Hirsalantie 11 519 Jorvas 02420 520 Finland 522 Email: Jani.Hautakorpi@ericsson.com 523 Gonzalo Camarillo 524 Ericsson 525 Hirsalantie 11 526 Jorvas 02420 527 Finland 529 Email: Gonzalo.Camarillo@ericsson.com 531 Full Copyright Statement 533 Copyright (C) The IETF Trust (2007). 535 This document is subject to the rights, licenses and restrictions 536 contained in BCP 78, and except as set forth therein, the authors 537 retain all their rights. 539 This document and the information contained herein are provided on an 540 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 541 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 542 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 543 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 544 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 545 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 547 Intellectual Property 549 The IETF takes no position regarding the validity or scope of any 550 Intellectual Property Rights or other rights that might be claimed to 551 pertain to the implementation or use of the technology described in 552 this document or the extent to which any license under such rights 553 might or might not be available; nor does it represent that it has 554 made any independent effort to identify any such rights. Information 555 on the procedures with respect to rights in RFC documents can be 556 found in BCP 78 and BCP 79. 558 Copies of IPR disclosures made to the IETF Secretariat and any 559 assurances of licenses to be made available, or the result of an 560 attempt made to obtain a general license or permission for the use of 561 such proprietary rights by implementers or users of this 562 specification can be obtained from the IETF on-line IPR repository at 563 http://www.ietf.org/ipr. 565 The IETF invites any interested party to bring to its attention any 566 copyrights, patents or patent applications, or other proprietary 567 rights that may cover technology that may be required to implement 568 this standard. Please address the information to the IETF at 569 ietf-ipr@ietf.org. 571 Acknowledgment 573 Funding for the RFC Editor function is provided by the IETF 574 Administrative Support Activity (IASA).