draft-ietf-geopriv-l7-lcp-ps-03.txt   draft-ietf-geopriv-l7-lcp-ps-04.txt 
Network Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: January 10, 2008 Columbia U. Expires: February 27, 2008 Columbia U.
July 9, 2007 August 26, 2007
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
Requirements Requirements
draft-ietf-geopriv-l7-lcp-ps-03.txt draft-ietf-geopriv-l7-lcp-ps-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008. This Internet-Draft will expire on February 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides a problem statement, lists requirements and This document provides a problem statement, lists requirements and
captures design aspects for a Geopriv Layer 7 Location Configuration captures design aspects for a Geopriv Layer 7 Location Configuration
Protocol L7 (LCP). This protocol aims to allow an end host to obtain Protocol L7 (LCP). This protocol aims to allow an end host to obtain
location information, by value or by reference, from a Location location information, by value or by reference, from a Location
Configuration Server (LCS) that is located in the access network. Information Server (LIS) that is located in the access network. The
The obtained location information can then be used for a variety of obtained location information can then be used for a variety of
different protocols and purposes. For example, it can be used as different protocols and purposes. For example, it can be used as
input to the Location-to-Service Translation Protocol (LoST) or to input to the Location-to-Service Translation Protocol (LoST) or to
convey location within SIP to other entities. convey location within SIP to other entities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5 3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5
3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9 3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9
4. Discovery of the Location Configuration Server . . . . . . . . 11 4. Discovery of the Location Information Server . . . . . . . . . 11
5. Identifier for Location Determination . . . . . . . . . . . . 13 5. Identifier for Location Determination . . . . . . . . . . . . 13
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
This document provides a problem statement, lists requirements and This document provides a problem statement, lists requirements and
captures design aspects for a Geopriv Layer 7 Location Configuration captures design aspects for a Geopriv Layer 7 Location Configuration
Protocol L7 (LCP). The protocol has two purposes: Protocol L7 (LCP). The protocol has two purposes:
o It is used to obtain location information (referred as "Location o It is used to obtain location information (referred as "Location
by Value" or LbyV) from a dedicated node, called the Location by Value" or LbyV) from a dedicated node, called the Location
Configuration Server (LCS). Information Server (LIS).
o It enables the Target to obtain a reference to location o It enables the Target to obtain a reference to location
information (referred as "Location by Reference" or LbyR). This information (referred as "Location by Reference" or LbyR). This
reference can take the form of a subscription URI, such as a SIP reference can take the form of a subscription URI, such as a SIP
presence URI, a HTTP/HTTPS URI, or another URI. The requirements presence URI, a HTTP/HTTPS URI, or another URI. The requirements
related to the task of obtaining a LbyR are described in a related to the task of obtaining a LbyR are described in a
separate document, see [4]. separate document, see [4].
The need for these two functions can be derived from the scenarios The need for these two functions can be derived from the scenarios
presented in Section 3. presented in Section 3.
For this document we assume that the GEOPRIV Layer 7 LCP runs between For this document we assume that the GEOPRIV Layer 7 LCP runs between
the end host (i.e., the Target in [1] terminology) acting as the LCP the end host (i.e., the Target in [1] terminology) and the LIS.
client and the Location Configuration Server acting as an LCP server.
This document is structured as follows. Section 4 discusses the This document is structured as follows. Section 4 discusses the
challenge of discovering the LCS in the access network. Section 5 challenge of discovering the LIS in the access network. Section 5
compares different types of identifiers that can be used to retrieve compares different types of identifiers that can be used to retrieve
location information. A list of requirements for the L7 LCP can be location information. A list of requirements for the L7 LCP can be
found in Section 6. found in Section 6.
This document does not describe how the access network provider This document does not describe how the access network provider
determines the location of the end host since this is largely a determines the location of the end host since this is largely a
matter of the capabilities of specific link layer technologies or matter of the capabilities of specific link layer technologies or
certain deployment environments. certain deployment environments.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], and "OPTIONAL" are to be interpreted as described in RFC 2119 [2],
with the qualification that unless otherwise stated these words apply with the qualification that unless otherwise stated these words apply
to the design of the GEOPRIV Layer 7 Location Configuration Protocol. to the design of the GEOPRIV Layer 7 Location Configuration Protocol.
The term Location Configuration Server (LCS) refers to an entity The term Location Information Server (LIS) refers to an entity
capable of determining the location of an end point and of providing capable of determining the location of a Target and of providing that
that location information, a reference to it, or both via the location information, a reference to it, or both via the Location
Location Configuration Protocol (LCP) to the requesting party, in Configuration Protocol (LCP) to the requesting party. In most cases
most cases to the end point itself (or to an authorized entity that the requesting party is the Target itself but it may also be an
acts on behalf of it). authorized entity that acts on behalf of it, such as a SIP proxy or
another LIS.
This document also uses terminology from [1] and [3]. This document also uses terminology from [1] (such as Target) and [3]
(such as Internet Access Provider (IAP), Internet Service Provider
(ISP), and Application Service Provider (ASP)).
With the term "Access Network Provider" we refer to the Internet
Access Provider (IAP) and the Internet Service Provider (ISP) without
further distinguishing these two entities as it is not relevant for
the purpose of this document. An additional requirements document on
LIS-to-LIS [5] shows scenario where the separation between IAP and
ISP is important.
3. Scenarios 3. Scenarios
This section describes a few network scenarios where the L7 LCP may This section describes a few network scenarios where the L7 LCP may
be used. Note that this section does not aim to exhaustively list be used. Note that this section does not aim to exhaustively list
all possible deployment environments. Instead we focus on the all possible deployment environments. Instead we focus on the
following environments: following environments:
o DSL/Cable networks, WiMax-like fixed access o DSL/Cable networks, WiMax-like fixed access
skipping to change at page 5, line 28 skipping to change at page 5, line 28
o Enterprise networks o Enterprise networks
We illustrate a few examples below. We illustrate a few examples below.
3.1. Fixed Wired Environment 3.1. Fixed Wired Environment
Figure 1 shows a DSL network scenario with the Access Network Figure 1 shows a DSL network scenario with the Access Network
Provider and the customer premises. The Access Network Provider Provider and the customer premises. The Access Network Provider
operates link and network layer devices (represented as Node) and the operates link and network layer devices (represented as Node) and the
LCS. LIS.
+---------------------------+ +---------------------------+
| | | |
| Access Network Provider | | Access Network Provider |
| | | |
| +--------+ | | +--------+ |
| | Node | | | | Node | |
| +--------+ +----------+ | | +--------+ +----------+ |
| | | | LCS | | | | | | LIS | |
| | +---| | | | | +---| | |
| | +----------+ | | | +----------+ |
| | | | | |
+-------+-------------------+ +-------+-------------------+
| Wired Network | Wired Network
<----------------> Access Network Provider demarc <----------------> Access Network Provider demarc
| |
+-------+-------------------+ +-------+-------------------+
| | | | | |
| +-------------+ | | +-------------+ |
skipping to change at page 9, line 10 skipping to change at page 9, line 10
Further examples of moving networks can be found in busses, trains, Further examples of moving networks can be found in busses, trains,
and airplanes. and airplanes.
Figure 2 shows an example topology for a moving network. Figure 2 shows an example topology for a moving network.
+--------------------------+ +--------------------------+
| Wireless | | Wireless |
| Access Network Provider | | Access Network Provider |
| | | |
| +----------+| | +----------+|
| +-------+ LCS || | +-------+ LIS ||
| | | || | | | ||
| +---+----+ +----------+| | +---+----+ +----------+|
| | Node | | | | Node | |
| | | | | | | |
| +---+----+ | | +---+----+ |
| | | | | |
+------+-------------------+ +------+-------------------+
| Wireless Interface | Wireless Interface
| |
+------+-------------------+ +------+-------------------+
skipping to change at page 9, line 40 skipping to change at page 9, line 40
|| A | \+ B | | || A | \+ B | |
|+--------+ +--------+ | |+--------+ +--------+ |
+--------------------------+ +--------------------------+
Figure 2: Moving Network Figure 2: Moving Network
3.3. Wireless Access 3.3. Wireless Access
Figure 3 shows a wireless access network where a moving end host Figure 3 shows a wireless access network where a moving end host
obtains location information or references to location information obtains location information or references to location information
from the LCS. The access equipment uses, in many cases, link layer from the LIS. The access equipment uses, in many cases, link layer
devices. Figure 3 represents a hotspot network found, for example, devices. Figure 3 represents a hotspot network found, for example,
in hotels, airports, and coffee shops. For editorial reasons we only in hotels, airports, and coffee shops. For editorial reasons we only
describe a single access point and do not depict how the LCS obtains describe a single access point and do not depict how the LIS obtains
location information since this is very deployment specific. location information since this is very deployment specific.
+--------------------------+ +--------------------------+
| Access Network Provider | | Access Network Provider |
| | | |
| +----------+| | +----------+|
| +-------| LCS || | +-------| LIS ||
| | | || | | | ||
| +--------+ +----------+| | +--------+ +----------+|
| | Access | | | | Access | |
| | Point | | | | Point | |
| +--------+ | | +--------+ |
| | | | | |
+------+-------------------+ +------+-------------------+
| |
+------+ +------+
| End | | End |
| Host | | Host |
+------+ +------+
Figure 3: Wireless Access Scenario Figure 3: Wireless Access Scenario
4. Discovery of the Location Configuration Server 4. Discovery of the Location Information Server
When a Target wants to retrieve location information from the LCS it When a Target wants to retrieve location information from the LIS it
first needs to discover it. Based on the problem statement of first needs to discover it. Based on the problem statement of
determining the location of the Target, which is known best by determining the location of the Target, which is known best by
entities close to the Target itself, we assume that the LCS is entities close to the Target itself, we assume that the LIS is
located in the access network. Several procedures have been located in the access network. Several procedures have been
investigated that aim to discover the LCS in such an access network. investigated that aim to discover the LIS in such an access network.
DHCP-based Discovery: DHCP-based Discovery:
In some environments the Dynamic Host Configuration Protocol In some environments the Dynamic Host Configuration Protocol
(DHCP) might be a good choice for discovering the FQDN or the IP (DHCP) might be a good choice for discovering the FQDN or the IP
address of the LCS. In environments where DHCP can be used it is address of the LIS. In environments where DHCP can be used it is
also possible to use the already defined location extensions. In also possible to use the already defined location extensions. In
environments with legacy devices, such as the one shown in environments with legacy devices, such as the one shown in
Section 3.1, a DHCP based discovery solution may not be possible. Section 3.1, a DHCP based discovery solution may not be possible.
DNS-based Discovery: DNS-based Discovery:
With this idea the end host obtains its public IP address (e.g., With this idea the end host obtains its public IP address (e.g.,
via STUN [5]) in order to obtain its domain name (via the usual via STUN [6]) in order to obtain its domain name (via the usual
reverse DNS lookup). Then, the SRV or NAPTR record for that reverse DNS lookup). Then, the SRV or NAPTR record for that
domain is retrieved. This relies on the user's public IP address domain is retrieved. This relies on the user's public IP address
having a DNS entry. having a DNS entry.
Redirect Rule: Redirect Rule:
A redirect rule at a device in the access network, for example at A redirect rule at a device in the access network, for example at
the AAA client, will be used to redirect the L7 LCP signalling the AAA client, will be used to redirect the L7 LCP signalling
messages (destined to a specific port) to the LCS. The end host messages (destined to a specific port) to the LIS. The end host
could then discover the LCS by sending a packet to almost any could then discover the LIS by sending a packet to almost any
address (as long it is not in the user's home network behind a address (as long it is not in the user's home network behind a
NAT). The packet would be redirected to the respective LCS being NAT). The packet would be redirected to the respective LIS being
configured. The same procedure is used by captive portals whereby configured. The same procedure is used by captive portals whereby
any HTTP traffic is intercepted and redirected. any HTTP traffic is intercepted and redirected.
Multicast Query: Multicast Query:
An end node could also discover a LCS by sending a multicast An end node could also discover a LIS by sending a multicast
request to a well-known address. An example of such a mechanism request to a well-known address. An example of such a mechanism
is multicast DNS (see [6] and [7]). is multicast DNS (see [7] and [8]).
The LCS discovery procedure raises deployment and security issues. The LIS discovery procedure raises deployment and security issues.
When an end host discovers a LCS it must be ensured that When an end host discovers a LIS it must be ensured that
1. it does not talk to a man-in-the-middle, and 1. it does not talk to a man-in-the-middle, and
2. that the discovered entity is indeed an authorized LCS. 2. that the discovered entity is indeed an authorized LIS.
5. Identifier for Location Determination 5. Identifier for Location Determination
The LCS returns location information to the end host when it receives The LIS returns location information to the end host when it receives
a request. Some form of identifier is therefore needed to allow the a request. Some form of identifier is therefore needed to allow the
LCS to retrieve the Target's current location (or a good LIS to retrieve the Target's current location (or a good
approximation of it) from a database. approximation of it) from a database.
The chosen identifier needs to have the following properties: The chosen identifier needs to have the following properties:
Ability for Target to learn or know the identifier: Ability for Target to learn or know the identifier:
The Target MUST know or MUST be able to learn the identifier The Target MUST know or MUST be able to learn the identifier
(explicitly or implicitly) in order to send it to the LCS. (explicitly or implicitly) in order to send it to the LIS.
Implicitly refers to the situation where a device along the path Implicitly refers to the situation where a device along the path
between the end host and the LCS modifies the identifier, as it is 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. done by a NAT when an IP address based identifier is used.
Ability to use the identifier for location determination: Ability to use the identifier for location determination:
The LCS MUST be able to use the identifier (directly or The LIS MUST be able to use the identifier (directly or
indirectly) for location determination. Indirectly refers to the indirectly) for location determination. Indirectly refers to the
case where the LCS uses other identifiers internally for location case where the LIS uses other identifiers internally for location
determination, in addition to the one provided by the Target. determination, in addition to the one provided by the Target.
Security properties of the identifier: Security properties of the identifier:
Misuse needs to be minimized whereby off-path adversary MUST NOT Misuse needs to be minimized whereby off-path adversary MUST NOT
be able to obtain location information of other Targets. A on- be able to obtain location information of other Targets. A on-
path adversary in the same subnet SHOULD NOT be able to spoof the path adversary in the same subnet SHOULD NOT be able to spoof the
identifier of another Target in the same subnet. identifier of another Target in the same subnet.
The following list discusses frequently mentioned identifiers and The following list discusses frequently mentioned identifiers and
their properties: their properties:
Host MAC Address: Host MAC Address:
The Target's MAC address is known to the end host, but not carried The Target's MAC address is known to the end host, but not carried
over an IP hop and therefore not accessible to the LCS in most over an IP hop and therefore not accessible to the LIS in most
deployment environments (unless carried in the L7 LCP itself). deployment environments (unless carried in the L7 LCP itself).
ATM VCI/VPI: ATM VCI/VPI:
The VPI/VCI is generally only seen by the DSL modem. Almost all 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. 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 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 (per end customer) to connect to the ATM switch. Only the network
provider is able to map VPI/VCI values through its network. With 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 the arrival of VDSL, ATM will slowly be phased out in favor of
skipping to change at page 14, line 22 skipping to change at page 14, line 22
enterprise networks, typically available via proprietary protocols enterprise networks, typically available via proprietary protocols
like CDP or, in the future, 802.1ab. like CDP or, in the future, 802.1ab.
Cell ID: Cell ID:
This identifier is available in cellular data networks and the This identifier is available in cellular data networks and the
cell ID may not be visible to the end host. cell ID may not be visible to the end host.
Host Identifier: Host Identifier:
The Host Identifier introduced by the Host Identity Protocol [8] The Host Identifier introduced by the Host Identity Protocol [9]
allows identification of a particular host. Unfortunately, the allows identification of a particular host. Unfortunately, the
network can only use this identifier for location determination if network can only use this identifier for location determination if
the operator already stores an mapping of host identities to the operator already stores an mapping of host identities to
location information. Furthermore, there is a deployment problem location information. Furthermore, there is a deployment problem
since the host identities are not used in todays networks. since the host identities are not used in todays networks.
Cryptographically Generated Address (CGA): Cryptographically Generated Address (CGA):
The concept of a Cryptographically Generated Address (CGA) was The concept of a Cryptographically Generated Address (CGA) was
introduced by [9]. The basic idea is to put the truncated hash of introduced by [10]. The basic idea is to put the truncated hash
a public key into the interface identifier part of an IPv6 of a public key into the interface identifier part of an IPv6
address. In addition to the properties of an IP address it allows address. In addition to the properties of an IP address it allows
a proof of ownership. Hence, a return routability check can be a proof of ownership. Hence, a return routability check can be
omitted. It is only available for IPv6 addresses. omitted. It is only available for IPv6 addresses.
Network Access Identifiers: Network Access Identifiers:
A Network Access Identifier [10] is used during the network access A Network Access Identifier [11] is used during the network access
authentication procedure, for example in RADIUS [11] and Diameter authentication procedure, for example in RADIUS [12] and Diameter
[12]. In DSL networks the user credentials are, in many cases, [13]. In DSL networks the user credentials are, in many cases,
only known by the home router and not configured at the Target only known by the home router and not configured at the Target
itself. To the network, the authenticated user identity is only itself. To the network, the authenticated user identity is only
available if a network access authentication procedure is available if a network access authentication procedure is
executed. In case of roaming the user's identity might not be executed. In case of roaming the user's identity might not be
available to the access network since security protocols might available to the access network since security protocols might
offer user identity confidentiality and thereby hiding the real offer user identity confidentiality and thereby hiding the real
identity of the user allowing the access network to only see a identity of the user allowing the access network to only see a
pseudonym or a randomized string. pseudonym or a randomized string.
Unique Client Identifier Unique Client Identifier
The DSL Forum has defined that all devices that expect to be The DSL Forum has defined that all devices that expect to be
managed by the TR-069 interface be able to generate an identifier managed by the TR-069 interface be able to generate an identifier
as described in Section 3.4.4 of the TR-069v2 DSL Forum document. as described in Section 3.4.4 of the TR-069v2 DSL Forum document.
It also has a requirement that routers that use DHCP to the WAN It also has a requirement that routers that use DHCP to the WAN
use RFC 4361 [13] to provide the DHCP server with a unique client use RFC 4361 [14] to provide the DHCP server with a unique client
identifier. This identifier is, however, not visible to the identifier. This identifier is, however, not visible to the
Target when legacy NTE device are used. Target when legacy NTE device are used.
IP Address: IP Address:
The Target's IP address may be used for location determination. The Target's IP address may be used for location determination.
This IP address is not visible to the LCS if the end host is This IP address is not visible to the LIS if the end host is
behind one or multiple NATs. This may not be a problem since the behind one or multiple NATs. This may not be a problem since the
location of a host that is located behind a NAT cannot be location of a host that is located behind a NAT cannot be
determined by the access network. The LCS would in this case only 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, see the public IP address of the NAT binding allocated by the NAT,
which is the expected behavior. The property of the IP address which is the expected behavior. The property of the IP address
for a return routability check is attractive to return location for a return routability check is attractive to return location
information only to the address that submitted the request. If an information only to the address that submitted the request. If an
adversary wants to learn the location of a Target (as identified adversary wants to learn the location of a Target (as identified
by a particular IP address) then it does not see the response by a particular IP address) then it does not see the response
message (unless he is on the subnetwork or at a router along the message (unless he is on the subnetwork or at a router along the
path towards the LCS). path towards the LIS).
On a shared medium an adversary could ask for location information On a shared medium an adversary could ask for location information
of another Target. The adversary would be able to see the of another Target. The adversary would be able to see the
response message since it is sniffing on the shared medium unless response message since it is sniffing on the shared medium unless
security mechanisms, such as link layer encryption, are in place. security mechanisms, such as link layer encryption, are in place.
With a network deployment as shown in Section 3.1 with multiple With a network deployment as shown in Section 3.1 with multiple
hosts in the Customer Premise being behind a NAT the LCS is unable hosts in the Customer Premise being behind a NAT the LIS is unable
to differentiate the individual end points. For WLAN deployments to differentiate the individual end points. For WLAN deployments
as found in hotels, as shown in Section 3.3, it is possible for an as found in hotels, as shown in Section 3.3, it is possible for an
adversary to eavesdrop data traffic and subsequently to spoof the adversary to eavesdrop data traffic and subsequently to spoof the
IP address in a query to the LCS to learn more detailed location IP address in a query to the LIS to learn more detailed location
information (e.g., specific room numbers). Such an attack might, information (e.g., specific room numbers). Such an attack might,
for example, compromise the privacy of hotel guests. for example, compromise the privacy of hotel guests.
6. Requirements 6. Requirements
The following requirements and assumptions have been identified: The following requirements and assumptions have been identified:
Requirement L7-1: Identifier Choice Requirement L7-1: Identifier Choice
The L7 LCP MUST be able to carry different identifiers or MUST The L7 LCP MUST be able to carry different identifiers or MUST
skipping to change at page 16, line 26 skipping to change at page 16, line 26
Requirement L7-2: Mobility Support Requirement L7-2: Mobility Support
The L7 LCP MUST support a broad range of mobility from devices The L7 LCP MUST support a broad range of mobility from devices
that can only move between reboots, to devices that can change that can only move between reboots, to devices that can change
attachment points with the impact that their IP address is attachment points with the impact that their IP address is
changed, to devices that do not change their IP address while changed, to devices that do not change their IP address while
roaming, to devices that continuously move by being attached to roaming, to devices that continuously move by being attached to
the same network attachment point. the same network attachment point.
Requirement L7-3: Layer 7 and Layer 2/3 Provider Relationship Requirement L7-3: ASP and Access Network Provider Relationship
The design of the L7 LCP MUST NOT assume a business or trust The design of the L7 LCP MUST NOT assume a business or trust
relationship between the VSP and the ISP/ASP. Requirements for relationship between the Application Service Provider (ASP) and
resolving a reference to location information are not discussed in the Access Network Provider. Requirements for resolving a
this document. reference to location information are not discussed in this
document.
Requirement L7-4: Layer 2 and Layer 3 Provider Relationship Requirement L7-4: Layer 2 and Layer 3 Provider Relationship
The design of the L7 LCP MUST assume that there is a trust and The design of the L7 LCP MUST assume that there is a trust and
business relationship between the L2 and the L3 provider. The L3 business relationship between the L2 and the L3 provider. The L3
provider operates the LCS and needs to obtain location information provider operates the LIS and needs to obtain location information
from the L2 provider since this one is closest to the end host. 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 If the L2 and L3 provider for the same host are different
entities, they cooperate for the purposes needed to determine end entities, they cooperate for the purposes needed to determine end
system locations. system locations.
Requirement L7-5: Legacy Device Considerations Requirement L7-5: Legacy Device Considerations
The design of the L7 LCP MUST consider legacy devices, such as The design of the L7 LCP MUST consider legacy devices, such as
residential NAT devices and NTEs in an DSL environment, that residential NAT devices and NTEs in an DSL environment, that
cannot be upgraded to support additional protocols, for example, cannot be upgraded to support additional protocols, for example,
to pass additional information towards the Target. to pass additional information towards the Target.
Requirement L7-6: VPN Awareness Requirement L7-6: VPN Awareness
The design of the L7 LCP MUST assume that at least one end of a The design of the L7 LCP MUST assume that at least one end of a
VPN is aware of the VPN functionality. In an enterprise scenario, VPN is aware of the VPN functionality. In an enterprise scenario,
the enterprise side will provide the LCS used by the client and the enterprise side will provide the LIS used by the client and
can thereby detect whether the LCS request was initiated through a can thereby detect whether the LIS request was initiated through a
VPN tunnel. VPN tunnel.
Requirement L7-7: Network Access Authentication Requirement L7-7: Network Access Authentication
The design of the L7 LCP MUST NOT assume prior network access The design of the L7 LCP MUST NOT assume prior network access
authentication. authentication.
Requirement L7-8: Network Topology Unawareness Requirement L7-8: Network Topology Unawareness
The design of the L7 LCP MUST NOT assume end systems being aware The design of the L7 LCP MUST NOT assume end systems being aware
of the access network topology. End systems are, however, able to of the access network topology. End systems are, however, able to
determine their public IP address(es) via mechanisms, such as STUN determine their public IP address(es) via mechanisms, such as STUN
[5] or NSIS NATFW NSLP [14] . [6] or NSIS NATFW NSLP [15] .
Requirement L7-9: Discovery Mechanism Requirement L7-9: Discovery Mechanism
The L7 LCP MUST define a mandatory-to-implement LCS discovery The L7 LCP MUST define a mandatory-to-implement LIS discovery
mechanism. mechanism.
7. Security Considerations 7. Security Considerations
A discussion about security aspects can be found in another document. This document contains security related requirements. A discussion
[Editor's Note: The security related content was previously in this about security aspects of the HELD protocol when used in the GEOPRIV
document and will be published in a separate document soon.] architecture when applied to certain usage environments, such as
emergency services, can be found in [16].
8. IANA Considerations 8. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
9. Contributors 9. Contributors
This contribution is a joint effort of the GEOPRIV Layer 7 Location This contribution is a joint effort of the GEOPRIV Layer 7 Location
Configuration Requirements Design Team of the IETF GEOPRIV Working Configuration Requirements Design Team of the IETF GEOPRIV Working
Group. The contributors include Henning Schulzrinne, Barbara Stark, Group. The contributors include Henning Schulzrinne, Barbara Stark,
skipping to change at page 20, line 34 skipping to change at page 20, line 34
Jon Peterson: jon.peterson@neustar.biz Jon Peterson: jon.peterson@neustar.biz
Brian Rosen: br@brianrosen.net Brian Rosen: br@brianrosen.net
Henning Schulzrinne: hgs@cs.columbia.edu Henning Schulzrinne: hgs@cs.columbia.edu
Barbara Stark: Barbara.Stark@bellsouth.com Barbara Stark: Barbara.Stark@bellsouth.com
Martin Thomson: Martin.Thomson@andrew.com Martin Thomson: Martin.Thomson@andrew.com
Hannes Tschofenig: Hannes.Tschofenig@siemens.com Hannes Tschofenig: Hannes.Tschofenig@nsn.com
James Winterbottom: James.Winterbottom@andrew.com James Winterbottom: James.Winterbottom@andrew.com
10. Acknowledgements 10. Acknowledgements
We would like to thank the IETF GEOPRIV working group chairs, Andy We would like to thank the IETF GEOPRIV working group chairs, Andy
Newton, Allison Mankin and Randall Gellens, for creating this design Newton, Allison Mankin and Randall Gellens, for creating this design
team. Furthermore, we would like thank Andy Newton for his support team. Furthermore, we would like thank Andy Newton for his support
during the design team mailing list, for setting up Jabber chat during the design team mailing list, for setting up Jabber chat
conferences and for participating in the phone conference conferences and for participating in the phone conference
skipping to change at page 22, line 24 skipping to change at page 22, line 24
[3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
March 2007. March 2007.
11.2. Informative References 11.2. Informative References
[4] Marshall, R., "Requirements for a Location-by-Reference [4] Marshall, R., "Requirements for a Location-by-Reference
Mechanism used in Location Configuration and Conveyance", Mechanism used in Location Configuration and Conveyance",
draft-marshall-geopriv-lbyr-requirements-01 (work in progress), draft-marshall-geopriv-lbyr-requirements-02 (work in progress),
March 2007. July 2007.
[5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
Requirements", draft-winterbottom-geopriv-lis2lis-req-00 (work
in progress), June 2007.
[6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[6] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast [7] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast
Name Resolution (LLMNR)", RFC 4795, January 2007. Name Resolution (LLMNR)", RFC 4795, January 2007.
[7] Cheshire, S. and M. Krochmal, "Multicast DNS", [8] Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-06 (work in progress), draft-cheshire-dnsext-multicastdns-06 (work in progress),
August 2006. August 2006.
[8] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08 [9] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08
(work in progress), June 2007. (work in progress), June 2007.
[9] Aura, T., "Cryptographically Generated Addresses (CGA)", [10] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[10] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network [11] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005. Access Identifier", RFC 4282, December 2005.
[11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [12] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000. June 2000.
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, [13] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003. "Diameter Base Protocol", RFC 3588, September 2003.
[13] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers [14] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
for Dynamic Host Configuration Protocol Version Four (DHCPv4)", for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
RFC 4361, February 2006. RFC 4361, February 2006.
[14] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol [15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in progress), (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in progress),
March 2007. July 2007.
[15] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[16] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
draft-ietf-ecrit-lost-05 (work in progress), March 2007.
[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] Peterson, J. and C. Jennings, "Enhancements for Authenticated [16] Barnes, R., "Threats to GEOPRIV Location Objects",
Identity Management in the Session Initiation Protocol (SIP)", draft-barnes-geopriv-lo-sec-00 (work in progress), July 2007.
RFC 4474, August 2006.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Phone: +49 89 636 40390 Phone: +49 89 636 40390
 End of changes. 64 change blocks. 
97 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/