1 / 28

Emergency Services IAB Tech Chat

Emergency Services IAB Tech Chat. 28 th February 2007 Hannes Tschofenig. Outline. Introduction The Building Blocks Architectural Models Challenges How the IAB can help us. Introduction. Authority to Citizen Example: Cell broadcast for Tsunami warning Authority to Authority

flo
Download Presentation

Emergency Services IAB Tech Chat

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Emergency ServicesIAB Tech Chat 28th February 2007 Hannes Tschofenig

  2. Outline • Introduction • The Building Blocks • Architectural Models • Challenges • How the IAB can help us

  3. Introduction • 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 Note that some SDOs use the term “individuals” instead of “citizen”.

  4. J J F F M M A A M M J J J J A A S S O O N N D D 2006 2004 J J F F M M A A M M J J J J A A S S O O N N D D 2007 2005 History 1st ECRITWG Meeting 1st ECRIT Interim Meeting 2nd ECRITWG Meeting 3rdECRITWG Meeting ECRIT BOF IETF ECRIT WG IETF#61 IETF#62 IETF#63 IETF#64 IETF ECRIT – 3GPP Workshop 5th ECRIT WG Meeting 2nd ECRIT Interim Meeting 6th ECRIT WG Meeting IETF ECRIT – IEEE Workshop IETF ECRIT WG IETF#66 IETF#65 IETF#67 IETF#68 1st SDO Emergency Services Workshop 2nd SDO Emergency Services Workshop 4th ECRIT WG Meeting 7th ECRIT WG Meeting

  5. Links • Joint IETF ECRIT / 3GPP Emergency Services Workshop http://www.ietf-ecrit.org/3GPP-IETF-2006/ • SDO Emergency Services Coordination Workshop (ESW06)  http://www.emergency-services-coordination.info/2006/ http://www.emergency-services-coordination.info/2006/slides/ • IETF ECRIT / 3GPP / TISPAN Emergency Services Work http://www.shingou.info/twiki/bin/view/EmergencyServices/EmergencyTopics • Reviews by VoIP providers still ongoing.

  6. The ECRIT Universe NENA, TISPAN, EMTEL, ATIS 3GPP, 3GPP2, IEEE, ITU-T, PacketCable DSL Forum, Wimax, OMA, TIA, OASIS, ECRIT GEOPRIV Regulators SIP OGC Open Geospatial Consortium (OGC)

  7. Architectural Considerations Common point - The end device! • Two main questions: • Who knows the location of the end host? • What is the relationship between access network provider and application service provider? VoIP, Inc. (Application Service Provider) Layer 7 ISP, Inc. (Internet Service Provider) Layer 3 Last Mile, Inc. (Access Provider) Layer 2

  8. Building Blocks

  9. Location Configuration • Manual configuration • GPS • Link layer mechanisms (e.g., LLDP-MED, ongoing work in the IEEE) • DHCP (civic and geospatial) RFC 4776 for civic location information RFC 3825 for geodetic location information • Application layer protocols(e.g., Geopriv L7 LCP, OMA)

  10. Building Blocks

  11. Identifying an Emergency Call • Purpose • For UA : To indicate emergency call • For Proxies: To handle the emergency call specially • For Mapping Protocol: To resolve to PSAP URI • Emergency Identifier • draft-ietf-ecrit-service-urn-05.txt • Example: urn:service:sos Emergency Numbers

  12. Emergency Numbers • Emergency numbers vary in countries • Example: 911 for North America, 112 for Europe • some countries uses separate numbers for ambulance/police/fire • Required to support both home and visited emergency number • e.g., for an American traveler who is visiting Europe, both 911 and 112 should be recognized as emergency • Configuration of emergency numbers and dial strings important • Home Emergency Number: User can set his/her home country through device configuration. • Visited Emergency Number: Obtained via LoST

  13. Building Blocks

  14. Location-to-Service Translation (LoST) • Status: WGLC started • http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/ Location Information + Service Identifier Service Number + (PSAP) URI + Service Boundary

  15. LoST Architecture G tree guide G G G broadcast (gossip) T1: .us T2: .de G resolver T2 (.de) seeker 313 Westview Leonia, NJ US T3 (.dk) T1 (.us) Leonia, NJ  sip:psap@leonianj.gov

  16. Building Blocks

  17. Architectural Models • Model 1: Location Information is available to End Host • This allows UA recognition & UA resolution as well as UA recognition & Proxy resolution • Model 2: Reference to Location Information is available to End Host • Might translate to model 1 if end host is allowed to resolve the reference • Translates to model 3 if end host is not allowed to resolve the reference (but relaxes assumptions of model 3) • Model 3: Location Information is NOT available to End Host • Assumption: SIP intermediaries are in the access network (or have a very close relationship to them) • Proxy recognition & Proxy resolution is a subcase of this model.

  18. (2) Location + Service Identifier (1) Location (3) PSAP URI + service number PSAP / Call Taker (4) dial dialstring UA Recognition & UA Resolution • Location Information is provided by the access network. • IETF ECRIT preferred emergency service architecture • SIP Proxy is user’s preferred SIP provider. It may re-run LoST Mapping Server INVITE PSAP URI To: urn:service:sos <PIDF-LO> INVITE PSAP URI To: urn:service:sos < PIDF-LO> SOS caller (6) (5) SIP proxy

  19. PSAP / Call Taker UA Recognition & Proxy Resolution Location Server Mapping Server (5) (4) PSAP URI Location + Service Identifier (3) Location (6) INVITE PSAP URI To: urn:service:sos <PIDF-LO Reference> (1) (2) INVITE urn:service:sos To: urn:service:sos dial dialstring SOS caller SIP proxy • Assumes that SIP proxy is able to determine the end hosts location information. • This assumes a close relationship to the access network

  20. PSAP / Call Taker Proxy Recognition & Proxy Resolution Location Server Mapping Server (5) (4) PSAP URI Location + Service Identifier (3) Location (1) (2) INVITE sip:911@domain To: sip:911@domain INVITE PSAP URI To: urn:service:sos <PIDF-LO Reference> SOS caller (6) dial dialstring SIP proxy • End host does not understand emergency service concept. • Legacy support scenario

  21. Challenges • SecurityThreat model assumes that the end host is not trustworthy. • Location InformationToo many protocols to obtain location information are available. They also use different formats. • RegulatorsRegulators have a lot to say. Unfortunately, very little detailed guidance is available. • Business Models No unified architecture (too many cooks). Business models impacting architectural design

  22. Challenge: Security • Example security threats: “location spoofing”, prank calls, fraud • Countermeasures: • Real-Time Check: PSAP receives a call with faked location information. • Determine identity of adversary for later prosecution. • Aspects are discussed mostly in GEOPRIV WG since the solutions refer to protocols developed there. • Further reading: Overview Paper on Security (NetCri Workshop 2007)http://www.shingou.info/Emergency-Service-Security.pdf

  23. Challenge: Location Information • To accomplish interoperability in the Internet either the network or the end host need to implement all location configuration protocols. • Location information differ in the format and the functionality (e.g., OMA and OGC GML). • Maybe a job for the IAB liaison persons but might be too late already. • Alignment between IEEE and IETF GEOPRIV is quite good. • Architectural assumptions of some Location Configuration Protocols are not compatible; not only the format.

  24. Challenge: Regulators • So far no indication from the regulator side regarding • preference for one of the architectural models • confidentiality protection of emergency calls • unauthenticated network access • priority for emergency services( QoS and IEPREP-like mechanisms) • unauthenticated emergency call • requirements on network providers to disclose location information

  25. Example: Unauthenticated Network Access • Bob wants to make an emergency call • Assume he is not yet attached to a network. • Assume he has no credentials for this particular network. • Bob uses a special link layer attachment procedure to attach to the network without authentication and authorization. • Bob initiates the emergency call. • How does the access network know whether Bob is really making an emergency call or not just calling his friend for free? • Answer: • It understands the concept of SIP-based emergency calls OR • It tunnels all emergency traffic to someone that understands it.

  26. Challenge: Business Models Dereference PSAP Location Server @ Access Network Location Reference Request Location Reference End Host

  27. Challenge: Business Models • Location-by-reference itself is not a bad concept; but it can be misused • The problem appears if access network providers only want to make location only available to “authorized” entities. • Authorized could mean only to entities that have a business relationship with the access network provider. • Without location information location-based routing does not work. • If VoIP has to do location-based routing then it need create business contracts with access providers. • There are many VoIP providers and even more access providers  impractical solution

  28. How the IAB could help us • Interacts with other SDOs • “SDO Emergency Services Workshop” (April 2007) is only one event in the overall stream of activities • Help us to investigate security aspects of the emergency services architecture • Develop an IAB position on the IETF emergency service architecture • Provide input to the long ongoing GEOPRIV L7 LCP discussion • Help to educate regulators • Interact with PSAP operators (and regulators) regarding the public availability of PSAP boundary data. This is important for a robust global LoST architecture.

More Related