One document matched: draft-tschofenig-sipping-framework-spit-reduction-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY RFC4745 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml">
<!ENTITY RFC3857 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3857.xml">
<!ENTITY RFC4825 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4825.xml">
<!ENTITY RFC3323 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3323.xml">
<!ENTITY RFC3325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml">
<!ENTITY XEP-0161 SYSTEM "http://www.xmpp.org/extensions/refs/reference.XSF.XEP-0161.xml">
<!ENTITY I-D.tschofenig-sipping-spit-policy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-sipping-spit-policy.xml">
<!ENTITY RFC5039 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5039.xml">
<!ENTITY RFC5025 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5025.xml">
<!ENTITY I-D.ietf-sip-saml SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-saml.xml">
<!ENTITY I-D.jennings-sip-hashcash SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-sip-hashcash.xml">
<!ENTITY I-D.ietf-sipping-consent-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-consent-framework.xml">
<!ENTITY I-D.ietf-dkim-overview SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dkim-overview.xml">
<!ENTITY I-D.shacham-http-corr-uris SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shacham-http-corr-uris.xml">
<!ENTITY I-D.jennings-sipping-pay SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-sipping-pay.xml">
<!ENTITY I-D.froment-sipping-spit-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.froment-sipping-spit-requirements.xml">
<!ENTITY I-D.schwartz-sipping-spit-saml SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schwartz-sipping-spit-saml.xml">
<!ENTITY I-D.ietf-sip-ua-privacy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-ua-privacy.xml">
<!ENTITY I-D.niccolini-sipping-feedback-spit SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.niccolini-sipping-feedback-spit.xml">
<!ENTITY I-D.wing-sipping-spam-score SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-sipping-spam-score.xml">
<!ENTITY I-D.tschofenig-sipping-captcha SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-sipping-captcha.xml">
]>
<rfc category="info" docName="draft-tschofenig-sipping-framework-spit-reduction-04"
ipr="full3978">
<front>
<title abbrev="Framework for Reducing Spam">A Framework to tackle Spam and Unwanted
Communication for Internet Telephony</title>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Jonathan Rosenberg" initials="J." surname="Rosenberg">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>600 Lanidex Plaza</street>
<city>Parsippany</city>
<region>New York</region>
<code>07054</code>
<country>USA</country>
</postal>
<email>jdrosen@cisco.com</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<author initials="D." surname="Schwartz" fullname="David Schwartz">
<organization>XConnect</organization>
<address>
<postal>
<street>Malcha Technology Park</street>
<city>Jerusalem</city>
<region/>
<code>96951</code>
<country>Israel</country>
</postal>
<email>dschwartz@xconnect.net</email>
</address>
</author>
<date year="2008"/>
<area>Real-time Applications and Infrastructure</area>
<workgroup>SIPPING</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Spam for Internet Telephony (SPIT)</keyword>
<abstract>
<t>Spam, defined as sending unsolicited messages to someone in bulk, is likely to become a
problem on SIP open-wide deployed networks. A number of solutions have been proposed for
dealing with Spam for Internet Telephony (SPIT) and unwanted communication, such as
content filtering, black lists, white lists, consent-based communication, reputation
systems, address obfuscation, limited use addresses, turing tests, computational
puzzles, payments at risk, circles of trust, and many others.</t>
<t> This document describes the big picture that illustrates how the different building
blocks fit together and can be deployed incrementally.</t>
</abstract>
</front>
<middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="introduction" title="Introduction">
<t>The problem of Spam for Internet Telephony (SPIT) is an imminent challenge and only the
combination of several techniques can provide a way to deal with unwanted communication
attempts.</t>
<t><xref target="RFC5039"/> provides four core recommendations that need to be considered
for a SPIT solution, namely</t>
<t>
<list style="symbols">
<t>Strong Identity</t>
<t>White Lists</t>
<t>Solve the Introduction Problem</t>
<t>Don't Wait Until its Too Late</t>
</list>
</t>
<t>This document illustrates how existing building blocks can be put together to be able to
recognize unwanted communication attempts and to execute appropriate actions. Ideally, a
framework should allow new building blocks to be added as adversaries become more
sophisticated. Since there are strong economical incentives for adversary to exploit
communication networks that are widely deployed it only possible to detect and react on
unwanted communication attempts in such a way that the total number of unwanted
communication attempts reaches a level that is acceptable for the end user considering
false positives and the additional burden for the users using these mechanisms. </t>
<t>The purpose of this document defines a model of internal device processing, protocol
interfaces, and terminology to illustrate a way in which SPIT prevention techniques can
be added in a seamless fashion. This document focuses on the descripion of how to
combine different building blocks in an architectural fashion. No specific pre-selection
is being provided on what mechanism should be standardized or implemented by various
parties. This is left to the parties deploying these mechanisms and, when it comes to
standardization, subject of a separate document to pick an initial set of mechanisms to
start with. </t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="terminology" title="Terminology">
<t>This document does not contain normative language.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Framework">
<t><xref target="overview"/> shows the interaction between the end host and a SIP proxy
belonging to its VoIP provider. One important part of the overall solution is the
ability to make authorization decisions based on incoming communication attempts. The
entity that writes these authorization rules is referred as Rule Maker. A human, acting
as the Rule Maker, might enter policies via some form of graphical user interface; some
other policies may be generated automatically by observing the behavior of the user.
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 service
provider. </t>
<t>Policies are processed by corresponding module within the SIP proxy, called
Authorization Engine, that interacts with the message routing component. By following
this architectural approach the Policy Decision Point (PDP) and the Policy Enforcement
Point (PEP) are closely combined. As such, authorization policies are stored at at a SIP
proxy rather than the SIP UA client itself. The implications of relocating these two
functions, PDP and PEP, to the SIP UA client are described in <xref
target="policies-at-host"/>. </t>
<t>
<figure anchor="overview" title="Overview">
<artwork><![CDATA[
+---------------------------------------------------------+
| Authorization |
| re-route Policy +------------+ |
| ^ (implicit) ######| Rule Maker | |
| o +#######+ # +------------+ |
| o # # # |
| +---o----------#-------#--+ # Authorization |
| | o # # |<####### Policy |
+--------+ | | o Proxy # # | |
| | | | o # # |<*******************+ |
| Sender |<***>|+-------+ v # | * |
| | | ||Msg. | +-----------+| Authorization * |
+--------+ | ||Routing| | Authz. || Policy (explicit) * |
^ o | ||Engine |<->| Engine |<#################+ * |
* o | |+-------+ +-----------+| # * |
* o | +-^--*--^-----------------+ # v |
* o | o * o +-------------+ |
* o | o * o | | |
* +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient/ | |
+**************************************************>| Rule Maker | |
| +-------------+ |
| |
| |
+-------------------Domain Boundary-----------------------+
Legend:
oooo: SIP message interaction
****: Protocol Interaction for authorizing the message sender
####: Management of authorization policies
]]></artwork>
</figure>
</t>
<t>Assume that an arbitrary entity transmits a message to a specific URI that finally hits
the SIP proxy on the recipients 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
evaluation process but for practical reasons a few selected fields do most of the work.
There are three aspects to consider when it comes to the rule evaluation: </t>
<t>
<list style="hanging">
<t hangText="Where does identity information come from?"><vspace blankLines="1"/>
Authentication information can come in different forms, depending on the chosen
SIP security mechanism (e.g., P-Asserted-ID <xref target="RFC3325"/> or SIP
Identity <xref target="RFC4474"/>). Additionally, the interworking with the
privacy mechanisms, such as <xref target="RFC3323"/> or <xref
target="I-D.ietf-sip-ua-privacy"/> need to be considered. <vspace
blankLines="1"/> An example of how these different mechanisms are being
considered during the rule evaluation is described in Common Policy <xref
target="RFC4745"/> and Presence Authorization Policy <xref target="RFC5025"/>. </t><vspace blankLines="1"/>
<t hangText="What is the quality of the authentication procedure?"><vspace
blankLines="1"/> When evaluating authorization policies with respect to an
incoming request the identity information of the entity sending the message may
provide enough information when the recipient authorized that specific sender's
identity. However, when the authorization policies refer to entire domains instead
of individual users then it would be valuable to know how easily users within that
specific domain are able to aquire their identities and how strong the
authentication procedure actuallly is. Consider the following example: an
enterprise network provisions entities to employees only and the authentication
credentials are based on a smart card based mechanism. In an other case new
identities can be created on the fly using a protocol interaction with an
email-address based return routability check without additional verification. As
such, in these two examples the chances to hold a real-world person accountable
for their actions is very likely to be different in case that abuse reports are
received by the two VoIP providers. Unfortunately, information about such a
process is often not available when the authorization decision is being made. </t> <vspace blankLines="1"/>
<t hangText="Who creates the policies?"><vspace blankLines="1"/> Identity based
authorization rules may contain entries for specific users or for entire domains.
Such policies may be configured by the end host as a Rule Maker or by the VoIP
provider themself. Particularly the later part is likely to be attractive for VoIP
providers since they may be able to form federations of VoIP providers that
fulfill certain preconditions with respect to their VoIP / IM usage. These type of
federations are also the basis for getting SIP SAML <xref
target="I-D.ietf-sip-saml"/> to work since a valid digital signature together
with the presence of certain assertions statements is insufficient as a basis for
trusting their content.</t>
</list>
</t>
<t>As illustrated above, there are various possible actions that may be taken by the
receipient or it's VoIP provider to authorize the message sender. Some of these
mechanisms may require interaction with the sender. The request for authorization might
require the message sender to be challenged (e.g., via hash cash <xref
target="I-D.jennings-sip-hashcash"/>, via SIP payment <xref
target="I-D.jennings-sipping-pay"/>, or via CAPTCHAs <xref
target="I-D.tschofenig-sipping-captcha"/>). Some other mechanisms, such as SIP
Identity do not require the verifying entity to challenge the authentication service
since the identity assertion is pushed towards the recipient.</t>
<t>Additionally, it is possible to utilize mechanisms the Consent Framework <xref
target="I-D.ietf-sipping-consent-framework"/> or the Information Event Package <xref
target="RFC3857"/> to allow the recipient to authorize a request.</t>
<t><xref target="authz-engine"/> shows this integration step. The conditions part of the
rule offer a mechanisms to incrementally extend the overall framework with new
components. Depending on the outcome of the rule evaluation, the message may be
re-routed to another entity, such as an answering machine, to the recipient, rejected or
other actions are triggered. The latter aspect is particularly interesting since it
allows further solution components to be executed.</t>
<t>
<figure anchor="authz-engine" title="Message Filtering and Routing">
<artwork><![CDATA[
SIP msg with
authenticated
identity +---------------+
-------------->| |---------------->
Additional | | Spam marked msg
Msg fields | Authorization |
-------------->| Engine |---------------->
Other SPIT | | Re-routed msg
Prevention | |
Components | |---------------->
-------------->+---------------+ Forwarded to
| | original recipient
| |
<-----------+ +----------->||
Politely blocked Blocked
]]></artwork>
</figure>
</t>
<t>Note that some traffic analysis and consequently some form of content filtering (e.g.,
of MESSAGEs) message be applied locally within the VoIP provider's domain also under the
control of the end user. However, this is largely an implementation-specific technique
without protocol impact. For example, consider a VoIP provider that wants to utilize a
statistical analysis tool for Spam prevention. It is not necessary to standardized the
algorithms nor protocols; the impact for the authorization policies is mainly the
ability to allow the 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) and 100 (i.e., the message was
classified as Spam). A Rule Maker may decide to act with an appropriate action on a
certain level of Spam marking. </t>
<!-- <t>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.</t>
-->
<t>
<list style="hanging">
<t hangText="Authenticated Identities:"><vspace blankLines="1"/> Initial VoIP
provider are likely to secure their SIP signaling using Transport Layer Security
(TLS) or IP security (IPsec) between neighboring providers and use P-Asserted-ID
<xref target="RFC3325"/>. <vspace blankLines="1"/>
<list style="empty">
<t>Note: SIP Identity is comparable to DomainKeys Identified Mail (DKIM) <xref
target="I-D.ietf-dkim-overview"/> used for associating a "responsible"
identity with an email message and provides a means of verifying that the
association is legitimate.</t>
</list>
<vspace blankLines="1"/> SIP Identity <xref target="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.<vspace blankLines="1"/> 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. <vspace blankLines="1"/></t>
<t hangText="Authorization Policies:"><vspace blankLines="1"/> Even if policy
decision making and policy enforcement is done outside the SIP UA client then
still there might not be a need to standardize an authorization policy language if
the policies can be modified via a webpage. This approach of policy handling is
done in many cases today already for various applications. <vspace blankLines="1"
/> Unfortunately, this approach tends to become cumbersome for end users and
therefore it is better to hide a lot of policy details from the end user itself
and to make use of context information, for example, address books and
authorization policies available already created for presence based systems.
<vspace blankLines="1"/> Additionally, a user may have multiple devices and a
consistent view of the policies should be provided. <vspace blankLines="1"/> An
example solution for authorization policies for dealing with reducing unwanted
communication is described in <xref target="I-D.tschofenig-sipping-spit-policy"/>
with the requirements detailed in <xref
target="I-D.froment-sipping-spit-requirements"/>.</t>
</list>
</t>
<t>There is still one significant problem unsolved: since white lists need to be created
somehow and hence there is an introduction problem. <xref
target="communication-patterns"/> discusses this aspect in more details.</t>
<!-- <t>Based on the above-described framework we discuss extensions in the subsequent
sections.</t>
-->
</section>
<section anchor="communication-patterns" title="Communication Patterns and User Groups">
<t>When communication takes place then at least three types of groups can be identified.</t>
<section title="Closed Groups">
<t>People in this group communicate only with the peers in their group. They do not
appreciate communication attempts from outside. Communication is possible only for
people within this list. Here is an example of a closed group: Consider parents that
do not want their children from getting contacted by strangers. Hence, they may want
to create a white list containing the identifies of known friends, parents and other
relatives on behalf of their kids.</t>
<t>The usage of authorization policies for usage with closed groups is straight forward.
The introduction problem is also not considered very large given that the identities
of the individual entities are typically known in an out-of-band fashion.</t>
</section>
<section title="Semi-Open Groups">
<t>In a semi-open environment all members of the same group are allowed to get in
contact with everyone else (e.g., persons working within the same company are allowed
to contact each other without restrictions). For the communication with persons
outside the company the communication patters depend on the role of the specific
person (e.g., standardization people, sales people, etc.) and on the work style of
the person.</t>
<t>For this category we distinguish a number of (non-spam) message sources based on
their characteristics:</t>
<t>
<list style="symbols">
<t>"friends" or "acquaintances", i.e., those we have communicated with before.</t>
<t>strangers, divided into 'interesting' and 'uninteresting'. The latter are
messages from people that someone does not care to have a conversation with or
respond to, at least at that particular moment.</t>
</list>
</t>
<t>Strangers can be defined by individual names or whole domains. A special class of
'stranger' messages are transaction-related communications, such as automated
messages or calls from an airline or shipping company.</t>
<t>One way to deal with the introduction problem is to make use of techniques like hash
cash <xref target="I-D.jennings-sip-hashcash"/> or Completely Automated Public Turing
Test to Tell Computers and Humans Apart (CAPTCHA) based robot challenges <xref
target="I-D.tschofenig-sipping-captcha"/>. Alternatively, a communication attempt
may also be forwarded to an answering maschine or alternative ways of establishing
the initial interaction may be proposed. </t>
<t>The usage of authorization policies for usage with Semi-Open Groups is challenging
but is considered manageable.</t>
<!-- <t>In the PSTN a certain amount of protection against unwanted calls is provided due to
costs for phone calls. With almost free calls (or instant messages) it might be necessary
to abandon the idea of allowing end-to-end real-time message delivery in all cases in
order to avoid the alerting the user.</t>
-->
</section>
<section title="Open Groups">
<t>People in this type of group are not allowed to limit communication attempts. Help
desks, certain people in governmental agencies, banks, insurance companies, etc.</t>
<t>For open groups a solution for providing SPIT prevention is far more complicated.
Consider a person working on a customer support helpdesk. Ideally, they would like to
receive only calls from friendly customers (although the motivation for calling is
most likely a problem they experience) and the topic of the calls only relates to
problems they are able to solve. Without listening to the caller they will have a
hard time to know whether the call could be classified as SPIT or not. Another
extreme case is a Public Safety Answering Point where emergency service personell is
not allowed to reject calls either. </t>
<t> Many SPIT prevention techniques might not be applicable since blocking callers is
likely not possible and applying other techniques, such as turing tests, might not be
ideal in an case of open groups. </t>
<t>Providing additional information about the caller may be helpful from the called
party VoIP provider but cannot be considered sufficient. A more promising approach is
the ability to provide abuse reporting in the style of <xref target="XEP-0161"/> to
provide the ability for punishment in case of misuse. This approach is helpful if an
honest VoIP provider has to deal with a small number of adversaries within their
network and the abuse reporting entity is trusted by that VoIP provider as well. This
technique is not helpful when VoIP provider itself is convolated in sending spam
messages or has some other financial benefits from not holding the adversary
accountable. Another possible approach is to establish blacklisted domains within a
federation, as this is common practice within the email domain.</t>
</section>
<section title="Summary">
<t>Based on the discussions regarding communication patters and groups the following
observations can be made:</t>
<t>
<list style="symbols">
<t>A single person very likely has many roles and they may have an impact on the
communication patterns.<list style="empty">
<t>For example, consider a person who is working in a company but also want
to be available for family members.</t>
</list></t>
<t>The context in which a person is may change at any time. For example, a person
might be available for family members while at work except during an important
meeting where communication attempts may be rejected. Switching a context has
an impact for reachability and the means for communicating with a specific
recipient, based on enabled rule sets.</t>
</list>
</t>
<t>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 between different spheres easily
by thereby switching to a different rule set.</t>
</section>
<section title="Usability">
<t>An important aspect in the usage of authorization policies is to assist the user when
creating policies. Ideally, the policies should be established automatically. Below,
there are a couple of examples to illustrate the idea given that these aspects are
largely implementation issues:</t>
<t>
<list style="symbols">
<t>It must be possible for the proxy to automatically add addresses on outbound
messages and calls to the rule set. This approach is similar to stateful packet
filtering firewalls where outbound packets establish state at the firewall to
allow inbound packets to traverse it again.</t>
<t>Already available information in the address book can be used for building the
policy rules there is quite likely already a relationship available with these
persons existent.</t>
<t>A large amount of email is non-personal, automated communication, such as
newsletters, confirmations and legitimate advertisements. These are often
tagged as spam by content filters. This type of correspondence is usually
initiated by a transaction over the web, such as a purchase or signing up for a
service. <xref target="I-D.shacham-http-corr-uris"/>, for example, defines an
HTTP header for conveying future correspondence addresses that can be
integrated in the rule set.</t>
</list>
</t>
</section>
<!-- <t>There are, however, a couple of challenges that need to be addressed:</t>
<t>
<list style="symbols">
<t>How is a communication attempt authorized that resulted on a previous real-world
interaction? For example, Joe gives Jane a business card (but not vice versa or Joe has
not updated her authorization policy). When Jane contacts Joe, Jane is not authorized
yet.</t>
<t>Is it necessary that some parties must be allowed to override the authorization
policies when contacted by someone? </t>
</list>
</t>
<t>When considering past experience on presence systems a couple of answers are available for
the above-mentioned problems. Consent-based communication, for example, is a potential
solution to communication attempts by unknown parties. In other cases it might be more
reasonable to to make use of limited use addresses when a long-lasting communication is not
desired.</t>
-->
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Protocol Interactions">
<t>This section describes the necessary building blocks that are necessary to tie the
framework together. </t>
<section title="Rule Enforcement via a Trusted Intermediary">
<t>
<list style="symbols">
<t>Some from of strong identity assurance is required to build the basis for
identity-based authorization. SIP Identity <xref target="RFC4474"/> or
P-Asserted-ID <xref target="RFC3325"/> are examples of available mechanisms.
These mechanisms allow the authenticated identity of the sending party to be
determined. </t>
<t>Authorization Policies based on the Common Policy framework <xref
target="RFC4745"/>, as extended in <xref
target="I-D.tschofenig-sipping-spit-policy"/> for the purpose of SPIT
prevention, are mandatory to implement at the end host side and at the trusted
intermediary. The implementation of the rule evaluation engine might only be
necessary on the trusted VoIP proxy. Harmonization with the work done for
presence authorization <xref target="RFC5025"/>, which is based on Common
Policy <xref target="RFC4745"/>, can be accomplished and is highly desirable.</t>
<t>XML Configuration Access Protocol (XCAP) <xref target="RFC4825"/> is used to
create, modify and delete authorization policies and is mandatory to implement
at the end host side and at the trusted intermediary.</t>
</list>
</t>
</section>
<section title="Incremental Deployment">
<t>An important property is incremental deployment of additional solution components
that can be added and used when they become available. This section aims to
illustrate how the extensibility is accomplished, based on an example.</t>
<t>Consider a VoIP provider that provides authorization policies that provide the
following functionality equivalent to the Common Policy framework, i.e.,
identity-based, sphere and validity based conditions initially. For actions only
'redirection' and 'blocking' is provided. In our example we give this basic
functionality the AUID 'new-spit-policy-example' with the namespace
'urn:ietf:params:xml:ns:new-spit-policy-example'.</t>
<t>When a client queries the capabilities of a SIP proxy in the VoIP providers network
using XCAP the following exchange may take place.</t>
<t>
<figure anchor="xcap-query" title="Initial XCAP Query for Capabilities">
<artwork><![CDATA[
GET /xcap-caps/global/index HTTP/1.1
Host: xcap.example.com
]]></artwork>
</figure>
</t>
<t>
<figure anchor="xcap-response" title="Initial XCAP Response with the supported Capabilities">
<artwork><![CDATA[
HTTP/1.1 200 OK
Etag: "wwhha"
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>
]]></artwork>
</figure>
</t>
<t>As shown in the example above, Common Policy and the example SPIT extension is
implemented and the client can upload rules according to the definition of the rule
set functionality.</t>
<t>Later, when the VoIP provider updates the functionality of authorization policies as
more sophisticated mechanisms become available and get implemented the functionality
of the authorization policy engine is enhanced with, for example, hashcash and the
ability to perform statistical analysis of signaling message. The latter
functionality comes with the ability to mark messages are Spam and the ability for
end users to enable/disable this functionality. We use the namespaces
'urn:ietf:params:xml:ns:hashcash' and 'urn:ietf:params:xml:ns:statistical-analysis'
for those.</t>
<t>A end user could now make use of these new functions and a capability query of the
SIP proxy would provide the following response.</t>
<t>
<figure anchor="second-xcap-query" title="Second XCAP Query for Capabilities">
<artwork><![CDATA[
GET /xcap-caps/global/index HTTP/1.1
Host: xcap.example.com
]]></artwork>
</figure>
</t>
<t>
<figure anchor="second-xcap-response" title="Second XCAP Response with the supported Capabilities">
<artwork><![CDATA[
HTTP/1.1 200 OK
Etag: "wwhha"
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>spit-policy</auid>
<auid>xcap-caps</auid>
<auid>hashcash</auid>
<auid>statistical-analysis</auid>
</auids>
<namespaces>
<namespace>urn:ietf:params:xml:ns:spit-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:statistical-analysis</namespace>
</namespaces>
</xcap-caps>
]]></artwork>
</figure>
</t>
<t>New SPIT handling functionality may extend condition, actions and/or transformation
elements of a rule.</t>
</section>
<section title="Botnets">
<t>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. </t>
<t>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 </t>
<t>
<list style="symbols">
<t>The botnet does not have access to the user's credentials. In this case
identity-based white lists provides adequate protection. </t>
<t>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. </t>
<t>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. </t>
</list>
</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Privacy Considerations">
<t>This document does not propose to distribute the user's authorization policies to other
VoIP providers nor is the configuration of policies at SIP proxies other than the
trusted user's VoIP provider necessary. Furthemore, if blocking or influencing of the
message processing is 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 "super-clever"
machine learning techniques often introduces unpredictability.</t>
<t>Legal norms from fields of law can take regulative effects in the context of SPIT
processing, such as constitutional law, data protection law, telecommunication law,
teleservices law, criminal law, and possibly administrative law. See, for example, <xref
target="Law1"/>, <xref target="Law2"/> and <xref target="Law3"/>. For example, it is
mandatory to pass full control of SPIT filtering to the end user, as this minimises
legal problems.</t>
<t>An overview about regulatory aspects can be found in <xref target="Spit-AL"/>.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Example">
<t>This section shows an example whereby we consider a user Bob@company-example.com that
writes (most likely via a nice user interface) the following policies. We use a
high-level language to show the main idea of the policies.</t>
<t>
<figure anchor="example-bob" title="Example of Bob's Rule Set">
<artwork><![CDATA[
RULE 1:
IF identity=alice@foo.example.com THEN ACCEPT
IF identity=tony@bar.example.com THEN ACCEPT
RULE 2:
IF domain=company-example.com THEN ACCEPT
RULE 3:
IF unauthenticated THEN
EXECUTE hashcash
RULE 4:
IF <hashcash result="success"/>
THEN
REDIRECT sip:voicebox@company-example.com
RULE 5:
IF <hashcash result="failure"/>
THEN
block
]]></artwork>
</figure>
</t>
<t>At some point in time Bob uploads his policies to the SIP proxy at his VoIP providers
SIP proxy.</t>
<t>
<figure anchor="uploading" title="Uploading Policies using XCAP">
<artwork><![CDATA[
PUT
/spit-policy/users/sip:bob@company-example.com/index/~~/ruleset
HTTP/1.1
Content-Type:application/spit+xml
Host: proxy.home-example.com
<<<< Added policies go in here. >>>>
]]></artwork>
</figure>
</t>
<t>When BoB receives a call from his friends, alice@foo.example and tony@bar.example.com,
then all the rules related to the spit policy are checked. Only the first rule (rule 1)
matches and is applied. 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.</t>
<t>When Bob receives a call from a co-worker, Charlie@company-example.com, Rule 2 is
applied since the domain part in the rule matches the domain part of Charlie's identity.</t>
<t>Now, when Bob receives a contact from an unknown user, called Mallice in this example.
Rule 3 indicates that an extended return-routability test using hashcash <xref
target="I-D.jennings-sip-hashcash"/> is used with the call being redirected to Bob's
voicebox afterwards. This exchange is shown in <xref target="malice"/>.</t>
<t>
<figure anchor="malice" title="Example Exchange: Malice contacts Bob">
<artwork><![CDATA[
UA Bob's
Malice Proxy Voicebox
| INVITE | |
|------------------------->|Puzzle: work=15; |
| |pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; |
| 419 with Puzzle |image="NhhMQ2l7SE0VBmZFKksUC19ia04="; |
| |value=160 |
|<-------------------------| |
| | |
| ACK | |
|------------------------->| |
| |Puzzle: work=0; |
| |pre="VgVGYixbRg0mdSwTY3YIfCBuYmg="; |
| |image="NhhMQ2l7SE0VBmZFKksUC19ia04=" |
| INVITE with Solution |value=160 |
|------------------------->| INVITE |
| |------------------------------------->|
| | |
| | 180 Ringing |
| 180 Ringing |<-------------------------------------|
|<-------------------------| |
| | 200 OK |
| 200 OK |<-------------------------------------|
|<-------------------------| |
| | ACK |
|---------------------------------------------------------------->|
| | |
]]></artwork>
</figure>
</t>
<t>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.). </t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Security Considerations">
<t>This document aims to describe a framework for addressing Spam for Internet Telephony
(SPIT) in order to make it simple for users to influence the behavior of SIP message
routing with an emphasis on SPIT prevention.</t>
<t>The framework relies on three building blocks, namely SIP Identity, authorization
policies based on Common Policy and Presence Authorization Policy, and XCAP.</t>
<t>As a high-level overview, the framework allows the user to control end-to-end
connectivity at the SIP message routing level whereby the glue that lets all parts fit
together is based on authorization policies. Several other solution components can be
developed independently and can be plugged into the framework as soon as available.</t>
<t>It must be avoided to introduce Denial of Service attacks against the recipient by
misguiding him or her to install authorization policies that allow senders to bypass the
policies although that was never intended by the recipient. Additionally, it must not be
possible by extensions to the authorization policy framework to create policies to block
legitimate senders or to stall the processing of the authorization policy engine.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Acknowledgments">
<t>We would like to thank</t>
<t>
<list style="empty">
<t>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. </t>
<t>Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski, Saverio
Niccolini, Albert Caruana, and Juergen Quittek for their comments to the 00
version.</t>
<t>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.</t>
</list>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
</middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<back>
<references title="Normative References"> </references>
<references title="Informative References"> &RFC3323; &RFC4474; &RFC4745;
&RFC3325; &RFC4825; &RFC5039; &RFC5025; &I-D.jennings-sip-hashcash;
&I-D.wing-sipping-spam-score; &I-D.ietf-sipping-consent-framework;
&I-D.ietf-dkim-overview; &I-D.tschofenig-sipping-spit-policy;
&I-D.schwartz-sipping-spit-saml; &I-D.shacham-http-corr-uris;
&I-D.jennings-sipping-pay; &I-D.froment-sipping-spit-requirements;
&I-D.niccolini-sipping-feedback-spit; &I-D.tschofenig-sipping-captcha; &I-D.ietf-sip-ua-privacy;
&RFC3857;
&I-D.ietf-sip-saml; <reference
anchor="Spit-AL">
<front>
<title>Developing a Legally Compliant Reachability Management System as a
Countermeasure against SPIT, Third Annual VoIP Security Workshop, Berlin,
available at https://tepin.aiki.de/blog/uploads/spit-al.pdf</title>
<author fullname="Markus Hansen" initials="M." surname="Hansen">
<organization/>
</author>
<author fullname="Marit Hansen" initials="M." surname="Hansen">
<organization/>
</author>
<author fullname="Jan Möller" initials="J." surname="Möller">
<organization/>
</author>
<author fullname="Thomas Rohwer" initials="T." surname="Rohwer">
<organization/>
</author>
<author fullname="Carsten Tolkmitt" initials="C." surname="Tolkmitt">
<organization/>
</author>
<author fullname="Henning Waack" initials="H." surname="Waack">
<organization/>
</author>
<date month="June" year="2006"/>
</front>
</reference>
<reference anchor="Law1">
<front>
<title>Bundesnetzagentur: Eckpunkte der regulatorischen Behandlung von Voice over IP
(VoIP), available at http://www.bundesnetzagentur.de/media/archive/3186.pdf</title>
<author>
<organization/>
</author>
<date day="9" month="September" year="2005"/>
</front>
</reference>
<reference anchor="Law2">
<front>
<title>70. Konferenz der Datenschutzbeauftragten des Bundes und der Länder:
Entschließung Telefonieren mit Internettechnologie (Voice over IP
– VoIP), available at
http://www.datenschutzzentrum.de/material/themen/press e/20051028-dsbk-voip.htm</title>
<author>
<organization/>
</author>
<date day="28" month="Oktober" year="2005"/>
</front>
</reference>
<reference anchor="Law3">
<front>
<title>Working Party 29 Opinion 2/2006 on privacy issues related to the provision of
email screening services, WP 118, available at
http://ec.europa.eu/justice_home/fsj/privacy/docs/wpdocs/2006/wp118_en.pdf</title>
<author>
<organization/>
</author>
<date day="21" month="February" year="2006"/>
</front>
</reference> &XEP-0161; </references>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="policies-at-host" title="Authorization Engine in SIP UA">
<t> 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.</t>
<t>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 <xref
target="I-D.wing-sipping-spam-score"/>. </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 13:58:10 |