Geopriv J. Winterbottom
Internet-Draft Andrew Corporation
Intended status: Standards Track S. Norreys
Expires: December 16, 2007 British Telecom
June 14, 2007
LIS to LIS Protocol Requirements
draft-winterbottom-geopriv-lis2lis-req-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 December 16, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Winterbottom & Norreys Expires December 16, 2007 [Page 1]
Internet-Draft LIS_2_LIS-Req June 2007
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative references . . . . . . . . . . . . . . . . . . . 13
9.2. Informative references . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Winterbottom & Norreys Expires December 16, 2007 [Page 2]
Internet-Draft LIS_2_LIS-Req June 2007
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.
Winterbottom & Norreys Expires December 16, 2007 [Page 3]
Internet-Draft LIS_2_LIS-Req June 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, to
represent a combined Location Server and Location Generator (as
defined in [RFC3693]) residing inside the local access domain.
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].
Winterbottom & Norreys Expires December 16, 2007 [Page 4]
Internet-Draft LIS_2_LIS-Req June 2007
3. Overview
The Geopriv L7 LCP requirements [I-D.ietf-geopriv-l7-lcp-ps] 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] is
such that it does not address specific network topologies that may
exist inside 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 provider 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
Winterbottom & Norreys Expires December 16, 2007 [Page 5]
Internet-Draft LIS_2_LIS-Req June 2007
Figure 1 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.
Winterbottom & Norreys Expires December 16, 2007 [Page 6]
Internet-Draft LIS_2_LIS-Req June 2007
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: End-points 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.
Winterbottom & Norreys Expires December 16, 2007 [Page 7]
Internet-Draft LIS_2_LIS-Req June 2007
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 an end-point 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 an end-point
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] format, and MUST comply with
[I-D.ietf-geopriv-pdif-lo-profile] .
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 end-point MUST be provided to the ISP LIS along
with the determined location.
6: Any usage-rule preferences provided by the end-point to the ISP
LIS MUST be included in any location returned to the end-point.
7: Where location signing is requested by the end-point, this request
MUST be forwarded to regional access LIS using the LIS to LIS
protocol
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 end-
point.
Winterbottom & Norreys Expires December 16, 2007 [Page 8]
Internet-Draft LIS_2_LIS-Req June 2007
9: The protocol MUST provide support for returning and dealing with
error conditions such as "no location found" or "timeout".
Winterbottom & Norreys Expires December 16, 2007 [Page 9]
Internet-Draft LIS_2_LIS-Req June 2007
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.
Winterbottom & Norreys Expires December 16, 2007 [Page 10]
Internet-Draft LIS_2_LIS-Req June 2007
7. IANA Considerations
There are no IANA considerations for this document.
Winterbottom & Norreys Expires December 16, 2007 [Page 11]
Internet-Draft LIS_2_LIS-Req June 2007
8. Acknowledgements
Thanks to Guy Caron and Barbara Stark for providing early reviews of
this document.
Winterbottom & Norreys Expires December 16, 2007 [Page 12]
Internet-Draft LIS_2_LIS-Req June 2007
9. References
9.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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-02 (work in
progress), April 2007.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[I-D.ietf-geopriv-pdif-lo-profile]
Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-07 (work in progress),
April 2007.
9.2. Informative references
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
Winterbottom & Norreys Expires December 16, 2007 [Page 13]
Internet-Draft LIS_2_LIS-Req June 2007
Authors' Addresses
James Winterbottom
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
Email: james.winterbottom@andrew.com
Steve Norreys
British Telecom
UK
Email: steve.norreys@bt.com
Winterbottom & Norreys Expires December 16, 2007 [Page 14]
Internet-Draft LIS_2_LIS-Req June 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 & Norreys Expires December 16, 2007 [Page 15]