Critical Issues Forum

i3 – The future and beyondBrian RosenEmergicom

Caveats for this session

Lots of different stakeholders here – I’ll be moving back and forth among messages to each of them

I’ll cover some things at a very high level initially, and later go into some more detail on them

Some repetition of Henning and others’ points i3 isn’t agreed yet, this is my opinion of how things

will turn out

Reminder of the basic Emergency Call problem

Determine a call is an emergency call Route the call to the correct PSAP Include the location of the caller so help can

be dispatched to the right place Include a way to call back if disconnected

The “Sierra Leone” problem

Patron at a Starbucks café has a laptop with WiFi connection to the Internet

VPN Tunnel exists to Patron’s employer Softclient on laptop connected to employer’s

VoIP PBX An accident happens, and the patron dials 9-

1-1 for help

Sierra Leone cont. – So What?

The Starbucks is in Chicago The employer is Sierra Leone Trading Intl Its VSP is Sierra Leone VoIP Services Pty Its ISP is Cable and Wireless Starbucks uses T-Mobile to supply the hotspot There are no contractual relationships except that

between S.L. Trading and S.L. VoIP There is clearly no contractual, legal or other

relationship between the Chicago PSAP and any entity in Sierra Leone

Assumptions for i3

PSAP is on the Internet (maybe behind a big firewall) Call taker answers VoIP call, not a gateway to

existing technology Databases can change Database access mechanisms can change Not necessarily a carrier in the path Inherently multimedia: Voice, video, image, text,.. Addresses are not necessarily numbers (e.164)

Challenges for i3

PSAP is on the Internet (maybe behind a big firewall) Call taker answers VoIP call, not a gateway to

existing technology Databases can change Database access mechanisms can change Not necessarily a carrier in the path Inherently multimedia: Voice, video, image, text,.. Addresses are not necessarily numbers (e.164)

PSAP is on the Internet

This means that anyone can place a 9-1-1 call to the PSAP

Must deal with viruses, Denial of Service attack, etc. directed to the PSAP

Need to have the routing database publicly available to all

Call taker answers VoIP

Implies that the design of the PSAP changes from a TDM switch (SR + PBX) to a data network

Must make VoIP protocol choices

Databases can change

More information can be provided Data can be reorganized to better fit the

source and use of the data Need to figure out how to populate and

maintain the data accurately

Data Access Mechanisms can change

New, IP based protocols will be used to access the data

These protocols are, for the most part, promulgated by the IETF, a new partner for the 9-1-1 community

Data will be public, raising security and privacy concerns

Not necessarily a carrier

Anyone can set up a VoIP system Large enterprises/organizations probably will,

much as they run their own email system Means that you cannot rely on a carrier to do

data management and validation Means that you cannot rely on a carrier to

deal with problems

Inherently Multimedia

Will support video, images and text (Instant Messaging) from the start

Means that the “phone” at the call taker workstation is NOT a simple VoIP set

Work towards passing this media towards the responder

Implies recording systems change

i3: It’s bigger than just us

The U.S. (or even North America) can’t design their own system

– The Sierra Leone Problem– Roamers from, say, Japan– Purchases by local citizens of equipment from other

countries There are NO national variants of any Internet

protocol The solution is to make the solution an international

solution, primarily promulgated in the IETF NENA can have significant influence in this process

How this will work (at least at i3)

The phone learns its location from the LOCAL environment

– DHCP supplies location when the laptop gets it’s IP address– This is the right location, before the VPN tunnel is

established Location is carried in the signaling, with the call There is an available routing database so that

anyone, worldwide, can route the call to the correct PSAP

This will be a significant change to the PSAP

It’s not really possible to gateway VoIP calls to existing systems, we will gateway PSTN calls to VoIP

Not limited to voice Much more data associated with the call Much more routing flexibility that existing systems,

especially in the Selective Router, can supply And one more thing

The Current 9-1-1 system is dangerously vulnerable to deliberate attack

Current congestion control mechanisms limit the number of calls into the PSAP to a very small number

Current Internet Viruses can infect 10s of thousands of machines, more than 50% of which have modems connected to existing PSTN lines

If a virus was directed to call 9-1-1, wait for answer, hang up and try again from thousands of machines spread out all over the country, the entire 9-1-1 system would be taken down. Not related to VoIP.

Such a virus has ALREADY been written, but not widely deployed

There is no defense available to stop this kind of attack

Routing is non trivial, especially in North America

There are approximately 6,134 PSAPs in North America

Each has a service boundary They are NOT necessarily aligned to any political

(state/county/city) boundary Call must be routed to the correct PSAP There are databases that exist for civic and geo

locations that tell you where to route the calls But currently, access to them is restricted, and has

cost associated with it Other areas are easier (one PSAP for a country)

others are harder (no existing database)

Location In Enterprises

Getting to the right “address” is not enough– Think of this as the “yelling” test

All enterprises who have large facilities will need to provide more specific location information

We’re going to make this as easy as possible, but it’s still going to be some level of burden on enterprise

Making Location work in Enterprise VoIP

Same basic idea – phone learns location from its local environment

– Could be proprietary to your VoIP vendor– Standards based approaches are feasible now– RFC3046 describes a mechanism to determine the switch

port a packet arrived on– Or check out LLDP-MED

This gives you the basis to use a (manually maintained) wiremap database (room number to switch port) to determine location – and that is where the cost is

DHCP can be used to supply this location to phones Location to building/suite/floor/room can be specified

Location for Residential VoIP

Voice Service Providers don’t have much of a role because they don’t know where the customer is AND THEY DON’T HAVE A RELATIONSHIP WITH ANYONE WHO DOES

The ISP may or may not know, but if they don’t they have a relationship with someone who does

The Access Infrastructure Provider knows where the customer is

Access Infrastructure Providers

“First Mile” infrastructure owner, wireline or wireless Wireline AIPs already have a notion of a Service

Address, and a wiremap (or equivalent) database I believe ALL AIPs, regardless of technology, and

regardless of whether they offer voice/video/text services, must supply location

It’s likely that regulation will be required, and it’s likely to happen

Fixed wireless (e.g. WiMax) vendors; plan on GPS receivers or triangulation mechanisms

You heard it here first

ISPs

If you are the AIP, you supply location to endpoints

If you aren’t, contract with the AIP to get it If there is a system spec on all infrastructure

including all end points, you can use any mechanism you like to get location to the endpoint

If you don’t have such control, support at least DHCP

Cascaded Location

Applicable to things like WiFi “AP” gets location from its environment, and

relays it to its endpoints If possible, supply more specific location

– The “yell test” again Works for things like café hotspots

Next Up - SIP Phone Vendors

You have to get location from the environment as described

If you do digit analysis in the phone, you have to learn the local emergency call number for the environment the phone is in

– We are working on standards for this When you detect an emergency call, or the

downstream proxy tells you its an emergency call, you must supply location

SIP Phone Vendors, cont.

Because location is sensitive, IETF standards REQUIRE sips (TLS) for emergency calls

PLEASE implement this now, pretty please Supply a good callback in Contact

– Good as in, “reachable from the PSAP” Implement blind and supervised transfer

(REFER/Replaces) 3rd Party Call Control (for conferencing)

SIP Proxy Vendors – Your turn

For i3, you need to implement routing based on location– This is the charter of the new IETF ECRIT

working group– A DNS based approach will work, others may or

may not, we’ll see You have to implement TLS too Allow callback from the PSAP

– Probably more a configuration thing

What if you don’t support SIP?

The standard interface to PSAPs, at least in North America, will be SIP

Other vendors will have to gateway to SIP to send emergency calls

Most vendors already support SIP, because most inter-enterprise/inter-carrier peering is SIP

Must include location, as per SIP standards on the call

VSP Responsibilities

Deploy TLS– So, beat up your (SBC) vendors. It’s the Right Thing To Do

For i3, simple routing decision – Look up location in a database (DNS for example)– Forward call to where it says to– No 3rd parties– Some proposals have the lookup occurring prior to placing a

call, I think that won’t work but we’ll see Allow callbacks to Contact header May need identity assertions

Other communications service providers have a role too

Video telephony/conferencing vendors, i3 PSAPs will take the calls– Also applies to camera phones

IM vendors, i3 PSAPs will take the calls And for everyone, there will be a new

generation of “TDD” devices based on SIP and interactive text streams. Please plan on supporting them

i3 Status

“Long Term Definition” working group in NENA VoIP/Packet Technical Committee

– Currently writing requirements– Will finish as early in CY2005 as I can push them

IETF ECRIT Working Group– Probably will be chartered within a month– Specifically limited to routing calls– VoIP allows international roaming, and effectively

international addresses (TNs/URIs) – Need a single global standard

– There are NO national variants of IETF (Internet) protocols

Other information that comes WITH THE CALL

Caller languages– automatically route to PSAP or call taker that

speaks French– Accept-Language: fr

Caller media preferences– automatically route to PSAP or call taker that can

deal with typed text– Accept-Contact: *;text;require

Location

Really, there are only two ways to determine location Measure it (e.g. GPS) Type it in (street address)

– Hopefully, a carrier (or enterprise) function– If you started with a civic (street address) don’t translate

Or we have to worry about what database you used to translate– PSAPs might have good databases

But the general case is there will be errors in conversion Always send the original data We can handle multiple forms, if you have both, send them

Getting location on wired phones

“DHCP” = protocol to get local infrastructure information

Commonly used to assign the IP address to a device

Now has a way to report location The entity that assigns (the first) IP address

knows where the wire is

Routing a call to the right PSAP

Many entities will route– Not necessarily a carrier, remember?– Carrier may not be local (Sierra Leone)

Need a globally accessible routing database– Which returns the “URI” of the PSAP (like a phone number)– But in VoIP, we can “Authenticate” a caller– Which means we only accept “9-1-1” calls

The routing database

Must be able to route civic and geo locations Must be able to be local, regional, national in scope,

with exceptions– E.G. All calls to State of Florida go to sos@psap.fl.us– Except Dade county, which goes to sos@psap.dade.fl.us

Must be readable by anyone, but writable only by the PSAP/9-1-1 authority

– Readers must be confident data is authentic and has not been modified

Proposal (not yet agreed)

Use the “Domain Name System” Normally used to translate a domain name (like

www.yahoo.com) to an IP address (like 123.112.62.10)

The DNS is– Distributed– Hierarchical– Redundant– Reliable– And (with DNSSEC), secure

What do you mean Hierarchical?

Multiple levels– Top level domain (like .com)– Second level domain (like yahoo)– N-level domain (geezer.pitt.comms.marconi.com)

For 9-1-1 we will use sos.arpa– 123.main.pittsburgh.allegheny.pa.us.sos.arpa contains the URL of

the PSAP that serves 123 Main Street– 235.5.newco.123.main.pittsburgh.allegheny.pa.us.sos.arpa would

be the location reported for room 235 on the 5th floor of the Newco suite at 123 Main St.

DNS is reliable

Multiple copies of the “authoritative” data geographically distributed

– E.G. St. Louis could have copies of Pittsburgh’s entries in the DNS

DNS servers “cache” copies of the data Caches can supply data even if connections to

authoritative servers are down DNS has not hard failed in last 15 years

DNS is distributed

Domains are “delegated” by higher level domain (e.g. Commonwealth of Pennsylvania delegates allegheny.pa.us.sos.arpa to Allegheny county, only Allegheny county can put data in that domain

Allegheny County has multiple copies of allegheny.pa.us.sos.arpa, PA has multiple copies of pa.us.sos.arpa, and they are in different servers

Building Owners and Tenants can be delegated their entries and supply data themselves, or contract with someone else to do it

DNS servers cache data locally = lots of copies all over the world Data has a lifetime (i.e. cached data times out and must be

prefetched from authoritative source)

DNS is secure

Cryptographic technology to assure– Only the authoritative server created the data– No “man in the middle”– No modification to the data

Provides the basis to assure callers they reach the real PSAP when they call 9-1-1

PSAPs on the Internet – No Way!

Way– The calls are on the Internet, so in some way, the PSAP is

on the Internet– Yes, it may be that many calls come from a carrier over a

private net– But many calls will really come over the “big I” Internet

But that does not mean each PSAP is directly on the Internet

Emergency Services Networks behind large firewalls– Might be state level, or more likely, city/county level

interconnected up to state level– All public safety networks would be connected to these

ESNs– But put a firewall between the ESN and your PSAP, please

Please don’t say “trusted”

Never trust Always verify Use cryptography

– Authenticate– Integrity Protect– Privacy Protect

You want the data that is out there anyway Allow access, but protect against intruders Requires

– Skills (not usually found in local IT groups)– Lots of bandwidth (gigabits) from the Internet

Response to Denial of Service Attack

Unlike the current system, the i3 PSAP will have reasonable defenses for DoS attacks

Signaling channels will handle 10s of thousands of calls

Firewalls will filter out bad calls “Leakers” will be directed to any available call takers,

and will only happen once per infected machine Firewall mechanisms will be flexible, and capable of

being dynamically modified PSAPs will be on managed networks not directly

accessible from the Internet

Legacy infrastructure

Sure, wireline/wireless PSTN will be the majority of the calls for a while

– Latest forecasts show 40% of wireline calls in U.S. will be VoIP within 5 years

Gateway PSTN into VoIP PSAP – We’ll start with a gateway from S/R to the PSAP– But VoIP will have many new functions S/Rs can’t do– So expect to gateway CO to PSAP, eliminating the S/R eventually

This might take a while DNS can tell you if PSAP is i3 upgraded!

Get ready: there is no ALI in i3

Location comes with the call We can dynamically query the MSAG equivalent as

the call arrives for ESN and other data associated with the location

This means we don’t need the ALI And we can get rid of all the processes to maintain it We’ll keep a simple form of it for PSTN

There is no ESN

We have to build a mechanism to define the service boundary of a PSAP for both civic and geo

We can use the same mechanism to define the service boundaries of any number of responders

We don’t need codes A query to the new MSAG will return the URI

(address & ELT equivalent) of the responders for the location

Eventually, there is no Selective Router

The S/R is the root of the existing deliberate attack mechanism

The S/R cannot transfer calls outside of the PSTN The S/R cannot handle non voice media streams The S/R cannot break the phone number/location

mapping problem So, we’ll phase it out

Phasing out the S/R

i3 will start with only VoIP calls coming in direct to the PSAP via IP

We will deploy a gateway between the S/R and the PSAP to convert PSTN and wireless calls to VoIP. It will use the existing ALI

Wireless can convert to VoIP at any time (no MPC required, just put location in the VoIP signaling)

Then we will move the gateway to be positioned between the C5 and the PSAP, bypassing the S/R

Eventually, I hope the PSTN carriers will deploy their own simple phone number to location mapping, and then we can decommission the ALI

Routing Flexibility in i3

We will have much more flexibility to route calls– Within the PSAP

By media type (TDD), language preference, location– Between PSAPs

Transfer to any i3 PSAP or responder WITH ALL DATA INCLUDING LOCATION

Failure routes can be to any PSAP willing to accept the calls

Route changes can be made dynamically, by PSAP management

i3 will lead to much more flexibility in disaster routing

Let’s talk about congestion control No one deserves a busy Busy is the networks response to no resources

available to help, usually, no call takers Callers get 1 bit of information from a busy – no one

will help you, you are on your own PSAPs get no information from a busy; you don’t

even know that it occurred Responders might be maxed out too, but they want

to triage. First come first served is NOT appropriate And you can’t triage if you don’t get all the data

Disaster Routing in i3

We can, if we want to, route calls to any i3 PSAP anywhere in the country

There are about 20,000+ trained call takers on duty at any one shift

We can build databases that any PSAP can access and add data to (who, where what, how bad, …)

We can provide instructions to callers We can, in some circumstances, provide first aid

instructions

Why would we do this

Major system failure Widespread disaster which overwhelms all

regional facilities Deliberate attack which tricks existing firewall

techniques until custom filters can be developed and deployed (maybe hours or a day)

We would only do it when both sides agree

Sending PSAP has to enable offload Receiving PSAP(s) has to accept offload One or more groups will have to develop criteria and

response plans so call takers can be trained It’s a disaster, we don’t need to use the same criteria

and responses we would under normal circumstances

Lots of data will be available

We can create data that is associated with a location Yes, you could put it in the GIS, but it makes more

sense to actually construct a distributed database that ties all information we have about a structure

We can delegate parts of this to building owners, if they are willing

The structure data can be made available to responders as well as call takers and dispatchers

Data on callers

VoIP has a notion of a user, distinct from the device (phone)

We can create an (opt-in!) database of information about a caller– Medical data– In an emergency, contact,…

Callers can roam, and the data comes with them

PSAPs will look a lot different

Not much of current PSAP systems will survive There is no switch (S/R, PBX, ..), it’s all in the data

network Things like loggers will change (video, text, new data) You’ll still have a call taker workstation, CAD and

radio console, but completely new code/functions/data organization

Some operational differences, but mostly new capabilities; call answering isn’t going to change radically

Funding

You can’t get a surcharge on CSPs, because they are not local and there may not even be one

What you can do is to have a surcharge on the Access Infrastructure Provider

Doesn’t matter if they aren’t the CSP, their facilities are used to place 9-1-1 calls

Would apply uniformly to all AIPs, which includes existing facilities based wireline and wireless vendors, even cable companies

They are always local, and always subject to regulation

Also no ALI, and the MSAG has to be free, so the surcharge is all you get.

Funding, Access Infrastructure Provider burden and reimbursement

This proposal loads the AIP with new responsibilities– Providing Location– Collecting and remitting surcharge

With those responsibilities, there are costs There is precedent (wireless) to allow cost recovery

from surcharge revenue This may make the scheme more palatable to the

AIPs

Summary

Phone Vendors – you have work to do Proxy Server vendors – you have work to do SBC vendors – you have work to do Access Infrastructure providers – you have work to do Internet Service Providers – you have work to do Communications Service Providers – you have work to do Enterprises – you have work to do PSAP CPE vendors – you have work to do PSAPs – your life will change, and you have work to do