idnits 2.17.1 draft-ietf-geopriv-l7-lcp-ps-08.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 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 833. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 839. 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 (June 29, 2008) is 5779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-02 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '6') (Obsoleted by RFC 5389) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-06 -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. '11') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. '15') (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '17') (Obsoleted by RFC 6733) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-18 == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-11 == Outdated reference: A later version (-05) exists of draft-barnes-geopriv-lo-sec-02 Summary: 1 error (**), 0 flaws (~~), 7 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 Nokia Siemens Networks 4 Intended status: Informational H. Schulzrinne 5 Expires: December 31, 2008 Columbia University 6 June 29, 2008 8 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and 9 Requirements 10 draft-ietf-geopriv-l7-lcp-ps-08.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 December 31, 2008. 37 Abstract 39 This document provides a problem statement, lists requirements and 40 captures design aspects for a Geopriv Layer 7 Location Configuration 41 Protocol L7 (LCP). This protocol aims to allow an end host to obtain 42 location information, by value or by reference, from a Location 43 Information Server (LIS) that is located in the access network. The 44 obtained location information can then be used for a variety of 45 different protocols and purposes. For example, it can be used as 46 input to the Location-to-Service Translation Protocol (LoST) or to 47 convey location within SIP to other entities. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5 55 3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7 56 3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9 57 4. Discovery of the Location Information Server . . . . . . . . . 11 58 5. Identifier for Location Determination . . . . . . . . . . . . 13 59 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 62 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 65 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 66 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 68 Intellectual Property and Copyright Statements . . . . . . . . . . 25 70 1. Introduction 72 This document provides a problem statement, lists requirements and 73 captures design aspects for a Geopriv Layer 7 Location Configuration 74 Protocol L7 (LCP). The protocol has two purposes: 76 o It is used to obtain location information (referred as "Location 77 by Value" or LbyV) from a dedicated node, called the Location 78 Information Server (LIS). 80 o It enables the Target to obtain a reference to location 81 information (referred as "Location by Reference" or LbyR). This 82 reference can take the form of a subscription URI, such as a SIP 83 presence URI, a HTTP/HTTPS URI, or another URI. The requirements 84 related to the task of obtaining a LbyR are described in a 85 separate document, see [4]. 87 The need for these two functions can be derived from the scenarios 88 presented in Section 3. 90 For this document we assume that the GEOPRIV Layer 7 LCP runs between 91 the end host (i.e., the Target in [1] terminology) and the LIS. 93 This document is structured as follows. Section 4 discusses the 94 challenge of discovering the LIS in the access network. Section 5 95 compares different types of identifiers that can be used to retrieve 96 location information. A list of requirements for the L7 LCP can be 97 found in Section 6. 99 This document does not describe how the access network provider 100 determines the location of the end host since this is largely a 101 matter of the capabilities of specific link layer technologies or 102 certain deployment environments. 104 2. Terminology 106 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 108 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], 109 with the qualification that unless otherwise stated these words apply 110 to the design of the GEOPRIV Layer 7 Location Configuration Protocol. 112 The term Location Information Server (LIS) refers to an entity 113 capable of determining the location of a Target and of providing that 114 location information, a reference to it, or both via the Location 115 Configuration Protocol (LCP) to the requesting party. In most cases 116 the requesting party is the Target itself but it may also be an 117 authorized entity that acts on behalf of it, such as a SIP proxy or 118 another LIS. 120 This document also uses terminology from [1] (such as Target) and [3] 121 (such as Internet Access Provider (IAP), Internet Service Provider 122 (ISP), and Application Service Provider (ASP)). 124 With the term "Access Network Provider" we refer to the Internet 125 Access Provider (IAP) and the Internet Service Provider (ISP) without 126 further distinguishing these two entities as it is not relevant for 127 the purpose of this document. An additional requirements document on 128 LIS-to-LIS [5] shows scenario where the separation between IAP and 129 ISP is important. 131 3. Scenarios 133 This section describes a few network scenarios where the L7 LCP may 134 be used. Note that this section does not aim to exhaustively list 135 all possible deployment environments. Instead we focus on the 136 following environments: 138 o DSL/Cable networks, WiMax-like fixed access 140 o Airport, City, Campus Wireless Networks, such as 802.11a/b/g, 141 802.16e/Wimax 143 o 3G networks 145 o Enterprise networks 147 We illustrate a few examples below. 149 3.1. Fixed Wired Environment 151 Figure 1 shows a DSL network scenario with the Access Network 152 Provider and the customer premises. The Access Network Provider 153 operates link and network layer devices (represented as Node) and the 154 LIS. 156 +---------------------------+ 157 | | 158 | Access Network Provider | 159 | | 160 | +--------+ | 161 | | Node | | 162 | +--------+ +----------+ | 163 | | | | LIS | | 164 | | +---| | | 165 | | +----------+ | 166 | | | 167 +-------+-------------------+ 168 | Wired Network 169 <----------------> Access Network Provider demarc 170 | 171 +-------+-------------------+ 172 | | | 173 | +-------------+ | 174 | | NTE | | 175 | +-------------+ | 176 | | | 177 | | | 178 | +--------------+ | 179 | | Device with | Home | 180 | | NAPT and | Router | 181 | | DHCP server | | 182 | +--------------+ | 183 | | | 184 | | | 185 | +------+ | 186 | | End | | 187 | | Host | | 188 | +------+ | 189 | | 190 |Customer Premises Network | 191 | | 192 +---------------------------+ 194 Figure 1: Fixed-wired Scenario 196 The customer premises consists of a router with a Network Address 197 Translator with Port Address Translation (NAPT) and a DHCP server as 198 used in most Customer Premises Networks (CPN) and the Network 199 Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 200 protocols are terminated. The router in the home network (e.g., 201 broadband router, cable or DSL router) typically runs a NAPT and a 202 DHCP server. The NTE is a legacy device and in many cases cannot be 203 modified for the purpose of delivering location information to the 204 end host. The same is true of the device with the NAPT and DHCP 205 server. 207 It is possible for the NTE and the home router to physically be in 208 the same box, or for there to be no home router, or for the NTE and 209 end host to be in the same physical box (with no home router). An 210 example of this last case is where Ethernet service is delivered to 211 customers' homes, and the Ethernet NIC in their PC serves as the NTE. 213 Current Customer Premises Network (CPN) deployments generally fall 214 into one of the following classifications: 216 1. Single PC 218 1. with Ethernet NIC (PPPoE or DHCP on PC); there may be a 219 bridged DSL or cable modem as NTE, or the Ethernet NIC might 220 be the NTE 222 2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC] 224 Note that the device with NAPT and DHCP of Figure 1 is not 225 present in such a scenario. 227 2. One or more hosts with at least one router (DHCP Client or PPPoE, 228 DHCP server in router; VoIP can be soft client on PC, stand-alone 229 VoIP device, or Analog Terminal Adaptor (ATA) function embedded 230 in router) 232 1. combined router and NTE 234 2. separate router with NTE in bridged mode 236 3. separate router with NTE (NTE/router does PPPoE or DHCP to 237 WAN, router provides DHCP server for hosts in LAN; double 238 NAT) 240 The majority of fixed access broadband customers use a router. The 241 placement of the VoIP client is mentioned to describe what sorts of 242 hosts may need to be able to request location information. Soft 243 clients on PCs are frequently not launched until long after bootstrap 244 is complete, and are not able to control any options that may be 245 specified during bootstrap. They also cannot control whether a VPN 246 client is running on the end host. 248 3.2. Moving Network 250 One example of a moving network is a WiMAX fixed wireless scenario. 251 This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless 252 networks. In implementations intended to provide broadband service 253 to a home or other stationary location, the customer-side antenna / 254 NTE tends to be rather small and portable. The LAN-side output of 255 this device is an Ethernet jack, which can be used to feed a PC or a 256 router. The PC or router then uses DHCP or PPPoE to connect to the 257 access network, the same as for wired access networks. Access 258 providers who deploy this technology may use the same core network 259 (including network elements that terminate PPPoE and provide IP 260 addresses) for DSL, fiber to the premises (FTTP), and fixed wireless 261 customers. 263 Given that the customer antenna is portable and can be battery- 264 powered, it is possible for a user to connect a laptop to it and move 265 within the coverage area of a single base antenna. This coverage 266 area can be many square kilometers in size. In this case, the laptop 267 (and any SIP client running on it) would be completely unaware of 268 their mobility. Only the user and the network are aware of the 269 laptop's mobility. 271 Further examples of moving networks (where end devices may not be 272 aware that they are moving) can be found in busses, trains, and 273 airplanes. 275 Figure 2 shows an example topology for a moving network. 277 +--------------------------+ 278 | Wireless | 279 | Access Network Provider | 280 | | 281 | +----------+| 282 | +-------+ LIS || 283 | | | || 284 | +---+----+ +----------+| 285 | | Node | | 286 | | | | 287 | +---+----+ | 288 | | | 289 +------+-------------------+ 290 | Wireless Interface 291 | 292 +------+-------------------+ 293 | | Moving Network | 294 | +---+----+ | 295 | | NTE | +--------+ | 296 | | +---+ Host | | 297 | +-+-----++ | B | | 298 | | \ +--------+ | 299 | | \ | 300 |+---+----+ \ +---+----+ | 301 || Host | \ | Host | | 302 || A | \+ B | | 303 |+--------+ +--------+ | 304 +--------------------------+ 306 Figure 2: Moving Network 308 3.3. Wireless Access 310 Figure 3 shows a wireless access network where a moving end host 311 obtains location information or references to location information 312 from the LIS. The access equipment uses, in many cases, link layer 313 devices. Figure 3 represents a hotspot network found, for example, 314 in hotels, airports, and coffee shops. For editorial reasons we only 315 describe a single access point and do not depict how the LIS obtains 316 location information since this is very deployment specific. 318 +--------------------------+ 319 | Access Network Provider | 320 | | 321 | +----------+| 322 | +-------| LIS || 323 | | | || 324 | +--------+ +----------+| 325 | | Access | | 326 | | Point | | 327 | +--------+ | 328 | | | 329 +------+-------------------+ 330 | 331 +------+ 332 | End | 333 | Host | 334 +------+ 336 Figure 3: Wireless Access Scenario 338 4. Discovery of the Location Information Server 340 When a Target wants to retrieve location information from the LIS it 341 first needs to discover it. Based on the problem statement of 342 determining the location of the Target, which is known best by 343 entities close to the Target itself, we assume that the LIS is 344 located in the local subnet or in access network. Several procedures 345 have been investigated that aim to discover the LIS in such an access 346 network. 348 DHCP-based Discovery: 350 In some environments the Dynamic Host Configuration Protocol 351 (DHCP) might be a good choice for discovering the FQDN or the IP 352 address of the LIS. In environments where DHCP can be used it is 353 also possible to use the already defined location extensions. In 354 environments with legacy devices, such as the one shown in 355 Section 3.1, a DHCP based discovery solution may not be possible. 357 DNS-based Discovery: 359 Before a DNS lookup can be started it is necessary to learn the 360 domain name of the access network that runs a LIS. Several ways 361 to learn the domain name exist. For example, the end host obtains 362 its own public IP address, for example via STUN [6], and performs 363 a reverse DNS lookup (assuming the data is provisioned into the 364 DNS). Then, the SRV or NAPTR record for that domain is retrieved. 365 A more detailed description of this approach can be found in [7]. 367 Redirect Rule: 369 A redirect rule at a device in the access network, for example at 370 the AAA client, could be used to redirect the L7 LCP signalling 371 messages (destined to a specific port) to the LIS. The end host 372 could then discover the LIS by sending a packet with a specific 373 (registered) port number to almost any address (as long as the 374 destination IP address does not target a device in the local 375 network). The packet would be redirected to the respective LIS 376 being configured. The same procedure is used by captive portals 377 whereby any HTTP traffic is intercepted and redirected. 379 To some extend this approach is similar to packets that are marked 380 with a Router Alert option [8] and intercepted by entities that 381 understand the specific marking. In the above-mentioned case, 382 however, the marking is provided via a registered port number 383 instead of relying on a Router Alert option. 385 Multicast Query: 387 An end node could also discover a LIS by sending a DNS query to a 388 well-known address. An example of such a mechanism is multicast 389 DNS (see [9] and [10]). Unfortunately, these mechanisms only work 390 on the local link. 392 Anycast: 394 With this solution an anycast address is defined (for IPv4 and 395 IPv6) in the style of [11] that allows the endhost to route 396 discovery packets to the nearest LIS. Note that this procedure 397 would be used purely for discovery and thereby similar to local 398 Teredo server discovery approach outlined in Section 4.2 of [12]. 400 The LIS discovery procedure raises deployment and security issues. 401 The access network needs to be designed to prevent man-in-the-middle 402 adversaries from presenting themselves as a LIS to end hosts. When 403 an end host discovers a LIS, it needs to ensure (and be able to 404 ensure) that the discovered entity is indeed an authorized LIS. 406 5. Identifier for Location Determination 408 The LIS returns location information to the end host when it receives 409 a request. Some form of identifier is therefore needed to allow the 410 LIS to retrieve the Target's current location (or a good 411 approximation of it) from a database. 413 The chosen identifier needs to have the following properties: 415 Ability for Target to learn or know the identifier: 417 The Target MUST know or MUST be able to learn the identifier 418 (explicitly or implicitly) in order to send it to the LIS. 419 Implicitly refers to the situation where a device along the path 420 between the end host and the LIS modifies the identifier, as it is 421 done by a NAT when an IP address based identifier is used. 423 Ability to use the identifier for location determination: 425 The LIS MUST be able to use the identifier (directly or 426 indirectly) for location determination. Indirectly refers to the 427 case where the LIS uses other identifiers internally for location 428 determination, in addition to the one provided by the Target. 430 Security properties of the identifier: 432 Misuse needs to be minimized whereby off-path adversary MUST NOT 433 be able to obtain location information of other Targets. A on- 434 path adversary in the same subnet SHOULD NOT be able to spoof the 435 identifier of another Target in the same subnet. 437 The following list discusses frequently mentioned identifiers and 438 their properties: 440 Host MAC Address: 442 The Target's MAC address is known to the end host, but not carried 443 over an IP hop and therefore not accessible to the LIS in most 444 deployment environments (unless carried in the L7 LCP itself). 446 ATM VCI/VPI: 448 The VPI/VCI is generally only seen by the DSL modem. Almost all 449 routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35. 450 This VC is terminated at the DSLAM, which uses a different VPI/VCI 451 (per end customer) to connect to the ATM switch. Only the network 452 provider is able to map VPI/VCI values through its network. With 453 the arrival of VDSL, ATM will slowly be phased out in favor of 454 Ethernet. 456 Switch/Port Number: 458 This identifier is available only in certain networks, such as 459 enterprise networks, typically available via proprietary protocols 460 like CDP or, in the future, 802.1ab. 462 Cell ID: 464 This identifier is available in cellular data networks and the 465 cell ID may not be visible to the end host. 467 Host Identifier: 469 The Host Identifier introduced by the Host Identity Protocol [13] 470 allows identification of a particular host. Unfortunately, the 471 network can only use this identifier for location determination if 472 the operator already stores a mapping of host identities to 473 location information. Furthermore, there is a deployment problem 474 since the host identities are not used in todays networks. 476 Cryptographically Generated Address (CGA): 478 The concept of a Cryptographically Generated Address (CGA) was 479 introduced by [14]. The basic idea is to put the truncated hash 480 of a public key into the interface identifier part of an IPv6 481 address. In addition to the properties of an IP address it allows 482 a proof of ownership. Hence, a return routability check can be 483 omitted. It is only available for IPv6 addresses. 485 Network Access Identifiers: 487 A Network Access Identifier [15] is used during the network access 488 authentication procedure, for example in RADIUS [16] and Diameter 489 [17]. In DSL networks the user credentials are, in many cases, 490 only known by the home router and not configured at the Target 491 itself. To the network, the authenticated user identity is only 492 available if a network access authentication procedure is 493 executed. In case of roaming the user's identity might not be 494 available to the access network since security protocols might 495 offer user identity confidentiality and thereby hiding the real 496 identity of the user allowing the access network to only see a 497 pseudonym or a randomized string. 499 Unique Client Identifier 501 The DSL Forum has defined that all devices that expect to be 502 managed by the TR-069 interface be able to generate an identifier 503 as described in Section 3.4.4 of the TR-069v2 DSL Forum document. 504 It also has a requirement that routers that use DHCP to the WAN 505 use RFC 4361 [18] to provide the DHCP server with a unique client 506 identifier. This identifier is, however, not visible to the 507 Target when legacy NTE device are used. 509 IP Address: 511 The Target's IP address may be used for location determination. 512 This IP address is not visible to the LIS if the end host is 513 behind one or multiple NATs. This may not be a problem since the 514 location of a host that is located behind a NAT cannot be 515 determined by the access network. The LIS would in this case only 516 see the public IP address of the NAT binding allocated by the NAT, 517 which is the expected behavior. The property of the IP address 518 for a return routability check is attractive to return location 519 information only to the address that submitted the request. If an 520 adversary wants to learn the location of a Target (as identified 521 by a particular IP address) then it does not see the response 522 message (unless he is on the subnetwork or at a router along the 523 path towards the LIS). 525 On a shared medium an adversary could ask for location information 526 of another Target. The adversary would be able to see the 527 response message since it is sniffing on the shared medium unless 528 security mechanisms, such as link layer encryption, are in place. 529 With a network deployment as shown in Section 3.1 with multiple 530 hosts in the Customer Premises being behind a NAT the LIS is 531 unable to differentiate the individual end points. For WLAN 532 deployments as found in hotels, as shown in Section 3.3, it is 533 possible for an adversary to eavesdrop data traffic and 534 subsequently to spoof the IP address in a query to the LIS to 535 learn more detailed location information (e.g., specific room 536 numbers). Such an attack might, for example, compromise the 537 privacy of hotel guests. 539 6. Requirements 541 The following requirements and assumptions have been identified: 543 Requirement L7-1: Identifier Choice 545 The L7 LCP MUST be able to carry different identifiers or MUST 546 define an identifier that is mandatory to implement. Regarding 547 the latter aspect, such an identifier is only appropriate if it is 548 from the same realm as the one for which the location information 549 service maintains identifier to location mapping. 551 Requirement L7-2: Mobility Support 553 The L7 LCP MUST support a broad range of mobility from devices 554 that can only move between reboots, to devices that can change 555 attachment points with the impact that their IP address is 556 changed, to devices that do not change their IP address while 557 roaming, to devices that continuously move by being attached to 558 the same network attachment point. 560 Requirement L7-3: ASP and Access Network Provider Relationship 562 The design of the L7 LCP MUST NOT assume a business or trust 563 relationship between the Application Service Provider (ASP) and 564 the Access Network Provider. Requirements for resolving a 565 reference to location information are not discussed in this 566 document. 568 Requirement L7-4: Layer 2 and Layer 3 Provider Relationship 570 The design of the L7 LCP MUST assume that there is a trust and 571 business relationship between the L2 and the L3 provider. The L3 572 provider operates the LIS that the Target queries. It, in turn, 573 needs to obtain location information from the L2 provider since 574 this one is closest to the end host. If the L2 and L3 provider 575 for the same host are different entities, they cooperate for the 576 purposes needed to determine end system locations. 578 Requirement L7-5: Legacy Device Considerations 580 The design of the L7 LCP MUST consider legacy devices, such as 581 residential NAT devices and NTEs in a DSL environment, that cannot 582 be upgraded to support additional protocols, for example, to pass 583 additional information towards the Target. 585 Requirement L7-6: VPN Awareness 587 The design of the L7 LCP MUST assume that at least one end of a 588 VPN is aware of the VPN functionality. In an enterprise scenario, 589 the enterprise side will provide the LIS used by the client and 590 can thereby detect whether the LIS request was initiated through a 591 VPN tunnel. 593 Requirement L7-7: Network Access Authentication 595 The design of the L7 LCP MUST NOT assume prior network access 596 authentication. 598 Requirement L7-8: Network Topology Unawareness 600 The design of the L7 LCP MUST NOT assume end systems being aware 601 of the access network topology. End systems are, however, able to 602 determine their public IP address(es) via mechanisms, such as STUN 603 [6] or NSIS NATFW NSLP [19] . 605 Requirement L7-9: Discovery Mechanism 607 The L7 LCP MUST define a mandatory-to-implement LIS discovery 608 mechanism. 610 Requirement L7-10: PIDF-LO Creation 612 When a LIS creates a PIDF-LO [20] then it MUST put the 613 element into the element of the presence document (see 614 [21]). This ensures that the resulting PIDF-LO document, which is 615 subsequently distributed to other entities, conforms to the rules 616 outlined in [22]. 618 7. Security Considerations 620 This document contains security related requirements. A discussion 621 about security aspects of the HELD protocol when used in the GEOPRIV 622 architecture when applied to certain usage environments, such as 623 emergency services, can be found in [23]. 625 8. IANA Considerations 627 This document does not require actions by IANA. 629 9. Contributors 631 This contribution is a joint effort of the GEOPRIV Layer 7 Location 632 Configuration Requirements Design Team of the IETF GEOPRIV Working 633 Group. The contributors include Henning Schulzrinne, Barbara Stark, 634 Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, 635 Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. 637 We would like to thank the GEOPRIV working group chairs, Andy Newton, 638 Randy Gellens and Allison Mankin, for creating the design team. 640 The design team members can be reached at: 642 Marc Linsner: mlinsner@cisco.com 644 Rohan Mahy: rohan@ekabal.com 646 Andrew Newton: andy@hxr.us 648 Jon Peterson: jon.peterson@neustar.biz 650 Brian Rosen: br@brianrosen.net 652 Henning Schulzrinne: hgs@cs.columbia.edu 654 Barbara Stark: Barbara.Stark@bellsouth.com 656 Martin Thomson: Martin.Thomson@andrew.com 658 Hannes Tschofenig: Hannes.Tschofenig@nsn.com 660 James Winterbottom: James.Winterbottom@andrew.com 662 10. Acknowledgements 664 We would like to thank the IETF GEOPRIV working group chairs, Andy 665 Newton, Allison Mankin and Randall Gellens, for creating this design 666 team. Furthermore, we would like thank Andy Newton for his support 667 during the design team mailing list, for setting up Jabber chat 668 conferences and for participating in the phone conference 669 discussions. 671 We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin 672 Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, 673 Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, 674 Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara 675 Stark, Michael Haberler, and Mary Barnes for their WGLC review 676 comments. 678 The authors would like to thank NENA for their work on [24] as it 679 helped to provide some of the initial thinking. 681 11. References 683 11.1. Normative References 685 [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 686 Polk, "Geopriv Requirements", RFC 3693, February 2004. 688 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 689 Levels", RFC 2119, BCP 14, March 1997. 691 [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 692 Context Resolution with Internet Technologies", 693 draft-ietf-ecrit-requirements-13 (work in progress), 694 March 2007. 696 11.2. Informative References 698 [4] Marshall, R., "Requirements for a Location-by-Reference 699 Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work in 700 progress), February 2008. 702 [5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 703 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 (work 704 in progress), November 2007. 706 [6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 707 - Simple Traversal of User Datagram Protocol (UDP) Through 708 Network Address Translators (NATs)", RFC 3489, March 2003. 710 [7] Thomson, M. and J. Winterbottom, "Discovering the Local 711 Location Information Server (LIS)", 712 draft-thomson-geopriv-lis-discovery-03 (work in progress), 713 September 2007. 715 [8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 717 [9] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast 718 Name Resolution (LLMNR)", RFC 4795, January 2007. 720 [10] Cheshire, S. and M. Krochmal, "Multicast DNS", 721 draft-cheshire-dnsext-multicastdns-06 (work in progress), 722 August 2006. 724 [11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 725 RFC 3068, June 2001. 727 [12] Ward, N., "Teredo Server Selection", 728 draft-nward-v6ops-teredo-server-selection-00 (work in 729 progress), July 2007. 731 [13] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 732 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 733 progress), October 2007. 735 [14] Aura, T., "Cryptographically Generated Addresses (CGA)", 736 RFC 3972, March 2005. 738 [15] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 739 Access Identifier", RFC 4282, December 2005. 741 [16] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 742 Authentication Dial In User Service (RADIUS)", RFC 2865, 743 June 2000. 745 [17] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 746 "Diameter Base Protocol", RFC 3588, September 2003. 748 [18] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers 749 for Dynamic Host Configuration Protocol Version Four (DHCPv4)", 750 RFC 4361, February 2006. 752 [19] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/ 753 Firewall NSIS Signaling Layer Protocol (NSLP)", 754 draft-ietf-nsis-nslp-natfw-18 (work in progress), 755 February 2008. 757 [20] Peterson, J., "A Presence-based GEOPRIV Location Object 758 Format", RFC 4119, December 2005. 760 [21] Rosenberg, J., "A Data Model for Presence", RFC 4479, 761 July 2006. 763 [22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 764 PIDF-LO Usage Clarification, Considerations and 765 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work 766 in progress), February 2008. 768 [23] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne, 769 "Security Requirements for the Geopriv Location System", 770 draft-barnes-geopriv-lo-sec-02 (work in progress), 771 February 2008. 773 [24] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA 774 Recommended Method(s) for Location Determination to Support IP- 775 Based Emergency Services - Technical Information Document 776 (TID)", PDF NENA 08-505, December 2006. 778 Authors' Addresses 780 Hannes Tschofenig 781 Nokia Siemens Networks 782 Linnoitustie 6 783 Espoo 02600 784 Finland 786 Phone: +358 (50) 4871445 787 Email: Hannes.Tschofenig@gmx.net 788 URI: http://www.tschofenig.priv.at 790 Henning Schulzrinne 791 Columbia University 792 Department of Computer Science 793 450 Computer Science Building 794 New York, NY 10027 795 US 797 Phone: +1 212 939 7004 798 Email: hgs+ecrit@cs.columbia.edu 799 URI: http://www.cs.columbia.edu 801 Full Copyright Statement 803 Copyright (C) The IETF Trust (2008). 805 This document is subject to the rights, licenses and restrictions 806 contained in BCP 78, and except as set forth therein, the authors 807 retain all their rights. 809 This document and the information contained herein are provided on an 810 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 811 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 812 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 813 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 814 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 815 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 817 Intellectual Property 819 The IETF takes no position regarding the validity or scope of any 820 Intellectual Property Rights or other rights that might be claimed to 821 pertain to the implementation or use of the technology described in 822 this document or the extent to which any license under such rights 823 might or might not be available; nor does it represent that it has 824 made any independent effort to identify any such rights. Information 825 on the procedures with respect to rights in RFC documents can be 826 found in BCP 78 and BCP 79. 828 Copies of IPR disclosures made to the IETF Secretariat and any 829 assurances of licenses to be made available, or the result of an 830 attempt made to obtain a general license or permission for the use of 831 such proprietary rights by implementers or users of this 832 specification can be obtained from the IETF on-line IPR repository at 833 http://www.ietf.org/ipr. 835 The IETF invites any interested party to bring to its attention any 836 copyrights, patents or patent applications, or other proprietary 837 rights that may cover technology that may be required to implement 838 this standard. Please address the information to the IETF at 839 ietf-ipr@ietf.org.