< draft-tschofenig-sipping-framework-spit-reduction-00.txt   draft-tschofenig-sipping-framework-spit-reduction-01.txt >
Network Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Standards Track H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: December 16, 2007 Columbia University Expires: January 9, 2008 Columbia University
D. Wing D. Wing
J. Rosenberg J. Rosenberg
Cisco Systems Cisco Systems
D. Schwartz D. Schwartz
Kayote Networks Kayote Networks
June 14, 2007 July 8, 2007
A Framework for Reducing Spam for Internet Telephony A Framework to tackle Spam and Unwanted Communication for Internet
draft-tschofenig-sipping-framework-spit-reduction-00.txt Telephony
draft-tschofenig-sipping-framework-spit-reduction-01.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 40 skipping to change at page 1, line 41
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 December 16, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Spam, defined as sending unsolicited messages to someone in bulk, Spam, defined as sending unsolicited messages to someone in bulk,
might be a problem on SIP open-wide deployed networks. A number of might be a problem on SIP open-wide deployed networks. A number of
solutions have been proposed for dealing with Spam for Internet solutions have been proposed for dealing with Spam for Internet
Telephony (SPIT), for example, content filtering, black lists, white Telephony (SPIT), for example, content filtering, black lists, white
lists, consent-based communication, reputation systems, address lists, consent-based communication, reputation systems, address
obfuscation, limited use addresses, turing tests, computational obfuscation, limited use addresses, turing tests, computational
puzzles, payments at risk, circles of trust, and many others. This puzzles, payments at risk, circles of trust, and many others. This
document describes the big picture that illustrates how the different document describes the big picture that illustrates how the different
building blocks fit together and can be deployabled incrementally. 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 . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9
5.1. End Host based Rule Enforcement . . . . . . . . . . . . . 9 5.1. End Host based Rule Enforcement . . . . . . . . . . . . . 9
5.2. Rule Enforcement via a Trusted Intermediary . . . . . . . 9 5.2. Rule Enforcement via a Trusted Intermediary . . . . . . . 10
5.3. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 5.3. Incremental Deployment . . . . . . . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 17 Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20
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
skipping to change at page 4, line 35 skipping to change at page 4, line 35
* o | o * o | | | * o | o * o | | |
* +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient | | * +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient | |
+**************************************************>| | | +**************************************************>| | |
| +-------------+ | | +-------------+ |
| | | |
| | | |
+-------------------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 sender transmits a message towards the
recipients URI that finally hits the SIP proxy on the recipients recipients URI that finally hits the SIP proxy on the recipients
side. Information provided within that message are used as input to side. Information provided within that message are used as input to
the rule evaluation. Any part of the message may serve as input to the rule evaluation. Any part of the message may serve as input to
the evaluation process but for practical reasons only a few selected the 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. In this document, we argue that the
authenticated identity of the sender is the most valuable information authenticated identity of the sender is the most valuable information
item. In the future, when standardization progresses then, for item. In the future, when standardization progresses then, for
example, reputation information obtained from social networks may example, reputation information obtained from social networks may
offer additional input to the authorization process. The protocol offer additional input to the authorization process. The protocol
interaction for authorizing the message sender refers to the ability interaction for authorizing the message sender refers to the ability
of the recipient or the proxy to interact with the sender to request of the recipient or the proxy to interact with the sender to request
authorization. The request for authorization is a pull model whereby authorization. The request for authorization is a pull model whereby
the proxy or the recipient challenges the sender (e.g., via hash cash the proxy or the recipient challenges the sender (e.g., via hash cash
[I-D.jennings-sip-hashcash], or SIP payment [I-D.jennings-sip-hashcash], or SIP payment
[I-D.jennings-sipping-pay]) for authorization. SIP Identity on the [I-D.jennings-sipping-pay], or Completely Automated Public Turing
other hand realizes as push model whereby authentication information Test to Tell Computers and Humans Apart (CAPTCHA) based robot
is pushed towards the recipient. challenges [I-D.tschofenig-sipping-captcha]) for authorization. SIP
Identity on the other hand realizes as push model whereby
authentication information is pushed towards 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 SPIT prevention solution components. Depending on the rule
evaluation the message may be rerouted to another entity, such as an evaluation the message may be rerouted to another entity, such as an
answering machine, to the recipient, rejected or other actions are 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. For example, a allows further solution components to be executed. For example, a
permission request as part of the consent framework. permission request as part of the consent framework.
SIP message with SIP msg with
authenticated authenticated
identity +---------------+ ^ identity +---------------+
-------------->| | | -------------->| |---------------->
Additional | |-----------+ Additional | | Spam marked msg
Msg fields | Authorization | re-routed Msg fields | Authorization |
-------------->| Engine | -------------->| Engine |---------------->
Other SPIT | |----------------> Other SPIT | | Re-routed msg
Prevention | | forwarded to Prevention | |
Components | | original Components | |---------------->
-------------->+---------------+ recipient -------------->+---------------+ Forwarded to
| | | | 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) can be applied locally within the VoIP
provider's domain also under the control of the end user. For provider's domain also under the control of the end user. For
example, a user that does not want content filtering to impact example, consider a Voice over IP provider that wants to utilize a
message handling would therefore not utilize this functionality. statistical analysis tool for Spam prevention. It is not necessary
to standardized the algorithms; the impact for the authorization
policies is mainly the ability to allow a Rule Maker to enable or to
disable the usage of these statistical techniques for SPIT filtering
and potentially to map the output of the analysis process 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 marking
is proposed in [I-D.schwartz-sipping-spit-saml] and in
[I-D.niccolini-sipping-feedback-spit]. A Rule Maker may decide to
act with an appropriate action on such a Spam marking.
In a minimalistic SPIT framework only authenticated identities in In a minimalistic SPIT framework only authenticated identities in
combination with authorization policies are used. This should serve combination with authorization policies are used. This should serve
as a starting point for future work. as a starting point for future work.
Authenticated Identities: Authenticated Identities:
SIP Identity [RFC4474] is assumed to be used to provide the SIP Identity [RFC4474] is assumed to be used to provide the
receiver of a communication attempt with the authenticated receiver of a communication attempt with the authenticated
identity. SIP Identity is a reasonable simple specification and identity. SIP Identity is a reasonable simple specification and
does not rely on a huge amount of infrastructure support. does not rely on a huge amount of infrastructure support.
Note: SIP Identity is comparable to DKIM
[I-D.ietf-dkim-overview] used for associating a "responsible" Note: SIP Identity is comparable to DomainKeys Identified Mail
identity with an email message and provides a means of (DKIM) [I-D.ietf-dkim-overview] used for associating a
verifying that the association is legitimate. "responsible" identity with an email message and provides a
means of verifying that the association is legitimate.
Authorization Policies: Authorization Policies:
When the white lists are stored and managed only at the end host When the white lists are stored and managed only at the end host
then the authorization policies and the protocol to modify the then the authorization policies and the protocol to modify the
policies do not need to be standardized since they are purely policies do not need to be standardized since they are purely
implementation specific details. Even if the authorization implementation specific details. Even if the authorization
policies are managed centrally or some amount of policy policies are managed centrally or some amount of policy
enforcement is done by trusted intermediaries then still there enforcement is done by trusted intermediaries then still there
might not be a need to standardize an authorization policy might not be a need to standardize an authorization policy
skipping to change at page 6, line 40 skipping to change at page 6, line 50
for end users and therefore it is useful to hide a lot of policy for end users and therefore it is useful to hide a lot of policy
details from the end user itself and to make use of context details from the end user itself and to make use of context
information, for example, address books and authorization policies information, for example, address books and authorization policies
available already created for presence based systems. available already created for presence based systems.
In some cases the above-described approach is not sufficient In some cases the above-described approach is not sufficient
whereby it is necessary to define a standardized protocol, for whereby it is necessary to define a standardized protocol, for
example, if policies are used by different entities, created and example, if policies are used by different entities, created and
modified in an automatic way and when multiple entities manipulate modified in an automatic way and when multiple entities manipulate
policies (potentially on behalf of the person affected by the policies (potentially on behalf of the person affected by the
policies). policies), e.g., the user may have multiple devices.
An example solution for authorization policies providing Spam
prevention capabilities are described in
[I-D.tschofenig-sipping-spit-policy] with the requirements
detailed in [I-D.froment-sipping-spit-requirements].
The white list needs to be created somehow and hence there is an The white list needs to be created somehow and hence there is an
introduction problem. Section 4 discusses this aspect in more introduction problem. Section 4 discusses this aspect in more
details. 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.
skipping to change at page 9, line 43 skipping to change at page 10, line 7
and used to determine the authenticated identity of the sending and used to determine the authenticated identity of the sending
side. side.
o Authorization policies are purely implementation specific matter. o Authorization policies are purely implementation specific matter.
Since a purely end host based rule enforcement suffers from a number Since a purely end host based rule enforcement suffers from a number
of drawbacks, rule enforcement by a trusted intermediary is also of drawbacks, rule enforcement by a trusted intermediary is also
offered. offered.
5.2. Rule Enforcement via a Trusted Intermediary 5.2. Rule Enforcement via a Trusted Intermediary
o SIP Identity [RFC4474] is mandatory to implement at the trusted o SIP Identity [RFC4474] or a corresponding mechanism is mandatory
intermediary (e.g., the immediate VoIP provider) and it determines to implement at the trusted intermediary (e.g., the immediate VoIP
the authenticated identity of the sending side. provider) and it determines the authenticated identity of the
sending side.
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) [I-D.ietf-simple-xcap] is o XML Configuration Access Protocol (XCAP) [RFC4825] is used to
used to create, modify and delete authorization policies and is create, modify and delete authorization policies and is mandatory
mandatory to implement at the end host side and at the trusted to implement at the end host side and at the trusted intermediary.
intermediary.
5.3. Incremental Deployment 5.3. 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
skipping to change at page 10, line 35 skipping to change at page 11, line 5
'urn:ietf:params:xml:ns:new-spit-policy-example'. 'urn:ietf:params:xml:ns:new-spit-policy-example'.
When a client queries the capabilities of a SIP proxy in the VoIP When a client queries the capabilities of a SIP proxy in the VoIP
providers network using XCAP the following exchange may take place. providers network using XCAP the following exchange may take place.
GET /xcap-caps/global/index HTTP/1.1 GET /xcap-caps/global/index HTTP/1.1
Host: xcap.example.com Host: xcap.example.com
Initial XCAP Query for Capabilities Initial XCAP Query for Capabilities
HTTP/1.1 200 OK HTTP/1.1 200 OK
Etag: "wwhha" Etag: "wwhha"
Content-Type: application/xcap-caps+xml Content-Type: application/xcap-caps+xml
<?xml version="1.0" encoding="UTF-8"?>
<xcap-caps xmlns="urn:ietf:params:xml:ns:xcap-caps">
<auids>
<auid>new-spit-policy-example</auid>
<auid>xcap-caps</auid>
</auids>
<namespaces>
<namespace>urn:ietf:params:xml:ns:xcap-caps</namespace>
<namespace>urn:ietf:params:xml:ns:spit-policy</namespace>
<namespace>urn:ietf:params:xml:ns:common-policy</namespace>
</namespaces>
</xcap-caps>
<?xml version="1.0" encoding="UTF-8"?>
<xcap-caps xmlns="urn:ietf:params:xml:ns:xcap-caps">
<auids>
<auid>new-spit-policy-example</auid>
<auid>xcap-caps</auid>
</auids>
<namespaces>
<namespace>urn:ietf:params:xml:ns:new-spit-policy-example</namespace>
<namespace>urn:ietf:params:xml:ns:common-policy</namespace>
</namespaces>
</xcap-caps>
Initial XCAP Response with the supported Capabilities Initial XCAP Response with the supported Capabilities
As shown in the example above, Common Policy and the example SPIT As shown in the example above, Common Policy and the example SPIT
extension is implemented and the client can upload rules according to extension is implemented and the client can upload rules according to
the definition of the rule set functionality. the definition of the rule set functionality.
Later, when the VoIP provider updates the functionality of Later, when the VoIP provider updates the functionality of
authorization policies as more sophisticated mechanisms become authorization policies as more sophisticated mechanisms become
available and get implemented the functionality of the authorization available and get implemented the functionality of the authorization
policy engine is enhanced with, for example, hashcash and the ability policy engine is enhanced with, for example, hashcash and the ability
to perform statistical analysis of signaling message. The latter to perform statistical analysis of signaling message. The latter
functionality comes with the ability to mark messages are Spam and functionality comes with the ability to mark messages are Spam and
the ability for end users to enable/disable this functionality. We the ability for end users to enable/disable this functionality. We
use the AUIDs 'hashcash', 'statistical-analysis' with the namespace use the namespaces 'urn:ietf:params:xml:ns:hashcash' and
'urn:ietf:params:xml:ns:hashcash' and 'urn:ietf:params:xml:ns:statistical-analysis' for those.
'urn:ietf:params:xml:ns:statistical-analysis', respectively.
A end user could now make use of these new functions and a capability A end user could now make use of these new functions and a capability
query of the SIP proxy would provide the following response. query of the SIP proxy would provide the following response.
GET /xcap-caps/global/index HTTP/1.1 GET /xcap-caps/global/index HTTP/1.1
Host: xcap.example.com Host: xcap.example.com
Second XCAP Query for Capabilities Second XCAP Query for Capabilities
HTTP/1.1 200 OK HTTP/1.1 200 OK
Etag: "wwhha" Etag: "wwhha"
Content-Type: application/xcap-caps+xml Content-Type: application/xcap-caps+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xcap-caps xmlns="urn:ietf:params:xml:ns:xcap-caps"> <xcap-caps xmlns="urn:ietf:params:xml:ns:xcap-caps">
<auids> <auids>
<auid>new-spit-policy-example</auid> <auid>spit-policy</auid>
<auid>xcap-caps</auid> <auid>xcap-caps</auid>
<auid>hashcash</auid> <auid>hashcash</auid>
<auid>statistical-analysis</auid> <auid>statistical-analysis</auid>
</auids> </auids>
<namespaces> <namespaces>
<namespace>urn:ietf:params:xml:ns:new-spit-policy-example</namespace> <namespace>urn:ietf:params:xml:ns:spit-policy</namespace>
<namespace>urn:ietf:params:xml:ns:common-policy</namespace> <namespace>urn:ietf:params:xml:ns:common-policy</namespace>
<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.
skipping to change at page 12, line 44 skipping to change at page 13, line 21
RULE 1: RULE 1:
IF identity=alice@foo.example.com THEN ACCEPT IF identity=alice@foo.example.com THEN ACCEPT
IF identity=tony@bar.example.com THEN ACCEPT IF identity=tony@bar.example.com THEN ACCEPT
RULE 2: RULE 2:
IF domain=company-example.com THEN ACCEPT IF domain=company-example.com THEN ACCEPT
RULE 3: RULE 3:
IF unauthenticated THEN IF unauthenticated THEN
EXECUTE hashcast EXECUTE hashcash
REDIRECT sip:voicebox@company-example.com
RULE 4:
IF <hashcash result="success"/>
THEN
REDIRECT sip:voicebox@company-example.com
RULE 5:
IF <hashcash result="failure"/>
THEN
block
Example of Bob's Rule Set Example of Bob's Rule Set
At some point in time Bob uploads his policies to the SIP proxy at At some point in time Bob uploads his policies to the SIP proxy at
his VoIP providers SIP proxy. his VoIP providers SIP proxy.
PUT PUT
/spit-services/users/sip:bob@company-example.com/index/~~/spit-services/ /spit-policy/users/sip:bob@company-example.com/index/~~/ruleset
service%5b@uri=%22sip:good-friends@example.com%22%5d
HTTP/1.1
Content-Type:application/spit+xml
Host: proxy.home-example.com
<<<< Policies go in here. >>>> HTTP/1.1
Content-Type:application/spit+xml
Host: proxy.home-example.com
<<<< Added policies go in here. >>>>
[Editor's Note: In a future version an XML example
policy document will be listed here.]
Uploading Policies using XCAP Uploading Policies using XCAP
When BoB receives a call from his friends, alice@foo.example and When BoB receives a call from his friends, alice@foo.example and
tony@bar.example.com, then the call is forwarded without any further tony@bar.example.com, then all the rules related to the spit policy
checks based on Rule 1. The rules assume that the authenticated are checked. Only the first rule (rule 1) matches and is applied.
identity of the caller has been verified. Thus, the call is forwarded without any further checks based on Rule
1. The rules assume that the authenticated identity of the caller
has been verified.
When Bob receives a call from a co-worker, When Bob receives a call from a co-worker,
Charlie@company-example.com, Rule 2 is applied since the domain part Charlie@company-example.com, Rule 2 is applied since the domain part
in the rule matches the domain part of Charlie's identity. in the rule matches the domain part of Charlie's identity.
Now, when Bob receives a contact from an unknwon user, called Mallice Now, when Bob receives a contact from an unknown user, called Mallice
in this example. Rule 3 indicates that an extended return- in this example. Rule 3 indicates that an extended return-
routability test using hashcash is used with the call being routability test using hashcash [I-D.jennings-sip-hashcash] is used
redirected to Bob's voicebox afterwards. This exchange is shown in with the call being redirected to Bob's voicebox afterwards. This
the figure below. exchange is shown in Figure 9.
UA Proxy Bob's UA Proxy Bob's
Malice Voicebox Malice Voicebox
| INVITE | | | INVITE | |
|------------------------->|Puzzle: work=15; | |------------------------->|Puzzle: work=15; |
| |pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; | | |pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; |
| 419 with Puzzle |image="NhhMQ2l7SE0VBmZFKksUC19ia04="; | | 419 with Puzzle |image="NhhMQ2l7SE0VBmZFKksUC19ia04="; |
| |value=160 | | |value=160 |
|<-------------------------| | |<-------------------------| |
| | | | | |
skipping to change at page 14, line 33 skipping to change at page 14, line 50
| | 180 Ringing | | | 180 Ringing |
| 180 Ringing |<-------------------------------------| | 180 Ringing |<-------------------------------------|
|<-------------------------| | |<-------------------------| |
| | 200 OK | | | 200 OK |
| 200 OK |<-------------------------------------| | 200 OK |<-------------------------------------|
|<-------------------------| | |<-------------------------| |
| | ACK | | | ACK |
|---------------------------------------------------------------->| |---------------------------------------------------------------->|
| | | | | |
Example Exchange: Malice contacts Bob Figure 9: Example Exchange: Malice contacts Bob
Depending on the outcome of the exchange the call is forwarded to a
mailbox sip:voicebox@company-example.com (in case Malory returned the
correct solution, see Rule 4) or blocked in case an incorrect
response was provided. It might be quite easy to see how this rule
set can be extended to support other SPIT handling mechanisms as well
(e.g., CAPTCHAs, SIP Pay, etc.).
8. Security Considerations 8. Security Considerations
This document aims to describe a framework for addressing Spam for This document aims to describe a framework for addressing Spam for
Internet Telephony (SPIT) in order to make it simple for users to Internet Telephony (SPIT) in order to make it simple for users to
influence the behavior of SIP message routing with an emphasis on influence the behavior of SIP message routing with an emphasis on
SPIT prevention. SPIT prevention.
The framework relies on three building blocks, namely SIP Identity, The framework relies on three building blocks, namely SIP Identity,
authorization policies based on Common Policy and Presence authorization policies based on Common Policy and Presence
skipping to change at page 15, line 15 skipping to change at page 15, line 40
It must be avoided to introduce Denial of Service attacks against the It must be avoided to introduce Denial of Service attacks against the
recipient by misguiding him or her to install authorization policies recipient by misguiding him or her to install authorization policies
that allow senders to bypass the policies although that was never that allow senders to bypass the policies although that was never
intended by the recipient. Additionally, it must not be possible by intended by the recipient. Additionally, it must not be possible by
extensions to the authorization policy framework to create policies extensions to the authorization policy framework to create policies
to block legitimate senders or to stall the processing of the to block legitimate senders or to stall the processing of the
authorization policy engine. authorization policy engine.
9. Acknowledgments 9. Acknowledgments
We would like to thank Jeremy Barkan, Dan York, Alexey Melnikov, We would like to thank
Thomas Schreck, Eva Leppanen, Cullen Jennings, Marit Hansen, and
Markus Hansen for their review comments.
10. References Jeremy Barkan, Dan York, Alexey Melnikov, Thomas Schreck, Eva
Leppanen, Cullen Jennings, Marit Hansen and Markus Hansen for
their review comments to a pre-00 version.
Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski,
Saverio Niccolini, Albert Caruana, and Juergen Quittek for their
comments to the 00 version.
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.
[I-D.ietf-simple-xcap] [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-12 (work in progress),
October 2006.
10.2. Informative References 10.2. Informative References
[I-D.froment-sipping-spit-authz-policies]
Froment, T., "Authorization Policies for Preventing SPIT",
draft-froment-sipping-spit-authz-policies-02 (work in
progress), February 2007.
[I-D.ietf-sipping-spam] [I-D.ietf-sipping-spam]
Jennings, C. and J. Rosenberg, "The Session Initiation Jennings, C. and J. Rosenberg, "The Session Initiation
Protocol (SIP) and Spam", draft-ietf-sipping-spam-04 (work Protocol (SIP) and Spam", draft-ietf-sipping-spam-04 (work
in progress), February 2007. in progress), February 2007.
[I-D.ietf-simple-presence-rules] [I-D.ietf-simple-presence-rules]
Rosenberg, J., "Presence Authorization Rules", Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-09 (work in progress), draft-ietf-simple-presence-rules-09 (work in progress),
March 2007. March 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-05 (work in progress), SIP", draft-jennings-sip-hashcash-05 (work in progress),
June 2007. June 2007.
[I-D.ietf-sip-consent-framework] [I-D.ietf-sip-consent-framework]
Rosenberg, J., "A Framework for Consent-Based Rosenberg, J., "A Framework for Consent-Based
Communications in the Session Initiation Protocol (SIP)", Communications in the Session Initiation Protocol (SIP)",
draft-ietf-sip-consent-framework-01 (work in progress), draft-ietf-sip-consent-framework-02 (work in progress),
November 2006. July 2007.
[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) Message Signing Service Overview", Identified Mail (DKIM) Message Signing Service Overview",
draft-ietf-dkim-overview-05 (work in progress), June 2007. draft-ietf-dkim-overview-05 (work in progress), June 2007.
[I-D.tschofenig-sipping-spit-policy] [I-D.tschofenig-sipping-spit-policy]
Tschofenig, H., "Anti-SPIT : A Document Format for Tschofenig, H., "Anti-SPIT : A Document Format for
Expressing Anti-SPIT Authorization Policies", Expressing Anti-SPIT Authorization Policies",
draft-tschofenig-sipping-spit-policy-00 (work in draft-tschofenig-sipping-spit-policy-00 (work in
progress), February 2007. progress), February 2007.
[I-D.schwartz-sipping-spit-saml]
Schwartz, D., "SPAM for Internet Telephony (SPIT)
Prevention using the Security Assertion Markup Language
(SAML)", draft-schwartz-sipping-spit-saml-01 (work in
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-05 (work in Protocol (SIP)", draft-jennings-sipping-pay-05 (work in
progress), October 2006. progress), October 2006.
[I-D.froment-sipping-spit-requirements]
Froment, T., "Requirements for Authorization Policies to
tackle Spam for Internet Telephony and Unwanted Traffic",
draft-froment-sipping-spit-requirements-00 (work in
progress), June 2007.
[I-D.niccolini-sipping-feedback-spit]
Niccolini, S., "SIP Extensions for SPIT identification",
draft-niccolini-sipping-feedback-spit-03 (work in
progress), February 2007.
[I-D.tschofenig-sipping-captcha]
Tschofenig, H. and E. Leppanen, "Completely Automated
Public Turing Test to Tell Computers and Humans Apart
(CAPTCHA) based Robot Challenges for the Session
Initiation Protocol (SIP)", 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
Behandlung von Voice over IP (VoIP), available at Behandlung von Voice over IP (VoIP), available at
skipping to change at page 18, line 4 skipping to change at page 18, line 36
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
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
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+ecrit@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
Phone: 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
 End of changes. 41 change blocks. 
107 lines changed or deleted 165 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/