idnits 2.17.1 draft-ietf-geopriv-l7-lcp-ps-03.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 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 774. 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 (July 9, 2007) is 6135 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '15' is defined on line 699, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 702, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 705, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 709, 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-08 -- 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: January 10, 2008 Columbia U. 6 July 9, 2007 8 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and 9 Requirements 10 draft-ietf-geopriv-l7-lcp-ps-03.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 January 10, 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 Configuration Server (LCS) that is located in the access network. 48 The 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 Configuration 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 Configuration Server (LCS). 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) acting as the LCP 96 client and the Location Configuration Server acting as an LCP server. 98 This document is structured as follows. Section 4 discusses the 99 challenge of discovering the LCS in the access network. Section 5 100 compares different types of identifiers that can be used to retrieve 101 location information. A list of requirements for the L7 LCP can be 102 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 or 107 certain deployment environments. 109 2. Terminology 111 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 112 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 113 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], 114 with the qualification that unless otherwise stated these words apply 115 to the design of the GEOPRIV Layer 7 Location Configuration Protocol. 117 The term Location Configuration Server (LCS) refers to an entity 118 capable of determining the location of an end point and of providing 119 that location information, a reference to it, or both via the 120 Location Configuration Protocol (LCP) to the requesting party, in 121 most cases to the end point itself (or to an authorized entity that 122 acts on behalf of it). 124 This document also uses terminology from [1] and [3]. 126 3. Scenarios 128 This section describes a few network scenarios where the L7 LCP may 129 be used. Note that this section does not aim to exhaustively list 130 all possible deployment environments. Instead we focus on the 131 following environments: 133 o DSL/Cable networks, WiMax-like fixed access 135 o Airport, City, Campus Wireless Networks, such as 802.11a/b/g, 136 802.16e/Wimax 138 o 3G networks 140 o Enterprise networks 142 We illustrate a few examples below. 144 3.1. Fixed Wired Environment 146 Figure 1 shows a DSL network scenario with the Access Network 147 Provider and the customer premises. The Access Network Provider 148 operates link and network layer devices (represented as Node) and the 149 LCS. 151 +---------------------------+ 152 | | 153 | Access Network Provider | 154 | | 155 | +--------+ | 156 | | Node | | 157 | +--------+ +----------+ | 158 | | | | LCS | | 159 | | +---| | | 160 | | +----------+ | 161 | | | 162 +-------+-------------------+ 163 | Wired Network 164 <----------------> Access Network Provider demarc 165 | 166 +-------+-------------------+ 167 | | | 168 | +-------------+ | 169 | | NTE | | 170 | +-------------+ | 171 | | | 172 | | | 173 | +--------------+ | 174 | | Device with | Home | 175 | | NAPT and | Router | 176 | | DHCP server | | 177 | +--------------+ | 178 | | | 179 | | | 180 | +------+ | 181 | | End | | 182 | | Host | | 183 | +------+ | 184 | | 185 |Customer Premises Network | 186 | | 187 +---------------------------+ 189 Figure 1: DSL Scenario 191 The customer premises consists of a router with a Network Address 192 Translator with Port Address Translation (NAPT) and a DHCP server as 193 used in most Customer Premises Networks (CPN) and the Network 194 Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 195 protocols are terminated. The router in the home network (e.g., 196 broadband router, cable or DSL router) typically runs a NAPT and a 197 DHCP server. The NTE is a legacy device and in many cases cannot be 198 modified for the purpose of delivering location information to the 199 end host. The same is true of the device with the NAPT and DHCP 200 server. 202 It is possible for the NTE and the home router to physically be in 203 the same box, or for there to be no home router, or for the NTE and 204 end host to be in the same physical box (with no home router). An 205 example of this last case is where Ethernet service is delivered to 206 customers' homes, and the Ethernet NIC in their PC serves as the NTE. 208 Current Customer Premises Network (CPN) deployments frequently show 209 the following characteristics: 211 1. CPE = Single PC 213 1. with Ethernet NIC (PPPoE or DHCP on PC); there may be a 214 bridged DSL or cable modem as NTE, or the Ethernet NIC might 215 be the NTE 217 2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC] 219 Note that the device with NAPT and DHCP of Figure 1 is not 220 present in such a scenario. 222 2. One or more hosts with at least one router (DHCP Client or PPPoE, 223 DHCP server in router; VoIP can be soft client on PC, stand-alone 224 VoIP device, or Analog Terminal Adaptor (ATA) function embedded 225 in router) 227 1. combined router and NTE 229 2. separate router with NTE in bridged mode 231 3. separate router with NTE (NTE/router does PPPoE or DHCP to 232 WAN, router provides DHCP server for hosts in LAN; double 233 NAT) 235 The majority of fixed access broadband customers use a router. The 236 placement of the VoIP client is mentioned to describe what sorts of 237 hosts may need to be able to request location information. Soft 238 clients on PCs are frequently not launched until long after bootstrap 239 is complete, and are not able to control any options that may be 240 specified during bootstrap. They also cannot control whether a VPN 241 client is running on the end host. 243 3.2. Moving Network 245 An example of a moving network is a "WIMAX-like fixed wireless" 246 scenario that is offered in several cities, like New Orleans, Biloxi, 247 etc., where much of the communications infrastructure was destroyed 248 due to a natural disaster. The customer-side antenna for this 249 service is rather small (about the size of a mass market paperback 250 book) and can be run off battery power. The output of this little 251 antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this 252 Ethernet jack. The user would then run a PPPoE client to connect to 253 the network. Once the network connection is established, the user 254 can run a SIP client on the laptop. 256 The network-side antenna is, for example, connected through ATM to 257 the core network, and from there to the same BRASs that serve regular 258 DSL customers. These Broadband Remote Access Servers (BRASs) 259 terminate the PPPoE sessions, just like they do for regular DSL. 261 The laptop and SIP client are, in this case, unaware that they are 262 "mobile". All they see is an Ethernet connection, and the IP address 263 they get from PPPoE does not change over the coverage area. Only the 264 user and the network are aware of the laptop's mobility. 266 Further examples of moving networks can be found in busses, trains, 267 and airplanes. 269 Figure 2 shows an example topology for a moving network. 271 +--------------------------+ 272 | Wireless | 273 | Access Network Provider | 274 | | 275 | +----------+| 276 | +-------+ LCS || 277 | | | || 278 | +---+----+ +----------+| 279 | | Node | | 280 | | | | 281 | +---+----+ | 282 | | | 283 +------+-------------------+ 284 | Wireless Interface 285 | 286 +------+-------------------+ 287 | | Moving Network | 288 | +---+----+ | 289 | | NTE | +--------+ | 290 | | +---+ Host | | 291 | +-+-----++ | B | | 292 | | \ +--------+ | 293 | | \ | 294 |+---+----+ \ +---+----+ | 295 || Host | \ | Host | | 296 || A | \+ B | | 297 |+--------+ +--------+ | 298 +--------------------------+ 300 Figure 2: Moving Network 302 3.3. Wireless Access 304 Figure 3 shows a wireless access network where a moving end host 305 obtains location information or references to location information 306 from the LCS. The access equipment uses, in many cases, link layer 307 devices. Figure 3 represents a hotspot network found, for example, 308 in hotels, airports, and coffee shops. For editorial reasons we only 309 describe a single access point and do not depict how the LCS obtains 310 location information since this is very deployment specific. 312 +--------------------------+ 313 | Access Network Provider | 314 | | 315 | +----------+| 316 | +-------| LCS || 317 | | | || 318 | +--------+ +----------+| 319 | | Access | | 320 | | Point | | 321 | +--------+ | 322 | | | 323 +------+-------------------+ 324 | 325 +------+ 326 | End | 327 | Host | 328 +------+ 330 Figure 3: Wireless Access Scenario 332 4. Discovery of the Location Configuration Server 334 When a Target wants to retrieve location information from the LCS it 335 first needs to discover it. Based on the problem statement of 336 determining the location of the Target, which is known best by 337 entities close to the Target itself, we assume that the LCS is 338 located in the access network. Several procedures have been 339 investigated that aim to discover the LCS in such an access network. 341 DHCP-based Discovery: 343 In some environments the Dynamic Host Configuration Protocol 344 (DHCP) might be a good choice for discovering the FQDN or the IP 345 address of the LCS. In environments where DHCP can be used it is 346 also possible to use the already defined location extensions. In 347 environments with legacy devices, such as the one shown in 348 Section 3.1, a DHCP based discovery solution may not be possible. 350 DNS-based Discovery: 352 With this idea the end host obtains its public IP address (e.g., 353 via STUN [5]) in order to obtain its domain name (via the usual 354 reverse DNS lookup). Then, the SRV or NAPTR record for that 355 domain is retrieved. This relies on the user's public IP address 356 having a DNS entry. 358 Redirect Rule: 360 A redirect rule at a device in the access network, for example at 361 the AAA client, will be used to redirect the L7 LCP signalling 362 messages (destined to a specific port) to the LCS. The end host 363 could then discover the LCS by sending a packet to almost any 364 address (as long it is not in the user's home network behind a 365 NAT). The packet would be redirected to the respective LCS being 366 configured. The same procedure is used by captive portals whereby 367 any HTTP traffic is intercepted and redirected. 369 Multicast Query: 371 An end node could also discover a LCS by sending a multicast 372 request to a well-known address. An example of such a mechanism 373 is multicast DNS (see [6] and [7]). 375 The LCS discovery procedure raises deployment and security issues. 376 When an end host discovers a LCS it must be ensured that 377 1. it does not talk to a man-in-the-middle, and 379 2. that the discovered entity is indeed an authorized LCS. 381 5. Identifier for Location Determination 383 The LCS returns location information to the end host when it receives 384 a request. Some form of identifier is therefore needed to allow the 385 LCS to retrieve the Target's current location (or a good 386 approximation of it) from a database. 388 The chosen identifier needs to have the following properties: 390 Ability for Target to learn or know the identifier: 392 The Target MUST know or MUST be able to learn the identifier 393 (explicitly or implicitly) in order to send it to the LCS. 394 Implicitly refers to the situation where a device along the path 395 between the end host and the LCS modifies the identifier, as it is 396 done by a NAT when an IP address based identifier is used. 398 Ability to use the identifier for location determination: 400 The LCS MUST be able to use the identifier (directly or 401 indirectly) for location determination. Indirectly refers to the 402 case where the LCS uses other identifiers internally for location 403 determination, in addition to the one provided by the Target. 405 Security properties of the identifier: 407 Misuse needs to be minimized whereby off-path adversary MUST NOT 408 be able to obtain location information of other Targets. A on- 409 path adversary in the same subnet SHOULD NOT be able to spoof the 410 identifier of another Target in the same subnet. 412 The following list discusses frequently mentioned identifiers and 413 their properties: 415 Host MAC Address: 417 The Target's MAC address is known to the end host, but not carried 418 over an IP hop and therefore not accessible to the LCS in most 419 deployment environments (unless carried in the L7 LCP itself). 421 ATM VCI/VPI: 423 The VPI/VCI is generally only seen by the DSL modem. Almost all 424 routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35. 425 This VC is terminated at the DSLAM, which uses a different VPI/VCI 426 (per end customer) to connect to the ATM switch. Only the network 427 provider is able to map VPI/VCI values through its network. With 428 the arrival of VDSL, ATM will slowly be phased out in favor of 429 Ethernet. 431 Switch/Port Number: 433 This identifier is available only in certain networks, such as 434 enterprise networks, typically available via proprietary protocols 435 like CDP or, in the future, 802.1ab. 437 Cell ID: 439 This identifier is available in cellular data networks and the 440 cell ID may not be visible to the end host. 442 Host Identifier: 444 The Host Identifier introduced by the Host Identity Protocol [8] 445 allows identification of a particular host. Unfortunately, the 446 network can only use this identifier for location determination if 447 the operator already stores an mapping of host identities to 448 location information. Furthermore, there is a deployment problem 449 since the host identities are not used in todays networks. 451 Cryptographically Generated Address (CGA): 453 The concept of a Cryptographically Generated Address (CGA) was 454 introduced by [9]. The basic idea is to put the truncated hash of 455 a public key into the interface identifier part of an IPv6 456 address. In addition to the properties of an IP address it allows 457 a proof of ownership. Hence, a return routability check can be 458 omitted. It is only available for IPv6 addresses. 460 Network Access Identifiers: 462 A Network Access Identifier [10] is used during the network access 463 authentication procedure, for example in RADIUS [11] and Diameter 464 [12]. In DSL networks the user credentials are, in many cases, 465 only known by the home router and not configured at the Target 466 itself. To the network, the authenticated user identity is only 467 available if a network access authentication procedure is 468 executed. In case of roaming the user's identity might not be 469 available to the access network since security protocols might 470 offer user identity confidentiality and thereby hiding the real 471 identity of the user allowing the access network to only see a 472 pseudonym or a randomized string. 474 Unique Client Identifier 476 The DSL Forum has defined that all devices that expect to be 477 managed by the TR-069 interface be able to generate an identifier 478 as described in Section 3.4.4 of the TR-069v2 DSL Forum document. 479 It also has a requirement that routers that use DHCP to the WAN 480 use RFC 4361 [13] to provide the DHCP server with a unique client 481 identifier. This identifier is, however, not visible to the 482 Target when legacy NTE device are used. 484 IP Address: 486 The Target's IP address may be used for location determination. 487 This IP address is not visible to the LCS if the end host is 488 behind one or multiple NATs. This may not be a problem since the 489 location of a host that is located behind a NAT cannot be 490 determined by the access network. The LCS would in this case only 491 see the public IP address of the NAT binding allocated by the NAT, 492 which is the expected behavior. The property of the IP address 493 for a return routability check is attractive to return location 494 information only to the address that submitted the request. If an 495 adversary wants to learn the location of a Target (as identified 496 by a particular IP address) then it does not see the response 497 message (unless he is on the subnetwork or at a router along the 498 path towards the LCS). 500 On a shared medium an adversary could ask for location information 501 of another Target. The adversary would be able to see the 502 response message since it is sniffing on the shared medium unless 503 security mechanisms, such as link layer encryption, are in place. 504 With a network deployment as shown in Section 3.1 with multiple 505 hosts in the Customer Premise being behind a NAT the LCS is unable 506 to differentiate the individual end points. For WLAN deployments 507 as found in hotels, as shown in Section 3.3, it is possible for an 508 adversary to eavesdrop data traffic and subsequently to spoof the 509 IP address in a query to the LCS to learn more detailed location 510 information (e.g., specific room numbers). Such an attack might, 511 for example, compromise the privacy of hotel guests. 513 6. Requirements 515 The following requirements and assumptions have been identified: 517 Requirement L7-1: Identifier Choice 519 The L7 LCP MUST be able to carry different identifiers or MUST 520 define an identifier that is mandatory to implement. Regarding 521 the latter aspect, such an identifier is only appropriate if it is 522 from the same realm as the one for which the location information 523 service maintains identifier to location mapping. 525 Requirement L7-2: Mobility Support 527 The L7 LCP MUST support a broad range of mobility from devices 528 that can only move between reboots, to devices that can change 529 attachment points with the impact that their IP address is 530 changed, to devices that do not change their IP address while 531 roaming, to devices that continuously move by being attached to 532 the same network attachment point. 534 Requirement L7-3: Layer 7 and Layer 2/3 Provider Relationship 536 The design of the L7 LCP MUST NOT assume a business or trust 537 relationship between the VSP and the ISP/ASP. Requirements for 538 resolving a reference to location information are not discussed in 539 this document. 541 Requirement L7-4: Layer 2 and Layer 3 Provider Relationship 543 The design of the L7 LCP MUST assume that there is a trust and 544 business relationship between the L2 and the L3 provider. The L3 545 provider operates the LCS and needs to obtain location information 546 from the L2 provider since this one is closest to the end host. 547 If the L2 and L3 provider for the same host are different 548 entities, they cooperate for the purposes needed to determine end 549 system locations. 551 Requirement L7-5: Legacy Device Considerations 553 The design of the L7 LCP MUST consider legacy devices, such as 554 residential NAT devices and NTEs in an DSL environment, that 555 cannot be upgraded to support additional protocols, for example, 556 to pass additional information towards the Target. 558 Requirement L7-6: VPN Awareness 560 The design of the L7 LCP MUST assume that at least one end of a 561 VPN is aware of the VPN functionality. In an enterprise scenario, 562 the enterprise side will provide the LCS used by the client and 563 can thereby detect whether the LCS request was initiated through a 564 VPN tunnel. 566 Requirement L7-7: Network Access Authentication 568 The design of the L7 LCP MUST NOT assume prior network access 569 authentication. 571 Requirement L7-8: Network Topology Unawareness 573 The design of the L7 LCP MUST NOT assume end systems being aware 574 of the access network topology. End systems are, however, able to 575 determine their public IP address(es) via mechanisms, such as STUN 576 [5] or NSIS NATFW NSLP [14] . 578 Requirement L7-9: Discovery Mechanism 580 The L7 LCP MUST define a mandatory-to-implement LCS discovery 581 mechanism. 583 7. Security Considerations 585 A discussion about security aspects can be found in another document. 586 [Editor's Note: The security related content was previously in this 587 document and will be published in a separate document soon.] 589 8. IANA Considerations 591 This document does not require actions by IANA. 593 9. Contributors 595 This contribution is a joint effort of the GEOPRIV Layer 7 Location 596 Configuration Requirements Design Team of the IETF GEOPRIV Working 597 Group. The contributors include Henning Schulzrinne, Barbara Stark, 598 Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, 599 Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. 601 We would like to thank the GEOPRIV working group chairs, Andy Newton, 602 Randy Gellens and Allison Mankin, for creating the design team. 604 The design team members can be reached at: 606 Marc Linsner: mlinsner@cisco.com 608 Rohan Mahy: rohan@ekabal.com 610 Andrew Newton: andy@hxr.us 612 Jon Peterson: jon.peterson@neustar.biz 614 Brian Rosen: br@brianrosen.net 616 Henning Schulzrinne: hgs@cs.columbia.edu 618 Barbara Stark: Barbara.Stark@bellsouth.com 620 Martin Thomson: Martin.Thomson@andrew.com 622 Hannes Tschofenig: Hannes.Tschofenig@siemens.com 624 James Winterbottom: James.Winterbottom@andrew.com 626 10. Acknowledgements 628 We would like to thank the IETF GEOPRIV working group chairs, Andy 629 Newton, Allison Mankin and Randall Gellens, for creating this design 630 team. Furthermore, we would like thank Andy Newton for his support 631 during the design team mailing list, for setting up Jabber chat 632 conferences and for participating in the phone conference 633 discussions. 635 We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin 636 Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, 637 Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, 638 Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara 639 Stark, Michael Haberler, and Mary Barnes for their WGLC review 640 comments. 642 11. References 644 11.1. Normative References 646 [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 647 Polk, "Geopriv Requirements", RFC 3693, February 2004. 649 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 650 Levels", RFC 2119, BCP 14, March 1997. 652 [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 653 Context Resolution with Internet Technologies", 654 draft-ietf-ecrit-requirements-13 (work in progress), 655 March 2007. 657 11.2. Informative References 659 [4] Marshall, R., "Requirements for a Location-by-Reference 660 Mechanism used in Location Configuration and Conveyance", 661 draft-marshall-geopriv-lbyr-requirements-01 (work in progress), 662 March 2007. 664 [5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 665 - Simple Traversal of User Datagram Protocol (UDP) Through 666 Network Address Translators (NATs)", RFC 3489, March 2003. 668 [6] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast 669 Name Resolution (LLMNR)", RFC 4795, January 2007. 671 [7] Cheshire, S. and M. Krochmal, "Multicast DNS", 672 draft-cheshire-dnsext-multicastdns-06 (work in progress), 673 August 2006. 675 [8] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08 676 (work in progress), June 2007. 678 [9] Aura, T., "Cryptographically Generated Addresses (CGA)", 679 RFC 3972, March 2005. 681 [10] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 682 Access Identifier", RFC 4282, December 2005. 684 [11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 685 Authentication Dial In User Service (RADIUS)", RFC 2865, 686 June 2000. 688 [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 689 "Diameter Base Protocol", RFC 3588, September 2003. 691 [13] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers 692 for Dynamic Host Configuration Protocol Version Four (DHCPv4)", 693 RFC 4361, February 2006. 695 [14] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 696 (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in progress), 697 March 2007. 699 [15] Peterson, J., "A Presence-based GEOPRIV Location Object 700 Format", RFC 4119, December 2005. 702 [16] Hardie, T., "LoST: A Location-to-Service Translation Protocol", 703 draft-ietf-ecrit-lost-05 (work in progress), March 2007. 705 [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated 706 Identity Management in the Session Initiation Protocol (SIP)", 707 draft-ietf-sip-identity-06 (work in progress), October 2005. 709 [18] Peterson, J. and C. Jennings, "Enhancements for Authenticated 710 Identity Management in the Session Initiation Protocol (SIP)", 711 RFC 4474, August 2006. 713 Authors' Addresses 715 Hannes Tschofenig 716 Nokia Siemens Networks 717 Otto-Hahn-Ring 6 718 Munich, Bavaria 81739 719 Germany 721 Phone: +49 89 636 40390 722 Email: Hannes.Tschofenig@nsn.com 723 URI: http://www.tschofenig.com 725 Henning Schulzrinne 726 Columbia University 727 Department of Computer Science 728 450 Computer Science Building 729 New York, NY 10027 730 US 732 Phone: +1 212 939 7004 733 Email: hgs+ecrit@cs.columbia.edu 734 URI: http://www.cs.columbia.edu 736 Full Copyright Statement 738 Copyright (C) The IETF Trust (2007). 740 This document is subject to the rights, licenses and restrictions 741 contained in BCP 78, and except as set forth therein, the authors 742 retain all their rights. 744 This document and the information contained herein are provided on an 745 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 746 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 747 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 748 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 749 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 750 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 752 Intellectual Property 754 The IETF takes no position regarding the validity or scope of any 755 Intellectual Property Rights or other rights that might be claimed to 756 pertain to the implementation or use of the technology described in 757 this document or the extent to which any license under such rights 758 might or might not be available; nor does it represent that it has 759 made any independent effort to identify any such rights. Information 760 on the procedures with respect to rights in RFC documents can be 761 found in BCP 78 and BCP 79. 763 Copies of IPR disclosures made to the IETF Secretariat and any 764 assurances of licenses to be made available, or the result of an 765 attempt made to obtain a general license or permission for the use of 766 such proprietary rights by implementers or users of this 767 specification can be obtained from the IETF on-line IPR repository at 768 http://www.ietf.org/ipr. 770 The IETF invites any interested party to bring to its attention any 771 copyrights, patents or patent applications, or other proprietary 772 rights that may cover technology that may be required to implement 773 this standard. Please address the information to the IETF at 774 ietf-ipr@ietf.org. 776 Acknowledgment 778 Funding for the RFC Editor function is provided by the IETF 779 Administrative Support Activity (IASA).