Network Working Group H. Tschofenig
Internet-Draft Siemens
Intended status: Informational H. Schulzrinne
Expires: March 2, 2007 Columbia U.
August 29, 2006
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
Requirements
draft-tschofenig-geopriv-l7-lcp-ps-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 2, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 1]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Abstract
This document provides a problem statement and lists requirements for
a GEOPRIV Layer 7 Location Configuration Protocol. This protocol
aims to allow an end host to obtain location information, by value or
by reference, from a Location Information Server (LIS) that is
located in the access network. The obtained location information can
then be used for a variety of different protocols and purposes. For
example, it can be used as input to the Location-to-Service
Translation Protocol (LoST) or to convey location within SIP to other
entities.
Disclaimer: This document represents the current status of the
discussions at the Geopriv-L7 design team and does not necessarily
reflect the opinion of every design team participant.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5
3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9
4. Discovery of the Location Information Server . . . . . . . . . 11
5. Identifier for Location Determination . . . . . . . . . . . . 13
6. Location-by-Reference and Location Subscriptions . . . . . . . 17
7. Preventing Faked Location based DoS Attacks . . . . . . . . . 19
7.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 19
7.2. Discussion about Countermeasures . . . . . . . . . . . . . 19
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Capabilities of the Adversary . . . . . . . . . . . . . . 25
9.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 2]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
1. Introduction
This document provides a problem statement and lists requirements for
a GEOPRIV Layer 7 Location Configuration Protocol. The protocol has
two purposes:
o It is used to obtain location information from a special node,
called the Location Information Server (LIS).
o It enables the end host to obtain a reference to location
information. This reference can take the form of a subscription
URI, such as a SIP presence URI, an HTTP/HTTPS URI, or any others.
The need for these two functions can be derived from the scenarios
presented in Section 3.
This document splits the problem space into separate parts and
discusses them in separate subsections. Section 4 discusses the
challenge of discovering the Location Information Server in the
access network. Section 5 compares different types of identifiers
that can be used to retrieve location information. The concept of
subscription URIs is described in Section 6. Digitally signing
location information and the perceived benefits are covered in
Section 7. A list of requirements for the GEOPRIV Layer 7 Location
Configuration Protocol can be found in Section 8. This work is
heavily influenced by security considerations. Hence, almost all
sections address security concerns. A list of desired security
properties can be found in Section 9 together with a discussion about
possible threat models.
This document does not describe how the access network provider
determines the location of the end host.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 3]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1],
with the qualification that unless otherwise stated these words apply
to the design of the GEOPRIV Layer 7 Location Configuration Protocol.
We also use terminology from [2] and [3].
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 4]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
3. Scenarios
The following network types are within scope:
o DSL/Cable networks, WiMax-like fixed access
o Airport, City, Campus Wireless Networks, such as 802.11a/b/g,
802.16e/Wimax
o 3G networks
o Enterprise networks
We illustrate a few examples below.
3.1. Fixed Wired Environment
The following figure shows a DSL network scenario with the Access
Network Provider and the customer premises. The Access Network
Provider operates link and network layer devices (represented as
Node) and the Location Information Server (LIS).
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 5]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
+---------------------------+
| |
| Access Network Provider |
| |
| +--------+ |
| | Node | |
| +--------+ +----------+ |
| | | | LIS | |
| | +---| | |
| | +----------+ |
| | |
+-------+-------------------+
| Wired Network
<----------------> Access Network Provider demarc
|
+-------+-------------------+
| | |
| +-------------+ |
| | NTE | |
| +-------------+ |
| | |
| | |
| +--------------+ |
| | Device with | Home |
| | NAPT and | Router |
| | DHCP server | |
| +--------------+ |
| | |
| | |
| +------+ |
| | End | |
| | Host | |
| +------+ |
| |
|Customer Premises Network |
| |
+---------------------------+
Figure 1: DSL Scenario
The customer premises consists of a router with a Network Address
Translator with Port Address Translation (NAPT) and a DHCP server as
used in most Customer Premises Networks (CPN) and the Network
Termination Equipment (NTE) where Layer 1 and sometimes Layer 2
protocols are terminated. The router in the home network (e.g.,
broadband router, cable or DSL router) typically runs a NAPT and a
DHCP server. The NTE is a legacy device and in many cases cannot be
modified for the purpose of delivering location information to the
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 6]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
end host. The same is true of the device with the NAPT and DHCP
server.
It is possible for the NTE and the home router to physically be in
the same box, or for there to be no home router, or for the NTE and
end host to be in the same physical box (with no home router). An
example of this last case is where Ethernet service is delivered to
customers' homes, and the Ethernet NIC in their PC serves as the NTE.
Current Customer Premises Network (CPN) deployments frequently show
the following characteristics:
1. CPE = Single PC
1. with Ethernet NIC [PPPoE or DHCP on PC]; there may be a
bridged DSL or cable modem as NTE, or the Ethernet NIC might
be the NTE
2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC]
Note that the device with NAPT and DHCP of Figure 1 is not
present in such a scenario.
2. One or more hosts with at least one router [DHCP Client or PPPoE,
DHCP server in router; VoIP can be soft client on PC, stand-alone
VoIP device, or Analog Terminal Adaptor (ATA) function embedded
in router]
1. combined router and NTE
2. separate router with NTE in bridged mode
3. separate router with NTE [NTE/router does PPPoE or DHCP to
WAN, router provides DHCP server for hosts in LAN; double NAT
The majority of fixed access broadband customers use a router. The
placement of the VoIP client is mentioned to describe what sorts of
hosts may need to be able to request location information. Soft
clients on PCs are frequently not launched until long after bootstrap
is complete, and are not able to control any options that may be
specified during bootstrap. They also cannot control whether a VPN
client is operating on the PC.
3.2. Moving Network
An example of a moving network is a "WIMAX-like fixed wireless"
scenario that is offered in several cities, like New Orleans, Biloxi,
etc., where much of the communications infrastructure was destroyed
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 7]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
due to a natural disaster. The customer-side antenna for this
service is rather small (about the size of a mass market paperback
book) and can be run off battery power. The output of this little
antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this
Ethernet jack. The user would then run a PPPoE client to connect to
the network. Once the network connection is established, the user
can run a SIP client on the laptop.
The network-side antenna is, for example, connected through ATM to
the core network, and from there to the same BRASs that serve regular
DSL customers. These Broadband Remote Access Servers (BRASs)
terminate the PPPoE sessions, just like they do for regular DSL.
The laptop and SIP client are, in this case, unaware that they are
"mobile". All they see is an Ethernet connection, and the IP address
they get from PPPoE does not change over the coverage area. Only the
user and the network are aware of the laptop's mobility.
Further examples of moving networks can be found in busses, trains,
airplanes.
Figure 2 shows an example topology for a moving network.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 8]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
+--------------------------+
| Wireless |
| Access Network Provider |
| |
| +----------+|
| +-------+ LIS ||
| | | ||
| +---+----+ +----------+|
| | Node | |
| | | |
| +---+----+ |
| | |
+------+-------------------+
| Wireless Interface
|
+------+-------------------+
| | Moving Network |
| +---+----+ |
| | NTE | +--------+ |
| | +---+ Host | |
| +-+-----++ | B | |
| | \ +--------+ |
| | \ |
|+---+----+ \ +---+----+ |
|| Host | \ | Host | |
|| A | \+ B | |
|+--------+ +--------+ |
+--------------------------+
Figure 2: Moving Network
3.3. Wireless Access
Figure 3 shows a wireless access network where a moving end host
obtains location information or references to location information
from the LIS. The access equipment us, in many cases, link layer
devices. This figure represents a hotspot network found in hotels,
airports, coffee shops.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 9]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
+--------------------------+
| Access Network Provider |
| |
| +----------+|
| +-------| LIS ||
| | | ||
| +--------+ +----------+|
| | Access | |
| | Point | |
| +--------+ |
| | |
+------+-------------------+
|
+------+
| End |
| Host |
+------+
Figure 3: Wireless Access Scenario
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 10]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
4. Discovery of the Location Information Server
When an end host wants to retrieve location information from the LIS
it first needs to discover it. Based on the problem statement of
determining the location of the end host, which is known best by
entities close to the end host itself, we assume that the LIS is
located in the access network. Several procedures have been
investigated that aim to discovery the LIS in such an access network.
DHCP-based Discovery:
In some environments the Dynamic Host Configuration Protocol might
be a good choice for discovering the FQDN or the IP address of the
LIS. In environments where DHCP can be used it is also possible
to use the already defined location extensions. In environments
with legacy devices, such as the one shown in Section 3.1, a DHCP
based discovery solution is not possible.
DNS-based Discovery:
With this idea the end host obtains its public IP address (e.g.,
via STUN [4]) in order to obtain its domain name (via the usual
reverse DNS lookup). Then, the SRV or NAPTR record for that
domain is retrieved. This relies on the user's public IP address
having a DNS entry.
Redirect Rule:
A redirect rule at a device in the access network, for example at
the AAA client, will be used to redirect the Geopriv-L7 signalling
messages (destined to a specific port) to the LIS. The end host
could then discover the LIS by sending a packet to almost any
address (as long it is not in the local network). The packet
would be redirected to the respective LIS being configured. The
same procedure is used by captive portals whereby any HTTP traffic
is intercepted and redirected.
Multicast Query:
An end node could also discover a LIS by sending a multicast
request to a well-known address. An example of such a mechanism
is multicast DNS (see [5] and [6]).
The LIS discovery procedure raises deployment and security issues.
When an end host discovers a LIS,
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 11]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
1. it does not talk to a man-in-the-middle adversary, and
2. it needs to ensure that the discovered entity is indeed an
authorized LIS.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 12]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
5. Identifier for Location Determination
The LIS returns location information to the end host when it receives
a request. Some form of identifier is therefore needed to allow the
LIS to determine the current location of the target or a good
approximation of it.
The chosen identifier needs to have the following properties:
Ability for end host to learn or know the identifier:
The end host MUST know or MUST be able to learn the identifier
(explicitly or implicitly) in order to send it to the LIS.
Implicitly refers to the situation where a device along the path
between the end host and the LIS modifies the identifier, as it is
done by a NAT when an IP address based identifier is used.
Ability to use the identifier for location determination:
The LIS MUST be able to use the identifier (directly or
indirectly) for location determination. Indirectly refers to the
case where the LIS uses other identifiers locally within the
access network, in addition to the one provided by the end host,
for location determination.
Security properties of the identifier:
Misuse needs to be minimized whereby off-path adversary MUST NOT
be able to obtain location information of other hosts. A on-path
adversary in the same subnet SHOULD NOT be able to spoof the
identifier of another host in the same subnet.
The problem is further complicated by the requirement that the end
host should not be aware of the network topology and the LIS must be
placed in such a way that it can determine location information with
the available information. As shown in Figure 1 the host behind the
NTE/NAPT-DHCP device is not visible to the access network and the LIS
itself. In the DSL network environment some identifier used at the
NTE is observable for by the LIS/access network.
The following list discusses frequently mentioned identifiers and
their properties:
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 13]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Host MAC address:
The host MAC address is known to the end system, but not carried
over an IP hop.
ATM VCI/VPI:
The VPI/VCI is generally only seen by the DSL modem. Almost all
routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35.
This VC is terminated at the DSLAM, which uses a different VPI/VCI
(per end customer) to connect to the ATM switch. Only the network
provider is able to map VPI/VCI values through its network. With
the arrival of VDSL, ATM will slowly be phased out in favor of
Ethernet.
Switch/Port Number:
This identifier is available only in certain networks, such as
enterprise networks, typically available via proprietary protocols
like CDP or, in the future, 802.1ab.
Cell ID:
This identifier is available in cellular data networks and the
cell ID might not be visible to the end host.
Authenticated User Identity:
In DSL networks the user credentials are, in many cases, only
known by the router and not to the end host. To the network, the
authenticated user identity is only available if a network access
authentication procedure is executed. In case of roaming it still
might not be available to the access network since security
protocols might provide user identity confidentiality and thereby
hide the real identity of the user allowing the access network to
only see a pseudonym or a randomized string.
Host Identifier:
The Host Identifier introduced by the Host Identity Protocol [7]
allows identification of a particular host. Unfortunately, the
network can only use this identifier for location determination if
the operator already stores an mapping of host identities to
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 14]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
location information. Furthermore, there is a deployment problem
since the host identities are not used in todays networks.
Cryptographically Generated Address (CGA):
The concept of a Cryptographically Generated Address (CGA) was
introduced by [8]. The basic idea is to put the truncated hash of
a public key into the interface identifier part of an IPv6
address. In addition to the properties of an IP address it allows
a proof of ownership. Hence, a return routability check can be
omitted.
Network Access Identifiers:
A Network Access Identifier [9] is only used during the network
access authentication procedure in RADIUS [10] or Diameter [11].
Furthermore, in a roaming scenario it does not help the access
network to make meaningful decisions since the username part might
be a pseudonym and there is no relationship to the end host's
location.
Unique Client Identifier
The DSL Forum has defined that all devices that expect to be
managed by the TR-069 interface be able to generate an identifier
as described in DSL Forum TR-069v2 Section 3.4.4. It also has a
requirement that routers that use DHCP to the WAN use RFC 4361
[12] to provide the DHCP server with a unique client identifier.
This identifier is, however, not visible to the end host with the
assumption of a legacy device like the NTE. If we assume that the
LTE can be modified then a number of solutions come to mind
including DHCP based location delivery.
IP Address:
The end host's IP address may be used for location determination.
This IP address is not visible to the LIS if the end host is
behind one or multipel NATs. This is, however, not a problem
since the location of a host that is located behind a NAT cannot
be determined by the access network. The LIS would in this case
only see the public IP address of the NAT binding allocated by the
NAT, which is the correct behavior. The property of the IP
address for a return routability check is attractive as well to
return location information only to a device that transmitted the
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 15]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
request. The LIS receives the request and provides location
information back to the same IP address. If an adversary wants to
learn location information from an IP address other than its own
IP address then it would not see the response message (unless he
is on the subnetwork or at a router along the path towards the
LIS) since the LIS would return the message to the address where
it came from.
On a shared medium an adversary could ask for location information
of another host using its IP address. The adversary would be able
to see the response message since he is sniffing on the shared
medium unless security mechanisms (such as link layer encryption)
is in place. With a network deployment as shown in Section 3.1
with multiple hosts in the Customer Premise being behind a NAT the
LIS is unable to differentiate the individual end points. For
WLAN deployments as found in hotels, as shown in as shown in
Section 3.3, it is possible for an adversary to eavesdrop data
traffic and subsequently to spoof the IP address in a query to the
LIS to learn more detailed location information (e.g., specific
room numbers). Such an attack might, for example, compromise the
privacy of hotel guests. Note that DHCP would suffer from the
same problem here unless each node uses link layer security
mechanism.
Return routability checks are useful only if the adversary does
not see the response message and if the goal is to delay state
establishment. If the adversary is in a broadcast network then a
return routability check alone is not sufficient to prevent the
above attack since the adversary will observe the response.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 16]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
6. Location-by-Reference and Location Subscriptions
In mobile wireless networks it is not efficient for the end host to
periodically query the LIS for up-to-date location information.
Furthermore, the end host might want to delegate the task of
retrieving and publishing location information to a third party, such
as a presence server. Finally, in some deployments the network
operator might not want to make location information available to the
end hosts.
These usage scenarios motivated the introduction of the location-by-
reference concept. Depending on the type of reference, such as HTTP/
HTTPS or SIP presence URI, different operations can be performed.
While an HTTP/HTTPS URI can be resolved to location information, a
SIP presence URI provides further benefits from the SUBSCRIBE/NOTIFY
concept that can additionally be combined with location filters [13].
Figure 4 shows the assumed communication model:
+--------+ Dereferencing +-----------+
| | Protocol (3) | |
| LIS +---------------+ Location |
| | | Recipient |
+---+----+ | |
| +----+------+
| --
| Geopriv-L7 --
| Protocol --
| (1) ---
| -- Geopriv
| --- Using (e.g.,SIP)
| -- Protocol
+----+-----+ -- (2)
| Target / +--
| End Host |
+----------+
Figure 4: Communication Model
Note that there is no requirement for using the same protocol in (1)
and (3).
The following list describes the location subscription idea:
1. The end host discovers the LIS.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 17]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
2. The end host sends a request to the LIS asking for a location-by-
reference, as shown in (1) of Figure 4.
3. The LIS responds to the request and includes a location object
together with a subscription URI.
4. The Target puts the subscription URI into a SIP message as
described in [14] forwards it to a Location Recipient, as shown
in (2) of Figure 4. The Location Recipient subscribes to the
obtained subscription URI (see (3) of Figure 4) and potentially
uses a location filter (see [13]) to limit the notification rate.
5. If the Target moves outside a certain area, indicated by the
location filter, then the Location Recipient will receive a
notification.
Note that the Target may also act in the role of the Location
Recipient whereby it would subscribe to its own location information.
For example, the Target obtains a subscription URI from the
Geopriv-L7 protocol. It subscribes to the URI in order to obtain its
currently location information, which then serves as input to a LoST
query (see [15]) in order to acquire the service boundary (e.g., PSAP
boundary). The service boundary indicates the region where the
device can move without the need to re-query since the returned
answer remains unchanged. The Target uses this service boundary to
location filters an updates the subscription. If the Target moves
outside a certain area, indicated by the location filter, it will
receive a notification and knows that re-querying LoST to obtain a
new service boundary is necessary.
For location-by-reference, the LIS needs to maintain a list of
randomized URIs for each host, timing out these URIs after the
reference expires. References need to expire to prevent the
recipient of such a URL from being able to (in some cases)
permanently track a host. Furthermore, this mechanism also offers
garbage collection capability for the LIS.
Location references must prevent adversaries from obtaining the
Target's location. There are at least two approaches: The location
reference contains a random component and allows any holder of the
reference to obtain location information. Alternatively, the
reference can be public and the LIS performs access control via a
separate authentication mechanism, such as HTTP digest or TLS client
side authentication, when resolving the reference to a location
object.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 18]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
7. Preventing Faked Location based DoS Attacks
A security threat is described in Section 7.1 and countermeasures are
discussed in Section 7.2.
7.1. Security Threat
Consider an end host that wants to act maliciously and creates its
own location object with faked location information and uses this
information in a subsequent SIP communication. In case of an
emergency call the other communication partner, the Public Safety
Answering Point (PSAP) operator, would use the information
potentially without having a further possibility to verify the
received location information. Emergency personnel would be sent to
the indicated location noticing that there is no incident.
Hence, the PSAP operator, and the Location Recipient in general,
would like to ensure that the provided location information is
genuine, accurate and fresh to avoid taking wrong actions, such as
dispatching emergency personnel to a wrong location.
There seems to be a need for preventing location forgery, replay and
substitution attacks, which are all forms of sending a location which
is deliberately not that of the end host. As shown below, various
forms of countermeasures are possible to mitigate these attacks.
Although some aspects are within the scope of the Geopriv-L7 Location
Configuration Protocol (LCP), which is between a LIS and an Target,
some aspects refer to other protocols, as shown in Figure 4. For
example, in an emergency call, the PSAP (as a Location Recipient)
wishes to verify that the location is indeed that of the calling
party. Further, the Geopriv-L7 LCP is not the only protocol that
could be used by an end host to acquire its location. Therefore, the
topic of signatures on the location information was deemed out of
scope. The subsequent discussion about countermeaures aims to
capture the state of the discussions and illustrates the complexity
in the overall design.
7.2. Discussion about Countermeasures
The goal of the above-described mechanism is to prevent prank calls
and, in case of emergency services, unnecessary first-responder
dispatch. As such, it is a mechanism to reduce the vulnerability of
denial of service attacks. The benefit of a digital signature
created by the LIS and covering the location information (plus some
other fields) is to treat a missing or invalid signature as suspect
during the call. The call would be treated differently in the sense
that more questions might be asked (if an interaction with a human
person is possible). In case of emergency services, the call might
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 19]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
get ranked differently if certain criteria are not fulfilled and if
the PSAP operator is confronted with a massive amount of calls
without the possiblity to respond to all of them.
7.2.1. Signed Location Information
One of the proposed countermeasures is to sign location information
by the LIS before it is sent to the end host whereby the signed
location information is verified by the final Location Recipient
rather than the Target. This prevents the Target from tampering with
the received location information since the digital signature would
become invalid. The Location Recipient would be able to verify the
source of the location information. Since the number of nodes that
may play the role of a Location Recipient is large a public key based
infrastructure is necessary.
This solution approach is challenging when a PIDF-LO [16] has to be
signed (instead of location information only) since the PIDF-LO
contains more than just location information, such as "entity"
attribute of the 'presence' element, and usage-rules (e.g.,
'retransmission-allowed', 'retention-expires', 'ruleset-reference',
'note-well').
The value for the "entity" attribute of the 'presence' element is, in
many cases, not known to the L2/L3 provider. If the LIS signs some
layer-2/layer-3 (e.g., PPP/RADIUS/NAI) identity as entity URI, it
will unlikely be the SIP URI.
To prevent adversaries from reusing an eavesdropped a signed location
object it is necessary to include additional information when
generating the digital signature. For example, a timestamp and a
validity field are useful to prevent certain replay attacks.
Furthermore, the "entity" attribute may be included in the digital
signature of a PIDF-LO with the following semantic: When using the
signed location object (e.g., in SIP or another higher layer
protocol), the Target needs to authenticate to the Location Recipient
using the same identity carried in the "entity" attribute of the
'presence' element of the signed PIDF-LO. Using SIP, for example, a
SIP proxy server could assert the entity URI corresponding to the
Target using the SIP identity mechanism.
Including the layer 7 identity into the "entity" attribute of the
'presence' element represents a privacy problem since the access
network provider can now see an identity that is in use. Hence, the
LIS and possibly unauthorized listeners (if there's no privacy
protection) find out where the L7 entity is located, rather than just
the location information.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 20]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
With regard to the ability for an adversary to replay eavesdrop a
signed location object, consider the following two approaches:
1. A signed PIDF-LO with the L7 identity included, conveyed without
confidentiality protection from the Target to the Location
Recipient, and
2. A signed PIDF-LO, without the L7 identity, conveyed with
confidentiality protection from the Target to the Location
Recipient.
Note that in both cases confidentiality protection for the
communication between the LIS and the Target is provided. (2) has the
same security properties as (1) in terms of the ability of somebody
else to steal and re-use the PIDF-LO ("location theft") (assuming the
Location Recipient and the Target are honest). Different attributes
can be included in the signature and in the best case no other party
can reuse the signed location object.
7.2.2. Authenticated Calls
In many cases, authenticated calls, i.e., verifying the callers
identity, are at least as useful as location signing since it
establishes accountability for later prosecution.
If most of the legitimate calls are authenticated in some way, then
it is possible, under attack conditions only, to give "dubious" calls
lower priority or to have them go through some sort of turing test.
As an example, PSAP operators do not want to reject emergency calls
regardless of how they look like, but if the alternative is wasting
90% of the resources on bogus calls (and thus leaving many legitimate
callers stranded) and not handling the unlucky unauthenticated, the
expected outcome is better if you can separate. This is the standard
"triage" model used in emergency medicine.
If somebody places a signed (known-third-party VSP-authenticated)
call, there is at least the possibility of catching a malicious
caller and the number of such calls is limited. Thus, there are only
legitimate calls left
o that use end system location determination (e.g., GPS, manual
configuration);
o that have no (known) VSP;
o that are not signed in some other way
In general, it is necessary to separate authentication from charging.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 21]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
There is no reason for tying authentication, authorization and
charging together for this particular context. For example,
certificates can be used, for example, for emergency service without
being subscribed to either a VSP or ISP.
7.2.3. Location-by-Reference
The concept of location-by-reference was described in Section 6. The
properties of location signing are very similar (if not equal) to the
properties of the location-by-reference concept when the Location
Recipient only authenticates the LIS (but not vice-versa). Bot
mechanisms allow the Location Recipient to authenticate the LIS (and
potentially the access network provider).
There are also a few drawbacks with the location signing and the
location-by-reference concept:
o Location signing has very limited utility if the number of signing
parties is very large
o Location signing has very limited utility for commercial
transactions. Commercial entities do not care whether a customer
lies about their location, as long as they can make you pay for
the service you asked for.
Authenticated calls also have their disadvantage since they require
end-host or end-user certificates, which creates a deployment burden,
unless mechanisms similar to SIP Identity [17] are used.
Furthermore, authenticated calls do not prevent attacks where the
location information was obtained unsecured from a LIS and an
adversary in the access network was able to tamper with the in-flight
location information.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 22]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
8. Requirements
The following requirements and assumptions have been identified:
Requirement L7-1: Identifier Choice
The LIS MUST be presented with a unique identifier of its own
addressing realm associated in some way with the physical location
of the end host.
An identifier is only appropriate if it is from the same realm as
the one for which the location information service maintains
identifier to location mapping.
Requirement L7-2: Mobility Support
The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
broad range of mobility from devices that can only move between
reboots, to devices that can change attachment points with the
impact that their IP address is changed, to devices that do not
change their IP address while roaming, to devices that
continuously move by being attached to the same network attachment
point.
Requirement L7-3: Layer 7 and Layer 2/3 Provider Relationship
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume a business or trust relationship between the
provider of application layer (e.g., SIP, XMPP, H.323) provider
and the access network provider operating the LIS.
Requirement L7-4: Layer 2 and Layer 3 Provider Relationship
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship
between the L2 and the L3 provider. The L3 provider operates the
LIS and needs to obtain location information from the L2 provider
since this one is closest to the end host. If the L2 and L3
provider for the same host are different entities, they cooperate
for the purposes needed to determine end system locations.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 23]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Requirement L7-5: Legacy Device Considerations
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST consider legacy residential NAT devices and NTEs in an DSL
environment that cannot be upgraded to support additional
protocols, for example to pass additional information through
DHCP.
Requirement L7-6: VPN Awareness
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that at least one end of a VPN is aware of the VPN
functionality. In an enterprise scenario, the enterprise side
will provide the LIS used by the client and can thereby detect
whether the LIS request was initiated through a VPN tunnel.
Requirement L7-7: Network Access Authentication
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume prior network access authentication.
Requirement L7-8: Network Topology Unawareness
The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume end systems being aware of the access network
topology. End systems are, however, able to determine their
public IP address(es) via mechanisms such as STUN [4] or NSIS
NATFW NSLP [18] .
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 24]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
9. Security Considerations
9.1. Capabilities of the Adversary
As common elsewhere, several kinds of attackers can be distinguished.
As always, Alice is the "good guy" and Trudy the attacker. Attackers
can be:
o off-path, i.e., it cannot see packets between Alice and the LIS;
o on-path, i.e., can see such packets.
On-path attackers may be:
o passive, i.e., can only observe;
o semi-active, i.e., can inject packets with a bogus IP address, but
cannot prevent the delivery of packets from the end system or
modify these packets;
o active, i.e., can inject and modify packets at will.
9.2. Threats
When the reference to location information is communicated to the
Location Recipient then on-path adversaries can eavesdrop the
signaling communication together with the reference. Furthermore,
the end-to-end communication might involve SIP proxies and they may
not be trustworthy. Hence, they can eavesdrop the reference and
misuse it (by resolving it).
Untrusted proxies that are involved in the communication lead to a
requirement for the Target to selectively grant access to already
known and trusted Location Recipients.
The following list presents threats specific to location information
handling:
Place-Shifting (PS):
Trudy pretends to be at an arbitrary location.
Time-Shifting (TS):
Trudy pretends to be at a location she was a while ago.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 25]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Location-Theft (LT):
Trudy observes Alice's location and replays it as her own location
object.
Location-Identity-Theft (LIT):
Trudy observes Alice's location and her identity (e.g., presence
identity) and replays it.
Location-Swapping (LS):
Trudy' and Trudy'', located at different locations, can collude
and swap location objects and pretend to be in each other's
location.
Table 1 shows the different threats and the applicability of proposed
countermeasures.
+----+----------+-----------+-----------+---------------+-----------+
| | Asserted | Timestamp | Encrypted | Authenticated | Location |
| | Location | | Location | Call | by |
| | | | | | Reference |
+----+----------+-----------+-----------+---------------+-----------+
| PS | X | - | - | Track | X |
| | | | | Offender | |
| | | | | | |
| TS | - | X | - | Track | Limits |
| | | | | Offender | Impact |
| | | | | | |
| LT | - | - | X | Track | - |
| | | | | Offender | |
| | | | | | |
| LI | - | - | X | - | - |
| T | | | | | |
| | | | | | |
| LS | - | Limits | - | Track | - |
| | | Impact | | Offender | |
+----+----------+-----------+-----------+---------------+-----------+
Table 1
Legend:
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 26]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
-: Functionality not necessary to accomplish the desired
functionality.
X: Functionality needed to prevent threat.
9.3. Requirements
The following requirements are placed on the location-by-value
approach:
o No conclusion was reached whether a PIDF-LO or just location
information has to be signed.
o No conclusion was reached whether location information should be
signed.
o No conclusion was reached what could be signed.
The following requirements are placed on the location-by-reference
approach:
o The reference MUST be valid for a limited amount of time.
o The reference MUST be hard to guess, i.e., it MUST contain a
cryptographically random component.
o The reference MUST NOT contain any information that identifies the
user, device or address of record
o The Location Recipient MUST be able to resolve the reference more
than once (i.e., there is no implicit limit on the number of
dereferencing actions).
o Possessing a reference to location information allows a Location
Recipient to repeately obtain the latest information about the
Target with the same granularity.
o The Target MUST be able to resolve the reference itself.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 27]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
10. IANA Considerations
This document does not require actions by IANA.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 28]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
11. Contributors
This contribution is a joint effort of the GEOPRIV Layer 7 Location
Configuration Requirements Design Team of the Geopriv WG. The
contributors include Henning Schulzrinne, Barbara Stark, Marc
Linsner, James Winterbottom, Martin Thomson, Rohan Mahy, Brian Rosen,
Jon Peterson and Hannes Tschofenig.
The design team members can be reached at:
Marc Linsner: mlinsner@cisco.com
Rohan Mahy: rohan@ekabal.com
Jon Peterson: jon.peterson@neustar.biz
Brian Rosen: br@brianrosen.net
Henning Schulzrinne: hgs@cs.columbia.edu
Barbara Stark: Barbara.Stark@bellsouth.com
Martin Thomson: Martin.Thomson@andrew.com
Hannes Tschofenig: Hannes.Tschofenig@siemens.com
James Winterbottom: James.Winterbottom@andrew.com
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 29]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
12. Acknowledgements
We would like to thanks the IETF GEOPRIV working group chairs, Andy
Newton, Allison Mankin and Randall Gellens, for creating this design
team. Furthermore, we would like thank Andy Newton for his support
during the design team mailing list, the Jabber chat conference and
the phone conference discussions. Finally, we would like to thank
Murugaraj Shanmugam for his draft review.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 30]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-12 (work in progress),
August 2006.
13.2. Informative References
[4] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[5] Aboba, B., "Link-local Multicast Name Resolution (LLMNR)",
draft-ietf-dnsext-mdns-47 (work in progress), August 2006.
[6] Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-06 (work in progress),
August 2006.
[7] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06
(work in progress), June 2006.
[8] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[9] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005.
[10] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[12] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
RFC 4361, February 2006.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 31]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
[13] Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in the Presence Information Document
Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-00 (work in progress),
March 2006.
[14] Polk, J. and B. Rosen, "Session Initiation Protocol Location
Conveyance", draft-ietf-sip-location-conveyance-03 (work in
progress), June 2006.
[15] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
draft-ietf-ecrit-lost-00 (work in progress), June 2006.
[16] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005.
[18] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in progress),
June 2006.
[19] Schulzrinne, H., "Common Policy: A Document Format for
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-11 (work in progress),
August 2006.
[20] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information",
draft-ietf-geopriv-policy-08 (work in progress), February 2006.
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 32]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 33]
Internet-Draft Geopriv L7 LCP; Problem Statement August 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tschofenig & Schulzrinne Expires March 2, 2007 [Page 34]