GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew
Expires: January 6, 2011 July 5, 2010
Using Device-provided Location-Related Measurements in Location
Configuration Protocols
draft-ietf-geopriv-held-measurements-00
Abstract
A method is described by which a Device is able to provide location-
related measurement data to a LIS within a request for location
information. Location-related measurement information are
observations concerning properties related to the position of a
Device, which could be data about network attachment or about the
physical environment. When a LIS generates location information for
a Device, information from the Device can improve the accuracy of the
location estimate. A basic set of location-related measurements are
defined, including common modes of network attachment as well as
assisted Global Navigation Satellite System (GNSS) parameters.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 6, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Thomson & Winterbottom Expires January 6, 2011 [Page 1]
Internet-Draft Location Measurements July 2010
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Thomson & Winterbottom Expires January 6, 2011 [Page 2]
Internet-Draft Location Measurements July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions used in this document . . . . . . . . . . . . . . 6
3. Location-Related Measurements in LCPs . . . . . . . . . . . . 7
4. Location-Related Measurement Data Types . . . . . . . . . . . 8
4.1. Measurement Container . . . . . . . . . . . . . . . . . . 9
4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 9
4.1.2. Expiry Time on Location-Related Measurement Data . . . 9
4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 10
4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . . 10
4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 11
4.4. Identifying Location Provenance . . . . . . . . . . . . . 12
5. Location-Related Measurement Data Types . . . . . . . . . . . 14
5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 14
5.2. DHCP Relay Agent Information Measurements . . . . . . . . 15
5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 15
5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 18
5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 18
5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 21
5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 21
5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . . 23
5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . . 24
5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 25
5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 25
5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 26
5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 26
5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 27
5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 27
6. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 27
6.1. Measurement Container Schema . . . . . . . . . . . . . . . 28
6.2. Measurement Source Schema . . . . . . . . . . . . . . . . 30
6.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 30
6.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 33
6.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 34
6.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 36
6.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 39
6.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 41
6.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 43
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 45
7.1. Measurement Data Privacy Model . . . . . . . . . . . . . . 45
7.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . . 46
7.3. Measurement Data and Location URIs . . . . . . . . . . . . 46
7.4. Third-Party-Provided Measurement Data . . . . . . . . . . 46
8. Security Considerations . . . . . . . . . . . . . . . . . . . 47
8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 47
8.1.1. Acquiring Location Information Without
Thomson & Winterbottom Expires January 6, 2011 [Page 3]
Internet-Draft Location Measurements July 2010
Authorization . . . . . . . . . . . . . . . . . . . . 47
8.1.2. Extracting Network Topology Data . . . . . . . . . . . 48
8.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . . 49
8.1.4. Measurement Replay . . . . . . . . . . . . . . . . . . 50
8.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 50
8.2.1. Measurement Validation . . . . . . . . . . . . . . . . 51
8.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 51
8.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 51
8.2.2. Location Validation . . . . . . . . . . . . . . . . . 52
8.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 53
8.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 53
8.2.3. Supporting Observations . . . . . . . . . . . . . . . 53
8.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 54
8.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 54
8.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 55
8.2.5. Stateful Correlation of Location Requests . . . . . . 56
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 56
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 57
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 58
9.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 59
9.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 59
9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 60
9.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 61
9.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 61
9.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 62
9.10. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 63
9.11. XML Schema Registration for Measurement Source Schema . . 63
9.12. XML Schema Registration for Measurement Container
Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.13. XML Schema Registration for Base Types Schema . . . . . . 64
9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 64
9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 64
9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 65
9.17. XML Schema Registration for Cellular Schema . . . . . . . 65
9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 65
9.19. XML Schema Registration for DSL Schema . . . . . . . . . . 66
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Thomson & Winterbottom Expires January 6, 2011 [Page 4]
Internet-Draft Location Measurements July 2010
11.1. Normative References . . . . . . . . . . . . . . . . . . . 66
11.2. Informative References . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68
Thomson & Winterbottom Expires January 6, 2011 [Page 5]
Internet-Draft Location Measurements July 2010
1. Introduction
A location configuration protocol (LCP) provides a means for a Device
to request information about its physical location from an access
network. A location information server (LIS) is the server that
provides location information; information that is available due to
the knowledge about the network and physical environment that is
available to the LIS.
As a part of the access network, the LIS is able to acquire
measurement results from network Devices within the network that are
related to Device location. The LIS also has access to information
about the network topology that can be used to turn measurement data
into location information. However, this information can be enhanced
with information acquired from the Device itself.
A Device is able to make observations about its network attachment,
or its physical environment. The location-related measurement data
might be unavailable to the LIS; alternatively, the LIS might be able
to acquire the data, but at a higher cost in time or otherwise.
Providing measurement data gives the LIS more options in determining
location, which could improve the quality of the service provided by
the LIS. Improvements in accuracy are one potential gain, but
improved response times and lower error rates are also possible.
This document describes a means for a Device to report location-
related measurement data to the LIS. Examples based on the HELD
[I-D.ietf-geopriv-http-location-delivery] location configuration
protocol are provided.
2. Conventions used in this document
The terms LIS and Device are used in this document in a manner
consistent with the usage in
[I-D.ietf-geopriv-http-location-delivery].
This document also uses the following definitions:
Location Measurement: An observation about the physical properties
of a particular Device's network access. The result of a location
measurement--"location-related measurement data", or simply
"measurement data" given sufficient context--can be used to
determine the location of a Device. Location-related measurement
data does not identify a Device; measurement data can change with
time if the location of the Device also changes.
Location-related measurement data does not necessarily contain
Thomson & Winterbottom Expires January 6, 2011 [Page 6]
Internet-Draft Location Measurements July 2010
location information directly, but it can be used in combination
with contextual knowledge of the network, or algorithms to derive
location information. Examples of location-related measurement
data are: radio signal strength or timing measurements, Ethernet
switch and port identifiers.
Location-related measurement data can be considered sighting
information, based on the definition in [RFC3693].
Location Estimate: The result of location determination, a location
estimate is an approximation of where the Device is located.
Location estimates are subject to uncertainty, which arise from
errors in measurement results.
GNSS: Global Navigation Satellite System. A satellite-based system
that provides positioning and time information. For example, the
US Global Positioning System (GPS) or the European Galileo system.
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].
3. Location-Related Measurements in LCPs
This document defines a standard container for the conveyance of
location-related measurement parameters in location configuration
protocols. This is an XML container that identifies parameters by
type and allows the Device to provide the results of any measurement
it is able to perform. A set of measurement schemas are also defined
that can be carried in the generic container.
The simplest example of measurement data conveyance is illustrated by
the example message in Figure 1. This shows a HELD location request
message with an Ethernet switch and port measurement taken using LLDP
[IEEE.8021AB].
civic
0a01003c
c2
Thomson & Winterbottom Expires January 6, 2011 [Page 7]
Internet-Draft Location Measurements July 2010
Figure 1: HELD Location Request with Measurement Data
Measurement data that the LIS does not support or understand can be
ignored. The measurements defined in this document follow this rule;
extensions that could result in backward incompatibility MUST be
added as new measurement definitions rather than extensions to
existing types.
Multiple sets of measurement data, either of the same type or from
different sources can be included in the "measurements" element. See
Section 4.1.1 for details on repetition of this element.
Use of location-related measurement data is at the discretion of the
LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to
reflect the method used.
Location-related measurement data need not be provided exclusively by
Devices. A third party location requester can request location
information using measurement data, if they are able and authorized.
There are privacy considerations relating to the use of measurements
by third parties, which are discussed in Section 7.4.
Location-related measurement data and its use presents a number of
security challenges. These are described in more detail in
Section 8.
4. Location-Related Measurement Data Types
A common container is defined for the expression of location
measurement data, as well as a simple means of identifying specific
types of measurement data for the purposes of requesting them.
The following example shows a measurement container with measurement
time and expiration time included. A WiFi measurement is enclosed.
wlan-home
00-12-F0-A0-80-EF
Figure 2: Measurement Example
Thomson & Winterbottom Expires January 6, 2011 [Page 8]
Internet-Draft Location Measurements July 2010
4.1. Measurement Container
The "measurement" element is used to encapsulate measurement data
that is collected at a certain point in time. It contains time-based
attributes that are common to all forms of measurement data, and
permits the inclusion of arbitrary measurement data.
This container can be added to any request for location information,
such as a HELD location request
[I-D.ietf-geopriv-http-location-delivery].
4.1.1. Time of Measurement
The "time" attribute records the time that the measurement or
observation was made. This time can be different to the time that
the measurement information was reported. Time information can be
used to populate a timestamp on the location result, or to determine
if the measurement information is used.
The "time" attribute is optional to avoid forcing an arbitrary choice
of timestamp for relatively static types of measurement (for
instance, the DSL measurements in Section 5.6) and for legacy Devices
that don't record time information (such as the Home Location
Register/Home Subscriber Server for cellular). However, time SHOULD
be provided whenever possible.
The "time" attribute is attached to the root "measurement" element.
If it is necessary to provide multiple sets of measurement data with
different times, multiple "measurement" elements SHOULD be provided.
4.1.2. Expiry Time on Location-Related Measurement Data
A Device is able to indicate an expiry time in the location
measurement using the "expires" attribute. Nominally, this attribute
indicates how long information is expected to be valid for, but it
can also indicate a time limit on the retention and use of the
measurement data. A Device can use this attribute to prevent the LIS
from retaining measurement data or limit the time that a LIS retains
this information.
Note: Movement of a Device might result in the measurement data
being invalidated before the expiry time.
The LIS MUST NOT keep location-related measurement data beyond the
time indicated in the "expires" attribute.
Thomson & Winterbottom Expires January 6, 2011 [Page 9]
Internet-Draft Location Measurements July 2010
4.2. RMS Error and Number of Samples
Often a measurement is taken more than once over a period of time.
Reporting the average of a number of measurement results mitigates
the effects of random errors that occur in the measurement process.
Typically, a mean value is reported at the end of the measurement
interval, but additional information about the distribution of the
results can be useful in determining location uncertainty.
Two optional attributes are provided for certain measurement values:
rmsError: The root-mean-squared (RMS) error of the set of
measurement values used in calculating the result. RMS error is
expressed in the same units as the measurement, unless otherwise
stated. If an accurate value for RMS error is not known, this
value can be used to indicate an upper bound for the RMS error.
samples: The number of samples that were taken in determining the
measurement value. If omitted, this value can be assumed to be a
very large value, so that the RMS error is an indication of the
standard deviation of the sample set.
For some measurement techniques, measurement error is largely
dependent on the measurement technique employed. In these cases,
measurement error is largely a product of the measurement technique
and not the specific circumstances, so RMS error does not need to be
actively measured. A fixed value MAY be provided for RMS error where
appropriate.
The "rmsError" and "samples" elements are added as attributes of
specific measurement data types.
4.2.1. Time RMS Error
Measurement of time can be significant in certain circumstances. The
GNSS measurements included in this document are one such case where a
small error in time can result in a large error in location. Factors
such as clock drift and errors in time sychronization can result in
small, but significant, time errors. Including an indication of the
quality of the time can be helpful.
An optional "timeError" attribute can be added to the "measurement"
element to indicate the RMS error in time. "timeError" indicates an
upper bound on the time RMS error in seconds.
The "timeError" attribute does not apply where multiple samples of a
measurement is taken over time. If multiple samples are taken, each
SHOULD be included in a different "measurement" element.
Thomson & Winterbottom Expires January 6, 2011 [Page 10]
Internet-Draft Location Measurements July 2010
4.3. Measurement Request
A measurement request is used by a protocol peer to describe a set of
measurement data that it desires. A "measurementRequest" element is
defined that can be included in a protocol exchange.
For instance, a LIS can use a measurement request in HELD responses.
If the LIS is unable to provide location information, but it believes
that a particular measurement type would enable it to provide a
location, it can include a measurement request in an error response.
The "measurement" element of the measurement request identifies the
type of measurement that is requested. The "type" attribute of this
element indicates the type of measurement, as identified by an XML
qualified name. An optional "samples" attribute indicates how many
samples of the identified measurement are requested.
The "measurement" element can be repeated to request multiple (or
alternative) measurement types.
Additional XML content might be defined for a particular measurement
type that is used to further refine a request. These elements either
constrain what is requested or specify optional components of the
measurement data that are needed. These are defined along with the
specific measurement type.
In the HELD protocol, the inclusion of a measurement request in a
error response with a code of "locationUnknown" indicates that the
LIS believes that providing the indicated measurements would increase
the likelihood of a subsequent request being successful.
The following example shows a HELD error response that indicates that
WiFi measurement data would be useful if a later request were made.
Additional elements indicate that received signal strength for an
802.11n access point is requested.
Insufficient measurement data
n
wifi:rcpi
Thomson & Winterbottom Expires January 6, 2011 [Page 11]
Internet-Draft Location Measurements July 2010
Figure 3
A measurement request that is included in other HELD messages has
undefined semantics and can be safely ignored. Other specifications
might define semantics for measurement requests under other
conditions.
4.4. Identifying Location Provenance
An extension is made to the PIDF-LO [RFC4119] that allows a location
recipient to identify the source (or sources) of location information
and the measurement data that was used to determine that location
information.
The "source" element is added to the "geopriv" element of the
PIDF-LO. This element does not identify specific entities. Instead,
it identifies the type of source.
The following types of measurement source are identified:
lis: Location information is based on measurement data that the LIS
or sources that it trusts have acquired. This label might be used
if measurement data provided by the Device has been completely
validated by the LIS.
device: Location information is based on measurement data that the
Device has provided to the LIS.
other: Location information is based on measurement data that a
third party has provided. This might be an authorized third party
that uses identity parameters
[I-D.ietf-geopriv-held-identity-extensions] or any other entity.
No assertion is made about the veracity of the measurement data from
sources other than the LIS. A combination of tags MAY be included to
indicate that measurement data from both sources was used.
Thomson & Winterbottom Expires January 6, 2011 [Page 12]
Internet-Draft Location Measurements July 2010
For example, the first tuple of the following PIDF-LO indicates that
measurement data from a LIS and a device was combined to produce the
result, the second tuple was produced by the LIS alone.
7.34324 134.47162
850.24
OTDOA
lis device
7.34379 134.46484
9000
Cell
lis
Thomson & Winterbottom Expires January 6, 2011 [Page 13]
Internet-Draft Location Measurements July 2010
5. Location-Related Measurement Data Types
This document defines location-related measurement data types for a
range of common network types.
All included measurement data definitions allow for arbitrary
extension in the corresponding schema. As new parameters that are
applicable to location determination are added, these can be added as
new XML elements in a unique namespace. Though many of the
underlying protocols support extension, creation of specific XML-
based extensions to the measurement format is favored over
accomodating protocol-specific extensions in generic containers.
5.1. LLDP Measurements
Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent
between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet,
WiFi, 802.16). These messages all contain identification information
for the sending node, which can be used to determine location
information. A Device that receives LLDP messages can report this
information as a location-related measurement to the LIS, which is
then able to use the measurement data in determining the location of
the Device.
Note: The LLDP extensions defined in LLDP Media Endpoint Discovery
(LLDP-MED) [ANSI/TIA-1057] provide the ability to acquire location
information directly from an LLDP endpoint. Where this
information is available, it might be unnecessary to use any other
form of location configuration.
The Device MUST report the values directly as they were provided by
the adjacent node. Attempting to adjust or translate the type of
identifier is likely to cause the measurement data to be useless.
Where a Device has received LLDP messages from multiple adjacent
nodes, it should provide information extracted from those messages by
repeating the "lldp" element.
An example of an LLDP measurement is shown in Figure 4. This shows
an adjacent node (chassis) that is identified by the IP address
192.0.2.45 (hexadecimal c000022d) and the port on that node is
numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).
Thomson & Winterbottom Expires January 6, 2011 [Page 14]
Internet-Draft Location Measurements July 2010
c000022d
a2
Figure 4: LLDP Measurement Example
IEEE 802 Devices that are able to obtain information about adjacent
network switches and their attachment to them by other means MAY use
this data type to convey this information.
5.2. DHCP Relay Agent Information Measurements
The DHCP Relay Agent Information option [RFC3046] provides
measurement data about the network attachment of a Device. This
measurement data can be included in the "dhcp-rai" element.
The elements in the DHCP relay agent information options are opaque
data types assigned by the DHCP relay agent. The three items are all
optional: circuit identifier ("circuit", [RFC3046]), remote
identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier
("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier
has an associated enterprise number [IANA.enterprise] as an XML
attribute.
::ffff:192.0.2.158
108b
Figure 5: DHCP Relay Agent Information Measurement Example
The "giaddr" is specified as a dotted quad IPv4 address or an RFC
4291 [RFC4291] IPv6 address. The enterprise number is specified as a
decimal integer. All other information is included verbatim from the
DHCP request in hexadecimal format.
5.3. 802.11 WLAN Measurements
In WiFi, or 802.11, networks a Device might be able to provide
information about the wireless access point (WAP) that it is attached
to, or other WiFi points it is able to see. This is provided using
Thomson & Winterbottom Expires January 6, 2011 [Page 15]
Internet-Draft Location Measurements July 2010
the "wifi" element, as shown in Figure 6.
Intel(r)PRO/Wireless 2200BG
wlan-home
00-12-F0-A0-80-EF
95
wlan-home
00-12-F0-A0-80-F0
15
wlan-home
00-12-F0-A0-80-F1
12
wlan-home
00-12-F0-A0-80-F2
5
Figure 6: 802.11 WLAN Measurement Example
A wifi element is made up of a serving WAP, zero or more neighbouring
WAPs, and an optional "nicType" element. Each WAP element is
comprised of the following fields:
ssid: The service set identifier for the wireless network. This
parameter MAY be provided.
bssid: The basic service set identifier. In an Infrastructure BSS
network, the bssid is the 48 bit MAC address of the wireless
access point, and it MUST be provided.
wapname: The broadcast name for the wireless access point.
location: The location of the wireless access point, as reported
using by the wireless access point. This element contains GML
geometry, following the restrictions described in [RFC5491].
Thomson & Winterbottom Expires January 6, 2011 [Page 16]
Internet-Draft Location Measurements July 2010
type: The network type for the network access. This element
includes the alphabetic suffix of the 802.11 specification that
defines the radio interface; e.g. "a", "b", "g", or "n".
channel: The channel number (frequency) that the wireless access
point operates on.
regclass: The regulatory domain and class. The "country" attribute
optionally includes the applicable three character country
identifier (assuming US-ASCII encoding). The element text content
includes the value of the regulatory class: an 8-bit integer.
wap: Measurement information for the WAP, as observed by the Device.
Some of these values are derived from 802.11v [IEEE.80211V]
messages exchanged between Device and WAP. The contents of this
element include:
transmit: The transmit power reported by the WAP, in dB.
gain: The gain of the WAP antenna reported by the WAP, in dB.
rcpi: The received channel power indicator, as measured by the
Device. This value SHOULD be in units of dBm (with RMS error
in dB). If the units are unknown, the "dBm" attribute MUST be
set to "false". Signal strength reporting on current hardware
uses a range of different units; therefore, the value of the
"nicType" element SHOULD be included if the units are not known
to be in dBm and the value reported by the hardware should be
included without modification. This element includes optional
"rmsError" and "samples" attributes.
rsni: The received signal to noise indicator in dBm. This
element includes optional "rmsError" and "samples" attributes.
rtd: The total round trip delay from the time that a message is
sent by the Device to the time that it receives an
acknowledgement from the access point. This measurement
includes any delays that might occur between the time that the
access point receives the message and the time that it sends
the response. If the delay at an access point is known, this
value can be used to calculate an approximate distance between
device and access point. This element includes optional
"rmsError" and "samples" attributes.
Thomson & Winterbottom Expires January 6, 2011 [Page 17]
Internet-Draft Location Measurements July 2010
device: Measurement information for the device, as reported by the
WAP. This element contains the same child elements as the "wap"
element, with the WAP and Device roles reversed.
All elements are optional except for "bssid".
The "nicType" element is used to specify the make and model of the
wireless network interface in the Device. Different 802.11 chipsets
report measurements in different ways, so knowing the network
interface type aids the LIS in determining how to use the provided
measurement data. The content of this field is unconstrained and no
mechanisms are specified to ensure uniqueness.
5.3.1. Wifi Measurement Requests
Two elements are defined for requesting WiFi measurements in a
measurement request:
type: The "type" element identifies the desired type (or types that
are requested.
parameter: The "parameter" element identifies an optional
measurements are requested for each measured access point. An
element is identified by its qualified name. The optional
"context" parameter can be used to specify if an element is
included as a child of the "wap" or "device" elements; omission
indicates that it applies to both.
Multiple types or parameters can be requested by repeating either
element.
5.4. Cellular Measurements
Cellular Devices are common throughout the world and base station
identifiers can provide a good source of coarse location information.
This information can be provided to a LIS run by the cellar operator,
or may be provided to an alternative LIS operator that has access to
one of several global cell-id to location mapping databases.
A number of advanced location determination methods have been
developed for cellular networks. For these methods a range of
measurement parameters can be collected by the network, Device, or
both in cooperation. This document includes a basic identifier for
the wireless transmitter only; future efforts might define additional
parameters that enable more accurate methods of location
determination.
The cellular measurement set allows a Device to report to a LIS any
Thomson & Winterbottom Expires January 6, 2011 [Page 18]
Internet-Draft Location Measurements July 2010
LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10)
cells that it is able to observe. Cells are reported using their
global identifiers. All 3GPP cells are identified by public land
mobile network (PLMN), which is formed of mobile country code (MCC)
and mobile network code (MNC); specific fields are added for each
network type. All other values are decimal integers.
46520
80936424
46506
10736789
Long term evolution (LTE) cells are identified by a 28-bit cell
identifier (eucid).
Figure 7: Example LTE Cellular Measurement
46520
200065000
46506
1638332767
Universal mobile telephony service (UMTS) cells are identified by
radio network controller (rnc) and cell id (cid).
Figure 8: Example UMTS Cellular Measurement
Thomson & Winterbottom Expires January 6, 2011 [Page 19]
Internet-Draft Location Measurements July 2010
46506
1638332767
Global System for Mobile communication (GSM) cells are identified by
local radio network controller (rnc) and cell id (cid).
Figure 9: Example GSM Cellular Measurement
47231589212
47231589213
Code division multiple access (CDMA) cells are not identified by
PLMN, instead these use network id (nid), system id (sid) and base
station id (baseid).
Figure 10: Example CDMA Cellular Measurement
In general a cellular Device will be attached to the cellular network
and so the notion of a serving cell exists. Cellular network also
provide overlap between neighbouring sites, so a mobile Device can
hear more than one cell. The measurement schema supports sending
both the serving cell and any other cells that the mobile might be
able to hear. In some cases, the Device may simply be listening to
cell information without actually attaching to the network, mobiles
without a SIM are an example of this. In this case the Device may
simply report cells it can hear without flagging one as a serving
cell. An example of this is shown in Figure 11.
Thomson & Winterbottom Expires January 6, 2011 [Page 20]
Internet-Draft Location Measurements July 2010
46520
200065000
46506
1638332767
Figure 11: Example Observed Cellular Measurement
5.4.1. Cellular Measurement Requests
Two elements can be used in measurement requests for cellular
measurements:
type: A label indicating the type of identifier to provide: one of
"gsm", "umts", "lte", or "cdma".
network: The network portion of the cell identifier. For 3GPP
networks, this is the combination of MCC and MNC; for CDMA, this
is the network identifier.
Multiple identifier types or networks can be identified by repeating
either element.
5.5. GNSS Measurements
GNSS use orbiting satellites to transmit signals. A Device with a
GNSS receiver is able to take measurements from the satellite
signals. The results of these measurements can be used to determine
time and the location of the Device.
Determining location and time in autonomous GNSS receivers follows
three steps:
Signal acquisition: During the signal acquisition stage, the
receiver searches for the repeating code that is sent by each GNSS
satellite. Successful operation typically requires measurement
data for a minimum of 5 satellites. At this stage, measurement
data is available to the Device.
Thomson & Winterbottom Expires January 6, 2011 [Page 21]
Internet-Draft Location Measurements July 2010
Navigation message decode: Once the signal has been acquired, the
receiver then receives information about the configuration of the
satellite constellation. This information is broadcast by each
satellite and is modulated with the base signal at a low rate; for
instance, GPS sends this information at about 50 bits per second.
Calculation: The measurement data is combined with the data on the
satellite constellation to determine the location of the receiver
and the current time.
A Device that uses a GNSS receiver is able to report measurements
after the first stage of this process. A LIS can use the results of
these measurements to determine a location. In the case where there
are fewer results available than the optimal minimum, the LIS might
be able to use other sources of measurement information and combine
these with the available measurement data to determine a position.
Note: The use of different sets of GNSS _assistance data_ can
reduce the amount of time required for the signal acquisition
stage and obviate the need for the receiver to extract data on the
satellite constellation. Provision of assistance data is outside
the scope of this document.
Figure 12 shows an example of GNSS measurement data. The measurement
shown is for the GPS system and includes measurement data for three
satellites only.
Thomson & Winterbottom Expires January 6, 2011 [Page 22]
Internet-Draft Location Measurements July 2010
499.9395
0.87595747
45
378.2657
0.56639479
52
-633.0309
0.57016835
48
Figure 12: Example GNSS Measurement
Each "gnss" element represents a single set of GNSS measurement data,
taken at a single point in time. Measurements taken at different
times can be included in different "gnss" elements to enable
iterative refinement of results.
GNSS measurement parameters are described in more detail in the
following sections.
5.5.1. GNSS System and Signal
The GNSS measurement structure is designed to be generic and to apply
to different GNSS types. Different signals within those systems are
also accounted for and can be measured separately.
The GNSS type determines the time system that is used. An indication
of the type of system and signal can ensure that the LIS is able to
correctly use measurements.
Measurements for multiple GNSS types and signals can be included by
repeating the "gnss" element.
This document creates an IANA registry for GNSS types. Two satellite
systems are registered by this document: GPS and Galileo. Details
for the registry are included in Section 9.1.
Thomson & Winterbottom Expires January 6, 2011 [Page 23]
Internet-Draft Location Measurements July 2010
5.5.2. Time
Each set of GNSS measurements is taken at a specific point in time.
The "time" attribute is used to indicate the time that the
measurement was acquired, if the receiver knows how the time system
used by the GNSS relates to UTC time.
Alternative to (or in addition to) the measurement time, the
"gnssTime" element MAY be included. The "gnssTime" element includes
a relative time in milliseconds using the time system native to the
satellite system. For the GPS satellite system, the "gnssTime"
element includes the time of week in milliseconds. For the Galileo
system, the "gnssTime" element includes the time of day in
milliseconds.
The accuracy of the time measurement provided is critical in
determining the accuracy of the location information derived from
GNSS measurements. The receiver SHOULD indicate an estimated time
error for any time that is provided. An RMS error can be included
for the "gnssTime" element, with a value in milliseconds.
5.5.3. Per-Satellite Measurement Data
Multiple satellites are included in each set of GNSS measurements
using the "sat" element. Each satellite is identified by a number in
the "num" attribute. The satellite number is consistent with the
identifier used in the given GNSS.
Both the GPS and Galileo systems use satellite numbers between 1 and
64.
The GNSS receiver measures the following parameters for each
satellite:
doppler: The observed Doppler shift of the satellite signal,
measured in meters per second. This is converted from a value in
Hertz by the receiver to allow the measurement to be used without
knowledge of the carrier frequency of the satellite system. This
value includes an optional RMS error attribute, also measured in
meters per second.
codephase: The observed code phase for the satellite signal,
measured in milliseconds. This is converted from a value in chips
or wavelengths. Increasing values indicate increasing
pseudoranges. This value includes an optional RMS error
attribute, also measured in milliseconds.
Thomson & Winterbottom Expires January 6, 2011 [Page 24]
Internet-Draft Location Measurements July 2010
cn0: The signal to noise ratio for the satellite signal, measured in
decibel-Hertz (dB-Hz). The expected range is between 20 and 50
dB-Hz.
mp: An estimation of the amount of error that multipath signals
contribute in metres. This parameter is optional.
cq: An indication of the carrier quality. Two attributes are
included: "continuous" may be either "true" or "false"; direct may
be either "direct" or "inverted". This parameter is optional.
adr: The accumulated Doppler range, measured in metres. This
parameter is optional and is not necessary unless multiple sets of
GNSS measurements are provided.
All values are converted from measures native to the satellite system
to generic measures to ensure consistency of interpretation. Unless
necessary, the schema does not constrain these values.
5.5.4. GNSS Measurement Requests
Measurement requests can include a "gnss" element, which includes the
"system" and "signal" attributes. Multiple elements can be included
to indicate a requests for GNSS measurements from multiple systems or
signals.
5.6. DSL Measurements
Digital Subscriber Line (DSL) networks rely on a range of network
technology. DSL deployments regularly require cooperation between
multiple organizations. These fall into two broad categories:
infrastructure providers and Internet service providers (ISPs).
Infrastructure providers manage the bulk of the physical
infrastructure including cabling. End users obtain their service
from an ISP, which manages all aspects visible to the end user
including IP address allocation and operation of a LIS. See
[DSL.TR025] and [DSL.TR101] for further information on DSL network
deployments.
Exchange of measurement information between these organizations is
necessary for location information to be correctly generated. The
ISP LIS needs to acquire location information from the infrastructure
provider. However, the infrastructure provider has no knowledge of
Device identifiers, it can only identify a stream of data that is
sent to the ISP. This is resolved by passing measurement data
relating to the Device to a LIS operated by the infrastructure
provider.
Thomson & Winterbottom Expires January 6, 2011 [Page 25]
Internet-Draft Location Measurements July 2010
5.6.1. L2TP Measurements
Layer 2 Tunneling Protocol (L2TP) is a common means of linking the
infrastructure provider and the ISP. The infrastructure provider LIS
requires measurement data that identifies a single L2TP tunnel, from
which it can generate location information. Figure 13 shows an
example L2TP measurement.
192.0.2.10
192.0.2.61
528
Figure 13: Example DSL L2TP Measurement
5.6.2. RADIUS Measurements
When authenticating network access, the infrastructure provider might
employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or
Access Node (AN). These messages provide the ISP RADIUS server with
an identifier for the DSLAM or AN, plus the slot and port that the
Device is attached on. These data can be provided as a measurement,
which allows the infrastructure provider LIS to generate location
information.
The format of the AN, slot and port identifiers are not defined in
the RADIUS protocol. Slot and port together identify a circuit on
the AN, analogous to the circuit identifier in [RFC3046]. These
items are provided directly, as they were in the RADIUS message. An
example is shown in Figure 14.
AN-7692
3
06
Figure 14: Example DSL RADIUS Measurement
Thomson & Winterbottom Expires January 6, 2011 [Page 26]
Internet-Draft Location Measurements July 2010
5.6.3. Ethernet VLAN Tag Measurements
For Ethernet-based DSL access networks, the DSL Access Module (DSLAM)
or Access Node (AN) provide two VLAN tags on packets. A C-TAG is
used to identify the incoming residential circuit, while the S-TAG is
used to identify the DSLAM or AN. The C-TAG and S-TAG together can
be used to identify a single point of network attachment. An example
is shown in Figure 15.
613
1097
Figure 15: Example DSL VLAN Tag Measurement
Alternatively, the C-TAG can be replaced by data on the slot and port
that the Device is attached to. This information might be included
in RADIUS requests that are proxied from the infrastructure provider
to the ISP RADIUS server.
5.6.4. ATM Virtual Circuit Measurements
An ATM virtual circuit can be employed between the ISP and
infrastructure provider. Providing the virtual port ID (VPI) and
virtual circuit ID (VCI) for the virtual circuit gives the
infrastructure provider LIS the ability to identify a single data
stream. A sample measurement is shown in Figure 16.
55
6323
Figure 16: Example DSL ATM Measurement
6. Measurement Schemas
The schema are broken up into their respective functions. There is a
base container schema into which all measurements are placed, plus
definitions for a measurement request (Section 6.1). A PIDF-LO
Thomson & Winterbottom Expires January 6, 2011 [Page 27]
Internet-Draft Location Measurements July 2010
extension is defined in a separate schema (Section 6.2). There is a
basic types schema, that contains various base type definitions for
things such as the "rmsError" and "samples" attributes IPv4, IPv6 and
MAC addresses (Section 6.3). Then each of the specific measurement
types is defined in its own schema.
6.1. Measurement Container Schema
This schema defines a framework for location measurements.
Measurement Container Schema
Thomson & Winterbottom Expires January 6, 2011 [Page 29]
Internet-Draft Location Measurements July 2010
6.2. Measurement Source Schema
This schema defines an extension to PIDF-LO that indicates the
type of source that produced the measurement data used in
generating the associated location information.
Measurement Source PIDF-LO Extension Schema
6.3. Base Type Schema
Note that the pattern rules in the following schema wrap due to
length constraints. None of the patterns contain whitespace.
This schema defines a set of base type elements.
Thomson & Winterbottom Expires January 6, 2011 [Page 31]
Internet-Draft Location Measurements July 2010
An IP version 6 address, based on RFC 4291.
Thomson & Winterbottom Expires January 6, 2011 [Page 32]
Internet-Draft Location Measurements July 2010
Base Type Schema
6.4. LLDP Measurement Schema
This schema defines a set of LLDP location measurements.
Thomson & Winterbottom Expires January 6, 2011 [Page 33]
Internet-Draft Location Measurements July 2010
LLDP measurement schema
6.5. DHCP Measurement Schema
Thomson & Winterbottom Expires January 6, 2011 [Page 34]
Internet-Draft Location Measurements July 2010
This schema defines a set of DHCP location measurements.
DHCP measurement schema
6.6. WiFi Measurement Schema
Thomson & Winterbottom Expires January 6, 2011 [Page 35]
Internet-Draft Location Measurements July 2010
WiFi location measurements
This schema defines a basic set of WiFi location measurements.
Thomson & Winterbottom Expires January 6, 2011 [Page 36]
Internet-Draft Location Measurements July 2010
Thomson & Winterbottom Expires January 6, 2011 [Page 37]
Internet-Draft Location Measurements July 2010
Thomson & Winterbottom Expires January 6, 2011 [Page 38]
Internet-Draft Location Measurements July 2010
WiFi measurement schema
6.7. Cellular Measurement Schema
This schema defines a set of cellular location measurements.
Thomson & Winterbottom Expires January 6, 2011 [Page 39]
Internet-Draft Location Measurements July 2010
Thomson & Winterbottom Expires January 6, 2011 [Page 40]
Internet-Draft Location Measurements July 2010
Cellular measurement schema
6.8. GNSS Measurement Schema
This schema defines a set of GNSS location measurements
Thomson & Winterbottom Expires January 6, 2011 [Page 42]
Internet-Draft Location Measurements July 2010
GNSS measurement Schema
6.9. DSL Measurement Schema
DSL measurement definitions
This schema defines a basic set of DSL location measurements.
Thomson & Winterbottom Expires January 6, 2011 [Page 43]
Internet-Draft Location Measurements July 2010
Thomson & Winterbottom Expires January 6, 2011 [Page 44]
Internet-Draft Location Measurements July 2010
DSL measurement schema
7. Privacy Considerations
Location-related measurement data can be as privacy sensitive as
location information.
Measurement data is effectively equivalent to location information if
the contextual knowledge necessary to generate one from the other is
readily accessible. Even where contextual knowledge is difficult to
acquire, there can be no assurance that an authorized recipient of
the contextual knowledge is also authorized to receive location
information.
In order to protect the privacy of the subject of location-related
measurement data, this implies that measurement data is protected
with the same degree of protection as location information.
7.1. Measurement Data Privacy Model
It is less desirable to distribute measurement data in the same
fashion as location information. Measurement data is less useful to
location recipients than location information. Therefore, a simple
distribution model is desirable.
In this simple model, the Device is the only entity that is able to
distribute measurement data. To use an analogy from the GEOPRIV
architecture, the Device - as the Location Generator (or the
Measurement Data Generator) - is the sole entity that can assume the
roles of Rule Maker and Location Server.
No entity can redistribute measurement data. The Device directs
Thomson & Winterbottom Expires January 6, 2011 [Page 45]
Internet-Draft Location Measurements July 2010
other entities in how measurement data is used and retained.
7.2. LIS Privacy Requirements
A LIS MUST NOT reveal location-related measurement data or location
information based on measurement data to any other entity unless
directed to do so by the Device.
By adding measurement data to a request for location information, the
Device implicitly grants permission for the LIS to generate the
requested location information using the measurement data.
Permission to use this data for any other purpose is not implied.
As long as measurement data is only used in serving the request that
contains it, rules regarding data retention are not necessary. A LIS
MUST discard location-related measurement data after servicing a
request, unless the Device grants permission to use that information
for other purposes.
7.3. Measurement Data and Location URIs
A LIS MAY use measurement data provided by the Device to serve
requests to location URIs, if the Device permits it. A Device
permits this by including measurement data in a request that
explcitly requests a location URI. By requesting a location URI, the
Device grants permission for the LIS to use the measurement data in
serving requests to that URI.
Note: In HELD, the "any" type is not an explicit request for a
location URI, though a location URI might be provided.
The usefulness of measurement data that is provided in this fashion
is limited. The measurement data is only valid at the time that it
was acquired by the Device. At the time that a request is made to a
location URI, the Device might have moved, rendering the measurement
data incorrect.
A Device is able to explicitly limit the time that a LIS retains
measurement data by adding an expiry time to the measurement data,
see Section 4.1.2.
7.4. Third-Party-Provided Measurement Data
An authorized third-party request for the location of a Device (see
[I-D.ietf-geopriv-held-identity-extensions]) can include location-
related measurement data. This is possible where the third-party is
able to make observations about the Device.
Thomson & Winterbottom Expires January 6, 2011 [Page 46]
Internet-Draft Location Measurements July 2010
A third-party that provides measurement data MUST be authorized to
provide the specific measurement for the identified device. A third-
party MUST either be trusted by the LIS for the purposes of providing
measurement data of the provided type, or the measurement data MUST
be validated (see Section 8.2.1) before being used.
How a third-party authenticates its identity or gains authorization
to use measurement data is not covered by this document.
8. Security Considerations
Use of location-related measurement data has privacy considerations
that are discussed in Section 7.
8.1. Threat Model
The threat model for location-related measurement data concentrates
on the Device providing falsified, stolen or incorrect measurement
data.
A Device that provides location location-related measurement data
might use data to:
o acquire the location of another Device, without authorization;
o extract information about network topology; or
o coerce the LIS into providing falsified location information based
on the measurement data.
8.1.1. Acquiring Location Information Without Authorization
Requiring authorization for location requests is an important part of
privacy protections of a location protocol. A location configuration
protocol usually operates under a restricted policy that allows a
requester to obtain their own location. HELD identity extensions
[I-D.ietf-geopriv-held-identity-extensions] allows other entities to
be authorized, conditional on a Rule Maker providing sufficient
authorization.
The intent of these protections is to ensure that a location
recipient is authorized to acquire location information. Location-
related measurement data could be used by an attacker to circumvent
such authorization checks if the association between measurement data
and Target Device is not validated by a LIS.
A LIS can be coerced into providing location information for a Device
Thomson & Winterbottom Expires January 6, 2011 [Page 47]
Internet-Draft Location Measurements July 2010
that a location recipient is not authorized to receive. A request
identifies one Device (implicitly or explicitly), but measurement
data is provided for another Device. If the LIS does not check that
the measurement data is for the identified Device, it could
incorrectly authorize the request.
By using unvalidated measurement data to generate a response, the LIS
provides information about a Device without appropriate
authorization.
The feasibility of this attack depends on the availability of
information that links a Device with measurement data. In some
cases, measurement data that is correlated with a target is readily
available. For instance, LLDP measurements (Section 5.1) are
broadcast to all nodes on the same network segment. An attacker on
that network segment can easily gain measurement data that relates a
Device with measurements.
For some types of measurement data, it's necessary for an attacker to
know the location of the target in order to determine what
measurements to use. This attack is meaningless for types of
measurement data that require that the attacker first know the
location of the target before measurement data can be acquired or
fabricated. GNSS measurements (Section 5.5) share this trait with
many wireless location determination methods.
8.1.2. Extracting Network Topology Data
Allowing requests with measurements might be used to collect
information about a network topology. This is possible if requests
containing measurements are permitted.
Network topology can be considered sensitive information by a network
operator for commercial or security reasons. While it is impossible
to completely prevent a Device from acquiring some knowledge of
network topology if a location service is provided, a network
operator might desire to limit how much of this information is made
available.
Mapping a network topology does not require that an attacker be able
to associate measurement data with a particular Device. If a
requester is able to try a number of measurements, it is possible to
acquire information about network topology.
It is not even necessary that the measurements are valid; random
guesses are sufficient, provided that there is no penalty or cost
associated with attempting to use the measurements.
Thomson & Winterbottom Expires January 6, 2011 [Page 48]
Internet-Draft Location Measurements July 2010
8.1.3. Lying By Proxy
Location information is a function of its inputs, which includes
measurement data. Thus, falsified measurement data can be used to
alter the location information that is provided by a LIS.
Some types of measurement data are relatively easy to falsify in a
way that the resulting location information to be selected with
little or no error. For instance, GNSS measurements are easy to use
for this purpose because all the contextual information necessary to
calculate a position using measurements is broadcast by the
satellites [HARPER].
An attacker that falsifies measurement data gains little if they are
the only recipients of the result. The attacker knows that the
location information is bad. The attacker only gains if the
information can somehow be attributed to the LIS by another location
recipient.
A recipient might evaluate the trustworthiness of the location
information based on the credibility of its source. By coercing the
LIS into providing falsified location information, any credibility
that the LIS might have - that the attacker does not - is gained by
the attacker.
A third-party that is reliant on the integrity of the location
information might base an evaluation of the credibility of the
information on the source of the information. If that third party is
able to attribute location information to the LIS, then an attacker
might gain.
Location information that is provided to the Device without any means
to identify the LIS as its source is not subject to this attack. The
Device is identified as the source of the data when it distributes
the location information to location recipients.
An attacker gains if they are able to coerce the LIS into providing
location information based on falsified measurement data and that
information can be attributed to the LIS.
Location information is attributed to the LIS either through the use
of digital signatures or by having the location recipient directly
interact with the LIS. A LIS that digitally signs location
information becomes identifiable as the source of the data.
Similarly, the LIS is identified as a source of data if a location
recipient acquires information directly from a LIS using a location
URI.
Thomson & Winterbottom Expires January 6, 2011 [Page 49]
Internet-Draft Location Measurements July 2010
8.1.4. Measurement Replay
The value of some measured properties do not change over time for a
single location. This allows for simple replay attacks, where an
attacker acquires measurements that can later be used without being
detected as being invalid.
Measurement data is frequently an observation of an time-invariant
property of the environment at the subject location. For
measurements of this nature, nothing in the measurement itself is
sufficient proof that the Device is present at the resulting
location. Measurement data might have been previously acquired and
reused.
For instance, the identity of a radio transmitter, if broadcast by
that transmitter, can be collected and stored. An attacker that
wishes it known that they exist at a particular location, can claim
to observe this transmitter at any time. Nothing inherent in the
claim reveals it to be false.
For properties of a network, time-invariance is often directly as a
result of the practicalities of operating the network. Limiting the
changes to a network ensures greater consistency of service. A
largely static network also greatly simplifies the data management
tasks involved with providing a location service.
8.2. Mitigation
The following measures can be applied to limit or prevent attacks.
The effectiveness of each depends on the type of measurement data and
how that measurement data is acquired.
Two general approaches are identified for dealing with untrusted
measurement data:
1. Require independent validation of measurement data or the
location information that is produced.
2. Identify the types of sources that provided the measurement data
that location information was derived from.
This section goes into more detail on the different forms of
validation in Section 8.2.1, Section 8.2.2, and Section 8.2.3. The
impact of attributing location information to sources is discussed in
more detail in Section 8.2.4.
Thomson & Winterbottom Expires January 6, 2011 [Page 50]
Internet-Draft Location Measurements July 2010
8.2.1. Measurement Validation
Detecting that measurement data has been falsified is difficult in
the absence of integrity mechanisms.
Independent confirmation of the veracity of measurement data ensures
that the measurement is accurate and that it applies to the correct
Device. By gathering the same measurement data from a trusted and
independent source, the LIS is able to check that the measurement
data is correct.
Measurement information might contain no inherent indication that it
is falsified. On the contrary, it can be difficult to obtain
information that would provide any degree of assurance that the
measurement device is physically at any particular location.
Measurements that are difficult to verify require other forms of
assurance before they can be used.
8.2.1.1. Effectiveness
Measurement validation MUST be used if measurement data for a
particular Device can be easily acquired by unauthorized location
recipients, as described in Section 8.1.1. This prevents
unauthorized access to location information using measurement data.
Validation of measurement data can be significantly more effective
than independent acquisition of the same. For instance, a Device in
a large Ethernet network could provide a measurement indicating its
point of attachment using LLDP measurements. For a LIS, acquiring
the same measurement data might require a request to all switches in
that network. With the measurement data, validation can target the
identified switch with a specific query.
Validation is effective in identifying falsified measurement data
(Section 8.1.3), including attacks involving replay of measurement
data (Section 8.1.4). Validation also limits the amount of network
topology information (Section 8.1.2) made available to Devices to
that portion of the network topology that they are directly attached.
8.2.1.2. Limitations (Unique Observer)
A Device is often in a unique position to make a measurement. It
alone occupies the point in space-time that the location
determination process seeks to determine. The Device becomes a
unique observer for a particular property.
The ability of the Device to become a unique observer makes the
Device invaluable to the location determination process. As a unique
Thomson & Winterbottom Expires January 6, 2011 [Page 51]
Internet-Draft Location Measurements July 2010
observer, it also makes the claims of a Device difficult to validate
and easily to spoof.
As long as no other entity is capable of making the same
measurements, there is also no other entity that can independently
check that the measurements are correct and applicable to the Device.
A LIS might be unable to validate all or part of the measurement data
it receives from a unique observer. For instance, a signal strength
measurement of the signal from a radio tower cannot be validated
directly.
Some portion of the measurement data might still be independently
verified, even if all information cannot. In the previous example,
the radio tower might be able to provide verification that the Device
is present if it is able to observe a radio signal sent by the
Device.
If measurement data can only be partially validated, the extent to
which it can be validated determines the effectiveness of validation
against these attacks.
The advantage of having the Device as a unique observer is that it
makes it difficult for an attacker to acquire measurements without
the assistance of the Device. Attempts to use measurements to gain
unauthorized access to measurement data (Section 8.1.1) are largely
ineffectual against a unique observer.
8.2.2. Location Validation
Location information that is derived from location-related
measurement data can also be verified against trusted location
information. Rather than validating inputs to the location
determination process, suspect locations are identified at the output
of the process.
Trusted location information is acquired using sources of measurement
data that are trusted. Untrusted location information is acquired
using measurement data provided from untrusted sources, which might
include the Device. These two locations are compared. If the
untrusted location agrees with the trusted location, the untrusted
location information is used.
Algorithms for the comparison of location information are not
included in this document. However, a simple comparison for
agreement might require that the untrusted location be entirely
contained within the uncertainty region of the trusted location.
There is little point in using a less accurate, less trusted
Thomson & Winterbottom Expires January 6, 2011 [Page 52]
Internet-Draft Location Measurements July 2010
location. Untrusted location information that has worse accuracy
than trusted information can be immediately discarded. There are
multiple factors that affect accuracy, uncertainty and currency being
the most important. How location information is compared for
accuracy is not defined in this document.
8.2.2.1. Effectiveness
Location validation limits the extent to which falsified - or
erroneous - measurement data can cause an incorrect location to be
reported.
Location validation can be more efficient than validation of inputs,
particularly for a unique observer (Section 8.2.1.2).
Validating location ensures that the Device is at or near the
resulting location. Location validation can be used to limit or
prevent all of the attacks identified in this document.
8.2.2.2. Limitations
The trusted location that is used for validation is always less
accurate than the location that is being checked. The amount by
which the untrusted location is more accurate, is the same amount
that an attacker can exploit.
For example, a trusted location might indicate a five kilometer
radius uncertainty region. An untrusted location that describes a
100 meter uncertainty within the larger region might be accepted as
more accurate. An attacker might still falsify measurement data to
select any location within the larger uncertainty region. While the
100 meter uncertainty that is reported seems more accurate, a
falsified location could be anywhere in the five kilometer region.
Where measurement data might have been falsified, the actual
uncertainty is effectively much higher. Local policy might allow
differing degrees of trust to location information derived from
untrusted measurement data. This might not be a boolean operation
with only two possible outcomes: untrusted location information might
be used entirely or not at all, or it could be combined with trusted
location information with the degree to which each contributes based
on a value set in local policy.
8.2.3. Supporting Observations
Replay attacks using previously acquired measurement data are
particularly hard to detect without independent validation. Rather
than validate the measurement data directly, supplementary data might
Thomson & Winterbottom Expires January 6, 2011 [Page 53]
Internet-Draft Location Measurements July 2010
be used to validate measurements or the location information derived
from those measurements.
These supporting observations could be used to convey information
that provides additional assurance that the Device was acquired at a
specific time and place. In effect, the Device is requested to
provide proof of its presence at the resulting location.
For instance, a Device that measures attributes of a radio signal
could also be asked to provide a sample of the measured radio signal.
If the LIS is able to observe the same signal, the two observations
could be compared. Providing that the signal cannot be predicted in
advance by the Device, this could be used to support the claim that
the Device is able to receive the signal. Thus, the Device is likely
to be within the range that the signal is transmitted. A LIS could
use this to attribute a higher level of trust in the associated
measurement data or resulting location.
8.2.3.1. Effectiveness
The use of supporting observations is limited by the ability of the
LIS to acquire and validate these observations. The advantage of
selecting observations independent of measurement data is that
observations can be selected based on how readily available the data
is for both LIS and Device. The amount and quality of the data can
be selected based on the degree of assurance that is desired.
Use of supporting observations is similar to both measurement
validation and location validation. All three methods rely on
independent validation of one or more properties. Applicability of
each method is similar.
Use of supporting observations can be used to limit or prevent all of
the attacks identified in this document.
8.2.3.2. Limitations
The effectiveness of the validation method depends on the quality of
the supporting observation: how hard it is to obtain at a different
time or place, how difficult it is to guess and what other costs
might be involved in acquiring this data.
In the example of an observed radio signal, requesting a sample of
the signal only provides an assurance that the Device is able to
receive the signal transmitted by the measured radio transmitter.
This only provides some assurance that the Device is within range of
the transmitter.
Thomson & Winterbottom Expires January 6, 2011 [Page 54]
Internet-Draft Location Measurements July 2010
As with location validation, a Device might still be able to provide
falsified measurements that could alter the value of the location
information as long as the result is within this region.
Requesting additional supporting observations can reduce the size of
the region over which location information can be altered by an
attacker, or increase trust in the result, but each additional has a
cost. Supporting observations contribute little or nothing toward
the primary goal of determining the location of the Device. Any
costs in acquiring supporting observations are balanced against the
degree of integrity desired of the resulting location information.
8.2.4. Attribution
Lying by proxy (Section 8.1.3) relies on the location recipient being
able to attribute location information to a LIS. The effectiveness
of this attack is negated if location information is explicitly
attributed to a particular source.
This requires an extension to the location object that explicitly
identifies the source (or sources) of each item of location
information.
Rather than relying on a process that seeks to ensure that location
information is accurate, this approach instead provides a location
recipient with the information necessary to reach their own
conclusion about the trustworthiness of the location information.
Including an authenticated identity for all sources of measurement
data is presents a number of technical and operational challenges.
It is possible that the LIS has a transient relationship with a
Device. A Device is not expected to share authentication information
with a LIS. There is no assurance that Device identification is
usable by a potential location recipient. Privacy concerns might
also prevent the sharing identification information, even if it were
available and usable.
Identifying the type of measurement source allows a location
recipient to make a decision about the trustworthiness of location
information without depending on having authenticated identity
information for each source. An element for this purpose is defined
in Section 4.4.
When including location information that is based on measurement data
from sources that might be untrusted, a LIS SHOULD include
alternative location information that is derived from trusted sources
of measurement data. Each item of location information can then be
labelled with the source of that data.
Thomson & Winterbottom Expires January 6, 2011 [Page 55]
Internet-Draft Location Measurements July 2010
A location recipient that is able to identify a specific source of
measurement data (whether it be LIS or Device) can use this
information to attribute location information to either or both
entity. The location recipient is then better able to make decisions
about trustworthiness based on the source of the data.
A location recipient that does not understand the "source" element is
unable to make this distinction. When constructing a PIDF-LO
document, trusted location information MUST be placed in the PIDF-LO
so that it is given higher priority to any untrusted location
information according to Rule #8 of [RFC5491].
8.2.5. Stateful Correlation of Location Requests
Stateful examination of requests can be used to prevent a Device from
attempting to map network topology using requests for location
information (Section 8.1.2).
Simply limiting the rate of requests from a single Device reduces the
amount of data that a Device can acquire about network topology.
9. IANA Considerations
This section creates a registry for GNSS types (Section 5.5) and
registers the namespaces and schema defined in Section 6.
9.1. IANA Registry for GNSS Types
This document establishes a new IANA registry for Global Navigation
Satellite System (GNSS) types. The registry includes tokens for the
GNSS type and for each of the signals within that type. Referring to
[RFC5226], this registry operates under "Specification Required"
rules. The IESG will appoint an Expert Reviewer who will advise IANA
promptly on each request for a new or updated GNSS type.
Each entry in the registry requires the following information:
GNSS name: the name and a brief description of the GNSS
Brief description: the name and a brief description of the GNSS
GNSS token: a token that can be used to identify the GNSS
Signals: a set of tokens that represent each of the signals that the
system provides
Thomson & Winterbottom Expires January 6, 2011 [Page 56]
Internet-Draft Location Measurements July 2010
Documentation reference: a reference to one or more stable, public
specifications that outline usage of the GNSS, including (but not
limited to) signal specifications and time systems
The registry initially includes two registrations:
GNSS name: Global Positioning System (GPS)
Brief description: a system of satellites that use spread-spectrum
transmission, operated by the US military for commercial and
military applications
GNSS token: gps
Signals: L1, L2, L1C, L2C, L5
Documentation reference: Navstar GPS Space Segment/Navigation User
Interface [GPS.ICD]
GNSS name: Galileo
Brief description: a system of satellites that operate in the same
spectrum as GPS, operated by the European Union for commercial
applications
GNSS Token: galileo
Signals: L1, E5A, E5B, E5A+B, E6
Documentation Reference: Galileo Open Service Signal In Space
Interface Control Document (SIS ICD) [Galileo.ICD]
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines
in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson & Winterbottom Expires January 6, 2011 [Page 57]
Internet-Draft Location Measurements July 2010
BEGIN
Measurement Source for PIDF-LO
Namespace for Location Measurement Source
urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
END
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
Measurement Container
Namespace for Location Measurement Container
urn:ietf:params:xml:ns:geopriv:lm
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
Thomson & Winterbottom Expires January 6, 2011 [Page 58]
Internet-Draft Location Measurements July 2010
END
9.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:basetypes
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines
in [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
Base Device Types
Namespace for Base Types
urn:ietf:params:xml:ns:geopriv:lm:basetypes
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
END
9.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:lldp
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson & Winterbottom Expires January 6, 2011 [Page 59]
Internet-Draft Location Measurements July 2010
BEGIN
LLDP Measurement Set
Namespace for LLDP Measurement Set
urn:ietf:params:xml:ns:geopriv:lm:lldp
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
END
9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
DHCP Measurement Set
Namespace for DHCP Measurement Set
urn:ietf:params:xml:ns:geopriv:lm:dhcp
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
Thomson & Winterbottom Expires January 6, 2011 [Page 60]
Internet-Draft Location Measurements July 2010
END
9.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:wifi
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
WiFi Measurement Set
Namespace for WiFi Measurement Set
urn:ietf:params:xml:ns:geopriv:lm:wifi
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
END
9.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:cell
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson & Winterbottom Expires January 6, 2011 [Page 61]
Internet-Draft Location Measurements July 2010
BEGIN
Cellular Measurement Set
Namespace for Cellular Measurement Set
urn:ietf:params:xml:ns:geopriv:lm:cell
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
END
9.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
GNSS Measurement Set
Namespace for GNSS Measurement Set
urn:ietf:params:xml:ns:geopriv:lm:gnss
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
Thomson & Winterbottom Expires January 6, 2011 [Page 62]
Internet-Draft Location Measurements July 2010
END
9.10. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:dsl
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
DSL Measurement Set
Namespace for DSL Measurement Set
urn:ietf:params:xml:ns:geopriv:lm:dsl
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
See RFCXXXX.
END
9.11. XML Schema Registration for Measurement Source Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.2 of this
document.
Thomson & Winterbottom Expires January 6, 2011 [Page 63]
Internet-Draft Location Measurements July 2010
9.12. XML Schema Registration for Measurement Container Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.1 of this
document.
9.13. XML Schema Registration for Base Types Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:basetypes
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.3 of this
document.
9.14. XML Schema Registration for LLDP Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:lldp
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.4 of this
document.
9.15. XML Schema Registration for DHCP Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:dhcp
Thomson & Winterbottom Expires January 6, 2011 [Page 64]
Internet-Draft Location Measurements July 2010
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.5 of this
document.
9.16. XML Schema Registration for WiFi Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:wifi
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.6 of this
document.
9.17. XML Schema Registration for Cellular Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:cellular
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.7 of this
document.
9.18. XML Schema Registration for GNSS Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:gnss
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.8 of this
document.
Thomson & Winterbottom Expires January 6, 2011 [Page 65]
Internet-Draft Location Measurements July 2010
9.19. XML Schema Registration for DSL Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:lm:dsl
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.9 of this
document.
10. Acknowledgements
Thanks go to Simon Cox for his comments relating to terminology that
have helped ensure that this document is aligns with ongoing work in
the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his
review and comments on the GNSS sections of this document. Thanks to
Noor-E-Gagan Singh, Gabor Bajko and Russell Priebe for independent
suggestions for improving the parameters associated with 802.11
measurements. Thanks to Cullen Jennings for feedback and
suggestions. Bernard Aboba provided review and feedback on a range
of measurement data definitions. Mary Barnes provided a review and
corrections.
11. References
11.1. Normative References
[DSL.TR025]
Wang, R., "Core Network Architecture Recommendations for
Access to Legacy Data Networks over ADSL", September 1999.
[DSL.TR101]
Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
Aggregation", April 2006.
[GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface",
ICD GPS-200, Apr 2000.
[Galileo.ICD]
GJU, "Galileo Open Service Signal In Space Interface
Control Document (SIS ICD)", May 2006.
[I-D.ietf-geopriv-http-location-delivery]
Thomson & Winterbottom Expires January 6, 2011 [Page 66]
Internet-Draft Location Measurements July 2010
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
11.2. Informative References
[ANSI/TIA-1057]
ANSI/TIA, "Link Layer Discovery Protocol for Media
Endpoint Devices", TIA 1057, April 2006.
[HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side
spoofing and detection for Assisted-GPS", Proceedings of
International Global Navigation Satellite Systems Society
(IGNSS) Symposium 2009 16, December 2009,
.
[I-D.ietf-geopriv-held-identity-extensions]
Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)",
draft-ietf-geopriv-held-identity-extensions-04 (work in
progress), June 2010.
[I-D.thomson-geopriv-uncertainty]
Thomson, M. and J. Winterbottom, "Representation of
Uncertainty and Confidence in PIDF-LO",
draft-thomson-geopriv-uncertainty-05 (work in progress),
May 2010.
[IANA.enterprise]
IANA, "Private Enterprise Numbers",
.
Thomson & Winterbottom Expires January 6, 2011 [Page 67]
Internet-Draft Location Measurements July 2010
[IEEE.80211V]
IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) specifications - IEEE 802.11 Wireless
Network Management (Draft)", P802.11v D12.0, June 2010.
[IEEE.8021AB]
IEEE, "IEEE Standard for Local and Metropolitan area
networks, Station and Media Access Control Connectivity
Discovery", 802.1AB, June 2005.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
Suboption for the Dynamic Host Configuration Protocol
(DHCP) Relay Agent Option", RFC 3993, March 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
June 2006.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010.
Thomson & Winterbottom Expires January 6, 2011 [Page 68]
Internet-Draft Location Measurements July 2010
Authors' Addresses
Martin Thomson
Andrew
Andrew Building (39)
University of Wollongong
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
James Winterbottom
Andrew
Andrew Building (39)
University of Wollongong
Northfields Avenue
NSW 2522
AU
Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Thomson & Winterbottom Expires January 6, 2011 [Page 69]