GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements

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: It is used to obtain location information (referred as "Location by Value" or LbyV) from a dedicated node, called the Location Information Server (LIS). 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 . The need for these two functions can be derived from the scenarios presented in . For this document we assume that the GEOPRIV Layer 7 LCP runs between the end host (i.e., the Target in terminology) and the LIS. This document is structured as follows. discusses the challenge of discovering the LIS in the access network. 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 . 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.

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 , 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 (such as Target) and (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 shows scenario where the separation between IAP and ISP is important.

This section describes a few network scenarios where the L7 LCP may be used. Note that this section does not aim to exhaustively list all possible deployment environments. Instead we focus on the following environments: DSL/Cable networks, WiMax-like fixed access Airport, City, Campus Wireless Networks, such as 802.11a/b/g, 802.16e/Wimax 3G networks Enterprise networks We illustrate a few examples below.

shows a DSL network scenario with the Access Network Provider and the customer premises. The Access Network Provider operates link and network layer devices (represented as Node) and the LIS.

Access Network Provider demarc | +-------+-------------------+ | | | | +-------------+ | | | NTE | | | +-------------+ | | | | | | | | +--------------+ | | | Device with | Home | | | NAPT and | Router | | | DHCP server | | | +--------------+ | | | | | | | | +------+ | | | End | | | | Host | | | +------+ | | | |Customer Premises Network | | | +---------------------------+ ]]> The customer premises consists of a router with a Network Address Translator with Port Address Translation (NAPT) and a DHCP server as used in most Customer Premises Networks (CPN) and the Network Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 protocols are terminated. The router in the home network (e.g., broadband router, cable or DSL router) typically runs a NAPT and a DHCP server. The NTE is a legacy device and in many cases cannot be modified for the purpose of delivering location information to the 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: Single PC 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 with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC] Note that the device with NAPT and DHCP of is not present in such a scenario. 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) combined router and NTE separate router with NTE in bridged mode 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.

One example of a moving network is a WiMAX fixed wireless scenario. This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless 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. shows an example topology for a moving network.

shows a wireless access network where a moving end host obtains location information or references to location information from the LIS. The access equipment uses, in many cases, link layer devices. represents a hotspot network found, for example, in hotels, airports, and coffee shops. For editorial reasons we only describe a single access point and do not depict how the LIS obtains location information since this is very deployment specific.

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. 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 , a DHCP based discovery solution may not be possible. 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 , 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 . 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 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. 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 and ). Unfortunately, these mechanisms only work on the local link. With this solution an anycast address is defined (for IPv4 and IPv6) in the style of 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 . 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.

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: 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. 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. 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: 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). The VPI/VCI is generally only seen by the DSL modem. Almost all routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35. This VC is terminated at the DSLAM, which uses a different VPI/VCI (per end customer) to connect to the ATM switch. Only the network provider is able to map VPI/VCI values through its network. With the arrival of VDSL, ATM will slowly be phased out in favor of Ethernet. 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. This identifier is available in cellular data networks and the cell ID may not be visible to the end host. The Host Identifier introduced by the Host Identity Protocol 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. The concept of a Cryptographically Generated Address (CGA) was introduced by . 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. A Network Access Identifier is used during the network access authentication procedure, for example in RADIUS and Diameter . 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 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. 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 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. 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 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 , 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.

The following requirements and assumptions have been identified: 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. 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. 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. 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. 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 additional information towards the Target. 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. The design of the L7 LCP MUST NOT assume prior network access authentication. 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 or NSIS NATFW NSLP . The L7 LCP MUST define a mandatory-to-implement LIS discovery mechanism. When a LIS creates a PIDF-LO then it MUST put the <geopriv> element into the <device> element of the presence document (see ). This ensures that the resulting PIDF-LO document, which is subsequently distributed to other entities, conforms to the rules outlined in .

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 .

This document does not require actions by IANA.

This contribution is a joint effort of the GEOPRIV Layer 7 Location Configuration Requirements Design Team of the IETF GEOPRIV Working Group. The contributors include Henning Schulzrinne, Barbara Stark, Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. We would like to thank the GEOPRIV working group chairs, Andy Newton, Randy Gellens and Allison Mankin, for creating the design team. The design team members can be reached at: mlinsner@cisco.com rohan@ekabal.com andy@hxr.us jon.peterson@neustar.biz br@brianrosen.net hgs@cs.columbia.edu Barbara.Stark@bellsouth.com Martin.Thomson@andrew.com Hannes.Tschofenig@nsn.com James.Winterbottom@andrew.com

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, Jérôme 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 as it helped to provide some of the initial thinking.