Network Working Group H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Informational H. Schulzrinne
Expires: December 31, 2008 Columbia University
June 29, 2008
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement andRequirementsdraft-ietf-geopriv-l7-lcp-ps-08.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 December 31, 2008.
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 1]

Internet-Draft Geopriv L7 LCP; Problem Statement June 20081. Introduction
This document provides a problem statement, lists requirements and
captures design aspects for a Geopriv Layer 7 Location Configuration
Protocol L7 (LCP). The protocol has two purposes:
o It is used to obtain location information (referred as "Location
by Value" or LbyV) from a dedicated node, called the Location
Information Server (LIS).
o It enables the Target to obtain a reference to location
information (referred as "Location by Reference" or LbyR). This
reference can take the form of a subscription URI, such as a SIP
presence URI, a HTTP/HTTPS URI, or another URI. The requirements
related to the task of obtaining a LbyR are described in a
separate document, see [4].
The need for these two functions can be derived from the scenarios
presented in Section 3.
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.
This document is structured as follows. Section 4 discusses the
challenge of discovering the LIS in the access network. Section 5
compares different types of identifiers that can be used to retrieve
location information. A list of requirements for the L7 LCP can be
found in Section 6.
This document does not describe how the access network provider
determines the location of the end host since this is largely a
matter of the capabilities of specific link layer technologies or
certain deployment environments.
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 3]

Internet-Draft Geopriv L7 LCP; Problem Statement June 20082. 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 [2],
with the qualification that unless otherwise stated these words apply
to the design of the GEOPRIV Layer 7 Location Configuration Protocol.
The term Location Information Server (LIS) refers to an entity
capable of determining the location of a Target and of providing that
location information, a reference to it, or both via the Location
Configuration Protocol (LCP) to the requesting party. In most cases
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
another LIS.
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.
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 4]

Internet-Draft Geopriv L7 LCP; Problem Statement June 2008
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 generally fall
into one of the following classifications:
1. 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 running on the end host.
3.2. Moving Network
One example of a moving network is a WiMAX fixed wireless scenario.
This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 7]

Internet-Draft Geopriv L7 LCP; Problem Statement June 2008
networks. In implementations intended to provide broadband service
to a home or other stationary location, the customer-side antenna /
NTE tends to be rather small and portable. The LAN-side output of
this device is an Ethernet jack, which can be used to feed a PC or a
router. The PC or router then uses DHCP or PPPoE to connect to the
access network, the same as for wired access networks. Access
providers who deploy this technology may use the same core network
(including network elements that terminate PPPoE and provide IP
addresses) for DSL, fiber to the premises (FTTP), and fixed wireless
customers.
Given that the customer antenna is portable and can be battery-
powered, it is possible for a user to connect a laptop to it and move
within the coverage area of a single base antenna. This coverage
area can be many square kilometers in size. In this case, the laptop
(and any SIP client running on it) would be completely unaware of
their mobility. Only the user and the network are aware of the
laptop's mobility.
Further examples of moving networks (where end devices may not be
aware that they are moving) can be found in busses, trains, and
airplanes.
Figure 2 shows an example topology for a moving network.
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 8]

Internet-Draft Geopriv L7 LCP; Problem Statement June 20084. Discovery of the Location Information Server
When a Target 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 Target, which is known best by
entities close to the Target itself, we assume that the LIS is
located in the local subnet or in access network. Several procedures
have been investigated that aim to discover the LIS in such an access
network.
DHCP-based Discovery:
In some environments the Dynamic Host Configuration Protocol
(DHCP) 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 may not be possible.
DNS-based Discovery:
Before a DNS lookup can be started it is necessary to learn the
domain name of the access network that runs a LIS. Several ways
to learn the domain name exist. For example, the end host obtains
its own public IP address, for example via STUN [6], and performs
a reverse DNS lookup (assuming the data is provisioned into the
DNS). Then, the SRV or NAPTR record for that domain is retrieved.
A more detailed description of this approach can be found in [7].
Redirect Rule:
A redirect rule at a device in the access network, for example at
the AAA client, could be used to redirect the L7 LCP signalling
messages (destined to a specific port) to the LIS. The end host
could then discover the LIS by sending a packet with a specific
(registered) port number to almost any address (as long as the
destination IP address does not target a device 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.
To some extend this approach is similar to packets that are marked
with a Router Alert option [8] and intercepted by entities that
understand the specific marking. In the above-mentioned case,
however, the marking is provided via a registered port number
instead of relying on a Router Alert option.
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 11]

Internet-Draft Geopriv L7 LCP; Problem Statement June 2008
Multicast Query:
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
DNS (see [9] and [10]). Unfortunately, these mechanisms only work
on the local link.
Anycast:
With this solution an anycast address is defined (for IPv4 and
IPv6) in the style of [11] that allows the endhost to route
discovery packets to the nearest LIS. Note that this procedure
would be used purely for discovery and thereby similar to local
Teredo server discovery approach outlined in Section 4.2 of [12].
The LIS discovery procedure raises deployment and security issues.
The access network needs to be designed to prevent man-in-the-middle
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
ensure) that the discovered entity is indeed an authorized LIS.
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 12]

Internet-Draft Geopriv L7 LCP; Problem Statement June 20085. 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 retrieve the Target's current location (or a good
approximation of it) from a database.
The chosen identifier needs to have the following properties:
Ability for Target to learn or know the identifier:
The Target 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 internally for location
determination, in addition to the one provided by the Target.
Security properties of the identifier:
Misuse needs to be minimized whereby off-path adversary MUST NOT
be able to obtain location information of other Targets. A on-
path adversary in the same subnet SHOULD NOT be able to spoof the
identifier of another Target in the same subnet.
The following list discusses frequently mentioned identifiers and
their properties:
Host MAC Address:
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
deployment environments (unless carried in the L7 LCP itself).
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
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 13]

Internet-Draft Geopriv L7 LCP; Problem Statement June 2008
(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 may not be visible to the end host.
Host Identifier:
The Host Identifier introduced by the Host Identity Protocol [13]
allows identification of a particular host. Unfortunately, the
network can only use this identifier for location determination if
the operator already stores a mapping of host identities to
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 [14]. 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. It is only available for IPv6 addresses.
Network Access Identifiers:
A Network Access Identifier [15] is used during the network access
authentication procedure, for example in RADIUS [16] and Diameter
[17]. In DSL networks the user credentials are, in many cases,
only known by the home router and not configured at the Target
itself. To the network, the authenticated user identity is only
available if a network access authentication procedure is
executed. In case of roaming the user's identity might not be
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 14]

Internet-Draft Geopriv L7 LCP; Problem Statement June 2008
available to the access network since security protocols might
offer user identity confidentiality and thereby hiding the real
identity of the user allowing the access network to only see a
pseudonym or a randomized string.
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 Section 3.4.4 of the TR-069v2 DSL Forum document.
It also has a requirement that routers that use DHCP to the WAN
use RFC 4361 [18] to provide the DHCP server with a unique client
identifier. This identifier is, however, not visible to the
Target when legacy NTE device are used.
IP Address:
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
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
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 expected behavior. The property of the IP address
for a return routability check is attractive to return location
information only to the address that submitted the request. If an
adversary wants to learn the location of a Target (as identified
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
path towards the LIS).
On a shared medium an adversary could ask for location information
of another Target. The adversary would be able to see the
response message since it is sniffing on the shared medium unless
security mechanisms, such as link layer encryption, are in place.
With a network deployment as shown in Section 3.1 with multiple
hosts in the Customer Premises being behind a NAT the LIS is
unable to differentiate the individual end points. For WLAN
deployments 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 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.
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 15]

Internet-Draft Geopriv L7 LCP; Problem Statement June 20086. Requirements
The following requirements and assumptions have been identified:
Requirement L7-1: Identifier Choice
The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding
the latter aspect, such 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 L7 LCP 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: ASP and Access Network Provider Relationship
The design of the L7 LCP MUST NOT assume a business or trust
relationship between the Application Service Provider (ASP) and
the Access Network Provider. Requirements for resolving a
reference to location information are not discussed in this
document.
Requirement L7-4: Layer 2 and Layer 3 Provider Relationship
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
provider operates the LIS that the Target queries. It, in turn,
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.
Requirement L7-5: Legacy Device Considerations
The design of the L7 LCP MUST consider legacy devices, such as
residential NAT devices and NTEs in a DSL environment, that cannot
be upgraded to support additional protocols, for example, to pass
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 16]

Internet-Draft Geopriv L7 LCP; Problem Statement June 2008
additional information towards the Target.
Requirement L7-6: VPN Awareness
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,
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 L7 LCP MUST NOT assume prior network access
authentication.
Requirement L7-8: Network Topology Unawareness
The design of the L7 LCP 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
[6] or NSIS NATFW NSLP [19] .
Requirement L7-9: Discovery Mechanism
The L7 LCP MUST define a mandatory-to-implement LIS discovery
mechanism.
Requirement L7-10: PIDF-LO Creation
When a LIS creates a PIDF-LO [20] then it MUST put the <geopriv>
element into the <device> element of the presence document (see
[21]). This ensures that the resulting PIDF-LO document, which is
subsequently distributed to other entities, conforms to the rules
outlined in [22].
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 17]

Internet-Draft Geopriv L7 LCP; Problem Statement June 20087. Security Considerations
This document contains security related requirements. A discussion
about security aspects of the HELD protocol when used in the GEOPRIV
architecture when applied to certain usage environments, such as
emergency services, can be found in [23].
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 18]

Internet-Draft Geopriv L7 LCP; Problem Statement June 200810. Acknowledgements
We would like to thank 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, for setting up Jabber chat
conferences and for participating in the phone conference
discussions.
We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin
Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl,
Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard,
Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara
Stark, Michael Haberler, and Mary Barnes for their WGLC review
comments.
The authors would like to thank NENA for their work on [24] as it
helped to provide some of the initial thinking.
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 21]

Internet-Draft Geopriv L7 LCP; Problem Statement June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Tschofenig & Schulzrinne Expires December 31, 2008 [Page 25]