idnits 2.17.1 draft-ietf-geopriv-lis-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 888. 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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 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. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 13, 2008) is 5790 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-15 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-07 == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-07 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft J. Winterbottom 4 Intended status: Standards Track Andrew 5 Expires: December 15, 2008 June 13, 2008 7 Discovering the Local Location Information Server (LIS) 8 draft-ietf-geopriv-lis-discovery-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 15, 2008. 35 Abstract 37 A method is described for the discovery of a Location Information 38 Server. The method consists of attempting to use a Dynamic Host 39 Configuration Protocol (DHCP) option, followed by a URI-enabled NAPTR 40 (U-NAPTR). DHCP options are defined for both IPv4 and IPv6 DHCP. 41 This document also defines a U-NAPTR Application Service for a LIS, 42 with a specific Application Protocol for the HTTP Enabled Location 43 Delivery (HELD) protocol. 45 Table of Contents 47 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 48 1.1. DHCP Discovery . . . . . . . . . . . . . . . . . . . . . . 3 49 1.2. U-NAPTR Discovery . . . . . . . . . . . . . . . . . . . . 3 50 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. LIS Discovery Using DHCP . . . . . . . . . . . . . . . . . . . 5 52 2.1. DHCPv4 Option for a LIS Address . . . . . . . . . . . . . 5 53 2.2. DHCPv6 Option for a LIS Address . . . . . . . . . . . . . 5 54 3. U-NAPTR for LIS Discovery . . . . . . . . . . . . . . . . . . 7 55 4. Determining the Access Network Domain Name . . . . . . . . . . 8 56 4.1. DHCP Domain Name Option . . . . . . . . . . . . . . . . . 8 57 4.2. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.2.1. Determining an External IP Address . . . . . . . . . . 9 59 5. Discovery Order . . . . . . . . . . . . . . . . . . . . . . . 11 60 5.1. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 12 61 6. Access Network Guidance . . . . . . . . . . . . . . . . . . . 13 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 64 8.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 15 65 8.2. Registration of a Location Server Application Service 66 Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 8.3. Registration of a Location Server Application Protocol 68 Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 15 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 73 Appendix A. Residential Broadband LIS Discovery Example . . . . . 20 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 75 Intellectual Property and Copyright Statements . . . . . . . . . . 24 77 1. Introduction and Overview 79 Discovering a Location Information Server (LIS) is an important part 80 of the location acquisition process. The LIS is an access network 81 service that needs to be discovered before it can be used. This 82 document describes a method that a host can use to discover a URI for 83 a LIS. 85 The product of a discovery process, such as the one described in this 86 document, is the address of the service. In this document, the 87 result is a URI, which identifies a LIS. A URI permits 88 identification of a LIS that includes information about protocols and 89 other supplementary information. 91 The discovery process requires that the host first attempt LIS 92 discovery using Dynamic Host Configuration protocol (DHCP). If DHCP 93 is not available, or the option is not supported by the network, the 94 host attempts to discover the LIS using the DNS and URI-enabled 95 Naming Authority Pointer (U-NAPTR). Finally, the host can rely on 96 proprietary methods for determining the address of the LIS, including 97 static configuration. 99 The URI result from the discovery process is suitable for location 100 configuration only; that is, the client MUST dereference the URI 101 using the process described in HELD 102 [I-D.ietf-geopriv-http-location-delivery]. URIs discovered in this 103 way are not "location by reference" URIs; dereferencing one of them 104 provides the location of the requester only. Clients MUST NOT embed 105 these URIs in fields in other protocols designed to carry the 106 location of the client. 108 1.1. DHCP Discovery 110 DHCP ([RFC2131], [RFC3315]) is a commonly used mechanism for 111 providing bootstrap configuration information allowing a host to 112 operate in a specific network environment. The bulk of DHCP 113 information is largely static; consisting of configuration 114 information that does not change over the period that the host is 115 attached to the network. Physical location information might change 116 over this time, however the address of the LIS does not. Thus, DHCP 117 is suitable for configuring a host with the address of a LIS. 119 1.2. U-NAPTR Discovery 121 Where DHCP is not available, the DNS might be able to provide a URI. 122 For DNS methods, alternative discovery techniques SRV records 123 [RFC2782] or Straightforward NAPTR (S-NAPTR) [RFC3958] provide an 124 indication of a service for a domain, but these methods cannot be 125 used; SRV and S-NAPTR only permit the return of a hostname and port, 126 not a URI. URI-enabled NAPTR (U-NAPTR) [RFC4848], which is based on 127 S-NAPTR, describes a method of applying the Dynamic Delegation 128 Discovery Service (DDDS) for URI results. 130 For the LIS discovery DDDS application, an Application Service tag 131 "LIS" and an Application Protocol tag "HELD" are created and 132 registered with the IANA. Taking a domain name, this U-NAPTR 133 application uses the two tags to determine the LIS URI. 135 Determining the domain name to be used is a critical part of the 136 resolution process. The second part of this document describes how a 137 domain name can be derived. Several methods are described that 138 address different scenarios. 140 1.3. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 This document also uses the term "host" to refer to an end host. In 147 RFC3693 [RFC3693] parlance, the host is the Device, which might also 148 be the Target. 150 The terms "access network" refers to the network that a host connects 151 to for Internet access. The "access network provider" is the entity 152 that operates the access network. This is consistent with the 153 definition in [I-D.ietf-geopriv-l7-lcp-ps] which combines the 154 Internet Access Provider (IAP) and Internet Service Provider (ISP). 155 The access network provider is responsible for allocating the host an 156 IP address and for directly or indirectly providing a LIS service. 158 2. LIS Discovery Using DHCP 160 DHCP allows the access network provider to specify the address of a 161 LIS as part of network configuration. This document registers DHCP 162 options for a LIS address for both IPv4 and IPv6. 164 2.1. DHCPv4 Option for a LIS Address 166 This section defines a DHCP for IPv4 (DHCPv4) option for the address 167 of a LIS. 169 0 1 2 3 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | LIS_URI | Length | URI ... . 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | URI ... 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1: DHCPv4 LIS URI Option 179 LIS_URI: The IANA assigned option number (TBD). 181 Length: The length of the URI in octets. 183 URI: The address of the LIS. This URI SHOULD NOT be more than 253 184 bytes in length, but MAY be extended by concatenating multiple 185 option values, as described in [RFC3396]. The URI MUST NOT be 186 NULL terminated. 188 2.2. DHCPv6 Option for a LIS Address 190 This section defines a DHCP for IPv6 (DHCPv6) option for the address 191 of a LIS. The DHCPv6 option for this parameter is similarly 192 formatted to the DHCPv4 option. 194 0 1 2 3 195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | OPTION_LIS_URI | Length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | URI ... 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 2: DHCPv6 LIS URI Option 204 OPTION_LIS_URI: The IANA assigned option number (TBD). 206 Length: The length of the URI in octets. 208 URI: The address of the LIS. The URI MUST NOT be NULL terminated. 210 3. U-NAPTR for LIS Discovery 212 U-NAPTR resolution for a LIS takes a domain name as input and 213 produces a URI that identifies the LIS. This process also requires 214 an Application Service tag and an Application Protocol tag, which 215 differentiate LIS-related NAPTR records from other records for that 216 domain. 218 Section 8.2 defines an Application Service tag of "LIS", which is 219 used to identify the location service for a particular domain. The 220 Application Protocol tag "HELD", defined in Section 8.3, is used to 221 identify a LIS that understands the HELD protocol 222 [I-D.ietf-geopriv-http-location-delivery]. 224 The NAPTR records in the following example demonstrate the use of the 225 Application Service and Protocol tags. Iterative NAPTR resolution is 226 used to delegate responsibility for the LIS service from 227 "zonea.example.com." and "zoneb.example.com." to 228 "outsource.example.com.". 230 zonea.example.com. 231 ;; order pref flags 232 IN NAPTR 100 10 "" "LIS:HELD" ( ; service 233 "" ; regex 234 outsource.example.com. ; replacement 235 ) 236 zoneb.example.com. 237 ;; order pref flags 238 IN NAPTR 100 10 "" "LIS:HELD" ( ; service 239 "" ; regex 240 outsource.example.com. ; replacement 241 ) 242 outsource.example.com. 243 ;; order pref flags 244 IN NAPTR 100 10 "u" "LIS:HELD" ( ; service 245 "!*.!https://lis.outsource.example.com/!" ; regex 246 . ; replacement 247 ) 249 Figure 3: Sample LIS:HELD Service NAPTR Records 251 Details for the "LIS" Application Service tag and the "HELD" 252 Application Protocol tag are included in Section 8. 254 4. Determining the Access Network Domain Name 256 The U-NAPTR discovery method described in Section 3 requires that the 257 domain name applicable to the access network is known. An 258 unconfigured host might not have this information, therefore it must 259 determine this value before the U-NAPTR method can be attempted. 261 This section describes several methods for discovering a domain name 262 for the local access network. Each method is attempted where 263 applicable until a domain name is derived. If a domain name is 264 successfully derived but that domain name does not produce any 265 U-NAPTR records, alternative methods can be attempted to determine 266 additional domain names. Reattempting with different methods is 267 particularly applicable when NAT is used, as is shown in 268 Section 4.2.1. 270 4.1. DHCP Domain Name Option 272 For IP version 4, Dynamic Host Configuration Protocol (DHCP) option 273 15 [RFC2131] includes the domain name suffix for the host. If DHCP 274 and option 15 are available, this value should be used as input the 275 U-NAPTR procedure. 277 Alternatively, a fully qualified domain name (FQDN) for the host 278 might be provided by the server ([RFC4702] for DHCPv4, [RFC4704] for 279 DHCPv6). This domain name is used as input to the U-NAPTR resolution 280 and is obtained from the FQDN by removing the first label. If the 281 host has provided a fully qualified domain name using this option, it 282 SHOULD NOT be used - the domain known to the host might not be the 283 same as that of the access network. 285 Either DHCP method SHOULD be attempted first if DHCP is available. 286 Note that this method is only attempted if the LIS address option is 287 not available. 289 4.2. Reverse DNS 291 DNS "PTR" records in the "in-addr.arpa." domain can be used to 292 determine the domain name of a host, and therefore, the name of the 293 domain for that host. The use of the "in-addr.arpa." domain is 294 described in [RFC1034] and results in the domain name of the host. 295 Likewise, IPv6 hosts use the "ip6.arpa." domain. In the majority of 296 cases, the domain part of this name (everything excluding the first 297 label) is also the domain name for the access network. Assuming that 298 this is true, this domain name can be used as input to the U-NAPTR 299 process. 301 For example, if the for "10.1.2.3" address, if the "PTR" record at 302 "3.2.1.10.in-addr.arpa." refers to "host.example.com", this results 303 in a U-NAPTR search for "example.com". 305 The DNS hierarchy does not necessarily directly map onto a network 306 topology (see [RFC4367]); therefore, this method MUST only be used 307 for the domain name determined by removing the first label only. 308 This method assumes that the access network provider also provides 309 the reverse DNS record and they control the domain that is indicated 310 in the "PTR" record. 312 Furthermore, this method might not apply where a host is given a 313 domain name that is different from the domain name of the access 314 network. This might occur in some hosting configurations, such as 315 where a number of web server hosts, with widely varying domain names, 316 are co-located. From the above example, the access network provider 317 allocated "10.1.2.3" to the host; therefore, they also need to 318 control the DNS domain "example.com" and the associated NAPTR 319 records. DNS Security Extensions (DNSSEC) [RFC4033] provides a 320 cryptographic means of validating this association, through data 321 origin authentication. 323 4.2.1. Determining an External IP Address 325 Reverse DNS relies on knowing the IP address of a host within the 326 access domain. Initially, this SHOULD be attempted using the IP 327 address that is assigned to a local interface on the host. However, 328 when a NAT device is used, the IP address of the NAT device is 329 substituted for the source IP address. If a NAT device exists 330 between the host and the access network, the host does not have any 331 direct way to determine the IP address that it is effectively using 332 within the access network. The IP address of the NAT device and the 333 corresponding domain name can be used to discover the LIS. 335 In order to use reverse DNS in this configuration, the hosts need to 336 know the IP address that the NAT device uses. The following sections 337 describe some possible methods. 339 These methods are particularly useful in residential broadband 340 configurations. A large proportion of residential broadband services 341 employ a NAT device so that several hosts can share the same Internet 342 access. Since the network behind the NAT device are generally very 343 small, both in numbers and geographical area, it isn't necessary for 344 a LIS to operate within that network; the hosts are able to access a 345 LIS in the access network outside of the NAT device. 347 4.2.1.1. UPnP 349 If a NAT device complies with the Universal Plug and Play (UPnP) 350 specification [UPnP-IGD-WANIPConnection1], the WANIPConnection part 351 can be used to query the device for its public IP address. The 352 "GetExternalIPAddress" function provides the external address for a 353 particular network connection. 355 UPnP defines a method for discovering UPnP-enabled hosts in a 356 network; the host does not need any prior configuration to employ 357 this method. 359 4.2.1.2. STUN 361 A host can use the Session Traversal Utilities for NAT (STUN) 362 [I-D.ietf-behave-rfc3489bis] to determine a public IP address. The 363 host uses the "Binding Request" message and the resulting 364 "XOR-MAPPED-ADDRESS" parameter that is returned in the response. 366 Using STUN requires cooperation from a publicly accessible STUN 367 server. The host also requires configuration information that 368 identifies the STUN server, or a domain name that can be used for 369 STUN server discovery. 371 4.2.1.3. Other Options 373 The source IP address in any IP packet can be used to determine the 374 public IP address of a host. While the STUN method uses a small part 375 of a more sophisticated protocol, this principle can be applied using 376 any other protocol. Like STUN, this method requires prior knowledge 377 of the publicly accessible server and the method that it supports. 379 For instance, a publicly accessible host could be configured to 380 respond to a UDP packet on a predefined port; the data of the 381 response could contain the source IP address that was in the request. 382 Alternatively, a HTTP server at a particular URL could be configured 383 to respond to a GET request with a "text/plain" body containing the 384 IP address of the requester. HTTP proxies render this method 385 unusable; in particular, transparent HTTP proxies might affect the 386 results of this method without the knowledge of the host. Such 387 services already exist on the public Internet. 389 5. Discovery Order 391 The previous sections described a set of procedures that allow a 392 device to determine the LIS associated with the local access network. 393 Some networks maintain a topology analogous to an onion and are 394 comprised of layers, or segments, separating hosts from the Internet 395 through intermediate networks. It is best therefore for a host to 396 discover the LIS logically closest to it, and this can best be done 397 by applying the discovery techniques in the following order: 399 1. DHCP LIS URI Option 401 2. DNS U-NAPTR Discovery, using the domain name from: 403 A. DHCP Domain Name Option 405 B. Reverse DNS, using the hosts IP address from: 407 1. the local network interface and immediate network segment 409 2. the network segment adjacent to the immediate segment, as 410 revealed by UPnP 412 3. the public Internet, as revealed by STUN; or the network 413 segment where the STUN server resides 415 (4.) any network segment, as revealed by other method 417 3. Static configuration 419 DHCP discovery MUST be attempted before DNS discovery. This allows 420 the network access provider a direct and explicit means of 421 configuring a LIS address. DNS discovery is used as a failsafe, 422 providing a means to discover a LIS where the DHCP infrastructure 423 does not support the LIS URI option. 425 Static host configuration MAY be used to provide a LIS address if 426 both DHCP and DNS methods fail. Note however, that if a host has 427 moved from its customary location, static configuration might 428 indicate a LIS that is unable to provide a location. User 429 interaction is NOT RECOMMENDED; the discovery process is not easily 430 diagnosed by a user. 432 LIS discovery through DNS requires the host to determine the domain 433 name of the local access network. Where DHCP is available, the DHCP 434 domain name option (Section 4.1) can be used to provide this 435 information. If the domain name cannot be determined from DHCP, or 436 the resulting domain name fails to yield a valid LIS address then 437 reverse DNS is used. 439 The discovery procedure assumes that the correct LIS is in a network 440 segment that is closer to the host. Each network segment between the 441 host and LIS decreases the chance that the LIS is able to correctly 442 determine a location for the host. 444 Discovery methods follow an order of precedence. The exception is 445 for alternative methods of determining the hosts IP address in each 446 network segment; precedence is given to addresses in the network 447 segments closer to the host. Therefore, the host MUST attempt to use 448 the IP address assigned to its local network interface before 449 attempting to determine its IP address. Precedence is given to 450 methods, like UPnP that provide an IP address in adjacent network 451 segments. Methods for determining addresses on the public Internet 452 are given lower precedence. 454 To claim compliance with this document, a host MUST support both DHCP 455 discovery and U-NAPTR discovery. Further, the host MUST support 456 retrieval of domain name from DHCP and reverse DNS, using a local 457 interface address, UPnP and STUN. Additional methods for determining 458 the IP address of the host in different network segments are 459 optional. 461 5.1. Virtual Private Networks (VPNs) 463 Where a host has multiple network interfaces the host MAY 464 independently discover the LIS corresponding to the access networks 465 reached by each network interface. Resolving which LIS to contact 466 for location information is a host application issue. 468 LIS discovery over a VPN network interface SHOULD NOT be performed 469 since such a LIS does not have the physical presence generally 470 necessary to determine location. However, since not all VPN 471 interfaces can be detected by hosts, a LIS SHOULD NOT provide 472 location information in response to requests originating from a VPN 473 pool. This ensures that even if a host discovers a LIS over the VPN, 474 it does not rely on a LIS that is unable to provide accurate location 475 information. The exception to this is where the LIS and host are 476 able to determine a location without access network support. 478 6. Access Network Guidance 480 In order to successfully discover a LIS, a host relies on information 481 provided by the access network. DHCP and DNS servers need to be able 482 to provide the data that the device depends on. This section 483 provides guidance on what information needs to be made available to a 484 host for it to successfully discover a LIS. 486 Access networks that provide both a LIS and a DHCP server must 487 provide the DHCP option for the LIS address. Since DHCP must be 488 attempted first, if it can be guaranteed that DHCP can be used by all 489 hosts in the network, no further configuration is necessary. 491 Unless DHCP can be relied upon for all hosts in the network (see 492 [I-D.ietf-geopriv-l7-lcp-ps] for common scenarios), DNS discovery 493 methods must also be supported. To support the DNS discovery 494 methods, the access network must provide two sets of DNS records: the 495 (U-)NAPTR records that enable the discovery of a LIS URI from a 496 domain name; and the reverse DNS records that enable the discovery of 497 a domain name based on the IP address of the host. 499 Access networks that provide a LIS should also provide reverse DNS 500 records for all IP addresses they administer. For each domain that 501 is referenced in reverse DNS records, a NAPTR record in that domain 502 must be provided for the "LIS:HELD" service that can be used to 503 resolve the address of a LIS. 505 Note: The DHCP domain name option is notably absent from this 506 guidance. The domain name option provides a quicker and more 507 reliable means to discover the domain name in the case where a 508 DHCP server does not support the LIS URI option. 510 7. Security Considerations 512 The primary attack against the methods described in this document is 513 one that would lead to impersonation of a LIS. The LIS is 514 responsible for providing location information and this information 515 is critical to a number of network services; furthermore, a host does 516 not necessarily have a prior relationship with a LIS. Several 517 methods are described here that can limit the probablity of, or 518 provide some protection against, such an attack. 520 The address of a LIS is usually well-known within an access network; 521 therefore, interception of messages does not introduce any specific 522 concerns. 524 If DHCP is used, the integrity of DHCP options is limited by the 525 security of the channel over which they are provided. Physical 526 security and separation of DHCP messages from other packets are 527 commonplace methods that can reduce the possibility of attack within 528 an access network; alternatively, DHCP authentication [RFC3118] can 529 provide a degree of protection against modification. 531 An attacker could attempt to compromise the U-NAPTR resolution. A 532 description of the security considerations for U-NAPTR applications 533 is included in [RFC4848]. 535 In addition to considerations related to U-NAPTR, it is important to 536 recognize that the output of this is entirely dependent on its input. 537 An attacker who can control the domain name can also control the 538 final URI. Because a number of methods are provided for determining 539 the domain name, a host implementation needs to consider attacks 540 against each of the methods that are used. 542 Reverse DNS is subject to the maintenance of the "in-addr.arpa." or 543 "ip6.arpa." domain and the integrity of the results that it provides. 544 DNSSEC [RFC4033] provides some measures that can improve the 545 reliability of DNS results. In particular, DNSSEC SHOULD be applied 546 to ensure that the reverse DNS record and the resulting domain are 547 provided by the same entity before this method is used. Without this 548 assurance, the host cannot be certain that the access network 549 provider has provided the NAPTR record for the domain name that is 550 provided. 552 Hosts behind NAT devices are also subject to attacks when retrieving 553 their public IP address. [I-D.ietf-behave-rfc3489bis] describes some 554 means of mitigating this attack for STUN. 556 8. IANA Considerations 558 8.1. Registration of DHCPv4 and DHCPv6 Option Codes 560 The IANA is requested to assign an option code for the DHCPv4 option 561 for a LIS address, as described in Section 2.1 of this document. 563 The IANA is requested to assign an option code for the DHCPv6 option 564 for a LIS address, as described in Section 2.2 of this document. 566 8.2. Registration of a Location Server Application Service Tag 568 This section registers a new S-NAPTR/U-NAPTR Application Service tag 569 for a LIS, as mandated by [RFC3958]. 571 Application Service Tag: LIS 573 Intended usage: Identifies a service that provides a host with its 574 location information. 576 Defining publication: RFCXXXX 578 Related publications: HELD [I-D.ietf-geopriv-http-location-delivery] 580 Contact information: The authors of this document 582 Author/Change controller: The IESG 584 8.3. Registration of a Location Server Application Protocol Tag for 585 HELD 587 This section registers a new S-NAPTR/U-NAPTR Application Protocol tag 588 for the HELD [I-D.ietf-geopriv-http-location-delivery] protocol, as 589 mandated by [RFC3958]. 591 Application Service Tag: HELD 593 Intended Usage: Identifies the HELD protocol. 595 Applicable Service Tag(s): LIS 597 Terminal NAPTR Record Type(s): U 599 Defining Publication: RFCXXXX 600 Related Publications: HELD [I-D.ietf-geopriv-http-location-delivery] 602 Contact Information: The authors of this document 604 Author/Change Controller: The IESG 606 9. Acknowledgements 608 The authors would like to thank Leslie Daigle for her work on 609 U-NAPTR; Peter Koch for his feedback on the DNS aspects of this 610 document; Andy Newton for constructive suggestions with regards to 611 document direction; Hannes Tschofenig and Richard Barnes for input 612 and reviews. 614 10. References 616 10.1. Normative References 618 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 619 STD 13, RFC 1034, November 1987. 621 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 622 RFC 2131, March 1997. 624 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 625 and M. Carney, "Dynamic Host Configuration Protocol for 626 IPv6 (DHCPv6)", RFC 3315, July 2003. 628 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 629 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 630 November 2002. 632 [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 633 Configuration Protocol (DHCP) Client Fully Qualified 634 Domain Name (FQDN) Option", RFC 4702, October 2006. 636 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 637 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 638 Option", RFC 4704, October 2006. 640 [RFC4848] Daigle, L., "Domain-Based Application Service Location 641 Using URIs and the Dynamic Delegation Discovery Service 642 (DDDS)", RFC 4848, April 2007. 644 [I-D.ietf-behave-rfc3489bis] 645 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 646 "Session Traversal Utilities for (NAT) (STUN)", 647 draft-ietf-behave-rfc3489bis-15 (work in progress), 648 February 2008. 650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, March 1997. 653 10.2. Informative References 655 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 656 specifying the location of services (DNS SRV)", RFC 2782, 657 February 2000. 659 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 660 Messages", RFC 3118, June 2001. 662 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 663 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 665 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 666 Service Location Using SRV RRs and the Dynamic Delegation 667 Discovery Service (DDDS)", RFC 3958, January 2005. 669 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 670 Rose, "DNS Security Introduction and Requirements", 671 RFC 4033, March 2005. 673 [RFC4367] Rosenberg, J. and IAB, "What's in a Name: False 674 Assumptions about DNS Names", RFC 4367, February 2006. 676 [I-D.ietf-geopriv-l7-lcp-ps] 677 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 678 Location Configuration Protocol; Problem Statement and 679 Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in 680 progress), March 2008. 682 [I-D.ietf-geopriv-http-location-delivery] 683 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 684 "HTTP Enabled Location Delivery (HELD)", 685 draft-ietf-geopriv-http-location-delivery-07 (work in 686 progress), April 2008. 688 [UPnP-IGD-WANIPConnection1] 689 UPnP Forum, "Internet Gateway Device (IGD) Standardized 690 Device Control Protocol V 1.0: WANIPConnection:1 Service 691 Template Version 1.01 For UPnP Version 1.0", DCP 05-001, 692 Nov 2001. 694 Appendix A. Residential Broadband LIS Discovery Example 696 This example shows how LIS discovery using U-NAPTR and DNS might be 697 performed in a residential broadband scenario. The assumed network 698 topology for this network is shown in Figure 4. 700 __________ __________ 701 +----------------+ ( ) ( ) 702 | NAT | ( ACCESS ) ( ) 703 | (Home Router) |-------( NETWORK )-------( INTERNET ) 704 | 192.0.2.75 | ( my.isp.net ) ( ) 705 +----------------+ ( ) ( ) 706 | ---------- ---------- 707 | : 708 | : 709 +----------------+ +-----------------+ 710 | DEVICE | | VOICE SERVICE | 711 | | | PROVIDER (VSP) | 712 | 192.168.0.55 | | STUN SERVER | 713 +----------------+ +-----------------+ 715 Figure 4: Example Network Topology 717 In this example, the host sits behind a home router that includes a 718 NAT function. The host is assigned an address from the private 719 192.168.x.x address range, in this case 192.168.0.55. The outbound 720 IP address provided to the home router is public and and belongs to 721 the my.isp.net domain; in this example the home router is assigned 722 192.0.2.75, which is also given the domain name 192-0-2- 723 75.my.isp.net. 725 In this example, several methods are not possible due to the 726 configuration of the devices and network. The DHCP server on the 727 home router does not support the LIS URI option, and a domain name is 728 not configured on the router. In addition to this, the UPnP service 729 on home router is disabled. Therefore, the host attempts these 730 methods and is unsuccessful. 732 The example first covers the unsuccessful attempts to discover the 733 LIS, followed by a successful application of DNS discovery based on 734 an address provided by a STUN server. In this situation, the STUN 735 server is provided by a Voice Service Provider (VSP) that the owner 736 of the host purchases a voice service from. The address of the STUN 737 server is configured on the host. The VSP is a separate entity on 738 the public Internet with no relation to the access network provider. 740 The sequence diagram below shows each of the failed attempts to 741 discover the LIS, followed by the successful discovery using the STUN 742 server, reverse DNS and the DNS discovery method. 744 +-------+ +--------+ +-----+ +-----+ +--------+ 745 | HOST | | HOME | | DNS | | LIS | | STUN | 746 | | | ROUTER | | | | | | SERVER | 747 +---+---+ +----+---+ +--+--+ +--+--+ +---+----+ 748 | | | | | 749 1 +--- DHCPINFORM -->| | | | 750 | | | | | 751 2 |<---- DHCPACK ----+ | | | 752 | | | | | 753 3 +------- DNS: PTR ------------->| | | 754 | 55.0.168.192.in-addr.arpa. | | | 755 | | | | | 756 4 |<------ DNS: no domain --------+ | | 757 | | | | | 758 5 +----- UPnP: ----->| | | | 759 | ssdp:discover | | | | 760 | | | | | 761 6 | (no response) | | | | 762 | | | | | 763 7 +---------------- STUN: Binding Request --------------->| 764 | | | | | 765 8 |<------- STUN: XOR-MAPPED-ADDRESS = (192.0.2.75) ------+ 766 | | | | | 767 9 +------- DNS: PTR ------------->| | | 768 | 75.2.0.192.in-addr.arpa. | | | 769 | | | | | 770 10 |<--- 192-0-2-205.my.isp.net ---+ | | 771 | | | | | 772 11 +--- DNS: NAPTR my.isp.net ---->| | | 773 | | | | | 774 12 |<--- https://lis.my.isp.net/ --+ | | 775 | | | | | 776 13 +-------- HELD: locationRequest ----------->| | 777 | | | | | 778 . . . . . 780 Figure 5: LIS Discovery Sequence 782 1. The host makes a DHCP request for the LIS URI option. To reduce 783 the overall time required in case the LIS URI is unknown, the 784 host also requests the domain name option. 786 2. The DHCP server (in the home router) responds but does not have 787 either datum. Therefore, the host is unable to use the DHCP 788 method, or use the domain name to perform U-NAPTR discovery. 790 3. The host then attempts reverse DNS based on its IP address 791 (192.168.0.55). The host makes a DNS PTR request for 792 "55.0.168.192.in-addr.arpa." 794 4. The DNS server has no knowledge of the private network segment 795 and so indicates that there is no such domain. 797 5. The host then must determine its address in a different network 798 segment. It first attempts to discover this using UPnP. The 799 host broadcasts a UPnP discovery message, attempting to locate a 800 UPnP capable device that supports the WANIPConnection profile. 802 6. There are no UPnP devices on the network and the UPnP discovery 803 message is unanswered. 805 7. The host contacts a STUN server, which is configured on the 806 host. It sends a Binding Request to the STUN server. 808 8. The STUN server responds to the Binding Request, including the 809 XOR-MAPPED-ADDRESS parameter. The host decodes this parameter, 810 which reveals the IP address of the home router: 192.0.2.75. 812 9. The host requests the domain name assigned to 192.0.2.75. It 813 makes a DNS PTR request to "75.2.0.192.in-addr.arpa." 815 10. The DNS server indicates that 192.0.2.75 is assigned the name 816 "192-0-2-75.my.isp.net." 818 11. The host removes the host part of the domain name and makes a 819 DNS NAPTR request for the domain "my.isp.net." 821 12. The DNS server provides all NAPTR records for the "my.isp.net." 822 domain. The host finds the record with a service tag of 823 "LIS:HELD" and retrieves the URI from the regexp field. The URI 824 of the LIS is found to be "https://lis.my.isp.net/". 826 13. The host sends a HELD "locationRequest" to the LIS. 828 Authors' Addresses 830 Martin Thomson 831 Andrew 832 PO Box U40 833 Wollongong University Campus, NSW 2500 834 AU 836 Phone: +61 2 4221 2915 837 Email: martin.thomson@andrew.com 838 URI: http://www.andrew.com/ 840 James Winterbottom 841 Andrew 842 PO Box U40 843 Wollongong University Campus, NSW 2500 844 AU 846 Phone: +61 2 4221 2938 847 Email: james.winterbottom@andrew.com 848 URI: http://www.andrew.com/ 850 Full Copyright Statement 852 Copyright (C) The IETF Trust (2008). 854 This document is subject to the rights, licenses and restrictions 855 contained in BCP 78, and except as set forth therein, the authors 856 retain all their rights. 858 This document and the information contained herein are provided on an 859 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 860 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 861 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 862 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 863 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 864 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 866 Intellectual Property 868 The IETF takes no position regarding the validity or scope of any 869 Intellectual Property Rights or other rights that might be claimed to 870 pertain to the implementation or use of the technology described in 871 this document or the extent to which any license under such rights 872 might or might not be available; nor does it represent that it has 873 made any independent effort to identify any such rights. Information 874 on the procedures with respect to rights in RFC documents can be 875 found in BCP 78 and BCP 79. 877 Copies of IPR disclosures made to the IETF Secretariat and any 878 assurances of licenses to be made available, or the result of an 879 attempt made to obtain a general license or permission for the use of 880 such proprietary rights by implementers or users of this 881 specification can be obtained from the IETF on-line IPR repository at 882 http://www.ietf.org/ipr. 884 The IETF invites any interested party to bring to its attention any 885 copyrights, patents or patent applications, or other proprietary 886 rights that may cover technology that may be required to implement 887 this standard. Please address the information to the IETF at 888 ietf-ipr@ietf.org.