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]