< draft-ietf-geopriv-l7-lcp-ps-09.txt   draft-ietf-geopriv-l7-lcp-ps-10.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: August 25, 2009 Columbia University Expires: January 14, 2010 Columbia University
February 21, 2009 July 13, 2009
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-09.txt draft-ietf-geopriv-l7-lcp-ps-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 August 25, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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
Information Server (LIS) that is located in the access network. The Information Server (LIS) that is located in the access network. 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 . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9 3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9
4. Discovery of the Location Information Server . . . . . . . . . 11 4. Discovery of the Location Information Server . . . . . . . . . 11
5. Identifier for Location Determination . . . . . . . . . . . . 13 5. Identifier for Location Determination . . . . . . . . . . . . 13
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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
Information Server (LIS). 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 based Uniform Resource Identifier (URI), a HTTP/HTTPS
related to the task of obtaining a LbyR are described in a URI, or another URI. The requirements related to the task of
separate document, see [4]. obtaining a LbyR are described in a separate document, see
[I-D.ietf-geopriv-lbyr-requirements].
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) and the LIS. the end host (i.e., the Target in [RFC3693] terminology) and the LIS.
This document is structured as follows. Section 4 discusses the This document is structured as follows. Section 4 discusses the
challenge of discovering the LIS 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
with the qualification that unless otherwise stated these words apply [RFC2119], with the qualification that unless otherwise stated these
to the design of the Geopriv Layer 7 Location Configuration Protocol. words apply to the design of the Geopriv Layer 7 Location
Configuration Protocol.
The term Location Information Server (LIS) refers to an entity The term Location Information Server (LIS) refers to an entity
capable of determining the location of a Target and of providing that capable of determining the location of a Target and of providing that
location information, a reference to it, or both via the Location location information, a reference to it, or both via the Location
Configuration Protocol (LCP) to the requesting party. In most cases Configuration Protocol (LCP) to the requesting party. In most cases
the requesting party is the Target itself but it may also be an the requesting party is the Target itself but it may also be an
authorized entity that acts on behalf of it, such as a SIP proxy or authorized entity that acts on behalf of it, such as a SIP proxy or
another LIS. another LIS.
This document also uses terminology from [1] (such as Target) and [3] This document also uses terminology from [RFC3693] (such as Target)
(such as Internet Access Provider (IAP), Internet Service Provider and [I-D.ietf-ecrit-requirements] (such as Internet Access Provider
(ISP), and Application Service Provider (ASP)). (IAP), Internet Service Provider (ISP), and Application Service
Provider (ASP)).
With the term "Access Network Provider" we refer to the Internet With the term "Access Network Provider" we refer to the Internet
Access Provider (IAP) and the Internet Service Provider (ISP) without Access Provider (IAP) and the Internet Service Provider (ISP) without
further distinguishing these two entities as it is not relevant for further distinguishing these two entities as it is not relevant for
the purpose of this document. An additional requirements document on the purpose of this document. An additional requirements document on
LIS-to-LIS [5] shows scenario where the separation between IAP and LIS-to-LIS [I-D.winterbottom-geopriv-lis2lis-req] shows scenario
ISP is important. 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 25 skipping to change at page 5, line 25
802.16e/Wimax 802.16e/Wimax
o 3G networks o 3G networks
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 Digital subscriber line (DSL) network scenario with
Provider and the customer premises. The Access Network Provider the Access Network Provider and the customer premises. The Access
operates link and network layer devices (represented as Node) and the Network Provider operates link and network layer devices (represented
LIS. as Node) and the LIS.
+---------------------------+ +---------------------------+
| | | |
| Access Network Provider | | Access Network Provider |
| | | |
| +--------+ | | +--------+ |
| | Node | | | | Node | |
| +--------+ +----------+ | | +--------+ +----------+ |
| | | | LIS | | | | | | LIS | |
| | +---| | | | | +---| | |
skipping to change at page 7, line 18 skipping to change at page 7, line 18
the same box, or for there to be no home router, or for the NTE and 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 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 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. customers' homes, and the Ethernet NIC in their PC serves as the NTE.
Current Customer Premises Network (CPN) deployments generally fall Current Customer Premises Network (CPN) deployments generally fall
into one of the following classifications: into one of the following classifications:
1. Single PC 1. Single PC
1. with Ethernet NIC (PPPoE or DHCP on PC); there may be a 1. with Ethernet network interface card (NIC) with Point-to-
bridged DSL or cable modem as NTE, or the Ethernet NIC might Point Protocol Over Ethernet (PPPoE) or Dynamic Host
be the NTE Configuration Protocol (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] 2. with Universal Serial Bus (USB) based DSL access or a cable
modem access using Point-to-Point Protocol over ATM (PPPoA),
PPPoE, or DHCP on PC
Note that the device with NAPT and DHCP of Figure 1 is not Note that the device with NAPT and DHCP of Figure 1 is not
present in such a scenario. present in such a scenario.
2. One or more hosts with at least one router (DHCP Client or PPPoE, 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 DHCP server in router; VoIP can be soft client on PC, stand-alone
VoIP device, or Analog Terminal Adaptor (ATA) function embedded VoIP device, or Analog Terminal Adaptor (ATA) function embedded
in router) in router)
1. combined router and NTE 1. combined router and NTE
skipping to change at page 11, line 7 skipping to change at page 11, line 7
| |
+------+ +------+
| End | | End |
| Host | | Host |
+------+ +------+
Figure 3: Wireless Access Scenario Figure 3: Wireless Access Scenario
4. Discovery of the Location Information Server 4. Discovery of the Location Information Server
Note that this section lists mechanisms that were discussed as Note that this section lists mechanisms that were discussed in the
part of the work on the Geopriv Layer 7 Location Configuration Geopriv Layer 7 Location Configuration Protocol design team. They
Protocol design team. They are included to show challenges in the are included to show challenges in the problem space and are
problem space and are listed for completeness reasons. They do listed for completeness reasons. They do not in any way mean that
not in any way mean that their is consensus that any of these there is consensus about any of the mechanisms or that the IETF
approaches are good or bad or that the IETF is in any recommended recommends any of the procedures described in this section.
in this document that any of these be used.
When a Target wants to retrieve location information from the LIS 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 LIS is entities close to the Target itself, we assume that the LIS is
located in the local subnet or in access network. Several procedures located in the local subnet or in access network. Several procedures
have been investigated that aim to discover the LIS in such an access have been investigated that aim to discover the LIS in such an access
network. 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 fully qualified
address of the LIS. In environments where DHCP can be used it is domain name (FQDN) or the IP address of the LIS. In environments
also possible to use the already defined location extensions. In where DHCP can be used it is also possible to use the already
environments with legacy devices, such as the one shown in defined location extensions. In environments with legacy devices,
Section 3.1, a DHCP based discovery solution may not be possible. such as the one shown in Section 3.1, a DHCP based discovery
solution may not be possible.
DNS-based Discovery: DNS-based Discovery:
Before a DNS lookup can be started it is necessary to learn the Before a Domain Name System (DNS) lookup can be started it is
domain name of the access network that runs a LIS. Several ways necessary to learn the domain name of the access network that runs
to learn the domain name exist. For example, the end host obtains a LIS. Several ways to learn the domain name exist. For example,
its own public IP address, for example via STUN [6], and performs the end host obtains its own public IP address, for example via
a reverse DNS lookup (assuming the data is provisioned into the STUN [RFC3489], and performs a reverse DNS lookup (assuming the
DNS). Then, the SRV or NAPTR record for that domain is retrieved. data is provisioned into the DNS). Then, the DNS Service (SRV)
A more detailed description of this approach can be found in [7]. record or the DNS Naming Authority Pointer (NAPTR) record for that
domain is retrieved. A more detailed description of this approach
can be found in [I-D.thomson-geopriv-lis-discovery].
Redirect Rule: Redirect Rule:
A redirect rule at a device in the access network could be used to A redirect rule at a device in the access network could be used to
redirect the L7 LCP signalling messages (destined to a specific redirect the L7 LCP signalling messages (destined to a specific
port) to the LIS. The end host could then discover the LIS by port) to the LIS. The end host could then discover the LIS by
sending a packet with a specific (registered) port number to sending a packet with a specific (registered) port number to
almost any address (as long as the destination IP address does not almost any address (as long as the destination IP address does not
target a device in the local network). The packet would be target a device in the local network). The packet would be
redirected to the respective LIS being configured. The same redirected to the respective LIS being configured. The same
procedure is used by captive portals whereby any HTTP traffic is procedure is used by captive portals whereby any HTTP traffic is
intercepted and redirected. intercepted and redirected.
To some extend this approach is similar to packets that are marked To some extend this approach is similar to packets that are marked
with a Router Alert option [8] and intercepted by entities that with a Router Alert option [RFC2113] and intercepted by entities
understand the specific marking. In the above-mentioned case, that understand the specific marking. In the above-mentioned
however, the marking is provided via a registered port number case, however, the marking is provided via a registered port
instead of relying on a Router Alert option. number instead of relying on a Router Alert option.
This solution approach would require a deep packet inspection This solution approach would require a deep packet inspection
capability at an entity in the access providers networks that capability at an entity in the access providers networks that
scans for the occurrence of particular destination port numbers. scans for the occurrence of particular destination port numbers.
Multicast Query: Multicast Query:
An end node could also discover a LIS by sending a DNS query to a An end node could also discover a LIS by sending a DNS query to a
well-known address. An example of such a mechanism is multicast well-known address. An example of such a mechanism is multicast
DNS (see [9] and [10]). Unfortunately, these mechanisms only work DNS (see [RFC4795] and [I-D.cheshire-dnsext-multicastdns]).
on the local link. Unfortunately, these mechanisms only work on the local link.
Anycast: Anycast:
With this solution an anycast address is defined (for IPv4 and With this solution an anycast address is defined (for IPv4 and
IPv6) in the style of [11] that allows the endhost to route IPv6) in the style of [RFC3068] that allows the endhost to route
discovery packets to the nearest LIS. Note that this procedure discovery packets to the nearest LIS. Note that this procedure
would be used purely for discovery and thereby similar to local would be used purely for discovery and thereby similar to local
Teredo server discovery approach outlined in Section 4.2 of [12]. Teredo server discovery approach outlined in Section 4.2 of
[I-D.nward-v6ops-teredo-server-selection].
The LIS discovery procedure raises deployment and security issues. The LIS discovery procedure raises deployment and security issues.
The access network needs to be designed to prevent man-in-the-middle The access network needs to be designed to prevent man-in-the-middle
adversaries from presenting themselves as a LIS to end hosts. When adversaries from presenting themselves as a LIS to end hosts. When
an end host discovers a LIS, it needs to ensure (and be able to an end host discovers a LIS, it needs to ensure (and be able to
ensure) that the discovered entity is indeed an authorized LIS. ensure) that the discovered entity is indeed an authorized LIS.
5. Identifier for Location Determination 5. Identifier for Location Determination
Note that this section lists mechanisms that were discussed as Note that this section lists mechanisms that were discussed in the
part of the work in the Geopriv Layer 7 Location Configuration Geopriv Layer 7 Location Configuration Protocol design team. They
Protocol design team. They are included to show challenges in the are included to show challenges in the problem space and are
problem space and are listed for completeness reasons. They do listed for completeness reasons. They do not in any way mean that
not in any way mean that their is consensus that any of these there is consensus about any of the mechanisms or that the IETF
approaches are good or bad or that the IETF is in any recommended recommends any of the procedures described in this section.
in this document that any of these be used.
The LIS 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
LIS 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:
skipping to change at page 14, line 5 skipping to change at page 13, line 46
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: Media Access Control (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 LIS 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: Asynchronous Transfer Mode (ATM) Virtual Path Identifier(VPI)/Virtual
Circuit Identifier(VCI):
The VPI/VCI is generally only seen by the DSL modem. Almost all The VCI/VPI 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 United States use 1 of 2 VPI/VCI value pairs: 0/35
This VC is terminated at the DSLAM, which uses a different VPI/VCI and 8/35. This VC is terminated at the digital subscriber line
(per end customer) to connect to the ATM switch. Only the network access multiplexer (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 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 Very high rate Digital Subscriber Line (VDSL), ATM
Ethernet. will slowly be phased out in favor of Ethernet.
Switch/Port Number: Ethernet Switch (Bridge)/Port Number:
This identifier is available only in certain networks, such as This identifier is available only in certain networks, such as
enterprise networks, typically available via proprietary protocols enterprise networks, typically available via the IEEE 802.1AB
like CDP or, in the future, 802.1ab. protocol [802.1AB] or proprietary protocols like the Cisco
Discovery Protocol (CDP) [CDP].
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 [13] The Host Identifier introduced by the Host Identity Protocol (HIP)
allows identification of a particular host. Unfortunately, the [I-D.ietf-hip-base] allows identification of a particular host.
network can only use this identifier for location determination if Unfortunately, the network can only use this identifier for
the operator already stores a mapping of host identities to location determination if the operator already stores a mapping of
location information. Furthermore, there is a deployment problem host identities to location information. Furthermore, there is a
since the host identities are not used in todays networks. deployment problem 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 [14]. The basic idea is to put the truncated hash introduced by [RFC3972]. The basic idea is to put the truncated
of a public key into the interface identifier part of an IPv6 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 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 [15] is used during the network access A Network Access Identifier [RFC4282] is used during the network
authentication procedure, for example in RADIUS [16] and Diameter access authentication procedure, for example in RADIUS [RFC2865]
[17]. In DSL networks the user credentials are, in many cases, and Diameter [RFC3588]. In DSL networks the user credentials are,
only known by the home router and not configured at the Target in many cases, only known by the home router and not configured at
itself. To the network, the authenticated user identity is only the Target itself. To the network, the authenticated user
available if a network access authentication procedure is identity is only available if a network access authentication
executed. In case of roaming the user's identity might not be procedure is executed. In case of roaming the user's identity
available to the access network since security protocols might might not be available to the access network since security
offer user identity confidentiality and thereby hiding the real protocols might offer user identity confidentiality and thereby
identity of the user allowing the access network to only see a hiding the real identity of the user allowing the access network
pseudonym or a randomized string. to only see a pseudonym or a randomized string.
Unique Client Identifier Unique Client Identifier
The DSL Forum has defined that all devices that expect to be The Broadband 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, see [TR069], have to be able to
as described in Section 3.4.4 of the TR-069v2 DSL Forum document. generate an identifier that uniquely identifies the device. It
It also has a requirement that routers that use DHCP to the WAN also has a requirement that routers that use DHCP to the WAN use
use RFC 4361 [18] to provide the DHCP server with a unique client RFC 4361 [RFC4361] 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 LIS 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 LIS would in this case only determined by the access network. The LIS would in this case only
skipping to change at page 18, line 6 skipping to change at page 18, line 6
for the same host are different entities, they cooperate for the for the same host are different entities, they cooperate for the
purposes needed to determine end system locations. purposes needed to determine end 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 a DSL environment, that cannot residential NAT devices and NTEs in a DSL environment, that cannot
be upgraded to support additional protocols, for example, to pass be upgraded to support additional protocols, for example, to pass
additional information towards the Target. additional information towards the Target.
Requirement L7-6: VPN Awareness Requirement L7-6: Virtual Private Network (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 LIS used by the client and the enterprise side will provide the LIS used by the client and
can thereby detect whether the LIS 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
[6] or NSIS NATFW NSLP [19] . Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs) (STUN) [RFC3489] or Next Steps in
Signaling (NSIS) NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
[I-D.ietf-nsis-nslp-natfw] .
Requirement L7-9: Discovery Mechanism Requirement L7-9: Discovery Mechanism
The L7 LCP MUST define a mandatory-to-implement LIS discovery The L7 LCP MUST define a mandatory-to-implement LIS discovery
mechanism. mechanism.
Requirement L7-10: PIDF-LO Creation Requirement L7-10: PIDF-LO Creation
When a LIS creates a PIDF-LO [20] then it MUST put the <geopriv> When a LIS creates a Presence Information Data Format (PIDF)
Location Object (LO) [RFC4119] then it MUST put the <geopriv>
element into the <device> element of the presence document (see element into the <device> element of the presence document (see
[21]). This ensures that the resulting PIDF-LO document, which is [RFC4479]). This ensures that the resulting PIDF-LO document,
subsequently distributed to other entities, conforms to the rules which is subsequently distributed to other entities, conforms to
outlined in [22]. the rules outlined in [I-D.ietf-geopriv-pdif-lo-profile].
7. Security Considerations 7. Security Considerations
By using a Geolocation L7 Location Configuration Protocol, the client By using a Geolocation L7 Location Configuration Protocol, the client
expose themselves to a privacy risk whereby an unauthorized entity expose themselves to a privacy risk whereby an unauthorized entity
receives location information. The provision of confidentiality receives location information. The provision of confidentiality
protected location to the requestor depends on the success of four protected location to the requestor depends on the success of four
steps: steps:
1. The client must have a means to discover a LIS. 1. The client MUST have a means to discover a LIS.
2. The client must authenticate the discovered LIS. 2. The client MUST authenticate the discovered LIS.
3. The LIS must be able to determine location and return it to the 3. The LIS MUST be able to determine location and return it to the
authorized entity. authorized entity.
4. The LIS must securely exchange messages without intermedaries 4. The LIS MUST securely exchange messages without intermedaries
eavesdropping or tampering them. eavesdropping or tampering them.
This document contains various security related requirements This document contains various security related requirements
throughout the document addressing the above-mentioned steps. For a throughout the document addressing the above-mentioned steps. For a
broader security discussion of the overall geolocation privacy broader security discussion of the overall geolocation privacy
architecture the reader is referred to [23]. architecture the reader is referred to [I-D.barnes-geopriv-lo-sec].
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 22, line 14 skipping to change at page 22, line 14
10. Acknowledgements 10. Acknowledgements
We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin
Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl,
Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard,
Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara
Stark, Michael Haberler, and Mary Barnes for their WGLC review Stark, Michael Haberler, and Mary Barnes for their WGLC review
comments. comments.
The authors would like to thank NENA for their work on [24] as it The authors would like to thank NENA for their work on [NENA] as it
helped to provide some of the initial thinking. helped to provide some of the initial thinking.
The authors would also like to thank Cullen Jennings for his feedback The authors would also like to thank Cullen Jennings for his feedback
as part of the IESG processing. as part of the IESG processing. Additionally, we would like to thank
Alexey Melnikov, Dan Romascanu,
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [I-D.ietf-ecrit-requirements]
Polk, "Geopriv Requirements", RFC 3693, February 2004. Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress),
March 2007.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
Context Resolution with Internet Technologies", J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
draft-ietf-ecrit-requirements-13 (work in progress),
March 2007.
11.2. Informative References 11.2. Informative References
[4] Marshall, R., "Requirements for a Location-by-Reference [802.1AB] "IEEE 802.1AB-2005 IEEE Standard for Local and
Mechanism", draft-ietf-geopriv-lbyr-requirements-05 (work in Metropolitan Area Networks Station and Media Access
progress), November 2008. Control Connectivity Discovery", (PDF document), http://
standards.ieee.org/getieee802/download/802.1AB-2005.pdf,
May 2005.
[5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol [CDP] "Cisco Discovery Protocol (CDP)", (HTML page), http://
Requirements", draft-winterbottom-geopriv-lis2lis-req-01 (work en.wikipedia.org/wiki/Cisco_Discovery_Protocol, July 2009.
in progress), November 2007.
[6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [I-D.barnes-geopriv-lo-sec]
- Simple Traversal of User Datagram Protocol (UDP) Through Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Network Address Translators (NATs)", RFC 3489, March 2003. Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-barnes-geopriv-lo-sec-05 (work in progress),
March 2009.
[7] Thomson, M. and J. Winterbottom, "Discovering the Local [I-D.cheshire-dnsext-multicastdns]
Location Information Server (LIS)", Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-thomson-geopriv-lis-discovery-03 (work in progress), draft-cheshire-dnsext-multicastdns-07 (work in progress),
September 2007. September 2008.
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [I-D.ietf-geopriv-lbyr-requirements]
Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work
in progress), February 2009.
[9] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast [I-D.ietf-geopriv-pdif-lo-profile]
Name Resolution (LLMNR)", RFC 4795, January 2007. Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), November 2008.
[10] Cheshire, S. and M. Krochmal, "Multicast DNS", [I-D.ietf-hip-base]
draft-cheshire-dnsext-multicastdns-07 (work in progress), Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
September 2008. "Host Identity Protocol", draft-ietf-hip-base-10 (work in
progress), October 2007.
[11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [I-D.ietf-nsis-nslp-natfw]
RFC 3068, June 2001. Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-20 (work in progress),
November 2008.
[12] Ward, N., "Teredo Server Selection", [I-D.nward-v6ops-teredo-server-selection]
draft-nward-v6ops-teredo-server-selection-00 (work in Ward, N., "Teredo Server Selection",
progress), July 2007. draft-nward-v6ops-teredo-server-selection-00 (work in
progress), July 2007.
[13] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [I-D.thomson-geopriv-lis-discovery]
"Host Identity Protocol", draft-ietf-hip-base-10 (work in Thomson, M. and J. Winterbottom, "Discovering the Local
progress), October 2007. Location Information Server (LIS)",
draft-thomson-geopriv-lis-discovery-03 (work in progress),
September 2007.
[14] Aura, T., "Cryptographically Generated Addresses (CGA)", [I-D.winterbottom-geopriv-lis2lis-req]
RFC 3972, March 2005. Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
Requirements", draft-winterbottom-geopriv-lis2lis-req-01
(work in progress), November 2007.
[15] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network [NENA] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA
Access Identifier", RFC 4282, December 2005. Recommended Method(s) for Location Determination to
Support IP-Based Emergency Services - Technical
Information Document (TID)", (PDF document), NENA 08-505,
December 2006.
[16] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
Authentication Dial In User Service (RADIUS)", RFC 2865, February 1997.
June 2000.
[17] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Diameter Base Protocol", RFC 3588, September 2003. "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[18] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 3068, June 2001.
RFC 4361, February 2006.
[19] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/ [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
Firewall NSIS Signaling Layer Protocol (NSLP)", "STUN - Simple Traversal of User Datagram Protocol (UDP)
draft-ietf-nsis-nslp-natfw-20 (work in progress), Through Network Address Translators (NATs)", RFC 3489,
November 2008. March 2003.
[20] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Format", RFC 4119, December 2005. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[21] Rosenberg, J., "A Data Model for Presence", RFC 4479, [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
July 2006. RFC 3972, March 2005.
[22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
PIDF-LO Usage Clarification, Considerations and Format", RFC 4119, December 2005.
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 (work
in progress), November 2008.
[23] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne, [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
"Additional Location Privacy Considerations", Network Access Identifier", RFC 4282, December 2005.
draft-barnes-geopriv-lo-sec-04 (work in progress),
January 2009.
[24] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Recommended Method(s) for Location Determination to Support IP- Identifiers for Dynamic Host Configuration Protocol
Based Emergency Services - Technical Information Document Version Four (DHCPv4)", RFC 4361, February 2006.
(TID)", PDF NENA 08-505, December 2006.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795,
January 2007.
[TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue
1 Amendment 2", (PDF document), http://
www.broadband-forum.org/technical/download/
TR-069Amendment2.pdf, December 2007.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
 End of changes. 67 change blocks. 
181 lines changed or deleted 227 lines changed or added

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