[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                             K. Ono
Internet-Draft                                            H. Schulzrinne
Intended status: Informational                       Columbia University
Expires: April 15, 2010                                 October 12, 2009


   Using Cross-Media Relations to Reduce False Positives during SPIT
                               Filtering
                 draft-ono-cross-media-relations-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 15, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Some legitimate calls are from persons or organizations connecting
   the callee with weak social ties, such as a restaurant the callee



Ono & Schulzrinne        Expires April 15, 2010                 [Page 1]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


   booked a table on-line.  These legitimate calls are often mistakenly
   labeled as unsolicited calls at a filtering system which uses the
   contact list of the callee.  To reduce these false positives during
   SPIT filtering, we propose two approaches to label incoming calls
   using cross-media relations from earlier communications.  One
   approach is that a potential caller offers the callee his contact
   address(es) which might be used in future calls.  Another is that a
   callee provides a potential caller with weakly secret information.
   In order to be identified as someone the callee contacted through
   other means previously, the caller should convey the information in
   future calls.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Using Cross-Media Relations  . . . . . . . . . . . . . . . . .  4
   4.  Mechanism I: Contact Addresses of Potential Callers  . . . . .  6
   5.  Mechanism II: Weakly Secret Information  . . . . . . . . . . .  6
   6.  Enhanced Filtering . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Consideration . . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
























Ono & Schulzrinne        Expires April 15, 2010                 [Page 2]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


1.  Introduction

   Unsolicited calls usually originate from persons or organizations,
   whom the callee does not know their contact addresses nor met before.
   Since an IP-based infrastructure is more vulnerable to unsolicited
   calls or SPIT (SPam over Internet Telephony) calls, as described in
   [RFC5039], people have recently been experiencing more SPIT calls.

   Most legitimate calls, by contrast, have caller identifiers (IDs)
   that the callee has seen before.  Some legitimate calls, however,
   have unknown caller IDs.  Examples of these legitimate calls include
   confirmations of appointments, reservations, or deliveries, and
   recorded notifications of flight delays or school closing on a snowy
   day.  These legitimate calls are prone to false positives during SPIT
   filtering.  This is because their caller IDs are not found on the
   callee's white list even if the callers have had prior contact with
   the callee through transactions over the web or email exchanges
   [have-i-met-u-before].

   This is a natural consequence of a conventional white list, which
   usually contains the same addresses with his contact list or address
   book.  The contact list contains known or used contact addresses of
   persons or organizations with strong ties in his or her social
   network, such as family members, friends, and colleagues.  The
   contact list, however, rarely includes the addresses of those with
   weak social ties [weak-ties], such as an operator at the customer
   center of an on-line shopping site, or friends of a friend in an SNS
   (Social Network Service) over the web.

   Using a white list to label incoming calls requires caller ID
   authentication.  For a VoIP (Voice over IP) call using the SIP
   (Session Initiation Protocol) [RFC3261], the SIP Identity header
   [RFC4474] enables a callee to authenticate the caller ID.  Some
   legitimate calls, however, are sent with "unavailable" caller IDs.
   These calls without any authenticated caller IDs limit the
   effectiveness of labeling incoming calls based on the caller ID.

   In summary, conventional whitelisting can hardly label the following
   types of calls:
   D1:  Calls from persons or organizations connecting the callee with
        weak social ties
   D2:  Calls from those connecting with strong social ties, but using
        new, alternative, or unknown caller IDs, e.g., from a visited
        place like a hotel







Ono & Schulzrinne        Expires April 15, 2010                 [Page 3]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


   D3:  Calls with unauthenticated caller IDs, e.g., through an
        unauthenticated domain or using the caller ID in tel-URI
        [RFC3966]
   D4:  Calls with blocked caller IDs

   To cope with these difficulties of conventional whitelisting, we
   propose to expand filter conditions with two mechanisms; both use
   cross-media relations from earlier communications.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document defines the following term:

   Cross-media relations:  The information suggesting the existence of a
         prior contact.  When the information is offered by a potential
         caller, it can be his contact address, which is in plain text
         or hash coded.  When the information is offered by the callee,
         it needs to be a weak secret in order to be used for labeling
         incoming call without authentication.  The weakly secret
         information is the value of the Message-ID [RFC5322] of an
         outgoing email from the callee or random components contained
         in the callee's customized contact address.


3.  Using Cross-Media Relations

   Figure 1 depicts an overview of our first mechanism.  In order to
   cope with the difficulties of D1 and D2 described above, a potential
   caller offers the callee his contact addresses which he might use in
   future calls.  If the callee agrees, these contact addresses are
   added to his white list.  Figure 2 depicts an overview of our second
   mechanism.  In order to cope with the difficulties of D3 and D4
   mainly, a callee provides a potential caller with weakly secret
   information.  The caller should use it in future calls in order to be
   identified as someone the callee has had prior contact through other
   means.  The second mechanism allows to label incoming calls using the
   weakly secret information, instead of caller IDs.









Ono & Schulzrinne        Expires April 15, 2010                 [Page 4]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


   [Potential Caller]               [Callee]

      | HTTP Response                 |          _____________
      |------------------------------>| rcv.&   /             \
      |                               | storep |\_____________/|
      |                               |------> | White list:   |
      or                                       |               |
      | Responded Email               |        | Contact addrs.|
      |------------------------------>| rcv.&  | in plain text |
      |                               | store  | or hash coded |
      |                               |------> |               |
     ~~~                             ~~~       |               |
     ~~~                             ~~~       |               |
      | SIP INVITE Request            |query to|               |
      | From:                         |label   |               |
      |------------------------------>|------>  \_____________/
      |                               |       Filter conditions

                   Figure 1: An Overview of Mechanism I


                         [Callee]                  [Potential Caller]
     ______________            |                               |
    /              \  generate,|                               |
   |\______________/| send,    | HTTP Request                  |
   | Weak sercrets: | & store  |------------------------------>|
   |                |<---------|                               |
   | Random comp. in|          or
   | customized own | generate,|                               |
   | contact addrs. | send,    | Outgoing Email                |
   | & Message-IDs  | & store  |------------------------------>|
   |                |<---------|                               |
   |                |         ~~~                             ~~~
   |                |         ~~~                             ~~~
   |                |          | SIP INITE Request             |
   |                |          | To:                           |
   |                |          | or                            |
   |                | query to | New-References:               |
   |                | label    |<------------------------------|
    \______________/ <---------|                               |
   Filter conditions

                   Figure 2: An Overview of Mechanism II








Ono & Schulzrinne        Expires April 15, 2010                 [Page 5]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


4.  Mechanism I: Contact Addresses of Potential Callers

   Our first mechanism enables potential callers to offer their contact
   addresses which they might use in future calls more easily and more
   widely.

   To make it more easily in a web transaction, we propose that an HTTP
   response from a potential caller conveys his or her contact addresses
   in an HTML META tag, HTTP-EQUIV [W3C.REC-html401-19991224] or a new
   HTTP header, Correspondence-URIs [I-D.shacham-http-corr-uris].  In an
   email exchange, the contact addresses can be contained in a vCard
   [RFC2426] attached to an email message sent from a potential caller.
   After the callee receives the contact addresses of a potential
   caller, the callee adds them to his or her white list.  To prevent
   misuse, the callee should be prompted for confirmation before
   updating his or her white list.

   To make it more widely, we propose to convey hash-coded contact
   addresses of potential callers.  Hash-coded contact addresses are
   suitable if potential callers prefer concealing their routable
   address for privacy reasons.  For example, in an SNS where
   subscribers prefer not to publish their routable contact addresses,
   subscribers should be allowed to publish their hashed contact address
   for the limited purpose of filtering calls.

   This first mechanism is useful in a case where the contact addresses
   of potential callers have been determined and the number is small.
   In other cases, our second mechanism should be used.


5.  Mechanism II: Weakly Secret Information

   Our second mechanism allows a callee to provide potential callers
   with weakly secret information as cross-media relations.  Potential
   callers should use this information in future calls to be identified
   as someone with whom the callee has had prior contact through other
   means.

   This mechanism is useful in the following cases.  One is where the
   previous contact was one-to-many correspondence between the callee
   and potential callers.  For example, when joining an association, the
   callee is unwilling to receive all the contact addresses of potential
   callers in the association.  Another case is where potential callers
   might use a different or no authenticated caller ID, due to their
   situation such as traveling, or due to the type of communication
   medium or service, such as two-stage dialing for international calls.

   The information about cross-media relations depends on the



Ono & Schulzrinne        Expires April 15, 2010                 [Page 6]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


   communication medium of a previous contact.  A customized contact
   address containing a random component or a token can be used when a
   callee fills out contact information on a web site, or in a vCard
   attached to an email message.  The random component or token can be
   automatically generated in correspondence to the URL (Uniform
   Resource Locator) [RFC3986], or manually specified.  In the examples
   in Figure 3, a token, "adgs24oF", in the SIP-URI is set between the
   user name and the domain name preceded with "+".  This is the same
   way as the email addressing practice called subaddressing [RFC5233].
   For tel-URI, a token, "0012", follows the E.164 number like an
   extension.  To convey this information in a later call, the caller
   just needs to set the destination address to the customized contact
   address, as the INVITE request shown in Figure 3.

  Web client                                                 Web server
  at callee                                         at potential caller
  |                                                                   |
  | POST /join HTTP/1.1                                               |
  | HOST: ffp.airline.com                                             |
  | Content-Length: 128                                               |
  | Conetnt-Type: application/x-www-form-urlencoded                   |
  |                                                                   |
  | phone1=sip:userA+adgs24oF@example.com&phone2=tel:+121291711110012 |
  | ...                                                               |
  |------------------------------------------------------------------>|
  | HTTP/1.1 200 OK                                                   |
  |<------------------------------------------------------------------|
  |                                                                   |
 ~~~                                                                 ~~~
 ~~~                                                                 ~~~
  |                                                                   |
  | INVITE sip:username+adgs20oF@exmale.com SIP/2.0                   |
  | To: sip:username+adgs20oF@exmale.com                              |
  |<------------------------------------------------------------------|
  |                                                                   |
 Note: To show related headers only, many mandatory headers are omitted.

           Figure 3: Using Weak-Eecret in HTTP and SIP messages













Ono & Schulzrinne        Expires April 15, 2010                 [Page 7]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


  Email client                                             Email client
  at callee                                         at potential caller
  |                                                                   |
  | (Message)                                                         |
  |<------------------------------------------------------------------|
  | Message                                                           |
  | Message-ID:<56626454-8D6F-49FF-BFA0-1FF6A63E71EA@example.com>     |
  |------------------------------------------------------------------>|
  |                                                                   |
 ~~~                                                                 ~~~
 ~~~                                                                 ~~~
  |                                                                   |
  | INVITE sip:username@exmale.com SIP/2.0                            |
  | New-References:<56626454-8D6F-49FF-BFA0-1FF6A63E71EA@example.com>;|
  | type="email"                                                      |
  |<------------------------------------------------------------------|
  |                                                                   |
 Note: To show related headers only, many mandatory headers are omitted.

           Figure 4: Using Weak Secret in Email and SIP messages

   Specifically in an email exchange, as shown in Figure 4, the message
   identifier of an email from the callee can be used.  A potential
   caller first sends a message to the callee requesting a real-time
   communication.  This message is optional.  If the callee accepts the
   request, he will respond to it by email optionally containing his
   contact address.  As a result, the message identifier of the response
   email, which is set in the Message-ID header, can be used as weakly
   secret information to prove the acceptance from the callee.  Thus,
   the message identifiers of outbound emails or the call identifers of
   SIP calls can be included by the potential caller in a later call,
   even if he uses a different caller ID or type of communication
   medium.  To convey the message identifier in a SIP call, the caller
   should set a SIP header extension [I-D.ono-earlier-comm-references]
   to its value.  In the example message in Figure 4, a new SIP header
   extension under discussion, New-References is used.


6.  Enhanced Filtering

   Our two mechanisms enhance a filtering process using caller IDs in
   the following ways.  For our first mechanism, it extends white list
   by contain contact addresses in hash format.

      Furthermore, sharing a white list for people within an
      organization increases the effectiveness of the white list.  A
      remote server maintaining common white lists is also effective, if
      it can be queried whether or not the caller ID is found on the



Ono & Schulzrinne        Expires April 15, 2010                 [Page 8]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


      list and respond with binary, e.g., query about membership.

   For our second mechanism, it adds conditionals using weakly secret
   information after the conditionals checking the authenticated caller
   ID of an incoming call on a black list nor on a white list.  For
   incoming calls of which caller ID is not found on the white list, the
   expanded filtering process tests on two new conditionals.  The first
   one is whether it contains a valid Message-ID value in the new
   references header under discussion [I-D.ono-earlier-comm-references].
   The second is whether it contains a valid subaddress of the
   destination address, i.e., in the To header.  That is, if the test
   succeeds in either condition of the message identifier or subaddress,
   the call request will be accepted.

   Therefore, by enhancing existing filter conditions, our proposed
   mechanisms enable a callee to label incoming calls, not only from
   persons or organizations with weak ties, but also from callers who
   change their caller IDs.  As a result, they are expected to reduce
   false positives that occur during filtering.


7.  Security Consideration

   TBD


8.  IANA Consideration

   This document requires no IANA Consideration.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

9.2.  Informative References

   [I-D.ono-earlier-comm-references]
              Ono, K. and H. Schulzrinne, "Referencing Earlier
              Communications in SIP Requests",



Ono & Schulzrinne        Expires April 15, 2010                 [Page 9]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


              draft-ono-earlier-comm-references-00 (work in progress),
              October 2009.

   [I-D.shacham-http-corr-uris]
              Shacham, R. and H. Schulzrinne, "HTTP Header for Future
              Correspondence Addresses", draft-shacham-http-corr-uris-00
              (work in progress), May 2007.

   [RFC2426]  Dawson, F. and T. Howes, "vCard MIME Directory Profile",
              RFC 2426, September 1998.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, December 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [RFC5039]  Rosenberg, J. and C. Jennings, "The Session Initiation
              Protocol (SIP) and Spam", RFC 5039, January 2008.

   [RFC5233]  Murchison, K., "Sieve Email Filtering: Subaddress
              Extension", RFC 5233, January 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [W3C.REC-html401-19991224]
              Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01
              Specification", World Wide Web Consortium
              Recommendation REC-html401-19991224, December 1999,
              <http://www.w3.org/TR/1999/REC-html401-19991224>.

   [have-i-met-u-before]
              Ono, K. and H. Schulzrinne, "Have I Met You Before? Using
              Cross-Media Relations to Reduce SPIT", IPTCOMM 09,
              July 2009.

   [weak-ties]
              Granovetter, M., "The Strength of Weak Ties", Amer.J.of
              Sociology 78:1360-80, May 1973.






Ono & Schulzrinne        Expires April 15, 2010                [Page 10]

Internet-Draft  Using Cross-Media Relations against SPIT    October 2009


Authors' Addresses

   Kumiko Ono
   Columbia University
   Department of Computer Science
   New York, NY  10027
   USA

   Email: kumiko@cs.columbia.edu


   Henning Schulzrin ne
   Columbia University
   Department of Computer Science
   New York, NY  10027
   USA

   Email: hgs@cs.columbia.edu

































Ono & Schulzrinne        Expires April 15, 2010                [Page 11]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/