idnits 2.17.1 draft-ietf-geopriv-held-measurements-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2013) is 4023 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-5' is mentioned on line 2069, but not defined == Missing Reference: '0-4' is mentioned on line 2069, but not defined == Missing Reference: '0-9' is mentioned on line 2069, but not defined == Missing Reference: '0-1' is mentioned on line 2069, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.80211V' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.80211' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.8021AB' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Microsoft 4 Intended status: Standards Track J. Winterbottom 5 Expires: October 13, 2013 Commscope 6 April 11, 2013 8 Using Device-provided Location-Related Measurements in Location 9 Configuration Protocols 10 draft-ietf-geopriv-held-measurements-07 12 Abstract 14 A method is described by which a Device is able to provide location- 15 related measurement data to a LIS within a request for location 16 information. Location-related measurement information are 17 observations concerning properties related to the position of a 18 Device, which could be data about network attachment or about the 19 physical environment. When a LIS generates location information for 20 a Device, information from the Device can improve the accuracy of the 21 location estimate. A basic set of location-related measurements are 22 defined, including common modes of network attachment as well as 23 assisted Global Navigation Satellite System (GNSS) parameters. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 13, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Conventions used in this document . . . . . . . . . . . . . . 4 61 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 5 62 4. Location-Related Measurement Data Types . . . . . . . . . . . 6 63 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 7 64 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 7 65 4.1.2. Expiry Time on Location-Related Measurement Data . . 8 66 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 8 67 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . 9 68 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 9 69 4.4. Identifying Location Provenance . . . . . . . . . . . . . 10 70 5. Location-Related Measurement Data Types . . . . . . . . . . . 12 71 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 13 72 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 14 73 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . 14 74 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 17 75 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 18 76 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 20 77 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 21 78 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . 22 79 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . 23 80 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . 23 81 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 24 82 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . 24 83 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 25 84 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 25 85 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . 26 86 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . 26 87 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 88 6.1. Measurement Data Privacy Model . . . . . . . . . . . . . 27 89 6.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . 27 90 6.3. Measurement Data and Location URIs . . . . . . . . . . . 28 91 6.4. Third-Party-Provided Measurement Data . . . . . . . . . . 28 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 93 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 29 94 7.1.1. Acquiring Location Information Without Authorization 29 95 7.1.2. Extracting Network Topology Data . . . . . . . . . . 30 96 7.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . 30 97 7.1.4. Measurement Replay . . . . . . . . . . . . . . . . . 31 98 7.1.5. Environment Spoofing . . . . . . . . . . . . . . . . 32 99 7.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 33 100 7.2.1. Measurement Validation . . . . . . . . . . . . . . . 34 101 7.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 34 102 7.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 35 103 7.2.2. Location Validation . . . . . . . . . . . . . . . . . 35 104 7.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 36 105 7.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 36 106 7.2.3. Supporting Observations . . . . . . . . . . . . . . . 37 107 7.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 37 108 7.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 37 109 7.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 38 110 7.2.5. Stateful Correlation of Location Requests . . . . . . 39 111 8. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 39 112 8.1. Measurement Container Schema . . . . . . . . . . . . . . 39 113 8.2. Measurement Source Schema . . . . . . . . . . . . . . . . 41 114 8.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . 42 115 8.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 45 116 8.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 46 117 8.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 47 118 8.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 51 119 8.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 53 120 8.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . 55 121 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 122 9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . 57 123 9.2. URN Sub-Namespace Registration for 124 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 58 125 9.3. URN Sub-Namespace Registration for 126 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 59 127 9.4. URN Sub-Namespace Registration for 128 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 59 129 9.5. URN Sub-Namespace Registration for 130 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . 60 131 9.6. URN Sub-Namespace Registration for 132 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . 61 133 9.7. URN Sub-Namespace Registration for 134 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . 62 135 9.8. URN Sub-Namespace Registration for 136 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . 62 137 9.9. URN Sub-Namespace Registration for 138 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . 63 139 9.10. URN Sub-Namespace Registration for 140 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 64 141 9.11. XML Schema Registration for Measurement Source Schema . . 64 142 9.12. XML Schema Registration for Measurement Container Schema 65 143 9.13. XML Schema Registration for Base Types Schema . . . . . . 65 144 9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 65 145 9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 65 146 9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 66 147 9.17. XML Schema Registration for Cellular Schema . . . . . . . 66 148 9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 66 149 9.19. XML Schema Registration for DSL Schema . . . . . . . . . 66 150 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67 151 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 152 11.1. Normative References . . . . . . . . . . . . . . . . . . 67 153 11.2. Informative References . . . . . . . . . . . . . . . . . 69 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 156 1. Introduction 158 A location configuration protocol (LCP) provides a means for a Device 159 to request information about its physical location from an access 160 network. A location information server (LIS) is the server that 161 provides location information; information that is available due to 162 the knowledge about the network and physical environment that is 163 available to the LIS. 165 As a part of the access network, the LIS is able to acquire 166 measurement results from network Devices within the network that are 167 related to Device location. The LIS also has access to information 168 about the network topology that can be used to turn measurement data 169 into location information. However, this information can be enhanced 170 with information acquired from the Device itself. 172 A Device is able to make observations about its network attachment, 173 or its physical environment. The location-related measurement data 174 might be unavailable to the LIS; alternatively, the LIS might be able 175 to acquire the data, but at a higher cost in time or otherwise. 176 Providing measurement data gives the LIS more options in determining 177 location, which could improve the quality of the service provided by 178 the LIS. Improvements in accuracy are one potential gain, but 179 improved response times and lower error rates are also possible. 181 This document describes a means for a Device to report location- 182 related measurement data to the LIS. Examples based on the HELD 183 [RFC5985] location configuration protocol are provided. 185 2. Conventions used in this document 187 The terms LIS and Device are used in this document in a manner 188 consistent with the usage in [RFC5985]. 190 This document also uses the following definitions: 192 Location Measurement: An observation about the physical properties 193 of a particular Device's network access. The result of a location 194 measurement - "location-related measurement data", or simply 195 "measurement data" given sufficient context - can be used to 196 determine the location of a Device. Location-related measurement 197 data does not identify a Device; measurement data can change with 198 time if the location of the Device also changes. 200 Location-related measurement data does not necessarily contain 201 location information directly, but it can be used in combination 202 with contextual knowledge of the network, or algorithms to derive 203 location information. Examples of location-related measurement 204 data are: radio signal strength or timing measurements, Ethernet 205 switch and port identifiers. 207 Location-related measurement data can be considered sighting 208 information, based on the definition in [RFC3693]. 210 Location Estimate: A location estimate is an approximation of where 211 the Device is located. Location estimates are derived from 212 location measurements. Location estimates are subject to 213 uncertainty, which arise from errors in measurement results. 215 GNSS: Global Navigation Satellite System. A satellite-based system 216 that provides positioning and time information. For example, the 217 US Global Positioning System (GPS) or the European Galileo system. 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [RFC2119]. 223 3. Location-Related Measurements in LCPs 225 This document defines a standard container for the conveyance of 226 location-related measurement parameters in location configuration 227 protocols. This is an XML container that identifies parameters by 228 type and allows the Device to provide the results of any measurement 229 it is able to perform. A set of measurement schemas are also defined 230 that can be carried in the generic container. 232 The simplest example of measurement data conveyance is illustrated by 233 the example message in Figure 1. This shows a HELD location request 234 message with an Ethernet switch and port measurement taken using LLDP 235 [IEEE.8021AB]. 237 238 civic 239 241 242 0a01003c 243 c2 244 245 246 248 Figure 1: HELD Location Request with Measurement Data 250 Measurement data that the LIS does not support or understand can be 251 ignored. The measurements defined in this document follow this rule; 252 extensions that could result in backward incompatibility MUST be 253 added as new measurement definitions rather than extensions to 254 existing types. 256 Multiple sets of measurement data, either of the same type or from 257 different sources can be included in the "measurements" element. See 258 Section 4.1.1 for details on repetition of this element. 260 Use of location-related measurement data is at the discretion of the 261 LIS, but the "method" parameter in the Presence Information Data 262 Format - Location Object (PIDF-LO) [RFC4119] SHOULD be adjusted to 263 reflect the method used. 265 Location-related measurement data need not be provided exclusively by 266 Devices. A third party location requester can request location 267 information using measurement data, if they are able and authorized. 268 There are privacy considerations relating to the use of measurements 269 by third parties, which are discussed in Section 6.4. 271 Location-related measurement data and its use presents a number of 272 security challenges. These are described in more detail in 273 Section 7. 275 4. Location-Related Measurement Data Types 277 A common container is defined for the expression of location 278 measurement data, as well as a simple means of identifying specific 279 types of measurement data for the purposes of requesting them. 281 The following example shows a measurement container with measurement 282 time and expiration time included. A WiFi measurement is enclosed. 284 287 288 289 00-12-F0-A0-80-EF 290 wlan-home 291 292 293 295 Figure 2: Measurement Example 297 4.1. Measurement Container 299 The "measurement" element is used to encapsulate measurement data 300 that is collected at a certain point in time. It contains time-based 301 attributes that are common to all forms of measurement data, and 302 permits the inclusion of arbitrary measurement data. 304 This container can be added to a request for location information in 305 any protocol capable of carrying XML, such as a HELD location request 306 [RFC5985]. 308 4.1.1. Time of Measurement 310 The "time" attribute records the time that the measurement or 311 observation was made. This time can be different to the time that 312 the measurement information was reported. Time information can be 313 used to populate a timestamp on the location result, or to determine 314 if the measurement information is used. 316 The "time" attribute is optional to avoid forcing an arbitrary choice 317 of timestamp for relatively static types of measurement (for 318 instance, the DSL measurements in Section 5.6) and for legacy Devices 319 that don't record time information (such as the Home Location 320 Register/Home Subscriber Server for cellular). However, time SHOULD 321 be provided whenever possible. 323 The "time" attribute is attached to the root "measurement" element. 324 If it is necessary to provide multiple sets of measurement data with 325 different times, multiple "measurement" elements SHOULD be provided. 327 4.1.2. Expiry Time on Location-Related Measurement Data 329 A Device is able to indicate an expiry time in the location 330 measurement using the "expires" attribute. Nominally, this attribute 331 indicates how long information is expected to be valid for, but it 332 can also indicate a time limit on the retention and use of the 333 measurement data. A Device can use this attribute to prevent the LIS 334 from retaining measurement data or limit the time that a LIS retains 335 this information. 337 Note: Movement of a Device might result in the measurement data 338 being invalidated before the expiry time. 340 The LIS MUST NOT keep location-related measurement data beyond the 341 time indicated in the "expires" attribute. 343 4.2. RMS Error and Number of Samples 345 Often a measurement is taken more than once over a period of time. 346 Reporting the average of a number of measurement results mitigates 347 the effects of random errors that occur in the measurement process. 349 Reporting each measurement individually can be the most effective 350 method of reporting multiple measurements. This is achieved by 351 providing multiple "measurement" elements for different times. 353 The alternative is to aggregate multiple measurements and report a 354 mean value across the set of measurements. Additional information 355 about the distribution of the results can be useful in determining 356 location uncertainty. 358 Two optional attributes are provided for certain measurement values: 360 rmsError: The root-mean-squared (RMS) error of the set of 361 measurement values used in calculating the result. RMS error is 362 expressed in the same units as the measurement, unless otherwise 363 stated. If an accurate value for RMS error is not known, this 364 value can be used to indicate an upper bound or estimate for the 365 RMS error. 367 samples: The number of samples that were taken in determining the 368 measurement value. If omitted, this value can be assumed to be a 369 very large value, so that the RMS error is an indication of the 370 standard deviation of the sample set. 372 For some measurement techniques, measurement error is largely 373 dependent on the measurement technique employed. In these cases, 374 measurement error is largely a product of the measurement technique 375 and not the specific circumstances, so RMS error does not need to be 376 actively measured. A fixed value MAY be provided for RMS error where 377 appropriate. 379 The "rmsError" and "samples" elements are added as attributes of 380 specific measurement data types. 382 4.2.1. Time RMS Error 384 Measurement of time can be significant in certain circumstances. The 385 GNSS measurements included in this document are one such case where a 386 small error in time can result in a large error in location. Factors 387 such as clock drift and errors in time synchronization can result in 388 small, but significant, time errors. Including an indication of the 389 quality of the time can be helpful. 391 An optional "timeError" attribute can be added to the "measurement" 392 element to indicate the RMS error in time. "timeError" indicates an 393 upper bound on the time RMS error in seconds. 395 The "timeError" attribute does not apply where multiple samples of a 396 measurement are taken over time. If multiple samples are taken, each 397 SHOULD be included in a different "measurement" element. 399 4.3. Measurement Request 401 A measurement request is used by a protocol peer to describe a set of 402 measurement data that it desires. A "measurementRequest" element is 403 defined that can be included in a protocol exchange. 405 For instance, a LIS can use a measurement request in HELD responses. 406 If the LIS is unable to provide location information, but it believes 407 that a particular measurement type would enable it to provide a 408 location, it can include a measurement request in an error response. 410 The "measurement" element of the measurement request identifies the 411 type of measurement that is requested. The "type" attribute of this 412 element indicates the type of measurement, as identified by an XML 413 qualified name. An optional "samples" attribute indicates how many 414 samples of the identified measurement are requested. 416 The "measurement" element can be repeated to request multiple (or 417 alternative) measurement types. 419 Additional XML content might be defined for a particular measurement 420 type that is used to further refine a request. These elements either 421 constrain what is requested or specify optional components of the 422 measurement data that are needed. These are defined along with the 423 specific measurement type. 425 In the HELD protocol, the inclusion of a measurement request in an 426 error response with a code of "locationUnknown" indicates that the 427 LIS believes that providing the indicated measurements would increase 428 the likelihood of a subsequent request being successful. 430 The following example shows a HELD error response that indicates that 431 WiFi measurement data would be useful if a later request were made. 432 Additional elements indicate that received signal strength for an 433 802.11n access point is requested. 435 437 Insufficient measurement data 438 441 442 n 443 wifi:rcpi 444 445 446 448 Figure 3: HELD Error Requesting Measurement Data 450 A measurement request that is included in other HELD messages has 451 undefined semantics and can be safely ignored. Other specifications 452 might define semantics for measurement requests under other 453 conditions. 455 4.4. Identifying Location Provenance 457 An extension is made to the PIDF-LO [RFC4119] that allows a location 458 recipient to identify the source (or sources) of location information 459 and the measurement data that was used to determine that location 460 information. 462 The "source" element is added to the "geopriv" element of the PIDF- 463 LO. This element does not identify specific entities. Instead, it 464 identifies the type of source. 466 The following types of measurement source are identified: 468 lis: Location information is based on measurement data that the LIS 469 or sources that it trusts have acquired. This label might be used 470 if measurement data provided by the Device has been completely 471 validated by the LIS. 473 device: Location information is based on measurement data that the 474 Device has provided to the LIS. 476 other: Location information is based on measurement data that a 477 third party has provided. This might be an authorized third party 478 that uses identity parameters [RFC6155] or any other entity. 480 No assertion is made about the veracity of the measurement data from 481 sources other than the LIS. A combination of tags MAY be included to 482 indicate that measurement data from both sources was used. 484 For example, the first tuple of the following PIDF-LO indicates that 485 measurement data from a LIS and a device was combined to produce the 486 result, the second tuple was produced by the LIS alone. 488 494 495 496 497 498 499 7.34324 134.47162 500 501 850.24 502 503 504 505 506 OTDOA 507 lis device 508 509 510 511 512 513 514 515 516 7.34379 134.46484 517 518 9000 519 520 521 522 523 Cell 524 lis 525 526 527 528 530 PIDF-LO document with source labels 532 5. Location-Related Measurement Data Types 534 This document defines location-related measurement data types for a 535 range of common network types. 537 All included measurement data definitions allow for arbitrary 538 extension in the corresponding schema. As new parameters that are 539 applicable to location determination are added, these can be added as 540 new XML elements in a unique namespace. Though many of the 541 underlying protocols support extension, creation of specific XML- 542 based extensions to the measurement format is favored over 543 accommodating protocol-specific extensions in generic containers. 545 5.1. LLDP Measurements 547 Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent 548 between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet, 549 WiFi, 802.16). These messages all contain identification information 550 for the sending node, which can be used to determine location 551 information. A Device that receives LLDP messages can report this 552 information as a location-related measurement to the LIS, which is 553 then able to use the measurement data in determining the location of 554 the Device. 556 Note: The LLDP extensions defined in LLDP Media Endpoint Discovery 557 (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location 558 information directly from an LLDP endpoint. Where this 559 information is available, it might be unnecessary to use any other 560 form of location configuration. 562 Values are provided as hexadecimal sequences. The Device MUST report 563 the values directly as they were provided by the adjacent node. 564 Attempting to adjust or translate the type of identifier is likely to 565 cause the measurement data to be useless. 567 Where a Device has received LLDP messages from multiple adjacent 568 nodes, it should provide information extracted from those messages by 569 repeating the "lldp" element. 571 An example of an LLDP measurement is shown in Figure 4. This shows 572 an adjacent node (chassis) that is identified by the IP address 573 192.0.2.45 (hexadecimal c000022d) and the port on that node is 574 numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2). 576 578 579 c000022d 580 a2 581 582 584 Figure 4: LLDP Measurement Example 586 IEEE 802 Devices that are able to obtain information about adjacent 587 network switches and their attachment to them by other means MAY use 588 this data type to convey this information. 590 5.2. DHCP Relay Agent Information Measurements 592 The DHCP Relay Agent Information option [RFC3046] provides 593 measurement data about the network attachment of a Device. This 594 measurement data can be included in the "dhcp-rai" element. 596 The elements in the DHCP relay agent information options are opaque 597 data types assigned by the DHCP relay agent. The three items are all 598 optional: circuit identifier ("circuit", [RFC3046]), remote 599 identifier ("remote", Remote ID [RFC3046], or remote-id [RFC4649]) 600 and subscriber identifier ("subscriber", subscriber-id [RFC3993], 601 Subscriber-ID [RFC4580]). The DHCPv6 remote-id has an associated 602 enterprise number [IANA.enterprise] as an XML attribute. 604 606 607 ::ffff:192.0.2.158 608 108b 609 610 612 Figure 5: DHCP Relay Agent Information Measurement Example 614 The "giaddr" is specified as a dotted quad IPv4 address or an RFC 615 4291 [RFC4291] IPv6 address, using the forms defined in [RFC3986]. 616 The enterprise number is specified as a decimal integer. All other 617 information is included verbatim from the DHCP request in hexadecimal 618 format. 620 5.3. 802.11 WLAN Measurements 622 In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to 623 provide information about the access point (AP) that it is attached 624 to, or other WiFi points it is able to see. This is provided using 625 the "wifi" element, as shown in Figure 6, which shows a single 626 complete measurement for a single access point. 628 630 631 Intel(r)PRO/Wireless 2200BG 632 633 AB-CD-EF-AB-CD-EF 634 example 635 5 636 637 638 -34.4 150.8 639 640 641 a 642 5 643 2 644 2 645 2.56e-9 646 647 23 648 5 649 -59 650 23 651 652 653 10 654 9 655 -98.5 656 7.5 657 658 659 660 662 Figure 6: 802.11 WLAN Measurement Example 664 A wifi element is made up of one or more access points, and an 665 optional "nicType" element. Each access point is described using the 666 "ap" element, which is comprised of the following fields: 668 bssid: The basic service set identifier. In an Infrastructure BSS 669 network, the bssid is the 48 bit MAC address of the access point. 671 The "verified" attribute of this element describes whether the 672 device has verified the MAC address or it authenticated the access 673 point or the network operating the access point (for example, a 674 captive portal accessed through the access point has been 675 authenticated). This attributes defaults to a value of "false" 676 when omitted. 678 ssid: The service set identifier (SSID) for the wireless network 679 served by the access point. 681 The SSID is a 32-octet identifier that is commonly represented as 682 a ASCII [ASCII] or UTF-8 [RFC3629] encoded string. To represent 683 octets that cannot be directly included in an XML element, 684 escaping is used. Sequences of octets that do not represent a 685 valid UTF-8 encoding can be escaped using a backslash ('\') 686 followed by two case-insensitive hexadecimal digits representing 687 the value of a single octet. 689 The canonical or value-space form of an SSID is a sequence of up 690 to 32 octets that is produced from the concatenation of UTF-8 691 encoded sequences of unescaped characters and octets derived from 692 escaped components. 694 channel: The channel number (frequency) that the access point 695 operates on. 697 location: The location of the access point, as reported by the 698 access point. This element contains any valid location, using the 699 rules for a "location-info" element, as described in [RFC5491]. 701 type: The network type for the network access. This element 702 includes the alphabetic suffix of the 802.11 specification that 703 introduced the radio interface, or PHY; e.g. "a", "b", "g", or 704 "n". 706 band: The frequency band for the radio, in gigahertz (GHz). 802.11 707 [IEEE.80211] specifies PHY layers that use 2.4, 3.7 and 5 708 gigahertz frequency bands. 710 regclass: The regulatory domain and class. The "country" attribute 711 optionally includes the applicable two character country 712 identifier (dot11CountryString), which can be followed by an 'O', 713 'I' or 'X'. The element text content includes the value of the 714 regulatory class: an 8-bit integer in decimal form. 716 antenna: The antenna identifier for the antenna that the access 717 point is using to transmit the measured signals. 719 flightTime: Flight time is the difference between the time of 720 departure (TOD) of signal from a transmitting station and time of 721 arrival (TOA) of signal at a receiving station, as defined in 722 [IEEE.80211V]. Measurement of this value requires that stations 723 synchronize their clocks. This value can be measured by access 724 point or Device; because the flight time is assumed to be the same 725 in either direction - aside from measurement errors - only a 726 single element is provided. This element includes optional 727 "rmsError" and "samples" attributes. RMS error might be derived 728 from the reported RMS error in TOD and TOA. 730 apSignal: Measurement information for the signal transmitted by the 731 access point, as observed by the Device. Some of these values are 732 derived from 802.11v [IEEE.80211V] messages exchanged between 733 Device and access point. The contents of this element include: 735 transmit: The transmit power reported by the access point, in 736 dBm. 738 gain: The gain of the access point antenna reported by the access 739 point, in dB. 741 rcpi: The received channel power indicator for the access point 742 signal, as measured by the Device. This value SHOULD be in 743 units of dBm (with RMS error in dB). If power is measured 744 in a different fashion, the "dBm" attribute MUST be set to 745 "false". Signal strength reporting on current hardware uses 746 a range of different mechanisms; therefore, the value of the 747 "nicType" element SHOULD be included if the units are not 748 known to be in dBm and the value reported by the hardware 749 should be included without modification. This element 750 includes optional "rmsError" and "samples" attributes. 752 rsni: The received signal to noise indicator in dB. This element 753 includes optional "rmsError" and "samples" attributes. 755 deviceSignal: Measurement information for the signal transmitted by 756 the device, as reported by the access point. This element 757 contains the same child elements as the "ap" element, with the 758 access point and Device roles reversed. 760 All elements are optional except for "bssid". 762 The "nicType" element is used to specify the make and model of the 763 wireless network interface in the Device. Different 802.11 chipsets 764 report measurements in different ways, so knowing the network 765 interface type aids the LIS in determining how to use the provided 766 measurement data. The content of this field is unconstrained and no 767 mechanisms are specified to ensure uniqueness. 769 5.3.1. Wifi Measurement Requests 771 Two elements are defined for requesting WiFi measurements in a 772 measurement request: 774 type: The "type" element identifies the desired type (or types that 775 are requested. 777 parameter: The "parameter" element identifies an optional 778 measurements are requested for each measured access point. An 779 element is identified by its qualified name. The optional 780 "context" parameter can be used to specify if an element is 781 included as a child of the "ap" or "device" elements; omission 782 indicates that it applies to both. 784 Multiple types or parameters can be requested by repeating either 785 element. 787 5.4. Cellular Measurements 789 Cellular Devices are common throughout the world and base station 790 identifiers can provide a good source of coarse location information. 791 This information can be provided to a LIS run by the cellar operator, 792 or may be provided to an alternative LIS operator that has access to 793 one of several global cell-id to location mapping databases. 795 A number of advanced location determination methods have been 796 developed for cellular networks. For these methods a range of 797 measurement parameters can be collected by the network, Device, or 798 both in cooperation. This document includes a basic identifier for 799 the wireless transmitter only; future efforts might define additional 800 parameters that enable more accurate methods of location 801 determination. 803 The cellular measurement set allows a Device to report to a LIS any 804 LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10) 805 cells that it is able to observe. Cells are reported using their 806 global identifiers. All 3GPP cells are identified by public land 807 mobile network (PLMN), which is formed of mobile country code (MCC) 808 and mobile network code (MNC); specific fields are added for each 809 network type. 811 Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003]. 812 Bit-level formats for CDMA cell identifiers are described in 813 [TIA-2000.5]; decimal representations are used. 815 MCC and MNC are provided as digit sequences; a leading zero in an MCC 816 or MNC is significant. All other values are decimal integers. 818 820 821 822 4652080936424 823 824 826 4650610736789 827 828 829 831 Long term evolution (LTE) cells are identified by a 28-bit cell 832 identifier (eucid). 834 Figure 7: Example LTE Cellular Measurement 836 838 839 840 46520 841 200065000 842 843 844 46506 845 1638332767 846 847 848 850 Universal mobile telephony service (UMTS) cells are identified by 12- 851 or 16-bit radio network controller (rnc) id and a 16-bit cell id 852 (cid). 854 Figure 8: Example UMTS Cellular Measurement 856 858 859 860 46506 861 1638332767 862 863 864 866 Global System for Mobile communication (GSM) cells are identified by 867 a 16-bit location area code (lac) and 16-bit cell id (cid). 869 Figure 9: Example GSM Cellular Measurement 871 873 874 875 15892472312 876 877 878 15892472313 879 880 881 883 Code division multiple access (CDMA) cells are not identified by 884 PLMN, instead these use a 15-bit system id (sid), a 16-bit network id 885 (nid) and a 16-bit base station id (baseid). 887 Figure 10: Example CDMA Cellular Measurement 889 In general a cellular Device will be attached to the cellular network 890 and so the notion of a serving cell exists. Cellular network also 891 provide overlap between neighbouring sites, so a mobile Device can 892 hear more than one cell. The measurement schema supports sending 893 both the serving cell and any other cells that the mobile might be 894 able to hear. In some cases, the Device may simply be listening to 895 cell information without actually attaching to the network, mobiles 896 without a SIM are an example of this. In this case the Device may 897 simply report cells it can hear without flagging one as a serving 898 cell. An example of this is shown in Figure 11. 900 902 903 904 46520 905 200065000 906 907 908 46506 909 1638332767 910 911 912 914 Figure 11: Example Observed Cellular Measurement 916 5.4.1. Cellular Measurement Requests 918 Two elements can be used in measurement requests for cellular 919 measurements: 921 type: A label indicating the type of identifier to provide: one of 922 "gsm", "umts", "lte", or "cdma". 924 network: The network portion of the cell identifier. For 3GPP 925 networks, this is the combination of MCC and MNC; for CDMA, this 926 is the network identifier. 928 Multiple identifier types or networks can be identified by repeating 929 either element. 931 5.5. GNSS Measurements 933 GNSS use orbiting satellites to transmit signals. A Device with a 934 GNSS receiver is able to take measurements from the satellite 935 signals. The results of these measurements can be used to determine 936 time and the location of the Device. 938 Determining location and time in autonomous GNSS receivers follows 939 three steps: 941 Signal acquisition: During the signal acquisition stage, the 942 receiver searches for the repeating code that is sent by each GNSS 943 satellite. Successful operation typically requires measurement 944 data for a minimum of 5 satellites. At this stage, measurement 945 data is available to the Device. 947 Navigation message decode: Once the signal has been acquired, the 948 receiver then receives information about the configuration of the 949 satellite constellation. This information is broadcast by each 950 satellite and is modulated with the base signal at a low rate; for 951 instance, GPS sends this information at about 50 bits per second. 953 Calculation: The measurement data is combined with the data on the 954 satellite constellation to determine the location of the receiver 955 and the current time. 957 A Device that uses a GNSS receiver is able to report measurements 958 after the first stage of this process. A LIS can use the results of 959 these measurements to determine a location. In the case where there 960 are fewer results available than the optimal minimum, the LIS might 961 be able to use other sources of measurement information and combine 962 these with the available measurement data to determine a position. 964 Note: The use of different sets of GNSS _assistance data_ can 965 reduce the amount of time required for the signal acquisition 966 stage and obviate the need for the receiver to extract data on the 967 satellite constellation. Provision of assistance data is outside 968 the scope of this document. 970 Figure 12 shows an example of GNSS measurement data. The measurement 971 shown is for the GPS system and includes measurement data for three 972 satellites only. 974 976 978 979 499.9395 980 0.87595747 981 45 982 983 984 378.2657 985 0.56639479 986 52 987 988 989 -633.0309 990 0.57016835 991 48 992 993 994 996 Figure 12: Example GNSS Measurement 998 Each "gnss" element represents a single set of GNSS measurement data, 999 taken at a single point in time. Measurements taken at different 1000 times can be included in different "gnss" elements to enable 1001 iterative refinement of results. 1003 GNSS measurement parameters are described in more detail in the 1004 following sections. 1006 5.5.1. GNSS System and Signal 1008 The GNSS measurement structure is designed to be generic and to apply 1009 to different GNSS types. Different signals within those systems are 1010 also accounted for and can be measured separately. 1012 The GNSS type determines the time system that is used. An indication 1013 of the type of system and signal can ensure that the LIS is able to 1014 correctly use measurements. 1016 Measurements for multiple GNSS types and signals can be included by 1017 repeating the "gnss" element. 1019 This document creates an IANA registry for GNSS types. Two satellite 1020 systems are registered by this document: GPS [GPS.ICD] and Galileo 1021 [Galileo.ICD]. Details for the registry are included in Section 9.1. 1023 5.5.2. Time 1025 Each set of GNSS measurements is taken at a specific point in time. 1026 The "time" attribute is used to indicate the time that the 1027 measurement was acquired, if the receiver knows how the time system 1028 used by the GNSS relates to UTC time. 1030 Alternative to (or in addition to) the measurement time, the 1031 "gnssTime" element MAY be included. The "gnssTime" element includes 1032 a relative time in milliseconds using the time system native to the 1033 satellite system. For the GPS satellite system, the "gnssTime" 1034 element includes the time of week in milliseconds. For the Galileo 1035 system, the "gnssTime" element includes the time of day in 1036 milliseconds. 1038 The accuracy of the time measurement provided is critical in 1039 determining the accuracy of the location information derived from 1040 GNSS measurements. The receiver SHOULD indicate an estimated time 1041 error for any time that is provided. An RMS error can be included 1042 for the "gnssTime" element, with a value in milliseconds. 1044 5.5.3. Per-Satellite Measurement Data 1046 Multiple satellites are included in each set of GNSS measurements 1047 using the "sat" element. Each satellite is identified by a number in 1048 the "num" attribute. The satellite number is consistent with the 1049 identifier used in the given GNSS. 1051 Both the GPS and Galileo systems use satellite numbers between 1 and 1052 64. 1054 The GNSS receiver measures the following parameters for each 1055 satellite: 1057 doppler: The observed Doppler shift of the satellite signal, 1058 measured in meters per second. This is converted from a value in 1059 Hertz by the receiver to allow the measurement to be used without 1060 knowledge of the carrier frequency of the satellite system. This 1061 value includes an optional RMS error attribute, also measured in 1062 meters per second. 1064 codephase: The observed code phase for the satellite signal, 1065 measured in milliseconds. This is converted the system-specific 1066 value of chips or wavelengths into a system independent value. 1068 Larger values indicate larger distances from satellite to 1069 receiver. This value includes an optional RMS error attribute, 1070 also measured in milliseconds. 1072 cn0: The signal to noise ratio for the satellite signal, measured in 1073 decibel-Hertz (dB-Hz). The expected range is between 20 and 50 1074 dB-Hz. 1076 mp: An estimation of the amount of error that multipath signals 1077 contribute in metres. This parameter is optional. 1079 cq: An indication of the carrier quality. Two attributes are 1080 included: "continuous" may be either "true" or "false"; direct may 1081 be either "direct" or "inverted". This parameter is optional. 1083 adr: The accumulated Doppler range, measured in metres. This 1084 parameter is optional and is not useful unless multiple sets of 1085 GNSS measurements are provided or differential positioning is 1086 being performed. 1088 All values are converted from measures native to the satellite system 1089 to generic measures to ensure consistency of interpretation. Unless 1090 necessary, the schema does not constrain these values. 1092 5.5.4. GNSS Measurement Requests 1094 Measurement requests can include a "gnss" element, which includes the 1095 "system" and "signal" attributes. Multiple elements can be included 1096 to indicate a requests for GNSS measurements from multiple systems or 1097 signals. 1099 5.6. DSL Measurements 1101 Digital Subscriber Line (DSL) networks rely on a range of network 1102 technologies. DSL deployments regularly require cooperation between 1103 multiple organizations. These fall into two broad categories: 1104 infrastructure providers and Internet service providers (ISPs). For 1105 the same end user, an infrastructure and Internet service can be 1106 provided by different entities. Infrastructure providers manage the 1107 bulk of the physical infrastructure including cabling. End users 1108 obtain their service from an ISP, which manages all aspects visible 1109 to the end user including IP address allocation and operation of a 1110 LIS. See [DSL.TR025] and [DSL.TR101] for further information on DSL 1111 network deployments and the parameters that are available. 1113 Exchange of measurement information between these organizations is 1114 necessary for location information to be correctly generated. The 1115 ISP LIS needs to acquire location information from the infrastructure 1116 provider. However, since the infrastructure provider could have no 1117 knowledge of Device identifiers, it can only identify a stream of 1118 data that is sent to the ISP. This is resolved by passing 1119 measurement data relating to the Device to a LIS operated by the 1120 infrastructure provider. 1122 5.6.1. L2TP Measurements 1124 Layer 2 Tunneling Protocol (L2TP) [RFC2661] is a common means of 1125 linking the infrastructure provider and the ISP. The infrastructure 1126 provider LIS requires measurement data that identifies a single L2TP 1127 tunnel, from which it can generate location information. Figure 13 1128 shows an example L2TP measurement. 1130 1132 1133 1134 192.0.2.10 1135 192.0.2.61 1136 528 1137 1138 1139 1141 Figure 13: Example DSL L2TP Measurement 1143 5.6.2. RADIUS Measurements 1145 When authenticating network access, the infrastructure provider might 1146 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or 1147 Access Node (AN). These messages provide the ISP RADIUS server with 1148 an identifier for the DSLAM or AN, plus the slot and port that the 1149 Device is attached on. These data can be provided as a measurement, 1150 which allows the infrastructure provider LIS to generate location 1151 information. 1153 The format of the AN, slot and port identifiers are not defined in 1154 the RADIUS protocol. Slot and port together identify a circuit on 1155 the AN, analogous to the circuit identifier in [RFC3046]. These 1156 items are provided directly, as they were in the RADIUS message. An 1157 example is shown in Figure 14. 1159 1161 1162 AN-7692 1163 3 1164 06 1165 1166 1168 Figure 14: Example DSL RADIUS Measurement 1170 5.6.3. Ethernet VLAN Tag Measurements 1172 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM) 1173 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is 1174 used to identify the incoming residential circuit, while the S-TAG is 1175 used to identify the DSLAM or AN. The C-TAG and S-TAG together can 1176 be used to identify a single point of network attachment. An example 1177 is shown in Figure 15. 1179 1181 1182 613 1183 1097 1184 1185 1187 Figure 15: Example DSL VLAN Tag Measurement 1189 Alternatively, the C-TAG can be replaced by data on the slot and port 1190 that the Device is attached to. This information might be included 1191 in RADIUS requests that are proxied from the infrastructure provider 1192 to the ISP RADIUS server. 1194 5.6.4. ATM Virtual Circuit Measurements 1196 An ATM virtual circuit can be employed between the ISP and 1197 infrastructure provider. Providing the virtual port ID (VPI) and 1198 virtual circuit ID (VCI) for the virtual circuit gives the 1199 infrastructure provider LIS the ability to identify a single data 1200 stream. A sample measurement is shown in Figure 16. 1202 1204 1205 55 1206 6323 1207 1208 1210 Figure 16: Example DSL ATM Measurement 1212 6. Privacy Considerations 1214 Location-related measurement data can be as privacy sensitive as 1215 location information. 1217 Measurement data is effectively equivalent to location information if 1218 the contextual knowledge necessary to generate one from the other is 1219 readily accessible. Even where contextual knowledge is difficult to 1220 acquire, there can be no assurance that an authorized recipient of 1221 the contextual knowledge is also authorized to receive location 1222 information. 1224 In order to protect the privacy of the subject of location-related 1225 measurement data, this implies that measurement data is protected 1226 with the same degree of protection as location information. 1228 6.1. Measurement Data Privacy Model 1230 It is less desirable to distribute measurement data in the same 1231 fashion as location information. Measurement data is less useful to 1232 location recipients than location information. Therefore, a simple 1233 distribution model is desirable. 1235 In this simple model, the Device is the only entity that is able to 1236 distribute measurement data. To use an analogy from the GEOPRIV 1237 architecture, the Device - as the Location Generator (or the 1238 Measurement Data Generator) - is the sole entity that can assume the 1239 roles of Rule Maker and Location Server. 1241 No entity is permitted to redistribute measurement data. The Device 1242 directs other entities in how measurement data is used and retained. 1244 6.2. LIS Privacy Requirements 1246 A LIS MUST NOT reveal location-related measurement data or location 1247 information based on measurement data to any other entity unless 1248 directed to do so by the Device. 1250 By adding measurement data to a request for location information, the 1251 Device implicitly grants permission for the LIS to generate the 1252 requested location information using the measurement data. 1253 Permission to use this data for any other purpose is not implied. 1255 As long as measurement data is only used in serving the request that 1256 contains it, rules regarding data retention are not necessary. A LIS 1257 MUST discard location-related measurement data after servicing a 1258 request, unless the Device grants permission to use that information 1259 for other purposes. 1261 6.3. Measurement Data and Location URIs 1263 A LIS MAY use measurement data provided by the Device to serve 1264 requests to location URIs, if the Device permits it. A Device 1265 permits this by including measurement data in a request that 1266 explicitly requests a location URI. By requesting a location URI, 1267 the Device grants permission for the LIS to use the measurement data 1268 in serving requests to that URI. 1270 Note: In HELD, the "any" type is not an explicit request for a 1271 location URI, though a location URI might be provided. 1273 The usefulness of measurement data that is provided in this fashion 1274 is limited. The measurement data is only valid at the time that it 1275 was acquired by the Device. At the time that a request is made to a 1276 location URI, the Device might have moved, rendering the measurement 1277 data incorrect. 1279 A Device is able to explicitly limit the time that a LIS retains 1280 measurement data by adding an expiry time to the measurement data, 1281 see Section 4.1.2. 1283 6.4. Third-Party-Provided Measurement Data 1285 An authorized third-party request for the location of a Device (see 1286 [RFC6155]) can include location-related measurement data. This is 1287 possible where the third-party is able to make observations about the 1288 Device. 1290 A third-party that provides measurement data MUST be authorized to 1291 provide the specific measurement for the identified device. A third- 1292 party MUST either be trusted by the LIS for the purposes of providing 1293 measurement data of the provided type, or the measurement data MUST 1294 be validated (see Section 7.2.1) before being used. 1296 How a third-party authenticates its identity or gains authorization 1297 to use measurement data is not covered by this document. 1299 7. Security Considerations 1301 Use of location-related measurement data has privacy considerations 1302 that are discussed in Section 6. 1304 7.1. Threat Model 1306 The threat model for location-related measurement data concentrates 1307 on the Device providing falsified, stolen or incorrect measurement 1308 data. 1310 A Device that provides location location-related measurement data 1311 might use data to: 1313 o acquire the location of another Device, without authorization; 1315 o extract information about network topology; or 1317 o coerce the LIS into providing falsified location information based 1318 on the measurement data. 1320 Location-related measurement data describes the physical environment 1321 or network attachment of a Device. A third party adversary in the 1322 proximity of the Device might be able to alter the physical 1323 environment such that the Device provides measurement data that is 1324 controlled by the third party. This might be used to indirectly 1325 control the location information that is derived from measurement 1326 data. 1328 7.1.1. Acquiring Location Information Without Authorization 1330 Requiring authorization for location requests is an important part of 1331 privacy protections of a location protocol. A location configuration 1332 protocol usually operates under a restricted policy that allows a 1333 requester to obtain their own location. HELD identity extensions 1334 [RFC6155] allows other entities to be authorized, conditional on a 1335 Rule Maker providing sufficient authorization. 1337 The intent of these protections is to ensure that a location 1338 recipient is authorized to acquire location information. Location- 1339 related measurement data could be used by an attacker to circumvent 1340 such authorization checks if the association between measurement data 1341 and Target Device is not validated by a LIS. 1343 A LIS can be coerced into providing location information for a Device 1344 that a location recipient is not authorized to receive. A request 1345 identifies one Device (implicitly or explicitly), but measurement 1346 data is provided for another Device. If the LIS does not check that 1347 the measurement data is for the identified Device, it could 1348 incorrectly authorize the request. 1350 By using unverified measurement data to generate a response, the LIS 1351 provides information about a Device without appropriate 1352 authorization. 1354 The feasibility of this attack depends on the availability of 1355 information that links a Device with measurement data. In some 1356 cases, measurement data that is correlated with a target is readily 1357 available. For instance, LLDP measurements (Section 5.1) are 1358 broadcast to all nodes on the same network segment. An attacker on 1359 that network segment can easily gain measurement data that relates a 1360 Device with measurements. 1362 For some types of measurement data, it's necessary for an attacker to 1363 know the location of the target in order to determine what 1364 measurements to use. This attack is meaningless for types of 1365 measurement data that require that the attacker first know the 1366 location of the target before measurement data can be acquired or 1367 fabricated. GNSS measurements (Section 5.5) share this trait with 1368 many wireless location determination methods. 1370 7.1.2. Extracting Network Topology Data 1372 Allowing requests with measurements might be used to collect 1373 information about a network topology. This is possible if requests 1374 containing measurements are permitted. 1376 Network topology can be considered sensitive information by a network 1377 operator for commercial or security reasons. While it is impossible 1378 to completely prevent a Device from acquiring some knowledge of 1379 network topology if a location service is provided, a network 1380 operator might desire to limit how much of this information is made 1381 available. 1383 Mapping a network topology does not require that an attacker be able 1384 to associate measurement data with a particular Device. If a 1385 requester is able to try a number of measurements, it is possible to 1386 acquire information about network topology. 1388 It is not even necessary that the measurements are valid; random 1389 guesses are sufficient, provided that there is no penalty or cost 1390 associated with attempting to use the measurements. 1392 7.1.3. Lying By Proxy 1394 Location information is a function of its inputs, which includes 1395 measurement data. Thus, falsified measurement data can be used to 1396 alter the location information that is provided by a LIS. 1398 Some types of measurement data are relatively easy to falsify in a 1399 way that the resulting location information to be selected with 1400 little or no error. For instance, GNSS measurements are easy to use 1401 for this purpose because all the contextual information necessary to 1402 calculate a position using measurements is broadcast by the 1403 satellites [HARPER]. 1405 An attacker that falsifies measurement data gains little if they are 1406 the only recipients of the result. The attacker knows that the 1407 location information is bad. The attacker only gains if the 1408 information can somehow be attributed to the LIS by another location 1409 recipient. 1411 A recipient might evaluate the trustworthiness of the location 1412 information based on the credibility of its source. By coercing the 1413 LIS into providing falsified location information, any credibility 1414 that the LIS might have - that the attacker does not - is gained by 1415 the attacker. 1417 A third-party that is reliant on the integrity of the location 1418 information might base an evaluation of the credibility of the 1419 information on the source of the information. If that third party is 1420 able to attribute location information to the LIS, then an attacker 1421 might gain. 1423 Location information that is provided to the Device without any means 1424 to identify the LIS as its source is not subject to this attack. The 1425 Device is identified as the source of the data when it distributes 1426 the location information to location recipients. 1428 An attacker gains if they are able to coerce the LIS into providing 1429 location information based on falsified measurement data and that 1430 information can be attributed to the LIS. 1432 Location information is attributed to the LIS either through the use 1433 of digital signatures or by having the location recipient directly 1434 interact with the LIS. A LIS that digitally signs location 1435 information becomes identifiable as the source of the data. 1436 Similarly, the LIS is identified as a source of data if a location 1437 recipient acquires information directly from a LIS using a location 1438 URI. 1440 7.1.4. Measurement Replay 1442 The value of some measured properties do not change over time for a 1443 single location. This allows for simple replay attacks, where an 1444 attacker acquires measurements that can later be used without being 1445 detected as being invalid. 1447 Measurement data is frequently an observation of an time-invariant 1448 property of the environment at the subject location. For 1449 measurements of this nature, nothing in the measurement itself is 1450 sufficient proof that the Device is present at the resulting 1451 location. Measurement data might have been previously acquired and 1452 reused. 1454 For instance, the identity of a radio transmitter, if broadcast by 1455 that transmitter, can be collected and stored. An attacker that 1456 wishes it known that they exist at a particular location, can claim 1457 to observe this transmitter at any time. Nothing inherent in the 1458 claim reveals it to be false. 1460 For properties of a network, time-invariance is often directly as a 1461 result of the practicalities of operating the network. Limiting the 1462 changes to a network ensures greater consistency of service. A 1463 largely static network also greatly simplifies the data management 1464 tasks involved with providing a location service. 1466 7.1.5. Environment Spoofing 1468 Some types of measurement data can be altered or influenced by a 1469 third party so that a Device. If it is possible for a third party to 1470 alter the measured phenomenon, then any location information that is 1471 derived from this data can be indirectly influenced. 1473 Altering the environment in this fashion might not require 1474 involvement with either Device or LIS. Measurement that is passive - 1475 where the Device observes a signal or other phenomenon without direct 1476 interaction - are most susceptible to alteration by third parties. 1478 Measurement of radio signal characteristics is especially vulnerable 1479 since an adversary need only be in the general vicinity of the Device 1480 and be able to transmit a signal. For instance, a GNSS spoofer is 1481 able to produce fake signals that claim to be transmitted by any 1482 satellite or set of satellites (see [GPS.SPOOF]). 1484 Measurements that require direct interaction increases the complexity 1485 of the attack. For measurements relating to the communication 1486 medium, a third party cannot avoid direct interaction, they need only 1487 be on the communications path (that is, man in the middle). 1489 Even if the entity that is interacted with is authenticated, this 1490 does not provide any assurance about the integrity of measurement 1491 data. For instance, the Device might authenticate the identity of a 1492 radio transmitter through the use of cryptographic means and obtain 1493 signal strength measurements for that transmitter. Radio signal 1494 strength is trivial for an attacker to increase simply by receiving 1495 and amplifying the raw signal; it is not necessary for the attacker 1496 to be able to understand the signal content. 1498 Note: This particular "attack" is more often completely legitimate. 1499 Radio repeaters are commonplace mechanism used to increase radio 1500 coverage. 1502 Attacks that rely on altering the observed environment of a Device 1503 require countermeasures that affect the measurement process. For 1504 radio signals, countermeasures could include the use of authenticated 1505 signals, altered receiver design. In general, countermeasures are 1506 highly specific to the individual measurement process. An exhaustive 1507 discussion of these issues is left to the relevant literature for 1508 each measurement technology. 1510 A Device that provides measurement data is assumed to be responsible 1511 for applying appropriate countermeasures against this type of attack. 1513 For a Device that is the ultimate recipient of location information 1514 derived from measurement data, a LIS might choose to provide location 1515 information without any validation. The responsibility for ensuring 1516 the veracity of the measurement data lies with the Device. 1518 Measurement data that is susceptible to this sort of influence MUST 1519 be treated as though it were produced by an untrusted Device for 1520 those cases where a location recipient might attribute the location 1521 information to the LIS. Such measurement data MUST be subjected to 1522 the same validation as for other types of attacks that rely on 1523 measurement falsification. 1525 Note: Altered measurement data might be provided by a Device that 1526 has no knowledge of the alteration. Thus, an otherwise trusted 1527 Device might still be an unreliable source of measurement data. 1529 7.2. Mitigation 1531 The following measures can be applied to limit or prevent attacks. 1532 The effectiveness of each depends on the type of measurement data and 1533 how that measurement data is acquired. 1535 Two general approaches are identified for dealing with untrusted 1536 measurement data: 1538 1. Require independent validation of measurement data or the 1539 location information that is produced. 1541 2. Identify the types of sources that provided the measurement data 1542 that location information was derived from. 1544 This section goes into more detail on the different forms of 1545 validation in Section 7.2.1, Section 7.2.2, and Section 7.2.3. The 1546 impact of attributing location information to sources is discussed in 1547 more detail in Section 7.2.4. 1549 7.2.1. Measurement Validation 1551 Detecting that measurement data has been falsified is difficult in 1552 the absence of integrity mechanisms. 1554 Independent confirmation of the veracity of measurement data ensures 1555 that the measurement is accurate and that it applies to the correct 1556 Device. By gathering the same measurement data from a trusted and 1557 independent source, the LIS is able to check that the measurement 1558 data is correct. 1560 Measurement information might contain no inherent indication that it 1561 is falsified. On the contrary, it can be difficult to obtain 1562 information that would provide any degree of assurance that the 1563 measurement device is physically at any particular location. 1564 Measurements that are difficult to verify require other forms of 1565 assurance before they can be used. 1567 7.2.1.1. Effectiveness 1569 Measurement validation MUST be used if measurement data for a 1570 particular Device can be easily acquired by unauthorized location 1571 recipients, as described in Section 7.1.1. This prevents 1572 unauthorized access to location information using measurement data. 1574 Validation of measurement data can be significantly more effective 1575 than independent acquisition of the same. For instance, a Device in 1576 a large Ethernet network could provide a measurement indicating its 1577 point of attachment using LLDP measurements. For a LIS, acquiring 1578 the same measurement data might require a request to all switches in 1579 that network. With the measurement data, validation can target the 1580 identified switch with a specific query. 1582 Validation is effective in identifying falsified measurement data 1583 (Section 7.1.3), including attacks involving replay of measurement 1584 data (Section 7.1.4). Validation also limits the amount of network 1585 topology information (Section 7.1.2) made available to Devices to 1586 that portion of the network topology that they are directly attached. 1588 Measurement validation has no effect if the underlying effect is 1589 being spoofed (Section 7.1.5). 1591 7.2.1.2. Limitations (Unique Observer) 1593 A Device is often in a unique position to make a measurement. It 1594 alone occupies the point in space-time that the location 1595 determination process seeks to determine. The Device becomes a 1596 unique observer for a particular property. 1598 The ability of the Device to become a unique observer makes the 1599 Device invaluable to the location determination process. As a unique 1600 observer, it also makes the claims of a Device difficult to validate 1601 and easily to spoof. 1603 As long as no other entity is capable of making the same 1604 measurements, there is also no other entity that can independently 1605 check that the measurements are correct and applicable to the Device. 1606 A LIS might be unable to validate all or part of the measurement data 1607 it receives from a unique observer. For instance, a signal strength 1608 measurement of the signal from a radio tower cannot be validated 1609 directly. 1611 Some portion of the measurement data might still be independently 1612 verified, even if all information cannot. In the previous example, 1613 the radio tower might be able to provide verification that the Device 1614 is present if it is able to observe a radio signal sent by the 1615 Device. 1617 If measurement data can only be partially validated, the extent to 1618 which it can be validated determines the effectiveness of validation 1619 against these attacks. 1621 The advantage of having the Device as a unique observer is that it 1622 makes it difficult for an attacker to acquire measurements without 1623 the assistance of the Device. Attempts to use measurements to gain 1624 unauthorized access to measurement data (Section 7.1.1) are largely 1625 ineffectual against a unique observer. 1627 7.2.2. Location Validation 1629 Location information that is derived from location-related 1630 measurement data can also be verified against trusted location 1631 information. Rather than validating inputs to the location 1632 determination process, suspect locations are identified at the output 1633 of the process. 1635 Trusted location information is acquired using sources of measurement 1636 data that are trusted. Untrusted location information is acquired 1637 using measurement data provided from untrusted sources, which might 1638 include the Device. These two locations are compared. If the 1639 untrusted location agrees with the trusted location, the untrusted 1640 location information is used. 1642 Algorithms for the comparison of location information are not 1643 included in this document. However, a simple comparison for 1644 agreement might require that the untrusted location be entirely 1645 contained within the uncertainty region of the trusted location. 1647 There is little point in using a less accurate, less trusted 1648 location. Untrusted location information that has worse accuracy 1649 than trusted information can be immediately discarded. There are 1650 multiple factors that affect accuracy, uncertainty and currency being 1651 the most important. How location information is compared for 1652 accuracy is not defined in this document. 1654 7.2.2.1. Effectiveness 1656 Location validation limits the extent to which falsified - or 1657 erroneous - measurement data can cause an incorrect location to be 1658 reported. 1660 Location validation can be more efficient than validation of inputs, 1661 particularly for a unique observer (Section 7.2.1.2). 1663 Validating location ensures that the Device is at or near the 1664 resulting location. Location validation can be used to limit or 1665 prevent all of the attacks identified in this document. 1667 7.2.2.2. Limitations 1669 The trusted location that is used for validation is always less 1670 accurate than the location that is being checked. The amount by 1671 which the untrusted location is more accurate, is the same amount 1672 that an attacker can exploit. 1674 For example, a trusted location might indicate a five kilometer 1675 radius uncertainty region. An untrusted location that describes a 1676 100 meter uncertainty within the larger region might be accepted as 1677 more accurate. An attacker might still falsify measurement data to 1678 select any location within the larger uncertainty region. While the 1679 100 meter uncertainty that is reported seems more accurate, a 1680 falsified location could be anywhere in the five kilometer region. 1682 Where measurement data might have been falsified, the actual 1683 uncertainty is effectively much higher. Local policy might allow 1684 differing degrees of trust to location information derived from 1685 untrusted measurement data. This might not be a boolean operation 1686 with only two possible outcomes: untrusted location information might 1687 be used entirely or not at all, or it could be combined with trusted 1688 location information with the degree to which each contributes based 1689 on a value set in local policy. 1691 7.2.3. Supporting Observations 1693 Replay attacks using previously acquired measurement data are 1694 particularly hard to detect without independent validation. Rather 1695 than validate the measurement data directly, supplementary data might 1696 be used to validate measurements or the location information derived 1697 from those measurements. 1699 These supporting observations could be used to convey information 1700 that provides additional assurance that the Device was acquired at a 1701 specific time and place. In effect, the Device is requested to 1702 provide proof of its presence at the resulting location. 1704 For instance, a Device that measures attributes of a radio signal 1705 could also be asked to provide a sample of the measured radio signal. 1706 If the LIS is able to observe the same signal, the two observations 1707 could be compared. Providing that the signal cannot be predicted in 1708 advance by the Device, this could be used to support the claim that 1709 the Device is able to receive the signal. Thus, the Device is likely 1710 to be within the range that the signal is transmitted. A LIS could 1711 use this to attribute a higher level of trust in the associated 1712 measurement data or resulting location. 1714 7.2.3.1. Effectiveness 1716 The use of supporting observations is limited by the ability of the 1717 LIS to acquire and validate these observations. The advantage of 1718 selecting observations independent of measurement data is that 1719 observations can be selected based on how readily available the data 1720 is for both LIS and Device. The amount and quality of the data can 1721 be selected based on the degree of assurance that is desired. 1723 Use of supporting observations is similar to both measurement 1724 validation and location validation. All three methods rely on 1725 independent validation of one or more properties. Applicability of 1726 each method is similar. 1728 Use of supporting observations can be used to limit or prevent all of 1729 the attacks identified in this document. 1731 7.2.3.2. Limitations 1733 The effectiveness of the validation method depends on the quality of 1734 the supporting observation: how hard it is to obtain at a different 1735 time or place, how difficult it is to guess and what other costs 1736 might be involved in acquiring this data. 1738 In the example of an observed radio signal, requesting a sample of 1739 the signal only provides an assurance that the Device is able to 1740 receive the signal transmitted by the measured radio transmitter. 1741 This only provides some assurance that the Device is within range of 1742 the transmitter. 1744 As with location validation, a Device might still be able to provide 1745 falsified measurements that could alter the value of the location 1746 information as long as the result is within this region. 1748 Requesting additional supporting observations can reduce the size of 1749 the region over which location information can be altered by an 1750 attacker, or increase trust in the result, but each additional has a 1751 cost. Supporting observations contribute little or nothing toward 1752 the primary goal of determining the location of the Device. Any 1753 costs in acquiring supporting observations are balanced against the 1754 degree of integrity desired of the resulting location information. 1756 7.2.4. Attribution 1758 Lying by proxy (Section 7.1.3) relies on the location recipient being 1759 able to attribute location information to a LIS. The effectiveness 1760 of this attack is negated if location information is explicitly 1761 attributed to a particular source. 1763 This requires an extension to the location object that explicitly 1764 identifies the source (or sources) of each item of location 1765 information. 1767 Rather than relying on a process that seeks to ensure that location 1768 information is accurate, this approach instead provides a location 1769 recipient with the information necessary to reach their own 1770 conclusion about the trustworthiness of the location information. 1772 Including an authenticated identity for all sources of measurement 1773 data is presents a number of technical and operational challenges. 1774 It is possible that the LIS has a transient relationship with a 1775 Device. A Device is not expected to share authentication information 1776 with a LIS. There is no assurance that Device identification is 1777 usable by a potential location recipient. Privacy concerns might 1778 also prevent the sharing identification information, even if it were 1779 available and usable. 1781 Identifying the type of measurement source allows a location 1782 recipient to make a decision about the trustworthiness of location 1783 information without depending on having authenticated identity 1784 information for each source. An element for this purpose is defined 1785 in Section 4.4. 1787 When including location information that is based on measurement data 1788 from sources that might be untrusted, a LIS SHOULD include 1789 alternative location information that is derived from trusted sources 1790 of measurement data. Each item of location information can then be 1791 labelled with the source of that data. 1793 A location recipient that is able to identify a specific source of 1794 measurement data (whether it be LIS or Device) can use this 1795 information to attribute location information to either or both 1796 entity. The location recipient is then better able to make decisions 1797 about trustworthiness based on the source of the data. 1799 A location recipient that does not understand the "source" element is 1800 unable to make this distinction. When constructing a PIDF-LO 1801 document, trusted location information MUST be placed in the PIDF-LO 1802 so that it is given higher priority to any untrusted location 1803 information according to Rule #8 of [RFC5491]. 1805 Attribution of information does nothing to address attacks that alter 1806 the observed parameters that are used in location determination 1807 (Section 7.1.5). 1809 7.2.5. Stateful Correlation of Location Requests 1811 Stateful examination of requests can be used to prevent a Device from 1812 attempting to map network topology using requests for location 1813 information (Section 7.1.2). 1815 Simply limiting the rate of requests from a single Device reduces the 1816 amount of data that a Device can acquire about network topology. 1818 8. Measurement Schemas 1820 The schema are broken up into their respective functions. There is a 1821 base container schema into which all measurements are placed, plus 1822 definitions for a measurement request (Section 8.1). A PIDF-LO 1823 extension is defined in a separate schema (Section 8.2). There is a 1824 basic types schema, that contains various base type definitions for 1825 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and 1826 MAC addresses (Section 8.3). Then each of the specific measurement 1827 types is defined in its own schema. 1829 8.1. Measurement Container Schema 1830 1831 1839 1840 1842 1843 1844 1846 This schema defines a framework for location measurements. 1847 1848 1850 1852 1853 1854 1855 1856 1857 1859 1860 1861 1862 1863 1864 1865 1866 1867 1869 1871 1872 1873 1874 1875 1877 1879 1880 1881 1882 1884 1885 1886 1887 1888 1889 1891 1892 1893 1894 1895 1896 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1913 Measurement Container Schema 1915 8.2. Measurement Source Schema 1917 1918 1925 1926 1928 1929 1930 1932 This schema defines an extension to PIDF-LO that indicates the 1933 type of source that produced the measurement data used in 1934 generating the associated location information. 1935 1936 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1952 Measurement Source PIDF-LO Extension Schema 1954 8.3. Base Type Schema 1956 Note that the pattern rules in the following schema wrap due to 1957 length constraints. None of the patterns contain whitespace. 1959 1960 1967 1968 1970 1971 1972 1975 This schema defines a set of base type elements. 1976 1977 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2019 2020 2021 2022 2023 2024 2025 2026 An IP version 6 address, based on RFC 4291. 2027 2028 2029 2030 2031 2032 2033 2034 2035 2037 2039 2041 2043 2045 2047 2048 2049 2050 2058 2059 2060 2061 2063 2064 2065 2066 2071 2072 2074 2075 2076 2077 2079 2080 2082 2084 Base Type Schema 2086 8.4. LLDP Measurement Schema 2088 2089 2097 2098 2100 2101 2102 2104 This schema defines a set of LLDP location measurements. 2105 2106 2108 2110 2111 2112 2113 2114 2115 2116 2117 2120 2121 2122 2123 2124 2126 2127 2128 2129 2131 2132 2133 2135 2136 2137 2138 2139 2140 2142 2144 LLDP measurement schema 2146 8.5. DHCP Measurement Schema 2148 2149 2157 2158 2160 2161 2162 2164 This schema defines a set of DHCP location measurements. 2165 2166 2168 2170 2171 2172 2173 2174 2175 2176 2177 2179 2181 2183 2185 2186 2187 2188 2189 2191 2192 2193 2194 2196 2197 2198 2200 2202 DHCP measurement schema 2204 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 2265 2267 2269 2271 2273 2274 2276 2277 2278 2279 2281 2282 2283 2284 2286 2287 2288 2290 2292 2293 2294 2295 2296 2298 2299 2300 2301 2302 2304 2305 2306 2307 2308 2309 2310 2311 2312 2314 2315 2316 2317 2319 2320 2321 2322 2323 2325 2326 2327 2328 2329 2331 2332 2334 2336 2338 2339 2340 2341 2343 2344 2345 2346 2347 2348 2349 2351 2352 2353 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2370 2372 WiFi measurement schema 2374 8.7. Cellular Measurement Schema 2376 2377 2384 2385 2387 2388 2389 2391 This schema defines a set of cellular location measurements. 2392 2393 2395 2397 2398 2399 2400 2401 2402 2403 2404 2405 2407 2408 2409 2411 2412 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2433 2434 2435 2436 2437 2438 2440 2441 2443 2444 2445 2446 2448 2449 2450 2451 2452 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2465 2467 2468 2469 2470 2471 2472 2473 2474 2475 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2492 2494 Cellular measurement schema 2496 8.8. GNSS Measurement Schema 2498 2499 2507 2508 2510 2511 2512 2514 This schema defines a set of GNSS location measurements 2515 2516 2518 2520 2521 2522 2523 2524 2525 2526 2528 2529 2530 2531 2532 2534 2536 2538 2539 2540 2541 2542 2543 2544 2546 2547 2548 2549 2550 2551 2553 2554 2556 2558 2559 2560 2562 2563 2564 2566 2567 2568 2569 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2584 GNSS measurement Schema 2586 8.9. DSL Measurement Schema 2588 2589 2597 2598 2600 DSL measurement definitions 2601 2602 2603 2605 This schema defines a basic set of DSL location measurements. 2606 2607 2609 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2667 2669 DSL measurement schema 2671 9. IANA Considerations 2673 This section creates a registry for GNSS types (Section 5.5) and 2674 registers the namespaces and schema defined in Section 8. 2676 9.1. IANA Registry for GNSS Types 2678 This document establishes a new IANA registry for "Global Navigation 2679 Satellite System (GNSS) types". The registry includes tokens for the 2680 GNSS type and for each of the signals within that type. Referring to 2681 [RFC5226], this registry operates under "Specification Required" 2682 rules. The IESG will appoint an Expert Reviewer who will advise IANA 2683 promptly on each request for a new or updated GNSS type. 2685 Each entry in the registry requires the following information: 2687 GNSS name: the name of the GNSS 2689 Brief description: a brief description of the GNSS 2691 GNSS token: a token that can be used to identify the GNSS 2693 Signals: a set of tokens that represent each of the signals that the 2694 system provides 2696 Documentation reference: a reference to one or more stable, public 2697 specifications that outline usage of the GNSS, including (but not 2698 limited to) signal specifications and time systems 2700 The registry initially includes two registrations: 2702 GNSS name: Global Positioning System (GPS) 2704 Brief description: a system of satellites that use spread-spectrum 2705 transmission, operated by the US military for commercial and 2706 military applications 2708 GNSS token: gps 2710 Signals: L1, L2, L1C, L2C, L5 2712 Documentation reference: Navstar GPS Space Segment/Navigation User 2713 Interface [GPS.ICD] 2715 GNSS name: Galileo 2717 Brief description: a system of satellites that operate in the same 2718 spectrum as GPS, operated by the European Union for commercial 2719 applications 2721 GNSS Token: galileo 2723 Signals: L1, E5A, E5B, E5A+B, E6 2725 Documentation Reference: Galileo Open Service Signal In Space 2726 Interface Control Document (SIS ICD) [Galileo.ICD] 2728 9.2. URN Sub-Namespace Registration for 2729 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2731 This section registers a new XML namespace, 2732 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines 2733 in [RFC3688]. 2735 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2737 Registrant Contact: IETF, GEOPRIV working group, 2738 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2740 XML: 2742 BEGIN 2743 2744 2746 2747 2748 Measurement Source for PIDF-LO 2749 2750 2751

Namespace for Location Measurement Source

2752

urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc

2753 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2754 with the RFC number for this specification.]] 2755

See RFCXXXX.

2756 2757 2758 END 2760 9.3. URN Sub-Namespace Registration for 2761 urn:ietf:params:xml:ns:geopriv:lm 2763 This section registers a new XML namespace, 2764 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in 2765 [RFC3688]. 2767 URI: urn:ietf:params:xml:ns:geopriv:lm 2769 Registrant Contact: IETF, GEOPRIV working group, 2770 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2772 XML: 2774 BEGIN 2775 2776 2778 2779 2780 Measurement Container 2781 2782 2783

Namespace for Location Measurement Container

2784

urn:ietf:params:xml:ns:geopriv:lm

2785 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2786 with the RFC number for this specification.]] 2787

See RFCXXXX.

2788 2789 2790 END 2792 9.4. URN Sub-Namespace Registration for 2793 urn:ietf:params:xml:ns:geopriv:lm:basetypes 2795 This section registers a new XML namespace, 2796 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines 2797 in [RFC3688]. 2799 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes 2801 Registrant Contact: IETF, GEOPRIV working group, 2802 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2804 XML: 2806 BEGIN 2807 2808 2810 2811 2812 Base Device Types 2813 2814 2815

Namespace for Base Types

2816

urn:ietf:params:xml:ns:geopriv:lm:basetypes

2817 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2818 with the RFC number for this specification.]] 2819

See RFCXXXX.

2820 2821 2822 END 2824 9.5. URN Sub-Namespace Registration for 2825 urn:ietf:params:xml:ns:geopriv:lm:lldp 2827 This section registers a new XML namespace, 2828 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in 2829 [RFC3688]. 2831 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp 2833 Registrant Contact: IETF, GEOPRIV working group, 2834 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2836 XML: 2838 BEGIN 2839 2840 2843 2844 2845 LLDP Measurement Set 2846 2847 2848

Namespace for LLDP Measurement Set

2849

urn:ietf:params:xml:ns:geopriv:lm:lldp

2850 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2851 with the RFC number for this specification.]] 2852

See RFCXXXX.

2853 2854 2855 END 2857 9.6. URN Sub-Namespace Registration for 2858 urn:ietf:params:xml:ns:geopriv:lm:dhcp 2860 This section registers a new XML namespace, 2861 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in 2862 [RFC3688]. 2864 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp 2866 Registrant Contact: IETF, GEOPRIV working group, 2867 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2869 XML: 2871 BEGIN 2872 2873 2875 2876 2877 DHCP Measurement Set 2878 2879 2880

Namespace for DHCP Measurement Set

2881

urn:ietf:params:xml:ns:geopriv:lm:dhcp

2882 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2883 with the RFC number for this specification.]] 2884

See RFCXXXX.

2885 2886 2887 END 2889 9.7. URN Sub-Namespace Registration for 2890 urn:ietf:params:xml:ns:geopriv:lm:wifi 2892 This section registers a new XML namespace, 2893 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in 2894 [RFC3688]. 2896 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi 2898 Registrant Contact: IETF, GEOPRIV working group, 2899 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2901 XML: 2903 BEGIN 2904 2905 2907 2908 2909 WiFi Measurement Set 2910 2911 2912

Namespace for WiFi Measurement Set

2913

urn:ietf:params:xml:ns:geopriv:lm:wifi

2914 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2915 with the RFC number for this specification.]] 2916

See RFCXXXX.

2917 2918 2919 END 2921 9.8. URN Sub-Namespace Registration for 2922 urn:ietf:params:xml:ns:geopriv:lm:cell 2924 This section registers a new XML namespace, 2925 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in 2926 [RFC3688]. 2928 URI: urn:ietf:params:xml:ns:geopriv:lm:cell 2930 Registrant Contact: IETF, GEOPRIV working group, 2931 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2933 XML: 2935 BEGIN 2936 2937 2939 2940 2941 Cellular Measurement Set 2942 2943 2944

Namespace for Cellular Measurement Set

2945

urn:ietf:params:xml:ns:geopriv:lm:cell

2946 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2947 with the RFC number for this specification.]] 2948

See RFCXXXX.

2949 2950 2951 END 2953 9.9. URN Sub-Namespace Registration for 2954 urn:ietf:params:xml:ns:geopriv:lm:gnss 2956 This section registers a new XML namespace, 2957 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in 2958 [RFC3688]. 2960 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss 2962 Registrant Contact: IETF, GEOPRIV working group, 2963 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2965 XML: 2967 BEGIN 2968 2969 2971 2972 2973 GNSS Measurement Set 2974 2975 2976

Namespace for GNSS Measurement Set

2977

urn:ietf:params:xml:ns:geopriv:lm:gnss

2978 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2979 with the RFC number for this specification.]] 2980

See RFCXXXX.

2981 2983 2984 END 2986 9.10. URN Sub-Namespace Registration for 2987 urn:ietf:params:xml:ns:geopriv:lm:dsl 2989 This section registers a new XML namespace, 2990 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in 2991 [RFC3688]. 2993 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl 2995 Registrant Contact: IETF, GEOPRIV working group, 2996 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 2998 XML: 3000 BEGIN 3001 3002 3004 3005 3006 DSL Measurement Set 3007 3008 3009

Namespace for DSL Measurement Set

3010

urn:ietf:params:xml:ns:geopriv:lm:dsl

3011 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 3012 with the RFC number for this specification.]] 3013

See RFCXXXX.

3014 3015 3016 END 3018 9.11. XML Schema Registration for Measurement Source Schema 3020 This section registers an XML schema as per the guidelines in 3021 [RFC3688]. 3023 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc 3025 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3026 Martin Thomson (martin.thomson@commscope.com). 3028 Schema: The XML for this schema can be found in Section 8.2 of this 3029 document. 3031 9.12. XML Schema Registration for Measurement Container Schema 3033 This section registers an XML schema as per the guidelines in 3034 [RFC3688]. 3036 URI: urn:ietf:params:xml:schema:lm 3038 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3039 Martin Thomson (martin.thomson@commscope.com). 3041 Schema: The XML for this schema can be found in Section 8.1 of this 3042 document. 3044 9.13. XML Schema Registration for Base Types Schema 3046 This section registers an XML schema as per the guidelines in 3047 [RFC3688]. 3049 URI: urn:ietf:params:xml:schema:lm:basetypes 3051 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3052 Martin Thomson (martin.thomson@commscope.com). 3054 Schema: The XML for this schema can be found in Section 8.3 of this 3055 document. 3057 9.14. XML Schema Registration for LLDP Schema 3059 This section registers an XML schema as per the guidelines in 3060 [RFC3688]. 3062 URI: urn:ietf:params:xml:schema:lm:lldp 3064 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3065 Martin Thomson (martin.thomson@commscope.com). 3067 Schema: The XML for this schema can be found in Section 8.4 of this 3068 document. 3070 9.15. XML Schema Registration for DHCP Schema 3072 This section registers an XML schema as per the guidelines in 3073 [RFC3688]. 3075 URI: urn:ietf:params:xml:schema:lm:dhcp 3076 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3077 Martin Thomson (martin.thomson@commscope.com). 3079 Schema: The XML for this schema can be found in Section 8.5 of this 3080 document. 3082 9.16. XML Schema Registration for WiFi Schema 3084 This section registers an XML schema as per the guidelines in 3085 [RFC3688]. 3087 URI: urn:ietf:params:xml:schema:lm:wifi 3089 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3090 Martin Thomson (martin.thomson@commscope.com). 3092 Schema: The XML for this schema can be found in Section 8.6 of this 3093 document. 3095 9.17. XML Schema Registration for Cellular Schema 3097 This section registers an XML schema as per the guidelines in 3098 [RFC3688]. 3100 URI: urn:ietf:params:xml:schema:lm:cellular 3102 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3103 Martin Thomson (martin.thomson@commscope.com). 3105 Schema: The XML for this schema can be found in Section 8.7 of this 3106 document. 3108 9.18. XML Schema Registration for GNSS Schema 3110 This section registers an XML schema as per the guidelines in 3111 [RFC3688]. 3113 URI: urn:ietf:params:xml:schema:lm:gnss 3115 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3116 Martin Thomson (martin.thomson@commscope.com). 3118 Schema: The XML for this schema can be found in Section 8.8 of this 3119 document. 3121 9.19. XML Schema Registration for DSL Schema 3122 This section registers an XML schema as per the guidelines in 3123 [RFC3688]. 3125 URI: urn:ietf:params:xml:schema:lm:dsl 3127 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 3128 Martin Thomson (martin.thomson@commscope.com). 3130 Schema: The XML for this schema can be found in Section 8.9 of this 3131 document. 3133 10. Acknowledgements 3135 Thanks go to Simon Cox for his comments relating to terminology that 3136 have helped ensure that this document is aligns with ongoing work in 3137 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his 3138 review and comments on the GNSS sections of this document. Thanks to 3139 Noor-E-Gagan Singh, Gabor Bajko, Russell Priebe, and Khalid Al-Mufti 3140 for their significant input to and suggestions for improving the 3141 802.11 measurements. Thanks to Cullen Jennings for feedback and 3142 suggestions. Bernard Aboba provided review and feedback on a range 3143 of measurement data definitions. Mary Barnes and Geoff Thompson 3144 provided a review and corrections. David Waitzman and John Bressler 3145 both noted shortcomings with 802.11 measurements. Keith Drage, 3146 Darren Pawson provided expert LTE knowledge. 3148 11. References 3150 11.1. Normative References 3152 [ASCII] , "US-ASCII. Coded Character Set - 7-Bit American Standard 3153 Code for Information Interchange. Standard ANSI X3.4-1986, 3154 ANSI, 1986.", . 3156 [GPS.ICD] , "Navstar GPS Space Segment/Navigation User Interface", 3157 ICD GPS-200, Apr 2000. 3159 [Galileo.ICD] 3160 GJU, "Galileo Open Service Signal In Space Interface 3161 Control Document (SIS ICD)", May 2006. 3163 [IANA.enterprise] 3164 IANA, "Private Enterprise Numbers", 2011, 3165 . 3167 [IEEE.80211V] 3168 IEEE, "Wireless LAN Medium Access Control (MAC) and 3169 Physical Layer (PHY) specifications - IEEE 802.11 Wireless 3170 Network Management (Draft)", P802.11v D12.0, June 2010. 3172 [IEEE.80211] 3173 IEEE, "Wireless LAN Medium Access Control (MAC) and 3174 Physical Layer (PHY) specifications - IEEE 802.11 Wireless 3175 Network Management", IEEE Std 802.11-2007, June 2007. 3177 [IEEE.8021AB] 3178 IEEE, "IEEE Standard for Local and Metropolitan area 3179 networks, Station and Media Access Control Connectivity 3180 Discovery", IEEE Std 802.1AB-2009, September 2009. 3182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3183 Requirement Levels", BCP 14, RFC 2119, March 1997. 3185 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3186 3046, January 2001. 3188 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3189 10646", STD 63, RFC 3629, November 2003. 3191 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3192 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3193 3986, January 2005. 3195 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID 3196 Suboption for the Dynamic Host Configuration Protocol 3197 (DHCP) Relay Agent Option", RFC 3993, March 2005. 3199 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3200 Format", RFC 4119, December 2005. 3202 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3203 Architecture", RFC 4291, February 2006. 3205 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 3206 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June 3207 2006. 3209 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 3210 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 3211 2006. 3213 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3214 Presence Information Data Format Location Object (PIDF-LO) 3215 Usage Clarification, Considerations, and Recommendations", 3216 RFC 5491, March 2009. 3218 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 3219 5985, September 2010. 3221 [TIA-2000.5] 3222 TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for 3223 cdma2000(R) Spread Spectrum Systems", TIA-2000.5-D, March 3224 2004. 3226 [TS.3GPP.23.003] 3227 3GPP, "Numbering, addressing and identification", 3GPP TS 3228 23.003 9.4.0, September 2010. 3230 11.2. Informative References 3232 [ANSI-TIA-1057] 3233 ANSI/TIA, "Link Layer Discovery Protocol for Media 3234 Endpoint Devices", TIA 1057, April 2006. 3236 [DSL.TR025] 3237 Wang, R., "Core Network Architecture Recommendations for 3238 Access to Legacy Data Networks over ADSL", September 1999. 3240 [DSL.TR101] 3241 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 3242 Aggregation", April 2006. 3244 [GPS.SPOOF] 3245 Scott, L., "Anti-Spoofing and Authenticated Signal 3246 Architectures for Civil Navigation Signals", ION-GNSS 3247 Portland, Oregon, 2003. 3249 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side 3250 spoofing and detection for Assisted-GPS", Proceedings of 3251 International Global Navigation Satellite Systems Society 3252 (IGNSS) Symposium 2009 16, December 2009, 3253 . 3255 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 3256 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 3257 RFC 2661, August 1999. 3259 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3260 "Remote Authentication Dial In User Service (RADIUS)", RFC 3261 2865, June 2000. 3263 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3264 January 2004. 3266 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 3267 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 3269 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3270 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3271 May 2008. 3273 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 3274 Barnes, "Use of Device Identity in HTTP-Enabled Location 3275 Delivery (HELD)", RFC 6155, March 2011. 3277 Authors' Addresses 3279 Martin Thomson 3280 Microsoft 3281 3210 Porter Drive 3282 Palo Alto, CA 94304 3283 US 3285 Phone: +1 650-353-1925 3286 Email: martin.thomson@skype.net 3288 James Winterbottom 3289 Commscope 3290 Andrew Building (39) 3291 University of Wollongong 3292 Northfields Avenue 3293 NSW 2522 3294 AU 3296 Phone: +61 2 4221 2938 3297 Email: james.winterbottom@commscope.com