LIS to LIS Protocol Requirements
draft-winterbottom-geopriv-lis2lis-req-01.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 22, 2008.

Abstract

This document describes requirements for a LIS to LIS protocol and provides examples of where such a protocol is applicable.

Table of Contents

1.  Introduction
2.  Terminology
3.  Overview
4.  Assumptions
5.  Requirements
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative references
    9.2.  Informative references
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The architecture of some networks results in more than one operator being involved in providing Internet connectivity to an end-point. Examples of this type of configuration are prevalent in residential broadband access environments where the physical infrastructure is owned by one operator, while a third-party ISP provides an IP address and layer 3 connectivity to the Internet. In architectures such as these, the Internet connectivity service is dependent on both providers. Similarly, both have information about the connectivity of an end-point to the network. The information that one party holds, however, is usually different to the information held by the other party, and neither party (on its own) can use the information it possesses to yield the physical location of an end-point. However, when the connectivity information held by the two parties is combined the location of the end-point can be determined.

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] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.).

This document uses the term Location Information Server (LIS) as defined in [I‑D.ietf‑geopriv‑l7‑lcp‑ps] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.).

Broadband Remote Access Server (BRAS). A node in a DSL network responsible for switching data streams between end-points and Internet Service Providers.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Overview

The Geopriv L7 LCP requirements [I‑D.ietf‑geopriv‑l7‑lcp‑ps] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.) describe a range of network topologies in which a Target should be able to acquire its location from a LIS using an application layer location acquisition protocol. The scope of [I‑D.ietf‑geopriv‑l7‑lcp‑ps] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.) is such that it does not address specific network topologies that may exist inside the access network provider domain. This document provides scope and requirements for LIS to LIS communications where the two servers are controlled by different operators each running a part of the access network. While the same principles may be applied to inter-LIS communication occurring between a LIS in the customer premise network and the access provider network, operation in this configuration is not considered in scope for this document.

   +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
   |                            |    |                                |
   |        Regional            |    |        INTERNET Service        |
   |  Access Network Provider   |    |            Provider            |
   |                            |    |          +------------------+  |
   |   +------------+           |    |          |  Network Access  |  |
   |   | Switching  |-------------------------->|      Server      |  |
   |   +------------+           |    |          +------------------+  |
   |         ^   |     +-----+  |    |  +-----+      |                |
   |         |   |     |     |  |    |  |     |      |                |
   |         |   +---->| LIS |<========>| LIS |<-----+                |
   |         |         |     |  |    |  |     |                       |
   |         |         +-----+  |    |  +-----+                       |
   |         |            ^     |    |                                |
   |     +--------+       |     |    |                                |
   |     | Access |-------+     |    |                                |
   |     |  Node  |             |    |                                |
   |     +----+---+             |    |                                |
   |          |                 |    |                                |
   |          |                 |    |                                |
   +~~~~~~~~~~~~~~~~~~~~~~~~~Access Network~~~~~~~~~~~~~~~~~~~~~~~~~~~+
              |
     <----------------> Cable Plant
              |
     +--------+----------+
     |                   |
     | Customer Premises |
     |                   |
     +-------------------+

Figure 1 (Multi-Operator Access Network) illustrates a typical multi-operator access network where physical and switched connectivity is provided by a Regional Access Network Provider, and higher layer routing functions are provided by an Internet Service provider (ISP). It is the ISP that owns the relationship with the broadband customer, the end-point, and it is the ISP LIS that will be contacted by any end-point to provide location. The ISP will know network parameters such as the IP address allocated to the end-point, and the associated NAS and port the incoming connection is terminated on; but it often will not know any information pertaining to connectivity (physical or logical) inside the regional access network. Conversely in many situations the regional access provider will not have access to information such as the IP address of the end-point or a means to correlate the IP address with other known physical parameters. The regional access provider will have access to information from the switch core, the access node, and cable termination records, allowing the regional access provider LIS to determine a physical location. Common information between the ISP NAS and the Regional Access Provider's switching core, such as circuit identifiers, are required in order to ensure correct data transmission through the network, and these can be used as Target identifiers from the ISP LIS to the Regional Access LIS allowing the physical location of an end-point to be retrieved.

This document describes the requirements for this information flow.

4.  Assumptions

This section details the high-level assumptions made in this document.

1:

A strong trust relationship exists between the regional access provider and ISP.

2:

Targets only deal directly with the ISP LIS, and may be totally unaware of any regional access provider LIS. A regional access LIS will only ever receive location requests from an ISP LIS.

5.  Requirements

This section details the requirements that MUST be satisfied by any LIS to LIS protocol

1:

Connections (physical and logical) from the ISP LIS to the regional access LIS require both ends to authenticate as part of connection establishment. The security of the data conveyed between the two servers MUST be ensured for both privacy and integrity.

2:

The data used to identify a Target to the ISP MUST be able to be passed to, and be recognizable by the regional access LIS using the LIS to LIS protocol. The data used to identify a Target to the ISP MUST be consistent with the traffic aggregation method supported by the Regional Access Network Provider.

3:

Location information returned over a LIS to LIS protocol MUST be in PIDF-LO [RFC4119] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) format, and MUST comply with [I‑D.ietf‑geopriv‑pdif‑lo‑profile] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.) .

4:

The type of location information requested by the end-point MUST be relayed to the regional access LIS by the ISP LIS using the LIS to LIS protocol.

5:

The method used by the regional access LIS to determine the location of the Target MUST be provided to the ISP LIS along with the determined location.

6:

Any usage-rule preferences provided by the Target to the ISP LIS MUST be included in any location returned to the Target or Location Recipient.

7:

Additional information provided by the Target to the ISP in a location request that cannot be processed directly by the ISP LIS MUST be forwarded to regional access LIS using the LIS to LIS protocol. The intention of this requirement is to support future LCP functions that require additional information from the Target.

8:

The presentity in the PIDF-LO returned by the regional access LIS MUST have been provided by the ISP LIS. The ISP LIS may create the presentity, or it may have received a presentity from the Target.

9:

The protocol MUST provide support for returning and dealing with error conditions such as “no location found” or “timeout”.

6.  Security Considerations

LIS to LIS communications are necessary in some network architectures and care must be taken to ensure that they are secure both from a privacy perspective and from an integrity perspective. This can be achieved in the most part with existing protocol suites, such as TLS, using certificates or pre-shared keys. Another factor that must be protected against is the ability of a legitimate ISP LIS asking for the location of an end-point associated with a different ISP. Operators of regional access servers will need to ensure that this operational requirement is met.

7.  IANA Considerations

There are no IANA considerations for this document.

8.  Acknowledgements

Thanks to Guy Caron and Barbara Stark for providing early reviews of this document. Thanks to Martin Thomson and Cullen Jennings for providing comments.

9.  References

9.1. Normative references

9.2. Informative references

Authors' Addresses

Full Copyright Statement

Copyright © 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.