GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5363

Network Working Group G. Camarillo Request for Comments: 5363 Ericsson Category: Standards Track A.B. Roach

                                                               Tekelec
                                                          October 2008
             Framework and Security Considerations for
        Session Initiation Protocol (SIP) URI-List Services

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Abstract

 This document describes the need for SIP URI-list services and
 provides requirements for their invocation.  Additionally, it defines
 a framework for SIP URI-list services, which includes security
 considerations applicable to these services.

Table of Contents

 1. Introduction ....................................................2
 2. Terminology .....................................................2
 3. Requirements ....................................................2
    3.1. Requirements for URI-List Services Using
         Request-Contained Lists ....................................3
    3.2. General Requirements for URI-List Services .................3
 4. Framework .......................................................3
    4.1. Carrying URI Lists in SIP ..................................3
    4.2. Processing of URI Lists ....................................4
    4.3. Results ....................................................5
 5. Security Considerations .........................................5
    5.1. List Integrity and Confidentiality .........................5
    5.2. Amplification Attacks ......................................5
    5.3. General Issues .............................................7
 6. IANA Considerations .............................................7
 7. Acknowledgements ................................................8
 8. References ......................................................8
    8.1. Normative References .......................................8
    8.2. Informative References .....................................8

Camarillo & Roach Standards Track [Page 1] RFC 5363 Framework for SIP URI-List Services October 2008

1. Introduction

 Some applications require that, at a given moment, a SIP [RFC3261] UA
 (User Agent) performs a similar transaction with a number of remote
 UAs.  For example, an instant messaging application that needs to
 send a particular message (e.g., "Hello folks") to n receivers needs
 to send n MESSAGE requests; one to each receiver.
 When the transaction that needs to be repeated consists of a large
 request, or when the number of recipients is high, or both, the
 access network of the UA needs to carry a considerable amount of
 traffic.  Completing all the transactions on a low-bandwidth access
 would require a long time.  This is unacceptable for a number of
 applications.
 A solution to this problem consists of introducing URI-list services
 in the network.  The task of a SIP URI-list service is to receive a
 request that contains or references a URI list (i.e., a list of one
 or more URIs) and send a number of similar requests to the
 destinations in this list.  Once the requests are sent, the URI-list
 service typically informs the UA about their status.  Effectively,
 the URI-list service behaves as a B2BUA (Back-to-Back-User-Agent).
 A given URI-list service can take as an input a URI list contained in
 the SIP request sent by the client or an external URI list (e.g., the
 Request-URI is a SIP URI that is associated with a URI list at the
 server).  External URI lists are typically set up using out-of-band
 mechanisms (e.g., XML Configuration Access Protocol (XCAP)
 [RFC4825]).  An example of a URI-list service for SUBSCRIBE requests
 that uses stored URI lists is described in [RFC4662].
 The remainder of this document provides requirements and a framework
 for URI-list services using request-contained URI lists, external URI
 lists, or both.

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 [RFC2119].

3. Requirements

 Section 3.1 discusses requirements that only apply to URI-list
 services that use request-contained lists, and Section 3.2 discusses
 requirements that also apply to services using external lists.

Camarillo & Roach Standards Track [Page 2] RFC 5363 Framework for SIP URI-List Services October 2008

3.1. Requirements for URI-List Services Using Request-Contained Lists

 REQ 1:  The URI-list service invocation mechanism MUST allow the
         invoker to provide a list of destination URIs to the URI-list
         service.
 REQ 2:  The invocation mechanism SHOULD NOT require more than one
         transaction.

3.2. General Requirements for URI-List Services

 GEN 1:  A URI-list service MAY include services beyond sending
         requests to the URIs in the URI list.  That is, URI-list
         services can be modeled as application servers.  For example,
         a URI-list service handling INVITE requests may behave as a
         conference server and perform media mixing for all the
         participants.
 GEN 2:  The interpretation of the meaning of the URI list sent by the
         invoker MUST be at the discretion of the application to which
         the list is sent.
 GEN 3:  It MUST be possible for the invoker to find out about the
         result of the operations performed by the URI-list service
         with the URI list.  An invoker may, for instance, be
         interested in the status of the transactions initiated by the
         URI-list service.
 GEN 4:  URI-list services MUST NOT send requests to any destination
         without authenticating the invoker.

4. Framework

 This framework is not restricted to application servers that only
 provide request fan-out services.  Per GEN 1, this framework also
 deals with application servers that provide a particular service that
 includes a request fan-out (e.g., a conference server that INVITEs
 several participants that are chosen by a user agent).

4.1. Carrying URI Lists in SIP

 The requirements related to URI-list services that use request-
 contained lists identify the need for a mechanism to provide a SIP
 URI-list service with a URI list in a single transaction.  We define
 a new disposition type [RFC2183] for the Content-Disposition header
 field: recipient-list.  Both requests and responses MAY carry

Camarillo & Roach Standards Track [Page 3] RFC 5363 Framework for SIP URI-List Services October 2008

 recipient-list bodies.  Bodies whose disposition type is recipient-
 list carry a list of URIs that contains the final recipients of the
 requests to be generated by a URI-list service.
 The default format for recipient-list bodies is service specific.
 So, URI-list services specifications MUST specify a default format
 for recipient-list bodies used within a particular service.  In any
 case, clients SHOULD NOT include any particular URI more than once in
 a given URI list.
 A UA server receiving a request with more than one recipient-list
 body parts (e.g., each body part using a different URI-list format)
 MUST behave as if it had received a single URI list that contains all
 the URIs present in the different body parts.
 A UA server receiving a recipient-list URI list that contains a URI
 more than once MUST behave as if that URI appeared in the URI list
 only once.  The UA server uses the comparison rules specific to the
 URI scheme of each of the URIs in the URI list to determine if there
 is any URI that appears more than once.  Additionally, Section 4 of
 "Extensible Markup Language (XML) Format Extension for Representing
 Copy Control Attributes in Resource Lists" [RFC5364] discusses cases
 where duplicated URI entries are tagged with different values of the
 'copyControl' attribute.  Naturally, URI-list services using the
 'copyControl' attribute defined in [RFC5364] need to follow the
 recommendations in [RFC5364] with respect to avoiding sending
 duplicated requests.
 The way a UA server interprets a URI list that it has received is
 service specific, as described in Section 4.2.

4.2. Processing of URI Lists

 According to GEN 1 and GEN 2, URI-list services can behave as
 application servers.  That is, taking a URI list as an input, they
 can provide arbitrary services.  So, the interpretation of the URI
 list by the server depends on the service to be provided.  For
 example, for a conference server, the URIs in the list may identify
 the initial set of participants.  On the other hand, for a server
 dealing with MESSAGEs, the URIs in the list may identify the
 recipients of an instant message.
 At the SIP level, this implies that the behavior of application
 servers receiving requests with URI lists SHOULD be specified on a
 per-service basis.  Examples of such specifications are [RFC5366] for
 INVITE, [RFC5365] for MESSAGE, and [RFC5367] for SUBSCRIBE.

Camarillo & Roach Standards Track [Page 4] RFC 5363 Framework for SIP URI-List Services October 2008

4.3. Results

 According to GEN 3, user agents should have a way to obtain
 information about the operations performed by the application server.
 Since these operations are service specific, the way user agents are
 kept informed is also service specific.  For example, a user agent
 establishing an ad hoc conference with an INVITE with a URI list may
 discover which participants were successfully brought into the
 conference by using the conference package [RFC4575].

5. Security Considerations

 Security plays an important role in the implementation of any URI-
 list service.  In fact, it is the most important common area across
 all types of URI-list services.
 By definition, a URI-list service takes one request in and sends a
 potentially large number of them out.  Attackers may attempt to use
 URI-list services as traffic amplifiers to launch DoS (denial-of-
 service) attacks.  This section provides guidelines to avoid these
 attacks.

5.1. List Integrity and Confidentiality

 Attackers may attempt to modify URI lists sent from clients to
 servers.  This would cause a different behavior at the server than
 expected by the client (e.g., requests being sent to different
 recipients than the ones specified by the client).  To prevent this
 attack, clients SHOULD integrity protect URI lists using end-to-end
 mechanisms such as S/MIME or, if not available, hop-by-hop mechanisms
 such as TLS.  Both S/MIME and TLS can also provide URI-list
 confidentiality if needed.

5.2. Amplification Attacks

 URI-list services take a request in and send a potentially large
 number of them out.  Given that URI-list services are typically
 implemented on top of powerful servers with high-bandwidth access
 links, we should be careful to keep attackers from using them as
 amplification tools to launch DoS attacks.
 Attackers may attempt to send a URI list containing URIs whose host
 parts route to the victims of the DoS attack.  These victims do not
 need to be SIP nodes; they can be non-SIP endpoints or even routers.
 If this attack is successful, the result is that an attacker can
 flood a set of nodes, or a single node, with traffic without needing
 to generate a high volume of traffic itself.

Camarillo & Roach Standards Track [Page 5] RFC 5363 Framework for SIP URI-List Services October 2008

    In any case, note that this problem is not specific to SIP URI-
    list services; it also appears in scenarios that relate to
    multihoming where a server needs to contact a set of IP addresses
    provided by a client.
 There are several measures that need to be taken to prevent this type
 of attack.  The first one is keeping unauthorized users from using
 URI-list services.  So, URI-list services MUST NOT perform any
 request explosion for an unauthorized user.  URI-list services MUST
 authenticate users and check whether they are authorized to request
 the service before performing any request fan-out.
 Note that the risk of this attack also exists when a client uses
 stored URI lists.  Application servers MUST use authentication and
 authorization mechanisms with equivalent security properties when
 dealing with stored and request-contained URI lists.
 Even though the previous rule keeps unauthorized users from using
 URI-list services, authorized users may still launch attacks using
 these services.  To prevent these attacks, we introduce the concept
 of opt-in lists.  That is, URI-list services should not allow a
 client to place a user (identified by his or her URI) in a URI list
 unless the user has previously agreed to be placed in such a URI
 list.  So, URI-list services MUST NOT send a request to a destination
 that has not agreed to receive requests from the URI-list service
 beforehand.  Users can agree to receive requests from a URI-list
 service in several ways, such as filling a web page, sending an
 email, signing a contract, or using "A Framework for Consent-Based
 Communications in the Session Initiation Protocol (SIP)" [RFC5360],
 whose requirements are discussed in [RFC4453].  Additionally, users
 MUST be able to further describe the requests they are willing to
 receive.  For example, a user may only want to receive requests from
 a particular URI-list service on behalf of a particular user.
 Effectively, these rules make URI lists that used by URI-list
 services into opt-in lists.
 When a URI-list service receives a request with a URI list from a
 client, the URI-list service checks whether all the destinations have
 agreed beforehand to receive requests from the service on behalf of
 this client.  If the URI list has permission to send requests to all
 of the targets in the request, it does so.  If not, it does not send
 any request at all.
 The Framework for Consent-Based Communications in SIP [RFC5360]
 specifies a means for the URI-list service to inform the client that
 some permissions were missing and how to request them.

Camarillo & Roach Standards Track [Page 6] RFC 5363 Framework for SIP URI-List Services October 2008

    Note that the mechanism used to obtain permissions should not
    create opportunities to launch DoS amplification attacks.  These
    attacks would be possible if, for instance, the URI-list service
    automatically contacted the full set of targets for which it did
    not have permissions in order to request permissions.  The URI-
    list service would be receiving one SIP request and sending out a
    number of authorization request messages.  The Framework for
    Consent-Based Communications in SIP [RFC5360] avoids this type of
    attack by having the client generate roughly the same amount of
    traffic towards the URI-list service as the service generates
    towards the destinations.
 In order to have an interoperable way to meet the requirements
 related to opt-in lists described in this section, URI-list services
 MUST implement and SHOULD use "A Framework for Consent-Based
 Communications in SIP" [RFC5360].

5.3. General Issues

 URI-list services MAY have policies that limit the number of URIs in
 the lists they accept, as a very long list could be used in a
 denial-of-service attack to place a large burden on the URI-list
 service to send a large number of SIP requests.
 A URI-list service generates a set of requests from a URI list.
 Section 19.1.5 of [RFC3261] provides recommendations that need to be
 taken into consideration when forming a request from a URI.
 Naturally, those recommendations apply to all SIP URI-list services.
 The general requirement GEN 4, which states that URI-list services
 need to authenticate their clients, and the previous rules apply to
 URI-list services in general.  In addition, specifications dealing
 with individual methods MUST describe the security issues that relate
 to each particular method.

6. IANA Considerations

 This document defines a new Content-Disposition header field
 disposition type (recipient-list) in Section 4.1.  This value has
 been registered in the IANA registry for Mail Content Disposition
 Values and Parameters with the following description:
 recipient-list    The body includes a list of URIs to which URI-list
                   services are to be applied.

Camarillo & Roach Standards Track [Page 7] RFC 5363 Framework for SIP URI-List Services October 2008

7. Acknowledgements

 Duncan Mills and Miguel A. Garcia-Martin supported the idea of 1 to n
 MESSAGE requests.  Jon Peterson, Dean Willis, and Jonathan Rosenberg
 provided useful comments.

8. References

8.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
            Presentation Information in Internet Messages: The
            Content-Disposition Header Field", RFC 2183, August 1997.
 [RFC3261]  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.
 [RFC5360]  Rosenberg, J., Camarillo, G., Ed., and D. Willis, "A
            Framework for Consent-Based Communications in the Session
            Initiation Protocol (SIP)", RFC 5360, October 2008.

8.2. Informative References

 [RFC4453]  Rosenberg, J., Camarillo, G., and D. Willis, "Requirements
            for Consent-Based Communications in the Session Initiation
            Protocol (SIP)", RFC 4453, April 2006.
 [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
            Initiation Protocol (SIP) Event Package for Conference
            State", RFC 4575, August 2006.
 [RFC4662]  Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
            Initiation Protocol (SIP) Event Notification Extension for
            Resource Lists", RFC 4662, August 2006.
 [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)
            Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
 [RFC5364]  Garcia-Martin, M. and G. Camarillo, "Extensible Markup
            Language (XML) Format Extension for Representing Copy
            Control Attributes in Resource Lists", RFC 5364, October
            2008.

Camarillo & Roach Standards Track [Page 8] RFC 5363 Framework for SIP URI-List Services October 2008

 [RFC5365]  Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
            MESSAGE Requests in the Session Initiation Protocol
            (SIP)", RFC 5365, October 2008.
 [RFC5366]  Camarillo, G. and A. Johnston, "Conference Establishment
            Using Request-Contained Lists in the Session Initiation
            Protocol (SIP)", RFC 5366, October 2008.
 [RFC5367]  Camarillo, G., Roach, A.B., and O. Levin, "Subscriptions
            to Request-Contained Resource Lists in the Session
            Initiation  Protocol (SIP)", RFC 5367, October 2008.

Authors' Addresses

 Gonzalo Camarillo
 Ericsson
 Hirsalantie 11
 Jorvas  02420
 Finland
 EMail: Gonzalo.Camarillo@ericsson.com
 Adam Roach
 Tekelec
 17210 Campbell Rd Ste 250
 Dallas, TX  75252
 USA
 EMail: Adam.Roach@tekelec.com

Camarillo & Roach Standards Track [Page 9] RFC 5363 Framework for SIP URI-List Services October 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 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.

Camarillo & Roach Standards Track [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5363.txt · Last modified: 2008/10/27 20:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki