idnits 2.17.1 draft-niccolini-sipping-feedback-spit-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 505. 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 23, 2007) is 6269 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3265 (ref. '1') (Obsoleted by RFC 6665) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-spam-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group S. Niccolini 3 Internet-Draft S. Tartarelli 4 Intended status: Informational M. Stiemerling 5 Expires: August 27, 2007 NEC 6 S. Srivastava 7 Nortel Networks 8 February 23, 2007 10 SIP Extensions for SPIT identification 11 draft-niccolini-sipping-feedback-spit-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 27, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This memo analyzes the need for SIP extensions for SPIT (Spam Over 45 Internet telephony) identification. This memo describes requirements 46 and gives an overview of possible solutions to send feedback 47 information using the SIP protocol for the scope of SPIT. Feedback 48 information from the users to the SPIT identification system (e.g., 49 working closely with the callee's SIP proxy server) are important for 50 SPIT detection and prevention. The overall SPIT protection systems 51 on the internet will benefit from such information. The basic idea 52 is that each user who receives a SPIT session request, will send a 53 feedback to SPIT identification system (for example, using a button 54 on the user interface of the client). Information could be also 55 exchanged among domains and/or servers in order to increase 56 effectiveness of SPIT detection systems. The idea is that SIP proxy 57 servers and/or B2BUAs include SPIT likeliness estimations (based on 58 some knowledge they have which is out of the scope of this draft) as 59 additional message headers (e.g. INVITE headers) when forwarding 60 such messages to other domains. This memo identifies the parameters 61 that the SPIT identification system may need in order to detect 62 abusive behaviors; moreover it proposes an overview of technical 63 solutions how such information can be sent back to the SPIT 64 identification system by means of the SIP protocol. The memo also 65 addresses the technical solutions on how forward information could be 66 passed among domains as well as how communication initiation could be 67 denied to users (e.g. blacklisted ones). 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Requirements for SPIT Identification using Feedbacks . . . . . 6 75 3. Parameters for SPIT Detection and Prevention . . . . . . . . . 7 77 4. SIP Extensions for SPIT . . . . . . . . . . . . . . . . . . . 8 78 4.1. Error Code for SPIT . . . . . . . . . . . . . . . . . . . 8 79 4.2. Additional Header for SPIT Feedback . . . . . . . . . . . 8 80 4.3. SIP Event Package . . . . . . . . . . . . . . . . . . . . 9 81 4.4. Additional Header for Indicating Likeliness of SPIT . . . 9 83 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 7. IPR Considerations . . . . . . . . . . . . . . . . . . . . . . 12 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 96 Intellectual Property and Copyright Statements . . . . . . . . . . 16 98 1. Introduction 100 The spam problem is well known in the email world. Voice 101 communications carried over the traditional PSTN are not largely 102 suffering from unsolicited telemarketing calls because of the big 103 costs an originator has to encounter to send voice spam over circuit 104 switched networks. Recent studies [3] have calculated that these 105 costs will significantly reduce for voice call carried over the 106 Internet Protocol (IP). Moreover significantly reduced cost of 107 international calls will enable spams to be originated from the 108 countries where do not call lists does not apply. 110 When referring to multimedia communications the spam is commonly 111 referred to as SPIT (SPam over Internet Telephony). In order to 112 provide additional value and to start using a common set of terms, we 113 define the following taxonomy in the scope of this memo: 115 o SPIT (SPam over Internet Telephony) for unsolicited voice/video 116 calls 118 o SPIM (SPam Over Instant Messaging) for unsolicited instant 119 messages. 121 o SPOP (SPam Over Presence) for unsolicited presence event SUBSCRIBE 122 requests. 124 o SPOF (SPam Over Fax) for unsolicited Fax calls. 126 o SPOM (SPam Over Multimedia) for unsolicited session request, where 127 type of media is not relevant. 129 This memo currently focuses on SPIT because it is the most actual 130 threat to be addressed in author's opinion. The SPIT threat is 131 currently gaining attention in the community and several solutions to 132 counter this threat are currently being analyzed [3] and proposed 133 [4]. The SPIT identification system is referred as "SPIT system" in 134 this document. The SPIT system is supposed to work closely with the 135 SIP infrastructure (e.g., with the callee's SIP proxy server or with 136 other SIP entities) and to make use of SIP signaling. This memo 137 analyzes the need for SIP extensions for SPIT identification after 138 presenting a list of parameters that a SPIT identification system may 139 need to know in order to detect and prevent SPIT session requests. 141 As per the lessons learnt from Anti-Virus and email Anti-SPAM 142 security products, there will be the case when SPIT systems will not 143 able to detect the SPIT calls. SPIT systems will require feedbacks 144 from users. Apart from the feedback being used for reputation system 145 and personal filters, these feedback will be useful for further 146 avoiding massive spread of SPIT in other provider's network. 147 Providers can share this information either via SIP signaling or by 148 extending the mechanisms defined in [5]. 150 It is not good to have other XML schema and/or protocols for 151 reporting SPAM on the SIP UA as it will require additional resource. 152 Using the SIP mechanism is better choice from the deployment 153 prespectives, otherwise out-of-band mechanism's topology and SIP 154 topology needs to be in synchronization and network traffic is 155 optimized. 157 When some session requests are not detected as SPIT by the SPIT 158 system, the callee picks up the call and realizes that he received an 159 unsolicited session request. After having realized that the session 160 was a SPIT one, the callee decides to terminate the session with a 161 special button that informs the system that a SPIT session request 162 was just delivered. This feedback could be as well sent by an 163 answering machine which answers the session request instead of the 164 callee and decides whether the session request was a SPIT one or not 165 sending afterwards the feedback to the SPIT system. 167 Other possible methods to fight SPIT could be to add a SPIT 168 likeliness score as additional header that the destination domain 169 could use for prevention scopes when deciding about the session. 170 SPIT likeliness can be used in addition to present the requirements 171 and the parameters for SPIT prevention, we analyze and propose 172 different methods on how such information could be exchanged among 173 proxy servers and user agents using SIP. 175 2. Requirements for SPIT Identification using Feedbacks 177 There are some important requirements for the mechanism above cited 178 to be taken into account when used for SPIT identification. The 179 identification of requirements is necessary to understand: 181 o how SIP messages carrying the feedback and the forward information 182 should look like; 184 o which are the methods best suited to carry such information; 186 o how the SIP entities should behave when dealing with such 187 messages. 189 We report here a first non-exhaustive list of requirements that we 190 identified in the context of SPIT identification using feedbacks and 191 forward information: 193 o SIP user agents do not know if the SPIT identification system is 194 working either in stateless or in stateful mode and therefore the 195 feedback must contain all necessary parameters both to non- 196 ambiguous identify the call and to serve as input for SPIT 197 identification methods; 199 o the feedback should not notify the caller that the call was 200 recognized to be SPIT by the terminating user agent, either the 201 message containing the feedback should have only a scope valid for 202 the SPIT identification system or the information related to the 203 feedback should be stripped from the SIP message before forwarding 204 it to the originating party. 206 o the SPIT likeliness information about a certain call should also 207 be forwarded to the callee since some of the identification and 208 prevention methods could be integrated with the callee's user 209 agent; 211 o the SPIT likeliness information should not notify the caller, 212 either the message containing such information should have only a 213 scope valid for the SPIT identification system or such information 214 should be stripped from the SIP message before forwarding it back 215 to the originating party. 217 o the information the originating domain/party should receive back 218 regarding the call should be at most a reason explaining why the 219 call was rejected (e.g. using an error code to be defined) 221 3. Parameters for SPIT Detection and Prevention 223 The parameters described here are intended to be a list of parameters 224 the system could need to know in order to detect and prevent the 225 delivery of next SPIT session requests. 227 In addition to the methods detailed in [3] there are other methods 228 that may be aided by the knowledge of parameters associated with SPIT 229 sessions (e.g., methods identifying SPIT calls based on caller's 230 session rate, methods identifying SPIT requests based on session 231 originator's number of simultaneous calls, pattern-based systems, 232 etc.) in order to identify and block next SPIT session requests. 234 We report here a non-exhaustive list of parameters associated to a 235 call we envision to be important in SPIT detection: 237 o caller SIP URI; 239 o callee SIP URI; 241 o call-id; 243 o call start time (exact definition of call start time has to be 244 included); 246 o call end time (exact definition of call start time has to be 247 included); 249 o caller signaling contact address (IP address and port); 251 o callee signaling contact address (IP address and port); 253 o caller media address (IP address and port); 255 o callee media address (IP address and port); 257 o Path Information (Via, Route, Record-Route, Path headers); 259 o Alert-Info (if present in the request). 261 The scope and the usefulness of the above cited parameters depends on 262 the actual methods implemented in the system to detect and prevent 263 SPIT requests. If a solution estimating the likeliness of SPIT 264 related to a particular message is in place at the originating domain 265 then an additional header containing such information could be 266 exchanged among domains reaching also the callee's user agent. In 267 this case the SPIT likeliness score is an additional parameter the 268 SPIT identification system could also take into account. 270 4. SIP Extensions for SPIT 272 We describe here the methods we identified for sending feedbacks for 273 SPIT identification purposes. The first option we analyze is to use 274 an additional error code between SIP edge devices, e.g. When caller 275 is blacklisted by callee. The second option is to use an additional 276 header inserted in the BYE in order to tell to the callee's proxy 277 server that the call was a SPIT one for the callee. The third option 278 is to make use of the event package or of other methods to be 279 notified about SPIT events. The last option we discuss is the usage 280 of an additional header to communicate the SPIT likeliness among 281 domains and users agents. We present here such solutions discussing 282 pros and cons of each approach. 284 4.1. Error Code for SPIT 286 When the caller's SIP URI is matching a black list entry of a SIP 287 device along the path (be it a UA or a Proxy) then it can reject the 288 request with a specific error code. Propogation of this error code 289 helps the edge proxies in avoiding any further request with the same 290 originator to go to other proxies. This error code should be sent 291 back to the callee but before sending it back it may be translated to 292 400/500 generic code by one of the proxy along the path. 294 4.2. Additional Header for SPIT Feedback 296 A light-weight solution to pass feedback between a user agent and a 297 SIP server is to add an additional header in the BYE message which 298 indicates whether the session was SPIT or not. This has as a 299 consequence that only the user who actively terminates the call can 300 give a feedback. We believe this not to be a limitation since 301 whenever a user receives a call that he considers SPIT, he will most 302 probably hang up before the call itself has ended; therefore, it is 303 very likely that the callee terminates a SPIT call that has been 304 answered. At the user agent such a method could be implemented as 305 two different buttons to hang-up a call, one for a normal hang-up and 306 the second one for hanging-up a SPIT session. If the second button 307 is used, a header is added to the BYE message to indicate that the 308 session was SPIT. This header is then interpreted by the system. It 309 is advisable that a SIP server strips any SPIT-related header to keep 310 them from leaking out of the local domain as they will only be used 311 by the local server anyway. How this additional header should look 312 like and which parameters should be sent with it is dependent on the 313 SPIT detection and prevention methods actually implemented in the 314 system. Since the BYE message contains already some of the 315 parameters listed in Section 3, a possible option is to include all 316 remaining parameters in the additional header included in the BYE 317 message and then leave the system using the only ones suitable for 318 the SPIT detection methods actually. 320 Alternatively the Reason header [2] can be extended for SPIT 321 feedbacks. 323 4.3. SIP Event Package 325 The idea is that when a client registers with the server, the server 326 subscribes to the feedback of the user using the SIP event 327 notification mechanism [1]. After each call the user decides whether 328 the call was SPIT or not and provides the feedback using an 329 appropriate GUI input method at the user agent. The client then 330 sends a NOTIFY to the server with the feedback given by the user. 331 The drawback with this approach is that it is rather heavy-weight and 332 [1] states that the SIP event package should not be used for general- 333 purpose notifications. How this additional NOTIFY should look like 334 and which parameters should be sent with it is dependent on the SPIT 335 detection and prevention methods actually implemented in the system. 336 A possible option is to include all necessary parameters listed in 337 Section 3 in the NOTIFY message and then leave the system using the 338 only ones suitable for the SPIT detection methods actually 339 implemented. 341 4.4. Additional Header for Indicating Likeliness of SPIT 343 An additional header for indicating the likeliness of the SPIT could 344 also be used. It could contain a qValue between 0 (no SPIT) and 1 345 (SPIT). How the sessions requests will then be handled by the UAs or 346 proxies along the path is not in the scope of this draft. 348 Edge proxies among different providers may have different 349 administrative policies based on this value. Caller should not be 350 notified that his particular session request is considered as SPIT in 351 another domain. This header may be present when callee's system 352 rejects the session request with the specific error code to be 353 defined. The proxy responsible for the UA will remove this header 354 when forwarding this request. This value may be used for reputation 355 scores and statistical analysis by the SPIT system. 357 5. Conclusions 359 This draft attempts to identify the need for a SIP extension for 360 SPIT. It starts by examining the requirements for technical 361 solutions when dealing with SPIT identification and the parameters 362 that a SPIT system may need to know in order to detect and prevent 363 it. Moreover the document presents the usage of SPIT detection using 364 feedbacks. Alternatives how this feedback and additional information 365 could be implemented using SIP are also listed while pros and cons 366 are discussed. Object of further work is the more precise definition 367 of alternatives and the discussion about the usefulness of their 368 standardization at this point in time. 370 6. Security Considerations 372 Some session requests may be spam for some users but not for others; 373 sending feedbacks to tell the system that the callee received a SPIT 374 call is depending on the callee concept of SPIT calls (unless there 375 is an automated machine checking on behalf of the user). Security 376 considerations should be tailored to understand if the feedback 377 should apply to all users served by the system or only to the callee 378 who gave the feedback. Moreover the system should process SPIT 379 feedbacks preserving normal operations for all users and do not let 380 some "mafia" users exploiting this mechanism to create DoS attacks 381 denying users to call. This risk is anyway lowered by the fact that 382 the mechanisms proposed for sending the feedback to the system are 383 specific to a single call and not general, i.e., only the callee or 384 the SIP proxy servers can give a SPIT feedback to the caller. 386 7. IPR Considerations 388 Please note that an IPR disclosure that pertains to this Internet- 389 Draft was submitted to the IETF Secretariat on 2006-08-16 and has 390 been posted on the "IETF Page of Intellectual Property Rights 391 Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The 392 title of the IPR disclosure is "Nortel Networks Statement about IPR 393 claimed in draft-niccolini-sipping-feedback-spit-01." 395 8. IANA Considerations 397 This document does not require IANA actions. 399 9. References 401 9.1. Normative References 403 [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 404 Notification", RFC 3265, June 2002. 406 9.2. Informative References 408 [2] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header 409 Field for the Session Initiation Protocol (SIP)", RFC 3326, 410 December 2002. 412 [3] Rosenberg, J., Jennings, C., and J. Peterson, "The Session 413 Initiation Protocol (SIP) and Spam", 414 draft-ietf-sipping-spam-03.txt (work in progress), October 2006. 416 [4] Schwartz, D., Sterman, B., Katz, E., and H. Tschofenig, "SPAM 417 for Internet Telephony (SPIT) Prevention using the Security 418 Assertion Markup Language (SAML)", 419 draft-schwartz-sipping-spit-saml-01.txt (work in progress), 420 June 2006. 422 [5] Moriarty, K., "Incident Handling: Real-time Inter-network 423 Defense", draft-ietf-inch-rid-08 (work in progress), 424 August 2006. 426 Authors' Addresses 428 Saverio Niccolini 429 Network Laboratories, NEC Europe Ltd. 430 Kurfuersten-Anlage 36 431 Heidelberg 69115 432 Germany 434 Phone: +49 (0) 6221 4342 118 435 Email: saverio.niccolini@netlab.nec.de 436 URI: http://www.netlab.nec.de 438 Sandra Tartarelli 439 Network Laboratories, NEC Europe Ltd. 440 Kurfuersten-Anlage 36 441 Heidelberg 69115 442 Germany 444 Phone: +49 (0) 6221 4342 132 445 Email: sandra.tartarelli@netlab.nec.de 446 URI: http://www.netlab.nec.de 448 Martin Stiemerling 449 Network Laboratories, NEC Europe Ltd. 450 Kurfuersten-Anlage 36 451 Heidelberg 69115 452 Germany 454 Phone: +49 (0) 6221 4342 113 455 Email: stiemerling@netlab.nec.de 456 URI: http://www.netlab.nec.de 458 Samir Srivastava 459 Nortel Networks 460 4655 Great America Parkway 461 Santa Clara, CA 95054 462 US 464 Phone: +1 408 495 5143 465 Email: samirsr@nortel.com 467 Full Copyright Statement 469 Copyright (C) The IETF Trust (2007). 471 This document is subject to the rights, licenses and restrictions 472 contained in BCP 78, and except as set forth therein, the authors 473 retain all their rights. 475 This document and the information contained herein are provided on an 476 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 477 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 478 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 479 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 480 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 481 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 483 Intellectual Property 485 The IETF takes no position regarding the validity or scope of any 486 Intellectual Property Rights or other rights that might be claimed to 487 pertain to the implementation or use of the technology described in 488 this document or the extent to which any license under such rights 489 might or might not be available; nor does it represent that it has 490 made any independent effort to identify any such rights. Information 491 on the procedures with respect to rights in RFC documents can be 492 found in BCP 78 and BCP 79. 494 Copies of IPR disclosures made to the IETF Secretariat and any 495 assurances of licenses to be made available, or the result of an 496 attempt made to obtain a general license or permission for the use of 497 such proprietary rights by implementers or users of this 498 specification can be obtained from the IETF on-line IPR repository at 499 http://www.ietf.org/ipr. 501 The IETF invites any interested party to bring to its attention any 502 copyrights, patents or patent applications, or other proprietary 503 rights that may cover technology that may be required to implement 504 this standard. Please address the information to the IETF at 505 ietf-ipr@ietf.org. 507 Acknowledgment 509 Funding for the RFC Editor function is provided by the IETF 510 Administrative Support Activity (IASA).