One document matched: draft-seedorf-sipping-spam-score-semantics-00.xml
<?xml version="1.0"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc5039 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5039.xml'>
<!ENTITY I-D.tschofenig-sipping-spit-policy PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-sipping-spit-policy.xml'>
]>
<rfc ipr="full3978" docName="draft-seedorf-sipping-spam-score-semantics-00" category="info">
<front>
<title abbrev="SIP spam score semantics">Spam score for SIP: a proposal for semantics</title>
<author initials="J." surname="Seedorf" fullname="Jan Seedorf">
<organization abbrev="NEC">NEC Laboratories Europe, NEC Europe
Ltd.</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<phone>+49 (0) 6221 4342 221</phone>
<email>seedorf@nw.neclab.eu</email>
<uri>http://www.nw.neclab.eu</uri>
</address>
</author>
<author initials="S." surname="Niccolini" fullname="Saverio Niccolini">
<organization abbrev="NEC">NEC Laboratories Europe, NEC Europe Ltd.</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<phone>+49 (0) 6221 4342 118</phone>
<email>saverio.niccolini@nw.neclab.eu</email>
<uri>http://www.nw.neclab.eu</uri>
</address>
</author>
<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization abbrev="Columbia University">Dept. of Computer Science, Columbia
University</organization>
<address>
<postal>
<street>1214 Amsterdam Avenue</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<email>hgs@cs.columbia.edu</email>
</address>
</author>
<!--<author fullname="Dan Wing" initials="D." surname="Wing">
<organization>Cisco System, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>-->
<!--<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich, Bavaria</city>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
</address>
</author>-->
<date month="February" year="2008"/>
<area>Real-time Applications and Infrastructure</area>
<workgroup>SIPPING Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>SPIT</keyword>
<keyword>SPam over Internet Telephony</keyword>
<keyword>Feedback</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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 <xref target="I-D.wing-spam-score"/>, as well as the mechanisms
and the rationale behind it.</t>
<t>The main issues raised were:
<list style="symbols">
<t>uncertainness on the appearance of the threat;</t>
<t>unknown effectiveness of mitigation algorithms;</t>
<t>lack of semantics and transmission of SPIT estimation scores;</t>
</list>
</t>
<t>Even though the spam threat is not fully defined today, the
recommendation of <xref target="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.</t>
<t>Even if <xref target="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).</t>
<t>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.</t>
</section>
<section anchor="spam-semantics" title="SIP spam score semantics proposal">
<section anchor="core" title="Proposal motivation">
<t>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:</t>
<t>
<list style="symbols">
<t>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).</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>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.</t>
</section>
<section anchor="details" title="Proposal details">
<t>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.</t>
<t>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.</t>
<t>Thus, methods giving a "binary output" can have very straightforward semantics:
<list style="symbols">
<t>blacklist/whitelist: 0 means "not on list", 1 means "on list";</t>
<t>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";</t>
<t>captcha: 0 means "the caller passed the CAPTCHA test", 1 means "the
caller did not pass the CAPTCHA test".</t>
<t>etc.</t>
</list>
</t>
<t>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 <xref target="I-D.tschofenig-sipping-spit-policy" />
and reference within.</t>
<t>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:
<list style="symbols">
<t>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;</t>
<t>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.</t>
<t>etc.</t>
</list>
</t>
<t>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).</t>
<t>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.</t>
<t>In principle a single node can append a number of scores equal to the number of
mechanisms that it applied to the message.</t>
<t>Once such semantics are defined and standardized it would be easy to start
experimenting with these extensions avoiding interoperability problems.</t>
</section>
<section anchor="examples" title="Examples of combinations of SIP spam scores">
<t>Examples of combinations of SIP spam scores would be
<list style="symbols">
<t>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).</t>
<t>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).</t>
</list>
</t>
<t>In these examples we assume a multi-operator and multi-vendor scenario where the
spam score semantics would play a fundamental role.</t>
</section>
</section>
<section anchor="proposal-objective" title="Objective of the proposal">
<t>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.</t>
<t>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.</t>
<t>According to the authors' opinion this proposal allows to address all the
three issues raised in section <xref target="intro"/> and it is therefore to be considered
as legitimating the progress of the spam score draft <xref target="I-D.wing-spam-score"/> inside
IETF.</t>
</section>
<section anchor="spam-mech" title="SPIT mitigation mechanisms overview and feasibility
study">
<t>[[This section will be completed in a later version of this document.]]</t>
</section>
<section anchor="security" title="Security Considerations">
<t>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.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>[[This section will be completed in a later version of this document.]]</t>
</section>
</middle>
<back>
<references title='Informative References'>
&rfc5039;
&I-D.tschofenig-sipping-spit-policy;
<reference anchor="I-D.wing-spam-score">
<front>
<title>Spam Score for SIP</title>
<author initials="D." surname="Wing" fullname="D. Wing">
<organization abbrev="Cisco"></organization>
</author>
<author initials="S." surname="Niccolini" fullname="S. Niccolini">
<organization abbrev="NEC"></organization>
</author>
<author initials="M." surname="Stiemerling" fullname="M. Stiemerling">
<organization abbrev="NEC"></organization>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization abbrev="Nokia Siemens Networks"></organization>
</author>
<date month="February" year="2008"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-wing-sipping-spam-score-01"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:40:13 |