Spam score for SIP: a proposal for semantics
draft-seedorf-sipping-spam-score-semantics-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 21, 2008.

Abstract

This document reports a proposal for semantics of SIP spam scoring in order to achieve a flexible signalling standardization allowing an incremental adoption of the scoring mechanism. This approach can give early experimental implementers the possibility to start using spam scoring extensions in an explorative fashion without running into interoperability problems.

Table of Contents

1.  Introduction
2.  SIP spam score semantics proposal
    2.1.  Proposal motivation
    2.2.  Proposal details
    2.3.  Examples of combinations of SIP spam scores
3.  Objective of the proposal
4.  SPIT mitigation mechanisms overview and feasibility study
5.  Security Considerations
6.  IANA Considerations
7.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

Latest discussion in the IETF demonstrated that there is still a lack of consensus how to address the general topic of SPIT mitigation. In particular, many controversial discussions have been centered around the SIP spam score draft [I‑D.wing‑spam‑score] (Wing, D., Niccolini, S., Stiemerling, M., and H. Tschofenig, “Spam Score for SIP,” February 2008.), as well as the mechanisms and the rationale behind it.

The main issues raised were:

• uncertainness on the appearance of the threat;
• unknown effectiveness of mitigation algorithms;
• lack of semantics and transmission of SPIT estimation scores;

Even though the spam threat is not fully defined today, the recommendation of [RFC5039] (Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” January 2008.) is to not wait until it is too late (i.e., providers should not ignore the spam problem until it happens); there is the need for some work in this area.

Even if [RFC5039] (Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” January 2008.) indicated a possible path, spam is such a multifaced problem that this cannot be regarded as the only one; multiple paths must be explored and standardization bodies should give implementers the possibility to experiment with solutions before the problem gets too big (as it got in the email case).

Given that something needs to be done, this document details a proposal for dealing with the remaining two issues, namely how to give implementers a chance to start experimenting with SPIT mitigation mechanisms and to communicate spam score results across different entities in the network in an interoperable and incremental way.

2.  SIP spam score semantics proposal

2.1.  Proposal motivation

The main points that motivated us to write such a proposal and made us believe that spam score is an important mechanisms for spam mitigation were:

• Whether a message is spam or not is not a binary proposition, both in terms of identifying it (mechanisms will have false positives and false negatives) and even in judging it (e.g., depending on user preferences).
• Different SIP routing elements have different types of information available that are useful for spam identification, but are not necessarly the ones that should be making call handling decisions.
• End systems or user services implemented in proxies should be judging this information and make a decision as to how to handle the call, i.e, whether to reject, forward or present the call to the user and what user interface indications to provide to the user.

For interoperability of such spam scores being exchanged among SIP entities it is absolutely necessary to have semantics defined. If no clear semantics are defined for spam scores, there is the risk of entities falsely interpreting scores they receive. Since every SPIT mitigation technique works differently, we propose to have semantics defined "per-method" and not in general.

2.2.  Proposal details

We propose to have SIP signalling extensions allowing the binding of SIP spam scores to well defined semantics. Such a solution would allow the possibility of making network-wide distributed decisions across multiple entities involved in SPIT mitigation decisions.

Even though spam is not a binary proposition, some currently suggested mitigation mechanisms give a 0/1 result when being applied to a message. Still, such an outcome is only an indicator for a message being spam or not. Defining semantics for SPIT mitigation mechanisms with such a 0/1 output (i.e., a binary output) is a matter of assigning 0 and 1 to specified outputs.

Thus, methods giving a "binary output" can have very straightforward semantics:

• blacklist/whitelist: 0 means "not on list", 1 means "on list";
• timecontext: 0 means "the caller initiated a session inside the user-defined interval for receiving calls", 1 means "the caller initiated a session inside the user-defined interval for receiving calls";
• captcha: 0 means "the caller passed the CAPTCHA test", 1 means "the caller did not pass the CAPTCHA test".
• etc.

Each binary method would need to standardize the "methodID" (e.g., the name) and the corresponding "semantic" (the meaning of 0/1, respectively). In principle, these methods could well be mapped to policies, see [I‑D.tschofenig‑sipping‑spit‑policy] (Tschofenig, H., Wing, D., Schulzrinne, H., Froment, T., and G. Dawirs, “A Document Format for Expressing Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony,” July 2008.) and reference within.

Other mechanisms currently proposed for SPIT mitigation have a more detailed output (which still only gives an indication for SPIT). These mechanisms need well-defined semantics as a basis for interoperability as well. Such methods giving a "non-binary output" could have more elaborate semantics based on statistics:

• statistics based on user feedback; such methods would give an estimation of a score x that could be the percentage of messages with the same method-result that were marked as SPIT by users;
• statistics based on anomaly detection; such methods would give an estimation of a score x that could be the percentage of previous messages were below/above (depending on the method) the result for this method compared to the current message.
• etc.

Also in this case, each non-binary method would need to standardize the "methodID" (e.g., the name) and the corresponding "semantic" (the meaning of the x score).

The proposal allows a per-method score in order to have different methods with different ranges. This flexibility enables the use of new detection methods without changing the standard which defines the SPIT estimation scores. In addition, methods can report the parameters used for computation (e.g., the call-rate method could have a parameter defining the length of the time-frame used as a basis for the score in milliseconds). Also these parameters would need to be agreed and standardized together with the methodID and the semantics.

In principle a single node can append a number of scores equal to the number of mechanisms that it applied to the message.

Once such semantics are defined and standardized it would be easy to start experimenting with these extensions avoiding interoperability problems.

2.3.  Examples of combinations of SIP spam scores

Examples of combinations of SIP spam scores would be

• an ingress spam filter performs call rate analysis and appends a score, a filter near the callee's UA combines this knowledge with the callee's black and white lists (using a secret magic algorithm that is completely out of the scope of standardization discussion).
• an ingress spam filter performs call rate analysis and appends a score, a filter near the proxy server of the callee perform a CAPTCHA test because the call rate score was suspicious, the final decision is taken by the UA based on the time of the day taking into account the previous tests performed (the final filter is on the UA).

In these examples we assume a multi-operator and multi-vendor scenario where the spam score semantics would play a fundamental role.

3.  Objective of the proposal

The objective of the proposal is to show a solution space to the issues raised in the SPIT mitigation discussion recently happening in the IETF.

This proposal would allow standardization of SIP spam scoring extensions that could be standardized and adopted incrementally giving early experimental implementers the possibility to start using spam scoring extensions in an explorative fashion without running into interoperability problems.

According to the authors' opinion this proposal allows to address all the three issues raised in section Section 1 (Introduction) and it is therefore to be considered as legitimating the progress of the spam score draft [I‑D.wing‑spam‑score] (Wing, D., Niccolini, S., Stiemerling, M., and H. Tschofenig, “Spam Score for SIP,” February 2008.) inside IETF.

4.  SPIT mitigation mechanisms overview and feasibility study

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

5.  Security Considerations

There are issues related to integrity, confidentiality, and trust of SPIT-related information, but they are not direclty related to the definition of semantics for SIP spam score mechanisms.

6.  IANA Considerations

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

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