Emergency ServicesIAB Tech Chat28th 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

Example: Communication between emergency personnel

Citizen to Authority

Example: VoIP emergency call

Authorities

CitizenNote that some SDOs use the term “individuals” instead of “citizen”.

History

J F M A M J J A S O N D J F M A M J J A S O N D2004 2005

ECRIT BOF

1st ECRITWG

Meeting

IETF ECRIT

WG

1st ECRIT Interim Meeting

IETF#63

J F M A M J J A S O N D J F M A M J J A S O N D2006 2007

2nd ECRIT Interim Meeting

4th ECRIT WG

Meeting

IETF ECRIT

WG

5th ECRIT WG

Meeting

IETF#62IETF#61

2nd ECRITWG

Meeting

3rd ECRIT

WG Meeting

IETF#64

IETF#65 IETF#66

IETF ECRIT –

3GPP Workshop

1st SDO Emergency

Services Workshop

2nd SDO Emergency

Services Workshop

IETF#67 IETF#68

6th ECRIT WG

Meeting IETF ECRIT – IEEE

Workshop

7th ECRIT WG

Meeting

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.

The ECRIT Universe

ECRIT

GEOPRIV

SIP OGCRegulators

Open Geospatial Consortium (OGC)

NENA, TISPAN, EMTEL, ATIS3GPP, 3GPP2, IEEE, ITU-T, PacketCableDSL Forum, Wimax, OMA,TIA, OASIS,

Architectural Considerations

Last Mile, Inc. (Access Provider)

ISP, Inc. (Internet Service Provider)

VoIP, Inc. (Application Service Provider)Layer 7

Layer 2

Layer 3

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?

Determine Location

Emergency Call

Determine correct PSAP

IdentifyEmergencyCalls

Building Blocks

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)

Location Configuration

Determine Location

Emergency Call

Determine correct PSAP

IdentifyEmergencyCalls

Building Blocks

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

Identifying an Emergency Call

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

Emergency Numbers

Determine Location

Emergency Call

Determine correct PSAP

IdentifyEmergencyCalls

Building Blocks

Location-to-Service Translation (LoST)

Status: WGLC started

http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/

+Location Information

(PSAP) URI

Service Identifier

Service Number

Service Boundary

+

+

LoST Architecture

T1

(.us)

T2

(.de) T3

(.dk)

G

G

GG

G broadcast (gossip)T1: .us

T2: .de

resolver

seeker313 Westview

Leonia, NJ US

Leonia, NJ

sip:psap@leonianj.gov

tree guide

Determine Location

Emergency Call

Determine correct PSAP

IdentifyEmergencyCalls

Building Blocks

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.

Mapping Server

SIP proxy PSAP / Call Taker

(1) Location

Location + Service Identifier

(2)

PSAP URI + service number

(3)

INVITE PSAP URITo: urn:service:sos

<PIDF-LO>

(5)INVITE PSAP URITo: urn:service:sos

< PIDF-LO >

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

SOS caller

PSAP / Call Taker

Mapping Server

SIP proxySOS caller

(3) Location

Location + Service Identifier

(4)

PSAP URI

(5)

INVITE urn:service:sosTo: urn:service:sos

(2) INVITE PSAP URITo: urn:service:sos

<PIDF-LO Reference>

(6)

(1)

dial dialstring

Location Server

UA Recognition & Proxy Resolution

Assumes that SIP proxy is able to determine the end hosts location information.

This assumes a close relationship to the access network

PSAP / Call Taker

Mapping Server

SIP proxy

(3) Location

Location + Service Identifier

(4)

PSAP URI

(5)

INVITE sip:911@domainTo: sip:911@domain

(2) INVITE PSAP URITo: urn:service:sos<PIDF-LO Reference>

(6)(1)

dial dialstring

Location Server

Proxy Recognition & Proxy Resolution

End host does not understand emergency service concept.

Legacy support scenario

SOS caller

Challenges Security

Threat 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

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

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.

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

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:

1) It understands the concept of SIP-based emergency calls

OR

1) It tunnels all emergency traffic to someone that understands it.

Challenge: Business Models

RequestLocationReference

Location Reference

PSAPLocationServer @AccessNetwork

End Host

Dereference

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

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.