Critical Issues Forum

1. Critical Issues Forum i3 – The future and beyond Brian Rosen Emergicom

2. 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

3. 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

4. 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

5. 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

6. 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)

7. 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)

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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)

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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)

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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.

39. 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

40. 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)

41. 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

42. 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

43. 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

44. 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

45. 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!

46. 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

47. 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

48. 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

49. 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

50. 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