idnits 2.17.1 draft-seedorf-sipping-spam-score-semantics-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 330. 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 18, 2008) is 5909 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-tschofenig-sipping-spit-policy-02 == Outdated reference: A later version (-02) exists of draft-wing-sipping-spam-score-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group J. Seedorf 3 Internet-Draft S. Niccolini 4 Intended status: Informational NEC 5 Expires: August 21, 2008 H. Schulzrinne 6 Columbia University 7 February 18, 2008 9 Spam score for SIP: a proposal for semantics 10 draft-seedorf-sipping-spam-score-semantics-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document reports a proposal for semantics of SIP spam scoring in 44 order to achieve a flexible signalling standardization allowing an 45 incremental adoption of the scoring mechanism. This approach can 46 give early experimental implementers the possibility to start using 47 spam scoring extensions in an explorative fashion without running 48 into interoperability problems. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. SIP spam score semantics proposal . . . . . . . . . . . . . . . 3 54 2.1. Proposal motivation . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Proposal details . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Examples of combinations of SIP spam scores . . . . . . . . 5 57 3. Objective of the proposal . . . . . . . . . . . . . . . . . . . 6 58 4. SPIT mitigation mechanisms overview and feasibility study . . . 6 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Intellectual Property and Copyright Statements . . . . . . . . . . 8 65 1. Introduction 67 Latest discussion in the IETF demonstrated that there is still a lack 68 of consensus how to address the general topic of SPIT mitigation. In 69 particular, many controversial discussions have been centered around 70 the SIP spam score draft [I-D.wing-spam-score], as well as the 71 mechanisms and the rationale behind it. 73 The main issues raised were: 74 o uncertainness on the appearance of the threat; 75 o unknown effectiveness of mitigation algorithms; 76 o lack of semantics and transmission of SPIT estimation scores; 78 Even though the spam threat is not fully defined today, the 79 recommendation of [RFC5039] is to not wait until it is too late 80 (i.e., providers should not ignore the spam problem until it 81 happens); there is the need for some work in this area. 83 Even if [RFC5039] indicated a possible path, spam is such a 84 multifaced problem that this cannot be regarded as the only one; 85 multiple paths must be explored and standardization bodies should 86 give implementers the possibility to experiment with solutions before 87 the problem gets too big (as it got in the email case). 89 Given that something needs to be done, this document details a 90 proposal for dealing with the remaining two issues, namely how to 91 give implementers a chance to start experimenting with SPIT 92 mitigation mechanisms and to communicate spam score results across 93 different entities in the network in an interoperable and incremental 94 way. 96 2. SIP spam score semantics proposal 98 2.1. Proposal motivation 100 The main points that motivated us to write such a proposal and made 101 us believe that spam score is an important mechanisms for spam 102 mitigation were: 104 o Whether a message is spam or not is not a binary proposition, both 105 in terms of identifying it (mechanisms will have false positives 106 and false negatives) and even in judging it (e.g., depending on 107 user preferences). 108 o Different SIP routing elements have different types of information 109 available that are useful for spam identification, but are not 110 necessarly the ones that should be making call handling decisions. 112 o End systems or user services implemented in proxies should be 113 judging this information and make a decision as to how to handle 114 the call, i.e, whether to reject, forward or present the call to 115 the user and what user interface indications to provide to the 116 user. 118 For interoperability of such spam scores being exchanged among SIP 119 entities it is absolutely necessary to have semantics defined. If no 120 clear semantics are defined for spam scores, there is the risk of 121 entities falsely interpreting scores they receive. Since every SPIT 122 mitigation technique works differently, we propose to have semantics 123 defined "per-method" and not in general. 125 2.2. Proposal details 127 We propose to have SIP signalling extensions allowing the binding of 128 SIP spam scores to well defined semantics. Such a solution would 129 allow the possibility of making network-wide distributed decisions 130 across multiple entities involved in SPIT mitigation decisions. 132 Even though spam is not a binary proposition, some currently 133 suggested mitigation mechanisms give a 0/1 result when being applied 134 to a message. Still, such an outcome is only an indicator for a 135 message being spam or not. Defining semantics for SPIT mitigation 136 mechanisms with such a 0/1 output (i.e., a binary output) is a matter 137 of assigning 0 and 1 to specified outputs. 139 Thus, methods giving a "binary output" can have very straightforward 140 semantics: 141 o blacklist/whitelist: 0 means "not on list", 1 means "on list"; 142 o timecontext: 0 means "the caller initiated a session inside the 143 user-defined interval for receiving calls", 1 means "the caller 144 initiated a session inside the user-defined interval for receiving 145 calls"; 146 o captcha: 0 means "the caller passed the CAPTCHA test", 1 means 147 "the caller did not pass the CAPTCHA test". 148 o etc. 150 Each binary method would need to standardize the "methodID" (e.g., 151 the name) and the corresponding "semantic" (the meaning of 0/1, 152 respectively). In principle, these methods could well be mapped to 153 policies, see [I-D.tschofenig-sipping-spit-policy] and reference 154 within. 156 Other mechanisms currently proposed for SPIT mitigation have a more 157 detailed output (which still only gives an indication for SPIT). 158 These mechanisms need well-defined semantics as a basis for 159 interoperability as well. Such methods giving a "non-binary output" 160 could have more elaborate semantics based on statistics: 161 o statistics based on user feedback; such methods would give an 162 estimation of a score x that could be the percentage of messages 163 with the same method-result that were marked as SPIT by users; 164 o statistics based on anomaly detection; such methods would give an 165 estimation of a score x that could be the percentage of previous 166 messages were below/above (depending on the method) the result for 167 this method compared to the current message. 168 o etc. 170 Also in this case, each non-binary method would need to standardize 171 the "methodID" (e.g., the name) and the corresponding "semantic" (the 172 meaning of the x score). 174 The proposal allows a per-method score in order to have different 175 methods with different ranges. This flexibility enables the use of 176 new detection methods without changing the standard which defines the 177 SPIT estimation scores. In addition, methods can report the 178 parameters used for computation (e.g., the call-rate method could 179 have a parameter defining the length of the time-frame used as a 180 basis for the score in milliseconds). Also these parameters would 181 need to be agreed and standardized together with the methodID and the 182 semantics. 184 In principle a single node can append a number of scores equal to the 185 number of mechanisms that it applied to the message. 187 Once such semantics are defined and standardized it would be easy to 188 start experimenting with these extensions avoiding interoperability 189 problems. 191 2.3. Examples of combinations of SIP spam scores 193 Examples of combinations of SIP spam scores would be 194 o an ingress spam filter performs call rate analysis and appends a 195 score, a filter near the callee's UA combines this knowledge with 196 the callee's black and white lists (using a secret magic algorithm 197 that is completely out of the scope of standardization 198 discussion). 199 o an ingress spam filter performs call rate analysis and appends a 200 score, a filter near the proxy server of the callee perform a 201 CAPTCHA test because the call rate score was suspicious, the final 202 decision is taken by the UA based on the time of the day taking 203 into account the previous tests performed (the final filter is on 204 the UA). 206 In these examples we assume a multi-operator and multi-vendor 207 scenario where the spam score semantics would play a fundamental 208 role. 210 3. Objective of the proposal 212 The objective of the proposal is to show a solution space to the 213 issues raised in the SPIT mitigation discussion recently happening in 214 the IETF. 216 This proposal would allow standardization of SIP spam scoring 217 extensions that could be standardized and adopted incrementally 218 giving early experimental implementers the possibility to start using 219 spam scoring extensions in an explorative fashion without running 220 into interoperability problems. 222 According to the authors' opinion this proposal allows to address all 223 the three issues raised in section Section 1 and it is therefore to 224 be considered as legitimating the progress of the spam score draft 225 [I-D.wing-spam-score] inside IETF. 227 4. SPIT mitigation mechanisms overview and feasibility study 229 [[This section will be completed in a later version of this 230 document.]] 232 5. Security Considerations 234 There are issues related to integrity, confidentiality, and trust of 235 SPIT-related information, but they are not direclty related to the 236 definition of semantics for SIP spam score mechanisms. 238 6. IANA Considerations 240 [[This section will be completed in a later version of this 241 document.]] 243 7. Informative References 245 [I-D.tschofenig-sipping-spit-policy] 246 Tschofenig, H., Wing, D., Schulzrinne, H., Froment, T., 247 and G. Dawirs, "A Document Format for Expressing 248 Authorization Policies to tackle Spam and Unwanted 249 Communication for Internet Telephony", 250 draft-tschofenig-sipping-spit-policy-02 (work in 251 progress), November 2007. 253 [I-D.wing-spam-score] 254 Wing, D., Niccolini, S., Stiemerling, M., and H. 255 Tschofenig, "Spam Score for SIP", 256 draft-wing-sipping-spam-score-01 (work in progress), 257 February 2008. 259 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 260 Protocol (SIP) and Spam", RFC 5039, January 2008. 262 Authors' Addresses 264 Jan Seedorf 265 NEC Laboratories Europe, NEC Europe Ltd. 266 Kurfuersten-Anlage 36 267 Heidelberg 69115 268 Germany 270 Phone: +49 (0) 6221 4342 221 271 Email: seedorf@nw.neclab.eu 272 URI: http://www.nw.neclab.eu 274 Saverio Niccolini 275 NEC Laboratories Europe, NEC Europe Ltd. 276 Kurfuersten-Anlage 36 277 Heidelberg 69115 278 Germany 280 Phone: +49 (0) 6221 4342 118 281 Email: saverio.niccolini@nw.neclab.eu 282 URI: http://www.nw.neclab.eu 284 Henning Schulzrinne 285 Dept. of Computer Science, Columbia University 286 1214 Amsterdam Avenue 287 New York, NY 10027 288 US 290 Email: hgs@cs.columbia.edu 292 Full Copyright Statement 294 Copyright (C) The IETF Trust (2008). 296 This document is subject to the rights, licenses and restrictions 297 contained in BCP 78, and except as set forth therein, the authors 298 retain all their rights. 300 This document and the information contained herein are provided on an 301 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 302 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 303 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 304 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 305 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 306 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 308 Intellectual Property 310 The IETF takes no position regarding the validity or scope of any 311 Intellectual Property Rights or other rights that might be claimed to 312 pertain to the implementation or use of the technology described in 313 this document or the extent to which any license under such rights 314 might or might not be available; nor does it represent that it has 315 made any independent effort to identify any such rights. Information 316 on the procedures with respect to rights in RFC documents can be 317 found in BCP 78 and BCP 79. 319 Copies of IPR disclosures made to the IETF Secretariat and any 320 assurances of licenses to be made available, or the result of an 321 attempt made to obtain a general license or permission for the use of 322 such proprietary rights by implementers or users of this 323 specification can be obtained from the IETF on-line IPR repository at 324 http://www.ietf.org/ipr. 326 The IETF invites any interested party to bring to its attention any 327 copyrights, patents or patent applications, or other proprietary 328 rights that may cover technology that may be required to implement 329 this standard. Please address the information to the IETF at 330 ietf-ipr@ietf.org. 332 Acknowledgment 334 Funding for the RFC Editor function is provided by the IETF 335 Administrative Support Activity (IASA).