idnits 2.17.1 draft-ietf-geopriv-res-gw-lis-discovery-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 19, 2013) is 3753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NAT' is mentioned on line 429, but not defined == Missing Reference: 'Gateway' is mentioned on line 435, but not defined == Unused Reference: 'RFC3693' is defined on line 713, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track R. Bellis 5 Expires: June 22, 2014 Nominet UK 6 December 19, 2013 8 Location Information Server (LIS) Discovery using IP address and Reverse 9 DNS 10 draft-ietf-geopriv-res-gw-lis-discovery-08 12 Abstract 14 The residential gateway is a device that has become an integral part 15 of home networking equipment. Discovering a Location Information 16 Server (LIS) is a necessary part of acquiring location information 17 for location-based services. However, discovering a LIS when a 18 residential gateway is present poses a configuration challenge, 19 requiring a method that is able to work around the obstacle presented 20 by the gateway. 22 This document describes a solution to this problem. The solution 23 provides alternative domain names as input to the LIS discovery 24 process based on the network addresses assigned to a Device. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 22, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions used in this document . . . . . . . . . . . . . . 3 62 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 5 64 3.2. Residential Gateway Security Features . . . . . . . . . . 6 65 4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Identification of IP Addresses . . . . . . . . . . . . . 7 67 4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 8 68 4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 8 69 4.4. When To Use The Reverse DNS Method . . . . . . . . . . . 9 70 4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 9 71 4.6. Necessary Assumptions and Restrictions . . . . . . . . . 10 72 4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 10 73 4.8. Deployment Considerations . . . . . . . . . . . . . . . . 11 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 10.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 A Location Information Server (LIS) is a service provided by an 87 access network. The LIS uses knowledge of the access network 88 topology and other information to generate location information for 89 Devices. Devices within an access network are able to acquire 90 location information from a LIS. 92 The relationship between a Device and an access network might be 93 transient. Configuration of the correct LIS at the Device ensures 94 that accurate location information is available. Without location 95 information, some network services are not available. 97 The configuration of a LIS IP address on a Device requires some 98 automated process. This is particularly relevant when one considers 99 that Devices might move between different access networks served by 100 different LISs. LIS Discovery [RFC5986] describes a method that 101 employs the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131], 102 DHCPv6 [RFC3315]) as input to U-NAPTR [RFC4848] discovery. 104 A residential gateway, or home router, provides a range of networking 105 functions for Devices within the network it serves. Unfortunately in 106 most cases these functions effectively prevent the successful use of 107 DHCP for LIS discovery. 109 One drawback with DHCP is that universal deployment of a new option 110 takes a considerable amount of time. Often, networking equipment 111 needs to be updated in order to support the new option. Of 112 particular concern are the millions of residential gateway devices 113 used to provide Internet access to homes and businesses. While 114 [RFC5986] describes functions that can be provided by residential 115 gateways to support LIS discovery, gateways built before the 116 publication of this specification are not expected (and are likely 117 not able) to provide these functions. 119 This document explores the problem of configuring Devices with a LIS 120 address when a residential gateway is interposed between the Device 121 and access network. Section 3 defines the problem and Section 4 122 describes a method for determining a domain name that can be used for 123 discovery of the LIS. 125 In some cases, the solution described in this document is based on a 126 UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those 127 cases, this solution is considered transitional until such time as 128 the recommendations for residential gateways in [RFC5986] are more 129 widely deployed. Considerations relating to UNSAF applications are 130 described in Section 8. 132 2. Conventions used in this document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 This document uses terminology established in [RFC6280] and 139 [RFC5012]. The terms Device and LIS are capitalized throughout when 140 they are used to identify the roles defined in [RFC6280]. 142 3. Problem Statement 143 Figure 1 shows a simplified network topology for fixed wire-line 144 Internet access. This arrangement is typical when wired Internet 145 access is provided. The diagram shows two network segments: the 146 access network provided by an internet service provider (ISP), and 147 the residential network served by the residential gateway. 149 There are a number of variations on this arrangement, as documented 150 in Section 3.1 of [RFC5687]. In each of these variations the goal of 151 LIS discovery is to identify the LIS in the access network. 153 ________ 154 (/ \) 155 (( Internet )) 156 (\________/) 157 | 158 | 159 .- - -|- - - - - - - - - - - -. 160 ( | ) 161 ( +--------+ +-------+ ) 162 Access ( | Access |. . . .| LIS | ) 163 Network ( | Node | | | ) 164 (ISP) ( +--------+ +-------+ ) 165 ( \ \ ) 166 `- - - -\- - - - - - - -\- - -' 167 \ \ 168 \ | 169 .- - - - -\- - - - - - - + -. 170 ( \ | ) 171 ( +-------------+ : ) 172 ( | Residential | | ) 173 Residential ( | Gateway | : ) 174 Network ( +-------------+ | ) 175 ( / \ / ) 176 ( / \ / ) 177 ( +--------+ +--------+ ) 178 ( | Device | | Device | ) 179 ( +--------+ +--------+ ) 180 ( ) 181 `- - - - - - - - - - - - - -' 183 Figure 1: Simplified Network Topology 185 A particularly important characteristic of this arrangement is the 186 relatively small geographical area served by the residential gateway. 187 Given a small enough area, it is reasonable to delegate the 188 responsibility for providing Devices within the residential network 189 with location information to the ISP. The ISP is able to provide 190 location information that identifies the residence, which should be 191 adequate for a wide range of purposes. 193 A residential network that covers a larger geographical area might 194 require a dedicated LIS, a case that is outside the scope of this 195 document. 197 The goal of LIS discovery is to identify a LIS that is able to 198 provide the Device with accurate location information. In the 199 network topology described, this means identifying the LIS in the 200 access network. The residential gateway is a major obstacle in 201 achieving this goal. 203 3.1. Residential Gateway 205 A residential gateway can encompass several different functions 206 including: modem, Ethernet switch, wireless access point, router, 207 network address translation (NAT), DHCP server, DNS relay and 208 firewall. Of the common functions provided, the NAT function of a 209 residential gateway has the greatest impact on LIS discovery. 211 An ISP is typically parsimonious about their IP address allocations; 212 each customer is allocated a limited number of IP addresses. 213 Therefore, NAT is an extremely common function of gateways. NAT 214 enables the use of multiple Devices within the residential network. 215 However NAT also means that Devices within the residence are not 216 configured by the ISP directly. 218 When it comes to discovering a LIS, the fact that Devices are not 219 configured by the ISP causes a significant problem. Configuration is 220 the ideal method of conveying the information necessary for 221 discovery. Devices attached to residential gateways are usually 222 given a generic configuration that includes no information about the 223 ISP network. For instance, DNS configuration typically points to a 224 DNS relay on the gateway device. This approach ensures that the 225 local network served by the gateway is able to operate without a 226 connection to the ISP, but it also means that Devices are effectively 227 ignorant of the ISP network. 229 [RFC5986] describes several methods that can be applied by a 230 residential gateway to assist Devices in acquiring location 231 information. For instance, the residential gateway could forward LIS 232 address information to hosts within the network it serves. 234 Unfortunately, such an active involvement in the discovery process 235 only works for new residential gateway devices that implement those 236 recommendations. 238 Where residential gateways already exist, direct involvement of the 239 gateway in LIS discovery requires that the residential gateway be 240 updated or replaced. The cost of replacement is difficult to justify 241 to the owner of the gateway, especially when it is considered that 242 the gateway still fills its primary function: Internet access. 243 Furthermore, updating the software in such devices is not feasible in 244 many cases. Even if software updates were made available, many 245 residential gateways cannot be updated remotely, inevitably leading 246 to some proportion that is not updated. 248 This document therefore describes a method that can be used by 249 Devices to discover their LIS without any assistance from the 250 network. 252 3.2. Residential Gateway Security Features 254 A network firewall function is often provided by residential gateways 255 as a security measure. Security features like intrusion detection 256 systems help protect users from attacks. Amongst these protections 257 is a port filter that prevents both inbound and outbound traffic on 258 certain TCP and UDP ports. Therefore, any solution needs to consider 259 the likelihood of traffic being blocked. 261 4. IP-based DNS Solution 263 LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery 264 Service (DDDS) system as the basis of discovery. Input to this 265 process is a domain name. Use of DHCP for acquiring the domain name 266 is specified, but alternative methods of acquisition are permitted. 268 This document specifies a means for a Device to discover several 269 alternative domain names that can be used as input to the DDDS 270 process. These domain names are based on the IP address of the 271 Device. Specifically, the domain names are a portion of the reverse 272 DNS trees - either the ".in-addr.arpa." or ".ip6.arpa." tree. 274 The goal of this process is to make a small number of DDDS queries in 275 order to find a LIS. After LIS discovery using the DHCP-based 276 process in [RFC5986] has failed, a Device can: 278 1. Collect a set of IP addresses that refer to the Device 279 (Section 4.1). 281 2. Convert each IP address into DNS names in the "in-addr.arpa." or 282 "ip6.arpa." tree (Section 4.2). 284 3. Perform the DDDS process for LIS discovery on those DNS names 285 ([RFC5986]). 287 4. Shorten the DNS names by some number of labels and repeat the 288 DDDS process (Section 4.3). 290 A Device might be reachable at one of a number of IP addresses. In 291 the process described, a Device first identifies each IP address that 292 it is potentially reachable from. From each of these addresses, the 293 Device then selects up to three domain names for use in discovery. 294 These domain names are then used as input to the DDDS process. 296 4.1. Identification of IP Addresses 298 A Device identifies a set of potential IP addresses that currently 299 result in packets being routed to it. These are ordered by 300 proximity, with those addresses that are used in adjacent network 301 segments being favoured over those used in public or remote networks. 302 The first addresses in the set are those that are assigned to local 303 network interfaces. 305 A Device can use the Session Traversal Utilities for NAT (STUN) 306 [RFC5389] mechanism to determine its public reflexive transport 307 address. The host uses the "Binding Request" message and the 308 resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the 309 response. 311 Alternative methods for determining other IP addresses MAY be used by 312 the Device. Port Control Protocol (PCP) [RFC6887], Universal Plug 313 and Play (UPnP) [UPnP-IGD-WANIPConnection1] and NAT Port Mapping 314 Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] are both able to provide 315 the external address of a residential gateway device when enabled. 316 These as well as proprietary methods for determining other addresses 317 might also be available. Because there is no assurance that these 318 methods will be supported by any access network, these methods are 319 not mandated. Note also that in some cases, methods that rely on the 320 view of the network from the residential gateway device could reveal 321 an address in a private address range (see Section 4.6). 323 In many instances, the IP address produced might be from a private 324 address range. For instance, the address on a local network 325 interface could be from a private range allocated by the residential 326 gateway. In other cases, methods that rely on the view of the 327 network (UPnP, NAT-PMP) from the residential gateway device could 328 reveal an address in a private address range if the access network 329 also uses NAT. For a private IP address, the derived domain name is 330 only usable where the DNS server used contains data for the 331 corresponding private IP address range. 333 4.2. Domain Name Selection 335 The domain name selected for each resulting IP address is the name 336 that would be used for a reverse DNS lookup. The domain name derived 337 from an IP version 4 address is in the ".in-addr.arpa." tree and 338 follows the construction rules in Section 3.5 of [RFC1035]. The 339 domain name derived from an IP version 6 address is in the 340 ".ip6.arpa." tree and follows the construction rules in Section 2.5 341 of [RFC3596]. 343 4.3. Shortened DNS Names 345 Additional domain names are added to allow for a single DNS record to 346 cover a larger set of addresses. If the search on the domain derived 347 from the full IP address does not produce a NAPTR record with the 348 desired service tag (e.g., "LIS:HELD"), a similar search is repeated 349 based on a shorter domain name, using a part of the IP address: 351 o For IP version 4, the resulting domain name SHOULD be shortened 352 successively by one and two labels and the query repeated. This 353 corresponds to a search on a /24 or /16 network prefix. This 354 allows for fewer DNS records in the case where a single access 355 network covering an entire /24 or /16 network is served by the 356 same LIS. 358 o For IP version 6, the resulting domain SHOULD be shortened 359 successively by 16, 18, 20 and 24 labels and the query repeated. 360 This corresponds to a search on a /64, /56, /48 or /32 network 361 prefix. 363 This set of labels is intended to provide network operators with a 364 degree of flexibility in where LIS discovery records can be placed 365 without significantly increasing the number of DNS names that are 366 searched. This does not attach any other significance to these 367 specific zone cuts, or create a classful addressing hierachy based on 368 the reverse DNS tree. 370 For example, the IPv4 address "192.0.2.75" could result in queries 371 to: 373 o 75.2.0.192.in-addr.arpa. 375 o 2.0.192.in-addr.arpa. 377 o 0.192.in-addr.arpa. 379 Similarly, the IPv6 address "2001:DB8::28e4:3a93:4429:dfb5" could 380 result in queries to: 382 o 5.b.f.d.9.2.4.4.3.9.a.3.4.e.8.2.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2 383 .ip6.arpa. 385 o 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 387 o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 389 o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 391 o 8.b.d.0.1.0.0.2.ip6.arpa. 393 The limited number of labels by which each name is shortened is 394 intended to limit the number of DNS queries performed by Devices. If 395 no LIS is discovered by this method, the result will be that no more 396 than five U-NAPTR resolutions are invoked for each IP address. 398 4.4. When To Use The Reverse DNS Method 400 The DHCP method described in [RFC5986] MUST be attempted on all local 401 network interfaces before attempting this method. This method is 402 employed either because DHCP is unavailable, when the DHCP server 403 does not provide a value for the access network domain name option, 404 or if a request to the resulting LIS results in a HELD "notLocatable" 405 error or equivalent. 407 4.5. Private Address Spaces 409 Addresses from a private use address space can be used as input to 410 this method. In many cases, this applies to addresses defined in 411 [RFC1918], though other address ranges could have limited 412 reachability where this advice also applies. This is only possible 413 if a DNS server with a view of the same address space is used. 414 Public DNS servers cannot provide useful records for private 415 addresses. 417 Using an address from a private space in discovery can provide a more 418 specific answer if the DNS server has records for that space. 419 Figure 2 shows a network configuration where addresses from an ISP 420 network could better indicate the correct LIS. Records in DNS B can 421 be provided for the 10.0.0.0/8 range, potentially dividing that range 422 so that a more local LIS can be selected. 424 _____ ________ 425 ( DNS ).....(/ \) Public 426 (__A__) (( Internet )) Address 427 (\________/) Space 428 | 429 [NAT] 430 _____ _____|_____ 431 ( DNS )....(/ \) Private 432 (__B__) (( ISP Network )) Address Space 433 (\___________/) (e.g. 10.0.0.0/8) 434 | 435 [Gateway] 436 ____|____ 437 (/ \) Private 438 (( Residence )) Address Space 439 (\_________/) (e.g. 192.168.0.0/16) 441 Figure 2: Address Space Example 443 The goal of automatic DNS configuration is usually to select a local 444 DNS, which suits configurations like the one shown. However, use of 445 public DNS or STUN servers means that a public IP address is likely 446 to be found. For STUN in particular, selecting a public server 447 minimizes the need for reconfiguration when a Device moves. Adding 448 records for the public address space used by an access network 449 ensures that the discovery process succeeds when a public address is 450 used. 452 4.6. Necessary Assumptions and Restrictions 454 When used by a Device for LIS discovery this is an UNSAF application 455 and is subject to the limitations described in Section 8. 457 It is not necessary that the IP address used is unique to the Device, 458 only that the address can be somehow related to the Device or the 459 access network that serves the Device. This allows a degree of 460 flexibility in determining this value, although security 461 considerations (Section 7) might require that the address be verified 462 to limit the chance of falsification. 464 This solution assumes that the public reflexive transport address 465 used by a Device is in some way controlled by the access network 466 provider, or some other related party. This implies that the 467 corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated 468 by that entity to include a useful value for the LIS address. 470 4.7. Failure Modes 471 Successful use of private addresses relies on a DNS server that has 472 records for the address space that is used. Using a public IP 473 address increases the likelihood of this. This document relies on 474 STUN to provide the Device with a public reflexive transport address. 475 Configuration of a STUN server is necessary to ensure that this is 476 successful. 478 In cases where a virtual private network (VPN) or other tunnel is 479 used, the entity providing a public IP address might not be able to 480 provide the Device with location information. It is assumed that 481 this entity is able to identify this problem and indicate this to the 482 Device (using the "notLocatable" HELD error, or similar). This 483 problem is described in more detail in [RFC5985]. 485 4.8. Deployment Considerations 487 An access network provider SHOULD provide NAPTR records for each 488 public IP address that is used for Devices within the access network. 490 Any DNS server internal to a NAT SHOULD also include records for the 491 private address range. These records might only be provided to 492 clients making requests from the private address range. Doing so 493 allows clients within the private address range to discover a LIS 494 based on their IP address prior to any address translation. In 495 geographically distributed networks that use a private address range, 496 this enables the use of a different LIS for different locations, 497 based on the IP address range used at each location. Use of a 498 public, translated IP address for the network can still work, but it 499 might result in a suboptimal LIS selection. 501 A network that operates network address translation SHOULD provide 502 NAPTR records that reference a LIS endpoint with a public address. 503 This requires the reservation of an IP and port for the LIS. To 504 ensure requests toward the LIS from within the private address space 505 do not traverse the NAT and have source addresses mapped by the NAT, 506 networks can provide direct route to the LIS. Clients that perform 507 discovery based on public DNS or STUN servers are thereby easier to 508 trace based on source address information. 510 NAPTR records can be provided for individual IP addresses. To limit 511 the proliferation of identical records, a single record can be placed 512 at higher nodes of the tree (corresponding to /24 and /16 for IPv4; / 513 64, /56, /48 and /32 for IPv6). A record at a higher point in the 514 tree (those with a shorter prefix) applies to all addresses lower in 515 the tree (those with a longer prefix); records at the lower point 516 override those at higher points, thus allowing for exceptions to be 517 specified. 519 5. IANA Considerations 521 This document has no IANA actions. 523 6. Privacy Considerations 525 As with all uses of geolocation information, it is very important 526 that measures be taken to ensure that location information is not 527 provided to unauthorized parties. The mechanism defined in this 528 document is focused on the case where a device is learning its own 529 location, so that it can provide that location information to 530 applications. We assume that the device learning its own location is 531 not a privacy risk. There are then two remaining privacy risks: The 532 use of geolocation by applications, and abuse of the location 533 configuration protocol. 535 The privacy considerations around the use of geolocation by 536 applications vary considerably by application context. A framework 537 for location privacy in applications is provided in [RFC6280]. 539 The mechanism specified in this document allows a device to discover 540 its local LIS, from which it then acquires its location using a 541 Location Configuration Protocol [RFC5687]. If an unauthorized third 542 party can spoof the LCP to obtain a target's location information, 543 then the mechanism in this document could allow them to discover the 544 proper server to attack for a given IP address. Thus, it is 545 important that a LIS meet the security requirements of the LCP it 546 implements. For HELD, these requirements are laid out in Section 9 547 of [RFC5985]. 549 A Device that discovers a LIS using the methods in this document MUST 550 NOT provide that LIS with additional information that might reveal 551 its position, such as the location measurements described in 552 [I-D.ietf-geopriv-held-measurements], unless it has a secondary 553 method for determining the authenticity of the LIS, such as a white 554 list. 556 7. Security Considerations 558 The security considerations described in [RFC5986] apply to the 559 discovery process as a whole. The primary security concern is with 560 the potential for an attacker to impersonate a LIS. 562 The added ability for a third party to discover the identity of a LIS 563 does not add any concerns, since the identity of a LIS is considered 564 public information. 566 In addition to existing considerations, this document introduces 567 further security considerations relating to the identification of the 568 IP address. It is possible that an attacker could attempt to provide 569 a falsified IP address in an attempt to subvert the rest of the 570 process. 572 [RFC5389] describes attacks where an attacker is able to ensure that 573 a Device receives a falsified reflexive address. An on-path attacker 574 might be able to ensure that a falsified address is provided to the 575 Device. Even though STUN messages are protected by a STUN MESSAGE- 576 INTEGRITY attribute, which is an HMAC that uses a shared secret, an 577 on-path attacker can capture and modify packets, altering source and 578 destination addresses to provide falsified addresses. 580 This attack could result in an effective means of denial of service, 581 or a means to provide a deliberately misleading service. Notably, 582 any LIS that is identified based on a falsified IP address could 583 still be a valid LIS for the given IP address, just not one that is 584 useful for providing the Device with location information. In this 585 case, the LIS provides a HELD "notLocatable" error, or an equivalent. 586 If the falsified IP address is under the control of the attacker, it 587 is possible that misleading (but verifiable) DNS records could 588 indicate a malicious LIS that provides false location information. 590 In all cases of falsification, the best remedy is to perform some 591 form of independent verification of the result. No specific 592 mechanism is currently available to prevent attacks based on 593 falsification of reflexive addresses; it is suggested that Devices 594 attempt to independently verify that the reflexive transport address 595 provided is accurate. An independent, trusted source of location 596 information could aid in verification, even if the trusted source is 597 unable to provide information with the same degree of accuracy as the 598 discovered LIS. 600 Use of private address space effectively prevents use of the usual 601 set of trust anchors for DNSSEC. Only a DNS server that is able to 602 see the same private address space can provide useful records. A 603 Device that relies on DNS records in the private address space 604 portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use 605 an alternative trust anchor for these records or rely on other means 606 of ensuring the veracity of the DNS records. 608 8. IAB Considerations 609 The IAB has studied the problem of Unilateral Self-Address Fixing 610 (UNSAF) [RFC3424], which is the general process by which a client 611 attempts to determine its address in another realm on the other side 612 of a NAT through a collaborative protocol reflection mechanism, such 613 as STUN. 615 This section only applies to the use of this method of LIS discovery 616 by Devices and does not apply to its use for third-party LIS 617 discovery. 619 The IAB requires that protocol specifications that define UNSAF 620 mechanisms document a set of considerations. 622 1. Precise definition of a specific, limited-scope problem that is 623 to be solved with the UNSAF proposal. 625 Section 3 describes the limited scope of the problem addressed in 626 this document. 628 2. Description of an exit strategy/transition plan. 630 [RFC5986] describes behaviour that residential gateways require 631 in order for this short term solution to be rendered unnecessary. 632 When implementations of the recommendations in LIS discovery are 633 widely available, this UNSAF mechanism can be made obsolete. 635 3. Discussion of specific issues that may render systems more 636 "brittle". 638 A description of the necessary assumptions and limitations of 639 this solution are included in Section 4.6. 641 Use of STUN for discovery of a reflexive transport address is 642 inherently brittle in the presence of multiple NATs or address 643 realms. In particular, brittleness is added by the requirement 644 of using a DNS server that is able to view the address realm that 645 contains the IP address in question. If address realms use 646 overlapping addressing space, then there is a risk that the DNS 647 server provides information that is not useful to the Device. 649 4. Identify requirements for longer term, sound technical solutions; 650 contribute to the process of finding the right longer term 651 solution. 653 A longer term solution is already provided in [RFC5986]. 654 However, that solution relies on widespread deployment. The 655 UNSAF solution provided here is provided as an interim solution 656 that enables LIS access for Devices that are not able to benefit 657 from deployment of the recommendations in [RFC5986]. 659 5. Discussion of the impact of the noted practical issues with 660 existing deployed NATs and experience reports. 662 The UNSAF mechanism depends on the experience in deployment of 663 STUN [RFC5389]. On the whole, existing residential gateway 664 devices are able to provide access to STUN and DNS service 665 reliably, although regard should be given to the size of the DNS 666 response (see [RFC5625]). 668 9. Acknowledgements 670 Richard Barnes provided the text in Section 6. 672 10. References 674 10.1. Normative References 676 [RFC1035] Mockapetris, P., "Domain names - implementation and 677 specification", STD 13, RFC 1035, November 1987. 679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, March 1997. 682 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 683 "DNS Extensions to Support IP Version 6", RFC 3596, 684 October 2003. 686 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 687 Location Information Server (LIS)", RFC 5986, September 688 2010. 690 [I-D.ietf-geopriv-held-measurements] 691 Thomson, M. and J. Winterbottom, "Using Device-provided 692 Location-Related Measurements in Location Configuration 693 Protocols", draft-ietf-geopriv-held-measurements-09 (work 694 in progress), September 2013. 696 10.2. Informative References 698 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 699 E. Lear, "Address Allocation for Private Internets", BCP 700 5, RFC 1918, February 1996. 702 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 703 2131, March 1997. 705 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 706 and M. Carney, "Dynamic Host Configuration Protocol for 707 IPv6 (DHCPv6)", RFC 3315, July 2003. 709 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 710 Self-Address Fixing (UNSAF) Across Network Address 711 Translation", RFC 3424, November 2002. 713 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 714 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 716 [RFC4848] Daigle, L., "Domain-Based Application Service Location 717 Using URIs and the Dynamic Delegation Discovery Service 718 (DDDS)", RFC 4848, April 2007. 720 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 721 Emergency Context Resolution with Internet Technologies", 722 RFC 5012, January 2008. 724 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 725 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 726 October 2008. 728 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 729 Location Configuration Protocol: Problem Statement and 730 Requirements", RFC 5687, March 2010. 732 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 733 Tschofenig, H., and H. Schulzrinne, "An Architecture for 734 Location and Location Privacy in Internet Applications", 735 BCP 160, RFC 6280, July 2011. 737 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 738 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 739 2013. 741 [UPnP-IGD-WANIPConnection1] 742 UPnP Forum, "Internet Gateway Device (IGD) Standardized 743 Device Control Protocol V 1.0: WANIPConnection:1 Service 744 Template Version 1.01 For UPnP Version 1.0", DCP 05-001, 745 Nov 2001. 747 [I-D.cheshire-nat-pmp] 748 Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol 749 (NAT-PMP)", draft-cheshire-nat-pmp-07 (work in progress), 750 January 2013. 752 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 753 152, RFC 5625, August 2009. 755 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 756 5985, September 2010. 758 Authors' Addresses 760 Martin Thomson 761 Mozilla 762 Suite 300 763 650 Castro Street 764 Mountain View, CA 94041 765 US 767 Email: martin.thomson@gmail.com 769 Ray Bellis 770 Nominet UK 771 Edmund Halley Road 772 Oxford OX4 4DQ 773 United Kingdom 775 Phone: +44 1865 332211 776 Email: ray.bellis@nominet.org.uk 777 URI: http://www.nominet.org.uk/