•   over 10 years ago

Treat VoIP gateways like SMTP gateways

Hypothesis: Many robocalls originate from IP-based VoIP gateways and supply bogus Caller ID data, or use "throwaway" accounts on otherwise well behaved small providers.

Solution: Create something similar to the SPF standard used by SMTP email servers to verify or block calls from bad sources, and create shared blacklists of misbehaving gateways. "Good" gateway owners can then "opt-in" to using this data to improve service to their own customers. This will motivate legitimate gateway owners to "clean house" much as email server owners have learned to do.

Problems: 911 and similar calls will need to be treated specially.

Note: This assumes that hardwire (non-VoIP) inter-exchange links are considered sufficiently trustworthy to be ignored by this system, although it could be extended if desired.


  •   •   over 10 years ago

    Exactly. This issue seems like it will only be fixed, in a practically manner, if the phone companies create a firewall between the user and caller. There would defiantly need to be a "shared blacklist" between the different phone companies, but I also think that it is important that they actively seek for new "law breakers" by making companies apply for the right to make 1000s of calls a day. Meaning that there should also be a shared "good list" of legitimate companies. Let me know what you think, also check out my post when you get the chance. (http://robocall.challenge.gov/forum_topics/1550)

  •   •   over 10 years ago

    I've cross-posted this discussion to the Asterisk forums, since they'd be the obvious test platform for such a solution:

  •   •   over 10 years ago

    For VOIP calls, some of the methods to block SPAM could be used. One of the methods is to limit the number of calls per hour based on origin UNLESS the originator is officially registered as a legitimate organization. If robocallers are limited to 200 calls per day, they will no longer be able to annoy millions of people. After 100 calls occur, a verbal CAPCHA could then be required or better yet the caller would be connected with an operator who would confirm that the call is an emergency. Limiting the number of calls per day would make telemarketing unprofitable assuming that it normally takes possibly over 100 calls for them to make a sale since most people hang up on them.

  •   •   over 10 years ago

    The real deal is, actually we shouldn't be using phones anymore nowadays. We're still using them just because of the phone company pressures just like oil company pressures against alternative oils.

    Actually world should be using voip since long time ago.

    back in 2000's, governments were planning to enable wifi all over the countries.

    Phone companies are terrified...

    Thanks god, they saved the day and prevented governments to establish free wifi all over the world.

  •   •   over 10 years ago

    Really have a problem with blaming VoIP and spoofing Caller-IDs.

    VoIP can be configured pretty secure at any ingres point and for each call/session request. PSTN/SS7 on the other side has become a pretty open system with many backdoors since the deregulation with the Telecom Act of 1996.
    … just become a legitimate PSTN/SS7 operator for a couple of dollars and then you are trusted by any means ;-(

    Any Robo-Call operator would be stupid not going through PSTN/SS7 to perfectly hide his identity. Of course, they can use VoIP as a frontend. But the real trick is done with the shortcoming of PSTN/SS7.

    Steven and Henning mentioned this already at the summit and one who is providing a solution shall better consider this fact.
    … otherwise I can screw it at any time ;-)


  •   •   over 10 years ago

    If PSTN/SS7 operators already have access to the shared routing database mandated by number portability, why can't they sanity check incoming caller ID against the originating system, and basically use it like SPF? Then build a reputation database to blacklist known ID spoofers.

  •   •   over 10 years ago

    Simply because on easily can one of these numbers and the we will see this is a vild origin ;-(

  •   •   about 10 years ago

    It is harder than you might think.

    I propose doing essentially that as one part of my proposal but there are major engineering challenges.

    First off, you need to use a PKI based solution to get any traction here so we are doing DKIM rather than SPF (I worked on both). Steve Bellovin (the FTC judge) had some pretty negative comments on SPF which was proposed when he was the IETF security area director. The reason we had to do SPF was to prove that we really needed DKIM.

    Applying PKI to the telephone network is a hard problem. First off it probably entails a switch from the current mix of POTS circuits and VOIP to a VOIP only network. There might be ways to make the legacy POTS circuit switched networks do PKI but that would be very hard as half the suppliers are bankrupt.

    The good news is that the VOIP network already has PKI in that most of the conversations are layered over TLS (might be some IPSEC there as well). BUT the credentials used for those conversations are hop-by-hop. There is no global registry and setting one up is a really hard problem. I helped set up the only large scale PKI in existence today, the SSL certificate scheme that drives Web security.

    Fortunately, that might not be necessary. We don't need a full end to end PKI of the sort that I would prefer to build. But that might not be necessary. In fact the key issue is likely to turn out to be understanding precisely how loose we can make the PKI.

    When I worked on the Web with Tim Berners-Lee we had a LOT of people from the network hypertext community telling us that the Web was no good because it did not solve 'referential transparency', a hard problem. Well guess what, the Web still hasn't solved that problem, broken links result in 404 not found. Scruffy links turned out to be good enough.

    The genius of the Web turned out to be the fact that Tim realized that what people knew was a hard problem was not a necessary one. In fact they didn't really understand the problem at all because it is actually referential integrity but they liked to dress it up in something that sounded fancier.

    We can't deploy a full PKI for the telephone system in the US in less than five years. But we could do a piecemeal one very quickly, a year or two and we could easily write a spec that would 'join up the dots' between PKI islands. This would not provide full end to end security but it would be good enough to identify where the water was coming in from and that would be enough to plug up the holes.

Comments are closed.