idnits 2.17.1 draft-wing-sipping-spam-score-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 458. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 169 has weird spacing: '... points rule-...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2008) is 5905 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-tschofenig-sipping-framework-spit-reduction-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RUCUS Exploratory Working Group D. Wing 3 Internet-Draft Cisco 4 Intended status: Experimental S. Niccolini 5 Expires: August 26, 2008 M. Stiemerling 6 NEC 7 H. Tschofenig 8 Nokia Siemens Networks 9 February 23, 2008 11 Spam Score for SIP 12 draft-wing-sipping-spam-score-02 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 26, 2008. 39 Abstract 41 This document defines a mechanism for SIP proxies to communicate a 42 spam score to downstream SIP proxies and to SIP user agents. This 43 information can then be used as input to other decision making 44 engines, for example, to provide alternate call routing or call 45 handling. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Calculation of the Spam Score . . . . . . . . . . . . . . . . 3 52 4. Information passed downstream . . . . . . . . . . . . . . . . 4 53 5. Operation of Spam-Scoring Proxy . . . . . . . . . . . . . . . 5 54 6. Operation of Downtream Proxy or User Agent . . . . . . . . . . 6 55 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 58 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 59 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 62 12.2. Informational References . . . . . . . . . . . . . . . . 9 63 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 10 64 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 10 65 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 67 Intellectual Property and Copyright Statements . . . . . . . . . . 12 69 1. Introduction 71 It is desirable for SIP proxies to insert a spam score so that 72 downstream SIP proxies and downstream SIP user agents can use a high 73 score to decide that special handling is required. For example, a 74 score above 20 might cause one of the spam avoidance techniques 75 described in [RFC5039] to be triggered for this call. 77 This specification allows each SIP proxy to contribute spam scoring 78 information that can be useful to downstream SIP proxies and the SIP 79 user agent (UA). The downstream SIP proxies or SIP UA might ignore 80 that information (e.g., it doesn't trust the SIP proxy that generated 81 the spam score) or might use it. 83 Note that this document does not make the attempt to define how the 84 spam score was derived nor to distribute information that could be 85 used to verify the spam score generation. Furthermore, this document 86 does not attempt to cryptographically bind the identity of the entity 87 generating the score to the value itself. Hence, its usage is likely 88 to be useful only between neighboring administrative domains 89 communicating such a score. 91 One may wonder why bother marking a message that appears to be SPAM 92 when the same process that detected the SPAM can also automatically 93 block it. The answer is that contractual as well as regulatory 94 issues may prevent blocking and in these cases while not able to 95 block, the detecting proxy can nonetheless notify downstream elements 96 of the potential threat. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Calculation of the Spam Score 106 A SIP proxy evaluates an incoming SIP request and generates a spam 107 score using a local mechanism. In order to allow for whitelisting as 108 well as blacklisting the scoring is between 0 and 100, 0 indicating 109 absolute acceptance (e.g., whitelist), 100 indicating absolute SPAM 110 (e.g., blacklist) and scores between 0 and 100 can be considered to 111 represent the percentage likelyhood of spam. 113 The actual calculation is governed by algorithms (one example is 114 found in examples section below) which MAY be agreed upon by the 115 upstream and downstrem domains. The algorithm MAY be conveyed by the 116 downstream doamins to the upstream one out of band prior to the 117 upstream domain marking a message for transport downstream. 118 Alternatively, a default algorithm can be used if no alternate 119 algorithm was established a-priori between upstream and downstream 120 domains. The mechanism for conveyance of algorithm to upstream 121 domain is out of scope for this document but can be seen as an 122 extension to [I-D.tschofenig-sipping-framework-spit-reduction]. 124 4. Information passed downstream 126 In addition to the score the following other pieces of information 127 should be passed downstream as well: 129 Realm - Indicating the upstream domain or realm making the claim 131 Algorithm - The name of the agreed upon algorithm 133 Strength - An integer indicating the confidence of the score 134 (0-100) 136 Info - A text field containing any arbitrary information 138 Param[1..3] - 3 general purpose parameters for futureproofing 140 IsSpam - A boolean for convenience purposes alone. 142 The Relam is shared by all proxies in a domain and enables the 143 downstream proxy to determine whether or not the score is to be 144 trusted. 146 The Algorithm is the name of the algorithm used and can be 147 standardized in the same way encryption algorithm names (e.g. sha-1) 148 have been standardized. 150 The Strength field inidicates the confidence level of the Score. 151 This is generated by the same entity which generates the Score, and 152 is an output from the algorithim, which is based on a number of 153 factors, including for example volume of calls, call type etc. It is 154 meant to quantify the score. A calling party that makes many calls 155 and has an average score of 85 is preferable to calling party who 156 made 1 or 2 calls only and has an average score of 95. 158 Info is a text field (which can be limited to 64 bytes if we are 159 concerned about the MTU) that is there to provide more complete 160 information on the SPIT scoring etc, and can be used for diagnosis 161 etc. (which is useful for off line analysis reporting etc.). For 162 example, it could provide an explanation of the score such as is done 163 in one particular email spam package. 165 In this email example the threshold for SPAM is 7 and this message 166 scored a 9.5. The sample text info below could be used to explain 167 how the score was calculated. 169 points rule-name rule-description 170 ------ ---------------- ------------------------------ 171 2.5 SUBJ_CAPS Subject lind is capitalized 172 1.8 INLINE_GIF inline GIF detected in message 173 3.0 NON_PREF_LANG Non default language 174 2.0 HONEYPOT Honeypot address in cc 175 0.2 KEYWORD_MATCH suspicious words in message 177 Figure 1: Email Spam Rule example 179 As expected in this example, different tests have different scores 180 depending on their contribution to the potential of SPAM. Similarly 181 in the case of SPIT there can be many rules applied and having this 182 info can enable the receiving party to analyze the results (non 183 realtime) 185 Params 1,2 and 3 are just general purpose placeholders (containing 186 Param_Desc, Param_Value pairs) for future proofing capabilities. 187 Since so much is still unknown about IP communications SPAM this is 188 seen as a wise approach. 190 Finally, as an option it may be wise to have a boolean yes/no kind of 191 indicator for all those downstream who do not care to know why the 192 upstream element assumes it is spit only that it is. 194 5. Operation of Spam-Scoring Proxy 196 A SIP proxy evaluates an incoming SIP request and generates a spam 197 score using a local mechanism. This score is between 0 (indicating 198 the message is not spam) and 100 (indicating the message is spam). 199 Values between 0 and 100 indicate the 'likelihood' that the SIP 200 request is spam, with higher values indicating a higher likelihood 201 the message is spam. 203 This spam score is inserted into the new "Spam-Score" header. This 204 header field contains a summary spam score and optionally contains 205 detail information. The detail information is implementation 206 dependent. The detail information is valuable for debugging and to 207 provide the SIP user agent or SIP proxy with additional information 208 regarding how the spam-scoring SIP proxy's local mechanism arrived at 209 the summary spam score. 211 6. Operation of Downtream Proxy or User Agent 213 A downstream proxy or the SIP user agent MAY use the spam score or 214 spam-detail information to change call routing or call handling. It 215 is envisioned that some form of policies indicate the trusted proxies 216 in order to decide which spam scores to consider for special call 217 treatment. 219 In some jurisdictions, the end user needs to authorize call 220 handling, including rejection of a call based on a spam score. 221 Mechanisms to allow users to authorize such policies are, however, 222 out of scope of this document. 224 The behavior of the SIP proxy or user agent when the spam score is 225 above a certain value is a local policy matter. Examples of behavior 226 include: 228 o a SIP request with a high spam score might cause a proxy or user 229 agent to redirect the SIP request to company's main telephone 230 extension or to the user's voicemail 232 o a user agent might alert the user by flashing the phone (without 233 audible ringing) 235 o a user agent might allow calls with a spam score below a certain 236 value during daylight hours, but deny such calls at night. 238 o a proxy might challenge the caller to complete a Turing test. 240 7. Grammar 242 ABNF using the ABNF syntax of [RFC3261]: 244 extension-header = "Spam-Score:" SP 245 spam-score *[ SP ";" spam-detail ] 247 spam-score = score SP "by" SP hostname 248 score = 1*3DIGIT [ "." 1*3DIGIT ] 250 spam-detail = spam-strength / spam-algorithm / spam-param 252 spam-algorithm = "spam-algorithm" EQUAL quoted-string 254 spam-strength = "spam-score-strength" EQUAL strength 255 strength = 1*3DIGIT [ "." 0*3DIGIT ] 257 spam-info = "spam-info" EQUAL info-value 258 info-value = quoted-string 260 spam-param1 = "spam-param1" EQUAL param-value 261 param-value = quoted-string 263 spam-param2 = "spam-param2" EQUAL param-value 264 param-value = quoted-string 266 spam-param3 = "spam-param3" EQUAL param-value 267 param-value = quoted-string 269 spam-isspam = [ "isSpam" ] 271 Figure 2: ABNF 273 8. Examples 275 The following example shows a SIP score generated and inserted by two 276 SIP proxies, sip.example.com and sip.example.net. In this example, 277 sip.example.com is owned by a spammer who is trying to fool 278 downstream systems with their low spam score (0). However, the 279 example.net proxies and user agents only pay attention to spam scores 280 from Spam-Score headers generated by example.net proxies, so 281 example.com's attempts to fool the downstream proxies (with its low 282 spam score) are in vain. Note also the sample Session Duration Time 283 (SDT) algorithm SDT [I-D.malas-performance-metrics] simply compares 284 the given callers previous session duration time with the expected 285 session duration time over all destinations. 287 INVITE sip:bob@example.net SIP/2.0 288 Via: SIP/2.0/UDP sip.example.net;branch=z9hG4bKnashds8 289 ;received=192.0.2.1 290 Spam-Score: 75 by sip.example.net 291 ;detail="SIPfilter-1.0;call_volume=75" 292 ;spam-algorithm="SDT" 293 ;spam-score-strength=50 294 ;spam-info="High call volume" 295 ;spam-isSpam 296 Via: SIP/2.0/UDP sip.example.com;branch=z9hG4bKfjzc 297 ;received=192.0.2.127 298 Max-Forwards: 70 299 To: Bob 300 From: Alice ;tag=1928301774 301 Call-ID: a84b4c76e66710@pc33.example.com 302 CSeq: 314159 INVITE 303 Contact: 304 Content-Type: application/sdp 305 Content-Length: 142 307 [... SDP elided from this example...] 309 Figure 3: Example with spam scores 311 9. Security Considerations 313 SIP proxies and SIP user agents need to ignore spam scores generated 314 by proxies that aren't trusted. As the spam scores are inserted 315 along with Via: headers, the last Via header inserted by a trusted 316 proxy indicates the last trusted spam score. 318 In addition, the entire issue of securing the channel between the 319 upstream and downstream domains MUST be addressed via mechanisms such 320 as TLS. 322 10. Acknowledgements 324 Thanks to Joachim Charzinski, Daniel Quinlan, and S. Moonesamy for 325 their suggestions to improve this document. Thanks to David Schwartz 326 for his contributed text and to Eli Katz for editing assistance. 328 11. IANA Considerations 330 [[This section will be completed in a later version of this 331 document.]] 333 12. References 335 12.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 341 A., Peterson, J., Sparks, R., Handley, M., and E. 342 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 343 June 2002. 345 12.2. Informational References 347 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 348 Protocol (SIP) and Spam", RFC 5039, January 2008. 350 [I-D.tschofenig-sipping-framework-spit-reduction] 351 Tschofenig, H., Schulzrinne, H., Wing, D., Rosenberg, J., 352 and D. Schwartz, "A Framework to tackle Spam and Unwanted 353 Communication for Internet Telephony", 354 draft-tschofenig-sipping-framework-spit-reduction-02 (work 355 in progress), November 2007. 357 [I-D.malas-performance-metrics] 358 Malas, D., "SIP End-to-End Performance Metrics", 359 draft-malas-performance-metrics-08 (work in progress), 360 December 2007. 362 Appendix A. Changes 364 Note to RFC Editor: please remove this section prior to publication. 366 A.1. Changes from -00 to -01 368 o Changed scoring from positive/negative to 0-100 range. 370 o Moved score from a "Via:" extension to a new header "Spam-Score:". 372 o Changed from Standards Track to Experimental. 374 A.2. Changes from -01 to -02 376 o Describe how spam score could be computed 378 o Added more descripive text describing how the header is passed 379 downstream towards the user agent 381 Authors' Addresses 383 Dan Wing 384 Cisco Systems, Inc. 385 170 West Tasman Drive 386 San Jose, CA 95134 387 USA 389 Email: dwing@cisco.com 391 Saverio Niccolini 392 Network Laboratories, NEC Europe Ltd. 393 Kurfuersten-Anlage 36 394 Heidelberg 69115 395 Germany 397 Phone: +49 (0) 6221 4342 118 398 Email: saverio.niccolini@netlab.nec.de 399 URI: http://www.netlab.nec.de 400 Martin Stiemerling 401 Network Laboratories, NEC Europe Ltd. 402 Kurfuersten-Anlage 36 403 Heidelberg 69115 404 Germany 406 Phone: +49 (0) 6221 4342 113 407 Email: stiemerling@netlab.nec.de 408 URI: http://www.netlab.nec.de 410 Hannes Tschofenig 411 Nokia Siemens Networks 412 Linnoitustie 6 413 Espoo 02600 414 Finland 416 Phone: +358 (50) 4871445 417 Email: Hannes.Tschofenig@nsn.com 418 URI: http://www.tschofenig.com 420 Full Copyright Statement 422 Copyright (C) The IETF Trust (2008). 424 This document is subject to the rights, licenses and restrictions 425 contained in BCP 78, and except as set forth therein, the authors 426 retain all their rights. 428 This document and the information contained herein are provided on an 429 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 430 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 431 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 432 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 433 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 434 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 436 Intellectual Property 438 The IETF takes no position regarding the validity or scope of any 439 Intellectual Property Rights or other rights that might be claimed to 440 pertain to the implementation or use of the technology described in 441 this document or the extent to which any license under such rights 442 might or might not be available; nor does it represent that it has 443 made any independent effort to identify any such rights. Information 444 on the procedures with respect to rights in RFC documents can be 445 found in BCP 78 and BCP 79. 447 Copies of IPR disclosures made to the IETF Secretariat and any 448 assurances of licenses to be made available, or the result of an 449 attempt made to obtain a general license or permission for the use of 450 such proprietary rights by implementers or users of this 451 specification can be obtained from the IETF on-line IPR repository at 452 http://www.ietf.org/ipr. 454 The IETF invites any interested party to bring to its attention any 455 copyrights, patents or patent applications, or other proprietary 456 rights that may cover technology that may be required to implement 457 this standard. Please address the information to the IETF at 458 ietf-ipr@ietf.org. 460 Acknowledgment 462 This document was produced using xml2rfc v1.33pre8 (of 463 http://xml.resource.org/) from a source in RFC-2629 XML format.