idnits 2.17.1
draft-ietf-geopriv-held-measurements-05.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 (July 6, 2012) is 4313 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 2078, but not defined
== Missing Reference: '0-4' is mentioned on line 2078, but not defined
== Missing Reference: '0-9' is mentioned on line 2078, but not defined
== Missing Reference: '0-1' is mentioned on line 2078, but not defined
== Unused Reference: 'I-D.thomson-geopriv-uncertainty' is defined on line
3232, but no explicit reference was found in the text
== Unused Reference: 'RFC5808' is defined on line 3285, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
== Outdated reference: A later version (-08) exists of
draft-thomson-geopriv-uncertainty-07
Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV M. Thomson
3 Internet-Draft Microsoft
4 Intended status: Standards Track J. Winterbottom
5 Expires: January 7, 2013 Commscope
6 July 6, 2012
8 Using Device-provided Location-Related Measurements in Location
9 Configuration Protocols
10 draft-ietf-geopriv-held-measurements-05
12 Abstract
14 A method is described by which a Device is able to provide location-
15 related measurement data to a LIS within a request for location
16 information. Location-related measurement information are
17 observations concerning properties related to the position of a
18 Device, which could be data about network attachment or about the
19 physical environment. When a LIS generates location information for
20 a Device, information from the Device can improve the accuracy of the
21 location estimate. A basic set of location-related measurements are
22 defined, including common modes of network attachment as well as
23 assisted Global Navigation Satellite System (GNSS) parameters.
25 Status of this Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on January 7, 2013.
42 Copyright Notice
44 Copyright (c) 2012 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 This document may contain material from IETF Documents or IETF
58 Contributions published or made publicly available before November
59 10, 2008. The person(s) controlling the copyright in some of this
60 material may not have granted the IETF Trust the right to allow
61 modifications of such material outside the IETF Standards Process.
62 Without obtaining an adequate license from the person(s) controlling
63 the copyright in such materials, this document may not be modified
64 outside the IETF Standards Process, and derivative works of it may
65 not be created outside the IETF Standards Process, except to format
66 it for publication as an RFC or to translate it into languages other
67 than English.
69 Table of Contents
71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
72 2. Conventions used in this document . . . . . . . . . . . . . . 6
73 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 7
74 4. Location-Related Measurement Data Types . . . . . . . . . . . 8
75 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 9
76 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 9
77 4.1.2. Expiry Time on Location-Related Measurement Data . . . 9
78 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 10
79 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . . 10
80 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 11
81 4.4. Identifying Location Provenance . . . . . . . . . . . . . 12
82 5. Location-Related Measurement Data Types . . . . . . . . . . . 15
83 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 15
84 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 16
85 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 16
86 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 20
87 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 20
88 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 23
89 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 23
90 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . . 25
91 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 26
92 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . . 26
93 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 27
94 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 27
95 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 28
96 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 28
97 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 29
98 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 29
99 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30
100 6.1. Measurement Data Privacy Model . . . . . . . . . . . . . . 30
101 6.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . . 30
102 6.3. Measurement Data and Location URIs . . . . . . . . . . . . 31
103 6.4. Third-Party-Provided Measurement Data . . . . . . . . . . 31
104 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
105 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 31
106 7.1.1. Acquiring Location Information Without
107 Authorization . . . . . . . . . . . . . . . . . . . . 32
108 7.1.2. Extracting Network Topology Data . . . . . . . . . . . 33
109 7.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . . 33
110 7.1.4. Measurement Replay . . . . . . . . . . . . . . . . . . 34
111 7.1.5. Environment Spoofing . . . . . . . . . . . . . . . . . 35
112 7.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 36
113 7.2.1. Measurement Validation . . . . . . . . . . . . . . . . 37
114 7.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 37
115 7.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 38
116 7.2.2. Location Validation . . . . . . . . . . . . . . . . . 38
117 7.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 39
118 7.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 39
119 7.2.3. Supporting Observations . . . . . . . . . . . . . . . 40
120 7.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 40
121 7.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 40
122 7.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 41
123 7.2.5. Stateful Correlation of Location Requests . . . . . . 42
124 8. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 42
125 8.1. Measurement Container Schema . . . . . . . . . . . . . . . 43
126 8.2. Measurement Source Schema . . . . . . . . . . . . . . . . 45
127 8.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 45
128 8.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 48
129 8.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 49
130 8.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 51
131 8.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 54
132 8.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 57
133 8.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 58
134 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
135 9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 60
136 9.2. URN Sub-Namespace Registration for
137 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 61
138 9.3. URN Sub-Namespace Registration for
139 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 62
140 9.4. URN Sub-Namespace Registration for
141 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 63
142 9.5. URN Sub-Namespace Registration for
143 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 64
144 9.6. URN Sub-Namespace Registration for
145 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 64
146 9.7. URN Sub-Namespace Registration for
147 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 65
148 9.8. URN Sub-Namespace Registration for
149 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 66
150 9.9. URN Sub-Namespace Registration for
151 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 66
152 9.10. URN Sub-Namespace Registration for
153 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 67
154 9.11. XML Schema Registration for Measurement Source Schema . . 68
155 9.12. XML Schema Registration for Measurement Container
156 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 68
157 9.13. XML Schema Registration for Base Types Schema . . . . . . 68
158 9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 68
159 9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 69
160 9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 69
161 9.17. XML Schema Registration for Cellular Schema . . . . . . . 69
162 9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 70
163 9.19. XML Schema Registration for DSL Schema . . . . . . . . . . 70
164 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 70
165 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
166 11.1. Normative References . . . . . . . . . . . . . . . . . . . 71
167 11.2. Informative References . . . . . . . . . . . . . . . . . . 72
168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
170 1. Introduction
172 A location configuration protocol (LCP) provides a means for a Device
173 to request information about its physical location from an access
174 network. A location information server (LIS) is the server that
175 provides location information; information that is available due to
176 the knowledge about the network and physical environment that is
177 available to the LIS.
179 As a part of the access network, the LIS is able to acquire
180 measurement results from network Devices within the network that are
181 related to Device location. The LIS also has access to information
182 about the network topology that can be used to turn measurement data
183 into location information. However, this information can be enhanced
184 with information acquired from the Device itself.
186 A Device is able to make observations about its network attachment,
187 or its physical environment. The location-related measurement data
188 might be unavailable to the LIS; alternatively, the LIS might be able
189 to acquire the data, but at a higher cost in time or otherwise.
190 Providing measurement data gives the LIS more options in determining
191 location, which could improve the quality of the service provided by
192 the LIS. Improvements in accuracy are one potential gain, but
193 improved response times and lower error rates are also possible.
195 This document describes a means for a Device to report location-
196 related measurement data to the LIS. Examples based on the HELD
197 [RFC5985] location configuration 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 [RFC5985].
204 This document also uses the following definitions:
206 Location Measurement: An observation about the physical properties
207 of a particular Device's network access. The result of a location
208 measurement--"location-related measurement data", or simply
209 "measurement data" given sufficient context--can be used to
210 determine the location of a Device. Location-related measurement
211 data does not identify a Device; measurement data can change with
212 time if the location of the Device also changes.
214 Location-related measurement data does not necessarily contain
215 location information directly, but it can be used in combination
216 with contextual knowledge of the network, or algorithms to derive
217 location information. Examples of location-related measurement
218 data are: radio signal strength or timing measurements, Ethernet
219 switch and port identifiers.
221 Location-related measurement data can be considered sighting
222 information, based on the definition in [RFC3693].
224 Location Estimate: The result of location determination, a location
225 estimate is an approximation of where the Device is located.
226 Location estimates are subject to uncertainty, which arise from
227 errors in measurement results.
229 GNSS: Global Navigation Satellite System. A satellite-based system
230 that provides positioning and time information. For example, the
231 US Global Positioning System (GPS) or the European Galileo system.
233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
235 document are to be interpreted as described in [RFC2119].
237 3. Location-Related Measurements in LCPs
239 This document defines a standard container for the conveyance of
240 location-related measurement parameters in location configuration
241 protocols. This is an XML container that identifies parameters by
242 type and allows the Device to provide the results of any measurement
243 it is able to perform. A set of measurement schemas are also defined
244 that can be carried in the generic container.
246 The simplest example of measurement data conveyance is illustrated by
247 the example message in Figure 1. This shows a HELD location request
248 message with an Ethernet switch and port measurement taken using LLDP
249 [IEEE.8021AB].
251
252 civic
253
255
256 0a01003c
257 c2
258
259
260
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 [RFC5985].
320 4.1.1. Time of Measurement
322 The "time" attribute records the time that the measurement or
323 observation was made. This time can be different to the time that
324 the measurement information was reported. Time information can be
325 used to populate a timestamp on the location result, or to determine
326 if the measurement information is used.
328 The "time" attribute is optional to avoid forcing an arbitrary choice
329 of timestamp for relatively static types of measurement (for
330 instance, the DSL measurements in Section 5.6) and for legacy Devices
331 that don't record time information (such as the Home Location
332 Register/Home Subscriber Server for cellular). However, time SHOULD
333 be provided whenever possible.
335 The "time" attribute is attached to the root "measurement" element.
336 If it is necessary to provide multiple sets of measurement data with
337 different times, multiple "measurement" elements SHOULD be provided.
339 4.1.2. Expiry Time on Location-Related Measurement Data
341 A Device is able to indicate an expiry time in the location
342 measurement using the "expires" attribute. Nominally, this attribute
343 indicates how long information is expected to be valid for, but it
344 can also indicate a time limit on the retention and use of the
345 measurement data. A Device can use this attribute to prevent the LIS
346 from retaining measurement data or limit the time that a LIS retains
347 this information.
349 Note: Movement of a Device might result in the measurement data
350 being invalidated before the expiry time.
352 The LIS MUST NOT keep location-related measurement data beyond the
353 time indicated in the "expires" attribute.
355 4.2. RMS Error and Number of Samples
357 Often a measurement is taken more than once over a period of time.
358 Reporting the average of a number of measurement results mitigates
359 the effects of random errors that occur in the measurement process.
361 Reporting each measurement individually can be the most effective
362 method of reporting multiple measurements. This is achieved by
363 providing multiple "measurement" elements for different times.
365 The alternative is to aggregate multiple measurements and report a
366 mean value across the set of measurements. Additional information
367 about the distribution of the results can be useful in determining
368 location uncertainty.
370 Two optional attributes are provided for certain measurement values:
372 rmsError: The root-mean-squared (RMS) error of the set of
373 measurement values used in calculating the result. RMS error is
374 expressed in the same units as the measurement, unless otherwise
375 stated. If an accurate value for RMS error is not known, this
376 value can be used to indicate an upper bound or estimate for the
377 RMS error.
379 samples: The number of samples that were taken in determining the
380 measurement value. If omitted, this value can be assumed to be a
381 very large value, so that the RMS error is an indication of the
382 standard deviation of the sample set.
384 For some measurement techniques, measurement error is largely
385 dependent on the measurement technique employed. In these cases,
386 measurement error is largely a product of the measurement technique
387 and not the specific circumstances, so RMS error does not need to be
388 actively measured. A fixed value MAY be provided for RMS error where
389 appropriate.
391 The "rmsError" and "samples" elements are added as attributes of
392 specific measurement data types.
394 4.2.1. Time RMS Error
396 Measurement of time can be significant in certain circumstances. The
397 GNSS measurements included in this document are one such case where a
398 small error in time can result in a large error in location. Factors
399 such as clock drift and errors in time sychronization can result in
400 small, but significant, time errors. Including an indication of the
401 quality of the time can be helpful.
403 An optional "timeError" attribute can be added to the "measurement"
404 element to indicate the RMS error in time. "timeError" indicates an
405 upper bound on the time RMS error in seconds.
407 The "timeError" attribute does not apply where multiple samples of a
408 measurement is taken over time. If multiple samples are taken, each
409 SHOULD be included in a different "measurement" element.
411 4.3. Measurement Request
413 A measurement request is used by a protocol peer to describe a set of
414 measurement data that it desires. A "measurementRequest" element is
415 defined that can be included in a protocol exchange.
417 For instance, a LIS can use a measurement request in HELD responses.
418 If the LIS is unable to provide location information, but it believes
419 that a particular measurement type would enable it to provide a
420 location, it can include a measurement request in an error response.
422 The "measurement" element of the measurement request identifies the
423 type of measurement that is requested. The "type" attribute of this
424 element indicates the type of measurement, as identified by an XML
425 qualified name. An optional "samples" attribute indicates how many
426 samples of the identified measurement are requested.
428 The "measurement" element can be repeated to request multiple (or
429 alternative) measurement types.
431 Additional XML content might be defined for a particular measurement
432 type that is used to further refine a request. These elements either
433 constrain what is requested or specify optional components of the
434 measurement data that are needed. These are defined along with the
435 specific measurement type.
437 In the HELD protocol, the inclusion of a measurement request in a
438 error response with a code of "locationUnknown" indicates that the
439 LIS believes that providing the indicated measurements would increase
440 the likelihood of a subsequent request being successful.
442 The following example shows a HELD error response that indicates that
443 WiFi measurement data would be useful if a later request were made.
444 Additional elements indicate that received signal strength for an
445 802.11n access point is requested.
447
449 Insufficient measurement data
450
453
454 n
455 wifi:rcpi
456
457
458
460 Figure 3: HELD Error Requesting Measurement Data
462 A measurement request that is included in other HELD messages has
463 undefined semantics and can be safely ignored. Other specifications
464 might define semantics for measurement requests under other
465 conditions.
467 4.4. Identifying Location Provenance
469 An extension is made to the PIDF-LO [RFC4119] that allows a location
470 recipient to identify the source (or sources) of location information
471 and the measurement data that was used to determine that location
472 information.
474 The "source" element is added to the "geopriv" element of the
475 PIDF-LO. This element does not identify specific entities. Instead,
476 it identifies the type of source.
478 The following types of measurement source are identified:
480 lis: Location information is based on measurement data that the LIS
481 or sources that it trusts have acquired. This label might be used
482 if measurement data provided by the Device has been completely
483 validated by the LIS.
485 device: Location information is based on measurement data that the
486 Device has provided to the LIS.
488 other: Location information is based on measurement data that a
489 third party has provided. This might be an authorized third party
490 that uses identity parameters
491 [I-D.ietf-geopriv-held-identity-extensions] or any other entity.
493 No assertion is made about the veracity of the measurement data from
494 sources other than the LIS. A combination of tags MAY be included to
495 indicate that measurement data from both sources was used.
497 For example, the first tuple of the following PIDF-LO indicates that
498 measurement data from a LIS and a device was combined to produce the
499 result, the second tuple was produced by the LIS alone.
501
507
508
509
510
511
512 7.34324 134.47162
513
514 850.24
515
516
517
518
519 OTDOA
520 lis device
521
522
523
524
525
526
527
528
529 7.34379 134.46484
530
531 9000
532
533
534
535
536 Cell
537 lis
538
539
540
541
543 5. Location-Related Measurement Data Types
545 This document defines location-related measurement data types for a
546 range of common network types.
548 All included measurement data definitions allow for arbitrary
549 extension in the corresponding schema. As new parameters that are
550 applicable to location determination are added, these can be added as
551 new XML elements in a unique namespace. Though many of the
552 underlying protocols support extension, creation of specific XML-
553 based extensions to the measurement format is favored over
554 accomodating protocol-specific extensions in generic containers.
556 5.1. LLDP Measurements
558 Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent
559 between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet,
560 WiFi, 802.16). These messages all contain identification information
561 for the sending node, which can be used to determine location
562 information. A Device that receives LLDP messages can report this
563 information as a location-related measurement to the LIS, which is
564 then able to use the measurement data in determining the location of
565 the Device.
567 Note: The LLDP extensions defined in LLDP Media Endpoint Discovery
568 (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location
569 information directly from an LLDP endpoint. Where this
570 information is available, it might be unnecessary to use any other
571 form of location configuration.
573 Values are provided as hexadecimal sequences. The Device MUST report
574 the values directly as they were provided by the adjacent node.
575 Attempting to adjust or translate the type of identifier is likely to
576 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, using the forms defined in [RFC3986].
627 The enterprise number is specified as a decimal integer. All other
628 information is included verbatim from the DHCP request in hexadecimal
629 format.
631 5.3. 802.11 WLAN Measurements
633 In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to
634 provide information about the access point (AP) that it is attached
635 to, or other WiFi points it is able to see. This is provided using
636 the "wifi" element, as shown in Figure 6, which shows a single
637 complete measurement for a single access point.
639
641
642 Intel(r)PRO/Wireless 2200BG
643
644 AB-CD-EF-AB-CD-EF
645 example
646 5
647
648
649 -34.4 150.8
650
651
652 a
653 5
654 2
655 2
656 2.56e-9
657
658 23
659 5
660 -59
661 23
662
663
664 10
665 9
666 -98.5
667 7.5
668
669
670
671
673 Figure 6: 802.11 WLAN Measurement Example
675 A wifi element is made up of one or more access points, and an
676 optional "nicType" element. Each access point is described using the
677 "ap" element, which is comprised of the following fields:
679 bssid: The basic service set identifier. In an Infrastructure BSS
680 network, the bssid is the 48 bit MAC address of the access point.
682 The "verified" attribute of this element describes whether the
683 device has verified the MAC address or it authenticated the access
684 point or the network operating the access point (for example, a
685 captive portal accessed through the access point has been
686 authenticated). This attributes defaults to a value of "false"
687 when omitted.
689 ssid: The service set identifier (SSID) for the wireless network
690 served by the access point.
692 The SSID is a 32-octet identifier that is commonly represented as
693 a ASCII [RFC0020] or UTF-8 [RFC3629] encoded string. To represent
694 octets that cannot be directly included in an XML element,
695 escaping is used. Sequences of octets that do not represent a
696 valid UTF-8 encoding can be escaped using a backslash ('\')
697 followed by two case-insensitive hexadecimal digits representing
698 the value of a single octet.
700 The canonical or value-space form of an SSID is a sequence of up
701 to 32 octets that is produced from the concatenation of UTF-8
702 encoded sequences of unescaped characters and octets derived from
703 escaped components.
705 channel: The channel number (frequency) that the access point
706 operates on.
708 location: The location of the access point, as reported by the
709 access point. This element contains any valid location, using the
710 rules for a "location-info" element, as described in [RFC5491].
712 type: The network type for the network access. This element
713 includes the alphabetic suffix of the 802.11 specification that
714 introducted the radio interface, or PHY; e.g. "a", "b", "g", or
715 "n".
717 band: The frequency band for the radio, in gigahertz (GHz). 802.11
718 [IEEE.80211] specifies PHY layers that use 2.4, 3.7 and 5
719 gigahertz frequency bands.
721 regclass: The regulatory domain and class. The "country" attribute
722 optionally includes the applicable two character country
723 identifier (dot11CountryString), which can be followed by an 'O',
724 'I' or 'X'. The element text content includes the value of the
725 regulatory class: an 8-bit integer in decimal form.
727 antenna: The antenna identifier for the antenna that the access
728 point is using to transmit the measured signals.
730 flightTime: Flight time is the difference between the time of
731 departure (TOD) of signal from a transmitting station and time of
732 arrival (TOA) of signal at a receiving station, as defined in
733 [IEEE.80211V]. Measurement of this value requires that stations
734 synchronize their clocks. This value can be measured by access
735 point or Device; because the flight time is assumed to be the same
736 in either direction - aside from measurement errors - only a
737 single element is provided. This element includes optional
738 "rmsError" and "samples" attributes. RMS error might be derived
739 from the reported RMS error in TOD and TOA.
741 apSignal: Measurement information for the signal transmitted by the
742 access point, as observed by the Device. Some of these values are
743 derived from 802.11v [IEEE.80211V] messages exchanged between
744 Device and access point. The contents of this element include:
746 transmit: The transmit power reported by the access point, in
747 dBm.
749 gain: The gain of the access point antenna reported by the access
750 point, in dB.
752 rcpi: The received channel power indicator for the access point
753 signal, as measured by the Device. This value SHOULD be in
754 units of dBm (with RMS error in dB). If power is measured in a
755 different fashion, the "dBm" attribute MUST be set to "false".
756 Signal strength reporting on current hardware uses a range of
757 different mechanisms; therefore, the value of the "nicType"
758 element SHOULD be included if the units are not known to be in
759 dBm and the value reported by the hardware should be included
760 without modification. This element includes optional
761 "rmsError" and "samples" attributes.
763 rsni: The received signal to noise indicator in dB. This element
764 includes optional "rmsError" and "samples" attributes.
766 deviceSignal: Measurement information for the signal transmitted by
767 the device, as reported by the access point. This element
768 contains the same child elements as the "ap" element, with the
769 access point and Device roles reversed.
771 All elements are optional except for "bssid".
773 The "nicType" element is used to specify the make and model of the
774 wireless network interface in the Device. Different 802.11 chipsets
775 report measurements in different ways, so knowing the network
776 interface type aids the LIS in determining how to use the provided
777 measurement data. The content of this field is unconstrained and no
778 mechanisms are specified to ensure uniqueness.
780 5.3.1. Wifi Measurement Requests
782 Two elements are defined for requesting WiFi measurements in a
783 measurement request:
785 type: The "type" element identifies the desired type (or types that
786 are requested.
788 parameter: The "parameter" element identifies an optional
789 measurements are requested for each measured access point. An
790 element is identified by its qualified name. The optional
791 "context" parameter can be used to specify if an element is
792 included as a child of the "ap" or "device" elements; omission
793 indicates that it applies to both.
795 Multiple types or parameters can be requested by repeating either
796 element.
798 5.4. Cellular Measurements
800 Cellular Devices are common throughout the world and base station
801 identifiers can provide a good source of coarse location information.
802 This information can be provided to a LIS run by the cellar operator,
803 or may be provided to an alternative LIS operator that has access to
804 one of several global cell-id to location mapping databases.
806 A number of advanced location determination methods have been
807 developed for cellular networks. For these methods a range of
808 measurement parameters can be collected by the network, Device, or
809 both in cooperation. This document includes a basic identifier for
810 the wireless transmitter only; future efforts might define additional
811 parameters that enable more accurate methods of location
812 determination.
814 The cellular measurement set allows a Device to report to a LIS any
815 LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10)
816 cells that it is able to observe. Cells are reported using their
817 global identifiers. All 3GPP cells are identified by public land
818 mobile network (PLMN), which is formed of mobile country code (MCC)
819 and mobile network code (MNC); specific fields are added for each
820 network type.
822 Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003].
823 Bit-level formats for CDMA cell identifiers are described in
824 [TIA-2000.5]; decimal representations are used.
826 MCC and MNC are provided as digit sequences; a leading zero in an MCC
827 or MNC is significant. All other values are decimal integers.
829
831
832
833 4652080936424
834
835
836 4650610736789
837
838
839
841 Long term evolution (LTE) cells are identified by a 28-bit cell
842 identifier (eucid).
844 Figure 7: Example LTE Cellular Measurement
846
848
849
850 46520
851 200065000
852
853
854 46506
855 1638332767
856
857
858
860 Universal mobile telephony service (UMTS) cells are identified by 12-
861 or 16-bit radio network controller (rnc) id and a 16-bit cell id
862 (cid).
864 Figure 8: Example UMTS Cellular Measurement
866
868
869
870 46506
871 1638332767
872
873
874
876 Global System for Mobile communication (GSM) cells are identified by
877 a 16-bit location area code (lac) and 16-bit cell id (cid).
879 Figure 9: Example GSM Cellular Measurement
881
883
884
885 15892472312
886
887
888 15892472313
889
890
891
893 Code division multiple access (CDMA) cells are not identified by
894 PLMN, instead these usea 15-bit system id (sid), a 16-bit network id
895 (nid) and a 16-bit base station id (baseid).
897 Figure 10: Example CDMA Cellular Measurement
899 In general a cellular Device will be attached to the cellular network
900 and so the notion of a serving cell exists. Cellular network also
901 provide overlap between neighbouring sites, so a mobile Device can
902 hear more than one cell. The measurement schema supports sending
903 both the serving cell and any other cells that the mobile might be
904 able to hear. In some cases, the Device may simply be listening to
905 cell information without actually attaching to the network, mobiles
906 without a SIM are an example of this. In this case the Device may
907 simply report cells it can hear without flagging one as a serving
908 cell. An example of this is shown in Figure 11.
910
912
913
914 46520
915 200065000
916
917
918 46506
919 1638332767
920
921
922
924 Figure 11: Example Observed Cellular Measurement
926 5.4.1. Cellular Measurement Requests
928 Two elements can be used in measurement requests for cellular
929 measurements:
931 type: A label indicating the type of identifier to provide: one of
932 "gsm", "umts", "lte", or "cdma".
934 network: The network portion of the cell identifier. For 3GPP
935 networks, this is the combination of MCC and MNC; for CDMA, this
936 is the network identifier.
938 Multiple identifier types or networks can be identified by repeating
939 either element.
941 5.5. GNSS Measurements
943 GNSS use orbiting satellites to transmit signals. A Device with a
944 GNSS receiver is able to take measurements from the satellite
945 signals. The results of these measurements can be used to determine
946 time and the location of the Device.
948 Determining location and time in autonomous GNSS receivers follows
949 three steps:
951 Signal acquisition: During the signal acquisition stage, the
952 receiver searches for the repeating code that is sent by each GNSS
953 satellite. Successful operation typically requires measurement
954 data for a minimum of 5 satellites. At this stage, measurement
955 data is available to the Device.
957 Navigation message decode: Once the signal has been acquired, the
958 receiver then receives information about the configuration of the
959 satellite constellation. This information is broadcast by each
960 satellite and is modulated with the base signal at a low rate; for
961 instance, GPS sends this information at about 50 bits per second.
963 Calculation: The measurement data is combined with the data on the
964 satellite constellation to determine the location of the receiver
965 and the current time.
967 A Device that uses a GNSS receiver is able to report measurements
968 after the first stage of this process. A LIS can use the results of
969 these measurements to determine a location. In the case where there
970 are fewer results available than the optimal minimum, the LIS might
971 be able to use other sources of measurement information and combine
972 these with the available measurement data to determine a position.
974 Note: The use of different sets of GNSS _assistance data_ can
975 reduce the amount of time required for the signal acquisition
976 stage and obviate the need for the receiver to extract data on the
977 satellite constellation. Provision of assistance data is outside
978 the scope of this document.
980 Figure 12 shows an example of GNSS measurement data. The measurement
981 shown is for the GPS system and includes measurement data for three
982 satellites only.
984
986
988
989 499.9395
990 0.87595747
991 45
992
993
994 378.2657
995 0.56639479
996 52
997
998
999 -633.0309
1000 0.57016835
1001 48
1002
1003
1004
1006 Figure 12: Example GNSS Measurement
1008 Each "gnss" element represents a single set of GNSS measurement data,
1009 taken at a single point in time. Measurements taken at different
1010 times can be included in different "gnss" elements to enable
1011 iterative refinement of results.
1013 GNSS measurement parameters are described in more detail in the
1014 following sections.
1016 5.5.1. GNSS System and Signal
1018 The GNSS measurement structure is designed to be generic and to apply
1019 to different GNSS types. Different signals within those systems are
1020 also accounted for and can be measured separately.
1022 The GNSS type determines the time system that is used. An indication
1023 of the type of system and signal can ensure that the LIS is able to
1024 correctly use measurements.
1026 Measurements for multiple GNSS types and signals can be included by
1027 repeating the "gnss" element.
1029 This document creates an IANA registry for GNSS types. Two satellite
1030 systems are registered by this document: GPS [GPS.ICD] and Galileo
1031 [Galileo.ICD]. Details for the registry are included in Section 9.1.
1033 5.5.2. Time
1035 Each set of GNSS measurements is taken at a specific point in time.
1036 The "time" attribute is used to indicate the time that the
1037 measurement was acquired, if the receiver knows how the time system
1038 used by the GNSS relates to UTC time.
1040 Alternative to (or in addition to) the measurement time, the
1041 "gnssTime" element MAY be included. The "gnssTime" element includes
1042 a relative time in milliseconds using the time system native to the
1043 satellite system. For the GPS satellite system, the "gnssTime"
1044 element includes the time of week in milliseconds. For the Galileo
1045 system, the "gnssTime" element includes the time of day in
1046 milliseconds.
1048 The accuracy of the time measurement provided is critical in
1049 determining the accuracy of the location information derived from
1050 GNSS measurements. The receiver SHOULD indicate an estimated time
1051 error for any time that is provided. An RMS error can be included
1052 for the "gnssTime" element, with a value in milliseconds.
1054 5.5.3. Per-Satellite Measurement Data
1056 Multiple satellites are included in each set of GNSS measurements
1057 using the "sat" element. Each satellite is identified by a number in
1058 the "num" attribute. The satellite number is consistent with the
1059 identifier used in the given GNSS.
1061 Both the GPS and Galileo systems use satellite numbers between 1 and
1062 64.
1064 The GNSS receiver measures the following parameters for each
1065 satellite:
1067 doppler: The observed Doppler shift of the satellite signal,
1068 measured in meters per second. This is converted from a value in
1069 Hertz by the receiver to allow the measurement to be used without
1070 knowledge of the carrier frequency of the satellite system. This
1071 value includes an optional RMS error attribute, also measured in
1072 meters per second.
1074 codephase: The observed code phase for the satellite signal,
1075 measured in milliseconds. This is converted the system-specific
1076 value of chips or wavelengths into a system independent value.
1077 Larger values indicate larger distances from satellite to
1078 receiver. This value includes an optional RMS error attribute,
1079 also measured in milliseconds.
1081 cn0: The signal to noise ratio for the satellite signal, measured in
1082 decibel-Hertz (dB-Hz). The expected range is between 20 and 50
1083 dB-Hz.
1085 mp: An estimation of the amount of error that multipath signals
1086 contribute in metres. This parameter is optional.
1088 cq: An indication of the carrier quality. Two attributes are
1089 included: "continuous" may be either "true" or "false"; direct may
1090 be either "direct" or "inverted". This parameter is optional.
1092 adr: The accumulated Doppler range, measured in metres. This
1093 parameter is optional and is not useful unless multiple sets of
1094 GNSS measurements are provided or differential positioning is
1095 being performed.
1097 All values are converted from measures native to the satellite system
1098 to generic measures to ensure consistency of interpretation. Unless
1099 necessary, the schema does not constrain these values.
1101 5.5.4. GNSS Measurement Requests
1103 Measurement requests can include a "gnss" element, which includes the
1104 "system" and "signal" attributes. Multiple elements can be included
1105 to indicate a requests for GNSS measurements from multiple systems or
1106 signals.
1108 5.6. DSL Measurements
1110 Digital Subscriber Line (DSL) networks rely on a range of network
1111 technologies. DSL deployments regularly require cooperation between
1112 multiple organizations. These fall into two broad categories:
1113 infrastructure providers and Internet service providers (ISPs). For
1114 the same end user, an infrastructure and Internet service can be
1115 provided by different entities. Infrastructure providers manage the
1116 bulk of the physical infrastructure including cabling. End users
1117 obtain their service from an ISP, which manages all aspects visible
1118 to the end user including IP address allocation and operation of a
1119 LIS. See [DSL.TR025] and [DSL.TR101] for further information on DSL
1120 network deployments and the parameters that are available.
1122 Exchange of measurement information between these organizations is
1123 necessary for location information to be correctly generated. The
1124 ISP LIS needs to acquire location information from the infrastructure
1125 provider. However, since the infrastructure provider could have no
1126 knowledge of Device identifiers, it can only identify a stream of
1127 data that is sent to the ISP. This is resolved by passing
1128 measurement data relating to the Device to a LIS operated by the
1129 infrastructure provider.
1131 5.6.1. L2TP Measurements
1133 Layer 2 Tunneling Protocol (L2TP) is a common means of linking the
1134 infrastructure provider and the ISP. The infrastructure provider LIS
1135 requires measurement data that identifies a single L2TP tunnel, from
1136 which it can generate location information. Figure 13 shows an
1137 example L2TP measurement.
1139
1141
1142
1143 192.0.2.10
1144 192.0.2.61
1145 528
1146
1147
1148
1150 Figure 13: Example DSL L2TP Measurement
1152 5.6.2. RADIUS Measurements
1154 When authenticating network access, the infrastructure provider might
1155 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or
1156 Access Node (AN). These messages provide the ISP RADIUS server with
1157 an identifier for the DSLAM or AN, plus the slot and port that the
1158 Device is attached on. These data can be provided as a measurement,
1159 which allows the infrastructure provider LIS to generate location
1160 information.
1162 The format of the AN, slot and port identifiers are not defined in
1163 the RADIUS protocol. Slot and port together identify a circuit on
1164 the AN, analogous to the circuit identifier in [RFC3046]. These
1165 items are provided directly, as they were in the RADIUS message. An
1166 example is shown in Figure 14.
1168
1170
1171 AN-7692
1172 3
1173 06
1174
1175
1176 Figure 14: Example DSL RADIUS Measurement
1178 5.6.3. Ethernet VLAN Tag Measurements
1180 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM)
1181 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is
1182 used to identify the incoming residential circuit, while the S-TAG is
1183 used to identify the DSLAM or AN. The C-TAG and S-TAG together can
1184 be used to identify a single point of network attachment. An example
1185 is shown in Figure 15.
1187
1189
1190 613
1191 1097
1192
1193
1195 Figure 15: Example DSL VLAN Tag Measurement
1197 Alternatively, the C-TAG can be replaced by data on the slot and port
1198 that the Device is attached to. This information might be included
1199 in RADIUS requests that are proxied from the infrastructure provider
1200 to the ISP RADIUS server.
1202 5.6.4. ATM Virtual Circuit Measurements
1204 An ATM virtual circuit can be employed between the ISP and
1205 infrastructure provider. Providing the virtual port ID (VPI) and
1206 virtual circuit ID (VCI) for the virtual circuit gives the
1207 infrastructure provider LIS the ability to identify a single data
1208 stream. A sample measurement is shown in Figure 16.
1210
1212
1213 55
1214 6323
1215
1216
1218 Figure 16: Example DSL ATM Measurement
1220 6. Privacy Considerations
1222 Location-related measurement data can be as privacy sensitive as
1223 location information.
1225 Measurement data is effectively equivalent to location information if
1226 the contextual knowledge necessary to generate one from the other is
1227 readily accessible. Even where contextual knowledge is difficult to
1228 acquire, there can be no assurance that an authorized recipient of
1229 the contextual knowledge is also authorized to receive location
1230 information.
1232 In order to protect the privacy of the subject of location-related
1233 measurement data, this implies that measurement data is protected
1234 with the same degree of protection as location information.
1236 6.1. Measurement Data Privacy Model
1238 It is less desirable to distribute measurement data in the same
1239 fashion as location information. Measurement data is less useful to
1240 location recipients than location information. Therefore, a simple
1241 distribution model is desirable.
1243 In this simple model, the Device is the only entity that is able to
1244 distribute measurement data. To use an analogy from the GEOPRIV
1245 architecture, the Device - as the Location Generator (or the
1246 Measurement Data Generator) - is the sole entity that can assume the
1247 roles of Rule Maker and Location Server.
1249 No entity is permitted to redistribute measurement data. The Device
1250 directs other entities in how measurement data is used and retained.
1252 6.2. LIS Privacy Requirements
1254 A LIS MUST NOT reveal location-related measurement data or location
1255 information based on measurement data to any other entity unless
1256 directed to do so by the Device.
1258 By adding measurement data to a request for location information, the
1259 Device implicitly grants permission for the LIS to generate the
1260 requested location information using the measurement data.
1261 Permission to use this data for any other purpose is not implied.
1263 As long as measurement data is only used in serving the request that
1264 contains it, rules regarding data retention are not necessary. A LIS
1265 MUST discard location-related measurement data after servicing a
1266 request, unless the Device grants permission to use that information
1267 for other purposes.
1269 6.3. Measurement Data and Location URIs
1271 A LIS MAY use measurement data provided by the Device to serve
1272 requests to location URIs, if the Device permits it. A Device
1273 permits this by including measurement data in a request that
1274 explcitly requests a location URI. By requesting a location URI, the
1275 Device grants permission for the LIS to use the measurement data in
1276 serving requests to that URI.
1278 Note: In HELD, the "any" type is not an explicit request for a
1279 location URI, though a location URI might be provided.
1281 The usefulness of measurement data that is provided in this fashion
1282 is limited. The measurement data is only valid at the time that it
1283 was acquired by the Device. At the time that a request is made to a
1284 location URI, the Device might have moved, rendering the measurement
1285 data incorrect.
1287 A Device is able to explicitly limit the time that a LIS retains
1288 measurement data by adding an expiry time to the measurement data,
1289 see Section 4.1.2.
1291 6.4. Third-Party-Provided Measurement Data
1293 An authorized third-party request for the location of a Device (see
1294 [I-D.ietf-geopriv-held-identity-extensions]) can include location-
1295 related measurement data. This is possible where the third-party is
1296 able to make observations about the Device.
1298 A third-party that provides measurement data MUST be authorized to
1299 provide the specific measurement for the identified device. A third-
1300 party MUST either be trusted by the LIS for the purposes of providing
1301 measurement data of the provided type, or the measurement data MUST
1302 be validated (see Section 7.2.1) before being used.
1304 How a third-party authenticates its identity or gains authorization
1305 to use measurement data is not covered by this document.
1307 7. Security Considerations
1309 Use of location-related measurement data has privacy considerations
1310 that are discussed in Section 6.
1312 7.1. Threat Model
1314 The threat model for location-related measurement data concentrates
1315 on the Device providing falsified, stolen or incorrect measurement
1316 data.
1318 A Device that provides location location-related measurement data
1319 might use data to:
1321 o acquire the location of another Device, without authorization;
1323 o extract information about network topology; or
1325 o coerce the LIS into providing falsified location information based
1326 on the measurement data.
1328 Location-related measurement data describes the physical environment
1329 or network attachment of a Device. A third party adversary in the
1330 proximity of the Device might be able to alter the physical
1331 environment such that the Device provides measurement data that is
1332 controlled by the third party. This might be used to indirectly
1333 control the location information that is derived from measurement
1334 data.
1336 7.1.1. Acquiring Location Information Without Authorization
1338 Requiring authorization for location requests is an important part of
1339 privacy protections of a location protocol. A location configuration
1340 protocol usually operates under a restricted policy that allows a
1341 requester to obtain their own location. HELD identity extensions
1342 [I-D.ietf-geopriv-held-identity-extensions] allows other entities to
1343 be authorized, conditional on a Rule Maker providing sufficient
1344 authorization.
1346 The intent of these protections is to ensure that a location
1347 recipient is authorized to acquire location information. Location-
1348 related measurement data could be used by an attacker to circumvent
1349 such authorization checks if the association between measurement data
1350 and Target Device is not validated by a LIS.
1352 A LIS can be coerced into providing location information for a Device
1353 that a location recipient is not authorized to receive. A request
1354 identifies one Device (implicitly or explicitly), but measurement
1355 data is provided for another Device. If the LIS does not check that
1356 the measurement data is for the identified Device, it could
1357 incorrectly authorize the request.
1359 By using unvalidated measurement data to generate a response, the LIS
1360 provides information about a Device without appropriate
1361 authorization.
1363 The feasibility of this attack depends on the availability of
1364 information that links a Device with measurement data. In some
1365 cases, measurement data that is correlated with a target is readily
1366 available. For instance, LLDP measurements (Section 5.1) are
1367 broadcast to all nodes on the same network segment. An attacker on
1368 that network segment can easily gain measurement data that relates a
1369 Device with measurements.
1371 For some types of measurement data, it's necessary for an attacker to
1372 know the location of the target in order to determine what
1373 measurements to use. This attack is meaningless for types of
1374 measurement data that require that the attacker first know the
1375 location of the target before measurement data can be acquired or
1376 fabricated. GNSS measurements (Section 5.5) share this trait with
1377 many wireless location determination methods.
1379 7.1.2. Extracting Network Topology Data
1381 Allowing requests with measurements might be used to collect
1382 information about a network topology. This is possible if requests
1383 containing measurements are permitted.
1385 Network topology can be considered sensitive information by a network
1386 operator for commercial or security reasons. While it is impossible
1387 to completely prevent a Device from acquiring some knowledge of
1388 network topology if a location service is provided, a network
1389 operator might desire to limit how much of this information is made
1390 available.
1392 Mapping a network topology does not require that an attacker be able
1393 to associate measurement data with a particular Device. If a
1394 requester is able to try a number of measurements, it is possible to
1395 acquire information about network topology.
1397 It is not even necessary that the measurements are valid; random
1398 guesses are sufficient, provided that there is no penalty or cost
1399 associated with attempting to use the measurements.
1401 7.1.3. Lying By Proxy
1403 Location information is a function of its inputs, which includes
1404 measurement data. Thus, falsified measurement data can be used to
1405 alter the location information that is provided by a LIS.
1407 Some types of measurement data are relatively easy to falsify in a
1408 way that the resulting location information to be selected with
1409 little or no error. For instance, GNSS measurements are easy to use
1410 for this purpose because all the contextual information necessary to
1411 calculate a position using measurements is broadcast by the
1412 satellites [HARPER].
1414 An attacker that falsifies measurement data gains little if they are
1415 the only recipients of the result. The attacker knows that the
1416 location information is bad. The attacker only gains if the
1417 information can somehow be attributed to the LIS by another location
1418 recipient.
1420 A recipient might evaluate the trustworthiness of the location
1421 information based on the credibility of its source. By coercing the
1422 LIS into providing falsified location information, any credibility
1423 that the LIS might have - that the attacker does not - is gained by
1424 the attacker.
1426 A third-party that is reliant on the integrity of the location
1427 information might base an evaluation of the credibility of the
1428 information on the source of the information. If that third party is
1429 able to attribute location information to the LIS, then an attacker
1430 might gain.
1432 Location information that is provided to the Device without any means
1433 to identify the LIS as its source is not subject to this attack. The
1434 Device is identified as the source of the data when it distributes
1435 the location information to location recipients.
1437 An attacker gains if they are able to coerce the LIS into providing
1438 location information based on falsified measurement data and that
1439 information can be attributed to the LIS.
1441 Location information is attributed to the LIS either through the use
1442 of digital signatures or by having the location recipient directly
1443 interact with the LIS. A LIS that digitally signs location
1444 information becomes identifiable as the source of the data.
1445 Similarly, the LIS is identified as a source of data if a location
1446 recipient acquires information directly from a LIS using a location
1447 URI.
1449 7.1.4. Measurement Replay
1451 The value of some measured properties do not change over time for a
1452 single location. This allows for simple replay attacks, where an
1453 attacker acquires measurements that can later be used without being
1454 detected as being invalid.
1456 Measurement data is frequently an observation of an time-invariant
1457 property of the environment at the subject location. For
1458 measurements of this nature, nothing in the measurement itself is
1459 sufficient proof that the Device is present at the resulting
1460 location. Measurement data might have been previously acquired and
1461 reused.
1463 For instance, the identity of a radio transmitter, if broadcast by
1464 that transmitter, can be collected and stored. An attacker that
1465 wishes it known that they exist at a particular location, can claim
1466 to observe this transmitter at any time. Nothing inherent in the
1467 claim reveals it to be false.
1469 For properties of a network, time-invariance is often directly as a
1470 result of the practicalities of operating the network. Limiting the
1471 changes to a network ensures greater consistency of service. A
1472 largely static network also greatly simplifies the data management
1473 tasks involved with providing a location service.
1475 7.1.5. Environment Spoofing
1477 Some types of measurement data can be altered or influenced by a
1478 third party so that a Device. If it is possible for a third party to
1479 alter the measured phenomenon, then any location information that is
1480 derived from this data can be indirectly influenced.
1482 Altering the environment in this fashion might not require
1483 involvement with either Device or LIS. Measurement that is passive -
1484 where the Device observes a signal or other phenomenon without direct
1485 interaction - are most susceptible to alteration by third parties.
1487 Measurement of radio signal characteristics is especially vulnerable
1488 since an adversary need only be in the general vicinity of the Device
1489 and be able to transmit a signal. For instance, a GNSS spoofer is
1490 able to produce fake signals that claim to be transmitted by any
1491 satellite or set of satellites (see [GPS.SPOOF]).
1493 Measurements that require direct interaction increases the complexity
1494 of the attack. For measurements relating to the communication
1495 medium, a third party cannot avoid direct interaction, they need only
1496 be on the comminications path (that is, man in the middle).
1498 Even if the entity that is interacted with is authenticated, this
1499 does not provide any assurance about the integrity of measurement
1500 data. For instance, the Device might authenticate the identity of a
1501 radio transmitter through the use of cryptographic means and obtain
1502 signal strength measurements for that transmitter. Radio signal
1503 strength is trivial for an attacker to increase simply by receiving
1504 and amplifying the raw signal; it is not necessary for the attacker
1505 to be able to understand the signal content.
1507 Note: This particular "attack" is more often completely legitimate.
1508 Radio repeaters are commonplace mechanism used to increase radio
1509 coverage.
1511 Attacks that rely on altering the observed environment of a Device
1512 require countermeasures that affect the measurement process. For
1513 radio signals, countermeasures could include the use of authenticated
1514 signals, altered receiver design. In general, countermeasures are
1515 highly specific to the individual measurement process. An exhaustive
1516 discussion of these issues is left to the relevant literature for
1517 each measurement technology.
1519 A Device that provides measurement data is assumed to be responsible
1520 for applying appropriate countermeasures against this type of attack.
1522 For a Device that is the ultimate recipient of location information
1523 derived from measurement data, a LIS might choose to provide location
1524 information without any validation. The responsibility for ensuring
1525 the veracity of the measurement data lies with the Device.
1527 Measurement data that is susceptible to this sort of influence MUST
1528 be treated as though it were produced by an untrusted Device for
1529 those cases where a location recipient might attribute the location
1530 information to the LIS. Such measurement data MUST be subjected to
1531 the same validation as for other types of attacks that rely on
1532 measurement falsification.
1534 Note: Altered measurement data might be provided by a Device that
1535 has no knowledge of the alteration. Thus, an otherwise trusted
1536 Device might still be an unreliable source of measurement data.
1538 7.2. Mitigation
1540 The following measures can be applied to limit or prevent attacks.
1541 The effectiveness of each depends on the type of measurement data and
1542 how that measurement data is acquired.
1544 Two general approaches are identified for dealing with untrusted
1545 measurement data:
1547 1. Require independent validation of measurement data or the
1548 location information that is produced.
1550 2. Identify the types of sources that provided the measurement data
1551 that location information was derived from.
1553 This section goes into more detail on the different forms of
1554 validation in Section 7.2.1, Section 7.2.2, and Section 7.2.3. The
1555 impact of attributing location information to sources is discussed in
1556 more detail in Section 7.2.4.
1558 7.2.1. Measurement Validation
1560 Detecting that measurement data has been falsified is difficult in
1561 the absence of integrity mechanisms.
1563 Independent confirmation of the veracity of measurement data ensures
1564 that the measurement is accurate and that it applies to the correct
1565 Device. By gathering the same measurement data from a trusted and
1566 independent source, the LIS is able to check that the measurement
1567 data is correct.
1569 Measurement information might contain no inherent indication that it
1570 is falsified. On the contrary, it can be difficult to obtain
1571 information that would provide any degree of assurance that the
1572 measurement device is physically at any particular location.
1573 Measurements that are difficult to verify require other forms of
1574 assurance before they can be used.
1576 7.2.1.1. Effectiveness
1578 Measurement validation MUST be used if measurement data for a
1579 particular Device can be easily acquired by unauthorized location
1580 recipients, as described in Section 7.1.1. This prevents
1581 unauthorized access to location information using measurement data.
1583 Validation of measurement data can be significantly more effective
1584 than independent acquisition of the same. For instance, a Device in
1585 a large Ethernet network could provide a measurement indicating its
1586 point of attachment using LLDP measurements. For a LIS, acquiring
1587 the same measurement data might require a request to all switches in
1588 that network. With the measurement data, validation can target the
1589 identified switch with a specific query.
1591 Validation is effective in identifying falsified measurement data
1592 (Section 7.1.3), including attacks involving replay of measurement
1593 data (Section 7.1.4). Validation also limits the amount of network
1594 topology information (Section 7.1.2) made available to Devices to
1595 that portion of the network topology that they are directly attached.
1597 Measurement validation has no effect if the underlying effect is
1598 being spoofed (Section 7.1.5).
1600 7.2.1.2. Limitations (Unique Observer)
1602 A Device is often in a unique position to make a measurement. It
1603 alone occupies the point in space-time that the location
1604 determination process seeks to determine. The Device becomes a
1605 unique observer for a particular property.
1607 The ability of the Device to become a unique observer makes the
1608 Device invaluable to the location determination process. As a unique
1609 observer, it also makes the claims of a Device difficult to validate
1610 and easily to spoof.
1612 As long as no other entity is capable of making the same
1613 measurements, there is also no other entity that can independently
1614 check that the measurements are correct and applicable to the Device.
1615 A LIS might be unable to validate all or part of the measurement data
1616 it receives from a unique observer. For instance, a signal strength
1617 measurement of the signal from a radio tower cannot be validated
1618 directly.
1620 Some portion of the measurement data might still be independently
1621 verified, even if all information cannot. In the previous example,
1622 the radio tower might be able to provide verification that the Device
1623 is present if it is able to observe a radio signal sent by the
1624 Device.
1626 If measurement data can only be partially validated, the extent to
1627 which it can be validated determines the effectiveness of validation
1628 against these attacks.
1630 The advantage of having the Device as a unique observer is that it
1631 makes it difficult for an attacker to acquire measurements without
1632 the assistance of the Device. Attempts to use measurements to gain
1633 unauthorized access to measurement data (Section 7.1.1) are largely
1634 ineffectual against a unique observer.
1636 7.2.2. Location Validation
1638 Location information that is derived from location-related
1639 measurement data can also be verified against trusted location
1640 information. Rather than validating inputs to the location
1641 determination process, suspect locations are identified at the output
1642 of the process.
1644 Trusted location information is acquired using sources of measurement
1645 data that are trusted. Untrusted location information is acquired
1646 using measurement data provided from untrusted sources, which might
1647 include the Device. These two locations are compared. If the
1648 untrusted location agrees with the trusted location, the untrusted
1649 location information is used.
1651 Algorithms for the comparison of location information are not
1652 included in this document. However, a simple comparison for
1653 agreement might require that the untrusted location be entirely
1654 contained within the uncertainty region of the trusted location.
1656 There is little point in using a less accurate, less trusted
1657 location. Untrusted location information that has worse accuracy
1658 than trusted information can be immediately discarded. There are
1659 multiple factors that affect accuracy, uncertainty and currency being
1660 the most important. How location information is compared for
1661 accuracy is not defined in this document.
1663 7.2.2.1. Effectiveness
1665 Location validation limits the extent to which falsified - or
1666 erroneous - measurement data can cause an incorrect location to be
1667 reported.
1669 Location validation can be more efficient than validation of inputs,
1670 particularly for a unique observer (Section 7.2.1.2).
1672 Validating location ensures that the Device is at or near the
1673 resulting location. Location validation can be used to limit or
1674 prevent all of the attacks identified in this document.
1676 7.2.2.2. Limitations
1678 The trusted location that is used for validation is always less
1679 accurate than the location that is being checked. The amount by
1680 which the untrusted location is more accurate, is the same amount
1681 that an attacker can exploit.
1683 For example, a trusted location might indicate a five kilometer
1684 radius uncertainty region. An untrusted location that describes a
1685 100 meter uncertainty within the larger region might be accepted as
1686 more accurate. An attacker might still falsify measurement data to
1687 select any location within the larger uncertainty region. While the
1688 100 meter uncertainty that is reported seems more accurate, a
1689 falsified location could be anywhere in the five kilometer region.
1691 Where measurement data might have been falsified, the actual
1692 uncertainty is effectively much higher. Local policy might allow
1693 differing degrees of trust to location information derived from
1694 untrusted measurement data. This might not be a boolean operation
1695 with only two possible outcomes: untrusted location information might
1696 be used entirely or not at all, or it could be combined with trusted
1697 location information with the degree to which each contributes based
1698 on a value set in local policy.
1700 7.2.3. Supporting Observations
1702 Replay attacks using previously acquired measurement data are
1703 particularly hard to detect without independent validation. Rather
1704 than validate the measurement data directly, supplementary data might
1705 be used to validate measurements or the location information derived
1706 from those measurements.
1708 These supporting observations could be used to convey information
1709 that provides additional assurance that the Device was acquired at a
1710 specific time and place. In effect, the Device is requested to
1711 provide proof of its presence at the resulting location.
1713 For instance, a Device that measures attributes of a radio signal
1714 could also be asked to provide a sample of the measured radio signal.
1715 If the LIS is able to observe the same signal, the two observations
1716 could be compared. Providing that the signal cannot be predicted in
1717 advance by the Device, this could be used to support the claim that
1718 the Device is able to receive the signal. Thus, the Device is likely
1719 to be within the range that the signal is transmitted. A LIS could
1720 use this to attribute a higher level of trust in the associated
1721 measurement data or resulting location.
1723 7.2.3.1. Effectiveness
1725 The use of supporting observations is limited by the ability of the
1726 LIS to acquire and validate these observations. The advantage of
1727 selecting observations independent of measurement data is that
1728 observations can be selected based on how readily available the data
1729 is for both LIS and Device. The amount and quality of the data can
1730 be selected based on the degree of assurance that is desired.
1732 Use of supporting observations is similar to both measurement
1733 validation and location validation. All three methods rely on
1734 independent validation of one or more properties. Applicability of
1735 each method is similar.
1737 Use of supporting observations can be used to limit or prevent all of
1738 the attacks identified in this document.
1740 7.2.3.2. Limitations
1742 The effectiveness of the validation method depends on the quality of
1743 the supporting observation: how hard it is to obtain at a different
1744 time or place, how difficult it is to guess and what other costs
1745 might be involved in acquiring this data.
1747 In the example of an observed radio signal, requesting a sample of
1748 the signal only provides an assurance that the Device is able to
1749 receive the signal transmitted by the measured radio transmitter.
1750 This only provides some assurance that the Device is within range of
1751 the transmitter.
1753 As with location validation, a Device might still be able to provide
1754 falsified measurements that could alter the value of the location
1755 information as long as the result is within this region.
1757 Requesting additional supporting observations can reduce the size of
1758 the region over which location information can be altered by an
1759 attacker, or increase trust in the result, but each additional has a
1760 cost. Supporting observations contribute little or nothing toward
1761 the primary goal of determining the location of the Device. Any
1762 costs in acquiring supporting observations are balanced against the
1763 degree of integrity desired of the resulting location information.
1765 7.2.4. Attribution
1767 Lying by proxy (Section 7.1.3) relies on the location recipient being
1768 able to attribute location information to a LIS. The effectiveness
1769 of this attack is negated if location information is explicitly
1770 attributed to a particular source.
1772 This requires an extension to the location object that explicitly
1773 identifies the source (or sources) of each item of location
1774 information.
1776 Rather than relying on a process that seeks to ensure that location
1777 information is accurate, this approach instead provides a location
1778 recipient with the information necessary to reach their own
1779 conclusion about the trustworthiness of the location information.
1781 Including an authenticated identity for all sources of measurement
1782 data is presents a number of technical and operational challenges.
1783 It is possible that the LIS has a transient relationship with a
1784 Device. A Device is not expected to share authentication information
1785 with a LIS. There is no assurance that Device identification is
1786 usable by a potential location recipient. Privacy concerns might
1787 also prevent the sharing identification information, even if it were
1788 available and usable.
1790 Identifying the type of measurement source allows a location
1791 recipient to make a decision about the trustworthiness of location
1792 information without depending on having authenticated identity
1793 information for each source. An element for this purpose is defined
1794 in Section 4.4.
1796 When including location information that is based on measurement data
1797 from sources that might be untrusted, a LIS SHOULD include
1798 alternative location information that is derived from trusted sources
1799 of measurement data. Each item of location information can then be
1800 labelled with the source of that data.
1802 A location recipient that is able to identify a specific source of
1803 measurement data (whether it be LIS or Device) can use this
1804 information to attribute location information to either or both
1805 entity. The location recipient is then better able to make decisions
1806 about trustworthiness based on the source of the data.
1808 A location recipient that does not understand the "source" element is
1809 unable to make this distinction. When constructing a PIDF-LO
1810 document, trusted location information MUST be placed in the PIDF-LO
1811 so that it is given higher priority to any untrusted location
1812 information according to Rule #8 of [RFC5491].
1814 Attribution of information does nothing to address attacks that alter
1815 the observed parameters that are used in location determination
1816 (Section 7.1.5).
1818 7.2.5. Stateful Correlation of Location Requests
1820 Stateful examination of requests can be used to prevent a Device from
1821 attempting to map network topology using requests for location
1822 information (Section 7.1.2).
1824 Simply limiting the rate of requests from a single Device reduces the
1825 amount of data that a Device can acquire about network topology.
1827 8. Measurement Schemas
1829 The schema are broken up into their respective functions. There is a
1830 base container schema into which all measurements are placed, plus
1831 definitions for a measurement request (Section 8.1). A PIDF-LO
1832 extension is defined in a separate schema (Section 8.2). There is a
1833 basic types schema, that contains various base type definitions for
1834 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and
1835 MAC addresses (Section 8.3). Then each of the specific measurement
1836 types is defined in its own schema.
1838 8.1. Measurement Container Schema
1839
1840
1848
1849
1851
1852
1853
1855 This schema defines a framework for location measurements.
1856
1857
1859
1861
1862
1863
1864
1865
1866
1868
1869
1870
1871
1872
1873
1874
1875
1876
1878
1880
1881
1882
1883
1884
1886
1888
1889
1890
1891
1893
1894
1895
1896
1897
1898
1900
1901
1902
1903
1904
1905
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1922 Measurement Container Schema
1924 8.2. Measurement Source Schema
1926
1927
1934
1935
1937
1938
1939
1941 This schema defines an extension to PIDF-LO that indicates the
1942 type of source that produced the measurement data used in
1943 generating the associated location information.
1944
1945
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1961 Measurement Source PIDF-LO Extension Schema
1963 8.3. Base Type Schema
1965 Note that the pattern rules in the following schema wrap due to
1966 length constraints. None of the patterns contain whitespace.
1968
1969
1976
1977
1979
1980
1981
1983 This schema defines a set of base type elements.
1984
1985
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2027
2028
2029
2031
2032
2033
2034
2035 An IP version 6 address, based on RFC 4291.
2036
2037
2038
2039
2040
2041
2042
2043
2044
2046
2048
2050
2052
2054
2056
2057
2058
2059
2067
2068
2069
2070
2072
2073
2074
2075
2079
2080
2082
2083
2084
2085
2087
2088
2090
2092 Base Type Schema
2094 8.4. LLDP Measurement Schema
2096
2097
2105
2106
2108
2109
2110
2112 This schema defines a set of LLDP location measurements.
2113
2114
2115
2117
2118
2119
2120
2121
2122
2123
2124
2126
2127
2128
2129
2130
2132
2133
2134
2135
2137
2138
2139
2141
2142
2143
2144
2145
2146
2148
2150 LLDP measurement schema
2152 8.5. DHCP Measurement Schema
2154
2155
2163
2164
2166
2167
2168
2170 This schema defines a set of DHCP location measurements.
2171
2172
2174
2176
2177
2178
2179
2180
2181
2182
2183
2185
2187
2189
2191
2192
2193
2194
2195
2197
2198
2199
2200
2202
2203
2204
2206
2208 DHCP measurement schema
2210 8.6. WiFi Measurement Schema
2211
2212
2221
2222
2224 802.11 location measurements
2225
2226
2227
2229 This schema defines a basic set of 802.11 location measurements.
2230
2231
2233
2234
2236
2238
2239
2240
2241
2242
2244
2246
2247
2248
2249
2250
2252
2253
2254
2255
2256
2257
2260
2262
2264
2266
2268
2270
2272
2274
2276
2278
2279
2281
2282
2283
2284
2286
2287
2288
2289
2291
2292
2293
2295
2297
2298
2299
2300
2301
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2322
2323
2324
2325
2326
2328
2329
2330
2331
2332
2334
2335
2337
2339
2341
2342
2343
2344
2346
2347
2348
2349
2350
2351
2352
2354
2355
2356
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2373
2375 WiFi measurement schema
2377 8.7. Cellular Measurement Schema
2379
2380
2387
2388
2390
2391
2392
2394 This schema defines a set of cellular location measurements.
2395
2396
2398
2400
2401
2402
2403
2404
2405
2406
2407
2408
2410
2411
2412
2413
2414
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2435
2436
2437
2438
2439
2440
2442
2443
2445
2446
2447
2448
2450
2451
2452
2453
2454
2456
2457
2458
2459
2460
2462
2463
2464
2465
2466
2468
2470
2471
2472
2473
2474
2475
2476
2477
2478
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2495
2497 Cellular measurement schema
2499 8.8. GNSS Measurement Schema
2500
2501
2509
2510
2512
2513
2514
2516 This schema defines a set of GNSS location measurements
2517
2518
2520
2522
2523
2524
2525
2526
2527
2528
2530
2531
2532
2533
2534
2536
2538
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2554
2555
2557
2559
2560
2561
2563
2564
2565
2567
2568
2569
2570
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2585 GNSS measurement Schema
2587 8.9. DSL Measurement Schema
2589
2590
2598
2599
2601 DSL measurement definitions
2602
2603
2604
2606 This schema defines a basic set of DSL location measurements.
2607
2608
2610
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2644
2645
2646
2647
2648
2649
2650
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2669
2671 DSL measurement schema
2673 9. IANA Considerations
2675 This section creates a registry for GNSS types (Section 5.5) and
2676 registers the namespaces and schema defined in Section 8.
2678 9.1. IANA Registry for GNSS Types
2680 This document establishes a new IANA registry for Global Navigation
2681 Satellite System (GNSS) types. The registry includes tokens for the
2682 GNSS type and for each of the signals within that type. Referring to
2683 [RFC5226], this registry operates under "Specification Required"
2684 rules. The IESG will appoint an Expert Reviewer who will advise IANA
2685 promptly on each request for a new or updated GNSS type.
2687 Each entry in the registry requires the following information:
2689 GNSS name: the name and a brief description of the GNSS
2691 Brief description: the name and a brief description of the GNSS
2693 GNSS token: a token that can be used to identify the GNSS
2695 Signals: a set of tokens that represent each of the signals that the
2696 system provides
2698 Documentation reference: a reference to one or more stable, public
2699 specifications that outline usage of the GNSS, including (but not
2700 limited to) signal specifications and time systems
2702 The registry initially includes two registrations:
2704 GNSS name: Global Positioning System (GPS)
2706 Brief description: a system of satellites that use spread-spectrum
2707 transmission, operated by the US military for commercial and
2708 military applications
2710 GNSS token: gps
2712 Signals: L1, L2, L1C, L2C, L5
2714 Documentation reference: Navstar GPS Space Segment/Navigation User
2715 Interface [GPS.ICD]
2717 GNSS name: Galileo
2719 Brief description: a system of satellites that operate in the same
2720 spectrum as GPS, operated by the European Union for commercial
2721 applications
2723 GNSS Token: galileo
2725 Signals: L1, E5A, E5B, E5A+B, E6
2727 Documentation Reference: Galileo Open Service Signal In Space
2728 Interface Control Document (SIS ICD) [Galileo.ICD]
2730 9.2. URN Sub-Namespace Registration for
2731 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2733 This section registers a new XML namespace,
2734 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines
2735 in [RFC3688].
2737 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2739 Registrant Contact: IETF, GEOPRIV working group,
2740 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2742 XML:
2744 BEGIN
2745
2746
2748
2749
2750 Measurement Source for PIDF-LO
2751
2752
2753 Namespace for Location Measurement Source
2754 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2755 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2756 with the RFC number for this specification.]]
2757 See RFCXXXX.
2758
2759
2760 END
2762 9.3. URN Sub-Namespace Registration for
2763 urn:ietf:params:xml:ns:geopriv:lm
2765 This section registers a new XML namespace,
2766 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in
2767 [RFC3688].
2769 URI: urn:ietf:params:xml:ns:geopriv:lm
2771 Registrant Contact: IETF, GEOPRIV working group,
2772 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2774 XML:
2776 BEGIN
2777
2778
2780
2781
2782 Measurement Container
2783
2784
2785 Namespace for Location Measurement Container
2786 urn:ietf:params:xml:ns:geopriv:lm
2787 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2788 with the RFC number for this specification.]]
2789 See RFCXXXX.
2790
2791
2792 END
2794 9.4. URN Sub-Namespace Registration for
2795 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2797 This section registers a new XML namespace,
2798 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines
2799 in [RFC3688].
2801 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes
2803 Registrant Contact: IETF, GEOPRIV working group,
2804 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2806 XML:
2808 BEGIN
2809
2810
2812
2813
2814 Base Device Types
2815
2816
2817 Namespace for Base Types
2818 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2819 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2820 with the RFC number for this specification.]]
2821 See RFCXXXX.
2822
2823
2825 END
2827 9.5. URN Sub-Namespace Registration for
2828 urn:ietf:params:xml:ns:geopriv:lm:lldp
2830 This section registers a new XML namespace,
2831 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in
2832 [RFC3688].
2834 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
2836 Registrant Contact: IETF, GEOPRIV working group,
2837 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2839 XML:
2841 BEGIN
2842
2843
2845
2846
2847 LLDP Measurement Set
2848
2849
2850 Namespace for LLDP Measurement Set
2851 urn:ietf:params:xml:ns:geopriv:lm:lldp
2852 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2853 with the RFC number for this specification.]]
2854 See RFCXXXX.
2855
2856
2857 END
2859 9.6. URN Sub-Namespace Registration for
2860 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2862 This section registers a new XML namespace,
2863 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in
2864 [RFC3688].
2866 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
2868 Registrant Contact: IETF, GEOPRIV working group,
2869 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2871 XML:
2873 BEGIN
2874
2875
2877
2878
2879 DHCP Measurement Set
2880
2881
2882 Namespace for DHCP Measurement Set
2883 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2884 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2885 with the RFC number for this specification.]]
2886 See RFCXXXX.
2887
2888
2889 END
2891 9.7. URN Sub-Namespace Registration for
2892 urn:ietf:params:xml:ns:geopriv:lm:wifi
2894 This section registers a new XML namespace,
2895 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
2896 [RFC3688].
2898 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi
2900 Registrant Contact: IETF, GEOPRIV working group,
2901 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2903 XML:
2905 BEGIN
2906
2907
2909
2910
2911 WiFi Measurement Set
2912
2913
2914 Namespace for WiFi Measurement Set
2915 urn:ietf:params:xml:ns:geopriv:lm:wifi
2916 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2917 with the RFC number for this specification.]]
2918 See RFCXXXX.
2919
2920
2922 END
2924 9.8. URN Sub-Namespace Registration for
2925 urn:ietf:params:xml:ns:geopriv:lm:cell
2927 This section registers a new XML namespace,
2928 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in
2929 [RFC3688].
2931 URI: urn:ietf:params:xml:ns:geopriv:lm:cell
2933 Registrant Contact: IETF, GEOPRIV working group,
2934 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2936 XML:
2938 BEGIN
2939
2940
2942
2943
2944 Cellular Measurement Set
2945
2946
2947 Namespace for Cellular Measurement Set
2948 urn:ietf:params:xml:ns:geopriv:lm:cell
2949 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2950 with the RFC number for this specification.]]
2951 See RFCXXXX.
2952
2953
2954 END
2956 9.9. URN Sub-Namespace Registration for
2957 urn:ietf:params:xml:ns:geopriv:lm:gnss
2959 This section registers a new XML namespace,
2960 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in
2961 [RFC3688].
2963 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
2965 Registrant Contact: IETF, GEOPRIV working group,
2966 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2968 XML:
2970 BEGIN
2971
2972
2974
2975
2976 GNSS Measurement Set
2977
2978
2979 Namespace for GNSS Measurement Set
2980 urn:ietf:params:xml:ns:geopriv:lm:gnss
2981 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2982 with the RFC number for this specification.]]
2983 See RFCXXXX.
2984
2985
2986 END
2988 9.10. URN Sub-Namespace Registration for
2989 urn:ietf:params:xml:ns:geopriv:lm:dsl
2991 This section registers a new XML namespace,
2992 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in
2993 [RFC3688].
2995 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl
2997 Registrant Contact: IETF, GEOPRIV working group,
2998 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
3000 XML:
3002 BEGIN
3003
3004
3006
3007
3008 DSL Measurement Set
3009
3010
3011 Namespace for DSL Measurement Set
3012 urn:ietf:params:xml:ns:geopriv:lm:dsl
3013 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3014 with the RFC number for this specification.]]
3015 See RFCXXXX.
3016
3017
3019 END
3021 9.11. XML Schema Registration for Measurement Source Schema
3023 This section registers an XML schema as per the guidelines in
3024 [RFC3688].
3026 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
3028 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3029 Martin Thomson (martin.thomson@commscope.com).
3031 Schema: The XML for this schema can be found in Section 8.2 of this
3032 document.
3034 9.12. XML Schema Registration for Measurement Container Schema
3036 This section registers an XML schema as per the guidelines in
3037 [RFC3688].
3039 URI: urn:ietf:params:xml:schema:lm
3041 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3042 Martin Thomson (martin.thomson@commscope.com).
3044 Schema: The XML for this schema can be found in Section 8.1 of this
3045 document.
3047 9.13. XML Schema Registration for Base Types Schema
3049 This section registers an XML schema as per the guidelines in
3050 [RFC3688].
3052 URI: urn:ietf:params:xml:schema:lm:basetypes
3054 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3055 Martin Thomson (martin.thomson@commscope.com).
3057 Schema: The XML for this schema can be found in Section 8.3 of this
3058 document.
3060 9.14. XML Schema Registration for LLDP Schema
3062 This section registers an XML schema as per the guidelines in
3063 [RFC3688].
3065 URI: urn:ietf:params:xml:schema:lm:lldp
3067 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3068 Martin Thomson (martin.thomson@commscope.com).
3070 Schema: The XML for this schema can be found in Section 8.4 of this
3071 document.
3073 9.15. XML Schema Registration for DHCP Schema
3075 This section registers an XML schema as per the guidelines in
3076 [RFC3688].
3078 URI: urn:ietf:params:xml:schema:lm:dhcp
3080 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3081 Martin Thomson (martin.thomson@commscope.com).
3083 Schema: The XML for this schema can be found in Section 8.5 of this
3084 document.
3086 9.16. XML Schema Registration for WiFi Schema
3088 This section registers an XML schema as per the guidelines in
3089 [RFC3688].
3091 URI: urn:ietf:params:xml:schema:lm:wifi
3093 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3094 Martin Thomson (martin.thomson@commscope.com).
3096 Schema: The XML for this schema can be found in Section 8.6 of this
3097 document.
3099 9.17. XML Schema Registration for Cellular Schema
3101 This section registers an XML schema as per the guidelines in
3102 [RFC3688].
3104 URI: urn:ietf:params:xml:schema:lm:cellular
3106 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3107 Martin Thomson (martin.thomson@commscope.com).
3109 Schema: The XML for this schema can be found in Section 8.7 of this
3110 document.
3112 9.18. XML Schema Registration for GNSS Schema
3114 This section registers an XML schema as per the guidelines in
3115 [RFC3688].
3117 URI: urn:ietf:params:xml:schema:lm:gnss
3119 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3120 Martin Thomson (martin.thomson@commscope.com).
3122 Schema: The XML for this schema can be found in Section 8.8 of this
3123 document.
3125 9.19. XML Schema Registration for DSL Schema
3127 This section registers an XML schema as per the guidelines in
3128 [RFC3688].
3130 URI: urn:ietf:params:xml:schema:lm:dsl
3132 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3133 Martin Thomson (martin.thomson@commscope.com).
3135 Schema: The XML for this schema can be found in Section 8.9 of this
3136 document.
3138 10. Acknowledgements
3140 Thanks go to Simon Cox for his comments relating to terminology that
3141 have helped ensure that this document is aligns with ongoing work in
3142 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his
3143 review and comments on the GNSS sections of this document. Thanks to
3144 Noor-E-Gagan Singh, Gabor Bajko, Russell Priebe, and Khalid Al-Mufti
3145 for their significant input to and suggestions for improving the
3146 802.11 measurements. Thanks to Cullen Jennings for feedback and
3147 suggestions. Bernard Aboba provided review and feedback on a range
3148 of measurement data definitions. Mary Barnes and Geoff Thompson
3149 provided a review and corrections. David Waitzman and John Bressler
3150 both noted shortcomings with 802.11 measurements. Keith Drage,
3151 Darren Pawson provided expert LTE knowledge.
3153 11. References
3154 11.1. Normative References
3156 [DSL.TR025]
3157 Wang, R., "Core Network Architecture Recommendations for
3158 Access to Legacy Data Networks over ADSL", September 1999.
3160 [DSL.TR101]
3161 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
3162 Aggregation", April 2006.
3164 [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface",
3165 ICD GPS-200, Apr 2000.
3167 [Galileo.ICD]
3168 GJU, "Galileo Open Service Signal In Space Interface
3169 Control Document (SIS ICD)", May 2006.
3171 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
3172 October 1969.
3174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3175 Requirement Levels", BCP 14, RFC 2119, March 1997.
3177 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3178 10646", STD 63, RFC 3629, November 2003.
3180 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3181 Resource Identifier (URI): Generic Syntax", STD 66,
3182 RFC 3986, January 2005.
3184 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
3185 Format", RFC 4119, December 2005.
3187 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3188 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3189 May 2008.
3191 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
3192 Presence Information Data Format Location Object (PIDF-LO)
3193 Usage Clarification, Considerations, and Recommendations",
3194 RFC 5491, March 2009.
3196 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
3197 RFC 5985, September 2010.
3199 [TIA-2000.5]
3200 TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for
3201 cdma2000(R) Spread Spectrum Systems", TIA-2000.5-D,
3202 March 2004.
3204 [TS.3GPP.23.003]
3205 3GPP, "Numbering, addressing and identification", 3GPP
3206 TS 23.003 9.4.0, September 2010.
3208 11.2. Informative References
3210 [ANSI-TIA-1057]
3211 ANSI/TIA, "Link Layer Discovery Protocol for Media
3212 Endpoint Devices", TIA 1057, April 2006.
3214 [GPS.SPOOF]
3215 Scott, L., "Anti-Spoofing and Authenticated Signal
3216 Architectures for Civil Navigation Signals", ION-
3217 GNSS Portland, Oregon, 2003.
3219 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side
3220 spoofing and detection for Assisted-GPS", Proceedings of
3221 International Global Navigation Satellite Systems Society
3222 (IGNSS) Symposium 2009 16, December 2009,
3223 .
3225 [I-D.ietf-geopriv-held-identity-extensions]
3226 Winterbottom, J., Thomson, M., Tschofenig, H., and R.
3227 Barnes, "Use of Device Identity in HTTP-Enabled Location
3228 Delivery (HELD)",
3229 draft-ietf-geopriv-held-identity-extensions-06 (work in
3230 progress), November 2010.
3232 [I-D.thomson-geopriv-uncertainty]
3233 Thomson, M. and J. Winterbottom, "Representation of
3234 Uncertainty and Confidence in PIDF-LO",
3235 draft-thomson-geopriv-uncertainty-07 (work in progress),
3236 March 2012.
3238 [IANA.enterprise]
3239 IANA, "Private Enterprise Numbers", 2011,
3240 .
3242 [IEEE.80211]
3243 IEEE, "Wireless LAN Medium Access Control (MAC) and
3244 Physical Layer (PHY) specifications - IEEE 802.11 Wireless
3245 Network Management", IEEE Std 802.11-2007, June 2007.
3247 [IEEE.80211V]
3248 IEEE, "Wireless LAN Medium Access Control (MAC) and
3249 Physical Layer (PHY) specifications - IEEE 802.11 Wireless
3250 Network Management (Draft)", P802.11v D12.0, June 2010.
3252 [IEEE.8021AB]
3253 IEEE, "IEEE Standard for Local and Metropolitan area
3254 networks, Station and Media Access Control Connectivity
3255 Discovery", IEEE Std 802.1AB-2009, September 2009.
3257 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
3258 "Remote Authentication Dial In User Service (RADIUS)",
3259 RFC 2865, June 2000.
3261 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
3262 RFC 3046, January 2001.
3264 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
3265 January 2004.
3267 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
3268 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
3270 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
3271 Suboption for the Dynamic Host Configuration Protocol
3272 (DHCP) Relay Agent Option", RFC 3993, March 2005.
3274 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
3275 Architecture", RFC 4291, February 2006.
3277 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3278 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
3279 June 2006.
3281 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3282 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
3283 August 2006.
3285 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
3286 Mechanism", RFC 5808, May 2010.
3288 Authors' Addresses
3290 Martin Thomson
3291 Microsoft
3292 3210 Porter Drive
3293 Palo Alto, CA 94304
3294 US
3296 Phone: +1 650-353-1925
3297 Email: martin.thomson@gmail.com
3299 James Winterbottom
3300 Commscope
3301 Andrew Building (39)
3302 University of Wollongong
3303 Northfields Avenue
3304 NSW 2522
3305 AU
3307 Phone: +61 2 4221 2938
3308 Email: james.winterbottom@commscope.com