draft-ietf-geopriv-res-gw-lis-discovery-07.txt   draft-ietf-geopriv-res-gw-lis-discovery-08.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft Microsoft Internet-Draft Mozilla
Intended status: Standards Track R. Bellis Intended status: Standards Track R. Bellis
Expires: May 08, 2014 Nominet UK Expires: June 22, 2014 Nominet UK
November 04, 2013 December 19, 2013
Location Information Server (LIS) Discovery using IP address and Reverse Location Information Server (LIS) Discovery using IP address and Reverse
DNS DNS
draft-ietf-geopriv-res-gw-lis-discovery-07 draft-ietf-geopriv-res-gw-lis-discovery-08
Abstract Abstract
The residential gateway is a device that has become an integral part The residential gateway is a device that has become an integral part
of home networking equipment. Discovering a Location Information of home networking equipment. Discovering a Location Information
Server (LIS) is a necessary part of acquiring location information Server (LIS) is a necessary part of acquiring location information
for location-based services. However, discovering a LIS when a for location-based services. However, discovering a LIS when a
residential gateway is present poses a configuration challenge, residential gateway is present poses a configuration challenge,
requiring a method that is able to work around the obstacle presented requiring a method that is able to work around the obstacle presented
by the gateway. by the gateway.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 08, 2014. This Internet-Draft will expire on June 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3.2. Residential Gateway Security Features . . . . . . . . . . 6 3.2. Residential Gateway Security Features . . . . . . . . . . 6
4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 6 4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 6
4.1. Identification of IP Addresses . . . . . . . . . . . . . 7 4.1. Identification of IP Addresses . . . . . . . . . . . . . 7
4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 8 4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 8
4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 8 4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 8
4.4. When To Use The Reverse DNS Method . . . . . . . . . . . 9 4.4. When To Use The Reverse DNS Method . . . . . . . . . . . 9
4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 9 4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 9
4.6. Necessary Assumptions and Restrictions . . . . . . . . . 10 4.6. Necessary Assumptions and Restrictions . . . . . . . . . 10
4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 10 4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 10
4.8. Deployment Considerations . . . . . . . . . . . . . . . . 11 4.8. Deployment Considerations . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
A Location Information Server (LIS) is a service provided by an A Location Information Server (LIS) is a service provided by an
access network. The LIS uses knowledge of the access network access network. The LIS uses knowledge of the access network
topology and other information to generate location information for topology and other information to generate location information for
Devices. Devices within an access network are able to acquire Devices. Devices within an access network are able to acquire
location information from a LIS. location information from a LIS.
The relationship between a Device and an access network might be The relationship between a Device and an access network might be
skipping to change at page 4, line 14 skipping to change at page 4, line 14
Figure 1 shows a simplified network topology for fixed wire-line Figure 1 shows a simplified network topology for fixed wire-line
Internet access. This arrangement is typical when wired Internet Internet access. This arrangement is typical when wired Internet
access is provided. The diagram shows two network segments: the access is provided. The diagram shows two network segments: the
access network provided by an internet service provider (ISP), and access network provided by an internet service provider (ISP), and
the residential network served by the residential gateway. the residential network served by the residential gateway.
There are a number of variations on this arrangement, as documented 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 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. LIS discovery is to identify the LIS in the access network.
________ ________
(/ \) (/ \)
(( Internet )) (( Internet ))
(\________/) (\________/)
| |
| |
.- - -|- - - - - - - - - - - -. .- - -|- - - - - - - - - - - -.
( | ) ( | )
( +--------+ +-------+ ) ( +--------+ +-------+ )
Access ( | Access |. . . .| LIS | ) Access ( | Access |. . . .| LIS | )
Network ( | Node | | | ) Network ( | Node | | | )
(ISP) ( +--------+ +-------+ ) (ISP) ( +--------+ +-------+ )
( \ \ ) ( \ \ )
`- - - -\- - - - - - - -\- - -' `- - - -\- - - - - - - -\- - -'
\ \ \ \
\ | \ |
.- - - - -\- - - - - - - + -. .- - - - -\- - - - - - - + -.
( \ | ) ( \ | )
( +-------------+ : ) ( +-------------+ : )
( | Residential | | ) ( | Residential | | )
Residential ( | Gateway | : ) Residential ( | Gateway | : )
Network ( +-------------+ | ) Network ( +-------------+ | )
( / \ / ) ( / \ / )
( / \ / ) ( / \ / )
( +--------+ +--------+ ) ( +--------+ +--------+ )
( | Device | | Device | ) ( | Device | | Device | )
( +--------+ +--------+ ) ( +--------+ +--------+ )
( ) ( )
`- - - - - - - - - - - - - -' `- - - - - - - - - - - - - -'
Figure 1: Simplified Network Topology Figure 1: Simplified Network Topology
A particularly important characteristic of this arrangement is the A particularly important characteristic of this arrangement is the
relatively small geographical area served by the residential gateway. relatively small geographical area served by the residential gateway.
Given a small enough area, it is reasonable to delegate the Given a small enough area, it is reasonable to delegate the
responsibility for providing Devices within the residential network responsibility for providing Devices within the residential network
with location information to the ISP. The ISP is able to provide with location information to the ISP. The ISP is able to provide
location information that identifies the residence, which should be location information that identifies the residence, which should be
adequate for a wide range of purposes. adequate for a wide range of purposes.
skipping to change at page 7, line 36 skipping to change at page 7, line 36
The first addresses in the set are those that are assigned to local The first addresses in the set are those that are assigned to local
network interfaces. network interfaces.
A Device can use the Session Traversal Utilities for NAT (STUN) A Device can use the Session Traversal Utilities for NAT (STUN)
[RFC5389] mechanism to determine its public reflexive transport [RFC5389] mechanism to determine its public reflexive transport
address. The host uses the "Binding Request" message and the address. The host uses the "Binding Request" message and the
resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the
response. response.
Alternative methods for determining other IP addresses MAY be used by Alternative methods for determining other IP addresses MAY be used by
the Device. Universal Plug and Play (UPnP) the Device. Port Control Protocol (PCP) [RFC6887], Universal Plug
[UPnP-IGD-WANIPConnection1] and NAT Port Mapping Protocol (NAT-PMP) and Play (UPnP) [UPnP-IGD-WANIPConnection1] and NAT Port Mapping
[I-D.cheshire-nat-pmp] are both able to provide the external address Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] are both able to provide
of a residential gateway device when enabled. These as well as the external address of a residential gateway device when enabled.
proprietary methods for determining other addresses might also be These as well as proprietary methods for determining other addresses
available. Because there is no assurance that these methods will be might also be available. Because there is no assurance that these
supported by any access network, these methods are not mandated. methods will be supported by any access network, these methods are
Note also that in some cases, methods that rely on the view of the not mandated. Note also that in some cases, methods that rely on the
network from the residential gateway device could reveal an address view of the network from the residential gateway device could reveal
in a private address range (see Section 4.6). an address in a private address range (see Section 4.6).
In many instances, the IP address produced might be from a private In many instances, the IP address produced might be from a private
address range. For instance, the address on a local network address range. For instance, the address on a local network
interface could be from a private range allocated by the residential interface could be from a private range allocated by the residential
gateway. In other cases, methods that rely on the view of the gateway. In other cases, methods that rely on the view of the
network (UPnP, NAT-PMP) from the residential gateway device could network (UPnP, NAT-PMP) from the residential gateway device could
reveal an address in a private address range if the access network 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 also uses NAT. For a private IP address, the derived domain name is
only usable where the DNS server used contains data for the only usable where the DNS server used contains data for the
corresponding private IP address range. corresponding private IP address range.
skipping to change at page 9, line 46 skipping to change at page 9, line 46
Addresses from a private use address space can be used as input to Addresses from a private use address space can be used as input to
this method. In many cases, this applies to addresses defined in this method. In many cases, this applies to addresses defined in
[RFC1918], though other address ranges could have limited [RFC1918], though other address ranges could have limited
reachability where this advice also applies. This is only possible reachability where this advice also applies. This is only possible
if a DNS server with a view of the same address space is used. if a DNS server with a view of the same address space is used.
Public DNS servers cannot provide useful records for private Public DNS servers cannot provide useful records for private
addresses. addresses.
Using an address from a private space in discovery can provide a more 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 specific answer if the DNS server has records for that space.
2 shows a network configuration where addresses from an ISP network Figure 2 shows a network configuration where addresses from an ISP
could better indicate the correct LIS. Records in DNS B can be network could better indicate the correct LIS. Records in DNS B can
provided for the 10.0.0.0/8 range, potentially dividing that range so be provided for the 10.0.0.0/8 range, potentially dividing that range
that a more local LIS can be selected. so that a more local LIS can be selected.
_____ ________ _____ ________
( DNS ).....(/ \) Public ( DNS ).....(/ \) Public
(__A__) (( Internet )) Address (__A__) (( Internet )) Address
(\________/) Space (\________/) Space
| |
[NAT] [NAT]
_____ _____|_____ _____ _____|_____
( DNS )....(/ \) Private ( DNS )....(/ \) Private
(__B__) (( ISP Network )) Address Space (__B__) (( ISP Network )) Address Space
(\___________/) (e.g. 10.0.0.0/8) (\___________/) (e.g. 10.0.0.0/8)
| |
[Gateway] [Gateway]
____|____ ____|____
(/ \) Private (/ \) Private
(( Residence )) Address Space (( Residence )) Address Space
(\_________/) (e.g. 192.168.0.0/16) (\_________/) (e.g. 192.168.0.0/16)
Figure 2: Address Space Example Figure 2: Address Space Example
The goal of automatic DNS configuration is usually to select a local The goal of automatic DNS configuration is usually to select a local
DNS, which suits configurations like the one shown. However, use of DNS, which suits configurations like the one shown. However, use of
public DNS or STUN servers means that a public IP address is likely public DNS or STUN servers means that a public IP address is likely
to be found. For STUN in particular, selecting a public server to be found. For STUN in particular, selecting a public server
minimizes the need for reconfiguration when a Device moves. Adding minimizes the need for reconfiguration when a Device moves. Adding
records for the public address space used by an access network records for the public address space used by an access network
ensures that the discovery process succeeds when a public address is ensures that the discovery process succeeds when a public address is
skipping to change at page 11, line 34 skipping to change at page 11, line 34
private address range. These records might only be provided to private address range. These records might only be provided to
clients making requests from the private address range. Doing so clients making requests from the private address range. Doing so
allows clients within the private address range to discover a LIS allows clients within the private address range to discover a LIS
based on their IP address prior to any address translation. In based on their IP address prior to any address translation. In
geographically distributed networks that use a private address range, geographically distributed networks that use a private address range,
this enables the use of a different LIS for different locations, this enables the use of a different LIS for different locations,
based on the IP address range used at each location. Use of a based on the IP address range used at each location. Use of a
public, translated IP address for the network can still work, but it public, translated IP address for the network can still work, but it
might result in a suboptimal LIS selection. might result in a suboptimal LIS selection.
A network that operates network address translation SHOULD provide
NAPTR records that reference a LIS endpoint with a public address.
This requires the reservation of an IP and port for the LIS. To
ensure requests toward the LIS from within the private address space
do not traverse the NAT and have source addresses mapped by the NAT,
networks can provide direct route to the LIS. Clients that perform
discovery based on public DNS or STUN servers are thereby easier to
trace based on source address information.
NAPTR records can be provided for individual IP addresses. To limit NAPTR records can be provided for individual IP addresses. To limit
the proliferation of identical records, a single record can be placed the proliferation of identical records, a single record can be placed
at higher nodes of the tree (corresponding to /24 and /16 for IPv4; / at higher nodes of the tree (corresponding to /24 and /16 for IPv4; /
64, /56, /48 and /32 for IPv6). A record at a higher point in the 64, /56, /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 tree (those with a shorter prefix) applies to all addresses lower in
the tree (those with a longer prefix); records at the lower point the tree (those with a longer prefix); records at the lower point
override those at higher points, thus allowing for exceptions to be override those at higher points, thus allowing for exceptions to be
specified. specified.
5. IANA Considerations 5. IANA Considerations
[RFC Editor: please remove this section prior to publication.]
This document has no IANA actions. This document has no IANA actions.
6. Privacy Considerations 6. Privacy Considerations
As with all uses of geolocation information, it is very important As with all uses of geolocation information, it is very important
that measures be taken to ensure that location information is not that measures be taken to ensure that location information is not
provided to unauthorized parties. The mechanism defined in this provided to unauthorized parties. The mechanism defined in this
document is focused on the case where a device is learning its own document is focused on the case where a device is learning its own
location, so that it can provide that location information to location, so that it can provide that location information to
applications. We assume that the device learning its own location is applications. We assume that the device learning its own location is
not a privacy risk. There are then two remaining privacy risks: The not a privacy risk. There are then two remaining privacy risks: The
use of geolocation by applications, and abuse of the location use of geolocation by applications, and abuse of the location
configuration protocol. configuration protocol.
skipping to change at page 13, line 29 skipping to change at page 13, line 35
If the falsified IP address is under the control of the attacker, it If the falsified IP address is under the control of the attacker, it
is possible that misleading (but verifiable) DNS records could is possible that misleading (but verifiable) DNS records could
indicate a malicious LIS that provides false location information. indicate a malicious LIS that provides false location information.
In all cases of falsification, the best remedy is to perform some In all cases of falsification, the best remedy is to perform some
form of independent verification of the result. No specific form of independent verification of the result. No specific
mechanism is currently available to prevent attacks based on mechanism is currently available to prevent attacks based on
falsification of reflexive addresses; it is suggested that Devices falsification of reflexive addresses; it is suggested that Devices
attempt to independently verify that the reflexive transport address attempt to independently verify that the reflexive transport address
provided is accurate. An independent, trusted source of location provided is accurate. An independent, trusted source of location
information could aid in verification, even in the trusted source is information could aid in verification, even if the trusted source is
unable to provide information with the same accuracy as the unable to provide information with the same degree of accuracy as the
discovered LIS. discovered LIS.
Use of private address space effectively prevents use of the usual 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 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 see the same private address space can provide useful records. A
Device that relies on DNS records in the private address space Device that relies on DNS records in the private address space
portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use 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 an alternative trust anchor for these records or rely on other means
of ensuring the veracity of the DNS records. of ensuring the veracity of the DNS records.
skipping to change at page 15, line 46 skipping to change at page 16, line 18
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self- [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4848] Daigle, L., "Domain-Based Application Service Location [RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007. (DDDS)", RFC 4848, April 2007.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
skipping to change at page 16, line 26 skipping to change at page 16, line 46
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010. Requirements", RFC 5687, March 2010.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011. BCP 160, RFC 6280, 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-IGD-WANIPConnection1]
UPnP Forum, "Internet Gateway Device (IGD) Standardized UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0: WANIPConnection:1 Service Device Control Protocol V 1.0: WANIPConnection:1 Service
Template Version 1.01 For UPnP Version 1.0 ", DCP 05-001, Template Version 1.01 For UPnP Version 1.0", DCP 05-001,
Nov 2001. Nov 2001.
[I-D.cheshire-nat-pmp] [I-D.cheshire-nat-pmp]
Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
(NAT-PMP)", draft-cheshire-nat-pmp-07 (work in progress), (NAT-PMP)", draft-cheshire-nat-pmp-07 (work in progress),
January 2013. January 2013.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP
152, RFC 5625, August 2009. 152, RFC 5625, August 2009.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC
5985, September 2010. 5985, September 2010.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Microsoft Mozilla
3210 Porter Drive Suite 300
Palo Alto, CA 94304 650 Castro Street
Mountain View, CA 94041
US US
Phone: +1 650-353-1925
Email: martin.thomson@gmail.com Email: martin.thomson@gmail.com
Ray Bellis Ray Bellis
Nominet UK Nominet UK
Edmund Halley Road Edmund Halley Road
Oxford OX4 4DQ Oxford OX4 4DQ
United Kingdom United Kingdom
Phone: +44 1865 332211 Phone: +44 1865 332211
Email: ray.bellis@nominet.org.uk Email: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/ URI: http://www.nominet.org.uk/
 End of changes. 20 change blocks. 
80 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/