TOC 
SIPPING Working GroupS. Niccolini
Internet-DraftNEC
Intended status: Standards TrackK. Fischer
Expires: August 18, 2008Siemens Enterprise Communications
 D. Wing
 Cisco System, Inc.
 M. Stiemerling
 NEC
 H. Tschofenig
 Nokia Siemens Networks
 February 15, 2008


Spam feedback for SIP
draft-niccolini-sipping-spam-feedback-00

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 August 18, 2008.

Abstract

This document gives on overview of possible mechanisms for SIP UAs to feedback spam information to the system (e.g. other SIP entities like upstream SIP proxies) thus they can use this information for handling subsequent calls (e.g. blacklist the caller, input this info to reputation systems, compute spam-specific caller statistics, etc.).



Table of Contents

1.  Introduction
2.  SIP Spam Feedback: sending operations
    2.1.  Alternatives for sending spam feedbacks
        2.1.1.  ABNF
        2.1.2.  Event package usage
            2.1.2.1.  Overview
            2.1.2.2.  Subscribe behavior
            2.1.2.3.  Notify behavior
3.  SIP Spam Feedback: system operations
4.  Advantages and disadvantages of alternatives
5.  Additional considerations of feedback operations
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

For the purpose of SPIT prevention it would be nice to have a mechanism for users to report the fact that they received a spam call. For example, a button on the user interface of the client (either hardware or software) might empower callees to inform the system that a particular caller initiated a spam call to the callee (see also [RFC5039] (Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” January 2008.)). This information can be used in many ways depending on the configuration of the system and on user preferences (e.g. can be used to add the caller to the callee's personal black list, to inform a reputation system, to apply particular call handling to subsequent calls of such caller either making him solving a CAPTCHA before initiating new calls or making him solving a computational puzzle, etc.). The discussion on how to use the user feedback depending on the configuration of the system and on user preferences is out of the scope of this document. The scope of this document is to highlight possible alternatives how this feedback should be delivered to the system in order to make a decision how this feedback should be implemented.



 TOC 

2.  SIP Spam Feedback: sending operations

A UA generates a spam feedback after the user press the "spam" button. The spam feedback SHOULD carry information about the call and its originator. Information that are redundant SHOULD be avoided. Such information are taken into account by the system in order to apply different policies depending on system configuration or on user preferences. Examples of information about the call are, but not limited to, listed here:



 TOC 

2.1.  Alternatives for sending spam feedbacks

The authors envision two alternatives to implement the spam feedback:

Both methods have pros and cons. Discussion about which is the best alternative for the purpose of sending spam feedbacks should take place in the SIPPING WG.



 TOC 

2.1.1.  ABNF

ABNF using the ABNF syntax of [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). Such ABNF can be used to define the additional header of the BYE message or the body of the NOTIFY message.

Spam              = "Spam" HCOLON spam-value
                    ; examples:
                    ;  Spam: 1; To: Bob <sip:bob@biloxi.com>;
                    ;  From: Alice <sip:alice@atlanta.com>;
                    ;   tag=1928301774;
                    ;  Call-ID: a84b4c76e66710@pc33.atlanta.com
                    ;  ...
spam-value        = 1 *(SEMI spam-params)
spam-params       = To / From / Call-ID /
                    Call-start-val / Call-end-val /
                    Caller-sign-val / Callee-sign-val /
                    Caller-media-val / Callee-media-val /
                    Via / Route / Record-Route /
                    Alert-Info / ...
Call-start-val    = "Call-start" EQUAL date
Call-end-val      = "Call-end" EQUAL date
Caller-sign-val   = "Caller-sign" EQUAL hostport
Callee-sign-val   = "Callee-sign" EQUAL hostport
Caller-media-val  = "Caller-media" EQUAL hostport
Callee-media-val  = "Callee-media" EQUAL hostport

               Figure 1: ABNF



 TOC 

2.1.2.  Event package usage



 TOC 

2.1.2.1.  Overview

[RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) specifies an extension to SIP providing an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have been occurred. This framework can be applied to realize an notification mechanism of spam feedback from a SIP UA towards a server like a SIP proxy. A server interested in feedback if a call is considered as spit / spam by the user, subscribes to the new defined event package 'spam-feedback' at the SIP UA. After the user has pressed the "spam" button, the SIP UA notifies the server about the spam call. The NOTIFY message includes also some information to correlate the feedback with a specific call and to provide additional information. Figure 1 (Overview call flow spam feedback event mechanism) depicts the general call flow, which is explained in the following sections. Call signaling specific messages like INVITE, 18x or 200 responses are omitted from the figure for simplicity.



                                           SIP proxy /
           SIP UA                         SPAM server
             |                                |
             |   SUBSCRIBE ('spam-feedback')  |
             |<-------------------------------|
             |                                |
             |             200                |
             |------------------------------->|
             |                                |
             |    NOTIFY ('spam-feedback')    |
             |------------------------------->|
             |                                |
             |             200                |
             |<-------------------------------|
 spam button |                                |
   pressed   |                                |
     ------->|                                |
             |    NOTIFY ('spam-feedback')    |
             |------------------------------->|
             |                                |
             |             200                |
             |<-------------------------------|
             |                                |
 Figure 1: Overview call flow spam feedback event mechanism 



 TOC 

2.1.2.2.  Subscribe behavior

A SPAM / SIP server interested in spam feedback from a SIP UA sends a SUBSCRIBE request to the dedicated SIP UA. The request contains a Event header indicating that the 'spam-feedback' event package shall be subscribed. The request may contain also an Expires header indicating the duration of the subscription. If no Expires header is present, the subscription has an unlimited duration. At any time before a subscription expires, the subscriber may refresh the timer on such a subscription by sending another SUBSCRIBE request on the same dialog as the existing subscription.

On receipt of a SUBSCRIBE request the SIP UA should check that the event package specified in the Event header is understood. If not, a "489 Bad Event" response should be returned. The SIP UA should check if the requesting server is authorized to subscribe to the event package. Prior to authorization the SIP UA needs to authenticate the server. One way achieving this is to use a TLS connection to the spam / SIP server, which might be already established to protect SIP registration and call signaling. Usually, the server is authenticated during TLS handshake, e.g. by a X.509 certificate, whereas the SIP UA is authenticated by SIP digest ([RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.)) on top of TLS. TLS provides also additional security properties, which addresses the security considerations of [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) (please refer to Section 6 (Security Considerations)).

Based on the configured policy the SIP UA accepts the SUBSCRIBE request by sending a 200 response, temporarily accepts the request with a 202 response or declines it by sending a non 200 class response like "403 Forbidden" or "603 Declined".



 TOC 

2.1.2.3.  Notify behavior

After the SIP UA has accepted the subscription, a NOTIFY message is sent directly after the 200 response to indicate the initial state. The NOTIFIY Event header contains the 'spam-feedback' package name. The body should be empty, because no spam feedback needs to be notified initially. The NOTIFY message is sent over the already established TLS connection.

When a user receives a call considered as spam, he presses the "spam" button, which initiates a new NOTIFY message from the UA to the server. In contrast to the initial NOTIFY message, the body contains information about the call and its originator. Such information are taken into account by the spam system in order to apply different policies depending on system configuration or on user preferences. Refer to Section 2 (SIP Spam Feedback: sending operations) for a list of carried information.

[[Note: The concrete specification of the 'spam-feedback' event package will be added in a future version.]]



 TOC 

3.  SIP Spam Feedback: system operations

The system (e.g. a SIP proxy) that receives a notification of a certain call being spam should apply the policies defined in the system configuration and in the user preferences in order to handle subsequent calls coming from that caller. Examples of behavior include:



 TOC 

4.  Advantages and disadvantages of alternatives

We provide here a list of advantages and disadvantages in order to stimulate discussion on which technique should be used to send feedback.

Advantages for using BYE are:

Disadvantages for using BYE are:

Advantages for using NOTIFY are:

Disadvantages for using NOTIFY are:

From a first analysis the usage of NOTIFY seems to be preferred but it is up to discussion in the community to reach consensus on this topic.



 TOC 

5.  Additional considerations of feedback operations

This document does not address important considerations on how and if the system (e.g. the SIP proxy serving the UA that received the spam call) should pass the information of a certain call being spam to other upstream proxies (e.g. to the SIP proxy in the originating domain). Such considerations are out of the scope of this document. The authors envision that such discussion should take place in another draft and investigate if additional headers or error messages should be defined to report upstream proxies about a call being considered spam by a certain domain or not. Also passing spam scoring information to upstream proxies is a possibility that should be considered in such draft and the appropriate security considerations shold be applied.



 TOC 

6.  Security Considerations

Some session requests may be spam for some users but not for others, it should be clear that the feedback is not providing a general security assessment of the call being spam or of the caller being abusive, but a personal one. The system should process spam feedbacks preserving normal operations for all users without letting some "mafia" users exploiting this mechanism to create DoS attacks denying users to call. The feedback message should be therefore challenged and authentication mechanisms should be applied. Also if the spam feedback is used to blacklist caller or entire domains, it should be used very carefully.

The security considerations described in [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) are inherited and need also be considered by applying the general notification framework for spam feedback. Most of the security threats are directly addressed by an authenticated TLS connection between the notifier and the subscriber.

[[Note: Additional text regarding each threat of RFC 3265 is added in a later version ]]



 TOC 

7.  IANA Considerations

[[This section will be completed in a later version of this document.]]



 TOC 

8.  References



 TOC 

8.1. Normative References

[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 (TXT).
[RFC3265] Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, June 2002 (TXT).


 TOC 

8.2. Informative References

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617, June 1999 (TXT, HTML, XML).
[RFC5039] Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” RFC 5039, January 2008 (TXT).


 TOC 

Authors' Addresses

  Saverio Niccolini
  NEC Laboratories Europe, NEC Europe Ltd.
  Kurfuersten-Anlage 36
  Heidelberg 69115
  Germany
Phone:  +49 (0) 6221 4342 118
Email:  saverio.niccolini@nw.neclab.eu
URI:  http://www.nw.neclab.eu
  
  Kai Fischer
  Siemens Enterprise Communications GmbH & Co. KG
  Schertlinstr. 8
  Munich 81379
  Germany
Phone:  +49 (0) 89 722-37360
Email:  kai.fischer@siemens.com
  
  Dan Wing
  Cisco System, Inc.
  170 West Tasman Drive
  San Jose, CA 95134
  US
Email:  dwing@cisco.com
  
  Martin Stiemerling
  NEC Laboratories Europe, NEC Europe Ltd.
  Kurfuersten-Anlage 36
  Heidelberg 69115
  Germany
Phone:  +49 (0) 6221 4342 113
Email:  stiemerling@nw.neclab.eu
URI:  http://www.nw.neclab.eu
  
  Hannes Tschofenig
  Nokia Siemens Networks
  Otto-Hahn-Ring 6
  Munich, Bavaria 81739
  Germany
Email:  Hannes.Tschofenig@nsn.com


 TOC 

Full Copyright Statement

Intellectual Property