One document matched: draft-wing-sipping-spam-score-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc5039 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5039.xml">
<!ENTITY I-D.tschofenig-sipping-framework-spit-reduction SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-sipping-framework-spit-reduction.xml">
<!ENTITY I-D.malas-performance-metrics SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.malas-performance-metrics.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="exp" docName="draft-wing-sipping-spam-score-02" ipr="full3978">
<front>
<title abbrev="SIP Spam Score">Spam Score for SIP</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Saverio Niccolini" initials="S." surname="Niccolini">
<organization abbrev="NEC">Network Laboratories, 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@netlab.nec.de</email>
<uri>http://www.netlab.nec.de</uri>
</address>
</author>
<author fullname="Martin Stiemerling" initials="M." surname="Stiemerling">
<organization abbrev="NEC">Network Laboratories, 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 113</phone>
<email>stiemerling@netlab.nec.de</email>
<uri>http://www.netlab.nec.de</uri>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<date year="2008" />
<workgroup>RUCUS Exploratory Working Group</workgroup>
<abstract>
<t>This document defines a mechanism for SIP proxies to communicate a
spam score to downstream SIP proxies and to SIP user agents. This
information can then be used as input to other decision making engines,
for example, to provide alternate call routing or call handling.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>It is desirable for SIP proxies to insert a spam score so that
downstream SIP proxies and downstream SIP user agents can use a high
score to decide that special handling is required. For example, a score
above 20 might cause one of the spam avoidance techniques described in
<xref target="RFC5039"></xref> to be triggered for this call.</t>
<t>This specification allows each SIP proxy to contribute spam scoring
information that can be useful to downstream SIP proxies and the SIP
user agent (UA). The downstream SIP proxies or SIP UA might ignore that
information (e.g., it doesn't trust the SIP proxy that generated the
spam score) or might use it.</t>
<t>Note that this document does not make the attempt to define how the
spam score was derived nor to distribute information that could be used
to verify the spam score generation. Furthermore, this document does not
attempt to cryptographically bind the identity of the entity generating
the score to the value itself. Hence, its usage is likely to be useful
only between neighboring administrative domains communicating such a
score.</t>
<t>One may wonder why bother marking a message that appears to be SPAM
when the same process that detected the SPAM can also automatically
block it. The answer is that contractual as well as regulatory issues
may prevent blocking and in these cases while not able to block, the
detecting proxy can nonetheless notify downstream elements of the
potential threat.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Calculation of the Spam Score">
<t>A SIP proxy evaluates an incoming SIP request and generates a spam
score using a local mechanism. In order to allow for whitelisting as
well as blacklisting the scoring is between 0 and 100, 0 indicating
absolute acceptance (e.g., whitelist), 100 indicating absolute SPAM
(e.g., blacklist) and scores between 0 and 100 can be considered to
represent the percentage likelyhood of spam.</t>
<t>The actual calculation is governed by algorithms (one example is
found in examples section below) which MAY be agreed upon by the
upstream and downstrem domains. The algorithm MAY be conveyed by the
downstream doamins to the upstream one out of band prior to the upstream
domain marking a message for transport downstream. Alternatively, a
default algorithm can be used if no alternate algorithm was established
a-priori between upstream and downstream domains. The mechanism for
conveyance of algorithm to upstream domain is out of scope for this
document but can be seen as an extension to <xref
target="I-D.tschofenig-sipping-framework-spit-reduction"></xref>.</t>
</section>
<section title="Information passed downstream">
<t>In addition to the score the following other pieces of information
should be passed downstream as well: <list>
<t>Realm - Indicating the upstream domain or realm making the
claim</t>
<t>Algorithm - The name of the agreed upon algorithm</t>
<t>Strength - An integer indicating the confidence of the score
(0-100)</t>
<t>Info - A text field containing any arbitrary information</t>
<t>Param[1..3] - 3 general purpose parameters for futureproofing</t>
<t>IsSpam - A boolean for convenience purposes alone.</t>
</list></t>
<t>The Relam is shared by all proxies in a domain and enables the
downstream proxy to determine whether or not the score is to be
trusted.</t>
<t>The Algorithm is the name of the algorithm used and can be
standardized in the same way encryption algorithm names (e.g. sha-1)
have been standardized.</t>
<t>The Strength field inidicates the confidence level of the Score. This
is generated by the same entity which generates the Score, and is an
output from the algorithim, which is based on a number of factors,
including for example volume of calls, call type etc. It is meant to
quantify the score. A calling party that makes many calls and has an
average score of 85 is preferable to calling party who made 1 or 2 calls
only and has an average score of 95.</t>
<t>Info is a text field (which can be limited to 64 bytes if we are
concerned about the MTU) that is there to provide more complete
information on the SPIT scoring etc, and can be used for diagnosis etc.
(which is useful for off line analysis reporting etc.). For example, it
could provide an explanation of the score such as is done in one
particular email spam package.</t>
<figure anchor="rule-example" title="Email Spam Rule example">
<preamble>In this email example the threshold for SPAM is 7 and this
message scored a 9.5. The sample text info below could be used to
explain how the score was calculated.</preamble>
<artwork align="center"><![CDATA[
points rule-name rule-description
------ ---------------- ------------------------------
2.5 SUBJ_CAPS Subject lind is capitalized
1.8 INLINE_GIF inline GIF detected in message
3.0 NON_PREF_LANG Non default language
2.0 HONEYPOT Honeypot address in cc
0.2 KEYWORD_MATCH suspicious words in message
]]></artwork>
<postamble></postamble>
</figure>
<t>As expected in this example, different tests have different scores
depending on their contribution to the potential of SPAM. Similarly in
the case of SPIT there can be many rules applied and having this info
can enable the receiving party to analyze the results (non realtime)</t>
<t>Params 1,2 and 3 are just general purpose placeholders (containing
Param_Desc, Param_Value pairs) for future proofing capabilities. Since
so much is still unknown about IP communications SPAM this is seen as a
wise approach.</t>
<t>Finally, as an option it may be wise to have a boolean yes/no kind of
indicator for all those downstream who do not care to know why the
upstream element assumes it is spit only that it is.</t>
</section>
<section title="Operation of Spam-Scoring Proxy">
<t>A SIP proxy evaluates an incoming SIP request and generates a spam
score using a local mechanism. This score is between 0 (indicating the
message is not spam) and 100 (indicating the message is spam). Values
between 0 and 100 indicate the 'likelihood' that the SIP request is
spam, with higher values indicating a higher likelihood the message is
spam.</t>
<t>This spam score is inserted into the new "Spam-Score" header. This
header field contains a summary spam score and optionally contains
detail information. The detail information is implementation dependent.
The detail information is valuable for debugging and to provide the SIP
user agent or SIP proxy with additional information regarding how the
spam-scoring SIP proxy's local mechanism arrived at the summary spam
score.</t>
</section>
<section title="Operation of Downtream Proxy or User Agent">
<t>A downstream proxy or the SIP user agent MAY use the spam score or
spam-detail information to change call routing or call handling. It is
envisioned that some form of policies indicate the trusted proxies in
order to decide which spam scores to consider for special call
treatment. <list>
<t>In some jurisdictions, the end user needs to authorize call
handling, including rejection of a call based on a spam score.
Mechanisms to allow users to authorize such policies are, however,
out of scope of this document.</t>
</list></t>
<t>The behavior of the SIP proxy or user agent when the spam score is
above a certain value is a local policy matter. Examples of behavior
include: <list style="symbols">
<t>a SIP request with a high spam score might cause a proxy or user
agent to redirect the SIP request to company's main telephone
extension or to the user's voicemail</t>
<t>a user agent might alert the user by flashing the phone (without
audible ringing)</t>
<t>a user agent might allow calls with a spam score below a certain
value during daylight hours, but deny such calls at night.</t>
<t>a proxy might challenge the caller to complete a Turing test.</t>
</list></t>
</section>
<section title="Grammar">
<figure anchor="ABNF" title="ABNF">
<preamble>ABNF using the ABNF syntax of <xref
target="RFC3261"></xref>:</preamble>
<artwork align="left"><![CDATA[
extension-header = "Spam-Score:" SP
spam-score *[ SP ";" spam-detail ]
spam-score = score SP "by" SP hostname
score = 1*3DIGIT [ "." 1*3DIGIT ]
spam-detail = spam-strength / spam-algorithm / spam-param
spam-algorithm = "spam-algorithm" EQUAL quoted-string
spam-strength = "spam-score-strength" EQUAL strength
strength = 1*3DIGIT [ "." 0*3DIGIT ]
spam-info = "spam-info" EQUAL info-value
info-value = quoted-string
spam-param1 = "spam-param1" EQUAL param-value
param-value = quoted-string
spam-param2 = "spam-param2" EQUAL param-value
param-value = quoted-string
spam-param3 = "spam-param3" EQUAL param-value
param-value = quoted-string
spam-isspam = [ "isSpam" ]
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section anchor="examples" title="Examples">
<figure anchor="example" title="Example with spam scores">
<preamble>The following example shows a SIP score generated and
inserted by two SIP proxies, sip.example.com and sip.example.net. In
this example, sip.example.com is owned by a spammer who is trying to
fool downstream systems with their low spam score (0). However, the
example.net proxies and user agents only pay attention to spam scores
from Spam-Score headers generated by example.net proxies, so
example.com's attempts to fool the downstream proxies (with its low
spam score) are in vain. Note also the sample Session Duration Time
(SDT) algorithm <xref
target="I-D.malas-performance-metrics">SDT</xref> simply compares the
given callers previous session duration time with the expected session
duration time over all destinations.</preamble>
<artwork align="left"><![CDATA[
INVITE sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP sip.example.net;branch=z9hG4bKnashds8
;received=192.0.2.1
Spam-Score: 75 by sip.example.net
;detail="SIPfilter-1.0;call_volume=75"
;spam-algorithm="SDT"
;spam-score-strength=50
;spam-info="High call volume"
;spam-isSpam
Via: SIP/2.0/UDP sip.example.com;branch=z9hG4bKfjzc
;received=192.0.2.127
Max-Forwards: 70
To: Bob <sip:bob@example.net>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: 142
[... SDP elided from this example...]
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>SIP proxies and SIP user agents need to ignore spam scores generated
by proxies that aren't trusted. As the spam scores are inserted along
with Via: headers, the last Via header inserted by a trusted proxy
indicates the last trusted spam score.</t>
<t>In addition, the entire issue of securing the channel between the
upstream and downstream domains MUST be addressed via mechanisms such as
TLS.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Joachim Charzinski, Daniel Quinlan, and S. Moonesamy for
their suggestions to improve this document. Thanks to David Schwartz for
his contributed text and to Eli Katz for editing assistance.</t>
</section>
<section title="IANA Considerations">
<t>[[This section will be completed in a later version of this
document.]]</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3261;
</references>
<references title="Informational References">
&rfc5039;
&I-D.tschofenig-sipping-framework-spit-reduction;
&I-D.malas-performance-metrics;
</references>
<section title="Changes">
<t>Note to RFC Editor: please remove this section prior to
publication.</t>
<section title="Changes from -00 to -01">
<t><list style="symbols">
<t>Changed scoring from positive/negative to 0-100 range.</t>
<t>Moved score from a "Via:" extension to a new header
"Spam-Score:".</t>
<t>Changed from Standards Track to Experimental.</t>
</list></t>
</section>
<section title="Changes from -01 to -02">
<t><list style="symbols">
<t>Describe how spam score could be computed</t>
<t>Added more descripive text describing how the header is passed
downstream towards the user agent</t>
</list></t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 22:22:53 |