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.

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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Table of Contents

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

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] (Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” January 2008.)). 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] (Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” January 2008.)) 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] (Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” January 2008.)) suggesting strong Identity (e.g. [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.)) 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 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.

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 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and ENUM [RFC3761] (Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” April 2004.)

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] (Tschofenig, H., Schulzrinne, H., Wing, D., Rosenberg, J., and D. Schwartz, “A Framework to tackle Spam and Unwanted Communication for Internet Telephony,” November 2007.)

6.  Misrepresentation

This category deals with propagation of trusted identity across trust boundaries and is covered in [RFC5039] (Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” January 2008.).

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

11.2. Informational References

Author's Address

Full Copyright Statement

Copyright © 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.