idnits 2.17.00 (12 Aug 2021) /tmp/idnits41912/draft-wing-sipping-spam-score-00.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 (August 18, 2007) is 5390 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-sipping-spam has been published as RFC 5039 == Outdated reference: A later version (-04) exists of draft-tschofenig-sipping-framework-spit-reduction-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Wing 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Niccolini 5 Expires: February 19, 2008 NEC 6 H. Tschofenig 7 Nokia Siemens Networks 8 M. Stiemerling 9 NEC 10 August 18, 2007 12 Spam Score for SIP 13 draft-wing-sipping-spam-score-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 19, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document defines a mechanism for SIP proxies to communicate a 47 spam score to downstream SIP proxies and SIP user agents so they can 48 provide alternate call routing or call handling. 50 Terminology 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Operation of Spam-Scoring Proxy . . . . . . . . . . . . . . . . 3 60 3. Operation of Proxy or User Agent . . . . . . . . . . . . . . . 3 61 4. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 68 9.2. Informational References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 Intellectual Property and Copyright Statements . . . . . . . . . . 8 72 1. Introduction 74 It is desirable for SIP proxies to insert a spam score so that 75 downstream SIP proxies and downstream SIP user agents can use a high 76 score to decide that special handling is required. For example, a 77 score above 20 might cause one of the spam avoidance techniques, 78 described in [I-D.ietf-sipping-spam], to be triggered for this call. 80 This specification allows each SIP proxy to contribute spam scoring 81 information that can be useful to downstream SIP proxies and the SIP 82 UA. The downstream SIP proxies might ignore that information (e.g., 83 they don't trust it) or might use it (e.g., they trust it because it 84 was generated by a federation). 86 From a deployment point of view it is expected that the score will 87 most likely be benefical (and trustworthy) when inserted by a SIP 88 proxy on the recipients side for evaluation by a SIP UA that has a 89 direct relationship with this SIP proxy. 91 2. Operation of Spam-Scoring Proxy 93 A SIP proxy generates a spam score using a local mechanism. Negative 94 scores indicate the SIP request is not considered spam, and positive 95 scores indicate the SIP request is considered spam. The higher the 96 value, the more likely a message is spam or is not spam. 98 This spam score is inserted into the "Via:" header, which is already 99 generated by the proxy. 101 The Via header was chosen because it the Via is already correlated 102 with the proxy that generated the Via header. 104 3. Operation of Proxy or User Agent 106 A downstream proxy MAY use the spam score or spam-detail information 107 to change call routing or call handling. It is RECOMMENDED that only 108 scores generated by trusted proxies be used. The behavior of the SIP 109 proxy or user agent when the spam score is above a certain value is a 110 local matter. Examples of behavior include: 112 o a SIP request with a high spam score might cause a proxy or user 113 agent to redirect the SIP request to company's main telephone 114 extension or to the user's voicemail 116 o a user agent might alert the user by flashing the phone (without 117 audible ringing) 119 o a user agent might allow calls with a spam score below a certain 120 value during daylight hours, but deny such calls at night. 122 o a proxy might challenge the caller to complete a Turing test. 124 These aspects are discussed in 125 [I-D.tschofenig-sipping-framework-spit-reduction]. 127 4. ABNF 129 ABNF using the ABNF syntax of [RFC3261]: 131 via-extension = spam-score / spam-detail 133 spam-score = "spam" EQUAL score 134 score = *"-" 1*4DIGIT [ "." 0*3DIGIT ] 136 spam-detail = "spam-detail" EQUAL detail 137 detail = QUOTE mech SEMI rule-score 138 *(COMMA rule-score) QUOTE 139 rule-score = rule [ "=" score ] 140 mech = token 141 rule = token 143 Figure 1: ABNF 145 5. Examples 147 The following example shows a SIP score generated by biloxi.com and 148 atlanta.com. In this example, atlanta.com is owned by a spammer who 149 is trying to fool downstream systems with their low spam score (0.0). 150 However, the biloxi.com proxies and user agents only pay attention to 151 spam scores from Via: headers generated by biloxi.com proxies, so 152 atlanta.com's attempts are in vain. 154 INVITE sip:bob@biloxi.com SIP/2.0 155 Via: SIP/2.0/UDP biloxi.com;branch=z9hG4bKnashds8 156 ;received=192.0.2.1 157 ;spam=-5 158 ;spam-detail="Hormel-1.0;whitelist=-10,call_volume=5" 159 Via: SIP/2.0/UDP sip.atlanta.com;branch=z9hG4bKfjzc 160 ;received=192.0.3.2 161 ;spam=-100 162 ;spam-detail="Jaeger-3.3;not-a-spammer=-100" 163 Max-Forwards: 70 164 To: Bob 165 From: Alice ;tag=1928301774 166 Call-ID: a84b4c76e66710@pc33.atlanta.com 167 CSeq: 314159 INVITE 168 Contact: 169 Content-Type: application/sdp 170 Content-Length: 142 172 Figure 2: example 174 6. Security Considerations 176 SIP proxies and SIP user agents need to ignore spam scores in Via 177 headers generated by proxies that aren't trusted. Via headers have 178 the most recent proxy on top, so parsing for spam scores should stop 179 at the first Via header from a non-trusted proxy. 181 7. Acknowledgements 183 Add your name here. 185 8. IANA Considerations 187 This document will add new IANA registrations for new SIP headers. 189 [[This section will be completed in a later version of this 190 document.]] 192 9. References 194 9.1. Normative References 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, March 1997. 199 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 200 A., Peterson, J., Sparks, R., Handley, M., and E. 201 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 202 June 2002. 204 9.2. Informational References 206 [I-D.ietf-sipping-spam] 207 Rosenberg, J. and C. Jennings, "The Session Initiation 208 Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work 209 in progress), July 2007. 211 [I-D.tschofenig-sipping-framework-spit-reduction] 212 Tschofenig, H., "A Framework to tackle Spam and Unwanted 213 Communication for Internet Telephony", 214 draft-tschofenig-sipping-framework-spit-reduction-01 (work 215 in progress), July 2007. 217 Authors' Addresses 219 Dan Wing 220 Cisco Systems, Inc. 221 170 West Tasman Drive 222 San Jose, CA 95134 223 USA 225 Email: dwing@cisco.com 226 Saverio Niccolini 227 Network Laboratories, NEC Europe Ltd. 228 Kurfuersten-Anlage 36 229 Heidelberg 69115 230 Germany 232 Phone: +49 (0) 6221 4342 118 233 Email: saverio.niccolini@netlab.nec.de 234 URI: http://www.netlab.nec.de 236 Hannes Tschofenig 237 Nokia Siemens Networks 238 Otto-Hahn-Ring 6 239 Munich, Bavaria 81739 240 Germany 242 Email: Hannes.Tschofenig@nsn.com 244 Martin Stiemerling 245 Network Laboratories, NEC Europe Ltd. 246 Kurfuersten-Anlage 36 247 Heidelberg 69115 248 Germany 250 Phone: +49 (0) 6221 4342 113 251 Email: stiemerling@netlab.nec.de 252 URI: http://www.netlab.nec.de 254 Full Copyright Statement 256 Copyright (C) The IETF Trust (2007). 258 This document is subject to the rights, licenses and restrictions 259 contained in BCP 78, and except as set forth therein, the authors 260 retain all their rights. 262 This document and the information contained herein are provided on an 263 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 264 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 265 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 266 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 267 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 268 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 270 Intellectual Property 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed to 274 pertain to the implementation or use of the technology described in 275 this document or the extent to which any license under such rights 276 might or might not be available; nor does it represent that it has 277 made any independent effort to identify any such rights. Information 278 on the procedures with respect to rights in RFC documents can be 279 found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use of 284 such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository at 286 http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights that may cover technology that may be required to implement 291 this standard. Please address the information to the IETF at 292 ietf-ipr@ietf.org. 294 Acknowledgment 296 Funding for the RFC Editor function is provided by the IETF 297 Administrative Support Activity (IASA).