draft-ietf-geopriv-l7-lcp-ps-04.txt   draft-ietf-geopriv-l7-lcp-ps-05.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: February 27, 2008 Columbia U. Expires: March 15, 2008 Columbia University
August 26, 2007 September 12, 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-04.txt draft-ietf-geopriv-l7-lcp-ps-05.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 February 27, 2008. This Internet-Draft will expire on March 15, 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 11, line 25 skipping to change at page 11, line 25
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 LIS. In environments where DHCP can be used it is address of the LIS. 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.
DNS-based Discovery: DNS-based Discovery:
With this idea the end host obtains its public IP address (e.g., With this approach the end host obtains its public IP address
via STUN [6]) in order to obtain its domain name (via the usual (e.g., via STUN [6]) in order to obtain its domain name (via a
reverse DNS lookup). Then, the SRV or NAPTR record for that reverse DNS lookup). Then, the SRV or NAPTR record for that
domain is retrieved. This relies on the user's public IP address domain is retrieved. This relies on the user's public IP address
having a DNS entry. having a DNS entry. A more detailed description of this approach
can be found in [7].
Redirect Rule: Redirect Rule:
A redirect rule at a device in the access network, for example at A redirect rule at a device in the access network, for example at
the AAA client, will be used to redirect the L7 LCP signalling the AAA client, could be used to redirect the L7 LCP signalling
messages (destined to a specific port) to the LIS. The end host messages (destined to a specific port) to the LIS. The end host
could then discover the LIS by sending a packet to almost any could then discover the LIS by sending a packet to almost any
address (as long it is not in the user's home network behind a address (as long as the destination IP address does not target a
NAT). The packet would be redirected to the respective LIS being device in the local network). The packet would be redirected to
configured. The same procedure is used by captive portals whereby the respective LIS being configured. The same procedure is used
any HTTP traffic is intercepted and redirected. 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.
Multicast Query: Multicast Query:
An end node could also discover a LIS by sending a multicast An end node could also discover a LIS by sending a DNS query to a
request to a well-known address. An example of such a mechanism well-known address. An example of such a mechanism is multicast
is multicast DNS (see [7] and [8]). 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 LIS discovery procedure raises deployment and security issues.
When an end host discovers a LIS it must be ensured that When an end host discovers a LIS it must be ensured that
1. it does not talk to a man-in-the-middle, and 1. it does not talk to a man-in-the-middle, and
2. 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.
skipping to change at page 14, line 22 skipping to change at page 14, line 22
enterprise networks, typically available via proprietary protocols enterprise networks, typically available via proprietary protocols
like CDP or, in the future, 802.1ab. like CDP or, in the future, 802.1ab.
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 [9] 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 an 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 [10]. 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
omitted. It is only available for IPv6 addresses. omitted. It is only available for IPv6 addresses.
Network Access Identifiers: Network Access Identifiers:
A Network Access Identifier [11] is used during the network access A Network Access Identifier [15] is used during the network access
authentication procedure, for example in RADIUS [12] and Diameter authentication procedure, for example in RADIUS [16] and Diameter
[13]. In DSL networks the user credentials are, in many cases, [17]. In DSL networks the user credentials are, in many cases,
only known by the home router and not configured at the Target only known by the home router and not configured at the Target
itself. To the network, the authenticated user identity is only itself. To the network, the authenticated user identity is only
available if a network access authentication procedure is available if a network access authentication procedure is
executed. In case of roaming the user's identity might not be executed. In case of roaming the user's identity might not be
available to the access network since security protocols might available to the access network since security protocols might
offer user identity confidentiality and thereby hiding the real offer user identity confidentiality and thereby hiding the real
identity of the user allowing the access network to only see a identity of the user allowing the access network to only see a
pseudonym or a randomized string. pseudonym or a randomized string.
Unique Client Identifier Unique Client Identifier
The DSL Forum has defined that all devices that expect to be The DSL Forum has defined that all devices that expect to be
managed by the TR-069 interface be able to generate an identifier 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. 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 It also has a requirement that routers that use DHCP to the WAN
use RFC 4361 [14] to provide the DHCP server with a unique client use RFC 4361 [18] to provide the DHCP server with a unique client
identifier. This identifier is, however, not visible to the identifier. This identifier is, however, not visible to the
Target when legacy NTE device are used. Target when legacy NTE device are used.
IP Address: IP Address:
The Target's IP address may be used for location determination. 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 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 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 location of a host that is located behind a NAT cannot be
determined by the access network. The LIS would in this case only determined by the access network. The LIS would in this case only
skipping to change at page 17, line 24 skipping to change at page 17, line 24
Requirement L7-7: Network Access Authentication Requirement L7-7: Network Access Authentication
The design of the L7 LCP MUST NOT assume prior network access The design of the L7 LCP MUST NOT assume prior network access
authentication. authentication.
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
[6] or NSIS NATFW NSLP [15] . [6] or NSIS NATFW NSLP [19] .
Requirement L7-9: Discovery Mechanism Requirement L7-9: Discovery Mechanism
The L7 LCP MUST define a mandatory-to-implement LIS discovery The L7 LCP MUST define a mandatory-to-implement LIS discovery
mechanism. 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].
7. Security Considerations 7. Security Considerations
This document contains security related requirements. A discussion This document contains security related requirements. A discussion
about security aspects of the HELD protocol when used in the GEOPRIV about security aspects of the HELD protocol when used in the GEOPRIV
architecture when applied to certain usage environments, such as architecture when applied to certain usage environments, such as
emergency services, can be found in [16]. emergency services, can be found in [23].
8. IANA Considerations 8. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
9. Contributors 9. Contributors
This contribution is a joint effort of the GEOPRIV Layer 7 Location This contribution is a joint effort of the GEOPRIV Layer 7 Location
Configuration Requirements Design Team of the IETF GEOPRIV Working Configuration Requirements Design Team of the IETF GEOPRIV Working
Group. The contributors include Henning Schulzrinne, Barbara Stark, Group. The contributors include Henning Schulzrinne, Barbara Stark,
skipping to change at page 22, line 23 skipping to change at page 22, line 23
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
March 2007. March 2007.
11.2. Informative References 11.2. Informative References
[4] Marshall, R., "Requirements for a Location-by-Reference [4] Marshall, R., "Requirements for a Location-by-Reference
Mechanism used in Location Configuration and Conveyance", Mechanism", draft-ietf-geopriv-lbyr-requirements-00 (work in
draft-marshall-geopriv-lbyr-requirements-02 (work in progress), progress), September 2007.
July 2007.
[5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol [5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
Requirements", draft-winterbottom-geopriv-lis2lis-req-00 (work Requirements", draft-winterbottom-geopriv-lis2lis-req-00 (work
in progress), June 2007. in progress), June 2007.
[6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- 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.
[7] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast [7] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-thomson-geopriv-lis-discovery-02 (work in progress),
July 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. Name Resolution (LLMNR)", RFC 4795, January 2007.
[8] Cheshire, S. and M. Krochmal, "Multicast DNS", [10] 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.
[9] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08 [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
progress), July 2007.
[13] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08
(work in progress), June 2007. (work in progress), June 2007.
[10] Aura, T., "Cryptographically Generated Addresses (CGA)", [14] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[11] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network [15] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005. Access Identifier", RFC 4282, December 2005.
[12] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [16] 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.
[13] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, [17] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003. "Diameter Base Protocol", RFC 3588, September 2003.
[14] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers [18] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
for Dynamic Host Configuration Protocol Version Four (DHCPv4)", for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
RFC 4361, February 2006. RFC 4361, February 2006.
[15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol [19] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in progress), (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in progress),
July 2007. July 2007.
[16] Barnes, R., "Threats to GEOPRIV Location Objects", [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] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
July 2007.
[23] Barnes, R., "Threats to GEOPRIV Location Objects",
draft-barnes-geopriv-lo-sec-00 (work in progress), July 2007. draft-barnes-geopriv-lo-sec-00 (work in progress), July 2007.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
 End of changes. 27 change blocks. 
36 lines changed or deleted 86 lines changed or added

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