SIPPING Working Group S. Niccolini Internet-Draft S. Tartarelli Intended status: Informational M. Stiemerling Expires: August 27, 2007 NEC S. Srivastava Nortel Networks February 23, 2007 SIP Extensions for SPIT identification draft-niccolini-sipping-feedback-spit-03 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 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Niccolini, et al. Expires August 27, 2007 [Page 1] Internet-Draft SIP Extensions for SPIT February 2007 Abstract This memo analyzes the need for SIP extensions for SPIT (Spam Over Internet telephony) identification. This memo describes requirements and gives an overview of possible solutions to send feedback information using the SIP protocol for the scope of SPIT. 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. The overall SPIT protection systems on the internet will benefit from such information. The basic idea is that each user who receives a SPIT session request, will send a feedback to SPIT identification system (for example, using a button on the user interface of the client). Information could be also exchanged among domains and/or servers in order to increase effectiveness of SPIT detection systems. The idea is that SIP proxy servers and/or B2BUAs include SPIT likeliness estimations (based on some knowledge they have which is out of the scope of this draft) as additional message headers (e.g. INVITE headers) when forwarding such messages to other domains. 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. The memo also addresses the technical solutions on how forward information could be passed among domains as well as how communication initiation could be denied to users (e.g. blacklisted ones). Niccolini, et al. Expires August 27, 2007 [Page 2] Internet-Draft SIP Extensions for SPIT February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements for SPIT Identification using Feedbacks . . . . . 6 3. Parameters for SPIT Detection and Prevention . . . . . . . . . 7 4. SIP Extensions for SPIT . . . . . . . . . . . . . . . . . . . 8 4.1. Error Code for SPIT . . . . . . . . . . . . . . . . . . . 8 4.2. Additional Header for SPIT Feedback . . . . . . . . . . . 8 4.3. SIP Event Package . . . . . . . . . . . . . . . . . . . . 9 4.4. Additional Header for Indicating Likeliness of SPIT . . . 9 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IPR Considerations . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Niccolini, et al. Expires August 27, 2007 [Page 3] Internet-Draft SIP Extensions for SPIT February 2007 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 [3] have calculated that these costs will significantly reduce for voice call carried over the Internet Protocol (IP). Moreover significantly reduced cost of international calls will enable spams to be originated from the countries where do not call lists does not apply. When referring to multimedia communications the spam is commonly referred to as SPIT (SPam over Internet Telephony). In order to provide additional value and to start using a common set of terms, we define the following taxonomy in the scope of this memo: o SPIT (SPam over Internet Telephony) for unsolicited voice/video calls o SPIM (SPam Over Instant Messaging) for unsolicited instant messages. o SPOP (SPam Over Presence) for unsolicited presence event SUBSCRIBE requests. o SPOF (SPam Over Fax) for unsolicited Fax calls. o SPOM (SPam Over Multimedia) for unsolicited session request, where type of media is not relevant. This memo currently focuses on SPIT because it is the most actual threat to be addressed in author's opinion. The SPIT threat is currently gaining attention in the community and several solutions to counter this threat are currently being analyzed [3] and proposed [4]. The SPIT identification system is referred as "SPIT system" in this document. The SPIT system 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. This memo analyzes the need for SIP extensions for SPIT identification after presenting a list of parameters that a SPIT identification system may need to know in order to detect and prevent SPIT session requests. As per the lessons learnt from Anti-Virus and email Anti-SPAM security products, there will be the case when SPIT systems will not able to detect the SPIT calls. SPIT systems will require feedbacks from users. Apart from the feedback being used for reputation system and personal filters, these feedback will be useful for further Niccolini, et al. Expires August 27, 2007 [Page 4] Internet-Draft SIP Extensions for SPIT February 2007 avoiding massive spread of SPIT in other provider's network. Providers can share this information either via SIP signaling or by extending the mechanisms defined in [5]. It is not good to have other XML schema and/or protocols for reporting SPAM on the SIP UA as it will require additional resource. Using the SIP mechanism is better choice from the deployment prespectives, otherwise out-of-band mechanism's topology and SIP topology needs to be in synchronization and network traffic is optimized. When some session requests are not detected as SPIT by the SPIT system, the callee picks up the call and realizes that he received an unsolicited session request. After having realized that the session was a SPIT one, the callee decides to terminate the session with a special button that informs the system that a SPIT session request was just delivered. This feedback could be as well sent by an answering machine which answers the session request instead of the callee and decides whether the session request was a SPIT one or not sending afterwards the feedback to the SPIT system. Other possible methods to fight SPIT could be to add a SPIT likeliness score as additional header that the destination domain could use for prevention scopes when deciding about the session. SPIT likeliness can be used in addition to present the requirements and the parameters for SPIT prevention, we analyze and propose different methods on how such information could be exchanged among proxy servers and user agents using SIP. Niccolini, et al. Expires August 27, 2007 [Page 5] Internet-Draft SIP Extensions for SPIT February 2007 2. Requirements for SPIT Identification using Feedbacks There are some important requirements for the mechanism above cited 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 and the forward information should look like; o which are the methods best suited to carry such information; o how the SIP entities should behave when dealing with such messages. We report here a first non-exhaustive list of requirements that we identified in the context of SPIT identification using feedbacks and forward information: o SIP user agents do not know if the 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. o the SPIT likeliness information about a certain call should also be forwarded to the callee since some of the identification and prevention methods could be integrated with the callee's user agent; o the SPIT likeliness information should not notify the caller, either the message containing such information should have only a scope valid for the SPIT identification system or such information should be stripped from the SIP message before forwarding it back to the originating party. o the information the originating domain/party should receive back regarding the call should be at most a reason explaining why the call was rejected (e.g. using an error code to be defined) Niccolini, et al. Expires August 27, 2007 [Page 6] Internet-Draft SIP Extensions for SPIT February 2007 3. 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 session requests. In addition to the methods detailed in [3] there are other methods that may be aided by the knowledge of parameters associated with SPIT sessions (e.g., methods identifying SPIT calls based on caller's session rate, methods identifying SPIT requests based on session originator's number of simultaneous calls, pattern-based systems, etc.) in order to identify and block next SPIT session requests. 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; 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); o Path Information (Via, Route, Record-Route, Path headers); o Alert-Info (if present in the request). The scope and the usefulness of the above cited parameters depends on the actual methods implemented in the system to detect and prevent SPIT requests. If a solution estimating the likeliness of SPIT related to a particular message is in place at the originating domain then an additional header containing such information could be exchanged among domains reaching also the callee's user agent. In this case the SPIT likeliness score is an additional parameter the SPIT identification system could also take into account. Niccolini, et al. Expires August 27, 2007 [Page 7] Internet-Draft SIP Extensions for SPIT February 2007 4. SIP Extensions for SPIT We describe here the methods we identified for sending feedbacks for SPIT identification purposes. The first option we analyze is to use an additional error code between SIP edge devices, e.g. When caller is blacklisted by callee. The second option is to use an additional header inserted in the BYE in order to tell to the callee's proxy server that the call was a SPIT one for the callee. The third option is to make use of the event package or of other methods to be notified about SPIT events. The last option we discuss is the usage of an additional header to communicate the SPIT likeliness among domains and users agents. We present here such solutions discussing pros and cons of each approach. 4.1. Error Code for SPIT When the caller's SIP URI is matching a black list entry of a SIP device along the path (be it a UA or a Proxy) then it can reject the request with a specific error code. Propogation of this error code helps the edge proxies in avoiding any further request with the same originator to go to other proxies. This error code should be sent back to the callee but before sending it back it may be translated to 400/500 generic code by one of the proxy along the path. 4.2. Additional Header for SPIT Feedback A light-weight solution to pass feedback between a user agent and a SIP server is to add an additional header in the BYE message which indicates whether the session 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 session. If the second button is used, a header is added to the BYE message to indicate that the session 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 parameters listed in Section 3, 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 Niccolini, et al. Expires August 27, 2007 [Page 8] Internet-Draft SIP Extensions for SPIT February 2007 the SPIT detection methods actually. Alternatively the Reason header [2] can be extended for SPIT feedbacks. 4.3. 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 3 in the NOTIFY message and then leave the system using the only ones suitable for the SPIT detection methods actually implemented. 4.4. Additional Header for Indicating Likeliness of SPIT An additional header for indicating the likeliness of the SPIT could also be used. It could contain a qValue between 0 (no SPIT) and 1 (SPIT). How the sessions requests will then be handled by the UAs or proxies along the path is not in the scope of this draft. Edge proxies among different providers may have different administrative policies based on this value. Caller should not be notified that his particular session request is considered as SPIT in another domain. This header may be present when callee's system rejects the session request with the specific error code to be defined. The proxy responsible for the UA will remove this header when forwarding this request. This value may be used for reputation scores and statistical analysis by the SPIT system. Niccolini, et al. Expires August 27, 2007 [Page 9] Internet-Draft SIP Extensions for SPIT February 2007 5. Conclusions This draft attempts to identify the need for a SIP extension for SPIT. It starts by examining the requirements for technical solutions when dealing with SPIT identification and the parameters that a SPIT system may need to know in order to detect and prevent it. Moreover the document presents the usage of SPIT detection using feedbacks. Alternatives how this feedback and additional information could be implemented using SIP are also listed while pros and cons are discussed. Object of further work is the more precise definition of alternatives and the discussion about the usefulness of their standardization at this point in time. Niccolini, et al. Expires August 27, 2007 [Page 10] Internet-Draft SIP Extensions for SPIT February 2007 6. Security Considerations Some session requests may be spam for some users but not for others; sending feedbacks 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 or the SIP proxy servers can give a SPIT feedback to the caller. Niccolini, et al. Expires August 27, 2007 [Page 11] Internet-Draft SIP Extensions for SPIT February 2007 7. IPR Considerations Please note that an IPR disclosure that pertains to this Internet- Draft was submitted to the IETF Secretariat on 2006-08-16 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Nortel Networks Statement about IPR claimed in draft-niccolini-sipping-feedback-spit-01." Niccolini, et al. Expires August 27, 2007 [Page 12] Internet-Draft SIP Extensions for SPIT February 2007 8. IANA Considerations This document does not require IANA actions. Niccolini, et al. Expires August 27, 2007 [Page 13] Internet-Draft SIP Extensions for SPIT February 2007 9. References 9.1. Normative References [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 9.2. Informative References [2] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. [3] Rosenberg, J., Jennings, C., and J. Peterson, "The Session Initiation Protocol (SIP) and Spam", draft-ietf-sipping-spam-03.txt (work in progress), October 2006. [4] Schwartz, D., Sterman, B., Katz, E., and H. Tschofenig, "SPAM for Internet Telephony (SPIT) Prevention using the Security Assertion Markup Language (SAML)", draft-schwartz-sipping-spit-saml-01.txt (work in progress), June 2006. [5] Moriarty, K., "Incident Handling: Real-time Inter-network Defense", draft-ietf-inch-rid-08 (work in progress), August 2006. Niccolini, et al. Expires August 27, 2007 [Page 14] Internet-Draft SIP Extensions for SPIT February 2007 Authors' Addresses Saverio Niccolini Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 118 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 4342 132 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 4342 113 Email: stiemerling@netlab.nec.de URI: http://www.netlab.nec.de Samir Srivastava Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US Phone: +1 408 495 5143 Email: samirsr@nortel.com Niccolini, et al. Expires August 27, 2007 [Page 15] Internet-Draft SIP Extensions for SPIT February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Niccolini, et al. Expires August 27, 2007 [Page 16]