Internet Engineering Task Force (IETF) M. Thomson Request for Comments: 7216 Mozilla Category: Standards Track R. Bellis ISSN: 2070-1721 Nominet UK April 2014 Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS
AbstractThe 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 is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7216.
Copyright Notice Copyright (c) 2014 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 Simplified BSD License. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6 3.2. Security Features of Residential Gateways . . . . . . . . 7 4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 7 4.1. Identification of IP Addresses . . . . . . . . . . . . . 8 4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9 4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 9 4.4. When To Use the Reverse DNS Method . . . . . . . . . . . 10 4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 10 4.6. Necessary Assumptions and Restrictions . . . . . . . . . 11 4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 12 4.8. Deployment Considerations . . . . . . . . . . . . . . . . 12 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
RFC5986] describes a method that employs the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131], DHCPv6 [RFC3315]) as input to U-NAPTR [RFC4848] discovery. A residential gateway, or home router, provides a range of networking functions for Devices within the network it serves. Unfortunately, in most cases these functions effectively prevent the successful use of DHCP for LIS discovery. One 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 [RFC5986] describes functions that can be provided by residential gateways to support LIS discovery, gateways built before the publication of this specification are not expected (and are likely not able) to 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 defines the problem, and Section 4 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) [RFC3424] method. For those cases, this solution is considered transitional until such time as the recommendations for residential gateways in [RFC5986] are more widely deployed. Considerations relating to UNSAF applications are described in Section 7.
RFC2119]. This document uses terminology established in [RFC6280] and [RFC5012]. The terms "Device" and "LIS" are capitalized throughout when they are used to identify the roles defined in [RFC6280]. Figure 1 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 [RFC5687]. 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 | ) ( +--------+ +--------+ ) ( ) `- - - - - - - - - - - - - -' Figure 1: Simplified Network Topology A particularly important characteristic of this arrangement is the relatively small geographical 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 geographical 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. RFC5986] 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. Unfortunately, such an active involvement in the discovery process only works for new residential gateway devices that implement those 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. Furthermore, 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 that can be used by Devices to discover their LIS without any assistance from the network. RFC5986] 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. The goal of this process is to make a small number of DDDS queries in order to find a LIS. After LIS discovery using the DHCP-based process in [RFC5986] has failed, a Device can: 1. Collect a set of IP addresses that refer to the Device (Section 4.1). 2. Convert each IP address into DNS names in the "in-addr.arpa." or "ip6.arpa." tree (Section 4.2). 3. Perform the DDDS process for LIS discovery on those DNS names ([RFC5986]). 4. Shorten the DNS names by some number of labels and repeat the DDDS process (Section 4.3).
A Device might be reachable at one of a number of IP addresses. In the process described, a Device first identifies each IP address from which it is potentially reachable. 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. RFC5389] mechanism 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 Device. If enabled, the Port Control Protocol (PCP) [RFC6887], Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1], and NAT Port Mapping Protocol (NAT-PMP) [RFC6886] are each able to provide the external address of a residential gateway device. These, as well as proprietary methods for determining other addresses, might 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.6). 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 employed DNS server contains data for the corresponding private IP address range.
Section 3.5 of [RFC1035]. 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].
Similarly, the IPv6 address "2001:DB8::28e4:3a93:4429:dfb5" could result in queries to: o 5.b.f.d.188.8.131.52.3.9.a.3.4.e.184.108.40.206.0.0.0.0.0.0.8.b.d.0.1.0.0.2 .ip6.arpa. o 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. o 8.b.d.0.1.0.0.2.ip6.arpa. The limited number of labels by which each name is shortened is intended to limit the number of DNS queries performed by Devices. If no LIS is discovered by this method, the result will be that no more than five U-NAPTR resolutions are invoked for each IP address. RFC5986] MUST 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 because a request to the resulting LIS results in a HELD "notLocatable" error or equivalent. RFC1918], though other address ranges could have limited reachability where this advice also applies. This is only possible if a DNS server with a view of the same address space is used. Public DNS servers cannot provide useful records for private addresses. Using an address from a private space in discovery can provide a more specific answer if the DNS server has records for that space. Figure 2 shows a network configuration where addresses from an ISP network could better indicate the correct LIS. Records in DNS B can be provided for the 10.0.0.0/8 range, potentially dividing that range so that a more local LIS can be selected.
_____ ________ ( DNS ).....(/ \) Public (__A__) (( Internet )) Address (\________/) Space | [NAT] _____ _____|_____ ( DNS )....(/ \) Private (__B__) (( ISP Network )) Address Space (\___________/) (e.g., 10.0.0.0/8) | [Gateway] ____|____ (/ \) Private (( Residence )) Address Space (\_________/) (e.g., 192.168.0.0/16) Figure 2: Address Space Example The goal of automatic DNS configuration is usually to select a local DNS, which suits configurations like the one shown. However, use of public DNS or STUN servers means that a public IP address is likely to be found. For STUN in particular, selecting a public server minimizes the need for reconfiguration when a Device moves. Adding records for the public address space used by an access network ensures that the discovery process succeeds when a public address is used. Section 7. 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 (Section 6) might require that the address be verified to limit the chance of falsification. This solution assumes that the public, reflexive transport address used by a Device is in some way controlled by the access network provider 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.
the tree (those with a longer prefix); records at the lower point override those at higher points, thus allowing for exceptions to be specified. RFC6280]. The mechanism specified in this document allows a device to discover its local LIS, from which it then acquires its location using a Location Configuration Protocol (LCP) [RFC5687]. If an unauthorized third party can spoof the LCP to obtain a target's location information, then the mechanism in this document could allow them to discover the proper server to attack for a given IP address. Thus, it is important that a LIS meet the security requirements of the LCP it implements. For HELD, these requirements are laid out in Section 9 of [RFC5985]. A Device that discovers a LIS using the methods in this document MUST NOT provide that LIS with additional information that might reveal its position, such as the location measurements described in [RFC7105], unless it has a secondary method for determining the authenticity of the LIS, such as a white list. RFC5986] apply to the discovery process as a whole. The primary security concern is with the potential for an attacker to impersonate a LIS. The added ability for a third party to discover the identity of a LIS does not add any concerns, since the identity of a LIS is considered public information.
In addition to existing considerations, this document introduces further security considerations relating to the identification of the IP address. It is possible that an attacker could attempt to provide a falsified IP address in an attempt to subvert the rest of the process. [RFC5389] describes attacks where an attacker is able to ensure that a Device receives a falsified reflexive address. An on-path attacker might be able to ensure that a falsified address is provided to the Device. Even though STUN messages are protected by a STUN MESSAGE- INTEGRITY attribute, which is an HMAC that uses a shared secret, an on-path attacker can capture and modify packets, altering source and destination addresses to provide falsified addresses. This attack could result in 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. An independent, trusted source of location information could aid in verification, even if the trusted source is unable to provide information with the same degree of accuracy as the discovered LIS. 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. DNS queries that are not blocked as [RFC6303] demands, or directed to servers outside the network, can cause the addresses that are in use within the network to be exposed outside of the network. For resolvers within the network, implementing [RFC6303] avoids this issue; otherwise, the problem cannot be avoided without blocking DNS queries to external servers.
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 describes the limited scope of the problem addressed in this document. 2. Description of an exit strategy/transition plan. [RFC5986] describes behavior 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.6. 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 [RFC5986]. However, that solution relies on widespread deployment. The UNSAF solution provided here is an interim solution that enables LIS access for Devices that are not able to benefit from deployment of the recommendations in [RFC5986]. 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 [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]). Section 5. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010. [RFC7105] Thomson, M. and J. Winterbottom, "Using Device-Provided Location-Related Measurements in Location Configuration Protocols", RFC 7105, January 2014. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007. [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010. [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011. [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, July 2011. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. [UPnP-IGD-WANIPConnection1] 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", DCP 05-001, Nov. 2001, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v1-Service.pdf>. [RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol (NAT-PMP)", RFC 6886, April 2013.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009. [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010. http://www.nominet.org.uk/