Session 1: Standardization and Regulation Emergency Call Standardization

Transcription

1 Session 1: Standardization and Regulation Emergency Call Standardization Hannes Tschofenig ECRIT IETF WG Chair Siemens AG Corporate Technology

2 Agenda Big Picture Determining Location Identify Emergency Call Find Correct PSAP Emergency Call

3 Big Picture High-Level Classification Authority to Citizen Example: Cell broadcast for Tsunami warning Authority to Authority Example: Communication between emergency personnel Citizen to Authority Example: VoIP emergency call Authorities Citizen

4 Citizen to Authority Communication Relevant Bodies 3GPP IEEE ITU-T PacketCable DSL Forum Wimax NENA ETSI EMTEL IETF Emergency Context Resolution with Internet Technologies (ECRIT) Geographic Location/Privacy (GEOPRIV) Internet Emergency Preparedness (IEPREP) Session Initiation Protocol (SIP) Session Initiation Proposal Investigation (SIPPING) Transport Area Working Group Third (TSVWG) Annual VoIP Security Workshop (2006)

5 GEOPRIV The Starting Point for Location and Privacy Work in the IETF

6 Important Architectural Consideration Who knows the location of the end host? OSI Model Layer 7 VoIP, Inc. (Application Service Provider) Common point - The end device! Layer 3 Layer 2 ISP, Inc. (Internet Service Provider) Last Mile, Inc. (Access Provider) Often the access provider, the Internet service provider and the application service provider are different parties.

7 VoIP Emergency Solution Building Blocks

8 Determine Location Manual configuration GPS Link layer mechanisms (e.g., LLDP) DHCP (civic and geospatial) Application layer protocol (e.g., HELD, OMA work)

9 Determining Location Example: DHCP for Location or DHCPINFORM [MAC=00:11:20:9d:a0:03] request response DHCPACK [option=0:us:1:ny:2:new YORK: 3:NEW YORK:6:AMSTERDAM:19:1214] DHCP Server

10 Determining Location Example: HELD (or similar proposals) Application layer protocol Useful if legacy equipment does not support location extensions (e.g., DHCP extensions in a DSL environment) What is PIDF-LO?

11 PIDF-LO Presence Information Data Format (PIDF) is an XML-based format for presence Extends PIDF to accommodate two new elements: Location-Info Encapsulates a location information GML 3.0 <feature.xsd> schema is mandatory-to-implement for all GEOPRIV-compliant applications Also defines an optional civil location format Usage-rules Used to indicate privacy preferences PDIF already contains a number of attributes: Placetype, presentity identity, status (busy, idle, ),. Most of the them are used in the presence environment (and are optional)

12 Abbreviated PIDF-LO Example <presence entity= > <tuple id= sg89ae > <status> <geopriv> <location-info> <gml > </gml> </location-info> <usage-rules> <retention-expiry/> <retransmission-allowed/> <note-well> </note-well> </usage-rules> </geopriv> </status> </tuple> </presence>

13 Basic GML Geometries Point: LineString: Linear Ring:

14 More Shares Arc Band <<GML code too long>> Polygon Start Angle Stop Angle outerboundaryis innerboundaryis

15 Civic Location Example (non-gml based) <gp:location-info> <cl:civiladdress> <cl:country>us</cl:country> <cl:a1>new York</cl:A1> <cl:a3>new York</cl:A3> <cl:a6>broadway</cl:a6> <cl:hno>123</cl:hno> <cl:loc>suite 75</cl:LOC> <cl:pc> </cl:pc> </cl:civiladdress> </gp:location-info>

16 Determining Location Security DHCP provides configuration information to the end host (not only distribute location info) DHCP is very weak on security and contains a lot of vulnerabilities See draft-ietf-dhc-v4-threat-analysis-02.txt RFC 3118 ( Authentication for DHCP Messages ) assumes a preshared security association between the DHCP client and the DHCP server. Turned out to be non-realistic assumption. Similar threats exist with other location determination solutions.

17 Work Split IETF work worries about emergency call, routing and location information Other organizations need to deal with an additional tough requirement: Network access without authentication (SIM-less emergency calls) Network access with authentication (but by skipping authorization) Examples: 3GPP Wimax

18 Mobility Environment Location by Value vs. Location by Value Problem: Location Inaccurate Obtaining location information only during network attachment Location info might be consumed later. Solution sketch: LIS creates a PIDF-LO and a reference to it. Reference is sent to the end host Subscription to the reference with information about event reduction is provided Security Challenge: Prevent unauthorized access to location information SUBSCRI BE NOTIFY (locationuri) (PIDF-LO)

19 Identifying an Emergency Call Purpose For UA : To send caller s location information For Proxies: To handle the emergency call specially For Mapping Protocol: To resolve to PSAP URI Emergency Identifier (Emergency Service URN) Service URN: identifies a generic service, not a specific resource For emergency: urn:service:sos urn:service:sos.ambulance urn:service:sos.fire urn:service:sos.police Can be used in request URI and To header. Security Challenge: Dial Strings (Emergency Numbers) Denial of Service: Marking calls as emergency calls

20 Emergency Dial Strings Dial Strings vs. Emergency identifiers Dial strings are entered by user Additional aspect: Configuration of dial strings important to map them to the emergency identifier Different emergency dial strings different in countries (e.g., 911 for North America, 112 for Europe) some countries uses separate numbers for ambulance/police/fire Required to support both home and visited emergency dial strings e.g., for an American traveler who is visiting Europe, both 911 and 112 should be recognized as emergency For the home emergency dial strings: User can set his/her home country through configuration. In initial time, UA gets the home emergency dial strings using mapping protocols. For the visited emergency dial strings: Whenever current location is changed, UA gets the visited emergency dial strings using mapping protocols. Security Challenges: Automatic configuration of dial strings

21 Finding the Correct PSAP Which PSAP should the call go to? Usually to the PSAP that covers the area Sometimes to a backup PSAP If no location, then default PSAP Standardization in progress: LoST: A Location-to-Service Translation Protocol PSAP determination is a mapping problem:

22 LoST (Location-to-Service Translation) For mapping a service identifier and location information to PSAP URL Supports both civic and geo location information Underlying transport mechanism in discussion (SOAP, UDP, HTTP) Security Challenges: Server authentication, integrity, confidentiality <mapping> <request> <operation>recurse</operation> <service>urn:service:sos</service> <gp:location-info> <cl:civicaddress> <cl:country>us</cl:country> <cl:a1>ny</cl:a1> <cl:a3>new York</cl:A3> <cl:a6>amsterdam</cl:a6> <cl:hno>1214</cl:hno> </cl:civicaddress> </gp:location-info> </request> </mapping> request response <mapping> <response expires=" t01:53:33.396z"> <displayname>new York City PSAP</displayName> <uri>sip:psap_ny@irt.cs.columbia.edu</uri> <civicmatch> <gp:location-info> <cl:civicaddress> <cl:country>us</cl:country> <cl:a1>ny</cl:a1> <cl:a3>new York</cl:A3> <cl:a6>amsterdam</cl:a6> <cl:hno>1214</cl:hno> </cl:civicaddress> </gp:location-info> </civicmatch> </response> </mapping> LoST Server

23 Emergency Call: Normal Case (UA recognition, UA resolution) (1) Location (2) Location + Service Identifier (3) PSAP URL + emergency dial-string Mapping Server (4) SOS caller dial emergency dialstring or (5) INVITE PSAP URL To: urn:service:sos <Location> SIP proxy (6) INVITE PSAP URL To: urn:service:sos <Location> call taker push emergency button Security Challenges: Classical VoIP call security problems

24 SIP message for Location Info. INVITE urn:service:sos SIP/2.0 To: urn:service:sos Call-ID: Via: SIP/2.0/TCP :4064;rport Content-Type: multipart/mixed; boundary From: Contact: CSeq: 1 INVITE Content-Length: 1379 request line header fields =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 content-type: application/sdp Content-Transfer-Encoding: 8bit v=0 o=eddie IN IP s=sipc Call c=in IP t=0 0 m=audio RTP/AVP 0 3 m=video RTP 31 SDP =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 Content-Type: application/pidf+xml Content-Transfer-Encoding: 8bit <?xml version="1.0" encoding="iso "?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilloc" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="sip:calltaker_ny2@irt.cs.columbia.edu"> <tuple id="28185"> <status> <gp:geopriv> <gp:location-info> <cl:civiladdress> <cl:country>us</cl:country> <cl:a1>ny</cl:a1> <cl:a2>new york</cl:a2> <cl:a3>new york</cl:a3> <cl:a6>amsterdam</cl:a6> <cl:hno>1214</cl:hno> </cl:civiladdress> </gp:location-info> <gp:method>manual</gp:method> </gp:geopriv> </status> <contact priority="0.8">sip:eddie@ :5060</contact> <timestamp> t15:57:34-04:00</timestamp> </tuple> </presence> =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=-- PIDF-LO

25 Emergency Call: No Location from UA (UA recognition, Proxy resolution) Location Database (3) Location (4) Location + Service Identifier Mapping Server (5) PSAP URL (1) dial 911 or push emergency button SOS caller (2) INVITE urn:service:sos To: urn:service:sos SIP proxy (6) INVITE PSAP URL To: urn:service:sos <Location> call taker

26 Emergency Call: Backward Compatible (Proxy recognition, Proxy resolution) Location Server (3) Location (4) Location + Service Identifier Mapping Server (5) PSAP URL (1) dial 911 SOS caller (2) INVITE sip:911@domain INVITE PSAP URL (6) To: sip:911@domain SIP proxy To: urn:service:sos <Location> call taker

27 Distributed Mapping Database Security Challenges: Authorization (Access Control), DoS! "#

28 Layered Defense against (D)DoS PSAP is a potential target for DDoS attacks Server itself; or First responders Emergency personnel Example: Adversary places an emergency call and attaches the wrong location information. The typical solution, namely cryptography, cannot be applied in a number of cases.

29 Layered Defense against (D)DoS Security Goal: 1. Determine quality of the emergency call in real-time (for ranking) [does not mean that the call is malicious if various security checks cannot be performed] 2. Catch adversary (later; non real-time) (1) How to trace back the adversary? Depends how the adversary placed the emergency call: Authenticate emergency caller to PSAP: Might require a public key infrastructure Deployment concerns Performance concerns Asserted identities: Works with approach (1) (P-Asserted-ID) and with approach (2) if you have a separate identity provider (SAML like scheme) IP address: IP traceback mechanisms (2) How to determine trustworthiness of provided information? Signing location information provided by access network

30 What s Next? Finalize WG documents: Requirements draft-ietf-ecrit-requirements-09.t Security Threats draft-ietf-ecrit-security-threats-01.txt Service URN draft-ietf-ecrit-service-urn-03.txt Progress LoST Continue work in ECRIT architecture design team to define the big picture. WG rechartering to include work on BCP, ECRIT Arch., Mapping Arch. Coordination meeting with 3GPP about emergency services Meeting with other organizations to synchronize VoIP emergency work

31 Questions?