Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)
RFC 4453

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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]
RFC 4453                  Consent Requirements                April 2006

   For MESSAGE requests, the content of the message is usually rendered
   to the user.

   SUBSCRIBE [4] requests do not normally get delivered to the user