SIPPING Working Group                                      J. Hautakorpi
Internet-Draft                                              G. Camarillo
Intended status: Informational                                  Ericsson
Expires: November 9, 2007                                    May 8, 2007


The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header
                               (P-Header)
       draft-hautakorpi-sipping-uri-list-handling-refused-02.txt

Status of this Memo

   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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 9, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies the Session Initiation Protocol (SIP)
   P-Refused-URI-List Private-Header (P-Header).  This P-Header is used
   in the Open Mobile Alliance's (OMA) Pust to talk over Cellular (PoC)
   system.  It enables URI-list servers to refuse the handling of
   incoming URI-list that have embedded URI-lists.  This P-Header also
   makes it possible for the URI-list server to inform the client about
   the embedded URI-list that caused the rejection and the individual



Hautakorpi & Camarillo  Expires November 9, 2007                [Page 1]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


   URIs that form such a URI-list.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  6
   5.  Syntax of P-Refused-URI-List Header Field  . . . . . . . . . .  6
   6.  Response Generation  . . . . . . . . . . . . . . . . . . . . .  7
   7.  Message Sequence Example . . . . . . . . . . . . . . . . . . .  7
   8.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     12.1.  Normative References  . . . . . . . . . . . . . . . . . . 11
     12.2.  Informative References  . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 14






























Hautakorpi & Camarillo  Expires November 9, 2007                [Page 2]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


1.  Introduction

   The Open Mobile Alliance (OMA) has specified the Push to talk over
   Cellular (PoC) service, which uses the Session Initiation Protocol
   (SIP) [3] and Uniform Resource Identifier (URI)-list services [5]
   (more information about OMA PoC can be found at [8]).

   OMA PoC needs a mechanism for servers to refuse the handling of
   incoming URI-lists when these have embedded URI-lists.  Such a
   mechanism is intended to be used to establish a particular type of
   PoC session called an ad-hoc PoC group session.

   The remainder of this document is organized as follows.  Section 3
   describes the scenario where the mechanism will be used.  Section 4
   provides an overview of the mechanism, which includes a new P-Header
   called P-Refused-URI-List.  Section 5 defines the syntax of this new
   P-Header.  Section 6 specifies how to use the P-Header.  Section 7
   provides a usage example.  Section 8 describes the applicability of
   the P-Header.  Security considerations are discussed in Section 9 and
   finally the IANA consideration are stated in Section 10.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].


3.  Usage Scenario

   An ad-hoc PoC group session is a type of multi-party PoC session.
   The originator of a particular ad-hoc PoC group session chooses in an
   ad-hoc manner (e.g., selecting from an address book) the set of
   desired participants.  In order to establish the ad-hoc PoC group
   session, the originator sends an INVITE request with a URI list that
   contains the URIs of those participants.

   The PoC network, following the procedures defined in [6], receives
   such an INVITE request and generates an individual INVITE request
   towards each of the URIs in the URI list.

   In previous versions of the OMA PoC service, the originator of an ad-
   hoc PoC group session was only allowed to populate the initial URI
   list with URIs identifying individual PoC users.  Later versions of
   the service allow the originator to also include uri lists whose
   entries represent URI lists.  That is, the initial URI list contains
   entries that are URI lists themselves.  The expected service behavior



Hautakorpi & Camarillo  Expires November 9, 2007                [Page 3]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


   then is that the members of the embedded URI lists are invited to
   join the ad-hoc PoC group session.

   Figure 1 illustrates the desired behavior.  The originator (not
   shown) places the URI list friends@example.org, along with the URI
   alice@example.com, in the initial URI list.  The PoC network resolves
   friends@example.org into its members, bob@example.org and
   carol@example.net, and sends INVITE requests to all the recipients.


                                   2. INVITE
                               +------------------>
                               |   alice@example.com
                               |
                               |
                        +-------------+
                        |             |
       1. INVITE        |             | 3. INVITE
     ------------------>| PoC Network |---------------->
    alice@example.com   |             | bob@example.org
    friends@example.org |             |
                        +-------------+
                               |
                               |
                               |
                               |   4. INVITE
                               +------------------>
                                   carol@example.net

                      Figure 1: PoC Expected Behavior

   The PoC network in Figure 1 consists of PoC servers, which are SIP
   entities that can behave as proxies or B2BUAs (Back-to-back User
   Agents).  There are two types of logical PoC servers: controlling and
   participating.

   In an ad-hoc PoC group session, there is always exactly one
   controlling PoC server.  The controlling PoC server of an ad-hoc PoC
   group session resolves an incoming URI list and sends INVITEs to the
   members of the list.  The controlling PoC Server also functions as
   the focus of the session.  Every participant in an ad-hoc PoC group
   has an associated participating PoC server, which resides in the home
   domain of the participant.

   Figure 2 shows how the PoC servers of the PoC network behave in the
   scenario shown in Figure 1.  An originating PoC user agent sends an
   INVITE request (1) with a URI list to its participating PoC server.
   The participating PoC server of the originator receives the INVITE



Hautakorpi & Camarillo  Expires November 9, 2007                [Page 4]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


   request, assumes the role of controlling PoC server for the ad-hoc
   PoC group session, and sends an INVITE request to each of the URIs in
   the URI list.

                                              +-------------+
                              2. INVITE       | Particip.   |
                          +------------------>| PoC server  |->
                          | alice@example.com | example.com |
                          |                   +-------------+
                          |
                   +-------------+ 3. INVITE           +-------------+
                   |             |-------------------->|             |
     1. INVITE     | Controlling | friends@example.org | Particip.   |
  ---------------->| PoC server  |                     | PoC server  |->
alice@example.com  |             | 4. 403 Forbidden    | example.org |
friends@example.org|             |<--------------------|             |
                   +-------------+  bob@example.org    +-------------+
                      |      |      carol@example.net         ^
                      |      |                                |
                      |      |     5. INVITE                  |
                      |      +--------------------------------+
                      |             bob@example.org
                      |
                      |                   +------------+
                      |   6. INVITE       | Particip.  |
                      +------------------>| PoC server |->
                        carol@example.net | example.net|
                                          +------------+

                      Figure 2: PoC Network Behavior

   The first URI of the list, alice@example.com, identifies a single
   user.  The second URI of the URI list, friends@example.org,
   identifies a URI list.  In PoC terminology, friends@example.com
   identifies a pre-arranged PoC group.  The PoC server at example.org,
   which knows the membership of friends@example.com, cannot send INVITE
   requests to the members of friends@example.org because that PoC
   server does not act as a controlling PoC server for the ad-hoc PoC
   group session being established.  Instead, it informs the controlling
   PoC server that friends@example.org is a list whose members are
   bob@example.org and carol@example.net.  Upon receiving this
   information, the controlling PoC server generates INVITE requests
   towards bob@example.org and carol@example.net.

   Although not shown in the above example, based on policy, presence of
   the members, etc., the participating PoC server (example.org) can
   include just a partial list of URIs of the URI list; furthermore, a
   URI that the participating PoC server returns can be URI list.



Hautakorpi & Camarillo  Expires November 9, 2007                [Page 5]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


   At present, there is neither a mechanism for a participating PoC
   server to inform a controlling PoC server that a URI identifies a
   list and about the members of that list, nor to indicate the URIs
   contained in the list.  This document defines such a mechanism: the
   P-Refused-URI-List P-Header.


4.  Overview of Operation

   When a URI-list server receives an INVITE request with a URI list,
   some of which entries are URI lists themselves that the server cannot
   handle, it returns a 403 (Forbidden) response with a P-Refused-URI-
   List P-Header, as shown in Figure 3.  The P-Refused-URI P-Header
   contains the members of the URI list or lists that caused the
   rejection of the request.  This way, the client can send requests
   directly to those member URIs.

           +---------+        INVITE request         +----------+
           |         |------------------------------>|          |
           |         |   [URI-list in a URI-list]    | URI-list |
           | Client  |                               |  server  |
           |         |        403 Forbidden          |          |
           |         |<------------------------------|          |
           |         | [Content of refused URI-list] |          |
           +---------+                               +----------+

                      Figure 3: Operational Overview


5.  Syntax of P-Refused-URI-List Header Field

   The following is the augmented Backus-Naur Form (BNF) [4] syntax of
   the P-Refused-URI-List P-Header:

       P-Refused-URI-List = "P-Refused-URI-List" HCOLON
                                 uri-list-entry
                                 *(COMMA uri-list-entry)
       uri-list-entry     = ( name-addr / addr-spec )
                                 *( SEMI refused-param )
       refused-param      = members-param / generic-param
       members-param      = "members" EQUAL
                                 LDQUOT *( qdtext / quoted-pair ) RDQUOT

   The members P-Header parameter MUST contain a cid-url, which is
   defined in RFC 2392 [2].

   The HCOLON, SEMI, EQUAL, LDQUOT, RDQUOT, and generic-param are
   defined in [3].



Hautakorpi & Camarillo  Expires November 9, 2007                [Page 6]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


6.  Response Generation

   A 403 (Forbidden) response can contain more than one P-Refused-URI-
   List entries.  The P-Refused-URI-List header field MUST NOT be used
   with any other response.  The P-Refused-URI-List P-Header contains
   one or more URIs, which were present in the URI-list in the incoming
   request and could not be handled by the server.  Additionally, the
   P-Refused-URI-List can optionally carry some or all of the members of
   the URI lists identified by those URIs.

   The 403 (Forbidden) response MAY contain body parts which contain
   URI-lists.  Those body parts can be referenced by the P-Refused-URI-
   List entries through their Content-IDs [2].  If there is a Content-ID
   defined in the P-Refused-URI-List, one of the body parts MUST have an
   equivalent Content-ID.  The format of a URI-list is service specific.

   This kind of message structure enables clients to determine which URI
   relates to which URI-list, if the URI-list server is willing to
   disclose that information.  Furthermore, the information enclosed in
   the URI lists enable clients to take further actions to remedy the
   rejection situation (e.g., send individual requests to the members of
   the URI list).


7.  Message Sequence Example

   In the following message sequence example, a controlling PoC server
   sends an INVITE request to a participating PoC server.  The
   participating PoC server rejects the request with a 403 (Forbidden)
   response.  The 403 response has a P-Refused-URI-List P-Header that
   carries the members of the rejected URI-lists that the participating
   PoC server determines to disclose to this controlling PoC server in
   the body of the message.

           Controlling PoC server           Participating PoC server
               example.com                      example.net

                    |                                 |
                    |             INVITE              |
                    |-------------------------------->|
                    |                                 |
                    |          403 Forbidden          |
                    |<--------------------------------|
                    |                                 |

                    Figure 4: Message Sequence Example

   The INVITE request shown in Figure 4 is the following (Via header



Hautakorpi & Camarillo  Expires November 9, 2007                [Page 7]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


   fields are not shown for simplicity):

      INVITE sip:poc-service@example.net SIP/2.0
      Max-Forwards: 70
      From: PoC service <sip:poc-service@example.com>;tag=4fxaed73sl
      To: PoC service <sip:poc-service@example.net>
      Call-ID: 7xTn9vxNit65XU7p4@example.com
      CSeq: 1 INVITE
      Contact: <sip:poc-service@poc-as.example.com>
      Require: recipient-list-invite
      Content-Type: multipart/mixed;boundary="boundary1"
      Content-Length: 538

      --boundary1
      Content-Type: application/sdp

      (SDP not shown)

      --boundary1
      Content-Type: application/resource-lists+xml
      Content-Disposition: recipient-list

      <?xml version="1.0" encoding="UTF-8"?>
      <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
        <list>
          <entry uri="sip:bob@example.net"/>
          <entry uri="sip:friends-list@example.net"/>
          <entry uri="sip:colleagues-list@example.net"/>
        </list>
      </resource-lists>
      --boundary1--


   The URIs sip:friends-list@example.net and
   sip:colleagues-list@example.net in the example above are actually
   references to URI lists (i.e., pre-arranged PoC groups).  In the
   following response, the URI lists are in the XML resource list format
   [7].

   The content of the 403 (Forbidden) response in Figure 4 is the
   following (Via header fields are not shown for simplicity):










Hautakorpi & Camarillo  Expires November 9, 2007                [Page 8]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


      SIP/2.0 403 Forbidden
      From: PoC service <sip:poc-service@example.com>;tag=4fxaed73sl
      To: PoC service <sip:poc-service@example.net>;tag=814254
      Call-ID: 7xTn9vxNit65XU7p4@example.com
      CSeq: 1 INVITE
      P-Refused-URI-List: sip:friends-list@example.net;
        members=<cid:an3bt8jf03@example.net>
      P-Refused-URI-List: sip:colleagues-list@example.net;
        members=<cid:bn35n8jf04@example.net>
      Content-Type: multipart/mixed;boundary="boundary1"
      Content-Length: 745

      --boundary1
      Content-Type: application/resource-lists+xml
      Content-Disposition: recipient-list
      Content-ID: <an3bt8jf03@example.net>

      <?xml version="1.0" encoding="UTF-8"?>
      <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
        <list>
          <entry uri="sip:bill@example3.com"/>
          <entry uri="sip:randy@example2.net"/>
          <entry uri="sip:eddy@example4.com"/>
        </list>
      </resource-lists>

      --boundary1
      Content-Type: application/resource-lists+xml
      Content-Disposition: recipient-list
      Content-ID: <bn35n8jf04@example.net>

      <?xml version="1.0" encoding="UTF-8"?>
      <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
        <list>
          <entry uri="sip:joe@example3.org"/>
          <entry uri="sip:carol@example5.net"/>
        </list>
      </resource-lists>
      --boundary1--

   Using the message body of the 403 (Forbidden) response above, the
   controlling PoC server can determine the members of
   sip:friend-list@example.net and sip:colleagues-list@example.net that
   the participating PoC Server determines to disclose to this
   controlling PoC Server.  Furthermore, the controlling PoC server can
   deduce that the participating PoC server has not sent any outgoing
   requests, per regular URI-list server procedures.




Hautakorpi & Camarillo  Expires November 9, 2007                [Page 9]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


8.  Applicability

   The P-Refused-URI-list header field is intended to be used in OMA PoC
   networks.  This header field is used between PoC servers and carries
   information about those URI-lists that were rejected by the server
   receiving the request.

   The OMA PoC services is designed so that, in a given session, only
   one PoC server can resolve incoming URI lists and send INVITEs to
   members of these lists.  This restriction is not present on services
   developed to be used on the public Internet.  Therefore, the
   P-Refused-URI-List P-Header does not seem to have general
   applicability outside the OMA PoC service.

   Additionally, the use of the P-Refused-URI-List P-Header requires
   special trust relationships between servers that do not typically
   exist on the public Internet.

   It is important to note that the P-Refused-URI-List is optional and
   does not change the basic behavior of a SIP URI-list service.  The
   P-Refused-URI-List only provides clients with additional information
   about the refusal of the request.


9.  Security Considerations

   It is assumed that the network elements handling the P-Refused-URI-
   List P-Header are trusted.  Also, attackers are not supposed to have
   access to the protocol messages between those elements.  This is
   because the P-Refused-URI-List is intended to be used in the OMA PoC
   environment, which is implemented in the operators' core network; for
   more on OMA PoC security assumptions, see [9].  Traffic protection
   between network elements is achieved by using IP Security (IPsec) and
   sometimes by physically protecting the network.

   However, implementors and administrators should be aware of two
   special security consideration related to the use of P-Refused-URI-
   List:

   Eavesdropping:  403 (Forbidden) responses may contain information
      about the members of a given URI list.  Eavesdroppers can acquire
      this information if the 403 (Forbidden) responses are not
      encrypted.  Therefore it is RECOMMENDED that either hop-by-hop or
      end-to-end encryption is used.







Hautakorpi & Camarillo  Expires November 9, 2007               [Page 10]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007



   Disclosing information:  A rogue entity may be able to acquire
      information about the members of a given URI list if the URI-list
      server sends information about those URI-lists also to
      unauthorized users.  Therefore, it is RECOMMENDED that URI-list
      server discloses the content of URI-list only to authorized
      clients.


10.  IANA Considerations

   The IANA is requested to make two additions to the Session Initiation
   Protocol (SIP) Parameters registry.  The first addition is to add the
   following header field to the already existing Header Fields sub-
   registry

     Header Name        compact    Reference
     -----------------  -------    ---------
     P-Refused-URI-List            [RFCxxxx]

   The second addition is to add the following header field parameter to
   the already existing Header Field Parameters and Parameter Values
   sub-registry.

                                                  Predefined
   Header Field                  Parameter Name     Values     Reference
   ----------------------------  ---------------   ---------   ---------
   P-Refused-URI-List            members              No       [RFCxxxx]

   Note for the RFC Editor: The two occurrences of 'RFCxxxx' in the
   above should be a reference to the coming RFC number of this draft.


11.  Acknowledgements

   Authors would like to thank Tom Hiller who did a thorough, dedicated
   review for this draft.


12.  References

12.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Levinson, E., "Content-ID and Message-ID Uniform Resource
        Locators", RFC 2392, August 1998.



Hautakorpi & Camarillo  Expires November 9, 2007               [Page 11]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


   [3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [4]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [5]  Camarillo, G. and A. Roach, "Framework and Security
        Considerations for Session Initiation Protocol (SIP)  Uniform
        Resource Identifier (URI)-List Services",
        draft-ietf-sipping-uri-services-06 (work in progress),
        September 2006.

   [6]  Camarillo, G. and A. Johnston, "Conference Establishment Using
        Request-Contained Lists in the Session  Initiation Protocol
        (SIP)", draft-ietf-sip-uri-list-conferencing-01 (work in
        progress), January 2007.

12.2.  Informative References

   [7]  Rosenberg, J., "Extensible Markup Language (XML) Formats for
        Representing Resource Lists",
        draft-ietf-simple-xcap-list-usage-05 (work in progress),
        February 2005.

   [8]  "OMA PoC System Description: Draft Version 2.0", April 2007.

   [9]  "Push to talk over Cellular (PoC) - Architecture: Draft Version
        2.0", April 2007.


Authors' Addresses

   Jani Hautakorpi
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Jani.Hautakorpi@ericsson.com











Hautakorpi & Camarillo  Expires November 9, 2007               [Page 12]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com












































Hautakorpi & Camarillo  Expires November 9, 2007               [Page 13]


Internet-Draft       The P-Refused-URI-List P-Header            May 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hautakorpi & Camarillo  Expires November 9, 2007               [Page 14]