idnits 2.17.1 draft-ietf-geopriv-l7-lcp-ps-06.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 807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 831. 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 (November 19, 2007) is 6000 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-01 -- 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-15 == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-10 == Outdated reference: A later version (-05) exists of draft-barnes-geopriv-lo-sec-00 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: May 22, 2008 Columbia University 6 November 19, 2007 8 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and 9 Requirements 10 draft-ietf-geopriv-l7-lcp-ps-06.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 May 22, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document provides a problem statement, lists requirements and 44 captures design aspects for a Geopriv Layer 7 Location Configuration 45 Protocol L7 (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. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 66 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 69 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 70 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 72 Intellectual Property and Copyright Statements . . . . . . . . . . 25 74 1. Introduction 76 This document provides a problem statement, lists requirements and 77 captures design aspects for a Geopriv Layer 7 Location Configuration 78 Protocol L7 (LCP). The protocol has two purposes: 80 o It is used to obtain location information (referred as "Location 81 by Value" or LbyV) from a dedicated node, called the Location 82 Information Server (LIS). 84 o It enables the Target to obtain a reference to location 85 information (referred as "Location by Reference" or LbyR). This 86 reference can take the form of a subscription URI, such as a SIP 87 presence URI, a HTTP/HTTPS URI, or another URI. The requirements 88 related to the task of obtaining a LbyR are described in a 89 separate document, see [4]. 91 The need for these two functions can be derived from the scenarios 92 presented in Section 3. 94 For this document we assume that the GEOPRIV Layer 7 LCP runs between 95 the end host (i.e., the Target in [1] terminology) and the LIS. 97 This document is structured as follows. Section 4 discusses the 98 challenge of discovering the LIS in the access network. Section 5 99 compares different types of identifiers that can be used to retrieve 100 location information. A list of requirements for the L7 LCP can be 101 found in Section 6. 103 This document does not describe how the access network provider 104 determines the location of the end host since this is largely a 105 matter of the capabilities of specific link layer technologies or 106 certain deployment environments. 108 2. Terminology 110 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 111 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 112 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], 113 with the qualification that unless otherwise stated these words apply 114 to the design of the GEOPRIV Layer 7 Location Configuration Protocol. 116 The term Location Information Server (LIS) refers to an entity 117 capable of determining the location of a Target and of providing that 118 location information, a reference to it, or both via the Location 119 Configuration Protocol (LCP) to the requesting party. In most cases 120 the requesting party is the Target itself but it may also be an 121 authorized entity that acts on behalf of it, such as a SIP proxy or 122 another LIS. 124 This document also uses terminology from [1] (such as Target) and [3] 125 (such as Internet Access Provider (IAP), Internet Service Provider 126 (ISP), and Application Service Provider (ASP)). 128 With the term "Access Network Provider" we refer to the Internet 129 Access Provider (IAP) and the Internet Service Provider (ISP) without 130 further distinguishing these two entities as it is not relevant for 131 the purpose of this document. An additional requirements document on 132 LIS-to-LIS [5] shows scenario where the separation between IAP and 133 ISP is important. 135 3. Scenarios 137 This section describes a few network scenarios where the L7 LCP may 138 be used. Note that this section does not aim to exhaustively list 139 all possible deployment environments. Instead we focus on the 140 following environments: 142 o DSL/Cable networks, WiMax-like fixed access 144 o Airport, City, Campus Wireless Networks, such as 802.11a/b/g, 145 802.16e/Wimax 147 o 3G networks 149 o Enterprise networks 151 We illustrate a few examples below. 153 3.1. Fixed Wired Environment 155 Figure 1 shows a DSL network scenario with the Access Network 156 Provider and the customer premises. The Access Network Provider 157 operates link and network layer devices (represented as Node) and the 158 LIS. 160 +---------------------------+ 161 | | 162 | Access Network Provider | 163 | | 164 | +--------+ | 165 | | Node | | 166 | +--------+ +----------+ | 167 | | | | LIS | | 168 | | +---| | | 169 | | +----------+ | 170 | | | 171 +-------+-------------------+ 172 | Wired Network 173 <----------------> Access Network Provider demarc 174 | 175 +-------+-------------------+ 176 | | | 177 | +-------------+ | 178 | | NTE | | 179 | +-------------+ | 180 | | | 181 | | | 182 | +--------------+ | 183 | | Device with | Home | 184 | | NAPT and | Router | 185 | | DHCP server | | 186 | +--------------+ | 187 | | | 188 | | | 189 | +------+ | 190 | | End | | 191 | | Host | | 192 | +------+ | 193 | | 194 |Customer Premises Network | 195 | | 196 +---------------------------+ 198 Figure 1: DSL Scenario 200 The customer premises consists of a router with a Network Address 201 Translator with Port Address Translation (NAPT) and a DHCP server as 202 used in most Customer Premises Networks (CPN) and the Network 203 Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 204 protocols are terminated. The router in the home network (e.g., 205 broadband router, cable or DSL router) typically runs a NAPT and a 206 DHCP server. The NTE is a legacy device and in many cases cannot be 207 modified for the purpose of delivering location information to the 208 end host. The same is true of the device with the NAPT and DHCP 209 server. 211 It is possible for the NTE and the home router to physically be in 212 the same box, or for there to be no home router, or for the NTE and 213 end host to be in the same physical box (with no home router). An 214 example of this last case is where Ethernet service is delivered to 215 customers' homes, and the Ethernet NIC in their PC serves as the NTE. 217 Current Customer Premises Network (CPN) deployments frequently show 218 the following characteristics: 220 1. CPE = Single PC 222 1. with Ethernet NIC (PPPoE or DHCP on PC); there may be a 223 bridged DSL or cable modem as NTE, or the Ethernet NIC might 224 be the NTE 226 2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC] 228 Note that the device with NAPT and DHCP of Figure 1 is not 229 present in such a scenario. 231 2. One or more hosts with at least one router (DHCP Client or PPPoE, 232 DHCP server in router; VoIP can be soft client on PC, stand-alone 233 VoIP device, or Analog Terminal Adaptor (ATA) function embedded 234 in router) 236 1. combined router and NTE 238 2. separate router with NTE in bridged mode 240 3. separate router with NTE (NTE/router does PPPoE or DHCP to 241 WAN, router provides DHCP server for hosts in LAN; double 242 NAT) 244 The majority of fixed access broadband customers use a router. The 245 placement of the VoIP client is mentioned to describe what sorts of 246 hosts may need to be able to request location information. Soft 247 clients on PCs are frequently not launched until long after bootstrap 248 is complete, and are not able to control any options that may be 249 specified during bootstrap. They also cannot control whether a VPN 250 client is running on the end host. 252 3.2. Moving Network 254 An example of a moving network is a "WIMAX-like fixed wireless" 255 scenario that is offered in several cities, like New Orleans, Biloxi, 256 etc., where much of the communications infrastructure was destroyed 257 due to a natural disaster. The customer-side antenna for this 258 service is rather small (about the size of a mass market paperback 259 book) and can be run off battery power. The output of this little 260 antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this 261 Ethernet jack. The user would then run a PPPoE client to connect to 262 the network. Once the network connection is established, the user 263 can run a SIP client on the laptop. 265 The network-side antenna is, for example, connected through ATM to 266 the core network, and from there to the same BRASs that serve regular 267 DSL customers. These Broadband Remote Access Servers (BRASs) 268 terminate the PPPoE sessions, just like they do for regular DSL. 270 The laptop and SIP client are, in this case, unaware that they are 271 "mobile". All they see is an Ethernet connection, and the IP address 272 they get from PPPoE does not change over the coverage area. Only the 273 user and the network are aware of the laptop's mobility. 275 Further examples of moving networks can be found in busses, trains, 276 and airplanes. 278 Figure 2 shows an example topology for a moving network. 280 +--------------------------+ 281 | Wireless | 282 | Access Network Provider | 283 | | 284 | +----------+| 285 | +-------+ LIS || 286 | | | || 287 | +---+----+ +----------+| 288 | | Node | | 289 | | | | 290 | +---+----+ | 291 | | | 292 +------+-------------------+ 293 | Wireless Interface 294 | 295 +------+-------------------+ 296 | | Moving Network | 297 | +---+----+ | 298 | | NTE | +--------+ | 299 | | +---+ Host | | 300 | +-+-----++ | B | | 301 | | \ +--------+ | 302 | | \ | 303 |+---+----+ \ +---+----+ | 304 || Host | \ | Host | | 305 || A | \+ B | | 306 |+--------+ +--------+ | 307 +--------------------------+ 309 Figure 2: Moving Network 311 3.3. Wireless Access 313 Figure 3 shows a wireless access network where a moving end host 314 obtains location information or references to location information 315 from the LIS. The access equipment uses, in many cases, link layer 316 devices. Figure 3 represents a hotspot network found, for example, 317 in hotels, airports, and coffee shops. For editorial reasons we only 318 describe a single access point and do not depict how the LIS obtains 319 location information since this is very deployment specific. 321 +--------------------------+ 322 | Access Network Provider | 323 | | 324 | +----------+| 325 | +-------| LIS || 326 | | | || 327 | +--------+ +----------+| 328 | | Access | | 329 | | Point | | 330 | +--------+ | 331 | | | 332 +------+-------------------+ 333 | 334 +------+ 335 | End | 336 | Host | 337 +------+ 339 Figure 3: Wireless Access Scenario 341 4. Discovery of the Location Information Server 343 When a Target wants to retrieve location information from the LIS it 344 first needs to discover it. Based on the problem statement of 345 determining the location of the Target, which is known best by 346 entities close to the Target itself, we assume that the LIS is 347 located in the local subnet or in access network. Several procedures 348 have been investigated that aim to discover the LIS in such an access 349 network. 351 DHCP-based Discovery: 353 In some environments the Dynamic Host Configuration Protocol 354 (DHCP) might be a good choice for discovering the FQDN or the IP 355 address of the LIS. In environments where DHCP can be used it is 356 also possible to use the already defined location extensions. In 357 environments with legacy devices, such as the one shown in 358 Section 3.1, a DHCP based discovery solution may not be possible. 360 DNS-based Discovery: 362 Before a DNS lookup can be started it is necessary to learn the 363 domain name of the access network that runs a LIS. Several ways 364 to learn the domain name exist. For example, the end host obtains 365 its own public IP address, for example via STUN [6], and performs 366 a reverse DNS lookup (assuming the data is provisioned into the 367 DNS). Then, the SRV or NAPTR record for that domain is retrieved. 368 A more detailed description of this approach can be found in [7]. 370 Redirect Rule: 372 A redirect rule at a device in the access network, for example at 373 the AAA client, could be used to redirect the L7 LCP signalling 374 messages (destined to a specific port) to the LIS. The end host 375 could then discover the LIS by sending a packet with a specific 376 (registered) port number to almost any address (as long as the 377 destination IP address does not target a device in the local 378 network). The packet would be redirected to the respective LIS 379 being configured. The same procedure is used by captive portals 380 whereby any HTTP traffic is intercepted and redirected. 382 To some extend this approach is similar to packets that are marked 383 with a Router Alert option [8] and intercepted by entities that 384 understand the specific marking. In the above-mentioned case, 385 however, the marking is provided via a registered port number 386 instead of relying on a Router Alert option. 388 Multicast Query: 390 An end node could also discover a LIS by sending a DNS query to a 391 well-known address. An example of such a mechanism is multicast 392 DNS (see [9] and [10]). Unfortunately, these mechanisms only work 393 on the local link. 395 Anycast: 397 With this solution an anycast address is defined (for IPv4 and 398 IPv6) in the style of [11] that allows the endhost to route 399 discovery packets to the nearest LIS. Note that this procedure 400 would be used purely for discovery and thereby similar to local 401 Teredo server discovery approach outlined in Section 4.2 of [12]. 403 The LIS discovery procedure raises deployment and security issues. 404 When an end host discovers a LIS it must be ensured that 406 1. it does not talk to a man-in-the-middle, and 408 2. that the discovered entity is indeed an authorized LIS. 410 5. Identifier for Location Determination 412 The LIS returns location information to the end host when it receives 413 a request. Some form of identifier is therefore needed to allow the 414 LIS to retrieve the Target's current location (or a good 415 approximation of it) from a database. 417 The chosen identifier needs to have the following properties: 419 Ability for Target to learn or know the identifier: 421 The Target MUST know or MUST be able to learn the identifier 422 (explicitly or implicitly) in order to send it to the LIS. 423 Implicitly refers to the situation where a device along the path 424 between the end host and the LIS modifies the identifier, as it is 425 done by a NAT when an IP address based identifier is used. 427 Ability to use the identifier for location determination: 429 The LIS MUST be able to use the identifier (directly or 430 indirectly) for location determination. Indirectly refers to the 431 case where the LIS uses other identifiers internally for location 432 determination, in addition to the one provided by the Target. 434 Security properties of the identifier: 436 Misuse needs to be minimized whereby off-path adversary MUST NOT 437 be able to obtain location information of other Targets. A on- 438 path adversary in the same subnet SHOULD NOT be able to spoof the 439 identifier of another Target in the same subnet. 441 The following list discusses frequently mentioned identifiers and 442 their properties: 444 Host MAC Address: 446 The Target's MAC address is known to the end host, but not carried 447 over an IP hop and therefore not accessible to the LIS in most 448 deployment environments (unless carried in the L7 LCP itself). 450 ATM VCI/VPI: 452 The VPI/VCI is generally only seen by the DSL modem. Almost all 453 routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35. 454 This VC is terminated at the DSLAM, which uses a different VPI/VCI 455 (per end customer) to connect to the ATM switch. Only the network 456 provider is able to map VPI/VCI values through its network. With 457 the arrival of VDSL, ATM will slowly be phased out in favor of 458 Ethernet. 460 Switch/Port Number: 462 This identifier is available only in certain networks, such as 463 enterprise networks, typically available via proprietary protocols 464 like CDP or, in the future, 802.1ab. 466 Cell ID: 468 This identifier is available in cellular data networks and the 469 cell ID may not be visible to the end host. 471 Host Identifier: 473 The Host Identifier introduced by the Host Identity Protocol [13] 474 allows identification of a particular host. Unfortunately, the 475 network can only use this identifier for location determination if 476 the operator already stores an mapping of host identities to 477 location information. Furthermore, there is a deployment problem 478 since the host identities are not used in todays networks. 480 Cryptographically Generated Address (CGA): 482 The concept of a Cryptographically Generated Address (CGA) was 483 introduced by [14]. The basic idea is to put the truncated hash 484 of a public key into the interface identifier part of an IPv6 485 address. In addition to the properties of an IP address it allows 486 a proof of ownership. Hence, a return routability check can be 487 omitted. It is only available for IPv6 addresses. 489 Network Access Identifiers: 491 A Network Access Identifier [15] is used during the network access 492 authentication procedure, for example in RADIUS [16] and Diameter 493 [17]. In DSL networks the user credentials are, in many cases, 494 only known by the home router and not configured at the Target 495 itself. To the network, the authenticated user identity is only 496 available if a network access authentication procedure is 497 executed. In case of roaming the user's identity might not be 498 available to the access network since security protocols might 499 offer user identity confidentiality and thereby hiding the real 500 identity of the user allowing the access network to only see a 501 pseudonym or a randomized string. 503 Unique Client Identifier 505 The DSL Forum has defined that all devices that expect to be 506 managed by the TR-069 interface be able to generate an identifier 507 as described in Section 3.4.4 of the TR-069v2 DSL Forum document. 508 It also has a requirement that routers that use DHCP to the WAN 509 use RFC 4361 [18] to provide the DHCP server with a unique client 510 identifier. This identifier is, however, not visible to the 511 Target when legacy NTE device are used. 513 IP Address: 515 The Target's IP address may be used for location determination. 516 This IP address is not visible to the LIS if the end host is 517 behind one or multiple NATs. This may not be a problem since the 518 location of a host that is located behind a NAT cannot be 519 determined by the access network. The LIS would in this case only 520 see the public IP address of the NAT binding allocated by the NAT, 521 which is the expected behavior. The property of the IP address 522 for a return routability check is attractive to return location 523 information only to the address that submitted the request. If an 524 adversary wants to learn the location of a Target (as identified 525 by a particular IP address) then it does not see the response 526 message (unless he is on the subnetwork or at a router along the 527 path towards the LIS). 529 On a shared medium an adversary could ask for location information 530 of another Target. The adversary would be able to see the 531 response message since it is sniffing on the shared medium unless 532 security mechanisms, such as link layer encryption, are in place. 533 With a network deployment as shown in Section 3.1 with multiple 534 hosts in the Customer Premise being behind a NAT the LIS is unable 535 to differentiate the individual end points. For WLAN deployments 536 as found in hotels, as shown in Section 3.3, it is possible for an 537 adversary to eavesdrop data traffic and subsequently to spoof the 538 IP address in a query to the LIS to learn more detailed location 539 information (e.g., specific room numbers). Such an attack might, 540 for example, compromise the privacy of hotel guests. 542 6. Requirements 544 The following requirements and assumptions have been identified: 546 Requirement L7-1: Identifier Choice 548 The L7 LCP MUST be able to carry different identifiers or MUST 549 define an identifier that is mandatory to implement. Regarding 550 the latter aspect, such an identifier is only appropriate if it is 551 from the same realm as the one for which the location information 552 service maintains identifier to location mapping. 554 Requirement L7-2: Mobility Support 556 The L7 LCP MUST support a broad range of mobility from devices 557 that can only move between reboots, to devices that can change 558 attachment points with the impact that their IP address is 559 changed, to devices that do not change their IP address while 560 roaming, to devices that continuously move by being attached to 561 the same network attachment point. 563 Requirement L7-3: ASP and Access Network Provider Relationship 565 The design of the L7 LCP MUST NOT assume a business or trust 566 relationship between the Application Service Provider (ASP) and 567 the Access Network Provider. Requirements for resolving a 568 reference to location information are not discussed in this 569 document. 571 Requirement L7-4: Layer 2 and Layer 3 Provider Relationship 573 The design of the L7 LCP MUST assume that there is a trust and 574 business relationship between the L2 and the L3 provider. The L3 575 provider operates the LIS and needs to obtain location information 576 from the L2 provider since this one is closest to the end host. 577 If the L2 and L3 provider for the same host are different 578 entities, they cooperate for the purposes needed to determine end 579 system locations. 581 Requirement L7-5: Legacy Device Considerations 583 The design of the L7 LCP MUST consider legacy devices, such as 584 residential NAT devices and NTEs in an DSL environment, that 585 cannot be upgraded to support additional protocols, for example, 586 to pass additional information towards the Target. 588 Requirement L7-6: VPN Awareness 590 The design of the L7 LCP MUST assume that at least one end of a 591 VPN is aware of the VPN functionality. In an enterprise scenario, 592 the enterprise side will provide the LIS used by the client and 593 can thereby detect whether the LIS request was initiated through a 594 VPN tunnel. 596 Requirement L7-7: Network Access Authentication 598 The design of the L7 LCP MUST NOT assume prior network access 599 authentication. 601 Requirement L7-8: Network Topology Unawareness 603 The design of the L7 LCP MUST NOT assume end systems being aware 604 of the access network topology. End systems are, however, able to 605 determine their public IP address(es) via mechanisms, such as STUN 606 [6] or NSIS NATFW NSLP [19] . 608 Requirement L7-9: Discovery Mechanism 610 The L7 LCP MUST define a mandatory-to-implement LIS discovery 611 mechanism. 613 Requirement L7-10: PIDF-LO Creation 615 When a LIS creates a PIDF-LO [20] then it MUST put the 616 element into the element of the presence document (see 617 [21]). This ensures that the resulting PIDF-LO document, which is 618 subsequently distributed to other entities, conforms to the rules 619 outlined in [22]. 621 7. Security Considerations 623 This document contains security related requirements. A discussion 624 about security aspects of the HELD protocol when used in the GEOPRIV 625 architecture when applied to certain usage environments, such as 626 emergency services, can be found in [23]. 628 8. IANA Considerations 630 This document does not require actions by IANA. 632 9. Contributors 634 This contribution is a joint effort of the GEOPRIV Layer 7 Location 635 Configuration Requirements Design Team of the IETF GEOPRIV Working 636 Group. The contributors include Henning Schulzrinne, Barbara Stark, 637 Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, 638 Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. 640 We would like to thank the GEOPRIV working group chairs, Andy Newton, 641 Randy Gellens and Allison Mankin, for creating the design team. 643 The design team members can be reached at: 645 Marc Linsner: mlinsner@cisco.com 647 Rohan Mahy: rohan@ekabal.com 649 Andrew Newton: andy@hxr.us 651 Jon Peterson: jon.peterson@neustar.biz 653 Brian Rosen: br@brianrosen.net 655 Henning Schulzrinne: hgs@cs.columbia.edu 657 Barbara Stark: Barbara.Stark@bellsouth.com 659 Martin Thomson: Martin.Thomson@andrew.com 661 Hannes Tschofenig: Hannes.Tschofenig@nsn.com 663 James Winterbottom: James.Winterbottom@andrew.com 665 10. Acknowledgements 667 We would like to thank the IETF GEOPRIV working group chairs, Andy 668 Newton, Allison Mankin and Randall Gellens, for creating this design 669 team. Furthermore, we would like thank Andy Newton for his support 670 during the design team mailing list, for setting up Jabber chat 671 conferences and for participating in the phone conference 672 discussions. 674 We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin 675 Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, 676 Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, 677 Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara 678 Stark, Michael Haberler, and Mary Barnes for their WGLC review 679 comments. 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-01 (work in 700 progress), October 2007. 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., "NAT/Firewall NSIS Signaling Layer Protocol 753 (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in progress), 754 July 2007. 756 [20] Peterson, J., "A Presence-based GEOPRIV Location Object 757 Format", RFC 4119, December 2005. 759 [21] Rosenberg, J., "A Data Model for Presence", RFC 4479, 760 July 2006. 762 [22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 763 PIDF-LO Usage Clarification, Considerations and 764 Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work 765 in progress), October 2007. 767 [23] Barnes, R., "Threats to GEOPRIV Location Objects", 768 draft-barnes-geopriv-lo-sec-00 (work in progress), July 2007. 770 Authors' Addresses 772 Hannes Tschofenig 773 Nokia Siemens Networks 774 Otto-Hahn-Ring 6 775 Munich, Bavaria 81739 776 Germany 778 Phone: +49 89 636 40390 779 Email: Hannes.Tschofenig@nsn.com 780 URI: http://www.tschofenig.com 782 Henning Schulzrinne 783 Columbia University 784 Department of Computer Science 785 450 Computer Science Building 786 New York, NY 10027 787 US 789 Phone: +1 212 939 7004 790 Email: hgs+ecrit@cs.columbia.edu 791 URI: http://www.cs.columbia.edu 793 Full Copyright Statement 795 Copyright (C) The IETF Trust (2007). 797 This document is subject to the rights, licenses and restrictions 798 contained in BCP 78, and except as set forth therein, the authors 799 retain all their rights. 801 This document and the information contained herein are provided on an 802 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 803 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 804 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 805 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 806 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 807 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 809 Intellectual Property 811 The IETF takes no position regarding the validity or scope of any 812 Intellectual Property Rights or other rights that might be claimed to 813 pertain to the implementation or use of the technology described in 814 this document or the extent to which any license under such rights 815 might or might not be available; nor does it represent that it has 816 made any independent effort to identify any such rights. Information 817 on the procedures with respect to rights in RFC documents can be 818 found in BCP 78 and BCP 79. 820 Copies of IPR disclosures made to the IETF Secretariat and any 821 assurances of licenses to be made available, or the result of an 822 attempt made to obtain a general license or permission for the use of 823 such proprietary rights by implementers or users of this 824 specification can be obtained from the IETF on-line IPR repository at 825 http://www.ietf.org/ipr. 827 The IETF invites any interested party to bring to its attention any 828 copyrights, patents or patent applications, or other proprietary 829 rights that may cover technology that may be required to implement 830 this standard. Please address the information to the IETF at 831 ietf-ipr@ietf.org. 833 Acknowledgment 835 Funding for the RFC Editor function is provided by the IETF 836 Administrative Support Activity (IASA).