One document matched: draft-winterbottom-ecrit-location-scope-req-00.txt
Geopriv J. Winterbottom
Internet-Draft M. Thomson
Expires: August 10, 2005 M. Dawson
Nortel Networks
February 9, 2005
ECRIT Location Scope Requirements
draft-winterbottom-ecrit-location-scope-req-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Special kinds of services require user location information to be
authenticated and validated within a specific operating domain. An
example of such a service is the emergency services network, where
the location of a caller is known with in the domain of the telephone
network, while the name or true identity of the caller is not
intrinsically known. This paper describes the entities and key
Winterbottom, et al. Expires August 10, 2005 [Page 1]
Internet-Draft ECRIT Location Scope February 2005
requirements necessary to provide such a service in an internet
environment.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Key Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Requirement 1 . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Requirement 2 . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Requirement 3 . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Requirement 4 . . . . . . . . . . . . . . . . . . . . . . 5
3.5 Requirement 5 . . . . . . . . . . . . . . . . . . . . . . 6
3.6 Requirement 6 . . . . . . . . . . . . . . . . . . . . . . 6
3.7 Requirement 7 . . . . . . . . . . . . . . . . . . . . . . 6
3.8 Requirement 8 . . . . . . . . . . . . . . . . . . . . . . 6
3.9 Requirement 9 . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Normative references . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Winterbottom, et al. Expires August 10, 2005 [Page 2]
Internet-Draft ECRIT Location Scope February 2005
1. Introduction
Some network elements and services have special requirements on
information concerning a user's location that must be satisfied
before the service is provided to the user. The primary group of
services that fall into this category are the emergency services that
make use of a user's location to route calls to their destination and
subsequently dispatch service crews to that destination. Since the
cost of providing these services is high, and the risk to service
crews in many cases is life threatening, simply trusting that a user
has provided an accurate and valid location is not enough. The
service provider requires additional information tying the user to
his/her location and some audit trail to the access network servicing
the user in the event of a mishap. In the interests of continuous
improvement, it is desirable that incidences of erroneous location
information being provided can be traced back to an answerable access
provider and corrected. This paper describes a base set of
requirements that need to be met to satisfy emergency service
provider's and then goes on to place scope around these requirements
based on possible access types and situations.
Winterbottom, et al. Expires August 10, 2005 [Page 3]
Internet-Draft ECRIT Location Scope February 2005
2. Terminology
The key conventions and terminology used in this paper are defined as
follows:
End-User: The user or user device entity needing sending his/her
location to another entity in the network.
Domain: An area or group of services falling with in a specific
category or jurisdictional boundary.
Domain Authentication and Validation Entity: A node that has
authority within a given domain to authenticate and validate user
location information.
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, et al. Expires August 10, 2005 [Page 4]
Internet-Draft ECRIT Location Scope February 2005
3. Key Requirements
3.1 Requirement 1
The emergency network in most cases today is accessed via the PSTN
using either a wireline or a cellular device. In both cases location
information is provided by the Carrier and is used directly to route
the call. Since the Carrier must route the call to the emergency
network, the emergency network holds the carrier responsible for the
correct location determination and routing, and this forms the basis
of requirement 1. A certain level of authentication and validation
around the source of the location is required for the domain in which
the information is to be used.
3.2 Requirement 2
The location information MUST be attributed to a specific point in
time. That is, the location used for routing and which is reported
to the emergency services operator, must be the actual location of
the caller at the time of making the call. This provides operator's
with confidence that the End-User is at the location. This is
accomplished today with existing telephony networks either through
the use of a calling-number to address "wire-map" database, or for
cellular with more complex triangulation and GPS based techniques
where the location is determined by the network and delivered at the
time of the call.
3.3 Requirement 3
The location information MUST be attributed to a specific End-User.
That is, for each call initiated, the emergency network requires that
the location was determined for that specific caller and is not
reused from a location determination applicable to a different
End-User. This information defines when the location was attributed
to the End-User, thereby tying a valid location to a user at a
specific point in time.
3.4 Requirement 4
Requirement 1 states that a level of authentication and validation
for the source of the location is required. This implies the need to
for the End-User to determine the authenticating and validating
entity for the emergency services domain in which they reside. That
is, it must be possible for an End-User to discover and utilize an
answerable source of location in the access network they are using.
Winterbottom, et al. Expires August 10, 2005 [Page 5]
Internet-Draft ECRIT Location Scope February 2005
3.5 Requirement 5
The End-User must be able to establish a session with the access
domain authenticating and validating entity to obtain a certified
location. The authentication of the location is granted with an
expiry time, after which the location within the domain is deemed
invalid.
3.6 Requirement 6
The session between the End-User and the domain authenticating and
validating entity SHALL NOT require the true identity of the
End-User. That is, the true identity of the user need never be
revealed to the domain authenticating and validating entity, a random
unique pseudonym generated within the authenticated domain is
sufficient.
3.7 Requirement 7
The domain authenticating and validation entity MUST be able to
accept a location provided by an End-User. On receipt of the
End-User's location the domain authenticating and validation entity
SHOULD validate the location as being applicable to that domain that
is, it falls within reasonable geographic boundaries for that domain
- before returning the certified location to the End-User.
3.8 Requirement 8
The End-User may have no means of determining or providing a
location, in which case the domain authentication and validation
entity MAY provide an estimate of location.
3.9 Requirement 9
Where the End-User does not desire the transmission of their location
in-band with their call setup, they shall have the option of
requesting a unique query key such that only authorized end points
may query the location directly from the domain.
Winterbottom, et al. Expires August 10, 2005 [Page 6]
Internet-Draft ECRIT Location Scope February 2005
4. Security Considerations
The requirements put forth in this draft suggest signaling interfaces
which have a variety of potential threats. Each of the specific
protocols defined in support of these requirements must adequately
address those threats.
Winterbottom, et al. Expires August 10, 2005 [Page 7]
Internet-Draft ECRIT Location Scope February 2005
5. IANA Considerations
This document does not introduce any IANA considerations.
Winterbottom, et al. Expires August 10, 2005 [Page 8]
Internet-Draft ECRIT Location Scope February 2005
6. Acknowledgments
7 Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
Authors' Addresses
James Winterbottom
Nortel Networks
Wollongong
NSW Australia
EMail: winterb@nortelnetworks.com
Martin Thomson
Nortel Networks
Wollongong
NSW Australia
EMail: marthom@nortelnetworks.com
Martin Dawson
Nortel Networks
Wollongong
NSW Australia
EMail: mdawson@nortelnetworks.com
Winterbottom, et al. Expires August 10, 2005 [Page 9]
Internet-Draft ECRIT Location Scope February 2005
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
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.
Winterbottom, et al. Expires August 10, 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 07:07:36 |