idnits 2.17.00 (12 Aug 2021) /tmp/idnits42557/draft-wing-sipping-spam-score-01.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 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 320. 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 -- 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 13, 2008) is 5211 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 16, 2008 M. Stiemerling 6 NEC 7 H. Tschofenig 8 Nokia Siemens Networks 9 February 13, 2008 11 Spam Score for SIP 12 draft-wing-sipping-spam-score-01 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 16, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document defines a mechanism for SIP proxies to communicate a 46 spam score to downstream SIP proxies and to SIP user agents. This 47 information can then be used as input to other decision making 48 engines, for example, to provide alternate call routing or call 49 handling. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Operation of Spam-Scoring Proxy . . . . . . . . . . . . . . . . 3 56 4. Operation of Proxy or User Agent . . . . . . . . . . . . . . . 4 57 5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 10.2. Informational References . . . . . . . . . . . . . . . . . 7 65 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 7 66 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Intellectual Property and Copyright Statements . . . . . . . . . . 9 70 1. Introduction 72 It is desirable for SIP proxies to insert a spam score so that 73 downstream SIP proxies and downstream SIP user agents can use a high 74 score to decide that special handling is required. For example, a 75 score above 20 might cause one of the spam avoidance techniques 76 described in [RFC5039] to be triggered for this call. 78 This specification allows each SIP proxy to contribute spam scoring 79 information that can be useful to downstream SIP proxies and the SIP 80 user agent (UA). The downstream SIP proxies or SIP UA might ignore 81 that information (e.g., it doesn't trust the SIP proxy that generated 82 the spam score) or might use it. 84 Note that this document does not make the attempt to define how the 85 spam score was derived nor to distribute information that could be 86 used to verify the spam score generation. Furthermore, this document 87 does not attempt to cryptographically bind the identity of the entity 88 generating the score to the value itself. Hence, its usage is likely 89 to be useful only between neighboring administrative domains 90 communicating such a score. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Operation of Spam-Scoring Proxy 100 A SIP proxy evaluates an incoming SIP request and generates a spam 101 score using a local mechanism. This score is between 0 (indicating 102 the message is not spam) and 100 (indicating the message is spam). 103 Values between 0 and 100 indicate the 'likelihood' that the SIP 104 request is spam, with higher values indicating a higher likelihood 105 the message is spam. 107 This spam score is inserted into the new "Spam-Score" header. This 108 header field contains a summary spam score and optionally contains 109 detail information. The detail information is implementation 110 dependent. The detail information is valuable for debugging and to 111 provide the SIP user agent or SIP proxy with additional information 112 regarding how the spam-scoring SIP proxy's local mechanism arrived at 113 the summary spam score. 115 4. Operation of Proxy or User Agent 117 A downstream proxy or the SIP user agent MAY use the spam score or 118 spam-detail information to change call routing or call handling. It 119 is envisioned that some form of policies indicate the trusted proxies 120 in order to decide which spam scores to consider for special call 121 treatment. 123 In some jurisdictions, the end user needs to authorize call 124 handling, including rejection of a call based on a spam score. 125 Mechanisms to allow users to influence such policies are, however, 126 out of scope of this document. 128 The behavior of the SIP proxy or user agent when the spam score is 129 above a certain value is a local policy matter. Examples of behavior 130 include: 132 o a SIP request with a high spam score might cause a proxy or user 133 agent to redirect the SIP request to company's main telephone 134 extension or to the user's voicemail 136 o a user agent might alert the user by flashing the phone (without 137 audible ringing) 139 o a user agent might allow calls with a spam score below a certain 140 value during daylight hours, but deny such calls at night. 142 o a proxy might challenge the caller to complete a Turing test. 144 5. Grammar 146 ABNF using the ABNF syntax of [RFC3261]: 148 extension-header = spam-score [ SP ";" spam-detail ] 150 spam-score = score SP "by" SP hostname 151 score = 1*3DIGIT [ "." 0*3DIGIT ] 153 spam-detail = "detail" EQUAL detail 154 detail = QUOTE mech SEMI rule-score 155 *(COMMA rule-score) QUOTE 156 ; mathematical average of the rule-scores 157 ; MUST be same as spam-score 159 rule-score = rule [ "=" score ] 160 mech = token 161 rule = token 163 Figure 1: ABNF 165 6. Examples 167 The following example shows a SIP score generated and inserted by two 168 SIP proxies, sip.example.com and sip.example.net. In this example, 169 sip.example.com is owned by a spammer who is trying to fool 170 downstream systems with their low spam score (0). However, the 171 example.net proxies and user agents only pay attention to spam scores 172 from Spam-Score headers generated by example.net proxies, so 173 example.com's attempts to fool the downstream proxies (with its low 174 spam score) are in vain. 176 INVITE sip:bob@example.net SIP/2.0 177 Via: SIP/2.0/UDP sip.example.net;branch=z9hG4bKnashds8 178 ;received=192.0.2.1 179 Spam-Score: 75 by sip.example.net 180 ;detail="SIPfilter-1.0;call_volume=75" 181 Via: SIP/2.0/UDP sip.example.com;branch=z9hG4bKfjzc 182 ;received=192.0.2.127 183 Max-Forwards: 70 184 To: Bob 185 From: Alice ;tag=1928301774 186 Call-ID: a84b4c76e66710@pc33.example.com 187 CSeq: 314159 INVITE 188 Contact: 189 Content-Type: application/sdp 190 Content-Length: 142 192 [... SDP elided from this example...] 194 Figure 2: Example with spam scores 196 7. Security Considerations 198 SIP proxies and SIP user agents need to ignore spam scores generated 199 by proxies that aren't trusted. 201 [[This section will be completed in a later version of this 202 document.]] 204 8. Acknowledgements 206 Thanks to Joachim Charzinski, Daniel Quinlan, and S. Moonesamy for 207 their suggestions to improve this document. 209 9. IANA Considerations 211 [[This section will be completed in a later version of this 212 document.]] 214 10. References 216 10.1. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 222 A., Peterson, J., Sparks, R., Handley, M., and E. 223 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 224 June 2002. 226 10.2. Informational References 228 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 229 Protocol (SIP) and Spam", RFC 5039, January 2008. 231 Appendix A. Changes 233 Note to RFC Editor: please remove this section prior to publication. 235 A.1. Changes from -00 to -01 237 o Changed scoring from positive/negative to 0-100 range. 239 o Moved score from a "Via:" extension to a new header "Spam-Score:". 241 o Changed from Standards Track to Experimental. 243 Authors' Addresses 245 Dan Wing 246 Cisco Systems, Inc. 247 170 West Tasman Drive 248 San Jose, CA 95134 249 USA 251 Email: dwing@cisco.com 253 Saverio Niccolini 254 Network Laboratories, NEC Europe Ltd. 255 Kurfuersten-Anlage 36 256 Heidelberg 69115 257 Germany 259 Phone: +49 (0) 6221 4342 118 260 Email: saverio.niccolini@netlab.nec.de 261 URI: http://www.netlab.nec.de 262 Martin Stiemerling 263 Network Laboratories, NEC Europe Ltd. 264 Kurfuersten-Anlage 36 265 Heidelberg 69115 266 Germany 268 Phone: +49 (0) 6221 4342 113 269 Email: stiemerling@netlab.nec.de 270 URI: http://www.netlab.nec.de 272 Hannes Tschofenig 273 Nokia Siemens Networks 274 Linnoitustie 6 275 Espoo 02600 276 Finland 278 Phone: +358 (50) 4871445 279 Email: Hannes.Tschofenig@nsn.com 280 URI: http://www.tschofenig.com 282 Full Copyright Statement 284 Copyright (C) The IETF Trust (2008). 286 This document is subject to the rights, licenses and restrictions 287 contained in BCP 78, and except as set forth therein, the authors 288 retain all their rights. 290 This document and the information contained herein are provided on an 291 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 292 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 293 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 294 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 295 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 296 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 298 Intellectual Property 300 The IETF takes no position regarding the validity or scope of any 301 Intellectual Property Rights or other rights that might be claimed to 302 pertain to the implementation or use of the technology described in 303 this document or the extent to which any license under such rights 304 might or might not be available; nor does it represent that it has 305 made any independent effort to identify any such rights. Information 306 on the procedures with respect to rights in RFC documents can be 307 found in BCP 78 and BCP 79. 309 Copies of IPR disclosures made to the IETF Secretariat and any 310 assurances of licenses to be made available, or the result of an 311 attempt made to obtain a general license or permission for the use of 312 such proprietary rights by implementers or users of this 313 specification can be obtained from the IETF on-line IPR repository at 314 http://www.ietf.org/ipr. 316 The IETF invites any interested party to bring to its attention any 317 copyrights, patents or patent applications, or other proprietary 318 rights that may cover technology that may be required to implement 319 this standard. Please address the information to the IETF at 320 ietf-ipr@ietf.org. 322 Acknowledgments 324 Funding for the RFC Editor function is provided by the IETF 325 Administrative Support Activity (IASA). This document was produced 326 using xml2rfc v1.33pre66 (of http://xml.resource.org/) from a source 327 in RFC-2629 XML format.