Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services
RFC 5363
|
| Document |
Type |
|
RFC - Proposed Standard
(October 2008; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5363 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Jon Peterson
|
|
Send notices to |
|
(None)
|
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].
Show full document text