< draft-tschofenig-sipping-framework-spit-reduction-02.txt   draft-tschofenig-sipping-framework-spit-reduction-03.txt >
SIPPING H. Tschofenig SIPPING H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: May 22, 2008 Columbia University Expires: August 28, 2008 Columbia University
D. Wing D. Wing
Cisco
J. Rosenberg J. Rosenberg
Cisco Systems Cisco Systems
D. Schwartz D. Schwartz
Kayote Networks XConnect
November 19, 2007 February 25, 2008
A Framework to tackle Spam and Unwanted Communication for Internet A Framework to tackle Spam and Unwanted Communication for Internet
Telephony Telephony
draft-tschofenig-sipping-framework-spit-reduction-02.txt draft-tschofenig-sipping-framework-spit-reduction-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Spam, defined as sending unsolicited messages to someone in bulk, Spam, defined as sending unsolicited messages to someone in bulk, is
might be a problem on SIP open-wide deployed networks. A number of likely to become a problem on SIP open-wide deployed networks. A
solutions have been proposed for dealing with Spam for Internet number of solutions have been proposed for dealing with Spam for
Telephony (SPIT), for example, content filtering, black lists, white Internet Telephony (SPIT) and unwanted communication, for example,
lists, consent-based communication, reputation systems, address content filtering, black lists, white lists, consent-based
obfuscation, limited use addresses, turing tests, computational communication, reputation systems, address obfuscation, limited use
puzzles, payments at risk, circles of trust, and many others. This addresses, turing tests, computational puzzles, payments at risk,
document describes the big picture that illustrates how the different circles of trust, and many others.
building blocks fit together and can be deployed incrementally.
This document describes the big picture that illustrates how the
different building blocks fit together and can be deployed
incrementally.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Communication Patterns and User Groups . . . . . . . . . . . . 7 4. Communication Patterns and User Groups . . . . . . . . . . . . 7
4.1. Closed Groups . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Closed Groups . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Semi-Open Groups . . . . . . . . . . . . . . . . . . . . . 7 4.2. Semi-Open Groups . . . . . . . . . . . . . . . . . . . . . 7
4.3. Open Groups . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Open Groups . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10 5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9
5.1. End Host based Rule Enforcement . . . . . . . . . . . . . 10 5.1. Rule Enforcement via a Trusted Intermediary . . . . . . . 10
5.2. Rule Enforcement via a Trusted Intermediary . . . . . . . 10 5.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 10
5.3. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 5.3. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 19 Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Authorization Engine in SIP UA . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
The problem of Spam for Internet Telephony (SPIT) is an imminent The problem of Spam for Internet Telephony (SPIT) is an imminent
challenge and only the combination of several techniques can provide challenge and only the combination of several techniques can provide
a framework for dealing with unwanted communication attempts. a framework for dealing with unwanted communication attempts.
[I-D.ietf-sipping-spam] provides four core recommendations that need [I-D.ietf-sipping-spam] provides four core recommendations that need
to be considered for a SPIT solution, namely to be considered for a SPIT solution, namely
o Strong Identity o Strong Identity
o White Lists o White Lists
o Solve the Introduction Problem o Solve the Introduction Problem
o Don't Wait Until its Too Late o Don't Wait Until its Too Late
This document illustrates how existing building blocks can be put This document illustrates how existing building blocks can be put
together to form a solution to deal with SPIT. New building blocks together to form a solution to deal with SPIT. New building blocks
can be added to provide more efficient SPIT handling, since there is can be added to provide more efficient SPIT handling, since there is
no single solution that provides 100 % protection. no single solution that provides 100 % protection.
The main purpose of this document is largely to define a model of The purpose of this document defines a model of internal device
internal device processing, protocol interfaces, and terminology to processing, protocol interfaces, and terminology to illustrate a way
illustrate a way in which SPIT prevention techniques can be added in in which SPIT prevention techniques can be added in a seamless
a seamless fashion. We focus only on the most important solution fashion. We focus only on the most important solution components and
components and consider many other aspects either outside the scope consider many other aspects either outside the scope of this work
of this work (see Appendix A) and postpone them for future work. (see Appendix A) and postpone them for future work.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Framework 3. Framework
The framework considered in this document assumes that an end user Figure 1 shows the interaction between the end host and a SIP proxy
uploads authorization policies to a SIP proxy of its VoIP provider. belonging to its VoIP provider. One important part of the overall
That VoIP provider enforces those authorization policies. This solution is the ability to make authorization decisions based on
separation allows the end user to delegate some authorization incoming communication attempts. The entity that writes these
decisions to the VoIP provider. authorization rules is referred as Rule Maker. The Rule Maker might
be a user via some form of user interface. Some rules may be
generated automatically by a piece of software by observing the users
behavior. Furthermore, in certain deployment environments an initial
rule set will be provided by some third party entity, such as the
enterprise system administrator or the VoIP provider.
Figure 1 below shows the interaction between the end host and a SIP Policies are processed by corresponding module within the SIP proxy,
proxy belonging to its VoIP provider. The end user, in the role of a called Authorization Engine, that interacts with the message routing
recipient for communication attempts, may upload authorization component. By following this architectural approach the Policy
policies. The entity that writes the rules is referred as Rule Decision Point (PDP) and the Policy Enforcement Point (PEP) are
Maker. The Rule Maker does not necessarily need to be recipient of closely combined. As such, authorization policies are stored at at a
the communication but it could instead be entity that acts on behalf SIP proxy rather than the SIP UA client itself. The implications of
of him or her. Note that a combination is possible as well where relocating these two functions, PDP and PEP, to the SIP UA client are
different entities contribute to the set of rules. These policies described in Appendix B.
are processed by corresponding module within the SIP proxy, called
Authorization Engine, that interacts with the message routing
functionality. A part of the rule set might, however, also be
created automatically as part of interactive interactions (e.g.,
monitoring ongoing communication attempts).
+---------------------------------------------------------+ +---------------------------------------------------------+
| Authorization | | Authorization |
| re-route Policy +------------+ | | re-route Policy +------------+ |
| ^ (implicit) ######| Rule Maker | | | ^ (implicit) ######| Rule Maker | |
| o +#######+ # +------------+ | | o +#######+ # +------------+ |
| o # # # | | o # # # |
| +---o----------#-------#--+ # Authorization | | +---o----------#-------#--+ # Authorization |
| | o # # |<####### Policy | | | o # # |<####### Policy |
+--------+ | | o Proxy # # | | +--------+ | | o Proxy # # | |
skipping to change at page 4, line 45 skipping to change at page 4, line 45
+-------------------Domain Boundary-----------------------+ +-------------------Domain Boundary-----------------------+
Legend: Legend:
oooo: SIP message interaction oooo: SIP message interaction
****: Protocol Interaction for authorizing the message sender ****: Protocol Interaction for authorizing the message sender
####: Management of authorization policies ####: Management of authorization policies
Figure 1: Overview Figure 1: Overview
Assume that an arbitrary sender transmits a message towards the Assume that an arbitrary entity transmits a message to a specific URI
recipients URI that finally hits the SIP proxy on the recipients that finally hits the SIP proxy on the recipients side. Information
side. Information provided within that message are used as input to provided within that message are used as input to the rule
the rule evaluation. Any part of the message may serve as input to evaluation. Any part of the message may serve as input to the
the evaluation process but for practical reasons only a few selected evaluation process but for practical reasons only a few selected
fields do most of the work. In this document, we argue that the fields do most of the work. The authenticated identity of the sender
authenticated identity of the sender is the most valuable information is probably the most valuable information item. One could, however,
item. In the future, when standardization progresses then, for imagine that other information, such as reputation information
example, reputation information obtained from social networks may obtained from social networks, could offer additional input to the
offer additional input to the authorization process. authorization engine.
The protocol interaction for authorizing the message sender refers to The protocol interaction for authorizing the message sender refers to
the ability of the recipient or the proxy to interact with the sender the ability of the recipient or the proxy to interact with the sender
to request authorization. The request for authorization is a pull to request authorization. The request for authorization might
model whereby the proxy or the recipient challenges the sender (e.g., require the message sender to be challenged (e.g., via hash cash
via hash cash [I-D.jennings-sip-hashcash], or SIP payment [I-D.jennings-sip-hashcash], via SIP payment
[I-D.jennings-sipping-pay], or Completely Automated Public Turing [I-D.jennings-sipping-pay], or via CAPTCHAs
Test to Tell Computers and Humans Apart (CAPTCHA) based robot [I-D.tschofenig-sipping-captcha]). Some other mechanisms, such as
challenges [I-D.tschofenig-sipping-captcha]) for authorization. SIP SIP Identity do not require the verifying entity to challenge the
Identity on the other hand realizes as push model whereby authentication service since the identity assertion is pushed towards
authentication information is pushed towards the recipient. the recipient.
Figure 2 shows this integration step. The conditions part of the Figure 2 shows this integration step. The conditions part of the
rule offer a mechanisms to incrementally extend the overall framework rule offer a mechanisms to incrementally extend the overall framework
with new SPIT prevention solution components. Depending on the rule with new components. Depending on the outcome of the rule
evaluation the message may be rerouted to another entity, such as an evaluation, the message may be re-routed to another entity, such as
answering machine, to the recipient, rejected or other actions are an answering machine, to the recipient, rejected or other actions are
triggered. The latter aspect is particularly interesting since it triggered. The latter aspect is particularly interesting since it
allows further solution components to be executed. allows further solution components to be executed.
SIP msg with SIP msg with
authenticated authenticated
identity +---------------+ identity +---------------+
-------------->| |----------------> -------------->| |---------------->
Additional | | Spam marked msg Additional | | Spam marked msg
Msg fields | Authorization | Msg fields | Authorization |
-------------->| Engine |----------------> -------------->| Engine |---------------->
skipping to change at page 5, line 47 skipping to change at page 5, line 47
Components | |----------------> Components | |---------------->
-------------->+---------------+ Forwarded to -------------->+---------------+ Forwarded to
| | original recipient | | original recipient
| | | |
<-----------+ +----------->|| <-----------+ +----------->||
Politely blocked Blocked Politely blocked Blocked
Figure 2: Message Filtering and Routing Figure 2: Message Filtering and Routing
Note that some traffic analysis and consequently some form of content Note that some traffic analysis and consequently some form of content
filtering (e.g., of MESSAGEs) can be applied locally within the VoIP filtering (e.g., of MESSAGEs) message be applied locally within the
provider's domain also under the control of the end user. For VoIP provider's domain also under the control of the end user.
example, consider a Voice over IP provider that wants to utilize a However, this is largely an implementation-specific technique without
statistical analysis tool for Spam prevention. It is not necessary protocol impact. For example, consider a VoIP provider that wants to
to standardized the algorithms; the impact for the authorization utilize a statistical analysis tool for Spam prevention. It is not
policies is mainly the ability to allow the Rule Maker to enable or necessary to standardized the algorithms nor protocols; the impact
to disable the usage of these statistical techniques for SPIT for the authorization policies is mainly the ability to allow the
filtering and potentially to map the output of the analysis process Rule Maker to enable or to disable the usage of these statistical
techniques and potentially to map the output of the analysis process
to value range from 0 (i.e., the message is not classified as Spam) to value range from 0 (i.e., the message is not classified as Spam)
and 100 (i.e., the message was classified as Spam). Conveying Spam and 100 (i.e., the message was classified as Spam). A Rule Maker may
marking is proposed in [I-D.schwartz-sipping-spit-saml], in decide to act with an appropriate action on a certain level of Spam
[I-D.niccolini-sipping-feedback-spit] and in marking.
[I-D.wing-sipping-spam-score]. A Rule Maker may decide to act with
an appropriate action on a certain level of Spam marking.
In a minimalistic SPIT framework only authenticated identities in
combination with authorization policies are used. This should serve
as a starting point for future work.
Authenticated Identities: Authenticated Identities:
SIP Identity [RFC4474] is assumed to be used to provide the Initial VoIP provider are likely to secure their SIP signaling
receiver of a communication attempt with the authenticated using Transport Layer Security (TLS) or IP security (IPsec)
identity. SIP Identity is a reasonable simple specification and between neighboring providers and use P-Asserted-ID [RFC3325].
does not rely on a huge amount of infrastructure support.
Note: SIP Identity is comparable to DomainKeys Identified Mail Note: SIP Identity is comparable to DomainKeys Identified Mail
(DKIM) [I-D.ietf-dkim-overview] used for associating a (DKIM) [I-D.ietf-dkim-overview] used for associating a
"responsible" identity with an email message and provides a "responsible" identity with an email message and provides a
means of verifying that the association is legitimate. means of verifying that the association is legitimate.
SIP Identity [RFC4474] is a proposal for stronger security
mechanisms used to provide the verification service with the
authenticated identity. SIP Identity is a reasonably simple
specification and does not rely on a huge amount of infrastructure
support.
This framework does not assume a specific mechanism for asserting
identities to be used but a strong identity mechanism is a pre-
requisity for authorization policy handling to be successful.
Authorization Policies: Authorization Policies:
When the white lists are stored and managed only at the end host Even if policy decision making and policy enforcement is done
then the authorization policies and the protocol to modify the outside the SIP UA client then still there might not be a need to
policies do not need to be standardized since they are purely standardize an authorization policy language if the policies can
implementation specific details. Even if the authorization be modified via a webpage. This approach of policy handling is
policies are managed centrally or some amount of policy done in many cases today already for various applications.
enforcement is done by trusted intermediaries then still there
might not be a need to standardize an authorization policy
language if the policies can be modified via a webpage. This type
of policy handling is done in many cases today already for various
applications.
Unfortunately, this approach tends to become cumbersome to manage Unfortunately, this approach tends to become cumbersome for end
for end users and therefore it is better to hide a lot of policy users and therefore it is better to hide a lot of policy details
details from the end user itself and to make use of context from the end user itself and to make use of context information,
information, for example, address books and authorization policies for example, address books and authorization policies available
available already created for presence based systems. already created for presence based systems.
In some cases the above-described approach is not sufficient Additionally, a user may have multiple devices and a consistent
whereby it is necessary to define a standardized protocol, for view of the policies should be provided.
example, if policies are used by different entities, created and
modified in an automatic way and when multiple entities manipulate
policies (potentially on behalf of the person affected by the
policies), e.g., the user may have multiple devices.
An example solution for authorization policies providing Spam An example solution for authorization policies for dealing with
prevention capabilities are described in reducing unwanted communication is described in
[I-D.tschofenig-sipping-spit-policy] with the requirements [I-D.tschofenig-sipping-spit-policy] with the requirements
detailed in [I-D.froment-sipping-spit-requirements]. detailed in [I-D.froment-sipping-spit-requirements].
The white list needs to be created somehow and hence there is an There is still one significant problem unsolved: since white lists
introduction problem. Section 4 discusses this aspect in more need to be created somehow and hence there is an introduction
details. problem. Section 4 discusses this aspect in more details.
4. Communication Patterns and User Groups 4. Communication Patterns and User Groups
When communication takes place then at least three types of groups When communication takes place then at least three types of groups
can be identified. can be identified.
4.1. Closed Groups 4.1. Closed Groups
People in this group communicate only with the peers in their group. People in this group communicate only with the peers in their group.
They do not appreciate communication attempts from outside. They do not appreciate communication attempts from outside.
skipping to change at page 9, line 12 skipping to change at page 9, line 4
additional information about the calling party. Social networks additional information about the calling party. Social networks
might provide similar techniques based on reputation based systems. might provide similar techniques based on reputation based systems.
4.4. Summary 4.4. Summary
Based on the discussions regarding communication patters and groups Based on the discussions regarding communication patters and groups
the following observations can be made: the following observations can be made:
o A single person very likely has many roles and they may have an o A single person very likely has many roles and they may have an
impact on the communication patterns. impact on the communication patterns.
For example, consider a person who is working in a company but For example, consider a person who is working in a company but
also want to be available for family members. also want to be available for family members.
o The context in which a person is may change at any time. For o The context in which a person is may change at any time. For
example, a person might be available for family members while at example, a person might be available for family members while at
work except during an important meeting where communication work except during an important meeting where communication
attempts may be rejected. Switching a context has an impact for attempts may be rejected. Switching a context has an impact for
reachability and the means for communicating with a specific reachability and the means for communicating with a specific
recipient, based on enabled rule sets. recipient, based on enabled rule sets.
From an authorization policy point of view it is important to be able From an authorization policy point of view it is important to be able
to express a sphere, i.e., the state a user is in and to switch to express a sphere (i.e., the state a user is in) and to switch
between different spheres easily by thereby switching to a different between different spheres easily by thereby switching to a different
rule set. rule set.
4.5. Usability 4.5. Usability
An important aspect in the usage of authorization policies is to An important aspect in the usage of authorization policies is to
assist the user when creating policies. Ideally, the policies should assist the user when creating policies. Ideally, the policies should
be established automatically. Below, there are a couple of examples be established automatically. Below, there are a couple of examples
to illustrate the idea given that these aspects are largely to illustrate the idea given that these aspects are largely
implementation issues: implementation issues:
skipping to change at page 10, line 8 skipping to change at page 9, line 47
These are often tagged as spam by content filters. This type of These are often tagged as spam by content filters. This type of
correspondence is usually initiated by a transaction over the web, correspondence is usually initiated by a transaction over the web,
such as a purchase or signing up for a service. such as a purchase or signing up for a service.
[I-D.shacham-http-corr-uris], for example, defines an HTTP header [I-D.shacham-http-corr-uris], for example, defines an HTTP header
for conveying future correspondence addresses that can be for conveying future correspondence addresses that can be
integrated in the rule set. integrated in the rule set.
5. Protocol Interactions 5. Protocol Interactions
This section describes the necessary building blocks that are This section describes the necessary building blocks that are
necessary to tie the framework together. We will describe two necessary to tie the framework together.
different environments, namely one where rule enforcement happens at
the end host and another one where a trusted network intermediary
performs the actions.
5.1. End Host based Rule Enforcement
o SIP Identity [RFC4474] is mandatory to implement at the end host
and used to determine the authenticated identity of the sending
side.
o Authorization policies are purely implementation specific matter.
Since a purely end host based rule enforcement suffers from a number
of drawbacks, rule enforcement by a trusted intermediary is also
offered.
5.2. Rule Enforcement via a Trusted Intermediary 5.1. Rule Enforcement via a Trusted Intermediary
o SIP Identity [RFC4474] or a corresponding mechanism is mandatory o Some from of strong identity assurance is required to build the
to implement at the trusted intermediary (e.g., the immediate VoIP basis for identity-based authorization. SIP Identity [RFC4474] or
provider) and it determines the authenticated identity of the P-Asserted-ID [RFC3325] are examples of available mechanisms.
sending side. These mechanisms allow the authenticated identity of the sending
party to be determined.
o Authorization Policies based on the Common Policy framework o Authorization Policies based on the Common Policy framework
[RFC4745], as extended in [I-D.tschofenig-sipping-spit-policy] for [RFC4745], as extended in [I-D.tschofenig-sipping-spit-policy] for
the purpose of SPIT prevention, are mandatory to implement at the the purpose of SPIT prevention, are mandatory to implement at the
end host side and at the trusted intermediary. The implementation end host side and at the trusted intermediary. The implementation
of the rule evaluation engine might only be necessary on the of the rule evaluation engine might only be necessary on the
trusted VoIP proxy. Harmonization with the work done for presence trusted VoIP proxy. Harmonization with the work done for presence
authorization [I-D.ietf-simple-presence-rules], which is based on authorization [I-D.ietf-simple-presence-rules], which is based on
Common Policy [RFC4745], can be accomplished and is highly Common Policy [RFC4745], can be accomplished and is highly
desirable. desirable.
o XML Configuration Access Protocol (XCAP) [RFC4825] is used to o XML Configuration Access Protocol (XCAP) [RFC4825] is used to
create, modify and delete authorization policies and is mandatory create, modify and delete authorization policies and is mandatory
to implement at the end host side and at the trusted intermediary. to implement at the end host side and at the trusted intermediary.
5.3. Incremental Deployment 5.2. Incremental Deployment
An important property is incremental deployment of additional An important property is incremental deployment of additional
solution components that can be added and used when they become solution components that can be added and used when they become
available. This section aims to illustrate how the extensibility is available. This section aims to illustrate how the extensibility is
accomplished, based on an example. accomplished, based on an example.
Consider a VoIP provider that provides authorization policies that Consider a VoIP provider that provides authorization policies that
provide the following functionality equivalent to the Common Policy provide the following functionality equivalent to the Common Policy
framework, i.e., identity-based, sphere and validity based conditions framework, i.e., identity-based, sphere and validity based conditions
initially. For actions only 'redirection' and 'blocking' is initially. For actions only 'redirection' and 'blocking' is
skipping to change at page 12, line 38 skipping to change at page 12, line 30
<namespace>urn:ietf:params:xml:ns:hashcash</namespace> <namespace>urn:ietf:params:xml:ns:hashcash</namespace>
<namespace>urn:ietf:params:xml:ns:statistical-analysis</namespace> <namespace>urn:ietf:params:xml:ns:statistical-analysis</namespace>
</namespaces> </namespaces>
</xcap-caps> </xcap-caps>
Second XCAP Response with the supported Capabilities Second XCAP Response with the supported Capabilities
New SPIT handling functionality may extend condition, actions and/or New SPIT handling functionality may extend condition, actions and/or
transformation elements of a rule. transformation elements of a rule.
5.3. Botnets
A botnet is a large number of compromised maschines that are used to
create and send spam or viruses or flood a network with messages as a
denial of service attack.
Such a botnet represents a significant challenge for a VoIP
infrastructure and also for the mechanisms proposed in this document.
Recently observed attacks indicated that some botnets tried to steal
credentials to distribute messages with "real" identities. To deal
with the threat it is useful to classify the behavior of these bots
into three categories, namely
o The botnet does not have access to the user's credentials. In
this case identity-based white lists provides adequate protection.
o The botnets does have access to user's credentials of compromised
maschines but distributes messages in a random fashion. In this
case identity-based white lists provides adequate protection since
it is unlikely that the recipient will have that person in their
whitelist.
o In this category the botnet has access to the user's credentials
and utilizes addresses from the user's addressbook. In this case
whitelists do not provide a proper protection. Since the
recipient knows the sender of the message it would, in many cases,
be able to get in contact with him or her and report the observed
problem. This approach does not work with a pure maschine-to-
maschine communication environment without user involvement.
6. Privacy Considerations 6. Privacy Considerations
This document does not propose to distribute the user's authorization This document does not propose to distribute the user's authorization
policies to other VoIP providers nor is the configuration of policies policies to other VoIP providers nor is the configuration of policies
at SIP proxies other than the trusted user's VoIP provider necessary. at SIP proxies other than the trusted user's VoIP provider necessary.
Furthemore, if blocking or influencing of the message processing is Furthemore, if blocking or influencing of the message processing is
executed by the VoIP provider then they have to be explicitly enabled executed by the VoIP provider then they have to be explicitly enabled
by the end user. Blocking of messages, even if it is based on by the end user. Blocking of messages, even if it is based on
"super-clever" machine learning techniques often introduces "super-clever" machine learning techniques often introduces
unpredictability. unpredictability.
skipping to change at page 16, line 30 skipping to change at page 16, line 41
9. Acknowledgments 9. Acknowledgments
We would like to thank We would like to thank
Jeremy Barkan, Dan York, Alexey Melnikov, Thomas Schreck, Eva Jeremy Barkan, Dan York, Alexey Melnikov, Thomas Schreck, Eva
Leppanen, Cullen Jennings, Marit Hansen and Markus Hansen for Leppanen, Cullen Jennings, Marit Hansen and Markus Hansen for
their review comments to a pre-00 version. their review comments to a pre-00 version.
Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski, Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski,
Saverio Niccolini, Albert Caruana, and Juergen Quittek for their Saverio Niccolini, Albert Caruana, and Juergen Quittek for their
comments to the 00 version. comments to the 00 version.
Otmar Lendl, Jan Seedorf, Saverio Niccolini, Kai Fischer, Joachim
Charzinski, Dan York, Peter Saint-Andre, Brian Azzopardi, Martin
Stiemerling, and Juergen Quittek for their comments to the -01/-02
version.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745, Format for Expressing Privacy Preferences", RFC 4745,
February 2007. February 2007.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
10.2. Informative References 10.2. Informative References
[I-D.ietf-sipping-spam] [I-D.ietf-sipping-spam]
Rosenberg, J. and C. Jennings, "The Session Initiation Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work
in progress), July 2007. in progress), July 2007.
skipping to change at page 17, line 23 skipping to change at page 17, line 44
Rosenberg, J., "Presence Authorization Rules", Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-10 (work in progress), draft-ietf-simple-presence-rules-10 (work in progress),
July 2007. July 2007.
[I-D.jennings-sip-hashcash] [I-D.jennings-sip-hashcash]
Jennings, C., "Computational Puzzles for SPAM Reduction in Jennings, C., "Computational Puzzles for SPAM Reduction in
SIP", draft-jennings-sip-hashcash-06 (work in progress), SIP", draft-jennings-sip-hashcash-06 (work in progress),
July 2007. July 2007.
[I-D.wing-sipping-spam-score] [I-D.wing-sipping-spam-score]
Wing, D., "Spam Score for SIP", Wing, D., Niccolini, S., Stiemerling, M., and H.
draft-wing-sipping-spam-score-00 (work in progress), Tschofenig, "Spam Score for SIP",
August 2007. draft-wing-sipping-spam-score-02 (work in progress),
February 2008.
[I-D.ietf-sip-consent-framework] [I-D.ietf-sip-consent-framework]
Rosenberg, J., Camarillo, G., and D. Willis, "A Framework Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
for Consent-based Communications in the Session Initiation for Consent-based Communications in the Session Initiation
Protocol (SIP)", draft-ietf-sip-consent-framework-03 (work Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work
in progress), November 2007. in progress), January 2008.
[I-D.ietf-dkim-overview] [I-D.ietf-dkim-overview]
Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", Identified Mail (DKIM) Service Overview",
draft-ietf-dkim-overview-07 (work in progress), draft-ietf-dkim-overview-09 (work in progress),
November 2007. February 2008.
[I-D.tschofenig-sipping-spit-policy] [I-D.tschofenig-sipping-spit-policy]
Tschofenig, H., "A Document Format for Expressing Tschofenig, H., Wing, D., Schulzrinne, H., Froment, T.,
and G. Dawirs, "A Document Format for Expressing
Authorization Policies to tackle Spam and Unwanted Authorization Policies to tackle Spam and Unwanted
Communication for Internet Telephony", Communication for Internet Telephony",
draft-tschofenig-sipping-spit-policy-01 (work in draft-tschofenig-sipping-spit-policy-02 (work in
progress), July 2007. progress), November 2007.
[I-D.schwartz-sipping-spit-saml] [I-D.schwartz-sipping-spit-saml]
Schwartz, D., "SPAM for Internet Telephony (SPIT) Schwartz, D., "SPAM for Internet Telephony (SPIT)
Prevention using the Security Assertion Markup Language Prevention using the Security Assertion Markup Language
(SAML)", draft-schwartz-sipping-spit-saml-01 (work in (SAML)", draft-schwartz-sipping-spit-saml-01 (work in
progress), June 2006. progress), June 2006.
[I-D.shacham-http-corr-uris] [I-D.shacham-http-corr-uris]
Shacham, R. and H. Schulzrinne, "HTTP Header for Future Shacham, R. and H. Schulzrinne, "HTTP Header for Future
Correspondence Addresses", draft-shacham-http-corr-uris-00 Correspondence Addresses", draft-shacham-http-corr-uris-00
(work in progress), May 2007. (work in progress), May 2007.
[I-D.jennings-sipping-pay] [I-D.jennings-sipping-pay]
Jennings, C., "Payment for Services in Session Initiation Jennings, C., "Payment for Services in Session Initiation
Protocol (SIP)", draft-jennings-sipping-pay-06 (work in Protocol (SIP)", draft-jennings-sipping-pay-06 (work in
progress), July 2007. progress), July 2007.
[I-D.froment-sipping-spit-requirements] [I-D.froment-sipping-spit-requirements]
Froment, T., "Requirements for Authorization Policies to Tschofenig, H., Dawirs, G., Froment, T., Wing, D., and H.
Schulzrinne, "Requirements for Authorization Policies to
tackle Spam and Unwanted Communication for Internet tackle Spam and Unwanted Communication for Internet
Telephony", draft-froment-sipping-spit-requirements-01 Telephony", draft-froment-sipping-spit-requirements-02
(work in progress), July 2007. (work in progress), February 2008.
[I-D.niccolini-sipping-feedback-spit] [I-D.niccolini-sipping-feedback-spit]
Niccolini, S., "SIP Extensions for SPIT identification", Niccolini, S., "SIP Extensions for SPIT identification",
draft-niccolini-sipping-feedback-spit-03 (work in draft-niccolini-sipping-feedback-spit-03 (work in
progress), February 2007. progress), February 2007.
[I-D.tschofenig-sipping-captcha] [I-D.tschofenig-sipping-captcha]
Tschofenig, H. and E. Leppanen, "Completely Automated Tschofenig, H., Leppanen, E., Niccolini, S., and M.
Public Turing Test to Tell Computers and Humans Apart Arumaithurai, "Completely Automated Public Turing Test to
(CAPTCHA) based Robot Challenges for the Session Tell Computers and Humans Apart (CAPTCHA) based Robot
Initiation Protocol (SIP)", Challenges for SIP", draft-tschofenig-sipping-captcha-01
draft-tschofenig-sipping-captcha-00 (work in progress), (work in progress), February 2008.
July 2007.
[Spit-AL] Hansen, M., Hansen, M., Moeller, J., Rohwer, T., Tolkmitt, [Spit-AL] Hansen, M., Hansen, M., Moeller, J., Rohwer, T., Tolkmitt,
C., and H. Waack, "Developing a Legally Compliant C., and H. Waack, "Developing a Legally Compliant
Reachability Management System as a Countermeasure against Reachability Management System as a Countermeasure against
SPIT, Third Annual VoIP Security Workshop, Berlin, SPIT, Third Annual VoIP Security Workshop, Berlin,
available at available at
https://tepin.aiki.de/blog/uploads/spit-al.pdf", https://tepin.aiki.de/blog/uploads/spit-al.pdf",
June 2006. June 2006.
[Law1] "Bundesnetzagentur: Eckpunkte der regulatorischen [Law1] "Bundesnetzagentur: Eckpunkte der regulatorischen
skipping to change at page 19, line 18 skipping to change at page 19, line 42
Appendix A. Outside the Scope Appendix A. Outside the Scope
We consider the following aspects outside the scope of this document: We consider the following aspects outside the scope of this document:
o Mechanisms to publish SPIT causing parties on the Internet, i.e., o Mechanisms to publish SPIT causing parties on the Internet, i.e.,
information about domains that create SPIT. information about domains that create SPIT.
o Determining the source of unwanted traffic in real-time. o Determining the source of unwanted traffic in real-time.
o Pushing packet filters and authorization policies towards the SPIT o Pushing packet filters and authorization policies towards the SPIT
sending domain. sending domain.
Appendix B. Authorization Engine in SIP UA
When white lists are stored and managed only at the SIP UA client
then the authorization policies language and the protocol to modify
the policies do not need to be standardized; they are purely
implementation specific details.
While this appears to be an advantage there are various drawbacks
including the inability to synchronize policies among different
devices. Additionally, some information that is typically available
to the Policy Decision Point may not be available to the end host.
To avoid standardizing the exchange of such type of information an
abstract form of Spam marking is proposed in
[I-D.wing-sipping-spam-score].
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
skipping to change at page 19, line 41 skipping to change at page 20, line 34
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Dan Wing Dan Wing
Cisco Systems Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Phone:
Email: dwing@cisco.com Email: dwing@cisco.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, New York 07054 Parsippany, New York 07054
USA USA
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
David Schwartz David Schwartz
Kayote Networks XConnect
Malcha Technology Park Malcha Technology Park
Jerusalem 96951 Jerusalem, 96951
Israel Israel
Email: david.schwartz@kayote.com Email: dschwartz@xconnect.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 52 change blocks. 
166 lines changed or deleted 209 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/