SIPPING Working Group S. Niccolini Internet-Draft S. Tartarelli Expires: August 5, 2006 M. Stiemerling NEC February 2006 Requirements and methods for SPIT identification using feedbacks in SIP draft-niccolini-sipping-feedback-spit-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes requirements and gives an overview of possible solutions to send feedbacks using the SIP protocol for the scope of SPIT (SPam over Internet Telephony) identification. Feedback information from the users to the SPIT identification system (e.g., working closely with the callee's SIP proxy server) are important for SPIT detection and prevention and the overall system could benefit from such information and increase its effectiveness. The basic idea Niccolini, et al. Expires August 5, 2006 [Page 1] Internet-Draft SIP Feedback for SPIT February 2006 is that each user who receives a SPIT call reports it to the SPIT identification system (for example, using a button on the user interface of the client). This memo identifies the parameters that the SPIT identification system may need in order to detect abusive behaviors; moreover it proposes an overview of technical solutions how such information can be sent back to the SPIT identification system by means of the SIP protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements for SPIT Identification using Feedbacks . . . . . 4 2.1. Parameters for SPIT Detection and Prevention . . . . . . . 4 3. Methods for sending SPIT Feedback using the SIP Protocol . . . 6 3.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 6 3.2. Additional Header for SPIT Feedback . . . . . . . . . . . 6 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Niccolini, et al. Expires August 5, 2006 [Page 2] Internet-Draft SIP Feedback for SPIT February 2006 1. Introduction The spam problem is well known in the email world. Voice communications carried over the traditional PSTN are not largely suffering from unsolicited telemarketing calls because of the big costs an originator has to encounter to send voice spam over circuit switched networks. Recent studies [2] have calculated that these costs will significantly reduce for voice call carried over the Internet Protocol (IP). When referring to voice communications the spam is commonly referred to as SPIT (SPam over Internet Telephony). Given that the Session Initiation Protocol (SIP) is used to initiate, among others, voice communications, it will be vulnerable to SPIT as the email is to spam. The SPIT threat is currently gaining attention in the community and several solutions to counter this threat are currently being analyzed [2] and proposed [3]. This memo analyzes the requirements for SPIT identification using feedbacks, moreover it presents a list of parameters that a SPIT identification system may need to know in order to detect and prevent SPIT calls. The SPIT identification system (referred to as "the system" in the rest of this document) is supposed to work closely with the SIP infrastructure (e.g., with the callee's SIP proxy server or with other SIP entities) and to make use of SIP signaling. The basic idea is that when some calls are not detected as SPIT by the system, the callee picks up the call and realizes that he received an unsolicited telemarketing call. After having realized that the call was a SPIT one, the callee decides to hung up the call with a special button that informs the system that a SPIT call was just delivered. This feedback could be as well sent by an answering machine which answers the call instead of the callee and decides whether the call was a SPIT one or not sending afterwards the feedback to the system. In addition to presenting the requirements and the parameters for SPIT prevention, we propose two methods on how this feedback could be sent back to the system using the SIP. Niccolini, et al. Expires August 5, 2006 [Page 3] Internet-Draft SIP Feedback for SPIT February 2006 2. Requirements for SPIT Identification using Feedbacks There are some important requirements for the feedback mechanism to be taken into account when used for SPIT identification. The identification of requirements is necessary to understand: o how SIP messages carrying the feedback itself should look like; o which are the methods best suited to carry such feedback; o how the SIP entities should behave when dealing with such feedbacks messages. We report here a first non-exhaustive list of requirements that we identified in the context of SPIT identification using feedbacks: o SIP user agents do not know if the handling SPIT identification system is working either in stateless or in stateful mode and therefore the feedback must contain all necessary parameters both to non-ambiguous identify the call and to serve as input for SPIT identification methods; o the feedback should not notify the caller that the call was recognized to be SPIT by the terminating user agent, either the message containing the feedback should have only a scope valid for the SPIT identification system or the information related to the feedback should be stripped from the SIP message before forwarding it to the originating party. 2.1. Parameters for SPIT Detection and Prevention The parameters described here are intended to be a list of parameters the system could need to know in order to detect and prevent the delivery of next SPIT calls. In addition to the methods detailed in [2] there are other methods that may be aided by the knowledge of parameters associated with SPIT calls (e.g., methods identifying SPIT calls based on caller's call rate, methods identifying SPIT calls based on caller's number of simultaneous calls, pattern-based systems, etc.) in order to identify and block next SPIT calls. We report here a non-exhaustive list of parameters associated to a call we envision to be important in SPIT detection: o caller SIP URI; Niccolini, et al. Expires August 5, 2006 [Page 4] Internet-Draft SIP Feedback for SPIT February 2006 o callee SIP URI; o call-id; o call start time (exact definition of call start time has to be included); o call end time (exact definition of call start time has to be included); o caller signaling contact address (IP address and port); o callee signaling contact address (IP address and port); o caller media address (IP address and port); o callee media address (IP address and port). The scope and the usefulness of the above cited parameters depends on the actual methods implemented in the system to detect and prevent SPIT calls. Niccolini, et al. Expires August 5, 2006 [Page 5] Internet-Draft SIP Feedback for SPIT February 2006 3. Methods for sending SPIT Feedback using the SIP Protocol We describe here two methods we identified for sending feedbacks for SPIT identification purposes. We identified an already standardized method for the SIP protocol (SIP event package) and a second one based on an additional SIP header for sending feedbacks for SPIT purposes. We present here both solutions and discuss pros and cons of each approach. 3.1. SIP Event Package The idea is that when a client registers with the server, the server subscribes to the feedback of the user using the SIP event notification mechanism [1]. After each call the user decides whether the call was SPIT or not and provides the feedback using an appropriate GUI input method at the user agent. The client then sends a NOTIFY to the server with the feedback given by the user. The drawback with this approach is that it is rather heavy-weight and [1] states that the SIP event package should not be used for general- purpose notifications. How this additional NOTIFY should look like and which parameters should be sent with it is dependent on the SPIT detection and prevention methods actually implemented in the system. A possible option is to include all necessary parameters listed in Section 2.1 in the NOTIFY message and then leave the system using the only ones suitable for the SPIT detection methods actually implemented. This issue is anyway left open for further discussion. 3.2. Additional Header for SPIT Feedback A light-weight solution to passing feedback between a user agent and a SIP server is to add an additional header in the BYE message which indicates whether the call was SPIT or not. This has as a consequence that only the user who actively terminates the call can give a feedback. We believe this not to be a limitation since whenever a user receives a call that he considers SPIT, he will most probably hang up before the call itself has ended; therefore, it is very likely that the callee terminates a SPIT call that has been answered. At the user agent such a method could be implemented as two different buttons to hang-up a call, one for a normal hang-up and the second one for hanging-up a SPIT call. If the second button is used, a header is added to the BYE message to indicate that the call was SPIT. This header is then interpreted by the system. It is advisable that a SIP server strips any SPIT-related header to keep them from leaking out of the local domain as they will only be used by the local server anyway. How this additional header should look like and which parameters should be sent with it is dependent on the SPIT detection and prevention methods actually implemented in the system. Since the BYE message contains already some of the Niccolini, et al. Expires August 5, 2006 [Page 6] Internet-Draft SIP Feedback for SPIT February 2006 parameters listed in Section 2.1, a possible option is to include all remaining parameters in the additional header included in the BYE message and then leave the system using the only ones suitable for the SPIT detection methods actually implemented. This issue is anyway left open for further discussion. Niccolini, et al. Expires August 5, 2006 [Page 7] Internet-Draft SIP Feedback for SPIT February 2006 4. Conclusions This draft attempts to identify the requirements for a standard way of sending user agent feedback using the Session Initiation Protocol (SIP) for the purpose of SPam over Internet Telephony (SPIT) identification. The document starts by examining the requirements in terms of parameters that a system may need to know in order to detect and prevent SPIT calls. Moreover the document presents two alternatives how this feedback could be implemented using SIP (namely using the SIP event package or using an additional header). The detailed analysis of the all the parameters that need to be included either in the NOTIFY message or in the additional header and their syntax will be topic for future work. Niccolini, et al. Expires August 5, 2006 [Page 8] Internet-Draft SIP Feedback for SPIT February 2006 5. Security Considerations Some calls may be SPIT for some users but not for others and sending feedback to tell the system that the callee received a SPIT call is depending on the callee concept of SPIT calls (unless there is an automated machine checking on behalf of the user). Security considerations should be tailored to understand if the feedback should apply to all users served by the system or only to the callee who gave the feedback. Moreover the system should process SPIT feedbacks preserving normal operations for all users and do not let some "mafia" users exploiting this mechanism to create DoS attacks denying users to call. This risk is anyway lowered by the fact that the mechanisms proposed for sending the feedback to the system are specific to a single call and not general, i.e., only the callee can give a SPIT feedback to the caller. Niccolini, et al. Expires August 5, 2006 [Page 9] Internet-Draft SIP Feedback for SPIT February 2006 6. References 6.1. Normative References [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 6.2. Informative References [2] Rosenberg, J., Jennings, C., and J. Peterson, "The Session Initiation Protocol (SIP) and Spam", DRAFT draft-ietf-sipping-spam-01.txt, July 2005. [3] Schwartz, D., Sterman, B., Katz, E., and H. Tschofenig, "SPAM for Internet Telephony (SPIT) Prevention using the Security Assertion Markup Language (SAML)", DRAFT draft-schwartz-sipping-spit-saml-00.txt, October 2005. Niccolini, et al. Expires August 5, 2006 [Page 10] Internet-Draft SIP Feedback for SPIT February 2006 Authors' Addresses Saverio Niccolini Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 18 Email: saverio.niccolini@netlab.nec.de URI: http://www.netlab.nec.de Sandra Tartarelli Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 32 Email: sandra.tartarelli@netlab.nec.de URI: http://www.netlab.nec.de Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 13 Email: stiemerling@netlab.nec.de URI: http://www.netlab.nec.de Niccolini, et al. Expires August 5, 2006 [Page 11] Internet-Draft SIP Feedback for SPIT February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Niccolini, et al. Expires August 5, 2006 [Page 12]