Network Working Group                                      H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status:  Informational                           H. Schulzrinne
Expires:  October 8, 30, 2007                                   Columbia U.
                                                          April 6, 28, 2007

 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
                              Requirements
                  draft-ietf-geopriv-l7-lcp-ps-01.txt
                  draft-ietf-geopriv-l7-lcp-ps-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 8, 30, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document provides a problem statement, lists requirements and
   captures discussions design aspects for a GEOPRIV Geopriv Layer 7 Location Configuration
   Protocol L7 (LCP).  This protocol aims to allow an end host to obtain
   location information, by value or by reference, from a Location
   Configuration Server (LS) (LCS) that is located in the access network.
   The obtained location information can then be used for a variety of
   different protocols and purposes.  For example, it can be used as
   input to the Location-to-Service Translation Protocol (LoST) or to
   convey location within SIP to other entities.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Fixed Wired Environment  . . . . . . . . . . . . . . . . .  5
     3.2.  Moving Network . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Wireless Access  . . . . . . . . . . . . . . . . . . . . .  9
   4.  Discovery of the Location Information Configuration Server . . . . . . . . . 11
   5.  Identifier for Location Determination  . . . . . . . . . . . . 13
   6.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19 18
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20 19
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 20
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 21
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 22
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 22
     11.2. Informative References . . . . . . . . . . . . . . . . . . 23 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 26 25

1.  Introduction

   This document provides a problem statement, lists requirements and
   captures discussions design aspects for a GEOPRIV Geopriv Layer 7 Location Configuration
   Protocol L7 (LCP).  The protocol has two purposes:

   o  It is used to obtain location information (referred as "Location
      by Value" or LbyV) from a special dedicated node, called the Location
      Configuration Server (LS). (LCS).

   o  It enables the end host Target to obtain a reference to location
      information.
      information (referred as "Location by Reference" or LbyR).  This
      reference can take the form of a subscription URI, such as a SIP
      presence URI, an a HTTP/HTTPS URI, or any others. another URI.  The requirements
      related to the task of obtaining such a reference LbyR are described in a
      separate document, see [4].

   The need for these two functions can be derived from the scenarios
   presented in Section 3.

   For this document we assume that the GEOPRIV Layer 7 LCP runs between
   the end host (i.e., the Target in [1] terminology) acting as the LCP
   client and the Location Configuration Server acting as an LCP server.

   This document splits the problem space into separate parts and
   discusses them in separate subsections. is structured as follows.  Section 4 discusses the
   challenge of discovering the Location Information Server LCS in the access network.  Section 5
   compares different types of identifiers that can be used to retrieve
   location information.  A list of requirements for the GEOPRIV Layer 7 Location Configuration Protocol L7 LCP can be
   found in Section 6.

   This document does not describe how the access network provider
   determines the location of the end host since this is largely a
   matter of the capabilities of specific link layer technologies. technologies or
   certain deployment environments.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [2],
   with the qualification that unless otherwise stated these words apply
   to the design of the GEOPRIV Layer 7 Location Configuration Protocol.

   We

   The term Location Configuration Server (LCS) refers to an entity
   capable of determining the location of the Target and of delivering
   that location information, a reference to it, or bot) to the Target
   via the L7 LCP.

   This document also use uses terminology from [1] and [3].

3.  Scenarios

   This section describes a few network scenarios where the GEOPRIV
   Layer 7 Location Configuration Protocol L7 LCP may
   be used.  Note that this section does not aim to exhaustively list
   all possible deployment environments
   exhaustively.  We environments.  Instead we focus on the description of the
   following environments:

   o  DSL/Cable networks, WiMax-like fixed access

   o  Airport, City, Campus Wireless Networks, such as 802.11a/b/g,
      802.16e/Wimax

   o  3G networks

   o  Enterprise networks

   We illustrate a few examples below.

3.1.  Fixed Wired Environment

   The following figure

   Figure 1 shows a DSL network scenario with the Access Network
   Provider and the customer premises.  The Access Network Provider
   operates link and network layer devices (represented as Node) and the Location Server (LS).
   LCS.

   +---------------------------+
   |                           |
   |  Access Network Provider  |
   |                           |
   |   +--------+              |
   |   | Node   |              |
   |   +--------+ +----------+ |
   |       |  |   | LS LCS      | |
   |       |  +---|          | |
   |       |      +----------+ |
   |       |                   |
   +-------+-------------------+
           | Wired Network
   <----------------> Access Network Provider demarc
           |
   +-------+-------------------+
   |       |                   |
   |   +-------------+         |
   |   | NTE         |         |
   |   +-------------+         |
   |       |                   |
   |       |                   |
   |   +--------------+        |
   |   | Device with  | Home   |
   |   | NAPT and     | Router |
   |   | DHCP server  |        |
   |   +--------------+        |
   |       |                   |
   |       |                   |
   |    +------+               |
   |    | End  |               |
   |    | Host |               |
   |    +------+               |
   |                           |
   |Customer Premises Network  |
   |                           |
   +---------------------------+

                          Figure 1: DSL Scenario

   The customer premises consists of a router with a Network Address
   Translator with Port Address Translation (NAPT) and a DHCP server as
   used in most Customer Premises Networks (CPN) and the Network
   Termination Equipment (NTE) where Layer 1 and sometimes Layer 2
   protocols are terminated.  The router in the home network (e.g.,
   broadband router, cable or DSL router) typically runs a NAPT and a
   DHCP server.  The NTE is a legacy device and in many cases cannot be
   modified for the purpose of delivering location information to the
   end host.  The same is true of the device with the NAPT and DHCP
   server.

   It is possible for the NTE and the home router to physically be in
   the same box, or for there to be no home router, or for the NTE and
   end host to be in the same physical box (with no home router).  An
   example of this last case is where Ethernet service is delivered to
   customers' homes, and the Ethernet NIC in their PC serves as the NTE.

   Current Customer Premises Network (CPN) deployments frequently show
   the following characteristics:

   1.  CPE = Single PC

       1.  with Ethernet NIC [PPPoE (PPPoE or DHCP on PC]; PC); there may be a
           bridged DSL or cable modem as NTE, or the Ethernet NIC might
           be the NTE

       2.  with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC]

       Note that the device with NAPT and DHCP of Figure 1 is not
       present in such a scenario.

   2.  One or more hosts with at least one router [DHCP (DHCP Client or PPPoE,
       DHCP server in router; VoIP can be soft client on PC, stand-alone
       VoIP device, or Analog Terminal Adaptor (ATA) function embedded
       in router] router)

       1.  combined router and NTE

       2.  separate router with NTE in bridged mode

       3.  separate router with NTE [NTE/router (NTE/router does PPPoE or DHCP to
           WAN, router provides DHCP server for hosts in LAN; double NAT
           NAT)

   The majority of fixed access broadband customers use a router.  The
   placement of the VoIP client is mentioned to describe what sorts of
   hosts may need to be able to request location information.  Soft
   clients on PCs are frequently not launched until long after bootstrap
   is complete, and are not able to control any options that may be
   specified during bootstrap.  They also cannot control whether a VPN
   client is operating running on the PC. end host.

3.2.  Moving Network

   An example of a moving network is a "WIMAX-like fixed wireless"
   scenario that is offered in several cities, like New Orleans, Biloxi,
   etc., where much of the communications infrastructure was destroyed
   due to a natural disaster.  The customer-side antenna for this
   service is rather small (about the size of a mass market paperback
   book) and can be run off battery power.  The output of this little
   antenna is a RJ-45 Ethernet jack.  A laptop can be plugged into this
   Ethernet jack.  The user would then run a PPPoE client to connect to
   the network.  Once the network connection is established, the user
   can run a SIP client on the laptop.

   The network-side antenna is, for example, connected through ATM to
   the core network, and from there to the same BRASs that serve regular
   DSL customers.  These Broadband Remote Access Servers (BRASs)
   terminate the PPPoE sessions, just like they do for regular DSL.

   The laptop and SIP client are, in this case, unaware that they are
   "mobile".  All they see is an Ethernet connection, and the IP address
   they get from PPPoE does not change over the coverage area.  Only the
   user and the network are aware of the laptop's mobility.

   Further examples of moving networks can be found in busses, trains,
   and airplanes.

   Figure 2 shows an example topology for a moving network.

   +--------------------------+
   | Wireless                 |
   | Access Network Provider  |
   |                          |
   |              +----------+|
   |      +-------+ LS LCS       ||
   |      |       |          ||
   |  +---+----+  +----------+|
   |  | Node   |              |
   |  |        |              |
   |  +---+----+              |
   |      |                   |
   +------+-------------------+
          | Wireless Interface
          |
   +------+-------------------+
   |      |    Moving Network |
   |  +---+----+              |
   |  | NTE    |   +--------+ |
   |  |        +---+ Host   | |
   |  +-+-----++   |  B     | |
   |    |     \    +--------+ |
   |    |      \              |
   |+---+----+  \  +---+----+ |
   || Host   |   \ | Host   | |
   ||  A     |    \+  B     | |
   |+--------+     +--------+ |
   +--------------------------+

                         Figure 2: Moving Network

3.3.  Wireless Access

   Figure 3 shows a wireless access network where a moving end host
   obtains location information or references to location information
   from the LS. LCS.  The access equipment uses, in many cases, link layer
   devices.  This figure  Figure 3 represents a hotspot network found found, for example,
   in hotels, airports, and coffee shops.  For editorial reasons we only
   describe a single access point and do not depict how the LS LCS obtains
   location information since this is very deployment specific.

   +--------------------------+
   | Access Network Provider  |
   |                          |
   |              +----------+|
   |      +-------| LS LC       ||
   |      |       |          ||
   |  +--------+  +----------+|
   |  | Access |              |
   |  | Point  |              |
   |  +--------+              |
   |      |                   |
   +------+-------------------+
          |
        +------+
        | End  |
        | Host |
        +------+

                    Figure 3: Wireless Access Scenario

4.  Discovery of the Location Information Configuration Server

   When an end host a Target wants to retrieve location information from the LS LCS it
   first needs to discover it.  Based on the problem statement of
   determining the location of the end host, Target, which is known best by
   entities close to the end host Target itself, we assume that the LS LCS is
   located in the access network.  Several procedures have been
   investigated that aim to discovery the LS LCS in such an access network.

   DHCP-based Discovery:

      In some environments the Dynamic Host Configuration Protocol
      (DHCP) might be a good choice for discovering the FQDN or the IP
      address of the
      LS. LCS.  In environments where DHCP can be used it is
      also possible to use the already defined location extensions.  In
      environments with legacy devices, such as the one shown in
      Section 3.1, a DHCP based discovery solution is may not be possible.

   DNS-based Discovery:

      With this idea the end host obtains its public IP address (e.g.,
      via STUN [5]) in order to obtain its domain name (via the usual
      reverse DNS lookup).  Then, the SRV or NAPTR record for that
      domain is retrieved.  This relies on the user's public IP address
      having a DNS entry.

   Redirect Rule:

      A redirect rule at a device in the access network, for example at
      the AAA client, will be used to redirect the Geopriv-L7 L7 LCP signalling
      messages (destined to a specific port) to the LS. LCS.  The end host
      could then discover the LS LCS by sending a packet to almost any
      address (as long it is not in the local network). user's home network behind a
      NAT).  The packet would be redirected to the respective LS LCS being
      configured.  The same procedure is used by captive portals whereby
      any HTTP traffic is intercepted and redirected.

   Multicast Query:

      An end node could also discover a LS LCS by sending a multicast
      request to a well-known address.  An example of such a mechanism
      is multicast DNS (see [6] and [7]).

   The LS LCS discovery procedure raises deployment and security issues.
   When an end host discovers a LS, LCS it must be ensured that
   1.  it does not talk to a man-in-the-middle adversary, man-in-the-middle, and

   2.  it needs to ensure  that the discovered entity is indeed an authorized LS. LCS.

5.  Identifier for Location Determination

   The LS LCS returns location information to the end host when it receives
   a request.  Some form of identifier is therefore needed to allow the
   LS
   LCS to determine retrieve the Target's current location of the target or (or a good
   approximation of it. it) from a database.

   The chosen identifier needs to have the following properties:

   Ability for end host Target to learn or know the identifier:

      The end host Target MUST know or MUST be able to learn the identifier
      (explicitly or implicitly) in order to send it to the LS. LCS.
      Implicitly refers to the situation where a device along the path
      between the end host and the LS LCS modifies the identifier, as it is
      done by a NAT when an IP address based identifier is used.

   Ability to use the identifier for location determination:

      The LS LCS MUST be able to use the identifier (directly or
      indirectly) for location determination.  Indirectly refers to the
      case where the LS LCS uses other identifiers locally within the access network, internally for location
      determination, in addition to the one provided by the end host, for location
      determination. Target.

   Security properties of the identifier:

      Misuse needs to be minimized whereby off-path adversary MUST NOT
      be able to obtain location information of other hosts. Targets.  A on-path on-
      path adversary in the same subnet SHOULD NOT be able to spoof the
      identifier of another host Target in the same subnet.

   The problem is further complicated by the requirement that the end
   host should not be aware of the network topology and the LS must be
   placed in such a way that it can determine location information with
   the available information.  As shown in Figure 1 the host behind the
   NTE/NAPT-DHCP device is not visible to the access network and the LS
   itself.  In the DSL network environment some identifier used at the
   NTE is observable for by the LS/access network.

   The following list discusses frequently mentioned identifiers and
   their properties:

   Host MAC address: Address:

      The host Target's MAC address is known to the end system, host, but not carried
      over an IP hop. hop and therefore not accessible to the LCS in most
      deployment environments (unless carried in the L7 LCP itself).

   ATM VCI/VPI:

      The VPI/VCI is generally only seen by the DSL modem.  Almost all
      routers in the US use 1 of 2 VPI/VCI value pairs:  0/35 and 8/35.
      This VC is terminated at the DSLAM, which uses a different VPI/VCI
      (per end customer) to connect to the ATM switch.  Only the network
      provider is able to map VPI/VCI values through its network.  With
      the arrival of VDSL, ATM will slowly be phased out in favor of
      Ethernet.

   Switch/Port Number:

      This identifier is available only in certain networks, such as
      enterprise networks, typically available via proprietary protocols
      like CDP or, in the future, 802.1ab.

   Cell ID:

      This identifier is available in cellular data networks and the
      cell ID might may not be visible to the end host.

   Authenticated User Identity:

      In DSL networks the user credentials are, in many cases, only
      known by the router and not to the end host.  To the network, the
      authenticated user identity is only available if a network access
      authentication procedure is executed.  In case of roaming it still
      might not be available to the access network since security
      protocols might provide user identity confidentiality and thereby
      hide the real identity of the user allowing the access network to
      only see a pseudonym or a randomized string.

   Host Identifier:

      The Host Identifier introduced by the Host Identity Protocol [8]
      allows identification of a particular host.  Unfortunately, the
      network can only use this identifier for location determination if
      the operator already stores an mapping of host identities to
      location information.  Furthermore, there is a deployment problem
      since the host identities are not used in todays networks.

   Cryptographically Generated Address (CGA):

      The concept of a Cryptographically Generated Address (CGA) was
      introduced by [9].  The basic idea is to put the truncated hash of
      a public key into the interface identifier part of an IPv6
      address.  In addition to the properties of an IP address it allows
      a proof of ownership.  Hence, a return routability check can be
      omitted.  It is only available for IPv6 addresses.

   Network Access Identifiers:

      A Network Access Identifier [10] is only used during the network access
      authentication procedure procedure, for example in RADIUS [11] or and Diameter
      [12].
      Furthermore,  In DSL networks the user credentials are, in many cases,
      only known by the home router and not configured at the Target
      itself.  To the network, the authenticated user identity is only
      available if a network access authentication procedure is
      executed.  In case of roaming scenario it does the user's identity might not help be
      available to the access network to make meaningful decisions since the username part security protocols might
      be a pseudonym
      offer user identity confidentiality and there is no relationship to thereby hiding the end host's
      location. real
      identity of the user allowing the access network to only see a
      pseudonym or a randomized string.

   Unique Client Identifier

      The DSL Forum has defined that all devices that expect to be
      managed by the TR-069 interface be able to generate an identifier
      as described in Section 3.4.4 of the TR-069v2 DSL Forum TR-069v2 Section 3.4.4. document.
      It also has a requirement that routers that use DHCP to the WAN
      use RFC 4361 [13] to provide the DHCP server with a unique client
      identifier.  This identifier is, however, not visible to the end host with the
      assumption of a
      Target when legacy NTE device like the NTE.  If we assume that the
      LTE can be modified then a number of solutions come to mind
      including DHCP based location delivery. are used.

   IP Address:

      The end host's Target's IP address may be used for location determination.
      This IP address is not visible to the LS LCS if the end host is
      behind one or multipel multiple NATs.  This is, however, may not be a problem since the
      location of a host that is located behind a NAT cannot be
      determined by the access network.  The LS LCS would in this case only
      see the public IP address of the NAT binding allocated by the NAT,
      which is the correct expected behavior.  The property of the IP address
      for a return routability check is attractive as well to return location
      information only to a device the address that transmitted submitted the request.  The LS receives the request and provides location
      information back to the same IP address.  If an
      adversary wants to learn the location information from an IP address other than its own of a Target (as identified
      by a particular IP address address) then it would does not see the response
      message (unless he is on the subnetwork or at a router along the
      path towards the LS)
      since the LS would return the message to the address where it came
      from. LCS).

      On a shared medium an adversary could ask for location information
      of another host using its IP address. Target.  The adversary would be able to see the
      response message since he it is sniffing on the shared medium unless
      security mechanisms (such as link layer encryption) is in place.
      With a network deployment as shown in Section 3.1 with multiple
      hosts in the Customer Premise being behind a NAT the
      LS LCS is unable
      to differentiate the individual end points.  For WLAN deployments
      as found in hotels, as shown in as shown in Section 3.3, it is possible for an
      adversary to eavesdrop data traffic and subsequently to spoof the
      IP address in a query to the
      LS LCS to learn more detailed location
      information (e.g., specific room numbers).  Such an attack might,
      for example, compromise the privacy of hotel guests.  Note that DHCP would suffer from the
      same problem here unless each node uses link layer security
      mechanism.

      Return routability checks are useful only if the adversary does
      not see the response message and if the goal is to delay state
      establishment.  If the adversary is in a broadcast network then a
      return routability check alone is not sufficient to prevent the
      above attack since the adversary will observe the response.

6.  Requirements

   The following requirements and assumptions have been identified:

   Requirement L7-1: Identifier Choice

      The LS L7 LCP MUST be presented with a unique identifier of its own
      addressing realm associated directly able to carry different identifiers or indirectly (i.e., linked
      through other identifiers) with the physical location of MUST
      define an identifier that is mandatory to implement.  Regarding
      the end
      host.

      An latter aspect, such an identifier is only appropriate if it is
      from the same realm as the one for which the location information
      service maintains identifier to location mapping.

   Requirement L7-2: Mobility Support

      The GEOPRIV Layer 7 Location Configuration Protocol L7 LCP MUST support a broad range of mobility from devices
      that can only move between reboots, to devices that can change
      attachment points with the impact that their IP address is
      changed, to devices that do not change their IP address while
      roaming, to devices that continuously move by being attached to
      the same network attachment point.

   Requirement L7-3: Layer 7 and Layer 2/3 Provider Relationship

      The design of the GEOPRIV Layer 7 Location Configuration Protocol L7 LCP MUST NOT assume a business or trust
      relationship between the
      provider of application layer (e.g., SIP, XMPP, H.323) provider VSP and the access network provider operating the LS. ISP/ASP.  Requirements for
      resolving a reference to location information are not discussed in
      this document.

   Requirement L7-4: Layer 2 and Layer 3 Provider Relationship

      The design of the GEOPRIV Layer 7 Location Configuration Protocol L7 LCP MUST assume that there is a trust and
      business relationship between the L2 and the L3 provider.  The L3
      provider operates the
      LS LCS and needs to obtain location information
      from the L2 provider since this one is closest to the end host.
      If the L2 and L3 provider for the same host are different
      entities, they cooperate for the purposes needed to determine end
      system locations.

   Requirement L7-5: Legacy Device Considerations

      The design of the GEOPRIV Layer 7 Location Configuration Protocol L7 LCP MUST consider legacy devices, such as
      residential NAT devices and NTEs in an DSL
      environment environment, that
      cannot be upgraded to support additional protocols, for example example,
      to pass additional information through
      DHCP. towards the Target.

   Requirement L7-6: VPN Awareness

      The design of the GEOPRIV Layer 7 Location Configuration Protocol L7 LCP MUST assume that at least one end of a
      VPN is aware of the VPN functionality.  In an enterprise scenario,
      the enterprise side will provide the LS LCS used by the client and
      can thereby detect whether the LS LCS request was initiated through a
      VPN tunnel.

   Requirement L7-7: Network Access Authentication

      The design of the GEOPRIV Layer 7 Location Configuration Protocol L7 LCP MUST NOT assume prior network access
      authentication.

   Requirement L7-8: Network Topology Unawareness

      The design of the GEOPRIV Layer 7 Location Configuration Protocol L7 LCP MUST NOT assume end systems being aware
      of the access network topology.  End systems are, however, able to
      determine their public IP address(es) via mechanisms mechanisms, such as STUN
      [5] or NSIS NATFW NSLP [14] .

   Requirement L7-9: Discovery Mechanism

      The GEOPRIV Layer 7 Location Configuration Protocol L7 LCP MUST provide define a single mandatory-to-implement discovery
      mechanism.

7.  Security Considerations

   This document addresses

   A discussion about security aspect throughout the aspects can be found in another document.
   [Editor's Note:  The security related content was previously in this
   document and will be published in a separate document soon.]

8.  IANA Considerations

   This document does not require actions by IANA.

9.  Contributors

   This contribution is a joint effort of the GEOPRIV Layer 7 Location
   Configuration Requirements Design Team of the IETF GEOPRIV Working
   Group.  The contributors include Henning Schulzrinne, Barbara Stark,
   Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson,
   Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig.

   We would like to thank the GEOPRIV working group chairs, Andy Newton,
   Randy Gellens and Allison Mankin, for creating the design team.

   The design team members can be reached at:

   Marc Linsner:  mlinsner@cisco.com

   Rohan Mahy:  rohan@ekabal.com

   Andrew Newton:  andy@hxr.us

   Jon Peterson:  jon.peterson@neustar.biz

   Brian Rosen:  br@brianrosen.net

   Henning Schulzrinne:  hgs@cs.columbia.edu

   Barbara Stark:  Barbara.Stark@bellsouth.com

   Martin Thomson:  Martin.Thomson@andrew.com

   Hannes Tschofenig:  Hannes.Tschofenig@siemens.com

   James Winterbottom:  James.Winterbottom@andrew.com

10.  Acknowledgements

   We would like to thank the IETF GEOPRIV working group chairs, Andy
   Newton, Allison Mankin and Randall Gellens, for creating this design
   team.  Furthermore, we would like thank Andy Newton for his support
   during the design team mailing list, for setting up Jabber chat
   conferences and for participating in the phone conference
   discussions.

   We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin
   Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl,
   Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard,
   Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara
   Stark, Michael Haberler for their WGLC review comments.

11.  References

11.1.  Normative References

   [1]   Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
         Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCP 14, March 1997.

   [3]   Schulzrinne, H. and R. Marshall, "Requirements for Emergency
         Context Resolution with Internet Technologies",
         draft-ietf-ecrit-requirements-13 (work in progress),
         March 2007.

11.2.  Informative References

   [4]   Marshall, R., "Requirements for a Location-by-Reference
         Mechanism used in Location  Configuration and Conveyance",
         draft-marshall-geopriv-lbyr-requirements-01 (work in progress),
         March 2007.

   [5]   Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
         - Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.

   [6]   Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast
         Name Resolution (LLMNR)",
         draft-ietf-dnsext-mdns-47 (work in progress), August 2006. RFC 4795, January 2007.

   [7]   Cheshire, S. and M. Krochmal, "Multicast DNS",
         draft-cheshire-dnsext-multicastdns-06 (work in progress),
         August 2006.

   [8]   Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07
         (work in progress), February 2007.

   [9]   Aura, T., "Cryptographically Generated Addresses (CGA)",
         RFC 3972, March 2005.

   [10]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
         Access Identifier", RFC 4282, December 2005.

   [11]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
         Authentication Dial In User Service (RADIUS)", RFC 2865,
         June 2000.

   [12]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
         "Diameter Base Protocol", RFC 3588, September 2003.

   [13]  Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
         for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
         RFC 4361, February 2006.

   [14]  Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
         (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in progress),
         March 2007.

   [15]  Peterson, J., "A Presence-based GEOPRIV Location Object
         Format", RFC 4119, December 2005.

   [16]  Hardie, T., "LoST: A Location-to-Service Translation Protocol",
         draft-ietf-ecrit-lost-05 (work in progress), March 2007.

   [17]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation  Protocol (SIP)",
         draft-ietf-sip-identity-06 (work in progress), October 2005.

   [18]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation Protocol (SIP)",
         RFC 4474, August 2006.

Authors' Addresses

   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Phone:  +49 89 636 40390
   Email:  Hannes.Tschofenig@siemens.com  Hannes.Tschofenig@nsn.com
   URI:    http://www.tschofenig.com

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone:  +1 212 939 7004
   Email:  hgs+ecrit@cs.columbia.edu
   URI:    http://www.cs.columbia.edu

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).