[VoiceOps] International IP blacklist

[John Todd]

On Apr 18, 2010, at 3:37 AM, anorexicpoodle wrote:

> Depending on your scope of service, I personally have found that  
> maintaining static blocklists just creates a heap of support  
> problems, but instead deny traffic outside ARIN allocated IP's  and  
> allow customers to turn on international use individually which has  
> severely cut down our fraud, since chasing it statically is just a  
> game of whack-a-mole.
>
> Though this topic does raise a question I have been kicking around  
> for a while, has anyone here tried implementing a SIP equivalent of  
> URPF on your border controllers or proxies on the peering side, so  
> if you cannot determine a route back to the calling number you drop  
> the call to IVR or reject? Obviously implementing UPRF at L3 has  
> saved me tons of headaches in other facets, but certainly a L5  
> solution could alleviate a potential ton of spam calls that come  
> through normal PSTN connections. Thoughts?

This is extremely difficult, if not impossible to do, with E.164  
addresses.  If you have a specific method that doesn't run into the  
authority/ownership headache issues that I can think of, please let  
the list know - I don't think there's a foolproof (or even marginally  
useful) way to do this.  IMHO, E.164 should die.  Good thing my  
opinion has little impact on the global telephony infrastructure!  ;-)


However, there IS a way to implement a semi-robust method for  
verifying domain identity for calls that come in with a SIP URI as the  
From: address or other type of asserted-identity.  It is kinda-sorta  
like URPF, or SPF.  Check out this idea I had some time ago (code  
included!):

   https://archives.internet2.edu/wws/arc/sip.edu/2006-07/msg00012.html

I have implemented this on my machines and it worked quite well (using  
Asterisk, but almost any intelligent SIP platform could easily script  
this method) and it seems to close a lot of the risk holes in  
accepting SIP session invitations from "the Internet at large."

Note: people reading that letter may assume, without close  
examination, that this is based on inverse address (in-addr) usage.   
It is not.  :-)

JT