idnits 2.17.1 draft-ietf-geopriv-l7-lcp-ps-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1387. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 5, 2007) is 6320 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '20' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1322, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-12 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '4') (Obsoleted by RFC 5389) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-06 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-06 -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. '9') (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '11') (Obsoleted by RFC 6733) == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-00 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-06 == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-02 -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '17') (Obsoleted by RFC 8224) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-13 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-09 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Siemens Networks GmbH & Co KG 4 Intended status: Informational H. Schulzrinne 5 Expires: July 9, 2007 Columbia U. 6 January 5, 2007 8 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and 9 Requirements 10 draft-ietf-geopriv-l7-lcp-ps-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 9, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document provides a problem statement, lists requirements and 44 captures discussions for a GEOPRIV Layer 7 Location Configuration 45 Protocol (LCP). This protocol aims to allow an end host to obtain 46 location information, by value or by reference, from a Location 47 Information Server (LIS) that is located in the access network. The 48 obtained location information can then be used for a variety of 49 different protocols and purposes. For example, it can be used as 50 input to the Location-to-Service Translation Protocol (LoST) or to 51 convey location within SIP to other entities. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5 59 3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7 60 3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9 61 4. Discovery of the Location Information Server . . . . . . . . . 11 62 5. Identifier for Location Determination . . . . . . . . . . . . 13 63 6. Virtual Private Network (VPN) Considerations . . . . . . . . . 17 64 6.1. VPN Tunneled Internet Traffic . . . . . . . . . . . . . . 17 65 6.2. VPN Client and End Point Physically Co-Located . . . . . . 17 66 6.3. VPN Client and End Point Physically Separated . . . . . . 18 67 7. Location-by-Reference and Location Subscriptions . . . . . . . 20 68 8. Preventing Faked Location based DoS Attacks . . . . . . . . . 22 69 8.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 22 70 8.2. Discussion about Countermeasures . . . . . . . . . . . . . 22 71 9. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 28 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 73 10.1. Capabilities of the Adversary . . . . . . . . . . . . . . 30 74 10.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 30 75 10.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 32 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 77 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 78 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 80 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 81 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 83 Intellectual Property and Copyright Statements . . . . . . . . . . 39 85 1. Introduction 87 This document provides a problem statement, lists requirements and 88 captures discussions for a GEOPRIV Layer 7 Location Configuration 89 Protocol (LCP). The protocol has two purposes: 91 o It is used to obtain location information from a special node, 92 called the Location Information Server (LIS). 94 o It enables the end host to obtain a reference to location 95 information. This reference can take the form of a subscription 96 URI, such as a SIP presence URI, an HTTP/HTTPS URI, or any others. 98 The need for these two functions can be derived from the scenarios 99 presented in Section 3. 101 This document splits the problem space into separate parts and 102 discusses them in separate subsections. Section 4 discusses the 103 challenge of discovering the Location Information Server in the 104 access network. Section 5 compares different types of identifiers 105 that can be used to retrieve location information. The concept of 106 subscription URIs is described in Section 7. Digitally signing 107 location information and the perceived benefits are covered in 108 Section 8. A list of requirements for the GEOPRIV Layer 7 Location 109 Configuration Protocol can be found in Section 9. This work is 110 heavily influenced by security considerations. Hence, almost all 111 sections address security concerns. A list of desired security 112 properties can be found in Section 10 together with a discussion 113 about possible threat models. 115 This document does not describe how the access network provider 116 determines the location of the end host. 118 2. Terminology 120 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 121 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 122 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], 123 with the qualification that unless otherwise stated these words apply 124 to the design of the GEOPRIV Layer 7 Location Configuration Protocol. 126 We also use terminology from [2] and [3]. 128 3. Scenarios 130 The following network types are within scope: 132 o DSL/Cable networks, WiMax-like fixed access 134 o Airport, City, Campus Wireless Networks, such as 802.11a/b/g, 135 802.16e/Wimax 137 o 3G networks 139 o Enterprise networks 141 We illustrate a few examples below. 143 3.1. Fixed Wired Environment 145 The following figure shows a DSL network scenario with the Access 146 Network Provider and the customer premises. The Access Network 147 Provider operates link and network layer devices (represented as 148 Node) and the Location Information Server (LIS). 150 +---------------------------+ 151 | | 152 | Access Network Provider | 153 | | 154 | +--------+ | 155 | | Node | | 156 | +--------+ +----------+ | 157 | | | | LIS | | 158 | | +---| | | 159 | | +----------+ | 160 | | | 161 +-------+-------------------+ 162 | Wired Network 163 <----------------> Access Network Provider demarc 164 | 165 +-------+-------------------+ 166 | | | 167 | +-------------+ | 168 | | NTE | | 169 | +-------------+ | 170 | | | 171 | | | 172 | +--------------+ | 173 | | Device with | Home | 174 | | NAPT and | Router | 175 | | DHCP server | | 176 | +--------------+ | 177 | | | 178 | | | 179 | +------+ | 180 | | End | | 181 | | Host | | 182 | +------+ | 183 | | 184 |Customer Premises Network | 185 | | 186 +---------------------------+ 188 Figure 1: DSL Scenario 190 The customer premises consists of a router with a Network Address 191 Translator with Port Address Translation (NAPT) and a DHCP server as 192 used in most Customer Premises Networks (CPN) and the Network 193 Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 194 protocols are terminated. The router in the home network (e.g., 195 broadband router, cable or DSL router) typically runs a NAPT and a 196 DHCP server. The NTE is a legacy device and in many cases cannot be 197 modified for the purpose of delivering location information to the 198 end host. The same is true of the device with the NAPT and DHCP 199 server. 201 It is possible for the NTE and the home router to physically be in 202 the same box, or for there to be no home router, or for the NTE and 203 end host to be in the same physical box (with no home router). An 204 example of this last case is where Ethernet service is delivered to 205 customers' homes, and the Ethernet NIC in their PC serves as the NTE. 207 Current Customer Premises Network (CPN) deployments frequently show 208 the following characteristics: 210 1. CPE = Single PC 212 1. with Ethernet NIC [PPPoE or DHCP on PC]; there may be a 213 bridged DSL or cable modem as NTE, or the Ethernet NIC might 214 be the NTE 216 2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC] 218 Note that the device with NAPT and DHCP of Figure 1 is not 219 present in such a scenario. 221 2. One or more hosts with at least one router [DHCP Client or PPPoE, 222 DHCP server in router; VoIP can be soft client on PC, stand-alone 223 VoIP device, or Analog Terminal Adaptor (ATA) function embedded 224 in router] 226 1. combined router and NTE 228 2. separate router with NTE in bridged mode 230 3. separate router with NTE [NTE/router does PPPoE or DHCP to 231 WAN, router provides DHCP server for hosts in LAN; double NAT 233 The majority of fixed access broadband customers use a router. The 234 placement of the VoIP client is mentioned to describe what sorts of 235 hosts may need to be able to request location information. Soft 236 clients on PCs are frequently not launched until long after bootstrap 237 is complete, and are not able to control any options that may be 238 specified during bootstrap. They also cannot control whether a VPN 239 client is operating on the PC. 241 3.2. Moving Network 243 An example of a moving network is a "WIMAX-like fixed wireless" 244 scenario that is offered in several cities, like New Orleans, Biloxi, 245 etc., where much of the communications infrastructure was destroyed 246 due to a natural disaster. The customer-side antenna for this 247 service is rather small (about the size of a mass market paperback 248 book) and can be run off battery power. The output of this little 249 antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this 250 Ethernet jack. The user would then run a PPPoE client to connect to 251 the network. Once the network connection is established, the user 252 can run a SIP client on the laptop. 254 The network-side antenna is, for example, connected through ATM to 255 the core network, and from there to the same BRASs that serve regular 256 DSL customers. These Broadband Remote Access Servers (BRASs) 257 terminate the PPPoE sessions, just like they do for regular DSL. 259 The laptop and SIP client are, in this case, unaware that they are 260 "mobile". All they see is an Ethernet connection, and the IP address 261 they get from PPPoE does not change over the coverage area. Only the 262 user and the network are aware of the laptop's mobility. 264 Further examples of moving networks can be found in busses, trains, 265 airplanes. 267 Figure 2 shows an example topology for a moving network. 269 +--------------------------+ 270 | Wireless | 271 | Access Network Provider | 272 | | 273 | +----------+| 274 | +-------+ LIS || 275 | | | || 276 | +---+----+ +----------+| 277 | | Node | | 278 | | | | 279 | +---+----+ | 280 | | | 281 +------+-------------------+ 282 | Wireless Interface 283 | 284 +------+-------------------+ 285 | | Moving Network | 286 | +---+----+ | 287 | | NTE | +--------+ | 288 | | +---+ Host | | 289 | +-+-----++ | B | | 290 | | \ +--------+ | 291 | | \ | 292 |+---+----+ \ +---+----+ | 293 || Host | \ | Host | | 294 || A | \+ B | | 295 |+--------+ +--------+ | 296 +--------------------------+ 298 Figure 2: Moving Network 300 3.3. Wireless Access 302 Figure 3 shows a wireless access network where a moving end host 303 obtains location information or references to location information 304 from the LIS. The access equipment us, in many cases, link layer 305 devices. This figure represents a hotspot network found in hotels, 306 airports, coffee shops. 308 +--------------------------+ 309 | Access Network Provider | 310 | | 311 | +----------+| 312 | +-------| LIS || 313 | | | || 314 | +--------+ +----------+| 315 | | Access | | 316 | | Point | | 317 | +--------+ | 318 | | | 319 +------+-------------------+ 320 | 321 +------+ 322 | End | 323 | Host | 324 +------+ 326 Figure 3: Wireless Access Scenario 328 4. Discovery of the Location Information Server 330 When an end host wants to retrieve location information from the LIS 331 it first needs to discover it. Based on the problem statement of 332 determining the location of the end host, which is known best by 333 entities close to the end host itself, we assume that the LIS is 334 located in the access network. Several procedures have been 335 investigated that aim to discovery the LIS in such an access network. 337 DHCP-based Discovery: 339 In some environments the Dynamic Host Configuration Protocol might 340 be a good choice for discovering the FQDN or the IP address of the 341 LIS. In environments where DHCP can be used it is also possible 342 to use the already defined location extensions. In environments 343 with legacy devices, such as the one shown in Section 3.1, a DHCP 344 based discovery solution is not possible. 346 DNS-based Discovery: 348 With this idea the end host obtains its public IP address (e.g., 349 via STUN [4]) in order to obtain its domain name (via the usual 350 reverse DNS lookup). Then, the SRV or NAPTR record for that 351 domain is retrieved. This relies on the user's public IP address 352 having a DNS entry. 354 Redirect Rule: 356 A redirect rule at a device in the access network, for example at 357 the AAA client, will be used to redirect the Geopriv-L7 signalling 358 messages (destined to a specific port) to the LIS. The end host 359 could then discover the LIS by sending a packet to almost any 360 address (as long it is not in the local network). The packet 361 would be redirected to the respective LIS being configured. The 362 same procedure is used by captive portals whereby any HTTP traffic 363 is intercepted and redirected. 365 Multicast Query: 367 An end node could also discover a LIS by sending a multicast 368 request to a well-known address. An example of such a mechanism 369 is multicast DNS (see [5] and [6]). 371 The LIS discovery procedure raises deployment and security issues. 372 When an end host discovers a LIS, 373 1. it does not talk to a man-in-the-middle adversary, and 375 2. it needs to ensure that the discovered entity is indeed an 376 authorized LIS. 378 5. Identifier for Location Determination 380 The LIS returns location information to the end host when it receives 381 a request. Some form of identifier is therefore needed to allow the 382 LIS to determine the current location of the target or a good 383 approximation of it. 385 The chosen identifier needs to have the following properties: 387 Ability for end host to learn or know the identifier: 389 The end host MUST know or MUST be able to learn the identifier 390 (explicitly or implicitly) in order to send it to the LIS. 391 Implicitly refers to the situation where a device along the path 392 between the end host and the LIS modifies the identifier, as it is 393 done by a NAT when an IP address based identifier is used. 395 Ability to use the identifier for location determination: 397 The LIS MUST be able to use the identifier (directly or 398 indirectly) for location determination. Indirectly refers to the 399 case where the LIS uses other identifiers locally within the 400 access network, in addition to the one provided by the end host, 401 for location determination. 403 Security properties of the identifier: 405 Misuse needs to be minimized whereby off-path adversary MUST NOT 406 be able to obtain location information of other hosts. A on-path 407 adversary in the same subnet SHOULD NOT be able to spoof the 408 identifier of another host in the same subnet. 410 The problem is further complicated by the requirement that the end 411 host should not be aware of the network topology and the LIS must be 412 placed in such a way that it can determine location information with 413 the available information. As shown in Figure 1 the host behind the 414 NTE/NAPT-DHCP device is not visible to the access network and the LIS 415 itself. In the DSL network environment some identifier used at the 416 NTE is observable for by the LIS/access network. 418 The following list discusses frequently mentioned identifiers and 419 their properties: 421 Host MAC address: 423 The host MAC address is known to the end system, but not carried 424 over an IP hop. 426 ATM VCI/VPI: 428 The VPI/VCI is generally only seen by the DSL modem. Almost all 429 routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35. 430 This VC is terminated at the DSLAM, which uses a different VPI/VCI 431 (per end customer) to connect to the ATM switch. Only the network 432 provider is able to map VPI/VCI values through its network. With 433 the arrival of VDSL, ATM will slowly be phased out in favor of 434 Ethernet. 436 Switch/Port Number: 438 This identifier is available only in certain networks, such as 439 enterprise networks, typically available via proprietary protocols 440 like CDP or, in the future, 802.1ab. 442 Cell ID: 444 This identifier is available in cellular data networks and the 445 cell ID might not be visible to the end host. 447 Authenticated User Identity: 449 In DSL networks the user credentials are, in many cases, only 450 known by the router and not to the end host. To the network, the 451 authenticated user identity is only available if a network access 452 authentication procedure is executed. In case of roaming it still 453 might not be available to the access network since security 454 protocols might provide user identity confidentiality and thereby 455 hide the real identity of the user allowing the access network to 456 only see a pseudonym or a randomized string. 458 Host Identifier: 460 The Host Identifier introduced by the Host Identity Protocol [7] 461 allows identification of a particular host. Unfortunately, the 462 network can only use this identifier for location determination if 463 the operator already stores an mapping of host identities to 464 location information. Furthermore, there is a deployment problem 465 since the host identities are not used in todays networks. 467 Cryptographically Generated Address (CGA): 469 The concept of a Cryptographically Generated Address (CGA) was 470 introduced by [8]. The basic idea is to put the truncated hash of 471 a public key into the interface identifier part of an IPv6 472 address. In addition to the properties of an IP address it allows 473 a proof of ownership. Hence, a return routability check can be 474 omitted. 476 Network Access Identifiers: 478 A Network Access Identifier [9] is only used during the network 479 access authentication procedure in RADIUS [10] or Diameter [11]. 480 Furthermore, in a roaming scenario it does not help the access 481 network to make meaningful decisions since the username part might 482 be a pseudonym and there is no relationship to the end host's 483 location. 485 Unique Client Identifier 487 The DSL Forum has defined that all devices that expect to be 488 managed by the TR-069 interface be able to generate an identifier 489 as described in DSL Forum TR-069v2 Section 3.4.4. It also has a 490 requirement that routers that use DHCP to the WAN use RFC 4361 491 [12] to provide the DHCP server with a unique client identifier. 492 This identifier is, however, not visible to the end host with the 493 assumption of a legacy device like the NTE. If we assume that the 494 LTE can be modified then a number of solutions come to mind 495 including DHCP based location delivery. 497 IP Address: 499 The end host's IP address may be used for location determination. 500 This IP address is not visible to the LIS if the end host is 501 behind one or multipel NATs. This is, however, not a problem 502 since the location of a host that is located behind a NAT cannot 503 be determined by the access network. The LIS would in this case 504 only see the public IP address of the NAT binding allocated by the 505 NAT, which is the correct behavior. The property of the IP 506 address for a return routability check is attractive as well to 507 return location information only to a device that transmitted the 508 request. The LIS receives the request and provides location 509 information back to the same IP address. If an adversary wants to 510 learn location information from an IP address other than its own 511 IP address then it would not see the response message (unless he 512 is on the subnetwork or at a router along the path towards the 513 LIS) since the LIS would return the message to the address where 514 it came from. 516 On a shared medium an adversary could ask for location information 517 of another host using its IP address. The adversary would be able 518 to see the response message since he is sniffing on the shared 519 medium unless security mechanisms (such as link layer encryption) 520 is in place. With a network deployment as shown in Section 3.1 521 with multiple hosts in the Customer Premise being behind a NAT the 522 LIS is unable to differentiate the individual end points. For 523 WLAN deployments as found in hotels, as shown in as shown in 524 Section 3.3, it is possible for an adversary to eavesdrop data 525 traffic and subsequently to spoof the IP address in a query to the 526 LIS to learn more detailed location information (e.g., specific 527 room numbers). Such an attack might, for example, compromise the 528 privacy of hotel guests. Note that DHCP would suffer from the 529 same problem here unless each node uses link layer security 530 mechanism. 532 Return routability checks are useful only if the adversary does 533 not see the response message and if the goal is to delay state 534 establishment. If the adversary is in a broadcast network then a 535 return routability check alone is not sufficient to prevent the 536 above attack since the adversary will observe the response. 538 6. Virtual Private Network (VPN) Considerations 540 To establish a VPN, a VPN client uses a particular VPN protocol to 541 create a tunnel to a VPN server. VPNs can be established using a 542 variety of protocols (e.g., IPsec, L2TP). The protocol used to 543 establish the VPN does not impact LIS discovery or location 544 acquisition. 546 VPN characteristics that can impact LIS discovery or acquiring a 547 location from a LIS include the relationship of the VPN client to the 548 communications application (e.g., VoIP phone), and whether the VPN 549 server requires the device with the VPN client to send all outbound 550 IP traffic across the VPN. 552 6.1. VPN Tunneled Internet Traffic 554 Any form of LIS discovery that would work without the VPN being 555 established, will also be able to work after the VPN has been 556 established. The DNS method of LIS discovery requires a device to 557 discover the proper IP address for discovering and querying the LIS. 558 Some devices may be expected to operate in a number of different 559 networks, including corporate networks, hotspots, home networks, and 560 protected networks by way of a VPN. The appropriate IP address to 561 use for LIS discovery may vary depending on the network. 563 It may be useful for such devices to do a reverse DNS lookup, LIS 564 discovery request, and LIS query for all IP addresses they can 565 determine for themselves. When all LISs involved in these queries 566 are properly configured, only one of these queries should be expected 567 to succeed. LISs should not be configured to provide a location for 568 an IP address that may be used by many geographically dispersed 569 users, or when the LIS has no way to determine the geographic 570 location of the device using the IP address. 572 This form of VPN will not interfere with queries to the LIS, once the 573 LIS has been discovered. It will also not interfere with location 574 dereferencing. 576 6.2. VPN Client and End Point Physically Co-Located 578 If LIS discovery and queries are done prior to establishing the VPN, 579 then the VPN will not interfere. For this reason, it is highly 580 desirable for devices that may support communications applications to 581 do location acquisition shortly after initial bootstrap, and prior to 582 establishing any VPN. As the communication application may not be 583 running prior to establishing the VPN, it is best if the 584 communication application is not responsible for location 585 acquisition. 587 Once a VPN has been established, the device should not permit 588 location acquisition to be attempted. Location acquisition done 589 after a VPN is established will either fail, or provide the wrong 590 location. 592 If the device does allow attempts at location acquisition after 593 establishing the VPN, these attempts should fail. LIS discovery 594 through DHCP, Redirect, and Multicast methods would fail due to lack 595 of support by the VPN server (it is undesirable for a VPN server to 596 support LIS discovery). For DNS discovery, the device might know a 597 variety of IP addresses, such as the IP address obtained at bootstrap 598 (which may be public or private, depending on whether the device is 599 behind a NAT), the VPN IP address, and an IP address the VPN provider 600 uses for Internet traffic through its firewall. RDNS of private LAN 601 addresses will fail. Success for RDNS of the VPN address would 602 depend on whether there are entries in the VPN provider's DNS server. 603 If RDNS of the VPN IP address succeeds, and the VPN provider has a 604 LIS in their network, LIS discovery of the VPN network's LIS should 605 succeed. It is desirable for a LIS that may get queries from devices 606 entering the network through a VPN, to provide an error response to 607 location queries that use such IP addresses. The LIS should not be 608 configured to return a location for these IP addresses. 610 RDNS of public IP addresses should generally succeed (assuming the 611 VPN provider's DNS allows for these queries to succeed). For IP 612 addresses used to connect the VPN network to the Internet, the 613 returned domain of RDNS would be the owner of that IP address, which 614 is either the VPN provider or its ISP. If the domain is that of the 615 VPN provider, the VPN provider may or may not have a DNS LIS entry 616 associated with that domain. If there is a LIS, that LIS should not 617 be configured to return a location for its public IP addresses. If 618 an ISP owns the domain of the VPN's public IP address, the device 619 will discover the ISP's LIS, and that LIS will return the location 620 where traffic from that IP address enters the access network. If the 621 device knows its public IP address, and RDNS and LIS discovery 622 succeeded, the LIS would not provide location information (assuming 623 the LIS would not be able to authenticate the device through means 624 other than return routability). The message that reached the LIS 625 would not be using (in the IP Header) an IP address from its domain. 627 If the private network allows traffic to go to the Internet, 628 dereferencing of a location reference will work. 630 6.3. VPN Client and End Point Physically Separated 632 In this case, it is possible for the device with the VPN client to 633 participate in the location acquisition process, and to provide 634 location to end devices. If the VPN client device does participate, 635 then it must acquire location information before setting up its VPN. 637 If the VPN client device that participates in location acquisition is 638 also the DHCP server for the LAN, then it would be able to either 639 provide its location by DHCP, or provide itself as the LIS by DHCP. 640 If this device names itself as the DNS server for devices in the LAN, 641 then it could support RDNS for LAN addresses and provide itself as 642 the LIS. If it says it is the LIS, then it must be able to respond 643 to LIS queries for location acquisition. This device would also be 644 able to support Redirect or Multicast methods of LIS determination. 646 If the VPN client device does not participate in location 647 acquisition, then location acquisition will either fail or provide 648 the wrong location, with the same results as described in section X.2 649 for a device that attempts location acquisition after establishing a 650 VPN. 652 If the private network allows traffic to go to the Internet, 653 dereferencing of a location reference will work. 655 7. Location-by-Reference and Location Subscriptions 657 In mobile wireless networks it is not efficient for the end host to 658 periodically query the LIS for up-to-date location information. 659 Furthermore, the end host might want to delegate the task of 660 retrieving and publishing location information to a third party, such 661 as a presence server. Finally, in some deployments the network 662 operator might not want to make location information available to the 663 end hosts. 665 These usage scenarios motivated the introduction of the location-by- 666 reference concept. Depending on the type of reference, such as HTTP/ 667 HTTPS or SIP presence URI, different operations can be performed. 668 While an HTTP/HTTPS URI can be resolved to location information, a 669 SIP presence URI provides further benefits from the SUBSCRIBE/NOTIFY 670 concept that can additionally be combined with location filters [13]. 672 Figure 4 shows the assumed communication model: 674 +--------+ Dereferencing +-----------+ 675 | | Protocol (3) | | 676 | LIS +---------------+ Location | 677 | | | Recipient | 678 +---+----+ | | 679 | +----+------+ 680 | -- 681 | Geopriv-L7 -- 682 | Protocol -- 683 | (1) --- 684 | -- Geopriv 685 | --- Using (e.g.,SIP) 686 | -- Protocol 687 +----+-----+ -- (2) 688 | Target / +-- 689 | End Host | 690 +----------+ 692 Figure 4: Communication Model 694 Note that there is no requirement for using the same protocol in (1) 695 and (3). 697 The following list describes the location subscription idea: 699 1. The end host discovers the LIS. 701 2. The end host sends a request to the LIS asking for a location-by- 702 reference, as shown in (1) of Figure 4. 704 3. The LIS responds to the request and includes a location object 705 together with a subscription URI. 707 4. The Target puts the subscription URI into a SIP message as 708 described in [14] forwards it to a Location Recipient, as shown 709 in (2) of Figure 4. The Location Recipient subscribes to the 710 obtained subscription URI (see (3) of Figure 4) and potentially 711 uses a location filter (see [13]) to limit the notification rate. 713 5. If the Target moves outside a certain area, indicated by the 714 location filter, then the Location Recipient will receive a 715 notification. 717 Note that the Target may also act in the role of the Location 718 Recipient whereby it would subscribe to its own location information. 719 For example, the Target obtains a subscription URI from the 720 Geopriv-L7 protocol. It subscribes to the URI in order to obtain its 721 currently location information, which then serves as input to a LoST 722 query (see [15]) in order to acquire the service boundary (e.g., PSAP 723 boundary). The service boundary indicates the region where the 724 device can move without the need to re-query since the returned 725 answer remains unchanged. The Target uses this service boundary to 726 location filters an updates the subscription. If the Target moves 727 outside a certain area, indicated by the location filter, it will 728 receive a notification and knows that re-querying LoST to obtain a 729 new service boundary is necessary. 731 For location-by-reference, the LIS needs to maintain a list of 732 randomized URIs for each host, timing out these URIs after the 733 reference expires. References need to expire to prevent the 734 recipient of such a URL from being able to (in some cases) 735 permanently track a host. Furthermore, this mechanism also offers 736 garbage collection capability for the LIS. 738 Location references must prevent adversaries from obtaining the 739 Target's location. There are at least two approaches: The location 740 reference contains a random component and allows any holder of the 741 reference to obtain location information. Alternatively, the 742 reference can be public and the LIS performs access control via a 743 separate authentication mechanism, such as HTTP digest or TLS client 744 side authentication, when resolving the reference to a location 745 object. 747 8. Preventing Faked Location based DoS Attacks 749 This section describes a possible security threat in emergency 750 related location conveyance and subsequently discusses 751 countermeasures to overcome the threat. 753 8.1. Security Threat 755 Consider an end host that wants to act maliciously and creates its 756 own location object with faked location information and uses this 757 information in a subsequent SIP communication. In case of an 758 emergency call the other communication partner, the Public Safety 759 Answering Point (PSAP) operator, would use the information 760 potentially without having a further possibility to verify the 761 received location information. Emergency personnel would be sent to 762 the indicated location noticing that there is no incident. 764 Hence, the PSAP operator, and the Location Recipient in general, 765 would like to ensure that the provided location information is 766 genuine, accurate and fresh to avoid taking wrong actions, such as 767 dispatching emergency personnel to a wrong location. 769 There seems to be a need for preventing location forgery, replay and 770 substitution attacks, which are all forms of sending a location which 771 is deliberately not that of the end host. As shown below, various 772 forms of countermeasures are possible to mitigate these attacks. 773 Although some aspects are within the scope of the Geopriv-L7 Location 774 Configuration Protocol (LCP), which is between a LIS and an Target, 775 some aspects refer to other protocols, as shown in Figure 4. For 776 example, in an emergency call, the PSAP (as a Location Recipient) 777 wishes to verify that the location is indeed that of the calling 778 party. Further, the Geopriv-L7 LCP is not the only protocol that 779 could be used by an end host to acquire its location. Therefore, the 780 topic of signatures on the location information was deemed out of 781 scope. The subsequent discussion about countermeaures aims to 782 capture the state of the discussions and illustrates the complexity 783 in the overall design. 785 8.2. Discussion about Countermeasures 787 The goal of the above-described mechanism is to prevent prank calls 788 and, in case of emergency services, unnecessary first-responder 789 dispatch. As such, it is a mechanism to reduce the vulnerability of 790 denial of service attacks. The benefit of a digital signature 791 created by the LIS and covering the location information (plus some 792 other fields) is to treat a missing or invalid signature as suspect 793 during the call. The call would be treated differently in the sense 794 that more questions might be asked (if an interaction with a human 795 person is possible). In case of emergency services, the call might 796 get ranked differently if certain criteria are not fulfilled and if 797 the PSAP operator is confronted with a massive amount of calls 798 without the possiblity to respond to all of them. 800 8.2.1. Signed Location Information 802 One of the proposed countermeasures is to sign location information 803 by the LIS before it is sent to the end host whereby the signed 804 location information is verified by the final Location Recipient 805 rather than the Target. This prevents the Target from tampering with 806 the received location information since the digital signature would 807 become invalid. The Location Recipient would be able to verify the 808 source of the location information. Since the number of nodes that 809 may play the role of a Location Recipient is large it is difficult to 810 utilize a pre-shared secret key based infrastructure. Hence, a 811 public key based infrastructure is required but authorization still 812 remains challenging. 814 This solution approach is challenging when a PIDF-LO [16] has to be 815 signed (instead of location information only) since the PIDF-LO 816 contains more than just location information, such as "entity" 817 attribute of the 'presence' element, and usage-rules (e.g., 818 'retransmission-allowed', 'retention-expires', 'ruleset-reference', 819 'note-well'). 821 The value for the "entity" attribute of the 'presence' element is, in 822 many cases, not known to the L2/L3 provider. If the LIS signs some 823 layer-2/layer-3 (e.g., PPP/RADIUS/NAI) identity as entity URI, it 824 will unlikely be the SIP URI. 826 To prevent adversaries from reusing an eavesdropped signed location 827 object it is necessary to include additional information when 828 generating the digital signature. For example, a timestamp and a 829 validity field are useful to prevent certain replay attacks. 830 Furthermore, the "entity" attribute may be included in the digital 831 signature of a PIDF-LO with the following semantic: When using the 832 signed location object (e.g., in SIP or another higher layer 833 protocol), the Target needs to authenticate to the Location Recipient 834 using the same identity carried in the "entity" attribute of the 835 'presence' element of the signed PIDF-LO. Using SIP, for example, a 836 SIP proxy server could assert the entity URI corresponding to the 837 Target using the SIP identity mechanism. 839 Including the layer 7 identity into the "entity" attribute of the 840 'presence' element poses a privacy problem since the access network 841 provider can now see an identity that is in use. Hence, the LIS and 842 possibly unauthorized listeners (if there's no privacy protection) 843 find out where the L7 entity is located, rather than just the 844 location information. 846 With regard to the ability for an adversary to replay an eavesdropped 847 a signed location object, the following two approaches need to be 848 considered: 850 1. A signed PIDF-LO with the L7 identity included, conveyed without 851 confidentiality protection from the Target to the Location 852 Recipient, and 854 2. A signed PIDF-LO, without the L7 identity, conveyed with 855 confidentiality protection from the Target to the Location 856 Recipient. 858 Note that in both cases confidentiality protection for the 859 communication between the LIS and the Target is provided. (2) has the 860 same security properties as (1) in terms of the ability of somebody 861 else to steal and re-use the PIDF-LO ("location theft") (assuming the 862 Location Recipient and the Target are honest). 864 An adversary might, for example, want to perform a replay attack by 865 eavesdropping the signed location object. If the LIS includes 866 additional attributes, such as a timestamp and the validity time, the 867 vulnerability can be reduced although not entirely prevented. The 868 reason for an adversary to still be able to replay the location 869 information is that there is no verifiable identifier is associated 870 with the signed location information. For example, the LIS might 871 include the IP address of the end host to the signed location object. 872 Spoofing the IP address is, however, relatively easy. Moreover, the 873 IP address that is used to associate the location information cannot 874 be verified by the LR since the IP address can be modified 875 legitimately (e.g., NAT reasons) or might not be seen due to 876 tunneling techniques (e.g., VPN, Mobile IP). 878 Ideally, an "identifier" with the property of being non-spoofable by 879 an adversary and verifiable by the LR when it receives a signed 880 location object, which will ensure that the submitted location 881 information is actually sent by the claimed end host and not 882 replayed. One such verifiable identifier is a public key, the serial 883 number of a certificate, a hash of a public key (in the sense of 884 Purpose-Built-Keys or Cryptographically-Generated-Addresses) or the 885 value of a hash chain. We call this identifier, key identifier or 886 keyID for short. 888 In more details, the end host provides this identifier to the LIS and 889 it is signed together with location information. The following steps 890 are executed: 892 1. The end host interacts with the LIS to obtain its location 893 information. The communication is secured using Transport Layer 894 Security. This request carries the keyID. In this example, we 895 use a keyID that represents the hash of a public key. The LIS 896 ties the received keyID to the location object and signs it. 898 2. The LIS returns the signed location object that includes the 899 keyID to the requesting end host. 901 3. Whenever the end host wants to distribute its location 902 information to a LR, it attaches location information to a SIP 903 message as described in [14]. The end host computes a digital 904 signature over the SIP header fields and signed location object 905 (as, for example, envisioned by SIP Identity [17]) with the 906 private key that corresponds to the hashed public key found in 907 the signed location object. 909 4. This message is sent to the LR. 911 5. The LR receives the message and it performs the following steps: 913 * It retrieves the public key. 915 * It computes the hash over the public key and compares it with 916 the value in the key identifier included in the signed 917 location object. 919 * It verifies the digital signature and thereby ensures that the 920 end host is indeed in possession of the private key 921 corresponding to the obtained public key. 923 * It verifies the digital signature protecting the location 924 information and checks whether it was signed by a trusted 925 access provider. 927 Even if an adversary eveasdrops the communication between the end 928 host and the LR it cannot successfully replay a signed location 929 object since it does not know the private key corresponding to the 930 hashed public key found in the signed location information. The 931 achieved security protection might even be stronger in context of 932 CGAs. 934 8.2.2. Authenticated Calls 936 In many cases, authenticated calls, i.e., verifying the callers 937 identity, are at least as useful as location signing since it 938 establishes accountability for later prosecution. 940 If most of the legitimate calls are authenticated in some way, then 941 it is possible, under attack conditions only, to give "dubious" calls 942 lower priority or to have them go through some sort of turing test. 943 As an example, PSAP operators do not want to reject emergency calls 944 regardless of how they look like, but if the alternative is wasting 945 90% of the resources on bogus calls (and thus leaving many legitimate 946 callers stranded) and not handling the unlucky unauthenticated, the 947 expected outcome is better if you can separate. This is the standard 948 "triage" model used in emergency medicine. 950 If somebody places a signed (known-third-party VSP-authenticated) 951 call, there is at least the possibility of catching a malicious 952 caller and the number of such calls is limited. Thus, there are only 953 legitimate calls left 955 o that use end system location determination (e.g., GPS, manual 956 configuration); 958 o that have no (known) VSP; 960 o that are not signed in some other way 962 In general, it is necessary to separate authentication from charging. 963 There is no reason for tying authentication, authorization and 964 charging together for this particular context. For example, 965 certificates can be used, for example, for emergency service without 966 being subscribed to either a VSP or ISP. 968 8.2.3. Location-by-Reference 970 The concept of location-by-reference was described in Section 7. The 971 properties of location signing are very similar (if not equal) to the 972 properties of the location-by-reference concept when the Location 973 Recipient only authenticates the LIS (but not vice-versa). Both 974 mechanisms allow the Location Recipient to authenticate the LIS (and 975 potentially the access network provider). 977 There are also a few drawbacks with the location signing and the 978 location-by-reference concept: 980 o Location signing has very limited utility if the number of signing 981 parties is very large 983 o Location signing has very limited utility for commercial 984 transactions. Commercial entities do not care whether a customer 985 lies about their location, as long as they can make you pay for 986 the service you asked for. 988 Authenticated calls also have their disadvantage since they require 989 end-host or end-user certificates, which creates a deployment burden, 990 unless mechanisms similar to SIP Identity [18] are used. 991 Furthermore, authenticated calls do not prevent attacks where the 992 location information was obtained unsecured from a LIS and an 993 adversary in the access network was able to tamper with the in-flight 994 location information. 996 9. Requirements 998 The following requirements and assumptions have been identified: 1000 Requirement L7-1: Identifier Choice 1002 The LIS MUST be presented with a unique identifier of its own 1003 addressing realm associated in some way with the physical location 1004 of the end host. 1006 An identifier is only appropriate if it is from the same realm as 1007 the one for which the location information service maintains 1008 identifier to location mapping. 1010 Requirement L7-2: Mobility Support 1012 The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 1013 broad range of mobility from devices that can only move between 1014 reboots, to devices that can change attachment points with the 1015 impact that their IP address is changed, to devices that do not 1016 change their IP address while roaming, to devices that 1017 continuously move by being attached to the same network attachment 1018 point. 1020 Requirement L7-3: Layer 7 and Layer 2/3 Provider Relationship 1022 The design of the GEOPRIV Layer 7 Location Configuration Protocol 1023 MUST NOT assume a business or trust relationship between the 1024 provider of application layer (e.g., SIP, XMPP, H.323) provider 1025 and the access network provider operating the LIS. 1027 Requirement L7-4: Layer 2 and Layer 3 Provider Relationship 1029 The design of the GEOPRIV Layer 7 Location Configuration Protocol 1030 MUST assume that there is a trust and business relationship 1031 between the L2 and the L3 provider. The L3 provider operates the 1032 LIS and needs to obtain location information from the L2 provider 1033 since this one is closest to the end host. If the L2 and L3 1034 provider for the same host are different entities, they cooperate 1035 for the purposes needed to determine end system locations. 1037 Requirement L7-5: Legacy Device Considerations 1039 The design of the GEOPRIV Layer 7 Location Configuration Protocol 1040 MUST consider legacy residential NAT devices and NTEs in an DSL 1041 environment that cannot be upgraded to support additional 1042 protocols, for example to pass additional information through 1043 DHCP. 1045 Requirement L7-6: VPN Awareness 1047 The design of the GEOPRIV Layer 7 Location Configuration Protocol 1048 MUST assume that at least one end of a VPN is aware of the VPN 1049 functionality. In an enterprise scenario, the enterprise side 1050 will provide the LIS used by the client and can thereby detect 1051 whether the LIS request was initiated through a VPN tunnel. 1053 Requirement L7-7: Network Access Authentication 1055 The design of the GEOPRIV Layer 7 Location Configuration Protocol 1056 MUST NOT assume prior network access authentication. 1058 Requirement L7-8: Network Topology Unawareness 1060 The design of the GEOPRIV Layer 7 Location Configuration Protocol 1061 MUST NOT assume end systems being aware of the access network 1062 topology. End systems are, however, able to determine their 1063 public IP address(es) via mechanisms such as STUN [4] or NSIS 1064 NATFW NSLP [19] . 1066 10. Security Considerations 1068 10.1. Capabilities of the Adversary 1070 As common elsewhere, several kinds of attackers can be distinguished. 1071 As always, Alice is the "good guy" and Trudy the attacker. Attackers 1072 can be: 1074 o off-path, i.e., it cannot see packets between Alice and the LIS; 1076 o on-path, i.e., can see such packets. 1078 On-path attackers may be: 1080 o passive, i.e., can only observe; 1082 o semi-active, i.e., can inject packets with a bogus IP address, but 1083 cannot prevent the delivery of packets from the end system or 1084 modify these packets; 1086 o active, i.e., can inject and modify packets at will. 1088 10.2. Threats 1090 When the reference to location information is communicated to the 1091 Location Recipient then on-path adversaries can eavesdrop the 1092 signaling communication together with the reference. Furthermore, 1093 the end-to-end communication might involve SIP proxies and they may 1094 not be trustworthy. Hence, they can eavesdrop the reference and 1095 misuse it (by resolving it). 1097 Untrusted proxies that are involved in the communication lead to a 1098 requirement for the Target to selectively grant access to already 1099 known and trusted Location Recipients. 1101 The following list presents threats specific to location information 1102 handling: 1104 Place-Shifting (PS): 1106 Trudy pretends to be at an arbitrary location. 1108 Time-Shifting (TS): 1110 Trudy pretends to be at a location she was a while ago. 1112 Location-Theft (LT): 1114 Trudy observes Alice's location and replays it as her own location 1115 object. 1117 Location-Identity-Theft (LIT): 1119 Trudy observes Alice's location and her identity (e.g., presence 1120 identity) and replays it. 1122 Location-Swapping (LS): 1124 Trudy' and Trudy'', located at different locations, can collude 1125 and swap location objects and pretend to be in each other's 1126 location. 1128 Table 1 shows the different threats and the applicability of proposed 1129 countermeasures. 1131 +----+----------+-----------+-----------+---------------+-----------+ 1132 | | Asserted | Timestamp | Encrypted | Authenticated | Location | 1133 | | Location | | Location | Call | by | 1134 | | | | | | Reference | 1135 +----+----------+-----------+-----------+---------------+-----------+ 1136 | PS | X | - | - | Track | X | 1137 | | | | | Offender | | 1138 | | | | | | | 1139 | TS | - | X | - | Track | Limits | 1140 | | | | | Offender | Impact | 1141 | | | | | | | 1142 | LT | - | - | X | Track | - | 1143 | | | | | Offender | | 1144 | | | | | | | 1145 | LI | - | - | X | - | - | 1146 | T | | | | | | 1147 | | | | | | | 1148 | LS | - | Limits | - | Track | - | 1149 | | | Impact | | Offender | | 1150 +----+----------+-----------+-----------+---------------+-----------+ 1152 Table 1 1154 Legend: 1156 -: Functionality not necessary to accomplish the desired 1157 functionality. 1159 X: Functionality needed to prevent threat. 1161 10.3. Requirements 1163 The following requirements are placed on the location-by-value 1164 approach: 1166 o No conclusion was reached whether a PIDF-LO or just location 1167 information has to be signed. 1169 o No conclusion was reached whether location information should be 1170 signed. 1172 o No conclusion was reached what could be signed. 1174 The following requirements are placed on the location-by-reference 1175 approach: 1177 o The reference MUST be valid for a limited amount of time. 1179 o The reference MUST be hard to guess, i.e., it MUST contain a 1180 cryptographically random component. 1182 o The reference MUST NOT contain any information that identifies the 1183 user, device or address of record 1185 o The Location Recipient MUST be able to resolve the reference more 1186 than once (i.e., there is no implicit limit on the number of 1187 dereferencing actions). 1189 o Possessing a reference to location information allows a Location 1190 Recipient to repeately obtain the latest information about the 1191 Target with the same granularity. 1193 o The Target MUST be able to resolve the reference itself. 1195 11. IANA Considerations 1197 This document does not require actions by IANA. 1199 12. Contributors 1201 This contribution is a joint effort of the GEOPRIV Layer 7 Location 1202 Configuration Requirements Design Team of the Geopriv WG. The 1203 contributors include Henning Schulzrinne, Barbara Stark, Marc 1204 Linsner, Andrew Newton, James Winterbottom, Martin Thomson, Rohan 1205 Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. 1207 The design team members can be reached at: 1209 Marc Linsner: mlinsner@cisco.com 1211 Rohan Mahy: rohan@ekabal.com 1213 Andrew Newton: andy@hxr.us 1215 Jon Peterson: jon.peterson@neustar.biz 1217 Brian Rosen: br@brianrosen.net 1219 Henning Schulzrinne: hgs@cs.columbia.edu 1221 Barbara Stark: Barbara.Stark@bellsouth.com 1223 Martin Thomson: Martin.Thomson@andrew.com 1225 Hannes Tschofenig: Hannes.Tschofenig@siemens.com 1227 James Winterbottom: James.Winterbottom@andrew.com 1229 The authors would like to thank Barbara Stark for her 'Virtual 1230 Private Network (VPN) Considerations' text proposal. 1232 13. Acknowledgements 1234 We would like to thanks the IETF GEOPRIV working group chairs, Andy 1235 Newton, Allison Mankin and Randall Gellens, for creating this design 1236 team. Furthermore, we would like thank Andy Newton for his support 1237 during the design team mailing list, the Jabber chat conference and 1238 the phone conference discussions. Finally, we would like to thank 1239 Murugaraj Shanmugam for his draft review. 1241 14. References 1243 14.1. Normative References 1245 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1246 Levels", RFC 2119, BCP 14, March 1997. 1248 [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1249 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1251 [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 1252 Context Resolution with Internet Technologies", 1253 draft-ietf-ecrit-requirements-12 (work in progress), 1254 August 2006. 1256 14.2. Informative References 1258 [4] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 1259 - Simple Traversal of User Datagram Protocol (UDP) Through 1260 Network Address Translators (NATs)", RFC 3489, March 2003. 1262 [5] Aboba, B., "Link-local Multicast Name Resolution (LLMNR)", 1263 draft-ietf-dnsext-mdns-47 (work in progress), August 2006. 1265 [6] Cheshire, S. and M. Krochmal, "Multicast DNS", 1266 draft-cheshire-dnsext-multicastdns-06 (work in progress), 1267 August 2006. 1269 [7] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 1270 (work in progress), June 2006. 1272 [8] Aura, T., "Cryptographically Generated Addresses (CGA)", 1273 RFC 3972, March 2005. 1275 [9] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 1276 Access Identifier", RFC 4282, December 2005. 1278 [10] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1279 Authentication Dial In User Service (RADIUS)", RFC 2865, 1280 June 2000. 1282 [11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1283 "Diameter Base Protocol", RFC 3588, September 2003. 1285 [12] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers 1286 for Dynamic Host Configuration Protocol Version Four (DHCPv4)", 1287 RFC 4361, February 2006. 1289 [13] Mahy, R., "A Document Format for Filtering and Reporting 1290 Location Notications in the Presence Information Document 1291 Format Location Object (PIDF-LO)", 1292 draft-ietf-geopriv-loc-filters-00 (work in progress), 1293 March 2006. 1295 [14] Polk, J. and B. Rosen, "Session Initiation Protocol Location 1296 Conveyance", draft-ietf-sip-location-conveyance-06 (work in 1297 progress), January 2007. 1299 [15] Hardie, T., "LoST: A Location-to-Service Translation Protocol", 1300 draft-ietf-ecrit-lost-02 (work in progress), October 2006. 1302 [16] Peterson, J., "A Presence-based GEOPRIV Location Object 1303 Format", RFC 4119, December 2005. 1305 [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1306 Identity Management in the Session Initiation Protocol (SIP)", 1307 RFC 4474, August 2006. 1309 [18] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1310 Identity Management in the Session Initiation Protocol (SIP)", 1311 draft-ietf-sip-identity-06 (work in progress), October 2005. 1313 [19] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 1314 (NSLP)", draft-ietf-nsis-nslp-natfw-13 (work in progress), 1315 October 2006. 1317 [20] Schulzrinne, H., "Common Policy: A Document Format for 1318 Expressing Privacy Preferences", 1319 draft-ietf-geopriv-common-policy-11 (work in progress), 1320 August 2006. 1322 [21] Schulzrinne, H., "Geolocation Policy: A Document Format for 1323 Expressing Privacy Preferences for Location Information", 1324 draft-ietf-geopriv-policy-09 (work in progress), December 2006. 1326 Authors' Addresses 1328 Hannes Tschofenig 1329 Siemens Networks GmbH & Co KG 1330 Otto-Hahn-Ring 6 1331 Munich, Bavaria 81739 1332 Germany 1334 Phone: +49 89 636 40390 1335 Email: Hannes.Tschofenig@siemens.com 1336 URI: http://www.tschofenig.com 1338 Henning Schulzrinne 1339 Columbia University 1340 Department of Computer Science 1341 450 Computer Science Building 1342 New York, NY 10027 1343 US 1345 Phone: +1 212 939 7004 1346 Email: hgs+ecrit@cs.columbia.edu 1347 URI: http://www.cs.columbia.edu 1349 Full Copyright Statement 1351 Copyright (C) The IETF Trust (2007). 1353 This document is subject to the rights, licenses and restrictions 1354 contained in BCP 78, and except as set forth therein, the authors 1355 retain all their rights. 1357 This document and the information contained herein are provided on an 1358 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1359 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1360 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1361 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1362 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1363 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1365 Intellectual Property 1367 The IETF takes no position regarding the validity or scope of any 1368 Intellectual Property Rights or other rights that might be claimed to 1369 pertain to the implementation or use of the technology described in 1370 this document or the extent to which any license under such rights 1371 might or might not be available; nor does it represent that it has 1372 made any independent effort to identify any such rights. Information 1373 on the procedures with respect to rights in RFC documents can be 1374 found in BCP 78 and BCP 79. 1376 Copies of IPR disclosures made to the IETF Secretariat and any 1377 assurances of licenses to be made available, or the result of an 1378 attempt made to obtain a general license or permission for the use of 1379 such proprietary rights by implementers or users of this 1380 specification can be obtained from the IETF on-line IPR repository at 1381 http://www.ietf.org/ipr. 1383 The IETF invites any interested party to bring to its attention any 1384 copyrights, patents or patent applications, or other proprietary 1385 rights that may cover technology that may be required to implement 1386 this standard. Please address the information to the IETF at 1387 ietf-ipr@ietf.org. 1389 Acknowledgment 1391 Funding for the RFC Editor function is provided by the IETF 1392 Administrative Support Activity (IASA).