idnits 2.17.1 draft-ietf-geopriv-l7-lcp-ps-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (July 13, 2009) is 5394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-07 == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-07 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-20 -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational H. Schulzrinne 5 Expires: January 14, 2010 Columbia University 6 July 13, 2009 8 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and 9 Requirements 10 draft-ietf-geopriv-l7-lcp-ps-10.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 January 14, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document provides a problem statement, lists requirements and 49 captures design aspects for a Geopriv Layer 7 Location Configuration 50 Protocol L7 (LCP). This protocol aims to allow an end host to obtain 51 location information, by value or by reference, from a Location 52 Information Server (LIS) that is located in the access network. The 53 obtained location information can then be used for a variety of 54 different protocols and purposes. For example, it can be used as 55 input to the Location-to-Service Translation Protocol (LoST) or to 56 convey location within SIP to other entities. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5 64 3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 8 65 3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9 66 4. Discovery of the Location Information Server . . . . . . . . . 11 67 5. Identifier for Location Determination . . . . . . . . . . . . 13 68 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 78 1. Introduction 80 This document provides a problem statement, lists requirements and 81 captures design aspects for a Geopriv Layer 7 Location Configuration 82 Protocol L7 (LCP). The protocol has two purposes: 84 o It is used to obtain location information (referred as "Location 85 by Value" or LbyV) from a dedicated node, called the Location 86 Information Server (LIS). 88 o It enables the Target to obtain a reference to location 89 information (referred as "Location by Reference" or LbyR). This 90 reference can take the form of a subscription URI, such as a SIP 91 presence based Uniform Resource Identifier (URI), a HTTP/HTTPS 92 URI, or another URI. The requirements related to the task of 93 obtaining a LbyR are described in a separate document, see 94 [I-D.ietf-geopriv-lbyr-requirements]. 96 The need for these two functions can be derived from the scenarios 97 presented in Section 3. 99 For this document we assume that the Geopriv Layer 7 LCP runs between 100 the end host (i.e., the Target in [RFC3693] terminology) and the LIS. 102 This document is structured as follows. Section 4 discusses the 103 challenge of discovering the LIS in the access network. Section 5 104 compares different types of identifiers that can be used to retrieve 105 location information. A list of requirements for the L7 LCP can be 106 found in Section 6. 108 This document does not describe how the access network provider 109 determines the location of the end host since this is largely a 110 matter of the capabilities of specific link layer technologies or 111 certain deployment environments. 113 2. Terminology 115 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 116 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 117 and "OPTIONAL" are to be interpreted as described in RFC 2119 118 [RFC2119], with the qualification that unless otherwise stated these 119 words apply to the design of the Geopriv Layer 7 Location 120 Configuration Protocol. 122 The term Location Information Server (LIS) refers to an entity 123 capable of determining the location of a Target and of providing that 124 location information, a reference to it, or both via the Location 125 Configuration Protocol (LCP) to the requesting party. In most cases 126 the requesting party is the Target itself but it may also be an 127 authorized entity that acts on behalf of it, such as a SIP proxy or 128 another LIS. 130 This document also uses terminology from [RFC3693] (such as Target) 131 and [I-D.ietf-ecrit-requirements] (such as Internet Access Provider 132 (IAP), Internet Service Provider (ISP), and Application Service 133 Provider (ASP)). 135 With the term "Access Network Provider" we refer to the Internet 136 Access Provider (IAP) and the Internet Service Provider (ISP) without 137 further distinguishing these two entities as it is not relevant for 138 the purpose of this document. An additional requirements document on 139 LIS-to-LIS [I-D.winterbottom-geopriv-lis2lis-req] shows scenario 140 where the separation between IAP and ISP is important. 142 3. Scenarios 144 This section describes a few network scenarios where the L7 LCP may 145 be used. Note that this section does not aim to exhaustively list 146 all possible deployment environments. Instead we focus on the 147 following environments: 149 o DSL/Cable networks, WiMax-like fixed access 151 o Airport, City, Campus Wireless Networks, such as 802.11a/b/g, 152 802.16e/Wimax 154 o 3G networks 156 o Enterprise networks 158 We illustrate a few examples below. 160 3.1. Fixed Wired Environment 162 Figure 1 shows a Digital subscriber line (DSL) network scenario with 163 the Access Network Provider and the customer premises. The Access 164 Network Provider operates link and network layer devices (represented 165 as Node) and the LIS. 167 +---------------------------+ 168 | | 169 | Access Network Provider | 170 | | 171 | +--------+ | 172 | | Node | | 173 | +--------+ +----------+ | 174 | | | | LIS | | 175 | | +---| | | 176 | | +----------+ | 177 | | | 178 +-------+-------------------+ 179 | Wired Network 180 <----------------> Access Network Provider demarc 181 | 182 +-------+-------------------+ 183 | | | 184 | +-------------+ | 185 | | NTE | | 186 | +-------------+ | 187 | | | 188 | | | 189 | +--------------+ | 190 | | Device with | Home | 191 | | NAPT and | Router | 192 | | DHCP server | | 193 | +--------------+ | 194 | | | 195 | | | 196 | +------+ | 197 | | End | | 198 | | Host | | 199 | +------+ | 200 | | 201 |Customer Premises Network | 202 | | 203 +---------------------------+ 205 Figure 1: Fixed-wired Scenario 207 The customer premises consists of a router with a Network Address 208 Translator with Port Address Translation (NAPT) and a DHCP server as 209 used in most Customer Premises Networks (CPN) and the Network 210 Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 211 protocols are terminated. The router in the home network (e.g., 212 broadband router, cable or DSL router) typically runs a NAPT and a 213 DHCP server. The NTE is a legacy device and in many cases cannot be 214 modified for the purpose of delivering location information to the 215 end host. The same is true of the device with the NAPT and DHCP 216 server. 218 It is possible for the NTE and the home router to physically be in 219 the same box, or for there to be no home router, or for the NTE and 220 end host to be in the same physical box (with no home router). An 221 example of this last case is where Ethernet service is delivered to 222 customers' homes, and the Ethernet NIC in their PC serves as the NTE. 224 Current Customer Premises Network (CPN) deployments generally fall 225 into one of the following classifications: 227 1. Single PC 229 1. with Ethernet network interface card (NIC) with Point-to- 230 Point Protocol Over Ethernet (PPPoE) or Dynamic Host 231 Configuration Protocol (DHCP) on PC; there may be a bridged 232 DSL or cable modem as NTE, or the Ethernet NIC might be the 233 NTE 235 2. with Universal Serial Bus (USB) based DSL access or a cable 236 modem access using Point-to-Point Protocol over ATM (PPPoA), 237 PPPoE, or DHCP on PC 239 Note that the device with NAPT and DHCP of Figure 1 is not 240 present in such a scenario. 242 2. One or more hosts with at least one router (DHCP Client or PPPoE, 243 DHCP server in router; VoIP can be soft client on PC, stand-alone 244 VoIP device, or Analog Terminal Adaptor (ATA) function embedded 245 in router) 247 1. combined router and NTE 249 2. separate router with NTE in bridged mode 251 3. separate router with NTE (NTE/router does PPPoE or DHCP to 252 WAN, router provides DHCP server for hosts in LAN; double 253 NAT) 255 The majority of fixed access broadband customers use a router. The 256 placement of the VoIP client is mentioned to describe what sorts of 257 hosts may need to be able to request location information. Soft 258 clients on PCs are frequently not launched until long after bootstrap 259 is complete, and are not able to control any options that may be 260 specified during bootstrap. They also cannot control whether a VPN 261 client is running on the end host. 263 3.2. Moving Network 265 One example of a moving network is a WiMAX fixed wireless scenario. 266 This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless 267 networks. In implementations intended to provide broadband service 268 to a home or other stationary location, the customer-side antenna / 269 NTE tends to be rather small and portable. The LAN-side output of 270 this device is an Ethernet jack, which can be used to feed a PC or a 271 router. The PC or router then uses DHCP or PPPoE to connect to the 272 access network, the same as for wired access networks. Access 273 providers who deploy this technology may use the same core network 274 (including network elements that terminate PPPoE and provide IP 275 addresses) for DSL, fiber to the premises (FTTP), and fixed wireless 276 customers. 278 Given that the customer antenna is portable and can be battery- 279 powered, it is possible for a user to connect a laptop to it and move 280 within the coverage area of a single base antenna. This coverage 281 area can be many square kilometers in size. In this case, the laptop 282 (and any SIP client running on it) would be completely unaware of 283 their mobility. Only the user and the network are aware of the 284 laptop's mobility. 286 Further examples of moving networks (where end devices may not be 287 aware that they are moving) can be found in busses, trains, and 288 airplanes. 290 Figure 2 shows an example topology for a moving network. 292 +--------------------------+ 293 | Wireless | 294 | Access Network Provider | 295 | | 296 | +----------+| 297 | +-------+ LIS || 298 | | | || 299 | +---+----+ +----------+| 300 | | Node | | 301 | | | | 302 | +---+----+ | 303 | | | 304 +------+-------------------+ 305 | Wireless Interface 306 | 307 +------+-------------------+ 308 | | Moving Network | 309 | +---+----+ | 310 | | NTE | +--------+ | 311 | | +---+ Host | | 312 | +-+-----++ | B | | 313 | | \ +--------+ | 314 | | \ | 315 |+---+----+ \ +---+----+ | 316 || Host | \ | Host | | 317 || A | \+ B | | 318 |+--------+ +--------+ | 319 +--------------------------+ 321 Figure 2: Moving Network 323 3.3. Wireless Access 325 Figure 3 shows a wireless access network where a moving end host 326 obtains location information or references to location information 327 from the LIS. The access equipment uses, in many cases, link layer 328 devices. Figure 3 represents a hotspot network found, for example, 329 in hotels, airports, and coffee shops. For editorial reasons we only 330 describe a single access point and do not depict how the LIS obtains 331 location information since this is very deployment specific. 333 +--------------------------+ 334 | Access Network Provider | 335 | | 336 | +----------+| 337 | +-------| LIS || 338 | | | || 339 | +--------+ +----------+| 340 | | Access | | 341 | | Point | | 342 | +--------+ | 343 | | | 344 +------+-------------------+ 345 | 346 +------+ 347 | End | 348 | Host | 349 +------+ 351 Figure 3: Wireless Access Scenario 353 4. Discovery of the Location Information Server 355 Note that this section lists mechanisms that were discussed in the 356 Geopriv Layer 7 Location Configuration Protocol design team. They 357 are included to show challenges in the problem space and are 358 listed for completeness reasons. They do not in any way mean that 359 there is consensus about any of the mechanisms or that the IETF 360 recommends any of the procedures described in this section. 362 When a Target wants to retrieve location information from the LIS it 363 first needs to discover it. Based on the problem statement of 364 determining the location of the Target, which is known best by 365 entities close to the Target itself, we assume that the LIS is 366 located in the local subnet or in access network. Several procedures 367 have been investigated that aim to discover the LIS in such an access 368 network. 370 DHCP-based Discovery: 372 In some environments the Dynamic Host Configuration Protocol 373 (DHCP) might be a good choice for discovering the fully qualified 374 domain name (FQDN) or the IP address of the LIS. In environments 375 where DHCP can be used it is also possible to use the already 376 defined location extensions. In environments with legacy devices, 377 such as the one shown in Section 3.1, a DHCP based discovery 378 solution may not be possible. 380 DNS-based Discovery: 382 Before a Domain Name System (DNS) lookup can be started it is 383 necessary to learn the domain name of the access network that runs 384 a LIS. Several ways to learn the domain name exist. For example, 385 the end host obtains its own public IP address, for example via 386 STUN [RFC3489], and performs a reverse DNS lookup (assuming the 387 data is provisioned into the DNS). Then, the DNS Service (SRV) 388 record or the DNS Naming Authority Pointer (NAPTR) record for that 389 domain is retrieved. A more detailed description of this approach 390 can be found in [I-D.thomson-geopriv-lis-discovery]. 392 Redirect Rule: 394 A redirect rule at a device in the access network could be used to 395 redirect the L7 LCP signalling messages (destined to a specific 396 port) to the LIS. The end host could then discover the LIS by 397 sending a packet with a specific (registered) port number to 398 almost any address (as long as the destination IP address does not 399 target a device in the local network). The packet would be 400 redirected to the respective LIS being configured. The same 401 procedure is used by captive portals whereby any HTTP traffic is 402 intercepted and redirected. 404 To some extend this approach is similar to packets that are marked 405 with a Router Alert option [RFC2113] and intercepted by entities 406 that understand the specific marking. In the above-mentioned 407 case, however, the marking is provided via a registered port 408 number instead of relying on a Router Alert option. 410 This solution approach would require a deep packet inspection 411 capability at an entity in the access providers networks that 412 scans for the occurrence of particular destination port numbers. 414 Multicast Query: 416 An end node could also discover a LIS by sending a DNS query to a 417 well-known address. An example of such a mechanism is multicast 418 DNS (see [RFC4795] and [I-D.cheshire-dnsext-multicastdns]). 419 Unfortunately, these mechanisms only work on the local link. 421 Anycast: 423 With this solution an anycast address is defined (for IPv4 and 424 IPv6) in the style of [RFC3068] that allows the endhost to route 425 discovery packets to the nearest LIS. Note that this procedure 426 would be used purely for discovery and thereby similar to local 427 Teredo server discovery approach outlined in Section 4.2 of 428 [I-D.nward-v6ops-teredo-server-selection]. 430 The LIS discovery procedure raises deployment and security issues. 431 The access network needs to be designed to prevent man-in-the-middle 432 adversaries from presenting themselves as a LIS to end hosts. When 433 an end host discovers a LIS, it needs to ensure (and be able to 434 ensure) that the discovered entity is indeed an authorized LIS. 436 5. Identifier for Location Determination 438 Note that this section lists mechanisms that were discussed in the 439 Geopriv Layer 7 Location Configuration Protocol design team. They 440 are included to show challenges in the problem space and are 441 listed for completeness reasons. They do not in any way mean that 442 there is consensus about any of the mechanisms or that the IETF 443 recommends any of the procedures described in this section. 445 The LIS returns location information to the end host when it receives 446 a request. Some form of identifier is therefore needed to allow the 447 LIS to retrieve the Target's current location (or a good 448 approximation of it) from a database. 450 The chosen identifier needs to have the following properties: 452 Ability for Target to learn or know the identifier: 454 The Target MUST know or MUST be able to learn the identifier 455 (explicitly or implicitly) in order to send it to the LIS. 456 Implicitly refers to the situation where a device along the path 457 between the end host and the LIS modifies the identifier, as it is 458 done by a NAT when an IP address based identifier is used. 460 Ability to use the identifier for location determination: 462 The LIS MUST be able to use the identifier (directly or 463 indirectly) for location determination. Indirectly refers to the 464 case where the LIS uses other identifiers internally for location 465 determination, in addition to the one provided by the Target. 467 Security properties of the identifier: 469 Misuse needs to be minimized whereby off-path adversary MUST NOT 470 be able to obtain location information of other Targets. A on- 471 path adversary in the same subnet SHOULD NOT be able to spoof the 472 identifier of another Target in the same subnet. 474 The following list discusses frequently mentioned identifiers and 475 their properties: 477 Media Access Control (MAC) Address: 479 The Target's MAC address is known to the end host, but not carried 480 over an IP hop and therefore not accessible to the LIS in most 481 deployment environments (unless carried in the L7 LCP itself). 483 Asynchronous Transfer Mode (ATM) Virtual Path Identifier(VPI)/Virtual 484 Circuit Identifier(VCI): 486 The VCI/VPI is generally only seen by the DSL modem. Almost all 487 routers in the United States use 1 of 2 VPI/VCI value pairs: 0/35 488 and 8/35. This VC is terminated at the digital subscriber line 489 access multiplexer (DSLAM), which uses a different VPI/VCI (per 490 end customer) to connect to the ATM switch. Only the network 491 provider is able to map VPI/VCI values through its network. With 492 the arrival of Very high rate Digital Subscriber Line (VDSL), ATM 493 will slowly be phased out in favor of Ethernet. 495 Ethernet Switch (Bridge)/Port Number: 497 This identifier is available only in certain networks, such as 498 enterprise networks, typically available via the IEEE 802.1AB 499 protocol [802.1AB] or proprietary protocols like the Cisco 500 Discovery Protocol (CDP) [CDP]. 502 Cell ID: 504 This identifier is available in cellular data networks and the 505 cell ID may not be visible to the end host. 507 Host Identifier: 509 The Host Identifier introduced by the Host Identity Protocol (HIP) 510 [I-D.ietf-hip-base] allows identification of a particular host. 511 Unfortunately, the network can only use this identifier for 512 location determination if the operator already stores a mapping of 513 host identities to location information. Furthermore, there is a 514 deployment problem since the host identities are not used in 515 todays networks. 517 Cryptographically Generated Address (CGA): 519 The concept of a Cryptographically Generated Address (CGA) was 520 introduced by [RFC3972]. The basic idea is to put the truncated 521 hash of a public key into the interface identifier part of an IPv6 522 address. In addition to the properties of an IP address it allows 523 a proof of ownership. Hence, a return routability check can be 524 omitted. It is only available for IPv6 addresses. 526 Network Access Identifiers: 528 A Network Access Identifier [RFC4282] is used during the network 529 access authentication procedure, for example in RADIUS [RFC2865] 530 and Diameter [RFC3588]. In DSL networks the user credentials are, 531 in many cases, only known by the home router and not configured at 532 the Target itself. To the network, the authenticated user 533 identity is only available if a network access authentication 534 procedure is executed. In case of roaming the user's identity 535 might not be available to the access network since security 536 protocols might offer user identity confidentiality and thereby 537 hiding the real identity of the user allowing the access network 538 to only see a pseudonym or a randomized string. 540 Unique Client Identifier 542 The Broadband Forum has defined that all devices that expect to be 543 managed by the TR-069 interface, see [TR069], have to be able to 544 generate an identifier that uniquely identifies the device. It 545 also has a requirement that routers that use DHCP to the WAN use 546 RFC 4361 [RFC4361] to provide the DHCP server with a unique client 547 identifier. This identifier is, however, not visible to the 548 Target when legacy NTE device are used. 550 IP Address: 552 The Target's IP address may be used for location determination. 553 This IP address is not visible to the LIS if the end host is 554 behind one or multiple NATs. This may not be a problem since the 555 location of a host that is located behind a NAT cannot be 556 determined by the access network. The LIS would in this case only 557 see the public IP address of the NAT binding allocated by the NAT, 558 which is the expected behavior. The property of the IP address 559 for a return routability check is attractive to return location 560 information only to the address that submitted the request. If an 561 adversary wants to learn the location of a Target (as identified 562 by a particular IP address) then it does not see the response 563 message (unless he is on the subnetwork or at a router along the 564 path towards the LIS). 566 On a shared medium an adversary could ask for location information 567 of another Target. The adversary would be able to see the 568 response message since it is sniffing on the shared medium unless 569 security mechanisms, such as link layer encryption, are in place. 570 With a network deployment as shown in Section 3.1 with multiple 571 hosts in the Customer Premises being behind a NAT the LIS is 572 unable to differentiate the individual end points. For WLAN 573 deployments as found in hotels, as shown in Section 3.3, it is 574 possible for an adversary to eavesdrop data traffic and 575 subsequently to spoof the IP address in a query to the LIS to 576 learn more detailed location information (e.g., specific room 577 numbers). Such an attack might, for example, compromise the 578 privacy of hotel guests. 580 6. Requirements 582 The following requirements and assumptions have been identified: 584 Requirement L7-1: Identifier Choice 586 The L7 LCP MUST be able to carry different identifiers or MUST 587 define an identifier that is mandatory to implement. Regarding 588 the latter aspect, such an identifier is only appropriate if it is 589 from the same realm as the one for which the location information 590 service maintains identifier to location mapping. 592 Requirement L7-2: Mobility Support 594 The L7 LCP MUST support a broad range of mobility from devices 595 that can only move between reboots, to devices that can change 596 attachment points with the impact that their IP address is 597 changed, to devices that do not change their IP address while 598 roaming, to devices that continuously move by being attached to 599 the same network attachment point. 601 Requirement L7-3: ASP and Access Network Provider Relationship 603 The design of the L7 LCP MUST NOT assume a business or trust 604 relationship between the Application Service Provider (ASP) and 605 the Access Network Provider. Requirements for resolving a 606 reference to location information are not discussed in this 607 document. 609 Requirement L7-4: Layer 2 and Layer 3 Provider Relationship 611 The design of the L7 LCP MUST assume that there is a trust and 612 business relationship between the L2 and the L3 provider. The L3 613 provider operates the LIS that the Target queries. It, in turn, 614 needs to obtain location information from the L2 provider since 615 this one is closest to the end host. If the L2 and L3 provider 616 for the same host are different entities, they cooperate for the 617 purposes needed to determine end system locations. 619 Requirement L7-5: Legacy Device Considerations 621 The design of the L7 LCP MUST consider legacy devices, such as 622 residential NAT devices and NTEs in a DSL environment, that cannot 623 be upgraded to support additional protocols, for example, to pass 624 additional information towards the Target. 626 Requirement L7-6: Virtual Private Network (VPN) Awareness 628 The design of the L7 LCP MUST assume that at least one end of a 629 VPN is aware of the VPN functionality. In an enterprise scenario, 630 the enterprise side will provide the LIS used by the client and 631 can thereby detect whether the LIS request was initiated through a 632 VPN tunnel. 634 Requirement L7-7: Network Access Authentication 636 The design of the L7 LCP MUST NOT assume prior network access 637 authentication. 639 Requirement L7-8: Network Topology Unawareness 641 The design of the L7 LCP MUST NOT assume end systems being aware 642 of the access network topology. End systems are, however, able to 643 determine their public IP address(es) via mechanisms, such as 644 Simple Traversal of User Datagram Protocol (UDP) Through Network 645 Address Translators (NATs) (STUN) [RFC3489] or Next Steps in 646 Signaling (NSIS) NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 647 [I-D.ietf-nsis-nslp-natfw] . 649 Requirement L7-9: Discovery Mechanism 651 The L7 LCP MUST define a mandatory-to-implement LIS discovery 652 mechanism. 654 Requirement L7-10: PIDF-LO Creation 656 When a LIS creates a Presence Information Data Format (PIDF) 657 Location Object (LO) [RFC4119] then it MUST put the 658 element into the element of the presence document (see 659 [RFC4479]). This ensures that the resulting PIDF-LO document, 660 which is subsequently distributed to other entities, conforms to 661 the rules outlined in [I-D.ietf-geopriv-pdif-lo-profile]. 663 7. Security Considerations 665 By using a Geolocation L7 Location Configuration Protocol, the client 666 expose themselves to a privacy risk whereby an unauthorized entity 667 receives location information. The provision of confidentiality 668 protected location to the requestor depends on the success of four 669 steps: 671 1. The client MUST have a means to discover a LIS. 673 2. The client MUST authenticate the discovered LIS. 675 3. The LIS MUST be able to determine location and return it to the 676 authorized entity. 678 4. The LIS MUST securely exchange messages without intermedaries 679 eavesdropping or tampering them. 681 This document contains various security related requirements 682 throughout the document addressing the above-mentioned steps. For a 683 broader security discussion of the overall geolocation privacy 684 architecture the reader is referred to [I-D.barnes-geopriv-lo-sec]. 686 8. IANA Considerations 688 This document does not require actions by IANA. 690 9. Contributors 692 This contribution is a joint effort of the Geopriv Layer 7 Location 693 Configuration Requirements Design Team of the IETF GEOPRIV Working 694 Group. The contributors include Henning Schulzrinne, Barbara Stark, 695 Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, 696 Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. 698 We would like to thank the GEOPRIV working group chairs, Andy Newton, 699 Randy Gellens and Allison Mankin, for creating the design team. 700 Furthermore, we would like thank Andy Newton for his support during 701 the design team mailing list, for setting up Jabber chat conferences 702 and for participating in the phone conference discussions. 704 The design team members can be reached at: 706 Marc Linsner: mlinsner@cisco.com 708 Rohan Mahy: rohan@ekabal.com 710 Andrew Newton: andy@hxr.us 712 Jon Peterson: jon.peterson@neustar.biz 714 Brian Rosen: br@brianrosen.net 716 Henning Schulzrinne: hgs@cs.columbia.edu 718 Barbara Stark: Barbara.Stark@bellsouth.com 720 Martin Thomson: Martin.Thomson@andrew.com 722 Hannes Tschofenig: Hannes.Tschofenig@nsn.com 724 James Winterbottom: James.Winterbottom@andrew.com 726 10. Acknowledgements 728 We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin 729 Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, 730 Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, 731 Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara 732 Stark, Michael Haberler, and Mary Barnes for their WGLC review 733 comments. 735 The authors would like to thank NENA for their work on [NENA] as it 736 helped to provide some of the initial thinking. 738 The authors would also like to thank Cullen Jennings for his feedback 739 as part of the IESG processing. Additionally, we would like to thank 740 Alexey Melnikov, Dan Romascanu, 742 11. References 744 11.1. Normative References 746 [I-D.ietf-ecrit-requirements] 747 Schulzrinne, H. and R. Marshall, "Requirements for 748 Emergency Context Resolution with Internet Technologies", 749 draft-ietf-ecrit-requirements-13 (work in progress), 750 March 2007. 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", RFC 2119, BCP 14, March 1997. 755 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 756 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 758 11.2. Informative References 760 [802.1AB] "IEEE 802.1AB-2005 IEEE Standard for Local and 761 Metropolitan Area Networks Station and Media Access 762 Control Connectivity Discovery", (PDF document), http:// 763 standards.ieee.org/getieee802/download/802.1AB-2005.pdf, 764 May 2005. 766 [CDP] "Cisco Discovery Protocol (CDP)", (HTML page), http:// 767 en.wikipedia.org/wiki/Cisco_Discovery_Protocol, July 2009. 769 [I-D.barnes-geopriv-lo-sec] 770 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 771 Tschofenig, H., and H. Schulzrinne, "An Architecture for 772 Location and Location Privacy in Internet Applications", 773 draft-barnes-geopriv-lo-sec-05 (work in progress), 774 March 2009. 776 [I-D.cheshire-dnsext-multicastdns] 777 Cheshire, S. and M. Krochmal, "Multicast DNS", 778 draft-cheshire-dnsext-multicastdns-07 (work in progress), 779 September 2008. 781 [I-D.ietf-geopriv-lbyr-requirements] 782 Marshall, R., "Requirements for a Location-by-Reference 783 Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work 784 in progress), February 2009. 786 [I-D.ietf-geopriv-pdif-lo-profile] 787 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 788 PIDF-LO Usage Clarification, Considerations and 789 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 790 (work in progress), November 2008. 792 [I-D.ietf-hip-base] 793 Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 794 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 795 progress), October 2007. 797 [I-D.ietf-nsis-nslp-natfw] 798 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 799 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 800 draft-ietf-nsis-nslp-natfw-20 (work in progress), 801 November 2008. 803 [I-D.nward-v6ops-teredo-server-selection] 804 Ward, N., "Teredo Server Selection", 805 draft-nward-v6ops-teredo-server-selection-00 (work in 806 progress), July 2007. 808 [I-D.thomson-geopriv-lis-discovery] 809 Thomson, M. and J. Winterbottom, "Discovering the Local 810 Location Information Server (LIS)", 811 draft-thomson-geopriv-lis-discovery-03 (work in progress), 812 September 2007. 814 [I-D.winterbottom-geopriv-lis2lis-req] 815 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 816 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 817 (work in progress), November 2007. 819 [NENA] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA 820 Recommended Method(s) for Location Determination to 821 Support IP-Based Emergency Services - Technical 822 Information Document (TID)", (PDF document), NENA 08-505, 823 December 2006. 825 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 826 February 1997. 828 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 829 "Remote Authentication Dial In User Service (RADIUS)", 830 RFC 2865, June 2000. 832 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 833 RFC 3068, June 2001. 835 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 836 "STUN - Simple Traversal of User Datagram Protocol (UDP) 837 Through Network Address Translators (NATs)", RFC 3489, 838 March 2003. 840 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 841 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 843 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 844 RFC 3972, March 2005. 846 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 847 Format", RFC 4119, December 2005. 849 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 850 Network Access Identifier", RFC 4282, December 2005. 852 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 853 Identifiers for Dynamic Host Configuration Protocol 854 Version Four (DHCPv4)", RFC 4361, February 2006. 856 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 857 July 2006. 859 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 860 Multicast Name Resolution (LLMNR)", RFC 4795, 861 January 2007. 863 [TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue 864 1 Amendment 2", (PDF document), http:// 865 www.broadband-forum.org/technical/download/ 866 TR-069Amendment2.pdf, December 2007. 868 Authors' Addresses 870 Hannes Tschofenig 871 Nokia Siemens Networks 872 Linnoitustie 6 873 Espoo 02600 874 Finland 876 Phone: +358 (50) 4871445 877 Email: Hannes.Tschofenig@gmx.net 878 URI: http://www.tschofenig.priv.at 880 Henning Schulzrinne 881 Columbia University 882 Department of Computer Science 883 450 Computer Science Building 884 New York, NY 10027 885 US 887 Phone: +1 212 939 7004 888 Email: hgs+ecrit@cs.columbia.edu 889 URI: http://www.cs.columbia.edu