--- 1/draft-ietf-geopriv-res-gw-lis-discovery-03.txt 2012-09-25 16:14:12.413425470 +0200 +++ 2/draft-ietf-geopriv-res-gw-lis-discovery-04.txt 2012-09-25 16:14:12.445425414 +0200 @@ -1,20 +1,20 @@ GEOPRIV M. Thomson Internet-Draft Microsoft Intended status: Informational R. Bellis -Expires: September 30, 2012 Nominet UK - March 29, 2012 +Expires: March 29, 2013 Nominet UK + September 25, 2012 Location Information Server (LIS) Discovery using IP address and Reverse DNS - draft-ietf-geopriv-res-gw-lis-discovery-03 + draft-ietf-geopriv-res-gw-lis-discovery-04 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. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on September 30, 2012. + This Internet-Draft will expire on March 29, 2013. Copyright Notice Copyright (c) 2012 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 @@ -58,21 +58,21 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6 3.2. Residential Gateway Security Features . . . . . . . . . . 7 4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 8 4.1. Identification of IP Addresses . . . . . . . . . . . . . . 8 4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9 - 4.3. When To Use This Method . . . . . . . . . . . . . . . . . 9 + 4.3. When To Use The Reverse DNS Method . . . . . . . . . . . . 9 4.4. Private Address Spaces . . . . . . . . . . . . . . . . . . 10 4.5. Necessary Assumptions and Restrictions . . . . . . . . . . 11 4.6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Deployment Considerations . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 @@ -84,41 +84,41 @@ 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 [RFC5986] describes a method that employs - the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131], DHCPv6 - [RFC3315]) as input to U-NAPTR [RFC4848] discovery. + The configuration of a LIS IP address on a Device requires some + automated process. This is particularly relevant when it is + considered that Devices might move between different access networks + served by different LISs. LIS Discovery [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. In most cases, - these functions effectively prevent the successful use of DHCP for - LIS discovery. + functions for Devices within the network it serves. Unfortunately 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 + 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 do not (and cannot) provide these - functions. + 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 @@ -173,29 +173,30 @@ ( / \ / ) ( +--------+ +--------+ ) ( | Device | | Device | ) ( +--------+ +--------+ ) ( ) `- - - - - - - - - - - - - -' Figure 1: Simplified Network Topology 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. + 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 area might require a - dedicated LIS, a case that is outside the scope of this document. + 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. 3.1. Residential Gateway A residential gateway can encompass several different functions @@ -218,23 +219,24 @@ 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. [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. Such an - active involvement in the discovery process only works for new - residential gateway devices that implement these recommendations. + 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. 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 @@ -279,35 +281,36 @@ 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] 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. + [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 host. Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] - and NAT Port Mapping Protocol (NAT-PMP) [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.5). + the Device. Universal Plug and Play (UPnP) + [UPnP-IGD-WANIPConnection1] and NAT Port Mapping Protocol (NAT-PMP) + [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.5). 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. @@ -315,44 +318,45 @@ 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]. 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]. - Additional domain names are added to allow for a single record to + Additional domain names are added to allow for a single DNS 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: o 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. o For IP version 6, the resulting domain SHOULD be shortened sucessively by 16, 18, 20 and 24 labels and the query repeated. This corresponds to a search on a /64, /56, /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. + performed in order 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 four U-NAPTR resolutions are invoked for each IP + address. -4.3. When To Use This Method +4.3. When To Use The Reverse DNS Method The DHCP method described in [RFC5986] 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. 4.4. Private Address Spaces @@ -435,31 +439,31 @@ 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 [RFC5985]. 4.7. 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. + If the access network provider uses NAT, any DNS server 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. + override those at higher points, thus allowing for exceptions to be + specified. 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 [RFC5986] apply to the @@ -474,29 +478,29 @@ further security considerations relating to the identification of the IP address. It is possible that an attacker could attempt to provide a falsified IP addresses 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. 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. + 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. 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 @@ -624,22 +628,23 @@ Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010. [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. [I-D.cheshire-nat-pmp] - Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", - draft-cheshire-nat-pmp-03 (work in progress), April 2008. + Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol + (NAT-PMP)", draft-cheshire-nat-pmp-05 (work in progress), + September 2012. [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009. Authors' Addresses Martin Thomson Microsoft 3210 Porter Drive Palo Alto, CA 94304