Geopriv J. Winterbottom Internet-Draft M. Thomson Intended status: Best Current Andrew Corporation Practice November 9, 2007 Expires: May 12, 2008 Using HELD for Inter-LIS Communication draft-winterbottom-geopriv-held-lis2lis-bcp-00.txt 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 May 12, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Winterbottom & Thomson Expires May 12, 2008 [Page 1] Internet-Draft LIS to LIS BCP November 2007 Abstract This document describes how HELD can be used to support LIS to LIS communication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative references . . . . . . . . . . . . . . . . . . . 12 8.2. Informative references . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Winterbottom & Thomson Expires May 12, 2008 [Page 2] Internet-Draft LIS to LIS BCP November 2007 1. Introduction The LIS to LIS communication requirements [I-D.winterbottom-geopriv-lis2lis-req] describe the need in some network environements for one LIS to consult another LIS in order to determine the location of a Device. This document describes how HELD [I-D.ietf-geopriv-http-location-delivery] in conjunction with the HELD identity extensions [I-D.winterbottom-geopriv-held-identity-extensions] and the HELD measurements specification [I-D.thomson-geopriv-held-measurements] can be used to satisfy these requirements. No new schema is introduced by this document, recipes using existing specifications are described. Winterbottom & Thomson Expires May 12, 2008 [Page 3] Internet-Draft LIS to LIS BCP November 2007 2. Terminology The key conventions and terminology used in this document are defined as follows: This document reuses the terms Target, as defined in [RFC3693]. This document uses the term Location Information Server, LIS, is used as defined in [I-D.ietf-geopriv-l7-lcp-ps]. Basic terms from the HELD specification [I-D.ietf-geopriv-http-location-delivery] are also reused. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Winterbottom & Thomson Expires May 12, 2008 [Page 4] Internet-Draft LIS to LIS BCP November 2007 3. Overview The network scenario described in [I-D.winterbottom-geopriv-lis2lis-req] shows that in some environments the LIS publically associated with a Device cannot, on its own, determine the location of the Device. HELD provides a specification allowing a Device to obtain location information from a Location Information Server (LIS). This specification extends HELD by chaining a location request from the publically accessible LIS to a LIS controlled by a regional access provider. The publically accessible LIS can also add measured and identity parameters relating to the Device in the HELD locationRequest made to the access provider LIS. Resuing HELD in this manner reduces the number of protocols that need to be supported on a LIS, it simplfies development, reduces complexity, and improves interoperability. Winterbottom & Thomson Expires May 12, 2008 [Page 5] Internet-Draft LIS to LIS BCP November 2007 4. Detailed Description In a typical environment using HELD, the Target discovers the LIS using one of the methods described in [I-D.thomson-geopriv-lis-discovery], and makes a request for location information. The ISP LIS receives the location request from the Target, adds additional information, and then sends the location request on to the regional access provider LIS. The regional access provider LIS uses the extra information provided in the ISP LIS to determine the location of the Device and provide the PIDF-LO [RFC4119] in the requested form. The ISP LIS will, in many cases creates the identity used in the "pres" field of the PIDF-LO. This value needs to be conveyed from the ISP LIS to the regional access provider LIS. HELD can convey this value using a URI identity extension as described in [I-D.winterbottom-geopriv-held-identity-extensions]. The ISP LIS may need to provide Device network attachment information, in the form of measurements, to the regional access provider LIS to aid it in determing the Device's location. A comprehensive set of measurements and how they are used is provided in [I-D.thomson-geopriv-held-measurements]. HELD supports the inclusion of these additional elements without modification. The ISP LIS should not send a request for a location URI to the regional access provider LIS. This is because the regional access provider LIS is, in most cases, invisible to entities other than the ISP LIS. A location URI contains the hostname of the LIS that will service a location request, which is the ISP LIS and not the regional access provider LIS. Consequently only the ISP LIS should create location URIs for the Device. A regional access provider LIS receiving a request for a location URI from an ISP LIS should respond with a "cannotProvideLiType" error. The ISP LIS should pass all elements included in the Device's location request to the regional access provider LIS, with the exception of a request for a location URI which was described in the previous paragraph. This behaviour ensures that any new options made available to the LIS through HELD can be supported without necessarily requiring changes to the ISP LIS. The ISP LIS should provide usage in any returned location object that match the user's desired settings, or in the absence of these, the default settings for and as applied by the ISP LIS. Basic HELD is provided with an HTTP binding, which is suitable for Winterbottom & Thomson Expires May 12, 2008 [Page 6] Internet-Draft LIS to LIS BCP November 2007 the application of a Device requesting its own location. Where a nailed up connection between two entities and continual transaction streaming is required, HTTP may be less appropriate. In this configuration an alternative transport, such as BEEP [I-D.thomson-geopriv-held-beep], may be used. Winterbottom & Thomson Expires May 12, 2008 [Page 7] Internet-Draft LIS to LIS BCP November 2007 5. Examples In this example a DSL service is provided with an L2TP tunnel forming the link between the BRAS in the regional access provider's network, and the NAS in the ISP. The Device has requested a civic location. The resulting location request sent from the ISP LIS to the regional access provider LIS is shown in Figure 1. civic pres:3sijsskcknckj@ls.example.com 192.0.2.10 192.0.2.61 528 Figure 1: LIS to LIS Location Request with L2TP Measurements The regional access provider LIS would use the L2TP tunnel information to establish the location of the Device. It would then create a PIDF-LO using the URI specified as a as the presentity value. The resulting location response from the access provider LIS to the ISP LIS may look something similar to Figure 2. On receiving this response the ISP LIS will need to add the usage rules specified by the Device or use local defaults if no Device instructions are available. Winterbottom & Thomson Expires May 12, 2008 [Page 8] Internet-Draft LIS to LIS BCP November 2007 AU NSW Wollongong Gwynneville Northfield Avenue University of Wollongong 2 Andrew Corporation 2500 39 WS-183 U40 2007-10-31T03:42:28+00:00 Figure 2: Regional Access Provider LIS Response Winterbottom & Thomson Expires May 12, 2008 [Page 9] Internet-Draft LIS to LIS BCP November 2007 6. Security Considerations A strong trust relationship needs to exist between the ISP and the regional access provider in order for this type of access network to operate successfully. Since this document describes the exchange of Device location information between two trusted parties it does not mandate the use of any specific crypto techniques but recommends the use of TLS with client-side and server-side certificates for authentication. Winterbottom & Thomson Expires May 12, 2008 [Page 10] Internet-Draft LIS to LIS BCP November 2007 7. IANA Considerations There are no IANA considerations for this document. Winterbottom & Thomson Expires May 12, 2008 [Page 11] Internet-Draft LIS to LIS BCP November 2007 8. References 8.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-02 (work in progress), September 2007. [I-D.winterbottom-geopriv-lis2lis-req] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol Requirements", draft-winterbottom-geopriv-lis2lis-req-00 (work in progress), June 2007. [I-D.winterbottom-geopriv-held-identity-extensions] Winterbottom, J. and M. Thomson, "HELD Device identity Extensions", draft-winterbottom-geopriv-held-identity-extensions-03 (work in progress), October 2007. [I-D.thomson-geopriv-held-measurements] Thomson, M. and J. Winterbottom, "Using Device-provided Location Measurements in HELD", draft-thomson-geopriv-held-measurements-00 (work in progress), October 2007. 8.2. Informative references [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [I-D.thomson-geopriv-held-beep] Thomson, M. and J. Winterbottom, "A BEEP Binding for the HELD Protocol", draft-thomson-geopriv-held-beep-00 (work in progress), February 2007. [I-D.thomson-geopriv-lis-discovery] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", Winterbottom & Thomson Expires May 12, 2008 [Page 12] Internet-Draft LIS to LIS BCP November 2007 draft-thomson-geopriv-lis-discovery-03 (work in progress), September 2007. [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in progress), September 2007. Winterbottom & Thomson Expires May 12, 2008 [Page 13] Internet-Draft LIS to LIS BCP November 2007 Authors' Addresses James Winterbottom Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Email: james.winterbottom@andrew.com Martin Thomson Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Email: martin.thomson@andrew.com Winterbottom & Thomson Expires May 12, 2008 [Page 14] Internet-Draft LIS to LIS BCP November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Winterbottom & Thomson Expires May 12, 2008 [Page 15]