GEOPRIV M. Linsner Internet-Draft J. Schnizlein Expires: July 29, 2006 Cisco Systems January 25, 2006 Location Configuration Protocol draft-linsner-geopriv-lcp-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006) Abstract Location Configuration Protocol provides a host with physical location based on its IP address. This document describes the communication protocol and mechanism for an IP host to discovery the physical location associated with its own IP address by communicating with a Location Information Server. This document describes the overall protocol and communication architecture. Linsner, Schnizlein Expires July 29, 2006 [Page 1] Internet-Draft LCP January 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. LIS Discovery . . . . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 3 7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1 Normative References . . . . . . . . . . . . . . . . . . 4 8.2 Informative References . . . . . . . . . . . . . . . . . 4 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 5 A. Intellectual Property and Copyright Statements . . . . . . . 5 1. Terminology In this document, the key words "MUST", "MUSTNOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 2. Definitions This document uses the following terms to describe Location Configuration Protocol (LCP): Location Information Server: (LIS) The server (service) operated by the entity with knowledge of physical location associated with hosts on a network. This is the entity that is the target of client LCP requests. 3. Introduction The LCP architecture of location configuration information distribution is patterned after the baseline dhcp architecture with a couple of differences. 1) Using the IP address as the identifier vs. the dhcp mechanism of using a media-access-control layer address plus optional relay agent information as the unique identifier. 2) Using TCP as the transport vs. UDP. The benefits of using IP address include not requiring relay agents operating within the infrastructure for unique parameters such as those used for location lookup using [2] or [3]. It is assumed that the LIS will deploy backend data functions such that correct location information can be derived using IP address. This backend mechanism is out of scope for this document. The LCP mechanism executes after dhcp/other configuration transactions thus requiring the client to be a full working IP host, and before establishing tunnels that disguise IP address. Linsner, Schnizlein Expires July 29, 2006 [Page 2] Internet-Draft LCP January 2006 If the clients network deploys Network Address Translation (NAT)/Port Address Translation (PAT) technology, normal NAT/PAT address/port substitution mechanisms will work since there is no application layer messaging that contains identifiers. The resultant location information would be matched to the IP address of the "outside" network. The purpose of LCP is to support environments either: (1) where there are obstacles to deploying relay-agent information options, or (2) where DHCP is not deployed. An example of one such environment is a broadband dsl service that currently utilizes Point-to-Point control protocols (PPPOE & IPCP) for client network configuration. In such an environment, it is claimed to be cost prohibitive to add the necessary DHCP relay agents to the in-place layer 2 architecture. 4. Overview The location configuration protocol (LCP) is a simple protocol that provides a host with its network derived location information, using the host IP address. The client connects to a Location Information Server (LIS), which matches the source IP address of the connection to location information that it returns on the connection. Since physical location knowledge is typically available to the access layer entity, it is assumed that the provider of the access layer operates the LIS that provides this service. LCP has the following properties, described more fully later in this document: - LCP is a "sighting" protocol as defined in [1]. - LCP utilizes a TCP connection to a well-known port on a LIS. - Only one simple client to LIS message is required; the LIS simply reacts to the TCP connection, matching the connections source IP address to a physical location. - The message returned to the client (requesting IP host) contains the LCI information formatted as defined in [2] and [3]. - LIS discovery can be via a DHCP option (possibly [4]); a yet-to-be defined PPP IPCP parameter; statically configured; or via broadcast using the well-known TCP port and broadcast forwarding functions available within layer 3 routers (if the LIS is located "off-net"). 5. LIS Discovery In order for a LCP client to query the LIS for location information, the client needs to know the IP address or FQDN of the LIS server. This can be accomplished using one of three mechanisms: 1) The LIS can be identified via DHCP, using [4] as an example. 2) The LIS can be identified via PPP control protocols using a newly (yet to be) defined IPCP parameter. 3) The client could IP-broadcast for the LIS, using the well-known port number. If the LIS is situated on the same broadcast domain as the client, the LIS could simply respond. Or, if the LIS is located on a Linsner, Schnizlein Expires July 29, 2006 [Page 3] Internet-Draft LCP January 2006 different L3 network, the client’s L3 router would need to be configured to forward the broadcast-to-well-known-port message to the LIS. This mechanism works identical to the current bootp forwarding mechanism deployed in L3 routers. 4) Statically configured 6. IANA Considerations IANA assigns well-known TCP port (tbd). 7. Security LCP addresses the following security issues, usually through the underlying transport security associations: Client impersonation: The use of TCP mitigates against a host spoofing a LCP client IP address because it requires reciprocal packet exchange 3- way-handshake to open the connection. Server impersonation: When using the broadcast mechanism for LIS discovery in a broadcast enabled layer 2 network, it is possible for LIS impersonation. LCP RECOMMENDS that the broadcast LIS discovery mechanism only be used in non-broadcast capable layer 2 networks and as the last resort by the client, where no LIS information is available via DHCP, IPCP, or statically. The use of server-side authentication, such as TLS [5] is also a recommended mechanism to assist in mitigating server impersonation. Query or query result corruption: To avoid that an attacker can modify and/or listen to the query or its result, LCP RECOMMENDS the client requests channel security, such as TLS [5]. 8. References 8.1 Normative References [1] RFC3693 Geopriv Requirements. J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. February 2004. [2] RFC3825 Dynamic Host Configuration Protocol Option for Coordinate- based Location Configuration Information. J. Polk, J. Schnizlein, M. Linsner. July 2004. [3] draft-ietf-geopriv-dhcp-civil-09 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information [4] draft-polk-dhc-uri-02 A Dynamic Host Configuration Protocol Option for Requesting and Receiving Uniform Resource Identifiers Linsner, Schnizlein Expires July 29, 2006 [Page 4] Internet-Draft LCP January 2006 8.2 Informative References [5] RFC3546 Transport Layer Security (TLS) Extensions. S. Blake- Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. June 2003. 9. Author's Address Marc Linsner Cisco Systems, Inc. Marco Island, Florida, USA Email: marc.linsner@cisco.com John Schnizlein Cisco Systems, Inc. Fort Washington, MD Email: john.schnizlein@cisco.com Comments are solicited and should be addressed to the working group's mailing list at geopriv@ietf.org and/or the authors. Appendix A. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Linsner, Schnizlein Expires July 29, 2006 [Page 5] Internet-Draft LCP January 2006 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Linsner, Schnizlein Expires July 29, 2006 [Page 6]