Hello, and greetings from the Central Office! It’s hard to believe that it’s already winter, but the Cascades are covered in snow and ski racks are on almost every car. This is a time of year when a lot of emergencies happen, and the telephone system plays—now more than ever—a vital part in emergency response.
These days, 911 is the virtually universal way throughout the US and Canada to summon the police, fire department, or an ambulance (sometimes all three at once). There is an extremely detailed and rigorous set of standards around how 911 systems and facilities are designed and constructed, and the standard-setting organization is the National Emergency Number Association (NENA).
When you dial 911, the telephone switch invokes a SS7 route that has been specially configured for this purpose. In most cases, your call will be routed over a dedicated trunk to a dedicated 911 switch (although in some areas this is a shared tandem switch—not the recommended configuration but it’s better than nothing). The 911 switch looks at your inbound ANI, and based on that, routes you to the appropriate Public Safety Answering Point (PSAP) via a dedicated trunk. At this point—only a couple of seconds after you placed the call—the call answerer will inquire “911, what’s your emergency?”
The information available to the 911 call answerer is dependent upon the 911 infrastructure in your area. In most cases, this will be some form of E911, the current standard (most recently updated in 2004). At the network level, E911 consists of a voice circuit (over which you communicate with the call answerer), and a data circuit. The data circuit (which is private, runs a proprietary protocol, and isn’t connected to the Internet) is a redundant dedicated connection to an Automatic Location Identification (ALI) database.
Basic 911 provides only a voice connection to the PSAP, with no other identifying data. While call takers have the ability to trace calls, it requires a call to the local phone company which can take up to 10 minutes. The limitations of this system are evident when 911 calls are received by people who are disoriented or experiencing medical emergencies, and may be unable to answer many questions or even provide the location from which they are calling.
In an effort to solve this problem, the E911 standard was developed. E911-capable PSAPs use Automatic Number Identification (ANI) data to identify callers. Based on this data, your phone number will display on the call answerer’s console. The E911 system will also query the ALI database based on your ANI data. In most cases, this database is maintained by Intrado, Incorporated (a private company) and contains CNA (Customer Name/Address) data for nearly everyone in the United States with a phone—even including unlisted numbers (I bet telemarketers would love to get their hands on this). Newer revisions of E911 include the ability to provide GPS location data for wireless phones, and this data is also obtained via the ALI database. However, these capabilities are fairly new and not yet widely deployed.
While the 911 system is incredibly useful and has saved many lives since it was originally deployed in 1968 (in Haleyville, Alabama and Nome, Alaska of all the random places) it wasn’t originally designed to work with newer telecommunications services such as VoIP, wireless phones, and CLECs. These have exploded since the Telecommunications Act of 1996 largely deregulated telephone service, creating both challenges and security vulnerabilities in the 911 system.
VoIP services, in particular, have illustrated practical vulnerability in the E911 system. Recently, a group of highly unethical phreaks (one of whom was known years ago as “Magnate”) was arrested for engaging in an activity called “SWATting.” This exploited a little-known and multi-tiered loophole in the E911 system.
In case you haven’t heard what “SWATting” is, it involves spoofing someone else’s ANI when calling a 911 “backdoor” number. Every PSAP in the 911 system has a “backdoor” number by design. These are used by operators to connect you to emergency services if you dial “0” instead of “911” for help. They can also be announced as the emergency contact number via the Emergency Broadcast System (of “This Is A Test” fame) in the event of a failure in the 911 switch or trunks (this actually happened a few years ago in Seattle). The unethical caller can then describe a violent kidnapping or other situation likely to provoke a SWAT team dispatch by the 911 call taker, who has no idea that the apparent caller is actually the victim of a cruel (and very dangerous) hoax.
Back in the good old days of Ma Bell, nobody could touch the SS7 network except for loyal card carrying CWA union technicians. These days, any idiot with an Asterisk box and a sleazy VoIP provider based in Romania effectively has full SS7 control and the ability to impersonate any ANI they damned well please. This is because with certain VoIP providers, any TNI data that you configure in your VoIP PBX is accepted as gospel by the VoIP carrier, and is sent to the PSTN as both CLID and ANI data. Congress is worried about spoofing Caller ID, but that’s small potatoes in my mind—most of the shenanigans around spoofed CLID data are harmless pranks. ANI spoofing, on the other hand—especially when mixed with 911—is the real problem. If anything damned well ought to be more illegal than it already is, it’s this!
And that’s the end of my curmudgeoning here from the Central Office, at least for this ski season. Stay in bounds, stop in place if you experience a white-out, and always keep your mobile phone charged to call the ski patrol!
Links
http://www.nena.org – National Emergency Number Association, the standard-setter for 911 systems.
http://www.qwest.com/wholesale/pcat/911.html – Qwest 911 interconnection and product offerings for filthy CLECs. This site contains links to many excellent diagrams of Basic 911 and E911 call routing topologies, which incompetent CLEC technicians could never understand.