Spam score for SIP: a proposal for semantics
draft-seedorf-sipping-spam-score-semantics-00

Versions: 00                                                            
SIPPING Working Group                                         J. Seedorf
Internet-Draft                                              S. Niccolini
Intended status: Informational                                       NEC
Expires: August 21, 2008                                  H. Schulzrinne
                                                     Columbia University
                                                       February 18, 2008


              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.

Copyright Notice

   Copyright (C) The IETF Trust (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.



Seedorf, et al.          Expires August 21, 2008                [Page 1]


Internet-Draft          SIP spam score semantics           February 2008


Table of Contents

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





































Seedorf, et al.          Expires August 21, 2008                [Page 2]


Internet-Draft          SIP spam score semantics           February 2008


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], as well as the
   mechanisms and the rationale behind it.

   The main issues raised were:
   o  uncertainness on the appearance of the threat;
   o  unknown effectiveness of mitigation algorithms;
   o  lack of semantics and transmission of SPIT estimation scores;

   Even though the spam threat is not fully defined today, the
   recommendation of [RFC5039] 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] 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:

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




Seedorf, et al.          Expires August 21, 2008                [Page 3]


Internet-Draft          SIP spam score semantics           February 2008


   o  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:
   o  blacklist/whitelist: 0 means "not on list", 1 means "on list";
   o  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";
   o  captcha: 0 means "the caller passed the CAPTCHA test", 1 means
      "the caller did not pass the CAPTCHA test".
   o  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] 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"



Seedorf, et al.          Expires August 21, 2008                [Page 4]


Internet-Draft          SIP spam score semantics           February 2008


   could have more elaborate semantics based on statistics:
   o  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;
   o  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.
   o  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
   o  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).
   o  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



Seedorf, et al.          Expires August 21, 2008                [Page 5]


Internet-Draft          SIP spam score semantics           February 2008


   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 and it is therefore to
   be considered as legitimating the progress of the spam score draft
   [I-D.wing-spam-score] 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

   [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",
              draft-tschofenig-sipping-spit-policy-02 (work in



Seedorf, et al.          Expires August 21, 2008                [Page 6]


Internet-Draft          SIP spam score semantics           February 2008


              progress), November 2007.

   [I-D.wing-spam-score]
              Wing, D., Niccolini, S., Stiemerling, M., and H.
              Tschofenig, "Spam Score for SIP",
              draft-wing-sipping-spam-score-01 (work in progress),
              February 2008.

   [RFC5039]  Rosenberg, J. and C. Jennings, "The Session Initiation
              Protocol (SIP) and Spam", RFC 5039, January 2008.


Authors' Addresses

   Jan Seedorf
   NEC Laboratories Europe, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 (0) 6221 4342 221
   Email: seedorf@nw.neclab.eu
   URI:   http://www.nw.neclab.eu


   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


   Henning Schulzrinne
   Dept. of Computer Science, Columbia University
   1214 Amsterdam Avenue
   New York, NY  10027
   US

   Email: hgs@cs.columbia.edu








Seedorf, et al.          Expires August 21, 2008                [Page 7]


Internet-Draft          SIP spam score semantics           February 2008


Full Copyright Statement

   Copyright (C) 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Seedorf, et al.          Expires August 21, 2008                [Page 8]