One document matched: draft-niccolini-sipping-feedback-spit-03.txt
Differences from draft-niccolini-sipping-feedback-spit-02.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 10:18:43 |