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