idnits 2.17.1 draft-ietf-geopriv-l7-lcp-ps-01.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 771. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 795. 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 (April 6, 2007) is 6227 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '15' is defined on line 720, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 723, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 726, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 730, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-marshall-geopriv-lbyr-requirements-01 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '5') (Obsoleted by RFC 5389) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-06 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-07 -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. '10') (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '12') (Obsoleted by RFC 6733) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-14 == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-05 -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '18') (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 11 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: October 8, 2007 Columbia U. 6 April 6, 2007 8 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and 9 Requirements 10 draft-ietf-geopriv-l7-lcp-ps-01.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 October 8, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document provides a problem statement, lists requirements and 44 captures discussions for a GEOPRIV Layer 7 Location Configuration 45 Protocol (LCP). This protocol aims to allow an end host to obtain 46 location information, by value or by reference, from a Location 47 Server (LS) that is located in the access network. The obtained 48 location information can then be used for a variety of different 49 protocols and purposes. For example, it can be used as input to the 50 Location-to-Service Translation Protocol (LoST) or to convey location 51 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 66 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 69 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 70 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 72 Intellectual Property and Copyright Statements . . . . . . . . . . 26 74 1. Introduction 76 This document provides a problem statement, lists requirements and 77 captures discussions for a GEOPRIV Layer 7 Location Configuration 78 Protocol (LCP). The protocol has two purposes: 80 o It is used to obtain location information from a special node, 81 called the Location Server (LS). 83 o It enables the end host to obtain a reference to location 84 information. This reference can take the form of a subscription 85 URI, such as a SIP presence URI, an HTTP/HTTPS URI, or any others. 86 The requirements related to the task of obtaining such a reference 87 are described in a separate document, see [4]. 89 The need for these two functions can be derived from the scenarios 90 presented in Section 3. 92 For this document we assume that the GEOPRIV Layer 7 LCP runs between 93 the end host (i.e., the Target in [1] terminology) acting as the LCP 94 client and the Location Server acting as an LCP server. 96 This document splits the problem space into separate parts and 97 discusses them in separate subsections. Section 4 discusses the 98 challenge of discovering the Location Information Server in the 99 access network. Section 5 compares different types of identifiers 100 that can be used to retrieve location information. A list of 101 requirements for the GEOPRIV Layer 7 Location Configuration Protocol 102 can be found in Section 6. 104 This document does not describe how the access network provider 105 determines the location of the end host since this is largely a 106 matter of the capabilities of specific link layer technologies. 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 We also use terminology from [1] and [3]. 118 3. Scenarios 120 This section describes a few network scenarios where the GEOPRIV 121 Layer 7 Location Configuration Protocol may be used. Note that this 122 section does not aim to list all possible deployment environments 123 exhaustively. We focus on the description of the following 124 environments: 126 o DSL/Cable networks, WiMax-like fixed access 128 o Airport, City, Campus Wireless Networks, such as 802.11a/b/g, 129 802.16e/Wimax 131 o 3G networks 133 o Enterprise networks 135 We illustrate a few examples below. 137 3.1. Fixed Wired Environment 139 The following figure shows a DSL network scenario with the Access 140 Network Provider and the customer premises. The Access Network 141 Provider operates link and network layer devices (represented as 142 Node) and the Location Server (LS). 144 +---------------------------+ 145 | | 146 | Access Network Provider | 147 | | 148 | +--------+ | 149 | | Node | | 150 | +--------+ +----------+ | 151 | | | | LS | | 152 | | +---| | | 153 | | +----------+ | 154 | | | 155 +-------+-------------------+ 156 | Wired Network 157 <----------------> Access Network Provider demarc 158 | 159 +-------+-------------------+ 160 | | | 161 | +-------------+ | 162 | | NTE | | 163 | +-------------+ | 164 | | | 165 | | | 166 | +--------------+ | 167 | | Device with | Home | 168 | | NAPT and | Router | 169 | | DHCP server | | 170 | +--------------+ | 171 | | | 172 | | | 173 | +------+ | 174 | | End | | 175 | | Host | | 176 | +------+ | 177 | | 178 |Customer Premises Network | 179 | | 180 +---------------------------+ 182 Figure 1: DSL Scenario 184 The customer premises consists of a router with a Network Address 185 Translator with Port Address Translation (NAPT) and a DHCP server as 186 used in most Customer Premises Networks (CPN) and the Network 187 Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 188 protocols are terminated. The router in the home network (e.g., 189 broadband router, cable or DSL router) typically runs a NAPT and a 190 DHCP server. The NTE is a legacy device and in many cases cannot be 191 modified for the purpose of delivering location information to the 192 end host. The same is true of the device with the NAPT and DHCP 193 server. 195 It is possible for the NTE and the home router to physically be in 196 the same box, or for there to be no home router, or for the NTE and 197 end host to be in the same physical box (with no home router). An 198 example of this last case is where Ethernet service is delivered to 199 customers' homes, and the Ethernet NIC in their PC serves as the NTE. 201 Current Customer Premises Network (CPN) deployments frequently show 202 the following characteristics: 204 1. CPE = Single PC 206 1. with Ethernet NIC [PPPoE or DHCP on PC]; there may be a 207 bridged DSL or cable modem as NTE, or the Ethernet NIC might 208 be the NTE 210 2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC] 212 Note that the device with NAPT and DHCP of Figure 1 is not 213 present in such a scenario. 215 2. One or more hosts with at least one router [DHCP Client or PPPoE, 216 DHCP server in router; VoIP can be soft client on PC, stand-alone 217 VoIP device, or Analog Terminal Adaptor (ATA) function embedded 218 in router] 220 1. combined router and NTE 222 2. separate router with NTE in bridged mode 224 3. separate router with NTE [NTE/router does PPPoE or DHCP to 225 WAN, router provides DHCP server for hosts in LAN; double NAT 227 The majority of fixed access broadband customers use a router. The 228 placement of the VoIP client is mentioned to describe what sorts of 229 hosts may need to be able to request location information. Soft 230 clients on PCs are frequently not launched until long after bootstrap 231 is complete, and are not able to control any options that may be 232 specified during bootstrap. They also cannot control whether a VPN 233 client is operating on the PC. 235 3.2. Moving Network 237 An example of a moving network is a "WIMAX-like fixed wireless" 238 scenario that is offered in several cities, like New Orleans, Biloxi, 239 etc., where much of the communications infrastructure was destroyed 240 due to a natural disaster. The customer-side antenna for this 241 service is rather small (about the size of a mass market paperback 242 book) and can be run off battery power. The output of this little 243 antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this 244 Ethernet jack. The user would then run a PPPoE client to connect to 245 the network. Once the network connection is established, the user 246 can run a SIP client on the laptop. 248 The network-side antenna is, for example, connected through ATM to 249 the core network, and from there to the same BRASs that serve regular 250 DSL customers. These Broadband Remote Access Servers (BRASs) 251 terminate the PPPoE sessions, just like they do for regular DSL. 253 The laptop and SIP client are, in this case, unaware that they are 254 "mobile". All they see is an Ethernet connection, and the IP address 255 they get from PPPoE does not change over the coverage area. Only the 256 user and the network are aware of the laptop's mobility. 258 Further examples of moving networks can be found in busses, trains, 259 airplanes. 261 Figure 2 shows an example topology for a moving network. 263 +--------------------------+ 264 | Wireless | 265 | Access Network Provider | 266 | | 267 | +----------+| 268 | +-------+ LS || 269 | | | || 270 | +---+----+ +----------+| 271 | | Node | | 272 | | | | 273 | +---+----+ | 274 | | | 275 +------+-------------------+ 276 | Wireless Interface 277 | 278 +------+-------------------+ 279 | | Moving Network | 280 | +---+----+ | 281 | | NTE | +--------+ | 282 | | +---+ Host | | 283 | +-+-----++ | B | | 284 | | \ +--------+ | 285 | | \ | 286 |+---+----+ \ +---+----+ | 287 || Host | \ | Host | | 288 || A | \+ B | | 289 |+--------+ +--------+ | 290 +--------------------------+ 292 Figure 2: Moving Network 294 3.3. Wireless Access 296 Figure 3 shows a wireless access network where a moving end host 297 obtains location information or references to location information 298 from the LS. The access equipment uses, in many cases, link layer 299 devices. This figure represents a hotspot network found in hotels, 300 airports, coffee shops. For editorial reasons we only describe a 301 single access point and do not depict how the LS obtains location 302 information since this is very deployment specific. 304 +--------------------------+ 305 | Access Network Provider | 306 | | 307 | +----------+| 308 | +-------| LS || 309 | | | || 310 | +--------+ +----------+| 311 | | Access | | 312 | | Point | | 313 | +--------+ | 314 | | | 315 +------+-------------------+ 316 | 317 +------+ 318 | End | 319 | Host | 320 +------+ 322 Figure 3: Wireless Access Scenario 324 4. Discovery of the Location Information Server 326 When an end host wants to retrieve location information from the LS 327 it first needs to discover it. Based on the problem statement of 328 determining the location of the end host, which is known best by 329 entities close to the end host itself, we assume that the LS is 330 located in the access network. Several procedures have been 331 investigated that aim to discovery the LS in such an access network. 333 DHCP-based Discovery: 335 In some environments the Dynamic Host Configuration Protocol might 336 be a good choice for discovering the FQDN or the IP address of the 337 LS. In environments where DHCP can be used it is also possible to 338 use the already defined location extensions. In environments with 339 legacy devices, such as the one shown in Section 3.1, a DHCP based 340 discovery solution is not possible. 342 DNS-based Discovery: 344 With this idea the end host obtains its public IP address (e.g., 345 via STUN [5]) in order to obtain its domain name (via the usual 346 reverse DNS lookup). Then, the SRV or NAPTR record for that 347 domain is retrieved. This relies on the user's public IP address 348 having a DNS entry. 350 Redirect Rule: 352 A redirect rule at a device in the access network, for example at 353 the AAA client, will be used to redirect the Geopriv-L7 signalling 354 messages (destined to a specific port) to the LS. The end host 355 could then discover the LS by sending a packet to almost any 356 address (as long it is not in the local network). The packet 357 would be redirected to the respective LS being configured. The 358 same procedure is used by captive portals whereby any HTTP traffic 359 is intercepted and redirected. 361 Multicast Query: 363 An end node could also discover a LS by sending a multicast 364 request to a well-known address. An example of such a mechanism 365 is multicast DNS (see [6] and [7]). 367 The LS discovery procedure raises deployment and security issues. 368 When an end host discovers a LS, 369 1. it does not talk to a man-in-the-middle adversary, and 371 2. it needs to ensure that the discovered entity is indeed an 372 authorized LS. 374 5. Identifier for Location Determination 376 The LS returns location information to the end host when it receives 377 a request. Some form of identifier is therefore needed to allow the 378 LS to determine the current location of the target or a good 379 approximation of it. 381 The chosen identifier needs to have the following properties: 383 Ability for end host to learn or know the identifier: 385 The end host MUST know or MUST be able to learn the identifier 386 (explicitly or implicitly) in order to send it to the LS. 387 Implicitly refers to the situation where a device along the path 388 between the end host and the LS modifies the identifier, as it is 389 done by a NAT when an IP address based identifier is used. 391 Ability to use the identifier for location determination: 393 The LS MUST be able to use the identifier (directly or indirectly) 394 for location determination. Indirectly refers to the case where 395 the LS uses other identifiers locally within the access network, 396 in addition to the one provided by the end host, for location 397 determination. 399 Security properties of the identifier: 401 Misuse needs to be minimized whereby off-path adversary MUST NOT 402 be able to obtain location information of other hosts. A on-path 403 adversary in the same subnet SHOULD NOT be able to spoof the 404 identifier of another host in the same subnet. 406 The problem is further complicated by the requirement that the end 407 host should not be aware of the network topology and the LS must be 408 placed in such a way that it can determine location information with 409 the available information. As shown in Figure 1 the host behind the 410 NTE/NAPT-DHCP device is not visible to the access network and the LS 411 itself. In the DSL network environment some identifier used at the 412 NTE is observable for by the LS/access network. 414 The following list discusses frequently mentioned identifiers and 415 their properties: 417 Host MAC address: 419 The host MAC address is known to the end system, but not carried 420 over an IP hop. 422 ATM VCI/VPI: 424 The VPI/VCI is generally only seen by the DSL modem. Almost all 425 routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35. 426 This VC is terminated at the DSLAM, which uses a different VPI/VCI 427 (per end customer) to connect to the ATM switch. Only the network 428 provider is able to map VPI/VCI values through its network. With 429 the arrival of VDSL, ATM will slowly be phased out in favor of 430 Ethernet. 432 Switch/Port Number: 434 This identifier is available only in certain networks, such as 435 enterprise networks, typically available via proprietary protocols 436 like CDP or, in the future, 802.1ab. 438 Cell ID: 440 This identifier is available in cellular data networks and the 441 cell ID might not be visible to the end host. 443 Authenticated User Identity: 445 In DSL networks the user credentials are, in many cases, only 446 known by the router and not to the end host. To the network, the 447 authenticated user identity is only available if a network access 448 authentication procedure is executed. In case of roaming it still 449 might not be available to the access network since security 450 protocols might provide user identity confidentiality and thereby 451 hide the real identity of the user allowing the access network to 452 only see a pseudonym or a randomized string. 454 Host Identifier: 456 The Host Identifier introduced by the Host Identity Protocol [8] 457 allows identification of a particular host. Unfortunately, the 458 network can only use this identifier for location determination if 459 the operator already stores an mapping of host identities to 460 location information. Furthermore, there is a deployment problem 461 since the host identities are not used in todays networks. 463 Cryptographically Generated Address (CGA): 465 The concept of a Cryptographically Generated Address (CGA) was 466 introduced by [9]. The basic idea is to put the truncated hash of 467 a public key into the interface identifier part of an IPv6 468 address. In addition to the properties of an IP address it allows 469 a proof of ownership. Hence, a return routability check can be 470 omitted. 472 Network Access Identifiers: 474 A Network Access Identifier [10] is only used during the network 475 access authentication procedure in RADIUS [11] or Diameter [12]. 476 Furthermore, in a roaming scenario it does not help the access 477 network to make meaningful decisions since the username part might 478 be a pseudonym and there is no relationship to the end host's 479 location. 481 Unique Client Identifier 483 The DSL Forum has defined that all devices that expect to be 484 managed by the TR-069 interface be able to generate an identifier 485 as described in DSL Forum TR-069v2 Section 3.4.4. It also has a 486 requirement that routers that use DHCP to the WAN use RFC 4361 487 [13] to provide the DHCP server with a unique client identifier. 488 This identifier is, however, not visible to the end host with the 489 assumption of a legacy device like the NTE. If we assume that the 490 LTE can be modified then a number of solutions come to mind 491 including DHCP based location delivery. 493 IP Address: 495 The end host's IP address may be used for location determination. 496 This IP address is not visible to the LS if the end host is behind 497 one or multipel NATs. This is, however, not a problem since the 498 location of a host that is located behind a NAT cannot be 499 determined by the access network. The LS would in this case only 500 see the public IP address of the NAT binding allocated by the NAT, 501 which is the correct behavior. The property of the IP address for 502 a return routability check is attractive as well to return 503 location information only to a device that transmitted the 504 request. The LS receives the request and provides location 505 information back to the same IP address. If an adversary wants to 506 learn location information from an IP address other than its own 507 IP address then it would not see the response message (unless he 508 is on the subnetwork or at a router along the path towards the LS) 509 since the LS would return the message to the address where it came 510 from. 512 On a shared medium an adversary could ask for location information 513 of another host using its IP address. The adversary would be able 514 to see the response message since he is sniffing on the shared 515 medium unless security mechanisms (such as link layer encryption) 516 is in place. With a network deployment as shown in Section 3.1 517 with multiple hosts in the Customer Premise being behind a NAT the 518 LS is unable to differentiate the individual end points. For WLAN 519 deployments as found in hotels, as shown in as shown in 520 Section 3.3, it is possible for an adversary to eavesdrop data 521 traffic and subsequently to spoof the IP address in a query to the 522 LS to learn more detailed location information (e.g., specific 523 room numbers). Such an attack might, for example, compromise the 524 privacy of hotel guests. Note that DHCP would suffer from the 525 same problem here unless each node uses link layer security 526 mechanism. 528 Return routability checks are useful only if the adversary does 529 not see the response message and if the goal is to delay state 530 establishment. If the adversary is in a broadcast network then a 531 return routability check alone is not sufficient to prevent the 532 above attack since the adversary will observe the response. 534 6. Requirements 536 The following requirements and assumptions have been identified: 538 Requirement L7-1: Identifier Choice 540 The LS MUST be presented with a unique identifier of its own 541 addressing realm associated directly or indirectly (i.e., linked 542 through other identifiers) with the physical location of the end 543 host. 545 An identifier is only appropriate if it is from the same realm as 546 the one for which the location information service maintains 547 identifier to location mapping. 549 Requirement L7-2: Mobility Support 551 The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 552 broad range of mobility from devices that can only move between 553 reboots, to devices that can change attachment points with the 554 impact that their IP address is changed, to devices that do not 555 change their IP address while roaming, to devices that 556 continuously move by being attached to the same network attachment 557 point. 559 Requirement L7-3: Layer 7 and Layer 2/3 Provider Relationship 561 The design of the GEOPRIV Layer 7 Location Configuration Protocol 562 MUST NOT assume a business or trust relationship between the 563 provider of application layer (e.g., SIP, XMPP, H.323) provider 564 and the access network provider operating the LS. 566 Requirement L7-4: Layer 2 and Layer 3 Provider Relationship 568 The design of the GEOPRIV Layer 7 Location Configuration Protocol 569 MUST assume that there is a trust and business relationship 570 between the L2 and the L3 provider. The L3 provider operates the 571 LS and needs to obtain location information from the L2 provider 572 since this one is closest to the end host. If the L2 and L3 573 provider for the same host are different entities, they cooperate 574 for the purposes needed to determine end system locations. 576 Requirement L7-5: Legacy Device Considerations 578 The design of the GEOPRIV Layer 7 Location Configuration Protocol 579 MUST consider legacy residential NAT devices and NTEs in an DSL 580 environment that cannot be upgraded to support additional 581 protocols, for example to pass additional information through 582 DHCP. 584 Requirement L7-6: VPN Awareness 586 The design of the GEOPRIV Layer 7 Location Configuration Protocol 587 MUST assume that at least one end of a VPN is aware of the VPN 588 functionality. In an enterprise scenario, the enterprise side 589 will provide the LS used by the client and can thereby detect 590 whether the LS request was initiated through a VPN tunnel. 592 Requirement L7-7: Network Access Authentication 594 The design of the GEOPRIV Layer 7 Location Configuration Protocol 595 MUST NOT assume prior network access authentication. 597 Requirement L7-8: Network Topology Unawareness 599 The design of the GEOPRIV Layer 7 Location Configuration Protocol 600 MUST NOT assume end systems being aware of the access network 601 topology. End systems are, however, able to determine their 602 public IP address(es) via mechanisms such as STUN [5] or NSIS 603 NATFW NSLP [14] . 605 Requirement L7-9: Discovery Mechanism 607 The GEOPRIV Layer 7 Location Configuration Protocol MUST provide a 608 mandatory-to-implement discovery mechanism. 610 7. Security Considerations 612 This document addresses security aspect throughout the document. 614 8. IANA Considerations 616 This document does not require actions by IANA. 618 9. Contributors 620 This contribution is a joint effort of the GEOPRIV Layer 7 Location 621 Configuration Requirements Design Team of the IETF GEOPRIV Working 622 Group. The contributors include Henning Schulzrinne, Barbara Stark, 623 Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, 624 Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. 626 The design team members can be reached at: 628 Marc Linsner: mlinsner@cisco.com 630 Rohan Mahy: rohan@ekabal.com 632 Andrew Newton: andy@hxr.us 634 Jon Peterson: jon.peterson@neustar.biz 636 Brian Rosen: br@brianrosen.net 638 Henning Schulzrinne: hgs@cs.columbia.edu 640 Barbara Stark: Barbara.Stark@bellsouth.com 642 Martin Thomson: Martin.Thomson@andrew.com 644 Hannes Tschofenig: Hannes.Tschofenig@siemens.com 646 James Winterbottom: James.Winterbottom@andrew.com 648 10. Acknowledgements 650 We would like to thank the IETF GEOPRIV working group chairs, Andy 651 Newton, Allison Mankin and Randall Gellens, for creating this design 652 team. Furthermore, we would like thank Andy Newton for his support 653 during the design team mailing list, for setting up Jabber chat 654 conferences and for participating in the phone conference 655 discussions. 657 We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin 658 Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, 659 Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, 660 Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara 661 Stark, Michael Haberler for their WGLC review comments. 663 11. References 665 11.1. Normative References 667 [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 668 Polk, "Geopriv Requirements", RFC 3693, February 2004. 670 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 671 Levels", RFC 2119, BCP 14, March 1997. 673 [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 674 Context Resolution with Internet Technologies", 675 draft-ietf-ecrit-requirements-13 (work in progress), 676 March 2007. 678 11.2. Informative References 680 [4] Marshall, R., "Requirements for a Location-by-Reference 681 Mechanism used in Location Configuration and Conveyance", 682 draft-marshall-geopriv-lbyr-requirements-01 (work in progress), 683 March 2007. 685 [5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 686 - Simple Traversal of User Datagram Protocol (UDP) Through 687 Network Address Translators (NATs)", RFC 3489, March 2003. 689 [6] Aboba, B., "Link-local Multicast Name Resolution (LLMNR)", 690 draft-ietf-dnsext-mdns-47 (work in progress), August 2006. 692 [7] Cheshire, S. and M. Krochmal, "Multicast DNS", 693 draft-cheshire-dnsext-multicastdns-06 (work in progress), 694 August 2006. 696 [8] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07 697 (work in progress), February 2007. 699 [9] Aura, T., "Cryptographically Generated Addresses (CGA)", 700 RFC 3972, March 2005. 702 [10] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 703 Access Identifier", RFC 4282, December 2005. 705 [11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 706 Authentication Dial In User Service (RADIUS)", RFC 2865, 707 June 2000. 709 [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 710 "Diameter Base Protocol", RFC 3588, September 2003. 712 [13] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers 713 for Dynamic Host Configuration Protocol Version Four (DHCPv4)", 714 RFC 4361, February 2006. 716 [14] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 717 (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in progress), 718 March 2007. 720 [15] Peterson, J., "A Presence-based GEOPRIV Location Object 721 Format", RFC 4119, December 2005. 723 [16] Hardie, T., "LoST: A Location-to-Service Translation Protocol", 724 draft-ietf-ecrit-lost-05 (work in progress), March 2007. 726 [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated 727 Identity Management in the Session Initiation Protocol (SIP)", 728 draft-ietf-sip-identity-06 (work in progress), October 2005. 730 [18] Peterson, J. and C. Jennings, "Enhancements for Authenticated 731 Identity Management in the Session Initiation Protocol (SIP)", 732 RFC 4474, August 2006. 734 Authors' Addresses 736 Hannes Tschofenig 737 Nokia Siemens Networks 738 Otto-Hahn-Ring 6 739 Munich, Bavaria 81739 740 Germany 742 Phone: +49 89 636 40390 743 Email: Hannes.Tschofenig@siemens.com 744 URI: http://www.tschofenig.com 746 Henning Schulzrinne 747 Columbia University 748 Department of Computer Science 749 450 Computer Science Building 750 New York, NY 10027 751 US 753 Phone: +1 212 939 7004 754 Email: hgs+ecrit@cs.columbia.edu 755 URI: http://www.cs.columbia.edu 757 Full Copyright Statement 759 Copyright (C) The IETF Trust (2007). 761 This document is subject to the rights, licenses and restrictions 762 contained in BCP 78, and except as set forth therein, the authors 763 retain all their rights. 765 This document and the information contained herein are provided on an 766 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 767 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 768 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 769 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 770 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 771 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 773 Intellectual Property 775 The IETF takes no position regarding the validity or scope of any 776 Intellectual Property Rights or other rights that might be claimed to 777 pertain to the implementation or use of the technology described in 778 this document or the extent to which any license under such rights 779 might or might not be available; nor does it represent that it has 780 made any independent effort to identify any such rights. Information 781 on the procedures with respect to rights in RFC documents can be 782 found in BCP 78 and BCP 79. 784 Copies of IPR disclosures made to the IETF Secretariat and any 785 assurances of licenses to be made available, or the result of an 786 attempt made to obtain a general license or permission for the use of 787 such proprietary rights by implementers or users of this 788 specification can be obtained from the IETF on-line IPR repository at 789 http://www.ietf.org/ipr. 791 The IETF invites any interested party to bring to its attention any 792 copyrights, patents or patent applications, or other proprietary 793 rights that may cover technology that may be required to implement 794 this standard. Please address the information to the IETF at 795 ietf-ipr@ietf.org. 797 Acknowledgment 799 Funding for the RFC Editor function is provided by the IETF 800 Administrative Support Activity (IASA).