draft-ietf-geopriv-l7-lcp-ps-02.txt   draft-ietf-geopriv-l7-lcp-ps-03.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: October 30, 2007 Columbia U. Expires: January 10, 2008 Columbia U.
April 28, 2007 July 9, 2007
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-02.txt draft-ietf-geopriv-l7-lcp-ps-03.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 October 30, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 4, line 14 skipping to change at page 4, line 14
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], and "OPTIONAL" are to be interpreted as described in RFC 2119 [2],
with the qualification that unless otherwise stated these words apply with the qualification that unless otherwise stated these words apply
to the design of the GEOPRIV Layer 7 Location Configuration Protocol. to the design of the GEOPRIV Layer 7 Location Configuration Protocol.
The term Location Configuration Server (LCS) refers to an entity The term Location Configuration Server (LCS) refers to an entity
capable of determining the location of the Target and of delivering capable of determining the location of an end point and of providing
that location information, a reference to it, or bot) to the Target that location information, a reference to it, or both via the
via the L7 LCP. Location Configuration Protocol (LCP) to the requesting party, in
most cases to the end point itself (or to an authorized entity that
acts on behalf of it).
This document also uses terminology from [1] and [3]. This document also uses terminology from [1] and [3].
3. Scenarios 3. Scenarios
This section describes a few network scenarios where the L7 LCP may This section describes a few network scenarios where the L7 LCP may
be used. Note that this section does not aim to exhaustively list be used. Note that this section does not aim to exhaustively list
all possible deployment environments. Instead we focus on the all possible deployment environments. Instead we focus on the
following environments: following environments:
skipping to change at page 10, line 9 skipping to change at page 10, line 9
from the LCS. The access equipment uses, in many cases, link layer from the LCS. The access equipment uses, in many cases, link layer
devices. Figure 3 represents a hotspot network found, for example, devices. Figure 3 represents a hotspot network found, for example,
in hotels, airports, and coffee shops. For editorial reasons we only in hotels, airports, and coffee shops. For editorial reasons we only
describe a single access point and do not depict how the LCS obtains describe a single access point and do not depict how the LCS obtains
location information since this is very deployment specific. location information since this is very deployment specific.
+--------------------------+ +--------------------------+
| Access Network Provider | | Access Network Provider |
| | | |
| +----------+| | +----------+|
| +-------| LC || | +-------| LCS ||
| | | || | | | ||
| +--------+ +----------+| | +--------+ +----------+|
| | Access | | | | Access | |
| | Point | | | | Point | |
| +--------+ | | +--------+ |
| | | | | |
+------+-------------------+ +------+-------------------+
| |
+------+ +------+
| End | | End |
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Figure 3: Wireless Access Scenario Figure 3: Wireless Access Scenario
4. Discovery of the Location Configuration Server 4. Discovery of the Location Configuration Server
When a Target wants to retrieve location information from the LCS it When a Target wants to retrieve location information from the LCS it
first needs to discover it. Based on the problem statement of first needs to discover it. Based on the problem statement of
determining the location of the Target, which is known best by determining the location of the Target, which is known best by
entities close to the Target itself, we assume that the LCS is entities close to the Target itself, we assume that the LCS is
located in the access network. Several procedures have been located in the access network. Several procedures have been
investigated that aim to discovery the LCS in such an access network. investigated that aim to discover the LCS in such an access network.
DHCP-based Discovery: DHCP-based Discovery:
In some environments the Dynamic Host Configuration Protocol In some environments the Dynamic Host Configuration Protocol
(DHCP) might be a good choice for discovering the FQDN or the IP (DHCP) might be a good choice for discovering the FQDN or the IP
address of the LCS. In environments where DHCP can be used it is address of the LCS. In environments where DHCP can be used it is
also possible to use the already defined location extensions. In also possible to use the already defined location extensions. In
environments with legacy devices, such as the one shown in environments with legacy devices, such as the one shown in
Section 3.1, a DHCP based discovery solution may not be possible. Section 3.1, a DHCP based discovery solution may not be possible.
skipping to change at page 15, line 38 skipping to change at page 15, line 38
for a return routability check is attractive to return location for a return routability check is attractive to return location
information only to the address that submitted the request. If an information only to the address that submitted the request. If an
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 LCS). path towards the LCS).
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) is 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 LCS is unable hosts in the Customer Premise being behind a NAT the LCS is unable
to differentiate the individual end points. For WLAN deployments to differentiate the individual end points. For WLAN deployments
as found in hotels, as shown in Section 3.3, it is possible for an 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 adversary to eavesdrop data traffic and subsequently to spoof the
IP address in a query to the LCS to learn more detailed location IP address in a query to the LCS to learn more detailed location
information (e.g., specific room numbers). Such an attack might, information (e.g., specific room numbers). Such an attack might,
for example, compromise the privacy of hotel guests. for example, compromise the privacy of hotel guests.
6. Requirements 6. Requirements
skipping to change at page 17, line 27 skipping to change at page 17, line 27
Requirement L7-8: Network Topology Unawareness Requirement L7-8: Network Topology Unawareness
The design of the L7 LCP MUST NOT assume end systems being aware The design of the L7 LCP MUST NOT assume end systems being aware
of the access network topology. End systems are, however, able to of the access network topology. End systems are, however, able to
determine their public IP address(es) via mechanisms, such as STUN determine their public IP address(es) via mechanisms, such as STUN
[5] or NSIS NATFW NSLP [14] . [5] or NSIS NATFW NSLP [14] .
Requirement L7-9: Discovery Mechanism Requirement L7-9: Discovery Mechanism
The L7 LCP MUST define a single mandatory-to-implement discovery The L7 LCP MUST define a mandatory-to-implement LCS discovery
mechanism. mechanism.
7. Security Considerations 7. Security Considerations
A discussion about security aspects can be found in another document. A discussion about security aspects can be found in another document.
[Editor's Note: The security related content was previously in this [Editor's Note: The security related content was previously in this
document and will be published in a separate document soon.] document and will be published in a separate document soon.]
8. IANA Considerations 8. IANA Considerations
skipping to change at page 21, line 18 skipping to change at page 21, line 18
Newton, Allison Mankin and Randall Gellens, for creating this design Newton, Allison Mankin and Randall Gellens, for creating this design
team. Furthermore, we would like thank Andy Newton for his support team. Furthermore, we would like thank Andy Newton for his support
during the design team mailing list, for setting up Jabber chat during the design team mailing list, for setting up Jabber chat
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 for their WGLC review comments. Stark, Michael Haberler, and Mary Barnes for their WGLC review
comments.
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 22, line 38 skipping to change at page 22, line 38
- Simple Traversal of User Datagram Protocol (UDP) Through - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[6] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast [6] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast
Name Resolution (LLMNR)", RFC 4795, January 2007. Name Resolution (LLMNR)", RFC 4795, January 2007.
[7] Cheshire, S. and M. Krochmal, "Multicast DNS", [7] Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-06 (work in progress), draft-cheshire-dnsext-multicastdns-06 (work in progress),
August 2006. August 2006.
[8] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07 [8] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08
(work in progress), February 2007. (work in progress), June 2007.
[9] Aura, T., "Cryptographically Generated Addresses (CGA)", [9] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[10] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network [10] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005. Access Identifier", RFC 4282, December 2005.
[11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000. June 2000.
 End of changes. 10 change blocks. 
14 lines changed or deleted 17 lines changed or added

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