[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-tschofenig-geopriv-l7-lcp-ps) 00 01 02 03 04 05 06 07 08 09 10 RFC 5687

Network Working Group                                      H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status:  Informational                           H. Schulzrinne
Expires:  August 25, 2009                            Columbia University
                                                       February 21, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 August 25, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.






Tschofenig & Schulzrinne  Expires August 25, 2009               [Page 1]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


Abstract

   This document provides a problem statement, lists requirements and
   captures design aspects for a 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
   Information Server (LIS) 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 Server . . . . . . . . . 11
   5.  Identifier for Location Determination  . . . . . . . . . . . . 13
   6.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     11.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25



















Tschofenig & Schulzrinne  Expires August 25, 2009               [Page 2]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


1.  Introduction

   This document provides a problem statement, lists requirements and
   captures design aspects for a 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 dedicated node, called the Location
      Information Server (LIS).

   o  It enables the Target to obtain a reference to location
      information (referred as "Location by Reference" or LbyR).  This
      reference can take the form of a subscription URI, such as a SIP
      presence URI, a HTTP/HTTPS URI, or another URI.  The requirements
      related to the task of obtaining a 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) and the LIS.

   This document is structured as follows.  Section 4 discusses the
   challenge of discovering the LIS 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 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 or
   certain deployment environments.


















Tschofenig & Schulzrinne  Expires August 25, 2009               [Page 3]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


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.

   The term Location Information Server (LIS) refers to an entity
   capable of determining the location of a Target and of providing that
   location information, a reference to it, or both via the Location
   Configuration Protocol (LCP) to the requesting party.  In most cases
   the requesting party is the Target itself but it may also be an
   authorized entity that acts on behalf of it, such as a SIP proxy or
   another LIS.

   This document also uses terminology from [1] (such as Target) and [3]
   (such as Internet Access Provider (IAP), Internet Service Provider
   (ISP), and Application Service Provider (ASP)).

   With the term "Access Network Provider" we refer to the Internet
   Access Provider (IAP) and the Internet Service Provider (ISP) without
   further distinguishing these two entities as it is not relevant for
   the purpose of this document.  An additional requirements document on
   LIS-to-LIS [5] shows scenario where the separation between IAP and
   ISP is important.

























Tschofenig & Schulzrinne  Expires August 25, 2009               [Page 4]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


3.  Scenarios

   This section describes a few network scenarios where the L7 LCP may
   be used.  Note that this section does not aim to exhaustively list
   all possible deployment environments.  Instead we focus on 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

   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
   LIS.



























Tschofenig & Schulzrinne  Expires August 25, 2009               [Page 5]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


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

                      Figure 1: Fixed-wired 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



Tschofenig & Schulzrinne  Expires August 25, 2009               [Page 6]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


   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 generally fall
   into one of the following classifications:

   1.  Single PC

       1.  with Ethernet NIC (PPPoE or DHCP on 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 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)

       1.  combined router and NTE

       2.  separate router with NTE in bridged mode

       3.  separate router with NTE (NTE/router does PPPoE or DHCP to
           WAN, router provides DHCP server for hosts in LAN; double
           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 running on the end host.

3.2.  Moving Network

   One example of a moving network is a WiMAX fixed wireless scenario.
   This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless



Tschofenig & Schulzrinne  Expires August 25, 2009               [Page 7]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


   networks.  In implementations intended to provide broadband service
   to a home or other stationary location, the customer-side antenna /
   NTE tends to be rather small and portable.  The LAN-side output of
   this device is an Ethernet jack, which can be used to feed a PC or a
   router.  The PC or router then uses DHCP or PPPoE to connect to the
   access network, the same as for wired access networks.  Access
   providers who deploy this technology may use the same core network
   (including network elements that terminate PPPoE and provide IP
   addresses) for DSL, fiber to the premises (FTTP), and fixed wireless
   customers.

   Given that the customer antenna is portable and can be battery-
   powered, it is possible for a user to connect a laptop to it and move
   within the coverage area of a single base antenna.  This coverage
   area can be many square kilometers in size.  In this case, the laptop
   (and any SIP client running on it) would be completely unaware of
   their mobility.  Only the user and the network are aware of the
   laptop's mobility.

   Further examples of moving networks (where end devices may not be
   aware that they are moving) can be found in busses, trains, and
   airplanes.

   Figure 2 shows an example topology for a moving network.



























Tschofenig & Schulzrinne  Expires August 25, 2009               [Page 8]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


   +--------------------------+
   | Wireless                 |
   | Access Network Provider  |
   |                          |
   |              +----------+|
   |      +-------+ LIS      ||
   |      |       |          ||
   |  +---+----+  +----------+|
   |  | 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 LIS.  The access equipment uses, in many cases, link layer
   devices.  Figure 3 represents a hotspot network 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 LIS obtains
   location information since this is very deployment specific.











Tschofenig & Schulzrinne  Expires August 25, 2009               [Page 9]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


   +--------------------------+
   | Access Network Provider  |
   |                          |
   |              +----------+|
   |      +-------| LIS      ||
   |      |       |          ||
   |  +--------+  +----------+|
   |  | Access |              |
   |  | Point  |              |
   |  +--------+              |
   |      |                   |
   +------+-------------------+
          |
        +------+
        | End  |
        | Host |
        +------+

                    Figure 3: Wireless Access Scenario
































Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 10]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


4.  Discovery of the Location Information Server

      Note that this section lists mechanisms that were discussed as
      part of the work on the Geopriv Layer 7 Location Configuration
      Protocol design team.  They are included to show challenges in the
      problem space and are listed for completeness reasons.  They do
      not in any way mean that their is consensus that any of these
      approaches are good or bad or that the IETF is in any recommended
      in this document that any of these be used.

   When a Target wants to retrieve location information from the LIS it
   first needs to discover it.  Based on the problem statement of
   determining the location of the Target, which is known best by
   entities close to the Target itself, we assume that the LIS is
   located in the local subnet or in access network.  Several procedures
   have been investigated that aim to discover the LIS 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 LIS.  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 may not be possible.


   DNS-based Discovery:

      Before a DNS lookup can be started it is necessary to learn the
      domain name of the access network that runs a LIS.  Several ways
      to learn the domain name exist.  For example, the end host obtains
      its own public IP address, for example via STUN [6], and performs
      a reverse DNS lookup (assuming the data is provisioned into the
      DNS).  Then, the SRV or NAPTR record for that domain is retrieved.
      A more detailed description of this approach can be found in [7].


   Redirect Rule:

      A redirect rule at a device in the access network could be used to
      redirect the L7 LCP signalling messages (destined to a specific
      port) to the LIS.  The end host could then discover the LIS by
      sending a packet with a specific (registered) port number to
      almost any address (as long as the destination IP address does not
      target a device in the local network).  The packet would be
      redirected to the respective LIS being configured.  The same



Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 11]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


      procedure is used by captive portals whereby any HTTP traffic is
      intercepted and redirected.

      To some extend this approach is similar to packets that are marked
      with a Router Alert option [8] and intercepted by entities that
      understand the specific marking.  In the above-mentioned case,
      however, the marking is provided via a registered port number
      instead of relying on a Router Alert option.

      This solution approach would require a deep packet inspection
      capability at an entity in the access providers networks that
      scans for the occurrence of particular destination port numbers.


   Multicast Query:

      An end node could also discover a LIS by sending a DNS query to a
      well-known address.  An example of such a mechanism is multicast
      DNS (see [9] and [10]).  Unfortunately, these mechanisms only work
      on the local link.


   Anycast:

      With this solution an anycast address is defined (for IPv4 and
      IPv6) in the style of [11] that allows the endhost to route
      discovery packets to the nearest LIS.  Note that this procedure
      would be used purely for discovery and thereby similar to local
      Teredo server discovery approach outlined in Section 4.2 of [12].

   The LIS discovery procedure raises deployment and security issues.
   The access network needs to be designed to prevent man-in-the-middle
   adversaries from presenting themselves as a LIS to end hosts.  When
   an end host discovers a LIS, it needs to ensure (and be able to
   ensure) that the discovered entity is indeed an authorized LIS.
















Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 12]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


5.  Identifier for Location Determination

      Note that this section lists mechanisms that were discussed as
      part of the work in the Geopriv Layer 7 Location Configuration
      Protocol design team.  They are included to show challenges in the
      problem space and are listed for completeness reasons.  They do
      not in any way mean that their is consensus that any of these
      approaches are good or bad or that the IETF is in any recommended
      in this document that any of these be used.

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

   The chosen identifier needs to have the following properties:

   Ability for Target to learn or know the identifier:

      The Target MUST know or MUST be able to learn the identifier
      (explicitly or implicitly) in order to send it to the LIS.
      Implicitly refers to the situation where a device along the path
      between the end host and the LIS 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 LIS MUST be able to use the identifier (directly or
      indirectly) for location determination.  Indirectly refers to the
      case where the LIS uses other identifiers internally for location
      determination, in addition to the one provided by the 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 Targets.  A on-
      path adversary in the same subnet SHOULD NOT be able to spoof the
      identifier of another Target in the same subnet.

   The following list discusses frequently mentioned identifiers and
   their properties:








Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 13]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


   Host MAC Address:

      The Target's MAC address is known to the end host, but not carried
      over an IP hop and therefore not accessible to the LIS 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 may not be visible to the end host.


   Host Identifier:

      The Host Identifier introduced by the Host Identity Protocol [13]
      allows identification of a particular host.  Unfortunately, the
      network can only use this identifier for location determination if
      the operator already stores a 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 [14].  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



Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 14]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


      omitted.  It is only available for IPv6 addresses.


   Network Access Identifiers:

      A Network Access Identifier [15] is used during the network access
      authentication procedure, for example in RADIUS [16] and Diameter
      [17].  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 the user's identity might not be
      available to the access network since security protocols might
      offer user identity confidentiality and thereby hiding the 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 document.
      It also has a requirement that routers that use DHCP to the WAN
      use RFC 4361 [18] to provide the DHCP server with a unique client
      identifier.  This identifier is, however, not visible to the
      Target when legacy NTE device are used.


   IP Address:

      The Target's IP address may be used for location determination.
      This IP address is not visible to the LIS if the end host is
      behind one or multiple NATs.  This 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 LIS would in this case only
      see the public IP address of the NAT binding allocated by the NAT,
      which is the expected behavior.  The property of the IP address
      for a return routability check is attractive to return location
      information only to the address that submitted the request.  If an
      adversary wants to learn the location of a Target (as identified
      by a particular IP address) then it does not see the response
      message (unless he is on the subnetwork or at a router along the
      path towards the LIS).

      On a shared medium an adversary could ask for location information
      of another Target.  The adversary would be able to see the
      response message since it is sniffing on the shared medium unless



Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 15]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


      security mechanisms, such as link layer encryption, are in place.
      With a network deployment as shown in Section 3.1 with multiple
      hosts in the Customer Premises being behind a NAT the LIS is
      unable to differentiate the individual end points.  For WLAN
      deployments as found in hotels, 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 LIS to
      learn more detailed location information (e.g., specific room
      numbers).  Such an attack might, for example, compromise the
      privacy of hotel guests.









































Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 16]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


6.  Requirements

   The following requirements and assumptions have been identified:

   Requirement L7-1: Identifier Choice

      The L7 LCP MUST be able to carry different identifiers or MUST
      define an identifier that is mandatory to implement.  Regarding
      the 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 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: ASP and Access Network Provider Relationship

      The design of the L7 LCP MUST NOT assume a business or trust
      relationship between the Application Service Provider (ASP) and
      the Access Network Provider.  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 L7 LCP MUST assume that there is a trust and
      business relationship between the L2 and the L3 provider.  The L3
      provider operates the LIS that the Target queries.  It, in turn,
      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 L7 LCP MUST consider legacy devices, such as
      residential NAT devices and NTEs in a DSL environment, that cannot
      be upgraded to support additional protocols, for example, to pass



Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 17]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


      additional information towards the Target.


   Requirement L7-6: VPN Awareness

      The design of the 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 LIS used by the client and
      can thereby detect whether the LIS request was initiated through a
      VPN tunnel.


   Requirement L7-7: Network Access Authentication

      The design of the L7 LCP MUST NOT assume prior network access
      authentication.


   Requirement L7-8: Network Topology Unawareness

      The design of the 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, such as STUN
      [6] or NSIS NATFW NSLP [19] .


   Requirement L7-9: Discovery Mechanism

      The L7 LCP MUST define a mandatory-to-implement LIS discovery
      mechanism.

   Requirement L7-10: PIDF-LO Creation

      When a LIS creates a PIDF-LO [20] then it MUST put the <geopriv>
      element into the <device> element of the presence document (see
      [21]).  This ensures that the resulting PIDF-LO document, which is
      subsequently distributed to other entities, conforms to the rules
      outlined in [22].













Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 18]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


7.  Security Considerations

   By using a Geolocation L7 Location Configuration Protocol, the client
   expose themselves to a privacy risk whereby an unauthorized entity
   receives location information.  The provision of confidentiality
   protected location to the requestor depends on the success of four
   steps:

   1.  The client must have a means to discover a LIS.

   2.  The client must authenticate the discovered LIS.

   3.  The LIS must be able to determine location and return it to the
       authorized entity.

   4.  The LIS must securely exchange messages without intermedaries
       eavesdropping or tampering them.

   This document contains various security related requirements
   throughout the document addressing the above-mentioned steps.  For a
   broader security discussion of the overall geolocation privacy
   architecture the reader is referred to [23].





























Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 19]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


8.  IANA Considerations

   This document does not require actions by IANA.
















































Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 20]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


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.
   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.

   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@nsn.com

   James Winterbottom:  James.Winterbottom@andrew.com
















Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 21]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


10.  Acknowledgements

   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, and Mary Barnes for their WGLC review
   comments.

   The authors would like to thank NENA for their work on [24] as it
   helped to provide some of the initial thinking.

   The authors would also like to thank Cullen Jennings for his feedback
   as part of the IESG processing.





































Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 22]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


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", draft-ietf-geopriv-lbyr-requirements-05 (work in
         progress), November 2008.

   [5]   Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
         Requirements", draft-winterbottom-geopriv-lis2lis-req-01 (work
         in progress), November 2007.

   [6]   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.

   [7]   Thomson, M. and J. Winterbottom, "Discovering the Local
         Location Information Server (LIS)",
         draft-thomson-geopriv-lis-discovery-03 (work in progress),
         September 2007.

   [8]   Katz, D., "IP Router Alert Option", RFC 2113, February 1997.

   [9]   Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast
         Name Resolution (LLMNR)", RFC 4795, January 2007.

   [10]  Cheshire, S. and M. Krochmal, "Multicast DNS",
         draft-cheshire-dnsext-multicastdns-07 (work in progress),
         September 2008.

   [11]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
         RFC 3068, June 2001.

   [12]  Ward, N., "Teredo Server Selection",
         draft-nward-v6ops-teredo-server-selection-00 (work in



Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 23]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


         progress), July 2007.

   [13]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
         "Host Identity Protocol", draft-ietf-hip-base-10 (work in
         progress), October 2007.

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

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

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

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

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

   [19]  Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/
         Firewall NSIS Signaling Layer Protocol (NSLP)",
         draft-ietf-nsis-nslp-natfw-20 (work in progress),
         November 2008.

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

   [21]  Rosenberg, J., "A Data Model for Presence", RFC 4479,
         July 2006.

   [22]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
         PIDF-LO Usage Clarification, Considerations and
         Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 (work
         in progress), November 2008.

   [23]  Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne,
         "Additional Location Privacy Considerations",
         draft-barnes-geopriv-lo-sec-04 (work in progress),
         January 2009.

   [24]  "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA
         Recommended Method(s) for Location Determination to Support IP-
         Based Emergency Services - Technical Information Document
         (TID)", PDF NENA 08-505, December 2006.



Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 24]


Internet-Draft      Geopriv L7 LCP; Problem Statement      February 2009


Authors' Addresses

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone:  +358 (50) 4871445
   Email:  Hannes.Tschofenig@gmx.net
   URI:    http://www.tschofenig.priv.at


   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




























Tschofenig & Schulzrinne  Expires August 25, 2009              [Page 25]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/