< draft-wing-sipping-spam-score-00.txt   draft-wing-sipping-spam-score-01.txt >
Network Working Group D. Wing RUCUS Exploratory Working Group D. Wing
Internet-Draft Cisco Systems Internet-Draft Cisco
Intended status: Standards Track S. Niccolini Intended status: Experimental S. Niccolini
Expires: February 19, 2008 NEC Expires: August 16, 2008 M. Stiemerling
NEC
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
M. Stiemerling February 13, 2008
NEC
August 18, 2007
Spam Score for SIP Spam Score for SIP
draft-wing-sipping-spam-score-00.txt draft-wing-sipping-spam-score-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 19, 2008. This Internet-Draft will expire on August 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines a mechanism for SIP proxies to communicate a This document defines a mechanism for SIP proxies to communicate a
spam score to downstream SIP proxies and SIP user agents so they can spam score to downstream SIP proxies and to SIP user agents. This
provide alternate call routing or call handling. information can then be used as input to other decision making
engines, for example, to provide alternate call routing or call
Terminology handling.
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 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Operation of Spam-Scoring Proxy . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operation of Proxy or User Agent . . . . . . . . . . . . . . . 3 3. Operation of Spam-Scoring Proxy . . . . . . . . . . . . . . . . 3
4. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operation of Proxy or User Agent . . . . . . . . . . . . . . . 4
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.2. Informational References . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 10.2. Informational References . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 7
A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 9
1. Introduction 1. Introduction
It is desirable for SIP proxies to insert a spam score so that 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 downstream SIP proxies and downstream SIP user agents can use a high
score to decide that special handling is required. For example, a score to decide that special handling is required. For example, a
score above 20 might cause one of the spam avoidance techniques, score above 20 might cause one of the spam avoidance techniques
described in [I-D.ietf-sipping-spam], to be triggered for this call. described in [RFC5039] to be triggered for this call.
This specification allows each SIP proxy to contribute spam scoring This specification allows each SIP proxy to contribute spam scoring
information that can be useful to downstream SIP proxies and the SIP information that can be useful to downstream SIP proxies and the SIP
UA. The downstream SIP proxies might ignore that information (e.g., user agent (UA). The downstream SIP proxies or SIP UA might ignore
they don't trust it) or might use it (e.g., they trust it because it that information (e.g., it doesn't trust the SIP proxy that generated
was generated by a federation). the spam score) or might use it.
From a deployment point of view it is expected that the score will Note that this document does not make the attempt to define how the
most likely be benefical (and trustworthy) when inserted by a SIP spam score was derived nor to distribute information that could be
proxy on the recipients side for evaluation by a SIP UA that has a used to verify the spam score generation. Furthermore, this document
direct relationship with this SIP proxy. 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.
2. Operation of Spam-Scoring Proxy 2. Terminology
A SIP proxy generates a spam score using a local mechanism. Negative The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
scores indicate the SIP request is not considered spam, and positive "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
scores indicate the SIP request is considered spam. The higher the document are to be interpreted as described in [RFC2119].
value, the more likely a message is spam or is not spam.
This spam score is inserted into the "Via:" header, which is already 3. Operation of Spam-Scoring Proxy
generated by the proxy.
The Via header was chosen because it the Via is already correlated A SIP proxy evaluates an incoming SIP request and generates a spam
with the proxy that generated the Via header. 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.
3. Operation of Proxy or User Agent 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.
A downstream proxy MAY use the spam score or spam-detail information 4. Operation of Proxy or User Agent
to change call routing or call handling. It is RECOMMENDED that only
scores generated by trusted proxies be used. The behavior of the SIP A downstream proxy or the SIP user agent MAY use the spam score or
proxy or user agent when the spam score is above a certain value is a spam-detail information to change call routing or call handling. It
local matter. Examples of behavior include: is envisioned that some form of policies indicate the trusted proxies
in order to decide which spam scores to consider for special call
treatment.
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 influence such policies are, however,
out of scope of this document.
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:
o a SIP request with a high spam score might cause a proxy or user o 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 agent to redirect the SIP request to company's main telephone
extension or to the user's voicemail extension or to the user's voicemail
o a user agent might alert the user by flashing the phone (without o a user agent might alert the user by flashing the phone (without
audible ringing) audible ringing)
o a user agent might allow calls with a spam score below a certain o a user agent might allow calls with a spam score below a certain
value during daylight hours, but deny such calls at night. value during daylight hours, but deny such calls at night.
o a proxy might challenge the caller to complete a Turing test. o a proxy might challenge the caller to complete a Turing test.
These aspects are discussed in 5. Grammar
[I-D.tschofenig-sipping-framework-spit-reduction].
4. ABNF
ABNF using the ABNF syntax of [RFC3261]: ABNF using the ABNF syntax of [RFC3261]:
via-extension = spam-score / spam-detail extension-header = spam-score [ SP ";" spam-detail ]
spam-score = "spam" EQUAL score spam-score = score SP "by" SP hostname
score = *"-" 1*4DIGIT [ "." 0*3DIGIT ] score = 1*3DIGIT [ "." 0*3DIGIT ]
spam-detail = "spam-detail" EQUAL detail spam-detail = "detail" EQUAL detail
detail = QUOTE mech SEMI rule-score detail = QUOTE mech SEMI rule-score
*(COMMA rule-score) QUOTE *(COMMA rule-score) QUOTE
; mathematical average of the rule-scores
; MUST be same as spam-score
rule-score = rule [ "=" score ] rule-score = rule [ "=" score ]
mech = token mech = token
rule = token rule = token
Figure 1: ABNF Figure 1: ABNF
5. Examples 6. Examples
The following example shows a SIP score generated by biloxi.com and The following example shows a SIP score generated and inserted by two
atlanta.com. In this example, atlanta.com is owned by a spammer who SIP proxies, sip.example.com and sip.example.net. In this example,
is trying to fool downstream systems with their low spam score (0.0). sip.example.com is owned by a spammer who is trying to fool
However, the biloxi.com proxies and user agents only pay attention to downstream systems with their low spam score (0). However, the
spam scores from Via: headers generated by biloxi.com proxies, so example.net proxies and user agents only pay attention to spam scores
atlanta.com's attempts are in vain. 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.
INVITE sip:bob@biloxi.com SIP/2.0 INVITE sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP biloxi.com;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP sip.example.net;branch=z9hG4bKnashds8
;received=192.0.2.1 ;received=192.0.2.1
;spam=-5 Spam-Score: 75 by sip.example.net
;spam-detail="Hormel-1.0;whitelist=-10,call_volume=5" ;detail="SIPfilter-1.0;call_volume=75"
Via: SIP/2.0/UDP sip.atlanta.com;branch=z9hG4bKfjzc Via: SIP/2.0/UDP sip.example.com;branch=z9hG4bKfjzc
;received=192.0.3.2 ;received=192.0.2.127
;spam=-100
;spam-detail="Jaeger-3.3;not-a-spammer=-100"
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@biloxi.com> To: Bob <sip:bob@example.net>
From: Alice <sip:alice@atlanta.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com> Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
Figure 2: example [... SDP elided from this example...]
6. Security Considerations Figure 2: Example with spam scores
SIP proxies and SIP user agents need to ignore spam scores in Via 7. Security Considerations
headers generated by proxies that aren't trusted. Via headers have
the most recent proxy on top, so parsing for spam scores should stop
at the first Via header from a non-trusted proxy.
7. Acknowledgements SIP proxies and SIP user agents need to ignore spam scores generated
by proxies that aren't trusted.
Add your name here. [[This section will be completed in a later version of this
document.]]
8. IANA Considerations 8. Acknowledgements
This document will add new IANA registrations for new SIP headers. Thanks to Joachim Charzinski, Daniel Quinlan, and S. Moonesamy for
their suggestions to improve this document.
9. IANA Considerations
[[This section will be completed in a later version of this [[This section will be completed in a later version of this
document.]] document.]]
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
9.2. Informational References 10.2. Informational References
[I-D.ietf-sipping-spam] [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, January 2008.
Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work
in progress), July 2007.
[I-D.tschofenig-sipping-framework-spit-reduction] Appendix A. Changes
Tschofenig, H., "A Framework to tackle Spam and Unwanted
Communication for Internet Telephony", Note to RFC Editor: please remove this section prior to publication.
draft-tschofenig-sipping-framework-spit-reduction-01 (work
in progress), July 2007. A.1. Changes from -00 to -01
o Changed scoring from positive/negative to 0-100 range.
o Moved score from a "Via:" extension to a new header "Spam-Score:".
o Changed from Standards Track to Experimental.
Authors' Addresses Authors' Addresses
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
skipping to change at page 7, line 4 skipping to change at page 7, line 36
Authors' Addresses Authors' Addresses
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
Saverio Niccolini Saverio Niccolini
Network Laboratories, NEC Europe Ltd. Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 (0) 6221 4342 118 Phone: +49 (0) 6221 4342 118
Email: saverio.niccolini@netlab.nec.de Email: saverio.niccolini@netlab.nec.de
URI: http://www.netlab.nec.de URI: http://www.netlab.nec.de
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@nsn.com
Martin Stiemerling Martin Stiemerling
Network Laboratories, NEC Europe Ltd. Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 (0) 6221 4342 113 Phone: +49 (0) 6221 4342 113
Email: stiemerling@netlab.nec.de Email: stiemerling@netlab.nec.de
URI: http://www.netlab.nec.de URI: http://www.netlab.nec.de
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 8, line 45 skipping to change at page 9, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgments
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA). This document was produced
using xml2rfc v1.33pre66 (of http://xml.resource.org/) from a source
in RFC-2629 XML format.
 End of changes. 45 change blocks. 
114 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/