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