One document matched: draft-ietf-geopriv-lbyr-requirements-01.txt
Differences from draft-ietf-geopriv-lbyr-requirements-00.txt
GeoPriv R. Marshall, Ed.
Internet-Draft TCS
Intended status: Informational October 11, 2007
Expires: April 13, 2008
Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-01
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 April 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Marshall Expires April 13, 2008 [Page 1]
Internet-Draft GEOPRIV LbyR Requirements October 2007
Abstract
This document defines terminology and provides requirements relating
to Location-by-Reference approach to handling location information
within signaling and other Internet messaging.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 8
5.1. Requirements for a Location Configuration Protocol . . . 8
5.2. Requirements for a Location Dereference Protocol . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Marshall Expires April 13, 2008 [Page 2]
Internet-Draft GEOPRIV LbyR Requirements October 2007
1. Introduction
Location-based services rely on ready access to location information,
which can be through a direct or indirect mechanism. While there is
already a direct mechanism which exists to provide location as part
of the SIP signaling protocol, an alternative mechanism has been
developed for handling location indirectly, via a location reference,
a reference which points to the actual location information. This
reference is called the location URI, and is used by the mechanism we
call Location-by-Reference, or LbyR.
Each of the actions by which a location URI can be used is
represented by specific individual protocol. For example, a Location
Configuration Protocol, is used by a device or middlebox to acquire a
location which already exists (examples of this protocol include
DHCP, LLDP-MED, and HELD [I-D.ietf-geopriv-http-location-delivery]).
The location configuration protocol problem statement and
requirements document can be found in [I-D.ietf-geopriv-l7-lcp-ps].
The action of conveying a location URI along from node to node
according to specific rules in SIP, for example, is known as a
conveyance protocol. A location dereferencing protocol, is used by a
client to resolve a location URI in exchange for location information
from a dereference server (e.g., a LIS).
The structure of this document first defines terminology, or points
to the appropriate draft where defined, in Section 3. Then a short
discussion on the basic elements which show LbyR. This section on
actors, Section 4 includes a basic model, and describes the steps
which the LbyR mechanism takes.
Requirements are outlined separately for location configuration,
Section 5.1, followed by those for a dereferencing protocol,
Section 5.2.
Location-by-Value, called LbyV, in contrast to LbyR, is a direct
location conveyance approach and includes the location object, e.g.,
a PIDF-LO [RFC4119] in the SIP signaling. Location conveyance is out
of scope for this document (see [I-D.ietf-sip-location-conveyance]
for an explanation of conveyance of location including both LbyR and
LbyV scenarios.
Location determination, which may include the processes of manual
provisioning, automated measurements, or location transformations,
(e.g., geo-coding), are beyond the scope of this document.
A detailed discussion of Identity information related to the caller,
subscriber, or device, as associated to location or location URI, is
also out of scope.
Marshall Expires April 13, 2008 [Page 3]
Internet-Draft GEOPRIV LbyR Requirements October 2007
2. Requirements Terminology
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 RFC 2119 [RFC2119].
Marshall Expires April 13, 2008 [Page 4]
Internet-Draft GEOPRIV LbyR Requirements October 2007
3. Terminology
This document reuses the terminology of [RFC3693], such as Location
Server (LS), Location Recipient (LR), Rule Maker (RM), Target,
Location Generator (LG), Location Object (LO), and Using Protocol:
3.1. Terms
Location-by-Value (LbyV): The mechanism of representing location
either in configuration or conveyance protocols, (i.e., the actual
included location value).
Location-by-Reference (LbyR): The mechanism of representing location
either in configuration, conveyance, or in dereferencing protocols
as an identifier which refers to a fully specified location,
(i.e., a pointer to the actual location value).
Location Configuration Protocol: A protocol which is used by a
client to acquire either location or a location URI from a
location configuration server, based on information unique to the
client.
Location Dereference Protocol: A protocol which is used by a client
to query a location dereference server, based on location URI
input and which returns location information.
Location URI: An identifier which serves as a pointer to a location
record on a remote host (e.g., LIS). Used within an Location-by-
Reference mechanism, a location URI is provided by a location
configuration server, and is used as input by a dereference
protocol to retrieve location from a dereference server.
Marshall Expires April 13, 2008 [Page 5]
Internet-Draft GEOPRIV LbyR Requirements October 2007
4. Basic Actors
In mobile wireless networks it is not efficient for the end host to
periodically query the LIS for up-to-date location information. This
is especially the case when power is a constraint or a location
update is not immediately needed. Furthermore, the end host might
want to delegate the task of retrieving and publishing location
information to a third party, such as to a presence server. Finally,
in some deployments, the network operator may not want to make
location information widely available.
These use scenarios motivated the introduction of the LbyR concept.
Depending on the type of reference, such as HTTP/HTTPS or SIP
Presence URI, different operations can be performed. While an HTTP/
HTTPS URI can be resolved to location information, a SIP Presence URI
provides further benefits from the SUBSCRIBE/NOTIFY concept that can
additionally be combined with location filters
[I-D.ietf-geopriv-loc-filters].
+-----------+ Geopriv +-----------+
| | Location | Location |
| LIS +---------------+ Recipient |
| | Dereference | |
+-----+-----+ Protocol (3) +----+------+
| --
| Geopriv --
| Location --
| Configuration --
| Protocol --
| (1) -- Geopriv
| -- Using Protocol
| -- (e.g., SIP)
+-----+-----+ -- (2)
| Target / |--
| End Host +
| |
+-----------+
Figure 1: Shows the assumed communication model for both a layer 7
location configuration protocol and a dereference protocol:
Note that there is no requirement for using the same protocol in (1)
and (3).
The following list describes the location subscription approach:
Marshall Expires April 13, 2008 [Page 6]
Internet-Draft GEOPRIV LbyR Requirements October 2007
1. The end host discovers the LIS.
2. The target (end host) sends a request to the LIS asking for a
location URI, as shown in (1) of Figure 1.
3. The LIS responds to the request and includes a location object
along with a subscription URI.
4. The Target puts the subscription URI into a SIP message and
forwards it to a Location Recipient via a using protocol, as shown in
(2) of Figure 1. The Location Recipient subscribes to the obtained
subscription URI (see (3) of Figure 1) and potentially uses a
location filter (see [I-D.ietf-geopriv-loc-filters]) to limit the
notification rate.
5. If the Target moves outside a certain area, indicated by a
location filter, the Location Recipient will receive a notification.
Note that the Target may also act in the role of the Location
Recipient whereby it would subscribe to its own location information.
For example, the Target obtains a subscription URI from the Geopriv
L7 Location Configuration Protocol. It subscribes to the URI in
order to obtain its current location information. A service boundary
indicates the bounded extent up to which the device can move without
the need to have an updated location, since a re-query with any
location within the boundary would result in the same answer returned
from a location-based service.
For LbyR, the LIS needs to maintain a list of randomized location
URIs for each host, timing out each of these URIs after the reference
expires. Location URIs need to expire to prevent the recipient of
such a URI from being able to (in some cases) permanently track a
host. Furthermore, an expiration mechanism also offers garbage
collection capability for the LIS.
Location URIs must be designed to prevent adversaries from obtaining
a known Target's location. There are at least two approaches: The
location URI contains a random component which helps obscure
sequential updates to location, yet still allows any holder of the
location URI to obtain location information. Alternatively, the
location URI can remain public and the LIS performs access control
via a separate authentication mechanism, such as HTTP digest or TLS
client side authentication, when resolving the reference to a
location object.
Marshall Expires April 13, 2008 [Page 7]
Internet-Draft GEOPRIV LbyR Requirements October 2007
5. High-Level Requirements
This document outlines only requirements for an LbyR mechanism which
is used by two different protocols, a location configuration
protocol, and a location dereferencing protocol. Each of these
protocols has its own unique client and server interactions, and the
requirements here are not intended to state what a client or server
is expected to do, but rather which requirements must be met by
either the configuration or dereferencing protocol itself.
5.1. Requirements for a Location Configuration Protocol
Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location
configuration protocol.
C1. Location URI support: The configuration protocol MUST support a
location reference in URI form.
Motivation: It is helpful to have a consistent form of key for the
LbyR mechanism.
C2. Location URI expiration: The lifetime of a location URI SHOULD
be indicated.
Motivation: Location URIs are not intended to represent a location
forever, and the identifier eventually may need to be recycled, or
may be subject to a specific window of validity, after which the
location reference fails to yield a location, or the location is
determined to be kept confidential.
C3. Location URI cancellation: The location configuration protocol
SHOULD support the ability to request a cancellation of a specific
location URI.
Motivation: If the client determines that in its best interest to
destroy the ability for a location URI to effectively be used to
dereference a location, then there should be a way to nullify the
location URI.
C4. Random Generated: The location URI MUST be hard to guess, i.e.,
it MUST contain a cryptographically random component.
Motivation: There is some benefit to the client if the location
URI is generated in an obscured manner so that its sequence, for
example in the case of a client's location update, can't be easy
guessed.
Marshall Expires April 13, 2008 [Page 8]
Internet-Draft GEOPRIV LbyR Requirements October 2007
C5. Identity Protection: The location URI MUST NOT contain any
information that identifies the user, device or address of record
within the URI form.
Motivation: It is important to protect caller identity or contact
address from being included in the form of the location URI itself
when it is generated.
C6. Reuse indicator: There SHOULD be a way to allow a client to
control whether a location URI can be resolved once or multiple
times.
Motivation: The client requesting a location URI may request a
location URI which has a 'one-time-use' only characteristic, as
opposed to a location URI having multiple reuse capability.
C7. Location timestamp: There SHOULD be a way to allow a client to
determine whether the dereferenced location information refers to
the location of the Target at the time when the location URI was
created or when it was dereferenced.
Motivation: It is important to distinguish between an original and
an updated location.
5.2. Requirements for a Location Dereference Protocol
Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location
dereference protocol.
D1. Location URI support: The location dereference protocol MUST
support a location reference in URI form.
Motivation: It is required that there be consistency of use
between location URI formats used in an configuration protocol and
those used by a dereference protocol.
D2. Location URI expiration status: The location dereference
protocol MUST support a message indicating that for a location URI
which is no longer valid, that the location URI has expired.
Motivation: Location URIs are expected to expire, based on
location configuration protocol parameters, and it is therefore
useful to convey the expired status of the location URI in the
location dereference protocol.
Marshall Expires April 13, 2008 [Page 9]
Internet-Draft GEOPRIV LbyR Requirements October 2007
D3. Authentication: The location dereference protocol MUST support
either client-side and server-side authentication.
Motivation: It is reasonable to expect implementations of
authentication to vary. Some implementations may choose to
implement both client-side and server-side authentication, might
implement one only, or may implement neither.
D4. Dereferenced Location Form: The dereferenced location MUST
result in a well-formed PIDF-LO.
Motivation: This is in order to ensure that adequate privacy rules
can be adhered to, since the PIDF-LO format comprises the
necessary structures to maintain location privacy.
D5. Repeated use: The location dereference protocol MUST support the
ability for the same location URI to be resolved more than once,
based on server settings and configuration server parameters.
Motivation: According to configuration server parameters, it may
be necessary to have a limit on the number of dereferencing
attempts.
Marshall Expires April 13, 2008 [Page 10]
Internet-Draft GEOPRIV LbyR Requirements October 2007
6. Security Considerations
The LbyR mechanism currently addresses security issues as follows.
A location URI, regardless of its randomized construction, if
public, implies no safeguard against anyone being able to
dereference and get the location. The randomization of a location
URI in its naming does help prevent some potential guessing,
according to some defined pattern. In the instance of one-time-
use location URIs, which function similarly to a pawn ticket, the
argument can be made that with a pawn ticket, possession implies
permission, and location URIs which are public are protected only
by privacy rules enforced at the dereference server.
Additional security issues will be discussed in the geopriv draft,
draft-barnes-geopriv-lo-sec-00.txt.
Marshall Expires April 13, 2008 [Page 11]
Internet-Draft GEOPRIV LbyR Requirements October 2007
7. IANA Considerations
This document does not require actions by the IANA.
Marshall Expires April 13, 2008 [Page 12]
Internet-Draft GEOPRIV LbyR Requirements October 2007
8. Acknowledgements
We would like to thank the IETF GEOPRIV working group chairs, Andy
Newton, Allison Mankin and Randall Gellens, for creating the design
team which initiated this requirements work. We'd also like to thank
those design team participants for their inputs, comments, and
reviews. The design team included the following folks: Richard
Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted Hardie;
Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; Roger
Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen;
John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes
Tschofenig; Martin Thomson; and James Winterbottom.
Marshall Expires April 13, 2008 [Page 13]
Internet-Draft GEOPRIV LbyR Requirements October 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.
9.2. Informative References
[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.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.
[I-D.ietf-geopriv-loc-filters]
Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in the Presence Information Document
Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-01 (work in progress),
March 2007.
[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol",
draft-ietf-sip-location-conveyance-08 (work in progress),
July 2007.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
Marshall Expires April 13, 2008 [Page 14]
Internet-Draft GEOPRIV LbyR Requirements October 2007
Appendix A. Change log
Changes to this draft in comparison to the -00 version:
1. Shortened Abstract and Introduction.
2. LDP term gone. Expansion of Location Dereferencing Protocol,
deletion of "LDP" acronym throughout, since LDP stands for Label
Distribution Protocol elsewhere in the IETF.
3. LCP term is also gone. LCP is used as Link Control Protocol
elsewhere (IETF).
4. Reduced the number of terms in the doc. Referenced other drafts
or RFCs for repeated terms.
5. Requirement C2. changed to indicate that the URI has a lifetime.
6. C3. Softened by changing from a MUST to a SHOULD.
7. C6. Reworded for clarity.
8. C7. Changed the MUST to a SHOULD to reflect a more appropriate
level.
9. D6. Replaced the text to make it clearer.
10. D7. Deleted the requirement since it wasn't an appropriate task
for the protocol.
11. Referenced Richard's security document
12. Cleaned up some text.
Marshall Expires April 13, 2008 [Page 15]
Internet-Draft GEOPRIV LbyR Requirements October 2007
Author's Address
Roger Marshall (editor)
TeleCommunication Systems, Inc.
2401 Elliott Avenue
2nd Floor
Seattle, WA 98121
US
Phone: +1 206 792 2424
Email: rmarshall@telecomsys.com
URI: http://www.telecomsys.com
Marshall Expires April 13, 2008 [Page 16]
Internet-Draft GEOPRIV LbyR Requirements October 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).
Marshall Expires April 13, 2008 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-21 21:15:41 |