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

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.

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:

• caller SIP URI;
• callee SIP URI;
• Call-ID;
• call start time (exact definition of call start time has to be included);
• call end time (exact definition of call start time has to be included);
• caller signaling contact address (IP address and port);
• callee signaling contact address (IP address and port);
• caller media address (IP address and port);
• callee media address (IP address and port);
• Path Information (Via, Route, Record-Route, Path headers);
• Alert-Info (if present in the request);
• etc. (to be defined).

2.1.  Alternatives for sending spam feedbacks

The authors envision two alternatives to implement the spam feedback:

• using an additional header is inserted the BYE message, which is already generated by the UA;
• using an event package for spam feedbacks (to be defined), the system (e.g. a SIP proxy) SUSCRIBE to UA spam feedback service, the UA NOTIFY the system each time the "spam" button is pressed by the user.

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.

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

2.1.2.  Event package usage

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                |
             |<-------------------------------|
             |                                |

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".

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

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:

• insert the caller in the callee's personal blacklist;
• input the feedback to a reputation system computing the reputation of the callers;
• configure the system to apply particular actions on subsequent calls initiated by such a caller (e.g. route to voicemail, challenge with a CAPTCHA, challenge with a computational puzzle, etc.)

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:

• the mechanism can piggyback on a message that is already present and that the UA is sending anyway;
• it gives users a positive feeling/knowledge (if realized using a special button) that there is a special entity in the network that takes care of spam information (other than the proxy only) and (theoretically) will do something useful with it.

Disadvantages for using BYE are:

• the mechanisms has to be piggybacked on the BYE; this means the user has to decide if the call is spam at the same time the user terminates the call. This could be difficult with some user interfaces;
• the feedback information can in principle be routed upstream to a SIP proxy that can make use of it (if the sender proxy is the one controlled by the spammer this would mean giving him information on how the call was evaluated). Thus it is necessary to strip feedback information when the BYE leaves the caller's administrative domain (this puts additional load on the proxy). Failure to strip that information will allow the caller to realize if their call was marked as spam by the called party (privacy and security risk).

Advantages for using NOTIFY are:

• feedback information is sent only to SIP proxy or other special devices that are the intended recipients of such a message and that can make use of it;
• it can be delivered after the BYE (e.g. using a special dialing sequence;
• there is no need to require header stripping at the network administrative boundary;
• it is easier (with respect ot the usage of BYE) to authorize the mechanisms;
• it gives users a positive feeling/knowledge that there is a special entity in the network that takes care of spam information (other than the proxy only) and (theoretically) will do something useful with it

Disadvantages for using NOTIFY are:

• it requires an additional message;
• it requires additional infrastructural devices to be deployed (even if their introduction would not be too difficult since they are orthogonal to the signalling path).

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.

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.

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 ]]

7.  IANA Considerations

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

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © 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.