In my previous blog entry I discussed some of the possibilities of misusing SIP for generating and sending SPAM calls. This time I will discuss some of the risks incurred by such calls from a financial point of view as well as the legal possibilities for pursuing spammers based on these financial losses.

Spam mails are annoying. We have to check the content and delete them – wasting some seconds. SPIT calls will most likely be even more annoying as we will be alerted by the phone ringing possibly late at night and will have to listen to at least some of the transmitted message before classifying the call as SPIT.

However, except for being annoying, SPIT and spam do not cause significant financial harm to us. Looking at spam from a more global view, the financial harm caused by spam is actually significant. Employees spend several minutes a day deleting useless mails, companies need to buy anti-spam products and the administrators need to acquire the knowledge for fighting spam and for properly operate anti-spam software. The ISPs need to carry spam mails and often save them on their mail servers until they are retrieved by their subscribers. This requires additional processing power and memory and disk space as well bandwidth resources. While it is difficult to accurately estimate the total cost of spam, various resources estimate the overall costs to be anywhere between $2 and $10 billion (Source: see http://www.messagelabs.co.uk/).

This aspect of financial harm can be used as the basis for legally pursuing the spammers.

Actions based upon so called unjust enrichment could be granted when the defendant saves costs or increases his income by making use of other people’s property without their consent. This is the basis upon which unsolicited faxes were prohibited. For email and VoIP, this argument is a bit more difficult to justify. In case where the recipient is using flat rate access then receiving spam does not incur any costs. If, however, the recipient pays for his Internet access per minute then receiving SPIT calls incurs some costs on him or her. In this case the unjust enrichment argument might still apply.

Not being the target of the unsolicited communication, the argument of unjust enrichment is not easily applicable by an ISP acting against a spammer.  In this case, Trespass to chattels has been alleged by service providers in some cases of spam. Trespass to chattels is committed when a person uses or intermeddles with another’s personal property without authorization. In the case of a service provider this could mean the excessive use of bandwidth, memory and processing resources needed for handling the large number of SPIT calls.

Another approach for a service provider to protect itself against spammers is to indicate in their terms of usage contracts with their subscribers that any form of spam is prohibited and that the subscribers need to abide to netiquette rules. While not being an explicit law or regulation it is well established that starting unsolicited calls is contrary to the customs in the Internet. Based on this, a service provider can have the legal basis for terminating the subscription of a spammer.

So what does all of this tell us? There is some legal basis for a service provider to pursue a spammer. However, this basis is rather weak and could be interpreted differently by courts in different countries. Therefore, often raised suggestions that service providers are responsible for protecting their subscribers from spam and SPIT is not such a simple thing as some think. This gets even more difficult if we consider the various aspects of privacy that I will touch upon in the next blog.

By the way, if you are interested in more details about SPIT and security in relation to SIP in general, then I am happy to announce that our book titled “SIP Security” was just released last week. Check out http://www.sipsecurity.org/ for more information on the book.

This is the second in a series of blog postings on the topic of “identity management” in SIP-based networks. The first posting was on Tuesday, March 10th, 2009. Click HERE to access PART 1.

We need identity for VoIP

I believe that a reasonable notion of identity can largely mitigate such horror scenarios. It would be very hard to eliminate anonymous undesirable communication. How could you blacklist “joedoe195″ if the user behind the name would choose to be “joedoe591″ in the next second. How could you deny incoming calls from “anonymous” if the majority of your callers would suppress caller ID, like in the stone age of traditional telephony? Asking for a legal action against “anonymous” would be as ridiculous as when Polyphemus blinded by cunning Odysseus was shouting ‘”nobody harmed me.”

What is Identity Actually?

The question is how can we reasonably answer to the compelling need for creating identity? Maybe even the first question to ask ourselves is “what is identity?”. Certainly DNA is a widely accepted notion of identity and if we were able to link IP packets with the originator’s DNA, the problem would have been solved. DNA is hard to change and unambiguous. Unfortunately, linking DNA to electronic communication does not sound very easy. Learning one’s DNA, encoding it, disclosing it in a way that guarantees non-repudiation, all of these problems make it terribly impractical.

Other Sorts of “Identity”

Many of the Internet e-shops have thus chosen a much simpler way for their purpose: they don’t really care about their customers’ DNA as long as they know their valid credit card number. Showing one’s credit card number to create trust is certainly not applicable to all Internet applications. However, if we find a way, in which sender’s IP packets are linked to a paid-for identity of his, we are on the right way. Only then will it be hard for an attacker to deny, change frequently or conceal his identity.

The “best current practice”

Actually a paid-for identity does exist in the Internet, we do not need to re-invent such. In fact all address verification emails “confirm this email if you wanted to do something with us” are paid-for, as they rely on paid-for DNS name. The verification established that the communication party is reachable under a non-free address, which is thus harder to change. IF we use the same scheme for VoIP, it would become quickly ineffective for all sorts of attackers to change identity by buying new domain names serially. Additionally, DNS as “trust currency” is already established for many other applications.

VoIP Verification

So this is I believe the conclusion: let’s use the email current best practices for weak verification of addresses to establish a notion of traceable identity. Not only is this proven and linked to a paid-for DNS service, it has a great migration strategy and incentives for adopters. It does not take the cooperation of multiple parties, industry consortia and other factors predestining a “cute idea” to fail. All it takes is telephones using this verification callback and providing preferential treatment for phone calls with clear identity. Callers’ telephones are likely to develop support for such verification (if needed) not to be blacklisted soon.

In summary, being able to verify with whom you talk will soon be one of the success-determining factors for VoIP. Using Current Best Practices as reverse address verification seems to be quite an appealing proposal. In the next post, I will provide a more technical review of current efforts to provide identity for VoIP services.

We’ve been diving into some fairly deep subjects recently – here’s some lighter technical fare.

We are often asked what SIP proxies are, particularly when they’re called stateful proxies.

A SIP proxy, as defined by RFC3261, is the only standard SIP element that is not an endpoint. Following the strict requirements in RFC3261, a SIP proxy forwards a request to one or more destinations, gathers the best response from each of those locations and forwards that response back to the requester.

It is important to note that a SIP proxy can deliver a single request to multiple destinations simultaneously. That is, Alice can call Bob and all five of Bob’s phones will start ringing at once (because Bob’s proxy was configured to handle calls for Bob that way). Proxies can also try a request at one class of destinations and if they don’t provide an answer quickly enough, withdraw the request from them and try somewhere else. For instance, if Bob doesn’t answer any of his five phones within 10 seconds, his proxy will cause the phones to stop ringing and will forward Alice’s invitation to Bob’s voicemail server.

RFC3261 defines two modes of operation for proxies, transaction stateful and transaction stateless. Transaction stateful proxies keep track of transaction state machines – one server state machine for the request it received and several client state machines, one for each request it forwards. The “state” in transaction stateful refers to that information the proxy remembers while handling each request, waiting for responses, and handling the responses that arrive. Keeping this information allows the transaction-stateful proxy to recognize retransmissions of requests, gather responses to forked requests (and eventually chose a best response to send), and to recognize a failure condition where the request doesn’t receive any response within the appropriate amount of time.

In contrast, transaction stateless proxies create no transaction state when forwarding a request. As a consequence, retransmitted requests are indistinguishable from new requests and have to be processed again, and that processing has to produce identical results or the overall system will not behave correctly. This limits transaction stateless proxies to  very special routing situations where the request will only be forwarded to exactly one location and that location does not change.

There is a different, less well defined, type of statefulness often referred to as call-stateful. A call-stateful proxy remembers successful INVITEs and keeps track of the dialog usages they create until they are terminated with a BYE. Such call-stateful proxies typically are acting as controllers for firewalls or providing some other form of policy enforcement – all well beyond what RFC3261 defines as a proxy.

Usually, when someone says “stateful proxy” they mean the transaction-stateful proxy as defined in RFC3261. But be careful – if the context in which you encounter the phrase is ambiguous, it’s best to ask what was really meant.

This is the first in a series of blog postings on the topic of “identity management” in SIP-based networks. The second posting is planned for Tuesday, March 24th.

Identity (Shorter Oxford English Dictionary Definition): The condition or fact of a person or thing being that specified unique person or thing, esp. as a continuous unchanging property throughout existence; the characteristics determining this; individuality, personality.

Anonymity prevails in the Internet

Almost everyone knows the Peter Steiner’s picture of a dog surfing on the Internet and saying to a fellow dog: “On the Internet, nobody knows you’re a dog.” [1] This 1993 famous picture shows that it is not easy between Internet users to establish identity credibly.

To a large extent that still holds, despite continuing  privacy protectionists’ concerns about disclosures through social networks and Internet providers’ effort to track users for marketing and legal-interception purposes. By the way, did you know that in Italy visitors of Internet coffees have to present their passports?

Future unsettled

Still, what is going to happen next remains largely unsettled. Identity in telecommunications has been for decades a frequent topic of heated debates. Privacy defenders are concerned about “big brothers”; legal enforcement agencies about their ability to track communication of criminals. Service providers feel caught in between both – finding all positions mostly a liability for themselves. Credible horror stories have been brought both in favor and against privacy. Frequently, violation of privacy in non-democratic (and sometimes democratic) countries by governments and criminals has been reported and used as argument for making anonymous communication possible, in legal and more reliably technical ways. On the other hand, anonymous communication is not only an obstacle for law enforcement agencies. From my own consumer experience all anonymous phone calls I have answered in the past five years were solely a nuisance. This was particularly irritating whenever I was paying roaming charges for incoming telemarketers’ calls.

State of the art

In most cases a modus vivendi developed in which service providers developed as a trust broker under influence of governmental organizations. If anonymous communication is desired, the service providers store information about the communication in confidentiality. Only if a law enforcement agency approaches the service provider with a legitimate disclosure request, the providers disclose confidential data. This is the case with telephone companies, Internet providers as well as Application Service Providers (ASPs).

VoIP impact

Nevertheless, this does not work well enough for VoIP. Like with traditional telephony, unsolicited calls can come at any time and cause very direct annoyance to the call recipient. The greatest advantage of the Internet ironically turns against the users. Whilst the Internet has reached its incredible penetration due to its global nature, technical simplicity and its economy, it is exactly the same features that telemarketers and attackers can enjoy. 6 AM telemarketing calls (of course automated) started from the other side of the globe or midnight attacks against your VoIP phone – that is all incredibly easy with VoIP. Recent attacks in Germany show this has begun to happen. [2]

Please come back on Tuesday, April 21st, 2009, to read the 2^nd (of 3) posting on this topic.

[1] http://en.wikipedia.org/wiki/On_the_Internet,_nobody_knows_you’re_a_dog

[2] www.ipcom.at/fileadmin/public/2008-10-22_Analysis_of_a_VoIP_Attack.pdf

Several weeks ago, I posted a rant on things that can stifle innovation. I threatened a part 2, in which I would discuss flexible application design. This is that post.

It may be instructive to take a look at one of the biggest hotbeds of innovation in the last couple of decades: the World Wide Web. There are many reasons for the success of the web, but I think the biggest one is that it has been treated as a platform, not an application. There are lots of web related standards and architectures, but most of them define how you move data around and present it to users. Very few of them define how applications themselves work. (See Adam’s post about standardizing tools, not services.)

Representational State Transfer (REST) has generated a lot of interest of late among the web community. REST is an architectural style that has, as its most basic principle, the idea that application state and function can be abstracted into addressable resources. More on that in a bit, but keep in mind that SIP borrows a lot from HTTP. The REST approach makes it very easy to reuse and recombine application bits in new ways.

Let’s look at a very common telephony application: Voice Mail. Back in the early days of SIP-based VoIP, people proposed a “diversion” header field for SIP. A SIP proxy would retarget a SIP call to the URI of your voice mailbox, and put a reason code in the diversion header field. The reason might be something like “busy”, “no answer”, “do not disturb”, and such. The voice mail server would use that information to determine its entry state.

That approach works fine as long as all voice mail servers have the same cookie-cutter sets of functions, but if you came up with a brand new function, your SIP proxy wouldn’t know how to invoke it. And it’s useless if you want to interact with some application other than voice mail.

RFC 3087 proposes a better approach. Rather than carrying inputs in application-specific SIP extensions, you treat each application entry state as an addressable resource, similar to REST for HTTP applications. So instead of having a single address for my voice mail box, I have a URI to deposit a voice mail because of a “ring-no-answer” condition, another for “busy”, another for “do not disturb”, and so on.

Furthermore, you don’t standardize the URI conventions in advance. Rather, you configure your proxy with target URI for each function. While this can make configuration more complicated, it makes it easy to add new functions that no one may have previously thought of. It’s okay to create conventions for mature application categories, but it’s still important to allow people to create new, innovative functions without having to go back to the drawing board (or even worse, the standardization process.)

RFC 3087 is often misunderstood to be about voice mail applications. It’s really about application design in general. Voice mail is just an example.

So, next time you want to design a SIP extension for some new application or service, go spend some time in your web browser first. Are you helping to create a similarly innovation-rich environment for real-time communication? Or are you creating yet another dead end?