One document matched: draft-schwartz-rucus-problem-statement-01.txt

Differences from draft-schwartz-rucus-problem-statement-00.txt

Network Working Group                                        D. Schwartz
Internet-Draft                                  XConnect Global Networks
Intended status:  Informational                        February 18, 2008
Expires:  August 21, 2008


                        RUCUS Problem Statement
               draft-schwartz-rucus-problem-statement-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   SIP is being used more an more today for everyday communication
   purposes.  With this widespread adoption comes the inevitability of
   abuse.  This document describes the problems that fit into the
   category of "unwanted Communication".

Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",



Schwartz                 Expires August 21, 2008                [Page 1]

Internet-Draft           RUCUS Problem statement           February 2008


   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Unwanted Communication  . . . . . . . . . . . . . . . . . . . . 3
   3.  Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  B-Side Attacks  . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Lack Of Policy  . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Misrepresentation . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Regulatory  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     11.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
     11.2.  Informational References . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8






























Schwartz                 Expires August 21, 2008                [Page 2]

Internet-Draft           RUCUS Problem statement           February 2008


1.  Introduction

   As worldwide communication infrastructure is shifting to IP the
   potential for disruption or abuse is increasing as well (see cost
   analysis brought down in [RFC5039]).  As such it is important to be
   able to assess the potential threat so that possible remedies can be
   sought.  It is important to stress, however, that this document and
   by extension this WG is not focusing ONLY on fraud or
   misrepresentation attacks such as those mentioned in [RFC5039]) but
   on all types of "unwanted" communications.

   Fortunately (or unfortunately) we have a large body of work already
   completed in other similar areas such as email and as such the
   guiding principles of this WG MUST be:

   What has been done right

   What has been done wrong

   What should have been done earlier


2.  Unwanted Communication

   So what constitutes Unwanted Communication?  Until now, most of the
   work that has been done in this area in the various IETF WGs has
   focused on the "misrepresentation" issue ([RFC5039]) suggesting
   strong Identity (e.g.  [RFC4474]) as the cornerstone of any solution.
   Lately, there has been a lot of discussion on the various lists
   trying to extend the identity protection (or better yet - give it
   some meaning) to e.164 numbers as well as sip URIs.

   Still, this is only one aspect of "Unwanted Communications" and
   focusing or solving only this issue (if at all possible) will clearly
   not eliminate SPAM.  As an example, one attack that is cropping up of
   late is a hybrid email VoIP attack which upgrades the age old
   phishing attack by replacing a compromised web server with a
   compromised PBX (or one set up just for this purpose) and includes an
   e.164 number in the email message that supposedly is sent by your
   bank instead of the traditional fake URL.  Since there is no "whois"
   equivalent for e.164 numbers there is no way today to combat this
   attack.  While not much can be done if the unsuspecting caller
   initiates the call from the PSTN, if the call is initiated using SIP,
   there may be some help we can provide.  But this help is contingent
   on us realizing that the problem scope is wider than we previously
   imagined.

   Following is an initial list of possible unwanted communication



Schwartz                 Expires August 21, 2008                [Page 3]

Internet-Draft           RUCUS Problem statement           February 2008


   categories:

    Data Mining -       This category includes messaging whose sole
                        purpose is to mine for information.
                        Included in this category are things like Number
                        Harvesting via SIP or ENUM

    B-side attacks -    This category is rooted in the lack of a
                        "whois" equivalent for e.164 numbers and
                        includs attacks where the originating
                        party has no information attesting to the
                        credibility or authenticity of the signaled
                        party

    Lack of policy -    This category deals with the non-malicious
                        middle-of-the-night or foreign-language
                        communication.  Strong identity will not
                        prevent this sort of communication.

    Misrepresentation - The one we all like to hate. In this
                        category are included:

                        * Telemarketing
                        * Fraudulent access (e.g. voice mail)

                        Any application where access is based
                        on the signaling party's phone number
                        falls into this category

    "underprivileged" - Malicious applications just trying to
                        gain a foothold on a remote computer fall
                        into this category. This class addresses
                        attacks that use IP communications as
                        a means rather than an end.

               Figure 1: Unwanted Communications Categories

   You will note in the list above I have included things like number
   mining even though the is not part of a "communication" process.  I
   did this since this is a prepatory attack for unwanted communcations
   I felt it should be dealt with in this context as well.


3.  Data Mining

   As opposed to the URI namespace which is infinite, the e.164
   namespace which is in use for the majority of SIP voice calls today
   is not large in computing terms.  As a result, it is quite trivial to



Schwartz                 Expires August 21, 2008                [Page 4]

Internet-Draft           RUCUS Problem statement           February 2008


   gather or mine this information for use (individually or for resale)
   in misrepresentation attacks.  Low volume SIP INVITE messages
   recording failures (e.g. 404 Not found) and successes (e.g. 183
   Session Progress) are highly effective and relatively hard to defend
   against.  These kind of attacks have been seen in the field using
   both SIP [RFC3261] and ENUM [RFC3761]


4.  B-Side Attacks

   It is important to understand that SPAM is not static but rather is
   all about economics and adapts accoridignly.  While the return on
   investment for the misrepresentation attacks does not yet justify
   widespread use, the ROI for B-side attacks is clearer and is being
   seen in the field today.  Basically, the spammers go with what works
   - and phishing works better than telemarketing.  When you do the math
   you see that a very small hit percentage is needed for a highly
   successful phishing campaign to materialize.  Continual improvement
   in protection against this sort of attack is forcing the phishers to
   adapt as well (e.g. inline GIFs instead of embedded URLs that can be
   verified).

   Against this backdrop it is to be expected that the next step in the
   evolution of phishing is to include an instruction to dial a DID or
   virtual phone number that the caller has no way to verify - where
   this will lead to nefarius activities.  In a sense it is the "B-side"
   that is threatening the "A-side" and hence the name of this category.
   It is important to realize that this attack is not unique to IP
   communications.  The compromised "B-side" could belong a PSTN
   compromised switch.  The thing is that (a) its harder to comparmise a
   PSTN switch (b) who ever said that we have to limit ourselves to the
   protection available on the PSTN?


5.  Lack Of Policy

   Unwanted communication is subjective - not objective.  As such it is
   entirely possible for a legitimate call to be unwanted (even at the
   level of not having the phone ring and force me to answer) at its
   intended destination and it is completely reasonable to arm the
   receiving party with the ability to prevent this sort of occurance
   a-priori.  In order to combat this form of unwanted communication
   there is a need for policy exchange mechanisms as discussed in
   [I-D.tschofenig-sipping-framework-spit-reduction]







Schwartz                 Expires August 21, 2008                [Page 5]

Internet-Draft           RUCUS Problem statement           February 2008


6.  Misrepresentation

   This category deals with propagation of trusted identity across trust
   boundaries and is covered in [RFC5039].


7.  Regulatory

   It wouldn't be right to finish a document describing the RUCUS
   problem statement without raising the specter of regulatory
   involvement.  An incident which occurred in 1997 in which House
   Speaker Newt Gingrich's cellular telephone conversation was illegally
   intercepted, taped and published by the media prompted calls in
   Congress for stronger anti-eavesdropping legislation.  One can only
   imagine what unwanted communications to one of these legislatures
   will cause to IP communications.


8.  Security Considerations

   [[This section will be completed in a later version of this
   document.]]


9.  Acknowledgements

   Thanks to Adam O'Donell for alerting me to the VoIP aspects of email
   phishing.


10.  IANA Considerations

   None.  This document is informational


11.  References

11.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.





Schwartz                 Expires August 21, 2008                [Page 6]

Internet-Draft           RUCUS Problem statement           February 2008


11.2.  Informational References

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

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

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.

   [I-D.tschofenig-sipping-framework-spit-reduction]
              Tschofenig, H., Schulzrinne, H., Wing, D., Rosenberg, J.,
              and D. Schwartz, "A Framework to tackle Spam and Unwanted
              Communication for Internet  Telephony",
              draft-tschofenig-sipping-framework-spit-reduction-02 (work
              in progress), November 2007.


Author's Address

   David Schwartz
   XConnect Global Networks
   Malcha Technology Park
   Building # 1
   Jerusalem  90961
   Israel

   Phone:  +972 52 347 4656
   Email:  dschwartz@xconnect.net
   URI:    www.kayote.com


















Schwartz                 Expires August 21, 2008                [Page 7]

Internet-Draft           RUCUS Problem statement           February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Schwartz                 Expires August 21, 2008                [Page 8]