March 04, 2006

Caller ID Spoofing

A few days back, AP had a story about easy availability of Caller ID spoofing service. As the article points out that this was feasible in PSTN itself (for example with CO trunks) and now it is more widely available with some VoIP services. The story also points out that there are many caller ID spoofing services. Obviously, many PSTN subscribers object to this capability and some are asking for legislation that will make it spoofing illegal.

There are legitimate uses of spoofing and the affected industries will object to such legislative attempts. For example, a call center that serves multiple customers should be able to put the caller ID information depending on the customer associated with the call. So my recommendation is the following set of actions on the service providers.

  1. As a caller ID subscriber, it is natural for me to expect my service provider to authenticate the validity of the caller ID information it is delivering to me. If it can not validate this information, then it can deliver that information; but it should mark it as such, that the information is not validated.
  2. Two peering networks must establish ground rules to extend the voracity of the validity routines across the two networks.
  3. If a network fails to stand by the voracity of its validity routine then any caller ID information it passes on should be marked as not validated.
  4. Of course this applies to VoIP providers as well, if they want to interconnect to PSTN. This is very much like even a small airport having the same level of security check if the passengers to have easy passage through other airports.

Currently SS7 ISUP and ISDN Q.931 (thereby H.323) have a mechanism (look at the Calling Party Number Screening field) to carry the status of the validity of the caller ID information. If it is already not there, then SIP and MGCP can easily add this. But the protocol for analog interface does not, but it is a simple matter to extend it.

In my opinion that this is a good compromise for all the parties involved. A legitimate callerís need for flexibility is maintained; the service providers need to implement a simple rule; the called user is given as much information as available.

Posted by aswath at March 4, 2006 02:15 PM
Related Posts Widget for Blogs by LinkWithin
If you do not have an OpenID, then please use www.enthinnai.com/unauopenid/anyblog.

 

Comments

Errr... so the trust model of the PSTN is fine as long as everyone who participates is trustworthy.

Whereas a "stupid network" requires the sender to assert something about who they are and then the recipient has to ascertain the truth of that with reference to a third party of choice (and that choice is allowed to not be the ITU). [Whether Verisign is less evil than the ITU is left as an exercise to the reader.]

Trust isn't transitive; only by being closed and static can the PSTN survive. The Internet is Darwinian-style evolving organisms highly resistant to attack. The PSTN is not, and has no resistance to Packetian Flu. The only possible outcome? See http://www.telepocalypse.net/archives/000453.html.

Posted by: Martin Geddes at March 4, 2006 03:12 PM

Martin, Your point is well taken. But the point here is not PSTN vs. Internet; I am of the opinion that that point has been established. Given PSTN's weakened state of immunity, I am asking whether we should ban infection (as being pursued by FCC) or should it avoid contact so as to protect itself.

Posted by: Aswath at March 4, 2006 07:47 PM

SIP has RFC3323 and 3325 which implement some privacy extentions, most important the P-Preferred-Identity and P-Asserted-Identity. We yet have to push our first product using these into full service. I expect it to do the job but it also introducted a non-neglectable risk of other ISPs (your airports) to not verify these headers and somehow an asserted number is fake.

Posted by: Hendrik Scholz at March 5, 2006 03:01 AM



Copyright © 2003-2014 Moca Educational Products.