SIPPING Working Group S. Niccolini Internet-Draft J. Quittek Expires: July 15, 2007 NEC January 11, 2007 Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario draft-niccolini-sipping-spitstop-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. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 July 15, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract This memo discusses the need for standards that support SPam over Internet Telephony (SPIT) prevention applications. After explaining the general need for SPIT prevention applications the memo provides a reference scenario for potential communication between entities that may be involved in SPIT prevention. Within this scenario the need Niccolini & Quittek Expires July 15, 2007 [Page 1] Internet-Draft SPITSTOP Reference Scenario January 2007 for standardizing communication is analyzed for each pair of communicating entities. The analysis is intended to serve as a starting point for discussing the requirements for signaling standards, for example, SIP extensions, that support SPIT prevention applications. This memo is not intended to suggest any solution of SPIT signaling issues. Such work, if necessary at all, would be subject of separate follow-up documents. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The SPIT Threat . . . . . . . . . . . . . . . . . . . . . 3 1.2. Communication Need for SPIT Prevention . . . . . . . . . . 4 2. Reference Scenario . . . . . . . . . . . . . . . . . . . . . . 5 3. Signaling Interfaces Considerations . . . . . . . . . . . . . 8 3.1. Interfaces on the Signaling Path . . . . . . . . . . . . . 8 3.1.1. Downstream . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Upstream . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Off-Path Interfaces between Proxy Servers . . . . . . . . 12 3.3. Interfaces to Special SPIT Prevention Entities . . . . . . 13 4. Need for Standardization . . . . . . . . . . . . . . . . . . . 14 4.1. Preliminary Protocol Considerations . . . . . . . . . . . 14 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Niccolini & Quittek Expires July 15, 2007 [Page 2] Internet-Draft SPITSTOP Reference Scenario January 2007 1. Introduction Email is an essential means for world-wide communication. The openness of the Internet make use of email easy but also makes it easy to mis-use it, particular to annoy users with spam email. Today, there is more spam email transmitted by the public Internet than regular email. Internet telephony is on its way to replace the traditional circuit- switched telephony. There is a strong concern that this migration to the open Internet will result in Spam over Internet Telephony (SPIT) that potentially will be annoy the users even more than spam email does today. If there are more SPIT calls than regular calls in the telephony world, then phones will ring all day making it hard to use this medium in a convenient and productive way. This memo discusses the need for producing standards that help preventing SPIT in the future. Although SPIT is not an actual problem today, it has a big potential to become one very soon. At this point in time it will be good to be prepared and have technology already available that protects users from SPIT. 1.1. The SPIT Threat Most of the spam emails are generated by so-called bot nets. Bot nets are networks of hosts that have been invaded by a spammer in order to use them for sending spam email without the knowledge of or admission by the regular administrators of these hosts. Bot nets can easily be used for initiating spam voice calls instead of or in addition to sending spam email. Today, there is already voice spam in the switched telephony network. Many households in Europe receive between 1 and 10 automated spam calls per month. During such a call, a prerecorded messages is played to the callee without supporting any interaction. However, these calls create significant cost for the caller, at least if they are made in numbers of thousands or hundred thousands. With the ongoing migration from traditional connection-switched telephony to packet-switched Internet telephony the cost of spam calls will drop drastically. The infrastructure for generating Spam over Internet Telephony (SPIT) is already there in form of the existing bot nets. A recent study [I-D.ietf-sipping-spam] estimated that the cost per delivery of SPIT call will be three order of magnitude cheaper than the costs per delivery of spam over circuit- switched telephony. This is expected to cause a flood of SPIT calls as soon as Internet telephony becomes the dominating telephony technology. Niccolini & Quittek Expires July 15, 2007 [Page 3] Internet-Draft SPITSTOP Reference Scenario January 2007 For dealing with this problem, particularly for preventing unwanted SPIT, not all methods that are used today for blocking spam email can be applied. Particularly, content checking, that is a basic method for detecting email spam, is not applicable, because content of a call is not available for checking before the phone rings. And stopping the phone from ringing for spam calls is one of the major goals of SPIT prevention. Therefore, further methods are needed. An overview of methods that are currently available for SPIT prevention is given in [I-D.ietf-sipping-spam]. The number of SPIT prevention methods listed there is quite large. Still, it is not considered to be a complete list or a list that is exhaustive enough for preventing SPIT sufficiently. In the contrary, this list shows that there are still a lot of opportunities left for SPIT generators to place SPIT calls successfully. 1.2. Communication Need for SPIT Prevention An important aspect in this context has not been investigated in detail yet. It is sharing of information between entities that are involved in preventing SPIT. They may have a need to exchange information related to SPIT. The range of information to be exchanged includes information about o SPIT events that actually occurred, o likeliness or indicators concerning callers to be sources of SPIT, o likeliness or indicators concerning concrete calls to be SPIT, o etc. This memo investigates the need of communication between entities involved in SPIT prevention and the need of standards for this communication. For this purpose, a reference scenario is defined in Section 2 that serves for identifying which communications interfaces may be required for sharing SPIT-related information between involved entities. Based on this scenario, requirements for individual interfaces are discussed in Section 3. Currently, the requirements are stated on a high level. Future revisions of this memo may elaborate the requirements in more detail. Which (kind of) communication protocol should be chosen for meeting the requirements is not subject of this memo. However, this memo is supposed to stimulate discussion on the need of standardization work in this area. The standardization work should both identify the best suited protocols for such information sharing at each interface and if extensions to such protocols for the support of SPIT information sharing is needed. If no suitable protocols matching the requirements for a particular interface is found a Niccolini & Quittek Expires July 15, 2007 [Page 4] Internet-Draft SPITSTOP Reference Scenario January 2007 suggestion for the design of a new protocol suited to such information sharing should be initiated. 2. Reference Scenario For our reference scenario we consider four kinds of communicating entities: o the caller User Agent (UA) that generates SPIT, o Proxy Servers (PS) forwarding call signaling, o specialized SPIT prevention entities, o the callee User Agent (UA). With the goal of avoiding that the callee's phone rings for SPIT calls, a goal of SPIT prevention is detecting a SPIT message already based on the INVITE method that is sent in order to initiate the SPIT call. This goal can only be achieved along the path the INVITE message is forwarded from the caller towards the callee. This path starts at the caller UA, then potentially includes a set of forwarding PS, and terminates latest at the callee UA. Please note that the described reference scenario does not addresses management interfaces to entities involved in SPIT prevention. A first approach to this issue has been made is described in [I-D.froment-sipping-spit-authz-policies]. Niccolini & Quittek Expires July 15, 2007 [Page 5] Internet-Draft SPITSTOP Reference Scenario January 2007 +--------+ | | | caller | | UA | | | +--------+ |d ^ # | ^ |o | # | | |w |u # | | |n |p # -------(a) |s |s # | | |t |t # | | |r |r (d) V v | (e) |e |e +--------+ | +--------+ | +--------+ |a |a | | | | | | | SPIT | |m |m | Other |<---|----| Proxy |----|--->| Prev. | | | | Proxy |----|--->| Server |<---|----| Entity | v | | | | | | | | | +--------+ +--------+ +--------+ # | ^ # | | # | | # -------(b) # S # | | # I # | | # P (d) V v | (e) # +--------+ | +--------+ | +--------+ # I | | | | | | | SPIT | # N | Other |<---|----| Proxy |----|--->| Prev. | # V | Proxy |----|--->| Server |<---|----| Entity | # I | | | | | | | | # T +--------+ +--------+ +--------+ # E # | ^ # # | | # m # | | # e # -------(c) # t # | | # h # | | # o V v | (f) # d +--------+ | +--------+ # | | | | SPIT | V | callee |----|--->| Prev. | | UA |<---|----| Entity | | | | | | +--------+ +--------+ Figure 1: SPIT prevention reference scenario with two proxy servers Niccolini & Quittek Expires July 15, 2007 [Page 6] Internet-Draft SPITSTOP Reference Scenario January 2007 Entities on this path may share information related to SPIT prevention. Related communication may happen already before a certain INVITE methods is transmitted or it may be initiated by this message. If this communication includes transmitting information in the same direction as the INVITE message along the path, then we talk about downstream communication. Transmitting information in the opposite direction we call upstream communication. The SPIT prevention reference scenario shown in Figure 1 contains a caller UA, a callee UA and two PS on the path of the INVITE message from caller UA to callee UA. This number of PS was chosen because it contains exactly one instance of each pair of interacting kinds of entities along the path of the INVITE message: o at interface (a) the caller UA is interacting with a PS, o at interface (b) two consecutive PS are interacting with each other, o at interface (c) a PS is interacting with the callee UA. The number of two PS matched the common SIP signaling trapezoid. However, any number of proxy servers greater than zero can be applied to the scenario. If there is only one PS present, then the interface (b) is not instantiated. If there are two or more PS on the path, then interface (b) is used between each consecutive pair of them. In general, the INVITE message could be sent directly from caller UA to callee UA without involving any PS. A direct call would be possible if the caller UA sends the INVITE directly to the callee UA, anyway such IP address retrieval is prone to errors either because of possible change of IP address during time of callee UA or because of Network Address Translator along the path masking the real IP address. The direct call case becomes even less relevant if the callee UAs are configured to accept INVITEs only from their proxy servers. For these reasons we decided not to include an interface for direct communication between caller UA and callee UA in the reference scenario. This issues is also been addressed by work on authentication between inbound proxy and the caller UA in [I-D.jung- sipping-authentication-spit] Each proxy server on the signaling path of the INVITE message may communicate with off-path entities in order to perform the task of SPIT prevention. These entities include one or more specific SPIT prevention entities that are consulted by the proxy server using interface (e) in order to get an indication or estimation of the probability of a given INVITE message to belong to a SPIT call. These entities also include one or more cooperating PS with which Niccolini & Quittek Expires July 15, 2007 [Page 7] Internet-Draft SPITSTOP Reference Scenario January 2007 information about SPIT calls (or call attempts, resp.) is shared using interface (d) in order to improve the SPIT prevention performance. An example for such a cooperation would be a set of PS in a single administrative domain sharing information about known sources of SPIT. The callee UA may also interact with a specific SPIT prevention entity similar to the PS. Since in this case, the offered service might be more personalized than in the case of the PS, we use a different interface (f) for our reference model. This does not preclude that instantiations of (e) and (f) may have identical functions. 3. Signaling Interfaces Considerations This section discusses the interactions between entities of the reference scenario that is shown in Figure 1. The interfaces are grouped into three sections. 1. The first one deals with interfaces (a), (b), and (c) which all serve for exchanging information between consecutive entities along the path of the INVITE message of a particular call. 2. Interface (d) has a similar function but is off-path and not necessarily related to individual (SPIT) calls. 3. Interfaces (e) and (f) are used by PS or the callee UA when they need to decide whether or not to consider a particular call request as SPIT. 3.1. Interfaces on the Signaling Path At all three interfaces (a), (b), and (c) information may be exchanged in upstream direction as well as in downstream direction. 3.1.1. Downstream There are several considerations of downstream communication that apply to all three interfaces. We first describe them before pointing out differences between the three interfaces. All Interfaces (a), (b), and (c) Downstream information is sent along with an INVITE in order to indicate an estimation of the likelihood of the INVITE to belong to a SPIT call. A sender or forwarder of an INVITE may, for example, be able to make such an estimation, but still not have sufficient certainty or not have legal rights for blocking a SPIT call. Niccolini & Quittek Expires July 15, 2007 [Page 8] Internet-Draft SPITSTOP Reference Scenario January 2007 In any case, interface (a), (b), or (c) would allow to pass such an estimation further along the path of the INVITE. Even if such information does not always lead to achieving a clear idea on the nature of the requested call, the transmitted estimations can be recorded by the receivers of this information and used for improving future judgments of call requests for SPIT prevention. In addition to the estimation of the likelihood of the INVITE to belong to a SPIT call such interfaces would allow to pass statistics about the recent behavior of the sender. An example of these statistics would consist in the rate of (SPIT) calls initiated by the sender during the last time slot, the ratio between regular calls and SPIT calls initiated by the sender during the last time slot, etc. The above mentioned statistics can also be bundled together and passed only after the expiration of a timeout in order to increase scalability. Besides the estimation and the statistics itself, also the source of the estimation may be transmitted. This way, an entity can indicate, whether it has been involved in producing the estimate, or just forwarded the received estimation along the path of the INVITE. Interface (a) This interface is instantiated between the caller UA and the first PS along the INVITE path. The relevance of interface (a) seems to be rather limited. It does not seem a good idea to have the caller UA neither estimating itself the likelihood of the INVITE to belong to a SPIT call not transmitting statistics about the its recent behavior. Moreover the instantiation of such an interface could be maliciously used by entities initiating SPIT without the PS having the proper means to judge if the information passed is trustable or not. Interface (b) This interface is instantiated if there are two or more PS on the path. In this case interface (b) is used between each consecutive pair of them. It is used to send downstream information about the likelihood of an INVITE to belong to a SPIT call and about most relevant statistics of the INVITE initiator recent behavior. If also the source of the estimation and statistics is transmitted, a receiving PS may be able to judge how much trust to associate with the indications based on local policies. Still depending on local policies and legal rights the PS can decide to carry out additional tests on the INVITE, initiate communication to other Niccolini & Quittek Expires July 15, 2007 [Page 9] Internet-Draft SPITSTOP Reference Scenario January 2007 entities (see Section 3.2 or Section 3.3), or block the call. Interface (c) This interface is instantiated between the last PS and the callee UA. It is used to send downstream information about the likelihood of an INVITE to belong to a SPIT call and about most relevant statistics of the INVITE initiator recent behavior. If also the source of the estimation and statistics is transmitted, the callee UA can judge how much trust to associate to the indications based on local policies. Still depending on local policies and legal rights the callee UA can decide to carry out additional tests on the INVITE, initiate communication to other entities (see Section 3.3), or block the call without having the phone ringing. 3.1.2. Upstream As for downstream communication above, we first describe considerations that are common for all three interfaces before them before pointing out differences between them. All Interfaces (a), (b), and (c) Upstream information is sent by entities after receiving an INVITE as feedback to the entity from which they received it. It may contain an estimation of the likelihood that the INVITE belonged to a SPIT call. This feedback may be sent before the call is established (if at all), after it was blocked, while the call is established, and after the call has been terminated. This information can help the sender in better judging following calls that are forwarded and the users sending the call initiation request. An example for this use of interfaces (a), (b) and (c) for the delivery of feedback information is given in [I-D.niccolini-sipping-feedback-spit]. In addition to the estimation of the likelihood that the INVITE belonged to a SPIT call, such interfaces, similar to downstream communication of statistics, would allow to feed back statistics about the recent behavior of the sender. An example of these statistics would consist in the rate of SPIT calls initiated by the sender during the last time slot, the ratio between regular calls and SPIT calls initiated by the sender during the last time slot, etc. The above mentioned statistics can also be bundled together and passed only after the expiration of a timeout in order to increase scalability. Niccolini & Quittek Expires July 15, 2007 [Page 10] Internet-Draft SPITSTOP Reference Scenario January 2007 Similar to downstream communication of estimates and statistics, the source of the feedback information may be contained. This is particularly interesting if the feedback was generated by the callee who received the call. Interface (a) This interface is instantiated between the first PS along the INVITE path and the caller UA. The relevance of interface (a) seems to be rather limited. It does not seem to be a good idea to give feedback to an initiator of SPIT on if and why requested calls have been blocked. This would allow the SPIT initiator to use this feedback for improving methods that bypass SPIT prevention systems in the network. A potential argument for sending a notification about detected SPIT to the SPIT generator would be that many legal operators of SPIT generating hosts might not be aware of this. Today, this is the case for email spam. Most of them are generated by bot nets where the legal operators of the contained hosts are not aware of their hosts being used for this purpose. However, in case of SPIT generation, it must be assumed that the generating software is either a software not in control of the legal operator or it is controlling the caller UA and capable of suppressing any feedback that should not be seen by the legal operator. Therefore, this means would probably not show the desired results. Interface (b) This interface is instantiated if there are two or more PS on the path. In this case interface (b) is used between each consecutive pair of them. It is used to feed back information about the likelihood that an INVITE belonged to a SPIT call and about most relevant statistics of the INVITE initiator recent behavior. If also the source of the estimation and statistics is transmitted, the PS can judge how much trust to associate to the indications based on local policies and act consequently. Still depending on local policies and legal rights the PS can decide to carry out additional tests on selected subsequent INVITEs, initiate communication to other entities (see Section 3.2 or Section 3.3), or block selected subsequent calls. Interface (c) Niccolini & Quittek Expires July 15, 2007 [Page 11] Internet-Draft SPITSTOP Reference Scenario January 2007 This interface is instantiated between the callee UA and the last PS along the INVITE path. It is used to feed back information about the likelihood that an INVITE belonged to a SPIT call and about most relevant statistics of the INVITE initiator recent behavior (even if in this case the statistics can be rather limited since are generated by the callee UA directly which has a narrow view on all the traffic). This feedback is supposed to be a very important one since it is the one directly generated by the callee UA (be it the software or the human itself). The PS will therefore associate high trust to such a feedback and act consequently. Still depending on local policies and legal rights the PS can decide to carry out additional tests on selected subsequent INVITEs, initiate communication to other entities (see Section 3.2 or Section 3.3), or block selected subsequent calls. 3.2. Off-Path Interfaces between Proxy Servers The basic idea of interface (d) is similar to the interface (b) where different PS exchange SPIT-related information. The difference to (b) is that for (d) this exchange is not bound to the path of an INVITE message. At interface (d) information will be shared among PS that collaborate on SPIT prevention. While the (b) interface can potentially be an inter-domain interface, (d) is rather seen as an intra-domain interface where collaborating proxies of a domain enforce a domain-wide SPIT prevention policy. For such a purpose, information needs to be exchanged rather on collected information than on single events of an observed INVITE message, although this case should not be excluded. Interface (d) has two major purposes. the first is the exchange of information regarding the likeliness of a caller UA or a certain administrative domain to produce SPIT. This does not necessarily require exchanging observations per INVITE message, but rather on a regular basis or incident-driven, for example whenever a PS detects a correlation between several calls that have been classified as SPIT. The exchange of such information may, for example, lead to a classification of a source address or a source network as source of SPIT which requires and update of blacklists and SPIT detection mechanisms. Consequently, the second major purpose of interface (d) is exchanging information that updates or synchronizes the prevention mechanisms that are acting at different PS. This includes particularly blacklist and whitelist entries, but also other SPIT prevention mechanisms may make use of exchanged information. Niccolini & Quittek Expires July 15, 2007 [Page 12] Internet-Draft SPITSTOP Reference Scenario January 2007 Still, interface (d) may also serve for exchanging estimated likelihoods of single call to be SPIT, for example for collecting this information at a central repository that serves for updating domain-wide SPIT prevention policies. 3.3. Interfaces to Special SPIT Prevention Entities Communication to special SPIT prevention entities can be performed either by a proxy server via interface (e) or by the callee UA via interface (f). We first discuss considerations that apply to both interfaces before pointing out differences between the two. Both Interfaces (e) and (f) The service offered by special SPIT prevention entities is related to the estimation of the likelihood of the INVITE to belong to a SPIT call. This communication is supposed to be instantiated in order to off-load computational intensive tasks to an external entity. The communication with this SPIT prevention entity follows the client-server scheme. The PS or UA acting as client requests an estimation of the likelihood of a given INVITE message to belong to a SPIT call. The estimation is performed by the SPIT prevention entity acting as server. A request may include call parameters to be used by the server when performing the estimations. Interface (e) This interface is instantiated between a proxy server and a special SPIT prevention entity in order to either request for SPIT likelihood estimations. In addition to the above considerations it is necessary to note that such service could be less personalized with respect to the service offered over the interface (f) since the estimations have to be general in order to deal with all the users served by the proxy server using such an interface. Otherwise the instantiated functions seems to be identical. Interface (f) This interface is instantiated between a UA and a special SPIT prevention entity in order to either request for SPIT likelihood estimations. In addition to the above considerations it is necessary to note that such service should be more personalized with respect to the service offered over the interface (e) since the estimations have to be specific to the callee requesting them Niccolini & Quittek Expires July 15, 2007 [Page 13] Internet-Draft SPITSTOP Reference Scenario January 2007 over the interface. Otherwise the instantiated functions seems to be identical. 4. Need for Standardization The considerations above indicate that there is an actual need for standardization of communication information. The strongest need seems to be for interfaces (b) and (c) in upstream direction for providing feedback on calls or call attempts. But also in downstream direction, there seems to be an obvious need to support this communication by providing a standard for it. This concerns both in intra- and inter-domain communication. The situation is very different for Interface (a). The considerations in Section 3.1 indicate that it might even be a bad idea to provide any feedback via (a) at all. Therefore, we do not see a need to work on standards for interface (a). Interface (d) seems to be useful but with a more limited scope of application within a (federated) administrative domain (intra- domain). Still for interoperability between different devices is appears to be beneficial to have a standard way of sharing SPIT- related information. For the remaining interfaces (e) and (f) we do not yet see a clear need for interoperability. SPIT prevention engines to which functions are outsourced by a PS or callee UA may typically be part of a solution that is offered together with the PS or with a set of SIP UAs. For these cases proprietary communication protocols appear to be sufficient. Still need for standardization may arise at later stages when SPIT prevention entities become more common. 4.1. Preliminary Protocol Considerations The fact that the communication over interfaces (b) and (c) follows the same path as the SIP signaling itself may influence the choice of the signaling protocols used for exchanging information at the interfaces. An obvious choice to be discussed would be embedding the SPIT information directly in the SIP messages flowing among the entities anyway. For the other interfaces (d), (e) and (f) other signaling protocols may be preferable since the communication will happen anyway not synchronously with the SIP messages used to initiate the session. An example could be the exchange of XML files among different entities. Niccolini & Quittek Expires July 15, 2007 [Page 14] Internet-Draft SPITSTOP Reference Scenario January 2007 5. Conclusions This memo addresses the necessity of providing standards for communication between entities involved in SPIT prevention. For this purpose a reference scenario is defined with involved entities and interfaces between them. For each interface the need for it and the need for standards for is discussed. This memo is intended to stimulate a discussion on SPIT prevention and to reach consensus on the identification of standardization goals in this area. Some of the considerations in Section 3 seem to indicate that there is an actual need to standardize communication for some of the discussed interfaces. This memo does not try to standardize any solution to the problems identified. The necessary work outcoming from the discussion stimulated will have to be carried out in separate documents. 6. Security Considerations This memo discusses the exchange of information related to SPIT prevention. This includes information on particular calls or call attempts as well as information on call initiators potentially being a source of SPIT. Exchanging per-call information may violate the privacy of a caller. Therefore, instantiations of the discussed exchange of information need to be carefully checked for compliance with legal regulations of information privacy. Also, since this information may be sensitive, appropriate steps should be undertaken to provide confidentiality when it is transmitted over the Internet. Both, per-call information and information of a caller being a source of SPIT may be a target of denial-of-service attacks. If such messages are faked, a regular caller may be blocked network-wide and not able anymore to perform calls. Therefore, integrity and authenticity need to be provided when this kind of information is transmitted over the Internet. 7. Informative References [I-D.ietf-sipping-spam] Jennings, C. and J. Rosenberg, "The Session Initiation Protocol (SIP) and Spam", draft-ietf-sipping-spam-03 (work in progress), October 2006. [I-D.froment-sipping-spit-authz-policies] Froment, T., "Authorization Policies for Preventing SPIT", Niccolini & Quittek Expires July 15, 2007 [Page 15] Internet-Draft SPITSTOP Reference Scenario January 2007 draft-froment-sipping-spit-authz-policies-01 (work in progress), June 2006. [I-D.jung-sipping-authentication-spit] Jung, S., "Authentication between the Inbound Proxy and the UAS for Protecting SPIT in the Session Initiation Protocol (SIP)", draft-jung-sipping-authentication-spit-00 (work in progress), October 2006. [I-D.niccolini-sipping-feedback-spit] Niccolini, S., "SIP Extensions for SPIT identification", draft-niccolini-sipping-feedback-spit-02 (work in progress), August 2006. Niccolini & Quittek Expires July 15, 2007 [Page 16] Internet-Draft SPITSTOP Reference Scenario January 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 Juergen Quittek Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 115 Email: quittek@netlab.nec.de URI: http://www.netlab.nec.de Niccolini & Quittek Expires July 15, 2007 [Page 17] Internet-Draft SPITSTOP Reference Scenario January 2007 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Niccolini & Quittek Expires July 15, 2007 [Page 18]