<?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&#246;ller" initials="J." surname="M&#246;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&#228;nder:
                  Entschlie&#223;ung Telefonieren mit Internettechnologie (Voice over IP
                  &#8211; 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>
