< draft-ietf-geopriv-l7-lcp-ps-07.txt   draft-ietf-geopriv-l7-lcp-ps-08.txt >
Network Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: September 30, 2008 Columbia University Expires: December 31, 2008 Columbia University
March 29, 2008 June 29, 2008
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
Requirements Requirements
draft-ietf-geopriv-l7-lcp-ps-07.txt draft-ietf-geopriv-l7-lcp-ps-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 30, 2008. This Internet-Draft will expire on December 31, 2008.
Abstract Abstract
This document provides a problem statement, lists requirements and This document provides a problem statement, lists requirements and
captures design aspects for a Geopriv Layer 7 Location Configuration captures design aspects for a Geopriv Layer 7 Location Configuration
Protocol L7 (LCP). This protocol aims to allow an end host to obtain Protocol L7 (LCP). This protocol aims to allow an end host to obtain
location information, by value or by reference, from a Location location information, by value or by reference, from a Location
Information Server (LIS) that is located in the access network. The Information Server (LIS) that is located in the access network. The
obtained location information can then be used for a variety of obtained location information can then be used for a variety of
different protocols and purposes. For example, it can be used as different protocols and purposes. For example, it can be used as
skipping to change at page 6, line 43 skipping to change at page 6, line 43
| | | | | |
| +------+ | | +------+ |
| | End | | | | End | |
| | Host | | | | Host | |
| +------+ | | +------+ |
| | | |
|Customer Premises Network | |Customer Premises Network |
| | | |
+---------------------------+ +---------------------------+
Figure 1: DSL Scenario Figure 1: Fixed-wired Scenario
The customer premises consists of a router with a Network Address The customer premises consists of a router with a Network Address
Translator with Port Address Translation (NAPT) and a DHCP server as Translator with Port Address Translation (NAPT) and a DHCP server as
used in most Customer Premises Networks (CPN) and the Network used in most Customer Premises Networks (CPN) and the Network
Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 Termination Equipment (NTE) where Layer 1 and sometimes Layer 2
protocols are terminated. The router in the home network (e.g., protocols are terminated. The router in the home network (e.g.,
broadband router, cable or DSL router) typically runs a NAPT and a 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 DHCP server. The NTE is a legacy device and in many cases cannot be
modified for the purpose of delivering location information to the modified for the purpose of delivering location information to the
end host. The same is true of the device with the NAPT and DHCP end host. The same is true of the device with the NAPT and DHCP
server. server.
It is possible for the NTE and the home router to physically be in 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 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 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 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. customers' homes, and the Ethernet NIC in their PC serves as the NTE.
Current Customer Premises Network (CPN) deployments frequently show Current Customer Premises Network (CPN) deployments generally fall
the following characteristics: into one of the following classifications:
1. CPE = Single PC 1. Single PC
1. with Ethernet NIC (PPPoE or DHCP on PC); there may be a 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 bridged DSL or cable modem as NTE, or the Ethernet NIC might
be the NTE be the NTE
2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC] 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 Note that the device with NAPT and DHCP of Figure 1 is not
present in such a scenario. present in such a scenario.
skipping to change at page 7, line 50 skipping to change at page 7, line 50
The majority of fixed access broadband customers use a router. The The majority of fixed access broadband customers use a router. The
placement of the VoIP client is mentioned to describe what sorts of placement of the VoIP client is mentioned to describe what sorts of
hosts may need to be able to request location information. Soft hosts may need to be able to request location information. Soft
clients on PCs are frequently not launched until long after bootstrap clients on PCs are frequently not launched until long after bootstrap
is complete, and are not able to control any options that may be is complete, and are not able to control any options that may be
specified during bootstrap. They also cannot control whether a VPN specified during bootstrap. They also cannot control whether a VPN
client is running on the end host. client is running on the end host.
3.2. Moving Network 3.2. Moving Network
An example of a moving network is a "WIMAX-like fixed wireless" One example of a moving network is a WiMAX fixed wireless scenario.
scenario that is offered in several cities, like New Orleans, Biloxi, This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless
etc., where much of the communications infrastructure was destroyed networks. In implementations intended to provide broadband service
due to a natural disaster. The customer-side antenna for this to a home or other stationary location, the customer-side antenna /
service is rather small (about the size of a mass market paperback NTE tends to be rather small and portable. The LAN-side output of
book) and can be run off battery power. The output of this little this device is an Ethernet jack, which can be used to feed a PC or a
antenna is a RJ-45 Ethernet jack. A laptop can be plugged into this router. The PC or router then uses DHCP or PPPoE to connect to the
Ethernet jack. The user would then run a PPPoE client to connect to access network, the same as for wired access networks. Access
the network. Once the network connection is established, the user providers who deploy this technology may use the same core network
can run a SIP client on the laptop. (including network elements that terminate PPPoE and provide IP
addresses) for DSL, fiber to the premises (FTTP), and fixed wireless
The network-side antenna is, for example, connected through ATM to customers.
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 Given that the customer antenna is portable and can be battery-
"mobile". All they see is an Ethernet connection, and the IP address powered, it is possible for a user to connect a laptop to it and move
they get from PPPoE does not change over the coverage area. Only the within the coverage area of a single base antenna. This coverage
user and the network are aware of the laptop's mobility. 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 can be found in busses, trains, Further examples of moving networks (where end devices may not be
and airplanes. aware that they are moving) can be found in busses, trains, and
airplanes.
Figure 2 shows an example topology for a moving network. Figure 2 shows an example topology for a moving network.
+--------------------------+ +--------------------------+
| Wireless | | Wireless |
| Access Network Provider | | Access Network Provider |
| | | |
| +----------+| | +----------+|
| +-------+ LIS || | +-------+ LIS ||
| | | || | | | ||
skipping to change at page 12, line 21 skipping to change at page 12, line 21
Anycast: Anycast:
With this solution an anycast address is defined (for IPv4 and With this solution an anycast address is defined (for IPv4 and
IPv6) in the style of [11] that allows the endhost to route IPv6) in the style of [11] that allows the endhost to route
discovery packets to the nearest LIS. Note that this procedure discovery packets to the nearest LIS. Note that this procedure
would be used purely for discovery and thereby similar to local would be used purely for discovery and thereby similar to local
Teredo server discovery approach outlined in Section 4.2 of [12]. Teredo server discovery approach outlined in Section 4.2 of [12].
The LIS discovery procedure raises deployment and security issues. The LIS discovery procedure raises deployment and security issues.
When an end host discovers a LIS it must be ensured that The access network needs to be designed to prevent man-in-the-middle
adversaries from presenting themselves as a LIS to end hosts. When
1. it does not talk to a man-in-the-middle, and an end host discovers a LIS, it needs to ensure (and be able to
ensure) that the discovered entity is indeed an authorized LIS.
2. that the discovered entity is indeed an authorized LIS.
5. Identifier for Location Determination 5. Identifier for Location Determination
The LIS returns location information to the end host when it receives The LIS returns location information to the end host when it receives
a request. Some form of identifier is therefore needed to allow the a request. Some form of identifier is therefore needed to allow the
LIS to retrieve the Target's current location (or a good LIS to retrieve the Target's current location (or a good
approximation of it) from a database. approximation of it) from a database.
The chosen identifier needs to have the following properties: The chosen identifier needs to have the following properties:
skipping to change at page 14, line 25 skipping to change at page 14, line 25
Cell ID: Cell ID:
This identifier is available in cellular data networks and the This identifier is available in cellular data networks and the
cell ID may not be visible to the end host. cell ID may not be visible to the end host.
Host Identifier: Host Identifier:
The Host Identifier introduced by the Host Identity Protocol [13] The Host Identifier introduced by the Host Identity Protocol [13]
allows identification of a particular host. Unfortunately, the allows identification of a particular host. Unfortunately, the
network can only use this identifier for location determination if network can only use this identifier for location determination if
the operator already stores an mapping of host identities to the operator already stores a mapping of host identities to
location information. Furthermore, there is a deployment problem location information. Furthermore, there is a deployment problem
since the host identities are not used in todays networks. since the host identities are not used in todays networks.
Cryptographically Generated Address (CGA): Cryptographically Generated Address (CGA):
The concept of a Cryptographically Generated Address (CGA) was The concept of a Cryptographically Generated Address (CGA) was
introduced by [14]. The basic idea is to put the truncated hash introduced by [14]. The basic idea is to put the truncated hash
of a public key into the interface identifier part of an IPv6 of a public key into the interface identifier part of an IPv6
address. In addition to the properties of an IP address it allows address. In addition to the properties of an IP address it allows
a proof of ownership. Hence, a return routability check can be a proof of ownership. Hence, a return routability check can be
skipping to change at page 15, line 40 skipping to change at page 15, line 40
adversary wants to learn the location of a Target (as identified adversary wants to learn the location of a Target (as identified
by a particular IP address) then it does not see the response 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 message (unless he is on the subnetwork or at a router along the
path towards the LIS). path towards the LIS).
On a shared medium an adversary could ask for location information On a shared medium an adversary could ask for location information
of another Target. The adversary would be able to see the of another Target. The adversary would be able to see the
response message since it is sniffing on the shared medium unless response message since it is sniffing on the shared medium unless
security mechanisms, such as link layer encryption, are in place. security mechanisms, such as link layer encryption, are in place.
With a network deployment as shown in Section 3.1 with multiple With a network deployment as shown in Section 3.1 with multiple
hosts in the Customer Premise being behind a NAT the LIS is unable hosts in the Customer Premises being behind a NAT the LIS is
to differentiate the individual end points. For WLAN deployments unable to differentiate the individual end points. For WLAN
as found in hotels, as shown in Section 3.3, it is possible for an deployments as found in hotels, as shown in Section 3.3, it is
adversary to eavesdrop data traffic and subsequently to spoof the possible for an adversary to eavesdrop data traffic and
IP address in a query to the LIS to learn more detailed location subsequently to spoof the IP address in a query to the LIS to
information (e.g., specific room numbers). Such an attack might, learn more detailed location information (e.g., specific room
for example, compromise the privacy of hotel guests. numbers). Such an attack might, for example, compromise the
privacy of hotel guests.
6. Requirements 6. Requirements
The following requirements and assumptions have been identified: The following requirements and assumptions have been identified:
Requirement L7-1: Identifier Choice Requirement L7-1: Identifier Choice
The L7 LCP MUST be able to carry different identifiers or MUST The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding define an identifier that is mandatory to implement. Regarding
the latter aspect, such an identifier is only appropriate if it is the latter aspect, such an identifier is only appropriate if it is
skipping to change at page 16, line 38 skipping to change at page 16, line 38
The design of the L7 LCP MUST NOT assume a business or trust The design of the L7 LCP MUST NOT assume a business or trust
relationship between the Application Service Provider (ASP) and relationship between the Application Service Provider (ASP) and
the Access Network Provider. Requirements for resolving a the Access Network Provider. Requirements for resolving a
reference to location information are not discussed in this reference to location information are not discussed in this
document. document.
Requirement L7-4: Layer 2 and Layer 3 Provider Relationship Requirement L7-4: Layer 2 and Layer 3 Provider Relationship
The design of the L7 LCP MUST assume that there is a trust and 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 business relationship between the L2 and the L3 provider. The L3
provider operates the LIS and needs to obtain location information provider operates the LIS that the Target queries. It, in turn,
from the L2 provider since this one is closest to the end host. needs to obtain location information from the L2 provider since
If the L2 and L3 provider for the same host are different this one is closest to the end host. If the L2 and L3 provider
entities, they cooperate for the purposes needed to determine end for the same host are different entities, they cooperate for the
system locations. purposes needed to determine end system locations.
Requirement L7-5: Legacy Device Considerations Requirement L7-5: Legacy Device Considerations
The design of the L7 LCP MUST consider legacy devices, such as The design of the L7 LCP MUST consider legacy devices, such as
residential NAT devices and NTEs in an DSL environment, that residential NAT devices and NTEs in a DSL environment, that cannot
cannot be upgraded to support additional protocols, for example, be upgraded to support additional protocols, for example, to pass
to pass additional information towards the Target. additional information towards the Target.
Requirement L7-6: VPN Awareness Requirement L7-6: VPN Awareness
The design of the L7 LCP MUST assume that at least one end of a 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, VPN is aware of the VPN functionality. In an enterprise scenario,
the enterprise side will provide the LIS used by the client and the enterprise side will provide the LIS used by the client and
can thereby detect whether the LIS request was initiated through a can thereby detect whether the LIS request was initiated through a
VPN tunnel. VPN tunnel.
Requirement L7-7: Network Access Authentication Requirement L7-7: Network Access Authentication
skipping to change at page 22, line 5 skipping to change at page 21, line 21
conferences and for participating in the phone conference conferences and for participating in the phone conference
discussions. discussions.
We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin
Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl,
Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard,
Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara
Stark, Michael Haberler, and Mary Barnes for their WGLC review Stark, Michael Haberler, and Mary Barnes for their WGLC review
comments. comments.
The authors would like to thank NENA for their work on [24] as it
helped to provide some of the initial thinking.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
skipping to change at page 24, line 5 skipping to change at page 23, line 48
[22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work
in progress), February 2008. in progress), February 2008.
[23] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne, [23] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne,
"Security Requirements for the Geopriv Location System", "Security Requirements for the Geopriv Location System",
draft-barnes-geopriv-lo-sec-02 (work in progress), draft-barnes-geopriv-lo-sec-02 (work in progress),
February 2008. February 2008.
[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.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
 End of changes. 16 change blocks. 
50 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/