idnits 2.17.1 draft-ietf-geopriv-l7-lcp-ps-07.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 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 830. 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 (March 29, 2008) is 5873 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: September 30, 2008 Columbia University 6 March 29, 2008 8 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and 9 Requirements 10 draft-ietf-geopriv-l7-lcp-ps-07.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 September 30, 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: DSL 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 frequently show 214 the following characteristics: 216 1. CPE = 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 An example of a moving network is a "WIMAX-like fixed wireless" 251 scenario that is offered in several cities, like New Orleans, Biloxi, 252 etc., where much of the communications infrastructure was destroyed 253 due to a natural disaster. The customer-side antenna for this 254 service is rather small (about the size of a mass market paperback 255 book) and can be run off battery power. The output of this little 256 antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this 257 Ethernet jack. The user would then run a PPPoE client to connect to 258 the network. Once the network connection is established, the user 259 can run a SIP client on the laptop. 261 The network-side antenna is, for example, connected through ATM to 262 the core network, and from there to the same BRASs that serve regular 263 DSL customers. These Broadband Remote Access Servers (BRASs) 264 terminate the PPPoE sessions, just like they do for regular DSL. 266 The laptop and SIP client are, in this case, unaware that they are 267 "mobile". All they see is an Ethernet connection, and the IP address 268 they get from PPPoE does not change over the coverage area. Only the 269 user and the network are aware of the laptop's mobility. 271 Further examples of moving networks can be found in busses, trains, 272 and airplanes. 274 Figure 2 shows an example topology for a moving network. 276 +--------------------------+ 277 | Wireless | 278 | Access Network Provider | 279 | | 280 | +----------+| 281 | +-------+ LIS || 282 | | | || 283 | +---+----+ +----------+| 284 | | Node | | 285 | | | | 286 | +---+----+ | 287 | | | 288 +------+-------------------+ 289 | Wireless Interface 290 | 291 +------+-------------------+ 292 | | Moving Network | 293 | +---+----+ | 294 | | NTE | +--------+ | 295 | | +---+ Host | | 296 | +-+-----++ | B | | 297 | | \ +--------+ | 298 | | \ | 299 |+---+----+ \ +---+----+ | 300 || Host | \ | Host | | 301 || A | \+ B | | 302 |+--------+ +--------+ | 303 +--------------------------+ 305 Figure 2: Moving Network 307 3.3. Wireless Access 309 Figure 3 shows a wireless access network where a moving end host 310 obtains location information or references to location information 311 from the LIS. The access equipment uses, in many cases, link layer 312 devices. Figure 3 represents a hotspot network found, for example, 313 in hotels, airports, and coffee shops. For editorial reasons we only 314 describe a single access point and do not depict how the LIS obtains 315 location information since this is very deployment specific. 317 +--------------------------+ 318 | Access Network Provider | 319 | | 320 | +----------+| 321 | +-------| LIS || 322 | | | || 323 | +--------+ +----------+| 324 | | Access | | 325 | | Point | | 326 | +--------+ | 327 | | | 328 +------+-------------------+ 329 | 330 +------+ 331 | End | 332 | Host | 333 +------+ 335 Figure 3: Wireless Access Scenario 337 4. Discovery of the Location Information Server 339 When a Target wants to retrieve location information from the LIS it 340 first needs to discover it. Based on the problem statement of 341 determining the location of the Target, which is known best by 342 entities close to the Target itself, we assume that the LIS is 343 located in the local subnet or in access network. Several procedures 344 have been investigated that aim to discover the LIS in such an access 345 network. 347 DHCP-based Discovery: 349 In some environments the Dynamic Host Configuration Protocol 350 (DHCP) might be a good choice for discovering the FQDN or the IP 351 address of the LIS. In environments where DHCP can be used it is 352 also possible to use the already defined location extensions. In 353 environments with legacy devices, such as the one shown in 354 Section 3.1, a DHCP based discovery solution may not be possible. 356 DNS-based Discovery: 358 Before a DNS lookup can be started it is necessary to learn the 359 domain name of the access network that runs a LIS. Several ways 360 to learn the domain name exist. For example, the end host obtains 361 its own public IP address, for example via STUN [6], and performs 362 a reverse DNS lookup (assuming the data is provisioned into the 363 DNS). Then, the SRV or NAPTR record for that domain is retrieved. 364 A more detailed description of this approach can be found in [7]. 366 Redirect Rule: 368 A redirect rule at a device in the access network, for example at 369 the AAA client, could be used to redirect the L7 LCP signalling 370 messages (destined to a specific port) to the LIS. The end host 371 could then discover the LIS by sending a packet with a specific 372 (registered) port number to almost any address (as long as the 373 destination IP address does not target a device in the local 374 network). The packet would be redirected to the respective LIS 375 being configured. The same procedure is used by captive portals 376 whereby any HTTP traffic is intercepted and redirected. 378 To some extend this approach is similar to packets that are marked 379 with a Router Alert option [8] and intercepted by entities that 380 understand the specific marking. In the above-mentioned case, 381 however, the marking is provided via a registered port number 382 instead of relying on a Router Alert option. 384 Multicast Query: 386 An end node could also discover a LIS by sending a DNS query to a 387 well-known address. An example of such a mechanism is multicast 388 DNS (see [9] and [10]). Unfortunately, these mechanisms only work 389 on the local link. 391 Anycast: 393 With this solution an anycast address is defined (for IPv4 and 394 IPv6) in the style of [11] that allows the endhost to route 395 discovery packets to the nearest LIS. Note that this procedure 396 would be used purely for discovery and thereby similar to local 397 Teredo server discovery approach outlined in Section 4.2 of [12]. 399 The LIS discovery procedure raises deployment and security issues. 400 When an end host discovers a LIS it must be ensured that 402 1. it does not talk to a man-in-the-middle, and 404 2. 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 an 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 Premise being behind a NAT the LIS is unable 531 to differentiate the individual end points. For WLAN deployments 532 as found in hotels, as shown in Section 3.3, it is possible for an 533 adversary to eavesdrop data traffic and subsequently to spoof the 534 IP address in a query to the LIS to learn more detailed location 535 information (e.g., specific room numbers). Such an attack might, 536 for example, compromise the privacy of hotel guests. 538 6. Requirements 540 The following requirements and assumptions have been identified: 542 Requirement L7-1: Identifier Choice 544 The L7 LCP MUST be able to carry different identifiers or MUST 545 define an identifier that is mandatory to implement. Regarding 546 the latter aspect, such an identifier is only appropriate if it is 547 from the same realm as the one for which the location information 548 service maintains identifier to location mapping. 550 Requirement L7-2: Mobility Support 552 The L7 LCP MUST support a broad range of mobility from devices 553 that can only move between reboots, to devices that can change 554 attachment points with the impact that their IP address is 555 changed, to devices that do not change their IP address while 556 roaming, to devices that continuously move by being attached to 557 the same network attachment point. 559 Requirement L7-3: ASP and Access Network Provider Relationship 561 The design of the L7 LCP MUST NOT assume a business or trust 562 relationship between the Application Service Provider (ASP) and 563 the Access Network Provider. Requirements for resolving a 564 reference to location information are not discussed in this 565 document. 567 Requirement L7-4: Layer 2 and Layer 3 Provider Relationship 569 The design of the L7 LCP MUST assume that there is a trust and 570 business relationship between the L2 and the L3 provider. The L3 571 provider operates the LIS and needs to obtain location information 572 from the L2 provider since this one is closest to the end host. 573 If the L2 and L3 provider for the same host are different 574 entities, they cooperate for the purposes needed to determine end 575 system locations. 577 Requirement L7-5: Legacy Device Considerations 579 The design of the L7 LCP MUST consider legacy devices, such as 580 residential NAT devices and NTEs in an DSL environment, that 581 cannot be upgraded to support additional protocols, for example, 582 to pass additional information towards the Target. 584 Requirement L7-6: VPN Awareness 586 The design of the L7 LCP MUST assume that at least one end of a 587 VPN is aware of the VPN functionality. In an enterprise scenario, 588 the enterprise side will provide the LIS used by the client and 589 can thereby detect whether the LIS request was initiated through a 590 VPN tunnel. 592 Requirement L7-7: Network Access Authentication 594 The design of the L7 LCP MUST NOT assume prior network access 595 authentication. 597 Requirement L7-8: Network Topology Unawareness 599 The design of the L7 LCP MUST NOT assume end systems being aware 600 of the access network topology. End systems are, however, able to 601 determine their public IP address(es) via mechanisms, such as STUN 602 [6] or NSIS NATFW NSLP [19] . 604 Requirement L7-9: Discovery Mechanism 606 The L7 LCP MUST define a mandatory-to-implement LIS discovery 607 mechanism. 609 Requirement L7-10: PIDF-LO Creation 611 When a LIS creates a PIDF-LO [20] then it MUST put the 612 element into the element of the presence document (see 613 [21]). This ensures that the resulting PIDF-LO document, which is 614 subsequently distributed to other entities, conforms to the rules 615 outlined in [22]. 617 7. Security Considerations 619 This document contains security related requirements. A discussion 620 about security aspects of the HELD protocol when used in the GEOPRIV 621 architecture when applied to certain usage environments, such as 622 emergency services, can be found in [23]. 624 8. IANA Considerations 626 This document does not require actions by IANA. 628 9. Contributors 630 This contribution is a joint effort of the GEOPRIV Layer 7 Location 631 Configuration Requirements Design Team of the IETF GEOPRIV Working 632 Group. The contributors include Henning Schulzrinne, Barbara Stark, 633 Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, 634 Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. 636 We would like to thank the GEOPRIV working group chairs, Andy Newton, 637 Randy Gellens and Allison Mankin, for creating the design team. 639 The design team members can be reached at: 641 Marc Linsner: mlinsner@cisco.com 643 Rohan Mahy: rohan@ekabal.com 645 Andrew Newton: andy@hxr.us 647 Jon Peterson: jon.peterson@neustar.biz 649 Brian Rosen: br@brianrosen.net 651 Henning Schulzrinne: hgs@cs.columbia.edu 653 Barbara Stark: Barbara.Stark@bellsouth.com 655 Martin Thomson: Martin.Thomson@andrew.com 657 Hannes Tschofenig: Hannes.Tschofenig@nsn.com 659 James Winterbottom: James.Winterbottom@andrew.com 661 10. Acknowledgements 663 We would like to thank the IETF GEOPRIV working group chairs, Andy 664 Newton, Allison Mankin and Randall Gellens, for creating this design 665 team. Furthermore, we would like thank Andy Newton for his support 666 during the design team mailing list, for setting up Jabber chat 667 conferences and for participating in the phone conference 668 discussions. 670 We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin 671 Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, 672 Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, 673 Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara 674 Stark, Michael Haberler, and Mary Barnes for their WGLC review 675 comments. 677 11. References 679 11.1. Normative References 681 [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 682 Polk, "Geopriv Requirements", RFC 3693, February 2004. 684 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 685 Levels", RFC 2119, BCP 14, March 1997. 687 [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 688 Context Resolution with Internet Technologies", 689 draft-ietf-ecrit-requirements-13 (work in progress), 690 March 2007. 692 11.2. Informative References 694 [4] Marshall, R., "Requirements for a Location-by-Reference 695 Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work in 696 progress), February 2008. 698 [5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 699 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 (work 700 in progress), November 2007. 702 [6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 703 - Simple Traversal of User Datagram Protocol (UDP) Through 704 Network Address Translators (NATs)", RFC 3489, March 2003. 706 [7] Thomson, M. and J. Winterbottom, "Discovering the Local 707 Location Information Server (LIS)", 708 draft-thomson-geopriv-lis-discovery-03 (work in progress), 709 September 2007. 711 [8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 713 [9] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast 714 Name Resolution (LLMNR)", RFC 4795, January 2007. 716 [10] Cheshire, S. and M. Krochmal, "Multicast DNS", 717 draft-cheshire-dnsext-multicastdns-06 (work in progress), 718 August 2006. 720 [11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 721 RFC 3068, June 2001. 723 [12] Ward, N., "Teredo Server Selection", 724 draft-nward-v6ops-teredo-server-selection-00 (work in 725 progress), July 2007. 727 [13] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 728 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 729 progress), October 2007. 731 [14] Aura, T., "Cryptographically Generated Addresses (CGA)", 732 RFC 3972, March 2005. 734 [15] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 735 Access Identifier", RFC 4282, December 2005. 737 [16] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 738 Authentication Dial In User Service (RADIUS)", RFC 2865, 739 June 2000. 741 [17] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 742 "Diameter Base Protocol", RFC 3588, September 2003. 744 [18] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers 745 for Dynamic Host Configuration Protocol Version Four (DHCPv4)", 746 RFC 4361, February 2006. 748 [19] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/ 749 Firewall NSIS Signaling Layer Protocol (NSLP)", 750 draft-ietf-nsis-nslp-natfw-18 (work in progress), 751 February 2008. 753 [20] Peterson, J., "A Presence-based GEOPRIV Location Object 754 Format", RFC 4119, December 2005. 756 [21] Rosenberg, J., "A Data Model for Presence", RFC 4479, 757 July 2006. 759 [22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 760 PIDF-LO Usage Clarification, Considerations and 761 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work 762 in progress), February 2008. 764 [23] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne, 765 "Security Requirements for the Geopriv Location System", 766 draft-barnes-geopriv-lo-sec-02 (work in progress), 767 February 2008. 769 Authors' Addresses 771 Hannes Tschofenig 772 Nokia Siemens Networks 773 Linnoitustie 6 774 Espoo 02600 775 Finland 777 Phone: +358 (50) 4871445 778 Email: Hannes.Tschofenig@gmx.net 779 URI: http://www.tschofenig.priv.at 781 Henning Schulzrinne 782 Columbia University 783 Department of Computer Science 784 450 Computer Science Building 785 New York, NY 10027 786 US 788 Phone: +1 212 939 7004 789 Email: hgs+ecrit@cs.columbia.edu 790 URI: http://www.cs.columbia.edu 792 Full Copyright Statement 794 Copyright (C) The IETF Trust (2008). 796 This document is subject to the rights, licenses and restrictions 797 contained in BCP 78, and except as set forth therein, the authors 798 retain all their rights. 800 This document and the information contained herein are provided on an 801 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 802 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 803 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 804 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 805 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 806 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 808 Intellectual Property 810 The IETF takes no position regarding the validity or scope of any 811 Intellectual Property Rights or other rights that might be claimed to 812 pertain to the implementation or use of the technology described in 813 this document or the extent to which any license under such rights 814 might or might not be available; nor does it represent that it has 815 made any independent effort to identify any such rights. Information 816 on the procedures with respect to rights in RFC documents can be 817 found in BCP 78 and BCP 79. 819 Copies of IPR disclosures made to the IETF Secretariat and any 820 assurances of licenses to be made available, or the result of an 821 attempt made to obtain a general license or permission for the use of 822 such proprietary rights by implementers or users of this 823 specification can be obtained from the IETF on-line IPR repository at 824 http://www.ietf.org/ipr. 826 The IETF invites any interested party to bring to its attention any 827 copyrights, patents or patent applications, or other proprietary 828 rights that may cover technology that may be required to implement 829 this standard. Please address the information to the IETF at 830 ietf-ipr@ietf.org.