Internet Call Routing II
ISN, ITAD, and freenum.org
The biggest shortcoming of ENUM is that it uses a numbering system that is not under the control of any Internet numbering authorities. The freenum.org project solves this problem by utilizing a numbering scheme that is managed by IANA. This means that a formal, globally valid, nongeographic numbering system for VoIP can be immediately and easily implemented without getting mired in the bureaucracy and politics that burden the E.164 numbering system.
Got ISN?
The heart of the freenum.org concept is the ITAD Subscriber Number (ISN). The ISN is a numeric string that is composed of an extension number on your system, an asterisk character separator ( * ), 11 and a number that is unique to your organization called an IP Telephony Administrative Domain (ITAD) number. The advantage of the ISN is that it can be dialed from any telephone. An ISN would look something like this:
0*1273
which would represent extension zero at ITAD 1273 12 and would resolve to sip:0@shifteight.org .
You control your extension numbers (everything to the left of the * ). Your ITAD is assigned by IANA (the same organization that controls IP and MAC addresses).
Once your ITAD is assigned, you will be able to publish ISNs on your website, or on business cards, or wherever you would normally publish phone numbers.
Any system capable of dialing ISNs will allow its users to call you by dialing your ISN. Calls will be routed directly between the two systems using the SIP URI that freenum.org returns.
ITAD Subscriber Numbers (ISNs)
The ISN does not replace a SIP URI, but rather complements it by allowing dialing of VoIP numbers using only characters found on a standard telephone dialpad. In order to resolve an ISN into a valid URI, the DNS system will query the ISN against the freenum.org domain. Any DNS lookup against your ISN will return a URI that defines how your system expects to receive calls to that ISN.
Management of Internet Numbering
The Internet Assigned Numbers Authority (IANA) is the body responsible for managing any numbering system that exists as a result of an RFC that requires a numerical database of some kind. The most well-known responsibility of IANA is the delegation of IP addresses to the five Regional Internet Registries that control all of the public IP addresses on the planet. These organizations are responsible for the assignment of IP addresses within their regions.
There are many other numbering schemes that have been created as a result of an RFC. Other IANA-managed numbers include MAC addresses—specifically, the Organizationally Unique Identifier (OUI) portion of the MAC addressing space.
Several years ago, a protocol named TRIP (Telephony Routing over IP) was created. While this protocol never took off, and is unlikely to see any future growth, it did offer us one incredibly useful thing: the ITAD. Since ITADs are part of an RFC, the IANA is mandated to maintain a database of ITADs. This is what makes freenum.org possible.
IP Telephony Administrative Domains (ITADs)
Freenum.org takes advantage of IANA’s responsibility to maintain a database of ITAD numbers and allows us to build simple, standards-based, globally relevant, and community-driven numbering plans for VoIP. 16 You can find the list of currently assigned ITAD numbers at the IANA website.
You will want to obtain your own ITAD number by submitting the form located at http://www.iana.org/cgi-bin/assignments.pl. This form should be filled out as shown in Figure -1.
Figure 1. Request for Assignments form
The following information is required on the form:
1. Name of the person responsible for this application.
2. Email address of said person.
3. ITAD (IP Telephony Administrative Domain).
4. General IANA directory of ITAD number listings, as found at http://www.iana.org/ assignments/trip-parameters.
5. Participation in ISN trial (http://www.freenum.org).
6. ITADs (IP Telephony Administrative Domain) are defined in “Telephony Routing over IP (TRIP)” [RFC 3219].
Additionally, be sure to include your postal mailing address, as this is a requirement for ITAD registration.
Your application will be reviewed by a Real Human BeingTM, and within a few days you should be assigned an ITAD by IANA. A few days later, you will also receive information for your freenum.org account (there is currently a simple review process to ensure that bots and spammers don’t abuse the system). You will then need to log onto the freenum.org site and define the parameters for your ITAD.
Create a DNS Entry for Your ITAD
In the top-right corner of the freenum.org site, you will see a “Sign in here” link. Your username is the email address you registered with IANA, and your password will have been emailed to you by the freenum.org system.
You will be presented with a list of your assigned ITADs. In order for your new ITAD to work, you will need to ensure the DNS records are up-to-date.
The freenum.org folks have created the Freenum Automated Self-Service Tool (FASST) to simplify DNS record entry for you. The essential fields will already be filled out. The only thing you need to change is under the DNS Setting section of the form: specify the hostname of your PBX and save the changes. The FASST tool uses a regular expression to convert an ISN lookup to a SIP URI.
In order to specify your hostname, you will need to modify the sample regular expression provided by FASST, changing the sample hostname sip.yourdomain.com to the hostname of your PBX. So, for example, in our case we would want to change:
!^\\+*([^\\*]*)!sip:\\1@sip.yourdomain.com!
to:
!^\\+*([^\\*]*)!sip:\\1@pbx.shifteight.org!
The other fields in the DNS entry should not be changed unless you know what you are doing. The rest of the fields in the form are optional, and can be filled out as you see fit.
Testing Your ITAD
As is often the case with DNS changes, it can take a few days for your changes to propagate through the system. To check, you can Google for “online dig tool” to find a webbased lookup tool, or use the dig tool under Linux:
$ dig NAPTR 4.3.2.1.1273.freenum.org
Once your record is updated in the system, the result will include the following:
;; ANSWER SECTION:
4.3.2.1.1273.freenum.org. 86400 IN NAPTR 100 10 “u” “E2U+sip”
“!^\\+*([^\\*]*)!sip:\\1@shifteight.org!” .
If the answer section does not include the regular expression containing your domain name, the records have not updated and you should wait a few more hours (or even leave it for a day).
Using ISNs in Your Asterisk System
So now that you’ve got your own ITAD (you did sign up, right?), you’ll want to make it available to others, and also configure your dialplan to allow you to dial other ITADs.
Under the [globals] section of your dialplan (/etc/asterisk/extensions.conf), add a global variable that contains your ITAD:
[globals]
ITAD = 1273 ; replace ‘1273’ with your own ITAD number
To allow calling to ITADs from your system, you will need something like the following dialplan code:
[OutgoingISN]
exten => _X*X!,1,GoSub(subFreenum,start,1(${EXTEN}))
exten => _XX*X!,1,GoSub(subFreenum,start,1(${EXTEN}))
exten => _XXX*X!,1,GoSub(subFreenum,start,1(${EXTEN}))
exten => _XXXX*X!,1,GoSub(subFreenum,start,1(${EXTEN}))
exten => _XXXXX*X!,1,GoSub(subFreenum,start,1(${EXTEN}))
; you may need to add more lines here to handle…
[subFreenum]
exten => start,1,Verbose(2,Performing ISN lookup)
same => n,Set(ISN=${FILTER(0-9*,${ARG1})})
same => n,Set(Result=${ENUMLOOKUP(${ISN},sip,s,,freenum.org)})
same => n,GotoIf($[${EXISTS(${Result})}]?call,1:no_result,1)
exten => call,1,Verbose(2,Placing call to ISN –${ISN}– via ${Result})
same => n,Dial(SIP/${Result})
same => n,Return()
exten => no_result,1,Verbose(2,Lookup for ISN: –${ISN}– returned no result)
same => n,Playback(silence/1&invalid)
same => n,Return()
We have added two new contexts to our dialplan: OutgoingISN and subFreenum . The OutgoingISN context controls who can dial ISN numbers from within your dialplan. If you have been following our examples throughout this book, you should have a context
called LocalSets , which is the context where all your telephones enter the dialplan. Including OutgoingISN within LocalSets enables dialing of ISN numbers:
[LocalSets]
include => OutgoingISN ; include the context that enables ISN dialing
include => external ; use subroutine to determine what you can dial
The magic for dialing ISN numbers is handled in the subFreenum context. Our Out goingISN context will pass the requested extension (e.g., 1234*256 ) to the subFree num subroutine. After the initial call to Verbose() on the first line, the subroutine will
filter the request for numbers and the asterisk ( * ) character to make the extension safe. The result will then be assigned to the ISN channel variable:
exten => start,n,Set(ISN=${FILTER(0-9*,${ARG1})})
The subroutine will then perform a lookup for the ISN via the DNS system using the ENUMLOOKUP() dialplan function. Options passed to the ENUMLOOKUP() function include:
• The ISN number to look up
• The method type to look up and return (SIP)
• The s option, which tells Asterisk to perform an ISN-style lookup instead of a standard ENUM lookup
• The zone suffix for performing the lookups (we’ll use freenum.org , but the default is e164.arpa )
Our code for performing the lookup then looks like this:
exten => start,n,Set(Result=${ENUMLOOKUP(${ISN},sip,s,,freenum.org)})
Following the lookup and storing the result in the ${Result} channel variable, our subroutine will verify whether we received a result or not:
exten => start,n,GotoIf($[${EXISTS(${Result})}]?call,1:no_result,1)
If no result is received, the call will be handled in the no_result extension. If a result is received back from our lookup, then execution will continue at the call extension where the call will be placed using the result stored in the ${Result} channel variable.
Receiving calls to your ITAD
Receiving calls to your ITAD is much simpler. If your system supports incoming SIP URIs, ISNs will already work for you.
Security and Identity
It is a sad fact of the Internet that there are a few selfish, greedy criminal types out there who think nothing of attempting to take advantage of people for their own gain. In telecom, this behavior represents several risks to you.
In this topic, we will focus on security issues relating to the portions of your system that you intend to make publicly available through the Internet. While it would be simple to just refuse to allow any sort of external connections, the reality is that if you want
people to be able to call you for free from the Internet (for example, if you intend to publish your company’s SIP URIs on your web page), you are going to have to define a secure place within your system where those calls will arrive. Securing your incoming public VoIP connections is conceptually similar to implementing a DMZ in traditional networking.
In Asterisk, certain contexts in your dialplan cannot be trusted. This means that you will need to carefully consider what resources are available to channels that enter the system through these contexts, and ensure that only certain services and features are available.
Toll Fraud
Toll fraud is by far the biggest risk to your phone system in terms of the potential for ruinous cost. It is not unheard of for fraudsters to rack up tens of thousands of dollars in stolen phone calls over the course of a few days.
Toll fraud is not a new thing, having existed prior to VoIP; however, the enabling nature of VoIP makes it easier for fraudsters to take advantage of unsecured systems. Most carriers will not take responsibility for these costs, and thus if your system is compro‐ mised you could be stuck with a very large phone bill. While carriers are getting better and better at alerting their customers to suspicious activity, that does not absolve you of responsibility for ensuring your system is hardened against this very real and very dangerous threat.
Within your Asterisk system, it is vitally important that you know what resources on your system are exposed to the outside world and ensure that those resources are secure. The most common form of toll fraud these days is accomplished by brute-force attack. In this scenario, the thieves have a script that contacts your system and attempts to register as a valid user. If they are able to register as a telephone on your system, the flood of calls will commence, and you will be stuck with the bill. If you are using simple extension numbers and easy-to-guess passwords, and your system accepts registrations from outside your firewall, it is certain that you will eventually be the victim of toll fraud.
Brute-force attacks can also cause performance problems with your system, as one of these scripts can flood your router and PBX with massive numbers of registration attempts.
The following tactics have proven successful in minimizing the risk of toll fraud:
1. Do not use easy-to-guess passwords. Passwords should be at least eight characters long and contain a mix of digits, letters, and characters. 8a$j03H% is a good pass‐word. 1234 is not.
2. Do not use extension numbers for your SIP registrations in sip.conf. Instead of [1000] , use something like a MAC address (something like [0004f2123456] would be much more difficult for a brute-force script to guess).
3. Use an analysis script such as fail2ban to tweak your internal firewall to block IP addresses that are displaying abusive behavior, such as massive packet floods.
Spam over Internet Telephony (SPIT)
VoIP spam has not yet taken off, but rest assured, it will. Spammers all over the world are drooling at the prospect of being able to freely assault anyone and everyone with an Internet-enabled phone system.
Like email, VoIP entails a certain level of trust, in that it assumes that every phone call is legitimate. Unfortunately, as with email spam, it only takes a few bad apples to spoil things for the rest of us.
Many organizations and persons are working on ways to address SPIT now, before it becomes a problem. Some concepts being worked on include certificates and whitelists. No one method has emerged as the definitive solution.
While it would be easy to simply lock our systems away from the world, the fact is that Internet telephony is something that every business will be expected to support in the not-too-distant future. SPIT will increasingly become a problem as more and more unsavory characters decide that this is the new road to riches.
Solving the SPIT problem will be an ongoing process: a battle between us and The Bad Guys.
Distributed Denial of Service Attacks
SIP denial of service attacks are already happening on the Internet. Amazon’s EC2 cloud has become a popular place to originate these attacks from, and other cloud-based or compromised systems will become popular for these activities as well. The actual attacks are not strictly denial of service attacks (in the sense that they are not deliberately trying to choke your system); rather, they are attack campaigns that are typically trying to use brute force to locate exploitable holes in any systems they can find. As the sheer number of these attacks increases, the effect on the network will be similar to that of email spam.
Phishing
When a VoIP system has been compromised, one popular use of the compromised system is to relay fraud campaigns using the identity of the compromised system. Criminals engaging in so-called phishing expeditions will make random calls to lists of numbers, attempting to obtain credit card or other sensitive information, while posing as your organization.
Security Is an Ongoing Process
Whatever you are working on, you should be thinking about security. While implementing good security requires more design, development, and testing effort, it will save you time and money in the long run.
