idnits 2.17.1 draft-hautakorpi-sipping-uri-list-handling-refused-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 548. 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 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 (Jan 2007) is 6309 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) -- Looks like a reference, but probably isn't: 'RFCxxxx' on line 450 ** Obsolete normative reference: RFC 4234 (ref. '4') (Obsoleted by RFC 5234) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-05 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-conferencing-00 Summary: 2 errors (**), 0 flaws (~~), 4 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 Expires: July 5, 2007 Ericsson 5 Jan 2007 7 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header 8 (P-Header) 9 draft-hautakorpi-sipping-uri-list-handling-refused-01.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 July 5, 2007. 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) Push to talk over Cellular (PoC) 45 system. It enables URI-list servers to refuse the handling of an 46 incoming URI-list, which has an embedded URI-list inside it. This 47 P-Header also makes it possible for the URI-list server to inform the 48 client about the embedded URI-list that caused the rejection and the 49 individual 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 . . . . . . . . . . . . . . . . . . . . . 6 59 7. Message Sequence Example . . . . . . . . . . . . . . . . . . . 7 60 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 65 11.2. Informative References . . . . . . . . . . . . . . . . . 12 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 67 Intellectual Property and Copyright Statements . . . . . . . . . . 13 69 1. Introduction 71 The Open Mobile Alliance (OMA) has specified the Push to talk over 72 Cellular (PoC) service, which uses the Session Initiation Protocol 73 (SIP) [3] and Uniform Resource Identifier (URI)-list services [5] 74 (more information about OMA PoC can be found at [8]). 76 OMA PoC needs a mechanism for servers to refuse the handling of 77 incoming URI-lists when these have embedded URI-lists inside them. 78 Such a mechanism is intended to be used to establish a particular 79 type of PoC session called ad-hoc PoC group. 81 The remainder of this document is organized as follows. Section 3 82 describes the scenario where the mechanism will be used. Section 4 83 provides an overview of the mechanism, which includes a new P-Header 84 called P-Refused-URI-List. Section 5 defines the syntax of this new 85 P-Header. Section 6 specifies how to use the P-Header. Section 7 86 provides a usage example. Section 8 describes the applicability of 87 the P-Header. Security considerations are discussed in Section 9 and 88 finally the IANA consideration are stated in Section 10. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [1]. 96 3. Usage Scenario 98 An ad-hoc PoC group is a type of multi-party PoC session. The 99 originator or a particular ad-hoc PoC group chooses in an ad-hoc 100 manner (e.g., selecting them from an address book) the set of 101 participants in the ad-hoc PoC group. In order to establish the ad- 102 hoc PoC group, the originator sends an INVITE request with a URI 103 list, which contains the URIs of those participants. 105 The PoC network, following the procedures defined in [6], receives 106 such an INVITE request and generates an individual INVITE request 107 towards each of the URIs in the URI list. 109 In previous versions of the OMA PoC service, the originator of an ad- 110 hoc PoC group was only allowed to populate the initial URI list with 111 URIs identifying individual users. Later versions of the service 112 allow the originator to also include entries that do not represent 113 individual users, but also represent URI lists themselves. That is, 114 the initial URI list would carry entries that are URI lists 115 themselves. 117 The expected service behavior in such a case is that all the members 118 of the embedded URI lists are also invited to join the ad-hoc PoC 119 group. Figure 1 illustrates this point. The originator places the 120 URI list friends@example.org in inside its initial URI list. The PoC 121 network resolves friends@example.org into its members, which are 122 bob@example.org and carol@example.net, and sends INVITE requests to 123 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 PoC servers: controlling and 149 participating. 151 In an ad-hoc PoC group, there is always exactly one controlling PoC 152 server. However, there can be any number of participating PoC 153 servers. The controlling PoC server of an ad-hoc PoC group is the 154 only PoC server that can resolve an incoming URI list and send 155 INVITEs to its members. Every participant in an ad-hoc PoC group has 156 an associated participating PoC server. 158 Figure 2 shows how the PoC network behaves in the scenario shown in 159 Figure 1. A PoC user agent sends an INVITE request (1) with URI list 160 in its body to its PoC server. The PoC server receives the INVITE 161 request becomes the controlling PoC server for the ad-hoc PoC group 162 and sends an INVITE request to each of the URIs in the URI list. 164 +-------------+ 165 2. INVITE | Particip. | 166 +------------------>| PoC server |-> 167 | alice@example.com | example.com | 168 | +-------------+ 169 | 170 +-------------+ 3. INVITE +-------------+ 171 | |-------------------->| | 172 1. INVITE | Controlling | friends@example.org | Particip. | 173 ---------------->| PoC server | | PoC server |-> 174 alice@example.com | | 4. 403 Forbidden | example.org | 175 friends@example.org| |<--------------------| | 176 +-------------+ bob@example.org +-------------+ 177 | | carol@example.net ^ 178 | | | 179 | | 5. INVITE | 180 | +--------------------------------+ 181 | bob@example.org 182 | 183 | +------------+ 184 | 6. INVITE | Particip. | 185 +------------------>| PoC server |-> 186 carol@example.net | example.net| 187 +------------+ 189 Figure 2: PoC Network Behavior 191 The first URI, alice@example.com, identifies a single user. However, 192 the second URI in the URI list, friends@example.org, identifies a URI 193 list. In PoC terminology, the URI identifies a pre-arranged PoC 194 group. The PoC server at example.org cannot send INVITE requests to 195 the member of friends@example.org because it is not the controlling 196 PoC server for the ad-hoc PoC group. Instead, it informs the 197 controlling PoC server that friends@example.org is a list whose 198 members are bob@example.org and carol@example.net. On receiving this 199 information, the controlling PoC server generates INVITE requests 200 towards the members of the list. 202 At present, there is no mechanism for a participating PoC server to 203 inform a controlling PoC server about the fact that a URI identifies 204 a list and about the members of that list. This document defines 205 such a mechanism: the P-Refused-URI-List P-Header. 207 4. Overview of Operation 209 When a URI-list server receives an INVITE request with a URI list, 210 some of which entries are URI lists themselves that the server cannot 211 handle, it returns a 403 (Forbidden) response with a P-Refused-URI- 212 List P-Header, as shown in Figure 3. The P-Refused-URI P-Header 213 contains the members of the URI list or lists that caused the 214 rejection of the request. This way, the client can send requests 215 directly to those member URIs. 217 +---------+ INVITE request +----------+ 218 | |------------------------------>| | 219 | | [URI-list in a URI-list] | URI-list | 220 | Client | | server | 221 | | 403 Forbidden | | 222 | |<------------------------------| | 223 | | [Content of refused URI-list] | | 224 +---------+ +----------+ 226 Figure 3: Operational Overview 228 5. Syntax of P-Refused-URI-List Header Field 230 The following is the augmented Backus-Naur Form (BNF) [4] syntax of 231 the P-Refused-URI-List P-Header: 233 P-Refused-URI-List = "P-Refused-URI-List" HCOLON 234 uri-list-entry 235 *(COMMA uri-list-entry) 236 uri-list-entry = ( name-addr / addr-spec ) 237 *( SEMI refused-param ) 238 refused-param = members-param / generic-param 239 members-param = "members" EQUAL 240 LDQUOT *( qdtext / quoted-pair ) RDQUOT 242 The members P-Header parameter MUST contain a cid-url, which is 243 defined in RFC 2392 [2]. 245 The HCOLON, SEMI, EQUAL, LDQUOT, RDQUOT, and generic-param are 246 defined in [3]. 248 6. Response Generation 250 A 403 (Forbidden) response can contain more than one P-Refused-URI- 251 List entries. The P-Refused-URI-List header field MUST NOT be used 252 with any other response. The P-Refused-URI-List P-Header contains 253 one or more URIs, which were present in the URI-list in the incoming 254 request and could not be handled by the server. Additionally, the 255 P-Refused-URI-List can optionally carry the members of the URI lists 256 identified by those URIs. 258 The 403 (Forbidden) response MAY contain body parts which contain 259 URI-lists. Those body parts can be referenced by the P-Refused-URI- 260 List entries through their Content-IDs [2]. If there is a Content-ID 261 defined in the P-Refused-URI-List, one of the body parts MUST have an 262 equivalent Content-ID. The format of a URI-list is service specific. 264 This kind of message structure enables clients to determine which URI 265 relates to which URI-list, if the URI-list server is willing to 266 disclose that information. Furthermore, the information enclosed in 267 the URI lists enable clients to take further actions to remedy the 268 rejection situation (e.g., send individual requests to the members of 269 the URI list). 271 7. Message Sequence Example 273 In the following message sequence example, a controlling PoC server 274 sends an INVITE request to a participating PoC server. The 275 participating PoC server rejects the request with a 403 (Forbidden) 276 response. The 403 response has a P-Refused-URI-List P-Header that 277 carries the members of the rejected URI-lists in the body of the 278 message. 280 Controlling PoC server Participating PoC server 281 example.com example.net 283 | | 284 | INVITE | 285 |-------------------------------->| 286 | | 287 | 403 Forbidden | 288 |<--------------------------------| 289 | | 291 Figure 4: Message Sequence Example 293 The INVITE request shown in Figure 4 is the following (Via header 294 fields are not shown for simplicity): 296 INVITE sip:poc-service@example.net SIP/2.0 297 Max-Forwards: 70 298 From: PoC service ;tag=4fxaed73sl 299 To: PoC service 300 Call-ID: 7xTn9vxNit65XU7p4@example.com 301 CSeq: 1 INVITE 302 Contact: 303 Require: recipient-list-invite 304 Content-Type: multipart/mixed;boundary="boundary1" 305 Content-Length: 538 307 --boundary1 308 Content-Type: application/sdp 310 (SDP not shown) 312 --boundary1 313 Content-Type: application/resource-lists+xml 314 Content-Disposition: recipient-list 316 317 318 319 320 321 322 323 324 --boundary1-- 326 The URIs sip:friends-list@example.net and 327 sip:colleagues-list@example.net in the example above are actually 328 references to URI lists (i.e., pre-arranged PoC groups). In the 329 following response, the URI lists are in the XML resource list format 330 [7]. 332 The content of the 403 (Forbidden) response in Figure 4 is the 333 following (Via header fields are not shown for simplicity): 335 SIP/2.0 403 Forbidden 336 From: PoC service ;tag=4fxaed73sl 337 To: PoC service ;tag=814254 338 Call-ID: 7xTn9vxNit65XU7p4@example.com 339 CSeq: 1 INVITE 340 P-Refused-URI-List: sip:friends-list@example.net; 341 members= 342 P-Refused-URI-List: sip:colleagues-list@example.net; 343 members= 344 Conten-Type: multipart/mixed;boundary="boundary1" 345 Content-Length: 745 347 --boundary1 348 Content-Type: application/resource-lists+xml 349 Content-Disposition: uri-list 350 Content-ID: 352 353 354 355 356 357 358 359 361 --boundary1 362 Content-Type: application/resource-lists+xml 363 Content-Disposition: uri-list 364 Content-ID: 366 367 368 369 370 371 372 373 --boundary1-- 375 From the 403 (Forbidden) response above controlling PoC server can 376 determine the members of sip:friend-list@example.net and 377 sip:colleagues-list@example.net from the message body. Furthermore, 378 the controlling PoC server can deduce that the participating PoC 379 server has not sent any outgoing requests, per regular URI-list 380 server procedures. 382 8. Applicability 384 The P-Refused-URI-list header field is intended to be used in OMA PoC 385 networks. This header field is used between PoC servers and carries 386 information about those URI-lists that were rejected by the server 387 receiving the request. 389 The OMA PoC services is designed so that, in a given session, only 390 one server can resolve incoming URI lists and send INVITEs to its 391 members. This restriction is not present on services developed to be 392 used on the public Internet. Therefore, the P-Refused-URI-List 393 P-Header does not seem to have general applicability outside the OMA 394 PoC service. 396 Additionally, the use of the P-Refused-URI-List P-Header requires 397 special trust relationships between servers that do not typically 398 exist on the public Internet. 400 It is important to note that the P-Refused-URI-List is optional and 401 does not change the basic behavior of a SIP URI-list service. The 402 P-Refused-URI-List only provides clients with additional information 403 about the refusal of the request. 405 9. Security Considerations 407 It is assumed that the network elements handling the P-Refused-URI- 408 List P-Header are trusted. Also, attackers are not supposed to have 409 access to the protocol messages between those elements. This is 410 because the P-Refused-URI-List is intended to be used in the OMA PoC 411 environment, which is implemented in the operators' core network. 412 Traffic protection between network elements is achieved by using IP 413 Security (IPsec) and sometimes by physically protecting the network. 415 However, implementors and administrators should be aware of two 416 special security consideration related to the use of P-Refused-URI- 417 List: 419 Eavesdropping: 403 (Forbidden) responses may contain information 420 about the members of a given URI list. Eavesdroppers can acquire 421 this information if the 403 (Forbidden) responses are not 422 encrypted. Therefore it is RECOMMENDED that either hop-by-hop or 423 end-to-end encryption is used. 425 Disclosing information: A rogue entity may be able to acquire 426 information about the members of a given URI list if the URI-list 427 server sends information about those URI-lists also to 428 unauthorized users. Therefore, it is RECOMMENDED that URI-list 429 server discloses the content of URI-list only to authorized 430 clients. 432 10. IANA Considerations 434 The IANA is requested to make two additions to the Session Initiation 435 Protocol (SIP) Parameters registry. The first addition is to add the 436 following header field to the already existing Header Fields sub- 437 registry 439 Header Name compact Reference 440 ----------------- ------- --------- 441 P-Refused-URI-List [RFCxxxx] 443 The second addition is to add the following header field parameter to 444 the already existing Header Field Parameters and Parameter Values 445 sub-registry. 447 Predefined 448 Header Field Parameter Name Values Reference 449 ---------------------------- --------------- --------- --------- 450 P-Refused-URI-List members No [RFCxxxx] 452 Note for the RFC Editor: The two occurrences of 'RFCxxxx' in the 453 above should be a reference to the coming RFC number of this draft. 455 11. References 457 11.1. Normative References 459 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 460 Levels", BCP 14, RFC 2119, March 1997. 462 [2] Levinson, E., "Content-ID and Message-ID Uniform Resource 463 Locators", RFC 2392, August 1998. 465 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 466 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 467 Session Initiation Protocol", RFC 3261, June 2002. 469 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 470 Specifications: ABNF", RFC 4234, October 2005. 472 [5] Camarillo, G. and A. Roach, "Framework and Security 473 Considerations for Session Initiation Protocol (SIP) Uniform 474 Resource Identifier (URI)-List Services", 475 draft-ietf-sipping-uri-services-05 (work in progress), 476 January 2006. 478 [6] Camarillo, G. and A. Johnston, "Conference Establishment Using 479 Request-Contained Lists in the Session Initiation Protocol 480 (SIP)", draft-ietf-sip-uri-list-conferencing-00 (work in 481 progress), September 2006. 483 11.2. Informative References 485 [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for 486 Representing Resource Lists", 487 draft-ietf-simple-xcap-list-usage-05 (work in progress), 488 February 2005. 490 [8] "OMA PoC System Description: Draft Version 2.0", April 2006. 492 Authors' Addresses 494 Jani Hautakorpi 495 Ericsson 496 Hirsalantie 11 497 Jorvas 02420 498 Finland 500 Email: Jani.Hautakorpi@ericsson.com 502 Gonzalo Camarillo 503 Ericsson 504 Hirsalantie 11 505 Jorvas 02420 506 Finland 508 Email: Gonzalo.Camarillo@ericsson.com 510 Full Copyright Statement 512 Copyright (C) The IETF Trust (2007). 514 This document is subject to the rights, licenses and restrictions 515 contained in BCP 78, and except as set forth therein, the authors 516 retain all their rights. 518 This document and the information contained herein are provided on an 519 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 520 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 521 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 522 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 523 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 524 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 526 Intellectual Property 528 The IETF takes no position regarding the validity or scope of any 529 Intellectual Property Rights or other rights that might be claimed to 530 pertain to the implementation or use of the technology described in 531 this document or the extent to which any license under such rights 532 might or might not be available; nor does it represent that it has 533 made any independent effort to identify any such rights. Information 534 on the procedures with respect to rights in RFC documents can be 535 found in BCP 78 and BCP 79. 537 Copies of IPR disclosures made to the IETF Secretariat and any 538 assurances of licenses to be made available, or the result of an 539 attempt made to obtain a general license or permission for the use of 540 such proprietary rights by implementers or users of this 541 specification can be obtained from the IETF on-line IPR repository at 542 http://www.ietf.org/ipr. 544 The IETF invites any interested party to bring to its attention any 545 copyrights, patents or patent applications, or other proprietary 546 rights that may cover technology that may be required to implement 547 this standard. Please address the information to the IETF at 548 ietf-ipr@ietf.org. 550 Acknowledgment 552 Funding for the RFC Editor function is provided by the IETF 553 Administrative Support Activity (IASA).