idnits 2.17.1
draft-ietf-geopriv-held-measurements-03.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 :
----------------------------------------------------------------------------
** There are 801 instances of lines with control characters in the document.
-- 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 (March 11, 2011) is 4794 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 2073, but not defined
== Missing Reference: '0-4' is mentioned on line 2073, but not defined
== Missing Reference: '0-9' is mentioned on line 2073, but not defined
== Missing Reference: '0-1' is mentioned on line 2073, but not defined
== Unused Reference: 'I-D.thomson-geopriv-uncertainty' is defined on line
3223, but no explicit reference was found in the text
== Unused Reference: 'RFC5808' is defined on line 3276, 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-06
Summary: 2 errors (**), 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 J. Winterbottom
4 Intended status: Standards Track Andrew
5 Expires: September 12, 2011 March 11, 2011
7 Using Device-provided Location-Related Measurements in Location
8 Configuration Protocols
9 draft-ietf-geopriv-held-measurements-03
11 Abstract
13 A method is described by which a Device is able to provide location-
14 related measurement data to a LIS within a request for location
15 information. Location-related measurement information are
16 observations concerning properties related to the position of a
17 Device, which could be data about network attachment or about the
18 physical environment. When a LIS generates location information for
19 a Device, information from the Device can improve the accuracy of the
20 location estimate. A basic set of location-related measurements are
21 defined, including common modes of network attachment as well as
22 assisted Global Navigation Satellite System (GNSS) parameters.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on September 12, 2011.
41 Copyright Notice
43 Copyright (c) 2011 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 This document may contain material from IETF Documents or IETF
57 Contributions published or made publicly available before November
58 10, 2008. The person(s) controlling the copyright in some of this
59 material may not have granted the IETF Trust the right to allow
60 modifications of such material outside the IETF Standards Process.
61 Without obtaining an adequate license from the person(s) controlling
62 the copyright in such materials, this document may not be modified
63 outside the IETF Standards Process, and derivative works of it may
64 not be created outside the IETF Standards Process, except to format
65 it for publication as an RFC or to translate it into languages other
66 than English.
68 Table of Contents
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
71 2. Conventions used in this document . . . . . . . . . . . . . . 6
72 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 7
73 4. Location-Related Measurement Data Types . . . . . . . . . . . 8
74 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 9
75 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 9
76 4.1.2. Expiry Time on Location-Related Measurement Data . . . 9
77 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 10
78 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . . 10
79 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 11
80 4.4. Identifying Location Provenance . . . . . . . . . . . . . 12
81 5. Location-Related Measurement Data Types . . . . . . . . . . . 15
82 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 15
83 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 16
84 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 16
85 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 20
86 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 20
87 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 23
88 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 23
89 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . . 25
90 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 26
91 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . . 26
92 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 27
93 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 27
94 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 28
95 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 28
96 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 29
97 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 29
98 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 29
99 6.1. Measurement Data Privacy Model . . . . . . . . . . . . . . 30
100 6.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . . 30
101 6.3. Measurement Data and Location URIs . . . . . . . . . . . . 30
102 6.4. Third-Party-Provided Measurement Data . . . . . . . . . . 31
103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
104 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 31
105 7.1.1. Acquiring Location Information Without
106 Authorization . . . . . . . . . . . . . . . . . . . . 32
107 7.1.2. Extracting Network Topology Data . . . . . . . . . . . 33
108 7.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . . 33
109 7.1.4. Measurement Replay . . . . . . . . . . . . . . . . . . 34
110 7.1.5. Environment Spoofing . . . . . . . . . . . . . . . . . 35
111 7.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 36
112 7.2.1. Measurement Validation . . . . . . . . . . . . . . . . 37
113 7.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 37
114 7.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 37
115 7.2.2. Location Validation . . . . . . . . . . . . . . . . . 38
117 7.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 39
118 7.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 39
119 7.2.3. Supporting Observations . . . . . . . . . . . . . . . 39
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 . . . . . . . . . . . . . . . 42
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 70
166 11.1. Normative References . . . . . . . . . . . . . . . . . . . 70
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
263 Measurement data that the LIS does not support or understand can be
264 ignored. The measurements defined in this document follow this rule;
265 extensions that could result in backward incompatibility MUST be
266 added as new measurement definitions rather than extensions to
267 existing types.
269 Multiple sets of measurement data, either of the same type or from
270 different sources can be included in the "measurements" element. See
271 Section 4.1.1 for details on repetition of this element.
273 Use of location-related measurement data is at the discretion of the
274 LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to
275 reflect the method used.
277 Location-related measurement data need not be provided exclusively by
278 Devices. A third party location requester can request location
279 information using measurement data, if they are able and authorized.
280 There are privacy considerations relating to the use of measurements
281 by third parties, which are discussed in Section 6.4.
283 Location-related measurement data and its use presents a number of
284 security challenges. These are described in more detail in
285 Section 7.
287 4. Location-Related Measurement Data Types
289 A common container is defined for the expression of location
290 measurement data, as well as a simple means of identifying specific
291 types of measurement data for the purposes of requesting them.
293 The following example shows a measurement container with measurement
294 time and expiration time included. A WiFi measurement is enclosed.
296
299
300
301 00-12-F0-A0-80-EF
302 wlan-home
303
304
305
307 Figure 2: Measurement Example
308 4.1. Measurement Container
310 The "measurement" element is used to encapsulate measurement data
311 that is collected at a certain point in time. It contains time-based
312 attributes that are common to all forms of measurement data, and
313 permits the inclusion of arbitrary measurement data.
315 This container can be added to any request for location information,
316 such as a HELD location request [RFC5985].
318 4.1.1. Time of Measurement
320 The "time" attribute records the time that the measurement or
321 observation was made. This time can be different to the time that
322 the measurement information was reported. Time information can be
323 used to populate a timestamp on the location result, or to determine
324 if the measurement information is used.
326 The "time" attribute is optional to avoid forcing an arbitrary choice
327 of timestamp for relatively static types of measurement (for
328 instance, the DSL measurements in Section 5.6) and for legacy Devices
329 that don't record time information (such as the Home Location
330 Register/Home Subscriber Server for cellular). However, time SHOULD
331 be provided whenever possible.
333 The "time" attribute is attached to the root "measurement" element.
334 If it is necessary to provide multiple sets of measurement data with
335 different times, multiple "measurement" elements SHOULD be provided.
337 4.1.2. Expiry Time on Location-Related Measurement Data
339 A Device is able to indicate an expiry time in the location
340 measurement using the "expires" attribute. Nominally, this attribute
341 indicates how long information is expected to be valid for, but it
342 can also indicate a time limit on the retention and use of the
343 measurement data. A Device can use this attribute to prevent the LIS
344 from retaining measurement data or limit the time that a LIS retains
345 this information.
347 Note: Movement of a Device might result in the measurement data
348 being invalidated before the expiry time.
350 The LIS MUST NOT keep location-related measurement data beyond the
351 time indicated in the "expires" attribute.
353 4.2. RMS Error and Number of Samples
355 Often a measurement is taken more than once over a period of time.
356 Reporting the average of a number of measurement results mitigates
357 the effects of random errors that occur in the measurement process.
359 Reporting each measurement individually can be the most effective
360 method of reporting multiple measurements. This is achieved by
361 providing multiple "measurement" elements for different times.
363 The alternative is to aggregate multiple measurements and report a
364 mean value across the set of measurements. Additional information
365 about the distribution of the results can be useful in determining
366 location uncertainty.
368 Two optional attributes are provided for certain measurement values:
370 rmsError: The root-mean-squared (RMS) error of the set of
371 measurement values used in calculating the result. RMS error is
372 expressed in the same units as the measurement, unless otherwise
373 stated. If an accurate value for RMS error is not known, this
374 value can be used to indicate an upper bound or estimate for the
375 RMS error.
377 samples: The number of samples that were taken in determining the
378 measurement value. If omitted, this value can be assumed to be a
379 very large value, so that the RMS error is an indication of the
380 standard deviation of the sample set.
382 For some measurement techniques, measurement error is largely
383 dependent on the measurement technique employed. In these cases,
384 measurement error is largely a product of the measurement technique
385 and not the specific circumstances, so RMS error does not need to be
386 actively measured. A fixed value MAY be provided for RMS error where
387 appropriate.
389 The "rmsError" and "samples" elements are added as attributes of
390 specific measurement data types.
392 4.2.1. Time RMS Error
394 Measurement of time can be significant in certain circumstances. The
395 GNSS measurements included in this document are one such case where a
396 small error in time can result in a large error in location. Factors
397 such as clock drift and errors in time sychronization can result in
398 small, but significant, time errors. Including an indication of the
399 quality of the time can be helpful.
401 An optional "timeError" attribute can be added to the "measurement"
402 element to indicate the RMS error in time. "timeError" indicates an
403 upper bound on the time RMS error in seconds.
405 The "timeError" attribute does not apply where multiple samples of a
406 measurement is taken over time. If multiple samples are taken, each
407 SHOULD be included in a different "measurement" element.
409 4.3. Measurement Request
411 A measurement request is used by a protocol peer to describe a set of
412 measurement data that it desires. A "measurementRequest" element is
413 defined that can be included in a protocol exchange.
415 For instance, a LIS can use a measurement request in HELD responses.
416 If the LIS is unable to provide location information, but it believes
417 that a particular measurement type would enable it to provide a
418 location, it can include a measurement request in an error response.
420 The "measurement" element of the measurement request identifies the
421 type of measurement that is requested. The "type" attribute of this
422 element indicates the type of measurement, as identified by an XML
423 qualified name. An optional "samples" attribute indicates how many
424 samples of the identified measurement are requested.
426 The "measurement" element can be repeated to request multiple (or
427 alternative) measurement types.
429 Additional XML content might be defined for a particular measurement
430 type that is used to further refine a request. These elements either
431 constrain what is requested or specify optional components of the
432 measurement data that are needed. These are defined along with the
433 specific measurement type.
435 In the HELD protocol, the inclusion of a measurement request in a
436 error response with a code of "locationUnknown" indicates that the
437 LIS believes that providing the indicated measurements would increase
438 the likelihood of a subsequent request being successful.
440 The following example shows a HELD error response that indicates that
441 WiFi measurement data would be useful if a later request were made.
442 Additional elements indicate that received signal strength for an
443 802.11n access point is requested.
445
447 Insufficient measurement data
448
451
452 n
453 wifi:rcpi
454
455
456
458 Figure 3: HELD Error Requesting Measurement Data
460 A measurement request that is included in other HELD messages has
461 undefined semantics and can be safely ignored. Other specifications
462 might define semantics for measurement requests under other
463 conditions.
465 4.4. Identifying Location Provenance
467 An extension is made to the PIDF-LO [RFC4119] that allows a location
468 recipient to identify the source (or sources) of location information
469 and the measurement data that was used to determine that location
470 information.
472 The "source" element is added to the "geopriv" element of the
473 PIDF-LO. This element does not identify specific entities. Instead,
474 it identifies the type of source.
476 The following types of measurement source are identified:
478 lis: Location information is based on measurement data that the LIS
479 or sources that it trusts have acquired. This label might be used
480 if measurement data provided by the Device has been completely
481 validated by the LIS.
483 device: Location information is based on measurement data that the
484 Device has provided to the LIS.
486 other: Location information is based on measurement data that a
487 third party has provided. This might be an authorized third party
488 that uses identity parameters
489 [I-D.ietf-geopriv-held-identity-extensions] or any other entity.
491 No assertion is made about the veracity of the measurement data from
492 sources other than the LIS. A combination of tags MAY be included to
493 indicate that measurement data from both sources was used.
495 For example, the first tuple of the following PIDF-LO indicates that
496 measurement data from a LIS and a device was combined to produce the
497 result, the second tuple was produced by the LIS alone.
499
505
506
507
508
509
510 7.34324 134.47162
511
512 850.24
513
514
515
516
517 OTDOA
518 lis device
519
520
521
522
523
524
525
526
527 7.34379 134.46484
528
529 9000
530
531
532
533
534 Cell
535 lis
536
537
538
539
541 5. Location-Related Measurement Data Types
543 This document defines location-related measurement data types for a
544 range of common network types.
546 All included measurement data definitions allow for arbitrary
547 extension in the corresponding schema. As new parameters that are
548 applicable to location determination are added, these can be added as
549 new XML elements in a unique namespace. Though many of the
550 underlying protocols support extension, creation of specific XML-
551 based extensions to the measurement format is favored over
552 accomodating protocol-specific extensions in generic containers.
554 5.1. LLDP Measurements
556 Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent
557 between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet,
558 WiFi, 802.16). These messages all contain identification information
559 for the sending node, which can be used to determine location
560 information. A Device that receives LLDP messages can report this
561 information as a location-related measurement to the LIS, which is
562 then able to use the measurement data in determining the location of
563 the Device.
565 Note: The LLDP extensions defined in LLDP Media Endpoint Discovery
566 (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location
567 information directly from an LLDP endpoint. Where this
568 information is available, it might be unnecessary to use any other
569 form of location configuration.
571 Values are provided as hexadecimal sequences. The Device MUST report
572 the values directly as they were provided by the adjacent node.
573 Attempting to adjust or translate the type of identifier is likely to
574 cause the measurement data to be useless.
576 Where a Device has received LLDP messages from multiple adjacent
577 nodes, it should provide information extracted from those messages by
578 repeating the "lldp" element.
580 An example of an LLDP measurement is shown in Figure 4. This shows
581 an adjacent node (chassis) that is identified by the IP address
582 192.0.2.45 (hexadecimal c000022d) and the port on that node is
583 numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).
585
587
588 c000022d
589 a2
590
591
593 Figure 4: LLDP Measurement Example
595 IEEE 802 Devices that are able to obtain information about adjacent
596 network switches and their attachment to them by other means MAY use
597 this data type to convey this information.
599 5.2. DHCP Relay Agent Information Measurements
601 The DHCP Relay Agent Information option [RFC3046] provides
602 measurement data about the network attachment of a Device. This
603 measurement data can be included in the "dhcp-rai" element.
605 The elements in the DHCP relay agent information options are opaque
606 data types assigned by the DHCP relay agent. The three items are all
607 optional: circuit identifier ("circuit", [RFC3046]), remote
608 identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier
609 ("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier
610 has an associated enterprise number [IANA.enterprise] as an XML
611 attribute.
613
615
616 ::ffff:192.0.2.158
617 108b
618
619
621 Figure 5: DHCP Relay Agent Information Measurement Example
623 The "giaddr" is specified as a dotted quad IPv4 address or an RFC
624 4291 [RFC4291] IPv6 address, using the forms defined in [RFC3986].
625 The enterprise number is specified as a decimal integer. All other
626 information is included verbatim from the DHCP request in hexadecimal
627 format.
629 5.3. 802.11 WLAN Measurements
631 In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to
632 provide information about the access point (AP) that it is attached
633 to, or other WiFi points it is able to see. This is provided using
634 the "wifi" element, as shown in Figure 6, which shows a single
635 complete measurement for a single access point.
637
639
640 Intel(r)PRO/Wireless 2200BG
641
642 AB-CD-EF-AB-CD-EF
643 example
644 5
645
646
647 -34.4 150.8
648
649
650 a
651 5
652 2
653 2
654 2.56e-9
655
656 23
657 5
658 -59
659 23
660
661
662 10
663 9
664 -98.5
665 7.5
666
667
668
669
671 Figure 6: 802.11 WLAN Measurement Example
673 A wifi element is made up of one or more access points, and an
674 optional "nicType" element. Each access point is described using the
675 "ap" element, which is comprised of the following fields:
677 bssid: The basic service set identifier. In an Infrastructure BSS
678 network, the bssid is the 48 bit MAC address of the access point.
680 The "verified" attribute of this element describes whether the
681 device has verified the MAC address or it authenticated the access
682 point or the network operating the access point (for example, a
683 captive portal accessed through the access point has been
684 authenticated). This attributes defaults to a value of "false"
685 when omitted.
687 ssid: The service set identifier (SSID) for the wireless network
688 served by the access point.
690 The SSID is a 32-octet identifier that is commonly represented as
691 a ASCII [RFC0020] or UTF-8 [RFC3629] encoded string. To represent
692 octets that cannot be directly included in an XML element,
693 escaping is used. Sequences of octets that do not represent a
694 valid UTF-8 encoding can be escaped using a backslash ('\')
695 followed by two case-insensitive hexadecimal digits representing
696 the value of a single octet.
698 The canonical or value-space form of an SSID is a sequence of up
699 to 32 octets that is produced from the concatenation of UTF-8
700 encoded sequences of unescaped characters and octets derived from
701 escaped components.
703 channel: The channel number (frequency) that the access point
704 operates on.
706 location: The location of the access point, as reported by the
707 access point. This element contains any valid location, using the
708 rules for a "location-info" element, as described in [RFC5491].
710 type: The network type for the network access. This element
711 includes the alphabetic suffix of the 802.11 specification that
712 introducted the radio interface, or PHY; e.g. "a", "b", "g", or
713 "n".
715 band: The frequency band for the radio, in gigahertz (GHz). 802.11
716 [IEEE.80211] specifies PHY layers that use 2.4, 3.7 and 5
717 gigahertz frequency bands.
719 regclass: The regulatory domain and class. The "country" attribute
720 optionally includes the applicable two character country
721 identifier (dot11CountryString), which can be followed by an 'O',
722 'I' or 'X'. The element text content includes the value of the
723 regulatory class: an 8-bit integer in decimal form.
725 antenna: The antenna identifier for the antenna that the access
726 point is using to transmit the measured signals.
728 flightTime: Flight time is the difference between the time of
729 departure (TOD) of signal from a transmitting station and time of
730 arrival (TOA) of signal at a receiving station, as defined in
731 [IEEE.80211V]. Measurement of this value requires that stations
732 synchronize their clocks. This value can be measured by access
733 point or Device; because the flight time is assumed to be the same
734 in either direction - aside from measurement errors - only a
735 single element is provided. This element includes optional
736 "rmsError" and "samples" attributes. RMS error might be derived
737 from the reported RMS error in TOD and TOA.
739 apSignal: Measurement information for the signal transmitted by the
740 access point, as observed by the Device. Some of these values are
741 derived from 802.11v [IEEE.80211V] messages exchanged between
742 Device and access point. The contents of this element include:
744 transmit: The transmit power reported by the access point, in dB.
746 gain: The gain of the access point antenna reported by the access
747 point, in dB.
749 rcpi: The received channel power indicator for the access point
750 signal, as measured by the Device. This value SHOULD be in
751 units of dBm (with RMS error in dB). If power is measured in a
752 different fashion, the "dBm" attribute MUST be set to "false".
753 Signal strength reporting on current hardware uses a range of
754 different mechanisms; therefore, the value of the "nicType"
755 element SHOULD be included if the units are not known to be in
756 dBm and the value reported by the hardware should be included
757 without modification. This element includes optional
758 "rmsError" and "samples" attributes.
760 rsni: The received signal to noise indicator in dBm. This
761 element includes optional "rmsError" and "samples" attributes.
763 deviceSignal: Measurement information for the signal transmitted by
764 the device, as reported by the access point. This element
765 contains the same child elements as the "ap" element, with the
766 access point and Device roles reversed.
768 All elements are optional except for "bssid".
770 The "nicType" element is used to specify the make and model of the
771 wireless network interface in the Device. Different 802.11 chipsets
772 report measurements in different ways, so knowing the network
773 interface type aids the LIS in determining how to use the provided
774 measurement data. The content of this field is unconstrained and no
775 mechanisms are specified to ensure uniqueness.
777 5.3.1. Wifi Measurement Requests
779 Two elements are defined for requesting WiFi measurements in a
780 measurement request:
782 type: The "type" element identifies the desired type (or types that
783 are requested.
785 parameter: The "parameter" element identifies an optional
786 measurements are requested for each measured access point. An
787 element is identified by its qualified name. The optional
788 "context" parameter can be used to specify if an element is
789 included as a child of the "ap" or "device" elements; omission
790 indicates that it applies to both.
792 Multiple types or parameters can be requested by repeating either
793 element.
795 5.4. Cellular Measurements
797 Cellular Devices are common throughout the world and base station
798 identifiers can provide a good source of coarse location information.
799 This information can be provided to a LIS run by the cellar operator,
800 or may be provided to an alternative LIS operator that has access to
801 one of several global cell-id to location mapping databases.
803 A number of advanced location determination methods have been
804 developed for cellular networks. For these methods a range of
805 measurement parameters can be collected by the network, Device, or
806 both in cooperation. This document includes a basic identifier for
807 the wireless transmitter only; future efforts might define additional
808 parameters that enable more accurate methods of location
809 determination.
811 The cellular measurement set allows a Device to report to a LIS any
812 LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10)
813 cells that it is able to observe. Cells are reported using their
814 global identifiers. All 3GPP cells are identified by public land
815 mobile network (PLMN), which is formed of mobile country code (MCC)
816 and mobile network code (MNC); specific fields are added for each
817 network type.
819 Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003].
820 Bit-level formats for CDMA cell identifiers are described in
821 [TIA-2000.5]; decimal representations are used.
823 MCC and MNC are provided as digit sequences; a leading zero in an MCC
824 or MNC is significant. All other values are decimal integers.
826
828
829
830 4652080936424
831
832
833 4650610736789
834
835
836
838 Long term evolution (LTE) cells are identified by a 28-bit cell
839 identifier (eucid).
841 Figure 7: Example LTE Cellular Measurement
843
845
846
847 46520
848 200065000
849
850
851 46506
852 1638332767
853
854
855
857 Universal mobile telephony service (UMTS) cells are identified by 16-
858 bit radio network controller (rnc) id and a 16-bit cell id (cid).
860 Figure 8: Example UMTS Cellular Measurement
861
863
864
865 46506
866 1638332767
867
868
869
871 Global System for Mobile communication (GSM) cells are identified by
872 a 16-bit location area code (lac) and 16-bit cell id (cid).
874 Figure 9: Example GSM Cellular Measurement
876
878
879
880 15892472312
881
882
883 15892472313
884
885
886
888 Code division multiple access (CDMA) cells are not identified by
889 PLMN, instead these usea 15-bit system id (sid), a 16-bit network id
890 (nid) and a 16-bit base station id (baseid).
892 Figure 10: Example CDMA Cellular Measurement
894 In general a cellular Device will be attached to the cellular network
895 and so the notion of a serving cell exists. Cellular network also
896 provide overlap between neighbouring sites, so a mobile Device can
897 hear more than one cell. The measurement schema supports sending
898 both the serving cell and any other cells that the mobile might be
899 able to hear. In some cases, the Device may simply be listening to
900 cell information without actually attaching to the network, mobiles
901 without a SIM are an example of this. In this case the Device may
902 simply report cells it can hear without flagging one as a serving
903 cell. An example of this is shown in Figure 11.
905
907
908
909 46520
910 200065000
911
912
913 46506
914 1638332767
915
916
917
919 Figure 11: Example Observed Cellular Measurement
921 5.4.1. Cellular Measurement Requests
923 Two elements can be used in measurement requests for cellular
924 measurements:
926 type: A label indicating the type of identifier to provide: one of
927 "gsm", "umts", "lte", or "cdma".
929 network: The network portion of the cell identifier. For 3GPP
930 networks, this is the combination of MCC and MNC; for CDMA, this
931 is the network identifier.
933 Multiple identifier types or networks can be identified by repeating
934 either element.
936 5.5. GNSS Measurements
938 GNSS use orbiting satellites to transmit signals. A Device with a
939 GNSS receiver is able to take measurements from the satellite
940 signals. The results of these measurements can be used to determine
941 time and the location of the Device.
943 Determining location and time in autonomous GNSS receivers follows
944 three steps:
946 Signal acquisition: During the signal acquisition stage, the
947 receiver searches for the repeating code that is sent by each GNSS
948 satellite. Successful operation typically requires measurement
949 data for a minimum of 5 satellites. At this stage, measurement
950 data is available to the Device.
952 Navigation message decode: Once the signal has been acquired, the
953 receiver then receives information about the configuration of the
954 satellite constellation. This information is broadcast by each
955 satellite and is modulated with the base signal at a low rate; for
956 instance, GPS sends this information at about 50 bits per second.
958 Calculation: The measurement data is combined with the data on the
959 satellite constellation to determine the location of the receiver
960 and the current time.
962 A Device that uses a GNSS receiver is able to report measurements
963 after the first stage of this process. A LIS can use the results of
964 these measurements to determine a location. In the case where there
965 are fewer results available than the optimal minimum, the LIS might
966 be able to use other sources of measurement information and combine
967 these with the available measurement data to determine a position.
969 Note: The use of different sets of GNSS _assistance data_ can
970 reduce the amount of time required for the signal acquisition
971 stage and obviate the need for the receiver to extract data on the
972 satellite constellation. Provision of assistance data is outside
973 the scope of this document.
975 Figure 12 shows an example of GNSS measurement data. The measurement
976 shown is for the GPS system and includes measurement data for three
977 satellites only.
979
981
983
984 499.9395
985 0.87595747
986 45
987
988
989 378.2657
990 0.56639479
991 52
992
993
994 -633.0309
995 0.57016835
996 48
997
998
999
1001 Figure 12: Example GNSS Measurement
1003 Each "gnss" element represents a single set of GNSS measurement data,
1004 taken at a single point in time. Measurements taken at different
1005 times can be included in different "gnss" elements to enable
1006 iterative refinement of results.
1008 GNSS measurement parameters are described in more detail in the
1009 following sections.
1011 5.5.1. GNSS System and Signal
1013 The GNSS measurement structure is designed to be generic and to apply
1014 to different GNSS types. Different signals within those systems are
1015 also accounted for and can be measured separately.
1017 The GNSS type determines the time system that is used. An indication
1018 of the type of system and signal can ensure that the LIS is able to
1019 correctly use measurements.
1021 Measurements for multiple GNSS types and signals can be included by
1022 repeating the "gnss" element.
1024 This document creates an IANA registry for GNSS types. Two satellite
1025 systems are registered by this document: GPS [GPS.ICD] and Galileo
1026 [Galileo.ICD]. Details for the registry are included in Section 9.1.
1028 5.5.2. Time
1030 Each set of GNSS measurements is taken at a specific point in time.
1031 The "time" attribute is used to indicate the time that the
1032 measurement was acquired, if the receiver knows how the time system
1033 used by the GNSS relates to UTC time.
1035 Alternative to (or in addition to) the measurement time, the
1036 "gnssTime" element MAY be included. The "gnssTime" element includes
1037 a relative time in milliseconds using the time system native to the
1038 satellite system. For the GPS satellite system, the "gnssTime"
1039 element includes the time of week in milliseconds. For the Galileo
1040 system, the "gnssTime" element includes the time of day in
1041 milliseconds.
1043 The accuracy of the time measurement provided is critical in
1044 determining the accuracy of the location information derived from
1045 GNSS measurements. The receiver SHOULD indicate an estimated time
1046 error for any time that is provided. An RMS error can be included
1047 for the "gnssTime" element, with a value in milliseconds.
1049 5.5.3. Per-Satellite Measurement Data
1051 Multiple satellites are included in each set of GNSS measurements
1052 using the "sat" element. Each satellite is identified by a number in
1053 the "num" attribute. The satellite number is consistent with the
1054 identifier used in the given GNSS.
1056 Both the GPS and Galileo systems use satellite numbers between 1 and
1057 64.
1059 The GNSS receiver measures the following parameters for each
1060 satellite:
1062 doppler: The observed Doppler shift of the satellite signal,
1063 measured in meters per second. This is converted from a value in
1064 Hertz by the receiver to allow the measurement to be used without
1065 knowledge of the carrier frequency of the satellite system. This
1066 value includes an optional RMS error attribute, also measured in
1067 meters per second.
1069 codephase: The observed code phase for the satellite signal,
1070 measured in milliseconds. This is converted the system-specific
1071 value of chips or wavelengths into a system independent value.
1072 Larger values indicate larger distances from satellite to
1073 receiver. This value includes an optional RMS error attribute,
1074 also measured in milliseconds.
1076 cn0: The signal to noise ratio for the satellite signal, measured in
1077 decibel-Hertz (dB-Hz). The expected range is between 20 and 50
1078 dB-Hz.
1080 mp: An estimation of the amount of error that multipath signals
1081 contribute in metres. This parameter is optional.
1083 cq: An indication of the carrier quality. Two attributes are
1084 included: "continuous" may be either "true" or "false"; direct may
1085 be either "direct" or "inverted". This parameter is optional.
1087 adr: The accumulated Doppler range, measured in metres. This
1088 parameter is optional and is not useful unless multiple sets of
1089 GNSS measurements are provided or differential positioning is
1090 being performed.
1092 All values are converted from measures native to the satellite system
1093 to generic measures to ensure consistency of interpretation. Unless
1094 necessary, the schema does not constrain these values.
1096 5.5.4. GNSS Measurement Requests
1098 Measurement requests can include a "gnss" element, which includes the
1099 "system" and "signal" attributes. Multiple elements can be included
1100 to indicate a requests for GNSS measurements from multiple systems or
1101 signals.
1103 5.6. DSL Measurements
1105 Digital Subscriber Line (DSL) networks rely on a range of network
1106 technology. DSL deployments regularly require cooperation between
1107 multiple organizations. These fall into two broad categories:
1108 infrastructure providers and Internet service providers (ISPs).
1109 Infrastructure providers manage the bulk of the physical
1110 infrastructure including cabling. End users obtain their service
1111 from an ISP, which manages all aspects visible to the end user
1112 including IP address allocation and operation of a LIS. See
1113 [DSL.TR025] and [DSL.TR101] for further information on DSL network
1114 deployments and the parameters that are available.
1116 Exchange of measurement information between these organizations is
1117 necessary for location information to be correctly generated. The
1118 ISP LIS needs to acquire location information from the infrastructure
1119 provider. However, the infrastructure provider has no knowledge of
1120 Device identifiers, it can only identify a stream of data that is
1121 sent to the ISP. This is resolved by passing measurement data
1122 relating to the Device to a LIS operated by the infrastructure
1123 provider.
1125 5.6.1. L2TP Measurements
1127 Layer 2 Tunneling Protocol (L2TP) is a common means of linking the
1128 infrastructure provider and the ISP. The infrastructure provider LIS
1129 requires measurement data that identifies a single L2TP tunnel, from
1130 which it can generate location information. Figure 13 shows an
1131 example L2TP measurement.
1133
1135
1136
1137 192.0.2.10
1138 192.0.2.61
1139 528
1140
1141
1142
1144 Figure 13: Example DSL L2TP Measurement
1146 5.6.2. RADIUS Measurements
1148 When authenticating network access, the infrastructure provider might
1149 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or
1150 Access Node (AN). These messages provide the ISP RADIUS server with
1151 an identifier for the DSLAM or AN, plus the slot and port that the
1152 Device is attached on. These data can be provided as a measurement,
1153 which allows the infrastructure provider LIS to generate location
1154 information.
1156 The format of the AN, slot and port identifiers are not defined in
1157 the RADIUS protocol. Slot and port together identify a circuit on
1158 the AN, analogous to the circuit identifier in [RFC3046]. These
1159 items are provided directly, as they were in the RADIUS message. An
1160 example is shown in Figure 14.
1162
1164
1165 AN-7692
1166 3
1167 06
1168
1169
1171 Figure 14: Example DSL RADIUS Measurement
1172 5.6.3. Ethernet VLAN Tag Measurements
1174 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM)
1175 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is
1176 used to identify the incoming residential circuit, while the S-TAG is
1177 used to identify the DSLAM or AN. The C-TAG and S-TAG together can
1178 be used to identify a single point of network attachment. An example
1179 is shown in Figure 15.
1181
1183
1184 613
1185 1097
1186
1187
1189 Figure 15: Example DSL VLAN Tag Measurement
1191 Alternatively, the C-TAG can be replaced by data on the slot and port
1192 that the Device is attached to. This information might be included
1193 in RADIUS requests that are proxied from the infrastructure provider
1194 to the ISP RADIUS server.
1196 5.6.4. ATM Virtual Circuit Measurements
1198 An ATM virtual circuit can be employed between the ISP and
1199 infrastructure provider. Providing the virtual port ID (VPI) and
1200 virtual circuit ID (VCI) for the virtual circuit gives the
1201 infrastructure provider LIS the ability to identify a single data
1202 stream. A sample measurement is shown in Figure 16.
1204
1206
1207 55
1208 6323
1209
1210
1212 Figure 16: Example DSL ATM Measurement
1214 6. Privacy Considerations
1216 Location-related measurement data can be as privacy sensitive as
1217 location information.
1219 Measurement data is effectively equivalent to location information if
1220 the contextual knowledge necessary to generate one from the other is
1221 readily accessible. Even where contextual knowledge is difficult to
1222 acquire, there can be no assurance that an authorized recipient of
1223 the contextual knowledge is also authorized to receive location
1224 information.
1226 In order to protect the privacy of the subject of location-related
1227 measurement data, this implies that measurement data is protected
1228 with the same degree of protection as location information.
1230 6.1. Measurement Data Privacy Model
1232 It is less desirable to distribute measurement data in the same
1233 fashion as location information. Measurement data is less useful to
1234 location recipients than location information. Therefore, a simple
1235 distribution model is desirable.
1237 In this simple model, the Device is the only entity that is able to
1238 distribute measurement data. To use an analogy from the GEOPRIV
1239 architecture, the Device - as the Location Generator (or the
1240 Measurement Data Generator) - is the sole entity that can assume the
1241 roles of Rule Maker and Location Server.
1243 No entity is permitted to redistribute measurement data. The Device
1244 directs other entities in how measurement data is used and retained.
1246 6.2. LIS Privacy Requirements
1248 A LIS MUST NOT reveal location-related measurement data or location
1249 information based on measurement data to any other entity unless
1250 directed to do so by the Device.
1252 By adding measurement data to a request for location information, the
1253 Device implicitly grants permission for the LIS to generate the
1254 requested location information using the measurement data.
1255 Permission to use this data for any other purpose is not implied.
1257 As long as measurement data is only used in serving the request that
1258 contains it, rules regarding data retention are not necessary. A LIS
1259 MUST discard location-related measurement data after servicing a
1260 request, unless the Device grants permission to use that information
1261 for other purposes.
1263 6.3. Measurement Data and Location URIs
1265 A LIS MAY use measurement data provided by the Device to serve
1266 requests to location URIs, if the Device permits it. A Device
1267 permits this by including measurement data in a request that
1268 explcitly requests a location URI. By requesting a location URI, the
1269 Device grants permission for the LIS to use the measurement data in
1270 serving requests to that URI.
1272 Note: In HELD, the "any" type is not an explicit request for a
1273 location URI, though a location URI might be provided.
1275 The usefulness of measurement data that is provided in this fashion
1276 is limited. The measurement data is only valid at the time that it
1277 was acquired by the Device. At the time that a request is made to a
1278 location URI, the Device might have moved, rendering the measurement
1279 data incorrect.
1281 A Device is able to explicitly limit the time that a LIS retains
1282 measurement data by adding an expiry time to the measurement data,
1283 see Section 4.1.2.
1285 6.4. Third-Party-Provided Measurement Data
1287 An authorized third-party request for the location of a Device (see
1288 [I-D.ietf-geopriv-held-identity-extensions]) can include location-
1289 related measurement data. This is possible where the third-party is
1290 able to make observations about the Device.
1292 A third-party that provides measurement data MUST be authorized to
1293 provide the specific measurement for the identified device. A third-
1294 party MUST either be trusted by the LIS for the purposes of providing
1295 measurement data of the provided type, or the measurement data MUST
1296 be validated (see Section 7.2.1) before being used.
1298 How a third-party authenticates its identity or gains authorization
1299 to use measurement data is not covered by this document.
1301 7. Security Considerations
1303 Use of location-related measurement data has privacy considerations
1304 that are discussed in Section 6.
1306 7.1. Threat Model
1308 The threat model for location-related measurement data concentrates
1309 on the Device providing falsified, stolen or incorrect measurement
1310 data.
1312 A Device that provides location location-related measurement data
1313 might use data to:
1315 o acquire the location of another Device, without authorization;
1317 o extract information about network topology; or
1319 o coerce the LIS into providing falsified location information based
1320 on the measurement data.
1322 Location-related measurement data describes the physical environment
1323 or network attachment of a Device. A third party adversary in the
1324 proximity of the Device might be able to alter the physical
1325 environment such that the Device provides measurement data that is
1326 controlled by the third party. This might be used to indirectly
1327 control the location information that is derived from measurement
1328 data.
1330 7.1.1. Acquiring Location Information Without Authorization
1332 Requiring authorization for location requests is an important part of
1333 privacy protections of a location protocol. A location configuration
1334 protocol usually operates under a restricted policy that allows a
1335 requester to obtain their own location. HELD identity extensions
1336 [I-D.ietf-geopriv-held-identity-extensions] allows other entities to
1337 be authorized, conditional on a Rule Maker providing sufficient
1338 authorization.
1340 The intent of these protections is to ensure that a location
1341 recipient is authorized to acquire location information. Location-
1342 related measurement data could be used by an attacker to circumvent
1343 such authorization checks if the association between measurement data
1344 and Target Device is not validated by a LIS.
1346 A LIS can be coerced into providing location information for a Device
1347 that a location recipient is not authorized to receive. A request
1348 identifies one Device (implicitly or explicitly), but measurement
1349 data is provided for another Device. If the LIS does not check that
1350 the measurement data is for the identified Device, it could
1351 incorrectly authorize the request.
1353 By using unvalidated measurement data to generate a response, the LIS
1354 provides information about a Device without appropriate
1355 authorization.
1357 The feasibility of this attack depends on the availability of
1358 information that links a Device with measurement data. In some
1359 cases, measurement data that is correlated with a target is readily
1360 available. For instance, LLDP measurements (Section 5.1) are
1361 broadcast to all nodes on the same network segment. An attacker on
1362 that network segment can easily gain measurement data that relates a
1363 Device with measurements.
1365 For some types of measurement data, it's necessary for an attacker to
1366 know the location of the target in order to determine what
1367 measurements to use. This attack is meaningless for types of
1368 measurement data that require that the attacker first know the
1369 location of the target before measurement data can be acquired or
1370 fabricated. GNSS measurements (Section 5.5) share this trait with
1371 many wireless location determination methods.
1373 7.1.2. Extracting Network Topology Data
1375 Allowing requests with measurements might be used to collect
1376 information about a network topology. This is possible if requests
1377 containing measurements are permitted.
1379 Network topology can be considered sensitive information by a network
1380 operator for commercial or security reasons. While it is impossible
1381 to completely prevent a Device from acquiring some knowledge of
1382 network topology if a location service is provided, a network
1383 operator might desire to limit how much of this information is made
1384 available.
1386 Mapping a network topology does not require that an attacker be able
1387 to associate measurement data with a particular Device. If a
1388 requester is able to try a number of measurements, it is possible to
1389 acquire information about network topology.
1391 It is not even necessary that the measurements are valid; random
1392 guesses are sufficient, provided that there is no penalty or cost
1393 associated with attempting to use the measurements.
1395 7.1.3. Lying By Proxy
1397 Location information is a function of its inputs, which includes
1398 measurement data. Thus, falsified measurement data can be used to
1399 alter the location information that is provided by a LIS.
1401 Some types of measurement data are relatively easy to falsify in a
1402 way that the resulting location information to be selected with
1403 little or no error. For instance, GNSS measurements are easy to use
1404 for this purpose because all the contextual information necessary to
1405 calculate a position using measurements is broadcast by the
1406 satellites [HARPER].
1408 An attacker that falsifies measurement data gains little if they are
1409 the only recipients of the result. The attacker knows that the
1410 location information is bad. The attacker only gains if the
1411 information can somehow be attributed to the LIS by another location
1412 recipient.
1414 A recipient might evaluate the trustworthiness of the location
1415 information based on the credibility of its source. By coercing the
1416 LIS into providing falsified location information, any credibility
1417 that the LIS might have - that the attacker does not - is gained by
1418 the attacker.
1420 A third-party that is reliant on the integrity of the location
1421 information might base an evaluation of the credibility of the
1422 information on the source of the information. If that third party is
1423 able to attribute location information to the LIS, then an attacker
1424 might gain.
1426 Location information that is provided to the Device without any means
1427 to identify the LIS as its source is not subject to this attack. The
1428 Device is identified as the source of the data when it distributes
1429 the location information to location recipients.
1431 An attacker gains if they are able to coerce the LIS into providing
1432 location information based on falsified measurement data and that
1433 information can be attributed to the LIS.
1435 Location information is attributed to the LIS either through the use
1436 of digital signatures or by having the location recipient directly
1437 interact with the LIS. A LIS that digitally signs location
1438 information becomes identifiable as the source of the data.
1439 Similarly, the LIS is identified as a source of data if a location
1440 recipient acquires information directly from a LIS using a location
1441 URI.
1443 7.1.4. Measurement Replay
1445 The value of some measured properties do not change over time for a
1446 single location. This allows for simple replay attacks, where an
1447 attacker acquires measurements that can later be used without being
1448 detected as being invalid.
1450 Measurement data is frequently an observation of an time-invariant
1451 property of the environment at the subject location. For
1452 measurements of this nature, nothing in the measurement itself is
1453 sufficient proof that the Device is present at the resulting
1454 location. Measurement data might have been previously acquired and
1455 reused.
1457 For instance, the identity of a radio transmitter, if broadcast by
1458 that transmitter, can be collected and stored. An attacker that
1459 wishes it known that they exist at a particular location, can claim
1460 to observe this transmitter at any time. Nothing inherent in the
1461 claim reveals it to be false.
1463 For properties of a network, time-invariance is often directly as a
1464 result of the practicalities of operating the network. Limiting the
1465 changes to a network ensures greater consistency of service. A
1466 largely static network also greatly simplifies the data management
1467 tasks involved with providing a location service.
1469 7.1.5. Environment Spoofing
1471 Some types of measurement data can be altered or influenced by a
1472 third party so that a Device. If it is possible for a third party to
1473 alter the measured phenomenon, then any location information that is
1474 derived from this data can be indirectly influenced.
1476 Altering the environment in this fashion might not require
1477 involvement with either Device or LIS. Measurement that is passive -
1478 where the Device observes a signal or other phenomenon without direct
1479 interaction - are most susceptible to alteration by third parties.
1481 Measurement of radio signal characteristics is especially vulnerable
1482 since an adversary need only be in the general vicinity of the Device
1483 and be able to transmit a signal. For instance, a GNSS spoofer is
1484 able to produce fake signals that claim to be transmitted by any
1485 satellite or set of satellites (see [GPS.SPOOF]).
1487 Measurements that require direct interaction increases the complexity
1488 of the attack. For measurements relating to the communication
1489 medium, a third party cannot avoid direct interaction, they need only
1490 be on the comminications path (that is, man in the middle).
1492 Even if the entity that is interacted with is authenticated, this
1493 does not provide any assurance about the integrity of measurement
1494 data. For instance, the Device might authenticate the identity of a
1495 radio transmitter through the use of cryptographic means and obtain
1496 signal strength measurements for that transmitter. Radio signal
1497 strength is trivial for an attacker to increase simply by receiving
1498 and amplifying the raw signal; it is not necessary for the attacker
1499 to be able to understand the signal content.
1501 Note: This particular "attack" is more often completely legitimate.
1502 Radio repeaters are commonplace mechanism used to increase radio
1503 coverage.
1505 Attacks that rely on altering the observed environment of a Device
1506 require countermeasures that affect the measurement process. For
1507 radio signals, countermeasures could include the use of authenticated
1508 signals, altered receiver design. In general, countermeasures are
1509 highly specific to the individual measurement process. An exhaustive
1510 discussion of these issues is left to the relevant literature for
1511 each measurement technology.
1513 A Device that provides measurement data is assumed to be responsible
1514 for applying appropriate countermeasures against this type of attack.
1516 For a Device that is the ultimate recipient of location information
1517 derived from measurement data, a LIS might choose to provide location
1518 information without any validation. The responsibility for ensuring
1519 the veracity of the measurement data lies with the Device.
1521 Measurement data that is susceptible to this sort of influence MUST
1522 be treated as though it were produced by an untrusted Device for
1523 those cases where a location recipient might attribute the location
1524 information to the LIS. Such measurement data MUST be subjected to
1525 the same validation as for other types of attacks that rely on
1526 measurement falsification.
1528 Note: Altered measurement data might be provided by a Device that
1529 has no knowledge of the alteration. Thus, an otherwise trusted
1530 Device might still be an unreliable source of measurement data.
1532 7.2. Mitigation
1534 The following measures can be applied to limit or prevent attacks.
1535 The effectiveness of each depends on the type of measurement data and
1536 how that measurement data is acquired.
1538 Two general approaches are identified for dealing with untrusted
1539 measurement data:
1541 1. Require independent validation of measurement data or the
1542 location information that is produced.
1544 2. Identify the types of sources that provided the measurement data
1545 that location information was derived from.
1547 This section goes into more detail on the different forms of
1548 validation in Section 7.2.1, Section 7.2.2, and Section 7.2.3. The
1549 impact of attributing location information to sources is discussed in
1550 more detail in Section 7.2.4.
1552 7.2.1. Measurement Validation
1554 Detecting that measurement data has been falsified is difficult in
1555 the absence of integrity mechanisms.
1557 Independent confirmation of the veracity of measurement data ensures
1558 that the measurement is accurate and that it applies to the correct
1559 Device. By gathering the same measurement data from a trusted and
1560 independent source, the LIS is able to check that the measurement
1561 data is correct.
1563 Measurement information might contain no inherent indication that it
1564 is falsified. On the contrary, it can be difficult to obtain
1565 information that would provide any degree of assurance that the
1566 measurement device is physically at any particular location.
1567 Measurements that are difficult to verify require other forms of
1568 assurance before they can be used.
1570 7.2.1.1. Effectiveness
1572 Measurement validation MUST be used if measurement data for a
1573 particular Device can be easily acquired by unauthorized location
1574 recipients, as described in Section 7.1.1. This prevents
1575 unauthorized access to location information using measurement data.
1577 Validation of measurement data can be significantly more effective
1578 than independent acquisition of the same. For instance, a Device in
1579 a large Ethernet network could provide a measurement indicating its
1580 point of attachment using LLDP measurements. For a LIS, acquiring
1581 the same measurement data might require a request to all switches in
1582 that network. With the measurement data, validation can target the
1583 identified switch with a specific query.
1585 Validation is effective in identifying falsified measurement data
1586 (Section 7.1.3), including attacks involving replay of measurement
1587 data (Section 7.1.4). Validation also limits the amount of network
1588 topology information (Section 7.1.2) made available to Devices to
1589 that portion of the network topology that they are directly attached.
1591 Measurement validation has no effect if the underlying effect is
1592 being spoofed (Section 7.1.5).
1594 7.2.1.2. Limitations (Unique Observer)
1596 A Device is often in a unique position to make a measurement. It
1597 alone occupies the point in space-time that the location
1598 determination process seeks to determine. The Device becomes a
1599 unique observer for a particular property.
1601 The ability of the Device to become a unique observer makes the
1602 Device invaluable to the location determination process. As a unique
1603 observer, it also makes the claims of a Device difficult to validate
1604 and easily to spoof.
1606 As long as no other entity is capable of making the same
1607 measurements, there is also no other entity that can independently
1608 check that the measurements are correct and applicable to the Device.
1609 A LIS might be unable to validate all or part of the measurement data
1610 it receives from a unique observer. For instance, a signal strength
1611 measurement of the signal from a radio tower cannot be validated
1612 directly.
1614 Some portion of the measurement data might still be independently
1615 verified, even if all information cannot. In the previous example,
1616 the radio tower might be able to provide verification that the Device
1617 is present if it is able to observe a radio signal sent by the
1618 Device.
1620 If measurement data can only be partially validated, the extent to
1621 which it can be validated determines the effectiveness of validation
1622 against these attacks.
1624 The advantage of having the Device as a unique observer is that it
1625 makes it difficult for an attacker to acquire measurements without
1626 the assistance of the Device. Attempts to use measurements to gain
1627 unauthorized access to measurement data (Section 7.1.1) are largely
1628 ineffectual against a unique observer.
1630 7.2.2. Location Validation
1632 Location information that is derived from location-related
1633 measurement data can also be verified against trusted location
1634 information. Rather than validating inputs to the location
1635 determination process, suspect locations are identified at the output
1636 of the process.
1638 Trusted location information is acquired using sources of measurement
1639 data that are trusted. Untrusted location information is acquired
1640 using measurement data provided from untrusted sources, which might
1641 include the Device. These two locations are compared. If the
1642 untrusted location agrees with the trusted location, the untrusted
1643 location information is used.
1645 Algorithms for the comparison of location information are not
1646 included in this document. However, a simple comparison for
1647 agreement might require that the untrusted location be entirely
1648 contained within the uncertainty region of the trusted location.
1650 There is little point in using a less accurate, less trusted
1651 location. Untrusted location information that has worse accuracy
1652 than trusted information can be immediately discarded. There are
1653 multiple factors that affect accuracy, uncertainty and currency being
1654 the most important. How location information is compared for
1655 accuracy is not defined in this document.
1657 7.2.2.1. Effectiveness
1659 Location validation limits the extent to which falsified - or
1660 erroneous - measurement data can cause an incorrect location to be
1661 reported.
1663 Location validation can be more efficient than validation of inputs,
1664 particularly for a unique observer (Section 7.2.1.2).
1666 Validating location ensures that the Device is at or near the
1667 resulting location. Location validation can be used to limit or
1668 prevent all of the attacks identified in this document.
1670 7.2.2.2. Limitations
1672 The trusted location that is used for validation is always less
1673 accurate than the location that is being checked. The amount by
1674 which the untrusted location is more accurate, is the same amount
1675 that an attacker can exploit.
1677 For example, a trusted location might indicate a five kilometer
1678 radius uncertainty region. An untrusted location that describes a
1679 100 meter uncertainty within the larger region might be accepted as
1680 more accurate. An attacker might still falsify measurement data to
1681 select any location within the larger uncertainty region. While the
1682 100 meter uncertainty that is reported seems more accurate, a
1683 falsified location could be anywhere in the five kilometer region.
1685 Where measurement data might have been falsified, the actual
1686 uncertainty is effectively much higher. Local policy might allow
1687 differing degrees of trust to location information derived from
1688 untrusted measurement data. This might not be a boolean operation
1689 with only two possible outcomes: untrusted location information might
1690 be used entirely or not at all, or it could be combined with trusted
1691 location information with the degree to which each contributes based
1692 on a value set in local policy.
1694 7.2.3. Supporting Observations
1696 Replay attacks using previously acquired measurement data are
1697 particularly hard to detect without independent validation. Rather
1698 than validate the measurement data directly, supplementary data might
1699 be used to validate measurements or the location information derived
1700 from those measurements.
1702 These supporting observations could be used to convey information
1703 that provides additional assurance that the Device was acquired at a
1704 specific time and place. In effect, the Device is requested to
1705 provide proof of its presence at the resulting location.
1707 For instance, a Device that measures attributes of a radio signal
1708 could also be asked to provide a sample of the measured radio signal.
1709 If the LIS is able to observe the same signal, the two observations
1710 could be compared. Providing that the signal cannot be predicted in
1711 advance by the Device, this could be used to support the claim that
1712 the Device is able to receive the signal. Thus, the Device is likely
1713 to be within the range that the signal is transmitted. A LIS could
1714 use this to attribute a higher level of trust in the associated
1715 measurement data or resulting location.
1717 7.2.3.1. Effectiveness
1719 The use of supporting observations is limited by the ability of the
1720 LIS to acquire and validate these observations. The advantage of
1721 selecting observations independent of measurement data is that
1722 observations can be selected based on how readily available the data
1723 is for both LIS and Device. The amount and quality of the data can
1724 be selected based on the degree of assurance that is desired.
1726 Use of supporting observations is similar to both measurement
1727 validation and location validation. All three methods rely on
1728 independent validation of one or more properties. Applicability of
1729 each method is similar.
1731 Use of supporting observations can be used to limit or prevent all of
1732 the attacks identified in this document.
1734 7.2.3.2. Limitations
1736 The effectiveness of the validation method depends on the quality of
1737 the supporting observation: how hard it is to obtain at a different
1738 time or place, how difficult it is to guess and what other costs
1739 might be involved in acquiring this data.
1741 In the example of an observed radio signal, requesting a sample of
1742 the signal only provides an assurance that the Device is able to
1743 receive the signal transmitted by the measured radio transmitter.
1744 This only provides some assurance that the Device is within range of
1745 the transmitter.
1747 As with location validation, a Device might still be able to provide
1748 falsified measurements that could alter the value of the location
1749 information as long as the result is within this region.
1751 Requesting additional supporting observations can reduce the size of
1752 the region over which location information can be altered by an
1753 attacker, or increase trust in the result, but each additional has a
1754 cost. Supporting observations contribute little or nothing toward
1755 the primary goal of determining the location of the Device. Any
1756 costs in acquiring supporting observations are balanced against the
1757 degree of integrity desired of the resulting location information.
1759 7.2.4. Attribution
1761 Lying by proxy (Section 7.1.3) relies on the location recipient being
1762 able to attribute location information to a LIS. The effectiveness
1763 of this attack is negated if location information is explicitly
1764 attributed to a particular source.
1766 This requires an extension to the location object that explicitly
1767 identifies the source (or sources) of each item of location
1768 information.
1770 Rather than relying on a process that seeks to ensure that location
1771 information is accurate, this approach instead provides a location
1772 recipient with the information necessary to reach their own
1773 conclusion about the trustworthiness of the location information.
1775 Including an authenticated identity for all sources of measurement
1776 data is presents a number of technical and operational challenges.
1777 It is possible that the LIS has a transient relationship with a
1778 Device. A Device is not expected to share authentication information
1779 with a LIS. There is no assurance that Device identification is
1780 usable by a potential location recipient. Privacy concerns might
1781 also prevent the sharing identification information, even if it were
1782 available and usable.
1784 Identifying the type of measurement source allows a location
1785 recipient to make a decision about the trustworthiness of location
1786 information without depending on having authenticated identity
1787 information for each source. An element for this purpose is defined
1788 in Section 4.4.
1790 When including location information that is based on measurement data
1791 from sources that might be untrusted, a LIS SHOULD include
1792 alternative location information that is derived from trusted sources
1793 of measurement data. Each item of location information can then be
1794 labelled with the source of that data.
1796 A location recipient that is able to identify a specific source of
1797 measurement data (whether it be LIS or Device) can use this
1798 information to attribute location information to either or both
1799 entity. The location recipient is then better able to make decisions
1800 about trustworthiness based on the source of the data.
1802 A location recipient that does not understand the "source" element is
1803 unable to make this distinction. When constructing a PIDF-LO
1804 document, trusted location information MUST be placed in the PIDF-LO
1805 so that it is given higher priority to any untrusted location
1806 information according to Rule #8 of [RFC5491].
1808 Attribution of information does nothing to address attacks that alter
1809 the observed parameters that are used in location determination
1810 (Section 7.1.5).
1812 7.2.5. Stateful Correlation of Location Requests
1814 Stateful examination of requests can be used to prevent a Device from
1815 attempting to map network topology using requests for location
1816 information (Section 7.1.2).
1818 Simply limiting the rate of requests from a single Device reduces the
1819 amount of data that a Device can acquire about network topology.
1821 8. Measurement Schemas
1823 The schema are broken up into their respective functions. There is a
1824 base container schema into which all measurements are placed, plus
1825 definitions for a measurement request (Section 8.1). A PIDF-LO
1826 extension is defined in a separate schema (Section 8.2). There is a
1827 basic types schema, that contains various base type definitions for
1828 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and
1829 MAC addresses (Section 8.3). Then each of the specific measurement
1830 types is defined in its own schema.
1832 8.1. Measurement Container Schema
1834
1835
1843
1844
1846
1847
1848
1850 This schema defines a framework for location measurements.
1851
1852
1854
1856
1857
1858
1859
1860
1861
1863
1864
1865
1866
1867
1868
1869
1870
1871
1873
1875
1876
1877
1878
1879
1881
1883
1884
1885
1886
1888
1889
1890
1892
1893
1894
1896
1897
1898
1899
1900
1901
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1918 Measurement Container Schema
1919 8.2. Measurement Source Schema
1921
1922
1929
1930
1932
1933
1934
1936 This schema defines an extension to PIDF-LO that indicates the
1937 type of source that produced the measurement data used in
1938 generating the associated location information.
1939
1940
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1956 Measurement Source PIDF-LO Extension Schema
1958 8.3. Base Type Schema
1960 Note that the pattern rules in the following schema wrap due to
1961 length constraints. None of the patterns contain whitespace.
1963
1964
1971
1972
1974
1975
1976
1978 This schema defines a set of base type elements.
1979
1980
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2022
2023
2024
2026
2027
2028
2029
2030 An IP version 6 address, based on RFC 4291.
2031
2032
2033
2034
2035
2036
2037
2038
2039
2041
2043
2045
2047
2049
2051
2052
2053
2054
2062
2063
2064
2065
2067
2068
2069
2070
2074
2075
2077
2078
2079
2080
2082
2083
2085
2087 Base Type Schema
2089 8.4. LLDP Measurement Schema
2091
2092
2100
2101
2103
2104
2105
2107 This schema defines a set of LLDP location measurements.
2108
2109
2110
2112
2113
2114
2115
2116
2117
2118
2119
2121
2122
2123
2124
2125
2127
2128
2129
2130
2132
2133
2134
2136
2137
2138
2139
2140
2141
2143
2145 LLDP measurement schema
2147 8.5. DHCP Measurement Schema
2149
2150
2158
2159
2161
2162
2163
2165 This schema defines a set of DHCP location measurements.
2166
2167
2169
2171
2172
2173
2174
2175
2176
2177
2178
2180
2182
2184
2186
2187
2188
2189
2190
2192
2193
2194
2195
2197
2198
2199
2201
2203 DHCP measurement schema
2205 8.6. WiFi Measurement Schema
2206
2207
2216
2217
2219 802.11 location measurements
2220
2221
2222
2224 This schema defines a basic set of 802.11 location measurements.
2225
2226
2228
2229
2231
2233
2234
2235
2236
2237
2239
2241
2242
2243
2244
2245
2247
2248
2249
2250
2251
2252
2254
2256
2258
2260
2262
2264
2266
2268
2270
2272
2273
2275
2276
2277
2278
2280
2281
2282
2283
2285
2286
2287
2289
2291
2292
2293
2294
2295
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2316
2317
2318
2319
2320
2322
2323
2324
2325
2326
2328
2329
2331
2333
2335
2336
2337
2338
2340
2341
2342
2343
2344
2345
2346
2348
2349
2350
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2367
2369 WiFi measurement schema
2371 8.7. Cellular Measurement Schema
2373
2374
2381
2382
2384
2385
2386
2388 This schema defines a set of cellular location measurements.
2389
2390
2392
2394
2395
2396
2397
2398
2399
2400
2401
2402
2404
2405
2406
2407
2408
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2429
2430
2431
2432
2433
2434
2436
2437
2439
2440
2441
2442
2444
2445
2447
2448
2449
2451
2452
2453
2454
2455
2457
2458
2459
2460
2461
2463
2465
2466
2467
2468
2469
2470
2471
2472
2473
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2490
2492 Cellular measurement schema
2494 8.8. GNSS Measurement Schema
2495
2496
2504
2505
2507
2508
2509
2511 This schema defines a set of GNSS location measurements
2512
2513
2515
2517
2518
2519
2520
2521
2522
2523
2525
2526
2527
2528
2529
2531
2533
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2549
2550
2552
2554
2555
2556
2558
2559
2560
2562
2563
2564
2565
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2580 GNSS measurement Schema
2582 8.9. DSL Measurement Schema
2584
2585
2593
2594
2596 DSL measurement definitions
2597
2598
2599
2601 This schema defines a basic set of DSL location measurements.
2602
2603
2605
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2663
2665 DSL measurement schema
2667 9. IANA Considerations
2669 This section creates a registry for GNSS types (Section 5.5) and
2670 registers the namespaces and schema defined in Section 8.
2672 9.1. IANA Registry for GNSS Types
2674 This document establishes a new IANA registry for Global Navigation
2675 Satellite System (GNSS) types. The registry includes tokens for the
2676 GNSS type and for each of the signals within that type. Referring to
2677 [RFC5226], this registry operates under "Specification Required"
2678 rules. The IESG will appoint an Expert Reviewer who will advise IANA
2679 promptly on each request for a new or updated GNSS type.
2681 Each entry in the registry requires the following information:
2683 GNSS name: the name and a brief description of the GNSS
2685 Brief description: the name and a brief description of the GNSS
2687 GNSS token: a token that can be used to identify the GNSS
2689 Signals: a set of tokens that represent each of the signals that the
2690 system provides
2692 Documentation reference: a reference to one or more stable, public
2693 specifications that outline usage of the GNSS, including (but not
2694 limited to) signal specifications and time systems
2696 The registry initially includes two registrations:
2698 GNSS name: Global Positioning System (GPS)
2700 Brief description: a system of satellites that use spread-spectrum
2701 transmission, operated by the US military for commercial and
2702 military applications
2704 GNSS token: gps
2706 Signals: L1, L2, L1C, L2C, L5
2708 Documentation reference: Navstar GPS Space Segment/Navigation User
2709 Interface [GPS.ICD]
2711 GNSS name: Galileo
2713 Brief description: a system of satellites that operate in the same
2714 spectrum as GPS, operated by the European Union for commercial
2715 applications
2717 GNSS Token: galileo
2719 Signals: L1, E5A, E5B, E5A+B, E6
2721 Documentation Reference: Galileo Open Service Signal In Space
2722 Interface Control Document (SIS ICD) [Galileo.ICD]
2724 9.2. URN Sub-Namespace Registration for
2725 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2727 This section registers a new XML namespace,
2728 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines
2729 in [RFC3688].
2731 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2733 Registrant Contact: IETF, GEOPRIV working group,
2734 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2736 XML:
2738 BEGIN
2739
2740
2742
2743
2744 Measurement Source for PIDF-LO
2745
2746
2747 Namespace for Location Measurement Source
2748 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2749 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2750 with the RFC number for this specification.]]
2751 See RFCXXXX.
2752
2753
2754 END
2756 9.3. URN Sub-Namespace Registration for
2757 urn:ietf:params:xml:ns:geopriv:lm
2759 This section registers a new XML namespace,
2760 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in
2761 [RFC3688].
2763 URI: urn:ietf:params:xml:ns:geopriv:lm
2765 Registrant Contact: IETF, GEOPRIV working group,
2766 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2768 XML:
2770 BEGIN
2771
2772
2774
2775
2776 Measurement Container
2777
2778
2779 Namespace for Location Measurement Container
2780 urn:ietf:params:xml:ns:geopriv:lm
2781 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2782 with the RFC number for this specification.]]
2783 See RFCXXXX.
2784
2785
2786 END
2788 9.4. URN Sub-Namespace Registration for
2789 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2791 This section registers a new XML namespace,
2792 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines
2793 in [RFC3688].
2795 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes
2797 Registrant Contact: IETF, GEOPRIV working group,
2798 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2800 XML:
2802 BEGIN
2803
2804
2806
2807
2808 Base Device Types
2809
2810
2811 Namespace for Base Types
2812 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2813 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2814 with the RFC number for this specification.]]
2815 See RFCXXXX.
2816
2817
2818 END
2820 9.5. URN Sub-Namespace Registration for
2821 urn:ietf:params:xml:ns:geopriv:lm:lldp
2823 This section registers a new XML namespace,
2824 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in
2825 [RFC3688].
2827 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
2829 Registrant Contact: IETF, GEOPRIV working group,
2830 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2832 XML:
2834 BEGIN
2835
2836
2838
2839
2840 LLDP Measurement Set
2841
2842
2843 Namespace for LLDP Measurement Set
2844 urn:ietf:params:xml:ns:geopriv:lm:lldp
2845 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2846 with the RFC number for this specification.]]
2847 See RFCXXXX.
2848
2849
2850 END
2852 9.6. URN Sub-Namespace Registration for
2853 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2855 This section registers a new XML namespace,
2856 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in
2857 [RFC3688].
2859 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
2861 Registrant Contact: IETF, GEOPRIV working group,
2862 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2864 XML:
2866 BEGIN
2867
2868
2870
2871
2872 DHCP Measurement Set
2873
2874
2875 Namespace for DHCP Measurement Set
2876 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2877 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2878 with the RFC number for this specification.]]
2879 See RFCXXXX.
2880
2881
2882 END
2884 9.7. URN Sub-Namespace Registration for
2885 urn:ietf:params:xml:ns:geopriv:lm:wifi
2887 This section registers a new XML namespace,
2888 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
2889 [RFC3688].
2891 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi
2893 Registrant Contact: IETF, GEOPRIV working group,
2894 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2896 XML:
2898 BEGIN
2899
2900
2902
2903
2904 WiFi Measurement Set
2905
2906
2907 Namespace for WiFi Measurement Set
2908 urn:ietf:params:xml:ns:geopriv:lm:wifi
2909 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2910 with the RFC number for this specification.]]
2911 See RFCXXXX.
2912
2913
2914 END
2916 9.8. URN Sub-Namespace Registration for
2917 urn:ietf:params:xml:ns:geopriv:lm:cell
2919 This section registers a new XML namespace,
2920 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in
2921 [RFC3688].
2923 URI: urn:ietf:params:xml:ns:geopriv:lm:cell
2925 Registrant Contact: IETF, GEOPRIV working group,
2926 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2928 XML:
2930 BEGIN
2931
2932
2934
2935
2936 Cellular Measurement Set
2937
2938
2939 Namespace for Cellular Measurement Set
2940 urn:ietf:params:xml:ns:geopriv:lm:cell
2941 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2942 with the RFC number for this specification.]]
2943 See RFCXXXX.
2944
2945
2946 END
2948 9.9. URN Sub-Namespace Registration for
2949 urn:ietf:params:xml:ns:geopriv:lm:gnss
2951 This section registers a new XML namespace,
2952 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in
2953 [RFC3688].
2955 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
2957 Registrant Contact: IETF, GEOPRIV working group,
2958 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2960 XML:
2962 BEGIN
2963
2964
2966
2967
2968 GNSS Measurement Set
2969
2970
2971 Namespace for GNSS Measurement Set
2972 urn:ietf:params:xml:ns:geopriv:lm:gnss
2973 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2974 with the RFC number for this specification.]]
2975 See RFCXXXX.
2976
2977
2978 END
2980 9.10. URN Sub-Namespace Registration for
2981 urn:ietf:params:xml:ns:geopriv:lm:dsl
2983 This section registers a new XML namespace,
2984 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in
2985 [RFC3688].
2987 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl
2989 Registrant Contact: IETF, GEOPRIV working group,
2990 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
2992 XML:
2994 BEGIN
2995
2996
2998
2999
3000 DSL Measurement Set
3001
3002
3003 Namespace for DSL Measurement Set
3004 urn:ietf:params:xml:ns:geopriv:lm:dsl
3005 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3006 with the RFC number for this specification.]]
3007 See RFCXXXX.
3008
3009
3010 END
3012 9.11. XML Schema Registration for Measurement Source Schema
3014 This section registers an XML schema as per the guidelines in
3015 [RFC3688].
3017 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
3019 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3020 Martin Thomson (martin.thomson@andrew.com).
3022 Schema: The XML for this schema can be found in Section 8.2 of this
3023 document.
3025 9.12. XML Schema Registration for Measurement Container Schema
3027 This section registers an XML schema as per the guidelines in
3028 [RFC3688].
3030 URI: urn:ietf:params:xml:schema:lm
3032 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3033 Martin Thomson (martin.thomson@andrew.com).
3035 Schema: The XML for this schema can be found in Section 8.1 of this
3036 document.
3038 9.13. XML Schema Registration for Base Types Schema
3040 This section registers an XML schema as per the guidelines in
3041 [RFC3688].
3043 URI: urn:ietf:params:xml:schema:lm:basetypes
3045 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3046 Martin Thomson (martin.thomson@andrew.com).
3048 Schema: The XML for this schema can be found in Section 8.3 of this
3049 document.
3051 9.14. XML Schema Registration for LLDP Schema
3053 This section registers an XML schema as per the guidelines in
3054 [RFC3688].
3056 URI: urn:ietf:params:xml:schema:lm:lldp
3058 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3059 Martin Thomson (martin.thomson@andrew.com).
3061 Schema: The XML for this schema can be found in Section 8.4 of this
3062 document.
3064 9.15. XML Schema Registration for DHCP Schema
3066 This section registers an XML schema as per the guidelines in
3067 [RFC3688].
3069 URI: urn:ietf:params:xml:schema:lm:dhcp
3071 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3072 Martin Thomson (martin.thomson@andrew.com).
3074 Schema: The XML for this schema can be found in Section 8.5 of this
3075 document.
3077 9.16. XML Schema Registration for WiFi Schema
3079 This section registers an XML schema as per the guidelines in
3080 [RFC3688].
3082 URI: urn:ietf:params:xml:schema:lm:wifi
3084 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3085 Martin Thomson (martin.thomson@andrew.com).
3087 Schema: The XML for this schema can be found in Section 8.6 of this
3088 document.
3090 9.17. XML Schema Registration for Cellular Schema
3092 This section registers an XML schema as per the guidelines in
3093 [RFC3688].
3095 URI: urn:ietf:params:xml:schema:lm:cellular
3097 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3098 Martin Thomson (martin.thomson@andrew.com).
3100 Schema: The XML for this schema can be found in Section 8.7 of this
3101 document.
3103 9.18. XML Schema Registration for GNSS Schema
3105 This section registers an XML schema as per the guidelines in
3106 [RFC3688].
3108 URI: urn:ietf:params:xml:schema:lm:gnss
3110 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3111 Martin Thomson (martin.thomson@andrew.com).
3113 Schema: The XML for this schema can be found in Section 8.8 of this
3114 document.
3116 9.19. XML Schema Registration for DSL Schema
3118 This section registers an XML schema as per the guidelines in
3119 [RFC3688].
3121 URI: urn:ietf:params:xml:schema:lm:dsl
3123 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3124 Martin Thomson (martin.thomson@andrew.com).
3126 Schema: The XML for this schema can be found in Section 8.9 of this
3127 document.
3129 10. Acknowledgements
3131 Thanks go to Simon Cox for his comments relating to terminology that
3132 have helped ensure that this document is aligns with ongoing work in
3133 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his
3134 review and comments on the GNSS sections of this document. Thanks to
3135 Noor-E-Gagan Singh, Gabor Bajko and Russell Priebe for their
3136 significant input to and suggestions for improving the 802.11
3137 measurements. Thanks to Cullen Jennings for feedback and
3138 suggestions. Bernard Aboba provided review and feedback on a range
3139 of measurement data definitions. Mary Barnes provided a review and
3140 corrections. David Waitzman and John Bressler both noted
3141 shortcomings with 802.11 measurements.
3143 11. References
3145 11.1. Normative References
3147 [DSL.TR025]
3148 Wang, R., "Core Network Architecture Recommendations for
3149 Access to Legacy Data Networks over ADSL", September 1999.
3151 [DSL.TR101]
3152 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
3153 Aggregation", April 2006.
3155 [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface",
3156 ICD GPS-200, Apr 2000.
3158 [Galileo.ICD]
3159 GJU, "Galileo Open Service Signal In Space Interface
3160 Control Document (SIS ICD)", May 2006.
3162 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
3163 October 1969.
3165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3166 Requirement Levels", BCP 14, RFC 2119, March 1997.
3168 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3169 10646", STD 63, RFC 3629, November 2003.
3171 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3172 Resource Identifier (URI): Generic Syntax", STD 66,
3173 RFC 3986, January 2005.
3175 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
3176 Format", RFC 4119, December 2005.
3178 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3179 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3180 May 2008.
3182 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
3183 Presence Information Data Format Location Object (PIDF-LO)
3184 Usage Clarification, Considerations, and Recommendations",
3185 RFC 5491, March 2009.
3187 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
3188 RFC 5985, September 2010.
3190 [TIA-2000.5]
3191 TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for
3192 cdma2000(R) Spread Spectrum Systems", TIA-2000.5-D,
3193 March 2004.
3195 [TS.3GPP.23.003]
3196 3GPP, "Numbering, addressing and identification", 3GPP
3197 TS 23.003 9.4.0, September 2010.
3199 11.2. Informative References
3201 [ANSI-TIA-1057]
3202 ANSI/TIA, "Link Layer Discovery Protocol for Media
3203 Endpoint Devices", TIA 1057, April 2006.
3205 [GPS.SPOOF]
3206 Scott, L., "Anti-Spoofing and Authenticated Signal
3207 Architectures for Civil Navigation Signals", ION-
3208 GNSS Portland, Oregon, 2003.
3210 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side
3211 spoofing and detection for Assisted-GPS", Proceedings of
3212 International Global Navigation Satellite Systems Society
3213 (IGNSS) Symposium 2009 16, December 2009,
3214 .
3216 [I-D.ietf-geopriv-held-identity-extensions]
3217 Winterbottom, J., Thomson, M., Tschofenig, H., and R.
3218 Barnes, "Use of Device Identity in HTTP-Enabled Location
3219 Delivery (HELD)",
3220 draft-ietf-geopriv-held-identity-extensions-06 (work in
3221 progress), November 2010.
3223 [I-D.thomson-geopriv-uncertainty]
3224 Thomson, M. and J. Winterbottom, "Representation of
3225 Uncertainty and Confidence in PIDF-LO",
3226 draft-thomson-geopriv-uncertainty-06 (work in progress),
3227 March 2011.
3229 [IANA.enterprise]
3230 IANA, "Private Enterprise Numbers", 2011,
3231 .
3233 [IEEE.80211]
3234 IEEE, "Wireless LAN Medium Access Control (MAC) and
3235 Physical Layer (PHY) specifications - IEEE 802.11 Wireless
3236 Network Management", IEEE Std 802.11-2007, June 2007.
3238 [IEEE.80211V]
3239 IEEE, "Wireless LAN Medium Access Control (MAC) and
3240 Physical Layer (PHY) specifications - IEEE 802.11 Wireless
3241 Network Management (Draft)", P802.11v D12.0, June 2010.
3243 [IEEE.8021AB]
3244 IEEE, "IEEE Standard for Local and Metropolitan area
3245 networks, Station and Media Access Control Connectivity
3246 Discovery", 802.1AB, June 2005.
3248 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
3249 "Remote Authentication Dial In User Service (RADIUS)",
3250 RFC 2865, June 2000.
3252 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
3253 RFC 3046, January 2001.
3255 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
3256 January 2004.
3258 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
3259 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
3261 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
3262 Suboption for the Dynamic Host Configuration Protocol
3263 (DHCP) Relay Agent Option", RFC 3993, March 2005.
3265 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
3266 Architecture", RFC 4291, February 2006.
3268 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3269 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
3270 June 2006.
3272 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3273 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
3274 August 2006.
3276 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
3277 Mechanism", RFC 5808, May 2010.
3279 Authors' Addresses
3281 Martin Thomson
3282 Andrew
3283 Andrew Building (39)
3284 University of Wollongong
3285 Northfields Avenue
3286 Wollongong, NSW 2522
3287 AU
3289 Phone: +61 2 4221 2915
3290 Email: martin.thomson@andrew.com
3291 URI: http://www.andrew.com/
3293 James Winterbottom
3294 Andrew
3295 Andrew Building (39)
3296 University of Wollongong
3297 Northfields Avenue
3298 NSW 2522
3299 AU
3301 Phone: +61 2 4221 2938
3302 Email: james.winterbottom@andrew.com
3303 URI: http://www.andrew.com/