idnits 2.17.1
draft-ietf-geopriv-held-measurements-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to contain a disclaimer for pre-RFC5378 work, but was
first submitted on or after 10 November 2008. The disclaimer is usually
necessary only for documents that revise or obsolete older RFCs, and that
take significant amounts of text from those RFCs. If you can contact all
authors of the source material and they are willing to grant the BCP78
rights to the IETF Trust, you can and should remove the disclaimer.
Otherwise, the disclaimer is needed and you can ignore this comment.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 25, 2010) is 4930 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: '0-5' is mentioned on line 2069, but not defined
== Missing Reference: '0-4' is mentioned on line 2069, but not defined
== Missing Reference: '0-9' is mentioned on line 2069, but not defined
== Missing Reference: '0-1' is mentioned on line 2069, but not defined
== Unused Reference: 'I-D.thomson-geopriv-uncertainty' is defined on line
3212, but no explicit reference was found in the text
== Unused Reference: 'RFC5808' is defined on line 3265, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
== Outdated reference: A later version (-06) exists of
draft-ietf-geopriv-held-identity-extensions-05
== Outdated reference: A later version (-08) exists of
draft-thomson-geopriv-uncertainty-05
Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV M. Thomson
3 Internet-Draft J. Winterbottom
4 Intended status: Standards Track Andrew
5 Expires: April 28, 2011 October 25, 2010
7 Using Device-provided Location-Related Measurements in Location
8 Configuration Protocols
9 draft-ietf-geopriv-held-measurements-02
11 Abstract
13 A method is described by which a Device is able to provide location-
14 related measurement data to a LIS within a request for location
15 information. Location-related measurement information are
16 observations concerning properties related to the position of a
17 Device, which could be data about network attachment or about the
18 physical environment. When a LIS generates location information for
19 a Device, information from the Device can improve the accuracy of the
20 location estimate. A basic set of location-related measurements are
21 defined, including common modes of network attachment as well as
22 assisted Global Navigation Satellite System (GNSS) parameters.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on April 28, 2011.
41 Copyright Notice
43 Copyright (c) 2010 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 This document may contain material from IETF Documents or IETF
57 Contributions published or made publicly available before November
58 10, 2008. The person(s) controlling the copyright in some of this
59 material may not have granted the IETF Trust the right to allow
60 modifications of such material outside the IETF Standards Process.
61 Without obtaining an adequate license from the person(s) controlling
62 the copyright in such materials, this document may not be modified
63 outside the IETF Standards Process, and derivative works of it may
64 not be created outside the IETF Standards Process, except to format
65 it for publication as an RFC or to translate it into languages other
66 than English.
68 Table of Contents
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
71 2. Conventions used in this document . . . . . . . . . . . . . . 6
72 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 7
73 4. Location-Related Measurement Data Types . . . . . . . . . . . 8
74 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 9
75 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 9
76 4.1.2. Expiry Time on Location-Related Measurement Data . . . 9
77 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 10
78 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . . 10
79 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 11
80 4.4. Identifying Location Provenance . . . . . . . . . . . . . 12
81 5. Location-Related Measurement Data Types . . . . . . . . . . . 15
82 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 15
83 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 16
84 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 16
85 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 20
86 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 20
87 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 23
88 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 23
89 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . . 25
90 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 26
91 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . . 26
92 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 27
93 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 27
94 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 28
95 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 28
96 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 29
97 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 29
98 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 29
99 6.1. Measurement Data Privacy Model . . . . . . . . . . . . . . 30
100 6.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . . 30
101 6.3. Measurement Data and Location URIs . . . . . . . . . . . . 30
102 6.4. Third-Party-Provided Measurement Data . . . . . . . . . . 31
103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
104 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 31
105 7.1.1. Acquiring Location Information Without
106 Authorization . . . . . . . . . . . . . . . . . . . . 32
107 7.1.2. Extracting Network Topology Data . . . . . . . . . . . 33
108 7.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . . 33
109 7.1.4. Measurement Replay . . . . . . . . . . . . . . . . . . 34
110 7.1.5. Environment Spoofing . . . . . . . . . . . . . . . . . 35
111 7.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 36
112 7.2.1. Measurement Validation . . . . . . . . . . . . . . . . 37
113 7.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 37
114 7.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 37
115 7.2.2. Location Validation . . . . . . . . . . . . . . . . . 38
116 7.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 39
117 7.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 39
118 7.2.3. Supporting Observations . . . . . . . . . . . . . . . 39
119 7.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 40
120 7.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 40
121 7.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 41
122 7.2.5. Stateful Correlation of Location Requests . . . . . . 42
123 8. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 42
124 8.1. Measurement Container Schema . . . . . . . . . . . . . . . 42
125 8.2. Measurement Source Schema . . . . . . . . . . . . . . . . 45
126 8.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 45
127 8.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 48
128 8.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 49
129 8.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 51
130 8.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 54
131 8.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 57
132 8.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 58
133 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
134 9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 60
135 9.2. URN Sub-Namespace Registration for
136 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 61
137 9.3. URN Sub-Namespace Registration for
138 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 62
139 9.4. URN Sub-Namespace Registration for
140 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 63
141 9.5. URN Sub-Namespace Registration for
142 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 64
143 9.6. URN Sub-Namespace Registration for
144 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 64
145 9.7. URN Sub-Namespace Registration for
146 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 65
147 9.8. URN Sub-Namespace Registration for
148 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 66
149 9.9. URN Sub-Namespace Registration for
150 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 66
151 9.10. URN Sub-Namespace Registration for
152 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 67
153 9.11. XML Schema Registration for Measurement Source Schema . . 68
154 9.12. XML Schema Registration for Measurement Container
155 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 68
156 9.13. XML Schema Registration for Base Types Schema . . . . . . 68
157 9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 68
158 9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 69
159 9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 69
160 9.17. XML Schema Registration for Cellular Schema . . . . . . . 69
161 9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 70
162 9.19. XML Schema Registration for DSL Schema . . . . . . . . . . 70
163 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 70
164 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
165 11.1. Normative References . . . . . . . . . . . . . . . . . . . 70
166 11.2. Informative References . . . . . . . . . . . . . . . . . . 71
167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
169 1. Introduction
171 A location configuration protocol (LCP) provides a means for a Device
172 to request information about its physical location from an access
173 network. A location information server (LIS) is the server that
174 provides location information; information that is available due to
175 the knowledge about the network and physical environment that is
176 available to the LIS.
178 As a part of the access network, the LIS is able to acquire
179 measurement results from network Devices within the network that are
180 related to Device location. The LIS also has access to information
181 about the network topology that can be used to turn measurement data
182 into location information. However, this information can be enhanced
183 with information acquired from the Device itself.
185 A Device is able to make observations about its network attachment,
186 or its physical environment. The location-related measurement data
187 might be unavailable to the LIS; alternatively, the LIS might be able
188 to acquire the data, but at a higher cost in time or otherwise.
189 Providing measurement data gives the LIS more options in determining
190 location, which could improve the quality of the service provided by
191 the LIS. Improvements in accuracy are one potential gain, but
192 improved response times and lower error rates are also possible.
194 This document describes a means for a Device to report location-
195 related measurement data to the LIS. Examples based on the HELD
196 [I-D.ietf-geopriv-http-location-delivery] location configuration
197 protocol are provided.
199 2. Conventions used in this document
201 The terms LIS and Device are used in this document in a manner
202 consistent with the usage in
203 [I-D.ietf-geopriv-http-location-delivery].
205 This document also uses the following definitions:
207 Location Measurement: An observation about the physical properties
208 of a particular Device's network access. The result of a location
209 measurement--"location-related measurement data", or simply
210 "measurement data" given sufficient context--can be used to
211 determine the location of a Device. Location-related measurement
212 data does not identify a Device; measurement data can change with
213 time if the location of the Device also changes.
215 Location-related measurement data does not necessarily contain
216 location information directly, but it can be used in combination
217 with contextual knowledge of the network, or algorithms to derive
218 location information. Examples of location-related measurement
219 data are: radio signal strength or timing measurements, Ethernet
220 switch and port identifiers.
222 Location-related measurement data can be considered sighting
223 information, based on the definition in [RFC3693].
225 Location Estimate: The result of location determination, a location
226 estimate is an approximation of where the Device is located.
227 Location estimates are subject to uncertainty, which arise from
228 errors in measurement results.
230 GNSS: Global Navigation Satellite System. A satellite-based system
231 that provides positioning and time information. For example, the
232 US Global Positioning System (GPS) or the European Galileo system.
234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
236 document are to be interpreted as described in [RFC2119].
238 3. Location-Related Measurements in LCPs
240 This document defines a standard container for the conveyance of
241 location-related measurement parameters in location configuration
242 protocols. This is an XML container that identifies parameters by
243 type and allows the Device to provide the results of any measurement
244 it is able to perform. A set of measurement schemas are also defined
245 that can be carried in the generic container.
247 The simplest example of measurement data conveyance is illustrated by
248 the example message in Figure 1. This shows a HELD location request
249 message with an Ethernet switch and port measurement taken using LLDP
250 [IEEE.8021AB].
252
253 civic
254
256
257 0a01003c
258 c2
259
260
261
262 Figure 1: HELD Location Request with Measurement Data
264 Measurement data that the LIS does not support or understand can be
265 ignored. The measurements defined in this document follow this rule;
266 extensions that could result in backward incompatibility MUST be
267 added as new measurement definitions rather than extensions to
268 existing types.
270 Multiple sets of measurement data, either of the same type or from
271 different sources can be included in the "measurements" element. See
272 Section 4.1.1 for details on repetition of this element.
274 Use of location-related measurement data is at the discretion of the
275 LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to
276 reflect the method used.
278 Location-related measurement data need not be provided exclusively by
279 Devices. A third party location requester can request location
280 information using measurement data, if they are able and authorized.
281 There are privacy considerations relating to the use of measurements
282 by third parties, which are discussed in Section 6.4.
284 Location-related measurement data and its use presents a number of
285 security challenges. These are described in more detail in
286 Section 7.
288 4. Location-Related Measurement Data Types
290 A common container is defined for the expression of location
291 measurement data, as well as a simple means of identifying specific
292 types of measurement data for the purposes of requesting them.
294 The following example shows a measurement container with measurement
295 time and expiration time included. A WiFi measurement is enclosed.
297
300
301
302 00-12-F0-A0-80-EF
303 wlan-home
304
305
306
308 Figure 2: Measurement Example
310 4.1. Measurement Container
312 The "measurement" element is used to encapsulate measurement data
313 that is collected at a certain point in time. It contains time-based
314 attributes that are common to all forms of measurement data, and
315 permits the inclusion of arbitrary measurement data.
317 This container can be added to any request for location information,
318 such as a HELD location request
319 [I-D.ietf-geopriv-http-location-delivery].
321 4.1.1. Time of Measurement
323 The "time" attribute records the time that the measurement or
324 observation was made. This time can be different to the time that
325 the measurement information was reported. Time information can be
326 used to populate a timestamp on the location result, or to determine
327 if the measurement information is used.
329 The "time" attribute is optional to avoid forcing an arbitrary choice
330 of timestamp for relatively static types of measurement (for
331 instance, the DSL measurements in Section 5.6) and for legacy Devices
332 that don't record time information (such as the Home Location
333 Register/Home Subscriber Server for cellular). However, time SHOULD
334 be provided whenever possible.
336 The "time" attribute is attached to the root "measurement" element.
337 If it is necessary to provide multiple sets of measurement data with
338 different times, multiple "measurement" elements SHOULD be provided.
340 4.1.2. Expiry Time on Location-Related Measurement Data
342 A Device is able to indicate an expiry time in the location
343 measurement using the "expires" attribute. Nominally, this attribute
344 indicates how long information is expected to be valid for, but it
345 can also indicate a time limit on the retention and use of the
346 measurement data. A Device can use this attribute to prevent the LIS
347 from retaining measurement data or limit the time that a LIS retains
348 this information.
350 Note: Movement of a Device might result in the measurement data
351 being invalidated before the expiry time.
353 The LIS MUST NOT keep location-related measurement data beyond the
354 time indicated in the "expires" attribute.
356 4.2. RMS Error and Number of Samples
358 Often a measurement is taken more than once over a period of time.
359 Reporting the average of a number of measurement results mitigates
360 the effects of random errors that occur in the measurement process.
362 Reporting each measurement individually can be the most effective
363 method of reporting multiple measurements. This is achieved by
364 providing multiple "measurement" elements for different times.
366 The alternative is to aggregate multiple measurements and report a
367 mean value across the set of measurements. Additional information
368 about the distribution of the results can be useful in determining
369 location uncertainty.
371 Two optional attributes are provided for certain measurement values:
373 rmsError: The root-mean-squared (RMS) error of the set of
374 measurement values used in calculating the result. RMS error is
375 expressed in the same units as the measurement, unless otherwise
376 stated. If an accurate value for RMS error is not known, this
377 value can be used to indicate an upper bound or estimate for the
378 RMS error.
380 samples: The number of samples that were taken in determining the
381 measurement value. If omitted, this value can be assumed to be a
382 very large value, so that the RMS error is an indication of the
383 standard deviation of the sample set.
385 For some measurement techniques, measurement error is largely
386 dependent on the measurement technique employed. In these cases,
387 measurement error is largely a product of the measurement technique
388 and not the specific circumstances, so RMS error does not need to be
389 actively measured. A fixed value MAY be provided for RMS error where
390 appropriate.
392 The "rmsError" and "samples" elements are added as attributes of
393 specific measurement data types.
395 4.2.1. Time RMS Error
397 Measurement of time can be significant in certain circumstances. The
398 GNSS measurements included in this document are one such case where a
399 small error in time can result in a large error in location. Factors
400 such as clock drift and errors in time sychronization can result in
401 small, but significant, time errors. Including an indication of the
402 quality of the time can be helpful.
404 An optional "timeError" attribute can be added to the "measurement"
405 element to indicate the RMS error in time. "timeError" indicates an
406 upper bound on the time RMS error in seconds.
408 The "timeError" attribute does not apply where multiple samples of a
409 measurement is taken over time. If multiple samples are taken, each
410 SHOULD be included in a different "measurement" element.
412 4.3. Measurement Request
414 A measurement request is used by a protocol peer to describe a set of
415 measurement data that it desires. A "measurementRequest" element is
416 defined that can be included in a protocol exchange.
418 For instance, a LIS can use a measurement request in HELD responses.
419 If the LIS is unable to provide location information, but it believes
420 that a particular measurement type would enable it to provide a
421 location, it can include a measurement request in an error response.
423 The "measurement" element of the measurement request identifies the
424 type of measurement that is requested. The "type" attribute of this
425 element indicates the type of measurement, as identified by an XML
426 qualified name. An optional "samples" attribute indicates how many
427 samples of the identified measurement are requested.
429 The "measurement" element can be repeated to request multiple (or
430 alternative) measurement types.
432 Additional XML content might be defined for a particular measurement
433 type that is used to further refine a request. These elements either
434 constrain what is requested or specify optional components of the
435 measurement data that are needed. These are defined along with the
436 specific measurement type.
438 In the HELD protocol, the inclusion of a measurement request in a
439 error response with a code of "locationUnknown" indicates that the
440 LIS believes that providing the indicated measurements would increase
441 the likelihood of a subsequent request being successful.
443 The following example shows a HELD error response that indicates that
444 WiFi measurement data would be useful if a later request were made.
445 Additional elements indicate that received signal strength for an
446 802.11n access point is requested.
448
450 Insufficient measurement data
451
454
455 n
456 wifi:rcpi
457
458
459
461 Figure 3: HELD Error Requesting Measurement Data
463 A measurement request that is included in other HELD messages has
464 undefined semantics and can be safely ignored. Other specifications
465 might define semantics for measurement requests under other
466 conditions.
468 4.4. Identifying Location Provenance
470 An extension is made to the PIDF-LO [RFC4119] that allows a location
471 recipient to identify the source (or sources) of location information
472 and the measurement data that was used to determine that location
473 information.
475 The "source" element is added to the "geopriv" element of the
476 PIDF-LO. This element does not identify specific entities. Instead,
477 it identifies the type of source.
479 The following types of measurement source are identified:
481 lis: Location information is based on measurement data that the LIS
482 or sources that it trusts have acquired. This label might be used
483 if measurement data provided by the Device has been completely
484 validated by the LIS.
486 device: Location information is based on measurement data that the
487 Device has provided to the LIS.
489 other: Location information is based on measurement data that a
490 third party has provided. This might be an authorized third party
491 that uses identity parameters
492 [I-D.ietf-geopriv-held-identity-extensions] or any other entity.
494 No assertion is made about the veracity of the measurement data from
495 sources other than the LIS. A combination of tags MAY be included to
496 indicate that measurement data from both sources was used.
498 For example, the first tuple of the following PIDF-LO indicates that
499 measurement data from a LIS and a device was combined to produce the
500 result, the second tuple was produced by the LIS alone.
502
508
509
510
511
512
513 7.34324 134.47162
514
515 850.24
516
517
518
519
520 OTDOA
521 lis device
522
523
524
525
526
527
528
529
530 7.34379 134.46484
531
532 9000
533
534
535
536
537 Cell
538 lis
539
540
541
542
544 5. Location-Related Measurement Data Types
546 This document defines location-related measurement data types for a
547 range of common network types.
549 All included measurement data definitions allow for arbitrary
550 extension in the corresponding schema. As new parameters that are
551 applicable to location determination are added, these can be added as
552 new XML elements in a unique namespace. Though many of the
553 underlying protocols support extension, creation of specific XML-
554 based extensions to the measurement format is favored over
555 accomodating protocol-specific extensions in generic containers.
557 5.1. LLDP Measurements
559 Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent
560 between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet,
561 WiFi, 802.16). These messages all contain identification information
562 for the sending node, which can be used to determine location
563 information. A Device that receives LLDP messages can report this
564 information as a location-related measurement to the LIS, which is
565 then able to use the measurement data in determining the location of
566 the Device.
568 Note: The LLDP extensions defined in LLDP Media Endpoint Discovery
569 (LLDP-MED) [ANSI/TIA-1057] provide the ability to acquire location
570 information directly from an LLDP endpoint. Where this
571 information is available, it might be unnecessary to use any other
572 form of location configuration.
574 The Device MUST report the values directly as they were provided by
575 the adjacent node. Attempting to adjust or translate the type of
576 identifier is likely to cause the measurement data to be useless.
578 Where a Device has received LLDP messages from multiple adjacent
579 nodes, it should provide information extracted from those messages by
580 repeating the "lldp" element.
582 An example of an LLDP measurement is shown in Figure 4. This shows
583 an adjacent node (chassis) that is identified by the IP address
584 192.0.2.45 (hexadecimal c000022d) and the port on that node is
585 numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).
587
589
590 c000022d
591 a2
592
593
595 Figure 4: LLDP Measurement Example
597 IEEE 802 Devices that are able to obtain information about adjacent
598 network switches and their attachment to them by other means MAY use
599 this data type to convey this information.
601 5.2. DHCP Relay Agent Information Measurements
603 The DHCP Relay Agent Information option [RFC3046] provides
604 measurement data about the network attachment of a Device. This
605 measurement data can be included in the "dhcp-rai" element.
607 The elements in the DHCP relay agent information options are opaque
608 data types assigned by the DHCP relay agent. The three items are all
609 optional: circuit identifier ("circuit", [RFC3046]), remote
610 identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier
611 ("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier
612 has an associated enterprise number [IANA.enterprise] as an XML
613 attribute.
615
617
618 ::ffff:192.0.2.158
619 108b
620
621
623 Figure 5: DHCP Relay Agent Information Measurement Example
625 The "giaddr" is specified as a dotted quad IPv4 address or an RFC
626 4291 [RFC4291] IPv6 address. The enterprise number is specified as a
627 decimal integer. All other information is included verbatim from the
628 DHCP request in hexadecimal format.
630 5.3. 802.11 WLAN Measurements
632 In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to
633 provide information about the access point (AP) that it is attached
634 to, or other WiFi points it is able to see. This is provided using
635 the "wifi" element, as shown in Figure 6, which shows a single
636 complete measurement for a single access point.
638
640
641 Intel(r)PRO/Wireless 2200BG
642
643 AB-CD-EF-AB-CD-EF
644 example
645 5
646
647
648 -34.4 150.8
649
650
651 a
652 5
653 2
654 2
655 2.56e-9
656
657 23
658 5
659 -59
660 23
661
662
663 10
664 9
665 -98.5
666 7.5
667
668
669
670
672 Figure 6: 802.11 WLAN Measurement Example
674 A wifi element is made up of one or more access points, and an
675 optional "nicType" element. Each access point is described using the
676 "ap" element, which is comprised of the following fields:
678 bssid: The basic service set identifier. In an Infrastructure BSS
679 network, the bssid is the 48 bit MAC address of the access point.
681 The "verified" attribute of this element describes whether the
682 device has verified the MAC address or it authenticated the access
683 point or the network operating the access point (for example, a
684 captive portal accessed through the access point has been
685 authenticated). This attributes defaults to a value of "false"
686 when omitted.
688 ssid: The service set identifier (SSID) for the wireless network
689 served by the access point.
691 The SSID is a 32-octet identifier that is commonly represented as
692 a ASCII [RFC0020] or UTF-8 [RFC3629] encoded string. To represent
693 octets that cannot be directly included in an XML element,
694 escaping is used. Sequences of octets that do not represent a
695 valid UTF-8 encoding can be escaped using a backslash ('\')
696 followed by two case-insensitive hexadecimal digits representing
697 the value of a single octet.
699 The canonical or value-space form of an SSID is a sequence of up
700 to 32 octets that is produced from the concatenation of UTF-8
701 encoded sequences of unescaped characters and octets derived from
702 escaped components.
704 channel: The channel number (frequency) that the access point
705 operates on.
707 location: The location of the access point, as reported by the
708 access point. This element contains any valid location, using the
709 rules for a "location-info" element, as described in [RFC5491].
711 type: The network type for the network access. This element
712 includes the alphabetic suffix of the 802.11 specification that
713 introducted the radio interface, or PHY; e.g. "a", "b", "g", or
714 "n".
716 band: The frequency band for the radio, in gigahertz (GHz). 802.11
717 [IEEE.80211] specifies PHY layers that use 2.4, 3.7 and 5
718 gigahertz frequency bands.
720 regclass: The regulatory domain and class. The "country" attribute
721 optionally includes the applicable two character country
722 identifier (dot11CountryString), which can be followed by an 'O',
723 'I' or 'X'. The element text content includes the value of the
724 regulatory class: an 8-bit integer in decimal form.
726 antenna: The antenna identifier for the antenna that the access
727 point is using to transmit the measured signals.
729 flightTime: Flight time is the difference between the time of
730 departure (TOD) of signal from a transmitting station and time of
731 arrival (TOA) of signal at a receiving station, as defined in
732 [IEEE.80211V]. Measurement of this value requires that stations
733 synchronize their clocks. This value can be measured by access
734 point or Device; because the flight time is assumed to be the same
735 in either direction - aside from measurement errors - only a
736 single element is provided. This element includes optional
737 "rmsError" and "samples" attributes. RMS error might be derived
738 from the reported RMS error in TOD and TOA.
740 apSignal: Measurement information for the signal transmitted by the
741 access point, as observed by the Device. Some of these values are
742 derived from 802.11v [IEEE.80211V] messages exchanged between
743 Device and access point. The contents of this element include:
745 transmit: The transmit power reported by the access point, in dB.
747 gain: The gain of the access point antenna reported by the access
748 point, in dB.
750 rcpi: The received channel power indicator for the access point
751 signal, as measured by the Device. This value SHOULD be in
752 units of dBm (with RMS error in dB). If power is measured in a
753 different fashion, the "dBm" attribute MUST be set to "false".
754 Signal strength reporting on current hardware uses a range of
755 different mechanisms; therefore, the value of the "nicType"
756 element SHOULD be included if the units are not known to be in
757 dBm and the value reported by the hardware should be included
758 without modification. This element includes optional
759 "rmsError" and "samples" attributes.
761 rsni: The received signal to noise indicator in dBm. This
762 element includes optional "rmsError" and "samples" attributes.
764 deviceSignal: Measurement information for the signal transmitted by
765 the device, as reported by the access point. This element
766 contains the same child elements as the "ap" element, with the
767 access point and Device roles reversed.
769 All elements are optional except for "bssid".
771 The "nicType" element is used to specify the make and model of the
772 wireless network interface in the Device. Different 802.11 chipsets
773 report measurements in different ways, so knowing the network
774 interface type aids the LIS in determining how to use the provided
775 measurement data. The content of this field is unconstrained and no
776 mechanisms are specified to ensure uniqueness.
778 5.3.1. Wifi Measurement Requests
780 Two elements are defined for requesting WiFi measurements in a
781 measurement request:
783 type: The "type" element identifies the desired type (or types that
784 are requested.
786 parameter: The "parameter" element identifies an optional
787 measurements are requested for each measured access point. An
788 element is identified by its qualified name. The optional
789 "context" parameter can be used to specify if an element is
790 included as a child of the "ap" or "device" elements; omission
791 indicates that it applies to both.
793 Multiple types or parameters can be requested by repeating either
794 element.
796 5.4. Cellular Measurements
798 Cellular Devices are common throughout the world and base station
799 identifiers can provide a good source of coarse location information.
800 This information can be provided to a LIS run by the cellar operator,
801 or may be provided to an alternative LIS operator that has access to
802 one of several global cell-id to location mapping databases.
804 A number of advanced location determination methods have been
805 developed for cellular networks. For these methods a range of
806 measurement parameters can be collected by the network, Device, or
807 both in cooperation. This document includes a basic identifier for
808 the wireless transmitter only; future efforts might define additional
809 parameters that enable more accurate methods of location
810 determination.
812 The cellular measurement set allows a Device to report to a LIS any
813 LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10)
814 cells that it is able to observe. Cells are reported using their
815 global identifiers. All 3GPP cells are identified by public land
816 mobile network (PLMN), which is formed of mobile country code (MCC)
817 and mobile network code (MNC); specific fields are added for each
818 network type. All other values are decimal integers.
820
822
823
824 46520
825 80936424
826
827
828 46506
829 10736789
830
831
832
834 Long term evolution (LTE) cells are identified by a 28-bit cell
835 identifier (eucid).
837 Figure 7: Example LTE Cellular Measurement
839
841
842
843 46520
844 200065000
845
846
847 46506
848 1638332767
849
850
851
853 Universal mobile telephony service (UMTS) cells are identified by
854 radio network controller (rnc) and cell id (cid).
856 Figure 8: Example UMTS Cellular Measurement
858
860
861
862 46506
863 1638332767
864
865
866
868 Global System for Mobile communication (GSM) cells are identified by
869 local radio network controller (rnc) and cell id (cid).
871 Figure 9: Example GSM Cellular Measurement
873
875
876
877 47231589212
878
879
880 47231589213
881
882
883
885 Code division multiple access (CDMA) cells are not identified by
886 PLMN, instead these use network id (nid), system id (sid) and base
887 station id (baseid).
889 Figure 10: Example CDMA Cellular Measurement
891 In general a cellular Device will be attached to the cellular network
892 and so the notion of a serving cell exists. Cellular network also
893 provide overlap between neighbouring sites, so a mobile Device can
894 hear more than one cell. The measurement schema supports sending
895 both the serving cell and any other cells that the mobile might be
896 able to hear. In some cases, the Device may simply be listening to
897 cell information without actually attaching to the network, mobiles
898 without a SIM are an example of this. In this case the Device may
899 simply report cells it can hear without flagging one as a serving
900 cell. An example of this is shown in Figure 11.
902
904
905
906 46520
907 200065000
908
909
910 46506
911 1638332767
912
913
914
916 Figure 11: Example Observed Cellular Measurement
918 5.4.1. Cellular Measurement Requests
920 Two elements can be used in measurement requests for cellular
921 measurements:
923 type: A label indicating the type of identifier to provide: one of
924 "gsm", "umts", "lte", or "cdma".
926 network: The network portion of the cell identifier. For 3GPP
927 networks, this is the combination of MCC and MNC; for CDMA, this
928 is the network identifier.
930 Multiple identifier types or networks can be identified by repeating
931 either element.
933 5.5. GNSS Measurements
935 GNSS use orbiting satellites to transmit signals. A Device with a
936 GNSS receiver is able to take measurements from the satellite
937 signals. The results of these measurements can be used to determine
938 time and the location of the Device.
940 Determining location and time in autonomous GNSS receivers follows
941 three steps:
943 Signal acquisition: During the signal acquisition stage, the
944 receiver searches for the repeating code that is sent by each GNSS
945 satellite. Successful operation typically requires measurement
946 data for a minimum of 5 satellites. At this stage, measurement
947 data is available to the Device.
949 Navigation message decode: Once the signal has been acquired, the
950 receiver then receives information about the configuration of the
951 satellite constellation. This information is broadcast by each
952 satellite and is modulated with the base signal at a low rate; for
953 instance, GPS sends this information at about 50 bits per second.
955 Calculation: The measurement data is combined with the data on the
956 satellite constellation to determine the location of the receiver
957 and the current time.
959 A Device that uses a GNSS receiver is able to report measurements
960 after the first stage of this process. A LIS can use the results of
961 these measurements to determine a location. In the case where there
962 are fewer results available than the optimal minimum, the LIS might
963 be able to use other sources of measurement information and combine
964 these with the available measurement data to determine a position.
966 Note: The use of different sets of GNSS _assistance data_ can
967 reduce the amount of time required for the signal acquisition
968 stage and obviate the need for the receiver to extract data on the
969 satellite constellation. Provision of assistance data is outside
970 the scope of this document.
972 Figure 12 shows an example of GNSS measurement data. The measurement
973 shown is for the GPS system and includes measurement data for three
974 satellites only.
976
978
980
981 499.9395
982 0.87595747
983 45
984
985
986 378.2657
987 0.56639479
988 52
989
990
991 -633.0309
992 0.57016835
993 48
994
995
996
998 Figure 12: Example GNSS Measurement
1000 Each "gnss" element represents a single set of GNSS measurement data,
1001 taken at a single point in time. Measurements taken at different
1002 times can be included in different "gnss" elements to enable
1003 iterative refinement of results.
1005 GNSS measurement parameters are described in more detail in the
1006 following sections.
1008 5.5.1. GNSS System and Signal
1010 The GNSS measurement structure is designed to be generic and to apply
1011 to different GNSS types. Different signals within those systems are
1012 also accounted for and can be measured separately.
1014 The GNSS type determines the time system that is used. An indication
1015 of the type of system and signal can ensure that the LIS is able to
1016 correctly use measurements.
1018 Measurements for multiple GNSS types and signals can be included by
1019 repeating the "gnss" element.
1021 This document creates an IANA registry for GNSS types. Two satellite
1022 systems are registered by this document: GPS and Galileo. Details
1023 for the registry are included in Section 9.1.
1025 5.5.2. Time
1027 Each set of GNSS measurements is taken at a specific point in time.
1028 The "time" attribute is used to indicate the time that the
1029 measurement was acquired, if the receiver knows how the time system
1030 used by the GNSS relates to UTC time.
1032 Alternative to (or in addition to) the measurement time, the
1033 "gnssTime" element MAY be included. The "gnssTime" element includes
1034 a relative time in milliseconds using the time system native to the
1035 satellite system. For the GPS satellite system, the "gnssTime"
1036 element includes the time of week in milliseconds. For the Galileo
1037 system, the "gnssTime" element includes the time of day in
1038 milliseconds.
1040 The accuracy of the time measurement provided is critical in
1041 determining the accuracy of the location information derived from
1042 GNSS measurements. The receiver SHOULD indicate an estimated time
1043 error for any time that is provided. An RMS error can be included
1044 for the "gnssTime" element, with a value in milliseconds.
1046 5.5.3. Per-Satellite Measurement Data
1048 Multiple satellites are included in each set of GNSS measurements
1049 using the "sat" element. Each satellite is identified by a number in
1050 the "num" attribute. The satellite number is consistent with the
1051 identifier used in the given GNSS.
1053 Both the GPS and Galileo systems use satellite numbers between 1 and
1054 64.
1056 The GNSS receiver measures the following parameters for each
1057 satellite:
1059 doppler: The observed Doppler shift of the satellite signal,
1060 measured in meters per second. This is converted from a value in
1061 Hertz by the receiver to allow the measurement to be used without
1062 knowledge of the carrier frequency of the satellite system. This
1063 value includes an optional RMS error attribute, also measured in
1064 meters per second.
1066 codephase: The observed code phase for the satellite signal,
1067 measured in milliseconds. This is converted from a value in chips
1068 or wavelengths. Increasing values indicate increasing
1069 pseudoranges. This value includes an optional RMS error
1070 attribute, also measured in milliseconds.
1072 cn0: The signal to noise ratio for the satellite signal, measured in
1073 decibel-Hertz (dB-Hz). The expected range is between 20 and 50
1074 dB-Hz.
1076 mp: An estimation of the amount of error that multipath signals
1077 contribute in metres. This parameter is optional.
1079 cq: An indication of the carrier quality. Two attributes are
1080 included: "continuous" may be either "true" or "false"; direct may
1081 be either "direct" or "inverted". This parameter is optional.
1083 adr: The accumulated Doppler range, measured in metres. This
1084 parameter is optional and is not necessary unless multiple sets of
1085 GNSS measurements are provided.
1087 All values are converted from measures native to the satellite system
1088 to generic measures to ensure consistency of interpretation. Unless
1089 necessary, the schema does not constrain these values.
1091 5.5.4. GNSS Measurement Requests
1093 Measurement requests can include a "gnss" element, which includes the
1094 "system" and "signal" attributes. Multiple elements can be included
1095 to indicate a requests for GNSS measurements from multiple systems or
1096 signals.
1098 5.6. DSL Measurements
1100 Digital Subscriber Line (DSL) networks rely on a range of network
1101 technology. DSL deployments regularly require cooperation between
1102 multiple organizations. These fall into two broad categories:
1103 infrastructure providers and Internet service providers (ISPs).
1104 Infrastructure providers manage the bulk of the physical
1105 infrastructure including cabling. End users obtain their service
1106 from an ISP, which manages all aspects visible to the end user
1107 including IP address allocation and operation of a LIS. See
1108 [DSL.TR025] and [DSL.TR101] for further information on DSL network
1109 deployments.
1111 Exchange of measurement information between these organizations is
1112 necessary for location information to be correctly generated. The
1113 ISP LIS needs to acquire location information from the infrastructure
1114 provider. However, the infrastructure provider has no knowledge of
1115 Device identifiers, it can only identify a stream of data that is
1116 sent to the ISP. This is resolved by passing measurement data
1117 relating to the Device to a LIS operated by the infrastructure
1118 provider.
1120 5.6.1. L2TP Measurements
1122 Layer 2 Tunneling Protocol (L2TP) is a common means of linking the
1123 infrastructure provider and the ISP. The infrastructure provider LIS
1124 requires measurement data that identifies a single L2TP tunnel, from
1125 which it can generate location information. Figure 13 shows an
1126 example L2TP measurement.
1128
1130
1131
1132 192.0.2.10
1133 192.0.2.61
1134 528
1135
1136
1137
1139 Figure 13: Example DSL L2TP Measurement
1141 5.6.2. RADIUS Measurements
1143 When authenticating network access, the infrastructure provider might
1144 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or
1145 Access Node (AN). These messages provide the ISP RADIUS server with
1146 an identifier for the DSLAM or AN, plus the slot and port that the
1147 Device is attached on. These data can be provided as a measurement,
1148 which allows the infrastructure provider LIS to generate location
1149 information.
1151 The format of the AN, slot and port identifiers are not defined in
1152 the RADIUS protocol. Slot and port together identify a circuit on
1153 the AN, analogous to the circuit identifier in [RFC3046]. These
1154 items are provided directly, as they were in the RADIUS message. An
1155 example is shown in Figure 14.
1157
1159
1160 AN-7692
1161 3
1162 06
1163
1164
1166 Figure 14: Example DSL RADIUS Measurement
1168 5.6.3. Ethernet VLAN Tag Measurements
1170 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM)
1171 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is
1172 used to identify the incoming residential circuit, while the S-TAG is
1173 used to identify the DSLAM or AN. The C-TAG and S-TAG together can
1174 be used to identify a single point of network attachment. An example
1175 is shown in Figure 15.
1177
1179
1180 613
1181 1097
1182
1183
1185 Figure 15: Example DSL VLAN Tag Measurement
1187 Alternatively, the C-TAG can be replaced by data on the slot and port
1188 that the Device is attached to. This information might be included
1189 in RADIUS requests that are proxied from the infrastructure provider
1190 to the ISP RADIUS server.
1192 5.6.4. ATM Virtual Circuit Measurements
1194 An ATM virtual circuit can be employed between the ISP and
1195 infrastructure provider. Providing the virtual port ID (VPI) and
1196 virtual circuit ID (VCI) for the virtual circuit gives the
1197 infrastructure provider LIS the ability to identify a single data
1198 stream. A sample measurement is shown in Figure 16.
1200
1202
1203 55
1204 6323
1205
1206
1208 Figure 16: Example DSL ATM Measurement
1210 6. Privacy Considerations
1212 Location-related measurement data can be as privacy sensitive as
1213 location information.
1215 Measurement data is effectively equivalent to location information if
1216 the contextual knowledge necessary to generate one from the other is
1217 readily accessible. Even where contextual knowledge is difficult to
1218 acquire, there can be no assurance that an authorized recipient of
1219 the contextual knowledge is also authorized to receive location
1220 information.
1222 In order to protect the privacy of the subject of location-related
1223 measurement data, this implies that measurement data is protected
1224 with the same degree of protection as location information.
1226 6.1. Measurement Data Privacy Model
1228 It is less desirable to distribute measurement data in the same
1229 fashion as location information. Measurement data is less useful to
1230 location recipients than location information. Therefore, a simple
1231 distribution model is desirable.
1233 In this simple model, the Device is the only entity that is able to
1234 distribute measurement data. To use an analogy from the GEOPRIV
1235 architecture, the Device - as the Location Generator (or the
1236 Measurement Data Generator) - is the sole entity that can assume the
1237 roles of Rule Maker and Location Server.
1239 No entity can redistribute measurement data. The Device directs
1240 other entities in how measurement data is used and retained.
1242 6.2. LIS Privacy Requirements
1244 A LIS MUST NOT reveal location-related measurement data or location
1245 information based on measurement data to any other entity unless
1246 directed to do so by the Device.
1248 By adding measurement data to a request for location information, the
1249 Device implicitly grants permission for the LIS to generate the
1250 requested location information using the measurement data.
1251 Permission to use this data for any other purpose is not implied.
1253 As long as measurement data is only used in serving the request that
1254 contains it, rules regarding data retention are not necessary. A LIS
1255 MUST discard location-related measurement data after servicing a
1256 request, unless the Device grants permission to use that information
1257 for other purposes.
1259 6.3. Measurement Data and Location URIs
1261 A LIS MAY use measurement data provided by the Device to serve
1262 requests to location URIs, if the Device permits it. A Device
1263 permits this by including measurement data in a request that
1264 explcitly requests a location URI. By requesting a location URI, the
1265 Device grants permission for the LIS to use the measurement data in
1266 serving requests to that URI.
1268 Note: In HELD, the "any" type is not an explicit request for a
1269 location URI, though a location URI might be provided.
1271 The usefulness of measurement data that is provided in this fashion
1272 is limited. The measurement data is only valid at the time that it
1273 was acquired by the Device. At the time that a request is made to a
1274 location URI, the Device might have moved, rendering the measurement
1275 data incorrect.
1277 A Device is able to explicitly limit the time that a LIS retains
1278 measurement data by adding an expiry time to the measurement data,
1279 see Section 4.1.2.
1281 6.4. Third-Party-Provided Measurement Data
1283 An authorized third-party request for the location of a Device (see
1284 [I-D.ietf-geopriv-held-identity-extensions]) can include location-
1285 related measurement data. This is possible where the third-party is
1286 able to make observations about the Device.
1288 A third-party that provides measurement data MUST be authorized to
1289 provide the specific measurement for the identified device. A third-
1290 party MUST either be trusted by the LIS for the purposes of providing
1291 measurement data of the provided type, or the measurement data MUST
1292 be validated (see Section 7.2.1) before being used.
1294 How a third-party authenticates its identity or gains authorization
1295 to use measurement data is not covered by this document.
1297 7. Security Considerations
1299 Use of location-related measurement data has privacy considerations
1300 that are discussed in Section 6.
1302 7.1. Threat Model
1304 The threat model for location-related measurement data concentrates
1305 on the Device providing falsified, stolen or incorrect measurement
1306 data.
1308 A Device that provides location location-related measurement data
1309 might use data to:
1311 o acquire the location of another Device, without authorization;
1313 o extract information about network topology; or
1315 o coerce the LIS into providing falsified location information based
1316 on the measurement data.
1318 Location-related measurement data describes the physical environment
1319 or network attachment of a Device. A third party adversary in the
1320 proximity of the Device might be able to alter the physical
1321 environment such that the Device provides measurement data that is
1322 controlled by the third party. This might be used to indirectly
1323 control the location information that is derived from measurement
1324 data.
1326 7.1.1. Acquiring Location Information Without Authorization
1328 Requiring authorization for location requests is an important part of
1329 privacy protections of a location protocol. A location configuration
1330 protocol usually operates under a restricted policy that allows a
1331 requester to obtain their own location. HELD identity extensions
1332 [I-D.ietf-geopriv-held-identity-extensions] allows other entities to
1333 be authorized, conditional on a Rule Maker providing sufficient
1334 authorization.
1336 The intent of these protections is to ensure that a location
1337 recipient is authorized to acquire location information. Location-
1338 related measurement data could be used by an attacker to circumvent
1339 such authorization checks if the association between measurement data
1340 and Target Device is not validated by a LIS.
1342 A LIS can be coerced into providing location information for a Device
1343 that a location recipient is not authorized to receive. A request
1344 identifies one Device (implicitly or explicitly), but measurement
1345 data is provided for another Device. If the LIS does not check that
1346 the measurement data is for the identified Device, it could
1347 incorrectly authorize the request.
1349 By using unvalidated measurement data to generate a response, the LIS
1350 provides information about a Device without appropriate
1351 authorization.
1353 The feasibility of this attack depends on the availability of
1354 information that links a Device with measurement data. In some
1355 cases, measurement data that is correlated with a target is readily
1356 available. For instance, LLDP measurements (Section 5.1) are
1357 broadcast to all nodes on the same network segment. An attacker on
1358 that network segment can easily gain measurement data that relates a
1359 Device with measurements.
1361 For some types of measurement data, it's necessary for an attacker to
1362 know the location of the target in order to determine what
1363 measurements to use. This attack is meaningless for types of
1364 measurement data that require that the attacker first know the
1365 location of the target before measurement data can be acquired or
1366 fabricated. GNSS measurements (Section 5.5) share this trait with
1367 many wireless location determination methods.
1369 7.1.2. Extracting Network Topology Data
1371 Allowing requests with measurements might be used to collect
1372 information about a network topology. This is possible if requests
1373 containing measurements are permitted.
1375 Network topology can be considered sensitive information by a network
1376 operator for commercial or security reasons. While it is impossible
1377 to completely prevent a Device from acquiring some knowledge of
1378 network topology if a location service is provided, a network
1379 operator might desire to limit how much of this information is made
1380 available.
1382 Mapping a network topology does not require that an attacker be able
1383 to associate measurement data with a particular Device. If a
1384 requester is able to try a number of measurements, it is possible to
1385 acquire information about network topology.
1387 It is not even necessary that the measurements are valid; random
1388 guesses are sufficient, provided that there is no penalty or cost
1389 associated with attempting to use the measurements.
1391 7.1.3. Lying By Proxy
1393 Location information is a function of its inputs, which includes
1394 measurement data. Thus, falsified measurement data can be used to
1395 alter the location information that is provided by a LIS.
1397 Some types of measurement data are relatively easy to falsify in a
1398 way that the resulting location information to be selected with
1399 little or no error. For instance, GNSS measurements are easy to use
1400 for this purpose because all the contextual information necessary to
1401 calculate a position using measurements is broadcast by the
1402 satellites [HARPER].
1404 An attacker that falsifies measurement data gains little if they are
1405 the only recipients of the result. The attacker knows that the
1406 location information is bad. The attacker only gains if the
1407 information can somehow be attributed to the LIS by another location
1408 recipient.
1410 A recipient might evaluate the trustworthiness of the location
1411 information based on the credibility of its source. By coercing the
1412 LIS into providing falsified location information, any credibility
1413 that the LIS might have - that the attacker does not - is gained by
1414 the attacker.
1416 A third-party that is reliant on the integrity of the location
1417 information might base an evaluation of the credibility of the
1418 information on the source of the information. If that third party is
1419 able to attribute location information to the LIS, then an attacker
1420 might gain.
1422 Location information that is provided to the Device without any means
1423 to identify the LIS as its source is not subject to this attack. The
1424 Device is identified as the source of the data when it distributes
1425 the location information to location recipients.
1427 An attacker gains if they are able to coerce the LIS into providing
1428 location information based on falsified measurement data and that
1429 information can be attributed to the LIS.
1431 Location information is attributed to the LIS either through the use
1432 of digital signatures or by having the location recipient directly
1433 interact with the LIS. A LIS that digitally signs location
1434 information becomes identifiable as the source of the data.
1435 Similarly, the LIS is identified as a source of data if a location
1436 recipient acquires information directly from a LIS using a location
1437 URI.
1439 7.1.4. Measurement Replay
1441 The value of some measured properties do not change over time for a
1442 single location. This allows for simple replay attacks, where an
1443 attacker acquires measurements that can later be used without being
1444 detected as being invalid.
1446 Measurement data is frequently an observation of an time-invariant
1447 property of the environment at the subject location. For
1448 measurements of this nature, nothing in the measurement itself is
1449 sufficient proof that the Device is present at the resulting
1450 location. Measurement data might have been previously acquired and
1451 reused.
1453 For instance, the identity of a radio transmitter, if broadcast by
1454 that transmitter, can be collected and stored. An attacker that
1455 wishes it known that they exist at a particular location, can claim
1456 to observe this transmitter at any time. Nothing inherent in the
1457 claim reveals it to be false.
1459 For properties of a network, time-invariance is often directly as a
1460 result of the practicalities of operating the network. Limiting the
1461 changes to a network ensures greater consistency of service. A
1462 largely static network also greatly simplifies the data management
1463 tasks involved with providing a location service.
1465 7.1.5. Environment Spoofing
1467 Some types of measurement data can be altered or influenced by a
1468 third party so that a Device. If it is possible for a third party to
1469 alter the measured phenomenon, then any location information that is
1470 derived from this data can be indirectly influenced.
1472 Altering the environment in this fashion might not require
1473 involvement with either Device or LIS. Measurement that is passive -
1474 where the Device observes a signal or other phenomenon without direct
1475 interaction - are most susceptible to alteration by third parties.
1477 Measurement of radio signal characteristics is especially vulnerable
1478 since an adversary need only be in the general vicinity of the Device
1479 and be able to transmit a signal. For instance, a GNSS spoofer is
1480 able to produce fake signals that claim to be transmitted by any
1481 satellite or set of satellites (see [GPS.SPOOF]).
1483 Measurements that require direct interaction increases the complexity
1484 of the attack. For measurements relating to the communication
1485 medium, a third party cannot avoid direct interaction, they need only
1486 be on the comminications path (that is, man in the middle).
1488 Even if the entity that is interacted with is authenticated, this
1489 does not provide any assurance about the integrity of measurement
1490 data. For instance, the Device might authenticate the identity of a
1491 radio transmitter through the use of cryptographic means and obtain
1492 signal strength measurements for that transmitter. Radio signal
1493 strength is trivial for an attacker to increase simply by receiving
1494 and amplifying the raw signal; it is not necessary for the attacker
1495 to be able to understand the signal content.
1497 Note: This particular "attack" is more often completely legitimate.
1498 Radio repeaters are commonplace mechanism used to increase radio
1499 coverage.
1501 Attacks that rely on altering the observed environment of a Device
1502 require countermeasures that affect the measurement process. For
1503 radio signals, countermeasures could include the use of authenticated
1504 signals, altered receiver design. In general, countermeasures are
1505 highly specific to the individual measurement process. An exhaustive
1506 discussion of these issues is left to the relevant literature for
1507 each measurement technology.
1509 A Device that provides measurement data is assumed to be responsible
1510 for applying appropriate countermeasures against this type of attack.
1512 For a Device that is the ultimate recipient of location information
1513 derived from measurement data, a LIS might choose to provide location
1514 information without any validation. The responsibility for ensuring
1515 the veracity of the measurement data lies with the Device.
1517 Measurement data that is susceptible to this sort of influence MUST
1518 be treated as though it were produced by an untrusted Device for
1519 those cases where a location recipient might attribute the location
1520 information to the LIS. Such measurement data MUST be subjected to
1521 the same validation as for other types of attacks that rely on
1522 measurement falsification.
1524 Note: Altered measurement data might be provided by a Device that
1525 has no knowledge of the alteration. Thus, an otherwise trusted
1526 Device might still be an unreliable source of measurement data.
1528 7.2. Mitigation
1530 The following measures can be applied to limit or prevent attacks.
1531 The effectiveness of each depends on the type of measurement data and
1532 how that measurement data is acquired.
1534 Two general approaches are identified for dealing with untrusted
1535 measurement data:
1537 1. Require independent validation of measurement data or the
1538 location information that is produced.
1540 2. Identify the types of sources that provided the measurement data
1541 that location information was derived from.
1543 This section goes into more detail on the different forms of
1544 validation in Section 7.2.1, Section 7.2.2, and Section 7.2.3. The
1545 impact of attributing location information to sources is discussed in
1546 more detail in Section 7.2.4.
1548 7.2.1. Measurement Validation
1550 Detecting that measurement data has been falsified is difficult in
1551 the absence of integrity mechanisms.
1553 Independent confirmation of the veracity of measurement data ensures
1554 that the measurement is accurate and that it applies to the correct
1555 Device. By gathering the same measurement data from a trusted and
1556 independent source, the LIS is able to check that the measurement
1557 data is correct.
1559 Measurement information might contain no inherent indication that it
1560 is falsified. On the contrary, it can be difficult to obtain
1561 information that would provide any degree of assurance that the
1562 measurement device is physically at any particular location.
1563 Measurements that are difficult to verify require other forms of
1564 assurance before they can be used.
1566 7.2.1.1. Effectiveness
1568 Measurement validation MUST be used if measurement data for a
1569 particular Device can be easily acquired by unauthorized location
1570 recipients, as described in Section 7.1.1. This prevents
1571 unauthorized access to location information using measurement data.
1573 Validation of measurement data can be significantly more effective
1574 than independent acquisition of the same. For instance, a Device in
1575 a large Ethernet network could provide a measurement indicating its
1576 point of attachment using LLDP measurements. For a LIS, acquiring
1577 the same measurement data might require a request to all switches in
1578 that network. With the measurement data, validation can target the
1579 identified switch with a specific query.
1581 Validation is effective in identifying falsified measurement data
1582 (Section 7.1.3), including attacks involving replay of measurement
1583 data (Section 7.1.4). Validation also limits the amount of network
1584 topology information (Section 7.1.2) made available to Devices to
1585 that portion of the network topology that they are directly attached.
1587 Measurement validation has no effect if the underlying effect is
1588 being spoofed (Section 7.1.5).
1590 7.2.1.2. Limitations (Unique Observer)
1592 A Device is often in a unique position to make a measurement. It
1593 alone occupies the point in space-time that the location
1594 determination process seeks to determine. The Device becomes a
1595 unique observer for a particular property.
1597 The ability of the Device to become a unique observer makes the
1598 Device invaluable to the location determination process. As a unique
1599 observer, it also makes the claims of a Device difficult to validate
1600 and easily to spoof.
1602 As long as no other entity is capable of making the same
1603 measurements, there is also no other entity that can independently
1604 check that the measurements are correct and applicable to the Device.
1605 A LIS might be unable to validate all or part of the measurement data
1606 it receives from a unique observer. For instance, a signal strength
1607 measurement of the signal from a radio tower cannot be validated
1608 directly.
1610 Some portion of the measurement data might still be independently
1611 verified, even if all information cannot. In the previous example,
1612 the radio tower might be able to provide verification that the Device
1613 is present if it is able to observe a radio signal sent by the
1614 Device.
1616 If measurement data can only be partially validated, the extent to
1617 which it can be validated determines the effectiveness of validation
1618 against these attacks.
1620 The advantage of having the Device as a unique observer is that it
1621 makes it difficult for an attacker to acquire measurements without
1622 the assistance of the Device. Attempts to use measurements to gain
1623 unauthorized access to measurement data (Section 7.1.1) are largely
1624 ineffectual against a unique observer.
1626 7.2.2. Location Validation
1628 Location information that is derived from location-related
1629 measurement data can also be verified against trusted location
1630 information. Rather than validating inputs to the location
1631 determination process, suspect locations are identified at the output
1632 of the process.
1634 Trusted location information is acquired using sources of measurement
1635 data that are trusted. Untrusted location information is acquired
1636 using measurement data provided from untrusted sources, which might
1637 include the Device. These two locations are compared. If the
1638 untrusted location agrees with the trusted location, the untrusted
1639 location information is used.
1641 Algorithms for the comparison of location information are not
1642 included in this document. However, a simple comparison for
1643 agreement might require that the untrusted location be entirely
1644 contained within the uncertainty region of the trusted location.
1646 There is little point in using a less accurate, less trusted
1647 location. Untrusted location information that has worse accuracy
1648 than trusted information can be immediately discarded. There are
1649 multiple factors that affect accuracy, uncertainty and currency being
1650 the most important. How location information is compared for
1651 accuracy is not defined in this document.
1653 7.2.2.1. Effectiveness
1655 Location validation limits the extent to which falsified - or
1656 erroneous - measurement data can cause an incorrect location to be
1657 reported.
1659 Location validation can be more efficient than validation of inputs,
1660 particularly for a unique observer (Section 7.2.1.2).
1662 Validating location ensures that the Device is at or near the
1663 resulting location. Location validation can be used to limit or
1664 prevent all of the attacks identified in this document.
1666 7.2.2.2. Limitations
1668 The trusted location that is used for validation is always less
1669 accurate than the location that is being checked. The amount by
1670 which the untrusted location is more accurate, is the same amount
1671 that an attacker can exploit.
1673 For example, a trusted location might indicate a five kilometer
1674 radius uncertainty region. An untrusted location that describes a
1675 100 meter uncertainty within the larger region might be accepted as
1676 more accurate. An attacker might still falsify measurement data to
1677 select any location within the larger uncertainty region. While the
1678 100 meter uncertainty that is reported seems more accurate, a
1679 falsified location could be anywhere in the five kilometer region.
1681 Where measurement data might have been falsified, the actual
1682 uncertainty is effectively much higher. Local policy might allow
1683 differing degrees of trust to location information derived from
1684 untrusted measurement data. This might not be a boolean operation
1685 with only two possible outcomes: untrusted location information might
1686 be used entirely or not at all, or it could be combined with trusted
1687 location information with the degree to which each contributes based
1688 on a value set in local policy.
1690 7.2.3. Supporting Observations
1692 Replay attacks using previously acquired measurement data are
1693 particularly hard to detect without independent validation. Rather
1694 than validate the measurement data directly, supplementary data might
1695 be used to validate measurements or the location information derived
1696 from those measurements.
1698 These supporting observations could be used to convey information
1699 that provides additional assurance that the Device was acquired at a
1700 specific time and place. In effect, the Device is requested to
1701 provide proof of its presence at the resulting location.
1703 For instance, a Device that measures attributes of a radio signal
1704 could also be asked to provide a sample of the measured radio signal.
1705 If the LIS is able to observe the same signal, the two observations
1706 could be compared. Providing that the signal cannot be predicted in
1707 advance by the Device, this could be used to support the claim that
1708 the Device is able to receive the signal. Thus, the Device is likely
1709 to be within the range that the signal is transmitted. A LIS could
1710 use this to attribute a higher level of trust in the associated
1711 measurement data or resulting location.
1713 7.2.3.1. Effectiveness
1715 The use of supporting observations is limited by the ability of the
1716 LIS to acquire and validate these observations. The advantage of
1717 selecting observations independent of measurement data is that
1718 observations can be selected based on how readily available the data
1719 is for both LIS and Device. The amount and quality of the data can
1720 be selected based on the degree of assurance that is desired.
1722 Use of supporting observations is similar to both measurement
1723 validation and location validation. All three methods rely on
1724 independent validation of one or more properties. Applicability of
1725 each method is similar.
1727 Use of supporting observations can be used to limit or prevent all of
1728 the attacks identified in this document.
1730 7.2.3.2. Limitations
1732 The effectiveness of the validation method depends on the quality of
1733 the supporting observation: how hard it is to obtain at a different
1734 time or place, how difficult it is to guess and what other costs
1735 might be involved in acquiring this data.
1737 In the example of an observed radio signal, requesting a sample of
1738 the signal only provides an assurance that the Device is able to
1739 receive the signal transmitted by the measured radio transmitter.
1740 This only provides some assurance that the Device is within range of
1741 the transmitter.
1743 As with location validation, a Device might still be able to provide
1744 falsified measurements that could alter the value of the location
1745 information as long as the result is within this region.
1747 Requesting additional supporting observations can reduce the size of
1748 the region over which location information can be altered by an
1749 attacker, or increase trust in the result, but each additional has a
1750 cost. Supporting observations contribute little or nothing toward
1751 the primary goal of determining the location of the Device. Any
1752 costs in acquiring supporting observations are balanced against the
1753 degree of integrity desired of the resulting location information.
1755 7.2.4. Attribution
1757 Lying by proxy (Section 7.1.3) relies on the location recipient being
1758 able to attribute location information to a LIS. The effectiveness
1759 of this attack is negated if location information is explicitly
1760 attributed to a particular source.
1762 This requires an extension to the location object that explicitly
1763 identifies the source (or sources) of each item of location
1764 information.
1766 Rather than relying on a process that seeks to ensure that location
1767 information is accurate, this approach instead provides a location
1768 recipient with the information necessary to reach their own
1769 conclusion about the trustworthiness of the location information.
1771 Including an authenticated identity for all sources of measurement
1772 data is presents a number of technical and operational challenges.
1773 It is possible that the LIS has a transient relationship with a
1774 Device. A Device is not expected to share authentication information
1775 with a LIS. There is no assurance that Device identification is
1776 usable by a potential location recipient. Privacy concerns might
1777 also prevent the sharing identification information, even if it were
1778 available and usable.
1780 Identifying the type of measurement source allows a location
1781 recipient to make a decision about the trustworthiness of location
1782 information without depending on having authenticated identity
1783 information for each source. An element for this purpose is defined
1784 in Section 4.4.
1786 When including location information that is based on measurement data
1787 from sources that might be untrusted, a LIS SHOULD include
1788 alternative location information that is derived from trusted sources
1789 of measurement data. Each item of location information can then be
1790 labelled with the source of that data.
1792 A location recipient that is able to identify a specific source of
1793 measurement data (whether it be LIS or Device) can use this
1794 information to attribute location information to either or both
1795 entity. The location recipient is then better able to make decisions
1796 about trustworthiness based on the source of the data.
1798 A location recipient that does not understand the "source" element is
1799 unable to make this distinction. When constructing a PIDF-LO
1800 document, trusted location information MUST be placed in the PIDF-LO
1801 so that it is given higher priority to any untrusted location
1802 information according to Rule #8 of [RFC5491].
1804 Attribution of information does nothing to address attacks that alter
1805 the observed parameters that are used in location determination
1806 (Section 7.1.5).
1808 7.2.5. Stateful Correlation of Location Requests
1810 Stateful examination of requests can be used to prevent a Device from
1811 attempting to map network topology using requests for location
1812 information (Section 7.1.2).
1814 Simply limiting the rate of requests from a single Device reduces the
1815 amount of data that a Device can acquire about network topology.
1817 8. Measurement Schemas
1819 The schema are broken up into their respective functions. There is a
1820 base container schema into which all measurements are placed, plus
1821 definitions for a measurement request (Section 8.1). A PIDF-LO
1822 extension is defined in a separate schema (Section 8.2). There is a
1823 basic types schema, that contains various base type definitions for
1824 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and
1825 MAC addresses (Section 8.3). Then each of the specific measurement
1826 types is defined in its own schema.
1828 8.1. Measurement Container Schema
1830
1831
1839
1840
1842
1843
1844
1846 This schema defines a framework for location measurements.
1847
1848
1850
1852
1853
1854
1855
1856
1857
1859
1860
1861
1862
1863
1864
1865
1866
1867
1869
1871
1872
1873
1874
1875
1877
1879
1880
1881
1882
1884
1885
1886
1887
1888
1889
1891
1892
1893
1894
1895
1896
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1913 Measurement Container Schema
1915 8.2. Measurement Source Schema
1917
1918
1925
1926
1928
1929
1930
1932 This schema defines an extension to PIDF-LO that indicates the
1933 type of source that produced the measurement data used in
1934 generating the associated location information.
1935
1936
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1952 Measurement Source PIDF-LO Extension Schema
1954 8.3. Base Type Schema
1956 Note that the pattern rules in the following schema wrap due to
1957 length constraints. None of the patterns contain whitespace.
1959
1960
1967
1968
1970
1971
1972
1974 This schema defines a set of base type elements.
1975
1976
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2018
2019
2020
2022
2023
2024
2025
2026 An IP version 6 address, based on RFC 4291.
2027
2028
2029
2030
2031
2032
2033
2034
2035
2037
2039
2041
2043
2045
2047
2048
2049
2050
2058
2059
2060
2061
2063
2064
2065
2066
2070
2071
2073
2074
2075
2076
2078
2079
2081
2083 Base Type Schema
2085 8.4. LLDP Measurement Schema
2087
2088
2096
2097
2099
2100
2101
2103 This schema defines a set of LLDP location measurements.
2104
2105
2106
2108
2109
2110
2111
2112
2113
2114
2115
2117
2118
2119
2120
2121
2123
2124
2125
2126
2128
2129
2130
2132
2133
2134
2135
2136
2137
2139
2141 LLDP measurement schema
2143 8.5. DHCP Measurement Schema
2145
2146
2154
2155
2157
2158
2159
2161 This schema defines a set of DHCP location measurements.
2162
2163
2165
2167
2168
2169
2170
2171
2172
2173
2174
2176
2178
2180
2182
2183
2184
2185
2186
2188
2189
2190
2191
2193
2194
2195
2197
2199 DHCP measurement schema
2201 8.6. WiFi Measurement Schema
2202
2203
2212
2213
2215 802.11 location measurements
2216
2217
2218
2220 This schema defines a basic set of 802.11 location measurements.
2221
2222
2224
2225
2227
2229
2230
2231
2232
2233
2235
2237
2238
2239
2240
2241
2243
2244
2245
2246
2247
2248
2251
2253
2255
2257
2259
2261
2263
2265
2267
2269
2270
2272
2273
2274
2275
2277
2278
2279
2280
2282
2283
2284
2286
2288
2289
2290
2291
2292
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2313
2314
2315
2316
2317
2319
2320
2321
2322
2323
2325
2326
2328
2330
2332
2333
2334
2335
2337
2338
2339
2340
2341
2342
2343
2345
2346
2347
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2364
2366 WiFi measurement schema
2368 8.7. Cellular Measurement Schema
2370
2371
2378
2379
2381
2382
2383
2385 This schema defines a set of cellular location measurements.
2386
2387
2389
2391
2392
2393
2394
2395
2396
2397
2398
2399
2401
2402
2403
2404
2405
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2426
2427
2428
2429
2430
2431
2433
2434
2436
2437
2438
2439
2441
2442
2443
2444
2445
2447
2448
2449
2450
2451
2453
2454
2455
2456
2457
2459
2461
2462
2463
2464
2465
2466
2467
2468
2469
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2486
2488 Cellular measurement schema
2490 8.8. GNSS Measurement Schema
2491
2492
2500
2501
2503
2504
2505
2507 This schema defines a set of GNSS location measurements
2508
2509
2511
2513
2514
2515
2516
2517
2518
2519
2521
2522
2523
2524
2525
2527
2529
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2547
2549
2550
2551
2553
2554
2555
2557
2558
2559
2560
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2575 GNSS measurement Schema
2577 8.9. DSL Measurement Schema
2579
2580
2588
2589
2591 DSL measurement definitions
2592
2593
2594
2596 This schema defines a basic set of DSL location measurements.
2597
2598
2600
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2635
2636
2637
2638
2639
2640
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2659
2661 DSL measurement schema
2663 9. IANA Considerations
2665 This section creates a registry for GNSS types (Section 5.5) and
2666 registers the namespaces and schema defined in Section 8.
2668 9.1. IANA Registry for GNSS Types
2670 This document establishes a new IANA registry for Global Navigation
2671 Satellite System (GNSS) types. The registry includes tokens for the
2672 GNSS type and for each of the signals within that type. Referring to
2673 [RFC5226], this registry operates under "Specification Required"
2674 rules. The IESG will appoint an Expert Reviewer who will advise IANA
2675 promptly on each request for a new or updated GNSS type.
2677 Each entry in the registry requires the following information:
2679 GNSS name: the name and a brief description of the GNSS
2681 Brief description: the name and a brief description of the GNSS
2683 GNSS token: a token that can be used to identify the GNSS
2685 Signals: a set of tokens that represent each of the signals that the
2686 system provides
2688 Documentation reference: a reference to one or more stable, public
2689 specifications that outline usage of the GNSS, including (but not
2690 limited to) signal specifications and time systems
2692 The registry initially includes two registrations:
2694 GNSS name: Global Positioning System (GPS)
2696 Brief description: a system of satellites that use spread-spectrum
2697 transmission, operated by the US military for commercial and
2698 military applications
2700 GNSS token: gps
2702 Signals: L1, L2, L1C, L2C, L5
2704 Documentation reference: Navstar GPS Space Segment/Navigation User
2705 Interface [GPS.ICD]
2707 GNSS name: Galileo
2709 Brief description: a system of satellites that operate in the same
2710 spectrum as GPS, operated by the European Union for commercial
2711 applications
2713 GNSS Token: galileo
2715 Signals: L1, E5A, E5B, E5A+B, E6
2717 Documentation Reference: Galileo Open Service Signal In Space
2718 Interface Control Document (SIS ICD) [Galileo.ICD]
2720 9.2. URN Sub-Namespace Registration for
2721 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2723 This section registers a new XML namespace,
2724 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines
2725 in [RFC3688].
2727 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2729 Registrant Contact: IETF, GEOPRIV working group,
2730 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2732 XML:
2734 BEGIN
2735
2736
2738
2739
2740 Measurement Source for PIDF-LO
2741
2742
2743 Namespace for Location Measurement Source
2744 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2745 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2746 with the RFC number for this specification.]]
2747 See RFCXXXX.
2748
2749
2750 END
2752 9.3. URN Sub-Namespace Registration for
2753 urn:ietf:params:xml:ns:geopriv:lm
2755 This section registers a new XML namespace,
2756 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in
2757 [RFC3688].
2759 URI: urn:ietf:params:xml:ns:geopriv:lm
2761 Registrant Contact: IETF, GEOPRIV working group,
2762 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2764 XML:
2766 BEGIN
2767
2768
2770
2771
2772 Measurement Container
2773
2774
2775 Namespace for Location Measurement Container
2776 urn:ietf:params:xml:ns:geopriv:lm
2777 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2778 with the RFC number for this specification.]]
2779 See RFCXXXX.
2780
2781
2782 END
2784 9.4. URN Sub-Namespace Registration for
2785 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2787 This section registers a new XML namespace,
2788 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines
2789 in [RFC3688].
2791 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes
2793 Registrant Contact: IETF, GEOPRIV working group,
2794 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2796 XML:
2798 BEGIN
2799
2800
2802
2803
2804 Base Device Types
2805
2806
2807 Namespace for Base Types
2808 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2809 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2810 with the RFC number for this specification.]]
2811 See RFCXXXX.
2812
2813
2815 END
2817 9.5. URN Sub-Namespace Registration for
2818 urn:ietf:params:xml:ns:geopriv:lm:lldp
2820 This section registers a new XML namespace,
2821 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in
2822 [RFC3688].
2824 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
2826 Registrant Contact: IETF, GEOPRIV working group,
2827 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2829 XML:
2831 BEGIN
2832
2833
2835
2836
2837 LLDP Measurement Set
2838
2839
2840 Namespace for LLDP Measurement Set
2841 urn:ietf:params:xml:ns:geopriv:lm:lldp
2842 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2843 with the RFC number for this specification.]]
2844 See RFCXXXX.
2845
2846
2847 END
2849 9.6. URN Sub-Namespace Registration for
2850 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2852 This section registers a new XML namespace,
2853 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in
2854 [RFC3688].
2856 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
2858 Registrant Contact: IETF, GEOPRIV working group,
2859 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2861 XML:
2863 BEGIN
2864
2865
2867
2868
2869 DHCP Measurement Set
2870
2871
2872 Namespace for DHCP Measurement Set
2873 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2874 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2875 with the RFC number for this specification.]]
2876 See RFCXXXX.
2877
2878
2879 END
2881 9.7. URN Sub-Namespace Registration for
2882 urn:ietf:params:xml:ns:geopriv:lm:wifi
2884 This section registers a new XML namespace,
2885 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
2886 [RFC3688].
2888 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi
2890 Registrant Contact: IETF, GEOPRIV working group,
2891 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2893 XML:
2895 BEGIN
2896
2897
2899
2900
2901 WiFi Measurement Set
2902
2903
2904 Namespace for WiFi Measurement Set
2905 urn:ietf:params:xml:ns:geopriv:lm:wifi
2906 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2907 with the RFC number for this specification.]]
2908 See RFCXXXX.
2909
2910
2912 END
2914 9.8. URN Sub-Namespace Registration for
2915 urn:ietf:params:xml:ns:geopriv:lm:cell
2917 This section registers a new XML namespace,
2918 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in
2919 [RFC3688].
2921 URI: urn:ietf:params:xml:ns:geopriv:lm:cell
2923 Registrant Contact: IETF, GEOPRIV working group,
2924 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2926 XML:
2928 BEGIN
2929
2930
2932
2933
2934 Cellular Measurement Set
2935
2936
2937 Namespace for Cellular Measurement Set
2938 urn:ietf:params:xml:ns:geopriv:lm:cell
2939 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2940 with the RFC number for this specification.]]
2941 See RFCXXXX.
2942
2943
2944 END
2946 9.9. URN Sub-Namespace Registration for
2947 urn:ietf:params:xml:ns:geopriv:lm:gnss
2949 This section registers a new XML namespace,
2950 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in
2951 [RFC3688].
2953 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
2955 Registrant Contact: IETF, GEOPRIV working group,
2956 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2958 XML:
2960 BEGIN
2961
2962
2964
2965
2966 GNSS Measurement Set
2967
2968
2969 Namespace for GNSS Measurement Set
2970 urn:ietf:params:xml:ns:geopriv:lm:gnss
2971 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2972 with the RFC number for this specification.]]
2973 See RFCXXXX.
2974
2975
2976 END
2978 9.10. URN Sub-Namespace Registration for
2979 urn:ietf:params:xml:ns:geopriv:lm:dsl
2981 This section registers a new XML namespace,
2982 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in
2983 [RFC3688].
2985 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl
2987 Registrant Contact: IETF, GEOPRIV working group,
2988 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2990 XML:
2992 BEGIN
2993
2994
2996
2997
2998 DSL Measurement Set
2999
3000
3001 Namespace for DSL Measurement Set
3002 urn:ietf:params:xml:ns:geopriv:lm:dsl
3003 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3004 with the RFC number for this specification.]]
3005 See RFCXXXX.
3006
3007
3009 END
3011 9.11. XML Schema Registration for Measurement Source Schema
3013 This section registers an XML schema as per the guidelines in
3014 [RFC3688].
3016 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
3018 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3019 Martin Thomson (martin.thomson@andrew.com).
3021 Schema: The XML for this schema can be found in Section 8.2 of this
3022 document.
3024 9.12. XML Schema Registration for Measurement Container Schema
3026 This section registers an XML schema as per the guidelines in
3027 [RFC3688].
3029 URI: urn:ietf:params:xml:schema:lm
3031 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3032 Martin Thomson (martin.thomson@andrew.com).
3034 Schema: The XML for this schema can be found in Section 8.1 of this
3035 document.
3037 9.13. XML Schema Registration for Base Types Schema
3039 This section registers an XML schema as per the guidelines in
3040 [RFC3688].
3042 URI: urn:ietf:params:xml:schema:lm:basetypes
3044 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3045 Martin Thomson (martin.thomson@andrew.com).
3047 Schema: The XML for this schema can be found in Section 8.3 of this
3048 document.
3050 9.14. XML Schema Registration for LLDP Schema
3052 This section registers an XML schema as per the guidelines in
3053 [RFC3688].
3055 URI: urn:ietf:params:xml:schema:lm:lldp
3057 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3058 Martin Thomson (martin.thomson@andrew.com).
3060 Schema: The XML for this schema can be found in Section 8.4 of this
3061 document.
3063 9.15. XML Schema Registration for DHCP Schema
3065 This section registers an XML schema as per the guidelines in
3066 [RFC3688].
3068 URI: urn:ietf:params:xml:schema:lm:dhcp
3070 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3071 Martin Thomson (martin.thomson@andrew.com).
3073 Schema: The XML for this schema can be found in Section 8.5 of this
3074 document.
3076 9.16. XML Schema Registration for WiFi Schema
3078 This section registers an XML schema as per the guidelines in
3079 [RFC3688].
3081 URI: urn:ietf:params:xml:schema:lm:wifi
3083 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3084 Martin Thomson (martin.thomson@andrew.com).
3086 Schema: The XML for this schema can be found in Section 8.6 of this
3087 document.
3089 9.17. XML Schema Registration for Cellular Schema
3091 This section registers an XML schema as per the guidelines in
3092 [RFC3688].
3094 URI: urn:ietf:params:xml:schema:lm:cellular
3096 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3097 Martin Thomson (martin.thomson@andrew.com).
3099 Schema: The XML for this schema can be found in Section 8.7 of this
3100 document.
3102 9.18. XML Schema Registration for GNSS Schema
3104 This section registers an XML schema as per the guidelines in
3105 [RFC3688].
3107 URI: urn:ietf:params:xml:schema:lm:gnss
3109 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3110 Martin Thomson (martin.thomson@andrew.com).
3112 Schema: The XML for this schema can be found in Section 8.8 of this
3113 document.
3115 9.19. XML Schema Registration for DSL Schema
3117 This section registers an XML schema as per the guidelines in
3118 [RFC3688].
3120 URI: urn:ietf:params:xml:schema:lm:dsl
3122 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3123 Martin Thomson (martin.thomson@andrew.com).
3125 Schema: The XML for this schema can be found in Section 8.9 of this
3126 document.
3128 10. Acknowledgements
3130 Thanks go to Simon Cox for his comments relating to terminology that
3131 have helped ensure that this document is aligns with ongoing work in
3132 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his
3133 review and comments on the GNSS sections of this document. Thanks to
3134 Noor-E-Gagan Singh, Gabor Bajko and Russell Priebe for their
3135 significant input to and suggestions for improving the 802.11
3136 measurements. Thanks to Cullen Jennings for feedback and
3137 suggestions. Bernard Aboba provided review and feedback on a range
3138 of measurement data definitions. Mary Barnes provided a review and
3139 corrections. David Waitzman and John Bressler both noted
3140 shortcomings with 802.11 measurements.
3142 11. References
3144 11.1. Normative References
3146 [DSL.TR025]
3147 Wang, R., "Core Network Architecture Recommendations for
3148 Access to Legacy Data Networks over ADSL", September 1999.
3150 [DSL.TR101]
3151 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
3152 Aggregation", April 2006.
3154 [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface",
3155 ICD GPS-200, Apr 2000.
3157 [Galileo.ICD]
3158 GJU, "Galileo Open Service Signal In Space Interface
3159 Control Document (SIS ICD)", May 2006.
3161 [I-D.ietf-geopriv-http-location-delivery]
3162 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
3163 "HTTP Enabled Location Delivery (HELD)",
3164 draft-ietf-geopriv-http-location-delivery-16 (work in
3165 progress), August 2009.
3167 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
3168 October 1969.
3170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3171 Requirement Levels", BCP 14, RFC 2119, March 1997.
3173 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3174 10646", STD 63, RFC 3629, November 2003.
3176 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
3177 Format", RFC 4119, December 2005.
3179 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3180 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3181 May 2008.
3183 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
3184 Presence Information Data Format Location Object (PIDF-LO)
3185 Usage Clarification, Considerations, and Recommendations",
3186 RFC 5491, March 2009.
3188 11.2. Informative References
3190 [ANSI/TIA-1057]
3191 ANSI/TIA, "Link Layer Discovery Protocol for Media
3192 Endpoint Devices", TIA 1057, April 2006.
3194 [GPS.SPOOF]
3195 Scott, L., "Anti-Spoofing and Authenticated Signal
3196 Architectures for Civil Navigation Signals", ION-
3197 GNSS Portland, Oregon, 2003.
3199 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side
3200 spoofing and detection for Assisted-GPS", Proceedings of
3201 International Global Navigation Satellite Systems Society
3202 (IGNSS) Symposium 2009 16, December 2009,
3203 .
3205 [I-D.ietf-geopriv-held-identity-extensions]
3206 Winterbottom, J., Thomson, M., Tschofenig, H., and R.
3207 Barnes, "Use of Device Identity in HTTP-Enabled Location
3208 Delivery (HELD)",
3209 draft-ietf-geopriv-held-identity-extensions-05 (work in
3210 progress), October 2010.
3212 [I-D.thomson-geopriv-uncertainty]
3213 Thomson, M. and J. Winterbottom, "Representation of
3214 Uncertainty and Confidence in PIDF-LO",
3215 draft-thomson-geopriv-uncertainty-05 (work in progress),
3216 May 2010.
3218 [IANA.enterprise]
3219 IANA, "Private Enterprise Numbers",
3220 .
3222 [IEEE.80211]
3223 IEEE, "Wireless LAN Medium Access Control (MAC) and
3224 Physical Layer (PHY) specifications - IEEE 802.11 Wireless
3225 Network Management", IEEE Std 802.11-2007, June 2007.
3227 [IEEE.80211V]
3228 IEEE, "Wireless LAN Medium Access Control (MAC) and
3229 Physical Layer (PHY) specifications - IEEE 802.11 Wireless
3230 Network Management (Draft)", P802.11v D12.0, June 2010.
3232 [IEEE.8021AB]
3233 IEEE, "IEEE Standard for Local and Metropolitan area
3234 networks, Station and Media Access Control Connectivity
3235 Discovery", 802.1AB, June 2005.
3237 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
3238 "Remote Authentication Dial In User Service (RADIUS)",
3239 RFC 2865, June 2000.
3241 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
3242 RFC 3046, January 2001.
3244 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
3245 January 2004.
3247 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
3248 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
3250 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
3251 Suboption for the Dynamic Host Configuration Protocol
3252 (DHCP) Relay Agent Option", RFC 3993, March 2005.
3254 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
3255 Architecture", RFC 4291, February 2006.
3257 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3258 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
3259 June 2006.
3261 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3262 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
3263 August 2006.
3265 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
3266 Mechanism", RFC 5808, May 2010.
3268 Authors' Addresses
3270 Martin Thomson
3271 Andrew
3272 Andrew Building (39)
3273 University of Wollongong
3274 Northfields Avenue
3275 Wollongong, NSW 2522
3276 AU
3278 Phone: +61 2 4221 2915
3279 Email: martin.thomson@andrew.com
3280 URI: http://www.andrew.com/
3281 James Winterbottom
3282 Andrew
3283 Andrew Building (39)
3284 University of Wollongong
3285 Northfields Avenue
3286 NSW 2522
3287 AU
3289 Phone: +61 2 4221 2938
3290 Email: james.winterbottom@andrew.com
3291 URI: http://www.andrew.com/