Critical issues forum
This presentation is the property of its rightful owner.
Sponsored Links
1 / 60

Critical Issues Forum PowerPoint PPT Presentation


  • 115 Views
  • Uploaded on
  • Presentation posted in: General

Critical Issues Forum. i3 – The future and beyond Brian Rosen Emergicom. Caveats for this session. Lots of different stakeholders here – I’ll be moving back and forth among messages to each of them

Download Presentation

Critical Issues Forum

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Critical Issues Forum

i3 – The future and beyond

Brian Rosen

Emergicom


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 [email protected]

    • Except Dade county, which goes to [email protected]

  • 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


  • Login