idnits 2.17.1 draft-ietf-geopriv-l7-lcp-ps-04.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 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 778. 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 (August 26, 2007) is 6085 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-winterbottom-geopriv-lis2lis-req-00 -- 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 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-08 -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. '11') (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '13') (Obsoleted by RFC 6733) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-15 == Outdated reference: A later version (-05) exists of draft-barnes-geopriv-lo-sec-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 10 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: February 27, 2008 Columbia U. 6 August 26, 2007 8 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and 9 Requirements 10 draft-ietf-geopriv-l7-lcp-ps-04.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 February 27, 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 access network. Several procedures have been 348 investigated that aim to discover the LIS in such an access network. 350 DHCP-based Discovery: 352 In some environments the Dynamic Host Configuration Protocol 353 (DHCP) might be a good choice for discovering the FQDN or the IP 354 address of the LIS. In environments where DHCP can be used it is 355 also possible to use the already defined location extensions. In 356 environments with legacy devices, such as the one shown in 357 Section 3.1, a DHCP based discovery solution may not be possible. 359 DNS-based Discovery: 361 With this idea the end host obtains its public IP address (e.g., 362 via STUN [6]) in order to obtain its domain name (via the usual 363 reverse DNS lookup). Then, the SRV or NAPTR record for that 364 domain is retrieved. This relies on the user's public IP address 365 having a DNS entry. 367 Redirect Rule: 369 A redirect rule at a device in the access network, for example at 370 the AAA client, will be used to redirect the L7 LCP signalling 371 messages (destined to a specific port) to the LIS. The end host 372 could then discover the LIS by sending a packet to almost any 373 address (as long it is not in the user's home network behind a 374 NAT). The packet would be redirected to the respective LIS being 375 configured. The same procedure is used by captive portals whereby 376 any HTTP traffic is intercepted and redirected. 378 Multicast Query: 380 An end node could also discover a LIS by sending a multicast 381 request to a well-known address. An example of such a mechanism 382 is multicast DNS (see [7] and [8]). 384 The LIS discovery procedure raises deployment and security issues. 385 When an end host discovers a LIS it must be ensured that 386 1. it does not talk to a man-in-the-middle, and 388 2. that the discovered entity is indeed an authorized LIS. 390 5. Identifier for Location Determination 392 The LIS returns location information to the end host when it receives 393 a request. Some form of identifier is therefore needed to allow the 394 LIS to retrieve the Target's current location (or a good 395 approximation of it) from a database. 397 The chosen identifier needs to have the following properties: 399 Ability for Target to learn or know the identifier: 401 The Target MUST know or MUST be able to learn the identifier 402 (explicitly or implicitly) in order to send it to the LIS. 403 Implicitly refers to the situation where a device along the path 404 between the end host and the LIS modifies the identifier, as it is 405 done by a NAT when an IP address based identifier is used. 407 Ability to use the identifier for location determination: 409 The LIS MUST be able to use the identifier (directly or 410 indirectly) for location determination. Indirectly refers to the 411 case where the LIS uses other identifiers internally for location 412 determination, in addition to the one provided by the Target. 414 Security properties of the identifier: 416 Misuse needs to be minimized whereby off-path adversary MUST NOT 417 be able to obtain location information of other Targets. A on- 418 path adversary in the same subnet SHOULD NOT be able to spoof the 419 identifier of another Target in the same subnet. 421 The following list discusses frequently mentioned identifiers and 422 their properties: 424 Host MAC Address: 426 The Target's MAC address is known to the end host, but not carried 427 over an IP hop and therefore not accessible to the LIS in most 428 deployment environments (unless carried in the L7 LCP itself). 430 ATM VCI/VPI: 432 The VPI/VCI is generally only seen by the DSL modem. Almost all 433 routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35. 434 This VC is terminated at the DSLAM, which uses a different VPI/VCI 435 (per end customer) to connect to the ATM switch. Only the network 436 provider is able to map VPI/VCI values through its network. With 437 the arrival of VDSL, ATM will slowly be phased out in favor of 438 Ethernet. 440 Switch/Port Number: 442 This identifier is available only in certain networks, such as 443 enterprise networks, typically available via proprietary protocols 444 like CDP or, in the future, 802.1ab. 446 Cell ID: 448 This identifier is available in cellular data networks and the 449 cell ID may not be visible to the end host. 451 Host Identifier: 453 The Host Identifier introduced by the Host Identity Protocol [9] 454 allows identification of a particular host. Unfortunately, the 455 network can only use this identifier for location determination if 456 the operator already stores an mapping of host identities to 457 location information. Furthermore, there is a deployment problem 458 since the host identities are not used in todays networks. 460 Cryptographically Generated Address (CGA): 462 The concept of a Cryptographically Generated Address (CGA) was 463 introduced by [10]. The basic idea is to put the truncated hash 464 of a public key into the interface identifier part of an IPv6 465 address. In addition to the properties of an IP address it allows 466 a proof of ownership. Hence, a return routability check can be 467 omitted. It is only available for IPv6 addresses. 469 Network Access Identifiers: 471 A Network Access Identifier [11] is used during the network access 472 authentication procedure, for example in RADIUS [12] and Diameter 473 [13]. In DSL networks the user credentials are, in many cases, 474 only known by the home router and not configured at the Target 475 itself. To the network, the authenticated user identity is only 476 available if a network access authentication procedure is 477 executed. In case of roaming the user's identity might not be 478 available to the access network since security protocols might 479 offer user identity confidentiality and thereby hiding the real 480 identity of the user allowing the access network to only see a 481 pseudonym or a randomized string. 483 Unique Client Identifier 485 The DSL Forum has defined that all devices that expect to be 486 managed by the TR-069 interface be able to generate an identifier 487 as described in Section 3.4.4 of the TR-069v2 DSL Forum document. 488 It also has a requirement that routers that use DHCP to the WAN 489 use RFC 4361 [14] to provide the DHCP server with a unique client 490 identifier. This identifier is, however, not visible to the 491 Target when legacy NTE device are used. 493 IP Address: 495 The Target's IP address may be used for location determination. 496 This IP address is not visible to the LIS if the end host is 497 behind one or multiple NATs. This may not be a problem since the 498 location of a host that is located behind a NAT cannot be 499 determined by the access network. The LIS would in this case only 500 see the public IP address of the NAT binding allocated by the NAT, 501 which is the expected behavior. The property of the IP address 502 for a return routability check is attractive to return location 503 information only to the address that submitted the request. If an 504 adversary wants to learn the location of a Target (as identified 505 by a particular IP address) then it does not see the response 506 message (unless he is on the subnetwork or at a router along the 507 path towards the LIS). 509 On a shared medium an adversary could ask for location information 510 of another Target. The adversary would be able to see the 511 response message since it is sniffing on the shared medium unless 512 security mechanisms, such as link layer encryption, are in place. 513 With a network deployment as shown in Section 3.1 with multiple 514 hosts in the Customer Premise being behind a NAT the LIS is unable 515 to differentiate the individual end points. For WLAN deployments 516 as found in hotels, as shown in Section 3.3, it is possible for an 517 adversary to eavesdrop data traffic and subsequently to spoof the 518 IP address in a query to the LIS to learn more detailed location 519 information (e.g., specific room numbers). Such an attack might, 520 for example, compromise the privacy of hotel guests. 522 6. Requirements 524 The following requirements and assumptions have been identified: 526 Requirement L7-1: Identifier Choice 528 The L7 LCP MUST be able to carry different identifiers or MUST 529 define an identifier that is mandatory to implement. Regarding 530 the latter aspect, such an identifier is only appropriate if it is 531 from the same realm as the one for which the location information 532 service maintains identifier to location mapping. 534 Requirement L7-2: Mobility Support 536 The L7 LCP MUST support a broad range of mobility from devices 537 that can only move between reboots, to devices that can change 538 attachment points with the impact that their IP address is 539 changed, to devices that do not change their IP address while 540 roaming, to devices that continuously move by being attached to 541 the same network attachment point. 543 Requirement L7-3: ASP and Access Network Provider Relationship 545 The design of the L7 LCP MUST NOT assume a business or trust 546 relationship between the Application Service Provider (ASP) and 547 the Access Network Provider. Requirements for resolving a 548 reference to location information are not discussed in this 549 document. 551 Requirement L7-4: Layer 2 and Layer 3 Provider Relationship 553 The design of the L7 LCP MUST assume that there is a trust and 554 business relationship between the L2 and the L3 provider. The L3 555 provider operates the LIS and needs to obtain location information 556 from the L2 provider since this one is closest to the end host. 557 If the L2 and L3 provider for the same host are different 558 entities, they cooperate for the purposes needed to determine end 559 system locations. 561 Requirement L7-5: Legacy Device Considerations 563 The design of the L7 LCP MUST consider legacy devices, such as 564 residential NAT devices and NTEs in an DSL environment, that 565 cannot be upgraded to support additional protocols, for example, 566 to pass additional information towards the Target. 568 Requirement L7-6: VPN Awareness 570 The design of the L7 LCP MUST assume that at least one end of a 571 VPN is aware of the VPN functionality. In an enterprise scenario, 572 the enterprise side will provide the LIS used by the client and 573 can thereby detect whether the LIS request was initiated through a 574 VPN tunnel. 576 Requirement L7-7: Network Access Authentication 578 The design of the L7 LCP MUST NOT assume prior network access 579 authentication. 581 Requirement L7-8: Network Topology Unawareness 583 The design of the L7 LCP MUST NOT assume end systems being aware 584 of the access network topology. End systems are, however, able to 585 determine their public IP address(es) via mechanisms, such as STUN 586 [6] or NSIS NATFW NSLP [15] . 588 Requirement L7-9: Discovery Mechanism 590 The L7 LCP MUST define a mandatory-to-implement LIS discovery 591 mechanism. 593 7. Security Considerations 595 This document contains security related requirements. A discussion 596 about security aspects of the HELD protocol when used in the GEOPRIV 597 architecture when applied to certain usage environments, such as 598 emergency services, can be found in [16]. 600 8. IANA Considerations 602 This document does not require actions by IANA. 604 9. Contributors 606 This contribution is a joint effort of the GEOPRIV Layer 7 Location 607 Configuration Requirements Design Team of the IETF GEOPRIV Working 608 Group. The contributors include Henning Schulzrinne, Barbara Stark, 609 Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, 610 Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. 612 We would like to thank the GEOPRIV working group chairs, Andy Newton, 613 Randy Gellens and Allison Mankin, for creating the design team. 615 The design team members can be reached at: 617 Marc Linsner: mlinsner@cisco.com 619 Rohan Mahy: rohan@ekabal.com 621 Andrew Newton: andy@hxr.us 623 Jon Peterson: jon.peterson@neustar.biz 625 Brian Rosen: br@brianrosen.net 627 Henning Schulzrinne: hgs@cs.columbia.edu 629 Barbara Stark: Barbara.Stark@bellsouth.com 631 Martin Thomson: Martin.Thomson@andrew.com 633 Hannes Tschofenig: Hannes.Tschofenig@nsn.com 635 James Winterbottom: James.Winterbottom@andrew.com 637 10. Acknowledgements 639 We would like to thank the IETF GEOPRIV working group chairs, Andy 640 Newton, Allison Mankin and Randall Gellens, for creating this design 641 team. Furthermore, we would like thank Andy Newton for his support 642 during the design team mailing list, for setting up Jabber chat 643 conferences and for participating in the phone conference 644 discussions. 646 We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin 647 Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, 648 Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, 649 Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara 650 Stark, Michael Haberler, and Mary Barnes for their WGLC review 651 comments. 653 11. References 655 11.1. Normative References 657 [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 658 Polk, "Geopriv Requirements", RFC 3693, February 2004. 660 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 661 Levels", RFC 2119, BCP 14, March 1997. 663 [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 664 Context Resolution with Internet Technologies", 665 draft-ietf-ecrit-requirements-13 (work in progress), 666 March 2007. 668 11.2. Informative References 670 [4] Marshall, R., "Requirements for a Location-by-Reference 671 Mechanism used in Location Configuration and Conveyance", 672 draft-marshall-geopriv-lbyr-requirements-02 (work in progress), 673 July 2007. 675 [5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 676 Requirements", draft-winterbottom-geopriv-lis2lis-req-00 (work 677 in progress), June 2007. 679 [6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 680 - Simple Traversal of User Datagram Protocol (UDP) Through 681 Network Address Translators (NATs)", RFC 3489, March 2003. 683 [7] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast 684 Name Resolution (LLMNR)", RFC 4795, January 2007. 686 [8] Cheshire, S. and M. Krochmal, "Multicast DNS", 687 draft-cheshire-dnsext-multicastdns-06 (work in progress), 688 August 2006. 690 [9] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08 691 (work in progress), June 2007. 693 [10] Aura, T., "Cryptographically Generated Addresses (CGA)", 694 RFC 3972, March 2005. 696 [11] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 697 Access Identifier", RFC 4282, December 2005. 699 [12] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 700 Authentication Dial In User Service (RADIUS)", RFC 2865, 701 June 2000. 703 [13] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 704 "Diameter Base Protocol", RFC 3588, September 2003. 706 [14] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers 707 for Dynamic Host Configuration Protocol Version Four (DHCPv4)", 708 RFC 4361, February 2006. 710 [15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 711 (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in progress), 712 July 2007. 714 [16] Barnes, R., "Threats to GEOPRIV Location Objects", 715 draft-barnes-geopriv-lo-sec-00 (work in progress), July 2007. 717 Authors' Addresses 719 Hannes Tschofenig 720 Nokia Siemens Networks 721 Otto-Hahn-Ring 6 722 Munich, Bavaria 81739 723 Germany 725 Phone: +49 89 636 40390 726 Email: Hannes.Tschofenig@nsn.com 727 URI: http://www.tschofenig.com 729 Henning Schulzrinne 730 Columbia University 731 Department of Computer Science 732 450 Computer Science Building 733 New York, NY 10027 734 US 736 Phone: +1 212 939 7004 737 Email: hgs+ecrit@cs.columbia.edu 738 URI: http://www.cs.columbia.edu 740 Full Copyright Statement 742 Copyright (C) The IETF Trust (2007). 744 This document is subject to the rights, licenses and restrictions 745 contained in BCP 78, and except as set forth therein, the authors 746 retain all their rights. 748 This document and the information contained herein are provided on an 749 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 750 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 751 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 752 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 753 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 754 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 756 Intellectual Property 758 The IETF takes no position regarding the validity or scope of any 759 Intellectual Property Rights or other rights that might be claimed to 760 pertain to the implementation or use of the technology described in 761 this document or the extent to which any license under such rights 762 might or might not be available; nor does it represent that it has 763 made any independent effort to identify any such rights. Information 764 on the procedures with respect to rights in RFC documents can be 765 found in BCP 78 and BCP 79. 767 Copies of IPR disclosures made to the IETF Secretariat and any 768 assurances of licenses to be made available, or the result of an 769 attempt made to obtain a general license or permission for the use of 770 such proprietary rights by implementers or users of this 771 specification can be obtained from the IETF on-line IPR repository at 772 http://www.ietf.org/ipr. 774 The IETF invites any interested party to bring to its attention any 775 copyrights, patents or patent applications, or other proprietary 776 rights that may cover technology that may be required to implement 777 this standard. Please address the information to the IETF at 778 ietf-ipr@ietf.org. 780 Acknowledgment 782 Funding for the RFC Editor function is provided by the IETF 783 Administrative Support Activity (IASA).