Location Information Server (LIS) Discovery using IP address and Reverse DNS
draft-thomson-geopriv-res-gw-lis-discovery-03

Abstract

The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.

This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 31, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  Conventions used in this document
3.  Problem Statement
    3.1.  Residential Gateway
    3.2.  Use of Discovery for Third Party Queries
    3.3.  Additional and Optional Constraints
4.  IP-based DNS Solution
    4.1.  Identification of IP Addresses
    4.2.  Domain Name Selection
    4.3.  When To Use This Method
    4.4.  Necessary Assumptions and Restrictions
    4.5.  Failure Modes
    4.6.  Deployment Considerations
5.  IANA Considerations
6.  Security Considerations
7.  IAB Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

A Location Information Server (LIS) is a service provided by an access network. The LIS uses knowledge of the access network topology and other information to generate location for Devices. Devices within an access network are able to acquire location information from a LIS.

The relationship between a Device and an access network might be transient. Configuration of the correct LIS at the Device ensures that accurate location information is available. Without location information, some network services are not available.

The configuration of a LIS address on a Device requires some automated configuration process. This is particularly relevant when it is considered that Devices might move between different access networks. LIS Discovery (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) [I‑D.ietf‑geopriv‑lis‑discovery] describes a method that employs the Dynamic Host Configuration Protocol (DHCPv4 (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131], DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315]) as input to U-NAPTR [RFC4848] (Daigle, L., “Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS),” April 2007.) discovery.

A residential gateway, or home router, provides a range of networking functions for Devices within the network it serves. In most cases, these functions effectively prevent the successful use of DHCP for LIS discovery.

The drawback with DHCP is that universal deployment of a new option takes a considerable amount of time. Often, networking equipment needs to be updated in order to support the new option. Of particular concern are the millions of residential gateway devices used to provide Internet access to homes and businesses. While [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) describes functions that can be provided by residential gateways to support LIS discovery, gateways built before the publication of this specification do not (and cannot) provide these functions.

This document explores the problem of configuring Devices with a LIS address when a residential gateway is interposed between the Device and access network. Section 3 (Problem Statement) defines the problem and Section 4 (IP-based DNS Solution) describes a method for determining a domain name that can be used for discovery of the LIS.

In some cases, the solution described in this document is based on a UNilateral Self-Address Fixing (UNSAF) (Daigle, L. and IAB, “IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation,” November 2002.) [RFC3424] method. For those cases, this solution is considered transitional until such time as the recommendations for residential gateways in [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) are more widely deployed. Considerations relating to UNSAF applications are described in Section 7 (IAB Considerations).

2.  Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This document uses terminology established in [RFC3693] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.) and [RFC5012] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” January 2008.).

3.  Problem Statement

Figure 1 (Simplified Network Topology) shows a simplified network topology for fixed wire-line Internet access. This arrangement is typical when wired Internet access is provided. The diagram shows two network segments: the access network provided by an internet service provider (ISP), and the residential network served by the residential gateway.

There are a number of variations on this arrangement, as documented in Section 3.1 of [I‑D.ietf‑geopriv‑l7‑lcp‑ps] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.). In each of these variations the goal of LIS discovery is to identify the LIS in the access network.

                 ________
               (/        \)
              (( Internet ))
               (\________/)
                    |
                    |
              .- - -|- - - - - - - - - - - -.
             (      |                        )
            (   +--------+       +-------+    )
  Access    (   | Access |. . . .|  LIS  |    )
  Network   (   |  Node  |       |       |    )
   (ISP)    (   +--------+       +-------+    )
             (       \               \       )
              `- - - -\- - - - - - - -\- - -'
                       \               \
                        \               |
               .- - - - -\- - - - - - - + -.
              (           \             |   )
             (      +-------------+     :    )
             (      | Residential |     |    )
 Residential (      |   Gateway   |     :    )
   Network   (      +-------------+     |    )
             (         /        \      /     )
             (        /          \    /      )
             (   +--------+    +--------+    )
             (   | Device |    | Device |    )
             (   +--------+    +--------+    )
              (                             )
               `- - - - - - - - - - - - - -'

A particularly important characteristic of this arrangement is the relatively small area served by the residential gateway. Given a small enough area, it is reasonable to delegate the responsibility for providing Devices within the residential network with location information to the ISP. The ISP is able to provide location information that identifies the residence, which should be adequate for a wide range of purposes.

A residential network that covers a larger area might require a dedicated LIS, a case that is outside the scope of this document.

The goal of LIS discovery is to identify a LIS that is able to provide the Device with accurate location information. In the network topology described, this means identifying the LIS in the access network. The residential gateway is a major obstacle in achieving this goal.

3.1.  Residential Gateway

A residential gateway can encompass several different functions including: modem, Ethernet switch, wireless access point, router, network address translation (NAT), DHCP server, DNS relay and firewall. Of the common functions provided, the NAT function of a residential gateway has the greatest impact on LIS discovery.

An ISP is typically parsimonious about their IP address allocations; each customer is allocated a limited number of IP addresses. Therefore, NAT is an extremely common function of gateways. NAT enables the use of multiple Devices within the residential network. However NAT also means that Devices within the residence are not configured by the ISP directly.

When it comes to discovering a LIS, the fact that Devices are not configured by the ISP causes a significant problem. Configuration is the ideal method of conveying the information necessary for discovery. Devices attached to residential gateways are usually given a generic configuration that includes no information about the ISP network. For instance, DNS configuration typically points to a DNS relay on the gateway device. This approach ensures that the local network served by the gateway is able to operate without a connection to the ISP, but it also means that Devices are effectively ignorant of the ISP network.

[I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) describes several methods that can be applied by a residential gateway to assist Devices in acquiring location information. For instance, the residential gateway could forward LIS address information to hosts within the network it serves. Such an active involvement in the discovery process only works for new residential gateway devices that implement these recommendations.

Where residential gateways already exist, direct involvement of the gateway in LIS discovery requires that the residential gateway be updated or replaced. The cost of replacement is difficult to justify to the owner of the gateway, especially when it is considered that the gateway still fills its primary function: Internet access.

Existing residential gateways have proven to be quite reliable devices, some operating continuously for many years without failure. As a result, there are many operational gateways that are of a considerable age, some well outside the period of manufacturer support. Updating the software in such devices is not feasible in many cases. Even if software updates were made available, many residential gateways cannot be updated remotely, inevitably leading to some proportion that is not updated.

This document therefore describes a method which can be used by Devices to discover their LIS without any assistance from the network.

3.2.  Use of Discovery for Third Party Queries

It is desirable that any discovery mechanism is capable of being used by hosts outside of the access network. This facilitates third party queries (see [I‑D.ietf‑geopriv‑held‑identity‑extensions] (Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, “Use of Device Identity in HTTP-Enabled Location Delivery (HELD),” February 2010.)) by enabling identification of the appropriate LIS.

For example, in some jurisdictions, interim solutions for emergency services require that a voice service provider (VSP) or public safety answering point (PSAP) be able to request location information from the access network provider. These architectures mandate third party queries to accommodate calling devices that are unable to acquire their own location information and subsequently convey [I‑D.ietf‑sipcore‑location‑conveyance] (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” February 2010.) that information within call signalling.

This document therefore describes a method which may also be used by third parties to discover the appropriate LIS based on the network address of the Device.

Note that an access network that fully supports DHCP-based LIS discovery [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) might not need to provide a secondary discovery mechanism. However this method SHOULD be provided for the benefit of third parties and for Devices that are unable to use DHCP-based LIS discovery.

3.3.  Additional and Optional Constraints

Certain other properties of residential gateways constrain the potential solutions to this problem.

A network firewall function is often provided by residential gateways as a security measure. Security features like intrusion detection systems help protect users from attacks. Amongst these protections is a port filter that prevents both inbound and outbound traffic on certain TCP and UDP ports. Therefore, any solution needs to consider the likelihood of traffic being blocked.

4.  IP-based DNS Solution

LIS discovery (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) [I‑D.ietf‑geopriv‑lis‑discovery] uses a DNS-based Dynamic Delegation Discovery Service (DDDS) system as the basis of discovery. Input to this process is a domain name. Use of DHCP for acquiring the domain name is specified, but alternative methods of acquisition are permitted.

This document specifies a means for a device to discover several alternative domain names that can be used as input to the DDDS process. These domain names are based on the IP address of the Device. Specifically, the domain names are a portion of the reverse DNS trees - either the .in-addr.arpa. or .ip6.arpa. tree.

A Device might be reachable at one of a number of IP addresses. In the process described, a Device first identifies each IP address that it is potentially reachable from. From each of these addresses, the Device then selects up to three domain names for use in discovery. These domain names are then used as input to the DDDS process.

4.1.  Identification of IP Addresses

A Device identifies a set of potential IP addresses that currently result in packets being routed to it. These are ordered by proximity, with those addresses that are used in adjacent network segments being favoured over those used in public or remote networks. The first addresses in the set are those that are assigned to local network interfaces.

A Device can use the Session Traversal Utilities for NAT (STUN) [RFC5389] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.) to determine its public reflexive transport address. The host uses the Binding Request message and the resulting XOR-MAPPED-ADDRESS parameter that is returned in the response.

Alternative methods for determining other IP addresses MAY be used by the host. Universal Plug and Play (UPnP) (UPnP Forum, “Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0: WANIPConnection:1 Service Template Version 1.01 For UPnP Version 1.0,” Nov 2001.) [UPnP‑IGD‑WANIPConnection1] and NAT Port Mapping Protocol (NAT-PMP) (Cheshire, S., “NAT Port Mapping Protocol (NAT-PMP),” April 2008.) [I‑D.cheshire‑nat‑pmp] are both able to provide the external address of a residential gateway device when enabled. These as well as proprietary methods for determining other addresses might also be available. Because there is no assurance that these methods will be supported by any access network these methods are not mandated. Note also that in some cases, methods that rely on the view of the network from the residential gateway device could reveal an address in a private address range (see Section 4.4 (Necessary Assumptions and Restrictions)).

In many instances, the IP address produced might be from a private address range. For instance, the address on a local network interface could be from a private range allocated by the residential gateway. In other cases, methods that rely on the view of the network (UPnP, NAT-PMP) from the residential gateway device could reveal an address in a private address range if the access network also uses NAT. For a private IP address, the derived domain name is only usable where the DNS server used contains data for the corresponding private IP address range.

4.2.  Domain Name Selection

The domain name selected for each resulting IP address is the name that would be used for a reverse DNS lookup. The domain name derived from an IP version 4 address is in the .in-addr.arpa. tree and follows the construction rules in Section 3.5 of [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.). The domain name derived from an IP version 6 address is in the .ip6.arpa. tree and follows the construction rules in Section 2.5 of [RFC3596] (Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, “DNS Extensions to Support IP Version 6,” October 2003.).

Additional domain names are added to allow for a single record to cover a larger set of addresses. If the search on the domain derived from the full IP address does not produce a NAPTR record with the desired service tag (e.g., LIS:HELD), a similar search is repeated based on a shorter domain name, using a part of the IP address:

• For IP version 4, the resulting domain name SHOULD be shortened successively by one and two labels and the query repeated. This corresponds to a search on a /24 or /16 network prefix. This allows for fewer DNS records in the case where a single access network covering an entire /24 or /16 network is served by the same LIS.
• For IP version 6, the resulting domain SHOULD be shortened sucessively by 16, 20 and 24 labels and the query repeated. This corresponds to a search on a /64, /48 or /32 network prefix.

DNS queries on other prefixes than those listed above SHOULD NOT be performed to limit the number of DNS queries performed by Devices. If no LIS is discovered by this method, no more than four U-NAPTR resolutions are invoked for each IP address.

4.3.  When To Use This Method

The DHCP method described in [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) SHOULD be attempted on all local network interfaces before attempting this method. This method is employed either because DHCP is unavailable, when the DHCP server does not provide a value for the access network domain name option, or if a request to the resulting LIS results in a HELD notLocatable error or equivalent.

This method can also be used to facilitate third party queries, as described in Section 3.2 (Use of Discovery for Third Party Queries). Based on a known IP address, the LIS that serves that address can be identified as long as the corresponding NAPTR records are provided.

4.4.  Necessary Assumptions and Restrictions

When used by a Device for LIS discovery this is an UNSAF application and is subject to the limitations described in Section 7 (IAB Considerations).

It is not necessary that the IP address used is unique to the Device, only that the address can be somehow related to the Device or the access network that serves the Device. This allows a degree of flexibility in determining this value, although security considerations (Security Considerations) might require that the address be verified to prevent falsification.

Addresses from private address space (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) [RFC1918] MAY be used as input to this method. However, it is assumed that a DNS server with a view of the same address space is used in order to provide the corresponding DNS mappings; the public DNS does not contain useful records for all possible address spaces.

This does not preclude the use of private address spaces; use of a private address space in discovery can provide an access network operator more granular control over discovery. This assumes that the DNS server used in the U-NAPTR resolution is able to view the address realm. Addresses from the public address space are more likely to be able to be resolved by any DNS server. Thus, use of the public reflexive transport addresses acquired from a STUN server provide better chance of the DNS server being able to produce a usable result. Therefore, access to a STUN server that is able to view addresses from the public Internet is necessary.

This solution assumes that the public reflexive transport address used by a Device is in some way controlled by their ISP, or some other related party. This implies that the corresponding .in-addr.arpa. or .ip6.arpa. record can be updated by that entity to include a useful value for the LIS address.

4.5.  Failure Modes

Successful use of private addresses relies on a DNS server that is able to see the private address space; therefore, a means to determine a public IP address is necessary. This document relies on STUN to provide the Device with a public reflexive transport address. Configuration of STUN server is necessary to ensure that this is successful.

Alternative methods for discovering external IP addresses are possible, including UPnP and NAT-PMP. However, these methods might not be enabled on the residential gateway; thus, these methods cannot be relied upon.

In cases where a virtual private network (VPN) or other tunnel is used, the entity providing a public IP address might not be able to provide the Device with location information. It is assumed that this entity is able to identify this problem and indicate this to the Device (using the notLocatable HELD error, or similar). This problem is described in more detail in [I‑D.ietf‑geopriv‑http‑location‑delivery] (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.).

4.6.  Deployment Considerations

An access network provider SHOULD provide NAPTR records for each public IP address that is used for Devices within the access network. If the access network provider uses NAT, any DNS internal to that NAT SHOULD also include records for the private address range.

NAPTR records can be provided for individual IP addresses. To limit the proliferation of identical records, a single record can be placed at a the higher nodes of the tree (corresponding to /24 and /16 for IPv4; /64, /48 and /32 for IPv6). A record at a higher point in the tree (those with a shorter prefix) applies to all addresses lower in the tree (those with a longer prefix); records at the lower point override those at higher points, allowing for exceptions to be provided for at the lower point.

5.  IANA Considerations

[RFC Editor: please remove this section prior to publication.]

This document has no IANA actions.

6.  Security Considerations

The security considerations described in [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) apply to the discovery process as a whole. In addition to those considerations, this document introduces further security considerations relating to the identification of the IP address. It is possible that an attacker could attempt to mislead a Device about its IP addresses in an attempt to subvert the rest of the process.

[RFC5389] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.) describes attacks where an attacker is able to ensure that a Device receives a falsified reflexive address. Even if the STUN server is trusted, an attacker might be able to ensure that a falsified address is provided to the Device.

This attack is an effective means of denial of service, or a means to provide a deliberately misleading service. Notably, any LIS that is identified based on a falsified IP address could still be a valid LIS for the given IP address, just not one that is useful for providing the Device with location information. In this case, the LIS provides a HELD notLocatable error, or an equivalent. If the falsified IP address is under the control of the attacker, it is possible that misleading (but verifiable) DNS records could indicate a malicious LIS that provides false location information.

In all cases of falsification, the best remedy is to perform some form of independent verification of the result. No specific mechanism is currently available to prevent attacks based on falsification of reflexive addresses; it is suggested that Devices attempt to independently verify that the reflexive transport address provided is accurate.

Use of private address space effectively prevents use of the usual set of trust anchors for DNSSEC. Only a DNS server that is able to see the same private address space can provide useful records. A Device that relies on DNS records in the private address space portion of the .in-addr.arpa. or .ip6.arpa. trees MUST either use an alternative trust anchor for these records or rely on other means of ensuring the veracity of the DNS records.

7.  IAB Considerations

The IAB has studied the problem of Unilateral Self-Address Fixing (UNSAF) (Daigle, L. and IAB, “IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation,” November 2002.) [RFC3424], which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism, such as STUN.

This section only applies to the use of this method of LIS discovery by Devices and does not apply to its use for third-party LIS discovery.

The IAB requires that protocol specifications that define UNSAF mechanisms document a set of considerations.

1. Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal.
   
   Section 3 (Problem Statement) describes the limited scope of the problem addressed in this document.
2. Description of an exit strategy/transition plan.
   
   [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) describes behaviour that residential gateways require in order for this short term solution to be rendered unnecessary. When implementations of the recommendations in LIS discovery are widely available, this UNSAF mechanism can be made obsolete.
3. Discussion of specific issues that may render systems more "brittle".
   
   A description of the necessary assumptions and limitations of this solution are included in Section 4.4 (Necessary Assumptions and Restrictions).
   
   Use of STUN for discovery of a reflexive transport address is inherently brittle in the presence of multiple NATs or address realms. In particular, brittleness is added by the requirement of using a DNS server that is able to view the address realm that contains the IP address in question. If address realms use overlapping addressing space, then there is a risk that the DNS server provides information that is not useful to the Device.
4. Identify requirements for longer term, sound technical solutions; contribute to the process of finding the right longer term solution.
   
   A longer term solution is already provided in [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.). However, that solution relies on widespread deployment. The UNSAF solution provided here is provided as an interim solution that enables LIS access for Devices that are not able to benefit from deployment of the recommendations in [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.).
5. Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports.
   
   The UNSAF mechanism depends on the experience in deployment of STUN (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.) [RFC5389]. On the whole, existing residential gateway devices are able to provide access to STUN and DNS service reliably, although regard should be given to the size of the DNS response (see [RFC5625] (Bellis, R., “DNS Proxy Implementation Guidelines,” August 2009.)).

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses