Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)
RFC 4453
|
| Document |
Type |
|
RFC - Informational
(April 2006; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4453 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Allison Mankin
|
|
Send notices to |
|
rohan@ekabal.com
|
Network Working Group J. Rosenberg
Request for Comments: 4453 Cisco Systems
Category: Informational G. Camarillo, Ed.
Ericsson
D. Willis
Cisco Systems
April 2006
Requirements for Consent-Based Communications
in the Session Initiation Protocol (SIP)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) supports communications across
many media types, including real-time audio, video, text, instant
messaging, and presence. In its current form, it allows session
invitations, instant messages, and other requests to be delivered
from one party to another without requiring explicit consent of the
recipient. Without such consent, it is possible for SIP to be used
for malicious purposes, including spam and denial-of-service attacks.
This document identifies a set of requirements for extensions to SIP
that add consent-based communications.
Table of Contents
1. Introduction ....................................................2
2. Problem Statement ...............................................2
3. Requirements ....................................................4
4. Security Considerations .........................................5
5. References ......................................................6
5.1. Normative References .......................................6
5.2. Informational References ...................................6
Rosenberg, et al. Informational [Page 1]
RFC 4453 Consent Requirements April 2006
1. Introduction
The Session Initiation Protocol (SIP) [1] supports communications
across many media types, including real-time audio, video, text,
instant messaging, and presence. This communication is established
by the transmission of various SIP requests (such as INVITE and
MESSAGE [3]) from an initiator to the recipient, with whom
communication is desired. Although a recipient of such a SIP request
can reject the request, and therefore decline the session, a SIP
network will deliver a SIP request to the recipient without their
explicit consent.
Receipt of these requests without explicit consent can cause a number
of problems in SIP networks. These include amplification attacks.
These problems have plagued email. At the time of this writing, most
SIP services are not interconnected, so the incidence of
amplification attacks directed at SIP services is low compared to the
same attacks on email services. The SIPPING working group believes
it is necessary to address these attacks proactively so the attacks
do not become as burdensome as attacks on email have become.
This document elaborates on the problems posed by the current open
model in which SIP was designed, and then goes on to define a set of
requirements for adding a consent framework to SIP.
2. Problem Statement
In SIP networks designed according to the principles of RFC 3261 [1]
and RFC 3263 [2], anyone on the Internet can create and send a SIP
request to any other SIP user, by identifying that user with a SIP
Uniform Resource Identifier (URI). The SIP network will usually
deliver this request to the user identified by that URI. It is
possible, of course, for network services, such as call screening, to
block such messaging from occurring, but this is not widespread and
certainly not a systematic solution to the problem under
consideration here.
Once the SIP request is received by the recipient, the user agent
typically takes some kind of automated action to alert the user about
receipt of the message. For INVITE requests, this usually involves
delivering an audible alert (e.g., "ringing the phone"), or a visual
alert (e.g., creating a screen pop-up window). These indicators
frequently convey the subject of the call and the identity of the
caller. Due to the real-time nature of the session, these alerts are
typically disruptive in nature, so as to get the attention of the
user.
Rosenberg, et al. Informational [Page 2]
Show full document text