Using Device-Provided Location-Related Measurements in Location Configuration Protocols
Extracted elements (32)
A Device in a unique observer position (the only entity at the exact space-time point being located) makes its measurements both invaluable and unverifiable: no other entity can independently confirm the same observation. This fundamental asymmetry limits the effectiveness of measurement validation and motivates the location validation approach as a complementary mitigation.
GNSS and other per-satellite measurement values are converted from system-native units (chips, wavelengths, Hz) to system-independent units (milliseconds, meters per second) in the schema, so that a LIS can use the measurements without needing knowledge of carrier frequencies or chip rates specific to each GNSS.
A Device MUST NOT provide information about network topology (e.g., LLDP, DHCP, DSL measurements) without a clear signal that the recipient LIS is authorized; a LIS discovered using DHCP per RFC 5986 can be considered authorized to receive access network information.
A Device that provides location-related measurement data MUST only do so as explicitly authorized by a Rule Maker, requiring an interface that allows Rule Makers (e.g., users or administrators) to control where and how measurement data is provided.
A LIS MUST discard location-related measurement data after servicing the request that contained it, unless the Device explicitly grants permission to use that information for other purposes.
A LIS MUST NOT retain location-related measurement data in memory, storage, or logs beyond the time indicated in the 'expires' attribute. If the 'expires' attribute is absent, the LIS MUST NOT retain the measurement data at all.
A LIS MUST NOT reveal location-related measurement data to any other entity, and MUST NOT reveal location information based on measurement data to any other entity unless directed to do so by the Device.
A third-party requester providing measurement data MUST be authorized to provide the specific measurement for the identified Device: either the LIS trusts the third party for that measurement type, or the measurement data MUST be validated before use.
Extensions that could result in backward incompatibility MUST be added as new measurement definitions rather than as extensions to existing types, ensuring that a LIS can safely ignore measurement data it does not support.
LLDP measurement values MUST be reported directly as provided by the adjacent node; attempting to adjust or translate identifier types is likely to render the measurement data useless to the LIS.
Measurement data MUST be protected with the same degree of protection as location information. TLS confidentiality and authentication MUST be used to convey measurement data over HELD; other protocols MUST provide comparable guarantees.
Measurement validation MUST be used if measurement data for a particular Device can be easily acquired by unauthorized location recipients, as described in the unauthorized acquisition threat, to prevent unauthorized access to location information.
The DHCP relay agent 'subscriber' element MUST NOT be provided to a LIS that is not authorized to receive information about the access network, as subscriber identifiers are considered sensitive.
The 'time' attribute on the 'measurements' element SHOULD be provided whenever possible, allowing the LIS to avoid selecting an arbitrary timestamp and to determine whether measurement data is current enough to be useful.
In the simple distribution model, the Device is the sole entity authorized to distribute measurement data; no entity (including the LIS) may redistribute it. The LIS may use measurement data only to serve the specific request that contained it, unless the Device explicitly permits other uses such as serving location URIs.
Location-related measurement data is effectively equivalent in privacy sensitivity to location information when the contextual knowledge to convert between them is readily accessible. Measurement data MUST therefore be protected with the same confidentiality and authentication mechanisms as location information itself.
802.11 WiFi measurements are conveyed in a 'wifi' element containing one or more 'ap' elements (mandatory 'bssid'; optional 'ssid', 'channel', 'type', 'band', 'flightTime', 'apSignal', 'deviceSignal') and an optional 'nicType'. The 'rcpi' signal strength value SHOULD be in dBm; if not, the 'dBm' attribute MUST be set to 'false'.
Cellular measurements are conveyed in a 'cellular' element supporting LTE (eucid: 28-bit), UMTS (rnc: 12/16-bit, cid: 16-bit), GSM (lac: 16-bit, cid: 16-bit), and CDMA (sid: 15-bit, nid: 16-bit, baseid: 16-bit) cells. Both 'servingCell' and multiple 'observedCell' elements may be included; 3GPP cells are identified by MCC and MNC.
DSL measurements are conveyed in a 'dsl' element supporting four sub-types: L2TP (src, dest, session), RADIUS/AN (an, slot, port), Ethernet VLAN (stag, ctag), and ATM virtual circuit (vpi, vci). These allow an ISP-operated LIS to pass identifying information to an infrastructure-provider LIS that lacks knowledge of Device identifiers.
GNSS measurements are conveyed in a 'gnss' element with 'system' and 'signal' attributes, containing per-satellite 'sat' elements with 'num', 'doppler' (m/s), 'codephase' (ms), 'cn0' (dB-Hz), and optional 'mp', 'cq', 'adr' fields. All values are normalized to system-independent units. The receiver SHOULD indicate an estimated time error for any provided time.
LLDP measurements are conveyed in a 'lldp' element containing 'chassis' and 'port' child elements with hexadecimal values and numeric 'type' attributes corresponding to LLDP TLV types. Multiple 'lldp' elements may be repeated for multiple adjacent nodes.
The 'measurementRequest' element allows a protocol peer (e.g., a LIS in a HELD error response) to describe measurement types it desires. It contains one or more 'measurement' child elements bearing a 'type' attribute (XML qualified name) and optional 'samples' count and type-specific refinement elements.
The 'measurements' XML element (namespace urn:ietf:params:xml:ns:geopriv:lm) is the standard container for conveying location-related measurement data in Location Configuration Protocols. It carries 'time' and optional 'expires' attributes common to all measurement types and permits inclusion of arbitrary typed measurement child elements.
The 'source' element, added to the 'geopriv' element of a PIDF-LO, identifies the type of measurement source contributing to location information. Defined values are 'lis' (LIS-validated data), 'device' (unvalidated Device-provided data, MUST be included if applicable), and 'other' (third-party data, MUST be included unless the third party is trusted).
This document creates an IANA registry for GNSS System Types, mapping short string tokens (e.g., 'gps', 'galileo') to satellite navigation systems. Initial entries register GPS [GPS.ICD] and Galileo [Galileo.ICD]. The registry also records the supported signal identifiers and time system for each entry.
This document registers nine URN sub-namespaces (urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc, urn:ietf:params:xml:ns:geopriv:lm, and seven measurement-type-specific namespaces) and nine corresponding XML schemas (measurement source, container, base types, LLDP, DHCP, WiFi, cellular, GNSS, DSL) in the IANA XML registry.
An attacker can present measurement data belonging to a different Device to coerce a LIS into providing location information for that Device without authorization, particularly for measurement types (e.g., LLDP) that are broadcast to all nodes on the same network segment and thus easily collected.
Environment spoofing allows a third party near the Device to alter the measured physical environment (e.g., GNSS signal spoofing, radio signal amplification) so the Device unwittingly provides falsified measurement data, potentially causing the LIS to generate incorrect location information attributed to the LIS itself.
Measurement replay attacks exploit the time-invariance of many network properties: an attacker can collect measurement data (e.g., radio transmitter identities) once and replay them later without detection, since nothing inherent in the measurement reveals it was acquired at a different time or place.
The 'lying by proxy' attack uses easily falsified measurement data (e.g., GNSS, whose contextual data is broadcast publicly) to coerce the LIS into producing falsified location information bearing the LIS's credibility, which is then conveyed to third-party location recipients. Digitally signed location information or location URIs served directly by the LIS are the primary attack vectors.
Two general mitigations are defined: (1) independent measurement validation — comparing Device-provided data against trusted sources or corroborating it — and (2) location validation — comparing untrusted location derived from Device measurements against trusted location from LIS-controlled sources, discarding the untrusted result if it falls outside the trusted uncertainty region.
RMS error and sample count attributes ('rmsError' and 'samples') are defined for numeric measurement values. 'rmsError' is expressed in the same units as the measurement; if omitted, 'samples' can be assumed large enough that rmsError equals standard deviation. A fixed MAY be provided where measurement error is technique-dependent rather than circumstance-dependent.