One document matched: 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-00

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 Prob 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.  Lack Of Policy  . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Misrepresentation . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Underprivileged Attacker  . . . . . . . . . . . . . . . . . . . 5
   7.  Regulatory  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     11.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
     11.2.  Informational References . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8






























Schwartz                 Expires August 21, 2008                [Page 2]

Internet-Draft            RUCUS Prob 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 Prob 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
                           * SIP message trace routing
                           * SIP Proxy capability mapping

       Lack of policy -    This category deals with the non malicious
                           2AM or Japanese (to an English speaker)
                           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 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

   Each of these categories MUST be addressed if we are to truly tackle
   this issue.


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 quite finite.  As a result, it is quite trivial to gather or mine
   this information for use (individually or 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 both using SIP
   [RFC3261] as well as ENUM [RFC3761]



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


   Similarly, gathering network information using SIP messaging is
   relatively simple as well.  Manipulation of the Max-Forwards header
   as well as clever usage of other SIP headers or messages can expose
   much about an internal SIP network.


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


5.  Misrepresentation

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


6.  Underprivileged Attacker

   This category reminds me of the slogan used in the 1992 US
   presidential elections:  "It's the economy stupid".  We sometimes get
   so caught up in what we do that we forget that its not always about
   attacking IP communications.  Very often the attack is just using the
   IP communication application as a trusted or privilaged application
   sitting on some server for gaining access to server.  This attack
   manifests itself in some of the more clever fuzzing attaks including
   things like SQL injections in fields such as "username" or "Call-ID".


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.







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


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.

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.










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


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 Prob 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]