draft-ietf-geopriv-held-measurements-00.txt   draft-ietf-geopriv-held-measurements-01.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft J. Winterbottom Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew Intended status: Standards Track Andrew
Expires: January 6, 2011 July 5, 2010 Expires: March 10, 2011 September 6, 2010
Using Device-provided Location-Related Measurements in Location Using Device-provided Location-Related Measurements in Location
Configuration Protocols Configuration Protocols
draft-ietf-geopriv-held-measurements-00 draft-ietf-geopriv-held-measurements-01
Abstract Abstract
A method is described by which a Device is able to provide location- A method is described by which a Device is able to provide location-
related measurement data to a LIS within a request for location related measurement data to a LIS within a request for location
information. Location-related measurement information are information. Location-related measurement information are
observations concerning properties related to the position of a observations concerning properties related to the position of a
Device, which could be data about network attachment or about the Device, which could be data about network attachment or about the
physical environment. When a LIS generates location information for physical environment. When a LIS generates location information for
a Device, information from the Device can improve the accuracy of the a Device, information from the Device can improve the accuracy of the
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2011. This Internet-Draft will expire on March 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Conventions used in this document . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 6
3. Location-Related Measurements in LCPs . . . . . . . . . . . . 7 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 7
4. Location-Related Measurement Data Types . . . . . . . . . . . 8 4. Location-Related Measurement Data Types . . . . . . . . . . . 8
4.1. Measurement Container . . . . . . . . . . . . . . . . . . 9 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 9
4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 9 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 9
4.1.2. Expiry Time on Location-Related Measurement Data . . . 9 4.1.2. Expiry Time on Location-Related Measurement Data . . . 9
4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 10 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 10
4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . . 10
4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 11 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 11
4.4. Identifying Location Provenance . . . . . . . . . . . . . 12 4.4. Identifying Location Provenance . . . . . . . . . . . . . 12
5. Location-Related Measurement Data Types . . . . . . . . . . . 14 5. Location-Related Measurement Data Types . . . . . . . . . . . 15
5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 14 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 15
5.2. DHCP Relay Agent Information Measurements . . . . . . . . 15 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 16
5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 15 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 16
5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 18 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 19
5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 18 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 20
5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 21 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 23
5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 21 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 23
5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . . 23 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . . 25
5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . . 24 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . . 26
5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 25 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 27
5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 25 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 27
5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 26 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 28
5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 26 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 28
5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 27 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 29
5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 27 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 29
6. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 27 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 29
6.1. Measurement Container Schema . . . . . . . . . . . . . . . 28 6.1. Measurement Data Privacy Model . . . . . . . . . . . . . . 30
6.2. Measurement Source Schema . . . . . . . . . . . . . . . . 30 6.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . . 30
6.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 30 6.3. Measurement Data and Location URIs . . . . . . . . . . . . 30
6.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 33 6.4. Third-Party-Provided Measurement Data . . . . . . . . . . 31
6.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 36 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 31
6.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 39 7.1.1. Acquiring Location Information Without
6.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 41 Authorization . . . . . . . . . . . . . . . . . . . . 32
6.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 43 7.1.2. Extracting Network Topology Data . . . . . . . . . . . 33
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 45 7.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . . 33
7.1. Measurement Data Privacy Model . . . . . . . . . . . . . . 45 7.1.4. Measurement Replay . . . . . . . . . . . . . . . . . . 34
7.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . . 46 7.1.5. Environment Spoofing . . . . . . . . . . . . . . . . . 35
7.3. Measurement Data and Location URIs . . . . . . . . . . . . 46 7.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4. Third-Party-Provided Measurement Data . . . . . . . . . . 46 7.2.1. Measurement Validation . . . . . . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 7.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 37
8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 47 7.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 37
8.1.1. Acquiring Location Information Without 7.2.2. Location Validation . . . . . . . . . . . . . . . . . 38
Authorization . . . . . . . . . . . . . . . . . . . . 47 7.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 39
8.1.2. Extracting Network Topology Data . . . . . . . . . . . 48 7.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 39
8.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . . 49 7.2.3. Supporting Observations . . . . . . . . . . . . . . . 39
8.1.4. Measurement Replay . . . . . . . . . . . . . . . . . . 50 7.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 40
8.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 50 7.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 40
8.2.1. Measurement Validation . . . . . . . . . . . . . . . . 51 7.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 41
8.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 51 7.2.5. Stateful Correlation of Location Requests . . . . . . 42
8.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 51 8. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 42
8.2.2. Location Validation . . . . . . . . . . . . . . . . . 52 8.1. Measurement Container Schema . . . . . . . . . . . . . . . 42
8.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 53 8.2. Measurement Source Schema . . . . . . . . . . . . . . . . 45
8.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 53 8.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 45
8.2.3. Supporting Observations . . . . . . . . . . . . . . . 53 8.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 48
8.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 54 8.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 49
8.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 54 8.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 51
8.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 55 8.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 54
8.2.5. Stateful Correlation of Location Requests . . . . . . 56 8.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 57
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 8.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 58
9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 60
9.2. URN Sub-Namespace Registration for 9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 57 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 61
9.3. URN Sub-Namespace Registration for 9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 58 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 62
9.4. URN Sub-Namespace Registration for 9.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 59 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 63
9.5. URN Sub-Namespace Registration for 9.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 59 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 64
9.6. URN Sub-Namespace Registration for 9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 60 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 64
9.7. URN Sub-Namespace Registration for 9.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 61 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 65
9.8. URN Sub-Namespace Registration for 9.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 61 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 66
9.9. URN Sub-Namespace Registration for 9.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 62 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 66
9.10. URN Sub-Namespace Registration for 9.10. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 63 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 67
9.11. XML Schema Registration for Measurement Source Schema . . 63 9.11. XML Schema Registration for Measurement Source Schema . . 68
9.12. XML Schema Registration for Measurement Container 9.12. XML Schema Registration for Measurement Container
Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.13. XML Schema Registration for Base Types Schema . . . . . . 64 9.13. XML Schema Registration for Base Types Schema . . . . . . 68
9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 64 9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 68
9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 64 9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 69
9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 65 9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 69
9.17. XML Schema Registration for Cellular Schema . . . . . . . 65 9.17. XML Schema Registration for Cellular Schema . . . . . . . 69
9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 65 9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 70
9.19. XML Schema Registration for DSL Schema . . . . . . . . . . 66 9.19. XML Schema Registration for DSL Schema . . . . . . . . . . 70
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 70
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
11.1. Normative References . . . . . . . . . . . . . . . . . . . 66 11.1. Normative References . . . . . . . . . . . . . . . . . . . 70
11.2. Informative References . . . . . . . . . . . . . . . . . . 67 11.2. Informative References . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
1. Introduction 1. Introduction
A location configuration protocol (LCP) provides a means for a Device A location configuration protocol (LCP) provides a means for a Device
to request information about its physical location from an access to request information about its physical location from an access
network. A location information server (LIS) is the server that network. A location information server (LIS) is the server that
provides location information; information that is available due to provides location information; information that is available due to
the knowledge about the network and physical environment that is the knowledge about the network and physical environment that is
available to the LIS. available to the LIS.
skipping to change at page 8, line 24 skipping to change at page 8, line 24
Section 4.1.1 for details on repetition of this element. Section 4.1.1 for details on repetition of this element.
Use of location-related measurement data is at the discretion of the 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 LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to
reflect the method used. reflect the method used.
Location-related measurement data need not be provided exclusively by Location-related measurement data need not be provided exclusively by
Devices. A third party location requester can request location Devices. A third party location requester can request location
information using measurement data, if they are able and authorized. information using measurement data, if they are able and authorized.
There are privacy considerations relating to the use of measurements There are privacy considerations relating to the use of measurements
by third parties, which are discussed in Section 7.4. by third parties, which are discussed in Section 6.4.
Location-related measurement data and its use presents a number of Location-related measurement data and its use presents a number of
security challenges. These are described in more detail in security challenges. These are described in more detail in
Section 8. Section 7.
4. Location-Related Measurement Data Types 4. Location-Related Measurement Data Types
A common container is defined for the expression of location A common container is defined for the expression of location
measurement data, as well as a simple means of identifying specific measurement data, as well as a simple means of identifying specific
types of measurement data for the purposes of requesting them. types of measurement data for the purposes of requesting them.
The following example shows a measurement container with measurement The following example shows a measurement container with measurement
time and expiration time included. A WiFi measurement is enclosed. time and expiration time included. A WiFi measurement is enclosed.
<lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm" <lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58" time="2008-04-29T14:33:58"
expires="2008-04-29T17:33:58"> expires="2008-04-29T17:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi"> <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<servingWap> <ap serving="true">
<ssid>wlan-home</ssid>
<bssid>00-12-F0-A0-80-EF</bssid> <bssid>00-12-F0-A0-80-EF</bssid>
</servingWap> <ssid>wlan-home</ssid>
</ap>
</wifi> </wifi>
</lm:measurements> </lm:measurements>
Figure 2: Measurement Example Figure 2: Measurement Example
4.1. Measurement Container 4.1. Measurement Container
The "measurement" element is used to encapsulate measurement data The "measurement" element is used to encapsulate measurement data
that is collected at a certain point in time. It contains time-based that is collected at a certain point in time. It contains time-based
attributes that are common to all forms of measurement data, and attributes that are common to all forms of measurement data, and
skipping to change at page 10, line 10 skipping to change at page 10, line 10
being invalidated before the expiry time. being invalidated before the expiry time.
The LIS MUST NOT keep location-related measurement data beyond the The LIS MUST NOT keep location-related measurement data beyond the
time indicated in the "expires" attribute. time indicated in the "expires" attribute.
4.2. RMS Error and Number of Samples 4.2. RMS Error and Number of Samples
Often a measurement is taken more than once over a period of time. Often a measurement is taken more than once over a period of time.
Reporting the average of a number of measurement results mitigates Reporting the average of a number of measurement results mitigates
the effects of random errors that occur in the measurement process. 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 Reporting each measurement individually can be the most effective
results can be useful in determining location uncertainty. method of reporting multiple measurements. This is achieved by
providing multiple "measurement" elements for different times.
The alternative is to aggregate multiple measurements and report a
mean value across the set of measurements. Additional information
about the distribution of the results can be useful in determining
location uncertainty.
Two optional attributes are provided for certain measurement values: Two optional attributes are provided for certain measurement values:
rmsError: The root-mean-squared (RMS) error of the set of rmsError: The root-mean-squared (RMS) error of the set of
measurement values used in calculating the result. RMS error is measurement values used in calculating the result. RMS error is
expressed in the same units as the measurement, unless otherwise expressed in the same units as the measurement, unless otherwise
stated. If an accurate value for RMS error is not known, this 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. value can be used to indicate an upper bound or estimate for the
RMS error.
samples: The number of samples that were taken in determining the samples: The number of samples that were taken in determining the
measurement value. If omitted, this value can be assumed to be a 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 very large value, so that the RMS error is an indication of the
standard deviation of the sample set. standard deviation of the sample set.
For some measurement techniques, measurement error is largely For some measurement techniques, measurement error is largely
dependent on the measurement technique employed. In these cases, dependent on the measurement technique employed. In these cases,
measurement error is largely a product of the measurement technique measurement error is largely a product of the measurement technique
and not the specific circumstances, so RMS error does not need to be and not the specific circumstances, so RMS error does not need to be
skipping to change at page 11, line 49 skipping to change at page 12, line 18
802.11n access point is requested. 802.11n access point is requested.
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown"> code="locationUnknown">
<message xml:lang="en">Insufficient measurement data</message> <message xml:lang="en">Insufficient measurement data</message>
<measurementRequest <measurementRequest
xmlns="urn:ietf:params:xml:ns:geopriv:lm" xmlns="urn:ietf:params:xml:ns:geopriv:lm"
xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi"> xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<measurement type="wifi:wifi"> <measurement type="wifi:wifi">
<wifi:type>n</wifi:type> <wifi:type>n</wifi:type>
<wifi:parameter context="wap">wifi:rcpi</wifi:parameter> <wifi:parameter context="ap">wifi:rcpi</wifi:parameter>
</measurement> </measurement>
</measurementRequest> </measurementRequest>
</error> </error>
Figure 3 Figure 3
A measurement request that is included in other HELD messages has A measurement request that is included in other HELD messages has
undefined semantics and can be safely ignored. Other specifications undefined semantics and can be safely ignored. Other specifications
might define semantics for measurement requests under other might define semantics for measurement requests under other
conditions. conditions.
4.4. Identifying Location Provenance 4.4. Identifying Location Provenance
An extension is made to the PIDF-LO [RFC4119] that allows a location An extension is made to the PIDF-LO [RFC4119] that allows a location
skipping to change at page 15, line 50 skipping to change at page 16, line 50
Figure 5: DHCP Relay Agent Information Measurement Example Figure 5: DHCP Relay Agent Information Measurement Example
The "giaddr" is specified as a dotted quad IPv4 address or an RFC The "giaddr" is specified as a dotted quad IPv4 address or an RFC
4291 [RFC4291] IPv6 address. The enterprise number is specified as a 4291 [RFC4291] IPv6 address. The enterprise number is specified as a
decimal integer. All other information is included verbatim from the decimal integer. All other information is included verbatim from the
DHCP request in hexadecimal format. DHCP request in hexadecimal format.
5.3. 802.11 WLAN Measurements 5.3. 802.11 WLAN Measurements
In WiFi, or 802.11, networks a Device might be able to provide In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to
information about the wireless access point (WAP) that it is attached provide information about the access point (AP) that it is attached
to, or other WiFi points it is able to see. This is provided using to, or other WiFi points it is able to see. This is provided using
the "wifi" element, as shown in Figure 6. the "wifi" element, as shown in Figure 6, which shows a single
complete measurement for a single access point.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2011-04-29T14:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi"> <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<nicType>Intel(r)PRO/Wireless 2200BG</nicType> <nicType>Intel(r)PRO/Wireless 2200BG</nicType>
<servingWap> <ap serving="true">
<ssid>wlan-home</ssid> <bssid>AB-CD-EF-AB-CD-EF</bssid>
<bssid>00-12-F0-A0-80-EF</bssid> <name>Example</name>
<wap><rcpi dBm="false">95</rcpi></wap> <ssid>example</ssid>
</servingWap> <channel>5</channel>
<neighbourWap> <location>
<ssid>wlan-home</ssid> <gml:Point xmlns:gml="http://opengis.net/gml">
<bssid>00-12-F0-A0-80-F0</bssid> <gml:pos>-34.4 150.8</gml:pos>
<wap><rcpi dBm="false">15</rcpi></wap> </gml:Point>
</neighbourWap> </location>
<neighbourWap> <type>a</type>
<ssid>wlan-home</ssid> <band>5</band>
<bssid>00-12-F0-A0-80-F1</bssid> <regclass country="AU">2</regclass>
<wap><rcpi dBm="false">12</rcpi></wap> <antenna>2</antenna>
</neighbourWap> <flightTime rmsError="4e-9" samples="1">2.56e-9</flightTime>
<neighbourWap> <apSignal>
<ssid>wlan-home</ssid> <transmit>23</transmit>
<bssid>00-12-F0-A0-80-F2</bssid> <gain>5</gain>
<wap><rcpi dBm="false">5</rcpi></wap> <rcpi dBm="true" rmsError="12" samples="1">-59</rcpi>
</neighbourWap> <rsni rmsError="15" samples="1">23</rsni>
</apSignal>
<deviceSignal>
<transmit>10</transmit>
<gain>9</gain>
<rcpi dBm="true" rmsError="9.5" samples="1">-98.5</rcpi>
<rsni rmsError="6" samples="1">7.5</rsni>
</deviceSignal>
</ap>
</wifi> </wifi>
</measurements> </measurements>
Figure 6: 802.11 WLAN Measurement Example Figure 6: 802.11 WLAN Measurement Example
A wifi element is made up of a serving WAP, zero or more neighbouring A wifi element is made up of one or more access points, and an
WAPs, and an optional "nicType" element. Each WAP element is optional "nicType" element. Each access point is described using the
comprised of the following fields: "ap" element, which 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 bssid: The basic service set identifier. In an Infrastructure BSS
network, the bssid is the 48 bit MAC address of the wireless network, the bssid is the 48 bit MAC address of the access point.
access point, and it MUST be provided.
wapname: The broadcast name for the wireless access point. The "verified" attribute of this element describes whether the
device has verified the MAC address or it authenticated the access
point or the network operating the access point (for example, a
captive portal accessed through the access point has been
authenticated). This attributes defaults to a value of "false"
when omitted.
location: The location of the wireless access point, as reported name: The broadcast name for the access point.
using by the wireless access point. This element contains GML
geometry, following the restrictions described in [RFC5491]. ssid: The service set identifier for the wireless network served by
the access point.
channel: The channel number (frequency) that the access point
operates on.
location: The location of the access point, as reported by the
access point. This element contains any valid location, using the
rules for a "location-info" element, as described in [RFC5491].
type: The network type for the network access. This element type: The network type for the network access. This element
includes the alphabetic suffix of the 802.11 specification that includes the alphabetic suffix of the 802.11 specification that
defines the radio interface; e.g. "a", "b", "g", or "n". introducted the radio interface, or PHY; e.g. "a", "b", "g", or
"n".
channel: The channel number (frequency) that the wireless access band: The frequency band for the radio, in gigahertz (GHz). 802.11
point operates on. [IEEE.80211] specifies PHY layers that use 2.4, 3.7 and 5
gigahertz frequency bands.
regclass: The regulatory domain and class. The "country" attribute regclass: The regulatory domain and class. The "country" attribute
optionally includes the applicable three character country optionally includes the applicable two character country
identifier (assuming US-ASCII encoding). The element text content identifier (dot11CountryString), which can be followed by an 'O',
includes the value of the regulatory class: an 8-bit integer. 'I' or 'X'. 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. antenna: The antenna identifier for the antenna that the access
Some of these values are derived from 802.11v [IEEE.80211V] point is using to transmit the measured signals.
messages exchanged between Device and WAP. The contents of this
element include:
transmit: The transmit power reported by the WAP, in dB. flightTime: Flight time is the difference between the time of
departure (TOD) of signal from a transmitting station and time of
arrival (TOA) of signal at a receiving station, as defined in
[IEEE.80211V]. Measurement of this value requires that stations
synchronize their clocks. This value can be measured by access
point or Device; because the flight time is assumed to be the same
in either direction - aside from measurement errors - only a
single element is provided. This element includes optional
"rmsError" and "samples" attributes. RMS error might be derived
from the reported RMS error in TOD and TOA.
gain: The gain of the WAP antenna reported by the WAP, in dB. apSignal: Measurement information for the signal transmitted by the
access point, as observed by the Device. Some of these values are
derived from 802.11v [IEEE.80211V] messages exchanged between
Device and access point. The contents of this element include:
rcpi: The received channel power indicator, as measured by the transmit: The transmit power reported by the access point, in dB.
Device. This value SHOULD be in units of dBm (with RMS error
in dB). If the units are unknown, the "dBm" attribute MUST be gain: The gain of the access point antenna reported by the access
set to "false". Signal strength reporting on current hardware point, in dB.
uses a range of different units; therefore, the value of the
"nicType" element SHOULD be included if the units are not known rcpi: The received channel power indicator for the access point
to be in dBm and the value reported by the hardware should be signal, as measured by the Device. This value SHOULD be in
included without modification. This element includes optional units of dBm (with RMS error in dB). If power is measured in a
different fashion, the "dBm" attribute MUST be set to "false".
Signal strength reporting on current hardware uses a range of
different mechanisms; 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. "rmsError" and "samples" attributes.
rsni: The received signal to noise indicator in dBm. This rsni: The received signal to noise indicator in dBm. This
element includes optional "rmsError" and "samples" attributes. element includes optional "rmsError" and "samples" attributes.
rtd: The total round trip delay from the time that a message is deviceSignal: Measurement information for the signal transmitted by
sent by the Device to the time that it receives an the device, as reported by the access point. This element
acknowledgement from the access point. This measurement contains the same child elements as the "ap" element, with the
includes any delays that might occur between the time that the access point and Device roles reversed.
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.
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". All elements are optional except for "bssid".
The "nicType" element is used to specify the make and model of the The "nicType" element is used to specify the make and model of the
wireless network interface in the Device. Different 802.11 chipsets wireless network interface in the Device. Different 802.11 chipsets
report measurements in different ways, so knowing the network report measurements in different ways, so knowing the network
interface type aids the LIS in determining how to use the provided interface type aids the LIS in determining how to use the provided
measurement data. The content of this field is unconstrained and no measurement data. The content of this field is unconstrained and no
mechanisms are specified to ensure uniqueness. mechanisms are specified to ensure uniqueness.
skipping to change at page 18, line 30 skipping to change at page 20, line 9
Two elements are defined for requesting WiFi measurements in a Two elements are defined for requesting WiFi measurements in a
measurement request: measurement request:
type: The "type" element identifies the desired type (or types that type: The "type" element identifies the desired type (or types that
are requested. are requested.
parameter: The "parameter" element identifies an optional parameter: The "parameter" element identifies an optional
measurements are requested for each measured access point. An measurements are requested for each measured access point. An
element is identified by its qualified name. The optional element is identified by its qualified name. The optional
"context" parameter can be used to specify if an element is "context" parameter can be used to specify if an element is
included as a child of the "wap" or "device" elements; omission included as a child of the "ap" or "device" elements; omission
indicates that it applies to both. indicates that it applies to both.
Multiple types or parameters can be requested by repeating either Multiple types or parameters can be requested by repeating either
element. element.
5.4. Cellular Measurements 5.4. Cellular Measurements
Cellular Devices are common throughout the world and base station Cellular Devices are common throughout the world and base station
identifiers can provide a good source of coarse location information. identifiers can provide a good source of coarse location information.
This information can be provided to a LIS run by the cellar operator, This information can be provided to a LIS run by the cellar operator,
skipping to change at page 27, line 47 skipping to change at page 29, line 47
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl"> <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<vpi>55</vpi> <vpi>55</vpi>
<vci>6323</vci> <vci>6323</vci>
</dsl> </dsl>
</measurements> </measurements>
Figure 16: Example DSL ATM Measurement Figure 16: Example DSL ATM Measurement
6. Measurement Schemas 6. 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.
6.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
other entities in how measurement data is used and retained.
6.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.
6.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.
6.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.
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 7.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.
7. Security Considerations
Use of location-related measurement data has privacy considerations
that are discussed in Section 6.
7.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.
Location-related measurement data describes the physical environment
or network attachment of a Device. A third party adversary in the
proximity of the Device might be able to alter the physical
environment such that the Device provides measurement data that is
controlled by the third party. This might be used to indirectly
control the location information that is derived from measurement
data.
7.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
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.
7.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.
7.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.
7.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.
7.1.5. Environment Spoofing
Some types of measurement data can be altered or influenced by a
third party so that a Device. If it is possible for a third party to
alter the measured phenomenon, then any location information that is
derived from this data can be indirectly influenced.
Altering the environment in this fashion might not require
involvement with either Device or LIS. Measurement that is passive -
where the Device observes a signal or other phenomenon without direct
interaction - are most susceptible to alteration by third parties.
Measurement of radio signal characteristics is especially vulnerable
since an adversary need only be in the general vicinity of the Device
and be able to transmit a signal. For instance, a GNSS spoofer is
able to produce fake signals that claim to be transmitted by any
satellite or set of satellites (see [GPS.SPOOF]).
Measurements that require direct interaction increases the complexity
of the attack. For measurements relating to the communication
medium, a third party cannot avoid direct interaction, they need only
be on the comminications path (that is, man in the middle).
Even if the entity that is interacted with is authenticated, this
does not provide any assurance about the integrity of measurement
data. For instance, the Device might authenticate the identity of a
radio transmitter through the use of cryptographic means and obtain
signal strength measurements for that transmitter. Radio signal
strength is trivial for an attacker to increase simply by receiving
and amplifying the raw signal; it is not necessary for the attacker
to be able to understand the signal content.
Note: This particular "attack" is more often completely legitimate.
Radio repeaters are commonplace mechanism used to increase radio
coverage.
Attacks that rely on altering the observed environment of a Device
require countermeasures that affect the measurement process. For
radio signals, countermeasures could include the use of authenticated
signals, altered receiver design. In general, countermeasures are
highly specific to the individual measurement process. An exhaustive
discussion of these issues is left to the relevant literature for
each measurement technology.
A Device that provides measurement data is assumed to be responsible
for applying appropriate countermeasures against this type of attack.
For a Device that is the ultimate recipient of location information
derived from measurement data, a LIS might choose to provide location
information without any validation. The responsibility for ensuring
the veracity of the measurement data lies with the Device.
Measurement data that is susceptible to this sort of influence MUST
be treated as though it were produced by an untrusted Device for
those cases where a location recipient might attribute the location
information to the LIS. Such measurement data MUST be subjected to
the same validation as for other types of attacks that rely on
measurement falsification.
Note: Altered measurement data might be provided by a Device that
has no knowledge of the alteration. Thus, an otherwise trusted
Device might still be an unreliable source of measurement data.
7.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 7.2.1, Section 7.2.2, and Section 7.2.3. The
impact of attributing location information to sources is discussed in
more detail in Section 7.2.4.
7.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.
7.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 7.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 7.1.3), including attacks involving replay of measurement
data (Section 7.1.4). Validation also limits the amount of network
topology information (Section 7.1.2) made available to Devices to
that portion of the network topology that they are directly attached.
Measurement validation has no effect if the underlying effect is
being spoofed (Section 7.1.5).
7.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
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 7.1.1) are largely
ineffectual against a unique observer.
7.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
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.
7.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 7.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.
7.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.
7.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
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.
7.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.
7.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.
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.
7.2.4. Attribution
Lying by proxy (Section 7.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.
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].
Attribution of information does nothing to address attacks that alter
the observed parameters that are used in location determination
(Section 7.1.5).
7.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 7.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.
8. Measurement Schemas
The schema are broken up into their respective functions. There is a The schema are broken up into their respective functions. There is a
base container schema into which all measurements are placed, plus base container schema into which all measurements are placed, plus
definitions for a measurement request (Section 6.1). A PIDF-LO definitions for a measurement request (Section 8.1). A PIDF-LO
extension is defined in a separate schema (Section 6.2). There is a extension is defined in a separate schema (Section 8.2). There is a
basic types schema, that contains various base type definitions for basic types schema, that contains various base type definitions for
things such as the "rmsError" and "samples" attributes IPv4, IPv6 and things such as the "rmsError" and "samples" attributes IPv4, IPv6 and
MAC addresses (Section 6.3). Then each of the specific measurement MAC addresses (Section 8.3). Then each of the specific measurement
types is defined in its own schema. types is defined in its own schema.
6.1. Measurement Container Schema 8.1. Measurement Container Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm" xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
skipping to change at page 29, line 9 skipping to change at page 43, line 41
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="measurementRequest" <xs:element name="measurementRequest"
type="lm:measurementRequestType"/> type="lm:measurementRequestType"/>
<xs:complexType name="measurementRequestType"> <xs:complexType name="measurementRequestType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="measurement" type="lm:measurementType" <xs:element ref="lm:measurement"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="measurement" type="lm:measurementType"/>
<xs:complexType name="measurementType"> <xs:complexType name="measurementType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="type" type="xs:QName" use="required"/> <xs:attribute name="type" type="xs:QName" use="required"/>
<xs:attribute name="samples" type="xs:positiveInteger"/> <xs:attribute name="samples" type="xs:positiveInteger"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- PIDF-LO extension for source -->
<xs:element name="source" type="lm:sourceType"/>
<xs:simpleType name="sourceType">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="lis"/>
<xs:enumeration value="device"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:schema>
Measurement Container Schema Measurement Container Schema
6.2. Measurement Source Schema 8.2. Measurement Source Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc" xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc" targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
skipping to change at page 30, line 44 skipping to change at page 45, line 44
<xs:enumeration value="device"/> <xs:enumeration value="device"/>
<xs:enumeration value="other"/> <xs:enumeration value="other"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:list> </xs:list>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Measurement Source PIDF-LO Extension Schema Measurement Source PIDF-LO Extension Schema
6.3. Base Type Schema 8.3. Base Type Schema
Note that the pattern rules in the following schema wrap due to Note that the pattern rules in the following schema wrap due to
length constraints. None of the patterns contain whitespace. length constraints. None of the patterns contain whitespace.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
elementFormDefault="qualified" elementFormDefault="qualified"
skipping to change at page 33, line 18 skipping to change at page 48, line 18
<!-- IPv4 format definition --> <!-- IPv4 format definition -->
<xs:simpleType name="IPv4AddressType"> <xs:simpleType name="IPv4AddressType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\. <xs:pattern value="(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\. (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\. (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/> (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- IEEE specifies a MAC address as having a - <!-- MAC address (EUI-48) or EUI-64 address -->
between 2 hex digit pairs -->
<xs:simpleType name="macAddressType"> <xs:simpleType name="macAddressType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="([0-9A-Fa-f]{2}-){5}([0-9A-Fa-f]{2})"/> <xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Base Type Schema Base Type Schema
6.4. LLDP Measurement Schema 8.4. LLDP Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp" xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
skipping to change at page 34, line 41 skipping to change at page 49, line 41
<xs:restriction base="xs:hexBinary"> <xs:restriction base="xs:hexBinary">
<xs:minLength value="1"/> <xs:minLength value="1"/>
<xs:maxLength value="255"/> <xs:maxLength value="255"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
LLDP measurement schema LLDP measurement schema
6.5. DHCP Measurement Schema 8.5. DHCP Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:dhcp="urn:ietf:params:xml:ns:geopriv:lm:dhcp" xmlns:dhcp="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dhcp" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
skipping to change at page 35, line 52 skipping to change at page 50, line 52
<xs:attribute name="enterprise" type="xs:positiveInteger" <xs:attribute name="enterprise" type="xs:positiveInteger"
use="optional"/> use="optional"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
DHCP measurement schema DHCP measurement schema
6.6. WiFi Measurement Schema 8.6. WiFi Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi" xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:wifi" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:wifi"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:wifi">
WiFi location measurements
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a basic set of WiFi location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <xs:annotation>
<xs:import namespace="http://www.opengis.net/gml"/> <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:wifi">
802.11 location measurements
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a basic set of 802.11 location measurements.
</xs:documentation>
</xs:annotation>
<xs:element name="wifi" type="wifi:wifiNetworkType"/> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:import namespace="http://www.opengis.net/gml"/>
<xs:complexType name="wifiNetworkType"> <xs:element name="wifi" type="wifi:wifiNetworkType"/>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="nicType" type="xs:token"
minOccurs="0"/>
<xs:choice>
<xs:element name="servingWap" type="wifi:wifiType"/>
<xs:element name="neighbourWap" type="wifi:wifiType"/>
</xs:choice>
<xs:element name="neighbourWap" type="wifi:wifiType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="wifiType"> <xs:complexType name="wifiNetworkType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="ssid" type="wifi:ssidBaseType" <xs:element name="nicType" type="xs:token"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="bssid" type="bt:macAddressType"/> <xs:element name="ap" type="wifi:wifiType"
<xs:element name="wapname" type="wifi:ssidBaseType" maxOccurs="unbounded"/>
minOccurs="0"/> </xs:sequence>
<xs:element name="location" minOccurs="0" <xs:anyAttribute namespace="##any" processContents="lax"/>
type="gml:GeometryPropertyType"/> </xs:restriction>
<xs:element name="type" type="wifi:networkType" </xs:complexContent>
minOccurs="0"/> </xs:complexType>
<xs:element name="regclass" type="wifi:regclassType"
minOccurs="0"/>
<xs:element name="channel" type="xs:nonNegativeInteger"
minOccurs="0"/>
<xs:element name="wap" type="wifi:staType" minOccurs="0"/>
<xs:element name="device" type="wifi:staType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="ssidBaseType"> <xs:complexType name="wifiType">
<xs:restriction base="xs:token"> <xs:complexContent>
<xs:maxLength value="32"/> <xs:restriction base="xs:anyType">
</xs:restriction> <xs:sequence>
</xs:simpleType> <xs:element name="bssid" type="wifi:bssidType"/>
<xs:element name="name" type="wifi:ssidBaseType"
minOccurs="0"/>
<xs:simpleType name="networkType"> <xs:element name="ssid" type="wifi:ssidBaseType"
<xs:restriction base="xs:token"> minOccurs="0"/>
<xs:pattern value="[a-zA-Z]+"/> <xs:element name="channel" type="xs:nonNegativeInteger"
</xs:restriction> minOccurs="0"/>
</xs:simpleType> <xs:element name="location" minOccurs="0"
type="xs:anyType"/>
<xs:element name="type" type="wifi:networkType"
minOccurs="0"/>
<xs:element name="regclass" type="wifi:regclassType"
minOccurs="0"/>
<xs:element name="antenna" type="wifi:octetType"
minOccurs="0"/>
<xs:element name="flightTime "minOccurs="0"
type="bt:nnDoubleWithRMSError"/>
<xs:element name="apSignal" type="wifi:signalType"
minOccurs="0"/>
<xs:element name="deviceSignal" type="wifi:signalType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serving" type="xs:boolean"
default="false"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="regclassType"> <xs:simpleType name="ssidBaseType">
<xs:simpleContent> <xs:restriction base="xs:token">
<xs:extension base="wifi:regclassBase"> <xs:maxLength value="32"/>
<xs:attribute name="country"> </xs:restriction>
<xs:simpleType> </xs:simpleType>
<xs:restriction base="xs:token">
<xs:length value="3"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType> <xs:complexType name="bssidType">
<xs:simpleContent>
<xs:extension base="bt:macAddressType">
<xs:attribute name="verified" type="xs:boolean"
default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="regclassBase"> <xs:simpleType name="networkType">
<xs:restriction base="xs:nonNegativeInteger"> <xs:restriction base="xs:token">
<xs:maxInclusive value="255"/> <xs:pattern value="[a-zA-Z]+"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="regclassType">
<xs:simpleContent>
<xs:extension base="wifi:octetType">
<xs:attribute name="country">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="[A-Z]{2}[OIX]?"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="staType"> <xs:simpleType name="octetType">
<xs:complexContent> <xs:restriction base="xs:nonNegativeInteger">
<xs:restriction base="xs:anyType"> <xs:maxInclusive value="255"/>
<xs:sequence> </xs:restriction>
<xs:element name="transmit" type="xs:double" minOccurs="0"/> </xs:simpleType>
<xs:element name="gain" type="xs:double" minOccurs="0"/>
<xs:element name="rcpi" type="wifi:rssiType"
minOccurs="0"/>
<xs:element name="rsni" type="bt:doubleWithRMSError"
minOccurs="0"/>
<xs:element name="rtd" type="bt:doubleWithRMSError"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="rssiType"> <xs:complexType name="signalType">
<xs:simpleContent> <xs:complexContent>
<xs:extension base="bt:doubleWithRMSError"> <xs:restriction base="xs:anyType">
<xs:attribute name="dBm" type="xs:boolean" default="true"/> <xs:sequence>
</xs:extension> <xs:element name="transmit" type="xs:double"
</xs:simpleContent> minOccurs="0"/>
</xs:complexType> <xs:element name="gain" type="xs:double" minOccurs="0"/>
<xs:element name="rcpi" type="wifi:rssiType"
minOccurs="0"/>
<xs:element name="rsni" type="bt:doubleWithRMSError"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- Measurement Request elements --> <xs:complexType name="rssiType">
<xs:element name="type" type="wifi:networkType"/> <xs:simpleContent>
<xs:element name="parameter" type="wifi:parameterType"/> <xs:extension base="bt:doubleWithRMSError">
<xs:attribute name="dBm" type="xs:boolean" default="true"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="parameterType"> <!-- Measurement Request elements -->
<xs:simpleContent> <xs:element name="type" type="wifi:networkType"/>
<xs:extension base="xs:QName"> <xs:element name="parameter" type="wifi:parameterType"/>
<xs:attribute name="context" use="optional">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="wap"/>
<xs:enumeration value="device"/>
</xs:restriction>
</xs:simpleType> <xs:complexType name="parameterType">
</xs:attribute> <xs:simpleContent>
</xs:extension> <xs:extension base="xs:QName">
</xs:simpleContent> <xs:attribute name="context" use="optional">
</xs:complexType> <xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="ap"/>
<xs:enumeration value="device"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema> </xs:schema>
WiFi measurement schema WiFi measurement schema
6.7. Cellular Measurement Schema 8.7. Cellular Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:cell="urn:ietf:params:xml:ns:geopriv:lm:cell" xmlns:cell="urn:ietf:params:xml:ns:geopriv:lm:cell"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:cell" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:cell"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
skipping to change at page 41, line 39 skipping to change at page 56, line 51
<xs:element name="nid" type="cell:cellIdType"/> <xs:element name="nid" type="cell:cellIdType"/>
</xs:choice> </xs:choice>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Cellular measurement schema Cellular measurement schema
6.8. GNSS Measurement Schema 8.8. GNSS Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss" xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:gnss" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:gnss"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
skipping to change at page 43, line 33 skipping to change at page 58, line 43
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
GNSS measurement Schema GNSS measurement Schema
6.9. DSL Measurement Schema 8.9. DSL Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:dsl="urn:ietf:params:xml:ns:geopriv:lm:dsl" xmlns:dsl="urn:ietf:params:xml:ns:geopriv:lm:dsl"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dsl" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dsl"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
skipping to change at page 45, line 22 skipping to change at page 60, line 33
<xs:sequence> <xs:sequence>
<xs:element name="slot" type="xs:token"/> <xs:element name="slot" type="xs:token"/>
<xs:element name="port" type="xs:token"/> <xs:element name="port" type="xs:token"/>
</xs:sequence> </xs:sequence>
</xs:group> </xs:group>
</xs:schema> </xs:schema>
DSL measurement schema 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
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.
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
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.
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.
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.
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
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
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
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.
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.
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 9. IANA Considerations
This section creates a registry for GNSS types (Section 5.5) and This section creates a registry for GNSS types (Section 5.5) and
registers the namespaces and schema defined in Section 6. registers the namespaces and schema defined in Section 8.
9.1. IANA Registry for GNSS Types 9.1. IANA Registry for GNSS Types
This document establishes a new IANA registry for Global Navigation This document establishes a new IANA registry for Global Navigation
Satellite System (GNSS) types. The registry includes tokens for the Satellite System (GNSS) types. The registry includes tokens for the
GNSS type and for each of the signals within that type. Referring to GNSS type and for each of the signals within that type. Referring to
[RFC5226], this registry operates under "Specification Required" [RFC5226], this registry operates under "Specification Required"
rules. The IESG will appoint an Expert Reviewer who will advise IANA rules. The IESG will appoint an Expert Reviewer who will advise IANA
promptly on each request for a new or updated GNSS type. promptly on each request for a new or updated GNSS type.
skipping to change at page 63, line 49 skipping to change at page 68, line 17
9.11. XML Schema Registration for Measurement Source Schema 9.11. XML Schema Registration for Measurement Source Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.2 of this Schema: The XML for this schema can be found in Section 8.2 of this
document. document.
9.12. XML Schema Registration for Measurement Container Schema 9.12. XML Schema Registration for Measurement Container Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm URI: urn:ietf:params:xml:schema:lm
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.1 of this Schema: The XML for this schema can be found in Section 8.1 of this
document. document.
9.13. XML Schema Registration for Base Types Schema 9.13. XML Schema Registration for Base Types Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:basetypes URI: urn:ietf:params:xml:schema:lm:basetypes
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.3 of this Schema: The XML for this schema can be found in Section 8.3 of this
document. document.
9.14. XML Schema Registration for LLDP Schema 9.14. XML Schema Registration for LLDP Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:lldp URI: urn:ietf:params:xml:schema:lm:lldp
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.4 of this Schema: The XML for this schema can be found in Section 8.4 of this
document. document.
9.15. XML Schema Registration for DHCP Schema 9.15. XML Schema Registration for DHCP Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:dhcp URI: urn:ietf:params:xml:schema:lm:dhcp
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.5 of this Schema: The XML for this schema can be found in Section 8.5 of this
document. document.
9.16. XML Schema Registration for WiFi Schema 9.16. XML Schema Registration for WiFi Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:wifi URI: urn:ietf:params:xml:schema:lm:wifi
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.6 of this Schema: The XML for this schema can be found in Section 8.6 of this
document. document.
9.17. XML Schema Registration for Cellular Schema 9.17. XML Schema Registration for Cellular Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:cellular URI: urn:ietf:params:xml:schema:lm:cellular
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.7 of this Schema: The XML for this schema can be found in Section 8.7 of this
document. document.
9.18. XML Schema Registration for GNSS Schema 9.18. XML Schema Registration for GNSS Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:gnss URI: urn:ietf:params:xml:schema:lm:gnss
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.8 of this Schema: The XML for this schema can be found in Section 8.8 of this
document. document.
9.19. XML Schema Registration for DSL Schema 9.19. XML Schema Registration for DSL Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:dsl URI: urn:ietf:params:xml:schema:lm:dsl
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 6.9 of this Schema: The XML for this schema can be found in Section 8.9 of this
document. document.
10. Acknowledgements 10. Acknowledgements
Thanks go to Simon Cox for his comments relating to terminology that Thanks go to Simon Cox for his comments relating to terminology that
have helped ensure that this document is aligns with ongoing work in have helped ensure that this document is aligns with ongoing work in
the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his
review and comments on the GNSS sections of this document. Thanks to review and comments on the GNSS sections of this document. Thanks to
Noor-E-Gagan Singh, Gabor Bajko and Russell Priebe for independent Noor-E-Gagan Singh, Gabor Bajko and Russell Priebe for their
suggestions for improving the parameters associated with 802.11 significant input to and suggestions for improving the 802.11
measurements. Thanks to Cullen Jennings for feedback and measurements. Thanks to Cullen Jennings for feedback and
suggestions. Bernard Aboba provided review and feedback on a range suggestions. Bernard Aboba provided review and feedback on a range
of measurement data definitions. Mary Barnes provided a review and of measurement data definitions. Mary Barnes provided a review and
corrections. corrections.
11. References 11. References
11.1. Normative References 11.1. Normative References
[DSL.TR025] [DSL.TR025]
skipping to change at page 67, line 30 skipping to change at page 71, line 43
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
11.2. Informative References 11.2. Informative References
[ANSI/TIA-1057] [ANSI/TIA-1057]
ANSI/TIA, "Link Layer Discovery Protocol for Media ANSI/TIA, "Link Layer Discovery Protocol for Media
Endpoint Devices", TIA 1057, April 2006. Endpoint Devices", TIA 1057, April 2006.
[GPS.SPOOF]
Scott, L., "Anti-Spoofing and Authenticated Signal
Architectures for Civil Navigation Signals", ION-
GNSS Portland, Oregon, 2003.
[HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side
spoofing and detection for Assisted-GPS", Proceedings of spoofing and detection for Assisted-GPS", Proceedings of
International Global Navigation Satellite Systems Society International Global Navigation Satellite Systems Society
(IGNSS) Symposium 2009 16, December 2009, (IGNSS) Symposium 2009 16, December 2009,
<http://ignss.org/files/Paper16.pdf>. <http://ignss.org/files/Paper16.pdf>.
[I-D.ietf-geopriv-held-identity-extensions] [I-D.ietf-geopriv-held-identity-extensions]
Winterbottom, J., Thomson, M., Tschofenig, H., and R. Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", Delivery (HELD)",
skipping to change at page 68, line 5 skipping to change at page 72, line 22
[I-D.thomson-geopriv-uncertainty] [I-D.thomson-geopriv-uncertainty]
Thomson, M. and J. Winterbottom, "Representation of Thomson, M. and J. Winterbottom, "Representation of
Uncertainty and Confidence in PIDF-LO", Uncertainty and Confidence in PIDF-LO",
draft-thomson-geopriv-uncertainty-05 (work in progress), draft-thomson-geopriv-uncertainty-05 (work in progress),
May 2010. May 2010.
[IANA.enterprise] [IANA.enterprise]
IANA, "Private Enterprise Numbers", IANA, "Private Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers>. <http://www.iana.org/assignments/enterprise-numbers>.
[IEEE.80211]
IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) specifications - IEEE 802.11 Wireless
Network Management", IEEE Std 802.11-2007, June 2007.
[IEEE.80211V] [IEEE.80211V]
IEEE, "Wireless LAN Medium Access Control (MAC) and IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) specifications - IEEE 802.11 Wireless Physical Layer (PHY) specifications - IEEE 802.11 Wireless
Network Management (Draft)", P802.11v D12.0, June 2010. Network Management (Draft)", P802.11v D12.0, June 2010.
[IEEE.8021AB] [IEEE.8021AB]
IEEE, "IEEE Standard for Local and Metropolitan area IEEE, "IEEE Standard for Local and Metropolitan area
networks, Station and Media Access Control Connectivity networks, Station and Media Access Control Connectivity
Discovery", 802.1AB, June 2005. Discovery", 802.1AB, June 2005.
 End of changes. 86 change blocks. 
856 lines changed or deleted 1007 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/