ESIF NGN technical issues LIS Recommendations

1
ESIF NGN technical issuesLIS Recommendations

• 6th June 2006

2
Revision Service-provider access-provider
decoupling and location integrity
3
Emergency N/W
VSP N/W
Voice Provider 1
SelectiveRouter
Voice Provider 2
Voice Provider 3
VSP is responsible for routing the call to the
correct S/RPSAP
PSAPs
ISP knows the user location
ISP N/W
Subscribers

• For emergency services to work in the VoIP
  world
• Location must be provided by ISPs
• VSPs must use ISP location information to route
  the call

4
NENA defined (i2) migratory architectureNote
boundaries of responsibility!
North American solution for VoIP 911
ISP
Emergency network
VSP
Location determination
Call routing and location delivery
Call Handling
Selective Router
CAMA
ISUP
IP
911
ESGW
CallServer
ALI
PAM
LIS
VPC
E2
Local
ALI
Geodetic Civil loc,n
ERDB
Global ESZboundary data
National
VDB
Civic addrMSAG validation
VPC VoIP Position CentreLIS Location
Identification Server
5
Answerability for location integrity is
challenged by VoIP

• In IP communications the End-Point is in charge.
  The End-Point can, may, and probably will provide
  location information in-band with an emergency
  call.
• How can location information provided by an
  End-Point be verified, validated and
  authenticated?
• Without explicit integrity requirements on
  location information the emergency network is
  left vulnerable to abuse.

6
Casual location spoofing
VPC
LOWall St
LIS
RouteManhattan PSAP
CallServer
LOWall St
ManhattanPSAP
LOWall St

• PROBLEM
• This means any user could send an LO to appear it
  is calling from a specific location (spoof that
  location).
• This means it will cause the call to be sent to
  the PSAP regardless of the actual location of the
  caller

7
Preventing casual location spoofingwith a signed
LO
VPC
X
LOLISWall St
LIS
RouteManhattan PSAP
LOLISWall St
CallServer
LOLISWall St
ManhattanPSAP
LOWall St

• A way to prevent users from sending arbitrary
  locations is to have the location information
  signed by the actual access network.
• The LIS provides the location but it also
  provides a signature object which can be checked
  at the VPC to determine whether this location was
  genuinely determined at that point in the
  network.
• A casually spoofed location can then be detected
  at the VPC.

8
Location Credentials (LC) Construction created
by the LIS
Location Credentials (LC)
Certificate
Expiry Time
Client-ID
Signature
Location Object (LO)
Private KeyEncrypt
Hash Value
The Certificate included with the credentials is
unique to the LIS, issued by a recognized
certificate authority so the LIS can be properly
identified. It contains the public key
information for that LIS that permits the key to
be decrypted. The LC may be delivered as a
separate VoIP signaling parameter or it could be
a defined parameter within the LO itself.
Hash Function
9
Global consistency is critical!1. Foreign VSP
subscriptions2. Roaming VSP subscribers
10
LIS protocol requirementsSource NENA VoIP -
Recommended Method(s) for Determining Location to
Support Emergency Calling Technical Information
Document (TID)
11

• Location Determination and Acquisition
• DA1 The access network shall provide a
  mechanism for determination and acquisition of
  location information, and support queries for
  location.
• DA2 The location estimate used shall be that
  associated with the physically (wire, fiber, air)
  connected network.
• DA3 Location may be requested at any time.
  Location information must be associated with the
  device at the time the location is requested.
  Location Integrity
• DA4 Location acquisition should be provided by
  a consistent method across all network
  configurations. Access independent protocol
• DA5 Location determination and acquisition
  mechanisms should be applicable to emergency
  calling, and may also be applicable to a wide
  range of value-added location-based services.
• DA6 Location determination and acquisition
  techniques shall support both NENA i2 and i3
  network architectures.
• DA7 (Location 1400-0100 from LTD WG i3 rqmts)
  When measurement based-location determination
  mechanisms fail, the most accurate location
  information available should be provided.
• DA8 Location determination and acquisition must
  provide minimal impact to call setup time in the
  event that location is not known ahead of time.
• DA9 Where a device is not location aware the
  network SHOULD have the ability to assert a
  location estimate on behalf of the device.
  Support a device-independent mode
• DA10 Location acquisition methods should not
  require modification of hardware/firmware in
  home-routers/modems. Restrict dependency to the
  access provider network and the VoIP device
  client
• DA11 A location determination method must exist
  that does not require network hardware
  replacement.
• Location Representation
• Rep1 Location information may be provided
  by-value or by-reference and the form is subject
  to the nature of the request.
• Rep2 Location determination and acquisition
  mechanisms MUST support all location information
  fields defined within a PIDF-LO.
• Rep3 Location acquisition mechanisms MUST allow
  for easy backwards compatibility as the
  representation of location information evolves.
  Best addressed with by-reference conveyance
• Rep4 All representations of location shall
  include the ability to carry altitude and/or
  floor designation. This requirement does not
  imply altitude and/or floor designation is always
  used or supplied.

12

• Location Security and Dependability
• LocSec1 Location information shall only be
  provided to authenticated and authorized network
  devices. The degree of authentication and
  authorization required may vary depending on the
  network.
• LocSec2 Location determination and acquisition
  methods should preserve privacy of location
  information, subject to local laws and
  regulations.
• LocSec3 The location or location estimate of a
  caller should be dependable. Location integrity
• LocSec4 The location acquisition protocol MUST
  support authentication of the Location
  Information Server, integrity protection of the
  Location Information, and protection against
  replay. Location integrity
• LocSec5 The location source shall be identified
  and should be authenticated. This includes
  manually entered location1.
• LocSec6 Where a location is acquired and cached
  prior to an emergency call, it SHOULD be
  refreshed at regular intervals to ensure that it
  is as current as possible, in the event location
  information cannot be obtained in real time.
  Addressable with location by-reference
• LocSec7 Where location by-reference is used the
  appropriate privacy policies MUST be implemented
  and enforced by the LIS operator.
• 1 Manual entry is not the preferred method.
  If the Location Information is configured into
  the Emergency Caller's Device by manual entry,
  such entry SHOULD require authentication and
  authorization of the person providing the entry.
  Allows the FCC first phase mandate to establish
  the baseline functionality with auto-location
  deployment occuring incrementally across the
  industry.

13
Using HELD and FLAP to meet the LIS requirements
14
Basic HELD messaging
IP/HTTPS
LIS
IP device / Client
HELD
LocationRequest(Type(Geodetic, PostalCivic))
Basic location request (an HTTP Get or Post)
LocationResponse( ResultCode, PIDF-LO)
LocationRequest( HW_at_, IP_at_, Type(Geodetic,
PostalCivic))
Formerly OBO location request but still
achievable with extentions
LocationResponse( ResultCode, PIDF-LO)
On behalf of
LocationRequest(Type(LocationURI))
Location URI requestlocation reference
LocationResponse( ResultCode, LocationURI)
15
Signed HELD request providing location integrity
IP/HTTPS
LIS
IP device / Client
HELD
Digital certificate
LocationRequest(Type(Geodetic, PostalCivic),
signed)
Signed location request
LocationResponse( ResultCode, SIGNED-PIDF-LO)
16
HELD assertion request supporting location
integrity by proxy of trust
IP/HTTPS
LIS
IP device / Client
HELD
Digital certificate
LocationRequest(Type(Geodetic, PostalCivic),
signed, MyPIDF-LO)
Asserted location request
LocationResponse( ResultCode, SIGNED-MyPIDF-LO)
MyPIDF-LO is the location offered by the client
and assertion tested by the LIS. In this example,
the assertion passes and the offered location is
signed by the LIS
17
Location assertion example
Assert(Rm7, Bldg 39, CampusAddr), (CampusAddr)
PASS
CampusLIS
ProviderLIS
HELD assertion request/response
Digital certificate
Operatornetwork
Rm7, Bldg 39, CampusAddr
Signed-PIDF-LO(Rm7, Bldg 39, CampusAddr)
Broadband provider link
Campus Address
Internet

• Scenario
• Client IP device on campus requests signed
  location from campus LIS
• Campus LIS determines building and room number
• Campus LIS performs assertion request to
  Internet provider LIS with client ID included in
  LO
• Internet provider LIS asserts the offered
  location and test passes
• Provider LIS signs the campus LIS location
  clientID
• Signed LO passed back to client IP device via
  campus LIS
• IP device provides location to application of
  interest

Application
18
Location measurement

• Location measurement involves determining the
  value of a number of parameters associated with
  the network connection in use by the IP device.
• Since devices will typically connect to a network
  using some form of link, the parameters will
  often be layer 2 information directly associated
  with the physical link in use by the device
  though not always
• Typical layer 2 pieces of information are the
  Ethernet switch port the device is connected to
  or the identity of a wireless access point the
  device is using.
• Alternatively, the permanent virtual circuit
  (PVC) identifier on the ATM aggregation of a DSL
  network may be measured even though it is
  physically separate from the copper pair or DSLAM
  connections of the physical link.
• Measurements taken from access networks need to
  be uniquely associated with the IP device in
  question and this association will often, if not
  always, be able to be done against the IP address
  of the device or terminating equipment.
• A common framework for access networks to
  transfer measurement information to a location
  determination entity is required.
• The XML based flexible LIS-ALE protocol (FLAP)
  is designed for this purpose

19
LIS-ALE architecture
20
LIS-ALE Network Model
21
FLAP Hierarchical definitionsTechnology
specific ALE capabilities
FLAPBase XML Schema
Etc.
Ethernet switch
WiFi AccessPoint
WiMAXBase Station
DSL Aggregator
CableHead End
22
Implementation examplesSee NENA VoIP -
Recommended Method(s) for Determining Location to
Support Emergency Calling Technical Information
Document (TID) for more examples and technical
details.
23
Example WiMax Network Controller ALE
NetworkController
IP
ALE
FLAP

• WiMax extension schema
• Terminal definition
• MAC address
• IP address
• Access definition extension
• BTS ID
• Vendor X extension schema
• Vendor X
• Product WAP-FamilyY-ModelZ
• Access definition extensions
• Channel info
• RoundTripTime
• RxLevel

LIS
WiMax BTS
Generic LIS record
Vendor X proprietary support LIS recordlocation
is determined by an algorithm which is a function
of RF signal strength and timing measurements
supported by the WiMax manufacturer
24
Example 1 A DSL Aggregator ALE
Copper
PVC
IP
DSLAggregator
ALE
ISP/Enterprise
FLAP
ATM
LIS
Device
ATU-R
DSLAM

• DSL Aggregator extension schema
• Terminal definition
• IP address
• Access definition extension
• Aggregation device ID
• ATM port ID
• PVC ID

25
Example 3 Ethernet Switch ALE
Switch
IP
ALE
ALE
FLAP
ALE
LIS
Ethernet
Switches

• Ethernet switch extension schema
• Terminal definition
• MAC address
• IP address
• Access definition extension
• Switch ID
• Switch address
• Port ID
• VLAN ID

26
Example 4 802.11x Access Point ALE
Switch
WAP
IP
ALE
ALE
FLAP

• 802.11x AP extension schema
• Terminal definition
• MAC address
• IP address
• Access definition extension
• WAP ID
• Channel No
• Vendor X extension schema
• Vendor X
• Product WAP-FamilyY-ModelZ
• Access definition extensions
• RoundTripTime
• RxLevel

LIS
Generic LIS record
Vendor X proprietary support LIS recordlocation
is determined by an algorithm which is a function
of RF signal strength and timing measurements
supported by the AP manufacturer
27
Device based measurementsLIS co-operative

• In addition to the device being able to make
  measurements and perform location determination
  independently, it may be able to
• Provide the raw measurements to the LIS and leave
  the location determination process up to the LIS.
• e.g. the device takes wireless RF measurements
  but the LIS applies these measurements to base
  station data to calculate location
• Perform the location determination itself but
  need the assistance of the LIS as part of taking
  the necessary measurements
• E.g. the device can perform GPS but needs GPS
  assistance data. The LIS calculates approximate
  location and delivers assistance data
• The specific protocols used to perform such
  co-operative location determination can be
  outside the scope of HELD.
• E.g. SUPL for AGPS operations or SNMP for LLDP
  related measurement transfer
• HELD supports the exchange of a location
  capability parameter set between the device and
  the LIS
• The device volunteers its capabilties and the LIS
  responds with an indication of which may be
  supported
• Extension types are used in the HELD protocol to
  identify the specifics of these protocols

AppProtocol(LocationURI)
Application
GPSsatellites
3
AccessNetwork
4
LocReq(signed)
6
HELD
LIS
LocReq( Type(locationURI), LocCap(TechList())
1
LocReqResp(LocCap(SubTechList())
2
Selected Location Technology protocol
LocResp
Protocol specific message exchange
5
FLAP
ALE
5
28
Example LIS/ALE deployment Residential DSL
Premises
Regional access provider
ISP
Internet
GatewayLIS
HELD
HELD
RelayLIS
HELD
DSLAggregator
Internet
Radius
DSLAM
ATU-R
ATM
IP Devices
Radius
ALE
GeneralLIS
FLAP
ALE
Digital certificate
HELDMessages
Applications
29
Backup Slides
30
Step x Step defining the LO Signature
Emergency Call Routing using an LO
VPC
LOWall St
LIS
RouteManhattan PSAP
CallServer
LOWall St
ManhattanPSAP

• The Location Object (LO) is provided in the call
  setup information to the Call Server.
• The Call Server requests the VPC to instruct it
  as to which is the correct serving PSAP to route
  the call to for the location described in the LO.
• The VPC provides that routing information and the
  call is established

31
Casual location spoofing
VPC
LOWall St
LIS
RouteManhattan PSAP
CallServer
LOWall St
ManhattanPSAP
LOWall St

• PROBLEM
• This means any user could send an LO to appear it
  is calling from a specific location (spoof that
  location).
• This means it will cause the call to be sent to
  the PSAP regardless of the actual location of the
  caller

32
Data signing by private/public key encryption
Overview tutorial
ORIGIN
DESTINATION
Transmission
DATA
DATA XMT
Hash Function
Hash Function
Hash Value Xmt
Hash Value Original
Compare
Hash Val Decrypted
Private KeyEncrypt
Public KeyDecrypt
SIGNATURE
SIGNATURE
Mechanism by which the public key is known to
the destination is implementation dependent.
There are a number of options.
33
Preventing casual location spoofingwith a signed
LO
VPC
X
LOLISWall St
LIS
RouteManhattan PSAP
LOLISWall St
CallServer
LOLISWall St
ManhattanPSAP
LOWall St

• A way to prevent users from sending arbitrary
  locations is to have the location information
  signed by the actual access network.
• The LIS provides the location but it also
  provides a signature object which can be checked
  at the VPC to determine whether this location was
  genuinely determined at that point in the
  network.
• A casually spoofed location can then be detected
  at the VPC.

34
One time theft/copy of a signed LO
VPC
LOLISWall St
LIS
RouteManhattan PSAP
LOLISWall St
CallServer
One time copy of LOLIS
ManhattanPSAP
LOLISWall St

• PROBLEM
• If the signed LO is static (doesnt change), then
  it only needs to be copied once, and may be used
  any number of times even without an ongoing
  presence at the access network.
• A non-casual spoofer can obtain a single copy of
  the signed LO using any capture technique at the
  access network.
• While casual spoofers and nuisance callers may
  have been deterred, it will not stop a more
  determined person. Signed LO information could be
  readily distributed around the internet if it was
  never subject to change.

35
Preventing one time copy spoofingwith an signed
timestamped LO
VPC
X
LOLIS-CurrentTimeWall St
LIS
RouteManhattan PSAP
LOLIS-CurrentTimeWall St
CallServer
LOLIS-CurrentTimeWall St
ManhattanPSAP
LOLIS-OldTimeWall St

• In addition to signing the LO, the LIS could
  provide a timestamp associated with the
  signature. The signature would be on the
  timestamp as well as the LO.
• The VPC needs to be synchronized to some degree
  with the LIS (e.g. expiry based on UTC clock) but
  it can make a determination if an excessively old
  copy of the LO is being used.
• If the expiry time is brief enough, then it
  limits the usefulness of a one-time copy of a
  signed LO. Real-time copying of signed LO from
  the access network required for continued
  exploits.

36
Amplification using a real time feed of unexpired
signed timestamped LO
VPC
LOLIS-CurrentTimeWall St
LIS
RouteManhattan PSAP
LOLIS-CurrentTimeWall St
CallServer
Real time copy of LOLIS-CurrentTime
ManhattanPSAP
LOLIS-CurrentTimeWall St

• HOWEVER
• A determined attacker, or group of attackers,
  could establish a single device in a target area
  to provide a real time feed of the unexpired
  signed LO credentials.
• This may be a device owned by the attackers or be
  done by compromising a single users device in
  that area.
• Since the same unexpired signed LO would be valid
  for all users, an attack through amplification
  could be raised, where multiple calls are
  generated using the same location object.

37
Preventing amplification using a unique client ID
VPC
VPC can detect that one call already exists for
this ClientID
X
LOLIS-CurrentTime-ClientIDWall St
LIS
RouteManhattan PSAP
LOLIS-CurrentTime-ClientIDWall St
CallServer
Real time copy of LOLIS-CurrentTime-ClientID
ManhattanPSAP
LOLIS-CurrentTime-ClientIDWall St

• The LIS can generate a unique identifier for each
  device it provides an LO to. This unique
  identifier can also be signed by the LIS and be
  included in the LO.
• The VPC is then able to identify whether two call
  routing requests have arrived for the same device
  or whether a very large number of requests are
  coming for the same device.
• A more constrained form of amplification is still
  possible if the attacker utilizes different VSP
  Call Server operators where they know that those
  VSPs use different VPC operators. This still
  significantly limits the number of distinct calls
  and is more difficult to engineer.

38
Location Credentials (LC) Construction created
by the LIS
Location Credentials (LC)
Certificate
Expiry Time
Client-ID
Signature
Location Object (LO)
Private KeyEncrypt
Hash Value
The Certificate included with the credentials is
unique to the LIS, issued by a recognized
certificate authority so the LIS can be properly
identified. It contains the public key
information for that LIS that permits the key to
be decrypted. The LC may be delivered as a
separate VoIP signaling parameter or it could be
a defined parameter within the LO itself.
Hash Function
39
Convergence architecture bridging the LIS into
3GPP and OMA SUPL

• IP device (UE) provides network recognizable
  verinym (MSISDN) or pseudonym (IMEI etc) for 3GPP
  network compatibility
• This optional tag element is ignored by LIS in
  other access network types (a bridging correlator
  supports convergence)
• LIS can select SGSN vs SLP based on IP_at_ ranges
  allocated at different access points
• LIS converts cellular geo loc to GEOPRIV
  representation
• LIS provides location URI and can re-query
  SGSN/SLP at any time
• So LIS incorporates thin GMLC and SLC
  functionality
• The IMS can continue to utilise GMLC and SLP
  direct interfaces when users are on-net
• IMS knows how to query a LIS and therefore can
  also now provide service to off-net users
• Subscribers can access their other foreign
  applications and obtain service in the same way
  as when using, say, DSL