<?xml version="1.0"?>

<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2617 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml'>
<!ENTITY rfc3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc3265 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml'>
<!ENTITY rfc5039 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5039.xml'>
]>

<rfc ipr="full3978" category="std">
   <front>
      <title abbrev="Spam feedback for SIP">Spam feedback for SIP</title>
      
      <author initials="S." surname="Niccolini" fullname="Saverio Niccolini">
         <organization abbrev="NEC">NEC Laboratories Europe, NEC Europe Ltd.</organization>
         <address>
            <postal>
               <street>Kurfuersten-Anlage 36</street>
               <city>Heidelberg</city>
               <code>69115</code>
               <country>Germany</country>
            </postal>
            <phone>+49 (0) 6221 4342 118</phone>
            <email>saverio.niccolini@nw.neclab.eu</email>
            <uri>http://www.nw.neclab.eu</uri>
         </address>
      </author>

      <author initials="K." surname="Fischer" fullname="Kai Fischer">
         <organization abbrev="Siemens Enterprise Communications">Siemens Enterprise Communications GmbH & Co. KG</organization>
         <address>
            <postal>
               <street>Schertlinstr. 8</street>
               <city>Munich</city>
               <code>81379</code>
               <country>Germany</country>
            </postal>
            <phone>+49 (0) 89 722-37360</phone>
            <email>kai.fischer@siemens.com</email>
         </address>
      </author>
      
      <author fullname="Dan Wing" initials="D." surname="Wing">
        <organization>Cisco System, Inc.</organization>
        <address>
          <postal>
            <street>170 West Tasman Drive</street>
            <city>San Jose</city>
            <region>CA</region>
            <code>95134</code>
            <country>US</country>
          </postal>
          <email>dwing@cisco.com</email>
        </address>
      </author>
    
      <author initials="M." surname="Stiemerling" fullname="Martin Stiemerling">
         <organization abbrev="NEC">NEC Laboratories Europe, NEC Europe Ltd.</organization>
         <address>
            <postal>
               <street>Kurfuersten-Anlage 36</street>
               <city>Heidelberg</city>
               <code>69115</code>
               <country>Germany</country>
            </postal>
            <phone>+49 (0) 6221 4342 113</phone>
            <email>stiemerling@nw.neclab.eu</email>
            <uri>http://www.nw.neclab.eu</uri>
         </address>
      </author>

    <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Otto-Hahn-Ring 6</street>
          <city>Munich, Bavaria</city>
          <code>81739</code>
          <country>Germany</country>
        </postal>
        <email>Hannes.Tschofenig@nsn.com</email>
      </address>
    </author>

      <date month="February" year="2008"/>

      <area>Real-time Applications and Infrastructure</area>

      <workgroup>SIPPING Working Group</workgroup>
      <keyword>RFC</keyword>
      <keyword>Request for Comments</keyword>
      <keyword>I-D</keyword>
      <keyword>Internet-Draft</keyword>
      <keyword>SPIT</keyword>
      <keyword>SPam over Internet Telephony</keyword>
      <keyword>Feedback</keyword>

  	  <abstract>
         <t>
         This document gives on overview of possible mechanisms for SIP UAs to
         feedback spam information to the system (e.g. other SIP entities like
         upstream SIP proxies) thus they can use this information for handling
         subsequent calls (e.g. blacklist the caller, input this info to
         reputation systems, compute spam-specific caller statistics, etc.).
         </t>
      </abstract>
   </front>

   <middle>

      <section anchor="intro" title="Introduction">
         <t>For the purpose of SPIT prevention it would be nice to have a
         mechanism for users to report the fact that they received a spam call.
         For example, a button on the user interface of the client (either
         hardware or software) might empower callees to inform the system
         that a particular caller initiated a spam call to the callee (see
         also <xref target="RFC5039"/>).
         This information can be used in many ways depending on the
         configuration of the system and on user preferences (e.g. can be
         used to add the caller to the callee's personal black list, to
         inform a reputation system, to apply particular call handling to
         subsequent calls of such caller either making him solving a CAPTCHA
         before initiating new calls or making him solving a computational
         puzzle, etc.).
         The discussion on how to use the user feedback depending on the
         configuration of the system and on user preferences is out of the
         scope of this document.
         The scope of this document is to highlight possible alternatives
         how this feedback should be delivered to the system in order to
         make a decision how this feedback should be implemented.
         </t>
      </section>
      
      <section anchor="spam-feedback-ua" title="SIP Spam Feedback: sending
      operations">
        <t>A UA generates a spam feedback after the user press the "spam"
        button.
        The spam feedback SHOULD carry information about the call and its
        originator. Information that are redundant SHOULD be avoided.
        Such information are taken into account by the system in order to
        apply different policies depending on system configuration
        or on user preferences.
         
        Examples of information about the call are, but not limited to, listed
        here:
          <list style="symbols">
            <t>
            caller SIP URI;
            </t>
            <t>
            callee SIP URI;
            </t>
            <t>
            Call-ID;
            </t>
            <t>
            call start time (exact definition of call start time has to be included);
            </t>
            <t>
            call end time (exact definition of call start time has to be included);
            </t>
            <t>
            caller signaling contact address (IP address and port);
            </t>
            <t>
            callee signaling contact address (IP address and port);
            </t>
            <t>
            caller media address (IP address and port);
            </t>
            <t>
            callee media address (IP address and port);
            </t>
            <t>
            Path Information (Via, Route, Record-Route, Path headers);
            </t>
            <t>
            Alert-Info (if present in the request);
            </t>
            <t>
            etc. (to be defined).
            </t>
          </list>
        </t>
        
        <section anchor="spam-feedback-alternatives" title="Alternatives for
        sending spam feedbacks">
          <t>
          The authors envision two alternatives to implement the spam feedback:
            <list style="symbols">
              <t>
              using an additional header is inserted the BYE message, which is already
              generated by the UA;
              </t>
              <t>
              using an event package for spam feedbacks (to be defined), the system (e.g.
              a SIP proxy) SUSCRIBE to UA spam feedback service, the UA NOTIFY the
              system each time the "spam" button is pressed by the user.
              </t>
            </list>
          Both methods have pros and cons. Discussion about which is the best alternative
          for the purpose of sending spam feedbacks should take place in the SIPPING WG.
          </t>
          <section anchor="byeheader-abnf" title="ABNF">
            <t>
            ABNF using the ABNF syntax of <xref target="RFC3261"/>. Such ABNF can be used
            to define the additional header of the BYE message or the body of the NOTIFY
            message.
              <figure>
                <artwork><![CDATA[
Spam              = "Spam" HCOLON spam-value
                    ; examples:
                    ;  Spam: 1; To: Bob <sip:bob@biloxi.com>;
                    ;  From: Alice <sip:alice@atlanta.com>;
                    ;   tag=1928301774;
                    ;  Call-ID: a84b4c76e66710@pc33.atlanta.com
                    ;  ...
spam-value        = 1 *(SEMI spam-params)
spam-params       = To / From / Call-ID /
                    Call-start-val / Call-end-val /
                    Caller-sign-val / Callee-sign-val /
                    Caller-media-val / Callee-media-val /
                    Via / Route / Record-Route /
                    Alert-Info / ... 
Call-start-val    = "Call-start" EQUAL date
Call-end-val      = "Call-end" EQUAL date
Caller-sign-val   = "Caller-sign" EQUAL hostport
Callee-sign-val   = "Callee-sign" EQUAL hostport
Caller-media-val  = "Caller-media" EQUAL hostport
Callee-media-val  = "Callee-media" EQUAL hostport
      
               Figure 1: ABNF]]>                              
                </artwork>
              </figure>

            </t>
          </section>
          <section anchor="event-package-usage" title="Event package usage">
	    <section anchor="event-overview" title="Overview">
            <t>
            <xref target="RFC3265"/> specifies an extension to SIP providing an extensible
            framework by which SIP nodes can request notification from remote nodes indicating
            that certain events have been occurred. This framework can be applied to realize an
            notification mechanism of spam feedback from a SIP UA towards a server like a SIP
            proxy. A server interested in feedback if a call is considered as spit / spam by the
            user, subscribes to the new defined event package 'spam-feedback' at the SIP UA. After
            the user has pressed the "spam" button, the SIP UA notifies the server about the spam
            call. The NOTIFY message includes also some information to correlate the feedback
            with a specific call and to provide additional information.
            <xref target="fig-event-call-flow"></xref> depicts the general call flow, which is
            explained in the following sections. Call signaling specific messages like INVITE, 18x
            or 200 responses are omitted from the figure for simplicity.
            </t>
            <figure anchor="fig-event-call-flow" title="Overview call flow spam feedback event mechanism">
              <artwork><![CDATA[
                                           SIP proxy /
           SIP UA                         SPAM server
             |                                |
             |   SUBSCRIBE ('spam-feedback')  |
             |<-------------------------------|
             |                                |
             |             200                |
             |------------------------------->|
             |                                |
             |    NOTIFY ('spam-feedback')    |
             |------------------------------->|
             |                                |
             |             200                |
             |<-------------------------------|
 spam button |                                |
   pressed   |                                |
     ------->|                                |
             |    NOTIFY ('spam-feedback')    |
             |------------------------------->|
             |                                |
             |             200                |
             |<-------------------------------|
             |                                |]]>
              </artwork>
            </figure>
            </section>
	    <section anchor="subscribe-behavior" title="Subscribe behavior">
            <t>
            A SPAM / SIP server interested in spam feedback from a SIP UA sends a SUBSCRIBE
            request to the dedicated SIP UA. The request contains a Event header indicating that
            the 'spam-feedback' event package shall be subscribed. The request may contain also an
            Expires header indicating the duration of the subscription. If no Expires header is
            present, the subscription has an unlimited duration. At any time before a subscription
            expires, the subscriber may refresh the timer on such a subscription by sending
            another SUBSCRIBE request on the same dialog as the existing subscription.
            </t>
            <t>
            On receipt of a SUBSCRIBE request the SIP UA should check that the event package
            specified in the Event header is understood. If not, a "489 Bad Event" response should
            be returned. The SIP UA should check if the requesting server is authorized to
            subscribe to the event package. Prior to authorization the SIP UA needs to
            authenticate the server. One way achieving this is to use a TLS connection to the
            spam / SIP server, which might be already established to protect SIP registration and
            call signaling. Usually, the server is authenticated during TLS handshake, e.g. by a
            X.509 certificate, whereas the SIP UA is authenticated by SIP digest (<xref
            target="RFC3261"/> and <xref target="RFC2617"/>) on top of TLS. TLS provides also
            additional security properties, which addresses the security considerations of
            <xref target="RFC3265"/> (please refer to <xref target="security" pageno="false"
            format="default"></xref>).
            </t>
            <t>
            Based on the configured policy the SIP UA accepts the SUBSCRIBE request by sending a
            200 response, temporarily accepts the request with a 202 response or declines it by
            sending a non 200 class response like "403 Forbidden" or "603 Declined".
            </t>
            </section>
	    <section anchor="notify-behavior" title="Notify behavior">
            <t>
            After the SIP UA has accepted the subscription, a NOTIFY message is sent directly after
            the 200 response to indicate the initial state. The NOTIFIY Event header contains the
            'spam-feedback' package name. The body should be empty, because no spam feedback needs
            to be notified initially. The NOTIFY message is sent over the already established TLS
            connection.
            </t>
            <t>
            When a user receives a call considered as spam, he presses the "spam" button, which
            initiates a new NOTIFY message from the UA to the server. In contrast to the
            initial NOTIFY message, the body contains information about the call and its
            originator. Such information are taken into account by the spam system in order to
            apply different policies depending on system configuration or on user preferences.
            Refer to <xref target="spam-feedback-ua" pageno="false" format="default"></xref> for a
            list of carried information.
            </t>
            <t>
            [[Note: The concrete specification of the 'spam-feedback' event package will be added
            in a future version.]]
            </t>
            </section>
          </section>
        </section>
      </section>
      
      <section anchor="spam-feedback-proxy" title="SIP Spam Feedback: system operations">
         <t>
         The system (e.g. a SIP proxy) that receives a notification of a certain call being
         spam should apply the policies defined in the system configuration and in the user
         preferences in order to handle subsequent calls coming from that caller.
         Examples of behavior include:
           <list style="symbols">
             <t>
             insert the caller in the callee's personal blacklist;
             </t>
             <t>
             input the feedback to a reputation system computing the reputation of the
             callers;
             </t>
             <t>
             configure the system to apply particular actions on subsequent calls initiated
             by such a caller (e.g. route to voicemail, challenge with a CAPTCHA, challenge
             with a computational puzzle, etc.)
             </t>
           </list>
         </t>
      </section>
      
      <section anchor="pros-cons" title="Advantages and disadvantages of alternatives">
        <t>We provide here a list of advantages and disadvantages in order to stimulate discussion
        on which technique should be used to send feedback.</t>
        <t>Advantages for using BYE are:
          <list style="symbols">
            <t>the mechanism can piggyback on a message that is already present and that the UA is
            sending anyway;</t>
            <t>it gives users a positive feeling/knowledge (if realized using a special button) that
            there is a special entity in the network that takes care of spam information (other than
            the proxy only) and (theoretically) will do something useful with it.</t>
          </list>
        </t>
        <t>Disadvantages for using BYE are:
          <list style="symbols">
            <t>the mechanisms has to be piggybacked on the BYE; this means the user has to decide
            if the call is spam at the same time the user terminates the call. This could be difficult
            with some user interfaces;</t>
            <t>the feedback information can in principle be routed upstream to a SIP proxy that can
            make use of it (if the sender proxy is the one controlled by the spammer this would mean
            giving him information on how the call was evaluated). Thus it is necessary to strip
            feedback information when the BYE leaves the caller's administrative domain (this puts
            additional load on the proxy). Failure to strip that information will allow the caller
            to realize if their call was marked as spam by the called party (privacy and security risk).</t>
          </list>
        </t>
        <t>Advantages for using NOTIFY are:
          <list style="symbols">
            <t>feedback information is sent only to SIP proxy or other special devices that are the
            intended recipients of such a message and that can make use of it;</t>
            <t>it can be delivered after the BYE (e.g. using a special dialing sequence;</t>
            <t>there is no need to require header stripping at the network administrative boundary;</t>
            <t>it is easier (with respect ot the usage of BYE) to authorize the mechanisms;</t>
            <t>it gives users a positive feeling/knowledge that there is a special entity in the network
            that takes care of spam information (other than the proxy only) and (theoretically) will do
            something useful with it</t>
          </list>
        </t>
        <t>Disadvantages for using NOTIFY are:
          <list style="symbols">
            <t>it requires an additional message;</t>
            <t>it requires additional infrastructural devices to be deployed (even if their introduction
            would not be too difficult since they are orthogonal to the signalling path).</t>
          </list>
        </t>
        <t>From a first analysis the usage of NOTIFY seems to be preferred but it is up to discussion
        in the community to reach consensus on this topic.</t>             
      </section>
        
      <section anchor="spam-additional" title="Additional considerations of feedback operations">
         <t>
         This document does not address important considerations on how and if the system (e.g. the SIP
         proxy serving the UA that received the spam call) should pass the information of a certain
         call being spam to other upstream proxies (e.g. to the SIP proxy in the originating domain).
         Such considerations are out of the scope of this document.
         The authors envision that such discussion should take place in another draft and investigate
         if additional headers or error messages should be defined to report upstream proxies about
         a call being considered spam by a certain domain or not. Also passing spam scoring information
         to upstream proxies is a possibility that should be considered in such draft and the appropriate
         security considerations shold be applied. 
         </t>
      </section>
      
      <section anchor="security" title="Security Considerations">
         <t>
         Some session requests may be spam for some users but not for others,
         it should be clear that the feedback is not providing a general
         security assessment of the call being spam or of the caller being abusive,
         but a personal one.
         The system should process spam feedbacks preserving normal operations
         for all users without letting some "mafia" users exploiting this
         mechanism to create DoS attacks denying users to call. The feedback
         message should be therefore challenged and authentication mechanisms
         should be applied. Also if the spam feedback is used to blacklist
         caller or entire domains, it should be used very carefully.
         </t>
         <t>
         The security considerations described in <xref target="RFC3265"/> are inherited and need
         also be considered by applying the general notification framework  for spam feedback.
         Most of the security threats are directly addressed by an authenticated TLS
         connection between the notifier and the subscriber.
         </t>
         <t>
         [[Note: Additional text regarding each threat of RFC 3265 is added in a later version
         ]]
         </t>
      </section>

      <!--<section anchor="contrib" title="Contributors">
         <t>Hannes Tschofenig, Nokia Siemens Networks</t>
         <t>Email: hannes.tschofenig@nsn.com</t>
      </section>-->

      <section anchor="iana" title="IANA Considerations">
         <t>
         [[This section will be completed in a later version of this document.]]

         </t>
      </section>
   
   </middle>

   <back>
   
      <references title='Normative References'>
	    &rfc3261;
	    &rfc3265;
	  </references>
	  
	  <references title='Informative References'>
	    &rfc2617;	    
	    &rfc5039;
      </references>

	</back>
</rfc>
